先日プラハチャレンジの参加者と雑談していた際に 消す前提で機能を作ると保守性が上がるかもしれない という内容に触れたので、思ったことを記事にまとめてみました。
企画には必ず切り戻し条件を明示する
少し話が脱線しますが、僕はエンジニアになる前はWEBサービスの新規事業企画を担当していて、当時所属していたチームではサービスに追加機能を立案するときは 何が起きたらこの機能を削除するのか という「切り戻し条件」がセットで求められていました。
例えば求人サイトの応募を増やしたいな〜と考えて新機能を立案するとしたら、こんな感じ：
機能概要：スマホ閲覧者にはフッターに応募ボタンを表示する
切り戻し条件：実験的に追加した画面の求人応募率が逆に5%低下したらフッターを削除する
機能を追加しているとき自分はサービスを改善しているように感じがちですが、正確には機能を追加することでサービスに変化を加えているだけで、それが改善か改悪かは結果を見て初めて判明するわけです。なので「うお〜この機能追加は必要だ〜なぜなら必要だからだ〜」と結果を振り返ることなく機能追加していくと実はサービスが改悪の一途を辿っていた...なんてこともあり得るわけです。
だから常に結果を測定して、改悪したようなら追加した機能をすぐ削除しようね、という考えが企画チームに根付いていました
その機能はすぐ削除できるか
こうした考えが根付いたチームでは「自分が作っている機能はすぐ削除されるかもしれない」という前提でコードを書くわけですが、この前提がサービスの保守性にも良い影響を与える可能性を感じています。例えばこんな具合に：
- コミットやPRをrevertしたときに他の機能が混じらないようにしよう
- →コミット/PRの粒度が適切に保たれる
- 削除する箇所が最小限に抑えられるようにコードを書こう
- →高凝集なコードに
- 要らなくなった機能はコードごと削除しよう
- →コードベースが小さくなり、デバッグや新規参画者のキャッチアップが簡単に
- 他の機能がリリースに混じらないよう機能単位で素早く開発してリリースしよう
- →リソース効率からフロー効率重視、リリースサイクルの改善
- すぐに元の機能に戻せるようにフィーチャーフラグを挟んでおこう
- →新機能に起因する障害が起きた時の暫定対応が速くなる
- 削除しやすいように外部ライブラリは一箇所にまとめてラップしておこう
- →依存関係が一箇所にまとめられて疎結合に
- 削除手順に対応漏れがないよう、機能追加した時の移行手順書を残しておこう
- →重要な知識がドキュメント化されて属人性が排除される
- どうせすぐ削除されるかもしれないから作り込みすぎないようにしておこう
- →YAGNIや早すぎる最適化の回避
- 切り戻し条件を測定できるようにしておこう
- →ログなどの非機能要件を実装し忘れない。後から追加するより正確な計測に繋がりやすい
- こういうデータも必要になるかもしれないから取っておこう
- →いざ必要になった時、ログを仕込んでデータが蓄積するのを待たなくて良い
- どうせコードを書くなら消されたくない！この機能は本当に作る必要があるのか自分も考えよう
- →作業者からサービスの開発者に意識が切り替わる
こじつけっぽい項目もありますが...笑
本来は企画職のための「切り戻し条件を必ず考える」というルールでしたが、意外とサービスの保守性にも繋がるかもしれません。役に立ちそうだったら使ってね〜！
Discussion