ピラミッド型開発からチェーン型開発へ(3) ?ユーザ企業による全体統制なんて現実的なの?

P2C_highway

第3回はすぐに公開するはずだったのに、3ヶ月も間が空いてしまった。公開のための文章を書くのは、私には結構なエネルギーが必要で、どうもブログのような自律的なスケジュール管理を要するタイプのものは継続が難しくなってしまうようだ。この歳になって、自分の特性がまだわかっていないとは、情けない話である。

さて、第2回からこれまでの間、チェーン型開発に関連して色々な出来事があった。弊社の札幌市の新拠点が立ち上げ(プレスリリース参照)、ビジネスイニシアティブ2015のセミナーでの講演があった。そして、この後、10月には学会発表プライベートセミナーでも展開していく予定である。さすがにその前には、入り口となる基本的な概念は提示しなければならない、ということで、遅ればせながら第3回を公開する次第である。

チェーン型開発の役割モデル

前回までで、チェーン型開発の考え方を示すとともに、その実現のための役割分担のモデルを示してきた。チェーン型開発とは、発注側にシステム開発に必要な標準「標準開発フレームワーク」を用意することによって、開発標準に従う複数の受注企業を統制しながら全体の開発を進めるシステム開発のモデルである。

前回は、標準開発フレームワークを使った全体統制を誰が行うのかについて議論を進めてきた。結論として、大きく、発注側PMによる全体統制をとるタイプ?と、受注側が全体統制をするタイプ?があることを示した。

タイプ?は、利用者の主体性を発揮できるという観点からは望ましいが、全体統制に必要なプロジェクト管理スキルや全体アーキテクチャを扱うスキルを充足させるという観点で課題がある。一方、タイプ?については、スキル充足の観点では課題をクリアしやすいが、ユーザ側の標準を使って統制を行ってくれる企業を見つけるというところに難しさがある。

今回は、こうした課題解決することでより現実的なものにするバリエーションを示す。

type?A?B

[タイプ?A] フレームワークプロバイダーが統括PMを支援する

システムの開発は、関係者が増えると複雑さが増大し、その管理をするのが困難になる。ユーザ企業側に不足しがちなのは、大規模システム開発を担うことのできるプロジェクト管理スキルである。

これに対し、発注者でも受注企業でもない第三者的な組織によってプロジェクト管理を支援するのが現実的な選択肢となる。この1つがフレームワークプロバイダーによる支援である。

チェーン型開発を実施する上で、そもそもこれまで開発を主体的に行ってきていない発注側のユーザ企業に実践的な開発標準を定められるのかという疑問がある。標準開発フレームワークを導入し、発注企業内の事情に合わせ、また、受注側の企業に合わせて導入する、第三者的な役割を導入する。この役割のことを、ここでは「フレームワークプロバイダー」と呼ぶことにする。

フレームワークプロバイダーは、フレームワークについて熟知しているため、それを活用した発注者側のPMによる統制を支援することができる。

[タイプ?B] PMコンサルタントが統括PMを支援する

ユーザ側の統括PMのプロジェクト管理を支援する役割は、標準開発フレームワークを提供する役割と同一である必要はない。むしろ、より一般的なビジネスモデルとしては、この2つの役割を分離し、統括PMを支援するコンサルタント「PMコンサルタント」を想定するほうがよい。

ただし、このモデルの場合は、PMコンサルタントが標準開発フレームワークの適用方法について、十分な理解をし、使いこなせる必要がある。その意味で、標準開発フレームワークの導入初期には、フレームワークプロバイダーに頼るタイプ?Aを採用し、タイプ?Bに移行していく進め方が考えられる。

前回、説明しようとしていたバリエーションは以上の2つであるが、その後の議論で他にも言及するべきバリエーションがあることがわかってきたので、追加で記載することにする。

type?C?A

[タイプ?C] FWプロバイダーが最初の開発を実施する

タイプ?Cはフレームワークプロバイダーが、最初の開発を行うモデルである。チェーン型開発を行う際に最も難しいのが最初の開発である。最初はユーザ企業側の統括PMも実践経験がないので、適切な指示ができない。開発企業もはじめての場合、ユーザ側標準に従って本当に手戻りなくできるのか確証が持てない。

フレームワークプロバイダーが、最初の開発を実施することで、開発が問題なく進められることを実証するとともに、個々のユーザ企業の導入で必要になる改良などを行うことで、後続の開発をスムーズに連鎖させることを可能にする。

[タイプ?A] システム子会社が開発全体を統括する

さらに、タイプ?の現実解として、システム子会社を活用するというパターンを示しておく。

ユーザ企業が大企業である場合には、システム開発をシステム子会社に委託している場合がある。システム子会社の役割はケースバイケースだが、ユーザ企業に代わって、システム全体の統制を自社の持つ標準に従って、自ら複数の企業を統制している会社もある。この場合、システム子会社自身がFWプロバイダーを兼ねたチェーン型開発であると言える。

システム子会社がチェーン型開発を実施しているケースは、現状では必ずしも一般的なケースとは言えない。運用を主に行い、開発自体は大手開発会社に丸投げしているケースも多い。ユーザ企業の要求に素早く応えられるようになるために、今後、統制に使う自社標準を定めて、チェーン型開発に移行していくこと必要があるのではないだろうか。


以上、チェーン型開発における役割のモデルを説明したが、複合した形態などが様々に考えられる。チェーン型開発に関連しては、興味深い議論がまだまだあるが、連載間隔が等比数列的に増えて、自然終了してしまうパターンに陥りつつあるので、チェーン型開発の導入部分のプチ連載は一旦、今回で完結させることにする。

この先は、ここまでで整理した概念を前提にして、断続的に、かつ読み切り型で議論を展開していく予定である。