🤑

他人の10倍仕事ができる人に10倍の給与を支払うべきなのか問題

2023/04/16に公開

ポエム

成果主義

idea

サブタイトル：「個人差」あるいは「知」と向き合う - 成果と継続、そしてチームについて語りたい記事だった。

この記事では、チームにおける成果と継続の価値について私が考えたことを述べようとしていたのですが、その問題提起の部分の話がかなり膨らんでしまったので問題提起部分だけを分けて書きました。
一応、どういう事を考えているかの概要もこの記事の末尾に書いておきます。

2024/7/7 10倍、という部分の構造について掘り下げた記事をかきました！

2023/4/18:補足を追記しました。

2023/4/29 とうとう、続きをかきました！

2023/4/30 結論"じみたもの"も書きました。↓

問題提起："成果主義"は解か？

まず手始めに「他人の10倍仕事ができる人に10倍の給与を支払うべきなのか問題」について考えたいと思います。

様々な人が、プログラマ、あるいはソフトウェアエンジニアの個人の能力には大きな差があると話しています。例えば、ピープルウエアにおいては、コーディングの実験で最優秀/最劣等の間で10倍程度の差があったという記述があります。また、ビル・ゲイツ氏は「優秀な旋盤工の賃金は平均的な旋盤工の数倍だが、優秀なソフトウェア・プログラマーは平均的なプログラマーの10,000倍の価値がある。」と述べたと言われます。この主張の一次資料を見つけられなかったのですが、少なくともそのような言葉が蓋然性をもって受け入れられる程度には、プログラマに差があるというのは「よくある主張」となっています。私自身も、具体的な数値が10倍か10000倍かはともかく、優秀なプログラマと普通のプログラマの間にはそうした性質の、数倍では済まない差があるように感じています。

では、そのような10倍、あるいは10,000倍の価値を創出するプログラマは、それに比例した給与を受け取るべきなのでしょうか？これはすごく素朴で単純ですが、しかし大変答えるのが難しい問いであると思います。

ソフトウェア開発ではない別の世界、例えばスポーツの世界を見れば、確かに一流の選手は一般的な選手の何倍もの契約金をもらっていて、そうしたあり方は正しいのかもしれません。
ただ、私は個人的に正しいと思うことができませんでした。
これはごく個人的な感覚の話です。他人の10倍、あるいは10,000倍の能力が純粋に本人の努力だけで生じたものであれば、まだ分かる部分がなくもないです。しかし、私の人生経験では、ソフトウェア開発に関して言うと、努力は支配的な要素ではなくて、運、天与のものと思えるようなものがプログラマのアウトプット量に大きく影響しているように思われました。ある一個人について、年月を経た成長について見る時、経験によるアウトプットの質はさておき、単純なアウトプット量そのものを評価するならば、それは最低限の教育が完了したキャリアの初期、その数年後、さらにその十年後、といった年月を経ても大きな差がない場合がほとんどであるように感じました。この差をもたらしているのが先天的なものなのか後天的なものなのか、私にはわかりませんが、しかし順調に作業できた場合のアウトプットの総量みたいなものは大きく変わらないように見えました。コードの質のようなものは確かに変わり得ますが、10倍、あるいは10,000倍変わるという事はそう無いように思いました。

そのような運だけで、10倍、あるいは10,000倍という価値の差をつけていいのでしょうか？

ここで、衣食住に困らない日本の家に生まれついた時点で既に運で差がついているのに、今更そんな事を考える意味があるのか？と言われると、それは確かにそうなのですが、これはナイーブな運をどう受け止めるべきかについての問題というより、 集団の間での利益配分の合理性、あるいは構成員がそれに納得できるか といった事が本質的な問題であると思っています。
というのも、この事を更に難しくしている要素に、非プログラマとのバランス があります。
もし、ここで述べたような常人のN倍のアウトプットをする優秀なプログラマだけが揃ってチームを構成するならば、少なくともチームの中では同等であって、そのチームの中で考える限りでは、難しい事はなくなります。そのチームが生み出した利益を等分すればよいので、常人との差を考える必要はありません。
しかし、ふつうの事業をするチームには、プログラマでない人もいます。簡単な例として、プログラマPさんと非プログラマNさんがチームを結成して仕事をすることを想像してみましょう。非プログラマには一般的な給与相場が決まっています。

