中学生でLinuxカーネルのバグフィックス！ 若き天才エンジニア矢倉大夢に爆速成長術を学ぶ

──矢倉さんがプログラミングを始めたのは中学1年生のころだったとか。

矢倉　「なんとなく面白そうだな」と思って中学校のパソコン部に入部したのが、プログラミングを始めたきっかけです。入部して、すぐにのめり込みました。

パソコン部はプログラミングの競技会である「日本情報オリンピック」に出場して勝ち進むことを目標としていたので、当時は競技プログラミングの勉強をたくさんしていましたね。

──具体的には、どんな勉強をしていましたか？

矢倉　競技プログラミングの過去問を解いていることが多かったです。たとえば、「AIZU ONLINE JUDGE」という会津大学が運営するサービス。色々な問題が数多く掲載されていたので、順に解いていました。

──毎日何時間くらいプログラミングを？

矢倉　どれくらいやっていたかなあ……。だいたい毎日15～16時くらいに学校の授業が終わって、そこから部活が18時まであるので、まず2～3時間。それから家に帰ってご飯を食べてお風呂に入って、21時くらいから深夜1時とかまでやっていたので、プラス4時間。

ときには、家に帰ってすぐ寝て、夜中の1時に起きてそこからプログラミングを朝までやることもありましたね（笑）。だから、トータルで1日6～7時間くらいはやっていました。

もしかしたら、学校の授業よりもプログラミングをやっている時間の方が長かったかもしれません（笑）。

──6～7時間！ とんでもない学習量ですね。それだけ集中してプログラミングを続けられたのは、なぜでしょうか？

矢倉　競技プログラミングから学習をスタートしたからだと思います。だいたい1時間あったら1問解けるので、小刻みに達成感を味わえて続けやすかったのかなと。

もし当時の自分がサービス開発をしながら学習していたら、完成までにとても時間がかかるので途中で心が折れていたかもしれません。

──“小刻みに達成感を”というのは、プログラミング初心者にとっては重要かもしれませんね！ AIZU ONLINE JUDGE以外には、どういったサイトの問題を解いていましたか？

矢倉　海外のサイトに掲載されている問題をよく解いていました。コンテスト形式のほうがモチベーションが上がるということもあって、メインで使っていたのはTopcoderとCodeforcesという2つのサイト。時々、練習として常時開設型のPKU JudgeOnlineや、UVa Online Judgeも使っていました。

達成できる目標を細かく設定し
モチベーションアップ！

プログラミングの課題解決スキルを上げるには、“質問上手”になるべし

──新しい言語やフレームワークを習得するときは、基本的にWebの情報から手を付けていますか？

矢倉　そうですね。まずは公式チュートリアルをやって、困った時はStack Overflowを見るアプローチで多くの場合は進めています。本でインプットするだけだとなかなか頭に入ってこないので、基本アウトプットベースです。

アウトプットありきでインプットを考えるというのはありますね。

──「独学を基本として、分からない部分を誰かに質問する」というアプローチは、プログラミング学習全般において有効だと思いますか？

矢倉　そうですね。そういう環境に身を置くのが一番上達する方法かなという気はします。もちろん独学だとコンパイルが通らなかったりとか想定通りに動かなかったりとか失敗することって結構あるんですけど、その失敗こそが一番の学びだなと思っているので。

失敗したときに一生懸命考えることで、問題が起きたときの解決法や解決するための質問方法などが分かってきます。

──プログラミングの課題解決のためには、質問方法を磨くことも重要なのですね。良い質問をするコツのようなものはありますか？

矢倉　起きている問題がテクニカルな要因なのか、問題の解き方そのものが間違っているのかを見極めることだと思います。

もしコンパイルエラーや例外の発生などであればテクニカルな要因である可能性が高い。なので、出力されているメッセージの内容などで検索すれば、その原因や調査方法の答えが見つかる可能性が高い。

でも、そうではなくて「どう解けばいいか、そもそも見当がつかない」という場合は問題の解き方そのものに課題がある。だから、自分で考えることは諦めて人に聞くことにしています。

