「納める」から「育てる」へ 。価値に向き合い続ける働き方

トヨクモ技術広報チームです。 現場のリアルな熱量をお伝えする「PLGに生きるエンジニアたち」第6回です。

今回お話を伺ったのは、現在FormBridgeの開発を統括する山口さんです。受託から自社プロダクトへ移った山口さんの言葉から、「技術者が自ら判断し、調整に時間を奪われずにプロダクトの価値に向き合える現場」がどのように動いているのかをお伝えします。

―今はどんな役割を担っていますか？

　FormBridgeの統括のような立場で、メンバーへのタスクの割り振りや進捗の調整・管理をしています。どちらかというとマネージャー寄りですが、人事には関わらず、開発に関する範囲です。自分自身も、ロードマップのタスクや細かい修正に取り組んでいます。トヨクモは8年目で、その前は10年ほどSIerにいました。

―前職では、どんなお仕事をしていたのですか？

　小規模なSIerで、官公庁などの公募案件を落札して開発する仕事を10年近くしていました。仕様書も納期も最初から決まっていて、勝負どころは見積もりと工数の組み立てです。

　そこでは、段取りの力が身に付きましたね。期日までに終えるには、頭から順にやるのではなく何を先に片づけるか。技術力も、磨こうと思えば身につく環境だったと思います。

―働き方において、理想とのギャップを感じていたのはどんなことですか？

　エンジニアとしては「もっとこうしたらいいのに」と思っても、仕様だから、納期だから、と一度形になったら納める、というやり方だったので、「自分だったらもっとできるのに」とよく感じていました。入札できたら仕事ができ、納品したら完了、という形だったので、作ったものを最後まで面倒を見られるとは限らなかったんです。納品後の運用が自分たちではないので、作ったものが良いのか悪いのかがわからない。例えば改修の時に、知らない人が読んでもわかりやすいコードだったのか、とか。作るところから運用まで一貫して担当して、その経験を積みたい。それが転職を考えたきっかけです。

―開発を進める上で、判断が必要なときは、どう進めていましたか。

　月に1、2回のクライアントとの定例会議までに、「確認していただかないと進められないこと」をまとめて資料を作っていました。その会議で確認して持ち帰り、議事録に起こして「先方に決めていただきました」と確定させる。実装上の判断は、だいたいこの流れでした。障害が起きたときも、お伺いを立てている間に状況が進んでいく、ということもありましたね。資料作りは、ものを作ることと並ぶくらい大事な仕事だったんです。

　そして判断するのは常にお客様で、さらに窓口となっている方の奥に本当の決裁者がいる、ということもあり、距離の遠さがありました。受託開発をしている時は、それが当然の手順だと思っていました。

―転職でトヨクモを選んだ理由は何だったのでしょうか？

　実装からメンテナンスまでやりたかったので、自社サービスで探していました。その上でトヨクモの面接で木下さん（CTO、PM）、北川さん（新しいタブで開きます）とUnix文化の話になり、小さな機能を組み合わせて大きな機能を作るという考え方が、自分の経験ともやりたいこととも合っていたんです。前職はお客様のOKがないと進みませんでしたが、ここでは自分たちで判断できる。責任はより大きいけれど、そのほうがいいと思いました。お客様の判断を待つより、イニシアチブはこちらで持ちたかったので。実際、今はそれができています。

―トヨクモに入って、仕事はどう変わりましたか？

　何もかも違いました。前職は成果物を納品すれば完了。トヨクモではリリースして終わりではなく、どんな改善が必要か、リリースのやり方自体にミスの起きやすいところはないかまで確かめ、自分たちで直していきます。改善の目的も立てやすくなりました。担当製品の価値を上げ、お客様に価値を届けるために、逆算して自分に何ができるかを想像しやすいんです。

　書類も大きく変わりました。前職では納品時に成果報告書が必要で、発注元に説明するための大事な書類でしたが、実はそれが一番時間のかかる作業でした。トヨクモでは社外に説明する必要がないぶん、ドキュメントは運用やレビューで実際に使うものに絞れます。以前の資料作成にかかっていた時間がまるごと、実装やタスク管理など製品の価値を上げることに回るようになりました。

―会議や確認に使う時間は、どう変わりましたか？

　前職では、判断が必要なことは、クライアントとの次の定例会議まで持ち越して確認していました。トヨクモも会議はありますが、関係者の認識をそろえる場や、新しい技術を関係者や興味がある人で共有する場で、外部の人に判断を仰ぐための会議はありません。

―要件はPM木下さんが作るということですが、その後やリリースまでは、誰がどう決めているのですか？

　要件をもとに実際にどう動かすか、プログラムやモジュールをどう分けるかは、ほぼエンジニアで決めています。実装の都合で「この要件のままでは難しい」となれば木下さんにSlackなどでフィードバックして、ある程度コントロールできる。ここがけっこう大きいですね。

