「自分はジェネラリストがいいのかもしれない」という気づき
kyon_mm氏：（スライドを示して）「どうしよう」と思った時に、「ちょっと考え直そう、どういうふうに考えたらいいかな」と思いました。その時に「スペシャリストとジェネラリストがいるな」みたいなことをぼやっと思いました。「スペシャリストは、特定の領域にメチャクチャ特化している達人で、その分野なら任せろという感じで、ジェネラリストは、いろいろな領域ができる万能な感じでだいたいそつなくこなします」という感じだなと思いました。
「自分は、もしかしたらスペシャリストではなくて、ジェネラリストがいいのかもしれないな」と思うようになりました。というのも、プログラミングの領域ではぜんぜん勝てない、追いつかないけれど、彼らももちろん苦手な部分はあったんですよね。仮に彼らが作るプログラムの品質が良くない時に、うまくサポートする仕事が当時の会社ではあまり足りていなかったので、ソフトウェアテストをやってみれば、いいかもしれないとなりました。
最初の頃、ソフトウェアテストはただ単純にテストケースとか考えていて、テストをやるというぐらいしかイメージがありませんでしたが、プログラミングスキルがある上で、ソフトウェアテストをやれば、もっと効率の良いソフトウェアテストを作れる気がするし、もっと効率の良い品質、担保の仕方ができると思うし、もっと解像度の高い情報で、品質の高さや品質の弱いところを説明できる気がすると（思いました）。
こういった感じで、いろいろな領域をつなげていくといいのかもしれないと思い、当時はソフトウェアテストからやってみようとなったのですが、方向性としてジェネラリストをやっていくといいかもしれないなと思いました。
さまざまな分野における理解力は武器になる
最初は現場でがんばる感じでしたが、ちょっとずつやっていくうちに自分の中で、世の中のスペシャリストたちをつなげることが、実は仕事になるんじゃないかなと気づきました。
スクフェス（Scrum Fest）やRSGT（Reginal Scrum Gathering Tokyo）を聞いていて、みなさんがどう思うかはわかりませんが、その分野の賢い人の話の理解が、まるで追いつかない時があるんですよね。もちろん賢い人は、私たちにわかりやすくしゃべってくれて、雰囲気としてわかったつもりになることはできるのですが、それをいろいろな分野でできる人はあまりいません。
スペシャリストの人たちは、自分の分野を誰かにわかりやすく説明することはできるのですが、多数の分野で、それがつながったり、整理されたりは意外とされていない気がしました。自分の職場ですら小さな部分がこうだったので、仕事やソフトウェア開発という大きな文脈で言うと、そういうところがメチャクチャあるんじゃない？ と気づいて、なるほどとなりました。
すべての分野のトップレベルの人たちの話を理解すれば、メチャクチャ武器になるのでは？ と気づいて、トップレベルになることは諦めて、この方針をメチャクチャやろうと思いました。
モチベーションを加速させた「脱専門家指向」
（スライドを示して）当時、自分のモチベーションをすごく加速させてくれたのが、伊藤穰一さんのブログでした。MITメディアラボに着任した時のことを「むしろ脱専門家指向」だと書いていたんです。
単純に物事をつなげていくのは、学際的、学際分野とよく言われるのですが、なにか足していってこういうものがあるよねではなくて、（脱専門的は）そもそも専門性をいったん引いてみて、なにか新しい分野をつくる感じです。
この時、伊藤穰一さんか別の方の説明のブログか論文かで言われていたのが、義手や義足をすごく発展させようと思った時に、分断が起きているということでした。医療系の人と、機械工学の人と、なんとかの人と、なんとかの人が全部分断されていて、知識がバラバラになっている。そこでメチャクチャ優れた義手を作ろうと思った時に、これを全部扱える人として専門家集団が必要になってきますが、そういった分野として学ぶことがかなり難しいということです。
だから、これからは脱専門的にいかないと、社会を変えていくことが難しいんだという話をしていて、なるほどなと思いました。なので、単純につなげるだけではなくて、脱専門的ななにかを見つけられるようになりたいと思ったのも、この時の自分のモチベーションとしてすごく高かったです。
80点を取るのは100点に比べるとずっと簡単
パレートの法則は、知っている人が多いという意味でみなさんご存じだと思います。Wikipediaから引用すると、パレートの法則はイタリアの経済学者ヴィルフレド・パレートが発見したべき乗則で、経済においてうんぬんかんぬんとあります。
よくあるのは、100という売上があった時に、その100のうちの80ぐらいの売上は、たった20の施策や製品から生まれているというものです。80のものは、20でできているとよく言われています。メチャクチャ儲けているのは、前者で言う2割の集団で、この集団が8割ぐらいを儲けているよねとよく言われます。
これは学習においてもあるんじゃないかなと思います。みなさんも学生時代にやってきたと思いますが、テスト勉強をしている時に、100点満点を取るのはめっちゃ難しいけれど、80点を取るのは、それほど難しくなくて、100点を取るのに比べたらずっと短い時間でできます。
プログラムを書いていても、バグをゼロにするのはメチャクチャ難しいけれど、だいたい動いて、だいたいバグがない状態までにするのは、そんなに時間がかかりません。そこからバグをゼロにするまでが、やたら時間がかかるなとプログラムを書いていて思っていました。ソフトウェアテストもバグの収束曲線で、やはりあるんですよね。なので、これは勉強でもそうなんじゃないかなって思ったんです。
スペシャリストがある種のスキルにおいて100点を取っているのであれば、自分は20ぐらいの時間で、80点を5つの分野で取っていくという戦略を取っていけば、いろいろな分野を効率良く勉強していくことができそうだと。80点ぐらい取れたら、だいたいトップの人たちが言っていることが理解ができそうだなと思いました。
重要なのはやり過ぎないことで、ROIのいいところで止める覚悟が大事だということです。好きなものはやっちゃいますが、仕事としてやるとなると、そういった覚悟は必要だなと思ったんですよね。
書籍や論文には先人の知見・経験が詰め込まれている
この時に何を参考にするかというと、書籍や論文です。昔から、書籍や論文はメチャクチャ偉大だなと思っていました。
特に技術書で良書と言われているものには傾向があって、著者が「ここ3年間ぐらいで、俺こういうことを経験してきて、こんなふうに見えてるんだぜ」みたいな経験が詰まっています。
アンクル・ボブの『Cleanシリーズ』は別かもしれませんが、提言されている手法や、設計の考え方や、ツールなど、自分が抱えてきた課題と、そこに対するソリューションと、それを実践することでこんな課題があって、それはこういうふうにつなげられるんだよねという、その人の3年間ぐらいの知見がメチャクチャたまっているなと思います。
「1冊読んで実践すれば3年はショートカットできて、10冊読めば30年ショートカットできるじゃん、これはもう読むしかないじゃん」と思ったんですよね。
僕は本を書いている人より才能がないので、下手したら3年どころじゃないわけで、自分でやったら6年とか7年とかかかるかもしれないものを、自分より賢い人たちが3年かけてやって、それを1冊にまとめてくれている。こんなショートカットできる術があるなら、読むしかない、やるしかないとガンガン読んでいこうと思いました。
書籍を読んでひたすら脳内シミュレーションを繰り返す
でも、読んでも実践できないことのほうが多かったし、今でもできません。なので、基本は読んでは脳内シミュレーションをひたすら繰り返す。読んでいる時から、どうやったらこれを実践できるんだろう？ とか、これをやるとどういうつまずきがありそうかな？ とかシミュレーションをします。また、この偉大な書籍があっても、世の中の人たちが実行していない、なんでそうなるんだ？ こんなにわかりやすく書かれているのになんで実践できないんだろう？ そのハードルを僕はどうやって越えたらいいんだろう？ とメチャクチャ考えるようにしていました。
1冊読んで、「それはこうやってやるといいんですよ。でも、そういうやり方はよくないんですよね。たぶん、こういうふうにつまずいちゃうんで」と、スラスラ言えるようになるまで脳内シミュレーションをひたすら繰り返します。
それを実践しながら、1年間で書籍はだいたい40冊以上、論文は年間50本以上読もうと思っています。ここ数年は、特に論文のほうをやっています。そうすると、だいたい1年間で100年以上ショートカットできます。1冊を3年と捉えれば、40冊読めば1年で120年ぐらいショートカットできて、私はざっくり10年間やってきたので、1200年ぐらいショートカットしてきたと思うと、「お、強い気がする」みたいな感じになってきます。
技術書の読み方
もう少し技術書の読み方をお話しすると、基本的に1周目はさらっと3日以内で読むようにしています。脳内に、この本のこのへんにこういったことが書いてある、こことここのひも付けはこういうふうに書かれているという流れを頭の中にインストールします。
あとは著者がどういう書きっぷりをしがちなのか、見出しにはこういうことを書きがちとか、大事なことは章の真ん中ぐらいに書くのか、まとめとしてきちんと書くのかとか、まとめが実はまとめになっていなくて、2セクション前ぐらいにメチャクチャ大事なことがまとまっていたりするのかとか、そういう傾向を知るのを最初にやります。
何日もかけて読んでいると、前に読んでいたところはなんだっけ？ って忘れちゃうんですよ。なんとなくでもいいから読まないと、頭からどんどん抜け落ちることがわかったので、斜め読みでもいいから、短期間でいったん通し読みをします。1周目はとにかく早く読むことをやりました。
2周目はゆっくりと精読します。ここで脳内シミュレーションをしていく読み方を、基本的にどの書籍でもやるようにしています。もちろん好きな書籍は3回、4回、5回と読んだりするし、何冊も買っちゃったりします。
読むだけではなく、学んだことはアウトプットする
（スライドを示して）学んだことは、アウトプットしましょう。読むだけではなく、アウトプットしなければいけません。ブログに投稿したり、プレゼンしたり、仕事にしたりします。ここでは、脳内シミュレーションしたことをいきなりやるのではなく、実際にアウトプットするものにおいて、どういったアウトプットの仕方がいいのかを考えます。
ある種の仮説を立てて、こういった出し方が良さそうと考えて、シミュレーションして、こういった指摘が来そうとか、これは別に無視していいけれどこれはきちんと受け入れたほうが良さそうと思ったら、やり方を直して、もう1回シミュレーションをして、やり方を直して、実際にやってみます。それでフィードバックをもらって、次のやり方につなげるというのをやっています。
これにすごく時間をかけるかどうかは、やりたいこと次第です。1日、2日、2週間かけてやるのか、30分ぐらい頭の中で「うーん」と考えてやるのかは、その量や、自分にどれくらい専門性があるかによって違うと思うのですが、とにかくやります。
（次回へつづく）
