好意と義務の境目を垣間見るとき

今年は自分にとって大きなイベントがありました。それは出産と結婚式です。

娘が誕生しました。育児と仕事の両立に追われる中で結婚式の準備もしました。結婚式というのは、立派なプロジェクトですね。しかも2回も行ったのですから尚更です。県外の方向けと、県内の方向けに分けたのです。

県外の方向けはご祝儀制、県内の片向けは会費制です。ご存じない方は「え?」と思うかもしれませんが、地域によって結婚式に参加するときに持って行くお金のルールが違います。
私が住んでいる地域では会費制が主流です。勝手な想像ですが、小さなコミュニティで顔見知りばかりのため、結婚式の参加は付き合い半分というのが根づいているのでしょう。毎回毎回、大金を出していては家計が危うくなりますし、かといって付き合いを疎かにしては顔が立ちません。田舎暮らしの人間にしか分からない感覚かもしれませんが、それも文化のひとつなのだと思います。

かといって、みんながみんな義務でお祝いしているわけではないのです。そこには昔からの付き合いだったり、大切な友人だったり、日頃からお世話になっている人だったり、「好意」としてのお祝いが間違いなくあります。
今回は結婚式を例に進めますが、そこに好意と義務が共存していることが自分にとって、非常に興味深いことでした。

参加者セグメントごとに好意と義務の割合は異なる

親族かどうか、付き合いが深いかどうかで、会費の他にご祝儀があったり、お祝いをいただいたりというケースが発生します。
結婚式は一見、好意を集めて成り立つ儀式のように見えて、義務が多くの割合を占めます。
風土や気質によりますが、親族は義務が背景にあり、金品という形で好意を還元する傾向があります。日頃から仕事でお世話になっている人は義務の割合がおおくなります。しかし、プライベートでの付き合いが深いと好意がそれを上回る傾向にあります。友人は好意の割合が非常に多くなります。これは社会的責任などがあまり発生しない間柄のためでしょう。

好意に祝儀・会費という義務を課す

好意は無償に見えます。しかし、結婚式というシチュエーションの場合、費用が発生するために祝儀・会費という義務を課します。それが大切な友人であってもです。
結婚式場やブライダルプランナー、お花屋、ケーキ屋といったビジネスと絡んでいくと費用が発生するのは当然です。言い方は悪いですが、好意と義務のすり替えが発生します。しかし、お祝い事なので、義務ではなく好意に見えるのだと思います。

好意を薄めずに義務を果たす

お祝い事とはいえ、冒頭にあるとおり、一大プロジェクトです。主催者側もやることは山積みで、祝ってもらうからには、それ相応の感謝を表したいと考えます。

主催者の意向にもよりますが、会費内で収めるか、会費を超えて日頃の感謝を表す意味で還元するかは分かれます。
人数が多くなってくると、人的負荷が高くなるため、如何に好意を薄めずに効率よく義務的作業をこなすかが大事です。例えば、メッセージカードを新郎新婦が直筆で全員に書く。というのは少人数なら辛くありません。ところが、田舎の結婚式は100人200人がざらです。

テンプレートを作って印刷すれば安上がりですし楽です。しかし、好意に対して義務的な返し方は悪印象です。そこで作業負荷を上げすぎずに好意を伝える方法に頭をひねることになります。
つまり好意を表すはずの作業が義務にすり替わる可能性を含んでいます。

好意と義務は表裏一体

好意と義務がいつの間にかすり替わるということは、表裏一体の関係なのだと思います。「せっかくのお祝い事ですから」というのはマジックワードで、商売側からすれば好意とお金をつなげるチャンスと言えますし、主催者側からすれば好意でもって義務を果たす原動力になります。参加者にとっては祝儀・会費といった金銭的義務を好意として解釈する理由になります。

費用が発生する仕組みである以上、義務はなくなりません。大事なのは義務を納得するだけの好意を各々が受け取れるようにすることなのだと思います。
各々が義務を十分に果たすと、顧客満足度、日頃の感謝、祝福などといった感情で好意が残ります。

