39
The solution beyond the solution. MAMEZOU 上流の要求開発 上流の要求開発 下流の要求開発 下流の要求開発 上流といっても広すぎる要求開発の世界株式会社 豆蔵

Upstream and downstream in Requirement Development

Embed Size (px)

DESCRIPTION

オープンコミュニティ「要求開発アライアンス(http://www.openthology.org)」2008年4月度定例会の発表資料です。 Open Community "Requirement Development Alliance" 2008 April regular meeting of the presentation materials.

Citation preview

Page 1: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 

上流の要求開発上流の要求開発下流の要求開発下流の要求開発

~上流といっても広すぎる要求開発の世界~

株式会社 豆蔵

Page 2: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 2

方向付け 推敲     構築      移行

Aシステム方向付け 推敲     構築      移行

Bシステム方向付け 推敲     構築      移行

Cシステム

経営分析

ビジョン、ミッションの確立

問題点分析

ビジネスゴール設定

広義のプロジェクト

狭義のプロジェクト

システム開発

要求開発

  準備    立案     デザイン    移行

検証評価

プロジェクトにおける「要求開発」

ビジネス要求からシステム要求を導くビジネス要求を開発する システム要求を元にシステムを開発する

なんとなくモヤモヤとしていた領域

Page 3: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 3

要求開発は、一筋縄ではない

• システム開発より手前を要求開発とくくった– 広さがわかっていなかった

• 「要求開発はじめました」と掲げたとたん、色々な球が飛んできた– 「冷やし中華」とか「エビスビール」とはだいぶ違う

• 大きくは、2分類– システム開発から遡った上流•いきなり作らないで、2、3歩下がって上位目的や業務

との整合性確認

– 企業戦略から降りてくるIT戦略、システム化計画•経営計画などから大上段に(EAとか投資判断とか)

•個々のシステム開発は、この先に

Page 4: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 4

下流要求開発の特徴

• システムの機能要件などが具体的に上がっている。システムイメージがある

• ほっておくと、PMが要件定義を始める

• いきなり作っていいのかと自問する、いやいやと自答する

• いまさら時間をかけて上流をきっちりやりなおすわけにはいかない

• 下流とはいえ、ビジネスにどう貢献するかは、トレースしておかなければならない(役に立つシステムを作るのが大目標)

• プロジェクトがブレないためのプロジェクトメーキングの意味が大きい(何のためにかを固める)

Page 5: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 5

方向付け 推敲     構築      移行

Aシステム方向付け 推敲     構築      移行

Bシステム方向付け 推敲     構築      移行

Cシステム

経営分析

ビジョン、ミッションの確立

問題点分析

ビジネスゴール設定

広義のプロジェクト

狭義のプロジェクト

システム開発

要求開発

  準備    立案     デザイン    移行

検証評価

「下流の」要求開発

ビジネス要求からシステム要求を導くビジネス要求を開発する システム要求を元にシステムを開発する

下流の要求開発

あっという間にやる

Page 6: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 6

上流の要求開発

• 経営戦略、事業戦略からITがどうあるべきかを決定する

• プロジェクトではなく、まずはIT全体を扱う

– IT資産の整理(既存システムの価値分析、ポートフォリオ)

– 他の投資項目との比較でプロジェクトをやる、やらないを決める(下流はやることは決まっている)

• EAと密接に絡む

• 全体の中で、ToBeに向うときにプロジェクトが発生する。その後で下流の要求開発につながる

• プログラムマネジメントまでを含む?

• IT戦略策定に該当する?

– ロードマップ

Page 7: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 7

方向付け 推敲     構築      移行

Aシステム方向付け 推敲     構築      移行

Bシステム方向付け 推敲     構築      移行

Cシステム

経営分析

広義のプロジェクト

狭義のプロジェクト

システム開発

要求開発

  準備    立案     デザイン    移行

検証評価

「上流の」要求開発

ビジネス要求からシステム要求を導くビジネス要求を開発する システム要求を元にシステムを開発する

上流の要求開発

こってりやる

IT戦略策定システム化計画

Page 8: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 8

今やITは複雑な生態系

• ITの世界はすでに不可分になっている

事業戦略

エンタープライズ

システム

IT戦略

分散システムビジネス

ソリューション事業部

エンジニアリングソリューション

事業部

IT戦戦略支援事業部

アプリケーション

制御

下流の

要求開発

ちなみに

豆蔵の事業部構成

上流の

要求開発

Page 9: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 

下流の要求開発本当にそれを作っていいの

Page 10: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 10

要求開発の流れ

財務

顧客

プロセス

教育

ud ユースケースモデル

サービスA

サービスC

サービスB

cd Eコマー ス事業

顧客

- 氏名: - 住所: - 電話番号:

会員

- ID: - パスワード: - 有効期間:

+ 認証する()

注文

- 注文年月日:

仕入先

- 名称:

商品タイトル

- 名称:

非会員 顧客

仕入先・商品タイトル関係

- 販売期間: - 販売単価:

購 入商品タイトル

- 注文時販売単価: - 注文量: - 消費税: - 販売金額: - 送料:

注文ル ール

決済方 法

+ 認証する()

決済方法=現金 決済方法=カー ド

カード会社

+ 認証する()

値引きルー ル送料計算ルール

ポイント

- 現ポイント数:

+ 金額換算()

ポイント加算

- ポイント加算年月日: - 加算ポイント:

決済方法- 個別

- 金額:

+ 認証する()

決済方法-ポイント利用

- ポイント利用年月日: - 利用ポイント数:

+ 金額換算()

注文ル ール型商品分類

- 名称:

1

*

1

*

1

1

*

1

*

1

1

0..1

1

*

注文ルール型

*

1

注文ルール型*1

1

*

1

*

1

1

*1

1

<<powertype>>

*

*

*

*

*

UC01: 商品情報を管理する商品 係

UC04: 販売情報を登録するレジ 係

UC02: 値札を作成する

UC03: 売上を集計する

販 売管理 係

要求体系の構造化ゴールの設定 ビジネスユースケース作成 業務フロー作成 概念モデリング

用語集

用語集

システムユースケース図作成

レシート・プリンタ

レシート印刷(販売 : 販売, 店舗 : 店舗)

キャッシュ・レジスタ・パネル

新規入力指示()入力準備完了通知()バーコード読取成功通知()販売数入力()小計表示()精算指示()合計表示()預かり金入力(金額)おつり表示()販売登録完了通知()

バーコード・リーダ

活性化()不活性化()

販売明細

販売単価販売数 = 1

販売数設定(販売数)

メーカ台帳

店舗

名前電話番号住所

商品検索(商品コード) : 商品販売履歴追加(新規販売 : 販売)

1

1

1

1

販売台帳

販売履歴追加(新規販売 : 販売)11

11

キャッシュ・レジスタ

新規入力指示()販売登録初期化()バーコード読取(バーコード)バーコード解析(バーコード)販売数入力()精算指示()預かり金入力(金額)販売登録後処理()

11

レシート・プリンタ

11

0..*

1

0..*

1

1

1

パネル

1

1

1

1

バーコード・リーダ1

1

0..1

0..1

0..1

現在の明細

0..1

メーカコード名前電話番号住所

0..*

0..1 メーカ・リスト

0..*台帳

0..1

商品台帳

商品検索(商品コード) : 商品1

1

1

1

販売

預かり金日時

新規明細(品目 : 商品) : 販売明細預かり金設定(金額)

0..*

0..1 販売履歴

0..*台帳

0..1

0..1

0..1

現在の販売

0..1

0..1

商品

コード名前定価販売価格登録日

0..*

1

製品0..*

製造元

1

0..*0..1

商品リスト

0..*

台帳

0..1

0..*

0..*販売

0..*

品目 0..*

洗練されたクラス図分析レベル

分析モデル作成

非機能要件

・・・・・・・・・・・・・・・・・・

非機能要件抽出

(各種開発規約・条件)

プロジェクトメーキング 業務設計(ビジネスモデリング)

システム開発への移行(RFP作成など)

利益向上(企業価値向上)

売上増(付加価値向上)

信用度維持・向上

コスト減(ロスセーブ)

職務経歴の迅速な提供

情報共有・活用

案件件数を増やす

値上げ提供価格

(単価)をあげる

生産性向上

営業力強化

リピートを増やす

タイムリーな提案

差別化付加価値増

既存事業の売上拡大

新規事業の立上げ

チャンスロス(機会損失)

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

労働力のロス

(稼働率)

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

事務処理コストに伴うロス

(契約にかかるコスト)

新規を増やす

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

適切な予実管理 売上・経費

タイムリーで高精度な把握

入力の分散(発生元での入力)

社内振替の管理

事業部、チーム毎に異なるビューが必要

稼働率を上げる

良質案件

実績

人数(要員数)

積極的採用

離職率を減らす

モチベーションアップ適正な評価個人売上の

リアルタイムな把握

個人別スキル情報の把握

入力作業の簡素化操作性向上レスポンス

回線障害の回避

二重入力の排除適切な営業活動

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

ステータス一覧金額

契約期間、時期

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

営業会議での情報共有

発生元での直接入力

(事業部、福数人で)二重入力の削減

(間違いの防止)

データ連携

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

事業部単位での予実管理

事業の円滑な運営

社会的信用度の向上

内部統制の確立

適正な情報開示

リスクポイントの把握コントロール

手作業の自動化早期の決算報告連結決算の自動化コスト・売上

予測の正確なリアルタイムの把握

利益の維持

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

(経費・工数・アサイン)のタイムリーな入力

予算実績

契約管理

精度ある売上予測

厳正な評価適正な

アサインメント(スキル・思考)

メンバーのマネジメント

適正な労務管理

勤怠の承認

精度ある稼動予実一覧(アサイン表)

豆蔵の決算早期化

社内情報案件情報の共有

原価計算方式の見直しと自動化入力の分散

(経費・勤怠)

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

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

何をすることで

何がいつ

までにどう

なるのか評価尺度

目標値

Page 11: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 11

下流要求開発の流れ

システムユースケース機能要件一覧非機能要件一覧主要画面イメージ開発計画書(スケジュール、ロードマップなど)

To-Be業務に対する、ビジネスユースケース業務フロー(アクティビティ図)概念モデル(クラス図)ビジネスルールリスト課題解決リスト

As-Is業務に対する、ビジネス概略図ビジネスユースケース業務フロー(アクティビティ図)概念モデル(クラス図)ビジネスルールリスト

プロジェクト定義書ステークホルダーリスト要求分析ツリーゴール記述書課題リスト成果物の例

システム化範囲をサブシステムとして切り出す・システム開発スコープの決定・動作イメージの明確化・システム開発プロジェクトの計画

課題を解決するTo-Be業務を設計する・業務の最適化・不明瞭ルールの整理・課題解消の確認

業務をシステムとして表現する・業務の可視化・課題の特定

プロジェクトの外枠を固める・プロジェクトの意義・目的の明確化・プロジェクト組織の構成・プロジェクトの全体構造の把握・メンバーの意識付け

趣旨

システム開発への移行業務の設計・再設計業務のモデル化プロジェクトメーキング主題

シフトフェーズデザインフェーズ立案フェーズ準備フェーズOpenthologyフェーズ

Page 12: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 12

プロジェクトメーキング時のオーバーヘッド

• 推進体制がまとまらない

– どんな体制がいいかわからない

• ユーザ側と開発側が噛み合わない

– いつまでも踏込みが足りない

– ゴールや背景の理解が異なる(同床異夢)

• レベルがばらばら、脈絡ない様々な要求

– 全体の構造が見えない

• リズムが生まれない

– 手順やシナリオがない

Page 13: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 13

コタツモデルは健在

• 経営、現場、ITの立場がバランスする必要がある

– それぞれの視点で見る人が必要

• コアチーム、プロジェクト、外郭、その他で分類

プロジェクトコア(推進、専任に近い)

プロジェクトメンバー(全体会議の範囲)

外郭メンバー(協力要請されている)

経営の立場

現場の立場 ITの立場

Page 14: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 14

コアメンバーで先行する

• 最初の1、2週間でプロジェクトの外枠を固める

• ステークホルダーを巻き込まないといけないが、まずは、イニシャルモデルを構築してから– 頭まっ白でユーザに臨むと信頼を失う

– 時間調整で、のんびりしてしまう

– 自分たちなりの理解と仮説をもって、ポイントを絞って、検証を

• 但し、モデルはいっしょに作るのが基本– イニシャルモデルは、予行練習。

– リズムがないとユーザはのってこない

Page 15: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 15

プロジェクトのコントロールのために

• 準備フェーズは、プロジェクトをつかむフェーズ

– プロジェクトのインストール

– プロジェクトの外枠固め

• プロジェクトの全体構造を共有する

– そもそもの目的を見失わない

– 課題、様々な要求、解決策の構造が見えている

– 詳細に入り込んでも、戻り先がわかる

– 関わる人を忘れない

• 見える化する

– 攻略点、コントロールポイントを絞る

– 見えるようにしてから議論する(空中戦を地上戦に)

Page 16: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 16

プロジェクトは混乱する

• 細部から入ると全体を見失う

– いきなり詳細な議論をしていくと元々の目的を見失いがち

– 様々な思惑が加わって本質的でない要求がたくさん出てくる

• 上位の目的(そもそもの要求)をピン留めしておく

– 全体構造を把握し、細部に入っても、上位がぶれないように押さえておく

– 適切な(ほどよい)ゴール設定が必要

– 混乱したら立ち戻れるようにしておく

Page 17: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 17

プロジェクトの必須事項を明確にし、チームでの共通認識を確立する。

プロジェクト定義

目 的

2008-2-1日 付1.00版フォーム

No文書名

現行システム+新規販売業務のサポート。 配達計画機能は含めないスコープ

2010年12月に現行システムのH/Wの保守期間切れ。3カ年計画でのコミットメント

制約事項

2007年度の業績見通しで下方修正がないこと(下方修正の場合はプロジェクト見直しをかける)

前提条件

全体のシステム化:2008年1月 ~ 2010年7月(カットオーバー)

要求開発:2008年1月 ~ 2008年5月末完了期間

1:様々な環境の変化でビジネスの刷新が迫られている(システムによる対応が必要)。

2:長期に継ぎ足して作ってきたので機能の追加、変更が困難になっている

3:システムH/Wの保守が切れ、ビジネス継続性が危ぶまれる

背景

1:ビジネス環境変化に柔軟かつ経済的に対応できる情報システムを提供する。

2:販売業務の改善に対応する機能を提供する。

3:今後10年間の使用に耐える技術、道具立てでシステムを刷新する。

目的

ReDA販売管理システム再構築プロジェクト(RenewDAs Project)名称

その他

1) オーナー   企画部長 秋山 

