Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

話者紹介 株式会社リクルート ＡＰソリューションＧ フロントエンドアーキテクト シニアプロフェッショナル 吉井 健文

Slide 3

Slide 3 text

話者紹介 個人的な活動として、フロントエンド関連書籍を執筆。 新しい技術を、いかに事業に活かせるかを模索。 引用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

Slide 4

Slide 4 text

話者紹介 株式会社リクルート ＨＲ領域プロダクトディベロップメントユニット ビジネスアナリシス シニアプロフェッショナル 竹下由美

Slide 5

Slide 5 text

【本日のテーマ】 分散と集約のデザインで最短最速を実現

Slide 6

Slide 6 text

システム開発は分散と集約のデザイン

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

背景 Indeed PLUS

Slide 12

Slide 12 text

独立したサービス→プラットフォームへ

Slide 13

Slide 13 text

独立したサービス→プラットフォームへ 売上規模：超特大！ ・ビジネスモデル変換 ・関係者 ：X０００人 ・サービス数：１０個 ・グローバルプロジェクト（４か国） 大変革PRJ

Slide 14

Slide 14 text

背景 Airワーク 採用管理

Slide 15

Slide 15 text

最長のサブプロジェクト Airワーク 採用管理はプロジェクト全体で 最大ボリュームの開発量190画面 最も長期間を要するサブプロジェクトになることが予想された 期間

Slide 16

Slide 16 text

短期化できれば、全体が短期になる。 Airワーク 採用管理はプロジェクト全体で 最大ボリュームの開発量190画面 最も長期間を要するサブプロジェクトになることが予想された 期間 期間

Slide 17

Slide 17 text

常識的な努力の範疇を超えている。 190画面≒総工数690人月 理論工期：20か月 Recruit標準工期：12か月 目標工期：4か月 1977年IBM Systems Journal 「Walston＆Felixの統計値」

Slide 18

Slide 18 text

異次元の短期化。 出来るのか？ 出来ないのか？

Slide 19

Slide 19 text

いつも通りじゃ 異次元の短期化などできない。

Slide 20

Slide 20 text

普段大事にしてること。 開発スピード 高品質 高メンテナンス性 高拡張性 高機能 高UX 低コスト 低ランニングコスト ・ ・ ・ ・

Slide 21

Slide 21 text

全部の良いとこ取りではない。 「スピード」を第一優先にする。 開発スピード

Slide 22

Slide 22 text

大変革を前にして。 常識の向こう側を見る覚悟。 原理原則のハックが必要。

Slide 23

Slide 23 text

コンセプトはシンプル １２ヶ月 N名の エンジニア ４ヶ月 N✕３名の エンジニア

Slide 24

Slide 24 text

常識では禁じ手。 １２ヶ月 N名の エンジニア ４ヶ月 N✕３名の エンジニア なぜ、禁じ手なのか？

Slide 25

Slide 25 text

システム開発の期間は コミュニケーションコストと関係する

Slide 26

Slide 26 text

システム開発の期間と コミュニケーションコストの関係 1975年 フレデリック・P・ブルックス.Jr.著 引用 https://honto.jp/ebook/pd_29625140.html?cid=nscl_rd ブルックスの法則

Slide 27

Slide 27 text

ブルックスの法則とは 遅れているソフトウェアプロジェクトへの要員追加は プロジェクトを更に遅らせる

Slide 28

Slide 28 text

人数を追加すると遅くなる •人数が増えるとコミュニケーションパスが２乗で増加する。 •人数増加のタスク消化量 ＜ コミュニケーションコスト

Slide 29

Slide 29 text

コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2

Slide 30

Slide 30 text

コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2 4人×（4-1）＝12

Slide 31

Slide 31 text

コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2 4人×（4-1）＝12 8人×（8-1）＝56

Slide 32

Slide 32 text

コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2 4人×（4-1）＝12 8人×（8-1）＝56 人数4倍

Slide 33

Slide 33 text

コミュニケーションパスは 人数の二乗で増加する 2人×（2-1）＝2 4人×（4-1）＝12 8人×（8-1）＝56 コミュニケーションパス28倍 人数4倍

Slide 34

Slide 34 text

このコミュニケーションパス増加が発生 する条件 •タスク間に依存関係がある •協調が必要

