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
shimobayashi
August 09, 2023
Business
1
1.7k
「いい感じにしといて」を支える技術
プロダクト開発の課題発見と管理の仕方について、具体例を交えながら紹介します。
shimobayashi
August 09, 2023
Tweet
Share
More Decks by shimobayashi
See All by shimobayashi
コミュニティを育てて会社を変える
shimobayashi
10
5.6k
Other Decks in Business
See All in Business
顧客に選ばれることから始める競争優位5条件を追求するプロダクトマネジメントゲーム/Five Criteria of Competitive Advantage SFF2025
moriyuya
1
350
顧客とユーザーと私/Dancing with customers and users
ikuodanaka
2
690
FastAccounting会社資料_202504
fahrteam
0
1.9k
ご参考資料
ryoheig0405
1
200
セイホ工業株式会社
seiho
1
130
株式会社WOGO 採用向け 会社紹介資料 2025/01
koeru
0
350
目安箱の設置とワークさせるポイント
konifar
4
1.5k
株式会社調布清掃 会社説明資料
ldk_by_bridge
0
13k
大城エネルギー 会社紹介スライド
daijyou
0
4.5k
【キャリア採用】BuySell Technologies会社説明資料
buyselltechnologies
2
87k
RightTouch Company Deck ver1.0
righttouch
PRO
3
920
【DearOne】Dear Newest Member
hrm
2
8k
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
36
1.7k
Bash Introduction
62gerente
611
210k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
How to train your dragon (web standard)
notwaldorf
91
5.9k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Scaling GitHub
holman
459
140k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
25k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Unsuck your backbone
ammeep
670
57k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Transcript
「いい感じにしといて」を 支える技術 id:shimobayashi はてなエンジニアセミナー #26 2023/08/09 1
自己紹介 • id:shimobayashi • 2023/2 EMになった&異動 ◦ やったことない働き方を、2つの知ら ないチームでやることになった 2
before/after • before: 課題が示されていることが多かった • after: 「いい感じにしといて」になった • マインドチェンジが必要になった 3
EMについて改めて考えた • EMとは、プロダクト開発をいい感じにする人 • いい感じにするとは、課題を発見・管理・解 決すること 4
話したいこと • プロダクト開発の課題を発見・管理・解決す る方法について、やったことを話したい ◦ 何かの参考になれば、と思います 5
「いい感じ」にするステップ 1. 情報収集 2. 課題発見 3. 課題管理 4. 課題解決 実際はこの間を行ったり来たりしながら進める
テクニックも色々ある 6
情報収集する 7
情報収集する • 何も分からないので、まずは情報収集する • とはいえ、闇雲にやっても効率が悪い • →プロダクト開発のメンタルモデルに沿うこ とで必要な情報を集めた 8
プロダクト開発のメンタルモデル 個人的には、 MVV, 売上 > 戦略 > 作戦 > 計画
> 体制・予算 というのがしっくりくる 9
しっくりくるメンタルモデルが大事 • 現場ごとにしっくりくるメンタルモデルを選 べると整理しやすい ◦ ウォーターフォール(Vモデル)、反復型開発、アジャ イルソフトウェア開発、…… • 参考資料: 自分の考え
◦ 現代ソフトウェア開発の地図 ◦ 開発プロセスの変遷モデル 10
情報収集の様子 11 自分でまとめたり、コメントをもらったりして集めた
課題発見する 12
課題発見する • 集めた情報を整理すると、課題が見えてくる • 整理の手法として、以下のようなものがある ◦ ロジックツリー ◦ 現状問題構造ツリー 13
自分の場合のイメージ 14 MVV 企画的戦略 企画的作戦 計画 技術的戦略 技術的作戦 施策 施策
施策 体制・予算 人員 お金 etc… 改めてプロダクト開発のメンタルモデルに沿って整理する そうすると、弱いところ=課題が見えてくる 売上
課題発見の様子 15 課題にうまく対処できていそうだが 一時的なマンパワー不足が課題 企画的戦略を中心とした他要素との整合性に 課題感あり
課題管理する 16
課題管理する • 図は扱いづらいので、リスト化して管理する ◦ どんな課題があってどんな着手順か、認識をすり合わ せる • 一般的には以下のように呼ばれている ◦ 課題管理表
◦ 妨害リスト 17
着手順の考え方 18 やる 1 予定する 2 任せる 3 やらない 4
緊急 緊急ではない 重要 重要ではない いわゆるアイゼンハワーマトリクスに当てはめると考えやすい
着手順の考え方 • 緊急とは、締め切りが近いかどうか • 重要とは、MVVへの貢献が大きいかどうか 19
課題管理の様子 20
(再掲)課題発見の様子 21 課題にうまく対処できていそうだが 一時的なマンパワー不足が課題 企画的戦略を中心とした他要素との整合性に 課題感あり
自分の場合 • マンパワー不足解消を最優先 ◦ 一時的に雑用を引き受ける判断をした • その次に企画的戦略・技術的戦略整理を並行 ◦ 企画的戦略がすぐに整理できなさそうだったので、そ れまで技術的戦略を放置できないという判断をした
22
23 課題解決する
解決法の見つけ方 • 課題によって違うので、一概に言えない • 世間や他のチームとのギャップに着目する と、ヒントが見つかることが多い ◦ 例: 当初立てた計画通りに開発を進行できない ▪
世間的には反復型の開発プロセスが流行っている ▪ 他のチームはバッファを積みまくることで対処してるかも 24
解決法の見つけ方 • しかし、解決法だけを真似るのは危険 ◦ 「スクラムが良いらしいからやるぞ!」みたいな ◦ 課題と解決法が本当に合っているか考えないと、効果 が無いことにコストを割いてしまう懸念 25
26 まとめ
「いい感じ」にするステップ 1. 情報収集 2. 課題発見 3. 課題管理 4. 課題解決 実際はこの間を行ったり来たりしながら進める
テクニックも色々ある 27