３ 失敗から学ぶ（２）
論理の共有
オフショア開発の現場に限らないが、システムの仕事は論理的思考を常に相棒にしていなければならない。
私も含めてだけれども、状況によって、あるいはしばしば論理的な思考ができなくなる傾向があるという場合は注意が必要である。もしもシステムを構成するピースの１つまたは幾つかが論理的思考から外れてしまえば、それはシステムの中にがん細胞が巣食ってしまうのと同じだ。それが致命的であるかどうかはまた別の問題で、ともかく進んでがん細胞を抱え込むようなことは避けるべきだ。
妥協するか、しないか
システムの論理設計でよくあることだが、とあるコンポーネント内にとある論理的なチャネルが複数必要だとする。通常は１つしか必要でないが、これを仮に４つ定義するとする。余っている３つは一見無駄に見えるが、設計上さまざまな理由で論理的キャパシティを保証するためにそうすることがある。
しかし経緯を知らない人には出来上がった設計の内容だけを見ても、なぜそうなっているのかわからない。
前にも書いたとおり、ヴェトナムへのオフショア開発プロジェクトが始まり設計書を翻訳して現地に送ったまではよかったが、設計の質の低さがブレーキとなり設計をしていた我々も請負先の現地企業もクリンチになってしまった。そうして開発が始まった後、設計者である私は現地のベンダにスペースをもらってほぼ常駐していた。
ある時、疑問をもったプログラマが私のところへ来た。そのエンジニアが翻訳された設計書のコピーを手に質問する。
「通常１つしか使われないこのチャネルをなぜ４つ確保して空けておく必要があるのか？」
論理的な上限があって、それをシステムが保証しなければいけないということを時間をかけて説明する。こういう場合は通訳を間にいれる。
しかし、どうにも彼の納得する答えには到達できなかった。
疲れ果ててしまった私は、そのチャネルは今のところ実際には１つしか使われないので４つでも１つでも同じなのだと言った。
通訳がその内容を伝えると、それを聞いてようやくエンジニアは納得して戻っていった。
さて、結果はどうなったか？
もちろん、４つあるはずの論理的なチャネルは１つになった。少なくとも実装上はそうなった。まさにがん細胞の移植である。
コードレビューをしていて気づいたが後の祭りである。これは違うじゃないかといっても、「１つでも同じだと言いましたね」とそのエンジニアは頑として引き下がらない。
結局ゴリ押ししても設計どおりに修正させることはできなかった。私の負けである。意図しないこととはいえ、相手は譲歩を勝ち取り私はあってはならない妥協をしたことになる。言葉の通じない相手であるからこそ、なおさら論理の土俵上でコミュニケーションを成立させる必要があるし、論理的思考を休ませてはいけない。
まずいとわかっていても頑固に固執しようといっているわけではない。論理的に破綻していると気付いたら、固執せずに潔くよりよい方向に舵を切る勇気も必要だ。
でも、美学的に論理を追求するあまり設計コンセプトや意見などコロコロと変えるようなことも慎みたい。信頼を失いそっぽを向かれてしまうようなことになると、うまくいくものもうまくいかなくなる。この点は注意が必要だ。
後日談になるけれど、このときの”がん細胞”は製品完成後約２年経ってからエンハンス作業の中で私自身が除去した。機能的にその修正が必要になるまで誰も触ることができなかったからである。
理由の如何に関わらず妥協をすればツケは必ず返ってくる。
小石に躓くリスク
上記の話のような、設計したのが自分自身であり内容がよくわかっていながら妥協してしまう上記のような場合は例としては少ないかもしれない。一般的にはブリッジなどで関わったときにまったくの他人の設計した内容について思い込みで判断を誤ったりすることの方がむしろ多いと思う。
人の書いたドキュメントというのはその人なりの思考が反映されており、そこで展開されている論理は基本的に別世界だ。そこを丹念に読み解いていく努力がまず必要だ。そして努力して読み進めていくうち運悪く何かで躓いてしまうと先に進めないことがある。路上に置かれた巨石のようにどうしても先に進めなければ立ち止まることも容易にできる。疑問点をクリアにして先に進むこともできるわけだが、一見立ち止まるほどでない、路上の小石レベルの問題が実はクリティカルな問題だったりすることもある。見逃しやすい分こちらの方が脅威だ。
これを見通すにはかなりの熟練が必要だと思うが、オフショア開発で仕様の取りまとめをする立場になる人やブリッジSEには必要な能力である反面、大抵は経験的に身につくものなので、どうしても時間がかかる。設計者、製造者と直接のコミュニケーションを取るなどして極力こうした齟齬を埋めるべく努力するしかない。
これは人から聞いた話。
あるプロジェクトでオフショア開発先に設計書が送られてきた。
その設計書の中にある外部コンポーネントらしきものが書かれてあり、しかもその説明がどこにもない。しかし至るところでデータを送りつけ、データを刈り取り、処理結果を評価する記述があった。この設計を見たベンダ側のエンジニアは困惑し、そのコンポーネントはどういうものか、インターフェースは何か、概要の資料でもないかとさっそく設計者に確認した。しかしどういうわけか設計者は「説明できないし、その部分に関しての資料はない」の一点張り。離れたところで交わされるコミュニケーションがうまくいかず確認は難航した。
状況が芳しくないため、仕方なく設計者は現地に飛んだ。そして待ち構えていたエンジニアがこのコンポーネントは何だと直接設計者に問い詰めた。
なんと正体はコンポーネントではなくオペレータ（ユーザ）のことだった。
こういう悲喜劇がいとも簡単に起こるのがこの開発形態の特色だ。
「何かを伝える」ということを再認識する
このようなトラブルは設計手法やツールによって大きく緩和される可能性はある。しかし最も重要なのは何のためにコミュニケーションをするかということをもう一度確認することだ。開発プロジェクトで成果物として作成されるものは対象の多寡に関わらず読まれることを想定する限り、全て人に「何かを伝える」という目的を持っている。残念なことにそれがうまく伝わらないという事自体、当事者のどちらか一方が責任を負うものではないと認識し、常にどうすればコミュニケーションをより円滑にするかを工夫する姿勢がまず必要だ。設計手法やツールといった具体化の手段を考えるのはその後だろう。
