前回は、「きちんと見」ないでも構わない理由を述べました。今回は、(いままで定義していなかった)「プログラミング」というものについて持論をお話しします。●おことわり今回、コラムニストの機会をいただき、こうしていろいろお話ししているわけですが、少々戸惑われたかもしれません。なんで、急にこんなことを言うやつが現れたのかと。筆者からすると、それなりに理屈があります。SP-4010をいじりまくっていました。SP-4010は30KByte程度のソフトで、GoToレスで関数定義もなく、もちろんcontinueやbreak相当の機能もありません。メモリは48KByteで、ワーク領域は主VRAM(D000番地から)に文字コードで記録しました(そうすると計算過程がすべて画面に出るので都合がよかったのです)。後処理を、ひたすらやり続ける以外、うまくいく方法がありませんでした。それで、七並べやLU分解などをやっていました。しているうち、この業界の仕事に携わることになりました。SP-4010ですでにやっていたため、オフコン(FACOM-Vでした)のCOBOLプログラムが理解できてしまったのでした。このようなことは、自分より2~3歳でも年配の方ではあり得ないはずです。「仕事を始める前にMZやPC-8000シリーズが発売されている」ということが、時系列からいってあり得ないからです。TK-80シリーズはあったでしょうが、それで高級言語を学ぶということは、一般の人間には不可能です。これまでの人は、数千万円単位の出資をしてもらって学び、その代わりにそれなりの引き回しを受けて仕事をしていたと思います。仕事関係について、ほんのわずかでも否定的なことは言えない(他人の義理がある。「閉じて発展しない」などと考えるのも不遜)それなりに引き回してもらえるので、そもそも否定的なことを考える必要がないはずです。Matterとなった影響で後ろ盾を失い、いままですごかった分、必要以上にけなされただけというのが真相かもしれません。筆者など、いい目を見ていないのにCOBOLのプログラミングをしていただけで「コボラー」扱いされ、非常に損をしました)。このような他人をエンカレッジするわけでもない執筆活動は、それなりに先が見えてしまわないとできないはずです。なにか志が残っているなら、こんな目立ちたがりなことはしないはずです。すると、どうしても50歳に手が届くくらいの年齢となるのです。MZやPCが出てから約30年。お分かりでしょうか?●プログラミングプログラミングは、プログラマがする知的作業で、全体から見ると下流工程です。仕様が固まってからプログラミングをし、単体テスト程度までするのが特徴です。その作業での入力は(要求)仕様ですが、実際のところ、仕様は機能単位では来ません。(要求)仕様を作る人も、機能と整合が取れるように配慮してくれるかもしれませんが、機能単位に見えて、実は「たまたま同じタイミングで起こる」複数の機能の「混載」状態であるのが普通です(ユーザーインターフェイスを伴う設計で、画面単位に設計するとよいというのも、これのせいだと思います)。プログラム内部における本当の意味での機能は、本質的に「見えない」からです。プログラムは、異常終了せず滑らかにつるつると動くことを求められていますが、これを成し遂げるためには、ユーザーが画面などを見る前に処理が終わっていなければならないし、ユーザーがアクションを起こした後に処理が始まらないといけないのです。何も関係ないかお互いにひっくり返って見える関係かわけの分からない関係となる以外ないのです。●仕様を出す人に求めること前段落でお話しした内容から導き出されることとして、「仕様を出す人に機能単位を求めることは、プログラミングに『きちんと見』て分かる資料を求めることと同じで、不当である」のは事実だと思います(歴史的に見て、プログラマに「きちんと見」て分かる資料を求めるのは、仕様を出す人に、機能単位を求めることへの対抗措置/報復措置かもしれないとも思っています)。実体(関数など)をプレイスホルダ化して、実際の処理は、機能単位の別モジュールを呼ぶだけにすることは可能なはず。ところが、「きちんと見える」ことを求める人は、ややもするとこれを禁止します(実際そういう事実が有りました)。して、「正式な」資料との1対1対応を求めるのです。何も関係ないか、お互いにひっくり返って見える関係か、わけの分からない関係である切り口から得た一覧にすべてを合わせろと言われては、自分としては腹を仰向けにごろんとして「わたしは無能です。いかようにでもしてください」という以外ありません。前々回申し上げたとおり、「トピック単位」を超えた「見て分かる」図は、絶対に不可能なので、それとの1対1対応も不可能です。●機能単位とは機能単位とは、人間にとって不自然です。最終的にその形で整理しないと保守できなくなります。言い換えるなら、機能単位とは「絶対に試行錯誤を必要とする」切り口です。人間にとって不自然なので、「一覧にしたとおりに実現でき」ない切り口です。そんなしるべのない切り口で作業を進めるのは、錯綜(さくそう)した車道の中に自転車で飛び込むもようなもの。1つひとつがやたら断片的で、人間的関係のような達成感がない。見る前に次をコーディングし、また次をコーディングする。情報を貪って消費する「オタク」の世界です。こんな中をどうやって進んでいけばいいのでしょう。●別の「見方」(プログラミングに有利な「見方」)さて、プログラミングで、「きちんと見る」すなわち、「いつも変わらず、『見る』という同じ規則を適用する」ことが不利だと言ってしまった以上、別の認知方法を示す必要があります。わたしは、『一階上から目線で見る』ことだと思います。一階述語論理の範囲で上から目線で見るのです。「なんだ、やっぱり見るじゃないか」と当然突っ込まれると思いますが、それは違います。それが『上から目線で見る』以上、『見る』とは違います。上から目線で見ている人は、「きちんと見て」いないからです(笑)。日常生活で現実をきちんと見ず、上から目線で見ることはかなり危ういですが、違うエスニックを対象として、閉じて発展しない世界を扱うプログラミングの分野では、妥当至極なのです。たんなる上から目線ではなく、定義された『一階(述語理論の範囲での)上から目線』ならば、完全に穏当です。『一階上から目線で見る』とは要するに、いくつかやってみて、(閉じて発展しない世界での)すべてを思い描くことです。非常にたくさんの対象を扱う際に人間ができるのは、これ以外ありません。今回はこんなところです。次回は、「結局、皆『もれぬけ』を恐れる」、について考察したいと思います(コラムを始めるに際して書いた目次案がなくなってきてしまったので、次のコラムを上梓するのは、ちょっと先かもしれません)。●コラムのコメント欄の方針コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。このコラムで、わたしは基本的にコメントに答えないコメントを書く人は、回答がない前提で議論を進めていただくとさせていただきます。私は「仕様」と「願望」は区別したいと考えている人です。機能単位が切り出せない「仕様」はどう考えても「願望」です。サーバSとクライアントCがあったとして、CにあるデータをSの持つデータで暗号化してCに一時保管するような意味内容の「一見仕様」は「願望」というべきです。Sの持つデータがCに物理的法則を無視して「ワープ」せざるえないからです。機能単位というからには、入出力ぐらいは考えてしかるべきです。入出力データさえ示せない「仕様」を見ても意味がありません。よって「プログラミングに『きちんと見』て分かる資料を求めることと同じで」とありますが、工程が違うので、粒度をどのぐらいに保つにかについては、同じにはなりえないと思います。「仕様」は絶対に「機能単位」に切り出せます。いつも悩むのはどこまでを「願望」から「仕様」を機能単位として切り出すか、です。細かすぎると極端に言えばコーディングになってしまうし、あいまいすぎると単なる願望から抜けてない。だいたい作業として切り出せたらいいことにして切り上げてますが。少なくとも、「仕様」を「機能単位」に切り出だせない、と考えるのには反対です。完全には切り出すとコーディングになってしまうので適度にとめるべきだというのには多少賛成します。関係ないけど、いまでも「機能設計」ってやってるのかなぁ。名前を記憶しておくコメント:くわぢ初めてのPCはMZ-80Cでした。終わるまで」とか習わされました。書籍「誰でも身につく!暗算力」を読んでみた。未成年者略取ムチャか?男気か?部下も立て続けに。利用規約ITmediaはアイティメディア株式会社の登録商標です。