あまり推敲していない記事になりますが、若干の参考にでもなればという気持ちで書き起こしてみました。

はじめに

弊社社内のLT会でメンタルモデルというワードが出てきたので、自分自身にどのようなイメージのメンタルモデルが形成されているのか、どうやって活用されているのか、分析してみます。

具体的に

メンタルモデルとは

メンタルモデル（英: mental model）とは、頭の中にある「ああなったらこうなる」といった「行動のイメージ」を表現したものである[1]。

メンタルモデルは、外界の現実を仮説的に説明するべく構築された内的な記号または表現であり、認識と意思決定において重要な役割を果たす。メンタルモデルが構築されると、時間とエネルギーを節約する手段として慎重に考慮された分析を置換する。

簡単にまとめると、我々が感じるインプット（五感）の結果、どのようなアウトプットが構築されるのかを予測する仕組みと理解しています。その目的は、インプットからの分析、判断にかかるエネルギーや時間を節約するため、と読むことができます。

コーディング段階のメンタルモデル

ここでのインプットは、

Issueなどでフィーチャーとして説明されている実装項目
設計書、仕様書

などとします。

インプットを読み込んで、メンタルモデルに照らし合わせてどのように思考するかをトレースしてみます。

これはあくまで私のメンタルモデル、思考のイメージを書き出したものです。

まず仕様確認。実現したいこと、最終的なアウトプットのイメージをインプットの文書から読み取る
過去に同じようなものを実装したことがないかどうか思案する
1. それが頻回に実装する内容であれば、実装に至るまでの道筋（タスクバラシ）がすぐアウトプットできる。
2. 同様、または類似の機能を実装したことがあるならば、その時の記憶を思い出しながら実装に至るまでの道筋を頭の中で構築する。
3. 実装したことがない、もしくは実装したことがあるかもしれないが具体的な方法を忘れている場合は実装に対してどのようなことを調査すれば良いか頭の中でリストアップする
  1. 過去に同様の調査を行ったことがあるならば、調査完了に至るまでの道筋がすぐアウトプットできる
  2. そうでなければ、過去の調査経験から汎用的な調査手順に則って調査をしていく

実装方法を調査する必要のないタスクであれば実装完了までのイメージがすでにできていて、すぐに実装に取り掛かれます。
そうでなければ、まずは調査タスクから始めることになります。ここでも過去に同じような調査を経験して調査完了までのイメージが形成できれいればそのまま調査に進めます。未知の分野を調査することになった場合、自分のイメージにある「汎用的な調査手順」に従って調査することになります。

汎用的な調査手順については本記事のトピックから外れるので、別の機会に書いてみようと思います。

デバッグにおけるメンタルモデル

LT会で話題になったのがこのデバッグにおけるメンタルモデルです。

バグの発生を２パターンに分けて考えてみます。

エラーメッセージが出る場合
エラーメッセージが出ず、出力結果が想定と異なる場合

エラーメッセージが出る場合

１行で書くと

対処はパターン化されており、ほとんどの場合はエラーメッセージの内容からどのパターンか類推可能。

具体的には

まずはエラーメッセージを確認する。
エラー内容が過去経験におけるエラーパターンのどれに一致するかを判断する。
1. 一致するものがあればパターンに基づく対処法に則って修正する
  - NullReference的なエラー。変数のtypo、代入し忘れなどが考えられる。
  - 文法エラー。セミコロンついてない、カッコが足りていない、など。
2. もし一致するパターンがなければ次のステップへ
スタックトレースを確認し、実装コードの前後のトレース内容を確認する。ライブラリが出しているスタックトレースはとりあえず無視。確認しても何かわかる可能性が少ない
エラーメッセージで検索する。google検索であればダブルクォートでくくる完全一致検索を活用。その際固有名詞や固有の変数名は含まずに検索する。
1. 検索結果にノイズが多い場合はStackOverflowなどに絞って検索する。
これで原因の糸口が掴めるのであれば対処する。それでもダメならメンバーに相談する <-New!!