Slide 35

Slide 35 text

このコミュニケーションパス増加が発生 する条件 •タスク間に依存関係がある •協調が必要

Slide 36

Slide 36 text

依存関係とは タスクA タスクB タスクC 依存関係がない 例：ホテルの部屋の清掃 A：１０１号室の清掃 B：１０２号室の清掃 C：１０３号室の清掃

Slide 37

Slide 37 text

依存関係とは タスクA タスクB タスクC 前後関係（Finish to Start） 例：400mリレー A:第１走者 B:第２走者 C:第３走者

Slide 38

Slide 38 text

依存関係とは 例：野菜炒め を作る A：玉ねぎを切る B：人参を切る C：炒める タスクA タスクB タスクC 合流の関係

Slide 39

Slide 39 text

依存関係とは 例：二人三脚 A：走者１ B：走者２ タスクA タスクB 相互依存の関係

Slide 40

Slide 40 text

このコミュニケーションパス増加が発生 する条件 •タスク間に依存関係がある •協調が必要

Slide 41

Slide 41 text

協調とは

Slide 42

Slide 42 text

依存関係のあるタスクを、 異なるヒトが担当すると協調が発生する タスクA タスクB タスクC 協調が不要 協調が不要 異なる担当者であり、 タスク間に依存関係がない。 タスク間に依存関係はあるが、 担当者が同じ。 タスクA タスクB タスクC

Slide 43

Slide 43 text

依存関係のあるタスクを、 異なるヒトが担当すると協調が発生する 協調が必要 タスクA タスクB タスクC 協調が必要 タスク間に依存関係はあるし、 担当者が異なる。 タスクA タスクB タスクC タスク間に依存関係はあるし、 担当者が異なる。

Slide 44

Slide 44 text

協調とは •依存関係のあるタスクを異なるヒトが担当する場合に発生する •コミュニケーションを通じて、円滑に進める

Slide 45

Slide 45 text

システム開発は依存関係協調だらけ 画面定義 データベ ース設計 API設計 画面設計 API実装 画面実装 画面定義 画面定義 共通API設計 画面設計 API設計 API実装 画面定義 １画面が複数APIと協調している 複数画面が１APIと協調してい る 複数画面や複数APIと協調している

Slide 46

Slide 46 text

システム開発とは コミュニケーションパスが複雑化する特性

Slide 47

Slide 47 text

異次元の短工期化が必要 １２ヶ月 N名の エンジニア ４ヶ月 N✕３名の エンジニア

Slide 48

Slide 48 text

異次元の短工期化が必要 →3倍の人数で開発 １２ヶ月 N名の エンジニア ４ヶ月 N✕３名の エンジニア

Slide 49

Slide 49 text

人数を増加すると遅くなる •人数が増えるとコミュニケーションパスが２乗で増加する。 •人数増加のタスク消化量 ＜ コミュニケーションコスト

Slide 50

Slide 50 text

システム開発の期間は コミュニケーションコストと関係する

Slide 51

Slide 51 text

短納期達成のため 3倍の人数増させる コミュニケーションパスの増化を防ぐ必要

Slide 52

Slide 52 text

短納期達成のため 3倍の人数増させる コミュニケーションパスの増化を防ぐ必要 8人×（8-1）＝ 56

Slide 53

Slide 53 text

短納期達成のため 3倍の人数増させる コミュニケーションパスの増化を防ぐ必要 8人×（8-1）＝ 56

Slide 54

Slide 54 text

短納期達成のため 3倍の人数増させる コミュニケーションパスの増化を防ぐ必要 8人×（8-1）＝ 56

Slide 55

Slide 55 text

この様なタスクの進め方になるはず

Slide 56

Slide 56 text

新！多重並走アーキテクチャ

Slide 57

Slide 57 text

新！多重並走アーキテクチャ FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断

Slide 58

Slide 58 text

アーキテクチャに潜む工期のボトルネック

Slide 59

Slide 59 text

アプリケーション実装の前提 •アプリケーション実装は「FE/BE」により成り立ちます。 2 ※ FE（フロントエンド）/ BE（バックエンド）

Slide 60

Slide 60 text

アプリケーション実装の前提 •アプリケーション実装は「FE/BE」により成り立ちます。 • アプリケーション実装において「どちらの責務であるか？」が 不明瞭な開発領域があります。それが「BFF」です。 2 ※ FE（フロントエンド）/ BE（バックエンド）

