Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
新規事業立ち上げ時のエンジニアリング
Search
KAKEHASHI
PRO
October 28, 2021
Business
1
1.5k
新規事業立ち上げ時のエンジニアリング
KAKEHASHI
PRO
October 28, 2021
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
生成AIが拓く医療DXの進化と壁
kakehashi
PRO
0
45
品質と速度を両立する、私たちのフロントエンドテストの工夫と取り組み
kakehashi
PRO
2
56
爆速でプロダクトをリリースしようと思ったらマイクロフロントエンドを選んでいた
kakehashi
PRO
4
1.8k
生成AI時代に必要な価値ある意思決定を育てる「開発プロセス定義」を用いた中期戦略
kakehashi
PRO
1
440
プロダクトの成長に合わせたアーキテクチャの段階的進化と成長痛、そして、ユニットエコノミクスの最適化
kakehashi
PRO
1
190
ユーザー課題を愛し抜く――AI時代のPdM価値
kakehashi
PRO
1
300
「AIと一緒にやる」が当たり前になるまでの奮闘記
kakehashi
PRO
3
350
みんなのSRE 〜チーム全員でのSRE活動にするための4つの取り組み〜
kakehashi
PRO
2
260
医療系のプロダクト開発における生産性向上と高信頼性を両立させる生成AI活用
kakehashi
PRO
1
210
Other Decks in Business
See All in Business
ログラス会社紹介資料 新卒採用 ビジネス職[経営幹部候補]/ Loglass Company Deck
loglass2019
1
10k
株式会社J Institute 採用説明資料
jsaiyou123
0
110
株式会社Domuz会社紹介資料(採用)
kimpachi_d
0
42k
ソニックガーデン経営組織論(2025/10版)
kuranuki
0
690
ユーザー数10万人規模のアプリで挑んだトップ画面のUI刷新
tochi86
0
370
We are Wunderbar, Culture Deck Full
wunderbar
0
1.4k
THxApp project
shotaro0913
0
420
コーポレートストーリー(新規投資家様向け会社説明資料)
gatechnologies
1
14k
Laiblitz/corporateprofile
laiblitz
0
24k
opt recruit
digitalholdings
0
52k
サービス紹介資料_Microsoft 365 / Power Platform活用 伴走支援サービス
2fcgroup
0
120
データ整備の「やり方」はどうなっていくか
shinu
PRO
1
210
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Why Our Code Smells
bkeepers
PRO
339
57k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.6k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
20k
How to train your dragon (web standard)
notwaldorf
96
6.3k
Done Done
chrislema
185
16k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Transcript
新規事業立ち上げ時のエンジニアリング @AI在庫管理の設計勘所 2021/10/05 木村 彰宏
自己紹介 名前: 木村 彰宏 (Twitter @kimutyam) 所属: 株式会社カケハシ (2021年5月~) 役割:
AI在庫管理の次の柱となる大型新規事業の立ち上げ 職種: エンジニア 関心分野: ドメイン駆動設計・データエンジニアリング・スクラム
State.0: 入社後 - PMが先行して企画を進めている状態 - 1人目のエンジニアとして大型新規事業の立ち上げのチームにアサインさ れる Input - 5つの要求ドキュメント
- 2つの画面イメージ - 事業計画 さて・・どうしたものか。 今回は、立ち上げ時に段階的に行ってきたことを紹介します。
State.1: ドメインを理解できない - 要求を見ても何を言っているか分からない - 医療関連の専門性の欠落 Action - アクターと外部システムの関係性をマッピング -
カケハシがストックしている大量にオンボーディング資料で専門知識を学習 - 関連システムの開発チームに一時的に参加しラーニング - 実際の現場で手を動かしながらユーザーストーリーをこなすことが効果 的だった
State.2 要求が曖昧 - 関係者間での共通理解ができているか曖昧 Action - ユーザーストーリーマッピングを使って関係者と対話 - 曖昧な用語や概念はお互いが理解できるまで対話を続ける
Column: ユーザーストーリーテンプレート - エンドユーザー以外にも多くのアクターの要 望に応じる必要がある場合に有用 - 要求の背景となる理由の解釈にバラつきを 軽減できる FYI: https://www.agilealliance.org/glossa
ry/user-story-template/
State.3 システム境界が不明瞭である - 初回から大規模なシステムが予想されたため、概観から捉える必要が 出てきた - システム規模や複雑度、チーム分割、採用計画をある程度事前整理を した方がいいプロジェクト特性だった Action -
境界づけられたコンテキストの探求を行う
Column: 境界づけられたコンテキスト - ドメイン駆動設計のパターン・ランゲージ - ドメインモデルが適用される境界のこと - マイクロサービスの分割統治粒度を考えるにあたって 重要な設計観点としても紹介されている -
経験的には、ドメインモデルの探求の過程で整理が 進む場合が多い FYI: Martin Fowler's Bliki (ja) 境界づけれ れたコンテキスト https://bliki-ja.github.io/BoundedCont ext/
State.4 ドメインモデルが曖昧 - ビジネススキームがほぼ未定であり、 ドメインモデルが曖昧 Action - ユースケースモデリングを先行し、境 界づけられたコンテキストの推測をた てる
State.5 実証実験が困難である - 事業を実現するための多くのPoCを回す必要があった - ビジネススキームを決定するために必要な情報の欠如と実験に協力的な パートナーの不在 - 加えて、医療関連のエコシステムや商習慣はインターネット上に有益な情 報が転がっていることが少ない
Action - フロント組織の人に協力を経て、ユーザー接点機会を増やしヒアリングを 行う(継続中) - ヒアリング可能性はある程度の偶発性を伴うので、PoCのエピックを作り検 査基準を明確にした
State.6 採用の壁 - どのタイミングでどういう人を何人集めて開発をするか? Action - 事業計画とエピックから、逆算した開発マイルストーンを立てる - 境界づけられたコンテキストから、おおよそのチーム分割粒度を決める
State.6 エンジニア受け入れ体制の不整備 - 立ち上げ期はほぼ非定型業務 - 正社員が採用できることを待つスタンスだと運要素が強くなる - 業務委託の方々は受け入れづらい状況を打破する必要があった Action -
プロトタイプレベルで開発ができるアーキテクチャの構築 - ドメインモデリングを切り口に定形業務化していく
State.7 チーム間の連携方法が不明瞭である - 一部コンテキストにおいて、ドメインモデルの共用部分が境界間で曖昧で あり、モジュラモノリス戦略を立案するがうまく連携できず 原因 フィーチャーチーム間の短期的なKPIのズレ 既存フィーチャーチーム PMFに到達させることが最優先 新規フィーチャーチーム
ビジネス要求の不確実性を軽減するための段階的なモデルの検査
State.7 チーム間の連携方法が不明瞭である Action - モデルの探求をするためにプロトタイプ戦略に切り替え、敢えて短期的に 「別々の道」を選択 - 中期的には、事業部レベルでのチーミングが課題
Column: なぜ最初からマイクロサービスを進めないか? - 境界づけられたコンテキストとチームの境界が曖昧な状態でマイクロサー ビスで分離すると、分散モノリス化する可能性が高い。 分散モノリスとは - 複数のサービスで構成されているが、一緒にデプロイしなくてはいけな い状態。
Column: なぜ最初からマイクロサービスを進めないか? ログ集約 分散トレーシング コードの所有権問題 参照整合性/一貫性 カスケード障害 e2eテスト ラントップ環境の開発者体験 インフラガバナンス
etc そもそもマイクロサービスは難しい チーム体制も一緒に整えることが鉄則
State.8 チームの行動の検査が難しくなる - 異なる職能(PdM、エンジニア、サイエンティスト)間でそれぞれのテーマで PoCをやるにつれて、情報対称性の担保とプロジェクトステートの検査が難 しくなった Action - 部分的にスクラムイベントを導入 -
バックログリファインメントとプランニング、スプリントレビューだけを簡 易に取り込み ※ 目的に合わせて最小限のスクラムイベントを定義するのが好み。むやみに スクラムイベントだけを増やさない。
まとめ ドメイン駆動で体系立てて以下を整理し、チーム課題も段階的に改善を行って います。 - 要求分析 - アーキテクチャ - チーム分割統治 -
開発計画 - 採用計画 何かの参考になれば幸いですし、縁があれば一緒に切り拓いていきません か!