ビジネスとコードの関心の非対称性

ソフトウェアの複雑性、歴史の積み重ねによる変更と、例外ルールの多さがけっこうな影響力を持っている
あと、例外ルールって、実際のドメインエキスパートからすれば「あーそういえば有るよねー」くらいだったりするけど、コードに落としてみると、8割とかがそうゆうパターンへの対応だったりするんだ

— magnoliak🍧 (@magnolia_k_) February 22, 2020

コードの8割は例外への対応だったりする一方で、ビジネス側の人は実現したい業務の主たる内容に関心がある。

一方でコード自体に、王道ルートも例外ルートの色分けは無く(ユースケース図で言うところの基本ルートと、代替ルートは有るけど)、等しくロジックとして実装しなければいけない。テストの密度を変える、みたいな話はあるかもしれないけど、王道ルートだろうが例外ルートだろうが、必要なロジックに合わせてコードを書くしかない。

このビジネスの関心と、コードの関心の非対称性が、時に「なんでたったこれだけのことをやるのにそんなに工数がかかるの？」みたいな不信感につながっていくのではないか。

また、当たり前だけど、ビジネス要求に基づく例外ルート以外にも、「メモリが不足していたら？」「外部サービスへのリクエストが返ってこなかったら？」「インフラに異常が発生したら？」などなど、さまざまなシステム上の要求に従って実装しなければいけないコードが有る。

また、業界の法規制(内部統制とか)からの要求によってはさらに、ビジネス側の主要な関心事項から外れるけど、実装しなければいけないことも発生してくる(ログが参照できるようになっているとか、さらにそれが改ざんできないようになっているとか)。

この非対称性を認識しないと、いつまで経ってもスピード感や、コスト感に対する合意が得られないのではないか？

この王道ルートと、例外(代替)ルートのビジネス上のインパクト大きさの割合が、コードに占める割合と合わないのって、けっこうビジネス側とエンジニアサイドで会話が合わないポイントだよなって

「そんな細かいことはいいんだよ」って言われるっていうさ

でも網羅しないといけないんだよっていう

— magnoliak🍧 (@magnolia_k_) February 22, 2020