## テクノロジーを駆使して生活者が主役となる医療体験の実現を目指すPharmaX

__――まず最初に、皆さまのこれまでの主な経歴や、現在の業務内容について教えてください。__

__上野__：大学・大学院在学中の頃は研究室やインターンなどに取り組んでいました。その過程でやりたいことを実現していくために、統計や機械学習、データ分析、アプリケーション開発を独学で習得しました。2018年に新卒でコンサルティングの会社に入社した後、同年にPharmaXを共同創業しました。立ち上げ初期から開発を担当してきて、今は2事業部のチームを統括する傍ら、生成AI/LLM（大規模言語モデル）を駆使した事業推進・情報発信にも取り組んでいます。

__古家__：新卒でニフティ株式会社に入社、新規事業開発部でのスタートアップ支援やベトナムでのオフショア組織立ち上げ・マネジメントなどを経験しました。退社後にフリーランスとして独立してITスタートアップのグロース支援に従事してから、PharmaXにジョインしています。PharmaXに入社してからはデータエンジニアとしてのダッシュボード整備・データ活用推進に始まり、スクラムマスターを経てエンジニアリングマネージャーを担当しています。

__江田__：趣味の延長でプログラミングをするようになったのがきっかけで、在学中からバックエンドエンジニアとしてPharmaXでインターンをしていました。率直な意見を言える社風だったり、ミッション・バリューへの共感もあって大学卒業後にそのまま入社しました。入社後は、創業事業である「YOJO」の唯一の専任者として従事し、現在はスクラムマスターなども担当しています。

__――PharmaXでは、どのようなミッションを掲げていますか？__

__上野__：「患者満足度世界一」をミッションに、生活者が主役となる医療体験の実現を目指しています。創業事業としてかかりつけ医療ブランド『YOJO』、2022年からは薬局DX事業も展開しています。2023年には専任チーム『PharmaX 生成AI Labs』を立ち上げて、生成AI/LLM（大規模言語モデル）による事業推進・情報発信にも取り組んでいます。

