KNOWLEDGE WORK Dev Talk #15「 『半径3メートルを幸せにしたい』新卒エンジニアの仕事観」kakeru|Knowledge Work Developers Blog

ナレッジワークで働くエンジニアたちのパーソナリティに迫るインタビューシリーズ、「KNOWLEDGE WORK Dev Talk」。これまでのキャリアの歩みや価値観、現在取り組んでいるプロジェクトなどについて質問していくコーナーです。ナレッジワークのVPoE(VP of Engineering)である木村 秀夫(hidek)と一緒に、ナレッジワークのエンジニアのイネーブルメントの源泉に切り込んでいきます。

第15回目となる今回は、2025年4月入社の新卒エンジニアである宮崎 翔(kakeru)に話を聞きました。

※過去のインタビュー記事はマガジンからご覧ください。


宮崎 翔(kakeru) / AI Portal Dev Group
2025年、東京大学大学院学際情報学府先端表現情報学コース修士課程卒業。同年、株式会社ナレッジワーク入社。ソフトウェアエンジニア職に従事。


数学好きの少年が「便利さ」に魅せられてコードの世界へ踏み込むまで

ーー自己紹介からお願いできますか?

kakeru:新卒1年目のkakeruです。フロントエンドエンジニアとして働いています。ナレッジワークでは、新卒として初めてのフロントエンドエンジニアということもあり、いろいろな方に可愛がっていただいています。

出身は愛知県で、東京大学で情報系の学問を学びました。個人開発やインターンを重ねる中でフロントエンドエンジニアとして働くことを決意し、ナレッジワークに入社しました。現在の業務としては、今後リリース予定のAI機能の開発を担当しています。よろしくお願いします。

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

kakeru:もともと高校まで数学が大好きで、大学では複素関数論の研究者になるつもりで進学しました。趣味だった数学で確率のシミュレーションを行ったことが、プログラミングとの最初の出会いでした。

僕の世代では珍しいと思うのですが、最初に触れたプログラミング言語はExcelのVBAです。プログラミングをやってみたいと思いながらも、「環境構築が難しいらしい」と聞いて、何が一番簡単に始められるのか調べたところ、VBAならマクロを有効化するだけですぐに書けると知って始めてみました。これが僕の最初のプログラミング体験です。

ーーそこから自分で試すうちに、プログラミングにハマっていった感じですか?

kakeru:大学の情報系の授業でUNIXを扱う機会があったんです。シェルを触るとドラッグ&ドロップしなくてもファイルを動かせたり作れたりして、クリック操作もいらないと知って、衝撃を受けました。僕はマウス操作があまり得意ではなかったので、なおさらその便利さに惹かれたのを覚えています。

もともとプログラミングに限らず「便利なものをつくること」が好きだったので、そこからシェルスクリプトでいろいろなアプリを作るようになり、徐々にプログラミングにのめり込んでいきました。

GUIじゃないと使ってもらえない。その悔しさがフロントエンドへと向かわせた

hidek:今の話を聞いてちょっと疑問に感じるのですが、そこからなぜフロントエンドへ進んだんですか?

kakeru:そう思いますよね(笑)。実はちょっとしたきっかけがあったんです。

あるとき、学部の友達に自作アプリを見せたら「めっちゃ欲しい!」と言ってくれたんです。「このZIPを解凍して、コマンドを叩けば使えるよ」と説明したら、「えっ、これって黒い画面で使うやつなの?」と言われてしまい、最終的に使ってもらえなかったんです。

自分が提供したい価値には共感してもらえたのに、見た目のせいで届けられなかったのが、自分にとってすごくショックでした。でもよく考えると、CUIが使える人よりウェブブラウザが使える人のほうが圧倒的に多い。「自分が本当にやりたいことはどっちなんだろう?」と考えたとき、「多くの人に面白いものを届けたい」という気持ちが勝りました。

そこで「じゃあブラウザからだったら使う?」と聞いたら、「それなら使うわ」と言ってくれて、それがフロントエンドを書き始めた最初のきっかけです。

