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
"SaaS is Dead" は本当か!? 生成AI時代の医療 Vertical SaaS のリアル
kakehashi
PRO
3
390
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
310
時間がないなら、つくればいい 〜数十人規模のチームが自律性を発揮するために試しているいくつかのこと〜
kakehashi
PRO
25
7.5k
続・やっぱり余白が大切だった話
kakehashi
PRO
4
630
AIでめっちゃ便利になったけど、結局みんなで学ぶよねっていう話
kakehashi
PRO
2
720
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
2
470
やっぱり余白が大切だった話
kakehashi
PRO
10
3.7k
貧民的プログラミングのすすめ
kakehashi
PRO
2
720
目標と時間軸 〜ベイビーステップでケイパビリティを高めよう〜
kakehashi
PRO
9
2.4k
Other Decks in Business
See All in Business
採用ピッチ資料|SBペイメントサービス株式会社
sbps
0
30k
第9回 情シス転職ミートアップ - わたしのミッションとLayerXに決めた理由
shimosyan
0
410
Platform Engineering done well: innovation, efficiency, market advantage - Matthew Skelton - ProductTank Auckland
matthewskelton
PRO
0
360
Sales Marker Culture Book(English)
salesmarker
PRO
2
5.4k
特別講義 理系のための法学入門
seko_shuhei
2
2.4k
ドクターベネフィットG紹介資料‗エムスリー
m3
0
170
5年勤めた印刷屋から ITエンジニアに転職した話
ichigats
0
160
【Progmat】Monthly-ST-Market-Report-2025-Jun.
progmat
0
260
Feedback in Action
lycorptech_jp
PRO
1
300
Morght 会社紹介資料_LAST UPDATED 2025.7
morght
1
3.7k
How can i speak to someone at Expedi𝓪® USA : A Complete Guide Steps
travelhupsupport
0
110
Things - Company Deck
things2109
0
870
Featured
See All Featured
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
We Have a Design System, Now What?
morganepeng
53
7.7k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
950
Writing Fast Ruby
sferik
628
62k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Git: the NoSQL Database
bkeepers
PRO
430
65k
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 - 部分的にスクラムイベントを導入 -
バックログリファインメントとプランニング、スプリントレビューだけを簡 易に取り込み ※ 目的に合わせて最小限のスクラムイベントを定義するのが好み。むやみに スクラムイベントだけを増やさない。
まとめ ドメイン駆動で体系立てて以下を整理し、チーム課題も段階的に改善を行って います。 - 要求分析 - アーキテクチャ - チーム分割統治 -
開発計画 - 採用計画 何かの参考になれば幸いですし、縁があれば一緒に切り拓いていきません か!