4年間1人もエンジニアが辞めずに拡大。「ノイズ」を徹底的に排除した組織のかたちとは

職種間で上下関係が発生したり、コミュニケーションエラーが頻発したりすることでプロダクト開発が思うように進まない……。こういった状況に陥ると、エンジニアのモチベーションが上がらず、状況の改善を待たずして現場のエンジニアが離職してしまう——そんな事態を招きかねません。

企業の調達・購買部門向けクラウドサービスである『リーナー見積』や『リーナー購買』を開発・販売する、株式会社Leaner Technologies（以下、リーナー）は、2019年の創業以来、エンジニアの退職者が一人も現れていないといいます（2025年3月時点）。

本記事では、そんな「人が辞めないエンジニア組織」の秘密を探るべく、組織づくりを牽引している小久保祐介さんにインタビュー。小久保さんはその秘密を「退職につながるような『ノイズ』を発生させないこと」だと明かします。

退職を招く「ノイズ」とは？　そして、そのノイズを抑制し、人が辞めないエンジニア組織を維持するための仕組みとは？　取材しました。

• keyboard_arrow_down 全員で同じ目的に向かうために、「ノイズ」を排除する
• keyboard_arrow_down 社内のコミュニケーションに「翻訳者」をつくらない
• keyboard_arrow_down メンバーにとっての最大のノイズは、「経営層が何を考えているかわからないこと」
• keyboard_arrow_down エンジニアに「定量目標」を付与しない理由
• keyboard_arrow_down 組織拡大も、文化の維持も諦めない
• keyboard_arrow_down 「言葉」だけではなく、コミュニケーションの「プロトコル」も整える

——今日はよろしくお願いします。まず、現在のエンジニア組織について教えてください。

小久保：約20名ほどが在籍しています。2021年に私が2人目のエンジニアとして入社してから、約4年の間に10倍の規模になっていることになります。現時点（2025年3月）では誰一人としてエンジニアが辞めていないんです。離職者ゼロにこだわっているわけではありませんが、エンジニアにとって働きがいのある組織をつくれているのではないかと思っています。

——組織づくりにおいて、どんなことを工夫していますか？

小久保：働く上での「ノイズ」を徹底して排除し続けています。

当社のプロダクト開発においては、エンジニア、セールス、カスタマーサクセス、コーポレート部門を含め、すべての部署と協働しながら、顧客の課題や社会課題の解決に向き合うことを最も重視しています。他職種とのコミュニケーションも多いし、スタートアップなので社長との距離感も近い。こうした環境では、バックグラウンドが違う人とのコミュニケーションがうまくいっていて、社長の方針に納得できていれば、メンバーはモチベーション高く働けてアウトカムも大きくなりますが、そうでない場合には、仕事へのモチベーションもアウトカムも大きく下がります。

つまりノイズとは「コミュニケーションエラー」と「社長の方針の不透明さ」。これらを排除するためのさまざまな施策を実施してきました。

——コミュニケーションにおけるノイズを抑えるために、どのようなことをしているのでしょうか。

小久保：社員同士のコミュニケーションにおいては、「翻訳者」のような存在をつくらないことを大事にしています。

ノイズが発生しがちな状況は、大きく分けて2つ。1つ目は、異なる職種間でコミュニケーションを取るとき、そして2つ目は、会社のトップがメンバーに言葉を伝えようとするときだと考えています。

こういうシーンでいわゆる翻訳者をはさむ、つまりエンジニア組織とセールス組織で折り合いがつかなくて「マネージャー同士で話をつける」とか、社長やCTOの考えをマネージャーが翻訳してメンバーに伝えるのは、「伝言ゲーム」になってしまいます。伝言ゲームを続けていると、いつの間にか発信者の意図からズレた言葉になってしまい、思わぬディスコミュニケーションが生じてしまうことがある。

だからこそ、翻訳者をつくらず、どのような職種、役割を担うメンバー間でも直接コミュニケーションを取る、という動き方ができる仕組みづくりを実践しています。

——「翻訳者」をつくらないための具体的な手段を教えてください。

小久保：プロダクト開発の基本的な進め方において、すべての職種がフラットにコミュニケーションをとれるような形にしています。

