道産子エンジニア

あなたは何事にも頭角をあらわしたことがない。

Apprenticeship Patternsを読んだ

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

アプレンティスシップ・パターン ―徒弟制度に学ぶ熟練技術者の技と心得 (THEORY/IN/PRACTICE)

  • 作者: Dave H. Hoover,Adewale Oshineye,柴田芳樹
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2010/07/08
  • メディア: 単行本(ソフトカバー)
  • 購入: 12人 クリック: 221回
  • この商品を含むブログ (53件) を見る

本の話をする前に、少し小話を。

前回の記事で金沢に行ったとき、夜の飲み会で盛り上がったときになんの話だったかは忘れたけど、同期がこの本を引き合いに出したのを覚えている。
(俺はよく飲み会で聞いた話を忘れないようにメモしておくのだ。)
この本の存在自体は新卒一年目の時点で知っていた。それもまた同期が話していたものだった。ただ、当時の自分には読むべきものが多すぎてすっかり忘れた今になってようやく読もうかなと思えたのだ。あとアプレンティスシップという制度の意味を知らなかったのだけど、イギリスでは今でも「Modern Apprenticeships」という形で存在しているのだそうだ。

アプレンティスシップとは徒弟、見習いのことをさす。ギルドがあった時代に生まれた制度らしく、見習いが職人となるまで熟達者の下について技能を学ぶ(いや真似ぶ)ことをさす。最近、THE GUILDという会社で働き始めた友人もいて、妙に心に残ったのだった。

昨年度から採用関連にいつもより多めに協力していることもあり、恥ずかしながらちゃんとトレーナーをしたことがない自分は、弟子を持つ者のことについて書いてあるのではないかと勘違いして本を読み始めたのだった。しかしこの本は自分が「教える側」と考えている人が読む本ではないし、また「教わる側」と考えている人が読む本でもなかった。多くの人が勘違いしているようなのだが、これは駆け出しプログラマーとか新卒一年目に向けて書かれた本でもない。 これはプログラマーに限らず、職人として生きていくための心構えについて書いてある本なのだ。

そして、このタイミングで読んで本当によかったと思えた。これはソフトウェア開発を業務である程度やったことがあり、プログラミングそのものの難しさや一人のエンジニアとして働く上で悩んだことがある人でないと刺さらないと思う。なので、新卒一年目のときに読んでも意味がなかったと思う。(もちろん、それまでに経験したことのある人であれば有用だと思う)

本を読んで、改めて自分の行動、職人気質について問いただしてみると学ぶべきことばかりだった。

昨年10月から異動し、初めて「チーム開発」をまともに経験した自分にとって、この本のパターンが点と点を線で繋いでくれるような感覚を持った。 「教える側としての勉強でもしてみようか?」などと考えていた自分が恥ずかしくなった。自分は職人として何一つ満足にできていないではないかと反省した。

俺はまたLv.1から、ゼロから、学びなおさないといけないのだと気付かされた。この先も続く、長い職人としての道のりを危うく踏み外しかねなかったのだ。 この本に書いてある具体的な問題はそのまま自分の具体的な問題であり、あげられている具体的な解決策は全てが正しくはないがやはり今の自分にとって具体的かつ有効な解決策ばかりだった。

良い本は年を経て輝きを増す。これは原著が9年前で、今はより光を放っている本だと思う。

見習い期間はあなたのキャリアにおける、ある時期にすぎません。あなたの学習の機会を最大限にする為に、収入をすぐに最大限にするという願望を先に伸ばす時期です。

これはすごくいい言葉だと思った。

専門性は、私たちがあゆむ長い道のりの副産物ですが、目的地ではありません。旅をしながら、職人は数知れない技術と領域に取り組みます。~~~マラソンの走者は、強い脚力になるようにトレーニングしているのではなく、走るトレーニングをしているのです。

(その副産物として強い脚力が手に入る)

自分のアプレンティスとしての長い道のりをここから始めないといけないなと改めて思う一冊だった。

フィードバックの種類について学んだ

