Slide 1

Slide 1 text

Copyright© M&Aクラウド 『⾃分のデータだけ⾒せたい!』を叶える ──Laravel × Casbin で複雑権限を スッキリ解きほぐす 25 分 PHPカンファレンス2025 Akito.Tsukahara

Slide 2

Slide 2 text

Copyright© M&Aクラウド 2 ⾃⼰紹介 塚原彰仁 AkitoTsukahara 株式会社M&Aクラウド AkitoTsukahara

Slide 3

Slide 3 text

Copyright© M&Aクラウド この発表で伝えたいこと ● 権限管理プロジェクトの取り組み⽅を題材に ■ 課題設定⼒ ● 複雑な仕様をシンプルにする思考プロセス ■ 課題解決⼒ ● 複雑な仕様をシンプルな実装で実現するアーキテクチャ

Slide 4

Slide 4 text

Copyright© M&Aクラウド アジェンダ 1. はじめに 2. なんだか難しいぞ!権限管理 3. 権限処理の全体像 4. 権限管理における課題解決の具体的なアプローチ 5. まとめ

Slide 5

Slide 5 text

Copyright© M&Aクラウド はじめに 5

Slide 6

Slide 6 text

Copyright© M&Aクラウド M&Aアドバイザーに向けたDXツール 6

Slide 7

Slide 7 text

Copyright© M&Aクラウド システム構成 7 ● バックエンド:PHP, Laravel ● フロントエンド:SvelteKit, TypeScript ● アーキテクチャ:レイヤードアーキテクチャを採⽤ ● 主要なエンティティ:Company,Deal,Sourcingなど

Slide 8

Slide 8 text

Copyright© M&Aクラウド プロジェクト概要 8 ● 期間:企画 1ヶ⽉+開発 1.5ヶ⽉ ● 体制:エンジニア 3⼈+PdM 1⼈ ● ⽬的:部署 / 担当者 / 外部パートナー間で”閲覧できるデータ”を分離 ● スコープ in:権限基盤 / UI制御 ● スコープ out:権限管理GUI

Slide 9

Slide 9 text

Copyright© M&Aクラウド なんだか難しいぞ!権限管理 9

Slide 10

Slide 10 text

Copyright© M&Aクラウド ● 部署間での情報取り扱い問題 ● インターンや外部パートナーの存在 ● M&A案件の機密性 権限管理の必要性 10

Slide 11

Slide 11 text

Copyright© M&Aクラウド どのようなデータ設計になるのか?先⼈たちの知恵を借りる ● 権限モデル ○ RBAC(Role Base Access Control) ■ ロール〈=職種‧部署など〉に権限を付与 ○ ABAC(Attribute Base Access Control) ■ ユーザー‧オブジェクト‧環境の属性で動的判定 権限管理のモデル:先⼈たちの知恵を借りる 11

Slide 12

Slide 12 text

Copyright© M&Aクラウド 初期要件の整理 12 要求の核⼼は「⾃分のデータだけ⾒せたい」 ● 部署/役職ベースのアクセス制御(RBAC) ● 担当者ベースのアクセス制御(ABAC) ● 基本的な権限制御

Slide 13

Slide 13 text

Copyright© M&Aクラウド (図解)部署/役職ベースの制御 13

Slide 14

Slide 14 text

Copyright© M&Aクラウド (図解)担当者ベースの制御 14

Slide 15

Slide 15 text

Copyright© M&Aクラウド 権限制御に関わる変数 15 ● 部署:24種 ● 役職:4種 ● オブジェクト:8種 ● スコープ:20種 ● アクション:13種

Slide 16

Slide 16 text

Copyright© M&Aクラウド 単純に変数を掛け合わせると 24 * 4 * 8 * 20 * 13 = ???パターン 組み合わせ爆発💣💥 16

Slide 17

Slide 17 text

Copyright© M&Aクラウド 単純に変数を掛け合わせると 199,680 組み合わせ爆発💣💥 17

Slide 18

Slide 18 text

Copyright© M&Aクラウド パターンを抑えられないか検討 18 さすがに全パターンを実装しないが、結構多くなりそうだ... PdMと業務に必要なパターンを全て書き出してみる 7,547パターン だいぶ減った感覚だが、まだまだ多い...

Slide 19

Slide 19 text

Copyright© M&Aクラウド パターンを抑えられないか検討 19 実際に書き出してみると検討の余地が⾒えてくる

Slide 20

Slide 20 text

