アーキテクチャレベルで考える開発生産性 / architecture-and-productivity

Transcript

1. © DMM © DMM アーキテクチャレベルで考える 開発生産性 2024/06/29(土) 開発生産性Conference 2024 合同会社DMM.com

   ミノ駆動 プラットフォーム開発本部 第3開発部 DeveloperProductivityGroup

2. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部

   DeveloperProductivityGroup DMMプラットフォームの設計を改善し開 発生産性向上を図るのがミッション 2

3. © DMM 著書紹介 『良いコード／悪いコードで学ぶ設計入門』 変更容易性の高い設計を学ぶ、初級〜中級 向け入門書 ITエンジニア本大賞2023技術書部門大賞 受賞 11刷重版 3

4. © DMM 本セッションの理解目標 • ソフトウェアの開発生産性を高めるには、開発の自動化やプロセス改 善だけでなく、アーキテクチャの設計も重要であること。 • サービスの競争優位性が何であるかを把握し、競争優位性を高められ るアーキテクチャを設計すること。 •

   こうしたアーキテクチャの設計には、ドメイン駆動設計の戦略的設計が 有用であること。 4

5. © DMM 突然ですが…

6. © DMM 皆さんのお給料、 どこから出ていますか？

7. © DMM 利益、収益、費用の関係 費用：業務遂行にかかる諸々のコスト 収益：商品やサービスが稼いだお金の総額。費用が差し引かれる前の金額。 利益：収益から費用を差し引いた金額。 7 利益 収益 費用

   我々の給料は「費用」ではあるが、費用 に回せる利益が元になっている。

8. © DMM 開発生産性の関わり 8 利益 収益 費用 費用を低減する活動が 開発生産性向上の専らの話題

9. © DMM 収益が得られなかったらどうなる？ 9 利益 収益 費用 開発生産性向上を一生懸命やったとしても 収益を得られなかったらどうなる？ 利益を得られなくなりますね

10. © DMM • CI/CD環境、Four Keys計測、チャットツールやタスク管 理ツールなど開発生産性向上の環境整備は完璧！ • でも顧客が見向きもしない、役に立たないサービスが完成 しました…… 極端な話

    いくら頑張って開発生産性向上の環境を整備しても、収益を 出せなかったら開発生産性も何もあったものではないですね （※開発生産性向上活動は重要です、否定はしません）

11. © DMM だから収益を上げられるサービスを作りましょう 「収益向上」をベースに開発生産性を考えましょう 収益と開発生産性を高めやすいアーキテクチャを考えましょう 本日はこういうお話をします

12. © DMM ところで

13. © DMM あなたが開発するサービス、 業界で独壇場ですか？

14. © DMM そうじゃないですよね ほとんどの場合 競合他社がいますよね

15. © DMM 競合他社がひしめき合っている状況で 生半可な機能開発で他社に勝てますか？ 勝てませんよね

16. © DMM じゃあ何を開発しますか？

17. © DMM 顧客があまり触らないような サブ機能やオプション機能を 集中的に改善しますか？

18. © DMM それともすでにコモディティ化している 機能を改修しますか？

19. © DMM 違いますよね

20. © DMM 他社が追従できない、差別化可能な、 「ここがウリだ！」と言えるような 競争優位になる魅力的な機能を 開発しますよね

21. © DMM ではあなたが開発するサービスの 競争優位性が何か すぐに説明できますか？

22. © DMM 競争優位性が何かよく分かっていなくて 機能開発が五月雨になってたり していませんか？

23. © DMM 何の話をしているかというと…

24. © DMM 機能性 • ソフトウェア品質特性のひとつ。機能が顧客ニーズを満たす度合い。 • 機能性が高いと当然収益も上がる。 • 競争優位性のある機能の開発が収益向上する上で重要。 •

    競争優位性を意識しないと思いつきで五月雨な開発になりがち。 • 逆噴射して「なんでこんな仕様に変えたの？」と顧客を失望させることも。 • 優位性のない機能は顧客を満足させることができず、収益が低下。 24 利益 収益 費用 収益↓　利益↓

