私の担当していたプロジェクトが中断になり、支援として別チームの小さな開発案件の試験を担当することになっていた私ですが、先週ようやくソフトウェアを納品するところまで行きました。その納品を以って、とりあえず開発フェーズは終わり・・・となるはずだったんですが。バグが出ました。ひょえー。
通常、システム開発はウォーターフォールモデルの場合、要件定義、設計、プログラミング、試験、という風に工程が進んでいくんですが、試験工程の中も結構細かく分かれています。我々システムベンダがやる単体試験、結合試験、総合試験の後、最終的にお客さんにシステムを受け渡す前に、お客さん自身が試験を実施してシステムの問題がないことを確認する受入試験と呼ばれる工程が存在します。
普通に上手く開発を進めていれば、受入試験では既にシステムはお客さんの要求を満たすものになっているはず、なんですが、私の開発はこの受入試験でバグが出てしまいました。先ほど述べた通り、受入試験までに各試験プロセスを踏んでいるので、この段階になって初めてバグが出るのは結構な事件です。私も後半の試験を実施していただけに背筋が凍る思いでした。
ただ、蓋を開けてみると、要件定義のミスに起因していることがわかりました。つまり、今回はこういう開発をしますよ、とお客さんと取り決めを行うのが要件定義ですが、ここにお客さんの要求が反映されていなかったんですね。ちなみに要件定義でミスをしていると我々が担当する試験でバグを見つけることはできません。なぜなら、私たちが確認できるのは、あくまで（要求ではなく）要件が満たされていることの確認だからです。
よって責任の一角はあったとしても、私のせいではないことがわかって一安心です。また、我々の会社としても自分たちの非は認めていません。ただ打ち合わせをしている限り、お客さんは我々のミスだと言わんばかりの物言いでした。はて、これは一体。
で、遡るとなぜ要件定義でミスっちゃったのか、という議論になるわけですね。真因はどこにあったのか、と。
ちなみに今回の開発案件は、商用（世の中に出ているシステム）でバグが発生したことに対処するための案件だったんですね。話を簡略化しますが、例えば、A機能を実施すると、処理が実行されるはずがエラーとなってしまう、みたいなバグがあったと思ってもらえればよいです。
で、そのバグを調査していると、実は実装されているべき①という処理が抜けていた、ということが判明したわけです。つまり、①が抜けているためにA機能がエラーになったことがわかったのです。
「じゃあその機能を改修しよう」となる前に、一般的には横並びで確認をするんですね。すなわち、「A機能と似たようなB機能やC機能についても、同じようなエラーになるんじゃないか？」という風に別の似たようなモノについてもチェックする、というのがバグ改修プロセスの定石です。で、そうやって横並びで確認した結果、B機能、C機能、D機能、E機能についても、②、③、④、⑤の処理が抜けているため、エラーとなってしまうことが判明しました。
ただし、「②〜⑤」が抜けているかどうか、というのは他社システムにも関連していたため、私たちの会社だけではわかりえないところだったんです。そのため、他社と認識を合わせた上で、②〜⑤が抜けている、ということが判明したわけです。そして、この時既に問題が発生していて、①は抜けていないという、商用で発生したバグとは辻褄の合わない回答をもらっていたんです。
結果、開発案件という形になったときには「②〜⑤の処理を追加して、B〜E機能が正常に動作するようにする」という趣旨の要件として定義されてしまった、というわけです。そのため、我々の言い分としては、他社の回答が間違っていたせい要件を誤ったので、我々は悪くないというわけです。
どうでしょうか。結局、誰が悪いんでしょうね。少なくとも、途中参戦の私としては、他社はもちろん、私たちもお客さんにも問題があったと思います。前述の通り、自分にも責任の一角はありますね。でも、正直自分はそんなに悪くなかったと思っています。
はい、ここです。ここなんですね。みんな同じように考えてると思います。多少の責任は自分にもあるけど、自分が真犯人ではない、と。自然とこういう風になってしまう誤りがタイトルのインタフェースエラーというものです。そして、この誤りが大問題の発覚を遅らせ、また一度犯しても改善するのが難しい、実に根が深い問題です。
Aさん「あの時こう言いましたよね？」
Bさん「いえ、聞いてません。」
こんなやり取りの「言った言わない問題」もインタフェースエラーの代表格です。こういうことを防ぐために、正式な決め事は契約書などの文書にして残すのが現代の会社では当たり前ですけど、例えば、少し曖昧な表現で書かれていれば契約書は意味を成さないものになってしまいます。
Aさん「私はこういうつもりで書いた」
Bさん「私はこういう意図だと読み取った」
という風に、お互いの認識がずれていたらお互いが自分は悪くない、という思考になってしまいますから。自分が改善するのではなく、相手に改善を期待するようになります。
これが私は非常に馬鹿げていると思うんですよね。今回バグが見つかった時も少しどっちが悪いのかを決める喧嘩みたいな議論にもなりましたけど、アホ臭ーと思ってました。どっちが悪いとかどうでもええんすわ。大切なのは良くするためにどうするかでしょ〜と思います。馬鹿げていると言いつつ、お金の問題が絡むので、会社としては簡単に責任を認められないんですけどね。。。
人が成長するために必要なのって、自分の権限や責任範囲が明確であることだと思います。何故かと言うと、自分の権限とか責任範囲が明確じゃないと失敗があった時に自分が悪いと思えないじゃないですか。自分の非を自覚していない人間は成長できないんですよ。インタフェースエラーが中々改善されないのも全く同じ理屈です。
良い組織はきっとこのインタフェースエラーを無くすための仕組みというのができています。でも、そうじゃない組織というのも結構多いんでしょう。そんな組織に入ってしまったらどうするべきか。あるいは自分としてこういったインタフェースエラーに巻き込まれた時にどう考えるべきか。
方法は二つだと思っています。
一つは言質を取る、という方法ですね。例えば、上司と認識齟齬が発生しないレベルの具体度で自分の責任範囲をガチガチに定めて、その中は自分の責任、他は自分の責任の範疇ではないと、公平な目で線引できるようにしておくことです。ただ、私はあんまり好きじゃないやり方です。
もう一つは、自分が課長以上権限を持っているつもりになる、ということですね。別に自分がPMだと思って仕事はしてるわけではないですけど、仕事で失敗した場合は必ずPMクラスの視点で省みます。そこで、あーPMのせいだな、と言って終わらせない。PMのせいだけど、PMはそのレベルの仕事しかできないから、いかにして自分の立場で補うのか、を考える。それだけでも全然違うでしょう。
実際、「自分を上手く使ってくれ」という上司が多いです。私はそういった上司として投げやりやスタンスは嫌いなんですが、いい意味で受け取ると課長権限を使えるってことなんです。つまり、自分には権限がなくてできないと思っている仕事でも上司に頼めばやってもらえる＝自分にも権限がある、ということです。
まぁ同時にそのぐらいの責任もお前にはあるんだ、って言う上司の逃げ道として使われるのがやっぱり腹立たしいですけどね。なら同じ給料寄越せって感じです。でもまぁ個人として、ちょっとでも失敗を改善したいとか仕事できるようになりたいと思うなら、こういう思考法もいいと思います。