Copyright© M&Aクラウド パターンを抑える作戦その1 20 似たような権限の部署をグループ化 ● 主にシステムを利⽤するアドバイザー部署は細かに権限制御 ● アドバイザー以外の部署は共通というグループにまとめる 24部署 → 14部署に削減

Slide 21

Slide 21 text

Copyright© M&Aクラウド パターンを抑える作戦その2 21 部署単位でスコープを分けるデータを最低限に抑える →主要な「案件」オブジェクトのみ詳細なスコープ制御を⾏い、他はシンプルな 制御に集約しました! 8オブジェクト * 20スコープ  → 1オブジェクト * 20スコープ

Slide 22

Slide 22 text

Copyright© M&Aクラウド 最終的には 3,395 組み合わせ爆発💣💥 22

Slide 23

Slide 23 text

Copyright© M&Aクラウド 実装検討へ 23 要件、仕様も固まってきて、対応する権限パターンも⾒えてきた この権限機能をどう実装するのか ● Laravel 標準のGate / Policy では難しそう ○ RBACは対応できるが、ABACの対応が困難であった ● 複雑な属性ベース制御が必要になる ● RBACとABACの両⽅に対応する必要がある

Slide 24

Slide 24 text

Copyright© M&Aクラウド Casbinとは? 24 宣⾔的アクセス制御エンジン ● RBAC,ABAC, ACLを同⼀DSLで定義 ● Go⾔語製、多⾔語バインディング ○ 今回はPHP-Casbinを利⽤ ● Model (ルール) と Policy (データ) 分離 ● DB, Redis, CSVファイル なんでもポリシー保存可

Slide 25

Slide 25 text

Copyright© M&Aクラウド (図解)Casbinとは? 25

Slide 26

Slide 26 text

Copyright© M&Aクラウド Casbinの基本4ブロック 26 1. request_definition  (r = sub, obj, act ) a. リクエスト引数の並びを宣⾔ 2. policy_definition (p = sub, obj, act) a. ポリシー⾏の列順を宣⾔ 3. role_definition (g = _, _) a. ロール継承 (RBAC) を有効化 4. matcher (m = g(r.sub,p.sub) && r.obj==p.obj && r.act==p.act) a. r.* と p.* をどう⽐べるかを論理式で定義

Slide 27

Slide 27 text

Copyright© M&Aクラウド (図解)Casbinの基本4ブロック 27

Slide 28

Slide 28 text

Copyright© M&Aクラウド なぜCasbinを選んだか 28 いくつかあるライブラリの中でCasbinを選んだのは、 ● 既存システムでの利⽤実績 ● 複雑なモデルへの対応⼒ ○ ABACに対応できる ■ matcherでABAC条件を書ける ○ データの持ち⽅がシンプルなので拡張しやすい

Slide 29

Slide 29 text

Copyright© M&Aクラウド Casbinモデル設計:最初の挑戦とシンプルな過ち 29 さあ、実装していこう! ● 要件は「サブジェクト(誰が)」「オブジェクト(何を)」「アクション(どうす る)」に加え、「スコープ(どの範囲で)」という重要な概念がありました ● 当初はCasbinの基本である3要素 (sub, obj, act) を維持するため、「オブ ジェクト」と「スコープ」を⼀体化して obj として扱う、シンプルな設計を 試みましたが。。。

Slide 30

Slide 30 text

Copyright© M&Aクラウド Casbinモデル設計:最初の挑戦とシンプルな過ち 30 ▼ 最初の設計案(失敗例) ● オブジェクト Company + スコープ ALL ○ Casbinの obj には 'Company_ALL' という⽂字列を渡す。 ● オブジェクト Company + スコープ OWN ○ Casbinの obj には 'Company_OWN' という⽂字列を渡す。

Slide 31

Slide 31 text

Copyright© M&Aクラウド (図解)最初の設計案(失敗例) 31

Slide 32

Slide 32 text

Copyright© M&Aクラウド 設計の落とし⽳:⼀体化がもたらした複雑性 32 「オブジェクトとスコープの⼀体化」案は、すぐに問題に直⾯ ● 同じオブジェクトなのに別扱いに ○ 『企業_ALL』と『企業_OWN』は同じ『企業』オブジェクトなのに、 ポリシー上は全くの別物として扱う必要がある ● メンテナンス性の悪化 ○ 新しいスコープが増えるたびに、オブジェクトの数だけ追加が必要

Slide 33

