システムで表現されてないものは事業のボトルネックになりうる

事業に存在する概念が、ちゃんとシステムで表現されていないときがある。

具体例を出す。たとえば、A機能とB機能とC機能をフルで提供しているサービスがあったとする。そこで、A機能が有効ではないユーザーのUIでは自分の情報取得のAPIみたいなもので `a_feature: false` みたいなフラグで制御するみたいなことがあると思う。

ところが、このA機能がオフなユーザーを実は営業パーソンは「割引プランユーザー」みたいに呼んでいたとする。つまり、システム上は単にA機能が使えないユーザーなんだけど、事業上は割引を受けているユーザーになっている。

こういうとき何が起こるか。

例えば、新しいD機能を追加するときにこれも無料プランユーザーには使わせたくないなと思ったりする。すると `a_feature: false` と `d_feature: false` みたいなフラグを返すAPIが作られて、それで制御する。

しかし、実際には「割引プラン対象ユーザー」なので、誰もA機能とD機能をオフにするユーザーだとは思っていない。だから、営業はずっと割引プランユーザーと言い続けるが、エンジニアはA機能やD機能がなんらかの理由でオフになることがある、と考える。

これを無数に繰り返すと、制御しきれなくなって破綻してしまう。

事業に存在する概念はシステムでも表現したほうがよい

これは恣意的な例である。しかし、事業に存在する概念を直接システムの言葉に表現できていないということは普通にある。なんなら、僕はそのような現場でしか働いたことがない。

このようなシステムの不備（事業についていけていないシステム）は常になにかしらのトラブルを起こしてきた。そしてそのトラブルをどのように解決するかというと、だいたいエンジニアのほうがリソースが少ないので人力で頑張るみたいな話になる。

これは一定程度効果を発揮すると思う。しかし、人力で頑張るとかマニュアルでどうにかするみたいな意思決定は却ってシステムの発展を滞らせることがある。エンジニアは仕事が減って嬉しいかもしれないが、それはむしろ事業の芽を摘む危険な行為なのかもしれない。

これはあくまで想像なのだが、人力なりマニュアルでどうにかするという運用が定着することでシステムを改善しようという気が、エンジニアもそれ以外の部署の人にも起こらなくなってくる。なぜならば、それで慣れているから。

しかし、ソフトウェアは容易に進化・変化できるからこそ荒れ狂う市場に対応できる。進化・変化の芽を自ら摘んでしまう、その機運をなくすような施策は本来は事業上のリスクである。

まとめると、事業に存在する概念をシステムで表現しないのは、それ自体が事業のリスクになりかねないと思っている。システムの発展に、その事業に存在する概念が勝手に組み込まれなくなり、勝手にシステムが柔軟性を失い、勝手に事業の可能性が失われていく。

それがよいソフトウェア開発なのか？

常にそう問うていたいものである。