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
20231118_過去の叡智から学ぶ効率的なアウトプット術
Search
hi-rose
November 19, 2023
Technology
0
150
20231118_過去の叡智から学ぶ効率的なアウトプット術
「Rakuten Technology Conference 2023 in 札幌」でのLT資料。
hi-rose
November 19, 2023
Tweet
Share
More Decks by hi-rose
See All by hi-rose
Kubernetes入門#5 The pod resource and QoS / Kubernetes Getting Started#5
hirose39
1
350
Kubernetes入門#4 About Kubernetes Uses With GKE & EKS
hirose39
1
350
Kubernetes入門#3 About ConfigMap and Secret / Kubernetes Getting Started#3
hirose39
1
590
Kubernetes入門#2 CronJob / Kubernetes Getting Started#2 CronJob
hirose39
1
570
Kubernetes入門#1 運用例の紹介 / Kubernetes Getting Started#1 Case Introduction for k8ssa
hirose39
0
280
Other Decks in Technology
See All in Technology
システムのアラート調査をサポートするAI Agentの紹介/Introduction to an AI Agent for System Alert Investigation
taddy_919
2
1.6k
サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit
cybozuinsideout
PRO
10
73k
データ民主化のための LLM 活用状況と課題紹介(IVRy の場合)
wxyzzz
2
640
プロダクト成長を支える開発基盤とスケールに伴う課題
yuu26
3
1.1k
We Built for Predictability; The Workloads Didn’t Care
stahnma
0
130
SREのプラクティスを用いた3領域同時 マネジメントへの挑戦 〜SRE・情シス・セキュリティを統合した チーム運営術〜
coconala_engineer
2
550
会社紹介資料 / Sansan Company Profile
sansan33
PRO
15
400k
AI推進者の視点で見る、Bill OneのAI活用の今
sansantech
PRO
2
330
Deno・Bunの標準機能やElysiaJSを使ったWebSocketサーバー実装 / ラーメン屋を貸し切ってLT会! IoTLT 2026新年会
you
PRO
0
260
Bill One急成長の舞台裏 開発組織が直面した失敗と教訓
sansantech
PRO
1
180
プロポーザルに込める段取り八分
shoheimitani
0
100
2人で作ったAIダッシュボードが、開発組織の次の一手を照らした話― Cursor × SpecKit × 可視化の実践 ― Qiita AI Summit
noalisaai
1
370
Featured
See All Featured
Design in an AI World
tapps
0
140
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
630
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
440
My Coaching Mixtape
mlcsv
0
45
Imperfection Machines: The Place of Print at Facebook
scottboms
269
14k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Max Prin - Stacking Signals: How International SEO Comes Together (And Falls Apart)
techseoconnect
PRO
0
80
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.6k
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
910
Are puppies a ranking factor?
jonoalderson
1
2.7k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1k
Code Review Best Practice
trishagee
74
20k
Transcript
過去の叡智から学ぶ 効率的なアウトプット術 2023/11/18 廣瀬 亮輔 Rakuten Technology Conference 2023 in
札幌
本日のテーマ 過去の叡智から定説を知り、低リスクかつ高アウトプットな仕事の進め方を考える。 事前に避けられることは避けよう。車輪は流用しよう。 • 定説から学ぶ ◦ 時間管理におけるパレートの法則の応用 ◦ パーキンソンの法則 ◦
パーキンソンの凡俗法則 • 現実と照らし合わせてどう動くか
自己紹介 • 株式会社ブロードリーフ 先端技術開発室 基盤開発課 ◦ 主な業務 ▪ 共通ライブラリやフレームワーク開発 ▪
新規事業系サービス開発、運用 ▪ 部署横断的な技術支援 • 最近の関心 ◦ terraform ◦ K8s ◦ CI/CD ◦ etc 基本は開発レイヤーですが、インフラ構築、CI/CD整備、開発環境改善、 運用・トラブル対応など幅広く対応しています。 X(Twitter): @hi_rose39
定説から学ぶ
時間管理におけるパレートの法則の応用 「結果の8割が20%の要素により生み出される」という、 「パレートの法則」を時間管理に応用して言われているのがこちら。 80点の完成度に達するには2割の時間で済むが、 残り20点を高めるためには8割の時間がかかる。 多くの場合、仕事の中で求められるのは 100%完璧なものではなく、 最短時間で効率的に合格点 +αを取ること。 自分自身の中で100%の物を時間をかけて作ったとし
ても、提出後に指摘や問題が発覚するリスクは 0 には ならない。
パーキンソンの法則 イギリスの官僚制を観察した結果に基づいた研究が発端の「パーキンソンの法則」。 組織の働き方が、悪い意味で官僚的な状態に傾いている場合にも当てはまると考えられる。 第一法則「仕事の量は完成のために与えられた時間をすべて満たすまで膨張する」 第二法則「支出の額は収入の額に達するまで膨張する」 前ページの「パレートの法則」と関連して、 合格点が適切に定められていない と、 下記 各リソースをあればあるほど使い切ってしまう
可能 性がある。 • 工期 • 人的リソース • コストリソース ex)余裕を食いつぶして 完璧を目指してしまう
パーキンソンの凡俗法則 本来必要な複雑で理解が難しい重要課題ではなく、理解が簡単な些細な物事に 重点をおいてしまうという「パーキンソンの凡俗法則」。 「組織は些細な物事に対して不釣り合いなほど重点を置く」 パーキンソンが例として挙げているのが原子力発電所のプロジェクトの話。 原子力発電所開発の審議の場において、 • 最も重要と考えられる原子炉の建設契約に関しての話題では意見が少ない • しかし、その中に作る自転車置き場の議題では最も意見が活発に出て時間が費やされる
というもの。 システム開発においても、プロジェクト進行を中心に同様のことが起こりえる。
現実と照らし合わせてどう動くか
現実と照らし合わせてみる これまでの話は、ゴールとなる合格点に対してまっすぐに進められている場合には対策も考えやすい。 しかし現実の仕事では、新入社員にふられるタスクでもなければ、より複雑性が増すこととなる。 プロジェクトのような大きな単位でも、個人タスクでも 大なり小なりの計画がある。 • 大きなゴール(最終形) • 中間地点のマイルストーン これを、安全かつ短いルートで最短で進む
のが理想。 しかし、実際にはゴールと思ってたどり着いた先が真のゴールとは限らな い。 開始時点でゴールを 見誤っている場合もあれば、 時間経過で周囲の情勢が変わってゴールが変化する場合 もある。 システム開発の特性上、全く同じものを作る事がほぼ無いことや、 社会の変化スピードも上がっているため、 開始時点で確実な完成形や道筋を描くことは難しくなってきている。 真のゴールはこちらかもしれない・・・ 山頂は霞の先。 近づいていかないと詳 細はわからない。 現実はこの1マスをまっすぐ進 めるかも怪しい。
自分自身がどう動くか • まずは最短を目指す ◦ 成果物は基本的に利用されて初めて価値になる ▪ 早ければ早いほど利用されて価値が大きくなる可能性が高まる ▪ 早く終わった分だけ他の価値を生むことができる ◦
目的を本質的にとらえ、合格点を適切に設定する ▪ 注意点: 合格点はTPOで変わる&経験がないと適切な設定は難しい。 • 初学者の場合は、まずは指示や依頼を独自解釈せずに進める →基礎ができてから合格点設定や進め方をアレンジ • ゴールを見失わない ◦ 定期的に状況を俯瞰したり、アドバイスを受ける ▪ 2-5-8割の報連相 • どこまでできたら進捗何割かの共通認識を持つことが前提 • 方向性、ゴール、スケジュールを定期的に確認する 大きなプロジェクトの改善であれば対策の一例として、スクラムをはじめとするアジャイル手法で柔軟 性を高めたり、組織体制を見直す(例えば逆コンウェイの法則を利用してチーム間・サービス間の依存や 不確実性リスクを減らす等)といったことが考え得る。 しかし、それらは他者や環境に依存してしまう割合が高い。確実に変えられるのは自分自身の行動。
LTでの質疑を受けての補足 • 確実に変えられるのは自分自身の行動 ◦ スティーブン・R・コヴィー博士の「7つの習慣」の前半部分が参考になる。 依存から自立に至る「第1: 主体的である」~「第3: 最優先事項を優先する」の習慣 ◦ また、関連して「自責思考、他責思考」の考え方も有効
• 2-5-8割の報連相 ◦ 定める達成基準例として設計書作成タスクであれば以下のようなイメージ ▪ 2割: 全体的な方向性が把握できる目次+各項のアウトライン ▪ 8割: 自分自身としての出来上がりをレビューして指摘を受ける ▪ 10割: レビューの指摘対応を行いメンバーの合意を得て完成 ▪ 5割: 中間進捗として間の日で設けるが、小さなタスクの場合は省略