2) コアチーム  情報システム部 吉田、 河内、 営業部 石田

               要求開発コンサル 坂巻

3) プロジェクト体制、ステークホルダー(体制図、ステークホルダーリストに記載)

組織

Page 18: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 18

ゴール記述、要求体系図、ステークホルダーリスト

• ステークホルダーリスト– 話を聞くべき人、気をつかうべき人の抽出– 利害関係者が納得ずく

• 現状の認識で合意• 全体としての必要性で合意• 決定プロセスで合意• 導入イメージで合意• 結果で大はずれなし

• 要求体系図– 様々な要求の全体構造がどうなっているかを一望する

• 目的ー手段の連鎖で構成• 上位目的への貢献度を説明する

– 個々の詳細の合意でなく文脈での合意

• ゴール記述– 適切なゴール設定は要求体系図の3~7レベルに現れる

• 具体的数値目標が出せる• 抽象的過ぎず、詳細すぎず• 程いい因果関係が認められる

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

何をすることで

何がいつ

までにどう

なるのか評価尺度

目標値

利益向上(企業価値向上)

売上増(付加価値向上)

信用度維持・向上

コスト減(ロスセーブ)

職務経歴の迅速な提供

情報共有・活用

案件件数を増やす

値上げ提供価格

(単価)をあげる

