背景
「こいつ人を枠に当てはめて決めつけが多いな～」
「この人、傾聴とか1on1って言って全然こちらの真意に耳を傾けていないじゃん」
と感じる人のメカニズムに気づいてしまいました。
今年も道中、様々な傷つくようなトラブルなどもあり、
そこから得た知見を自分なりにシステマチックに残しておこうと思い、
設計思想の復習と絡めて、年の瀬に記事に残しておきたいと感じたのが始まり。
自分の脳内のトラウマや執着との決別だけでなく、棚卸にもなるのでね。
前提知識 -演繹法とリスコフの置換原則の関係-
演繹法
演繹法は前提となるルールや規格に、個別具体な事例を当てはめて未来を予測する推論技術。
未来を予測するだけではなく、置いている正しいと思っていた前提条件が
本当に正しいのかを検証するために用いることもできる。
そのため、インターフェイスの定義の検証とかと同様の思考だと思っている。
リスコフの置換原則との関係
インターフェイスのような抽象概念で、目的を達成できているかの検証ができない時、
個別具体なクラスでの振る舞いで検証するしかない。
もしも新しい目的を達成できるような、クラスの方での事前条件や事後条件が
既存の前提条件であるインターフェイスの定義に反していた場合、
リスコフの置換原則に違反していることになる。
この場合、具体なクラスの方で検証を通っているわけだから、
前提に置いているインターフェイスの定義を再設計し直す必要がある。
何が起きている？
一言でいうと個々の具体例のほんのイチ側面だけを見て、
己の引き出しにある当てはまりそうな、
大量の個別事例がその人の中で経験則的にグルーピングされた抽象グループ、
ようはパッケージなどのコンポーネントに配置し、
そのコンポーネントの性質(前提条件)に、目の前の相手を無理矢理当てはめ、
その前提条件を「正しい」と妄信し、決して疑わないスタンスがあるということ。
ようは、自分の中のバイアスである、
インターフェイス定義や方針の間違いに気づけていない。
いや、正確には気づこうとしない意思決定をしているということ。
同様のシステムの現象で説明
前提を変えるとは、システム開発でいうと以下のようなケースが相当している。
安定していると思っていたinterfaceの定義を変更しなくてはいけなくなり、
自分の脳内の他のコンポーネントに対してどのくらい変更影響を与えるのか？が常に不確実。
他のコンポーネントへの影響範囲の特定に時間も労力もかかるし、
変更コスト(労力と時間)もかかることと同じメカニズムであるといえる。
自分の脳内の棚卸しという意味で、体系的にやろうとすると、
設計思想や設計原則という一部の人しか学習する縁がない知見を必要とするし、
非常に頭も時間も使う作業でもある。
しかも一度やって終わりということはなく、常に継続的メンテが必要。
システムが寿命を迎えるまでメンテするのと同様に、
私たち人間も自分の中のコンポーネントや、
他コンポーネントに公開するインターフェイス定義を継続的にメンテすることを
本当の意味での頭の中の棚卸しと言えるであろう。
これは場合によっては、
自分の大切なアイデンティティや価値観を根底からぶち壊さないといけなくなる可能性が高い。
そのため常にメンテの際に、強烈な痛みと向き合い続ける勇気が必須な活動ともいえる。
しかもこの時代の特性から、その痛みを伴った活動をしたからと言って、
生きやすくなるといった吉に転ずる絶対的な正解パターンもない。
コミュニティの文化との関係
しかしながら、
・一人一人が己の脳内に置いた前提条件や
それを変えられない制約条件などをモデルなどで視える化したり、他人に言語化する。
・設計思想を用いて脳内の要素を整理し、
さらに継続的に要素の移動やコンテキスト境界の再検討などのメンテをしていく。
といった活動を継続的にしないと、
組織やコミュニティは、前提条件の素早い検証と改善が困難になり、
どんどん挑戦しない、外部との情報交換もしないという
保守的でやらない意思決定をすることに必死になる集団や組織文化を形成しやすい。
現に2000年前とかの事例でめちゃくちゃ賢い集団がいたコミュニティでも、
他のコミュニティとの情報交換によって、
「相互に発展していこう」という価値観のないコミュニティは文明崩壊している。
もうこんな大昔から、【越境】という活動の重要性が語りつくされている。
不確実性の高いリスク
越境すること、システムで言えば他の外部システムとの連携によって、
当初想定しえなかったトラブルなどが起こるリスクは充分ある。
でもだからといって、閉じた空間の中でピーチクパーチク言っていても、
何も発展やイノベーションは起きにくい。
時にはリスクに目をつぶってでも、外部システム(それは組織でもいいし、ヒトでもいい)
と繋がることによって、情報の交換をしたりすることで、
各々自分の中にその知見をアナロジー展開し、新たなアイデアを創出する足掛かりとなる。
ハイリスクハイリターンであるので、まずは小さな一歩でもいい。
そこから徐々に越境の範囲を広げていけば。
何も踏み出さないことは、完全な逃げのスタンスであり、
そういう人は後輩とかに対して説教やダメ出しをすることを自分の責務として、
可能性を潰していることに一切気づいていない。
越境に対する自論
これは皆さん、経験則的にも他の会社の人との交流や、
異業種というさらに大きな枠を超えた交流の中で、
「そんな発想なかったよ✨ あ！なんか閃いたかも」ていう経験が多かれ少なかれあるはず。
なかったら、、厳しいこと書くけども、それだけ狭い世界の中にいるという意思決定ばかりしているってこと。
確かに家庭環境だとか、いろんな不条理で不平等な制約が私たちを取り巻いている。
でも、自分の置かれている制約条件と向き合わずに、
その苦しい・つまらないと嘆いている環境を飛び出さないっていう選択をしているのは、
あまりにも己に対して失礼。 めちゃくちゃ失礼！！
そんな人を誰が魅力的だと思うんだ、と私は言いたいです。
生まれた瞬間から私たちは自分を取り巻く色んな制約と戦わないといけない。
その制約を徐々に排除していき、より生きやすくするために知恵を付けたりする。
学校で習うようなもの１つとってもそう。
外部との交流に必要な共通言語の国語や英語とか、
曖昧さや主観を取っ払った客観的な議論をする際に用いる数学という共通言語。
仮説を構築し検証するために必要なメカニズムを考えるためのサイエンス。
ぜーんぶ私たちが足かせとなる制約を取っ払うためにヒントになってくれるスキル。
それらを総動員して、自分たちの目の前にある制約や、
暗黙的においてしまっている前提という壁をぶち壊す活動をする。
その中で色々な痛みを伴うけども、今までに想像もしなかった気づきや、
チームとしての一体感といったエンゲージメントというものへ繋がっていくのではないでしょうか？
対策として考えられる実現手段
組織マネジメント＆システムコーチング
組織的マネジメントやコーチング担当者は、
この組織を構成する一人一人のヒトや、情報システムといったモノ
個別具体なリソースが抱えている制約条件や置いている前提の視える化の支援。
さらにはそこから個々のヒトモノの特性の強みが活かせるプロダクトへのアサイン計画まで、
アーキテクトと連携しながら設計構築をしていかないといけないのかもしれない。
コーチングで1on1などによって、個別具体なレイヤーの制約条件を可視化し、
それを段階的に抽象化して、チーム全体という１段階マクロなレベルでの制約条件、
さらにそれを抽象化して、プロダクトサービス全体の制約条件。
といったように、
前提となる方針と、制約条件を抽象から具体までレイヤーごとに構造化し、
チームが成長してきて制約の１つをクリアしたら、
制約条件を１つ無くし、「こんなコンピテンシーをこのくらい磨いたら、この制約条件を取っ払えた」というチームナレッジとして蓄積する。
それを他のチームにも横展開できるように、チーム横断的なギルド活動も継続的に行う。
(サービスメッシュのような活動)
これには、チームトポロジーに記載のチーム設計と、
マイクロサービスのメッシュの考え方があるとより理論立てた考えを可能にしてくれる。
よって、アーキテクトとコーチングを行う人が別々の人であるなら、
密なやり取りがひつようになってくるであろうし、
横断的に幅広く全体を俯瞰して視れるマクロとミクロを素早く行き来できる
抽象化能力やアナロジースキルがないとダメといえる。
SOLIDとコンポーネント設計原則
枯れた知見 つまり安定した再利用ライブラリの設計と同じ考え方で、
その組織の再利用文化だったり、前提ナレッジをまとめたり。
それとは別のまだ検証回数の甘い、不安定な変化に頻繁にさらされる文化やナレッジを
再利用観点よりも、メンテ性の観点を優勢とし纒める活動を継続的に行う。
これはコア事業だけではなく、
これから伸びてくるであろうけど今はまだ華開いていない事業へのデータの利活用
といった知見の横展開の際にも大事な思想である。
ソフトウェアの領域だけに適用できる設計原則でないことは、
自分が何度も検証してきたので、是非ともビジネスアーキテクチャの方や
他のデータアーキテクチャ領域にもアナロジー展開していってほしい。
さいごに忘れないでほしいこと
あらゆる箇所に設計思想(というか哲学に近いかも)や、
個別具体のプロダクトたちから抽象化によりメタ化した概念である、
プロダクトに依存しない経営レイヤーでの脅威分析など、
そしてポリシーの再検討などを継続的にしていく活動は、これからも永遠に変わることはないと思われる。
一度身に付けたスキルは、決して無駄になんてならない。
ただ、時間経過や、環境の変化に伴って重要性が変わってくるというだけ。
新しく身に付けたスキルなどを是非脳内で暗黙的に整理するのではなく、
付箋などを用いてモデリングして視える化しつつ、
コンポーネントの設計原則などを用いて整理し、
新しく入ってきたスキル要素との関係性から再配置しなおして、
別々のコンポーネント同士を相互に発展させていく。
そうすることで今まで身に付けたものは決して意味をなくさない。
そのために設計原則などを深く理解して、メリットデメリットの両方から考察して、
自分の脳内のスキル要素をグルーピング化し、
常に想定が困難な未知な事例を通して、その前提を検証し、前提のメンテを続けていく。
このマインドを絶対に忘れたくないし、これを読んでくれている人にも忘れないでほしい。
来年もまた( ｀・∀・´)ﾉﾖﾛｼｸね！