EPUBが論文出版のデファクトスタンダードになる日は来るか

で、一つ前のエントリでも書いたようにKindleはわりと愛用するようになったのですが、不満な点もあって、論文。論文が読みづらい。

KindleにはPDFの表示機能が組み込まれてはいるのですが、なにせ画面が小さいので、もともとA4（やレターサイズ）で表示されることを前提にしている論文だと文字が相当小さくなってしまう。ましてや2-columnの論文となるともう無理って感じです。またページ繰りもじゃっかん遅い。ユーザエクスペリエンスがまずい。拡大して読む、ということもできないし。
シリーズの中でもKindleDXだけは比較的大きいので論文とかも読みやすいのでは、という考えに基づいて私も買ったことがあるのですが、これも間違ってたなあというのが正直なところ。上に挙げた文句のうち、「画面が小さいので読みづらい」という問題が若干緩和されているだけで、ユーザエクスペリエンスがよくないといった話は全然解決していないのですね。
一方、携帯電話やタブレットで読むという選択肢もちょっとないな、と思っています。これも前のエントリに書きましたが、Kindleに慣れてしまうと、E-Inkの読みやすさというのを実感します。それに、特に携帯電話で、ページの一箇所を拡大表示で読むというのも読みやすいのかなぁというのが若干疑問だったり……。

というわけで掲題の話を、ちょっと前から思っているわけです。そもそも論文をPDFで配布する必然性って、ないよね？　EPUBとかのほうがいいんじゃないのかなあ？

PDFというフォーマットが悪いということは全然ないのだけど、PDFは「紙」とか「ページ」とかいった概念に強く依拠するフォーマットだということは言えます。だから紙に印刷して読むならとてもいいんです。いっぽう、昨今の電子書籍フォーマットでは、もはやページという概念すらなくなっている。たとえばAmazonの「なか見検索」でも、Kindle版の場合は上下になめらかにスクロールするUIになっちゃっているわけです。
そしてこの、ページという概念がないというのがキモでして、デバイスごとに違う文字サイズで表示できるし（ユーザも文字サイズをカスタマイズできるし）、デバイスごとに一画面分の文字数（単語数）がかわるということもありうる。だからどのデバイスでも読みやすいように読める。
ま、ようは、紙で印刷して読むならPDFも優れていますが、紙を使わないなら電子書籍デバイス向けのフォーマットというものがあり、そちらを使うといろいろ捗るぞ、というやつではないかと思うわけです。

でも実際問題としてどうなの、という面はあると思います。電子書籍デバイスは現状、相当の趣味人でないと持っていないものなのは確かなので、そういう人向けに頑張るというのも何かおかしい気がします。いちおうEPUBをパソコンなどで読めるソフトもありますが、電子書籍デバイスを持ってない人はそれで頑張れ、というのもいかがなものか、という気もします。だめなら印刷する、というのもありだとは思いますが、EPUBのデータを紙に印刷してPDFの品質に勝てるのか、というのは疑問です（っていうかやったことないからわからないのですが……）。
一方で、巨大な学会のproceedingsなど、昨今もはや紙に印刷するほうが珍しいのではないかという気もします。PDFの入ったデータを全員に渡しておしまいで、後日に一部だけ選んでエルゼビアから出版される、というパターンもおなじみなのではないでしょうか。私はだいぶ長いこと学会とかには行ってませんが、私が学生時代だった当時でさえ、分厚いproceedingsは定番の「忘れ物」でした。CDなりなんなりで電子データのみを配布する、というのは一般的でした。今ではそれがむしろ普通でしょう。
とすると、紙に印刷することを前提にしたPDFというフォーマットの利点は、実はそれほど大きくないのではないかという気もするのですが、どうですかね……。

技術的な話としては、latex2epubというのはとっくの昔に作られています。もちろんクオリティはわからないけど、latex2htmlはもともとあったわけですから、同程度のクオリティを目指すのは不可能ではないのかなと。となると、大学の先生におかれては、ぜひ、PDFとあわせてEPUB形式でも公開してほしいなあ、と思っているところではあるのです。もっとも、latex2htmlで論文をhtml化して公開しているのも相当の「趣味人」だけでしたから、こういう草の根運動は実を結びそうもないのかも……。
この話を同僚と話していたら、「TeXやDVIから変換したPDFはパターンがあるから、PDFからEPUBに変換できるんじゃないか」というアイディアも出ました。それはクールかもしれません。それでもいいなあ。うーむ。

