スピードを支えるのは、「小さいリリース」と「開発に集中できる環境」

スピードを支えるのは、「小さいリリース」と「開発に集中できる環境」

三須/細川
開発本部

三須/細川

Misu/Hosokawa

■語り手プロフィール■ (左)三須:エンジニアとして広告系ベンチャーやIoTスタートアップ、SaaSなど様々な企業で勤務。2024年4月トヨクモに中途入社。現在は「PrintCreator」担当。 (右)細川:新卒でメーカーの事務系総合職として入社し、その後未経験でエンジニアに転身。不動産DX企業やアプリケーションの受託開発企業で勤務。2024年1月トヨクモに中途入社。現在は「PrintCreator」担当。

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


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

前回の原さんのお話にあった「自分で工数とリリース日を決める」という働き方やスピード感は、どんなチームの上に成り立っているのか。今回のPrintCreatorチームの細川さん・三須さんのインタビューを通して、開発組織のリアルをお届けします。

1.デザイン以降は、全部エンジニアが「決める」

―簡単に自己紹介と、いまPrintCreatorチームで担当されていることを教えてください。


細川:PrintCreatorでフロント〜バックエンド、インフラを担当しています。入社直後は「電子契約」という大きな機能に取り組みました。その後の新機能については設計からリリースまで担当しています。直近はAIによるフィールド情報の追加や自動配置、監査ログの導入にも対応しています。

三須:細川さんと同じく「電子契約」関連を担当しました。その後は「電子契約」まわりの追加機能の実装や、直近ではユーザーライセンス関連の機能追加などの対応をしています。


トヨクモでは「1機能(※)を1人でやりきる」という開発スタイルですが、実際、ご自身で決めている範囲はどこまでですか?

※1製品の中の1機能のこと。

細川:基本的には、デザインドック(仕様)はPM兼CTOの木下さんが書き、それを元にデザイナーがデザインを作り、それらを見て自分たちが設計して実装していきます。デザインができて以降のことはすべて自分でやります。「どういう方向で実現するのか」を設計し、レビューに出し、技術選定も含めて全部考えます。

エンジニア1人1人の裁量が大きいですね。フルスタックで開発することについてはどうですか?

三須:前職はバックエンドがメインでフロントがあまりなかったんです。でもトヨクモはフルスタックなので、開発できる技術の範囲が広がったのはすごくいいところだと思います。

細川:トヨクモで全部担当できるのは嬉しかったです。とはいえ最初は製品の全体像を把握できていなかったので苦労するところもありましたが、個人的な成長にはつながったと思います。

担当範囲が広いと、お客様の課題への解像度も変わってきそうですね。お客様の課題感を知るのはどんな時ですか?

細川:お客様の要望はkintoneのアプリで随時共有されているので、こちらを見ればすぐに知ることができます。最近では、トヨクモフェス(※)に初めて参加して、ユーザーの声を直接聞けたことが大きかったです。自分たちでは気づかなかった使いづらさに気づける場でした。

三須:あと、PMが書くデザインドックに根拠となるユーザーの声が提示されているので、「お客様の要望があって、こういう手段で実現しようとしているのか」と理解できますし、ユーザーの要望も印象に残りますね。

※トヨクモフェス:「kintone」とトヨクモ製品を連携させた活用事例や、業務改善のノウハウを共有する年に一度の大型カンファレンス。


2.1人でやりきる。でも、1人で抱えない。

入社間もない頃の「電子契約」機能は、PM木下さんが仕様、テックリード江口さんが設計、お2人が実装、という流れだったと伺いました。

細川:入社して数か月の頃なので、大きなスケールの設計を見て「江口さん、これ一人でやったんだ!」と驚きました(笑)。仕様も複雑だったので理解が非常に難しく、画面でどういう動きになるのかを確認しながら設計も見ていく、というのがすごく大変だったのを覚えています。

三須:リリースまでの道筋がフェーズごとに区切ってあって、開発の順序まで気にしてくださっていてやりやすかったですね。

セキュリティ上の制約も厳しい機能を、半年で実現できた要因はどこにあると思いますか?

細川:設計がすごくしっかりしていたからですね。さらに、当時は自分と三須さんと他2人の4人が中心だったのですが、お互いが何をしているか常に分かる状態で作業していました。おかしなところがあればすぐ共有し、修正に取り掛かる体制だったんです。なので不具合や設計上の考慮漏れがあっても、割とすぐ修正できました。そういったことからも、江口さんの当初の見積もり通りリリースできたんだと思います。

―この「電子契約」の後は、1機能の設計から1人で担当するようになったんですよね。

