読者です 読者をやめる 読者になる 読者になる

考える場所

ココロとカラダ、思考する全部

「大事」と「大切」の違いは

前に、信用と信頼の違いについて書いたけど、「大事」と「大切」の違いもそこにあるんじゃないかと考えた。つまり「大事」は対象のことを、「大切」は自分のことを言うんじゃないかと。程度の問題だと思っていたけど、そう分けた方がしっくりくる、ような気がする。

仕事と私、どっちが大事なの!?

え、ああ、うん、、

これは「大事」を使うのが合ってるように思う。聞かれている人の主観ではあるが、仕事がなのか、私がなのか、つまり対象のことを言っているのであって、言葉からは評価としての存在を表しているような感じを受ける。そして、この質問は男を困らせる。

だから、本当に聞きたいことが私の評価値なのではなく、彼の生きている感情や情熱であるのならば、次のようにした方がよいと思う。

私のこと大切にしてくれる?

ああ、もちろん

///

ほらね、会話だってスムーズになったでしょ。どうだろうか。

冗談はさておき。「大事」の反対は「小事」である。しかし「大切」の反対は「小切」ではなくて、「粗末」だとか「雑」だとかかな。それは姿勢のことを言っているのであって、やはり言葉が表すものは自分の問題なわけでしょ。

そうしたらなんで「大切」の方が「大事」よりも程度が大きいように感じるのかと言えば、それは自分との距離が近いからなんじゃないかと思っている。感情や姿勢のことを言うのか、対象や評価のことを言うのかを考えれば、前者の方が近い。だから大きく感じる。『一億人の英文法』の大西先生が書いた、もっと初級向けの本で、過去形は実際過去を表しているのではなく距離を表している、というのを見て目からウロコしたことがある。その感じだ。

英語で「大事」と「大切」を言うと次のようになるんじゃないだろうか。文法として英語は日本語よりロジカルな表現になる気がする。

You are important to me.

が「大事」で、

I care about you.

が「大切」。いかがかな。

言葉っていうのはおもしろいね。ものごとを表現するためのものであっても、言葉が表現を制限してしまうことだってあるような気がする。表現することで在るということが鮮明に見えるようになるのだけど、同時に形という枠組みの中でしか見ることができなくなってしまうような。

blog.fukuchiharuki.me

一億人の英文法 ――すべての日本人に贈る「話すため」の英文法(東進ブックス)

一億人の英文法 ――すべての日本人に贈る「話すため」の英文法(東進ブックス)

所作を調えて心を調える、ハウツー本もたまにはいいなと思った話

もうしばらくいわゆるハウツー本を避けてきたのだけれど、読んでみて、これはこれでいいものだと思った。ハウツー本をあえて避けてきたのは、「○○する3つの方法」みたいな表面だけをなでるだけの感じ、煽られてるような気になるのがとにかく嫌だったからだ。

それがなんでハウツー本をまた読んでみたのかというと、"習慣"がすごく大切だと思うようになってきたから。やればできる、明日から本気出す、みたいに器用なことがそうそうできはしなくて、ほとんどの場合がいつもどおりの自分が在るだけ。そういう意味では逆に、ハウツーをこなせばよかろうなのだ、というわけにはいかないんでしょ、と思っていた。

だけど、心と体はつながっていて、所作を調えることで心が調う、ということはあるとも思っている。これはもう完全に禅とか仏道とかの影響なんだけど、これは本当だと思う。心だけがきれいで所作がきたないとか、ないと思うんだよ。脳科学的にもそういうことはあると言えるみたいで、過去の行動とつじつまを合わせるために価値観を更新することだってあるらしい。

厚切りさんのツイートをひとつ拝借する。がんばれる自分を見ることはいいことだと思う。それは間違っていないし、人格を抜きにして成果だけを見る考え方は好きじゃない。それでも、がんばれる自分を、人格だけを見て形成していくことはかなり難しいでしょ。それがまあ厚切りさんの言うところの"コントロール"だと理解している。このような"コントロール"で自分を変えていくことは「スタンフォードの自分を変える教室」にも書いてあったと思う。

スタンフォードの自分を変える教室 (だいわ文庫)

スタンフォードの自分を変える教室 (だいわ文庫)

そういう科学的というのか、立証的な言い方ではないのだけど、松下さんの本にも"形をやる"というようなことは書いてある。印象に残っているのは「掃除をきちんとする」ということだったり「仏壇でも神棚でもいいから毎日手を合わせる」ということだったり。もう半年くらいは神棚に手を合わせるようにしていて、それでどうにかなったということはないんだけど、どうにかなりたいんだって思えるわけ。それがちょっとの知識を得たところでガラッと変わっちゃうなんてことはなくて。どこに一貫性をもたせようかということを考えれば、自分に本来的な価値観を創造する力が備わっていないなら、信仰の形に頼るというのはよくできた答えのひとつだと思ってる。

リーダーになる人に知っておいてほしいこと

リーダーになる人に知っておいてほしいこと

パウエルさんの本には"訓練"という言葉が使われていたと思う。それについて書いてあるのはチームのこととしてだったと記憶しているけど、チームの在りようを変えるための訓練を定めて実践する、というのはそれが個人でも同じことだろう。能動的に自らを変えようとする意志のある分、"訓練"という言葉には力強さとテクニカルさのようなものを感じる。

