スーパープログラマーは生産性がスーパーなわけではない

スーパーコーダーならともかく。でもそれってツールを使いこなす技量と大差ない。

ということを上げているんだけど、なんでこれが理由になるのか分からない。「スーパープログラマーでもいつも生産性が高いとは限らない」ことの理由としてならわかるけど、体制が変わらない/変えられないことの理由としてはさっぱり分からない。誰か解説して。

Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記

ようはあなたが望む体制はスーパープログラマーに選ばれないってことじゃないの？僕はスーパーじゃないからわからないけど。

もとのエントリは単に「個人の能力差はとても大きいのにそれを無視して属人性をなくそうとするのは間違ってる」というだけの話。

Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記

という話が間違っていると思うからみんな反応するんだと思うよ。
そもそもの前提として、業界は今現存する(あるいは将来生まれる)スーパープログラマーで全ての需要が満たされるというものが成立しないと、属人性を排除して均質化および全体の質の向上を図るという戦略が間違っているとはいえないから。

なんだろう、コンプレックスでもあるんかな。

Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記

僕はともかくdankogaiにそれいっちゃいかんだろｗｗｗ

これとかそうだよね。もとの趣旨を外してコーディングだけに限定している。個人能力差が大きいことや属人性のことは、別にコーディングに限った話じゃないことぐらいわかるだろうに。

Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記

それは捉え方が間違っている。業務要件だってテストだって、個人能力によって効率は違う。でもそんなの誤差だというぐらいの物量の前でこちらに人数がいなくてどうするんだって話。小規模プロジェクトしか経験ないのかなあ。

こういう人ほどプロジェクトに人員を投入したがるんだろうなあ。『搾り出す』とか、なんでそんな言葉を選ぶかね。普通に、生産性の高い人の能力を引き出す、でいいじゃん

Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記

オリンピック選手のたとえをするというのは極端な例だったんだろうけど、その話をした以上はスーパープログラマーのレベルを世界を争うレベルと規定しているという前提だと思って当然です。で、搾り出すと引き出すを言い換えたところでやろうとしていること変わるの？単なるサポートなら普通大きいプロジェクトはPMはじめとした管理専門体制がひかれているし、会社の雑務は管理部門とか営業にお願いしたりするよね。特別チーム北島を作らなきゃいかんようなプロジェクトがあるんかねえ。
非現実的な提案に見えるのは、そういうところ。雑務に煩わされない程度なら今でも十分実現可能だし、実現されている。

月70万の人材より月140万の人材が4倍5倍の生産性を出すような世界で、何言ってるんだか意味不明ですよ。

Re: 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 - kなんとかの日記

30倍からだいぶ縮まりましたな。で、その生産性ってどういうもの？コードの量？コードの質？それとも…なんだろう。

昔話

一昔前の、たとえばインターネットバンキングの話をすると、突貫工事、毎日バグ対応リリース当たり前、作業手順もへったくれもなく、ただただ個人スキル(パイオニア的な人たちの集まりでかなり高い)に依存した、昼も夜も現場で生活しています状態のプロジェクトでかなり物理量的な生産性も高いし新しい仕掛けが日々生まれていったのだけど、当然穴は沢山ありました。一時期猛威を振るったoffice氏の、ほとんど実効力のないセキュリティーホールの指摘に鷹揚に対応していたり。
僕がこの業界に入ったころはそういう風潮の最後期。当時のプロジェクトは本当にスピード感があった。工数も今考えるとありえないほど安い。出来る人がそれなりに集まって、それなりの設計をしていなかったら終わっていただろう。もちろん、全部が全部そういうチームばかりではなく、毎日のように起きるバグに泣かされているところもあった。でも、生産性のいいチームが楽勝だったかというと、もともとぎりぎりなわけで。つらいチームが死ぬほどつらいだけだった。
その後どうなったかというと、ネットバンキングはもはや試行サービスではなく、ATMと同様の重大なインフラであり、金融監督庁に監督されている。重大な障害が起きると呼び出され、立ち入り検査され、頭取が怒られ、誰かの首が飛ぶ。テストの工数も、リリースの手順も、必要な期間も、飛躍的に増大した。特にテスト工数はもはや全体の工数の80%を占めるといってよい。膨大なエビデンスを検証した証を残しておかないと障害が起きたときに体制の不備を指摘され、全コード見直しだとかそういう指示を食らうことになる。
その中で、スーパープログラマーの出来ることは少しでも質のよいコードを、それをうまく使う手順とともに、スーパーじゃない人のために提供することだ。そして、そのことによって全体のコードの均質化を図ることが、ソフトウェア工学が目指すものの一つだろう。
引き合いに出すのもなんだけど、はてなくらいの不具合発生レベルでインターネットバンキング作ったら銀行潰れる。
出来る人の存在によって、軽減されるのは、量ではなく質。もちろん、すばらしい設計によってコードの量が減ることはある。けれども、10個の分岐が共通ロジックに収められようが、ITのケースは変わらない。UT＜ITの状態では、無理に共通化したロジックの変更により障害対応のテスト工数が跳ね上がることもある。
僕の体験として。
当初800人月くらいの見積もりを、機能を削ったといえ500人月くらいでやったのはたいしたものだと思う。多分、スーパーほどじゃなくても、平均的な人よりかなり生産性…ではなく、設計力のあるプログラマーがリーダーを張っていたと思う。そういうプロジェクトも経験したうえで、スーパープログラマー雇えば、すごい工数減るじゃんと思う人はあんまりいないと思う。