チームで話をしたときに、記憶すると理解するの違いはなんだろうという話題になりました。非常に興味深いテーマなので、ここでも改めて考えてみたいと思います。
発端
scrum開発をはじめる前のチームメンバは言われたことをやることが多かったようです。こういう風にやってほしい、こうすればできると思うからやってみてほしい、という感じです。
scrum開発がはじまると言われたことをやるのではなく、問題を解決するのが主な作業になります。これは開発チームとして自律していくために必要な変化だと思っています。このときに記憶すると理解するに関して深堀してみようとなった出来事がありました。
あるとき、作業について話し合いをしているとやることはあっているのにそこまでの経緯があっていないということがありました。なぜこれをやるのか？に答えられないという現象です。興味深いとともに変わったほうがいいと思ったので深堀してみました。
なぜ・ということは
記憶するというのは点に着目することだと思います。その上で思考には流れがあって点と点はつながっているはずであり、点から線が出て点ができるのだと思います。こと問題解決においてはトライアンドエラーの連続でトライアンドエラーの回数は多いほど良いと思います。この場合、1つの点からは複数の線が出ていて何層かの階層構造になっているイメージになります。このとき、なぜは階層を1つ上に、ということはは階層を1つ下に移動する方法になると思います。
理解するとは
理解するとは、点と点を繋ぐ思考のツリーを再構築できることではないかと思います。ツリーの上層から今の点までを繋ぐことができ、必要に応じて道中の点を補うことができると理解しているという印象になると思います。
では、どうのようにして理解しているかをチェックするのでしょうか。おそらく説明できることが理解していることのチェックになると思います。
まずは自分自身が納得できること、自分自身に説明できることが重要ではないかと思います。自分自身への説明すらできないのであれば、明らかに理解が足りない状態です。まずは定期的に自分自身に説明してみることが大切だと思います。
自分自身への説明ができたら、他者への説明です。これができたら理解している状態と言えるでしょう。他者にわかりやすく伝え、質問にも答えられる状態が理想です。
そのために有効なのが、壁打ちなど他者からなぜ・ということはをもらうことです。もしくはベアプログラミングなど、特定の物に対して独り言をしてみて自問自答することだと思います。
コツ
理解を深めるにはある程度の記憶をする必要があります。このとき、記憶は簡潔な日本語になるようにするのがコツだと思います。単純に複雑な文章は記憶しづらいというのもありますが、簡潔な日本語にすると階層を合わせやすいと思っています。日本語を長くするといろいろな条件や状態を含めることができるので、記憶の点が大きくなっていき線が出にくくなってしまいます。記憶の点のなかに、思考のツリーができてしまうこともありツリーの複雑度があがり、理解を困難にしてしまいます。
最後に
改めて記憶すると理解するの違いについて考えてみましたが、私としてはこのようなイメージになっているようです。なんとなくですが、このようなイメージはもとを辿ると勉強の仕方が影響しているのかなと思いました。私は記憶力がないので、極力記憶するものは少なくするように勉強していたように思います。
また、ストーリーを作って記憶する方法にも近いかもしれません。ツリーを再構築するにはストーリーが必要なので、覚えやすいのかもしれません。意識的にツリーを再構築するときに極端な煽りをしてみたり抑揚を意識したりすることがあります。これも理解するには有効なのかもしれないと思いました。
