山口輝樹（yama）

京都大学大学院 工学研究科社会基盤工学専攻 在籍。大学２年時にプログラミングに出会い、学生ベンチャーでのCTO経験を経て、現在は会計申告開発事業本部で内定者インターン生として従事。「成長にリミッターをかけない」ことを信念に、圧倒的なブレイクスルーを追い求めて高い視座で価値創造に挑んでいる。

サークルの部内ツールの開発から始まったエンジニアの道。「やるならガチで」という焦りとワクワク

ーープログラミングに出会ったきっかけを教えてください。

yama：大学２年の時、サークルの新歓のために情報共有ツールを作ったのが最初でした。自分のサークルは200人以上の新入生が新歓に来てくれるほどの大きなサークルなのですが、上回生（新歓する側）がその新入生の情報を管理する良い方法がなく、データを探すのが大変だったり、せっかく編集があっても気づけないという課題がありました。当時、周囲と『新入生の情報を一箇所にまとめて色分けや日程管理ができたら便利やな』と話していたことがきっかけとなり、流れで自分がGoogle Apps Script（GAS）でツールを作ることになりました。

初めての開発には苦労もありましたが、それ以上に「プログラミング楽しいぞ」という気持ちになり、２ヶ月後には大学生協で未経験可の求人を見つけて、開発系アルバイトを始めました。そこでは、アルバイト中心でホワイトボードWebアプリを開発しており、WebWorkerを用いた描画処理の並列化や、サーバーサイドレンダリングの仕組みの設計・実装などを経験させてもらいました。

ーー独学でも学ばれていたとのことですが、勉強はどのように進められたのですか？

yama：アルバイトの業務時間外でも、そこで扱っているソースコードを読み漁りながら、細かい言語仕様からライブラリ、デザインパターンの話まで、気になったことをとことん深堀りしていました。プログラミングに出会ってから半年ほど経った頃にはChatGPTが登場し、なんでも教えてくれるようになったことで、学習はどんどん加速していきました。

独学のモチベーションの源は様々でしたが、特に強かったのは「開発の世界で戦うには、自分は遅れを取りすぎている」という焦りです。同世代には小学生の頃からプログラムを書いてきたベテランがいることや、京大の情報学科にいるような一部の超人が、持ち前の賢さと要領の良さですごい勢いで成長していることはわかっていたので。「やるならガチでやらないと」という焦りがありました。

とはいえ、ものづくりのワクワクが自分の性には合っていたのも大きかったです。自分の考えたものが動くのが楽しいし、実装そのものに慣れてきてビジネス価値なども考え始めたら、自分の能力にレバレッジをかけている感じというか、大きなことを成せそうなイメージも湧いてくるようになりました。

学生ベンチャーでのCTO経験。“わかりやすい指標”に目を奪われた苦い反省

ーーその後、学生ベンチャーにCTOとして参画されたそうですが、どのような経緯だったのでしょうか。

yama：はじまりは大学３年のときにやっていた「お試しの就活」です。もともと大学院に進学するつもりだったので本格的な就職のためではありませんでしたが、インターンなどを通じて第一線のエンジニアの思考法や求められる資質に触れてみたいと考えていました。しかしこの経験が、自分にとって想像以上の大きな転機になりました。多くの企業で多くの方とお会いする中で、自身の視座が大きく引き上げられた一方で、「この高まった視座に見合う実行力を、早くどこかで試したい」とウズウズするようにもなったんです。

そんな折に、知人の紹介で学生ベンチャーにCTOとして加わらないか、という話をいただきました。自分が培ってきた技術や視座を最も裁量を持って発揮できる場所であり、ここなら求めていた「難易度の高い挑戦」ができると確信して、参画を決意しました。

ーーその学生ベンチャーでは、どのような取り組みをされていましたか？

yama：CTOとして、学生とシニアをマッチングして、訪問・交流してもらうサービスのアプリ開発を行っていました。CTOといっても、一人目エンジニアを格好良く呼んだ程度のものでしたが（笑）。Flutterによるモバイルアプリやバックエンド、Web管理画面など、開発の全領域に責任を持っていました。要求される機能が一人ではとても作りきれない量だったので、途中からアルバイトのエンジニアにも加わってもらい、開発と並行してチームのマネジメントも担っていました。この組織特有の問題に、仕組みを作って柔軟に対応できたこともあれば、失敗してしまったこともありました。