Slide 61

Slide 61 text

BFF とは何か？ • BFF とは、画面要求を達成するためのサーバー実装です。 2

Slide 62

Slide 62 text

BFF とは何か？ • BFF とは、画面要求を達成するためのサーバー実装です。 • UI を表現するための「データ取得」を行う。 2

Slide 63

Slide 63 text

BFF とは何か？ • BFF とは、画面要求を達成するためのサーバー実装です。 • UI を表現するための「データ取得」を行う。 • UI の操作を受け付け「データ更新」を行う。 2

Slide 64

Slide 64 text

BFF とは何か？ •「画面要求を達成するために、UI にどのようなデータが必要 ですか？」 2

Slide 65

Slide 65 text

BFF とは何か？ •「画面要求を達成するために、UI にどのようなデータが必要 ですか？」 •これを検討するのは「FE/BE」どちらの責務でしょう？また、 コードとして実装するのは、どちらの責務でしょう？ 2

Slide 66

Slide 66 text

BFF とは何か？ • BFFという名の通り「どちらの責務でもある」実装です。 （Backend For Frontend） 2

Slide 67

Slide 67 text

BFF とは何か？ • BFFという名の通り「どちらの責務でもある」実装です。 （Backend For Frontend） •円滑に実装を完遂するためには、双方の認識齟齬なく、確実で、 的確なやりとりが求められます。 2

Slide 68

Slide 68 text

BFF とは何か？ • BFFという名の通り「どちらの責務でもある」実装です。 （Backend For Frontend） •円滑に実装を完遂するためには、双方の認識齟齬なく、確実で、 的確なやりとりが求められます。 • この「BFF 実装の整理」こそ、ブルックスの法則に抗うための キーポイントでした。 2

Slide 69

Slide 69 text

一般的な BFF の実装方法 •一般的な BFF 実装例をみてみましょう。 2

Slide 70

Slide 70 text

一般的な BFF の実装方法 •一般的な BFF 実装例をみてみましょう。 •BFF 実装が FE エンジニアの責務の場合、UI にデータを表示 するまで、3 つの工程を経ます。 2

Slide 71

Slide 71 text

一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 BE 開発領域 WEB API サーバー 2

Slide 72

Slide 72 text

一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 BFF サーバー FE 開発領域 BE 開発領域 WEB API サーバー 2

Slide 73

Slide 73 text

一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2

Slide 74

Slide 74 text

一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 UI を経由し、アプリケーションは持続的に操作されます。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2

Slide 75

Slide 75 text

一般的な BFF の実装方法 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 「BFF サーバーをどう実装するか？」という問いは、状況によっては複雑です。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2

Slide 76

Slide 76 text

開発プロセスに潜むボトルネック BFF サーバーの実装詳細をイメージしてみましょう。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2

Slide 77

Slide 77 text

開発プロセスに潜むボトルネック • リクエストから、ユーザーID を特定 BFF サーバーの実装詳細をイメージしてみましょう。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2

Slide 78

Slide 78 text

開発プロセスに潜むボトルネック • リクエストから、ユーザーID を特定 • 特定した ID を使用して、次のデータを取得 BFF サーバーの実装詳細をイメージしてみましょう。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2

Slide 79

Slide 79 text

開発プロセスに潜むボトルネック • リクエストから、ユーザーID を特定 • 特定した ID を使用して、次のデータを取得 • 取得したデータを、さらに別のデータと結合する、、 BFF サーバーの実装詳細をイメージしてみましょう。 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 2

Slide 80

Slide 80 text

開発プロセスに潜むボトルネック • リクエストから、ユーザーID を特定 • 特定した ID を使用して、次のデータを取得 • 取得したデータを、さらに別のデータと結合する、、 FE/BE エンジニアは、このようなクエリを組み立てるために、 「密な協調」が求められます。 BFF サーバー UI（ブラウザ表示） FE 開発領域 協調 BE 開発領域 WEB API サーバー 2

Slide 81

Slide 81 text

開発プロセスに潜むボトルネック BFF サーバー UI（ブラウザ表示） FE 開発領域 そして BFF サーバー実装が完了するまで、UI 実装は着手できません。 BE 開発領域 WEB API サーバー 2

