『プロジェクトマネジメントの基本が全部わかる本』橋本将功さん｜プロジェクトマネジメントは「球拾い」である

あなたがいま関わっているプロジェクトは、統計的に見れば、成功より失敗に近い場所にいます。橋本将功さんの『プロジェクトマネジメントの基本が全部わかる本』は、その不都合な現実を冒頭で突きつけてきます。

国際調査「CHAOS 2020」によればITプロジェクトの成功率はわずか31%。日経SYSTEMSの調査に至っては、9割を超える現場が深刻な失敗を経験し、そのうちの大半が同じ失敗を繰り返しているといいます。

不思議なのは、優秀な人材がそろっているのに炎上が止まらないことです。著者はこの矛盾を、個人の能力の問題ではなく「進め方」の問題として引き取ります。

22年間で500件を超えるプロジェクトを渡り歩いた実務家が、交渉・契約・要件定義・テスト・リリース後の改善までを一枚の地図に落とし込んだ、いわば現場の生存マニュアルです。

資格試験の教科書ではなく、明日の会議でそのまま使える手順書として書かれている点に、この本の性格がよく出ています。

PMの本質は「球拾い」——権力ではなくスキルで人を動かす

本書でいちばん印象に残るのは、その定義そのものです。橋本さんはこれを、飾らずこう言い切ります。「プロジェクトマネジメントとはなにか。一言でいってしまうと、球拾いです」。メンバーが気持ちよく働けるよう、先回りして障害やリスクを取り除いていく地道な作業——それがPMの正体だといいます。

花形の司令塔ではなく、むしろ裏方の雑用に近いです。

この定義には、二つのスタイルの対比が下敷きになっています。

「金を払うほうが偉い」「役職が上の言うことが正しい」という価値観は、不都合な事実の隠蔽や無理な計画の強行を生みます。だから複雑さの増した現代のプロジェクトには、権力ではなくスキルで人を動かすやり方が向いている、と著者は説きます。

そのうえでPMの役割は「プロジェクトとメンバーを守る」ことだと定義されます。自己犠牲でもなく支配でもなく、実力でチームを守るという姿勢が、本書全体を貫く背骨になっています。ここで編集部として一つ補助線を引いておきたいです。

「球拾い」という比喩は謙虚さの表明であると同時に、権限のないPMが現場で潰されないための護身術でもある、という点です。守るためには、しばしば上位者に「ノー」を言う胆力が要ります。

その具体的な作法が、次の交渉論につながっていきます。

QCDはトレードオフ——「全部必達」がプロジェクトを追い詰める

そもそもプロジェクトとは何か。橋本さんは「いまある状態」を「あるべき状態」へ変える、始点から終点までの業務のかたまりだと定義します。工場のルーチンワークと決定的に違うのは三つの特性です。

期限

明確な期限があります

不確定要素

多く、予測できない事態が起きやすいです

分業

立場も専門性も異なる人々の分業で成り立ちます

だからプロジェクトを既製品を「買う」ように扱った瞬間、話がこじれます。

この三特性を測る物差しがQCD、すなわちQuality（品質）・Cost（コスト）・Delivery（納期）です。ここで著者が繰り返し強調するのが、三つがトレードオフの関係にあるという事実です。

品質を上げればコストか納期に響き、どれか一つを動かせば必ず他が動きます。だから開始時点で優先順位を関係者と合意しておく——この一手を省くかどうかで、後の炎上確率は大きく変わります。

当たり前に聞こえて、実際の現場でいちばん飛ばされがちな工程でもあります。

「丸投げ」と「ざっくり見積り」が炎上を生む

プロジェクトを貫くスキルとして、本書は交渉とタスクマネジメントの二つを挙げます。交渉と聞くと相手を言い負かす技術を想像しますが、著者の交渉論はむしろ逆です。

発注者と受注者、役職の上下を越えて対等なパートナーシップを築くことが出発点になります。相手が誰であろうと是々非々、つまり「よいことはよい、悪いことは悪い」で臨み、無理な要求には事実ベースで「無理です」と伝えます。

「言った・言わない」を防ぐため重要な合意は議事録に残し、それを盾に身を守ります。会社間の交渉に出る前に必ず社内で方針を固めておく、という順序も念押しされています。

ここを怠るとPMが一人で矢面に立たされるからです。

タスクマネジメントで強く戒められるのが「丸投げ」です。「これ作っておいて」と作業だけ渡すと手戻りが起きます。原因は担当者へのインプット不足だから、依頼時には手順だけでなく「なぜ必要か」という目的と背景をセットで渡します。

もう一つの落とし穴が期限の決め方です。「今週中に」と期間で区切るのではなく、「何時間かかるか」という工数で見積もり、それを積み上げてからスケジュールを組みます。