生産性向上

営業力強化

リピートを増やす

タイムリーな提案

差別化付加価値増

既存事業の売上拡大

新規事業の立上げ

チャンスロス(機会損失)

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

労働力のロス

(稼働率)

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

事務処理コストに伴うロス

(契約にかかるコスト)

新規を増やす

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

適切な予実管理 売上・経費

タイムリーで高精度な把握

入力の分散(発生元での入力)

社内振替の管理

事業部、チーム毎に異なるビューが必要

稼働率を上げる

良質案件

実績

人数(要員数)

積極的採用

離職率を減らす

モチベーションアップ適正な評価個人売上の

リアルタイムな把握

個人別スキル情報の把握

入力作業の簡素化操作性向上レスポンス

回線障害の回避

二重入力の排除適切な営業活動

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

ステータス一覧金額

契約期間、時期

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

営業会議での情報共有

発生元での直接入力

(事業部、福数人で)二重入力の削減

(間違いの防止)

データ連携

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

事業部単位での予実管理

事業の円滑な運営

社会的信用度の向上

内部統制の確立

適正な情報開示

リスクポイントの把握コントロール

手作業の自動化早期の決算報告連結決算の自動化コスト・売上

予測の正確なリアルタイムの把握

利益の維持

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

(経費・工数・アサイン)のタイムリーな入力

