シンプルとは何なのかの再考
昔書いた記事。今のシンプルにたいする考え方のアップデート
シンプルとは、システムの提供価値の総量からみて認知的負荷が比較的低い関数fを選択することである。
認知的負荷 = f(システムの提供価値の総量)
認知的負荷とは、人間の有限なメモリでの把握のしやすさであり、人間フレンドリーさである。
システムが提供する価値の総量はいろいろありそうだが、僕自身の現時点の認識だと、「ユーザー規模と機能価値(数)の掛け算」と捉えている。「総量」とは累積値のことではなく、MAU(月間アクティブユーザー数)やDAU(日間アクティブユーザー数)に機能価値(数)を掛けたものとして捉えてほしい。つまり、ある程度瞬間的な値である。
一般的に、システムが提供する価値の総量が増えれば増えるほど、システムは複雑化していき、メンテナンスや機能開発する側の人間のシステムに対する認知的負荷は高まっていく。例えば、ユーザー数が増えれば、インフラを強化しなければいけないし、影響を与える人間の数が多くなるため、セキュリティ要件も高くなり、コンプラ的側面も厳守しなければいけなくなる。システムが提供するサービスのレベル(例えばお金を扱ったり、命を扱ったり)によっては、システムを止めないや復旧時間が重要になってくる。また、ユーザー数とは別に、機能の数を増やすと、その機能を提供するためのインフラやプログラミングコードも増えていく。
システムの提供価値の総量と、それをメンテナンスし機能開発する側の人間に対する認知的負荷は相関関係にある。下の図はそのイメージとして書いた。
しかし、実際にこのように、原点からのきれいな線形になることは少ない。なぜなら、業務レベルの開発において、スクラッチ(0から)でコードを書くことは少なく、インフラレベルからアプリレベルからコードレベルまで、さまざまなOSSライブラリや有料ライブラリが開発補助として提供されており、開発初期はこれらライブラリの学習コスト分認知的負荷は増えるが、その分提供価値が上がるからだ。y軸に定数項が足された線形になりそうである。下の図はそのイメージとして書いた。
現代の開発において、基本的に何かしらのフレームワークを使って開発されているため、ある程度の認知的負荷の爆発は抑えられる。しかし、もし仮に、これらフレームワークを使わずに、認知的負荷を抑える開発モデル(MVCパターンとか)やアーキテクチャを使わずに、コードにパターンやルールや一貫性がないと、認知的負荷は下の図のように指数関数的に高まってしまう。また、フレームワークにはそれぞれ設計思想があり、その設計思想を超える価値を提供する場合もまた認知的負荷は高まってしまう。例えば、フロントエンドのフレームワークである、Vue(OptionsAPIの使用を想定)は初学者へのハードルはかなり低く初期の学習コストと認知的負荷が低い代わりに、開発が進むにつれて、関数を組み合わせた複雑な処理などが苦手になってくる。同じフロントエンドのフレームワークであるReactは学習コストが高いが、開発後期でも比較的認知的負荷を抑えながら開発をすすめることができる。もちろんどこかで限界はあり、また開発者の書き方にも大きく依存する。
フレームワークやアーキテクチャをうまく取り入れることにより、認知的負荷が抑えられる事がわかった。理想としては以下の図のような対数関数てきなものが理想だと思う。
ここまでで提供価値の総量と認知的負荷の関係性を説明してきた。
自分たちのシステムが提供したい価値の総量に適切なフレームワークやアーキテクチャを採用する
下図に前のセクションで出てきたすべての関数を重ねて表示してみた。
この記事で言いたいことは、「自分たちのシステムが提供したい価値の総量に適切なフレームワークやアーキテクチャを採用する」ということ。例えば下の図で、自分たちが提供したい価値の総量がゾーンAに当たるなら、フルスクラッチか軽量のフレームワークやアーキテクチャをつかう①のやり方を選択する。同様にゾーンBなら①、ゾーンCなら③、ゾーンＤなら④である。
もっとも、そもそも自分たちが提供したい価値の総量を想定するのは難しく、また想定した価値の総量に見合うフレームワークやアーキテクチャがどれにあたるのかがわかる能力はまた別問題である。
そのため、ゾーンBを想定して開発を進め、サービスがヒットしゾーンCに来だしたら、頑張って耐えつつ、ゾーンDに入る前に、③か④にリプレイスするなどのやり方をとることもあったりする。
ほかにも色々なルートがありそうなので、ぜひ考えてみてほしい。
こちらの記事もどうぞ(2分ほどで読めます)
Discussion