| @Mac/iPhone

au の iPhone 、通話時の音が悪くてつらい。SoftBank の iPhone の方が電話しやすかった。他にも通話中はデータ通信ができないとか意外と電波の入りが悪いとか予想だにしなかった不便さがあってつらい。iPhone 、どこのキャリアで買っても大して違いないと思ってたけど、通信方式・インフラの違いは結構でかいと思った。

| @雑談

d4990c64f75ca38b6b416a9037adfed5.png (802×562)

Ruby 関連のことを検索していて Shopify の中の人のブログにたどり着いた。なかなか面白いことが書いてあった。

この人は去年の 11 月に iPhone 4 を落として割ってしまったらしい。すぐに iPhone 5 を買おうとしたのだけど、思いとどまって一月ほど iPhone なしで過ごすことにしたそう。自分がどのくらい iPhone に依存してるのか知りたかったのだとか。そしたら意外と良かったらしい。以下超訳。

iPhone があった頃は常に Facebook、Twitter、Email、iMessage、携帯、HipChat、Skype や対面での会話と心が安まらなかった。プッシュ通知を切ったとしても空き時間にメールチェックしたり Twitter や Facebook を見てしまう。常にオンライン状態で、どこにいてもどこにもいないような感じがつらかった。iPhone がなくなったらコンピューターの前にいるとき以外は目の前の友達や同僚のことだけ気にしていればいい。スマートフォンは作業と作業の合間の、さっきまでやっていたことと次にやるべきことについてに省みるべき時間を、ぼーっとゲームをしたり Twitter を見るような用途に費やす手助けをしていることに気がついた。スマートフォンがなくなってからアングリーバードやったり、Facebook を見たりして無為に時間を過ごすことがなくなり、やるべきことに集中できるようになった。

スマートフォンをやめて Nokia レンガ(昔ながらの携帯)で過ごすにあたって、心配してたのが以下の三点だった。

カメラがない

旅行するときはいつも iPhone で写真をとっていたけど、カメラは人に借りれば良いかも知れない。ひょっとするとなくても事足りるのかも知れない。

音楽がない

歩くときは気分を紛らわせるために音楽を聞いていた。しかし本当に音楽を聞きたいときはパソコンの前に座れば良いことに気がついた。音楽なしで歩いてもしんどくないし、周囲の物事に心を巡らせる良い機会になった。

地図がない

iPhone の Map は多用していたけど、方向感覚に自信があったのでどこかに行くときに地図を見るのをやめてみた。そうすると出発前に入念に準備が必要になった。外国に行くときは紙の地図を使った。また本当に迷ったときは人に道を聞けば良いし、尋ね先の人に電話して道を尋ねれば良い。

3ヶ月ほどスマートフォンなしで過ごしてみて、期待していなかった以下のメリットに気がついた。

よく人に電話するようになった

iPhone の頃はメールを多用していてほとんど電話をかけていなかったけど、古い Nokia の携帯だとメールを打つのがつらくてしょっちゅう電話をかけるようになった。同世代の人に電話をかけるとびっくりされる(みんなメールしか使わないから)。携帯の根本機能と会話の楽しさを再発見した。電話した方が話が早く済みそうな場合や深い話の時はメールではなく電話しか使わないようにしている。

携帯の存在を気にしなくなった

鞄の中に適当に携帯を突っ込んで出かけるようになった。ポケットに何も入ってなくて気楽になった。眠る前に携帯がどこにあるか探さなくていいし、安い携帯だからキズが入らないように気を付ける必要もない。心配事が減るのはいいことだ。

上に挙げた懸念事項は正しかったが、それなしでもやっていける

確かに色々不便だがなくてもやっていけることに気がついたし、スマートフォンを持たないことによって得られるメリットがあることもわかった。

“携帯を二週間に一度しか充電しなくて良いのは気が楽” というあたりはなるほどなぁと思った。寝るとき、出かけるときに iPhone を探さなくて良いのも羨ましい。随分楽だと思う。

自分もスマートフォンを使うようになってから Twitter 中毒が重症化し、移動中に本を読むということがまったく出来なくなった。iPad ではなく Kindle がいいと思ったのもネットを見る機能が付いてなくて読書に集中できそうだから。しかし結局手元に iPhone があると Twitter を見てしまう。この人みたいに思い切って落として割ってしまうのが良いのかも知れない。

| @散財

