FIT2020 第19回情報科学技術フォーラム（2020年9月3日） イベント企画「DXを推進する俊敏なシステム開発・運用─アジャイルにつなぐビジネスとICT ～デジタルプラクティスライブ～」 【概要】 エンタープライズ領域においてデジタルトランスフォーメーション（以下DX）と言われるようなビジネスモデルの変化に合わせ、システム開発にアジャイル開発プロセスを導入する取り組みが増えている。しかし、実際に導入しても高いビジネス成果をあげることは容易ではない。本稿ではシステム開発手法を組織の意思決定プロセスと捉え、エンタープライズ領域におけるアジャイル開発の課題を論じる。また事例をあげて、この解決に向けた取り組みを紹介する。

1. エンタプライズ領域のアジャイル開発の課題
2020/9/3
グロース・アーキテクチャ＆チームス株式会社
代表取締役社⻑
鈴⽊雄介
FIT2020 第19回情報科学技術フォーラム
DXを推進する俊敏なシステム開発・運⽤─アジャイルにつなぐビジネスとICT
〜デジタルプラクティスライブ〜

2. ⾃⼰紹介
鈴⽊雄介
• グロース・アーキテクチャ＆チームス（株）
» 略称︓Graat（グラーツ）
» 代表取締役社⻑
» https://www.graat.co.jp
» クラウドマイグレーション、マイクロサービス、ア
ジャイルコーチ
• ⽇本Javaユーザーグループ
» サブリーダー/CCC運営委員⻑
• @yusuke_arclamp
1

3. はじめに
本講演資料は以下の論⽂のダイジェストです。詳細について
は論⽂を確認ください。
デジタルプラクティス Vol.11 No.2(Apr. 2020)
https://www.ipsj.or.jp/dp/contents/publication/42/S1102-index.html
エンタープライズ領域のアジャイル開発の課題
─アジャイル開発がもたらす意思決定プロセスの変化─
https://www.ipsj.or.jp/dp/contents/publication/42/S1102-S06.html
2

4. アジェンダ
• エンタープライズアジャイルとは
• 課題
• 導⼊パターン
• 事例
• まとめ
3

5. エンタープライズアジャイルとは
4

6. エンタープライズアジャイルとは
• ウォーターフォール開発プロセスを主に実施している組織
において実施されるアジャイル開発プロセスのこと
▸本講演での定義であり、広く知られた定義ではない
»組織および従業員の思考や⾏動がウォーターフォール開発プロセ
スに適応している状況でアジャイル開発を実施すると、思考や⾏
動とのギャップが⼤きく、関係者間に認識齟齬が⽣まれやすい
5

7. 課題
6

8. アジャイルとウォーターフォール
マネジメントプロセスとしての違い
• ウォーターフォール開発プロセス
»⻑期的な計画を⽴案→開発チーム内で進捗確認→差異を調整
»計画主導。当初のスコープを実現するために⽇程や要員を調整
• アジャイル開発プロセス
»短期＆定期に計画⽴案→関係者全員でレビュー→次の計画⽴案
»調整主導。期間と要員を固定化し、定期的にスコープを決める
7

9. アジャイルとウォーターフォール
ウォーターフォール的思考
• ウォーターフォール開発で⾏うこと
»作るべき機能と期間を決めて、凛議を通して、予算を確保
»その機能（品質）と期間と予算を達成する
• 最初に「開発すべき機能」を決定する
»その決定を達成するために計画し、実⾏する
▸途中の計画変更は、あくまでも最初の決定を守るため
»⽬的︓そのシステム開発を成功させる
8

10. アジャイルとウォーターフォール
アジャイル的思考
• アジャイル開発を実施した企業によるアンケート結果
»優先順位の変更を管理する機能 69%
»プロジェクトの可視性 65%
»ビジネスとITの⾜並みを揃える 64%
• ビジネスの状況にあわせて「開発すべき機能」を決定する
»アジャイルではビジネスとシステム機能の関係性を管理しやすい
»⽬的︓ビジネスの変化に適応する
9
出典 CollabNet VersionOne編 : 13th Annual State of Agile Report.
https://stateofagile.com/

11. エンタープライズアジャイル開発の課題
思考の違いからくる⾏動の違い
• 例︓「AIを使った需要予測」を開発すると決定
»作業を進めたら「予測精度を実現するデータがない」ことが判明
»ウォーターフォール的思考: (精度が低くても)当初の機能を作る
べきだ（凛議も決裁済みだし... ）
»アジャイル的思考: 精度が低ければビジネス的な価値がない。何
か他に需要予測するアプローチに変えよう
10

12. エンタープライズアジャイル開発の課題
考え⽅の違いが課題となる
• ウォーターフォール的思考の組織は、最初の決定を遵守す
る意識が⾮常に⾼い
• アジャイル開発プロセス＆的思考は、最初の決定にはこだ
わらず、その時点で最適な決定をすることが前提
• このギャップがストレスになる
»ウォーターフォール的思考からするとアジャイル的思考は「組織
決定への軽視」に感じられる
11

13. 導⼊パターン
12

14. エンタープライズアジャイルの導⼊パターン
既存組織とアジャイル組織の関係性に注⽬する
• アジャイルチームの活動が素晴らしくても、企業内の⽴ち
位置が適切でないとビジネス成果につながらない
• 既存組織を⼤陸と捉え、アジャイル組織を、どのように配
置するのか
»半島型パターン
»孤島型パターン
»出島型パターン
13

