Continuity is The Father of Success

Androidアプリとかゲームとか。毎日続けてるものについて。

結論を出す「こと」

たとえば10人のチームに属しているとする。 この時、何かを決めようとするとどうなるだろう。

  • case-1
    • あなたの隣のだれかと1時間会議室に籠もって議論をし、そこで結論を出し、全体に対して「結論を出しました」と宣言する。その結論は受け入れられるだろうか?
  • case-2
    • あなたの隣のだれかと1時間会議室に籠もって議論をし、そこで結論を出し、全体に対して「提案書を作成しました」と宣言する。その結論は受け入れられるだろうか?

実際にはどちらも受け入れられることはあるし、受け入れられないこともある。 このとき、受け入れられない場合の「理由」が全く違うのではないか、という話を書く。

case-1をイメージしてみる。

受け入れられないと言うより、反発が発生する。もしくは、なぜその結論になるのか納得がされない。 つまり「2名の意見を全体の意見と見なす合意が取れていない」状況で、『これが結論である』と表明されることに対する不快感によって拒絶される。 もしくは、2名の結論を出した過程に対して疑問が挟まれて、拒絶される。

このため、"あなたと隣のだれか"が検討委員のような、検討を行う役割であれば話が全く変わってくる。 それは当然の活動であって、特段意識されるようなものでもない。 10人のチームの中で決められた役割を果たしているものだ。

case-2をイメージしてみる。

受け入れられないというより、手直しが発生する。もしくは、提案を出す権限がないということになる。 というより、この例はずるくて「提案書」がどういったものか明示していないのに自明のものとして扱っている。 「提案書」と言って一発で通じるのならば、それはそのチームで「提案書」がどういったものか明示的に/暗黙的に同意されているはずだ。

明示的に/暗黙的に定められたステップに従っているのでも、case-1と異なるのは、明らかに「このチームの合意にしたい」ことを伝えている点だろう。 case-1とcase-2で提出されている「案」の品質に違いはない。単に「案」の品質でもって全知全能の人が判断するのであれば、それは手順が違っても同じ結論になるはずだ。 けれどそうはならないことは、容易に想像できる。

チームがどう結論を出すかは、そのチームが明示的に/暗黙的に持っている「どういう手順をもって結論を作るか」という認識に引きづられる。 もしかすると、それは『年長者が判断する』かもしれないし『リーダーがコストとベネフィットから判断する』かもしれない。 『年長者が判断する』であればその年長者の過去の決断にそう話とするだろうし、『リーダーがコストとベネフィットから判断する』であればコストとベネフィットの試算を添付するだろう。

つまり、何らかの結論を出そうと考えるときには、その結論を結論とするための方法を考える必要がある。 逆に言えば、結論とするための方法を考えていない「案」は、単なる「案」であって合意のための検討がされることはない。

2重に物事を考えることが必要だなと、痛感しているこの頃。