イエローフラッグは早く上げろ。あるいは救済と罰
★プロジェクトマネージャーの悪夢
プロジェクトを管理していて一番怖いのは、積み上げてきたプロジェクト成果が実はクズだと判明すること。例えば、完成しているハズのプログラムが実はバグだらけで、使い物にならないとか。順調にいっていて、あとちょっとで終わると思っていた作業が、納期の直前になって全然終わりそうにないと判明する場合もある。
どちらのケースも、マネージャーや発注者（お客さん/プロジェクトオーナー）の目の届かないところで深く静かに問題が進行し、突然問題が明らかになる。そして、判明したときにはたいてい手遅れである。良くて納期遅延。最悪の場合はプロジェクト打ち切り。
こういうことを早めに察知するための能力として「ヤバイぞアンテナ」について以前紹介した。深く静かに進行する問題点をどうやって感じ取るか。
ただ、アンテナを磨くことは絶対に必要なのだが、超能力者じゃないんだから感度には限界があり、見落としがある。特にプロジェクトマネージャーが何度か成功体験を積み、慣れてきた頃が危ない。
じゃあ感覚に頼るのはやめよう、とカッチリ管理するのもなかなか問題が多い。やることなすこと上司に監視され、指図されることになってしまうからだ。上司の方も負荷が大きいが、一番問題なのはそうやって監視されると、だんだんと自分で何も考えなくなってしまうことだ。
★プロジェクトでは、ヤバイ状況が普通
もしあなたがやっている仕事がプロジェクトワークではなくルーティン業務なら、ミスはなくて当たり前。ミスゼロといかないまでも、例えば「お客さんから仕事を受注して、下請けさんに発注をかける」という一連の事務作業を100回やるうち、30回もミスっていたら大問題だ。
（コンサルタントをやっていると、こういうケースにたまに出くわすが）
メーカーの製造ラインで、不良品率が1%なら、カイゼン活動をしてなんとしてでも0.1%くらいには下げたいところだろう。ものにもよるけど。
ところが、プロジェクトワークはそうはいかない。初めてのことを試行錯誤しながら進めるのがプロジェクト。初めて泊まった友人の家で、停電中にトイレに行く時のことを想像してみよう。手探りで進むから色々な所に足をぶつける。そんな感じで、失敗をしながら何とか進めることになる。
だから、プロジェクトを成功させるためには「小さな失敗も許さない」という姿勢は無駄。というか危険ですらある。そうではなく「小さな失敗を許容しながら、それを大きな失敗にはつなげないような仕掛け」が必要となる。失敗と上手におつきあいしましょう、ということ。
だとすると、失敗がまだ小さいうちに張本人から「ヤバイです」とアラームを上げてもらうのが一番確実だ。
★ヤバイ時にはYellow Flagを上げろ
プロジェクトで自分が担当しているタスクがうまくいっていないとき、「僕ピンチです」と自分からカミングアウトすることを、「Yellow Flagを上げる」と言っている。語源はアメフトで反則があったときに審判が投げ込む黄色い旗（ハンカチ？）だ。
アメフトではフィールドの至る所で局地戦があり、反則が起きうる。審判が投げ込むYellow Flagは「フィールドのどこかで、プレイを止めるべき事態が発生しているぞ」という意味を持つ。
プロジェクトでも同じ。多くのプロジェクトメンバーが自分の持ち場で現実と格闘する。自分一人で解決できないような問題や遅れが発生してしまったら、それをみんなに知らせなければならない。
「○○部門にプロジェクトのコンセプトを説明し、××の件で協力してもらうハズだったけど、自分一人じゃ説得しきれる気がしない」
「○○を月曜までに調査し、要件定義に取り込むかどうかを決める。ハズなんだけど、調査が終わる気がしない。」
などなど。
ちなみに、アメフトと違って審判はいないから、プロジェクトでは自分でYellow Flagを上げなければならない。
これが小さな失敗とのつきあう僕らの方法だ。
プロジェクトは難しいんだから、多少のピンチは誰にでもあるし、恥ずかしくない。ピンチを表明してくれれば、誰かが助けられる。
冒頭に書いたように、ピンチを隠し、ピンチを育ててしまったり、手遅れになるまで隠してしまう方がよほど危険だ。
★Yellow Flagを上げると褒められる
「僕の仕事、うまくいってません」と大声で言うのには抵抗がある。信頼できる相手にしか言わない人も多いし、絶対に言わない人もいる。悪気はないのだけれども、自分でなんとかしようとする。そして事態は悪化する。
だからケンブリッジの新入社員やプロジェクトで一緒に仕事をすることになったお客さん、協力会社さんなどには口を酸っぱくして、Yellow Flagを上げて欲しいとお願いする。
それでもYellow Flagを上げてくれないときは、問題が起こるたびに「こういう時はYellow Flagを上げてください。そうすれば、今回だってこういう手を打てたんですから」と諄々と話をする。
「Yellow Flagを上げてもあなたを罰しません。無能とも思いません。Yellow Flagはあなたとプロジェクトを救う仕掛けなのです」というメッセージを伝え続ける。
Yellow Flagを上げた人は、やっかいな問題を1人で背負わなくて済むようになる。1人の問題ではなく、プロジェクト全体で何とかする課題に格上げされるからだ。
いいタイミングでYellow Flagを上げてくれた時は「知らせてくれたおかげで対処出来ました。ありがとう！」と伝えるのも、忘れないようにしたい。
★Red Flagを上げると怒られる
既に手遅れになってから問題が発覚してしまうこともある。これをRed Flagと言う。
Red Flagを上げること（それすら上げられずに、他のメンバーに介入されること）はプロジェクトメンバーとして絶対に避けるべきことだ。
Yellowの段階だったら回避できたかもしれないトラブルや遅延も、手遅れになっている。リカバリーしきれなくて、プロジェクト全体が遅れたり大きな赤字につながることもある。
以前ある方にこの話をしたら「それはYellowとRed、2つあるからうまく回るんだよね～」と感想をくれた。慧眼だと思う。黄色は救済、一転して赤は罰。罰があるからこそ、救済にすがることのハードルが下がる。救済があるから、罰のすごみが出る。
★それでもYellow Flagを上げるのは難しい
ケンブリッジではプロジェクト中に良く反省会をする。1日のおわりにちょっと振り返りの場を作ることも多いし（チェックポイントと呼んでいる）、1つのプロジェクトが終わった後にもガッチリ振り返りをする（サンセットミーティングと呼んでいる）。
そのなかで一番多く挙がる反省が「○○の件で、Yellow Flagを上げるのが遅かったので、みんなに迷惑をかけてしまった」というたぐいのものだ。
これだけ口やかましく「Yellow Flagを上げろ」と言われていても、簡単には出来ない。
その代わり、ひとたびプロジェクトメンバー全員がYellow Flagを上げられるようになったら、このチームは強い。ガチガチに監視しないから効率もいいし、任せられているからやりがいもある。それなのに、大きな問題が後から発覚して対応に追われることも、ほとんどおこらなくなる。なにより、他のメンバーを信頼しながら仕事ができる。これって気持ち良さそうだな、と思いません？
まとめ。
ピンチを共有することをYellow Flagと名付け、上げることを奨励する。そうやってプロジェクトの問題点が素早く表面化し、的確に手を打てるようなプロジェクトカルチャーを作る。これが、プロジェクトメンバーのやることを逐一監視するよりは、ずっと自立的で、健康的で、リスクの小さい方法なのだ。決め手は徹底。
今日はここまで。