品質を担保したい場合や大規模開発、長期間の開発を行う場合、ウォーターフォールでの開発手法がよく使われます。
ウォーターフォールは大まかに、要件定義、設計、製造、テスト、リリースといった工程で開発が行われるものです。
しかし、大規模リリースが終わり、瑕疵対応や追加対応が始まると、よく問題が発生します。
例えば、システムに影響のある重大な不具合が出たとします。開発規模が大きければ大きいほど、山のように不具合が出てきますよね。
そのような時、何も体制を変えることなく作業したとすると、エンドユーザが求めるスピードについていけないといった状況が出てきます。
それは、以下のような特性が原因となってると考えます。
・各工程間に、上長、クライアント、エンドユーザの承認が入る。
・承認がある為、ドキュメントをはじめから納品レベルで作成しなければならない。
・受け入れで問題発生した場合の手戻りが大きい。
私の現場では、レビューが作成の段階ではなく完成後のタイミングであったことや、開発者の設計書作成のレベルが低かった(要件を理解していなかったこともある！)ことがこれに重なり、3か月の開発が6か月にまで伸びました。
体制の変更はとても重要なものと感じます。
私個人の意見としては、追加開発や瑕疵対応のタイミングでアジャイル開発手法を用いることが、問題解消へ繋がるのではないかと感じています。
理由としては以下の通りです。
・開発者同士での評価をもらえる体制の為、有識者と連携して対応できる。
・プログラム製造前に、きっちりとした設計は行わないため、ドキュメント作成の時間短縮になる。(ドキュメントの作成が苦手な開発者が多い場合、メリットが大きい)
・納品する頻度が比較的高く、クライアント、エンドユーザへ仕事のパフォーマンスを見せることができる。
まとめですが、
手法としてアジャイル開発を挙げましたが、どちらの手法も積極的なやり取りが大事になってきます。
やはり、PJメンバー同士での密なコミュニケーションと、クライアントやエンドユーザからの理解・協力を得ることが、どこでも必要ではないでしょうか。
入会申込
ログイン
