give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

達人の技芸を継承する方法はこの世に存在するか?

前回投稿した技芸(アート)における経験の重要性というエントリを改めて読みなおしてみると、「誰も第二の倉貫さんにはなれない」とか、「妻と同じパンは誰にも焼けない」とか、見方によっては救いのない印象を与えたまま終わってしまったのが、ちょっと残念だったかな〜と感じました。(自分の書いた文章ながら)


まあ確かに、達人の技芸を完璧に継承することは不可能だとは思います。
ですが、ちょっとでも近づいたり、達人の心意気や考えは取り入れつつ、その人独自の路線で進化(深化?)させたりすることは可能なんじゃないかとも考えています。


ちなみに、プログラマであれば、以下の2冊にそれらしきヒントが見つかるかもしれません。
(というか、久々に本棚から引っ張りだして読んでみたら、前回のエントリに結構内容がかぶっていました。別に意識して書いてたわけじゃないんですけどね)

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

  • 作者: ピートマクブリーン,McBreen Pete,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2002/03
  • メディア: 単行本
  • 購入: 4人 クリック: 85回
  • この商品を含むブログ (63件) を見る
アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

  • 作者: Dave H. Hoover,Adewale Oshineye,柴田芳樹
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2010/07/08
  • メディア: 単行本(ソフトカバー)
  • 購入: 12人 クリック: 221回
  • この商品を含むブログ (53件) を見る


とはいえ、別に僕はこれらの本の通りに何かを実践して自分の技芸を向上させてきたわけではありません。
なので、「きっとこの本を読めば何とかなるでしょー。それじゃ!」と言って終わらせるのもちょっと無責任です。


そこで自分の経験から、達人の技芸を習得するいい方法は何かないかな〜?と自分なりに考えてみました。
すると過去に僕が参加した2つの開発案件が頭に浮かんできました。
今回はこの経験談から「達人の技芸を継承する方法」について考えてみたいと思います。


一つ目はSIer時代に参加したJavaの新規開発案件です。
その案件ではM江さんという先輩が開発リーダーとして積極的に新技術を取り入れようとしていました。
当時は「WEB+DB PRESSの読者であれば聞いたことはある」ぐらいの知名度だった、StrutsやHibernateを案件に取り入れていました。
また、JavaScriptを使ったUI制御も自分でフレームワーク化していて、パラメータを少し変えるだけで、色々な画面でその部品を再利用することができました。


この案件に参加した当時、僕はこの業界に入ってちょうど1年が過ぎたぐらいの頃でした。
入社してからそれまではVBの案件が中心でした。たまに小規模なJavaの案件もありました。
しかし、今思えばプログラムはどれもトホホな作りでした。
たとえば、1画面=1プログラムで、似たような画面からコードをコピペしてモディファイ、という作り方が大半を占めていました。
ある案件のVBプログラムはやたら不自然なロジックで改造しにくかったのですが、開発の歴史を聞くとそれもそのはず、COBOL時代のロジックをそのままVBに移植しただけだった、なんてこともありました。


なので、「プログラムはコピペして作るもの」としか考えていなかった(そして実際にそう教育されていた)PG1年生の僕にとって、M江さんと一緒に開発したこの案件はもの凄い衝撃でした。
コピペなんてしなくても違う画面が作れる、SQLの結果をResultSetから取り出す処理を書かなくても結果が取り出せる、サーブレットのややこしいリクエスト&レスポンス処理を書かなくてもブラウザとのやりとりを簡単に実現できる、といったことは僕にとって魔法のように見えました。
そして、英語のオンラインドキュメントをモニタに映しながら僕たちに指示を出したり、助けの手を差し出したりしてくれるM江さんが本当にカッコよく見えました。


この案件以来、僕は「技術を知っていれば、それまで苦労して実装していたことが簡単に実現できる。技術って面白い!」「新しい技術を取り入れようとするなら英語はやっぱり切り離せないんや!」と強く思うようになりました。
この案件に参加していなければ、今の僕は存在しなかったと言っても過言ではありません。


