同じように産んで、同じように育てたきょうだいなのに、違うねえ」という感想を良く聞くように、やはり生まれ持った性格というのはあるようだ。もっとはっきり言えば生まれ持った天分というのは仕方がないくらいある。社会問題ネタ、目次へ
こう言ってしまうと「天は人の上に人を造らず人の下に人を造らず」という平等主義の教条に反してしまうが、あるものをあると認めないと先に進めない。実際こどもを育てていると分かる。上の子は容姿、音感、色彩感、料理については親が仰天するほどの天分があるが（そういえば字も上手い）、できないことが一つある。ただし下の子はできるのだ。生まれたときから居間にパソコンがあったせいか、下の子は１才の時からマウス操作になじんでいる。最初はただのいたずらだったが、ようやくPoint＆Clickがこなせるようになって、超簡単な絵合わせゲームができるようになったころ、奇妙な動きをした。投機的実行である。
このゲーム、次々と図形が表示され、それと同じ図形を下の一覧から選んでクリックする、という単純なものなのだが、この子は次の問題が表示されるまでの間に「とりあえず、残った図形のうち、適当なモノにマウスのポインタを合わせ」て待っていた。２才になるかならないかの子どもにとってマウスのポイントを合わせるのは至難の業である。それにも拘わらず、無駄かもしれないが、トータルで所要時間を短縮する手法を行っていたのだ。これに対して、上の子は「とにかく順列組み合わせで計算をし、その中から正解を求める」パターンの問題が出ると、引き算一つしようとしない。トータルでは必要なことだけど、個別には無駄かもしれない計算をしようとしないのだ。
上の子は、無駄かもしれない計算を極端にいやがるねえ、とニョーボにこぼすと、ニョーボは「好きな人いないよ」。それはそうだけど、フェルマーの大定理の反例を出そうとどれだけの人がどれくらいの時間を無駄にした？と言うと無駄を厭わない人間の存在を納得してくれた。彼らは無駄かもしんないと思いつつ、できたら凄いと計算をし続けたのだ。 そういう気持ちはたまにチャレンジ精神と呼ばれる。（ちなみにフェルマーの大定理 a**n + b**n = c**nとなるa,b,c,nの素数の組み合わせがないということが、公開鍵暗号が解読できない根拠となっている・・・もちろんギャクです。）
高校時代、数学の苦手な子がその理由として「私、ひらめかないから」と言っているのを良く耳にした。ついムカッとなった記憶がある。「私はひらめくと思われているかもしれないけど、私がひらめくまでに考えたことは、あなたが自分はひらめかないと判断したまでに考えたことに比べて、ものすごく多いの」。
研究職なんぞ、無駄な努力の連続なのだろうなあ。抗生物質を探すときは、細菌を集めまくってしらみつぶしに調べるのだろうし、常温超伝導が話題になったときは、これはという材料をいろいろな比率で混ぜ合わせることを繰り返す。ほとんどは「それだけ見れば無駄な努力」に終わるだろう。しかしだからといって全くやらなければ（超伝導はどうか知らないが）感染症で多くの人が死んでいた。無駄な努力は必要だ。少なくとも無駄な努力を容認することは必要だ。言い換えれば失敗することを容認することも必要だ。
ただし、多くの場合失敗は容認されないものとされる。研究室で「プロトタイプを100個作って99個は失敗でした、でも1個良いのができたから無駄ではありません」といえば通じるかもしれないが、工場で「製品を100個作って99個は失敗でした、でも1個できたから無駄ではありません」などと主張する奴がいたら筋金入りのアホである。
生産する相手が「物体」の場合はこの辺区別しやすいが、形がないものとなると判断が分かれる。プロトタイプと製品の区別が判然としないからだ。
こうくると「プロトタイプがそのまま製品になってしまうソフトウェア（特に社内開発）」に焦点が移るのが普通だが・・・実は私もそうしたいのだが、話が複雑になるので、もう少し製作にコストがかからないものを例にする。例えば「情報漏洩防止策」といった「ルール」の作成だ。以前、ちょっと頭をひねったのが、社内にカメラを持ち込んでの撮影、である。写真により情報が漏洩することを防ぐためにルールを作ろうとしたのである。こう言われて誰もがまず考えつくのは「カメラ持ち込み禁止」である。これを「ルール」のプロトタイプ１とする。
すぐに気がつくとおり、このルールは実現不可能である。というのはどっかの誰かの発案のおかげで、事実上全ての携帯電話にカメラが標準搭載されているからだ。従ってルールを徹底するためには携帯電話を持ち込み禁止にしなければならない。確かにできなくはないが、その場合 (1)何か問題が生じたとき、誰かに対して携帯電話で連絡をとることをあきらめる、(2)社内の入り口に携帯電話を預かっておくクロークないしロッカーを用意する、という覚悟が必要になる。そうでなければそもそも守れないルールを作ったことになる。守れないものを作ってもルール作成者の自己満足ないし責任転嫁でしかない。
果たしてできるか？10年前までは携帯電話がないのが当たり前だったが、現在では実務に影響が出るのは明らかである。ロッカーを作るというのも場所的に無理である。というのは、ロッカーの設置は執務エリアの入り口に限定されるからだ。かくして簡単な脳内シミュレーションの結果、単純な「持ち込み禁止」は失敗作に終わることが判明した。次善の策として「撮影禁止」を考える。これが「ルール」のプロトタイプ２。
持ち込み禁止にしたところで、ボディチェックや金属探知器の設置を（マシンルームを除いて）行うわけ無いのだから実効上は変わらないはず、という言い訳がその辺に浮いている。ところが、撮影を行わなければならないときもある。操作マニュアルを作るときに「マウスを操作している手」とか「スイッチの位置」などを載せたいときもあるだろう。絵を描けばいいかもしれないが、写真を撮った方が圧倒的に生産性が高い。
さらに言うと、例えばビルの工事でビル管理部門が「作業前／作業後」の写真を撮るときもある。従って一律に「撮影禁止」とするわけにはいけない。かといって「やむを得ない事情の場合は例外とする」なんて規程を作るとザル法になるのは天下り先への入札なし発注を見なくても分かること。
あるいは、社内報の取材が来て「写真を撮りたい」ということもありうる。
かくして「撮影禁止」というルールも失敗作となった。
そして個人的には、退職者を囲んでの記念写真くらいは「堅いこと言わなくてもいいんじゃない」という気分。というわけでとりあえず作ったプロトタイプ３はこんな感じになった。
《当部管理エリアにおける写真撮影は以下の場合に限定する。
・退職、転勤等のセレモニー
・当社公認出版物（Webページを含む）へ掲載する場合
・その他業務上の必要があると情報管理責任者が認めた場合
（例、端末操作マニュアル作成時の資料収集）
但し、それらの場合でも、撮影画像に内部情報を含むことは禁止とする。》ビルメンテでいじるパイプスペースなどは管理エリアではない、ということにする。（PHSのアンテナがある事業所はこうはいくまいが。）情報管理責任者というのを介在させて判断を仰ぐ、としたのは撮影の場合に司法の介在を必須にしたということであって、単なる逃げとは受け取られまい。というわけで「守るに不都合はないルール」がやっとできた。情報漏洩対策に責任を持っている企画屋としてはまーまーのものができたと思っている。これなら「守れ」と要求できる。少なくとも実行に移したとき「守れないルールだから」ということで失敗することはない。なにしろ自分の頭の中でシミュレートして２回プロトタイプを作って失敗しているからね。完成品はそれなりの品質。
もちろん、この案、日の目を見ませんでした。２年前だったし。ちなみにこのルール、今再提出するとしたら「社内携帯電話利用ルール」を一緒に出さないといけないでしょう。「当部管理エリアにおいて携帯電話を取り出している場合は、レンズ面を常に壁・床・窓に向けること」というのを付け加えないと（少なくとも私は）情報漏洩対策担当の企画屋として責任あることをしているとは思えない。
いやあ、こんな場合を考えたんだわ。コピー機のメンテに来ている人が（おそらく）自社と連絡をとろうとして携帯電話を取り出して（多分）電話番号を押している。まてよ。たまたまコピー機の上に書類が放置されていたとしたら、書類を撮影していても、電話しているのと区別が付かないぞ。
「社内携帯電話利用ルール」にこの一行を付け加えると、こういう疑いをしなくてよい。少なくともフツーに携帯電話を使っているメンテの技術者に注意を呼びかけやすい。呼びかける根拠となる。「いやあ、うちのパラノイアがこういうルールを作っちゃいましてねえ。」
というわけで撮影ルール、３度目の失敗。おかげで４度目の案を採用することがあるとして、少なくとも「ルール」の段階で破綻を呼び込むことはない。これまで述べた企画屋の作ったルール案がプロトタイプ。実施された案が完成品の例である。無駄な努力はたくさんやった。この例ではあまり気にならないがやることの大部分は失敗に終わるものだ。ただし、失敗する覚悟はあるから失敗を恐れない。失敗作を作ったときにかけたエネルギーをしゃーないかとちゃんと割り切れることはある。
もしこれができないと結局は失敗作のルールを実施する側に無理強いすることになるんだな。しかも失敗と自分で分かっているルールを、である。失敗が自分の脳内にとどまっているならいいじゃないかと開き直ろう。まあ失敗しすぎて少々期限をぶっちぎることはあるが、これは勘弁してください。ルールならまだ「機能しない」で済むかもしれないが、これが「戦略」的色彩を帯びた「計画」だと大変なことになる。到底実現不能な目標に資源を浪費することになる。（新興IT企業だと現在の成長率を元にして売上目標を立てると、簡単に市場規模をオーバーしそうだ。そんな目標値を立てても有害である。）
だから企画屋は頭の中で作った案が失敗しても影響が自分内部にとどまるならば、シミュレーションの段階で失敗できて良かったと思い直し、より現実的な案を考えなくてはなりません。意地になって（責任逃れのために）ごり押ししてはいけません。
自分の失敗を自分で許してやりましょう。毛沢東だって失敗したのです。スズメが米を食べる。→その分収穫が減る。→スズメを駆除しよう。ところがスズメがいなくなって害虫が繁殖した結果、農村は壊滅状態に。
そういやこんな例も聞いたことがあるなあ、イギリスの王様ですか？馬車不足に悩み「馬車待合所には必ず２台駐留していること」とかいうおふれを出した。結局３台目が来るまで発車できず馬車不足はさらに深刻化。そのうちに他人についてもどういう失敗をするか分かるようになります。どの程度の失敗が出てくるか予測して、どこまでなら許せるかを計算できるようになります。そうすると実際に動いてくれる人は楽になります。マンガに出てくるような「失敗には死を」という鉄の規律の組織が実際にあったらと考えてください。最初の失敗で殺されてしまうなら、決してスキルはたまりません。つまり組織の構成員は未経験者ばかりとなり、とても弱くなってしまいます。
このように失敗を認めて、良いものを作る時の訓練として、数学の問題であーでもない、こーでもない（あーやったけど失敗、こーやったけど失敗）と悩んだ経験はきっと生きると思います。役に立たない結論：企画屋は数学の得意な奴の方が向いている。
バックグラウンドで進行していたソフトウェア開発への示唆：ウォーターフォール型開発モデルの欠点は、上流工程での失敗を構造的に許せない（認めるフレームがない）ことに起因する。従って上流工程で作り込まれた（無いことになっている）問題点は下流工程に解決責任が（非公式に）押しつけられる。下流工程を担当した技術者は言うだろう「上流が悪いんだから、結局解決できないよ」。その通りだ。その技術者がとりうる方法は２つ。無視するか（仕様通りに作る）、さらに先送りする。品質が悪くなるのは当たり前である。（プロジェクト管理の教科書にある「変更管理」の入る余地がない。）
さらなる悪影響もある。問題点は上流工程つまり自分以外にあるという「法則」を発見した技術者は、改善能力（少なくとも改善意欲）を失う。つまりスキルがたまらないのである。多分上流工程を担当するようになっても、その癖はなかなかとれないだろう。示唆を元にした改善策：上流工程で作り込まれた問題点を下流工程がきちんと指摘するスキームを作る。そうすれば下流工程担当技術者の意欲は下がらない。また公式に改善策がとれる可能性がある。
改善策への反対意見：「企業人としては、上流工程（元請？）の間違いを公式に指摘できない。」
改善策への評価：ボツ。・・・問題が起きたときの報告用に匿名のメールアドレスを用意するというデマルコのアイディアは秀逸だよなあ。
役に立つ結論：算数はちゃんと教えようね。無駄や失敗と折り合いを付けることを学ばせよう。できれば、無駄や失敗から学ぶことも教えよう。最初は順列組み合わせを端からやってゆく鶴亀算もだんだん勘ができて、ほとんど無駄なく解けるようになるものなんだから。（だから最初から連立方程式を教えてはいけないのだ。）