技芸(アート)における経験の重要性

今日は過去に読んだことのあるWeb記事をふと読みなおして感じたことをつらつらと書いてみます。

プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（SIビジネスの本質編） － Publickey
プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（クラウド時代の受託開発編） － Publickey
プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（夢に挑戦できる社会にする編） － Publickey

なぜ受託開発をやめたかというと、アジャイル開発が受託開発の中でうまくいかないんですね。
プログラマだからうまくいかないのかと思ってリーダーをやってみましたが、うまくいかないと。マネージャをやってみたけどうまくいかないと。営業で仕事をとってくるところかなと営業もやってみたんだけどうまくいかないと。
ではなにが悪いのかというと、受託開発というビジネス構造が悪いのではと思うようになりました。

プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（SIビジネスの本質編） － Publickey

なんか上のエピソードを読んで、「あ〜、これは誰にも真似できないな(=誰も第二の倉貫さんにはなれないな)」と思いました。
文章で書くとほんの数行ですが、これ実際にやってみて、色々考えて「受託開発というビジネス構造が悪い」という仮説を導きだすための過程を想像すると、膨大な時間や苦労を経てきたはずです。

上のエピソードに限らず、Web記事を読んでいくと、SI時代から現在に至るまで相当な紆余曲折、波瀾万丈(?)な出来事と、様々な仮説と検証を繰り返しています。
こういう経験の積み重ねは「その人にしかできない技芸(Art)」を生み出します。
ある人が同じ問題に遭遇したとしても、その達人と同じように対処し、解決することは不可能です。
失敗に終わったり、相当な遠回りをして解決したりすることになります。

話を少し変えますが、僕の妻はパン屋をやっています。
妻は完全に独学でここまでやってきたという少し変わった経歴を持っています。
しかし、「独学＝素人レベル」「どこかで修行してきた人＝プロレベル」になるとは限りません。

「独学で5〜6年パンを作り続け、昨年パン屋をオープンした」と書けばたった一行ですが、傍らでその様子を見てきた僕に言わせると、半端ないぐらい大量のパンを焼き続けていました。
毎日のように試行錯誤して、試作を繰り返し、相当な時間とお金をつぎ込んできています。
僕が「おいしいやん。見た目もまあまあきれいやし、もうええやん？」と言っても妻は納得せず、時々「パン・ノイローゼ」にかかったようになりながら、パンを焼いていました。
現在、お店は繁盛していますし、お客さんもみんなおいしいと言ってくれますが、妻は現状に満足しているわけではなく、たぶん死ぬまで「もっときれいでおいしいパン」を追求し続けるんだろうと思います。

時々妻は僕にこう言います。
「私がレシピを公開しても絶対誰も同じパンは作れない。そもそもその日の気温や湿度、生地の状態なんかを見ながら、日によって作り方を微妙に変えているから決まったレシピ自体が存在しない」
と。

これもまた経験の積み重ねが生み出した「技芸」であり、「アート」です。
妻と同じパンを焼くことは誰にもできません。

では、経験のない人間が問題に対処するとどうなるか？
これは僕のこんなエピソードが役に立つかもしれません。

2〜3年前、中規模なWebシステムを新規開発するプロジェクトに僕は参加しました。
数年ぶりの割と大きめな新規開発案件だったので、僕の鼻息は非常に荒く、「完璧な理想のアーキテクチャを作り上げたる！！」と意気込んでいました。
.NETで作ることがほぼ確実だったので、僕は.NETやアーキテクチャ設計に関連する本を山ほど読みあさってから案件に着手しました。
そのときに参考にしていた本を挙げてみます。

.NETエンタープライズWEBアプリケーション開発技術大全VOL.3 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ)

.NETエンタープライズWEBアプリケーション開発技術大全VOL.4 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ―Microsoft.net)

.NETエンターWEBアプリ開発技術大全5 トランザクション設計編 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ―Microsoft.net)

Microsoft Visual Studio 2005によるWebアプリケーション構築技法 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ)

[asin:4891005122:detail]

プログラミング MS ADO .NET2.0 (マイクロソフト公式解説書)

実践!ソフトウェアアーキテクチャ ~VisualStudioとASP.NETによる業務システム開発方法~ (.NET TECHNOLOGY)

Effective C#

More Effective C#

.NETのクラスライブラリ設計 (Microsoft.net Development Series)

他にもあったような気もしますが、ぱっと思い出せるのはこれぐらいです。

で、僕としては「これだけ勉強したんだから、怖いものなしやわー！」と思っていたのですが・・・すぐ小石につまずきました。
実際に自分でシステムを作ろうと思うと、「あれ？こういうときはどうするんやろ？こんなケースは本には載っていなかったな・・・」みたいな場面にしょっちゅう遭遇しました。
何とかシステム自体は無事に完成しましたが、案件着手前の「怖いものなしやわー」という予想とは裏腹に、「結構、大変やったね・・・(汗)」という感想で終わりました。

結局のところ、本を読むだけでは「知識」が得られるだけで、「経験」は得られません。
よって「技芸」を習得したことにはなりません。
「問題発生！こんなときどうする？」という場面で、さっと解決策を編み出せるか、はたまた右往左往して貴重な時間を食いつぶしてしまうのかは経験の有無が大きな差を生みます。

もちろん、読書自体は悪いものではないです。
読書によって得られる知識は、問題解決への「正しい道筋」をある程度教えてくれます。
予備知識なしに問題を解決しようとすると、異様に遠回りしてしまったり、間違った道を選択して失敗に終わる可能性も出てくるでしょう。
実際、妻もパン作りに関する本はたくさん読んでいます。

そろそろまとめます。
結局、倉貫さん、僕の妻、そして僕自身のエピソードを通じて何が言いたかったのかというと、

技術スキルや技芸(アート)といったものは経験や試行錯誤の積み重ねなしでは体得できないものであり、そのようにして得られた技芸は他人が簡単に真似できるものではない

ということです。

そしてそれがその人の「取り替えのきかない価値」になります。
不況が長引くこの時代、「取り替えのきかない価値」を持っている人は強いです。
なぜなら、その価値から自分でお金を生み出すことができるからです。

他人が真似できない、あなたの「技芸」は何ですか？
あなたは「取り替えのきかない価値」を持っていますか？
会社や社会において、あなたは「取り替え可能な部品」になっていませんか？

ここで一度、その答えを考えてみてはいかがでしょうか？
さらに、

我々のソフトウェア開発という仕事は「誰でも同じように作れる工場」を目指すのか？
それとも「他人が真似できない技芸」を追求すべきなのか？

これも現状のIT業界とこれからのIT業界を考える上でも重要な問いになるのかもしれません。

・・・って、思うままに書いていったら妙に大きなテーマに着地してしまいました。
今日はいつもと違って、ノープランでブログを書いてみました。
たまにはこんなのもアリですかね〜？？

というわけで、おしまい！

あわせて読みたい

達人の技芸を継承する方法はこの世に存在するか？ - give IT a try
このエントリの続編を書いてみました。

プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン | Social Change!
倉貫さん本人のブログにも同じ内容が載っています。

夫から見たパン屋さんの舞台裏 - give IT a try
妻のパン屋のエピソードはこっちにも色々書いています。