度重なる期日の延期、お客さまの「激怒」、クリティカルな問題の発覚……。
多くのプロジェクトマネージャー（以下、PM）が最も恐れるのは、そんな「炎上」でしょう。巻き返しを図るものの、逆に現場に負担をかけたり、混乱を招いたり。その結果、品質が大きく下がってしまう、あるいはサービスイン（新しいサービスを開始すること）に間に合わないなんてことになれば、PMとしての信用は大きく損なわれてしまいます。
そうしたトラブルをうまく収め、プロジェクトを無事に着地させるには、どのような心構えや技術が必要なのでしょうか？
今回お声がけしたのは、日本IBMやパナソニックなどで、PMとして数えきれないほどの炎上プロジェクトを解決してきた木部智之さん。日本IBMではPMのグローバル最高位である「シニア・コンプレックス・プロジェクト・マネジャー」に認定された生粋の「火消し屋」です。
そんな炎上対応のプロフェッショナルである木部さんに、ご自身の経験を交えながら、プロジェクトの「火消し術」を伺いました。
木部智之さん。横浜国立大学大学院環境情報学府工学研究科修了後、2002年、日本IBMにSEとして入社。以後、数々の炎上プロジェクトを解決する「火消し屋」として活躍。2018年、パナソニック システムソリューションズ ジャパンに入社、新規事業の担当マネジャーとして、炎上プロジェクトを解決。著書に『プロジェクトのトラブル解決大全 小さな問題から大炎上まで使える「プロの火消し術86」』（KADOKAWA）など。
放置すると“炎上必至”、「火種」の実例
──これまで数多くの炎上プロジェクトをゴールに導いてきた木部さんにぜひお聞きしたいのですが、そもそも、プロジェクトはなぜ「炎上」してしまうのでしょうか？
木部智之さん（以下、木部）：大前提として、「問題が発生しないプロジェクトはない」と私は思っているんです。「こんな綺麗な計画書があるんだ……」と驚いたプロジェクトでさえ、実際中に入ってみると何も計画書通りに実行されていなかった、ということも経験しました。
そんななかでも「炎上」と呼ばれるレベルにまで問題が発生してしまうプロジェクトは、リーダーや推進者が炎上の原因となる「火種」をしっかり潰せていない傾向にあります。
──「火種」とは、具体的にどんなことですか？
木部：例えば、プロジェクトの資料がメンテナンスされていないこと。課題管理表（解決すべき問題と解決のために必要なタスクが実施スケジュールとともに書き込まれた表）の内容が古かったり、日付や担当者が記入されていなかったり。課題管理表がずさんなプロジェクトは、だいたい炎上しますね。そこでPMが「これ日付入ってないよ」とメンバーに指摘する行為って指摘されたほうも面白くないし、自分も細かいことは言いたくありません。でも、そこをしっかり潰していく。地味なことを地道にやることでしか、炎上は防げません。
＜PMが潰すべき「火種」の一例＞ ・更新されない資料 「プロジェクト計画書」「体制図」「課題管理表」「進捗報告書」などの資料がメンテナンスされておらず、実態に即していない。特に、課題管理表の期日や担当者の欄が空白になっていたり、期日が過ぎているのに何のアクションも取られていなかったり、最新の課題が記入されていない場合は要注意。・指揮命令系統が曖昧な体制図 体制図の「責任者」や「リーダー」の欄に複数人の名前が並列で記載され、レポートライン（指揮命令系統）が曖昧になっている。年齢や社歴などに配慮するあまり、責任者を明示しないぼんやりした体制をつくってしまうとプロジェクトの混乱を招く。
・議論がなされない会議 会議の場で建設的な議論がなされていない。プロジェクトは本来、メンバー同士がさまざまな意見や考えをぶつけ合って最適解を導いていくもの。一方的な報告や指示、情報共有のみで終わってしまう「形骸化された会議」ばかりに時間を費やしているプロジェクトは失敗する可能性が高い。
・「言いっぱなし」が蔓延するコミュニケーション 誰に対する発言なのかが不明瞭な「言いっぱなし」が増える。「池に石を投げる」とも表現される。発言した当人は「この人に受け取ってもらいたい」と心の中で思っているが、各メンバーは自分が受け取りたくないのでノーリアクションでスルーし、to doが明確にならない。具体的なto doとセットで語られないコミュニケーションは、物事を停滞させる。ただ、発言者にのみto doを押し付けると、誰も発言しなくなるので注意。
・不規則な勤務時間 メンバーの勤務時間は、プロジェクトの進捗に問題がなければ基本的に自由でいいが、時差があることで対面での会話の機会が減り、コミュニケーションに問題が生じることも。特に注意が必要なのは、「昼に来て深夜まで仕事をして、翌日また昼に出社する」といったメンバーがちらほらいる場合。プロジェクトの統制がとれていない可能性が高い。
・散らかった机の上 プロジェクトが健全に進んでいると執務スペースもきれいに保たれる。資料や物が雑然と置かれた机は、「混乱する状況の現れ」とも言える。
──「なんだか身に覚えがある」という人も多そうです。こうした火種が生まれてしまう最大の要因は何でしょう？
木部：突き詰めると、「人」だと思います。特に、チームのリーダーや重要なポジション、あるいはお客さま側など、プロジェクトに対して影響力の強い人がやるべきことをやらないと、プロジェクトはいとも簡単に炎上してしまいます。
一言余計、必要以上に怒鳴る……プロジェクトをかき乱す「スペキャラ」への対処法
──炎上を招く最大の要因は「人」であるということですが、やるべきことをやらないだけでなく、時にはプロジェクトの進行を阻害する行動をとってしまう「厄介な人」もいます。木部さんは『プロジェクトのトラブル解決大全』（以下、著書）の中でそうした人物を「スペキャラ（スペシャルキャラクターの略）」と表現していますが、PMとして社内外のスペキャラにどう対処したらいいのでしょうか？
木部：例えば、「実力はあっても余計な一言でメンバーのやる気をたびたび削ぎ、チームの士気を下げてしまう人」が社内のリーダーだったとします。はじめに考えるのは、その人をプロジェクトから外すこと。ただ、リーダーに選ばれている以上、会社からはある程度評価されているわけで、実際は簡単に排除できない場合も少なくありません。その時は「役割を変えて、影響力を弱める」ことを試みます。リーダーというポジションから外し、代わりにその人のスキルを生かせるようなロール（役割）を与えるといった対処法ですね。
──PMの立場なら、社内のチーム体制はある程度コントロールできると思います。ただ、お客さま側のスペキャラはそういうわけにもいきませんよね。
木部：そうですね。私自身もお客さま側のスペキャラに苦しめられた経験は多々あります。昔は、夜中の1時にプログラムの不備が見つかり、真っ白なスーツを来て会社に乗り込んできて「担当者を呼び出して、朝までに直せ！」と怒鳴る人もいました。
あとは同じプロジェクトで、ホワイトボードに投影した設計書を黄色い靴ベラでパンパン叩きながら、「なんでこんな設計してんの！？」と大声で詰めてくる人もいましたね……。ちなみに、そのプロジェクトにはそうしたスペキャラが5人くらいいました。
──なかなか強烈な現場ですね。
木部：我慢して（その人が）いないつもりでやるしかない場合もありますが、一方で少しでも影響力を弱めたり、あわよくばプロジェクトから外せないかという試行錯誤は続けます。そのうちスペキャラの存在がプロジェクトに悪影響を与えていることが社内外に周知され、相手方の上層が「彼、どうなの？」と探りを入れてきたら、そこが攻めどきとも言えるでしょう。溜めてきたマイナス要素をここぞとばかりに伝えた結果、1〜2カ月後にスペキャラをプロジェクトから外してもらえたこともあります。
ただ、スペキャラは得てしてお客さまの社内でもスペキャラと見なされている場合が多く、外してもらえないことも少なくありません。なので、あえてスペキャラの懐に入り込めるよう頑張る時もあります。例えば、トラブルが発生して呼び出された時、スーツではなく「今これしかなくて」と、あえて私服や明るいネクタイを着て行ったり。人によっては、そういうカジュアルさが受け入れられる場合もあるんですよね。
余談ですが、自分は炎上プロジェクトを担当する時、いつお客さまに呼ばれてもいいよう、会社にスーツを置いています。
「人が足りないから進まない」は言い訳にならない
──トラブルを解決するために人員を補充するのはよくある手だと思いますが、木部さんは「拙速な体制強化には意味がない」と著書で述べられています。なぜ人を増やさないほうがいいのでしょうか？
木部：普段の仕事に置き換えて考えてみてほしいのですが、人が増えると仕事も増える場合が多いんですね。個々の仕事レベルのバラつきが増えて作業の指示が煩雑になり、パフォーマンスの振れ幅を小さくするための調整作業も必要になる。また、追加メンバーが仕事を理解し力を発揮するまでには時間を要しますし、もともといるメンバーがプロジェクトについて説明するコストなどもかかってきますので、一時的に全体のパフォーマンスが落ちる可能性もありますよね。以前、2500人くらいを率いる規模感のプロジェクトを任された時、「このプロジェクトで一番何を変えたいか」と会社から聞かれて「（プロジェクトに関わる）人を少なくしたい」と答えたこともあります。それくらい、人が多いと大変です。
──では、一人ひとりの仕事量が多くメンバーが疲弊したり、進捗に遅れが出たりしている場合はどうしたらいいでしょうか？
木部：まず意識してほしいのは、人を増やすのではなく「仕事量を減らす」ことです。やらなくていいことを精査して減らしていかないと、いつまでたっても人手不足のループから抜け出せません。最初に5人でやると決めたなら、基本的には5人でできる仕事量にコントロールする。もっと言うと、ワークロード（仕事量）を根本から見直して100の仕事を70にできないかと考える。例えば、何か一つのドキュメントをテンプレート化して各々が1から作る手間を省いたり、レビューをフレームワーク化して手順を減らしたり。他にも、各自がバラバラにやっている作業をまとめたり、効率化するために作業の順番を変えてみたり、やれることは色々あるはずです。すべての手を尽くして、それでも回せないのであれば、そこで初めて人を増やすことを考えたほうがいいですね。
──時には不測の事態により、突発的にやらなければいけないことが出てくる可能性もあります。そう考えると、なるべく仕事量を減らし、常に余力がある状態にしておきたいですよね。
木部：そのとおりです。100の作業にそのまま100の工数を見積もっていたら、何か問題が起きて20の追加作業が発生した時にトラブルが起こりますよね。まずは100の作業を3〜4割くらい減らすことができないか、という思考でプランニングするべきでしょう。
──それはプロジェクトを預かるPMの立場として、大切な心構えかもしれません。
木部：そもそも、メンバーの頭数だけで語るのはよくないですよね。例えば、PMが「このプロジェクトにはあと10人必要です」と言って、仮に9人しか集まらなかったとします。すると、PMは「1人足りないからできなくても仕方ない」という言い訳ができてしまう。それに、会社から「希望通り10人用意したんだから、ちゃんとやれよ」と言われてしまったら、PMの逃げ場もなくなってしまいます。
大事なのは、メンバー一人ひとりの実力を上げることや少ないメンバーで回していくための工夫であるはずです。
新しく誕生したスポーツチームって、どうしてもメンバーを選べなかったり、メンバーの数が少なかったりしますが、私はそんなチームの監督をやるつもりでPMをやっています。当然ながら、メンバーを選べなくても、メンバーの数が少なくても「勝てません」とは言えないわけですよね。じゃあ勝ち方や戦い方を工夫しなければならない。
あとはメンバー一人ひとりの「戦闘力」をいかに強化するか。一人ひとりの伸びしろとチームの総合力で勝負するのがPMとして大事なことです。
そもそも炎上プロジェクトは人が増えるどころか（退職や休職などで）減ることも少なくありません。だからこそ私は「人が少ないなかでどうやるか」を考える所作が染み付いているんですね。
「こんな人はリーダーに上げたい」メンバーがやるとPMに喜ばれることとは？
──そうした打ち手が分かっていても、最終的にはメンバーがこの状況を「自分ごと化」しなければ物事は前進しません。木部さんはメンバーに当事者意識を持ってもらうため、どんな工夫をされていますか？
木部：そもそもメンバー全員に当事者意識を持たせるのは、おそらく不可能です。僕の体感的に、3割〜5割がその気になってくれれば、御の字かなという印象です。
そのうえで、プロジェクトの状況をフラットに正しく伝える場を定期的に持つことは意識しています。そもそもプロジェクトが炎上していることをメンバーが知らないケースも結構あります。クライアントと接しているメンバーや定例の進捗報告会に出席するメンバーが少ない場合はなおさらです。
あとは、特にリーダークラスの「やる気」を引き上げることを心がけています。現場をまとめるリーダーが当事者意識を持って動いてくれないと、それこそ「池に石を投げる」だけで終わってしまいますから。
先ほど紹介した怒鳴るお客さまのプロジェクトには、私の下に3人くらいリーダーがいて、本人たちはちゃんと向き合っている様子だったのですが「逃げ腰」な印象が伝わってしまったのか、彼らもお客さまからよく怒られていました。
やはりトップクラスのPMになるには、技術とメンタリティの双方が必要なんですよね。
──PMやリーダーではない「メンバー」の立場から、何か貢献できることはあるでしょうか？
木部：まずは、自分が任された仕事で最高のパフォーマンスを出す。そのうえで、一回り大きな視点を持って、チームの困りごとをプロアクティブに（先取りする形で）巻き取ることも重要です。チームの視点を持って動けるメンバーはPMから見てもありがたいですし、こういう人なら「リーダーに上げてみようか」とも思えます。逆に、自分で作った枠から出てこない人はやはりキャリアアップしづらいですよね。
今も夢に出てくる「最悪の炎上プロジェクト」
──もともとは普通にPMとしてプロジェクトを率いていた木部さんが、トラブルを抱えた「炎上プロジェクト」の火消し役としてアサインされることが多くなったのは、どんなきっかけからだったのでしょうか？
木部：日本IBMに新卒で入社した3年目くらいですかね。いま考えれば、そこまで「炎上」と呼ぶほどではなかったですが、トラブルが起きたプロジェクトにPMとして入りました。それを無事に終わらせた後に休暇を取り、2週間ぶりに出社すると上司から「もう、次のプロジェクトも決まっているから」と言われ、それも炎上プロジェクトで（笑）。そこから「火消し屋」としての歴史が始まりました。
──なかでも、最も苦労したプロジェクトを一つ挙げるとしたら？
木部：いまも夢に出るくらいキツかったのは、8年ほど前に担当した、複数の会社の基幹システムを統合するプロジェクトです。私が入ったのはサービスインまで半年を切ったタイミング。実は、その1年前にも一度期日を延期し、追加予算を投入してリスタートしていたのですが、このままでは延期した期日にも間に合わないということで私が呼ばれました。それくらい、苦労した案件でしたね。
せめてリスタートした段階で声をかけてもらえれば色々と手の打ちようもありましたが、私が入った時点では、もうやれることは多くありませんでした。分かっていたのは、そのままのシステムでは動かないのが明白であること。半年後にサービスインするには、システムの7割を作り直すしかありませんでした。最終的には数億円を追加投入して作り直し、何とかサービスインまでこぎつけましたが、あれはツラかったですね。
──お話を聞いただけでも大変そうです。「火消し屋」とはPMとしてはかなり特殊なキャリアですが、20代の頃から数多くの炎上プロジェクトを経験してきたことで、何か得られたものはありますか？
木部：一番はやはり自信です。プロジェクトマネジメントという領域に関しては誰にも負けない、どんなプロジェクトがきても対応できるだろうと。当初は嫌で嫌で仕方ありませんでしたが、いつの間にか（炎上していない）普通のプロジェクトの話が来ても、「それ、自分がやる意味があるのかな」とさえ思うようになりました。
──すごい。
木部：あとは「つぎはぎ力」でしょうか。注文住宅にたとえると、設計図通りに建て始めたのに「ドアがガタつく」とか「間取りが違う」とか「柱が斜めになってる」といったことはしばしば起こります。それでも、当初の予算やスケジュール内でリカバーしなければならない時は、ちょっとガタつくけど閉まりはする中古のドアを仕入れてくる、みたいな工夫が必要になる。もちろん、オーダーいただいた方には申し訳ない気持ちでいっぱいなのですが、プロジェクトも同じですよね。
私は新卒の頃「新しいシステムを生み出して世の中に新しい価値を提供していきたい」となんとなく思っていました。でも、いつの間にか「つぎはぎの住宅を建てる仕事」がメインになっていて、もちろんそれを「つぎはぎではありませんよ」という風に見せることもビジネスでは大事なのですが、一方でそれはあまり本質的じゃない、クリエイティブじゃない、と思ってしまうフシもあるんです。
炎上プロジェクトは、「平和なプロジェクトの延長線上」にある
──いえ、軌道修正や試行錯誤を重ねながらメンバーをゴールへと導いていくプロセスは、個人的にとてもクリエイティブであるように思います。
木部：結局、プロジェクトは「人」が回しているので、当初の目的やゴールにフィットしないことが出てくるのも当然で、その「つぎはぎ」の中でやっていくしかないんだな、と最近は感じています。そして、そうやってプロジェクトを遂行する醍醐味こそ、自分も含めた「人の成長」なんだろうな、とも。
──最後に、PM歴の浅い若手、これからPMとしてプロジェクトを回していく若手は、まだトラブルへの耐性がありません。もしトラブルが発生してしまった時、慌てず冷静に対処するための「火消しの心得」を改めて教えてください。
木部：まずお伝えしたいのは、「炎上プロジェクトは、平和なプロジェクトの延長線上にある」ということです。「炎上」と聞くと「超トラブル」みたいな印象を受けるかもしれませんが、どんなプロジェクトであってもその過程では絶対に“なんかある”じゃないですか。
だからこそ、繰り返しになりますが、何かしらの「きな臭さ」を感じたら放置せず、その場で対処するのが大事です。
これまでの経験を振り返ると、簡単に終わったように見えるプロジェクトも、じつは何度も細かくそうした“初期消火”をおこなっています。ですから、きな臭さを敏感に感じ取る嗅覚と、それを小まめに潰していくやり方さえ身に付けば、あなたのプロジェクトが炎上することもなくなるのではないでしょうか。
取材・文：榎並紀行（やじろべえ）
写真：小野奈那子
編集：はてな編集部
制作：マイナビ転職
