Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
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
350
Kubernetes入門#3 About ConfigMap and Secret / Kubernetes Getting Started#3
hirose39
1
590
Kubernetes入門#2 CronJob / Kubernetes Getting Started#2 CronJob
hirose39
1
560
Kubernetes入門#1 運用例の紹介 / Kubernetes Getting Started#1 Case Introduction for k8ssa
hirose39
0
280
Other Decks in Technology
See All in Technology
なぜフロントエンド技術を追うのか?なぜカンファレンスに参加するのか?
sakito
8
1.9k
Modern Data Stack大好きマンが語るSnowflakeの魅力
sagara
0
260
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
37k
タグ付きユニオン型を便利に使うテクニックとその注意点
uhyo
2
430
DGX SparkでローカルLLMをLangChainで動かした話
ruzia
1
240
Docker, Infraestructuras seguras y Hardening
josejuansanchez
0
140
Digitization部 紹介資料
sansan33
PRO
1
6.1k
事業部のプロジェクト進行と開発チームの改善の “時間軸" のすり合わせ
konifar
9
2.7k
21st ACRi Webinar - AMD Presentation Slide (Nao Sumikawa)
nao_sumikawa
0
140
命名から始めるSpec Driven
kuruwic
3
810
なぜ使われないのか?──定量×定性で見極める本当のボトルネック
kakehashi
PRO
1
290
原理から解き明かす AIと人間の成長 - Progate BAR
teba_eleven
2
290
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.8k
jQuery: Nuts, Bolts and Bling
dougneiner
65
8k
Stop Working from a Prison Cell
hatefulcrawdad
273
21k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.8k
Why Our Code Smells
bkeepers
PRO
340
57k
Agile that works and the tools we love
rasmusluckow
331
21k
The Language of Interfaces
destraynor
162
25k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.2k
Six Lessons from altMBA
skipperchong
29
4.1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.6k
The Pragmatic Product Professional
lauravandoore
37
7k
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割: 中間進捗として間の日で設けるが、小さなタスクの場合は省略