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
660
新規事業立ち上げ時のエンジニアリング
kakehashi
October 28, 2021
Tweet
Share
More Decks by kakehashi
See All by kakehashi
Agile Tech EXPO_2022/カケハシ
kakehashi
0
82
TechPlay22_06_28_Full TypeScriptで新規プロダクトを立ち上げた際に実践した設計と反省
kakehashi
0
260
異分野の知見を活かす、DevOpsの実践: Learning from Other Fields
kakehashi
1
1.2k
1万台のRaspberry_Pi4を制御する_AWS_IoTで実現する新処方箋情報基盤.pdf
kakehashi
0
990
業務システムにも使いやすいUIを。モダンフロントエンドの技術選定
kakehashi
0
960
新規開発のスーパーカオス期からの スクラム導入Step by Step
kakehashi
0
850
薬局の在庫発注管理の難しさと機械学習活用
kakehashi
0
930
株式会社カケハシ_採用サイト2022年1月時点
kakehashi
1
5k
KAKEHASHI-会社説明資料-2022.07
kakehashi
2
10k
Other Decks in Business
See All in Business
VisasQ's Culture Book
eikohashiba
1
33k
[월간 데이터리안 세미나 7월] 데이터 기반 의사 결정, 이렇게 합니다
datarian
0
260
タケウチグループRecruit
takeuchigroup
0
3.5k
with_company_info.pdf
with
0
5.6k
EmbedSocial サポートプラン
esj
0
560
メドピアグループ紹介資料
medpeer_recruit
4
39k
minma_corporate
minma_curama
1
110
220727 QA資料 【徹底解説】業務改善の進め方/フレームワークを学ぶ!~計画段階で差が付く関係者会議の秘訣~ 株式会社シイエム・シイ
comucal
PRO
0
260
Pococha CultureDeck
daisukemzt
16
18k
クラフタ_サービス資料/Crafta
growba
0
3.9k
LayerX Company Deck
layerx
PRO
2
8.8k
15分で学ぶ Amazon Connect入門
shigematsukodai
0
1.3k
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1020
420k
Gamification - CAS2011
davidbonilla
75
3.9k
Bootstrapping a Software Product
garrettdimon
296
110k
Imperfection Machines: The Place of Print at Facebook
scottboms
253
12k
Mobile First: as difficult as doing things right
swwweet
213
7.6k
Stop Working from a Prison Cell
hatefulcrawdad
262
17k
Bash Introduction
62gerente
598
210k
Build your cross-platform service in a week with App Engine
jlugia
219
17k
The MySQL Ecosystem @ GitHub 2015
samlambert
239
11k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
12
940
GraphQLとの向き合い方2022年版
quramy
16
8.4k
Principles of Awesome APIs and How to Build Them.
keavy
113
15k
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 - 部分的にスクラムイベントを導入 -
バックログリファインメントとプランニング、スプリントレビューだけを簡 易に取り込み ※ 目的に合わせて最小限のスクラムイベントを定義するのが好み。むやみに スクラムイベントだけを増やさない。
まとめ ドメイン駆動で体系立てて以下を整理し、チーム課題も段階的に改善を行って います。 - 要求分析 - アーキテクチャ - チーム分割統治 -
開発計画 - 採用計画 何かの参考になれば幸いですし、縁があれば一緒に切り拓いていきません か!