いずれにせよ、学術出版の世界で電子書籍というのはもっと注目されたり実験されたりしてもおかしくないのになあ、とは思います。私のあずかり知らぬところで、きっと色々進んでいるのだろうな、と期待しつつ、様子を見ている外野の私なのでした。

電子書籍強化月間のまとめ

電子書籍で生活をするという30day challengeが完了したので、まとめます。

チャレンジの概要
スタート時にこちらにまとめました。紙の本を一切読まず、それに充てていた時間を電子書籍に使うというものです。まんがや雑誌も「紙の本」に含まれる、また紙で売られた本をスキャン(いわゆる自炊)したものは電子書籍には含まない、といったレギュレーションを課しました。ちなみに所有している電子書籍デバイスはAmazon Kindleのみです。Androidデバイスは持っているので、それをサポートする環境はいちおう使えるのですが、E-Ink以外で読むのは抵抗感があり、使っていません。

読んだ本

• Charles Yu: how to live safely in a science fictional universe
• 可知豊: 知る、読む、使う！ オープンソースライセンス
• ケヴィン・ケリー / 堺屋七左衛門(訳): ケヴィン・ケリー著作選集　１
• Fantasy and Science fiction magazine 2012 Jan/Feb
• Beautiful Data: The Stories Behind Elegant Data Solutions (一部の章のみ)
• Kristina Chodorow / 夏目大(訳): スケーリングMongoDB
• yomoyomo: 情報共有の未来
• Kelly Link: Pretty Monsters (途中まで)

実態はどうだったか？
読書時間は平日はあまり多く取ることができておらず、これもこれでなんとかしないといけないなあと思うわけですが、この辺の改善は行わないまま、今回のチャレンジを始めてしまいました。結果的に読書時間はそれほどかわらず、大して分量を読めないままだったという現状認識が、まずあります。
とはいえ、リストしてみると意外と冊数があります。私は普段の読書量だと、月間で4-5冊といったところだったと思うので、一見するとそれよりは多いですね。とはいえ、日本語の本はどれもかなり短いものが多いので、あまりたくさん読めたという気がしません。英語の本はさすがに読むスピードも遅いし。長編は実質的には1冊、Charles Yuの本しか読んでない。Kelly LinkのPretty Monstersは短篇集、F&SF誌も中編が6本とか入っているので分量もあり、短編はちょっと体力を使うというのを実感しました。

まんがについては、余力があればウェブ雑誌を探してみたりしてもいいかなと思ったのですが、他の本だけでも十分に読むものは多かったので、けっきょく挑戦に至りませんでした。単行本も買っていません。ただし、単行本については前提として、電子書籍は刊行から数ヶ月遅れてやってくることが多い、という事情もあるような気がします。興味のあるまんがはだいたい新刊で買っているので……。

感想と今後
30day challengeは、二通りのパターンがあると思います。第一には生活スタイルを変えるというパターン。毎日自転車で会社に通う生活をしてみる、というチャレンジですね。こういうチャレンジの場合、期待される効果としては、生活スタイルが変わり、今後も毎日ではないにせよ自転車出勤生活を続ける、というものになります。
一方で、30日で小説を書き上げる、みたいに、新しいことを挑戦してみるだけでその後も続けるとも限らないタイプのチャレンジもあるとおもいます。この場合は、ひとつ何かを成し遂げるというものですね。
今回の件についてはその辺の認識が中途半端なまま始めてしまったという反省点があります。とりあえずお試しで電子書籍に注力してみたものの、今後も電子書籍のみの生活ができるかというと、まあできないだろうなと思いながら始めていたのです。かといって、何かを成し遂げるというようなタイプのものでもないし。

