Agile Japan 2020
“変わる勇気・変えない勇気”

DXのための出島型アジャイル組織-半島や孤島を避けるために
2020/11/18
グロース・アーキテクチャ＆チームス株式会社
代表取締役社⻑

鈴⽊雄介

⾃⼰紹介

鈴⽊雄介

• Graat（グラーツ）» グロース・アーキテクチャ＆チームス（株）▸ 代表取締役社⻑

▸https://www.graat.co.jp» マイクロサービス設計、アジャイル導⼊など• ⽇本Javaユーザーグループ» サブリーダー/CCC運営委員⻑

• その他» @yusuke_arclamp» http://arclamp.hatenablog.com/
1

今⽇の話したいことDXのためのアジャイル導⼊の壁• 思考や⾏動の違い» ウォーターフォール開発プロセスを実施してきた組織では、組織のルールや従業員の思考や⾏動がそれに最適化している» そこでアジャイル開発を実施しようすると関係者間に様々な齟齬が⽣まれてしまう• ではどうすればいいのか︖» 思考や⾏動の違いを理解し、適切に使い分ける2

アジェンダ• ウォーターフォールとアジャイル• 組織の関係パターン• 出島パターンを⽬指す
• 事例

• まとめ

3

ウォーターフォールとアジャイル

4

ウォーターフォールとアジャイル
ウォーターフォールの特性• ウォーターフォール開発で⾏うこと» 最初に作るべき機能を全て決める» その機能を実現するための費⽤と期間を計画し、凛議を通す» その計画を達成するために⾏動する（そのための変更はOK）• 最初に開発すべき機能を決定する» その決定を達成するために計画し、実⾏する▸途中の計画変更は、あくまでも最初の決定を守るため» 機能（システム）そのものが⽬的になりがち5

ウォーターフォールとアジャイル
アジャイルの特性• アジャイル開発を実施した企業によるアンケート結果» 優先順位の変更を管理する機能 69%» プロジェクトの可視性 65%» ビジネスとITの⾜並みを揃える 64%• ビジネスの状況にあわせて開発すべき機能を決定する» 短期＆定期に計画/実⾏/確認→次の計画⽴案を繰り返す» 外部要因による変化に対応することが可能

出典 CollabNet VersionOne編 : 13th Annual State of Agile Report.
https://stateofagile.com/

6ウォーターフォールとアジャイル
考え⽅の違いがストレスになる• ウォーターフォールから⾒ると...

» 組織決定への軽視» 場当たり的で機能もチープだし、品質が安定しない• アジャイルから⾒ると» 意味ないことへのこだわり» 間違ったものを計画的に⼤量に⾼品質に作っている7

ウォーターフォールとアジャイル
重要なことは思考の使い分け• ウォーターフォールが悪ではない» 最初の決定を遵守するのは組織運営として重要なこと» ただし、「⼿段」の失敗がわかった上でも「⼿段」にこだわるのは愚かなこと。⼤事なことはビジネス成果の達成• アジャイルの「状況に応じて決定する」ことのメリットを理解し、適切に使い分けることが重要

8

組織の関係パターン

9

組織の関係パターン
既存組織とDX推進組織の関係性• 既存組織を⼤陸と捉え、アジャイル組織が、どのように配置されているのか︖» 半島型パターン» 孤島型パターン» 出島型パターン10

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

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

12

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

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

出島パターンを⽬指す

ビジネス成果の事前検証

16

ビジネス成果の事前検証
開発が始まってからでは遅い• 企業であればアジャイルであっても「最初の決定」を完全に無視することはすべきではない» 「最初の決定」の確度を上げるのは重要» アジャイル開発は企画検証にしては軽量ではない▸チームを継続的にアサインをすれば毎⽉ 数百万円は消えていく• 本格的な開発を始める前に事前検証を⾏う必要がある» ディスカバリーフェーズとして分離する» 簡易なユーザーテストはデザイナーだけでもできる17

ビジネス成果の事前検証
まずビジネス成果の実現性を明確にする• 検証すべきは「ビジネス成果の実現性」» 「技術的に実現できる」と「ビジネス成果につながる」は別• ビジネス成果に実現性がないならやめるべき» AIという技術に実現性があっても意味がない» 何を成果とするのかを⾒極めるのはビジネス視点であるべき

18

出島パターンを⽬指す

シンプルな意思決定プロセス

