X(Twitter) Zenn GitHub RSS 共有

メンタルモデル

作成日時：2024-07-07
更新日時：2024-08-30

私のメンタルモデルは、主に下記の4つからなる。

  1. 認知負荷の軽減
  2. 会社に貢献する
  3. 不知の自覚
  4. プラグマティズム

1 認知負荷の低減

1-1 認知負荷とは

人間が情報を処理する際に要求される精神的な努力のこと。
つまり、無駄に頭を使わされることである。

下記の状況において、認知負荷が発生した経験は誰しもあるだろう。

1-2 認知負荷はプロジェクトから排除しなければならない

認知負荷の存在はシステムの品質低下に繋がる。
認知負荷が高い、すなわち脳内CPUの使用率が高い状態で仕事をすると、へまをする可能性が高まる。

前項にある認知負荷の例と、システム品質の低下の対応を下に記す。

認知負荷の存在はシステムの品質低下に繋がる。
故にプロジェクトから認知負荷を消し去る努力をしなければならない。

1-3 認知負荷排除の困難性と排除対象

しかし、プロジェクトから認知負荷を消し去ることは困難である。
何故ならば、プロジェクトのその「有期性と独自性を持つ業務(※PMBOKより)」という性質の為である。
「独自性」が不確実性と曖昧性を産み、認知負荷が発生する。
プロジェクトに携わる以上、それの持つ認知負荷とは向き合わざるを得ない。

だが「プロジェクト以外」を起因とする認知負荷は、減らすことができるし、減らさなければならない。
汚いコードや不明確な意思伝達による認知負荷などの事である。

ただでさえプロジェクトという認知負荷が高いものに、余計な認知負荷を増やしてはならない。

認知負荷を減らす為、下記の思想に則り業務を行う。

1-4 コーディング原則適用思想

コーディング原則適用思想とは、
「コーディング原則はコーディングに限らず、他のさまざまな領域においても認知負荷を軽減する効果がある。」
という考えをもとに、
「業務における全事象に対してコーディング原則を適用し、その対象から認知負荷を排除する。」
という思想である。

全てに対して、コーディング原則を適用する。
ドキュメントライティングを例にした実行方法をドキュメントライティングの2章から4章に記載しているので参照されたし。

1-4-1 私が主に使用しているコーディング原則

基本的に下記を使用している。

1-4-2 デザインパターンとフレームワーク

デザインパターンとフレームワークも適用する。
但し、コーディングのデザインパターンとフレームワークはそのまま適用できない。
その為、適用対象が持つデザインパターンとフレームワークを用いる。
例えば、何かしらの提案文書を作成する場合、PREPフレームワークに基づいてドキュメントを作成する。

参考：フレームワーク思考

1-4-3 アナロジー思考との相違

アナロジー思考的な考えである。
厳密に言えば、アナロジー思考は「違う事柄から双方の類似点を見つけて課題に応用する思考」。
コーディング原則適用思想は、類似点に関係なくコーディング原則を適用するため、アナロジー思考ではない。

1-5 ゼロトラスト思想

全てを疑い検証することにより、不確実性と曖昧性を排除し、認知負荷を下げる。

何も信じてはならない。
リーダーの指示も、設計書も、コードのコメントも信じてはならない。
その内容の正当性を誰が証明するというのか。

セキュリティ用語の「ゼロトラスト」と同じ思想である。
”Never Trust, Always Verify”（絶対に信用せず、常に確認しろ）

作業指示が不明瞭な場合はBOSCARフレームワークに従い、観点を整理する。
能動的に曖昧さを排除していく。

ただし、ゼロトラストは疲弊する。
体制としてのゼロトラストを構築すべき。

など。

1-5-1 リアリティショックの低減

ゼロトラスト思想の副次的効果として、リアリティショック(※)を低減できる。
誰にも期待しないため、怒りや失望など、負の感情を起因とする認知負荷が発生しなくなる。

※リアリティショック：理想と現実の乖離によって発生する心的な負の事象。

1-5-2 不満があるならば自分でやる

他人に期待するのは時間の無駄である。
他人は絶対に変わらない。
何年もそのスタイルでやっているんだろうから。
ならば自分を変えた方が早い。自分から動く。
コヴィーもカーネギーもそう言っている。
他人に期待するな。

1-6 頭を使わせない環境を作る

プロジェクトにおいて頭を使うべきはその対象のみであり、それ以外に頭を使わせないようにすべきである。
自分やメンバーに余計なことで頭を使わせないように。

1-6-1 驚き最小原則

驚きは推測可能性を妨げ、認知負荷を上げる。

1-7 その他

1-7-1 出向先の不満は自分で解消する

例えば出向先に下記の物が無かったとする。

その場合は自分で作る。(1-5-2参照)
出向先に作るように依頼や提案しても、動く可能性は低い。

1-7-2 報連相

1-7-3 ドキュメントには「何故」を書け

「何をしているか」は設計書やソースを読めばわかる。
「何故そうしたか」は記載されていなければ分からない。
即ち認知負荷を発生させる。

1-7-4 VUCAの排除

1-7-5 結論を最初に話す

最後まで聞かないと内容が分からない会話は認知負荷を発生させる。
最初に何の話かを相手に伝える。

WEBで例えるならばpreload。
事前に必要そうな情報が分かれば、脳内補助記憶装置から脳内メモリに必要な情報が事前ロードされる。
必要な情報がロードされた状態で話を聞くことができるならば、相手の話は推測が容易になり、認知負荷を低減できる。