Slide 82

Slide 82 text

開発プロセスに潜むボトルネック BFF サーバー FE 開発領域 まとめると、3つの工程は 「直列でしか開発を進められないウォーターフォール」といえます。 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 UI（ブラウザ表示） BE 開発領域 WEB API サーバー 2

Slide 83

Slide 83 text

開発プロセスに潜むボトルネック BFF サーバー UI（ブラウザ表示） FE 開発領域 そして「どこが原因でバグが発生しているのか？」という調査は、 特定までに時間がかかります。 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 バグ？ バグ？ バグ？ バグ？ BE 開発領域 WEB API サーバー 2

Slide 84

Slide 84 text

BFF 実装に潜むボトルネック • BFF 実装は「要求とシステムを繋ぐ要」である。 2

Slide 85

Slide 85 text

BFF 実装に潜むボトルネック • BFF 実装は「要求とシステムを繋ぐ要」である。 • BFF 実装は「時に複雑」である。 2

Slide 86

Slide 86 text

BFF 実装に潜むボトルネック • BFF 実装は「要求とシステムを繋ぐ要」である。 • BFF 実装は「時に複雑」である。 • FE/BE 間の「密な協調」が双方に求められる。 2

Slide 87

Slide 87 text

協調点の移動 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 2

Slide 88

Slide 88 text

協調点の移動 BFF サーバー UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 FE/BE 間の密な「協調」がボトルネックと仮定。 協調 2

Slide 89

Slide 89 text

協調点の移動 UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 FE/BE 間で求められていた「協調」を、BE チームだけで完結するよう合意形成。 協調 2

Slide 90

Slide 90 text

協調点の移動 UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 FE/BE 間を跨ぐ「協調」は、単一で単純なものに。 単純 2

Slide 91

Slide 91 text

協調点の移動 UI（ブラウザ表示） FE 開発領域 BE 開発領域 WEB API サーバー 1. BE エンジニアは、Web API サーバーを開発 2. FE エンジニアは、BFF サーバーから Web API サーバーにリクエストを発行 3. FE エンジニアは、取得したデータを、UI に反映 実装制約により必要な、最小限の機能のみを BFF サーバーに残す。 認証 / SSR 2

Slide 92

Slide 92 text

協調を分断する責務境界

Slide 93

Slide 93 text

UI コンポーネントとは？ •UI コンポーネントとは「画面構成要素 」 3

Slide 94

Slide 94 text

UI コンポーネントとは？ •UI コンポーネントとは「画面構成要素 」 •画面要求を達成するための「単位」 3

Slide 95

Slide 95 text

UI コンポーネントとは？ •UI コンポーネントとは「画面構成要素 」 •画面要求を達成するための「単位」 画面 3

Slide 96

Slide 96 text

UI コンポーネントとは？ •UI コンポーネントとは「画面構成要素 」 •画面要求を達成するための「単位」 3

Slide 97

Slide 97 text

• 一般的に、BE/FE 並走のためには OpenAPI（規約）を定義 Web API サーバー 規約 UI コンポーネントにもとづく責務境界 3

Slide 98

Slide 98 text

• 一般的に、BE/FE 並走のためには OpenAPI（規約）を定義 • しかしこの規約だけでは、十分な責務境界をひけない Web API サーバー 規約 UI コンポーネントにもとづく責務境界 3

Slide 99

Slide 99 text

? • UI 表示に必要なデータ加工はどこで行うか？（要協調） Web API サーバー 規約 UI コンポーネントにもとづく責務境界 3

Slide 100

Slide 100 text

? • UI 表示に必要なデータ加工はどこで行うか？（要協調） • データ中心の API なのか？UI 中心の API なのか？（要協調） Web API サーバー 規約 ? UI コンポーネントにもとづく責務境界 3

Slide 101

Slide 101 text

UI コンポーネントにもとづく責務境界 •1 つの画面は、複数の UI コンポーネントに分断可能 3

Slide 102

Slide 102 text

UI コンポーネントにもとづく責務境界 •1 つの画面は、複数の UI コンポーネントに分断可能 3

Slide 103

Slide 103 text

UI コンポーネントにもとづく責務境界 •UI コンポーネント同士は、協調が必ずしも必要ではない 3

