© LayerX Inc. 爆速開発文化を支えるProduct Engineerの 開発生産性向上の取り組み 株式会社LayerX 高江 信次

© LayerX Inc. 2 自己紹介 高江 信次 (Shinji Takae) 株式会社LayerX バクラク事業部 プロダクト開発部 カード開発グループ EM LayerX ● 2019年12月にLayerXにジョイン。バクラク事業の立ち上げから参画し、当初は 主にインフラの開発・運用を担当。 ● 現在はバクラクビジネスカードの開発チームマネージャーとして、インフラからアプ リ開発に軸足を移して事業開発を推進。 ● 「爆速開発」を体現する強いチームを作るために、日々奮闘しています。 経歴 ● ソニー株式会社(R&D) → ソニーコンピュータサイエンス研究所(CSL) → ソニー・グローバルエデュケーション → フリーランス → LayerX @shnjtk

目次 Agenda ● 事業紹介 ● 開発組織と開発文化 ● プロダクト開発の生産性評価 ● 開発生産性を向上させる取り組み ● 現状の課題と今後の展望 ● まとめ

事業紹介

5 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 会社紹介 バクラク事業 企業活動のインフラとなる法人支出 管理（BSM）SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン

6 © LayerX Inc. バクラク事業 ミッション 圧倒的に使いやすいプロダクトで わくわくする働き方を。 企業活動を支えるコーポレート業務は、ミスができない難しい業務。 バクラクはそんな業務の負担を少しでも軽くし、日常の業務がわくわくするような体験を届けます。 使いやすさへの圧倒的なこだわりと、深い顧客理解で業務効率化を実現。 手作業、ハンコ、紙のやり取りから脱却し、事業と組織を支える本来の仕事に向き合えるようサポートします。

7 © LayerX Inc. バクラクが対象とする業務領域 バクラクは、企業取引の前段となる「稟議の統一」と「債権・債務の一元管理」が可能。 従業員・経理のそれぞれが係る業務領域において、なめらかな業務連携により企業経営を加速させます。 取引先 債権管理 債務管理 ※ 開発予定の機能を含む 請求書処理 経費精算 振込 稟議 法⼈カード 請求書発⾏ 稟議 仕訳 ⼊⾦消込 ※ ※ ※ 仕訳 発注 請求 発注 請求 銀⾏ 会計ソフト 仕訳データ 振込データ ⼊⾦データ 従 業 員 経 理

8 © LayerX Inc. バクラクシリーズラインナップ 仕訳・支払処理効率化 法人カードの発行・管理 稟議・支払申請・経費精算 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ AIが領収書を５秒でデータ化 スマホアプリとSlack連携あり 領収書の重複申請などミス防止機能 AIが請求書を５秒でデータ化 仕訳・振込データを自動作成 稟議から会計までスムーズに連携 年会費無料で何枚でも発行可 インボイス制度・電帳法対応 すべての決済で1%以上の還元 AIが書類を5秒でデータ化 あらゆる書類の電子保管に対応 電子取引・スキャナ保存に完全対応 帳票の一括作成も個別作成も自由自在 帳票の作成・稟議・送付・保存を一本化 レイアウトや項目のカスタマイズも可能 ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・

開発組織と開発文化

10 © LayerX Inc. バクラクの開発組織 請求書発⾏ 機械学習‧データ Platform Engineering Engineering Office 申請‧経費精算 請求書受取 電⼦帳簿保存 ビジネスカード Design QA

11 © LayerX Inc. プロダクト開発で大切にしていること https://speakerdeck.com/layerx/how-fast-is-the-development-speed ✅ 顧客への価値提供（アウトカム）が速い ❌ 機能の開発（アウトプット）が速い ● 使われないものを作らない ● 仕様をシンプルにする ● 言われた通り作らない 開発速度が速い 重要なこと

12 © LayerX Inc. プロダクトエンジニアという潮流 ● 顧客理解の解像度を高く持ち、それ を源泉として優れた体験を創出する ● 顧客課題の解決に対するオーナー シップを持ち、プロダクト価値を最 大化する ● 技術だけでなくデザインやビジネス ドメインの領域にも越境する https://note.com/niwa_takeru/n/n0ae4acf2964d プロダクトエンジニアとは

13 © LayerX Inc. バクラクのプロダクトエンジニア像 ● 顧客の業務ドメインに深く入り込み、業務フローや課題に対する解像度を高く 持ち、圧倒的に使いやすいプロダクトを提供する ● BizとDevの垣根を作らず、一丸となって最高の顧客体験を考え抜く ● 一人ひとりが機能単位で一気通貫で開発し、お互いに背中を預け合う

プロダクト開発の生産性評価

