「2023 にレベルアップする方法」というスレッドをGithub公式が上げていたので、内容を薄く拾ってみます。
- 時間管理の方法
- いたずらに時間を消費せず、アウトプットにつなげる方法
- アジャイルな（意訳）計画方法
なお、DeepLでの逐語訳や、それを元にさらにchatGPTで機械要約することも可能な2023です。
翻訳をしたいわけでもないので、
多分に意訳が含まれており、恣意的にかいつまんでいることをご了承ください。
時間のある方はぜひ元記事にあたってください。長くないです。もし誤訳があったら教えてください。
時間管理
Time management for makers · GitHub
エンジニアが何かを作るためには、妨げ（差し込み）のない、長いまとまった時間が必要なことを大体のマネージャーは認識しています。
しかし、残念ながら差し込みは止みません。
たとえどんなに優れたマネージャーでも、差し込みが一切発生しないようにするのは不可能です。
そもそも差し込みが発生する背景には以下があります。
- エンジニアが作ったシステムを自分たちで保守することに多くの利点があり、問題が発生すれば修正することが求められる。
- 組織はトップダウンではなく、現場のデータに基づいて判断するようになり、現場に意見が求められる
- 避けられないミーティングは存在し、（グローバル企業の場合）地理的な要因で全員のフォーカスタイムを考慮した時間を設定できない
これらの傾向が強まると、エンジニアのカレンダーにはミーティングが増え、さながらマネージャーのようになっていきます。これが罠です。
エンジニアはそもそも作り手であり、作ることを期待されています。マネージャーのようなスケジュールを受け入れてしまう罠にはまると、どちらかの運命が待っています
- 時間外労働
- "マネージャー"になる
この罠を避ける簡単な方法は、責任を負わないようにすることです。
しかし、そうすると今度はキャリアが息詰まります。
ではマネージャーのスケジュールを避けつつ、かつ責任とインパクトを大きくしていくにはどうすればよいでしょうか。
成功したエンジニアには以下に共通する特徴があります。
- 時間を確保する
- Pay Yourself First (まず自分に払おう)
- 人の時間を守る
- 差し込みの仕事を明確にして割り当てる
- 投資対効果の悪いタスクを明確にして処理する
ひとつずつ見ていきます。
時間を確保する
フォーカスタイム（連続する時間）を最大化するため、不要なタスクは消すか、バッチ処理します
具体的には、
- slackやメールの処理をする時間を決めておく
- 不可避のミーティングはまとめる（ミーティングを連続させる）
などです
Pay Yourself First (まず自分に払おう)
フォーカスタイムは予めスケジュールに入れておきます。
他の予定が入らないようにします。
それと同時に、それらの時間をどう使うか（プログラミング、ミーティングの準備、など）を長期的視点から予め決めておきます。
プロジェクトごとにどれだけの時間が必要かを考えておかないと、時間が足りなくなってしまいます。
人の時間を守る
時間管理のGolden Ruleです。
自分の時間を侵害されないためには、まず人のフォーカスタイムを侵害しないようにします。
もし本当にしょうがなく、予定を被せるときは最低でも一言聞くとよいです。
差し込みの仕事を明確にして割り当てる
エンジニアにはどうしても差し込みドリブンの仕事があります。これら差し込みにさらされる時間は当番制にしましょう。
これは非常に重要ですが、意外とドキュメント化されていないプラクティスです。
エンジニアは仕事の20%以上を差し込みにさらされてはいけません。つまり、健全な当番制には最低5人のエンジニアが必要になります。
投資対効果の悪いタスクを明確にして処理する
やる必要があるが、費用対効果の悪いタスクがあります。
これらは、相対的に質を犠牲にしても、決めた時間内に処理するようにします。
率直にコミュニケーションする
率直なコミュニケーションの利点は豊富にあります。時間管理の改善もその一つです。
率直なコミュニケーションは他人の時間を無駄にしにくく、"No" と言える力も身につきます。
非情に優先順位付けする
最も重要ですが、難しいでしょう。
ただ、これまでに挙げた点を踏まえれば少しは実践しやすくなるはずです。
元記事（再掲）：
Time management for makers · GitHub
意図的に生産する（アウトプット）
我々には皆、価値あるアウトプットを生み出す可能性があります。
しかし、消費するコンテンツを絶え間なく与えられる現代において、この可能性を実際のアウトプットへとつなげるのは難しいです。
そこで、アウトプットを生み出す4 step を紹介します
- 消費する
- 批評する
- 集積する
- 生産する
1: 受動的な消費を能動的な調査に変える
朝目を覚ました瞬間から、我々は常に情報の波にさらされています。
記事、動画、podcast、最新の Wordle...。
我々は消費に囲まれていますが、消費で終わってしまう状態は危険です。
消費の無限ループは創造の機会を奪ってしまいます。
とはいえ、消費が全て悪いわけではありません。
むしろ、創造は、調査のための消費や、批評を意図した消費から始まります。
2: 自分の反応を批評に変え、反応できる以上の消費をしない
意識的な創造は、目新しい入力に対して、少し立ち止まることから始まります。
難しいかもしれませんが、feed の次に思いをはせる前に、批判的感覚を働かせてみてください。
なんらかの結論を引き出してみてください。仮に吟味されたものでなくても、それはあなたのものです。
もし批評することができなければ、それは、省みることができないくらい早く消費をしていることのサインです。
省みなければ、何も学べません。
もしこういった消費をしているなら、１つ１つの消費に深く潜ってみるか、少し休憩する必要があります。
どんな形であれ、批評は難しいです。
新しい消費を行う前に、まずはエディターを開いてみてください。
今この瞬間に開いてもOKです。
3: 批評をまとめ、生産の参考になる形にまとめる
批評は、価値あるアウトプットのプロトタイプです。
批評をそのままにせず、まとめた形にしておくことは大事です。
まとめただけでも価値が生まれたりします（リンク集など）。
4: Create
まとめがある程度のサイズになると、面白い発見があります。
まとめた中にパターンやギャップが見つかり、それに沿って価値あるアウトプットできるのです。
そこからOSSが始まったりするのです。
元記事（再掲）：
https://github.com/readme/guides/intentional-creation
Using ‘Roofshots’ to make impossible decisions · GitHub
（注：原文が一人称の語り調なので、それに沿います）
これまで、良い計画をすることでcodingは順調に進み、成功すると信じてきた。
しかし、大企業のスタッフエンジニアになって大規模なプロジェクトに携わると、これまでにうまくいった方法がうまくいかないことに気づいた。
事前に入念に要件定義やデザインをしても、それはその後も正しくあることができず、
決定をやり直すのは難しくなり、結果的に多くのエンジニアの時間を無駄にしてしまうようになった。
その原因を振り返ってみると、あいまいさが支配的な中で、事前の確かな想定に頼ることなどできないことに気づいた。
例えばプロジェクトの期間が長いと、あいまいさの要因は増える
すると、まず間違いなく優先度の上下は変わる。
間違った判断はよりやり直しがきかなくなる。
そこで、「変化を前提として、どう上手く軌道を変えるか」を考えるようにした。
リーンの方法論を参考にして、より早く市場に出して反応を見て、方向修正、のサイクルを繰り返すようにすると、うまくいくようになった。
計画段階で誤った判断を恐れて分析しすぎてしまうのはよくない。
とはいえ計画をしないわけにはいかない。
計画段階では以下をやれば十分だ。
- 課題と制約と想定と目的を言語化する
- オーナーを指名する
- 最も価値のある意思決定にまずは注力して、方向を定める
その後は、少しづつ実行するようにする。
ここで、どんなことをしても賭けであり、リスクがあると考えるようにしてみる。
すると、問題は「どれだけのリスクをとるか」になる。
小さいリスクを選ぼう。
そうすることで、自然とやることはシンプルで、本質的で、具体的なものになる。
また、やることが小さくなると、早く市場に出すことができ、その分だけ早くフィードバックを得られる。
賭けの結果を未来の計画へのフィードバックにする。
小さな賭けを繰り返すことで、全体の計画のずれを小さくすることを目指す。
特定の銘柄に投資するのではなく、市場全体に投資するイメージだ。
この戦略の良い点は、自分が達成できると思うよりも大きいことに挑戦できるようになることだ。
技術界隈では、大きなプロジェクトをムーンショットと呼ぶことが多いが、歴史的には月面着陸は複数の計画の末に実現されたものである。
それを聞くと、不可能な目標も、長く、地道に取り組むことで達成可能だと勇気づけられるはずだ。
これにはルーフショットという名前もついている。
ここまでの話をまとめると、以下のような段階を踏めばよい。
- 大きく、複雑だが解決したい課題を見つける。
- 次に進むために積み重ねる道が見つかるまで課題を吟味する。
- それらの方法を試す。ただし、短く実行する。結果を見て、修正する。
- 繰り返す！
元記事（再掲）：
Using ‘Roofshots’ to make impossible decisions · GitHub
ほかにもたくさんある Best Practice
Github のREADME Project には、参考になる話がかいてあります。見てみてください。
Guides · The ReadME Project · GitHub
あとがき
翻訳のために自分の中で反芻したりするうちに、自分の考えを反映してしまったものになった感もあります。
あとかなり端折りました。
正直もっと技術的な話を期待してスレッドを呼んだのですが、こういうソフトビジネススキルみたいなのも定期的に読んでいかないと経験則に頼るようになっちゃうと思うので、大事ですね。
