筆者は今まで誤解していたことが有りました。それは、V字モデル（引用：http://ja.wikipedia.org/wiki/V%E3%83%A2%E3%83%87%E3%83%AB）についてです。

　誤解していたこととは、「V字モデルは『基本設計⇔システムテスト』が頂点だと思っていた」ことです。自分が誤解していたから言うわけではないですが、案外、この件については皆そのように思っているのではないかと思います。

●誤解に気付いたきっかけ

　誤解に気付いたきっかけは、仕事でプログラムの修正に関する合意文書をお客さまと作っていたときのことでした。筆者は意気込んでUML 2.0のアクティビティ図を書き、最も上位の概略から説明しようとしました。

　しかし、「このような内容は、お客さんの関心事ではない」とばっさり切られてしまいました。そして、代わりに模範例として提示されたのは、いくつかの散文的で網羅されていないルールのような記述でした。もちろんそれが「ビジネスルール」とか「業務知識」とかで括られる内容だというのはすぐ分かりましたが、納得はいきませんでした。

　その後、「そのような内容が最も根本的だとしたら、V字モデルの2つの上は『基本設計⇔システムテスト』では変ではないか」と思い、「しめしめ、これでコラムに書く内容ができた。タイトルはさしずめ『V字モデルの2つの上』だろう。もっと別の何かが2つの上に来なければおかしいではないか！！」「よく最終テストになってから、聞いても居ない指摘がごっそり入り、費用が嵩むのは、『基本設計⇔システムテスト』が頂点だと思い込んでいるからではないか！！  これでコラムもう一本！！」とか思ったのですが、その直後Wikipediaの内容を見て、「早まったことをしなくて良かった」と思った次第です。

　『要求分析⇔受け入れテスト』がV字モデルの2つの頂点だとしたら、確かにお客さまとの合意文書でまず書くのは「ビジネスルール」とか「業務知識」とかで納得です。

●過去の経験を振り返って

　そう考えると、得心がいくことがありました。それは、初めて仕事に就いた新人の一部に共通した振る舞いです。

　筆者は受注ソフトのアプリケーションプログラマなので、もちろん最重要なものは「ビジネスルール」や「業務知識」です。ですから、新人にもそれを主に伝えることになります。しかし、すべての新人は判を押したように、それに対して「そんなことを聞きたいのではない！」「商用の現行システムなのだから、もっと基本的なことを教えるべきだ！」と、（ぼそっと）言って、こちらの言うことには耳を貸さないのが普通です。

　「ビジネスルール」や「業務知識」は、

• どんなに他の知識が普及したとしても、こればかりはオープンにならない（ただし、「こことここを足してここに書き込め」程度の内容の「決めごと」なので、秘密にしたとしても人類に対する不義理だというものではありません）。
• 少なからず、頭を下げて、気まずい思いをして得た知識であることも多い。
• 隠しておいた方が古株にとって有利であるようなことでも、「属人的にならないように」との覚悟で教えている。

など、それらを新人のころに教えられるというのは、最高のもてなしで遇されたと解すべきものです。あーそれなのに、それなのに……。

　まぁ、そもそも、わけも分からずソフト開発に対して切磋琢磨せず、無目的に入ってきた大人の未経験者に何かアドバイスをして、ものになる人間ができると思う時点で傲慢（ごうまん）なのかもしれませんが、それにしても悔しい話です。

　その悔しい話ですが、それら新人も（筆者と同じように）V字モデルすなわち、システムの概略について、（筆者と同じような）誤解をしていたとしたら、たしかにつじつまが合います。要するにシステムの頂点とは『基本設計⇔システムテスト』だと思い込んでいるとしたら、です。

　第一、普通の業務ソフトで、そんな目の覚めるような「基本設計」があると思うのが間違いです。DevOpsなどを持ち出すまでもなく、システムは運用をできるようにするのが大前提で、それゆえ、プログラムはまず同じタイミングで行われる複数の動作の渾然一体（こんぜんいったい）の塊です。プログラムを「システム」として見たいのなら、いちいちスライシングしないとまったく見えないでしょう。毎回毎回、そのようなないものをねだるのは、合法的にサボろうとしているようにしか見えないのは年のせいでしょうか？

まぁ、今回はこんな所です。

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

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

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

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

とさせていただきます。

　昔は、「プログラマも日報を書いていたな」と、ふと思い出しました。もちろん、いまでも「今日、何をやったか」というような日報は書いています。「何をやったか」は収支計算上のプロジェクト名だったり、工程名だったりします。それに対して、「プログラマの日報」は、もっと技術的な細かい内容を指します。

　ある時期から「書かなくてもよい」と指示されて日報を書かなくなったのですが、理由は以下のことだったのではないかと考えます。

• （特に初心者の）リーダーが技術的な細かい日報を見ても、「意味のないもの」「技術者の自己満足で、無駄」としか思えなかった
• 日報として提出されてしまうと、リーダーは対応を求められるが、とても対応できる数ではなかった
• 経験豊富な、管理職扱いの、今までの実績から収支に責任を持たない（多少の赤字を認められる）仕事をしても誰も文句を言わない、ぶっちゃけ暇な、技術系の人間がたくさんいてレビューしていたため、プログラマの日報のようなデータの蓄積はさほど必要なかった

　しかし、今振り返ってみますと、以下のように考えられます。

• 初心者のリーダーならそう思ったかもしれないが、同じ人が経験を経て、もう一度同じ内容を見たら、意味を見いだすに違いない（と筆者は考えます）
• すべての提出物を同等に処理する必要はなく、直属の上司は「データを蓄積する」だけとし、別工程（テスト作成など）で使用する資料としての利用でもいいはず
• 「経験豊富な、管理職扱いの……」人間がいなくなっていて、彼らがやってくれていたこと（識者の経験による問題点の洗い出しという、現行の開発のやり方で当てにしきっている部分）がなくなってきている為、簡単に作れる資料なら必要

●ビッグデータとインバリアント分析

　先日、雑誌を見ていると、「建造物などにセンサーをたくさん付けて、ビッグデータとして記録し、何か違いがあったら問題があるのではないかと疑う」という手法が書いてありました。筆者が「昔、日報を書いていた」ことを思い出したのも、その記事を読んで以下のように考えたからです。

• 付ければ簡単に情報が取れるセンサーを作ることは、現在の技術では難しく、その情報に代わるものは「昔書いていた、技術的な日報」ではないか？
• ビッグデータなら、資料のストレージとして最適でないか？
• 筆者が言う昔とは、「経験豊富な、管理職扱いの……」人間がまだあまりいなかったころのことで、（技術的な日報作成のような）その“昔”にやっていたことなら、これからの状況に合致するのではないか？

●どうするか

　インバリアント（プログラムで、何が同じで何が違うか←今の技術でこれを認知できるのはプログラムを書いた当人か、そのプログラムを精査した経験豊富な人間のみ）を考慮に入れて、とにかくつぶやけばいいと思います。もちろんオンプレミスなシステムへのつぶやきでいいと思います（さすがにパブリックのソーシャルメディアにつぶやくのは行き過ぎです）。

• いままで同じ処理を50個書いたが、51個目と52個目と53個目で初めて、違う処理方法が必要だった。
• 今日、自分はこのようにすごいHACKをした。