hidek:なるほど、プロダクトデリバリーの観点で、お客様ニーズとしてGUIが必要だったから挑戦したんですね。フロントエンドの原体験としては珍しいケースですね。

kakeru:言われてみるとそうかもしれません。自分にとっては大きな転機でした。

hidek:ただ、そこからフロントエンドに特化していった背景には、技術的な面白さもあったのかなと勝手に想像しているんですが、そのあたりはどうですか?

kakeru:まさにその通りで、技術的な面白さも大きかったです。CUIのアプリをGUIに移したとき、ユーザーからのフィードバックの質が全然違ったんです。

CUIのときは「便利だね」「自分向けじゃない」みたいな大雑把な反応が多かったのですが、GUIにした途端、「ここはカスタムできる?」「テーマを選べるようにしてほしい」といった具体的な意見や要望がたくさん来るようになりました。

しかもフロントエンドだと、それを直して提供し直すサイクルが速い。友達の目の前で修正して、「こういうこと?」とすぐ見せられるのが本当に楽しかった。その体験から、ものづくりをする上で自分はフロントエンドに向いていると感じるようになりました。

hidek:おっしゃる通り、フロントエンドとバックエンドではユーザーからのフィードバックの性質が違いますよね。フロントエンドは「ぬるぬる感」や「使いやすさ」といった定性的な反応が多いので、プロダクトに反映したらユーザーからすぐに返ってくる。フィードバックサイクルが速いのは、まさにフロントエンドの面白いところですね。

フロントエンドはなんとなく動くまでは早いけれどけれど「教えるのが難しい」

ーー学生時代にインターンに力を入れていたと伺いました。どんなことをしていたのですか?

kakeru:学部生の頃、高校〜大学の先輩3人が受託開発の会社を立ち上げることになり、「手伝ってくれない?」と声をかけてもらってインターンをすることになりました。

その先輩3人が、バックエンド担当、アプリとインフラ担当、フロントエンド担当という構成だったのですが、ある日フロントエンドの方が退職してしまって、急遽自分がやらざるを得ない状況になりました。もともと個人で書いてはいたのですが、このインターンをきっかけに実務としても本格的にやっていくことになり、それ以来ずっとフロントエンド開発に取り組んできました。

その会社では多くを任せてもらい、最終的にはフロントエンドの責任者という立場で、インターン生や正社員の方に教える機会もありました。

ーーその時に難しかったことはありますか?

kakeru:そうですね…。言語化が難しいのですが、フロントエンドは「何を教えればいいか」が本当に分かりづらいんです。

バックエンドであれば、APIを作って疎通して…という一連の流れがあり、入門として教えることがある程度は決まっていると思うんです。でもフロントエンドは、動かすまでが速い一方で、学ぶべき範囲がとても広い。

見た目を作る部分を教えるのか、Reactなどフレームワークの難しさに触れてもらうのか、バックエンドとの疎通を学んでもらうのか、アーキテクチャを理解してもらうのか。プログラミング未経験の方から「フロントエンドのことを学びたい」と言われた時に、どこから教えるべきか、本人はどこに興味があるのかを探りながら進める必要があり、その見極めが難しかったです。

hidek:なるほど。フロントエンドって、デザイン寄りの部分もあれば、ロジックやアルゴリズムのようなプログラミングの基礎的な部分もあるし、UXのようなファジーな部分もある。興味を持ってもらいやすい反面、教えるとなると領域が多いので難しいですよね。

「ここで働きたい」と確信したナレッジワークでのインターン経験

ーーここからは、kakeruがナレッジワークに出会った話へ移ります。会社の存在を知ったきっかけは?

kakeru:就職活動を始めた頃、逆求人イベントに参加したのですが、そこでmayahさん(CTOの川中)と話したのがきっかけです。学生時代に自分で開発したアプリを紹介したところ、「面白いですね」と共感してくださり、とても温かいフィードバックをいただきました。そのうえでナレッジワークのことも丁寧に説明してくれたのですが、そこで「この人面白いな」と感じて、インターンに参加してみようと思いました。

hidek:どんなアプリを見せたんですか?

