こんにちは。不動産・住宅情報サイト「LIFULL HOME'S」で賃貸領域の企画を行っている斉藤です。
過去エンジニア職だった経験から、エンジニアリングスキルを活かしながらプロダクト改善に取り組んでいます。

今回は、ホームズ賃貸プロダクトの改修スピードと品質を高めた２つの取り組みを紹介します。

背景

賃貸プロダクトを支えるモノづくり組織の中で、社内で「サービス企画」と呼んでいる職種のメンバーが多数在籍しており、それぞれ１～数名ずつが開発・デザインメンバーとバディとなって動くチームが複数あります。

また、賃貸プロダクトは長年の改修を積み重ねてきた経緯があり、サービス規模が大きいため、以下の課題があると感じていました。

1. 施策検討に時間がかかる。（改善スピードの課題）
   過去に似たような施策を行っていないかなどの確認が必要。

2. 過去行った施策のドキュメントやソースコードの整備が劣後し、
   対応漏れが生じたり最新ではないままになる。（品質の課題）

もちろん、チーム内での工夫や、個々のケアによってカバーできている部分もありますが、そういったチームやメンバーに依存しないような仕組みづくりが必要だと考えました。

取り組み紹介

上記の課題を解決するため、以下の２つの取り組みを行っています。

①モブプラ

上記課題のNo.1「施策検討に時間がかかる（改善スピードの課題）」に対しての取り組みです。

チーム内や個人での検討では、ドメインや過去施策についてどれだけ把握しているかなどによって、施策として考えられる幅が狭まってしまう可能性があるのと、「この方向性で大丈夫だろうか」の不安を感じてしまいがちです。これらの課題を解決するため、気軽に話せる場を設けました。

元々、仕様書を作成者以外がチェックする「企画チェック」なる工程などがありますが、「モブプラ」はさらに施策検討・仕様策定フェーズのパフォーマンスを上げるためにも活用できるよう、相談したい内容の種類に制限を設けないようにしています。

なお、この「モブプラ」という言葉は、複数の開発メンバーが同じ場所にあつまり、1台のコンピュータを使い、話し合いながらソフトウェア開発を進める手法の「モブプログラミング」をもじった「モブプランニング」の意味で名付けました。

方法としましては、週に数日、固定の時間を設け、相談したい事項がある人はカレンダー予定にその内容を書き込みます。
予定時間の１時間ほど前にslack通知がなされ、議題があれば、サービス企画職メンバーが集まります。
固定の時間を設けることで、気軽に相談できるようになり、通知時にのみ集まることで、不要な集まりを防ぐこともできます。
また、案件に応じて、デザイナーやエンジニアを呼ぶこともあります。

②クロージングミーティング

上記課題のNo.2「過去行った施策のドキュメントやソースコードの整備が劣後し、対応漏れが生じたり最新ではないままになる。（品質の課題）」に対しての取り組みです。

「クロージングミーティング」はGoogleで検索すると、Wikipediaにはないものの、言葉としては存在し、以下の意味があると書かれています。
（引用元： https://web-director.net/know-how/closingmtg/ 他）

• プロジェクトが完了したことを宣言し、解散する

• 関係者全員で振り返りを行い、総括する

ホームズ賃貸領域のプロダクト開発において、これまでも、「振り返り会」または「レトロスペクティブ」という名称でプロジェクトの終了時やスプリント開発の終了時に行われてきました。

これらは、いわゆるKPTと呼ばれる振り返りの手法がメインで行われていましたが、それ以外のことにはほとんど触れてきていませんでした。

そのため、（ウォータフォール開発での）プロジェクト終了時に行っていた「振り返り会」の対象範囲を拡大した「クロージングミーティング」に発展させました。
なお、この「クロージングミーティング」は、既にプロジェクト開始時に行っていた「キックオフミーティング」とは対の立ち位置となります。

以下、具体的に行う内容の一例です。

②-1. 施策の結果（効果測定）共有
②-2. 仕様書などのドキュメントが最新状態かをチェック
②-3. プロジェクト・プロダクトの状態がわかるように
②-4. 本実装の残タスクをタスク管理ツールに残す

上記以外にも様々なチェック項目があり、それらをテンプレート化しています。
「②-3」「②-4」に関しては以下に補足説明します。

「②-3. プロジェクト・プロダクトの状態がわかるように」
は、プロジェクトページのタイトルにの頭に以下の文字を付けることで、
一目で状態がわかるようにしました。
（何も先頭についていないプロジェクトは進行中）

• 【保留】

• 【A】：オリジナルパターンに戻した場合

• 【B】：チャレンジパターンに寄せた場合
  ※ABCテストを行いCパターンが勝利した場合は【C】とします。

• 【完】：ABテストを行わない施策が完了した場合

• 【中止】

「②-4. 本実装の残タスクをタスク管理ツールに残す」
は②-3に関連する内容で、サイトの見た目上はチャレンジパターンに寄せているものの、ソースコード上はオリジナルパターンとチャレンジパターンが混在している場合があります。

その場合、どこかのタイミングでソースコードをきれいにする必要があるのですが、この工程が漏れがちになるため、残タスクとして把握できるよう、タスク管理ツール上にタスクを登録しておきます。

クロージングミーティングを実施することで、プロダクトコード・それにまつわるドキュメント類を最新に保つことができるため、後から見た人（特にプロジェクトに関わっていない人）が見て理解しづらくなることを防ぎます。

また、「②-1. 施策の結果（効果測定）共有」に関しては、
今回得られた知見を企画以外の職種メンバーにも共有することで、次の施策につなげる新たなアイディアが出ることもあります。

取り組み紹介

いかがでしたでしょうか。

一つ目に紹介しました「モブプラ」ですが、日々の対話の中で、「これ、モブプラで相談しましょう。」といった話が時折出てきます。
私の個人的見解にはなりますが、実際上流工程におけるスピードや品質が向上するだけでなく、気軽に相談できる場があることで、コミュニケーション量が増えたり心理的安全性が保たれるといった副次的効果もあるのではないでしょうか。

また、二つ目に紹介しました「クロージングミーティング」は、一見地味に見えますし、短期的に見ての効果が見えづらいです。
ただ、長期的な目線でプロダクトを育てる上で重要ではないかと、私は考えています（規模が大きいプロダクトは特に）。

お読みいただきありがとうございました。
お役立ていただけましたら幸いです。