Pさんは常人の10倍のスーパープログラマなので給与10倍、Nさんは一般的な職種なので給与1倍、このウェイトを踏まえて給与を設定しよう！
Pさんは3,000万、Nさんは300万で！

極端な例ですが、こうした考え方に耐えられるかどうか、ということです。
色々な事を考えましたが、私はどうしてもこうした考え方に耐えられませんでした。
また、チームを拡張していくとき、このようなチームに進んで入りたいか、という事も私にはわかりませんでした。Pさんがカリスマになれば、「そのようなスターのいるチームに進んで入りたい」となるのかもしれませんが、個人的にはどうしても気持ち悪さがありました。

もちろん、Pさんが並外れているならば、"多少"は多い給与でもよいと思います。しかし、じゃあそれが10倍なのかというと、何かが違うのではないか？と私は思わざるを得ませんでした。

ところで、この"チーム"の事業に価値があって、長期的に継続していく必要が生じたとします。Pさんは人間なので、いつか年老いて死にますが、Pさんが死んでも事業を継続するためには、プログラマを増やさないといけません。
（AIの発展によってプログラマは不要になるかもしれないのですが、仮に必要な状況が継続したとすれば、プログラマを増やすことが必要です。少なくとも、今を遡って30年前、あるいは60年前にはそうでした。）

このとき、うまくPさんと同程度のプログラマを採用できず、並のプログラマしか採用できなかったとします。そうすると、例によって単純な給与計算をすると新しいプログラマはPさんの1/10の給与になってしまいます。つまり、先ほどのNさんの場合と似たような問題が生じます。
じつは、この新しいプログラマについては、Nさんよりもさらに難しい問題が生じ得ます。Pさんが上述の状況で気持ちが悪くて300万しかもらっていなかったらどうでしょうか。事業の立ち上げの際、Pさんが自身の働きによって事業収支的に過不足がなくなるように顧客からの売上を設計していたら、本来3,000万必要な仕事の原価が300万円になるような設計をしていた事になります。つまり、根本的にPさん並のプログラマでないと事業継続ができないという事になってしまうのです。
これは深刻で、もしPさんの給与が600万でも、あるいは900万であっても1,500万であっても、仮に並のプログラマでは10人必要という事になると、3,000万が必要になって破綻してしまいます。Pさんには悪意はない、どころか事業の立ち上げ期における適正な給与をもらったというつもりなのに。

そうすると...
事業継続的な意味で、10倍の成果を挙げるプログラマには10倍の給与を支払うべきなのか？
その場合、何をもって成果が10倍だといえばいいのか？Pさん以外のプログラマを採用したときに、定量的に10倍ということを説明できるのか？
PさんはNさんと二人で立ち上げたチームにおいて事業に強い思い入れがあって、「事業として安定するまではとにかく身を削ってでも必死にやるんだ」と思って1倍の給与で事業を立ち上げたとしても、それは"よくないこと"なのか？でも、最初から3,000万取っていたら色々な意味で破綻してしまうのでは？
PさんとNさんの間の合意は？実際に3,000万を出すための原資もあるのか？
でも、事業が発展すると、同程度の働きに対して3,000万払う状況にしないとスケールしない？
Pさんは事業を立ち上げる時点で10倍の能力があると定量的な知識を持っていないといけないのか？

あーーーー、給与ってなにーーーー？

これが、私の思う「他人の10倍仕事ができる人に10倍の給与を支払うべきなのか問題」のほぼ全貌です。
さらに細かい議論もあるかもしれませんが、だいたいこのような構造の問題について、私はずっと悩んできました。

ここでいう10倍という数字は、あくまでも象徴であって厳密な数ではないです。また、「仕事ができる」という概念は一般に複雑であって、絶対的に数値に還元できるようなものではないとも思っています。同じ人がある状況であればよくワークし、別の状況ではワークしないといった事もあると思います。ただ、それは問題をさらに複雑にする要素だというだけで、ここで述べた問題を根本的に解決する方向に作用するようなものではないと思っています。

