【「スゴ本」中の人が薦める】ITエンジニアなら知ってほしい。プロジェクトを炎上させないマネジメント術を身につける4冊

炎上したプロジェクトを鎮火する技術は既に書いたが、ここでは、そもそもプロジェクトを炎上させない技術を身につける4冊を紹介する。単に本の紹介だけでなく、プロジェクトをうまく回していくために使えるセリフと一緒に解説する。

 

• keyboard_arrow_down はじめに
• keyboard_arrow_down ご要望は承りました。要件として落とし込むために検討します
• keyboard_arrow_down ノー、それは我々の優先順位に合致していません
• keyboard_arrow_down あとどれだけ？（何日？／何時間？）
• keyboard_arrow_down ここが問題となっているところですね
• keyboard_arrow_down おわりに

問題。次のうち、どちらが重要？

1. 1. 炎上プロジェクトを鎮火する技術
2. 2. プロジェクトを炎上させない技術

修羅場における火消しの技術が1だ。燃え上がって墜落寸前のプロジェクトを制御して、なんとか胴体着陸まで持っていくノウハウである。

一方、プロジェクトを修羅場にさせない技術が2だ。そもそもそんな操縦不能に陥らせることなく、リスクが顕在化する前に発見し、手を打つノウハウである。

ベンジャミン・フランクリンの箴言「予防の1オンスは治療の1ポンドに優る」というように、炎上させない2のほうが大事に決まっている。問題が起きてから泥縄式に対応するよりも、トラブルにさせないよう予め手を打っておくほうが安あがりだ。

そう思うだろ？
だが、現実は違う。

問題プロジェクトは経営層の関心を引き、鎮火のためエース級の人材が投入される。燃え上がる火の粉は関連部署に降りかかり、全社的にも注目の的となる。そんな状況で失速を立て直し、どんな形であれ終結にまで持っていけたら御の字だ。そんなスキルや経験を持つ人は重宝されるに違いない。事実、幹部に上がるのは、そうした修羅場の生き残りがほとんどである。

一方、うまくいくプロジェクトは目立たない。品質は問題なく、納期を守り、変更要求はバッファの中で対応し、予算通りに完成しても、淡々と事務処理されるだけだ。問題を顕在化させないための様々な努力や工夫は、「ごくろうさま」の一言でスルーされる。「問題なくクリアした」という成果は、成果として見なされない。

見た目が派手で上司ウケするのはもちろん1だろう。だが、現場の人間にとって有難いのは2だ。

1の、炎上を鎮火する技術は、「実際の炎上プロジェクトを通して学ぶ。ITエンジニアが修羅場をシミュレートできる3冊＋α」に書いた。

この記事では、2の「そもそも修羅場にさせないノウハウ」を紹介する。

プロジェクトをうまく回していくコツというか勘所は確かにある。トレーニングを積めば、誰でも習得可能だ。にもかかわらず、2のスキルへの投資は蔑ろにされがちだ（そういうスキルがあるということすら、知らない人がいる）。

ここで紹介する良書を読んでもらうのが一番なのだが、せっかくなので、その書籍から得られるエッセンスを、実際に使われる問答として解説する。

普段から何気なく使う一言だったり、必殺の一撃として取っておく言刃（ことば）だったり、使いどころは様々だ。だが、どれも実践的で、すぐに使えるので、ぜひ覚えておいてほしい。

炎上プロジェクトあるあるとして、「膨らみすぎた要件を取り込めず爆発四散する」というのがある。

膨れ上がる要件について、普通なら優先順位を付けたり、場合によっては次バージョンでの実装にするなど、切り分けが必要だ。

だが、そういう采配の必要性を認識してなかったり、要求をゴリゴリ押してくる顧客だったりすると、黄信号が灯る。これは顧客に限らない。上司や営業が安請け合いしてきて、「お客さまのご要望だから、できないという返事はできなかった」なんて開き直る場合もある（殺意を感じる）。さらに、全部やらなきゃ、という真面目な（律儀な？）エンジニアだと、しゃにむに実現しようとする。

当然できるはずもなく、予算超過かスケジュール遅延という影響が出てくる。さもなくば、エンジニアが無理をして身体を壊したり、そのプロジェクトを乗り切ってたとしてもメンタルをやられて退職するというパターンもある。

膨れ上がる要件を、炎上させないために、どうすればよいか？

『プロジェクトマネジメントの基本が全部わかる本』橋本将功 著、翔泳社

『プロジェクトマネジメントの基本が全部わかる本』では、この問題について、「要求と要件を分けよ」とある。