ーーその「仕組みづくり」について、うまくいった例を教えてください。

yama：一番効いたのは、ビジネスサイドとの認識あわせを早く正確に行うための工夫です。それまでは、開発する機能について、手描きのデザイン草案の図と中身の説明を共有して「これでいきましょう」と合意したつもりでも、フロントもバックエンドも作り込んだ後で「なんかイメージと違う」となって、大きな手戻りが起きることがありました。

手戻りをなくそうと思うと、事前の認識合わせをもっと丁寧にやろう、という方向に力を入れたくなります。ただ、どれだけ話し合って実装前に取り決めたつもりでも、実際に動くものを見た瞬間に「やっぱり違う」となるのは避けられません。だとすれば、これはコミュニケーションの精度を上げて解く問題ではなく、仕組みのほうで解くべきだと考えました。静的な図と言葉で説明するより、初めから動くもの（動いて見えるもの）を触ってもらうほうが早いし、確実だろうという発想です。

そこで、WidgetbookというUIカタログ構築ツールに目をつけ、試作段階のアプリを簡単に試せるようにしました。ふつうUIカタログというと、細かいUI部品の単位で使うことが多いですが、ここではアプリ上の画面を一単位として、モックデータを注入して動かせるようにしました。そして、Flutterのクロスプラットフォームの特性を活かして、UIカタログをWeb向けにコンパイルしてホストし、ビジネスサイドがURLを開くだけで本物に近い挙動を確かめられるようになりました。

その仕組みのもとで、まず動く「外側」だけをミニマムに作って「こういうものでいいですか」と共有し、合意が取れてから複雑な裏側を作り込む。この順番に変えたことで、手戻りを大きく減らすことができました。

ーー 一方で、苦い反省もあると伺いました。何があったのでしょうか。

yama：アルバイトを募集して人を増やしたのに、開発スピードが思ったほど上がらなかったんです。むしろリリースはどんどん後ろ倒しになっていって。当時は本当に苦しい思いでした。

メンバーに気持ちよく動いてもらうための工夫は、当時からかなりやっていたつもりでした。タスクの依存関係を整理して、お互いの作業が被ったり待ちが発生したりしないように丁寧に分解する。新しいタスクに入るときは、初動で変な方向に進まないよう設計のディスカッションに特に時間をかけて、不確実性を先に潰しておく。一人ひとりが手を止めずに進められる状態をつくることを、当たり前に守るべき原則だと信じてやっていました。

ーーそれだけやっていて、なぜうまくいかなかったのでしょう。

yama：今振り返ると、自分が最適化していたものがそもそも間違っていたんです。全員の手が止まらないこと（＝リソース効率）を最上位に置いてしまっていました。

待ちをなくすために全員へ別々のタスクを割り当てると、確かに各自は止まらず進みます。でもその中には、ビジネスの成長にすぐには効かない優先度の低い機能も混ざっています。しかも別々のタスクであっても、コードレビューや設計の相談は必ず発生するので、本筋のコア機能を進めている自分の工数が、そちらに吸われていくことも。「全員忙しいのに、一番大事なものが進まない」という状態になっていたんです。

本当に最適化すべきだったのは、稼働率を上げることではなく、重要な機能を最速で完成させること（＝フロー効率）でした。多少誰かの手が空いてしまうことがあっても、全員でひとつの重要な機能の開発に力を集中させたほうが、リリースが速くなる。「待ちや詰まりこそ避けるべき悪だ」という思い込みそのものが、課題の見え方を歪めていたんだと思います。

ーー組織のマネジメントだけでなく、プロダクトの作り方にも反省があるとか。

yama：そうですね。同じ「リリースが遅れた」という失敗でも、プロダクトの視点から見るとまた別の反省が出てきます。リリースが遅れた根本の原因は、要求を絞りきれずに、作るべき機能がどんどん膨らんでいったことでした。

もちろん「最初から全部を作り込まず、まずは最小限のMVPで出すべきだ」という発想自体は、当時の自分にもありました。”欲しい機能全部入りの完璧な箱”を目指す空気がチーム全体にある中で、「今そこまで要るだろうか？」とは思っていたんです。本当に解決すべき課題、人手による運営では大きな手間がかかる部分から順に、少しずつ解決していけば良い。頭ではわかっているつもりでした。