19シンプルな意思決定プロセス
開発中の変更をスムーズに実現する• ①最終決定者が明確であること» 関係者が多いほど困難になるため、意思決定者を絞る• ②決定がビジネス成果の観点であること» 決定がビジネス成果につながるかを判断できる• ③決定が既存組織でも尊重されること» この決定が既存組織内で覆らない→役員レベルの関与は必須
20シンプルな意思決定プロセス
よりシンプルにするために• ①定期的に判断を実施する» 週1回、おそくとも⽉に1回決定できるようにする• ②⼩さな案件は権限移譲する» ⼀定の⼤きさまでは現場のPOが決めればいい• ③組織で決定リズムを守る» 案件サイズでリードタイムをはっきりさせて組織的に守る▸案出し→整理→実施決定→実装→リリース

21

出島パターンを⽬指す

技術的な独⽴性とシステム連携

22

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

23

事例

24

事例１

YourFIT 365

25

YourFIT 365
概要• 三越伊勢丹における3D計測機を利⽤した婦⼈靴と紳⼠靴のパーソナルフィッティングサービス» 2019年8⽉にスタートし、1年間で1万⼈以上が利⽤» ⾜形を3D計測すると、⾜にフィットする順に靴をタブレットで表⽰。シューカウンセラーがフィッティングを確認し、最適な1⾜を⾒つける» 計測結果を分析し、⽊型開発なども実施

26

YourFIT 365• ビジネス成果の事前検証» システム開発前に靴売場スタッフが独⾃に計測機を試験導⼊し、精度を確認。その上でシステム開発を上申• シンプルな意思決定プロセス» 売場スタッフを情報システム部⾨に異動しPOに任命。部⻑配下で既存のIT部⾨を切り離して開発チームを組成。売場と直接コミュニケーションをして開発を⾏った• 技術的な独⽴性とシステム連携» 新規技術を採⽤し、既存システムはAPI基盤経由で利⽤。既存組織のAPI基盤チームがルール調整を全て⾏なってくれた
参考︓ITエンジニアの祭典「Developers Summit 2020」に弊社鈴⽊と河村が登壇しました
https://note.com/imd_lab/n/nf6c85e635c87
27

事例2

マーケティングシステム

28

マーケティングシステム
概要• メディア企業における顧客分析システム» 各システムに分断した顧客情報や契約情報を集約し、分析することで、これまでに⾒えていなかった顧客を発⾒する» 各システムのデータ項⽬がバラバラであったり、紐付けキーが異なっていたため、これらを段階的に紐つけていった» 開発プロセスにアジャイルの採⽤を前提としてベンダー調達• 当初予算の1/3で成果を達成

29

マーケティングシステム• ビジネス成果の事前検証» 3ヶ⽉かけてデータ分析とシステム分析を実施し、現状の課題を理解した上でアジャイル開発を前提にベンダーを調達• シンプルな意思決定プロセス» ⽉1回の担当役員ミーティングで意思決定。すべての事業部⾨を巻き込んで毎⽉ビジネス成果を出すことが求められた• 技術的な独⽴性とシステム連携» 分析に適したOSS製品をチームが選定。データ連携についても規則を遵守しながら段階的に⾃動化して⾏った
30

まとめ

31

まとめ
• DX推進組織の悩み» 新しいシステム開発スタイルを導⼊したいが、成果が伸びない» ウォーターフォール思考の組織や⼈とのギャップが⾟い• ウォーターフォール思考とアジャイル思考» 最初の決定を遵守 vs 状況に対応して決定していく▸後者は組織への軽視に⾒えてしまいがち▸ただし、失敗が明確になっても最初の決定を遵守するのは愚か» 思考の使い分けが重要

32

まとめ
• 組織の関係パターン» 既存組織とDX組織の関係性を健全にする必要がある▸半島︓影響を受けすぎてウォーターフォール思考になってしまう▸孤島︓影響を受けないが、逆に影響を与えることもできない▸出島︓適度な⾃治権と関係性を維持する• 出島型パターンを達成する» ビジネス成果の事前検証» シンプルな意思決定プロセス» 技術的な独⽴性とシステム連携
33

さいごに変わる勇気・変えない勇気• 相⼿が「変わらない」ことにイライラしすぎない» ⼤陸の住⼈にも敬意をはらうこと• ⾃らが「変わったつもりで変わっていない」か︖» いつのまにか「最初に決定された⼿段」に流されていないか︖• 「変えるため」の⽀援者を⾒つける» 変わらない側（⼤陸）にいる⼈が、変えようとしなかれば変わらない
34

参考⽂献
デジタルプラクティス 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

35