2．「きちんと見ることを尊ぶ」人はなぜ不利か

スキル

» 2010/10/05

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

　前回は、自転車（など2輪車）に乗るドライバーの「見方」である「きちんと見」ない見方が、プログラミングにとって有利である、というドグマを導き出したまでを話しました。

　今回は、反対に「きちんと見ることを尊ぶ」人はなせ不利か、という点について持論をお話しします。

●「きちんと見る」人間は、組織の要石

　まず、お断りしておきますが、「きちんと見る」人間が悪いといっているわけではありません。

　「きちんと見る」人は、組織の中では「個人の状態把握」などにおいて、要石として活躍しているはずです。

　悪くないのですが、その良さゆえに行動様式をほかの仕事にも敷衍（ふえん）する、あるいは敷衍されると、問題が起きます。さらに、新人教育係が「きちんと見る」人ばかりとなっている点も、問題を助長します。

●「きちん」とは何か

　無条件に特定の言葉をあげつらって批判しても、論理的ではありません。かといって、なかなか既存の言葉で表現できません。

　ですので、言葉については、ある程度「おれおれ定義」をしたいと思います。

　まず「きちん」ですが、「きちん＝連続性」ではないかと考えます。ただし、数学的な「なめらかさ」でなく、

　　「初めに対する規則を、次も同じように適用できる」こと

を（おれおれ）定義としたいと思います。何かを「きちん」とすることは、原則として褒められる傾向にあります。

●「見る」とは何か

　次に「見る」について。情報処理の仕事における定義ですが、

　目で、VDT画面を見る。人間を見る。

ということになります。

　さて、「見る」の特徴を挙げてみましょう。

1．対象の数が決まっている

　フロー図（ノードとアークから成る図）において、四方からのアークはともかく、八方にアークを出すと、間違いなく限界となります。アークが16ぐらいになると、確実にレビューで却下されるでしょう。

　人間関係でも同じです。例えば、会合などで「見る」対象となるのは、（面識がある程度ある知り合いを除けば）せいぜい10人程度を超えることはないはずです。

2．リアルタイムである

　1．の「対象の数が決まっている」点と結びついているかもしれませんが、きちんとした手順を踏んで「見る」のは困難です。見ることは一瞬、一期一会です。

●プログラミング分野で「きちんと見る」ことの弊害

　プログラミングは、

1. リアルタイムでなく、あらかじめ手順を用意しておく（プログラムの本質中の本質）
2. 非常にたくさんの対象（データなどは万～億以上ということもあり得る、オブジェクトでも数千になり得る）を扱う

という特徴があり、プログラミングの特徴に適した規則は、「見る」規則と相反します。「きちんと見る」すなわち「いつも変わらず『見る』という同じ規則を適用する」ことが、プログラミングに適した規則を阻害します。

　結果（プログラム）が「一目見て分かる」ように直感的でない以上、もっぱら人間の頭の中で、直感的である要求文書などの入力を、直感的でないプログラムに変換しているわけです。それゆえ、プログラミングをする人間は、「見る」を常にやっていても何も生まれないのです。

　電算処理周縁の領域で似たような「変換」といえば、「フーリエ変換」や「ソートマージ＆集計」があります。プログラミングにおける「変換」とは、何か「見えないけれどある」測度に対して変換を行っている可能性があります（もしそれが、「見える」測度であったなら、プログラム自動生成など60年代に完成していたことでしょう）。

●「見て分かる」資料の弊害

　もちろん、トピック単位なら、「見て分かる」定評のある書式はいくらでもあります（例：UML、ER図、特性要因図）。

　ただし、「きちんと見ることを尊ぶ」人は、総じて「トピック単位」を許さない傾向にあります。なぜならば、トピック単位の資料だと、あるトピック以外の情報について、「見た」だけでは分からないからです。

　また、「トピック単位」の資料では、漏れや抜けを見つけるのに不利で、それもまた、「トピック単位」を許さない理由の1つだと思います。

　それはまったく当たり前のことですが、しかし「トピック単位」を超えた「見て分かる」図は、絶対に不可能だと自分は考えます。それは、「見る」規則（1）から導き出せます。

　バブルのころ、それこそ金を惜しまず、人を惜しまず、課題を惜しまず、常道奇道、ある価値を持ち上げる、ある価値を貶めるなど、あらゆるチャレンジがなされました。しかし現在に至るも「トピック単位」を超えた「見て分かる」図は世に出ていません。厳密に0件です。これは、何か本質的な問題があるように思います。

●「トピック単位」とは何か

　「トピック単位」（あるいは「トピック」）のおれおれ定義をしておきます。それは、

　「ある規則を重くとらえ、ほかの規則を軽くとらえる、あるいは無視する」こと

です。たとえば伝統的にある項目一覧を排除して、代わりにURLのクラス図に統一するといったことは、クラス図からすると心外だと思います。

●結局

　「見て分かる」陽関数的（？）な資料はあきらめ、いろいろな管理対象に「トピック単位」に分類したラベルなどの名前をつけて、間接的ないくつもの一覧をいちいち見比べないといけない、陰関数的（？）な資料とせざるを得ないのが、人間の限界だと思います。プログラミングで必要とする数に対応するには、それしかないと思います。

　もちろん、決められたエントリポイントから再帰的、推移的、反射的に深く深く沈思黙考し、すべてを無名の参照で表すことは可能ですし、電子計算機的にはむしろそちらの方が自然かもしれませんが、どう考えてもそれは、人智の及ばない領域だと思います。

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

　次回は、「なぜきちんと見ないでよいのか」、について考察したいと思います。

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

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

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

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

とさせていただきます。