読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ググルナカス / 仕事とサーチ

Project Management

もうそうもうそう。書籍「ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド」を読んでいたらケーススタディの中で面白い会話があった。ある作業の方法が分からないので検索エンジンでリサーチをするかどうか、チームメンバーで協議していたのだ。これは良い考えだと思う。周りの人に声をかければ解決するような問題について、チームの中でどれだけ無駄なサーチがされているのだろう。これからはググレカスではなくて、ググルナカスだ。
http://www.flickr.com/photos/22127803@N02/5267464508
photo by MoneyBlogNewz

Peteのアップデートの番になり、彼は、RTCがチームが使用できるバッチをリリースしたが、それをダウンロードし、チームのためにインストールするための手順がよくわからないと言っている。彼は更新の取得場所を把握するためにネットを探索する時間を使うべきか尋ねている。
Mark: 「いいえ、Pete、私はあなたが貴重な時間を上手く使えていないと思います。私はTerryと話して、更新のインストールについて方針と手順を見つけるつもりです。私は、ホワイトボード上の私たちの課題一覧に課題として、これを囲うと思います。対処として、上手くいけば、明日の日次ミーティングでこの課題を一覧から削除できるでしょう」
ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド 第17章 ケーススタディ

悪い検索

目の前に何かの問題が存在したときに、現代では人はつい検索をしてしまう。それは非常に便利だけど、はたして検索することが正しいのかをもう一度考えたほうが良いと思う。

  • チームメンバーが答えを持っているかもしれない。聞けば瞬時に解決するかも。
  • そもそも問題を正しく捉えられていないかもしれない。いくら検索しても答えには辿り着かないかも。
  • 答えはチームローカルな情報資源(文書やwiki)の中にあるかもしれない(普通、そういったものは検索では辿り着けない)
  • あなたが問題に直面しているという事は、別の大きな問題の一部かもしれない(例えばマニュアルが間違っていたり、不親切なのが真の問題かも)

そう考え始めたら、プロジェクトメンバーがいったいどれだけの無駄な検索をしてるのか心配になり、ゾッとする。
本来は問題にぶち当たったら、まずその事態を共有すべきなのだ。しかし「検索」があまりにも強力かつ容易なので、人は共有するより検索を選ぶかもしれない。なにより問題を共有するのは手間がかかるから。

良い検索

じゃあ極端な話、検索を禁止してしまうのはどうだろうか。それはあまりに極端だとは思う。考えるに「良い検索」と「悪い検索」があって、「良い検索」まで規制したらおそらく生産性が大きく下がるだろう。例えばこんなもの。

  • 事実の確認
  • 記憶を補うような検索(だいたい覚えているけど、正確なところは思い出せないような・・・あれ、なんだっけ?)
  • 存在することがわかっている情報へのアクセス(よく覚えていないけど、たしかこんな公開情報があったはず・・・)

会話術(質問術)には「オープンクエスチョン」「クローズドクエスチョン」というものがある。前者は自由回答を求めるもので、後者は択一式の回答を求めるものだ。これを真似して「オープンサーチ」「クローズドサーチ」という言葉を定義するならば、「クローズドサーチ」は良い検索なのだろう。「クローズドサーチはやっていいけど、オープンサーチをするならタスク(チケット)を切ってチームと問題を共有しようぜ」という方向性をどうやってつくるかが問題だ。

いっそ、Proxyを立ててチームメンバーのサーチクエリを収集して分析してみたら何かわかるだろうか?
もしくは、Google検索のゲートウェイシステムを立ち上げてチーム単位でサーチクエリを共有する(今日皆がどんな検索しているのかを見えるようにする)とか。
検索と言う時間泥棒とうまくつきあっていく方法を考えてみたい。