X(Twitter) Zenn GitHub RSS 共有

メンタルモデル

作成日時：2024-07-07
更新日時：2024-12-23

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

  1. 認知負荷の軽減
  2. 会社に貢献する
  3. 「既知の未知」を増やす
  4. プラグマティズム

根幹を成す思想は下記の3つ。

⇒思想 | takc-tech

価値の検証と追求。

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-5-3 防衛的悲観主義(Defensive pessimism)

自身のゼロトラスト思想は、防衛的悲観主義から発生した。

全ては最悪である。
絶対に負の事象が発生する。
自分の為すことは、全て絶対にうまく行かない。

故に、そういった悪い結果を避けるために、徹底した準備をしなければならない
これ即ち、自身や周囲の人間から認知負荷を取り除くことに繋がる。
副次的効果として、リアリティショックが低減されうる。
提案やアイディアの創造に繋がる。

また、下記の思想へと繋がる。

参考：前事実的思考

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

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

1-6-1 驚き最小原則

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

1-7 提案

“提案”のレベルを上げる - Konifar’s ZATSU

レベルが上がれば上がるほど、相手の認知負荷は下がる。

1-8 その他

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

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

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

もう自分がPMと思え。

1-8-2 報連相

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

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

1-8-4 VUCAの排除

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

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

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

1-8-6 メモ

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

1-9 会話の公理

会話が文字通りの意味で伝達されるために満たすべき条件(ポール・グライス)。

※個人的には「コーディング原則適用思想」を使えば問題なし。

参考：無藤隆ほか. 心理学. 有斐閣, 2004, 143p.

2 会社に貢献する

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

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

2-1-1 寄生虫理論

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

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

2-2 単価を上げる

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

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

3 「既知の未知」を増やす

3-1 「既知の未知」とは

「既知の未知」とは知らない知識が存在することを認識している状態。
「知らないということを知っている」もの。

「ある技術の存在と概要のみ認知した状態」なども「既知の未知」状態と言える。
その技術が存在するのは知っているが、具体的にどのような物かは分からない、という状態。

3-2 「既知の未知」を増やすメリット

「既知の未知」を増やすことで、学習および業務において下記のメリットがあると考えている。

3-2-1 学習行為の促進

「既知の未知」の増加は学習行為を促進させる。

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

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

知らなければなにも始まらない。
存在さえ知っていれば、ネットで検索したりAIに聞くことが出来る。
持続的に学習を行うために、「既知の未知」を増やす習慣を身につけなければならない。

学習すれば「既知の未知」は「既知の既知」へと変わる。
それは技術の深い理解へと繋がるし、“できる事”が増える。
また、学習の過程で新たな「既知の未知」を増やすことができる。

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

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

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

仮にその提案が採用された場合、学習機会が発生する。
アイディアの源泉は蓄積された情報である。

3-2-3 認知負荷の低減

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

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

3-3 「既知の未知」を増やすには

とにかく色々なものに触れる。
本を読むなり、ネットで調べるなり、勉強会に行ったりなど。
情報収集を欠かさない。

4 プラグマティズム

プラグマティズム - Wikipedia

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

4-1 価値の判断基準

プラグマティズムをベースとした考えが健全であり続けるためには、価値を正確かつ柔軟に判断する能力が必要である。
→個人的価値だけではなく社会的価値も考えるべき。
→ネオプラグマティズム。

4-2 ネオプラグマティズム

ネオプラグマティズム - Wikipedia

ネオプラグマティズムは、20世紀後半に発展した哲学的潮流で、古典的プラグマティズムを現代的に再解釈・発展させた思想。
絶対的真理を否定し、社会的対話と実践的有用性を重視する現代哲学の潮流。

絶対の真理など存在しない。 価値や効果は暫定的で都度変わる。普遍的である。
→古典的プラグマティズムは、個人的または社会的価値や効果を暫定的な真理とみなした。
→しかし絶対的な価値/効果の定義は存在しない

古典的プラグマティズムは個々の経験や合意に基づいたものを暫定的な真理とみなした。
ネオプラグマティズムは真理とは流動的/相対的な物であり、文脈などに依存するとした。

4-3 誤ったプラグマティズムの利用

プラグマティズムを理解していなかったり、誤解していたとしても、
その誤った考え方に価値を見出して利用することは、
ある意味「誤ったプラグマティズムをプラグマティズム的に利用している」と言える。

4-4 プラグマティズムの個人的解釈