　リリースも、日程を決めたら「ここまでできていればまず出す。追加で必要な機能は次のこのタイミングで」と自分たちで決めます。出した後も、やるべきことは最後までメンテナンスしながら進めていきます。

―前職ではお客様の判断を待っていた要件や仕様、リリースを、今は自分たちで決めている。会議や確認にかかる手間がここまで変わったのは、何が違うからだと思いますか？

　誤解を恐れずに言えば、決定を相談したり委ねたりする相手が「身内」であることです。受託では、社外の方に一から説明しなければならないこともある。トヨクモではエンジニアが社内で決めたことを製品に反映していきます。社外への説明はCS（カスタマーサポート）がプロとして担い、整理された話が開発に届く。そこに時間を使わなくてよくなったのは大きいですね。

―自分たちで決める部分が多くなると、その分責任を負うことになりますよね。負担ではないですか？

　負担とは感じていません。自分たちが作ったものをどうするかは、自分たちで決める。むしろそちらが当たり前だと思っています。前職では、納品先で製品が実際にどう使われているかわかりませんでした。今はリリース後まで自分たちで見られるから、責任を果たすための作業を逆算で考えるようになります。インフラも、コストや運用の手間からベストな構成を選び、陳腐化すればその都度更新します。作ったものが動くベストな状況まで自分たちで決められるのが、前職との大きな違いです。

―判断の重さを感じたのは、どんな場面でしたか？

　今担当しているFormBridgeで、新しいバージョンのフォームを設計したときです。7年近く使ってきたフォームを、UIもアーキテクチャも0から作り直しました。旧いフォームとの互換性もある程度必要で、何を引き継ぐか、新しいアーキテクチャでどこまで引き継ぐか、何を捨てるか。その選択が難しく、判断の責任の重さを感じました。

―判断の重さがあっても、自分たちで決めるほうを選ぶのはなぜですか？ 

　「お客様が言ったとおり」に進めるには、相手にすべてを説明しきっている前提があります。私にはそちらのほうがつらい。もちろん今も社内への説明責任はありますが、それも判断を委ねるのではなく、「自分たちはこう考えるからこうする」と説明するものです。自分たちで考えたことを説明するほうが納得できますし、大雑把に言えば、むしろ楽なんです。

―お客様と直接やり取りするCSとの連携は、どう回っていますか？

　CSがお客様の要望を「バリューになりそうか」「致命的な不具合か」という観点で絞って渡してくれます。過去の修正履歴や開発側が共有した仕様もCS側で調べた上で、「開発担当に聞かないとわからない」ものだけが来るんです。

　ただ、最初からこうだったわけではありません。5年ほど前までは問い合わせがそのままこちらに流れてきて、何を聞かれているのかわからないこともありました。

―そこからどう変わったのですか？

　北川さんが問い合わせのフォーマットを作り、「これに合わせて開発に聞いてください」と発信したところ、一発で通じ、その後CSと改めてすり合わせることもありませんでした。誰がどこまで調べるかという境界が曖昧だったのを、そこさえ決めれば回ると見極めて作られたフォーマットだったからだと思います。

　開発側も、調査手順をマニュアル化し、新しく入った人に渡して随時更新しています。以前はCSと一往復しないと調査の入り口にも立てなかったのが、今は最初から「お客様にこれを聞いてください」と言えます。

―誰がどこまで調べるかの境界をはっきりさせると、「そこから先は関係ない」という縦割りになりませんか？ 

　受け取るのはCSからでも、出どころはお客様です。返す相手も、困っているお客様だと考えて回答しています。CSと開発は、得意なスキル、いわば「パラメーター」が違うだけで、誰に価値を届けるかは同じです。フォーマットは両者が話しやすくするためのもので、その上で各部署が、自分たちに合う仕事の形を探しています。

―CSとの連携以外でも、やり方を変えることはありますか。

　大小さまざま、わりと変わります。「これ問題だよね」となったその場で関係者が認識を合わせて決めるパターンが多いですね。開発の中なら当人同士ですぐ決まりますし、部署をまたぐ場合も上長に話を通したうえで、Slackに流せば反応があります。合理的だとなれば、そのやり方が採用されます。

―リリースした後、プロダクトを育てていく場面には具体的にどんなものがありますか？ 

　例えば、利用者や登録データが増えて遅くなった機能の改善ですね。「昔はそのやり方でよかったけれど、今の規模には合わなくなった」という時は、画面や仕様は変えずに「作り」だけを変えます。まずエンジニアがデータを計測して提案し、木下さんも含めた開発メンバー全員で見る。インフラは江口さん（テックリードの一人）というように、それぞれが得意な領域から意見を出します。

　新機能なら、PMがまとめた要件をもとにデザイナーがデザインを、エンジニアが設計を起こし、製品ごとのチームでレビューします。難易度が高ければ、テックリードにもレビューを頼みます。