iPhone 5c の白か黄色がカッコイイと思ったけど家庭内稟議通らなそうなので諦めて安くなってた iPhone 5 を買った。黒色は iPhone 5s のラインナップにはないみたい(シルバーになるっぽい)ので型落ちだけど黒色もかっこいいしまぁ良いかなと思ってもうそろそろ買ってから 2 年になる iPhone 4S から乗り換えた。

MNP で SoftBank から au に移転したんだけど、キャッシュバックの 6 万円をもらうつもりがプランを選び間違ってもらいそびれ、あと一ヶ月遅ければ SoftBank の更新月で違約金かからなかったのに一万円弱の違約金が発生し、なんだかんだで結構な出費をしながら旧式の iPhone を手にする羽目になった。加えて au スマートバリューに申し込むつもりが自宅アパートが au ひかり未対応だったため申し込めず、ネット / IP 電話は Yahoo! BB (SoftBank)、携帯は au といういびつな状態になってしまった。

無職の頃とか血眼になって 1 円でも安く買い物をしようとしてたけど、年を取って気力が減退してきてるのと仕事をしていて調べ物にあてられる時間が少ないことが原因で最安を追求できなくなってきてる。仕事が終わったあととか週末の限られた時間で、可能な範囲でなるべく安い買い物をするしかない。

そういうわけで型落ちで iPhone 5 を買った。むかしは新しいものを追いかける Apple ファンボーイおじさんだったんだけど、こうして段々普通の情弱おっさんになっていくんだろうなぁ。

| @技術/プログラミング

一月くらい前から Lokka の master ブランチを自分のブログ用のブランチに merge してサイトをデプロイすると謎の白画面が出るようになっていて困っていた。現象は極めて謎で、ローカルの開発環境(RACK_ENV='development')では見られず、本番(RACK_ENV='production')だけで発生した。HTTP ステータスコードは 1054 が返ってきたりする。なんか変な gem でも入れてしまったかなと休みの日に動作検証したりしていたんだけどついぞ分からなかった。

SQL 弱者なので気がついてなかったんだけど、2月15日の commit で Site モデルに新しいフィールドが追加されていた(Add default markup in admin/site/edit · 2243dc5 · lokka/lokka ※この機能便利すね)。なので bundle exec rake db:migrate しないといけなかったわけだった。ローカルで動いている開発環境(データベースは SQLite)では Migration なんて行ってないんだけどエラーは出なかった。本番は MySQL で動いていて、こちらでだけエラーが出るようだった。

しかしいざ migrate しようとすると失敗する。

bundle exec rake db:migrate
Upgrading Database...
rake aborted!
Invalid default value for 'updated_at'

のようなエラーが出る。updated_at のデフォルト値がおかしいらしい。このときのテーブルの構造を見てみると以下のような感じだった。

mysql> desc entries;
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| Field           | Type         | Null | Key | Default             | Extra                       |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| id              | int(11)      | NO   | PRI | NULL                | auto_increment              |
| user_id         | int(11)      | YES  |     | NULL                |                             |
| category_id     | int(11)      | YES  |     | NULL                |                             |
| slug            | varchar(255) | YES  |     | NULL                |                             |
| title           | varchar(255) | YES  |     | NULL                |                             |
| body            | text         | YES  |     | NULL                |                             |
| type            | text         | NO   |     | NULL                |                             |
| draft           | tinyint(1)   | YES  |     | 0                   |                             |
| created_at      | timestamp    | NO   |     | 0000-00-00 00:00:00 |                             |
| updated_at      | timestamp    | NO   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| frozen_tag_list | text         | YES  |     | NULL                |                             |
| markup          | varchar(255) | YES  |     | NULL                |                             |
+-----------------+--------------+------+-----+---------------------+-----------------------------+

調べてみたところ MySQL の Mode が NO_ZERO_DATE になっている場合、MySQL は timestamp 型のフィールドのデフォルト値に 0000-00-00 00:00:00 みたいな値を設定することを許さないらしい。 mysql - Invalid default value for 'create_date' timestamp field - Stack Overflow

検証用に別にテーブルを用意して bundle exec rake db:setup してみたところ、以下のような構造のテーブルができた。