PさんとNさんの間で納得できる値付け
事業の立ち上げの時期に可能な値付け
その後にプログラマを追加採用したときに作業効率に実際に差があり得ること
そのような場合のプログラマへの値付け
プログラマを追加採用した後の最終的なPさんへの値付け
これらの事象を心の中でどう理解すると平穏になるのか

このような構造で発生する問題について、どう捉えれば継続的に発展していくようなチームを構成していく上で意味があると言えるのか。 ということです。

事業全体の売上は10倍に増やさないといけない...同じ速度での開発を望むならば

もしPさんに他の仕事があって、かつ並のプログラマしか採用ができなかったき、同じ速度で開発を続けようとしたら、"原価"が10倍になっても耐えられるようにしないといけません。並のプログラマの給与をダンピングせず、売上と"原価"の比率を維持するとしたら、つまり売上も10倍にしないといけない、ということです。
これは単純な算数の問題で、もし並のプログラマしか採用できなければ原価が10倍になることは避けようがなく（そうでなければプログラマ一人あたりの仕事が並ではない）、また売上と原価の比率を維持すると仮定すれば（そうでなければ普通は事業が成立しない）、原価が10倍なら売上も10倍、という計算になります。
Pさんの給与がどうあるべきかはさておき、事業全体の売上は10倍相当に増やさないといけません。

事業を立ち上げる時点では、Pさんはそんな事まで頭はまわらないかもしれないし、立ち上げ時点では"投資"として"原価"を抑えなければキャッシュフローが回らないかもしれません。しかし、将来的にこの"投資"を回収する、つまりPさんの給与にするかどうかはともかくとして、"原価"が10倍になる事を前提にしないといけません。

ただ、この結論については 同じ速度で開発を続けようとしたら という事が前提になっています。プログラマの場合、そのアウトプットが整っていれば、運用そのものにはプログラマが張り付く必要はありません。言い換えると、レバレッジが効く不労所得に近い"資産"を築く速度は、必ずしもずっと同じである必要はないということです。

ただ、何にしても、 アウトプットの量と原価の比としての費用効率は確実に下がる 事になります。
この構造は、優秀なプログラマと並のプログラマの間に差があるとすれば変えることができません。

従って、これまでに述べた話の時点で、諸問題について次のことがわかります。（あるいは、次のことが制約であると言えるかもしれません。）

事業の立ち上げの時期に可能な値付け
- 最初に大きく資金調達をしていなければ、投資的行為であると認識を持った上で、ある程度相場より安い値段をつけることは避けられない
- ただし、その後に追加採用をするときに、この時点での値付けを正と考えると失敗する
その後にプログラマを追加採用したときに作業効率に実際に差があり得ること
- 測定方法はともかく、多くの人がそのような事実について示唆している
そのような場合のプログラマへの値付け
- 普通のプログラマの生活の事を考えるならば、標準的な値付けにせざるを得ない

従って、Pさんの立場としては、事業の立ち上げ時期には投資だとはっきり思える給与で働くという認識を持つこと、つまり最終的に事業が回る段階では投資と思える給与水準では採用ができないので、チームを拡大したら費用効率が1/10になる事を想定して事業を計画しないといけない という事になります。

そうすると、残るのは以下のような問題です。

PさんとNさんの間で納得できる値付け
プログラマを追加採用した後の最終的なPさんへの値付け
これらの事象を心の中でどう理解すると平穏になるのか

これらの問題に対する直接的な答え、「ズバリ3倍にすればいい！」みたいなものはまだ得られていないのですが、ただ、心の平穏を得るためのメンタルモデルを構築することができました。

ということで、このメンタルモデルについて説明します！...というのを本来この記事で書きたかったのですが、導入部分が思ったよりも膨らんでしまったので記事を分割することにしました。

俺たちの戦いはこれからだ！

現時点では、以降で示す展開A・展開Bのような内容で書くことを検討しています。骨子だけで伝わる事もあるかなと思ってここに骨子を記載しました。

