アーキテクチャと要件定義の隙間 - QCon Tokyo · 2014-04-23 · 開発方法論、アーキテクチャ設計コンサルティング、システム全体設計を得

アーキテクチャと要件定義の隙間

〜現状分析から得られること〜

1 Copyright (C) 2013 Atsushi Takayasu All Rights Reserved.

1 2 3 4 5 アジェンダ

▌自己紹介

▌1 はじめに

▌2 システム分析

▌3 アーキテクチャ分析

▌4 終わりに

Copyright (C) 2013 Atsushi Takayasu All Rights Reserved. 2

1 2 3 4 5 自己紹介

高安厚思

▌活動領域・キーワード ▌２０年にわたり、ソフトウエアエンジニアリングを適用したシステム開発やコンサルティングに携わる。

▌最新技術を適切に利用した、柔軟なシステム構成の構築、品質管理を中心として技術マネージメントなどを主要テーマとして活動。

▌開発方法論、アーキテクチャ設計コンサルティング、システム全体設計を得意分野とする。

▌東京電機大学非常勤講師、SQuBOK設計開発領域検討委員。

▌資格 ▌ネットワークスペシャリスト

▌アプリケーションエンジニア（現システムアーキテクト）

▌プロジェクトマネージャ

▌ ITストラテジスト

▌MCSE

▌MCSD

▌VSP/VSTP


1 2 3 4 5 対外活動

最近の著書、訳書

▌「システム設計の謎を解く（ソフトバンク）」

▌「StrutsによるWebアプリケーションスーパーサンプル（ソフトバンク）」

▌「Seasar入門[（ソフトバンク）」

▌「Javaルールブック（エクスメディア）

▌「ITアーキテクトのためのシステム設計実践ガイドアーキテクチャ編（日経BP）」など。

連載記事執筆

▌日経SYSTEMS誌「Webアーキテクチャ再入門」

講演

▌SODEC ミッションクリティカル開発

▌日本テクノセンターセミナー

▌UML Forum

▌日経BP社 ITアーキテクトのためのシステム設計フォーラム特別講演

▌Developers Summit 2013 Summer


1 はじめに


1 2 3 4 5 今回の位置付け

▌今日の話は、現行システムからのリプレイスにおいて、死角になりがちな内容について触れていきます。

▌新しい業務については重要ですが、今回お話する内容の対象外です！


要件定義

その他

現状分析

要求開発

1 2 3 4 5 本日の話の背景

▌要件定義は決められたことを元に思考するのではありません

▌いわゆるWhatを定義するため、背景にある方針や思考を意識する必要があります。


常に価値を意識する

• 価値基準の明確化

仮説検証型の思考

• 差分を確認する

モデルの利用

• 網羅的な遂行に必要な道具

理想と現実のバランス

• 事実に立脚すること

1 2 3 4 5 リファレンスモデルの代表例

▌リファレンスモデルとして、参考としていくつかご紹介します。


Enterprise Architecture

DMBoK

TOGAF ADM

1 2 3 4 5 参考）Enterprise Architecture

▌http://www.meti.go.jp/policy/it_policy/itasociate/EA3.ppt 「Enterprise Architectureについて」p41より引用


業績測定参照モデル

（Business Reference Model )

政策・業務参照モデル

（Performance Reference Model )

(Data Reference Model)

(Technical Reference Model ) 技術参照モデル

データ参照モデル

サービスコンポーネント参照モデル (Service Component Reference Model )

データ体系

技術体系（Technology Architecture）

適用処理体系

（Data Architecture）

政策・業務体系（Business Architecture）

（Application Architecture）

http://www.meti.go.jp/policy/it_policy/itasociate/EA3.ppt



2 システムの分析

EAの視点から


1 2 3 4 5 業務

▌対象システムを超えて、業務の位置づけを把握（判断材料）

▌業務移行を意識して、業務内容を把握


全体システム化計画（最適化計画）での課題認識

業務体系の確認

業務の位置付け

業務移行

1 2 3 4 5 データ

▌システム現状分析の要となる調査・分析

▌業務の視点とアプリの視点の双方が必要となり、これらをインクリメンタルに実施

Copyright (C) 2013 Atsushi Takayasu All Rights Reserved 12

業務をデータの流れで追っていく

現行データの分析を実施

データ分類の明確化

データ辞書の確認（作成）

1 2 3 4 5 アプリケーション

▌アプリケーションの分析は新システムのアプリケーション構造の参考となる

▌課題はアプリケーションに埋め込まれていることも多い

▌データ分類ごとのロジックを確認

Copyright (C) 2013 Atsushi Takayasu All Rights Reserved 13

アプリケーション間の関係を把握

アプリケーションの構造を把握

IOの確認

ロジックの分析

課題の原因を確認

3 アーキテクチャ


1 2 3 4 5 アーキテクチャとは

▌アーキテクチャは複雑であり、整理が重要

▌本日の視点はシステムアーキテクチャ


http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory05/softfactory05_01.html から引用

http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory05/softfactory05_01.html

http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory05/softfactory05_01.html

1 2 3 4 5 システムアーキテクチャ

▌システムアーキテクチャとして、把握すべき内容は以下の4つ

▌これらを非機能要件の視点から把握


ネットワーク

•システム間の関係

ストレージ

•データの格納領域

• IO性能値

サーバ

•構成

•性能

• OS

ソフトウェア

•ミドルウェア •アプリケーション

1 2 3 4 5 これらから読み取ること

▌現行のシステムが構成された背景を推測します。もちろん、非機能要件定義書があれば確認をします。

▌現行で想定されているサービスレベルや非機能要件が推測できます。


可用性

運用方針（監視・バックアップ）

セキュリティ

オンラインとバッチの処理方針

1 2 3 4 5 性能はデータから判断

▌現行システムの性能情報は必ず取得しましょう。

▌取得方法はいろいろあります！

▌平均値とピーク時の値を元に、将来値を考慮します。


CPU、メモリ使用率

IOPS、IOスループット

ネットワークスループット

イベントリ情報

1 2 3 4 5 非機能要件のとりまとめ

▌現行情報と課題から、非機能要件をまとめる

▌対応すべき内容とコスト試算から適切な要件に落としこむ


非機能要件の確定

非機能要件の調整想定ソリューション

非機能要件整理

非機能要件と課題予算

現行要件

非機能要件定義書

システム分析アーキテクチャ

分析

4 終わりに


1 2 3 4 5 蛇足）現実問題としての移行

▌移行は、必ず存在します。新システムだけでなく、現行システムを知っておかないと破綻します。


業務移行

• 新システム業務フロー

• 新システム運用フロー

システム移行

• システム切替

• 段階的切替

• 切戻

データ移行

• 新旧マッピング

• クレンジング

• データ作成

• 更新停止・差分更新

1 2 3 4 5 今日お伝えしたかったこと！

▌今日お伝えしたかったのは以下の3つです。


現状分析は重要です

• すべてヒアリングで確認することはできません！

非機能要件は可能かどうか検討すること

• 非機能要件は実現手段を想定し、コストパフォーマンスを意識します。

でも、現状と同じでは仕方ありません

• 何を変える必要があるのか、見極めましょう！

Documents

アーキテクチャと要件定義の隙間 - QCon Tokyo · 2014-04-23 · 開発方法論、アーキテクチャ設計コンサルティング、システム全体設計を得