とかいちいち書くのです。

●なにが得なのか

　同じ処理なら何百個あろうと、テストは同じでいいと思います。しかし、何かが違う場合（例えばその処理にif文が1つかぶさるだけとか）でも、テストは格段に難しくなると思います。今までは、その困難さを経験豊かな技術者が陰から支援してくれていて、どこが問題なのかを指摘してくれるのは当たり前だと信じ切っていたと思います。しかし筆者の実感からして、間違いなくそのような素晴らしい世界はなくなってしまっていると思います。

　もちろん、このような細かい日報だと、とても見切れないものだとは思いますが、それはビッグデータの要約技術を使って、1つでも2つでもテストの方向付けとなる結果が得られるなら、素晴らしくない世界で1つの指針となると思います。

　また、筆者の経験から言って、「自分がその日寝る前に思い返して酔ってしまうような、すごいHACK」の過半数は改めて考えてみると、もっと単純な方法に書き直すべき内容だと気づくのが普通です。そのような細かい記録は、他人のためでもあると同時に、本人の振り返りにもなると思います。

　さらに、（いくら経っても具体的にどうやったらいいか書いておらず、もしやるとしてもどう考えてもプログラマに過度の負担がかかることが容易に予想される）テストファーストか、（昔、当たり前のようにやっていた）技術的な細かい日報かどちらか選べと言われたら、プログラマは大抵、後者を取ると思います。

　まぁ、今回はこんなところです。

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

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

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

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

とさせていただきます。

　「パロール」と「ラング」（『増15補足.実行可能って』で言及）について調べていたら、この本を見つけました。『「知」の欺瞞―ポストモダン思想における科学の濫用』アラン・ソーカル ジャン・ブリクモン著 岩波現代文庫です。読んでみたらなかなか面白かったので紹介します。

●内容

　ポストモダニズム（「モダニズムを批判する文化上の運動のこと」 Wikipedia 日本語版「ポストモダン」の項より）で語られる主張において、比喩は簡単な言葉を用い、誰でも分かるようにしないとならないのに、分かりにくい物理学などの理論を比喩として用い、権威付けをしているのはおかしいのではないかという内容です。

●面白く感じた点

　このコラムでは、今に至るまでプログラマである筆者がプログラムについて持論を述べてきたのですが、（特に増15や16など）ポストモダンの指導原理と似てきたように思います（相対主義だとか）。

　自分は一貫して理系で、高校のころエピステーメー叢書を2、3冊買って読んだ程度なのに、自然とそちらの方向に向かってしまうのは、もしかすると、ポストモダンと（“がりがり書く”狭義のでない、社会とのつながりも含めた）プログラミングに相通じる面があるからなのかもしれません。

　まぁ、今回はこんなところです。

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

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

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

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

とさせていただきます。

　先日、設計者と仕様について少々議論をしました。その際、「かけ算の順序」（Wikipedia 日本語版「かけ算の順序問題」など）の問題が話題になりました。

　Wikipediaの説明では、「『6人のこどもに、1人4こずつみかんをあたえたい。みかんはいくつあればよいでしょうか』という設問に対する、6 × 4 = 24 という式と答えを不正解にすべきか」という話です。わりと、有名な話だと思います。

　もちろん、筆者がその問題の理非を問う資格とかはないですし、当コラムではそれについて一切述べません。そうではなく、自分たちの中で話題になったのは、「この問題の起こり方が、仕様書を介した設計者とプログラマの間の悶着（もんちゃく）の起こり方と瓜二つだ」という点です。

　このところ、連投気味ですが、これについて意見をご披露いたします。

●原因は

　今回の議論は、

• 値の範囲を整数と指定された。
• しかし、その「整数」とはどう考えても1以上の整数のことを言っているとしか思えない。

というものです。それに対して、

• やっぱりこれは「自然数」であり、言っていることが変ではないか？

という（出るべくして出た）反論が起きました。

　要するに、“数学の言葉を再定義している”のが原因です。そして、「かけ算の順序」も同じことが原因だと思います（「×」の再定義が原因だと思います）。

●「間違いである。以上！」では何が問題か？

　まだ、小学校の授業のやり方は柔軟な対応が可能で、「こちらのやり方がだめならあちら」というふうにできるかも知れませんが、IT分野の設計者の作る仕様の場合、そうもいかないことがあります。

　たとえば「NULL」という言葉ですが、

• RDBでいうNULLを表す（試験での正解はこれだと思います）
• RDBでいうNULLまたは、空文字を表す（MSAccessなどで、テーブルを表示した場合、NULLが意図せず空文字に更新されてしまうことがあり、またテーブルをCSVを介して移動した場合にも、NULLが空文字になってしまう場合があるので、両方を同一視したい。VARCHAR2とかならこの問題はクリアされる）。
• RDBでいうNULLまたは、空文字または、半角全角スペースのみの文字列を表す（画面などで、左記3つは同じに見えるため、それらは同一視したい）。

というふうに、場合によって再定義しなければならない場合が頻繁に出ます。

　ここで「数学の言葉の再定義はあり得ない」とされてしまうと、設計者は動きが取れなくなりますし、プログラマも自由を奪われることになります。

●解法の自然な拡張なら……。

　これが「再定義」でなく、「解法の自然な拡張」なら何の問題もありません。

• 応答日を考慮した、日付と月数の足し算。

とか

• 月末日を考慮した、日付と月数の足し算。（Oracleの“ADD_MONTHS 関数”のような）

とかなら、単なる「＋」と共存できると思います。

ただ、そのためには

• 名前を別の（もっと限定的な）ものにする

とか

• 引数の型で区別する

とか複雑になります。プログラミングではもちろん常套手段としてやりますが、設計段階ではかえって分かりにくくなるので、やらないと思います。小学生に教える際にも同じような配慮がいるのかもしれません。

●プログラマの一員として

　プログラマの一員としては、

• 自治の範囲で数学の言葉の再定義は認める。
• その際、責任者はその再定義について十分な配慮をする。

程度の落としどころにしていただけると、本当に助かります。ITをなりわいとしている他の人も、そうだと筆者は思います。

まぁ、今回はこんなところです。

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

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

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

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

とさせていただきます。

　前回、『増15.逆問題の良さ』で、上流工程を「実行可能でない」、下流工程を「実行可能」と位置付けました。そして「実行可能でない」分だけ上流工程が俊敏であるとしました。どうもこの話は、「自転車とプログラミングと」というコラム全体に関わる問題のように思えてきました。それについて、少々説明します。

　なお、今回はこのコラムの以前の文書を多く参照しますので、

• “文参照〔回の番号〕”

でそれを表すこととします（例：“「有用性の高いコメント」とは〔増15〕”）。

●確率関係と因果関係

　“「お客さんの話は確率関係に近く、それを因果関係に変換することにより、電算機システムとして実装可能になる」〔増10〕”としましたが、「実行可能でない」は「確率関係」に、「実行可能」は「因果関係」にそれぞれ相当すると思います。

