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.4k
新規事業立ち上げ時のエンジニアリング
KAKEHASHI
PRO
October 28, 2021
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
安定した基盤システムのためのライブラリ選定
kakehashi
PRO
3
130
"SaaS is Dead" は本当か!? 生成AI時代の医療 Vertical SaaS のリアル
kakehashi
PRO
4
640
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
340
時間がないなら、つくればいい 〜数十人規模のチームが自律性を発揮するために試しているいくつかのこと〜
kakehashi
PRO
25
7.6k
続・やっぱり余白が大切だった話
kakehashi
PRO
4
650
AIでめっちゃ便利になったけど、結局みんなで学ぶよねっていう話
kakehashi
PRO
2
750
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
2
490
やっぱり余白が大切だった話
kakehashi
PRO
10
3.7k
貧民的プログラミングのすすめ
kakehashi
PRO
2
750
Other Decks in Business
See All in Business
Sales Marker Culture Book(English)
salesmarker
PRO
2
5.5k
Platform Engineering done well: innovation, efficiency, market advantage - Matthew Skelton - ProductTank Auckland
matthewskelton
PRO
0
430
エンジニアのための事業貢献入門/A business introduction for engineers
dskst
52
15k
KINTOテクノロジーズ OsakaTechLab説明資料 / ktc-osakatechlab-introduction.pdf
ktc_creative
0
730
特別講義 理系のための法学入門
seko_shuhei
2
2.4k
SlackでDMを使わない方が いい理由を説明してみた
walkersumida
1
1.1k
クリフトンストレングスを用いたチームビルディングワークショップ
chibanba1982
PRO
1
240
株式会社レコモット会社紹介資料
recomothr
0
9.8k
組織を AI との協働に最適化する ~ AI と人が補完しあって成長し続ける組織の作り方 ~
yoshizaki
0
560
日本ロボット工業会:講演「中国のヒューマノイド・ロボットの開発と利用の最新動向」 20250625
takasumasakazu
1
2.6k
Company Deck_2025.06
sixtypercent
0
640
AI時代における変革の入口-100年後も語られる25年のために- #scrumosaka / The entry point to transformation in the AI era For 25 years that will be talked about 100 years from now
kyonmm
PRO
4
250
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
40
1.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Producing Creativity
orderedlist
PRO
346
40k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
A designer walks into a library…
pauljervisheath
207
24k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
282
13k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Building Applications with DynamoDB
mza
95
6.5k
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 - 部分的にスクラムイベントを導入 -
バックログリファインメントとプランニング、スプリントレビューだけを簡 易に取り込み ※ 目的に合わせて最小限のスクラムイベントを定義するのが好み。むやみに スクラムイベントだけを増やさない。
まとめ ドメイン駆動で体系立てて以下を整理し、チーム課題も段階的に改善を行って います。 - 要求分析 - アーキテクチャ - チーム分割統治 -
開発計画 - 採用計画 何かの参考になれば幸いですし、縁があれば一緒に切り拓いていきません か!