開発のスタートは、事業計画をもとに、セールスやカスタマーサクセスがお客様からヒアリングをして、ニーズを調査することです。その後、カスタマーサクセス、セールス、エンジニア間でプロダクトとして解くべき課題は何かを話し合います。大きな方向性が決まったら、エンジニアがプロトタイプをつくります。

そして、カスタマーサクセスやセールスのメンバーが——必要に応じてエンジニアも——プロトタイプに対してユーザーからフィードバックをもらうヒアリングをして、どのように改善するかを決め、改善策を反映する……といったことを繰り返しながら開発を進めています。

探索的に課題を探りながらの開発が必要な機能については、ニーズの収集、他案件を含めた優先順位付け、実装に至る一連の流れを、セールス、カスタマーサクセス、エンジニアで協働。月に2度、全体MTGを開催し、その中で開発のロードマップを確認し、案件の優先順位を決定しています。

——開発のプロセス全体に、カスタマーサクセスやセールスのメンバーも深くかかわっているのですね。

小久保：プロダクトのコアになるような機能についてはそうですね。エンジニアが単独で、ただただ手を動かすという時間はそう多くないです。

——開発に大きなリソースを要さない、小規模な修正などはどのように進めているのでしょうか。

小久保：エンジニアがサクッと1～2時間手を動かすだけで対応できる、ユーザーから寄せられる細かな要望には、都度迅速に対応できる仕組みをつくっています。

社内では「相棒制度」と呼んでいて、カスタマーサクセスやセールスのメンバーがお客様からご意見をいただいた場合、対応方針を一緒に考える相棒として都度エンジニアを募るための制度をつくりました。こちらは先ほどの探索的な開発よりも手前の、まだふわっとしている段階から。

まず、カスタマーサクセスのメンバーがお客様からの要望をヒアリングします。カスタマーサクセスのメンバーからすると、プロダクトでどう解決すべきか、そもそも解決できるのかもわからないので、可能な限りたくさんの要望を集めてもらうようにしています。その時に、要望の背景もできる限り聞いてもらって、その情報を社内に共有し、ストック。

その後、任意のタイミングでカスタマーサクセスのメンバーが相棒となるエンジニアを募集し、エンジニアチーム側でペアになる相棒をアサインしてマッチングが完了。あとは二人で時間を調整して、ゆるく相談してもらいます。相棒制度はあくまでゆるい相談の場ですが、話を聞いてみると中には意外と簡単に対応できそうな要望もあるんです。そのような小規模な修正は、各エンジニアの判断でサクッと対応を済ませる場合もありますね。

ここで大切にしているのは、対応方針を個々のエンジニアが自分で決めること。こういった話の決定権を、プロダクトマネージャーなど一部メンバーに閉じてしまうと、その人がボトルネックになって話が進まなくなってしまう恐れがあります。エンジニアだけでも的確に判断できるようになるために、エンジニアにもプロダクトマネージャー的な視点を持つよう求めています。

——どうしても折り合いがつかない場合は、上位者が介入することもあるのでしょうか。

小久保：うまくコミュニケーションが取れなくてやりとりが長引いているときも、安易に間に入ったりはしません。そもそもマネージャーなどの「間に入って解決する役」のような立場を設けていないのです。僕が組織づくりを担っていることもあって、便宜上、対外的にマネージャーと名乗ることはあります。ただ、組織内に「マネージャー」と「メンバー」という明確な階層構造はつくっていません。

メンバー同士で言葉を尽くせば理解し合えるはずですし、間に誰かが入ることでむしろ相互理解を阻害し、それがゆくゆくノイズにつながってしまう。それに、違う職種の人とコミュニケーションをとるのが「当たり前」の状態で開発を進めることによって、「相互理解をせざるを得ない環境」が生まれます。するとお互いに、多少わかりあえないことがあったとしても、コミュニケーションを諦めたり苛立ちを溜め込むのではなく「どうしたら伝わるだろうか」と考えて行動するようになるのです。

——ビジネスサイドとエンジニアサイドのコミュニケーションを丁寧に行うと、意思疎通までに時間がかかってしまうこともありそうです。

小久保：コミュニケーションを諦めることなく、素早く意思疎通していくために、「言葉」を揃えるための取り組みを実施しています。

