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
350
Kubernetes入門#3 About ConfigMap and Secret / Kubernetes Getting Started#3
hirose39
1
580
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
セキュアな認可付きリモートMCPサーバーをAWSマネージドサービスでつくろう! / Let's build an OAuth protected remote MCP server based on AWS managed services
kaminashi
3
310
ニッポンの人に知ってもらいたいGISスポット
sakaik
0
120
エンタメとAIのための3Dパラレルワールド構築(GPU UNITE 2025 特別講演)
pfn
PRO
0
250
社内お問い合わせBotの仕組みと学び
nish01
1
580
Modern_Data_Stack最新動向クイズ_買収_AI_激動の2025年_.pdf
sagara
0
240
能登半島地震で見えた災害対応の課題と組織変革の重要性
ditccsugii
0
660
いまからでも遅くない!SSL/TLS証明書超入門(It's not too late to start! SSL/TLS Certificates: The Absolute Beginner's Guide)
norimuraz
0
190
AI時代だからこそ考える、僕らが本当につくりたいスクラムチーム / A Scrum Team we really want to create in this AI era
takaking22
8
4.2k
職種別ミートアップで社内から盛り上げる アウトプット文化の醸成と関係強化/ #DevRelKaigi
nishiuma
2
160
リセラー企業のテクサポ担当が考える、生成 AI 時代のトラブルシュート 2025
kazzpapa3
1
160
スタートアップにおけるこれからの「データ整備」
shomaekawa
2
410
ComposeではないコードをCompose化する case ビズリーチ / DroidKaigi 2025 koyasai
visional_engineering_and_design
0
110
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
900
Facilitating Awesome Meetings
lara
56
6.6k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.7k
Statistics for Hackers
jakevdp
799
220k
Mobile First: as difficult as doing things right
swwweet
224
10k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Keith and Marios Guide to Fast Websites
keithpitt
411
23k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
970
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
The World Runs on Bad Software
bkeepers
PRO
72
11k
Git: the NoSQL Database
bkeepers
PRO
431
66k
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割: 中間進捗として間の日で設けるが、小さなタスクの場合は省略