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
3.2k
ソフトウェア開発における「パーフェクトな意思決定」/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
弥生のQAエンジニア 品質保証活動と今後の課題 / Yayoi QA engineers, Quality assurance activities and future challenges
yayoi_dd
0
73
【弥生】20250130_AWSマルチアカウント運用セミナー登壇資料
yayoi_dd
2
2.5k
Amazon OpenSearchのコスト最適化とZeroETLへの期待 / Amazon OpenSearch Cost Optimization and ZeroETL Expectations
yayoi_dd
1
65
フロントエンドとバックエンド非同期連携パターンのセッションを見てきた話 / Talk about seeing a session on front-end and back-end asynchronous coordination patterns
yayoi_dd
0
66
reInventで学んだWebシステム運用のBadDayへの備え方 / How to Prepare for BadDay in Web System Operations Learned at reInvent
yayoi_dd
0
49
AWS reInventで感じた世界に見る生成AIの競争 / Competition in Generative AI as Seen Around the World at AWS reInvent
yayoi_dd
0
60
データの意味を適切に伝えましょう データ可視化のお手本/Conveying the Meaning of Data Appropriately: Exemplary Data Visualization
yayoi_dd
0
75
「失敗」から学ぶこと ~ソフトウェア開発と失敗の歴史~/Learning from 'Failures': The History of Software Development and Failures
yayoi_dd
0
68
ソフトウェアアーキテクチャーの基礎 エンジニアリングに基づく体系的アプローチ/Fundamentals of Software Architecture: A Systematic Approach Based on Engineering
yayoi_dd
0
76
Other Decks in Technology
See All in Technology
クラウドネイティブ環境の脅威モデリング
kyohmizu
1
290
AIでめっちゃ便利になったけど、結局みんなで学ぶよねっていう話
kakehashi
PRO
1
520
LLM アプリケーションのためのクラウドセキュリティ - CSPM の実装ポイント-
osakatechlab
0
160
AIによるコードレビューで開発体験を向上させよう!
moongift
PRO
0
350
ビジネスとデザインとエンジニアリングを繋ぐために 一人のエンジニアは何ができるか / What can a single engineer do to connect business, design, and engineering?
kaminashi
2
860
AIコーディングの最前線 〜活用のコツと課題〜
pharma_x_tech
4
2.9k
PostgreSQL Log File Mastery: Optimizing Database Performance Through Advanced Log Analysis
shiviyer007
PRO
1
150
日経電子版 for Android の技術的課題と取り組み(令和最新版)/android-20250423
nikkei_engineer_recruiting
1
610
ペアーズにおける評価ドリブンな AI Agent 開発のご紹介
fukubaka0825
7
2k
意思決定を支える検索体験を目指してやってきたこと
hinatades
PRO
0
390
より良い開発者体験を実現するために~開発初心者が感じた生成AIの可能性~
masakiokuda
0
230
Mastraに入門してみた ~AWS CDKを添えて~
tsukuboshi
0
380
Featured
See All Featured
BBQ
matthewcrist
88
9.6k
The Cult of Friendly URLs
andyhume
78
6.3k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
410
[RailsConf 2023] Rails as a piece of cake
palkan
54
5.5k
Facilitating Awesome Meetings
lara
54
6.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
5
590
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Music & Morning Musume
bryan
47
6.5k
YesSQL, Process and Tooling at Scale
rocio
172
14k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
820
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%納得できる決定はありえない ⚫ 意思決定者には、不安や反論と向き合う義務が生じる ◼ それでも、決定しないと次に進めない ⚫
ビジネスを前に進めるためには、意思決定は必要 ⚫ 必要な情報を揃え、勇気を持って意思決定していく ◼ 意思決定は「石のように」ではなく「水のように」 ⚫ 毎回、正しい決定をし続けるのは至難の業 ⚫ 間違いを認め、軌道修正をし、決定をし続けていく必要がある スピードが重視される世の中 「パーフェクトな意思決定」を意識してみませんか?
ご清聴ありがとうございました