デンソーが挑む“インド発グローバル開発”Findy Team+で実現した“共通指標”によるマネジメント改革
デンソーが挑む“インド発グローバル開発”Findy Team+で実現した“共通指標”によるマネジメント改革
目次
目次を読み込み中...
モビリティ産業の変革を背景に、インドで新規デジタル事業を立ち上げたデンソー。インド人エンジニアを中心に構成された開発チームの拡大とともに開発プロセスの属人化やブラックボックス化が課題となる中、Findy Team+ による開発生産性の可視化が、共通言語による改善文化を支えています。
今回は現地責任者の守本さんに、事業立ち上げの背景と組織変革のリアルを伺いました。
プロフィール
守本 剛
デンソーインターナショナルインド Vice President
自動車部品メーカーのデンソーに2008年入社。新興国におけるモビリティサービスの企画・戦略立案業務を担当していた2017年に、市場調査のため初めてインドを訪問。2019年よりデンソー・インターナショナル・インドへ赴任。
「自動車産業の100年に一度の変革期」に挑む──インド市場を見据えた新規事業立ち上げの原点
ーーインドで新規事業を立ち上げるまでの背景を教えてください。
守本：私がインドと関わり始めたのは 2017年頃です。当時、自動車産業は“100年に一度の変革期”と言われ、Uberなどのモビリティサービスが急成長していました。
私は日本の技術企画部（全社の技術戦略をつくる部署）にいて、「モビリティサービスの時代に、デンソーはどう生き残るか」という戦略立案を担当していました。
ハード×ソフトからソフト集中へ──スピードと構造課題が導いたSolwer誕生のターニングポイント
ーー当初はハード×ソフトの構想だったと伺いましたが、そこからどう現在の事業モデルにつながっていったのでしょう？
守本：デンソーには空調・冷却技術という強みがあり、車載用空調製品は世界シェア1位。その技術を活かせば新興国で新しい価値を生み出せるのでは、という仮説から始まりました。
私は、インドにおけるデータ活用型コールドチェーン構築の実証事業の中で、業務可視化を含むハード×ソフトのPoCに関わってきました。
こうした取り組みを通じて、低温物流領域での新規事業の可能性を探っていました。
ーーそこからソフトウェア中心へ大きく舵を切られたわけですが、何が転機になったのでしょう？
守本：ソフトへ舵を切った転機はスピードの差でした。
ソフトは週単位で改善できる一方、ハードはソフトと比べて開発や修正に時間がかかります。さらにコロナ禍の影響もあり、市場で学びながら事業をつくる段階でハードが足かせとなったため、「まずはソフトに集中すべき」と判断し、ソフト一本で進む決断をしました。
1,000億円規模を見据えた事業戦略──Solwer（ソルバー）が描くリバースイノベーション戦略
守本：トップダウンで「100億ではなく1,000億円規模の事業をつくる」という目標が掲げられたことで、アプリ単体では達成できず、産業構造そのものを変えるプラットフォームが必要だと明確になりました。そこで複数プロダクトを共通基盤で展開するマルチプロダクト型構想が生まれ、Solwer（ソルバー）が誕生しました。
Solwer は、製造改善・物流最適化・GHG可視化・アフターマーケット統合・AIデジタルインスペクションなど、製造・モビリティ領域の複数アプリを一つの基盤で動かす統合デジタルプラットフォームです。現在、経産省・UNIDOの支援のもと2027年の社会実装に向けて進行しており、その後はインド全土からグローバル市場へ拡大していきます。
低コスト・高競争力のサービスをインドでつくり、そこから世界へ届ける。それがSolwerの挑戦です。
（引用：インドで成功する日本企業の共通点と、電通とドリームインキュベータの共創力）
属人化と文化の壁を乗り越えるために──データドリブンで進める開発プロセス可視化の第一歩
ーーSolwerの開発体制を拡大していく中で、どんな課題が顕在化していったのでしょう？
守本：Solwerの開発体制が拡大する中で明らかになったのは、「プロセスが整わないまま組織だけが急成長した」ことでした。初期は少人数で対応できていたものの、人が増えるとスキル差やガバナンスの必要性が一気に浮上し、外部ベンダーの活用も文化や進め方の違いでうまく回らない状況が続きました。
特に大きかったのが、ハードウェアを前提としたものづくりの開発プロセスと、ソフトウェア開発との時間軸の違いでした。また、複数プロダクト開発が同時に進む中で、どこで進捗が止まっているのか分からないブラックボックス化が進んでいきました。
ちょうどその頃、河島さん（ファインディ株式会社 海外事業責任者兼 CFO）とお話しする機会があり、「属人的な判断には限界がある」という認識で一致しました。ただ、着手ポイントはまだ明確ではなく、まずは事実を可視化する仕組みが必要だという整理に至り、GitHubやJiraのデータを基盤にプロセスを見ていく方向性が見え始めた段階でした。
「気がする」からの脱却──共通言語としてのデータ可視化で意思決定の精度を高める取り組み
ーー「事実を捉える仕組み」が必要だと強く感じた背景には、現場で具体的にどんなことが起きていましたか？
守本：当時の議論はすべて「気がする」で進んでいました。
「速い気がする」「遅れている気がする」「レビューが止まっている気がする」──しかし実際どこがボトルネックなのか誰も説明できない。私たちは 「データドリブンで社会課題を解決する」というビジネスを作っているのに、肝心の自分たちの開発プロセスには数字が出てこない。これは正直、すごく大きな矛盾でした。
遅いと言うなら、どこが遅いのか？60％進捗と言うなら、何をもって 60％なのか？レビューに時間がかかっていると言うなら、どこの工程なのか？
誰も答えられない。だから、チームによって認識も判断基準もバラバラになる。
ーー多拠点・多国籍で進める開発では、なおさら 「共通言語がないと意思決定できない」という問題もありますよね。
守本：Solwer は各国拠点、正社員、フリーランス、ベンダーが混在する体制で、しかも複数のプロダクト開発が同時に走っています。この状況で「どこを優先するか」「どのチームを改善するか」を判断しようとしても、感覚だけではもう限界でした。
特に象徴的だったのがレビュー遅延です。そもそもレビューが出ているのかどうかすら把握できない。誰が止めているのかも分からない。中にはレビューを通さずにマージしてしまっているケースまであって、もはや議論が成立しない状態でした。
ーー「数字がないから進めない」のではなく、「数字がないせいで間違った意思決定をしてしまう」可能性もあります。
守本：本当にその通りです。だからこそ、「まずは事実を見よう」と。GitHub と Jira のデータを分析して、客観的にプロセスを把握する必要があると強く思いました。
そこで 「どの工程で詰まっているのか」 「チームごとの成熟度がどう違うのか」 をまず可視化しようという話になり、Findy Team+の導入を前向きに検討し始めたわけです。
“Yesだが動かない”チームの文化と、導入初期に直面した静かな抵抗
ーー実際に Findy Team+を導入しようとした際、現場ではどんな反応がありましたか？
守本：本当に大変でした。というのも、私のチームの特徴として “表面的には Yes だが、行動は No” ということがよく起きます。ミーティングでは全員が前向きに「Yes」と言う。でも翌週に状況を見ると、実際には何も変わっていない。
ーー会議ではポジティブなのに、実行が伴っていないように見える場面は多かったですよね。
守本：明確に反対はせず、表向きは「Yes」と言いながら裏では動かず、理由を後付けして実行しない。コンフリクトを嫌う文化ゆえに正面から「No」とは言わないものの、行動は真逆でした。Findy Team+の管理もまさにそのパターンでした。巨大プルリクエスト（PR）は避けて、レビューを必ず入れてくださいと指摘すると、ミーティングでは「Yes」「やります」と言う。でも翌週見てみたら、巨大PRはそのまま、レビューは依然として入っていない。
ーー現場のメンバーと握っていたはずなのに、守本さん側には一切伝わっていないこともありましたよね。
守本：合意した内容が、各チームの判断や優先順位の中で調整され、結果として「実はやらない」という判断が現場で起きていることに、マネジメント側が気づけない場面がありました。
もし Findy Team+がなかったら、「現場が Yes と言っているなら大丈夫だろう」と思い込んで、実際はまったく動いていない。そんな状況に確実に陥っていたと思います。
組織が拡大すると、誰が本当に動いていて、どこが止まっているのかが一気に見えなくなる。少人数なら勘で把握できていたブロッカーも、組織が大きくなると一瞬でブラックボックス化します。そこにYes と言うが動かない文化が重なると、もう完全にカオスです。
だからこそ、「感覚ではダメだ。数字で判断するしかない」と腹を括りました。数字は嘘をつかない。組織拡大の課題を乗り越えるためにも、Findy Team+を軸に事実ベースで運営する体制へ切り替えたことは大きな転機でした。
Findy Team+の活用方法──共通ダッシュボードで実現する自走と牽制の仕組み
ーー 開発プロセスを可視化する中で、守本さんご自身は、どんなポイントを見ているんでしょう？
守本： GitHubやJira自体はすでに活用していましたが、そこに蓄積されたデータを、どの視点で見れば開発プロセスの課題が浮かび上がるのかについては整理できていませんでした。
そこでまずは、Findy Team+のカスタマーサクセスの皆さんに、本当に基礎の基礎から丁寧に教えてもらいました。
プルリクエストの数やコードの変更量、プルリクを出してからマージされるまでの時間（サイクルタイム）といった指標を追っていくと、「PRは出ているのにレビューがまったく行われていない」「レビュー依頼からマージまでが異様に長い」といった、基本の基本でつまずいているポイントが一気に可視化されました。
ーー最初ご一緒したときも、「そもそもレビューしていないPRが結構ありますよね」というところからでした。
守本：レビューなしのマージは、口頭で「やめましょう」と言っても全然減りませんでした。むしろ抜け道を作ろうとする動きが出てくる。
そこで発想を変えて、仕組みそのものを変える方向にしました。単に注意するのではなく、
- Findy Team+上で「レビューなしマージ」を可視化する
- スプリントレビューや定例の場で、具体的なPRを画面に映しながら議論する
こうした取り組みをセットで回すことで、ようやく改善が進んでいきました。
言い続けるだけでは絶対に直らない。ツール・プロセス・教育の三点セットで変える必要があった。これは大きな学びでした。
GitHub × Jira × Findy Team+ で実現する事実ベースの対話
ーー今は GitHub と Jira の両方をつないでいただいていますが、どんな使い方になっていますか？
守本：GitHub と Jira を Findy Team+に全部つないで、Solwer 全体の開発状況を一つのダッシュボードで見られるようにしている、というのが今の形です。
これらを一枚の絵として可視化し、スプリント計画やレビュー会議では必ずこのダッシュボードを起点に議論するという運営にしています。「なんとなく忙しい」「なんとなく遅い」といった曖昧な言葉ではなく、
- どのチームのサイクルタイムが悪化しているのか
- レビュー滞留がどのプロダクト／どのメンバーに偏っているのか
- 巨大 PRがどこで頻発しているのか
といった 事実ベースの対話 に完全に切り替わりました。この「共通指標で語れる状態」が、組織にとって非常に大きな価値でした。
マイクロマネジメントから「QA による三権分立」で支える自律的な開発体制へ
ーー 守本さんご自身が毎日のようにダッシュボードを見て、分析しているのでしょうか？
守本：当初はそうでした。ただ途中でマネージャーが全部見て全部指摘していたら、いつまでも組織が自走しないと感じ、途中からは、QAチームを独立させて、「プロジェクト品質の責任」もQAに持たせる形にしました。プロダクトのバグだけじゃなくて、開発プロセスの品質も含めて QAの責任にしました。
イメージとしては、
- ビジネス／事業開発
- プロダクト開発
- QA（品質保証）
そして Findy Team+のデータについては、「QAがきちんと見ていなければ QAに責任が返ってくる」という明確な役割分担にしました。
また、三権分立の核となるのが、QAマネージャーが毎月作成するレポートでした。
（※QAマネージャーが毎月作成しているレポートです。個人名への配慮のため、名称を変更しています。）
ただ数字を並べるだけではなく、「このチームは明確に改善している」「活動量が不足しているわけではないが手戻りが多い」「レビューの偏りが顕著」といった 解釈まで踏み込んで言語化してくれるので、このレポート自体が個々の振り返りの鏡 であり、組織としての 改善テーマを決める指針 にもなっています。
この月次レポートが、可視化されたプロセス改善の土台になったと言っていいと思います。
Findy CSという第三者評価が加わり、改善サイクルがさらなる強化へ
守本：そこに加わったのが、Findy Team+のカスタマーサクセス（CS）による第三者評価です。
毎月のレポートレビューでCSが参加し、
- QAでも見落としていた兆候
- 数値の異常値
- プロセスの歪みや再発傾向
といった点を、完全な外部視点で指摘してくれます。内部だけではどうしてもバイアスがかかりますが、CSが入ることで「外から見ても不自然」が明確になる。その結果、組織内に自然と緊張感が生まれました。
フリーランスも含めた「牽制」と「フェアさ」を担保する
ーーフリーランスエンジニアのマネジメントにもお使いいただいていますよね。
守本：今もフリーランスエンジニアを結構使っているのですが、基本は時間課金です。そうすると、アクティビティが見えないと不正の温床になりかねない。
Findy Team+でPRの数や活動量が見えることで、
- 明らかに活動していない人がいれば気づける
- 逆に、ちゃんと貢献している人も可視化される
という意味で、牽制とフェアさの両方を担保する仕組みになっています。
「活動量が不足している人を見つける」というより、頑張っている人がきちんと評価される状態をつくるために使っている、という感覚に近いです。
データドリブン文化と KPI ハックのせめぎ合い
ーー 「データドリブンな文化」と「数字のハック」の話もよくしていましたよね。
守本： 数字が見えるようになると、どうしても指標をハックしようとする動きは出ます。デプロイ数だけ増やすなど、数字だけ良く見えるケースですね。でも、それは KPI を設計する側の責任 だと思っています。
違和感があれば指標を調整するし、デプロイ数を見るなら手戻り率もセットで確認する。数字と実態を常にすり合わせています。
Findy Team+の活用方法──レビューなしゼロへ。透明性が支える開発生産性向上のインパクト
ーー Findy Team+の導入で、まず最初にどんな変化が起きましたか？
守本：一番大きかったのは、問題を課題として認識できるようになったことです。導入前は、レビューなしマージ、巨大 PR、レビュー滞留などが「気がする」レベルでしか語れず、構造的な把握ができていませんでした。
そこでFindy Team+を軸に、次の4つの施策をセットで進めていきました。
- レビューなしマージを定期的に洗い出す（Findy Team+）
- 具体的な事例を会議で振り返り、再発要因を特定する
- GitHub のルールを見直し、レビュー必須 を仕組みとして定着させる
- 新人やフリーランスを含めた全員に継続的に教育する
この「プロセス整備 × 教育 × 仕組み化」の三点セットが効き、レビューなしマージは最終的にゼロになりました。
口頭の注意だけでは絶対に直らず、 データと仕組みでしか改善は前に進まないということを痛感しました。
サイクルタイムのばらつきが減り、PR活動が健全化
守本：定量的な面では、
- サイクルタイムのばらつきが大幅に縮小
- レビュー滞留が確実に減少
- PRの粒度が整い、巨大PRが激減
このあたりは明確に改善が見えた部分でした。さらに、五つのプロダクトを同時並行で開発しているにもかかわらず、以前は「もっと人を増やさないと回らない」と思っていたところが、実際には人数を増やさずとも安定して回るようになった。
定量的に厳密な測定は難しい部分もありますが、開発スピードが確実に上がっている手触りがありますし、今のチームで回るという事実そのものが、生産性向上の証拠だと思っています。
経営層まで浸透した「透明性」と、スケールに耐えるマネジメントモデルへ
ーーFindy Team+のデータやレポートは、御社の中でどのレベルまで共有されているのでしょうか？
守本：かなり上層部まで共有しています。インド側の社長、日本側の役員にも毎週報告していますし、「Solwer はこういうツールを使ってプロセスを管理している」というのは経営層共通の認識になっています。
また、日本から頻繁に視察も来ますが、全員「ここまでマイクロマネジメントを仕組み化できるのか」と驚かれます。
ただ、私が細かく管理しているのではなく、三権分立（BizDev／開発／QA）で牽制させる仕組みにしている点が特に評価されています。
これは 属人化させないという意味でも重要で、マネージャーが交代しても組織が揺れない体制をつくるための工夫です。
今後の展望──私が抜けても回る組織へ。スケール対応のマネジメントモデル
ーー守本さんがアメリカ拠点に移られると伺いましたが、インド拠点の運営は今後どのようにしていくお考えですか？
守本：本当はインド人メンバーに引き継ぐことが理想でしたが、組織が急拡大する中で、プロセスの運用がまだ完全には安定しきっていない部分もあり、次も日本からの出向者に任せることにしました。
私はアメリカで Solwer の展開を担当しますが、インド開発との連携は続きますし、UNIDOの補助金もKPIの達成が必須なので、責任を持って達成しにいきます。
最終的にはアメリカ（企画・事業） × インド（開発） × 各国拠点（R＆D・営業）のグローバルモデルを見据えています。
グローバル展開に向けた「共通言語」としての Findy Team+
ーー今後、Findy Team+をどのように活用したいと考えていますか？
守本：アメリカ展開が始まるので、グローバルの共通ダッシュボードとして使っていきたいです。リモート前提の体制ですし、新しい開発拠点が増えるほど 共通のプロセス指標が必須になります。
また、今は AI エージェントを使った開発自動化にも取り組んでいて、将来的には 「どのエージェントが最も効くか」も Findy のデータで評価できるのではないかと思っています。
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます
モビリティ産業の変革を背景に、インドで新規デジタル事業を立ち上げたデンソー。インド人エンジニアを中心に構成された開発チームの拡大とともに開発プロセスの属人化やブラックボックス化が課題となる中、Findy Team+ による開発生産性の可視化が、共通言語による改善文化を支えています。
今回は現地責任者の守本さんに、事業立ち上げの背景と組織変革のリアルを伺いました。
プロフィール
守本 剛
デンソーインターナショナルインド Vice President
自動車部品メーカーのデンソーに2008年入社。新興国におけるモビリティサービスの企画・戦略立案業務を担当していた2017年に、市場調査のため初めてインドを訪問。2019年よりデンソー・インターナショナル・インドへ赴任。
「自動車産業の100年に一度の変革期」に挑む──インド市場を見据えた新規事業立ち上げの原点
ーーインドで新規事業を立ち上げるまでの背景を教えてください。
守本：私がインドと関わり始めたのは 2017年頃です。当時、自動車産業は“100年に一度の変革期”と言われ、Uberなどのモビリティサービスが急成長していました。
私は日本の技術企画部（全社の技術戦略をつくる部署）にいて、「モビリティサービスの時代に、デンソーはどう生き残るか」という戦略立案を担当していました。
ハード×ソフトからソフト集中へ──スピードと構造課題が導いたSolwer誕生のターニングポイント
ーー当初はハード×ソフトの構想だったと伺いましたが、そこからどう現在の事業モデルにつながっていったのでしょう？
守本：デンソーには空調・冷却技術という強みがあり、車載用空調製品は世界シェア1位。その技術を活かせば新興国で新しい価値を生み出せるのでは、という仮説から始まりました。
私は、インドにおけるデータ活用型コールドチェーン構築の実証事業の中で、業務可視化を含むハード×ソフトのPoCに関わってきました。
こうした取り組みを通じて、低温物流領域での新規事業の可能性を探っていました。
ーーそこからソフトウェア中心へ大きく舵を切られたわけですが、何が転機になったのでしょう？
守本：ソフトへ舵を切った転機はスピードの差でした。
ソフトは週単位で改善できる一方、ハードはソフトと比べて開発や修正に時間がかかります。さらにコロナ禍の影響もあり、市場で学びながら事業をつくる段階でハードが足かせとなったため、「まずはソフトに集中すべき」と判断し、ソフト一本で進む決断をしました。
1,000億円規模を見据えた事業戦略──Solwer（ソルバー）が描くリバースイノベーション戦略
守本：トップダウンで「100億ではなく1,000億円規模の事業をつくる」という目標が掲げられたことで、アプリ単体では達成できず、産業構造そのものを変えるプラットフォームが必要だと明確になりました。そこで複数プロダクトを共通基盤で展開するマルチプロダクト型構想が生まれ、Solwer（ソルバー）が誕生しました。
Solwer は、製造改善・物流最適化・GHG可視化・アフターマーケット統合・AIデジタルインスペクションなど、製造・モビリティ領域の複数アプリを一つの基盤で動かす統合デジタルプラットフォームです。現在、経産省・UNIDOの支援のもと2027年の社会実装に向けて進行しており、その後はインド全土からグローバル市場へ拡大していきます。
低コスト・高競争力のサービスをインドでつくり、そこから世界へ届ける。それがSolwerの挑戦です。
（引用：インドで成功する日本企業の共通点と、電通とドリームインキュベータの共創力）
属人化と文化の壁を乗り越えるために──データドリブンで進める開発プロセス可視化の第一歩
ーーSolwerの開発体制を拡大していく中で、どんな課題が顕在化していったのでしょう？
守本：Solwerの開発体制が拡大する中で明らかになったのは、「プロセスが整わないまま組織だけが急成長した」ことでした。初期は少人数で対応できていたものの、人が増えるとスキル差やガバナンスの必要性が一気に浮上し、外部ベンダーの活用も文化や進め方の違いでうまく回らない状況が続きました。
特に大きかったのが、ハードウェアを前提としたものづくりの開発プロセスと、ソフトウェア開発との時間軸の違いでした。また、複数プロダクト開発が同時に進む中で、どこで進捗が止まっているのか分からないブラックボックス化が進んでいきました。
ちょうどその頃、河島さん（ファインディ株式会社 海外事業責任者兼 CFO）とお話しする機会があり、「属人的な判断には限界がある」という認識で一致しました。ただ、着手ポイントはまだ明確ではなく、まずは事実を可視化する仕組みが必要だという整理に至り、GitHubやJiraのデータを基盤にプロセスを見ていく方向性が見え始めた段階でした。
「気がする」からの脱却──共通言語としてのデータ可視化で意思決定の精度を高める取り組み
ーー「事実を捉える仕組み」が必要だと強く感じた背景には、現場で具体的にどんなことが起きていましたか？
守本：当時の議論はすべて「気がする」で進んでいました。
「速い気がする」「遅れている気がする」「レビューが止まっている気がする」──しかし実際どこがボトルネックなのか誰も説明できない。私たちは 「データドリブンで社会課題を解決する」というビジネスを作っているのに、肝心の自分たちの開発プロセスには数字が出てこない。これは正直、すごく大きな矛盾でした。
遅いと言うなら、どこが遅いのか？60％進捗と言うなら、何をもって 60％なのか？レビューに時間がかかっていると言うなら、どこの工程なのか？
誰も答えられない。だから、チームによって認識も判断基準もバラバラになる。
ーー多拠点・多国籍で進める開発では、なおさら 「共通言語がないと意思決定できない」という問題もありますよね。
守本：Solwer は各国拠点、正社員、フリーランス、ベンダーが混在する体制で、しかも複数のプロダクト開発が同時に走っています。この状況で「どこを優先するか」「どのチームを改善するか」を判断しようとしても、感覚だけではもう限界でした。
特に象徴的だったのがレビュー遅延です。そもそもレビューが出ているのかどうかすら把握できない。誰が止めているのかも分からない。中にはレビューを通さずにマージしてしまっているケースまであって、もはや議論が成立しない状態でした。
ーー「数字がないから進めない」のではなく、「数字がないせいで間違った意思決定をしてしまう」可能性もあります。
守本：本当にその通りです。だからこそ、「まずは事実を見よう」と。GitHub と Jira のデータを分析して、客観的にプロセスを把握する必要があると強く思いました。
そこで 「どの工程で詰まっているのか」 「チームごとの成熟度がどう違うのか」 をまず可視化しようという話になり、Findy Team+の導入を前向きに検討し始めたわけです。
“Yesだが動かない”チームの文化と、導入初期に直面した静かな抵抗
ーー実際に Findy Team+を導入しようとした際、現場ではどんな反応がありましたか？
守本：本当に大変でした。というのも、私のチームの特徴として “表面的には Yes だが、行動は No” ということがよく起きます。ミーティングでは全員が前向きに「Yes」と言う。でも翌週に状況を見ると、実際には何も変わっていない。
ーー会議ではポジティブなのに、実行が伴っていないように見える場面は多かったですよね。
守本：明確に反対はせず、表向きは「Yes」と言いながら裏では動かず、理由を後付けして実行しない。コンフリクトを嫌う文化ゆえに正面から「No」とは言わないものの、行動は真逆でした。Findy Team+の管理もまさにそのパターンでした。巨大プルリクエスト（PR）は避けて、レビューを必ず入れてくださいと指摘すると、ミーティングでは「Yes」「やります」と言う。でも翌週見てみたら、巨大PRはそのまま、レビューは依然として入っていない。
ーー現場のメンバーと握っていたはずなのに、守本さん側には一切伝わっていないこともありましたよね。
守本：合意した内容が、各チームの判断や優先順位の中で調整され、結果として「実はやらない」という判断が現場で起きていることに、マネジメント側が気づけない場面がありました。
もし Findy Team+がなかったら、「現場が Yes と言っているなら大丈夫だろう」と思い込んで、実際はまったく動いていない。そんな状況に確実に陥っていたと思います。
組織が拡大すると、誰が本当に動いていて、どこが止まっているのかが一気に見えなくなる。少人数なら勘で把握できていたブロッカーも、組織が大きくなると一瞬でブラックボックス化します。そこにYes と言うが動かない文化が重なると、もう完全にカオスです。
だからこそ、「感覚ではダメだ。数字で判断するしかない」と腹を括りました。数字は嘘をつかない。組織拡大の課題を乗り越えるためにも、Findy Team+を軸に事実ベースで運営する体制へ切り替えたことは大きな転機でした。
Findy Team+の活用方法──共通ダッシュボードで実現する自走と牽制の仕組み
ーー 開発プロセスを可視化する中で、守本さんご自身は、どんなポイントを見ているんでしょう？
守本： GitHubやJira自体はすでに活用していましたが、そこに蓄積されたデータを、どの視点で見れば開発プロセスの課題が浮かび上がるのかについては整理できていませんでした。
そこでまずは、Findy Team+のカスタマーサクセスの皆さんに、本当に基礎の基礎から丁寧に教えてもらいました。
プルリクエストの数やコードの変更量、プルリクを出してからマージされるまでの時間（サイクルタイム）といった指標を追っていくと、「PRは出ているのにレビューがまったく行われていない」「レビュー依頼からマージまでが異様に長い」といった、基本の基本でつまずいているポイントが一気に可視化されました。
ーー最初ご一緒したときも、「そもそもレビューしていないPRが結構ありますよね」というところからでした。
守本：レビューなしのマージは、口頭で「やめましょう」と言っても全然減りませんでした。むしろ抜け道を作ろうとする動きが出てくる。
そこで発想を変えて、仕組みそのものを変える方向にしました。単に注意するのではなく、
- Findy Team+上で「レビューなしマージ」を可視化する
- スプリントレビューや定例の場で、具体的なPRを画面に映しながら議論する
こうした取り組みをセットで回すことで、ようやく改善が進んでいきました。
言い続けるだけでは絶対に直らない。ツール・プロセス・教育の三点セットで変える必要があった。これは大きな学びでした。
GitHub × Jira × Findy Team+ で実現する事実ベースの対話
ーー今は GitHub と Jira の両方をつないでいただいていますが、どんな使い方になっていますか？
守本：GitHub と Jira を Findy Team+に全部つないで、Solwer 全体の開発状況を一つのダッシュボードで見られるようにしている、というのが今の形です。
これらを一枚の絵として可視化し、スプリント計画やレビュー会議では必ずこのダッシュボードを起点に議論するという運営にしています。「なんとなく忙しい」「なんとなく遅い」といった曖昧な言葉ではなく、
- どのチームのサイクルタイムが悪化しているのか
- レビュー滞留がどのプロダクト／どのメンバーに偏っているのか
- 巨大 PRがどこで頻発しているのか
といった 事実ベースの対話 に完全に切り替わりました。この「共通指標で語れる状態」が、組織にとって非常に大きな価値でした。
マイクロマネジメントから「QA による三権分立」で支える自律的な開発体制へ
ーー 守本さんご自身が毎日のようにダッシュボードを見て、分析しているのでしょうか？
守本：当初はそうでした。ただ途中でマネージャーが全部見て全部指摘していたら、いつまでも組織が自走しないと感じ、途中からは、QAチームを独立させて、「プロジェクト品質の責任」もQAに持たせる形にしました。プロダクトのバグだけじゃなくて、開発プロセスの品質も含めて QAの責任にしました。
イメージとしては、
- ビジネス／事業開発
- プロダクト開発
- QA（品質保証）
そして Findy Team+のデータについては、「QAがきちんと見ていなければ QAに責任が返ってくる」という明確な役割分担にしました。
また、三権分立の核となるのが、QAマネージャーが毎月作成するレポートでした。
（※QAマネージャーが毎月作成しているレポートです。個人名への配慮のため、名称を変更しています。）
ただ数字を並べるだけではなく、「このチームは明確に改善している」「活動量が不足しているわけではないが手戻りが多い」「レビューの偏りが顕著」といった 解釈まで踏み込んで言語化してくれるので、このレポート自体が個々の振り返りの鏡 であり、組織としての 改善テーマを決める指針 にもなっています。
この月次レポートが、可視化されたプロセス改善の土台になったと言っていいと思います。
Findy CSという第三者評価が加わり、改善サイクルがさらなる強化へ
守本：そこに加わったのが、Findy Team+のカスタマーサクセス（CS）による第三者評価です。
毎月のレポートレビューでCSが参加し、
- QAでも見落としていた兆候
- 数値の異常値
- プロセスの歪みや再発傾向
といった点を、完全な外部視点で指摘してくれます。内部だけではどうしてもバイアスがかかりますが、CSが入ることで「外から見ても不自然」が明確になる。その結果、組織内に自然と緊張感が生まれました。
フリーランスも含めた「牽制」と「フェアさ」を担保する
ーーフリーランスエンジニアのマネジメントにもお使いいただいていますよね。
守本：今もフリーランスエンジニアを結構使っているのですが、基本は時間課金です。そうすると、アクティビティが見えないと不正の温床になりかねない。
Findy Team+でPRの数や活動量が見えることで、
- 明らかに活動していない人がいれば気づける
- 逆に、ちゃんと貢献している人も可視化される
という意味で、牽制とフェアさの両方を担保する仕組みになっています。
「活動量が不足している人を見つける」というより、頑張っている人がきちんと評価される状態をつくるために使っている、という感覚に近いです。
データドリブン文化と KPI ハックのせめぎ合い
ーー 「データドリブンな文化」と「数字のハック」の話もよくしていましたよね。
守本： 数字が見えるようになると、どうしても指標をハックしようとする動きは出ます。デプロイ数だけ増やすなど、数字だけ良く見えるケースですね。でも、それは KPI を設計する側の責任 だと思っています。
違和感があれば指標を調整するし、デプロイ数を見るなら手戻り率もセットで確認する。数字と実態を常にすり合わせています。
Findy Team+の活用方法──レビューなしゼロへ。透明性が支える開発生産性向上のインパクト
ーー Findy Team+の導入で、まず最初にどんな変化が起きましたか？
守本：一番大きかったのは、問題を課題として認識できるようになったことです。導入前は、レビューなしマージ、巨大 PR、レビュー滞留などが「気がする」レベルでしか語れず、構造的な把握ができていませんでした。
そこでFindy Team+を軸に、次の4つの施策をセットで進めていきました。
- レビューなしマージを定期的に洗い出す（Findy Team+）
- 具体的な事例を会議で振り返り、再発要因を特定する
- GitHub のルールを見直し、レビュー必須 を仕組みとして定着させる
- 新人やフリーランスを含めた全員に継続的に教育する
この「プロセス整備 × 教育 × 仕組み化」の三点セットが効き、レビューなしマージは最終的にゼロになりました。
口頭の注意だけでは絶対に直らず、 データと仕組みでしか改善は前に進まないということを痛感しました。
サイクルタイムのばらつきが減り、PR活動が健全化
守本：定量的な面では、
- サイクルタイムのばらつきが大幅に縮小
- レビュー滞留が確実に減少
- PRの粒度が整い、巨大PRが激減
このあたりは明確に改善が見えた部分でした。さらに、五つのプロダクトを同時並行で開発しているにもかかわらず、以前は「もっと人を増やさないと回らない」と思っていたところが、実際には人数を増やさずとも安定して回るようになった。
定量的に厳密な測定は難しい部分もありますが、開発スピードが確実に上がっている手触りがありますし、今のチームで回るという事実そのものが、生産性向上の証拠だと思っています。
経営層まで浸透した「透明性」と、スケールに耐えるマネジメントモデルへ
ーーFindy Team+のデータやレポートは、御社の中でどのレベルまで共有されているのでしょうか？
守本：かなり上層部まで共有しています。インド側の社長、日本側の役員にも毎週報告していますし、「Solwer はこういうツールを使ってプロセスを管理している」というのは経営層共通の認識になっています。
また、日本から頻繁に視察も来ますが、全員「ここまでマイクロマネジメントを仕組み化できるのか」と驚かれます。
ただ、私が細かく管理しているのではなく、三権分立（BizDev／開発／QA）で牽制させる仕組みにしている点が特に評価されています。
これは 属人化させないという意味でも重要で、マネージャーが交代しても組織が揺れない体制をつくるための工夫です。
今後の展望──私が抜けても回る組織へ。スケール対応のマネジメントモデル
ーー守本さんがアメリカ拠点に移られると伺いましたが、インド拠点の運営は今後どのようにしていくお考えですか？
守本：本当はインド人メンバーに引き継ぐことが理想でしたが、組織が急拡大する中で、プロセスの運用がまだ完全には安定しきっていない部分もあり、次も日本からの出向者に任せることにしました。
私はアメリカで Solwer の展開を担当しますが、インド開発との連携は続きますし、UNIDOの補助金もKPIの達成が必須なので、責任を持って達成しにいきます。
最終的にはアメリカ（企画・事業） × インド（開発） × 各国拠点（R＆D・営業）のグローバルモデルを見据えています。
グローバル展開に向けた「共通言語」としての Findy Team+
ーー今後、Findy Team+をどのように活用したいと考えていますか？
守本：アメリカ展開が始まるので、グローバルの共通ダッシュボードとして使っていきたいです。リモート前提の体制ですし、新しい開発拠点が増えるほど 共通のプロセス指標が必須になります。
また、今は AI エージェントを使った開発自動化にも取り組んでいて、将来的には 「どのエージェントが最も効くか」も Findy のデータで評価できるのではないかと思っています。
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます
デンソーが挑む“インド発グローバル開発”Findy Team+で実現した“共通指標”によるマネジメント改革
モビリティ産業の変革を背景に、インドで新規デジタル事業を立ち上げたデンソー。インド人エンジニアを中心に構成された開発チームの拡大とともに開発プロセスの属人化やブラックボックス化が課題となる中、Findy Team+ による開発生産性の可視化が、共通言語による改善文化を支えています。
今回は現地責任者の守本さんに、事業立ち上げの背景と組織変革のリアルを伺いました。
プロフィール
守本 剛
デンソーインターナショナルインド Vice President
自動車部品メーカーのデンソーに2008年入社。新興国におけるモビリティサービスの企画・戦略立案業務を担当していた2017年に、市場調査のため初めてインドを訪問。2019年よりデンソー・インターナショナル・インドへ赴任。
「自動車産業の100年に一度の変革期」に挑む──インド市場を見据えた新規事業立ち上げの原点
ーーインドで新規事業を立ち上げるまでの背景を教えてください。
守本：私がインドと関わり始めたのは 2017年頃です。当時、自動車産業は“100年に一度の変革期”と言われ、Uberなどのモビリティサービスが急成長していました。
私は日本の技術企画部（全社の技術戦略をつくる部署）にいて、「モビリティサービスの時代に、デンソーはどう生き残るか」という戦略立案を担当していました。
ハード×ソフトからソフト集中へ──スピードと構造課題が導いたSolwer誕生のターニングポイント
ーー当初はハード×ソフトの構想だったと伺いましたが、そこからどう現在の事業モデルにつながっていったのでしょう？
守本：デンソーには空調・冷却技術という強みがあり、車載用空調製品は世界シェア1位。その技術を活かせば新興国で新しい価値を生み出せるのでは、という仮説から始まりました。
私は、インドにおけるデータ活用型コールドチェーン構築の実証事業の中で、業務可視化を含むハード×ソフトのPoCに関わってきました。
こうした取り組みを通じて、低温物流領域での新規事業の可能性を探っていました。
ーーそこからソフトウェア中心へ大きく舵を切られたわけですが、何が転機になったのでしょう？
守本：ソフトへ舵を切った転機はスピードの差でした。
ソフトは週単位で改善できる一方、ハードはソフトと比べて開発や修正に時間がかかります。さらにコロナ禍の影響もあり、市場で学びながら事業をつくる段階でハードが足かせとなったため、「まずはソフトに集中すべき」と判断し、ソフト一本で進む決断をしました。
1,000億円規模を見据えた事業戦略──Solwer（ソルバー）が描くリバースイノベーション戦略
守本：トップダウンで「100億ではなく1,000億円規模の事業をつくる」という目標が掲げられたことで、アプリ単体では達成できず、産業構造そのものを変えるプラットフォームが必要だと明確になりました。そこで複数プロダクトを共通基盤で展開するマルチプロダクト型構想が生まれ、Solwer（ソルバー）が誕生しました。
Solwer は、製造改善・物流最適化・GHG可視化・アフターマーケット統合・AIデジタルインスペクションなど、製造・モビリティ領域の複数アプリを一つの基盤で動かす統合デジタルプラットフォームです。現在、経産省・UNIDOの支援のもと2027年の社会実装に向けて進行しており、その後はインド全土からグローバル市場へ拡大していきます。
低コスト・高競争力のサービスをインドでつくり、そこから世界へ届ける。それがSolwerの挑戦です。
（引用：インドで成功する日本企業の共通点と、電通とドリームインキュベータの共創力）
属人化と文化の壁を乗り越えるために──データドリブンで進める開発プロセス可視化の第一歩
ーーSolwerの開発体制を拡大していく中で、どんな課題が顕在化していったのでしょう？
守本：Solwerの開発体制が拡大する中で明らかになったのは、「プロセスが整わないまま組織だけが急成長した」ことでした。初期は少人数で対応できていたものの、人が増えるとスキル差やガバナンスの必要性が一気に浮上し、外部ベンダーの活用も文化や進め方の違いでうまく回らない状況が続きました。
特に大きかったのが、ハードウェアを前提としたものづくりの開発プロセスと、ソフトウェア開発との時間軸の違いでした。また、複数プロダクト開発が同時に進む中で、どこで進捗が止まっているのか分からないブラックボックス化が進んでいきました。
ちょうどその頃、河島さん（ファインディ株式会社 海外事業責任者兼 CFO）とお話しする機会があり、「属人的な判断には限界がある」という認識で一致しました。ただ、着手ポイントはまだ明確ではなく、まずは事実を可視化する仕組みが必要だという整理に至り、GitHubやJiraのデータを基盤にプロセスを見ていく方向性が見え始めた段階でした。
「気がする」からの脱却──共通言語としてのデータ可視化で意思決定の精度を高める取り組み
ーー「事実を捉える仕組み」が必要だと強く感じた背景には、現場で具体的にどんなことが起きていましたか？
守本：当時の議論はすべて「気がする」で進んでいました。
「速い気がする」「遅れている気がする」「レビューが止まっている気がする」──しかし実際どこがボトルネックなのか誰も説明できない。私たちは 「データドリブンで社会課題を解決する」というビジネスを作っているのに、肝心の自分たちの開発プロセスには数字が出てこない。これは正直、すごく大きな矛盾でした。
遅いと言うなら、どこが遅いのか？60％進捗と言うなら、何をもって 60％なのか？レビューに時間がかかっていると言うなら、どこの工程なのか？
誰も答えられない。だから、チームによって認識も判断基準もバラバラになる。
ーー多拠点・多国籍で進める開発では、なおさら 「共通言語がないと意思決定できない」という問題もありますよね。
守本：Solwer は各国拠点、正社員、フリーランス、ベンダーが混在する体制で、しかも複数のプロダクト開発が同時に走っています。この状況で「どこを優先するか」「どのチームを改善するか」を判断しようとしても、感覚だけではもう限界でした。
特に象徴的だったのがレビュー遅延です。そもそもレビューが出ているのかどうかすら把握できない。誰が止めているのかも分からない。中にはレビューを通さずにマージしてしまっているケースまであって、もはや議論が成立しない状態でした。
ーー「数字がないから進めない」のではなく、「数字がないせいで間違った意思決定をしてしまう」可能性もあります。
守本：本当にその通りです。だからこそ、「まずは事実を見よう」と。GitHub と Jira のデータを分析して、客観的にプロセスを把握する必要があると強く思いました。
そこで 「どの工程で詰まっているのか」 「チームごとの成熟度がどう違うのか」 をまず可視化しようという話になり、Findy Team+の導入を前向きに検討し始めたわけです。
“Yesだが動かない”チームの文化と、導入初期に直面した静かな抵抗
ーー実際に Findy Team+を導入しようとした際、現場ではどんな反応がありましたか？
守本：本当に大変でした。というのも、私のチームの特徴として “表面的には Yes だが、行動は No” ということがよく起きます。ミーティングでは全員が前向きに「Yes」と言う。でも翌週に状況を見ると、実際には何も変わっていない。
ーー会議ではポジティブなのに、実行が伴っていないように見える場面は多かったですよね。
守本：明確に反対はせず、表向きは「Yes」と言いながら裏では動かず、理由を後付けして実行しない。コンフリクトを嫌う文化ゆえに正面から「No」とは言わないものの、行動は真逆でした。Findy Team+の管理もまさにそのパターンでした。巨大プルリクエスト（PR）は避けて、レビューを必ず入れてくださいと指摘すると、ミーティングでは「Yes」「やります」と言う。でも翌週見てみたら、巨大PRはそのまま、レビューは依然として入っていない。
ーー現場のメンバーと握っていたはずなのに、守本さん側には一切伝わっていないこともありましたよね。
守本：合意した内容が、各チームの判断や優先順位の中で調整され、結果として「実はやらない」という判断が現場で起きていることに、マネジメント側が気づけない場面がありました。
もし Findy Team+がなかったら、「現場が Yes と言っているなら大丈夫だろう」と思い込んで、実際はまったく動いていない。そんな状況に確実に陥っていたと思います。
組織が拡大すると、誰が本当に動いていて、どこが止まっているのかが一気に見えなくなる。少人数なら勘で把握できていたブロッカーも、組織が大きくなると一瞬でブラックボックス化します。そこにYes と言うが動かない文化が重なると、もう完全にカオスです。
だからこそ、「感覚ではダメだ。数字で判断するしかない」と腹を括りました。数字は嘘をつかない。組織拡大の課題を乗り越えるためにも、Findy Team+を軸に事実ベースで運営する体制へ切り替えたことは大きな転機でした。
Findy Team+の活用方法──共通ダッシュボードで実現する自走と牽制の仕組み
ーー 開発プロセスを可視化する中で、守本さんご自身は、どんなポイントを見ているんでしょう？
守本： GitHubやJira自体はすでに活用していましたが、そこに蓄積されたデータを、どの視点で見れば開発プロセスの課題が浮かび上がるのかについては整理できていませんでした。
そこでまずは、Findy Team+のカスタマーサクセスの皆さんに、本当に基礎の基礎から丁寧に教えてもらいました。
プルリクエストの数やコードの変更量、プルリクを出してからマージされるまでの時間（サイクルタイム）といった指標を追っていくと、「PRは出ているのにレビューがまったく行われていない」「レビュー依頼からマージまでが異様に長い」といった、基本の基本でつまずいているポイントが一気に可視化されました。
ーー最初ご一緒したときも、「そもそもレビューしていないPRが結構ありますよね」というところからでした。
守本：レビューなしのマージは、口頭で「やめましょう」と言っても全然減りませんでした。むしろ抜け道を作ろうとする動きが出てくる。
そこで発想を変えて、仕組みそのものを変える方向にしました。単に注意するのではなく、
- Findy Team+上で「レビューなしマージ」を可視化する
- スプリントレビューや定例の場で、具体的なPRを画面に映しながら議論する
こうした取り組みをセットで回すことで、ようやく改善が進んでいきました。
言い続けるだけでは絶対に直らない。ツール・プロセス・教育の三点セットで変える必要があった。これは大きな学びでした。
GitHub × Jira × Findy Team+ で実現する事実ベースの対話
ーー今は GitHub と Jira の両方をつないでいただいていますが、どんな使い方になっていますか？
守本：GitHub と Jira を Findy Team+に全部つないで、Solwer 全体の開発状況を一つのダッシュボードで見られるようにしている、というのが今の形です。
これらを一枚の絵として可視化し、スプリント計画やレビュー会議では必ずこのダッシュボードを起点に議論するという運営にしています。「なんとなく忙しい」「なんとなく遅い」といった曖昧な言葉ではなく、
- どのチームのサイクルタイムが悪化しているのか
- レビュー滞留がどのプロダクト／どのメンバーに偏っているのか
- 巨大 PRがどこで頻発しているのか
といった 事実ベースの対話 に完全に切り替わりました。この「共通指標で語れる状態」が、組織にとって非常に大きな価値でした。
マイクロマネジメントから「QA による三権分立」で支える自律的な開発体制へ
ーー 守本さんご自身が毎日のようにダッシュボードを見て、分析しているのでしょうか？
守本：当初はそうでした。ただ途中でマネージャーが全部見て全部指摘していたら、いつまでも組織が自走しないと感じ、途中からは、QAチームを独立させて、「プロジェクト品質の責任」もQAに持たせる形にしました。プロダクトのバグだけじゃなくて、開発プロセスの品質も含めて QAの責任にしました。
イメージとしては、
- ビジネス／事業開発
- プロダクト開発
- QA（品質保証）
そして Findy Team+のデータについては、「QAがきちんと見ていなければ QAに責任が返ってくる」という明確な役割分担にしました。
また、三権分立の核となるのが、QAマネージャーが毎月作成するレポートでした。
（※QAマネージャーが毎月作成しているレポートです。個人名への配慮のため、名称を変更しています。）
ただ数字を並べるだけではなく、「このチームは明確に改善している」「活動量が不足しているわけではないが手戻りが多い」「レビューの偏りが顕著」といった 解釈まで踏み込んで言語化してくれるので、このレポート自体が個々の振り返りの鏡 であり、組織としての 改善テーマを決める指針 にもなっています。
この月次レポートが、可視化されたプロセス改善の土台になったと言っていいと思います。
Findy CSという第三者評価が加わり、改善サイクルがさらなる強化へ
守本：そこに加わったのが、Findy Team+のカスタマーサクセス（CS）による第三者評価です。
毎月のレポートレビューでCSが参加し、
- QAでも見落としていた兆候
- 数値の異常値
- プロセスの歪みや再発傾向
といった点を、完全な外部視点で指摘してくれます。内部だけではどうしてもバイアスがかかりますが、CSが入ることで「外から見ても不自然」が明確になる。その結果、組織内に自然と緊張感が生まれました。
フリーランスも含めた「牽制」と「フェアさ」を担保する
ーーフリーランスエンジニアのマネジメントにもお使いいただいていますよね。
守本：今もフリーランスエンジニアを結構使っているのですが、基本は時間課金です。そうすると、アクティビティが見えないと不正の温床になりかねない。
Findy Team+でPRの数や活動量が見えることで、
- 明らかに活動していない人がいれば気づける
- 逆に、ちゃんと貢献している人も可視化される
という意味で、牽制とフェアさの両方を担保する仕組みになっています。
「活動量が不足している人を見つける」というより、頑張っている人がきちんと評価される状態をつくるために使っている、という感覚に近いです。
データドリブン文化と KPI ハックのせめぎ合い
ーー 「データドリブンな文化」と「数字のハック」の話もよくしていましたよね。
守本： 数字が見えるようになると、どうしても指標をハックしようとする動きは出ます。デプロイ数だけ増やすなど、数字だけ良く見えるケースですね。でも、それは KPI を設計する側の責任 だと思っています。
違和感があれば指標を調整するし、デプロイ数を見るなら手戻り率もセットで確認する。数字と実態を常にすり合わせています。
Findy Team+の活用方法──レビューなしゼロへ。透明性が支える開発生産性向上のインパクト
ーー Findy Team+の導入で、まず最初にどんな変化が起きましたか？
守本：一番大きかったのは、問題を課題として認識できるようになったことです。導入前は、レビューなしマージ、巨大 PR、レビュー滞留などが「気がする」レベルでしか語れず、構造的な把握ができていませんでした。
そこでFindy Team+を軸に、次の4つの施策をセットで進めていきました。
- レビューなしマージを定期的に洗い出す（Findy Team+）
- 具体的な事例を会議で振り返り、再発要因を特定する
- GitHub のルールを見直し、レビュー必須 を仕組みとして定着させる
- 新人やフリーランスを含めた全員に継続的に教育する
この「プロセス整備 × 教育 × 仕組み化」の三点セットが効き、レビューなしマージは最終的にゼロになりました。
口頭の注意だけでは絶対に直らず、 データと仕組みでしか改善は前に進まないということを痛感しました。
サイクルタイムのばらつきが減り、PR活動が健全化
守本：定量的な面では、
- サイクルタイムのばらつきが大幅に縮小
- レビュー滞留が確実に減少
- PRの粒度が整い、巨大PRが激減
このあたりは明確に改善が見えた部分でした。さらに、五つのプロダクトを同時並行で開発しているにもかかわらず、以前は「もっと人を増やさないと回らない」と思っていたところが、実際には人数を増やさずとも安定して回るようになった。
定量的に厳密な測定は難しい部分もありますが、開発スピードが確実に上がっている手触りがありますし、今のチームで回るという事実そのものが、生産性向上の証拠だと思っています。
経営層まで浸透した「透明性」と、スケールに耐えるマネジメントモデルへ
ーーFindy Team+のデータやレポートは、御社の中でどのレベルまで共有されているのでしょうか？
守本：かなり上層部まで共有しています。インド側の社長、日本側の役員にも毎週報告していますし、「Solwer はこういうツールを使ってプロセスを管理している」というのは経営層共通の認識になっています。
また、日本から頻繁に視察も来ますが、全員「ここまでマイクロマネジメントを仕組み化できるのか」と驚かれます。
ただ、私が細かく管理しているのではなく、三権分立（BizDev／開発／QA）で牽制させる仕組みにしている点が特に評価されています。
これは 属人化させないという意味でも重要で、マネージャーが交代しても組織が揺れない体制をつくるための工夫です。
今後の展望──私が抜けても回る組織へ。スケール対応のマネジメントモデル
ーー守本さんがアメリカ拠点に移られると伺いましたが、インド拠点の運営は今後どのようにしていくお考えですか？
守本：本当はインド人メンバーに引き継ぐことが理想でしたが、組織が急拡大する中で、プロセスの運用がまだ完全には安定しきっていない部分もあり、次も日本からの出向者に任せることにしました。
私はアメリカで Solwer の展開を担当しますが、インド開発との連携は続きますし、UNIDOの補助金もKPIの達成が必須なので、責任を持って達成しにいきます。
最終的にはアメリカ（企画・事業） × インド（開発） × 各国拠点（R＆D・営業）のグローバルモデルを見据えています。
グローバル展開に向けた「共通言語」としての Findy Team+
ーー今後、Findy Team+をどのように活用したいと考えていますか？
守本：アメリカ展開が始まるので、グローバルの共通ダッシュボードとして使っていきたいです。リモート前提の体制ですし、新しい開発拠点が増えるほど 共通のプロセス指標が必須になります。
また、今は AI エージェントを使った開発自動化にも取り組んでいて、将来的には 「どのエージェントが最も効くか」も Findy のデータで評価できるのではないかと思っています。
※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます
