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

by ないとー

Embed

Start on current slide

Slide 1

Slide 1 text

制約が導く迷わない設計信頼性と運用性を両立するマイナンバー管理システムの実践 Dress Code 株式会社 / Product & Technology ないとー（内藤翔太） 1

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© 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

Slide 5

Slide 5 text

© Dress Code Inc . 挑戦する事業ドメイン/マーケット Dress Code は、従業員の「入社から退職まで」をすべて管理するグローバル(まずはアジア)なワークフォースマネジメントプラットフォーム Asia to Global Workforce Management領域労務管理育成/ 定着人事/ 配置採用管理拠点/ 環境プロジェクト福利厚生 ITツール /備品外部人材活用セキュリティ /ガバナンス【Entry】入社/入場【Retire】退職/退場ライフサイクル × 5

Slide 6

Slide 6 text

© Dress Code Inc . デジタル化に伴う社会課題 -「摩擦問題」 - SaaS/ツール乱立に伴い、システムの分断・業務のサイロ化が進む採用部門法務部門労務部門人事部門情報システム部門総務部門採用管理システム契約管理システム労務管理システム勤怠管理システム SaaS管理システムデバイス管理台帳採用関連データ契約関連データ労務関連データ勤怠関連データ SaaS関連データデバイス関連データツールの乱立で、使いこなせない/慣れるのまでに時間がかかるツール/部門間のアナログ連携が大変担当間/部門間の摩擦が増大している各業務担当者経営/管理部全体最適なSaaSを選定することが困難データが散在していて利用/活用できない連携/メンテのためのコスト(時間・お金)が膨大 ❌  分断  ❌  分断  ❌  分断  ❌  分断  ❌  分断  6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© Dress Code Inc . ● 制約とは？ ○ ある条件や枠をもうけて、自由な活動や物事の成立をおさえつけること（Wikipedia）＝外部から課される、設計判断の自由度を制限するもの ex）法令、予算 ● 制約を見落とすと何が起きるか？ ○ 法令を見落とす → 企業としての社会的信用を毀損する ○ 予算を見落とす → 実現不可能な案を検討して時間とコストを浪費する → 制約を網羅的に洗い出すことが、設計判断の第一歩 17 制約とは何か？

Slide 18

Slide 18 text

© Dress Code Inc . 法令・規制：義務・禁止など、法律やガイドラインで定められた遵守事項例：暗号化（PPC ガイドライン）、第三者提供には本人同意必須（個人情報保護法）ビジネス要件：SLA・予算・納期など、事業として守るべき数値や期限例：SLA 99.9%、インフラ月額予算 $500 以内、リリース期限 3月末技術環境：技術スタック・インフラなど、既に決まっている環境や依存関係例：本番環境は AWS、DB は PostgreSQL、既存の認証基盤と連携必須チーム・体制：人員・スキル・承認フローなど、チームとして対応できる体制例：セキュリティ担当は兼務1名、本番デプロイはSREチーム承認必須運用：実施頻度・対応時間など、継続的に守るべき運用基準例：鍵ローテーションは四半期ごと、障害復旧は4時間以内 18 制約の5つの種類

Slide 19

Slide 19 text

© Dress Code Inc . 法令・規制：信頼性例：暗号化（PPC ガイドライン）、第三者提供には本人同意必須（個人情報保護法）ビジネス要件：信頼性例：SLA 99.9%、インフラ月額予算 $500 以内、リリース期限 3月末技術環境：運用性例：本番環境は AWS、DB は PostgreSQL、既存の認証基盤と連携必須チーム・体制：運用性例：セキュリティ担当は兼務1名、本番デプロイはSREチーム承認必須運用：運用性例：鍵ローテーションは四半期ごと、障害復旧は4時間以内 19 制約の5つの種類〜信頼性と運用性にどう寄与するか？~

Slide 20

Slide 20 text

