1月25日　要求開発アライアンスでお話させていただいた内容です。

1. 要求開発を補完する現状分析
株式会社ビッグツリーテクノロジー＆コンサルティング
高安 厚思
1Copyright (C) 2016 Atsushi Takayasu All Rights Reserved.

2. 1 2 3 4 5アジェンダ
▌自己紹介
▌1 はじめに
▌2 システム分析
▌3 アーキテクチャ分析
▌4 終わりに
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 2

3. 1 2 3 4 5
■社名
株式会社ビッグツリーテクノロジー＆コンサルティング
■所在地
【東京オフィス】〒106-0041 東京都港区麻布台2-3-5 ノアビル3階
TEL： 03-5114-6171（代表） FAX： 03-5114-6172
【札幌オフィス】〒060-0001 北海道札幌市中央区北1条西3-3 札幌プラザビル4F
TEL： 011-206-1914
■設立
2002年2月7日
■資本金
8800万円
■役員
代表取締役社長／杉山 健
取締役／巻口 祐樹、水本 健太郎、鵜飼 一夫、村武 真后、中川 卓、森田 正樹
■事業内容
・ソフトウェア開発およびソフトウェア開発のコンサルティング
・Webコンテンツ開発およびWebコンテンツ開発のコンサルティング
・ITエンジニアリソース事業（人材派遣サービス）
・上記に付帯する一切の事業
■各種認証
・ISMS資格 ISO(JISQ)27001 （認証番号：IS 505446）
・Oracle認定Webコンポーネントディベロッパ 保有者所属企業
・VMware認定 ソリューションプロバイダ
会社概要

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

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

6. 1 はじめに
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 6

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

8. 1 2 3 4 5対象となる領域
▌領域を新規・リプレースという軸と組織のシステム全体とひとつのシ
ステムという軸のマトリックスで分類してみます。
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 8
新
規
リ
プ
レ
ー
ス
全体 1システム
コンサルティング
領域
要求開発 領域
現状分析 領域
経営計画
システム化計画
全体アーキテクチャ
概念ビジネスモデル
ビジネス要求リスト
ビジネス ToBe モデル
概観ビジネスモデル
IT 基本要求ﾘｽﾄ(デザイン)
システム基本構想書
システム移行計画書
現行業務課題の背景
業務移行方針
データ辞書（データ分類）
アプリケーション構成図

9. 1 2 3 4 5リファレンスモデルの代表例
▌リファレンスモデルとして、参考としていくつかご紹介します。
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 9
Enterprise
Architecture
DMBoK
TOGAF ADM

10. 2 システムの分析
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 10

11. 1 2 3 4 5業務
▌対象システムを超えて、業務の位置づけを把握（判断材料）
▌業務移行を意識して、業務内容を把握
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 11
全体システム化計画（最適化計画）での
課題認識
業務体系の確認
対象業務の詳細化（経営・管理・OP）
業務移行

12. 1 2 3 4 5データ
▌システム現状分析の要となる調査・分析
▌業務の視点とアプリの視点の双方が必要となり、
これらをインクリメンタルに実施
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved 12
業務をデータの流れで追っていく
現行データの分析を実施 詳細は次頁
データ分類の明確化
データ辞書の確認（作成）

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

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

15. 3 アーキテクチャ分析
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 15

16. 1 2 3 4 5アーキテクチャとは
▌アーキテクチャは複雑であり、整理が重要
▌本日の視点はシステムアーキテクチャ
Copyright (C) 2016 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) 2016 Atsushi Takayasu All Rights Reserved. 18
可用性
運用方針（監視・バックアップ）
セキュリティ
オンラインとバッチの処理方針
（データ連携の方針）

19. 1 2 3 4 5性能はデータから判断
▌現行システムの性能情報は必ず取得しましょう。
▌取得方法はいろいろあります！
▌平均値とピーク時の値を元に、将来値を考慮します。
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 19
CPU、メモリ使用率
IOPS、IOスループット
ネットワークスループット
イベントリ情報

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

21. 1 2 3 4 5基盤と個別システム
▌非機能要件とは別の視点として、個別システムで機能をもたない方が効率
が高い場合に複数システムから利用される基盤を用いることがあります。
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 21
 文字情報基盤
 認証基盤
 承認フロー（ワークフロー基盤）
 JOB実行基盤
 インフラ統合基盤
 データ統合基盤（MDMやデータ配信基盤）
 システム連携基盤
 帳票基盤
 情報基盤（ポータル等）
 システム管理基盤（構成管理、インシデント管理、サービスデスク管
理など）
 運用基盤（監視、性能分析など）

22. 4 終わりに
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 22

23. 1 2 3 4 5現状分析の重要性は移行にあり
▌移行は重要でありながら、クローズアップされることが少なく、知識
の蓄積も少ない分野です。
Copyright (C) 2016 Atsushi Takayasu All Rights Reserved. 23
http://blogs.itmedia.co.jp/magic/2011/03/itps-5487.html

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

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