mysql> desc entries;
+-----------------+------------------+------+-----+---------+----------------+
| Field           | Type             | Null | Key | Default | Extra          |
+-----------------+------------------+------+-----+---------+----------------+
| id              | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)          | YES  |     | NULL    |                |
| category_id     | int(11)          | YES  |     | NULL    |                |
| slug            | varchar(255)     | YES  |     | NULL    |                |
| title           | varchar(255)     | YES  |     | NULL    |                |
| body            | text             | YES  |     | NULL    |                |
| markup          | varchar(255)     | YES  |     | NULL    |                |
| type            | varchar(50)      | NO   |     | NULL    |                |
| draft           | tinyint(1)       | YES  |     | 0       |                |
| created_at      | datetime         | YES  |     | NULL    |                |
| updated_at      | datetime         | YES  |     | NULL    |                |
| frozen_tag_list | text             | YES  |     | NULL    |                |
+-----------------+------------------+------+-----+---------+----------------+

created_atupdated_atdatetime 型になるらしい。なので以下のような ALTER 文を実行した。

mysql> alter table entries modify column created_at datetime, modify column updated_at datetime;
mysql> desc entries;
+-----------------+--------------+------+-----+---------+----------------+
| Field           | Type         | Null | Key | Default | Extra          |
+-----------------+--------------+------+-----+---------+----------------+
| id              | int(11)      | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)      | YES  |     | NULL    |                |
| category_id     | int(11)      | YES  |     | NULL    |                |
| slug            | varchar(255) | YES  |     | NULL    |                |
| title           | varchar(255) | YES  |     | NULL    |                |
| body            | text         | YES  |     | NULL    |                |
| type            | text         | NO   |     | NULL    |                |
| draft           | tinyint(1)   | YES  |     | 0       |                |
| created_at      | datetime     | YES  |     | NULL    |                |
| updated_at      | datetime     | YES  |     | NULL    |                |
| frozen_tag_list | text         | YES  |     | NULL    |                |
| markup          | varchar(255) | YES  |     | NULL    |                |
+-----------------+--------------+------+-----+---------+----------------+

これで最新のコードをデプロイしても真っ白画面になることはなくなった。以前遭遇した更新時に created_at の値が更新されてしまう問題 もフィールドの型が timestamp だったのが原因なのだと思う。SQLite から MySQL への移行は一筋縄では行かないことが分かった。

DataMapper はソースコード内の記述内容から動的に Migration を行えるけど、ActiveRecord みたいに $APP_ROOT/db/ ディレクトリに Migration ファイルを作ってくれたりしないので DB スキーマの変更が必要なことに気がつきにくい。便利だけど不便な感じがする。Rails で $APP_ROOT/db/ 以下にアホみたいにファイルが出来ていくの嫌だと思っていたけど、スキーマ変更に気がつかずコードをデプロイしてウェブアプリケーション停止みたいな自体は防げると思った。

ブログ書こうと思ってパソコン開いて「ついでに最新版の変更を取り込むか」とかやるとデプロイできなくなったりして書きたかった記事が書けず残念な感じになる。はてなブログでブログ書いてて画面が真っ白になったらひとでくんさんに不具合報告して直してもらえば良いので楽だと思う。

| @散財

指定暴力団清貧会会長なので2012年の消費活動を振り返ろうと思います。買って良かったものベスト3をご覧ください。

3位 無印良品の肌着

天然素材にこだわったぬくもりクルーネック長袖シャツ 紳士・M・杢カーキ

3年くらい前からヒートテックを着て冬を過ごしていた。しかしヒートテックは窮屈だしちくちくしていて着心地がよくなく、さらにすぐ伸びてだらだらになってしまうので正直微妙だと思っていた。今年は偶然無印良品で見かけたこの肌着が安くなっていたので試しに買ってみたら、大変暖かくて良かった。気に入ったのでもう一枚買って二枚でローテーションを組んでいる。ユニクロのヒートテックとの違いは、生地の厚みと柔らかさにある。ユニクロのヒートテックは生地が薄くて締め付けられる感覚があるけど、この無印良品の肌着は生地に厚みがあり、締め付けはゆるく、心地よく着られる。暖かさもヒートテックよりも暖かいと思う。氷点下の阿蘇でもこの肌着と厚手のラガーシャツとナイロンパーカーの三枚で外出できた。買ってよかったと思う。

2位 携帯ウォシュレット

