プロジェクトマネージメントに潜む４つの地雷。その性質と対策とは！？

この記事は ユアマイスター Advent Calendar 2020 25日目の記事です。本日最終日！なんとか今年も最後まで走り切れましたね、みんなすごい！

こんにちは。@inase17000です。

今日はプロジェクトを進めていくと現れる４つの地雷について解説します。

これまで文字通り何百ものプロジェクトを実行してきた中で破壊力のあったものだけをピックアップしてお届けします。

もちろん地雷をそのまま放置しておいても、いつか誰かが気づかずに踏んで爆発するだけなので、経験が多少あるぼくが知りうる限りの対処方法や事前防止策についても書かせてもらいます。

普段プロジェクトをもっと円滑に回したい、これからプロジェクトリーダーとしてのキャリアを高めていきたい、そんな方の一助になればと思います。

背景

プロジェクトとは、期限、予算、体制が決まっていて、１つの目標を達成するための枠組みです。

ぼくだけではなく、先人たちが幾度となく取り組んできました。今も毎日多くの人が戦っているでしょう。

なにもシステム開発に限ったものではなく、物理的な建築構造物や例えばオリンピックのようなイベントにおいても、「プロジェクト」は当たり前に使われています。

このプロジェクトをうまくなんとかする王道的なアプローチは、PMBOKなどの体系化された知識も参考にしてください。(ぼくは分厚い参考書を全て読みきることができませんでした)

冷戦時代の米国が体系的にプロジェクトのスピードを上げるために研究した結果が現在のプロジェクトマネージメントの礎になっているそうです。

そんな感じで、先日、社内メンバーとプロジェクトの誕生から終焉までのフローを見直し、組織的に最適化を図ろうと話し合っていた時に、「プロジェクトを進めていくと必ず現れる危険がいくつかある」と話したことがきっかけでした。

そこで触れた話を残しておくことで、今後のメンバーにも整理して伝えることができると思うので、筆をとりました。

特に危険なのものは4つある

さて、前置きが長くなってしまったので、本題に入るとします。

今回紹介するのは、過去にぼくがプロジェクトを推進する中で出会った危険な4つの地雷です。

・「そもそも」地雷
・「とはいえ」地雷
・「じつはさ」地雷
・「やっぱり」地雷

どれも何故だか決まってプロジェクト後半にひょっこり顔を出します。それまでに息を潜めていて、必ずと言っていいほど時限式でした。

今回はひとつずつ紹介していこうと思います。皆さんも未然にこれらの地雷を防げるように備えあれば憂いなしでありましょう。

「そもそも」地雷

「そもそもさ、この機能いるんだっけ？」
「そもそも、これやってるのなんでだっけ？」

人は簡単に不安になる生き物です。人間だもの。

ステークホルダーを集め、一度ちゃんと確認をとったのにも関わらず、議論を蒸し返すことができるスペシャルカードが「そもそも」地雷です。

これがプロジェクト終盤の会議で出始めるとかなりの爆発力を持ちます。不安は人から人に伝わり、相当に強い信念をもった人やリーダーシップのある人がないと爆発に全員巻き込まれることになります。

不安からくる言葉であればまだいい方で、実際想定外の考慮漏れから起きるクリティカルなミスに気づいたときは、（味わったことがある人しかわからない）冷たい汗が流れます。

一人で考えたり作ったりできるものは限定的です。チームで解決する方法を仕組みとして用意し、うまく防ぐような動きが肝要です。

例えば、後戻りできない Point of No Return の設定を事前に設定し、ステークホルダーで共通認識を持っておくのが有効です。

考えられる対応策
・プロジェクトキックオフでフォーマット化し抜け漏れを防ぐ
・ステークホルダーへの事前共有を行う、後戻りできないマイルストーンを設定する

「とはいえ」地雷

「とはいえ、こちらを優先していこう」
「とはいえ、承服しかねる話です」

納得しているようで実は納得していない上で、強引に結論に着地させる高等技術です。

ついつい口にしてしまうことがあるのではないでしょうか。

こちらの話に耳を傾けてくれている点はすごくありがたいのですが、耳に入った瞬間ゴミ箱に捨てているのではないか、という切なさも持ち合わせています。

そんな思いをしないようにするには、そう、ちゃんと説明し、ちゃんと一歩ずつ進めるのがいいとおもいます。

論理の飛躍がないようにロジカルシンキングやわかりやすいプレゼンテーションのトレーニングをするのも有効的でしょう。（日々鍛錬）

コップの水が一杯になってからこの地雷に出会うのではなくて、繊細に状況を確認しながら進めるのが大事ですね。

考えられる対応策
・ステークホルダーに細かな理解確認、意思確認を行う
・いきなり100点の結論を出そうとせず、スモールテストから始める
・徐々に改良し成功事例を集めながら論拠を作る

「じつはさ」地雷

「じつはさ、始めからこっちの方がいいと思ってたんだよね」
「じつはさ、明日までなんだよね」

