エンジニアを支援するプラットフォームを提供するファインディ
ファインディはエンジニア転職サービス「Findy」や開発データを意思決定に活かす、経営と現場をつなぐAI戦略支援SaaS「Findy Team+」など、エンジニアを支援するプラットフォームを提供している企業である。
セッション冒頭、ファインディの渡邉氏は自身の経歴と「Findy Team+」を紹介した。
渡邉氏はサンマイクロシステムズ、プリファードインフラストラクチャー、トレジャーデータ、MODEを経て24年にファインディに入社。「テック企業で営業やマーケティング、デベロッパーコミュニケーションなどを担当してきました」（渡邉氏）
同社が提供する「Findy Team+」はGitHubのようなソースコード管理ツール、Jira、Notionのようなタスク管理ツール、AIエージェントツールなど、ソフトウェアエンジニアが利用するDevOpsツールと連携して、開発ワークフローや生成AIによる開発状況を可視化することで、開発効率や開発者体験を最大化するための課題を発見、改善を支援する。ダイキン工業は同サービスを導入し、開発生産性の計測に活用している。
「PoCで終わるプロダクト開発」からの脱却──内製開発チーム立ち上げの背景にあった危機感
ダイキン工業では現在、アジャイル開発の内製化を進めている。それを牽引しているのが、森鳰氏だ。
森鳰氏は2016年にAI機械学習エンジニアとしてダイキン工業に入社し、研究開発に従事していた。研究職だった森鳰氏が内製開発チームを立ち上げるきっかけとなったのは、「自分の関わった技術のプロダクト化をしようとしても日の目をみることなく、PoCで終わってしまっていた。事業貢献に繋がらない原因を探ってみると、ソフトウェア開発が自社のコントロール外にあることが問題に見えたこと」だった。
具体的には、企画側が「こんなプロダクトを作ればこんな顧客価値が提供できるのでは」と仮説を立てて仕様書を作っても、その後はベンダー委託をしてしまうため、実際の顧客価値を検証することがほとんどないまま進展し、最終的には失敗してしまう経験が何度もあった。
そこで森鳰氏はプロダクトのすべてを一貫して取り組むためにソフトウェアエンジニアに転身。2019年に森鳰氏を含め未経験者4人で内製チームを立ち上げた。「ターゲットにしたのは事業部が進めていた補助金事業です。このままだと事業を畳まざるをえないほど工数がネックになっていました。私たちはその状況を見て、完全なプロダクトを作るのではなく、一日でも早く彼らの業務を楽にしようと業務の整理や自動化をして、最終的に従来工数の9割を削減しました」（森鳰氏）
そのような取り組みの結果、2020年に補助金制度に頼らない事業として商材化したのが、「EneFocusα」である。EneFocusαは空調機の遠隔監視・省エネをサポートするエネルギーマネジメントのサブスクリプションサービスだ。
ダイキン工業では空調機を納入したビルに対して、空調の使用状況に関するデータを収集している。「EneFocusα」を活用することで、収集したデータを分析して空調の使用状況の無駄や不要な運転している箇所を特定し、最適な運用を提案している。「1つのビルに対して約20％弱の省エネ、節電効果があります」（森鳰氏）
商材化できたことで、内製化チームのメンバーも増やし、適用先を拡大。その過程で得られた知見を共有するために、2023年には社内向けの開発者コミュニティ、2025年にはアジャイル内製センターを立ち上げた。アジャイル内製センターは事業部横断型のプロジェクト型仮想の組織で、「今は正式な組織ではなく、有志で組織を構成しています」と森鳰氏は説明する。
組織上はデータ推進グループに所属しているが、事業部の人たちと共通のチームを作って、事業計画に基づいたプロダクト開発を加速する。アジャイル内製センターでは事業に関するものをすべて内製するわけではなく、空調のコア事業に関するところの内製化を推進している。現在は20人弱のメンバーが所属する組織になっている。
アジャイル内製センターの特徴は、「イベントへの登壇など、社外活動を積極的に行っていること」と森鳰氏。外部へのPRや外部人材との交流を増やす目的ではあるが、「発表することでうまくいったこと、うまくいかなかったことの再整理ができるので、自分たちにとっても学習になる。また話すことで客観的なフィードバックがもらえる」と、もう1つの狙いを説明する。「スクラムやアジャイルなどのイベントを中心に、品質や製造関係、ファインディが主催するイベントにも登壇させていただいています」（森鳰氏）
認知負荷の拡大、チーム間の衝突、ステークホルダーとの関わり──組織拡大の過程にあった3つの課題
組織を拡大する上での苦労や課題を渡邉氏が質問すると、森鳰氏は「3つの課題がありました」と続けた。
第1の課題はサービス拡大に伴う認知負荷の増加だ。アジャイル内製センターは、サービス拡大のためにメンバーを増員しながら活動してきた。開発人員が増えてプロダクトも成長していく一方で、開発側の認知負荷が増加していく問題が発生した。「メンバーを増やしてもシステムが複雑化していくため、チームで扱っているドメインの領域が広がり、考えるべきこと、知るべきことが増えてしまった」と当時のチームの状態を振り返る。
この状況を打破するため、森鳰氏たちはチームを分解し、特定のユーザータイプに注力できる環境をつくりチームを再構成した。
図に表すと簡単に見えるが、「実態はドメインの戦略的部分を一つ一つ丁寧に整理する必要があった」と森鳰氏は明かす。例えば依存関係の整理はその1つ。「どこに境界を設けるべきか、どのチームがどのドメインを持つべきかなどについて一つ一つ議論して切り替えていきました」（森鳰氏）
こうして認知負荷の課題は緩和したが、チームを切り分け、数が増えたことで、「チーム間の衝突が増えてしまった」と森鳰氏は話す。これが第2の課題だ。「特に我々の場合は、各チームが自律してリリースまでを担当する。このような自律性が高いチーム同士の場合、さらに衝突が起きやすい可能性がある」と森鳰氏は言う。
いくらドメインの境界を設けても、他のチームの協力がないと実現できないものの場合、優先度が衝突する。また、他チームの意思決定に対する納得性は低くなりがちだ。技術選定はその代表例だろう。さらに、所属チーム以外に関心が薄れてしまうということもある。
このような自律性の重視による課題に似た話として、森鳰氏は「仕事のやり方に一貫性がないと人材の異動は難しくなり、悪化すると一つの組織で動いている感じがしなくなる」というSpotifyモデルに対する批判を紹介。「他のチームに異動しづらくなることは、組織のサイロ化が避けられなくなり、チームの学習も妨げられるなどの副作用がある。それが問題だと感じていました」（森鳰氏）
そこで森鳰氏は、なぜ自律性を重視すると、仕事のやり方に一貫性がなくなるなど、弊害を引き起こしてしまうのか、仮説を立てて検証していった。
立てた仮説は2つ。1つは自律性の意味することがチームごとに異なること。もう1つは各チームの自律性で網羅されていない組織の課題があることだ。検証方法として採用したのは、デリゲーションポーカーの考えをベースとした、チーム自体の権限を整理する方法だ。「デリゲーションポーカーは7つのレベルで権限を切り替えて合意をとっていくが、私たちは4つぐらいに絞って行いました」（森鳰氏）
具体的には「チーム内で決められること」「チーム間で合意が必要なこと」「決められないこと」「チームの自律性によって実現しないもの（暗黙知、属人性）」の4つである。「チーム間で認識が揃っていないことを、きちんと揃えていき、揃っていることを確認していきました」（森鳰氏）
揃っていないことが確認されていくことで、良いこともあった。「チームに求められる能力や権限、スキルなどが明らかになったので、例えば組織を拡大するために新しくチームを増やす場合、チームとして成立する条件の目安になりました」（森鳰氏）
一方で、統一による制約はチームの自由度を下げることにもなる。例えば組織で使う言語をPythonに限定したとする。プラスの側面としては、Pythonに関する1つの改善が全チームに影響するため、チーム数分の効果が得られる。一方、Pythonしか使えないのであれば、「辞めます」という人が出てくるかもしれない。
オライリーの『エンジニアリング統括責任者の手引き』に、「働き方にはそれぞれ多くの暗黙のトレードオフがあり、そうしたトレードオフのプロセスにフラストレーションを感じている人には見えていないことが多い」と記されているように、フラストレーションを感じている人は負の側面ばかり見えてしまうからだ。
これを防ぐ方法として、森鳰氏が挙げたのが、権限整理のプロセスにメンバーを参加させること。そうすることで納得感が得られ、制約の意図が理解できるようになる。
第3の課題はステークホルダー（事業部）との関わりだ。「内製している企業の中には、事業部からの受注関係になってしまっているケースもあるのではないか」と森鳰氏は問いかける。実際、森鳰氏のチームもそういう状況に陥っていた。というのも、当時は開発の優先度が事業部側の課長に委ねられており、チーム側で立てたプロダクトオーナー（PO）は、開発チームとの調整役だったという。
この状況を解消するために、まずは事業部からPOやエンジニアを出してもらってチームを構成。社外の内製開発チームの交流会に事業部のメンバーを招待したり、カンファレンス登壇に同行してもらったり、スクラムワークショップに一緒に参加してもらった。こうすることで、最終的には事業部の課長を含む開発チーム全体で、共通言語を持ちプロダクトを議論することができるようになった。
開発生産性スコアが、内製改革を進める根拠の1つに
「これら3つの課題について、開発生産性という観点で捉えることもできるのか」と渡邉氏が問いかけると、森鳰氏は1つ目の課題である、サービス拡大に伴う認知負荷の増大については、指標から問題に気づく、または改善の検査は可能だと話す。「良くない状況に陥っていないか、Negative Indicatorとしての検査、または相対的な変化、相互関係による検査を実施しています」（森鳰氏）
実際、森鳰氏たちがチームの再構成をするまでは、稼働人数とリードタイムの相関性が高く、人数を増やしてもうまくいかない状況がわかった。そこでチームを再構成したところ一気に変化。一時は変更のリードタイムが伸びたこともあったが、今は落ち着いており、「大きな問題を抑えながら組織の拡大ができるようになった」と森鳰氏は語る。
2つ目のチームの自律性と開発組織化という課題に対しては、数値計測で確認できなくてもマネジメントすべきだと話す。何とかすべきと感じたのなら、実際に行動に移してしまってもいいと考えている。
3つ目のステークホルダーとの関わりという課題については、アウトプットを追っていくと逆効果になる可能性があると指摘。アウトプットを見ていても事業部との関わりの課題は見つからないし、直近のアウトプットを上げるために課題解決や探索に時間が使えなくなる可能性があるからだ。「改善に時間を充てると、一時的にアウトプットは落ちるかもしれません。ですがそれによってアウトプットが下がるのは当たり前なので、どのくらい下がったか計測して覚えておきましょう。そうすれば将来、改善する際、いつどのくらい時間を充てればいいか判断できると思います」（森鳰氏）
これまでダイキン工業では、事前に要件を定義して外部に開発を委託する傾向にあった。だがこれからは状況の変化に合わせて継続的に内製改革をしていくと話す。その根拠の1つとなるのが開発生産性スコアである。「継続的な開発の必要性を事実として示すことは、経営層への説明に効果的ではないかと考えています」（森鳰氏）
また内製開発を進めるには、社外の人たちと取り組み内容を共有していくことも大事だと言う。森鳰氏がカンファレンス経由で知り合った企業を中心に交流会を実施したところ、講演では聴けない込み入った話を聞けるなど、知見が得られたからだ。「もっとこの場を拡大させたい」と考えた森鳰氏は企業の枠を超えた内製開発コミュニティを発足。Discordサーバーで議論の場を提供するほか、企業間交流会の促進もしている。「ぜひ、興味のある方は参加してほしい」と最後に呼びかけ、セッションを締め括った。
