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

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

技術的ポピュリズムの成れ果て 2

「因果ダイアグラム」の効用

「ゼロ情シス」となっている様なシステムでも、「因果ダイアグラム」が無くても、
下記の様な質問ー回答が得られるAIが有れば十分です*1

  1. Windowsで、Rust言語で、Hello World!!!を出すプログラムをデバッグしたい。
  2. Rustツールチェーンを忘れて、エラーメッセージが出た
  3. WinLibs(winget経由)が入っているか調べます。Runボタン押下
  4. ...
  5. CodeLLDBが入っているか調べます。Runボタン押下
  6. ...
  7. などなど

をRust言語に関してはゼロ知識の私でも、どんどん推し進める事が出来、非常にありがたかったですが、

では、何故この様な事が出来るのでしょうか? それは、

  • 知識が体系化されていて、
  • 資料が大量に公開されている

からだと思います。しかし(会社とかの)私的なシステムではその様な体系化や公開は無理だと思います。

それに対し、「因果ダイアグラム」は、

  • その様なAI程では無いが、
  • 最小限の知識となり得る

と思います。

上記の様な回答をしてくれるAIが有れば良いのでしょうけれど、私的なシステムでは無理です。

 

 

(当時の)「現時点の」人間にとっての利得

  • プログラム(関数)のみの視点(地を這うもののの視点)のみで良く
  • 「因果ダイアグラム」の視点(空を飛ぶものの視点)が不要だ

としたのは、それに利益が有ったからだと思います。

特に本邦では、(ポピュリズム的)IT普及とバブルが重なった事で、世界に類を見ないねじれが起きて、さらにそれが「現時点の」人間にとっての利得になったと思われます。

それは、

  • 受注側が「因果ダイアログ」等で示すべき、そのシステムの情報を独占出来、競合に奪われない様にする
  • 発注側が過去の経緯に囚われない、すきな機能追加を安価に出せる

事だったと思います。

  • 次世代の人間にとってののり代を奪う事になり、
  • 「ゼロ情シス」となる

事は、その帰着です。

そして、多分、その事を分かっていた人でも、

  • (自分たちの給料は、バブルでもそれほど無い代わりに)億単位のプロジェクトなど、月替わりで初めても全く痛痒が無い
  • ダメならまたやれば良い

と思っていたのだと思います。

 

 

海外に出す利得

海外にソフトウェア開発を出しても、最終的には大して安くない様ですが、それでも出すのは、

  • 「技術的ポピュリズム」が通用しない。全ての情報を連携しないと、なにも始まらない。
  • 「因果ダイアグラム」の上限方向の根本を変更すれば、なーなーで済まず、全ての実費を請求されるので、「技術的財政規律」が保たれる

事が大きいと思います。

それにより、開発に携われない本邦の若者は残念な事になりますが、「因果ダイアグラム」の維持を生業とするなら、それはそれで有りかも知れません。

 

 

結論

これからも「技術的ポピュリズムの成れ果て」の物語の帰着により、プログラミングが嫌いになる人は存在し続けることでしょう。

 

 

*1:ただ、下記の様な質問ー回答は、そもそも「因果ダイアグラム」を作成出来る資料が整っているからなので、その辺は、「誤魔化した説明」になりますので、ご留意ください。

技術的ポピュリズムの成れ果て 1

どの様な話?

Youtubeで、

  • 民主化した国で、財政規律の観点で有り得ない事をし、
  • 非常に豊かになったが、財源は全て借金で、
  • 次世代の人間ののり代が無くなった

という話題について視聴しました。ポピュリズムです。

これの「技術的」版が有るのでは無いか? というのが、この話の主眼です。

