要求開発方法論オーバービュー

要求開発方法論について

要求開発方法論(Openthology)は、Version 0.6とVersion 1.0があります。 詳しい説明は、要求開発アライアンスホームページにあります。

Version 0.6は、お客様のところで要求開発を実践してきたものを、とりあえず書き下ろしたものです。Version 0.6は、手順的に分かりやすく書かれています。そして、Version 1.0は、要求開発アライアンスの理事の方々とデスカッションしながら作りあげ、書籍「要求開発」(日経BP出版)としてリリースしたものでVersion 0.6をさらに洗練化させたものです。

要求開発方法論は、要求開発を実践する方々が見るガイドラインで、、やり方、考え方、手順が書かれています。
ガイドラインと異なるのは、方法論(Methodology)として、しっかりとした体系を持っていることです。

さて、ここから要求開発方法論の体系を説明していきます。
せっかくですので、最新バージョンとして作成中のVersion 2.0で説明を進めます。Version 2.0は、今、要求開発アライアンスのTAWG(ToBe Structureワーキンググループ)で策定中で2009年夏くらいにリリースを予定しています。このワーキンググループのリーダとして僕も活動を盛り上げています。
Version 2.0は、Version 1.0を用語等で、さらに分かりやすくしたものですので、説明には最適ですし、ここで取り上げる内容としては、基本的にはVersion 1.0とあまり変わりがありません。

 

要求開発方法論の構成要素

要求開発方法論は、次のような構成からできています。それぞれの構成要素の説明をしていきます。

1.モデル

モデルとは、「見える化」を行うための道具です。モデルは、業務フロー、ユースケース図、クラス図(概念モデル)などといった図(ダイアグラム)で表されます。要求開発で推薦しているモデル図の代表的なものとしては、「BSC戦略マップ」「ビジネスユースケース図」「業務フロー図(UML※アクティビティ図)」「概念モデル図(UML※クラス図)」「システムユースケース図」などがあります。

図1 要求開発で使われるモデル
図1 要求開発で使われるモデル

拡大画像

  • ※UMLについて
    UMLは、正式には、統一モデリング言語(Unified Modeling Language)のことを言い、ソフトウェア工学におけるオブジェクト指向開発のために標準化された仕様記述言語です。要求開発方法論では、このUMLをベースに使っています。詳しくはVol.10で説明します。

2.プロセス

プロセスとは、要求開発を行う上で、どのような手順でどのような事を目的にして行うのかという手順が示されています。手順は、フェーズ(工程)として纏められており、それぞれのフェーズでは、何を目的として、どのようなモデル(図)で、何を表し、次のフェーズに何を繋げていくのかということが説明されています。
要求開発方法論のフェーズとしては、「準備フェーズ」「立案フェーズ」「デザインフェーズ」「シフトフェーズ」があります。
下記の図中、フェーズの中で何を行うのか、書いてありますが、まだ意味が分からなくても心配しないでください。これらは、後で説明していきます。

図2 要求開発のフェーズ
図2 要求開発のフェーズ

ページトップへ

 

要求開発方法論のストラクチャ

要求開発方法論には2つのストラクチャ(Structure)つまりは構造と呼ばれているものがあります。この2つのストラクチャはとても大切なものですのでここで簡単に説明しておきますね。

モデル・ストラクチャ

モデル・ストラクチャとは、要求開発方法論を使ってモデルを書く("見える化"する)際にモデルをどのような視点で描くかという視点(ビュー)の分類構造を示しています。
要求開発のモデル・ストラクチャは、戦略ビュー、サービスビュー、プロセスビュー、情報ビューという4つのビューで構成されています。また、上半分はビジネスを表し、下半分はITシステムを表します。図中の黄色い矢印は、"見える化"活動の大まかな流れを示しています。

図3 モデル・ストラクチャー
図3 モデル・ストラクチャー

それぞれのビューを簡単に説明しましょう。

戦略ビュー ビジネス戦略やIT戦略の見える化を行いコタツモデルの中で合意を得ます。
そして、プロジェクトを企画してプロジェクト戦略を立てるためのビューです。
戦略ビューは、BSC戦略マップやゴール記述書というモデルで表されます。
サービスビュー プロジェクトで業務改革・改善やシステム開発を行うための対象を、サービスという観点で切り出します。
サービスとは、会社が社外に何らかの価値を提供しているのもサービスですし、企業の中で部門が他部門に何らかの価値を提供しているのもサービスとなります。
サービスビューは、プロジェクトで取り扱うドメイン(対象)の全体を把握するためのビューです。
サービスビューは、ビジネスユースケース図、システムユースケース図で表します。
プロセスビュー サービスビューとして切り出された、業務改革・改善やシステム開発を行うための業務対象が、どのような手順で進めていくか"見える化"するものです。
つまりは、業務の流れを明確にするものです。プロセスビューは、業務フロー図として表します。
情報ビュー サービスビューとして切り出された、業務改革・改善やシステム開発を行うための
業務対象の中に存在する重要な概念用語の関係を概念モデルとして描きます。
これによって、異なる業務部門間で、用語のぶれがなくなったり、用語の意味が統一化・共通化されたりすることができます。
情報ビューで扱う概念モデルによって、業務の流れとは異なった普遍的な業務構造が理解できるようになります。
情報ビューは、UMLのクラス図として表しますが、通常のクラス図のように属性や操作は書かずにクラス名(概念語彙名)だけを書いた関係図を表します。
概念モデルやクラス図の説明も後で行います。

ページトップへ

プロセス・ストラクチャ

プロセス・ストラクチャとは、名前の通りプロセスの全体構造を示した概念的な図の事を言います。
プロセスとは前で説明したように、要求開発を行っていく上での手順をフェーズとして説明しているものです。
プロセス・ストラクチャでは、横軸にフェーズを書き、縦軸にPDCAを表しています。PDCAとはPlan、Do、Check、Actionの略です。要求開発における実際の活動(アクティビティ)は、この図で示すように、それぞれのフェーズに用意されたPDCAの箱の中に標準で用意されているので、それらをチョイスして使ってくださいというわけです。
つまりは、それぞれのフェーズの中での活動は、ちゃんとPDCAで回すようにという教育的な工夫が取られています。
要求開発では、このプロセスの戸棚のことをプロセスキャビネットと呼んでいます。

図4 プロセス・ストラクチャ
図4 プロセス・ストラクチャ

さて、この概念図としてのプロセスキャビネットの中に実際には何が入るのでしょうか?
図5がプロセスキャビネットの中身です。
プロセスキャビネットはDoの中身を目的別に分類しています。
要求開発を行う際には、このキャビネットの中から必要と思えるPlanとDo、そしてCheckとActionをプランニングの参考にするとよいでしょう。

図5 プロセスキャビネットの中身
図5 プロセスキャビネットの中身

拡大画像

要求開発方法論のオーバービューとしては、大体このくらいのことを理解していればOKです。では、次から要求開発のチーム、見える化とは何か、プロセスとは、スキルとは、など、要求開発の中で知っておかなければならない重要な考え方を説明していきましょう。


  • ※掲載されている製品・サービスは、掲載当時のものです。
  • ※掲載されている社名および製品名は、各社の商標または登録商標です。

ページトップへ