随分間が開いてしまったが、チェーン型開発の連載第2回を公開する。この間、日経ITProにも大規模システム開発に適用可能な、オルタナティブSIのひとつとして位置づけて、取り上げていただいた。 http://itpro.nikkeibp.co.jp/atcl/column/14/346926/060500271/ 大変光栄なことだと思っている。この記事にも力をいただきながら、引き続きチェーン型開発について深堀りしていく。
前回はチェーン型開発のモデルがどのようなものかについて大枠を説明した。説明を読む中で多くの皆さんが様々な疑問を持たれたことと思う。今回から、そうした疑問に答えることを通じてチェーン型開発モデルのコンセプトを明確にしていきたい。
プロジェクト管理を誰が行うのか
最初のテーマは、「誰が開発プロジェクト全体の統制をとるのか」の議論だ。チェーン型開発では、開発標準フレームワークとして、開発の進め方の標準と全体アーキテクチャの標準を定めることで発注側からの統制を可能にすると書いた。しかし、そうした標準があればプロジェクト管理ができるのかというとそれほど甘くはない。
開発に必要な標準が揃っていれば、プロジェクトを素早く立ち上げて、遂行状況を把握するのに必要な準備作業を迷うことなく円滑に進めることができる。しかし、個々のシステム開発プロジェクトの事情を勘案したり、遂行時の問題解決するところまで、標準がカバーできるわけではない。
システム開発は個々それぞれに特有の事情がある。例えば、連携が必要なシステムが違う、利用するインフラが違う、想定利用者のスキルレベルが違う、といった事情だ。また、受注側の開発企業の事情も様々だ。会社ごとに経験の多い技術領域が違うし、プロジェクト管理手法や開発の進め方が違う。さらに、実際の開発体制を構成する要員のスキルと経験は千差万別である。開発全体を統括するプロジェクトマネージャには、こうした違いを踏まえて必要な修正も加えながら標準を適用する力量が必要になる。
さらに、プロジェクト管理において最も大変なのは、遂行時に発生する様々な問題に適宜手を打って解決し続けながら、定められたスケジュールとコストの中でシステム構築を完遂するところである。これは開発規模が大きくなればなるほど、飛躍的に難しくなっていく。ここで必要になる創造的な問題解決能力は個々のプロジェクトマネージャの手腕に頼るところが大きく、標準ではカバーしきれない。
チェーン型開発の構成要素とプロジェクト管理
改めて、チェーン型開発を構成する要件を整理すると次の二つになる。
- 開発標準に従う複数の受注企業がそれぞれ開発実作業を行うこと
- 従う標準は発注側企業のものであること
この要件を満たしていれば、組織体制もその統制方法も異なっていても構わない。可能性はいろいろあるはずだが、私たちの経験から、チェーン型と呼べる開発の取りうる現実的な形態として4種類あることがわかっている。これらは大きく2つの基本的な形態として、発注側によるものと受注側によるものに分かれ、さらにこれのうち発注側を支援するためのバリエーションが2つ加わる。今回はまず、基本の2つのタイプについて説明する。
[タイプ?] 発注側PMによる全体統制
この形態は、発注側のユーザ企業側のプロジェクトマネージャが開発全体を統制するものだ。内製に近いが、設計やコーディングなど技術専門性の高い実作業は受注側の開発企業が行うところに違いがある 。内製化で難しいのは、開発に必要なスタッフを保持し、高い技術スキルと開発経験を蓄積し維持し続けることだが、これが解決される。
しかし、全体プロジェクト管理には、やはり非常に高いスキルが求められることに変わりはない。標準の開発プロセスと標準のアーキテクチャに従ってもらうので、複数の受注企業でプロジェクトが遂行されても全体の統制をするのは可能ではあるが、容易なわけではない。
もちろん、最初は力量が十分でないプロジェクトマネージャであっても、適用を何度も繰り返す中で、プロジェクトの遂行に習熟していく効果は期待できる。長期的なプロジェクトマネージャの育成という観点まで含めれば、現実的な解となり得る。
[タイプ?] 受注側PMによる全体統制
この形態は、多重請負構造を作ることを前提として、一次請け企業のプロジェクトマネージャに標準開発フレームワークに基づく開発全体統制をしてもらうものだ。元々、大規模開発の全体統括をしてきたプロジェクトマネージャが全体プロジェクト管理を行うので、スキルの充足の問題は解決できる。
図で示すように体制は丸投げ開発のピラミッド型開発に似ているが、設計やコーディングなどの実作業が、発注側で定めた標準の開発プロセスと標準のアーキテクチャに従うので、チェーン型の構成要件を満たす。多重請負構造であっても、標準に従って開発してもらうことで、発注側にも状況が共有できるというチェーン型開発の利点を得ることができる。
ただし、発注側の開発の進め方に従ってもらいつつ、開発プロジェクト全体の責務を一次請け企業に負ってもらうというのは、少々虫のいい話ではある。一般的には受け入れられにくいことは指摘しておく。
一次請けの企業はそれぞれで進め方を持っており、品質管理もそれを前提に行っている。発注側が押し付けてくる得体のしれない開発の進め方に従って開発するのはリスクが高いと判断されても不思議はない。この形態を採用する場合は、最初に意義を説明し、発注側標準の不備に由来する問題が発生した時の対応などを最初にしっかり定めておくことが重要になる。
現実解を探る
以上、チェーン型開発を実施するための2形態を説明したが、どちらがより良いかはプロジェクトの規模などにもより、一概には言えない。発注者が主体的に開発に関わるためには、タイプ?がより望ましいとは言えるが、大規模な開発になると最初からそうするのはさすがに無理がある。そこでタイプ1をより現実的に実施できるようにするため、発注側プロジェク管理に第三者的な支援を入れるバリエーションが考えられる。
次回はこれらのバリエーションについて紹介する。今回ほど間を空けずに更新できると考えている。
