制約が導く迷わない設計 〜 信頼性と運用性を両立するマイナンバー管理システムの実践 〜

生成AIがコードや選択肢を提示できる時代だからこそ、人間には「ガードレールの設定」と「責任ある意思決定」がより強く求められています。

本資料では、設計判断における迷いをなくすため、法令・ビジネス・技術など5つの「制約」を判断軸として活用するフレームワークを解説。AIに「調査と提案」を任せ、人間が「制約による絞り込み」と「最終決定」を担うための実践論について紹介します。

Transcript

1. 制約が導く迷わない設計 信頼性と運用性を両立する マイナンバー管理システムの実践 Dress Code 株式会社 / Product & Technology ないとー（内藤 翔太） 1
2. © Dress Code Inc . • 業務 ◦ HR領域のプロダクト開発 ◦ 共通基盤的な仕組み作り ◦ 技術広報 • 経歴 ◦ 2023/04 レバテック株式会社 ◦ 2025/07 Dress Code株式会社 • 技術 ◦ アーキテクチャが好き • 趣味 ◦ 美味しいご飯 / お酒 自己紹介 ないとー(@_bwkw_) 2
3. © Dress Code Inc . 会社・事業紹介 3
4. © Dress Code Inc . 14.1億円　 資金調達を実施 Pre Seed&Seed Round 200+社 が利用中　 Number of companies Number of countries 5カ国 で事業を展開　 Dress Code　会社概要 Company Name / 会社名 Dress Code 株式会社 2024年9月（正式創業：2025年4月） 23名 東京都中央区築地2-1-4 銀座PREX East 8F CEO / 代表取締役 Date of establishment / 設立年月 Location / 所在地 江尻 祐樹 Member / メンバー数 4
5. © Dress Code Inc . 挑戦する事業ドメイン/マーケット Dress Code は、従業員の「入社から退職まで」をすべて管理する グローバル(まずはアジア)なワークフォースマネジメントプラットフォーム Asia to Global Workforce Management領域 労務 管理 育成/ 定着 人事/ 配置 採用 管理 拠点/ 環境 プロ ジェ クト 福利 厚生 ITツール /備品 外部 人材 活用 セキュ リティ /ガバナ ンス 【Entry】 入社/入場 【Retire】 退職/退場 ライフサイクル × 5
6. © Dress Code Inc . デジタル化に伴う社会課題 -「摩擦問題」 - SaaS/ツール乱立に伴い、システムの分断・業務のサイロ化が進む 採用 部門 法務 部門 労務 部門 人事 部門 情報 システム 部門 総務 部門 採用管理 システム 契約管理 システム 労務管理 システム 勤怠管理 システム SaaS管理 システム デバイス 管理台帳 採用関連データ 契約関連データ 労務関連データ 勤怠関連データ SaaS関連データ デバイス関連データ ツールの乱立で、使いこなせない/慣れるのまでに時間がかかる ツール/部門間のアナログ連携が大変 担当間/部門間の摩擦が増大している 各業務担当者 経営/管理部全体 最適なSaaSを選定することが困難 データが散在していて利用/活用できない 連携/メンテのためのコスト(時間・お金)が膨大 ❌
 分断
 ❌
 分断
 ❌
 分断
 ❌
 分断
 ❌
 分断
 6
