世界的に有名な日本人の数学者２人の間でやりとりされた、「技術」に関する興味深い逸話をお話しましょう。

　広中平祐さん（数学者、フィールズ賞受賞）が、若い頃、岡潔さん（数学者）の講義を聴講なさったそうです。岡さんは、当時、整数論の領域で、世界的な評価を得られていらっしゃいました。岡さんは、講義のなかで、（「無明」ということに言及なさって）「数学の問題などは、（坐禅して）心を平静にすれば、解が見えてくる」とおっしゃたそうです。数学の「技術」を学びたかった広中さんは、その講義を聴いて、岡さんから「技術」を学ぶことができない、と思ったそうです。

　広中さんが、（フィールズ賞受賞の対象になった）「複素多様体の特異点解消」に関して、数学学会で、中間報告なさったら、最前列に座って聞いていらした岡さんが、以下のようにおっしゃたそうです。
　「そういうふうに、制限を次第に多く設定していくやりかたでは駄目です。
　　もっと一般化した形にしたほうがいい。」と。

　岡さんの助言を聞いた広中さんは、（心の内では、「なにを言ってやがる」と思ったそうですが--笑）「ありがとうございます」と返礼なさったそうです。そして、広中さんが、そののち、「特異点解消」の論文を完成なさったとき、岡さんのおっしゃたように、一般化した形としてソリューションが出た、とのことです。
　そして、広中さんは、50歳代になってから、岡さんのおっしゃっていた「（無明から脱して）心を平静にすれば、ソリューションは見えてくる」ということが、「（当時は理解できなかったが、） 今なら、わかるような気がする」とおっしゃったそうです。

　学びの途上にいる人 （あるいは、なにかを具体的に完成しようとしている人） が体得しなければならないのは「技術」です。そして、一事を成した人 （あるいは、大きな業績を示して現役を退いた人） は、自らの人生を回顧して、「心得え」を語ろうとします。「心得え」を語る人が偉大であればあるほど、聴くほうの人は語られる「仕事を成すときのコツ」を信頼しますが、聴くほうには、それを実現すための「技術」がなければならないでしょうね。

　「表現」は、的確な「技術」に裏打ちされていなければ、危うい。たとえば、ピアノの演奏では、的確な技術を体得していないで、ただただ、情感たっぷりと弾いても、感動を呼び起こすことはできないでしょうし、逆に、情感が先走った演奏には嫌悪感すら感じます。
　訴えたい思い（あるいは、意見）を整えて的確に伝達するのが「技術」です。

　我々の業界 （ＩＴ業界） では--あるいは、おそらく、どのような業界であれ--、「技術」の裏打ちがないくせに、意見を言い散らすことを「能書きを垂れる」という言いかたをして、軽蔑の対象になります。たとえば、新卒の人が、「コンピュータは経営に役立つことを目的としている」と言えば、先輩たちは苦笑するでしょう。なぜなら、それを実現するために、プロは技術を使うのだから。プロは、それを実現するために、具体的な手続き （how-to） を提示するのだから。

　さて、life-cycle という言葉がありますが、「適時 （時節）」ということが大切でしょうね。
　でも、これを気づくのが、なかなか、むずかしい。というのは、若い頃には--実際の仕事に就業していない頃には、実際の技術を習得する機会がないから--、「概念」しか知ることができないし、そして、その人が知識欲旺盛で、読書すればするほど、まず、書物を通して社会を知る、という現象が起こるから。

　「技術」というのは、使われてはじめて「技術」になるのであって、プログラマはプログラムを作成することが仕事であるし、 SE は、事業を解析してシステムを設計することが仕事なので、プログラマが、どれほど、データベース設計論に関して豊富な知識を習得していても、プログラムを作成できなければ、エンジニアとして役に立たないし、 SE が、どれほど、事業戦略に関する知識を豊富に習得していても、システムを設計できなければ、エンジニアとして役に立たない。
　エンジニアは、--たとえ、その人が どのような人生観を抱いていようが、--エンジニアとして「体得している技術」が評価対象となる。エンジニアの評価は、技術が評価の対象であって、人 （character） が評価の対象になるのではない。あるいは、エンジニアが、ピアノ演奏の上手さを誉められたとしても、エンジニアとしての評価にはならない。
　この冷徹な意識がプロ意識ではないでしょうか。

　ただ、難しい点は、一生、プログラマとして仕事ができるか、という点です。
　少数の天才的なプログラマは、生涯を通して、プログラマでいることができるでしょうが、おおかたのプログラマは、３０歳過ぎ頃から、キャリアを迷うのではないでしょうか--少なくとも、僕は、迷いました。プログラマの仕事を離れるとき、選択できる道は２つでしょう。１つは、業界のなかで、通常のキャリア・パスとなっている「プログラマから SE になる」という道と、もう１つは、コンピュータ業界を離れる、という道です。僕は２つとも体験しました（笑）。というのは、「人間プログラム製造機」扱いされていることに対して嫌気を感じて、いったん、コンピュータ業界を離れてガードマンの仕事に就きました。そして、コンピュータ業界にもどってきました。

　コンピュータ業界を離れて再就職するときに ぶつかった壁が「即戦力」ということでした。
　すなわち、すでに、30歳近い年齢になっていますから、求職しても、雇う企業のほうは、年相応の「即戦力」を期待する、という点です。30歳の--しかも、すでに、企業のなかで仕事をしてきた--職業人を「新卒」として迎えるほどに企業人事は悠長ではない。再雇用する企業のほうでは、当然、仕事のなかで培ってきた年相応の技術力を期待します。