ふと思ったことがあります。好意や善意という感情を集める仕組みは、ビジネスモデルとして重要な要素を多く含んでいるということです。次はその可能性について考えてみようと思います。


[解決]xampp 1.7.0 でSQL実行時にApacheが落ちる

状況

ローカルの開発環境ではxampplite1.7.0を利用しています。バンドルされているPHPのバージョンは5.2.8。Symfonyからdoctrineを使用してSQL(SELECT)を発行すると、Apacheが強制終了するという現象が発生していました。save()は問題なく実行できていたので、コード側の問題かと思っていましたが、どうやらlibmysql.dllの不具合のようです。

解決策

libmysql.dllをlibmysql_5.0.51a.dllで置き換えるとApacheが落ちなくなりました。同じような現象で悩んでいる方が多いようですが、どれも具体的な原因を突き止められていない様子。DLLそのものの問題のようなので、修正版で置き換えがてっとり早いようです。

libmysql.dllが置かれているのは以下の場所です。

  • /path/to/xampplite/php/libmysql.dll
  • /path/to/xampplite/apache/bin/libmysql.dll

それぞれ同じ場所にlibmysql_5.0.51a.dllがあるので、置き換えてしまいましょう。


[WordPress]サブカテゴリと単一記事のパーマリンクを混在させる設定

パーマリンクの設定でポピュラーな設定は/%category%/%postname%/ですが、この場合、サブカテゴリが存在すると投稿スラッグがサブカテゴリを表すのか、投稿名を表すのか区別がつかないので、とあるカテゴリの単一記事を表示しようとすると、404となってしまいます。

かといって、/%category%/だけを指定すると、アーカイブページでタイトルにパーマリンクを反映させると、単一記事の表示ができなくなります。そこで、以下の方法としました。

/%category%/%post_id%/

記事の運用方法にもよりますが、投稿スラッグを使用しない運用であれば上記の設定でサブカテゴリと単一記事のパーマリンクが混在させられます。もっと良い方法があれば、どなたかご教授いただきたく・・・。短縮URL使えば、見てる側は気にならないことですが、WordPressのテーマカスタマイズをしてる側は重要な問題となります。


[WordPress]抜粋(excerpt)を使わずにエントリの途中まで表示する

通常のsubstr()を使用するとバイト指定になるため、マルチバイト対応のmb_substr()を使うことになります。
[sourcecode language="php"]
<p><a href="<?php the_permalink(); ?>"><?php echo mb_substr(get_the_content(), 0, 56); ?>...more</a></p>
[/sourcecode]
上記サンプルの場合は、先頭から56文字を抽出して表示し、その文章にリンクさせています。指定した文字数より短い文章の場合は、文章の最後まで表示されることになります。文字数をカウントする場合は、マルチバイト対応のmb_strlen()を使用することになります。


[WordPress]ページスラッグを取得する

投稿、ページ作成時にURIを指定して、それを利用してCSS切り替えやclass指定、画像表示の制御をしたい時に使うのでメモ。

   1:  <?php if(have_posts()): while(have_posts()): the_post(); ?>
   2:  <?php $slug = get_page_uri(get_the_ID()); ?>
   3:  ...
   4:  <?php endwhile; endif; ?>

固定ページのスラッグを取得したい場合は、以下の方法でも可能。

   1:  <?php $page = get_page(get_the_ID()); ?>
   2:  <?php $slug = $page->post_name;?>

階層ページの場合、1つ目の方法だと「親のページ名/このページ名」みたく取得されるので、配列化して任意の要素だけを取り出すという方法も考えられるが、今表示しているページのスラッグを取得したい場合は、2つ目の方法で十分だと思われる。


jFeedMixer - 複数RSSフィードを統合してウェブサイトに表示するjQueryプラグイン