kakeru:東京の路線図を使ったアプリです。僕は愛知出身なのですが、上京したときに電車の乗り換えが全然わからなくて。「何分かかるか」は簡単に調べられるサービスはあるけれど、「何分あればどこまで行けるのか」は調べられないことに気づき、探索できるアプリを作りました。地図を動かして操作すると、行ける範囲が可視化されるものです。

さらにもう一つ機能があり、例えば友人と待ち合わせる時、「どこでもいいから中間地点で会いたい」という状況ってありますよね。そういう場合、お互いが最短で移動できる「最適な集合駅」を、操作するだけで割り出せる機能を作っていました。こうした機能を説明したところ、興味を持ってもらえました。

hidek:面白いですね。mayahさんにはどんな印象を持ちましたか?

kakeru::話していて、「この方は本当に技術力が高い」とすぐに分かりました。話し方がとても論理的で、技術への深い見識が伝わってきました。そのうえで、プロダクトに対する強いこだわりも持っていて、当時のナレッジワークのプロダクト品質に満足しておらず、「本当はもっとこうしたい」という理想を率直に話してくださったことを覚えています。

それまで出会った優秀なエンジニアの方は、どちらかというと技術へのこだわりが強いタイプが多かったのですが、mayahさんは技術とプロダクト品質の両方に高い熱量を持っていて、本当にすごいと感じました。

ーーナレッジワークという会社についてはどう感じました?

kakeru:印象が一番大きかったのは、プロダクトのUI・UXが素晴らしかった点です。

実は、就職活動をしていた当時、僕の中では少しジレンマがありました。僕はとにかく便利なものが好きで、「自分の時間を使うなら、誰かの生活を便利にすることに使いたい」という思いが強いんです。なので就職活動でも、エンタメ系などのサービスにはあまり惹かれず、BtoBのプロダクトに携わりたいと感じていました。

でも同時に、フロントエンドエンジニアとしてデザインやインタラクションの質にも妥協したくないと思っていました。ところが日本のBtoBプロダクトは、管理画面寄りの無機質なUIが多く、体験として惹かれるものが少なかった。一方で BtoCは体験はリッチでも、自分の志向とは少し違う領域でした。

そんな中、ナレッジワークのプロダクトのデモを見て「BtoBでもここまでのUI・UXが作れるのか」と強く感じて、「この会社のプロダクトは違う」「ここで働きたい」と自然に思えました。

ーー入社前にナレッジワークでもインターンを経験していますよね。記憶に残っていることはありますか?

kakeru:はい、2週間のサマーインターンが非常に印象的でした。6人チームで機能を開発する形式だったのですが、想定外だったのはフロントエンドエンジニアが自分ひとりだったことです。最初は「本当に大丈夫かな…」と緊張しました。でも、当時すでに社内外で活躍されていたよしこさん(フロントエンドエンジニアの吉田)の存在を知っており、大丈夫だろうと思って挑戦することにしました。

結果的に、このサマーインターンは本当に楽しく、間違いなく人生で一番成長できた2週間でした。開発者体験として非常に良く、とても満足度の高いインターンでした。また、同じチームだった2人が、その後同期として入社してくれたのも嬉しかったですね。

ナレッジワークのコンセプトである「イネーブルメント」を、単なるスローガンではなく「自分自身が成長させてもらう経験」として体感できたのが大きかったです。

hidek:具体的にはどのような点でご自身の成長を感じましたか?

kakeru:複数のメンターの方にローテーションでサポートいただいたのですが、どんな質問にも丁寧に答えてくださって、本当にありがたい環境でした。

特に印象に残っているのが、コードを読んでいて違和感を覚えた箇所があり、「ここはなぜこう書いてあるんですか?」とよしこさんに質問したときのことです。今思えば、インターン生が突っ込むには少し踏み込んだ質問だったと思います。でも真っ直ぐ向き合ってくださり、「たしかにここは変だね」と言いながら、「どんな意図や設計思想で作られたのか」「どういう経緯でこの形になったのか」をとても丁寧に説明してくれました。

