要求変化対応と安心・安全 （BRMS 2/2）
システムの複雑さは信頼性を低下させる
ルール処理モジュール
第3階層 第2階層
第1階層 ルール１
要求変化対応ソフトウェア・アーキテクチャ （マイクロサービス 1/２）
<出典> James Lewis: Microservices, ThoughtWorks, 25 March 2014.
http://martinfowler.com/articles/microservices.html
複数の小さな“サービス”を組み合わせて アプリケーションを構築
各サービスは独立にデプロイされ，疎結 合で独立動作．
従来の“モノリシック”タイプ マイクロサービス
要求変化対応ソフトウェア・アーキテクチャ （マイクロサービス 1/２）
俊敏な変更が可能
独立チームで特徴を活かす
＜課題＞
不得手な制御もある
トラブル時の対応に配慮要
開発・運用の効率化のための支援環境が重要 マイクロサービスの特徴
必要なサービスのみ，変更・置換
他のサービスへの影響の考慮不要
制約が少なく，工夫・挑戦する意識の高まり
責任の明確化
サービス 3 サービス
2
サービス 1
サービス 5 サービス
4
軽量な，標準 インタフェース 置換対象
★アジャイル文化への組織の転換はタフなこと
アジャイル文化への組織の転換
（Agile transformation）
多くの組織，チーム，個人にとって，アジャイル開発プロセスへの転換は
“挑戦的”である．それは，ある種の文化的変革を必要とするからだ．
［Agile transformation, ＩＢＭ］
アジャイルは，プロセスではなく文化である．
Michael Sahota: “An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture,” 2012.
http://www.ibm.com/smarterplanet/us/en/business_analytics/article/agiledevelopment.html
53%
42%
35% 33%
30% 28%
23%
13% 13%
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
50%
組 織 文 化 の 変 化 能 力
変 化 へ の 一 般 的 な 抵 抗
ア ジ ャ イ ル 経 験 者 不 足
マ ネ ジ メ ン ト の 支 援
プ ロ ジ ェ ク ト の 複 雑 さ ･ 規 模
顧 客 の 協 力
規 模 拡 大 へ の 対 応 の 自 信
移 行 ま で に 許 さ れ る 時 間
予 算 の 制 約
（VersionOne社 アジャイル開発の現状調査第8回2014より）
55%
25%
13%
ＷＦ フレ ーム ワー クへ のア ジャ イル の整 合
特 に な し
１．組織文化の変化能力 ２．変化への一般的な抵抗
３．WFフレームワークへのアジャイルの整合
→前回調査と同傾向
アジャイル開発手法の導入拡大の障壁 （海外）
参考データ
44%
34% 32%
35%
29%
24%
15%
22%
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
50%
組 織 文 化 の 変 化 能 力
ア ジ ャ イ ル 経 験 者 不 足
マ ネ ジ メ ン ト の 支 援
顧 客 の 協 力
規 模 拡 大 へ の 対 応 の 自 信 特
に な し 変
化 へ の 一 般 的 な 抵
抗
（VersionOne社 アジャイル開発の現状調査第9回2015より）
55%
23%
16%
ＷＦ フレ ーム ワー クへ のア ジャ イル の整 合
アジャイル開発手法の導入拡大の障壁 （海外）
参考データ
上 流 での 計 画 不 足 への 管 理 上 の懸 念
経 営 管 理 の浪 費 に関 する 懸 念
１．組織文化の変化能力はトップ変わらず ２．経験者不足が上位に
３．新規２項目追加：
・上流での計画不足への管理上の懸念
・経営管理の浪費に関する懸念
42%
37%
6%
30%
0%
10%
20%
30%
40%
企 業 哲 学 又 は 文 化 と の 相 性 手
法 へ の 不 慣 れ
従 来 型 開 発 採 用 へ の 外 部 圧 力
チ ー ム 内 で の 反 発 文
化 的 な 移 行 の 欠 如 マ ネ
ジ メ ン ト の 支 援 の 欠 如
不 十 分 な ト レ ー ニ ン グ 44%
（VersionOne社 アジャイル開発の現状調査第9回2015より）
36% 33%
そ の 他
・ 分 か ら な い 組
織 管 理
・ コ ミ ュ ニ ケ ー シ ョ ン 上 の 問 題
33%
38%
50% 「手法への不慣れ」がさらに２ランクアップ トップに！
「マネジメントの支援 の欠如」も大幅(6ラ ンク)アップ
参考データ（再掲）
アジャイル型開発プロジェクトの失敗理由 （海外）
継続的に
上位に
位置する
★彼を知り己を知れば百戦殆うからず
ソフトウェア開発においては，
開発対象と組織・プロジェクトの特徴に応じた 適切な形態・手法の選択が重要
彼を知り己を知れば百戦殆うからず(孫子)
失敗しません！
変わる 変える
アジャイル開発に関する IPA/SEC の検討結果等は：
http://www.ipa.go.jp/sec/softwareengineering/std/ent02-c.html
ご清聴，ありがとう
ございました
補足情報
アジャイル宣言における4つの価値
アジャイル宣言（Agile Manifesto）
アジャイルな開発手法の提唱者17名が集まり，2001年に発表．
http://agilemanifesto.org/iso/ja/manifesto.html
私たちは，ソフトウェア開発の実践を手助けする活動を通じて，
よりよい開発方法を見つけだそうとしている．
この活動を通して，私たちは以下のことを重視する：
①プロセスやツールよりも，個人と対話を
②包括的なドキュメントよりも，動くソフトウェアを
③契約交渉よりも，顧客との協調を
④計画に従うことよりも，変化への対応を
すなわち，①～④の各文の前者（「よりも」の前の言葉）に価値 があることを認めながらも，私たちは後者（「よりも」の後の言葉）
の事柄により価値をおく．
参考
アジャイル宣言の背後にある12の原則
私たちは以下の原則に従う。
①顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する。
②要求の変更はたとえ開発の後期であっても歓迎する。
変化を味方につけることによって、顧客の競争力を引き上げる。
③動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースする。
④ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働く。
⑤意欲に満ちた人々を集めてプロジェクトを構成する。
環境と支援を与え仕事が無事終わるまで彼らを信頼する。
⑥情報を伝える最も効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることである。
⑦動くソフトウェアこそが進捗の最も重要な尺度である。
⑧アジャイル･プロセスは持続可能な開発を促進する。
一定のペースを継続的に維持できるようにしなければならない。
⑨技術的卓越性と優れた設計に対する不断の注意が機敏さを高める。
⑩シンプルさ（ムダなく作れる量を最大限にすること）が本質である。
⑪最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出される。
⑫チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たち のやり方を最適に調整する。
参考
↙ 安
ドキュメント内
プロローグ ビジネスを取り巻く状況と IT 2
(ページ 104-116)