re-introduction to openthology

The solution beyond the solution.MAMEZOU　

要求開発再入門

萩本　順三


要求は「開発」するもの

• 「要求分析」、「要求定義」などは、要求がすでに存在しているという前提に立っている

• ユーザからヒアリングした要求の実現が業務効率化に結びつくとは限らない。

– ユーザの理解の範囲内で生まれた属人的なもの

– 直感的、場当たり的であることが多い

• 要求は、業務を分析することによって開発される。ロジカルに導かれる必要がある。

動機編より抜粋２．要求開発方法論とは　　


なぜよいシステム開発ができないのか？

– 最悪のシナリオ

業務管理者の論理

システム開発者の論理業務担当者の論理

業務理念を統制し、業務効率化を図るための業務とは

○○あるべきだよ。

我々のやり方がベストなんだ。これにあわせてシステム

を作ってくれよ。

あの業務は、○○パッケージや○○フレームワークを使って開発

すれば簡単だよ。業務は、それにあわせればいい

。

壁



それは、正しいシステム要求がだせないから

• うまくいきそうで駄目なシナリオ（その１）– トップ・業務管理者の考えどおりのシステムを作ったが、業務担当から大クレー

ム。

– 結局使われないシステムになった。



業務理念を統制し、業務効率化を図るための業務とは

○○あるべきだよ。

あの部長、業務の事をなにも分かっていないんだよね。

わかりました。おっしゃるとおり、業務効率化案に基づいた要求を

考えていきましょう。壁

でも、あの人のいうこと本当にただしい

のかなあ？まあ、いっか。

２．要求開発方法論とは　　動機編より抜粋


それは、正しいシステム要求がだせないから



業務理念を統制し、業務効率化を図るための業務とは○○あるべきだけど、業務担当は、みんな既存システムのやり方に慣れてしまって本当に改善しようとおもっ

ていないんだ。

我々のやり方がベストなんだ。これにあわせてシステム

を作ってくれよ。

分かりました。業務担当の方々に合わせて、システムを開発しま

す。壁

• うまくいきそうで駄目なシナリオ（その２）– 業務担当者からそれぞれ要求を聞きだした。

» 業務の標準化ができない。» 効率化を考慮していない業務にあわせて

システムを作ってしまう。

だけど、それぞれの担当者から出てくる要望を開発するのは

大変だよな。ま、いっか。



要求開発とは

–正しい要求の獲得と合意のための活動



業務理念を統制し、業務効率化を図るための業務とは○○あるべきだ、しかし現実は△△だから、それをどう改善できるか現場と話し合ってみよう。

我々のやり方がベストだと思っていたけど、見方を変えれば欠点が多いね。問題分析ツリーでもう少し業務のあるべき姿を考えてみよう。

あの業務は、○○パッケージや○○フレームワークを使って開発すればよさそうだ、しかし、本当に求められている業務の姿を明確にして３者で合意しなければ、真の要求など獲得できるはずがないね。

問題の視覚化(モデル)と改善プロセスによる活動

開発された要求（システム要件）

コタツモデル


要求（正確に言うと要求仕様）はどうにでも定義できる！

ビジネス戦略

現場の問題解決ＩＴによる付加価値注入　　　　問題解決

最適解はどれだ！


要求の重要性

• 米国Standishグループの調査によれば、システムに作りこんだ機能のうち、結果として利用されているのは３６％だということです。これは言い換えると３分の２のシステムが「役に立たない」ということにもなります(Standish group study report in 2000 chaos report)。このような「大いなる無駄」を排するためには「正しい」要求にもとづくシステム開発が必要となります。要求開発は、システム企画の段階からRFP（Request For Proposal）の作成まで、一貫して「目的と手段の連鎖」を見える化していくプロセスです。これにより、ステークホルダー間の合意をとりながら、企業経営への貢献という最終的な目的を実現させるためのシステム開発を推進していきます。

The solution beyond the solution.MAMEZOU　9

開発プロセスオーバービュー

準備

方向付け　推敲　　　　　構築　　　　　　移行

第１　プロジェクト方向付け　推敲　　　　　構築　　　　　　移行

第２　プロジェクト方向付け　推敲　　　　　構築　　　　　　移行

