あなたがいま関わっているプロジェクトは、統計的に見れば、成功より失敗に近い場所にいる。橋本将功さんの『プロジェクトマネジメントの基本が全部わかる本』は、その不都合な現実を冒頭で突きつけてくる。
国際調査「CHAOS 2020」によればITプロジェクトの成功率はわずか31%。日経SYSTEMSの調査に至っては、9割を超える現場が深刻な失敗を経験し、そのうちの大半が同じ失敗を繰り返しているという。
不思議なのは、優秀な人材がそろっているのに炎上が止まらないことだ。著者はこの矛盾を、個人の能力の問題ではなく「進め方」の問題として引き取る。
22年間で500件を超えるプロジェクトを渡り歩いた実務家が、交渉・契約・要件定義・テスト・リリース後の改善までを一枚の地図に落とし込んだ、いわば現場の生存マニュアルだ。
資格試験の教科書ではなく、明日の会議でそのまま使える手順書として書かれている点に、この本の性格がよく出ている。
PMの本質は「球拾い」——権力ではなくスキルで人を動かす
本書でいちばん印象に残るのは、プロジェクトマネジメントの定義そのものだ。橋本さんはこれを、飾らずこう言い切る。「プロジェクトマネジメントとはなにか。
一言でいってしまうと、球拾いです」。メンバーが気持ちよく働けるよう、先回りして障害やリスクを取り除いていく地道な作業——それがPMの正体だという。
花形の司令塔ではなく、むしろ裏方の雑用に近い。
この定義には、二つのスタイルの対比が下敷きになっている。権力を振りかざして細部まで指示を出す「ストロングスタイル」と、体系化されたスキルでリスクを制御する「プロフェッショナルスタイル」だ。
「金を払うほうが偉い」「役職が上の言うことが正しい」という価値観は、不都合な事実の隠蔽や無理な計画の強行を生む。だから複雑さの増した現代のプロジェクトには、権力ではなくスキルで人を動かすやり方が向いている、と著者は説く。
そのうえでPMの役割は「プロジェクトとメンバーを守る」ことだと定義される。自己犠牲でもなく支配でもなく、実力でチームを守るという姿勢が、本書全体を貫く背骨になっている。ここで編集部として一つ補助線を引いておきたい。
「球拾い」という比喩は謙虚さの表明であると同時に、権限のないPMが現場で潰されないための護身術でもある、という点だ。守るためには、しばしば上位者に「ノー」を言う胆力が要る。
その具体的な作法が、次の交渉論につながっていく。
QCDはトレードオフ——「全部必達」がプロジェクトを追い詰める
そもそもプロジェクトとは何か。橋本さんは「いまある状態」を「あるべき状態」へ変える、始点から終点までの業務のかたまりだと定義する。工場のルーチンワークと決定的に違うのは三つの特性だ。
第一に、明確な期限がある。第二に、不確定要素が多く、予測できない事態が起きやすい。第三に、立場も専門性も異なる人々の分業で成り立つ。だからプロジェクトを既製品を「買う」ように扱った瞬間、話がこじれる。
この三特性を測る物差しがQCD、すなわちQuality（品質）・Cost（コスト）・Delivery（納期）である。ここで著者が繰り返し強調するのが、三つがトレードオフの関係にあるという事実だ。
品質を上げればコストか納期に響き、どれか一つを動かせば必ず他が動く。三つすべてを「必達」にした瞬間、調整の余地は消え、プロジェクトは逃げ場を失って追い詰められる。だから開始時点で優先順位を関係者と合意しておく——この一手を省くかどうかで、後の炎上確率は大きく変わる。
当たり前に聞こえて、実際の現場でいちばん飛ばされがちな工程でもある。
「丸投げ」と「ざっくり見積り」が炎上を生む
プロジェクトを貫くスキルとして、本書は交渉とタスクマネジメントの二つを挙げる。交渉と聞くと相手を言い負かす技術を想像するが、著者の交渉論はむしろ逆だ。
発注者と受注者、役職の上下を越えて対等なパートナーシップを築くことが出発点になる。相手が誰であろうと是々非々、つまり「よいことはよい、悪いことは悪い」で臨み、無理な要求には事実ベースで「無理です」と伝える。
「言った・言わない」を防ぐため重要な合意は議事録に残し、それを盾に身を守る。会社間の交渉に出る前に必ず社内で方針を固めておく、という順序も念押しされている。
ここを怠るとPMが一人で矢面に立たされるからだ。
タスクマネジメントで強く戒められるのが「丸投げ」である。「これ作っておいて」と作業だけ渡すと手戻りが起きる。原因は担当者へのインプット不足だから、依頼時には手順だけでなく「なぜ必要か」という目的と背景をセットで渡す。
もう一つの落とし穴が期限の決め方だ。「今週中に」と期間で区切るのではなく、「何時間かかるか」という工数で見積もり、それを積み上げてからスケジュールを組む。
この流れで橋本さんは、日本の現場で愛用されるガントチャートに疑問を投げる。横棒を並べると計画らしく見えるが、タスクの抜け漏れに気づきにくく、締切直前まで着手しない「学生症候群」を招きやすい、という指摘だ。
代わりに勧めるのがクリティカルパス法——全体の納期に直結する作業経路を見つけ、そこを最優先する考え方である。ガント批判はやや強めで、現実には併用が落としどころだと編集部は見るが、「見た目の安心感」に流されるなという警告として受け取ると効く。
見積りについても、経験者ほど「ざっくりこれくらい」と即答しないという指摘が刺さる。その場の数字が独り歩きして既成事実になるからだ。要件定義前の「概算見積り」と設計後の「詳細見積り」を分け、予算には1.2〜1.5倍のバッファを持たせておく。
加えてチームを継続的に底上げする仕組みとして、Keep（よかったこと）・Problem（課題）・Try（次にやること）を定期的に洗い出すKPTも紹介される。
進捗の確認だけで終わらせず、働きやすさそのものを改善の対象に含めていく発想で、タスク管理を「締切の管理」から「チームの管理」へ広げる装置として読める。
失敗の半分は「要件定義」で決まる
本書が最重要と位置づけるのが要件定義だ。日本情報システム・ユーザー協会の調査では、QCDに影響した事象の原因のうち、要件定義が49.1%を占めていた。失敗のほぼ半分が、作り始める前のこの段階で仕込まれているというわけである。
カギは「要求」と「要件」を切り分けることだ。発注者が「実現したいこと」が要求、プロジェクトとして「実現すべきこと」が要件。「アプリを作りたい」をそのまま受け取らず、何を作るべきかへ翻訳する。
著者はここでヘンリー・フォードの「顧客に聞けば『もっと速い馬が欲しい』と答えた」という逸話を引き、要求を鵜呑みにしても正解は出ないと釘を刺す。
もう一つのコツが図解だ。言葉だけで進めると、賢い人が集まっていても検討が抜け落ちる。目に見えないシステムほど、フロー図や概念図にして認識のズレを消しておく——地味だが効果の大きい実務知だ。
設計段階では技術的負債にも触れつつ、完璧主義には釘を刺す。ザッカーバーグの「Done is better than perfect」が引かれ、やりきることは完璧に勝ると背中を押す。
テストは「欠陥がある」ことしか示せない
テストのフェーズで、本書は常識を静かにひっくり返す。橋本さんは「テストは『欠陥がある』ことしか示せない」と言う。テストでバグが見つかることはあっても、「バグがない」ことは原理的に証明できない。
現代のソフトウェアは組み合わせが爆発的に増えるほど複雑で、全パターンの検証は不可能だからだ。本書が引く日本科学未来館の例では、2×2マスの道順は12通りだが、6×6マスでは5億通りを超えるという。
だからテストの目的は「完璧の証明」ではなく、欠陥を早く見つけてリスクを下げることに切り替わる。IPAの調査ではテストは開発全体の3割程度の工数が適切とされ、ここを削ると事業リスクが跳ね上がる。
発注者に安易に削らせてはいけない、という現場感覚が添えられている。加えてパレートの法則どおり、不具合の8割は2割のプログラムに集中する。やみくもにではなく、あたりをつけて潰す。
そして著者が最後に置くのは「空気」の話だ。バグを個人の責任にすると隠蔽が始まる。責任の追及ではなく対策の追求で臨む——テストの技術論を、最終的にチームの心理的安全へ着地させる筆致が本書らしい。
リリースはゴールではなく、事業のスタート
本書のもう一つの主張は、プロジェクトは「つくって終わり」ではない、という点にある。リリースにはトラブルがつきものだ。この前提を関係者で共有しないまま強行すると、事業に深刻な被害が出る。
だから緊急時対応計画を用意し、問題が起きたら元に戻すロールバックの判断基準を、事前に共有しておく。
そしてリリースはゴールではなく、事業としてのスタート地点にすぎない。初期開発に成功しても、その後の運用や改善に投資しなければ事業は失敗する。
2017年の中小企業白書では、71%の企業が新規事業に失敗したと答えているという。保守改善のフェーズでは固定費・変動費・損益分岐点を意識し、顧客が「認知」から「購入」へ至る流れを漏斗に見立てるファネルモデルで、どこで人が離脱しているかを見つけて改善していく。
プロジェクトを事業の成長へ接続する視点だ。
読み終えて残るのは、PMは英雄ではない、という感覚である。権力で押し切るのでも、自分を犠牲にするのでもなく、地味に球を拾い続けてプロジェクトとメンバーを守る。
その積み重ねが成否を分ける。ページ数のわりに扱う範囲が広く、一つひとつの手法は入り口の紹介にとどまる場面もある。だが「全部わかる」という書名どおり、プロジェクトの全体像を最短で見取り図にできることが、この本のいちばんの価値だ。
まずは、自分がいま関わっている仕事が全体のどのフェーズにいるのか——そこを一つ確かめるところから、この本は役に立ちはじめる。