こんにちは、HelpfeelでTeam Leaderをしているエンジニアの寺本(@teramotodaiki)です。
入社から1年半が経ちまして、最近ではチームメンバーのマネージメントもしつつ、新機能開発から細かなバグ修正まで、コードを書いて解決できることなら何でもやらせてもらってます。

今回はHelpfeelのリブランディングと社名変更に向けたNota Reborn Calendarの9日目ということで、HelpfeelのValueにも深く紐づいた社内ツール「DevReport」の開発秘話について書こうと思います。

この記事を３行でまとめると

🤔エンジニアの原価計算のために、エンジニアは毎日作業報告をする必要がある
😳でも、エンジニアの作業報告ってGitHubのコミットログそのものじゃない？
🤗という訳で、いい感じに自動生成してくれる社内ツールを作っていきたいと思います〜（ﾊﾟﾁﾊﾟﾁ

このツールが生まれた背景

弊社は上場を目指すスタートアップ企業であり、上場のためには監査を受ける必要があります。その監査を受ける際に必要なことの一つが、「エンジニアの原価計算」です。

エンジニアの原価計算

通常、会計には、売上に対する原価というものが存在します。ハードウェアを作って売るならば原価はわりと単純に求められますが、ソフトウェアの場合はエンジニアの人件費が原価であると考えられています。
しかしエンジニアの人件費の全てが原価というわけではないため、人件費のうちいくらを原価にするのか、基準を作って按分しています。この基準は会社によって異なりますが、弊社の場合プロダクトの開発フェーズと作業内容によって会計上の分類を行うことになっています。

原価計算には日報が必要？

エンジニアの原価計算は、各自の作業報告内容に基づいていなくてはなりません。「全員一律で何％」のような計算ではなく、「今月はこれこれしたから、この人は人件費に対して何％が原価なのです。証拠はこちらです」という形にする必要があるのです。
これをどのようにして計算するのかと言うと、日報を基準にすることが多いそうです。会計上の分類については、エンジニアが自分で申告してマネージャーが確認する方法や、マネージャーが全て分類する方法などがあるそうです。
普通に考えると、エンジニアが監査のために日報を書かなければいけなくなるのです。

自動化できないか

監査の影響によるエンジニアの負担増を危惧したCEOの洛西は、すぐにツールで解決するアイデアを考えました。その方法とは、GitHubのプルリクエスト機能（以下プルリク）から作業記録を生成するというものです。
その時たまたま手が空いていた僕に白羽の矢が立ち、まずは「稼働内容の一覧を試しに２週間分だけ出力して欲しい」というお題が降りてきました。結果さえ得られれば方法は問わないという条件でした。

まずは僕がGitHub APIを用いて対象期間の稼働内容の一覧を取り出して、次にCTOの秋山（当時は開発部長兼VPoE兼Helpfeel PM）がタスクの内容を目で見て判断し、会計上の分類を手作業で入力して集計するという作戦を立てました。最初の作戦としては妥当だと思いましたが、これを毎月行ったらCTOの秋山（当時は開発部長兼VPoE兼Helpfeel PM）が上場前に過労で倒れてしまう可能性の方が高いのではないかと思いました。

いちエンジニアとしても、日報を書くのはしんどいですし、これまで「研究」として自由に取り組んでいたような、意味があるのかないのかハッキリとは分からないようなタスクまでいちいち分類して報告していたら、「研究」のモチベが著しく下がるだろうなという危機感を抱きました。
そこでHelpfeel開発のかたわら、これも「研究」として、ツール開発に取り組むことにしました。

※弊社における「研究」という文化については、All Stars Meetupで話した時のScrapboxをご覧ください。

どのように開発を進めていったのか

どうなったら嬉しいのかを言語化する

まずは関係者（CEO、開発部長、監査法人との窓口になっている管理部）そして僕というメンバーで、ざっくりとアウトプットのイメージを共有しました。「そもそも、監査って何ですか？」という質問から、監査の目的、SaaS企業における原価計算のあり方など、いわゆるコーポレートガバナンス的な視点を学びました。

