プロジェクト・マネジャーが覚えておきたい名言・箴言・法則

2021年6月2日2022年8月8日

今回はプロジェクト・マネジャーや制作現場のディレクター、SEが覚えておくと役に立つ名言や箴言、法則をまとめました。
このページで紹介する言葉はこちらです。

• 勝兵は先ず勝ちて而る後に戦いを求め、敗兵は先ず戦いて而る後に勝を求む。
• なぜ、こんな悲惨な条件がプロジェクトに課されるのだろうか。大部分は「政治」という非常に単純な言葉で説明できる。
• 『熊とワルツを』（リスク管理の本のタイトル）
• 成功プロジェクトのマネジャーはトラブルに対応し、失敗プロジェクトでは犠牲者を演じる。
• プロジェクトが大失敗する原因には２つある。１つは見積りミスだ。
• もう１つは仕様を凍結できないことだ。
• 要件作業を実施する意味は、人々が望まないシステムを設計しないようにすることだ。
• 遅延しているプロジェクトに人を追加すると、ますますプロジェクトは遅延する。
• 他のすべての原因よりもカレンダー時間の切迫が、ソフトウェアプロジェクトにその失敗の現実を直視させる。
• いくら時間的に余裕があっても締め切りギリギリにならないと着手しない。
• 組織は些細なものごとに対して、不釣り合いなほど重点を置く。
• 地図の最も重要な特性は関係者全員がそれを理解できなければならない。
• 地図と実際の土地が一致しない時は、つねに実際の土地を信じよ。
• ソフトウェア開発はチームスポーツである。

それでは詳しく見ていきましょう。

ゴールまでの道筋をつけてから取り組む

勝兵は先ず勝ちて而る後に戦いを求め、敗兵は先ず戦いて而る後に勝を求む

孫子

はじめにご紹介するのは世界的にも有名な孫子の言葉で、「戦う前に勝利までの道筋をつけておいて、その後に戦おう」という意味です。
最近ではプロジェクトの不確実性への取り組みが強調され、「計画をしても、その通りにならないことが多い」という雰囲気が強まってきました。
しかし、だからといって計画を軽視してはいけません。
計画の上でも上手くいかないものが、実際に取り組んで上手くいくということも少ないでしょう。
「プロジェクトのゴールがどこなのか？」「そこに到達するまでにどのように取り組めばよいのか？」「どのような準備が必要なのか？」という道筋をつけてからプロジェクトに取り組んでいきましょう。

政治を軽視してはならない

なぜ、こんな悲惨な条件がプロジェクトに課されるのだろうか。大部分は「政治」という非常に単純な言葉で説明できる。

『デスマーチ ソフトウエア開発プロジェクトはなぜ混乱するのか』 より

プロジェクトが失敗する理由はいくつもありますが、世の中には開始前から成功があまり望めないようなプロジェクトがあります。
信じられないほどの短い納期や低い予算、まったくメンバーが確保できない状況など、このまま開始すればプロジェクトが座礁することは目に見えているのに、それでも出航してしまうプロジェクトは後を絶ちません。
こうしたプロジェクトは「デスマーチ（死の行軍）」を始めるのですが、先ほどの言葉はこのデスマーチを研究した『デスマーチ ソフトウエア開発プロジェクトはなぜ混乱するのか』の一節です^[1]G.M.ワインバーグ (著)、木村 泉 (訳)『スーパーエンジニアへの道―技術リーダーシップの人間学』共立出版、1991年、８頁。。
つまり、短納期・低予算・資源不足などの悲惨な条件でプロジェクトが開始される理由は「政治」にあるのだとしています。
例えば、「同期のあいつに負けたくないから、あいつより短い納期で提案してやった」「人手が足らない時期だけど、社長の機嫌をとるために10周年プロジェクトを進めなければならない」というようなものです。
ここまでひどい話ではなくても、プロジェクトには多かれ少なかれ政治が関係しています。
プロジェクト・マネジャーやディレクターは、こうした政治にも注意してプロジェクトを進めることが望まれます。

リスクに向き合う

ターウィリガーおじさんはリスクをとることに意欲的だ。
彼がリスクの評価、抑制、軽減をきちんと理解していることを願う。
それさえ理解していれば、リスクを抱えるソフトウェア・プロジェクト・マネジャーにとって、すなわち時には熊数匹と踊らねばならない人たちにとって、完璧なお手本である。

『熊とワルツを　リスクを愉しむ
プロジェクト管理』より