「要求」とは、顧客が言ってくる「あれがしたい」「これがしたい」である。要望と言い換えてもいい。ふわふわした思いつきもあれば、きちんと仕様化されたものもあるが、あくまで顧客の要望だ。

一方、「要件」とは、プロジェクトで実装すべき機能や性能となる。開発するシステムが具備する機能要件や、性能やデザインといった非機能要件があるが、いずれであれ実現する対象となる。

ポイントは、「要求」と「要件」は似てたり重なっていたりしても、分けて記述して、分けて説明せよというところにある。

具体的には、Excelなどで表をつくるとき、「要求」と「要件」のカラムを別にして、それぞれを記述していく。顧客の言い分は「要求」のカラムに記載する。それぞれの要求に対し、どんな機能で実現するかを、「要件」のカラムに書くのだ。

わざわざ見出しを分けるのは、顧客の「あれがしたい」と、プロジェクトへの影響を分けて考えるためだ。顧客の言い分を「要求」としていったん受け止める。その上でメンバーと一緒に機能を検討していく。

そうすることで、顧客は言い分を聞いてもらったと感じるだろうし、メンバーは「要求は必ずしも要件ではない」と冷静に分析できる。あるいは、「この要求を要件にするうえで、何が足りないか、どういう条件が付くか」といった発想で考えることができる。

要求と要件は違う。これ、基本的なことなのだが、分かっていない人が結構いる。そして、この基本がズレていることで、炎上の火種がばらまかれている。このズレを入れ込まないようにするために、こうした表現をチームに浸透させよう（要求という言い方がキツいと思うなら、「ご要望」のようにマイルドな表現にしてもいい）。

• ・いただいたご要望を実現するために必要な機能は、次の通りです
• ・ご要望を機能に落とし込むための前提を整理しました
• ・どんな機能が実装されると、そのご要望を満たせるのか、詰めさせてください（要求が曖昧な場合）

『プロジェクトマネジメントの基本が全部わかる本』は、こうした「あたりまえ」のことが丁寧＆具体的に説明されている。経験者が読めば、「なぜこんな当然のことを書くのだろう？」と疑問に思うかもしれない。だが、その「あたりまえ」をやらなかったために、数々の炎上があったのだ。

修羅場の火種は要件定義に限らない。

例えば、想定外の事象によるスケジュール遅れを取り戻すためのタスク調整の必要が出てくる（新型感染症の影響は、以前は想定外の扱いだったが、これからは変動要素として予め織り込んでおく必要がある）。

あるいは、軽微なものから深刻なものまで種々雑多なバグに取り組まねばならぬ（しかもそれが軽微なのか深刻なのか、すぐには分からないものもある）。取り組みが後手に回ると、問題はすくすくと成長し火種となる。

火種のないプロジェクトは存在しない。火種は、品質、予算、スケジュールの全てに燃え移る可能性がある。成果そのものに影響を与えるクリティカルものから、メンバ限定の30分のミーティングで対応できるものまで、様々だ。

問題を来た順に処理しようとしても、その量に圧倒される。いずれメンバーの誰かにしわ寄せが行ったり、スケジュール的に無理があることが手遅れになってから明らかになったり、品質が致命的であることに気づかないまま納品したりする。プロジェクトマネージャー自身が過労で倒れることだってある。

では、そういう問題にどう対応するのか？

『アート・オブ・プロジェクトマネジメント』Scott Berkun 著、村上 雅章 訳、オライリー・ジャパン

そんなとき『アート・オブ・プロジェクトマネジメント』が頼りになる。

著者はマイクロソフトで巨大なプロジェクトをいくつも成功させてきた人物だ。彼が惜しみなく開陳する「プロジェクトマネージャーとしての考え方」は、これからあなたが出会うかもしれない問題に、きっと役に立つ。

その中で最も役に立ったのは、この言葉だ。

あなたが「ノー」と言う時に、ものごとが成し遂げられる。

プロジェクトが抱える様々な問題が、解決に向けて前進する瞬間は、プロジェクトマネージャーが「ノー」という時だ。

言い換えるなら、プロジェクトマネージャーが「ノー」と言わなければ、優先順位は決定できない。「するべきこと」と「やったほうがいいこと」「しなくていいこと」を分けて、どのリスクを負うのか決めて、誰がそれを引き受けるのかを判断し、指示する。これらの仕事の中で、全て「ノー」と言うべき瞬間が待っているのだ。

「何かを優先してする」ということは、それ以外のものをやらないでおくことに等しい。優先するリストがその優先順になっている理由を説明する責任は、プロジェクトマネージャーにある。もちろん、なぜ「ノー」なのかも説明する責任もある。だが、その上で、「ノー」というときにこそ、問題の火種は消し止められる。

