認められた延期、取り下げた延期。 判断を分けた「ユーザー価値」

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

今回お話を伺ったのは、現在Toyokumoアカウント領域とkintone連携製品の開発を担当する高坂さんです。石油・天然ガス開発のエンジニアからソフトウェアの道へ転身し、受託開発会社を経て2022年にトヨクモに入社しました。
細かな承認を待たずに任される自由と、その裏にある責任、そしてトヨクモで求められる「自律的成長」の中身をお伝えします。

―1社目はまったく違う業界だったそうですね。

　新卒で石油・天然ガスを開発する会社に入り、生産エンジニアとしてプラントの管理や事業性の検討をしていました。プロジェクトが数十年単位で動くので、どの段階に関わるかで経験が決まってしまい、自分でキャリアを描きにくいと感じていました。1年かけた調査が形にならないことも何度かあり、自分の仕事が何につながっているのか見えにくかったんです。

　そんな時、興味本位でソフトウェアを学び始めたら、これが楽しくて。土日も夢中で勉強しました。作ったものを直接ユーザーが使ってくれる。その手応えに惹かれて、転身を決めました。

―2社目は受託開発の会社でしたね。

　小さな会社で、お客様の業務課題を解決するWebアプリケーションの開発や保守、サーバーのリプレイスなどを約2年担当しました。AWSのまっさらなインスタンスにデータベースやランタイム、メール転送などの仕組みを手動でインストールして設定し、バッチ処理のスケジュールは直接サーバーのファイルを書き換えて設定していました。今なら意識しなくていい部分まで手を動かして作った経験が、「裏側で何が動いているか」を想像する力の土台になっています。トラブルの時も、どこに原因がありそうか、どんなログが残っているはずかと当たりをつけられるんです。

―転職を考えるようになったのは、なぜですか？

　僕がいた受託開発の会社では、「合意した要件を約束の期日に届けること」に価値が置かれることが多かったんです。その構造の中では、「新しい技術の採用は納期が延びるリスク」とみなされることがよくありました。例えば、Vue.jsやReactでフロントエンドを分離する構成は、今ではごく一般的です。ただ、採用するには書ける人材を育てるコストがかかり、社内に実績のない技術では開発期間も見通せません。そのため、実績のあるPHPでのマルチページ構成を使い続けていました。会社としては合理的な判断だったと思います。ただ、「もっと世の中の技術を知りたい」という気持ちとのギャップは広がっていきました。このままでは成長が止まるという焦りから、転職を決めました。

―トヨクモに入社してみて、どうでしたか？

　最初は学ぶことだらけでした。僕にとって、既存のコードはすべてが教材で、周りのエンジニアが共有してくれる技術の話にも刺激を受けていました。とにかく追いつこうと必死に吸収しましたね。扱ったことのない技術に挑む機会も多くありました。トヨクモの製品で最初のパスキー認証の開発を、テックリードの支援を受けながら担当したこともあります。

―リリース日について、前職とトヨクモで捉え方に違いはありますか？

　前職の受託会社でのリリース日は、お客様との契約で決まった「動かせない締め切り」でした。トヨクモには、厳密な意味での締め切りはないと僕は認識しています。

　まずタスクの担当になると、「デザインドック」で定義されている機能としてのゴールが決まった状態からスタートします。それをどう設計し、どうタスクに分解し、どんな段取りで進めるか。その上で「この日にリリースできそうです」とエンジニアが自分で組み立てて提案するんです。新機能による価値を効果的にユーザーに届けるために、機能のリリースには営業など、多くの部署が関わります。リリース日は「全社が足並みをそろえて動くための目標日」なんですね。

―では、遅れても構わないということでしょうか？

　いえ、そうではありません。目標日に間に合わせることは当然重要です。ただ、それが絶対的なゴールかと言うと少し違います。ゴールは「ユーザーに価値を届けること」なので、開発中に考慮漏れや既存機能への影響が見つかれば、ユーザー体験や品質を優先してリリース日を調整することがある、ということです。