第３　プロジェクト

狭義のシステム開発

広義のシステム開発

ビジネスユースケース

業務フロー（As-Is、To-Be)

業務レベルの概念モデル

経営分析ビジョン、ミッションの

確立

問題点分析

ビジネスゴール設定

システム化範囲の導出

ロードマップ作成

システムユースケースの抽出と個別プロジェクト

へのブレークダウン

広義のプロジェクト

狭義のプロジェクト

要求開発

財務的解決やマーケティング的解決で終わ

る課題もある

ビジネス戦略の見える化、プロジェクトスコープとリソースを確定しゴール

を明確化。

システム開発

業務要求の獲得とプロセスの見える化、ITの基本要

求の獲得。

広義の要求開発（要求定義）狭義の要求定義

ＢＤＡＢＤＡ

立案デザイン移行


要求開発方法論（要求開発方法論（OpenthologyOpenthology））構造とモデル

• 戦略とサービス構造中心でモデル化– ビジネス戦略からプロジェクト戦略へ– 業務のサービスの明確化

• 企業の意思決定層とビジネスオペレーション層の構造を確立（見える化）– 企業の意思決定層の戦略を、ビジネスオペレーション層のサービスまで具体的に

落とし込むメソッドを持つ。

データデータモデルモデル

オブジェクトオブジェクトモデルモデル

アプリケーション・プロセスアプリケーション・プロセス

ビジネス・プロセスビジネス・プロセス

　　　　　　　　　　　　　　　　　　　　　　　　

ビジネス要求ビジネス要求

システム要求システム要求

アプリケーションアプリケーション

フレームワークフレームワーク

実装アーキテクチャ実装アーキテクチャ

ビビジジネネスス

IITTシシスステテムム

プロセス構造プロセス構造サービス構造サービス構造

情報構造情報構造

ビジネス戦略ビジネス戦略

ビジョン：ゴール構造

ビジネスビジネスオペレーションオペレーション

The solution beyond the solution.MAMEZOU　11


ビジョン：ゴール構造

データデータモデルモデル

オブジェクトオブジェクトモデルモデル

OpenthologyOpenthology構造とモデル

アプリケーション・プロセスアプリケーション・プロセス

ビジネス・プロセスビジネス・プロセス

　　　　　　　　　　　　　　　　　　　　　　　　

ビジネス要求ビジネス要求

システム要求システム要求

ビジネスビジネス




ビビジジネネスス

IITTシシスステテムム

プロセス構造プロセス構造サービス構造サービス構造情報構造情報構造

ビジネスユースケースモデル

業務フロー（アクティビティ図）ユースケースモデル

ユースケース記述

　ビジネス概念モデル

　DB　　モデル

　分析・設計モデル　　　　クラス図

BSC戦略マップ


要求の基本（ビジネスからシステム開発につなげる表と裏）

ビジネス戦略ビジネス

オペレーション

戦略オペレーション

ビジネス表（価値）　裏（実現）

システム要求

システム

表（価値）　

裏（実現）

システム設計

表（価値）裏（実現）

What How

What

How

What How


戦略のトリアージ　

課題　オペレーション

ビジネス

製品開発

ビジネス戦略ビジネス戦術

製品要求　

トリアージされた戦略改善・改革が必

要な業務処理

トリアージされた要求

トリアージ（triage）：要求を戦略的に取捨選択する事。もともとは医学用語で、有限のリソース（医師や医薬品など）を最大限に活用し、各患者の病状や状況に合わせて、より多くの傷病者の治療をするために優先順位を決定することを指す。

付録：発刊予定書籍　「成功する要求仕様、失敗する要求仕様」日経ＢＰ　アランＭデービス著、安井・萩本監訳、高嶋訳


Structure Openthology ver2.0 モデル・ストラクチャ図


ビジネス・プロセス

　　　　　　　　　　　　　　　　　　　　　　　　

ビジネス要求

システム要求




プロセス　ビュー

サービス　ビュー

情報　ビュー

　　戦略ビュー

アプリケーション・プロセス

データモデル

オブジェクトモデル

ビジネス

ＩＴシステム

ビジネス戦略

プロジェクト戦略

ＩＴ戦略