細川:自分の設計の時も、「どこを考慮すればよいか」「何を書けばよいか」と、よく立ち返り、事前によく考えた上で進めています。このあたりは「電子契約」の設計を参考にすることが多いです。

三須:設計ができたら、いったんチーム内でレビューし、その後にテックリード江口さんにレビューしてもらいます。すんなり通る場合と通らない場合がありますが(笑)。

―お互いにレビューし合う時、実際はどんなやりとりになりますか?

三須:PR(Pull Request)は基本的にチーム内で見ます。細川さんに出すこともあれば逆もありますし、「このあたり詳しそうな人」で振ることもあります。

細川:1つの機能をリリースする際は、チーム全体で動作確認します。インフラ構成の変更など、テックリードの判断が欲しいものは江口さんに見てもらうことが多いですね。

―江口さんからのフィードバックで、印象に残っているものはありますか?

細川:「PRを出すときに、レビュアーのことを考えたPRになっているかを考えて」と言われたことですね。「コミットの量が適切か」「読みやすい順番になっているか」とか。PRを出す側の怠慢でレビューする側の負荷になるのはよくないです。負荷が増えると品質が下がるし、時間もかかります。逆にそこを意識すればスピードも品質も上がるんです。

三須:私は、自分が考えた設計へのフィードバックで「ユーザーがこういう操作をしたらこうなると思うけど、そこの考慮ってどうなってますか」という指摘を受けたことを覚えています。その時は確かにそのケースが考えられていなかったなという、「しまった!」という感じでした。

―「1人で1機能をやりきる」と聞くと大変そうにも思えますが、実際はどうですか?

細川:設計の段階でどうしようかなとなった時に、江口さんに相談することはよくあります。逆に江口さん側から来てくれることも多いですよ。Slackで軽くつぶやいたことにも反応してくださるので、それで助けられることはすごく多いです。

三須:設計以外でも、「こうしたほうがチームの生産性が良くなるんじゃないか」ということがあれば相談します。自分から相談しに行くことは多いですね。江口さんは社歴も長いので、その機能が生まれた背景などを聞くこともあります。

3.承認もミーティングも、ないに等しい~「小さいリリース」と「開発に集中できる環境」~

―トヨクモにおける「リリースまでの承認フロー」はどのようなものですか?

細川:承認フローはないに等しいです。開発中の都度のレビューと、最終的なリリースのタイミングでチームで動作確認をして、デザインはデザイナーに動きを見てもらってOKとなれば出せる。テックリードやPMに承認をもらってOK、という承認フローはないんです。

三須:前職も承認はありませんでしたが、スクラム開発だとプロダクトオーナーの確認がありました。トヨクモはそれもなく、エンジニアとデザイナーで確認作業ができたらリリースしていきます。

―「承認フローはないに等しい」というのは、どうして成り立っているのでしょうか?

細川:こまめにリリースしているので、影響範囲を把握できているんです。なので、関係が薄い方の承認が要るのか要らないのかも、自分たちで判断できます。何かあっても原因が明確になりやすいので、戻すなり、少し修正するなりの判断もつきやすいですね。

三須:細かくリリースしていくので、自分のタスクもなるべく小さく計画するようにして、どんどんリリースできるようレビュー&マージしています。

―しかし新しい機能は、どうしても大きなリリースになりませんか?

細川:確かに新しい機能を出すとなった時、機能単位で見るとどうしても大きなリリースになります。そういう時は、たとえばバックエンドだけ先にリリースします。フロントエンドの新しいページも、導線は出さずにソースコードだけ先に本番環境に出して運用し、何かしらの相互作用でバグが出ないか、を確認します。「最後にバグがドンと出てくることがないように」というのは、PrintCreatorだけでなく他の製品のエンジニアも意識してやっていると思います。(アンチ・ビッグバン的開発)

―頻繁にリリースすること自体が難しいのではないでしょうか?

細川:会社によっては一度のリリースにすごく手間や時間をかけているために頻繁にリリースできない、という事情もあるようです。しかしトヨクモの場合はCI/CDの環境が整っているので、リリース自体に時間と手間がかからないのだと思います。

―そこまでして小さく速く出すことに、どんな意味があると感じていますか?

細川:SaaSで、PLGというビジネスモデルなので、製品自体に魅力がないとなかなか広まっていかないんですよね。良い機能や良い体験になるような改善はいち早くリリースしたほうが新規の契約にもつながるし、既存ユーザーにとっても有益で、結果として売り上げにもつながると考えています。

―トヨクモが掲げているバリューである「スピード」が実現できているということですね。その最も大きな要因は何だと思いますか?

