過去自分が前職で経験したソフトウェア開発に関する失敗の話です。 とあるLTで発表しようと思ったのですが、機会を失ったので公開することにしました。

1. 失敗の話
吉村総一郎 (@sifue)

2. 今日は、前職で経験したり聞いた失敗プロ
ジェクトの話をします(守秘義務の範囲で)

3. 前職について
自分と@hinamaruさんが5年以上務めていた会社
事業内容
金型切削加工機と光造形機のインテグレーション
開発プロセス改善コンサルとそのためのシステム
自分たちがいたのは後者の事業で、大体100人ぐらいのJavaと
C++の開発者がいました

4. 倒産を経験
その当時は新丸ビルの37F, 31F, 30Fを貸しきってイケイケ
ただ倒産時フロア連結階段があって、その修繕費がすごくかかった
原因は、長野に作った完全無人工場の構築に失敗したこと
構築したが度重なるシステムトラブル、正しい加工精度が出ない問題
加工機のドライバやDBまわりの実装のコストが高すぎた問題
最後はシステム部署は数人なったので、大抵のIT企業には知り合いがいる
楽天, DeNA, Cookpad, mixi, ワークスアプリケーションズなどなど...

5. その中で経験したり聞いた失敗したプロ
ジェクトの話をします(守秘義務の範囲で)

6. プロジェクト一覧
設計支援システム - 自分がSL
新エンジン - 同期がいた隣のチーム
新スケジューラー - 隣のチーム

7. プロジェクトにおける失敗とは
当初予定していた品質・予算・納期（QCD)を遵守できな
かったこと、とここで定義します

8. そもそも大体3割ぐらいITプロジェク
トは失敗します
出典：日経コンピュータ2014年10月16日号26頁
http://d.hatena.ne.jp/redips/20141025/1414202319

9. まあどんなに頑張っても3割ぐらい失敗してしまうものです。
ただ3割を超えてくると何か問題があるかもしれないと疑ったほうがいい。
それを踏まえた上で気軽におじさんの昔話を聞いてもらえればとおもいます。

10. 設計支援システムの失敗
自分がSLで7人チーム、ウォーターフォールで1年、大手十社以上採用
失敗内容
納期は間に合わせたが、運用開始後にバージョンアップ時に致命的なDB
コンバートミスが発覚
お客様の信頼を失った。信頼を失い証跡の提出義務が増加。
数社再リリース、各社向け月例品質会議の開始に
初めての2徹後出張を経験

11. 設計支援システムの失敗の原因
一番最初に作った人が抜けてドメイン知識が大幅に欠損した
コンサルの要求変更を品質を盾に止めることができず、要求を受
け入れてしまいウォーターフォールの手戻りを許容した
SLである自分が並走プロジェクト課題管理システム(半年、3人)の
SLをやっていた
DBのスキーマが論理削除や複合主キーベースのテーブル構成だっ
た

12. 設計支援システムの教訓
ドメインが複雑な場合は、開発技術よりもドメイン知識が重要な場合
があり、しかもそれはすぐに補填できない
ウォーターフォールでは途中で要求変更を受け入れた場合、致命的な
品質低下につながる
SLの能力を超えて複数チームのSLをすべきではない、他の人に委任し
た方がいい
2種複合主キーまだしも、6種とか7種複合主キーや論理削除前提テーブ
ルはバグに繋がりやすい

13. 新エンジンの失敗
同期が入っているチーム、5人で2年間
開発フローなし (デザインレビュー等の承認フローなし)
失敗内容
お客様へのリリースがされなかった

14. 新エンジンの原因予測
吉村の原因予測
長過ぎる社長/事業部長と進めるプロトタイピングプレゼン期
間のため開発プロセスの制定ができなかった
様々なものに状態を持つことができるフローエンジン?（よく
分かってない)の良い活用ができなかった
通信処理や並行処理の実装経験がないメンバーが多く開発した
ものが実用に耐えなかった

15. 新エンジンの教訓
開発プロセスを導入して、要件定義や各設計の承認フェー
ズがあったほうが良い
必要な開発技術がない場合には、無理せず得意なエンジニ
アを呼んだ方が良い

16. 新スケジューラーの失敗
隣のチーム、4人で1年間、ウォーターフォール
失敗内容
お客様がいない中、開発を開始したが、完成後リリースされない時期が長かった
無理してお客様に導入してもらったが、要件が悪く使い物にならなかった
吉村の原因予測
具体的なお客様なしでの開発は難しい
お客様に磨かれるのが遅すぎると要件が悪くなる可能性がある

17. 新スケジューラーの教訓
具体的なお客様ユーザーが決まってから開発をすべき
お客様に使って磨いてもらわないと求められる機能と実際
の機能との乖離が大きくなる

18. 過去のプロジェクト全てを通じて
失敗後どういう風になったか
プロジェクトが失敗した時にそこそこ人が辞めた
設計支援システム 7人中2人退職、新エンジン ５人中2人退職、
新スケジューラー ４人中1名退職
みんな上司(自分)や組織に対する諦め、怒り、憎しみの業火に
焼かれながら辞めていった
その結果、長い年月をかけて貯めた開発技術や既存ドメイン知識
が失われた

19. まとめ
以下は仕方がないことである
プロジェクトは失敗する可能性がある
失敗すると叱咤も受けるしモチベーション低下からの退職に
繋がりやすい
プロジェクトの失敗があろうがなかろうが、人は流動的なので
やはり常に開発技術、ドメイン知識の移転をしていきながら開
発したほうが良い

20. 具体的対策として
開発技術とドメイン知識を組織のものにする方法
1.チーム見積もり
2.ドキュメンテーション
3.ペアプロ
4.開発技術とドメイン知識の勉強会
これらが順番に費用対効果として高いのではないかと思って
います。

21. それでも退職率を下げたい
有給取得の取りやすい雰囲気を作る
長時間労働(残業)をしない働き方を推し進める
リーダーが以上を率先して実行し、やりくりをする
たったそれだけでかなり有効に効きます。
過去2年間で37名のチームで退職者ゼロを実現できました。

22. 失敗に関わるおすすめの本
デスマーチ
システム障害はなぜ二度起きたか

23. 以上
ご清聴ありがとうございました