　そして、“専門家でない限り「聞かないと分からない」というのもあります。プログラミングの文脈に応じた圧縮があまりに高効率である〔3〕”と書きました。それは「確率関係」より「因果関係」の方がどうしても微に入り細に入る関係上、後者は、見やすさを（悪い言い方ですが）ある程度ないがしろにしているためだと思います。

　そしてその圧縮方法として、「実行可能でない」が「“文脈自由〔増13補足〕”」のに対し、「実行可能」は「文脈依存」であり、そのことにより圧縮を実現している、その代わり後者はその分、逐次読み進めていかないとわけが分からず、“結果（プログラム）が「一目見て分かる」ように直感的でない〔2〕”ようになってしまっていると思います。

　もちろん、見やすい方を扱う方（一目見て分かる方）が俊敏だと思います。

●文脈自由と文脈依存

　このコラムのそもそもの発端である、“「自転車などに乗っているときの『見方』の違い」〔1〕”とプログラミングの類似ですが、

• クロスバイクのような早い自転車は歩行者にない「車線」という概念を利用して情報を圧縮していることで速く走る
• プログラミングは設計段階にない「文脈依存」という概念を利用して情報を圧縮し「実行可能」としている

と定式化できると思います。

　クロスバイクは速いですが、「曲がれない、止まれない、縁石を乗り越えられない」といった感じで、とても俊敏かというと違うと思います。「実行可能」というのもそれと似たようなものではないでしょうか？

●他に

　文系の方で歴史的にある概念の、「パロール」と「ラング」というのももしかすると、「実行可能でない」と「実行可能」と対応付くかも知れません。この件は知ったかですが、もしこれが成り立つとすると、プログラミングについて昔からある議論を援用できる可能性も出ます（本当に知ったかですが……）。

まぁ、今回はこんなところです。

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

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

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

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

とさせていただきます。

　前回、『増１４補足.分担してプログラムを作る』で、「逆問題」について（割と否定的に）言及しました。しかし、後から考えてみると、逆問題も有用ではないかと思えてきました。

　それについて、それについて少々説明します（なお、「1.→2.」などの記法は前回の通りです）。

●上流工程の人は
前回、

1. お客さんは、「なになにを満たすすべて」がうまくいくことを要求。
2. 上流工程の人は、それでは他人に伝わらないので、指示を出す形式（仕様書のような）に変換。

とさらっと言いましたが、

1. 要求
2. 仕様

で、1.→2.のみの順問題を解くだけで仕様書が出来るとは考えづらいです。仕様を作るに当たって、ぶち当たった制限や、整理した結果得たひらめきなどから、1.←2.の逆問題も解いてお客さんの要求をリファインしているはずです。

　下流の人間に対しては、「（逆問題的なことにはかかわらず）言われたことだけやっていればいい」的な言い方しかされません。もちろん、別にそれはそれでいいのです。必要な「正しさ」を供給し続けてくれるなら。

　当然ですが、最後まで必要な正しさを供給してくれるなんてことはありません。ですから、下流の人間としても（表だってはしないとしても）裏で、ぶち当たった制限や、整理した結果得たひらめきなどから、2.←※3.の逆問題を解いて仕様をリファインし具申して、上流の人間の意欲が枯渇するのを少しでも遅らせる必要があります。

　※3：下流工程の人は、「その指示を満たす特定の」実装を作成（前回のコラム参照）。

　心の中だけで逆問題を解くのに、それまで妨げることのできる人間はいないと思います。

●やっぱ、この逆問題最高じゃん！

　しかしながら、衷心から申しますが、プログラムを入力とし逆問題を解いて得た知識のみから、個別の設計を超えるスコープの問題について発言するのは、絶対にするべきではありません。

なぜなら、

• 上流の人が1.→2.（時々1.←2.）の順問題（時々逆問題）で仕様を得るのと、下流の人が2.←3.の逆問題で仕様を得るのでは、労力に格段の差がつくため。もし10倍差が付くとすると、常時下流の人は9倍のただ働きを強いられることになり、絶対続かない。
• 仕様として同じ結果が得られるなら、設計のやり方で記述し結果を得る方が、プログラムのやり方で記述し結果を得るよりも、より俊敏である（ここで「設計」とは「実行可能でない設計」のことです。「実行可能な設計」はどう考えてもプログラム作成と同義です。「実行可能でない」分だけ「設計」が俊敏なのは当然です。UMLの規格で「定義されたポンチ絵としてのUML」を「実行可能により近いUML」に昇華させようとして、あまりに大変なことになったという例もあります）。
• 下流の人が2.←3.の逆問題を解いて仕様を得ても、その入力は“閉じた、発展しない”対象であるプログラムであり、「頭の固い技術者の考えそうな」仕様しか得られない（「実行可能」である為には、必然的に“閉じさせ、発展を止めさせる”必要があります）。

という不利を背負い込むことになるからです。この分野では、下流の人間が「言われたことだけやっていればいい」とされるのは、至極もっともです（残念ですが）。

　以前、『増 2．デスマ考』で、

5. その内、「権限がない中で仕様に介入する」ことが常態化し、安定的にデスマが発生する。権限がないので、営業の無理な発注にも対抗できない。
6. プログラムは「閉じた発展しない」ものなので、実情に合わなくなってくる。

と書いたのは、このことです。

●ではどうしましょう？

　プログラムのコメントの有用性を高めるのに「逆問題」という概念は使えると思います。そして有用性の高いコメントは他のプログラマに対しても、他工程に対しても、有利な結果をもたらすと思います。

ここでおれおれ定義です。

• 「有用性の高いコメント」とは、そのプログラムの（コメントの対象となる）部分について逆問題を解く時、助けになるコメントのこと。
• なお、ここで「助け」とは、より楽により正確にそれが解けること。

とします。

その「有用性の高いコメント」の作り方ですが、

1. プログラムを作る、今作ったプログラムを直す、前に（自分／他人が）作ったプログラムを直す
2. それをしたらすぐ、今したコーディングについて逆問題を解く。つまり、今作ったロジックを入力とし、その仕様を考える。
3. それをコメントに書く（考えたすべてでなく、後で助けになる程度に簡略化する方が望ましい）。

です。1を代入したロジックのコメントとして、「1を代入」ではなく、「初期値である1を代入」とか「こういう意味を持つ1を代入」とか書けば、より有用性が上がりますが、後2つを得るためには、どうしても逆問題を解く必要が有ります。

　しかし、今まさに作ったロジックの逆問題を解くことは、後で解くより圧倒的に有利だと思います。それをロジックを入力する度にやるのです。これなら、上流の人にも「余計なこと」だと言われないと思います（心の中だけの問題なので、文句の言いようがない）。

　まぁ、今回はこんなところです。

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

ですので、このコラムで、
　・わたしは基本的にコメントに答えない
　・コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。

　前々回、『増14．“テストファースト”と言われて』で、

• 一人でプログラムを作成する場合

と、

• 複数人で分担して作成する場合

を対比して提示しましたが、その（筆者の中での）背景の説明がなされていませんでした。年をまたぎましたが、それについて少々説明します。

●役割分担

　複数人で分担してプログラム（システム）を作る場合、全員が同じ仕事をするわけではありません。