しかし、ひとまずのところ、電子書籍のみでの生活というのはどうかというと、なくはない、といったところだと思いました。とくに英語で本を読むならほぼ支障はないと思いました（新刊が即Kindle化されるとも限らないし、すべてがKindle化されるわけでもないので、今後の電子書籍ライフではそのへんも気に掛かるところですが）。一方、和書はまだバリエーションが少ないため、完全移行は難しいと言わざるを得ないと思いました。したがって、翻訳書から徐々に電子書籍に移行していくという当初の想定通りの流れになりそうな気がします。
問題はむしろ、紙の書籍と電子書籍のバランスをどうするか、という点にあります。正直わたしも紙の本という物体への愛着は薄い方なので、紙の本は可能な限り回避したいという意識があります。またそれは今回のチャレンジでかなりはっきりしてきました。今所持している本の処分を進め、また新しく購入するのは控えめになるのではないか、と思っています。

ただ問題はまんがでして、まんがはそれ以外の書籍よりはるかに権利関係が厳しく、電子書籍化があまり期待できません（確かに、下手に弱い制限で販売して一番海賊版などが出回りやすいのはまんがだろう、という悲しい現実は理解できます）。スキャンも明白に禁止している出版社や作家が多いので、こうなるとなるべく買わないか、買っても読んだら捨てるというオプションを取るしかなくなってしまっています。まんがとどうつきあうか、というのはもう少し様子を見て考えたいと思っています。

紙の本のスキャンについて
ところで、自分で紙の本を買ってスキャンするのは、過渡期の技術としてアリかなあと思っていたのですが、なんというか、わりとどうでもいいような気がしてきました。自宅に累積した本には何らかの手段で電子化してでも保存したいものがあるため、スキャン自体は、ある程度は継続をするつもりです。ですが、持っている本の大部分は処分しても問題ない気がしますし、新しい本を買って電子化して読むというのはあまり私の生活スタイルには合わないと思いました。
スキャンした本というのは、ようするにページの画像データのことですが、電子書籍デバイスで読むのはあまりおすすめできるユーザ体験ではないと思います（Kindleの画像表示能力がそんなに高くないという個別事情もあります。解像度の調整をしないと相当読みづらい）。紙の本として購入したものを、あえて労力を費やして電子化してから読むというのはメリットが薄いと思いました。そのまま紙の本として読むほうがなんぼかよろしい。まあ、分厚い本であれば、持ち歩きやすいという利点があるかな、とは思いますが……。
とはいえ、上でも書いたように、今ここにある本の山のうち、いくらかを電子化して保存するという行為については否定的ではありません。後から参照し、必要な箇所だけ読むという面では、電子化することの利点もそれなりにありそうです。ただ現状、縦書きの書籍のOCRの精度は全然よくないものが多い気がするので、本によっては「後から検索したい」という欲求は満たしづらい場合もあります。

電子書籍デバイスについて
上にも書いたように、今回は電子書籍デバイスとしてはAmazon Kindleのみを所持という状態でスタートしました。チャレンジをはじめる前に事前調査をもっとすべきだったとあとで思いましたが、現在の日本の電子書籍サイトでKindleというのはまったく役に立たないデバイスとなっています。基本的にはSony Reader、PC向けにWindows、タブレットならiOS、という環境のサポートが主になっていて、Kindle、Mac、Androidな私はまるで手がでない(笑)。AndroidやMacのサポートはまれにあるのですが、品揃えの問題と、発光する画面で本を読むというのはちょっとありえないという考えから、まったく頼むことはありませんでした。上に挙げた日本語の本は、どれもEPub形式で購入しています。もっともKindleはEPubも表示できないので、Calibreで変換しています。
Kindle自体は私はとても好きなデバイスなのですが、実際問題として日本でもKindleが支配的であるべきだとも思いません。楽天が買収したKoboが日本に来るという話もあり、これもこれで期待しているところです。結局のところ品揃えの多寡で決まる面が大きいと思うので、いい品揃えであればデバイスには強いこだわりは、私には今のところないのです。
ただやはり、E-Inkは必須だと思いました。発光するデバイスで本を読むのは正直しんどいです。またKindleは圧倒的に軽い、という利点もあります。実際、私もいっときAndroidタブレットを入手したときにはKindle終わったな、と思ったのですが実態は全く逆でした。重量には大きな意味があります。軽くて読みやすい、という利点を他のデバイスがどう乗り越えるか、というのが要点だなと思っています。

コンテキストスイッチ力

