19
29

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

なぜ炎上する開発案件があるのか?考えてみた

Posted at

10年くらいエンジニアやっています。その中で、開発が炎上したなぁとか、うまく行ったなぁとか、振り返ってみると実力以外のところに要因があったことも多かったので、そのへんを書きたいと思います。

人によっては、違うと思われる方もいると思いますが、1エンジニアの所感と思ってくださいm(_ _)m

火種達

  • リテラシの低さによる無茶振り
  • 開発途中の品質チェックを細かく出来ていない
  • マネジメント側のキャパオーバー
  • マネジメント側がエンジニアの言った工数で必ず出来ると捉えてしまう
  • 作業者のモチベーションの欠落
  • 作業者の実力不足

経験上、ざっくり上げると上記の要因があると思います。作業者の実力不足以外は、マネジメント側でコントロール出来るのでは?と思います。

リテラシの低さによる無茶振り


ある程度システムについて知っていれば、何に時間が掛るのか?とか、何が出来るのか?とかわかると思います。作業を振る側の人も勉強してほしいなぁと。

少なくとも、httpとhttpsの違いくらいは知っていてもおかしくないと思います。

どこかの会社では、職種が違うペアで、ペアプロをやるらしく、これはかなり面白いのでは無いか?と思います。お互いの作業を説明しつつ、相互理解を深められると思います。

開発途中の品質チェックを細かく出来ていない


ゴールが明確じゃないと完成にまでは至らないと思うのですが、新システムを作る段階で最終形が見えていることは無いと思います。

最終形が見えないなら、細かく作業を区切って完成チェックをしていけば良いと思います。

全部できあがってからチェックするよりも、1週間とか2週間単位でチェックポイントを設けて、軌道修正していくほうがお互い前進している感じがすると思います。(ウォーターフォール開発でも、細かくチェックしたほうがいいと思います。)

こちらだと結果的に期限が延びる仕様変更になるはずなので、作り手も疲弊しないで済むと思います。

マネジメント側のキャパオーバー


上の話とも関係があるのですが、細かくチェックしようとすると、マネジメント側の作業負荷が指数関数的に増大します。たいていの日本の会社はマネジメントする人は偉い人となっていて、偉い人は人数が少なくて、人数が少ないから細かいチェックが出来ず、結果丸投げするしかないという感じなのでは?と思います。

タスクをどんどん遅延させてしまう人に、何故遅延させてしまうのかヒアリングした時の話

こちらを読むと個人的には手がかかるなぁという印象ですが、日本人は丸投げクラスに作業を振りすぎなのかもしれません。丸投げしておいて、3ヶ月後に出来ていないじゃないか!!とか、それはエンジニアの責任なのか?と思ったりもします。

マネジメント側の人数が足らないことによるプロジェクトの遅れは可視化されづらいと思っています。制作進行係を複数人用意してもらうか、用意できないのであれば遅れる可能性が高まると考えて貰えれば良いなぁと思います。

マネジメント側がエンジニアの言った工数で必ず出来ると捉えてしまう


ソフトウェア開発の失敗確率と、原因が上流工程にあるという根拠データを確認してみた

システム開発がうまくいく可能性が20%という統計結果があるので、大掛かりなシステム開発は見積もりの通りには完成しないと思ってほしい。

エンジニアが正確な見積もりを出せないのが悪いというよりは、作っていくうちに仕様が変わることが多いので、正確に見積もりを出すことは不可能。というのが正しい認識だと思います。

きのこ本 [49] 見積りとは何か

PM「機能xyzの件だけど、開発期間はどのくらいだと見積もってる?」 プログラマ「1ヶ月ですね。」 PM「長すぎる。1週間で何とかならないか。」 プログラマ「どんなにがんばっても3週間は必要ですよ。」 PM「2週間、それ以上は無理だな。」 プログラマ「わかりました。それで手を打ちましょう!」

こういうことをしていると、うまくいかないと思います。

見積もりには、会社の行事や会議等への出席などの時間は考慮されていません。

開発期間が長くなればなるほど、コーディング以外の作業が多くなるため、見積もりはより不正確になっていくと思ったほうが良いです。

事例によるスケジューリング

個人的には、こちらの手法を使えばある程度、正確な未来を予測できる気がします。(記録をつけていくのが大変なので、このへんも制作進行係がやってくれるとうれしいです。)

作業者のモチベーションの欠落


  • これ必要ないよなぁとか、腑に落ちないよなぁと思って開発するとめちゃめちゃ時間が掛かったりします。
  • 自由度の低い開発だと、本人のやりやすいように出来なかったりするので時間がかかったりします(Windowsしか開発に使えないとか、何するにしても申請書が必要とか)

マネジメントする人と、

  • しっかりと話をする
  • 開発環境改善をしていく

ほかないと思います。

しっかりと話をする

マネジメント側が時間を割いて説明するしかないかと。

あと、花形システムと裏方システムに見えるものがあって、裏方ばっかりやっていると、俺達は2流エンジニアか?とか、思ったりもするので、そのへんについてもケア出来る体制にしてほしいです。下記が個人的に良いなぁ思う体制です。

フェイスブックは業務を自動化して社員を「過去の仕事」から解放した

開発環境改善をしていく

開発環境については、セキュリティ気にして禁止事項を増やすことが多いと思います。そうではなく、セキュリティも担保した開発しやすい環境を作ってほしいです。
(個人的には、Linux Mint使いなので、LinuxOSを正規に使える環境を用意してほしいです。ライセンス料も安いはずです。)

作業者の実力不足


雇ってみたけど実力不足だったということもあると思います。エンジニアも、分業体制が整っている現場でずっと働いていると、担当範囲が狭く、転職して広い範囲の仕事を任せられるとやったことがなく、出来ないということもあると思います。

これに関しては、個人的には試用期間として現場に入ってもらって、実力を認めた人だけを雇うというのが良いと思うのですが、それだとコストが掛かりすぎるとか言われそうな気もします。(フリーランスとかアルバイトで、とりあえず入れる入り口があるとか良いと思うのですが、どうでしょうか?)

より高みへ

マネジメント側の人へ


番外編 海外の残業

「上司が嫌だ」「あの同僚全然仕事できない」といったストレスは全く無かったです。

こういうことが出来る現場は存在するので、僕らもやれば出来るはずです。キーワードは、「あいつは出来ない無能だ!!」ではなく、「なぜ出来ないのだろう?改善する手立てはないか?」だと思います。

スティーブ・ジョブズも

『即戦力になるような人材なんて存在しない。だから育てるんだ。』

と言っています。

今いるメンバーで最高のパフォーマンスを発揮できる方法はないか?と考えて手を打っていける現場にしてほしいです。

偉い人へ


日本人はルールを守ることばかり重視して、ルールが形骸化しても遵守するとかやっていることが多いと思います。現場の人間が間違っていると思うルールがあるなら変えていける職場にしてほしいです。(偉い人がルールの決定権をもっているので、ここだけは本当にお願いします。)

エンジニアへ


エンジニアが貴重だからか?権力を持っている現場があると聞きます。それを悪用して、会議があるのに来なかったり、出来るはずだけど難しそうだから出来ないと言って終わらせたりする人も居ると聞きます。腕と工数さえあれば、大抵のことは出来ると思うので、悪用せずに権力を有効活用してほしいと思います。

全体を通して

大半の人は、働いている時間が一番長いと思います。そこが楽しいと思える会社と、苦しいと思う会社。自分の置かれている状況によっても色々あると思いますが、システム開発が楽しいものだと言える現場が多いといいなぁと思いました。

19
29
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
29

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?