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
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
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 Cloud Infrastructure:2026年5月度サービス・アップデート
oracle4engineer
PRO
1
240
人が担う「価値」とは?これからの「QA」とは / Human Value and the Future of Quality Assurance
bitkey
PRO
0
130
シンデレラなんかになりたくない!ガラスの靴が割れた時代にどう歩く?
nomizone
0
220
OpenID Connectによるサービス間連携
takesection
0
140
Dynamic Workersについて
yusukebe
1
410
AIが変えた"品質の守り方"
kkakizaki
13
5.3k
AI時代から振り返るTerraform drift運用の歴史 / AI Age Reflections on the History of Terraform Drift Operations
aeonpeople
0
580
電子辞書Brainをネットに繋げてみた(自力編)
raspython3
0
310
OpenClawとHermesAgentでAI新入社員を作った話
takanoriyanada
0
140
GitHub Copilot CLIでWebアクセシビリティを改善した話
tomokusaba
0
120
Amazon Bedrock 経由の Claude Cowork を試してみよう・MCP にも繋いでみよう
sugimomoto
0
250
ポスター発表&デモと総括 / Poster Presentations & Demonstrations and Summary
ks91
PRO
0
150
Featured
See All Featured
Practical Orchestrator
shlominoach
191
11k
Ethics towards AI in product and experience design
skipperchong
2
290
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
2
560
The World Runs on Bad Software
bkeepers
PRO
72
12k
Building an army of robots
kneath
306
46k
Reality Check: Gamification 10 Years Later
codingconduct
0
2.2k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
0
1.5k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.9k
Fireside Chat
paigeccino
42
3.9k
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
370
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
210
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%納得できる決定はありえない ⚫ 意思決定者には、不安や反論と向き合う義務が生じる ◼ それでも、決定しないと次に進めない ⚫
ビジネスを前に進めるためには、意思決定は必要 ⚫ 必要な情報を揃え、勇気を持って意思決定していく ◼ 意思決定は「石のように」ではなく「水のように」 ⚫ 毎回、正しい決定をし続けるのは至難の業 ⚫ 間違いを認め、軌道修正をし、決定をし続けていく必要がある スピードが重視される世の中 「パーフェクトな意思決定」を意識してみませんか?
ご清聴ありがとうございました