連載　情報システムの本質に迫る
第11回　複雑さ、コミュニケーション、能力開発　あるいは　プロジェクト管理の基礎

　「プロジェクト」というと、特別の目的を達成するため、特別チームを編成して対処する、タスクフォース的な仕事を指すのが一般的でした。日常的な組織で遂行される業務を、プロジェクトとはあまり言わなかったものです。
　９０年代の後半、米国からもたらされたPMBOK（Project Management Body of Knowledge）は、この考え方を一新しました。そこではプロジェクトが「独自の成果物またはサービスを創出するための有期活動」と定義されていました。この定義では、組織が日常的か特別編成かは問うていません。１人で行うのか多人数かも言っていません。１日でも１０年でも、期限があれば有期です。したがって、例えば上司が担当者に「明日の昼までにこれこれの書類を作るように」指示すれば、それはプロジェクトになります。完全なコピーでない限り、新たに作る書類には、必ず何らかの独自性があるからです。
　このため、社長であれ新入社員であれ、企業人が担う業務はほとんどがプロジェクトと見なされるようになりました。企業内で行われる仕事には、通常、期限があります。また、繰り返しのように見える仕事であっても、つねに何か新しい要素が含まれているからです。もちろん、研究・教育機関の仕事は、プロジェクトの塊と言ってもよいでしょう。
　プロジェクトの定義の変化は、プロジェクト管理に対する考え方も変革しました。プロジェクトがタスクフォース的に考えられていたときは、プロジェクト管理は管理者が学ぶものとされていました。しかし、新入社員の仕事でさえプロジェクトと見なされる今日では、プロジェクト管理能力は、すべての人にとって必須の素養となりました。
　このようにわが国にも大きな影響を与えたPMBOKでしたが、ほどなくPMBOK自体、構造的に改善すべき点のあることが明らかになりました。さらにわが国電気学会の研究により、特に情報システムに関し、複雑さの観点からプロジェクト管理の本質の解明が進められました。
　今回は、わが国におけるプロジェクト管理概念の変遷について見ていくことにします。

　特定の分野ごとに限れば、わが国でもプロジェクト管理の概念は早くから発達していました。例えば、ある金属系のメーカは、社内に１０００人をはるかに超える情報システムの専門家集団を形成していましたが、すでに１９７０年代、全社情報システム部門共通の「コンピュータ・プロジェクト推進管理マニュアル」をまとめていました。そこではシステム開発工程が、後の共通フレームと基本的に同等の構造で、フェーズごとの系統的なドキュメントの作成プロセスとして整理され、また開発部門と利用部門の役割分担も明確に規定されていました。
　この体系にもとづいて推進されたプロジェクト管理の実績が、菅野文友監修「ソフトウェア・プロジェクト管理」下巻に報告されています。このプロジェクトは、工期を２ヶ月短縮、しかも品質レベルを従来比１桁高めて完成するという画期的な成果を挙げました。
　このプロジェクトを取り上げたのは、その完成時期が、５０００万件の不明データで問題になっている年金記録管理システム（国民年金）のリリースと同じ年だったからです（厚生年金はさらに２年後）。年金記録管理システムの問題については、２０数年も前のことだから、当時のプロジェクト管理や設計技術の知見ではもともと困難なプロジェクトだったのではないかとか、このような問題を起こさないために同業の仲間たちはどういう努力をしていたのか、などという意見があります。
　しかし、金属系メーカの情報システム部門でさえ、上記のような体系化の努力をしていたのです。まして情報系の専門企業、例えば当時の電電公社では「既に１９６０年代に作業工程などソフトウェア・ライフサイクルの概念を確立」「研究所と複数のメーカとが共同で大規模ソフトウェアを開発する際のプロジェクト管理、計画・報告の在り方、文書化要領・・」をDIPS作業標準としてまとめていました。この標準とそれにもとづくプロジェクト成功の経験が「国内メーカのプロジェクト管理方法や作業標準として広く普及した」とされています（前掲書上巻）。
　学問の要件が概念・歴史・理論・方策にあることはつとに知られており、回転ドアの事故分析でも最終的に技術者の歴史認識が問われたことは、この連載の前々回で述べました。年金記録管理システムのリリースが１９８０年代半ばであることを考えると、この問題を議論するとき７０年代までにどれだけの技術蓄積ができていたか、正確な歴史認識をもって臨むことの重要性が分かります。