ちなみに、メンタルモデルを一言で言うと、「森」です。知識の森。といっても、図書館ではありません。図書館はむしろダム（形式化された知としての本＝水を蓄える）で、そうではなくて、構成要素の人々それぞれが知を蓄えるモデルです。

言いたいことをより短くまとめるなら、仕事をするには知の蓄積が不可欠で、知を蓄積するモデルはダムでなくて森で、給与は成果の評価だけでは本質的に足りないという話になります。

展開Aの骨子

「知」がどのように維持されるかということ。知を獲得することと、それを実践することの違い。
個人の成果の量だけが全てではないということ。
このあたりの事柄について、ようやく納得できるメンタルモデルを形成できたので、そのメンタルモデルについてまとめます。

一般に、一人でできる事には限界がある
- リソース量：例えば原発は一人で作れない
- 知：試してみたり経験したりして初めてわかるノウハウがあるが、一人でできる経験の時間は限られる
  - 個人の考え方によってはそもそも生じない・生じにくい知もある
  - 知には大きな価値があり、知がなければ個人の作業効率だけで解決できない事もある
ソフトウェア開発においてもこれが当てはまる
一方で作業効率には大きな個人差がある
- 作業効率の差の本質が何かは不明瞭だが、無為に作業をすると差がある事だけは明らか
- やり方で改善できる可能性は当然ある
知識による差は万人に作用する
知識の定着力にも個人差はあると思うが、作業効率と比較すると個々の定着力の個人差は少ない
知識は出来上がったものを解釈して身につける方法と、誰かから聞いて身につける方法がある
- ざっくり、自学と他者との会話（講義含む）
常識/知識を組織に蓄積するとき、その蓄積はダムというより森に近い
- ダムのように水（知識）を貯めるのではなく、森が保水するように木々＝人々とその間に知識が貯まる
個人の作業効率は現時点でのアウトプットには影響するが組織継続性と直接は関係ない
組織継続性は、アウトプットが少ない人も含め知の総体による
- 森をどれだけ構築できるかが組織継続性ということ
組織を継続するために、知が途絶えないように/拡張するように森を維持する
- 森の維持は必ずしもアウトプット向上を意味しない、別軸で必要な事
アウトプットは得意な人がやる
- 突然変異的に生じた人がそれまでの知をベースに大きな成果を出すことで事業が成立するかもしれない
森を維持する人にはアウトプットは必ずしも期待しない
- 事業の立ち上げの時期（作業効率が重要）を一旦脱したら、平均作業効率はある程度落ちてもよい
- あるいは、落ちる前提で事業を組み直す必要がある
知識を継承し続けることが重要で、単純な成果とは別に価値がある

めちゃくちゃ当たり前の事を書いているだけかもしれませんが、継続というのを成果とは別に明示的に評価しないといけない、という事を感じたのがあります。これは、"ある意味で"リソース効率とフロー効率の議論にも通じるところがあります。継続はリソース効率の観点での評価ではない、より正確に言えばリソース効率は常になんらかの作業をしているので100%であったとしても、それがアウトプット、あるいは個人としてはアウトカムにすらつながらない可能性があるが、それを良しとする、ということです。
少し言い方を変えると...事業を単純に継続するには金、キャッシュフローの成立≒成果が必須ですが、それだけではなくてリソースの維持が必要で、しかしリソースは突如湧き出るものではないし、何か施設を作っておけば貯められるようなものでもなくて、有機的に形成された集団が「森」として知を蓄えることが必要になる。そういうことでした。

展開Bの骨子

当初は展開Aを単独で書きたかったのですが、問題提起が膨らんでしまったので、問題提起に寄せるように別の展開Bも検討していました。

