テストを書いてくれない １

どの様な話？

プログラミングにはテストが必須です。それは正解との適合性の検証です。
そして多分、テストはプログラミングの素養がなければ書けません。

それは、

• テストが出来る様な対象は有史以来、プログラミングが初めて

だからです。プログラミングが成立する前は、テストも有りませんでした。

ですので、プログラミングが嫌いな人は、テストも嫌悪し、しかしそれを望むのです。アンビバレントというやつでしょうか？

何が問題か？

（自然言語で書かれた）要件定義書を元にプログラミングを作るプログラマーは、永続的なテストが書けないのです。

状況を模式的に言うなら、

• 要件定義書とは、いくつかの必要とする点を指定したもの
• プログラミングとは、それにふさわしい滑らかな曲線を描くこと
• ふさわしい滑らかな曲線は、複数存在する
• 「無限」で無く、「複数」なのは、プログラミングの技術的制約のため

ですが、そういう状況下でプログラマーは、

• そのプロジェクトの原理原則を極力遵守し
• 複数のふさわしい滑らかな曲線のどれになっても（まぁ）大丈夫な様にしつつ、
• その内の1つの滑らかな曲線を（半ばあてずっぽうで）選び実装する

という知的作業をします。

どうにもならないのか？

この時点で、コストをかけて永続的に使い得るテストを書くのは無駄です。
1回使い捨ての簡易なテストをして、要件定義書の発注者側に近い（上流の）人に渡します。これは定義された正当な手順です。

その後、上流の人間が、

• この（あてずっぽうで選んだ）滑らかな曲線が良ければ、（多くの場合テストの専門家が）永続的なテストを書き
• そうで無いならその旨を下流に返す（このことを「不具合」と称することが有りますが、不本意では有ります。）

とすることでしょう。上流に近い人間は、プログラミングの素養の他に、どの「滑らかな曲線」が正解か判定する素養も必要です。

どの「滑らかな曲線」が正解なのかを本当に知るのは発注者で有り、上流の人はその代弁人として、正解を判定します。

やはり例外は有ります

運用コストが高いシステムで動かしているプログラムを、低いシステムで動く様に変更する場合、テストはかなり容易になります。

• 前のシステムの入力→出力と、全く同じな入力→出力になる様

にすれば良いからです。

多分これが理想なのだと思います。
あらかじめ正解が（要件定義書が）プログラミングとして書き切られている場合です。

もちろん現実はこれとは合致しない場合が大大大多数たと思います。

結論

プログラミングの素養の他に、どの「滑らかな曲線」が正解か判定する素養も持った人がいない場合、永続的なテストは書けません。
そして、一般のプログラマーはまずもって前者しか持ちません。それは技能の問題では無く、立場の問題です。

そうなると、どちらの素養も無い人はお手上げになり、

これからも「テストを書いてくれない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

原理原則が見当たらない １

どの様な話？

プログラミングにおいては、

• ある原理原則が出来、それに基づいて業務を遂行していると、
• それに携わっている人間にとっては致命的に困る差異があり、
• しかし基本的には同一の、
• 別の原理原則を作り出す事が容易

です。ですので通常、原理原則は強いリーダーシップ（＝大規模なプロジェクト）の下でのみ成立します。

もちろん、余りに作り出すのが容易過ぎて、意図的な意地悪で別の原理原則を作ろうとこころみる必要は有りません。自然にそうなります。
ですので、強いリーダーシップの下でのみ成立すると思います。

普通の人間がそれを体験するには、大規模なプロジェクトで駒になるしか無いと思いますし、そのプロジェクトから離れると、それは無効になると思います。

流行りは大事

ですので、流行りはプログラミングにとって非常に大事だと思います。

例外も有るのでは？

クラスというのは、

• 集落内で名前だけで生活していた人が
• 行動範囲が広がって、故地の地名を前（または後）に付けた
  （風の谷の、とか、焼津の、とか）

ものだと思います。これは原理原則より一段上で「自然法則に準ずるもの」では無いかと思います。

原理原則は容易に別のものが作れますが、自然法則に準ずるものは無理だと思います。

結論

これからも「原理原則が見当たらない」事でプログラミングが嫌いになる人は存在し続ける事でしょう。

箇条書きが書けない １

どの様な話？

これはプログラミングというよりプログラミングの設計の話ですが、

