底辺SESエンジニアが見た炎上プロジェクトあるある

底辺ってのは、責任が少なく心に余裕があるので、意外と周りがよく見えます。そこで、今回は底辺から見た炎上プロジェクトの特徴なんかを紹介できたらと思います！

底辺アピール

まずは自分の底辺っぷりをアピールするために自己紹介をしようと思います。

• 10年以上4次受けで働いている

• 一度も自社の先輩と仕事した事がない

• 新人の頃、ソロで出張と題した関西常駐

• 5年目で先輩が全員辞め、最年長に

• 未経験文卒中途

• フリーター上がり

どうだ、まごう事なく底辺だろう！
とまあこんな感じでよく見るブラックSESみたいな生い立ちで仕事をしてきた訳ですが、お陰でつよつよメンタルのエンジニアになる事ができました。サンキュー底辺。

炎上の定義

人によって炎上とは何か、が異なるような気がしたので一旦炎上の定義をしておきます。

炎上とは
スケジュールが遅延し、リソースも足りず、解決すべき問題がプロジェクトのキャパシティを超えてしまっている状態
です。
私の経験上、だいたいの場合、結合試験くらいのタイミングから荒れ始めます。正確に言うと開発タイミングで荒れてはいるんですが、このフェーズでは未確定な部分はとりあえず空実装しといて終わったことにする、みたいな対応を取ることが多いです。スケジュール的に問題がない、という見せ方をする訳ですね。嘘つき！
んで、嘘を本当にするために頑張ろうとするけど、時すでに遅し、みたいな。いやあ、怖いですねえ。

炎上プロジェクトあるある

さて、ここからが本題ですね。プロ底辺エンジニアの私が思う、炎上プロジェクトあるあるを紹介していこうと思います！

決定したがらない

炎上プロジェクトでは、仕様の決定、方針の決定など、とにかく決めなければいけないことを先延ばしにする傾向があります。決定権があるはずの人すら、上司に相談してから〜とか言い始めます。とても日本らしいですね！ちなみに、顧客と開発ベンダーが双方歴史が長い企業の場合に良く見られる現象です。稟議稟議ぃ！

打ち合わせが大好き

目的が分からない謎な打ち合わせが常態化します。特に定例と題した打ち合わせには要注意です。上流工程で口を挟むくらいしかできないおじさんたちが気持ちよくなるためのイベントであり、そこに中身はありません。
不思議なことに、こういう打ち合わせに限って議事録が作成されないケースが多いです。話の内容が外にバレるとまずいのでしょうかね。会議が始まってから議題が決まるからね、しょうがないね。

上流工程担当者のスキル不足が顕著

上流工程はシステム開発のフローに置いてとても重要な位置づけの筈ですが、何故かスキルがないおじさんが担当している事があります。
しかも驚くことに、一部の担当者がスキル不足と言うわけではありません。かなりの割合の担当者がスキル不足なのです。
で、ある程度工数を食った後で、優秀な中堅が合流して尻拭いが行われる訳ですね。スキル不足おじさんにギリギリまでスケジュールを遅延してもらって、金を稼ぐビジネスモデルなんじゃねえかな？とか思ってしまいます。
新しいプロジェクトに入ったら、要件定義と基本設計、周りで働いている人の年齢層を見てみると、何となく未来が見えて面白いですよ。

ドキュメント体裁への熱いこだわり

フォント、フォントサイズ、印刷や罫線など、おおよそ設計と関係ない場所への熱いこだわりが見られます。残念な事にレビューでそんなところを指摘してもシステムの品質は向上しません。こういう部分をウキウキで指摘する人が正しいとされる風潮が未だに残っているプロジェクトがあります。
流石に印刷して罫線やら文字のはみ出しやらを確認する、と言うのはあんまり見なくなりましたが、恐らく古い体質のプロジェクトだとまだ残ってるんじゃないかな、と推測してます。紙もったいねえ。

他チームとやりとりする人の文章がクソ

本来であれば対外のやりとりは円滑なコミュニケーションができる人がやるべきです。しかし炎上プロジェクトでは、何が言いたいのか分からない不思議な文章で、受け手の脳を混乱に導く輩が蔓延っています。
プロジェクト参画時にQA票なんかを見てみると、おおよそプロジェクトの荒れ具合が見えるのでやってみましょう。
ちなみにこのポイントは、炎上がどの程度長引くかに大きく関連します。逆にここがしっかりしていれば、炎上したとしても円滑に問題解決ができるでしょう。

本来プログラム組む人が管理してる

炎上しているプロジェクトはとにかく人を増やしてどうにかしようとする傾向があります。しかし、こういう状態のプロジェクトに送り込まれるのはスキル不足なエンジニアである事が多いです。コピペでコードが書ければ良い方、場合によってはそれすらできません。コピペは最低限コードが読めないとできないですからね。
で、こんな状態なのに、本来リードエンジニアとしてのスキルを持っているエンジニアが、開発の進捗管理をしていたりします。恐らく自分でコードを書いたほうが品質はいいし、スピードも早いです。が、謎に増やされた人員を動かすために、管理作業を任せられてしまうのです。
これは特に開発経験に乏しいマネージャーがやりがちで、プロジェクトがこの状態になっていたら、恐らくその先も上手くいきません。
日本は何故かプログラマーが軽視される風潮がありますが、良いプログラマーが良いコードを書いていれば、バグ対とかで工数を食うリスクは少なくなりますよね。
これが分かっていない割り振りが行われているのであれば要注意です。

予定していない成果物が爆誕

本来は成果物を先に決めて見積もりをする訳ですが、プロジェクト進行時に予定していない成果物が生まれ出てくる事があります。まあこれ自体はよくある事な気がしますが、限度はあります。
これが常態化すると、メインタスクが振られていない、はたから見たら何をしているか分からないポジションの人が発生したりします。たぶんその人は犠牲者です。優しくしてあげましょう。

私は炎上に育てられたエンジニアだ！

ここまで炎上プロジェクトあるあると題して、炎上プロジェクトの特徴を挙げてきたけど、個人的には炎上に助けられた部分も少なからずあります。
恐らくフリーター上がりの文卒未経験エンジニアがここまで生きてこられたのは、炎上プロジェクト特有の採用ハードルの低さが起因しているし、割と早い段階で開発を経験できたのも、これによる部分があるでしょう。
もちろん月350hを超える稼働をしたり、ブチギレて二次請けのマネージャーとガチ喧嘩した事もあったりしましたが、それも今では良い思い出です。たぶん。冷静に考えると、あんとき25歳とかだよな、ワイやばいヤツすぎて草。
もっとも後輩たちにそんな経験はして欲しくはないし、今は私が未経験の方にエンジニアの仕事を教える立場でもあります。自分がしていた経験は一般的には間違っているルートだと思います。
近年、IT業界の体質は大きく変わってきており、法外な残業などは目に見えて減ってきていますし、私を雑に扱っきた弊社でさえ、新人は先輩のもとで経験を積む構造になっています。しゃちょう！マジで俺に感謝したほうがいいぞ！みんな辞めてるんだからな！　
私は炎上プロジェクトで成長してきましたが、今後炎上プロジェクトを起こさないように振る舞わなければならない。
そんな覚悟をもって締めたいと思います。
ここまで読んでくれた方、ありがとうございました。