1. お客さんは、「なになにを満たすすべて」がうまくいくことを要求。
2. 上流工程の人は、それでは他人に伝わらないので、指示を出す形式（仕様書のような）に変換。
3. 下流工程の人は、「その指示を満たす特定の」実装を作成。
4. テスト工程の人は、「その指示から正解値を実装と独立して得、その通りか調べる」。

ことになると思います。

　大抵、上流工程以上での議論は企業秘密、それに対し、下流工程での議論は世の中にこれほどのことは類例を見ないというほどオープンで、インターネット上でいろいろな知識が得られると思います（ただ、実際、下流工程で作成されたアプリケーションソフトの結果は、上流工程以上での情報を含んでいるので、どうしても秘密になります）。

　実は、上流工程以上と下流工程は、うまくかみ合っていません。オブジェクトモデルと、リレーションモデルのミスマッチなんて屁でもないほどかみ合っていないです。設計書などで、何でこんなことを思いついたのか、下流工程の人間にはさっぱり分かりません（逆に、かみ合っているならば、とっくにプログラムの自動生成が可能だったはず）。

　かみ合っていないので、下流工程の人間は「気を利かせる」ことができない、下流工程の人間は自発的に「何が正しいか」を思い付くことができない、という状態になります。

　もちろん、「なになにを満たすすべて」を知っていれば思いつきますが、それは企業秘密です（オープン化全盛の時代、そちらまでオープンにすれば済むじゃないかとも言えますが、さすがにそこをオープンにしてしまうと儲けのネタが無くなり、ITの会社にも発注してもらえなくなるので、さすがにそれは永久に無理だと思います）。

　ですので、少人数（しかも、上流工程以上に携わっている人間の数の方が少ない）の場合、上流工程の人がくたびれて、緊張が途切れた途端、急激に不具合が発生することがよくあります。

●権限と逆問題

　1.←→2.、2.←→3.は順問題、逆問題の関係にあるかも知れません。1.→2.より1.←2が、2.→3.より2.←3.が困難だということになります。プログラムを読み解いて仕様を作成するというのはできなくはありませんが、逆問題であり、困難なので普通はしません。特に、ITに関する費用が昔のようにじゃぼじゃぼ出なくなった今日では、したくてもできない問題です。

　もちろん時間をかければ（＝お金をかければ）プログラミング分野の逆問題は、人間わざとして解けます（レガシープログラムの保守なんてそればかりでした（笑））。ただ最近はお金がないので、原則として2.→3.の流れにするのが普通です。

　ここで、1つ、このコラムの前段落で言ったことと矛盾があるのではと思われるかも知れません。

• 下流工程の人間は「気を利かせる」ことができない、下流工程の人間は自発的に「何が正しいか」を思いつくことが出来ない

と言ったはずなのに、

• （2.←3.の様な）逆問題は、人間わざとして解ける

というのは矛盾ではないかということです。

　それに、絡むキーワードが「権限」です。現在普通に行われているプログラム（システム）作成のプロセスでは、「文書」を作って承認を得るのが普通です。それに反して、苦労して「2.←3.」を解いても、（たとえ1字1句違わぬ大正解を導き出していたとしても）それは「正しい」ことではありません。大規模（複数人で分担して作る）の場合、「権限」を顕わにして「逆問題」を廃するのが、ソフトウェア工学の進歩の流れだと筆者は解釈しています。

●そして、始めに作るテスト

　ここまで書いていて思ったのですが、仕事でプログラミングをしている人間の危惧は、

• テストファーストで「いつでも動かせるテストを作る」ことは、「権限」、「文書」にそわずプログラムを作成し、その結果、テストを作った以外の人間にそのテストを読み解かせる「逆問題」を強いる

　結果になる（のでは）という点ではないかと思えてきました（このことは今、思いついたので、『増14．“テストファースト”と言われて』には書いていません。念のため）。

　これは困ります！

　この点から言っても、

• 本当に“テストファースト”を望むのなら設計者、それもアーキテクトクラスの設計者に言うべき

というのは正しいと思います。なお、ここで「上級の設計者に言え」と言ったのは、普通の設計者はビジネスルールの維持で手一杯で、さらなる技術的な要素の追加まで背負うことは不可能だろうからという、一種テクニカルな問題に過ぎません（上流工程の人間がくたびれると、前述の通り下流の人間も困るのです）。他意はありませんでした。

　そうした上で、テストファーストも、「権限」に沿い「逆問題」を避ける方向でやっていただくならば、幸甚至極です。

　まぁ、今回はこんなところです。

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

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

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

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

とさせていただきます。

　「増13．『プログラミングのメンタルモデル』についての一考察」で、「プログラミングは慌てないとできないのではないか？」と書きました。それなりに時間を置いて見てみても、筆者はそれが正しいと思っています。

　しかしながら、言葉足らずだったことは否めないとも思うようになりました。ですので、補足をしたいと思います。自分にとっての「プログラミング時の定言命法」ともいえるものを紹介します。つまり、「慌てるとはいえ、取りあえず習慣的に行っている規則のようなもの」です。もちろん、事務計算の応用プログラマの言っていることですので、その背景や限界はお察しください。

• n個を目指せ

• あえて計算を軽んじ、制御を重んじよ

●1個でも2個でもなく

　事務計算の応用プログラムは、

• 扱う量が多い（100万件なんて少ない方、もちろん今はやりのbigdataなんかと比べれば小さい）

• 個々のレコードは均一（というより、均一でないとやっていられなかったので、無理にでも均一にしたというのが現状）

です。

　1個でも2個でも100個でも1000個でも2GBに収まる個数でもなく、n個を目指す必要があります。

　n個を目指す具体的なやり方としては、レコードの集まり（レコードセットとかデータテーブルとかいわれているようなもの）を文脈自由言語と見なし、それを受理できる（最小の）ロジックを書く方法があります（文脈自由言語はn個を扱うのに適しています）。具体的には「前処理→主処理（終わるまで繰り返す）→後処理」です。もちろん入力が1個や2個の場合、あまりにオーバースキル的なロジックになってしまいますが、そこは大は小を兼ねるです。

　さらに、n個を目指すためには、逆に記憶領域（一時、永続問わず）に持つ状態は定数個になるようにする必要があります。ここを「可変」個にすると、その物理的な限界によりパンクするからです。

●もっと制御を！

　もう1つの規則ですが、

• たとえその計算が作ろうとしているシステム全体の99.9999％を占めるものだとしても、あえて軽んじて脇に寄せ、その計算を滑らかに呼び出すためのロジック（制御ロジック）を重んじて正面に出す。

という意味です。

　これも、計算対象が1回や2回の場合、オーバースキルになりますが、たとえ本番実行が1回2回とはいえ、テストはその回数では済まないわけで、決して“オーバー”ではないと思います。さらに「脇に寄せる」ということは、関数化やインスタンス化にもつながり、形式的に軽んじているだけで、決して“脇に寄せる＝心の底から軽んじる”ではありません。

　さらに、制御を重んじることは、処理にシミュレーション的な要素がある場合、非常に重要になります。一般にレコードの集まりは事実を表します。事実のみから事実でないこと（未来の予測とか）を創り出すのは非常に困難で、どうしても「前処理→主処理（終わるまで繰り返す）→後処理」のループ処理が必要となります。シミュレーション的な要素がない場合でも、あると思ってプログラミングをすると、（虚数まで考えると見通しが良くなるように）見通しが良くなる場合が多々あります。

