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
ソフトウェア開発における「パーフェクトな意思決定」/Perfect Decision-Maki...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
yayoi_dd
December 26, 2024
Technology
3.7k
3
Share
ソフトウェア開発における「パーフェクトな意思決定」/Perfect Decision-Making in Software Development
弥生株式会社 もくテク
読んでよかった技術書・ビジネス書LT
https://mokuteku.connpass.com/event/340131/
yayoi_dd
December 26, 2024
More Decks by yayoi_dd
See All by yayoi_dd
AWS re:Invent 2025 参加報告 / AWS re:Invent 2025 Participation Report
yayoi_dd
0
24
re:Inventの学びを最大化するためにしたこと / What I Did to Maximize Learning at re:Invent
yayoi_dd
0
24
Werner Vogelsが語った”T型人材” / "T-Shaped Talent" as Discussed by Werner Vogels
yayoi_dd
0
23
AI駆動開発のさらにその先へ / Beyond AI-Driven Development
yayoi_dd
0
28
AWS DevOps Agentで見えた運用の未来 / The Future of Operations with AWS DevOps Agent
yayoi_dd
0
24
OpenSearch Warm Tier設計の実践 / Practical Implementation of OpenSearch Warm Tier Design
yayoi_dd
0
48
なぜ私たちは「生成AI-LT大会」を終了するのか / Why we are ending the Generative AI-LT competition
yayoi_dd
0
74
AIと働く / Working with AI
yayoi_dd
0
83
AIで未経験タスクの心理的ハードルが下がった話 / How AI has lowered the psychological barrier to unfamiliar tasks
yayoi_dd
0
52
Other Decks in Technology
See All in Technology
Oracle AI Database@Google Cloud:サービス概要のご紹介
oracle4engineer
PRO
6
1.5k
CloudFront VPCオリジンとVPC Latticeサービスの内部ALBをマルチアカウントで一元利用しよう
duelist2020jp
5
260
Sony_KMP_Journey_KotlinConf2026
sony
0
170
食べログのサーキットブレーカー導入を振り返って
atpons
1
150
類似画像検索モデルの開発ノウハウ
lycorptech_jp
PRO
4
1k
AI時代の私の技術インプットとアウトプット術
tonkotsuboy_com
15
7.7k
Dynamic Workersについて
yusukebe
1
420
Cloud Run のアップデート 触ってみる&紹介
gre212
0
220
ポスター発表&デモと総括 / Poster Presentations & Demonstrations and Summary
ks91
PRO
0
150
OpenClawとHermesAgentでAI新入社員を作った話
takanoriyanada
0
140
自称宇宙最速で不合格となったAIP-C01にリベンジを果たすべくAIで問題集アプリを作ってみた。
yama3133
0
240
ITエンジニアを取り巻く環境とキャリアパス / A career path for Japanese IT engineers
takatama
4
1.8k
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
KATA
mclloyd
PRO
35
15k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
1.5k
So, you think you're a good person
axbom
PRO
2
2k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
180
VelocityConf: Rendering Performance Case Studies
addyosmani
333
25k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
190
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.1k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.2k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
430
Rebuilding a faster, lazier Slack
samanthasiow
85
9.5k
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
370
Transcript
ソフトウェア開発における 『パーフェクトな意思決定』 弥生株式会社 志田 拓也
自己紹介 志田 拓也 ▪2021年12月 弥生にJoin ▪弥生会計オンライン・やよいの青色申告オンライン 開発チーム プロジェクトマネージャー ▪基本的に優柔不断で、近所のスーパーでも 買い物に30分以上かけることはザラ
▪そんな私が「意思決定」を語ります
今回の本の紹介 ◼ 「パーフェクトな意思決定」
なぜこの本を選んだか? ◼ 意思決定に対するニガテ意識があったため ⚫ PMとして、意思決定は避けられない ⚫ 自身の決定が満場一致で歓迎されることは、まずない ⚫ 何か物事を決める際には、板挟みで考える事が多く、決断が難しい ⚫
決めた後にも、反論や変化に向き合わなければいけない ⚫ ・・・など、ネガティブ要素は上げればキリがない 総じて「決断」という行為自体が非常にストレス (現在進行系)
この本はどんな人にオススメ? ⚫ ある程度「決定責任」がある人 ⚫ 「検討します」が口癖になっている人 ⚫ 決定には全員の納得が必要だと思っている人 ⚫ 一度決めたことをコロコロ変えないことが「意思決定」の 肝だと考えている人
⚫ 逆に、意思決定の判断を仰ぐ立場の人 ・・・など ビジネスパーソンである以上、 意思決定には何らかの形で関わるはず →なので、すべての方にオススメ!
この本の構成 ◼ なぜ決めることは怖いのか ◼ 「正しい意思決定」という勘違い ◼ 「よく考える」の正体 ◼ 自分が決めない「聖域」 ◼
「勇気」としか言いようがないもの
この本の構成 ◼ なぜ決めることは怖いのか ◼ 「正しい意思決定」という勘違い ◼ 「よく考える」の正体 ◼ 自分が決めない「聖域」 ◼
「勇気」としか言いようがないもの ここで語られている 「3つの箱」という話にフォーカス
意思決定の3つの箱 即決 情報不足 期限を設定する
1つ目の箱「即決」 ◼ 何よりもスピード重視 ⚫ 選択肢が明確な場合は、意思決定者は明確に決める ⚫ 判断を引き延ばすことはビジネススピードの停滞を招く ◼ 無理に全員の理解を得る必要はない ⚫
十分な情報と権限があるならば、全員の賛同を待たず、意思決定を行う ⚫ 決まった内容とそれを実効するためのレクチャーを行う
2つ目の箱「情報不足」 ◼ 意思決定に必要な情報が足りない ⚫ 意思決定の難易度が高い、決定により生じるインパクトが大きい場合など ⚫ 決定に必要な情報を集める必要がある ◼ 必要な情報を集める際のコツ ⚫
意思決定者だけが動くのではなく、全員で情報を収集する ⚫ そうすることで、最終的に意思決定が早まり、 全員が決まったゴールに向かって進むことが早期に可能となる
3つ目の箱「期限を設定する」 ◼ 長いスパンで判断したい場合 ⚫ 即断即決が向かないケースも存在する ⚫ ある程度観測を行ったうえで意思決定を行う ◼ 期限は必ず設定する ⚫
観測を決めた場合でも期限は必ず設ける ⚫ 観測の中で「期限を伸ばす」と判断するのはありだが、 その判断自体の期限を必ず設ける
ソフトウェア開発で考えてみる
1つ目の箱「即決」 ◼ 作業担当者をアサインする場合 Q:機能Aの仕様について確認したいのですが、誰に聞けばいいですか? A:XXさんに聞いて下さい ⚫ ある程度チームの進捗状況が把握できていれば、都度伺いを立てる必要はない ⚫
余分な確認を挟むことで、スピードの低下につながる恐れがある ⚫ 問題がある場合は本人からアラートを上げてもらう、ということを事前に取り決 めておけるとベター 必要な情報が揃っている場合は、無駄に引き伸ばさない
2つ目の箱「情報不足」 ◼ 作業方針に対して反論が上がった場合 Q:新規作成するB機能ですが、A機能からの模範で作るのではなく、 ゼロベースで検討し直したほうが本質的ではないでしょうか? A:意思決定に必要な情報(期間、リソース等)を収集する必要があります ⚫ 判断が難しい場合は「どうすればシンプルな判断ができるのか」を考える
⚫ そのために必要な情報を集める必要がある ⚫ 今回のケースだと、ゼロベースで検討する際の情報以外にも、 「そもそもゼロベースで検討し直せる予算やスケジュールがあるか」という 前提の確認も重要な要素となる 意思決定を行うためには何が必要か?を考える
3つ目の箱「期限を設定する」 ◼ 機能の削除を検討する場合 Q:C機能はユーザーがあまり使っていないようです。一方で保守は大変です。 そのため、機能自体を削除すべきではないでしょうか? A:今期の利用状況を収集したうえで、X月までに判断します ⚫ 判断に時間軸が必要な場合は期限を設ける
⚫ このケースでは「一定期間内の利用状況」を分析する必要があるため、 情報を集めるために期間が必要 ⚫ 期限は必ず設ける あらかじめ決めた期限が来たら、しっかり決める 「放っておかないこと」が大事
アンチパターン「検討します」
「検討します」は全裸より恥ずかしい ◼ 本当に検討することは稀 ⚫ そもそも「検討します」は言い逃れやその場しのぎの思いが大きい ⚫ 相手が勝手に諦めるのを待つ場合に使いがち ◼ 決定しないことは責任の放棄 ⚫
保留にされた側はずっとモヤモヤが残る ⚫ 「やらない」という決定をしたほうが、判断を仰ぐ側にとっても建設的 ◼ 現状維持はリスク ⚫ 判断を保留にすることで、停滞や未来の機会損失につながる ⚫ 失敗からは学べるが、保留からは学びはない 必ずどれかの箱に入れることを検討すべき 決めることも責任のうち
まとめ ◼ 意思決定は辛くて当たり前! ⚫ 全員が100%納得できる決定はありえない ⚫ 意思決定者には、不安や反論と向き合う義務が生じる ◼ それでも、決定しないと次に進めない ⚫
ビジネスを前に進めるためには、意思決定は必要 ⚫ 必要な情報を揃え、勇気を持って意思決定していく ◼ 意思決定は「石のように」ではなく「水のように」 ⚫ 毎回、正しい決定をし続けるのは至難の業 ⚫ 間違いを認め、軌道修正をし、決定をし続けていく必要がある スピードが重視される世の中 「パーフェクトな意思決定」を意識してみませんか?
ご清聴ありがとうございました