嫌われプログラミングの代弁者

「何で頭ごなしに嫌う人間が居るのか」を色々考える

SIerの本質 2

コボラーと中間リーダー

コボラーは、

  • 月数百億円のハードウェア使用料の
  • おまけとして、
  • プログラムを作っていたので、

それほど組織論にこだわっていなかったと思います。

その上、汎用機が出来ていた事(機能)は、現在と比べて千万分の一でしか無く、プログラム自体の構成が、単純な組織を規定していたと言っても過言では無いと思います。

そして、パソコンの大きい物(PCサーバー)でRDBRAIDが出来る様になって
以降(オープン化)コボラーは、

  • リーダー(最終決定権を持つ)
  • 中間リーダー(最終決定権を持たず、正しさを忖度する権利を持つ)
  • プログラマー(情報の取捨選択、正しさの忖度を求められない)

3番目にされてました。
理由は、

  • リーダー系の業務は、プログラミングとは別体系で、それを学んでいない
    コボラーは、該当しない

為だったと理解しています。

ですので私は、リーダー(特に中間リーダー)に対して斟酌する立場に有りません。

ただ、オープン化以降、20年近く中間リーダーと接していて、良い印象も沢山持ってはいます。

 

中間リーダーは

中間リーダーは、

  • 最終決定権を持たず、忖度するのみなので、
  • 構造的にコンサバティブに

なる傾向があります。

基本(最終決定権を持つ)リーダーは、中間リーダーの決定に異を唱えることはありません。それをするとは、即、その中間リーダーの追放と同義です。

しかし、忖度のみで正しさを維持するには、

  • 理念のみのアイディアでは足りず、
  • 解の存在が明らかなアイディアで無いと

受け入れてはなりません。

解の存在が未確定な(リアクティブプログラミングとか、その派生のFRPとか)アイディアを推進したがる人間とは、犬猿の仲となると思います。

また、中間リーダーは剛腕である必要は無く、柔軟性が求められると思います。

 

逆に

逆に自動テストというアイディアを推進したがる人間とは、相性が良いと思います。

  • 自動テストは
  • 解の存在を明らかにする

からです。

もちろん、テストピラミッドの頂点側(UIテスト側)では、解の存在を、

  • テストでは無く
  • フレームワーク(リアクティブプログラミングがその語源となったReactなど)によって

包括的に明らかにした方がコストは下がるとは思いますが、

中間リーダーの「正しさを忖度する」権能が、ユニットテストなどをプログラマーに作らせるという目的と、うまく合致するのでは無いかと期待出来ると思います。

 

ただし、

ただし、中間リーダーは基本的に、

  • 一種の中間管理職であり、
  • アジャイルさからは確実に遠のく

と思います。自動テストは、(私の私見では)プログラマーで無い別組織に書かせた方が吉の様に思えてなりません。

プログラマーに書かせると良いというのは、

  • プログラムを書いているまさにほぼ同時に書く事で、
  • 経緯などを細大漏らさずに書く事が期待出来る

からだと思いますが、別組織が同時に(あるいはプログラムが上がった直後に)書いても良い(第三者目線が入るので、より良くなる可能性も有り)と思います。

 

結論

これからも「SIerの本質」の現れにより、プログラミング技術、ひいてはソフトウェアそのものが嫌いになる人は存在し続けることでしょう。

 

SIerの本質 1

どの様な話?

SIerは嫌われており、内製は素晴らしいとされております。

ただ、

のでは無いかと思います。

プログラマー5人で開発出来ていたシステムが、プログラマーの分担範囲が変わり、生産性が20分の1となった為、プログラマー100人体制になった場合、

どんなにSIerを忌避しても、SIerの本質は現れてしまう、という論調です。

 

SIer誕生

プログラマー5人体制程度なら、

  • 最終決定権(何が正しいか)を持ち
  • 情報を全部部下に渡す(取捨選択する暇が無い)

リーダーと、

  • 最終決定権(何が正しいか)は持たず
  • 情報の取捨選択が求められ、正しさを有る程度忖度する権利を持ち、
  • (最終決定権を持つ)リーダーに質問出来る

メンバー(プログラマー)で済むと思いますが、

100人体制になってしまうと、

の階層に絶対になると思います。

そして、3番目の階層(プログラマー"専業")が出来た時点で、(実質的に)SIerが誕生すると思います。SIerを雇わなくても、です。

3番目の階層の特徴として、

  • 情報の取捨選択、正しさの忖度は求められない、してはいけない
  • (最終決定権を持つ)リーダーに質問出来ない

となると思います。

 

SIerの本質

とにかくリーダーをパンクさせない事が大規模体制の要諦となります。

しかも、さまざまな情報が遮断されている3番目の階層のプログラマーに、

ので、中間リーダーの

  • 情報の取捨選択、正しさの忖度

の権能は本当に重大となります。

中間リーダーのこの権能こそが、SIerの本質で有り、SIerという会社である事が本質では有りません

つまり、

  • 内製であっても、
  • 中間リーダーのこの権能が発揮されるべき規模になったら
  • SIerの本質は現れてしまう

という宿命が有るという事です。

 

DXでの概念実証の成功とその後の失敗

DXでの概念実証(PoC)の成功とその後の失敗は、規模の拡大によるものだと考えます。特にプログラマーにテストを書かせると、規模が急速に拡大するので、

