Mais conteúdo relacionado Semelhante a 納涼 和風要求開発小ネタ集 (20) Mais de Kent Ishizawa (20) 納涼 和風要求開発小ネタ集3. IT戦略とプロジェクトの発生
現在のTo-Be IT現在の
事業戦略
As-Is IT
将来のTo-Be IT将来の
事業戦略
現在現在現在現在 XX年後年後年後年後
現実的目標のIT
現行システム
新規追加
機能的改修
時間軸時間軸
プロジェクト
プロジェクト
プロジェクトプロジェクト
プロジェクトプロジェクト
改善
サーバ統合
セキュリティ
強化
維持 保守切れ対応
OS変更
プロジェクトプロジェクト
プロジェクトプロジェクト
プロジェクトプロジェクト
破棄破棄
事業戦略
への対応
現行IT人材
コスト削減
継続性確保
コンプライアン
ス
育成育成
採用採用
パートナ戦略パートナ戦略
必要IT人材
アウトプット
IT中期計画
ITロードマップ
アウトプットアウトプット
IT中期計画
ITロードマップ
例えば3カ年計画
各各各各プロジェクトプロジェクトプロジェクトプロジェクトがががが上位目的上位目的上位目的上位目的にににに基基基基づいてづいてづいてづいて企画企画企画企画されているかされているかされているかされているか
上流上流上流上流のののの要求開発要求開発要求開発要求開発((((プログラムマネジメントプログラムマネジメントプログラムマネジメントプログラムマネジメント視点視点視点視点))))とととと下流下流下流下流のののの要求開発要求開発要求開発要求開発((((プロジェクトプロジェクトプロジェクトプロジェクト視点視点視点視点))))
7. 企画にエンジニアリングを導入する
外 注業者購買担 当者設計担当者営業担当者顧客
見 積依頼書を作 成
する
見積依頼
の送付
見積依頼
の 受領
見積依頼の確認
引合案件の 登録
社内見積依頼の
作成
設 計する
見積 条件を検討す
る
外 注業者の選定を
する
見積依頼書を作成
する
見積依頼
の 送付
見積依 頼
を受 領す
る
見積を実施する
見積書の
送付
見積書を
受領
見積内容を評価し
て 候補を絞り込む
見積 計算を行う
見積書を作成する
見積書の
送付
見積書の
受領
見積回答の 評価
受注フロ ーへ
購 入中止
の連絡
購入中止
の 連絡を
受け る
失注の登録を行う
[新規引合の 場合]
[再見積の 場合]
[外注委託加工が 必要な場合]
[再 見積依頼]
[発注]
[購入中止]
要求は、業務をもとに能動的かつロジカルに開発しなければならない
個々の要求が生まれた
背景に立ち戻る
個々の要求が生まれた
背景に立ち戻る
多くの関係者の視点
を集めた全体構造を
見える化
多くの関係者の視点
を集めた全体構造を
見える化
エンジニアリングを
導入してロジカルに
システムを企画する
•開発プロセス
•モデリング
•ファシリテーション
共通の地図をもって、
具体的に課題箇所を
指さして議論
共通の地図をもって、
具体的に課題箇所を
指さして議論
上位目的との整合性
を確保
上位目的との整合性
を確保 課題の解決をモデル上
で検証
課題の解決をモデル上
で検証
業務に組み込まれ、課題を
解決するシステムへ
業務に組み込まれ、課題を
解決するシステムへ
7
9. 結果につながらないIT投資
• 投資の目的は、ビジネス的な目標の達成
– システム導入は手段にすぎない
– システム開発のQCD(品質、コスト、納期)が目標ではない
• How(いかに作るか)ではなく、What(何を作るか)が先決
– 上位目的を見失ったプロジェクト
– ビジネス目標に整合しないシステム
ビジネスゴールビジネスゴール 業務業務 システムシステム
どんなシステムを作れば
事業目的にかなうのか
正しいシステム要求がなければ、間違ったものを正しく作ってしまう
資本回転率
を上げたい
配送を早め
たい
在庫一覧が
見たい
9
12. モデル中心に
見える化とトレーサビリティ確保
準備 立案 デザイン シフト
udududud ユースケースモデルユースケースモデルユースケースモデルユースケースモデル
サ
ー
ビ
ス
A
サ
ー
ビ
ス
C
サ
ー
ビ
ス
B
cd Ecd Ecd Ecd E コマ ースコマ ースコマ ースコマ ース 事業事業事業事業
顧客顧客顧客顧客
- 氏名:
- 住所:
- 電話番号:
会員会員会員会員
- ID:
- パスワード:
- 有効期間:
+ 認証する()
注文注文注文注文
- 注文年月日:
仕入 先仕入 先仕入 先仕入 先
- 名称:
商品商品商品商品 タ イトルタ イトルタ イトルタ イトル
- 名称:
非会 員顧客非会 員顧客非会 員顧客非会 員顧客
仕入先仕入先仕入先仕入先 ・・・・ 商品商品商品商品 タ イタ イタ イタ イ
トルトルトルトル 関係関係関係関係
- 販売期間:
- 販売単価:
購入商 品購入商 品購入商 品購入商 品 タイトルタイトルタイトルタイトル
- 注文時販売単価:
- 注文量:
- 消費税:
- 販売金額:
- 送料:
注 文注 文注 文注 文 ルールルールルールルール
決済方法決済方法決済方法決済方法
+ 認証する()
決 済方法決 済方法決 済方法決 済方法 ==== 現金現金現金現金 決済 方法決済 方法決済 方法決済 方法 ==== カードカードカードカード
カードカードカードカード 会社会社会社会社
+ 認証する()
値引値引値引値引 きききき ルールルールルールルール送 料計算送 料計算送 料計算送 料計算 ルールルールルールルール
ポイントポイントポイントポイント
- 現ポイント数:
+ 金額換算()
ポ イントポ イントポ イントポ イント 加算加算加算加算
- ポイント加算年月日:
- 加算ポイント:
決済方法決済方法決済方法決済方法 ---- 個別個別個別個別
- 金額:
+ 認証する()
決済方法決済方法決済方法決済方法 ---- ポイントポイントポイントポイント 利利利利
用用用用
- ポイント利用年月日:
- 利用ポイント数:
+ 金額換算()
注文注文注文注文 ルールルールルールルール 型型型型
商品分類商品分類商品分類商品分類
- 名称:
1
*
1
*
1
1
*
1
*
1
1
0..1
1
*
注文ルール型
*
1
注文ルール型
*1
1
*
1
*
1
1
*
1
1
<<powertype>>
*
*
*
*
*
利益向上
(企業価値
向上)
売上増
(付加価値向上)
信用度
維持・向上
コスト減
(ロスセーブ)
職務経歴の
迅速な提供
情報共有
・活用
案件件数を
増やす
値上げ
提供価格
(単価)をあげる
生産性向上
営業力強化
リピートを増やす
タイムリーな
提案
差別化
付加価値増
既存事業の
売上拡大
新規事業の
立上げ
チャンスロス
(機会損失)
アサイン状況
のタイムリーな
把握
労働力の
ロス
(稼働率)
プロジェクトの
円滑な運営
事務処理コスト
に伴うロス
(契約にかかるコスト)
新規を増やす
営業マンを
増やす営業の
事務処理
負荷軽減
適切な
予実管理 売上・経費
タイムリーで
高精度な把握
入力の分散
(発生元での
入力)
社内振替の
管理
事業部、チーム
毎に異なる
ビューが必要
稼働率を上げる
良質案件
実績
人数
(要員数)
積極的採用
離職率を
減らす
モチベーション
アップ適正な評価個人売上の
リアルタイムな
把握
個人別スキル
情報の把握
入力作業の
簡素化操作性向上レスポンス
回線障害の回避
二重入力の排除
適切な営業
活動
案件の適切な
優先順位つけ見落とし案件
の撲滅ToDo作業の
把握
ステータス一覧
金額
契約期間、
時期
システムによる
案件情報の
提供
営業会議での
情報共有
発生元での
直接入力
(事業部、福数人で)
二重入力の
削減
(間違いの防止)
データ連携
予算と実績の
同一粒度での
対比
事業部単位での
予実管理
事業の円滑
な運営
社会的
信用度の向上
内部統制の
確立
適正な
情報開示
リスクポイントの把握
コントロール
手作業の自動化
早期の決算報告連結決算
の自動化コスト・売上
予測の正確な
リアルタイムの把握
利益の
維持
収支管理表
適正な運用プロジェクト情報
(経費・工数・アサイン)
のタイムリーな入力
予算
実績
契約管理
精度ある
売上予測
厳正な評価
適正な
アサインメント
(スキル・思考)
メンバーの
マネジメント
適正な
労務管理
勤怠の承認
精度ある
稼動予実一覧
(アサイン表)
豆蔵の
決算早期化
社内情報
案件情報
の共有
原価計算方式
の見直しと
自動化入力の分散
(経費・勤怠)
経理部の
チェック作業
負荷の削減提出期限の
厳守
プロジェクトゴール記述書
何をする
ことで
何が
いつ
までに
どう
なるのか
評価
尺度
目標値
プロジェクト定義プロジェクト定義
ステークホルダーリストステークホルダーリスト
要求分析ツリー要求分析ツリー
UC01: 商品情報 を管理す る
商品係
UC04: 販売 情報を登録 する
レジ係
UC02: 値札を作成す る
UC03: 売上を集計す る
販 売管理 係
レシート・プリンタ
レシート印刷(販売 : 販売, 店舗 : 店舗)
キャッシュ・レジスタ・パネル
新規入力指示()
入力準備完了通知()
バーコード読取成功通知()
販売数入力()
小計表示()
精算指示()
合計表示()
預かり金入力(金額)
おつり表示()
販売登録完了通知()
バーコード・リーダ
活性化()
不活性化()
販売明細
販売単価
販売数 = 1
販売数設定(販売数)
メーカ台帳
店舗
名前
電話番号
住所
商品検索(商品コード) : 商品
販売履歴追加(新規販売 : 販売)
1
1
1
1
販売台帳
販売履歴追加(新規販売 : 販売)1
1
1
1
キャッシュ・レジスタ
新規入力指示()
販売登録初期化()
バーコード読取(バーコード)
バーコード解析(バーコード)
販売数入力()
精算指示()
預かり金入力(金額)
販売登録後処理()
1
1
レシート・プリンタ
1
1
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.セキュリティ要件
・
・
・
ゴール記述ゴール記述
ビジネスユースケースビジネスユースケース
概念モデル概念モデル
業務フロー業務フロー
ビジネスルールビジネスルール
udududud ユースケースモデルユースケースモデルユースケースモデルユースケースモデル
サ
ー
ビ
ス
A
サ
ー
ビ
ス
C
サ
ー
ビ
ス
B
cd Ecd Ecd Ecd E コマ ースコマ ースコマ ースコマ ース 事業事業事業事業
顧客顧客顧客顧客
- 氏名:
- 住所:
- 電話番号:
会員会員会員会員
- ID:
- パスワード:
- 有効期間:
+ 認証する()
注文注文注文注文
- 注文年月日:
仕入 先仕入 先仕入 先仕入 先
- 名称:
商品商品商品商品 タ イトルタ イトルタ イトルタ イトル
- 名称:
非会 員顧客非会 員顧客非会 員顧客非会 員顧客
仕入先仕入先仕入先仕入先 ・・・・ 商品商品商品商品 タイタイタイタイ
トルトルトルトル 関係関係関係関係
- 販売期間:
- 販売単価:
購入商 品購入商 品購入商 品購入商 品 タイトルタイトルタイトルタイトル
- 注文時販売単価:
- 注文量:
- 消費税:
- 販売金額:
- 送料:
注 文注 文注 文注 文 ルールルールルールルール
決済方法決済方法決済方法決済方法
+ 認証する()
決 済方法決 済方法決 済方法決 済方法 ==== 現金現金現金現金 決済 方法決済 方法決済 方法決済 方法 ==== カードカードカードカード
カードカードカードカード 会社会社会社会社
+ 認証する()
値引値引値引値引 きききき ルールルールルールルール送 料計算送 料計算送 料計算送 料計算 ルールルールルールルール
ポイントポイントポイントポイント
- 現ポイント数:
+ 金額換算()
ポ イントポ イントポ イントポ イント 加算加算加算加算
- ポイント加算年月日:
- 加算ポイント:
決済方法決済方法決済方法決済方法 ---- 個別個別個別個別
- 金額:
+ 認証する()
決済方法決済方法決済方法決済方法 ---- ポ イントポ イントポ イントポ イント 利利利利
用用用用
- ポイント利用年月日:
- 利用ポイント数:
+ 金額換算()
注文注文注文注文 ルールルールルールルール 型型型型
商品分類商品分類商品分類商品分類
- 名称:
1
*
1
*
1
1
*
1
*
1
1
0..1
1
*
注文ルール型
*
1
注文ルール型
*1
1
*
1
*
1
1
*
1
1
<<powertype>>
*
*
*
*
*
ビジネスユースケースビジネスユースケース
概念モデル概念モデル
業務フロー業務フロー
ビジネスルールビジネスルール
システムユースケースシステムユースケース
非機能要件非機能要件
課題解
決
課題解
決
データモデルデータモデル
RFP/システム化計画RFP/システム化計画課題解
決
課題解
決
トレーサビリティを維持しつつ必要な観点を網羅トレーサビリティを維持しつつ必要な観点を網羅
12
14. 小ネタ① 要求開発における主要モデル
• 準備フェーズで早期にイニシャルの要求モデルを確立する
– 要求モデルはだんだん鮮明になっていく
• 立案フェーズで業務を上位のシステムととらえてモデル化する。デザインフェーズ
で改善・最適化する。
– サービスモデル、静的モデル、動的モデル、ルールモデル
– 情報システムとほぼ同じモデルで表現する
• シフトフェーズ以降で、サブシステムである情報システムをモデル化する
– サービスモデル、静的モデル、動的モデル、ルールモデル
意識的に要求モデルをもってプロジェクトに臨むことが重要
要求要求要求要求モデルモデルモデルモデル要求要求要求要求モデルモデルモデルモデル
サービスサービスサービスサービス
モデルモデルモデルモデル
サービスサービスサービスサービス
モデルモデルモデルモデル
静的静的静的静的モデルモデルモデルモデル静的静的静的静的モデルモデルモデルモデル 動的動的動的動的モデルモデルモデルモデル動的動的動的動的モデルモデルモデルモデル
ルールルールルールルール
モデルモデルモデルモデル
ルールルールルールルール
モデルモデルモデルモデル
17. 小ネタ② IT分野外での要求開発適用例
• ピークワン社(広告代理店)の要求開発トレーニング
– 年度スタートのキックオフミーティング 1日合宿
– 要求開発の講義 40分
– 要求分析ツリー作成 60分 1チーム3、4名 3チーム UML
ツール利用
– あとで各チーム発表
• 問題意識(ヒアリングに問題あり)
– 顧客の真のニーズを獲得できていない
– 本質をとらえた提案ができていない。
– 顧客の言った通り以上の提案にならず、他社と差別化できない
– ヒアリングで聞ききれていない。突っ込んだ話やイメージ共有
ができていない。
IT分野以外で要求開発やってみました
19. 3つのニーズ(狩野モデル)
• 基本ニーズ(当たり前の品質)
– これが満たされないとクライアントはとても不満をもつ。
– 満たされても何も感じない。
– 直接不満を言わなくても、次には選ばれない。不満は他のクライアン
トに伝わる。
• 期待のニーズ(一元的品質)
– クライアントが明示的に求めている。
– クライアントから直接、満足か不満かを聞ける。
– 差別化にはならない。話題にはならない。
• 喜びのニーズ(魅力的品質)
– クライアントの気づいていなかったことを提供する。
– 満たされなくても不満にはならない。
– 差別化になる。必ず次がくる。頼られる。他のクライアントに伝わる。
狩野モデル: 東京理科大学の狩野紀昭教授によって 1980 年代
に開発されました顧客の好みを理解するために使用するモデル
言うまでもなく当たり前
言ったことをやってくれる
サプライズがある
20. マーケティング要求事例
• 制作物(パンフレット、Webなど)編
– 製品説明が多過ぎて読んでもらえない
– 表紙はすっきりしたデザインにしたい
– ソーシャルデザインを踏襲したWebにしたい
– 売りに繋がるWebにしたい
– ひと言でサービスを表現したい
– 米国本社に合わせたトーン&マナーにしたい
– 多数ある事例を一元化したい
– 多数の製品群を上手く見せる方法がほしい
– エグゼクティブ向けのノベルティを作りたい
– 販売パートナー用総合カタログを作りたい
– 翻訳ベースの製品カタログを変えたい
– 事例に顧客社名を出せない
– 15分で読める営業ツールがほしい
24. 小ネタ③ 再構築での要求開発とサービス指向
• 個別システムが連携して複雑な生態系を成すに至る
• 個々のシステムだけを考えるのはもはや不可能。
• 必要に迫られて場当たり的に改修や追加、つなぎこみをして、
温泉旅館状態になっている。エンタープライズとしてのアーキ
テクチャが不在
• 更地にして再構築したいが、規模、スコープ、リスク、コストが
大きすぎて現実的でない
• 現状をベースに徐々に持続可能な構造に移行する
• 業務の変化、システムの変化を別のレイヤーで吸収する
• 業務に極力影響を与えない
間欠的間欠的間欠的間欠的ビッグバンビッグバンビッグバンビッグバンからからからから継続的継続的継続的継続的リフォームリフォームリフォームリフォームへへへへ
28. 駅再開発と情報システム再構築の対比
観点観点観点観点 駅再開発駅再開発駅再開発駅再開発 情報情報情報情報システムシステムシステムシステム再構築再構築再構築再構築
コンセプトの変化
電車に乗り降りする施設 →
高集積の経済・生活空間
事務処理の補助装置 →
業務のサイバー化(人とCPUで業務
をサイボーグ化)
構造
経済活動・生活の機能(交通、商
業、ビジネス、宿泊、コミュニティ、
やすらぎ)の複合空間
異なる特性の機能ブロック(人、設備、
ITなど)からなる複合システム
課題の例
交通混雑解消、人の回遊性向上、
効率的ビジネス空間創出、高密
度な経済活動の場の提供、老朽
化への対応
業務のさらなる効率化、ビジネス環境
変化への対応、コスト削減、老朽化へ
の対応、新技術導入によるメリット享
受
制約事項
機能を維持しながら、既存設備を
活かしつつ、高度な環境を目指し
て移行する。老朽部分を速やかに
置き換え
片時もサービスレベルを下げず、老朽
化に対処しつつ、ビジネス環境に適応
させる。常に業務パフォーマンス向上
を目指す
アプローチ
複数のプロジェクトで継続的に改
善を図る。機能を維持するための
工法は様々。
複数のプロジェクトで継続的に改善を
図り続ける。疎結合の上位レイヤーを
維持しながら、構成要素を置き換える
など
31. • 徐々にあるべき姿に近づける
– 一気にやらず、優先順位に基づいて部分的に進める
• 既存のものを活かす
– 利用価値の高い既存部分、はずせないものは残す。部分的に移せるところは移
す。
• 平準的投資と短期のリターンをこまめに稼ぐ
– 大型投資と長期の資産償却、ひたすら陳腐化のパターンに陥らない
• 業務の改革と同期化してシステムの標準化・効率化を進める
– 業務改革ができた部分に合わせてシステム化を進める
• 新築ではなく、常に平均“築3年”を目指す
– 少しずつ手を入れて毎年築3年
– 頻繁に変わるところによく手を入れる
• 新しい技術を積極的に取り入れる
– クラウドの部分的組込み。技術進化を享受する。
• 変化を常態ととらえる
– 移行が一過性の作業ではなく、日常の作業として、いかにインパクトなく行うかを
仕組みとして取り入れる
– 常に足場が設置されている状態を作る
“継続的継続的継続的継続的リフォームリフォームリフォームリフォーム”のののの発想発想発想発想
31
35. アジャイル開発で期待される効用
• ユーザーニーズの的確な把握、実現
– 顧客(要求元)と一体化したチーム
– 短いサイクルでの確認、フィードバック
– ドキュメントではなく動作するプログラムでの評価
• ビジネス変化への対応
– 予測不可能なビジネス環境の変化を短期サイクルで軌道修正して、プロ
ジェクトに組み入れる
• こまめな計画調整
– 重要機能、リスクの高い機能から優先順位に従い開発
– 仕様の欠陥、技術的課題の早期解決
– 現実的な着地点の見極め、業務との適宜調整
• 開発チームの生産性向上
– ドキュメントや非効率な作業を低減し、開発作業に集中
– 見える化やリズムをもった開発サイクルで、開発者のモティベーションを
高め、パフォーマンスを長期に継続維持。
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED. 35
要求開発と
意図が同じ
36. 企業内でのアジャイル開発導入のハードル
• 体制・組織
– オンサイト顧客不在
– 小規模開発チーム、集結した開発拠点
– ガバナンスの確保が困難。抜け道になる
• 契約・商習慣
– 最終的な実現機能を事前にコミットできない
– 責任の所在が明確にならない
• スキルセット
– 多能エンジニアの養成、確保
– リーダー(例えばスクラムマスター)の養成
– アジャイルを効率化するための環境の構築
• 文化・マインドセット
– 経営層・マネジメント層がアジャイル開発手法への理解が足りない
– ベンダー側がユーザビジネスを理解しない
COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED. 36