異なる専門分野の協働では、専門用語や、専門知識に紐づいた概念や肌感を、相手に理解してもらえるように説明しなくてはなりません。でもその説明において、そもそも同じ言葉で別の意味を話していて、余計に伝わらないことが多い。専門用語の解釈が違うのはもちろん、プロダクトに備わっている機能の名称などについても、放っておくと名称と意味の組み合わせが揺れてしまうことがあります。

すると、エンジニア組織とセールス組織内で特定の機能の呼称が異なっている場合、同じ機能について話をしているのにコミュニケーションがスムーズにいかないということがある。そういったコミュニケーションロスを減らすために、「ユビキタス言語」をつくりNotion上で管理しています。

たとえば、『リーナー見積』のユーザーは、見積依頼する企業の担当者と見積回答する企業の担当者に分けられますが、前者を「クライアント」と呼ぶ人もいれば、「バイヤー」と呼ぶ人もいるような状態でした。そこで、見積依頼する企業の呼称を「バイヤー」、バイヤー社内の担当者が使用するアカウントの呼称を「バイヤーユーザー」に統一。また、見積回答する企業は「サプライヤー」、サプライヤーの担当者が使用するアカウントは「サプライヤーユーザー」としています。

これはあくまでも一例で、他にも表記や呼称が揺れがちだったさまざまな言葉をピックアップし、ユビキタス言語を策定することで、職種を問わずスムーズにコミュニケーションができる環境を整えているんです。

——もう1つ、ノイズが生じる「場所」があり、それが「経営層とメンバーの間」とのことでした。

小久保：個人的に、メンバーが退職や転職を考えるきっかけになりうるクリティカルなノイズは「社長、あるいは大きな影響力を持っている人物が、何を考えているかわからない」ことなのではないかと考えています。

というのも、メンバーが「社長が何を考えているかわからない」ときは、社長も「メンバーが何を考えているのかわからない」状態になっているのではないかと。つまり、上層部と現場間に相互理解がない、信頼し合えていない状態なのだと思っています。

そういった状態になると、メンバーは「自分が会社や事業に対して、どのように貢献すればいいのか」、言い換えれば「いかに事業成長とその先にある社会課題の解決に向き合うべきなのか」がわからなくなってしまう。

すると、自分が評価されていたとしても、評価されている理由もわからなくなってしまいますし、評価する立場にある人は、メンバーをどう評価すればいいのか迷ってしまうなど、さまざまな要素に少しずつズレが生じてしまうと思うんです。そういった小さなズレの積み重なりが、組織を崩壊させるのではないかと考えています。

——そういったズレを生まないためには、どんなことが重要なのでしょうか。

小久保：これまでの経験から言えば、社長が「メンバー層との相互理解、あるいは信頼構築が重要である」ということを認識し、しっかりと問題意識を持っていることが何よりも重要だと考えています。この手の問題は、顕在化してから対処していては手遅れなんですよね。組織がある程度大きくなってから、経営層とメンバー層の信頼関係を構築するのはかなり難しいのではないかと思います。

ですから、何らかの問題やズレが生じる前からしっかりとコミュニケーションを図り、相互理解を深めていく必要があります。幸い、大平（代表取締役CEO・大平裕介さん）はこの問題に対してアンテナを張ってくれています。

具体的な仕組みとして挙げられるのは「熱中することを探求する会」、略して「ネコたん」ですね。これは毎回異なるトークテーマを設定した全社会議で、役職や部門を問わず、各々が感じている課題感や3〜5年後に実現したいビジョンなどを、ざっくばらんに話し合っています。未来のためにメンバー全員が同じ方向を向いて議論をするので、自ずと信頼関係が構築される効果があると感じています。

——体制や仕組みを整えても、どうしても「部署ごとの力学」が働いてしまう瞬間はあるのではないでしょうか。

小久保：そういったことを抑制する要素として重要なのが「評価基準」です。「全員で課題に向き合おう！」と言ったところで、たとえばセールスは売上、カスタマーサクセスはチャーンレート、エンジニアは機能数といった形で、それぞれに定量目標を設定すると、どうしてもその数字に引っ張られてしまって、なかなか同じ方向を向けないと思います。

