１
＜知識継承性＞	＝
		＜ソフト開発要員数＞

　この式は感覚的な式です。ソフトウェア開発要員が１人であれば、＜知識継承性＞は１となりますから、＜知識継承性＞＝１は知識継承性が最大であることを意味します。ソフト開発要員数が５０人になると、知識継承性は５０分の１になるという計算です。この計算の数値には特に意味がありません。しかし、要員の増加は知識継承性を落とすということは分かります。

　従って、ソフトウェア開発はできるだけ少人数で行うのが望ましいということが分かります。要員数が増えるほど、知識継承コストは増大します。理想は１人で開発することです。作業を１人で行うことができるならば、次のメリットがあります。

（１）	知識の継承が不要
（２）	管理者は不要
（３）	中間ドキュメントが最小限に減らせる

　上記は極論ですが、ITプロジェクトの組織づくりを考える際、指針となるヒントを与えてくれます。つまり、理想的なソフト開発は、知識継承コストを抑え、管理者を減らし、最少のドキュメントで行うことです。

　実際のプロジェクトでは、1人でこなせる仕事量には限界がありますので、納期・品質確保のために、多くの要員を投入することになります。要員数が増えると、関係者間で知識を共有するためのコストが増大します。作業標準や開発支援ツールを習得するためのコストも発生します。プロジェクト状況を把握するためのコストも大きくなります。５人のプロジェクトと５０人のプロジェクトでは１人当たりの知識継承コストは５０人プロジェクトの方が大きくなります。プロジェクトのメンバが増えるほどプロジェクトの生産性は低下します。予算内で仕事を達成するには、既存の知識でそのまま役立つ人材を揃えるのが最善です。しかし、現実には、潜在能力がある人材を集め、上記のコストが最小となるような開発を目指しています。

　以下では、一般的な開発モデル（Waterfall型）を使って、知識継承の必要性と望ましい考え方について述べます。

（１）　一般的な開発モデル

　一般的にソフトウェア開発は、Waterfall型の要求仕様（外部仕様）設計＆構成（構造）仕様設計→詳細仕様設計→コード化→単体テスト→結合テスト→総合テスト＆評価というプロセス（図３参照）で行います。小さなソフトウェアであれば、顧客要求をいきなりコード化することもできるのでしょうが、１人で２０KLOCのソフトウェアを開発することもあります。２０KLOCもあるソフトウェアを要求仕様からいきなりコード化するという無謀なことは避けなければなりません。論理構造が複雑なソフトウェアならばなおさらです。複雑な論理構造をもつソフトウェアはモジュール化が必須となります。論理構造を明らかにしておいてから、プログラム（モジュール）のコード化を行わなければ、とんでもない結果が待ち受けています。論理構造の設計とモジュールのコード化とを同時並行的に行うと誤りを誘引する確率が高くなります。論理構造の設計とコード化では頭の使い方がまるで異なるからです。コード化する前の段階で、全体の論理を整理しておかなければ手戻りが多くなってしまいます。関連性の薄い複数のプログラム（モジュール）の集合からなるソフトウェアならば可能かもしれませんが、現実にそのようなソフトウェアがどれだけあるのでしょうか。従って、たとえ１人であっても上記の手順を踏むことにより、頭の中が整理でき、見通しが利いたソフトウェア開発が可能となります。

　上記の開発モデルでは６つの工程に分けています。この６つの工程は大きく前工程と後工程の２つに括ることができます。前工程は要求仕様（外部仕様）設計＆構成（構造）仕様設計です。後工程は詳細仕様設計、コード化、単体テスト、結合テスト、総合テスト＆評価です。このように前工程と後工程に分ける理由は、前工程は比較的少人数の熟練者のみで作業を行い、ソフトウェア構築の段取りをつけるのに対し、後工程は前工程で決めた段取りに従い、大人数をかけて手分けして開発します。従って、この２つの前・後の工程では管理方法・知識継承方法が異なります。

　前工程の生産物は要求仕様（外部仕様）設計書および構成（構造）仕様設計書です。これらの仕様設計書はソフトウェアの機能とそれを実現するモジュール構成を定義し、詳細仕様設計工程以降を実行する多数のメンバへの展開を可能とすることを目的としています。従って、詳細仕様設計以降の作業担当者が従うべき情報はすべてこれらの仕様設計書に盛り込まれていなければなりません。