このエントリはjFeedMixer専用ページへ移行しました。今後は、そちらを御覧ください。

複数ブログで管理しているRSSフィードを統合して、ウェブサイト上に表示させることができるjQueryプラグイン、jFeedMixer 0.2.0 をリリースします。このプラグインはGoogle AJAX Feed API を使用しているので、ご利用の場合は、AJAX API Keyを事前に取得する必要があります。

jFeedMixer 0.2.0 - github

jFeedMixerを使うシチュエーション

複数ブログを管理していて、メインサイトのトップページに各ブログのRSSフィードを時系列順で表示したい。

デモ

デモページへ

jFeedMixerの使い方

scriptタグで各ライブラリを読み込み、任意のdivを指定してjFeedMixerを呼び出します。





表示オプション

feeds: ["feed URL", "..."]  必須
複数のフィードURLを指定できます。RSS、Atomなどが表示されるURLを指定してください。
countPerFeed: 数値 オプション(デフォルト: 5)
1フィードURLあたり取得するフィード数です。例えば、「5」と指定して、feedsに2つのURLを指定した場合は10件のフィードが表示されることになります。
countLimit: 数値 オプション(デフォルト: 10)
表示フィードの最大件数を指定します。countPerFeedと併用でき、feedsに2つのURLを指定し、countPerFeedを10と指定した場合、全体の件数は20件ですが、このオプションを指定すると、上位10件が表示されます。
feedFormat: "http://your.site.com/js/feed.jfm.html" オプション

デフォルト:

			%title【%blogTitle】(%date)[%category]
		
フィード表示のフォーマットを指定できます。「.jfm.html」を含むファイル名を指定した場合、ファイル中で指定したテンプレートを利用して結果を出力します。サンプルファイルのテンプレートは以下のようになっています。

			
%title %blogTitle
%date %category
使用可能なパラメータは以下のとおりです。

  • %link: フィードへのリンク(URL)
  • %title: フィードのタイトル
  • %date: フィードの投稿日
  • %blogTitle: フィードを管理するブログのタイトル
  • %blogURL: フィードを管理するブログのURL
  • %category: フィードのカテゴリ
beforeFeeds: "<dl>" オプション(デフォルト: "<ul>")
feedFormatオプションで指定した出力結果全体の「前」に付加される文字列を指定できます。
afterFeeds: "</dl>" オプション(デフォルト: "</ul>")
feedFormatオプションで指定した出力結果全体の「後」に付加される文字列を指定できます。
dateFormat: "日付フォーマット" オプション(デフォルト: "yyyy.mm.dd")
フィードの投稿日を表示する際のフォーマットを指定できます。

  • yyyy: 西暦
  • mm: 月(1桁の場合はゼロパディング)
  • dd: 日(1桁の場合はゼロパディング)
  • H: 時(1桁の場合はゼロパディング)
  • i: 分(1桁の場合はゼロパディング)
  • s: 秒(1桁の場合はゼロパディング)
feedFormatオプションで指定した出力結果全体の「後」に付加される文字列を指定できます。
カテゴリが複数の場合、指定の区切り文字を挿入して表示します。

補足

  • 表示されるフィードはdiv > ul > li > フィード の形式で表示されます。
  • 表示結果などの詳しい説明は README_ja を御覧ください。
  • 要望、質問などは info@calmtech.netまで。

ライセンス

jFeedMixerはGPL、MITライセンスのもと作成されています。

リリースノート

  • 2010.08.30 jFeedMixerを公開
  • 2010.08.31 カテゴリ表示、表示の最大件数オプションを追加
  • 2010.09.07 テンプレート指定、前後に任意テキスト表示のオプションを追加

EclipseからGitができるEGit

