まともな名前を付けさせてくれない ２

どの様な話？

「まともな名前」の1例です。

何で！？

経理部門の人が、数あるプロジェクトの中で、ほんの時限的な小型プロジェクトで、

• こともあろうに「project@example.com（仮名）」というMLを、そのプロジェクト用に作ってくれ

と言ってきました。もちろん職権で突き返しました。

自分らはゴーイングコンサーンとか言っている癖に、MLの将来的な保全を損なう名前を平気で要求するのです。

別のもっと深い理由

経理部門とプログラム部門は割と上手くやれています。行動原理が似ているからだと思います。

ただし別部門としてならですが、（すこし大袈裟に言うと）協働してなにかやるとなると、途端にやばい事になります。

その理由は、人間は

• 総じて、似ている仕事は手を抜く

からだと思います。経理部門とプログラム部門は似ていて、尊重し合える代わりに、協働しだすと泥沼になり、
外注化して、御社・弊社パターンに持ち込まないと必敗になるのだと思います。

何で手を抜くのか？

• 名前がかち合う

のだと思います。

同じ名前だが、向こうの分野とこちらの分野で重い軽いが全く違う場合、
似ている仕事だからと、調べもしないでやってきた場合、その名前に引っ張られ、それをハタから見ると「手を抜いている様に見える」のです。

プログラマーとマネージャ、数学とプログラミング、運用と開発、プログラミングにおける学術系と実務系など、多くの事例があると思いますが、
ハタから見ると、

• 総じて、似ている仕事は手を抜く

様に見えます。

結論

これからも「（似ている仕事の人にとって）まともな名前（としか思えない名前）を付けさせてくれない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

まともな名前を付けさせてくれない １

どの様な話？

特に経理畑の人が、プログラミングの各種名前に一々、まともな名前（妙に一般的な、普遍的な名前）を付けてしまい、理由が有って否定されます。
これはプログラミングが嫌われて当然の話ですが、理由が有ります。

どんな理由？

• 目的は、一貫した基準で有り、
• 手段は、それを維持するための物

です。プログラミングは目的にするには惜しいくらい手段に向いています。そして、一貫した基準を維持するための物の名前は、より限定的になります。

経理畑の人だって、仕分けを維持するための理屈は、決して「まともな名前」で成り立っている訳では無い（一言二言で説明が付く理屈では無い）はずです。

• 目的には、まともな名前が付き、
• 手段には、より限定的な名前が付く

というのは妥当だと思います。

プログラミングの分野での名前とは？

プログラムは現状、

• 2次元の用紙（画面）に文言を書いて出来ています。
• しかし、プログラムの部分に名前を付け、それを参照する事で、より複雑になります。
• そして手段で有る以上、目的のために変幻自在に変更されます。

よく、複雑で変幻自在なプログラムを「建て増しされた温泉旅館」に例えることが有りますが、様相はかなり異なります。

• 温泉旅館はいくら複雑でも、同じ所に複数の建物は建ちませんし、重力の影響も受けますが、
• プログラミングは名前を参照しさえすれば、いくらでも繋がります。

なぜ、より限定的な名前を付けないとならないか？

維持すべき一貫的な基準を維持するための手段である以上、変更されますが、完全に変更していたら、テストも初めからやり直しです。
変更されながら、完全に変更しないためには、名前をより限定的にするのが常套手段です。

まともな名前をつけると、変更した時に丸かぶりになり、完全な変更が必要になります。

何で「まともな名前」を付けたがるのか？

想像ですが、プログラミングを目的と思っているからだと思います。プログラミングを目的にするのは勿体無いです。
プログラミングは一貫的な基準を維持する手段となり得る能力が有ります。

そういう理由が有って否定されるのです。

結論

これからも「まともな名前を付けさせてくれない」事でプログラミングが嫌いになる人は存在し続けることでしょう。

悪口を言われる ２

どの様な話？

IT業界の多重下請け構造というのは、悪口が原因では無いかと思えてなりません。

プログラマーとその経験が無い上司が同じ会社・部署に居ると、