リーダーを目指す人の心得

リーダーを目指す人の心得

それでまあ、久しぶりに次のハウツー本を手にとってみたのだけれど、"習慣づけ"とか"訓練"のつもりでいて目を通す分にはよいなと思えた。そのきっかけは掃除のことが書いてあったからで、松下さんの本にあったことの影響は自分の中で大きいなと感じた。掃除のことが書いてる本はいい本だ、って。そんなバイアスをかけてしまっているのはちょっと危ないことでもあるが。

とは言え、やっぱりハウツー本だけを読むのはなんだか違う気がしている。だいたい、わあっとハウツー本に食いついてしまうときっていうのは、目に見えるような成果をすぐに求めてしまっていて、そういう心の状態で形をやり続けることができるのかって、それは難しいでしょ。だからいろいろ読んでみるのがいいんじゃないかな。いろんな方向からものごとを見て、考えて、やってみるしかない。どれかだけで成す、ということはできないと思うんだよね。

やる気のないチームを劇的に変える3分の習慣

やる気のないチームを劇的に変える3分の習慣

ちなみにこの本で一番よいと思った"習慣"は「音をたてないようにしてみる」である。八百万神を信じることにしているから、ものを大切にするのは当然であるのだが、じゃあどうやってということまで考える必要がある。ものを大切にすればばたばたと音を立てることはないでしょ、と考えることができれば、音をたてないようにしてみる、と"コントロール"することができる。当たり前と言えば当たり前なのだが、そういう発想はできていなかったなと思ったのである。

CQRSの小さな演習(番外) バリューオブジェクト

たとえば、エンティティがIDをもっていて、これをどうやって表現するかを考えてみます。MySQLでauto incrementの数値だからintかな?とか、UUIDだからStringかな?とかって考えますよね。だけど、その前に、エンティティにとってはそれが数値であっても文字列であっても、IDをもつ、ということに変わりはないはずです。

f:id:fukuchiharuki:20160416121345p:plain

そこでIdというオブジェクトを考えます。今回の演習ではIdのほかに、DoingとDoneAtを個別のクラスにしていて、それぞれString、String、Dateをラップしています。

class Id {
  String value;
}
class Doing {
  String value;
}
class DoneAt {
  Date value;
}

これはちょっと面倒なんじゃないの?と最初こそ思うのですが、実際に書いてみると分かります。引き寄せられるように部品が組み立っていきます。一度やってみてください。

値を確実に識別する

メソッドの引数や戻り値に型を指定しますね。引数でString idとすれば、文字列の値を受け取れますが、これが本当にIDなのかどうかは分かりません。Stringは文字列として間違いないですが、IDとして間違いないことを意味しません。変数名でidと言うことに拘束力がないからです。

この拘束力のなさはメソッドの呼び出しに不安定さを与えるような気がします。String idでIDの値を考えた場合、どこからがIDとして妥当な値なのかが見えなくなります。約束事で取り決めることはできるかもしれませんが、コード上の制約にすればそれがもっと強力になります。

イベントでもコマンドでも属性をバリューオブジェクトにしました。エンティティがもっているIDとイベントやコマンドがもっているIDは同じIdである、ということがコードとして表現することができます。すると、間違ってコードを組み立ててしまうことがグッと減ると思います。

値を変更しない

バリューオブジェクトは値そのものですから、途中で値を変えるようなことをしません。できないようにします。immutableです。

ドメインとして意味のあるオブジェクトである、という型をもっていても、その内容が書き換わっていくようでは困ります。3+2をやったときに、次回の35のはたらきをしたら大変ですよね。プリミティブな変数なら少なく(広く?)ともメソッドでスコープが切れますが、インスタンスはあちこちで参照されて保持される可能性がありますから、知らない間に破壊される(値として妥当でなくなる)と目も当てられません。バリューオブジェクトは完全コンストラクタか相当のもので生成することで、安心して利用することができます。

なお、Stringもimmutableです。が、それでもStringをラップしてドメインとして意味のあるバリューオブジェクトにするべきです。

そのデータの処理はそのオブジェクトでする

オブジェクト指向の、データと振る舞いを一体にする、という基本的な考え方に従えば、プリミティブな値をラップするのは自然なことです。Idの内部的な値がStringであっても、その値をIDとして処理することがあればIdにメソッドをもたせたいのです。

たとえば、IDをハッシュ化することがあったときに、次のようにはしたくなくて、

String str = id.toString();
MessageDigest md = MessageDigest.getInstance("SHA-1");
byte[] digest = md.digest(str.getBytes());

こうしたいのです。

byte[] digest = id.getDigest();

もっと言うとbyte[]を直接操作するのは不安定なので、こうした方がいいかもしれません。

DigestedId digestedId = id.digest();

データコンテナとそれを操作する処理、という構図は積極的に回避したいのです。ので、参照している側が内部の値をgetして直接処理するべきではないです。エンティティがそうならバリューオブジェクトも同じで、ドメインとしての意味をもつ個別のクラスにできるわけです。

本編

blog.fukuchiharuki.me