Slide 33 text

Copyright© M&Aクラウド 解決策:モデルの分離と真のシンプルさの回復 33 この問題を解決するため、私たちはCasbinのモデル定義を拡張し、「オブジェ クト」と「スコープ」を分離する決断💡 ● request_definition: sub, obj, scope, act ○ オブジェクトとスコープの分離 ○ 4要素での権限表現

Slide 34

Slide 34 text

Copyright© M&Aクラウド (図解)解決策:モデルの分離と真のシンプルさの回復 34

Slide 35

Slide 35 text

Copyright© M&Aクラウド 権限処理の全体像 35

Slide 36

Slide 36 text

Copyright© M&Aクラウド 権限処理の全体像:5つの主要な登場⼈物 36 ● 主要コンポーネントの役割説明 ○ ⾨番:PermissionEnforcerMiddleware ○ 司令塔:PermissionChecker ○ 専⾨家:ObjectIdentifier ○ 実⾏者:Casbin(EnforcerAdapter) ○ 情報伝達役:PermissionContext

Slide 37

Slide 37 text

Copyright© M&Aクラウド 全体の流れ:権限チェックはシンプルな3ステップ 37

Slide 38

Slide 38 text

Copyright© M&Aクラウド 権限管理における課題解決の 具体的なアプローチ 38

Slide 39

Slide 39 text

Copyright© M&Aクラウド 権限管理における課題解決の具体的なアプローチ 39 実装の壁を乗り越える3つの技術戦略+α ● 権限チェック処理の責務分離とテスト容易性の向上 ● 属性ベースアクセス制御 (ABAC) の実現 ● データフィルタリングとパフォーマンス最適化 ● フロントエンドでの動的UI制御(時間ないので付録で) ● 品質向上への取り組み(時間ないので付録で)

Slide 40

Slide 40 text

Copyright© M&Aクラウド 権限チェック処理の責務分離とテスト容易性の向上 40 初期の課題: 複雑化するMiddleware ● Middlewareの肥⼤化 ● ロジックの複雑化 ● テストの困難さといった課題が発⽣

Slide 41

Slide 41 text

Copyright© M&Aクラウド 権限チェック処理の責務分離とテスト容易性の向上 41 解決策:権限チェック処理の責務分解 ● Middlewareは「リクエストの受付」「Checkerへの処理委譲」に専念 ● PermissionChecker: ○ オブジェクトの属性を解釈し、Casbinへの問い合わせ内容を組み⽴て る司令塔 ● EnforcerAdapter: ○ Casbinのenforceメソッドを呼び出すだけの、シンプルな橋渡し役

Slide 42

Slide 42 text

Copyright© M&Aクラウド 権限チェック処理の責務分離とテスト容易性の向上 42

Slide 43

Slide 43 text

Copyright© M&Aクラウド 権限チェック処理の責務分解 43

Slide 44

Slide 44 text

Copyright© M&Aクラウド 権限チェック処理の責務分解 44 権限チェックを分離

Slide 45

Slide 45 text

Copyright© M&Aクラウド 権限チェック処理の責務分解 45 EnforcerAdapterへの権限判定委譲 オブジェクトの属性を解釈し、Casbinへの問い合わせ内容を組み⽴てる司令塔

Slide 46

Slide 46 text

Copyright© M&Aクラウド 権限チェック処理の責務分解 46 Casbinのenforceメソッドを呼び出すだけの、シンプルな橋渡し役

Slide 47

Slide 47 text

Copyright© M&Aクラウド 属性ベースアクセス制御 (ABAC) の実現 47 課題: 「⾃分が担当者の案件か?」で権限が変わる RBACだけでは「⾃分が担当者の案件だけ編集できる」といった、 データの中⾝を⾒ないと判断できない動的な条件に対応できない。。。 このオブジェクト固有の判定ロジックを、どうスッキリ実装するかが最⼤の課題 でした。

Slide 48

Slide 48 text

Copyright© M&Aクラウド 解決策: オブジェクト固有の「権限判定ロジック」をカプセル化 48 そこで「ObjectIdentifier」という新しい責務を導⼊しました。 ■ ObjectIdentifierの役割 オブジェクトに関する情報を収集し、その属性に応じて 適切な権限スコープ(例: ALL, OWN)を決定するクラスです。 オブジェクト固有の複雑なロジックを、このクラスにすべて閉じ込めます。

Slide 49

Slide 49 text