　もちろん、のんびりやっていいわけではなく、理由が合理的でなければPMにリリース計画の見直しを求められます。ユーザーに価値を感じていただける単位でスコープを区切り、リリース日を延期するのではなくステップを分割するという判断をすることもあります。つまり期限は、「外から与えられて守るだけのもの」ではありません。ユーザーに品質のよいものを届けることを軸に組み立てる、全社がリリースに向けてスムーズに動けるための基準だと捉えています。

―リリース日を調整した、具体的なエピソードを教えてください。

　kViewerに「編集者」という権限を追加した案件（新しいタブで開きます）です。kintone連携製品はこれまで、複数人で使いたいというニーズがあっても、それに応える仕組みがありませんでした。そのため、1つのメールアドレスを複数人で共有して使うケースが多く、問題が起きた時に誰が操作したのか区別できないという課題がありました。そこで「ユーザーライセンス」という仕組みを導入して、1人1アドレスで使えるようにしました。さらに「管理者」に加えて、割り当てられた範囲だけを扱える「編集者」を追加しました。

―開発中に、何が起きたのでしょうか？

　リリースの2週間ほど前に、FormBridge（新しいタブで開きます）との連携の仕組みが自分の想定と違っていたことに気づきました。サービス品質を保証するには連携の仕組みを直す必要があったのですが、直すと連携設定画面の表示がkViewer側の権限によって変わるようになります。そして、その状態をユーザーにどう伝え、どう解決してもらうかというUIの考慮が抜け落ちていました。例えば、他の人が設定した連携を、その連携先を見る権限のない人が開くと、連携の情報が表示されるはずの場所がブランクになってしまう。エラーメッセージも出ないので、ユーザーからすると急に画面が壊れたように見えて、「何が起きているのか」「どうすれば解決できるのか」が分からなくなる状態が起こると判明しました。

―どのように対応したのですか？

　愚直に、連携表示パターンを洗い出して表にしました。操作する人がオーナーか、管理者か、編集者か、ライセンスを持っていないか。それに、他の人がすでに設定済みかどうかを掛け合わせて、8パターンほどです。その上でデザイナーとPMに同時に相談し、ユーザーが状況を理解できる見せ方をパターンごとに詰めました。バックエンドで返す情報も変える必要があったので、リリースを1週間ほど延ばしました。

―延期の判断基準は何だったのでしょうか？

　多少使いにくい程度なら、予定どおりリリースして後から直せばいい場合もあります。でも今回は、ユーザーを迷子にしてしまう状態でした。権限まわりは後から直しにくく、使い勝手にも直結します。だから、ここでリリース前に作り切ることを優先しました。延期はロードマップを共有するチャンネルで理由を添えて報告し、了承をもらいました。

―他に、リリース日の延期を検討したことはありますか？

　最初に行ったデータベース設計が、新たに追加された仕様に対応しにくい構造になっていたため、リファクタリングしたいと申し出たことがあります。データベース層の制約を活かせるテーブル構造に移行しようと考え、リリース日の延期を提案しました。

　ところがPMから「それは本当に今やるべきことですか」と問われ、考え直してみると、アプリケーション層で制御すれば十分な要求でした。ユーザーに価値を届けることより、ソフトウェア設計の綺麗さを優先した、いわばオーバーエンジニアリングだったんです。そこで延期をやめることにしました。その後も問題は起きていないので、延ばさなくてよかったと今は思っています。

―トヨクモでは、仕事の担当はどのように決まるのでしょうか？

　今後取り組むロードマップタスクは、半期の最初にPMから共有されます。ただ、誰がやるのか、どうやるのかを上司が細かく指示することはありません。手を挙げるのも自分、やり方を決めるのも自分です。誰も経験したことのない領域なら、自分で調べ、テックリードのレビューやアドバイスを受けながら設計を決めきります。レビューは受けても、最終的に品質の高いものを完成させ、その面倒を見ていく責任は自分にあります。