そして、その成れ果てが、

  • 次世代の人間が寄り付かなくなった、
  • 「ゼロ情シス」(IT部門の「ひとり情シス」化を他人事にしてよいのか、中堅企業より大企業が深刻に 木村 岳史 日経クロステック/日経コンピュータ

では無いかというのが主張です。

 

 

いつ民主化したのか?

私もそうでしたが、コボラーはありとあらゆる非難を受けましたが、

  • その中に、「技術的ポピュリズム」と言うべき運動が含まれ、
  • 「技術的財政規律」の観点で有り得ない事をし、
  • より良く、より安くなったが、財源は全て「技術的飛ばし」で、
  • 「ゼロ情シス」となった

部分が、かなりの割合で含まれていた可能性が有ります。

 

 

第一に何が問題だったのか?

  • プログラム言語は、呼ばれる側がプラガブル(関数)で、呼ぶ側はそうでは無く、
  • 呼ぶ側は、いわゆる「第一級オブジェクト(Wikipedia 日本語版)」にならないのが、過去からの事実

なのに、

  • 「依存性逆転の原則(dependency inversion principle)」で初めてそうなり、
  • 呼ばれる側がプラガブル(関数)とするのはより有利だ

とした事が、第一の貢献となると思います。

  • 呼ばれる側のみがプラガブル(関数)なのは、
  • 当初よりの弱点であり、
  • それを推し進める事は、現時点の人間にとっては作りやすく有利かも知れなかったが、
  • 次世代の人間にとってののり代を奪う事になり、
  • 「ゼロ情シス」となった

となると思います。

 

 

どんな「技術的財政規律」を歪めたのか?

  • プログラムだけで因果関係を全て書ける

と思った事だと思います。

  • プログラムだけでは呼ばれる側の事しか書けず、
  • 呼ぶ側の事を書くには、因果ダイアログか、それと同等の何かの記述が必要

なのに、そうせず、

  • 現時点の人間にとっては、より作りやすく有利になったが、
  • その良さは、すべて「技術的飛ばし」が原因だった

のです。

 

 

何故、コボラーは非難されたか?

「技術的MMTに抗ったからだと思います。

  • これからはサービスだ、とか言って、
  • (現時点の人間にとって)より良くした成れ果てが
  • 「ゼロ情シス」で、
  • コボラーで無い)誰かが始めた(広めた)物語

なので、その辺は過つべきでは無いと思います。

 

 

結論

これからも「技術的ポピュリズムの成れ果て」の物語の帰着により、プログラミングが嫌いになる人は存在し続けることでしょう。

アジリティの対価 2

CAP定理のまね

CAP定理(Wikipedia 日本語版)では、

  • 分散コンピュータシステムのマシン間の情報複製に関する定理。
  • ノード間のデータ複製において、同時に次の3つの保証を提供することはできない
  • 1. 一貫性・2. 可用性・3. 分断耐性

という定理が有るそうですが、それのまねをして見ようと思います。

 

 

それは、

  • 1. インターフェース固定2. 拡張に対する解放3. 因果ダイアグラム保持

となると思います。CAP定理より、QCDF(Wikipedia 日本語版)の方が近いかも知れません。それは、

  • 1. 品質・2. 価格・3. 納期や入手性・4. 柔軟性

です。

また、CLEAN(ソフトウェア品質 Wikipedia 日本語版)というのも有るそうで、

ですが、コストを度外視していると思います。

 

 

何で「因果ダイアグラム保持」出てくるのか?

因果ダイアグラムを保持しないと、いくらでも下請けから絞れるからです。QCDFの

  • 2. 価格

に相当すると思います。

  • 要求の変更はたとえ開発の後期であっても歓迎します。
    変化を味方につけることによって、お客様の競争力を引き上げます。

という特性は、「因果ダイアグラム保持」の否定により成立し、それにより、

  • 1. インターフェース固定
  • 2. 拡張に対する解放

の両方を満たす事が可能になります。定額で、いくらでも働かせる事が出来るかです。

 

 

インターフェース固定と、拡張に対する解放は対立するのか?

すると思います。インターフェースを固定してこそ、

  • ずっと使える自動テスト

が書けるので有り、拡張にたいする解放は、それを書く事の否定です。

モダンな考え方の中にも、すくみが内在されていた訳です。

逆に、anyの多用を許容する場面では、ずっと使える自動テストは書けないと思います。

 

 

結論

これからも「アジリティの対価」が十分で無い事で、プログラミングが嫌いになる人は存在し続けることでしょう。

アジリティの対価 1

どの様な話?

アジャイルソフトウェア宣言(The Agile Manifesto) で、

特に、

  • 要求の変更はたとえ開発の後期であっても歓迎します。
    変化を味方につけることによって、お客様の競争力を引き上げます。

というのは虫が良すぎるのでは無いか? という記事を見ました。

何故でしょうか?

 

 

結論

因果ダイアグラムを書いていないからだと思います。

  • 要求の変更因果の変更
  • 少しの原因の変更で、結果が大幅に変わり得る事を因果ダイアグラムは示す

のです。

これからも「アジリティの対価」が十分で無い事で、プログラミングが嫌いになる人は存在し続けることでしょう。