でも、頭でわかっていることと、それをやり切ることは別でした。「”完璧なアプリ”が欲しい！」という流れを止めるには、自分の提示できる代替案は足りていませんでした。さらには、自分自身もエンジニアとして「後から機能を足すより、今まとめて作ったほうが楽だ」と技術負債化を避けたい気持ちもあり、”作らない選択”をますます遠ざけてしまいました。

就活でいろいろな会社のインターンを経験した今なら、あの時の考えの甘さを理解できます。何より、アプリを早く出すことの価値を過小評価していました。アプリが完璧な状態でなくても、出すのが早ければ、そのぶん市場の反応から多くの示唆を得られ、仮説検証と改善のサイクルを回すことができたはずです。技術的負債についても、単なる”債務”として恐れ、慎重になりすぎていました。しかし、仮組みであってもアプリを早く出すことで得られる学びや収益が、後から負債を解消するためのコストを上回ることは十分にあります。負債は、事業を前に進めるための”投資”でもあったんですね。

ーー 「リリースが遅れた」ことへの２つの視点からの反省ですが、共通して見えてくるものはありますか。

yama：こうして振り返ると、組織で見ていた「稼働率」も、プロダクトで見ていた「アプリの完成度」も、結局は手応えを得やすいわかりやすい指標だっただけで、その価値を錯覚していたんだと思います。どちらも方向性としてただちに間違っているわけではないし、当然手も抜いていないのですが…。その先にある「本当に届けたい価値」からは、少し目が離れてしまっていました。

「思考を寝かせて発酵させる」成長を絶対に引き寄せる執念とメタ認知

ーー山口さんの圧倒的な成長を支えているのは、凄まじいまでの「自省（リフレクション）」と「メタ認知能力」の高さだと感じます。ご自身の成長の特性についてどう考えていますか？

yama：理屈っぽいところがあり、「ここまで他の人は考えないだろう」というところまで考え尽くすことにこだわりを持っています。いい意味で疑心暗鬼になりがちで、「これでいいんだっけ？」を考え続ける癖が元々あるんですよね。それゆえ、失敗から多くを学べるタイプ、ともいえるかもしれません。

自分が振り返りの中で一番大事にしているのは、成長のきっかけを取りこぼさないことです。ふと気づいたこと、偶然うまくいったことを、その場で見過ごさずに拾い集めておくと、後々の成長の材料になります。

拾い集めた材料を成長に昇華させるコツに、「思考を寝かせて変化を待つ」というものがあります。問題を問題と認識した状態で時を過ごしていると、自然と整理されたり、他の思考と予期せずつながったりして、良い答えが出ることがあるんです。こうした考えは、有名な『思考の整理学』という本でも"寝させる"や"醱酵"という言葉で紹介されていますが、答えの出せない難しい問いには、その場で考え続けて中途半端な答えを出すより、時間をかけて発酵を待つのが良いこともあります。

ーーなぜ「取りこぼさない」ことを重要視するようになったのでしょうか？

yama：きっかけとしては、サークルでやっているテニスを後輩に教えるようになったことが大きかったと思います。プレイヤーとしてではなく、コーチ的な役割で選手の成長を見るうちに、「うまく成長できない人は、同じアドバイスを何度もされるのに、毎回初めて聞いたような顔をしている」ということに気づいたんです。

見るたびに成長を感じられるような勢いのある人は、もらったアドバイスをその場では実践できなくても、後から自分で考えたことをどんどん混ぜていって、ものにしていきます。「この前言ってたあのアドバイス、最近になってわかってきました！」という言葉を聞けるとすごく嬉しくなります（笑）。一方で、伸び悩む人は、せっかくアドバイスを受けても、その場でしっくり来なければ忘れてしまうことが多かったんです。成長のきっかけを、ある人はちゃんと成長に変え、ある人は取りこぼしている。その差は、アドバイスの質でもセンスでもなく、受け取った後にどう扱うかだけでした。

