gofujita notes

自分目盛りの階層性 ¹

May 2, 2016

1. 問い

　まず、以下の記事を味わってください。読んで損しない文章です。97%請け合います。

　「そこにわずかでも意思があるかぎり」 (Word Piece, Tak. April 24, 2016)

　記事の後半に、エピソードが登場します。レポートを完成させたいなぁと思っていたのに、同僚のアクシデントの手助けに追われ、レポートのための作業を電車とカフェでしかできなかった、でもなぜか少し満足できたという１日。誰もが一度は経験していそうな、なさそうな。身近なエピソードです。

　この問いについて自分なりに考えたくて、エピソードの背景になっているモデルを考えました。ここで言うモデルとは、現実世界から、自分にとって大切と思う部分だけをとりだして組み立てた、現実世界の模型です。模型ですから、その世界をつくる部品の種類や数、部品どうしの関係をできるだけ少なくします。

　部品を減らしたり関係を単純化したにも関わらず、今気になっている問題 (この記事では「アクシデントに追われたのに何となく満足できた」問題) について、その模型が現実と同じ振る舞いをしたとき、ぼくたちはその問題とするプロセスを「要約」できたことになります。モデルをつくる作業は、この世界を理解する方法のひとつと思ってください。

2. モデルのフレームワーク

　まず時間の流れを考えます。これは、ぼくたちがまったく管理できないものです。ぼくたちが何をしても、同じ速度で流れ続けます。

　そして、このモデルの主人公はひとりだけ。２人以上を主人公にはできません。その主人公は、それぞれの時間にひとつだけ、アクションを選ぶことができます。このアクションは広い意味で使っていて、たとえば眠るとか何もしないとか、活動的じゃないアクションも含まれます。

　その主人公の中には目盛りがあり、その値に基づいて自分自身の満足度を評価します。この目盛りを「評価軸」、満足度を「自分得点」と呼ぶことにします。この自分得点の計算もアクションのひとつです。そして、この計算をアクションすることで、自分得点の記憶が更新されます。

3. モデルを問題にあてはめる

　より具体的なステップに入ります。記事後半のエピソードでは、まずレポートを完成させることをゴールとする評価軸を設定しています。これをレポート完成軸と呼ぶことにします。現在地点の座標とレポート完成というゴールの座標の差が小さくなるほど、自分得点が上がります。そして主人公は、出勤前の電車とカフェで、レポート完成に近づく作業をアクションとして選び、レポート完成という座標に近づきました。自分得点が少し上がります。

　しかし、職場につくとアクシデントが起こります。その対策に追われ、この主人公はレポート完成軸上のゴールに近づくことができませんでした。にもかかわらず主人公は、ある種の満足感を感じています。主人公は自分得点を上げています。なぜ、そんなことができるのでしょうか。

　それは、レポート完成という軸の上位階層に別の軸が存在していたから、というのがぼくの仮説です。

4. 仮説 (答えの案)

　くわしく説明します。レポート完成というゴールが定まっている限り、レポート完成に必要なアクションを実行せずに、レポート完成軸上の現在地点とゴールとの距離を縮めることはできません。しかし、そのレポート完成軸が、別の軸に乗っかっているとどうでしょうか。たとえば人情軸。人情とすると説教くさい感じですから、人間大切軸にしましょうか。困っている職場の同僚を手伝うというアクションを実行することで、この人間大切軸に沿ってプラス方向へ移動できました。

　レポート完成軸が人間大切軸に乗っているとは、たとえば人間大切軸の現在地点に円盤 (球体でもいいです) があり、その円盤にレポート完成軸が描かれていると考えてください。この場合、人間大切軸の現在地点がプラス方向へ移動すると、たとえレポート完成軸の現在地点が不動あるいはマイナス方向へ移動した場合でも、全体として現在視点はプラス方向へ移動する可能性があります。つまり、自分得点増加の可能性があります。その仕組みはシンプルで、上位階層の軸のスケールが下位階層の軸のスケールよりも大きいからです。

　たとえば、鎌倉から江ノ島へのんびり走る江ノ電車両の中で、あなたが先頭から２両目でぼーっと立っていても、あるいは鎌倉方向へ大急ぎで歩いても、あなたはおよそ時速20キロで江ノ島方向へ移動するのと同じ仕組み、と言えばよいでしょうか。江ノ電列車の鎌倉側最後尾を０、先頭の運転座席うしろを100とした目盛りがレポート完成軸、江ノ電の路地裏をとおるような線路に刻んだ、鎌倉駅が０で江ノ島駅が100とする目盛りが、人間大切軸にあたります。これら２つの評価軸のスケールをくらべると、線路のひと目盛りは江ノ電車両のひと目盛りよりも、はるかに大きくなっています。

　この例だと、列車の軸と線路の軸は並行ですが、軸の向きが直角に交わる場合もあれば、斜めに交わる場合もあります。

　＊

　モデルの中の主人公は、朝の電車やカフェの中で、レポート完成軸にフォーカスします。つまり、レポート完成軸の目盛りで現在地点を測ります。その後、会社でアクシデントに追われる同僚と一緒になったとき、その手伝いをしながらフォーカスする階層を人間大切軸へ移動します。ポイントは、人間大切軸がレポート完成軸より上の階層にあることを、この主人公が認識していることです。この認識がなければ、主人公は、自分得点が上がったと感じることができません。

　とすると、電車の中やカフェの中などで、この主人公は、レポート完成に必要なアクション以外に、大切なアクションをとった可能性が考えられます。

　自分にどんな種類の軸が関わっていて、それらの軸が、どんな階層関係にあるかを自分の頭で整理する、という作業です。現在の自分にとって、レポート完成軸という大切な軸があること、でもそれ以外に人間大切軸が重要な軸として自分に関係しており、人間大切がレポート完成よりも上位階層にあることを「確認」する、という作業です。

　この確認作業があれば、レポート完成軸上でのプラスへの移動が実現しなくても、人間大切軸の自分得点が増加していることを認識できるため、満足度は増すことになります。これをぼくは「自分目盛りの階層性」仮説と呼んでいます (笑)。

5. おわりに

　階層モデルは、 ツリー (樹状) モデルと呼んでも良いと思います。階層構造はツリーで記述できるからです。このツリーモデルのすぐれた点は、要素がとてもたくさんある場合でも、要素の関係がつくるツリー構造という形に要約でき、たがいの位置関係などで、個々の要素の特徴まで含めて瞬感的にイメージできることです。しかも、一度にフォーカスできる範囲が限られていても、フォーカスする枝の範囲を変化させながらフォーカスを繰り返すことで、全体のツリー構造の情報と合わせ、よりたくさんの要素について「認識」可能になります。

　オブジェクト指向プログラミングの手法は、非常に複雑な作業を実行するプログラムを作成するために、このツリーモデルの長所を利用していると、ぼくは理解しています。

　加えて、この世界の現象の多くは、ツリーモデルでうまく近似できます。この世界が本当にツリー構造かどうかは別として。ぼくたちが生活の中で、日々、人や生き物たちやいろんなできごとに出会いながら、何かを選んで行動して何かを感じて生活していくというプロセスも、このツリーモデルで記述できるのではないでしょうか。

　そして、本に書かれた仕事術などの how to が、あなたの生活の中でうまく働かないとき、その理由としてそこに書かれた how to の背景にあるモデルが、この生活のツリー構造、つまり、自分目盛りの階層性を無視した場合があるのではないかと、ぼくは考えています。

1. 一部、誤字と表現を修正しました (May 3, 2016)。

---