受託開発プロセスはプロジェクトリーダーの手腕に100%依存している

「受託開発の極意」を読んだ感想を書いてみる。
＃思いついたまま書くので、論理的整合性は後回し。

【1】受託開発プロセスはプロジェクトリーダーの手腕に100%依存している

SIerの受託開発プロセスは、プロジェクトリーダーに大きく依存していると思う。
プロジェクトリーダーごとに独自のプロジェクト管理技術を持っているのが実情だろう。

僕も過去に色んなプロジェクトリーダーを見てきた。
顧客調整が得意な人、進捗や運用の管理が上手な人、チームビルディングに力点を置いてメンバーをその気にさせるのが上手な人など。

「受託開発の極意」を読むと、顧客調整や要件定義プロセス、進捗管理、チームビルディングに彼独自の手法を編み出しているのが良く分かる。

それはそれでよいのだが、開発プロセスがプロジェクトリーダーに依存しすぎていたら、CMMのレベル3の段階ではないと思う。
つまり、組織として、標準化されたプロセスを持っているわけではない。
学習する組織まで成熟していないように思う。

本を出版しているから、そのノウハウは社内で公開され共有されているだろうが、普通のSIerでは、なかなかそこまでできないのが実情だろう。

【2】設計で品質を作りこむ

「受託開発の極意」を読むと、設計で品質を作りこむという思想が根底にあるように思える。

サービスは見積もりから始まっている。
だからこそ、工数見積に細心の注意を払う。

丸投げされた時は責任の所在を明確にしてから受ける。
丸投げドキュメントは、一覧を作って整合性を図り、シナリオを書きながら検証していく。
要件定義でも進捗を示して、前進していることをお客様にも見せ付けておく。

高レベル設計はドキュメント重視、低レベル設計はテスト駆動。
これは非常に役立つノウハウだと思う。

ソースコードに近い設計は、ユニットテストを書きながらプログラミングしていけばいい。
ユニットテストで大事なのは網羅性。
カバレッジが100%でないと、漏れたロジックからバグが出る。

でも、複数の機能を組み合わせて初めてシステムが出来上がるのに、機能の結合部分の調整でいつも労力がかかる時が多い。
その時は、プログラミングレベルではなく、システム全体を鳥瞰して、一連の業務フローというシナリオで理解する。
そうすれば、特に異常系の業務フローから派生するバグを発見できる。
このレベルは、ユースケース駆動と言っていいだろう。

ユースケース駆動で重要な成果物はドメインモデルだ。
つまり、お客様の業務の用語集がドメインモデルに相当する。
ドキュメントとは、業務の用語集であるべきなのだ。

特に運用保守では、保守されたドキュメントが威力を発揮する。
本番稼動後に、お客様から仕様を質問された時、的確に素早く返答せねばならない時が多い。
その時に手元に役立つドキュメントがあるかどうかの違いはすごく大きい。

業務フローからプログラムまできちんとトレースするためのミッシングリングの一つがドメインモデル。
つまり、仕様をプログラムにあるオブジェクトへ翻訳する。

【3】プロジェクトリーダーの本質的な役割は、人と組織を変化させること

「受託開発の極意」では、プロジェクトリーダーの大きな役割の一つに変化があると主張している。

プロジェクトリーダーの評価は、プロジェクトが納期通りに完了して黒字になることだけではない。
お客様と信頼関係を築いて、リピートオーダーがもらえることも含まれている。
更に、チームメンバーがプロジェクトを経験して成長していることも含まれている。

つまり、プロジェクトリーダーが関わる人達が、プロジェクト開始前と終了後に変化していなければ、成功したと評価されないのだ。

「受託開発の極意」では、自分を変えること、周囲の仲間を増やして組織を変えることのテクニックが書かれている。
普通のプロジェクトリーダーは、請け負ったプロジェクトのメンバーだけしか影響させられない。

でも、大規模プロジェクトでは、メンバーだけでなく、複数のチームを影響させねばならない。
だから、普通は、サブリーダーを通じて複数のチームをコントロールするようになる。
その時に、右腕となるサブリーダーとの信頼関係構築が最も重要になる。

受託開発はパッケージ製品開発と違って、デスマーチになりやすい傾向がある。
しかし、日本の大手SIerのパッケージ製品は、メインフレーム＋Cobolで動く金融システムとか、ビジネスユース向けのWidows上で動くVBプログラムとか、技術がすごく古い。
最近になってようやく、Web2.0の技術を基盤としたビジネスが出ているけれど、それはまだごく少数。

受託Webシステム開発ならば、その時代のオープンソースのライブラリやサーバー環境を上手に使いこなせば、常に最新の技術を追いかけながら仕事できる。

受託開発のボトルネックであるプロジェクト管理さえ上手に制御できれば、受託開発はもっと面白い仕事になると思っている。