ベトナムの現地案件が頓挫。。

某月某日

ベトナム現地のクライアントから受注して始めたプロジェクトがとにかくうまく行っていないのであった。
計画よりも遥かに多くの人員を割いて毎月のマイルストーンを達成しようとしているので、詳細を聞いていくと、どうやら最初の見積よりも2倍以上工数がかかってしまうことがわかった。

え〜、なんでそんなことになるの？？？

と思ったが、私にも責任はある。
現地クライアントはベトナム語しかできないので、現地に全部任していたのだがそれがいけなかった。

ソフトウェア開発プロジェクトで正確な見積もりをすることは非常に難しく、独立してから15年もこの仕事をしている私でも見積もりを誤ることはある。それでも見積もりよりも実際の工数が2倍以上になるということはなかった。

今回は作るもの自体が非常に大きく1年の長期プロジェクトだったので、それが2倍以上になるとインパクトが大きすぎた。

1つのiPhoneアプリ、とかであれば2倍になってもなんとか終わらせることができるが、フロントエンド、バックエンド、インフラストラクチャすべてを一から開発する大きなシステムが2倍となると、こちらが費用を持ち出して穴埋めすることは非常に難しくなる。

僕は学部生のときにソフトウェア工学の研究室に属していた。ソフトウェア工学とはソフトウェアを開発する方法（プログラミングなど）を勉強する学問ではなく、ソフトウェア開発をもう一段メタレベルで捉えて、要件定義や工数の見積もり、品質などの管理手法を勉強、研究する学問分野である。

僕の選んだ研究室の教授は学科のなかで唯一、博士も修士も持っていない教授で、現場からの叩き上げだった。叩き上げといっても当時日本のコンピュータエンジニアの最高峰が集まっていたNECでいくつもの巨大プロジェクトを経験してきたので誰もが持っていない経験値、知恵を持っていたと思う。

とはいえ、僕は当時ソフトウェア工学に興味が持てず、プログラミングなどの”作る技術”の方を学びたいと思っていたので、先生の言うことをあまり聞いておらず覚えていることはあまり多くない。

ただ、教授が言っていたことで頭にずっと残っている唯一の言葉が、

「ソフトウェア開発プロジェクトがデスマーチになったときには機能を極限まで削るしかそこから抜け出す方法はない。」

というものであった。

これは追加で人員や予算を投入したり、スケジュールを後ろ倒しにしても抜け出せないという意味でもあり、教授もそのことをこの言葉の後に説明していた。

まさに今がこの教授が言っていた状況である。

僕はこの教えが頭にあったので、デスマーチになりそうなプロジェクトに出会ったときは始まる前に極力仕様を削ったり、シンプルにしたり、分割して別のプロジェクトやフェーズにしたりするようにクライアントと時間をとって話をしてきた。それができない場合、プロジェクトが小さいものであればリスクをとることができるのでやることもあったが、大きいものであればプロジェクトを受けることをお断りしたり、プロトタイプフェーズだけを担当して後は抜けることもあった。
幸いクライアントに恵まれてきたこともあってこれまでデスマーチの状態で開発を続けたことはない。

デスマーチになってしまうと、我々作り手が損をするだけではなく、クライアントにも結果的には損をさせてしまうことになる。
たとえばこの件のように見積もりよりも2倍の規模のシステムだった場合、実際の予算の2分の1以下の予算でシステムを開発してもらえるのだからクライアントにとってはお得に思えるかもしれないが、計画の2倍のものをつくるということは、スケジュールが遅れたり、品質が低下したり、その後のメンテナンス性や拡張性に難がでることもある。またクライアント側の要件定義や成果物の確認の作業も考えていたよりも2倍以上になるということであり、どちらにとっても得にならないケースのほうが多いのである。

僕がソフトウェア工学研究室を選んでよかった唯一の点はこのことを22歳の時点で、何十年もNECで経験を積んだ先生に教えてもらえたことであった。
（もちろんもっと真面目に勉強していたら他にも良いものがたくさん吸収できていたことは言うまでもない。。）

ベトナムチームには、
- クライアントに現状の問題を包み隠さず伝えること
- 仕様を削れる箇所がないかクライアントととことん話し合うこと

を伝えた。もちろん上記のソフトウェア工学のセオリーも伝えた。

そこから1週間が経った。

どうも状況は改善していないようである。
仕様を削れないかどうかは常に話をしているが、これ以上削れるものはない、
という説明が来た。

仕様を削るのは意外にも創造的な作業である。創造力を働かせると思わぬ代案が見つかることがあり、実装コストが一気に何分の1になることもあるのだが、それにはクライアントの助けも必要である。
開発側が気づいていない、あるいは絶対必要と思い込んでいるものの中に、「これでも実は良い」という別の案があったりするのだが、それはクライアント側からアイデアがでてくることもあるのである。
クライアントと信頼関係が築けていて、クライアントの創造力を借りることができればこういう解決策に辿り着くこともできる。

だが、どうやら事情はそう行っていないようであった。

次に僕は、

仕様を削ることは継続して議論しながら、開発費を上げてもらうように交渉してくれ。

とお願いした。

しばらくして、開発費を2倍にして、開発期間を2倍にしたらどうかと提案したと報告があった。

開発期間を2倍にするというのは悪手である。先の教授が、人員、予算、期間を増やしても抜け出せないと言っていたことに当てはまる。

開発期間はそのままのほうがいい、と助言したが、エンジニアが疲れているから開発期間も2倍あったほうがよいという説明が来た。

これは嫌な予感がするなと思ってしばらく待っていると、クライアントから開発期間は2倍にしても良いが予算はそのままにしてほしいという要望がきた、と報告があった。

展開としては更に悪くなってきた。2年間もデスマーチを続けたら会社は潰れてしまう。

私はここで決断した。

このプロジェクトをキャンセルしてもらうように先方と交渉してほしい。

と依頼した。
まだプロジェクトが始まって2ヶ月半、キャンセルするならば早いほうが双方にダメージがなくていい。これが半年後だったり、1年近く経っているともう後戻りができなくなってしまう。

キャンセルの仕方も創造力を働かせればいろいろとある。
複数のオプションをこちらで作って、それを持って交渉を始めてもらうようにお願いした。

私がすべてのプロジェクトの見積もりをしている日本のプロジェクトではこういうケースに至ることはないのだが、今回オールベトナム語で行われるやり取りに自分が入ってスピードを落としたくない、彼らの自主性を尊重したい、と思って関与しなかったことが結果的にこのような状況を作ってしまい、大反省である。

コミッション男の顔がふと浮かんだ。彼にも迷惑をかけるなぁ。

続く。。

次回は↓↓↓