システム開発手法の進化：ウォーターフォールからアジャイル、XPまで

「どんなシステムが必要か？」をお客様と相談して決定する重要な上流工程です。

システムの機能要件・非機能要件・制約条件・バジェット（予算）など、プロジェクトの土台となる情報を集め、具体的にどのようにプロジェクトを進めていくのかを大まかに決定するフェーズです。

受注者・発注者それぞれが明確な妥結ラインを見いだせていない場合、受け入れテストの段階で納品拒否や最悪訴訟に発展するケースも見られるので、明朗・明確な合意を引き出せると良いでしょう。

想定される成果物：
・システム化対象の業務フローの洗い出し
・機能要件（システムの主なユースケース・シナリオ）の策定
・非機能要件の合意を得る（セキュリティ・ピーク時想定アクセス・サーバー負荷）
・実行計画（ヒト・モノ・カネなどのリソースの洗い出し）
・ステイクホルダーの担当工程の洗い出し

エンジニアが要件を実現するための実際のシステムに落とした場合の青写真を描くための工程です。

「クラウドは何を使うのか？（AWS/GCP/Azure…)」「技術選定はどうするのか？」「メール送信はどのサービスを利用するのか？」など、要件定義されたシナリオ・ユースケースに合致する技術を集めて、後続の詳細設計に落とせるように、技術的な全体像を描くフェーズです。

想定される成果物：
・アーキテクチャ設計/システム構成図
・機能一覧
・画面遷移図
・APIドキュメント

個々の画面やユースケースをそれぞれ具体的に実装可能な粒度に落とし込む工程です。

このフェーズでは、システムをどのように実装するのかを詳細に定義します。「画面のレイアウトがどうなるのか？」「クラス設計はどうするのか？」「処理の流れはどのようになるのか？」このような極めて実装のHOWに近い情報を定義していきます。

想定される成果物：
・画面遷移図
・クラス図
・ワイヤーフレーム
・状態遷移図
・データベース物理設計
・バッチ処理詳細定義
・画面設計書

設計に沿って実際にプログラム・コードを作成する工程です。

このフェーズでは、実際にシステムを開発していきます。基本的には設計書や開発バックログチケットなどにそって開発を実施しますが、得てして設計書では考慮しきれていなかった部分が出てきがちですので、ここがウォーターフォールを実施する上でのボトルネックとなることも多いでしょう。

想定される成果物：
ソースコード
実際にデプロイされたシステム

実装された成果物が、本当に設計および合意された仕様と合致しているのか、システムが予期しないバグによって動作不全を引き起こしていないかを確認するための工程です。

単体テスト・結合テスト・総合テストなど詳細に別れている場面が多いです。

想定される成果物：
テスト仕様書
バグ報告
バグ修正のされたソースコード

実際にシステムを稼働させ、業務を代替させていく段階です。

運用フェーズでは、ここまで開発してきたシステムを実践導入し、実際の業務に組み込んでいきます。場合によっては、初期運用段階で追加の機能開発が必要になることや、利用方法によっては思いもしない挙動が確認されることがあり、運用フェーズもプロジェクトの中でフォローされることが理想です。

想定される成果物：
システム概要/ドキュメント/操作方法
デプロイ済みの動作するシステム

それぞれのスプリントの開始時に、スプリントバックログを確認し、チームのベロシティ（進捗度合い）に応じたタスク配分を計画します。

開発者・スクラムマスター・プロダクトオーナーといったスクラムに関連している人は所定の会議に参加し、計画への参加が求められます。

レトロスペクティブとして、プロセスを見直していきます

主に、チームの生産性を向上するための方策を考えます。KEPTのような形でうまくいったこと・うまくいかなかったことの視点でパフォーマンスや作業工程全般の改善案を考えます。

ドキュメントを書いて共有するよりも、３０分のミーティングでコミュニケーションを取ればプロジェクトが円滑にまわるなら積極的にコミュニケーションを実施するというスタンスです。

エンジニアは時に過度な実装（オーバーエンジニアリング）してしまうことがありますが、大抵の場合後で必要になることは少ないです。あくまで、本当にニーズが出てきた時に実装すればいいということで、必要最低限のシンプルな実装がよいということです。

ソフトウェア開発において、開発された機能の殆どは使われないという調査もあるようです。私たちも、実際にXやYouTubeなどを使うときにもいつも同じ機能をつかっていたりすることはよくあるでしょう。

こういった、本当に市場から求められている機能を迅速に開発するためのフィードバックを頻繁に得るべきだという考え方をXPではとっています。

XPではこれらを実現するための勇気が求められるといえます。

プロジェクトをうまく成り立たせるものはお互いの尊敬です。一方的に力関係が働いてしまうと、社内受託のようになってしまい、また部門間でのコミュニケーションに壁ができてしまいます。尊敬こそがプロジェクトの潤滑油です。