前回までの議論で言えば、基本設計では、機能を尺度に設計が行われ、分割されたプログラム群は準モジュラー型アーキテクチャを体現しており、インターフェースに修正が起こらなければ、詳細設計以降の工程ではそれぞれのプログラムを全く独立に設計・製造できる。この結果、基本設計と詳細設計に間に明確な区切りができ、詳細設計以降の個々のプログラムの設計・製造が独立性を帯び、可搬性、移動性を有することになった。このプログラムの設計・製造の可搬性こそが、日本のシステム開発産業において特に顕著な人月方式と多重下請け構造を生む原動力になったと筆者は考えている。そして、今回論議するのは、詳細設計以降の下流工程についての日本のシステム開発の特徴についてである。

万能型SE一貫生産方式という生産方式
日本におけるシステム開発の工程は、一般的に図10-1に示すようなウォーターフォール型工程モデルが採用されている。日本のシステム開発では、多くの場合上流工程として要件定義工程と基本設計工程が含まれ、それ以降を下流工程と呼び、詳細設計工程、製造、そして、テストなどの工程が含まれている。また、今回のテーマである下流工程の始まりである詳細設計で生み出されるプログラムアーキテクチャはすり合わせ型となる。つまり、日本のシステム開発の特徴は、システムアーキテクチャとプログラムアーキテクチャの組合せが、(準モジュラー型、すり合わせ型)という組合せが長らく続いてきたのだ。この組み合わせにより、日本のシステム開発の特徴は、図10-2にその概念図を示す「万能型SE一貫生産方式」と筆者が呼ぶシステム開発方式が長らく定着している。もし仮に、基本設計で毎回新たな構造設計が行われるとすると、基本設計は、極めて難易度の高い、担当者間のすり合わせ作業の多い設計工程になったはずである。筆者は、1970年代前半の銀行におけるオンライン開発で困難な設計作業に従事した。まさに、打合せの連続で、それによりインターフェースを決定し、設計を進めていくのである。もし、すり合わせ型のアーキテクチャがその後も続いたとしたら、こんなに多くの業務にコンピュータが使われることは無かったのではないかと思う。それが、機能的強度を重視した、いわゆる機能分割という設計手法で基本設計を行い、その結果生まれた構造要素が一つの機能に対応するようになる手法が自然に採用されるようになった。それにより、基本設計では構造要素に複数の機能がマッピングされることはなくなり、すり合わせ作業を回避することに成功した。

しかし、詳細設計のプログラム単位の設計ではもはや構造設計を回避することはできない。ここでは、機能と構造要素間のマッピングは多対多にならざるを得ない。もし、詳細設計を複数のSEが分業として行った場合、基本設計で回避したインターフェースの打合せが再現することになる。しかし、現実にはそのような打合せの多発はどこにも起こらなかった。それは、一人のSEに一本のプログラムを全部任せてしまうからである。つまり、構造設計にて複数の要素が当然設計されるが、その間のインターフェースの整合性は、一人のSEの頭の中で容易に取ることができる。これが、筆者が「万能型SE一貫生産方式」と呼ぶ日本で一般的に行われる下流工程におけるシステム開発の生産方式なのである。
“万能型”というSE
まず、前半の部分の“万能型SE”というソフトウェア技術者を明確にする必要があるだろう。「万能」とは「業務も技術もともに知識を有している」という意味である。詳細設計以降のプログラムの設計や製造を任される技術者には、もちろん、開発の対象となる業務に関する知識が必要となる。しかし、それだけでは設計を行うことはできない。それは、担当するプログラムの機能要件を踏まえて、処理モデルとデータモデルの二つを問題なく整合する仕組みを設計することが求められるからである。このような作業を行うには、対象業務を理解するための業務知識とともに、主にデータベースやデータモデル関連の知識を中心にしたソフト技術の知識をバランスよく双方とも習得しているSEが求められたのである。筆者が在籍した都市銀行でも、当初は行員がプログラマを務めたが、ソフト技術の進化が激しくそれらの習得が困難なので、徐々に下流の詳細設計以降をアウトソーシングするようになった。つまり、利用者側の人間にとっては、ソフト技術の進化に遅れないで追随することが困難になったからである。そこで、業務も技術も分かる万能型SEを供給することを目的にソフト会社が続々と誕生したのである。
一貫生産方式は「分業の否定」がポイント
後半部分の「一貫生産方式」とは、詳細設計以降において、プログラム設計や製造の双方あるいは、それぞれの作業を一人の技術者が一貫して担当する体制が取られたということを意味している。つまりこのことは、それらの作業において、分業は行われないということである。それは、既に説明したように、準モジュラー型の採用で、先送りされた構造設計を詳細設計以降のプログラムの設計において行う必要があるが、そこで、もし分業が行われれば、せっかく回避した担当者間の打合せ作業やインターフェースのすり合わせが復活し、プログラム設計の各所において、猛烈な打合せの多発に見舞われるからである。それを回避するには、一本のプログラムを一人の担当者に任せ、担当者本人の中で部品間のインターフェースを整合させてもらうしかない。これが、一貫生産方式の最大の眼目であったのだ。
人月方式の意味するもの
システム開発の要員の動員方式として「人月方式」と呼ばれる工数見積り方式が長らく採用されてきた。開発の仕事量を何人の技術者を何か月動員するかということで示すために、その掛算で工数を表現するのである。例えば、10人の技術者を10か月動員する必要があれば、その仕事量は、10人×10か月=100人月ということになる。この方式が暗黙に前提にしていた1人の技術者とは万能型SEであり、そのような万能型SEの技術者の標準的な力量であれば、仮に一人が詳細設計で1カ月に4本プログラムを設計できるとすると、100本のプログラムの開発に必要な人月は、25人月(=100本÷4本/人月)ということになる。この万能型SE一貫生産方式と筆者が呼ぶ生産方式を採用していることが、人月方式を長年使い続けた本当の要因だったと筆者は考えている。人月方式は、早い段階から色々と批判の対象となったが、今に至るまでその基本に変更は成されていない。それは、日本のシステム開発の根幹が、筆者が「万能型SE一貫生産方式」と呼ぶやり方で今も続けられているからに他ならないからだ。