●この規則の使える範囲

　バッチ処理なら使えると思います。もちろんそれだけでなく、Webブラウザ上のJavaScriptの複雑な処理でも結局同様の規則で済んだこともありました。もちろんSelect文のSumやMinなどの集計一発で済む場合に「前処理→主処理（終わるまで繰り返す）→後処理」を持ち出されては鼻白まれるかも知れませんが、何度も言いますが大は小を兼ねるの考え方をすると、慌てているときの一種のワンパターンとして支えになると、筆者は強く信じます。

　まぁ、今回はこんなところです。

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

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

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

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

とさせていただきます。

　筆者は直接は言われたことはありませんが、別の所で仕事をしている人などは、「テストファースト」でプログラムを作るのが良いと言われたことがあるそうです（その人は「緑の文字」と言われただけで嫌そうな顔をしていました）。Webの記事などでも見かけます。

　もちろん、人間の価値観で軽重の無いプログラムの成果を、人間の価値観に引き込む唯一といっていい方法がテストです。テストは必要です。

　しかしながら、“仕事で分担して作業しているプログラマに直接”“「テストファースト」をしろ”と、言われると、まるで「労せず実務上の権限をごっそり奪取しよう」としているように聞こえます。多分、周りの人が手をこまねいていると本当に奪取されるかもしれません。

　なぜ、良いことのはずが、こんなにひどいことになるのか？ その辺りを描写したいと思います。

●背景説明

　学生のプロジェクトなどで、

• 自分一人でやっている

• デザイン担当はいるが、ノリでそれを改変しても問題なし、むしろ意欲があってよろしい

という環境なら「テストファースト」は非常に良いかもしれません。究極の少人数で手掛かりもないところに、それが見つかるのですから、悪いはずがありません。

　ただし、仕事でプログラミングをしている場合、

• 大枠を誰かが作る（誰が作るかは割と自由で、そこそこ書けるようになった新人の場合もあれば、ベテランの場合もあります）

• 個別の機能を誰かが作りつつ、必要な共通機能を誰かが作る

ということになると思います（複数人数で個別の機能を作ってもばらばらになるだけです）。ここで問題なのは、どこがファーストか？ ということです。上記の例では「大枠を作る」のがファーストに見えますが、ほぼ中身は作らないので、テストしようがありません。しかしながら、テストしがいのある個別の機能に着手できるころには、勝手なテストソースを混ぜ込むだけの余地は残っていなくなります。

　できるタイミングが無いのに、指示を出すことは無責任であり、無責任な人間に対して周りの人間が手をこまねいていることは、社会の成員として不誠実です。もちろん、相当の金額を投資して、対価をもって権限を得た場合でしたら別ですが、その場合の金額は家計レベルでなく、事業レベル（2桁は高い）となると思います。

●さらに説明

　さらにそもそも、プログラミングはファーストではありません。その前に、設計があります。そして、その設計内容は「ノリで改変する」ことあたわざるものです。

　もちろん設計は（アニメでいう動画と原画の原画に当たる）大まかな物で、（動画に相当するものの担当の）プログラマも質問したり、すりあわせをしたりしてコミュニケーションを取る必要がありますが、その際、設計者に対して意見をしたりする知見の元は、実際にやってみた実体験です。少なくとも１度は実体験をしないと、前々から準備してきた設計者を揺り動かすだけの知見は得られません。

　（自分の置かれた制限の中で闇雲に何かをやる）実体験がファーストだと思います。何もやらずに手を動かさずに設計者の意図とは独立してテスト内容を「ファースト」で思い付くのは人智を超えていると思います。

●本当に“テストファースト”を望むのなら

　本当に“テストファースト”を望むのなら設計者、それもアーキテクトクラスの設計者に言うべきだと思います。そここそがまさに「ファースト」です。

　VBなど「任意の箇所で任意の資源にアクセスできて当然」みたいな作りのシステム（作りやすい代わりに、確定的なテストをするためには、すべて画面から手で打ち込まないと×）を、設計段階からもう少し“不自由”にしてもらって（MVCパターンとか）切れ目を利用してテストしやすくするなど、できたら最高ですが、そのような全体の決定は高位の設計者の役割です。
プログラミングの段階で個別のプログラマに、そのような決定を強いるのは、間違いなく権限の簒奪です。

　まぁ、今回はこんなところです。

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

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

ですので、このコラムで、
　・わたしは基本的にコメントに答えない
　・コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。

　某スラッシュドットで前に「プログラマは誰もがなれるものではない？」という記事があり、「メンタルモデルを一貫して適用できる能力」が重要だとありました（本当はもっと原典がありますが、ぱっと見て分かる解説付きなので、こちらを参照しました）。

　そこでは「実際のメンタルモデルとは何なのか」は書かれていませんでしたが、そのメンタルモデル（と思われる）の1例を思いつきましたので、披露致します。なお、メンタルモデルについては、筆者は複合的に絡み合った一筋縄ではいかないものだと考えています。なぜなら、「一筋縄でいく」ような簡単なものなら「銀の弾丸はない」などと難しく考えなくてもいいからです。しかし「銀の弾丸」うんぬんは正しそうに思えます。故に一筋縄ではいかないと思います（あくまで一考察です）。

●「慌てるな！」

　自分が仕事をしていて、本番データの扱い（本番VSSのアナライズ）でうまくいかず、見かねたリーダーに「慌てるな！」と言われてしまいました。

　本番運用で「慌てるな！」と言うのはまったく正当なことです。「すみません」と謝って、落ち着いて最初からやり直したのですが、その際、ひらめきました。

• （確かに本番運用や、機器設置・インストールなんかでは「慌てるな！」が正解なのは事実ですが）プログラミングは「慌てないとできない」のではないか？

です。

　それは、（本番運用などではなく）プログラミングフェイズで筆者が「慌てるな！」と言われるたびに、妙な違和感を覚えたからです。自分としてはノリノリで普通に作業していただけです。別にアナライズのコマンドを（本番データベースに対して）何回も何回も試行錯誤で間違えていた（ようなフォールトがあった）わけではありません。

　プログラマ職からリーダー職が分離されて少なくとも10年は経っていると思いますが、リーダーのありふれたアドバイスである「慌てるな！」で、逆にプログラマが育った試しはないと思います。それどころかデモリッションマンよろしく、新人がプログラマに育つのを1つ1つ着実につぶしている感さえあります。

　彼ら新人がプログラムをできないのは「慌てて」いるからではなく、「慌てが足りない」からだとしたら、着実なプログラマ取り壊し効果も理解できます。外国人しかプログラムが作れなくなって、将来、そのレアスキルを買うお金がなくなった暁には困るように思います。（まじで思います）

●「慌てる」のおれおれ定義とその適用

　久しぶりのおれおれ定義です。

　「慌てる」とは

• 事の軽重を考えず、やみくもに（何かを）やること

とします。それほど違和感のある定義でもないと思います。