• 上司から（プログラマーから見た）悪口を際限なく言われ続ける
• どう見ても中毒としか見えない、多幸感のかたまりになる
• しかしその上司も、裁量を持った上司が大まかな指示を出すのは正当だと思い、悪口に対して配慮をしない
• 裁判官も世間の目も同様
• だれも（この筆者を含めて）それが悪いとする論理を構成できない

からです。またプログラマーでも、バックエンドとフロントエンドでは断層が有ります。（レベル20とレベル50と言った所でしょうか？）

プログラマー上がりが上司になれば？

そうするとマイクロマネージメントしか出来なくなります。1つのプロジェクトを完遂する能力は失われます。

対策は？

御社・弊社の関係に擬制すると、同じ組織とは扱いが全く違う様になります。悪口どころか、ものすごく相手の立場に立った配慮がされます。気持ち悪いくらいです。

畢竟、多重下請け構造となります。

この筆者は？

この筆者は目の調子が悪く、目視で1つ1つ確認する事が非常に苦手で、

• プログラミング全体の趣向は頭で考えるだけで可能で
• ロジックの不備も自分でやった事は覚えておき、寝る前に反芻すれば対応出来、
• 入力はタッチタイプで目視で1つ1つ確認する必要が無く、
• 確認はロジックによるテスト（まさにテストです）で出来る

というプログラミングにしがみ付くのが最良で、どんな悪口も平気でした。

なお、目視で1つ1つ確認する際は、片目ずつ（0.5有ります）見れば良いと解ったのは55歳を過ぎてからでした。

この様なやり方はとても他人にはお勧めできません。

結論

これからも「悪口を言われる」事でプログラミングが嫌いになる人は存在し続けることでしょう。

悪口を言われる １

どの様な話？

実際にプログラムを書いていると、書いていない人から悪口を言われます。
それに対してなかなか反論出来ません。

なぜでしょうか？

実際にやっている人（この場合はプログラムを書いている人）と、悪口を言う人（この場合は書いていない人）を天秤の両端で表すとすると、

• 天秤の支点までの距離がプログラミングの分野では、他のどんな分野よりも実際にやっている人が比較して断然長くなる
• 例えるなら、悪口を言う人が箇条書きレベル1 ならば、プログラマーは箇条書きレベル20 になる様なもの

です。悪口を言う人は、プログラムの批評をするには余りに大まかすぎるので、牛刀でしらす1 匹をさばく様な形になり、

• どんな悪口を言っても前提が偽と（同様と）なり、
• その結果、どんな悪口の結論も真になる

という最悪な形だからです。

それでは悪口を言う人が最強では無いか

と思われるかも知れませんが、それらの悪口は全く実を結びません。天秤の（余りにも）短い方の端から、長い方の端を動かそうとするのは無理です。

社会の分野によっては、天秤の両端が同じ長さで議論が泥沼になる分野もあれば、長い短いが絶妙で、上手く社会に介入できる分野も有るかも知れませんが、プログラミングの分野は上記のとおりです。

ですので、「20年（悪口を）主張してきたが実を結ばず、後10年主張しても同じかも知れない」という詠嘆は確かな実感だと言えます。

違いの本質は何か？

悪口を言われる人と、実を結ばない人との違いの本質は何でしょうか？

それは、

• 確率で済ませるか、定義（因果）にまで落とし込むか

だと思います。要件定義書は確率の側で、それはそれで（その時点では）尊いものだと思いますが、プログラミングはそれから先に進めます。

• その過程で他の可能性を削ぎ落とします

が定義とはそういうものです。本当に細かい話になります。

テストは？

もちろんテストを書くことも全く同じで（定義（因果）にまで落とし込む）、やはり本当にテストを書くと、悪口を言われると思います。
本当にテストを書いていないから悪口を言われないだけです。

例えば、1円の売上げを自動的に2円で計上するプログラムのテストを書いても、プログラミング上は何の問題も有りません。

それが正しいか誤りかは要件を決める側の人の問題です。ただ、明らかに悪口を言われそうなので、テストを書くのを尻込みするだけです。

テストを書いたのに悪口を言うのは悪質です。

結論

これからも「悪口を言われる」事でプログラミングが嫌いになる人は存在し続けることでしょう。