Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,140 views

Published on

QCon Tokyo 2014にてお話させていただいた資料。
話した内容のもととなった原稿を確認されたい方はPDF版をご参照ください。

http://www.slideshare.net/taka1970/2010430-qcon-after

  • Be the first to comment

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

  1. 1. アーキテクチャと要件定義の隙間 〜現状分析から得られること〜 1Copyright (C) 2013 Atsushi Takayasu All Rights Reserved.
  2. 2. 1 2 3 4 5アジェンダ ▌ 自己紹介 ▌ 1 はじめに ▌ 2 システム分析 ▌ 3 アーキテクチャ分析 ▌ 4 終わりに Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 2
  3. 3. 1 2 3 4 5自己紹介 高安 厚思 ▌ 活動領域・キーワード ▌ 20年にわたり、ソフトウエアエンジニアリングを適用したシステム 開発やコンサルティングに携わる。 ▌ 最新技術を適切に利用した、柔軟なシステム構成の構築、品質管理を 中心として技術マネージメントなどを主要テーマとして活動。 ▌ 開発方法論、アーキテクチャ設計コンサルティング、システム全体設 計を得意分野とする。 ▌ 東京電機大学非常勤講師、SQuBOK設計開発領域 検討委員。 ▌ 資格 ▌ ネットワークスペシャリスト ▌ アプリケーションエンジニア(現 システムアーキテクト) ▌ プロジェクトマネージャ ▌ ITストラテジスト ▌ MCSE ▌ MCSD ▌ VSP/VSTP Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 3
  4. 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
  5. 5. 1 はじめに Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 5
  6. 6. 1 2 3 4 5今回の位置付け ▌ 今日の話は、現行システムからのリプレイスにおいて、 死角になりがちな内容について触れていきます。 ▌ 新しい業務については重要ですが、今回お話する内容の対象外です! Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 6 要件定義 その 他 現状 分析 要求 開発
  7. 7. 1 2 3 4 5本日の話の背景 ▌ 要件定義は決められたことを元に思考するのではありません ▌ いわゆるWhatを定義するため、 背景にある方針や思考を意識する必要があります。 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 7 常に価値を 意識する • 価値基準の 明確化 仮説検証型 の思考 • 差分を 確認する モデルの 利用 • 網羅的な 遂行に 必要な道具 理想と現実 のバランス • 事実に立脚 すること
  8. 8. 1 2 3 4 5リファレンスモデルの代表例 ▌ リファレンスモデルとして、参考としていくつかご紹介します。 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 8 Enterprise Architecture DMBoK TOGAF ADM
  9. 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)
  10. 10. 2 システムの分析 EAの視点から Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 10
  11. 11. 1 2 3 4 5業務 ▌ 対象システムを超えて、業務の位置づけを把握(判断材料) ▌ 業務移行を意識して、業務内容を把握 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 11 全体システム化計画(最適化計画)での 課題認識 業務体系の確認 対象業務の詳細化(経営・管理・OP) 業務移行
  12. 12. 1 2 3 4 5データ ▌ システム現状分析の要となる調査・分析 ▌ 業務の視点とアプリの視点の双方が必要となり、 これらをインクリメンタルに実施 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved 12 業務をデータの流れで追っていく 現行データの分析を実施 詳細は次頁 データ分類の明確化 データ辞書の確認(作成)
  13. 13. 1 2 3 4 5追加)現行データの分析 ▌ 現行データの分析は、2つの理由から難しいですが実施すると 効果の高い作業です。 ▌ 本作業の主たる作業は、主要データにおけるデータ分類を 明確化することです。 Copyright (C) 2014 Atsushi Takayasu All Rights Reserved 13 2つの理由  アウトプットに対する工数比率が低くなる  現行データを提供することのセキュリティ上の課題 データ分類の目的  ロジックへの影響を確認する  ドメイン値の統制がされているかどうかの確認をする  移行における難易度や工数を評価するための情報を確認する  テストデータへの変換に対する可否を確認する
  14. 14. 1 2 3 4 5アプリケーション ▌ アプリケーションの分析は新システムのアプリケーション構造の 参考となる ▌ 課題はアプリケーションに埋め込まれていることも多い ▌ データ分類ごとのロジックを確認 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved 14 アプリケーション間の関係を把握 アプリケーションの構造を把握 IOの確認 ロジックの分析 課題の原因を確認
  15. 15. 3 アーキテクチャ分析 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 15
  16. 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. 17. 1 2 3 4 5システムアーキテクチャ ▌ システムアーキテクチャとして、把握すべき内容は以下の4つ ▌ これらを非機能要件の視点から把握 Copyright (C) 2012 Atsushi Takayasu All Rights Reserved. 17 ネット ワーク • システム間の 関係 ストレージ • データの 格納領域 • IO性能値 サーバ • 構成 • 性能 • OS ソフト ウェア • ミドルウェア • アプリケー ション
  18. 18. 1 2 3 4 5これらから読み取ること ▌ 現行のシステムが構成された背景を推測します。 もちろん、非機能要件定義書があれば確認をします。 ▌ 現行で想定されているサービスレベルや非機能要件が推測できます。 Copyright (C) 2012 Atsushi Takayasu All Rights Reserved. 18 可用性 運用方針(監視・バックアップ) セキュリティ オンラインとバッチの処理方針 (データ連携の方針)
  19. 19. 1 2 3 4 5性能はデータから判断 ▌ 現行システムの性能情報は必ず取得しましょう。 ▌ 取得方法はいろいろあります! ▌ 平均値とピーク時の値を元に、将来値を考慮します。 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 19 CPU、メモリ使用率 IOPS、IOスループット ネットワークスループット イベントリ情報
  20. 20. 1 2 3 4 5非機能要件のとりまとめ ▌ 現行情報と課題から、非機能要件をまとめる ▌ 対応すべき内容とコスト試算から適切な要件に落としこむ Copyright (C) 2014 Atsushi Takayasu All Rights Reserved. 20 非機能要件の確定 非機能要件の調整 想定ソリューション 非機能要件整理 非機能要件と課題 予算 現行要件 非機能要件 定義書 システム分析 アーキテクチャ 分析
  21. 21. 4 終わりに Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 21
  22. 22. 1 2 3 4 5蛇足)現実問題としての移行 ▌ 移行は、必ず存在します。新システムだけでなく、現行システムを 知っておかないと破綻します。 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 22 業務移行 • 新システム業務フロー • 新システム運用フロー システム 移行 • システム切替 • 段階的切替 • 切戻 データ移 行 • 新旧マッピング • クレンジング • データ作成 • 更新停止・差分更新
  23. 23. 1 2 3 4 5今日お伝えしたかったこと! ▌ 今日お伝えしたかったのは以下の3つです。 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 23 現状分析は重要です • すべてヒアリングで確認することは できません! 非機能要件は可能かどうか検討すること • 非機能要件は実現手段を想定し、 コストパフォーマンスを意識します。 でも、現状と同じでは仕方ありません • 何を変える必要があるのか、見極めましょう!

×