逃げろ！　炎上案件の5つの兆候と付き合い方

はい、どうもこんにちは！

システムエンジニアをやり始めて3年目くらいの七堂です！

ここ最近は、炎上案件に付き合っています。

Twitterでは3ヶ月に1回燃えてるよな

それ。

一年間の半分は炎上案件に付き合っていて、３６協定に引っかかりましたよ！

この前なんて、月の上限を突破させましたからね。

さて、そんな、炎上案件ソムリエとも言える私が、炎上案件にありがちな兆候を紹介します。

炎上案件ソムリエ……

解決するか、逃げるかはあなた次第。

後半では、炎上案件との付き合い方を紹介しますね。

IT業界の商流について

さて、本題です。

と言いたいところなのですが、少しだけIT業界の仕組みを紹介させてください。

コレがわかってると、後半の記事が読みやすくなりますから。

設計フェーズ

自社開発でない場合、必ず、発注と受注があります。

「こんなプログラムを作って」依頼があって、初めて成立するんですよね。

依頼があると、要件定義・基本設計と言って、どんな機能がほしいのか、整理する作業が始まります。

何が作りたいのかわからないと、何もできませんからね。

「おまかせ」って注文ほど怖いものはありません。

あとから文句言われたら、それまで作ってきたことが、無駄になるわけですから……。

ITは大黒柱を折りに行く変更を容赦なくかける

ほんとそれ。

美容院で「お任せ」って言うのとは、規模が違います。

お仕事の内容によっては、この段階でデザインとWEBサイトの動きの部分を作っておきます。

最近の案件だと、ここをしっかり作ることが多いですね。

WEBデザイナも設計段階で関わることが多くなってきたので、利回りがだんだん良くなっている気がします。

製造フェーズ

さて、設計が終わったら、お楽しみのプログラミングです。

詳細設計と言って、プログラミングの大まかな流れを整理したり、実際にコードを書いたりします。

最近では、ツールの進化から、詳細設計をやらないお仕事も、増えてきました。

複雑なロジックでなければ、プログラミングをするのはそこまで難しくなくなってきましたから。

プログラミングも誰でもできる仕事になってきたよね。。。

テストフェーズ

製造である程度動くプログラムができたら、ひたすら操作をして、バグが発生しないか確認します。

プログラム単体をチェックする「単体テスト」。

プログラム同士の動くを確認する「結合テスト」

全体の流れを確認する「システムテスト」と複数のテストを行います。

優れたエンジニアが多いお仕事では「単体テスト」は、省略することが多いですね。

細かいバグなんて起きませんから！

キリッ。

性格がバグってるで……

ひどいな………

まぁ。バグは小さうちに潰しておかないと、後々苦労するので、予算に余裕があるなら、やっておくべきだとは思っています。

バグが出たら、即対応で、上手く潰していきます。

ここが一番燃えるんですよねー

設計と製造での不備を引づっていることが、多いですから。

IT業界の一連の流れは、こんな感じです。

詳しく言うと。

「要件定義」「基本設計」「詳細設計」「製造」「単体テスト」

って流れですね。

IT業界に行きたいと考えている方は知っておくと良いですよ！

炎上案件に見られる5つの兆候

さて、本題です！

炎上するお仕事に見られる兆候を紹介しますね！

発注側が何をしたいのか明確でない

要件定義・基本設計での問題ですね。

酷いところでは、「どういった事をしたいのか分からないけど作って！」って着ますからね！

え？　それホントに発注元？

それな、すごくツッコみたい………

いや、たしかに、それを整理してあげるのも、システムエンジニア仕事のですよ！

でも、当事者がよくわかっていないってことが多いんだよね……。

特に、ここ１０年位で、色々なサービスや企画を打ち出しているせいで、起業のビジネスモデルも複雑になってきています。

「この商品とこの商品を組み合わせたら、割増になって。この特典がついて、○年たったらこのプランにして……」

って、管理できるわけが無いですからね！

１回の交渉で成立する、八百屋みたいな商売なら、良いのです。

