4．プログラミングとは、実際のところ何なのか

スキル

» 2010/10/26

●前回の「自転車とプログラミングと」

 前回は、「きちんと見」ないでも構わない理由を述べました。今回は、（いままで定義していなかった）「プログラミング」というものについて持論をお話しします。

●おことわり

　今回、コラムニストの機会をいただき、こうしていろいろお話ししているわけですが、少々戸惑われたかもしれません。なんで、急にこんなことを言うやつが現れたのかと。

　でも、筆者からすると、それなりに理屈があります。

　自分は10代のころ、出たてのMZ-80Cを購入し、インタプリタ Pascal SP-4010をいじりまくっていました。SP-4010は30KByte程度のソフトで、GoToレスで関数定義もなく、もちろんcontinueやbreak相当の機能もありません。メモリは48KByteで、ワーク領域は主VRAM（D000番地から）に文字コードで記録しました（そうすると計算過程がすべて画面に出るので都合がよかったのです）。

　そのような言語なので、

• 前処理
• 前処理の次の処理への処理
• 判定
• 主処理
• 主処理の次の処理への処理
• 後処理

を、ひたすらやり続ける以外、うまくいく方法がありませんでした。それで、七並べやLU分解などをやっていました。

　そうこうしているうち、この業界の仕事に携わることになりました。Pascal SP-4010ですでにやっていたため、オフコン（FACOM-Vでした）のCOBOLプログラムが理解できてしまったのでした。

　このようなことは、自分より2～3歳でも年配の方ではあり得ないはずです。「仕事を始める前にMZやPC-8000シリーズが発売されている」ということが、時系列からいってあり得ないからです。もちろんTK-80シリーズはあったでしょうが、それで高級言語を学ぶということは、一般の人間には不可能です。

　これまでの人は、数千万円単位の出資をしてもらって学び、その代わりにそれなりの引き回しを受けて仕事をしていたと思います。そうすると、

• 仕事関係について、ほんのわずかでも否定的なことは言えない（他人の義理がある。「閉じて発展しない」などと考えるのも不遜）
• それなりに引き回してもらえるので、そもそも否定的なことを考える必要がない

はずです。

　そういう人は、このコラムのようなことは思いつかないでしょう（「コボラー」などという蔑称も、それなりの引き回しを受けていた人が、IT Doesn't Matterとなった影響で後ろ盾を失い、いままですごかった分、必要以上にけなされただけというのが真相かもしれません。筆者など、いい目を見ていないのにCOBOLのプログラミングをしていただけで「コボラー」扱いされ、非常に損をしました）。

　とにかく、このような他人をエンカレッジするわけでもない執筆活動は、それなりに先が見えてしまわないとできないはずです。なにか志が残っているなら、こんな目立ちたがりなことはしないはずです。すると、どうしても50歳に手が届くくらいの年齢となるのです。

　MZやPCが出てから約30年。それがいまなのです。お分かりでしょうか？

●プログラミング

　プログラミングは、プログラマがする知的作業で、全体から見ると下流工程です。

　仕様が固まってからプログラミングをし、単体テスト程度までするのが特徴です。

　その作業での入力は（要求）仕様ですが、実際のところ、仕様は機能単位では来ません。（要求）仕様を作る人も、機能と整合が取れるように配慮してくれるかもしれませんが、機能単位に見えて、実は「たまたま同じタイミングで起こる」複数の機能の「混載」状態であるのが普通です（ユーザーインターフェイスを伴う設計で、画面単位に設計するとよいというのも、これのせいだと思います）。

　なぜならば、プログラム内部における本当の意味での機能は、本質的に「見えない」からです。

　プログラムは、異常終了せず滑らかにつるつると動くことを求められていますが、これを成し遂げるためには、ユーザーが画面などを見る前に処理が終わっていなければならないし、ユーザーがアクションを起こした後に処理が始まらないといけないのです。

　ユーザーのターンで必要なことと、プログラムのターンで必要なことが密接に関連しているのは確かですが、ユーザーエクスペリエンスで必要な機能（人間なので技能でしょうか）と、プログラムで必要な機能は、

• 何も関係ないか
• お互いにひっくり返って見える関係か
• わけの分からない関係

となる以外ないのです。

●仕様を出す人に求めること

　前段落でお話しした内容から導き出されることとして、「仕様を出す人に機能単位を求めることは、プログラミングに『きちんと見』て分かる資料を求めることと同じで、不当である」のは事実だと思います（歴史的に見て、プログラマに「きちんと見」て分かる資料を求めるのは、仕様を出す人に、機能単位を求めることへの対抗措置／報復措置かもしれないとも思っています）。

　もちろん、「混載」状態単位の実体（関数など）をプレイスホルダ化して、実際の処理は、機能単位の別モジュールを呼ぶだけにすることは可能なはず。

　ところが、「きちんと見える」ことを求める人は、ややもするとこれを禁止します（実際そういう事実が有りました）。

　そうして、「正式な」資料との1対1対応を求めるのです。何も関係ないか、お互いにひっくり返って見える関係か、わけの分からない関係である切り口から得た一覧にすべてを合わせろと言われては、自分としては腹を仰向けにごろんとして「わたしは無能です。いかようにでもしてください」という以外ありません。

　前々回申し上げたとおり、「トピック単位」を超えた「見て分かる」図は、絶対に不可能なので、それとの1対1対応も不可能です。

●機能単位とは

　機能単位とは、人間にとって不自然です。しかし、最終的にその形で整理しないと保守できなくなります。つまり、言い換えるなら、機能単位とは「絶対に試行錯誤を必要とする」切り口です。人間にとって不自然なので、「一覧にしたとおりに実現でき」ない切り口です。

　そんなしるべのない切り口で作業を進めるのは、錯綜（さくそう）した車道の中に自転車で飛び込むもようなもの。1つひとつがやたら断片的で、人間的関係のような達成感がない。きちんと見る前に次をコーディングし、また次をコーディングする。まさに情報を貪って消費する「オタク」の世界です。

　こんな中をどうやって進んでいけばいいのでしょう。

●別の「見方」（プログラミングに有利な「見方」）

　さて、プログラミングで、「きちんと見る」すなわち、「いつも変わらず、『見る』という同じ規則を適用する」ことが不利だと言ってしまった以上、別の認知方法を示す必要があります。

　わたしは、『一階上から目線で見る』ことだと思います。一階述語論理の範囲で上から目線で見るのです。「なんだ、やっぱり見るじゃないか」と当然突っ込まれると思いますが、それは違います。それが『上から目線で見る』以上、『見る』とは違います。

　上から目線で見ている人は、「きちんと見て」いないからです(笑)。

　日常生活で現実をきちんと見ず、上から目線で見ることはかなり危ういですが、違うエスニックを対象として、閉じて発展しない世界を扱うプログラミングの分野では、妥当至極なのです。しかもたんなる上から目線ではなく、定義された『一階（述語理論の範囲での）上から目線』ならば、完全に穏当です。

　『一階上から目線で見る』とは要するに、

• いくつかやってみて、
• （閉じて発展しない世界での）すべてを思い描く

ことです。非常にたくさんの対象を扱う際に人間ができるのは、これ以外ありません。

　まぁ、今回はこんなところです。次回は、「結局、皆『もれぬけ』を恐れる」、について考察したいと思います（コラムを始めるに際して書いた目次案がなくなってきてしまったので、次のコラムを上梓するのは、ちょっと先かもしれません）。

●コラムのコメント欄の方針

　コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。

　ですので、このコラムで、

• わたしは基本的にコメントに答えない
• コメントを書く人は、回答がない前提で議論を進めていただく

とさせていただきます。