予算実績

契約管理

精度ある売上予測

厳正な評価適正な

アサインメント(スキル・思考)

メンバーのマネジメント

適正な労務管理

勤怠の承認

精度ある稼動予実一覧(アサイン表)

豆蔵の決算早期化

社内情報案件情報の共有

原価計算方式の見直しと自動化入力の分散

(経費・勤怠)

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

Page 19: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 19

運用管理の負荷増大

有馬23グループの情報システム、インフラの管理・運営を実施

情報システム部

経営情報のリアルタイム把握

大石22グループの経営戦略立案経営戦略室

業務効率化、精度向上、迅速化

川端43経理業務に加え、法務、総務機能の実施

財務・経理

統制事項の追加田辺13内部統制監査の運営内部統制監査室

監査情報の信頼性向上

相沢31監査の実施監査役

監査情報の信頼性向上

OO監査法人

11財務諸表が会計原則に準拠しており、企業の財政状態や経営状態を適正に表示しているか否かについての監査を実施

監査法人

経営指標の迅速な把握。経営の見える化

吉沢社長43会社経営の実施経営

想定される影響(メリット・デメリット)

具体例人数重要度

説明ステークホルダー名

重要度 : 高い 3 ・ 2 ・ 1 低い (敬称略)

ステークホルダーリスト(例)

Page 20: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 20

初期の入力情報を構造化する

• たいていのプロジェクトでは、あらかじめ、課題、要求、解決策が仮説的に与えられている

• 但し、その粒度、重要度、文脈はまちまち

• 系統的に整理することで、プロジェクトの対象の全体構造が見えてくる

• 文脈をつかむことで、押さえるべきところ(適切なゴール)を特定できる

Page 21: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 21

要求分析ツリー(例:ReDa家具)現状における課題 

3景気の低迷、少子高齢化、ライフスタイルの変化のために、売上が伸び悩んでいる。

5低価格の輸入家具の増加、通販による販売コストの低減のために、価格競争が激化している。

1全国8ケ所のショールームを基軸にしているために、それ以外の顧客とのファーストコンタクトの機会が少ない。

4.顧客との継続的な関係が維持できていないために、リピート数が少ない。

6.売上に比してショールーム販売のコストが高いために、利益を圧迫している。

2不良在庫が多いために、在庫保管、処分にコストがかかっている。

利益向上(企業価値向上)

売上増(付加価値向上)

コスト削減(支出減)

変動費削減

固定費削減

販売コストの削減

販売数量の拡大(取引増)

一販売あたりの売上増大(客単価)

顧客定着率の向上

(リピート増)

反復利用にメリットがある

サービスに魅力がある