© Dress Code Inc . 除外として効く制約数値・禁止ルールが明らかで、選択肢に入らない案が即座に判断できる例・法令「個人情報保護法」で個人情報の第三者提供は本人同意が必須　　→ 無同意での API 提携は即除外・技術「本番環境は AWS」→ GCP 前提の案は基本的に即除外比較として効く制約定義はあるが、複数の案を「見比べて」初めて効果が分かる（＝トレードオフ）例・ビジネス「予算が潤沢ではない」 → 案ごとに総所要コストを比較・チーム「チームが他案件も抱えている」→ 案ごとに運用負荷を比較 20 制約の2つの効き方

Slide 21

Slide 21 text

© Dress Code Inc . 除外として効く制約比較として効く制約法令・規制・個人情報取扱事業者は、次に掲げる場合を除くほか、あらかじめ本人の同意を得ないで、個人データを第三者に提供してはならない。（個人情報保護法第二十七条）（法令は基本的に除外として効く）ビジネス要件・月額 $500 以内・SLA 99.9% ・リリース期限 3月末・予算が潤沢ではない技術環境・AWS 利用・PostgreSQL 必須・既存認証基盤との連携必須・既存システムからの移行が必要チーム・体制・兼務1名で運用可能な複雑さに留める・本番デプロイは SRE チーム承認必須・チームが他案件も抱えている運用・鍵ローテーション 3ヶ月ごと・障害復旧時間（RTO）4時間以内・インシデント対応時に影響範囲の報告が必要 21 制約の種類 × 効き方のマトリクス種類効き方

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

© Dress Code Inc . 26 1. 制約を見つける除外として効く制約比較として効く制約法令・規制・暗号化は実質必須　・番号法「適切な管理措置」　・個人情報保護委員会のガイドライン「暗号化又はパスワードによる保護を推奨」（法令は基本的に除外として効く）ビジネス要件 - ・予算が潤沢ではない技術環境・AWS 利用 - チーム・体制・兼務1名で運用可能な複雑さに留める - 運用 - ・インシデント対応時に影響範囲の報告が必要種類効き方

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© Dress Code Inc . 29 前提既存システムに AWS KMS キーが存在する選択肢 ● 暗号化しない → 法令「暗号化は実質必須」✗ 除外 ● GCP Cloud KMS で管理 → 技術「AWS 利用」✗ 除外 ● AWS CloudHSM で管理 → チーム「兼務1名で運用可能な複雑さに留める」✗ 除外 ● 既存の AWS KMS キーを使い回す ● マイナンバー専用の AWS KMS キーを新設 ● 秘匿レベル別の AWS KMS キーを新設 2. 選択肢を出して、除外する

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© Dress Code Inc . 31 3. 比較して、選ぶ ● 既存の KMS キーを使い回す ○ ビジネス「予算が潤沢ではない」◎ 追加コストなし ○ 運用「インシデント対応時に影響範囲の報告が必要」✗ 爆発半径大 ● マイナンバー専用の KMS キーを新設 ○ ビジネス「予算が潤沢ではない」○ 追加コスト小 ○ 運用「インシデント対応時に影響範囲の報告が必要」○ 爆発半径を限定できる ● 秘匿レベル別の KMS キーを新設 ○ ビジネス「予算が潤沢ではない」○ 追加コスト小 ○ 運用「インシデント対応時に影響範囲の報告が必要」 ○ 爆発半径を限定できる

Slide 32

Slide 32 text

© Dress Code Inc . 32 3. 比較して、選ぶ ● 既存の KMS キーを使い回す ○ ビジネス「予算が潤沢ではない」◎ 追加コストなし ○ 運用「インシデント対応時に影響範囲の報告が必要」✗ 爆発半径大 ○ 制約以外の観点「後から拡張できるか？」✗ 混在状態から分離するのが大変 ● マイナンバー専用の KMS キーを新設 ○ ビジネス「予算が潤沢ではない」○ 追加コスト小 ○ 運用「インシデント対応時に影響範囲の報告が必要」○ 爆発半径を限定できる ○ 制約以外の観点「後から拡張できるか？」○ 必要になったら秘匿別に移行可能 ● 秘匿レベル別の KMS キーを新設 ○ ビジネス「予算が潤沢ではない」○ 追加コスト小 ○ 運用「インシデント対応時に影響範囲の報告が必要」 ○ 爆発半径を限定できる ○ 制約以外の観点「後から拡張できるか？」△ 最初から完成形

