すっかり冬の様相に切り替わった感のある今日この頃ですが、皆さんはいかがお過ごしでしょうか。結構冷え込みが厳しくなっているようですが、風邪などお召にならないようどうぞご自愛ください。
さて前回は、要件定義の２つの機能階層である「ビジネスを捉える」と「システムを
考える」のそれぞれの階層の考え方の違いと、それ故に起きる要件定義という作業の難しさについて考えました。
要件定義作業の２つの階層の断絶により、作業の一元性が損なわれることでユー
ザー、ひいてはスポンサーが不利益を被ることになります。ただ前回の考察で、その
原因を作ったのは他でもないスポンサーであると結論しました。なかなか悩ましいこ
とです。
この断絶を解消するための方法論の一つとして、BA（ビジネスアナリシス）を紹介しました。BAは、要件定義作業の2重階層の第1階層である「経営の視点」により、業務を構造化し整理することで論理的にビジネスを理解し、正しいビジネスの要求を引き出します。ここまでが第一弾。
その上で要求に優先順位を付け、それを実現するための具体的な道筋を考えます。その
とき、どのような方針でシステムを構築するかなど「システム化」の視点で実現手法を立案します。
このようにBAが持つ守備範囲は広いのですが、詳細なシステム要件定義の作業へ間違いなくその成果を受け渡すところまでを目的としています。
しかしこれだけでは、当初の状況に比べて引き継ぎの密度が上がっただけで、指摘した問題を解決するには不充分です。つまり2つの階層の断絶が完全に解消されるようには思えません。では、どうしたらいいのでしょうか。
BAはこの対策として、実施体制の側面から提案をしています。
先にも述べましたが、BAが責任を持つ守備範囲はとても広く、多岐にわたります。そのため必然的に、BA活動を一人の人間が個人の力だけで押し進めるのは、非常に難しいことだというのは容易に想像できます。
そのためBAは、組織の中でその活動に必要なスキルを持つ人材が協力して実施することを前提としています。
したがって、その活動に参加するメンバーはテンポラリーなチームの一員として、組織の内外から様々な人で構成されます。またそのチーム構成は作業の進捗によって柔軟に変更されて行くことになります。
一般的にBA活動のどこかのタイミングで、後工程であるシステム構築プロジェクトを担当するPMの参加が必須となります。少なくともシステム化の方針を決める後半部分、もしくは活動全体を通して関わることが必要です。
このように、BA活動の実施体制を目的に合わせて設計することで、要件定義作業における2つの階層間の断絶を解消することを可能とします。
さて要件定義フェーズの階層構造とその課題、および課題解決のためのアイデアについて考えて来ました。
次回から本題である要件定義とアジャイル手法の関係について考えたいと思います。