ソフトウェアにうまい前提を与える

ソフトウェア機能が、普通はユーザはこういう利用方法はしないだろう、という前提にもとづいて作られていることがある。

先日の経験を例に上げると、ちょっと理由があって自分のGmailの全メール一度にアーカイブ操作をしてみようとしたことがある。メールは8万件くらいあった。普通のユーザは一度に8万件もアーカイブ操作をしたりしないと思う。

実際に操作を実行してみたところ、「実行しています」というようなメッセージがしばらく表示された後、「リクエストの実行に問題が出ているようです」というようなメッセージが表示されてしまった。メッセージの内容は不安に感じるところがあったが、結果としては、すべてのメールがちゃんとアーカイブされため、大きな不満はなかった。

ユーザがこういうめちゃくちゃなことをすることは稀であり、一般的なリクエストのタイムアウトを過ぎたために、UIが問題を報告したのだと思う。実際にソフトウェアを作っている人にはよくあるかもしれないが、ユーザはさすがにこういうことは滅多にしないだろうという前提をしてプログラムを書くことはよくある。

こういう現実的な前提を置かなければいけない理由はいくつかあると思うが、その１つにソフトウェアの複雑性を下げることができるというのがある。Gmailの例では、時間のかかる処理については、プログレスバーなどを使って、状況をユーザに表示することもできるだろう。しかし、大半の処理が短時間で終了するのにも関わらず、プログレスバーの表示機能を追加することで、ソフトウェアの複雑性を上げ、保守を難しくし、将来にわたるコストを高める積極的な理由はない。

逆にとらえると、ソフトウェアが解決しようとしている問題に、うまい前提をあたえると、ソフトウェアの構造をシンプルに維持することも可能になる。ただし、前提をまちがうと、ユーザに不便をあたえることになり、製品の価値も下がるため、バランスが非常に難しい。エッジケースでUIが多少おかしくなるのは許されるかもしれないが、いきなりデータが消えたりするのは困る。

問題にうまい前提をあたえられるエンジニアはセンスがあって優秀だと感じるが職人芸的でもある。ここで言ってるうまい前提は、保守性を考慮した問題のモデリングと言い換えられるかもしれない。保守性を考慮した問題のモデリングを工学的に取り扱う方法があるかが気になる。

機能を要求をする人と実装をする人が同じかすぐに意思疎通できる状態にないと、実現が難しいのであまりやられてないのかもしれない。自社サービスつくってるとやりやすい。機能を要求をする人と実装をする人が別で異常に保守性さがるという例も見かける気がする。

モデリングと実装の話なので、ドメイン駆動設計を読むと知見が載ってるのかもしれない。(まだ読んでない)