ピラミッド型開発からチェーン型開発へ（１） ?そのチェーン型って何？

前回は告知のための第0回であったが、今回から本題に入っていく。連載第1回では、ピラミッド型開発と対比しながらチェーン型開発のコンセプトの骨格を示す。

なお、前回、連載のペースを記述するのを忘れていたが、ほぼ1週間に1回の頻度で公開していくつもりである。

※連載タイトルについて、前回のものに対して修正を加えている。前回は「ピラミッド型SIからチェーン型SIへ」としていたが、「SI」を「開発」に置き換えた。これに伴う修正を、前回のタイトルと本文にも遡って実施済である。なお、この但し書きは、次回分の公開時には削除する予定である。

対象とするシステム開発

少々言い訳がましいが、システム開発をどう進めるべきかという議論はなかなか難しい。システム開発の範囲が急速に広がり、使用される技術も多様化してきたためだ。適用分野の違い、技術の違い、規模の違いがあり、それぞれが時代と共に変化してきたことに加え、システム開発への関わり方の違いによって、人それぞれに見てきたものが異なっている。そのために議論の土台を合わせるのがとても難しい。

この連載で主として扱う開発の範囲は、企業、自治体、公共団体などにおいて、業務を支援する基幹システムのソフトウェア開発である。これでもまだ広いが、絞り過ぎると議論に一般性がなくなるので、まずはここまでとし、必要に応じて補足を行っていく。

ピラミッド型モデル

ここで改めてピラミッド型開発のモデルについて説明する。このモデルは、システム開発全体に責任を持つ一次請け企業を頂点とし、二次請け、三次請け、(場合によってはもっと)からなる多重請負構造のピラミッドを形成して開発を行うものである。役割分担はケースバイケースだが、大まかにはプロジェクトの全体管理・要件定義・基本設計などいわゆる上流工程を階層上位の企業が行い、詳細設計・コーディング・テストなど開発の実作業を階層下位の企業が担うものである。

このモデルは、商流と開発全体の責任を一次請け企業に集約できるなどの発注側にとっての利点があり、国内においては、ある程度の規模以上の開発で広く採用されているが、問題があることも指摘されている。

指摘される問題には色々なものがあるが、中でも重大なのは、開発体制の規模が大きくなるとシステムの利用者と開発の実作業者が遠く離れ、一次請け企業が状況共有のボトルネックになりやすいということである。そうなってしまうと、利用者からは作業の実状が把握できず、開発の実作業者からは利用者の要望を十分に理解できない、という状態で開発を進めることになる。その結果、プロジェクトの遅延や迷走、あるいは要件漏れや性能未達といった問題が起こりやすくなるのである。

チェーン型モデル

この連載で提唱するチェーン型開発のモデルは、ユーザ企業側と開発の実作業者を近づけ、より直接的に状況の共有を可能にするものである。形態としては様々なものを取りうるが、ピラミッド型と対比して理解しやすいのは、大規模なシステム開発を機能ごとに分割し、複数の開発会社によって進める形態だ。

チェーン型モデルを特徴づけるもっとも重要な要素は、この連載で「標準開発フレームワーク」と呼んでいるものである。これはピラミッド型の開発であれば、一次請け企業が定めていた、システム開発の進め方や、構築するシステム全体のアーキテクチャについて定めたものである。

こうした標準をユーザ企業が持ち、開発企業に遵守してもらうことで、複数企業が並列して開発を行った場合であっても、プロジェクト全体の進捗を的確に把握でき、また、統一的なシステムを構築することが可能になる。

チェーン型モデルの特徴は、ユーザ側が定める標準を軸にして、複数の開発企業が連なることができるというところにあり、それが「チェーン」と名付けた由来でもある。

今後の内容

ここまでの説明で、おそらく多くの方が様々な疑問に持たれたことと思う。次回以降ではそうした疑問について答えながら、チェーン型開発のコンセプトについて、ときにはより詳細に、ときにはより俯瞰的に議論を深めていく。

弊社(ピースミール・テクノロジー)の活動についてご存じの方は、チェーン型開発のモデルが弊社の「包括フレームワーク(AGUA)」を用いた利用者主導の開発を別の見方で表現したものだと思われたかもしれない。その指摘は半分正しい。弊社が行ってきた開発支援の活動は、確かにチェーン型開発を実現するための手法ではあるが、取りうる形態のひとつにすぎない。この連載は弊社の活動を包含しつつ、より広く一般性のあるコンセプトとして可能性を探索する試みである。