Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』
こんにちは、谷口です。
某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。
あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。
という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると
「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をしていれば炎上が防げたのか』などがわかって勉強になるし、次の仕事に活かせる知見が得られて非常に役に立つからであって、決してそういう性癖だったわけではない」
と言われまして、じゃあせっかくだからということで「これまでにどんな炎上プロジェクトを経験してきたのか」、そして「そこから得られた炎上を防ぐための知見」や「自分がいるプロジェクトが炎上し始めたらどうすべきか」などを聞いてきましたので、ご紹介いたします。
- ■炎上しているプロジェクトに自ら突入してくのが趣味だった人の簡単な経歴
- ■本気でヤバいと感じた炎上プロジェクト体験談
- ■ここに気をつければ炎上を防げる?かもしれない、炎上プロジェクトに多い傾向
- ■プロジェクトをなるべく炎上させないために、新人でもできること
- ■まとめ
■炎上しているプロジェクトに自ら突入してくのが趣味だった人の簡単な経歴
高村
経歴:大学(情報工学)→メーカー系の大手SIer→paiza(ギノ)
入社一年目はテスターから始まって、二年目ぐらいから開発チームのサブリーダーとかマネジメント役をやるようになって、最終的にはなぜかPMは別にいるのにほぼ自分がPM的業務をやっている状態になっていました。
■本気でヤバいと感じた炎上プロジェクト体験談
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』
◆3年目で初めてのサブリーダーになったらすぐにPMがいなくなってしまったプロジェクト
◇始まり方
これは当時開発中のシステム開発プロジェクトがリリースに向けて奮闘している中、その既存システムの料金計算系の追加機能の開発をするプロジェクトでした。
既存システムを熟知しているベテラン社員のPMを中心に、入社3年目の私と4年目の女性社員がサブリーダーとして開発チームを動かすという体制で開始しました。2人ともサブリーダーをやるのは初めてだったんですが、上層部も「若手社員をサブリーダーとして育てたい」という思いがあったんだと思います。
◇炎上過程
・開始早々にPMが鬱になって来なくなってしまい、代わりに営業出身でPM未経験な方がPMに抜擢される→既存システムありきのプロジェクトなのに、詳しい人がいない(ちなみにその既存システムもリリースに向けて絶賛炎上中でした)。
・PMもサブリーダー2人も全員その役割をするのが初めてで、設計のレビューなどもするけど、経験不足なこともあって抜け漏れが大量発生→遅れも大幅発生
・遅れを取り戻すために残業する→PMより上位の管理職の方から「利益が下がるから残業を抑止しろ」とお達し→既に超遅れてるのに、PM「上に言われたから残業禁止で」→「いやめっちゃ遅れてるから残業しないと絶対できないです」と反論すると、PM「リカバリ案は考えるから残業禁止で」→その後PMからリカバリ案は出てくることはなく、順調に炎上
◇学んだこと
そもそも自分も3年目で初めてサブリーダー的な役割だったので、初心者にありがちな「何かまずい気がする、でも具体的に何がまずいのかわからない…!」という状態で、どこがまずいとか、まずい理由や原因、予想される結果などなど、上にうまく説明できないことがよくあり、悪かったと思います。
当時はプロジェクトがまずい状況であることを論理立てて問題点を説明することができずに、「う、うまく言えないけどまずいと思います!」ぐらいのことしか言えなくて、上の人からも「なんか若造がピーチクパーチクうるせえなぁ」的な感じであしらわれてしまっていたので、双方どうしようもなかったなと感じます。
まぁ、PMとサブリーダーが全員未経験でプロジェクトを推進すると、悲惨な状況になるものだという勉強になりました……。
◆仕様書がなくて信じるものがコピペ&継ぎ足しのソースだけだったプロジェクト
◇始まり方
自分は助っ人として途中から行った客先常駐プロジェクトです。とりあえず、まず行ってみたら仕様書が存在していませんでした。
◇炎上過程
・まあ仕様書がないのはそんなに珍しいことでははないので、とりあえず頼りになるのは既存のソースのみ
・言語はPerlが使われていて、ソース自体は「読める、読めるぞー!」と思ったらコピペソースばっかり
・例えば「common.pl」が何個も何個も出てきて、全部実装が違って、どれが実際に使われてて動いてるのかもわからない(いろんな協力会社が、同じようなソースコードを継ぎ足し継ぎ足しで作っていったと思われる…)→どれが動いているかを調べるには、いろんな場所にprintを埋め込んでちょっとずつ動かして検証するしかない状態→全然作業が進まない
・そのプロジェクトの専任でやっていた方が「ここではみんなが、俺のcommonを作り上げるのさ……」とか言ってる(自分は助っ人なのに笑いながら涙が出ました、いろいろ間違った青春でした)
・テスト環境もわけがわからない状態で、複数あるテストサーバのどれをどう使うべきなのか誰もわからない→お客様にも聞いても、お客様も環境について把握してる人がいないから回答に時間がかかる→全然作業が進まない
・全然間に合わないから人はどんどん増やされる→どんなに技術的に腕の立つ人が投入されたとしても、継ぎ足しソースや把握してる人がいないテスト環境などのせいで、本当に少数のサバイバルが得意な強靭なプログラマーしか作業を進められない(ちなみにそういう人たちは最終的にWeb系の企業に転職していったりしてました)
◇学んだこと
これは、継ぎ足し継ぎ足しで手のつけられない状況になってしまう前に、きちんと時間と予算をかけて、リプレースしたりリファクタリングしたりして、コードをきれいにしたり環境を整えたりするタイミングがあれば、ここまで非効率なことにはならなかったと思います。お前が信じるお前のcommonを信じてもだめなんだよ……その後もプロジェクトは続いていくんだから。
協力会社が複数いて、お互いが作った部分には干渉しない(できない)とか、コピペでとりあえず動くものを作ったら「今回のプロジェクトにおけるうちの会社の責任はここまでだからOK!」とかいうことが続くと、こういうふうになっちゃうんだろうなあという案件でした。
◆新しいフレームワークを使おうとしたら、有識者がいなくて大失敗したプロジェクト
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』
◇始まり方
これも私は助っ人で入ったプロジェクトです。
それまではStrutsを使っていたけど、「StrutsってXML地獄になるのが嫌だよね~」「なんかSeasarがいい感じらしいから導入しようぜ!使ったことある人だれもいないけどね!」といった感じで、有識者もいないのに新しいフレームワークを導入したプロジェクトでした。
◇炎上過程
・有識者がいないので、みんな見よう見まねなんで何とか動くものを作る→突貫工事で作ったものなんで、いざテスト工程に入ったらもちろんバグだらけ
・遅れそうなので人を増やしていく→追加された人たちもSeasarを使った経験がない→何がどうなって処理が呼び出されているのかがわからないので、すぐには修正作業が進まない(Seasarがわかればどうってことない修正でも、その時は本当に経験者がいなかったので……)
・最終的に、呼び出し関係や依存関係をプログラムからExcelに起こして説明書みたいなのを作る(これ作るのにもめちゃくちゃ時間かかった)→説明書を見ながらなんとかバグを潰していって、一応リリース完了(納品日は遅延)
◇学んだこと
これは、当然ですが導入前にSeasarを理解する工程が必要でしたね。PMの人もSeasarをわかっていなかったので、炎上し出した頃は何が原因で遅れてるとか、どうすれば解決するかとか、みんなさっぱりわからない状態でした。
このプロジェクトのおかげで、有識者もいないのに新しいものを導入するとまずい……というか、新しいものを導入する前には、チームの人全員じゃなくても、せめて誰かがそれについてしっかり理解している状態になっておかなければならない、もしくはせめて誰か有識者とのパイプをつなげておいていつでも聞ける状態にしておかないと危険である……ということがわかりました。
◆有識者が一人いたけど、協力会社の人と直接話せなくて生産性がた落ちのプロジェクト
◇始まり方
これも助っ人で行ったプロジェクトです。
・一つ前のプロジェクトと同様、新規で導入するフレームワークとか、新しい技術要素が盛りだくさんのプロジェクト
・しかしこのプロジェクトには、ものすごーく技術に精通している技術補佐の課長がメンバーにいた。新たに導入するフレームワークについてもよく知っている人だったので、この人がいれば安心!うまくいきそうだね!
◇炎上過程
・蓋を開けてみれば、協力会社の末端で実装してくれてる人たちは契約の都合上、その課長に直接質問できない(!!!!)→どうするかというと、各チームで彼らをまとめるサブリーダーが間に立って質問や課題の報告を上げたり戻したりしないといけない
・新技術が導入されてわからないところがいっぱいあるから末端からは疑問・質問が出まくる→その都度サブリーダーは取りまとめて、課長補佐に聞いて、回答をまた末端に下ろす→そのうちサブリーダーにめちゃくちゃ負荷が集中する→末端の生産性は上がらない→有識者がいるのに全然開発が進んでない
・開発が進んでないのに、PM(技術補佐の課長とは別にいた)が上の管理職の人に対して、ギリギリまで上に問題ないと見せかけていた(端的に言うと嘘ついてた……)
・報告上は「問題なし」となっていたが、報告を聞いた部長がなんだかプロジェクト内に漂う不穏な空気に気付く→部長が、私含む数人を助っ人という名目でガサ入れをさせる→ガサ入れ班が「実際は大変危険な状態です」と密告→お祭り騒ぎの大炎上ワッショイワッショイ
◇学んだこと
これはボトルネックで末端が上層部に直接聞けないせいで生産性がた落ちしたプロジェクトでした。
あとはPMの人がやるべきことを全然やってなかったのもありますね。大手のSIerって最低限の開発プロセスが決まっていて、それを守っていれば(生産性は若干犠牲になるものの)最後の方で急に大炎上!とはならないようなプロセスが完成しているはずなんですが……かっこつけたり嘘ついたりして、うまくいっているように見せかけているとそのプロセスが崩れてしまうので、絶対にダメですね。もしかしたら背水の陣を切って成功させる自信があったのかもしれませんが……。
◆「リリースまであと一日」という張り紙があるけど、全然進んでないプロジェクト
◇始まり方
↑まずタイトルがどういうことかというと、官公庁系のシステムで、年末休みの12月28日ぐらいから突然「助っ人として東京から関西まで飛んでくれ」と言われたプロジェクトでした。納期が連休明けの次の日だったので、営業日換算だとリリースまであと一日だけど、連休に入ってるから時間が止まってるんですね!わ~不思議ぃ~!
◇炎上過程
もうこれは、何が悪かったのかわからないというか全部悪かったんですけど……
・助っ人として来たけど何の説明もない、割り当てられたPCの中に前の担当者が残していったシステムが一応あるけど、官公庁系のシステムなので表示されている用語が専門的で、見ていてもいまいちよくわからない。
・PMに聞いてもタスクすら把握していない。助っ人が入れ代わり立ち代わり来るけど誰がいるのかも把握していない。
・昼間は毎日官公庁側に出向いて仕様を詰めているはずの人が、夕方になって開発現場に戻ってくる→助っ人は仕様についていっぱい質問があるので聞く→なぜか判断がつかないらしく、別の部屋にいる一次請けの人達に一緒に質問しに行く(夕方までこの人を待ってる意味が全くなかった)
・なぜか3時間に一回しかコードがデプロイされない。デプロイする人たちは違うフロアにいて、3時間に一回機械的にデプロイをする。待ってもらえないので、デプロイタイムを一秒でも過ぎたら3時間後の次のデプロイまで待たないといけない。
・コミット時はExcel&印刷した書面による謎の二重申請をしなければならない(そしてなぜかその申請を受けつけるだけが仕事のおじいちゃんみたいな人がPM補佐として鎮座している)。→結合テスト一つするのにもめちゃくちゃ時間がかかって全然進まない
他にもいろいろありましたが、私はそこには年末年始の間しかいなかったので……。納期は結局2月末まで伸びたそうです。あの張り紙は一体何だったんだ……。
◇学んだこと
このプロジェクトは仕様もなかなか決まらなくて、発注側にも問題があったようなのですが、一次請けとその子会社における責任のなすりつけ合いが横行していた(お互いに「うちはここまでしかやりませんよ」「それはそっちの仕事でしょ」みたいな)のも問題だったと思います。
あとは謎の3時間に一回しかデプロイできない制度とか、コミット申請二重管理制度とか、コミット申請書類を管理するだけの謎の人員とか……明らかに効率化できる部分を非効率的なまま進めていくのは本当にだめだということがわかりました。
他にも数えきれないぐらい炎上プロジェクトを経験したり、助っ人で自ら飛び込んでいったり、最後の方は自分も倒れちゃったりとかいろいろあったんですが、次にいろいろ経験してきた中で感じた炎上するプロジェクトに共通する予兆や傾向をまとめます。
■ここに気をつければ炎上を防げる?かもしれない、炎上プロジェクトに多い傾向
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』
◇有識者がいない、もしくは有識者が一人しかいない
特に新しい技術を導入するプロジェクトの場合、わからない・進まない部分が必ず発生します。
だから、本当に全員が初体験な場合は、その技術を理解する工程を飛ばすのはまずいんですよね。そんな悠長なこと言ってられないプロジェクトもあるとは思うんですけど、突貫工事で進めてテストでバグが大量発生しちゃう方が結果として対応に時間がかかっちゃって、非効率なことになってしまうので。
あと、たとえ有識者の人がいたとしても、一人しかいないという状況はまずいです。有識者の手がふさがってるときは進められないとか、負担が一人に集中しちゃって潰れちゃうとか、それでその人が倒れたりしちゃったら、プロジェクト全体が共倒れという状態になってしまいますよね。
それでも、どうしても突貫で勉強しながらやってくしかない、わかる人がプロジェクト内にいない…というプロジェクトの場合は、プロジェクト外の人でもいいので、有識者を探して見つけて繋がっておいた方がいいです。
前述の初めてSeasarを導入したプロジェクトの場合、そもそもSeasarを使って成功した社内事例があったはずなんです。でも、「どっかで成功事例があったらしい」ぐらいの認識で、社内のどこにSeasar経験者がいるのか誰も知らなかった。あのプロジェクトが始まるときに、誰か経験者を見つけて「以前〇〇プロジェクトでSeasarを使われてましたよね?今度うちでも導入することになったので、何かあったときはすみませんが質問させてください~」って感じで繋がっておけたら、そこまで炎上することはなかったんじゃないかと思います。
◇末端の人が有識者に質問できないなど、契約のせいでボトルネックが発生する
前述した経験談から言うと、末端の作業者が他社の有識者に直接質問できないなど、契約上の問題で効率や生産性がガタ落ちしてしまう場合があります。
こういう案件は絶対に避けたいです。とは言え契約の問題って、もう決まってしまったプロジェクトに入るしかない場合はどうしようもなかったりするんですが……私は前職で最後の方には契約前の段階から打ち合わせに入ることもあったので、そういう状況を未然に防ぐためによく口を出してました。
例えば、A社からの仕事があったとして、自社と別の協力会社B社が両社ともA社と個別に直接契約した場合、契約上自社とB社の人は、A社の人を通さないと直接質問もできない……という状態になってしまったりする。こういうときは、そのプロジェクトを自社で一旦請けて、B社は自社の協力会社として契約&アサインしてもらえれば、末端で非効率化する問題が防げるので、そういう契約にしてもらえないか提案したりしていました。
◇PM一人でWBSを決めてしまっている
各工程でやっておくべきことができていないプロジェクトは、テスト工程で必ず炎上してしまうので、炎上を防ぐためにはそういった小さな火種の段階で潰しておく必要があります。
ただ、PMが最初から全てのタスクを割り出せるかといったら、そんなの無理なんですよね。後から必ず抜け漏れしていたタスクが発生します。
でも、最初の時点でPMがぎっちぎちのスケジュールを引いてしまっていた場合、後から発生した抜け漏れを割り振ろうとすると、誰かに無理をしてもらわなければならなくなる。「何で増えるんですか?できませんよ」と言う人も出てくる。
……という問題が絶対起きるので……プロジェクトにもよるとは思いますが、WBSはPMが決めるよりも、例えばエンジニアのチームが担当機能ごとにわかれているなら、チームごとにタスクを挙げてもらう。それを元にWBSを作った方が絶対にいいです。
それで、例えばチームごとに共通した部分があるなら、一部重なってるぐらいの状態にしておいた方がいいです。タスクを切り分けすぎると、また抜け漏れがあったときに「誰がこの穴を埋めるんだよ」って感じになってしまいますので。
◇各工程でやっておくべきことができていない
炎上の原因をつきつめて考えると、ほとんどがこれに行きいちゃいます。当たり前のことなんですが……。
例えば、本来は仕様を詰める段階で決めておくべきことを決めずに設計に進んじゃうとか、設計で確定しておくべきことがふわっとしたままなのに確定したことにして実装に進んじゃうとか……やるべきことの基準が甘いまま進んでいってしまって、それが積み重なって、いざテスト工程に入ったら大量のバグが発生して、あれもできてない、これもできてない→大炎上に至るというのが、炎上プロジェクトに多いパターンかと思います。
ただ、そうは言われても「そりゃそうだろ」「どうしたらいいんだよ」という感じだと思うので、次の章で「各工程でやっておくべきことができていないと発覚したときに作業者がどうすべきか」ということから書いていきたいと思います。
■プロジェクトをなるべく炎上させないために、新人でもできること
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ!』
前職の後輩とは未だに一緒に飲みに行ったり、炎上をなるべく防ぐ&小さくするための方法を相談されたりもするので、そのときによく話していることを書きます。
◆自分がいるプロジェクトが炎上し始めたらどうすべきか
◇自分のわかる範囲でいいので、スキマになっている工程を洗い出して報告する
前述にもありますが、炎上し出すとみんな結構責任のなすりつけ合いというか、タスクの線引きをしたがるんですよ。「いや、私が担当するタスクはここまでだけですから」という感じで。ただ、それだと結局、火種になってる抜け漏れがあった部分を作る人がいなくなっちゃって、いつまでたっても炎上がおさまらないんです。
だからプロジェクトが炎上し始めたら、自分なりにでいいので「これ、誰かがやらないと終わらないぞ」というスキマになってる部分を洗い出して見える化してあげると、上の人は大変助かるかと思います。まあ、その洗い出した部分が自分の担当になっちゃう可能性も大きいので両刃の剣なんですけど、ほっといてもどうせ大きな火種になってしまうので……。
◇PMがだめだったら、もう一つ上の人に直接話してもいい
前述の例だと、めちゃくちゃ遅れてるのに残業禁止令を出して、リカバリー策を考えると言いながら全然何も考えてこない人とか、遅れてるのに上には遅れてないように見せる人とか、嘘つく人とか……本当にやむを得ない炎上ならいざ知らず、PM自身に問題がある場合や、もうこの人じゃ話にならないという場合は、さらに上の人に直接話をしに行ってもいいんだよとは、よく後輩に言っています。
ただ、いきなりPMを飛ばして話をしてはだめで、一度はちゃんとPMに、例えば「上には遅れてないように見せかけてるけど、本当はスケジュールめっちゃ遅れてるから対策しないとまずいですよね」という話をしてエビデンスを残し、そこで何も変わらないのであれば、改めてPMの上の課長に「本当は遅れててこのままだと大炎上しそうです」という話をする、課長がだめだったらまたその上の部長に話す……というふうに、ちゃんと順番に話して段階を踏んでいくことが必要です。
これ、もしかしたら会社によってはPMの首が飛ぶかもしれないんですが、自分の前職は結構年功序列でそう簡単には降格もしない会社だったので……きちんと段階を踏めば、PMよりさらに上の人に相談するのもアリだと思います。っていうかこの手段をとらないと、自分が潰されかねないようなプロジェクトもあると思いますので……。
◇周りの人の動きを見ておく
これは炎上を鎮めるためというよりも、後学のためなんですが。
「何が原因で炎上したのか」「どこをどの段階でどうしていれば炎上を防げたのか」「すごい人が助っ人で来たときに、何をしてどう動いて鎮火をしていったか」を観察して把握しておくと、今後自分が開発をするに当たってものすごく役に立ちます。というか私はそれが見たくてわざわざ立候補して燃えてるところに何度も飛び込んでいってたので。
世の中にプロジェクトマネジメントに関する教科書的なセオリーはたくさんありますが、よく見ていれば、それを実地で勉強することができます。
炎上してるときって当事者にとってはそれどころじゃないとは思うんですが、漫然と肉体を酷使するだけでなく、「ここから自分なりに学んで、次は炎上させないぞ」ぐらいに思っていろいろ見てると、得るものがありますし、その苦労を次のプロジェクトで活かせると思います。
■まとめ
どんな炎上も火種のないところで突然起こるわけじゃないので、よく見ていれば早い段階で火種が散らばっているのが見つかるはずなんです。
炎上プロジェクトの話が出ると、必ずPMがやり玉に上げられますが、逆に言うと、PMが的確にマネジメントできていれば、炎上を防ぐもしくは最小限でおさえることができるわけで……。
本来、PMは負荷がかかってるところ見極めて分散させたり調整したりしなければならないんですけど、そのためには末端の作業者でも、タスクを洗い出して協力したり、ときには上の役職の人に掛け合ったり、なるべく炎上を食い止めるためにできることはあると思います。
ただ、それも身体や精神を壊さない程度にして、あまりにもヤバい案件しか回ってこないような会社だったら、本気で転職を考えた方がいいかと思います。
ずっと炎上の話をしておいてなんですが……SIerというと炎上の話ばかりが目立ちますが、決してそんなプロジェクトばかりじゃなくて、いい案件もたくさんあるんです。でも、明らかに炎上しそうな仕事ばかりが回ってくるというのは、そもそもその会社に問題があったりするので……。
慣れてしまうと「プロジェクトは炎上して当然」みたいな感じで麻痺しちゃってる人もいるんですが、そんなはずはないんです。ITエンジニアの仕事って、身体を酷使して炎上をしずめることじゃなくて、ITで世の中を便利にしていくことですからね。
↓ちょいちょい出てきた画像の漫画はこちら↓
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
「paiza転職」は、自分のプログラミング力が他社で通用するか(こっそり)腕試しができる、IT/Webエンジニアのための転職サービスです。プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
また、paiza転職をご利用いただいている企業の人事担当や、paiza転職を使って転職を成功した方々へのインタビューもございます。こちらもぜひチェックしてみてください。
詳しくはこちら