あるソフトウェア関連の会合で、「プログラマの思い込みの激しさ」を批判ご指摘される方がおみえだった。

「思い込みの激しさは、プログラマにとっては、生産性の高さの原動力であって弱みではないのでは」とお答えした。

この文章は、「プログラマの思い込みの激しさ」を指摘いただいた方の思い込みの激しさをあぶり出せるかどうかを確かめることが副産物として想定しています。

本題自体もまだ十分論証できていませんが、なんらかの成果がでるまで追記し続ける予定です。

なお、編集リクエストは、しばしば Qiitaの処理系がうまく処理できず、矛盾などを発生させることがあります。コメント欄でご指摘くださると幸いです。
Contributionも、編集リクエストだと Qiitaの処理系がうまく処理できないことがあると、コメントいただいた方が、著者以外の「いいね」がつく可能性があり、お得です。よろしくお願いします。

現在、Qiitaでは主にAUTOSARの資料整理にあたっており、その1日の目標作業が終わるまで他の記事の読み書きを控えています。コメントの返事が数日後になる可能性があることをあらかじめお詫びいたします。

そんなある日、
自分を忘れない事の大切さ
https://qiita.com/sk4869pw4869/items/023c2a99aa790fdb1a66

そうか、思い込みでも、プログラムが書けなくなる思い込みもあるんだ。

そこで表題を
プログラマの思い込みの激しさは強みであって弱点ではない３つの理由
を
プログラマの「プログラムが書ける」思い込みの激しさは強みであって弱点ではない３つの理由
に変更させていただきました。

普段, HAZOPで、逆も考えようと言っている割に、紺屋の白袴してしまいました。@sk4869pw4869さんありがとう。
みなさん、ごめんなさい。

背景(back ground)

ここでプログラマは、OS、言語、通信、DB、試験を含む自動化などの道具類を設計する人たちを想定しています。自分は仕事で、主にプログラマの道具類をプログラミングしてきたためです。

その分野でお付き合いいただいたことがある天才プログラマの半分くらいは、プログラム以外については思い込みが激しい性格だったような気がします。

それでも社会生活がおくれているのは、大学、企業、研究所、家族などの組織が支えているか、それぞれの組織の代表者、管理者が、いろいろ代行してくれることがあるからかもしれません。

プログラマの評価は、書いたプログラムですべきです。何を思い込んでいるかで評価しても仕方ないと思いませんか。
思い込みを止めたら、他の人が考え付かないプログラム（解法）を思いつかないかもしれない。

安全分析で、ありえないことを前提に発想して、ありえることの対応を見出すかのように。

効率的なHAZOPの進め方
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446

前提(premise)

リスク理論(risk theory)

リスク理論には、正と負の両方を検討する経済理論系の理論と、負だけを検討する理論がある。
どちらの理論も、その利用方法によっては、等価な境界(interface)が存在する可能性がある。ここでは、正と負の両方のリスクを扱うものとする。負だけを検討する理論についてはいつか扱うかもしれない。

強みには、その強みの影に隠れて、変動があると負の現象が起こる確率がある。これを強みの負のリスクという。強みを活かさずに、競争に負けるのも、負のリスクとして計算する。強みがどんどん伸びて、想定したよりも早く仕事が終わってしまうという正ののリスクがある。しかし、この正のリスクを見積もっていないと、早く終わった時に、やることを間違えて、台無しにするかもしれない。正のリスクはいつ負のリスクに転化するかわからないようでは管理としてよろしくないかもしれない。負のリスクも、正のリスクに転化できる方法を知らなくては、管理としてよろしくないかもしれない。

弱みは、負のリスクを考慮するよりも、正のリスクが生まれないかを検討するとよい。

技能管理(skill management)

プログラマ、音楽家、運動選手など、個々人の技能を最大限有効に利用する必要がある仕事では、技能管理が重要である。これらの専門家の技能管理においては、強いところを利用し、弱いところは使わないようにする。

製造業における製造工程でも、職能の高い人の作業を習うようにして、標準作業の効率化を測る。

