IT業界は人に教える文化がない、みたいな主語の大きすぎる話はそっと横に置いておいて、人に教えていると思うことを書きます。
新しい分野が出てきてそれが仕事になりそうだと気づいたとき、誰かがその分野に取り組まないと始まらないのですが、やっぱりそういう時は私のようなこれまでの状況をわかっている人がやったほうが効率はいいです。新しい技術と言っても無から生まれたのではなく、これまでの経緯等々の結果生まれたイノベーションだからです。むしろ、これまでの経緯がわかっている人すらわからない技術なんて、だれもわからないので広まらず、時間軸の中で消え去るのみです。流行する技術と言うのは、いつでも、とっつきやすく、結果が出やすい。ただ、やっぱり前提知識がないと、本も技術情報も少ないのでハードルはあると思います。
さて、じゃあ知識があるからってすんなり身に着けられるかというと、苦労の連続です。よく新しい技術を取り入れた会社が「・・・を自力で構築した後の運用１年間、苦労の連続を語る」みたいなプレゼンを外部公開していると思いますが、新技術は想定外なことがたくさんです。特にバージョンアップが激しく、互換性はある程度確保しつつもどんどん機能が増えて行ったり、過去の機能が切り捨てられていったりするので、安定するまでは余計な仕事に巻き込まれることが度々です。また、ある目的を達成するための方法がいくつもあり、業界内でどの方法を採用するのか決まり切っていない、という問題もあります。どの方法を採っても達成できるけれども、数年後にはデファクトスタンダードが決まっていて周りは全部その方式なのに、自社だけマイナーな方式にしてしまい運用が大変、ということもあります。
新しい技術というのは、波乱含みなのを頭に入れたうえで、とにかく、あの方法もこの方法も試してみます。実装方法は自由でどうとでもできますよ、というのは、じゃあどうするの、という方法は自分で見つけなければいけません。ですから、このような状態で方法を確立するというのは、はたから見て非効率に見えるかもしれません。だから、これまでの技術ではどうしてきたか、というリファレンスのようなものが必要になると思います。このレベルでは、手順書なんて作りません。試行錯誤しますから、その中で感覚として実装方法をおぼえていく、という段階です。
さて、なんとかかんとか実装手順を確立し、これが正解かな、という知識を得たとします。そこからは自分以外のメンバーに基礎レベルを身につけさせなければいけません。自分だけしかできない技術なんて、属人化の世界に入門することと変わりありません。ある程度は基本レベルとして必要な知識はわかっているので、何らかのドキュメントを作ってその通りやってみて、と指導することになります。ドキュメントを配布する以上は自分で検証し、問題なく動くことを事前にもちろん確認します。そうやって、技術を教えていくプロセスは進みます。
しかし、ここで、ある程度プロセスが進んだところで、「じゃあ、こうするためにはどうしたらいいか、自分で調べて答えを出してみてください」と言う、自由記述型の課題を出したとします。急にメンバーは困惑し出すのです。新幹線で快適な旅をしていたら、急に徒歩になって、自分の足で歩いて見てください、というような状況に追い込まれたような反応をします。
でも、私は、樹海に入って出口の分からない道を探索し、どうにか道を引いたのですから、すこしぐらい探検したっていいのではないか、ガイドもいるのだし。
この温度差に、最近のプログラミングスクールの話や、IT業界は教えてくれない、の件と同じ空気を感じます。もともとインターネットが仕事に使われだした1990年後半あたりの状況は、新技術が四方八方から吹き出し、同時に全部はやれないので、各自興味や業務状況により散らばって、選択して苦労して身に着けたものでした。もちろん道などなく、英語のマニュアルなどと格闘し試行錯誤で理解していくスポーツでした。
いつのころからかスマートになり、ある程度の技術は鉄板構成が決まり、そしてどんどん構築は自動化されていきました。今やクラウドでWEBで数クリックすれば構築できてしまうところまで来ています。
そう言った、道が舗装されているところをガイドしてもらって、それで技術を身に着けたつもりになる風潮があり、ちょっと道を外れるとすぐに迷子になってしまう。
技術者は、私は、いつでも密林に入り道を切り開くことができる能力が必要と思っています。だから、教える、ということはするけれども、それでは技術者ではないよ、といつも言っています。勝手に冒険をはじめるような人でないと、この業界はなかなか上に行けない、そう思います。
