「フィードバックループを速く回すことが重要」という考え方は、アジャイル開発やリーンスタートアップなどで広く知られています。

実際、動くものを早く作り、フィードバックを得ながら改善していくことで、短期間で品質を高められる場面は少なくありません。

最近、この考え方は設計判断にも当てはまるのではないかと考えるようになりました。

実装すると違和感が見えてくる

設計は頭の中だけで考えていても、問題に気付けないことがあります。

しかし、実際に実装してみると、

  • クラスの責務が曖昧ではないか
  • 命名に違和感はないか
  • 依存関係が複雑になっていないか
  • モデルがドメインを自然に表現できているか

といった違和感が見えてきます。

この違和感こそが設計を改善するためのフィードバックです。

つまり、まずは実装してみる、そして、フィードバックを早く得るという考え方は重要だと考えています。

そのため、

仮説 → 実装 → フィードバック → 改善

というサイクルを速く回すことで、設計判断の質も向上すると考えています。

設計にはフィードバックループが通用しない場面もある

一方で、この考え方を設計全体にそのまま適用することはできません。

例えば、ドメインモデリングやシステム全体の概念設計を誤ると、後から修正するために多くのコードを書き直すことになります。

つまり、フィードバックループを速く回すことによるメリットよりも、作り直しのコストが大きくなる場合があります。

そのため、設計では

  • 後から変更しやすい部分は、早く実装してフィードバックを得る
  • 後から変更しにくい部分は、十分に検討してから実装する

というように、変更コストを考慮してフィードバックループの回し方を変えることが重要なのだと考えました。

おわりに

私はこれまで、「フィードバックループを速く回すこと」で開発体験を向上させるという話はよく聞いていました。

しかし今回、設計判断においても同じ考え方が有効である一方、設計には変更コストという制約があるため、適用範囲を見極める必要があることに気付きました。

「速く作って、速くフィードバックを得る」という一択ではなく、変更コストに応じてフィードバックを得るタイミングを設計することも、設計者に求められる重要な判断なのだと考えています。