最近、社内で関わるプロジェクトが移り、当然と言えば当然だが生産性が低下している。ついでに、長いビルドの暇な時間に、プログラマの生産性ってなんだろうな、ってなことをぼんやり考えたりしている。
スーパーエンジニアは凡百なエンジニアの数十倍とか数百倍という生産性があるという。数十倍かはわからないけど確かにものすごく生産性の高いエンジニアというのはいる。いるのだけど、何故彼らは生産性が高いのか。っていうか、そもそも生産性、ってなんだろう。

一般的にプログラマの生産性というとコーディングスキルだと思われている気がする。だけど、それだけなんだろうか。そりゃ優れたコードを書くのは才能だし、スピードも才能で、ぼくにはそんなものはない。ただ、言語も開発環境も大同小異なプロジェクトのメンバー同士でも、かなり生産性には差がある。この差がコーディング能力だけでつくとはとても思えない。

高林さんの文章で、プログラマの生産性についての考察があった。いちいちうなずくこと然り。レスポンスが異常に速いとか、フットワークが軽いとか、終わらせるとか……。と読みながら、ひとつ付け加えることがあるとすれば "コンテキストスイッチ力" があるんじゃないかと思った。コンテキストスイッチのコストが低い人は総じて生産性が高い。

プログラマの仕事というのは、意外と待ちの時間があるものだ。ビルドに費やしている時間、データをダウンロードしたりアップロードしたりする時間。解析プログラムが巨大なデータを処理している待ち時間。レビューやメールの返事待ち。その他もろもろ。
そういう細かい空き時間をどう使うかというのは生産性に大きく寄与している。複数の作業を効率良く並列に進められるか。関連するコードを読んでみたり、論文に軽く目を通してみたり、メールの処理時間に使ったりもできる。
私はコンテキストスイッチのコストが高めなので、ビルドのログが流れていくのを眺めながら、比較的どうでもいいこと（プログラマの生産性ってなんなのか、みたいなこと）をあれこれ考えたりしてしまう。
ビルド中にメールでも書こうか、とメールの画面に移って、書いていたら意外と手間取ってしまって送信してほっと一息ついたら実はとっくの昔にビルドが終わってて、本当はその後にテストを実行させないといけなかったのだが……みたいなあるあるネタを実際にやっちまったりして。……あるよね？

コンテキストスイッチのコストはどうやったら下げられるのだろう。

そんなことが分かっていたら、こんな文章を書いているはずがないので（笑）、私にもよくわからない。だがひとつ仮説として考えているのは、自分の作業フローを見通す能力なのではないかということだ。今からメールの返事を書くのにどれぐらいの時間がかかるのか。ビルドはどれぐらいの時間で終わって、その間にできることは何か。作業時間の予測とか、比較的短いスパンで何ができて何をどの順番でやるか、というのを把握していれば、テンポよく作業を進めることもできる。
レスポンスが速いというのもそういうことだ。メールやチャットで連絡が来たときにプライオリティ付けがきちんとできないと、連絡したのにいつまでも返信ができない。逆に、チャットで相談に乗っていてひととおり解決したところでさっきまで何をしてたっけ……とならずにすぐ復帰できる人は生産性が高いし、自分はすぐ復帰できるからこそ連絡にきめ細かく対応できる。
また、こういう知識や優先順位づけは一般化しづらく、プロジェクトやチームによっても往々にして変わるから、プロジェクトが変わると生産性がいったん落ちたりするのだと思う。

プログラマの界隈ではよく「フローに入る」という表現がある。それがどういう意味なのか正確に把握している自信はないけど、少なくともコンテキストスイッチをよしとしないということだ。人間、コンテキストスイッチのコストは決してゼロにはならないので、それを減らして作業に集中するというのもひとつの作戦だ。だけど、それが全てでもないのでは、と思う今日この頃。
たぶんきっと、このへんはプロジェクトの性質にも関わっている。ビルドにどれぐらいの時間がかかり、テストの実行やレビューや各種のプロセスがどうであるか、というのにもよる。個人プロジェクトに近いものほどフローが重視され、大きなプロジェクトではコンテキストスイッチは避けられないものとして対峙する必要があるのかも。

いずれにしても、コードを書くパワーだけが生産性ではない。だけど何しろコードを書いて生活しているように思っているので、そこを頑張ってしまいがちなのではないか、とちょっと思っている今日この頃です。

