知ることとやることは違う
よく言われること。知っててもやってみるとなかなかできないもの。
そう、「知ることとやることは違う」違うこと...
「知識と経験は違う」これもよく言われること。
知識豊富な人と経験豊富な人をイコールで結ぶことはできないのは、言うまでもなく皆が知っていること。
「ミング」って...プログラミング (Programming) のミング。
プログラムを知ることとか、プログラムの知識を得ることではなく、プログラムを書くこと、一行一行書いていく行為。(ミングは、-ing形の部分に着目した造語です)
プログラムに求められていることを理解し、その限られた時間を書く行為に適切に割り振り、オーダーメイドな「役に立つもの」に仕上げる。書いた後にもそれが生き続けることを念頭に入れて。
プログラマーは成長するために勉強をします。何を勉強するか？文法を覚える？APIを覚える？概念を覚える？ショートカットを覚える？大事なことです。それやらないと先に進まない。でもそれらは「ミング」のための下ごしらえであり、「ミング」自体ではない。
覚えるものではなく、体得するもの
「ミング」の練習は難しい。それは知識ではなく、かといって経験とも言い切れないが、本を読んでもネットで調べても得られないもの。プログラミングのお作法を覚えるってのに近いことかもしれない。でも、それはやはり知識でしかなく、そのお作法をうまく活用できるかどうかは、「ミング」中に頭を支配しているパイロットの腕次第だ。
「ミング」は覚えるものではなく、体得するもの
ロジカルで工学的なイメージがあるだろうが、実はバッターボックスに立つのとそう変わらない。
別にバッターは反射神経で打ってるわけではない。試合の状況、ランナー、スタジアムの広さ、相手チームの守備力、さらには天候・湿度と様々な要因を限られた時間で考慮に入れて、何を投げてくるかわからないピッチャーに対して、バットを振る。とてもロジカルであり、とても感覚的でもある。
プログラムへの要件は常に変化する。同じ道は歩かない。要件って言うと、画面仕様とか業務仕様を思い浮かべてしまうかもだが、プロジェクトの状況、そのプログラムに割ける時間、周辺実装との連携、書いた後のメンテ、コーディングポリシー、実行パフォーマンス、フレームワークの利用、って書ききれないほど要因はある。その場その場で、やるべきこと考えるべきことは変わる。
知識は必要だが、知識を活用するのは感覚だ。その感覚、なかなか言葉で表現するのは難しい。
「ミング」に割く勇気があるだろうか？
若いプログラマー、勉強するって何をする？やっぱり本を読む？仕組みを覚える？ツールの使い方を覚える？それらはとても大事なこと。
とはいえ、プログラマーはプログラムを書いてるばかりが仕事ではない。一年のうち、プログラムを書く仕事をやっている時間は、実は半分もいかないこともあるだろう。四分の一くらいかもしれない。
仕事をこなすには、知識を得ないといけない。覚えることがたくさんある。覚えれば仕事ができる。
昨今、さらにインフラやアーキテクチャの多様化により、覚えることは多くなった。同時に仕事も書くばかりが仕事ではなくなり、業務時間に「ミング」を体得していくことが、とても難しいように思う。
さらにやっかいなのは、「ミング」には正解がない。「ミング」の先輩たちも、それを構造的な知識として後輩に与えることはなかなかできない。まだ車の運転をしたことのない人に対して、言葉だけで運転できるようにさせられるだろうか？
正解がないため、「ミング」にはゴールが設定されていない。ゴールがないものを学ぶのは確かにそれは大変なこと。いくらでも向上できるものである一方、ある程度のレベルに達してしまうと、その先が見えにくくなって向上意欲が消えやすいもの。
「ミング」が未熟で、それにより問題が発生したとしても、そもそも「ミング」の向上で問題が解決できると気付きにくい。なんとなくわかっても、それを誰も証明できないからなおさらだ。知識なら簡単だ...「知ってたら回避できた」と口を揃えて言える。
厳しい業務の中、そして、かろうじて自分を成長させるために確保した貴重な時間、果たして「ミング」に割く勇気があるだろうか？
でも、「ミング」も忘れてはいけない。矛盾だ。
作り上げる様をしっかりと演じよう
若い人と接することが多い今日この頃、「ミング」を伝えるにはどうしたらいいだろうと、常々考えていたことをちょっと綴ってみました。
色々とよく知ってるはずなのにプログラム書いてみると、いまいち活かせてなかったり、効率の悪いロジカルシンキングだったり。最近では、DBFluteハンズオンという、DBFluteを学ぶための実践形式(プログラムミング形式)の
勉強会をよく開いているのですが、それぞれの「ミング」の個性がよく見えてきて、とても興味深いものです。一方で、DBFluteだけ伝えてもダメだと。DBFluteの機能を授けても、「ミング」で失敗している場面をよく見かける。
究極的には「知識」と「ミング」はバランスよく、ってのが結論なんだけど、どうしても知識優先になってしまうなぁと。そう...みな必死に覚えようとするのです。とても優等生ではあるのです。
そんなみんなに、jfluteが口すっぱくみんなに言っていることがあります。
答えを覚えることよりも、答えを導くためのプロセスを学んで欲しい
=> 答えよりも答えを導くプロセスを | jfluteの日記
といっても、やっぱり答えを求めちゃう。まあそりゃそうなんだよね。目先で求められてるのはそれだし。なによりも、その方が楽だから。「プロセスを感覚的に覚えて体に馴染ませて...」って言ったところで「はぁ？」だよね。
ただ、限られた時間、限られたチャンスがある。勉強会やソースレビュー会、ペアプロ、ペアデバッグなど、短い時間ではあるが。
スポーツとほぼ同じだ。
o 人の試合を見ること
o 練習試合をすること
o 試合内容を分析すること
もっと実装している風景を見せよう。
実装のリズム、ロジカルシンキングの感覚、要件との戦いの風景。わかりきっていることだとしても、書き終わったコードを見せるだけでなく、それを作り上げる様をしっかりと演じよう。(大変なんだけどね)
DBFluteハンズオンでは、「ミング」の要素をたくさん盛り込んでみた。「ミング」だけで時間を割いて勉強会ってのはなかなかできない。DBFluteを学びながら、ちょっとした「ミング」も学べるといい。
人の試合も見て、練習試合もして、その上で、「ミング」の要素を分析して解説して、知識と感覚の両面から、その要素を体得してもらえればと。
自分も若い頃、尊敬する師匠の隣の席に座っていて、プログラムミングや問題解決やデバッグやら「-ing」を、そのリズムとニュアンスと「空気」を学んだものです。何を学んだのかって言葉にできないですが、確かに受け取って成長した。
「ミング」を伝えたい。
自分もさらに「ミング」を鍛えたい。
※休日を使ったペアプロは良かったね。
=> DBFluteの実装風景 その八 (ペアプロ) | jfluteの日記