社外の方（監査法人のご担当者）が見られるので、レポートがしっかりとした見た目になっていることも重要です。とはいえ、他社事例を参考にしたくとも、監査に提出した資料なんてインターネットに公開されていません。

そんなことを話していたMTGの最中、CEOの洛西が突如SpreadSheetを作り始め、「こんな感じのイメージで〜」と言ってダミーデータを打ち込んだり集計の関数を書いたり枠線を描いたりして、CTOの秋山と一緒に、あっという間にラピッドプロトタイピングを作り上げてしまいました。この時作られたビューは、ほとんどそのまま最終形にもそのまま使われることになります。

あとはSpreadSheetに入れる稼働データがあればいいよね、という話になり、稼働データを生成するツールの開発がスタートしました。その後も、業務の傍らでツールをブラッシュアップしては、一ヶ月に一度くらいのペースでCEO、開発部長、管理部からフィードバックをもらうというサイクルを４〜５回繰り返していきました。

V1: GitHubの情報をもとに稼働時間の割合を出力するツール

※V1はバージョン１という意味です。

まずは、最も不確定要素の大きい「GitHubの情報をもとに稼働時間の割合を出力できるか」という課題から取り組み初めました。
GitHubからプルリクの一覧を取得します。最初はPAT（Personal Access Token）で実験し始めましたが、PATでは僕の個人的なリポジトリにまでアクセスできてしまうため、GitHub Appに移行しました。

全データを一括ダウンロードしてみたところ、とんでもなく古いリポジトリがあって面白かったです。GyazoなんかはGitHubより昔から存在しているくらいですし、大昔にやっていたサービスなんかも残っていて、とにかく歴史の重みを感じました。勢いよくfetchするとGitHub APIのrate limitに引っかかってしまうので、API requestを1秒に1回くらいのペースまで抑えました。

V2: Googleカレンダーを追加

GitHubだけだと、マネージメント業務が多い従業員の作業報告を上手く生成できなかったため、Googleカレンダーの情報もデータソースに加えました。当時は「ちょっといいね」程度でしたが、組織が拡大してきた現在では必須のデータソースとなっています。
機能を追加したことで、イベントによって会計上の分類が異なるという問題をどう運用でカバーしていくかという問題にぶつかりました。まずは試しにデータを出してみて、それを人間が分類して、その結果をパターンに落とし込むという流れが良さそうだということで、CTOの秋山と共同でパターンを増やしていきました。
改めて考えると、これはHelpfeelのテクニカルライターが顧客企業の既存FAQを読み、その内容から質問文を考えて、Helpfeel記法に落とし込むというテクニカルライティングにも通ずるものがあります。

V3: 人事労務freeeとの連携

これまでは、会計上の分類ごとの割合は分かっていましたが、勤務時間は一律１日８時間として計算しており、これが論理の穴になっているのではないかと感じていました。弊社ではfreeeという勤怠管理サービスを利用していますが、作成中のツールが生成する稼働時間は人事労務freeeに入力された総勤務時間と一致することが理想です。

人事労務freeeのダッシュボードから勤怠レコードをCSVで出力できることに気付いたので、まずは自分のデータで動くようにしてみました。その後、他の人にも協力してもらって、勤怠レコードを出してもらい、出力結果を見て違和感がないかを確かめてもらいました。

この時点で当初の目的は達成出来たと判断し、まずは全てのスクリプトを実装者（僕）が回す形で運用がスタートしました。

V4: 誰でもブラウザで使えるツールに

ちょうどこの頃、経理の方が入社されて、運用を引き継いでいただけることになりました。１ヶ月やってみて、運用フローのうち手作業が必要な部分がどこか分かっていたので、Next.jsでWebアプリ化し、経理担当者に任せられる部分をGUIにして、Herokuにデプロイしました。

ツールの名前は「DevReport」に決まりました。

‍

図　DevReportの実際の画面

※「開発部の管理者の方が月の初めに行ってください」と書かれていますが、現在は自動的に実行されています。

