「ミング」の時間ですよ

知ることとやることは違う

よく言われること。知っててもやってみるとなかなかできないもの。

そう、「知ることとやることは違う」違うこと...

「知識と経験は違う」これもよく言われること。

知識豊富な人と経験豊富な人をイコールで結ぶことはできないのは、言うまでもなく皆が知っていること。

「ミング」って...プログラミング (Programming) のミング。

プログラムを知ることとか、プログラムの知識を得ることではなく、プログラムを書くこと、一行一行書いていく行為。(ミングは、-ing形の部分に着目した造語です)

プログラムに求められていることを理解し、その限られた時間を書く行為に適切に割り振り、オーダーメイドな「役に立つもの」に仕上げる。書いた後にもそれが生き続けることを念頭に入れて。

プログラマーは成長するために勉強をします。何を勉強するか？文法を覚える？APIを覚える？概念を覚える？ショートカットを覚える？大事なことです。それやらないと先に進まない。でもそれらは「ミング」のための下ごしらえであり、「ミング」自体ではない。

覚えるものではなく、体得するもの

「ミング」の練習は難しい。それは知識ではなく、かといって経験とも言い切れないが、本を読んでもネットで調べても得られないもの。プログラミングのお作法を覚えるってのに近いことかもしれない。でも、それはやはり知識でしかなく、そのお作法をうまく活用できるかどうかは、「ミング」中に頭を支配しているパイロットの腕次第だ。

「ミング」は覚えるものではなく、体得するもの

ロジカルで工学的なイメージがあるだろうが、実はバッターボックスに立つのとそう変わらない。

別にバッターは反射神経で打ってるわけではない。試合の状況、ランナー、スタジアムの広さ、相手チームの守備力、さらには天候・湿度と様々な要因を限られた時間で考慮に入れて、何を投げてくるかわからないピッチャーに対して、バットを振る。とてもロジカルであり、とても感覚的でもある。

プログラムへの要件は常に変化する。同じ道は歩かない。要件って言うと、画面仕様とか業務仕様を思い浮かべてしまうかもだが、プロジェクトの状況、そのプログラムに割ける時間、周辺実装との連携、書いた後のメンテ、コーディングポリシー、実行パフォーマンス、フレームワークの利用、って書ききれないほど要因はある。その場その場で、やるべきこと考えるべきことは変わる。

知識は必要だが、知識を活用するのは感覚だ。その感覚、なかなか言葉で表現するのは難しい。

「ミング」に割く勇気があるだろうか？

若いプログラマー、勉強するって何をする？やっぱり本を読む？仕組みを覚える？ツールの使い方を覚える？それらはとても大事なこと。

とはいえ、プログラマーはプログラムを書いてるばかりが仕事ではない。一年のうち、プログラムを書く仕事をやっている時間は、実は半分もいかないこともあるだろう。四分の一くらいかもしれない。

仕事をこなすには、知識を得ないといけない。覚えることがたくさんある。覚えれば仕事ができる。

昨今、さらにインフラやアーキテクチャの多様化により、覚えることは多くなった。同時に仕事も書くばかりが仕事ではなくなり、業務時間に「ミング」を体得していくことが、とても難しいように思う。

さらにやっかいなのは、「ミング」には正解がない。「ミング」の先輩たちも、それを構造的な知識として後輩に与えることはなかなかできない。まだ車の運転をしたことのない人に対して、言葉だけで運転できるようにさせられるだろうか？

正解がないため、「ミング」にはゴールが設定されていない。ゴールがないものを学ぶのは確かにそれは大変なこと。いくらでも向上できるものである一方、ある程度のレベルに達してしまうと、その先が見えにくくなって向上意欲が消えやすいもの。

「ミング」が未熟で、それにより問題が発生したとしても、そもそも「ミング」の向上で問題が解決できると気付きにくい。なんとなくわかっても、それを誰も証明できないからなおさらだ。知識なら簡単だ...「知ってたら回避できた」と口を揃えて言える。

厳しい業務の中、そして、かろうじて自分を成長させるために確保した貴重な時間、果たして「ミング」に割く勇気があるだろうか？

でも、「ミング」も忘れてはいけない。矛盾だ。

作り上げる様をしっかりと演じよう

若い人と接することが多い今日この頃、「ミング」を伝えるにはどうしたらいいだろうと、常々考えていたことをちょっと綴ってみました。

色々とよく知ってるはずなのにプログラム書いてみると、いまいち活かせてなかったり、効率の悪いロジカルシンキングだったり。最近では、DBFluteハンズオンという、DBFluteを学ぶための実践形式(プログラムミング形式)の
勉強会をよく開いているのですが、それぞれの「ミング」の個性がよく見えてきて、とても興味深いものです。一方で、DBFluteだけ伝えてもダメだと。DBFluteの機能を授けても、「ミング」で失敗している場面をよく見かける。

究極的には「知識」と「ミング」はバランスよく、ってのが結論なんだけど、どうしても知識優先になってしまうなぁと。そう...みな必死に覚えようとするのです。とても優等生ではあるのです。

そんなみんなに、jfluteが口すっぱくみんなに言っていることがあります。

答えを覚えることよりも、答えを導くためのプロセスを学んで欲しい
　=> 答えよりも答えを導くプロセスを | jfluteの日記

といっても、やっぱり答えを求めちゃう。まあそりゃそうなんだよね。目先で求められてるのはそれだし。なによりも、その方が楽だから。「プロセスを感覚的に覚えて体に馴染ませて...」って言ったところで「はぁ？」だよね。

ただ、限られた時間、限られたチャンスがある。勉強会やソースレビュー会、ペアプロ、ペアデバッグなど、短い時間ではあるが。

スポーツとほぼ同じだ。

o 人の試合を見ること
o 練習試合をすること
o 試合内容を分析すること

もっと実装している風景を見せよう。

実装のリズム、ロジカルシンキングの感覚、要件との戦いの風景。わかりきっていることだとしても、書き終わったコードを見せるだけでなく、それを作り上げる様をしっかりと演じよう。(大変なんだけどね)

DBFluteハンズオンでは、「ミング」の要素をたくさん盛り込んでみた。「ミング」だけで時間を割いて勉強会ってのはなかなかできない。DBFluteを学びながら、ちょっとした「ミング」も学べるといい。

人の試合も見て、練習試合もして、その上で、「ミング」の要素を分析して解説して、知識と感覚の両面から、その要素を体得してもらえればと。

自分も若い頃、尊敬する師匠の隣の席に座っていて、プログラムミングや問題解決やデバッグやら「-ing」を、そのリズムとニュアンスと「空気」を学んだものです。何を学んだのかって言葉にできないですが、確かに受け取って成長した。

「ミング」を伝えたい。
自分もさらに「ミング」を鍛えたい。

※休日を使ったペアプロは良かったね。
　=> DBFluteの実装風景　その八 (ペアプロ) | jfluteの日記