- 多くの要素が開発者の生産性に影響する
- 一部は明確で測定しやすいが、他は測定が難しく、見落とされがちである
何を作るべきかを知ること (Knowing what to build)
- 間違ったものを素早く作ることは、まったく生産的ではない
- 顧客が何を求めているかを知り、
- 他のチームが受け入れ可能なものは何かを知り（DBテーブルにはいくつインデックスを置けるのか、法的に許可されていない情報を共有できるのか？）、
- 以前に試したが効果がなかったものが何かを知る必要がある
より少ない仕事をする
- 仕事を早く終えるのは良いことだが、そもそも「やらなくていい」のであれば、その方がもっと良い
- 会社のプロセスは、生産性を下げる「忙しいだけの仕事」を追加してしまうことがある
- ときには、はるかに少ない作業で同じ価値を提供できるよう、プロセスを簡単に調整する方法がある
- 「明かりをつけ続ける (Keep the lights on, KTLO)」ために、ある程度の努力が必要な場合がある
- これは継続的に行う必要があるが（例: サポートチケットへの返信）、プロジェクトを前進させる仕事ではない
- こうした業務は、さまざまな指標（完了チケット数、マージされたコミット数）では生産的に見えるかもしれないが、会社をより良い場所へ導くわけではない
応答の速いツール
- 開発者はエディタ、git、ビルドシステムなどのツールを継続的に使っている
- これらのツールが追加する時間は、使われる頻度を考えるとかなり大きなコストになる
- それは時間単価の問題だけでなく、開発者の集中も妨げる
開発者の頭の中にある知識
- これは測定が難しい
- 他の条件がすべて同じなら、関連知識の多い開発者の方がより生産的である
- コードがどう動くかを知っているため、深く読み込む必要がなく、
- ツールの使い方や避けるべき落とし穴を知っており
- 正しい質問ができる
- 10x開発者は存在し、それは「コードベースをよく知っている人たち」である
- これは、1つのチームが頭の中に集合的に保持できる量を超えるものを所有すべきではない、ということでもある（バスナンバーは1より大きいのが理想的: Bus Factor 理論）
- また、所有権が変わる頻度を最小限にする方が有利であることも意味する
- それを作った本人以上によく知っている人はいない
- 理想的には、そのシステムを初めて扱う人は、すでにそのシステムに慣れている人と一緒に作業しながら学ぶのがよい
- システム間には明確な境界が必要である
- 単純なセマンティクスを持つクリーンなインターフェースは、その背後にあるシステム全体を知らなくても、インターフェースの性質について考えられることを意味する
- ドキュメントは知識を伝える良い方法である
- 特に、開発者が慣れていない特定の作業を行わなければならない場合に重要である
- ドキュメントが不足していると、開発者は作業方法を自分で調べなければならず、ミスをしてやり直したり、他チームが質問に答えるまで待ったりするため、作業が遅くなることがある
- その結果、1時間の作業があっという間に2日がかりの作業になりうる
- 100人の開発者がこれを行う必要があるなら、1ページのドキュメント不足によるコストは、開発者1人分の年収に相当しうる
- これは、専門化 (Specialization) を進めるべきだということでもある
- すべての開発者に幅広い作業を求めるのは非生産的である
- ある種のセキュリティシステムやキャパシティプランニングを書くプロセスに費やす1時間は、問題解決のためにドメインを理解するのに費やす1時間とは異なる
役に立つインフラ
- インフラは障害物ではなく、助けになるものであるべきだ
- 行う必要のあるすべての作業と、合理的に近い形で整合しているべきである
- インフラの各部分は特定のユースケースを念頭に設計されているが、プロジェクトでは時々そのユースケースから外れることがある
- そんなときに「うちのインフラしか使ってはいけません」や「うちのインフラではそれはできません」と言われると、非常にもどかしい
- そうなると、インフラを回避して仕事をするか、要件をインフラのオーナーに納得してもらう会議に参加して時間を無駄にすることになる
少ない技術的負債
- 既存のコードは、あなたがやろうとしている作業に常に完全に適しているわけではない
- 元のコードを書いた人は、あなたがどんな変更をするか見通せる「水晶玉」を持っていたわけではない
- しかし、あるコードは他のコードよりもはるかに変更しやすい
- 「どうすれば X ができますか？」への答えが「これを全部再設計しなければなりません」であってはならない
- 技術的負債が多ければ、機能を少し変えるだけでも、システムをもっと大きく変更しなければならなくなる
- 技術的負債を減らせば、(a) 理解すべき範囲と (b) 変更すべき影響範囲を最小化できる
- 技術的負債を返済するためのプロジェクトは、完了させなければならない
- 途中で諦めたり優先順位を下げたりすると、システムが最初より悪くなる可能性がある
低い失敗率
- ツール実行の失敗、ビルド失敗、デプロイ失敗、あるいは本番障害によるリグレッションが起きるなら、それは時間の無駄である
- こうした失敗の確率を下げれば、生産性は向上する
- 失敗を経験したエンジニアだけでなく、失敗したシステムを所有するチームの時間も浪費しがちである（原因を一緒に分析し、修正しなければならないため）
生産的な実践は実用的である (Productive practices are practical)
- 特定の問題の解き方を学ぶ最良の方法は、プロトタイプを書くことである
- もし環境がプロトタイピングを妨げるなら、最も生産的なアプローチでさえ妨げられうる
- モニタリングツールを使うのが難しければ、開発者はダッシュボードを作る数を減らし、測定も減り、意思決定はよりデータ駆動でなくなる
- 逆に、大きな変更をより小さなコードレビューに分割すれば、コードはよりレビューしやすく、デプロイしやすくなる
エンジニアがどれだけ集中できるか
- エンジニアは作業スケジュールに沿って働き、集中できる必要がある
- そのフォーカスは、会議や割り込みによって奪われうる
- 割り込みには、遅い CLI コマンド、遅いテスト、やり方がわからず調査しなければならない作業も含まれる
- 1週間のうちに多すぎることを考えるのも、集中力を損なう
- 迫る締切や、マネージャーからまだ回答を得られていない質問は、他のことに集中しようとするときでも精神的な RAM を占有する
作業を終わらせること
- 50%作ることは、50%の生産性ではなく、0%の生産性である
- 捨てられる仕事ほど非生産的なものはない
- 途中でプロジェクトを諦めるのが正しい判断である場合もある
- サンクコストの誤謬と戦うことは、ときに正しい
- しかし、プロジェクトが完了する前に優先順位を変えるという一貫したパターンがあってはならない
- そうなると、チームの生産性は 0 にまで落ちうる
まとめ
- このような多様な要素を測るために、常にダッシュボードを構築できるわけではないが、上のようなことが生産性にどう影響するかは理解できる
- こうした問題を解決すれば、こなせる仕事の量は大きく増える可能性がある
- 問題の中には、驚くほど簡単に直せるものもある
- ドキュメントを書くのに数時間かければ、会社は数千時間を節約できるかもしれない
- 木を早く切りたいなら、まずのこぎりの刃を研ぐことから始めよう
7件のコメント
締めの部分が多い文章ですね
「ドキュメントが不足していると、開発者は作業の進め方を自分で調べなければならず、ミスをしたり、作業をやり直したり、別のチームが質問に答えるまで待ったりすることになるため、作業のスピードが落ちる可能性がある」
開発ドキュメントではありませんが、社内のオンボーディング資料について、オンボーディングを受けた人に1週間後に更新してもらうよう依頼すると、資料の質が良くなるんですよね。入社して何の情報もないときに何が必要かは、その時点ではその人たちがいちばんよく分かっているので。
GitHubにあるオープンソースプロジェクトの
Readme.mdが比較的どれもよく書かれているものが多いのも、多くの最初の利用者が来てフィードバックをくれるからではないかと思ったりもします。最近、仕事が多すぎて本当にてんてこ舞い TT
インフラは障害物ではなく助けになるべきです --> でも現在の韓国企業では、セキュリティを言い訳にしてまったくそうなっていませんね。
お気持ちは理解しますが、この文章は英語で書かれていますね。英語圏の企業でも状況は似ているようです。
要約というより翻訳レベルのようですね……詳しいまとめありがとうございます。