15. 導⼊パターン
半島型
• アジャイル組織は既存組織から強く影響される
»初期の決定を遵守することを求められる＆やろうとする
▸アジャイル組織のメンバーも、この思考になっている
»⽬的と開発プロセスに齟齬があるため管理が困難
▸ウォーターフォール開発プロセスのほうが良かった、と思いがち
»関係部⾨が既存思考のままだと、より困難になる
»結論︓ビジネスの変化に対応するような成果にはつながらない
14

16. 導⼊パターン
孤島型
• アジャイル組織は既存組織から切り離されている
»アジャイル組織内ではアジャイル開発プロセスの運営は可能
»ただし、既存組織の資産を活⽤することが困難
▸規則の問題から既存システムとの連携ができない。する場合は⼿動
▸既存組織の部署から協⼒を得ることが難しい
»結論︓既存組織に影響があるようなビジネス成果にならない
▸結果として、1年程度でビジネスが縮⼩してしまう
15

17. 導⼊パターン
出島型
• アジャイル組織に⾃治権があり
、かつ既存組織との適度な連携
»既存組織との間に緩衝帯がある
»双⽅に敬意をはらっている
▸部署の都合よりも、企業全体としてビジ
ネス成果にコミットする
»結論︓ここを⽬指すべき
16

18. 出島型導⼊パターンの実現にむけて
出島型を達成するに必要なこと
• ビジネス成果の事前検証
• シンプルな意思決定プロセス
• 技術的な独⽴性とシステム連携
• アジャイル開発プロセスの実践は前提
»アジャイル開発に知⾒があるメンバーがいる
»関係する部署もアジャイル開発を理解している
17

19. 出島型導⼊パターンの実現にむけて
ビジネス成果の事前検証
• システム開発を開始する前に、開発システムで実現しよう
とするアイデアのビジネス成果を検証する
»アジャイル開発は、アイデアの検証には重すぎる
»特に重要なのは「ビジネス成果」の定義。そこから必要になるシ
ステム機能を考える
▸ビジネス成果の定義︓ディスカバリー。サービスデザインの領域
▸アジャイル開発︓デリバリー。成果を達成するためにシステムを作る
»PoCも重要だが、成果がないなら撤退する
18

20. 出島型導⼊パターンの実現にむけて
シンプルな意思決定プロセス
• 開発中に⽅針変更や決定がスムーズに⾏えるようにする
»あくまでもビジネス的な成果を⾼めるためであることをアジャイ
ル組織も既存組織も理解する
»関係者が多いほど困難になるため、意思決定者を絞る
»既存組織の意思決定プロセスとの関係性は重要で、この意思決定
が既存組織でも尊重される必要がある
19

21. 出島型導⼊パターンの実現にむけて
技術的な独⽴性とシステム連携
• 技術選定の独⽴性が担保される⼀⽅で、既存システムとの
⾃動連携が可能になっている
»最新の技術が利⽤可能になっていないと⽣産性が上がらないが、
既存のデータが利⽤可能になっていることも重要
»既存のシステム開発に関わる規則との折り合いをつけていく必要
がある
▸守るべきものは守らないとダメ
▸特定のツールを前提とした規則を適切に調整する
20

22. 事例
21

23. 事例
Your FIT 365
• 三越伊勢丹における3D計測機を利⽤した婦⼈靴や紳⼠靴の
フィッティングサービス
»1年間で1万⼈以上が利⽤し、現在での機能向上中
▸システム開発前に靴売場スタッフが計測機を試験導⼊し、成果をあげられ
る確信があった
▸靴売場スタッフを情報システム部⾨に異動させ、仕様決定者としてアサイ
ン。既存のIT部⾨と関係なく、開発チームと直接コミュニケーションした
▸既存システムをAPI基盤経由で利⽤するようにした。API基盤チームが既存
規則との調整を全て⾏なった
22

24. 事例
マーケティングシステム
• メディア企業における顧客分析システム
»当初予算の1/3で成果を達成
▸3ヶ⽉かけてデータ分析とシステム分析を実施し、現状の課題を理解した上
でアジャイル開発を前提にベンダーを調達
▸やるべきことは⽉1回の担当役員ミーティングで決定。システム開発の⽬的
を「事業部⾨が成果を出すこと」と定めた
▸分析に適したOSS製品を採⽤。データ連携についても規則を遵守しながら
段階的に⾃動化して⾏った
23

25. まとめ
24

26. まとめ
• アジャイル開発
»メリット︓ビジネスの状況に応じて開発すべき機能を調整できる
»⼿法︓定期的な計画⽴案とビジネス関係者によるレビュー
• エンタープライズアジャイルの課題
»最初の稟議決裁時点で決定された「機能を作ること」が⽬標とな
ってしまうと、せっかくの調整機能が逆効果になる
»既存組織とアジャイル組織の適切な関係性を考えることが必要
25

27. まとめ
• 出島型パターンを達成する
»ビジネス成果の事前検証
»シンプルな意思決定プロセス
»技術的な独⽴性とシステム連携
• やはり、キーパーソンは必要
»ビジネス成果を明確に定義できる⼈物
»アジャイル開発の意義を理解しているマネジメント層
»チーム内で技術判断やプロセス推進ができる⼈物
26