アーキテクチャと要件定義の隙間（PPT版）

3. 1 2 3 4 5自己紹介高安厚思 ▌ 活動領域・キーワード ▌ ２０年にわたり、ソフトウエアエンジニアリングを適用したシステム開発やコンサルティングに携わる。 ▌ 最新技術を適切に利用した、柔軟なシステム構成の構築、品質管理を中心として技術マネージメントなどを主要テーマとして活動。 ▌ 開発方法論、アーキテクチャ設計コンサルティング、システム全体設計を得意分野とする。 ▌ 東京電機大学非常勤講師、SQuBOK設計開発領域検討委員。 ▌ 資格 ▌ ネットワークスペシャリスト ▌ アプリケーションエンジニア（現システムアーキテクト） ▌ プロジェクトマネージャ ▌ ITストラテジスト ▌ MCSE ▌ MCSD ▌ VSP/VSTP Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 3

4. 1 2 3 4 5対外活動 最近の著書、訳書 ▌ 「システム設計の謎を解く（ソフトバンク）」 ▌ 「StrutsによるWebアプリケーションスーパーサンプル（ソフトバンク）」 ▌ 「Seasar入門[（ソフトバンク）」 ▌ 「Javaルールブック（エクスメディア） ▌ 「ITアーキテクトのためのシステム設計実践ガイドアーキテクチャ編（日経BP）」など。 連載記事執筆 ▌ 日経SYSTEMS誌「Webアーキテクチャ再入門」 講演 ▌ SODEC ミッションクリティカル開発 ▌ 日本テクノセンターセミナー ▌ UML Forum ▌ 日経BP社 ITアーキテクトのためのシステム設計フォーラム特別講演 ▌ Developers Summit 2013 Summer Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 4

7. 1 2 3 4 5本日の話の背景 ▌ 要件定義は決められたことを元に思考するのではありません ▌ いわゆるWhatを定義するため、背景にある方針や思考を意識する必要があります。 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 7 常に価値を意識する • 価値基準の明確化仮説検証型の思考 • 差分を確認するモデルの利用 • 網羅的な遂行に必要な道具理想と現実のバランス • 事実に立脚すること

9. 1 2 3 4 5参考）Enterprise Architecture ▌ http://www.meti.go.jp/policy/it_policy/itasociate/EA3.ppt 「Enterprise Architectureについて」p41より引用 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 9 業績測定参照モデル（Business Reference Model ) 政策・業務参照モデル（Performance Reference Model ) (Data Reference Model) (Technical Reference Model ) 技術参照モデルデータ参照モデルサービスコンポーネント参照モデル (Service Component Reference Model ) データ体系技術体系（TechnologyArchitecture）適用処理体系（DataArchitecture）政策・業務体系（BusinessArchitecture）（ApplicationArchitecture）

13. 1 2 3 4 5追加）現行データの分析 ▌ 現行データの分析は、2つの理由から難しいですが実施すると効果の高い作業です。 ▌ 本作業の主たる作業は、主要データにおけるデータ分類を明確化することです。 Copyright (C) 2014 Atsushi Takayasu All Rights Reserved 13 2つの理由  アウトプットに対する工数比率が低くなる  現行データを提供することのセキュリティ上の課題データ分類の目的  ロジックへの影響を確認する  ドメイン値の統制がされているかどうかの確認をする  移行における難易度や工数を評価するための情報を確認する  テストデータへの変換に対する可否を確認する

14. 1 2 3 4 5アプリケーション ▌ アプリケーションの分析は新システムのアプリケーション構造の参考となる ▌ 課題はアプリケーションに埋め込まれていることも多い ▌ データ分類ごとのロジックを確認 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved 14 アプリケーション間の関係を把握アプリケーションの構造を把握 IOの確認ロジックの分析課題の原因を確認

16. 1 2 3 4 5アーキテクチャとは ▌ アーキテクチャは複雑であり、整理が重要 ▌ 本日の視点はシステムアーキテクチャ Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 16 http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory05/softfactory05_01.html から引用

17. 1 2 3 4 5システムアーキテクチャ ▌ システムアーキテクチャとして、把握すべき内容は以下の4つ ▌ これらを非機能要件の視点から把握 Copyright (C) 2012 Atsushi Takayasu All Rights Reserved. 17 ネットワーク • システム間の関係ストレージ • データの格納領域 • IO性能値サーバ • 構成 • 性能 • OS ソフトウェア • ミドルウェア • アプリケーション

18. 1 2 3 4 5これらから読み取ること ▌ 現行のシステムが構成された背景を推測します。もちろん、非機能要件定義書があれば確認をします。 ▌ 現行で想定されているサービスレベルや非機能要件が推測できます。 Copyright (C) 2012 Atsushi Takayasu All Rights Reserved. 18 可用性運用方針（監視・バックアップ）セキュリティオンラインとバッチの処理方針（データ連携の方針）

20. 1 2 3 4 5非機能要件のとりまとめ ▌ 現行情報と課題から、非機能要件をまとめる ▌ 対応すべき内容とコスト試算から適切な要件に落としこむ Copyright (C) 2014 Atsushi Takayasu All Rights Reserved. 20 非機能要件の確定非機能要件の調整想定ソリューション非機能要件整理非機能要件と課題予算現行要件非機能要件定義書システム分析アーキテクチャ分析

22. 1 2 3 4 5蛇足）現実問題としての移行 ▌ 移行は、必ず存在します。新システムだけでなく、現行システムを知っておかないと破綻します。 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 22 業務移行 • 新システム業務フロー • 新システム運用フローシステム移行 • システム切替 • 段階的切替 • 切戻データ移行 • 新旧マッピング • クレンジング • データ作成 • 更新停止・差分更新

23. 1 2 3 4 5今日お伝えしたかったこと！ ▌ 今日お伝えしたかったのは以下の3つです。 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 23 現状分析は重要です • すべてヒアリングで確認することはできません！非機能要件は可能かどうか検討すること • 非機能要件は実現手段を想定し、コストパフォーマンスを意識します。でも、現状と同じでは仕方ありません • 何を変える必要があるのか、見極めましょう！