痔瘻になって手術後とかシートン法の輪ゴムをつけてる間とか、肛門周辺が阿鼻叫喚になっているときはウォシュレットがないとつらい。自宅は古い賃貸住宅なのでウォシュレットがついてなくて、痔瘻になった後は半泣きになりながら血だらけの肛門を拭いていた。そんなときに伊藤直也さんのブログを読んで携帯ウォシュレットなるものの存在を知り、すぐさま注文した。最初は半信半疑だったんだけど、普通に使える。手で水が当たる部分を調整できる分、便器に備え付けてあるやつよりも便利かもしれない。水の強さ調節もできるし、満タン時は23秒間放水できる。ただ便器備え付けのやつと違って温水ではなく水しか出せないので冬場はつらい。でもこいつがなければ俺の肛門は崩壊してたと思う。買ってよかったと思う。

1位 ソニーの Bluetooth ヘッドホン

これは嫁さんに買ってもらった。Bluetooth なのがとてもすばらしい。ワイヤレスヘッドホン、初めて買ったけど想像以上に良かった。実は二年くらい前から Kleer という規格のヘッドホンを狙ってはいた。当時は Bluetooth は音質の劣化がひどく実用に耐えないという意見を目にすることが多かった。Kleer は Bluetooth の後継規格で、まだ普及がいまいちなため出力側に送信機をつけないといけなかった。TH-WR700 という TDK 製のを買おうかと思ったのだけど、せっかく無線のヘッドホンを導入するのに送信機を取り付けなければならないというのが気にくわなかった。Mac につないで使うのならそれでもよいかもだけど、外で iPhone で使うときにヘッドホンジャックに送信機をつけるなんてあり得ないと思った。 MDR-1RBT は Bluetooth の Version 3.0 という規格に対応していて、よく知らないんだけど音質がいいらしい。また無線接続時は再生される周波数の帯域が20Hz-20000Hzまで落ち込むらしいんだけど、Sony が開発したナントカという技術によって劣化した音質を頑張ってなかなかよいとこまで復元するらしい。どうしても Bluetooth の音質に不満がある場合は、付属のケーブルを使うことで兄弟製品の MDR-1R と同じ音質で再生できるらしい。これも良い。自分は高音難聴でどうせ8000Hz以上の音は聞こえないので自分にとっての可聴域はカバーされているし、音質面で MDR-1RBT には全く不満がない。音質重視のヘッドホンだけどマイクとかついていて、電話のヘッドセットとしても使えるし、充電が micro USB でできるのも良い。ヘッドホンがオーディオの世界に閉じこもるのやめてデジタルガジェットの方に歩み寄ってきた感がある。買ってよかったと思う。

以上、2012年買って良かったものベスト3でした。

| @技術/プログラミング

一個前の記事で書いた「記事の更新時に updated_at ではなく created_at が更新されてしまう」問題、原因はプログラム側にあるのではなく、MySQL の設定の問題だった。

mysql> desc entries;
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| Field           | Type         | Null | Key | Default             | Extra                       |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| id              | int(11)      | NO   | PRI | NULL                | auto_increment              |
| user_id         | int(11)      | YES  |     | NULL                |                             |
| category_id     | int(11)      | YES  |     | NULL                |                             |
| slug            | varchar(255) | YES  |     | NULL                |                             |
| title           | varchar(255) | YES  |     | NULL                |                             |
| body            | text         | YES  |     | NULL                |                             |
| type            | text         | NO   |     | NULL                |                             |
| draft           | tinyint(1)   | YES  |     | 0                   |                             |
| created_at      | timestamp    | NO   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| updated_at      | timestamp    | NO   |     | 0000-00-00 00:00:00 |                             |
| frozen_tag_list | text         | YES  |     | NULL                |                             |
| markup          | varchar(255) | YES  |     | NULL                |                             |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
12 rows in set (0.00 sec)

updated_atcreated_at の設定値が逆になってたのが原因。ALTER 文でカラムの情報を入れ替えておいた。

MySQL に流し込んだ Sqlite3 のデータを dump したやつの CREATE TABLE entries を見ると以下のようになってた。

CREATE TABLE `entries` (`id` integer PRIMARY KEY AUTO_INCREMENT, `user_id` integer, `category_id` integer, `slug` varchar(255), `title` varchar(255), `body` text, `type` text NOT NULL, `draft` boolean DEFAULT '0', `created_at` timestamp, `updated_at` timestamp, `frozen_tag_list` text, `markup` VARCHAR(255));