──問題の解き方が分からないのか、問題そのものへのアプローチが分からないのかをちゃんと切り分けるという話ですね。

問題の出どころを見極めれば
質問の仕方が分かる

矢倉式・モチベーション維持のコツ

──「どうしても、プログラミング学習のモチベーションが維持できない」というエンジニアもいると思うのですが、そういった方にアドバイスはありますか？

矢倉　自分がやりやすい領域から手を付けるのは重要なことかなと思っています。たとえば私は中学時代にLinuxカーネルのバグフィックスをした経験があるんですが、その際にはドライバやコンフィグのように比較的“手を付けやすい”ところをいじっていました。

矢倉さんが最初に実施したバグフィックス。「変数名のtypoを修正しただけなので、バグフィックスよりもLKMLに英語で投稿するのに苦労した記憶があります」とのこと。

Linuxカーネルのコーディングをしようと思うと、どうしても「コアの機能であるメモリ管理やプロセス管理をいじってみたい」と考える方も多いと思うんです。けれど、実装の難易度が高いのでどうしても心が折れてしまうんですね。

だから、自分にとって解決しやすい問題、自分と繋がりが見える問題から取り組んでいって、徐々に難易度を上げていくというアプローチはモチベーションを維持するために大事なことだと思います。

実は私が中学～高校時代に初めて開発したWebサービスも、競技プログラミングのオンラインジャッジシステムでした*1。これもやはり、自分に近いところからというアプローチですね。

アーキテクチャ選定方法は「拙速は巧遅に勝る」

──参考までに、当時開発していた競技プログラミングのオンラインジャッジシステムのアーキテクチャを教えていただいてもいいですか？

矢倉　CakePHPで実装したWebフロントエンドが、複数台のジャッジワーカー内の、Pythonで実装した独自デーモンの1つに実行タスクを振り分けるという構成でした。今なら、潤沢なリソースを使ってDockerで立てるのがいいんでしょうが、2012年当時はコンテナもあんまりメジャーではなかったですし、中学3年だったということを差し引くとこんな感じかなと思います。

矢倉さんが高校時代に作り出したWebサービスのシステム構成。

──高校生の段階でそれほど高度なアーキテクチャ選定をされていた、というのはすごい話ですね。矢倉さんはアーキテクチャを選定する場合、何を大事にしていますか？

矢倉　「迷わないこと」と「時間をかけないこと」ことを大事にしています。

──それはなぜ？

矢倉　個人的にはプログラミングをする際にソースコードの綺麗さやソリューションの美しさを追い求めたくなるときもあります。でも、膨大なブラッシュアップの時間をかけることでどんな価値が生まれるかというと「画面の読み込みが0.5秒早くなる」くらいの変化だったりする。であれば、そのサービスをより早くユーザーに届ける方が価値が高いなと考えています。

それに、アーキテクチャの選定に時間をかければ、たしかにより良い技術を選べる確率は高くなります。でも、選定に費やすコストと選定した結果得られるリターンを比較すると、実はそれほど得になっていないケースは少なくありません。時間が経過すれば開発へのモチベーションだって落ちてしまいます。

それよりも、現時点で自分が知っているベストのソリューション。言うなれば自分がストックしている技術で、なるべく早く開発を進めてしまった方がいい。高いモチベーションを保って開発を進めた方が、絶対に良いプロダクトになりますから。

──ここでも一貫してモチベーション維持術が発揮されるんですね。その「手持ちのストック技術」はどうやって作っているんですか？

矢倉　新しく登場したミドルウェアやフレームワークなどを用いて、定期的に趣味でシステムを開発しています。そうして自社のサービスにそれがマッチしそうかを確かめて、ストックを作っておくんです。

重要なのは、コードの美しさよりも提供価値

──そして現在、TEAMBOXでCTOを務めているわけですが、CTO就任の前と後とではマインドに変化はありましたか？

矢倉　「ユーザーになるべく早く価値を提供すること」をより重視するようになったと思います。

昔は、ギークとしてソースコードの綺麗さやソリューションの美しさばかりを追い求めていました。でも、それをやってどんなメリットがあるかというと、先ほど言ったように「画面の読み込みが0.5秒早くなる」くらいの違いしかなかったりするわけです。