Slide 33

Slide 33 text

© Dress Code Inc . 33 3. 比較して、選ぶ ● 既存の KMS キーを使い回す ○ ビジネス「予算が潤沢ではない」◎ 追加コストなし ○ 運用「インシデント対応時に影響範囲の報告が必要」✗ 爆発半径大 ○ 制約以外の観点「後から拡張できるか？」✗ 混在状態から分離するのが大変 ● マイナンバー専用の KMS キーを新設 ○ ビジネス「予算が潤沢ではない」○ 追加コスト小 ○ 運用「インシデント対応時に影響範囲の報告が必要」○ 爆発半径を限定できる ○ 制約以外の観点「後から拡張できるか？」○ 必要になったら秘匿別に移行可能 ● 秘匿レベル別の KMS キーを新設 ○ ビジネス「予算が潤沢ではない」○ 追加コスト小 ○ 運用「インシデント対応時に影響範囲の報告が必要」 ○ 爆発半径を限定できる ○ 制約以外の観点「後から拡張できるか？」△ 最初から完成形現時点で同等の秘匿性のデータを扱う予定もないし万が一必要になっても移行可能なので

Slide 34

Slide 34 text

© Dress Code Inc . 34 制約で絞り込んでも、最後に残るのは判断 ● 制約を考えることは重要 ○ 制約を見逃すとコンプライアンス違反、リソース浪費、手戻りのようなリスクが生じるので、設計判断において制約を考えることは重要 ● それでも制約だけでは決まらないことが多い ○ 制約で絞った選択肢の中で、他観点も踏まえたトレードオフを考慮する必要ある ○ 最終的には、設計者の判断が求められる

Slide 35

Slide 35 text

© Dress Code Inc . 35 制約で絞り込んでも、最後に残るのは判断 ● 制約を考えることは重要 ○ 制約を見逃すとコンプライアンス違反、リソース浪費、手戻りのようなリスクが生じるので、設計判断において制約を考えることは重要 ● それでも制約だけでは決まらないことが多い ○ 制約で絞った選択肢の中で、他観点も踏まえたトレードオフを考慮する必要ある ○ 最終的には、設計者の判断が求められる

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© Dress Code Inc . 40 2. 判断時：可逆性を高める決定を簡単に変更できる場合、決定を正しく行う重要性は低くなり、作業がはるかにシンプルになります。進化的設計の帰結として、設計者は決定の不可逆性を回避する方法を考える必要があります。今すぐ正しい決定を下そうとするのではなく、決定を後回しにする方法（より多くの情報が得られるまで）を探すか、後になってもそれほど困難なく変更できるような方法で決定を下す必要があります。　　　　　　　　Is Design Dead? / Martin Fowler(2004) ref: https://martinfowler.com/articles/designDead.html

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© Dress Code Inc . 45 ADR 読み合わせ会「3. 判断を記録する」 + 「1. 判断力を育てる」を両立できる実践 ■ 週1回30分 ● 新しい ADR をチームで共有 ● 他メンバーに FB をもらう ■ 効果 ● ADR を書くモチベーションになる ● 他の人の判断プロセスを追体験する河村の発表もご参照くださいドキュメントはAIの味方！スタートアップのアジャイルを加速するADR

Slide 46

Slide 46 text

Slide 47

Slide 47 text

© Dress Code Inc . ● 制約を使って、設計判断を進める ○ 制約を見逃すとコンプライアンス違反、リソース浪費、手戻りのようなリスクが生じるので、設計判断において制約を考えることは重要 ○ 5つの種類（法令・ビジネス・技術・チーム・運用）で棚卸しする ○ 2つの効き方（除外として効く / 比較として効く）を見分ける ○ 除外で選択肢を絞り込み、比較して最適解を選ぶ ● それでも残る判断と、どう向き合うか？ ○ 事前：判断力を育てる ○ 判断時：可逆性を高める ○ 事後：判断を記録する 47 まとめ