ウェビナー登壇から改めて振り返る助太刀のプロダクト開発サイクル
テックイベントに登壇してきました
株式会社助太刀でVPoEをやってる月澤です。助太刀でVPoEとして開発部を見るようになってもう2年近く経ってしまいました。
去る2022年6月28日（火）に「レガシー現場をテクノロジーで切り拓く〜保育・教育・建設・製造・医療現場で活躍する管理画面づくりとは〜」というテーマで株式会社Globeeさん主催のイベントに登壇させていただきました。イベントとしては参加企業各社がレガシー業界に対してどのようにプロダクトを出してきたかなどを各々のテーマで発表するもので、各社のそれぞれ工夫した点などが聞けて僕自身も勉強になったし、非常に盛り上がるイベントとなりました。
助太刀としては、建設業界に対するアプローチの仕方というよりは、開発部が普段どのように課題に向き合い、どのように開発サイクルを回しているか、という点について話したいなーと思った（僕も他社のそういうお話し聞きたいです）ので、今まで自分がやってきたことをまとめるという意味でもプロダクトの開発フローについて話してきました。
今回は発表から少し経ち、改めて自分の備忘録としても助太刀のプロダクト開発の流れをまとめておきたいなと思ったので以下はそのまとめになります。
助太刀のテーマについて
IT化が必ずしも課題を解決するものではないと思いますが、それでもレガシー産業と呼ばれる業界にはIT化することで効率化できたり、今までにないアプローチができるようになるということはあったりします。助太刀は建設業界で特に大きな問題である「人手不足」、もっと言えば「建設業界における適切な人材配置の難しさ」というテーマに向き合っており、助太刀アプリがあることで今までになかった新たなアプローチで職人さんと工事会社さんが繋がり、実際に工事が進むようになってきています。
今回のイベントでは先に挙げたように、今やっている助太刀のプロダクト開発フローについてお話ししようということにしました。
このテーマにした理由は、僕がVPoEとして開発組織を作るという意味合いが強い立場にいるということ、今の助太刀が CTOではなくVPoEを開発のTOPとして置き組織作りに注力していること、そして入社して感じたプロダクト開発フローの不安定さを解消するために、プロダクトの意思決定や開発サイクルを僕自身明確な意思を持って変えてきたということがあったからです。
プロダクト開発における課題
まず助太刀のプロダクトは個人の職人さんと工事会社のマッチングを始め、工事会社同士のマッチングや正社員求人の求人媒体などのサービスを展開しています。
僕が入社した2020年末頃はまだオフショア開発チーム（ベトナム / ダナン）が助太刀アプリ開発のメインであり、バックエンド側の開発を社内に移行している最中という感じでした。開発チームに入って状況を見てみると
開発要望の吸い上げ
→ 定性的な部分はCSの顧客対応時のフィードバックのみ
→ 定量的な部分ではユーザーのアクションをログとして持っていないので、分析できない開発優先度の決め方
→ プロダクトロードマップが決まっていない
→ 事業部からの要望をbacklogに積んで上からやっていく開発の進め方
→ Sprint単位で開発はされていた
→ 適切な振り返りの設定や優先度の調整などはできていない
というような状況でした。
それまでは建設業の知見が豊富で、職人さんの課題を理解している代表の我妻のアイデアを中心に大型の機能開発、それ以外の社内外の改善要望をチケット化してSprint内でできるだけやるという開発スタイルだったので、プロダクトの改善は一定進んでいるが、それが正しい優先度や方向性なのか判断できる指標などが整備されていませんでした。
なので、メインの開発を社内で内製化するという開発チームの組成や仕組み作りと並行して、プロダクト開発フローも整備していく必要があると感じました。
ユーザーや業界の課題やニーズを再度しっかり収集できる仕組み作り
ユーザー行動や各チームで追いたい指標をログとして保存して集計できるデータ基盤を作る
ユーザーへのヒアリングやリアルイベントなどを組織として推進する仕組み
少し先の未来のプロダクト像を定義し、プロダクトロードマップを作成
事業計画や業界の動向、ユーザーニーズをもとに中長期的なプロダクト戦略をまとめる
経営陣やPM中心にプロダクトロードマップを作成して全社共有
事業計画とプロダクトロードマップをベースにタスクの優先度を決定
助太刀内で優先度を決める基準や会議体を設定
開発Sprint単位で優先度を決めて開発していく
という流れで進めることにしました。
現在プロダクトをどんな手順で開発しているか
ここでは発表してきた開発体制や組織、開発サイクルのお話をメインで書きます。
プロダクトに関わる組織構成
助太刀では様々なチームから要望やアイデアを吸い上げプロダクトに生かしていますが、メインとして関わっているチームとしては
開発チーム（エンジニアのチーム）
デザインチーム（デザイナーのチーム）
QAチーム（QAエンジニアのチーム）
プロダクトチーム（PMMのチーム）
上記４つのチームになります。組織図的には開発チーム、デザインチーム、QAチームが開発グループ、プロダクトチームはいわゆるPM（PMM）のチームなのでCOO直下の事業グループに属しています。
ビジネス要件は事業グループ側中心、技術要件やUI/UXなどは開発グループ中心に進め、プロダクト定例という場を設けてそこで認識合わせをしています。その間に企画で迷っているところや、開発側として決めてほしいビジネス要件が出てきたりした場合は都度プロダクトチームと開発グループで話し合って色々決めたりしてます。
ニーズの把握
ユーザーの要望やニーズをどれだけ正確に掴めているか、についてはどの会社やプロダクトでも最も重要な事項の１つだとは思いますが、我々開発グループ含めプロダクト側に建設業出身者があまりいないので、ドメイン知識を補完するためには社内の経験者へのヒアリングやユーザーに直接ヒアリングして知見を貯めていく必要があります。
現在の助太刀では
ユーザーインタビュー
ユーザー交流会
電話でのユーザーヒアリング
上記を主に行なっており、その他国土交通省の担当者や大手ゼネコンとの建設業に関する勉強会を定期的に実施するなど、常に業界の把握に努めています。
定性データではなく定量データに関してはKARTE Data Hubを使ったデータ基盤に全てのログを貯めて分析できるようにしており、主にプロダクトチームがデータ分析を行なっています。現在では全てのユーザーのすべての行動をログとして取得できるように常に開発を続けています。
プロダクト開発要望の整理
各チームからの要望やユーザーからの声を各チームで取りまとめた上でプロダクトチームに共有してもらい、それら全ての要望はNotion上に集約されます。各チケットはカテゴリやどのサービスを対象にした要望か、現状どのステータスかなど様々なタグをつけて管理され、優先順位つけ+開発見積もりが完了するとSprintという括りに入ることになります。
PRDの作成
上記でnotion上に整理された各開発要望は、その１つ１つがPRDとしてドキュメント化されています。PRDの内容としては基本的なセオリー通り
概要
背景と課題
機能要求
主要な指標やKPI
期待される効果
UI/UX
詳細設計
テストケース
リリース手順
リリース後タスク
などを書くようにしており、プロダクトチーム、開発チーム、デザインチームがそれぞれのパートを埋めて皆で認識合わせをするというやり方をとっています。
優先順位付け
優先度はプロダクトチームが中心に考えつつ、最終的には代表、COO、VPoE（僕）が参加している隔週のプロダクト定例で大きな順位付けを決定させています。細かい施策やバグ修正など細かいものはプロダクトGの企画定例で決めたり、その場で開発部と会話してSprint内に入れるものを調整したりと現場で決めています。
プロダクトロードマップの作成
定性/定量の両面でユーザーニーズを把握し、そこから施策に落としていきます。プロダクトチームを中心に直近1年程度のプロダクトの成長ストーリーを可視化してもらい、開発グループと一緒に具体的な施策だったり作るべき機能のワイヤーを作って議論したりしながらロードマップに載せていきます。
期初や四半期ごとに更新されている事業計画や事業方針に合ったものであるか
プロダクトの価値（＝顧客価値）を向上させるものであるか、またそのインパクトや開発工数
単一のユーザーの声を聞くのではなく、しっかり建設業の状況やその声の背景を理解した上で優先度が決められているか
などなどいろんな観点を考慮し、各チームと話し合いながら優先すべき機能や新規サービスをプロダクトロードマップに落とし込んでいきます。
Sprint単位での開発
助太刀の開発部の基本的な開発サイクルは2週間程度を1スプリントとしたアジャイル的な手法をとっており、
仕様が決定したチケット（見積もり待ちステータスのチケット）= 内容が全て埋まったPRD をSprintの最初に開発チームみんなで議論し、ストーリーポイントを振る
プロダクトチームと一緒に決めた優先度やチームのヴェロシティに基づいて、チームリーダーが対象スプリント内に入れるチケットを決定
開発チームでの開発 → QAチームによるテスト → リリース
というような流れをとっています。
Sprintの流れとしては
Sprint Plannning （Sprintの最初の月曜日）
デイリースクラム（毎朝簡単な振り返りとタスクの認識合わせ）
Sprint Refinement（基本1週目の最後の金曜日に行い、優先度の変更やタスクの調整など）
QA
リリース（アプリの場合はiOSの申請など）
Sprint Review / Sprint Retrospective（２週目最後の金曜日）
といった形で２週間のサイクルで行なっています。
開発サイクルを振り返る
僕が入社してからも色々とやり方を変えたりしながら、今のサイクルで回すようになり、それなりに整った部分もあればまだまだ改善余地のある部分もあります。今の形が完成とは思っていないですが、ざっくり感想を書くと
良かったこと
要望を定性/定量両面で考えることができるようになり、それが最終的にプロダクトロードマップの作成につなげることができた。
開発する優先度をロードマップをベースに議論できるようになり、開発部と事業部での認識合わせができるようになった。
ストーリーポイントを導入し、チームでの開発をより定量的に表現できるようになった → リモートと出社のハイブリッドなので、リモート時の成果の可視化にも一役買っている。
明確にSprint Eventを実施するようになり、開発メンバーの共通認識も上がった。
課題だと思うところ
まだまだデータ分析とか甘い。
Sprint Eventをしっかりやるということはどうしても開発にかける時間とのトレードオフになりがち。効率の良いやり方を探していく。
2週間で開発が終わらなかった or QAフェーズが長引いてしまった、などはよくあることで、ストーリーポイントの精緻化とテストの効率化（自動化やテストコードの拡充など）はやらなければいけない。
上記のようにまだまだ課題はたくさんありますが、建設業界という巨大な業界に立ち向かうべく、プロダクトに向き合う組織を全体的に見ながら改善していくつもりです。前よりはかなり良くなってきましたが、それでも課題があるってことはさらに良くすることもできるってことだと思うので。
こんな助太刀開発部ですが、もし興味のある方がいればぜひカジュアルにお話ししましょう。
この記事が気に入ったらサポートをしてみませんか？