Slide 1

Slide 1 text

ゼロからはじめるスクラム開発

Slide 2

Slide 2 text

自己紹介 樋口 翔哉(ひぐち しょうや) ● Edtechの事業会社で2年ほど企画を担当 ● Webエンジニア4年ほど ● 受託開発会社を個人で立ち上げ ● X Mile株式会社でプロダクトオーナーを担当

Slide 3

Slide 3 text

テクノロジーの力で ノンデスクワーカーが主役の世界を。 日本の人口減少トレンドの中で、 3Kと言われるブルーカラー産業では人手不足感はますます加速しています。 物流、建設、製造といった業界は衣食住を支える社会生活におけるインフラであり、 決して止まることができない産業です。 にも関わらず、社会的地位は低く、光が当てられていないのが現実です。 私たちは事業構築力とテクノロジーを駆使して、 ノンデスク産業の課題を解決することで、 従事者及び消費者の生活の質を向上し、社会に貢献し続けます。 © X Mile All Rights Reserved. Vision X Mileの解決する社会課題

Slide 4

Slide 4 text

人口減少社会におけるインフラ産業の人手不足に対して、 X Mileのプラットフォーム群が包括的に顧客課題を解決します。 経営管理 売上拡大 情報サイト 求人広告 採用管理 人材紹介 ノンデスクSaaS・PF事業 HRプラットフォーム事業 SaaS Platfom Media Recruit ノンデスク産業特化の経営支援デジタルプラットフォーム © X Mile All Rights Reserved. Service 事業内容 ノンデスク向け業務効率化SaaS 受発注プラットフォーム メディア 求人メディア・採用管理SaaS ノンデスクワーカー転職支援 M&A M&A仲介プラットフォーム

Slide 5

Slide 5 text

運輸事業者向け バーティカルSaaS・PF 運輸業界では社会問題化する日本最大の ドライバー不足と同時に「多重化下請け構造」や 電話・紙・FAX を中心とした「低い労働生産性」など 多くの解決すべき業界課題が存在しています。 当社はそれらをソフトウェアによって解決し、 事業者様の売上最大化・コスト改善を図ることで、 インフラ産業である運輸業界を支えます。 © X Mile All Rights Reserved. Product プロダクト紹介

Slide 6

Slide 6 text

今日のお題 スクラム体制を導入して、専任のPO(プロダクトオーナー)を置いた背景とそ の結果

Slide 7

Slide 7 text

人を増やしても開発生産性が上がらない ● 仕様理解不足でレビュー遅延 ○ → リリースまで時間が長い ● 事前の設計が足りず、PRのコード差分が膨大に ○ → 不十分なレビューで技術的負債が蓄積 課題感

Slide 8

Slide 8 text

スクラムを導入へ スクラムを導入し、仕様と技術の責務を分割 ● POが仕様責任を持ち、開発前に仕様を確定 ● エンジニアは設計・実装に専念 ● 必須のドメイン知識は事前共有 ○ → 不明点がない状態で開発開始

Slide 9

Slide 9 text

スクラム導入の成果 ● 1日あたりのPR数が大幅に増加 ● レビューの待機時間が大幅に削減

Slide 10

Slide 10 text

プロダクトオーナーとしての振る舞い POの役割 ● 仕様設計とステークホルダー合意 ● 品質担保(仕様通りのレビュー) 開発者の役割 ● ❌ 仕様書通りに実装 ● ⭕ 必要な知識を共有し、提案可能な状態に

Slide 11

Slide 11 text

自己紹介 兒玉 尚貴(こだま なおき) ● 医療系SaaS企業でフィールドセールスを3年担 当 ● 同企業でバックエンド・フロントエンドのエンジニ アリングを3年担当 ● X Mile株式会社でロジポケのWebとMobileチームの プロダクトオーナーを担当

Slide 12

Slide 12 text

Mobileチームの状況と体制 項目 〜2024年7月 2024年7月〜 技術スタック React Native (クロスプラット フォーム) Kotlin (Android) / Swift (iOS) エンジニア数(非フルタイム) 1名 3名 開発アプローチ 共通コードベース プラットフォーム別ネイティブ開発 2025年1月のアプリリニューアルへ向けて、技術スタック・エンジニア数・開発アプ ローチを変更し絶賛開発中!

Slide 13

Slide 13 text

アプリリニューアル中の開発プロセス スクラムは未導入、エンジニアの自走力に依存している ● 週1でPOとエンジニア間で進捗と計画をすり合わせ ● ReactNativeのアプリとFigmaが仕様書の代わり ● 機能単位でQAテスト ● 継続的な不具合対応

Slide 14

Slide 14 text

課題感 ● チームメンバーで仕様の認識が揃っていない(分からない) ○ 仕様のドキュメント不足、ジョイン間もないメンバーが多い ● 不具合が多数見つかる ● 不具合修正に追われ機能開発が進まない ● チーム課題が改善されない

Slide 15

Slide 15 text

アプリリニューアル後のスクラム導入にあたっての懸念 非フルタイムのエンジニア中心であるため、以下のことが挙げられる 1. スプリントイベントの負担 ○ デイリースタンドアップ ○ スプリントプランニング ○ スプリント振り返り ○ デモデイ ○ etc… 2. 小規模チームでのリソース制約

Slide 16

Slide 16 text

これから導入するスクラムの内約 1. スプリントイベントの軽量化 ○ デイリースタンドアップ(テキストベース) ○ スプリントプランニング ■ POが事前に仕様をドキュメント化 ■ チーム合意を取った上で開発着手 ○ スプリント振り返り 2. POがスクラムマスターを兼務

Slide 17

Slide 17 text

まとめ チームの規模やメンバーの稼働状況に応じてスクラムをそのまま適 用するのではなく、柔軟にアプローチを調整し、最適な運用方法を模 索することが重要である。

Slide 18

Slide 18 text

We are hiring テクノロジーでノンデスクワーカーが輝く世界を! 物流・建設・製造業界の課題を解決し、社会を支える産業 をより良くする仲間を募集中!