Slide 104

Slide 104 text

UI コンポーネントにもとづく責務境界 •UI コンポーネント同士は、協調が必ずしも必要ではない • UI コンポーネント毎に「責務」を分断できる 3

Slide 105

Slide 105 text

UI コンポーネントと Web API の関係 • テーブル表示のための UI コンポーネントの場合 3

Slide 106

Slide 106 text

UI コンポーネントと Web API の関係 • Web API から、単独でデータを取得。初期表示を行う。 Web API サーバー 3

Slide 107

Slide 107 text

UI コンポーネントと Web API の関係 • クリックすると、再度データを取得。表示を更新。 Web API サーバー Click ! 3

Slide 108

Slide 108 text

Web API サーバー 多重並走開発のための責務境界 • そこで、UI コンポーネントを軸に責務を分断 3

Slide 109

Slide 109 text

Web API サーバー 多重並走開発のための責務境界 • そこで、UI コンポーネントを軸に責務を分断 • Web API は「UI を成立させることに徹する」 3

Slide 110

Slide 110 text

多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする WEB API 3

Slide 111

Slide 111 text

多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする WEB API WEB API 3

Slide 112

Slide 112 text

多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする WEB API WEB API WEB API 3

Slide 113

Slide 113 text

多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする WEB API WEB API WEB API WEB API 3

Slide 114

Slide 114 text

多重並走開発のための責務境界 •「UI コンポーネント：専用 Web API」は「1：1」の関係とする •専用 Web API の OpenAPI を定義、BE/FE は並走開発 WEB API WEB API WEB API WEB API 3 規約 規約 規約 規約

Slide 115

Slide 115 text

多重並走開発のキーポイント

Slide 116

Slide 116 text

今回のアーキテクチャ特性のおさらい •（1）密な「協調」は BE チームだけで完結するよう変更 BFF サーバー UI（ブラウザ表示） FE 開発領域（6名） BE 開発領域（2名） WEB API サーバー 4

Slide 117

Slide 117 text

今回のアーキテクチャ特性のおさらい •（1）密な「協調」は BE チームだけで完結するよう変更 UI（ブラウザ表示） FE 開発領域（4名） BE 開発領域（4名） WEB API サーバー 4

Slide 118

Slide 118 text

今回のアーキテクチャ特性のおさらい FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断 4

Slide 119

Slide 119 text

今回のアーキテクチャ特性のおさらい FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） UI コンポーネント軸で分断することで、各レーンの責務が明確に •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断 4

Slide 120

Slide 120 text

今回のアーキテクチャ特性のおさらい FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） 規約に変更があった場合、FE/BE 間の協調は最小限に •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断 変更 4

Slide 121

Slide 121 text

今回のアーキテクチャ特性のおさらい FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） 単機能テスト（単体テスト）もレーン毎に実施でき、進捗管理なども容易に •（1）密な「協調」は BE チームだけで完結するよう変更 •（2）UI コンポーネントを軸に「責務」をレーン毎に分断 単機能 テスト 4

Slide 122

Slide 122 text

多重並走開発のキーポイント •（1）FE/BE 間の協調を、最小限に抑えること 4

Slide 123

Slide 123 text

多重並走開発のキーポイント •（1）FE/BE 間の協調を、最小限に抑えること •（2）「UI コンポーネント軸」に、責務を分断すること 4

Slide 124

Slide 124 text

多重並走開発のキーポイント •（1）FE/BE 間の協調を、最小限に抑えること •（2）「UI コンポーネント軸」に、責務を分断すること •（3）★ 要件定義の段階から、分断されていること 4

Slide 125

Slide 125 text

多重並走開発のキーポイント •今回、開発対象の画面数は40画面ほど 4

Slide 126

Slide 126 text

多重並走開発のキーポイント •今回、開発対象の画面数は40画面ほど •通常、要件定義の数は画面と比例し40程度となる 4

Slide 127

Slide 127 text

多重並走開発のキーポイント •今回、開発対象の画面数は40画面ほど •通常、要件定義の数は画面と比例し40程度となる この40画面を「190 UI コンポーネント」に分断 4

Slide 128

Slide 128 text

多重並走開発のキーポイント •要件定義の段階から介入 4

Slide 129

Slide 129 text

