年次は不問。「顧客価値」に向き合う人が報われる理由

トヨクモ技術広報チームです。

現場のリアルな熱量をお伝えする「PLGに生きるエンジニアたち」第5回です。

今回お話を伺ったのは、現在DataCollectの開発を担当する上山さんです。2024年に新卒で入社し、2年目の2026年1月には、5段階ある等級の3段階目「プロフェッショナル」（※）に昇格しました。
※等級についての詳細は会社紹介資料（新しいタブで開きます）をご覧ください。

新卒の若手を、トヨクモは何を見て評価したのか。本人の言葉から紐解いていきます。

―トヨクモには、アルバイトとして入ったそうですね。

　大学生の時にすでに他社の内定をいただいていましたが、卒業までの間もプログラミングの仕事がしたいと思っていました。でも内定先の企業ではアルバイトの募集は行っておらず、他のアルバイト先を探していた時に出会ったのがトヨクモでした。

―実際に働いてみて、どんな印象でしたか？

　驚いたのは、最初から実際に販売している製品のバグ改善や小さな機能追加を任されたことです。バグの原因は自分で調べますし、提出時の説明もフォーマットはなく、書き方はアルバイトに委ねられていました。説明が少ないぶん工夫の余地があり、裁量の大きさを感じました。

―印象に残っているやり取りはありますか？

　最初の頃、バグの原因と直し方だけを書いて出したら、「他の方法はなかったですか？」と聞かれたんです。これで直りはするけれど、小手先の修正になっていないか、似たようなバグがまた起きる直し方になっていないか。それを検証するために、複数の案を出してほしい、ということでした。
　製品に直接コミットしている以上、責任を持ってほしい、というメッセージだったのだと思います。それに、60点くらいの提出物で「OKです」と言われても、自分の成長にはなりません。指摘してもらえてよかったと思います。

―その後、CTO木下さんから入社のオファーを受けたんですよね。

　はい、驚きしかなかったです。当時、トヨクモがエンジニアの新卒採用をしていないことは知っていましたし、待遇も、新卒の自分には想像していなかったものでした。新卒で社会的な信用もない自分を、技術力で判断してくれたことが素直に嬉しかったですし、評価してもらえているなら、とトヨクモに決めました。

―社会人経験のない学生の、何が評価されたと思いますか？

　当時言われたのは、「実力を見ている」ということでした。具体的には、TDD（テスト駆動開発）を自主的に実践していて、社員に褒めてもらったこともあったので、その姿勢とアウトプットが認められたのかなと思います。
　もう一つは、タスクへの向き合い方の違いです。アルバイトを監督する立場になって気づいたのですが、課題を渡されて「できました」と、言われたことだけで終える人が少なくない印象です。私の場合は、幼い頃からずっと「なぜ？」と原因が気になってしまう性格だったこともあり、そもそも何が原因だったのか、既存のコードと比べてどうか、他の案と比べてどうか、を丁寧に書いていました。社員から見て信頼できるプルリクエストになっていたんだと思います。

―着手前にリスクを洗い出し、承認手続きを重ねてから動く、という組織も多いと聞きます。トヨクモでは、新しい開発をどう進めていますか？

　社内共通の「トヨクモのプロダクト開発」というドキュメントがあって、それに沿っています。流れはシンプルです。PMが課題と理想像を言語化した「デザインドック」を書き、それを見てエンジニアが設計し、テックリードのレビューを経て着手します。
　リスクを潰す工程を飛ばしているわけではありません。詳細設計の段階で先行調査やPoCを行い、テックリードと一緒に判断します。ただ、その間にスタンプラリーのような承認手続きはないので、レビューを通ればすぐに着手できます。

―最近の例にはどんなものがありますか？

　DataCollectで最近作った「AI関数（新しいタブで開きます）」です。ExcelのSUMやIFと同じ感覚で日本語の指示を書くだけで、kintoneのテキストデータの要約や翻訳、分類をAIに任せられる機能です。設計段階でPoCを作って、出力の精度を検証し、利用コストを試算しました。結果的に、そのPoCをほぼそのままプロダクトに採用できました。

―テックリードに相談する時は、どんなやり取りになりますか？

