え、マジ！？同僚プログラマーの生産性が低すぎてヤバい件（2023年版）
引用元：https://news.ycombinator.com/item?id=43452649
開発者の生産性を個人で測るってナンセンスじゃね？魔法じゃないけど変数が多すぎんだよね。ストーリーポイントとかコード行数で測るのは逆効果。意味ない作業を増やそうとするじゃん。タスクを簡単にするか、既存のツールを使う方が価値あるのに。ビジネスの成果で測りたいけど、特定の開発者のせいにするのは難しいし。結局、主観的な判断になっちゃうよね。測れないって認めた方がマシだと思う。
うちのディレクターがGitHub Enterpriseの統計にマジでハマっててさ。commitのsquash禁止、毎日commitしろって言うんだよ。誰が一番コード書いてるか見たいんだって。インターンが終わりに近づいたとき、そいつのこと気に入ってて採用したがってたんだよね。コードの量で判断してたんだけど、そのインターン、マジでヤバかったんだよ。unit test書かせたら、今の結果を強制するテスト書くんだもん。今の挙動が間違ってるかどうかなんて考えないの。おかげで採用は免れたけどね。
下手な運転手を警官が止めるジョーク思い出したわ。「事故ってないぞ！」って運転手が文句言うと、警官が「いや、お前は事故を何十件も引き起こしてる」って返すやつ。一部の人は、自分がどんな破壊的なことをしてるのかマジで気づいてないんだよね。
＞「ほとんど全てのソフトウェア開発組織には、戦術的なプログラミングを極端に行う開発者が少なくとも1人はいる。戦術的な竜巻だ。戦術的な竜巻は、他の人よりもはるかに速くコードを書き出す多作なプログラマーだが、完全に戦術的な方法で作業を行う。素早い機能を実装することに関しては、戦術的な竜巻よりも早く終わらせる人はいない。一部の組織では、経営陣は戦術的な竜巻を英雄として扱う。しかし、戦術的な竜巻は破壊の痕跡を残す。彼らは将来彼らのコードを扱うエンジニアからは英雄とは見なされないことが多い。通常、他のエンジニアは戦術的な竜巻が残した混乱を片付けなければならないため、それらのエンジニア（真の英雄）は戦術的な竜巻よりも進捗が遅く見える」。ジョン・オースターハウト、ソフトウェアデザインの哲学”
まさにそれ。
つまり、10x programmerってこと。
そうじゃないよ。10x programmerはチームメンバーとかプロジェクトの状況に関係なく成果を10倍にするって思われてるけど、LLMとか、それを使ったエージェントなら、そのうちそうなるかもね。
10x devsが企業の宣伝文句だって考えるより、LLMが10x devsになるって考える方がヤバくない？
昔いたマネージャーとQA思い出したわ。QAはいい奴だったけど、マジで使えないQAだった。どうでもいいガイドラインでstoryを落とすんだよ。ホームページのフォントサイズ変更のstoryで、ログインできないから落とすんだぜ？（認証サービスがメンテナンス中だった）。マネージャーはそいつのこと気に入ってて、何回も昇進させたんだ。他の社員は昇進を飛ばされるのに嫌気がさして、会社を辞めて、ちょっとした人手不足になったんだよね。
みんな、こういう奴らと何人も付き合ってきたんじゃないかな。
＞who was writing the most code
問題はそこだよね。コードの量は価値と相関しない。むしろ、バグだらけで技術的負債を抱えてる場合は、マイナスになることだってある。コードの量で生産性を測るのは、キレイでメンテナンスしやすい、バグのないコードを書くことを積極的に妨げるんだ。
最近よく聞くAIの“成功”事例も似たような感じがするんだよね。AIが短時間で大量のコードを生成することには驚かされるけど、生成されたコードのメンテナンスやデバッグについてはあんまり語られないよね。
100行以上あって制御フローが複雑に絡み合った関数を、メソッドチェーンを使って数行の式にまとめるのはマジで最高。
同僚が、その一行の式じゃ対応できない特殊なケースのデバッグで苦労して、結局全部書き直すハメになるんだよ。凝縮されたコードが良いとは限らないし、コード全体が理解不能になることもあるからね。
同僚が長いチェーンで書かれたコードをデバッグするのを見たことあるけど、結局デバッグするために全部元に戻してたよ。分解したらデバッグできたから最高じゃん！デバッグが終わったら、また元通りに戻してたけど…意味不明。
＞コードの量は価値と相関しない。むしろ、バグだらけで技術的負債が多い場合は、価値と負の相関関係になることさえある。
“No Code”またはニヒリズムソフトウェアエンジニアリング
コードがない方が速い。
コードがない方がバグが少ない。
コードがない方がメモリの使用量が少ない。
コードがない方が理解しやすい。
コードがない方が安全で信頼性の高いアプリケーションになる。何も書かずに、どこにもデプロイしない。
最も生産的な日は1000行のコードを削除した日だった。– Ken Thompson
最も安く、最も速く、最も信頼性の高いコンポーネントは、そこにないものだ。– Gordon Bell
削除されたコードはデバッグされたコードだ。– Jeff Sickel
コード行数でプログラミングの進捗を測るのは、重量で航空機の建設進捗を測るようなものだ。– Bill Gates
＊Master FooとTen Thousand Lines＊
Master Fooは、プログラマーに言った。「シェルスクリプト一行には、C言語一万行以上のUnixの本質がある」と。
プログラマーは、「C言語こそがUnixのカーネルだ。どうしてそんなことがありえるんだ！」と言った。
Master Fooは言った。「それでもシェルスクリプト一行には、C言語一万行以上のUnixの本質がある」と。
Unixの本質は悪意のある引数とコードインジェクションの脆弱性を好み、C言語はバッファオーバーフローなどの独自の問題を引き起こす。
開発者の生産性は量子力学みたいなもんだよね。測ろうとすると、波動関数が崩壊して、測ろうとしてたものが根本的に変わっちゃう。とは言え、どこに行っても、コードのコミット数を見れば、誰が優秀な開発者かだいたいわかる。Tim senseiみたいなケースは意外と多いのかもしれないけど、俺はまだ出会ったことないな。
＞どこの職場でも、コードのコミット数を見れば優秀な開発者が誰か見当がつく
これはジュニアからシニアレベルの役割には当てはまるけど、Staff以上のレベルになると通用しなくなる。エンジニアはコードを書くけど、以前より書く量は減るのが普通。それは、彼らにイニシアチブ、統合、移行全体を設計してほしいから。重要な仕事だしトップ開発者がやるべきだけど、シングルフィーチャーを担当する人よりコミット数は少なくなる。ソースレベルの複雑性が高いプロジェクトを除けば、Staff以上のエンジニアがシニアエンジニアと同じくらいコミットしてるなら、レベルが間違ってるか、使い方が間違ってる。
＞どこの職場でも、コードのコミット数を見れば優秀な開発者が誰か見当がつく
今の職場ではコーディングのパフォーマンス指標は測ってないけど、リポジトリへのコミット数が多い人を見ると、会社に一番貢献してる人だってわかる。Staffエンジニアでも、コードを量産する人が一番価値を生み出す。月に1回しかコミットしないStaffエンジニアは、給料が高い割に価値を生み出さないことが多い。
前の職場では、最後の1年半はStaffエンジニアとしてほとんどコミットしなかったよ。提案書を書いたり、役員に説明したり、アーキテクチャレビューをしたり、設計コンサルをしたり、大規模インシデントへの長期的な対応を計画したりしてたからね。会社に貢献してたのは間違いないけど、コミットとは全く関係なかった。コードを書きたかったから、またコードを書きまくるような仕事に移ったよ！
会社が主観的にパフォーマンスの低い人を会社の寿命の間ずっと雇い続けることってできるのかな？それって会社全体の収入や利益にとってプラスなのマイナスなの？もし全ての会社がそうしたらどうなる？チャリティの負担を全ての会社に分散させて、より良い社会にできる？結局、指標が良いか悪いかすら分からん。なんでこんな風に見るのか考えるべきかも。船長にとって、最高の船乗りばかりじゃないって事がそんなに気に障る事なの？航海に出るチャンスじゃん。フリーライドって考え方が深刻なモラルハザードになってる気がするんだけど、なんでだろ。 日本がそうじゃん。雇用は終身雇用が前提。パフォーマンスが低い人を辞めさせるための抜け道はあるけど、ほとんどの人はほぼ終身雇用だよ。 それってどうやって教えられたんだろ？どうやって知ったんだろ？ そんなフリーライダーをチームに入れるつもり？結局、あんたが自分とそいつのタスクを両方やる羽目になるのに、給料は同じかそれ以下。チームの予算が決まってるなら、分割する人数増やしたい？履歴書どこに送ればいい？ もしそうするなら、必要な能力からかけ離れた人は選ばないよ。質問を変えるなら、90点の学生ばかりのチームに70点の学生を雇うかってことだよね？イエス。50点の学生は選ばない。議論されてる内容は80点の学生（95点のクラスでのフリーライダー）を排除するって話。70点の学生を指導する必要があるかって？イエス。なんでそんなことするかって？魂のためだよ。そんな考え方は今の社会ではビジネスにはそぐわない。 個人的な意見だけど、会社の目的は従業員に生活の糧を提供することだと思う。 最近の最悪なプログラマーはバイブコーダー。バイブコーディングって過大評価されてる気がする。 バイブコーディングが、マジな仕事のスキル要件になってるけど、ありがたいことに、まだ働きたい場所じゃない（今のところ）。先日、YC24の金融サービス業界の会社で「バイブコーダー」のポジションを見たよ。応募条件は、現在のコードの50%以上がAIによって生成されていること。バイブコーディングの経験は「必須」。従来のプログラマーは応募不可。しかも、週7日、1日12時間労働だって。年収は最大12万ドルで、ストックオプションは雀の涙程度。サンフランシスコへの引っ越しが必要。サンフランシスコじゃマクドナルドレベルの給料。バイブコーディングの搾取工場を運営するのが、彼らにとって大幅な節約になるって考えてるんだろうね。おまけに、そのスタートアップが提供する金融サービスは、債務回収業者に代わって債務者に電話をかける自動音声サービス。 10年間プロとしてコードを書いてきたけど、バイブコーディングできるようになったから、自由時間にめっちゃコード書くようになった。仕事ではやらないし、ジュニアのバイブを信用しないけど、こんなに力を感じたツールはないよ。 プロトタイプには便利だけど、複雑なものには向かないね。 前はそう思ってたけど、ここ半年で考え方がマジ変わったわ。このスタイルでもマジ複雑なもん作れるんだわ。 それって矛盾じゃないんだよね。たぶん、めっちゃ複雑なプロトタイプは作れるってこと。でも、そのプロトタイプが信頼できてメンテナンスもできなきゃ、ただのプロトタイプで終わるじゃん。 ＞たぶん、めっちゃ複雑なプロトタイプは作れるってことでしょ？ プログラミングチームのメンバーはみんな、誰が優秀で誰がそうでないか知ってるっしょ。 意味なくね？本当に優秀な人を見抜くには、自分も優秀じゃないと無理じゃん？それに、分かってても言わないでしょ普通。 今まで働いたどの会社でも、誰が有能で誰が無能かはみんな知ってたよ。学校と同じ。良い先生と良い生徒は誰かみんな知ってたじゃん。他の人と一緒に働いてて、それに気づかないとかありえなくね？ ぶっちゃけ、「有能」と「頭が良い」とか「一緒に働きやすい」をごっちゃにしてるんじゃない？何社かでスタッフエンジニアのBobの事を絶賛する人がいたけど、確かに良い人（か口が上手いだけ）だけど、プロジェクトは失敗続きで、100%彼のせいだって知ってたし、マネジメントも気づいてた。逆もたまにあるけど。それに、そういうことにマジ無頓着な人も結構いると思うよ。 ＞「有能」と「頭が良い」とか「一緒に働きやすい」をごっちゃにしてるんじゃない？ ＞仕事では、頭が良いとか、働きやすいとか、良い人かどうかはマジどうでもいい。結果が全て。嫌な奴だけど結果を出す「Bob」を擁護する。 つまり、Aliceがわがままだったらどうするかってこと？Bobがマジでひどい奴ならHRが動くでしょ。でも、Bobが単に扱いにくいだけなら、AliceとBobが協力するしかない。みんなが自分の思い通りに動くなんて期待できないじゃん。 Timみたいな状況、昔はマジで困ってたけど、あることに気づいてからは余裕になったんだよねー。Tim本人も記事の作者も気づいてないみたいだけど。解決策は超簡単で、マネージャーがTimが手伝ったチケットにTimの名前を紐付ければいいだけ。Timからチームメイトにお願いすれば喜んでやってくれるし、優しいチームメイトならチケットに「@Timに手伝ってもらった」って書いてくれるよ。こうすれば、会社のクソみたいな指標でTimが不利になるのを防げるんだよね。 ＞問題はマネジメントがTimの名前をチケットに紐付けることで簡単に解決できる” 誰も良い解決策だなんて言ってないと思うよ。数あるダメな解決策の一つってだけで、現状それしかないから使ってるだけ。例えば、リモートチームを8年くらいやってるけど、みんなにパブリックチャンネルで会話するように言い続けてるんだよね。理由の一つは、誰がどれだけ手を貸してるかを知りたいから。でも、みんな全然やってくれないんだよね。どうすればいいのさ？ チームとの信頼関係とコミュニケーション不足って感じだね。 まず最初に、気分を害さないで聞いてほしいんだけど、これはあなたの考え方を正すためのアドバイスだよ。あなたの公開プロフィールを見ると、技術的なバックグラウンドがあまりないみたいで、ScrumとかAgileの手法でチームを管理してるのかな。プロジェクトのデリバリーには使えるかもしれないけど、チームの生産性を深く分析するには、あなたにその能力がないと思う。メンバーの一人がサボってるとか、他の人に頼ってるとか、判断できないでしょ。 他のコメントは的外れな憶測が多いけど、あなたのコメントが一番正しいと思う。解決策にも大賛成。ただ一つ違うのは、外部から雇うのではなく、チームの中から技術リードを育てようとしてること。チームの貢献を評価してるってことを伝えたいし、できる限り内部から昇進させたいんだ。年功序列とか、言語スキルとか、社内的な問題はあるけど、解決に向けて努力してるよ。 チームメンバーの一人がほとんど何もしなくて、常に他の人に手伝ってもらって生き残ってる。これは他の従業員の生産性を下げてるよね。 え、何が言いたいの？自分のことだって思って気分を害したみたいだけど、全然理解してないよね。私が言いたいのは、エンジニアリング以外のマネージャーは、1) 休暇の承認、2) ちょっとしたプロジェクト管理、3) 定期的な1on1はできるけど、意味ないってこと。だって、仕事の内容を理解してないし、パフォーマンスのための行動しかしてないから。または、もう開き直って、MBAとかScrum masterに重要なエンジニアリング事業を任せて、結局Boeingの飛行機からドアが落ちたり、宇宙飛行士が9日じゃなくて9ヶ月も宇宙にいたりするんだよね。 30年の経験を持つエンジニアだけが、MustangがModel Tよりも優れていると言えるんだよ（笑） なんで(笑)をつけるの？話が違うと思うけど。何かを使うことと、製品をエンジニアリングすることは違うんだよ。最新のiPhoneを持ってても、エンジニアじゃないし、製品を設計、概念化、構築するのに何が必要か知らないでしょ。経験がある人たちは、キャリアアップや収入アップのために会議でハッタリをかます人じゃなくて、情熱を持った人がエンジニアリングをしていた時代を覚えてる。Boeingの例を見ればわかるように、パフォーマンスばかり気にする人が生産性や収益性を下げてるだけでなく、みんなを危険に晒してるんだよ。MBAの人が医療POとかScrum masterを思いつかないことを願うよ。 誰かの助けを借りてばかりのダメ社員をクビにするのに、20年も経験いらないっしょ。他の仕事と同じで、プログラマーにも使えないやつなんていっぱいいるって。そういう社員って、人の時間を奪ってチームの足を引っ張るんだよね。 反論する前に、ソフトウェア開発チームのマネジメントに関する本を読んでみてよ。例えば「Peopleware」とか「Dynamics of Software Development」とか。ちょっと古いけど、名著だよ。「Dynamics of Software Development」はMicrosoftのプロダクトマネージャーが書いたんだ。そしたら、もっと理解できるかもね。MBA批判してるのって、俺だけじゃないから。飛行機のドアが外れた事故覚えてる？アメリカ議会で公聴会が開かれて、議員たちが「ボーイングのCEOがエンジニアじゃないのはなぜだ？」って質問してたよ。政治家ですらそう思うんだよ。 関係ない本とか、統合失調症とか？何も指摘してないのはお前だろ？自分のコメントをゆっくり読み返して反省しろって。医者じゃないから医学的なことは言えないけど、その2冊の本は名著だよ。マネージャーなら知っとけっての。 社員は、あんたに相談したり、あんたが見てる場所で話すと、友達がクビになったり、アドバイスなしに悪い決定が下されたりすると思ってるみたいだね。あんたと社員の間に、信頼関係を築けるマネージャーを挟んだ方がいいかもね。 優秀なテクニカルリードがいれば、この問題も解決するんじゃない？ 生産性の指標を形式化しても、意味ないよ。それに、あんたが言ってるその人は、他の開発者よりも早く指標を悪用する方法を学ぶと思うよ。 ＞「みんなにパブリックチャンネルで会話するように言ってるんだけど、開発者は拒否するんだよね。」 ＞ポリシーを無視するやつはクビにしろ。そうすれば態度が変わるよ。 そんな態度だと、特定のチームしか育たないよ。指標 অনুসারে生産性は高いけど、仲間意識が強くて、合わない人は排除されるようなチームになるよ。でも、新しいことを生み出す必要が出てきたら、マジでヤバいよ。 解決策を提案しただけで低評価されるなんてかわいそう。 ＞例えば、リモートチームを8年くらいやってるんだけど、みんなにパブリックチャネルで会話するように頼み続けてるんだよね。 気を悪くしないでほしいんだけど、決めつけでプロセスを変えようとしてるように聞こえるよ。目的は何？チームのパフォーマンスを上げることだよね？誰かをいじめてそれができる？絶対に無理。他の人が彼をかばうよ。だって次は自分がそうなるかもしれないって知ってるから。そのパフォーマンスの低い人が、怠けてるからそうしてると思う？助けを求める方がずっと大変なんだよ。彼が他の人と同じレベルになれるように手助けする方法を探してみてはどう？それが目標だよ。スパイするんじゃなくて、他の人を助けたチームメンバーを表彰して、隠れる必要がないようにしてあげて。弱いメンバーが安心して相談できる環境を作って。もし、努力してもダメで、チームの生産性を下げてるなら、それは自分の責任だってことを知るべきだよ。それは仕方ないことだけど、もっと頑張るべきだってこと。 Jiraをバリバリ使って速度を測り、貢献者全員がチケットに時間を記録する組織でチームを管理してたんだけど、すごく役に立ったよ。見積もりが正確になるし、知識の伝達がどこで行われてるかもわかるし、みんなが忙しいってこともわかるから、最初から正確な見積もりができたんだよね。Agileは形式的になりすぎることもあるけど、そういう会社で働いてるなら、抵抗するのは無理かも。だから、複数の参加者が同じチケットに時間を記録することで、厳格なスクラムの中でも有機的なチーム運営ができるんだ。システム全体を変えられないなら、せめて自分たちに合うように調整するしかないってこと。 生産性を測る数値は役に立たないかもしれないけど、GPは貢献を記録してるだけだと読めるな。そのアプローチは良いと思う。推薦だけでなく、具体的な記録も残せる。 大きな組織では、技術に詳しくない上司や人手不足の管理職にもわかりやすく、目に見える形で成果を上げることで、出世していく人がいるんだよね。それは生き残るための必須スキル。それが正しいかどうかは別として、そうせざるを得ない状況もある。もちろん、システムを悪用する人もいるけど、周りの人は気づいてるし、それは管理職の問題だと思う。 バグ/ケーストラッキングがクソなんだよ。今まで使ったやつは全部アサインできるのが一人だけだから、対等なペアプログラミングでも誰か一人を選ばないといけないんだ。提案されてるのは、メトリックじゃなくてケーストラッカーを回避すること。 ＞これは問題を悪化させるだけだよ。だって、メトリックがクソで、仕事ぶりを反映してないって認めてるんだから。 会社とかビジネスでは何かを提供する必要があるし、お金を払ってる側は、それに見合う何かを受け取ってるか知りたいんだから、「今週は何をしたのか」って聞くのは当然のこと。 GPは、メトリックについて文句を言っても、上司や製品担当者が肩をすくめるっていう、ありがちな前提で話してるんだと思う。彼らは自分たちのインセンティブを維持しようとするからね。 それってさ、commitの自動テストでfailureが出たときに、自分の名前をticketにつけてもらおうとするか、もっと言えば自分でつけちゃうような人が出てくる原因になるんだよね。「品質文化についてチームメンバーを徹底的にmentorする」とか言ってさ。 確かにそうなんだけど、くだらないゲームに参加したがらない人もいるじゃん。managerがチームと一緒にいないで、チームの状況を理解してないのが謎。まあ、新任だったのかもしれないけど、優秀なmanagerならチームのdynamicsをチームメンバーに聞くよね。 くだらないゲームってのはagreeだけど、これは単に他の人のcontributionを認めるってことじゃん。metricとか関係なく、これはgeneralにencouragedされるべきだと思うな。 Tim自身が、そのmetricが存在することを知ってて、それがfiringの判断に使われるってわかってたのに、最初に全部のticketに自分の名前をattachしなかったのがshockだわ。self-preservationが足りないって話だよな。performanceをmetricで測るところって、みんなinstinctivelyそのmetricをpumpしようとするじゃん。他のmotivationなんていらないんだよ。 みんながみんなmetric gameをやるわけじゃないよ。 Yup、metric gameに参加しなかったらburnedしちゃった。gameをplayしてるco-workerと比べると、my metricがgoodに見えないからね。そのcostは、実際にどれだけworkをget doneしてるか、teamをsupportしてるかをみんなにremindしなきゃいけないこと。「your metric tells us you’re not doing enough」talkがcome upするときに。 どのemployerもbasically同じだってresignedしたよ。actual workに25-50%の時間を使って、politicalなこととかself-promotionとかmetric-chasingなworkに50-75%の時間を使わないと、companyが言うところの”impactをshow”できないんだよね。literally every jobでそうだった。expertとしてhireされたtechnical workを100%just doすると、bad timeになるよ。 Timはteamにappreciatedされててworkを楽しんでて、upper managementがそれをupendしたらjump shipできるskillがあるpositionにいるみたいだね。彼がsilly metric gameをplayするreasonはないよ。 Timのproblemはbad managerだってこと。managerのcore jobの一つは、team memberそれぞれがprovidingしてるvalueをupwardsにcommunicateすること（or not providing）。彼のjobはTimのcontributionがreflectedされてvisibleになるようにensureすることだったんだよ。 interesting pointだね。multiple peopleにticketをassignできるticketing systemを見た覚えがないな。 Timが残って、マネージャーがプロセスを正しい方向に導いたのは良かったね。それには話を聞くマネージャーが必要だ。もっとコメントを表示（1）
＞https://www.lycee.ai/blog/why-vibe-coding-is-overrated
https://www.ycombinator.com/companies/domu-technology-inc/jo…
YCは悪役になったね。
GPはプロトタイプ以上のことができるって言ってるんだと思う。マジ同意。でも、どこでも使えるわけじゃないのが現状。俺のプロジェクトで一番良いのは、マジどうでもいいけどめんどくさい「3rd party integrations」かな。例えば、成熟した製品があるとして、クライアントxが製品zとの連携を求めてきたとするじゃん。そしたら「これがうちの内部モデル{json dump}で、これが3rd party integrationのドキュメント/サンプル{code dump}です。インターフェース書いて」って言えるようになった。だいたい上手くいく。もっと複雑な場合は、まず/architectして、それから「書いて」ってやると良い感じ。場合によるけど、食わず嫌いはマジ損。この分野は進化がマジ早いから、今できることにフォーカスすべき。できないことは分かってるけど、できる時はマジで時間節約になる。
チームで仕事してて、チームの成績で給料が変わるような状況なら、ごっちゃにしてないって。仕事では、頭が良いとか、働きやすいとか、良い人かどうかはマジどうでもいい。結果が全て。嫌な奴だけど結果を出す「Bob」を擁護する。仕事以外では、頭の良い友達を大切にする。レイオフされた友達もいるけど、友達関係は続くし。自閉症スペクトラム気味だから、そういう人には寛容だよ。
＞無頓着な人もいると思うよ
無頓着な人はレイオフされてた。自分は会社の宝だと思ってたんだから。数年後には「会社が正しかった」って認めてたけど。
「Bob」のせいで、彼と同じくらい優秀な「Alice」が力を発揮できなくなったらどうすんの？もっとコメントを表示（2）
生産性の指標が全部ムダってわけじゃないよ。例えば、あるチームに入ったとき、Jiraチケット1枚に対してPRがほぼ1つ紐づいてて、3人チームの中で一人が年間のPRの70%を占めてるとしたら、これは無視できない情報だよ。その人がリードの可能性が高い。もちろん例外もあるし、ズルする人もいるけど、考慮すべきデータポイントだよね。
全然解決になってないと思うんだけど。むしろ悪化すると思う。だって、a) 指標がクソで仕事ぶりを反映してないって認めてるし、b) クソみたいな指標を維持したまま、何かのシナリオでスコアを上げるために操作しようとしてるじゃん。そんなの誰も望んでないって。
結局、全員が不正だってわかってるシステムを構築して、それに深く関わってるからズルし続けることになるんだよね。
チームメンバーの中に、あんまり仕事してなくて、他のメンバーに手伝ってもらってばかりの人がいるんだよね。悪い人じゃないんだけど、うちの基準には達してないかな。直接聞けばいいって言うけど、チームを良くするためでも、同僚の悪いことを言えない文化もあるんだよ。
魔法みたいな解決策なんてないと思ってるから、特定の解決策を主張するつもりはないよ。もしあなたが世界中の人が見つけられなかった、より良い指標やマネジメントスキルを持ってるなら、ぜひ教えてほしい。みんな喜んで採用するよ。
＞もしあなたが世界中の人が見つけられなかった、より良い指標やマネジメントスキルを持ってるなら、ぜひ教えてほしい。みんな喜んで採用するよ。”
マジか…
追記：もしかしたら、悪い知らせがすぐに解雇につながるんじゃないかって恐れてるのかも。問題が起きたときに、安心してオープンに話し合える雰囲気を作るべきだよ。チームの最大のメリットの一つは、みんなの知識や能力を結集できることだと思うんだ。もし正直なコミュニケーションを恐れていたら、チームのパフォーマンスは確実に下がるよ。マネージャーがそれを改善する一番の力を持ってると思うんだけどな。
解決策は2つ。チームに技術的なリードを雇うか昇進させるか、あなたが自分でプログラミングを学んで、1年くらいの実務経験を積んでから評価するか。同じようなバックグラウンドの人たちが、チャットでの発言回数とか、commit数とか、Confluenceでの活動とか、色々な指標でエンジニアの生産性を推測しようとして苦労してるのを見てきたから。
Scrum master、PO、Agile coach、MBAの人がこのジレンマを考えるなら、医者とか弁護士とか機械エンジニアの仕事の質を、同じような経験や知識がないのに判断できないのと同じだってこと。ソフトウェアエンジニアを評価できると思うのはなぜ？
でも、それまでの間、チームを管理しなきゃいけないしね。
プログラミングに限らず、色んな仕事でよくあること。
なのに、こんなコメントがあるんだよね。
＞あなたは、メンバーの一人がサボってるとか、他の人に頼ってるとか、判断する能力がない”
マジかよ。
他の仕事なら、マネージャーやHRがチャットやメールを読んで、通話記録を要求すればわかることじゃん。バレバレなのに。
それに、これはマネジメントの基本でしょ？
「技術的な能力がない」って言うけど、マネジメント能力もないように見えるんだけど。
それに、開発者がお互いをプロの基準に保つっていうAgileの考え方は、おとぎ話だよね（Agile全体がそうだけど）。
あとさー、MBAとかscrum masterの文句ばっかり言ってると、プロっぽく見えないし、話が通じない人だと思われちゃうよ。「MBAは全員悪」みたいな白黒思考もヤバいって。ちなみに、俺はMBA持ってないし、scrum masterでもないからね。
お願いするのやめなよ。マネージャーの指示は命令だよ。部下に拒否させんなって。給料払ってるのお前だろ。ポリシーを無視するやつはクビにしろ。そうすれば態度が変わるよ。
技術的な面では、プロジェクトのコミュニケーションをすべて記録して、オンボーディングとかドキュメントの自動生成、チームの時間を節約できるリファクタリングのホットスポットの特定に役立てたいってことを明確にすること。監視目的じゃなくて価値があるからやるんだってこと。
＞「多くの文化では、同僚の悪口を言うことは許されない。」
マネージャーは、文化的な違いを理解して、それに対応する必要があるんだよ。問題点を特定できたなら、解決策を見つける番だよ。
＞「もしあなたが、世界中の誰もが考え出したよりも優れた指標や管理スキルを持っているのであれば」
そんな態度じゃ、答えは見つからないよ。基本的なことができてないんじゃない？
次の日には、みんな履歴書更新して、転職先探すよ。もっとコメントを表示（3）
誰もやらないのは、それがみんなを邪魔するただのノイズだから。それに、議論が拡散して停滞するし。
少人数のグループの方が問題解決には効果的なんだよね。親密なグループほど会話の摩擦が少ないし、ビジネス用語を使わなくてもいいから。それに、技術者じゃない人がいなければ、会話を簡単にする必要もないし。プライベートチャットなら、誰も状況を逐一聞いてこないし。問題が解決してコミットされるか、グループが作業中かのどっちか。
物理学で言うように、”すべてのモデルは間違っているが、いくつかは役に立つ”ってこと。すべてのメトリックは間違ってるけど、正しく使えば役に立つものもある。
ゲームを捨てられないなら、ルールを調整するしかない。
metricがdumbでdepressingだって思って避ける人もいるし（articleであったように）。
時間が経てば無くなるとか、managerがcoverしてくれるってassumeする人もいるし（articleであったように）。
manager+execs+HRとbehind-the-scenesでtalkして、bad metricを終わらせる人もいる。
disapprovalのlookのintensityでmetricをmeltさせる人もいる。(Management ProTip: このlevelのwillはbusinessやengineering problemsをsolveするのにharnessedした方がbetter)
OKRで悪い結末を経験したよ。そのスタートアップはチームだけでなく個人のOKRも求めて、さらにストックオプションをOKRに結びつけたんだ。ロボットのスタートアップで、ソフトウェア、ハードウェア、組み込み、DevOpsとかのチームがあった。
結果、開発者は孤独な島になった。昔のTimはいなくなった。俺（ソフトウェアインテグレータ）が問題に遭遇して、解決できなかったから、専門家（制御/運動学）にフィードバックを求めたら、「OKRの締め切りが近いから助けたいけど無理」って言われた。彼なら1日で修正できたのに、結局2週間かかった。
問題はboostライブラリとカスタム運動学ライブラリでstructコピーがあって、違うライブラリが違う順番で並進と回転（xyz、rpy、Euler、Quaternion）を表してたことだった。2年間誰も気づかなかったみたい。Softwareチームに報告したけど、OKRのせいで何もされなかった。
