DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

＜　前回　｜　目次　｜　次回　＞

７月１１日に行なわれた第２２回参議院選挙では、民主党は改選前議席である５４から、１０議席下回る４４議席という結果となりました。結果の是非についてはコメントいたしませんが、
・ 選挙の争点は何であったのか？
・ その争点が実現できたとすると、何が嬉しいのか？
・ そもそも各政党が考える将来の日本国像は何なのか？
　などの疑問が残りました。個々の政策は「点」で見ると良さそうな気がします。しかし「点」をつないだ「線」、そして「線」の集合体である「面（＝国家/もしくは地域）」になると、ぼやけて見えるような気が致します。

　政治の世界でも、ＢＡが行なう重要な取組みである、現状（As Is）と将来（To Be）を明確にし、そのギャップを埋めるための「要求」、そしてその「要求」を実現するためのソリューションをマニフェストに書き国民に訴えることが出来れば、政治家が何を目指し、何をしようとしているのかについて、国民ももう少し理解ができるようになるのではないかと感じた今回の参議院選挙でした。

　さて前回のメルマガでは、下記「現状（As Is）」と「将来（To Be）」、およびそのギャップを埋めるための「ビジネス要求」と「ステークホルダー要求」について簡単に解説いたしました。

　この２つの要求だけでは抽象度が高いため、もう少しブレイクダウンする必要があります。そのために、「ビジネス要求」と「ステークホルダー要求」を満たすソリューションの特徴を示す「ソリューション要求」を明確にします。
　BABOKⓇにおいて「ソリューション要求」は、『要求アナリシス』を通して作成し、定義するとあります。この『要求アナリシス』はBABOKⓇで定義された６つの知識エリアの１つで、ＢＡがステークホルダー要求とソリューション要求に優先順位を付け、徐々に推敲する方法してソリューションを定義します。この６つの知識エリアについては、次回のメルマガでお伝えいたします。

　話しを元に戻し、今回の事例における「ソリューション要求」の例を以下にご覧いただきます。

ここで注意しなければならないことは、「○△パッケージを導入する」や「ＳＯＡを導入する」など、「ソリューション要求」の解決策である「ソリューション」を記載しないことです。私もそうですが、システムに携わっている方は、（無意識に）「ソリューション」を思い付いていることが多いからです。「ソリューション」を「要求」だと思い込んでいると、手段が目的化するパターンに陥ってしまいます。そのようなパターンで立ち上げられたプロジェクトは、多くの場合、ユーザにとって満足行く成果を挙げられない結果に陥り易くなります。

　なお「ソリューション要求」に関しBABOKⓇでは、ソフトウエアソリューションの要求を記述するときには「機能要求」と「非機能要求」に分けられると記載がありますが、ここでは解説は割愛いたします。

　「ソリューション要求」の洗い出しが出来たら、最後の要求である「移行要求」を明確にします。
この要求では、現状からあるべき姿に移行するために必要なことを定義します。
　今回の場合であれば、「現行システムから新システムへデータ移行を行なう。」や、「新システムに慣れるためのユーザ訓練を行なう。」などが要求として定義されます。

　以上ごく簡単にBABOKⓇで定義された次の要求を、どのように使い分類してゆくのかについてお伝えいたしました。

1. ビジネス要求
2. ステークホルダー要求
3. ソリューション要求
4. 移行要求

※各要求の定義は、2010年5月25日に配信した本メルマガに記載しておりますので、詳しくは下記をご覧ください。

https://www.it-innovation.co.jp/2010/05/25-131635/

　BABOKⓇが優れている点は、これまであまり意識して整理せずに使ってきた「要求」を、４つに分類するとしたことです。分類することによって、例えばシステムの構想・企画で挙げられる「ソリューション要求」を、経営レベルの要求である「ビジネス要求」とひもづけることが出来ます。そのことで経営層にも、システム部門が行なおうとしていることの意図が端的に伝わるようになります。

次回は、本メルマガでは説明を省略した、BABOKⓇの６つの知識エリアについてお伝えいたします。

＜　前回　｜　目次　｜　次回　＞