昨日は随分と冷え込んだここ南関東地方ですが、今日は幾分寒さも緩むようで、いい天気となりました。
今年の秋は、寒かったかと思うと暖かくなったりでなんとなく落ち着かない気候が続きましたが、着実に冬も深まっているようです。今年もあとわずかですが、気を引き締めて頑張りましょう。
朝日＠通勤路
結局プロトタイピングの手法を応用することで、要件定義にアジャイル的なスタイルを持ち込もうというところに落ち着いた今回のテーマです。ちょっと安易すぎるきらいもなきにしにもあらずですが、やはりスタート時点での予算確定を前提とした、システム開発のレガシー的なプロセスを見直すことができず、かつ、要件定義の品質を上げることでシステム構築の失敗を回避したいのであれば、もっとも有効で魅力的な方法ではないかと考えます。
前回、プロトタイピングの課題はプロトタイプシステムの品質とコストがトレードオフになるということであると考えました。
この課題を乗り越えるために、ユーザーが新しいシステムでの業務をイメージできるレベルの品質で、要件定義のコストとして許容できる範囲であることが一つの条件となると考えます。
したがって、プロトタイプのレベルをどうデザインするのかが重要なファクターになります。これがこのシリーズの 10回目 で言ったレベルで考えるということに繫がります。
プロトタイプですから、もちろん実際に使用するシステムとは見た感じも機能も異なってきます。これでユーザーが自らが利用するシーンをリアルに想像できるのか？という問題が発生します。
そういう意味では、同じプロトタイプでも単なる画面の紙芝居から実際にDBに接続して、データの出し入れまで可能にするものまで、そのレベルは様々考えられます。この範囲の中で、目的達成が可能で安価に作ることが可能なものが、選択肢となります。これが、システム側のレベルです。
もう一つ検討が必要なレベルがあります。
ある限定された機能を見ることで、自己の新しい業務の姿を想像することはとても難しいものですが、これを可能とする業務知識、想像力、発想の柔軟性、全体最適の理解など幅広い視点で仕事を捉える力が必要になります。
これがユーザーの（システム開発業務とプロジェクト経験の）レベルです。
この２つのレベルは、プロジェクトの実施環境等のさまざまな制約条件により規定される割合が大きいのですが、制約に取らわれ過ぎるとせっかくの作業が目的を達成できなくなる可能性もあり、やはりバランスを考えることが重要になります。
当たり前ですが、プロトタイピングという開発手法を選択するとき、その特性にあった計画を立てることが重要となります。また、プロトタイピングは反復作業を伴うことがほとんどなので、そこにはアジャイルのマネジメント手法が利用できます。
どのようなツールを使って、どのレベルのプロトタイプを何回の反復（イテレーション）で最終の要件確定まで持っていくのかを考え計画することになります。
次回は、もう一つの開発手法である「パッケージ導入」における要件定義とアジャイルスタイルの関係を見て行くことにします。