プロジェクトにはリスクがつきものです。
そして、プロジェクトのリスク管理の名著が『熊とワルツを　リスクを愉しむプロジェクト管理』（以下、『熊とワルツを』と略記）です。
このかわいらしい本のタイトルは“My Uncle Terwilliger Waltzes With Bears（熊とワルツを踊るターウィリガーおじさん）”という子供向けの音楽に由来します。
そして、なぜ子供向けの曲のタイトルから『熊とワルツを』というタイトルにしたのかを著者が説明したのが先ほど引用した言葉です^[2]トム・デマルコ（著）、ティモシー・リスター（著）、伊豆原弓 … Continue reading。
『熊とワルツを』ではプロジェクトのリスクを「熊」に、プロジェクト・マネジャーを「ターウィリガーおじさん」に見立てて表現しています。
熊とワルツを踊るというのは、子供向け音楽の歌詞になるほど楽し気なことですが、熊が引き起こす様々なリスクを管理していなければ、大惨事になってしまいます。
プロジェクトは日常的な業務ではない仕事に取り組むため、未知の部分が少なからずあり、それがリスクにつながっています。
例えば、前人未到の土地を発見することに成功すれば、発見した冒険家は高い名声を得られますが、前人未到の土地を目指すことはそれだけ高いリスクを伴います。
多くの場合、プロジェクトで得られる成果とリスクというのは比例の関係にあります。

大きな成果を得るために、十分なリスク管理を行うことがプロジェクト・マネジャーに求められます。

どのようなプロジェクトでもトラブルは起こる

成功プロジェクトのマネジャーはトラブルに対応し、失敗プロジェクトでは犠牲者を演じる。

『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』より

ソフトウェア開発の人類学者と呼ばれるG.M.ワインバーグの『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』（以下、『システム思考法』と略記）では面白い研究結果が紹介されています。
それは調査を行ったところ、成功したプロジェクトであっても、失敗したプロジェクトであっても、「悪運」というべき不測のトラブルは同様に発生しているというものです。
大切なのはトラブルが発生した後の対応で、成功に導いたプロジェクト・マネジャーはあらかじめトラブルに備えており、トラブル発生後も柔軟に解決に取り組みました^[3]G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年、129頁。。
一方で、失敗したプロジェクトのプロジェクト・マネジャーは「私は悪運の犠牲者になってしまった」と悲劇の主人公を演じるのみで、上手く対応できませんでした。

先ほどの『熊とワルツを』の話にも似ていますが、プロジェクトにリスクやトラブルはつきものです。
しかし、プロジェクトが成功するか否かを分けるのは、そのリスクやトラブルに対して十分な備えをし、対応できるかどうかにかかっています。

見積りという失敗要因

プロジェクトが大失敗する原因には２つある。１つは見積りミスだ。

『ソフトウエア開発 55の真実と10のウソ』より

プロジェクトが失敗する理由は様々ありますが、大きな失敗要因の１つが見積りです^[4]ロバート・L・グラス (著)、山浦 恒央 (訳)『ソフトウエア開発 55の真実と10のウソ』日経BP出版センター、2004年、42頁。。
例えば、プロジェクトで取り組む作業（スコープ）の見積りを誤ると、金額の見積りに影響し、予算不足になってしまったり、作業のスケジュールが十分に用意できなかったりしてしまいます。

見積りが必要な主な項目は、作業・時間・金額ですが、これらの見積りをできるだけ正確に行うことが大切です。

仕様が凍結されないという失敗要因

もう１つは仕様を凍結できないことだ。

『ソフトウエア開発 55の真実と10のウソ』より

見積りとともにプロジェクトの大きな失敗要因になるのが仕様を凍結できないことです。
「何をするのか」という仕様が決まらず、ズルズルとプロジェクトが進んでしまうと、後になってから「やっぱり仕様を変えよう」という変更が入り、プロジェクトが混乱してしまうというのはよく聞く話です。
アジャイル開発ではこうした仕様変更も見越してプロジェクトを進めるものの、いつかは仕様を固めなければなりません。

ユーザーを想定し、何をするかだけではなく、何をしてはいけないのかを考える

要件作業を実施する意味は、人々が望まないシステムを設計しないようにすることだ。

『要求仕様の探検学―設計に先立つ品質の
作り込み』より

要件や仕様を考える上で大切なのは、「何をするのか」を考えるだけではなく、「何をしてはいけないのか」もあわせて考えることです。
一口に「使いやすいWebサイト」と言っても、10代の若者にとって使いやすいWebサイトと高齢者が使いやすいWebサイトは異なります。
要件や仕様を策定する際は、ターゲットとなるユーザーを必ず想定し、「その人が望むものは何か？」と「その人が望まないものは何か？」をあわせて考えていきましょう。

遅延しているプロジェクトに人を追加すると、ますます遅延する

遅延しているプロジェクトに人を追加すると、ますますプロジェクトは遅延する。

ブルックスの法則

ブルックスの法則は、プロジェクトマネジメントの世界では有名な法則です。
スケジュールが遅れていると、「人を増やして何とかしろ！」と言われることもあるのですが、安易な方法に頼ってはますますプロジェクトは混乱していきます。

