目的で駆動する、AI時代のアーキテクチャ設計 / purpose-driven-architecture

by MinoDriven

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© DMM 新たな課題一方で、AIによる開発の難しさや問題が上がってきています。 ● AIの高速実装に伴い、技術的負債が加速度的に増加 ● AIが混乱し、コード実装がいつまで経っても終わらない ● AIが既存コードや環境を破壊する etc.. こうした問題があると、AIによる持続的開発が困難です。せっかくAIを使っても開発がスケールしません。 AIによる持続的開発を可能にする、なんらかのアプローチが必要です。 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© DMM ソフトウェア開発＝品質特性の作り込み 12 品質特性説明品質副特性機能適合性機能がニーズを満たす度合い機能完全性、機能正確性、機能適切性性能効率性リソース効率や性能の度合い時間効率性、資源効率性、容量満足性互換性他のシステムと情報共有、交換できる度合い共存性、相互運用性使用性利用者がシステムを満足に利用できる度合い適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザーインターフェイス快美性、アクセシビリティ信頼性必要なときに機能実行できる度合い成熟性、可用性、障害許容性、回復性セキュリティ不正利用から保護する度合い機密性、インテグリティ、否認防止性、責任追跡性、真正性保守性システムを修正する有効性や効率の度合いモジュール性、再利用性、解析性、修正性、試験性移植性他の実行環境に移植できる度合い適応性、設置性、置換性

Slide 13

Slide 13 text

© DMM ソフトウェア開発＝品質特性の作り込み 13 品質特性説明品質副特性機能適合性機能がニーズを満たす度合い機能完全性、機能正確性、機能適切性性能効率性リソース効率や性能の度合い時間効率性、資源効率性、容量満足性互換性他のシステムと情報共有、交換できる度合い共存性、相互運用性使用性利用者がシステムを満足に利用できる度合い適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザーインターフェイス快美性、アクセシビリティ信頼性必要なときに機能実行できる度合い成熟性、可用性、障害許容性、回復性セキュリティ不正利用から保護する度合い機密性、インテグリティ、否認防止性、責任追跡性、真正性保守性システムを修正する有効性や効率の度合いモジュール性、再利用性、解析性、修正性、試験性移植性他の実行環境に移植できる度合い適応性、設置性、置換性持続的開発で特に重要なのがこれ！

Slide 14

Slide 14 text

© DMM 変更容易性（修正性）なるべくバグを埋め込まず、素早く正確にコード変更できる度合いを変更容易性といいます。変更容易性に問題のあるコードは複雑で混乱しています。些細なコード変更でバグが埋め込まれやすい構造です。バグを埋め込まないよう、慎重に修正検討しなければなりません。なかなかコード変更できなくなるため、開発生産性が低下してしまいます。ソフトウェアの持続的開発を可能にするには、変更容易性が重要なポジションとなります。 14

Slide 15

Slide 15 text

© DMM ソフトウェアアーキテクチャとはソフトウェアとはただ作っても品質特性が向上するものではなく、なんらかの品質特性を促進するために意図をもってアーキテクチャを設計する必要がある、ということですね。 15 望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかに対する、重要な設計判断が集まったもの『Design It!』著:Michael Keeling,訳:島田浩二,2019年刊行,オライリー・ジャパン,p.8より引用

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© DMM 「目標」は要件や仕様に相当する 30 【目的】注文数を正しく表現したい【目標】注文数は1〜200であること【手段】目的を満たすソースコードシステムを不具合なく的確に機能させるには、仕様を決める必要があります。例えば注文数が負数だと不具合になりますし、 5000兆個といった非現実的な数量も問題があります。注文数については出荷業務の都合などを考慮し仕様を決めます。こうした要件や仕様が目標に相当します。目標を満たすようにコードを実施します。

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© DMM 34 class Validator { boolean isValidQuantity(OrderItem orderItem) { return 1 <= orderItem.quantity && orderItem.quantity <= 200; } } 正しい注文数だけを受け付けられるよう、次のようなバリデーションをどこかに実装するかもしれません。しかしこの実装では、以下のような問題が生じる可能性があります。 ● バリデーションを呼び忘れるとバグになる ● 別の箇所に重複したコードが実装される可能性 ● 注文数の仕様変更時、あちこち探し回らなければならない

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

© DMM 37 class Quantity { private static final int MIN = 1; private static final int MAX = 200; final int value; Quantity(final int value) { if (value < MIN || MAX < value) { throw new IllegalArgumentException("注文数は1以上200以下で指定してください"); } this.value = value; } Quantity add(final Quantity other) { return new Quantity(value + other.value); } } カプセル化とはデータとそのデータを操作するロジックをひとまとめにすること。これで正しい注文数を確実に表現できる。

Slide 38

Slide 38 text