15 © LayerX Inc. 何のために開発生産性を評価するのか ● 顧客に価値を継続的に提供できているかを確認する ● チームとプロダクトの状態を把握し、何が生産性のボトルネックになっている かを突き止めるきっかけを与える

16 © LayerX Inc. プロダクト開発の生産性評価方針 アウトプット（機能の開発）ではなく アウトカム（顧客への価値提供）をベースに評価する 評価軸 個人ではなくチーム全体の開発生産性を評価する 完璧さ、緻密さを求めない 評価対象 評価精度 評価コスト 評価することに過剰なコストをかけない

17 © LayerX Inc. プロダクト開発の生産性に関する先行記事 https://tech.layerx.co.jp/entry/measure-development-speed-by-outcomes-not-story-points

18 © LayerX Inc. アウトカムの評価指標 提供できた価値の量 提供した機能の利用率 提供までにかかった時間

19 © LayerX Inc. プロダクト開発における開発内容の分類 アウトカムに直接つながるもの アウトカムに直接つながらないもの ● 新機能開発 ● 機能改善 ● バグ修正 ● 事業の継続や業務の都合上必要なもの ● リファクタリングやリアーキテクティング ● テストカバレッジの向上

20 © LayerX Inc. 新機能開発・機能改善の流れ 社内メンバー 要望DB Backlog Sprint Board 要望収集チャネル ‥‥‥ ‥‥‥ ‥‥‥ ‥‥‥ 要望企業名、重要度、要望内容や 背景などをSlackに投稿 ‥‥‥ ‥‥‥ ‥‥‥ ‥‥‥ 要望棚卸会で開発するかどうかを判断 開発するものはBacklog化する 既にBacklogにある場合は追加で 紐づける スプリントプランニングでスプリント中 に開発するものを決める

21 © LayerX Inc. Backlogのアウトカムスコア定義 要望企業数 開発コスト ✖ 業務インパクト アウトカム = 開発コスト 内容 １ 半日程度 ２ １〜３日程度 ３ ５日程度 ４ １０日程度 ５ １スプリント以上かかる 見積もり困難 項目 内容 その機能を利用できる ユーザー権限の数 １ユーザー権限あたり +１５ 運用で代替もしくは 回避可能かどうか 代替や回避不可なら +２０ 可能だが大変なら ＋10 発生頻度 （機能が必要とされる頻度） 該当する操作が週に数回以上 発生するなら +10 事故誘発の可能性 その機能がないことでオペミスなどの 事故を誘発しそうなら +３０ 開発コストの定義 業務インパクトの定義

22 © LayerX Inc. アウトカムスコアの可視化 スプリントごとのアウトカムスコアを比較すること で、安定して価値提供できているかを確認できる スコア「０」はアウトカムに直接つながらないタスク

23 © LayerX Inc. 提供した機能の利用率 ● DBのデータを基に、機能ごとの利用率を可視化 ● 機能が認知されていないのか、開発時に立てた仮説とギャップがあるのかなどを 分析することで改善につなげる

開発生産性を向上させる取り組み

25 © LayerX Inc. スプリントイベント 要望棚卸会 スプリント プランニング 仕様検討 顧客ヒアリング レビュー会 ET会 QA リリース 顧客理解 体験の作り込み

26 © LayerX Inc. 顧客理解 ： 要望棚卸会 ● 開発メンバーが顧客要望を理解する ● 顧客が本当に困っていることを深掘りして、優先順位付けや仕様検討 の参考にする 目的 内容 ● 商談に出ているBizメンバーも含めて、プロダクトに関わるメンバーが 参加する ● 顧客や社内から出た要望を整理し、Backlogに載せるかどうか、いつ やるかなどを判断する ● 顧客ヒアリングが必要な場合はタスクとして設定する 効果 ● 顧客の声という一次情報に触れられるため、開発メンバーの顧客解像 度向上に役立っている ● 事前のご要望からニーズを深掘りした上で顧客ヒアリングに臨むため、 何を聞きたいかが事前に明確になっている

27 © LayerX Inc. 体験の作り込み ： レビュー会 ● 開発中の機能を社内に披露することで、開発者を讃えるとともに、 全体に対して機能を周知する 目的 内容 ● 各プロダクト開発チームから、一週間の機能アップデートをデモする ● なぜその機能が必要か、どういうニーズから生まれたかを丁寧に説明 する ● 参加者は積極的にフィードバックする 効果 ● 多くのフィードバックを得られることで、リリースする前により良い 改善につながる ● チームを超えたメンバーの認知・交流が促進される