多重並走開発のキーポイント •要件定義の段階から介入 •アーキテクチャに則った「要件定義の細分化」を提案 4

Slide 130

Slide 130 text

多重並走開発のキーポイント •要件定義の段階から介入 •アーキテクチャに則った「要件定義の細分化」を提案 •40画面分の要件定義を 190 に細分化するように指揮 4

Slide 131

Slide 131 text

多重並走開発のキーポイント •要件定義の段階から介入 •アーキテクチャに則った「要件定義の細分化」を提案 •40画面分の要件定義を 190 に細分化するように指揮 「190 画面／190API」の正体は、実は「190 UI コンポーネント／190API」 4

Slide 132

Slide 132 text

「UI コンポーネントの境界がどこにあるのか？」 という判断が、このアーキテクチャの 勘所といえるでしょう。 4

Slide 133

Slide 133 text

要件定義の段階から境界を設けたことが 「短期間で開発を完遂したい。人数は問わない」 という要求に応える結果となりました。 4

Slide 134

Slide 134 text

多重並走アーキテクチャを作成

Slide 135

Slide 135 text

多重並走アーキテクチャを作成 それだけでは1/3の工期にならない

Slide 136

Slide 136 text

データベースだけは アーキテクチャで制御出来ない 画面 画面 画面 画面 画面 画面 画面 画面 画面 API API API API API API API API API データベース

Slide 137

Slide 137 text

データベース設計を通じて 協調が発生する 画面 画面 画面 画面 画面 画面 画面 画面 画面 API API API API API API API API API データベース

Slide 138

Slide 138 text

データベース設計を変更しなければ 協調は発生しない 画面 画面 画面 画面 画面 画面 画面 画面 画面 API API API API API API API API API データベース

Slide 139

Slide 139 text

逆転の発想 先にデータベースをロックする 画面 画面 画面 画面 画面 画面 画面 画面 画面 API API API API API API API API API データベース

Slide 140

Slide 140 text

この様なタスクの進め方にしました データベー ス 画面 画面 画面 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ API API API API API API API API API データベース設計 画面定義 画面設計(UIパーツ化) API設計 製造

Slide 141

Slide 141 text

データベー ス 画面 画面 画面 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ データベース設 計 画面定義 画面設計(UIパーツ 化) 画面 画面 主要画面 定義 主要画面な数画面のみ固め 早期データベースFIX

Slide 142

Slide 142 text

後続作成する画面は Fixしたデータベースを制約を受ける 画面 画面 画面 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ 画面パーツ データベース設 計 画面定義 画面設計(UIパーツ 化) 画面 画面 主要画面 定義 データベー ス 主要画面は全体の約15％ 最速で完了することだけを考えた MVPを開発で決めてしまう

Slide 143

Slide 143 text

最速のためのMVP これで出来るのか？

Slide 144

Slide 144 text

まだまだ足りない

Slide 145

Slide 145 text

なぜならば 開発は 想定外のコミュニケーションが発生するから まだまだ足りない

Slide 146

Slide 146 text

想定外のコミュニケーション発生源 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム リリース データベース 設計FIX

Slide 147

Slide 147 text

想定外のコミュニケーション発生源 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム 後で、ビジネ ス要件の漏れ が発生する。 リリース データベース 設計FIX

Slide 148

Slide 148 text

想定外のコミュニケーション発生源 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム 後で、ビジネ ス要件の漏れ が発生する。 設計まで立ち返る 様な問題が発覚。 リリース データベース 設計FIX

Slide 149

Slide 149 text

想定外のコミュニケーション発生源 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム 後で、ビジネ ス要件の漏れ が発生する。 リリース データベース 設計FIX 設計まで立ち返る 様な問題が発覚。

Slide 150

Slide 150 text

コミュニケーションパスの発生 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス コーディング 中に仕様の矛 盾に気づく 並列開発チーム 後で、ビジネ ス要件の漏れ が発生する。 リリース データベース 設計FIX 設計まで立ち返る 様な問題が発覚。

Slide 151

Slide 151 text

途中発生するコミュニケーションパスを 制限しなければ、開発者は集中できない

Slide 152

Slide 152 text

コミュニケーションパスの増加場所を コントロールして、開発者を支援する ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース コーディング 中に仕様の矛 盾に気づく 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。

