NEW
開発パフォーマンスを経営層にも「見える化」へ。 部署の垣根を超え、全社員でプロダクトの改善に挑むdiniiの取り組み。
外食産業のインフラを目指すdiniiは、飲食店向けの POS を中心として、 All in One Restaurant Cloud を展開しています。diniiでは、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。
今回は、diniiにてVPoT（VP of Technology）を務める唐澤さんと、エンジニアリングマネージャーを務める浦山さんにインタビュー。開発生産性の計測への取り組みを始めた背景や「Findy Team+」を導入した理由、現在の活用方法などについて伺いました。
目次
学生起業から始まったスタートアップ、diniiに感じた魅力
――最初に、お二人の主なご経歴や現在の役割についてお聞きしたいと思います。まずは唐澤さんから教えていただけますか？
唐澤：新卒で株式会社メルカリに入社し、1年ほどソフトウェアエンジニアとして活動しました。担当はフロントエンドで、メルカリのアプリ内にあるWebView向けのアプリケーションを開発していました。そして、その後diniiへ転職。diniiはもともと東大の学生が起業した会社で、創業者が自分の先輩だったので、そのつながりで声を掛けてもらい参画しました。
正社員の第1号として入社し、モバイルオーダー事業が始まった直後からジョインしたので、今あるほぼすべてのプロジェクトの技術的な意思決定などを行ってきました。昨年の夏からは、VPoTをしています。
――diniiにどのような魅力を感じて、正社員としてジョインすることを決めたのでしょうか？
唐澤：創業者の社長やCTOと話をするなかで、この2人がつくる会社であれば成功しそうだというイメージがありました。2人とは年齢も近く、芯の部分からわかり合えた気がしたことと、diniiで自分が活躍するイメージを持てたことも大きいです。
もともと2人は、大学時代に学生向けの起業支援プログラムで、すでにチーム単位で活躍していたんです。その当時、自分は別のチームに所属していたのですが、彼らのチームはプログラムを開始して数日でプロダクトを導入し始めていて、別のチームから見ると異彩を放つ存在でした。
そのときから本当に行動力があるなと思っていましたし、飲食店というドメインに対して深く入っていく、良い意味でのこだわりのなさも感じて、このチームなら勝てるだろうという思いがありました。
――続いて、浦山さんからもご経歴や現在の役割についてお願いします。
浦山：僕はdiniiが4社目です。新卒ではセコム株式会社に総合職で入社したのですが、徐々に社内でソフトウェアのエンジニアを志向するようになりました。その後は、株式会社インターネットイニシアティブに入社し、クラウドサービスを開発していました。
次に唐澤さんと同じく、メルカリに転職。WebプラットフォームチームというWebプロダクトの共通基盤を開発するチームで、フロントエンドやインフラの技術をメインとして、テックリードやエンジニアリングマネージャーを担っていました。
メルカリ退職後は、個人でサービスを開発していたのですが、昨年8月にdiniiのエンジニアメンバーから声を掛けてもらい入社しました。いちエンジニアとして手を動かしていた期間が4ヶ月ほどあり、昨年12月からはエンジニアリングマネージャーをしています。
――個人での開発をされていたなか、diniiのどんなところに魅力を感じてジョインを決められたのでしょうか？
浦山：もともと自分としては、単純に良いものをつくることと、良いものをつくれる組織をつくることに関心があったんです。自分で手を動かしてものをつくることで、個人のエンジニアとしてやりたいことが一定はできた実感があり、組織でしかできないこともやってみたいという気持ちがありました。
diniiはメルカリ出身のメンバーが多く、エンジニアのレベルが高い組織だということは知っていました。かつ、プロダクトの特性として、スタートアップのため、スピード感ある開発が求められる一方で、障害が起きると飲食店のオペレーションが止まってしまうため、品質も求められます。そういったところが、エンジニアとしてチャレンジングで面白そうだと感じました。
マルチプロダクト展開をしていくことも含め、さまざまなチャレンジングな要素があって組織として面白そうだし、成長にも期待できる。diniiのそういったところに大きな魅力を感じました。
――お二人の役割についてくわしくお聞きしたいと思いますが、まずは唐澤さんのVPoTという役職について教えてください。
唐澤：名前自体にあまりこだわりはないのですが、VPoTの役割は、システム面から顧客への提供価値に責任を持つところにあります。具体的には、そのシステムを使うことで顧客がきちんと業務を実行できているか、安定性の面で不具合なく動いているか、そして継続的にそれを改善できるシステムになっているかなどです。組織によっては、CTOやVPoEが担っている部分かもしれません。
――VPoTとして役割を切り出されたのは、どういった背景がありましたか？
唐澤：CTOとの役割分担が主な理由です。弊社のCTOは創業メンバーで、エンジニアリングだけに強みを持っているわけではなく、飲食のドメインにくわしく、経営者として会社全体にコメントができる立場にあります。
その立場で、システム面の詳細まで責任を持つ必要はないだろうということで、そこを切り出して自分が担当しています。むしろ今、CTOはアカウントセールスをしているセールス組織の管理まで担っていて、CTOとしては珍しいのではないかと思います。
――浦山さんはエンジニアリングマネージャーとして、普段どのようなことを担っていますか？
浦山：システムなどの技術面は基本的に唐澤さんが見ていて、自分は組織面を見ています。採用や評価、今後の組織体制についてなどですね。
自身の担当領域にとどまらず意見を出す、壁のない組織
――開発組織として掲げているミッションがあれば教えてください。
唐澤：開発組織として明確に掲げているミッションはないのですが、組織全体に浸透しているポリシーとして、自分自身の担当領域にとどまらず、自分が触れるものはすべて触るという考え方があります。
役割分担をしてしまうと、役割ごとにコミュニケーションコストがかかったり、まわりが見えず部分最適になってしまったりして、上手く動けない部分が出てきます。そのため、すべての人がすべてのところに意見を出せるような仕組みづくり、意識づくりをしています。
エンジニアリングのなかで、フロントエンド、バックエンドといった役割を超えるのは当然のこと、デザインや仕様にも意見を出します。ときには、アカウントセールスがレポーティングする顧客へのサクセス活動に対して、「こういった提案のほうがいいのではないか」とか、「こういう機能を上手く使ってほしい」と伝えたりもします。
そのほか、会社のコーポレート的な部分に関しても、例えばオンボーディングのやり方に意見することもありますし、いろいろなところで壁をつくることなくコミュニケーションしています。
――開発生産性の計測について、どのようなきっかけや背景から取り組みを始められましたか？
唐澤：開発組織のパフォーマンスを定量的に把握したいと思っていました。なぜかというと、先ほどお話ししたとおり、会社の文化として、別の部署のパフォーマンスも気にしている背景があるからです。
セールスチームではリードや商談、コンバージョン、受注など、すべての活動を数字で表すことができますよね。これらは目標の数字も掲げられていて、エンジニアも把握しています。そうすると、他の部署からも目標に対する頑張りがわかりやすく見えますが、それと同じことを開発組織でもできないかと考えたんです。
コストは人件費で出すことができるので、リソースを上手く活用できているかどうかを報告したい。ただ、そこでアウトカムとして、機能のリリース数などを出しても粒度が荒く、それだけでは良いとも悪いとも言えません。そのため、もう少し手前の数字を取り、何が成果につながったのかを示せるようにして、振り返りができるようにしたいと考えていました。
――開発組織でもそういった数字が見れると、メンバー自身や組織内での改善も進むだろうということですね。
唐澤：そうですね。もう少し小さな単位では、業務委託の方のパフォーマンスを見たいという意図もありました。開発組織全体では、長期的な取り組みも含まれるので計算が難しいのですが、目の前のタスクに取り組む業務委託の方は、報酬に対してどれくらいのアウトプットが出ているかを計算しやすい。費用対効果に見合ったものができていることを、報告しやすくなるという期待がありました。
浦山：補足すると、業務委託であっても正社員であっても、数値でダイレクトに評価することはしていません。ただ、数値が出せると、その活躍が経営陣にも一目でわかってもらいやすいということですね。
一方で、もしアウトプットが出ていない場合があれば、あくまでヒントとして使います。数値が出ていない原因がどこにあるのか、一時的なものなのか、ケアできるものなのかといったことを、1on1などで話しながら加味していく。そういうコミュニケーションを促進するために使っています。
――開発生産性の計測にあたって、「Findy Team+」の導入を決めていただいた理由を教えてください。
唐澤：当初は、海外のプロダクトで無料で導入できるものがあったので、まずはそれを見ていました。ただ、そのプロダクトでは「Findy Team+」で言うところのリードタイムの一番大きな粒度でしか見れず、組織ごとに見たり、より細かいリードタイムの内訳を見たりすることができなかったので、あまり学びがなかったんです。その後、「Findy Team+」を知り、かなり細かい粒度で見れることがわかったので、導入してみようと判断しました。
――開発生産性の計測を通じたゴールは、どういったところに設定されていましたか？
唐澤：まずはシンプルに、持っている仮説を数量的に示すというところですね。長期的にはメンバーが自走して、自身で成長できるようになるのが理想だと思っています。
――開発組織のOKRやKPIに、定量数値を設定されていますか？
浦山：チームではなく、個人の目標では使われています。レビューのリードタイムを短くするとか、自分のプルリクエストに対するコメントが多ければ、平均コメント数を減らすとか。そういった個人の目標には使いやすいと感じています。
開発組織の活動を、経営陣や開発組織外へレポーティング
――「Findy Team+」の導入について、社内ではどのように理解を得ていきましたか？
唐澤：経営陣については、開発組織のリソースを上手く使えているかという観点は、全員が気にしていることなので、それに対する取り組みだということでスムーズに理解を得られました。
正社員のメンバーに向けては、まずは「Findy Team+」の皆さんと一緒に説明会を開きました。あとは、日々の1on1や目標設定などのタイミングで、必要に応じて各メンバーと数値を見ながら話をするようにしています。
――生産性を可視化することに対して、メンバーからのネガティブな反応はありませんでしたか？
浦山：今のところありません。というのも、先ほどお話した通り、単純に数値を見て評価することはしていないからです。目標設定にしても、単純に達成したからOK、達成しなければNGではなく、その目標に対してどういったアクションをしたか、実際のアウトカムはどうだったかなど、中身をしっかりと見ています。
唐澤：会社的には、顧客にどれだけのアウトカムを与えられたかが重要で、評価ではそういったところを見ています。数値はそのプロセスにおいて、各自が自己分析をしたり、マネージャーがアドバイスをしたりするところに使っているだけなので、その情報量が増えることに対して、メンバーがネガティブな印象を持つことはないように思います。
――ここまでにお話しいただいた以外にも、「Findy Team+」の活用方法があれば教えてください。
唐澤：今まさに取り組んでいるのは、「Findy Team+」を使った経営上のレポート作成です。内容としては、まず開発が進んでいるか、顧客への導入が進んでいるかなどを分析したうえで、いくつか仮説を立てて、それを「Findy Team+」で検証します。例えば、あるチームでアウトプットが減っていて成果が増えていないとすれば、アウトプットが原因だと考えられるから、そこを上げていく必要があると提案するようなイメージですね。
――アウトプットとしては、主にどういった指標をご覧になっていますか？
唐澤：プルリク作成数とプルリクごとの平均変更行数を見ています。
――リードタイムについてはいかがでしょうか？
唐澤：リードタイムはヘルスチェック的に、大きく伸びてしまっている条件がないかどうかは確認しています。リードタイムを短くするのは、改善のサイクルを早めたいからですが、弊社の場合、そのサイクルのなかで開発が占める割合はそれほど高くありません。
それよりも、実際に顧客に機能を使ってもらうインストールの部分であったり、バックログ上で長い間溜まっていてなかなか着手されなかったり、といったところが問題になります。そのため、着手してからリリースまでは、あまり見ても仕方がないと思っています。
――開発生産性の可視化を通じて、組織やメンバーのなかで意識や行動が変化したと感じることはありますか？
浦山：メンバー自身が定量的な目標を立てやすくなり、それを意識できるようになってきたと思います。個人のパフォーマンスを向上させたくても、主観的にしか見られなかったり、自分ではどうすればいいのかわからなかったりしたことが、数値として見えるようになったことが大きいですね。
唐澤：組織としては、開発組織以外のメンバーから見て「開発が何をしているのかよくわからない」という状況がありましたが、可視化によってレポーティングできるようになりました。それによって、「きちんと活動しているからこそ結果が出ているんだ」という、実感のこもった信頼を得られるようになったと思います。
――「Findy Team+」のおすすめポイントを挙げるとしたら、どんなところでしょうか？
唐澤：メトリクスがすごく多いので、仮説を検証するためのヒントは何かしらあると思いますね。ぴったり合うものがないときもありますが、そういった場合は要望をお伝えさせてもらっているので、今後にも期待しています。
「事に向き合う」姿勢で、本質的な問題を解決していく
――今までの取り組みのなかで難しかったポイントや、今後取り組んでいきたいと考えていることがあれば教えてください。
唐澤：「Findy Team+」では見れる数字がものすごく多いので、それをランダムに眺めていても、結論を得にくいと感じます。実際に、最初は結構ランダムに見ていたので、すごく時間がかかってしまいました。まず先に仮説を持ったうえで、それを検証するために必要な数字があるかを見ていくのがいいと思っています。
浦山：取り組みのなかで感じるのは、チームによる特性の違いですね。例えば、弊社のフィーチャーチームではレビューを比較的厚めにやっていて、その分リードタイムは他のチームに比べると長くなっています。
ただ、それはコードのクオリティの面で言うと、必ずしも悪いことではないので、チーム間での単純な比較はできないなと。チームごとの特性を把握したうえで、個々のチーム内でどう改善していけるのかという部分は、今後トライしていきたいところです。
そのほかにも「Findy Team+」は、開発生産性向上のためのツールを入れたりプロセスを変えたりしたときに、それが全体にどう影響を与えるのかといったモニタリングにも使えると思っています。今後そういう機会があれば、前後の差分を見てみたいと考えています。
――それでは最後に、組織のアピールポイントや一緒に働きたいエンジニア像について教えてください。
唐澤：diniiはロールごとの壁がなく、とてもフラットな組織です。自分自身で改善したものがアウトカムとして出て、売り上げも立ち、飲食店への良い影響も与えられる。そして、実際に飲食店に行けば、それを自分で体験することもできます。自分で何でもやりたいと思う人には、すごく合っている環境だと思います。
浦山：自分の転職理由でもお話しした通り、diniiは生産性と品質の両方がかなり高い水準で求められる組織です。少ない人数でマルチプロダクト展開をしていくなかでの生産性と、飲食店のオペレーションを支えるという部分での品質。そこはやはりエンジニアとしてチャレンジングだと思うので、そういったところに挑戦したい方にとって、すごく良い環境だと思います。
そして、diniiのエンジニアはフルスタックエンジニアの枠組みを超えて、フルサイクルエンジニアと言ってもいいくらい、必要に応じて幅広い周辺領域にも染み出していきます。diniiには「事に向き合う」というバリューがありますが、組織やプロダクトの本質的な問題を解決するための動きに価値を感じる方々は、すごく合っている組織だと思いますし、そういった方と一緒に働きたいと思っています。
――唐澤さん、浦山さん、ありがとうございました！
※現在diniiでは、エンジニアを募集しています。
https://findy-code.io/companies/803/jobs
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
