今回は，要求開発やシステム開発で使用される「モデリング」が，なぜ必要なのかについて整理したいと思います。最初に「要求開発」についておさらいした後に，「なぜモデリングをするのか？」という点について論じます。
要求開発とは
要求開発とは，「要求は在るものではなく，開発するものである」をコンセプトに「ビジネスとして本当に求められている（必要とされている）システムはどのようなものか，本当にシステム構築する必要があるのか」を考えていくためのシステム化企画の手法です。
現在のITは，多種多様な業務を助ける便利なツールとして欠かせない存在であり，利用者やシステム・オーナーのITに対する要求も膨大になっています。その結果，企業や業務にとって本当に必要なシステムに対する要求（価値のある要求）は何なのかが見えにくくなっています。
これら顕在化されている要求だけでなく，潜在的な要求も含めた要求開発のステップを踏み，システムをイメージ（各分析やモデリングやその他の資料により“見える化”）することで，企業・業務に本当に必要なシステムとは“どのような要件を満たしたシステムなのか”を関係者間で確認，合意していきます（図1）。
|
|
| 図1●要求開発は，利用者やシステム・オーナーの“価値のある要求”を明らかにし，システムをイメージする |
| Wants | 利用者やシステム・オーナーなどの潜在的な要求（欲求） |
| Needs | 利用者やシステム・オーナーなどの顕在化された要求（必要性） |
| Seeds | 提供されている技術，アイデア，ソリューションなど |
なぜモデリングをするのか？
私はモデリングをしているとき，見栄えよく全体を網羅することにこだわり，本来の目的を見失いがちになります。そこで，“なぜモデリングをするのか”について再確認して，ここでまとめておきたいと思います。
モデリングは業務とシステムをイメージするために作成しますが，モデリングだけではシステム化の要件をまとめることはできません。では，なぜモデリングをするのでしょうか。また，どれだけ書く必要があるのでしょうか。モデリングの必要性について確認します。
(1)モデリングの必要性モデリングでは，対象となる業務の問題領域で，必要かつ重要な現実世界のオブジェクトを中心に，その構造と関係をまとめます。この視覚での表現であるモデルを基に，関係者間で全体概要を理解し，問題領域について共通の認識になっていることを確認します。
要は，システム化する業務をすべて見ていくのではなく，要点や範囲を絞って必要な部分をモデリングして確認することで，関係者で共通の認識を持ちましょうということです。
モデルには次の特徴があります。
- 記憶に残りやすい
- 概要が素早く理解できる
- 全体の構造，関係がわかりやすい
- 一目で要素同士の関連がわかる
- 関係者間で共通の認識が得られる（認識のすれ違いを確認できる）
その作業概要として，まず，これから始めるモデリングは何を確認するためなのかを明確にし，そこに必要かつ重要な情報を中心に構造と関係をまとめていきます。
次に関係者の間で，モデリングを基に，「視覚での表現」とそれに関係する業務内容のヒアリングや業務マニュアル，作業手順書などの「文書での表現」の両方で内容を確認し，問題とその解決方法（要求）を認識します。
モデリングも万能ではありません。モデリングによって全体像と個々の要素の関係を示したりすることはできますが，詳細な内容まで含めて表現すると，モデル全体が見えにくくなりその良い特徴が失われてしまいます。その場合，詳細な内容は言葉で補足して説明すべきでしょう。
モデリングの限界を認識して，「視覚（モデリング）での表現」「文書での表現」の両方の特徴を活かし上手く利用する必要があります。
(2)なぜAs-Is分析とTo-Be分析でモデリングを行うのか？ここでは，As-Is分析とTo-Be分析のモデリングについて確認しておきたいと思います。
そもそも分析とは，複雑な事柄の構成などを明らかにすることです。As-Is分析では，現状の問題点と改善策を確認します。To-Be分析では，今後の業務やシステムでの“ありたい姿”を明確にすることにより，そこに近づくための課題と対策を検討していきます。
また，そこからAs-Is分析とTo-Be分析のギャップを確認した後に，その対応の必要性を考慮することで業務要求やシステム要求を抽出していきます（図2）。
|
|
| 図2●As-Is分析で確認した問題点と，To-Be分析で見いだした将来モデルのギャップを確認して，業務要求やシステム要求を抽出する |
As-Is分析，To-Be分析でもモデリングによる「視覚的な表現」をすることで，それぞれの状況とギャップを把握し，議論を進めやすくします。
具体的には，As-Is分析（現状業務・システムの把握）では次の点を意識して作業を進めます。
- 業務およびシステムを理解（現在何ができるのかを確認）することにより，関係者間で現状の問題，課題の発生原因を認識し合意する（現在地の確認，現状認識）
- To-Be分析で新しい視点での方向性が見出せないとき，本来の問題を確認する（原点回帰）
- 担当者間での用語と情報（機能やデータなど）の関係や構造の意識を合わせる
- なぜ，現在の業務およびシステムが成り立ったのかなどの過去の背景を確認する（業務ルールの確認）
一方，To-Be分析（新業務・システムの把握）では次の点を意識して作業を進めます。
- “あるべき姿”の業務およびシステムの内容を理解，定義するため
- “あるべき姿”の業務およびシステムへの期待を実現性も含めて描く
- 目的と目標，到達地点，成功イメージを関係者間で認識，合意する
- 担当者間での用語と情報（機能やデータなど）の関係や構造の意識を合わせる
この場合，
目的：動機/なぜ進むのか
目標：目印/何を目指すのか
到達地点：ゴール/どこにいくのか
成功イメージ：何を持って成功とするのか
を示します。
これらの中でも，As-Is分析，To-Be分析のモデリングは，「担当者間での用語と情報（機能やデータなど）の関係や構造の意識を合わせる」ことが特に重要と感じています。
簡単に「なぜモデリングをするのか？」ということについて整理してみました。「モデリング」の意味合いをあらためて考えることで，皆さんが「モデリング」をより有効活用できる一助になれば幸いです。
| （又吉 真知＝要求開発アライアンス） |
