仕事とはいかに早く「ロジックのビルを建設できるか」が重要かと感じるこの頃です。

とある社内の光景

社内でMTGがあったとして、自分がファシリテータをやっているとします。 議論が始まると、参加者が一斉にパチパチ 手元のキーボードを叩いてメモでもしています。

最後に「パソコンで今書いてたメモ、議事録にしたいからデータもらえる？」とランダムに聞いてみると、大抵の場合

  • 「自分用のメモなので多分役に立ちません」
  • 「そのまま使えないと思います」

こんなケースが多い。もちろんパソコンのメモを通じて、自分で理解しようとはしているのだろうと推測しますが、 とりあえず聞こえた内容を写経しているだけでは、キーボードタイピングの訓練くらいにしかならなそうです。

戦略立案や要件定義の難しさ

企業の戦略立案やソフトウェアの上流工程など、問題自体を定義しながら解決しなければならない作業は割りと大変です。 唯一の答えはなく、誤った方向性の結論を出してしまうと、後工程の人が全員大変な目にあってしまいます。

当事者としてそんな課題にでくわすと、頭も沢山使わないといけないので、ついついメールチェックのような簡単な業務に流されてしまいがちな人も多いと思います。 このように後回しにした結果、課題のデッドラインが近づき、最終的に「これでいいか」くらいのもので終わらせてしまう。

なぜダイバーシティーは必要か　人口減少時代に勝つ 日本マイクロソフト会長　樋口泰行氏（２） http://style.nikkei.com/article/DGXMZO05506030R00C16A8000000

また創薬のように直接材料費はきわめて少ないがＲ＆Ｄ（研究開発）に巨額の費用を要するビジネスでは、Ｒ＆Ｄの方向性や開発のプライオリティーを間違えると多額の損失につながる。それだけ戦略性が高い。

上記のようなR&Dの事例にかぎらず、どんな会社でも人員計画を間違えただけで、「アサインする仕事がない」or 「人員が足りない」となってしまいます。 とにかく方向性を決める最初の段階がとても重要です。ただ分かっているけど、難しさ故に、ついつい易きに流れてしまう。

最近発見したTIPSは、これ自体を「ロジックでいかに早くビルを建設できるか」というゲームだと思うことです。 事実、自分が理解していないこと、スケジュール、担当者・・・沢山の要素を組み立てていかに早くビルを建設するか。 既にどこか事例があるなら、それを足場に、高速でビルを組み立てる。ソフトウェアであればRFCを見る、Apacheプロジェクト一覧見る、Github見る。

ロジックのビルがある程度高くなったならば、今度は耐震性のあるビルを作るようにしていきます。 とにかくスタート地点から一歩でも前に進んだ状態に留まり切ることが重要です。スタート地点に留まってはダメです。

このように「ビルの建設」というような具体的なイメージを想起させるメタファーを自分の中に持てると、どんどん作業が進みます。 具体的な進捗のイメージが自分の中に湧くからです。メタファーに関してはCode Completeでも指摘されています。

最初の話

議事録を作るのしても、建設用の資材をただかき集めて散らかして終わりではなく、自分なりの小さなビルを組み立てることを意識することです。

すなわち文書として具体的に完成させきるほうが重要だということです。 会議中に全部まとめきれないのであれば、メモを頼りに自分なりに補完して、あとで完成させることです。

この日々のトレーニングを重ねることで、どんどん早く仕事のアウトプットが出せるようになるのではないかと感じます。 という訳で皆さん、是非ともよろしくお願いします！

実践編

「それではビルをどうやって建てればいいのか」という疑問も湧くかと思います。 今後執筆予定です。乞うご期待下さい。