私のメインIDEはEclipseで、SVNを使用しているのですが、githubにちょっと公開したいソースができたので、gitもEclipseからできないものかとプラグインを探してみたら、ありました。EGit。 前に調べたときはmsysgitでやるしかなく、Eclipseプラグインもgit向けが出たばっかりでろくに動かなかったので見送っていました。コマンドで暮らしてれば別に問題ないのでしょうが、GUIメインですし、メインの開発環境から出ずに済むならその方がいいです。

インストール

アップデートサイトがあるので、http://download.eclipse.org/egit/updatesからEclipseユーザならいつものパターンでインストールできます。新規ソフトウェアのインストールからウィザードに従ってインストールします。EGitはgitクライアントのJavaによる実装、JGitをベースにしています。

リポジトリを作る

まずは普段どおり、githubにリポジトリを作ります。ここからが普段と異なるところで、通常、リポジトリを作った後、ローカルブランチ(master)からoriginに向けて一度、pushをすることでリポジトリの作成は完了するチュートリアルが提供されていますが、pushの操作をEclipseから行ないます。ssh公開鍵の登録が必要ですが、その操作については割愛します。

Eclipseにリポジトリをインポート

[ウィンドウ]->[Viewの表示]->[その他]をクリックし、[Git]->[Git Repositries]を選択します。パースペクティブ上にGitビューが表示されるので、そこで右クリックし、[Git リポジトリーのインポート]を選択します。ロケーションのURIにgithubのリポジトリページで表示されている、「git@github.com...」をコピーして、URIに貼りつけます。必要な情報は補完入力されるので、ssh公開鍵のパスフレーズを入力して、次へ進んでいきます。初めてのsshアクセスだとknown_hostsの登録を確認されるので、そのまま従ってください。

リポジトリからプロジェクトを作る

Gitビューに表示されたリポジトリから右クリックし、[Import Projects]を選択します。[Use the New Projects wizard]を選択し、完了するとプロジェクト作成ウィザードが起動するので、任意のプロジェクトを作成します。

コミットする

作成されたプロジェクトでREADMEなど、何らかのファイルを作成した後、右クリックから[チーム]->[コミット]を行います。

originにプッシュする

プロジェクトを右クリックし、[チーム]->[push]を選択します。宛先のリポジトリを選択するのですが、必ずCustom URIを利用してください。2010/08/29の時点では、登録済みリポジトリを利用するConfigured remote repositoryからはリモートリポジトリの接続に失敗するバグがあります。Custom URIの[URI]にgithubリポジトリのURIを入力し、ssh公開鍵のパスフレーズを入力して次へ進みます。Source Refのプルダウンからmasterを選択し、[Add spec]を選択し継へ進みます。今回更新する内容が表示されるので、問題なければ完了を選択します。これでoriginに編集結果が反映されました。

バグがあるのと、ややUI的に発展途上な部分もありますが、メイン開発環境からいつもどおりに作業できるのは嬉しいですね。


WordPressで認証ページを作成する

特定のページのみ(この場合は固定ページ)に認証を設ける方法についてです。 ここでの例はページテンプレートを作成し、このページテンプレートしたページへアクセスした場合、ログイン済みならそのまま表示、未ログインであればWordPressのログインページへリダイレクトします。なお、ログイン後はアクセスしたページへリダイレクトされます。

   1:  <?php
   2:  /**
   3:   * Template Name: 認証つきページ
   4:   */
   5:  if(!is_user_logged_in()) auth_redirect();
   6:  get_header();
   7:  
   8:  ?>

ポイントをあげるとすれば、wp_header()の前に認証処理を記述することです。


人間にマルチタスクはできているのか?をiPad的UIで考えてみる

4月下旬、iPadがいよいよ日本発売となります。iPadは様々な箇所で賛否両論を巻き起こていたようですが、その中で否定的な意見として言われたのが「シングルタスクだからダメ」というものです。おそらく、これは複数のアプリケーションを同時に起動しておきたいと言う意味だと思います。