　私は少なくとも3案出して、それぞれのメリットとデメリットを並べます。そのうえで「個人的にはA案が良いと考えていますが、このデメリットが気になっています。どれがいいと思いますか？」と聞くんです。するとテックリードが、私が見落としていたメリット・デメリットを補足してくれたり、理解の誤りを指摘してくれたりします。それで納得して進む、ということがほとんどです。

―その聞き方は、上山さん個人のやり方ですか？

　論点を明確化するというのは社風だと思います。新卒の頃は曖昧な質問もしていたんですが、その度にCTOやテックリードから「上山さんは、何が課題だと思っているんですか？」と必ず返ってきました。それで自分の説明不足に気づくんです。
　指導を待つのではなく、「ここに不安があるので指摘してほしい」と伝えるコミュニケーションをする。上長が指導しやすくなれば、自分が吸収できる量も増えます。主体的な成長とは、そういうことだと解釈しています。

―指摘を受けて、納得できないこともあるのでは？

　新卒入社直後はよくありました。データベースの設計で物理層にチェック制約を入れようとしたら、テックリードから「変更や拡張もありうるし、今回のケースであればアプリケーション層のチェックで十分」と言われたんです。正直「チェックはなるべく硬いほうが良い」と当時は思いました（笑）。でも言われた通りに実装を進めると、アプリケーション層で十分ということが体感できましたし、実際に後で機能追加による拡張が発生しました。自分の判断も大事にしますが、基本はまずテックリードの判断を飲み込んで進みます。9割は、最終的に腑に落ちるので。

―「美しい仕事」にこだわりがあると伺いました。今はどう考えていますか？

　「完璧な設計をする」という意味での美しさは、正直、主観の部分が多いと思っています。それは自分にとっては美しいけれど、「良い仕事」ではないと思っています。
　トヨクモにおける「良い仕事」は、「スピード感を持って、お客様に最大限の価値を届けること」だと捉えています。仕様に対して、必要最小限の仕事量で完了できること。それが今の自分の基準です。

―お客様の要望には、どう向き合っていますか？

　お客様やマーケティング担当から、例えば「機能Aはできるのに、似たようなBができないのは変じゃないですか？」と聞かれることがあります。その機能がないのは、確かに不足かもしれません。でも、「そもそもそのお客様がやりたいのはこういうことで、それなら別の既存機能で解決できる」ということもあります。何をするときも、まず本質が何かを考えます。
　マーケティング担当も開発への問い合わせを減らそうと工夫してくれていますが、エンジニアでない人に、ソフトウェア目線で言語化してから質問してほしいと求めるのは無理があると思っています。課題に対してソフトウェアでどう対応するのかを考えるのはエンジニアの領域ですから。PLGをやるからには、その責任はエンジニアにあると私は思っています。

―上山さんは入社2年目でプロフェッショナルグレードに昇格されました。入社当初から目指していたそうですね。

　グレード制度を知ってから、ずっとなりたいと思っていました。人事資料には、各グレードに必要なスキルや、影響を与えるべき範囲が明確に言語化されています。プロフェッショナルグレードには、「課題設定力」と「仲間の成長を促進させること」が求められていました。だから、とにかくその通りにやる、ということを意識しました。

―それだけで昇格できるものですか？

　「その通りに行動していたらなれた」という感覚です。飛躍した何かを達成したわけではなく、地道に、着実に積み上げました。
　どうしてもわからない時は、CTOに「求められているのは、こういうアクションですか？」と、具体案を持って確認しました。違うと言われた時も、放置ではなくちゃんと解説をしていただけます。「求めているのはこういう姿勢で、なぜなら組織にこういう影響があるから」と。だから、目標設定で苦悩したことは一切ないです。

―昇格時の評価面談では、何が評価されたと言われましたか？

　当時、DataCollectは、ほぼ1人で主担当としてメンテナンスしていました。その中で、「技術的な部分を押さえつつ、『スピード感』という組織の行動指針を守って開発を安定させていたこと」。そこが良い、と言われました。周りへの影響はまだこれから、という期待値込みの評価だったと思います。

―エンジニアの仕事は、営業職などと比べると成果を数字で示しにくい面もありますよね。