―正解がない中で設計を決めきるのは、どう感じていますか？ 

　答えを自分で見出すのは正直難しいと感じています。でも、会議や合意形成のプロセスがほとんどないぶん、力を発揮しやすい。僕にはこのやり方が合っています。困った時はテックリードに相談できますし、リリース日の変更のような大きな判断にはPMの目も入ります。ただ、やり方を全部教えてもらえるわけではないので、判断の拠り所は自分で持つ必要があります。タスクごとに、ユーザーにとっての価値は何かを考え続けることになります。

―仕事を進める上で、大切にしていることはありますか？

　判断の経緯を残すことです。ユーザーライセンスのうち、kViewerの「管理者」権限は僕がほぼ1人で実装していて、気づけば「この機能を知っているのは自分だけ」という状態になっていました。これは危ない、と思いました。

　そこで「編集者」権限からはチームを巻き込み、設計判断をドキュメントにして共有し、開発メンバーが経験したことのない技術については小さな勉強会も開きました。メンバーが開発できるようになると任せられる範囲が広がり、結果的にリリースの遅れも防げました。貴重な開発経験を自分だけで抱えず、チームに分けられたのもよかったです。

―共有の意識はどこから来ているのでしょうか？

　1社目で、前任者が辞めると経緯が分からなくなる経験をしたからだと思います。後から入る人が困らないよう、暗黙の前提は作りません。そもそもそういうコードを書かないように心がけ、どうしても必要な時はコメントを残すようにしています。

―高坂さんにとって、自律的成長とは何でしょうか？

　自分から手を挙げて、正解が決まっていない中でも「これならいける」というやり方を考えて段取りを立て、責任を引き受けて最後までやり遂げる。その繰り返しだと思います。リスクを負いながら一つずつ形にしていくと、任せてもらえる範囲も広がっていくんです。

―任される範囲は、どのように広がっていきましたか？

　大きな仕事を任せてもらうには、「この人なら途中で投げ出さない」と信頼してもらう必要があると思っています。だから入社してからは、自分が直接担当していない機能も自分ごととしてアンテナを張り、自分でも開発・保守できる範囲を広げていきました。

　そうして任されたのが、kViewerのリストビュー（新しいタブで開きます）のデザイン刷新です。それを最後までやり切れたことが、kintone連携製品全体にまたがるユーザーライセンスの開発につながったのだと思います。チーム間で連携しながら進める必要がある仕事で、コミュニケーションを取りながら進めた点を評価していただいたと受け止めています。

―評価や報酬についてはどう感じていますか？

　評価では足りない部分のフィードバックももらいます。その上で、製品やチームをまたぐ仕事を最後までやり遂げること、そしてメンバーの成長を後押しすることを期待されていると感じています。報酬は、正直想像以上に上がっていて驚きました。今の立ち位置は逆算して狙ったものではなく、日々の積み重ねの結果です。

―今後の展望を教えてください。

　ものを作ることは今も好きです。その上で、一つの技術を深掘りするより、技術をどう組み合わせて適切なものを選び、作るかというアーキテクト的な意思決定に携わっていきたいと考えています。あわせて、周りを巻き込みながら、チーム全体でレベルアップしていけたらうれしいですね。

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

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

【最後に】

今回は、kintone連携製品全体にまたがる機能開発を担う高坂さんに「任される現場で、エンジニアは何を拠り所に判断し、何に責任を負うのか」について伺いました。

トヨクモの「自律」とは、「自分の判断に理由を持つこと」です。期限を延ばすか延ばさないかもユーザーの価値で決め、その経緯をチームに残す。そうして任される範囲を広げていくことが「自律的成長」の形の一つです。

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

次回は、前職では相談相手がいないまま仕事を巻き取っていた状態から、「デザイナーの思考に触れながら作る」働き方へと変わったエンジニアへバトンを繋ぎます。

どうぞお楽しみに！

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

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

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

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

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