ソフトウェア開発プロジェクトの問題や失敗の多くは、技術面ではなく、人と組織の問題であることが多い。もちろん、技術的な要素は重要なのですが、新技術や初物プロダクトを利用する場合、難度が高く、また重要であると皆が認識している場合、課題はあったとしても、適切に管理され、大問題となる前に解決への手が打たれます。そのため、失敗の原因の多くは、技術的な面よりも、社会学的な面が多くなります。この点に焦点をあてたものが「ピープルウェア」になります。「ピープルウェア」の観点に立つと、ＩＴ技術者、とりわけプロマネは、機械とコミュニケートすることと同時に、またそれ以上に、プロジェクト・メンバー間相互やステークホルダとのコミュニケーションが、プロジェクト推進にあたって、より大切になると考えています。
ところで、フレデリック・P・ブルックス Jr.の『人月の神話』が出た当時から既に３５年余り経ちます。以前紹介しましたが（第37 回 『人月の神話』と『デザインのためのデザイン』との間）、過去３５年間、ソフトウェア開発を行うための環境・道具立ては、大きく変わりました。一人一台のパソコン、メール、グループウェア、インターネット、ウェブ、パッケージソフト、リレーショナル・データベース、オブジェクト指向言語、アプリケーションフレームワーク、仮想化技術、ＢＩツール、ＥＴＬツール・・、静かできれいなオフィス、オフショア・ニアショア利用などが、３５年前にはなく、またあっても実プロジェクトへの適用はこれからの段階でした。
しかしながら、これらは、ソフトウェア開発における副次的な問題、「偶有的な問題」の改善には大いに役立ったものの、「本質的な問題」は依然残っています。「本質的な問題」、すなわち、モジュール化、抽象データ型、階層的構造化などのシステムを分割するための方法や、システム化にあたって顧客の要求が「２−４−２−３の法則」というプロセスを踏む現象に見られるように、顧客自身が何を希望しているか、明確に分かっているわけではないこと。また、システムの再構築において、「現行システム通り」といった要求の背後にある巨大なレガシーシステムを解析する方法などがあります。
これらの本質的な問題に気づかないまま、または、その問題の存在を曖昧にしたまま、偶有的な問題の解決策である新しい手法、プロダクトやツール、統合開発環境を導入することで、本質的な問題に対する対策も打ったつもりになることが、トラブル・プロジェクトの入口に立つことかもしれません。
以下に、要員のアサイン、体制構築において考慮すべき事項を述べてみます。
（１）ソフトウェア開発は、人間による作業である。人間は代替可能な部品ではない。
ソフトウェア開発の自動化への取り組みは、過去数十年にわたって行われている。設計開発支援のツールや統合開発環境は、充実してきました。しかし、モデリング、分析・設計作業における本質的な難しさは依然残っており、個々の技術者のスキルに依存することは残っている。プロジェクト・メンバーに満足感を与え、辞めないようにする工夫が必要になります。
（２）人はアナログでしか育たない、動かない。
命令一つで、オフからオンに切り替わって、想定通りのパフォーマンスが出るわけではありません。技術者各人が、プロジェクトでの役割、タスクの意味を理解し、納得づくで仕事をするようになることが必要になります。そのため、プロジェクト・チームとして決めたルールや行動パターンが、組織・チームの風土・文化になって身につくようにすることが大切となります。
アメリカの心理学者ウィリアム・ジェームズの言葉に、「意識が変われば行動が変わる。行動が変われば習慣が変わる。習慣が変われば人格が変わる。人格が変われば運命が変わる。」というものがありますが、
プロジェクト・チームとして決めたルールや行動パターンが、組織・チームの風土・文化になって身につくようにすることが大切になります。
（３）人間は、環境とスキルとモチベーションで、生産性は大きく１桁変動する。
個々人の生産性の差は、一説によると、２６倍あります（＊２）。
トム・デマルコ、ティモシー・リスター『ピープルウェア』において、スキル差で１０倍、環境差で２．６倍の差があったケースが紹介されています。その内訳は、オフィス環境などの良し悪しで、２．６倍の差があり、また、ＩＴ技術者としてのスキルの差が１０倍あるから、というものです。
また、同じ人間であっても、モチベーションの有無によって、倍半分異なることも考慮すると、個人差・環境の差によって、１桁の生産性の変動は存在すると思っています。
ただし、プロマネとしては、向上した生産性を前提にプロジェクト計画を立てるわけにはいかないため、標準的な生産性の値にプラスアルファした値を適用し、実際の生産性改善分を、不具合や手戻りのためのバッファーやコンティンジェンシーに充てる等の工夫が必要になると思います。
「プログラムは夜作られる」という言葉がありますが、これは、人がいなくなった静かな深夜にこそ、集中してプログラムは作られるということを示しています。「机の前に何時間座っていたか」よりも、「全神経を集中して仕事に取り組んだ時間」の方が大切です。
そのため、オフィス環境の騒音や仕事中の割り込みの存在は、ＩＴ技術者の集中力にとって大きな問題です。人がフロー状態とか、ゾーンという状態に入った時、素晴らしいパフォーマンスが発揮されることは知られていますが、割り込みのない連続した時間がどれだけ確保できるかが、生産性に大きく影響します。このフロー状態になれる環境を用意できるか否かが、プロマネの責任の一つだと思います。
したがって、プロマネの仕事の一つは、プロジェクト・メンバーが力を発揮できる環境を用意し、教育・育成・フォローを行い、動機付けをすることになります。
（４）チームは少数精鋭が良い。また、少数だからこそ、精鋭化する。
大規模システムの攻略の鍵の一つは、サブシステム分割にあります。
分割しないままだと、個人の思考の理解限界を超え、思考停止につながるし、関係者が多いままだと、莫大なコミュニケーションロスのために、生産性は極めて低くなります。
そのために、サブシステムに分割する必要があるのですが、たとえ分割しても、難度の高い領域と低い領域が存在するため、難易度を見極めて、要員をアサインする必要があります。
人余りのプロジェクトは、めったに存在しないとは思いますが、１つの仕事を複数人で分割してかえって難しくしてしまうぐらいであれば、一人一人にある程度まとまった領域を任せて、数人だけで特定領域をグリップできるようにした方がよい。
（５）急がせても、早くは考えられない
納期直前のバタバタの状態で、急がしたとしても、単純作業であるならばまだしも、
考えることを早くすることはできません。
事前に、考えるための時間を十分にとっておく必要があります。そのため、成果物が生まれない期間の並行作業をどうするか、などの段取りが大切になります。
（６）人と月は入替不能。人を投入しても、月（工期）は短縮できない。
寄せ集めのメンバーを短期間に投入したチームよりも、錬度の高い要員のいるチームで長期間かけてプロジェクトを推進する方が、生産性も品質も良くなることは容易に想像できます。
必要な工期の４分の３以下に短縮したプロジェクトの成功率は極端に下がり、品質面でのフォロー期間を考慮すると、当初の工期を超えるトラブル・プロジェクトとなってしまいます。
また、プロマネやリーダとしては、工期短縮のために、「さば」を読んだ納期をメンバーに提示することをしたい誘惑にかられますが、非常にタイトな状況下で行った場合、一度はともかく、二度は通用しません。
（７）個人プレーから組織プレーへの転換が必要となる。
大規模プロジェクトにおいては、一人で人の３倍の生産性を誇るよりも、１０名のメンバーで、１０名分以上の成果を出せるようになることがより重要となります。そのためには、「人に任せるよりも、自分でやった方が早くて正しい」「人に教えるのは面倒だ」などの低いパラダイムからの転換が、プロマネになるためには必要となります。
（８）チーム・ビルディングには時間がかかる
十分に訓練されたチームは、組織にとって貴重な財産です。
≪組織の学習能力は、組織がどの程度人を引きとめておけるかで決まる≫（＊２）
そのため、プロジェクトが終結した場合、個別に人をはがすのではなく、チーム全体として新しいプロジェクトを担当させるようにすることが大切です。単独のプロジェクトを超えた、プログラム・マネージャやポートフォリオ・マネージャの仕事の一つはここにある、と考えています。
以上のようなことはこれまでも、要員・体制作り、メンバーの育成時に考えて取り組まれてきたと思います。また、ＰＭＢＯＫの知識エリアであれば、プロジェクトタイムマネジメントのアクティビティ資源見積りやスケジュール作成において、個別に考慮してきたと思います。
しかし、プロジェクトの組成時に事前に検討すべきこととして、「ハードウェア」「ソフトウェア」に並立した、「ピープルウェア」を定立すべきではないか、と思っています。
（＊１）フレデリック・P・ブルックス Jr.『人月の神話』訳・滝沢徹、牧野祐子、富澤昇、 ピアソン桐原、２０１０年刊
（＊２）トム・デマルコ『ピープルウエア 第２版 - ヤル気こそプロジェクト成功の鍵』訳・松原友夫・山浦 恒央、日経ＢＰ社、２００１年刊