本書には、「ノー」の言い方まで紹介されている。

• ・「ノー、それは我々の優先順位に合致していません」
  ・「ノー、時間ができた場合にのみ行います」
  ・「ノー、あなたが＜不可能なことをここに入れてください＞を行ってください」
  ・「ノー、次のリリースで考えます」
  ・「ノー、絶対ダメです」

「ノー」は強い言葉だ。使うのはキツいかもしれない。著者は、ブラウザの覇権争いの真っ只中の時代に、Internet Explorer（バージョン1～5）のプログラムマネージャーだった。ギリギリの状況でプロジェクトを進めるためには、「ノー」と言えることが必要だったのだ。

私はもう少しソフトな言葉に言い換えて、「厳しい」を使っている。例えばこんな風に。

客「これって結局、できるの？できないの？」

私「可能か不可能か、という言い方をするのであれば、可能です。ただそれは潤沢な資金と充分な時間がある場合になります。今はそうではないため、ご要望をそのまま実現することは非常に厳しいです」

客「『できない』言い訳を聞きたいわけじゃない。『どうすればできるか』それを考えるのが、あなたの仕事じゃないのか？」

私「先ほど申し上げましたように、『このままでは』難しく、できかねます。ご要望された機能の追加を優先するのであれば、現在進行中のクリティカルパス上にあるタスクに影響があるため、プロジェクト全体に響きます。対策としては、クリティカルパスにない〇〇のタスクの優先度を下げて、新たな要望を優先するか、あるいは、次のリリースでの実装を提案します」

客「〇〇のタスクの優先度は私の一存では決められない。他の案を考えてください」

私「既にこのご提案を検討するために、かなりの稼働を調整しております。この他の案を検討するのであれば、現在進行中のタスクと並走して進めていくのは、工数的に無理があり、現実的ではありません。そのため、全体のタスク進行をいったん止め、リリース全体を遅らせることとし、改めて検討した上で、ご提案させていただくことになりますが、よろしいでしょうか」

「難しい」「現実的ではない」「実現性をお約束できない」。言い方は色々あるが、プロジェクトマネージャーが「ノー」と言うとき、火種は消し止められる。

進捗会議などで、こんな会話はないだろうか。

問「このタスクの進捗はどれくらいですか？」
答「そうですね、およそ90％といったところですか」

そうか、全体の9割なんだから、もうすぐ完了するんだな……などと考えないように（地雷だよ）。残りの10％が全然進まず、次の回も、その次の回も「90％」のまま。この進捗率というのが曲者で、「予算を消化した割合」なのか「見積り作業量の達成度合い」なのか、様々だったりする。

おまけにその10％が進まないのは、単に仕事量の話ではなく、技術的なハードルだったりアサインできる人に依存していたりする。

クリティカルパス上に無いタスクにありがちなのだが、「おおむね順調」と判断されて、それ以上ツッコミされない。結果「90％」のタスクが蔓延して、クリティカルパスを浸食しはじめ、気づいた時には燃え始めていた……というパターンだ。

そうならないため、どうするか？

『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』VenkatSubramaniam,AndyHunt 著、木下史彦,角谷信太郎 監訳、オーム社

『アジャイルプラクティス』は、「進捗率」をでっち上げるのはやめろと説く。代わりに「あとどれだけ？」という言葉を使えという。

「あとどれだけ？／何日？／何時間？」という質問であれば、問われた方も、「あと〇日／〇時間です」と、今後の見通しを返すほかない。

プロジェクトは生物（いきもの）だ。時間が経つとどんどん成長していく。見積もり段階で40時間かかる作業が、35時間経過した時点で、さらに30時間かかりそうなことが分かった……なんてことはザラにある。

プロジェクトは生物（なまもの）だ。その「さらに30時間かかる」という見積もりは、見積もった時点の数字であって、スケジュールに反映させるのが遅くなればなるほど腐敗が進み、使い物にならなくなる。

だったら、分かった時点で「さらに30時間かかる」と正直に伝える。重要なのは、経過した時間ではなく、「あと30時間」の見通しのほうだ。

『アジャイルプラクティス』は、達人プログラマーが現場で培ってきた「うまくいく」経験則をまとめたものだ。本書が素晴らしいのは、うまくいくプロジェクトはプラクティス（習慣）であると主張する点にある。

タイトルに「アジャイル」とあるが、アジャイル開発に限らない。本来的な意味でのアジャイル（＝機敏）で、変化に素早く適応することを継続させていくための習慣……というぐらいに捉えてほしい。