複数人が一緒に仕事をする場合には、その仕事の仕方をうまく組み合わせて最大限の効率をもたらすようにするのが指導者、指揮者、監督の仕事となる。

一人で仕事をする場合でも、健康管理、精神集中管理など、管理を手助けする人たちがいる。

1. 思い込みの類型(classification)

どんな思い込みが良くて、どんな思い込みが悪いという経験則は見つかっていない。

どんなに思い込みが激しくても、作ったプログラムが、自分の思い込んだ意図通りに動かなければ、それを一生突き詰めていくか、機敏(agile)に方針変換するかどちらかの可能性がある。

1.1 突き詰め型(maniac)

一生突き詰めていけば、数学の未解決問題を解決できるかもしれない。

http://www.claymath.org/millennium-problems

多くの未解決問題は発見的で、何か正しいことを突き詰めればいいわけではない。
正しいことは、思い込みの一つとしてはいいかもしれない。
すべてではない。

Poincaré Conjecture by Perelman Grisha
https://arxiv.org/abs/math/0211159
https://arxiv.org/abs/math/0303109
https://arxiv.org/abs/math/0307245

論理科学の問題で、自然科学、生命科学、社会科学の模型が利用できるかもしれない。

数学者、プログラマは、科学分野における確率とか分布とかを捨象し、抽象的に決定できると思い込むことがある。

仮説・検証(93) 科学四分類と算譜(program)
https://qiita.com/kaizen_nagoya/items/a2f2b9cc3a51b6af7603

抽象的に決定できると思い込むことは悪いことではない。解への近道が、あらかじめわかっているわけではない。

1.2 機敏型(agile)

プログラムが思うように動かなければ、いくつかの次候補を選ぶ。

自分が使う道具であったり、市場に出すプログラムや、オープンソースのプログラムでは、書いたらすぐに結果がわかり、検証(verification)は必要なく妥当性確認(validation)がすぐにできるかもしれない。

妥当でなければ、作り直すしかない。
できるだけすばやく設計することが大事だ。
一生かけて実現するのであれば、一生かけて設計してもよい。
その方法は上記「突き詰め型」分類に属し、この節(section)では議論しない。

1.2.1 算法(algorithm)を変える

自分は得意ではない。徐々に事例を集める。

算法を変える例は、次の記事で紹介している。

『フカシギの数え方』おねえさんといっしょ：組み合わせ爆発の凄さ: docker(111)
https://qiita.com/kaizen_nagoya/items/f309b0c2bb015bbc71c3

オープンハウス2013：基調講演「フカシギの数え方― 組合せ爆発に立ち向かう最先端アルゴリズム技術」湊真一
https://www.youtube.com/watch?v=8xqEBQc1nTo

科学分野の模型(model)を変えたり、Datarobotのようなデータ解析についての機械学習の結果を比較して洗濯するのもよい。

DataRobotは次の記事で紹介している。

「Qiitaのいろいろランキング2019」への感謝と提案
https://qiita.com/kaizen_nagoya/items/40b8557a20e8d75d62b5

1.2.2. 言語(language)を変える

アセンブラで書いていたがC言語にする。
FORTRANで書いていたがMATLABにする。
mathematicaで書いていたが、XXXにする。

専用言語を作ってもいいかもしれない。
特定の問題を解くだけの言語があってもいいかも。

「アセンブラへの道」組立語(assembler)・機械語(machine language)・CPU
https://qiita.com/kaizen_nagoya/items/46f2333c2647b0e692b2

転職(16) ６５歳からのプログラミング入門
https://qiita.com/kaizen_nagoya/items/1561f910c275b22d7c9f

1.2.3. OS(operating system)を変える

OSが言語の足を引っ張っているかもしれない。

問題専用のOSを作ってもいいかも。
自動車のエンジン、電動機(motor)などの角速度制御では、OSのタスクではなく割り込み制御を基本とし、タスクは割り込み制御の邪魔をしない設計になっている。

TOPPERS/SSP, OSEK, AUTOSARなどの最小構成がそれにあたる。

12ステップで作る組込みOS自作入門　坂井弘亮, カットシステム, 2010

https://www.amazon.co.jp/dp/4877832394

