要求定義

• 要求定義と要件定義の違いを考える
• 要求開発超入門

• 要求開発アライアンス
  • 匠メソッド超入門（要求開発アライアンス定例会）

• 見ざる 聞かざる 書かざる 「これだけ」要求定義 ... ToBe?重視型のシステム開発での要求定義

• 要求仕様書とは？書き方と例・要件定義書との違い

• エンドユーザーの要求を正しく掴まないと、要求を出発点とするシステム開発を成功させることができない
• システム開発には、ユーザーの要求を正しくつかみ、技術者が開発のために必要な要件定義を作成することが大切

• ビジネスで、いつ、誰が、何を、誰に、どのようにしてサービスを提供することで、何らかの付加価値をもたらそうとしているのかを "見える化"（デザイン）する必要があり、その一部をコンピューターシステムとして要件定義し設計する

• システム化した後の結果イメージがもっと早い段階で予測できれば、それに対する変更やチューニングが容易になる

• 最近のビジネスでは、ITによりビジネス価値が拡大することが多くあります。そのほとんどの現象として、目的自体（要求）が価値を持つのではなく、目的（要求）の手段（IT化方式）によって価値が決まることが多い
• 手段のチューニングこそが価値をもたらしている
• 目的と手段を切り離しながらも、セットで考えることを、開発着手前の要求開発段階で、できるだけ早く行うことが大事

要求定義と要件定義 †

• 要求定義
  • 「～がしたい」　利用者の希望
  • ビジネスで何が必要かを記述したもの
  • 事業運用をオペレーションレベル考えそれを実現する
  • コンピュータシステムへの要求

• 要件定義
  • 「～が必要」システムの仕様書
  • システムが何をしなければならないかを記述したもの
  • システムの機能やＤＢ・通信などの利用方法

要求開発 †

• 情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて「開発」されるべきものである。
• 情報システムは、それ単体ではなく、人間の業務活動と相互作用する一体化した業務プロセスとしてデザインされ、全体でビジネス価値の向上を目的とするべきである。
• 情報システムの存在意義は、ビジネス価値の定義から要求開発を経てシステム開発にいたる目的・手段連鎖の追跡可能性によって説明可能である。
• ビジネス価値を満たす要求は、直接・間接にその価値に関わるステークホルダー間の合意形成を通じてのみ創り出される。
• 要求の開発は、命令統制によらず参加協調による継続的改善プロセスを指向すべきである。
• 「ビジネスをモデルとして可視化する」ということが、合意形成、追跡可能性、説明可能性、および継続的改善にとって、決定的に重要である。

• コタツモデル
  • トップ（の役割を持つ人）、業務、ITそれぞれのミッションと、知恵を持った人を集める
  • 要求には、ビジネス要求、システム要求などがありますが、経営的判断からトップダウン的に生まれる要求もあれば、業務現場の問題課題から生まれる要求もあり、IT活用という観点から生まれる要求もあるのです。それらの全体像を捉えるために、それぞれの専門知識を結集し、その中で戦略・業務オペレーション・IT活用を"見える化"することが重要となるため、それぞれの担当を呼んでまずはコタツに入れる

要求開発チームの活動 †

• コアチームは、週二回の活動が必要となります。たとえば、要求開発会議が開催される一日前に、要求開発会議の中で、何を議論の対象として、どのような成果を出すかという一日の活動のPlanとDoの結果を予測します。また、その他、各フェーズ毎のスケジュールを立てたり、調整したりします。
• さらに事前資料を作成することも必要
• 重要なことは、要求開発会議に重要な方々を呼ぶのですから、無駄なく効率的に作業が進められるよう、事前準備を行います。
• 要求開発活動は、週一回行います。
• ここで重要なのは、「結果イメージの予測」
  • 一日の作業結果を予測して、それが次の活動にどう活用するのか、または、作業結果によって何が分かり、次へのステップが取られるのかを予測し、その作業がどの程度時間がかかるものなのか、その作業によって得られる成果が何であるのか十分に考えることが重要
  • そうすることで、要求開発会議が、円滑に進められるようになる
  • 要求開発チームが集まって、「さあ何をやろう？」といった事が起こったり、いつも集まってもだらだら意見交換する会議では、全体に成果は出せませんし、長続きしません。

要求開発チームに必要とされるスキル †

• 要求開発に必要なスキル

• プロセス推進力
• 折衝力
• ファシリテーション ... 会議等の進行において、参加者の意識を高め、自ら積極的に活動していくために場を盛り上げることができる
• メンターリング ... 技術やノウハウを人に教えることができる

AsIs?とToBe? †

• 要求開発において
  • AsIs? ... 現状の業務やシステムのこと
  • ToBe? ... 次期の業務やシステムのこと

要求開発の心得 †

• 要求開発の心得

要求定義のポイント †

大前提をつかむ †

• キーパーソンを見つける
  • プロジェクトオーナー ... 要求を少しでもぶれにくくするために重要
  • 新ビジネス、新システムに対して熱意がある人 ... 検討の方向性が決まりやすくなる
  • 既存システム、業務に詳しい人
• 過去のエピソードで価値観をつかむ
  • 価値観や強みの項目を記入することにより、相手にとっての「理想像」を推測しやすくなる。さらにその理想像から、「理想と現実とのギャップ・課題」や「現状に対する認識」、今後何をすればよいかという「アクションプラン」なども見えてくる。これらは後に続く理想を投げかけるフェーズに活用できる。

• スコープを緩く把握する
  • ザクッとどの辺りのビジネス領域が対象になるのかを把握する
  • 緩いレベルのスコープであれば、個々の要求の変化に伴う影響を受けにくい