新規顧客の獲得

(大幅な増加)

低価格の実現

●新規購入者の  会員化率80%以上

●登録会員数  10万名

高級化

原価の削減

セット販売

顧客の不満解消

ニーズに適した魅力的な品揃え

販売対象顧客を拡大

品質による差別化

1回当りの購入点数UP

●120億円/年 売上増

解決策

G4顧客情報を一元管理し、顧客サービス向上、売上促進に活用する。

○優先度A

G2販売管理システムを再構築し、システム間の連携をする。

G7アフターサービス管理をシステム化する。

G8ネット販売サイトを構築し、ネットビジネス展開

G3多角的に販売情報を分析する。DWH導入。

G1アライアンスの推進

○優先度B

○優先度A

○優先度B

○優先度A

○優先度A

G5顧客満足度調査を定期的に実施する。

○優先度A

G6物流システムを構築し、効率的な配送を実現する。

○優先度B

要求システム関連

解決策システム

解決策運用

課題 要求【凡例】

優先度 A:高 B:中 C:低 ○:今回採用 ×:非採用

既存設備の稼働率最大化

新商品企画の強化

アフターサービスの充実

製品がリサイクルできる

ネット販売の開始

販売の効率化

不良在庫の低減

●納期達成率100%

●ネット販売件数  4万件/年

●販売コスト10%削減

会員制ポイント制の導入

適正な需要予測

●ポイント利用3万件/年

●システムによる配送管理100%

●利用件数5千件/年

●システムによる販売管理100%

一部製品を注文生産に切り替える

関連購買促進

購買への誘導

機会ロスの削減

顧客の不満の把握

一括発注の実施

物流コストを下げる

無料配送範囲を拡大

スピード回答の実現

配送計画の精緻化

システムによる配送計画

顧客のライフサイクル情報の把握

CRMの導入

顧客の購入履歴の把握

顧客満足度調査の実施

製造元の絞り込み

配送センターの統合

仮想ショールームによる補完

パート、アルバイト

の比率を上げる

不採算ショールームの閉鎖

スピード納期の実現

リフォーム、クリーニングサービスの展開

レコメンデーションサービス

バスケット分析

コスト削減

会員向けサービスの充実

対応・納期が迅速

顧客のライフサイクル

にあわせた販促

顧客ニーズの正確な把握

市場・競合調査

売れ筋死に筋の把握

販売チャネルの拡大

レコメンデーション機能

引越し、ブライダル、

ハウスメーカーと提携

リアルタイムの在庫状況を把握したい

欠品を減らす

接客の向上

他店の在庫を照会したい

教育を実施

入荷予定を把握したい

システムによる発注管理

システムによる販売管理

ポイント管理のシステム化

システムによる在庫管理

配送のアウトソーシング

販売分析DWH

ネットサイト

全店舗の在庫照会

Page 22: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 22

プロジェクトのゴール設定

• プロジェクトの成功はシステムが稼動することではない

– システム開発プロジェクトの成功は、QCD(品質、コスト、納期)の遵守といわれている

– スポンサーはシステムを作りたくて作っているわけではない

– システムを作るための元々の目的(業務上の目的)があったはず

• プロジェクトの成功をビジネス的表現で表す

Page 23: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 23

ゴール記述書(例)

プロジェクト名:  LSCサポートシステム開発プロジェクト 作成日  2005年12月11日

No 何をすることで 何が いつまでに どうなるのか 評価尺度 目標値

1

ネット販売サイトを開設することで 新しい販売機会が

2009年4月

創出され、結果として販売件数が大幅に増加する

サイトアクセス数

100万件/年

2

顧客管理システムを構築することで 様々な会員サービスが

2009年4月

提供され、結果として新規顧客とリピーターが大幅に増加する

ポイント利用数

3万件/年

(特記事項)

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

Page 24: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 24

準備フェーズのモデル

運用管理の負荷増大有馬23グループの情報システム、インフラの管理・運営を実施情報システム部

経営情報のリアルタイム把握大石22グループの経営戦略立案経営戦略室

業務効率化、精度向上、迅速化川端43経理業務に加え、法務、総務機能の実施財務・経理

統制事項の追加田辺13内部統制監査の運営内部統制監査室

監査情報の信頼性向上相沢31監査の実施監査役

監査情報の信頼性向上OO監査法人

11財務諸表が会計原則に準拠しており、企業の財政状態や経営状態を適正に表示しているか否かについての監査を実施

監査法人

経営指標の迅速な把握。経営の見える化

吉沢社長43会社経営の実施経営

想定される影響(メリット・デメリット )

具体例人数重要度

説明ステークホルダー名

利益向上(企業価値向上)

売上増(付加価値向上)

信用度維持・向上

コスト減(ロスセーブ)

職務経歴の迅速な提供

情報共有・活用

案件件数を増やす

値上げ提供価格

(単価)をあげる

生産性向上

営業力強化

リピートを増やす

タイムリーな提案

差別化付加価値増

既存事業の売上拡大

新規事業の立上げ

チャンスロス(機会損失)

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

労働力のロス