そして、「あとどれだけ？」の回答が、最初の見積りを上回りそうな場合、続けてこう聞くとよい→「もし問題があるとするなら、それは何ですか？」。

たいていの進捗会議にはえらい人がいる。「問題」という言葉がセンシティブになりそうなら、「気になること」「懸念点」と言い換えてもいい。まだ「問題」と確定したわけではないけれど、進捗に響きそうなものがあれば教えてね、という姿勢だ。

技術的なハードルや、見積もり時には想定していなかったボトルネックがあるとするなら、ここで答えてくれるだろう。

本書はTOC理論（Theory of Constraints：制約条件の理論）を踏襲している。TOC理論は、パフォーマンスを妨げている制約条件を集中して改善することで、企業全体の業績を改善するマネジメント手法のことだ。本書はこれを応用し、プロジェクトを回していく上で制約となるものをいかに早期に発見し、対処していくかを、45のプラクティスに落とし込んでくれている。

日常的な取り組みで、積み重ねにより、あたりまえのように成し遂げられるものが習慣だ。「あたりまえだけど、重要な習慣」というものを、きちんと教えてくれる書籍は少ない。本書はその稀有な中の一冊である。

ここまで紹介してきた書籍は、どれも優れものだが、それなりにボリュームがある。おそらくあなたは、「何冊も読むのは大変なので、一冊でなんとかなる『まとめ』みたいなのが欲しい」と感じているかもしれない。

実はある。

プロジェクトをうまく回し、意図した成果をどのように達成していくかを体系的にまとめたスタンダードがある。プロジェクトを実施するアプローチは、ウォーターフォール、アジャイル、ハイブリッドを問わず適用でき、プロジェクトのみならず、ガバナンスやプロダクトの関連性にまで網羅している。

それは『PMBOKガイド』である。PMBOKは、「Project Management Body Of Knowledge」のことで、「プロジェクトマネジメントの知識体系ガイド」と訳されている。

『プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版＋プロジェクトマネジメント標準』PMI 著、PMI日本支部 監訳

元は軍事や宇宙開発などの巨大プロジェクトを動かしていくために必要な知識や手法をまとめたものから始まり、建設、製造、ソフトウェア開発など幅広いプロジェクトに適用できる国際的な標準となっている。

時代の変化を取り込み版数を重ね、2021年に第7版が世に出ている。新しさと網羅性を兼ね備えた、プロジェクトの教科書といっていい。

じゃあそれだけ読めばよいのでは？と思うだろうが、そうは問屋が卸さない。

他の書籍と比較すると、抽象度が少し高い。そのため、漫然と読むだけでは身についてこないだろう。「PMBOKは使えない」と文句を言う人がいるが、分かる。300ページに満たないボリュームで語ろうとすると、嫌でも抽象的にならざるを得ない。

例えば、「コンフリクトマネジメント」という節がある。

コンフリクト（対立）は、あらゆるプロジェクトにあり、QCDのどの条件からも起きうると書いている。コンフリクトを回避したくなるが、全てのコンフリクトが良くないとは限らない等々。その後、コンフリクトが激化する前に対処すると、より良い結果が得られるという。

そのまま読むと、あたりまえのことを普通に書いているだけなので、ピンと来ない。そのため、読み手は自分の経験に照らし合わせて具体化する必要がある。

今の「コンフリクト」を具体化するなら、「議論」とか「空中戦」と言うとピンと来るかもしれない。ある機能の品質に問題が見つかり、仕様書の不備が原因だというエンジニアと、レビュー時に指摘しなかったからと反論する発注側がいる。互いに非は相手にあるとして、口論がヒートアップしていく。

エンジニア：不備のある仕様書を出してきた発注側に問題あり
発注者：レビューで指摘できないエンジニアに問題あり

エンジニアは発注者に、発注者はエンジニアに問題ありとする。議論はこんな構図だ。

エンジニア　vs　発注者

オレのせいじゃない、オマエのせいだという堂々巡り。すごく頻繁にとてもよく見かける光景である。というか、激しさの多少はあれど、議論や空中戦は必ず起きる。

そんな時、どうするか？

コンフリクトマネジメントのアプローチがいくつかあるが、その一つである「人ではなく課題に焦点を当てよ」を適用すると、構図はこうなる。

品質の問題　vs　私たち

そして、「過去ではなく現在と未来に焦点を当てる」アプローチを加えると、構図はさらにこう変わる。

品質の問題にどう対処していくか　vs　私たち

