プログラミングとマニュアルを作成すること

ロジックをつなげて流れを作り出し１つのアウトプットを出すという行いは、文章を書いて１つのエントリなり日記なりを書くという行いと、相当の部分が似ていると私も感じます。

プログラミングと文章を書くこと - GoTheDistance

プログラミングは文章を書くことというのは半分正解で半分間違いだと思います。プログラミングそのものには起承転結は必要ありません。

相手は機械ですので、指示したとおりに動きます。なので、その指示をするプログラムは、単純に言えば、どう動かせば自分が望むことをやってくれるかを書く作業であると言えます。

これってマニュアル作りに通じるところがあって、マニュアルは人を動かすために書くものです。
機械と人の差はあれど、その根本は変わらないと私は考えます。

ただし、もちろん違いはあって、マニュアルは多少の不備があっても人が補完してくれますが、プログラムはそうは行きません。ですから、プログラムを書く人はマニュアルを書く以上の正確性を求められます。

でもこれ逆から見ると、面白い着眼点になっていて、プログラムをバグを少なく書ける人はマニュアルを正確に作ることができるということを意味しているんですよね。

他にもプログラムとマニュアルの違いはあり、それは動かす対象の性質の違いです。人は正確に、また一つのことに集中して物事を行うのが苦手ですが、逆に機械は状況に応じて柔軟に対応するのが苦手です。対象の違いにより作り方は違います。

でも、機械の中にも得手不得手があります。例えば関数型のプログラム言語とオブジェクト思考型のプログラム言語では効率良く書ける書き方が違います。また、従来のコンピュータと量子コンピュータでは得意とする分野が違います。詳しくは知りませんが、因数分解が得意らしいですね、量子。あとパイプライン処理を多段持っているアーキテクチャーとそうでないものでは早い書き方はまた違うらしい。知るかって感じですが。

しかし、結局、マニュアルも対象とする人の専門性や気質に対し、より良い方法が違います。

プログラムそのものが上手く書ける人は、マニュアル作りが上手い人になれそうです。

文章を作るのに近いのは、ツール・サービス・アプリケーション・システムを作ることだと思います。

どうしてそのツールを作るのか。どうして現在の社会に必要なのか。どのくらいの期間規模で作ることができるのか。そのツールが生まれることで何が変わるのか。そして、それを実現する具体的な方法（プログラム）は何か。

一種のストーリーになっています。どうやってツールを意義あるものにするか。文章と近いのは、むしろここなんじゃないかなと思っているのでした。

あと、僕はSIer屋さんではないので想像でしかないですが、SIer屋さんに限って、文章とプログラムは近いという考えも理解できなくはありません。SIer屋さんは、プログラムのロジックをプログラムが分からない顧客に見せなければならなりません。顧客により理解して頂くために、プログラムにストーリーを入れることもあるでしょう。例え、速度を犠牲にしてでも。だから、プログラムが文章に見えるのかもしれません。