はじめに
ウォーターフォールという開発プロセス自体を否定する気はありません。
つくるものが明確でしっかり管理されていればもっとも効率よくシステムを開発できるプロセスだと思います。
しかし、どの会社やプロジェクトも同じ失敗を繰り返しています。
こんなプロジェクトがいくつも続き、破格の見積りが通ったプロジェクトで利益を得ています。
もしくは有能な管理者がいるプロジェクトで臨機応変にアジャイルやスパイラルのような手法を混ぜて進めているおかげでプロジェクトが成功を納めているケースもあるでしょう。
15年ほどいろんな会社やプロジェクトに参画させて頂きました。比較的大きなプロジェクトに参画することが多かったのでIT関係者以外の人が聞いてもみんな知ってるほどの名高い大企業がほとんどです。
そこで私がウォーターフォールと名乗るプロジェクトでも成功を見たのはすべてスパイラルやRUP(Rational Unified Process)のようにフェーズ内で設計と製造を繰り返したり推敲フェーズのようなタイミングで技術的な準備するなど、「デキる管理者」がコントロールしているプロジェクトでした。
あなたのプロジェクトが以下のどこかの段階を迎えているなら、
一度立ち止まって改善すべきではないかとよく考えてください。
よくある失敗の流れ(フィクションではありません)
- 要件定義が長引く(やりたいことがすべてわかるわけがない)
- 基本設計は更に長引く(実際に整理するとやりたいことが増えてくる)
- 納期までの工数が減ってきたので詳細設計は適当になる
- 詳細設計終わってないのに報告上終わったことにして製造フェーズ突入
- 時間がないので人員を増やす(短期間で一気に工数を使い果たす)
- 急に集めた人員なのでエンジニアの能力差は当然バラバラだけど教育する時間もない
- 設計担当はボトルネックになりてんやわんや
- 詳細設計と製造を並行でやるので手戻りしまくり
- 納期を守るためといういいわけでテストコード作らない
- こんな詳細設計でオフショアやニイショアやって更に悲惨なことになる
- オフショア・ニアショアで製造された画面がほぼ動かない
- オフショア・ニアショアともめる
- 結局引き取ったプログラムを修正しまくる(ほぼ作り直す)
- 製造終わってないのに報告上終わったことにしてテストフェーズ突入
- 単体テスト終わってないのに結合テストフェーズに突入
- 詳細設計と製造とテストを並行でやる
- 仕様変更も来るのでさらに工数は圧迫
- 基本設計・詳細設計はあとで修正することにして製造だけやる
- テストフェーズだけどやってることは不具合修正の毎日(実際には製造)
- なんちゃって結合テストを終えてシステムテストや受け入れテストをする
- このときはじめて動くシステムを見たユーザから指摘が大量発生
- 終わってない製造とユーザからの指摘対応と仕様変更でもはや収拾不可能
- 連日の残業や休日出勤は当たり前で開発メンバーは疲労困憊(メンバーもミスもうなぎのぼり)
- なぜリスケしないのかと内部から反発出まくり
- リリース日直前になってリリース日延期
- リリース日延期とリリース対象を縮小する
- たいして延期しないのでリカバリーできるわけもなく品質ぼろぼろで数を揃えただけの状態で本番開始
- 不具合対応と緊急リリースに追われる毎日
- プロジェクトは赤字で一旦本番を迎えたのでエンジニアを手放す(開発メンバーは9割が外注)
- リリース対象を縮小した分すぐに二次開発がはじまる
- やることは山ほどあるのに人が減りメンバーへの負荷はさらに上がる
- 引継もろくにないので未開のプログラムを解析しつつ不具合対応する(デグレ発生可能性が上がる)
- 未開の仕様を確認したくても設計書はメンテナンスされていないので謎だらけ
- 年単位の不具合対応を経てやっと安定
- 何年も経ってるうちに要望や世間の情勢も変わる
- その間も仕様変更しまくる
- そうする間にミドルウェアやフレームワークのサポート期限が間近になる
- リプレースしましょうと提案
- ミドルウェアやプログラム言語などバージョンがかなり変わっていて移行はかなり難航(かなり作り直し)
- テストコードがないので手動でテストし直し(莫大な工数)
代表的な開発プロセス
- ウォーターフォール
- アジャイル
- SCRUM(スクラム)
- XP(エクストリーム・プログラミング)
- カンバン(リーンソフトウェア開発)
- スパイラル
- プロトタイプ
- ラショナル統一プロセス(RUP)
まとめ
システム開発のプロジェクト管理をやっている方はぜひともこの辺りを一通り確認することをおすすめします。
また、システム開発としては初心者という人も開発プロセスを意識しあなたのチームでプロジェクトの成功を勝ち取るための積極的に模索してください。
技術はほとんどが調べれば解決できると思いますが、マニュアル通りやってもうまくいかないのがプロジェクトの進め方です。一つのやり方だけではないことを知り、開発プロセスの型にはまるのではなくチームに合わせて柔軟に組み合わせる必要があると思います。