私がよくやるのは、空中戦で飛び交うキーワードから、問題の構図に当てはめていく。ここでは「品質の問題にどう対処していくか」のヒントになりそうなものを、エンジニアと発注者の発言から拾い上げる。

例えば、エンジニアが「いまさら仕様書を直しても間に合わない」と述べたのなら、それを裏返して、時間が制約条件の一つにあると判断できる。

そして発注者が「異常系のパターンが仕様書にないのは、そんなに使われない機能だからだ」と言ったのなら、問題となっている機能の重要性を下げてよいか検討の余地があると推測する。

私たちは、〇〇機能の品質問題にどう対処していくか
→時間的な制約はどの程度あるか（そこから対応スケジュールを調整できるか）
→機能の利用頻度はどれくらいか（そこから取り組み対象や優先度を決められるか）
………………

問題の構造をテキストファイルに羅列して、「ここが問題となっているところですね」と共有する。対立する議論をそのまま並べるのではなく、いま取り組むべき問題に当てはめるなら、どう書き直せるか？という観点で表現を変える。

そうした上で、一緒に代替案を考えていく。ヒートアップの度合いによって、落としどころまでたどり着けないことがある。だが、「何が問題なのか」は明確になる。過去をほじくっても実りは少ないし、「アイツが悪い」と立証しても役に立たない。

他によく使うのは、このセリフだ。

• ・私たちが取り組むべき問題は何だろう？
• ・いま、違う問題をやろうとしてない？
• ・もし違っていたら教えてほしいけれど、これを解決すれば嬉しいんだっけ？

こんな風に、自分の経験と照らし合わせながら、PMBOKを読んでいく。すると、未経験の手法や考え方、アイデアが見つかってゆく。主唱者の名前やキーワードが記載されているから、あとは自分で調べて血肉化すればいい。PM経験者にとっては、宝が埋まっている一冊となるだろう。

では、PM初心者は？抽象的すぎて役に立たないだろうか？

そんなことはない。使い方次第だ。PMBOKガイドは、成果に導くための知識や手法が網羅されている。これをくり返し熟読することで、プロジェクトを上手く回していく考え方は、身につけることができる。

ただし、それが身についているのが分かるのは、現場で問題に直面したときや、重要な判断が求められたときになる。手法や知識がつながってゆき、「あれはこのことだったのか」という気持ちになるだろう。

プロジェクトを上手く回していくため、意図して使っているセリフとともに、4冊の書籍を紹介してきた。

『プロジェクトマネジメントの基本が全部わかる本』は、PM初心者向けの具体的なノウハウがまとまっており、「プロジェクトあるある」の初見殺しの罠は予習できる。なにより、何をどうしなきゃいけないかを、手取り足取り教えてくれる。

『アート・オブ・プロジェクトマネジメント』は、PM経験者向けにお薦めしたい。どのページを開いても上手く回すアイデアが詰まっており、「PMとは何か」の本質的な議論から、何かしらのヒントが得られることを請け負う。

『アジャイルプラクティス』は、PM、チームリーダー、エンジニアにとって、すぐに使える実践的なプラクティス集になる。どういう風に考え、口癖にして、習慣化していくと、上手く回せていけるかが身につく。拾い読みして、良さげなものを取り込んでいくのが効果的だろう。

『PMBOKガイド』は、オールマイティ―の究極の一冊といっていい。その分、抽象的に書かれているため、使い方に注意する必要がある。自分の経験と照らし合わせながら、「どんな考え方を背景にこのように書かれているのだろう？」と問題意識を持ちながら読むと、現実に直面したとき、答え合わせになる。

世の中に、「本を読むだけでは身につかない」という人がいる。言いたい気持ちは分かるが、読むだけで回避できる罠や、知っておくだけで役立つ手法なら、予習しておくに越したことはない。それでも頑なに「実践を経ない知識は血肉化しない」と主張するのであれば、ぜひご自身のキャリアで頑張ってほしい（かなり大変だろうし、時間がかかりすぎる）。

また、プロジェクトマネージャー向けの本の紹介に加え、エンジニアとしても使えそうなセリフも併せて解説した。「ご要望は承りました。要件として落とし込むために検討します」は、ごちゃごちゃ言ってくる顧客の牽制に使えるし、先行タスクを担っている人に「あとどれくらいかかりそう？」なんて応用が利くだろう。ぜひ活用してほしい。

炎上プロジェクトを鎮火させるPMは、ヒーローみたいに扱われる。だが、やるべきことを当たり前のようにやり、火種を消しつつゴールにまで持っていけるPMの方が、私には、ヒーローに見える。

良い本で、よいプロジェクトを。