開発サイクルと全体像、 完全に理解した。/ Comprehensive Understanding of the Development Cycle

このスライドは、2026/10/10 - 11 に開催された「技育祭 2026 秋」で発表したものです。

cf. https://geek.supporterz.jp/geeksai/2026autumn#timetable

Transcript

1. 開発サイクルと全体像、 完全に理解した。 #技育祭 2026【秋】 --- かず (@Guvalif)
2. ⾃⼰紹介：⾼瀬 和之 (かず) Profile { works = [ "IoT エンジニア", "フロントエンドエンジニア", "開発人事", "TechPM ⭐", "エンジニア育成 ⭐" ], memo = "公式メンターでいちばん学術派 (自称)" } 𝕏：@Guvalif
3. 本⽇のアジェンダ • 《プロダクト》のつくられ⽅を知る • 《モデリング》を知る • 《デザイン》を知る • 《エンジニアリング》を知る 質問はまとめて拾い上げるので、ぜひお気軽に Zoom のチャット欄へご投稿まで！🙌
4. 《プロダクト》のつくられ⽅を知る_
5. 例) プロダクトが持つ 3 つの抽象構造 特にソフトウェアの場合、抽象構造の集まりによってプロダクトは構成できる (※ 他にもさまざまな構造化が知られていますが、もっともシンプルな例の 1 つを紹介しています) プロダクト ユーザー プレゼンテーション 表層 を担う抽象構造 インタラクション 体験 を担う抽象構造 モデル 機能の中核 を担う抽象構造
6. ネットワークによって抽象構造は分離できる 物理世界から切り離して考えられることを利⽤し、抽象構造を物理的に分離 して、 ネットワークを介して繋げるようなつくり⽅もできる → これは Web アプリに⼀般的 プロダクト プレゼンテーション モデル インタラクション ネットワーク ユーザー ブラウザ サーバー
7. 例) 架空 Web 企業における職種と役割 プレゼンテーション / インタラクション プロダクトデザイナー Web フロントエンド エンジニア モバイルアプリケーション エンジニア プロダクト エンジニア 機能的 プロダクト マネージャー 専門的 FDE サーバーサイド エンジニア SRE モデル / ネットワーク
8. 《モデリング》を知る_
9. 再掲) プロダクトが持つ 3 つの抽象構造 "モデル" は機能の中核を担う抽象構造 のため、この部分のつくり⽅がプロダクトの 品質を左右しうる ... → モデリングの主たる関⼼ごとはこれ プロダクト ユーザー プレゼンテーション 表層 を担う抽象構造 インタラクション 体験 を担う抽象構造 モデル 機能の中核 を担う抽象構造
10. 良いモデルは、探索的かつ漸進的にしか⾒つかりづらい • プロの開発者であっても、良いモデルを⼀発で導き出せることは稀 • ときに課題‧要求分析まで⽴ち戻りながら、抽象構造を洗練させていく 課題・要求分析 ユースケース特定 ユースケース分析 モデリング ユーザーの抱える課題， もしくは満たしたい要求は 何か？を分析する 課題の解決や要求を満たす ために、プロダクト上で 必要なやり取りを特定する プロダクト上で必要な やり取りの中から、機能を 組成する概念を洗い出す 概念に名前をつけ、 概念同士の関係を示し、 概念に対する条件を調べる
11. モデリングまでの雰囲気を少しだけ ... "ユースケース特定" までが済んでいる前提で、例題からモデルを考えてみる 課題・要求分析 ユースケース特定 ユースケース分析 モデリング プロダクト上で必要な やり取りの中から、機能を 組成する概念を洗い出す 概念に名前をつけ、 概念同士の関係を示し、 概念に対する条件を調べる
12. 例) 割り勘アプリのモデルを考える 割り勘アプリに対して、次のようなユースケース (やり取り) を定めたとする： 0. (ここは現実世界のできごと) 幹事が、飲み会を開催する 1. 幹事は、⽀払区分 (多め / 普通 / 少なめ) ごとに⽀払割合を設定する 2. 幹事は、飲み会の参加者を追加 / 削除する 3. 幹事は、飲み会の参加者ごとに⽀払区分 (多め / 普通 / 少なめ) を設定する 4. 幹事は、飲み会の請求⾦額を設定する 5. 幹事は、飲み会の参加者ごとの⽀払⾦額を計算する See also: 例題で学ぶドメイン駆動設計
13. 例) 概念を洗い出す モデリングの前準備として、概念っぽいものに着⽬してみる： 0. (ここは現実世界のできごと) 幹事が、飲み会を開催する 1. 幹事は、⽀払区分 (多め / 普通 / 少なめ) ごとに⽀払割合を設定する 2. 幹事は、飲み会の参加者を追加 / 削除する 3. 幹事は、飲み会の参加者ごとに⽀払区分 (多め / 普通 / 少なめ) を設定する 4. 幹事は、飲み会の請求⾦額を設定する 5. 幹事は、飲み会の参加者ごとの⽀払⾦額を計算する
14. 例) 概念同⼠の関係性を考える 単独で成⽴する概念もあれば、関連性をもって初めて意味を持つ概念もありうる ⽀払区分 ⽀払割合 「必ず 1:1 対応しないと不具合があるな ... 🤔」 参加者 参加者 参加者 「個別で扱うか、⼈数でまとめて扱うか ... 🤔」
15. 例) 概念に対する条件づけを考える 「請求⾦額や⽀払い⾦額に関して、必ず等式が成⽴するな ... 🤔」 請求⾦額 aT = ( 普通の⽀払⾦額 + ( 多めの⽀払⾦額 + ( 少なめの⽀払⾦額 + 端数 C aM aL aS × × × 普通の⽀払⼈数 多めの⽀払⼈数 少なめの⽀払⼈数 nM ) nL ) nS ) 「普通の⽀払い割合を 1 で固定すると、計算が楽になったりしないか？🤔」 etc ...
16. 《デザイン》を知る_
17. 再掲) プロダクトが持つ 3 つの抽象構造 デザイン ≒ "プレゼンテーション" と "インタラクション" を定めることと 思われがちだが、これは誤解であり、モデルと表裏⼀体に洗練しあうこと が⼤事！ プロダクト プレゼンテーション 表層 や 体験 も大事だけど ... インタラクション ユーザー モデル モデルを度外視してはダメ！
18. 良いデザイン ≒ モデルとの剥離が少ないこと See also: ソシオメディア | メンタルモデル
19. 極端な悪いデザインの例 このような状況は、内部に持つ機能 (モデル) とデザインに剥離がある 󰢃 "ドアノブ" があるということは、 ひねって押す or 引くと開くのかな？🤔 ※ 実はスライド式ドア
20. 再掲) 割り勘アプリのモデルを考える モデルを考慮せずに デザインを考えてみると、どんなことが起こりうるか？🤔 0. (ここは現実世界のできごと) 幹事が、飲み会を開催する 1. 幹事は、⽀払区分 (多め / 普通 / 少なめ) ごとに⽀払割合を設定する 2. 幹事は、飲み会の参加者を追加 / 削除する 3. 幹事は、飲み会の参加者ごとに⽀払区分 (多め / 普通 / 少なめ) を設定する 4. 幹事は、飲み会の請求⾦額を設定する 5. 幹事は、飲み会の参加者ごとの⽀払⾦額を計算する
21. 例) たぶん、こんな割り勘アプリができる ... 🤔 参加者一覧 割合設定 金額設定 金額計算 "やりとり" をそのまま反映 ...
22. 例) こっちの⽅が使いやすそうじゃない？🎨 モデルが "デザイン" に対応 多め × N 普通 × N 少なめ × N 人 人 人 請求金額 N,NNN 円 割り勘する
23. 探索的かつ漸進的に、良いデザインを⾒つける枠組み モデルと同様な考え⽅で、デザインも洗練させることができる See also: 人間中心設計入門
24. 《エンジニアリング》を知る_
25. 再掲) プロダクトが持つ 3 つの抽象構造 抽象構造の集まりによってプロダクトは構成できるとは⾔ったものの、 どのようにして実現するか は未だ不明 ... → エンジニアリングの主たる関⼼ごとはこれ プロダクト ユーザー プレゼンテーション 表層 を担う抽象構造 インタラクション 体験 を担う抽象構造 モデル 機能の中核 を担う抽象構造
26. 抽象的だからこそ、エンジニアリングに努める プロダクトをつくるステップは、⼯学的に検証 & 洗練を積み重ねている AI による効率化 課題 or 要求 モデリング / デザイン タスク / 仕様管理 コーディング 検証の自動化 リリース プロダクト
27. "AI による効率化" の勘所 ゴールを適切に定義し、ゴールへの収束を "検証の⾃動化" でアシストする AI による効率化 課題 or 要求 モデリング / デザイン タスク / 仕様管理 コーディング 検証の自動化 リリース プロダクト
28. なぜ "検証の⾃動化" が重要か？ AI の性能を最⼤限引き出すためには、 ⽣成結果や判断結果に対するフィードバックループ が重要となる ⼈⼿でこれを⾏うことは⼤変なため、適切な検証ツールを通じた⾃動化が⼤事！ 【 典型的な検証ツール 】 • Linter → ⽂法エラー、潜在的なバグ、スタイル規約の違反を検出するもの • 単体テスト → 関数やメソッドなどに対して、⽋陥が無いか確認するもの • E2E テスト → ユーザー操作を⾃動化することで、実際の使⽤感を再現するもの See also: ハーネス / ループエンジニアリング
29. どんなに AI の能⼒が向上したとしても ... ユーザーに出す or 出さないの 最終意思決定は⼈間が担う (という覚悟を持つ) AI による効率化 課題 or 要求 モデリング / デザイン タスク / 仕様管理 コーディング 検証の自動化 リリース プロダクト
30. 本当にこれで⼤丈夫 ...？
31. Q. ⼀般的なプロダクトにおける 新規開発 の割合は どの程度か考えてみよう ... ⏳
32. ソフトウェア資産計上を元にした推計値 新規開発と⾒なせる割合は約 20% 程度で、残りの 約 80% は保守‧運⽤ に割かれている 新規開発 (約 20 %) 保守・運用 (約 80 %)
33. 保守‧運⽤とは何か？ 【 保守 】 • プロダクトに対して、改良、要素技術の更新、不具合の修正を施すこと • すなわち 不測の事態を抑⽌する ための取り組み全般 【 運⽤ 】 • プロダクトに対して、稼働状況の監視体制、異常発⽣時の復旧体制を整えること • すなわち 正常な状態を保つ ための取り組み全般 Monitoring & Recovery Refactoring & Debug
34. なぜ保守‧運⽤の割合が⾼くなるのか？ 【 保守の観点 】 • ソフトウェアは (物理法則と独⽴なので) 誤った構造を適⽤しやすい • そもそも進化が速いことも相まって、将来にわたって正しい構造を保証しづらい 【 運⽤の観点 】 • プロダクトが使えなくなる ≒ ユーザーの業務を⽌める ことに繋がる • ゆえに、不測の事態を抑⽌し、正常な状態を保つことへの要求が⾼い
35. まとめ • 《モデリング》と《デザイン》を通じて、 新規に ユーザーの 要求を満たす or 課題を解決する ⾜がかりが得られる • 《エンジニアリング》によって、実際にプロダクトを形づくる流れもわかる • しかしながら、現実には保守‧運⽤もとても⼤事 なプロダクト開発の⼀部 まずは新規開発をたくさん経験しましょう (でないと感覚も掴めない) その上で、どこかのタイミングで保守‧運⽤にも思いを馳せてもらえたら幸いです 👍
36. Any Questions ?