Comments
Description
Transcript
システム開発のアジリティーを考える
システム開発のアジリティーを考える なぜプラント建設は納期に間に合い、システム開発は納期に遅れるのか 2015年9月4日 PMシンポジウム2015 タワーホール船堀 江戸川総合区民ホール 株式会社シナジー研究所 代表取締役社長 依田 智夫 yoda@synergy‐res.co.jp 自己紹介 共著書： 株式会社 シナジー研究所 代表取締役 プリンシパル・コンサルタント 東洋エンジニアリング株式会社入社後、システム系 技術者として、プラント建設支援のための情報シス テム開発に携わる。その後、加工組立系生産シス テムの事業立ち上げに参画。 1997年 株式会社シナジー研究所設立、代表取締 役。 以来、流通、製造、金融、サービス業向けの、 システム分析設計、概念モデリング、プロジェクトマ ネジメント支援、ソフトウェア資産可視化等に従事。 元総務省技術顧問（政府IT調達） IT‐ADRセンター専門ADR委員 ◦ 「要求開発 – 価値ある要求を導き出すプロセスとモデ リング ‐ 」 、日経BP社 監訳書： ◦ ◦ ◦ ◦ ◦ ◦ 「Javaオブジェクト設計」 「Javaエンタープライズ・コンポーネント」 「ビジネスオブジェクトモデリング」 「実践UML」 「UMLによるXMLアプリケーションモデリング」 「UMLによるWEBアプリケーション開発」 ◦ 「ビジネスパターンによるモデル駆動設計」 ◦ 日経BPソフトプレス社 「リーンソフトウェア開発と組織改革」 要求開発アライアンス理事 すべてピアソン・エデュケーション社 アスキーメディアワークス エンタープライズ・アジリティー協議会会長 エンタープライズ・アジャイル勉強会役員 Copyright 2008-2015 Synergy Research Corporation 2 独自性ある情報システム構築の課題と解決策 独自性ある情報システム構築の課題と解決策 設計を重視した段階的ソフトウェア開発プロセス 情報可視化共有型プロジェクト Copyright 2008‐2015 Synergy Research Corporation 3 独自性ある情報システム構築、その課題とは？ • 独自性あるシステムの構築は競争優位性実現のための重要な手段 • ERPパッケージ＋アドオンは、コストアップの要因にしかならなかった • 競争優位とは、企業が実行する活動の違いから生じる、相対的価格または相対的コストの違いをいう。 • 「マイケルポーターの競争戦略」、ジョアン・マグレッタ著、櫻井 祐子訳、早川書房 • 効率的に独自性あるシステムの構築が可能であることの意味は非常に大きい • しかしながらその失敗は後を絶たない • 官も民も • 主要な失敗原因は常に要求・要件に関わるものとされてきた • 「日経コンピュータ（2003.11）のアンケート結果にもあるように，要求仕様の不備は，開発プロジェクトに甚大な被害を与えてしまう （失敗原因の40％）」 http://itpro.nikkeibp.co.jp/article/Watcher/20061120/254219/ • 「プロジェクト失敗の80%~85%は間違った要求に起因することが複数の研究で示されている」（ 「アジャイルソフトウェア要求、Dean Leffingwell著、（日本語版：株式会社オージス総研、藤井拓監訳）」によせたDon Reinertsenの前書きより） • 要求・要件に関わる問題 ① 正しく捉えることが難しい ② 一度決めたあとの変更が難しい（許されない） • 要求・要件による失敗の回避策として、アジャイル開発をはじめとする軽量な開発スタイルへの期待が大きい。し かし、開発スタイルへの過信がさまざまなプロジェクト運営上の問題を引き起こしている • 要求が明確でなくても開発が始められる・・・ • 途中でいくらでも要求を変えられる・・・ • 軽量だからコストも抑えられそう Copyright 2008‐2015 Synergy Research Corporation 4 エンタープライズと呼ばれるシステムのイメージ • 比較的大規模な企業情報システムに対してエンタープライズという形容詞が付 くようになった。 • エンタープライズの規模？ • • • • • • • • ユースケース100以上 テーブル100以上 予算5000万円以上 期間1年以上 トランザクションとマスターの明確な区分 基幹業務を支援 競争優位性に密接に関係 要求開発・要件定義段階で創意工夫が必要 Copyright 2008‐2015 Synergy Research Corporation 5 システム構築プロジェクトの成功率 日経BP Next ICT選書、日経コンピュータReport、IT業界を数字で見る、日経コンピュータ編、より作図 Copyright 2008‐2015 Synergy Research Corporation 6 軽量な開発スタイルとは • • • • プロトタイプ型開発 スパイラル型開発 アジャイル開発 RAD（高速アプリケーション開発）ツールによる開発 Copyright 2008‐2015 Synergy Research Corporation 7 軽量な開発スタイルへの過信によって生じる プロジェクト運営上の問題点 問題点 具体的に言うと 要求・要件の独り歩き 要求・要件の扱いが不明確で、スコープ管理があいまい。結果として、 コスト、スケジュールの把握が困難。 視野の狭いプロジェクト管理 プロジェクトベースラインが要求・要件の大枠と予定工数のみ。WBSと して粗く、真のEVM（出来高管理）が困難。 柔軟すぎる開発スタイル 反復単位の中で基本的に何でもできる。明確なプロジェクトライフサイ クルがないため、実施内容に関する指針がない。 アジリティー（俊敏性）の浪費 要求・要件を模索するための反復単位のはずだが、実際には、いろい ろなことに忙しく、顧客のために十分使えていない。 不明確な責任 スコープがあいまいのまま進むため、組織上の責任が不明確で、適 切な緊張感が不足する。外注が高リスクとなる。 難しい方向転換（中止、やり直し） レジリエンス不足 プロジェクトライフサイクルが不明確なため、意思決定のチャンスが失 われやすい。大きな損害につながりやすい。あるいは、一度形骸化す ると元に戻れない。 Copyright 2008‐2015 Synergy Research Corporation 8 解決策の提案 • 解決策 ① 設計（基本構造設計）を重視した段階的ソフトウェア開発スタイル • 上質な設計情報の生成と管理 精密な情報 一貫性のある情報 最新の情報 プロジェクトベースラインとなる ② 情報可視化共有型プロジェクト • 可視化を積極的に推し進め、生成された情報を適切に共有する仕組みをもったプロジェクト • 問題点との対応（対策としての有効性） 問題点 ① 段階的ソフトウェア開発プロセス ② 情報可視化共有型プロジェクト 要求・要件の独り歩き ○ ○ 視野の狭いプロジェクト管理 ○ ○ 柔軟すぎる開発スタイル ○ アジリティー（俊敏性）の浪費 ○ 不明確な責任 ○ ○ 難しい方向転換・レジリエンス不足 ○ ○ Copyright 2008‐2015 Synergy Research Corporation 9 設計を重視した段階的ソフトウェア開発スタイル 独自性ある情報システム構築の課題と解決策 設計を重視した段階的ソフトウェア開発プロセス 情報可視化共有型プロジェクト Copyright 2008‐2015 Synergy Research Corporation 10 プラント建設を参考にする （依田の経歴と体験） • 新卒で入社以来、19年間プラントエンジニアリング会社に在籍 • 在籍期間の前半では、情報システム要員としてプラント建設プロジェクトに参画 • プロジェクト管理システム • 現地工事管理システム • その経験の中で、プロジェクトライフサイクルを通じた、プラント設計情報の生成と利用 方法について学ぶことができた。 • プロジェクトには明確な段階分け（フェーズ）が存在する • プロジェクトの進行に伴い、設計情報は、段階的に詳細化されていく • プロジェクトのどんな段階でも、その時点で利用可能な設計情報は、プロジェクトマネジメントのための 情報として共有され、コスト・スケジュールの予測に活用される。 • その後、ソフトウェア開発系コンサルタント事業のために起業、独立 • 多くのソフトウェア開発プロジェクトに参画したが、プラント建設業とソフトウェア業、それ ぞれの仕事の進め方の良いとこどりができないか考えてきた。 Copyright 2008‐2015 Synergy Research Corporation 11 プラント・エンジニアリング会社に勤務していたころ Copyright 2008‐2015 Synergy Research Corporation 12 プラント建設業とソフトウェア業（ビジネス系システム）の比較 プラント建設 ソフトウェア 工程分け ウォーターフォール型（R&D除く） 計画、基本、詳細、調達、工事 従来は左記と同様であったが、ウォーターフォー ル型は最近すこぶる評判がわるい。新しいスタイ ルを模索中。 制度・文化 教育が充実（出身会社には「大学」があった）、 先輩から教わることができる。 やりきる文化、伝える文化。 外注（サブコントラクト）は、最大コスト工程のコス トミニマムのために当然。 ドキュメントが重視されかつ活きている。 新しい分野かつ変化の激しい分野であり、何を教 えるべきかの迷いが常に。（技術V.S.管理、製品 V.S.実装・・・）。 やりきる、伝える、は実に弱い。 なんのためにどこまで外注するのか、迷いが常 に。ドキュメントは少ないか多いかどちらかに極 端。多くてもたいていは活用されない。 QCDすべてに方法論がある QDが弱い。Cは根性で。 予算 数百億～数千億 数千万～数千億 期間 年 数か月～年 人 数十人～数百人 数人～数百人 欠陥・瑕疵の影響 大事故・爆発・人身事故 大事故に直接つながらないが、社会的影響は拡 大中。 QCD Quality Cost Delivery Copyright 2008‐2015 Synergy Research Corporation ウォータフォール嫌 いは食わず嫌い？ 13 プラント建設の工程 「WIKIPEDIA」の表から翻訳 IPA: FEL(Front-End Loading) FEL-1 FEL-2 FEL-3 ・物質収支 ・プレリミナリ機器設計 ・調達用主要機器仕様 ・エネルギー収支 ・プレリミナリレイアウト設計 ・確定見積 ・プロジェクト憲章 ・プレリミナリスケジュール ・プロジェクト実行計画 ・プレリミナリ見積 ・プレリミナリ 3-Dモデル 調達に絡む設計 供給業者（Supplier)との情報の授受 工事に絡む設計 現地工事側との情報の授受 ・電気計装機器リスト ・配管リスト ソフト契約とEPC契約の境界 設 計 E (ENGINEERING) 基本計画・概念設計 基本設計 詳細設計 工事設計・施工設計 (BASIC PLANNING/CONCEPTUAL DESIGN) (BASIC DESIGN) (DETAIL DESIGN) (CONSTRUCTION DESIGN) 調 達 P (PROCUREMENT) 設備・材料発注／製作／検査／現地搬送 (PURCASE ORDER/MANUFACTURING/INSPECTION/TRANSPORTATION) 工 事 C (CONSTRUCTION) 現地工事・試運転 (CONSTRUCTION/PRE-COMMISSIONING) (1) プロセス計画設計 （プロセスフローシート） （２） プロセス基本設計 （３） プラントレイアウト （４） 詳細設計 （５） 機器資材調達 （６） 工事 依田が見てきた世界 Copyright 2008‐2015 Synergy Research Corporation 14 プラントの基本設計（プロセスフローシート） Copyright 2008‐2015 Synergy Research Corporation 15 プラントの基本設計（プラントレイアウト） Copyright 2008‐2015 Synergy Research Corporation 16 IPA‐FEL (Front‐End Loading) • IPA: Independent Project Analysis社、メガプロジェクトを対象としたプロジェクト評価とベンチマー キングの世界的企業 • メガプロジェクト： 10億ドルクラスの、石油、化学、医薬、鉱物プラント等のプロジェクト • IPA‐FEL (Front‐End Loading) ： もっともコストのかかる工程である調達・工事の開始前に、情報 の世界だけで、設計と調達・工事計画等を精密かつ整合的に行い、トータルコストを下げる考え 方。 • FELのレベルに応じて、FEL１、FEL2 、 FEL3と3段階があり、それぞれの終了条件を満たした場合 にのみ通過できるFEL GATEをもち、個別プロジェクトに対して終了条件の判定結果としてFEL RATINGを与える。 • IPAは、FEL RATINGが良好な場合にのみ、次ステップに進むことをオーナーに強く進めている。 FEL RATINGとプロジェクトの最終結果に関するデータベースを持っているため、非常に説得力が ある。 • 契約の収支のみを気にする建設・エンジニアリング会社の視点ではなく、投資計画を成功させな ければならないオーナーの視点を提供している。「継続、中止、やり直し」を視野に入れている。 Copyright 2008‐2015 Synergy Research Corporation 17 FEL (Front‐End Loading) Gate 1 Gate 2 基本計画・概念設計 アイデア ジェネレーション/ 構想づくり 機会の定義 Gate 3 基本設計 スコープ開発 工事設計 施工設計 詳細設計 プロジェクト定義 設備・材料発注 /製作/検査/ 実行 現地搬送 生産 現地工事 試運転 FEL‐1 FEL‐2 FEL‐3 経済的合理性！！ ビジネスケースは 強固か スコープは 完全か？ 実行開始 できるか？ 関係組織、関係者が 一気に広がる直前。 Insustrial megaprojects, Concepts,Strategies, and Practices for Success, Wiley, 2011 より、翻訳、加筆、転載 従来の詳細設計を 分断。 Copyright 2008‐2015 Synergy Research Corporation 18 背景にあるコストの考え方 PMBOKガイド第5版、PMI。 図2‐9. 「プロジェクト期間に基づいた可変要素の影響」 を転載 高 リスクや不確実性 度 合 い 変更コスト 低 プロジェクト経過時間 Copyright 2008‐2015 Synergy Research Corporation 19 軽量な開発スタイルの代表アジャイル開発との対比 • XPの場合 • 変更コストはプロジェクトの進行とともに上昇する と考えられてきたが、一定の条件が満たされる場 合、変更コストはフラットに近いものになる。 COST OF CHANGE • この時に、従来のソフトウェア開発の常識が大き く変わる。 変更コスト • 価値ある要求をいつでも取り込むことができて、 無駄のないソフトウェア開発が可能となる。 REQUIRMENTS ANALYSIS DESIGN IMPLEMENTATION TESTING PRODUCTION • 一定の条件とは、適切な技術とプログラミング・ プラクティスの組合せ • 適切な技術の代表 • オブジェクト指向プログラミング 変化を抱擁せよ！ （変化を積極的に受け入れなさい） Extreme Programming Explained, EMBRACE CHANGE Kent Beck, Addison Wesley, 2000より COST OF CHANGE 変更コスト TIME FIGURE3. The cost of change may not rise dramatically over time Copyright 2008‐2015 Synergy Research Corporation 20 大規模化にともない変更コストは加速度的上昇する 一単位の変更 COST OF CHANGE 40人月プロジェクト 30人月プロジェクト 20人月プロジェクト 単 位 ビ ジ ネ ス 価 値 の 変 更 コ ス ト システムと組織の 複雑化 10人月プロジェクト TIME Copyright 2010‐2014 Synergy Research Corporation 21 メガプロジェクト V.S. アジャイル開発 • 同じプロジェクトの世界に二つの「ど反対」の考え方があるように見える。 • しかし、IPA‐FELが、プロジェクト前半における準備活動の重要性を、アジャイル開発が、 プロジェクト後半における柔軟性とその価値について語っていると考えると、これらの間 に矛盾はないと考えられる • これらが融合できるプロジェクトライフサイクルモデルは存在するか。 Copyright 2008‐2015 Synergy Research Corporation 22 エンタープライズ開発の流れ DAD （Disciplined Agile Delivery）： ディシプリンド・アジャイル・デリバリー RUP （Rational Unified Process） UP （Unified Process） ユニファイドプロセス SAFe （Scaled Agile Framework） エンタープライズ・アジャイル開発？ SEMAT （Software Engineering Method and Thory） Copyright 2008‐2015 Synergy Research Corporation 23 UPにおける反復の考え方 この図は反復型開発（UP）を説明するためにしばしば用いられるが、 ウォータフォール、反復、アジャイルのすべての開発工程が含まれ ているとも言えます。 システムのライフサイクル 誕生 サイクル １ サイクル ２ サイクル ３ サイクル ４ 終了 フェーズ リリース 作業分野 (Discipline) 方向付け Inception リリース 推敲 Elaboration リリース 構築 Construction 移行 Migration 要求 分析 設計 実装 テスト イテレーション 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 Copyright 2008‐2015 Synergy Research Corporation 24 反復型開発にFELを結合すると 現地工事 試運転 基本計画・概念設計 アイデア ジェネレーション/ 構想づくり 機会の定義 基本設計 スコープ開発 Gate 1 xxxxxxxxxx xxxxxxxxxx 詳細設計 設備・材料発注 /製作/検査/ 実行 現地搬送 プロジェクト定義 Gate 2 xxxxxxxxxx 工事設計 施工設計 生産 Gate 3 構築 Construction 移行 Migration 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 反復 Copyright 2008‐2015 Synergy Research Corporation 25 FELが結合された反復型開発の利点 • 重要な構造に関わる設計（アーキテクチャー設計）が、構築フェーズ前に完了している。 • アジャイル開発の考え方では、アーキテクチャー設計に関わるアクティビティの必要性が認めら れているにも関わらず明らかには語られない。 • 「アジャイルの成功の多くは小さなプロジェクトで生まれているので、それが大規模システムでは同じように有用であるかを問うのはごく自然である。私はアジャイル手法の価 値を非常に尊重しているが、大規模システム開発のニーズを満足するためにそれらの手法を拡張しなければならないというDean氏（アジャイルソフトウェア要求の著者）の考 え方は正しいと思う。大規模システムのアーキテクチャーは自然と出現し、不十分な点はリファクタリングで取り除けると仮定するのは非常にリスクが高い。例えば、海軍の軍 艦は３０年間就役するように設計されている。優秀な海軍のアーキテクトは、驚異の拡大、技術の出現、任務の変化を予期する。アーキテクチャーが「出現」するがままにまか せて、そのようなシステムづくりはしない。」（Don Reinertsen、出典は前出と同様） • 明確なフェーズを設けることでアーキテクチャ設計の確実な実施を保証する。 • リファクタリング（実装での方向転換）の限界をカバーできる。 • 顧客価値の追求に使用されるはずの構築フェーズにおける反復が、技術検証、アーキ テクチャー設計で浪費されない。顧客価値追求のための柔軟性はアーキテクチャ設計 の範囲内で守られる。 • アーキテクチャ設計の範囲を超えた変更も、プロジェクトに備わる変更管理によって可 能である。 • FEL GATEにより、継続、中止、再実施の判断が可能になるため、オーナーの資産、投資 機会を守りやすい。 Copyright 2008‐2015 Synergy Research Corporation 26 大規模アジャイルにおけるアーキテクチャー設計 アジャイルプロジェク トのキックオフ 反復 1 反復 2 反復 3 時間 マネージメントチーム アーキテクチャチーム 先行プロジェクト チーム プロトタイピングチーム キックオフやマネジメントチームの発足 前に何をトリガーに先行チームをスター トさせるのか （依田） 初期反復でのアーキテクチャの構築 （16.6 アーキテクチャ助走路の構築より） 翔泳社、ディーン・レフィングウェル、アジャイル開発の本質とスケールアップ、2010より転載して改変 Copyright 2008‐2015 Synergy Research Corporation 27 アーキテクチャー設計を何とか押し込んだ例 政府ガイドラインにおける調達手順 調達担当課室 Ｓ 調達仕様書 作成 最適化計画策定支援事業者 最適化 計画策定 仕様書作成 (要件定義書) 調 達 調達単位 決定 調達仕様書 作成 受入テ スト 共通基盤 単体テスト 結合・ 総合テスト 工程管理支援事業者 工程管理 共通基盤事業者 調 達 要件の精査 ・システム化要件の精査 ・運用・保守要件の精査 共通基盤 設計・開発 基本的事項の整理 ・システム方式の具体化 運用・保守設計 個別機能事業者(複数) 調 達 調 達 個別機能 設計・開発 運用・保守 設計 個別機能 単体テスト 結合・ 結合・ 総合テスト 総合テスト ハードウェア等納入業者 HW/SW 設定・設置 図3‐14 保守分離調達の手順 総務省行政管理局、 「情報システムに係る政府調達の基本指針 実務手引き書、2007、より 一部改変 Copyright 2008‐2015 Synergy Research Corporation HW/SW 保守 調 達 調 達 運用事業者 受入テ スト 運用 保守事業者 受入テ スト 保守 28 アーキテクチャー設計でWBSも息を吹き返す 2軸管理のWBS 位置のストラクチャー A‐WBS 役務のストラクチャー ‐ F W B S • • P2M 標準ガイドブック 改訂3版、日本プロジェクトマネジメント協 会、JMAM、2014、より転載し加筆 （エンジニアリングプロジェクト・マネジメント、重化学工業通信社、 1986） ワーク パッケージ リソース ○○ スケジュール 作業管理責任 作業○○ スケジュールアクティビティー 1. 役務のストラクチャー (何をすべきか？) 役務とは作業を表すもので、具体 的には設計、調達、建設、あるいは 製作、プロジェクト・マネジメント・サー ビス等々であり、下位レベルのブレイ クダウンを行えば、カテゴリーに区分 され、更にプロダクトあるいはタスクで 区分されるものである。 2. 位置のストラクチャー (どこの作業か？) 上記作業を識別するもう一方の条 件として、何の設計なのか、どこの建 設なのかといった位置を明らかにす る要素が必要である。 具体的にはプラント、ファシリティー、 ユニット、エリア、作業(コントロール) ブロックといった区分となる。 Copyright 2008‐2015 Synergy Research Corporation • • • ビジネスプロセス ユースケース 共通機能 • • サーバー サービス • プロセス • ビジネス • アプリケーション EAIコンポーネント アプリケーション・コンポー ネント メッセージング・システム 開発環境 • • • • 29 WBSはプロジェクトベースラインの出発点である • スコープ マネジメント P2M 標準ガイドブック 改訂3版、日本プロジェクトマネジメント協 会、JMAM、2014、より転載 WBS HOW WHO アーンドバリュー マネジメント 報告･変更･課題管理 ワークパッケージ WHAT HOW MUCH 品質 マネジメント WHEN トレードオフ コスト マネジメント 引き渡し管理 タイム マネジメント ライフサイクルマネジメント Copyright 2008‐2015 Synergy Research Corporation 30 EVM（出来高管理の活用） 計画時の 完了日 今後発生予想原価 (EAC) EAC 計画時の 予算 コストのオーバーラン (BAC) 予測原価、資源消費、出来高 • スケジュール差異(時間) 計画配分予算 (BCWS) プロジェクトの概念 プロジェクトマネジメントの知恵に学ぶ、日本 プロジェクトマネジメント協会編、神沼靖子著、近代科学社、2013 より転載 コスト差異 (CV) スケジュール差異(コスト) (SV) 実際発生コスト (AC) スケジュールの オーバーラン 作業出来高 (EV) 報告日 時間 EVMによる諸解析 Copyright 2008‐2015 Synergy Research Corporation 31 FEL発想でさまざまな設計基礎情報が確実に利用可能となる テーブル分類 開発フェーズ分け（案） 事例： CRUD表 ｻﾌﾞ ｼｽ ﾃﾑ ブ ル 名 機能ID 機能名 D契約01-01 見積一覧画面 2 D契約01-03 見積管理画面 3 見 D契約01-05 積 No 1 D契約01-06 見積書面編集画面 5 R契約01-01 見積書・注文書PDF出力 6 D契約02-01 契約一覧画面 7 R契約02-02 先方担当者情報CSV出力 8 D契約02-02 契約詳細検索条件指定画面 9 D契約02-03 契約管理画面 10 R契約02-03 契約内容PDF出力 11 D契約02-04 契約明細管理画面 12 D契約02-05 約定回収一覧画面 13 R契約02-01 契約一覧CSV出力 14 D契約02-06 従量課金利用量登録画面 15 契 D契約02-08 約 契約タグ管理画面 16 D契約02-09 契約変更履歴画面 17 D契約02-10 開通情報管理画面 18 D契約02-12 19 B契約02-01 先方担当者情報FML連携バッチ 問合せ検索画面 20 D契約03-01 D契約03-02 受注管理画面 22 D契約03-03 一式タグ管理画面 23 R契約03-01 注文請書PDF出力 24 B契約03-01 分析用スナップショット作成バッチ 本フェーズリリース までは、 新契約系と新請求 契 約 基 本 マ ス タ 契 約 明 細 マ ス タ 契 約 料 金 約 定 回 収 基 本 マ ス タ S S L ・ ド メ イ ン ○ ○ 現状EXCEL ○ 更 新 明 細 S S L ・ ド メ イ ン 更 新 履 歴 S S L ・ ド メ イ ン 見 積 見 積 明 細 見 積 帳 票 明 細 見 積 料 金 合 計 契約 受 注 受 注 契 約 明 細 受 注 明 細 解 約 解 約 明 細 情提 報供 サ ビ ス 個 別 契 約 タ グ 明 細 一 式 タ グ 契 約 基 本 履 歴 契 約 明 細 履 歴 R R C R C U R C R D R R U R R R R R R C C ○ R R R R R R R R R ○ ○ C R C R C R 約定回収の機能拡張へ対 U D U D U D 応 R R R ○ SSL・ドメインの次年度契 約の手動作成に関し 簡 ○ ○ R R C R 約定回収の機能拡張へ対 U U D U D 応 R R R R R R R R R R R R R R R R C R C R C R R R R R R R R ○ R R R R ○ R R R R ○ R R R R R C R C R D D ○ R ○ R U R U R R ○ R R R R R R U R R U R R R U C R C R C R U D U D U D R U C R C C C R U D R R R R ○ 新業務 ○ 現状EXCEL R C R U U ○ ○ C U ○ ○ 新業務 ○ 新業務 契 約 料 金 履 歴 C R C R C R C R D D D D C R C R C U ○ ○ 契 約 タ グ C R C R C R C R 現状EXCEL ○ 現状EXCEL 受注一覧画面 21 開発Ⅲ 現状EXCEL ○ 現状EXCEL 見積受注変換画面 4 開発Ⅱ （請求/入金 系） ー ー テ 開発Ⅰ （契約／マスタ 系） R R R Copyright 2008‐2015 Synergy Research Corporation R R R R 32 表形式の2軸WBS 機能一覧 90：共通 90：共通 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 01：見積 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 03：契約 ッ 1 共通 2 共通 3 見積 3 見積 3 見積 4 見積 5 見積 5 見積 5 見積 6 見積 7 見積 7 見積 8 見積 8 見積 9 見積 9 見積 9 見積 10 見積 10 見積 11 契約 11 契約 11 契約 11 契約 11 契約 11 契約 11 契約 11 契約 11 契約 11 契約 11 契約 12 契約 13 契約 13 契約 14 契約 14 契約 15 契約 15 契約 15 契約 16 契約 汎 バ C バ 用 画 帳 S ツ チ 面 票 V チ 区 ル 分 ッ カ テ メニューカテゴリ ゴ リ ー N o ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 機 能 I D Presentation Layer 機能名称 Client 入力チェック D共通00-01 D共通00-02 D契約01-01 D契約01-01 D契約01-01 D契約01-01 D契約01-03 D契約01-03 D契約01-03 D契約01-03 D契約01-03 D契約01-03 D契約01-05 D契約01-05 D契約01-06 D契約01-06 D契約01-06 R契約01-01 R契約01-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 D契約02-01 Business Layer 表示モード 親画面へ 帳票印刷 別機能呼出 切換 情報反映 File Upload File メール送信 Download 照会系 WebService Domain DB相関 更新系 チェック Data Access Layer DbAccess External Access 帳票作成 クライゼル SRSPlus システム化対象外 SBI SQL ｽﾄｱﾄﾞ 外部システム（手動ファイル連携） クライゼル FML TKC CA 各種 明治安田 レジストリ 金融期間 メール送信先 取引先 担当者 デヂエ 社内 担当者 ログイン メインメニュー 見積一覧画面 見積一覧画面 見積一覧画面 見積管理画面 見積管理画面 見積管理画面 見積受注変換画面 見積受注変換画面 見積書面編集画面 見積書面編集画面 見積書面編集画面 見積書・注文書PDF出力 見積書・注文書PDF出力 契約一覧画面 契約一覧画面 契約一覧画面 契約一覧画面 契約一覧画面 契約一覧画面 契約一覧画面 契約一覧画面 契約一覧画面 契約一覧画面 契約一覧画面 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ Copyright 2008‐2015 Synergy Research Corporation 33 概念モデルは重要なアーキテクチャ設計成果物である クラス図 不動産仲介ベンチャー企業 株式会社ワンストップ様のご厚意による インスタンス図 Copyright 2008‐2015 Synergy Research Corporation 34 課題は解決されているか 問題点 ① 段階的ソフトウェア開発プロセス ② 情報可視化共有型プロジェクト 要求・要件の独り歩き ○ ○ 視野の狭いプロジェクト管理 ○ ○ 柔軟すぎる開発スタイル ○ アジリティー（俊敏性）の浪費 ○ 不明確な責任 ○ ○ 難しい方向転換・レジリエンス不足 ○ ○ Copyright 2008‐2015 Synergy Research Corporation 35 情報可視化共有型プロジェクト 独自性ある情報システム構築の課題と解決策 設計を重視した段階的ソフトウェア開発プロセス 情報可視化共有型プロジェクト Copyright 2008‐2015 Synergy Research Corporation 36 設計情報が持つ二つ（縦軸と横軸）の役割 縦軸 アイデア ジェネレーション/ 構想づくり 基本計画 概念設計 機会の定義 スコープ開発 基本設計 横軸 フェーズ内で同期す るべき情報 設計過程で得られる情報は、 一刻も早く実行のための情報 として変換されて工程を通過 していく必要がある。 しかし、同時に「継続、実施、 やり直し」を含む意思決定や、 プロジェクトの改善のために、 関係者間での機能横断的な 共通理解が促進されるべき情 報でもある。 後者のためには、フェーズ間 を同期して、整然と設計作業 を進めるべきである。 プロジェクト定義 詳細設計 現地工事 試運転 設備・材料発注 /製作/検査/ 現地搬送 工事設計 施工設計 実行 最大コストの発生工程 生産 Copyright 2008‐2015 Synergy Research Corporation 37 プロジェクトの多様性・複雑性・高度化への対処 • いろいろな人・組織 • 知識 • 経験 • スキル • 組合せはさらに多様になる • 専門性はますます高まる • 視野の狭いプロジェクトの運営は硬直化や破たんを早める場合がある • 関係者の知恵が有機的に活用され、気づきと行動が促進されるような組織にす る必要がある。 • システム思考 • 働く人を含めてシステムである • 「どうすればよいかを経営トップが考え、ほかの人すべてをその「大戦略家」の命令に従わせることなど、もう不可 能なのだ」（「学習する組織」、ピーター・M・センゲ、枝廣淳子他訳、栄治出版、2011より） • プロジェクトの科学とは矛盾しないはず Copyright 2008‐2015 Synergy Research Corporation 38 まとめ 独自性ある情報システム構築の課題と解決策 設計を重視した段階的ソフトウェア開発プロセス 情報可視化共有型プロジェクト Copyright 2008‐2015 Synergy Research Corporation 39 まとめ（追加） • 開発プロセスの選定は、妥協の産物でも肝試しでもなく、最適化問題として取り 組まれるべき課題である。ウォータフォール否定やGATE否定にやすやすと負け てはならない • 考えた末に、ウォータフォールが消えれば最高 • 思考放棄や人任せに陥らず、いままでの知識資産を最大限に継承し活用する。 それらは矛盾しておらず、経済的合理性の観点で統合できる。 • • • • プロジェクト管理 FEL GATE ウォータフォール型プロセス 軽量プロセス • アジャイル・リーン • システム思考 • 画一的な答えはないが、最適解はある。 • 硬すぎず柔らかすぎない方法で、ビジネス価値を実現する失敗しない開発を目 指してください。 Copyright 2008‐2015 Synergy Research Corporation 40