コンピュータをマルチタスクで動かすのは当たり前になっていますが、人間がそもそもマルチタスクをできているんだろうか?という疑問が湧いたので、それについて思考実験をしたことをまとめてみました。iPhoneユーザなので、改めて各々の操作を振り返りつつ、iPadで行ったとしてどうなるだろう?と考えて行きます。

脳がそもそもマルチタスクなのか?という話を始めてしまうと、無意識や反射のことを考えなければならず、おそらく「よくわからない」と言う結論が大抵待っていると想像できるので、実際に動かしている部分がどうなっているかに焦点を当てて行きたいと思います。

追記 2010/03/08
Twitter上でマルチタスクの定義が不明確と意見がありました。ここでのマルチタスクの対象は後述しますが、目、耳、手のみとします。臓器や細胞まで考えると、話が拡散してしまうためです。また、目、耳、手を対象とするのも、アプリケーション操作において表層で主要となる部位であるためです。そこをつかさどる運動神経などには上記と同じ理由で深く言及しません。

人間のCPUは1つだと言う仮定

人間は1CPUをもったマルチタスク可能な動物で、訓練によってタスク切り替え速度をかなり向上させることができる。と私は仮定しています。よく両手でピアノが弾けるとか、ブラインドタッチができるというのが、同時進行で手が動いているように見えますが、ブラインドタッチについて言えば、指は逐次で動いています。これはキーボードでのインプット自体が逐次でないと受け付けていないからもでもありますが、同時押しも、指を逐次で押しています。それが相当な速度なため、できない人から見れば、同時に動かしているように見えています。

おもしろいのはブラインドタッチの「フリ」をしてみると、次に何を動かせば良いか意識しなくてもよくなるので、ほぼ同時に両指を誰でも動かすことができます。逆にいうと、意識が大きく影響していると言う表れです。ただ、先述の通り、意識と言うものではなく、可動部位を中心に考えます。

可動部位は重複させられない

例えばiPadというデバイスを前にしたとき、私たちが利用できる可動部位として思いつくのは、目、耳、手になると思います。まずそれぞれの部位について同時進行のように見せられる組み合わせを考えてみます。

目 + 耳

動画再生をしている時などが考えられるます。説明字幕が出ている間にナレーションが進んでいたりすると、聞き漏らし、見落としが発生する場合があります。逐次で目と耳を切り替えながら、字幕とナレーションを交互に認識していると考えられます。

目 + 手

ホームでアプリケーションを選択している時や、写真をフリップしながら見ている時などが考えられます。まず目で操作対象を決め、実行するために必要な手順に沿って手を動かして行きます。扱っている情報の性質にはよると思いますが、目で始まって手で実行と言う逐次処理を求められます。

耳 + 手

キー入力をしている時に、入力音をONにしているとします。カチッという入力音が聞こえたことで、正確に入力されたと判断して、次の入力をおこなうと言う動作が可能です。目での判断も間違いなく入っているのですが、耳から手、手から耳と言う逐次処理を行っていると考えられます。

可動部位には主従関係と優先度が発生している

どのパターンにも言えることは、主となる可動部位があり、その実行結果に従って次の可動部位が連動していると捉えられます。目がほとんどの場合、主となっているはずです。目が使えない暗闇は耳に、音が特にない場合は手でなど、状況に合わせて優先度が変わっていきます。

iPadに関しては視覚が必須のデバイスなので、目で対象を捉えるというのがトリガーになると考えられます。

ここから2つある可動部位を重複として考えます。

目 + 目

目が2つあることで焦点合わせなどを行っており、同時に違うものを見るというのはできていません。視野の端にとらえると言うことはできますが、そのものを具体的には捉えられていません。焦点を移して行くことになるので、実質は逐次処理であると思います。

耳 + 耳

反射した音などを両側から捉えるというここと、どちらの耳から聞こえるかで方向の特定などができています。おそらく同時に聞こえているというのは成立していると思いますが、同じ方向から来る音を一緒に聞いているかというと、それはできていないはずです。片方からの音をまず捉え、頭の中の振動が反対側に伝わるか、反射した音がもう一方に遅れて入ってくるかでしょう。

