HRMOS（ハーモス）事業部 デザイナーの五十嵐です。「HRMOS採用 新卒エディション」（新卒採用領域における採用管理クラウド）のプロダクトデザインを担当しています。
今回は、今年の2月から取り組んできた開発フローの改善の取り組みについてまとめたいと思います。
HRMOS採用 新卒エディションは、顧客である新卒採用担当者のニーズ合わせてリリース日を先に決定し、スピードを優先して開発されたものです。そのためチームでは、プロダクトオーナー（PO）と私で仕様や要件を決めて、それをエンジニアが実装する体制を取っていました。ですが結果的にワイヤー段階での手戻りが多くなったり、開発コストが膨らみ対応が見送られた機能もありました。
またリリース後も、開発スピードを保つためにその体制を続けており、役割をまたいだコラボレーションがなかなか起こりづらい開発フローになってしまっていました。
こうした状況のなか私は、「現状の開発フローが最適なのか」という疑問を持っていました。チームみんなでコラボレーションをしながらつくるやり方が私自身すごく好きですし、結果として最高のプロダクトができると信じていたのです。
そう思い、仕様を決める段階のアイデア発散にエンジニアを巻き込むなど、それまでの開発フローからの脱却を図ってきましたが、劇的な改善には至りませんでした。いっそのことフローを思い切って見直してみよう、と思い立ったのが今年の2月。POとエンジニアのリーダーに相談して、2人とも同じような課題感を持っていたので、取り組みをスタートしました。
まず最初に行ったのは、Miroを使った現状の開発フローの可視化です。可視化したものをPOとデザイナー、そしてエンジニア全員に共有し、みんなで「具体的にどこに課題があるのか」意見をふせんで貼っていき、課題を洗い出しながら現状の認識を揃えました。
具体的には、「チーム全員が同じ解像度でユーザーの課題を理解しているかわからない」「解決策が十分に発散できていない」「仕様の認識がずれていて開発に入ったときにコストがかかりすぎると判断され、リリースにいたらない」などの課題が出てきました。
現状の課題を洗い出した後は、私のほうで「こう変えたらいいんじゃないか」という開発フロー案を再度まとめました。Miro上での思考プロセスがこちらです。
こちらに対しても、現状分析のときと同じようにチームメンバーから意見をもらいました。議論を通じて、「デザイナーとエンジニアの間で、ユーザー行動から機能実装までの認識が揃わず、余計なコミュニケーションコストがかかっていたこと」に課題が集約されました。
ですので、新しい開発フローでは「何を作るのか」の全体像を把握することと、「どんなスコープで作っていくか」の認識をチームで合わせることにフォーカスしました。具体的に行ったのは、小さいコストで始められる「開発スコープを決める前にユーザーストーリーマッピングを行うこと」と「全員参加のドメインモデリングを行うこと」の2つです。
ユーザーストーリーマッピングは、ユーザーがどのような流れでプロダクトを使うのか、そこにどのような機能があるのかを図にしたものです。これによりチーム全員が高い解像度でサービス全体の共通認識を持ち、作るものの要件を理解できるようにすることが狙いです。
ドメインモデリングは、エンジニアがよく使う手法の1つで、システムに関する業務知識の情報構造化することです。今回はプロダクトや機能レベルで情報を構造化するワークを行いました。これを行うことで実装の解像度が上がるので、エンジニアと共通認識を持つことができ、手戻りなどの余計なコミュニケーションをなくせるのではないか、と考えました。
まずはチーム全員でユーザーストーリーマッピングをすることに。取り組みの目的や手順、メリットを共有したものの、ほとんどのメンバーが初めての取り組みで、十分な理解に至らず思うように共通認識をつくれませんでした。
そこで私がユーザーストーリーマッピングの解説資料を作成し、改めて取り組みの意義を共有して再度実施。解説資料では、共通ができることが目的だと伝わるよう内容にこだわりました。
その結果、サービスの全体像と最小工数で提供できる機能の認識を揃えられました。しかし、このために全メンバーに1.5日以上協力してもらいました。毎回これだけの時間をかけるのは大きなコストです。以降は私が最小機能のたたきを作ってPOに意見をもらい、それをメンバーに共有するという形をとるなどして、試行錯誤を続けています。
ドメインモデリングはエンジニアがよくやる手法なので、エンジニアに巻き込み進めることに。機能を作るうえでどういう情報が必要かをみんなで構造化するワークを行いました。
この2つを通じて、メンバー全員で共通認識をもったうえで議論、意思決定ができるようになったと思いますし、一体感を持ちながら開発できるようになりました。
ユーザーストーリーマッピングは今後も定期的に行っていくつもりですし、モデリングは機能追加のたびにやっています。ただこれらは認識を揃えるための手段に過ぎず、目的達成のためによりいい方法があれば、積極的に取り入れたいと思います。
多くの人が関わる開発フローの変更を主導することはとてもハードルが高く思われるかもしれません。私自身、言い出したものの、最初のうちは「やって失敗したらどうしよう」という考えを拭えませんでした。
そんなときにスクラムマスターの人から「成功させるつもりでやって、それで失敗してもそれは成功。まずはやってみろ」と言われ、安心したのを覚えています。「まずはやる、失敗したらそれを学びにして次また挑戦すればいい」と思い、スタートしました。
ユーザーストーリーマッピングがうまくいかなかったときは正直心が折れかけました。ただそんなときもエンジニアと1on1をして、アイデアを出してもらい、「仲間に引き入れる」ことを意識しました。「チームの問題をチーム全員で解決する」「これはチーム戦だ」と思うことで、困難なときも乗り切れました。
2月から進めてきた開発フロー改善の取り組みをいったん終え、今はだいぶスムーズにプロダクトづくりを進められるようになりました。ただ、開発フローに完成形はないと思っています。終わりなき改善と思い、今もなお試行錯誤の最中です。
形を作ってまた壊す。全員で同じ解像度で理解して、最高のプロダクトを作るために試行錯誤をやめない。今後もそれを忘れずにやっていきたいと思います。