学びのテーマの紹介
エンジニアリングとマネジメントにまつわる諸問題を扱うポッドキャスト、
エンジニアリングマネージャーの問題集、ホストの後藤秀典です。
この番組では、エンジニアリングチームで起きている問題について、
技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体やアプローチしていきます。
今回のテーマは、ソフトウェアエンジニアとしての学び方と学びの加速、です。
学びっていうところ、皆さん結構興味がある方が多いんじゃないのかなと思っていまして、
私自身もこれ大好きなテーマでして、何度も語っているんですけれども、
普段とはちょっと違った観点でまたお話ししていきたいと思っています。
エンジニアリングマネージャーの問題集。
では今日はですね、また学びに関することを話してみようと思っています。
私のポッドキャスト、これ私の趣味なんですけれども、
意外と学び系のトピックというのをこれまでもお話ししてきてまして、
例えばエピソード15でマネージャーの学びの加速というお話をしてますし、
あとエピソード19、こちらは学び方の違いに対するマネジメントアプローチというようなタイトルで話してますし、
それからエピソード23ではカップを空にするっていう、
これ書籍で言うとアプレンティスシップパターンという本を取り上げた回だったりするんですけれども、
そんな感じでちょいちょい学びに関する私のお考え方みたいなのを話してきました。
今日もまた学びというものを取り上げるんですが、
よりどちらかというとエンジニアとしての学び方っていうんですかね、
エンジニアのスキルに寄せたような話を私の経験を交えながらしてみたいなと思っています。
大きく二つぐらいのことを話そうと思っていて、
一つは独学というか、自分自身がどういう学び方をしていくのがいいのかだったり、
そういうやり方に対してどういうことがあるのかというところを話していくのと、
もう一つ後半のほうで、自分一人で切り開くだけじゃなくて、
師匠というか、そういう人を見つけるっていうような話もしてみたいなと思っています。
まず最初、その二つのことを話すんですが、
どちらにも共通して、学びというものは何を得るものなのか、何を得るためにやるのかっていうと、
これも私の考えで言うと、具体で言えばコードを書くスキルだとか、
コーディングテクニックの何々ができるようになるとか、そういうことかもしれませんけれども、
そういったものをやっぱりソフトウェアをよりうまく作るっていう問題解決というか、
そういうところに適応していくときに、スキルっていうのとはちょっと違うんですけれども、
物事をどういうふうに捉えて、自分の持ってるスキルというか経験というか知識というかをどういうふうに適応するのかっていうような組み合わせというかひも付けというか、
いうところが大事なのかなと思っていまして、そのときに何がどういうふうにひも付けられるのか、どのように見られるのかっていうところで言うと、
複数の視点を持って物事を見れるようになるっていうことだったりすると思うんですよね。
なので、そういった視点をいかにロジカルにその視点を理解しているっていうことではなくて、
本当に自分が物事を眺める、自分の視点として持つに至っているのかどうか、こういう視点をどのように獲得していくのかっていうのが学びなのかなと思っていて、
それはソフトウェアエンジニアとしても、学びの結果、視点が持てるかどうかというところがキーになるのかなと思っていますので、
まずそこが抽象的な目標だよというところを最初に触れておきます。
独学による学びの深化
一つ目の話は、独学的なやり方によって学びを深めていくっていうところから話していきます。
ソフトウェアエンジニアなので、多くの場合、多くの時間をソースコードを書くっていうことに費やすと思いますので、
そのソースコードっていうものをいかに上手に扱えるのかっていうんですかね、っていうところが多くの皆さんにとっては非常に重要なスキルであって、
それらを磨いていくということが必要だと思っています。
これをどう僕の人生の中で飛び抜けて、僕が他の人よりも上手にできるかっていうと、そうではないと思っているんですけれども、
とはいえ一定のところまではできるようになっているのかなと思っていまして、
過去にこういうことをやったよっていうのをお話しするんですけれども、まずやっぱりコードをたくさん書くっていうことは当然必要だと思います。
ただ、闇雲に仕事で与えられた課題ではないんですけれども、仕事で取り組むイシュー、お客さまから発注されたものを作っていくっていうだけでは、
なかなか幅が広がらないものだったりもするのかなと思っています。
特に一つの会社の中だけで仕事をしていると、これは自社開発にせよ、自宅にせよ、自宅の場合もしかすると会社の特徴によっては、
かなり幅広くいろいろなものに取り組める場合もあったりするかもしれませんけれども、
ただ経営観点で考えると似たようなものを繰り返しやったほうが経営効率は圧倒的に良くなるので、
同じようなものを同じような作り方をしていくということもよくあることなんじゃないかなと思うんですよね。
自社サービスにしてもやっぱり一つのものだったり、そんなにたくさんのものじゃない似たようなものを扱っていくということが多いと思うので、
なかなかその幅が広がっていかないというのはあると思うんですよね。
こういったときにやっぱりそれだけやっているというよりは、少し違うことを題材にしたコードを書くっていうのが、
やっぱり自分自身のコードを書くときの考え方の幅を広げることに役に立ったりします。
そういった観点で僕がやったことで言いますと、これそんなに昔じゃないんですけれども、いつぐらいだったかな、2015年とかそこら辺りにやってたことで、
当時は名古屋近辺でプログラミングコミュニティとかを主催とまでは言わないけど参加していたような形で、
そのときにプログラミング問題を解くみたいなことを何度か勉強会の題材にしたことがありまして、
当時ちょうど別の勉強会で、鍋谷さんという方が主催されていた横浜ヘナチョコプログラミング勉強会というのがあって、
今はもうやられてないのかな、この勉強会。ただ、Googleったりするとこの勉強会の過去のログだとかが出てきて、
結構何回も、かなりの回数、この鍋谷さんらが考えられたプログラミング問題っていうのがウェブ上で出てきます。
これを彼らはどう書くっていうようなテーマで読んでいて、その勉強会の場で、例えば1時間とかのタイムボックスでその問題を解いて、
解けたコードを見せ合ったりしながら、あれこれ言い合うみたいな、そういう勉強会をやってたっていうので、それが非常に面白いなと思って、
名古屋のプログラミングコミュニティ、名古屋のPHP勉強会かな、同じようなことを何度かやっていたというのがあります。
これ、いわゆるプログラミング問題というか、アルゴリズム的な問題、今でいうとアットコーダーとかそういうのがあるんですけれども、
それと似たような系統の問題を解くっていうことなんですけれども、名古屋の勉強会のときには、
僕の趣味を若干反映させてまして、単にアルゴリズム的に問題を解くっていうだけではなくて、
ちょっとオブジェクト思考というか、問題をどういうふうに認識して、それをコードにどう落とし込むのかっていうところも、
ちょっと工夫してみようねっていうエッセンスを入れたりだとかしてたんですよ。
なので、より短時間で正解を導き出すコードを書くっていうよりは、他の人に説明可能というか、問題をこういうふうに私は捉えたんですみたいな、
そういうところを話せるような、そういう水準のコードを書きましょうっていうような感じでやったりしてました。
でも、タイムボックスの中で解かなきゃいけないので、やれることにも限界があるし、それが逆に面白かったりもしたんですけどね。
なので、時間内で解けなかったりっていうこともあるんですけど、そこで問題をどういうふうに捉えてっていうのも、
小さいアルゴリズム問題とはいえ、解く人によって見方が違ったり、解くアルゴリズム自体も、やっぱりいくつかの種類の解き方があるものなので、
なるほど、そっちの作戦でいったのかみたいなところが見えてきたりだとかしますし、
時には割と愚直に問題に現れてくるオブジェクトっていうか、そういうものをクラスにしていって、
それらの関係性をくっつけてロジックを書いていくことで問題が解けちゃうタイプのものもあれば、
そういうふうにするだけでは全く解けないようなものもあったりするんですよ。
っていうときに、ちょっと数学的な見方で、データ構造じゃないんですけれども、違った何か道具を用いるとすごくシンプルに問題が解けるっていうタイプのものもあったりして、
そういうやり方もあるのかっていうのに気づいたりだとかいう意味で、単にコードを書くっていうことだけではなくて、
どのように問題を理解し解釈してコードに落とし込むのか、そのコードに落とし込むところもいろいろなバリエーションがあるよねっていうところで、
これは非常に自分自身の普段の仕事ではなかなか出会わないタイプのコーディングスキルっていうのかな、問題を解くスキルっていうのを磨く場になったかなと思っていて、
この活動って結構面白いと思いますし、アットコーダーとかみたいな一人で黙々とやるだけではなくて、他の人と見せ合うっていうのがまた結構面白いので、
そういう勉強が今でもされているところはあると思うんですが、こういった活動はすごく有益なので広まるといいなというふうに思っています。
OSSの活用と再実装
これは結構やってましたっていうところが一つですね。
あと、今コードをたくさん書くっていう話をしてるんですけれども、コードを書くっていう意味だと、さっき話したようなサンプル問題というか、そういうのを解くっていうのも一つなんですけれども、
今でいうとインターネット上にいろんなOSSのソースコードがたくさんあって、実際に活用されているOSSがたくさんあるという中で、
そのOSSを例えばそれに貢献するっていうのも一ついいことなんですが、自分の学びになるんですけれども、
同じ目的のものを自分で再実装してみるとか、違う言語のライブラリを自分が普段使っている言語にポーティングしてみたりとか、
また別、逆方向ですね。自分が普段使っている何らかのライブラリを自分が普段使っていないプログラミング言語で書き直してみるとか、
これも結構コーディング力そのものだったり、言語に対する理解だったり、ライブラリの機能の理解だったり、
結構いくつかの軸でちゃんと深みを持った理解がないとできないことだったりするので、これも結構いいスキルを磨くというか、ソフトウェアエンジニアリング力っていうんですかね。
それを磨く一つの方法だなと思っています。
これ私の最近の例だと、現職だと今Rubyを使っているんですね。私もめちゃくちゃたくさん現場のエンジニアのように日々書くわけではなくて、
マネジメントのほうが中心なんですけれども、やっぱり自分も書く必要があるということで、Rubyを言ってマスターしてやらなきゃいけないなということで、
Rubyを勉強してやれるようになっているんですけれども、その過程でこのアプローチを試しましたというときに、
PHPの界隈で郡山さんという方が作られたBear Sundayというフレームワークがあって、
これいろいろないくつかのライブラリとフレームワークみたいなものでくっつけられた集合体なんですけれども、
その中にAOPの機能を実現しているRayAOPというライブラリがあるんですね。
これがサイズ的に難易度的にも良さそうだなと思って、こいつを選んでRubyで実装してみようということで取り組んだ時期がありました。
結構な割合でポーティングしたんですけれども、途中で心が折れて完成には至ってないです。
ちなみに心が折れた大きな理由というのは、このRayAOPというのはPHPの方だとアノテーション周りの機能が言語レベルでついていて、
その辺りを利用してインジェクションとかを指定しているような感じなんですよ。
その辺りがRubyだとないんですよね、言語レベルでは。
今、Ruby会議だとか、あの辺りではいかにRubyという言語の上に型を指定するようなアプローチを載せていくのかというので、
言語そのものにそういったアノテーション的な機能がないので、
ちょっと横からくっつけるようなアプローチでその辺りを保管しようという動きがここ何年かずっと取り組まれていて結構厚い議論だったりするんですけれども、
まだそういう状態なので、なかなかRayAOPで実現している機能を素直に実装するということができなかったんですよね。
なので無理やり、Rubyってメソッドの定義とかを全部ランタイムの中で読んでいくことができるので、
アンデファインドなメソッドがあったときにそれをアノテーションとみなすみたいな、
そういうハック的なやり方をされている方が何名か世の中に存在していらっしゃったので、
そのやり方をちょっとパクって、これをアノテーションとみなすみたいな感じで一定の動きは実現できたんですけれども、
なかなかここがハッキーな感じだったりするので、ちょっとこれをこのまま進めるのは難しいなというところで心が折れたというところでしたけれども、
それでも結構Rubyの凝った機能とかを使いこなさないとなかなかこのRayAOPの機能というのを実現できないものが多かったりしたので、
非常にトレーニングとしてはいい勉強になったなと思っていますので、
こんなやり方を皆さんもしてみるといいんじゃないのかなと思っています。
アプリケーション実装の重要性
それとは別に、これはよく語られる勉強方法なんですけれども、
小さいアプリケーションを実装してみるっていうやつですね。
これもよく例に出るのがToDoアプリとかだったりするんですけれども、
僕的にはこのToDoレベルのアプリっていうのはあんまり学びにならないなという、
それぐらいちょっと簡単すぎるかなというふうに思ってまして、
もうちょっと難易度があるレベルのアプリが皆さんの手元に題材としてあるといいなと思っていて、
ちょっと具体例で挙げるとなかなか難しいんですが、
僕は例えば過去に書籍を執筆してたことがあって、
その時に出版社の指定でマークダウンとちょっとカスタマイズしたような指定の形式で原稿を書いていくっていうような感じだったんですけれども、
例えばマークダウンでGitHubで管理しながらやってたんですが、
自分の進捗がどれくらい進んだのかっていうのがなかなか可視化されないとやる気を維持しづらかったので、
目標の文字数とそれに対して毎日どれくらい進んでるのかっていうのをGitHubのコミットから抽出して進捗を可視化するようなところを自分で作ったりとか、
あとはそれと同時にちょっと特殊な形式が入ってたので、
その形式も含めてマークダウンをコンパイルとは言わないけれどもレンダリングしてプレビューっていうんですかね、見える形にして、
進捗の可視化とは違うんだけれども、一定できたものがこんな感じなんだよっていうのが見えるような状態にして、
自分のやる気を保つみたいな、そういうアプリを作ってたことがあったんですけれども、
原稿を執筆するよりもアプリを作る方に何なら逃避しちゃうというぐらい、そっちの方が面白くなっちゃって作ってたぐらいのものをやったりもしてたんですけれども、
そういった自分の抱えてる課題を解決するような、でも簡単すぎないサイズのアプリっていうのを実装していくと、
それ自体が、いつも使ってるのとはちょっと違う道具だって、ライブラリだったりだとか、
言語の機能を公式ドキュメントっていうのを隅々まで見て探さないといけなかったりだとか、
もしくはマークダウンだったらマークダウンの一定の標準の形式みたいなのがあるので、
その辺をライブラリを使えるところと使えないところもあったりしたので、そこは自分で拡張して実装しなきゃいけないので、
その辺をやるときに一定の標準というのがどういうものなのかっていうのを、マークダウンだったらそんなに大きな標準ではないんだけれども、
たまに物によっては例えばRFCを読みに行かなきゃいけないとか、そういう問題もあったりしますよね。
中でもそういうサイズの問題を扱う小さめのアプリっていうのがあると、いくつかの軸でもって深みを持った理解がないと作れないってなってくるので、
それ自体作ることが結構大きな学びになったりするので、そういったサイズの問題っていうのをいくつかストックしとくっていうか、
これはちょうど良さそうだみたいなものをちゃんと取り組めるみたいなふうにしとくといいのかなという感じですね。
コードを読む力の鍛え方
という感じで、コードを書くっていうところでいくつかの例をお話ししましたが、やっぱりこのコードを書くっていうところがソフトウェアエンジニアのやっぱり大部分ではあって、
ここをどう深めていくのか、維持していくのか、もしくは長期間にわたって継続して学び続けられるのかっていうところが非常に重要なので、
ここのバリエーションだったり、自分自身のアプローチだったりだとかいうところをいくつかストックしたりしておくといいんじゃないのかなと思っています。
コードを書くっていうのはそこまでで、そこが非常に大事な話なんですけれども、一方で、これ最近Xで金城さんだったかながつぶやかれてた、
コードを読む方の力っていうのはどうやって鍛えたらいいんだみたいなことを言われていて、確かにここもコードを書くのと表裏一体的な感じもしますが、
とはいえ読む方は読む方で、やっぱりちょっと違ったスキルが必要なのかなと思っています。
先ほど触れた金城さんのツイートにも何人かの方がレスト化されてて面白いなと思って読んでましたけれども、
これ僕だったらっていうので言うと、僕自身、たくさんコードを読んできてると思ってまして、それは綺麗なコードばかりを読んでるっていうことはもう決してなくてですね、
どっちかっていうと現実味のある、そこそこのサイズの、なんなら綺麗じゃないというか、ドロッとしたような、そういうコードを相当たくさん読んできたかなと思っています。
で、ある種ちょっと僕はそういう辛いことが好きなタイプかもしれないので、皆さんはもう皆さんのこの許容範囲を超えて辛いことになっちゃうのかもしれないんですけれども、
でもやっぱりそのより好みせずにどんなコードでも読む、読んでいく、読んでいけるっていうことって、そのコードを読む力っていうのには直結すると思うんですよ。
僕がコードを読むとき、別に何かそんな特殊なことをしているわけではなくて、やっぱり何かこう一定時間をかけてじっくり読まないと理解できないものって当然あるんですよ。
でも最近だとRubyと格闘しているときに、Railsのスタートアップの処理どうなってんだっていうのを読んだりしてるんですけれども、これがなかなか難しいんですね。
聞いている方の中にはいろんな言語を使われている方で、結構もう肩がついててコードが読みやすくなっている世界の方々と、はたまたRubyの方ってやっぱりそういうのがないので、
今どのクラスのインスタンスが入っているのかとか、どのメソッドが入っているのかってなかなかパッとわからなかったりするんですよね。
その辺がRubyの良さとしてあったり、デメリットの方で出てきたりするんですけれども、そういう中でもコードを読んでいってどういうふうに動いているのかっていう理解していくっていうのが、
そのものを理解するにあたって非常に重要だと思っているので、大体何かに触れるときには必ずやることだったりするんですよね。
ひたすらコールスタックを追いかけていったりだとかしますし、何ならやっぱり1クラス、1メソッドずつ、このクラスはどういう役割で、このメソッドはどういう役割で、
どういう順番で呼ばれててとか、どういう依存関係になっててとか、これを書き出していって地道に構造を把握していくということをしないと、やっぱりわからないコードって普通にあります。
さっき挙げたレールズのやつなんかは非常にわかりづらいんですね、スタートアップのところが。
1回ラックのほうまで行ってまた帰ってきたりするんですけれども、どこがラックのチェーン呼ぶレスポンシビリティみたいなパターンで、
リクエストとレスポンスが包まれてたりするので、どこがどうなっているのかわかんないみたいなのがあるんですけれども、
そこも地道に紐解いていくとはなるほど、ここでこういう処理が挟まってるからこういうふうになるんだみたいなのが、やっぱりだんだん見えてくるんですよね。
そういうことの繰り返しがコードを読む力っていうところにつながっていくっていうものすごく単純で愚直な話なんですけれども、
それをやっぱり繰り返すだけなのかなというふうに思っています。なのでここはコードを読む方のスキルでいうと、
やっぱりここも簡単なものだけ読んでたら絶対にコードを読むスキルっていうのは身につかないし、
やっぱり一定の複雑度とか一定の大きさ、パッケージ一つだけとかだとやっぱり閉じた世界で目的がクリアだったりするので、
なんならコードを読まなくても最初からある程度処理が予測できて、その予測のもとに読んでいけるみたいなのがあると思うんですけれども、
そうではない世界のソースコードですよね。レール図みたいなのがやっぱりいいと思うんですけれども、
皆さんだったらどうだろう普段使われているフレームワークのソースコードとか、やっぱりこれをスタートアップからどんなところからコードが始まって、
処理が流れていくのか、この辺やっぱり一通り追いかけて地道に全部を理解していくみたいなことを一度やっておくと、
フレームワークって最近だと小さなフレームワークもありますけれども、やっぱり一定のサイズがあって結構いろんな役割のものが登場したりするので、
かつちょっとテクニカルな呼び出し方というか、いうことをされてたりすることもあるので、やっぱり読むのにそこそこの力量がいったりするんですよね。
そういうことをやっておくとコードを読むスキルっていうのが徐々に徐々に高まっていくというか、なんていうのかな、耐性がつくみたいなことかもしれないですよね。
ちょっと複雑でもびっくりしないというか、いうものかもしれませんよね。
コードの読み書きの重要性
それがコードを読む力とかいうことになるのかなという気がしています。
最近だとやっぱりIDEとか使うと、Rubyのコードとかでもどんどんコードジャンプして呼び出し元とかたどっていったりできるので、
すごくコードを読みやすい時代になってますよね。
昔はそんなものなかったので、グレップしたり定義をもとに自力で飛んでいって読むとか、
あとはよくわかんないときはプリントデバッグ的なものを仕込んで、動かしながらこういう順番なのかっていうのを理解したりしながらやってたんですけれども、
今はそこまでしなくても結構IDEだけで読んでいける幅っていうのが広がってるなと思うので、
そういう意味でもより複雑なコードでも読みやすい環境は整ってきてるなと思うんですよね。
そんな感じで地道にコードに向かい合って、書く方も読む方もやるといいんじゃないのかなと思っています。
ここまでソフトウェアエンジニア、プログラマーっていうのかな、スキルの一番重要なコードっていうものに対して書くことだとか読むことについて触れてきました。
とはいえソフトウェアエンジニアでも、それ以外のところからの学びっていうのもやっぱりあるので、多少触れておくと、
一つが本ですね。特に設計とか考え方とかいうところでいうと、本から得られる知識っていうのは依然として非常に多い世界かなと思っています。
なので、本だけじゃないですね。インターネット上のドキュメントとかも含めて、そういった書かれたものからいかに知識を吸収していくのかっていうところ。
そういった知識の吸収の仕方自体がスキルだったりもすると思うんですよね。そういうところも鍛えておくといいんじゃないのかなと思っていて。
この方面でいうと、二つの軸での知識の吸収の仕方というか学び方があるかなと思っています。
一つは、広く浅く本を、なら本を読むっていうやり方ですね。
これはこれで非常に有用で、世の中にこういう技術や考え方だったり原則だったりプラクティスだったりがあるっていうことを一旦頭に入れてインデックスしておくみたいな感じですよね。
この言われ方は本当に僕が言わなくても知ってる方が多いというか、世の中の学び方でよく言われることなので一般的だと思うんですけれども、
中身どういう技術なのかっていうところを完全に理解はしていなくても、どんな状況で使われる技術なんだなとか、
それぐらいの程度で、表面的にだけでもそういうものが存在してるっていうことが頭に入っているっていうことがまず大事なんですよね。
そうすると何かいざそういう状況に直面したときに、何か聞いたことあるあれがもしかしたら今使えるんじゃないかみたいな、それだけでも思い出すことができるものだったりするんですよ。
そうするとそのときに実際に本なり何かを引っ張り出してきて、その技術なりを深く調べて、それを使って問題を解くっていうことができればいいので、
まず最初はインデックスがあるっていうことが大事なんですよね。なので、広く浅くいろいろなものを触れながら、
脳内にインデックスを作るっていうのはちょっと難しい場合もあるので、全然今だったらブログでも自分のメモでも何でもいいので、
何か軽く残しておいて、いざというときに検索できるようにしておけば十分ですよね。なので、広く浅く情報収集するという軸が一つ。
それから二つ目の軸っていうのが、深く掘っていくっていう知識の吸収の仕方ですね。
この辺は毎回毎回深く情報を吸収するっていうのが必ずしも効率は良くないですし、あと狙った技術みたいなものを深く吸収したいと思っても、
やっぱりそのタイミングでは100%吸収できないとかってなることが多いので、時と場合によるような感じなんですよね。
本であれば、僕だったら最近だと杉本さんの書かれたデータモデリングでドメインを駆動するっていう本なんかは、
深く読むっていうようなアプローチをした本の一つなんですけれども、その本の中の一段落ずつというか、何なら1センテンスずつぐらいですね、
味わって噛みしめて、何言ってるのかを本当に丁寧に理解しながら読んでいくぐらいの、そういう勢いで本を読むみたいな感じですよね。
この深く読んで理解する、吸収するっていうのは。これをやるとどういう状態になるかっていうと、理想的にはですよ、
その著者杉本さんがどんなふうにこの機関システムだったりデータモデリングだったりを見てるのかっていう、
その人の視点だったり、マインドセットだったりだとか態度だとか、そういうものが自分の血肉になってるような状態になるんですね、理想的には。
それはなかなかそこまでいけるもんじゃないんですけれども。
その状態に関して、何ていうのかな、ちょっとした例えで言うと、これもまた本なんですけれども、無聞漢っていう仏教の本があってですね、
この本の一番最初に出てくるエピソードかな、エッシュっていう素晴らしい和尚さんから教えを置く話があるんですけれども、
そこにその師匠たちと自分が眉毛と眉毛を結び合って、同じ位置から同じものを見て同じ音を聞くぐらいの、
それぐらい全く同じ視点とかで物事を見ることができるっていう話があってですね。
その本に書いてある言葉で言うと、
ただ親しくエッシュにまみえるのみにあらず、すなわち歴代の祖師と手を取って共に生き、
美毛、これ眉毛のことを美毛って言うんですけど、美毛を相結んで、同一弦に見、同じ目で見、同一にに聞く、同じ耳で聞くことができるっていうふうに書いてあるんですね。
それを無文官と名付けたっていうふうにこの著者の人が言ってるんですよね。
無というものについて考え続けるとそういうことができるっていうことを言ってるんですけれども、
それぐらいの勢いで著者の考え方を吸収するっていうのが、深く読む時の理想状態なんですけれども、
なかなか理想状態に簡単にいつもたどり着けるわけじゃないんですよね。
1文ずつ読んだからといって必ずそうなるわけではなくて、それは何でかっていうと、
自分の側の経験だったり知識っていうのがやっぱり足りてないと同じように見ることができない。
いくら書いてあることをロジカルに理解できたとしても、自分自身の感覚だとかがその域に達しないっていうことがやっぱりあるので、
この深く読むっていうのはなかなかそういう面でも難しいですね。
ただ、これだと狙いを定めた本に対してはトライはしたほうがいいかなと思っています。
僕の過去の経験で言うと、エリック・エヴァンスのドメイクド設計もこういう読み方をした本なんですけれども、
日本語版が出た時にそういう読み方をしたんですね。トライしたんですね。
でもやっぱりその当時の僕では、本に書いてあることがわからんみたいなことがたくさんありました。
何度も読んだり、その時間を置いて自分自身の経験の蓄積っていうのが増えたり、いろいろな角度で物事を見て考えを深めてきたみたいなのが積み重なった結果、
もう一度読んでみると、なるほどこういうことを言っていたのかっていうのがようやくわかるだったりするんですよね。
そういう意味で、この深く読むっていうのは、一回それをやればいいっていう話でもないんですよね。
でも本を読んだり、情報にアプローチするときの2つの軸として、広く浅くっていうところと深くっていう、
この2つがあるっていうのは知っておいていただいたほうがいいかなと思いますし、
学びの加速
狙ったものに対しては深く読むっていうアプローチというかトライっていうのをしてみることをお勧めしたいと思います。
いろいろ語ったんですが、最初に学び方に関して視点を複数持つみたいな話をしました。
学びっていうのをただ単に数をこなせばいいっていうものでもないと言いますか、
どこかの段階からやっぱり効率よくっていうんですかね。
僕はこれを加速っていう表現をするのを好んでいるんですけれども、
例えばソフトウェアのプログラミング言語にしましょうか。
これをどんどんどんどん新しい言語を横並びに使える言語を増やしていけば、
ソフトウェアエンジニアとしてのスキルが上がっていくかというと、
それは上がる部分も当然あるんですけれども、
道具が横に増えていくだけであって、
加速度的にソフトウェアエンジニアとしてのスキルっていうか、
物事を見る目っていうのが養われていくっていうのとはちょっと違うと思うんですよね。
なのでその使えるテクニック自体を横に増やすっていうのはやっぱり、
どこかで限界が来るというか、時間的な物量が足りなくなってくるので、
どうしたら一つの同じ時間をかけて学ぶことに対して、
よりたくさんの学び、より濃い学びが得られるのかっていうことを、
どこかからは考えたほうがいいと思っています。
それがどういうことなのかっていうと、どういうふうにするとできるのかっていうと、
これは僕が科学的に検証したところではないんですけれども、
僕自身の経験で言うと、例えばエリック・エバンスのドメイン駆動設計で言うと、
最初に読んだ時も自分の経験とすごくこれこれって思うようなことが書かれていたりとかいう部分があったりしたんですけれども、
自分の経験と学ぶ対象のものっていうのをいかに紐づけられるかっていうことが大事なのかなと思っています。
それはある本をオブジェクト思考のロバート・C・マーチンが書いたソリッドの原則の本とかがあって、
それを読んだ後に実際の仕事でそれを使ってみる。
そうするとソリッドの原則の知識を現場の問題に紐づけて、どう適用するのかっていうことを捉えして、
それが一つの知識になっていきますよね。
同じように逆方向に、現場でいろいろな問題、自分が何らかのリファクタリングを自分の考えでやったとか、
すごい複雑な、どうにも解きほぐしがたいようなソースコードの構造みたいなのがあって、
一つの解を仮説というのかな、持ってきれいにしたんだけど、なんかスッキリしなかったみたいな経験があって、
そういう経験をもとにソリッドの原則の本を読むと、
その本を読んでる最中に、あの時の問題はこういう見方ができるんだとか、
この方法適用したらちょっと違うアプローチで解きほぐすことができたんだなとか、
そういうふうに本を読んでる最中に自分自身の知識とか過去の経験っていうのが、
なんていうのかな、すごく紐づいていくというか、
頭の中で電気が走るみたいにピッピッピッって結びついていく時があるんですよね。
そういうことが全然起こらない状態で本を読んだりしてると、
何かその本を読む時間に対する学びの密度、濃度っていうのが、
やっぱり客観的にはあまり高くないと思うんですよね。
無駄とは言いません。
それもその頭の中に辞書を作る、インデックスを作るっていう意味ではすごく大事なことなんだけど、
その状態だけを続けていても、その学びの加速にはならないので、
現実の問題に一定取り組み、その現実の問題とどう学んでる対象、
ドメイン駆動設計なのか、ソフトウェアのプラクティスみたいな話なのか、
そういうところがどう結びつくのかっていうのを常に考えながら、
学びの加速
これは後で振り返ったりしながらだったりするかもしれないし、
問題を解いてる最中に手元に置いてある本を見ながら考えてみるとか、
その現場では自由にそういう自分の設計のアイディアを適用できないかもしれないんだけれども、
考えてみることは自由ですよね。
考えてみるっていうことをやるとか、今回のプロジェクトでは使えなかったけれども、
こういうやり方は可能だったかもしれないっていうふうに、
自分なりにブログに書いてみるとか、メモを書いてみるとか、
そういうことができるわけですよね。
そういうふうに現実の問題と書籍だったり、
そういうところの知識っていうののひも付きを常に作るっていうことをしていくと、
これがどんどんどんどん積み重なって、
現実の問題、現実の経験、自分の知識っていうののひも付きの数っていうのがどんどん増えるわけですよ。
そうすると、そういった状態になった後に本を読んだり、
もしくは現実でなんか新しい問題にぶち当たったみたいな時に、
思いつくこれはあのパターンでいけるみたいなところの引き出しの数っていうのが、
どんどんどんどん増えてきて、それでもってまた問題を解いてだったり、
本を読んだ時の解釈をしたりとかいうところの学びっていうのが、
過去の知識とのひも付きの数っていうのが、
どんどんやっぱり指数関数的に増えていく感じになるんですよね。
こういうのがその学びが加速している状態だと僕は思っているので、
なんかこうやっぱり単にインプットだけするとか、
それをそのままアウトプットなんていうのかな、
登壇するとかいうことではなくて、現実の問題、
自分自身が取り組んだ問題といかにひも付けて、
密度の高い知識、経験として、
なんか自分の中に体系とまでは言わないけれども、
蓄積していくかっていうところが非常に大事だと思っているので、
ここまで来るとプログラマーの学びっていう枠を超えてるんだけれども、
そういうところまで意識してコードの書き方とか読み方とかいうところも
やっていくといいんじゃないのかなと思っています。
コードを書くとコードを読むみたいな、
独学系の話をかなりたくさんしてきたんですが、
最初に言った2つ目の話、
師匠を見つけるみたいなところも少し触れておきたいと思います。
まず私の経験からお話しすると、
いい師匠に結構出会えてきた方だなと思ってますし、
特に2015年、もうちょっと前あたりかな、
すごく濃密な数年間を過ごしたことがあって、
その時に活動で言うとPHPメンターズっていうバーチャルなグループっていうんですかね、
いうのをアイテマンさん、久保さんと一緒に結成して、
ある種の師匠活動っていうのかな、
カンファレンスで登壇したりだとか、優勝のトレーニングを企業向けに提供したりだとか、
いうことをやっていた時期があって、
その時期に私で言うと、ものすごくソフトウェア設計とか、
その周辺の知識、いろいろなことに対して、
濃密な学びを得たかなと思っていて、
一つ大事だった、二つあるな。
一つは久保さんっていう方が、なんていうのかな、
僕の師匠みたいな感じでもあるし、兄弟子っていうか、
すごく近い位置にいるお兄さん的な感じだったんですよね。
同時にその頃、杉本さんだとか渡辺光三さんだとかの勉強会にも参加するようになって、
そこの方々は完全にもう師匠という感じではあるんですけれども、
そういった師匠人と僕らは毎日同じ仕事現場で顔を合わすような間柄では当然ないというか、
月1回の勉強会でちょっとお話しするぐらいの距離感だったんですよね。
なのでどちらかというと、僕は久保さんとものすごく多い時間、会話をしていて、
当時PHPメンターズをやっていたときは、毎週金曜日の夜に定例ミーティングとショーをして、
どうだろうな、夜の10時ぐらいから3、4時間、下手すると夜が明けるぐらい、
ソフトウェア設計について延々と語り合うというか、最初の1年ぐらいは僕は久保さんの話を一方的に聞くだけぐらいの感じというか、
それぐらいの知識量に差があったんですよ。
でもひたすら久保さんは彼の持っている知識というか、語りたいことみたいなのを僕にひたすら注いでくれたという時期があって、
そういう時期を過ごしてたんですよね。
なので、兄弟子的な方だったり師匠的な方々がいる環境にまず入れるかどうかっていうのが非常に重要なのかなと思っています。
その入れるかどうかっていうところですよね。
入った後はもうひたすらその人たちとどうにかこうにかチャレンジしていくってことなんですけれども、
まず入るっていうところがなかなかないのかなと思うんですよね。
会社の中とかでそういう関係性の方が見つかればいいんだけれども、そういう方々ばかりではないでしょうし、
やっぱり会社みたいな組織から外れたところでこの人はみたいな人を見つけて師匠にしていくということが一定必要なんだと思うんですよね。
実はこの辺の話もアプレンティスシップパターンに出てきたりするんですけれども。
僕はたまたま工房さんと出会えたみたいなところがあったんですが、
この人はみたいな人をインターネット上だったり、カンファレンスに行って登壇を聞いたりとかで思うことってあると思うんですよ。
ただそこからの一歩の踏み出しっていうのが普通は難しいと思うんですが、
ただ意外とやってみてもいいと思うんですよね。
ちょっとコーチしてくださいっていうか、師匠になってくださいでもいいんですけど。
いうふうにちょっと話しかけてみるだったり、昔だったらメールを送るみたいな感じなんですけども。
そういうことをやってみると。
ただ多分ちょっと大げさじゃないですか、師匠になってもらうみたいなところって。
大げさっていうのは何かっていうと、同時に何人もの人に師匠になってもらうのってちょっと無理があると言いますか。
別に師匠同士が対立してる世界でもないので、ロジカルには別にそれでもいいんだけど、
やっぱり師匠との関係の中で学びを得るには、一定一人の人に別途するっていうか、かけるというかいうことが必要と言いますか。
それって客観的に言うと、一人の人と多くの時間を共有するというんですかね。
っていうことをしないと学び取れないものっていうのが、その師匠関係の中で得られるものだと思うんですよ。
なので、一定師匠側というよりも弟子になる側に覚悟が必要なんですよね。この人にかけてみようっていう。
でも何かそれに値する方っていうのは、やっぱり普通に多くいらっしゃると思うので。
だし、そういう方々、一定の経験をされてきて活躍されてる方々って、そのご自分たちが持っている知見というか経験だとか、そういうのを活かしたいなというか還元したいなって思ってるものだったりするんですよね。
なので、そういう意味でも声をかけること自体は全然失礼じゃないというか、むしろ喜んでくれることでもあると思うので。
どちらかというと、その弟子になる側の覚悟っていうのが先に必要なところが注意というか、そこだけは一定の考えを先に持っておく必要はあるかなと思っていますが。
ちなみに僕もそういった師匠的な活動は昔してましたし、PHPメンターズとして。
今でももちろんそういったお声掛けをいただければ、100人来たら無理かもしれませんけれども、そういった活動もしたいなと思っているので、興味がある方はお声掛けください。
そういうふうに師匠を見つけて声をかけると。その師匠にベッドする。かけると。自分の時間をかけると。
なった後は、もちろん師匠がどんなふうに接してくれるかっていうのはもう千差万別なんでしょうけれども、
まず一定の時間をきちんと師匠との活動のためにコミットする的なことは必要でしょうし、
どういう学び方を師匠から得られるかっていうところで言うと、やっぱり自分一人では難しい、自分の限界を突破させてくれるみたいなところが、
その師匠と弟子の関係の中では結構大きいのかなと僕的には思っています。
これはやっぱり独学ではなかなか打ち破りづらい。もちろん自分だけでやれるものもありますけれども、
師匠がついてくれることでそこが加速する側面が大きいかなと思っています。
なので、師匠にはそういうハードな側面というか、自分自身の足りてないところを気づかせてくれるような指導というか、
そういうのをきちんとくれくれと言ってくれるものじゃないんだけれども、師匠との関係性の中できちんとそういうところに自分が向き合い乗り越えていく。
これって時間もかかることだと思うんですけれども、ということができるような活動として使うといいのかなと思っています。
なので、これは結構信頼関係も重要だし、なかなか気軽にできるもんじゃないんですけれども、
人生で一度ぐらいはそういう師匠を見つけて、そういう活動をしてみるっていうのはいいんじゃないのかなと思っているので、
師匠との関係
ぜひ聞いてる方、一人でもそういう一歩を踏み出していただけるといいんじゃないのかなと思っています。
というわけで、大きく独学でどういうふうに学んでいくか、特にその学びを加速させるみたいなところとかをお話しして、
加えて師匠を見つけるみたいなお話をしました。
こういうことをしていくことで、最初にお話しした、最終的には自分自身が持ってる視点っていうか、
物事をどう捉えるのかっていう引き出しの数が増えたりだとか、
もともと持ってた引き出しがレベルアップするっていうことにつながっていくのかなと思っています。
話の途中でも出したんですけれども、書籍でいうとアプレンティスシップパターンっていうのがやっぱりこの辺の話でも引き続きお勧めでして、
そのカップを空にする話は当然なんですけれども、さっき話したような自分の限界に挑戦するみたいなところもパターンとして実は書かれていて、
無知に向き合うとか、無知をさらけ出すみたいなパターンがあるんですよね。
そういうことが書いてあったり、あとはやっぱり時間がかかるんだよねっていうのが長い道のりみたいなパターンで書かれていたりするんですよ。
結構やっぱりこの本、本質を捉えていて、僕は何度も読み返してる本だし、改めて今、さっきも読んだんですけれども、
いいこと書いてあるなと思える本なので、なかなかこれ手に入りづらい本ではあるんですけれども、
その学びを加速させていきたいと思ってる方は一度手に取っていただけるといいんじゃないのかなと思っています。
というわけで、学び、ソフトウェアエンジニア、プログラマーとしての学び方みたいなことについて、あれこれと私の経験を交えて語ってきました。
アプレンティスシップの重要性
なんか話したいことがいっぱいあって、途中ちょっと喉が枯れ気味になっちゃうぐらいだったんですけれども、
特にその後半でお話ししたその師匠を見つけるみたいなところ、
これ前回のZoeさんとのお話の時にもちょっと触れた運要素が強いというか、
やっぱり出会いの問題なので、なかなかこの人はみたいな人を見つけられないみたいなこともあるかもしれないんですが、
とはいえプログラミングのカンファレンスとか行くと、やっぱりそれなりの方々と出会えたり、
もしくは出会った方から紹介してもらったりとかね、そういう形っていうのも意外とあるかなと思っていますので、
ぜひそういう一歩を踏み出して見ていただきたいなとは思っています。
さて、この番組では感想や質問、お悩み相談をお待ちしております。
エンジニアリングの現場で遭遇するあらゆるトピックについて、番組詳細欄にあるお便りフォームよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
お相手は後藤秀典でした。また次回をお楽しみに。
