こんにちは！
複数の億規模プロジェクトでPLやってるやまさんです！
突然ですが、先日、炎上プロジェクトのヘルプ役をやってきました。
炎上プロジェクトというのはご存じの通り…
- 仕様変更が止まらない…
- 終電帰りがずっと続く…
- メンバーがバタバタ倒れていく…
ただ、世の中にはいろんな炎上プロジェクトがありますが、PM目線、かつヘルプ側目線で炎上を紹介したものは少ない気がするんですよ^^;
なので、今回、記事にして紹介してみようかと思います。
正直なところ、炎上プロジェクトは回避したいですよね。
一度、炎上してしまうと身体的にも、精神的にもかなりの負担をかけますから…
今回の記事が炎上プロジェクトの回避につなればうれしいです。
興味があれば、ぜひ読んでみてください！
Contents
ヘルプで入ったプロジェクトの炎上原因と火消し方法のまとめ
後から思えば、今回、ヘルプで入ったプロジェクトはプロジェクトマネジメント目線で言うと計画の時点で炎上することが確定しているようなプロジェクトでした。
- 表面的な炎上原因
計画時点から管理者(PL)に管理以外の開発作業が割り振られている
- 根本的な炎上原因
関係者との調整作業に関する見積りが甘い(技術以外の作業を軽視)
- 対処方針
→タスクの再整理
→開発方針の明確化
→必要スキルを持つエンジニアの巻き込み
結局のところ、「調整作業なんてすぐ終わるでしょ」という見積りが炎上の根本原因でした。
というのも、調整系の作業って目に見える成果物が少ないので軽視されがちなんですよね。
で、結果、調整作業の見積りがあまくPLへ負担がかかり、やらないといけない作業の管理ができなくなって必要な作業をやらないまま進んだプロジェクトでした。
ボクがヘルプで入ったころには「調査不足」「検討不足」という形で問題が表面化…
大きく燃え上がってしまったんですよ。
ここからはプロジェクトの概要を含めて詳しく説明していきますね。
炎上プロジェクトの概要
今回のプロジェクトは次のようなシステムをお客さんに提供するプロジェクトです。
- 基幹系システムの情報をクラウド上の既存システムと連携
- 基幹系システムの情報をグラフィカルな情報を出力
- グラフィカルな情報出力で一般ユーザの満足度向上を狙う
「一般ユーザの満足度向上」のその先もあるんですが、守秘義務の関係上、ここまでにさせてください(ごめんなさい^^;)。
Twitterやこのブログでたまにお伝えしてますが、ボクは金融系エンジニアをやっています。
正直なところ、最近の金融業界は”DX”という言葉が大好きなので、まあ今回のプロジェクトもよくあるやつですよ。
※何をもって”DX”なのかはここでは触れません^^;
このプロジェクトの全体像とポイントは次の3つです。
- 基幹系システムとクラウド上の既存システムへ連携
- ただし、基幹系システムとクラウドの既存システムの間にインターフェイス整備用の新システムを新規構築
- クラウド上の既存システムのさらに先に他社システムと連携
正直なところ、このプロジェクト、技術面ではそこまで難易度が高い開発とは思いませんでした。
既存システムとの連携が多いですからね。
”インターフェイス”や”性能などの非機能要件”をしっかりおさえれば、そこまで難しい開発でありません。
というのも、金融系システムは基幹系とスマホアプリを連携させるなど、最近こういったプロジェクトが多いんですよ。
開発実績が結構あるってことですね。
ですが、PM目線だと、このプロジェクトは難易度が高いです。
なにが難しいのかというと…関係者の多さですね。
さっきの図で関係者が分かるように吹き出しを付けてみると、次のような感じです。
他社システムが関連するところは図解上、1つなのですが、ボクが勤めているのはわりと大きな企業。
大企業あるあるなのですが、部署が違うと他社と感じるぐらい距離感があるんですよ…
なので、実質的に他社の立ち位置にいるのは3社、お客さんも合わせると4社ぐらいの関係者がいます。
PMBOKで言うところの「ステークホルダーマネジメント」の難易度が高めになるんですよね。
ということで、関係者との調整作業がかなり難しいという特徴のあるプロジェクトでした。
そんなプロジェクトの設計工程後半にやまさんはヘルプ要員として参画します。
炎上プロジェクトヘルプ やまさんの最初の立ち位置：基幹系システム開発のアドバイザーとして参加
最初、ボクは基幹系システム側の仕様検討アドバイザー的な立ち位置で参加しました。
設計品質に問題がありそう、ということでえらい人からの指示で入った感じです。
いちお「ヘルプしてほしい」という”依頼”の形で言われましたが、拒否権はないやつですね^^;
工程としては設計工程後半。
あと1ヵ月弱で設計工程完了っていうところでの参画でした。
実は、ボク、もともと金融系の基幹系システムの部署の出身なんですよ。
基幹系システムと周辺システムが連携するプロジェクトのPL経験が豊富ということで選ばれたらしいです。
金融系基幹システムって、歴史が長く複雑な仕様になっていることが多いので、知識を持っていると割と重宝されます^^
で、今回のプロジェクトはクラウド側のシステムで基幹系システムの情報をグラフィカルに出力する開発。
基幹系システムから見ると、「基幹系システムから情報吸い上げて、かっこよく見せるシステムを開発する」って感覚です。
なので、どんな情報をクラウドシステム側に渡せばいいのかを設計を行う上で把握しておく必要があります。
基幹系システム側の開発アドバイザーとして参加するので、クラウドシステムに連携すべき情報を理解しておくのは当たり前ですね。
で、このプロジェクトのPLに確認しに行きます。
クラウドシステム側のインターフェイス仕様書ってどこにありますか？
あ、そういえばもらってないですね… 他部署ですが、いちお社内なのですぐ入手できると思います。
このとき、ボクはこのプロジェクトが炎上していると確信するのでした…
「クラウドシステムの設計書がない」からの…基幹系システムの開発リーダーへ
担当者に聞いてみたところ、クラウドシステム側の仕様書を入手していないとのことでした。
(え？！ 今まで何やってたの？)
設計工程はすでに後半に入っています。
クラウドシステム側の仕様書がなければ、基幹系システムの設計はほぼ進みません。
2ヵ月以上時間あったと思うけど、ホント何してたの？
そう言いたくなりましたが、グッとこらえました^^;
少し聞いてみたところ、お客さんや他システムの調整に手間取っていたとのこと…
まあ、確かにお客さんとか他社との調整の方が社内調整よりも優先度は高いです。
ですが、さすがに2ヵ月も引っ張るのはマズい^^;
アドバイザーだから作業進めるのは仕事じゃないはずだけど、PLさん、忙しそうだしやっておくか…
今後も仕事で関わることもありますからね^^;
ということで、ボクは基幹系システム開発の推進役を担当することにしました。
ホントはえらい人から正式に指示を出してもらうのがいいんですけどね。
えらい人たちを動かして指示が出るのを待っていたら設計工程が終わりそうな予感です(苦笑)
このプロジェクトにどれだけ時間を割くのか、とか社内的にいろんな”政治の力”が働くのでこういう役割分担的な話し合いは時間がかかるんですよ。
こういったのは大企業特有のことかもしれません。
なので、PLさんと話をして基幹系システム側のマネジメントはボクが担当することにしました。
そこから2日ほど経過して、仕様書が(やっと)到着します。
仕様書が届けば、こちらのもの。
仕様書を確認し、基幹系システムの開発方針や大まかな改修ポイントをまとめます。
その後、基幹系システムのエンジニアでまとめた開発方針や改修ポイントを説明し、詳細な設計を依頼しました。
正直、2ヵ月も停止していた期間があったのでスケジュールはかなり厳しいです。
※ちなみにこういった「作業が止まる期間」を作らないのもマネジメント側の仕事です・
ですが、ウチの基幹系システムのエンジニアは職人気質の方が多いんですよ。
超ハイレベルなITスキルを持っていて基幹系システムの仕様にも詳しいです。
正直、いろいろクレーム的なこともあったんですが、ギリギリなんとかなりそうとの回答をもらえました。
基幹系システム側はこれで動き出したしなんとかなりそうだな。
ボクの仕事としてはあとは基幹系システムのエンジニアが作ってくる今回の改修内容をまとめた設計書をレビューするぐらいです。
ということで、基幹系システム側は一段落ついたことを報告しにPLのところへ行ったのですが…
ボクが見たのはPLが若手メンバーにマジ切れしてる光景でした。
PLの目がヤバい
いや、それ違うでしょ。 忙しいんだからホントそれぐらいはしっかりやってくれよ
すいません…
基幹系システム側の作業はうまく進みだしたよ、そう報告をするためにPLさんのところに行ったところ…
PLさんが若手メンバーにマジ切れしてました。
(こわっ！！)
でも、この感じボクも知っています。
忙しすぎて、アドレナリンがドバドバ出まくってる感じですね。
本人(PLさん)も何で自分がこんなに忙しいのか分からなくなっていたと思います^^;
とにかく忙しい…
やらないことがたくさんある…
そんな中思うように後輩などのメンバーが動いてくれない…
もうどうすればええねん！！
本人はそんな感じだったと思います^^;
PLとしては配下のメンバーはミスをするものとしてカバーできるように仕事をすべきなんですが、カバーしている余裕がない、そんな感じですね。
時間的にも、
精神的にも、
身体的にも…
さらにこのPLさん、忙しすぎて実際の開発(今回だと設計作業)にも少し手を出しているようでした。
もうこうなると、最悪です。
本当はPLってマネジメントに集中すべきなんですよ。
開発側の作業に手を出すべきではないんです。
なぜかというと、開発作業に手を出すと作業管理したり全体の方向性を検討する時間を取れないんですよ。
小規模のプロジェクトならPLが作業者を兼任してもなんとかなるんですが、今回は関係者がめちゃ多い大きめのプロジェクト。
PLが作業に手を出してしまうと、管理者がいなくなってしまいます。
実際、このPLさんも目が血走っている感じで常にイライラしている様子でした。
で、周りのメンバーもなかなか問題を報告しにこない悪循環です。
まあ、報告したら怒鳴られるって分かっているのに、問題を報告したい人なんていないですからね。
仕事なんで仕方ないんですが、やっぱりつらいものがあるじゃないですか^^;
(問題出ちゃったんだけど、忙しそうだから落ち着いたら報告しようかな…)
そうやって、問題の報告は先送りされます。
でも、報告しないといけません。
なので、時間的に余裕がなくなってから報告がきて、またPLはその対応に追われて…そんな悪循環ですね。
ただでさえ、PLは調整作業に時間が取られているのに、問題を解決する時間が限られているので開発作業にまで手をだし泥沼にはまっていく…
典型的な炎上プロジェクトでした。
プロジェクト炎上原因のまとめ
いろいろお話しましたが、今回のプロジェクトが炎上した原因はなんだったのか。
結局のところ、”調整”作業の見積りの甘さ(技術以外の作業の軽視) というのが根本的な炎上原因だとボクは考えています。
調整作業を甘く見た結果、PLがパンクしちゃったってことですね^^;
で、PLが個人的に炎上した結果、次のような問題が芋づる式に出てきてプロジェクト全体まで炎が広がったイメージかと思います。
- 仕様の優先順位づけの不足
お客さんからの要求をそのまま実現しようとする体質 - タスク管理の漏れ
クリティカルパス(遅れが発生すると遅延確定の作業群)の未把握 - 必要な設計スキルを持ったエンジニアの不足
直前になって人員の手配が必要となることに気づき対応が遅延
正直、”調整作業”ってあまく見られがちです。
”調整”がメインのボクが所属する大手SIer側でも今回のようにあまくみられることがあるので、一般的なIT業界で見ても軽視されがちと言えるでしょう。
ですが、”調整”作業って仕様を決めたり、設計方針を決めたり、かなり重要なこともやるんですよ。
特に今回紹介した関係者が多いプロジェクトだと、かなり重要な作業になってきます。
”調整”作業が終わらないと設計などの実際の開発作業に進めないですからね。
ぶっちゃけ、何でやってるのかよく分からない調整作業もありますよ^^;
ですが、開発方針を左右するようなことも”調整”作業とひとくくりにされて呼ばれているのが実態なんですよね。
”調整”作業をあまく見ると今回のように痛い目をみるので注意が必要です。
炎上プロジェクトの立て直し
ここまでを読んでくれた方はお分かりいただけると思いますが、当初、ボクがお願いされた基幹系システムの開発アドバイザーなんて氷山の一角でしかないわけですよ。
プロジェクト自体の炎上は止まりません。
ということで、炎上プロジェクトの立て直しに入ります。
まあ、そこまでやる義務というか、義理はないんですけどね^^;
今回のPLさんはこれから一緒に仕事をすることもあるので、恩を売っておいてもそんはないかなって思ったのがホンネです(笑)
それになんていうか、やっぱり感謝されるとうれしいじゃないですか。
感謝される仕事と感謝されない仕事だったら、やっぱり「助かったよ！ ありがとう！」とか言われたいなーということもありお手伝いすることにしました^^
で、炎上しまくってるプロジェクトを火消しするためにやったのは大きく3つです。
- タスクの再整理
- 開発方針の明確化
- 必要スキルを持つエンジニアの巻き込み
”立て直し”なんてレベルが高そうなことを言っていますが、ぶっちゃけ当たり前のことしかしてません。
「当たり前のことを当たり前にやる」
もうこれしかないんですよ。
がっかりさせてしまったかもしれませんが、炎上プロジェクトの火消しに一発逆転の魔法なんてないです。
炎上プロジェクト共通でいえますが、火消しは「当たり前のことを当たり前にやる」これが大前提なんですよね。
炎上プロジェクトでよくある”増員”は「当たり前のことを当たり前にやる」を短期間にやるためにやってるようなものです。
これが現実なんですよね^^;
炎上プロジェクト立て直し：タスクの再整理
まずやったことはタスク再整理です。
WBSを作り直した感じですね。
というか、ちゃんと整理された資料がなかったので作りました。
ここで意識したの大きく次の3つです。
- 重複した作業がないか
- 手戻りが発生するような作業の順番になっていないか
- クリティカルパス（遅れが発生すると遅延確定の一連作業)はどこなのか
忙しくなればなるほど、WBSとか管理系の作業は後回しにされがちです。
しかも、一度、後回してしまうと、どんどん管理上の進捗と現実の作業状況がズレていくんですよね。
現場にいると遭遇したことないでしょうか。
まったく更新されていない作業一覧。
何の作業が進んでて何の作業が進んでいないのかよく分からない状況。
作業者が決まっていない、かつよくわからない作業
一度、こうなってしまうと、実態と合わせるのはなかなか大変なんですよ^^;
それこそ今回のようにイチから作りなおすようなこともよくあります。
ですが、ちゃんと整理しておかないと、作業漏れが出たり、今遅れているのかしっかりと進んでいるのか分からなくなるんですよ。
なので、忙しいときほどしっかり管理しておく必要があります。
ちなみに、タスク一覧(WBS)を作るときのポイントはPMやPLの独断にならないようにすることですね。
各チームのリーダー層あたりまでの了解を得ておくのがベストです。
もちろん、ただ作っただけではいけません。
週1回とか週2回とか、どこまで作業が進んだのか定期的に確認します。
他には新しい作業が出てきたら確認するタイミングでWBSに書き込んでタスク管理の資料が古くならないように気を付ける必要がありますね。
ちなみに、今回は1日に1回、WBSをもとに進捗を確認することになりました。
多い気もするんですが、明らかに炎上プロジェクトになってますし、えらい人からの指示があったので1日1回の頻度となりました^^;
炎上プロジェクト立て直し：開発方針の明確化
タスク再整理が終わったら次は開発方針を明確にする作業に入りました。
WBSを作っただけだと、「〇〇機能の設計方針を検討する」とか「お客さんと仕様調整を行う」しかありませんからね。
判断基準がないわけですよ。
なので、お客さんがシステムに期待することから外部仕様、内部仕様の大まかな設計方針を検討していきます。
本当はこういう開発方針って、プロジェクト開始時に大枠を決めて少しずつブラシュアップしていくものんなんですけどね^^;
要件定義の最初に作ったものから更新が止まっていたので最新化する感じで細かいところを決めていきます。
開発方針を検討してプロジェクトに関わるメンバーに周知するのはかなり重要な作業なんですよね。
社内でも各システムやチームの事情もありますし、お客さんからの要求もすべて受け入れるのは難しいです。
なので、社内向けには良い悪いの判断基準を作ってあげる必要があるんですよね。
社外向けには関してはどこまで調整相手側に配慮できるか、事前に基準を決めておかないと交渉できません。
特に、お客さん向けの調整方針やどこまで要求を受け入れるのかという基準は超重要。
ほっておくとどんどん仕様が膨らんでいきますから^^;
このとき重要なのは最終的な目標を見失わないことです。
- システムを導入したことによるお客さんの価値や実現したいことはなんなのか
- 「お客さんの実現したいこと」から逆算したとき、必要な機能とあったらいい機能の線引きは何なのか
これらをはっきりさせていきます。
ようはお客さんとの仕様調整、つまり交渉で許容できる部分とできない部分をはっきりさせる感じですね。
開発方針は頭の中にあるだけだと、矛盾している部分が出てきたりするので、しっかり書き出しのがオススメです。
炎上プロジェクト立て直し：必要スキルを持つエンジニアの巻き込み
タスクの再整理が終わり、開発方針も明確になったら次は必要な人員を巻き込みます。
基幹系システムについては一定数のエンジニアが常にいるような体制になっているのでえらい人を巻き込んで協力を取り付けました。
社内向けの調整のテクニックなんですが、えらい人に言う前に担当者と調整をつけておくと動きが速くなります。
「あなた(えらい人)がOKっていれば、現場は走りだせます」って感じにしておくってことですね^^
こういったことは「根回し」とか呼ばれますが、大人数の組織を動かすのには意外と重要なんですよ。
手を動かしてくれるエンジニアさんも、突然言われるより、事前にお願いしておいたほうがOKを出してくれやすいです。
正直、大きなプロジェクトでは派手な目立つプレゼンなどが注目されがちです。
ですが、それは地道でコツコツした作業の上に成立するんですよね。
なので、地味な作業もめんどくさがらずしっかりとこなしていく必要があります。
炎上プロジェクト立て直しのその後…
実はボクのヘルプは1ヵ月という、期間限定のものでした。
別のプロジェクトのPLとしてボク自身が動き出す必要があったためですね。
ということで、ここまでで紹介した3つの立て直し作業をこなしてボクは離脱することになりました。
その後も質問とかがたまに来ますが、ウワサを聞く限り、なんとか持ちなおしてくれたようです.
炎上プロジェクトのPLさんも忙しそうにはしていますが、怒鳴ったりしてしまうほど余裕がない状態からは脱出できたみたい^^
炎上プロジェクトは長く続くと、精神的な病気になってしまいますからね。
少しでも状況が改善できたようでよかったです^^
まとめ
この記事では次のようなことを紹介しました。
- “調整作業”をあまくみると炎上のきっかけになる
- プロジェクトを炎上させないコツは「当たり前のことを当たり前にやる」
- 炎上しても火消しするには「当たり前のことを当たり前にやる」しかない
いかがでしたでしょうか。
今回はボクが経験した炎上プロジェクトの話を紹介してみました。
炎上の原因っていろいろあります。
ですが、炎上プロジェクトのほとんどは今回のようにIT技術と関係ないところでおこるのがほとんどなんですよね。
それを知っておいていただきたく、今回ボクが経験した炎上プロジェクトの記事を書いてみました^^
ただ、一方で「ITの勉強をしない→エンジニア失格」という空気がこの業界に流れているのを感じます…
そのことについてこちらの記事でボクの考えを書いてみました。
興味のある方はぜひ見てみてくださいね！
このブログの中でも人気の記事なので気にある方は一度開いてみてください^^
それでは！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
おそろしい…