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

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

V字モデルのおかしさ 2

合う・合わない

ソフトウェア開発は、時空を扱う自然科学とは違う系統の科学で、

  • 「きっと起こる」と信じるような観念、すなわち「信念」こそが、
  • ソフトウェア開発(コーディング開始後の相転移としての因果ダイアグラム)の本質だ

とすべきで、ウィトゲンシュタイン好みの名前の「一義的で明確」さを優先すべきであるか、私は非常に疑問に思います。

自然科学が(観測機器の未熟により)「新しもの好きのやる、あやふやなモノ」とされていた頃に主流だった哲学こそ、ソフトウェア開発に合う、取り上げるべきモノだと思います。

マッハやウィトゲンシュタインの哲学は、時空を扱う自然科学には向かいこそすれ、ソフトウェア開発の科学とは縁もゆかりも無い様に思います。

 

ただし、

ただし「信念」で全てが何とかなる世界では、そこではそこで、

  • 相容れない「信念」のどれかに統一出来るとは限らない
  • むしろ、実用的ソフトウェアでは、出来ない方が普通

では無いかと思います。「信念」が全てを支配する世界では、それによる争いが生まれるのは道理です。

 

因果ダイアグラムの上限付近の、

  • (要求分析の)どうとでも取れる『原因』から導き出される
  • 『結果』としての相容れない「信念」たちが、
  • 下限方向に向かっての、詳細化された新たな『原因』として鼎立(足の数は3本とは限らない)し、
  • 矛盾含みのまま、新たな『結果』をもたらし続ける

のが、ベクトルV字モデルでのソフトウェア開発となるに違いありません。*1

 

それにより、

それにより、当然、

  • 相容れない「信念」の帰着である所の負債が
  • 必ず生じる
  • 負債無しのソフトウェアシステムは動かない

となると思います。

  • 相容れない「信念」を統一すると、
  • 上限側の要求を満たせなくなる

のであるならば、負債を一掃すれば動かなくなって当然です。

 

誰がベクトルV字モデルでの因果ダイアグラムを書くのか?

設計側の人間だと思います。プロのプログラマーなら、自分が書いたプログラムが、

  • 何を『原因』としているのか?

明確に意識しているはずです。

それを吸い上げる文書が(今まで)無かっただけで、(本当に書けるのか不明な、永続的に使えて、変化にも対応する)テストを書けと言われるより、
よほど書きやすと思います。(もちろん別途料金は取られるとは思います。)

 

それらを集約して、因果ダイアグラムにするのは、当然設計側の人間になると思います。

始原の粒子が相互作用を起こして観測され、この世界が始まったのかも知れませんが、仕様がコーディングで観測され、相転移を起こして因果ダイアグラムになるのは自然だと思います。

 

結論

ベクトルV字モデルが一般化するまでは、これからも「V字モデルのおかしさ」でプログラミングが嫌いになる人は存在し続けることでしょう。 

 

 

 

*1:なお、因果ダイアグラムはコーディングの末、出来上がるモノで、「因果ダイアログを見てコーディングをする」のは無理だと思います。その辺は誤解なきよう! 単体テストより後の、各テストの為には使えると思います。

V字モデルのおかしさ 1

どの様な話?

V字モデル(Vモデル Wikipedia 日本語版)について前から(特にテストの辺りで)おかしいと思っていましたが、

何がおかしいか、理解出来つつある様に思えて来ました。

 

V字モデルでは、

と言うモデルですが、

確かに、V字の左側(コーディング開始前)は、その様な荒い切り方(分析・設計の各段階)以外にあり得ないでしょうけれど、

V字の右側(コーディング開始後)には、果たしてそれで事足りるのか? と言う問題意識が生じるはずです。

 

コーディング開始後

このブログの初めの方で「箇条書きが書けない 1」と言う記事を書きましたが、

  • (感覚的に言って)レベル20の項目や、レベル50の項目が それなりの重要性をもって現れる。
  • しかしExcelでもWordでも、専用のWBSのツールでも、 レベル50はもちろん、レベル20の項目でも書き込めない。

と言うのが趣旨でした。

これは現役当時の偽らざる実感でしたが、なぜなのかは名状し難い問題でした。

 

これを(閉じた、束構造の)因果ダイアログを使って名状する事が可能では無いかと思えて来たのです。

つまり、

  • コーディング開始前には、要求分析・基本設計・機能設計・詳細設計程度の数のレベル分けからスタートする事は、合理的で有り、仕方の無い事かも知れないが、
  • それら(この場合は4レベル)が、コーディングにより実際の動作対象として観測されると、多数レベル*1の因果ダイアログ*2に細分化する

のでは無いかと言うのです。

プログラミングの実務を担当していた私がいくら、箇条書きが書けない(レベルが多すぎる)と話しても、
プログラミングの実務を担当していない上司には届かない(4レベルが妥当に見える)と言う話は、これが原因だった可能性があります。

 

V字モデルのテストの真のあるべき姿

そして、

  • それらをコーディング前の階梯(例えば4レベル)のまま、「対応するレベルのテスト」として扱うと、
  • せっかく多数レベルの因果ダイアグラムの形に現実化した知見を全部捨てることになり、
  • 複数の「原因ー結果」が連なった隔靴掻痒的なテストになってしまう。(まさに因果推論・統計学的な『交叉』を地で行く様)

(のでは無いか)と言う言い方です。

つまり、

  • 要求分析・基本設計・機能設計・詳細設計程度の数のレベル分けは、コーディング開始便法で有り
  • テストでは、コーディング開始に得られた、因果ダイアログの階梯にしたがった、より現実的なレベル分けに対応するテストをするべきでは無いか?

