リリース178日停滞からの脱却。入社2カ月のエンジニアが主導し、チーム全員で磨いた開発の仕組み

新卒でヤフー株式会社に入社し、もともとはデザイナーとしてキャリアをスタートしました。実際に担当していたのは、デザイナーというよりマークアップエンジニアに近い仕事で、そこからフロントエンドの領域へとキャリアを広げていきました。以降、複数社を経て現在はカオナビに在籍しています。

教員免許を所持していることもあり、もともと「教育や社会貢献性の高い仕事に携わりたい」という強い思いがありました。一方で、eコマース分野の開発などを通じて、ビジネス性の高いサービスをつくる経験もしました。ただ当時の私は「社会貢献性の高い仕事をしたい」という思いが強く、数値達成にコミットする姿勢を素直に受け止めきれずにいました。

その後、前職での経験を通じて考えが変わり、「収益性やビジネス面まで意識したプロダクト開発に取り組みたい」と思うようになりました。そこで出会ったのがカオナビです。

かつてeコマース事業に携わっていたときの経験です。デザイナーも含む開発メンバー全員が徹底して数字を意識し、事業に向き合っていました。その姿勢を当時は素直に受け止められず、その反省が、今の考え方につながっています。エンジニアがつくったものも、実際にユーザーに使われたり、購入されたりしなければ、企業のなかでつくる意味が薄れてしまいます。自社が掲げる目標を理解し、事業の成長に貢献するところまで意識することは、会社員として働くうえで重要だと考えています。

経営やビジネスの視点を持ってものづくりができる人ほど、さまざまな組織で必要とされると私は思っています。過去の同僚や先輩方から刺激を受けた経験もあり、私自身もそうした視点を身につけたいと考えるようになりました。

バリューに掲げられている「誠実さを大切にする」という言葉に惹かれたことが大きかったですね。これまでの経験の中では、お客様よりも社内の事情が優先されていると感じる場面もありました。そのため、お客様の声を直接聞きながら、誠実なものづくりに取り組むカオナビに興味を持ったのです。

2025年10月にフロントエンドエンジニアとして入社し、現在はテックリードを務めています。

プロダクトをつくることが前面に出過ぎてしまう態度は不誠実だと捉えています。その態度を持っていると開発そのものが目的化してしまい、お金の流れやリソースとのバランスといったビジネス視点が失われてしまうためです。 どれほどリソースを投じても、事業成長や収益という価値につながらないのであれば、それはつくり手のエゴに過ぎません。

カオナビの誠実さは、顧客の声を聞く姿勢と、自分たちの事業軸の両方が確立されている点にあると思います。現在所属するチームでは、積極的にお客様のもとへ足を運び、寄せられた意見に真摯に対応しています。全社的にも、ミートアップなどを定期開催し、ユーザーとの対話の機会を重んじています。

単に要望をそのまま受け入れるのではなく、「どのようなプロダクトやビジネスを展開したいのか」という自社の軸を明確に持ちながら開発を進める。相手の意見を聞きつつ、自分たちの足元を見つめて意思決定を行う文化に、カオナビらしい健全な「誠実さ」を感じています。

いえ、入社後2カ月間は別のチームに所属し、カオナビの開発体制やプロダクトへの理解を深めることに専念していました。その後マネージャーから声をかけていただき、チームを異動しました。オンボーディングを通じてフロントエンドの技術面を評価いただき、テックリードとしてチームを牽引する役割を期待されての配属だったと受け止めています。 異動後の主なミッションは、停滞していたリリースサイクルを短縮することでした。単にエンジニアとして開発を担うだけでなく、プロダクトを迅速かつ高品質に届けるためのプロセス改善や課題解決など、一歩踏み込んだ働きを求められていると感じました。

リリースが178日間止まっている状態でした。実際に入ってみると、致命的な混乱はなかったものの、チーム内に「自分たちは成果を出せていない」と自らを責める空気が漂っていました。