生存に対する貢献は成果だけではない
重要なタスクに対するフロー効率
- お金を生み出すのは必ずしもコードの量や難しさではない（多少の相関はあるかもしれないが）
個人のアウトプットが多くても最終的には「知」無しでは戦えない
運用のための知にはアウトプットほどの個人差はない
- 相対性理論の発見は難しいが、相対性理論の習得は比較すれば易しい
チームが価値を生む為には知を欠かせない
生産的なチームにはベースとなる常識が必要
- 入社試験で本来やるべきことは常識の確認
難しいタスクは優秀なプログラマが処理しつつ、普通のプログラマは知を維持しながら易しいが重要なタスクを処理する
これらにも"プログラマ個としての成果"は存在するが、その追求は本質的でない
チームとしての"最終的なアウトカム"がどうなるか で評価をする
- 維持の"成果"も、長期間のスパンで見たときに後から入ってきた優秀なプログラマが作業できる状態を維持した事によって優秀なプログラマが生産する成果（をてきとうに按分したもの）と捉えられる
  - ただし、個に按分することに本質的な意味はなく、チームとしての成果がすべて

こちらはチームを軸にコンパクトにまとめようとしたものですが、肝心のメンタルモデル（森）に直接的に言及していません。ただ、フロー効率と関連する話題への言及があり、近年しばしばリソース効率と引き換えになると話をされるフロー効率が求められる背景についてもこのメンタルモデルで説明できる（単にアウトプットが効率よく行えることではなくて、ビジネス的に重要な事をピンポイントに遂行するための体制が必要で、それはアウトプットの量ではなくて十分な知を持った人が多数いる事の方が効く）という部分においては展開Aで説明できていない事を説明しています。

これらを統合整理して、いい感じに書き直す必要があるなあと思ったので、一旦ここで切りました。続きの記事を書いたらここにリンクを貼ります。なるべくはやめに書きます。
→かきました：

結論じみたこと（結論ではない）

給与に関しては、総じて以下のような事を思っていて、少なくとも知の評価を抜いて考えることはできない、という程度の考えです。

作業量以外に、知を持っている・今後もたらす存在であるということそれだけで（他者に知識を共有できるなどの条件付きで）ある種の価値がある
どの知がどれぐらい役に立つかは、その知の内容に限らずチームの状態（人数など）からも影響を受けるので、適当な仮定を置いた上での確率分布等としてしか評価できない
- 個人の性質によって、その人自身が収集しやすい知に差がある
- 使いこなしてどれぐらい価値があるかは状況に依存する
  - rubyの知識を個人で集めている人の知は、pythonやphpで書いているコードそのもののノウハウには影響しないかもしれないが、ruby周辺で新しい実装や機能があった場合にキャッチアップできるメリットもある
    - このメリットについて、pythonを趣味でやる方がよいのかrubyを趣味でやる方がよいのか長期的に考えると、判定できない
    - ただ、好きなものをやった方が結果的に知として集積しやすいとは思う
      - しかし、それがプログラミング教育であったなら？PTA活動であったなら？サウナであったなら？
      - 役に立てることはできるが、役に立てるためにするものではないと思う

続きの記事のコメントに書きましたが、もともとこの記事たちを書き始めたのは、「営業など非開発のメンバーの知識が開発に対してどう影響するのかを分析していたこと」が大きく影響しています。非開発メンバーの実装貢献は0で、しかししばしば、機能について本質的な知見を提供し、サービスの価値を高めます。私は今日でちょうど6年、同じソフトウェアのコードを書いていて（HAPPY BIRTHDAY🎉）、実装については（少なくとも形式的には）全てのコードに目を通してきました。その立場で思うのは、コードに全く目を通していないメンバーがいなければ、今に至るまでの様々な知を得ることは決してできなかった、ということです。この6年の間、10を超えるコードベースを"立ち上げ"、また関わりましたが、今もサービスとして稼働しているのはそのうちの3つで、最終的にエンドユーザーが付く前に終わったものも、数年でサービス提供が終わったものもありました。それぞれについての私個人の働き方としては、多少は色があったとしても根本的に違うことはなくて、だいたいは同じ感度でコードを書いたつもりです。その結果には、ビジネスモデルとしての手離れの良さや、一顧客あたりの費用、提供する価値、需要の大きさなどもありますが、結果的にいま生き残っているサービスについては知が絶大な影響をもたらしたと思っています。
それが開発についても言えるのではないか、それによってN倍給与問題を心穏やかに考えられるようになるのでは、というのがこの記事を書き始めたきっかけでした。
（サービスを作り始めた時点で、結果的にどれぐらい私たちに知がなかったかという事は、どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論の記事に書いたとおりです）