最後には「じゃあプルリク作っといて」と任せてくれて、自分の意見を真摯に扱ってもらえたことが本当に嬉しかったです。コードそのものだけでなくその背景まで含めて説明していただけたことで、多くの学びが得られ、それが自分の成長につながったと強く感じています。

hidek:それは、視座が一段上がる体験ですね。ビジネスの現場で使われるプロダクトコードって、関わる人が多いから、常に変化を求められますよね。過去のコードには必ず歴史的な背景があって、それを理解しないと変更もできないし、軽率に変えるとお客様が使えなくなる可能性もある。だからこそ、背景を踏まえて理解する姿勢が重要ですね。

kakeru:はい。そしてこれはサマーインターンとは別の話ですが、入社前に参加した内定者インターンも非常に良い経験でした。ラーニング領域の開発チームに配属され、ノウハウ獲得の有償化に関わる開発を1ヶ月ほど担当しました。

特にメンターのwadamaruさん(フロントエンドエンジニアの和田)と働けたことは自分にとって大きく、自分の「当たり前」の水準が大きく引き上がりました。フロントエンドの技術だけでなく、仕事の進め方やプロダクトの捉え方まで多くを学び、「こういう人と働きたい」という理想像も明確になった貴重な経験でした。

入社後の挑戦──目の前の課題と向き合い続けて広がったスキルの幅

ーーでは、学生時代の話から、入社後の挑戦へと進みます。この半年間、どんな仕事に携わってきましたか?

kakeru:入社して最初の大きな開発が、カレンダー連携に関する機能でした。営業の方は、商談の予定をGoogleやOutlookのカレンダーで管理していることが多いのですが、当時のナレッジワークでは 「予定を登録することはできるけれど、カレンダーそのものは見られない」という状態でした。つまり、外部カレンダーを開く、空き時間を確認する、ナレッジワークに戻って予定を作成する、という行ったり来たりの手間があったんです。

特に大企業ではOutlookユーザーが多く、「ナレッジワークの画面でそのまま自分のカレンダーを見られるようにしてほしい」という要望が非常に強くありました。

そこで、ナレッジワークの画面にOutlookの予定表を表示でき、そこからそのまま商談の予定が組めるという仕組みを作ったのが、入社後最初の本格的なプロジェクトでした。

ーーこの半年を振り返って一番大変だったタスクはありますか?

kakeru:「顧客情報をもっと柔軟に管理したい」というお客様の要望に応えるための、顧客管理画面の拡張が特に大変でした。

ナレッジワークには、お客様ごとの情報をまとめておく画面があるのですが、当時は「顧客名・担当者・関係者」の3つだけしか登録できませんでした。でも実際には、住所・電話番号・メモなど、営業活動の中で必要な情報は会社ごとに異なります。そこで、会社ごとに好きな項目を柔軟に設定できるようにする機能を追加することになりました。

これはゼロからの新機能ではなく、既存コードを理解した上でデグレを防ぎつつ、将来的な拡張性も考えた設計が必要でした。入社半年で取り組んだタスクの中では、技術的にも設計的にも一番難しく、やりがいの大きかった開発でした。

hidek:既存機能の改修と、新しくゼロから機能開発するのとでは、使う頭がかなり違いますよね。インターンのときに「ここ、なんでこうなっているんですか?」とコードの背景まで踏み込んでいた話を聞くと、改修のほうが得意なのかなと思ったのですが、実際どちらが好きですか?

kakeru:好きなのは圧倒的にゼロから作る方です。特に基盤を設計するような仕事が好きなので、いつかミドルウェアみたいなものも作ってみたいと思っています。みんなが自然ときれいにコードを書けるように基盤を作ることに関心がありますし、フィードバックサイクルが早いところに魅力を感じます。

ただ、「得意かどうか」となると話は別で、自分ではどちらもフラットだと思っています。ナレッジワークのコードはとても綺麗なので、読んで理解する負荷が少ないんです。だから既存機能の改修でも、過去の意図をくみ取りながら考慮漏れを潰していく作業は意外と好きですし、やっていて楽しいと感じます。