　そうすると、何でプログラミングでは「慌てないとできない」のかの実態が見えてきます。プログラミングの世界の住人たるオブジェクトたちは、「別のエスニック」と言っていいほど、人間やほ乳類や鳥類などとかけ離れていると筆者は認識していますが、その違いの1つに、

• 1つ1つのオブジェクトは人間の価値観で軽重がない

ことが挙げられます。

　キーAのみを軸とするオブジェクトも、キーAとキーBを軸とするオブジェクトも、プログラマにとっては等価です。どちらが価値が高く、どちらがより“有意義”かなどプログラマには考えようもありません（「プログラミングをきちんとする手段としてのテスト」というのに筆者が疑問を持っているのも、その理由です。価値観を持ち得ない立場の人間が、なんでテストを主導的に考えられるのか不思議でなりません）。

　もちろん、少数の指導的価値観（『データを先に決めてロジックはその後、ロジック次第でデータを直すのはあり』とか、『入出力をおさえるのは大切』とか）はあると思いますが、少数だし、少しでもプログラミングにかかわった人間には一目瞭然です。

　プログラマのプログラミング行為のフェイズで、事の軽重など分かりません。やみくもと思われるようにひたすらやっていくだけです。そこでプログラミングの手法のはやり廃りはあれ、どんな時代にもはやりがあり、はやりはなくならないのも、それだと思います。“やみくも”の中でも第一にまずやることの全体的了解があれば、間違いのない光明です。

●さらに考えるなら

　さらに考えるなら、このプログラマの窮状は人間によって仕組まれた可能性があります。それは、

• プログラマ職からリーダー職が分離された際に、人間の価値観で軽重がある部分はプログラマの範疇でないとされた

ことです。これは事実だと思います。

　プログラマは「慌てる」ことについて仕組まれている可能性があります。この難しさがあるため、プログラマは日本で衰退していっているのかもしれません。その中で他のエスニックと仲良くなり、思いを果たしていくには、「慌てる」ことを恐れないことが必要かもしれません（もちろんこれは、プログラマを志すならであって、みんなにプログラマをすすめているのではないことは、強い口調で併せて申し上げます）。

まぁ、今回はこんなところです。

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

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

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

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

とさせていただきます。

　いにしえのブルックスより現在に至るまで、ソフトウェア開発に対する報酬は人月単位で払われています。

　成果に基付く報酬など、別案もありますが、かちんとして受け付けられません。

　１つ理由みたいなものを思い付きましたので、披露致します。

●頭としっぽ

　また、アンビバレントな話です。

• ソフトウェアは簡単である。

• ソフトウェアは学んでも尽きないほど高度である。

　どちらも正しく聞こえます。そうすると、例によってまた、隠れた構造があることが予測されます。

　筆者は、それが「束構造」ではないかと思いました（図は、束 (代数学) wikipedia 日本語より）。

　つまり、ソフトウェアは“要求は簡単で、作っている最中は難しく、できたら簡単になる”と考えると、上記のつじつまが合うということです（もちろん上流工程の要求も、下流と実情は同じで“できたら簡単になる”のだと思います。上流工程の要求は常に簡単だといっているわけではありません）。

●成果に基付く報酬なんてとんでもない！

　これ以降、上記の構造が妥当だとして話を進めます。

　要するに、成果物で推し量られると、やっていけないほど損になるのです。どうしても成果物で量ることをされると、多分作る側は半製品を完成品だとして納品することになると思います。

　人間の根源的・部族的感情からしても、できた簡単な成果物より、途中までの難しい成果物の方に価値があり、学術的にも優れているように見えると思います。筆者も職業的立場から離れてみるなら、そうだと思わざるを得ません。

　しかーしっ！！！それはどう考えても「技術的負債」以外の何者でもありません。

●（突然ですが）資格審査報告

　この次の段で、ある侮蔑的な言葉を言いますが、筆者は言っても問題ないだろうことを示すエピソードを述べます。

　筆者は前に、汎用機のデータをRDBに変換するプログラムを作ったことがあります。その際の条件として、

• VSAMのマスタは読むだけ

• 特定のVOL=SERで中間ファイルは作り放題

• もう、その汎用機はあまり使っていないので、SUBMITもし放題

で、結局、2本マッチング、3本マッチングをぐちゃぐちゃに織り交ぜて、何とかRDBの世代データにすることができました。

　その際、つい同僚にその言葉を言ったのですが、同じフロアに居た別の会社の人が、ものすごい形相でにらんできました。しかしながら次の日、（多分筆者の作ったソースを見たのだと思いますが）「まぁ、おまえなら言ってもいいや」とかぼそっと言ってくれました。

　もちろん、これで万事とは言いませんが他社さんの（ある意味）ピアレビューとして、取りあえずこの場で、その侮蔑的な言葉を言うだけの根拠にはなると思います（その人は名前も存じ上げませんし、その後もお会いしたことはありませんが、この場で感謝したいと思います。）

●コボラーとはなんだったのか

　あーあ、言っちゃった（笑）

　しかしながら、このコボラーという侮蔑も、「束構造」で考えると見通しが良くなります。そしてもちろんかなりの部分が不当なものだと反論できるようになります。

●コボラーに対する典型的な非難

　思いつく限りでも、

1. コピペである。ソースを表か何かのように画一的に作る
2. 変数を階層的に長く作る
3. 部品化しない

　とかありますが、すべてネタは同じです。それはコボラー側には「難しい作っている最中」の状態を割り当て、非難する側は「簡単なできた」状態を割り当てているということです。上図を見ていただくと分かりますが、プログラミングが（当コラムの仮定により正しいとした）「束構造」であるならば、1．も2．も最適中の最適ですし、部品化とは出来てからが部品化で、作っている最中に部品化言われても「なんのこっちゃ」です。

●もう1つ、別の話ですが

　不案内な分野なので、ご案内にとどめますが、ソフトウェアの「見積もり」というのも、「簡単な要求」から「難しいものを作っている最中」を推し量るものだと整理できるのではと思います。もしそうなら（筆者はそうだと思っていますが）確かに大変な仕事だと思います。

まぁ、今回はこんなところです。

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

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

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

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

とさせていただきます。

　保守や旧システムを見本にした類似機能を作るときには、どうしても現ソースの技術的負債について考えざるを得ません。

　もちろん、あまりに負荷が高すぎて、否応なく負債を残すことはあると思いますが、どう見てもそれだけではありません。

　その平時の負債発生のメカニズムについて、考えたいと思います。

●技術的負債とは

　Wikipediaの「技術的負債」の項目には、例として、「組織で共有されない知識や、複雑すぎて変更が難しいコードなど」とあります。ここでは、プログラムの保守作業などの時点で、後の人が困ること一般を考えます。

●どこで起きるのか

　テーブルなどではあまり起きないと思います。それは、

• 縦横か、せいぜいキューブ程度の構造なので、そもそも起きにくい。

• テーブルで技術的負債的なことが起きたら、関係者全員に耐え難い問題を引き起こす。だから負債を負債のままにしておけない。

• 必ず使うアクセスメソッド的なプログラムで補償が可能。

だからだと思います。

　どこで起きるのかというと、間違いなく第一義的にプログラムでだと思います。マジックナンバーとはよくいわれますが、ここでの問題は「マジックロジック」といっていいと思います。