プログラム戦略



ビジネス・プロセス

　　　　　　　　　　　　　　　　　　　　　　　　

ビジネス要求

システム要求




プロセス　ビューサービス　ビュー

情報　ビュー

　　戦略ビュー

アプリケーション・プロセス

データモデル

オブジェクトモデル

ビジネス

ＩＴシステム

ビジネス戦略

プロジェクト戦略

ＩＴ戦略

プログラム戦略

Openthology ver2.0 Structure & Reference

　　Business Strategy　　　　　Reference Model 　　IT Strategy Reference Model

　　Project Strategy Reference Model

　　Process Reference Model

　　Service Reference Model

　　Information Reference Model

　　ProgramStrategy Reference Model

戦略

サービス

プロセス情報

Openthology 本質　ビュー

Structure


モデルの役割(Ver1.0)ビジネス課題ビジネス・オペレーションシステム要求システム設計

戦略モデルサービスモデル

情報モデル

プロセスモデルサービスモデル

TFP分割手法　・Thing図　・Function図　・Place図

・業務フロー

・ビジネス　ユースケース

・システムユース　ケース

アーキテクチャモデル

　・ERD/DB設計

　・アーキテクチャモデル

　・SOAモデル

・BSC戦略　マップ・IT貢献度　マップ・プロジェクト　ゴール記述書

要求開発フェーズ

観点の流れ

準備立案デザインシフト

８．要求開発ビジネスモデリング応用編

システム開発フェーズ

ビジネス概念からITアーキテクチャへ

業務プロセスからIT要求へ


戦略ビューサービスビュープロセスビュー

Structure （要求開発）

BSRM

BSC戦略マップ

ITSRM

IT貢献度マップ技術マップ

財務

顧客

プロセス

教育

要求分析ツリービジョン分析ツリー問題分析ツリーターゲット分析

ビジネスユースケースステークホルダー分析

利益向上（企業価値向上）

売上増（付加価値向上）

信用度維持･向上

コスト減(ロスセーブ)

職務経歴の迅速な提供

情報共有･活用

案件件数を増やす

値上げ提供価格

（単価）をあげる

生産性向上

営業力強化

リピートを増やす

タイムリーな提案

差別化付加価値増

既存事業の売上拡大

新規事業の立上げ

チャンスロス（機会損失）

アサイン状況のタイムリーな

把握

プロジェクトの円滑な運営

新規を増やす

営業マンを増やす営業の事務処理負荷軽減

適切な予実管理

売上･経費タイムリーで高精度な把握

（

社内振替の管理

事業部、ﾁｰﾑ毎に異なるﾋﾞｭｰが必要

稼働率を上げる

良質案件

実績

人数（要員数）

積極的採用

離職率を減らす

モチベーションアップ

適正な評価個人売上のリアルタイムな

把握

個人別スキル情報の把握

入力作業の簡素化

操作性向上レスポンス回線障害の回避

二重入力の排除

適切な営業活動

案件の適切な優先順位つけ見落とし案件の撲滅ToDo作業の把握

ｽﾃｰﾀｽ一覧金額

契約期間、時期

システムによる案件情報の提供

営業会議での情報共有

発生元での直接入力

（事業部、福数人で）二重入力の削減

（間違いの防止）

データ連携

予算と実績の同一粒度での

対比

事業部単位での予実管理

事業の円滑な運営

社会的信用度の向上

内部統制の確立

適正な情報開示

ﾘｽｸﾎﾟｲﾝﾄの把握コントロール

手作業の自動化早期の決算報告連結決算

の自動化ｺｽﾄ･売上予測の正確な

リアルタイムの把握

利益の維持

収支管理表適正な運用プロジェクト情報

（経費･工数･アサイン）のタイムリーな入力

予算

実績

契約管理

精度ある売上予測

厳正な評価

適正なアサインメント（スキル･思考）適正な

労務管理勤怠の承認

精度ある稼動予実一覧（アサイン表）

豆蔵の決算早期化

社内情報案件情報の共有

原価計算方式の見直しと自動化

入力の分散（経費･勤怠）

経理部のチェック作業負荷の削減提出期限の

厳守

ゴール記述書プログラム計画　　　

