ソフトウェア開発者の道具箱 | Moonmile Solutions Blog の第4弾は「知恵の箱」です。金の鍵 は自分から外部に発信する外向きの話ですが、知恵の箱は外部から自分に取り込む内向きの話になります。
「知恵」というのは、自分の外側にながれていく沢山の「情報」のことです。それは Twitter に流れる TL であったり、テレビから流れて来るマスコミの情報であったり、社内で流れて来る共有すべき情報であったり、チームで仕事をしているときのメンバからの情報だったりします。それぞれの関係があるので、本質的に「知恵」になるかどうかはわかりませんが、まあ、知恵の元ということです。
金の鍵のところでも話しましたが、ひとつ重要なことは「情報を制限する／開け閉めする」ことが必須ということです。つまり、開け閉めする箱の蓋は、自分で持っているにも関わらず、それがあたかも「開けっ放し」にしてあって、それは決して絞められないような心理状態に陥るということです。勿論、外側から暴力的に情報を流す（いわゆる、DV に近いもの）こともできますが、一般的に言えば、開け閉めの鍵／蓋は自分でもっています。
不特定多数の情報から「知恵」を得る
あなたが、テレビや Twitter や新聞やメーリングリストや、様々なところから情報を得ているときに、それを「見聞き」する鍵は、自分にあることを忘れないようにしてください。流れ込んでいるテレビからの情報は、テレビを消すことによってなだれ込むことをやめることができます。なだれ込む情報がなくなると、「不安」になるかもしれませんが、しばらくすると「不安」が消えます。ある意味で中毒のような症状に似ています。一見、取捨選択しているようで、なだれ込む情報に流されている場合もあれば、自分の都合のよい情報だけをピックアップして納得してしまう場合もあるでしょう。なので、そこから得るものは、
- 流れて来るのは単なる事実
- それが自分に関わるかどうか
に制限しておきます。
まあ、聞き流しできる精神状態の場合はいいのですが、とある自体に陥ったとき、一見、たくさんの情報を得ているように思っても、単に情報が上滑りしてしまって「知恵」になってないことが多いのです。
リーダーがメンバの「知恵」を得る
プロジェクトリーダーやマネージャが、プロジェクトメンバから情報を得るときに、いわゆる「吸い上げ」という言葉を使うことが多いのですが、この情報発信は、
- 自発的にメンバから流された情報なのか？
- 客観的な情報なのか？
に分類されます。警察の尋問ではないので、無理矢理聞き出す必要はありません。聞き出せないのならば聞き出せないなりの方法もあり、報告があればあったでそこから虚偽であるかどうかのチェックが必要になってきます。
例えば、プロジェクトリーダーがメンバから進捗を聞く場面を考えてみましょう。一般的に進捗会議を開いて、各自メンバが進捗率を報告する、そして、リーダーやマネージャが進捗状態をまとめる、というスタイルが多く使われます。しかし、
- メンバが虚偽の進捗を報告しているのではないか？
- リーダーやマネージャが虚偽の進捗を作るのではないか？
という懸念が残ります…というか、大抵、ここに陥ってしまうんですけどね。そもそも、なぜ「進捗率」を調べるのかというと、進捗が遅れることを未然に知ることによって、メンバを増やすなり、スケジュールを調節するなりの、対策をするための進捗会議なんですけどね。大抵は、「オンスケですか？」の進捗会議になるで、そりゃ「オンスケです」になるしかないでしょう。進捗自体は、コード量とか、勤務時間とかの客観的な指標を使えばよいので、実は進捗会議自体意味はありません。
もう少し、捻た見方をしてみると、
- メンバが虚偽を報告をする「要因」が、プロジェクトメンバ内にある。
- リーダーやマネージャが虚偽申請をすると得をする「要因」がある。
状態があるということですよね。そういう「要因」自体を、進捗報告とは別に探っていき、悪い要因を取り除いて正常な状態に戻すこともできます。
まあ、そんな訳で、上下関係のあるときは、直接情報を仕入れたとして「知恵」を得ることはできません。そうそう、孫子の兵法な感じで、内部的な間諜を入れておくというのお勧めです。間諜な話は、また今度にしましょう。
同僚のチームメンバから「知恵」を得る
どちらかというと、同列のあるメンバから「知恵」を仕入れるほうが有効です。同じプロジェクト内で、プロジェクトの成功という同じ目標を共有しているならば（暗躍する場合は、共通な目的にならないのですが、それは別の話で）、相互の情報のやり取りをしたほうがよいでしょう。
このあたり、仕事で言えば「分担」とか「分掌」とかいう感じで、壁を作ってしまうことが多いのですが、それは効率的ではなくて、ちょっとだけ重なりを作っておくのがコツです。「知識創造企業」にある「さしみプロセス」というやつですね。確か、ピープルウェアにも「のりしろ」として似たようなことが書いてあります。
ペアプログラミングみたいに、完全にコードを共有しながら作ることが理想的でもあるのですが、常にできるとは限りません。と言いますか、人によってペアプログラミングを長くやるとストレスが溜まるし、ひとりでガシガシと作っていったほうがよい場合もあります。そこは、程度の問題だったりするのです。その程度の問題が「のりしろ」になります。
完全に分離するのではなく、逆に完全に同一の仕事をこなす（相手の仕事を完全に理解する）のではなくて、ちょっとだけ理解して踏み込めるようにしておきます。それは「日常的に聞けるスタイル／状態にしておく」という物理的な方法もあれば、ちょっとだけ作業を入れ替えてみるという方法もあります。そうそう、家事を分担するときに単調で辛くなったら（相手のほうが楽じゃないかと思いはじめたら）、分担を交代してみることもアリですね。ちょっとだけ交代してみると解るのですが、最終的にはそれぞれの得意な分野に落ち着くのが「効率的」であったりします。そのあたりは「尊重」も含めてなんですけど。
仕事の同僚から何かの「知恵」を得るときは、ちょっとだけ相手の領域に踏み込みます。ちょっとだけ押して、度合いを見て、元に戻ります。これは、会社の社風であたったり、仕事場の雰囲気であったりするわけですが、ええ、
- そういう場を作るか
- そういう場に移るか
ということですね。私としてはどちらもお薦めです。