●何が起きるのか

　 保守や旧システムを見本にした類似機能を作っていて思うのは、プログラムにおける技術的負債は、プログラムの難読化と通じるものがあるのでは、ということです。

　MS　MSDNのVisual　Studio　2008の資料で、バンドルされている難読化ツールについての文書には、

• 名前の変更（名前を、通常、1 文字に短縮）

• 文字列の暗号化（特定の文字列を検索して戦略的なロジックを探し出すことの回避）

• 制御フローの難読化（スパゲッティのように複雑にからみ合うロジック）

• 拡張オーバーロード誘導（メソッド名およびフィールド名の重複性を高める）

とあります。1つめの「名前の変更」は最近ではさすがに悪い例として回避されていることはあるとしても、間違いなく、筆者が「技術的負債」で「マジックロジック」だと感じている点と合致します（注：もちろんこれは「技術的負債」の一例であり、これ以外にもいろいろあると思います）。

●なぜ起きるのか

　 これについては筆者は目算があります。

• 「文字列の暗号化」はマジックナンバーを回避しようとして、定数一覧をただ1カ所に決めて定義したのはいいけれど、大量の定数ができてしまい、その定数の変数名の命名方法が実情に追いつけなくなる。大量なのでリネームも無理な場合、それはかえってマジックナンバーに近くなってしまう

• 制御フローの難読化と拡張オーバーロード誘導を行うと、ソースを修正・追記する際に、Diffツールで判別しやすいように修正することを奨励され、その結果、プログラムがバランスの悪い入れ子になってしまう

ためです。

　この内、2つめの「文字列の暗号化」は、個々のプログラマではどうすることもできない問題ですが（“ただ1か所”という規約を無視して、サブ機能ローカルの定数一覧を作ってしまうことも、実際行われては居ますが、もし品質管理の監査が入った場合、ただでは済まなくなると思います）、制御フローの難読化と拡張オーバーロード誘導はプログラマで何とかしうる、実際に作譜しているプログラマにしかなんとかできない問題だと思います。

●なぜ起きるのを止められないのか

　これは、実際に作譜しているプログラマが、プログラムは難しいと思い込んでいるからだと思います。難しいと思い込んでいたら、実際の譜面もそれに引きずられて難しくなるのは道理です。

　プログラムなんて簡単もいいところなのですよ。筆者は、就職する前から一応（Tiny Pascalでありましたが）プログラムはできていましたので、逆に1週間もしない内に、「どう考えてもプログラム以外の要素（なにが正しいのかとか全体のアーキテクチャとか何とか）があって、プログラムなんて全体から見ると微々たるものだ」と気付いたりもしました。社会に出てからプログラムを学ぶとそれに気付くチャンスが失われるのかも知れません（気付いたときには、もう職業上致命的な言説を吐いていて、来世に期待するしかなくなっているような……）。

●起きるのを止める手立てはないのか

　これは、「他人の目」だと思います。自分はプログラマで、他人から仕様をもらいテスト担当者に引き渡す役割ですが、技術的負債が有るプログラムを渡すと、テスト担当者の態度が一変します。ぎちぎちの遵法闘争を始めるのです（これはプログラマの感想であり、特定の組織の効果・効能を表すものではありません）。

　（特にブラックボックスをテストの基本としている所はそうですが）テスト担当者は、プログラムの内部について意見できません。できないのは確かですが、彼らも内々ではソースについてもしっかり理解しているはずです。

　意見できないため、その代わりにねちねち言ってきて、プログラマに反省を促しているのだと思いますが、実際に作譜したプログラマとテスト担当者は直接接することはないのが普通なので、そんな反省が生まれるはずもありません。

　しかしながら、ここは1つ、テスト担当者を「他人の目」として認知した上、彼らの態度に注意し、自主的に技術的負債を除いていく必要があります。

●自分一人で、起きるのを止める手立てはないのか

　よっぽど簡単なプログラムならともかく、難しく煮詰まってくると、プログラマには個人個人に「信念」が芽生えてきます。そしてそれはその当時の自分にはまったく分かりません（空気のように、魚の水のように）。

　SFで脳梁を切断して、脳の効率をアップさせるなんて話もありますが、その位でもしない限り、自分1人では止められないと思います。

　まぁ、今回はこんな所です。

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

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

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

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

　仕事中に、某ブックマークを見ていたら、AI分野で、チューリング賞を取ったすごい人（後世の人に肩を貸す“GIANT”に擬せられている程）の書いた、「統計的因果推論：モデル・推論・推測」Judea Pearl著 共立出版について、記事がありました。読んでみると、なかなかなので紹介します。

●良かった点

　筆者は、

• 「お客さんの話は確率関係に近く、それを因果関係に変換することにより、電算機システムとして実装可能になる」という方向で応用できるのでは？

と思いました。

●「わたしも、伝えたいことがある」

　大規模開発の際によく、

• 本当はきちんとやらないといけないのかもしれないけれど、大規模開発だからきちんと追ってはいけない。

と言われたり、

• 統計的に不具合の有無を推定。

されたりします。

　しかし、ソフトウェアは人間が主幹となって作るものであるため、

• 因果構造が（統計的に何とかできる範囲を超えた）不均一となる。そればかりか、もし何らかの均一さができてしまった場合、少々不利でもわざと不均一を選好することすらある。

• （結局の所、根が単純な）人間が満足しさえすればOKなので、因果グラフの深さはそれほど深くならない。

とか直感的に考えました。

　事実として、統計的にソフトウェアを管理しても、当てずっぽ以下の成果しか得られないこともあるのは、上記2点が原因ではないか！！！

　とか、かの本にインスパイアされて思ったりもしました。

　短いですが、今回はこんなところです。

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

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

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

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

とさせていただきます。

　以前、TDDについていろいろ言いましたが、なぜこのような概念が生まれたのか考えるようになりました。すこし、文書になるぐらいになったので、公開します。

●インターフェイスの問題点

　インターフェイスは、かなり自由度があります。

• メソッドがいくつかある。呼び方についての制限の記述方法は（どんな言語でも）ない。
• メソッドのパラメータは大抵、普通の数字や文字列である。範囲指定された型はあい。（VB、.NETなどはString型が「NotInheritable」で、部分範囲型のようなものが作れない）

　そのためか、まとわりついて離れない“不吉なにおい”があります。いかにも失敗しそうな自由度です。

●インターフェイスのさらなる問題点

　メソッドのパラメータとしてのコード設計方法には、大きく2つのやり方があると思います。

• オブジェクトローカルのコード（内部の処理の都合のみで決めた）を用いる。オブジェクトの利用者が、呼ぶ度いちいちグローバルコード⇔ローカルコードの変換をする
• グローバルのコードを用いる

　前者の場合、オブジェクトの設計の側からすると、

• コード1～コードm。以上。

ですが、後者の場合、

• コード1～コードn　＋　名状しがたいそれ以外。

となります。オブジェクトの設計者からすると、グローバルコードがなにとなにを取るかは、まったくわからず、ましてや将来にいたって分かるはずもありません。 さらに、その「名状しがたいそれ以外」は、

• オブジェクトの現状のロジックで対応可能。
• オブジェクトの現状のロジックで対応不能。

