プロジェクトがもうすぐ終わる前の振り返り

今日は、今回経験したプロジェクトの成果を徒然と書いてみようと思う。

 

2011年11月からこのプロジェクトが始まった。

私にとっては、前回のプロジェクトと同じお客さまでこのお客様とは２回プロジェクトを経験している。このお客様のプロジェクトは、大概、予算・品質の面で問題を起こし、社内でも悪い意味で有名なプロジェクトとなっている。いわゆる「デスマーチ」に属するプロジェクトだ。

 

今回も要件定義工程から一括請負で契約した非常に厳しいプロジェクトとなっている。

このような厳しい契約で受注しなければならないのは、自社の強み、営業力がなく、社員を維持するために受託開発で食いつないでいるからだ。（多くの同業者もこのような状態だと思われる。）

 

SI業界の構造的な課題は置いといて、与えられた予算、納期でお客さまの要求に応えられるシステムを構築しなければならない。

プロジェクトの規模は、約50人月。自分以外は、協力会社から人を集めないといけない。

最近は、少し景気が上向いてきたからか、プロジェクトメンバーを首都圏で集めることができずに、地方にある会社に詳細設計工程以降一括発注することになった。（直前まで猛反対したが、コストダウンしたいという上層部の考えを変えることができず、泣く泣く受諾した。）

 

メンバーが入った後に最も気をつけないといけないところは、自分がボトルネックにならないこと。これだけだ。

しかし、詳細設計工程以降一括発注したことで、自分がボトルネックになってしまった。

お客さまと調整したことを、資料にまとめてメールで送り、電話する。実際の詳細設計は自分でやっていたようなものだ。

今回のプロジェクトでは、一括発注する部分と自社で開発する部分があった。

自社で開発する部分は、基本設計から機能単体の試験まですべて１人の担当者に任せた。

お客さまからの細かい要求の変更が頻発するため、１機能１担当者とした方が工数が最小となり、品質もよくなるからだ。

 

一方、詳細設計工程から外注したところは、お客さまとの調整結果を外注会社に伝える工数が非常にかかった。外注会社の担当がお客さまの業務を知らなかった（また知ろうとしなかった）ため、お客さまの要望を詳細設計レベルにまで落とし込んで外注会社の担当に伝える必要があったからだ。

実際、外注会社に発注した機能の品質は自社で開発した機能と比較して、非常に悪く、自社で故障を修正するという事態になっている。外注会社のエンジニアのプログラミングスキル自体には問題ない。問題なのは、お客さま、およびお客さまの業務を理解しようという姿勢が足りず、それが無駄なコード、意図しないコードを作ってしまっている。作業の手戻りなんて軽いものではない。技術的な負債だ。

 

スピードとシステムリリース後の持続性が求められる今のシステム開発に、工程分業制の開発スタイルはふさわしくない。プログラムは工業製品と違って大量生産するものではない。ベルトコンベア型の大量生産のように工程ごとに分業すると工程間のコミュニケーションコストがかかり、伝達ミスによって品質が低下する。工程分業制によってシステム開発のコストが約２倍に跳ね上がっていることが自分の作業実績を記録することで分かった。

 

これからは、お客さま単位で、要件から運用まで一貫してシステムサービスを提供することのできるエンジニアの組織体制を組める会社が成長するだろうと思う。