テキストフォーマットからの脱却

ありのさんにPowerShellの話の要望を出したら運良く書いていただいたのだが、これが面白い。
私のざっくりとした把握では、PowerShellではテキストだけじゃなくてオブジェクトも直接パイプを使って受け渡しできるみたいなシステムだったかと思うけど、やっぱしそういうのは面白いなと思う。興味はあるけどWindowsはもうずっと使ってないからなぁ。

似たようなことを考える人は、たぶんほかにもいて、たとえばTermKitはJSオブジェクトを受け渡すような感じになっているし、きっと似たようなことを考えて、UNIXな世界に持ち込もうとした人はほかにもいたのだと思うが、今のところ全滅な気がする。

しかし、なんでUNIX系のシステムではこういう考え方が普及しないのか。
個人的には、UNIXの世界の根底に流れる思想がテキスト志向だからだと思う。もともとUNIXの開発の名目は文書処理システムだった、といった神話があるが、真偽はさておき、UNIX系システムには共通のフォーマットというものがない。データは基本的には行志向のhuman-readableな文字列で、それぞれのプロセスがそれぞれなりに文字列処理をするという文化になっている。そんななかで成長してきた便利ツールも、ファイルも、そういった文化を受け継いでいる。単純な空白区切りやタブ区切りでも、よっぽど変な場合を除いてはだいたいうまく動くし問題ないわけ。
そして、その文化を反映するようにUNIXではテキスト処理のツールというのがものすごく充実している。catやheadやtailを使って人間が目で見て、簡単なエディタ(ed/sed/vi)でちょちょっといじれて、cutやheadやtailやuniqやsortやgrepで処理できる世界がもうそこに展開されている。たとえばちょうど偶然nokunoさんがテキスト処理用のUNIXコマンドまとめという記事を書いているが、これがまさにUNIXなのだと思う。
日付の処理も、dateコマンドとexprで頑張る変態テクニックが、きっと探せば出てきて、それがきっとUNIX wayなのだ。

そんな世界をPowerShellみたいな世界観にもっていくのは大変だ。できるのはほぼ同じ事なうえに、過去の資産を生かせない。ここでいう過去の資産ってのは別に各種ツールの実装の問題だけじゃなくて、今まで持っていたデータファイルなども含まれる。こういったものをうまく扱えるようにしつつ、過去の資産と比べて実利がなければうまくいかないし、UNIXの世界はよく言えば自由、悪く言えばカオスなので、オブジェクトの形式を揃えるなんて夢のまた夢だろう。
psやtopのようなコマンドを簡単に処理できればいかに楽かと思う時もあるのだけど、そういうのはperlとかpythonとかrubyとかで、直接APIを叩くほうがいいってことになってしまう。

実際、こういうツールの代わりに、irbを立ち上げっぱなしにして、何かあったらrubyを使うという人はわりといると思う。
それはまぁ、合理的な選択でもある。

PowerShellでなんでああいうことができたのかというと、まず .NET 環境というものがあるWindowsだからだったのだと思うし、UNIXとは「文化がちがーう」という奴なのでこれはまあ仕方ないというしかない。だけど、こういうテクノロジーの可能性を見るのはとても面白いなーと。

甘酒づくり

去年唐突にやってみた甘酒づくりを今年もたまにやっています。
麹から作る甘酒は、自然な甘さがあって美味。初詣などで買える甘酒は酒粕から作ったものであることが多いのですが、これは文字通り別物というか、別種の飲み物といったほうがいい感じ。お酒のような匂いもなく、ただ甘いのです。

甘酒の作り方は、検索するといっぱい出てくるのですが、私の場合はだいたい以下のとおり。
まず、麹をどこかから入手します。スーパーで売ってるとのことですが、私の場合、近くを適当に見て回ったら見当たらなかったので、けっきょくamazonで買いました。分量はそんなに多くなくても大丈夫。

米の分量ですが、この時は半カップほどでした。これで完成後の分量は、お椀に2−3杯分できます。普通の紙コップで飲むなら4-5杯分ぐらい？けっこうな量ができます。
あと、麹もほぼ同量用意します。麹の量は、米と同量だとかなり甘くなって贅沢な雰囲気になるというのですが、ぼくや皆さんの場合、どうせそのために麹を買ったのだし、盛大に使いましょう。
ともあれ、用意した麹は水につけておきます。ぬるま湯（20-30度ぐらい）にするといいという話もあります。