Copyright© M&Aクラウド Factoryパターンで、オブジェクトに応じたIdentifierを動的に⽣成 49

Slide 50

Slide 50 text

Copyright© M&Aクラウド Factoryパターンで、オブジェクトに応じたIdentifierを動的に⽣成 50 Factory Patternによる柔軟な オブジェクト生成

Slide 51

Slide 51 text

Copyright© M&Aクラウド 実装例:静的なスコープを返すシンプルな例 51 スコープとアクションの動的決定

Slide 52

Slide 52 text

Copyright© M&Aクラウド 実装例:属性でスコープを切り替えるABACの核⼼ 52 オブジェクト毎の権限ロジックを 分離できる

Slide 53

Slide 53 text

Copyright© M&Aクラウド データフィルタリングとパフォーマンス最適化 53 課題: 1万件のデータで破綻する⼀覧表⽰

Slide 54

Slide 54 text

Copyright© M&Aクラウド データフィルタリングとパフォーマンス最適化 54 課題: 1万件のデータで破綻する⼀覧表⽰ ❌ DBから全件取得するため、データ量に応じて遅くなる。 ❌ 正しいページネーションが実装できない。( 2ページ目を表示する ためだけに、また全件取得と全件チェックが必要)

Slide 55

Slide 55 text

Copyright© M&Aクラウド データフィルタリングとパフォーマンス最適化 55 解決策:アプリではなく、DBにフィルタリングを任せる

Slide 56

Slide 56 text

Copyright© M&Aクラウド データフィルタリングとパフォーマンス最適化 56 解決策:アプリではなく、DBにフィルタリングを任せる ✅ DBが最初から必要なデータだけを抽出するので、超高速 ✅ DBの機能を使うため、ページネーションも正しく機能する

Slide 57

Slide 57 text

Copyright© M&Aクラウド アーキテクチャ: "Context"でMiddlewareとRepositoryを疎に繋ぐ 57

Slide 58

Slide 58 text

Copyright© M&Aクラウド STEP①: Middlewareで、リクエスト固有の権限をContextに預ける 58 PermissionContextへのコンテキスト設定

Slide 59

Slide 59 text

Copyright© M&Aクラウド STEP②: Repositoryが、Context経由で権限フィルターを適⽤ 59

Slide 60

Slide 60 text

Copyright© M&Aクラウド STEP②: Repositoryが、Context経由で権限フィルターを適⽤ 60 RepositoryはDIされたContextを使うだけ。 Middlewareのことは何も知りません。

Slide 61

Slide 61 text

Copyright© M&Aクラウド データフィルタリングとパフォーマンス最適化 61

Slide 62

Slide 62 text

Copyright© M&Aクラウド STEP③: そして、これがWHERE句を動的に組み⽴てる⼼臓部! 62 Contextから受け取った権限ポリシーに応じて、 Laravel のクエリビルダを使い、最適な WHERE句を動的に組み 立てています。 これにより、DBへの問い合わせを最小限に抑えること ができる!

Slide 63

Slide 63 text

Copyright© M&Aクラウド まとめ 63

Slide 64

Slide 64 text

Copyright© M&Aクラウド 複雑な権限を「スッキリ解きほぐす」ために 64 本⽇は、20万近い組み合わせパターンから始まった、複雑な権限要件という「絡 まった⽷」に、私たちがどう⽴ち向かったかをお話ししました 。 この⽷を「スッキリ解きほぐす」ための答えは、魔法のような特効薬ではありま せんでした。 それは、「徹底的に『分ける』」ことと「正しく『繋ぐ』」こと。この2つの地 道な原則の積み重ねにありました。

Slide 65

Slide 65 text

Copyright© M&Aクラウド Step 1:徹底的に「分けて」考える 65 巨⼤で捉えどころのない問題を、扱えるサイズに「分け」ていきました。 ● 要件を「分けて」可視化する ○ 権限要件を5軸に分け、課題の⼤きさを数値で明確に ● モデルを「分けて」シンプルにする ○ 当初⼀体化して失敗した「オブジェクト」と「スコープ」を分離 ● 問題発覚時の迅速な⽅向転換 ○ 肥⼤化したMiddlewareを「⾨番」「司令塔」「専⾨家」に分け、各ク ラスが単⼀責務を持つように設計

Slide 66

Slide 66 text

