Recommandé
Contenu connexe
En vedette
Similaire à ビジネスまで最短距離のモデリング
Similaire à ビジネスまで最短距離のモデリング (20)
ビジネスまで最短距離のモデリング
- 2. 今日お話したいこと • いま、俊敏な開発（アジャイルな開発）が求められています • しかし、一定規模以上のシステム開発において、俊敏性だけをやみくもに追及することに賛成する 人はあまりいないようです • 多くの人が長い間親しんできたウォータフォール型の開発プロセスは、規模と言う観点からは安定 感があるものの、俊敏性の観点から評判が悪く、敬遠されているようです • では、システム開発に俊敏性を求める時、ウォータフォール型の開発プロセスから私たちが学ぶも のは何もないのでしょうか • そもそも、俊敏な開発（アジャイルな開発）とウォータフォール型の開発プロセスは、対立関係にあ るのでしょうか • 今日は、この疑問を切り口にして、「準備段階でのモデリング」を重視した顧客フィードバック指向 の開発スタイルについて一緒に考えてみたいと思います 2Copyright 2016 Synergy Research Corporation, All rights reserved.
- 3. ウォータフォール VS. アジャイル？ • それぞれの至高のメッセージは何か？ ウォータフォール アジャイル開発 3 対立？ Copyright 2016 Synergy Research Corporation, All rights reserved.
- 4. 開発手法の4象限 4 システム規模 大 小 顧客(市場・ユーザー）からの 迅速なフィードバックが重要 YES ？ アジャイル開発 NO ウォータフォール なんでもOK さがすべきは ここの解 Copyright 2016 Synergy Research Corporation, All rights reserved.
- 7. プラント建設の工程 7 IPA: FEL(Front-End Loading) ・物質収支 ・プレリミナリ機器設計 ・調達用主要機器仕様 ・エネルギー収支 ・プレリミナリレイアウト設計 ・確定見積 ・プロジェクト憲章 ・プレリミナリスケジュール ・プロジェクト実行計画 ・プレリミナリ見積 ・プレリミナリ 3-Dモデル ・電気計装機器リスト ・配管リスト （５） 機器資材調達 （６） 工事 設備・材料発注／製作／検査／現地搬送 (PURCASE ORDER/MANUFACTURING/INSPECTION/TRANSPORTATION) 現地工事・試運転 (CONSTRUCTION/PRE-COMMISSIONING) 設 計 E (ENGINEERING) 調 達 P (PROCUREMENT) 工 事 C (CONSTRUCTION) 基本計画・概念設計 (BASIC PLANNING/CONCEPTUAL DESIGN) 基本設計 (BASIC DESIGN) 詳細設計 (DETAIL DESIGN) 工事設計・施工設計 (CONSTRUCTION DESIGN) 「WIKIPEDIA」の表から翻訳 (1) プロセス計画設計 （プロセスフローシート） （２） プロセス基本設計 （３） プラントレイアウト （４） 詳細設計 FEL-3FEL-2FEL-1 ソフト契約とEPC契約の境界 調達に絡む設計 供給業者（Supplier)との情報の授受 工事に絡む設計 現地工事側との情報の授受 Copyright 2016 Synergy Research Corporation, All rights reserved.
- 8. FEL （フロントエンドローディング） • IPA: Independent Project Analysis社、メガプロジェクトを対象としたプロジェクト評価と ベンチマーキングの世界的企業 • メガプロジェクト： 10億ドルクラスの、石油、化学、医薬、鉱物プラント等のプロジェクト • IPA-FEL (Front-End Loading) ： もっともコストのかかる工程である調達・工事の開始 前に、情報の世界だけで、設計と調達・工事計画等を精密かつ整合的に行い、トータル コストを下げる考え方。 • FELのレベルに応じて、FEL１、FEL2 、 FEL3と3段階があり、それぞれの終了条件を満た した場合にのみ通過できるFEL GATEをもち、個別プロジェクトに対して終了条件の判定 結果としてFEL RATINGを与える。 • IPAは、FEL RATINGが良好な場合にのみ、次ステップに進むことをオーナーに強く進めて いる。 FEL RATINGとプロジェクトの最終結果に関するデータベースを持っているため、非 常に説得力がある。 • 契約の収支のみを気にする建設・エンジニアリング会社の視点ではなく、投資計画を成 功させなければならないオーナーの視点を提供している。「継続、中止、やり直し」を視野 に入れている。 8Copyright 2016 Synergy Research Corporation, All rights reserved.
- 9. FEL (Front-End Loading) 9 アイデア ジェネレーション/ 構想づくり 機会の定義 スコープ開発 プロジェクト定義 実行 生産 Gate 1 Gate 2 Gate 3 FEL‐1FEL‐1 FEL‐2FEL‐2 FEL‐3FEL‐3 ビジネスケースは 強固か スコープは 完全か？ 実行開始 できるか？ Insustrial megaprojects, Concepts,Strategies, and Practices for Success, Wiley, 2011 より、翻訳、加筆、転載 基本計画・概念設計 基本設計 詳細設計 設備・材料発注 /製作/検査/ 現地搬送 現地工事 試運転 工事設計 施工設計 関係組織、関係者が 一気に広がる直前。 従来の詳細設計を 分断。 経済的合理性！！ Copyright 2016 Synergy Research Corporation, All rights reserved.
- 11. アジャイル開発との対比 • XPの場合 • 変更コストはプロジェクトの進行とともに上昇する と考えられてきたが、一定の条件が満たされる場 合、変更コストはフラットに近いものになる。 • この時に、従来のソフトウェア開発の常識が大きく 変わる。 • 価値ある要求をいつでも取り込むことができて、 無駄のないソフトウェア開発が可能となる。 • 一定の条件とは、適切な技術とプログラミング・プ ラクティスの組合せ • 適切な技術の代表 • オブジェクト指向プログラミング 11 Extreme Programming Explained, EMBRACE CHANGE Kent Beck, Addison Wesley, 2000より FIGURE3. The cost of change may not rise dramatically over time 変化を抱擁せよ！ （変化を積極的に受け入れなさい） COST OF CHANGE REQUIRMENTS ANALYSIS DESIGN IMPLEMENTATION TESTING PRODUCTION 変更コスト COST OF CHANGE TIME 変更コスト Copyright 2016 Synergy Research Corporation, All rights reserved.
- 14. もっと準備のことを語ろう！ • 準備のことを語るのは恥ずかしくない • 準備こそ、語り、継承されるべき • 「実装を急ぐことが経済性に優れている、キャッシュフロー上好ましい」という議論 は誤り • コストが大きければ負のキャッシュフローが生まれる 14Copyright 2016 Synergy Research Corporation, All rights reserved.
- 15. 「準備」の例 • エンタープライズアジャイル手法における「準備」 • RUP • DAD • SAFe • 政府IT調達における「準備」 15 DAD （Disciplined Agile Delivery）： ディシプリンド・アジャイル・デリバリー SAFe （Scaled Agile Framework） RUP （Rational Unified Process） UP （Unified Process） ユニファイドプロセス Copyright 2016 Synergy Research Corporation, All rights reserved.
- 16. RUP・UP （統一プロセス） 16 サイクル １ サイクル ２ サイクル ３ サイクル ４ システムのライフサイクル 誕生 終了 リリース リリース リリース 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 方向付け Inception 推敲 Elaboration 構築 Construction 移行 Migration 要求 分析 設計 実装 テスト フェーズ イテレーション 作業分野 (Discipline) Copyright 2016 Synergy Research Corporation, All rights reserved. 要求分析 アーキテクチャー ベースライン設計
- 17. ディシプリンド・アジャイル・デリバリー • ー＞ディシプリンド・アジャイル ２．X • Scott W.Ambler/Mark Lines Copyright 2016 Synergy Research Corporation, All rights reserved. 17 方向付け 構築 移行 推敲を消したのは、固定的に考 えてほしくないから。 コンテキストに合わせてプロセス モデルを選択してほしい。
- 18. Scaled Agile Framework （SAFe） 18Copyright 2016 Synergy Research Corporation, All rights reserved. 大きなテーマを扱うところ。 アーキテクチャーをどこま で継続的、連続的に扱う ことができるか。 準備的な期間はどう取り 扱うのか？ エピックは複数リ リースにわたる アーキテクチャー は継続的に発展 する
- 19. 政府IT調達における「準備」 19 結合・ 総合テスト Ｓ調達仕様書 作成 調達単位 決定 調達仕様書 作成 受入テ スト 最適化 計画策定 仕様書作成 (要件定義書) 工程管理 基本的事項の整理 ・システム方式の具体化 要件の精査 ・システム化要件の精査 ・運用・保守要件の精査 共通基盤 単体テスト 結合・ 総合テスト 運用・保守設計 共通基盤 設計・開発 HW/SW 設定・設置 HW/SW 保守 受入テ スト 運用 受入テ スト 保守 調達担当課室 最適化計画策定支援事業者 工程管理支援事業者 共通基盤事業者 個別機能 設計・開発 運用・保守 設計 個別機能 単体テスト 結合・ 総合テスト 個別機能事業者(複数) ハードウェア等納入業者 運用事業者 保守事業者 調 達 調 達 調 達 調 達 調 達 調 達 図3-14 保守分離調達の手順 総務省行政管理局、 「情報システムに係る政府調達の基本指針 実務手引き書、2007、より 一部改変 政府ガイドラインにおける調達手順 Copyright 2016 Synergy Research Corporation, All rights reserved. 要求分析 アーキテクチャー ベースライン設計
- 20. 何を準備するのか • 準備（上流で行うべきこと）の定番は要件定義であった • 顧客フィードバック指向により、要件（WHAT）は最重要な準備項目ではなくなった • 仕様書にサインして仕様凍結する時代は終わった • 要件のフィクスを待っていたら仕事がなくなる • 開発そのものが変更管理 • 開発環境の変化 • ITインフラ、開発・運用プラットフォームの進化と普及により、要件と並行（あるいは先行）して、 「アプリに適したやり方（HOW）」を考える時代へ • クラウドネイティブな開発やPaaSへの期待 • 「準備」の中心はWHATからHOWに移り始めている • プロセス論議において天動説ー＞地動説くらいのインパクト • 政府調達プロセスにおいては、WHATよりもHOWを先行させることはベンダーロックインを招く ため禁止されている！ • OSSがベンダー中立性の問題をクリア 20Copyright 2016 Synergy Research Corporation, All rights reserved.
- 21. HOWの準備 ≒ （広い意味の）プラットフォーム選定・構築 • プラットフォーム製品・PaaS・各種クラウドサービスなど（狭い意味のプラットフォーム） • アーキテクチャーベースライン設計 • 各種設定、オプション選択 • モデリングツール • UML • EXCELL • （開発のための）DB • 要求定義言語 • 要求（メタ）モデル • モデリングツールもこれの一つ • ASTAHを選択した＝UMLというメタモデルを選択した • UMLはドメイン化することもできる（例：ステレオタイプ） • 要求・実装変換手順 • 初期要求モデル（機能、非機能） • 創意と信頼の土壌 21Copyright 2016 Synergy Research Corporation, All rights reserved.
- 23. 機能とシステム要素との関係を洗い出す Copyright 2016 Synergy Research Corporation, All rights reserved. 23 入力チェック 表示モード 切換 親画面へ 情報反映 帳票印刷 別機能呼出 File Upload File Download メール送信 照会系 更新系 DB相関 チェック 帳票作成 クライゼル SRSPlus SBI SQL ｽﾄｱﾄﾞ クライゼル FML TKC CA 各種 金融期間 明治安田 レジストリ 取引先 担当者 デヂエ 社内 担当者 1 共通 90：共通 ○ D共通00-01 ログイン 2 共通 90：共通 ○ D共通00-02 メインメニュー 3 見積 01：見積 ○ D契約01-01 見積一覧画面 3 見積 01：見積 ○ D契約01-01 見積一覧画面 3 見積 01：見積 ○ D契約01-01 見積一覧画面 4 見積 01：見積 D契約01-01 5 見積 01：見積 ○ D契約01-03 見積管理画面 5 見積 01：見積 ○ D契約01-03 見積管理画面 5 見積 01：見積 ○ D契約01-03 見積管理画面 6 見積 01：見積 D契約01-03 7 見積 01：見積 D契約01-03 7 見積 01：見積 D契約01-03 8 見積 01：見積 ○ D契約01-05 見積受注変換画面 8 見積 01：見積 ○ D契約01-05 見積受注変換画面 9 見積 01：見積 ○ D契約01-06 見積書面編集画面 9 見積 01：見積 ○ D契約01-06 見積書面編集画面 9 見積 01：見積 ○ D契約01-06 見積書面編集画面 10 見積 01：見積 ○ R契約01-01 見積書・注文書PDF出力 10 見積 01：見積 ○ R契約01-01 見積書・注文書PDF出力 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ ○ 11 契約 03：契約 ○ D契約02-01 契約一覧画面 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ ○ ○ 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ ○ 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ ○ 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ ○ 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ ○ 11 契約 03：契約 ○ D契約02-01 契約一覧画面 ○ ○ ○ 12 契約 03：契約 D契約02-01 ○ ○ ○ ○ ○ ○ 13 契約 03：契約 D契約02-01 ○ ○ ○ ○ ○ ○ 13 契約 03：契約 D契約02-01 ○ ○ ○ ○ ○ 14 契約 03：契約 D契約02-01 ○ ○ ○ ○ 14 契約 03：契約 D契約02-01 ○ ○ ○ ○ 15 契約 03：契約 D契約02-01 ○ ○ 15 契約 03：契約 D契約02-01 ○ 15 契約 03：契約 D契約02-01 ○ 16 契約 03：契約 D契約02-01 ○ 機 能 I D バッ チ 区 分 機能一覧 帳 票 バッ チ N o カ テ ゴ リ メニューカテゴリ 汎 用 ツー ル 画 面 C S V メール送信先Client機能名称 外部システム（手動ファイル連携） システム化対象外Data Access LayerBusiness Layer External Access WebService Domain DbAccess Presentation Layer
- 24. 要求・実装変換手順 • 手順書 • 顧客価値要素と実装価値要素の見極め • 実装価値要素＝顧客価値要素の物理的着地点 • 顧客価値要素から実装価値要素までの変換過程（工程） • 例：ORマッピング • 自動生成 • かつてモデル駆動アーキテクチャ（MDA)が目指したが、 • 自動生成はMUSTではない • リバースエンジニアリング • 常に意識されているべき • しっかりやればオフショアも低リスク 24Copyright 2016 Synergy Research Corporation, All rights reserved.
- 25. HOWを要件定義からさらに上流化するメリット • 開発プロセスにおける仕様の不連続点をつくらない • 「ウォータフォール＝経済性」が約束されるのは、建設、製造などの成熟産業の話 • 後発のソフトウェア産業においては、仕様の不連続点のために、必ずしも「ウォータフォール＝経済 性」とはならない • 仕様の不連続点は不効率、コスト増の源であり、ソフトウェア業界におけるウォータフォール固有の ガンである • 反復型開発でも同様 25Copyright 2016 Synergy Research Corporation, All rights reserved. HOWを検討する 上流工程 要件定義工程 実装工程設計工程
- 26. どうすれば仕様の不連続点を回避できるのか • （先輩産業と同じく）あいまいな図面をかかない • 図面とは • UMLモデル • EXCEL • DB • テキスト記述 • あいまいなUMLモデルとは • これは実際にはなんなのかという質問に答えられないユースケース • これは実際にはなんなのかという質問に答えられないクラスや関連 • 「実際には」とはどういうことか （「実際」の観点は一つではない） • ユーザーに価値が理解できるものとして何なのかということ －＞ 顧客価値要素 • 開発者が作業の対象として理解できることものとして何なのか －＞ 実装価値要素 Copyright 2016 Synergy Research Corporation, All rights reserved. 26 ？ ？ ？
- 27. プラットフォームに制約された要求モデリング • 顧客価値モデル • 顧客（ユーザー）がその価値や意味を理解できるモデル • プラットフォーム依存 • 実装価値モデル • 開発者がその価値や意味を理解できるモデル • プラットフォーム依存 • 顧客価値要素と実装価値要素には明確な対応関係があること • 変換を何らかの方法でルール化できること • 自動的に変換できる必要はない 27Copyright 2016 Synergy Research Corporation, All rights reserved.
- 28. ショッピングサイトの例 Copyright 2016 Synergy Research Corporation, All rights reserved. 28 買い物を続ける レジに行く カート カートを空にする ログインする 商品一覧 商品詳細 商品番号 商品名 価格 １０ えんぴつ 100 ２０ 消しゴム 150 ３０ のり 120 買い物を続ける レジに行く カート カートを空にする ログインする 商品名 えんぴつ 価格 100 コメント 使いやすい 数量 1 カートに入れる 買い物を続ける
- 29. プラットフォームに制約された要求モデリング（クラス図）の例 • 画面遷移と情報構造をクラス図として描いた例 • ユーザーに理解ができて、かつ特定プラットフォームに対して過不足なく要求を表現している • クラスは、ユーザーがブラウザ上で閲覧するWEBページであり、ショッピングページのサブクラスは、 実装上で、必ずJSPとコントローラクラスに対応する Copyright 2016 Synergy Research Corporation, All rights reserved. 29
- 30. プラットフォームの前提 • 日本語と英語を辞書は変換する • Spring MVC • <!-- HandlerMapping --> • <bean class="org.springframework.web.servlet.mvc.support.ControllerClassNam eHandlerMapping"/> • <context:component-scan base-package="controller,dao,logic"/> • ・・・・・・・・・・・・・・・・・・・・・ • ・・・・・・・・・・・・・・・・・・・・・ 30Copyright 2016 Synergy Research Corporation, All rights reserved.
- 32. ますます重要になるITアーキテクトというロール • 組織的なロールの実現が求められている • 資質としては • 知識 • 責任感 • 人に組織に働きかける能力 • スーパーなプロマネにすべてを期待するのは無理 32Copyright 2016 Synergy Research Corporation, All rights reserved.
- 33. ビジネスまで最短距離のモデリング： 結論 • 俊敏性を求める開発でも上流工程での適切な準備が必要 （経済性） • 準備の中身としては、従来からの要件定義（WHAT）に加えて、（広い意味の）プラット フォームの選定と構築（HOW）が重要に。 • プラットフォームの選定と構築により、各種のオーバーヘッドが取り除かれると同時に、プ ラットフォームに制約されたより精度の高い要求モデリングが可能に。 • 「プラットフォームに制約された要求モデル」は仕様の不連続性によるコスト増を抑止し、 顧客フィードバックの迅速で頻繁な取り込みを可能にし、顧客フィードバック指向開発ス タイルを実現する。 • 特定プロジェクト環境においてHOWを構築し、その投資効果を実現するITアーキテクトの 役割と責任は大きい （かつてのビジネスアナリストに代わる役割） 33Copyright 2016 Synergy Research Corporation, All rights reserved.