(稼働率)

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

事務処理コストに伴うロス

(契約にかかるコスト)

新規を増やす

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

適切な予実管理

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

入力の分散(発生元での入力)

社内振替の管理

事業部、チーム毎に異なるビューが必要

稼働率を上げる

良質案件

実績

人数(要員数)

積極的採用

離職率を減らす

モチベーションアップ

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

個人別スキル情報の把握

入力作業の簡素化

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

二重入力の排除

適切な営業活動

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

ステータス一覧金額

契約期間、時期

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

営業会議での情報共有

発生元での直接入力

(事業部、福数人で)二重入力の削減

(間違いの防止)

データ連携

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

事業部単位での予実管理

事業の円滑な運営

社会的信用度の向上

内部統制の確立

適正な情報開示

リスクポイントの把握コントロール

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

の自動化コスト・売上予測の正確なリアルタイムの把握

利益の維持

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

(経費・工数・アサイン)のタイムリーな入力

予算

実績

契約管理

精度ある売上予測

厳正な評価

適正なアサインメント(スキル・思考)

メンバーのマネジメント

適正な労務管理

勤怠の承認

精度ある稼動予実一覧(アサイン表)

豆蔵の決算早期化

社内情報案件情報の共有

原価計算方式の見直しと自動化入力の分散(経費・勤怠)

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

重視すべき立場からのインプット(課題、要求、解決案)

10

「サービス/業務・システム関連表」にて定義スコープ

現行システムのH/Wの保守期間切れ。3カ年計画でのコミットメント。制約事項

(本プロジェクトに影響をもたらすもの)

某社との提携がある場合、凍結して見直しをかける前提条件

全体のシステム化:20XX年末までにカットオーバー。年明けから運用開始。

グランドデザインの完了:20XX年XX月末までに期間

1:顧客の要求するリードタイムが実現できていない。

2:在庫が多く、資産回転率、保管場所の両面で問題。

3:現システムの機能不足(手作業の発生)。

背景

1:製造と販売を密に連携させ、効率的サプライチェーンを構築する

2:ビジネス環境変化に柔軟かつ経済的に対応できる情報システムを提供する。目的

製販一体化システム再構築プロジェクト名称

その他

製販一体化システム計画書(別途、構成案)成果物イメージ

1) オーナー 経営企画部長

2) 推進コアーチーム 経営企画2名 IS部門3名

3) ステークホルダー(ステークホルダーリストに記載)

組織 (別途組織図)

プロジェクト定義

ステークホルダーリスト

要求分析ツリー

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

何をすることで

何がいつ

までにどう

なるのか評価尺度

目標値

元々のプロジェクト目的との整合

適切なレベルの目標を設定

スコープからステークホルダーを特定

ゴール記述

既出のインプット情報(課題、要求、解決案)

Page 25: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 25

立案フェーズのモデル

運用管理の負荷増大有馬23グループの情報システム、インフラの管理・運営を実施情報システム部

経営情報のリアルタイム把握

大石22グループの経営戦略立案経営戦略室

業務効率化、精度向上、迅速化

川端43経理業務に加え、法務、総務機能の実施財務・経理

統制事項の追加田辺13内部統制監査の運営内部統制監査室

監査情報の信頼性向上相沢31監査の実施監査役

監査情報の信頼性向上OO監査法人

11財務諸表が会計原則に準拠しており、企業の財政状態や経営状態を適正に表示しているか否かについての監査を実施

監査法人

経営指標の迅速な把握。経営の見える化

吉沢社長

43会社経営の実施経営

想定される影響(メリット・デメリ ット )

具体例人数

重要度

説明ステークホルダー名ステークホルダーリスト

ud ユースケースモデル

サービ

スA

サービスC

サービ

スB

利益向上(企業価値向上)

売上増(付加価値向上)

信用度維持・向上

コスト減(ロスセーブ)

職務経歴の迅速な提供

情報共有・活用

案件件数を増やす

値上げ提供価格

(単価)をあげる

生産性向上

営業力強化

リピートを増やす

タイムリーな提案

差別化付加価値増

既存事業の売上拡大

新規事業の立上げ

チャンスロス(機会損失)

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

労働力のロス

(稼働率)

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

事務処理コストに伴うロス

(契約にかかるコスト)

新規を増やす

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

適切な予実管理 売上・経費

タイムリーで高精度な把握

入力の分散(発生元での入力)

社内振替の管理

事業部、チーム毎に異なるビューが必要

稼働率を上げる

良質案件

実績

人数(要員数)

積極的採用

離職率を減らす

モチベーションアップ

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

個人別スキル情報の把握

入力作業の簡素化

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

二重入力の排除

適切な営業活動

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

ステータス一覧金額

契約期間、時期

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

営業会議での情報共有

発生元での直接入力

(事業部、福数人で)二重入力の削減

(間違いの防止)

データ連携

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

事業部単位での予実管理

事業の円滑な運営

社会的信用度の向上

内部統制の確立

適正な情報開示

リスクポイントの把握コントロール

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

の自動化コスト・売上予測の正確なリアルタイムの把握