Copyright© M&Aクラウド Step 2:正しく「繋いで」動かす 66 次に、分離したコンポーネントを、あるべき姿に「繋ぎ」合わせました。 ● 強⼒なエンジンで「繋ぐ」 ○ 分離した権限ルールを、Casbinというエンジンで繋ぎ、判定ロジック のコアをシンプルに保ちました ● 疎なインターフェースで「繋ぐ」 ○ ObjectIdentifierなど、各クラスをインターフェースで疎に繋ぐこと で、拡張性とテスト容易性を両⽴ ● Contextでレイヤー間を「繋ぐ」 ○ PermissionContextを導⼊し、MiddlewareとRepositoryという異な る関⼼事を疎に繋ぎ、DBへの権限フィルター移譲を実現

Slide 67

Slide 67 text

Copyright© M&Aクラウド 「スッキリ解きほぐす」とは? 67 絡まった⽷を、 丁寧に⾒極め、「分ける」。 そして、あるべき姿に「繋ぎ直す」。 複雑な課題解決の本質は、この地道な繰り返しにあると考えています。

Slide 68

Slide 68 text

Copyright© M&Aクラウド ありがとうございました! 68

Slide 69

Slide 69 text

Copyright© M&Aクラウド 付録 69

Slide 70

Slide 70 text

Copyright© M&Aクラウド 想定Q&A 70 ● Q: ⽐較検討したライブラリは他には何があったのか? ● Q: 全体の流れを把握したいです ● Q: キャッシュ戦略は? ● Q: フロントエンドでの権限制御は? ● Q: 品質向上の取り組みは?

Slide 71

Slide 71 text

Copyright© M&Aクラウド Q: ⽐較検討したライブラリは他には何があったのか? 71 ライブラリ モデル対応 主な対象⾔語 ⻑所 短所 適合度 Casbin ACL / RBAC / ABAC / 任意拡張 Go (core) 他に PHP, Java, Node など 10 以上 マルチモデル‧軽量 組込‧⾼性能;PHP バインディングあり DSL 構⽂が独特で学 習コストやや⾼ ◎(採⽤) Laravel Policy & Gate ACL(基本的なアクセ ス制御) PHP / Laravel 標準機 能 追加パッケージ不要 ‧学習コスト低 ‧Eloquentモデルと の親和性⾼ 複雑なRBAC/ABAC不 可‧階層的権限管理 困難‧⼤規模権限管 理には機能不⾜ △(基本的な権限管 理のみ) Spatie laravel-permission RBAC(ロール+パー ミッション) PHP / Laravel Laravel Gate との親 和性∕学習コスト低 ABAC不可‧階層/属 性表現が弱い ○(Laravel 単体なら ⼿軽) Bouncer RBAC + きめ細かい "ability" 概念 PHP / Laravel 否定権限・モデル単位 許可など表現力高 ABAC不可・階層/属性 表現が弱い ○(Laravel 単体なら手 軽) Oso / Oso Cloud RBAC / ABAC / ReBAC(Polar DSL) Node, Go, Rust, Python, Java ほか "Polar" DSL が可読性 高い・クラウド/ローカル 混在可 PHP バインディング無 し、SaaS 料金高め △(言語制約)

Slide 72

Slide 72 text

Copyright© M&Aクラウド Q: 全体の流れを把握したいです 72

Slide 73

Slide 73 text

Copyright© M&Aクラウド Q: キャッシュ戦略は? 73 ● バックエンドでは、利⽤していない。 ○ 権限機能はセキュリティが重要であり、キャッシュは正しく実装しない と漏洩のリスクが伴うため、現時点では利⽤していない ○ パフォーマンス最適化のためにいずれ利⽤する可能性はある ● フロントエンドでは、利⽤している。 ○ コンポーネントの表⽰判定のために、権限データを毎回バックエンドに リクエストしていては、パフォーマンスに影響するため ○ もし意図しないコンポーネントを表⽰してしまっても、バックエンドで 防ぐことができるので、リスクは少ない

Slide 74

Slide 74 text

Copyright© M&Aクラウド Q: フロントエンドでの制御は? 74 A. 制御しています。 なぜ制御しているのか?:UXを損なう不適切なUI表⽰になるため ● バックエンドで権限エラーになる前に、ユーザーに「できないこと」を明⽰ することで、UXを向上させたい ● しかし、UIの表⽰制御ロジックがフロントエンドに散らばったり、バックエ ンドの権限ロジックと乖離するリスクがある

Slide 75

Slide 75 text

