決断のコストと携帯電話キャリアの話

http://syakkin-dama.hatenablog.com/entry/20170426/1493204691 を読んで少しだけ考えた。しかしリンク先の話とはあまり関係ないかもしれない。
昨年末まで使っていたNTTドコモで、一番嫌だったのは、「できるだけちょうど2年毎に買い替えないと損をしてしまう」「買い替え時に適切な機種を選ばないとやっぱり損をしている気分になる」ということだった*1
前回から2年経ったタイミングで欲しい機種がなかったら、損を継続しつつもうしばらく待つか、それともあまり欲しくないけど損したくないから機種変するか、全く意味不明な選択を迫られるのである。だいたいいつもそれに向けて「次は何にすべきか」「今後のトレンドはどうか」みたいなことを検討しているような感じだった。いろいろあって機種変の決断を失敗したらそれはそれでなんか悔しかったりした。無駄な決断コストを消費している気がした。


そんなわけで、端末を売っていないMVNOMNPすることは、無駄に消費していた決断コストを下げることに大きく貢献してくれると思う。何と言っても、いつ機種変しても、その機種を買ったこと以外では損しないのだ。Androidは全部クソな感じがしたのでiPhoneSEを選んだ。たとえば2年後にイヤホンジャックのない機種しかなくなってて、それでも自分はMDR-EX300SLを使い続けたい、みたいな場合でも、単に新機種を買わなければいいだけなのだ。
「iPhone8s買うとイヤホン使えなくなるからイヤホンどうしようか…BTだと音ゲーできないしLightning端子のイヤホンだと他の機械に繋げられないし…」みたいなことを考えないといけないのは、もしかしたら楽しいかもしれないけど、今はそういうのはできるだけ避けたい気分だ。だってイヤホンはそういうつまんないことに悩むより「BAのやつ買ってみようかな?」とかで悩むほうがいいじゃん。


余談だが、自分がそんな感じのこともあって、ソフトウェア開発においてもできるだけ変数名とか関数名とかを決めたくないしそういうのをつけなくていいようなのが望ましいと思う。そのへんが分かってないひとたちはすぐに名前を付けたがる。何でも状態遷移表を書いて設計することに疑問を持たない連中はだめだと思う。状態遷移表を書くだけでどれだけの名前を決めないといけないのか、そしてその名前が適切じゃなかったときに発生する諸問題にどう責任を持つつもりなのか。もちろんSTATE_HOGEなどのようにコード内に状態名が出てきてしまうような作りにせざるを得ない場合には状態遷移表を書いてもいいと思うが、そうでない書き方ができる場合には本当に状態遷移でそれを記述していいのかどうか考えるべきだと思うよ。

*1:昔はそうではなかった。悪名高いインセンティブが出ていたときは、そこまで明確に損というわけでもなかったので、6ヶ月以降の好きな時期に機種変すればよかった。2007年の新販売制度の直後など、完全に割賦になったので全く機種変しなくても損することがなくなった時期があったと思う