しなくていい失敗を回避する『プロジェクトマネジメントの基本が全部わかる本』

プロジェクトマネジメント（PM）の重要性は、あまり認知されていないように見える。

うまく回っているときは「あたりまえ」扱いでスルーされ、いざ暗礁に乗り上げたときに「どうなってるんだ！？」と糾弾の的となる。

プロジェクトをうまく回していくコツというか勘所は確かにあり、相応のトレーニングが必要だ。にもかかわらず、なぜか蔑ろにされている。ろくに訓練もしないまま、「見て学べ」「やって覚えよ」と実践に放り込み、メンタルをやられず生き延びた者が幹部になる。

これは悪手だ。

よく、「失敗から学ぶほうがより身につく」などと唱える輩がいるが、しなくていい失敗は避けたほうがいいに決まってる。そして、この「しなくていい失敗」のほとんどは、基本を押さえるだけで回避できる。

この、PMの基本を押さえているのが本書だ。

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

ここでは、本書で紹介されている「しなくていい失敗」と「それを回避する技」を合わせて紹介していく。これらが「あたりまえ」と見えるなら本書は不要だろうが、もっと知りたいのであれば、ぜひ手に取ってほしい。

要件が膨らみすぎて爆発する

要件定義を詰めていくとき、発注者の「アレがしたい」「この機能を入れたい」という言い分を丸のみして、身動きが取れなくなる。

もちろん発注者の要求なので尊重するべきだが、それを受け入れることで、品質・コスト・納期（QCD）に影響が出てくる。どれくらいの影響が出るかも含めて検討し、優先順位を付ける必要がある。どうすればよいか。

本書では、「要求と要件を分けよ」と説く。

つまりこうだ。発注者が言ってくることは、いったん「要求」として受け止める。そして、検討を進めることで「要件」に落としていく。具体的には、Excelなどで「要求」と「要件」のカラムを分けて、関係者に共有しながら検討を進めると、自然と切り分けが明確になっていく。

例えば、サイトをリニューアルするプロジェクトで、「パソコンやスマホでもスムースに見られるようにしたい」という要求は、要件として「レスポンシブデザインにする」となる。ポイントは、要求は「〇〇したい」という表現にして、要件は「〇〇する」という書き方にする。

重要なのは、発注者の言い分を、いったん「要求」として受け止める点にある。「要求」を持ち帰り、「この要求を要件に落とし込むのであれば……」という観点からプロジェクトメンバーと検討する。発注者は言い分を受け止めてもらったという印象を持つだろうし、メンバーは「要求は必ずしも要件ならず」と冷静に分析できる。

発注者の要求は、要件を決めるためのインプットであり、要件そのものではない。あたりまえのことなのに、両者をごっちゃにしている人は、結構いるように見える。

機能追加やスケジュール短縮のプレッシャーに負ける

思いつきレベルで機能追加が要求されたり、合意したはずの納期が短縮できないか圧力をかけてくる。発注者だけでなく、営業チームの連中や上司も思いつきでモノを言う。

もちろん一筋縄ではゆかぬ。適当にあしらうことが出来ればよいのだが、思いつきで言う連中に限って役職が上だったりするから一応は聞かねばならぬ。しかも、進捗会議の場で「アレ言ったよね」とプレッシャーをかけてくる。

その思いつきを受け入れるために、QCDのどこかに影響が出てくる。結果、プロジェクト全体で調整が必要となると、他ならぬ言い出しっぺが「それは聞いていない」と騒ぎ出す。非常によくある話だ。どう対処すればよいか。

これに対して本書は、「発注者は、自分の要求がプロジェクト全体にどのような影響を与えるかという視点を持っていない」と説く。これ、あたりまえのことなのだけど、見過ごされやすい。

要件定義をした後に機能追加を要求してきたり、たとえ一部でも前倒しの要望を出してきたとき、コストやスケジュール全体に影響が出る可能性を言っておく必要がある。

すると、どの程度のコスト増なのか、スケジュールへのインパクトがどれほどなのかといった質問が二の矢で来るだろう。だが、それを調べるためにも、それなりの時間がかかる。即答できないからといって、微々たるものである理由にはならない。

発注者の口頭ベースのプレッシャーに対し、エビデンスを残す。要求に対するプロジェクトへの影響を整理し、ファクトベースで資料化する。落としどころを予め想定し、事前に社内で通しておく―――その上で、発注者と交渉する。

プロジェクトでは、変更のプレッシャーが来るのは当たり前だ。だが、プレッシャーを受け止めた上で、「要求を言うのは自由だが、それを要件として呑むとどうなるのか」これをハッキリ告げるのは、PMしかいない。

あたりまえのことなのだが、これをやらないと、「言った／言わない」の不毛な空中戦になる。土壇場でちゃぶ台をひっくり返されたり、社内の後ろから撃たれることになる。お客から罵倒されるのに慣れても、背中から撃たれるのは痛いぞ。

「請負契約しか通せない」と言われたとき

契約締結プロセスでよくある話。発注者が「社内の稟議、請負なら通せるんですけど、準委任は厳しいですね」と言ってくるやつ。あるあるすぎて草も生えぬ。

補足すると、「請負」とは請負契約のこと。期日までに完成品を納めることが契約となる（つまり、納期と仕様が決められた契約）。「準委任」とは準委任契約のことで、一定の期間に労務を提供する契約となる。

そして、請負契約には罠がある。

納期は「〇年〇月〇日」と誰が見ても明確であるにもかかわらず、仕様は「〇〇機能を実装する」みたいなふわっとした書き方となっている。仕様は、変更／追加／読替えリスクが常について回る一方、納期は動かない。

プロジェクトあるあるとして、ふわふわした仕様を確定させようとする一方、動かない納期までの残り時間がどんどん食いつぶされるパターンがある。あるいは、できあがったものを、「これは欲しかったものではない」と難癖つけられるパターンだ。

現実はもう少し巧妙で、「早く製造に着手したいだろ？仕様を確定させたくばこの機能を入れろ」とか「難癖つけて瑕疵扱いされたくないだろ？なら無償でこの機能を入れろ」と捻じ込んでくる発注者がいる。そいつの不幸を心から希うのはこの瞬間である。

そうならないために、本書では有用なポイントを挙げている。

まず、「成果物の定義」だ。納品するものを定義する。成果物として何を書くかによって、プロジェクト全体への負担が変わってくる。ふわふわ変わる要件や仕様をドキュメント化していたら、そこへの負担が大きくなる。

必要なのはサービスやプロダクトなのだからと割り切って、成果物としてソースコードのみを納品物として提出する形とする。仕様書や設計書は、あくまで合意を得るための「共有資料」として扱うのだ。

次に、「検収の定義」だ。できあがった成果物を、発注者が受け入れる検収というプロセスがある。結合テストが問題なく行われたかを確認したり、第三者機関による脆弱性テストを確認するといった「検収の条件」を決めておく。

契約書に詳細化されなくても、すくなくともプロジェクト計画書に取り込んで文書化しておく必要がある。これ超重要なんだけれど、痛い目に遭わないと思い知らない人が多すぎる。

まだまだあるが、残りはご自身で確かめて欲しい。

この紹介で「あるあるｗｗｗ」と笑える人には、本書は不要だろう。おそらく、ご自身が痛い目に遭ったか、そんな上司や先輩を見てきたかのいずれかだろう（というか、わたしがそうだった）。

わたし自身が酷い目に遭ってきたからこそ、なおさらこの本を薦めたい。ハマらなくていい罠は、予め回避できるのだから。

プロジェクトで転ばぬ先の一冊。