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
3
3k
ソフトウェア開発における「パーフェクトな意思決定」/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
【弥生】20250130_AWSマルチアカウント運用セミナー登壇資料
yayoi_dd
1
240
Amazon OpenSearchのコスト最適化とZeroETLへの期待 / Amazon OpenSearch Cost Optimization and ZeroETL Expectations
yayoi_dd
1
39
フロントエンドとバックエンド非同期連携パターンのセッションを見てきた話 / Talk about seeing a session on front-end and back-end asynchronous coordination patterns
yayoi_dd
0
41
reInventで学んだWebシステム運用のBadDayへの備え方 / How to Prepare for BadDay in Web System Operations Learned at reInvent
yayoi_dd
0
29
AWS reInventで感じた世界に見る生成AIの競争 / Competition in Generative AI as Seen Around the World at AWS reInvent
yayoi_dd
0
37
データの意味を適切に伝えましょう データ可視化のお手本/Conveying the Meaning of Data Appropriately: Exemplary Data Visualization
yayoi_dd
0
50
「失敗」から学ぶこと ~ソフトウェア開発と失敗の歴史~/Learning from 'Failures': The History of Software Development and Failures
yayoi_dd
0
52
ソフトウェアアーキテクチャーの基礎 エンジニアリングに基づく体系的アプローチ/Fundamentals of Software Architecture: A Systematic Approach Based on Engineering
yayoi_dd
0
54
Lambdaの特徴を理解して活用する/Understanding and utilizing the features of Lambda
yayoi_dd
2
56
Other Decks in Technology
See All in Technology
PHPカンファレンス名古屋-テックリードの経験から学んだ設計の教訓
hayatokudou
2
390
目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる / Every little bit counts
soudai
25
7.2k
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
560
Developer Summit 2025 [14-D-1] Yuki Hattori
yuhattor
19
6.3k
転生CISOサバイバル・ガイド / CISO Career Transition Survival Guide
kanny
3
1k
自動テストの世界に、この5年間で起きたこと
autifyhq
10
8.6k
RSNA2024振り返り
nanachi
0
590
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
18
6.9k
データ資産をシームレスに伝達するためのイベント駆動型アーキテクチャ
kakehashi
PRO
2
550
インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて
nwiizo
5
2.6k
JEDAI Meetup! Databricks AI/BI概要
databricksjapan
0
150
Active Directoryハッキング
cryptopeg
1
140
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
Writing Fast Ruby
sferik
628
61k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Typedesign – Prime Four
hannesfritz
40
2.5k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
330
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
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%納得できる決定はありえない ⚫ 意思決定者には、不安や反論と向き合う義務が生じる ◼ それでも、決定しないと次に進めない ⚫
ビジネスを前に進めるためには、意思決定は必要 ⚫ 必要な情報を揃え、勇気を持って意思決定していく ◼ 意思決定は「石のように」ではなく「水のように」 ⚫ 毎回、正しい決定をし続けるのは至難の業 ⚫ 間違いを認め、軌道修正をし、決定をし続けていく必要がある スピードが重視される世の中 「パーフェクトな意思決定」を意識してみませんか?
ご清聴ありがとうございました