私がソフトウェアの世界にいる限り、10倍の開発者という話があります。 彼らは、あなたの問題を解決するために、1/10の時間と1/10のコード行数でそれを行うでしょう。 素晴らしい人たちのように聞こえますが、この言葉はどこから来たのでしょうか。 それらは存在するのでしょうか。 もし存在するとしても、あなたはそうなりたいですか。
Tom DeMarco と Tim Lister は、1977 年から「コーディング ウォーゲーム」を実施しています。 これは、さまざまな組織のソフトウェア実装者のチームが、一連のベンチマークを最小の時間で最小の欠陥で完成させることを競う、一般向けの生産性調査です。 この調査では、600人以上の開発者が参加しました。
- プログラミング言語の選択はほとんど影響を与えず、COBOL/FortranであろうとPascalなどの高級言語であろうと、結果の広がりはほぼ同じでした。
- ある言語での経験が6ヶ月未満の人は、他の人ほどうまくいかなかったということを除いて、経験とパフォーマンスの間に相関関係はありませんでした。
- 欠陥ゼロのソリューションの開発者は、より正確な作業を行うためにパフォーマンスのペナルティを受けませんでした（実際、わずかに時間がかかりました！）。 最高の組織は最低の組織よりも11.1倍速く働いていた。 さらに、最も速く作業した組織は、受け入れテストに合格するコードを開発しました。 これで一件落着か？
そうとも言えません。 この研究では、職場環境（これは組織によって異なる）をパフォーマンスに相関させるために行っています。 7590>
Environments for coding Lesson learnt – get your working environment right first before you start about whether you can find 10x developers or not!
ネット マイナス プログラマー
Schulmeyer は、一部の開発者は「ネット マイナス プログラマー」 (NNPP) であり、チームから彼らを排除すると生産性が向上するほど多くの不具合を発生させると指摘しています。 これは、10 倍の開発者とはほぼ正反対で、チームの状態を悪化させる人がいる可能性があります。
もし負の生産者が存在するなら (- Nx 開発者？)ならば、10倍の開発者が存在することは明らかに可能です(数学はさておき)。
10倍プログラマの最大の論拠にはなりませんが？ もし私が小学生にチームに参加するよう頼んだら、彼らはネットマイナスの生産者になるでしょうか？ おそらく、隅っこに座らせて、コードを書き込ませたら（そして、どうにかして生産まで押し上げることができたら！）、そうなるでしょう。 もしあなたが、人々を隅に座らせて、フィードバックを与えず、彼らに生産に向かわせるような会社なら、おそらくあなたのチームにはNNPPがいるのがふさわしいと思います。
より現実的には、普通の会社で誰かを雇用する場合、その人がその役割で素晴らしくなるために必要なすべてのサポート (ピアコードレビュー、フィードバック、メンター、フィードバックのための自動コード分析、学習教材など) を与えるつもりであってほしいと思います。 確かに10倍速開発者の存在を語るには最適な話ではなさそうです。
Exploratory experimental studies comparing online and offline programming performance
Sackman, Erikson, Grantは1968年に「Exploratory experimental studies comparing online and offline programming performance」という論文を発表しているそうです。 最後に引用されているのは個人差に関するもので、「パフォーマンスの高い人と低い人の間には大きな個人差があり、しばしば一桁の差があることが明らかになった」という研究です。 これは、10 倍の差を説明する魔法の論文なのでしょうか。
この研究全体を読んで、いくつかの文脈を理解することが必要です。 まず、これらのテストは、IBM AN/FSQ-32 を使用したオンラインと、ペンと紙のパフォーマンスの両方を比較しました。 プログラマーは、JTS (ALGOL の派生言語) と呼ばれる言語を使用して、コードを (ペン/紙に書いてオペレーターに渡すか、直接コンピューターに) 書きました。 彼らは解答を実装するために、Samelson と Bauer による論文を渡されました。 その論文からの画像を以下に示します。
Obvious, right? 2 つ目の課題は、ちょうど 1 本の道を持つ 20×20 の迷路を解くことでした。 迷路は、各セルの出口の情報を含む 400 要素のルックアップテーブルで記述されていました。 この課題では、補助教材は提供されませんでした。 迷路の解決は魅力的な問題空間で、最近グラフ理論のコースを修了した人は大きな利点があったと思います！
これらの課題を知ると、大きな個人差があることに驚きを禁じえません。 1968年当時、ソフトウェア工学は学問として生まれたばかりでした。 タスクは数学的なものであり、参加者のバックグラウンドがどうであったかは定かではありません。 確かに、より高度な数学の授業を受けた人に有利でしょう。
ここから見つかる10倍の人は、これらの問題を解く才能がある人だと思うのです。 迷路＋連立方程式を解く」という問題空間では、10倍の開発者が存在し得ると信じることができますが、これが他のドメインに移行することは困難です。 しかし、おそらくコードを書くことは 10 倍うまくなるでしょう。
10 倍開発者神話の背後にある研究方法論については、この素晴らしい本の中でより良い議論がなされています。 たとえ 10 倍の開発者が存在したとしても、おそらくそうなることを目指すべきではありません。たとえ最初に完璧にコードを実装できたとしても、おそらく最初の段階で間違った問題を解決していたことに気づくでしょう。 これは、引き出し、想像、実装、検証の継続的なサイクルがあるアジャイル アプローチに変わりました。 このモデルでは、実装は (通常は) ボトルネックではありません
ボトルネックでない部分で節約できた 1 時間というのは、幻のようなものです。 (Eliyahu Goldratt)
では、代わりに何をすればよいのでしょうか。 そう、ビジネスにとってより価値のある存在になることに集中するのです。
- 人々が使用できるソリューションを設計する。
- それが価値あるものかどうかを評価するためにフィードバックを収集する。
- 面白いことよりも、本当の問題に焦点を当てること。
- チームのメンバーを素晴らしい人に育てること。
そして、記録的な速さで完璧なコードを書くよりも価値があることがたくさんある（T字型を参照！）。 コーディングは重要です! コードは書かれるより 4 倍多く読まれるので、コードについて簡単に推論できるように書けば、将来劇的に報われます (どこかに 10 倍の話があるかもしれませんが、それはまた別の日にしましょう)。 自分の技術 (コーディング、デザイン、プロジェクト管理など) に時間を費やすことは必須ですが、自分の技術は単独で存在するのではなく、より高い目標を達成するために存在することを忘れないでください。 幅広いスキル (特に人に関連するもの) を学べば、より価値が高まり、真の 10 倍の「開発者」に近づくことができます」
。