dotkuwaの日記： 微視のソフトウェアプロセス

品質マネジメント国際規格なんて、自分らにとっては、
・バブル期に審査員が実務のあらゆる方面に喧嘩を売っただけ
の活動にしか思えません。さらに事実としてそれ以外の影響を
受けていません。
　
休みで暇なので少し調べてみた所、なぜかそういう規格は、
「実際のプログラム作成」の所を測ったように迂回している
事が判ります。
まるで金属の品質を評価するのに、金属の周りの温度、湿度のみ
でしている様なものです。
金属の品質なら、表面を磨いて顕微鏡で見るとかするべきだと
思います。
　
ただ、ソフトウェアの品質を、プログラム自体を微視的に見ても
測ることが出来ないのも歴史的事実です。
「関数当たりの行数」だとか「コメントの文字数÷全体の行数」
だとかです。
　
しかし、ソフトウェアを作成する微視的なプロセスなら
もう少しましになるかも知れません。
・テストを書くプロセスの前に、アーキテクチャーを決める
　プロセスを置く。
だとかです。
＃こう考えると、「テストを初めに書け」という提案は、
＃微視的なソフトウェアプロセスに関する嚆矢だったの
＃かも知れません。
この場合のアーキテクチャーは、
・高給取りがプロジェクト統制の為にする、すごい行為
では無く、
・技術的ネタ（仮想DOMとか）の検証（入力値＋１を返すだけ
　とか）の様な卑近な行為
です。
これをするだけでも、テストによる柔軟性（保守性、移行性など）に
対する重大な侵害を防ぐことが出来ると思いますし、
各人がアーキテクチャーに対する理解を持つ事は、プロセス改善に
とって有意義だと思います。

なぜなら、、

[dotkuwa (9387)]

ソフトウェア開発で最悪なのは、
・必要とする複雑さより少ない複雑さで大丈夫だと
　提唱し、合意を得る
事です。
確実に失敗します。アーキテクチャーというのは、
その複雑さのみを予め予見する為のものだとおもいます。
その階梯に於いては、金額が十円違おうが、一億円違おうが
関係ありません。
　
よく見かけるのが、ネットワーク畑の人が、システム全体
に携わる時によくやる、
・全システムをステートレスにすべきだ
という提唱です。
確かにより少ない複雑さになりますが、これは有り得ません。
なぜなら、
・人間がシステムに求めるのは、今までの経緯を覚えてくれる
　ステートフルなものだから
です。これで有る以上、人間が好ましいと思えるシステムは、
ステートフルを必ず含みます。
結局、
そのステートフルな部分は、文書化されない、収益化されない
所に押し込まれ、他人になすりつけられるだけになるでしょう。
　
ただ、そのアーキテクチャーを推し量る為の作業は、困難を伴い
ます。作業が大変だと言っているのでは有りません。
リーダーが、推し量りをやっている人間に、
・慌てるな、落ち着いて考えろ
と言うのです。どう考えたらいいのか聞くと、
・それはお前が考える事だ
と答えるのです。品質マネジメント国際規格の審査員の言っていた
事とそっくりです。
複雑さのみを推し量ろうと、技術的なネタを調べたり、
フレームワークの制限を調べたりしている最中に、
・落ち着いて考えろ
です。そりゃリーダーに不可欠な権能が有るのは事実ですが、
この行為は完全に向こうの悪です。人ならざる者の行為です。
　
リーダーのその様な、必要とする複雑さより少ない複雑さ
で大丈夫と提唱する行為は、周りの人間が咎めるべきだと
思います。

「落ち着いて考えろ」の真意

[dotkuwa (9387)]