28 © LayerX Inc. 体験の作り込み ： ET会 （Exploratory Testing：探索的テスト） ● リリース前のテストよりも前の段階で、開発チーム全員でテストを実施 することで、早期に不具合を発見し、リリース前のテスト期間の短縮や、 チームのテストスキルの向上を図る 目的 内容 ● リリースされる機能について担当者をアサインし、事前に「テストチャー ター」を記載した上で検証を実施する ● 発見した不具合について、どうやって発見したかのHowも含めてチー ムに共有する ● 挙げられた修正点・改善点をBacklogもしくはSprint Boardに積む 効果 ● 不具合を見つける以外にも、文言や操作が分かりにくい、ミスが起きそ うなど、体験を損ねている箇所の発見につながっている ● 他のメンバーはどういう観点で考え、どのように不具合を発見してい るかを学ぶことで、自身のスキル向上に活かせている 参考：やってみよう！探索的テスト 〜ハイクオリティな妄想の高速ループ〜 https://www.jasst.jp/symposium/jasst18tokyo/pdf/E2.pdf

29 © LayerX Inc. 改善デー ● 日頃から気になっているがなかなかできていない、細かな修正したい 箇所や改善したい箇所を集中して対応する ○ 「アウトカムに直接つながらないもの」に取り組む日 目的 内容 ● 事前に改善したいことをBacklogに積んでおき、改善デー当日には 自分がやりたいものをそれぞれ選んで着手する ● 1日の終わりに、各自がやったことを共有する 効果 ● 技術的負債の返済と開発者の精神衛生を保つ ● 「改善デーがある」ということが、通常のスプリント中は価値提供に 集中することに寄与している

30 © LayerX Inc. コードレビューガイドラインの策定 ● チームメンバーからの 「いつまでにレビューすればいいか分からない」 「何をレビューすればいいか分からない」 という声が上がったことがきっかけ ● レビューが遅れることにより、レビュイーがレビュアーにSlackで メンションするなど、非効率な状態が続いていた 経緯 ● レビュアーやレビュイーに求められる心構えや、どのような観点で レビューを行うかについてチーム内で認識を揃える ● コードベースの品質を高い状態で維持する ● 実装された機能について、コードレベルで理解している人が最低2人 以上いる状態にする 目的

31 © LayerX Inc. コードレビューの観点 ● 重要な箇所は正しくテストされているか ● テストしやすいコードになっているか ● エラー処理は適切か 品質 複雑さ ● 必要以上に複雑（コードをすぐに理解できない状態）になっていないか ● いきすぎた抽象化や早すぎる最適化がされていないか ● 将来必要になる「かもしれない」ことのために今は不要な実装がされていないか ● 既存の設計や実装と一貫しているか ● その言語の一般的な慣習やイディオムに沿っているか 一貫性 可読性 ● 変数や関数の命名は適切か。読んで意味が分かるか ● コメントは適切で分かりやすいか。「何を」ではなく「なぜ」を説明しているか ● エラーメッセージは分かりやすいか 知識の共有 ● レビュアーは自身が知っている情報をFYIとして記載することでメンバーに知識を 共有する

32 © LayerX Inc. コードレビューで期待すること・しないこと レビュアーに期待すること レビュイーに期待すること Do’s Do’s ● 1営業日以内を目処に行う。遅れる場合はAckを返す ● 自身よりも適切なレビュアーがいる場合はその人に依頼する ● 変更の中に素晴らしいものがあれば賞賛する ● PRは小さく、一つの目的にフォーカスする ● 1つのコメントに対して1つの修正をcommitする ● 口頭で解決したレビューをPRに記載する Don’ts Don’ts ● 個人的な好みを押し付ける ● レビューを複数回に分ける ● 完璧さを追求する ● PR上だけでコードの意味を説明し、コードに反映しない ● レビュアーのコメントをResolveしない レビュアーに期待しないこと ● バグの発見 ● 後方互換性が維持されているか ● 仕様に沿って実装されているか

現状の課題と今後の展望

34 © LayerX Inc. 現状の課題と今後の展望 ● 「提供までにかかった時間」については、まだしっくりくる評価手法が 立てられていない ● アウトカムスコアや機能の利用率などを分析・活用してチームで改善を 検討するサイクル（改善の型）をスプリントに深く組み込めていない 現状の課題 今後の展望 ● 「提供までにかかった時間」の評価手法を立て、既存の評価指標と合わ せて開発生産性を多面的に分析し、より多くの価値提供ができるよう 開発サイクルやチーム運用の改善に活用する ● より良い評価指標・評価手法を模索し、開発生産性の評価自体をアップ デートする

35 © LayerX Inc. まとめ ● プロダクト開発チームの生産性は顧客への提供価値をベースに評価する ● プロダクト開発の生産性を向上させるには顧客理解が重要 ○ 使われるものを作る ● 個人ではなくチームで生産性を向上させるために、ボトムアップで意見を 出し合い改善を続ける

36 © LayerX Inc. We’re hiring! https://jobs.layerx.co.jp/ NEW

37 © LayerX Inc. LayerX OpenDoor