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
October 28, 2021
Business
1
1.3k
新規事業立ち上げ時のエンジニアリング
kakehashi
October 28, 2021
Tweet
Share
More Decks by kakehashi
See All by kakehashi
linkマクロが使いたい/smart knowledge management with link macro
kakehashi
2
68
Value Driven DevOps Team
kakehashi
13
2.6k
GitHubを使わずDatabricksだけで お手軽にライブラリ共有やCIが できる環境を作ってみた/Creating an Environment for Easy Library Sharing and CI Using Only Databricks Without GitHub
kakehashi
1
300
循環する学び~現場とコミュニティの境目で考える~/Learning Cycle between a team and a community
kakehashi
14
6.6k
新規プロダクトの仮説検証ループをすばやく回し続けるためのプロダクトエンジニアリング/PdENight3
kakehashi
15
4.6k
ドメイン知識を活用した、薬局における患者の来局予測/Predicting Patient Visits to Pharmacies Using Domain Knowledge
kakehashi
3
240
「業務システムSPAのフロントエンド技術選定」 の振り返り/furikaeri about our SPA stack 2023
kakehashi
1
360
Databricksで築く未来のデータメッシュ組織/The Datamesh Organization Built with Databricks
kakehashi
3
1.3k
薬局組織の内部を探る BIツールを通じたドメイン理解/Explore inside the pharmacy Domain understanding through BI tools
kakehashi
2
1k
Other Decks in Business
See All in Business
KADOKAWA Connected|会社紹介資料/Corporate Introduction
kadokawaconnected
4
50k
株式会社トラストバンク_採用ピッチ資料
sugahara
0
550
ラクスル株式会社 会社概要(IR)
raksulrecruiting
5
5.1k
plan-renewal-freee-2024
yuki_yano
PRO
0
110
enechain company deck
enechain
PRO
2
68k
Nstock 採用資料 / We are hiring
nstock
20
150k
Findy - 人生で熱くなれるなにかを探している誰かへ / Letter from Findy
findyinc
6
110k
社会変化兆候調査 vol.17 / 132 global changes in lifestyle 2024 vol.17
nozomi
0
170
Стратегия решает проблемы на всех уровнях компании
alexanderbyndyu
0
140
東大放射線科2025年度入局者向け資料
utrad
0
460
株式会社CINC 会社案内/Company introduction
cinchr
5
33k
OH MY GOD inc. 会社概要
fujiyamayuta
0
13k
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
260
12k
Mobile First: as difficult as doing things right
swwweet
216
8.6k
Fontdeck: Realign not Redesign
paulrobertlloyd
76
4.9k
Unsuck your backbone
ammeep
663
57k
Designing on Purpose - Digital PM Summit 2013
jponch
110
6.5k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
125
32k
How STYLIGHT went responsive
nonsquared
92
4.8k
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
Rebuilding a faster, lazier Slack
samanthasiow
73
8.2k
Building Better People: How to give real-time feedback that sticks.
wjessup
355
18k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
659
120k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
20
1.9k
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 - 部分的にスクラムイベントを導入 -
バックログリファインメントとプランニング、スプリントレビューだけを簡 易に取り込み ※ 目的に合わせて最小限のスクラムイベントを定義するのが好み。むやみに スクラムイベントだけを増やさない。
まとめ ドメイン駆動で体系立てて以下を整理し、チーム課題も段階的に改善を行って います。 - 要求分析 - アーキテクチャ - チーム分割統治 -
開発計画 - 採用計画 何かの参考になれば幸いですし、縁があれば一緒に切り拓いていきません か!