私個人は、自分で新しい知を拾いに行くという事についてはめちゃくちゃ無頓着で、とにかく技術的にこれをやりたいみたいな事はほぼなかったですが、代わりに人の知を拾うという事にはおそらく謎の執念があって、今のサービスはそれによって"うまくやれている"部分も結構あると思っています。

今の時点で、仮に私が突然死んだとしても、細かい運用障害などを除けばサービス継続できるようになったので、とりあえず開発チームを名乗って問題ない状態になってきたかなと思っていますが、一方で身近に落ちてきた知を拾う執念を万人に引き継ぐのは難しく、知の共有という事に漠然と課題を感じたり、また今後新しい知を自分から拾いに行くような種類の執念をチームに加えていくにはどうすべきなのかという考えがありました。それについて、「作業量だけじゃない」という結論が見えたのが良かったなあと思っています。

給与の具体的な金額？そんな難しい事はわかりません、組織のルールに応じて 個別に相談して個別に結論を出しましょう！
もちろん承認する側は何らかの側面で平等性を考えるにしても、最終的には双方で納得できるか否かが全てで、それが契約なのだと思います。
笑ったツイートをはっておきます！（必ずしも個人としてこういう考え方だという事ではないです！！！）

補足

続きの記事を書くまでに少し時間がかかったので、その間に補足を書きました。
この記事については、私の思いもつかないような、あるいは真反対の立場からの全否定のような意見があったりすると、発見があるので嬉しいなあと思っています。

結局成果/仕事量ってなんなの

成果については、明確な定義を避けてぼかした書き方をしていました。というのは、基本的には成果は一つの軸で測定できるものではないし、何かの軸を挙げるとそれに対するハックや特殊な例によって議論が発散するかなと思ったからです。
この記事で雑に仕事量と呼んでいるものは、次のような量を測ったときに、相関があると（私には）思われる何らかの量です。

一定時間にこなせる同程度の粒度のissue
- レビュー指摘も含めた対応時間
同じ条件下で一定時間に書けるコードの平均
テトリス等のパズルを同じ条件で実装するのに必要な時間
障害事象の調査対応にかかる時間

これらが、冒頭のピープルウエアの実験やビル・ゲイツの発言とされる言葉の真意と一致するかは不明ですが、私の経験においては、これらはある程度の相関性があると思いました。個人差や得意不得意という事はありますが。

もちろん、必ずしもこうした点で測れるような能力を持つ人が常に優れた設計の知識やノウハウを持っているという訳ではないです。ただ、現実に問題になる事として、「Pさんが初期に1人分の給与でこなしていた事を、その後採用したプログラマに依頼しようとしたらコストがN倍になってしまう」 という事があります。これは、単純な作業としてPさんがこなしていた事が必要で、それは高度な設計で大幅に安く済ませることはできず（せいぜい半分とか）、本質的に当初の1人分がN人分（またはN/2人分）のコストになってしまう、というシチュエーションを想定しています。多くの人がそのシチュエーションを体験するかはわかりません。

これは、Pさん一人の問題や、その後の教育だけの問題ではありません。
プログラミング歴1年を切る人々が、私が関わった中で一般的なプログラミング歴10年や20年の人よりもずっと効率的かつ私としては読みやすいコードを書き、上述の様々な指標で測っていずれもN倍のパフォーマンスを出す、というような事を私は複数のケースで経験しました。誤解の無いように付け加えると、これらの事例においてはみんな真面目にコードを書いていて、少なくとも意図的にサボるような事はなかったです。また、全ての点においてプログラミング歴1年を切る人々が最初に上げてくるコードが上という事ではなく、だいたいの人では経験の不足によって（洗練されたように見えても）最後の詰めを仕損じるような事がありました。ただ、それの対応も含めてもN倍でした。

