学部１年生のときから組織開発のコミュニティーに関わっていたこともあり、学部３年の後半から半年間くらいTJSというサービスの開発に関わらせてもらったことがある。久しぶりにその時の資料を見たら面白かったので、当時工夫したり・考えたことを書いてみようと思う（もちろん言える範囲で）。
TJS（Team Journey Supporter）は組織開発のツールで、株式会社ガイアックス、英治出版株式会社、NPO法人home's viの３団体が共同開発した。URL：https://team-journey-supporter.com/
サービスの全体像としては、組織開発のためのアンケートの実施、そのレポーティング、それを元にした対話支援。つまり、対象となる部署やチームの各メンバーにアンケートに答えてもらい、その結果を集計してレポートとして提供し、またそれを元にした対話もサポートするサービスである。
僕が担当したのは、アンケート結果をどう集計してレポーティングするかの設計。
学部１年生のときに、先進的な人事制度を採用している企業にインターンをさせてもらったり、学部２年生のときに組織開発研修事業を行なっている企業のプロジェクトに入れてもらったりして組織論についてある程度の理解があったこと、および学部２年生の間はデータ分析についてゴリゴリに鍛えて、その後は「どう集計するか」などに関わる経済学理論について学んでいたことなどから、大きな挑戦をさせてもらうことができた。
とはいえ、サービス開発に関わるのは初めてであったし、経済学についても今ほど知識はなくから考えることがとても多かった。今回はそのときに考えたことや工夫したことをいくつか書いてみたい。
判断なのか表現なのか
これは集計の根本的な役割についてである。つ例を考えてみる。
例えば、「このチームではリーダーの声が大きく、リーダー以外のメンバーは意見が思うようにいえないことがある」という質問を考える（実際にはこの質問はしていないが）。これについて「とてもそう思う」を、として「まったくそう思わない」を
としてみる。
このとき、回答結果がとなったとする。
つまり人のメンバー全員が「とてもそう思う」を回答しているような状況である。これは非常にまずい状況だと考えられる。もし集計結果を
で表示するとしたら（1はまったく問題ない、6はとても問題がある）、
にしたくなる。
でも次に違う回答結果としてを考えてみる（さらにここでは最後の回答者がリーダーであることも分かっているとしよう）。
この場合はリーダー以外が「とてもそう思う」と回答して、リーダーは「まったくそう思わない」と回答している状況である。このつのケースで状況はどちらの方が深刻だろうか？
個人的には後者の方が問題があるように感じる。
つまり、チームのメンバーの回答結果の平均を取るような集計方法では、を
よりも深刻であると判断してしまい、チームの深刻度を判断するという意味ではよくなさそうである。
このときに「さぁ困った。じゃあどう丁寧に設計しよう」と一瞬なりそうだったが、実際にはここで少し立ち止まった。
今回の集計でしないといけないのは、本当に"判断"や"診断"なのだろうか。
チームの状況の深刻度を診断するのであれば、平均値はたしかにまずそうである。しかし、今回のサービスの全体像としては、レポーティングで終わりではなくそれを元にした対話の支援までする。
するとここで大事になるのは、状況を決めつけるような"診断"ではなく、チームの回答状況を対話に役立つように"上手く表示すること"だと分かってきた。もっといえば「だいたいどんなかんじに集計したのか」を参加者が感じられるような集計方法であり、「アンケートの回答結果はこんなかんじになったんだ。んーその背後には何があるかな、みんなで考えていこう」みたいになる集計が望ましいだろうとなった。
このような観点から考えると、平均値はどう集計されたかも分かりやすく、またその弱点も説明されれば理解されやすいため望ましそうである。もちろん対話支援までしないサービスの全体像であればこのようなケースにおいて「平均値」を用いないと思う。
実際にどういう議論だったかは詳しくは覚えていないが（先ほどの質問はあくまでこの場で分かりやすい説明のために考えたものであり実際にはしていないが）、上のような議論から、今回のサービスにおける「集計アルゴリズム」とは「診断アルゴリズム」ではなく「対話に役立つようにアンケート結果の情報を上手く情報圧縮して表示するアルゴリズム」であるべきだと分かってきて、何をするべきかがだいぶクリアになった記憶がある。
犯人探しの回避
回答結果をどう集計するかについてだが、例えば分布をそのまま表示することもできるし、その平均値だけを表示することもできる。情報が多ければ多いほど状況は把握しやすいが情報が多すぎると困ってしまう。そこについても考える必要があるが、もっと重視したポイントとして、「犯人探しが起きないようにする」という観点がある。
仮に分布を表示する場合（先ほどのケースでいえばという回答結果に対して
を選んだ人は
人であり、、、
を選んだ人は
人である、のように表示する場合）、「誰が
を選んだんだ」という犯人探しが起きかねない。これでは安全な対話を促進するのは難しそうである。
そこで実際には例えば次のような表示をした。
のスケールで回答してもらった質問について、
で回答した人、
で回答した人、
で回答した人、
で回答した人の割合を色の濃さで表す表示にした。ネガティブな回答については
という広めのスケールにしてあり、これは犯人探しが起きないような工夫である。
しかし例えば他の質問群について「認識のずれが大きかった（回答のブレが大きかった質問）」を取り上げて細かい分布を載せたりはした。これは「認識のずれが大きい質問」であれば人だけが極端な回答をしている可能性は低いという判断である
のようなケースが一番犯人探しが起きやすそうである。しかしこの場合は「回答のずれ」は小さい）。
一般的な質問においては分布を示してしまうと「犯人探し」が起きるが、多くの質問の中から特に回答にズレがあったものについて対話をすると良い質問として取り上げる場合には分布を示してしまっても大きくは問題がないと考えられる。
このへんの話はバランス感覚がすごく求められた。
実務レベルの知恵
これは、ファシリテーションなどの専門集団であるNPO法人home's viのメンバーが教えてくれた観点。集計アルゴリズムについては基本的に僕が担当したが、レポーティングのデザインや表示については何人かのメンバーで検討していった（僕はコメントするくらいしかしていない）。
ある日のミーティングで、今まで色分けしていた表示について（下の写真参考。茶色とか赤とかの色が表示されている）、各項目について色だけでなくダイヤやスペードのような「記号」も表示されている案が出てきた。
色と記号が対
に対応しており、記号については情報としては意味がない(なお、この色分けはTJSの理論的基礎である「ティール理論」から取ってきている)。
これを見たときに僕は、「え、記号載せるのって意味なくないですか？だって色を見ればいいじゃないですか？」とあまり考えずにコメントした。そしたら「これは生まれつき色を判別するのが苦手な人たちに向けてなんだよ」と教えてもらった。
これは知らなかった。
サービス設計レベルでの細かい工夫があることを知ることができ、とても勉強になった。
経済学には色々な役立て方がある
上の説明において「と
を比べたときに、、、」のように、簡単な例を作って説明した。この例は問題意識を一発で共有できるものだと思っている。例をすぐに作ってみる経済学のカルチャーは（もちろん経済学だけのカルチャーだとは言わない）開発メンバー間のコミュニケーションにとても役立った。経済学のカルチャーが役立った。
他にも経済学には「不可能性を証明する」という手法がある。この３つの条件を満たす制度は作ることができないと証明するなどである。今回は不可能性の証明などはしなかったが（そんな時間も技量もなかったし）、「不可能性を証明する」という考え方はとても役立った。このつの条件ってそもそもトレードオフになっているのでどちらかを取らないとダメですよね、のように「できないことをできないと明確にする姿勢」は議論を進める上で役立った。経済学の発想が役立った。
今回、技術的に難しかった点として、チーム"間"比較がある。いままで書いてきたのはつのチームについてどう表示するかであり、
つのチームしかない会社ならそれで十分だが、大きな企業を対象とする場合には、それぞれのチームについてTSJを利用してもらった上で、チームごとの比較をしたくなることもある。これについて考えると実は難しい問題が出てきた。詳細は書かないが、この問題にちゃんと気づくことができたのは、貧困測定の指標を作る際に重要になる「部分グループ整合性」の議論を知っていたからである。経済学の内容が役立った。
ーーーーーー
TJSの開発は本当に貴重な経験になった。当時の僕に大きな仕事を任せてくれてすごく感謝している。当時の自分はいまの自分よりも組織論に対する知識はあったと思うが経済学についてそこまでだったので、今回わりと心配になりながら資料を見返したが、「あれ、意外とちゃんとできているな」という感想になったので少し安心。笑
頑張って共同で作ったサービスなのでよろしければ、チームの状況把握と対話が必要な際には是非使ってみてください！
Fin.
関連記事
・「ティール組織」って本から勝手に学んだ知恵の作り方
→TJSの基礎となっている理論の書評
