エンジニアを縛る計画思考 - 室長のひとりごち

シンポジウムやカンファレンスでワークショップをコマとして設けていることがある。定員制で、グループワークが多い。見聞きしない、でも講演のアブストラクトのキーワードに興味を惹かれて受講する。

ワークショップに参加した。初めて会うエンジニアと顔見知りになれたし、ワークは初めてで理解には及ばないが体験としては楽しい時間だった。ワークショップでこれなら仕事で活かせそうだ、と思ったやり方があった。このワークショップはまずまずだな。

そう思うこともあるだろうし、講師の立場の場合はそう感じてくれるだけでも嬉しい。

ところが、そうした気持ちは最短で会場の扉の外に出た瞬間、忘れてしまう。その気持ちが消えず、現場、チームに持ち帰りやってみたいと思うこともある。それでも、チームのメンバの顔を見るとその気持ちが消えてしまったり、諦めようと思う。

中にはその気持ちを自分に向けて、自分の仕事のやり方を変えてみようとするエンジニアもいる。

でも、多くのエンジニアは何かを得て、使ってみようと思っても実際に使おうとしたとき、使えないと感じてやめてしまう。

使おうと思ったときの対象に対して、仕事に対するアプローチとか手法とかマインドとかそういったもので何かを変えようとする。

その対象は得てして、漠としているか粒度は大きい。

やり遂げられたら素晴らしいことは確かである。ToBeとしても相応しい。

でも、この素晴らしいToBeは実行されない。

いや、できない。

なぜなら、実際に行動に移すとき、粒度が大きすぎるからだ。

『生産性をあげる』ことをやろうと思ったとする。

さて、仕事場で『生産性をあげる』と思い、ワークショップでうろ覚えの記憶を掘り起こし、『生産性をあげる』と思ったとき、手が止まる。

ToBeはToBeのままでは手をつけられない。ToDoへ分解しなければいけない。これが実行されない理由の1つ。

『生産性をあげる』としたままでプランを作ったとする。かなりチャレンジングである。

こうすればできる、

と一人合点してプランを作る。

でも上手くいかない。なぜなら、合点したつもりの前提とした制約条件も前提条件も全ての状況は刻々と移り変わっているからである。

大きな粒度のプランと想定した状況が変わっていることを気づかない。

だから上手くいかない。

こればプランを作ろうとしたときと実際作ったときの変化を考慮していないことと変化に対応できる粒度にしていないことが原因なのである。