利益の維持

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

(経費・工数・アサイン)のタイムリーな入力

予算

実績

契約管理

精度ある売上予測

厳正な評価

適正なアサインメント(スキル・思考)

メンバーのマネジメント

適正な労務管理

勤怠の承認

精度ある稼動予実一覧(アサイン表)

豆蔵の決算早期化

社内情報案件情報の共有

原価計算方式の見直しと自動化入力の分散(経費・勤怠)

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

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

何をすることで

何がいつ

までにどう

なるのか評価尺度

目標値

ゴール記述

要求分析ツリー

アクターと提供すべきサービスの抽出

要求に関連したサービスの抽出

ゴールに関連したサービスを抽出する

cd Eコマース事業

顧客

- 氏名: - 住所: - 電話番号:

会員

- ID: - パスワード: - 有効期間:

+ 認証する()

注文

- 注文年月日:

仕入先

- 名称:

商品タイトル

- 名称:

非会員顧客

仕入先・商品タイトル関係

- 販売期間: - 販売単価:

購入商品タイトル

- 注文時販売単価: - 注文量: - 消費税: - 販売金額: - 送料:

注文ルール

決済方法

+ 認証する()

決済方法=現金 決済方法=カード

カード会社

+ 認証する()

値引きルール送料計算ルール

ポイント

- 現ポイント数:

+ 金額換算()

ポイント加算

- ポイント加算年月日: - 加算ポイント:

決済方法-個別

- 金額:

+ 認証する()

決済方法-ポイント利用

- ポイント利用年月日: - 利用ポイント数:

+ 金額換算()

注文ルール型商品分類

- 名称:

1

*

1

*

1

1

*

1

*

1

1

0..1

1

*

注文ルール型

*

1

注文ルール型*1

1

*

1

*

1

1

*1

1

<<powertype>>

*

*

*

*

*

ビジネスユースケース

業務フロー

概念モデル

サービスを実現する手順を表す

サービスに関わる概念を整理

業務に現れる概念を整理

基本的にAs-Is

Page 26: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 26

デザイン・シフトフェーズのモデル

cd Eコマース事業

顧客

- 氏名: - 住所: - 電話番号:

会員

- ID: - パスワード: - 有効期間:

+ 認証する()

注文

- 注文年月日:

仕入先

- 名称:

商品タイトル

- 名称:

非会員顧客

仕入先・商品タイトル関係

- 販売期間: - 販売単価:

購入商品タイトル

- 注文時販売単価: - 注文量: - 消費税: - 販売金額: - 送料:

注文ルール

決済方法

+ 認証する()

決済方法=現金 決済方法=カード

カード会社

+ 認証する()

値引きルール送料計算ルール

ポイント

- 現ポイント数:

+ 金額換算()

ポイント加算

- ポイント加算年月日: - 加算ポイント:

決済方法-個別

- 金額:

+ 認証する()

決済方法-ポイント利用

- ポイント利用年月日: - 利用ポイント数:

+ 金額換算()

注文ルール型商品分類

- 名称:

1

*

1

*

1

1

*

1

*

1

1

0..1

1

*

注文ルール型

*

1

注文ルール型*1

1

*

1

*

1

1

*1

1

<<powertype>>

*

*

*

*

*

業務フロー

概念モデル

システムスコープで切り出し

UC01: 商品情報を管理する商品係

UC04: 販売情報を登録するレジ 係

UC02: 値札を作成する

UC03: 売上を集計する

販 売管理 係

レシート・プリンタ

レシート印刷(販売 : 販売, 店舗 : 店舗)

キャッシュ・レジスタ・パネル

新規入力指示()入力準備完了通知()バーコード読取成功通知()販売数入力()小計表示()精算指示()合計表示()預かり金入力(金額)おつり表示()販売登録完了通知()

バーコード・リーダ

活性化()不活性化()

販売明細

販売単価販売数 = 1

販売数設定(販売数)

メーカ台帳

店舗

名前電話番号住所

商品検索(商品コード) : 商品販売履歴追加(新規販売 : 販売)

1

1

1

1

販売台帳

販売履歴追加(新規販売 : 販売)11

11

キャッシュ・レジスタ

新規入力指示()販売登録初期化()バーコード 読取(バーコード)バーコード 解析(バーコード)販売数入力()精算指示()預かり金入力(金額)販売登録後処理()

11

レシート・プリンタ

11

0..*

1

0..*

1

1

1

パネル

1

1

1

1

バーコード・リーダ1

1

0..1

0..1

0..1

現在の明細

0..1

メーカ

コード名前電話番号住所

0..*

0..1 メーカ・リスト

0..*台帳

0..1

商品台帳

商品検索(商品コード) : 商品1

1

1

1

販売

預かり金日時

新規明細(品目 : 商品) : 販売明細預かり金設定(金額)

0..*

0..1 販売履歴

0..*台帳

0..1

0..1

0..1

現在の販売

0..1

0..1

商品コード名前定価販売価格登録日

0..*

1

製品0..*

製造元

1

0..*0..1

商品リスト

0..*

