💡

実装後の“ちょっとここ直して”問題に仕組みで向き合った話

に公開

はじめに

弊社では toB SaaS の開発をしています。

開発フローは、要件定義 → 実装 → 各種レビュー → リリース、といったオーソドックスな流れ。

PjM が要件をまとめ、デザイナーがモックを起こし、それに沿ってエンジニアが実装。並行して QA エンジニアがテスト仕様書を作り、ステージング環境で動作確認を行います。

ただ、まだまだスモールな組織のため、PjM が QA を兼務することも珍しくなく、動作レビューの場面で「やっぱこの仕様じゃなくて、こっちにしてくれない?」といった細かい要件変更が出てしまうことがよくありました。

もちろん要件の漏れは要件定義の問題ですが、実際に触ってみて初めて気づく細かい文言や要素配置の違和感は、どうしてもゼロにはできません。

「要件は変わって当たり前」という姿勢はよくないとはいえ、プロダクトをより良くするために要件変更が発生するのは避けられない部分でもあります。

エンジニアの本音

問題はその「タイミング」です。

実装者からすると「コード書き終わったあとに細かい要件変更しないでよ…」という思いが当然あります。これが常態化するとモチベーションの低下に直結します。

PjM 側からすると「ちょっと直すだけでしょ?」という感覚ですが、エンジニアからすると「後で別チケットでまとめて対応したい」という思いが強く、両者の温度感にズレが出ていました。

解決策:「気になりチャンネル」の導入

これはなんとかできないものかと思い、Slack のやりとりを観察してみると、変更依頼の多くは「文言」「要素の位置」といった小さなものでした。
そこで、こんな仕組みを導入してみました。

その名も「気になりチャンネル」。
Biz側、Dev側関係なく、プロダクトを触っていて感じた違和感や改善点を気軽に投稿できる Slack チャンネルを作成しました。併せて、機能開発に関しては以下のルールを設けました。

ルールその1:受け入れ基準を明確にする

まず重要なのは、要件定義の段階で「どこまで実装できていれば受け入れ可能とするのか」という基準をきちんと決めておくことです。

この基準を明確にしておくことで、実装が完了した後に「やっぱりこの文言を変えてほしい」「ボタンの位置を少しずらしてほしい」といった細かい要件変更が入りづらくなります。

要件を定義する側にとっても「ここまでは責任を持つ」という線引きができ、エンジニアにとっても「ここまで作り込めば文句は言われない」という安心感につながります。


ルールその2:細かい要件変更は気になりチャンネルに記載する

それでも、どうしても要件定義の段階で拾いきれない細かい変更点は出てきます。

例えば、文章のニュアンスがしっくりこない、デザインの余白が少し気になる、といった類のものです。

そうした場合は、動作レビューの場で直接「これ変えて」と言うのではなく、必ず「気になりチャンネル」に投稿することをルール化しました。

これにより、エンジニアがコードを書いた後に想定外の修正依頼が飛んできて振り回されることがなくなりますし、変更内容がチャンネルに蓄積されるので履歴も明確に残ります。


ルールその3:投稿された気になりは週単位で優先度を決め、クイックに対応する

気軽に投稿できるとはいえ、全てを対応していては工数も膨らみますし、プロダクトの統一感にも悪影響が出る可能性があります。

そのため、投稿された内容の中で「1週間以内にリリースできそうか」「バックエンドの改修を伴わないか」「破壊的変更が含まれないか」という観点で PdM とリードエンジニアが優先度を判断し、対象となるものだけをその週のうちにクイックに対応します。

規模が大きすぎたり課題が明確でない、抽象的すぎる内容などについては、その場で「今回は見送ります」といった内容を理由とともにコメントし、明確に線引きをします。

こうすることで「どこまで対応して、どこからは対応しないか」が組織全体で共有され、無駄な期待値のズレを防ぐことができます。

運用してみてどうなったか

この仕組みによって、PjM は気軽に気づきを投稿できるようになり、エンジニアは「受け入れ基準を満たしていれば文句を言われない」安心感を得られるようになりました。

さらに、運用を開始して1年ほど経った今では、当初の狙い通り職種や部署に関係なく誰でも気になったことを積極的に投稿するカルチャーが定着しています。毎週だいたい8件前後は実際に対応されています。

要件変更についても「絶対に直してほしいもの以外は気になりチャンネルに投げる」という文化ができあがり、エンジニアと PjM の衝突はほとんど無くなりました。

まとめ

プロダクトを良くしたい気持ちは全員同じ。

ただし、それをどう開発フローに落とし込むかで、チームの健全性は大きく変わります。

「気になりチャンネル」というシンプルな仕組みですが、導入したことでエンジニアのモチベーションを守りつつ、プロダクト改善のスピードも落とさないバランスを取れたんじゃないかなと思ってます。


Bizibl では開発エンジニアを絶賛採用強化中です。カジュアル面談に興味がある方はこちらから!
https://open.talentio.com/r/1/c/bizibl/pages/99945

株式会社Bizibl Technologies テックブログ

Discussion