なんでこれが created_at に対して更新時に現在時間を上書きし、 updated_at は作成時のみ現在時刻が入るようになるのかは分からない。

それにしても日頃 MongoDB ばかり使っていて、データにおかしなことがあるのはほぼ間違いなくコードのせいだと思う癖がついていることが今回よくわかった。データベースのスキーマを見てみるまでに3日くらい時間がかかった。とほほ。

一方でデータベース内のデータ構造のことをあまり考えなくてよく、開発のみに集中すればよい MongoDB はやっぱり便利だなと思った。規模がでかくなったり高速な読み書きをさばかなければならない状況だと MongoDB にも色々問題があるのでしょうけどね。

| @読書

最近、蓄財意欲が高まっているので『男の本格節約術 — 5年で1000万円貯める52のノウハウ』を買って読んだ。

著者は元メガバンク勤務のエリートサラリーマンなので、「そりゃ年収1000万円以上あれば5年で1000万貯まるだろうよ」と思いながら読み始めたんだけど、中身を読んでみると読者の年収はあまり関係ない内容になっている。とにかく節約が大切だ、ということが書いてあった。

以下、気になった点の要約。


資産を形成するために

  • やること
    • 銀行口座残高と総資産残高を月次管理する
    • Excel に毎月の資産の変動を記録する
    • 毎月、資産増加額の目標を設定し、目標と実績の乖離を検証する
    • Excel でグラフを作成する
    • 毎月、手取り給料の25%を積み立てる
  • やらないこと
    • 家計簿はつけない
      週五日働いているサラリーマンが家計簿をつけることは事実上無理。
    • こづかい額は設定しない
      「使う額」のことを気にするのではなく、「貯める額」の方を気にする。貯めた上で余った金額を使う。
    • 貯金箱は使わない
      正確な月次資産把握ができなくなるので。

日々の心がけ

  • 「機会費用」、「時給換算」の概念を捨てる
    「時給に換算したら壊れたものの修理を自分でやるのはバカらしいので新しいものを買った方がよい」は間違い。壊れたものを修理するのにかかる間、職場にいるわけではないので給料は発生していない。新しいものを買えばお金が出ていくだけ。実際のキャッシュベースで考える。

ものを持たない、ローンを組まない

  • 持ち家よりも賃貸に住む
    • 住宅ローンは年収の5倍もの借金をすることであり、家計を企業に置き換えると圧倒的な債務超過に陥っている。住宅ローンを組むのは正気の沙汰ではない。
    • 不動産を買って良いのは、現金で買える場合か、10年程度の短期間で返済を終えられるかのどちらかの場合のみ。
  • 車は持たない
    • 車の維持費はガソリン代以外固定であり、年間の維持費は70万円程度になる。
    • 車を乗り換えながら30年間所有した場合、車への支出は2000万円を超える。
  • ものを買っても死ぬときはあの世に持っていくことはできない。レンタルで済むものは借りるようにする。

家庭での実践

  • 外食は休日の昼間に行う
    昼に外食することで安く上げられる。
  • 贅沢は結婚記念日や誕生日に限定して行う
  • 本や雑誌は図書館で借りて読む
    • 本は持っていても物理的に保管不能になる。必要なときに図書館へ行って借りて読むのが良い。
    • 読んだ本の中で気になった点は写経してパソコンに保存すると検索できるようになるので便利。
  • CD や DVD はレンタルを利用する
  • 保険に入りすぎない
    • 保険とギャンブルは似た性格を有している
      • どちらも確率ベースで、保険は「当たった」ときに辛い目に遭い(代わりに保険金を得る)、ギャンブルは当たったときに富を得られる。
      • ギャンブル(宝くじ)の還元率は46%だが、保険の還元率は39%と考えられている(保険会社は十分に情報を開示していない)。保険の方が宝くじよりも割りが悪い。
    • 十分な金融資産があるならば保険に入る必要は無い
      • 金融資産を積み上げるほど、保険料は引き下げられる。万が一のときには自己資産で対応できる。
      • 「家族の必要生活資金(総額)」 - 「手持ち金融資産」 = 保険金で受け取る金額 ←式に合わせて加入する保険を考える。
    • 生活に余裕が出たら、保険は見直す

