いつの時だってバグの無いソフトウェアを作ることは大変難しいことだが、少なくともバグ・トラッキング・システムを有効に使っているかどうかは、その開発組織を信じていいかどうかの目安になるだろう。
ロゴスウェアでは、もうずいぶん前からTracというシステムを使っている。
Tracでは、バグの管理にチケットという機能を使う。 テスト担当者や顧客からバグが報告されると、これらはすべてチケットという形でシステムに登録され、確実にステータスを追いかけられるのだ。
チケットを管理することにより、どんな問題が報告されていて、何が解決済みで、何に着手していて、何がまだ残っているかが組織全体で把握できる。 チケットは担当者ごとにアサインされるため、一人一人の状況もわかり、取り逃がしも防げる。 これらのことは確実に高品質なソフトウェアに仕上げるための重要な作業だ。
ロゴスウェアもTrac のようなバグ・トラッキング・システムを使わずにやっていた時代があるのではっきり言えるが、「エクセルで管理しています」などと言っている開発組織の作ったソフトウェアの品質など信じない方が良い。
3月6日、スルガ銀行は、銀行業務に関する基幹システムの開発が契約どおりに行われなかったとして日本IBMに約111億円の損害賠償を求める訴訟を起こした。 新システムは予定していた2008年1月を過ぎても稼動の目処が立たず訴訟に踏み切ったということらしい。
数あるソフトウェア開発会社の中でも、おそらくかなりの優秀な人材を抱え、厳格なプロジェクト管理をするであろう日本IBMが訴えられるような事態になることに、ソフトウェア開発の現状の深刻さが浮き彫りになる。
詳しい状況が明らかになっていないのではっきりしたことは言えないが、プロジェクトが大失敗する原因は、事前に期間と予算を正しく見積もれなかったか、仕様がいつまでたっても凍結できなかったかだ。
今回のような深刻な事態に至らないとしても、ソフトウェア開発に関わるものたちは、この二つの問題に日常的に直面している。
見積もりの算出方法にしても、仕様の決定方法にしても、プロジェクトの管理方法にしても、ソフトウェアの業界は多くの努力をし数々の方法論を考え出している。昔よりずいぶんといろいろなことが分かってきているはずだ。
それにも関わらず、ソフトウェア開発においては、いつ誰が地雷を踏んでもおかしくないような状態にあることに変わりがない。
日本IBMは「スルガ銀行との契約上の義務は果たしたと認識している」とコメントしている。委託者としてのスルガ銀行と受託者としての日本IBMには、思いに大きな溝があるに違いない。
スルガ銀行は原因は日本IBMにあると思っていることだろうし（だから提訴したのだから）、日本IBMはスルガ銀行が正確に要求を伝えていなかったり途中で仕様変更を何度もしたりするからだと思っていることだろう。
こういう思いの違いがソフトウェア開発では日常茶飯事なのだ。ずっとこのままでいいわけがない。
ソフトウェアというものは今の社会を動かすあまりにも重要なものであるのだから、もっと社会全体の問題として議論されるべきだ。（もっと言うならば、これらを解決しなければ、プログラマーは過度な長時間労働から解放されないのだ。）
ソフトウェアの開発工程は、「要求仕様定義」、「詳細設計」、「コーディング」、「デバッグ」の４つに分類できる。
時間配分がどうなるかはプロジェクトによって様々だが、一般的には、
要求仕様定義 － 20％
詳細設計 － 20％
コーディング － 20％
デバッグ － 40％
と言われている。
スケジュールや予算の見積もりをするベストなタイミングはどこだろうか？
最も合理的に考えれば、要求仕様定義が終わった後である。 要求仕様定義が完了してはじめて、何を作るのかがわかる。
ところが、一般的な商習慣として、私たちがスケジュールや予算の見積もりを作成しなければいけないのは、要求仕様定義をする前なのだ。
どう考えても、見積もりが間違う。 何を作るのかがはっきりしないのに、スケジュールを組んだり、予算を組んだりするのだから、当然そうなる。
「ソフトウェア開発は人類史上最も複雑な作業である」と主張する人たちがいる。 本当に複雑なのだ。 その工程にほとんど事務作業ですませられる部分のない作業なのだ。
このようなものを何を作るかはっきりしない段階で見積もるなんて、そもそも無理がある。 本当は、要求仕様定義を終えてからすべきなのだ。
しかし、ここに一つの問題がある。 要求仕様定義を終えるということは、全工程の20％を終えているということだ。
顧客との契約が成立するのかどうかわからないものに対して、仕事の20％を無償サービスするわけにはいかない。
最善の方法は、「要求仕様定義」の作成だけを独立した仕事として成立させることではないかと思う。 まず「要求仕様定義」の作成業務だけを取引するのだ。 それを元にその後の開発の金額とスケジュールが提示される。 提示された見積もりに合意すれば、その後の開発も同じ会社が行えばいいし、合意できなければその仕様書を持って別の会社に依頼するのもよい。
考えてみれば、このような仕組みは他の産業ではめずらしいことではない。 例えば、建築業界では、設計者と建築者はわかれている。
ソフトウェア業界でもできるのではないか？ ソフトウェアは今となっては社会を動かす重要な産業なのだからもっと積極的に動くべきだと思う。 どういう団体がこういうことをドライブすべきか知らないが、社会で発生している諸々のトラブル（銀行端末が止まったり、電車の改札口が開かなかったり、・・・・）や労働環境の問題（過度な長時間労働、など）を解決するには、ソフトウェア開発の特性にあった商習慣やルールを作らないといけないときにきているのではないかと思う。
ソニー創業者の一人 故盛田昭夫の著書 「ＭＡＤＥ ＩＮ ＪＡＰＡＮ」 の中に、契約書のことが書かれている。
「日本の契約書には「もし本契約の期間中に、当事者のいずれかに本条項についての異議が生じた場合には、両者は誠意を持って協議するものとする」という条項が最後に書かれるのが一般的だが、アメリカ人にはこれは信じられないことのようだった。」 と書いている。
確かに私たちが目にする契約書にはこの一文が必ず入っていて、それは常識だと思っていたが、どうも世界的に見ればそういうことではないらしい。「ＭＡＤＥ ＩＮ ＪＡＰＡＮ」は1987年の著書だから、20年経過しても、この状況は変わっていない。
冷静に考えてみれば、この契約は変だ。 契約が契約であるならば、「もし本条項に違反した場合には、ＸＸＸＸの賠償金を納める」のような書き方になっていないとおかしい。 それなのに日本の契約書は、「もし破ってしまうようなことがあっても、まあいいですよ。そのときは話し合いましょう」と言っているわけだ。 これでは厳密には約束にはならないので、論理を重んじる外国人には理解不能であろう。
私たちは日本人で日本でビジネスをしているから、それでいいではないかという考えもある。 実際多くの契約書は、それが問題になることはない。 ただ、どうもこの約束をはっきりさせないという日本独特のやり方がソフトウェア開発の契約では、少なからず問題を引き起こすように思われるのだ。
ソフトウェアプログラムの開発は極めて論理的な仕事で、論理が崩れると、その土台からやり直さなければならない事態に陥る。 このような世界で、契約面だけが非論理的であることに違和感を覚えるのだ。 ソフトウェア開発では、最初に要件定義や仕様書などを作成し、それに基づいてプログラミング作業が始まるわけだが、その要件定義や仕様書が途中でいとも簡単に変わってしまうのだ。 これが時として、「もし破ってしまうようなことがあっても、まあいいですよ。そのときは話し合いましょう」と笑ってすまされない事態を引き起こすように思われるのだ。
要件定義や仕様書を始まったら一切変えるなと主張するつもりはない。 実際そのようなものを開発の初期段階で全て把握して書くなんて誰にもできないし、それは馬鹿げている。 せめて、要件定義や仕様が変わったら、こうしましょうね、と約束しておくべきなのだ。
プログラム開発には、まず仕様書が書かれる （・・・はずだ。 これについてはまた書こう）
ここでの問題は仕様書は読まれているのかだ。
ビル・ゲイツは翌日の会議のために、仕様書をプリントアウトし持ち帰り、会議に赤ペンで書き込まれた仕様書を持ってくるという。
これはすごいことだ。 仕様書を読むのは苦行なのだ。
第一に、面白い文書ではない （誰か、スティーヴン・キングのように書いてくれないか？）
第二に、脳をフルに稼動させ、集中させないとどこに論理ミスがあるのかは見つからない。 （間違いなく、IQサプリより難しい！！）
という最もな理由があっても仕様書は読まなければいけない。 論理ミスがあればそれを発見しなければいけない。 ユーザーインターフェースに問題があれば、それを発見しなければいけない。 これらがいつの間にか神の手によって解決されていることを期待してはいけない。 さもなければ、そう、誰もが経験している地獄を見る。 開発の最後の最後になって、ここがおかしい、あそこが間違いだ、となる。
家がすっかり出来上がってから、やっぱりキッチンは東じゃなくて西にしよう、ということになったらどんなことになる?
仕様書のレベルで、ワードの文書のあそこを修正して、そこを追加することは簡単だけど、組みあがったプログラムコードはそんな風に直せない。
憂鬱な気分になるのはやめよう。 みんな幸せでなくては。 だから、仕様書を読もう。
（知っています。 顧客に仕様書を読んでもらうのが難しいことを。 結局最後に仕様書が役に立たなくなることを。 この問題については、また改めて）
