最短最速に魂を売る！ 新しいアーキテクチャとプロセスの提案！

2024/07/23に、Developers Summit 2024 Summerで発表した、吉井と竹下の資料です。

Transcript

1. 最短最速に魂を売る！ 新しいアーキテクチャとプロセスの提案！
2. 話者紹介 株式会社リクルート ＡＰソリューションＧ フロントエンドアーキテクト シニアプロフェッショナル 吉井 健文
3. 話者紹介 個人的な活動として、フロントエンド関連書籍を執筆。 新しい技術を、いかに事業に活かせるかを模索。 引用https://gihyo.jp/book/2024/978-4-297-14061-8 https://www.shoeisha.co.jp/book/detail/9784798178189 https://book.mynavi.jp/ec/products/detail/id=104703
4. 話者紹介 株式会社リクルート ＨＲ領域プロダクトディベロップメントユニット ビジネスアナリシス シニアプロフェッショナル 竹下由美
5. 【本日のテーマ】 分散と集約のデザインで最短最速を実現
6. システム開発は分散と集約のデザイン
7. 集約のデザイン例
8. 分散のデザイン例
9. 新デザイン 多重並走アーキテクチャ
10. 新アーキテクチャデザインは なぜ作ったのか？何のために？
11. 背景 Indeed PLUS
12. 独立したサービス→プラットフォームへ
13. 独立したサービス→プラットフォームへ 売上規模：超特大！ ・ビジネスモデル変換 ・関係者 ：X０００人 ・サービス数：１０個 ・グローバルプロジェクト（４か国） 大変革PRJ
14. 背景 Airワーク 採用管理
15. 最長のサブプロジェクト Airワーク 採用管理はプロジェクト全体で 最大ボリュームの開発量190画面 最も長期間を要するサブプロジェクトになることが予想された 期間
16. 短期化できれば、全体が短期になる。 Airワーク 採用管理はプロジェクト全体で 最大ボリュームの開発量190画面 最も長期間を要するサブプロジェクトになることが予想された 期間 期間
17. 常識的な努力の範疇を超えている。 190画面≒総工数690人月 理論工期：20か月 Recruit標準工期：12か月 目標工期：4か月 1977年IBM Systems Journal 「Walston＆Felixの統計値」
18. 異次元の短期化。 出来るのか？ 出来ないのか？
19. いつも通りじゃ 異次元の短期化などできない。
20. 普段大事にしてること。 開発スピード 高品質 高メンテナンス性 高拡張性 高機能 高UX 低コスト 低ランニングコスト ・ ・ ・ ・
21. 全部の良いとこ取りではない。 「スピード」を第一優先にする。 開発スピード
22. 大変革を前にして。 常識の向こう側を見る覚悟。 原理原則のハックが必要。
23. コンセプトはシンプル １２ヶ月 N名の エンジニア ４ヶ月 N✕３名の エンジニア
24. 常識では禁じ手。 １２ヶ月 N名の エンジニア ４ヶ月 N✕３名の エンジニア なぜ、禁じ手なのか？
25. システム開発の期間は コミュニケーションコストと関係する
26. システム開発の期間と コミュニケーションコストの関係 1975年 フレデリック・P・ブルックス.Jr.著 引用 https://honto.jp/ebook/pd_29625140.html?cid=nscl_rd ブルックスの法則
27. ブルックスの法則とは 遅れているソフトウェアプロジェクトへの要員追加は プロジェクトを更に遅らせる
28. 人数を追加すると遅くなる •人数が増えるとコミュニケーションパスが２乗で増加する。 •人数増加のタスク消化量 ＜ コミュニケーションコスト
29. コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2
30. コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2 4人×（4-1）＝12
31. コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2 4人×（4-1）＝12 8人×（8-1）＝56
32. コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2 4人×（4-1）＝12 8人×（8-1）＝56 人数4倍
33. コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2 4人×（4-1）＝12 8人×（8-1）＝56 コミュニケーションパス28倍 人数4倍
34. このコミュニケーションパス増加が発生 する条件 •タスク間に依存関係がある •協調が必要
35. このコミュニケーションパス増加が発生 する条件 •タスク間に依存関係がある •協調が必要
36. 依存関係とは タスクA タスクB タスクC 依存関係がない 例：ホテルの部屋の清掃 A：１０１号室の清掃 B：１０２号室の清掃 C：１０３号室の清掃
37. 依存関係とは タスクA タスクB タスクC 前後関係（Finish to Start） 例：400mリレー A:第１走者 B:第２走者 C:第３走者
38. 依存関係とは 例：野菜炒め を作る A：玉ねぎを切る B：人参を切る C：炒める タスクA タスクB タスクC 合流の関係
39. 依存関係とは 例：二人三脚 A：走者１ B：走者２ タスクA タスクB 相互依存の関係
40. このコミュニケーションパス増加が発生 する条件 •タスク間に依存関係がある •協調が必要
41. 協調とは
42. 依存関係のあるタスクを、 異なるヒトが担当すると協調が発生する タスクA タスクB タスクC 協調が不要 協調が不要 異なる担当者であり、 タスク間に依存関係がない。 タスク間に依存関係はあるが、 担当者が同じ。 タスクA タスクB タスクC
43. 依存関係のあるタスクを、 異なるヒトが担当すると協調が発生する 協調が必要 タスクA タスクB タスクC 協調が必要 タスク間に依存関係はあるし、 担当者が異なる。 タスクA タスクB タスクC タスク間に依存関係はあるし、 担当者が異なる。
44. 協調とは •依存関係のあるタスクを異なるヒトが担当する場合に発生する •コミュニケーションを通じて、円滑に進める
45. システム開発は依存関係協調だらけ 画面定義 データベ ース設計 API設計 画面設計 API実装 画面実装 画面定義 画面定義 共通API設計 画面設計 API設計 API実装 画面定義 １画面が複数APIと協調している 複数画面が１APIと協調してい る 複数画面や複数APIと協調している
46. システム開発とは コミュニケーションパスが複雑化する特性
47. 異次元の短工期化が必要 １２ヶ月 N名の エンジニア ４ヶ月 N✕３名の エンジニア
48. 異次元の短工期化が必要 →3倍の人数で開発 １２ヶ月 N名の エンジニア ４ヶ月 N✕３名の エンジニア
49. 人数を増加すると遅くなる •人数が増えるとコミュニケーションパスが２乗で増加する。 •人数増加のタスク消化量 ＜ コミュニケーションコスト
50. システム開発の期間は コミュニケーションコストと関係する
51. 短納期達成のため 3倍の人数増させる コミュニケーションパスの増化を防ぐ必要
52. 短納期達成のため 3倍の人数増させる コミュニケーションパスの増化を防ぐ必要 8人×（8-1）＝ 56
53. 短納期達成のため 3倍の人数増させる コミュニケーションパスの増化を防ぐ必要 8人×（8-1）＝ 56
54. 短納期達成のため 3倍の人数増させる コミュニケーションパスの増化を防ぐ必要 8人×（8-1）＝ 56
55. この様なタスクの進め方になるはず
56. 新！多重並走アーキテクチャ
57. 新！多重並走アーキテクチャ FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断
58. アーキテクチャに潜む工期のボトルネック
59. アプリケーション実装の前提 •アプリケーション実装は「FE/BE」により成り立ちます。 2 ※ FE（フロントエンド）/ BE（バックエンド）
60. アプリケーション実装の前提 •アプリケーション実装は「FE/BE」により成り立ちます。 • アプリケーション実装において「どちらの責務であるか？」が 不明瞭な開発領域があります。それが「BFF」です。 2 ※ FE（フロントエンド）/ BE（バックエンド）
61. BFF とは何か？ • BFF とは、画面要求を達成するためのサーバー実装です。 2
62. BFF とは何か？ • BFF とは、画面要求を達成するためのサーバー実装です。 • UI を表現するための「データ取得」を行う。 2
63. BFF とは何か？ • BFF とは、画面要求を達成するためのサーバー実装です。 • UI を表現するための「データ取得」を行う。 • UI の操作を受け付け「データ更新」を行う。 2
64. BFF とは何か？ •「画面要求を達成するために、UI にどのようなデータが必要 ですか？」 2
65. BFF とは何か？ •「画面要求を達成するために、UI にどのようなデータが必要 ですか？」 •これを検討するのは「FE/BE」どちらの責務でしょう？また、 コードとして実装するのは、どちらの責務でしょう？ 2
66. BFF とは何か？ • BFFという名の通り「どちらの責務でもある」実装です。 （Backend For Frontend） 2
67. BFF とは何か？ • BFFという名の通り「どちらの責務でもある」実装です。 （Backend For Frontend） •円滑に実装を完遂するためには、双方の認識齟齬なく、確実で、 的確なやりとりが求められます。 2
68. BFF とは何か？ • BFFという名の通り「どちらの責務でもある」実装です。 （Backend For Frontend） •円滑に実装を完遂するためには、双方の認識齟齬なく、確実で、 的確なやりとりが求められます。 • この「BFF 実装の整理」こそ、ブルックスの法則に抗うための キーポイントでした。 2
69. 一般的な BFF の実装方法 •一般的な BFF 実装例をみてみましょう。 2
70. 一般的な BFF の実装方法 •一般的な BFF 実装例をみてみましょう。 •BFF 実装が FE エンジニアの責務の場合、UI にデータを表示 するまで、3 つの工程を経ます。 2
71. 一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 BE 開発領域 WEB API サーバー 2
72. 一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 BFF サーバー FE 開発領域 BE 開発領域 WEB API サーバー 2
73. 一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2
74. 一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 UI を経由し、アプリケーションは持続的に操作されます。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2
75. 一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 「BFF サーバーをどう実装するか？」という問いは、状況によっては複雑です。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2
76. 開発プロセスに潜むボトルネック BFF サーバーの実装詳細をイメージしてみましょう。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2
77. 開発プロセスに潜むボトルネック • リクエストから、ユーザーID を特定 BFF サーバーの実装詳細をイメージしてみましょう。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2
78. 開発プロセスに潜むボトルネック • リクエストから、ユーザーID を特定 • 特定した ID を使用して、次のデータを取得 BFF サーバーの実装詳細をイメージしてみましょう。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2
79. 開発プロセスに潜むボトルネック • リクエストから、ユーザーID を特定 • 特定した ID を使用して、次のデータを取得 • 取得したデータを、さらに別のデータと結合する、、 BFF サーバーの実装詳細をイメージしてみましょう。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2
80. 開発プロセスに潜むボトルネック • リクエストから、ユーザーID を特定 • 特定した ID を使用して、次のデータを取得 • 取得したデータを、さらに別のデータと結合する、、 FE/BE エンジニアは、このようなクエリを組み立てるために、 「密な協調」が求められます。 BFF サーバー UI（ブラウザ表示） FE 開発領域 協調 BE 開発領域 WEB API サーバー 2
81. 開発プロセスに潜むボトルネック BFF サーバー UI（ブラウザ表示） FE 開発領域 そして BFF サーバー実装が完了するまで、UI 実装は着手できません。 BE 開発領域 WEB API サーバー 2
82. 開発プロセスに潜むボトルネック BFF サーバー FE 開発領域 まとめると、3つの工程は 「直列でしか開発を進められないウォーターフォール」といえます。 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 UI（ブラウザ表示） BE 開発領域 WEB API サーバー 2
83. 開発プロセスに潜むボトルネック BFF サーバー UI（ブラウザ表示） FE 開発領域 そして「どこが原因でバグが発生しているのか？」という調査は、 特定までに時間がかかります。 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 バグ？ バグ？ バグ？ バグ？ BE 開発領域 WEB API サーバー 2
84. BFF 実装に潜むボトルネック • BFF 実装は「要求とシステムを繋ぐ要」である。 2
85. BFF 実装に潜むボトルネック • BFF 実装は「要求とシステムを繋ぐ要」である。 • BFF 実装は「時に複雑」である。 2
86. BFF 実装に潜むボトルネック • BFF 実装は「要求とシステムを繋ぐ要」である。 • BFF 実装は「時に複雑」である。 • FE/BE 間の「密な協調」が双方に求められる。 2
87. 協調点の移動 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 2
88. 協調点の移動 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 FE/BE 間の密な「協調」がボトルネックと仮定。 協調 2
89. 協調点の移動 UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 FE/BE 間で求められていた「協調」を、BE チームだけで完結するよう合意形成。 協調 2
90. 協調点の移動 UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 FE/BE 間を跨ぐ「協調」は、単一で単純なものに。 単純 2
91. 協調点の移動 UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 実装制約により必要な、最小限の機能のみを BFF サーバーに残す。 認証 / SSR 2
92. 協調を分断する責務境界
93. UI コンポーネントとは？ •UI コンポーネントとは「画面構成要素 」 3
94. UI コンポーネントとは？ •UI コンポーネントとは「画面構成要素 」 •画面要求を達成するための「単位」 3
95. UI コンポーネントとは？ •UI コンポーネントとは「画面構成要素 」 •画面要求を達成するための「単位」 画面 3
96. UI コンポーネントとは？ •UI コンポーネントとは「画面構成要素 」 •画面要求を達成するための「単位」 3
97. • 一般的に、BE/FE 並走のためには OpenAPI（規約）を定義 Web API サーバー 規約 UI コンポーネントにもとづく責務境界 3
98. • 一般的に、BE/FE 並走のためには OpenAPI（規約）を定義 • しかしこの規約だけでは、十分な責務境界をひけない Web API サーバー 規約 UI コンポーネントにもとづく責務境界 3
99. ? • UI 表示に必要なデータ加工はどこで行うか？（要協調） Web API サーバー 規約 UI コンポーネントにもとづく責務境界 3
100. ? • UI 表示に必要なデータ加工はどこで行うか？（要協調） • データ中心の API なのか？UI 中心の API なのか？（要協調） Web API サーバー 規約 ? UI コンポーネントにもとづく責務境界 3
101. UI コンポーネントにもとづく責務境界 •1 つの画面は、複数の UI コンポーネントに分断可能 3
102. UI コンポーネントにもとづく責務境界 •1 つの画面は、複数の UI コンポーネントに分断可能 3
103. UI コンポーネントにもとづく責務境界 •UI コンポーネント同士は、協調が必ずしも必要ではない 3
104. UI コンポーネントにもとづく責務境界 •UI コンポーネント同士は、協調が必ずしも必要ではない • UI コンポーネント毎に「責務」を分断できる 3
105. UI コンポーネントと Web API の関係 • テーブル表示のための UI コンポーネントの場合 3
106. UI コンポーネントと Web API の関係 • Web API から、単独でデータを取得。初期表示を行う。 Web API サーバー 3
107. UI コンポーネントと Web API の関係 • クリックすると、再度データを取得。表示を更新。 Web API サーバー Click ! 3
108. Web API サーバー 多重並走開発のための責務境界 • そこで、UI コンポーネントを軸に責務を分断 3
109. Web API サーバー 多重並走開発のための責務境界 • そこで、UI コンポーネントを軸に責務を分断 • Web API は「UI を成立させることに徹する」 3
110. 多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする WEB API 3
111. 多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする WEB API WEB API 3
112. 多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする WEB API WEB API WEB API 3
113. 多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする WEB API WEB API WEB API WEB API 3
114. 多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする •専用 Web API の OpenAPI を定義、BE/FE は並走開発 WEB API WEB API WEB API WEB API 3 規約 規約 規約 規約
115. 多重並走開発のキーポイント
116. 今回のアーキテクチャ特性のおさらい •（1）密な「協調」は BE チームだけで完結するよう変更 BFF サーバー UI（ブラウザ表示） FE 開発領域（6名） BE 開発領域（2名） WEB API サーバー 4
117. 今回のアーキテクチャ特性のおさらい •（1）密な「協調」は BE チームだけで完結するよう変更 UI（ブラウザ表示） FE 開発領域（4名） BE 開発領域（4名） WEB API サーバー 4
118. 今回のアーキテクチャ特性のおさらい FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断 4
119. 今回のアーキテクチャ特性のおさらい FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） UI コンポーネント軸で分断することで、各レーンの責務が明確に •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断 4
120. 今回のアーキテクチャ特性のおさらい FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） 規約に変更があった場合、FE/BE 間の協調は最小限に •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断 変更 4
121. 今回のアーキテクチャ特性のおさらい FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） 単機能テスト（単体テスト）もレーン毎に実施でき、進捗管理なども容易に •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断 単機能 テスト 4
122. 多重並走開発のキーポイント •（1）FE/BE 間の協調を、最小限に抑えること 4
123. 多重並走開発のキーポイント •（1）FE/BE 間の協調を、最小限に抑えること •（2）「UI コンポーネント軸」に、責務を分断すること 4
124. 多重並走開発のキーポイント •（1）FE/BE 間の協調を、最小限に抑えること •（2）「UI コンポーネント軸」に、責務を分断すること •（3）★ 要件定義の段階から、分断されていること 4
125. 多重並走開発のキーポイント •今回、開発対象の画面数は40画面ほど 4
126. 多重並走開発のキーポイント •今回、開発対象の画面数は40画面ほど •通常、要件定義の数は画面と比例し40程度となる 4
127. 多重並走開発のキーポイント •今回、開発対象の画面数は40画面ほど •通常、要件定義の数は画面と比例し40程度となる この40画面を「190 UI コンポーネント」に分断 4
128. 多重並走開発のキーポイント •要件定義の段階から介入 4
129. 多重並走開発のキーポイント •要件定義の段階から介入 •アーキテクチャに則った「要件定義の細分化」を提案 4
130. 多重並走開発のキーポイント •要件定義の段階から介入 •アーキテクチャに則った「要件定義の細分化」を提案 •40画面分の要件定義を 190 に細分化するように指揮 4
131. 多重並走開発のキーポイント •要件定義の段階から介入 •アーキテクチャに則った「要件定義の細分化」を提案 •40画面分の要件定義を 190 に細分化するように指揮 「190 画面／190API」の正体は、実は「190 UI コンポーネント／190API」 4
132. 「UI コンポーネントの境界がどこにあるのか？」 という判断が、このアーキテクチャの 勘所といえるでしょう。 4
133. 要件定義の段階から境界を設けたことが 「短期間で開発を完遂したい。人数は問わない」 という要求に応える結果となりました。 4
134. 多重並走アーキテクチャを作成
135. 多重並走アーキテクチャを作成 それだけでは1/3の工期にならない
136. データベースだけは アーキテクチャで制御出来ない 画面 画面 画面 画面 画面 画面 画面 画面 画面 API API API API API API API API API データベース
137. データベース設計を通じて 協調が発生する 画面 画面 画面 画面 画面 画面 画面 画面 画面 API API API API API API API API API データベース
138. データベース設計を変更しなければ 協調は発生しない 画面 画面 画面 画面 画面 画面 画面 画面 画面 API API API API API API API API API データベース
139. 逆転の発想 先にデータベースをロックする 画面 画面 画面 画面 画面 画面 画面 画面 画面 API API API API API API API API API データベース
140. この様なタスクの進め方にしました データベー ス 画面 画面 画面 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ API API API API API API API API API データベース設計 画面定義 画面設計(UIパーツ化) API設計 製造
141. データベー ス 画面 画面 画面 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ データベース設 計 画面定義 画面設計(UIパーツ 化) 画面 画面 主要画面 定義 主要画面な数画面のみ固め 早期データベースFIX
142. 後続作成する画面は Fixしたデータベースを制約を受ける 画面 画面 画面 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ データベース設 計 画面定義 画面設計(UIパーツ 化) 画面 画面 主要画面 定義 データベー ス 主要画面は全体の約15％ 最速で完了することだけを考えた MVPを開発で決めてしまう
143. 最速のためのMVP これで出来るのか？
144. まだまだ足りない
145. なぜならば 開発は 想定外のコミュニケーションが発生するから まだまだ足りない
146. 想定外のコミュニケーション発生源 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム リリース データベース 設計FIX
147. 想定外のコミュニケーション発生源 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム 後で、ビジネ ス要件の漏れ が発生する。 リリース データベース 設計FIX
148. 想定外のコミュニケーション発生源 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム 後で、ビジネ ス要件の漏れ が発生する。 設計まで立ち返る 様な問題が発覚。 リリース データベース 設計FIX
149. 想定外のコミュニケーション発生源 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム 後で、ビジネ ス要件の漏れ が発生する。 リリース データベース 設計FIX 設計まで立ち返る 様な問題が発覚。
150. コミュニケーションパスの発生 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム 後で、ビジネ ス要件の漏れ が発生する。 リリース データベース 設計FIX 設計まで立ち返る 様な問題が発覚。
151. 途中発生するコミュニケーションパスを 制限しなければ、開発者は集中できない
152. コミュニケーションパスの増加場所を コントロールして、開発者を支援する ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース コーディング 中に仕様の矛 盾に気づく 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。
153. コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 コーディング 中に仕様の矛 盾に気づく 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。
154. コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み コーディング 中に仕様の矛 盾に気づく 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。
155. コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み 取り込み コーディング 中に仕様の矛 盾に気づく 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。
156. コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み 取り込み コーディング 中に仕様の矛 盾に気づく 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。
157. コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み 取り込み 開発するのに都合 の良い仕様で対応 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。
158. コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 要件の問題発 生 開発するのに都合 の良い仕様で対応 並列開発チーム リリース 取り込み 取り込み 取り込み この期間に エンジニアが巻き込 まれてしまう コミュニケーション を発生させない 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。
159. コミュニケーションコスト削減により 工期1/3を達成
160. コミュニケーションコスト削減により 工期1/3を達成 従来よりも8か月早くリリース 8か月
161. 異次元の短期化。 出来るのか？ 出来ないのか？
162. 工期1/3でリリースできたけど
163. 工期1/3でリリースできたけど 保守エンハンスはどうなるの？
164. 協調の最小化による恩恵
165. 協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 5
166. 協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 •しかし、最後までそれを一貫することは可能なのでしょうか？ 5
167. 協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 •しかし、最後までそれを一貫することは可能なのでしょうか？ •それは不可能なことです。 5
168. 協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 •しかし、最後までそれを一貫することは可能なのでしょうか？ •それは不可能なことです。 •開発対象は、一つのアプリケーションです。 5
169. 協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 •しかし、最後までそれを一貫することは可能なのでしょうか？ •それは不可能なことです。 •開発対象は、一つのアプリケーションです。 •最終的には結合する必要があります。 5
170. 協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 5
171. 協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 •各レーンを結合する際には「協調」が必要です。 5
172. 協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 •各レーンを結合する際には「協調」が必要です。 この時点の結合テストにおいてバグが発生することもあります。 バグ？ 5
173. 協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 •各レーンを結合する際には「協調」が必要です。 しかしながら結合点が明確であるため、バグの特定は容易です。 バグ！ 5
174. 協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 •各レーンを結合する際には「協調」が必要です。 これは、レーン単位で 単機能テストが完了している恩恵です。 バグ！ 単機能 テスト 5
175. 協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •障害対応やエンハンスの中でも、影響範囲が絞られる。 5
176. 協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •障害対応やエンハンスの中でも、影響範囲が絞られる。 •品質スピードともに既存と比較し向上。 5
177. まとめ 【課題】 R標準1/3の異次元の短期化が必要 超並列開発しか実現できないと考えた。 【ナレッジポイント】 • コミュニケーションコストを低下させるための 超分散型新アーキテクチャ考案。 • データベース設計を開発実行タスクの先頭に置く。 • エンジニアが巻き込まれるコミュニケーション増加を止める。 【結果】 異次元の短期化（工期1/3）を実現した。