（このブログは、Graat社とのリレーブログ『チームとテクノロジーの幸福な関係』の記事として投稿しています。）
コラボレーション研究家の吉田裕美子です。
人財開発に費やす時間を生み出すことは、リーダーにとって重要であるにも関わらず、とても解決の難しい問題とも言えます。スキルも経験もあるリーダーは、すでに自分の仕事をかなりの量、抱えており、その中でチームメンバーの能力開発にも時間を割かなければならないのですから。
優秀なリーダーは、ともすると、「自分でやってしまった方が早い」と感じてしまう傾向があります。確かに自分でやれば、「教える」、「指示する」という時間を省くことができますし、自分の思う成果にたどり着けることも事実かもしれません。
他方で、この状態になっていると、いつまでもメンバーは育ちませんし、リーダーの忙しさは、全く改善されないわけです。リーダーが忙しいというのは、実は、リーダー自身の成長がなかなか叶わない状態にあるとも言えます。その意味でも、なんとかして、メンバーが自分たちで仕事ができる様な工夫をする必要があります。
この辺りの工夫は、実は、世の中で様々行われていたりもします。
例えば、システム開発を行っているチームでは、「ペア・プログラミング」と呼ばれる、通常は1人で行うプログラミングをペアで行なったりすることもあります。ペア・プログラミングは、必ずしも人財開発の目的だけで行われているものではありませんが、作業を1人のエンジニアにクローズドにしないことで、知見は自然とペアを組んだ相手に伝わる部分があり、頭脳労働者のナレッジをチーム内で共有していく優れた働き方と言えるでしょう。
そんな世の中にある様々な人財開発の方法を、今日は少し異なる視点から考えてみたいと思います。
それは、どういうわけか、組織の中であまり活用されることがない、「情報設計を通じたインストラクション」というものです。
■ メンバーの「理解」を促す
前回のリレーブログでは、情報設計について触れる中で、「インストラクショナル・デザイン」について以下の様に書きました。
情報設計という言葉が耳慣れない方もいらっしゃるかと思いますが、起源を辿ると、リチャード・ソウル・ワーマン氏が、著書『理解の秘密―マジカル・インストラクション』の中で提唱している 「インストラクショナル・デザイン」という、理解を促す概念から、「理解をデザインする人」としてのインフォメーション・アーキテクトという職業が考案されたと言われています。
インストラクションとは、なんらかのアクションによって、完成する形に到達できる様、教えたり、指示したりすることを指します。
この完成に到達するまでに、人は、自分の知識や経験を使ってアクションを起こしますが、同時に、このアクションを支援する情報が常に必要になります。
例えば、明日、子供の小学校の運動会があるので、持ち物を準備しようとしているとします。
この場合の「完成」は、運動会に出発できるよう、持ち物が整っているという状態です。
この時、もちろん、過去の経験値からおおよその準備は可能でしょう。同時に、その時の個別の事情を理解するために、学校からの案内文を確認するかもしれません。また、天気予報を見て、翌日の天気や気温を確認することもあるでしょう。お子さん自身に先生からの伝達事項がないか確認するかもしれません。
つまり、この準備をしている人は、様々なデータを集め、自分の必要な情報としてまとめた上で、意思決定して、持ち物を準備するというアクションを起こしているわけです。
この様な単純な作業であれば、例え、データ収集が多少煩雑であったとしても、やりこなすことはできる人は多いでしょう。それでも、うっかり忘れたり、誤解してしまって、適切な準備が行われないケースも十分考えられます。
リーダーは、この様な一連の「完成」へと到達するアクションを、多かれ少なかれ、なんらかの形で指示する役割があります。そして、指示がうまく伝わらなかったり、指示することが手間に感じられる場合に、前述の様に、自分でその仕事を引き取ってしまったりするのは、よくあることでは無いでしょうか？
でも、よく上述のプロセスを見ていただければわかる様に、「何を」「どうやって」行うかが伝われば、全部を直接指示しなくてもできることは多くありますし、人が側で指示するよりも、上手いやり方が考えられないでしょうか。
前述のリチャード・S・ワーマンは、著書『それは「情報」ではない。』において、次の様に記しています。
情報を求めたり、問題を明確にするための質問は、問題解決の道を拓く無垢な質問だ。
私自身が、Hyper-collaboration（HYC）を創業してすぐにぶつかったのが、プロジェクト開始時の戦略立案を、チームメンバーの誰もができる様になり、また、どの様な思考プロセスを経て、現地点に至っているのかを後から誰もが参照できる様にするということでした。
HYCは、たった4名で活動している組織で、その割に扱っているプロジェクトは大きいケースが多く、プロジェクト開始時点での分析や思考、意思決定は非常に重要な要素であるにもかかわらず、人財開発が難しい側面があったからです。
私は、この「無垢な問い」が浮かぶ様な仕組みを用意する方法を、いろいろな方のアドバイスから、社内に構築することにチャレンジしました。それによって、指示に費やす時間を大幅に削減し、メンバー同士が質問し合い、必要な情報を求め、自分で考え、創造性を発揮して、仕事を完成するという、エンパワメントが実現しています。
そして、それは、次の様な、準備してしまえば本当にシンプルな方法なのです。
■ 問いを構造化する
仕事は、個々の詳細を具体的に見ていけば、それぞれ異なっていて、同じ仕事はないとも言えますが、例えそれがプロジェクト型の仕事であっても、一定のパターンで進められていることは間違い無いでしょう。
例えば、プロジェクトの一番最初に何を考えなければならないのかと言ったことは、「問いかけ」として予め用意できる部分があるはずです。つまり、答えは毎回違っていても、「問い」には共通するものがあるのです。
この「問い」が構造化されているものを、フレームワークと呼ぶことがあります。
フレームワークと呼べるほどの構造がなかったとしても、再利用可能なテンプレートを用意するだけでも、「問い」をあらかじめ準備しておくことが可能です。
会議を開くときは、アジェンダを用意して、時間配分を設計し、議論した後、決定事項をまとめ、誰がどんなアクションを取るのか決めるのだという様な指示を丁寧に出さなくても、議事録用のテンプレートを利用しておけば良いのです。テンプレートの枠組みに「ミーティング・ゴール」と書かれていれば、「このミーティングのゴールはなんですか？」と問いかけられていると解釈でき、ゴールを記述するために必要な確認や思考を、会議の主催者は自分で行えます。
HYCの場合、最初は、私が用意したフレームワークやテンプレート類を使ってもらっていましたが、今現在は、誰もがプロセスを体系化し、問いを構造化して、自らテンプレートを作成できる様になりました。
なぜ、みんながそうするか・・というと、私たちは、本当に多くの企業や外部の方々とコラボレーションしながら仕事を進めているからです。
自律分散型にチームが活動しながらも、そこに最適なプロセスがあり、同時にそこで生み出された情報を誰もが参照しやすい状態にしておかなければ、常に「誰かに聞く」ことをしないと、過去のプロセスを確認することができなくなります。
これでは、経験を共有するコストが非常に高くなってしまい、企業の成長にとって、とても危険な状態に陥ってしまうのです。
情報は、常に開示されており、それが参照しやすい状態であること。
そして、プロセスの進め方としては、「問い」を構造化したテンプレートやフレームワークがあり、それを活用しながら、メンバーが情報を集めて、新たな意思決定ができる様にすること。
人が直接指示を出す、インストラクションがなくなるわけではありませんが、この2点が整っていれば、「情報」が人の活動を適切に支援してくれる様になり、圧倒的にリーダーの負荷は下がるはずです。
必要な情報が抜けていないか確認する方法は、Graat浅木さんの前回のブログ、『自律的なチームを作る情報設計』を是非ご参照ください。
また情報の分類方法は、次回の浅木さんのブログでご紹介いただく予定です。
リレーブログ『チームとテクノロジーの幸福な関係』を展開させていただいているGraat社、JiraやConfluenceと言ったチームの情報活用を支援するツールを様々提供されている、Atlassian社、そして、Hyper-collaborationの3社共催のWebセミナーを開催することになりました！！
チームの意思決定を育てる"情報のレイヤー化"とは？ 〜Confluenceを使ったモデルケース〜
｜開催概要
日付：2021月11月4日(木)
時間：13:00〜 16:00
開催形式：オンライン（Zoomを使用します）
ZoomのURLは開催前日までにご参加の方へ送付します。
定員：50名
｜こんな方々におすすめ
組織(チーム)の情報設計に関心のある方
組織(チーム)の情報共有に問題を感じている方
Confluenceを活用しきれていないと感じる方
ぜひご参加ください！
事務局より：
好評をもちましてWebセミナーは終了しました。
ありがとうございました。