万能型SE一貫生産方式の合理性の根拠
このように人月方式とは、「万能型SE一貫生産方式」の別の表現であると筆者は考えている。そして、この方式が長らく続いてきたことは、このやり方に合理的なメリットが存在するからなのだ。システム開発の時間やコストを構成するものは、担当者の正味の設計や製造・テストなどの作業時間とその作業を行うために関係のある担当者と打合せを行う時間との合計である。同じようなレベルの技術者が集まったと仮定すると、設計・製造・テストなどの作業時間そのものは、そんなに違いは出てこない。問題なのは、どれだけの担当者間のすり合わせ作業を必要とするのかである。図10-3に示すのは、システム開発の打合せコストを模式的に表現したものである。その中で、要員間調整コストがプロジェクトの開発時間やコストを左右することになる。図中に示したように、要員間調整コストは次の式で表すことができる。
要員間調整コスト=(1箇所当たりの調整コスト)×(調整必要箇所数)
当然ながら、この二つの項目の双方とも小さくすることができれば、要員間調整コストは抑えることができる。そして、そのための策は、次のようなものである。
① 1箇所当たりの調整コストの削減策:経験を重ねチームとして熟練すること。そうすることで、1回当りの調整コストを低減させることができる。いわゆる、阿吽の呼吸で、少ない打合せで相手の意図を理解し、すり合わせを完了するということ。このことは、初回の開発後のバージョンアップ開発で生産性が向上することが広く知られているが、1箇所当りの調整コストがチームとしての熟練により低下することが理由と思われる。
② 調整必要箇所数の削減
1)モジュール化や疎結合による打合せ減少効果:モジュール化や疎結合により、呼ばれる側のインターフェースが固定化されるので、打合せは大幅に削減される。
2)プログラム内非分業で調整を不要化:一人の担当者が一本のプログラム全部を担当することで、調整そのものを不要化する。これが「一貫生産方式」のメリットになる。
この中で、②の2)のプログラム内非分業、つまり、万能型SE一貫生産方式の採用が、多分一番大きな打合せ削減効果を生んだものと推察される。このことの合理性が、無意識的に分業を排除し、一本のプログラムを一人のSEに全面的に任せるというやり方を採用させたのではないかと筆者は見ている。米国を始めとする諸外国でのシステム開発の実相を筆者は残念ながら知悉していないので諸外国との比較に関して確かなことは言えない。しかし、本稿第7回で言及した「クスマノ先生の投げかけた日本SEの謎」のデータが示す日本のシステム開発の圧倒的な効率性は、日本人の能力の平均値の高さが、この手法に見事に適合していることを示していると思う。だからこそ、この手法はほぼ四十年の間、日本のシステム開発の根幹の仕組みとして、プログラム言語やデータベース技術に変更が起ころうが、変わることなく引き継がれてきたのだと思う。次回は、このようなシステム開発手法を取る日本の開発プロジェクトの管理のあるべき姿について考察することにする。





Follow CIO on Twitter
Fan CIO on Facebook
RSS
記事一覧

Header_Social_Icon