hidek:両方を楽しめるのは強みですよ。ミドルウェアって、頭の中だけで設計しても実際に使われないことが多い。だからこそ、お客様のニーズを現場で知りながら作る経験はすごく大事。今のプロダクト開発での学びは、将来にとって大きな財産になると思います。

kakeru:ありがとうございます。まだまだひよっ子ですが、本当に学ぶことばかりで、毎日が刺激的です。

ーー入社時と今を比べて、ご自身が成長を実感する部分はありますか?

kakeru:ハードスキルで一番伸びたと感じるのは、E2Eテストを書くようになったことです。入社前はまったく経験がなかったのですが、任された範囲のテスト設計を主体的に進めるうちに、確実にスキルが身についたと実感しています。

一方、より大きく伸びたと感じるのはソフトスキルです。調整力というか、周辺と足並みをそろえるためのコミュニケーション力は、この半年で驚くほど必要になりました。

現在所属しているチームで開発している機能は、ナレッジワーク全体におけるポータルの役割を担っています。そのため、他プロダクトとの関係性が重要です。他プロダクトの方針を把握しておかないと判断できなかったり、仕様上のコンフリクトが発生したり、フロントエンド全体の将来像も考慮しないといけない。

様々なリスクがあるため、横串での調整が必須になります。そうした状況の中で、関係者と早めに認識を合わせに行く動きが自然と身についたのは大きな成長だと思います。

さらに、最近は構造的な視点も持てるようになりました。たとえば、とある機能はもともと特定のプロダクト専用として作られていたため、そのプロダクト向けのパッケージに置かれていました。過去の経緯を考えれば自然なのですが、別チームがその機能を使い始めたことで、「このままでは構造が複雑になり、どんどん扱いづらくなるのでは?」と早い段階で違和感を覚えました。

そこで、 「いまの配置では将来つらいので、全体から参照できる共通レイヤーに移したほうがいい」とチームに提案し、最終的にその方向で整理されました。結果としてコード構造がシンプルになり、どのプロダクトからも扱いやすくなったので、とても良い改善だったと思っています。

hidek: その視点を持てるのは本当に良いことですね。コードを書くだけじゃなくて、プロダクト全体の構造や将来の負債まで考えられるのは、若手のうちに身につけるのが難しい力だから。

違和感をそのままにせず、ちゃんと相談して動いた点も素晴らしいと思います。こういう「おかしいと思ったら早めに声を上げる姿勢」が、プロダクトを良くしていくので、ぜひこれからも続けていってほしいです。

「最初にインストールされるアプリを作りたい」便利さへの異常な執着が僕の原点

ーー ここからは、仕事観や価値観について伺います。仕事において意識していることや心がけているスタンスはありますか?

kakeru:大きく2つあります。

1つ目は、「仕事を好きでい続けたい」ということです。僕はもともと好きなことには全力で取り組めるのですが、反対に、嫌いなことは本当に手が動かなくなるタイプなんです。たとえば事務作業が苦手で、もしそれが仕事の中心になってしまったら毎日がつらくなる。だからこそ、自分がワクワクしたり、楽しさを感じながら取り組める領域で成果を出していきたいという思いがあります。

hidek:大丈夫、エンジニアはだいたい事務作業が苦手だから(笑)。

kakeru:もう1つ意識しているのは、仕事に限らず「半径3メートル以内の人を幸せにしたい」という気持ちが強いことです。

僕がいなくても世界は回るけれど、僕がそこにいることで「話していて楽しかったな」と思ってもらえたり、一緒に働くチームのパフォーマンスが下がるのではなく、むしろ上がるような存在でありたいと思っています。

「このチーム好きだな」と思ってもらえるような働き方ができたら嬉しいし、みんなが楽しく仕事できる雰囲気づくりには、いつも意識的に取り組んでいます。

ーーこの先キャリアにおいて、kakeruが成し遂げたいことはありますか?

kakeru:実は、エンジニアとしてずっと抱いている野望があります。それは「パソコンを買ったとき、真っ先にインストールしてもらえるようなアプリを作ること」です。「なんでこれ最初から入ってないんだろう?」と思ってもらえるような存在になれたら理想です。