だとしたら、多少ソースコードが汚くてもいいからサービスをより早くリリースする方が価値があると考えるようになりました。つまり、本質的に大切なものは何かを考えるようになったということです。

──その「本質は何かを見抜く」というマインドは業務経験の中で身に付けた部分も大きいと思うのですが、読者のために書籍やWebサイトによって学べるものがあればぜひ教えてください。

矢倉　書籍だとおすすめは『ライト、ついてますか』。これは「問題の本質とは何なのか？」を考えることの重要性が解説されている本です。

作家・心理学教師・ソフトウェア開発の人類学者であるジェラルド・ワインバーグによって執筆された名著。仕事をする上で必須である「問題発見」の方法が、平易な言葉で解説されている。

Webサイトの場合、定期的にチェックしているアカウントやニュースサイトなどはないんですが、Twitterでフォローしている方々が何名もリツイートするようなSpeaker Deckの資料などは読んだ方がいいんじゃないかという感じがします。

特定の誰が言ったかというよりも「それが世間にどれぐらい影響を及ぼしているか」を重視して情報を選定するようにしていますね。以下のスライドなどは非常に参考になりました。

CTOとしてチェックするのは、サービスが「課題を解いているか？」

──TEAMBOXは、企業のリーダー育成トレーニングである「TEAMBOX League」や組織力を数値で可視化する「TB Scan」といったサービスを提供しています。これらのコンセプト策定に、矢倉さんはどういった形で携わっていますか？

矢倉　僕はサービスそのもののアイデアを考えるより、サービスがきちんと「課題を解いているか？」をチェックする仕事をしていることの方が多いです。

たとえばTEAMBOX LeagueやTB Scanの場合どういったことを考えたかというと、各企業において、マネジメントの問題点や育成の結果が可視化されていないという課題があると思ったんです。可視化する、数値化するというのはテクノロジーの十八番ですから、これらの課題はシステムによって解決する意義があります。

あとは、マネジメントや育成の課題点って他の人から指摘されると結構イラっとすると思うんですけど、コンピューターに言われたら「これが真実なのか」って納得せざるを得ない部分があると思うんですね。

だから総括すると、「サービスは世の中の課題を解決しているか？」「その課題はテクノロジー“だからこそ”解決できるものか？」を、CTOとしての判断基準に置いています。

CTOに選びたいのは、こんな人材

──最後に、もし矢倉さんが次期CTOを選出するとしたら、どのような方を選びますか？

矢倉　エンジニアとしてテクノロジーへの理解があることはもちろん必要です。でも、それ以上にTEAMBOXが担っている事業にそのエンジニアの持つマインドがマッチするかを重視したいと思っています。

──というと、具体的には？

矢倉　自分を成長させようとしている人、人を成長させたいと思える人、であることが重要ですね。当社が開発・運営しているTEAMBOX LeagueやTB Scanは、いずれも人を成長させるためのサービスです。そして、TEAMBOXが成しとげたいビジョンもそこにありますから。

──事業が目指す部分と、CTOのマインドが合致しているべき、ということですね。

矢倉　そうですね。まとめると「人の成長を信じられるかどうか」が大事だと思います。人の成長を信じているビジネスなので。だから、それを実現するために全力を注げるエンジニアであれば、次期CTOを任せたいと思いますね。

“楽しむこと”こそ、上達の秘訣

矢倉さんの話の中で一貫していたテーマ。それは、「いかにしてモチベーションを維持するか？」という思考法でした。

中学時代にプログラミングと出会ってから、ひたむきにトレーニングを重ね、若くしてCTOに就任した矢倉さん。そのキャリアを「とにかくプログラミングが楽しかった。だからこそ、ずっと続けてこれました」と語ります。

どうすればプログラミングを楽しめるか？ どうすればモチベーションを高められるか？

それを考えることが、実はエンジニアとしてキャリアアップする一番の近道なのかもしれません。

取材：中薗昴（サムライト）／写真：小堀将生