「お金」という概念をシステム設計の視点で見てみる

前回、
「社会を１つのシステムとして捉えると、システム設計の観点で事象を説明できる」
という気づきを得て面白くなったので、自分の身の回りの色々な課題をシステム設計の観点で紐解き始めた。

というわけで、今回は
「お金」という概念をシステム設計の視点で見てみると…？
というお話。

「そのシステムは何であるか」

システムを開発する上で大切なことは、
「そのシステムは何であるか」
を明確にして、そこからぶれないこと。

気を付けたいのは、「できるかどうか」で判断しないということ。
やろうと思えばできるから、という理由で、
本来の役割でないことをやり始めると、気づいた時には、複雑で入り組んでいて、わかりづらいシステムになっている。

例えば、Facebook。
その名前が示す通り、元々は、知人たちの投稿が一綴りの本のようにまとめられていて購読できることを目的としていた（と思う）。
普及し始めた頃のFacebookは、投稿を読むことと、知人と繋がることに特化したシンプルでわかりやすいシステムだった。
しかし、そこから、
「グループも作れるね」
「イベントページも作れると便利だね」
「アプリも入れられるといいのでは？」
etc..
様々なニーズや思惑の元に、機能が次々に追加されていき、現在のFacebookは、「色々なことができるけれど、使い勝手のイマイチなシステム」となっている。

知人の日々の徒然を眺めるシステムと、グループの情報交換や、イベントを管理するシステムとでは、適した画面構成や動線が異なるのだから、いっしょくたに詰め込むのに無理があるのは当たり前である。

だから、
「新たな機能を加えたいけど、いいかな？」
となった時に、
「そのシステムは何であるか」
につど立ち返って、
「そうだね、それはこのシステムの目的・役割に叶っているね」
あるいは
「いや、それはこのシステムの目的・役割から外れてるね」
と、判断することが大切である。

「そのクラスは何であるか」

「それが何であるか」を明確にして、ぶれないことが大切なのは、システムを構成する各要素にも言える。

オブジェクト指向プログラミングの場合、
たくさんのクラス（概念）が相互に関係しあうことによって、１つのシステムを成している。

例えば、図書館システムの場合、下図のようになる。

１つ１つのクラスの役割をシンプルで明確にすることで、クラスの改修や差し替えが容易な保守性や拡張性の高いシステムとなる。

たとえば、上図の図書館システムで、
「利用者が自分で手続きを行える自動貸出返却端末を導入しよう」
となって、この変更に対応するためにどうすればいいか、を考えるとする。

「職員クラスというのは、特定の図書館に属していて、貸出や返却を行うクラスだから、自動貸出返却端末もこのクラスの一員と捉えればいいのでは？」
「でも”職員”というのは人間を表すものだよね？」
「じゃあ、このクラスの名称を人間か機械かを限定しないものに変更しよう」
てな感じの検討を経て、クラス名や属性名を変更するというシンプルなやり方で対応できる。

このように変更に柔軟に対応していけるシステムにするためにも、
「このクラスは、こういう役割なんだ！」
ということが、はっきりとわかるクラス名にすることが大切。
名前を曖昧にすると、いつのまにか１つのクラスがあれもこれも担って、わかりづらい中身になってしまうことがよくある。

Managerクラスというアンチパターン

Managerクラスという、アンチパターンとして有名なクラス名がある。

「こういった情報を管理して、それに関する処理を行うクラスにしたいな」
という時に、SystemManagerとか、AuthManagerとか、ProcessManagerとか、そんな風にxxxManagerというクラス名を付けてしまうことがある。

だが、この名前をつけてしまうと、最初はそんな大がかりなものを考えていなくても、xxxに関する「あらゆる」処理を突っ込んでいってしまい、気づくと手に負えないくらいに肥大化してしまう危険性を孕んでいるので、安易にクラス名に使わない方がよいとされているのだ。

例えば
「システムに関する情報を一元管理するクラスを用意しよう」
と考えて、SystemManagerクラスを作る。

