成長の鍵はアウトプット：知識を行動に移す重要性
アジャイル開発とかクラウドコンピューティングとか、新しいコンセプトが世の中を席巻している。知らないでは済まされない。だから学習する。費用負担とかなしの社内研修でも開けば、大入満員だ。でも業務利用はと言うと進まない。こういうの、あるあるだよね。
ペーパードライバーの背伸び
進まないどころか、「新規のアジャイル案件があるんだけど」「クラウド案件があるんだけど」と打診すると「いや、まだ実案件はちょっとね」となることもあるらしい。それが研修受講者や資格取得者のいる部署でもだというのだけど、ちょっとおもしろいなと思ったのがこれ。
まだペーパードライバーみたいなものだから、実案件はちょっと…
聞かされた人は「ニワトリが先かタマゴが先か」的なむず痒さを覚えたようだけど、僕としてはちょっと思うところがあった。
AWSには2024年初めの時点で247ものサービスがあり、2023年の実績で年間2,705件のアップデートがあった。AWSの方と打合せをすると、彼らにも名前ぐらいしか知らないサービスや聞いたことない機能が普通にある。彼らですら得意な部分以外はペーパードライバーなのだ。
僕もアーキテクトのような役割をしているけど、詳しくないサービスや方法論がポンポン要求される。「動画を配信したいのですけど、IVSってやつを使えばいいんですかね？」「もう少し詳しく…なるほど、複数のソースと2～3桁の配信先という形なら、KVSの方が適していそうですね」。そう言ってから、心の中で「どっちも触ったことないけど」と付け加える。
僕もペーパードライバーだけどなと思いつつ同じようにしている仲間4人と話してみたのだけど、「そうだよね、僕たちはペーパードライブしている」とみんなが言った。ペーパードライブして、詳しくないサービスでもそれがよいアーキテクチャなら提案して、採用されちゃったら必死で食らいつくぞと思いながら毎日背伸びしている。
学習を捨てよ、実務に出よう
先日、ジョシュ・カウフマンの「20時間の法則」を紹介したけど、その中で彼はこう言っている。
自己修正できるだけ学びます。3〜5つのリソースを手に入れて、それが本であれDVDであれコースであれ、何でも構いません。ただし、これらを練習の言い訳に使わないようにしましょう。私もそうすることがありますが、20冊の本を手に入れて、「プログラミングを学び始めるのは、この20冊を読了してからだ」と考えるわけです。それは実際には先延ばしです。実際に練習を開始できるようになるまでの学びを抑え、自己修正または自己編集できるようにしましょう。
20時間の法則でも、その元となっているアンダース・エリクソンの「1万時間の法則」でも、訓練や練習は適切なフィードバックを得ながら行うことが重視されている。「自己修正」というのは、自分の出来を自分で評価しフィードバックできる程度には、知識を学んでお手本を自分の中に持っておくという事だ。ただし、学習に夢中になって、練習を始めるのをいつまでも先延ばししてはいけない。
AWSのスキルを身につけたいなら、この点はなおさら重要だ。だって247ものサービスがあり年間2,705件のアップデートがある。「一通りのサービスを学んだら」「最近のアップデートを把握したら」と考えたりしたら、いつまでも学習したら終わるのか想像もつかない。どこかで「まだ知らないことがあるから」ではなく「知らないことがあるけど」と言うことにして、実務に飛び込まないと、「実際にやってみる」という練習が始まらない。
フィードバックはアウトプットが生む
じゃあ、学習をどこかで「終える」のではなく「打ち切る」のだとしたら、自己修正の話はどうなるんだろう。フィードバックは？
簡単だ。仕事であれば、アウトプットを出せばいい。仕事には求められる成果物があって、それがお手本だ。そして多くの場合、仕事はその成果を求めている人がいる。作業指示者だったり、依頼者だったり、お客様だったり。彼らは、あなたの努力なんてプロセスには見向きもしないで、あなたのアウトプットを評価してくれるだろう。そしてNGならやり直しをさせて、そのアウトプットの再評価もしてくれるだろう。だって、求めるレベルに達してないのに受け取っちゃったら、彼らがする後工程に差し障るんだから。
時にはフィードバックがもっと具体的なこともある。例えば、「動画配信ですね、IVSよりKVSの方が適していそうですね」と言ったら「なんでだい？」と聞かれたとする。説明の解像度が足りないのだ。「どうやればいいんだい？」と聞かれる。技術紹介で終わらず実現案、構成提案まで必要なのだ。「ここがちょっとさ…」と言われる。そのまま、そこを直すべきという事だ。これらの反応は、すべて修正すべき場所と、どのように修正すべきかを教えてくれている。
ちょっと当たり前のことを言っておくと、あなたのインプットしたものは他の人には見えない。だから、それに誰かがフィードバックをしてくれることはまずない。でもアウトプットしたものは見えるから、フィードバックをもらえる可能性がある。フィードバックを生むのはアウトプットなんだ。
人を成長させるのはアウトプット
AWSだからこそ、自分でフィードバック（自己修正）するのには限界があって、さっさとアウトプットに――つまりペーパードライバーだけど仕事するという決断に――進む必要がある。でもそれ以外のことでも我流で先に進むのには、限界があるよね。20時間でそこそこになるまではそれができても、1万時間とか、いやその半分の5,000時間で目指すかなりのレベルのためのフィードバックとなったら、自分でできるかな？
カウフマンの「20時間の法則」とエリクソンの「1万時間の法則」、僕なりにまとめたのが下表だけど、共通して「適切な質と量の訓練」が必要と言っていて、フィードバックが大切にされている。がむしゃらに量だけ（たとえば1万時間）やればいいとは言っていない。1万時間の法則ではフィードバックを指導者に求めているし、そこそこになるための20時間の法則では自分でフィードバックできるようになるために「練習」の前に少し本などで「学習」する。
でも、練習に先立って自己修正できるところまで学習とか言ってたら、それが終わらなくなる分野がある。あるいは、20時間と1万時間の間に、指導者をつけるまでできないけど、自己修正のある意味我流では進めなくなる段階がある。そこを超えて、人を成長させるのはインプットではなくアウトプットだ。インプットでなんとかしようとし続けるするのは、努力の方向が間違っているかもしれないと、考えてみた方がいい。成長したい本人も、成長を支援したい人たちも、インプット沼から抜け出そう。
ペーパードライバーを卒業するには実務経験が必要で、でも実務の前にペーパードライバーを卒業する必要があって……なんて、そんなニワトリが先かタマゴが先かみたいな話は、ここにはない。どっちが先か、はっきりしている。ペーパードライバー「だから」なんて言うのはやめて、ペーパードライバー「だけど」背伸びするのだ。