ある開発現場にて
ショッピングサイトの保守をしているAさん
ある日、Aさんは設計書の中にこんな記載を見つけました。
手数料が0円の場合
即日配送オプションを選択できるようにする。
Aさん：先輩、なんで手数料が0円だと即日配送オプションが選択できるんですか？
Aさん：即日配送をお願いするなら、むしろ手数料が余分にかかるような気がしますけど。
先輩：え…確かに。なんでだろうね。昔からある仕様みたいだし、よく分からないね
Aさん、新しい要件の開発を頼まれる
クライアント：有料会員は手数料無料にしてたんだけど、今後は新しくできたプレミアム会員を手数料無料にして、有料会員からは5%だけ手数料をいただくようにしたいんだ。
Aさん：分かりました。手数料無料になる条件を改修しますね。
～リリース後～
クライアント：有料会員の方から問い合わせがあって、即日配送オプションが選べなくなったらしいんだけど、調べてみてくれない？
Aさん：手数料がかかるようになったので、即日配送オプションが選べなくなったのではないでしょうか？
クライアント：え？即日配送オプションは有料会員向けのサービスだよ。手数料とは関係ないはずだ。
その後、Aさんが保守しているショッピングサイトについて以下の事実が明らかになりました
- リリース当初から、無料会員は手数料がかかり、有料会員は手数料無料という仕様だった
- あるタイミングで、有料会員向けに即日配送オプションが導入された
- その機能が「手数料が0円の場合、即日配送オプションが選択できる」と設計されていた
三段論法設計とは
以下のような設計を三段論法設計と名付けました。
- Xの場合、Yの処理を行うという要件がある
- 既存の仕様で、Xの場合、必ずZになることがわかっている
- Zの場合、Yの処理を行う、という設計で1.の要件を実現する
上記の例だとそれぞれ以下に該当します
X＝有料会員である
Y＝即日配送オプションが選択できる
Z＝手数料0円である
三段論法設計をしてしまう背景
「有料会員の場合、即日配送オプションが選択できる」という設計にすべきだし、普通はそうするだろうと思います。
上述したのは単純な例ですが、実際はもう少し複雑なケースにて三段論法設計が発生してしまう可能性があるのではないかと考えています
- 例1
- DBに条件Xを直接的に表現する項目が無く、導出が必要であった
- 条件Xの判定処理が再利用可能な形で部品化されていなかった
- たまたま条件Xであれば必ずZになるような条件Zが、使いやすい形で用意されていた
- 例2
- DBに条件を直接的に表現する項目Xがあったが、新しいエンティティのDB取得処理追加を避けて、既に取得しているエンティティの情報Zだけで済ませたかった
- 性能要件上の理由など
- 例3
- 開発チーム内で「X＝Z」という業務仕様が暗黙の了解になっていたり、当時の仕様ではほぼ同義とみなされたりしていた
三段論法設計によって起きてしまうこと
背景にある業務仕様が見えにくくなる
三段論法設計をしてしまうと、設計の背景にある業務仕様が見えにくくなってしまいます
Aさんは、「手数料が0円だと即日配送オプションが選択できる」という設計から、「即日配送オプションは有料会員限定のサービスである」という業務仕様を読み取れませんでした。
前提となる仕様が変わったときに影響を受ける
三段論法設計は
2. 既存の仕様で、Xの場合、必ずZになることがわかっている
が前提である設計です。ここが崩れるとそもそも成り立たなくなります。
Aさんは、有料会員にも手数料をつける改修を行ったことによって、同時に即日配送オプションが選択できないようになってしまいました。
この手のことは、業務仕様を把握していない限り、事前の影響範囲の調査でも発見されにくいものです。
直接的な表現をしよう
三段論法設計をやめて、業務仕様を直接表現する設計を心がけましょう。
これにより、設計の意図が明確になり、変更に対して予期せぬ影響も受けにくくなります。