その後の失敗を助長するものだと思います。

 

結論

これからも「SIerの本質」の現れにより、プログラミング技術、ひいてはソフトウェアそのものが嫌いになる人は存在し続けることでしょう。

 

第一原理計算? 2

実際に因果推論をして見ると

仕事として手が動くプログラマー全人口の1万人に1人だと想定すると ー(1)

はじめにテストを書け、仕事として手が動くプログラマー全人口の100万人に1人では無いかと推察します ー(2)

もしそうなら、

  • (1)のプログラマーを私が使って私の為に仕事をしてもらえる確率は0では無いと思われ、
    企業や公共団体が(1)のプログラマーを使ってそれらの為に仕事をしてもらえ、そこのサービスを通じて私の為になる確率は100%と言っていい、

と思いますが、

  • (2)のプログラマーが私の為に仕事をしてくれる確率は0(殆ど0の確率が、何段階も重なって初めてそうなる)でしょうし、
    企業や公共団体が(2)のプログラマーを使える(間接的に私もそのサービスを使える)のも、少ない確率となる、

と思います。

(なんでも有り得る)可能世界では、

  • はじめにテストを書け、仕事として手が動くプログラマーが登場する

道筋も有るかも知れませんが、確率まで加味して考えると、現実ではお目にかかる事は、まず無いのでは無いかと愚考します。

 

 

なんでそう思ったのか?

なんで、仕事として手が動くプログラマー1/100 が、はじめにテストを書け、かつ仕事として手が動くプログラマーになると推察したかと言うと、

(はじめの内ではテスト(=モデル)など気にしない、在来工法の)
仕事として手が動くプログラマー(私もそうだったと思いますが)は、

  • はじめの内は「動くプログラムの定石」に従い作る
  • なぜなら、動くプログラムを作るのが絶対条件で、動く定石から外れた所には解が無い為。
  • 特に初めの内は、モデルなんてどうでも良い、計算の正しさもどうでも良い

からで、

  • はじめの内から、テスト(=モデル)を気にする事が出来、

かつ、

  • 動くプログラムを作れる、手が動く

となると、それ位希少になると思ったからです。

 

 

「はじめの内」と言う条件を取っ払えば...

もちろん、在来工法で目鼻を付けてからテストを書いても良いなら、かなりの、在来工法のプログラマーでも、テストは書けると思いますが、

それだと、

  • 仕様制定の経緯から入らないと、テストにたどりつかない
  • (その様な有る意味 "よそごと"もやっていると)生産性(ステップ換算)は1/10 程度にまで落ちるだろう
  • (テストを作る手間で)生産性(テスト以外のプログラムのステップ換算)は、さらに1/2 程度になるだろう
  • 既存RDBシステムと切り離して使える、それを模倣出来る性能のモックを作るとすると、それだけで大仕事になる
  • プログラマーと兼ね合いで仕様制定にも絡むのだから、もらえる金額は多くしてもらわないと、割が合わない
  • つまり、プログラマーの人数が20倍以上(高性能モック作成は別途)必要で、費用も割高になる。

となる事が予想されます。

プログラマーはただでさえ希少なのに、(「はじめの内」では無いにせよ)テスト書くとなると、(希少性は大丈夫だとしても)費用は上がる様に思えてなりません。

プログラマーがテストを書けと言うなら、そういう事も考慮すべきだと思います。

 

 

結論

費用をかければ良くなる!

 

 

第一原理計算? 1

どの様な話?

逆に、

  • 現行システムは「曲げられない」
  • どんなに理解し易くなっても!

だと思います。

  • 保守フェーズ(「曲げられない」)で、曲げ(≡分かり易さ)が通じない

のはそのせいだと思います。

そして、曲げられない場合に何をやるかというと、

  • 因果推論
  • 具体的には調査分析

だと思います。すなわち、

  • 因果推論こそが、プログラミング手法の第一原理計算

なのでは無いでしょうか? 第一原理計算は一般に、

  • 難しい

のが通例で、一般に調査分析が煩瑣なのもこの主張の傍証となるのでは無いでしょうか?

 

曲げられる(完全新規開発、既存要件無しの)場合

曲げられる場合には、(針の穴を通す様な細心の配慮の元)SOLID原則を満たす様に作ることも可能でしょう。

しかし曲げられない場合には、まず無理だと思います。

なぜならば、

  • (非常に多数から引用され、「曲げられない」原因となっている)因果の元の方が、
  • SOLID原則を満たす様になっていなかった
  • そこから直すとなると、完全新規開発、既存要件無しとなってしまう

からだと思います。SOLID原則適用の困難さも、第一原理に立ち返って見れば明白なのでは無いでしょうか?

 

技術的負債の返済の技法

技術的負債の返済の技法も、

  • 粗々でかなりの了解は取れている(と私は思う)

けれども、その第一原理計算はやはり、因果推論なのでは無いでしょうか?

第一原理が有ればこそ、粗々にせよかなりの了解が取れると言う物では無いでしょうか?

 

結論

第一原理計算は難しいので、それを持ち出さないといけない場合、
これからも「第一原理計算?」の突破の困難さにより、プログラミングが嫌いになる人が存在し続けることを、理論的に証明出来る日が来るかも知れません。