おやおや、今日のお客さんは随分差し迫った様子だね。シャツの裾が燃えてるんじゃないかっていうぐらい、焦げくさい匂いがするよ。
まずは落ち着こう 、君がやるべきことは、そこに座って、ネクタイを緩めることだ。コーヒーはどうだい？紅茶はフォションのアッサムなら用意できる。これはちょっと渋い茶葉なんだけど、ミルクを入れると丁度良い案配なんだ―――
焦らない焦らない。気持ちはわかるけどね。えっと、なんだっけ優先順位とタスク管理だっけ？それも大事だけど、まずは君が落ち着くこと、これが一番必要なんだよ。わかってるわかってる、こちとら長く生きてる分、君なんかより何倍も炎上現場の場数を踏んでるんだ。そういう僕が大丈夫って言ってるんだから、問題ないんだよ。まずは、そのソファーに座って、僕の話を聞いてくれるかな？ほらホットミルクティーを淹れたよ。
*
昔、同じような状況にいたことがあってね。僕の参画してるプロジェクトじゃないんだが、チケットシステムや日報を見れば大体の状況はわかる、って奴さ。帳票システムのマイルストーンがどんどんスケジュールの奥に追いやられててね、こりゃマズいんじゃないか、って思って人づてで状況を聞いたんだよ。
デザイン案と全然違うから修正、っていうチケットが山ほどあってね。なんだこりゃ、って思ってみたらひっくり返ったよ。デザインがIllustratorで作られてたんだ。信じられるかい？JavaでIllustratorで作られたテンプレートを禁則処理付きでPDF帳票できるエンジンがあるんなら、是非とも欲しいし、何なら外販しても売れるレベルの話だよ。
もちろんそんなものは存在しない。存在しないから、哀れな新人プログラマーはせっせとドット単位で文字位置をプログラミングしてた。こんなチケットが100個はあったんじゃないかな。さらにひどかったのは、PMが帳票エンジンの遅れをタスク管理の問題にすり替えてたことだよ。PMはこの状況で何をしていたと思う？チケットの消化を時間単位で区切って、新人プログラマーたちのその日の予定に次々と放り込んでいた。10:00～13:00までに#219の修正、13:30～16:00までに#242の修正って具合にね。
そう！マイクロマネジメントだよ！さすがの僕も腹に据えかねて、ほうぼうに今すぐ止めたほうがいいと触れ回ったけど、外部チームの人間にはどうにもならなかった。
結局、納期にいたっても帳票エンジンは未完成、新人プログラマー君は体調不良で休職、PMは事実上クビになったよ。
――悲しい話だろう？ でも、これは炎上現場でよく起きることなんだ。PMは『管理』という幻想にすがり、プログラマーは『実現不可能』という壁に頭を打ちつけ続ける。僕に言わせれば両者とも、見るべきものを見ていないんだ。
じゃあ、何を見るべきなのか。
優先順位？ タスク管理？ それも大事だ。でも、火事場で一番最初に確認すべきは、そんな小難しいことじゃない。『どこが一番、人の心をかき乱しているか』だ。燃えているのはプロジェクトのスケジュールだけじゃない。顧客の、そしてチームの『心理状態』なんだよ。
*
僕が途中から放り込まれた、別の炎上プロジェクトの話をしようか。そこでも状況は最悪だった。コアチームはバグのモグラ叩きに追われ、僕みたいな途中参画のプログラマーに構っている暇はないみたいで、返事もロクに帰って来ない。正直、僕にできることなんて何もないように思えた。
そこで僕は、プロジェクトから一歩引いて、棒立ちになっている営業に声を掛けたんだ。『今一番目立っている問題は何だろう？』ってね…
営業は「全てだ」と言いすてて、頭を振った。
それでも、僕はさらに食い下がった
「最近、エンドクライアント（顧客）が一際怒った出来事があったと思うんだけど、それは何だった？」という具合にね。
そしたら営業ははっとして「それなら1ヶ月前から修正要望が出てるUI修正の進捗がなかったことだね、あれについてはずいぶん絞られたよ」と言ったんだ。
これだって思ったね。そりゃコア部分で、問題が多発してる状況で、UIを直してる暇なんてないだろうけど、顧客から見えるのはUIだから、ある意味ではそのUI修正の遅れが炎上プロジェクトの象徴になっていたんだ。
あと、UIってのは普通のフレームワークを使っていればある程度コアロジックからは分離できてるものだから、こちらで問題修正する分にはコアチームとのコミュニケーションの手数は最小限になるだろう、という目算もあった。
僕はバグトラックシステムを見回して、コアに関わらない、UIだけの修正でなんとかなるような、バグチケットをいくつか取りだして、コアチームに向かってこう宣言した「こちらのブランチでこのUI修正のチケットを直しておく。コアの修正で僕の修正が無効になるのを、僕は全然気にしないし、できる限りすぐに追従する。もし僕の修正でコアの修正がプレビューできないようなら、こちらのブランチを無視してくれても構わない。ブランチをマージするタイミングもそちらに完全に任せる」という具合にね。
コアチームからは、正直いい反応はなかったけど、コア部分の修正に僕をオンボーディングさせるためのリソースも時間もないのは明かだったから、最終的には「途中で放り込まれた以上、僕も仕事をしてるポーズは見せる必要があるんだよ」という言葉でOKを貰えた。
僕がやろうとしていることが、わかるかい？
コアチームは必死で火元を探している。でも、顧客は『玄関のドアノブが1ヶ月も壊れたままだ！』と叫んでいる。
そこで、僕はドアノブを直しに行ったということさ。ピカピカの真鍮製のに付け替えてやったんだ。コアチームは『何を遊んでいるんだ』という顔をしていたけどね。でも、それでいいんだ。僕は彼らにこう言ったのさ。『これは僕と、このドアノブに文句を言ってるお客様との間の問題だ。君たちは安心して家の中の火を消してくれ』ってね。
そこからはシンプルな話で、僕は修正する、変更がJSやHTMLやCSSに留まってる限りはマージしてもらえたから、画面は次々と最新「仕様」に変わっていく、そうやって、焦点の問題を僕はコアチームの作業から引き剥がして、UI調整屋の僕と顧客の問題にすり替えていった。そしたら顧客側のコアチームに対するプレッシャーも実際に減っていったんだ。
最終的に納期時点でフル機能の実装までは届かなかったんだけど、少なくとも最後の2週間ぐらいは、コアチームは立て直した体制で作業できたんじゃないかな、と思うよ。最後までお礼は言われなかったけどね！（正確には、僕を呼んでくれたコアチームの会社の役員からは感謝されたよ。「炎上プロジェクトに役員である自分が手を打った」部分の実績としては十分だったからね！）
この話における教訓はこうだ。
プロジェクトにおける仕事ってのは、コードを書くことだけじゃない。誰かの『心配事』を引き受けてやることでもあるんだ。たとえそれが、技術的には些細なドアノブの交換だったとしても、だれかの心を鎮めることができるなら、それは立派な鎮火活動なんだよ
*
さて、僕の長い話もそろそろ終わりだ。どうだい？君のシャツの裾で燻っていた火は、少しは落ち着いたかな。ホットミルクティーも、もうすっかり冷めてしまっただろう。
君が今すぐやるべきことは、分厚い仕様書や、真っ赤に染まったガントチャートを睨みつけることじゃない。JIRAやBacklogの画面を一旦閉じて、人の顔を見ることだ。
そして、君のプロジェクトの『ドアノブ』はどこにあるかを探すんだ。
顧客が、あるいは上司が、一番顔を曇らせている些細なこと。チームが見て見ぬふりをしている、でもずっと心のどこかで引っかかっている小さなトゲ。
それを見つけて、君が引き抜いてやるんだ。
それは君のヒーロー願望を満たすような、派手な仕事じゃないかもしれない。誰にも感謝されないかもしれない。
でも、その小さな一手で、確実に空気は変わる。チームに呼吸するだけの、ほんのわずかな隙間が生まれる。炎上時の優先順位やタスク管理ってのは、そういう隙間をつくる目的でやるべきなんだ。
そのためには、まずは、君自身がパニックから抜け出すこと。そして、誰かの『心配事』を引き受けること。
それができれば、君はもう立派な火消しのプロさ。
…おっと、もうこんな時間か。じゃあ、頑張ってくれよ。それじゃ―――