でも、システムを作るとなると、数十年規模で続きます。

それが積み重なって、あれよあれよと人が管理できない状態に……。

キャンペーンを作ったり、新しいプランを作るのは良いとは思います。

ただ、その裏にはシステム的な問題がたくさんあるのです。

企画や広報の方は、そのへんも理解してくれると嬉しいですね！

毎年プランを打ち出している保険会社や携帯会社は闇深そう

うん、深いよ。基本的に触れないほうが良いよ！

現行踏襲はほとんどが地雷

こちらもよくある要件定義・基本設計での問題。

だいたい、「現行踏襲」は地雷です。

そもそも、最近の案件では、現行の隅から隅ませ知っている方はいません。

さっきも言ってたな……

ただ、要件定義の時間を削除するためだけの魔法のコトバで、全くできていないことが多いです。

だって、こういう操作をしたら、どのエラーメッセージが出るとか、複雑過ぎて記憶できませんからね！

さらに、顧客にシステムをお披露目すると、ひどいことになります。

「いままでのシステムでは○○ができたのに、今回は○○ができない」

ってね。

「いや、それ、仕様整理してないじゃん。」

って突っぱねるのが筋なのですけど……。

日本の場合は、お客様は神様だから、仕方ないよね……。

せつねぇ

殆どは、デザインやUIに関わるところなので、簡単に直してあげられます。

「ここの色合いを濃くして」「位置を2pxずらして……etc」とかですからね。

ただ、本当に時々なのですが、大黒柱を壊すような提案もあることがあり……orz

ひえっ

顧客との力関係が弱すぎる

今度はプランニングの問題です。

顧客との力関係が弱いと、予算を絞られます。

そうなると、ギリギリの予算で依頼してくるんですよね。

炎上するリスクが、非常に高いです。

ギリギリの人数で回すって、リスク管理できていないんじゃ？

それな。

しかも、最近は、さらに予算を絞っている印象があります。

そのせいで、案件に携われる人数が限られてしまい、一人あたりの負荷が大きくなるんですよ………

一人が潰れれば、ものすごい負荷が周りに飛散するという……

ひえっ

そのような関係になりやすいのが、メーカー系SIerです。

ヤバいからあれ、ホントに、ヤバいから！

なにか嫌な記憶でも？

うっ、頭が！

予算は常にギリギリです。

ギリギリの予算でやるって、残業前提ですからね！

特に、こうなるのは、金融系のSIerに多い印象があります。

こんなことがありました。

一昔前の話です。今は、ちょっとはマシになっていますけど………

お金でスキルが買えると思ってる？

それな。

お金を積んで、いきなり開発速度が上がるのは、ゲームの世界だけでして……

どんなに優秀なエンジニアでも、技術と仕様を把握するまでに時間がかかります。

金融系は資金が潤沢にあるせいか、そのへんの価値観が狂っていることが多いんですよね………

特に、保険会社のSIerはヤバい……。

一緒に良いものをつくろうって感じではなく、完全に子会社状態ですから……。

メーカー系SIerの宿命だねー

そして、人を入れれば、なんとかなるって考えが強いせいか、開発環境も貧素であることが多いです。

画面1枚、メモリ2Gのマシンで何をしろと……。

エクセルが定期的に落ちるんですが……。

行コピーを元に戻すと、フリーズするのですが………

案件を選べるなら、金融系/保険会社は避けたほうが良いです。

魂の叫びだ……

スプリントを切らないアジャイル開発

こちらもプランニングの問題です。

最近では、アジャイル開発の手法を取り入れる事も多くなりました。

アジャイル開発って知ってますかね？

通常はウォーターフォールと言って、設計をしたら、戻らないのが基本です。

でも、アジャイル開発は製造をしていく中で、不備や改善点があれば、設計を修正することができます。

理想的な開発では？

そう、理想的に動けば！

理想的に動ければ、品質が高いものができ、顧客から文句も言わることもありません。

ただ、ここにも地雷が潜んでいます。

