アーキテクチャの発掘に見る要求変化の発見 - 要求開発アライアンス2014年2月定例会

アーキテクチャの発掘にみる
要求変化の発見
グロースエクスパートナーズ株式会社
鈴木雄介
2014/2/27

Copyright© Growth xPartners, Inc. All rights reserved.

自己紹介
• 鈴木雄介
– グロースエクスパートナーズ株式会社執行役員
» ビジネスソリューション事業本部本部長

– 日本Javaユーザーグループ会長
– 日本Springユーザー会幹事
– 要求開発アライアンスは2006年10月以来
» 「要求2.0開発 - 2.0時代の要求を考える」


1

自己紹介
• 要求2.0開発 1/2
– 3つの変化が訪れる
» ユーザーが共同開発者に（中間利用者と中間提供者）
» 初期構築から運用が重要に（プラットフォームとサービス
）
» 一括請負ビジネスからライフサイクルビジネスへ


2

自己紹介
• 要求2.0開発 2/2
– 要求2.0とは
» その要求はインタラクティブである
▸ ビジネスとテクノロジーの対話
▸ 常に変化する

» その要求はビジョンである
▸ 小さくて多様な要求をつなぐグラウンドルール
▸ サスティナブル（持続可能）

» その要求はイノベーティブである
▸ “とりあえず、やってみる”重要
▸ 問題を解決するのではなく、価値を創造する


3

今日のお話
• 背景の共有
– 最近「システムが要求に追いつけないのですが、な
んとかなりませんか？」という相談が多い
» 長年の歴史で保守性が悪化した
» 品質/性能が足りなかった、拡張性がない

– アーキテクチャ点検すると問題が見つかる
» なんで、こんなことが起きるんだろう？

– “要求開発”ではなくて”要求変化の発見”という話を
アーキテクトがしてみます
» あまり結論がある話ではないです…


4

目次
•
•
•
•
•
•

ITサービスとは
アーキテクチャとは
要求の変化とアーキテクチャ
アーキテクチャの発掘
発掘の心構え
まとめ


5

ITサービスを作る


6

• 「ITサービスを作る」とは
影響する

プロセス

構造/構成

提供機能

利用価値

依存する

Inpired by JISX0129-1 ソフトウェア製品の品質第１部品質モデル

7

特徴

例

利用価値

・利用状況によって評価が異な
る

・ユーザーＡさんとユーザー
Ｂさんで評価が異なる

提供機能

・システムの振る舞い
・誰がテストしても同じ結果
・一般的な仕様策定の対象

・テストケース
・外部仕様

構造/構成

・システムを構成している要素
すべて（含ドキュメント）
・後に残り、評価が可能
・エンジニアがこだわるところ

・クラス図
・フレームワーク
・ドキュメント

プロセス

・後に残らない

・コミュニケーション
・


8

ITサービスとは
• 各要素は互いに依存し、影響する
– それらのバランスが崩れると良いITサービスは作れ
ない

• どうやって、それらのバランスを取ればいいの
か？
– プロセスを改善するだけはダメ
– もちろん、要求（≒利用価値）を正しく定義するだ
けでもダメ
» 要求開発アライアンスで話をしていてなんですが

9



10


IEEE-Std-1471-2000 Recommended Practice for Architectural Description of
Software-Intensive Systems（アーキテクチャ記述の推奨プラクティス）

11

ミッション

制約（環境）

システム

ビュー

利害関係者の
関心事

モデルによって記述
ビューポイント
12

• アーキテクチャとは
– システムのミッションに従い、システムのおかれた
制約を前提としながら
– システムに関わる複数の利害関係者の関心事を整合
させ、
» 経営者、オーナー、ユーザー、プログラマ、 DBA、インフ
ラ屋、PM、上司

– ライフサイクル（設計から保守）まで意識した
– システムの分け方と組合せ方のこと


13

• アーキテクチャは各要素を繋ぐもの
– アーキテクチャ設計は各要素の関係を考えること
– 構造/構成は結果であり、目的ではない
» あくまでも利用価値の実現が最大

影響する

プロセス

構造/構成

提供機能

利用価値

依存する

14

• プロジェクトマネジメントとアーキテクチャ
– コンウェイの法則
» アーキテクチャは組織にしたがう
» 組織はアーキテクチャにしたがう

– WBS
» 何をどう作るか
スコープ管理（WBS）
部分
部分

