設計の本質：コード、システム、そして組織へ / The Essence of Design: To Code, Systems, and Organizations

Qiita Conference 2025 における発表の資料です。
設計とはなんだろうか、というお話をしています

# プロポーザル
https://qiita.com/official-campaigns/conference/2025#day1

設計とは単なる技術的な構造を定める行為ではなく、未来を見据えた計画そのものです。
コードを書く段階での意図、システム全体を俯瞰するアーキテクチャの構想、さらには組織や経営に至るまで、設計はさまざまなレイヤーで行われています。
本講演では私のこれまでのコンフォートゾーン脱却の遍歴から、設計という概念を多角的に捉え、それぞれの立場で相対する設計とテーマについて考察します。
この講演を通じて、設計という営みの本質への学びと、次のステージへ踏み出すための勇気を共有できれば幸いです。

# URL
YouTube: https://www.youtube.com/c/narusemi
HomePage: https://nrslib.com
Twitter: https://twitter.com/nrslib
Instagram: https://www.instagram.com/nrslib/

Transcript

1. nrs 設計の本質：コード、システム、そして組織へ
2. 2 Profile nrs（成瀬 允宣） @nrslib 株式会社コドモン 執行役員CTO 趣味： カンファレンス講演 学生支援 小学校支援 写真
3. 3 Profile nrs（成瀬 允宣） @nrslib 株式会社コドモン 執行役員CTO 趣味： カンファレンス講演 学生支援 小学校支援 写真
4. 4 今日のお話
5. 5 今日のお話
6. 6 今日のお話
7. 7 今日のお話
8. 8 今日のお話
9. 設計とは いろんな計画行為の確認 個人史から学ぶ計画行為 まとめ 設計の本質：コード、システム、そして組織へ
10. 設計とは いろんな計画行為の確認 個人史から学ぶ計画行為 まとめ 設計の本質：コード、システム、そして組織へ
11. 設計とは
12. 12 • 設計とは…… 言葉の定義を確認する
13. 13 • 設計とは…… 言葉の定義を確認する 審美性を根源とする計画的行為
14. 14 • 審美性とは…… 言葉の定義を確認する
15. 15 • 審美性とは…… 言葉の定義を確認する 美に関する感覚や判断の性質を指す概念
16. 美しさはとっても便利
17. 17 • 美しさの便利なところを因数分解 なぜ美しさが？ １．感情的な共鳴と魅力 ２．コミュニケーションの効率化 ３．価値の付加 ４．機能性との補完 ５．人間の本能的な特性
18. 18 • 1. 感情的な共鳴と魅力 美しさの便利さを解説
19. 19 • 2. コミュニケーションの効率化 美しさの便利さを解説
20. 20 • 3. 価値の付加 美しさの便利さを解説
21. 21 • 4. 機能美との補完 美しさの便利さを解説
22. 22 • 5. 人間の本能と特性 美しさの便利さを解説
23. 23 • 美しさは効率性と持続性の鍵 美しさがもつ効果
24. 24 美しいものがもつ持続性の例 システィーナの聖母 ラファエロ・サンティ キリストの復活 ピエロ・デラ・フランチェスカ 牧場の聖母 ラファエロ・サンティ
25. 設計とは いろんな計画行為の確認 個人史から学ぶ計画行為 まとめ 設計の本質：コード、システム、そして組織へ
26. 26 • 設計とは…… 言葉の定義を再確認 審美性を根源とする計画的行為
27. 27 • わかりやすいもの いろんな計画的行為 ウェブデザイン
28. 28 • わかりやすいもの いろんな計画的行為 UX デザイン
29. 29 • わかりづらいもの いろんな計画的行為 オブジェクト指向設計
30. 30 • わかりづらいもの いろんな計画的行為 ドメイン駆動設計
31. 31 • わかりづらいもの いろんな計画的行為 組織設計
32. 設計とは いろんな計画行為の確認 個人史から学ぶ計画行為 まとめ 設計の本質：コード、システム、そして組織へ
33. 33 • よくあるキャリアラダーを登ってきました コンフォートゾーン脱却の歴史
34. 34 • よくあるキャリアラダーを登ってきました コンフォートゾーン脱却の歴史 メンバー →リーダー →アーキテクト →スタッフエンジニア →CTO
35. メンバー
36. 36 • 自問自答 メンバー 良いコードはどうすれば作れるのか
37. 37 • コードの将来を計画 コードレベルの計画 後続の開発者にどう読み解いてほしいか 改修の影響範囲をどう定めるか 予期された拡張にどのように備えるか
38. 38 • オブジェクト指向プログラミングに拘泥 コードレベルの計画 コードの意図を深く考える（読むとき／書くとき） テクニックや原則の背景を学ぶ デザインパターンの真意を学ぶ
39. リーダー
40. 40 • 自問自答 リーダー システムの持続可能性を高めるには どのような手段があるか
41. 41 • システムの将来を計画 システムレベルの計画 プロダクトの方向性に合わせる計画 ビジネスと開発のギャップを埋めるための計画
42. 42 • この出会いは運命だったのかもしれない ドメイン駆動設計との出会い この本に出会ったとき これこそが……！ まさに……！ ポエムかな？ と思った
43. 43 • この出会いは運命だったのかもしれない ドメイン駆動設計との出会い この本に出会ったとき これこそが……！ まさに……！ ポエムかな？ と思った
44. 44 • この出会いは運命だったのかもしれない ドメイン駆動設計との出会い この本に出会ったとき これこそが……！ まさに……！ ポエムかな？ と思った
45. 45 • しばらく積んだのち…… ドメイン駆動設計との出会い 読み方がわかると ソフトウェア開発と設計全般を 取り扱っていることがわかる
46. 46 • 優れた構造の計画 アーキテクチャレベルの計画 過度の複雑性から脱却し拡張性や優れた構造を計画 ソフトウェアアーキテクチャの文脈では システム全体の構成やコンポーネント間の関係を計画
47. 47 • ぱっと思いつくだけでも さまざまなアーキテクチャとの出会い レイヤードアーキテクチャ ヘキサゴナルアーキテクチャ オニオンアーキテクチャ GUIアーキテクチャパターン マイクロサービスアーキテクチャ イベント駆動アーキテクチャ ：
48. 48 • 個人的な当時の感想 さまざまなアーキテクチャとの出会い 思いついたものは大抵名前がついてる 先人の知恵ってスゲー
49. 49 • コンセプトは異なるが相対する課題は同じであることも多い ソフトウェアアーキテクチャの学び方 伝統的なレイヤードアーキテクチャよりも 洗練されたヘキサゴナルアーキテクチャ ↓ この裏を読むと レイヤードアーキテクチャがやりたかったことを ヘキサゴナルアーキテクチャはシンプルに実現
50. 50 • コンセプトは異なるが相対する課題は同じであることも多い ソフトウェアアーキテクチャの学び方 伝統的なレイヤードアーキテクチャよりも 洗練されたヘキサゴナルアーキテクチャ ↓ この裏を読むと レイヤードアーキテクチャがやりたかったことを ヘキサゴナルアーキテクチャはシンプルに実現
51. 51 • コンセプトは異なるが相対する課題は同じであることも多い ソフトウェアアーキテクチャの学び方 伝統的なレイヤードアーキテクチャよりも 洗練されたヘキサゴナルアーキテクチャ ↓ この裏を読むと レイヤードアーキテクチャがやりたかったことを ヘキサゴナルアーキテクチャはシンプルに実現
52. 52 • コンセプトは異なるが相対する課題は同じであることも多い ソフトウェアアーキテクチャの学び方 伝統的なレイヤードアーキテクチャよりも 洗練されたヘキサゴナルアーキテクチャ ↓ この裏を読むと レイヤードアーキテクチャがやりたかったことを ヘキサゴナルアーキテクチャはシンプルに実現
53. 53 • コンセプトは異なるが相対する課題は同じであることも多い ソフトウェアアーキテクチャの学び方 MVC, MVC2, MVP, MVVMなどの乱立後にMVWの考え方
54. アーキテクト
55. 55 • 自問自答 アーキテクト これまでなんだかんだでうまくいったけど 再現性あるのかな
56. 56 • 必要な取り組み 再現性の計画 共有と教育による標準化 ツールによる標準化 プロセスによる標準化
57. 57 • 共有と教育による標準化 再現性のための取り組み 伝える場・共有する場を作る
58. 58 • ツールによる標準化 再現性のための取り組み 開発／運用 ツール
59. 59 • プロセスによる標準化 再現性のための取り組み コードレビュー レトロスペクティブ
60. スタッフエンジニア
61. 61 • 自問自答 スタッフエンジニア 今私は何をすべきか
62. 62 • 抽象的で壮大な課題 高次元の計画 リソースをスケーラブルに 開発組織をスケーラブルに データの利活用を柔軟に
63. 63 • スケーラブルサービスの実現 抽象的で壮大な課題を解決するために リアクティブなシステム クラウドネイティブなシステム 処理レベルで分散可能な マイクロサービス https://www.reactivemanifesto.org/ja
64. 64 • 水の低きに就くが如し 抽象的で壮大な課題を解決するために 組織のコントロールは 川をイメージ 自分ならどう流れたいかな？ 人の気持ちを考える日々
65. 65 • データはあればいいってもんじゃない 抽象的で壮大な課題を解決するために 利活用しやすいデータの模索 欠落を防ぐアーキテクチャ 参照のための仕組み
66. CTO
67. 67 • 自問自答 CTOになることを決める前 •私はなにがしたいのか •より高次元のエンジニアリングに到達するには？
68. 68 • アプローチすべきは 高次元への到達を計画 経営戦略と技術戦略
69. 69 • 詳しく語ると１時間ぐらいかかるからここを見てくれ！ 高次元への到達を計画
70. 70 • 経営戦略が計画するもの（特に開発に関わる部分） 高次元への到達を計画 組織の目標達成への計画 リソースの配分 組織文化の形成
71. 71 • なにをベースに考えるのか 中長期目線の計画 その柱となるのは ミッションとヴィジョン
72. 72 • コドモンのミッションとヴィジョン 参考までに ◆ Mission ◆ 子どもを取り巻く環境をテクノロジーの力でよりよいものに ◆ Vision ◆ 子どもの育ちや学びを社会全体で支えられる世の中へ
73. 73 え？ そんなCTOはあんまり見たことないけど…‥？
74. 74 • 0->1 CTOの役割 スーパープログラマ
75. 75 • 1->10 CTOの役割 コードを書きながら 開発チームをリード
76. 76 • 10->100 CTOの役割 組織構築 マネジメント
77. 77 • 100->1000（コドモンはココ） CTOの役割 長期的な技術戦略 投資判断
78. 78 • なにをすべきか 100->1000のCTOをまっとうするために 「ビジネスのわかる開発者」になること
79. 79 続きはWebで イベントやります！ 成瀬の発表：ドメイン駆動設計とXPで支える子どもの未来〜保育の暗黙知を活かすシステム開発〜
80. 設計とは いろんな計画行為の確認 個人史から学ぶ計画行為 まとめ 設計の本質：コード、システム、そして組織へ
81. 81 • 設計は計画だ！ まとめ 再現可能で持続性のある力＝美しさを使った 計画行為
82. 82 • このセッションも計画しました！ 自己例証 あなたがいつでもコンフォートゾーンを脱却して 新たな挑戦へと勇気をもって踏み出せますように
83. 83 仲間を探しています 子どもを取り巻く環境をテクノロジーの力でよりよいものにしていく仲間を大募集！ • 子育てしやすい環境です ◦ 子育てにドメイン知識がありすぎるメンバー ◦ フレックス／フルリモート可 • 開発者体験が最高です ◦ アジャイル（XP） ◦ バーチャルオフィス（Gather） ◦ コンフォートゾーンを抜け出せるような環境 ◦ CTOが財布
84. てんぷれーと