爆速開発文化を支えるProduct Engineerの 開発生産性向上の取り組み

Transcript

1. © LayerX Inc. 爆速開発文化を支えるProduct Engineerの 開発生産性向上の取り組み 株式会社LayerX 高江 信次
2. © LayerX Inc. 2 自己紹介 高江 信次 (Shinji Takae) 株式会社LayerX バクラク事業部 プロダクト開発部 カード開発グループ EM LayerX • 2019年12月にLayerXにジョイン。バクラク事業の立ち上げから参画し、当初は 主にインフラの開発・運用を担当。 • 現在はバクラクビジネスカードの開発チームマネージャーとして、インフラからアプ リ開発に軸足を移して事業開発を推進。 • 「爆速開発」を体現する強いチームを作るために、日々奮闘しています。 経歴 • ソニー株式会社(R&D) → ソニーコンピュータサイエンス研究所(CSL) → ソニー・グローバルエデュケーション → フリーランス → LayerX @shnjtk
3. 目次 Agenda • 事業紹介 • 開発組織と開発文化 • プロダクト開発の生産性評価 • 開発生産性を向上させる取り組み • 現状の課題と今後の展望 • まとめ
4. 事業紹介
5. 5 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに掲げ、 法人支出管理サービス「バクラク」や企業内業務のデジタル化を支援するサービスを提供しています。 会社紹介 バクラク事業 企業活動のインフラとなる法人支出 管理（BSM）SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネジメ ント・証券事業を合弁会社にて展開 AI・LLM事業 文書処理を中心とした、LLMの活用による プロセスのリデザイン
6. 6 © LayerX Inc. バクラク事業 ミッション 圧倒的に使いやすいプロダクトで わくわくする働き方を。 企業活動を支えるコーポレート業務は、ミスができない難しい業務。 バクラクはそんな業務の負担を少しでも軽くし、日常の業務がわくわくするような体験を届けます。 使いやすさへの圧倒的なこだわりと、深い顧客理解で業務効率化を実現。 手作業、ハンコ、紙のやり取りから脱却し、事業と組織を支える本来の仕事に向き合えるようサポートします。
7. 7 © LayerX Inc. バクラクが対象とする業務領域 バクラクは、企業取引の前段となる「稟議の統一」と「債権・債務の一元管理」が可能。 従業員・経理のそれぞれが係る業務領域において、なめらかな業務連携により企業経営を加速させます。 取引先 債権管理 債務管理 ※ 開発予定の機能を含む 請求書処理 経費精算 振込 稟議 法⼈カード 請求書発⾏ 稟議 仕訳 ⼊⾦消込 ※ ※ ※ 仕訳 発注 請求 発注 請求 銀⾏ 会計ソフト 仕訳データ 振込データ ⼊⾦データ 従 業 員 経 理
8. 8 © LayerX Inc. バクラクシリーズラインナップ 仕訳・支払処理効率化 法人カードの発行・管理 稟議・支払申請・経費精算 帳票保存・ストレージ 帳票発行 * 経費精算のSlack連携は申請内容の通知のみ AIが領収書を５秒でデータ化 スマホアプリとSlack連携あり 領収書の重複申請などミス防止機能 AIが請求書を５秒でデータ化 仕訳・振込データを自動作成 稟議から会計までスムーズに連携 年会費無料で何枚でも発行可 インボイス制度・電帳法対応 すべての決済で1%以上の還元 AIが書類を5秒でデータ化 あらゆる書類の電子保管に対応 電子取引・スキャナ保存に完全対応 帳票の一括作成も個別作成も自由自在 帳票の作成・稟議・送付・保存を一本化 レイアウトや項目のカスタマイズも可能 ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・
9. 開発組織と開発文化
10. 10 © LayerX Inc. バクラクの開発組織 請求書発⾏ 機械学習‧データ Platform Engineering Engineering Office 申請‧経費精算 請求書受取 電⼦帳簿保存 ビジネスカード Design QA
11. 11 © LayerX Inc. プロダクト開発で大切にしていること https://speakerdeck.com/layerx/how-fast-is-the-development-speed ✅ 顧客への価値提供（アウトカム）が速い ❌ 機能の開発（アウトプット）が速い • 使われないものを作らない • 仕様をシンプルにする • 言われた通り作らない 開発速度が速い 重要なこと
12. 12 © LayerX Inc. プロダクトエンジニアという潮流 • 顧客理解の解像度を高く持ち、それ を源泉として優れた体験を創出する • 顧客課題の解決に対するオーナー シップを持ち、プロダクト価値を最 大化する • 技術だけでなくデザインやビジネス ドメインの領域にも越境する https://note.com/niwa_takeru/n/n0ae4acf2964d プロダクトエンジニアとは
13. 13 © LayerX Inc. バクラクのプロダクトエンジニア像 • 顧客の業務ドメインに深く入り込み、業務フローや課題に対する解像度を高く 持ち、圧倒的に使いやすいプロダクトを提供する • BizとDevの垣根を作らず、一丸となって最高の顧客体験を考え抜く • 一人ひとりが機能単位で一気通貫で開発し、お互いに背中を預け合う
14. プロダクト開発の生産性評価
15. 15 © LayerX Inc. 何のために開発生産性を評価するのか • 顧客に価値を継続的に提供できているかを確認する • チームとプロダクトの状態を把握し、何が生産性のボトルネックになっている かを突き止めるきっかけを与える
16. 16 © LayerX Inc. プロダクト開発の生産性評価方針 アウトプット（機能の開発）ではなく アウトカム（顧客への価値提供）をベースに評価する 評価軸 個人ではなくチーム全体の開発生産性を評価する 完璧さ、緻密さを求めない 評価対象 評価精度 評価コスト 評価することに過剰なコストをかけない
17. 17 © LayerX Inc. プロダクト開発の生産性に関する先行記事 https://tech.layerx.co.jp/entry/measure-development-speed-by-outcomes-not-story-points
18. 18 © LayerX Inc. アウトカムの評価指標 提供できた価値の量 提供した機能の利用率 提供までにかかった時間
19. 19 © LayerX Inc. プロダクト開発における開発内容の分類 アウトカムに直接つながるもの アウトカムに直接つながらないもの • 新機能開発 • 機能改善 • バグ修正 • 事業の継続や業務の都合上必要なもの • リファクタリングやリアーキテクティング • テストカバレッジの向上
20. 20 © LayerX Inc. 新機能開発・機能改善の流れ 社内メンバー 要望DB Backlog Sprint Board 要望収集チャネル ‥‥‥ ‥‥‥ ‥‥‥ ‥‥‥ 要望企業名、重要度、要望内容や 背景などをSlackに投稿 ‥‥‥ ‥‥‥ ‥‥‥ ‥‥‥ 要望棚卸会で開発するかどうかを判断 開発するものはBacklog化する 既にBacklogにある場合は追加で 紐づける スプリントプランニングでスプリント中 に開発するものを決める
21. 21 © LayerX Inc. Backlogのアウトカムスコア定義 要望企業数 開発コスト ✖ 業務インパクト アウトカム = 開発コスト 内容 １ 半日程度 ２ １〜３日程度 ３ ５日程度 ４ １０日程度 ５ １スプリント以上かかる 見積もり困難 項目 内容 その機能を利用できる ユーザー権限の数 １ユーザー権限あたり +１５ 運用で代替もしくは 回避可能かどうか 代替や回避不可なら +２０ 可能だが大変なら ＋10 発生頻度 （機能が必要とされる頻度） 該当する操作が週に数回以上 発生するなら +10 事故誘発の可能性 その機能がないことでオペミスなどの 事故を誘発しそうなら +３０ 開発コストの定義 業務インパクトの定義
22. 22 © LayerX Inc. アウトカムスコアの可視化 スプリントごとのアウトカムスコアを比較すること で、安定して価値提供できているかを確認できる スコア「０」はアウトカムに直接つながらないタスク
23. 23 © LayerX Inc. 提供した機能の利用率 • DBのデータを基に、機能ごとの利用率を可視化 • 機能が認知されていないのか、開発時に立てた仮説とギャップがあるのかなどを 分析することで改善につなげる
24. 開発生産性を向上させる取り組み
25. 25 © LayerX Inc. スプリントイベント 要望棚卸会 スプリント プランニング 仕様検討 顧客ヒアリング レビュー会 ET会 QA リリース 顧客理解 体験の作り込み
26. 26 © LayerX Inc. 顧客理解 ： 要望棚卸会 • 開発メンバーが顧客要望を理解する • 顧客が本当に困っていることを深掘りして、優先順位付けや仕様検討 の参考にする 目的 内容 • 商談に出ているBizメンバーも含めて、プロダクトに関わるメンバーが 参加する • 顧客や社内から出た要望を整理し、Backlogに載せるかどうか、いつ やるかなどを判断する • 顧客ヒアリングが必要な場合はタスクとして設定する 効果 • 顧客の声という一次情報に触れられるため、開発メンバーの顧客解像 度向上に役立っている • 事前のご要望からニーズを深掘りした上で顧客ヒアリングに臨むため、 何を聞きたいかが事前に明確になっている
27. 27 © LayerX Inc. 体験の作り込み ： レビュー会 • 開発中の機能を社内に披露することで、開発者を讃えるとともに、 全体に対して機能を周知する 目的 内容 • 各プロダクト開発チームから、一週間の機能アップデートをデモする • なぜその機能が必要か、どういうニーズから生まれたかを丁寧に説明 する • 参加者は積極的にフィードバックする 効果 • 多くのフィードバックを得られることで、リリースする前により良い 改善につながる • チームを超えたメンバーの認知・交流が促進される
28. 28 © LayerX Inc. 体験の作り込み ： ET会 （Exploratory Testing：探索的テスト） • リリース前のテストよりも前の段階で、開発チーム全員でテストを実施 することで、早期に不具合を発見し、リリース前のテスト期間の短縮や、 チームのテストスキルの向上を図る 目的 内容 • リリースされる機能について担当者をアサインし、事前に「テストチャー ター」を記載した上で検証を実施する • 発見した不具合について、どうやって発見したかのHowも含めてチー ムに共有する • 挙げられた修正点・改善点をBacklogもしくはSprint Boardに積む 効果 • 不具合を見つける以外にも、文言や操作が分かりにくい、ミスが起きそ うなど、体験を損ねている箇所の発見につながっている • 他のメンバーはどういう観点で考え、どのように不具合を発見してい るかを学ぶことで、自身のスキル向上に活かせている 参考：やってみよう！探索的テスト 〜ハイクオリティな妄想の高速ループ〜 https://www.jasst.jp/symposium/jasst18tokyo/pdf/E2.pdf
29. 29 © LayerX Inc. 改善デー • 日頃から気になっているがなかなかできていない、細かな修正したい 箇所や改善したい箇所を集中して対応する ◦ 「アウトカムに直接つながらないもの」に取り組む日 目的 内容 • 事前に改善したいことをBacklogに積んでおき、改善デー当日には 自分がやりたいものをそれぞれ選んで着手する • 1日の終わりに、各自がやったことを共有する 効果 • 技術的負債の返済と開発者の精神衛生を保つ • 「改善デーがある」ということが、通常のスプリント中は価値提供に 集中することに寄与している
30. 30 © LayerX Inc. コードレビューガイドラインの策定 • チームメンバーからの 「いつまでにレビューすればいいか分からない」 「何をレビューすればいいか分からない」 という声が上がったことがきっかけ • レビューが遅れることにより、レビュイーがレビュアーにSlackで メンションするなど、非効率な状態が続いていた 経緯 • レビュアーやレビュイーに求められる心構えや、どのような観点で レビューを行うかについてチーム内で認識を揃える • コードベースの品質を高い状態で維持する • 実装された機能について、コードレベルで理解している人が最低2人 以上いる状態にする 目的
31. 31 © LayerX Inc. コードレビューの観点 • 重要な箇所は正しくテストされているか • テストしやすいコードになっているか • エラー処理は適切か 品質 複雑さ • 必要以上に複雑（コードをすぐに理解できない状態）になっていないか • いきすぎた抽象化や早すぎる最適化がされていないか • 将来必要になる「かもしれない」ことのために今は不要な実装がされていないか • 既存の設計や実装と一貫しているか • その言語の一般的な慣習やイディオムに沿っているか 一貫性 可読性 • 変数や関数の命名は適切か。読んで意味が分かるか • コメントは適切で分かりやすいか。「何を」ではなく「なぜ」を説明しているか • エラーメッセージは分かりやすいか 知識の共有 • レビュアーは自身が知っている情報をFYIとして記載することでメンバーに知識を 共有する
32. 32 © LayerX Inc. コードレビューで期待すること・しないこと レビュアーに期待すること レビュイーに期待すること Do’s Do’s • 1営業日以内を目処に行う。遅れる場合はAckを返す • 自身よりも適切なレビュアーがいる場合はその人に依頼する • 変更の中に素晴らしいものがあれば賞賛する • PRは小さく、一つの目的にフォーカスする • 1つのコメントに対して1つの修正をcommitする • 口頭で解決したレビューをPRに記載する Don’ts Don’ts • 個人的な好みを押し付ける • レビューを複数回に分ける • 完璧さを追求する • PR上だけでコードの意味を説明し、コードに反映しない • レビュアーのコメントをResolveしない レビュアーに期待しないこと • バグの発見 • 後方互換性が維持されているか • 仕様に沿って実装されているか
33. 現状の課題と今後の展望
34. 34 © LayerX Inc. 現状の課題と今後の展望 • 「提供までにかかった時間」については、まだしっくりくる評価手法が 立てられていない • アウトカムスコアや機能の利用率などを分析・活用してチームで改善を 検討するサイクル（改善の型）をスプリントに深く組み込めていない 現状の課題 今後の展望 • 「提供までにかかった時間」の評価手法を立て、既存の評価指標と合わ せて開発生産性を多面的に分析し、より多くの価値提供ができるよう 開発サイクルやチーム運用の改善に活用する • より良い評価指標・評価手法を模索し、開発生産性の評価自体をアップ デートする
35. 35 © LayerX Inc. まとめ • プロダクト開発チームの生産性は顧客への提供価値をベースに評価する • プロダクト開発の生産性を向上させるには顧客理解が重要 ◦ 使われるものを作る • 個人ではなくチームで生産性を向上させるために、ボトムアップで意見を 出し合い改善を続ける
36. 36 © LayerX Inc. We’re hiring! https://jobs.layerx.co.jp/ NEW
37. 37 © LayerX Inc. LayerX OpenDoor