![PharmaX_interview_0508_1](//images.ctfassets.net/ngrpflsbp3rq/3I54YBAqAda8E8cu2VsQ4d/9db570d4341269501a783a13aad21aca/1__.jpg)

## 生産性の可視化を通じて、スピード感と魅力あるエンジニア組織を目指す

__――開発生産性の計測の取り組みを始めた、背景やきっかけを教えてください。__

__古家__：PharmaXのミッションを実現するべく事業計画、さらには日々の施策を達成するためのスピードと質を向上させたいと考えていました。一方でプロジェクトが当初想定していた通りに進められず、期限のリスケや大きなリリースによるバグ発生といった問題が積み重なっていました。

そのため開発の正確な見通しやバグを減らすためにも適切な指標が欲しいと思ったのが、開発生産性の計測を検討し始めたきっかけです。

情報収集していく中で「DevOpsの科学」やt-wadaさんの資料にたどり着き、Four Keys（開発生産性の計測指標）の可視化に取り組むことを推進し始めました。

__――「Findy Team+」の導入前は、開発生産性の可視化に関する取り組みをされていましたか？__

__古家__：オープンソースやGitHubで公開されているライブラリなどを駆使し、独自に内製で計測・可視化しようと試み、その結果リードタイムを改善することはできました。しかしさらに深掘りをするためにデータを取得していこうと考えると保守にかかる工数が大きかったため、最終的には内製で着手することを断念しました。

__上野__：社内には2つの事業部がありますが、エンジニアは事業部を横断するチーム構成の「テクノロジー本部」に在籍しています。エンジニアは業務時間の85%程度で事業部の仕事に着手している一方で、残りの15%程度は組織運営や開発チーム強化に関する取り組みに注力してもらうという体制をとっています。開発生産性についても開発チーム強化の文脈で取り組みを進められていたと思います。

![PharmaX_interview_0508_グラフ1](//images.ctfassets.net/ngrpflsbp3rq/5Izpf6SLSjEEKSG6peEq0J/aee91ee62caf9443f77fc4b3c385c6b7/__.png)

__――「Findy Team+」のことは、どのようなきっかけで知っていただきましたか？__

__古家__：開発生産性の可視化を内製で取り組む傍ら、開発生産性を計測するツールについて調査を進めていく中でFindy Team+のことを知りました。開発生産性を計測できるツールはいくつかありましたが、可視化できる指標・データが充実していて導入事例も多かった点で、Findy Team+の導入を前向きに考え始めました。

__――「Findy Team+」の導入にあたって、社内ではどのように理解を得ていきましたか？__

__古家__：経営陣に対しては、1on1で開発生産性について解説したり、今後の事業拡大に向けて会社として投資する価値を伝えるなどしていました。メンバー向けには指標のロジックについて説明しながら、Four Keysについて理解を得るよう進めていました。一方で、ROI観点での説得や理解を得るための資料作成、といったことはなかったです。開発チームで独自に設定されている「エゴから発展させよ」というバリューに基づいて、自身の実現したいことに周囲を巻き込んでいきました。

__江田__：古家さんが周囲を巻き込んで話を進めていく一方で、メンバー起点でも徐々に開発生産性への関心は高まっていたように思います。毎週個人的な取り組みを発表する場があったことで、生産性に興味をもったメンバーが積極的に可視化を行い、知見をシェアしていました。

__――最終的に「Findy Team+」のどういった部分が導入の決め手になりましたか？__

__上野__：経営観点で言えば、魅力的なエンジニア組織であることを外部に発信する指標・機会としてもFindy Team+を活用し、採用・広報にも活用できるのではないか、というのが導入の決め手となりました。

開発生産性の改善がビジネスの成果に影響を与えるようになるまでには時間がかかりますし、可視化するだけではエンジニア以外を説得するうえで限界があると感じていました。

一方で周囲のスタートアップを見ていると、エンジニアから魅力的な組織ほど開発生産性スコアを公開しているというトレンドがあり、着手しないことはむしろ自社にとってマイナスに影響するように思えました。

そして今の自社開発チームなら対外的に見ても良いスコアを目指せる、「Findy Team+ Award」の受賞も狙えるのではないかと考えました。

__――実際に、2023年1月に実施したアンケートによると、求人応募や転職を考える際に、8割弱の方が開発生産性を重視していると回答しています。__

![PharmaX_interview_0508_グラフ2](//images.ctfassets.net/ngrpflsbp3rq/NyyZINZCpNtTh5Lzypsi0/8e8046be2d60c070843819f1cda23861/__.png)

　　　　　　　　　　　　　　　　（Findy調査より抜粋）

## 数値の可視化で意識・行動が変わり、自信にもつながった

__ーFindy Team+を用いた日々の振り返り・分析などについてお伺いしたいです。__

__江田__：チームでの振り返りは1週間ごとに実施していて、全体の1週間前での数値と目標値とを比較しています。具体的には開発生産性スコアサマリ、デプロイ頻度とリードタイム、チーム内アクティビティ、最近だとレビューサマリも確認しています。

  - 開発生産性スコアサマリ
  - デプロイ頻度とリードタイム
  - チーム内アクティビティ
  - レビューサマリ（オープンからレビューまでの平均時間）

各メンバーとは1on1で個別の振り返りを実施しています。例えばDevOps分析のプルリク一覧をリードタイム順で並び替えてみて、相対的に多かったプルリクを見ながら、ユーザーストーリーを細かく切り分けることを一緒に考えてみたりしています。

__ー開発生産性を組織目標に紐づける中で工夫したポイントがあれば__

__古家__：組織目標として、事業の施策スピードを上げることを目指しているので、リードタイムとプルリク数を開発チームの目標としてます。、具体的にはリードタイム平均23時間以内、プルリク数は1人2件以上/日で設定しており、週次で実施しているスプリント振り返りの際にFindy Team+のダッシュボードを参照しながら振り返りを行っています。
振り返りをするだけでなく、具体的な改善タスクの設定とそれに着手する時間を設定して、個々のプルリク数増加を試みたりしています。

また、各メンバーのOKR目標の管理においても、Findy Team+を利用しています。例えばOKRにプルリク作成数が設定されているメンバーとは、チームコンディション画面などを見ながら1on1で一緒に振り返りをしています。

__ーその他にも開発チームやメンバーの意識・行動における変化などありましたでしょうか？__

__江田__：ちょっとしたコード改修でも数値に反映される体感があり、ゲーム感覚で楽しみながら改善・成功体験に繋げられているように感じます。結果としてチーム全体で前向きなスタンスになり、プルリクを適切なリードタイムで出すようになってきています。

__上野__：リリース速度に対してチームがフォーカスするようになったのは大きかったです。これまでにリリースの重要性を言葉で伝えても組織に浸透しなかったところが、数値として目標が設定されたことでチーム全体での達成意欲が醸成されてきました。

![PharmaX_interview_0508_2](//images.ctfassets.net/ngrpflsbp3rq/6GQOY7MSY00O1lvaofEosP/e12ac2013a8a9f8f8edce19fabc3fa55/4__.jpg)

__ー改善の成果を共有する機会などはありますでしょうか？__

__古家__：毎月末に全社で各チーム・メンバーの1ヶ月の成果を発表・賞賛し合うWin-Session（ウィンセッション）という場があります。先日も、リードタイムが1/10になって開発生産性が大幅に改善したことなどを発表しました。発表の際に使用するドキュメントでもFindy Team+ Labのダッシュボード画像などを引用したりしています。

これまで、最終的なアウトプットでしか経営陣の成果を伝えることしかできなかったのですが、開発プロセスの改善結果を数値で可視化ができるようになったことで、正確に開発組織の成果を伝えることができるようになりました。
その結果、開発生産性の数値改善を通じて経営陣からの信頼獲得につながっているように感じます。

__上野__：開発生産性改善のインパクトが数字として現れていることに対して、社内の開発組織以外でも一定の良い反応が得られていると感じます。

![PharmaX_interview_0508_グラフ3](//images.ctfassets.net/ngrpflsbp3rq/4WhuThOuqnIIOdhN8yu8lE/074d169c44ede52224c6ff0b24e43589/_2.png)

__ーTeam+のおすすめポイントについてもお伺いしてもよろしいでしょうか？__

__江田__：DevOps分析画面でのランク(*)、開発生産性スコアでの偏差値が表示されるのがすごくよいと思っています。開発組織の相対評価を見れるのは、自社開発や他ツールにはなかったTeam+独自の魅力だと感じます。

(*Findy Team+ の画面上に、DORAが開発のスピードと安定性を測る指標)

__古家__：レビュー分析はまさに数値として見たかった内容なのでとても重宝しています。自前で作ろうとした際にかなり困難だった部分でもあります。オープンからレビューまでの平均時間が可視化されたことによってチーム全体のレビューに対する意識が変わったのもよかったです。

__上野__：プロダクトだけでなく、カスタマーサクセスのサポート体制も魅力だと感じています。導入直後のオンボーディングで活用の相談をしていく際も、エンジニアでないとキャッチアップが難しいように思えるテーマも含めて対等に議論できたのは、思わずすごいなと感心してしまいました。

![PharmaX_interview_0508_3](//images.ctfassets.net/ngrpflsbp3rq/4LcsIxUM40C9F4DWyQ9CID/45668c8830412b9e2e056fb45c4697b4/6__.jpg)

## 全社で体感できるインパクトに繋げるべく開発生産性を次のレベルへ

__ー今後チームとしてどんなことにトライしていきたいでしょうか？__

__上野__：エンジニア以外のメンバーも開発生産性向上のインパクトを体感できるぐらいに、改善効果をビジネスにも反映していきたいです。そのためには開発生産性を開発組織だけでなく全社の生産性に紐づく状態まで引き上げていく、成長感の伝わる計測指標を設定する必要があると感じます。

__古家__：直近では開発組織の生産性向上を実現するべく動き始めています。Team+で計測できる指標に加えてテストカバレッジや品質向上なども数値で可視化しようとしています。開発チームの生産性が一定向上した段階であれば、ベロシティを計測しても良いかなと考えていたりします。

__ーチームのアピールポイントについてお伺いしてもよろしいでしょうか？__

__上野__：エンジニアとユーザーとの距離が近い環境です。エンジニアリングだけに閉じずユーザーへの価値提供やPS（薬剤師）チームと連携しながら仕事を進めています。また、技術的なチャレンジに積極的な土壌もあり、生成AIという最先端の技術に積極的に取り組んでいることも強みだと考えています。

__古家__：行動指針の「患者起点」を徹底しつつ、ビジネスのスケールと両立させることを追求している点でしょうか。医療や健康の領域で社会的意義があることを成し遂げたい、インパクトのあることをしたい人に向いていると感じます。

__ー今後一緒に働きたいエンジニア像についても教えてください。__

__上野__：エンジニアリングに閉じず、プロダクトやユーザー価値に意識を向けられる方とご一緒できると嬉しいな、と思っています。

__ー上野さん、古家さん、江田さん、ありがとうございました！__

![PharmaX_interview_0508_4](//images.ctfassets.net/ngrpflsbp3rq/3SJ63GQfOrob6SjO1ozNmO/b2e83e41891fe8b2f39fef809ac3a2f6/7__.jpg)

__※PharmaXでは、『患者満足度世界一』をミッションとして、価値観に共感するエンジニアを募集しています。__
[https://herp.careers/v1/yojo](https://herp.careers/v1/yojo)

__※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。__
[https://findy-team.io/service_introduction](https://findy-team.io/service_introduction)


PharmaX_interview_0508_FV

医療・医薬品領域で2つの事業を展開しているPharmaX株式会社では、2023年12月よりエンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回はCTO上野さん、エンジニアリングマネージャー古家さん、エンジニアの江田さんにインタビュー。導入のきっかけや、リードタイムが1/10に改善するなど早くも成果が現れ始めている背景について、お話を伺いました。

開発生産性の高さを採用戦略の新たな切り口に。8名から開発者体験の向上を目指すPharmaXの取り組み	


## 社内の部門から会社へ。アジャイル開発でDXを推進

__――まず最初に、お二人の主な経歴や現在の役割について教えてください。__

__岡澤__：ソフトウェアエンジニアを経てKDDIに入社し、認証系サービス、セキュリティサービス、IoTサービス、海外スタートアップ企業との新規事業立ち上げなどいろいろとプロジェクトをリードしました。KDDIでアジャイル開発の立ち上げをスクラムマスターとして行った後は、エンジニアリングマネージャーとしてエンジニア育成やビジネスモデル、プロセス、企業文化の変革などを推進してきました。

2022年7月からKDDIアジャイル開発センターの事業開始に伴い、VPoEと開発戦略本部長に就任しました。もともとKDDIのアジャイル推進をしてきた背景もあり、いろいろな役割を担っておりますが、社内の組織をどうしたらより良くしていけるかというところも担っています。まだできたばかりの会社なので、実際に各案件のコンサルにも入るなど、幅広く動いています。

今回の話題に関するところでは、組織をより良くしていき、いかにエンジニアが楽しく働けるかを、きちんと仕組みとして取り入れていくこと。これを振り返りも含めて進めていくところが大きいですね。

__吉村__：メーカーで新規事業担当としてB2Bサービスの開発を行い、企画から開発までの一連のプロセスを経験した後、KDDIアジャイル開発センターに転職しました。

現在は、スマートシティの開発で3つのスクラムチームがあり、その支援をしています。ロールはスクラムマスターですが、一般的に定義されている動き方とは少し違うかもしれません。具体的には、最初期のアーキテクチャを描いたり、先行的な調査をしたり、各チームで解決できない課題に対応したりしています。加えて、顧客との各種調整やエンジニアの採用など、幅広く行っています。

__――アジャイル開発センターの開発組織について教えていただけますか？__

__岡澤__：もともとアジャイル開発センターは、KDDI社内の1つの部門だったのですが、それがそのまま会社になった背景があります。開発組織は5部門あり、パートナーも含めると400人くらいの規模。さまざまなプロダクト、チーム規模のスクラムチームが、40チームほどあります。

そのなかに高輪ゲートウェイスマートシティ開発チームと、auでんきチームの2つがあり、まずはその2チームから「Findy Team+」を導入しています。

__――御社の開発組織では、どのようなミッションを掲げていますか？__

__岡澤__：我々がミッションとして掲げているのは、国内のお客様のDX推進です。そのなかでも大きく2つあって、この両方に取り組んでいます。

1つは内製支援のような形で、実際にアジャイル開発センターのメンバーがチームに入って、育成しながらサービスをつくり上げていく。それが終わったころには、お客様の中でエンジニア組織やアジャイルなマインドができあがっているという流れで、その企業のDXを推進していくものです。

もう1つは、今までウォーターフォールなどのやり方をされてきて、新しいサービスがつくれないお客様がいらっしゃるので、UXデザイナーを含めてビジネス変化に対応しながら開発を進めていくものです。

![kddiagile_interview_0507_1](//images.ctfassets.net/ngrpflsbp3rq/7LrsBcGnYSeGwBdaE6nh4w/2a0d21ff07ecf18704a35a14b32bb22a/1__.jpg)

## 2つの大規模プロジェクトで「Findy Team+」を導入

__――「Findy Team+」導入前にあった課題感や、開発生産性の計測に取り組まれた背景について教えてください。__

__岡澤__：いくつかありますが、エンジニアの働き方をより理解したうえで、1on1に取り組んだり、フォローしたりできるようにしたいというのが、まず1つ。なので、生産性を計測したいというよりは、見える化を進めたいというイメージですね。

また、スクラムは良くも悪くもスクラムのなかで完結してしまえば問題なく、40チームあるので各チームで最適化が進んでいます。ですが、より一層良くしていくために、横との比較ではなく、メンバー同士でお互いに気づきが得られるものがあるといいなと。実際に今、横のチームのベロシティなどは見れるのですが、それとはまた違う気づきが生まれるきっかけをつくりたいと考えていました。

それから、スクラムチームでは、メンバーが固定されてずっと同じチームでいることが理想ですが、実際にはそれは難しく、人が入れ替わるタイミングがきます。そのタイミングでより適切に、エンジニアが働きやすい状態のままメンバーを入れ替えたり、新しいチームをつくったりしたい。そういう場面で、定性的な情報だけでなく定量的な情報まで、今見えている観点以外にも見れたらいいなと思っていました。

__吉村__：「Findy Team+」導入に関しては、岡澤さんから話をもらったのが最初のきっかけでした。ただ、個人的にはもともと可視化にはすごく興味があって。製造業にいたときに、その会社で「測定なくしてコントロールなし」という標語があったんです。それがずっと頭に残っていて、生産性の可視化にはずっと興味を持っていました。

スクラムやアジャイルをやっていくなかで、お互いの不理解もあって、生産性という言葉を頭ごなしに使ってしまうケースがあると思います。生産性という言葉は、過剰に反応されたり嫌われたりしがちな面もありますが、それで終わらせてしまうと、ベロシティで一方的に評価される状況から次のステップに進まないと感じています。

以前はGitHubやJIRAのAPIからデータを取ってきて、ElasticSearchに入れてKibanaで見たりしていたのですが、各チームのブランチ戦略やチケットのワークフローの違いなどがあり、面倒な部分が多くありました。そこはあまり時間をかけるところではないと考えていたので、その部分をカバーしてくれるツールがあるなら、ぜひ入れてみたいと思っていました。

![kddiagile_interview_0507_2](//images.ctfassets.net/ngrpflsbp3rq/49rYcL6dbCgbaAfO2SFSNb/4f60330eb611c8d4254cd2926c2f5c84/2__.jpg)

__――現時点では、各チームで開発生産性をどのように可視化していますか？__

__岡澤__：「Findy Team+」を入れていないチームでは、ベロシティがメインで、リードタイムを取ったりしていることが多いですね。基本的には、JIRAやGitHubをベースに見ています。

__――「Findy Team+」を導入している2チームは、どういった理由から計測を始められたのでしょうか？__

__岡澤__：高輪ゲートウェイスマートシティ開発チームは、新しく立ち上がったチームで、まずはそこから計測を始めました。2つ目のauでんきチームは、電気自由化のタイミングで立ち上がった、2016年ごろから長く続いているチーム。連携チームは3〜4つほどあります。なので、新たに始める大規模プロジェクトと、もとからあった大規模プロジェクト、この2つに入れて進めてみようという考えですね。

それから、auでんきチームは安定してリリースしているチームでもあります。スクラムでは開発生産性のほかに、振り返りで幸福度を測ったりするんですね。生産性と幸福度はチームビルドにとても影響するものなので、単一なプロダクトで、チームがどういう状況であればベストなのかを知りたいというのが、大きな目的の1つでもありました。

## 定量面と定性面の両方を見ていくバランス感が重要

__――最近はFour Keysのほかに、SPACEなどのフレームワークも注目を集めています。御社としても定量面だけでなく、定性面も重視する意識が強いですか？__

__岡澤__：スクラムやアジャイルは、心理的安全性があるうえで、チームで働くことによって安定して開発ができるものです。なぜスクラムマスターがいるかというと、エンジニアが開発に集中できるように、障害物を取り除くため。つまり、エンジニアがエンジニアらしく働けるようにするためなんですよね。これは先ほどお話しした幸福度もそうですが、かなりSPACEの考えに近いところがあります。

ただ、そこってなかなか表現しにくい部分ではあると思うんですよ。チーム開発をしたことがない人は、個別に開発した方が速いと思うかもしれません。でも、もちろん不満やモヤモヤを抱えた状態だと仕事は進みませんが、そういったものがまったくない状態でチーム開発をしていくと、生産性は最も高くなると考えているんです。

「Findy Team+」は、そういったところの一部を見やすくできるものだと思っています。なので、一人ひとりのコミット量を見て、メンバーを監視するような使い方は、まったく想定していません。

__吉村__：幸福度などを測ることも重要な一方で、定性的な指標だけに偏ってしまうと、外から見たときに、ただ仲良くやっているだけに見えてしまう可能性もあります。なので、そういった定性的な指標を追う活動が、定量的にどう効いているのか、不確実性を下げるエンジニアリングにどう寄与しているのかは、開発者として責任を持つ必要がある。そこのバランスが重要だと思っています。

事業部では売り上げなどの数字を、責任を持って追っているじゃないですか。それに対して、開発は何を追っているのかというときに、一例として、我々は開発生産性やリードタイムなど、そういったところに責任を持っていると言えるといいのかなと考えています。

![kddiagile_interview_0507_3](//images.ctfassets.net/ngrpflsbp3rq/4Jy906nFFPJq5b1jxjuiXq/d9d454aa1cf66359ec9a3ab5a1b7eb73/3__.jpg)

__――今後OKRやKPIとして、定量的な数値を設定することは検討されていますか？__

__吉村__：高輪ゲートウェイスマートシティ開発チームでは、そういった目標の設定を目指したいと思っています。ただ、現状はようやく人が固定化してきて、やっとチームの型ができてきたところなので、各数値の定義はまだこれからですね。

例えばプルリク数などは、そこにコミットするというほどではなくとも、いったん目標を置いて振り返っていくことは、自分たちをコントロールする意味でもやっていきたいなと思っています。

__――現在は、新しくジョインした方がスムーズにオンボーディングできているかなどを、「Findy Team+」で追っていると伺いました。それ以外にも、何か活用されている例はありますか？__

__吉村__：それ以外では、主に1on1で活用しています。1on1をするときに、スクラムマスターとして定量的な情報を把握したうえで、メンバーと会話したりとか。メンバーによっては直接ダッシュボードを見せて、前週との違いを実感と合っているか確かめたりなど、1on1の話題として使っています。

## “チームの良い状態”をトータルで可視化することを目指す

__――今後「Findy Team+」をどのように活用していきたいと考えていますか？__

__岡澤__：アジャイル開発センターは、ずっとKDDIのなかでエンジニアを育成してきた背景があり、毎年グループ会社のエンジニアを受け入れて育成しています。そういった際に、メンバーがどれくらい成長したかを定量的に示してあげられると、本人自身が成長実感を得やすくなると考えています。

吉村さんのチームにも1年目のメンバーが入っていますが、そういうメンバーにとっては、自分がどれだけチームに貢献できているかわかりにくく、不安を感じやすいですよね。チームに貢献していることが見えれば、成長実感が得やすいと思うので、そういった教育的な観点での活用を進めていきたいと思っています。

__吉村__：直近は導入したばかりで、これからデータが溜まっていく段階です。理想を言えば、せっかく可視化できているので、今後はダッシュボードなどをもっとオープンにしていけるといいのかなと思います。ただ、そこは少し注意も必要なので、ゆっくりとやっていきたいですね。

まだまだ入口の段階なので、「自分たちの生産性って何だろう」とか、そういう会話をするきっかけにできたらいいなと思っています。今求められているのは、スループットなのか、リードタイムなのかとか。「Findy Team+」ではいろいろな数字が取れているので、「この期間はこれを追っていこう」といった、前向きな議論につなげていきたいです。

![kddiagile_interview_0507_4](//images.ctfassets.net/ngrpflsbp3rq/YfTJ4ZgDBHjqaZ1sZVqE3/1c29300c2e4e7559a4e849cfab7ad0fa/4__.jpg)

__――そのほかにも、開発生産性の計測に関して今後トライしていきたいことがあれば教えてください。__

__岡澤__：アジャイル開発センターでは今、生成AIをかなり活用しています。Copilotもそうですし、それ以外の開発ツールの導入も検証したり、いろいろな生成AIを活用したサービスもつくったりもしています。我々としては、ずっとスクラムやアジャイルをやってきたなかで、そこにAIが入ったらどうなるのかをすごく考えているんですね。Copilotを入れれば働き方が変わるし、それによってどう変わったのかを、定量的に見ていきたいと思っています。

エンジニアリングのなかで、例えばCursorを使ったり、もしくはSourceGraphを使ったり、Copilot以外を試してみたり、我々の組織、開発スタイルにフィットしたものを色々試している状況です。そういった開発ツールの導入を推進して開発が楽しくかつ先進的な働き方ができると、すごくいいなと思いますね。

ただ、やはり最も目指したいのは、チームの良い状態をトータルで可視化すること。例えば、切羽詰まって頑張っているチームは、一時期の生産性は高くても、メンバーは幸せではなくて、その後が続かないというケースがありますよね。社員エンゲージメントが低くなることは一番の問題で、成長実感があって楽しい状態が組織として健全だと考えています。

そして、我々は感覚として、アジャイルがすごく良い方法で、結果的にビジネスにも貢献できていると思っています。それはやってみればわかることなのですが、やったことがない人たちには伝わりにくい。そのあたりが可視化できて、今我々が進めていることの裏付けになると、お客様にとってもメリットがありそうだと感じています。

__――それでは最後に、御社の組織のアピールポイントや、一緒に働きたいエンジニア像を教えてください。__

お客様と共に新たなビジネス創出に乗り出し、自らの専門知識をフルに活かして共に高みを目指す挑戦を楽しむ。そんな情熱を共有できる方と一緒に働けることを心から楽しみにしています！

__――岡澤さん、吉村さん、ありがとうございました！__

![kddiagile_interview_0507_5](//images.ctfassets.net/ngrpflsbp3rq/2mBSKMjqwCluVBX7j9UL0A/d28cc6663b4a914718bdbe8e2dfc363d/5__.jpg)

__※KDDIアジャイル開発センターでは、エンジニアを募集しています。__

[KDDIアジャイル開発センター株式会社 ｜求人](https://hrmos.co/pages/kddigroup/jobs?category=1900792379653292032)

__※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。__

[https://findy-team.io/service_introduction](https://findy-team.io/service_introduction)


kddiagile_interview_0507_FV

アジャイル開発でDX開発支援を行うKDDIアジャイル開発センター株式会社では、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、開発戦略本部長でVPoEを務める岡澤さん、スクラムマスターの吉村さんにインタビュー。開発生産性の可視化への取り組みを始めた背景や、「Findy Team+」を今後どのように活用していきたいかなどについて、お話をうかがいました。

自律的な改善を促す組織文化の形成へ。生成AI時代を見据えたKDDIアジャイル開発センターの組織づくり

## 新サービスの開発を進めるため、組織改革を実施
__――まず最初に、皆さんのこれまでのご経歴や現在のロールについて教えてください。__

__佐々木__：AI系ベンチャーにてPaaS/SaaSの企画・開発・運用やR&D、組織運営をしていました。その後、PaaS/SaaSでAWSを利用したことを切っ掛けに外資系クラウドベンダーに参画し、Cloud Infrastructure Architectとしてコンサルティング業務に従事していました。その後縁あって弥生株式会社に入社し、2022年1月よりCTOとしてエンジニア採用/教育、全社的なアーキテクチャ検討やR&D支援などに従事しています。

__髙瀬__：前職はSIerで、受託のウォーターフォール開発をしていました。その会社には13年ほどいて、プレイングマネージャーを務めていました。弥生にジョインしたのは1年ほど前で、当初はプロジェクトマネージャーという立ち位置でした。途中からスクラム開発に移行し、現在はスクラムマスターをしています。

__水尻__：僕は前の会社が2020年に弥生と吸収合併し、弥生に転籍してきました。主な業務は、請求管理サービス「Misoca」の開発で、前の会社から合わせて5年ほど開発に携わっています。それと並行して、佐々木さんと一緒にCCoEとしてクラウド利用を推進する活動もしていて、その活動の一環として「Findy Team+」の導入を進めました。

__――弥生の開発組織では組織変革が行われたそうですが、その背景や経緯について教えていただけますか？__

__佐々木__：まず関連するプロダクトの歴史からお話ししますと、もともと弥生は会計領域のソフトを中心に、スモールビジネスのお客様のバックオフィス業務を便利にするソリューションを提供してきています。

大きく分けると業務支援サービスと事業支援サービスの2つの柱があり、業務支援サービスとしてバックオフィス業務に関連する会計や給与計算のソフト、事業支援サービスとして起業・開業を支援するサービスや、事業承継を支援するサービスなどを展開しています。このうち、主に業務支援サービスの方を内製で開発しています。

業務支援サービスには、昔からあるデスクトップソフトの製品と、クラウドサービスがあります。既存の製品は、機能アップデートや法令改正を中心に開発をするため、年1回の法令改正を中心に開発をします。そのため、ウォーターフォールで進めやすいです。一方で、新しいサービスもつくっていかなければなりません。新サービスがなかなか世に出せないことは、弥生の経営課題の1つになっていました。

お客様はそもそも会計がしたいのではなく、ビジネスがしたいわけなので、会計は意識せずとも終わっている方がいいですよね。それを今までのサービスで実現できるかというと、少しアプローチを変えなければいけない。では、具体的に何をつくればいいのかというのは、お客様の反応を見ながら開発していく必要があります。

今までのような年に1回の大きなリリース、四半期に1回のホットフィックスではなく、日常的なリリースをしていくためには、やはりアジャイルやスクラムが適しています。新サービス開発に着手したのは2019～2020年ごろで、最初は開発本部内のいち組織として始めたのですが、よりスピードを上げるアプローチの1つとして組織改革も行ってきました。

もともとは開発本部が他の部から依頼を受けて開発する、いわゆる社内受託のような体制でした。ですが、新サービスの開発をその体制でやっていると、すごく時間がかかってしまいます。なので、既存サービスを開発する開発本部とは別に、ビジネス側も同じ組織に入って一緒にものづくりしていく新部署をつくりました。それが、「弥生Next」という新サービスを開発する次世代本部です。

これによって現在は、機能ごとに切り分けた開発本部やマーケティング本部と、ビジネスと開発が一緒になった次世代本部、それぞれが混在する組織になっています。

![yayoi_intereview_240426_1](//images.ctfassets.net/ngrpflsbp3rq/2MJCpNbfJbGL3xfwkB3J3n/0826c02922f9bc936b9b25d2c3709b98/1__.jpg)

__――社内受託のような体制になっていたことは、以前から課題として認識されていたのでしょうか？__

__佐々木__：そうですね。実際に外部からの受託ほど縦割りだったわけではないのですが、部署をまたぐため形式に従って要件定義書を書き、開発側でもそれをきっちりチェックするような重いプロセスになっていたんです。そうしていくうちに、気軽に進めづらい雰囲気になってしまったのかなと。私がジョインする前のことなのですが、話を聞く限りではそのように感じます。

__――開発組織では、「1クリックであらゆるバックオフィス業務を完了させ、お客さまの1日の労働時間の100%を本業に費やすことができる状態にする」というミッションを掲げられているとうかがいました。__

__佐々木__：はい、開発本部ではそうしたミッションを掲げています。ただ、昨年10月の開発本部と次世代本部に分かれたタイミングで、本部ごとにミッションを作成しており、次世代本部の方がより自動化を意識したミッションになっています。

__髙瀬__：次世代本部は「弥生Next」という新ブランドの製品をつくるチームなので、その世界観として「日本全国のスモールビジネスと​そのステークホルダーが​最も頼る経営プラットフォーム」を目指しています。そのなかにバックオフィスの自動化やフロント業務のデータ利活用、経営状況の可視化などが入ってくるイメージです。

__――本部ごとにミッションをつくられたとのことですが、各部に共通する行動指針などはありますか？__

__佐々木__：共通しているのは、カスタマーオブセッションですね。先ほどお話した社内受託のような形でやっていると、社内で要求を出してくる人のほうを見ながら仕事をしてしまいがちです。しかし、その裏にいるお客様のことをしっかりと見なければなりません。

特に意思決定においては、先代の社長がお客様やその領域にくわしく、それに頼ってしまう雰囲気がありました。そうではなく、ちゃんと自分自身でお客様のことを見て、お客様のことを考えて行動する。そういった考え方が重視されています。

## 全社的なデータドリブン経営への移行が計測のきっかけに

__――どのような背景から、開発生産性の計測への取り組みを始められたのでしょうか？__

__佐々木__：しっかりとデータを取ってそれをもとに判断していく、データドリブン経営が必要だという話が、全社的に上がっていたことが背景にあります。というのも、歴史の長い会社ではよくあることかもしれませんが、勘で判断されることが多くあったんですね。

開発においても、これまで開発をより効率化するためにさまざまな施策を打ってきていましたが、それがどう効いたのか、どの施策が良かったのかなどを、定量的に見られておらず、勘に頼っているところが多く見受けられました。なので、しっかりと定量的なデータを取り、判断していこうという話になったんです。

また、ウォーターフォールで取っていた指標はあったものの、アジャイルに移行していくにあたって、どのような指標を取ればいいのかという疑問も出てきました。そこで、CCoEのミーティングで水尻さんに相談してみたところ、Four Keysという指標があり、それを計測できるツールがあることを教えてもらいました。

__――水尻さんがFour Keysに注目された背景や、「Findy Team+」を知ったきっかけを教えてください。__

__水尻__：Four Keysについては、多くの人がそうだと思うのですが、『LeanとDevOpsの科学』という本を読んで知ったのが最初です。そして、Four Keysを計測するにあたって自分で実装するか、「Findy Team+」のようなSaaSを使うか、この2つから考え始めました。

まずは一度自分で実装してみて、メトリクスが取れるところまでは実装できたのですが、これを自分以外のチームに展開するのは大変だなと思い、SaaSを検討し始めました。なかでも「Findy Team+」を選んだ理由は、もともと存在を知っていて、かつ「RubyKaigi 2023」のスポンサーブースで実際に動いている画面を見たことがあったから。そのおかげで、具体的に社内で使うイメージが湧いていたことが大きいです。

![yayoi_intereview_240426_2](//images.ctfassets.net/ngrpflsbp3rq/2OXhakxf0Mw13qXS6Z3aGe/40d43a059360caf900a8efcb01f15e11/2__.jpg)

__――開発生産性の計測を通じたゴールはどのように設定されていますか？__

__佐々木__：まず、「Findy Team+」で計測した数値を横並びにして、チームの良し悪しを比較することには使ってほしくないという思いがありました。というのも、各チームでやっていることもつくっている製品も違うので、一概に数値を高めることだけが正解とは思えないからです。なので、私から経営陣やマネージャーには、生産性の計測はするけれど、それを横並びにして評価しないでほしいと伝えています。

計測した数値は、自分自身のチームの振り返りに活かし、チームをより良くしていく改善サイクルをまわす目的で使ってもらいたいと思っています。改善サイクルがうまくまわれば、チームが強くなり、アウトプットされるプロダクトも良くなるはず。その結果としてお客様が増えて、弥生の売り上げが上がるとともに、弥生が提供しているサービスによって日本の生産性が上がるはずだと考えています。

__水尻__：僕はCCoEと「Misoca」の開発エンジニア、2つの立場でのゴールがあると思っています。まずCCoEの立場から言えば、「Findy Team+」というツールをさまざまなチームで使ってもらい、各チームでの開発生産性の可視化と向上のための改善を、もっと当たり前にできるように推進していきたいと考えています。

「Misoca」の開発メンバーの1人としては、こうした開発生産性への取り組みを通じて、開発チームのアウトプットを増やし、最終的には自身がつくっているプロダクトの価値を高め、アウトカムをより大きくしていくことがゴールだと思っています。

__髙瀬__：スクラムチームを見ている立場として、開発生産性というのは、どこまでいっても1つの視点でしかないと思っています。我々は開発生産性の計測を通じて、まだ試行錯誤をしている旅の途中なので、なかなか明示的なゴールを設定することは難しいなと。

ただ、開発生産性に限らず、プロダクトチームはプロダクトをリリースし、お客様からフィードバックをいただきながら、常に価値のあるプロダクトをつくることを考えるべきで、そこに向かっていることが大事だと思います。

ウォーターフォールを長く経験してきた僕からすると、デプロイ頻度のような指標は「そんな視点があるんだな」と感じる新鮮なものでした。開発生産性はエンジニアのためだけのものではなく、プロダクトチーム全体として考えていくべき議題の1つというイメージです。

![yayoi_intereview_240426_3](//images.ctfassets.net/ngrpflsbp3rq/6PihdUE993MER8PNRqlm1S/3977f6b8a8c51dc6f4e9e2166b4b8877/3__.jpg)

__――指標をOKRやKPIに紐づけることは、今のところは想定されていないでしょうか。__

__佐々木__：はい、Four Keysを直接紐づけることはしないと思います。ミッションを達成するために見ておいた方が良い指標というイメージですね。

## 活用のさらなる試行錯誤や、社内での導入チーム拡大へ

__――「Findy Team+」の導入にあたって、社内やチームの理解を得るのに苦労したことはありましたか？__

__佐々木__：社内では壁がなく、使ってみたいツールがあれば、「やってみて」と言われる環境があります。ただ、そのツールを入れた結果がどうなったかを聞くと、「そういえば最近あれ使ってないね」ということが多かったんですね。

それはつまりツールを入れた結果、数値が上がったのか下がったのかを見ていないということ。そういった結果をしっかり確認するためにも、可視化が必要だよねといった話をしていたら、特にどこからも反対の声はありませんでした。

__髙瀬__：導入してみて、チームが必要に駆られないところが最大の難所だと感じました。数値を出していても、それよりも自分にとってインパクトが大きい内容を振り返ることが多くなるんですね。振り返りのときに、事実ベースで話をしていこうとか、そういった地道なアプローチをしていくところは、今でも少し苦労しています。

__水尻__：「Findy Team+」の導入を提案した側としては、運が良かった部分もあったと思います。先ほど話題に上がった、全社的にデータを重視していく方針があったことが、まず追い風の1つになりました。さらに、佐々木さんが和田卓人さんの「質とスピード」の発表を聞いて、Four Keysの重要性について共感を得られていたこと。この2つの追い風があったから、スムーズに進んでいったのかなと感じます。

あとは、「Findy Team+」のトライアルのときに、髙瀬さんのチームにお願いしたのですが、データを見てチームの課題を見つけるなど、自分が思っていた以上にこのツールを活用してもらえていました。それを見て、「Findy Team+」を活用していく実感を得られたことも大きかったです。

![yayoi_intereview_240426_4](//images.ctfassets.net/ngrpflsbp3rq/20rSQ785Sl44hgNshtQNl9/3ff919fc9c9de39bb69a9806c700a1a9/4__.jpg)

__――開発生産性の計測に関して、今後のトライとして考えていることはありますか？__

__佐々木__：私の方では、今後1つ予定している取り組みがあります。御社のイベントでヤフーさんが、生産性が高い開発チームの習慣をアンケートで把握していたという発表をされていました。その後、懇親会でヤフーさんに直接お話をうかがいまして、その取り組みを参考に弊社でもやってみようと考えています。

__髙瀬__：ツールで計測するだけにとどまらず、スクラムのなかの活動について、どういう考え方やアプローチができるのかを、今後もチームと試行錯誤していきたいです。スクラムマスターとして、例えば「今回はこういうデータだったね」と事実ベースでチームに伝達するようなアプローチを少しずつ行い、それに対してチームがどう考えるのか、というステップを経ようと思っています。スクラムマスターから言われたから、とかそういうことではなく、チームメンバーが自分たちで発想したり、思考するというところにトライしていきたいと考えています。

__水尻__：僕としては、「Findy Team+」を社内のいろいろなチームで使っていくことを、今後のトライと考えています。なので、社内で使っていくにあたって、どんな良いところや課題があったかを調査し、他のチームで使ってもらうためのアプローチを探りながら、広げていきたいと思っています。そして最終的には、開発組織の各チームでの生産性を、しっかりとデータで見られる状態に持っていきたいです。

![yayoi_intereview_240426_5](//images.ctfassets.net/ngrpflsbp3rq/23bfczdlFxgrRFqF0h55pT/a7758038e9c134cf490648b5318667d9/5__.jpg)

__――それでは最後に、御社の組織のアピールポイントや、一緒に働きたいエンジニア像を教えてください。__

スモールビジネスと呼ばれる中小企業・個人事業主は、日本全体の企業数の99%を占めています。
ベンチャー企業はもちろん、行きつけのカフェや美容室など、私たちの生活はスモールビジネスによって支えられています。
私たち弥生は、夢を実現しようとするスモールビジネスを応援すると同時に、彼らの事業に寄り添い、支える存在でありたいと考えています。

実際に、弥生ではお客様の業務を効率的に変えていくサービスの開発に関わることが出来ます。企画から開発、運用までを自社で行っているため、超上流工程から経験を積むことも可能です。色々と新しい事にチャレンジしているため様々な課題も見つかっていますが、日々楽しみながら組織や製品の課題を解決するために試行錯誤してくださるような方にJoinして頂けると嬉しいです。

__――皆さん、本日はありがとうございました！__

![yayoi_intereview_240426_6](//images.ctfassets.net/ngrpflsbp3rq/7JIjJZtTKgGYlnE6DAqxnx/4962905a20272401fa6235dc3462d2e8/6__.jpg)

__※弥生では、エンジニアを募集しています。__

[エンジニア採用サイト | 弥生](https://herp.careers/v1/yayoi/requisition-groups/2363876d-7695-46ea-9e6a-0bc64d11b6bc)

__※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。__

[https://findy-team.io/service_introduction](https://findy-team.io/service_introduction)


yayoi_intereview_240426_fv

バックオフィス業務の自動化を支援するソフトウェア「弥生シリーズ」を展開する弥生株式会社では、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用頂いています。今回は、弥生でCTOを務める佐々木さん、スクラムマスターの髙瀬さん、CCoEとしても活動するエンジニアの水尻さんにインタビュー。新サービス開発のために行われた組織改革や、開発生産性の計測への取り組みを始めた背景、「Findy Team+」の活用を含む今後のトライなどについてお話を伺いました。

アジャイルへの移行の結果を可視化へ。データ・ドリブン経営を目指す弥生株式会社の取り組みとは？

## 「NewsPicks」のコミュニティ施策を担うチームを新設
__――まず最初に、加藤さんのこれまでの主な経歴や、現在の業務内容について教えてください。__

__加藤__：私は20年ほど開発職を続けています。SESやSIer、自社開発などさまざまな企業を経験したのち、地方（新潟）に住みながら、2022年9月に株式会社ニューズピックス（2023年7月に株式会社ユーザベースに法人統合）にジョインしました。

最初に配属されたのは、トピックスという、専門家の方がコメントを書いて発信できるコンテンツの開発を行うチームでした。そのチームはコミュニティ施策も担当しているチームだったのですが、コミュニティ施策を専任で担うチームを新たに立ち上げ、今はそのチームのリーダーをしています。

![UZABASE_interview_0424_1](//images.ctfassets.net/ngrpflsbp3rq/C1hA7NEpt2oGWAgMMJZ8g/4cd09a7d17edc2f04b3c3f390f6b68c4/1__.jpg)

__――チームの立ち上げには、どのような背景があったのでしょうか？__

__加藤__：トピックスとコミュニティの2つの施策を行うにあたって、チーム全体で見たときに、キャッチアップやコンテキストスイッチにコストがかかっている課題感がありました。そのため、それぞれにチームを分けた方が効率が良いのではないかという話から、期が始まる昨年1月のタイミングで、実際にチームを立ち上げることになりました。

__――立ち上げ当初、チームは何名くらいの体制でしたか？__

__加藤__：当初は4名でしたが、その翌月に入社が決まっていた人が1名いたので、すぐに5名になりました。年度の途中で6人になった時期もありましたが、今年からはまた少し体制が変わっています。

__――チームで掲げているミッションについて教えてください。__

__加藤__：今は体制変更により若干変わっている部分もありますが、コメントを書いてくれる人の体験を良くすることや、アクションしてくれる人を増やすことをミッションとしていました。「NewsPicks」には、記事にコメントしたり、記事をおすすめ・保存したりする機能があり、アクションというのは、そうした部分の利用を指しています。

__――それに関して、OKRやKPIとして設定していた指標はありましたか？__

__加藤__：最初はコメント数にフォーカスしていましたが、年度末ごろには週に何人がアクションしてくれるかを指標としていました。最終的には数字というより、施策を完遂するところを目指していましたね。

## プルリクを通知する仕組みの見直しから取り組み開始

__――開発生産性の計測への取り組みを始めた背景について教えてください。__

__加藤__：チームの状況として、9月入社の私のほかに、11月入社のメンバーが1人、2月入社のメンバーが1名。あと2名は別チームから入ってもらっていたため、全員がドメインに関しての経験値が少ない状態から始まりました。チームも立ち上がったばかりで、チームとしての形がまだしっかりと定まっていなかったんです。

そうしたなかで開発を進めていると、やはり最初はしっくりきていない感じがあって。実際に、振り返りのなかでもレビューが遅いといった反省点などが出てきていました。なので、その課題に対する対応として、計測に取り組んでみようというのが最初のきっかけでした。

__――どのような経緯から、「Findy Team+」を導入いただきましたか？__

__加藤__：人が集まって雑談していたタイミングで、他チームが「Findy Team+」を使っているという話を聞き、見てみようという話になったのがきっかけです。

__――そのときのチームメンバーの皆さんの反応はいかがでしたか？__

__加藤__：おおむねポジティブな反応だったと思います。オンラインなので反応が見えづらい部分もありましたが、5人くらいで話していて「良さそうだね」という反応だったと記憶しています。

__――「Findy Team+」を導入した当初、設定されていたゴールや数値目標はありましたか？__

__加藤__：最初は何かを目指すというよりは、「ちょっと見てみようかな」という温度感で始めました。なので、レトロスペクティブのなかで数字を見てみて、例えばプルリクのオープンからレビューまでに少し時間がかかっているなとか、そういう見方をしていました。そのうちに、ただ見ているだけではなく目標を決めることになり、ひとまず組織の平均を目指してみようという話になりました。

__――目標を設定されてから、チームではどのように取り組みを進められましたか？__

__加藤__：もともとメンバーの体感として時間がかかっている感覚があり、それと一致していたので、何かできることはないかとメンバーのなかで話し合っていきました。そして、まずはプルリクが上がったら通知される仕組みなど、基本的なところから見直していきました。

取り組みとしては、例えばGitHubのTeam機能を使って、よく開発するいくつかのリポジトリにTeamを設定し、レビュアーにTeamを指定できるようにしました。ラベルもつけられるようにして、ラベルがついたプルリクで未レビューのものや、アプルーブされたのにマージされていないものが通知されるようにしています。

そのほかにも、プルリクに対するアクション、例えばコメントやレビュー依頼が来たときに、Slackで通知するとか。そういった、なるべく早く気づくための仕組みを少しずつ整えていきました。

![UZABASE_interview_0424_2](//images.ctfassets.net/ngrpflsbp3rq/4pcpGmbYZN1QLQos4CODFr/9d3ce3f315a42d72cb1082f3045072b0/2__.jpg)

__――仕組みの見直し以外にも、レビューの優先度を上げていく意識づくりとして工夫されたことはありましたか？__

__加藤__：朝会のアジェンダを見直して、上がっているプルリクについて確認するようにしました。Slackに通知が来ているので、何かリリースしていないものがないか、そこで確認するようにしています。

あと、レビューの時間を設ける取り組みも試してみたのですが、これはみんなそれぞれ好きな時間にやりたいということで、上手くいかなかったですね。最終的に、朝会後にレビューしようというゆるい感じがちょうど良くて、そこに落ち着きました。

それ以外には、メンバー個別に本人の成長も兼ねて、積極的にレビューしてみようと声掛けする取り組みもありました。やはりレビューをすることでコーディングのスキル向上につながります。

それだけでなく、みんなまだドメイン知識が不足している部分があったので、レビューすることによって、メンバーが何をやっているのか、どういう仕組みになっているかなどのキャッチアップにもつながります。複数人でレビューしたりするので、もちろん時間はかかるのですが、必要なことだと意識して取り組んでいました。

__――レビューへの意識が変化したことで、品質面などにも良い影響はありましたか？__

__加藤__：品質面で言うと、レビューを早くしようとすると、プルリクを細かくするところに行き着くと思うのですが、その結果として見やすくなりますよね。なので、それを目指すことによって、結果的にプルリクが小さくなり、品質向上につながる面はあると思います。

ある程度の開発経験があれば、プルリクのサイズを細かくすることに理解があると思いますが、それを経験が少ない人に伝えるのは難しい。なので、レビューに関する数値を目指した結果、品質向上につながるというのは、1つの良い方法かなと思っています。

## 「Findy Team+」のグラフで見る、チームやメンバーの成長

__――実際に「Findy Team+」で、取り組み開始前の2月から5月までのグラフを見てみると、3月前半ごろからリードタイムが落ち着き始め、プルリク作成数が増えています。このころのメンバーの皆さんの実感や反応はいかがでしたか？__

![UZABASE_interview_0424_4枚目グラフ１](//images.ctfassets.net/ngrpflsbp3rq/56UCe5pJhDezkTs19xdKQa/75be151440cb67f529ad1385b554c47d/UZABASE_interview_xx_4______.png)

__加藤__：そのころは、メンバーと1on1でもレトロスペクティブでも、良くなってきたという声が増えてきた感覚がありました。具体的には、例えば「レビューがやりやすくなった」とか、「早く見てもらえて助かる」とか。あとは、「指摘したあとの対応が早くなった」とか、そういった声が上がっていました。

__――組織の平均を目指すというお話もありましたが、こうした数字の変化をどのように捉えていましたか？__

__加藤__：良い意味で“良いとこ取り”というか、もし仮にあまり良くない数字が出ていたとしても、あまりネガティブに捉えすぎる必要はないと考えていました。良いところを見たほうが、気持ちも上向くので、そういう使い方もありなのかなと。数値を把握すること自体に一定の意味はあると思いますが、必ずしもそれがすべてではないとも思うので、ほどよく活用しています。

__――レビュー数のグラフを見ると、9月から12月にかけて大きく伸びているメンバーの方がいらっしゃいます。かなり意識して取り組まれたのかと思いますが、いかがでしょうか？__

![UZABASE_interview_0424_5枚目グラフ２](//images.ctfassets.net/ngrpflsbp3rq/3QvuYQjv1tOhdlwUuwHyMa/a832ba7a477fa739be74a64f649a3ee1/UZABASE_interview_xx_5______.png)

__加藤__：彼は私のあとに入社したメンバーなのですが、半年で大きく変わっていて、数字を見なくても明らかに変化していることがわかりました。

まず彼には、振り返りの習慣を大事にするために、日や週の単位での予実をつけてもらっていました。例えば、午前にレビューをして午後に開発するという予定を立て、実際にはどう時間がかかったかという実績をつける。それに対して、なぜ予定より延びてしまったのか、あるいはなぜ早く終わったのかを一緒に見ていました。

彼はドメイン知識も経験も多くなく、コーディングのスキルも必ずしも高くありませんでした。やはりコードを見るには、ドメイン知識やコーディングのスキルが必要だと考えられるので、彼はもともと自信のなさから、人のプルリクに対してレビューすることがなかったんです。

なので、まずは自分のコードを見たときに、他人がどう感じるかを考えて、コメントを入れてみるところから始めました。それが9～10月あたりですね。それができてきたら、次は人のプルリクに対してメモを書いてみるという段階を踏んでいき、着実にレビュー数が増えていきました。

![UZABASE_interview_0424_5](//images.ctfassets.net/ngrpflsbp3rq/6WopfnEwCZUu66Vg1s87u7/73326a87f6df236719f59e13a1a4a001/5__.jpg)

__――取り組みを経て、この変化をご本人はどのように実感されていましたか？__

__加藤__：1日1レビューを心がけてやってくれていたのですが、彼自身も成長を感じていました。また、弊社では半期に一度、一緒に仕事をしたメンバーからフィードバックをもらう360度評価を行っています。そのコメントを見ても、みんなからレビューについて高く評価されていて、そういったところからも明らかに変わったことがわかりました。

## 数字が良くなることをゲーミフィケーション的に楽しめる

![UZABASE_interview_0424_6](//images.ctfassets.net/ngrpflsbp3rq/NyneyKFJ2DWIQK7wJ18h8/ed04c6f5a4370ebb8b56f70eb8acc8b3/6__.jpg)

__――取り組みを通じて、開発生産性を可視化するベネフィットをどういったところに感じられていますか？__

__加藤__：意外と良かったなと思うのは、雑談のネタになることですね。弊社は基本フルリモート勤務ですが、チームには月1回の出社推奨日があり、みんなが集まる機会があります。そういう場での話題になるところが良いなと思っています。

それから、現状を知るという意味では、他チームとの比較ができるところ。弊社はチーム数が多く、13～14くらいの開発チームがあります。他チームの数字を見て、大きく違いがあれば、どんな違いがあるのか、それが合理的な理由によるものなのかを確かめられる。もし比較して数字が良いチームがあったら、「どんな取り組みをしていますか？」とコミュニケーションするきっかけにもなります。

あとは、やはり始めた当初は数字で見ても悪いことがわかったので、一定の現状把握ができるのは良いことだと思います。さらに、ゲーミフィケーション的な要素として、単純に数字が良くなっていると嬉しいという感覚があります。メンバーの特性にもよるとは思いますが、そこはみんな楽しんでやってくれていたので、私たちのチームには合っていたのかなと感じますね。

__――可視化の取り組みや「Findy Team+」の活用について、今後のトライとして考えられていることがあれば教えてください。__

__加藤__：「Findy Team+」は、私自身もまだ知らない機能があるなど、使いこなせていない部分があります。随時追加されていく機能のキャッチアップも含めて、しっかりと学んだうえで活かしていきたいと考えています。

ファインディさんとの「Findy Team+」活用法のミーティングで出てきたトピックをもとに、社内の他チームとも情報交換をしながら、さらなる活用の可能性を考えていけたらと思っています。

__――それでは最後に、御社の組織のアピールポイントや、一緒に働きたいエンジニア像を教えてください。__

NewsPicks のエンジニアカルチャーとして、ユーザへの提供価値を最大化することを重視し、エンジニア自身もプロダクトの改善案を考え、実装していくという事業にコミットすることを重視したプロダクト志向のエンジニアが多い組織となっています。社内のコンテンツクリエイターやマーケターともフラットに意見交換できる組織で、普段から職種を超えて協力しながらプロダクト開発を推進しています。そのためエンジニア組織の構成も、モバイルやバックエンドなどの職能ごとではなく、サービスや機能単位でチームをつくる、ミッションベースの組織体制になっています。

また、私が所属するエンジニア部門ではエンジニアに対するサポート制度も充実しており、技術書などの購入サポートはもちろんのこと、入社後6カ月間にわたって毎月1回、CTOに1on1の時間を割いてもらう制度があったり、他部署の先輩に助言や指導をお願いできるメンター制度、コーポレート部門に日々の困りごとに対処してもらえる相談窓口があったりします。

リモートワークをサポートする制度も手厚くなってきているので、私自身を含め、地方在住のメンバーもいます。ここには、多様なバックグラウンドを持つ人たちを迎え入れる柔軟性に富んだカルチャーがあり、チャレンジを推奨する開発環境もあります。もしNewsPicksに少しでも関心があるなら、ぜひ気軽にカジュアル面談を受けてみてください。私のようにそれまで想像しなかった未来が開けるかも知れません。

__――加藤さん、ありがとうございました！__

![UZABASE_interview_0424_7](//images.ctfassets.net/ngrpflsbp3rq/5t4uhtuH9Uehm9NisIHI6N/e7c4e402db8b5f2946d167bffdd8b7d4/7__.jpg)

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
[https://findy-team.io/](https://findy-team.io/)


UZABASE_interview_0424_fv 

ソーシャル経済メディア「NewsPicks」などを提供する株式会社ユーザベースでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、「NewsPicks」の開発に携わるエンジニアの加藤さんにインタビュー。開発生産性の可視化への取り組みを始めた背景やチームでの取り組みの内容について、「Findy Team+」での実際の数値を見ながら、お話をうかがいました。

開発生産性の可視化によりレビュー数が4倍に。メンバーの成長を促進させるユーザベースの組織づくり

## レビュー滞留による停滞感、結果指標のなさが課題に
__――まず最初に、お二人の主なご経歴や現在の業務について教えてください。__

__松山__：2014年に新卒で株式会社リクルートに入社し、ずっとソフトウェアエンジニアとして働いてきました。2019年11月にmentoに入社し、CTOをしています。ロール的には、経営とエンジニアリングのマネージャーですが、チームが小さいのでコードも書いています。

割合としては、経営を2割、マネジメントを4割くらいやりつつ、残りの4割はコードを書いているようなイメージですね。あとは、コーポレートのエンジニアリングのところも、僕が見ています。

__吉谷__：2017年に新卒で株式会社FiNC Technologiesに入り、3年前にmentoに入社しました。エンジニアとして、スクラムチームのなかでコードを書きつつ、より生産的に活動できるようにチームを改善していくところを主に担っています。

__――開発組織の規模や体制、掲げているミッションについて教えていただけますか？__

__松山__：全社の組織規模としては今、正社員が17人。シリーズBの資金調達に向けて動いているところで、ラウンドでいうとシリーズAなので、まだまだアーリーステージのスタートアップです。

開発組織の体制は小さく、正社員は僕と吉谷の2人のみ。プロダクトチームとしては、業務委託で複数名に手伝っていただいている状況で、デザイナーやPdM、データサイエンティストがおり、スクラムチームとしては7人くらいです。

開発組織のミッションは、「Findy Team+」を使って開発のリードタイムを追っていくことと、もう1つは採用ですね。組織で内定承諾の数を採用KPIとして持っているので、今はその2つを組織のミッションとしています。

![mento_intereview_2024/04/11_h2-1-1](//images.ctfassets.net/ngrpflsbp3rq/2W28atyS7JeDsS9KNK9YFZ/35b889985c118d84c8a159605080787e/unnamed__4_.jpg)

__――「Findy Team+」を導入する前、どのような課題がありましたか？__

__吉谷__：いくつかありましたが、まず1つはチームの形に関する課題です。もともとはスモールチームに、エンジニアやプロダクトマネージャー、Biz側のメンバーもいる構成になっていました。

そのとき、エンジニアのケイパビリティが上手く活きないという課題感があり、それに対してプレッシャーを感じてしまうメンバーもいました。そのため、最終的にはエンジニアチームをつくり、エンジニアリングにフォーカスするという意思決定をしています。

もう1つの課題は、レビューの滞留。レビューする人が属人化してしまっていたり、業務委託の方のプルリクはどうしてもリードタイムがかかってしまったりなど、いくつかの原因からレビューが溜まっていました。それによって、なんとなくの停滞感や上手くいっていない感覚がありました。

__松山__：レビューの課題に関しては、さらに言うと結果指標がなかったんです。レビューが溜まっていることによって、我々の何が良くない状況になっているのかがわからない。どこか気持ち悪いという感覚はあるけれど、どこにどんな不具合が起きているのか共通認識を持てない、というのが大きな課題の1つでした。

__――「Findy Team+」を導入いただいた背景やきっかけについて教えてください。__

__松山__：経緯としては、最初に組織変革の話があり、エンジニアチームを切り出すにあたって、エンジニアチームのKRをどうするか考えていました。アウトプット偏重になりすぎて顧客価値に繋がらないプロダクトを作ってしまうチームにしたくないので、アウトカムの目標を置きたかったのですが、チームを切り出したばかりの状況でいきなりアウトカムまで追おうとすると、チームとして動きづらくなってしまいます。

なので、まずはアウトプットの目標を置こうと考え、そこでグローバルスタンダードな指標であるFour Keysをベースにしようと思ったんですね。ただ、Four Keysを自分たちで可視化するのは大変だと思い、調べてみたところ「Findy Team+」のことを知りました。さらに、イベントでブースが出ていて、実際に「Findy Team+」のデモを見られたので、その次の日に問い合わせました。

![mento_intereview_2024/04/11_h2-1-2](//images.ctfassets.net/ngrpflsbp3rq/1BLgqUluVH5RIwEOXtj2hy/95dcc10c2a921154669fa81f70dbbeaa/DSC03770__1_.jpg)

## 定義の議論に時間をかけずに済むことがメリットの1つ
__――「Findy Team+」を導入する前、開発生産性の計測に関する取り組みはされていましたか？__

__松山__：していなかったです。基本的には「これくらいのものは、これくらいの期間でつくりたいよね」という何となくの合意があって、それをスクラムのイテレーションのなかでやっていました。振り返りで「もうちょっと上手くできたかも」といった話はあったものの、振り返りの頻度もそれほど高くなく、あまり機能はしていませんでした。

__――「Findy Team+」の導入について、どのようにして社内の理解を得ていきましたか？__

__松山__：導入については僕が決める立場にあるので、社長を説得したといったエピソードなどは特にありません。ただ、自分たちでFour Keysを計測するプログラムを書く選択肢もあったなかで、「Findy Team+」を導入することにしたのには理由があります。

KRを決めるとき、そのKRの定義の細かいところを議論したりするじゃないですか。例えば、Four Keysの変更までのリードタイムとは、どこからどこまでなのかとか。でも、その定義を議論している時間は何も価値を生み出していないので、無駄だと思っているんですよ。定義は何でもいいからひとまず決めて、コードを書いていきたいわけです。

「Findy Team+」の場合は、「この項目はこう取っています」と決まっていますよね。なので、まずはそれに全部乗っかって、その数値を良くしていこうと。その改善活動のなかで、指標がイケてないなとか、僕らのプロセスならこういう定義の方がいいなとか、そういうものが出てきたら後から変えていけばいいと考えました。

そうした定義の議論に時間をかけなくて済むところが、「Findy Team+」の良かったポイントの1つ。なので、社内でもその指標に沿ってやっていくことを伝えて、スムーズに導入が進みました。

![mento_intereview_2024/04/11_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/2lz1Dz3ke9fFifzRx8AWAr/9197ca2532ae56f0b0e0ae21fa5bff38/DSC03942__1_.jpg)

__――導入後に取り組みを進めていくなかで、難しかったポイントはありましたか？__

__吉谷__：「Findy Team+」で見られる指標はたくさんあるので、どの指標をどう見ていけばいいのかという部分が難しかったです。そうしたなか、カスタマーサクセスの方とのミーティングで、「まずはリードタイムから見ていきましょう」とお話いただけたので、そこにフォーカスしていくことができました。

特にリードタイムのなかでも、レビューからアプルーブまで、アプルーブからマージまでを良くしていくといった話ができたことは、すごく良かったと思っています。そこまで決まれば、あとは改善していくだけなので、そこからはスムーズに進んでいきました。

ただ、まだ「Findy Team+」をみんなが主体的に見る状態にはできておらず、僕や松山さんが見てシェアしている状況です。「Findy Team+」はすごく綺麗に可視化されていますし、深堀りがいがあるデータもたくさんあると思うのですが、そこはまだ僕も含めて触りきれていない印象がありますね。

## 週2回のレビュー会を設け、全員のレビュー優先度をアップ
__――レビューの課題については、どのように改善を進めていきましたか？__

__吉谷__：レビューに関しては、特に僕に属人化しているところがあったので、みんなでレビューしていくことと、レビューを優先的にすることをチームで合意しました。具体的には、火曜と木曜に1時間ずつレビュー会を設けて、そこでエンジニア全員でレビューする時間を取っています。

レビュー依頼が来たらすぐにレビューをするのが理想ではあるのですが、コンテキストスイッチもあるので、レビューするタイミングをつくって、レビューが溜まっていたら対応するという意識をつけていきました。

![mento_intereview_2024/04/11_h2-3-3](//images.ctfassets.net/ngrpflsbp3rq/5vwpGgdrmtrcIzxwVX6zRw/0890d11f8b85b3ec5c70718f2c693eb2/unnamed.jpg)
__――レビュー会を設けることに対して、ネガティブな反応などはありませんでしたか？__

__吉谷__：レビュー会を設ける前のことを思い出すと、そこに時間をかけていいのかという不安があったように思いますね。コードを書く方が生産的な感じがして、その時間を使ってどうなるのか、あまりイメージがつかないというか。

__松山__：効率が悪いのではないかという漠然とした不安があるんですよね。それは効率をどう捉えているかだと思っていて、おそらく多くの人が、エンジニアみんなが100%の稼働でコードを書いてるのが効率の良い状態だと思い込んでいるんだと思うんですよ。

それはエンジニアを1つのリソースと捉えたときの効率としては正しくても、ものをデリバリーしていくことを考えたとき、みんながコード書いてるとレビューでスタックしてしまって、デリバリー効率としてはあまり良くなっていないんですよね。

一人ひとりの効率が多少落ちても、レビューしたりQAしたりした方が、世の中に出ていくスピードは上がる。そういう話は、理論的には理解できても、本当に正しいのかという不安がついてまわります。でも、結果指標が可視化されていると、自分たちがやっていることが間違いではなかったとわかるので、そこで自信につながる部分があると思います。

__吉谷__：加えて言うと、僕自身もリソース効率が100％になっていない状態への不安は、まだあります。例えばレビュー会で1時間取って、エンジニア4人でやっていた場合、僕がレビューを3人に分配するんですよ。

そうすると上手くパスできないタイミングがあって、フロントエンドエンジニアの人は今レビューするものがないけど、10分後から動作確認タイムになる、みたいなことが起こるんですね。そうすると、その10分間はどうしても暇になってしまいます。

そういう何かが止まっている時間ができてしまうことが怖くて、もしこれが10人になったら、何もしない時間が結構あるだろうなと。なので、そういう怖さを認識しつつ、何もない時間には他のことをやっていく必要があるのかなと思っています。

## 今後はデリバリー効率の改善やデリバリー品質の計測へ

__――開発生産性を計測することによるベネフィットをどのようなところに感じていますか？__

__吉谷__：やはり目標に数字が置けることと、それが改善しているかどうかが見えることですね。最初の1ヶ月はあまり変わらなかったのですが、それは溜まっていたプルリクを消化するタイミングだからという共通認識がありました。溜まっていたプルリクが消化できてからは早くなっていって、それが可視化できたので良かったです。

実際に導入初期の2023年11月ではサイクルタイムの合計値は94.8時間でしたが、2024年4月には26.1時間と約1/3以下の数値に改善してきています。

![mento_intereview_2024/04/11_h2-4-1 ](//images.ctfassets.net/ngrpflsbp3rq/3PWM7EXxU7h69e9Yyed7hS/adcebf0635cdcf1a429816e7e60be050/__________2024-04-23_16.02.51.png)

![mento_intereview_2024/04/23_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/4Iz0LdYUfXW61X1OAB1dfn/eb45a62bc83a7cce1baa3a9184b2493d/__________2024-04-23_15.43.20.png)

__――メンバーの方々の意識や行動の変化を感じた部分はありますか？__

__吉谷__：エンジニアのなかで、レビューを最優先にするという意識づけができました。最近は、OKRにプルリクのリードタイムではなく、JIRAのリードタイムを置いています。なので、エンジニアだけでなくプロダクトマネージャーなども同じように、タスクをなるべく滞留させず、早めにDONEするという意識がついています。

プルリクもそうですが、チケットを細かく分割していくところも、意識や行動の変化の1つですね。小さくチケットを切って、小さくリリースすることが意識的になってきたと思います。

基本的にダークローンチというか、ユーザーに影響がない範囲でどんどん出していくことによって、リリースの頻度も上がりますし、一つひとつのプルリクも小さくなります。「Findy Team+」でも見れていますが、変更行数もどんどん小さくなっていて、レビューに時間かかることが減ってきました。そういったところは良い変化だと思っています。

![mento_intereview_2024/04/11_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/4LHJuYjQX9hPRc8HBS9cfb/7765be4533ab0348f8dc448930f60d78/unnamed__5_.jpg)

__――プルリクを小さくすることについては、特に声掛けをせずとも自然とそうなっていったのでしょうか？__

__吉谷__：そうですね。自然となっていった気がします。どうしてもレビューの頻度が少なくてリードタイムが伸びると、そこにどんどん変更が足されてプルリクが大きくなってしまいます。ですが、少なくとも週に2回のレビュー会がありますし、その前にもレビューされるので、プルリクが大きくなりにくくなったと思います。

__――開発生産性の計測について、今後のトライとして考えていることを教えてください。__

__吉谷__：今はレビュー会を正社員2人、業務委託4人くらいでやっています。今後、エンジニアメンバーが10人、20人と増えていったときにも、これが文化としてキープできているとすごくいいなと思います。

__松山__：デリバリー効率は健康指標だと思っていて、一定水準まで上がったら、もうそれ以上は求めてもきりがありません。例えば、プルリクの変更行数を5行にしましょう、なんて話は起きえないですよね。

なので、一定水準になったらそれを健康指標として、組織のコンディションが悪くなってしまったときに戻す力学が働くことが大事だと思っています。ただ、今はまだ健康指標にもなっていないので、まずはそこを目指していく段階。それができたら、定点観測していかに維持できるかが重要だと考えています。

もう1つ、Four Keysの文脈でいうと、僕らは現状デリバリー品質の部分が見れていません。直近もエラーが多いという課題が上がってきていますが、hotfix運用をしていなかったりリリースに影響がない本番障害があったりして、今はFour Keysの変更失敗率が「Findy Team+」で適切に取れないんですね。

ただ、ゆくゆくはそういった部分もプラットフォーム上ですべて管理して、我々の目標として追っていきたいので、そこは明確に今後の展望の1つだと思っています。

__――それでは最後に、組織のアピールポイントについて教えてください。__

__吉谷__：アピールポイントは、改善活動を気持ち良くできるチームだというところですね。プロダクトやサービスの価値にみんなが向かっていて、そのために改善活動するということを、すごくポジティブに捉えているチームだと思います。

__松山__：組織の小ささとフラットさは、アピールポイントだと思います。今回お話したような、エンジニアチームを切り出したり、KRにアウトプットの目標を置いたりといった話も、僕だけで決めているわけではなく、ヒアリングしながら吉谷と一緒に決めています。

エンジニアリングの枠に閉じずに、組織の目標をどうするか、採用をどう考えるかといったところまで、一人ひとりがやろうと思えばやれる環境があります。まだまだ小さな組織なので、自分をエンジニアという枠に収めたくない人にとっては、何でもできて面白い環境だと思います。

__――松山さん、吉谷さん、ありがとうございました！__

![mento_intereview_2024/04/19_h2-4-2](//images.ctfassets.net/ngrpflsbp3rq/MW2MR2NZn0CswoN5ApqJs/6374401ffda2495b68139edbdc5c27b5/DSC04122__1_.jpg)

（※最後はチーム全員で写真撮影をして頂きました。）

※現在mentoでは、エンジニアを募集しています。
[エンジニア求人　| mento](https://herp.careers/v1/mento/bmLBljpda7kA)

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
[https://findy-team.io/](https://findy-team.io/)


mento_intereview_2024/04/23_fv

パーソナルコーチングサービス「mento（メント）」の開発・運営などを行う株式会社mentoでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、mentoのCTOを務める松山さんと、エンジニアの吉谷さんにインタビュー。「Findy Team+」を導入する前にあった組織の課題や導入後の取り組み、開発生産性の計測のベネフィットをどのように感じているかなどについて伺っていきます。

「正社員2名」の開発組織からFourKeys向上へ。事業拡大を目指すmentoにおける開発組織の文化づくりとは？

## 開発組織が拡大するなか、課題が顕在化しない状況に
__――まず最初に、金杉さんの主なご経歴と現在の業務について教えてください。__

__金杉__：新卒でワークスアプリケーションズに入社し、エンジニアとしてのキャリアをスタートしました。その後、スタートアップ企業で開発のマネジメントなどに携わったのち、自分の力試しをする気持ちでフリーランスとして独立。フルスタックエンジニアとして、何社かお手伝いさせていただきました。

そして、もともと正社員時代に働いていたスタートアップ企業で、弊社の創業メンバーである中村と渡部と一緒に仕事をしていた背景から、ともにミチビクを創業。ミチビクではCTOをしています。

__――開発組織の規模や体制について教えていただけますか？__

__金杉__：現在、日本とオフショアに拠点があります。自分が開発チームとデザインチームの2つを持っていて、開発組織の規模としてはオフショアを含めて15～16人。マネジメントしているのは自分のほかに、オフショアをメインでマネジメントしているブリッジエンジニアが1人います。

![michibiku_intereview_2024/04/11_h2-1](//images.ctfassets.net/ngrpflsbp3rq/3eORgPVAiQyx1uVpEY2e7l/b21967b1a6faaa0ee8bd579e30fac5e0/team_m.jpg________1_.jpeg)

__――設立された当初、開発組織は何名でしたか？__

__金杉__：設立した当時は2人でした。

__――開発組織の人数を拡大していくなかで、組織の課題になっていたことがあれば教えてください。__

__金杉__：日本チームでは、人数が拡大してもスピード感を維持するためにどうすればいいかを考えていました。課題は特に顕在化しておらず、課題を見つけようと1on1などで話を聞いても、みんな「このままでいい」と言っていたんですね。他の会社で働いていた経験から比較しても、今のチームはうまく回っているとのことで、困っていることが顕在化していませんでした。

__――「Findy Team+」を導入いただいたのは、どのようなきっかけからでしたか？__

__金杉__：課題がない組織はないだろうと思っていたものの、定性的な情報からは課題を見つけることができなかったわけですね。そうしたとき、ファインディさんはCTOのイベントにたくさんいらっしゃっていたので、「Findy Team+」のことも知っていたんです。CTOの佐藤さんとも知り合いですし、プロダクトマネージャーの方ともお会いしたことがあり、そうしたきっかけで問い合わせさせていただきました。

__――開発生産性の可視化にあたって、設定されたゴールはありましたか__

__金杉__：課題が見えていない状況だったので、まず最初の3ヶ月で課題の特定。その次の3ヶ月で、課題に対する分析や対応を行うことにしました。その次の6ヶ月で、課題すべてに対応し切って「Findy Team+ Award」※の表彰ラインに乗せることを目指しています。

（※「Findy Team+」 利用企業を対象に「エンジニア組織の生産性指標」を算出し、「組織規模、チーム別」および「優れた取り組み」を表彰するアワード）

__――「Findy Team+」導入前は、定量的なデータの計測はされていませんでしたか？__

__金杉__：基本的には、ロードマップに間に合っているかどうかを見ていました。2～3ヶ月のエピック単位で見て、リリースしたいバージョンに間に合っていればOK。それはずっと未達になったことがなく、問題になっていませんでした。

顧客から要望があったさまざまな新機能をつくる必要があるフェーズなのですが、ビジネスサイドと合意を取りながら、「このバージョンに間に合わせます」といった約束に応えるように進めていました。

## 数値の可視化にあたって重要なのは、本質を見誤らないこと

__――KPIとしてチームで設定されている定量的な指標はありますか？__

__金杉__：下記のような形で、目標スコアを表にしています。開発生産性スコアサマリでは、Findy Team+ Awardの表彰ラインを考慮して、ある程度の余裕を持たせた数値を目標スコアとして設定しました。ほかには、主に見たいサイクルタイムやDevOpsの目標スコアを設定して、マンスリーで振り返りをしています。

![michibiku_intereview_2024/04/11_h2-2-1](//images.ctfassets.net/ngrpflsbp3rq/65xkKELaWyj8rnNDK0bXFX/41109c935e51f42c9228073f1cf993bc/__________2024-04-11_14.59.13.png)

__――取り組みによって数値が改善した事例があれば教えてください。__

__金杉__：現時点で数値が改善したのは、リードタイムです。なかでも、大きく改善したのはアプルーブからマージまで。あとは、レビューからアプルーブまでですね。僕らは1ヶ月で間に合わせればよかったので、そのあたりはあまり意識していなかったのですが、可視化されたことによってアプルーブからマージまでは約90％減少、レビューからアプルーブまでは約30％減少と劇的に改善しました。

![michibiku_intereview_2024/04/11_h2-2-2](//images.ctfassets.net/ngrpflsbp3rq/3Q6SI1TeaX9UJhTz6jg1sI/415612d9e3fd8efdc11051aa81a11e3b/__________2024-04-12_14.06.13.png)

![michibiku_intereview_2024/04/11_h2-2-3](//images.ctfassets.net/ngrpflsbp3rq/6G7lSDzgOFbUcz1mrqeFCI/1e9009ca72364c84ad0a5864ae339907/__________2024-04-12_14.06.19.png)

__ーーレビューからアプルーブまでの改善について、金杉さんに偏っている部分があると伺ったのですが、分散していく取り組みを行ったのでしょうか？__

__金杉__：分散についてはまだ移行中で、今レビュアーの育成などに取り組んでいるところです。数値に効いていると思うのは、プルリクのサイズを小さくしていったこと。それによって、レビューのしやすさが向上しました。

それから、やはりレビューの指摘が入ると、アプルーブまでにより時間がかかります。アプルーブまでの速度を意識して、以前あった指摘を繰り返さないような取り組みもしていて、そういったところも効いてきたのかなと思います。

__――「Findy Team+」の活用について、社内で理解を得ていくにあたって難しかったことはありましたか？__

__金杉__：2つに分かれます。費用面を判断するのはCEOなので、まずはそこを口説くのが大変でしたね。ファインディさんと一緒に作戦会議をしながら、「Findy Team+」を導入して生産性が上がれば、顧客にとってもビジネスとしてもメリットがあるんだということを伝えていきました。

もう1つは社内のメンバーで、そちらはトライアルで導入した時点で、みんなから良い反応が返ってきました。特に自分の肌感と違う部分が見られるので、そこが面白いといった声がありました。あと、こうしたツールを使って、どうやってチームをより良くしていくかを考えるのが好きなエンジニアもいるので、そういう面でも良かったです。

__――自分のアクティビティやチームのデータが可視化されることに、抵抗がある人はいませんでしたか？__

__金杉__：そういう人はいないですね。そういった考え方の人は、そもそも弊社のカルチャーとマッチしないと思います。

__――取り組みを進めていくにあたって、難しかったポイントはありましたか？__

__金杉__：数値の改善をするためには、それまでの社内の開発フローを変えなければならず、その意思決定が正しいのかという判断が難しかったです。定量的に可視化して、本当にそのスコアが改善することが良いことだと定義して進めるのか。本質を見誤ってスコアの改善だけに注力してしまわないか、といった部分が難しかったですね。

__――そうした部分に対して、意識したことや心がけたことがあれば教えてください。__

__金杉__：まず1つは、やはり本質を見誤らないところ。結局、もし数値が良くなったとしても、スケジュールに間に合わなくなったら本末転倒じゃないですか。そこは意識して、あくまで数値だからということをメンバーにも伝えていました。

もう1つは、この数値の改善をまず1年間のトライとしたところ。取り組みが上手くいってスコアが改善したら、その結果として、社内で何が変わったのか見えてくると思うんです。僕らは定量的な指標がなく、課題が見えなかったところから始まっていますから、まずはトライして結果を見てみようということですね。

## 良い意味で裏切られた、「Findy Team+」導入後の印象

__――ここまでにお話いただいた以外にも、開発生産性の計測によるベネフィットを感じた部分はありましたか？__

__金杉__：「Findy Team+」の開発生産性スコアは相対比較なので、他の会社と比べてどうなのかわかるところが面白いですね。自分たちのこの数値はイケてるなとか、他社はもっとリードタイムが速いんだなとか、そういった比較ができるのはありがたいです。

あと、予期せぬベネフィットだったのは、日本と比べてオフショアの生産性が良くないと気づけたこと。上手くまわしていくためにさまざまな施策をして、アウトプットは問題ないと思っていたのですが、もっと改善できるところがあると気づきました。そういったオフショアや受託の管理にかなり有用だなと感じます。

![michibiku_intereview_2024/04/11_h2-3-1](//images.ctfassets.net/ngrpflsbp3rq/1wVWV3LmQgrcU4U94M3J12/3202b42583019bf8c00302a36ee6dde3/team_receipt.jpg________1_.jpeg)

__――開発生産性の可視化を通じて、メンバーの意識や行動に変化はありましたか？__

__金杉__：行動や意識の変化は感じています。具体的には、例えばプルリクを小さくするといったチームで決めたトライに対して、今まではただそう言うだけで、なかなか実行できていなかったんですね。そういった部分で、先ほど挙げたようなKPIに向けて、どうすればいいのかを考えて行動してくれるようになりました。

あとは、レビューのスピードがかなり上がりました。今までレビューは間に合えばいいという意識で、少しおざなりになっていた部分があったんです。それが可視化によって、レビュー速度を上げたらどれくらいスコアが上がるかがわかり、即時レビューするという意識につながりました。可視化しなければ、そこまで意識がまわっていなかったと思います。
導入して1ヶ月でリードタイムスコアが改善し、開発生産性スコアも上昇することができました。

![michibiku_intereview_2024/04/11_h2-3-2](//images.ctfassets.net/ngrpflsbp3rq/6FPcEolfWDjvahtvxdnwwf/8b0a0798bbbe46c6db3bf005307202b0/__________2024-04-11_14.56.48.png)

__――金杉さん自身が「Findy Team+」を導入して良かったと感じる部分について教えてください。__

__金杉__：導入してイメージが変わって、かなりポジティブな評価になりました。良い意味で裏切られた感じですね。もともと気になっていたのは、本当にFour Keysが正しいのか、弊社にも当てはまるのだろうかというところ。そこはモヤモヤしながら進めていたのですが、実際はいろいろと可視化できるメリットの方が大きくて、上書きされた感覚があります。

__――Four Keysという指標に対する、今の納得感はいかがですか？__

__金杉__：それについてはまだ50％くらいで、先ほどお話ししたこのあとの1年間のトライで腹落ちさせたいというのが正直なところです。弊社のプロダクトは性質上、toBかつユーザーが月に1回くらい使うもの。Four Keysを提唱したGoogleさんを含む、他のtoBプロダクトは、ユーザーが毎日使うものだったりします。なので、即時リリースすべきかといったところは、まだ腑に落ちていません。

ただ、結局はお客様の声が正義だと思うので、そういったトライをしてみようと、今は即時リリースできるように運用を変えている途中です。それでお客様の声が変われば良かったということだし、逆に不具合が増えてしまったら戻そうと考えていて、今まさに検証中です。

__――お客様の声は何らかの形で計測されていますか？__

__金杉__：NPSのようなアンケートはまだ取れていません。しかも、年契約のサービスのため、今取り組んでいる内容への回答が1年半後などになってしまいます。なので、アップセルや他社への紹介につながることが増えたら、良い反応だと捉えています。

## 新たな気づきを得た、オフショアにおける課題の改善へ

__――開発生産性の可視化に関して、今後のトライとして考えていることはありますか？__

__金杉__：まず1つは、先ほどお話しした即時リリースですね。そして、今ちょうど取り組んでいるのがフィーチャーブランチの撤廃。すべてdevelopのメインブランチに直マージして、フィーチャートグルで機能を管理することにチャレンジしています。

今までフィーチャーブランチに8つくらいのプルリクを入れていたため、これでおそらくプルリクの作成数が一気に上がるだろうと。プルリクの作成数がアウトプットに響いていると推測しているので、特にオフショアでの数値に大きく変化があるのではないかと考えています。

それから、新たな気づきとしてあった、オフショアにおける生産性の課題に関してですね。明らかに日本チームとの差があることに気づけたので、どういったところから日本チームとの差分が生まれているのか、バイネームでデータを見ながら改善を進めています。

オフショアはコストパフォーマンスや採用の観点でメリットがあると考えていましたが、生産性が上がらないのであれば、日本チームだけでやったほうがいいのではないかという話になってきます。改善を進めながら、オフショアの戦略が正しいのかといったところも含めて見ていきたいと思っています。

__――それでは最後に、開発組織についてのアピールや一緒に働きたいエンジニア像について教えてください。__

__金杉__：僕らが掲げているコンセプトは、“和製GitLab”。フルリモートで世界中に従業員がいるGitLabと同じように、僕らも国籍や人種や性別に関係なくチャレンジしていきます。開発生産性を意識する文化も根付き始めていますから、フルリモートでも定量的な面からサポートしつつ、ビジネスとして成長させていきます。

会社のカルチャーを大切にしたいので、フルリモートでもコミュニケーションが取れてアウトプットが出せて、チームのことに責任を持てる。そういう方を求めています。弊社では、ただコードを書くだけでなく、フルサイクルエンジニアのような形で、調査やデプロイ、QA、自動テストなどもしてもらっています。なので、そういうエンジニアの方とぜひ一緒に働きたいと考えています。

__――金杉さん、ありがとうございました！__

![michibiku_intereview_2024/04/11_h2-4](//downloads.ctfassets.net/ngrpflsbp3rq/olyn8Rajq4KK9IFkibuAh/e1ba209cc65ff20a171f612e5d406952/DSC03016.jpg________2_.jpeg)

※現在ミチビクでは、エンジニアを募集しています。
[エンジニア採用サイト　| ミチビク](https://engineer-recruit.michibiku.jp/index.html)

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
[https://findy-team.io/](https://findy-team.io/)


michibiku_intereview_2024/04/12_FV

取締役会運営の効率化を支援するツール「michibiku」を運営するミチビク株式会社では、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。  今回は、ミチビクのCTOを務める金杉さんにインタビュー。開発生産性の可視化における取り組みに「Findy Team+」をどのように活用しているか、導入後に組織やメンバーにどのような変化があったかなどについて伺っていきます。

潜在的な課題を特定し、数値に基づく目標設定へ。設立3年目で開発生産性向上を目指すミチビクの取り組み

tsukuruba_intereview_2024/04/02_FV

中古・リノベーション住宅の流通プラットフォーム「cowcamo（カウカモ）」などを展開する株式会社ツクルバでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

経営と開発をつなぐ架け橋に。事業成長を加速させるツクルバの開発生産性指標の活用方法とは？

ourly_interview_2024/02/21_FV

プルリクオープンオープンまでの時間が9分の1に。15名でFourKeys向上に向き合うourlyの取り組みとは？

プルリクオープンまでの時間が9分の1に。15名でFourKeys向上に向き合うourlyの取り組みとは？

## 組織が立ち上がった2年前から、アジャイル開発を推進
__――まず最初に、皆さんの主なご経歴や現在の役割を教えてください。__

__坂井__：2004年に新卒で入社し、入社時からソフトウェア開発を続けています。2022年から現在の組織のマネージャーになり、現場から管理までプレイングマネージャーとして業務しています。

__古澤__：2000年に新卒で入社しました。入社後の6～7年間は、携帯電話のソフトウェア開発に携わり、その後は、通信キャリアやエンタープライズ向けのソフトウェア開発を行っていました。3年前に自社サービスを開発する現在の組織へ異動してきました。

__山下__：2014年に新卒で入社し、4年ほど開発部門でロボット内部のソフトウェアやタブレットのアプリケーション開発を行いました。その後、別の部門で4年間パブリッククラウドのアーキテクトを経験し、現在は社内のアジャイル推進とスクラムマスターを担当しています。

__――皆さんが所属されている組織について、教えていただけますか？__

__坂井__：私たちはSymphonict事業推進本部の先端技術開発グループに所属しており、グループマネージャーを古澤が務めています。さらに、そのグループ内にあるSymphonictサービス開発チームに坂井と山下が所属しており、私はそこでマネージャーを担当しています。

__――どのような背景から、アジャイルを推進していくことになったのでしょうか？__

__坂井__：2022年に組織が立ち上がった際、このVUCAの時代を生き抜くために、組織のアジリティを上げていかなければならない。そのために、アジャイルな組織になる必要があるという話になりました。

しかしながら、私たちにはその知見がなかったため、まずはコンサルタントの支援を受け、アジャイルの基礎を叩き込んでもらうところからスタートしました。初めの3ヵ月は座学を中心に行い、その後、PoC案件でスクラムチームを1つ立ち上げたのが始まりです。そして、さらに2つ目のチームを立ち上げ、現在も開発を継続しています。

__――現在チームでは、どのようなミッションを掲げていますか？__

__坂井__：部の名前についている「Symphonict」というのは弊社のブランドで、“デジタルでつなぐ”というコンセプトのもとお客様のDXイノベーションをサポートするサービスの総称です。Symphonictを実現するために、「早く、安く、巧く」サービスを提供できるプラットフォームを準備することや、そのプラットフォーム上でサービスを開発することが大きなミッションとなっています。

Symphonictのブランドにはさまざまなサービスがありますが、現在アジャイル開発を行っているサービスは、主にお客様向けのポータルサイトになります。私としては全ての開発をアジャイルでやっていきたいという思いがあるのですが、現状はアジャイルの案件数がそれほど多くないのが実情です。

自社サービスは作ったら終わりではなく、常にフィードバックをもらいながら、より良いものに更新し、価値を高め続けなければならないと思っています。そのためには、やはりアジリティが重要であると考えています。私たちのミッションと照らし合わせても、アジャイルな組織としてリリース頻度を高めていくことが必要だと考えています。

__――チームで設定されている、OKRやKPIはありますか？__

__坂井__：リリースするサービス数やアジャイルのスクラムチーム数などはKPIとして設定されています。また、運用フェーズでは、サービス稼働率、インシデント発生数、インシデントの対応にかかる日数などがKPIになっています。

ただし、チーム毎の1日のリリース回数や、プルリクの作成数など、スクラムの活動に特化したKPIはまだ設定されていません。
![【使用①】インタビュー風 DSC07257](//images.ctfassets.net/ngrpflsbp3rq/MRuXbepkf9AF1Ejh8prhf/cf4db525fa868f7f254c23f579088894/______________DSC07257.jpg)
## 開発生産性に関する疑念から、「Findy Team+」の導入へ

__――開発生産性の計測に取り組み始めたきっかけを教えてください。__

__坂井__：今年の3月に、社内で「アジャイルの方が、ウォーターフォールよりも生産性が低いのではないか？」という声が上がりました。その時、私は「そんなことはないだろう」と感じたと同時に、生産性を測る指標がコード量だったことにも違和感がありました。

そこから、生産性をどのように測るべきかを調べ始め、『LeanとDevOpsの科学』などを読み、Four Keysのことを知りました。そこで、そもそも本当に生産性が低いかどうか、まずは数字で見える化しなければならないと思ったのがきっかけです。

__――そうした生産性に関する情報を調べるなかで、「Findy Team+」を見つけていただいたのでしょうか。__

__坂井__：最初は私が片手間で、GitHubのAPIを使ってAWSにデータを取り込み、BIツールで可視化しようとしていました。それを作る途中でたまたま「Findy Team+」を発見しました。これを参考に似たものを作ろうと思ったのですが、ものすごく大変で（笑）。「Findy Team+」のサイトを見てみると、とても高機能だったため、これは自分で作るよりも導入した方が良いなと思いました。

__――その後、どのような流れで「Findy Team+」の導入が決まりましたか？__

__坂井__：4月の組織変更で新たな本部長が着任し、そのタイミングで本部長に直接話を聞いてもらえる機会がありました。そこで私は、開発力を高めてリリースを早めていくためには、生産性を計測する必要があるという考えと、Four Keysの導入を提案しました。さらに、そのFour Keysを可視化できる「Findy Team+」というツールがあると伝えたところ、トントン拍子で導入まで進みました。

__――「Findy Team+」の導入前に、懸念されていた部分はありましたか？__

__坂井__：「Findy Team+」では個人の数値が計測されるため、個人の能力面も可視化されてしまいます。その数値だけで100％判断できるわけではないにしても、そういった数値をメンバーに見せて大丈夫なのかという懸念がありました。現在、導入から4ヵ月経ちましたが、そういった懸念に関する声は特に上がってきていません。
![【使用②】坂井さん DSC07240](//images.ctfassets.net/ngrpflsbp3rq/6hIrUVxJ1u4b0aJdAYijv0/aba973965e3451ba6be1cf08de064fb6/__________DSC07240.jpg)
## 経営層まで、Four Keysが浸透したことで意識が変化

__――開発生産性の計測を通じたゴールを、どういったところに設定していますか？__

__坂井__：ウォーターフォールとアジャイルの比較が最初のトリガーにはなったものの、そもそも比較するものではないため、今はそこにはあまりフォーカスしておらず、純粋に私たちのスクラムチームにおけるFour Keysの可視化を目的にしています。最終的には、お客様にどれだけ価値を届けられているかを計測したいのですが、まずは開発のアウトプットとしてFour Keysやプルリク数を向上させていくことを目指しています。

__古澤__：生産性という言葉のイメージから、一般的な「開発コード量」のみを見て、アジャイルは生産性が落ちると思っている人は、社内にもまだ存在します。
ですが、デプロイ頻度、リードタイムまで生産性と考えるような価値観が、ようやく少しずつ浸透してきました。とはいえ、まだまだアジャイルでの開発が軌道に乗っているとは言えず、お客様に価値を提供するところまで持っていくことがゴールだと考えています。
![【使用③】古澤さん DSC07235](//images.ctfassets.net/ngrpflsbp3rq/4py4HsIYASfIIOTt5iVLpH/b390cd94393b28baeefcfab41d4df10a/__________DSC07235.jpg)
__――目標に設定されている、具体的な数値などはありますか？__

__坂井__：私たちのデプロイ頻度は、まだ2ヵ月に1回程度なので、まずは1ヵ月に1回のデプロイを目指しています。また、コミットからマージまでの時間を表すサイクルタイムですが、今は100時間を超えているため、24時間を目指そうと開発チーム内で目標設定しています。ただし、これはまだ明確に決めているわけではなく、現状は可視化してみて、次の段階で具体的な数値目標を設定していきたいと考えています。

__――「Findy Team+」の活用について、スクラムマスターをされている山下さんから見ていかがでしょうか？__

__山下__：チームの活動において、自分たちがどれだけ効率的に開発できているかを可視化できるところが、とても有用だと思っています。スプリントごとの振り返りで、今まではメンバーが感じていることをベースに話すことが多かったのですが、今は「Findy Team+」の数字を見ながら実態に則した話もできているので、振り返りの質が向上しました。

2週間のスプリントの中で、明らかに課題があった場合は別ですが、そうではなく計画通りに開発ができた時、はたして本当に効率が良かったのかどうかは、おそらく数字がないと判断できません。ですので、チームの活動を改善するための取っ掛かりとしても非常に有用なツールだと感じています。

__――スプリントの振り返り以外で、「Findy Team+」を見る場面はありますか？__

__坂井__：振り返り以外では、マネージャーを含めて各個人が自由に見たい時に見ています。また、同じ本部内に品質管理グループという、プロジェクトやアウトプットの品質をチェックするグループがあるのですが、そのグループもプロジェクトの状況を見るために「Findy Team+」の数字を見たいと言っています。

__――ここまでにお話いただいた以外にも、開発生産性を計測することによるベネフィットを感じた部分があれば教えてください。__

__坂井__：「Findy Team+」を導入してから、経営層にもFour Keysが浸透してきた印象があります。以前はコード量をもとに話していた人も、最近ではFour Keysで話すようになり、意識が変化してきた部分があると思います。

マネージャーとしての立場から見ると、「Findy Team+」では活動量が見えるので、プロジェクトの負荷が高くなっている場合や、何らかの問題が生じている場合に気付きやすくなりました。加えて、レビュアーの負担や偏りも可視化されるので、メンバーからもそれを意識するような発言や、改善しようとする動きが出てきています。

__山下__：スクラムマスターとしてチームに改善を促す際に、今までは実際にやってみてどうだったかという体験をもとに話をしていました。ですが、例えばPBI単位でブランチを切るとか、タスクレベルでなるべく細かくプルリクを出すとか、そういったところも数字で見えるようになったので、説得力を持って提言できるようになりました。

__坂井__：課のメンバーが半期ごとに目標を立てるときに、「Findy Team+」の数字を使って目標を立てるようになり、活用されていることを実感しています。具体的な数字で目標を立てられるので、評価もしやすく、成長を促しやすくなったと思います。

__――経営層へのレポーティングなどに、「Findy Team+」を活用いただいている場面はありますか？__

__坂井__：先日、経営層向けにチームの「Findy Team+」の数字を見せながら、開発チームの状況を説明しました。今後も定期的に「Findy Team+」を活用して説明を行っていこうと思っています。

__山下__：その説明の場で印象的だったのが、経営層から「今はこういう指標を見るんだ」、「これはあまり考えたことがなかったな」といったコメントが出たことでした。組織としての振り返りに、今までになかった新しい観点を取り入れられるツールなのかなと思います。

## 開発組織に閉じない生産性まで、可視化していきたい

__――「Findy Team+」で計測するにあたって、難しかったポイントはありましたか？__

__坂井__：「Findy Team+」で計測するためには、Gitのブランチ戦略を適切に合わせる必要があり、私たちの従来のやり方を少し変える必要がありました。例えば、空コミットを実施してからコーディングをスタートさせることや、同じプルリクをマージした時に二重集計されないようにタグ付けするなど、Gitの運用をルール化し、チームに浸透させて上手く使いこなせるようになるまで、ひと手間あったと思います。

__山下__：「Findy Team+」で難しいのは、誰がどこをどう見たら良いかが分かりにくいところでしょうか。データはたくさん取れており、有用な指標もたくさんあるはずなのですが、それを有効活用することは難しいと感じました。

私や坂井は、ファインディの方との定例で、サポートを受ける中で「こういうところを見ればいいんだな」と、徐々に分かってきました。ですが、現場の開発メンバーにはまだあまりノウハウが伝わっていないため、そこを浸透させ、共通認識化させていくことがツールを活用する上での課題だと感じています。

__――今後のトライとして、現在考えられていることがあれば教えてください。__

__古澤__：ウォーターフォールとアジャイルを両方見ている立場としては、品質の観点では、アジャイルの方が若干良いと感じています。しかし、単純比較はできないな、とも感じています。

その理由として、アジャイルはプロダクトオーナーの判断で、開発機能の優先順位やリリース可否を変更できますが、ウォーターフォールではそうはいきません。

アジャイルが途中で変更されやすいことを踏まえると、計画時点でのPBIがどのくらい守れたのかといった指標も、数値的に見れると良いなと思っています。

__坂井__：ビジネスサイドまで含めた可視化をしていきたいと考えています。開発に閉じた生産性は「Findy Team+」で見えますが、本当に価値が届けられたのかまではわかりません。PBIや要求が生まれてから、リリースまでにどれだけ時間がかかったのかも見えないので、それを見えるようにしたいという思いがあります。

あとは、開発コストも可視化したいと思っています。サービスの収支については別途取り組んでいるのですが、もっとブレイクダウンして機能ごとの開発コストも見えるようにしていきたいと考えています。

価値が届けられているかどうかという部分については、どう計測するべきかがまだはっきりと見出せていません。アクセス数で測るのか、満足度アンケートを取るのか、それとも他にもっといい指標があるのか。これについては私たちの今後の課題だと思っています。

__――それでは最後に、組織のアピールポイントがあれば教えてください。__

__坂井__：開発力の高いチームが立ち上がってきているので、開発するもののビジョンさえ立てば、どんどん良いものを開発していける組織です。また、本部長が新技術の取り込みに積極的で、データ分析やAIをもっと取り入れていこうと掲げており、生成AIのCopilot導入に向けて動いています。私としても開発者の体験を向上させて、みんなが楽しく開発できるようにしたいと思っています。

__――皆さん、本日はありがとうございました！__
![【使用④】2shot DSC07329](//images.ctfassets.net/ngrpflsbp3rq/nroKriCNDCwZtCtznVyAV/c35853e62bea91c159929e3c35d68e18/_____2shot_DSC07329.jpg)

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
[https://findy-team.io/service_introduction](https://findy-team.io/service_introduction)

nec.netssi_interview_2024/01/16_FV

コミュニケーションに関わるさまざまなサービスを提供し、DX事業のブランド「Symphonict（シンフォニクト）」を展開する、NECネッツエスアイ株式会社。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

コード量からFour Keysへ。 経営層に新たな視点をもたらしたNECネッツエスアイの取り組み

parsol　FV

転職支援や求人メディアをはじめとした、幅広い人材サービスを展開するパーソルキャリア株式会社。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。 

インタビュー

開発生産性の高さを採用戦略の新たな切り口に。8名から開発者体験の向上を目指すPharmaXの取り組み

自律的な改善を促す組織文化の形成へ。生成AI時代を見据えたKDDIアジャイル開発センターの組織づくり

アジャイルへの移行の結果を可視化へ。データ・ドリブン経営を目指す弥生株式会社の取り組みとは？

開発生産性の可視化によりレビュー数が4倍に。メンバーの成長を促進させるユーザベースの組織づくり

「正社員2名」の開発組織からFourKeys向上へ。事業拡大を目指すmentoにおける開発組織の文化づくりとは？

潜在的な課題を特定し、数値に基づく目標設定へ。設立3年目で開発生産性向上を目指すミチビクの取り組み

経営と開発をつなぐ架け橋に。事業成長を加速させるツクルバの開発生産性指標の活用方法とは？

プルリクオープンまでの時間が9分の1に。15名でFourKeys向上に向き合うourlyの取り組みとは？

コード量からFour Keysへ。経営層に新たな視点をもたらしたNECネッツエスアイの取り組み

数値の意味づけや目標設定でメンバーの意識が変化。パーソルキャリアの全社的な開発生産性向上に向けた取り組みとは？

.css-1uuptc0 svg{width:32px;height:32px;fill:#666666;stroke:#666666;}@media (max-width: 750px){.css-1uuptc0 svg{width:24px;height:24px;}}インタビュー

開発生産性の高さを採用戦略の新たな切り口に。8名から開発者体験の向上を目指すPharmaXの取り組み

自律的な改善を促す組織文化の形成へ。生成AI時代を見据えたKDDIアジャイル開発センターの組織づくり

アジャイルへの移行の結果を可視化へ。データ・ドリブン経営を目指す弥生株式会社の取り組みとは？

開発生産性の可視化によりレビュー数が4倍に。メンバーの成長を促進させるユーザベースの組織づくり

「正社員2名」の開発組織からFourKeys向上へ。事業拡大を目指すmentoにおける開発組織の文化づくりとは？

潜在的な課題を特定し、数値に基づく目標設定へ。設立3年目で開発生産性向上を目指すミチビクの取り組み

経営と開発をつなぐ架け橋に。事業成長を加速させるツクルバの開発生産性指標の活用方法とは？

プルリクオープンまでの時間が9分の1に。15名でFourKeys向上に向き合うourlyの取り組みとは？

コード量からFour Keysへ。 経営層に新たな視点をもたらしたNECネッツエスアイの取り組み

数値の意味づけや目標設定でメンバーの意識が変化。パーソルキャリアの全社的な開発生産性向上に向けた取り組みとは？

インタビュー

コード量からFour Keysへ。経営層に新たな視点をもたらしたNECネッツエスアイの取り組み