1-7-6 メモ

曖昧さと不確実性に繋がり不具合へ繋がる。
恐怖は未知から生まれる。
恐怖はストレス(負荷)を生み出す。
ストレスは脳に無駄な負荷を掛ける。
曖昧さは脳のメモリを圧迫する。

2 会社に貢献する

2-1 なぜ会社に貢献しなければならないのか

「会社に貢献」なんて言うと、ネットだと社畜とか奴隷とか言われそうだがそうではない。
会社の為ではなく、自身の為に会社へ貢献するように働く。

2-1-1 寄生虫理論

会社員は会社に寄生する寄生虫である。(※マイナスのニュアンスは無い)
自身が太るためには宿主を太らせなければならない。
宿主の栄養を貪るだけならば駆虫薬で体外に出されるだけ。

故に、自身の為に会社へ貢献する。
例え愛社精神や帰属意識が希薄だったとしても、会社の売上に貢献するように動け。
※私の愛社精神や帰属意識が無いとは言ってないよ。

2-2 単価を上げる

※基本、私はSESなのでその立場で書く。

振られた作業を完遂するのは当たり前であって、そこに付加価値をつける。

3 不知の自覚

「不知の自覚」とは「自分に知識がないことを自覚する概念」である。

私は「ある技術の存在と概要を認知した状態」を不知の自覚と定義している。
つまり「名前と概要は知っているけど詳しくは知らない状態」(既知の未知)。

不知の自覚をすることで、学習および業務においてメリットがあると考えている。

3-1 学習における不知の自覚

学習対象を認知していなければ、そもそも学習が発生しない。
学習という行為は、学習対象の認知の後に来る。

例えば「MVCC」を知らない人間が「MVCC」に関して勉強することは無い。
何故ならば、「MVCC」の存在を知らないのだから。
「ネットで検索をする」「AIに聞く」というアクションすら発生しない。

知らなければなにも始まらない。
持続的に学習を行うために、不知の自覚をする習慣を身につけなければならない。

3-2 業務における提案可能性

「ある技術の存在と概要の認知」さえ知っていれば、顧客に提案ができる。
例え、その技術の内容をよく知らないとしても。

何かしら業務でトラブルが発生した時などに
「よくわからないですけど、こういったものがあるみたいですよ」
と提案ができる。

仮にその提案が採用された場合、学習機会が発生する。

3-3 認知負荷の低減

概要さえ知っていれば認知負荷を低減できる。
何故ならば、相手の話が推測可能になるから。

例えばMVCCに関する話をされた場合、「MVCCが何なのかは分からないが、DB関連の用語である。」という状態であるならば、
脳内メモリへDBに関する情報をロードできるため、話の推測可能性が発生する。

4 [WIP]プラグマティズム

「それが何であるかより、それがもたらす効果を考える」

5 その他思想

5-1 根本原因分析

RCA:root cause analysis

5-2 指摘するときは自分の事を棚に上げる

例えばAさんがBさんのコードレビューをしているとき
A「この書き方は駄目だけど自分もこの書き方しているからいっか。指摘したら面倒だし。」
というクソみたいな思考。

自分の事は棚に上げて指摘しろ。
それが明らかに間違っているならば指摘しないと後々手戻りや不具合、クソコードという形で襲い掛かってくる。
認知負荷の発生。

-Aが指摘Bは改善
1するされる　
2するされない
3しないされる　
4しないされない

3に関して、Aが指摘事項を認知している時点でBは指摘事項を認知していない。
即ちBが自ら改善する可能性は低いため、3はこの表から除外する。
その場合、指摘しなければ改善される可能性は0だが、指摘すれば改善される可能性が存在しうる。

指摘しない場合、モラルとモチベの低下を発生させる。
モラル：自分もしていないし相手にも指摘しなかったから、自分もこのままでいいや。
モチベ：指摘したからには自分も直さなければならないという気持ち。

5-3 設計書はADRであり脳内INDEXである

ペライチでいい。
大まかなフローとWhyが書かれていればそれでいい。

5-4 デザイン思考

問題解決のためのマインドセット。

  1. 問題提起：トピック選定
  2. 共感：情報収集
  3. 定義：解決対象の選定
  4. アイディア：ブレスト
  5. プロトタイプ：検証
  6. テスト：評価

「もしかして～でしたか」という確認は誘導である。
本来の要望をくみ取ることができなくなる呪いの言葉。

5-5 返事はなるべく早く

相手の作業を止めることになる。

コンテキストスイッチを発生させない
認知負荷低減・生産性を低下させない

5-6 泳ごうとすらしない奴は沈めばいい

泳げない奴は沈めばいい。(闘うプログラマー[新装版]より。)
つまり自走できない奴は知らん。

しかし上記はマイクロソフトでの話。
日本の中小企業で、そこまで要求するのは酷かと思う。

なので、私は「泳ごうとすらしない奴は沈めばいい」と考える。
「泳げなくても泳ぐ意思がある奴」は全力で支援する。

泳ごうとすらしない奴は知らん。勝手にしろ。
時間の無駄なので距離を置く。

5-7 モデル化

情報収集⇒モデル化⇒実践が学習のフロー。
モデル化は名前をつけろ。

5-8 その他

6 参考書籍