PSRM

PJSRM SRM

a d アクティビティ

業務

情報

終了開始

概念アクティビティ図

概念クラス図　 ☆TFP分割　（Thing図、Function図、Place図）

PRM

IRM

ud ユースケースモデル

c d 論理モデル

0..*0..*

0..1

1..*

10..*

要求リスト

情報ビュー

プロジェクト定義

プロジェクト　　ゴール記述書

コタツモデル

What What

How How


プロセスビュー

Structure（要求開発からシステム開発へ）

a d アクティビティ

業務

情報

終了開始

概念アクティビティ図

概念クラス図　 ☆TFP分割　（Thing図、Function図、Place図）

PRM

IRM

c d 論理モデル

0..*0..*

0..1

1..*

10..*

要求リスト

情報ビュー

サービスビュープロセスビュー

システムユースケースユースケース記述

ud ユースケースモデル

情報ビュー

cd 分析クラス図

0..*

0..*

0..1

1..*

cd 設計クラス図

cd 設計クラス図

id コンポーネントモデル

パッケージ

パッケージ

パッケージ

sd 相互作用

?

論理モデル::

?

論理モデル::

?

論理モデル::

?

論理モデル::

?

論理モデル::

イベントフロー

シーケンス図

アプリケーションスコープ

エンタープライズレベル

アプリケーションレベル

設計クラス図（アーキテクチャ）

配置図

ＥＲ図

要求開発システム開発

What What

How How


システム開発におけるＶ字モデル

システム要件

サブシステム要件

コンポーネント要件

モジュール要件単体テスト

コンポーネントテスト

サブシステムテスト

受け入れテスト

３．要求開発の意義


評価

評価

評価

評価

要求開発の目指す・変形Ｖ字モデル

システム要件

サブシステム要件

コンポーネント要件

モジュール要件単体テスト

コンポーネントテスト

サブシステムテスト

受け入れテスト

ビジネス要求ビジネステスト

要求開発

システム開発

ValidationVerification結果イメージの予測

３．要求開発の意義


ToBeビジネス（結果イメージ）の予測

方式How

方式How

方式How

方式How

方式How

ビジネス戦略What

立案

戦略の根拠Why



戦略の根拠Why 戦略の根拠

Why

準備

デザイン・シフト


ビジネス価値とビジネス方式関係

A

B

価値What

価値What

価値What

要求開発（時間軸）

方式How

価値What

価値What

価値What

要求開発（時間軸）

方式How方式How

方式How方式How方式How


ビジネス戦略のトリアージ

ビジネス戦略

トリアージ後選択された戦略

２００７年３月

２００８年３月

引き継がれる戦略

２００８年１０月

１年

７ヶ月

要求を開発（実現）

要求を開発

引き継がれる戦略

新たに見つけられた戦略

新たに見つけられた戦略



優先順位


これからのアーキテクトの課題

ビジネスとITを分けて考える（WhatとHowの分離）

現状システム

要求

ビジネスの見える化手法を確立（戦略と実現の分離）

NEXT

システム設計実装

ビジネス IT

ビジネス戦略

システム要求

ビジネスオペレーション


ビジネス IT

What How

What HowWhat How What How

見える化を目的で繋げる（分離したもの同士の最適なリレーション）

NEXT

IT

What HowWhat How What How

ビジネス戦略

システム要求

ビジネスオペレーション


ビジネス

Howからの突き上げによるビジネス価値増大のための見える化

NEXT


要求開発プロセス（プロセスキャビネット）のイメージ

Plan

Do

Check

Act

Phase：　　　　段階的に詳細化・具体化していく

Disciplines

PP

C C

D D

AA

作業項目名

P

C

D

A

P

C

D

A

作業項目名

準備立案デザイン　シフト　

７．要求開発プロセス

Structure


実際のプロセスキャビネット

要求開発プロセスキャビネット

段階初期知識の可視化と合意に基づく計画ビジネス課題に関する概観の可視化新ビジネスのデザインシステム開発への移行

・フェーズ基本計画・要求開発プロジェクトのゴールの設定・要求開発チーム編成計画・準備教育計画作成