25. © DMM もうひとつ別の観点の話をします

26. © DMM では何が競争優位な機能か わかっているものとします もしくは頻繁に仕様変更される機能を 思い浮かべてください

27. © DMM その機能のためのロジックが ソースコードのどこにあるのか熟知していますか？ どこにあるのか把握が困難で いちいち詳しく読みにいかなければ ならなくなっていませんか？

28. © DMM その機能のソースコードは 変更しやすい構造になっていますか？ 混乱して複雑化していて 変更が難しい構造になっていませんか？ そのコードを変更すると 別の機能が壊れたりしませんか？

29. © DMM 何の話をしているかというと…

30. © DMM 変更容易性 • ソフトウェア品質特性のひとつ。 • なるべくバグを埋め込まず素早く正確に変更可能な度合い。 • 変更容易性の高い構造であるほど開発コスト（費用）が下がる。 •

    逆に複雑で混乱した構造は変更容易性が低く、開発コスト増大。 • 特に競争優位になる魅力的な機能は顧客ニーズが多く、頻繁に仕様変更さ れ、放っておくとどんどん複雑化していく。 • 機能の魅力をもっと高めようにもなかなか変更できなくなり、優位性が失 われていく。 30 利益 費用 収益 費用↑　利益↓

31. © DMM 費用に関してもうひとつ重要なこと 「費用は有限」

32. © DMM 選択と集中 • 当たり前ですが開発リソースは有限です。無限ではありません。 • だからサービスの全部に対して等しく開発投資するなんてことは不可 能です。 • 優先度を決め、重要な部分に集中的に開発リソースを投じなければな

    らない現実があります。 • ではどの部分に集中するか？それは競争優位性を発揮できるビジネ ス領域であり機能ですね。 • 変更容易性の設計も同様に、重要な部分に集中すべきです。 32

33. © DMM 重要部分の機能性と変更容易性を高めることで 利益が上がる 投資費用対効果すなわち 開発生産性が上がる

34. © DMM ここまで一旦まとめ 1. 限られた開発リソースの中で、 2. 競争優位性を発揮できるビジネス領域を見定め、 3. その領域に対して集中的に開発リソースを投じ、魅力的な機能を開発 する

    4. 魅力的機能の機能性を素早く高められるように、その機能に対して変 更容易性の設計コストを集中させる 34

35. © DMM では 機能性と変更容易性を高めるために どう取り組めば良いのでしょう？

36. © DMM ドメイン駆動設計

37. © DMM ドメイン駆動設計には 機能性と変更容易性を高め 持続的に利益向上していくための戦略や アーキテクチャ設計のノウハウが 網羅されています

38. © DMM ドメイン駆動設計における 「戦略的設計」 のノウハウを いくつか紹介します

39. © DMM ドメイン駆動設計の「戦略的設計」は きわめて重要ではあるものの あまり話題にされないので 概要だけでもしっかりおさえておいてほしいです

40. © DMM コアドメイン • ドメインとは、ソフトウェアが解決する事業領域。 • コアドメインとは、差別化が図られ、競争優位性を発揮する領域。 • 一方で必要ではあるがコアではない領域をサブドメインと呼ぶ。 •

    ドメインエキスパート（事業課題の専門家）と話し合い、コアとサブを見 分けることが重要。これが一番大変！ • ちなみにソフトウェアはユーザー目的を満たすように作られるものな ので、コアを主目的、サブを副目的と個人的に呼称していたりする。 40 サブドメイン1 サブドメイン2 機能性 コアドメイン

41. © DMM ドメインビジョン声明文 • コアドメインを見定めたらそのままにしておくのではなく、関係者全員 が共通認識を持てるように指針を示す必要がある。 • ドメインビジョン声明文とは、コアドメインがもたらす価値を簡潔に記 述したドキュメント。 41

    機能性

