シェア
はてブ
2024年6月28日、29日の二日間にわたって、ファインディ株式会社が主催するイベント「開発生産性Conference」が、開催されました。本カンファレンスは、虎ノ門ヒルズフォーラム（東京）にて実施され、一部のセッションはオンライン配信も行われました。
本記事では、オンラインでも配信されたセッションのうち、株式会社LayerXでEngineering Managerを務める高江信次さんによるセッション「爆速開発文化を支えるProduct Engineerの開発生産性向上の取り組み」の内容をお届けします。
法人支出管理SaaSを提供するバクラクを中心にFintech、AI・LLMなど幅広い事業を展開する株式会社LayerX。同社のバクラク事業部では、開発生産性の向上に向けて、アウトカム（顧客への価値提供）をベースとした独自の指標を設けています。どのような指標を設定し、どのように計測しているのか？本セッションでは、同社が取り組んでいる開発生産性向上に向けた取り組みについてお話しいただきました。
■プロフィール
高江 信次（たかえ しんじ）/ @shnjtk
株式会社LayerX バクラク事業部 プロダクト開発部 カード開発グループ Engineering Manager
奈良先端大を卒業後、ソニー株式会社にてR&Dや新規事業の立ち上げに従事。その後フリーランスとして独立し、2019年12月にLayerXへジョイン。企業活動のインフラとなる法人支出管理Business Spend Management（BSM）SaaS、バクラク事業の立ち上げから参画し、当初は主にインフラの開発・運用を担当。2022年にリリースしたバクラクビジネスカード（法人カード）の開発をリードし、現在はEngineering Managerを担当。
ミスの許されないコーポレート業務をサポート
高江：株式会社LayerXの高江と申します。本日は「爆速開発文化を支えるProduct Engineerの開発生産性向上の取り組み」と題してお話しさせていただきます。よろしくお願いいたします。
最初に自己紹介をさせてください。私は新卒でソニーに入社してR&Dや新規事業を担当したあと、フリーランスを経て、LayerXに転職しました。LayerXではバクラクの初期段階から関わっており、インフラの開発・運用からスタートして、Webアプリ開発を担当しました。現在はバクラクビジネスカードの開発チームのEMを担当しております。
本日は、LayerXの事業と開発組織と文化について紹介したあと、メインテーマの開発生産性について「評価」と「取り組み」にわけて、それぞれお話しします。
高江：LayerXは「すべての経済活動を、デジタル化する。」をミッションとし、法人支出管理（ビジネス・スペンド・マネジメント）を対象としたサービス「バクラク」を提供しています。それ以外に、Fintech事業として不動産のアセットマネジメントや証券事業も展開しています。また2023年11月からは企業や行政のLLM活用を支援するAI・LLM事業も立ち上げています。
私が所属しているバクラク事業部では、ミスが許されない、かつスピードが求められるコーポレート業務の負担を軽減するサービスを提供しています。機能の有無だけではなくUI/UXにこだわって開発しているのが特徴で、一言で表すと「多岐にわたる法人支出管理を包括的に管理するサービス」です。
具体的には、社内の稟議や支払申請、経費精算を管理する「バクラク申請・経費精算」をハブとし、「バクラク請求書受取」「バクラク電子帳保存」「バクラク請求書発行」「バクラクビジネスカード」といったサービスを提供しています。本日は法人向けのクレジットカードサービスである「バクラクビジネスカード」の開発チームにおける、開発生産性向上の取り組みについてご紹介します。
バクラクが考える「プロダクトエンジニア像」とは
高江：次に開発組織と文化についてご紹介します。バクラクの開発組織は、プロダクトごとにストリームアラインドチームが作られています。横断的な組織としてQAやデザイン、機械学習、データ分析のチームもあります。
高江：上図を見るとそれぞれが完全に独立しているように見えますが、実際には横断的な組織に属しているメンバーが、各プロダクトチームを行ったり来たりしています。例えば、QAの観点では、全プロダクトで統一されたテスト環境を作るのは横断的な組織で、テストケースの作成などプロダクトに依存する部分は、各プロダクトチームの中で考えるというスタイルです。
次に、LayerXがプロダクト開発で大切にしていることが言語化されている登壇資料とブログ記事をご紹介させてください。
一つ目がバクラクの事業部CPOが作った社内資料『開発速度が速い ＃とは』です。内容と要点をかいつまんでお話しすると「開発速度が速い＝機能を作ることが早いのではなく、価値提供が速いこと」だと書かれています。
重要なポイントが三点あり、一つは「使われないものを作らない」ということ。作った瞬間から負債になるという前提で、作るなら“作るに値するもの”を作ることが大切です。
もう一つは「仕様をシンプルにする」。複雑な仕様のものはユーザー側も使うのが難しいため、できる限りシンプルな仕様にすることを心がけています。
最後は「言われた通りに作らない」です。実際にあった事例をご紹介すると、お客様から「申請の画面にあるリストの一覧を古い順にソートできるようにして欲しい」と要望をいただいたことがありました。そこでお客様にヒアリングしてみたところ「申請から日が経っているのに未承認のままの案件の承認を催促をしたい」という要望が見えてきました。そのため、そのチームではソート機能ではなく承認者への催促機能を開発することにしました。このように、言われた通りに作るのではなく、顧客ニーズを深く捉えていくことが重要だと考えています。
続けてご紹介するのが、アセンド株式会社CTOの丹羽健さんが書かれたブログ記事「プロダクトエンジニアとは何者か」です。こちらの内容をサマライズすると、プロダクトエンジニアは、顧客を理解し解像度を上げて優れた体験を創出する存在だとされています。そのためには、顧客の課題解決を自分ごととして捉えて、オーナーシップを持ち、プロダクト価値を最大化することが重要だと。技術だけでなく、デザインやビジネスドメインの領域にも越境する姿勢が求められると書かれています。ブログではこれらの詳細が書かれているので、ぜひご一読ください。
ここまでの話をまとめると、バクラクが考えるプロダクトエンジニア像は下記の通りです。
- 顧客の業務ドメインに深く入り込み、業務フローや課題に対する解像度を高く持ち、圧倒的に使いやすいプロダクトを提供する
- BizとDevの垣根を作らず、一丸となって最高の顧客体験を考え抜く
- 一人ひとりが機能単位で一気通貫で開発し、お互いに背中を預け合う
アウトカムをベースにした三つの指標
高江：ここからは開発生産性の評価についてお話しします。そもそも、何のために開発生産性を評価するのか。その答えは「顧客に価値を継続的に提供できているのかを確認する」「チームとプロダクトの状態を把握し、何が生産性のボトルネックになっているかを突き止めるきっかけを与える」の二点だと考えています。
LayerXでは、生産性評価の方針を下図の通りに定めています。
高江：まず、アウトプット（機能の開発）ではなくアウトカム（顧客への価値提供）をベースに評価しています。評価の対象となるのは、個人ではなくチーム全体の開発生産性です。残りの評価精度と評価コストについては、どこまでも突き詰めていくことができるため、あえて割り切って考えるようにしています。
ちなみに、ここからお話しする内容は、昨年「ストーリーポイントではなくアウトカムで開発速度を測る」というブログ記事で書かせていただいた内容と一部重複しています。もしブログ記事をご覧になってくださっている方がいらっしゃる場合は、その旨ご承知おきください。
本題に戻ります。アウトカムをどのように評価するのかについては、「提供できた価値の量」「提供までにかかった時間」「提供した機能の利用率」の三点を指標としています。なお、全てのプロダクト開発がアウトカムにつながるとは考えていません。
例えば、バクラクビジネスカードは、ご利用いただく前に入会審査があり、ミスの発生を防ぐために社内審査のオペレーションを堅実にするための開発が求められます。そういった事業の継続や業務の都合で必要となる開発は、アウトカムに直接つながるものではありません。リファクタリングやリアーキテクティング、テストカバレッジの向上もアウトカムにつながるものではないと考えています。アウトカムにつながらないものの取り扱いについては、後半でお話しします。
高江：新機能開発・機能改善の流れとしては、セールスやカスタマーサクセス（CS）のメンバーが企業から寄せられた要望を「要望企業名、重要度、要望内容、背景」のように整理してSlackに投稿します。その情報を要望DBに蓄積していって、要望棚卸会にて開発するかどうかを判断します。開発するものはBacklog化して、スプリントランニングでスプリント中に開発するものを決めていきます。ここでのポイントはBacklogと要望DBがつながっているということです。それにより、アウトカムスコアが計測できるようになっています。
高江：アウトカムスコアは、上図のような計算式で導き出しています。要望企業数はその機能を求めている企業の数で、開発コストは開発にかかる日数・時間を目安として独自に定義しています。もう一つ特徴的なのが、業務インパクトです。ここでは、機能が必要とされる頻度や事故誘発の可能性など、機能が顧客に与えるインパクトを定義しています。
高江：これは各スプリントで達成したBacklogの実例です。スプリントごとに、合計してどれほど価値提供できたのかをスコアで表しています。これらのスコアは、各スプリントの振り返りで活用しており、スコアが下がった場合に何が原因なのかを考えるきっかけにもつながっています。
なお、スコア0については、先ほどお話しした直接アウトカムにはつながらないタスクですね。スコアにつながらないからといって、全く取り組まないわけではなく、スプリントの中でしっかりと対応しています。
高江：こちらは機能の利用率を可視化したものです。利用率の取得にはさまざまな方法があると思いますが、弊社ではDBのデータをもとに導き出しています。例えば、バクラクビジネスカードは一つひとつのカードに「インフラ用」「マーケティング用」など、用途をタグ付けできる機能があります。そのタグを一つでも使ったことがあるかどうかで利用率を見ることができるため、基本的にはDBのデータを活用しているというわけです。これにより、どの機能がよく使われていて、逆にどの機能があまり使われていないかというのも見えるようになりました。
上図を見る限り、一番右の機能は全く使われていないように見えますが、これはリリースしたばかりの機能だったため、機能自体があまり認知されていない状態でした。このようなこともあり得るため、通常はリリースしたあと一定の期間をおいて利用率を確認するようにしています。
開発生産性向上に向けた独自の取り組み
スプリントイベントに組み込んだ取り組み
高江：ここからは開発生産性を向上させる取り組みについてお話しします。
高江：こちらは弊社の各ストリームアラインドチームにおける1スプリントの中での一般的なスクラムイベント、スプリントイベントを図にしたものです。ざっくりと大きく分けて「顧客を理解する」「体験の作り込み」といった二つのフェーズがあります。スプリントプランニングやスプリントの振り返り、Backlogリファインメントといったところについては割愛しています。
スプリントイベントのなかで注力しているのが「要望棚卸会」「レビュー会」「ET会」です。
要望棚卸会は、各スプリントの一番最初に行うもので、前回のスプリントで期間中にいただいた顧客要望を理解することが目的です。Backlogに載せるかどうかの判断も、要望棚卸会で行っています。要望棚卸会には開発メンバーだけでなく、商談に出ているBizメンバーも含めてプロダクトに関わっている全員が参加できます。要望の背景がわからない場合はBizメンバーに質問するなどして、チーム全体で顧客要望への理解を深めています。要望棚卸会を通して、開発メンバーは顧客の声を聞くことができますし、Bizメンバーは顧客ヒアリングの精度向上につながっています。
レビュー会はBizメンバーも含めてバクラク事業部全員が参加しています。全員でその週に作られた機能をデモで確認するといった形です。そうすることで全体に対して機能を周知することができますし、参加者からのフィードバックをもとに、お客様に届ける前に改善のプロセスを取り入れることができます。またチームを超えたメンバー同士のコミュニケーションが促進されるという副次的な効果もあります。
ET会は、いわゆる“探索的テスト”ですね。リリース前テストよりも前の段階で、エンジニアとQAメンバー、PdMが一緒になって、リリース前の機能をテストするようにしています。これにより、バグや不具合を検出すると同時に、セルフQAのスキル向上にもつながっています。例えば「フォームのsubmitボタンをダブルクリックしたらどうなるのか」「キーボードだけで全部の操作を完結しようとしたらどうなるか」など、他のメンバーがどのような視点でテストをしているのかを学ぶ機会として活用しています。
スプリントイベントとは別で行っている取り組み
高江：スプリントイベントとは別で行っている取り組みもあり、一つ目に紹介するのは「改善デー」です。
これは少し前にお話した、リファクタリングやテストの追加など、直接アウトカムに結びつかないものの対応を集中して行う日です。頻度としては、月に1～2回ほどの改善デーを設けています。改善デーを設けることで、開発メンバーからすると「気になるけれど後で対応できる」と思えますし、価値提供に集中できるようになります。
二つ目がコードレビューガイドラインの策定です。コードレビューに苦労されている企業は少なくないと思います。弊社もコードレビューには少し苦労していて、特に新しく入社したメンバーから「プロダクトやドメインのキャッチアップがまだできていない時はレビューが心理的負担になる」という声が挙がっていました。そこで、ルールとして強制するのではなく、困った時の拠り所となるようにコードレビューガイドラインを策定しました。
コードレビューガイドラインの目的は次の三つです。
・レビュアー／レビュイーに求められる心構えや、レビューの観点についてチーム内で認識を揃える
・コードベースの品質を高い状態で維持する
・実装された機能をコードレベルで理解している人が最低2人以上いる状態にする
コードレビューの観点としては下記のようにまとめています。
高江：コードレビューガイドラインの一部もお見せします。
高江：レビュアーとレビュイー、それぞれに期待することを書いていて、「Do’s」と「Don’ts」に分けて、心がけたい行動についても細かく記してあります。「変更の中に素晴らしいものがあれば賞賛する」「個人的な好みは押し付けない」など、当たり前のようで意識していないと意外とできていない部分についても明確に記載しています。
コードレビューガイドラインを策定する中で、一番大事なポイントだったと感じているのは「レビュアーに期待しないことの言語化」です。期待が大きすぎると、レビュアーに大きな負担がかかってしまいます。レビュアー側は、レビュイーをプロとしてリスペクトしており、仕様通り作られているかどうかやバグなどについてはお任せしています。これは前半でお話ししたバクラクが考えるプロダクトエンジニア像の「一人ひとりが機能単位で一気通貫で開発し、お互いに背中を預け合う」につながる部分ですね。
より良い方法を模索しながらアップデートを続ける
高江：これまで取り組んできたことを紹介してきましたが、ここからは現状の課題と今後についてお話しします。
高江：課題は二つあり、一つはアウトカムの指標として掲げた「提供までにかかった時間」について、まだ計測できていないことです。突き詰めて考えるといくらでも方法はあるのですが、“本当に意味のある機能の提供までにかかった時間”を計測するのが難しくて。
例えば、バクラクビジネスカードで顧客の要望を受けて新しいタイプのカードを作成する必要があったとします。その場合、利用規約などプロダクトとは別の部分も変更しなくてはいけません。そうすると、計測のスタート地点はご要望いただいたところなのか、Backlogに入ったタイミングなのか、開発に着手してからなのか……。まだ最適解を見つけられていません。
二つ目は、アウトカムスコアや機能の利用率を可視化して出せるようにしているものの、それらをベースに意思決定するまでは至っていない点も課題だと考えています。
今後の展望としては、まずは提供までにかかった時間をしっかり評価指標として捉えていくこと。次に、アウトカムスコアや機能の利用率について、より良い方法を模索しながら、生産性と評価をアップデートしていきたいと考えています。
まとめに入ります。弊社のプロダクト開発チームは、顧客への価値提供をベースに評価しています。開発生産性を向上させるためには、しっかりと顧客を理解した上で使われる機能を作ることが重要だと考えています。個人ではなく、チーム全体の生産性を向上させるために、ボトムアップで意見を出し合い改善を続けることも大切です。
ちなみに、本日ご紹介したコードレビューガイドラインは、メンバーから「ガイドラインがほしい」という声が挙がったため作成したものです。ガイドラインの内容については、意見ボックスのようなものを作って、そこに出されたメンバーの意見をまとめる形で作成しました。もし「直接は意見を出しづらいな」と感じているメンバーがいらっしゃるなら、このように非同期で進めるのも良いかもしれません。バクラクでは、今後もメンバー全員で話し合いながら改善を続けていきたいと考えています。
最後に、LayerXの現状についてもお話しさせてください。LayerXについて「すでに開発組織が出来上がっている」と思ってくださっている方もいらっしゃるのですが、まだ整っていない部分もありますし、人手も足りていません。まだまだ伸び代のある組織ですし、全方位で採用を行っています。最近はLMMやジェネレーティブAIの活用も推進しており、AI-UXというポジションでの募集もスタートしました。もしご興味を持っていただけたなら、ぜひカジュアル面談などをお申し込みいただけると嬉しいです。
本日はご清聴ありがとうございました。
