メンタルモデルを伝えるためのツールや手法は？
(lobste.rs)- システムや製品を理解するためのメンタルモデルを、他の人に伝え、共に育てていくのに効果的なツールや手法を問う内容
- メンタルモデルを育てる方法として、システムを自ら作り保守する経験が挙げられている
- 伝達のやり方は、ナプキンへの走り書き、隣で身振りを交えて説明すること、一緒に考えながら言葉でほどいていくことのような、非公式な説明に近い
- 機能一覧や表面的な領域を漏れなく整理した文書は包括的ではありうるが、主題のメンタルモデルを作ったり伝えたりするには不十分かもしれない
- よく設計されたツールや製品を実際に使う経験は、メンタルモデルを育て、伝える過程の両方を同時に助けうる
質問の焦点
- どのようなツールや手法が、メンタルモデルを伝え、成長させるのに効果的かが核心
- 質問は次の二つの方向をあわせて扱っている
- メンタルモデルを育てる方法
- メンタルモデルを他の人に伝える方法
例と問題意識
- メンタルモデルを育てる例として、システムを作り保守するやり方が挙がっている
- メンタルモデルを伝える方法は、次のように現場で一緒に理解をすり合わせる形
- ナプキンに走り書きする
- 隣で身振りを交えて説明する
- 一緒に考える状況で説明する
- 機能を列挙したり、表面的な範囲をカタログ化した文書は包括的でありうる
- しかし、そのような文書がその主題のメンタルモデルを作ったり伝えたりするところまでつながるとは限らない
- よく設計されたツールや製品を実際に使う経験は、メンタルモデルの成長と伝達の両方を達成できる方法として扱われている
- 最後の問いは、それぞれが効果を感じたツールや手法、そしてそれがなぜ効果的なのかを尋ねている
1件のコメント
Lobste.rs のコメント
オントロジーログは、オントロジーを伝えるのに適した形式主義です。
内部状態が多い長時間実行プロセスなら、状態図とステートチャートがシステム文書化に役立ちます。
システムのユーザーは通常、実際のシステム構造を知覚できません。理由の一つは、Nakatomi spaceがシステムを誤用するユーザーにだけ見えるからであり、weird machinesのような意図しない動作のための状態空間領域が別に存在するからです。
もう一つの理由は、the purpose of a system is what it doesという見方のように、ユーザーはシステムが自分にしてくれることだけを見て個人的な存在理由を作れますが、設計者や保守担当者が意図した全体の目的には気づけない場合があるからです。
本を書いて、編集者を雇えばよいです。
これは教育の中核的な問題に近いのではないかと思います。やってみて学ぶことと、専門家による指導という二つのカテゴリーを挙げましたが、三つ目は教えることです。
より重要な問いは、似た原理や設計を再利用しながら、より習得しやすいモデルを作れるのか、あるいは抽象化によって完全に習得する必要を減らせるのかです。ただし、その抽象化がどこで漏れるのかはよく定義されている必要があります。
関連して、Felienne Hermans の The Programmer's Brain は興味深いです。幼い子どもに数学などを教えるときの「私がいくつも例題を解いてみせるから見ていなさい」というやり方が、プログラミング教育にもかなりうまく効くという点が印象的でした。
職場でオンボーディングするなら、「このバグを私がどう調査するか見ていてください」や、「しばらく触っていなかったこのサブシステムを私がどう把握し直すか見ていてください」といった形になるでしょう。
ソフトウェア工学では、メンタルモデルをユーザーストーリーと技術実装に分けて見ると役に立ちます。
通常、ユーザーストーリーは一次要件、つまり達成しようとしている価値であり、技術実装はその目標を達成するために必要な二次的要素です。
ユーザーストーリーは顧客に提供する価値を説明し、技術実装は作ったシステムの制約がユーザーストーリーをどのように制限するかを説明します。
ときには両者が重なり、ユーザーストーリーが技術実装に制約されたり、逆にユーザーストーリーを達成するために技術実装を選んだりします。しかし、多くのシステムの動作はどちらか一方の枠組みで捉えられます。
その次は、最も合うツールを選べばよいです。UML はオブジェクトの地図を描くのに向いており、フローチャートは流れを説明するのに向いています。状態図は許可・不許可の状態と遷移を説明するのに向いており、変数と状態表は取り得る値をすべて列挙するのに向いています。
システムを描く方法を学ぶ最良の方法は、異なる三人に、それぞれが考える図を描いてもらうことです。同じ考えでも表現の仕方は驚くほど多様で、ほとんどは同じように妥当ですが、テーマの異なる側面を見せてくれます。芸術に似ています。
主に、より形式的な図式化を使います。それでも画面共有中にリアルタイムで落書きするときは、ときどき jspaint を開き、後で他の人が見る価値がある内容なら Figjam のようなものも使います。
図式化と指差しがうまく機能する理由は、それらが私たちの持つ最も古く、今でも有用な注意誘導ツールだからです。言葉を話す前から私たちは指差して泣き、位置やナビゲーションでは言語より指差しのほうがはるかに即時的なので、レーザーポインター市場は今も残っています。
Peter Gårdenfors の The Geometry of Meaning: Semantics of Conceptual Spaces は、このテーマをかなり詳しく扱っています。Barbara Tversky も図式化や認知空間の構造化に関する研究が多く、Peter Cheng の “What Constitutes an Effective Representation?” は、効果的な表現の基準をかなり定量的に示しています。
シャドーイング、ペアリング、ホワイトボードセッションが良いです。このとき、双方が描き、質問する必要があります。
モデルを拡張したり変更したりするプロジェクトを一緒に選んで実行すること、クイズ、学習者が教え返すこと、暗記して手で書いてみることなどの方法もあります。
単純な暗記は常に他の方法と併用すべきで、それだけが唯一の方法になってはいけません。ホワイトボード以外で図式化や落書きをすること、他のモデルや解決策と比較するギャップ分析、ハンモックタイムのような熟考的で半ば無意識の振り返りも役立ちます。
伝達のための表現と、実際のタスク遂行のための表現は区別すべきだと思います。後者はここでは言及されていませんが、「実行」に近いものです。
実行可能なモデルは伝達力に劣ることが多く、たいてい抽象化の境界が悪いからです。コンピューティングでは、ほぼ常に漏れる抽象化です。
何が何をするのかを把握する作業は、それを効率的に行わせるために積み上げられた努力の山に覆い隠されることがあります。だからナプキンに走り書きしながら、「現在のあなたのメンタルモデルに合う抽象化レベルでは、このシステムはこう動く」と説明する必要が出てきます。
文書は別の成果物なので、実行モデルより遅れがちであり、それを防ぐには非常に手間をかけて保守する必要があります。もっと大変な方法は、文書をコードに直接結合するか、文芸的プログラミングのように文書をコードより前面に出すことです。
したがってメンタルモデルを伝えるときは、たいてい最小限の労力と保守で済む方法、つまりナプキンへの落書きと、時間をかけて実際のシステムを一緒に扱う方法が適しています。
新人が設計文書の作成ではなく、簡単なバグ修正から始めるのには理由があります。
新人はやってみながら学ぶ必要があるので、チュートリアルが最も適しているかもしれません。しかし、ある程度触った後には、いくつかの誤解が混ざっている可能性が高く、ナプキンの落書き上での説明によってそれを解きほぐせます。
だからチュートリアルを書くことにしたなら、「すべて」を網羅する文書を作ろうとするのではなく、焦点のはっきりした良いチュートリアルを書くべきです。
書くことが答えです。
ソフトウェアは個人向けの動的メディアなので、かなり興味深いです。
インタラクティブシステムが役に立つと思います。たとえば、Python とボックスで表された変数を教えるビジュアルデバッガのようなものです。