仲間と思っていた人が、時に、最も残酷な凶器に変貌する時があります。え、そこでそれ言う？って思ったことありませんか？w

よく「はしごを外す」という表現のしかたをされることもありますが、①自分が知らないことを教えてくれる善意パターンと②後から伝えて困らせようとする悪意パターンの２つがよく見てきたものです。

いずれにせよ、最初から言ってよーという気持ちにはなるんですが、それは言った方が得な環境を作れていれば解決した話かもしれません。

プロジェクトを任せられた瞬間から戦いははじまっているのです。まずはステークホルダーとプロジェクトメンバー全員と関係を築くことが大事でしょう。

ただし、飲みにいって仲良くなれという話ではなく、
・経営陣やリーダー陣とはプロジェクトの目的や背景など抽象度の高い話をしっかりすること
・プロジェクトメンバーにもそれをしっかり伝え意義を感じながらプロジェクトに取り組めるようにすること
・具体的なレベルでの課題や解決策の話をメンバーと定期的に膝を突き合わせてすること
など、相手にあわせた議論内容や詳細度に揃えながら情報の非対称性をできる限り取り除くための地盤固めが重要だという意味です。

考えられる対応策
・具体⇄抽象のレベルをあわせたコミュニケーションをする
・エスカレーションフローの設計
・日頃の雑談大事、心理的安全なチームへ
・オープンコミュニケーションにした方が得するルール、仕組みを作る

「やっぱり」地雷

「やっぱりこっちがいいから、変更しよう」
「あの時の話、やっぱり納得いかないんだ」

「じつはさ」地雷と似てるようですが違いがあります。それは隠し球ではないということ。

相手の人はずーっと異議を主張してきたのです。多かれ少なかれ反対意見を言ってきたに違いありません。

その上で、迷ってるにもかかわらず、プロジェクトは走らせたまま時間を過ぎさせ、プロジェクトが乗ってきたところで混迷の淵へ誘います。

ただし、状況が変わり、前提が変わった時には、地雷と決めつけず、救世主として捉える視野の広さは持っておきましょう。実は自分だけが気づいていないだけでゲームルールが変わっていることがあります。

プロジェクトをはじめる段階で、あらかじめ変化を許容することをチーム全体で共通認識をもっていくことも大事でしょう。定例のMTGやイベントで定期的にふりかえりとズレがないかのチェックをすると早い段階で言い出してもらえる確率があがります。

考えられる対応策
・意思決定の根拠を言語化、見えるところに置く
・チームのルールを定義、言語化、見えるところに置く
・変化を許容するタイミング、頻度を限定する

以上の地雷を全て組み合わせると必殺技になります。

「じつはさ、ずっと考えてたんだけど、そもそも考え方が違うと思うんだよね。やっぱり、全部作り直した方がいいんじゃないかな。とはいえ、現実的ではないだろうから無理だよねえ。。。」

何か言ってるようで何も言っていない。。。このままじゃ、プロダクトもプロジェクトも１ミリもよくならない。僕はそういう時間をできるだけ少なくしたいなあと思っています。

人間は情報がたくさんあっても迷うだけ

これら４つの地雷は今になって思うと、不確実性コーンの話とリンクしてるという気づきがあります。

引用：エンジニアリング組織論への招待（広木大地著）

不確実性コーン
不確実性コーンとは...プロジェクトが進んでいくと、工数の見積もりのばらつきがどのように推移していくのかを、横軸を時間、縦軸をプロジェクト規模（工数・スケジュール）として、左から右にだんだんと幅が狭くなっていくという右向きに尖りのある図となります。

プロジェクト開始時には、全ての情報が揃うことはないので見積もりには誤差が生じます。裏を返せば、プロジェクト後半に進むにつれて情報が揃っていき、見積もりが正確になっていくことが予測されます。

情報が不足していれば、人間は実験的な意思決定を短いサイクルで繰り返し、最適を模索するアプローチを取りたくなるのはすごく納得がいきます。実際、ぼくが所属するユアマイスターでもアジャイルなやり方が一番合っていると思いますし、スピード感を大事にするために日夜研究を繰り返しています。

意外だったのは、情報の不足が解消され複数の選択肢が現れてきた時に、なぜか人はその最適化サイクルを遅らせるような行動をとることがある、ということ。そしてトリガーになっているのは往々にして、欲や不安からくる個人の主観的な判断である、ということです。

今回紹介した話は、プロジェクトを進める上で絶対に出てきてはいけないものではありません。むしろ真剣に目標を達成しようとした仲間が揃ったプロジェクトで喧々諤々と議論を重ねれば自然と出てくるものばかりだと思います。

重要なのは、その時に地雷発言を認知できるか、そして冷静に対処できるか、ということですね。間違っても、目をつぶったり、焦って間に合わせの対応だけで済ませてはなりません。本質的な課題から目を背けずに、受け止めて仲間たちとそのプロジェクトの正解を探すことがまずやるべきことです。

以上です。