・各人がそれぞれ箱をもっている
・その箱は所有者しか覗き込めない
・その箱の中身を（空であっても構わない）、《カブトムシ》と呼ぶ
これは、ウィトゲンシュタインの有名な思考実験「Beatle in the box」です。
他人が《カブトムシ》と呼ぶものが何なのかは分かりませんし、そもそも存在しないかもしれません。互いに《カブトムシ》と呼び合うことで会話が成立しますが、具体的には何も共有されていません。
私的な体験の表現は、「覗けない箱の中の《カブトムシ》」と同じで、伝えること（あるいは、同一の感覚的体験をすること）の不可能性を示しているという解釈がなされています。
この思考実験の解釈は、もう少し“実社会”の側に引き寄せられるように思います。
実社会では、哲学の世界ほど用語の定義を厳密にしているわけではありませんので、私的体験のみが《カブトムシ》になるわけではありません。共通言語レベルでも《カブトムシ》が存在するのが現実です。
****************************************************************************************
《カブトムシ》の存在を認めることは、プロジェクトマネジメント上で大きなアドバンテージを得ます。
そこで、ロゴスウェアのシステム開発部のプロジェクトマネジメント手法の一部をご紹介しましょう。
１．身近な《カブトムシ》
例えば「ユーザ管理機能はありますか？」と尋ねられた時に、この思考実験を思い出す必要があります。
確かに私が開発したシステムには【ユーザ管理機能】があります。しかし、これがあなたの要求する『ユーザ管理機能』と同じである保証はどこにあるのでしょうか？
「“ユーザ”を“管理”するんだから、大して違いはないだろう」という判断が悲惨な事態を引き起こす事例は山ほど見つかるでしょう。“破綻プロジェクトとデスマーチの２択”に自ら邁進するようなものです。
もっと小さな例を挙げましょう。
「メールの返事はいつまでにしますか？」「急ぎじゃないからゆっくりでいいよ」「では、ちょっと後にします」という会話では、“メールの返信タイミング”という《カブトムシ》が同じものである可能性は限りなく低いでしょう。
“あなたと私の《カブトムシ》が同じ”であることをどの程度保証する必要があるのかは、『《カブトムシ》の誤差と損害の分析』に依存します。なんでもかんでも厳密にすればいいというものではありません。
しかし重要なのは、《カブトムシ》であるという認識を持っているということです。
例えば「１週間くらい後でいいよ」という合意には、“くらい”という《カブトムシ》がいます。
この《カブトムシ》は、今日は無視してもよいレベルですが、おそらく５日後にはもう１回連絡を取り合って期限を確認する必要があるでしょう。
《カブトムシ》であることを認識するということは、この事例のようにビジネスの基本でもあります。
２．《カブトムシ》は、どこまでいっても《カブトムシ》
- 「対話を重ねれば、いつかは《同じカブトムシ》になる」のでしょうか？
- そのためには、どれくらい対話を要するのでしょうか？
- どれくらい《カブトムシ》の特徴を一致させれば、“同じ”と判断できるのでしょうか？
一時期、手にしているプロジェクトで、上記のことばかり考えていたことがあります。
「あなたが考えている《カブトムシ》は、私の《カブトムシ》と同じでしょうか？」という質問は、互いに《カブトムシ》を往復させるだけの構造でしかありません。
いくつもの“特徴”を抜き出しても、その“特徴”のすべてが新しい《カブトムシ》になるというカオス構造そのものです。
そこで、私は「《カブトムシ》は永遠に《カブトムシ》」を受け入れて、マネジメントをしています。
チームのメンバーに「顧客に再確認してください」「いえ、すでに合意しています」「それでも“今”このタイミングで、再確認してください」を繰り返すのは、このマネジメント手法です。
３．《カブトムシ》に紐をつけておく
私たちは、PM（プロジェクト・マネジメント）の知識とツールとテクニックを習得します。PMの能力は、ある一定レベルのプロジェクト進行を確実に繰り返し実行できるもので、非常に有効です。
PMが利用するツールとテクニックは、顧客の要求を正しく把握し実行するためのものです。
“顧客の要望を把握することなどできない”を前提にしたら、それこそ話になりません。PMの勉強をしている間は“顧客を理解する”ことを学ぶべきです。
しかし、PMの能力を習得した後は、もう一度《カブトムシ》に思いを巡らす必要があります。
つまり「ここまでヒアリングしたこと・合意したことが、根本的には《カブトムシ》である」ことを忘れないということです。これは、上の例で“適切な時期に再確認する”という行動を導いたように、“適切なタイミングでステークホルダーと再確認する”という行動を導くということです。
「以前合意しましたよね」「そのような認識で合意したのではありません」という食い違いのケーススタディは、それこそ山のように存在します。多くの場合は、“最初の合意が甘かった”ので、“○○というツールを使いましょう”という結論になりがちです。
そもそも“最初の合意は《カブトムシ》”だと認識して、「再確認するタイミング」を設定したほうが、良い結果を生むのではないでしょうか。少なくとも、私たちロゴスウェアのシステム開発部では“最適なタイミングで再確認する”ことで多くのリスクを回避しています。このマネジメント方法を、私は「《カブトムシ》に紐をつけておく」と名付けています。
****************************************************************************************
PMBOKでは９つのナレッジエリアを定義しています。
「《カブトムシ》に紐をつけておく」手法は、直接的には、その中の“コミュニケーション管理”のツールになります。
“コミュニケーション管理”は、“合意の積み上げ”を前提にしています。確かに“変更”のプロセスは存在しますが、“《カブトムシ》を前提にした合意”を扱うことは想定していません。この意味で異端なツールかもしれませんが、私自身はあくまでPMBOKの中のツールに組み込んでいるという認識です。
以上、“コミュニケーション管理”をより現実に即して実行できるツールとして、私たちの手法をご紹介しました。
ロゴスウェア
最新記事 by ロゴスウェア (全て見る)
- Amazon Linux（EC2）と PHPSTORM で Xdebug を行う - 2018年9月26日
- やらないことの合意 - 2018年6月27日
- 卒園アルバムとプロジェクトマネジメント - 2018年3月30日
Comments are closed.