• 業務モデルのテンプレートをたたき台として提示しながら、プロジェクトオーナーにヒヤリング
  • 抽象度が高い業務機能を網羅的に掲載
  • 重要なポイントは「具体的なイメージを早くつかんでもらうこと」
  • 業務機能を説明する際、利用部門の現場担当者のユースケースレベルまで落とし込んで具体的な話をする
  • プロジェクトオーナーは具体例を聞くことで、どの業務機能でどんなことが技術的に可能なのかを理解できる。このような活動を通じ、プロジェクトオーナーの反応を見てスコープを緩く把握する

理想を投げかける †

• つかんだ大前提を手がかりに、「こんな要求はいかがでしょうか」などと提案を相手にぶつける
• その提案に対して相手が見せた反応から、「何ができると嬉しいのか」を考える

軽く「かたどる」 †

プロトタイピング †

• 重要なプロセスは実際に画面を作成したり、動くプロトタイプを用意したりする一方で、それ以外の部分は手描きのスケッチで代替するといった具合にメリハリを付けることを考える
• 細かい機能は気にせず、人の動きや業務の流れを意識する中で気付いた点を指摘する

ドキュメント †

• 要求を掘り起こす過程で作成する各種のドキュメントも、記述を絞り込み、要求が変わった場合などにあっさりと捨てられるレベル感に抑えられると理想的
• メリハリをつける
  • クリティカルな部分については、一つずつ要求を固め、きっちりとした仕様書を作成
  • 要求の変更に応じやすい部分と応じにくい部分の切り分けに注意 ... データ量やデータの種類、業務プロセスなど、後で変更しにくい部分はしっかりと定義
• 要件定義Wikiなどを設けるのも一手

絞り込んだモデリング †

利用シーン †

• 全体構造を捉える
  • 要求を掘り起こすプロセスでは、情報システムだけでなく「業務そのもの」もシステムの一種と捉えてモデリングを行う
  • モデリングによって個々の視点をつなぎ合わせて全体の地図を作り上げる。その地図を頼りに検討を進める。
• 複雑な部分を理解しやすくする
  • 業務の一部は、複雑な構造やメカニズムを含んでいることがある。そうした部分についてモデリングすると、ズームアップされて理解の助けとなる。
• 構造や動作を設計・検証する
  • 主にシステム開発のアーキテクチャー設計やそれ以降の設計工程において、最適化の実現性を確保し、それを保証するためにモデリングを行う。
  • 業務の最適化を図る際や、その後の「To-Be」の検証として「As-Is」の課題を解決できること（効率よく業務が流れること）を机上でシミュレーションするときに有用
• 本質的な概念・構造・メカニズムを捉える
  • システム全体レベルでのフレームワークや共通コンポーネントを設計する際に多用される。業務レベルでも、共通化や標準化を図るときに有用である。

ダイヤグラム †

• ビジネスユースケース図 ... 特定業務領域において対象業務を棚卸しし、業務スコープを明らかにする
• 概念クラス図 ... 特定業務領域を構成する概念（エンティティー）を抽出し、それらの関係を明らかにする
• 業務フロー図 ... 業務の処理手順を可視化し、システムとのやり取りを明らかにする

記法 †

• モデリングは、その時の目的に照らして、達成に必要なレベル（範囲、粒度、詳細度、抽象度）に抑えることが肝心
• 必要以上のレベルにすると（例えば、全体を捉えたいのに、詳細なところにまで精度を求める）、その分だけ多くの作業コスト（時間と労力）がかかってしまう

開発に先立つ「前さばき」で要求の全体像をつかむ †

プロジェクトの前提を整理する †

• 「プロジェクト定義書」と呼ぶツールを利用
  • 名称
  • 目的
  • 背景
  • 期間
  • 前提条件
  • 制約事項
  • スコープ
  • 組織
  • その他

• 分からないことを把握できればOK ... 分からない項目は、利用部門に確認すればよい

ステークホルダーを確認する †

• 重要なステークホルダーが漏れていると、重要な要求の漏れにつながる。これが後工程で発覚すると、いわゆる「ちゃぶ台返し」の原因となる。
• 「ステークホルダーリスト」と呼ぶツールを利用
  • ステークホルダー名 ... 開発対象のシステムとのかかわりを、主に役割で示したもの
  • 説明
  • 重要度
  • 人数
  • 具体例
  • 想定される影響 ... 要求を実現したシステムによって、ステークホルダーにどんな効果や副作用が発生するのかを記入
  • レビューポイント

要求の全体像を捉える †

• 「要求分析ツリー」というツールを利用
  • 要求分析ツリーは、左側に「課題」、中央に「要求」、右側に「解決策」の領域を設けた図
  • 要求エリアは、さらに10段階程度のレベルで領域を分ける
    • レベル1～4の領域には、経営視点の要求を置く
    • レベル3～8には、業務管理の視点の要求を置く
    • レベル7以降は、利用部門の現場の視点として具体的な機能要求などを置く

• このように要求を分けて配置すると、どんな要求が出ているのか、何が出ていないかが見えるようになる。このツリーを提示しながら、利用部門の担当者らにヒアリングをしてみよう。要求を系統立てて整理でき、システム開発の対象となる要求を明確にできる。利用部門とITエンジニアの認識もそろう。要求に対応付ける形で課題エリア、解決策エリアのそれぞれに、課題と解決策も書き入れよう。

ゴールを設定する †

• 「ゴール記述書」というツールを利用 ... 得たい成果や達成時期、達成の判断基準を整理する表で、以下を記述
  • 何をすることで
  • 何が
  • いつまでに
  • どうなるのか
  • 評価尺度
  • 目標値