米の方は、おかゆにします。おかゆは炊飯器でもできますが、ここでは鍋で作っています。鍋に米と3倍の量の水を足して、中弱火ぐらいで温め始めて、沸騰する頃に弱火にしていきます。頻繁にしゃもじなどでかき混ぜてやらないと底に焦げ付くことがあるので注意。まあ、鍋で作るおかゆの作り方も、ネットを探せばいっぱい出てきます。

おかゆが完成したら、まず冷ます必要があります。完成直後のおかゆは熱すぎるので、そのままでは麹が澱粉を分解して糖になる反応ができません。要するに全然甘くならないわけです。甘酒づくりの好適温度は50-60度と言われています。
もちろん厳密である必要はないので温度計で図るほどでもなくて、私は適当にやっています。小指を突っ込んでみて、我慢はできるけどちょっとつらいというレベルですね。お風呂よりはかなり熱いけど、すぐ引っ込めたくなるほどでもないというか……。
ともあれ、放置しているだけではおかゆはなかなか冷めないので、適宜水を足したりして温度を調整します。この辺は適当で大丈夫。
温度が適温になったら、先程水につけておいた麹をそのまま投入し、全体的によく混ぜます。
混ぜ終わったら保温します。甘酒を作るのはだいたい6-8時間ぐらい、簡単に言うと一晩ぐらいかかりますから、そのまま放置すると冷めてしまいます。冷めてしまうと好適温度から外れて甘くはなりません。

保温の方法は、炊飯器を使う方法や、こたつを使う方法などいろいろありますが、私のオススメは湯たんぽを使う方法です。湯たんぽをあらかじめあたためておいて、その上に鍋を置きます。
この状態で、保温のためにさらに周囲をタオルでぐるぐる巻きにしておけば、それほど熱が逃げることもありません。
これを作ったのは夜中だったので、ここまでできたらひとまずオヤスミナサイ、また明日〜。

で、一晩して出来たのが右の写真。見た目はあんまり変わっていませんが、これで完成です。
ただ、一晩放置しておくと、さすがにけっこう冷めてしまっているので、そのまま飲んでもそんなに甘みを感じません。なので、火にかけてあたためてから飲みます。火にかけるのは、混入した雑菌を除く意味もあるようで、放置すると酸っぱくなるという話も見かけました。

完成した甘酒は、コップとかだと米粒が残ってしまうので、私はお椀でいただいています。
今回のはなんだかものすごく甘かった！　でもそれが美味しい。とてもいい出来でした。「酒」といいつつお酒らしさは微塵も感じられません。
ところで、甘酒は砂糖は使いません。米をおかゆにするときにできる澱粉を麹の力で分解して糖分にする、というのをやるわけです（この糖分をさらに分解してアルコールにするとお酒ができるわけですね）。
もっとも、自分で作ったものは何でも美味しい気がしてしまうものなので、何ごとも割り引いて考える必要はあります。でもやはり、自分で作るこういうものは美味しいし、何より楽しいなあという感じ。

ところで、これまで私は甘酒ってのは、麹が澱粉を分解して糖分を作るのだと思っていたのですが、実はちがうんだそうで、麹の好適温度は20-30度ぐらい。50-60度は全然快適な温度ではなく、コウジカビは死滅してしまうんだそうです。
じゃあ何が起きているのかというと、コウジカビがつくっていた酵素が澱粉を分解して糖にする、その酵素の好適温度が50-60度だというのですね。麹を水につけて戻してるときに「ぬるま湯だといい」というのは、コウジカビの好適温度にしてみて生育させつつ酵素を増やしたいのかな、という気がしていますよく知らんけど。

というわけで甘酒づくり、いかがでしょうか。時間はかかるけど作業自体はたいしたことはないので（おかゆを作って麹を入れて保温するだけですからね）、ぜひ皆さんもどぞー。

財布のない生活への挑戦

