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.5k
Other Decks in Business
See All in Business
Cobe Associe: Who we are? /コンサル・市場調査・人材紹介のCobe Associe
nozomi
6
19k
イクシアス株式会社 会社紹介資料
ixyas
0
1.4k
akippa株式会社 - 会社紹介資料
akippa
4
61k
Terra Charge|会社紹介 / Terra Charge Company Profile
contents
0
160
ビジネスマナー研修用スライド
chibanba1982
PRO
0
150
enechain company deck
enechain
PRO
8
96k
イオリア株式会社 会社説明資料
aeoliainc
0
380
Fake “Agile” is the Norm: How to Instill Agility, not Agile Practices
johannarothman
PRO
0
1.4k
【新卒採用】BuySell Technologies会社紹介資料
buyselltechnologies
0
190k
Sales Marker Culture book
salesmarker
PRO
10
28k
未来の職業を作り出せ!「ジョブスタカード版」
chibanba1982
PRO
0
190
【エンジニア採用】BuySell Technologies会社説明資料
buyselltechnologies
3
56k
Featured
See All Featured
Visualization
eitanlees
146
15k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Adopting Sorbet at Scale
ufuk
74
9.2k
A Philosophy of Restraint
colly
203
16k
Speed Design
sergeychernyshev
25
740
A better future with KSS
kneath
238
17k
GraphQLとの向き合い方2022年版
quramy
44
13k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Optimising Largest Contentful Paint
csswizardry
33
3k
GitHub's CSS Performance
jonrohan
1030
460k
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