42. © DMM 境界付けられたコンテキスト どのドメインでも共通の、統一的 な一枚岩モデルにするとモデル が多目的に使われ、巨大化複雑 化する。 42 変更容易性 在庫ドメイン

    配送ドメイン 注文ドメイン 審査ドメイン ECサイト 商品モデル

43. © DMM 境界付けられたコンテキスト 各ドメイン（目的）に特化したモデ ルを設計し、各特化型モデルが 適用可能なスコープを決める。 これが境界付けられたコンテキ スト。 後述のコアとサブでシステムを 分けるのにも用いる。

    43 変更容易性 在庫ドメイン 配送ドメイン 注文ドメイン 審査ドメイン 審査コンテキスト 審査品目 在庫コンテキスト 在庫品 配送コンテキスト 配送品 注文コンテキスト 注文品

44. © DMM 蒸留 混ざりあったコンポーネントを分離し、価値のある部分を抽出するプロセ ス。DDDではもっぱらコアドメインの要素を抽出することを意味する。 ばらばらに断片化したコアロジックを抽出し、コア用のモジュール（サブシ ステム）に集めてカプセル化する。 44

45. © DMM 隔離されたコア コア用のロジックとサブ用のロジック が複雑に絡み合っていると、コアの 機能を改善しようにも変更が難しく なってしまう。 従って、境界付けられたコンテキスト と蒸留に基づきコアとサブでシステ ムを分離隔離する。

    コアにサブの要素が入り込まないよ う徹底的に純化し、コアに特化したシ ステムにする。 45 コアドメイン サブドメインA サブドメインB コアシステム サブシステム A サブシステム B 変更容易性

46. © DMM レイヤードアーキテクチャ 46 ドメイン ルール解決 ユースケース 解決 入出力変換 外界

    ドメイン層 ユースケース層 コントローラ層 インフラ層 View データベース 変更容易性 下図はレイヤードアーキテクチャの一例（いろいろバリエーションあり）。 ドメイン関心事や技術関心事単位で関心を分離することで変更容易性の向 上を図る。 (※戦術的設計)

47. © DMM ドメイン層 47 Repository interface Aggregate Entity ValueObject 変更容易性

    以下、代表的な設計パターン（このパターンには限らない）を用いてドメイ ン概念を整理することにより変更容易性が向上する。 (※戦術的設計)

48. © DMM コアへの開発投資を優先する • 開発リソースは有限、全てに対して満遍なく等しく開発投資することは 不可能。 • エンジニアによってスキルの熟達度はそれぞれ。 • 同様に変更容易性の設計スキルもピンキリ。

    • サービスの競争優位性を高めるには、コアに対して優先的に開発コスト を割き、スキルの高いエンジニアをアサインする必要がある。 • サブドメインの機能については、開発を外部に委託する、サードパー ティのサービスやツールで賄う、といった戦略も考えられる。 48

49. © DMM コアドメインは移動する ユーザー要求の変化、競合他社の台頭、優 位性のコモディティ化など外的な要因に より、競争舞台であるコアドメインは時代 とともに移動する。 ここでコアシステムの構造が複雑で粗悪 だと、コアドメインの変化に追従できなく なる。

    追従できるようコアシステムの変更容易 性を高めておくことが、競争優位性を維 持する上で肝要。 49 コアドメイン コアシステム 変更容易性

50. © DMM 我々はアジャイルを実践できているのか 「アジャイル（素早い、機敏）」という言葉が放たれるとき、開発プロセスや組 織、FourKeysといった、システム本体ではなくシステムを取り巻く世界の話 がよく挙がります。 しかし、「価値」が構造化されていないシステムは、アジャイルと言えるでしょ うか？ 複雑怪奇で変更が困難なシステムは、アジャイルと言えるでしょうか？ 価値を素早く成長し続けられる構造を設計することが、アジャイルな開発を

    推進し、開発生産性を向上する上で重要な位置付けであると考えます。 50

51. © DMM ご清聴ありがとうございました