前職について
自分と@hinamaruさんが5年以上務めていた会社
事業内容
金型切削加工機と光造形機のインテグレーション
開発プロセス改善コンサルとそのためのシステム
自分たちがいたのは後者の事業で、大体100人ぐらいのJavaとC++の開発者がいました
倒産を経験その当時は新丸ビルの37F, 31F, 30Fを貸しきってイケイケ
ただ倒産時フロア連結階段があって、その修繕費がすごくかかった
原因は、長野に作った完全無人工場の構築に失敗したこと
構築したが度重なるシステムトラブル、正しい加工精度が出ない問題
加工機のドライバやDBまわりの実装のコストが高すぎた問題
最後はシステム部署は数人なったので、大抵のIT企業には知り合いがいる
楽天, DeNA, Cookpad, mixi, ワークスアプリケーションズなどなど...
そもそも大体3割ぐらいITプロジェクトは失敗します
出典:日経コンピュータ2014年10月16日号26頁http://d.hatena.ne.jp/redips/20141025/1414202319
設計支援システムの失敗
自分がSLで7人チーム、ウォーターフォールで1年、大手十社以上採用
失敗内容
納期は間に合わせたが、運用開始後にバージョンアップ時に致命的なDB
コンバートミスが発覚
お客様の信頼を失った。信頼を失い証跡の提出義務が増加。
数社再リリース、各社向け月例品質会議の開始に
初めての2徹後出張を経験
設計支援システムの失敗の原因
一番最初に作った人が抜けてドメイン知識が大幅に欠損した
コンサルの要求変更を品質を盾に止めることができず、要求を受け入れてしまいウォーターフォールの手戻りを許容した
SLである自分が並走プロジェクト課題管理システム(半年、3人)のSLをやっていた
DBのスキーマが論理削除や複合主キーベースのテーブル構成だった
設計支援システムの教訓ドメインが複雑な場合は、開発技術よりもドメイン知識が重要な場合があり、しかもそれはすぐに補填できない
ウォーターフォールでは途中で要求変更を受け入れた場合、致命的な品質低下につながる
SLの能力を超えて複数チームのSLをすべきではない、他の人に委任した方がいい
2種複合主キーまだしも、6種とか7種複合主キーや論理削除前提テーブルはバグに繋がりやすい
新エンジンの原因予測
吉村の原因予測
長過ぎる社長/事業部長と進めるプロトタイピングプレゼン期間のため開発プロセスの制定ができなかった
様々なものに状態を持つことができるフローエンジン?(よく分かってない)の良い活用ができなかった
通信処理や並行処理の実装経験がないメンバーが多く開発したものが実用に耐えなかった
新スケジューラーの失敗
隣のチーム、4人で1年間、ウォーターフォール
失敗内容
お客様がいない中、開発を開始したが、完成後リリースされない時期が長かった
無理してお客様に導入してもらったが、要件が悪く使い物にならなかった
吉村の原因予測
具体的なお客様なしでの開発は難しい
お客様に磨かれるのが遅すぎると要件が悪くなる可能性がある
過去のプロジェクト全てを通じて 失敗後どういう風になったかプロジェクトが失敗した時にそこそこ人が辞めた
設計支援システム 7人中2人退職、新エンジン 5人中2人退職、新スケジューラー 4人中1名退職
みんな上司(自分)や組織に対する諦め、怒り、憎しみの業火に焼かれながら辞めていった
その結果、長い年月をかけて貯めた開発技術や既存ドメイン知識が失われた
まとめ
以下は仕方がないことである
プロジェクトは失敗する可能性がある
失敗すると叱咤も受けるしモチベーション低下からの退職に繋がりやすい
プロジェクトの失敗があろうがなかろうが、人は流動的なのでやはり常に開発技術、ドメイン知識の移転をしていきながら開発したほうが良い
具体的対策として開発技術とドメイン知識を組織のものにする方法
1.チーム見積もり2.ドキュメンテーション3.ペアプロ4.開発技術とドメイン知識の勉強会これらが順番に費用対効果として高いのではないかと思っています。
それでも退職率を下げたい
有給取得の取りやすい雰囲気を作る
長時間労働(残業)をしない働き方を推し進める
リーダーが以上を率先して実行し、やりくりをする
たったそれだけでかなり有効に効きます。過去2年間で37名のチームで退職者ゼロを実現できました。