３．失敗に学ぶ
全体を俯瞰する
何があるるのかわからないまま暗い道を進むようなオフショア開発プロジェクト。道は明るくしていきたいところだが、さて、どうしたら．．．？
アノマロカリスの謎
太古カンブリア紀の昔、この時代では最大の生物となるアノマロカリスは皆さんご存知だろう。アノマロカリスは同時代の生物のどれと比較しても巨大で奇妙な形だが、実は長い間その存在は確認されていなかった。この生物が確認されて現在みられる形になるまでには頭のイカのような部分と後ろのエビの尻尾のような部分は別々の生物と考えられていた時期もあった。
頭と尾の化石が別々に出てくるからである。あるいはあまりに形状が違うので一緒の生物とは考えられなかった。生物が他の生物を捕食中に死に化石になったのだろうと推測されたりもした。
なぜ長年本当の姿に行き着かなかったか。
カンブリア紀が終わって長い年月のあとにこの世に登場した我々はこの生き物の本当の姿を誰も確認することができなかったからだ。
まさかあの２つの化石が同じ生物の体の部分だったなんて。。。と分かってしまえば受け入れ易いことでも知らないうちはまったく考えも及ばなかったということになる。
この話は数人の盲人が象を触りそれぞれの感じたまま象とはどんな動物かを語る故事とも通ずるものがある。
このように、全体を俯瞰することの意味は実に大きい。
ソフトウェア開発での、より規模が大きくなればなるほど、全体の様子は把握しにくくなる。
作業を細分化していくと下流工程ではそれぞれの受け持つコードがいったいソフトウェアの中でどういう位置付けなのか各々はわかっていないという状況になる。この状況の起きる傾向はプロジェクトの規模とほぼ比例するといっていい。
それでもなんとかソフトウェアとして論理的に統合できるのは、やはり全体を見る立場の人間がいて、その知見がプロジェクト内に存在しているからであろう。
全体を見通す知見がなければたちまち論理的整合がとれなくなり、いわば目標を失った航海のようになるであろう。
インタフェースはどこに？
オフショア開発でいくつかの案件をみていて、この形態での開発のある弱点があることがわかった。すでにシステムの中に既成のサブシステムなどが組み込まれており、この中が完全なるブラックボックスになっている場合などがある。たとえば特定のメーカーのハードウェアなどを使用するときに、そのハードウェアのドライバーおよび関連ツールなどと共にサブシステムが構築されている場合がある。また、古くから使われているコンポーネントであればすでに導入時のことを知る人間もおらず、情報が不十分であることが多い。基本的なインターフェースの情報があれば御の字なんていうこともｌ少なくないのが実情だ。
オフショア開発企業は自分たちがタッチする直接のコンポーネントについては比較的詳細を確認するが、上記のような閉ざされたサブシステムに関しては「これが何をするものかわからない。我々はどうしていいのかわからない。」といった思いのほか強い拒否反応がある。ビジネスの上での「そこを何とか．．．」の通じる世界とそうでない世界の違いなのかもしれない。この拒否反応があまりに強くて、工程自体がストップしたりすることもあるし、テストのためといって多大な工数をかけてでも当該のサブシステムの代用品を自分たちで作ることも辞さない勢いである。
まさに上記のような性格のプロジェクトをオフショア開発で委託して、やり取りに苦心していたプロジェクトを知っている。従来からあるシステムの機能追加であり比較的小規模のエンハンス案件であったが、そこに当初の開発でのみ関わったベンダが作成したサブシステムが存在し、このサブシステムが実にデータの入出力に介在していたのだ。「そういうものだから」とずっと面倒をみてきたが、いざ開発をしようとすると資料もなく当初の担当者もいない。その重要なサブシステムの仕様がよくわからない。それでも、そのサブシステムの中を改造するわけじゃないし．．．とそのままオフショア開発に踏み切った。実際中はさわらなくてもデータの内容は重要で、オフショア開発会社側は何度も情報の公開を依頼したが、「ないものは出せない」とずっと依頼を拒否するしかなかった。結局そういった状況がネックになってQ&Aなどのやり取りに相当時間とパワーを使っていた。これは設計上重要な位置を占めるガシーなサブシステムの情報を開示できずにいたためのコミュニケーションの負荷であり、実装工程から結合試験工程でのバグ潰しにいたるまで大きく影響してしまった。
担当者は「オフショアなんかしなけりゃよかった．．．。」と嘆息したが、その原因はオフショア開発にあるのではないことは明白だろう。
情報は受け取る側の身になって
誰しも不可解なものを使って仕事をするのに結果だけは保証しろといった話には腰がひけるのは仕方ないところかもしれない。ここは作業を請け負っている立場になって考える必要がある。オフショア開発の担当者にもいろんな人がいるので一概にはいえないが、「とにかく黙って言った通りやればいいんだ」という態度でいくと大概うまくいかない。自分がその仕事に携わる側の立場になったつもりで考えてみよう。おそらく情報が少ない、情報が曖昧など様々な問題がみえてくるはずだ。自分の発信している情報がどれだけの精度を持っているかを第三者にチェックしてもらうのもよい。
もし使い古しのサブシステムであろうが何だろうが、システムのコンポーネントである以上、機能やインターフェースは明確なものを提示し、ブラックボックスはブラックボックスなりに全体を把握する妨げにならないだけの情報はそろえる必要がある。情報がなければシステムの概要図に大きな穴があいているのも同然だ。これではうまくいくものもうまくいかなくなることを認識しよう。
全体像を共有する
プロジェクトの全体あるいは規模によってはキーメンバーだけでもいいが、関係者に全体の完成イメージを見せてどう「パズル」が組み合わされるのか認識をまず共有するべきだ。もちろんその場でいろいろ議論してもいい。自分自身が疑問を持っていなくても議論の場にいたという経験は後々知見に大きく貢献する。オフショア開発の場でも、というよりそういう場であるからこそ最終的なターゲットのイメージは共有することに大いに意義がある。アノマロカリスの部分部分をみて「どういう生物だ」とか語るよりはずっと状況は改善している。
全体図を見せようにも、場合によっては完成形が見えないプロジェクトというのも世の中にはあるかもしれない。いかに完成形が定義されていなくとも、目標のないプロジェクトは存在しない。そういう場合も目標と目標に向かうプロセスを共有することで十分なコミュニケーション効果が得られる。
いささか偏った考え方になるが、理論だけで語ると、きちんとした構造化ができていれば全体が見えなくてもきちっと完成物になるはずである。それぞれのコンポーネントを受け持ったベンダがバラバラに仕事をしても問題ないはずだ。しかし現実はどうだろう。それはまさに夢のような話だ。そう理論どおりにならないところが不完全な人間の仕事だし、そもそも完成物に仕立てるための労力がエンジニアの仕事であるといっても過言ではない。
