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

8,280 views

Published on

要求開発アライアンスの2014年2月定例会(2014/2/27)での講演「アーキテクチャの発掘にみる要求変化の発見」の資料です。
http://redajp.doorkeeper.jp/events/8825

Published in: Technology
0 Comments
22 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,280
On SlideShare
0
From Embeds
0
Number of Embeds
4,593
Actions
Shares
0
Downloads
46
Comments
0
Likes
22
Embeds 0
No embeds

No notes for slide

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

  1. 1. アーキテクチャの発掘にみる 要求変化の発見 グロースエクスパートナーズ株式会社 鈴木 雄介 2014/2/27 Copyright© Growth xPartners, Inc. All rights reserved.
  2. 2. 自己紹介 • 鈴木雄介 – グロースエクスパートナーズ株式会社 執行役員 » ビジネスソリューション事業本部 本部長 – 日本Javaユーザーグループ 会長 – 日本Springユーザー会 幹事 – 要求開発アライアンスは2006年10月以来 » 「要求2.0開発 - 2.0時代の要求を考える」 Copyright© Growth xPartners, Inc. All rights reserved. 1
  3. 3. 自己紹介 • 要求2.0開発 1/2 – 3つの変化が訪れる » ユーザーが共同開発者に(中間利用者と中間提供者) » 初期構築から運用が重要に(プラットフォームとサービス ) » 一括請負ビジネスからライフサイクルビジネスへ Copyright© Growth xPartners, Inc. All rights reserved. 2
  4. 4. 自己紹介 • 要求2.0開発 2/2 – 要求2.0とは » その要求はインタラクティブである ▸ ビジネスとテクノロジーの対話 ▸ 常に変化する » その要求はビジョンである ▸ 小さくて多様な要求をつなぐグラウンドルール ▸ サスティナブル(持続可能) » その要求はイノベーティブである ▸ “とりあえず、やってみる”重要 ▸ 問題を解決するのではなく、価値を創造する Copyright© Growth xPartners, Inc. All rights reserved. 3
  5. 5. 今日のお話 • 背景の共有 – 最近「システムが要求に追いつけないのですが、な んとかなりませんか?」という相談が多い » 長年の歴史で保守性が悪化した » 品質/性能が足りなかった、拡張性がない – アーキテクチャ点検すると問題が見つかる » なんで、こんなことが起きるんだろう? – “要求開発”ではなくて”要求変化の発見”という話を アーキテクトがしてみます » あまり結論がある話ではないです… Copyright© Growth xPartners, Inc. All rights reserved. 4
  6. 6. 目次 • • • • • • ITサービスとは アーキテクチャとは 要求の変化とアーキテクチャ アーキテクチャの発掘 発掘の心構え まとめ Copyright© Growth xPartners, Inc. All rights reserved. 5
  7. 7. ITサービスを作る Copyright© Growth xPartners, Inc. All rights reserved. 6
  8. 8. ITサービスを作る • 「ITサービスを作る」とは 影響する プロセス 構造/構成 提供機能 利用価値 依存する Inpired by JISX0129-1 ソフトウェア製品の品質 第1部 品質モデル Copyright© Growth xPartners, Inc. All rights reserved. 7
  9. 9. ITサービスを作る 特徴 例 利用価値 ・利用状況によって評価が異な る ・ユーザーAさんとユーザー Bさんで評価が異なる 提供機能 ・システムの振る舞い ・誰がテストしても同じ結果 ・一般的な仕様策定の対象 ・テストケース ・外部仕様 構造/構成 ・システムを構成している要素 すべて(含ドキュメント) ・後に残り、評価が可能 ・エンジニアがこだわるところ ・クラス図 ・フレームワーク ・ドキュメント プロセス ・後に残らない ・コミュニケーション ・ Copyright© Growth xPartners, Inc. All rights reserved. 8
  10. 10. ITサービスとは • 各要素は互いに依存し、影響する – それらのバランスが崩れると良いITサービスは作れ ない • どうやって、それらのバランスを取ればいいの か? – プロセスを改善するだけはダメ – もちろん、要求(≒利用価値)を正しく定義するだ けでもダメ » 要求開発アライアンスで話をしていてなんですが Copyright© Growth xPartners, Inc. All rights reserved. 9
  11. 11. アーキテクチャとは Copyright© Growth xPartners, Inc. All rights reserved. 10
  12. 12. アーキテクチャとは IEEE-Std-1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems(アーキテクチャ記述の推奨プラクティス) Copyright© Growth xPartners, Inc. All rights reserved. 11
  13. 13. アーキテクチャとは ミッション 制約(環境) システム ビュー 利害関係者の 関心事 Copyright© Growth xPartners, Inc. All rights reserved. モデルによって記述 ビューポイント 12
  14. 14. アーキテクチャとは • アーキテクチャとは – システムのミッションに従い、システムのおかれた 制約を前提としながら – システムに関わる複数の利害関係者の関心事を整合 させ、 » 経営者、オーナー、ユーザー、プログラマ、 DBA、インフ ラ屋、PM、上司 – ライフサイクル(設計から保守)まで意識した – システムの分け方と組合せ方のこと Copyright© Growth xPartners, Inc. All rights reserved. 13
  15. 15. アーキテクチャとは • アーキテクチャは各要素を繋ぐもの – アーキテクチャ設計は各要素の関係を考えること – 構造/構成は結果であり、目的ではない » あくまでも利用価値の実現が最大 影響する プロセス 構造/構成 提供機能 利用価値 依存する Copyright© Growth xPartners, Inc. All rights reserved. 14
  16. 16. アーキテクチャとは • プロジェクトマネジメントとアーキテクチャ – コンウェイの法則 » アーキテクチャは組織にしたがう » 組織はアーキテクチャにしたがう – WBS » 何をどう作るか スコープ管理(WBS) 部分 部分 部分を作る 部分 全体 部分を作る 時間管理(スケジュール) 部分を作る Copyright© Growth xPartners, Inc. All rights reserved. 10 5 20 15
  17. 17. 要求の変化とアーキテクチャ Copyright© Growth xPartners, Inc. All rights reserved. 16
  18. 18. 要求の変化とアーキテクチャ • リリース直後 プロセス Copyright© Growth xPartners, Inc. All rights reserved. 構造/構成 提供機能 利用価値 17
  19. 19. 要求の変化とアーキテクチャ • 要求は変化する – 求める価値が異なってくる – 利用価値が変化することで、必要な機能が変わる 利用価値 プロセス Copyright© Growth xPartners, Inc. All rights reserved. 構造/構成 提供機能 18
  20. 20. 要求の変化とアーキテクチャ • 機能を改善/追加する – 提供される機能は大きくなる – それにあわせて構造も変わる » ただし、当初想定していなければ追加になる – プロセスは変化できる 利用価値 プロセス Copyright© Growth xPartners, Inc. All rights reserved. 構造/構成 提供機能 19
  21. 21. 要求の変化とアーキテクチャ • いつか限界を迎える 動いていることが謎 機能への不満 不思議な増築 チームへの不信感 使わない なんでそう作ったんだ いまどきそれ!? 構造への不満 機能への不満 利用価値 プロセス なんか使いにくい 客への不満 提供機能 構造/構成 忘れさられた経緯 Copyright© Growth xPartners, Inc. All rights reserved. 20
  22. 22. アーキテクチャの発掘 Copyright© Growth xPartners, Inc. All rights reserved. 21
  23. 23. アーキテクチャの発掘 • アプリケーションの構造/構成を分析 – するだけではアーキテクチャの発掘にならない 利用価値 プロセス 提供機能 構造/構成 Copyright© Growth xPartners, Inc. All rights reserved. 22
  24. 24. アーキテクチャの発掘 • 各要素間の関連性に着目する – 構造/構成の”常識的な善し悪し”だけで考えない 利用価値 プロセス 提供機能 構造/構成 Copyright© Growth xPartners, Inc. All rights reserved. 23
  25. 25. アーキテクチャの発掘 • 特に要求(利用価値)の変化を”想像する” – 過去の経緯は聞かないと教えてくれない 利用価値 構造/構成 Copyright© Growth xPartners, Inc. All rights reserved. 利用価値 24
  26. 26. アーキテクチャの発掘 • どうやって発掘するのか – 動的構造と静的構造の把握 » 振る舞い図 ▸ アクティビティ図、シーケンス図 ▸ データフローダイアグラム » 構造図 ▸ 配置図、コンポーネント図 ▸ データモデリング ▸ ※クラス図を書くことはめったにない Copyright© Growth xPartners, Inc. All rights reserved. 25
  27. 27. アーキテクチャの発掘 • 構造の把握 – 動的構造と静的構造を掛け合わせながら詳細化して いくのが王道 » レイヤーや粒度を整合させて段階的に落とし込む 処理 行動 Copyright© Growth xPartners, Inc. All rights reserved. 処理 行動 26
  28. 28. アーキテクチャの発掘 • 発掘のコツ – 粒度 » ユースケース実践ガイドを読んでください 全体概要 ビジネスシナリオ ユーザー視点(≒コーヒーブレイクテスト) 画面の操作 内部処理ロジック » ホットスポットは細かくて言い ▸ 濃淡を意識することは大事 Copyright© Growth xPartners, Inc. All rights reserved. 27
  29. 29. アーキテクチャの発掘 • 発掘のコツ – レイヤー » インフラ ▸ センター/拠点(場所) ▸ ネットワーク(回線、装置、セグメント、仮想) ▸ サーバ(物理と仮想/WinとLinux) » アプリケーション ▸ ミドルウェア(サーバ、DB、その他) ▸ アプリ(オンライン、バッチ) » オペレーション ▸ 業務(人間、他シス) ▸ 出力(画面、帳票、データ) Copyright© Growth xPartners, Inc. All rights reserved. 28
  30. 30. 発掘の心構え Copyright© Growth xPartners, Inc. All rights reserved. 29
  31. 31. 発掘の心構え • 「あー、ダメなアーキテクチャですね」 – でも、過去と経緯に敬意を払うこと » そのときのベストな答(たとえ無知であったとしても) » 判断は外側からやってくる » 罪を憎んで人を憎まず • 「じゃ、作り直しましょう」 – とは言えない » サービスは継続する » いますぐ改善しないとマズイ Copyright© Growth xPartners, Inc. All rights reserved. 30
  32. 32. 発掘の心構え • 要求とアーキテクチャの関係性を考える – 要求が間違っていた、というよりも正しく変化した – もしくは、要求と構造/構成がマッチしていなかった » アーキテクチャ設計の不備だと思う » 要求とITサービスの距離が埋まっていない Copyright© Growth xPartners, Inc. All rights reserved. 31
  33. 33. まとめ Copyright© Growth xPartners, Inc. All rights reserved. 32
  34. 34. まとめ • 「ITサービスを作ること」を要素分解する – 利用価値 – 提供機能 – 構造/構成 – プロセス • アーキテクチャは各要素のバランスのこと – アーキテクチャ設計は各要素のバランスをとること Copyright© Growth xPartners, Inc. All rights reserved. 33
  35. 35. まとめ • 運用が始まって要求が変化するとアーキテクチ ャは「歪む」 • アーキテクチャの歪みを捉えていく – 静的構造と動的構造 – 基点となった要求の変化を想像し、理解する • 要求とアーキテクチャの関係を正しく理解する ことが良いITサービスにつながる Copyright© Growth xPartners, Inc. All rights reserved. 34

×