この発見から、成長のきっかけとは、簡単にどこかへ行ってしまいがちなものだと知り、それを取りこぼさない習慣が必要だと考えるようになりました。”取りこぼし”は、気づいていないだけで自分にも起きているのだろう、と思ったからです。もちろん、自分で自分をいくら眺めても見えてこないことはありますが、せめて自分で振り返って気付ける課題くらいは、逃さず成長につなげたい、と思うようになりました。

特に学生ベンチャーの環境では、自分で見つけた小さな気づきを成長に昇華させるために、この習慣が欠かせませんでした。大きな会社のように経験豊富な先輩から的確なフィードバックをもらえる環境ではないので、簡単には変わることもできません。それでも成長し続けるためには、それ単体ではまだ役に立たない、小さな気付きの一つ一つも、取りこぼさずに寝かせて、発酵させることが必要でした。

なぜ、トップガンコースをファーストキャリアとして選択したのか ― 「成長に加速をつけられる場所」

ーー27卒就活では大手からスタートアップまで６社もの就業型インターンを経験したそうですね。その中で、最終的にfreeeの「トップガンコース」を選んだ理由は何だったのでしょうか。

yama：入社先は非常に悩んだ末、直感に任せた部分もあるのでうまく説明できないのですが、あえて一言にまとめるなら「成長に加速をつけられる場所」だと感じられたことが決め手でした。

もともと就活の軸としては「成長環境」を掲げていました。職能に固定されずにいろいろな挑戦をしたい、その挑戦を後押しする流動性のある組織（成長中の企業や、組織改革中の企業など）で、成長の機会を増やしたいと考えていたのですが、いざ内定をとって選択肢を複数並べてみると、どれもいい環境で比べられない！と困り果ててしまったんです（笑）。

そこで「本当に自分にあった成長環境とは何なのか」を掘り下げてみたところ、freeeには２つの魅力がありました。

インターンで強く感じた魅力が、挑戦の幅を自分から広げていけそうな風土です。freeeではスプリントタスクに囚われすぎず、脇道に逸れるのもOKで「やりたいならとりあえずやってみればいい」という空気がありました。また、配属先の部署には、月に２日間、OKR外の取り組みに自由に使える時間を強制的に設けるG20という制度もありました。成長のきっかけを自分で見つけに行ける環境だと感じました。

そしてもう一つ、何よりの決め手になった魅力が「トップガンコース」ならではのプレッシャーです。中途水準のスキル・マインドセットが求められ、大きな仕事を任されるような期待がかかる。この環境圧が、自分にとって良いストレスになるだろうと思ったんです。

こうした環境で幅広く成長のきっかけを掴み、大きなブレイクスルーを何度も起こして成長に加速をつけていきたいと考えています。

ーーなぜ「加速」や「ブレイクスルー」にこだわるのですか？

yama：これまでの経験の中で、想定外の急成長が自分を支えてきたからです。コツコツ努力を継続する力は誰にも負けない自分の強みですが、今の自分を作っているのは、結果的には積み上げそのものではなく、そこから偶然のように起きた大成長でした。

テニスをしていると、たった一言のアドバイスから何かがつながりはじめて急成長が起きた経験や、偶然うまく打てた一球を振り返って再現するうちに、難しい技術を習得できた経験があります。勉強でも、試行錯誤の中で思い切って問題演習のやり方を変えたことで、停滞していた成績を大きく伸ばしたことがあります。

こうした経験から、単なる積み上げで終わらず、「ブレイクスルー」を起こしてバーンと跳ねる成長曲線を描きたいと考えるようになりました。しかも一度急激な成長をすると、それまで見えなかったものが見えるようになっていきます。成長が次の成長を呼んでいく、この連鎖が自分にとっての「加速」です。

そのためには、幅広いことに挑戦して様々な成長のタネを持っておきたいし、一度大きく成長してもそこで満足せず、さらにその先を貪欲に目指したい。だから何より、リミッターをかけられないことが重要だと思っています。まさにこの思いにピタリとはまったのが、freeeのトップガンコースという選択でした。

１期生なので前例はないかもしれませんが、だからこそ「トップガンだからこそ任せていい」と思ってもらえる状態を作っていきたいです。リミッターをかけず、かけられずに、最初からぶっ飛ばして、freeeからの期待も超えていきたいと思っています。

freeeでは、トップガン2期生（2028年卒）を募集しています。