印象に残っている二つ目の記憶はその約1年後に参加した比較的大規模なJava案件です。
このときは僕は別会社に出向していました。
そこで出会った出向先のO原さんという方がこの案件の技術責任者でした。
O原さんは飄々とした雰囲気の、「一風変わったおじさん(失礼)」です。
しかし、オブジェクト指向やデザインパターンについてとても造詣の深い方で、大規模なシステムを効率よく構築するためのモジュール化やレイヤー化なども積極的に取り入れていました。
「なるほど、システムの作り方にはそんな考え方や手法があるのか」と感心しながら僕はO原さんの説明を聞いていました。


O原さんはいわゆるPOEAA本を参考書籍として僕たちに薦めてきたことを思い出します。
今では「それぐらいの技術書ぐらい読んでてて当たり前やん」と思いますが、当時は「こんなに分厚くて難しそうな本をこの人読んでるの!?すげー!!」と驚いたのを覚えています。
あれはたしか翻訳版が出るか出ないかぐらいの時期だったので、もしかするとO原さんは洋書を読んでいたのかもしれません。

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION)

  • 作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート
  • 出版社/メーカー: 翔泳社
  • 発売日: 2005/04/21
  • メディア: 大型本
  • 購入: 10人 クリック: 635回
  • この商品を含むブログ (143件) を見る


僕たちはO原さんの助言や指導を受けながら、担当モジュールのクラス設計やHibernateやSpringを使った実装を進めていきました。
そうそう、JUnitのような単体テストフレームワークを使ったのもこの時が初めてでした。
大規模案件だったこともあり、長期にわたって助言や指導を受けたので、オブジェクト指向設計やJavaの新技術をかなり深く勉強することができました。


このように、M江さんやO原さんが当時の僕にとっての「達人」でした。
その達人と一緒に仕事をすることで、僕は彼らの技術そのものだけでなく、彼らの技術に対する心意気(Attitude)も一緒に学び取りました。
あの開発案件以来、彼らと一緒に仕事をすることはありませんでしたが、それでも僕はM江さんやO原さんに追いつけ、追い越せの精神でたくさん本を読んだり、最高のアーキテクチャを目指して自分でシステムを設計したりしてきました。


そういえば僕の妻も、「趣味のパン作り」から「本気のパン作り」に心意気が変わったのは、ネットで有名なパン作りの達人のパン教室に行って、刺激を受けたときからだと言っていました。


僕も妻も意識的に達人から何かを引き継ごうとしたわけではないので、「これが技芸を習得する最善の方法だ」と言いきってしまうのは少し無理があります。
どちらかというと、偶然の出会いによって自分の中で何かが目覚めたり、予期しないほどのスキルアップを実現できた、と言った方が正しいです。
しかし、結果としては達人の心意気や技術を引き継ぎ、分かれた枝を良い形で伸ばすことができたんじゃないかと思います。


つまり、達人と実際に出会い、達人と深い関わりを持つことが、達人の技芸を継承する最も有力な方法だと僕は考えます。


一方、達人が残した言葉を読むだけだったり、自分一人で試行錯誤するだけだったりすると、その達人に近づくのはなかなか難しそうな気がします。


達人の技芸を継承する何か良い方法は存在するか?
自分や周りの人で達人の技芸をうまく継承できた人は存在するか?


もし何か良い情報があれば、みんなで共有していきたいですね。

あわせて読みたい

技芸(アート)における経験の重要性 - give IT a try
前回のエントリをまだ読んでいない方がいれば、こちらをどうぞ。


「わたしがプログラマという職業を選んだ理由」 - give IT a try
M江さんの話は強烈な印象として残っているので、僕のブログに時々登場します。


O/Rマッピングツールに対する誤解をときたい - give IT a try
O原さんと一緒にHibernateを使い倒した経験を元に、O/Rマッピングツールの利点について述べてみました。