図３　開発工程

（２）　知識継承の必要性と望ましい考え方

　これまで述べたことで、ITプロジェクトにおける知識継承について具体的な議論ができるようになりました。ここでのテーマは　どんな知識を、誰に継承するのかです。

（ａ）　前工程の知識継承

　前工程の生産物はソフトウェアの要求仕様（外部仕様）設計書と構成（構造）仕様設計書です。これらの仕様設計書は詳細設計工程以降のソフトウェアを実現するための段取りをつけるためのものです。前工程はソフトウェア全体が見渡すことができる、レベルの高い、比較的小人数のシステム技術者で作業します。少人数の方がコミュニケーションがとり易いからでもあります。

　要求仕様（外部仕様）設計書にはソフトウェアが何を行うのか（Ｗｈａｔ）を詳細に定義します。外部仕様を定義するとも言われます。外部仕様とは、ソフトウェアが動作するとき、利用者とのインターフェースとなるすべての情報について定義する仕様書です。ソフトウェアの機能と動作を具体的に定義します。

　構成（構造）仕様設計書には要求仕様（外部仕様）設計書で定義されたソフトウェアの機能と動作を実現するために必要なすべての情報（How-to）を詳細に定義します。ソフトウェアの骨格（構成、構造）を明らかにします。どのようなハードウェア・ネットワーク構成の上で動作するのか、どのようなモジュールの組合せになっているのか、モジュール間で使用するデータ、外部仕様上で表現されているデータの内部表現、ソフトウェアの動作をモジュール間の関係として表現します。これらの仕様設計書の詳細度は、以降の複数モジュールの詳細仕様設計が平行開発できるレベルであることが必要です。他のシステムとのインターフェースもここで定義します。

　要求仕様（外部仕様）設計書を定義するためには、利用者（顧客）の要求を体系的に文書化します。この作業は、対象とするソフトウェアに手馴れたシステム技術者によって行われる必要があります。利用者（顧客）は自らの仕事をどうしたいのかを提示します。システム技術者は利用者（顧客）の要求を聴き、ソフトウェアの機能・動作をどのようにすべきかをまとめます。利用者（顧客）は自分の仕事に詳しく、システム技術に必ずしも詳しくありません。他方、システム技術者はシステム技術に詳しく、利用者（顧客）の仕事に必ずしも詳しくありません。要求仕様（外部仕様）設計書をまとめるのはシステム技術者であり、利用者（顧客）からヒヤリングして文書化します。この段階で、システム技術者がコンサルタントを使うこともあります。システム技術者は利用者（顧客）の知識をいろいろな手段を使って吸収（継承）し、要求仕様（外部仕様）設計書を書き上げます（図４参照）。

図４　利用者（顧客）知識の継承

　システム技術者は要求仕様（外部仕様）設計書を元にして構成（構造）仕様設計書を書きます。構成（構造）仕様設計書の目的は次を明らかにすることです。

・	ソフトウェアの骨格（構成、構造）。 ソフトウェアが動作するハードウェア構成、ネットワーク構成。
・	ソフトウェアのモジュール構成。モジュール間の関係。
・	ソフトウェアのモジュール間で使用するデータの定義（含：データベース定義）。
・	他のシステムとのインターフェース定義。

　構成（構造）仕様設計書を書くために必要な知識は、要求仕様（外部仕様）設計書と、ここで定義された機能と動作を実現するために必要なシステム技術です。利用者（顧客）の要求が完全に要求仕様（外部仕様）設計書に反映されることは先ずありません。コンパイラの設計であれば、言語仕様書として定義されていますから、比較的完全に近い表現がされていますが、通常の顧客のシステムの場合、どうしても曖昧さが残ります。従って、構成（構造）仕様設計書を書くためには、図５に示すように、利用者（顧客）を含む人たちからの知識継承が必要となります。

図５　ソフトウェア構築のための知識継承