・フェーズ基本計画・モデリング戦略策定・ビジネス要求評価方法の策定・教育計画の作成・ビジネス可視化プロトタイプ計画・システム基本構想策定計画

・フェーズ基本計画・ToBeモデルの評価方法の策定・IT基本要求の評価方法の策定・ビジネス可視化プロトタイプ計画の見直し・システム基本構想策定計画

・フェーズ基本計画・システムToBeモデルの評価方法の策定・IT基本要求の評価方法の策定・システム移行計画書達成評価基準の明確化

計画

・要求開発プロセスのカスタマイズ・実施計画書作成

ビジネスモデル・ビジネス課題の理解・プレビジネスモデリング(Option)

・概観ビジネスモデリング・ビジネスToBeモデリング・システムToBeモデリング

要求モデル・ビジネス要求の開発・IT基本要求の開発・IT基本要求の開発

教育

・コアメンバー教育 (Option)・動機付けセミナー(Option)・教材の作成(Option)

・要求開発メンバー教育

システム化・プロトタイプ開発・プロトタイプ開発・システム移行計画書作成

Check

・承認権限者による検証・メンバー責務・スキルの確認・モデリングの評価（Option）・ビジネス課題の評価・教育実施評価

・承認権限者による検証・プロジェクトミッションの評価・モデリング戦略評価・概観ビジネスモデリング評価

・承認権限者による検証・ビジネスToBeモデルの評価・IT基本要求の評価・プロトタイプの評価・システム基本構想の評価

・承認権限者による検証・システムToBeモデルの評価・IT基本要求の評価・システム移行計画書内容の評価

Action

・計画の見直し・改善・メンバー構成の見直し・教育計画の再計画・必要であればビジネス課題の理解のやり直し・メンバー構成の見直し・必要であれば、再教育を期間を検討する・すぐやるカイゼン

・計画の見直し・改善・構想の見直し・改善・すぐやるカイゼン

・計画の見直し・改善・構想の見直し・改善・すぐやるカイゼン

・計画の見直し・改善・すぐやるカイゼン

シフト shift準備 arrangements 立案 draft デザイン design

Do

Phase

Decipliens

Plan



要求開発のフェーズ

準備

立案

デザイン

シフト

■ビジネス戦略の把握とプロジェクト課題の見極め　・ビジネス戦略、ＩＴ戦略の見える化　・プロジェクト課題の見極めのための、ざっくりとした見える化　・必要人材のアサイン（我々で果たしてプロジェクト課題を解決できるか？：リソース）　・プロジェクトターゲット範囲の決定（どの領域をどこまでやるの？：スコープ）　・要求開発プロジェクトゴールの策定

■概観の把握と可視化　・モデリング戦略（ToBe、AsIs業務モデルの把握のための順序戦略）　・プロジェクトゴールにスコープしたビジネス領域の外観を見える化（攻略点の把握）　・当初から課題とされているビジネス要求の抽出と整理（本質的見極め）

■ToBe業務の設計　・ToBe業務の設計　・ビジネス要求開発、IT基本要求の開発

■システム計画　・IT基本要求の抽出　・システム移行計画書の作成



要求の開発および獲得

• 要望

– 業務視点でだされた、ビジネスおよびシステムに対する「XXXのためにXXXしたい。」といった要望。

• 要求

– 要求開発チームで、意味不明な要望、要望の重複排除、似ている要望を整理することで要求に格上げされる。

• 要件

–期間コストを踏まえて、どのシステム開発で取り入れるのか決定されたシステム要件。

３．要求開発における要求の開発および獲得


要望-要求-要件への変化

要望　要求　

　業務要求

　システム要求

0…＊

非機能要求

　機能要求

　システム要件

　ユースケース

ビジョン

方針

個別方針

トップ・品質管理　例：　「検査業務を早く、安く、正確に！」　

管理者・品質管理（業界標準等）　　　　　　　　例：管理者「効率化を図るために、再測を止める」　　　　　　　　　　品質管理「セキュリティのために、個人特定機能が必要」

現場　例：担当者「業務ミスを犯さないために、二重チェックを行う」

（会議体で検討）・重複を省く･グループ分け・重要度の管理・業務かシステムかの判断・要求の優先度付け・目的に対する対策を分析　し、参加者の納得できる方法を仕上げる。

