吉澤さんいわく、

「慣れるまでは、要素を漏れなく洗い出したつもりでも、抜けていることが多かった。この行動の前にこういう判断があるのでは、とみんなでチェックし合いました」

　大森さんも言う。

「打ち合わせがうまくいっていなかったのは、『もしも』という仮定が抜けていたからだと思います。分岐がないアジェンダばかり作っていたから、クライアントに想定外のことを言われたときに対応できなかったのでは」

●プログラムは書かない

　オブジェクトに分解する練習にもトライした。

「プログラミングでいうオブジェクト指向という考え方につながりますが、動詞と名詞に分けて考えるという方法があります。たとえば車なら、『走る』という機能や、『タイヤ』という部品がある」（大森さん）

　動詞と名詞に分解していくと、それぞれのパーツが担っている機能がクリアに見えてくるという。

「プログラミング脳」班に参加するまでは、仕事で思わぬアクシデントが起きると「わー！　どうしよう、大変！」となっていた、と吉澤さん。でも、

「要素分解ができていると、改善のアクションをどこで起こせばいいのかがわかる。これを改善するためには、ここに手を打てばいい、とあわてず冷静に考えられるようになりました」

　フローチャートの書き方は「UML（統一モデリング言語）」という世界標準の仕様にならったが、プログラムを書けるようになることは目指さなかった。そう割り切って身近なテーマに落とし込んだことで、具体的な業務に生きる「プログラミング思考」が身についた。（編集部・高橋有紀）

※AERA　2016年10月31日号