職場での実践

  • 飲み会に行かない
    歓送迎会などの一次会のみに参加する。
  • 職場で飲み物を買わない
    毎日、2回喫茶店に入ると年間で 300円 * 2回 * 5日 * 52週 = 156,000円 の出費、毎日2本缶コーヒーを飲むと 120円 * 2回 * 5日 * 52週 = 62,400円 の出費。
  • 昼食代を浮かせる
    • 弁当を作ってもらえるなら弁当を持参する。
    • 社食があるなら社食で食べる。
  • 見栄を張らない
    職場に高いスーツを着ていかない、高い時計や靴を買わない。
  • 金融リテラシーを高める
    • 日本の教育は、個人の資産形成については教えてくれないため、日本人は金融リテラシーが著しく低い。
    • 『アメリカの高校生が読んでいる資産運用の教科書』のような本を読み、お金についての知識を高める。
  • 家計に企業の経営手法を応用する。
    • キャッシュフロー経営(入ってきた以上に使わない)
    • ローコストオペレーション(固定費を下げた生活を心がける)
    • 月次決算(金融資産の額を毎月確認する)
    • 見える化(金融資産のポートフォリオグラフを作成する)
    • 不稼働資産の売却(使わないもの、読まない本、聞かないCDを売る)
  • 貯蓄よりも返済を優先する
    一日も早く返済を終え、支払い金利を一円でも少なくする。

節約志向の副作用を知る

  • 節約ばかり考えていると発想の貧困化を招く。
  • 既存の枠組みの中でいかに出費を抑えるか、ということばかりに目が行き、斬新な発想をしてみようという感覚が出てこなくなる。

以下感想です。

すべての始まりは節約

本の中には英語の節約に関することわざがたくさんちりばめられている。冒頭は著者が影響を受けた『となりの億万長者—成功を生む7つの法則』の引用から始まる。昼食は毎日1,000円程度の外食で、職場では2本も3本も缶コーヒーを飲み、休憩時には喫茶店でコーヒー、仕事の後も週に1回は飲みに行く、という人は多いと思うけど、自分には到底理解しがたい金銭感覚だ。職場では基本的に無料の水しか飲まないし(ウォーターサーバーのある会社で良かった)、昼は持参した弁当か配達の激安弁当を食べる。豪華な昼ご飯を食べたり缶ジュースを何本も飲んだりするよりも、もっと他のことにお金使った方がいいと思う。こういう金銭感覚を持った自分からすると、英米の偉大な金持ちはケチだったという話には大変勇気づけられた。

貯蓄を行うための確実な方法は天引き

蓄財を行うための確実な方法は、手取り収入の25%を給料日に有無を言わさず貯金してしまうこと。後は残りのお金で生活する。こづかい額を設定しないのもこの発想に基づいている。貯蓄が一番先に来て消費は最後。貯蓄して余った分を使うという発想に切り替えないとお金は貯まらないと思った。

著者が提唱する Excel による月次の資産管理も参考になった。自分は iCompta という iPhone と Mac で同期しながら使えるソフトで家計簿を付けていたけど、レシートが溜まっていくばかりでここ一年ほど破滅状態にあり、家計簿が実体を反映していない。やはり着眼点を変えて、出ていく金額に気をかけるのではなく、貯める金額に気をかけるべきだと思った。

投資について

投資はどちらかというと損をしないために行うべきものであって、積極的に儲けようとしてはいけない、という印象を持った。例えば著者は海外赴任中に、日本の銀行の普通預金口座に数百万円預けたままにしておいたことに赴任先で気づいたそうだ。もしこれを定期預金として預けておけばより多い額の利息を得ることが出来た。このような「効率的に運用していれば得られたはずであろう利益」を損として考えるような心構えで投資や資産運用を行うべきだと感じた。『アメリカの高校生が読んでいる資産運用の教科書』は興味が湧いたので Amazon で古本を注文した。

家や車について

家について

著者は持ち家派か賃貸派かで言えば賃貸派だと言っている。しかし賃貸は支払う家賃の割りに部屋が狭くてしょぼいのが問題だと思う。例えば分譲マンションを購入して2000万円の35年ローンを組んだとき、月の住居費(ローンの返済、管理費、修繕積立金)は8万円くらいになると思う(ここで計算できます)。しかし同じマンションに賃貸で入居しようとすると家賃は12万円くらいになる。月8万円で住める賃貸住宅は狭くて設備も著しく劣っているはずだ。どうせ同じ金額(8万円)を住居費に費やすのだったら広くて快適なところに住みたい。

