みなさんこんにちは、kitakです。
2023年も一ヶ月を切りました。特に今年は１年すぎるのが早かったなぁと感じてます。
また、個人としてもとても楽しい一年を過ごすことができました！

今年は、自分が１年以上ずっとメンバーとして動いていたとあるプロジェクトについて知見・教訓などを書いていきたいと思います。

私自身ディレクター職であるため、今回はテックテックした話にはなりませんが見て頂けますと幸いです。

シームレスプロジェクトについて

このプロジェクトの中では、@cosmeに掲載する商品を登録・掲載するためのツールの改修を主に行ってきました。商品情報が網羅されていて、タイムリーにユーザーに届けることを目的としていることからシームレスプロジェクトという名称で動いてきました。

@cosmeに商品が掲載される流れとして、ブランドの方が掲載したい商品を申請し、申請された商品を登録作業者の方が精査・申請情報を確認した上でページ上に掲載される流れとなっています。

しかし、商品を掲載していく中で以下のような課題も発生しました。

・ブランド担当者が商品を一括で申請できない
・商品登録の進捗状況が伺えない
・登録作業を行う上での管理ツールが多岐に渡り、登録作業者の方が手動で登録せざるをえない状態だった
・新商品の情報掲載に時間がかかってしまった

そこで、上記の課題を改善し、より使っていただけるようなサービスを目指すことを目的に動いたのが本プロジェクトになります。

作ったもの

今回プロジェクトの中で作ったものは大きく以下の2つになります。
・掲載商品申請ツール(ブランド担当者の方が使用するツール)　※既存のツールを1から刷新
・商品登録作業ツール(商品登録作業者の方が使用するツール) ※新規ツールとして今回作成

掲載商品申請ツール

・@cosmeに商品の掲載を行うブランド担当者が使用するツールになります。
・掲載したい商品の新規申請、掲載商品の修正・廃盤申請等の商品管理が行えます。
・登録しているメーカー名、ブランド名の変更申請も行えます。
・申請した商品の進捗状況を確認することができるようになりました。　
・一括で掲載する商品の申請を行うことができるようになりました。

商品登録作業ツール

・掲載商品申請ツールで申請があったものの登録作業を行うツールになります。
・申請ごとに商品の登録・修正・廃盤、メーカー名・ブランド名の修正を行うことができます。
・商品登録作業ツールの中で掲載申請→登録も行うことができます。

学んだ知見・教訓

今回プロジェクトを動かした事で得られた知見・教訓をトピックごとにまとめました。
企画→仕様検討→開発→テスト→リリースまで1年半かかった長期プロジェクトとなりました。
長期でプロジェクトを動かす上での参考になれば幸いです。

既存仕様の把握・確認

problem:
・既存仕様の把握が曖昧だったことで仕様検討に時間を要してしまった。
・どの機能を入れるべきか、本当に適切であるべきかの判断をすることが最初難しかった。
try:
・なぜ現時点でこの仕様になっているのか、現状不足している箇所はどこか、
　改善できそうな部分はどこかなど課題を細分化してみる
・使用者が実際に使用するところをイメージしてみる

仕様書の作成

problem:
・複数人で役割分担をして作業を行っていた→他の人が作成したものと合わせて矛盾がないか、辻褄が合うものになっているかは念入りに行うべきだった。
・作成できたものから開発側とレビューを行なっていたが、都度レビュー頂く場合でも
　一度作成したものも含め通しで説明を頂かないとわからない箇所が多かった。
try:
・仕様書作成前に必要な要素は洗い出してFIXさせる。
・作成する画面・システムとの繋がりを意識する。関連する機能ごとにレビュー頂けるように
　レビューする順番は適切に決めておく。

仕様追加・更新等の管理

problem:
・作成した仕様の数が膨大なものになってしまい、以前までの差分などがわかりづらくなってしまったものがあった。
・仕様の量が膨大であったため、更新の反映に時間がかかってしまった。
・資料の履歴管理・反映箇所の管理など、開発側とのコミュニケーションが不足していた。
try:
・差分を記載する管理シートは必須。
・どこか、いつ、何を更新したかの記載は分かりやすくする。
・開発側が見落としてしまう、あるいは企画側で共有漏れなどが発生しないよう
　コミュニケーションを行った上でどこまで開発側と確認できているかを管理する項目をシートの中で用意する。

手戻りを発生しないために

problem:
・動作確認テスト・サービステストを行った際に追加要件を依頼してしまった。
→早急に対応が必要なバグの場合可能だが、仕様を大幅に変える要望を出すタイミングとしては不適切
try:
・手戻りをなくすために画面イメージから話すのではなく、必要な要素単位で洗い出し、既存画面との整合性、システム的な観点、事業部側の要望などを踏まえたものとして表示要件をFIX→その後画面イメージを作成する形の段取りにする。
・どういう判断にしたのかの記載は残す。
・仕様を設計後、上記要件を踏まえたポイントが抑えられているかチェックシートなどを用意する。

コミュニケーションコストをかけないために

problem:
・仕様や要望、課題・バグ管理などの工程においてコミュニケーションコストがかかってしまった。
・細かい確認を行っていく際、終盤のコミュニケーションで開発側に負荷がかかってしまった。
try:
・当初は事業部側でも部署ごとに開発側とのコミュニケーションを分けていた。
→要求・要望の仕様策定を行った上で事業部側まとめて仕様の展開・共有を開発側と行うことで
　確認する際もその場で行うことができ、コミュニケーションコストを大幅に短縮することができた。
・実施タイミング・順番等の温度感ははじめに伝える。
・どれくらいの期間が必要かテストがいつ実施できるかの共有・確認はかかさず行う。

良かったこと・まとめ

・規模の大きいもの、長期に渡ってかかるプロジェクト管理ならでわの大変さを体験することができた。

・仕様の検討や変更など、企画側と開発側が密に議論しあって最終的な形として起こすことができた。

・1年半と長期に渡って思い描いてきたサービスを形に起こしたことで大きな達成感を得られた。

・ブランド担当者や登録作業者をはじめ、多くの人達が抱えている課題を解決することができた。

さいごに

今回1からプロダクトをリニューアルしたため、かなり規模の大きいものになりました。
どのように動かなければならないか、何を準備しなければならないか、起こりうる問題は何かなどを考える良い経験になったと思います。

今後また大きなプロダクト・サービスを作ることにに携わる場合に今回のような教訓を活かしたいなと思います！

そして、個人的にもとてもやりがいを感じたプロジェクトであり、考えたものが形となって動いたことで大きな喜びも感じました。

技術よりの話ではありませんでしたが、最後まで読んでいただきありがとうございました。
みなさん良い年末をお過ごしください。以上、kitakでした。