これは、私について「プログラミング歴10年や20年の人が、1年を切る人と同等のパフォーマンスを出せるようにする為に必要な教育や導入ができない」という事を示していると考えることもできて、つまりは私にある種の能力が無いという事を示していると思いますし、それを軸にして貢献量のようなものを測るとすれば、私の現在のパフォーマンスは高くないであろう、という事にもなります。ただ、私のそうしたある種のパフォーマンス/仕事量/成果に問題があるとしても、一旦は現実を受け入れる必要があります。

これまで、私は持ち前のネガティブ・ケイパビリティを駆使して、これらは不合理/説明できない事実として、いつか解決できたらいいが死ぬまで解決できないかもしれない、と思ってきました。しかし、ネガティブ・ケイパビリティに強くは依存せずに理解する、心の平穏を保つような考え方があるなあと思ったので、それについて続きの記事で書きすすめる予定です。

基本的には、以下のような結論だと思っています（再掲）

難しいタスクは優秀なプログラマが処理しつつ、普通のプログラマは知を維持しながら易しいが重要なタスクを処理する
これらにも"プログラマ個としての成果"は存在するが、その追求は本質的でない
チームとしての"最終的なアウトカム"がどうなるか で評価をする
- 維持の"成果"も、長期間のスパンで見たときに後から入ってきた優秀なプログラマが作業できる状態を維持した事によって優秀なプログラマが生産する成果（をてきとうに按分したもの）と捉えられる
  - ただし、個に按分することに本質的な意味はなく、チームとしての成果がすべて

10倍の仕事をすると、10倍の売上が立っているのでは？

これは、事業の立ち上げの時期とかに限ると、決してそんな事はないです。
例えば、資金調達しても事業を成立させられなかったという場合がしばしば生じますが、これにはプログラマが並の仕事をできなかった場合もあるものの、多くは並以上の仕事をしても事業が成立しなかった場合（＝1倍の売上が立たなかった場合）であると思います。
（受託開発などでない）自社事業のソフトウェア開発の場合、マネタイズと開発コスト発生タイミングは必ずずれているうえに、開発した時点で具体的に立つ売上を予測するのは一般には難しいです。
ただ、そうした売上予測の難しさとは無関係に、適正な"原価"を把握するため、Pさんまたは別の経営者は、事業を拡大するまでのタイミングのどこかで、その仕事を他の人や外注などで実現した場合にどれぐらいコストがかかるのかを検討する必要はあると思います。これは、心の平穏とかいうことではなくて、事業をスケールするために単純に投資費用を計算するために必要だからです。

ちなみに、これについてより難しい問題としては、ごく短期的に見てしまった場合には、Pさんの仕事が一見して非効率に見える場合すらあるという事があります。一つ前の節で述べた成果/仕事量に関する主張と一見逆の事を言っているようにも見えてしまうのですが、例えばサービスがスケールした場合の事を考えてサーバーを水平に増やせる設計を選ぶ人と、サービスがスケールした場合の事は一切考えずに単一サーバーでだけ動作するような設計を選ぶ人では、ごく短期的には後者がペイし、すこし短期的には（そして中期も長期も）前者がペイするというような事があります。
（上述の仕事量についての話は、主に同等の作業をする想定での話です。ちなみに、この作業が明確であれば知以外で差が出て、作業を自分で判断する場合には知でも差が出るという事は、知がチームの中でどのような役割を果たすかというヒントでもあると思いますが、詳しくはまた別で整理して述べます。）

なお、私は、もう存在しない過去の会社で、自分が実装する想定だったシステムのざっくりとした仕様を伝えて、一括見積で概算を取ったことがあります。全ての会社に同じように説明して、質問があった場合には個別にごく一部解答しましたが、結果は10社弱で、提示された見積を"比率"で言うと150〜1000で分布していました。中央値でたぶん400ぐらいだったと思います。
200の会社が技術的に一番良さそうな雰囲気で、そこに頼んでもよかったのですが、私はその見積を元に、インターンの人に作業を依頼して、実費で100で想定していた仕様までの実装をして、それを使ってギリギリ元を取れる程度には事業案件を成立させました。（ただ、そのサービスは案件手離れの割に利用料が安いというビジネス的な課題があって1年でサービスを畳んでいますが。別の記事で技術的負債についての実例について書きましたが、私が携わったというか作り出したサービスには技術的負債にすらなれなかったものがいくつもありました。）