手 + 手

厳密には指と言うサブシステムで考えるべきですが、両手で操作する場合は、フルキーボード入力が考えられます。これは冒頭に述べた通り、実際は逐次入力となります。また、指を2本以上同時に押す場合、それぞれが完全に独立して動くことはなく、例えば画像の拡大であれば、画面の中央から外側へと同じ方向へ動かしています。他の操作もそうです。

マルチタスクはできそうだが、独立した同時処理はどうなのか?

これまでの内容から、人間はマルチタスクが可能だと考えられそうです。ここで一歩進めて、同時に複数のアプリケーションが起動できるとして、独立した状態で使いこなせるのか?と考えてみます。目、耳、手は2つあるので同時に動かすことはできますが、独立して動かすのは困難だと言うことです。

しかし、ここでそもそもの前提として足りないものがあると思いました。それはデバイス側、つまりコンピューターそのものが逐次処理のため、同時入力は受け付けていないと言うことです。2画面や複数アプリケーションという状況はあっても、フォーカス、つまりターゲットをまず決めるという処理が必要な以上、やはりコンピューター側の都合で同時入力はさせてもらえません。

GUIであれば、フォーカスによって1つずつですし、CUIだとキーボード自体は同時入力できますが、内部での解釈は逐次処理になっています。実は人間の行動様式や可動部位を考慮してデザインされていると言われるデバイスも、コンピューター側の逐次処理という制約ありきということになります。

それを考えると、複数のアプリケーションが同時に動くと言うよりは、同時に起動しているのと変わらないぐらい切り替えのストレスがないか、そう見せるインターフェースがあれば今は十分だろうと私は思います。

そういう意味では、メニューとアクティブなアプリケーションが常時表示され、アプリケーションの切り替えも兼ねるWindows7のタスクバーは、かなり秀逸なデザインだと思います。実際、そのおかげでWindows用のDockが不要になりました。

どのI/Oをどこまで独立させていけば良いのか?

ピアノは鍵盤1つ1つが独立したI/Oですし、パーカッションもそうです。しかし、音としては独立していても、人間に取っては和音と言う結果を得ることができます。コンピュータのI/O、それらを総合したUIを考える場合、どこまでの単位で独立させると良いのか?ということについて再考が必要だろうと思います。

マルチプロセッサが普及してきていますが、メモリ管理も含めて完全に独立処理というのは、できるできないがあります。演算と描画を独立させることでパフォーマンスが上がったように、同時処理ができるということは入力方式から再デザインされる必要があるのではと今は考えています。

今回の思考実験は浅い考察だと思うので、I/Oを独立させる単位を考えなおすと言う方向で、また、まとめてみたいと思います。


[読了] 「結果を出す人」はノートに何を書いているのか

書評というより、本を読みながらノートをとるというのを試したら、思いのほか楽しかったので、その内容について残しておこうと思います。

書籍の紹介やサマリーはAmazonや書評を書いている方々に任せるとして、本を読んで自分が「おっ」と思ったことをトピックにして行きます。

ノートを記憶時間の長さで分類する

短期記憶

タスク、アイディア、緊急の要件などが主な用途。後で思い出せるキーワードとしての価値が重要。今を忘れて次のアクションにつなげるために書き留める。

中期記憶

短期記憶の断片や切り抜き、コピーなどをスクラップする。短期記憶をある程度膨らませたり、整理したものが中心となる。その他、何らかのタイミングで見返す必要のあることとして、議事録や勉強したことなども記しておく。その場合、Plan –> Do –> Seeのサイクルを前提とし、予測としてトピックを立て、それに対する検証結果や実態となる流れで記述して行く。見積と消化時間のような計測効果が望めるのと、結果的に「まとめ」となる。

長期記憶、優先度管理(スケジュール)