「落ち着いて考えろ」と言ったリーダーは、10年選手とは
言え、30代の人間です。
自分がこの様な大言壮語を吐くようになったのも、間違いの
無い衰えからですが、その人はとてもそうとは思えません
でした。
　
「落ち着いて考えろ」というのは、その言いたい事は、
・整数に例える事が可能な、一列に一覧された情報だけで
　ソフトウェアシステム全体を考える事が可能だから、
　その様に考えろ。
だと思います。
余りに雑過ぎます。少なくともソフトウェアの中学校レベル
の勉強をした人以上なら、そうは思わないでしょう。
　
そして、そのリーダーは自信満々で、しかもそのリーダーだけ
がそう言っていた訳では有りません。疫学的なインフルエンサー
が存在したはずです。
多分それは、学校の先生だと思います。学校の先生が、
日々の実践（笑）から導き出した、現実解（爆笑）だったの
でしょう。
　
冗談では有りません。自分が教員過程で学んだ範囲やその周辺なら
兎も角、まるっきり畑違いの分野で「実践」とやらのお遊戯を
披露し、
しかも、弱年層に対して、見え方の変わる色眼鏡をかけ続ける
事を立場によって強要したのですから。。。
それは単に新しい技法を提案して、今までのやり方は古いとか
宣伝するのとは、次元が異なります。
一生変わる事のない洗脳です。
　
日々の実践（笑）をするのは教員の特権でしょうから、自分では
歯ぎしり以上の事は出来ませんが、これは確固とした事実だと
思います。

学用と実用

[dotkuwa (9387)]

学用と実用は分けないといけないのに、
学用を新世代の実用だとするのが
諸悪の根源かも知れない。
　
全員に行きわたらせる必要のある
（知識を or 論文のネタを）学用が
実用の筈が無い。
新しいプログラムの構文（関数型とか）は
昔の嘘（学用を新世代の実用とした）だが、
「一列に一覧された情報だけでソフトウェアシステム
　全体を考える事が可能」というのを実用と言い張る
のは今の嘘（その嘘を信じ込んだ人間がプロジェクト
の全主要メンバーになり、問題が起きているのは今！）
です。

現在の「学用」の懸念点

[dotkuwa (9387)]

例えば航空分野で、
・揚力なんてあいまいで、たまたまうまく行っている
　やり方で、それだけのワンパターンなので、
　代わりに、広場でみんなで手を左右に広げて、口で
　「ぶーん」と言いながら走り回ろう。
とか言ったら変だと思いますよね？　それが幼稚園児で
無く、大人対象だったらさらに変ですよね？
　
ソフトウェアでは、その
・たまたまうまく行っている
・ワンパターンの
やり方をみんな切り捨てて、
・より簡単になった
と自賛するのを、誰も不思議だと思わないのです。
　
さらに、ソフトウェアは本質的に安全なので、
（非常に大きいエネルギー差をもつハードウェアと
　連結するとそうでは無くなる）
専門の大学校に入って、You have Control.とか、
MaxQとか、Fox one！とかいう訓練を経なくても
出来るのに、そうでは無いやり方を推奨したりも
しているのが不思議です。
　
いずれにしましても、揚力に相当するような、
・たまたまうまく行っている
・ワンパターンの
部分をいとも容易く切り捨てるのが本当に不可解です。
　
例えば、nullの無いオブジェクトへの参照の変数を
デフォルトにするというのが有りますが、
オブジェクトは、普通の値型の変数より、アクセスするのに
時間がかかります。スマホでちょっとした通知に対応する
のにフルフルの機能が必要で、通知だけの為に電気の10%、
20%を持っていかれる様なものです。
nullは圧倒的なコストの安さで「対象外」を表現する事が
可能です。
そのチェックはたまたまでワンパターンかも知れませんが、
外せない「たまたまでワンパターン」というのが有るのは
どの分野も同じだと思います。
　
木構造というのもたまたまでワンパターンです。
しかしこれがソフトウェア分野での「揚力」だと思います。
世界を切り捨てるたまたまでワンパターンのデータ構造
です。
これを文書で表すと、
・1.1　1.1.1　1.1.2　1.2 ...
・2.1　2.2
・
・
・
とかの段数可変の箇条書きになるでしょうし、その構造を
素直にプログラム言語に写し取るとオブジェクト指向に
なるでしょう。もう、丸っと「たまたまでワンパターン」です。
それを忌避しなければならないとするならば、新規性を
必要とする論文を必要とする構造は悪だと思います。
　
ただプログラムを作る、うじゃうじゃ作る、その為には
見本を平和裏に写経する、ではだめですかねー。