管理職やリーダーは、プログラマーにとって指示を受けたり、相談したりする相手ですが、彼ら彼女らの「必殺技」として、箇条書きが有ります。
複数のレベルの項目を行を分けて並べていく書き方で、レベルの高いものは何か、一目瞭然となり仕事の指針となる文書だと思います。

何が問題なのか？

管理職やリーダーは、プログラマー（詳細設計がまだの時点で）に、箇条書きで作業内容を書けといいます。
しかし書けません。なぜなら、

• （感覚的に言って）レベル20の項目や、レベル50の項目が
  それなりの重要性をもって現れる。
• しかしExcelでもWordでも、専用のWBSのツールでも、
  レベル50はもちろん、レベル20の項目でも書き込めない。
• それが必ず、どんな場面でもレベル20と50ならまだしも、
  レベル8と70になったり、違う風になったり、、、、
  となるので、箇条書きに出来ない。

からです。

そんなの、誤魔化してレベル4と5にすれば良いでは無いかと思うかも知れませんが、実際に有るレベル3と比べて、いかにも些細な詳細な零細な項目に見えます。
実際にそんな細い事は書くな、と言われます。
しかし、それが解決しないと全ての話がダメになったり、解決するのにかなりの時間がかかったりもする項目なので、絶対に省いてもらいたく無いのです。

なにか働きかけはしなかったのか？

トピックベースの一覧にしてはどうか、と提案しましたが、にべも無く断られました。トピックベースとはレベル1の項目も、レベル50の項目も同じに並べろという提案ですが、毎回断れれました。
「レベルの高いものから（重要度の高い（？）ものから）」作業をしたい、管理職やリーダーにとって、トピックベースの一覧など唾棄すべきものなのでしょう。
（そうとしか思えない態度でした。）

これは双方にとって不幸でした

箇条書きで書くのを渋るプログラマーの態度、ひいてはプログラミングに対して、管理職やリーダーは嫌いになったと思います。

しかしこの場合、逆も真です。

箇条書きにしろ、とは、レベル20の項目やレベル50の項目を無償で提供しろと言っているのと同義です。

結局の所、管理職やリーダーの肌体験で得た知識より、この件（箇条書きを書かせる件）は有耶無耶にするのが妥当だ（何てプログラマーは無能なんだと思いつつ）、という風潮になっていると思います。

結論

これからも「箇条書きが書けない」事でプログラミングが嫌いになる人は存在し続ける事でしょう。

記述の順番が異なる 1

どの様な話？

何とプログラミングと異なるか？　というと、（自然言語で書かれた）要件定義書と異なる、です。
『何で同じに書かないのか』で、嫌いになる場合が実際に有りました。

プログラミングは（たとえどんな論理的糖衣をまぶしても）、結局の所、

• プログラムのある部分に制御が渡る、次に別の部分に制御が渡る、、、

でしか動きません。ですので、融通無碍な要件定義書と比べて、順番にかなりの制約が有ります。

例１

プログラムは、滑らかに回るエンジンやモーターの様に、プログラムの各部分は前の制御に依存し、次の制御のための準備も必要です。

ですので、要件定義書に1→2→3と書いてあっても、
3→1→2→3→1→2→3→1→2→という風に書かなければならない場合が有ります。

この様な記述の順番が異なる（自分が思っていた要件定義の順番と異なる）所為で、嫌うというのは、間違いなく有ります。

例２

要件定義書では、おおまかな所から、細かい所へ書きます。
しかしプログラミングでは細かい所から、おおまかな所に書きます。
プログラミングでは「おおまか」とは画餅に過ぎず、幾つもの細かい例外「以外」がおおまかになります。

この書き方の違いについては、突きつけられると激怒する人間がたくさん居ます。何で自分の指定した通りにしないのだ、と。
理由は「おおまか」とは画餅に過ぎないからです。

激怒した対象を好きになる事など、あまり有りません。嫌われる原因の1つでしょう。

何とかならないのか？

要件定義書の通りにプログラミング出来るプログラミング言語というのは、長く望まれて来ました。来ましたが、多分無理だと思います。

もしこれが出来たらこれ以降100年間は、人類全体の教師として人類全員から尊敬を受けるはずなので、もし有ったらそれをもたらす事が可能な人間なら隠さずに公表すると思いますが、全く有りません。

結論

これからも「記述の順番が異なる」事でプログラミングが嫌いになる人は存在し続ける事でしょう。