ここまで、Helpfeelの開発業務と並行して取り組んで、およそ４ヶ月ぐらいでした。

得られた成果

エンジニアが日報を書かなくて済んだ

現状から何かが変わったわけではないので嬉しさを実感しづらいのですが、困難を未然に防げたという事で良かったです。

それっぽい費用対効果を述べると、日報を書くために1日10分かかるとして、年240日稼働したら2400分=40時間です（すごい！）。それがエンジニア10名に発生すると考えれば、なんと年間400時間もの工数削減効果が見込まれます。人件費を１時間あたり4000円とすれば、年間160万円の削減ですね。

肝心のDevReportを作るのにかかった工数はちゃんと計算していませんが、実はそんなにかかっていません。ROIはかなり高いと思います。厳密にやりすぎるといくらでもこだわることができてしまう課題に対し、良い感じの落とし所を見つけるセンスというのは個人的にも、また会社としても強みだと思います。

経理担当者に運用を引き継げた

これは個人的に最も達成感のあるマイルストーンでした。なんというか、自分用のツールではなく、人の役に立つツールになったなと感じた瞬間でした。

WebのUIを社内のMTGでデモした時、「もうSaaSとして売れるんじゃないか」と言ってもらえた時は素直に嬉しかったです。（僕はセールスできる自信がないので、売ってくれる人さえいれば…w）

こだわったポイント

まずはCLIツールを作り、運用してからNext.jsに移植した

最初からWebのツールとして作っていたら、UIの議論が発散して、こんなに短期間では作れなかったと思うので、この方針は正解だったと思います。そもそも最初のプロトタイプは2021年度決算に間に合わせるため、10日間で作る必要がありました。
UIの実装はこだわりの連続です。しかし今回は敢えて、こだわらないことを最初に決めました。

このツールで重要なのは入力と出力だからです。

• 実行時間が長くてもいい
• GUIがなくてもいい
• 最初は自分がコマンドを叩く係をすればよい
• 運用もツールに合わせて後から考えればいい
• 集計はSpreadSheetでやればよい

CLIとして作り始めたことで、余計なことを考えず、入出力をつなぐ処理にフォーカスできました。

他にも沢山ありましたが、専門的な話になるのでいつか技術系の話をする場に持ち越したいと思います。

おわりに

発想の転換によって、常識は変えられる

人件費を按分して原価計算したいとき、普通は日毎のタスクと所要時間を入力してから、それを集計して割合を求めるというアプローチをとるはずです。今回紹介したDevReportは逆の発想で、GitHubなどのソースから実際に行った作業の分類と割合を導出してしまって、勤怠の稼働時間に掛け算してやればよいというアプローチです。こういうのを思いついて現実的なアイデアに落とし込めるCEOの洛西はすごいなと改めて思います。

Helpfeelの新しいValueにも、このような一文があります。

‍Create the future - 一足先の未来を想像する

Helpfeelのメンバーは、野心的に、前向きに、そして偏見や経験にとらわれずに考えることで、独自の価値を創造し、お客様にお届けします。

今回の開発秘話で知って貰いたかったのは、このツールの開発がまさに新しいValueのひとつである「Self-drive - 自律的に行動する」というValueを体現したものだった、ということです。つまり、

「こういうツールを作って下さい」と命令されるのではなく、
「こういうツールを作ってみたんですけど、どうですか？」とエンジニアから提案する

これこそが弊社のカルチャーであり、Helpfeelが提供する価値です。

良いツールが出来たらみんなからめっちゃ褒められるので、とても気持ち良くなれます。

他のValueも知りたくなった方は https://corp.helpfeel.com/ja/rebranding もぜひご覧ください。

エンジニアが自律的に裁量をもって仕事をすることができるHelpfeel

そんなHelpfeelであなたも働いてみませんか？
Helpfeelはカルチャーフィットをとても重視しています。この記事を読んで少しでも興味をお持ちいただけましたら、ぜひご応募ください。

カジュアル面談でお会いしましょう！
https://meety.net/matches/NABtpOlaFkxD

‍