一方で、メンバーは全員が「何とかしたい」という思いを持っていました。リリースできる単位まで案件を小さくしたり、コミュニケーションを改善するためにチームを分割したりと、すでにさまざまな工夫が行われていました。

それなのに具体的な打開策が見つからない状態だったのです。さらにはスクラム開発の運用が空回りして、アジャイルコーチから指摘を受けることも多く、ネガティブな空気が生まれていました。

メンバーから反発が起こる可能性は考えていたので、コミュニケーションは慎重に取っていました。ただ、もともとチーム内で意見を活発に交わす文化があったわけではなく、対話そのものが不足していると感じていました。

アジャイルコーチから問いかけがあっても、発言が出てこない場面が少なくありませんでした。そこで、まずは私自身が積極的に意見を述べるようにしました。そのやり取りを重ねる中で、メンバーにも私の意図や考えが伝わり、改善案について話しやすい雰囲気ができていったのだと思います。

ありがたかったのは、PdMの土井さんが非常にオープンに受け入れてくださったこと。チームのメンバーも含め、配属直後から私の意見を受け入れてくれる環境があったので、とても動きやすかったですね。自分一人の力でチームを変えたというより、周囲に受け入れてもらえたからこそ動けたのだと感じています。

主に「スモールリリースの推進」「リファインメント（仕様策定・認識合わせ）の改善」「バックログ（優先順位）の階層整理」「デイリースクラム（朝会）の運用見直し」の4点に取り組みました。

・スモールリリースの推進

開発規模を小さくすることでエンジニアの思考負荷を下げ、リリースサイクルを早める狙いがありました。完璧な状態で一括リリースを目指すのではなく、Webサービスの強みを活かして小さな単位で素早くリリースし、順次アップデートしていく意識へ切り替えました。

・リファインメントの改善

「なぜこの案件をやるのか」という背景を、開発者が理解したうえで取り組める状態をつくる狙いがありました。目的を理解していれば、要件を実装に落とし込む際にも「より簡易な実装方法がある」といった技術的提案が可能になり、結果として、開発速度も、つくるものへの納得感も高まります。

・バックログの階層整理

案件ごとの目的が明確になれば、優先順位も判断しやすくなります。「この機能はお客様のどの課題につながるのか」「今これを届けないと、お客様の課題が解消されないままになるのではないか」といった観点で議論できるようになるからです。PdMが目標に対する責任を持ち、チーム全体でその方向性を理解して支える。そうした一体感をつくることを意識して、取り組むべきタスクの優先順位を階層で整理し、可視化しました。

・デイリースクラムの運用見直し

メンバー同士の朝会で進捗報告を行う際、以前は「人」ベースで「私は今これをやっています」と報告していました。しかし、それでは1つのタスクに複数人が関わっていても横の連携が生まれにくいうえに、停滞したときに個人の責任のように見えてしまいます。そのため、「事（タスク）」ベースで「今どういう状況なのか」を確認する形に変更しました。

理由は、メンバー個々の技術水準が高く、停滞の原因は実装速度ではなく仕様の不確実性やタスクの未整理にあると見立てたからです。コミュニケーションの摩擦と仕組みの不備を取り除けば自ずと進展すると判断し、配属後の数カ月はコードを書くこと以上にチームの仕組みづくりに専念しました。

当時のチーム内では「開発がスムーズに進まないのは、正しいスクラムを実践できていないからだ」と捉えている部分があり、いわゆる「正しいスクラムの型」をなぞることに意識が向いていました。

例えば、開発の成果をステークホルダーに共有し、フィードバックを得る「スプリントレビュー」もその一つです。もちろん、本来はプロダクトを改善するうえで有効な場です。ただ、そこにリソースを割くよりも、まずはリリースすることを優先すべきだと考え、思い切って「今のフェーズでは、スプリントレビューを一度止めてもいいのでは」と提案しました。

大切なのは「スクラムを正しく実施すること」ではなく、「目的を達成するためにスクラムをどう活用するか」。その時点で本当に必要なものは何かを考え、柔軟にプロセスを変えることが重要だと考えています。