この本では、タスクなどは半分以降にしか出てこない。
OSに必要なのは、CPUの抽象化、入出力の抽象化であることがわかる。タスクは、割り込みの抽象化の一つの方法でることがわかるかもしれない。

1.2.4. 物(hardware)を変える

種記憶容量を増やす。
CPUからGPU, DSP, FPGA(verilog-HDL)、量子計算機など、今なら選択肢が沢山あるかも。

量子コンピュータプログラムへの道
https://qiita.com/kaizen_nagoya/items/37c90488c87bbe9f2d71

RTL設計スタイルガイド Verilog HDL編(System Verilog対応版）
https://qiita.com/kaizen_nagoya/items/4c02f1575db1f28310a7

トランスピュータの設計を継承するXmosの有効利用を考えるのもいいかも。

128bit CPUを設計してもいいかも。256bit CPU, 1024bit CPUがあっても多白いかも。

1.2.5 色(color)を変える

視覚は、思い込みの極致かも。自分が見えているものを、脳が処理していることに気がつかないことがある。錯視がよい例かもしれない。

色覚の分布は、個々人で分布、確率が異なるにも関わらず、同じものが見えていると思い込んでいる。

今、考えていることを見直すには、色を変えてみるといいかもしれない。色を変えてみると、それまで思っていたことと違うものが見えるかもしれない。油絵の先生から習った方法は、りんごは赤だと思わずに、部屋の中にあるものの色をりんごに置いてみるという方法。部屋の中の色をりんごに置いてみると、存在感が増すことがある。自分の思い込みを、取り払う方法の一つ。

仮説・検証（37）ぼくの先生　プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

プログラマが知っているとよい色使い(JIS安全色)
https://qiita.com/kaizen_nagoya/items/cb7eb3199b0b98904a35

1.2.6 音(tone)を変える

人と一緒にいた方が安心するというのも思い込みかもしれない。
一人でいると安心するというのも思い込みかもしれない。

音を変えると、一つの思い込みから別の思い込みに変換できるかもしれない。

仮説・検証（54）プログラムは音楽だ (A program is a music.)
https://qiita.com/kaizen_nagoya/items/33c9f33581e6886f8ad8

1.2.7 自然言語(tone)を替えてみる。

日本語で考えている人は英語で考えてみる。
カタカナ語を多用している人は、カタカナ語を止めてみる。

そうすると、それまでに見えていなかった発想が見えてくるかもしれない。

略号を使っていたら、全部full spellingに直してみるとよいかもしれない。
同じ略号なのに、別の意味だったものに出くわすかもしれない。

英語(1) プログラマが知っているとよい英単語の語源
https://qiita.com/kaizen_nagoya/items/9de6d47c47e2c211222b

英語(3) 仮説・検証(88)用語の衝突(用語・用例募集中)
https://qiita.com/kaizen_nagoya/items/6a8eb7ffaa45eeb16624

2.原動力(power)

何を信じていようが、何を思い込んでいようが、問題を解決できればよい。

制約条件、前提条件、初期条件に間違いがあっても、解の候補が出てから、制約条件、前提条件、初期条件の違いを加味して、解を補正してもよい。

例えば、ラプラス変換は、時間領域の問題を、空間領域（周波数領域）で解き、時間領域に戻してから初期条件を加える。
制約条件、前提条件、初期条件が正しくないと問題が解けないとは限らない。制約条件、前提条件、初期条件の何かを捨象した方が、時やすい問題の形になるかもしれない。

詳解LAPLACE変換演習大下眞二, 共立出版. 1983

https://www.amazon.co.jp/詳解LAPLACE変換演習-郎/dp/4320070917/ref=sr_1_20?__mk_ja_JP=カタカナ&keywords=演習+ラプラス変換&qid=1581221961&s=books&sr=1-20

制約条件、前提条件、初期条件を思い込みだと読み直せば、思い込みの間違いは、解の間違いになるとは限らない。解の一部を削らなくてはいけないか、解をより厳密にしなければいけないだけかもしれない。

必要なのは解くことであり、解いたものが必要なものかどうかを確かめられればよい。

プログラムでも同様で、書いたプログラムの一部に間違いがあったり、問題があってもよい。
制約条件、前提条件、初期条件などを与えて、有効な範囲を限定していけばよい。

必要なのは、解を出すのに必要な原動力だけで、解き方が合っているかどうかが重要とは限らない。

論理的に正しいものだけを並べて、最終的にも正しいものを導き出す方法もあるかもしれない。それはそれで思い込んでやっていけばいいだけで、誰が早く必要な解に至るかどうかの競争なだけかもしれない。

3 試行錯誤(trial and error)

プログラムを書いて、走らせて、結果が得られなければ、またやり直す。

どんな思い込みで書いても、解に至るかどうかが大事。

試行錯誤は天才型というよりは努力型かもしれない。

試行錯誤していれば、いつか解決するはずだというのも思い込み。

解がない問題はいくらでもあるし、特異解しかない問題は発見的なことがある。
１年で見つけられるかもしれないし、１００年かかるかもしれない。

どんな間違った思い込みでも、解が見つかるはずだと思い込んで試行錯誤しているうちに、間違った操作、間違った前提だと解がでるかもしれない。

出た解を、制約条件、初期条件などで修正すれば、求めたかった解になるかもしれない。

VZエディタ移植(porting)に当たって実施したことと成果
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949

事例考察(case study)

1. 人間の資質に関する思い込み

人間の資質に関する思い込みは、多人数で協調して作業する場合には、組み合わせを考慮するとよい。ある思い込みと共存できる思い込みになにがあり、どう組み合わせると負の効果が少なく、正の効果が大きくなるか。

2. 設計機材、道具に関する思い込み

複数人で作業する場合に、共通で利用する機材、道具に関する思い込みがあると、複数の道具の境界を決めたり、自動連携の道具を用意する必要があるかもしれない。それらの労力が、複数人で作業する正の効果よりも小さければ、問題ないかもしれない。

3. 設計対象に関する思い込み

何を作らなくてはいけないかに対する思い込みは、指揮者でなければ問題ないかもしれない。
設計対象の範囲、設計・試験方法、道具類などで無駄か抜け漏れがなければよいかもしれない。

4. 論理現象に関する思い込み

すべての問題は解けるはずだとか、この問題は解けないとか、今の作業の一部にしか影響を与えないかもしれない思い込みは、管理可能かもしれない。

5. 物理現象に関する思い込み

最適解が見つかるはずだとか、最適解は存在しないとか、今の作業の一部にしか影響を与えないかもしれない思い込みは、管理可能かもしれない。

6. 生命現象に関する思い込み。

遺伝子配列が分かれば行動が予測できるとか、今の作業の一部にしか影響を与えないかもしれない思い込みは、管理可能かもしれない。

7. 社会現象に関する

特定の団体、特定の個人に対する思い込みが激しくても、今の作業の一部にしか影響を与えないかもしれない思いこみは管理可能かもしれない。

まとめ

Three proofs of the intensity of programmers' beliefs is strength, not weakness.

Qiitaで「思い込み」検索すると、いろいろな思い込みの記録がある。
自分のことを書いている場合は、思い込みに気がついた例で、細かな思い込みから、大きな思い込みまでさまざまな気付きが書かれている。

突き詰め型であれ、機敏型であれ、思い込みは大切。
解への到達も、天才型であれ、努力型であれ、解が出るまで、思い込んで諦めないことが大事かもしれない。

日程が決まっていたり、多人数での作業では、一人の思い込みが全体に悪影響を与えた例はあるのかもしれない。顧客側の思い込みで困ることは時々ある。

仮説・検証（32）顧客の勘違い、思い込みにどう対応するか
https://qiita.com/kaizen_nagoya/items/2e61f1c770b66d1a1484

顧客側にもプログラマがいて、そのプログラマの思い込みが激しくても、実際にプログラミングして、動かして貰えば、伝わることが多かった。思い込もうが、思い込まなかろうが、プログラミングしてみればわかることなら問題ない。

解の候補から解への導出は、大量のデータから帰納的に求めてもよいし、演繹的に求めてもよい。

大量のデータを解析するのに、物理科学、生命科学、社会科学の模型(model)を知っていると、いかなる分布が登場しても困らないかも。

確率論及統計論
https://qiita.com/kaizen_nagoya/items/89d0a91a56d33529e85c

転職(1) なぜ経済学徒を辞め、計算機屋になったか（経済学部入学前・入学後・卒業後対応）
https://qiita.com/kaizen_nagoya/items/06335a1d24c099733f64

参考資料(reference)

思い通りに動かないときの対処方法
https://qiita.com/FeelSoGood/items/22ac08f6fb3ea11d4688

【業界初心者向け】システム設計者がプログラマに求める1つのこと
https://qiita.com/JEo4YZZPL3zRRW7/items/cde48cd85fa86c57dc76

[ まつもとゆきひろ氏 ]若手エンジニアの生存戦略
https://qiita.com/Tsutou/items/50be50cdb200f1e31d1c

has_oneとhas_manyの違いは多重度だけという思い込み
https://qiita.com/haazime/items/4d528f8d173d654ba394

_.extendはcloneをしてくれるはず、と勘違いしていた話
https://qiita.com/sasaplus1/items/380d1fe6d5400c1beedf

rails sでサーバーが起動しなかった時に確認したい初歩的なこと
https://qiita.com/sakuraniumarete/items/46f6bd5ce9a1afdf88a7

デバッグ心得
https://qiita.com/cactusman/items/90128938db93fa8c46d3

事故参照(self reference)

「平成のうちにやめたかった『ITの7つの無意味な習慣』」に付け加えたかったこと。
https://qiita.com/kaizen_nagoya/items/e6f9c2e0afbf8ab4181c

2020年の開発者が知っておくべき11の必須技能→回答編 → 並べ替え→項目合併(8項目)→内容追記
https://qiita.com/kaizen_nagoya/items/39e1c69bddb8e608b42b

仮説・検証（38）プログラマで「飛び抜けた人が少ない」という仮説
https://qiita.com/kaizen_nagoya/items/f0d22e20f6d2c58f2c1b

仮説・検証（50）作業診断(process assessment)を成功させる５つの鍵。失敗する５つの罠
https://qiita.com/kaizen_nagoya/items/bcdc60db20e8d7081fab

仮説・検証（51）公開算譜は機敏だ(open source is agile)GitHub and docker
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e

仮説・検証（53）日本のプログラマが世界で戦える10個の事例
https://qiita.com/kaizen_nagoya/items/a7e634a996cdd02bc53b

仮説・検証（124）IT系勉強会をすべて当たりにする方法
https://qiita.com/kaizen_nagoya/items/9f001a79ab4162220406

仮説・検証（139）新人(学生)を指導するよりも新人(学生)に指導してもらった方が効率的
https://qiita.com/kaizen_nagoya/items/db993b1536055029f7c8

IT教育の基本としてきたこと
https://qiita.com/kaizen_nagoya/items/efeed472847aa4fcc835

文書履歴(document history)

ver. 0.01 初稿 20200208 午後
ver. 0.02 湊真一　追記 20200208 夜
ver. 0.03 書籍　12ステップで作る組込みOS自作入門　詳解LAPLACE変換演習追記 20200209 午前
ver. 0.04 DataRobot追記 20200209 午後
ver. 0.05 URL追記 20200209 夜
ver. 0.06 色、音、自然言語追記 20200209 深夜
ver. 0.07 参考資料追記 20200210 朝
ver. 0.08 見出し番号補正 20200210 午前 10時
ver. 0.09 見出し英語追記 20200210 午前 11時
ver. 0.10 英語標題追記 20200210 午後２時
ver. 0.11 補足 20200210 午後３時
ver. 0.12 分野追記 20200210 午後５時
ver. 0.13 背景、前提追記 20200210 午後１０時
ver. 0.14 事例追記 20200210 午後１１時
ver. 0.15 @scivolaさんの指摘により綴り訂正　algorithm 20200210 午後９時
ver. 0.16 表題追記 20200229
ver. 0.17 @sk4869pw4869　さんの記事に基づき表題変更 20200311

https://b.hatena.ne.jp/guide/bbutton