ソフトウェア開発は、システムの分析や設計、実装、そしてテストに重きが置かれるきらいがあります。

しかし、手戻りがなく良質なソフトウェアを開発するうえで、質の良い要件が整っていることが前提になります。総論ではこの活動に異議を唱える方は少ないと思いますが、現状のソフトウェア開発の現場ではまだまだ十分に認識されていないようです。しかも、この活動に時間と労力が割けられていないことが現状です。

この要件開発に限らず、「正しいことが正しいとわかっただけ」ではなかなか行動を起こすことができません。実際に行動が起こせるためには、その活動の「価値」と、「わたしでもできるんだ」といった「見通し」が必要です。 ITコンサルタントのための要件開発入門

本連載では、この「要件開発」活動の「価値」とその活動を効率かつ、効果的に遂行するための「基本的な考え方」や「具体的な進め方」、ちょっとした「コツ」や「ポイント」を紹介していきます。それは、コンサルティング現場で培ったノウハウをエンジニアリングとして整理し、体系化した知識であり、思考法です。また、技術的な側面もさることながら、ヒューマン・ファクターにも踏み込んだ内容です。

なお、本連載は、書籍「ITコンサルタントのための要件開発入門」で紹介させて頂いた内容の抜粋であり、本書でなかなか伝えきれなかった実践で役立つ「思考のネタ(フレームワークやワークシート)」をご紹介するものです。

「要件」とは

ソフトウェア開発プロジェクトには、そのプロジェクトが発生した「目的」と「達成目標(達成しなければならないテーマ)」、そして達成に向けた方法や手段があります。この「目的」と「達成目標」、「方法」の総称が「要件」になります。

また、「要件」の類似語として、「要望」や「要求」があります。「要望」とは、要求の担い手がもとめのぞむこと、期待していることです。つまり、要求の担い手が思い考えていることで、まだ要求の担い手の「期待」や「価値」が他者へは伝わっていない状態(顕在化されていない状態)になります。

そして、要求の担い手がそのことを実現または達成することが必要であると考え、それを伝えまたは記述することで顕在化されたものが「要求」になります。つまり、「要求」とは、利害関係者の「要望」、つまり「期待」や「価値」が顕在化した状態であり、他者に認識された状態です。しかし、そのままの状態ではまだ真の要求が欠落しているかもしれません。なぜならば要求とは要求の担い手が関心を示す部分が強調され、詳しく語られることが少ないからです。この「要求」の質を確保し、要求の担い手の「期待」や「価値」の真の姿が描き出され、利害関係者もその状態を認識できた状態で「要件」へと昇格していきます。

重要なことは、要求の担い手により語られたことが「要件」ではなく、この「要望」から「要求」、そして「要件」への流れと、要求の担い手が真に思い考えていることを引き出すこと、そしてその「要件」を利害関係者との間で適切に共有することです。そのための「思考法」、「アプローチ法」が「要件開発」です。

要件開発とは

案外、要件を定義することはモデリングを行うことだと思っている方が多いのではないでしょうか。

要件開発とは、きれいなモデルを作成することではありません。ましてや、情報システムの観点でモデルを形成するものでもありません。重要なことは、利害関係者が理解できるようなモデルを形成することです。そのためには、形成された要件が「見える化」「「見せる化」できていなければなりません。その「見える化」「見せる化」された要件に基づき、利害関係者とコンセンサスを形成していかなければならないのです。そのためにも、利害関係者が読解可能な「見せ方」をしていかなければなりません。

また、「要望」から「要求」、そして「要件」へと段階的に仕立て上げていくためのアプローチ法は、エンジニアリングとしてのアプローチである必要があります。つまり、体系立った仕組み(アーキテクチャ―)と体系立てられた手続きが必要です。

要件開発では、利害関係者との適切なる会話を通じて、ビジネスおよびシステムに関する「要求」を引出し、引出した「要求」を「要件」へと形成をはかり、利害関係者との間で合意を得る活動で構成されます。

図1

当然、成果物の質が粗悪(ヌケやモレ、ダブリ、抽象的な粒度(レベル))なものでは意味がありません。同時に良質な成果物を創り出すための「原理」や「原則」、「コツ」や「ポイント」が提供されています。

要件開発のモデル

要件開発では、「要求」を3つの類型(タイプ)に分け、それぞれの「要求」に応じたモデルを形成します。

図2

メタ・モデルとは、発足したプロジェクトのチャーターとなる情報を形成したモデルです。つまり、プロジェクトの「目的」や「ねらい」、「達成目標」、「方法・手段」を全体網羅的に形成し、プロジェクトに関与する方々がプロジェクト活動に関する統一した見方、意味付けができるように、「プロジェクトの要件」を形成したモデルです。

図3

またビジネス・モデルとは、プロジェクトの「目的」や「ねらい」を達成・実現するために、「何を」「どのように」実現・達成しなければならないかを形成したモデルです。つまり、メタ・モデルの「達成目標」と「方法」を具体的に掘り下げたモデルが「ビジネス・モデル」です。ビジネス・モデルは、ビジネスの3つの要因(「サービス」「プロセス」「リソース」)に応じて、さらに3つのモデル(「サービス・モデル」「プロセス・モデル」「リソース・モデル」で構成されます。

図4

さらに「システム・モデル」とは、ビジネス・モデルで形成された要件に基づき、システムとして実現・達成しなければならない要件を形成したモデルです。UMLのユースケース・モデルや概念モデル(概念クラス図)、ロバストネス・モデルなどがシステム・モデルの1つの要素です。

本連載では、プロジェクトの「目的」や「ねらい」を形成する「メタ・モデル」に焦点をあて、ご紹介していきます。

プロジェクトの「目的」や「ねらい」は、ソフトウェア開発の成否を決定する重要な情報です。この情報が利害関係者との間で共有できることで、ビジネス目標に沿ったIT達成目標を形成することができます。つまり、ソフトウェアの「品質を確保」するための重要な情報になります。また、ソフトウェア開発の「手戻り」をなくすためにとても重要な情報なのです。

本連載の構成

次回より全7回にわたり、プロジェクトの「目的」や「ねらい」を形成するための「メタ・モデル」に関し、基本的な考え方をわかりやすく、具体的に紹介していきます。

  1. メタ・モデルの位置づけ
  2. メタ・モデリングの基礎知識
  3. メタ・モデリングの進め方
    1. (ア)「とらえる」段階:「要求」の引出し
    2. (イ)「ふかめる」段階:「要求」の分析
    3. (ウ)「まとめる」段階:「要件」の形成(仕様化)と合意形成
  4. 効率かつ、効果的にメタ・モデリングを進めるための「思考のネタ」