細川:「PRが出たら早くレビュー」「マージされたらすぐリリース」というのを、みんなで協力してできていることですね。あとはAIで開発スピードが上がっているのもありますね。また、外的要因によって阻害されることもありません。開発以外の理由で「リリースを早める」「逆に待つ」ということがないんです。「お客様からのバグ報告」があればそれを優先することはありますが、それ以外の外的要因で対応順位が変わることはないですからね。

―開発そのもの以外に時間を取られることがない、ということでしょうか?

三須:ミーティングもほとんどないですしね。

細川:QAによるプロダクトの確認作業もないので、そのためにエンジニアが説明する時間も要りません。チームで動作確認までやってしまうので。

三須:あとは、つまずいたことや調べたことをSlackのチャンネルに書けば、すぐに誰かが巡回で見に来てレスをくれる文化があって、知見が残っていくので、聞き回る手間もありません。

4.自分で決めた期日を、自分で引き受ける

―リリース承認もなく、外から急かされることもない。逆に不安になることはありませんか?

細川:自由にやれる環境には責任も同時に伴うので、任されているからこそ、良い仕事ができているのかなと思います。最初は不安もありましたが、スピーディーにリリースできるのは開発する側としては気持ちが良いですし、ストレスではないですね。

―工数の見積もりが合わなかったことはありますか?

三須:AIを使った最初の開発では、一発で合格するコードが出てこず、余計に時間がかかってしまったことがありました。原因は、AIのアウトプットがトヨクモで定義しているコーディング規約と合っていなかったことでした。そのため、次の開発が始まる前にプロダクト内のコードで規約に合っていない部分を合う形に修正し、AIのアウトプットが意図したものになるようにしました。

この件は2週に1回のKPTでも話したところ、江口さんから「自分が担当の製品では起きていないから、もしかして製品内のコードで規約に沿っていないところを参照して、意図しないアウトプットになっているんじゃないか」といった指摘をもらいました。KPTの機会を使って、他のプロダクトの知見を引っ張ってきて自分の開発に活かしています。

―AIを前提とした開発を見積もると、不確定要素を含んだ見積もりになると思います。この点で工夫していることはありますか?

三須:人間のレビューと一緒で、AIのアウトプットに対して自分でレビューして、細川さんにもレビューしてもらい、不足部分をAIへの指示に加える、という最低限のことはやるようにしています。

細川:AIが出すアウトプットは冗長だったり分量が多くなりがちなので、できるだけ小さい単位で、レビュアーが見やすい量でPRを出すようにしています。説明も過剰になりがちなので、分かりやすくシンプルに、レビューに時間がかからないように心掛けていますね。

―一番時間をかけている工程はどこですか?

細川:設計に一番時間をかけています。シフトレフトの考え方ですね。「実装の段階で見つかるより、上流の設計の段階で考慮されていたほうが、手戻りが発生した時に少ない修正で済む」と考えています。

―この開発サイクルを維持していくうえで、いま課題に感じていることはありますか?

細川:課題として感じているのは、AIでスピードは上がっているけれど、レビューがボトルネックになることです。実装は3つ同時にすぐできても、レビューは1つずつ。どうしてもレビューが相対的に遅くなります。そこをいかに「スピード感を持ってやれるか」なんですが、PRの内容を図解してくれるなど、レビューを助けるプラグインをAI側に導入し始めたので、スピードは上がってきてはいますね。

三須:私は、AIに最初から正解を出してほしいので、そこをどうするかが課題ですね。AIとのやりとりも、レビュアーとのやりとりも減らしたいですしね。

―最後に、どんな方と一緒に働きたいですか?

細川:分かりやすく言うと「協調性があること」ですね。チームで開発していくことが前提なので、1人でガンガンやっていきたい人、自分のやり方にこだわりがある人は大変かもしれません。細かい単位でスピーディーにリリースしていくには、チームの協力が必要ですからね。

三須:1人が1機能の開発を進めることがほとんどなので、オーナーシップがあり、自分がやっていることに責任感を持てる人がすごく合うと思います。そういう人にぜひ来てほしいですね。「1人が1機能を全部やるから大変そう」というよりは、それをやりがいに思える人と一緒に働きたいなと思います。

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


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

【最後に】

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

今回は、「1人1機能開発」のリアルなエンジニアの声をお届けしました。

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

次回は、細川さんのお話にもあった「レビューを助けるプラグイン」などでメンバーのスムーズな開発をサポートするテックリードへバトンを繋ぎます。

どうぞお楽しみに!
************************************

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

応募はこちらから

開発本部全体の情報はこちら

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


この記事をシェアする

この記事に関連する求人情報

採用情報を見る