台帳

0..1

0..*

0..*販売

0..*

品目 0..*

洗練されたクラス図分析レベル

非機能要件リスト

1.レスポンス  a)____  b)________2.セキュリティ要件・・・分析モデル

システムユースケース

人系とシステムレーンのI/Oを取り出す

As-IsからTo-Be

Page 27: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 27

ご参考

下流の要求開発は、連載中(vol. 15 – vol. 20 予定)

Page 28: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 

上流の要求開発うちはこういうITでいく

Page 29: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 29

情報システム部の悩ましい世界:作るばかりが仕事ではない

• 維持する(今のレベルを保つ)– 運用– 保守切れ対応

• 改善する(現状の不足を補う)– 統合する、効率化する

– 世間並みにする

– ビジネスに追従させる

– IT人材育成

• 攻める(ITをビジネスモデルに組み込む)– ITをビジネスの武器にする

– 新たな事業モデルにする

70~80%が保守・運用といわれている

Page 30: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 30

テーマ(個々の共通課題)

• 解決すべき課題の数々

– 内部統制・IT統制– 個人情報保護・情報漏えい対策

– セキュリティ対策

– 人材育成

– 共通基盤の確立・標準化

– ビジネス継続性の確保

– TCOの削減

– 新規技術への対応

– IT資産管理

Page 31: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 31

テーマ(重いテーマ)

• 企業のIT戦略の考え方

– 企業戦略とIT戦略の関係

– ITガバナンスをどのように効かせるか

– IT投資の考え方

• 情報システム部はどうあるべきか

– 自社でもつべき機能は

– 他部門、システム子会社、パートナとの棲み分け

– システム子会社の考え方

Page 32: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 32

2つのIT

• 差別化のためのIT– 付加価値のためのIT

(効率化は極めると付加価値へ)

– 本業と一体化したIT– ビジネスモデルを変革するIT

• 必要のためのIT– 基本はコスト削減、ミス削減、効率化

– 守りのIT、コンプライアンス

– 中枢機能としてのIT(基幹システム)

Page 33: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 33

日本はIT後進国といわれる:スポット的には解決できない

• 輪廻しているITの問題

– 企業内におけるITの戦略性が低い• 経営の中での認識が弱い。経営トップがITをわからない。理屈で

わかっても、感覚がない

• 積極的投資の対象になりきれていない。必要のためのITで手一杯

– ITに関わるメンバーの社内的地位が低い• 本業に対して、スタッフの扱い

• 何をしているかわからない

• 優秀な人材を当てていない

– ITで将来的にメインストリームになれる可能性が低い• 業務を知らない

• 偉くなれない

• キャリアパスが確立されない

輪廻をどこで断ち切るか

Page 34: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 34

例えば人材育成

• ビジネスとITを兼ね備えたメンバーの育成– どう育てる。トップの強い意志で育てる

– ITが肌感覚でわかる経営者

• キャリアパス、スキルマップ– 適正な評価。将来への安定した自己投資

• IT関連人材の健全な育成方法– IT業界と互換性をもつことで地位とモティベーショ

ンをもつ

– 企業を越えたローテーション(ユーザ側とベンダー側)

Page 35: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 35

全貌が分からないままの運営

• 個別個別の投資– 全体ではどうなのか。

• 戦略性をもった投資に見えない– 攻めなのか、守りなのか

– 業界横並びでいいのか

• 全体のモデルがない– 理屈がない、トレードオフが見えない

• 企業戦略と一貫したモデルが必要– 企業戦略とIT戦略の連動性(トレーサビリティ)。

• 意思を持った運営ができない– 判断をするための基盤がない

Page 36: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 36

求められる統一モデルや共通フレーム

• ITの見える化(選択と集中のための判断材料)– 効果、対象、力学

– 全体構造とその中のトレードオフ

– 事業戦略との連動性• どこに重点を置くべきかの指針

• IT投資モデル– NVP– ROI

Page 37: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 37

上流の要求開発の考慮事項

• IT戦略の定義– トータルITの視野(開発だけの話ではない)

– プログラムマネジメント

• IT戦略から、個別戦術へのI/O– 下流の要求開発との接点

• 事業戦略との整合性

• カバーしなければならない項目– 投資計画

– ロードマップ

– 人材ポートフォリオ・調達育成計画

– IT資産構成+ITポートフォリオ

– 適用技術方針

– 技術変化からビジネスへのフィードバック

Page 38: Upstream and downstream in Requirement Development

The solution beyond the solution.MAMEZOU 38

やっぱり方法論が必要なはず

• 策定の体制

• 最終の成果物定義

– IT戦略(何をカバーするか)

• 策定するためのプロセス

• 作成するモデル

– 戦略を立てるに必要なモデル

– 全体構造

– 特定のビュー

Page 39: Upstream and downstream in Requirement Development

39

MAMEZOU The Solution beyond the solution.

[email protected]

 http://www.mamezou.com/ 〒163-0434 新宿区西新宿2-1-1新宿三井ビル34F(私書箱302号) tel: 03-5339-2100 fax: 03-5339-1795