この思いの根っこには、以前からお話ししているように、便利なものへの異常なくらいの好きさがあります。自然に手が伸びて、意識せず使いこなせるようなプロダクトが本当に好きなんです。

本当に良いUXって、気づかれないものだと僕は思っていて。普段使っているパソコンと違う環境に触れると、思わず操作を間違えてしまうことがありますよね。ああいう「身体に染みつくレベルの体験」をつくりたいんです。だからこそ「最初に入れるアプリ」という位置づけは、自分の理想にすごく近いんだと思います。

hidek:すごく分かります。僕も昔、「開発エコシステムを良くしたい」という思いがあって、パッケージシステムのような、エンジニアが環境構築時に最初に触るものを作りたいと思っていたんですよ。なので「みんなに使われるものを作りたい」という気持ちは共感できます。

kakeru:ありがとうございます。さらに言えば、もしBtoB向けのシステムをつくるなら、日常の中に深く溶け込んでいるプロダクトにしたいです。業務開始から終了までずっと使われて、「これがないと仕事にならない」と言ってもらえるような存在にしたい気持ちがあります。

hidek:まさに、僕らがナレッジワークで目指しているものってそれですよね。営業の方が朝出社して一番に立ち上げて、仕事中もずっと寄り添って、成長まで支える。そんなプロダクトを作ろうとしている。kakeruのやりたいことと、ナレッジワークの方向性がすごく噛み合っているのが羨ましいくらいです。

kakeru:本当にそう思います。挑戦したいことはたくさんあるので、もっと力をつけていきたいです。

コミュニティへの挑戦──初めてのカンファレンス登壇

ーー11月23日に開催される、TSKaigi Hokurikuで登壇されますよね(タイトル:「type-challenges を全問解いたのでエッセンスと推し問題を紹介してみる」)。内容について紹介いただけますか?

kakeru:Type Challenges」というTypeScriptの型を使ったパズル問題集があるのですが、僕は学生時代にそれを全問解いたことがあります。そこで得た学びや、問題を解くうえで意識したほうがいい点、それが実務でどう役立つか、といった内容をお話ししようと考えています。

この題材を選んだのは、サマーインターン時代に社内のオンボーディング資料でType Challengesが紹介されていて、それが取り組むきっかけになったからです。もともと型パズルが好きだったこともあり、「全部解いてみたら面白いかも」と挑戦してみました。型まわりの理解を深めることは、プロダクトの保守性や安心して機能追加できる土台づくりにも直結するので、その重要性についてもお話しできればと思っています。

参考:過去の執筆記事
【TypeScript と友達に】Type Challenges を全問解いたのでエッセンスと推し問題を紹介してみる – 前編
【TypeScript と友達に】Type Challenges を全問解いたのでエッセンスと推し問題を紹介してみる – 後編

ーー登壇しようと思った動機は?

kakeru:プロポーザルを出した理由は、「いつかはカンファレンスで登壇してみたい」という思いが昔からあったからです。学生の頃からオーディエンスとして参加する機会はあったものの、登壇しようと思ったことはありませんでした。社内の経験豊富な登壇者と話しているうちに、「自分も一度挑戦してみたい」という気持ちが強くなっていき、よしこさんに相談したところ「出してみなよ。まずは応募してみたら?」と背中を押してもらいました。

そして今回、人生で初めて出したプロポーザルが無事採択されて、初めての登壇に挑戦することになりました。小さなミートアップでの登壇経験すらないので、正直やばいくらい緊張しています。

hidek:それはすごいチャレンジですね!

ーーそういったコミュニティで発表するのはすごく価値ある経験になりますし、素晴らしいことだと思います。成功を祈っています!

(取材・編集:三木鉄平 / 撮影場所: WeWork 神谷町 共用部)

【採用情報】 ナレッジワークでは、一緒に働くエンジニアを募集しています

新卒採用 特設ページ

27新卒エンジニア採用 募集要項

就業型インターンシップ 募集要項


元の記事を確認する

関連記事