の２つに分かれます。

パラメタのコードの設計については、RDBの作法に端を発し、グローバルなコードを圧倒的に選ぶであろう今日、たまさか「現状のロジックで対応可能」な部分があるため、伝統的な「assert（実行中にテストし、不合格の場合無条件に異常終了する）」は適用しがたく、その代わりに「これこれはテストしましたが、名状しがたい部分はテストしてませんよ！」ということを、プログラム内に記述するTDDを思いついたのだと思いました。

●利用者の問題／保守担当者の問題／初心者の問題

　そうはいっても、今まで実績のある入力のみでオブジェクトを使おうとしない、わがままな利用者が、TDDによるテストの記述を尊重してくれるとは到底思えません。

　また、グローバルコードのコードの拡張について、通知を得られない立場の人間が、オブジェクトを保守しようとするのもあまりに無理があると思います。グローバルなコードの保守責任は、オブジェクトの利用者側とすべきです。

　さらに、TDDに沿ってテストを書くと、仕様を意識することになり、初心者にとって有意義だという点も、それを「腹の底から理解しないと記述できない、別の言語である、自然言語」でなく、「同じ言語なので、うわべだけ理解していれば記述可能な、プログラム言語」で書くという事が、本当に教育的なのか心の底から疑問です。

●別案

　どこでもグローバルなコードを使う事はあきらめ、

• 共通で使うオブジェクトでは、オブジェクトローカルのコードを使う。
• それを使う側は、自システムのどこかに（基底クラスやFriendクラス）「インターフェイスの使用」メソッド群を作る。そこで、グローバル⇔オブジェクトローカルコードの変換をする。
• オブジェクトを直に使う事は禁止、「インターフェイスの使用」を使う事で間接的に利用する。

というのはどうでしょうか？　「インターフェイス」だけを概念上の実体とするのでなく、「インターフェイスの使用」も実体とするのです。実体の数が増えるのですから、当然制御できる範囲も増え、“不吉なにおい”を押さえ込む助けになると思います。

　まぁ、今回はこんなところです。

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

ですので、このコラムで、
　・わたしは基本的にコメントに答えない
　・コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。

　今回の話は、前回の「増8．プログラマの困難について」を前提としています。ですので、その前提が崩れてしまえば、この話も崩れる理屈です。そういう前提で読んでみてください。

●加速度その1

　以前から述べていますが、自然現象や、交通などの現象に比べてみると、人間が行う動作の加速度は、比べものにならないほど高いです。時間は短く、力も少ないですが、その代わり、他では類を見ない加速度を日常で生み出します。

　特に異性に対して気を引こうとする際の動作は、特別に強い加速度を持っています。手をひらひらさせたりして、それを見るのがいやで目をそむけると執拗に追ってきたりするなど、私にとっては非常に苦痛です。

　前回、「きちんと見る人間＝リア充」だと書きましたが、このような理屈がありました。「リア充」という言葉の誤用・拡大解釈というつもりではなく、両者に通底したなにかがあるのでは、という意図です。このような強度の加速度にさらされていながら普通に対応できるのは、異性を「きちんと見」ているからではないでしょうか。

　とはいっても、筆者のように、加速度に悪慣れしてしまった人間には、プログラミングの初学者がどう対処すればいいか、とうてい分かりません。それについては各自、良い方法を見つけていただくしか無いと思います。

　さらに、ただ1人黙々とプログラミングをする場合は別ですが、仕事の場合、「加速度禁止」とするのは現実的ではありません。それゆえ、プログラミングに特化したプログラマの他に、プログラミング的な要素を抑える代わり、他人と長くコミュニケーションを取り続ける、リーダー的存在が必要なのも必然だと思います。

　ただ、どうも最近のリーダーは、うすうすプログラマが加速度に弱いことを知り、彼らを服従させるために加速度を利用しているとしか思えない節があります。配下の人間の思考を鈍らせれば、御しやすくなるからです。

　自分の非力さ、生産性の限度を考えると、それはいけないことだと言い切れない面もあります。最終的な結果責任を負ったリーダーが最終的結論に異を唱えさせないために、そのようなプログラマの生態を利用するのも（個人としての自分は非常に腹が立ちますが）プロジェクト遂行を考えると、ありとせざるを得ないと思います。

　問題はその後です。リーダーは、何年かするともう少し上の地位に就くはずです。それは、「自分で結果責任を負う」のでなく、リーダーを配下に置き「部下に結果責任を任せる」立場になると思います。その時、今までのように、加速度などを使って、配下がいやがることをして服従させようとすると、まずいことになります。それは、自分の責任が自分1人で頑張ればできる範囲を超えているからです。

　ペンを回したり、ノック式ペンをかちゃかちゃさせたりするのは、なにからなにまで仕事を引き取って「最終的に自分がすべてできる」場合のみ許されることで、そうならなくなった時点でそれはまずい話になります。

　また、そういう人間に限って「（机に）壁を作るな」とか余計なことを言いますが、人間が日常的に強い加速度を生み出すのは仕方がないことで、それを少し遮るだけで生産性が上がるのなら、それをとがめるべきではありません。

●加速度その2

　「きちんと見」ない場合の、加速度というのは、目から見えるものとは限りません。特にプログラミング初学者の場合、別の加速度により強いストレスを感じるはずです。

　それは、「思考の速度の変化が生み出す加速度」です。まさにSFだと思われるかもしれませんが、筆者は自信をもって「あり」だと思います。

　実際の経験ですが、

• なにかプログラムについて学んでいる時、

• さらに何かすごいことを考えようとし、

• さらに何かすごいことを考えようとした時

脳みそがバチッといって（実際は肩の筋がいったのだと思いますが、実感としては「脳みそ」でした）すごく疲れ、すぐ横になっても残ったままでした。

　その時は自室で1人でしたし、カーテンを引いた薄暗い部屋で、外は夕暮れでカラスが寝どこへ帰る様な、のどかなようでした。加速度など見えませんでした。そう感じたのです。

　プログラミングは即興性を要求されるものではなく、積み重ねができます。また、（構造化など）積み重ねがしやすいよう、研究がなされています。さらに、知識を増やしていけば、思考の速度一定でより多くの事柄について考察できるようになります。焦らずに着実に学ぶべきです。

●最近の「手法」

　「上流」「下流」とか言われ、「下流」の人間が下に置かれているのは歴史的事実だと思います。しかし「下流」の人間から見て、（実際はともかく）たてまえ・理念・使命感としては、「上流」の人間が大多数の加速度分（開発における困難）を背負おうとしていたのも事実だと思います。

　ひるがえって、アジャイルやTDDなどの最近の手法ははじめから、単価の安い人間に大多数の加速度分に関する責任を転嫁する気まんまんに見えます。手法の改良も結構ですが、「机に鉛筆を立て、その上に鉛筆を立てている」状態で、「さらに鉛筆を立てようと」している様に見えます。前回の改良（行程を分ける）は（個人的にはともかく、業界全体としては）ありとしても、今回の改良はすでに、限界をまたいでいる様に見えます。

　まぁ、今回はこんなところです。

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

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

　ですので、このコラムで、
　・わたしは基本的にコメントに答えない
　・コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。