　PMBOKがもたらされた９０年代の後半以降、プロジェクトの本質の解明は特定の分野を超えて急速に進みました。それにともない、より普遍的なプロジェクト管理の体系化が可能になりました。
　PMBOKは、米国に本部を置くプロジェクト管理協会ＰＭＩ（プロジェクトマネジメントインスティチュート）がまとめた、プロジェクト管理の知識体系です。先述したように、PMBOKではプロジェクトを「独自の成果物またはサービスを創出するための有期活動」と定義しています。したがって、大小を問わず非常に広範囲の業務が対象になります。
　PMBOKでは、成果物を特定し作り出す作業自体は、プロダクトプロセスと位置づけています。プロジェクト管理は、プロダクトプロセスとは密接な関連をもちながらも独立した、どのような成果物に対しても共通のプロセスとして整理されています。したがって、例えば情報システム開発のプロジェクト管理を考える場合、最も重要な開発プロセスの管理自体はPMBOKに含まれていません。このことは、常に留意しておく必要があります。
　PMBOKでは、プロジェクト管理のプロセスをフェーズ（設計、実施など）毎に次の５つのグループに大別しています。前月号で述べたＰＤＣＡが、中核のサイクルとして位置づけられています。
　　1. 立ち上げのプロセス
　　2. 計画のプロセス
　　3. 実行のプロセス
　　4. コントロールのプロセス
　　5. 終結のプロセス

　一方、プロジェクト管理のプロセスは、次の９つの知識エリアに整理されています。
　　1. 統合マネジメント
　　2. スコープマネジメント
　　3. タイムマネジメント
　　4. コストマネジメント
　　5. 品質マネジメント
　　6. 組織マネジメント
　　7. コミュニケーションマネジメント
　　8. リスクマネジメント
　　9. 調達マネジメント

　PMBOKでは、スコープ（プロジェクトの成果物と作業の範囲）、コミュニケーション、リスクなどきわめて広範囲の概念が知識エリアとして取り入れられ、しかもそれらが品質、コスト、タイムなどわが国でもＱＣＤとして以前からなじみ深い概念と同じ並びで設定されているところに大きな特徴があります。
　あと１つ、PMBOKの特徴は、その構造が、この連載の第５回で述べた構造化分析の構造と整合性をもっていることです。
　最新構造化分析によると一般的に業務は、WHAT、WHEN、HOW、すなわち何を対象に、どんなタイムサイクル（あるいは順序）で、どのように処理するか、という３軸モデルで表現できます。

　プロジェクト管理も１つの業務として、３軸構造で表現することが可能です。PMBOKの場合、９つの知識エリアを業務の対象、すなわちカテゴリと見ることができます。フェーズ毎の５つの大別されたグループは、業務の実行順序を表わしています。したがってPMBOKの構造は、９つの知識エリアを縦軸、５つの大別されたグループを横軸とし、対応する位置に業務内容を配置したマトリクスで説明することができます。このマトリクスは業務の全体像を俯瞰し、また個別業務を管理していく上で、きわめて有用です。あるカテゴリ（例えば品質）について業務の順序は行に表わされています。計画、実行、コントロールなどの各段階で、カテゴリ毎に何をなすべきか、列に表現されています。

　このように非常に優れた特徴をもったPMBOKですが、構造的に一部改善すべき点のあることがすぐに明らかになりました。第１は、リスク管理の位置づけに関してです。
　上記のマトリクスで、横軸の主要なプロセスになっているのは、計画→実行→コントロールという、いわゆるデミングの管理サイクルです。デミングの管理サイクルでコントロールは、計画を実行後、問題が発生していないかどうかチェックして、問題が発生していれば改善処置をとるというもので、これは当然必要なことです。しかし、計画を立てた後、この計画を実行したときに問題が発生しないかどうかあらかじめチェックして、発生する可能性があれば、実行前に改善処置をとっておく方がさらに重要かつ効果的であることは明らかです。したがってデミングの管理サイクルは、本来、計画→コントロール→実行→コントロール（ＰＣＡＤＣＡ）とすべきでした。
ここで、実行前のコントロールはリスク管理と見なすことができます。PMBOKでは、リスク管理は、品質管理や調達管理と同列のカテゴリ（知識エリア）に位置づけられています。しかしリスクは、品質のリスク、調達のリスクという形で発生しますから、カテゴリの中にカテゴリを考えていく必要があり、独立性に問題がある上、繁雑です。そこで、横軸の管理サイクルを、計画→コントロール→実行→コントロールのように改訂し、リスク管理をカテゴリからはずす方が合理的と考えられます。

　PMBOKの次の改善は、カテゴリに「複雑さ」を取り入れることです。
　PMBOKでは、その定義から、１人で、１日で実行するようなプロジェクトから１０万人月にも及ぶプロジェクトまで、同じプロセスで実行することになっていますが、そんなことはあり得ません。
　９０年代末、電気学会の巨大システム調査専門委員会（高橋勝委員長）により、プロジェクト管理において複雑さを考慮することの重要性が指摘されました。その説明は厳密な分析にもとづき詳細にわたっていますが、ここではポイントとして次の２項目を挙げます。
（１）開発規模により生産性に大きな差があることは、実績により明らかです。
　　　例えば、開発規模１００万ステップの生産性は、１０万ステップの生産性
　　　の２〜３分の１になるとされています。
（２）このような事象は、次の２つの要因によってもたらされます。
　　　・システム開発規模が大きくなると、システムの複雑さが急激に増大する
　　　・プロジェクト組織が大きくなると、組織の効率が急激に低下する
　「複雑さ」は、PMBOKの９つのカテゴリのいずれからも独立した概念としての広がりをもっています。電気学会の調査結果から、プロジェクト管理における「複雑さ」の重要性は十分説明されています。したがって、「複雑さ」は新たにプロジェクト管理のカテゴリとして設定することが望ましいと考えられます。
　PMBOKの構造の第１の改善で、リスク管理をカテゴリからはずし、横軸の管理サイクルを、計画→コントロール→実行→コントロールのように改訂する方が合理的と考えられることを述べました。第１の改善でリスク管理をはずすと、「複雑さ」を加えたとしても、カテゴリの数は９つに保たれ、７±２のマジカルナンバー（人間の認知能力の限界から適切と考えられる、概念の第１分類の数）の範囲にはいります。

