成功を導くために
失敗談をまとめてからあと、長らく中断してしまった。それも非常に長く。
この間仕事が忙しくなったというのは表向きの話で、その「どうやったらうまくいくか」というテーマの重さによって行き詰まったというのが実際のところだ。
そもそもソフトウェアプロジェクトに、こうやったらうまくいく、なんて話はあり得ない。
ここからは体験談という範囲を超えるけれど、一般的な開発手法的な話なら他にいくらでも情報はある。どう手を出すかを迷ってしまうところだが、この執筆で何に対して責任を持つというわけでもないし、逆に自分の思うように展開すればいいんじゃないかという開き直りのような心境になった。
．．．まあ、それしかできないのだけど。
そういうわけで、持論をまとめつつというアプローチで進めてみようと思う。
不連続ドラマ：とあるオフショアプロジェクト
長年開発に携わっていたシステム開発部があるが、フレームワークにあたる部分から自作ですべて賄っていた時代は過ぎ去りオープンソース開発が一般的になっている。それに伴い、メンテナンスをする対象の規模が小さくなり開発チームの規模をも縮小している。
しかし、旧来の業務支援システムをWebのシステムに乗せ替えて１０年。近年システムの負荷が増大し、しばしばトランザクション集中時にパフォーマンスが激しく落ちる事態になってきているので、システムのパフォーマンスをアップさせ、処理ノードは負荷分散し将来的にもスケーラビリティを確保できるような仕組みに移行する変更が必要になった。
ここでシステム開発部15年目のベテランY君が検討を開始することに相成ったが、そもそもこの10年を数人の人員でシステムのメンテナンスだけ行ってきた。検討を始める以前にどうやっても対応人員が足りないのは明白だ。これからそこそこの規模の開発人員を社内で調達するほどリソースの余裕もない。そこでY君は今回の開発をオフショア開発にすることを盛り込んだ計画書を作成した。計画書には、まとまった人員の確保、コスト上のメリット、システムの性質上開発の拠点は特に問わないことなどを強調した。オフショア先はインフラも整いつつありカントリーリスクも少ないヴェトナムを一推しとした。
この計画書を見た上司はY君の説明をほとんど聞かずに「これでは上を納得させられない。うまくいけばの話ばかりが書いてあるように見えるな。困難な状況になったときのヘッジについて考慮してるならその点もちゃんとアピールしないと。」と言った。もっともな意見だと思いながらも、Y君は考え込んでしまった。品質、費用対効果、保守性．．．考慮することはいくつもありそうだ。
Y君はさっそく対策を検討することにした。さて、Y君はどのようにして上司を説得できるのだろう。
オフショア開発が失敗してもなんとかリカバリする対策なんて沢山そうあるものではない。効果のほどは状況により様々だがとりあえず挙げてみよう。
１．開発先のエンジニアを設計に参加させる
オフショアでは設計内容のスムーズな理解が最も効果がある。その意味でこれはいい作戦だ。多くの設計工程のトラフィックなしにイテレーティブな開発に移行できる。問題はファーストコンタクトではどこの誰かわからない人材を設計に参加させる形になるので、事実上は不可能だということ。つまり実績が認められているベンダとの間にのみ有効ということだ。また、設計に参加した人材がいつまでもその会社に居続ける保証は低い。離職した場合にはすべて無に帰するリスクもある。
２．複数のフェーズに分けて開発する
全体をいくつかのフェーズに分けて設計・開発することにより、危険信号が点ったらその時点でプロジェクトを巻きとれるようにしておく。開発コストの点での痛手が解消されるように思えるが、冒頭で失敗した出来損ないを捨てるにしてもまともなモノにするにしても多くのヒトと金がまず間違いなくかかる。したがって、これは実効性のない対策の典型といってもよい。
３．複数の開発先に負荷分散する
すべてを一社に発注すると成功するか失敗するかはAll or Nothingである。だから複数のベンダに分けて開発を委託する。分割するポイントが重要で、これを誤るとインターフェースで矛盾が起きたときの収拾に一苦労が待っている。また、分割でなくまったく同じものの開発を複数のベンダに冗長的に委託するという荒技もある。この場合、コストがデメリットとなるだろう。
４．請負でなく構築支援として業務委託する
システム構築そのものを要件とせず、構築支援のような形での業務委託にすることで、要件の変更、工程の変更に柔軟に対応できるようにしておく。仕様が半端な状態での見切り発車には効果的かもしれない。ただ、一応のマイルストーンを決めて走り出さなければ無計画なプロジェクトになる恐れがある。プロジェクトを管理する側も相手側もその状況をよく理解して動くだけのナレッジが必要ということもあり、最もハードルが高い方法といえる。
これらの事をよく考慮して、プロジェクトの性質・目的にあった効果の期待できる方法を選ぶ。決して目に見える目先のコストだけが重要ではないことを理解している有能なマネージャであればよりよい対策を導き出す助け舟を出してくれるだろう。
Y君は開発先とは4.の業務委託の形にすることを計画書に盛り込み、オプションとして1.開発先の設計参加についても「可能であれば」との但し書きで追記した。また、発注先のベンダの情報については、数年前からオフショア開発を手がけている学生時代の同業の友人にアドバイスをもらっておいた。これを参考という形で記載しておいた。
件の計画書を清書し提出してから数日後、Y君は上司から呼び出しを受けた。行ってみると、そこには開発部長が同席している。
「忙しいとこすまない。例のプロジェクトの計画書の件で訊きたいことがあるのでね。」
Y君は「いよいよ来た！」と思った。
...
そして30分後、自席に戻るY君の心の中にはある葛藤が生じていた。
（続くかも）
ここで重要なことはシンプルだ。
何事もメリットだけではない。デメリットの部分もよく照らしてみてから実行しようということだ。
そうすると、予想外の展開は予想外でなくなる可能性が高くなる。
