ビジネスサイドが書く、事業成長を加速するSaaS「Findy Team+」ってなに？
ファインディ株式会社のオコノギ（@yui_okonogi）です！
近年SaaS業界では様々なサービスが登場していますが、「Findy Team+」をご存知でしょうか？
「エンジニア組織の見える化と生産性向上をサポートするサービス」
なのですが…ビジネスサイドには理解が難しいサービスかと思います。
（私自身、IT業界未経験でFindy Team+のカスタマーサクセスとしてジョインしましたが、最初の3ヶ月はかなり苦労しました😇。）
あまり馴染みのないエンジニア領域のサービスなので、「何のためのサービスなの？」と提供価値がわかりにくいのは仕方ないと思います。
ですが、いつも採用面談でご説明すると、「めちゃくちゃ面白いですね！」とよくおっしゃっていただけます。
そこで圧倒的に噛み砕いて、Findy Team+について説明する記事を書こうと思いました。
本記事では、「結局何のためのサービスなの？」をわかりやすくイメージできることに重点を置きました。
厳密には少し違う部分も出てくると思いますが、ご容赦ください。
誰に向けた記事か？
「Findy Team+って何？」を知りたい採用エージェント、企業人事の皆様
漠然とエンジニア組織にコミュニケーション不足や課題を感じている経営者の皆様
SaaS転職を考えているビジネス職の皆様
エンジニア組織が抱える課題とは？
そもそも、なぜFindy Team+が誕生することになったのか。
まずはエンジニア組織が抱える課題について、いくつかお話しします。
エンジニアが主体的に追えるKGI/KPIがない
企業の目標は常に、売上を伸ばし、利益を上げることですよね。
従業員はそれに貢献するために雇われています。
そのためビジネスサイドの皆さんは、ビジネス（売上）に紐づくKGI/KPIがあるかと思います。
ですが、エンジニアはどうでしょうか。
実はエンジニアの業務を、ビジネス（売上）に紐づけてKGI/KPIを設定するのは至難の業です。
KGI/KPIがないことは、個人・チームの目標が明確化しづらいことや、評価がしづらいことなど、色々な課題を生み出します。
ダイエットを仕事だと例えるとわかりやすいですが、下記のような状態だと成果の出しようがないですよね。
自分の理想的な体型は体重何kg / 体脂肪率何％なのか、目指す場所がわからない
そもそも今、自分が体重何kg / 体脂肪率何％なのかわからない
なんとなく痩せた気がするが、本当に痩せたのか測る手段がない
「このダイエットには効果がある」と証明することができない
今の開発組織はイケてるのか？伸びしろがあるのか？がわからない
ビジネスサイドは、「開発スピードって普通このくらい」という肌感がないことがほとんどです。
そのため、企画が適切なスピードで開発されているのか、判断することができません。
そんな中よく起きてしまうのが、ビジネスサイドとエンジニアでの下記のようなコミュニケーションです。
企画：XXという機能を、できるだけ早くつくっていただきたいです。どのくらいかかりますか？
エンジニア：そうですね、だいたい3週間程度ですかね。来月頭にはできるかと思います。
企画：もう少し早くならないですか？
エンジニア：そうですね…うまく行けば月末くらいにはできるかもしれません…。（まだ先週依頼を受けた機能も終わっていないのに…今週は残業かなあ）
企画：（クライアントに迅速に届けたいのに、もう少し早くならないものなのかなあ…）
共通認識がないことから、企画にもエンジニアにも不満が残ってしまいます。
また実は、エンジニア自身も「自社の開発は効率的なのか？」「もっと伸び代があるのか？」を認識できていないケースもあります。
ダイエットの例で言うと、体重は自分で鏡を見ればある程度わかるかもしれませんが、体脂肪率は自分でもよくわからないことが多いですよね。
これらの課題は「可視化」すると解消されるかもしれない！
これらの課題も一部ではありますが、まずは「可視化」することが課題を解決するために重要です。
そこでFindy Team+では、さまざまな機能を用意し、エンジニア組織の活動状況・パフォーマンスを可視化しています。
それでは、Findy Team+とはどんなサービスなのでしょうか。
Findy Team+とは？
Findy Team+は一言で言うと、「開発ツール（GitHub, GitLab, Jira）と連携して、（開発プロセスの一部である）コーディングプロセスを可視化するサービス」です。
…と言われても、なんとなくしか分からないですよね。
そもそも、開発プロセスとは？
つくりたいものを考えてから完成するまでの流れが、開発プロセスです。
具体的には、「計画」→「設計」→「実装」→「テスト」→「リリース」。
開発プロセスは、大きく分けると2種類あります。
ウォーターフォール：初めに完璧な計画を立てて、粛々とスケジュール通りに開発する手法
アジャイル：小さく計画して即作って、小さな完成品をどんどんリリースしていく手法
多くの自社サービス企業は、アジャイル開発を採用しています。
そしてコーディングプロセスとは、開発プロセスの一部である「実装」→「テスト」→「リリース（の途中まで）」 です。
アジャイル開発において「計画」→「設計」は主にプロダクト企画部門が担当します。
「どんな機能をどのようにつくってほしい」という「計画」→「設計」が定まったら、エンジニアがコードを書いて開発し、実現できたらリリースする、というのが一連の開発プロセスです。
Findy Team+は（主に）コーディングプロセスでの活動状況を可視化するサービス
多くのエンジニアの業務は、プログラミング言語を用いて「実装」→「テスト」→「リリース（の途中まで）」を行うことです。
そのため、コーディングプロセスでの活動状況を可視化することで、エンジニアの活動状況を可視化することができます。
（※厳密にはプログラムを書かないインフラエンジニア、QAエンジニア等の職種もありますが、ここでは言及しません）
では具体的にどんなことが可視化できるのか、一つの機能を使ってご説明していきます。
Findy Team+ができることーサイクルタイム分析
今回は「サイクルタイム分析」をご紹介します。
この機能では、「GitHub（GitLab）上の各プルリクエストに紐づく、最初のコミットからマージされるまでのリードタイム」を分析できます。
全然意味がわからないですね。噛み砕いてご説明していきます。
そもそも、GitHub（GitLab）とは？
GitHub（GitLab）とは、プログラムのコードやデザインデータを保存・公開できるソースコード管理サービスです。
本当にイメージですが、「開発に適したGoogleドライブ」みたいなものです。
（チームやフォルダを作ってファイルを管理、自分の作成したファイルを共有、レビューをもらう、等）
そもそも、プルリクエストとは？
プルリクエストとは、GitHub（GitLab）上で作成する「アプリケーションに小さな変更依頼をするコード群」です。
本当にイメージですが、本番環境が「HPに公開されている採用スライド資料」だとします。
今月、社員数が3名増え、会社概要資料に変更を加えたいとします。
そこで新しく会社概要資料をつくり、「新しい会社概要資料をつくったので、HPの資料に反映させてください」というのがプルリクエストです。
※プルリクエスト＝プル（引っ張る＝本番環境に反映させる） ＋リクエスト（要求）
この例の場合、公開されている資料に変更に加えるので、下記のような手順で変更を行うかと思います。
原本のコピーを作成
コピー上に変更を加え、変更内容を他者にチェックしてもらう
問題なければ原本の資料に反映させる
システムの開発でも同じようなプロセスを踏んでいます。
「サイクルタイム分析」のサイクルとは？
この図は、プルリクエストが作られてから、本番環境に反映されるまでの一連の流れです。
サイクルとは、この一連の流れを指します。
・コミット
コードを書くときのセーブ機能です。
（資料作りでの例：PowerPointで資料をつくるときに逐一保存するイメージ）
・オープン
プルリクエスト（以下、プルリク）をつくり、チームに公開することです。
（資料作りでの例：自分のPCでPowerPoint資料をつくり、Googleドライブにアップロードして共有する）
・レビュー
その名の通り、プルリクのレビューです。変更内容を他者にチェックしてもらいます。
（資料作りでの例：「数値間違ってるよ」というミス指摘から「ここはもっとデザインを変えると見やすいね！」というMore指摘まであります）
・アプルーブ
プルリクの承認、つまりレビュー通過のアクションです。
（資料作りでの例：資料作りではボタンはありませんが、「OK」をもらいますよね。GitHubにはApproveボタンがあり、アクティビティとして記録されます）
・マージ
プルリクを原本のコード群に反映させることです。
（資料作りでの例：上記例の通り、HP採用資料から旧・会社概要を削除、新・会社概要を追加する）
エンジニア組織では、各々がプルリクを作成し、相互にレビューしながら開発を進めています。
サイクルタイム分析を見てみよう
この機能では、プルリクの一連の流れにおいて、「どのフェーズでどのくらい時間がかかっているか？」がわかります。
上記は、チームメンバーが作成した全プルリクの、平均リードタイムです。
例えば次のようなことがわかります。
「コミットからオープンまでの平均時間」が31.7hなので、エンジニアが一つの変更依頼をつくるのに1日半くらいかかっている💻
「オープンからレビューまでの平均時間」が5.8hなので、他者にレビュー依頼をしたらその日中にはレビューをもらえる📝
「レビューからアプルーブまでの平均時間」が2.0hなので、ほとんど修正することなく承認がもらえている👏
サイクルタイム分析にはどんな意味がある？
プルリク単位のリードタイムを見ることで、自社の開発が「作業単位で効率化できているか？」がわかります。
一概に言えない部分はありますが、基本的にはリードタイムが短い方が効率よく開発できている傾向にあります。
ビジネスサイドで言うと、資料作りでも、作業を細かくレビューを頻繁にもらった方が効率的ですよね。
「レビューがくるまで何日もかかると仕事が進まない」「完璧に作ってからレビューをもらったら全部やり直しになった」など、チーム内で作業のボトルネックとなっているところをリードタイムで可視化することができます。
Findy Team+で開発パフォーマンスが大幅改善！
可視化できた先には、どんな効果があるのでしょうか。
Findy Team+が目指すのは、可視化したデータを用いてエンジニア組織のパフォーマンスを向上させることです。
可視化してみると、実はエンジニア組織によってパフォーマンスは大きく異なります。
（サイクルタイムも、数十時間〜数百時間と開きがあります…！）
最初から伸び代がないほどパフォーマンスの高い企業様は少ないですが、取り組み次第でどの組織もパフォーマンスが大幅に向上する可能性があります。
実はご導入企業様でも数倍改善される事例がいくつもあり、テックブログ等で取り組みや成果を公開いただいています！
近年では「開発生産性」というワードが徐々にトレンドになってきており、エンジニア組織にとっては重要だと考えられるようになってきていると思います。
事業成長が加速し、日本のイノベーションが加速する
そして突然壮大な話になりますが、最後に開発生産性が向上することの意味を考えたいと思います。
まずは開発生産性が向上すると、事業成長が加速すると言っても過言ではありません。
例えば新規SaaSをローンチするのに、1年かかる企業と半年かかる企業では、事業成長のスピードは圧倒的に後者の方が早いと言えます。
（同じ人数のセールスパーソンを抱えていても、商材がないと売ることができませんよね。）
他にも、社内の業務効率化システム開発、既存プロダクトの新機能開発なども、売上拡大もしくはコスト削減が目的ですよね。
つまり、事業を成長させたいなら、開発生産性を改善することが大きなドライバーになるということです。
そして、各社の開発パフォーマンスが向上すると、各社の事業成長が加速していき、日本全体でイノベーションが加速していくはずです。
そんな世界をファインディは目指しています！
さいごに
長文にお付き合いいただきありがとうございました。
ビジネスサイドの皆さんが少しでもエンジニア組織の課題を認識したり、Findy Team+をつかって事業成長を加速させたいと思っていただけたら嬉しいです。
一緒に働ける仲間を募集しています！
ファインディではこのように「挑戦するエンジニアのプラットフォームをつくる」ことを目指し、日々エンジニア領域の課題に向き合い、価値提供に邁進しています。
少しでもご興味があればカジュアル面談を実施させてください。
オコノギ（@yui_okonogi）宛にDMをお待ちしております！
▼Findy Team+カスタマーサクセスにご興味のある方はこちらご覧ください😊
▼採用情報はこちらです！
この記事が気に入ったらサポートをしてみませんか？