WKTS=わからないことはとりあえず質問

http://yattom.jp/trac/public/blog/20090308 から転載しました。

いま一緒に仕事をしている若者が作った、略語？アクロニム？です。

去年からアジャイル開発をしているチームですが、わたしはアジャイルコーチとして、特にプロセス的な部分を中心に支援しています。単なる「アジャイルプロセスの導入」にとどまらない、「アジャイルな態度を身につける」ことを、チームとして達成したことが、このWKTSにも現れていると思っています。

わたしはWKTSを良いプラクティスとして強く推しますが、反対されることもあります。得てして新卒社会人は「質問する前によく調べる・考える」なんていう指導をされがちですし、そういう文化の職場も数多くあるし、自分で調べることはそれはそれで重要です。わたしも、調べるスキルを身につけなくては、まともな技術者にはなれないだろうとも思います。

わからないことがあったとき、自分で調べて解決できれば、他の人には迷惑がかかりません。自力でやったという達成感もあるし、人の時間を奪うこともないし、苦労したことは忘れずに身につくでしょう。しかし、それはチームワークとチームのパフォーマンスを無視した、身勝手な意見であったりは、しないでしょうか？

わからないことがあったとき、すぐに気軽に聞いて、聞かれた側もわかれば即答する、わからなければ「わからんから自分で調べて」と即答する、そんなことができるチームは、確実にチーム全体の時間を節約しています。初歩的なことであれば「ググレカス」と言えば済む。お互いイヤな気持ちにならずにそういったやりとりができるためには、チーム内に信頼関係と太いコミュニケーションパスが必要です。

新人が気にかかった疑問が、実はプロジェクト全体に関わる大きな問題の一端であることもあります。そうした疑問を表面化して共有することは、重要なリスク管理の手法となります。信頼関係があれば、新人に限らずベテランの人でも「ん？」と思ったとき、人と相談できるでしょう。そこからリスクを発見できるかもしれないし、場合によっては直ちに解消できるかもしれない。表面化したリスクをまた見失わないように、解決した疑問を記録して共有する仕組みも用意するべきです。

誰かが疑問に思ったことは、他の人もまた疑問に思う可能性が高い。いったん解決した問題は、フォーマットにこだわらず記録して共有すれば、プロジェクトの知識という資産として残ります。網羅的な説明資料よりも、ピンポイントで役に立つ、しかも作成・維持にかかるコストが小さいプロジェクトナレッジベースとなります。疑問を埋没させず表面化し、さらに解決したときにはちゃんと記録するように促す(システム的にも、人的にもそうした仕組みが必要)。解決にかかった時間から、「個人の成長」という曖昧な効果を期待するだけでなく、プロジェクトの資産という目に見えるリターンを得ることができます。もちろん、個人的なメモをするだけではなくなるので、プロジェクトの記録を残すという作業からより深く客観的に疑問と解決を整理できるという効果もあるでしょう。

「わからないことはとりあえず質問する=WKTS」が、ひとつのプラクティスとして成立するかは微妙かもしれません。ですが、そうした文化を醸成できるチームは、コミュニケーションの薄い個人主義的メンバーの多いチームより、確実に高いパフォーマンスを出すことができます。