© DMM 38 class YearlyPointBonus { int value; YearlyPointBonus(PurchaseHistory purchaseHistory, boolean isGoldMember) { value = (int)(purchaseHistory.yearlyAmount() * 0.01); if (isGoldMember) { value += 10000; } } } 会員ランク年間ポイントボーナス仕様一般会員年間購入費の1% ゴールド会員年間購入費の1% + 10000ポイントショッピングサイトにおけるポイントボーナスを考えてみます。この仕様を下記のように実装したとします。

Slide 39

Slide 39 text

© DMM 39 class YearlyPointBonus { int value; YearlyPointBonus(PurchaseHistory purchaseHistory, boolean isGoldMember) { value = (int)(purchaseHistory.yearlyAmount() * 0.02); if (isGoldMember) { value += 10000; } } } 会員ランク年間ポイントボーナス仕様一般会員年間購入費の1% ゴールド会員年間購入費の2% + 10000ポイントゴールド会員側の仕様が2%に変わり、0.02に実装修正すると、一般会員側が正しく計算できなくなります。バグになります！

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

© DMM 42 class RegularYearlyPointBonus { private static final double POINT_RATE = 0.01; final int value; RegularYearlyPointBonus(final PurchaseHistory purchaseHistory) { value = (int)(purchaseHistory.yearlyAmount() * POINT_RATE); } } class GoldYearlyPointBonus { private static final double POINT_RATE = 0.01; private static final int FIXED_POINT_BONUS = 10000; final int value; GoldYearlyPointBonus(final PurchaseHistory purchaseHistory) { value = (int)(purchaseHistory.yearlyAmount() * POINT_RATE) + FIXED_POINT_BONUS; } } このように目的ごとに分離することでコード変更影響が生じなくなります。変更に強くなります。

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© DMM 目的（要求）と変更容易性は地続きである要求定義とモジュール設計は違うフェーズのものであり、モジュール設計時にわざわざ要求定義を踏まえていない、というのが多くの開発現場で起こっていることではないでしょうか？しかし前述したように構造化は目的単位であることがわかります。変更容易性の高い構造の設計には目的は不可欠であり、目的すなわち要求がモジュール構造と地続きになっている、というのが目的という概念を持ち出す最大の理由です。 45

Slide 46

Slide 46 text

© DMM 背後にあるのはドメイン駆動設計の考えそしてこの「目的ごとに構造化する」というのは、実はドメイン駆動設計の考え方を言い換えたものです。 DDDは複雑な問題の解決手段をドメインモデルで構造化する手法。「じゃあ目的じゃなくてDDDでいいんじゃないの？」とツッコミがあるかもしれませんが、「ドメイン」という言葉よりも「目的」の方が馴染みやすいですし、なにより目的の方が「目的−目標−手段」の関係性で整理しやすいです。そしてそれだけではなく、目的を用いた方がさらにアドバンテージがあります（後述）。 46

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© DMM 「契約による設計」で目標を厳密に定める契約による設計とは、正確性の向上を目的にバートランド・メイヤー氏が考案した設計の方法論。 ● 事前条件：メソッド開始時に保証されるべき条件 ● 事後条件：メソッド終了時に保証されるべき条件 ● 不変条件：常に維持されるべき条件モジュールの機能適合性を保証するテストはこの3条件の検証が基本。上記3条件は「目的−目標−手段」における目標に相当。「目的を確実に達成するためにどんな目標が必要か」と考えることで条件をより的確に設計できます。 49

Slide 50

Slide 50 text

© DMM 目的を教示するとAIの回答精度が向上するそして目的を持ち出す理由として特に重要なのがこれ。 AIの回答精度を高める指示の仕方として有名なテクニックですが、 AIに目的を伝えると回答精度が向上します。この延長上にあるのがコンテキストエンジニアリング。目的の背後にある前提や状況をAIに伝えてより的確な回答を生成するアプローチ。 50 # 目的 ◯◯したい # 命令あなたの仕事はxxxすることである

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© DMM AIの判断力がめちゃめちゃ向上します【変更容易性の高いコード実装】 AIが目的の違うコードを別々のクラスに分けて実装します。つまり変更容易性の高いコードをAIが書けるようになります。【コードリーディング性能向上】コードそれぞれの目的の違いを見分けられるようになります。「このコードはクレジットカード決済を目的としているCardSettlement クラスにあるべき」といった判断ができるようになります。【実装の正確性向上】契約による設計が「ガードレール」になっているのもあり、 AIが迷走せず正確に実装できるようになります。 52

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

© DMM 仕事のタスクを目的−目標−手段で書こう 71 【Issueタイトル】検索結果画面の表示速度改善 # 目的ユーザーが快適にアプリを使えるようにし、離脱率を下げたい # 目標（目的の達成条件）主要な検索キーワードに対する検索結果の初期表示時間を2秒以内にすること # 手段クエリの実行計画を分析し、不要なJOINを削減する GitHubのIssueやタスク管理ツールのチケットを次の形式で書こう

Slide 72

Slide 72 text

Slide 73

Slide 73 text