「ミング」の時間ですよ

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

よく言われること。
知っててもやってみるとなかなかできないもの。
そう、
「知ることとやることは違う」
違うこと...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スポーツとほぼ同じだ。

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

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

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

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

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

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


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