お金のリファクタリング ～価値の尺度～
前回の記事で書いた通り、現在私は価値Managerクラスと化したお金クラスの絶賛リファクタリング中。現在のお金というものに紐づいている、様々な意味や機能を一つずつ紐解いて引っ剥がしていこうと試みています。
というわけで、今回は、お金に紐づいている「価値の尺度」という機能についてのお話。
お金は本当に価値の尺度か？
【貨幣】
商品交換の媒介物で、価値尺度・流通手段・価値貯蔵手段の三つの機能を持つもの。
（広辞苑より）
「お金は価値の尺度」
と、私たちは当たり前のように受け入れている。
例えばスーパーに行って、100円の普通のトマトと、200円の有機トマトが並んでいたとする。
「有機トマトの方がいいけど200円か…」
自分の懐事情と相談しながら、今日は100円のトマトにするか、200円の有機トマトにするかを考える。
有機トマトが、普通のトマトよりも価格が高いことについては、
「有機野菜は栽培が大変だし、体にも良いから、仕方ない。それだけ価値があるってことだから」
と受け入れている。
なるほど、お金は価値の尺度として機能している。
では、次にマイホームの購入を検討するとする。不動産広告や現地の物件を見たりしながら、
「この家は立地もいいけど5000万か…。こっちは2000万円で手頃だけど築年数がいっているし、立地もイマイチだな…」
自分の貯金や年収と相談しながら、あれこれ悩む。
築年数が浅くて立地も良い家の価格が高いことは、普通に受け入れている。築年数の浅さや立地の良さは価値だから。
なるほど、お金は価値の尺度として機能している。
ではここで、トマトと家を並べてみる。
200円の有機トマトと、5000万円の家。
「この家は、有機トマトの25万倍の価値があるな」
「このトマトは、この家の25万分の1の価値だな」
と、私たちは考えるだろうか？ たぶん多くの人は考えない。
だけど、お金という共通した単位の線上に並べることができるので、私たちがトマトと家を並べて考えることがあろうがなかろうが、
「家を1軒買うお金で、トマトを25万個買うことができる」
という事実は存在する。
そのつもりはなくても、
「このトマトは、この家の25万分の1の価値だ」
というメッセージを発してしまっているのだ。
私たちは相場で判断している
トマトや家を作るのにどれくらいの労力がかかるのか、私はエンジニアなので、わからない。だけど、アプリを作るのにどれくらいの労力がかかるかはよく知っている。
「アプリって、ちゃちゃっと作れて、いくらでも複製できるから、簡単に儲けられるんでしょ？」
非エンジニアの人と会話をしていると、こう思われているんだなー、と感じることがよくある。
アプリストアに並んでいるアプリたちの価格が無料～数百円ということから、
「無料～数百円で採算が取れる＝ちゃちゃっと作れて、たくさん売れるorたくさん広告収入が入る」
と想像しているのだろう。
だけど、実際にアプリを開発するには、数十～数百、数千時間を要する。
そして、お金を出して購入してくれるユーザはそこまでいないし、広告収入だって微々たるものだ。それなのに、毎年Appleストアへの登録費用はかかるし、OSアップデートに対応する必要は随時生じるし、ユーザを維持したり増やしたりするために、追加機能開発する時間も必要になる。
つまり、アプリストアに並んでいるほとんどのアプリは赤字である。アプリ単体で採算の取れているものは1%にも満たないと思う。
iPhoneという高価な品物を買える人が、700円のアプリを見て「高い」と言う。
その人の所持金に対して、700円が高いのではない。
アプリの開発にかかっている労力と700円を天秤に載せて測って、700円を高いと感じているのでもない。
アプリストアに並んでいる他のアプリと比べて、700円を高いと感じているのだ。
私たちは、家族や友人などの近しい人と、お金を介したやり取りをすることは、ほとんどない。お金を介したやり取りをするのは、「距離のある相手」とだ。
どう作られているのか、作り手がどう生活しているのか、そういったものが見えない相手と物やサービスをやり取りする時に、お金を介する。
私たちは、「どう作られているかわからないもの」に対して、どう作られているかわからないから、相場を基準に判断してお金を払う。
どう作られているかわからないのだから、本当にはその価値を判断できているとは言えない。
「価値のわからないものの価値をとりあえず判断する尺度」としてお金が使われているという点で、
「お金は価値の尺度」
というのは合っているが、対象の価値を本当に表しているわけではない。
だけど、「生活に必要なものをお金を介して得る」という仕組みの資本主義社会で暮らしていると、お金の大小が価値の大小であるような錯覚を抱きやすく、物事を相場で判断することが癖になっていく。
職業も相場で選択
「○○の仕事だと、食べていけないから」
というセリフを私たちは違和感なく言ったり聞いたりする。
だけど、もしも私がお金という概念を知らない国の人間だったら、首を傾げて尋ねる。
「その仕事は人から必要とされないの？」
「その仕事をするのに必要な能力を持ってないの？」
「この国は食べ物が不足しているの？」
この問いに全てノーが返ってきたら、
「じゃあ何で、その仕事だと食べていけないの？」
そう聞き返すだろう。
「○○の仕事だと、食べていけないから」
というのは、
「○○の仕事の賃金相場だと、十分な衣食住を得られないから」
という意味だ。
私たちは、仕事すらも相場を基準に選んでいる。
一度出来上がった相場基準は、その後、大きく変わることはない。需要供給の関係で上下したとしても多少の範囲だ。過去のあれこれの経緯で決まった、現状の実態に即しているとは限らない相場を基準に、私たちは自分たちの仕事を決めて、社会を作っている。
スコープという考え方
「社会を１つのシステムとして捉えることで、システム開発のノウハウを適用して社会システムをリファクタリングする」
というのが私の趣旨なので、今回もシステム開発になぞらえて考えてみる。
システムを設計する上で大切な考慮ポイントとして、「スコープ」というものがある。システムには値を格納する変数というものがあるのだが、この変数の有効範囲（＝スコープ）をできる限り最小にすることを抑えておくと、良いシステム設計になりやすい。
どういうことか、システムを構成する各部品を工房に例えて説明してみる。
ある工房があって、その工房の出入り口にはポストがある。
その工房の仕事は、入口のポストに投函されたＡという品物を、Ｂという品物に加工して出口ポストに入れることだとする。
そして、ＣやＤという道具を使って、ＡをＢに加工するとする。
この時、もしもＣやＤが他の工房と共有して使っている道具だったら、他の工房のことも意識して使う必要がある。勝手な使い方をしたら怒られるかもしれない。
だけど、もしもこの工房の中だけで使われる道具ならば、この工房の中だけで完結するので、どう使おうが勝手だ。
「なるべく自分の工房の中にある道具を使って、ＡをＢに加工する」
というのが、「変数のスコープを最小にすること」だ。
もっと言うと、Ａがどうやって来て、Ｂがその先でどう使われるか、ということも意識せず、「自分の工房の中でＡをＢに加工することにだけ、ただひたすら専念すること」が「変数のスコープを最小にすること」だ。
そうすることで、考える必要のあることをシンプルにできるし、どこかの工房で何かあってもその影響範囲を最小に抑えることができる。
さて。お金というのは、この例でいうＡやＢである。
私たちは、自分に渡されたお金がどういうルートで来たかわからないし、誰かに渡したお金がその先でどう使われるかわからない。
わからなくすることで、自分のタスクをシンプルに考えることができる。
物事をシンプルに考えるための方法として、お金というインタフェースを設けていることは、システム設計の観点で考えると悪くない。
じゃあ、システム設計の観点で見た時に何が悪いかというと、お金の「単位（目盛り）」がグローバルスコープになっていることだ。
1円あたりの機能（できること）がグローバルスコープ（システム全体が有効範囲）になっているがために、自分たちでコントロール不可能なところによる影響をもろに受けてしまっていることだ。
人間は同種の物事で、10倍以内に収まるものならば、それなりにうまく相対的に比較・判断することができるらしい。
（参考書籍）
有機トマトと普通のトマトを並べた時に、諸々の要素を加味してつけた値段の比率自体は、価値の尺度として、おそらくそれなりに妥当なのだ。アプリストアに並んでいるアプリの価格だって、各アプリの価格の比率を比較するだけなら、まぁ妥当かな、と私も思う。
だけど、トマト同士を比較する時の1と、家を比較する時の1は、等しくないのだ。というか、トマトの比較基準と家の比較基準を変換することは不可能だろう。変換不可能なはずのものを、無理やり単位を同じにして変換可能にしているのが現在のお金だ。
つまり、トマトを買う時の「１円」と、家を買う時の「１円」は、価値の尺度として本当は異なるものなのに、これをグローバルスコープとしてシステム全体で使いまわしているのだ。
システムのリファクタリングでは、本来異なるはずの概念（クラス）を持ちまわって使ってしまっているようなケースがあった場合、クラスを分離する形で対応する。
じゃあ、この場合、トマト用の通貨と、家用の通貨を新たに用意すればいいのか？
それぞれの通貨を試しに作ってみて、それでうまくいくかどうか簡単に試すことができるならば試してみるのがいいのだが、それはかなり大掛かりな改修となるし、「トマト用通貨と家用通貨をどうやって交換するのか？」という課題が生じるのは明らかなので、大掛かりな改修を始める決断を下す前に、
「新しいクラスは本当に必要か？」
「そもそも、現在のインタフェースは適切なのか？」
といった検討を行って、本当に必要だと判断できたクラスだけを新たに作成するようにする。
ちなみに、スコープというのは、視野や視座のことでもある。
システム設計では、検討内容に応じてスコープを逐一切り替える。（地図の縮尺を必要に応じて切り替えるのと同じだと思ってもらえればいい）
というわけで、視野を「全体を俯瞰するスコープ」に切り替えて、
「各工房（部品）間でやり取りするインタフェースとして、トマト用通貨、家用通貨…を用意するのが適切なのか？」
を検討しようと思うのだが、この話はまた今度。
この記事が気に入ったらサポートをしてみませんか？