Copyright© M&Aクラウド Q: フロントエンドでの権限制御は? 75 解決策:権限APIとクライアントサイドでの制御 ● 特定の操作(「編集」「削除」「新規作成」など)に対して現在のユーザー が権限を持っているか否かを返すAPIエンドポイントを⽤意 ● フロントエンド(SvelteKitなど)がこのAPIを呼び出し、その結果に基づい てUI要素(ボタン、メニュー、フォームフィールドなど)を動的に⾮表⽰ 化、⾮アクティブ化、または表⽰する

Slide 76

Slide 76 text

Copyright© M&Aクラウド フロントエンド権限制御設計のポイント 76 ● セキュリティ ○ フロントエンド:UI制御のみ ○ バックエンド:実際のセキュリティ担保 ● パフォーマンス ○ ポリシーキャッシングで⾼速化 ○ 重複リクエストの防⽌ ● 保守性 ○ コンポーネントベースで再利⽤可能 ○ 宣⾔的な権限制御

Slide 77

Slide 77 text

Copyright© M&Aクラウド フロントエンド権限制御 77

Slide 78

Slide 78 text

Copyright© M&Aクラウド Canコンポーネント:宣⾔的な権限制御UI 78

Slide 79

Slide 79 text

Copyright© M&Aクラウド Canコンポーネント:宣⾔的な権限制御UI 79 ● 宣言的な権限チェック ● 非同期処理のサポート ● ローディング・エラー状態の制御

Slide 80

Slide 80 text

Copyright© M&Aクラウド usePermissionCheck:権限チェックの中核ロジック 80 メインロジック

Slide 81

Slide 81 text

Copyright© M&Aクラウド usePermissionCheck:権限チェックの中核ロジック 81 ポリシーマッチング ● 単一・複数権限チェック対応 ● フィーチャーフラグによる機能制御 ● ワイルドカード( *)によるフレキシブルなマッチング

Slide 82

Slide 82 text

Copyright© M&Aクラウド Policy Store:パフォーマンスを重視したポリシー管理 82 ストア構造 キャッシング戦略

Slide 83

Slide 83 text

Copyright© M&Aクラウド Policy Store:パフォーマンスを重視したポリシー管理 83 ストア構造 キャッシング戦略 ● Svelteストアベースの状態管理 ● インメモリキャッシングでパフォーマンス向上 ● 重複リクエストの防止 ● SSR対応

Slide 84

Slide 84 text

Copyright© M&Aクラウド DoD(Definition of Done)チェックリスト 84 コンポーネント Unit DB Integration Feature 新規Object追加時 ObjectIdentifier実装 ✅ ー ー ✅ 新規作成 SQLフィルタリング ー ✅ ー ✅ 更新 APIエンドポイント ー ー ✅ ✅ 更新

Slide 85

Slide 85 text

Copyright© M&Aクラウド Q: 品質向上の取り組みは? 85 ● ⽬的: 実装の⼿間や抜け漏れを防ぐための包括的アプローチ ● 3つの柱 ○ テスト戦略 ■ テストピラミッドによる効率的なテスト設計 ○ DoD(Definition of Done)チェックリスト ■ 新規権限対象追加時の必須項⽬ ○ ⽣成AI活⽤による効率化 ■ テンプレートクラスの⾃動⽣成

Slide 86

Slide 86 text

Copyright© M&Aクラウド DoD(Definition of Done)チェックリスト 86 ● アジャイル開発でのDoD運⽤体制 ○ PBI完了条件: JIRAのPBIにDoD条件を明記 ○ チームルール: DoD未達成のPBIはDone扱いしない

Slide 87

Slide 87 text

Copyright© M&Aクラウド DoD(Definition of Done)チェックリスト 87 JIRAのPBIテンプレート例

Slide 88

Slide 88 text

Copyright© M&Aクラウド プロンプトテンプレートによる開発時間の⼤幅短縮 88 実装⽣成プロンプト

Slide 89

Slide 89 text

Copyright© M&Aクラウド プロンプトテンプレートによる開発時間の⼤幅短縮 89 テスト⽣成プロンプト ● 一回の実行で必要な全てのクラス・テス トを生成 ● 実装パターンの統一化 ● 開発時間の大幅短縮

Slide 90

Slide 90 text

Copyright© M&Aクラウド 参考資料 ● casbin:https://casbin.org/ja ● php-casbin:https://github.com/php-casbin/php-casbin ● コード画像化ツール:https://chalk.ist/ ● Mermaidツール:https://mermaid.live/