この体験も、N倍の経験の一つになっています。ちなみに、当時のプログラマインターンの募集時給は試用期間含め2,000円〜2,500円だったので、不当にダンピングをしたうちには多分入らないかなと思います。（ただ、それでも最終的な費用感からすると相場より安く済んでいて不当なのではないかと言われると、難しく思うことはあります。単純にビジネスとしては、相応の値段で金を動かした方が"正しい"という考え方もあります。実績はないし詰めも甘いが、そこを補えばN倍という性質を活かしたのか搾取したのか、私にはまだ答えはありません。個人的に一番申し訳ないのは、その能力と経験を、結果的に事業継続の見極めみたいな事で"使い捨て"にしてしまったということです。こういうことは、常にずーっと考えている訳ではありませんが、しかし自分を振り返ると必ず思い返されます。これを繰り返さずに、真に関わる全員にとって価値があり、他の道を歩むよりも意味があったと10年後、20年後、あるいは死ぬ前に胸を張って言えるのはどういう在り方か？ということの答えを、この記事でいう"心の平穏"の先に求めています。）

努力が支配的な要素か否かについて

様々な物事、例えば将棋や囲碁においては、そのプロとしての強さはIQとは無相関、ないし無相関に近い状態であると言われていて、（何かしらの先天的な要素の否定はされないにしても）個人が積み上げた時間とその質、いわゆる努力が支配的な要素であると言われています。
（プログラミングが先天的な要素と関係するかしないかわかりませんが）何にしても世界のトップレベルに至るまで、一流としての研鑽を重ねて突き抜けるならば、それは紛れもなく努力であると思いますが、私が日常生活で出会うレベルでは、ことソフトウェア開発のある種の作業量に関しては、努力よりももっと別の要素の影響の方が大きいと思いました。
これが、例えば一個人としてある領域を限界までやる、いわゆる"極める"という事と比較すると、ほんの入口の入口の議論にすぎないというのは、全く同意します。私の水準が低いという事であれば、それはそうなのだと思います。こうした背景を特に記載していた訳ではなかったので、この記事を読んで憤慨するような気持ちが生まれたとしたら、申し訳ありませんでした。エジソンも99%の汗と1%のひらめきと言っていますね。
前節で述べたようにインターンで格安にプロトタイプを作って原価割れしない程度で事業可能性を評価して結果として事業を潰すことと、仮に別の道を歩んだ私がいて10年ひたすら何事かを極めようとして研鑽を重ねた上でインターンを指導することと、どちらが価値のある事なのだと言われたら、私には返す言葉もありません。こんな非生産的なことを書いている暇があったら研鑽を重ねろ、という指摘はその通りかもしれません。

ただ、世の中の人の全てがそのような研鑽にストイックに生きているわけではなく、むしろ多くの人はそのようにストイックには生きていないし、ストイックでなくても生きられる世の中であるべきと私は思います。また、私としては常に肯定をしてはいませんが、ある種の工学においては、むしろストイックさは前提とせず、エラーの多い一般的な人間を前提として仕事や作業を設計すべきである、という考え方もあります。実際、ある種のアートをテクノロジーで置き換えていくというのは、そういう一面もあると思います。（個人的には置き換えより共同・共創のような考えが良いと思っていますが、世の中にはそのような考え方もあるということです。）

そのような前提で、でもキャッシュフローを成立させないといけない事業においては、単純に作業量を金額で評価したくなる場面がいくつもあって、それをどうしたらいいのか？ということがずっと私の中で引っかかっていました。
一つの結論が、経営としては全体の予算は考えないといけないが、個に還元して求めることは本質的に無意味な可能性があり、また単純な作業効率によらず知を維持拡張する人が居る方がチームとしては効率が良くなるので、そのような意味で個人の効率によらずチームとして価値を高めるべき。知を維持拡張することの"価値"をもっと重く見れば、必ずしも単純な（マネジメント等も含む）貢献の多寡が給与を支配するものではない。
という事なのだと思っています。