　構成（構造）仕様設計の作業は、次に控えている詳細仕様設計工程で、複数モジュールの詳細仕様設計が平行開発できるようにすることを目的としています。複数のプログラマは、図６に示すように、要求仕様（外部仕様）設計書と構成（構造）仕様設計書を元に詳細仕様設計書を書きます。要求仕様（外部仕様）設計書と構成（構造）仕様設計書は、ソフトウェアを構成する複数のモジュール間の関係、モジュールの仕様を定義する詳細仕様設計書で共通的に使用するデータとを定義します。

図６　仕様の階層構造

（ｂ）　後工程の知識継承

　後工程、特に詳細仕様設計工程とコード化工程の知識継承は図７に示すように、プログラマは、システム技術者、要求仕様（外部仕様）設計書と構成（構造）仕様設計書から知識を得て、また、システム技術を駆使してモジュールの詳細仕様設計とコード化を行います。モジュール単体でのテストについてもプログラマが行うのが合理的です。コード化を別のメンバに引き継ぐと知識継承コストがかかるからです。

　図６に示す仕様の階層構造からも分かるように、前工程と後工程とでは、ITプロジェクト体制が大きく異なります。要求仕様（外部仕様）設計＆構成（構造）仕様設計工程は比較的少人数で作業することができるのですが、後工程は大人数に展開する必要があります。この段階で、ソフトウェアの規模見積、要員数、予算、納期、品質、計測、知識継承、などの様々な課題が発生します。こうしたITプロジェクト管理の問題は別稿に譲るとして、ここでは知識継承問題に着目したいと思います。

　システム技術者は本ITプロジェクトに関係する複数のプログラマに対して、要求仕様（外部仕様）設計書、システム技術について、徹底して伝える必要があります。各プログラマは自分が担当するモジュールについて、全体の中で理解しなければなりません。単に、構成（構造）仕様設計書で定義されたモジュールの詳細設計書の執筆、コード化を行えば良いというものではありません。プログラマは、ソフトウェアが何を狙いとしているか、そのためにどのような機能・動作を定義しているのか、そして全体の構成はどうなっているのか、自分が担当するモジュールはその中のどこに位置づけられているのかを知らなければなりません。

　詳細仕様設計工程では、どのプログラマにどのモジュールを割り当てるか、使用するシステム構築ツールの理解、進捗状況の計測、要求仕様（外部仕様）設計と構成（構造）仕様設計書の不備の訂正、利用者（顧客）要求の変更・不備の訂正、利用者（顧客）との調整などが必要になります。これらの問題・課題情報を集約し、解決策を見つけ、判断しプロジェクトにフィードバックするプロジェクト推進グループを作る必要があります。

　テスト工程以降についても知識継承の問題はありますが、これについては別稿で述べることにします。

図７　詳細仕様・コード化のための知識継承

　上に述べましたように、ITプロジェクトでは利用者（顧客）の要求をソフトウェアとして具体化するまでの間、利用者（顧客）→システム技術者→プログラマへとプロジェクトを進めるために必要な知識を継承する必要があります（図８参照）。利用者（顧客）がもつ業務知識はシステム技術者が継承し、システム技術者がもつ知識はプログラマが継承します。プログラマは詳細設計およびコード化を行うのですが、システム技術者がサブシステム毎にプログラマのリーダ役をつとめ、知識継承のコストをできるだけ少なくするようにします。

　詳細設計工程に入る前に、新しくプロジェクトに加わるプログラマ全員に対し、要求仕様（外部仕様）設計と構成（構造）仕様設計を説明し、また、詳細仕様設計書の執筆標準を提示し、理解させることが大切です。

　プロジェクト進捗を制御することを目的とするプロジェクト推進グループはシステム技術者で構成するのが望ましいでしょう。

図８　知識継承の流れ

（３）　知識および継承の不完全性と修復

　上に挙げた要求仕様（外部仕様）設計書、構成（構造）仕様設計書、詳細仕様設計書の記述内容は、利用者（顧客）→システム技術者→プログラマへと正確に伝えられなければなりませんが、知識そのものが不完全であったり、知識の継承が不正確であったりすることはよくあることです。ＩＴプロジェクトにおいて、これらの問題は常に伴ないます。人が作業する限り、避けて通れない問題です。しかし、問題を修復することはできます。問題はいつでも発生しますが、問題が顕在化する時期を遅らせないようにすることが最善の策です。顕在化するまでの時間が長いほど、問題の修復に時間と費用がかかります。

