納涼 和風要求開発小ネタ集
•
10 recomendaciones•4,079 vistas
オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2013年7月定例会発表資料です。 Open Community "Requirement Development Alliance" 2013/7 regular meeting of the presentation materials.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Similar a 納涼 和風要求開発小ネタ集
Similar a 納涼 和風要求開発小ネタ集 (20)
Más de Kent Ishizawa
Más de Kent Ishizawa (20)
納涼 和風要求開発小ネタ集
- 2. アジェンダ • 「要求開発」と言い出して１０年 • 実際の案件の中で遭遇する「要求開発」のシーン • 要求開発最近の取り口 • 小ネタ集 ① 要求開発における主要モデル ② IT分野外での要求開発適用例 ③ 再構築での要求開発とサービス指向 ④ エンタープライズでの要求開発とアジャイル
- 3. ＩＴ戦略とプロジェクトの発生 現在のTo-Be IT現在の 事業戦略 As-Is IT 将来のTo-Be IT将来の 事業戦略 現在現在現在現在 XX年後年後年後年後 現実的目標のIT 現行システム 新規追加 機能的改修 時間軸時間軸 プロジェクト プロジェクト プロジェクトプロジェクト プロジェクトプロジェクト 改善 サーバ統合 セキュリティ 強化 維持 保守切れ対応 OS変更 プロジェクトプロジェクト プロジェクトプロジェクト プロジェクトプロジェクト 破棄破棄 事業戦略 への対応 現行IT人材 コスト削減 継続性確保 コンプライアン ス 育成育成 採用採用 パートナ戦略パートナ戦略 必要IT人材 アウトプット ＩＴ中期計画 ＩＴロードマップ アウトプットアウトプット ＩＴ中期計画 ＩＴロードマップ 例えば３カ年計画 各各各各プロジェクトプロジェクトプロジェクトプロジェクトがががが上位目的上位目的上位目的上位目的にににに基基基基づいてづいてづいてづいて企画企画企画企画されているかされているかされているかされているか 上流上流上流上流のののの要求開発要求開発要求開発要求開発（（（（プログラムマネジメントプログラムマネジメントプログラムマネジメントプログラムマネジメント視点視点視点視点））））とととと下流下流下流下流のののの要求開発要求開発要求開発要求開発（（（（プロジェクトプロジェクトプロジェクトプロジェクト視点視点視点視点））））
- 5. 業務とＩＴの位置関係 発送する 商品在庫を確 認する 注文を受け付 ける 請求書を送付 する 注文をクローズ する 納品を確認する 支払いを確認 する 商品を発注する 注文を登録す る 入金を調べる 在庫センター在庫センター 営業営業 経理経理 ＩＴシステムＩＴシステム 販売管理システム販売管理システム 入金管理システム入金管理システム 取引顧客取引顧客 「業務」という上 位のシステム ＩＴはサブシ ステム ＩＴシステムの役割は業務の全体設計の中で決まる 5
- 7. 企画にエンジニアリングを導入する 外 注業者購買担 当者設計担当者営業担当者顧客 見 積依頼書を作 成 する 見積依頼 の送付 見積依頼 の 受領 見積依頼の確認 引合案件の 登録 社内見積依頼の 作成 設 計する 見積 条件を検討す る 外 注業者の選定を する 見積依頼書を作成 する 見積依頼 の 送付 見積依 頼 を受 領す る 見積を実施する 見積書の 送付 見積書を 受領 見積内容を評価し て 候補を絞り込む 見積 計算を行う 見積書を作成する 見積書の 送付 見積書の 受領 見積回答の 評価 受注フロ ーへ 購 入中止 の連絡 購入中止 の 連絡を 受け る 失注の登録を行う [新規引合の 場合] [再見積の 場合] [外注委託加工が 必要な場合] [再 見積依頼] [発注] [購入中止] 要求は、業務をもとに能動的かつロジカルに開発しなければならない 個々の要求が生まれた 背景に立ち戻る 個々の要求が生まれた 背景に立ち戻る 多くの関係者の視点 を集めた全体構造を 見える化 多くの関係者の視点 を集めた全体構造を 見える化 エンジニアリングを 導入してロジカルに システムを企画する •開発プロセス •モデリング •ファシリテーション 共通の地図をもって、 具体的に課題箇所を 指さして議論 共通の地図をもって、 具体的に課題箇所を 指さして議論 上位目的との整合性 を確保 上位目的との整合性 を確保 課題の解決をモデル上 で検証 課題の解決をモデル上 で検証 業務に組み込まれ、課題を 解決するシステムへ 業務に組み込まれ、課題を 解決するシステムへ 7
- 9. 結果につながらないIT投資 • 投資の目的は、ビジネス的な目標の達成 – システム導入は手段にすぎない – システム開発のQCD（品質、コスト、納期）が目標ではない • How（いかに作るか）ではなく、What（何を作るか）が先決 – 上位目的を見失ったプロジェクト – ビジネス目標に整合しないシステム ビジネスゴールビジネスゴール 業務業務 システムシステム どんなシステムを作れば 事業目的にかなうのか 正しいシステム要求がなければ、間違ったものを正しく作ってしまう 資本回転率 を上げたい 配送を早め たい 在庫一覧が 見たい 9
- 10. 要求開発手法の構成 要求は在るものではなく開発するものである システム開発と同様の道具立て 実施組織の定義実施組織の定義 コアチーム プロジェクト メンバー 外郭メンバー 経営 業務 システム 開発プロセス開発プロセス 利益向上 （企業価値 向上） 売上増 （付加価値向上） 信用度 維持･向上 コスト減 (ロスセーブ) 職務経歴の 迅速な提供 情報共有 ･活用 案件件数を 増やす 値上げ 提供価格 （単価）をあげる 生産性向上 営業力強化 リピートを増やす タイムリーな 提案 差別化 付加価値増 既存事業の 売上拡大 新規事業の 立上げ チャンスロス （機会損失） アサイン状況 のタイムリーな 把握 労働力の ロス （稼働率） プロジェクトの 円滑な運営 事務処理ｺｽﾄ に伴うロス （契約にかかるコスト） 新規を増やす 営業マンを 増やす営業の 事務処理 負荷軽減 適切な 予実管理 売上･経費 タイムリーで 高精度な把握 入力の分散 （発生元での 入力） 社内振替の 管理 事業部、ﾁｰﾑ 毎に異なる ﾋﾞｭｰが必要 稼働率を上げる 良質案件 実績 人数 （要員数） 積極的採用 離職率を 減らす モチベーション アップ 適正な評価個人売上の リアルタイムな 把握 個人別スキル 情報の把握 入力作業の 簡素化操作性向上レスポンス 回線障害の回避 二重入力の排除 適切な営業 活動 案件の適切な 優先順位つけ見落とし案件 の撲滅ToDo作業の 把握 ｽﾃｰﾀｽ一覧 金額 契約期間、 時期 システムによる 案件情報の 提供 営業会議での 情報共有 発生元での 直接入力 （事業部、福数人で） 二重入力の 削減 （間違いの防止） データ連携 予算と実績の 同一粒度での 対比 事業部単位での 予実管理 事業の円滑 な運営 社会的 信用度の向上 内部統制の 確立 適正な 情報開示 ﾘｽｸﾎﾟｲﾝﾄの把握 コントロール 手作業の自動化 早期の決算報告連結決算 の自動化ｺｽﾄ･売上 予測の正確な リアルタイムの把握 利益の 維持 収支管理表 適正な運用プロジェクト情報 （経費･工数･アサイン） のタイムリーな入力 予算 実績 契約管理 精度ある 売上予測 厳正な評価 適正な アサインメント （スキル･思考） メンバーの マネジメント 適正な 労務管理 勤怠の承認 精度ある 稼動予実一覧 （アサイン表） 豆蔵の 決算早期化 社内情報 案件情報 の共有 原価計算方式 の見直しと 自動化入力の分散 （経費･勤怠） 経理部の チェック作業 負荷の削減提出期限の 厳守 成果物定義成果物定義 手法手法 どのような順序でどん な作業を行うか どのような観点で調査・ 分析・設計・検証を行う か 作成すべきモデ ル・文書など どのような組織 で作業を行うか 10
- 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..* 洗練されたクラス図 分析レベル 非機能要件リスト １．レスポンス a)＿＿＿＿ b)________ ２．セキュリティ要件 ・ ・ ・ ゴール記述ゴール記述 ビジネスユースケースビジネスユースケース 概念モデル概念モデル 業務フロー業務フロー ビジネスルールビジネスルール 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
- 13. 要求開発の効用 13
- 14. 小ネタ① 要求開発における主要モデル • 準備フェーズで早期にイニシャルの要求モデルを確立する – 要求モデルはだんだん鮮明になっていく • 立案フェーズで業務を上位のシステムととらえてモデル化する。デザインフェーズ で改善・最適化する。 – サービスモデル、静的モデル、動的モデル、ルールモデル – 情報システムとほぼ同じモデルで表現する • シフトフェーズ以降で、サブシステムである情報システムをモデル化する – サービスモデル、静的モデル、動的モデル、ルールモデル 意識的に要求モデルをもってプロジェクトに臨むことが重要 要求要求要求要求モデルモデルモデルモデル要求要求要求要求モデルモデルモデルモデル サービスサービスサービスサービス モデルモデルモデルモデル サービスサービスサービスサービス モデルモデルモデルモデル 静的静的静的静的モデルモデルモデルモデル静的静的静的静的モデルモデルモデルモデル 動的動的動的動的モデルモデルモデルモデル動的動的動的動的モデルモデルモデルモデル ルールルールルールルール モデルモデルモデルモデル ルールルールルールルール モデルモデルモデルモデル
- 16. 課題の特定とその解決 • 要求開発でのモデリングの目的は“課題箇所の特定”と“課題解決の確認” • システムとして表現する – サービスモデル • ビジネスユースケース – 静的モデル • 概念モデル – 動的モデル • 業務フロー – ルールモデル • ビジネスルール • 課題は、いずれかのモデルに表現される
- 17. 小ネタ② IT分野外での要求開発適用例 • ピークワン社（広告代理店）の要求開発トレーニング – 年度スタートのキックオフミーティング １日合宿 – 要求開発の講義 ４０分 – 要求分析ツリー作成 ６０分 １チーム３、４名 ３チーム UML ツール利用 – あとで各チーム発表 • 問題意識（ヒアリングに問題あり） – 顧客の真のニーズを獲得できていない – 本質をとらえた提案ができていない。 – 顧客の言った通り以上の提案にならず、他社と差別化できない – ヒアリングで聞ききれていない。突っ込んだ話やイメージ共有 ができていない。 IT分野以外で要求開発やってみました
- 19. ３つのニーズ（狩野モデル） • 基本ニーズ（当たり前の品質） – これが満たされないとクライアントはとても不満をもつ。 – 満たされても何も感じない。 – 直接不満を言わなくても、次には選ばれない。不満は他のクライアン トに伝わる。 • 期待のニーズ（一元的品質） – クライアントが明示的に求めている。 – クライアントから直接、満足か不満かを聞ける。 – 差別化にはならない。話題にはならない。 • 喜びのニーズ（魅力的品質） – クライアントの気づいていなかったことを提供する。 – 満たされなくても不満にはならない。 – 差別化になる。必ず次がくる。頼られる。他のクライアントに伝わる。 狩野モデル： 東京理科大学の狩野紀昭教授によって 1980 年代 に開発されました顧客の好みを理解するために使用するモデル 言うまでもなく当たり前 言ったことをやってくれる サプライズがある
- 20. マーケティング要求事例 • 制作物（パンフレット、Webなど）編 – 製品説明が多過ぎて読んでもらえない – 表紙はすっきりしたデザインにしたい – ソーシャルデザインを踏襲したWebにしたい – 売りに繋がるWebにしたい – ひと言でサービスを表現したい – 米国本社に合わせたトーン＆マナーにしたい – 多数ある事例を一元化したい – 多数の製品群を上手く見せる方法がほしい – エグゼクティブ向けのノベルティを作りたい – 販売パートナー用総合カタログを作りたい – 翻訳ベースの製品カタログを変えたい – 事例に顧客社名を出せない – 15分で読める営業ツールがほしい
- 21. 要求分析ツリーの例
- 22. マーケティングの話にマッピングすると・・・ • クライアントは、答らしきこと（ソリューション）をいうけれども、目的に照らして、本 当に一番よい答えという自信があるわけではない。 • クライアントは、マーケティングに何を期待すべきかわかっていないことが多い。そ もそもの上位目的が定まっていないことも多い。 • クライアントの出してきた要求に対して、言われたことをやるというスタンスでは差 別化はできない • 本当に必要なものが何か、全体構造を把握する手助けをしつつ（プロセスを共有 する）、同じ立場に立って、本質に根差したソリューションをいっしょに検討していく スタンスが必要。 • クライアントは日々の目先のことで視野狭窄になり、匍匐前進状態にある。航空 写真のようなものを作って、どこにいて、どこに向かうべきかをファシリテートする ことが付加価値になる。 • ヒアリングするときは、自分の中に仮説でもモデルを持って臨む。モデルが完成す るようにヒアリングをして、同じモデルが共有できれば共感できるソリューションが 提案できる。手ぶら、白紙でいきなり「どうしましょう」はない。 シナリオと地図をもって、クライアントといっしょにゴールにたどりつくシナリオと地図をもって、クライアントといっしょにゴールにたどりつく
- 23. ワークショップを終えて • 感想・気づき – ヒアリングするときに頭が白紙ではだめで自分なりのモデ ルをもって臨む必要がある – メモでなく、モデルを持ち帰れば、様々な提案ができる – 顧客といっしょにやれば価値観を共有できる – ヒアリングはすでに営業。こちらがちゃんとついてきている ことがわかるとアドバンテージがつく • 振り返り – IT分野でなくても大いに盛り上がるし、難しいところはない。 枠組みがあると考えやすい。 – 目的‐手段の展開には慣れが必要
- 24. 小ネタ③ 再構築での要求開発とサービス指向 • 個別システムが連携して複雑な生態系を成すに至る • 個々のシステムだけを考えるのはもはや不可能。 • 必要に迫られて場当たり的に改修や追加、つなぎこみをして、 温泉旅館状態になっている。エンタープライズとしてのアーキ テクチャが不在 • 更地にして再構築したいが、規模、スコープ、リスク、コストが 大きすぎて現実的でない • 現状をベースに徐々に持続可能な構造に移行する • 業務の変化、システムの変化を別のレイヤーで吸収する • 業務に極力影響を与えない 間欠的間欠的間欠的間欠的ビッグバンビッグバンビッグバンビッグバンからからからから継続的継続的継続的継続的リフォームリフォームリフォームリフォームへへへへ
- 28. 駅再開発と情報システム再構築の対比 観点観点観点観点 駅再開発駅再開発駅再開発駅再開発 情報情報情報情報システムシステムシステムシステム再構築再構築再構築再構築 コンセプトの変化 電車に乗り降りする施設 → 高集積の経済・生活空間 事務処理の補助装置 → 業務のサイバー化（人とＣＰＵで業務 をサイボーグ化） 構造 経済活動・生活の機能（交通、商 業、ビジネス、宿泊、コミュニティ、 やすらぎ）の複合空間 異なる特性の機能ブロック（人、設備、 ＩＴなど）からなる複合システム 課題の例 交通混雑解消、人の回遊性向上、 効率的ビジネス空間創出、高密 度な経済活動の場の提供、老朽 化への対応 業務のさらなる効率化、ビジネス環境 変化への対応、コスト削減、老朽化へ の対応、新技術導入によるメリット享 受 制約事項 機能を維持しながら、既存設備を 活かしつつ、高度な環境を目指し て移行する。老朽部分を速やかに 置き換え 片時もサービスレベルを下げず、老朽 化に対処しつつ、ビジネス環境に適応 させる。常に業務パフォーマンス向上 を目指す アプローチ 複数のプロジェクトで継続的に改 善を図る。機能を維持するための 工法は様々。 複数のプロジェクトで継続的に改善を 図り続ける。疎結合の上位レイヤーを 維持しながら、構成要素を置き換える など
- 30. サービス抽出過程は要求開発プロセスそのもの 発送する 商品在庫を確 認する 注文を受け付 ける 請求書を送付 する 注文をクローズ する 納品を確認する 支払いを確認 する 商品を発注 する 入金を調べ る 在庫セン ター 在庫セン ター 営業営業 経理経理 システムシステム 入金管理システム入金管理システム 取引顧客取引顧客 30 業務業務業務業務のののの変化変化変化変化ををををトレーサビリティトレーサビリティトレーサビリティトレーサビリティをををを以以以以ててててシステムサービスシステムサービスシステムサービスシステムサービスにににに伝伝伝伝えるえるえるえる ビジネス サービス ビジネス サービス 注文を登 録する ・・・・・・・・ ・・・・・・・・ ・・・・・・・・・・・・・・・・ ・・・・ ・・・・・・・・ ・・・・・・・・ ・・・・・・・ ・・・・・・・・ ・ ・・・・・・・・ ・・・・・・・・ ユースケース記述ユースケース記述
- 31. • 徐々にあるべき姿に近づける – 一気にやらず、優先順位に基づいて部分的に進める • 既存のものを活かす – 利用価値の高い既存部分、はずせないものは残す。部分的に移せるところは移 す。 • 平準的投資と短期のリターンをこまめに稼ぐ – 大型投資と長期の資産償却、ひたすら陳腐化のパターンに陥らない • 業務の改革と同期化してシステムの標準化・効率化を進める – 業務改革ができた部分に合わせてシステム化を進める • 新築ではなく、常に平均“築３年”を目指す – 少しずつ手を入れて毎年築３年 – 頻繁に変わるところによく手を入れる • 新しい技術を積極的に取り入れる – クラウドの部分的組込み。技術進化を享受する。 • 変化を常態ととらえる – 移行が一過性の作業ではなく、日常の作業として、いかにインパクトなく行うかを 仕組みとして取り入れる – 常に足場が設置されている状態を作る “継続的継続的継続的継続的リフォームリフォームリフォームリフォーム”のののの発想発想発想発想 31
- 34. 小ネタ④ エンタープライズでの要求開発とアジャイル • エンタープライズ系システムでアジャイルは適用可能な のか • 要求開発はアジャイルプロセスに組み込めるのか
- 35. アジャイル開発で期待される効用 • ユーザーニーズの的確な把握、実現 – 顧客（要求元）と一体化したチーム – 短いサイクルでの確認、フィードバック – ドキュメントではなく動作するプログラムでの評価 • ビジネス変化への対応 – 予測不可能なビジネス環境の変化を短期サイクルで軌道修正して、プロ ジェクトに組み入れる • こまめな計画調整 – 重要機能、リスクの高い機能から優先順位に従い開発 – 仕様の欠陥、技術的課題の早期解決 – 現実的な着地点の見極め、業務との適宜調整 • 開発チームの生産性向上 – ドキュメントや非効率な作業を低減し、開発作業に集中 – 見える化やリズムをもった開発サイクルで、開発者のモティベーションを 高め、パフォーマンスを長期に継続維持。 COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED. 35 要求開発と 意図が同じ
- 36. 企業内でのアジャイル開発導入のハードル • 体制・組織 – オンサイト顧客不在 – 小規模開発チーム、集結した開発拠点 – ガバナンスの確保が困難。抜け道になる • 契約・商習慣 – 最終的な実現機能を事前にコミットできない – 責任の所在が明確にならない • スキルセット – 多能エンジニアの養成、確保 – リーダー（例えばスクラムマスター）の養成 – アジャイルを効率化するための環境の構築 • 文化・マインドセット – 経営層・マネジメント層がアジャイル開発手法への理解が足りない – ベンダー側がユーザビジネスを理解しない COPYRIGHT (C) MethodoLogic,Inc. ALL RIGHTS RESERVED. 36
- 37. エンタープライズでのアジャイルのあり方 • 一般にエンタープライズ系システム（主に基幹系）は – イテレーションに入る前に腰を落ち着けた要求開発（RD0)、 アーキテクチャ設計（他システムとの連携など含む）、モデリン グが必要 – イテレーションと別に移行計画、ユーザ教育などが必要 • すべての開発へのアジャイル適用は無理 – 適応重視と計画重視のトレードオフ。システム／プロジェクトの 特性で適合度が変わる。 – ウォーターフォールが合わない開発シーンは増えてきている – 特殊部隊の組成から 適応的開発 計画重視適応的開発 計画重視 ウォーターフォールウォーターフォールウォーターフォールウォーターフォール型型型型ウォーターフォールウォーターフォールウォーターフォールウォーターフォール型型型型反復型反復型反復型反復型反復型反復型反復型反復型アジャイルアジャイルアジャイルアジャイルアジャイルアジャイルアジャイルアジャイル
- 39. アジェンダ • 「要求開発」と言い出して１０年 • 実際の案件の中で遭遇する「要求開発」のシーン • 要求開発最近の取り口 • 小ネタ集 ① 要求開発における主要モデル ② IT分野外での要求開発適用例 ③ 再構築での要求開発とサービス指向 ④ エンタープライズでの要求開発とアジャイル