理解者を求めたいのに、求められない孤独。
他人との「あるある」の共有が、出来る部分と出来ない部分。
将棋で、何手先まで、先読みするか？について私は１手先すら読むのが困難です。超人的に数手先まで読み通せる人が居ると聞くと、驚嘆するしかありません。そういう、数手先を読み通せる人と会話しても、多分話は合わないと思います。２手先すら私の想像力では到達できず、話の内容を理解できないと思います。将棋の経験が少ないので、あるシーンで「此処で迷うよね」と言われてもそのシーンを経験していないので、解りません。
聞きかじりの話ですが、水先案内人（パイロット）に関する話で、こんな話を聞いたことがあります。
それは、水面下の地形が時々変化する水域での水先案内人たちの会話だったそうです。ある熟練の水先案内人がこう言っていたそうです。『「この水域の仕事で、ミスはしたことはない。」と言っている奴がいたら、その水先案内人は駆け出しだ。』
この発言の裏にあるのは、長年仕事をしていると、何らかの問題に遭遇するのを避けられないはずだから、問題に遭遇したことが無いと言うのは、回数がまだ少ないはずだ。言う事だと思います。
ミスゼロを自慢している人がいたら、あなたはどう思い、どう対応しますか？。
ミスゼロを自慢する人に対して、素人呼ばわりをしたら、喧嘩になるかもしれないので、自分の心では、「素人か、スーパーマンか、強力な助っ人が居るんだろう」と思っておいて、「そりゃーすごいなー」と褒めるなどするのではないでしょうか。
素人か、スーパーマンか？については、普段付き合っていくとだんだん見える部分があると思います。
スーパーマンではないと確信できた時に、思うのは、「じゃ、なぜ、ミスがゼロなのだろう？」過去の仕事をさかのぼって、経験が浅いのだと判明すれば、素人だったと言う事になるが、経験値としての仕事の数が相当数あるとしたら、ミスをゼロに抑えた理由について興味が湧いてきます。 ミスを出さない仕事術とかセオリーとかが 存在するのか？強力な助っ人が存在するのか？
現代は、仕事術とか、セオリーとか、強力な助っ人というのが、ネットやITツールだと言う事はありえるわけです。
自分で全てを学び、技量を磨いて、ITツールを作ることが出来ない場合、よその誰かが作成したツールを用いるより無いのですが、そのツールの安全性を誰が確認し、誰が誰に責任を持つかについて、厳密にしようとすると、ちょっと大変なんです。
その製品の開発に必要だった設計書一式を見せてくれとか、そのソフトのソースコードを全部見せてくれとか、試験結果や検証結果のデータも提供してくれとかそう言うお願いをしても、無料提供は期待薄ですし、仮に提供してもらっても読みこなせるか？と思うと、自分が書いたわけでもない他人の書いた設計書やソースコードを読みこなさないといけないし、読みこなして、どう言うシーンで、何が起きるかを把握できないと読む意味がありませんし、将棋で２手先の会話が出来ないレベルでは、プログラムのソースコードを全部読みこなして、あるシーンにおける、ソフトの挙動について把握できているかとか、言ったって無理な話でしょ。
ソースコードを読みこなして、挙動を推論できたら、バグが出るはずがないわけですから、バグ対処のパッチが出てくるはずがない。しかし、何処のメーカーでもバグ対処や機能改善などのパッチやバージョンアップはやっていますから、設計書とソースコードも含め一式揃っていたって、どう言う挙動が何処で出るかについて読みきれなかったと言うことでしょ。
つまり、設計書もソースコードも手に入れることが困難な一般利用者が、メーカーに成り代わり、机上デバッグに匹敵する問題の摘出作業を出来るのか？。と考えると、無理なはずなんです。
じゃ、実行モジュールだけ提供を受けて、全部の挙動を把握するにはどうしたらいいか？などと考えた場合に、手元にあるのは、実行モジュールのマシン語ぐらいしかないので、マシン語によるCPUとシステムの挙動を逐一モニタリングし解析する作業になるので、より高度なデバッグ検証環境の構築が必要になり、より一層素人には無理な話でしょ。
そういうことで、ソフトの挙動を見るには、実行モジュールだけではなくて、さらに設計書とソースコード一式が必要になるはずなのです。
そして、そのプログラム言語を読みこなすことが必要になります。
そして、そのプログラム言語は、コンパイラーでコンパイルされるのですが、どう言うプラットフォームに向けてコンパイルされるか？が次に課題になります。
DOS/V向けなのか？メインフレーム向けなのか、ワークステーション向けなのか？
DOS／V向けとしてメジャーなOSはWindowsとLINUXとMAC-OSやその他があるかと思いますが、どのプラットフォーム向けにコンパイルされたバイナリー（実行モジュール、マシン語）なのか、を知る必要が有ります。その理由は、コンパイラはターゲットのプラットフォームごとに生成物を変えるので、どのプラットフォーム向けかを知る必要が有ります。
そのソースコードを、コンパイルしても、その実行モジュールが生成されないなどということになったら、嘘のソースコードを提供されたのか？という事にもなりますので、そのソースコードをこのコンパイルオプションでコンパイルすると、確かにその実行モジュールが生成されるのだと、確認をされるべきだと思います。
そして、プラットフォームが判ったら、システムコールを知る必要が有ります。
その理由はソフトを組む場合に、初期化とか、自分で関数を定義したりしますが、此処のステートメントや組み込み関数などはコンパイラーがOSのシステムコールを多用していますので、そのコンパイラーはどう言うコンパイル結果を生成すべきかを理解していないと実行モジュールの出力に、本来無いはずのコードが含まれているとか、あるはずのコードがないとかを見抜けません。でもコンパイラーまで自社製造しているケースはまれですからコンパイラー無料利用では、問題のある出力について、責任の所在をとえません。
また、コンパイラーはプラットフォームとなるOSにターゲットを絞って、コードを生成してきますが、生成されたシステムコールが実際に処理されるのはOSのシステムコール処理で処理されますから、OSの信頼性を誰が確認し、誰が誰に責任を持つのかということになると思いますが。
基本的には、利用許諾を出してもらっているぐらいでしか無くて、基本自己責任で使っているのではないでしょうか。
効率化と省力化と経費節減を錦の御旗としてITを進めると思いますが、本質的に経費節減になるか？と言うと、疑問は多いと思います。
企業においては、競合他社との差別化のために、莫大な開発投資を行い新商品開発を行っていると思いますが、ITを利用することで、他の企業に対する優位性になるはずの特許なり企業秘密が外部に流出してはいけないのですが、開発中の段階から外部に出ているとかだと、最後の追い込み段階で先を越されるかもしれませんし過去の研究の膨大なデータを元に、よその企業が、先に何かを発見するかもしれません。
そう言う事を考えた場合、勤怠管理と言う単純なシステムですら、そのソフトの構成要素の全てに目を通して問題がない事を確認するべきですが、コンパイラーやOSまで、安全確認をするというのは、たやすいことではありません。膨大な検証環境と検証工数が必要になると思われます。
今後ますますITは、人間生活や世界の存在に、重要な関わりを持ってきますが、新製品の開発を自社一社で完結して行うとか、一つの国で完結して行うのは多分無理なのだろうと思います。国際分業体制が前提になると思います。
ITは複雑化と高度化を今後ますます高めていくと思いますが、一個人がその中の何％に目を通せるか？理解できるか、検証できるか？を考えると、ますます大変になると思います。
日常のITシステムに、不用意に、悪意のコードやまずいコードが紛れ込んでは困るのですが、インターネットは世界を包んでいて、個人所有のインターネット接続のあるデバイスには、世界中からそして、世界中にアクセスが可能な状態ですから、インターネットに関わる国すべての人が等しく、安全を心がけていける社会が必要になると思います。
ITで飯を食うには、いがみ合っていない世界の存在が前提であり、悪意を起こすテロ集団も存在しない社会や世界が前提になると思います。
世界がいがみ合っていて、悪意のコードが、いつ紛れ込むかわからない状況では、自社製品に対してさえ、顧客に対する訴求力を強く出せません。
「金を払ってくれれば、ソフトやシステムを使ってもいいけど、使う事で問題が起きても知らないよ、とも言えないので、払ってくれた金額を上限に返金に応じないでもないけど、きちんと裁判しようね」とかそういうことになるんでしょ。でもこれでは訴求力が低い。
だけど、訴求力を高めようとして、へたに安心・安全を謳い文句にしてしまうと、本来保護できない機密でさえ載せても大丈夫だと勘違いする人が出てきて、やがて、とんでもない事になるので、ハッタリかます事も出来ない。
世界を混迷に導かないように、どうすると良いのか？。
と言う課題について議論を持ちかけても、ソフト開発の経験者でないと、状況を理解できないので、議論にならない。
この世の未来を予測するには、マシン語を理解し、OSを理解し、コンパイラーを理解し、各種プログラミング言語を理解し、ソフト開発の、A-Zを知り、人間の特性を知っていないと、「あるある談義」は出来ないと思えて。
余談
＜DLL：ダイナミックリンクライブラリー＞
プログラムを組み動かすメカニズムにおいて、関数定義をすることがあると思います。
定義した関数を呼ぶ処理が入ったプロセスが複数ある場合に、例えば、５個あったとして、その５個のプロセスのコンパイルとリンケージにおいてそのプロセス内部にその関数をもたせるようにすると。その５個それぞれでその関数のコードを持つことになります。ですから、単純に考えるとメモリ消費の観点ではそれぞれ５個のプロセス内部にその関数のコードがあるということです。メモリ節約をしたい場合に、５個のプロセスの中にその関数のコードをもたせるのではなくて、切り出してしまえば、メモリ消費を減らせるのではないか？と言う事で、ダイナミックリンクライブラリーと言う名称のフィアルに切りだすと、メモリの節約が出来るんです。切り出す関数の名称をfunc_aと言う名前だとして、切り出した関数のコードを、A.DLLと言うダイナミックリンクライブラリーに入れてあるとしたら、関数をコールする処理を持つ５個のプロセスでは、A.DLLの中にある関数func_aをコールすると書いてあるんです。５個のプロセスは内部に、func_aのコードは持ちませんから、その分メモリの節約ができるのです。
さて、A.DLLと言うなのダイナミックリンクライブラリーにfunc_aと言う関数が収まっている。わけなんですが、
純正じゃないA.DLLてのを提供できなくもない。わけなんです。
自分が作った、A．DLLが純正だとして、他人が作ったA.DLLが存在する場合があるんです。過去にあった事例では、DLLの入れ替えで、問題動作が改善したとか発生したとか。
昨今この、DLLのメカニズムは、安全性を高められてきては居ますが、利用者個人でDLLを入れ替えることは不可能じゃないと思います。
func_aを呼ぶプロセスは呼ぶだけ、DLLにはfunc_aのコードが収まっている。
仮に暗号化関数に合鍵付きの関数と、合鍵なしの関数があったとして、本来は合鍵なしの暗号化関数がfunc_aで収まっているべきところを、合鍵付きの関数といれかえて、名前をfunc_aにした、改造版DLLを、罠の解説WEBを参照して、DLLファイルを入れ替えると、まずい事態になりますよね。
と言う事で過去を振り返った時に、結構安易に、DLLの入れ替えとか、何処かのサイトからのダウンロードとか、指南されているのですが、誰が安全を確認しているのか？と言うと、それは、自己責任。だと思うのです。
利用者個人の責任で持って、入れる。ということだったと思うのです。
しかし、一般的個人が、マシン語コードの検証設備やスキルを持っているはずがない。
が、解決策は提供されていない。
と。
ということは、利用者は、世界の誠意と善意を信じている。ということですよね。
だから、世界は平和でないと、まずいことになるわけなんです。
＜蛇足＞
ITとは、次のいずれなのだろうと言う悩みが晴れません。
「信じるものは救われる」
「信じるものは(足を)すくわれる」