「効果や価値」に重きをおいて物事を考える。
それは物事をシンプルにし、おおよその場合はうまくいく。

しかし、「効果や価値」の判断の妥当性は、誰が保証する。
ネオプラグマティズムの観点から、「効果や価値」は文脈に依存する。

「効果や価値」に重きをおいて物事を考える手法が健全であり続けるには、
「効果や価値」の判断基準を常に最適な状態にしなければならない。

それを行うためには常に学習し、新しい価値観や判断基準を
取得し続ける必要がある。

5 その他思想

5-1 根本原因分析

RCA:root cause analysis

5-1-1 なぜなぜ分析

個人的には下記のタブーがあると考える。

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 まともな要件定義など無い

諦めて自分であるべき姿を考える。
行間を読み取って提案するしかない。

5-9 目的にフォーカスする

作業指示を受けたならば、その目的が何かを第一に考える。
作業指示が目的を達成する最適な行動である保証はない。
目的を達成できるならば、作業の内容は何でもいい。

何のためにその作業を振られたのか。

問題→根本的原因→目的→作業。

5-10 哲学における「批判」

  1. 本質的意味
    • 対象を徹底的に分析
    • 理論や概念の根本的な吟味
    • 前提や方法論の妥当性の検証
  2. 目的
    • 既存の思考枠組みの問い直し
    • 新たな視点や理解の獲得
    • 知的な成長と変革の促進
  3. アプローチ
    • 徹底的な論理的分析
    • 対象の多角的な検証
    • 偏りや盲点の発見
  4. 批判の特徴
    • 破壊的ではなく建設的
    • 対象への深い理解を伴う
    • 無前提の懐疑ではない

批判は、思想の深化と革新のための根本的な知的営み

5-11 「考える」方法

積極的に考えてもアイディアは出にくい。
出ないものに時間をかけるのは無駄である。

積極的に考えなくてもいいので、考える対象を頭の片隅に置いておく。
そうしておけば、普段の生活の何かしらのイベントがそれを起爆する。
「これこれこういうことがあった。そういえばこの事象は例の件に当てはめるとどうだろうか」とか。
積極的に考えるのに比べ、こちらは「考えの源泉(イベント)」があるので、アイディアは出やすい。

風呂入ってる時や、寝る前に起爆しがち。

5-13 学習

5-14 自身の思想には名前をつけろ

自身のアイディアに名称をつけることは、脳内データベースに対するハッシュインデックスを貼るがごとし。
名称を思い浮かべただけで、その情報が脳内に展開される。
認知的効率性。
「なんか玉ねぎとジャガイモ、ニンジン、肉が入ったスパイシーな奴」ではなくて
「カレー」の一言で上記の情報が脳に展開される。

5-15 教育に関して

相手の「既知の未知」を増やすように努力をする。
「既知の未知」は新たな学習の起点と考えているため。

「既知の既知」の増大に関しては、その人の意思に任せる。
そこまで面倒見る義理はない。
もちろん質問されたらば、喜んで答える。

⇒(参考)泳ごうとすらしない奴は沈めばいい(「闘うプログラマー」の例のアレの個人的解釈)

5-16 提案をする

善管注意義務違反とならないために顧客へ提案をする。
善管注意義務違反は債務不履行による損害賠償へ繋がる。

仮にシステムにセキュリティリスクがあったとする。
それを見逃して損失が発生したならば、顧客から損害賠償を請求される可能性がある。
エンジニアならば、報告や対策をするはずだから。

仮にプロジェクトマネジメントが上手くいかなかったとする。
それで損失が発生したならば、顧客から損害賠償を請求される可能性がある。
エンジニアならば、プロジェクトが上手く行くように立ち回るはずだから。

だから、事前に提案をしておく。出来るならばデータに残る形で(Backlogとかメールとか)。
そうすれば、提案はした⇒提案したけれども顧客が実施をしなかった。
となり、善管注意義務は果たしたとなる。

簡単に言えば、プロならプロらしく、真面目にエンジニアの業務に当たれ。
後は契約書の解釈により判決は決まる。

参考：改正民放第644条、第415条

5-15 その他

5-15-1 自分とは何か

分からないのでプラグマティズム的な観点で思考する。
周囲の物事に対して、プラスの効果や価値を提供する生物であると思っていたいし、
そうありたいし、あり続けたい。

5-15-2 思考のベース

プラグマティズムをベースとして構築したメンタルモデルを使用し、
価値/効果/改善を追求する。

6 参考書籍