また賃貸は年をとってからが大変な気がする。70歳とかになって賃貸住宅に住もうとしても、入居の審査が通らないかも知れない。そもそも年金暮らしになったときに、毎月8万円も住居費に充てるのは無理な気がする。国民年金を満額収めている人でも6万6千円しか支給されないのだから、やはり定年退職する前までには住居に関する不安は払拭しておきたい。となると働けるうちに家を購入して返済を終え、老後は家賃がかからない生活を送るのがいいと思う。

本の中で著者はたばこを吸う人を刹那の快楽を得るために寿命を短くすると言っているのだけど、賃貸住宅を好む人達だって、若いときに好きな町にふらふら移り住むために高い家賃を払い、老後に困窮することを選択しているキリギリスにしか見えない。

車について

車については著者は、都市部に住んでいるなら持つ必要は無い、と言っている。車を所持することで年間で必要な維持費は70万円であると試算してある。これは駐車場代が月2万円で、200万円の車を10年乗るとして購入した場合である。車を処分するだけで年間70万円の節約になるので、車は持つべきではない、というのが著者の主張だ。

自分も福岡に引っ越してくるときに車を処分してしまった。確かに福岡市の中央区や博多区などから一歩も出ないと決意するのであれば車はいらないかも知れないけど、市内でも郊外に住んだり実家に帰省したりするときのことを考えると、車がないとなかなか厳しい。福岡は駐車場代が東京よりは安いし車を買うとしても100万円くらいのものにしようと思っているので、維持費は、当初3年間は車のローンの返済があるため年間80万円、完済後は45万円くらいになると試算している。

一方で、車を所有している場合と同じ頻度でレンタカーやタクシーを利用すると仮定した場合(月2回レンタカーを借り、月20回タクシーを利用し、電車やバスも適宜利用すると仮定)、年間の自動車費は98万程度になると予想された。これなら買ってしまった方が経済的だ、ということになる。

またレンタカーやタクシーを利用する場合、いつでも好きなときに自分のタイミングで外出する、ということが難しくなる。金曜の夜10時頃に唐突に久留米ラーメンが食べたくなってしまったとき、自動車を所有しているならマイカーに乗って久留米まで行ってしまえばいい。しかし車を持っていない場合は諦めざるを得ない。レンタカー屋はほぼ閉まっているし、タクシーで久留米まで行くことは不経済だ。電車で行けないこともないけど、ラーメンを食べ終えた頃に上り列車の終電に間に合うかは微妙なところである。

少なくとも地方都市に住んでいる限りにおいては、車があった方が圧倒的に快適な生活を送ることができるのではないかと思うがどうだろうか。

ものを持たない生活について

著者が提唱するなんでもレンタルで済ませるという生活には一理ある。大抵の本は買っても一度しか読まないし、一度しか読まない本のためにスペースを確保するのはバカらしい。また本はかさばるので捨てるとしても大変難儀する。図書館で借りられるならそうした方がいいとは思う。

しかし CD とかもレンタルで済ませろというのには違和感がある。誰も音楽買わなくなったら音楽で食ってる人達が生活できなくなる。そうしたら世に出回る音楽の種類や質も劣っていくのではないだろうか。そういう世の中はつまらない。そもそも自分が聞きたい音楽がレンタルで手に入るとは限らない。

この本全般に言えることだが、著者はファッションや音楽など、俗世への煩悩が控えめな人のようなため、主張が極端な気がする。みんなが著者と同じ価値観でものを考えられる訳ではないし、服が好きな人や、アンダーグラウンドな音楽が好きな人だっている。そういう文化的な趣味趣向は「無価値」と割り切れるのであれば、ひたすら節約生活を極めることができると思うけど、なかなか人間そうはいかない気がする。

そもそものことを言うと、みんなが何でもレンタルで済ませるようになったら、この本だって誰も買わず(買うのは全国の図書館だけ)、筆者だって困るはずだ。

家にしろ車にしろ本にしろ、「ものを買うやつは情報弱者」と言い捨てるのは気分爽快かもしれないけど、みんながそのような消費行動を取り始めると世の中お金が回らなくなってしまう。それはそれで問題だと思うんだけどな。

ともあれ冒頭の「資産残高の月次管理」の部分は参考になったので、自分も実践してみたいと思いました。とりあえず家計簿をつけることやめてたまりにたまったレシートを捨てることにします。