―得意な領域が違うメンバー同士が一緒に議論しているのですね。一方で、トヨクモのエンジニアは「フルスタック」が求められるとも伺いました。

　フルスタックであることはもちろん望ましいですが、常に一人で全部やる、という意味ではありません。フロント、サーバーサイド、インフラを広く浅く知っていて、新しい話を聞いても「聞いたことはある」と会話ができる。その上で、どこかに特化した強みがある状態です。全体が見えているから、フロントから逆算してDBを組んでもいいし、その逆でもいい。その時々で効率のいいやり方を選べるのが、フルスタックのメリットだと思います。お互いのレベル感がわかっているので、前提から説明し直す必要もありません。

　この製品が得意だからこれしか見ない、ということもありません。ほかの製品も自分から見に行って知見を得る。会社としても推奨されている姿勢です。評価にも表れていて、月間・年間MVPは契約金額や契約数だけでなく、リリースした機能や製品の価値、その達成の難しさも含めて決まります。

 　一番コミュニケーションコストが高いのは、何も知らない領域で、何を聞けばいいかもわからない状態です。浅い知識があれば、それをとっかかりに「私はこう理解していましたが違いますか」と聞けるし、自分で調べることもできる。新聞を流し読みする程度でもアンテナを張っておけば、キーワードにフックがかかるんです。

―その知識を使う上で、意識していることはありますか？

　「自分の知識は浅い」という前提に立つことです。とっかかりだけで突っ込むと危ない。設計や実装で必要になったら、何か起きたときに何が起きているかわかるレベルまで、知っていることを足がかりに調べます。

　入社後に特に深めたのは、アーキテクチャやモジュールの切り分け方です。自分たちで書いたコードを自分たちで読み返す機会が多いので、運用を踏まえた読みやすい設計の方法論を集めるようになりました。

―一人ひとりがそうして自分で調べ、判断していく。その前提として、何があると思いますか？

　木下さんやほかのエンジニアとの信頼があって、「この人はこういうふうに対応できる」とわかっているから任せられる。任された側は、このポジションでこれを任されているのだからベストを尽くして応える。その責務が、自律できることの前提になっていると思います。

―トヨクモのエンジニアに求められるのは「自律的な成長」ですが、具体的にどんなことが大事だと思いますか？

　「興味を持てること」だと思います。勉強しようとしてするより、知りたいから調べる。リリースが優先ではありますが、作業の中で出会った技術に興味を持ったら、直接関係なくても放置せず調べてみる。それがなくなると、エンジニアとして厳しくなると思います。

　私自身は「なぜ」を掘るタイプで、この関数は実際に何をしているのか、突き詰めれば0と1の上に何が積み重なっているのかを知るのが純粋に楽しいんです。ただ没頭しすぎると仕事が進まないので、プライベートの時間で調べています。

―8年目の今も、仕事の進め方は変わり続けていますか？

　お恥ずかしい話、まだ全然ベストにはなっていません。ここ数年でAIが当たり前になり、仕事の進め方そのものを試行錯誤しています。1on1でも毎回「今回この作業をAIでやったけど、ここがよくなかった」と話していて、一回でうまくいくことはほぼありません。だから次はこうしてみよう、と改善を続けている。どんなコードを書くかだけでなく、どう仕事を進めるかも変え続けています。

―試行錯誤しながら技術を磨き続ける姿は、職人の世界にも通じるように感じます。

　職人さんは、傍から見るといつも同じことをやっているように見えますよね。でも実は、小さな改善の積み重ねで進歩している。傍からはわかりにくい小さな改善を積み重ねている、という点は似ているかもしれません。

―最後に、かつての山口さんのように「自分ならもっとできるのに」と感じているエンジニアへメッセージをお願いします。

　コントローラブルな環境が自分に向いていると思う方は、来ていただければ仕事がしやすいと思います。「お客様が言う通り」に進めるのがつらい方ですね。自分たちでコントロールして、お客様により良い価値を届けたいと考えられる方が来てくれたら、私たちも嬉しいですね。

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

【最後に】

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

今回は、SIerから自社プロダクトの開発へ移った山口さんのお話をお届けしました。

お話から見えてきたのは、PLG構造において技術者が判断し、部署間の境界も現場が自ら引き直してきたことで、判断を仰ぐための確認や調整に使っていた時間が、プロダクトを育てる時間に戻っているということです。そして、その自律を支えているのは、任された信頼に技術で応える責務と、「なぜ」を掘り続ける好奇心、そして傍からは見えにくい小さな改善を愚直に積み重ねる、職人のような姿勢です。

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

次回は、成果が見えにくい場所で守るべき品質の水準を自ら決め続け、kBackupを7年守り抜いてきたエンジニアへバトンを繋ぎます。

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

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

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

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

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