年始にライフハック：分厚くて邪魔なサイフを薄くする方法 - Radium Softwareという記事を読んだ。財布から余計なものを省きたいと前から思っていたというのと、Google+で紹介したところ知人で似たようなことをやっている人がいるということ、あと私がKZR氏のファンだということ（笑）もあり、試してみることにした。

で、結論を先に書いちゃうと、全面的な撤廃には失敗。

まずは書いてあるように財布を撤廃して紙幣数枚と日常使うと思われるカード類、小銭を適宜ポケットに入れていたのだが、いろいろ問題が出てきた。

• 小銭はポケットに雑然と入れているとごちゃごちゃになって取り出せなくなる。いきおい、支払いは紙幣で済ませてしまい、小銭がたまる。
• 紙幣も雑然としており、複数種類が入り交じってしまい、支払い時にいろいろ滞りがちになる。紙幣はしわくちゃになったり、下手をするとちょっと破れたりした。
• カード類もどれがどれかわからなくなる。束ねる必要はある。また、日常あまり使わないカード類は家に置いておいたのだが、たまに使うパターンで難儀することもあった。

小銭を収容しつつ紙幣もカードも全部入れられる財布というのは、やっぱりそれなりの歴史を経てああいう形態になっているのだなあと思ったのだった。もちろんその人のライフスタイルにもよるし、紙幣がしわくちゃになるとかそういうものは、ポケットに何を入れているかとかポケットに手を突っ込んで歩いたりするかどうかとかいったその人の日常行動の影響が強いと思う。

いずれにせよKZR氏の場合はうまくいったのだろうが、自分の場合はあまりうまく行かなかった。結局3日かそこらで音を上げた。

ただ、だからといって必ずしも財布を使う必要はない。自分が直面した問題ってのは、何らかの意味での収容用具はやっぱ必要だった、ってことだし。せっかくなので財布生活に戻るのも癪だ。というわけで、別な手段を検討した。

小銭:

財布でなくてもいいが、なんらかのかたちで小銭入れは必要だと思った。というわけで、写真にあるような小銭入れをハンズで買った。ただ、ポケットに入れるわけじゃなくてかばんに入れて持ち歩くことにした。かばんから出すのが億劫なシチュエーションでは紙幣で支払いを済ませて、つり銭はポケットに入れておき、帰宅してから小銭の整理をする。時間と心に余裕があれば小銭入れからの支払いもする、って感じ。

紙幣:

小銭入れと同時にマネークリップも購入した。専用のマネークリップも同じくハンズでいろいろあるが、それなりの金額はかかる。今使っているのは、やっぱり写真に写っているやつ。本当は、カードホルダーと一体化しているものというのもあって、それが良いかと買ってみたのだが、それなりにかさばるので買い直した。

ところで、マネークリップって必要？　もっと安いクリップとか、輪ゴムとかでいいんじゃない？　という気もする。まあ輪ゴムでもいいかもしれないけど、取り回しは不便かも。100円ショップで売ってるような安いやつでも何の問題もないと思うが、丈夫さが大事なので壊れやすいやつにはしないように。ポケットの中でするっと抜けちゃったら意味ないので。

カード類:

比較的よく使いそうなカード（ようはSuicaとか）はポケットに入れて持ち歩きたい。だけども、そういうカードはそう多くないので、これは輪ゴムで束ねて適当にポケットに入れることにした。輪ゴムはやはり取り回しが若干面倒臭いかも。Suicaなら束のまま置けばいいので楽だけども。

このスタイルで1週間ほど生活してみたが、案外と悪くない感じなので、しばらくこれで行きたいと思う。紙幣やカード類はどうにかなると思うが、どうしたって何らかの意味での小銭入れは必要だと思ったな。

さて、普段ポケットに入れられないカード類をどうするかということなのだが、これは今でも家に積み上がっていて、どうしたもんかと悩んでいる。封筒を買ってつっこもうかと思ったのだが、これもすぐ何が何やらわからなくなりそうだし……。「そんなにあれこれ使うの？」という指摘はごもっともなのだけど、私は趣味でロッククライミングのジムに行くわけですが、すくなくともジムごとの会員証が必要。で、今日はここに行く日だからこれを持って……とかやるのは案外煩雑だということがわかったのでした。

という話をしていたら、同僚が名刺バインダーにカードを入れるというライフハックを紹介していたので、これも試してみようかと思います。