そして、
「誰がログインしているか、という情報もシステムで管理する情報だから、このクラスで管理すればいいかな？」
と考えてログイン職員情報を格納し、次に、
「ログイン職員情報を管理しているから、認証処理もこのクラスでやってもらえばいいかな？」
となって認証処理が追加される。

そのうちに、
「各職員への簡単な伝達事項をログイン時に表示できるようにしたいな。簡単なものだから、ログイン職員を管理しているこのクラスでやってもらえばいいかな？」
「利用者に伝えたいこともシステムで管理できるようにしたいな。職員への伝達事項と似てるから、このクラスにやってもらおう」
「閉館後に行う締め処理はシステムに関する処理だから、このクラスにやってもらおう」
etc...となっていき、気づいた時にはSystemManagerhaは様々なクラスと密接にかかわりながら、様々な処理を行うクラスと化している。

外のクラスからすると、「何かよくわからないけど、何でもやってくれる便利なクラス」だが、その中を覗いてみると、各処理がどう関係しあっているのかいないのかも、長大なソースコードを読み解かないとわからない…というような状態に陥っていて、このクラスがシステムを改善する際のボトルネックになったりする。

社会システムの中の「お金」クラス

では、本題のお金について。

おそらく最初は、物を前借りするときの、AさんとBさんの間でだけ成り立つ証文のようなものだった。

それがそのうちに、Aさんから受け取ったお金を、BさんとCさんとの間でのやり取りにも使えることに気づいて、それが拡大していき、特定のコミュニティの中でならば、物と交換できる媒体となった。

物の代わりになるので、これをお礼の気持ちを表すものとして使い始める人々も現れた。

そのうちに、人に頼み事を聞いてもらうための手段としても使えることに気づいた人が賃金としてお金を扱い始めた。これによって、人間（の時間）がお金と交換可能になった。

やがて、利息や投資という概念を発明した人々が現れて、自身は何もしなくても、お金が勝手に増えていくようになった。

そうこうして、お金は「これさえあれば何でも手に入れられる！」という万能ツールとなり、現在の都市社会では、価値（っぽいもの）を表す指標として扱われている。

さて。
何が言いたいかというと、
これ、Managerクラスだよね？？
ということ。

名付けるならば、「価値Managerクラス」ってところだろうか。
価値っぽいものを、全てこのクラスに注ぎ込んで、それを使ってできることをあれこれ機能として付け加えていった結果が現在のお金という代物。

たとえば、お金をもらった時に、
嬉しい気持ちになることもあれば、
粗雑に扱われたように感じることもあるのは、
「お金クラスが何であるか」
が一意に定まっておらず、矛盾する意味を抱えているからだ。

システムエンジニア視点からすると、悪い設計だ。

そして、この価値Managerクラスを抱える現在の社会システムは、価値Managerクラスを通らずには、必要なものを手に入れることが難しいシステムと化してしまっている。

システムエンジニア視点からすると、非常に設計の悪いシステムだ。

私たちが人生を満たすために必要なのは、衣食住や娯楽、団欒であって、お金自体ではないはずなのに、お金を得るためのmy攻略法を編み出せなければ、生きていくことが困難になってしまうのは、この設計の悪さゆえだ。

リファクタリングという考え方

システム開発では、最初から全ての要件が見えているわけでなく、作ったり運用したりしていく中で見えてくるものにつど、対処していく。このため、開発の過程でどうしてもイマイチな作りになってしまう部分が出てくることは仕方がない。
しかし、それを放置したままでは、どこかで行き詰まってしまうので、折々で、綺麗に直していくリファクタリングという作業が欠かせない。

肥大化したManagerクラスをリファクタリングする時には、
そのManagerクラスが担っている役割を洗い出して、「この役割は別のクラスを用意して分離しよう」と、少しずつ責務をビリビリと引っ剥がしていく。
そうして、引っ剥がしていき、最後は、Managerクラスは消滅するか別の名前のクラスに置き換わる。

私は、リファクタリングしがいのありそうなシステムを見つけてはリファクタリングして、綺麗になったシステムを眺めてニヤッとするのが好きである。
そういうわけで、現在はお金クラスのリファクタリングに挑戦中。
長くなるので、その話は、また今度。