Slide 153

Slide 153 text

コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 コーディング 中に仕様の矛 盾に気づく 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。

Slide 154

Slide 154 text

コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み コーディング 中に仕様の矛 盾に気づく 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。

Slide 155

Slide 155 text

コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み 取り込み コーディング 中に仕様の矛 盾に気づく 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。

Slide 156

Slide 156 text

コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み 取り込み コーディング 中に仕様の矛 盾に気づく 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。

Slide 157

Slide 157 text

コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 並列開発チーム リリース 取り込み 取り込み 取り込み 開発するのに都合 の良い仕様で対応 取り込み 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。

Slide 158

Slide 158 text

コミュニケーションパスを増やす 想定外の問題への対応 ビジネス 検討 要件定義 設計実装 テスト リリース前 エンハンス リリース後 エンハンス 要件の問題発 生 開発するのに都合 の良い仕様で対応 並列開発チーム リリース 取り込み 取り込み 取り込み この期間に エンジニアが巻き込 まれてしまう コミュニケーション を発生させない 並列開発を破綻させないため に戦略的な先送りを 出来る期間を事前に設定。 後で、ビジネ ス要件の漏れ が発生する。 データベース 設計FIX 設計まで立ち返る 様な問題が発覚。

Slide 159

Slide 159 text

コミュニケーションコスト削減により 工期1/3を達成

Slide 160

Slide 160 text

コミュニケーションコスト削減により 工期1/3を達成 従来よりも8か月早くリリース 8か月

Slide 161

Slide 161 text

異次元の短期化。 出来るのか？ 出来ないのか？

Slide 162

Slide 162 text

工期1/3でリリースできたけど

Slide 163

Slide 163 text

工期1/3でリリースできたけど 保守エンハンスはどうなるの？

Slide 164

Slide 164 text

協調の最小化による恩恵

Slide 165

Slide 165 text

協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 5

Slide 166

Slide 166 text

協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 •しかし、最後までそれを一貫することは可能なのでしょうか？ 5

Slide 167

Slide 167 text

協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 •しかし、最後までそれを一貫することは可能なのでしょうか？ •それは不可能なことです。 5

Slide 168

Slide 168 text

協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 •しかし、最後までそれを一貫することは可能なのでしょうか？ •それは不可能なことです。 •開発対象は、一つのアプリケーションです。 5

Slide 169

Slide 169 text

協調を断ち切りきることは可能か？ •ここまで「協調」を断ち切ることにフォーカスしてきました。 •しかし、最後までそれを一貫することは可能なのでしょうか？ •それは不可能なことです。 •開発対象は、一つのアプリケーションです。 •最終的には結合する必要があります。 5

Slide 170

Slide 170 text

協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 5

Slide 171

Slide 171 text

協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 •各レーンを結合する際には「協調」が必要です。 5

Slide 172

Slide 172 text

協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 •各レーンを結合する際には「協調」が必要です。 この時点の結合テストにおいてバグが発生することもあります。 バグ？ 5

Slide 173

Slide 173 text

協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 •各レーンを結合する際には「協調」が必要です。 しかしながら結合点が明確であるため、バグの特定は容易です。 バグ！ 5

Slide 174

Slide 174 text

協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •我々のアーキテクチャは「協調の最小化」を叶えます。 •各レーンを結合する際には「協調」が必要です。 これは、レーン単位で 単機能テストが完了している恩恵です。 バグ！ 単機能 テスト 5

Slide 175

Slide 175 text

協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •障害対応やエンハンスの中でも、影響範囲が絞られる。 5

Slide 176

Slide 176 text

協調の最小化による恩恵 FE 開発領域（1名 × 4） BE 開発領域（1名 × 4） •障害対応やエンハンスの中でも、影響範囲が絞られる。 •品質スピードともに既存と比較し向上。 5

Slide 177

Slide 177 text

まとめ 【課題】 R標準1/3の異次元の短期化が必要 超並列開発しか実現できないと考えた。 【ナレッジポイント】 • コミュニケーションコストを低下させるための 超分散型新アーキテクチャ考案。 • データベース設計を開発実行タスクの先頭に置く。 • エンジニアが巻き込まれるコミュニケーション増加を止める。 【結果】 異次元の短期化（工期1/3）を実現した。