• ブルックスの法則について詳しくはこちら

スケジュール遅延は結果である

他のすべての原因よりもカレンダー時間の切迫が、ソフトウェアプロジェクトにその失敗の現実を直視させる。

ブルックスの法則のいいかえ

先ほどのブルックスの法則を、G.M.ワインバーグが言い換えたものです^[5]G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年、83頁。。
ワインバーグが言いたいことは、スケジュールというのはプロジェクトの通信簿であって、スケジュール自体がプロジェクト失敗の原因ではないということです。
「あと１週間時間があったらこんな失敗しなかったのに」というような愚痴を耳にすることはよくありますが、その１週間の時間を作れなかった他の部分に問題の本質はあるはずです。

スケジュールだけを見て、場当たり的な対応をしてしまうと、先ほどのブルックスの法則が働き、プロジェクトは手が付けられないものになってしまいます。
スケジュール遅延が発生した場合は、プロジェクト全体を見渡し、おちついて体制の立て直しに取り組むことが大切です。

時間があると人は怠ける

いくら時間的に余裕があっても締め切りギリギリにならないと着手しない。

学生症候群

この学生症候群はどれだけ時間があっても終わらせられない夏休みの宿題や、卒業がかかっていても学期末にしか進まない卒業論文に見られる現象のことです。
プロジェクトの失敗の理由に「スケジュールが短かったからだ」という回答をする人は多いですが、十分な時間をとってプロジェクトを始めても、学生症候群が発生し、余裕のある分だけ時間を無駄にしてしまうことはよくあります。

プロジェクト・マネジャーやディレクターは、メンバーの手が空いているのであれば、できるだけ前倒しで取り組むように促していくことが大切です。

• 学生症候群について詳しくはこちら

人は些細なことに囚われる

組織は些細なものごとに対して、不釣り合いなほど重点を置く

パーキンソンの法則

これはパーキンソンの法則と呼ばれるものです。
ブルックスの法則とともにプロジェクトマネジメントの世界で有名な法則で、学生症候群とともに、十分に時間を用意したプロジェクトであってもスケジュールが足らなくなる一因となっています。

よく例として出されるのが原子力発電所建設のプロジェクトです。
このプロジェクトのミーティングが開かれたら、原子力発電の仕様の話は数分で終わり、ミーティングで提供するお弁当の話には数時間単位で時間が費やされるかもしれません。
このように、重要な話は十分に議論されず、誰もが口を出しやすい重要度の高くない話にばかり時間が使われるのがパーキンソンの法則です。

プロジェクト・マネジャーはこのような状態にならないように会議をコントロールしていく必要があります。

• パーキンソンの法則について詳しくはこちら

参加者が理解できる資料を作る

地図の最も重要な特性は関係者全員がそれを理解できなければならない

『要求仕様の探検学―設計に先立つ品質の
作り込み』より

プロジェクトでは様々な資料を作成していきます。
その中で重要なのは、プロジェクトの参加者が内容を理解できるような資料をつくらなければならないということです。
専門用語が解説もなく大量に使われている資料や、専門的な知識を持っていないと読み解けない設計図は不親切なだけでなく、後々のトラブルにつながります。

プロジェクトの参加者の誰もが、資料を読み返すことで状況を理解できるというのが、理想的な資料作成です。

現状を重視する

地図と実際の土地が一致しない時は、つねに実際の土地を信じよ

『要求仕様の探検学―設計に先立つ品質の
作り込み』より

この言葉がアジャイル開発の本質だと思われます。
つまり、プロジェクトの計画は用意するものの、実際にプロジェクトを進めていく上で、現状にそぐわない部分があれば、現状を重視して対策を練るというものです。

「導入しようとしていたITツールが社内の環境にあわなかった」「実際のユーザーは想定していた利用をしていなかった」など、新事実がわかった場合は、無理にプロジェクトを進めようとせず、プロジェクトを中止し、一度道を引き返すのか、それとも準備を整えて再度進めるのかという判断をしたほうがよいでしょう。

仕事はチームスポーツである

ソフトウェア開発はチームスポーツである

『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』より

最後に紹介するのは、Googleでの開発体制を紹介した『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』（以下、『Team Geek』と略記）からの言葉です^[6]Brian W. Fitzpatrick（著）、Ben Collins-Sussman（著）、角征典（訳）『Team Geek … Continue reading。
ソフトウェア開発はプログラマーの個人プレイの仕事だと思われがちですが、そうではなくチームで協力していくことが大切であるというのが、『Team Geek』のテーマです。

これはソフトウェア開発プロジェクトだけでなく、他のプロジェクトであっても同様であり、仕事というものがチームスポーツであると言えるでしょう。
プロジェクト・マネジャーはプロジェクト・チームが協力しあえる環境をつくり、自分も協力し、協力してもらえる体制を目指していくことが大切です。