7. © Dress Code Inc . 7
8. © Dress Code Inc . 8
9. © Dress Code Inc . 9
10. © Dress Code Inc . 10 マイナンバー管理システムにて...
11. © Dress Code Inc . 11 多くの設計判断が求められた • どの範囲 / どのレイヤーまで暗号化を適用するか？ • テナントごとのデータ分離をどこまでやるか？ • どの操作を、どの粒度 / 保存期間で監査ログとして記録するか？ • アクセス制御と権限管理をどこまで厳密にやるか？ …
12. © Dress Code Inc . 12 設計判断で起こりがちなこと 判断軸が曖昧 → 何を基準に決めればいいかわからない → 決めきれず迷い続ける or とりあえず場当たりで決めてしまう ＋ なぜその案を採用したのか、後から説明できない
13. © Dress Code Inc . 13 ただマイナンバー管理システムでは迷いづらかった 個人情報保護委員会のガイドラインをはじめとして 「制約」を網羅的に洗い出した https://www.ppc.go.jp/files/pdf/2506_my_number_guideline_jigyosha.pdf 判断軸が決まり、設計判断で迷いづらかった
14. © Dress Code Inc . 14 本日は 制約で設計判断を進めるお話 +α
15. © Dress Code Inc . 15 1. 制約を使って、設計判断を進める ・理論：制約 → 設計判断の3ステップ ・実践：マイナンバー管理システムでのケーススタディ 2. それでも残る判断と、どう向き合うか？ 3. まとめ アジェンダ
16. © Dress Code Inc . 16 制約を使って、設計判断を進める 〜 理論：制約 → 設計判断の3ステップ 〜
17. © Dress Code Inc . • 制約とは？ ◦ ある条件や枠をもうけて、自由な活動や物事の成立をおさえつけること （Wikipedia） ＝ 外部から課される、設計判断の自由度を制限するもの ex）法令、予算 • 制約を見落とすと何が起きるか？ ◦ 法令を見落とす → 企業としての社会的信用を毀損する ◦ 予算を見落とす → 実現不可能な案を検討して時間とコストを浪費する → 制約を網羅的に洗い出すことが、設計判断の第一歩 17 制約とは何か？
18. © Dress Code Inc . 法令・規制：義務・禁止など、法律やガイドラインで定められた遵守事項 例：暗号化（PPC ガイドライン）、第三者提供には本人同意必須（個人情報保護法） ビジネス要件：SLA・予算・納期など、事業として守るべき数値や期限 例：SLA 99.9%、インフラ月額予算 $500 以内、リリース期限 3月末 技術環境：技術スタック・インフラなど、既に決まっている環境や依存関係 例：本番環境は AWS、DB は PostgreSQL、既存の認証基盤と連携必須 チーム・体制： 人員・スキル・承認フローなど、チームとして対応できる体制 例：セキュリティ担当は兼務1名、本番デプロイはSREチーム承認必須 運用：実施頻度・対応時間など、継続的に守るべき運用基準 例：鍵ローテーションは四半期ごと、障害復旧は4時間以内 18 制約の5つの種類
19. © Dress Code Inc . 法令・規制：信頼性 例：暗号化（PPC ガイドライン）、第三者提供には本人同意必須（個人情報保護法） ビジネス要件：信頼性 例：SLA 99.9%、インフラ月額予算 $500 以内、リリース期限 3月末 技術環境：運用性 例：本番環境は AWS、DB は PostgreSQL、既存の認証基盤と連携必須 チーム・体制：運用性 例：セキュリティ担当は兼務1名、本番デプロイはSREチーム承認必須 運用：運用性 例：鍵ローテーションは四半期ごと、障害復旧は4時間以内 19 制約の5つの種類 〜信頼性と運用性にどう寄与するか？~
20. © Dress Code Inc . 除外として効く制約 数値・禁止ルールが明らかで、選択肢に入らない案が即座に判断できる 例 ・法令 「個人情報保護法」で個人情報の第三者提供は本人同意が必須 　　→ 無同意での API 提携は即除外 ・技術「本番環境は AWS」→ GCP 前提の案は基本的に即除外 比較として効く制約 定義はあるが、複数の案を「見比べて」初めて効果が分かる（＝トレードオフ） 例 ・ビジネス「予算が潤沢ではない」 → 案ごとに総所要コストを比較 ・チーム「チームが他案件も抱えている」→ 案ごとに運用負荷を比較 20 制約の2つの効き方
21. © Dress Code Inc . 除外として効く制約 比較として効く制約 法令・規制 ・個人情報取扱事業者は、次に掲げる場合 を除くほか、あらかじめ本人の同意を得な いで、個人データを第三者に提供してはな らない。（個人情報保護法第二十七条） （法令は基本的に除外として効く） ビジネス要件 ・月額 $500 以内 ・SLA 99.9% ・リリース期限 3月末 ・予算が潤沢ではない 技術環境 ・AWS 利用 ・PostgreSQL 必須 ・既存認証基盤との連携必須 ・既存システムからの移行が必要 チーム・体制 ・兼務1名で運用可能な複雑さに留める ・本番デプロイは SRE チーム承認必須 ・チームが他案件も抱えている 運用 ・鍵ローテーション 3ヶ月ごと ・障害復旧時間（RTO）4時間以内 ・インシデント対応時に影響範囲の報告が必要 21 制約の種類 × 効き方のマトリクス 種類 効き方
22. © Dress Code Inc . 1. 制約を見つける 「5つの種類」で制約を洗い出し、「2つの効き方」で整理する 2. 選択肢を出して、除外する 設計案を列挙し、「除外として効く制約」で NG 案を落とす 3. 比較して、選ぶ 「比較として効く制約」と制約以外の観点で設計案を比較し、 最適解を選ぶ 22 制約 → 設計判断の3ステップ
23. © Dress Code Inc . 23 制約を使って、設計判断を進める 〜 実践：マイナンバー管理システムでのケーススタディ 〜
24. © Dress Code Inc . 24 Q. マイナンバーデータを暗号化するか？ 　 暗号化するならどうやって暗号化するか？ 　　　　（※ あくまでケーススタディです）
25. © Dress Code Inc . 1. 制約を見つける 「5つの種類」で制約を洗い出し、「2つの効き方」で整理する 2. 選択肢を出して、除外する 設計案を列挙し、「除外として効く制約」で NG 案を落とす 3. 比較して、選ぶ 「比較として効く制約」と制約以外の観点で設計案を比較し、 最適解を選ぶ 25 制約 → 設計判断の3ステップ
26. © Dress Code Inc . 26 1. 制約を見つける 除外として効く制約 比較として効く制約 法令・規制 ・暗号化は実質必須 　・番号法「適切な管理措置」 　・個人情報保護委員会のガイドライン 「暗号化又はパスワードによる保護を推奨」 （法令は基本的に除外として効く） ビジネス要件 - ・予算が潤沢ではない 技術環境 ・AWS 利用 - チーム・体制 ・兼務1名で運用可能な複雑さに留める - 運用 - ・インシデント対応時に影響範囲の報告が必要 種類 効き方
27. © Dress Code Inc . 1. 制約を見つける 「5つの種類」で制約を洗い出し、「2つの効き方」で整理する 2. 選択肢を出して、除外する 設計案を列挙し、「除外として効く制約」で NG 案を落とす 3. 比較して、選ぶ 「比較として効く制約」と制約以外の観点で設計案を比較し、 最適解を選ぶ 27 制約 → 設計判断の3ステップ
28. © Dress Code Inc . 28 2. 選択肢を出して、除外する 前提 既存システムに AWS KMS キーが存在する 選択肢 • 暗号化しない • GCP Cloud KMS で管理 • AWS CloudHSM で管理 • 既存の AWS KMS キーを使い回す • マイナンバー専用の AWS KMS キーを新設 • 秘匿レベル別の AWS KMS キーを新設
29. © Dress Code Inc . 29 前提 既存システムに AWS KMS キーが存在する 選択肢 • 暗号化しない → 法令「暗号化は実質必須」✗ 除外 • GCP Cloud KMS で管理 → 技術「AWS 利用」✗ 除外 • AWS CloudHSM で管理 → チーム「兼務1名で運用可能な複雑さに留める」✗ 除外 • 既存の AWS KMS キーを使い回す • マイナンバー専用の AWS KMS キーを新設 • 秘匿レベル別の AWS KMS キーを新設 2. 選択肢を出して、除外する
30. © Dress Code Inc . 1. 制約を見つける 「5つの種類」で制約を洗い出し、「2つの効き方」で整理する 2. 選択肢を出して、除外する 設計案を列挙し、「除外として効く制約」で NG 案を落とす 3. 比較して、選ぶ 「比較として効く制約」と制約以外の観点で設計案を比較し、 最適解を選ぶ 30 制約 → 設計判断の3ステップ
31. © Dress Code Inc . 31 3. 比較して、選ぶ • 既存の KMS キーを使い回す ◦ ビジネス「予算が潤沢ではない」◎ 追加コストなし ◦ 運用「インシデント対応時に影響範囲の報告が必要」✗ 爆発半径大 • マイナンバー専用の KMS キーを新設 ◦ ビジネス「予算が潤沢ではない」◦ 追加コスト小 ◦ 運用「インシデント対応時に影響範囲の報告が必要」◦ 爆発半径を限定できる • 秘匿レベル別の KMS キーを新設 ◦ ビジネス「予算が潤沢ではない」◦ 追加コスト小 ◦ 運用「インシデント対応時に影響範囲の報告が必要」 ◦ 爆発半径を限定できる
32. © Dress Code Inc . 32 3. 比較して、選ぶ • 既存の KMS キーを使い回す ◦ ビジネス「予算が潤沢ではない」◎ 追加コストなし ◦ 運用「インシデント対応時に影響範囲の報告が必要」✗ 爆発半径大 ◦ 制約以外の観点「後から拡張できるか？」✗ 混在状態から分離するのが大変 • マイナンバー専用の KMS キーを新設 ◦ ビジネス「予算が潤沢ではない」◦ 追加コスト小 ◦ 運用「インシデント対応時に影響範囲の報告が必要」◦ 爆発半径を限定できる ◦ 制約以外の観点「後から拡張できるか？」◦ 必要になったら秘匿別に移行可能 • 秘匿レベル別の KMS キーを新設 ◦ ビジネス「予算が潤沢ではない」◦ 追加コスト小 ◦ 運用「インシデント対応時に影響範囲の報告が必要」 ◦ 爆発半径を限定できる ◦ 制約以外の観点「後から拡張できるか？」△ 最初から完成形
33. © Dress Code Inc . 33 3. 比較して、選ぶ • 既存の KMS キーを使い回す ◦ ビジネス「予算が潤沢ではない」◎ 追加コストなし ◦ 運用「インシデント対応時に影響範囲の報告が必要」✗ 爆発半径大 ◦ 制約以外の観点「後から拡張できるか？」✗ 混在状態から分離するのが大変 • マイナンバー専用の KMS キーを新設 ◦ ビジネス「予算が潤沢ではない」◦ 追加コスト小 ◦ 運用「インシデント対応時に影響範囲の報告が必要」◦ 爆発半径を限定できる ◦ 制約以外の観点「後から拡張できるか？」◦ 必要になったら秘匿別に移行可能 • 秘匿レベル別の KMS キーを新設 ◦ ビジネス「予算が潤沢ではない」◦ 追加コスト小 ◦ 運用「インシデント対応時に影響範囲の報告が必要」 ◦ 爆発半径を限定できる ◦ 制約以外の観点「後から拡張できるか？」△ 最初から完成形 現時点で同等の秘匿性のデータを扱う予定もないし 万が一必要になっても移行可能なので
34. © Dress Code Inc . 34 制約で絞り込んでも、最後に残るのは判断 • 制約を考えることは重要 ◦ 制約を見逃すとコンプライアンス違反、リソース浪費、手戻りのようなリスクが 生じるので、設計判断において制約を考えることは重要 • それでも制約だけでは決まらないことが多い ◦ 制約で絞った選択肢の中で、他観点も踏まえたトレードオフを考慮する必要ある ◦ 最終的には、設計者の判断が求められる
35. © Dress Code Inc . 35 制約で絞り込んでも、最後に残るのは判断 • 制約を考えることは重要 ◦ 制約を見逃すとコンプライアンス違反、リソース浪費、手戻りのようなリスクが 生じるので、設計判断において制約を考えることは重要 • それでも制約だけでは決まらないことが多い ◦ 制約で絞った選択肢の中で、他観点も踏まえたトレードオフを考慮する必要ある ◦ 最終的には、設計者の判断が求められる
36. © Dress Code Inc . 36 それでも残る判断と、どう向き合うか？
37. © Dress Code Inc . 1. 事前：判断力を育てる 2. 判断時：可逆性を高める 3. 事後：判断を記録する 37 判断とどう向き合うか？
38. © Dress Code Inc . 38 1. 事前：判断力を育てる ref: https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition
39. © Dress Code Inc . 39 1. 事前：判断力を育てる 他にも • 小さな判断で「意図的な練習」を繰り返す • 既存の ADR を読み解いて、他の人の判断プロセスを追体験する • ポストモーテムを読み、ズレていた部分を分解してトレースする …
40. © Dress Code Inc . 40 2. 判断時：可逆性を高める 決定を簡単に変更できる場合、決定を正しく行う重要性は低くなり、作業がはるか にシンプルになります。進化的設計の帰結として、設計者は決定の不可逆性を回避 する方法を考える必要があります。今すぐ正しい決定を下そうとするのではなく、 決定を後回しにする方法（より多くの情報が得られるまで）を探すか、後になって もそれほど困難なく変更できるような方法で決定を下す必要があります。 　　　　　　　　Is Design Dead? / Martin Fowler(2004) ref: https://martinfowler.com/articles/designDead.html
41. © Dress Code Inc . 41 2. 判断時：可逆性を高める 間違った(かもしれない)意思決定があったとき、 それ自体が責められるべきではなく、 間違った意思決定を修正できないことのほうが問題なのです。 ref: https://qiita.com/hirokidaichi/items/a746062917595619720b
42. © Dress Code Inc . 42 3. 事後：判断を記録する ADR = Architecture Decision Record 「なぜこの設計にしたか？」を記録するドキュメント • Status（ステータス） • Context（背景・文脈） • Considered Options（検討した選択肢） • Decision（決定） • Consequences（結果・影響）
43. © Dress Code Inc . 43 Dress Code では... ADR = Any Decision Record 「決定事項をなんでも」記録するドキュメント • 開発に関することはなんでも記録するように • あえて雑多にすることで書くハードルが下がった • 特に複数人が触る領域は ADR を残すような力が働くように • 直接関わりがないプロダクトでも何が起こっているのか追えるように
44. © Dress Code Inc . 44 ADR 読み合わせ会 「3. 判断を記録する」 + 「1. 判断力を育てる」を両立できる実践 ▪ 週1回30分 • 新しい ADR をチームで共有 • 他メンバーに FB をもらう ▪ 効果 • ADR を書くモチベーションになる • 他の人の判断プロセスを追体験する
45. © Dress Code Inc . 45 ADR 読み合わせ会 「3. 判断を記録する」 + 「1. 判断力を育てる」を両立できる実践 ▪ 週1回30分 • 新しい ADR をチームで共有 • 他メンバーに FB をもらう ▪ 効果 • ADR を書くモチベーションになる • 他の人の判断プロセスを追体験する 河村の発表もご参照ください ドキュメントはAIの味方！スタートアップのアジャイルを加速するADR
46. © Dress Code Inc . 46 まとめ
47. © Dress Code Inc . • 制約を使って、設計判断を進める ◦ 制約を見逃すとコンプライアンス違反、リソース浪費、手戻りのようなリスクが 生じるので、設計判断において制約を考えることは重要 ◦ 5つの種類（法令・ビジネス・技術・チーム・運用）で棚卸しする ◦ 2つの効き方（除外として効く / 比較として効く）を見分ける ◦ 除外で選択肢を絞り込み、比較して最適解を選ぶ • それでも残る判断と、どう向き合うか？ ◦ 事前：判断力を育てる ◦ 判断時：可逆性を高める ◦ 事後：判断を記録する 47 まとめ
48. © Dress Code Inc . 48 AI 時代だからこそ、判断力が問われる • 設計判断における AI と人間の責務 ◦ AI の責務：調査する、選択肢を出す ◦ 人間の責務：AI にガードレールを引く、最終決定に責任を負う • 人間の責務を果たすために ◦ 制約を見つけて、選択肢を絞り込む 　　＝AI にガードレールを引く ◦ 判断力を育てて、判断を記録する 　　＝最終決定に責任を負う
49. © Dress Code Inc . 49 🎉 宣伝 🎉
50. © Dress Code Inc . 50 ”グローバル”に挑戦する仲間を募集しています！ • SRE • PdM（プロダクトマネージャー） • プロダクトエンジニア • AI エンジニア • プロダクトデザイナー • etc… Dress Code イベント登壇情報まとめ
51. © Dress Code Inc . 51 ご清聴ありがとうございました！！！ ブースや懇親会等でもお話ししましょう！