分離エンジニアリング
AとBがいっしょくたになっている構造に注目し、AとBを分離した上で個別に扱うことで、よりきめ細かなアプローチを目指すための方法論。
分離の例
会議 = 交流 + 議論
会議にはグルーミングと議論（その他合意形成などもあるが全部議論に含むとする）が混ざっている。だから迂闊に会議を効率化すると反発される。グルーミングという社会的動物として当たり前の営みをなくすのか、人の心がないのか、と本能的・感覚的に拒絶されるからだ。あるいは、文化として刻み込まれているがゆえに自覚すらできない。 ならば両者を分ければ良い。グルーミングを行うための時間と、純粋な議論を行う時間を分ける。すると前者と後者をそれぞれ独立的に運用できる
通知 = 割り込み + インボックス + 情報
リーダー = リード + ガバナンス
リーダーはリードに専念するべきであって、ガバナンスを行うべきではありません。ガバナンスとは、ここでは権限を用いた行使を意味し、マネージャー（もっと抽象化すると上司）が行うものです。しかしリーダーも迂闊に権限を持ってしまいがちです。このいっしょくたを理解するために、A=リード、B=ガバナンスと対応付けます。そしてリーダーからガバナンスを、つまりは権限を切り離せばいいと考えます
分離事例
今のところ、私がセンスで分離している。ひとまず事例を貯めておけば、イメージや勘所を掴んでいただく材料として使えるだろうsta.icon
特定
「いっしょくたになっているもの」にあたりをつけること。いつ、どうやって、何にあたりをつけるかを体系化するsta.icon
分離
特定した対象を分離すること。これもAとBをどうやって導いてくるかを体系化するsta.icon
対処
分離したAとBそれぞれについて処置を考えること。ここは特に共通項があるのでまとめていきたい。たとえば「Aを行うためだけの時間」の確保は鉄板だし、余裕と集中も必要だからそもそもそれらを確保するための仕事術全般も鉄板sta.icon
パターン
分離事例から導けると思うが、「混ざっているものとしてありがちなもの」など傾向があるはずだ。それを体系化するsta.icon
構造と仕組みの把握
たとえば会議の分離は、グルーミングという人間の性質を知らねば行えまい。このように分離対象を構成してそうなもの・分離対象に絡んでそうなものの、根本の構造や仕組みを知らねばならないことがよくあるsta.icon
参考:
開発秘話
私がこの概念を導こうと思った発端は.gitignoreです。Gitというプログラムコードの履歴管理を行う技術の話ですが、これはパスワードやアクセストークンなどセンシティブな情報を誤って管理（登録）しないための仕組みです。管理対象から無視するものを指定するファイルとなっています。つまり、.gitignoreでsensitive.txtを指定し、センシティブな情報はこのファイルに書いておくことで管理されなくなります。これはもっと言えば、センシティブな情報をsensitive.txtに書くこと、またここから読み込むことも要請します（sensitive.txtありきの設計にするのです） 一方、情報共有の文脈で、極めて優秀な大企業の人達ですら、まともに共有ができない現実を目の当たりにしてきました。根本的な原因の一つがセンシティブ安全性(Sensitive Safety)でした。極論を言えば、機密情報が含まれている（かもしれない）ものを共有することなどできません。考えるまでもないことです。 私は逆に考えました。ならば機密情報が含まれていなければ良い。最初から含まれないようなあり方をつくって、その前提で仕事をすればいい、情報を扱えばいいのだと。これは.gitignoreの発想そのものです。この考え方を、一般的な仕事術に抽象化すればいいだけであり、私にとっては造作もないことです。
あとは名前ですが、私はさらに抽象化できるとわかり、A+Bが混ざっているものをAとBに分ける、との営みだと捉えました。分けるということで分離、特に誰でも再現性を持って扱えるようにしたいのでエンジニアリング（工学・体系）にしようとも思いまして、分離エンジニアリングと名付けました。ちなみに、この概念を使うと、センシティブ情報の問題は A+Sensitiveと捉えることができます。