と言うのが、私のV字モデルに対する疑念です。
(ベクトルのアルファベット表示の様な、V字の仮説とでも言いましょうか? V字の左側は2本線であるべきかと思います。)

ベクトルのV字

結論

V字モデルは、コーディング開始後には、現実離れした側面が現れる為、
これからも「V字モデルのおかしさ」でプログラミングが嫌いになる人は存在し続けることでしょう。 

*1:実用システムでは100レベルに達しかねない

*2:レベルが増えた分、1つのレベル内のノードは減る

因果推論に関する教示 10

因果関係というのはそれ程、一般的では無い?

ヒュームと同時期の哲学者のエルンスト・マッハに関する本*1 を読んだのですが、

マッハは、

  • 「原因」と「結果」の観念など

は、持ち込むべきではない、と思っていたそうです。

同じ本でマッハの文体に「むかついて」いたルートヴィヒ・ウィトゲンシュタインは、

  • 語りうることと語りえないこと(倫理上の問題など)は有るが、
  • 語りうることは一義的で明確で無いといけない

と、やはり「原因」と「結果」の観念などについてはマッハに賛成していたとの事です。

 

そう言われてみれば

そう言われてみれば、純粋なプログラム内部の議論を除けば、ソフトウェア開発の現場でも、

  • 「原因」と「結果」の観念など

は無視していると思います。

 

プログラマーとして新人だった頃、オフコン(言語はCOBOLで、14インチディスクパックを「カコン」とはめ込む様な機械でした)のプログラム修正時、

  • 直接の詳細設計書には書いていないが、
  • 基本設計書などと引き比べると、
  • 隠れた「原因」が有るとしか思えない(そうしないと要求された「結果」を導き出せない)

ので、それを指導の先輩に言ったら、引き取ると言われ、そのままでしたが、

もし、新人で無い、自分で何とかしないとならない立場だった場合、

  • 隠れた「原因」については語らず、それも踏まえた必要なプログラムを作り、
    (語りえないこと❓❓❓❓)
  • 詳細設計書が間違っているなどと、事を荒立たせず、
  • 文書化もしない(その様な記述を書くに相応しい文書がそもそも無い)

のがまともな大人の振る舞いだと思います。
つまり、マッハやウィトゲンシュタインの態度の踏襲となると思います。

ソフトウェア開発の現場では

  • 「原因」と「結果」の観念など

は無視しているので、当然の帰着です。

 

プログラマーに書かせるのは

でも、私の本心としましては、プログラマーに書かせるのは、

  • テストなんか

では無く、

  • 結果としてのプログラムの原因全て(詳細設計書も原因だが、それ以外の隠れた原因も残らず!!)

なのでは無いかと強く思います。*2

 

テストというのは、

なぜなら、
テストというのは(単一の関数呼出と、その準備と確認の様な単純で線形なものを除き)、因果推論の言葉で言う、『交叉』や、『介入』や、『反事実』も駆使すべき、大域的な知識が必要で、

プログラマーにやらせるより、(より因果ダイアグラムの上限側に近い)設計者にやらせた方が良いと思いますし、

逆に、結果としてのプログラムの原因全てこそ、プログラマーでしか書けない(思いつかない)と思います。

 

結論

これからも「因果推論に関する教示」を周りの人にされる事でプログラミングが嫌いになる人は存在し続けることでしょう。 

*1:マッハとニーチェ 世紀転換期思想史 (講談社学術文庫) [電子書籍版] 木田元

*2:もっとも、単一の関数呼出とその準備と確認の様な単純で線形なテストの場合、テストを書くだけで、原因全てを表現可能なのかも知れませんが、そうで無い場合の方が大多数だと思います。

因果推論に関する教示 9

国による、得意分野の違い

哲学は歴史的に、その後、自然観察を元にした別のやり方によって、メタクソにおとしめられ、それは故無きことでもなかったので、定着して行ったのだと思います。

国による、得意分野の違いは、どうしても出ると思いますが、

  • 何の思潮により隆盛したか

も影響すると思います。

特にこの国では、

  • 他のやり方を、自然観察を元にしたやり方でおとしめ、
  • 非常に成功して来た

ので、その傾向は強いと思います。

ただ、その、

  • 観察すべき対象である、
  • 一貫性を持った”自然”が無い

分野では、一気に弱みとして噴出するのかも知れません。

 

何が必要なのか?

  • 自然に代わる徹底的な一貫性

だと思います。一貫性さえ有ればCOBOLですら、さらにアッセンブリ言語であってすら成立したのですから。。。

ただ、その後の言語の良さは、

  • より中立な表現とし、
    (『必ず「レコード表現」を必須とし、一番目立つ場所に書かなければ
     ならない』、などの「判り易さ」を排すなど)
  • より一貫性を表現し易くする
    (苗字としてのclass的言語要素とか、居住地としての名前空間言語要素とか)

点に主に有り、
その第一原理が因果推論で、その表現が(特に、”閉じた”)因果ダイアログだと思います。

 

国外の人に作らせる利点

昔は安くて国外の人にプログラムを発注して作らせていた事も有ったと思いますが、それ程安い訳でも無くなった今日でも、同じ事をしている場合が有ります。

これは、

  • 日本語が通じにくい人に頼んだ方が、
  • より、「自然に代わる徹底的な一貫性」を維持し易い

からである可能性が有ります。

コボラーの時代の人間は、今より話が通じなかったのは歴史的な事実だと思いますが、それも、

  • より、「自然に代わる徹底的な一貫性」を維持し易い

為だったのでは無いかと思う様にもなりました。

 

結論

これからも「因果推論に関する教示」を周りの人にされる事でプログラミングが嫌いになる人は存在し続けることでしょう。