このNew項目は最近自分のメンタルモデルに追加されました。

エラーメッセージが出ず、出力結果が想定と異なる場合

１行で書くと

エラーメッセージの確認が仕様確認になるだけで、他のプロセスはほぼ同じ

具体的には

まずは仕様(期待する状態)を確認する。
現状の出力結果が過去経験における「使用に対して現状の出力結果がどう違うか」のどれに一致するかを判断する。
1. 一致するものがあればパターンに基づく対処法に則って修正する
  - 想定と異なる文字列が出力されているのであれば、変数名の指定間違いが最もありそう。
  - 文字列が出力されていないのであれば、モデル初期化してない、取得条件の間違いなどモデル側で何らかのミスがある。リアクティブなシステムであればバインディング方法にミスがある、コンポーネントの初期化タイミングで発生している、などの当たりがつく。
  - 数値が想定と異なる場合、出力する集計方法のミス、集計元モデルの抽出条件ミスなど。
2. もし一致するパターンがなければ次のステップへ
出力に直接関係する変数に何か代入している箇所でブレークポイントで止めたりログを挿入したりして中身を確認する。参照をどんどん遡っていき想定と同じ内容が現れたら、その前後の処理に何かしらの問題があるはず、と当たりがつけられる。前述のスタックトレースを手動で追っていくような感じ。
これで原因の糸口が掴めるのであれば対処する。それでもダメならメンバーに相談する <-New!!

テックリードのメンタルモデル

自分がテックリードとして、他メンバーからある実装タスクにおいてタスクの分解や実装方法の相談を受けた場合を想定します。

まず実装タスクの仕様、要件を確認する。出力、結果のイメージを実装者と共有するため。
同様、類似の機能を実装した経験があれば、その経験から実装モデルの構造決定、コーディングまでの道筋を考える。
- 同様の実装がプロジェクト内、または他のプロダクトの実装に存在するのであれば、その実装を参照してもらうのが最も手っ取り早く、工数も少なくなる。
- そうでない場合、道筋は複数ある。また、今のプロジェクトを進めるにあたり重視する優先項目もここで考慮する必要がある。とにかくスピード優先であれば技術的負債はある程度出る前提で実装が一番早そうな方法、そうでなければ技術的負債がなく、かつ想定される将来の変更が容易になりそうな実装モデルを考え、提案する。
- ここでテックリードとしての心理として、この選択が本当に最適だろうかという不安が出てくる。この不安に打ち勝つだけの説得力がこれから伝える実装案に乗せられるかどうか。なぜ不安になるかというと、実装が終わった後で 「やっぱり別の方法で実装した方が良かった」 と思えてしまうことが多いからである。
実装モデルのイメージが描ききれない、または描いた実装モデルイメージが適切であると自信が持てない場合は、他に知見があるメンバーと相談して実装モデルの細部をディスカッションする。
- という判断がすぐにできれば良いのであるが、大抵は頭の中で実装イメージをこねくり回してより最適なものがないか考え込んでしまう。テックリードの責務としてここで結論を出さないといけないと思いがち。しかしここで考え込むと相談相手の時間も奪ってしまうことになるので宜しくないメンタルモデルが形成されていると言える。

まとめ

開発業務における3つの領域でそれぞれメンタルモデルを考えてみました。
結果は、どの領域でも「過去の経験」ベースでまずいずれかのパターンに当てはまるかを考え、パターンにハマらなかった場合に思考と試行を開始する、という点は共通しています。
今回はメンタルモデルが開発業務にどのような作用をしているかを中心に考察しました。自分の持っているメンタルモデルの言語化と書き出しは時間がかかりそうですぐには難しそうです。言語化、可視化することで他者に対して良いメンタルモデルの形成に役立つのであれば頑張って書いてみようかなと思います。