オープンコミュニティ「要求開発アライアンス」(http://www.openthology.org)の2008年10月定例会発表資料です。 Open Community "Requirement Development Alliance" 2008 October regular meeting of the presentation materials.

1. 要求開発とSOAはセットで入れろ
～要求開発ベースのSOA方法論～
株式会社豆蔵 BS事業部
岩崎浩文
1 Copyright 2008 Mamezou. CONFIDENTIAL

2. SOA型システム設計・実装時の
問題点
要求開発とSOAはセットで入れろ
～要求開発ベースのSOA方法論～
2 Copyright 2008 Mamezou. CONFIDENTIAL

3. SOAプロジェクトは「大変な事」になる
可能性が高い
 SOAでありがちな「大変な事」の例
 製品ありきで突っ走って大変な事に
 SOA製品の知識を誰も持っていない状況で楽観視して暴走
 ベンダー主導で製品導入に走ったがその後を誰も考えてなかった
 明確な設計方針無く突っ走って大変な事に
 各サービスの切り方で揉めに揉めてグチャグチャに
 各サービスをバラバラの担当者や企業に発注して大変な事に
 社内調整で時間を使い果たして大変な事に
 部署間にまたがる連携時に各部署間の調整で大揉めに
 エラー発生時の責任所在を巡り社内政治が発生して大喧嘩
 実装技術が低くて大変な事に
 SOAの経験と知識を持つ技術者が揃わず現場は修羅場に
 運用経験ゼロで勘所が分からずサービスイン時に大問題に
3 Copyright 2008 Mamezou. CONFIDENTIAL

4. 何故「大変な事」になるのか?
 設計の根拠が無い、または不明瞭
 すべてのシステムは業務命題を解決するために存在するの
だが・・・そうなっていない?
 業務担当者の思い込みや思い入れでねじ曲げられる仕様
 実装を知らない設計者の、実装できないトンデモ設計
 システム実装側の勝手な理屈でへし折られるまともな設計
 とにかく全ての作業が「繋がってない」事が原因
 これらは全て通常の開発でも起こる問題だが、
多くのシステムにまたがるSOAプロジェクトでは
より濃縮されて問題が露呈しやすい
4 Copyright 2008 Mamezou. CONFIDENTIAL

5. 結局どうすればいいか?
→業務システムにトレーサビリティーを
 業務システム構築のためには、業務命題から設計に繋
がる「根拠」が必要
 何故そうなっているのか、どうしてそうなったのか。積み重なる
コストの要因は全て業務命題に繋がっている必要がある。
 業務からシステムに繋ぐ根拠の導出には、
的確な手法が必要
 企業非依存のオープンスタンダード
「OPENTHOLOGY」の豆蔵版である
「enThology」（エンソロジー）では、
実装時に設計の根拠で揉
統合開発作業に必要な、設計時における めるのは、業務命題に繋
遡及可能性（トレーサビリティー）を がる設計がされてない為
↓
工学的な手法として整備 業務から繋がった客観性
を持つ設計が必要
5 Copyright 2008 Mamezou. CONFIDENTIAL

6. SOAの諸問題に対する
豆蔵の具体的解決支援策
要求開発とSOAはセットで入れろ
～要求開発ベースのSOA方法論～
6 Copyright 2008 Mamezou. CONFIDENTIAL

7. SOA型のシステム統合設計には、
それに対応した定式化された方法が必要
 業務から導き出された要求と、既存システムは、直接繋
がらない現実がある
 シンプルで美しい理想像と、想像以上にスパゲッティー化して
いる既存システム群のギャップは激しい
 イチから全部新規で構築するのであれば容易いが、あくまで
SOAの主眼は「既存システムの統合」
VB6
Java
ホスト
.NET
定式化された方法が無
ければ、担当者によりバ
業務命題から導出された ラツキある品質どころか 現実としての
理想像としての 失敗しかねない 重複の多く泥臭い
仮想単一システム像 複数の既存システム連携設計
7 Copyright 2008 Mamezou. CONFIDENTIAL

8. 豆蔵の具体的解決策の例:
enThology大規模分散システム方法論
 enThologyの中で、インテグレーション（システム連携）分
野のアーキテクチャー設計を担当する方法論
 「戦略的情報化企画」、つまり設計部分での方法論
 ITアーキテクトをメインターゲットとしたもの
 SOAにも対応した汎用的方法論として整備
 オブジェクト指向分析から具体的システム連携まで、
一貫したトレーサビリティーを担保した実践的手法
 既存システムをいかに合理的に繋ぐか、に特化した手法
 情報の構造に着目し、仮想的な「分散システム」として、全体
で整合性を担保する形で設計を行う手法を採用
8 Copyright 2008 Mamezou. CONFIDENTIAL

9. 本方法論の位置づけ
IT投資の局面と活動領域 (ITSS V3)
経営戦略 戦略的情報化企画 開発 運用・保守
策定
IT戦略策定
要求開発 戦略効果評価
はこの辺!
契約の観点
業務要件定義 運用テスト
本方法論
はこの辺!
システム システム適格
要件定義 性確認テスト
ソフトウェア ソフトウェア適
準委任契約 要件定義 格性確認テスト
ソフトウェア ソフトウェア
開発 テスト
請負契約
9 Copyright 2008 Mamezou. CONFIDENTIAL

10. 本方法論の対象読者
本方法論
はこの辺!
ITスキル標準 (ITSS V3)より
10 Copyright 2008 Mamezou. CONFIDENTIAL

11. 付属資料の例:
enThology業務プロセスパターン
 本方法論の追加資料として、業務プロセスのパターン例
集を完備
 OMGにより2003年より定義されているワークフローパターン
を、より具体的なBPMNによる業務例と解説を加える形で整備
 分散システム方法論の中で、システム連携部分にワークフ
ローエンジンを採用する場合、本方法論をそのまま参考にす
ることが可能に
 参考例として、Microsoft .NET Framework 3.5 Windows
Workflow Foundation (WF) による実装例も添付
顧客
航空券予約サービス
予約
結果
申込 航空券を予約する 予約情報
B B B
航空券が不要
ホテル予約サービス
予約
A A A
結果
旅行予約システム
C C C
enThology
クレジットカードの
ホテルを予約する
支払を処理する
申込みを 予約完了を
受け付ける 通知する
OMG Workflow Patterns
ホテルが不要
レンタカー予約サービス
予約
.NET WF例
結果
業務プロセスパターン
レンタカーを予約
する
レンタカーが不要
11 Copyright 2008 Mamezou. CONFIDENTIAL

12. 付属資料の例:
複数プラットフォームのプロトタイプでの検証
 異種混在型統合を前提とした実践的アプローチの為、Java EE
及び.NET Frameworkでのプロトタイプで検証を実施
 WS-BPELやWS-Atomic Transaction、WS-Security等を用いた次世代
統合技術を中心とする
 本検証の資料が添付
▲.NET Framework 3.5版
(WCF + WF + Windows Server 2008
▲Java EE 5版 (JBI + BPEL + Glassfish V2 + DB2 V9.5) + SQL Server 2005)
12 Copyright 2008 Mamezou. CONFIDENTIAL

13. 要求開発とSOAはセットで!
 要求開発から先の話には、
SOAが待っている!
 要求開発が扱う領域は大きい!!
 大きい領域をシステム化する時には、
結局SOAのようなシステム間連携が
登場する事になる
 SOA型システム設計には、
要求開発が必須!
 SOA化する時にいつも「サービスの切
り出し方」が話題になるが、それは要
求開発で業務から開発すべき
 トレーサビリティー担保の為にも、やは
りきちんと上流からやるべきです
13 Copyright 2008 Mamezou. CONFIDENTIAL

14. 株式会社 豆蔵
http://www.mamezou.com
〒163-0434
新宿区西新宿2-1-1新宿三井ビル34F（私書箱302号）
TEL: 03-5339-2114（代表）
FAX: 03-5339-2380
14 Copyright 2008 Mamezou. CONFIDENTIAL