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
90
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
260
Kubernetes入門#4 About Kubernetes Uses With GKE & EKS
hirose39
1
270
Kubernetes入門#3 About ConfigMap and Secret / Kubernetes Getting Started#3
hirose39
1
420
Kubernetes入門#2 CronJob / Kubernetes Getting Started#2 CronJob
hirose39
1
420
Kubernetes入門#1 運用例の紹介 / Kubernetes Getting Started#1 Case Introduction for k8ssa
hirose39
0
240
Other Decks in Technology
See All in Technology
どうするコスト最適化のトレードオフ
tetsuyaooooo
1
710
IaCジェネレーターとBedrockで詳細設計書を生成してみた
tsukasa_ishimaru
4
880
On Your Data を超えていく!
hirotomotaguchi
2
750
KubeConにproposalを送りたい人へのアドバイス
sat
PRO
3
270
Grafana x PagerDuty Better Together
jacopen
1
250
LangSmith入門―トレース/評価/プロンプト管理などを担うLLMアプリ開発プラットフォーム
os1ma
5
700
コードや知識を組み込む / Incorporate Code and knowledge
ks91
PRO
0
140
R3のコードから見る実践LINQ実装最適化・コンカレントプログラミング実例
neuecc
3
2.2k
FrontDoorとWebAppsを組み合わせた際のリダイレクト処理の注意点
kenichirokimura
1
720
いつか使うかも貯金してたらめちゃめちゃ機能が増えてた話
riyaamemiya
0
610
Azure犬駆動開発の記録/GlobalAzureFukuoka2024_20240420
nina01
1
240
TechFeed Experts Night#27 〜 フロントエンドフレームワーク最前線 (Svelte)
baseballyama
2
590
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
290
19k
RailsConf 2023
tenderlove
8
550
Build your cross-platform service in a week with App Engine
jlugia
226
17k
Git: the NoSQL Database
bkeepers
PRO
423
63k
Fashionably flexible responsive web design (full day workshop)
malarkey
398
65k
Building Effective Engineering Teams - LeadDev
addyosmani
32
1.9k
Debugging Ruby Performance
tmm1
70
11k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
34
8.9k
Designing with Data
zakiwarfel
96
4.8k
Atom: Resistance is Futile
akmur
260
25k
jQuery: Nuts, Bolts and Bling
dougneiner
59
7.2k
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割: 中間進捗として間の日で設けるが、小さなタスクの場合は省略