基本的にリーナーでは目標設定にOKRを導入しているのですが、エンジニアについて言えば、定量的な目標は置いていません。何かしらの目標数値を課してしまうと、その数字を追うことに必死になってしまって、他の職種のメンバーとコミュニケーションを取る時間が減り、その結果、お客様にとっての価値の追求がおざなりになってしまう可能性がある。

数字を追うことよりも、お客様の要望を形にし、事業成長に寄与するという本来の役割にフォーカスしてもらうためにも、定量目標は設定しないようにしています。

——では、基本的にはプロセスを評価している？

小久保：そうですね。個人がどのような形で、どれだけ組織全体や事業、ひいては顧客の課題解決に貢献したのかを定性的に評価するようにしています。

事業成長に対してどのように貢献するかは、人それぞれだと思います。新たな機能の開発に大きく貢献した、というわかりやすい貢献の仕方をする人もいれば、その人を後方から支援することで間接的に貢献する人もいます。それに、その貢献の仕方は個人のスキルのみに依拠するわけではなく、組織全体の状況や、プロダクト開発のフェーズによって変化するものだと考えています。

開発の成果としてもたらされたアウトカムもまったく見ていないわけではないですが、現時点ではそれを評価基準にしたことはありません。アウトカムはあくまでもチーム、そして会社全体としての成果なので。一見すると個人の成果に見えるものでも、その裏ではいろんな人の協力の元で成り立っています。

——このような組織を構築できた理由は、どのような点にありますか。

小久保：大前提にあるのは、採用です。採用においては、もちろんスキルなども重要な要素ですが、これまで構築してきた組織文化にマッチする人だけを採用することにこだわり抜いてきました。その結果、いまの組織があるのだと考えています。

——組織の拡大ペースが比較的緩やかな印象を受けるのですが、これは意図したことなのでしょうか。

小久保：「ゆっくり組織を拡大しよう」と意識したことはなく、結果としてこのようなペースになりました。一時期は採用活動よりも、プロダクト開発に使う時間を優先していたこともあります。

スタートアップですからリソースは常に足りません。でも、いくら人を増やしたとしても、入社したメンバーが活躍できる仕組みを整えなければアウトカムには繋がりません。それに、人を増やそうとして、元々いるメンバーと、考え方や価値観にズレがある人を採用してしまっては、今までつくりあげてきた文化が崩れていってしまう。だとしたら、人数を増やしてやりたいことがたくさんあったとしても、無理に採用を進めるのは得策でないだろう、と判断しました。

——ペースは緩やかにせよ、組織は徐々に拡大していくと思います。どの程度の規模まで、現在の仕組みや制度を維持しようと考えていますか？

小久保：30人くらいで一区切りかなと思っています。現在の規模でも、一人ひとりと丁寧にコミュニケーションを取るのは難しくなってきているので、組織が30人を超えたときはアプローチを変えなくてはいけないでしょうね。それに、それくらいの規模になると「個と個」の関係性というよりは、「チームとチーム」の関係性を考えなくてはならないと思うので、これまで通りとはいかないと思っています。

——今後、組織づくりの上で、トライしたいと思っていることはありますか？

小久保：先ほど、ユビキタス言語をつくったというお話をしましたが、今後は会話自体のプロトコルを整理したいと思っています。たとえば、何かしらのプロダクトをつくるとき、カスタマーサクセスやセールスのメンバーとエンジニア間で、「お客様のどういう問題を解決するのか」「この機能開発はどれくらいの工数が掛かりそうか」「どんな調査をする必要があるか」といった会話が交わされますよね。

そのやり取りの内容や進め方は人それぞれで、標準化されていないのが現状です。なので、効率良く物事を決定することを目的に、コミュニケーションのプロトコルをつくりたいんです。そうすることによって、コミュニケーションの無駄が減り、より本質的な議論ができるのではないかと。

どれだけ組織規模が大きくなったとしても、部門を問わず、すべてのメンバーで課題に向かえる組織であり続けたいと思っています。だからこそ、これからもさまざまな工夫をこらしながら、この環境を維持していきたいです。

取材：鷲尾 諒太郎、光松 瞳
執筆：鷲尾 諒太郎
編集：光松 瞳
撮影：曽川 拓哉