　複雑さの概念は、情報システムに限らず、どのような業種のプロジェクトを進める場合でも重要です。そこで複雑さの概念の分かりやすい説明を工夫してみることにします。
　今、プロジェクトの成果物の大きさを、成果物の要素の数で表わします。このとき成果物の複雑さには、要素数のほか要素間の関係数が影響します。要素の数が３、４、５、６のとき、要素間の関係数は次のようになります。

　要素数が増加したとき、要素間の関係数の増加によって複雑さが急激に増大していることが分ります。
　一方、上の図は、要員の数と要員間のコミュニケーションの必要数を表わしているとみることができます。組織全体が一定時間になしうる仕事量は、要員数が増加するのにともない増加しますが、コミュニケーションの必要数が増えただけ、ロスも増大します。したがって、組織全体でなしうる正味の仕事量は、要員数が増加するにしたがって、相対的には減少します。
　要素数と複雑さ、要員数となしうる仕事量（ロスを除く正味）の関係を概念図で表わすと、次のような曲線になります。

　上の図で、要素数Ｎの成果物の複雑さはＣになります。複雑さＣをこなし得る仕事量Ｗは、要員数Ｍによって生み出すことができます。この関係はバランスしていますから、プロジェクトは順調に進んでいきます。
　一方、要素数N'の場合、成果物の複雑さはC'となりますが、この複雑さを処理可能な要員数は求まらない可能性があります。複雑さ曲線は下に凸、仕事量曲線は上に凸になりますから、両曲線の交点より要素数の多い場合は、プロジェクトの推進がきわめてむずかしくなり、破たんすることさえあります。
　要素数N'の場合、プロジェクトはどうすれば順調に進むでしょうか。
　第１は、複雑さを減らすことです。要素間の関係を少なくして複雑さを減らすと、複雑さ曲線は下に移動し、交点が右の方に移動します。したがって同じ要素数N'に対してバランスの取れた要員数が求まる可能性が出てきます。
　要素間の関係を少なくする効果的な方法は、モジュール化です。ソフトウェアの場合は、モジュールの凝集度を高め、モジュール間の結合度を減らせばよいということが、１９７０年代から明らかになっています。モジュール間の結合度を減らすには、互いに内部を隠蔽し、メッセージのみ交換するのがベストです。凝集度を高めるには、当初機能中心にまとめるのがよいとされていましたが、データ中心の考え方の発展にともない、データと機能をカプセルにしてまとめるのがよしとされるようになりました。つまり、オブジェクト指向です。今日オブジェクト指向の考え方は、ソフトウェアのみでなく、業務プロセスや経営プロセスのモジュール化にも適用されています。
　プロジェクトを順調に進める第２の方法は、仕事量曲線を高めることです。それによって交点を右に移動させることができます。
　もともと、仕事量曲線がだんだん寝てきているのは、コミュニケーションロスが増大するからです。したがって、コミュニケーション管理を徹底してコミュニケーションロスを減少させることが、プロジェクトを順調に進める決定的な方法の１つということになります。コミュニケーション管理は、PMBOKのカテゴリに含まれていますが、プロジェクトの成否を分ける重要な意味をもっているのです。
　仕事量曲線を高めるあと１つの方法は、計画段階で能力の高い要員を選定するとともに、プロジェクト開始後、積極的に能力開発をすることです。それによって、仕事量曲線が高まり、破たんしかねないプロジェクトが順調に進むようになります。
　PMBOKのカテゴリに能力開発はありませんが、組織マネジメントの実行段階のプロセスが「プロジェクトチームの育成」となっているのは注目すべきことです。わが国では、このプロセスを「要員管理」と定義することが多いし、プロジェクトマネージャの中にも、プロジェクトが始まると忙しくて能力開発なんかしていられませんよ、という人が多かったのも事実です。能力開発もプロジェクトの成否を分ける決定的なプロセスになります。

　PMBOKは優れた構造をもったプロジェクト管理の知識体系ですが、リスク管理の位置づけを変更し、複雑さの管理（モジュール化）を新たに加え、（カテゴリはいずれも重要なのですが、その中でも）コミュニケーション管理と能力開発のプロセスに特に着目して実行すると、一段とすばらしいプロジェクト成果を挙げることができます。

　この連載では、情報と情報システムの本質に関わるトピックを取り上げていきます。皆様からもご意見を頂ければ幸いです。