PR

 Openthologyは,要求開発において標準となり得る方法論を提供することを目標に作成され,要求開発のプロセスとモデリング手法の2つを定めている。今回は,これら2つの概要を紹介しよう。これらはいずれも,過去4回にわたって本ブログで取り上げてきた問題を解決するための手法として策定されている。この記事を読む前に,ぜひ目を通していただきたい。

 また,ここで取り上げるOpenthologyは,バージョン1.0のものとなる。このバージョンは,書籍「要求開発」(日経BP社発行)としてまとめられている。こちらもぜひ参考にしてほしい。

正しい要求を得るために必要な4つのフェーズ

 Openthologyでは,要求開発のプロセスとして「準備」「立案」「デザイン」「移行」という4つのフェーズを定めている。前々回にも説明した通り,正しい要求を迅速に獲得するためには,制御可能で制御価値のある個所に狙いを定めてモデリングすることが大切だ。これら4つのフェーズは,そのために必要となる手続きをフェーズ(工程)として定義付けたものである。

 最初の「準備フェーズ」は,その名の通り,要求開発活動の準備を行うための作業である。要求開発の範囲(スコープ)とリソース(誰が行うのか)を決めて,プロジェクトとしてのゴールを定めていくための作業となる。つまり,要求開発計画(Plan)を決めるための活動(Do)を集めたフェーズと言える。

 要求開発のような永遠の企業業務改善(改革)活動では,計画の現実性・実現可能性が非常に重要になる。現実的で実現可能な計画を定めるためには,ビジネス戦略の地図を描き,その中で要求開発プロジェクトとして短期・中期に狙う個所を定めて,ゴールを定める。そして,その中の短期的なゴールを要求開発プロジェクトのゴールとして定義するのである。

 次の「立案フェーズ」では,準備フェーズで定めたゴールを達成するために,関係する業務をどのように変えるのか(改善・改革)を決定する。このフェーズでは,「概観ビジネス・モデリング」と呼ぶモデリングを行う。概観ビジネス・モデリングとは名前の通り,対象となるビジネスの問題領域を大ざっぱに描くことで,どこに制御価値があり,どこが制御可能であるかを見ていく作業である(「制御価値」「制御可能」については前回の記事を参照)。つまり,モデリングを深めて意味のある個所の“アタリ”をつけていくのである。また,将来の業務モデルを描くために,現状の業務がどうなっているかを表現する現状(As Is)モデルを描くのもこのフェーズである。

 その次は「デザイン・フェーズ」である。デザイン・フェーズは,立案フェーズによってアタリをつけた個所の業務についてしっかりとした将来(To Be)業務の設計を行う。ここで言う将来業務は,明確にプロジェクト・ゴールとして定めた次期業務のことであり,夢のような未来の業務ではない。ここで作成したモデルの根拠は,準備フェーズで作成したプロジェクト・ゴールにある。つまり,プロジェクト・ゴールで定めた指標を達成できるか否かによってモデルを評価できるのである。

 最後は「シフト・フェーズ」である。これは,将来(To Be)業務の設計の中から,次期システムに必要とされる基本的な要求とシステム基本構造を策定するフェーズである。

 要求開発方法論には,これら4つのフェーズに加え,実はもう一つフェーズとして組み入れようとして断念した“隠れフェーズ”がある。それは,「評価フェーズ」である。評価フェーズは,システム開発完了後に,要求開発チームが新ビジネスのテストという観点で,新システムを評価するフェーズであり,要求開発活動の中で実際に行われているフェーズである。Openthologyの今回のバージョンでは,方法論の複雑さを排除するためにあえて組み込むのを見送ったが,読者の皆さんはこの点を頭の片隅にとどめておいてほしい。

 Openthologyでは,これら4つのフェーズを「プロセス・キャビネット」という形式で提供している。プロセス・キャビネットは,Y軸にフェーズ,X軸にPDCA(Plan,Do,Check,Act)という,4×4のマスで区切られた,要求開発としての基本活動(アクティビティ)を整理するための引き出しである。

 プロセス・キャビネットのアイデアは,フェーズの中で必要となる基本活動を,PDCA(Plan,Do,Check,Act)に分類して管理することだ。利用者は,この引き出しから必要な活動をPDCAの組(PDCAサイクル)として取り出すことで要求開発のプランニングが可能となる。

 しかし,活動をPDCAサイクルとして取り出すことは,要求開発の経験が浅い人にとっては難しい作業である。そこで,要求開発アライアンスではOpenthologyに「プロセス・セル」という概念を導入した。「プロセス・セル」は,基本活動をあらかじめPDCAという単位にまとめ,それに目的と成果物,および入出力をカプセル化した概念である。これによって,プロセスを実施する個人,または,グループの責任範囲が明確になり,活動(アクティビティ)単位に作業を分割するよりも分かりやすい作業単位を定義できる。さらに,責任範囲で仕事をカプセル化できるため,並行して作業を実施しやすくなったのもメリットだ。プロセス・セルは,要求開発だけではなく,今後ソフトウエア開発プロセスにも応用できると考えている。

対象に応じてモデリングの手段を使い分ける

 Openthologyにおけるモデリングでは,モデリング対象によってUMLを使う場合と別の図式化の手法を使う場合がある。UMLは基本的に,現状業務と将来業務の姿を可視化する際に使用する。具体的には,「サービス」「プロセス」「情報」という3つの構造に着目して図式化する。

 では,要求開発チームの活動の中で,現状業務から将来業務を導き出していく際に,その過程を図式化するにはどうしたらよいだろうか。もし,この過程を描けなければ,将来業務をどのような選択肢からどのような手順で決めていったかという記録が残らないことになり,後で様々な問題を引き起こす可能性がある。

 要求開発では,この目的のためにトップダウン・ビジネス分析,ボトムアップ・ビジネス分析の中でモデルを作成する。トップダウン・ビジネス分析で利用するモデルとしては,BSC(バランス・スコア・カード)やプロジェクト・ゴール記述書がある。つまり,プロジェクトのゴールを決める際に,ビジネス戦略の地図を描くのである。

 このように要求開発で戦略的側面を可視化するのは,要求開発プロジェクトのゴールを決定する際に非常に重要である。詳しくは,書籍「戦略的要求開発のススメ」(翔泳社発行)を一読されたい。

 Openthologyの情報構造モデルには,UMLの概念モデル(クラス図)を使用している。ただし,概念モデルといっても,ビジネス・パーソンが無理なく理解可能な範囲でクラス図を記述できるレベルのものとしてチューニングしなければならない。そこで,ここでもOpenthologyでは新たな手法を提供している。

 それは,「TFP分割手法」である。TFP分割は,クラス図を,Thing図(モノ図),Function図(コト図),Place図(バ図)の3つに分けて分析する手法だ。Thing図では,ビジネスの普遍的な概念構造をとらえ,Function図では概念(もの)の使い方をモデル化し,Place図ではモノとコトの置き場所をモデル化する。これにより,変化に富んだビジネスの価値を比較的容易に表現できるようになる。TFP分割の詳細は,書籍「要求開発」を参照されたい。

 このように,Openthologyではビジネスを見える化し,改善を加えてITにつなげるために,プロセスとモデリングの手法について新たな提案を行っている。これらは,要求開発という範囲を超え,ビジネスとITにおける普遍的かつ一般的なプロセス,モデリングの手法として価値あるものを目指している。そのために,要求開発アライアンスのメンバーで日々ブラッシュアップ作業を続けているところである。

(萩本 順三=要求開発アライアンス理事)