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
yayoi_dd
December 26, 2024
Technology
0
20
ソフトウェア開発における「パーフェクトな意思決定」/Perfect Decision-Making in Software Development
弥生株式会社 もくテク
読んでよかった技術書・ビジネス書LT
https://mokuteku.connpass.com/event/340131/
yayoi_dd
December 26, 2024
Tweet
Share
More Decks by yayoi_dd
See All by yayoi_dd
データの意味を適切に伝えましょう データ可視化のお手本/Conveying the Meaning of Data Appropriately: Exemplary Data Visualization
yayoi_dd
0
15
「失敗」から学ぶこと ~ソフトウェア開発と失敗の歴史~/Learning from 'Failures': The History of Software Development and Failures
yayoi_dd
0
22
ソフトウェアアーキテクチャーの基礎 エンジニアリングに基づく体系的アプローチ/Fundamentals of Software Architecture: A Systematic Approach Based on Engineering
yayoi_dd
0
17
Lambdaの特徴を理解して活用する/Understanding and utilizing the features of Lambda
yayoi_dd
2
37
SIEM on Amazon OpenSearchで得たOSSを利用する上での教訓/Lessons learned when using OSS
yayoi_dd
1
31
RDS Aurora MySQLを用いたデータ連携でやらかした話/Story about when linking data using RDS Aurora MySQL
yayoi_dd
1
46
ライフサイクル考えられていますか/Do you think about lifecycle
yayoi_dd
1
39
プロンプトエンジニアリングに触れてみよう / Let's try prompt engineering!
yayoi_dd
1
2.5k
ChatGPTによるお手軽データ分析 / Easy data analysis with ChatGPT
yayoi_dd
1
2.5k
Other Decks in Technology
See All in Technology
podman_update_2024-12
orimanabu
1
290
Microsoft Azure全冠になってみた ~アレを使い倒した者が試験を制す!?~/Obtained all Microsoft Azure certifications Those who use "that" to the full will win the exam! ?
yuj1osm
2
120
Opcodeを読んでいたら何故かphp-srcを読んでいた話
murashotaro
0
320
2024年にチャレンジしたことを振り返るぞ
mitchan
0
150
LINEヤフーのフロントエンド組織・体制の紹介【24年12月】
lycorp_recruit_jp
0
550
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
300
なぜCodeceptJSを選んだか
goataka
0
180
クレカ・銀行連携機能における “状態”との向き合い方 / SmartBank Engineer LT Event
smartbank
2
100
ゼロから創る横断SREチーム 挑戦と進化の軌跡
rvirus0817
3
280
[JAWS-UG新潟#20] re:Invent2024 -CloudOperationsアップデートについて-
shintaro_fukatsu
0
120
5分でわかるDuckDB
chanyou0311
10
3.3k
TSKaigi 2024 の登壇から広がったコミュニティ活動について
tsukuha
0
170
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
A designer walks into a library…
pauljervisheath
205
24k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Agile that works and the tools we love
rasmusluckow
328
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
111
49k
For a Future-Friendly Web
brad_frost
175
9.4k
Code Reviewing Like a Champion
maltzj
521
39k
Thoughts on Productivity
jonyablonski
68
4.4k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2k
Automating Front-end Workflow
addyosmani
1366
200k
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%納得できる決定はありえない ⚫ 意思決定者には、不安や反論と向き合う義務が生じる ◼ それでも、決定しないと次に進めない ⚫
ビジネスを前に進めるためには、意思決定は必要 ⚫ 必要な情報を揃え、勇気を持って意思決定していく ◼ 意思決定は「石のように」ではなく「水のように」 ⚫ 毎回、正しい決定をし続けるのは至難の業 ⚫ 間違いを認め、軌道修正をし、決定をし続けていく必要がある スピードが重視される世の中 「パーフェクトな意思決定」を意識してみませんか?
ご清聴ありがとうございました