エンジニアの認知、観察力から、解釈の特性をモニタリングしないと進捗でトラブるかもしれない

ワタシは視界に入ってくる、そのとき起きている事柄からしか、情報を得ることができません。これはワタシだけではなく、どの人も同じです。

視界に入ってくるということは、視界に入って起きる事柄には少なからず関心を抱いているか、無意識にその起きている事象に関連していることに気づかずに結びつけているだけなのです。

とするとき、認知するためには背景に多くの知識や経験が必要で、そのためには、主体的にバックグラウンドとなる形式知の蓄積と経験知の言語化の繰り返しが必要となるのです。

あるとき、メンバのエンジニアが出席していない会議の議事をチームで共有しているときに、その出席していなかったエンジニアが議事内容を取り違えて急に前のめりで噛み付いてたんですね。

その議事内容はおかしい、これまでの経緯と違うのではないか、訂正が必要だ、と。

まー、何言っているんだ、コイツは、と思ったわけです。普段から早合点するたちではありましたが。

ふと、思ったんですね。これは見えている、視界に入っている目の前の出来事で得ている情報が少ないのではないか、と。言い方を変えれば、情報共有が十分出来ていないということもできますし、コミュニケーションが不足しているということもできます。

でも、視界自体が狭かったり、広かったとしても関心事項ではないのだとしたら、それは幾ら情報共有していても結果は期待する情報共有はできないし、コミュニケーションだって同じ事象としてしか表面には出てこないのです。

視界自体が狭い、つまり、認知する窓が狭いということは、目の前で起きている事柄に対しての観察する力が何かしら不足していることを疑わざるを得ません。認知しようとしていているのにも関わらず、その前で起きている事象を観察対象とできないのですから。

認知の窓が狭く、目の前に起きている事柄についての観察する力量も弱いとするならば、そこからもたらされる事柄に対する解釈は、限定された情報の中で観察できた方法量だけが解釈されるので、認知の窓が広く、観察する力量も十分備わっている場合に得られる解釈から導き出される結果や行動は全く違うものであっても不思議ではありません。

チームの活動においては、普段の行動や判断基準から、メンバの認知、観察する力、及び、解釈から導い出される結果をアウトプットをモニタリングして、メンバごとの特性として把握して置く必要があります。

こうした行動の結果に結びつく、内面的にもかかわず外的な活動の結果として現れるパフォーマンスはプロジェクト立ち上げの早期に把握する機会を作り、基礎データとして持っておかなければ、あとあとトラップになりかねません。