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

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

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

 

れで3週連続の台風襲来となりました。伊丹空港は晴れで風もさほどではありません。

{D67BFF06-E109-456A-982F-2E90734B28AC}
久々の787

て、今回のテーマも長期化していますが、実はここからが今回のテーマの本題となります。

 

  これまで要件定義の結果として、対象となるシステムがどのような未来を作るのかを、如何にユーザーに理解してもらうかについて考えてきました。もちろんこれは、要件定義フェーズにおいて重要なファクターであり、議論する価値があるものです。

 

  ただ要件定義の本質は(当たり前ですが)「要件を定義するする」ことにあります。

 

  では「要件を定義する」とはなんであるのか、考えを進めて行くことにします。

 

 

 

件定義の活動を分解すると、その要素は幾つかの階層から構成されていることが解ります。

 

  ます一番上位階層になるのが、ユーザーやスポンサーが明確にもしくはなんとなく思っている”想い”というものがあります。実にあやふやな感じがしますが、そこには明確になっていないが感覚的な問題点の捉え方としての合理性があるのもです。

 

  このなんとなくという感覚から発生した意識を分析して、問題の本質を明らかにし、具体的な対策を考えることが要件定義の本質となります。

 

 

 

層の2段目は、なんとなくから始まった問題意識から、いったい何を解決したいのかという”要求”を導き出すことになります。

 

  ただしこの上位階層レベルでの要求は、その要求の出所によって様々な意味があります。

 

  「うちの会社、このままじゃまずいよね。なんとかしないと」という問題意識が表すものは、それを語る人の立場によって千差万別であるのは当たり前です。

 

 

 

ってこのレベルでの”要求”を明らかにするには、要求を発信する様々なレイヤー毎にある要求を構造化し、全体としての要求の本質を明らかにすることが必要になります。つまり、相当の時間と手間がかかる作業となります。

 

  この作業のことをBA(ビジネスアナリシス)が請け負うことになるわけですね。それなりの理論と手法が必要になります。

 

  問題は、多くの企業ではこのBA活動がちゃんと理解されておらず、この重要なプロセスをすっ飛ばして、いきなり現場業務効率化のためのシステム導入プロジェクトを実施しようとすることです。

 

 

 

件定義のレイヤーについて次回も考えて行くことにします。