Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
新規事業立ち上げ時のエンジニアリング
kakehashi
October 28, 2021
Business
0
880
新規事業立ち上げ時のエンジニアリング
kakehashi
October 28, 2021
Tweet
Share
More Decks by kakehashi
See All by kakehashi
データ基盤チームの紹介
kakehashi
0
16
Databricksでのデータ権限管理方針について.pdf
kakehashi
0
69
カケハシがDatabricksを採用した背景 〜薬局DXを支えるデータ基盤が目指す姿〜
kakehashi
0
16
KAKEHASHI-会社説明資料-2023.01
kakehashi
3
20k
プロダクト成長とともに変化に強くする方法
kakehashi
0
310
Agile Tech EXPO_2022/カケハシ
kakehashi
0
590
TechPlay22_06_28_Full TypeScriptで新規プロダクトを立ち上げた際に実践した設計と反省
kakehashi
0
640
異分野の知見を活かす、DevOpsの実践: Learning from Other Fields
kakehashi
1
1.6k
1万台のRaspberry_Pi4を制御する_AWS_IoTで実現する新処方箋情報基盤.pdf
kakehashi
0
1.2k
Other Decks in Business
See All in Business
株式会社WEIN Group_会社説明資料
weingroup0213
0
1.2k
[ウェビナー資料] AWSエンジニア1年目が考える学習エンジンを止めない4つのコツ
o2mami
0
960
開発本部紹介資料
makuake_saiyou
0
1.2k
RPALT WinActor Talk / LT4 : WinActor's novelty introduction
tsutomu_asari
0
340
TOKIUM 会社紹介資料
morita0921
1
23k
SWOT Bot - Electronic Arts
swotbot
0
480
株式会社ルネックスプロテクト
runex
0
130
アジャイル開発 QAチーム不要論
rhdoh
2
140
Findy - 人生で熱くなれるなにかを探している誰かへ / Letter from Findy
findyinc
6
57k
株式会社コドモン会社紹介資料2022
codmoninc
0
110
思い込みが激しい人の理屈がわかる資料
nyattx
PRO
1
1.2k
WASABI Company Guide
takumiman5
0
230
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
2
300
Embracing the Ebb and Flow
colly
75
3.6k
What's new in Ruby 2.0
geeforr
336
30k
Become a Pro
speakerdeck
PRO
6
3.2k
A Tale of Four Properties
chriscoyier
149
21k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
44
14k
Robots, Beer and Maslow
schacon
154
7.3k
Building Adaptive Systems
keathley
27
1.3k
Adopting Sorbet at Scale
ufuk
65
7.8k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
657
120k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
175
9.1k
4 Signs Your Business is Dying
shpigford
171
20k
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 - 部分的にスクラムイベントを導入 -
バックログリファインメントとプランニング、スプリントレビューだけを簡 易に取り込み ※ 目的に合わせて最小限のスクラムイベントを定義するのが好み。むやみに スクラムイベントだけを増やさない。
まとめ ドメイン駆動で体系立てて以下を整理し、チーム課題も段階的に改善を行って います。 - 要求分析 - アーキテクチャ - チーム分割統治 -
開発計画 - 採用計画 何かの参考になれば幸いですし、縁があれば一緒に切り拓いていきません か!