watermint.org - Takayuki Okazaki's note

考えるためのツール選び (ノートからカードへ)

ちょうど使っていたノートの残りページが少なくなってきたタイミングで、書籍「知的生産の技術」を読んだことが影響して、使うノートをカード(断裁紙)に変えてみることにしました。知的生産の技術は初版が1969年と約50年ほどまえの内容ですが、今回は加えてパソコンやスマートフォンをつかったデジタル端末と連携した使い方を整理してみます。

モレスキン

カードとは

本エントリーでいうカードとは、特別なものではなくノートのように綴られていない1枚一枚ばらばらの紙(断裁紙)のことです。「知的生産の技術」ではB6サイズで、やや厚みのある紙(105kg)、9mmの罫線がはいったものが紹介されています。これは「京大式カード」としていまでも文具店で売られています。今回はいくつか検討した結果A5サイズ、5mmドット方眼を使うことにしました。

このような紙の片面だけに内容を書きます。ややもったいない気がしますが、両面は使いません。カードの使い方や、カードにつかう紙については後述します。

なぜカードにするか

2008年頃からノートは[ミドリのMDノート(http://www.midori-japan.co.jp/md/)というのを使っていました。サイズはA5のものを主に使っています。

MDノート

素朴なデザイン、クリーム色がかった紙、万年筆で書いたときも気持ちが良いなどいくつか気に入る要素があったのがこの8年ほど使い続けていた理由です。ノートは主に議事メモや計算、思考実験などいろいろな用途に使っていました。ただ近年、いくつか不便だと感じるところも増えてきました。

「知的生産の技術」にもいくつかノートよりもカードの方が優れている点が紹介されていますが、読みながら自分で気付いた理由を以下にご紹介します。

前ページに書いた内容を振り返りながら考えるのが面倒

考え中、まとめ中の内容を前ページと何度も往復しながら進めるのはかなり面倒です。できれば10ページ分ぐらいの情報量を一覧して考えたいのに、何度もページをめくらないといけないので考えが中断されてしまうのがもどかしいところでした。

特に多かったのはアプリケーションの設計をしているときにあるページにはデプロイ図、あるページにはクラス図、あるページには重要な処理のシーケンスなどを描いていたとしてこれらが一度に参照できないと一貫性があるかどうか確認できないといったケースです。

対策としてよりA4/A3サイズとか、大きめの画用紙を用意するなど紙を大きくすることで一部解消していましたが、保管する際にサイズが違うと扱いに困ったり、必要なときに大きな紙が手元にないなど完全な解消とは言えませんでした。

カードであれば机いっぱいにカードを広げてあれこれ比較しながら考えることができます。ちなみに、カードの両面を使ってしまうとこのように広げて比較するときに結局ぺらぺらめくりながらとなるのでノートで味わった不便さを引き継いでしまいます。もったいないですが贅沢にカードを片面だけを利用します。

不必要な情報を持ち歩きたくないときに困る

特に仕事上のメモが入ったノートをどう取り扱うかは悩ましいところです。パソコンやモバイルデバイスであれば暗号化やパスコードロック、遠隔から削除するなどいくつも防御手段があるので安全ですが、紙媒体ではどこかに置き忘れてしまうとどうにもなりません。

このため、仕事で使うノートは基本的に会社の机や棚に入れて施錠しておくことになります。用途ごとなどでノートを分離しすぎると持ち歩きや管理が面倒なのでできれば一冊にまとめたいのですが、会社のセキュリティーレベルで保管しておきたいのであれば分離するしかありません。

仕事用ノートには仕事上のメモだけではなく読書備忘録などを記録することもあるのですが、読書備忘録だけ持ち帰りたくてもやぶってもって帰るわけにも行かないのでやむなく持ち帰らないという選択をするしかありませんでした。

カードであれば行き先と用事にあわせて取捨選択できるのでこういった悩みがなくなります。仕事用カードは仕事場に施錠しておいておき、残りの読書備忘録や旅行メモなどはいつでも好きなように持ち歩けます。ささいな悩みもチリも積もれば大きなストレスになるのでカードの利用は大きな安心感があります。

スキャンしづらい

ノートは物理的に保管スペースもとるのと、持ち歩かないと参照できないのでやや不便です。 先月読んだ本から思いついたアイデアって何だったっけ? といった振り返りができないのではせっかくメモしても役に立ちません。こういうデータはDropboxなどクラウド上に保存して持ち歩きたいのでスキャンしています。

スキャンするのに1ページ、2ページ程度をスキャンするのはノートでも簡単ですが複数ページとなると面倒です。断裁紙であればScanSnapなどのスキャナで連続してスムースにスキャンできるのでデジタル化の手間が省けます。なお断裁紙でもパンチ穴があると穴にひっかかってうまく紙が送られないということもあるので穴をあけずに使います。

カードの使い方

カードの使い方は「知的生産の技術」に紹介されている内容をほぼ踏襲しています。次のようなことを心がけて使います。以下のような使い方を心がけているのはメモや考えを再利用しやすくするためです。

1枚に1件のトピックのみ書く

慣れるまで抵抗感がありますが、余白があっても別のトピックであれば別の紙に書きます。これは自分のまとめた情報を取捨選択したり並び替えたりして新しくアイデアをまとめていくことを重視するためです。

カードの片面のみ使う

いくつかのカードを一覧にして比較検討したいので両面使ってしまうと煩雑になります。また、異なるセキュリティーレベル(仕事用と個人用)の情報が混じったりすると管理が煩雑になるのでカードは片面だけを利用します。

カードにはなるべく文章で書く

ある程度時間が経つと自分で書いた文章でもメモの意味がわからなくなり、メモの意味がなくなってしまうといったことがあります。 議事録など議事進行に合わせてある程度速記的に書いたものは新たなカードに文章としてまとめなおしておきます。

ただ、「知的生産の技術」が書かれた時代(初版1969年)と違い現在ではパソコンやスマートフォンなどを用いて手書きよりも効率良く長文を書くことができますので、かなり長文になるようであれば迷わずパソコンを使ったほうがいいでしょう。 議事録であれば参加者などに共有する場合に手書きより電子データの方が便利です。紙に書いたメモと電子的に書いたメモをどう管理するかについてはまた別の機会に書くことにします。

日付(年月日)とタイトルを書く

カードがある程度たまって整理するときに日付やタイトルがないと内容の判断が面倒になります。いま考えようとしているトピックと関連があるのかないのか簡単に判断できるよう、面倒でも必ず記入しておいたほうがいいでしょう。また同じトピックについて複数枚ある場合は連番を振っておくべきです。

「知的生産の技術」にも書かれていましたが、日付については月日だけでなく年も書いておくべきです。個人的にも3〜4年前からは年も含めて書いていますが、年を記入していなかったときのメモは再利用するのに苦労します。特に時系列にそって整理し直そうとすると大変です。

日付についての書き方はいろいろありますが、個人的にはISO 8601の拡張形式 YYYY-MM-DDを使っています。これはある程度好みの問題ですが個人的には下記のような理由でYYYY-MM-DDにしています。

  • YYYYMMDDのように区切りがない場合は判読しづらい。
  • YYYY年MM月DD日や平成YY年MM月DD日のように漢字や和暦を使ってもよいが、手書きのときには面倒。
  • スキャンしたカードのファイル名も合わせたいが、YYYY.MM.DDのようなドット区切では一部ソフトウエアでうまく扱えないことがある。ハイフン区切りでは問題が起きにくい。
  • May 1st, 2016のように英語表記では電子化したときのファイル名を使った時系列のソートが面倒。

カードに使う紙を選ぶ

カードに使う紙をどれにするかあれこれ考えました。文具好きにはたまらない時間です。単に趣味の選択というほかに、カードとして利用するためにいくつか条件を考えました。

調達しやすさ

整理して再利用していくため、または記録を資産として残していくために利用したいので10、20年と長期的に販売されているものを選びたいものです。そのほかに、出先で紙が足りなくなって追加で手に入れられないというのももどかしいですから調達しやすさは重要な評価ポイントです。

厚さや紙質は多少変わっても構わないのですが、サイズがばらばらになると扱いづらくなるので調達しやすいサイズの紙を選ぶことにします。モレスキンのラージサイズ(A5より少しスリムな130x210mm)は持ち運ぶときに絶妙なサイズでとても魅力的だったのですが、断裁紙の状態で販売されているのをみつけることができなかったので断念しました。

「知的生産の技術」でふれられているB6サイズの京大式カードは都内の文具店を何店舗か回ってみたところ、きちんと数えていませんが2〜3割程度の店舗でおいているような印象がありました。

takeopaperのようなさまざまなサンプルから好みのサイズにカットして納品してもらえるようなサービスもあります。このため必ずしも標準サイズにこだわる必要はありませんが収納文具など周辺をととのえることまで考えれば標準サイズのほうがより手軽です。

どのサイズにするか

調達しやすいサイズとなると必然的にA4、A5、A6、B5、B6サイズなどの標準的な断裁紙を選ぶことになります。標準サイズを使えばクリアフォルダーやファイルなど収納文具も無理なく使えるので効率的です。

京大式カードのようにB6サイズは野外など立った状態でも使うことを想定して小さすぎず大きすぎずという選び方に適しています。

一方、いま野外など立った状態でメモするのであればスマートフォンを使うのが最も手っ取り早く、煩わしさがありません。このため、野外などで軽くメモをしたいという用途は縮小し、デスク上で使うことを主な利用シーンと想定しました。

このためB6サイズ(128x182mm)よりやや大きいA5サイズ(148x210mm)を使うことにしました。もともと使っていたMDノートもA5を最もよく使っていたので使い慣れているということもあります。

紙選び

まず、ちょうど紙選びをしていたときに日本橋三越の世界の万年筆祭という催事に神戸派計画というブランドが出店していたのでのぞいてきました。GRAPHILOという万年筆用紙が展示されており、試し書きもさせていただきました。ちょうどA5サイズの断裁紙もおいていたので、横に置いてあったLiscio-1と合わせて買ってきました。

Liscio-1とGRAPHILO

価格はLiscio-1が100枚で800円(税抜)、GRAPHILOが50枚で800円(税抜)とGRAPHILOはかなり高級感があります。厚みや重さなど詳しく書いていないのでわかりませんが、目測では厚みはどちらもほぼ同じで、おそらくモレスキンやMDノートなどともさほど大きな変わりはないかと思います。

後から知ったことですが残念ながらLiscio-1は在庫限りのようで今後はGRAPHILOに統一されていくようです。どちらも100枚ずつ使ってみた時点の好みでは、Liscio-1のほうが好みだったのでこれは残念でした。GRAPHILOは非常になめらかで気持ちいいのですが、すこしざらつきがあったほうが個人的には書きやすいと感じたためです。

次に試したのがMDノートを出しているミドリからMDノートの断裁紙版、MD用紙A5 100枚パックです。こちらはオンラインストア限定で売られていますが100枚で400円(税抜)と神戸派計画と比べてもかなり手ごろです。MDノートだと176ページ(88枚)で800円程度ですからノートと比べるとさらにお得感があります。

MD用紙

MD用紙がいつまで手に入るかはわかりませんが、ひとまず今回の紙選びではMD用紙をメインにすることにしました。

持ち運び

ノートのように表紙がないと紙がぐちゃぐちゃになってしまうので持ち運び用の工夫が必要です。最初はA5サイズのプラスチック下敷き2枚でサンドイッチにすればよいかと考えていましたが、実際に文具店でプラスチック下敷きをみてみると比較的やわらかいものがおおいのでカッティングマットを使うことにしました。

カッティングマットでサンドイッチ

カッティングマットだと硬さも申し分なく、適度にしっとりと手になじむのが好印象です。このカッティングマットをゴムバンドでとめて持ち歩いています。十分に硬いので、クリップボードを使うように立ち姿勢でメモを取ることもできます。

ドット方眼

方眼の大きさや濃さなどかなり好みの分かれるところだと思います。モレスキンの方眼は個人的には方眼が濃すぎるので好みではありません。MDノートの方眼は適度に薄く、あまり主張しないので長年気に入って使っています。

罫線のいれかたも、端から端までびっしり線がかかれているのはあまり好みではありません。厳密に書かなければいけないという印象があるからかもしれません。

MDノートがイメージしている原稿用紙のマス目ようにひとマスごとわずかに隙間が空いているほうが圧迫感を感じないので書きやすく感じます。

最初、断裁紙を探す際も好みの方眼のはいったA5サイズものを探していましたが全く見つかりませんでした。このため方眼についてはあきらめて、無地の断裁紙を買った上で自宅のプリンターで印刷することにしました。

個人的には5mm方眼でぱっと判別できるかどうかぎりぎりぐらい薄い方眼が好みです。印字するときも薄ければインクをあまり使わないので経済的です。

ぎりぎり見えるか見えないかの方眼

ノートからカードへ変更した効果

ノートからカードにしたことでどのぐらい生産性が上がったとか、時間が節約できたかといった定量的なデータはとらなかったのではっきりとはわかりません。ただ、前後のページをぱらぱらめくるような思考の妨げがなくなったこと、情報の取捨選択が簡単になったことは実感として確かなものがあります。

スキャンしたカードのファイルをどう管理するか、スキャン済みのカードをどう整理するか、そもそも大量のカードをどう管理するかといった課題についてはもう少し長期間試行錯誤する必要がありそうです。

考える時間と質

成果物の品質があがったかどうかの客観的判断は難しいところですが、自己満足レベルではかなり効果があったと思っています。「知的生産の技術」にもふれられていますが、なにかものを作り出すための時間においてはいかにわずらわしさをなくすかが影響を与えます。今回ノートからカードにしたことによって、本エントリーでふれたいくつかのわずらわしさがなくなりました。これにより思考が途切れることなく考えることに集中できるようになりました。

英辞郎テキストをDictionary.app用に変換

8年ほど前にも同様に、英辞郎の非暗号化テキストを購入してMac OS X標準辞書アプリ(Dictionary.app)向けにデータを変換して長らく利用していました。今回、ひさしぶりに新しくデータを購入して作り直すことにしました。

英辞郎サイトによれば、非暗号化テキストデータはバージョン145以降販売される予定はなく、最新版は144.1とのことです。

いまはわざわざ自分で変換しなくとも英辞郎 for OS X Dictionary.appとして販売されていますので面倒だとか、ターミナルからコマンドをうつという作業にぴんとこない方はこちらを購入されるのが良いでしょう。辞書データのバージョンも新しいです。

一方、個人的にはすこし表示をカスタマイズしたいなという気持ちもありましたので今回は少し古いですがテキストデータを購入し、データを作り直すことにしました。

今回やりたかったところは

  • 品詞(名詞、動詞等)ごとの表示整理
  • 読みがなをルビとして表示
  • カナによる発音、大学入試のような記号は不要なので省略

といったところです。あとは文字サイズや色のテイストをOS X標準インストールされているウィズダム等とにたようなものにそろえたいと いったところです。

完成形は下記のようなイメージです。品詞については、単語によって若干表現ゆれがあったので、一度ソートし直して番号を振り直しています。

辞書での表示例

変換方法とスクリプトについてはGithubにおいてあります。MITライセンスとしましたのでご自由にご利用ください。辞書データ全体について表示の確認をしているわけではないのでくずれている部分もあるかと思いますが、気になる方は随時修正いただければ。

書評: 僕たちのゲーム史

40年程度のビデオゲームの歴史を膨大な文献から、ゲーム発売当時の状況を振り返った上で考察していく、というスタイルでゲームの歴史が綴られています。

本書の直前に「教養としてのゲーム史 (ちくま新書)」というのを読んだことが本書を読む上で好対照となりました。「教養としてのゲーム史」は教養としてのとするには全体的に論拠がうすく、著者独自による振り返りであるように感じました。これは今回紹介する「僕たちの」が紹介している文献の幅広さと比較してしまうからかもしれません。

さて、「僕たちのゲーム史」の内容は今となっては当たり前となったゲームシステムや、スタイル、ジャンルを当時開発者やユーザがどのような体験を通して切り開いてきたかを丁寧に振り返っている良著です。ここまで膨大な範囲を調査し、分析することはなかなかできることではありませんから、ゲーム史評価において本書を超えるのはかなりのハードルが上がったことだろうと思っています。

本書の流れですが帯にある「スーパーマリオはアクションゲームではなかった!」は、それだけを聞けば何ことかわからないのですが、当時のゲーム雑誌での評価をもとにうまく分析しています。

しかもその2ページの記事の中で、『Beep』はファミコン用ソフト『デビルワールド』について次のように書いています。 「このタイプのゲームは、種々出つくした感がありますが、これはところどころに新しい趣向を採り入れて、十分に楽しめるできばえになっています。」 これはなかなか衝撃的な言葉ですね。僕はまだゲームの歴史を語り出したばかりなのですが、第一章の段階で、すでに特定のジャンルのゲームは「出つくした」と言われているわけです。

このようにゲーム史は常に過剰供給との戦いがあり、その状況下でも創意工夫の中で新しいジャンルが切り開かれてきました。本書はこの創意工夫を当時のゲーム体験に振り返って評価することで何が新しかったのかを丁寧に分析しているところが著者の主張をより明確に裏付けています。

ゲームの歴史を振り返ろうとするとき、ヒットしたゲームがあってそれらについて単に機能とかゲームシステムといった事実としてわかりやすい特徴をもとに分析したのではこのような裏付けをつくることはできません。

ゲームの歴史という比較的我々が慣れ親しんで、体験し、よく知っている分野であるからこそあるジャンルのゲームがどのような経緯で評価されるようになったのか、知るのは難しいことです。あるいみゲームの歴史という物語の結果を我々自身がよく知っていることもあって、なあんだそんなことか。と思うことが多かったり、拍子抜けするかもしれません。

それでも本書全体を通してみれば拍子抜けすると言うよりは、子供から歴代遊んできたゲームを思い出しながら、その面白さを追体験しているような印象さえあります。このため堅苦しすぎず、読み終わった後も気持ちよく、古いゲームでも引っ張り出してみようかなと思える構成になっていているのでしょう。

Akka + JavaFX Proof of Concept

Since GUI framework like JavaFX requires always run on main thread for handle events/manipurating UI properties. This usually cause unexpected behaviors. Fextile trying to separate layout specific codes, handling events, manipurating UI properties, and business logic on top of Akka async messaging framework.

Defining layout is very similar to JavaFX/ScalaFX applications.

object MyApp extends FextileApp {
  // Do layout just like JavaFX/ScalaFX application
  stage = new PrimaryStage {
    title = "My Application"
    width = 800
    height = 600
    scene = new Scene {
      fill = Color.BLUE
    }
  }

  override def props: Option[Props] = Some(Props[MyApp])
}

For all events from scene graph are transfered to actors on Akka.

class MyApp extends Actor {
  override def receive: Receive = {
    case (s: Scene, e: MouseClicked) =>
      s.fill = Color.RED

    case (_, _: WindowHidden) =>
      Fextile.shutdown()
  }
}

code on github: semester/semester-foundation-fextile

Product/Service GA/EOL/EOSL dates

Glossary

  • GA … General Availability
  • EOL … End of Life. End of support for enhancement and/or bug fix.
  • EOSL … End of Service Life. End of support for both bug fix and security fix.
  • TBD … To be determined.

Programming Languages

Ruby (MRI)

Version GA EOL EOSL
1.9.3 2011-10-31 2014-02-23 2015-02-25
2.0.0 2013-02-24 TBD (2015-02?) TBD (2016-02?)
2.1 2013-12-25 TBD (2015-12?) TBD (2016-12?)
2.2 2014-12-25 TBD (2016-12?) TBD (2017-12?)

PHP

Version GA EOL EOSL
5.4 2012-03-01 2014-09-14 2015-09-14
5.5 2013-06-20 2015-06-20 2016-06-20
5.6 2014-08-28 2016-08-28 2017-08-28

Java SE

Version GA Public EOL
5.0 2004-05 2009-10
6 2006-12 2013-02
7 2011-06 2015-04
8 2014-04 TBD

Database

MySQL

Version GA Public EOL
5.0 2005-10-15 2012-01-09
5.1 2008-11-27 2013-12-31
5.5 2010-12-03  
5.6 2013-02-05  

KVS

Redis

Version GA EOL/EOSL
2.4 2011-10-18 2012-11-29(?)
2.6 2012-10-24 2013-12-11(?)
2.8 2013-11-22  
3.0 TBD  

Server OS

Reference

Debian (Server)

Version GA EOL/EOSL
6.0 (Squeeze) LTS 2011-02-06 2016-02-06
7.0 (Wheezy) 2013-05-04 TBD

Ubuntu (Server)

Version GA EOL/EOSL
10.04 LTS 2010-04-29 2015-04
12.04 LTS (Precise) 2012-04-26 2017-04
14.04 LTS (Trusty) 2014-04-17 2019-04

CentOS

Version GA EOL EOSL
3 2004-03-19 2006-06-20 2010-10-31
4 2005-03-09 2009-03-31 2012-02-29
5 2007-04-12 2014-Q1 2017-03-31
6 2011-07-11 2017-Q2 2020-11-30
7 2014-07-07 2020-Q4 2024-06-30

Mobile OS

Reference

iOS

Version GA EOL/EOSL
6 2012-09-19 2013-02-21(?)
7 2013-09-18 2014-06-30(?)
8 2014-09-17 TBD
  • No explicit EOL/EOSL policy found. Guessing EOL/EOSL dates from latest update of each version.
  • iOS 6.x latest update: iOS 6.1.6
  • iOS 7.x latest update: iOS 7.1.2

Android

Version GA EOL/EOSL
3.2 (API level 13) 2011-06-15 2012-02(?)
4.0 (API level 14/15) 2011-10-18 2012-03-29(?)
4.1 (API level 16) 2012-07-09 2012-10-09(?)
4.2 (API level 17) 2012-11-13 2013-02-11(?)
4.3 (API level 19) 2013-07-24 2013-10-03(?)
4.4 (API level 20) 2013-10-31 2014-06-19(?)
5.0 (API level 21) 2014-11-12 TBD