ちゃんとした手順を踏まないアジャイルは、地雷です。

アジャイルの手順？

ちゃんと管理されたアジャイル開発は、スプリントとという期限を短いスパンで切って、その中でできたものを顧客に見せて、フィードバッグをもらいます。

エンジニアを目指しているなら、一度検索してみてください。

さて、問題は手順を踏まないアジャイル開発です。

この場合、顧客の言いなりになりやすいんですよね………

期限が切られていないため、顧客側が期限の意識をできなくなります。

そのせいで、本質的でないところに文句を言われ続けて、遅延して、炎上することに………

本質的でない？

縁取りが見にくいとか……そのへん………

プログラマのスキルが低すぎる

最後の最後で「詳細設計」「製造」「単体テスト」の問題です。

スキルが低すぎる人材がいると、急激に苦しくなるんですよね……。

プロジェクトは、かけた人数によって、成果を求められます。

なので、スキルが低い人材が入って来ると、周りがかなり、がんばってフォローしなきゃいけないんですよ！

この前なんて、この道20年のベテランに、新卒がやるようなSQL教えましたからね……。

ベテランに基本的なことをかぁ……

流石にSQLはモダンな技術じゃないからねぇ。

ちょっと引きました………

IT人材は、「ショパンを弾ける人材」と「猫踏んじゃったしか弾けない人材」で例えられますね………

「猫踏んじゃったしか弾けない人材」を10人集めたところで、ショパンは弾けるようにならないんですよ！

いや、ある程度は、難しい部分を共通化して、ごまかせます。

でも、限度があるんですよね………

結衣、プロトタイプ作成や共通化部分を作るタスクが多いので、ここの苦しみがよく分かる………

自由にプログラムを書かせたいけど、それだとスキルのバラツキから大変なことになるんですよねぇ………

炎上案件との付き合い方

炎上案件に携わっていると、間違いなく潰れます。

36協定を越えなくても、潰れます………

大事なことなので２回言いました

ほんとそれ。

ってか、頭を使うエンジニアの仕事で、40時間の残業とか、拷問ですぜ！

それが、3ヶ月も続いてみてくださいよ………

無理です。

潰れた方々を何人見てきたことか………

ひえっ

「要件定義」「基本設計」に関わって、燃えている場合は、ほとんど顧客側の協力が取り付けられないから起こります。

逃げましょう！　

「プランニング」で燃えている場合は……こちらから、何を言っても、変わらないことが多いです。

逃げましょう！　

プログラミングで炎上している場合は、逃げましょう！　

自分たちの手で、どうにかするって難しすぎるので……。

どんなに効率化したところで、1.5人分くらいしかパワー出ませんから………

基本は逃げですね！

そうそう、だって、精神を病んだ方が、何倍も損失が大きいわけで………

下働きだろうと、長い間働けた方が良いですからね………

逃げられない場合は？

会社から派遣されていて、どうしても逃げられない場合は以下の対処がおすすめです。

基本的には与えられたタスクだけを守るように動きます。周りは対応できなくて沈んでいくので、それだけで、評価が上がりますよ！

もちろん、この状態のときは、人を助けるようなことはできません！

それができたら、スーパーマンなわけでして………

・他の方のタスクで、前に進まない場合は交渉する。

よくあるのが他人のタスクが終わらず、自身のタスクが完了できない場合です。

できない理由をつけて、無理と言いましょう！できない理由があれば、タスクを完了しなくても免罪符になります！

・次の仕事につながる可能性がある場合は、渦中(あえてこの字)の栗を拾う選択肢もあり。

フリーランスとかはこちらかな。炎上している案件に長いこといると、かなり信頼されます。

次の仕事につながる可能性があるときは、あえて、燃えている案件を拾うのもありです。

戦略ですよね………

まとめ

炎上する兆候を感じたら、逃げることをメインで考えましょう！

潰れたときの損失が大きすぎるので………

恩を売って、

もし、なんとかできる立場の場合は、火種が小さいうちに摘み取るのが、大切です。