　正直、自分が頑張って機能を作ったから売上が爆発的に伸びる、ということはないです。サブスクリプションなので積み上げのビジネスですし、「この日のこの行動が劇的に売上を変えた」というのもありません。
　ただ、スピード感を持って新機能の開発や改善を続けることで、ユーザー数は伸び続けています。自分が積み上げてきた開発が売上に寄与している、という体感はあります。
　実際、評価面談でも売上の数字の話はほとんど出ません。常に感じるのは、開発スピードや、他のエンジニアとのコミュニケーションが重視されている、ということです。それができていれば効率的な開発になり、結果として売上にもつながる。そういうことだと理解しています。

―昇格時には、次の課題も伝えられたそうですね。

　「責任範囲を、もう少し広げてほしい」と言われました。自分の製品をリードするのは当然として、他のメンバーや、プロフェッショナル未満のメンバーに良い影響を与えていくことです。

―実際に変えたことはありますか？

　以前は、自分のタスクを終わらせるので手一杯でした。今は、DataCollectの価値を高めるために何を優先すべきか、他のメンバーの進捗はどうか、を意識的に見る時間を作っています。
　そこで気づいたのが、担当エンジニア同士の会話が少ないかもしれない、ということでした。トヨクモでは会話の履歴を残すためにSlackでのやり取りが基本ですが、テキストだけだと表情や声のトーンといった非言語の情報が伝わりにくく、ちょっとした確認や相談がしづらいかもしれないと感じていました。そこで、他のチームでやっていた「毎朝5分の朝会」を、「とりあえず1週間やってみませんか」と私のチームにも提案しました。1週間後に聞いてみたら「円滑なコミュニケーションのために続けたほうがいい」と意見が一致して、今も続けています。

―効果はありましたか？

　はい！朝会の会話から「これをやったらお客様に喜んでもらえそう」という気づきが生まれ、タスクの順番を入れ替えられました。また、頻繁に進捗を共有することで対応漏れも 防げるようになりました。毎朝5分かかりますが、結果的にそれ以上の開発時間の短縮ができています。

―将来はVPoEを目指していると伺いました。

　私にとって技術はあくまで手段で、製品や組織を成長させることに関心があります。
　私から見ると、今の開発本部は、CTOが細部まで目を配ることで、製品が会社の理念から外れないようにハンドリングされています。でも、組織が大きくなったり、AIで開発スピードが上がったりすれば、どうしてもCTO一人では見きれない部分が出てくると思うんです。その時、会社の理念や目指す方向を理解して、判断を言語化できる人が増えれば、スピードを落とさずに成長できるはずです。そういう人材になりたいと私は思っています。

―最後に、今の環境でプロダクトに向き合えずにいるエンジニアへ、メッセージをお願いします。

　この会社でしか社会人経験がないので、わかったようなことは言えないのですが、トヨクモは純粋に製品を良くすることに向き合っていると感じます。そのために、不要なペーパーワークやスタンプラリーは、徹底して削ぎ落とされています。
　少人数で、短期間でリリースできてしまうと、「確認が不十分なんじゃないか」と思われるかもしれません。でも実際は、無駄を削って最小限の設計をすることで、エンジニアリングに集中できる環境になっています。その結果として短期間が実現しているのであって、短期間を目標にしているわけではないんです。そういう環境で、責任を持って働けるのが良いと、私は思っています。

―ありがとうございました！

************************************

【最後に】

トヨクモ技術広報から
自分の限界を決めずに挑戦したい方へ

今回は、新卒2年目でプロフェッショナルに昇格した上山さんに、トヨクモでは何が評価されるのかについて伺いました。

年次でも、売上の数字だけでもない。「お客様にとっての価値に向かって判断し、自ら動き続けること」。それが、トヨクモで評価されるエンジニアの姿です。

オープンな組織と確かな技術をベースに「自らプロダクトの価値を作る！」
それが私たちの目指すエンジニアリングです。

次回は、「調整のない構造」で純粋に開発に向き合うエンジニアへバトンを繋ぎます。
どうぞお楽しみに！

************************************

「すべての人を非効率な仕事から解放する」という弊社のミッションに共感し、ともに挑戦していただける方からのご応募を心よりお待ちしております。

▶応募はこちらから（新しいタブで開きます）

▶開発本部全体の情報はこちら（新しいタブで開きます）

引き続きトヨクモをよろしくお願いいたします！