【616】要件定義の構造 -8- | キットPM奮闘記 改め キットビジネスアナリスト奮闘記

キットPM奮闘記 改め キットビジネスアナリスト奮闘記

PMの世界からビジネスアナリストへ、キットPM2.0を目指して奮闘中です。BAを超上流とか言いますが、当たり前のようで難しいビジネス要件をどうやればちゃんとまとめられるのか、皆さんとご一緒に考えていきます。

風も通り過ぎ真夏が戻ってきたここ神奈川ですが、2週続けての台風襲来で東北、北海道では大きな災害となったようです。被災された皆さん、こころよりお見舞い申し上げます。

 

{585378E2-E2FE-4BDB-811A-D15A8503323D}
台風一過

 

 

 

回アジャイル開発という開発手法を、要件定義の視点から見てみました。

 

  アジャイル開発はその名が示す通り、開発のための手法ですが、そのプロセスの中に要件定義の一部を取り込んでいます。

 

  あるレベルで動作するする実物を評価しながら、必要とする機能を考え(要件を定義し)実装するということを繰り返すことで、最終的にユーザーが最も必要とするシステムを構築するという考えです。

 

 

 

のように、要件定義の難しさの一つである、ユーザーと完成した未来のシステムに対するイメージを、正しく共有するという意味では、アジャイル型の開発手法は有効です。

 

  もちろん、アジャイル型開発を成功させるには、多くのメリットと乗り越えないといけない壁があります。

 

  ただ、上記のメリットを考えたとき、エンジニアとユーザー双方に有効な手法だとキットPMは考えます。

 

 

 

たような考えに”パイロットシステム開発”や”プロトタイピング開発”という方法があります。

 

  両方とも実際に動くものを評価することで、最終的なシステムの姿を決定しようというものですが、アジャイルと異なるのは要件定義または基本設計の段階でこの作業を終了し、後は従来の手法でプロジェクトを進めることです。

 

  パイロットシステムは、最終形態に近いシステムを限定されたユーザー環境の中で使用し、その機能を検証し修正するという考え方です。堅実ですが、手間とコストが大きくなります。

 

  プロトタイピングは、原型となる機能が制限されたシステムを導入し、それを評価することで最終的な機能を決定しようというものです。そのため、作成したプロトタイプシステムは破棄して、最終決定した仕様に従い新たに開発をします。これもコストがかかってしまいます。

 

 

 

れに対して、なんらかのシステムを開発してそれを評価することで要件を決定するのではなく、要件を感覚的に分かり易く記述することで、ユーザーを未来のシステムの姿を共有しようという方法があります。

 

  次回からこの手法について少し考えて行くことにします。