フィードバックループを構築するというパターンの節で学んだ。普段フィードバックをするとき、自分がどんなことに気をつけているか思い返してみた。たいてい、

  • 否定から始めない
  • 論点を絞る
  • 質問は閉じた質問方法で答えを明確にする

といった心理的アプローチについてのことが多い気がする。フィードバックそのものの種類についてあまり考えたことがなかった。本にあったのは、 「ある事柄をもっと増やしなさい」というニュアンスを持つフィードバックを強化フィードバックと呼び、「ある事柄をもっと少なくしなさい」というニュアンスを持つフィードバックをバランスフィードバックということだった。確かにフィードバックを大きく大別すると事の程度を増減させるものが多いと思う。これは今後意識しながら色々なフィードバックをしたりされたりしたいなを思った。

そして何より、いいフィードバックというのは「このあとすぐに何か行動を起こせる」ものだということだ。自分がフィードバックをもらうときも次に何をすべきかわかるまでは、ちゃんと聞き直した方がいいだろうなと考え始めた。

本を読んでやると決めたこと

俺は最近、自分がまだまだ技術を発揮して開発できていると思えてない。それなりのソフトウェアしか書けていないのだろうなと思う。 本書のパターンは多くの人が実践し、試行錯誤を重ねながら滲み生まれる結晶の一つだ。パターンには学ぶべき教訓がある。 技術を発揮していくためにも今回学んだことを生かして、より良い技術を身につけていきたい。

  • 自分が仕事について実際にわかっていないことをいくつか書き出し、他の人が見れる状況にする(OKRの文脈が良さそう)
  • webを組めるようになりたいので、熟達者を見つけつつゼロから学ぶ
  • ゼロから学ぶために、自分が所属している、関わりのあるチームを全部列挙して、レベル付けをして、その中の上から順に参加して活動する
  • Androidとwebのともに、自分が模倣したい良き指導者を見つける
  • 新しいプログラミング言語を覚えるために使う自分なりの型を作る。(まずはkotlin)アプリまたはサンプルを作成し、他の言語に置き換えれる準備しておく
  • データ構造やアルゴリズムについて書いてある本を手に入れ、上の型に追加しつつ勉強する。競プロとか始める(二分探索とかから始めたい)
  • 新卒研修やメンターができたときのためのペアプログラミングの準備をする、自分が先輩とペアプログラミングする。いろんな人とペアプログラミングしてみる
  • 綺麗なコードをかくために読むべき本を調べ、聞き、リストを公開する。読んでいる間に引用された本はリストの上に移動、下の本は読まない
  • 調べた知識を使うだけの「偶発的プログラミング」をしてないか徹底チェックする
  • 最近記事を書いたいくつかの技術系記事で登場したもののの設計理由について深く調べる

筋トレの文脈で前に書いたのは「誰にも言わずに決めてやりとげるのは難しい」なのだけど、習慣ではなく仕事や技術についてそれをやっていては周りの人に伝わらないので公開してやっていく。 とはいえうざい広め方はしないようにしたい。


自分の暗黙知を伝えていかないと意味がないというストラディバリウスの例をあげた最後の話は、儚くも恐ろしいものだった。職人としてこれから生きていくには、自分自信を説明するためにもっと努力しないといけないなということだ。自分はどんな技術を持って、それをどんな風に使って、どんないいことがあるのか。広くわかりやすくしておかないと、どんなに才能があってもそこで終わってしまう。 仕事やそれ以外でも意識していかないとすぐ内に秘めてしまうものだと思う。そうすると誰からも批判されないから。でもそうじゃない!って思えるようになるのがこの本のいいところだと思う。

そしてほとんどのプログラマは自分が平均以上だと思っているかつ実際は平均以下であるという締めくくり方はすごく好きだった。これは成功しているソフトウェア開発が少ないことが証明しているが、この本を読んだものとして、謙虚に、自分がいつもアプレンティスであるという気持ちを忘れないための戒律であるのだと俺は感じた。

読書所要時間:約4時間
おすすめ度:★★★★★