メンタルモデル
作成日時:2024-07-07
更新日時:2024-11-16
私のメンタルモデルは、主に下記の4つからなる。
- 認知負荷の軽減
- 会社に貢献する
- 不知の自覚
- プラグマティズム
1 認知負荷の低減
1-1 認知負荷とは
人間が情報を処理する際に要求される精神的な努力のこと。
つまり、無駄に頭を使わされることである。
下記の状況において、認知負荷が発生した経験は誰しもあるだろう。
- 汚いソースコードを読んでいるとき
- 意味不明な作業指示を与えられたとき
- 薄く浅い要件定義を渡された時
1-2 認知負荷はプロジェクトから排除しなければならない
認知負荷の存在はシステムの品質低下に繋がる。
認知負荷が高い、すなわち脳内CPUの使用率が高い状態で仕事をすると、へまをする可能性が高まる。
前項にある認知負荷の例と、システム品質の低下の対応を下に記す。
- ソースコードが汚ければ、アジリティの低下とデグレを発生させる。
- 意味不明な作業指示は、余計な作業や手戻りを発生させる。
- 薄く浅い要件定義は、手戻りや顧客の不満を発生させる。
- 新たな価値を生み出すのに、認知負荷は邪魔でしかない
認知負荷の存在はシステムの品質低下に繋がる。
故にプロジェクトから認知負荷を消し去る努力をしなければならない。
脳のリソースは価値を生み出す行為にのみ使用されるべき。
1-3 認知負荷排除の困難性と排除対象
しかし、プロジェクトから認知負荷を消し去ることは困難である。
何故ならば、プロジェクトのその「有期性と独自性を持つ業務(※PMBOKより)」という性質の為である。
「独自性」が不確実性と曖昧性を産み、認知負荷が発生する。
プロジェクトに携わる以上、それの持つ認知負荷とは向き合わざるを得ない。
だが「プロジェクト以外」を起因とする認知負荷は、減らすことができるし、減らさなければならない。
汚いコードや不明確な意思伝達による認知負荷などの事である。
ただでさえプロジェクトという認知負荷が高いものに、余計な認知負荷を増やしてはならない。
認知負荷を減らす為、下記の思想に則り業務を行う。
1-4 コーディング原則適用思想
コーディング原則適用思想とは、
「コーディング原則はコーディングに限らず、他のさまざまな領域においても認知負荷を軽減する効果がある。」
という考えをもとに、
「業務における全事象に対してコーディング原則を適用し、その対象から認知負荷を排除する。」
という思想である。
- コミュニケーション
- ドキュメントライティング
- デザイン
- SQL
- etc…
全てに対して、コーディング原則を適用する。
ドキュメントライティングを例にした実行方法をドキュメントライティングの2章から4章に記載しているので参照されたし。
1-4-1 私が主に使用しているコーディング原則
基本的に下記を使用している。
- DRY/OAOO
- KISS
- YAGNI
- SOLID
- SLAP
- PIE
- CLEAN
- 名前重要
- 小は美なり
- デメテルの法則
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 出向先の不満は自分で解消する
例えば出向先に下記の物が無かったとする。
- 開発環境構築手順書
- 用語集
- ADR
- Design Doc
- システム構成図 / 接続情報
- Wiki / 規約 / チェックリスト
- チケットを起こす文化/フォーマット
- DML/DDL自動作成マクロ
- 変更履歴
- その他の「無くて不満を感じたもの」
その場合は自分で作る。(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なのでその立場で書く。
振られた作業を完遂するのは当たり前であって、そこに付加価値をつける。
- 提案をする
- 根拠と手段を携えて
- 改善をする
- 出向先の偉い人を味方につける(PMBOK)
- 出向先のプロジェクトの運用がダメダメならば自分が直す
- 出向先にプロセス資産が無いならば自分が作る
- 片っ端から必要そうなドキュメントを勝手に作成する
- 脆弱性情報を伝える
3 不知の自覚
「不知の自覚」とは「自分に知識がないことを自覚する概念」である。
私は「ある技術の存在と概要を認知した状態」を不知の自覚と定義している。
つまり「名前と概要は知っているけど詳しくは知らない状態」(既知の未知)。
不知の自覚をすることで、学習および業務においてメリットがあると考えている。
3-1 学習における不知の自覚
学習対象を認知していなければ、そもそも学習が発生しない。
学習という行為は、学習対象の認知の後に来る。
例えば「MVCC」を知らない人間が「MVCC」に関して勉強することは無い。
何故ならば、「MVCC」の存在を知らないのだから。
「ネットで検索をする」「AIに聞く」というアクションすら発生しない。
知らなければなにも始まらない。
持続的に学習を行うために、不知の自覚をする習慣を身につけなければならない。
3-2 業務における提案可能性
「ある技術の存在と概要の認知」さえ知っていれば、顧客に提案ができる。
例え、その技術の内容をよく知らないとしても。
何かしら業務でトラブルが発生した時などに
「よくわからないですけど、こういったものがあるみたいですよ」
と提案ができる。
仮にその提案が採用された場合、学習機会が発生する。
3-3 認知負荷の低減
概要さえ知っていれば認知負荷を低減できる。
何故ならば、相手の話が推測可能になるから。
例えばMVCCに関する話をされた場合、「MVCCが何なのかは分からないが、DB関連の用語である。」という状態であるならば、
脳内メモリへDBに関する情報をロードできるため、話の推測可能性が発生する。
4 プラグマティズム
「それが何であるかより、それがもたらす効果を考える」
- 効果を中心に考える
- 真理なぞ解らんから、効果を真理とみなす
- 心理的負荷の低減に繋がる
- プラグマティズムと不知の自覚
- 「何かは知らないがそれで◯◯ができる。」という考え方
- 提案思考に繋がる
- プラグマティズムとスクラム
- アジャイルとの親和性
- 「効果」と「価値」
- プラグマティズム→価値の追求
- 価値を理解せずして行動を起こすな
4-1 価値の判断基準
プラグマティズムをベースとした考えが健全であり続けるためには、価値を正確かつ柔軟に判断する能力が必要である。
→個人的価値だけではなく社会的価値も考えるべき。
→ネオプラグマティズム。
4-2 ネオプラグマティズム
- リチャード・ローティ:最も影響力のある代表的な論者
ネオプラグマティズムは、20世紀後半に発展した哲学的潮流で、古典的プラグマティズムを現代的に再解釈・発展させた思想。
絶対的真理を否定し、社会的対話と実践的有用性を重視する現代哲学の潮流。
絶対の真理など存在しない。 価値や効果は暫定的で都度変わる。普遍的である。
→古典的プラグマティズムは、個人的または社会的価値や効果を暫定的な真理とみなした。
→しかし絶対的な価値/効果の定義は存在しない
- そもそも「真理」という概念自体を疑問視
- 知識は常に文脈依存的で流動的
- 文脈(コンテキスト)への依存
- 文脈(ぶんみゃく)の意味や定義 わかりやすく解説 Weblio辞書
- 合意や効果も一時的なものに過ぎない
- より徹底的な相対主義的立場
- 価値の絶対的基準は無い。価値とは相対的なものである。
- 例:ステマ規制
古典的プラグマティズムは個々の経験や合意に基づいたものを暫定的な真理とみなした。
ネオプラグマティズムは真理とは流動的/相対的な物であり、文脈などに依存するとした。
4-3 誤ったプラグマティズムの利用
プラグマティズムを理解していなかったり、誤解していたとしても、
その誤った考え方に価値を見出して利用することは、
ある意味「誤ったプラグマティズムをプラグマティズム的に利用している」と言える。
- 誤解していても効果があれば価値がある
- その「誤解」自体が実践的な道具として機能している
- 「正しい理解」より「有効な理解」を重視
- ネオプラグマティズム的に見ると、そもそも「正しいプラグマティズム理解」は存在しない
4-4 プラグマティズムの個人的解釈
「効果や価値」に重きをおいて物事を考える。
それは物事をシンプルにし、おおよその場合はうまくいく。
しかし、「効果や価値」の判断の妥当性は、誰が保証する。
ネオプラグマティズムの観点から、「効果や価値」は文脈に依存する。
「効果や価値」に重きをおいて物事を考える手法が健全であり続けるには、
「効果や価値」の判断基準を常に最適な状態にしなければならない。
それを行うためには「不知の自覚」をし、新しい価値観や判断基準を
取得し続ける必要がある。
5 その他思想
5-1 根本原因分析
RCA:root cause analysis
- 5-Why分析(なぜなぜ分析)
- BOSCAR
5-1-1 なぜなぜ分析
個人的には下記のタブーがあると考える。
- 個人に対してなぜなぜ分析をする
- 絶対に個人へ向けるな。体制や組織に対して行え。
- なぜなぜの向き先が個人に向かうと、ただの人格攻撃になりうる。
- 仮に改善されたとしても、改善されたのはその人だけである。組織としての改善は無い。
- むりやり5回「なぜ」を出そうとする
- 5回は下限ではなく上限
- 「なぜなぜ分析だから、あと5回なぜを繰り返してください」というやつは手段と目的を履き違えている。
- 根本原因が特定できるのならば1回でもいいし、100回でもいい。
5-2 指摘するときは自分の事を棚に上げる
例えばAさんがBさんのコードレビューをしているとき
A「この書き方は駄目だけど自分もこの書き方しているからいっか。指摘したら面倒だし。」
というクソみたいな思考。
自分の事は棚に上げて指摘しろ。
それが明らかに間違っているならば指摘しないと後々手戻りや不具合、クソコードという形で襲い掛かってくる。
認知負荷の発生。
- | Aが指摘 | Bは改善 |
---|---|---|
1 | する | される |
2 | する | されない |
3 | しない | される |
4 | しない | されない |
3に関して、Aが指摘事項を認知している時点でBは指摘事項を認知していない。
即ちBが自ら改善する可能性は低いため、3はこの表から除外する。
その場合、指摘しなければ改善される可能性は0だが、指摘すれば改善される可能性が存在しうる。
指摘しない場合、モラルとモチベの低下を発生させる。
モラル:自分もしていないし相手にも指摘しなかったから、自分もこのままでいいや。
モチベ:指摘したからには自分も直さなければならないという気持ち。
5-3 設計書はADRであり脳内INDEXである
ペライチでいい。
大まかなフローとWhyが書かれていればそれでいい。
5-4 デザイン思考
問題解決のためのマインドセット。
- 問題提起:トピック選定
- 共感:情報収集
- 定義:解決対象の選定
- アイディア:ブレスト
- プロトタイプ:検証
- テスト:評価
- インタビュー
- Why分析
- 早めにプロトを作って客に使わせ、要件を掘る
「もしかして~でしたか」という確認は誘導である。
本来の要望をくみ取ることができなくなる呪いの言葉。
5-5 返事はなるべく早く
相手の作業を止めることになる。
コンテキストスイッチを発生させない。
認知負荷低減・生産性を低下させない。
キーエンスの如く。
返事は早い方が、契約がうまくいくらしい。
5-6 泳ごうとすらしない奴は沈めばいい
泳げない奴は沈めばいい。(闘うプログラマー[新装版]より。)
つまり自走できない奴は知らん。
しかし上記はマイクロソフトでの話。
日本の中小企業で、そこまで要求するのは酷かと思う。
なので、私は「泳ごうとすらしない奴は沈めばいい」と考える。
「泳げなくても泳ぐ意思がある奴」は全力で支援する。
泳ごうとすらしない奴は知らん。勝手にしろ。
時間の無駄なので距離を置く。
5-7 モデル化
情報収集⇒モデル化⇒実践が学習のフロー。
モデル化は名前をつけろ。
5-8 まともな要件定義など無い
諦めて自分であるべき姿を考える。
行間を読み取って提案するしかない。
5-9 目的にフォーカスする
作業指示を受けたならば、その目的が何かを第一に考える。
作業指示が目的を達成する最適な行動である保証はない。
目的を達成できるならば、作業の内容は何でもいい。
何のためにその作業を振られたのか。
問題→根本的原因→目的→作業。
5-10 哲学における「批判」
- 本質的意味
- 対象を徹底的に分析
- 理論や概念の根本的な吟味
- 前提や方法論の妥当性の検証
- 目的
- 既存の思考枠組みの問い直し
- 新たな視点や理解の獲得
- 知的な成長と変革の促進
- アプローチ
- 徹底的な論理的分析
- 対象の多角的な検証
- 偏りや盲点の発見
- 批判の特徴
- 破壊的ではなく建設的
- 対象への深い理解を伴う
- 無前提の懐疑ではない
批判は、思想の深化と革新のための根本的な知的営み
5-11 「考える」方法
積極的に考えてもアイディアは出にくい。
出ないものに時間をかけるのは無駄である。
積極的に考えなくてもいいので、考える対象を頭の片隅に置いておく。
そうしておけば、普段の生活の何かしらのイベントがそれを起爆する。
「これこれこういうことがあった。そういえばこの事象は例の件に当てはめるとどうだろうか」とか。
積極的に考えるのに比べ、こちらは「考えの源泉(イベント)」があるので、アイディアは出やすい。
風呂入ってる時や、寝る前に起爆しがち。
5-12 その他
- 常にメモを取れ。
- 教えたがりであれ。自分の知らない技術でも相手が困ってたらググって教えろ。
- 相手を否定しない
- マイナスの言葉を吐かない
- ろくなマネジメント体制が無い事やク◯コード塗れが当たり前だと思え
- 出向先に期待すんな
- だからそれらに対してイラつくな
- 逆にそれらに対してお前が改善していけ
- 「良きシステム」とは
- 知らん
- プラグマティズムで考えれば「良い効果・価値を生み出すもの」
- ルールは無いと逆にメンバーの行動を制限する。
- 最低限のルールを
- 背景情報/根本的原因/目的の明確化
- VUCAを取り除く。
- ペシミズムであれ
- 全てうまくいかないし、全て失敗すると考える。
- そして、その失敗を防ぐことを考え続ける。
- それは提案やアイディアの創造に繋がる。
- 会社と意見が異なってもそれはそれでいい
- 弁証法
- 対立する意見を統合してより高い次元の命題を導き出す
5-10-1 自分とは何か
分からないのでプラグマティズム的な観点で思考する。
周囲の物事に対して、プラスの効果や価値を提供する生物であると思っていたいし、
そうありたいし、あり続けたい。
5-10-2 思考のベース
プラグマティズムをベースとして構築したメンタルモデルを使用し、
価値/効果/改善を追求する。
6 参考書籍
- プログラマー脳
- 認知負荷に関して
- エンジニアの知的生産術
- 「既知の未知」に関して