私が知る最悪のプログラマー
(dannorth.net)- ある Big Bank のコンサルティングチームは、個人の生産性を完了したストーリー／ストーリーポイントで測ろうとし、Tim Mackinnon はその指標で繰り返し 0 点を取っていた
- 0 点だった理由は仕事をしていなかったからではなく、自分の名前でストーリーを持たず、1日の大半をペアプログラミングに費やしていたためだった
- 経験の浅い開発者には直接答えを与えるのではなく、ソクラテス式の質問で学びを生み出し、シニアとは互いに異なる視点から、より良い解決策を一緒に見つけていた
- チームは Tim が一緒にいると、より効果的で生産的、かつ足並みのそろったやり方で働き、マネージャーは最終的に Tim を残したまま、個人の生産性指標をひっそりと廃止した
- 個人の貢献を切り離して測る方法では、Tim のような貢献を 0 にしてしまう可能性があるため、生産性はビジネスへの影響とチーム単位のフローで見るべきである
個人指標が生んだ「0点プログラマー」
- Big Bank のあるチームは、個人の業績評価と育成を目的として個人別の成果指標を導入した
- マネージャーはコード行数やバグ数のように簡単に操作され得る指標を避け、ビジネス価値を代表するものとして、完了したストーリーまたはストーリーポイントを測定対象にした
- Jira に似たツールで各人がストーリーに名前を載せていたため、個人別の生産性指標を作るのは容易だった
- Tim Mackinnon のスコアは低いどころではなく、毎週、毎イテレーションで文字どおり 0 点だった
- マネージャーは Tim をチームから外し、ストーリーを実際に「デリバリーする」人に置き換えるべきだと考えたが、チームリードはそれを拒んだ
Tim が実際に届けていたもの
- Tim は自分の名前でストーリーを担当せず、代わりに毎日別のチームメンバーとペアリングして働いていた
- 経験の浅い開発者と働くときは、その人自身にドライバーを任せ、解決策へ向かうよう穏やかに導いた
- 答えを押し付けたり、強引に進めたりしない
- “what if”、“how else” のような質問や Socratic questions で学びの瞬間を作る
- シニア開発者とは、共同創作やスパーリングに近い形で働き、互いに異なる世界観を問題に適用して、一人では思いつきにくい結果を生み出した
- Tim はソフトウェアを直接届けるのではなく、ソフトウェアを届けるチームを育てていた
- チーム全体がより効果的かつ生産的に動く
- より足並みがそろい、より寛容なやり方で働く
- 一緒に働く経験もより楽しくなる
- マネージャーがチームを観察しに来たとき、Tim はいつも誰かと一緒に「その人の仕事」をしており、その成果物は品質が高まり、価値を届けるまでの時間も短くなっていた
- 最終的にチームは Tim を残し、個人の生産性指標ではなくチームの責任性を選んだ
- 高パフォーマンスの単位として、組織に届けたビジネス上の影響を追跡し、称賛した
生産性はどこを見るべきか
- 生産性の測定そのものは必要であり、責任性を持つためには測定可能なビジネスへの影響が理想的である
- 削減した金額
- 生み出した金額
- 守った金額
- 直接的なビジネスへの影響の測定が難しければ、代理となるビジネス指標も使える
- 複雑な適応システムでは、個人一人の貢献を切り離して測定しようとする前提から揺らぐ
- DORA 指標は個々のピストンの貢献ではなく、作業システムの動作の仕方を測定する
- Westrum の文化指標として見ることもできる
- 技術的な変更がプロダクションへ流れていく様子を見る指標としても捉えられる
- 個人指標は Tim のような人の実際の貢献を 0 にしてしまう可能性があり、チーム単位の成果とシステムレベルのフローを見る方法のほうが適している
1件のコメント
Hacker News の意見
20年ほど前、Mac と Windows 向けのデスクトップアプリを販売していた中堅ソフトウェア会社で働いていた。チームの大半は Mac の経験しかなく、Windows は学び始めたばかりだったので、Windows 版には問題が多かった。
当時の私は Windows の専門家として知られていたため、そのバージョンを改善し、チームが Windows プログラミングに慣れるのを助ける目的で採用された。
一日の前半は主に「往診」のように他の開発者の部屋を回り、ペアプログラミング、バグ調査、Windows API のベストプラクティスについての議論をしていた。後に同僚から「どうしてそんなに時間に余裕を持てるのか」と聞かれた。
数か月後の評価で「生産性は期待ほどではなく、とくにチームの他のメンバーの生産性が最近上がっていることを考えるとそうだ」と評された。私はそれこそが自分を採用した理由だと思っていた。
知識共有は他の開発者に与えられる最大の利益なのに、その道を選ぶ人たちはあまりにも報われていない。
こういう開発者がいなければ、今のソフトウェアの世界に近づくことすらできなかったはずだし、直接感謝されなくても確かに価値がある。
すべての修理作業の優先度は同じだったが難易度は異なり、1か月かけて学ぶ必要があって誰も手を出さない 基地局の修理を引き受けたところ、時間は余計にかかったが運用上ははるかに重要だった。
月末の会議で稼働率の円グラフが出され、私は熟練した先輩たちよりずっと悪く見えた。
そのとき、先輩たちが速くて簡単な仕事だけを選んで取る理由と、社内政治の存在を学んだ。ひどい上司をキャリアの初期に経験できたのは、むしろ幸運だった。
新しい上司は最初の評価で本来 業績改善計画を書いていたが、オープンオフィスに移ってから、助けを求めて私のところに列を作る人たちと、誰も追い返さない私の姿を見て、それを捨てたと認めた。
仕切りのある席を失ったのは少し腹立たしかったが、その出来事のおかげでオープンオフィスを前向きに見るようになった。
もちろん今ではどのオフィスでも働いておらず、在宅でない仕事は二度と受けないつもりだ。
評判が先に作られてからでないと、何かを変えることはできず、その前は難しい。
あまりにも多くの人が「チーム」のために最適化した結果、上層部の否定的な認識によって解雇されたり昇進で不利になったりしている。一方で、会社が現在重視している基準で良い評判を得た人は、かなり長い間 悪い行動も容認されがちだ。
すぐにもっと良い場所へ移ったのか、会社の成果指標に合わせて時間をあまり分け与えないようにし始めたのか、それとも組織図上で十分に上の人に、実際にそういう役割で採用されたのだと説得したのか、知りたい。
Bell Labs の逸話を思い出す。
ある人が特許数のような基準で最も生産的な社員を算出したところ、その多くが同じ人物と昼食を取っていることに気づいた。
その人物自身の個人生産性は高くなかったが、常に深く説得力のある質問を投げかけ、同僚たちを測定可能な形でより生産的にしていた。
Bell Labs の特許部門の弁護士たちは、なぜある人がより生産的なのかを説明する組織原理を見つけようとしたが、共通点は、特許の多い社員たちが電気工学者 Harry Nyquist と昼食や朝食をよく共にしていたことだけだった。
Nyquist が具体的なアイデアを与えたわけではなく、人々を引き出して考えさせ、何より 良い質問を投げかけていた。
人の集団は繊細な構造なので、良いチームの雰囲気や良い質問は、目に見えない形で状況を改善しうる。
そうでないと公正な賃金を得るのは難しい。
私はそうは思わない。
数年間勤めた会社では、週に10ポイントを作れないとパフォーマンス改善の対象になり、ジュニアかシニアかは関係なかった
いくつものチームを経験したが、そのチームがポイントをどう測っているかは、開発者たちのストレスレベルを見るだけですぐ分かった
善意でポイントを測ろうとしていたチームはストレスを抱え、ほとんどがバーンアウトの兆候があり、週60時間働いていた
逆に、システムをゲームのように扱い、それが不可能な課題だと理解していたチームは、チケットにできるだけ高いポイントを付けたり、小さなチケットに分割して点数を積み上げ続けたりして、ストレスなく幸せだった
そういう環境でルールどおりにやるのはカモ戦略で、私が結局辞めると、その会社のシニアエンジニア7人が4か月以内に全員後を追うように辞めた
大きな不確実性やリスクのあるストーリーよりも、継続的にストレスなく達成できるストーリーへ分けることが目標だからだ
その職場が良さそうだという意味ではないが、システムをゲームしたと見ていた開発者たちは、概ねスクラムが促そうとしているやり方どおりに動いたように見える
ただし、週あたりの最低ポイントを強制してポイントの水増しを誘導するのはひどいマネジメントだ
圧力をかけなかった場合よりも、同じ人たちからより多くの仕事を引き出せたからだ
昔の上司は、プロジェクトを終わらせるために「人を雇って燃やし尽くす」と露骨に言い、6か月だけ役に立つように働けばいいという計画だった
ストレスと低い報酬に耐えて残ってくれるなら、会社にとってはおまけのようなもの、という考え方で、私も長くは持たなかった
その週に終わらせられなかったらチケットは完了扱いにして、残りの作業はバグとして新しく開く、というやり方だった
「測定値が目標になる瞬間、その測定値は良い測定値ではなくなる」
あるところでは、目標に向けた純粋な生産性よりも、マネージャーが何を期待できるかを知っていることの方が重要だった
善意で見積もった人たちは、経営陣も善意で行動していると思っていたのかもしれないが、多くのプロジェクトは願望ベースで作られたり、人々を「動機づける」ために人為的に短い締め切りを置いたりする
そのストレスは、マネージャーの感情的な満足以外にはほとんど価値を生まなかったのかもしれない
ソフトウェアエンジニアの成果を非技術者が評価すると、劇的な結果になることがある
友人の「Tommy」はネットワークに非常に強いIT担当者で、政府所有のエネルギー会社に移って数週間で、本社の全建物まで含めてネットワークを現代的な機器で全面的に再構築しなければならなくなった
会社は外部業者に任せようとしていたが、財務部門が見積もった費用を見てTommyは驚き、ルーター、スイッチ、ケーブルのような物理機器と配線担当者2人だけいれば自分でできると言った
彼は数週間で初期予算の10分の1にも満たない費用で仕事を終えたが、受け取ったのは上司からの口頭での「ありがとう、よくやった」だけだった
上司たちが旧式で本当の価値を理解できない時代のIT技術者というのは、実に苦いものだ
後でTommyが契約者として入って追加報酬を受け取れたはずだ
一緒に働いた本当に優秀な開発者は、素晴らしいコードも書いたし、今すぐ作り直すべきひどいコードも書いたが、そのどちらも一緒に働きやすくする要素だった
良いコードの価値は説明するまでもなく、今でも彼のコードを使っている可能性がある
だが彼は緊急事態でも卓越していた
顧客が完全に止まっていて、こちらのせいかもしれない状況で、すぐに現れて問題を素早く把握し、顧客を再び動かすための汚いスパゲッティコードを素早く書いてインストールした
チェックインもリファクタリングもできない、目に痛いコードだったが、誰かが後でちゃんと直すまでの間、当面の危機は避けられた
私はむしろ後者の能力により感心した。何より珍しいスキルだったし、彼はただの良い人で、皆に好かれていた
それでも仕事を素早く終わらせるし、私の風変わりなコードが緊急事態を解決したり入札を勝ち取ったりして、何度も窮地を救ってきた
「完璧志向」の開発者たちとはコミュニケーションが難しく、彼らにとっては、コードが十分に設計されていなければ、速度が必要だという点を理解していても価値がないように見える
もちろん彼らも私について逆のことを考えているだろう
今は毎週ミーティングを設けて問題を和らげており、かなりうまく機能している
一番難しいのは、緊急事態ではないがスケジュールが厳しく仕様が不明確なときに、どのタイプのアプローチが合っているかを決めることで、少なくとも共同で決めるようにはなっている
自力で学べないわけではないが、よくある問題と解法を機械的にタイプできるほど暗記するやり方は、私には本当に苦痛だ
会社を所有していない限り、常に外から見える価値で評価される
雇用主が視覚的にあなたの価値を見られなければ、そこで生き残れる可能性は低い
完全な能力主義の成果システムが理想ではあるが、雇用や評価を他人が握っているなら、成功は100%その人があなたをどう見るかにかかっている
その認識は、会社にとって実際に価値があるかどうかに関係なく、外から見える姿から生まれる
ここで言っているのはプログラミング能力や実際の価値ではなく、雇用と評価のことであり、生産性が高く、なおかつ評判管理もうまい人も多い
個人的には、チームのシニアには本当に難しい仕事を実際にやり遂げてほしい
ジュニアが仕事を進められるよう助けるのもよいが、知識・経験・対人スキルが不足しているジュニアにはできない、難しく複雑な仕事には、やはり熟練者が必要
どんなペアプログラミングも、それを完全に代替することはできない
価値の低い機能は非常によく実装された一方で、最も経験豊富な人たちが経験の浅い人たちに単体テストの書き方などを手伝っているせいで、インパクトが大きく優先度の高い作業が終わらない、という状況は避けるべき
ジュニアが担当したからといって、それが基本的に簡単な問題だという意味ではない。そうでなければ、どうやってエンジニアを成長させられるというのか
すべてのシニアがジュニアのメンタリングと協業に時間を使うべきではないが、チームにこういう人が数人いれば、力を倍増させる役割を果たし、チーム全体の利益になる
採用時には分からなかったとしても、彼が有用なニッチな役割を見つけたのなら、会社はそれを正式な役割に変えるべきだった
彼はコーチであり、そういう役割として採用したのなら問題ないが、おそらくコーチが欲しかったなら別に雇っていただろう
難しい機能は、無限に時間を与えてもジュニアには終えられないことがある。まだスキルがなく、そのスキルは身につくまでに何年もかかるからだ
ときにはシニアの助けは必要だが、そのせいでシニアが何も作れないなら、会社の立場では意味が薄い
難しい機能は十分にシニアな人に渡し、ジュニアを育てたいなら、その作業の簡単な部分を一緒に分担し、シニアが何をしているのか説明させればよい
皆を助けるTimの姿勢は素晴らしいが、ほかのプログラマーたちがそれほど多くの助けを必要としていて、Timが自分の成果物を出す時間がまったくないというのもおかしい
問題はTimではなく、専門家が常に助けを必要としている状態と、ボランティアのようなTimがいつでも助ける構造をよしとしたマネジメントにある
そもそもシニアの誰かがきちんと作っていたなら、ジュニアでも修正できるはずだった
もしそのシニアが作ったにもかかわらず構造のせいで難しく複雑なら、なぜ彼をシニアと呼ぶのか疑問だ
それでも、すべてのシニアの仕事がジュニアを助けることだけになるわけにはいかない
最近は、そういう人になるのは難しい
すべてが表に見える成果中心なので、そういう人は整理対象になりやすく、自分でも直接経験した
チームプレイヤー、メンター、ソフトウェアアーキテクトはだんだん押しのけられ、大量のコードを吐き出すコーダーがその座を占める
技術的負債のせいで機能提供と保守能力が時間とともに低下しても、マネージャーは実際にリリースされた機能やバグ数に関係なく、週に5000行超を安定して書く開発者を好む
チームリードであり、複雑なプロジェクトを管理した経験のあるエンジニアとしては、週に2000行を超えるコードを書く人は恐ろしく感じる
年間10万行を超えるコードであり、不要な複雑さを考えなければならない
同じ機能を1万行で、バグも少なく半分の時間で実装できる可能性が高いが、そうすると週380行にしかならず、マネージャーは好まないだろう
数千行を生み出す開発者は、プロジェクトの長期的な方向性を十分に深く考えていないと見るほうで、そのコードの大半は捨てられるコードに近いと感じる
Googleはある程度、Tech Leadという役割としてこれを制度化しており、このエンジニアには個人貢献者よりも、力を倍増させる人、メンターとして振る舞うことが期待される
設計どおりに常に機能するわけではなく、もしかするとまれにしか機能せず、TLが人の調整・計画・些細な論争にはまり、エンジニアとして働けなくなることもある
それでも役割の趣旨は悪くない
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
すべてを測定し、得られる数字に基づいて行動しようという発想は19世紀からあった
マネージャーたちはその頃から同じ慣行を繰り返し、結果も同じようにかなり安定して出ていた
少しだけ在籍した会社のオーナーは、最新のWebフレームワークと流行を追うために、Webサービスを6か月ごとにゼロから書き直したがっていた
週5000行の英雄なら、その場で採用していただろう
保守プロジェクトでは、一人で1行も書かずに1週間を過ごすこともあるし、むしろ1週間ずっとコード行数を減らす作業をすることもある
素晴らしい
ボート競技にはseat racingという訓練があり、8つの座席にさまざまな組み合わせで人を入れ替え、最も速い組み合わせを探す
個人の力も指標にはなるが、競技艇に誰が乗るかはチームの速度で決まる
結局、最速の組み合わせに最も強い8人がそのまま入ることはまれで、書類上ではそれほど優れて見えなくても、どの艇に入れても速くする「魔法のような」人が1人か2人いることがよくある
彼らは他の人たちのバランス、リズム、力を微妙に改善する
一部のコーチはこれを快く受け入れず抵抗し、その結果、勝ち星が減る
ソフトウェアチームとも非常によく似ていて、結局重要なのは組み合わせと結果だ
「技術的リーダーシップ」をコーチしてほしいと頼まれたときは、いつも促進者型の社員を注意深く見るように言っています。
彼らの支援は他の社員をより生産的で効果的にし、中には驚くような仕事を自分で成し遂げてすべての手柄を取るより、他人が見事にやり遂げるのを助けることに、より大きな職業上の満足を得る人もいます。
こうした人たちはしばしばスコアが低く出ますが、失うとチームの生産性は純減します。
だから、実際には生産的でない人と、他人の成功の中で生産性が現れる人を見分けるための道具を渡そうとしているのです。
1つの指標だけを測定し、それに合わせて管理するのは決してよくありません。
指標をゲーム化する人が「勝利」し、そうした行動が昇進につながるからです。
Googleのリーダー陣にもこの点を伝えましたが、Laszloは「これが我々の持っているシステムであり、完璧ではないが、これで進める。その中で働くかどうかはあなた次第だ」と言いました。
その会議だけでも、上級リーダー層がより良いエンジニアリング環境を作ろうとしているのかどうかを知るには十分でした。
多くの新任マネージャー、特に以前は個人貢献者のエンジニアだった人たちは、「最高」のメンバーを残し、「悪い」メンバーを外せば、チームの士気も成果も良くなると考えます。
しかし、彼らが理解する「最高」は、人を管理する基準ではなく、かつての自分の仕事をうまくこなす基準に基づいています。
そのため、自分と似たスキルや習慣を持つ人を好み、異なるスキルや習慣を持つ人を低く見てしまいます。
これに気づかせたときに目を見開く瞬間は、いつも興味深いものです。
ゼロ金利政策は、Jiraボードの管理やタスクリストを扱うシニアディレクターのような役割を増やし、実際の仕事ができる人を不足させました。
他の人の生産性を促進する人が存在し得るという考えに反対しているわけではありませんが、結局、何かを終わらせるにはその「他の人たち」が必要です。
そうでなければ、組織は壊死します。