部分を作る

部分

全体

部分を作る

時間管理（スケジュール）

部分を作る


10

5
20

15



16

• リリース直後

プロセス


構造/構成

提供機能

利用価値

17

• 要求は変化する
– 求める価値が異なってくる
– 利用価値が変化することで、必要な機能が変わる

利用価値
プロセス


構造/構成

提供機能

18

• 機能を改善/追加する
– 提供される機能は大きくなる
– それにあわせて構造も変わる
» ただし、当初想定していなければ追加になる

– プロセスは変化できる

利用価値
プロセス


構造/構成

提供機能

19

• いつか限界を迎える
動いていることが謎
機能への不満

不思議な増築

チームへの不信感

使わない
なんでそう作ったんだ

いまどきそれ！？
構造への不満

機能への不満

利用価値
プロセス
なんか使いにくい

客への不満

提供機能
構造/構成

忘れさられた経緯


20



21

• アプリケーションの構造/構成を分析
– するだけではアーキテクチャの発掘にならない

利用価値
プロセス

提供機能
構造/構成


22

• 各要素間の関連性に着目する
– 構造/構成の”常識的な善し悪し”だけで考えない

利用価値
プロセス

提供機能
構造/構成


23

• 特に要求（利用価値）の変化を”想像する”
– 過去の経緯は聞かないと教えてくれない

利用価値

構造/構成


利用価値

24

• どうやって発掘するのか
– 動的構造と静的構造の把握
» 振る舞い図
▸ アクティビティ図、シーケンス図
▸ データフローダイアグラム

» 構造図
▸ 配置図、コンポーネント図
▸ データモデリング
▸ ※クラス図を書くことはめったにない


25

• 構造の把握
– 動的構造と静的構造を掛け合わせながら詳細化して
いくのが王道
» レイヤーや粒度を整合させて段階的に落とし込む

処理
行動


処理
行動

26

• 発掘のコツ
– 粒度
» ユースケース実践ガイドを読んでください
全体概要
ビジネスシナリオ
ユーザー視点（≒コーヒーブレイクテスト）
画面の操作
内部処理ロジック

» ホットスポットは細かくて言い
▸ 濃淡を意識することは大事

27

• 発掘のコツ
– レイヤー
» インフラ
▸ センター/拠点（場所）
▸ ネットワーク（回線、装置、セグメント、仮想）
▸ サーバ（物理と仮想/WinとLinux）

» アプリケーション
▸ ミドルウェア（サーバ、DB、その他）
▸ アプリ（オンライン、バッチ）

» オペレーション
▸ 業務（人間、他シス）
▸ 出力（画面、帳票、データ）

28

発掘の心構え


29

発掘の心構え
• 「あー、ダメなアーキテクチャですね」
– でも、過去と経緯に敬意を払うこと
» そのときのベストな答（たとえ無知であったとしても）
» 判断は外側からやってくる
» 罪を憎んで人を憎まず

• 「じゃ、作り直しましょう」
– とは言えない
» サービスは継続する
» いますぐ改善しないとマズイ

30

発掘の心構え
• 要求とアーキテクチャの関係性を考える
– 要求が間違っていた、というよりも正しく変化した
– もしくは、要求と構造/構成がマッチしていなかった
» アーキテクチャ設計の不備だと思う
» 要求とITサービスの距離が埋まっていない


31

まとめ


32

まとめ
• 「ITサービスを作ること」を要素分解する
– 利用価値
– 提供機能
– 構造/構成
– プロセス

• アーキテクチャは各要素のバランスのこと
– アーキテクチャ設計は各要素のバランスをとること


33

まとめ
• 運用が始まって要求が変化するとアーキテクチ
ャは「歪む」
• アーキテクチャの歪みを捉えていく
– 静的構造と動的構造
– 基点となった要求の変化を想像し、理解する

• 要求とアーキテクチャの関係を正しく理解する
ことが良いITサービスにつながる


34

アーキテクチャの発掘に見る要求変化の発見 - 要求開発アライアンス2014年2月定例会

More Related Content

What's hot

Viewers also liked

Similar to アーキテクチャの発掘に見る要求変化の発見 - 要求開発アライアンス2014年2月定例会

More from Yusuke Suzuki

Recently uploaded

アーキテクチャの発掘に見る要求変化の発見 - 要求開発アライアンス2014年2月定例会