目的対策

　アーキテクチャ

（会議体で分析）・システム化対象の選択・システム化実現方法の　選択検討と合意･リリース予定日の設定

要件　

　業務要件

（会議体で分析）・コンセプトの再確認・運用方法の確立・例外事象の洗出・システム利用方法・上記の標準化

要求

コンポーネント



要求の生息地

• 原住民– 初めから企業ミッションの中に生息している、そもそも達成

すべき最優先要求。

– いままでの業務の延長から見つかる要求。

– いままでのシステムの中に生息して、今後も必要となる要求。

• 未開の土地– 業務改善により始めて姿を見せる要求。恥ずかしがりやで

、まだ形がはっきりとせず、個人の意識の中に眠っているので、みんなで目に見えるように可視化しないと出てきてくれない。

• 暗黙知域– 業務メンバーと開発メンバーの意識の中に暗黙知として眠

っており、これが基で様々なトラブルを引き起こす。



ＴＦＰ分割概要（なぜＴＦＰ分割か？）• データモデル

– 長所• 物と場だけに着目する。所詮はデータ集合を静的に現すものなの

で、非常に解りやすく曖昧性がない。

– 短所• 機能（業務）との関係が希薄。業務処理の概念化が異なる図

(DFD)として表現するしかない。

• オブジェクト（クラス）モデル– 長所

• 機能的なクラスを抽出するために、機能概念を含んだ自然な概念世界を表現できる。

– 欠点• 概念の中に機能的なクラスが存在すると、機能の中に関連が隠さ

れてしまったり、機能の入出力関係と、「もの」と「もの」との関係が混在することになり非常に曖昧になる。


Thing、Function、Placeにクラスを分類する

概念（クラス）

Thing

Function

Place

…もの（情報）として識別された単位。　 Entity(属性の集合が一般的)

•イベントイベント（事象）やトランザクショントランザクション（取引）

　の結果・記録も「もの」に分類

…機能として識別された単位　 Control(機能名がクラス)

　　通常、属性と操作がない。　

…場所を示す

イベントの記録としてThingに置くのがポイント


クラスを　Thing、Function、Placeの中でさらに分類する

概念（クラス）

イベント系

リソース系

機能系

ルール系

Thing

Function

Place

仕訳

科目商品顧客

取引注文

店

取引業務注文業務

Ａ取引Ｂ取引

場所系会社

大分類小分類事例

モノ

コト

スル

キソク

バ


Thing図の例

Thing図 Function Placeにはとを含めてはならない。

?

cd 論理モデル

顧客客

商品

1 1..*

0..*

1..*+購入商品

?cd 論理モデル

勘定科目仕訳

累積データ

- 借り方計: int- 貸し方計: int

BS/PL

1..*0..1

+貸し方

1..*0..1

+借り方

1..* +月次単位

1 +対象科目

?

科目11

Thing図例ピンク系統で表現。またはステレオタイプ<<Thing>>を使う

ものとものとの関係


Function図の例

Function図にはを含めてよいThing

?cd

勘定科目仕訳

累積データ

- 借り方計: int- 貸し方計: int

BS/PL

月次更新支社

1..*0..1

+借り方

1..*0..1

+貸し方?

科目1 1

Function図例グリーン系統で表現。またはステレオタイプ<<Function>>

ものの使われ方（ものの価値証明）

支社


Place図の例

Place図

クラス表現の場合　　　…ブルー系統で表現。またはステレオタイプ<<Place>>パッケージ表現の場合…特になし

Place図例１

とを含めてよいThingFunctionには

?

cd

店舗

本社

売上

顧客商品0..*1..*

+購入商品

<<購入される>>

もの・ことを置く場の定義場により価値が出る！


ＴＦＰ分割手法まとめ

ものとものとの関係

ものの使われ方

ものとことをおく場の定義

Thing図Function図Place図

ThingThing

Function

Function

Place

ビジネス普遍概念ビジネス具現的概念（ビジネスの本質に着目）（ビジネスの価値に着目）

ＳＯＡビジネス

オブジェクト汎用概念

ＤＢ設計アーキテクチャ設計分散協調設計

分析対象

開発に移行可能な概念