この流れで橋本さんは、日本の現場で愛用されるガントチャートに疑問を投げます。横棒を並べると計画らしく見えますが、タスクの抜け漏れに気づきにくく、締切直前まで着手しない「学生症候群」を招きやすい、という指摘です。

代わりに勧めるのがクリティカルパス法——全体の納期に直結する作業経路を見つけ、そこを最優先する考え方です。ガント批判はやや強めで、現実には併用が落としどころだと編集部は見ますが、「見た目の安心感」に流されるなという警告として受け取ると効きます。

見積りについても、経験者ほど「ざっくりこれくらい」と即答しないという指摘が刺さります。その場の数字が独り歩きして既成事実になるからです。要件定義前の「概算見積り」と設計後の「詳細見積り」を分け、予算には1.2〜1.5倍のバッファを持たせておきます。

加えてチームを継続的に底上げする仕組みとして、KPTも紹介されます。定期的に次の3点を洗い出します。

Keep

よかったこと

Problem

課題

Try

次にやること

進捗の確認だけで終わらせず、働きやすさそのものを改善の対象に含めていく発想で、タスク管理を「締切の管理」から「チームの管理」へ広げる装置として読めます。

失敗の半分は「要件定義」で決まる

本書が最重要と位置づけるのが要件定義です。日本情報システム・ユーザー協会の調査では、QCDに影響した事象の原因のうち、要件定義が49.1%を占めていたというわけです。

カギは「要求」と「要件」を切り分けることです。発注者が「実現したいこと」が要求、プロジェクトとして「実現すべきこと」が要件。「アプリを作りたい」をそのまま受け取らず、何を作るべきかへ翻訳します。

著者はここでヘンリー・フォードの「顧客に聞けば『もっと速い馬が欲しい』と答えた」という逸話を引き、要求を鵜呑みにしても正解は出ないと釘を刺します。

もう一つのコツが図解です。言葉だけで進めると、賢い人が集まっていても検討が抜け落ちます。目に見えないシステムほど、フロー図や概念図にして認識のズレを消しておく——地味ですが効果の大きい実務知です。

設計段階では技術的負債にも触れつつ、完璧主義には釘を刺します。ザッカーバーグの「Done is better than perfect」が引かれ、やりきることは完璧に勝ると背中を押します。

テストは「欠陥がある」ことしか示せない

テストのフェーズで、本書は常識を静かにひっくり返します。橋本さんは「テストは『欠陥がある』ことしか示せない」と言います。

現代のソフトウェアは組み合わせが爆発的に増えるほど複雑で、全パターンの検証は不可能だからです。本書が引く日本科学未来館の例では、2×2マスの道順は12通りですが、6×6マスでは5億通りを超えるといいます。

だからテストの目的は「完璧の証明」ではなく、欠陥を早く見つけてリスクを下げることに切り替わります。IPAの調査ではテストは開発全体の3割程度の工数が適切とされ、ここを削ると事業リスクが跳ね上がります。

発注者に安易に削らせてはいけない、という現場感覚が添えられています。加えてパレートの法則どおり、不具合の8割は2割のプログラムに集中します。やみくもにではなく、あたりをつけて潰します。

そして著者が最後に置くのは「空気」の話です。バグを個人の責任にすると隠蔽が始まります。責任の追及ではなく対策の追求で臨む——テストの技術論を、最終的にチームの心理的安全へ着地させる筆致が本書らしいです。

リリースはゴールではなく、事業のスタート

リリースにはトラブルがつきものです。この前提を関係者で共有しないまま強行すると、事業に深刻な被害が出ます。

だから緊急時対応計画を用意し、問題が起きたら元に戻すロールバックの判断基準を、事前に共有しておきます。

そして、初期開発に成功しても、その後の運用や改善に投資しなければ事業は失敗します。

2017年の中小企業白書では、71%の企業が新規事業に失敗したと答えているといいます。保守改善のフェーズでは固定費・変動費・損益分岐点を意識し、顧客が「認知」から「購入」へ至る流れを漏斗に見立てるファネルモデルで、どこで人が離脱しているかを見つけて改善していきます。

プロジェクトを事業の成長へ接続する視点です。

読み終えて残るのは、PMは英雄ではない、という感覚です。権力で押し切るのでも、自分を犠牲にするのでもなく、地味に球を拾い続けてプロジェクトとメンバーを守ります。

その積み重ねが成否を分けます。ページ数のわりに扱う範囲が広く、一つひとつの手法は入り口の紹介にとどまる場面もあります。ですが「全部わかる」という書名どおり、プロジェクトの全体像を最短で見取り図にできることが、この本のいちばんの価値です。

まずは、自分がいま関わっている仕事が全体のどのフェーズにいるのか——そこを一つ確かめるところから、この本は役に立ちはじめます。