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
340
Kubernetes入門#4 About Kubernetes Uses With GKE & EKS
hirose39
1
340
Kubernetes入門#3 About ConfigMap and Secret / Kubernetes Getting Started#3
hirose39
1
570
Kubernetes入門#2 CronJob / Kubernetes Getting Started#2 CronJob
hirose39
1
550
Kubernetes入門#1 運用例の紹介 / Kubernetes Getting Started#1 Case Introduction for k8ssa
hirose39
0
270
Other Decks in Technology
See All in Technology
エンジニア採用から始まる技術広報と組織づくり/202506lt
nishiuma
8
1.7k
「実体」で築く共通認識: 開発現場のコミュニケーション最適化 / Let's Get on the Same Page with Concrete Artifacts: Optimization of Communication in dev teams
kazizi55
0
140
“プロダクトを好きになれるか“も QAエンジニア転職の大事な判断基準だと思ったの
tomodakengo
0
140
RubyOnRailsOnDevin+α / DevinMeetupJapan#2
ginkouno
0
440
ObsidianをMCP連携させてみる
ttnyt8701
2
120
Whats_new_in_Podman_and_CRI-O_2025-06
orimanabu
3
180
TerraformをSaaSで使うとAzureの運用がこんなに楽ちん!HCP Terraformって何?
mnakabayashi
0
130
Workflows から Agents へ ~ 生成 AI アプリの成長過程とアプローチ~
belongadmin
3
160
Devin(Deep) Wiki/Searchの活用で変わる開発の世界観/devin-wiki-search-impact
tomoki10
0
320
SFTPコンテナからファイルをダウンロードする
dip
0
300
DB 醬,嗨!哪泥嘎斯基?
line_developers_tw
PRO
0
200
本部長の代わりに提案書レビュー! KDDI営業が毎日使うAIエージェント「A-BOSS」開発秘話
minorun365
PRO
14
1.8k
Featured
See All Featured
Statistics for Hackers
jakevdp
799
220k
The Language of Interfaces
destraynor
158
25k
Facilitating Awesome Meetings
lara
54
6.4k
Building Adaptive Systems
keathley
43
2.6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
A Tale of Four Properties
chriscoyier
159
23k
Writing Fast Ruby
sferik
628
61k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.6k
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割: 中間進捗として間の日で設けるが、小さなタスクの場合は省略