　そして、僕は、とうとう、コンピュータ業界に復帰することになりました。コンピュータ業界にもどった僕は、再び、プログラマとなりましたが、すでに、「人間プログラム製造機」扱いに対して嫌気を感じていたので、なんとか、「次のステップ」に進みたいと思っていました。「次のステップ」に進むときには、「次のステップ」の準備をしていなければならないでしょうね。この時点で、さきほど述べた「むずかしい」点が出てくるようです。すなわち、プログラマはプログラマとしての「技術」が評価の対象になるのですが、（ SE になるためには） SE の準備をしていなければならない。この匙加減が非常にむずかしい。
　というのは、プログラマは、システムが導入間近になると、（現実問題として）残業や徹夜が続いて、ほかの勉強をする余裕がない。あるいは、逆に、（キャリア・パスのなかで） SE になることを本来の目的としていて、プログラマという仕事は、システム構築とは どういうことをするのか、という点を おおまかに理解するための１つの体験 （２年や３年の「腰掛け」程度の体験） に過ぎないというふうに扱えば、そういうプログラマの作成したプログラムなど、シロートが作成したプログラムに過ぎない。

　キャリアの人口構成から判断しても、プログラマと SE の比率が「１：１」の対応関係であることはあり得ない--ピラミッド構成にならなければ、組織の構成が成立しない。つまり、「プログラマから SE になる」というキャリア・パスは、プログラマの半数以上が辞めることを前提にしている。競争原理だといえば、それまでのことですが、、、。

　ただ、論点になるのは、プログラマとして、「ほどほど」の実力だけれど、データベース設計論を「ほどほどに」知っている人のほうが、データベース設計論を知らないけれど腕の立つプログラマに比べて--第一級とは言っていない点に注意されたい、なぜなら、第一級のプログラマは、並の SE なんかよりも、データベース設計論を知っているから--、 SE になるチャンスが高い、という点です。

　とすれば、「ほどほどの」プログラム作成技術と「ほどほどの」システム設計論を知っている人が SE になる「危険性が高い」。つまり、 SE という仕事が、中途半端になっている、ということです。「ほどほどの」プログラム作成技術と「ほどほどの」システム設計技術をもっている人が、プログラム作成技術に関して、並以上のプログラマと話しても、技術が及ばないけれど、いっぽうでは、「プログラマに比べて、システム設計技術を知っている」という的外れな感想を抱くでしょうし、システム設計技術に関して、並以上の SE と話しても、システム設計技術が及ばないのだけれど、「プログラムのしくみを知っている」とうそぶくでしょうね。
　なぜなら、そうしなければ、（数々の技術を「ほどほどに」知ってはいるけれど、１つも専門的な技術を体得していない） 自らの raison d'etre を証明できないから。

　「制限された合理性 （与えられた環境のなかでの現実的なソリューション）」というのは、「ほどほどの」ソリューションという意味ではない。なぜなら、与えられた環境のなかで、認知できるかぎりの物事を把握する第一級の才覚がなければならないから。
　おそらく、そういう resourceful （あるいは、capable） な人というのは、100人のなかで１人くらいでしょう。僕は、クライアントのなかで、そういう resourceful な人たちを観てきていますが、「すべて」の人たちが、そうでなければならない、というのは無理な期待でしょうね。逆に、そういう人たちばかりだと、「組織」が成立しない（笑）。

　英語には、「有能」を記述する代表的な形容詞として「able」と「capable」がありますが、「able」は、「任に堪えうる能力」であり、「capable」は「（潜在能力を示唆する） 臨機応変な才覚」を意味するようです--潜在能力は良いほうにも悪いほうにも適用できるので、capable には、悪い意味にも使うことができるようです （たとえば、昨今、報道されている企業犯罪のなかで、capable of forging official documents とか）。

　プロであるなら、「able」は最低限の前提です。そして、第一級の「技術」を、たとえ、体得していても、「心得え」が疎かになれば、「訓練された無能」ということになるのでしょうね。
　「技術」の習得と「心得え （あるいは、適用目的）」の理解は、両車輪なのですが、年齢に応じて、どちらかの色が強くなるようです。ただ、エンジニアとして「現役」であるということは、「技術を使うことができる」ということと同値である、と思っていいでしょう。エンジニアであるなら、評価の対象となるのは「技術」です。そして、それは、的確な専門技術のことをいっているのであって、「ほどほどの」技術ではないことは確かでしょう。

　コンピュータ業界紙には、概念をまとめた多くのキーワードが飛び交っていますが、業界紙は、マーケットの動向を感知するための１つの材料にすぎない。もし、マスコミのなかで拾ったキーワードのいくつかが気になるのなら、しかるべき文献を読まなければ、詳細な情報を得ることができない。それらのキーワードを提示した原文を読まないで、様々な評釈の尾ひれを付け足すようなことには関与しないで、立脚点としている「技術」が、環境の変化 （あるいは、適用目的） に対応できているのかどうか、という点を、エンジニアとして、冷静に見極めるようにしてください。技術のなかのどこが論点になるのか、という点を見極めるには、「技術」は、当然ながら、的確な技術であって、「ザッとした」おおまかな技術の理解では対応できない、ということを忘れないでください。
　くれぐれも、「歌を忘れたカナリア」にならないように注意してください。

　
　（2003年12月7日）