（ａ）　要求仕様（外部仕様）の不完全性の修復

　利用者（顧客）が、頭の中でイメージしていたことと実現されたソフトウェアとが異なるということはあり得ることです。要求仕様（外部仕様）の不完全性は、仕様書のレビュー、プロトタイピング、シミュレーションなどによる手段で修復することができます。ソフトウェアが完成していない初期の段階であっても、ソフトウェアの画面や動作のプロトタイピングやシミュレーションにより、ビジュアル化し、早い段階で致命的な障害となる要因を取り除きます。要求通りにソフトウェアが動作しないということは最長の修復期間がかかり、最大のコスト増となりますから、多少の費用をかけても、このような問題を起こさないようにすることは非常に価値があることです。

（ｂ）　構成（構造）仕様設計書、詳細仕様設計書、モジュール・コードの不完全性の修復

　システム技術者やプログラマが構成（構造）仕様や詳細仕様、モジュール・コードに誤りを作りこむことはよくあることです。このような不完全性は、仕様書やコードのレビューを行うことにより修復することができます。しかし、この問題の解決は単純ではなく、これらの不完全性は、システム技術者やプログラマの個人的な能力に大きく依存しています。

　作業開始以前の訓練、個人の能力を見極めた仕事の配分、２人１組にした作業、などにより問題の作り込みの回避や修復を行います。

　ソフトウェアの不具合は、ソフトウェアの一部が動作するようになって、テストを開始したときに顕在化してきます。テストする前までは幸せな時間を過ごすことができるのですが、テスト段階になって多くの不具合が顕在化すると関係者は狼狽し、大慌てで要員を追加したり対策をとろうとします。このような事態は、ソフトウェアの不完全性を見極めるタイミングを逃していたために引き起こされたのです。ソフトウェアは論理の塊ですから、完全に考えきっていれば、テスト段階ではケアレスミス位しか発見されません。大きなトラブルは考えきっていないままコード化し、テスト工程に突っ込んで行ったことによることが多いのです。皆さんはテストで不具合を見つけたとき、どうやって修復しますか。ケアレスミスならば、直ぐに気がつくでしょう。論理ミスならば、そう簡単ではありません。詳細仕様設計書→構成（構造）仕様設計書→要求仕様（外部仕様）設計書にまで遡って原因を探ろうとするはずです。結局は、前の工程の作業に戻ってしまうのです。このような事態が頻発するようであれば、テスト作業を中止し、仕様書の見直し（レビュー）からやり直す方が事態は早期に収拾します。テストを継続すると、非常に長いサイクルのやり直しを何度も強いられ、納期は遅れ、費用は莫大なものになってしまいます。

（ｃ）　知識継承の不正確さの排除

　知識継承の不正確さの排除の最善の手段は、知識の継承の必要な状況をできるだけ避けることです。

　ＩＴプロジェクトの当初のメンバ（システム技術者、プログラマ）はソフトウェアが完成し、利用者（顧客）に使用してもらえるまで、そのプロジェクトに留まる（１００％でなくても）べきです。途中で、新しいメンバ（システム技術者、プログラマ）に交代すると、その時点で知識継承コストが発生します。

　前工程から詳細仕様設計に入る際、ＩＴプロジェクトには多数のプログラマが入ります。ここでは、大規模な知識継承が必要となります。講習会や合宿、訓練などの機会を通して、当該ソフトウェアに関連する知識を継承することになります。プログラマは詳細仕様設計から開始しますが、要求仕様（外部仕様）設計書と構成（構造）仕様設計書だけを頼りに仕事を始めることは困難を伴ないます。プログラマの傍らにこれらの仕様書を執筆したシステム技術者がいて、いつでも相談に乗れるような環境にしておくことが望ましいのです。

（ｄ）　プロジェクト推進グループの設置

　ＩＴプロジェクトを遂行している間は、ソフトウェア開発自体の問題だけでなく、利用者（顧客）との調整、要員の追加・変更、・・・などの問題が発生します。また、ＩＴプロジェクトの現在状況がどうなっているか、把握（計測）することも必要です。これらの問題を解決するために、プロジェクト推進グループを設置し、すべての情報はこのグループで把握し、指示し、調整するようにします。知識継承の問題もこのグループで扱うべきでしょう。　

■