マンスリーで予定管理。1ヶ月単位というのが中長期の視野を持たせることになる。また、限られた枠という制約がコンパクトに情報を記述して行く習慣を作る。予定は未定。予定を編集しやすいように、何度でも貼ったり剥がしたりできる小さなラベルシールを利用する。シールをドラッグアンドドロップするという表現は言い得て妙。

スケジュール管理のこつとして、「バッファ」を作る。この日は予備日として週1回あけるということにしておく。予定外のものなどはそこで吸収する。自分の場合、打ち合わせと書類作りに時間をとられてばかりという状態が好ましくないので、作業のためにそういったミーティングや外出を一切入れない日をつくるというのは重要だと思った。

勉強したことを試す機会をタスク化する

まとめるべきは、この勉強をした後に自分が何をするか。何かの思考法や整理法などについて勉強したのであれば、それをどこで試すかをタスクにしてしまう。更にキャッチフレーズをつけることで、自分への意識付けを強める。

試す機会をタスクとして管理するというのは良いと思う。強制力は大事。自分の場合は、読んでる最中にノートを取りながら読むという取り組みをスタートしてみた。こうすると、斜め読みしてはいけないところを拾える効果があった。既存知識は読み飛ばしがちだが、文書化しようとすると、見逃しや曖昧な理解について浮き彫りになる。

セミナーは持ち帰ることを決めておく

目的を明確にしておくことでアンテナを張り、聞き逃しを無くする。講師の印象に残りたい場合は、事前に講師について情報を収集し、講師が求めている情報について質問をするのが効果的。

何かあるかもしれないという「期待」でセミナーに参加は確かに漫然と聞いてしまうと思う。自分が決めたテーマと違った内容であれば、それはそれで比較検討にもなりうる。そういった前提の決め打ちもいいかもしれない。また、講師が求めている情報というのは、つまり共通の話題を得るチャンスであるということ。

ビジュアルイメージをタグにする

ノートをスキャンして管理するときのタグにビジュアルイメージとする。時系列とイメージの方が内容よりも思い出しやすくなる。他にはページ数を最もさいたコンテンツをタグとする。

ノートは連番で管理しがちだが、ハッシュとして管理するのが良いと解釈した。試しにノートに名前をつけてみたが、しっくりきている。またタグ管理のアプローチとして、情報量と密度を用いるのは確かに有効だと思う。ある短い期間中に集中した出現したもの、長期で特定のタイミングで現れるものを抽出などといったものは、様々な検索サービスで活用されている。自分が整理した情報についても、そういう集約の仕方を応用してみるのはいいかもしれない。

読後感想

著者はノートつまり紙というデバイスの長所を何度も繰り返し訴えるが、デジタルデバイスとの棲み分けがはっきりしていて、自分が扱っている情報の性質を的確に捉えていると感じた。個人的にはいわゆるライフハックという行為をどのデバイスでやるかは生活様式次第だと考えていて、「このテクニックは自分だとこのデバイスで済ませられるな」などといった比較検討をしながら読み進める過程は楽しいものであった。

情報集約ツールを考案しているが、改めて自分が扱っている情報の種類、それぞれの特徴をマインドマップで書き出そうとすると、うまく説明しきれないものがある。これらを理解し応用方法を考えることがまず先決だと感じている。

最近はデジタル化の手間を省くためにノートPCで議事録などを記録するようにしていたが、情報整理の方法を突き詰めるという意味で、改めてノートでの記録に戻ってみた。まだまだ改善の余地は大ありだ。白紙という自由は、これほどまでに自分を楽しく悩ませるものかと思えた。

もともと文房具も好きで色々試していて、文中で紹介されているノートを始めとした文房具を、さっそく文具屋で片っぱしから手に取ってみた。この中で、また合う合わないがあり、ネットでの情報を見たときに良さそうと思ったものが、実物を見るとそうでなかったりと、これもまた楽しい。

文房具で何か、ひとネタ書いてみようと思う。