朝会については「一度、自分がファシリテーションを担当して進め方を変えてみてもいいですか」と提案し、その場で変更しました。リファインメントやバックログの整理など、より根幹に関わる部分については、PdMに相談しながら進めました。

最初に相談を持ち掛けたのは、チームに入って1カ月も経っていない頃だったと思います。当時はチームを2つに分割しようと試みていた時期で、相互の連携が不十分になりがちな状態でした。ちょうどその頃、お客様から重要なご指摘をいただき、最優先で対応する必要が生じていました。

そこで「一度チームを1つに戻し、全員のリソースを集中させましょう」と提案したのです。メンバーはすぐに納得して、一致団結して対応してくれました。

そのとき改めて感じたのは、「個々の自走力や技術水準が非常に高いチームだ」ということです。方向性さえ明確になれば、短期間で開発を進め、リリースまでつなげられる。だからこそ、メンバーが力を発揮しやすい環境を整えることが重要だと考えました。

はい、皆さん非常に協力的でした。特に、同じフロントエンドエンジニアで年代の近いメンバーが、私の考えを理解して背中を押してくださったことが印象に残っています。熱が入りすぎたときには「もう少し緩やかに伝えたほうがいいですよ」と客観的な助言もいただき、とても心強かったですね。

また、基盤を整えた後は、皆さん自律的に動いてくれました。私自身がすべてを実行するのではなく、チーム全体が動きやすい状態をつくることに専念できたのは大きかったと思います。チーム全体で役割を分担し、背中を預け合える関係性を築けたことが、改善の成功要因だと感じています。

当初は、メンバーが改善案を発言することを遠慮しているようにも見えました。しかし、PdMから「案件を積極的につくっていきたいので、提案してほしい」という方針が示されたことをきっかけに、徐々にメンバーからも具体的な提案が出るようになりました。エンジニアメンバーから「これを進めるのはどうですか？」と声が上がり、実際にリリースされて成果につながった例もあります。

それぞれの取り組みが定着した後、2026年2月にはチームが「アビリティマネージャー」と「ポジションマッチング」の担当に分かれ、私は後者を担当するチームに移りました。今では、両チームとも部署内でトップクラスのリリース頻度を誇るまでになっています。

現在は、機能をリリースするだけでなく、定期的にお客様と対話し、直接フィードバックを受けながらプロダクトを改善する段階へと進んでいます。形式的にスクラムを運用することに意識を向けるのではなく、お客様が価値を見出しやすく、かつビジネス性も担保できる方法を自分たちで考え、実行できるチームへ変わってきたと感じますね。

エンジニアとして、新規契約の獲得や既存顧客のアップセルにつながる機能を開発し、より一層ビジネスへ貢献することです。これは以前から一貫して挑戦し続けているテーマでもあります。

また、チームとしても常にビジネス成果を見据え、お客様と直接コミュニケーションを取りながら開発することを意識して、しっかりと成果につなげていけたらと考えています。お客様に「こういう人たちがサービスをつくっている」と知っていただくことが、プロダクトへの信頼感にもつながると思っているので、今後もお客様との接点は大切にしていきたいですね。

「サービスをどう成長させるかを考えながら、真摯にものづくりができる人」ではないでしょうか。カオナビは2025年6月に株式非公開化し、中長期の成長を見据えてより「攻め」の姿勢で投資を進めるフェーズを迎えています。単に技術的に良いものをつくるだけではなく、ビジネスとして価値のあるものをつくりたい。そのような思いを持っている方にとって、カオナビは挑戦しがいのある環境だと思います。

また、カオナビには「仕組みを磨き続ける」というバリューがあります。「人を増やして解決するのではなく、仕組みによって改善する」という思想は社内に深く浸透していると感じます。私自身も今回、チームの課題を仕組みから見直すことで改善してきました。

社内の課題をプロセスやシステムで解決しようとする姿勢が、とても歓迎される会社です。そういった仕組みの改善に関心があり、自ら行動して組織を変えていきたいという人は、ぜひ一緒に働けたらと思っています。