こんにちわ。組織開発がミッションの人事グループ・組織開発室に所属しているてぃーびーです。
全社、部門、チームなど様々な単位での組織や業務の課題を拾い集めるために自由記述形式のアンケートを実施することがあると思います。
これらの回答の内容次第で、
- 回答者が求める結果につながるか？
- 回答者が求める結果につながるまでの時間がどの程度かかるか？
- 回答者が思いもよらない想定外のマイナス影響がでるか？
などが変化してきます。
今回は、それを踏まえて自由記述形式のアンケートの回答について整理します。
組織改善、業務改善のための自由記述形式のアンケートとは？
組織改善、業務改善のための自由記述形式のアンケートは、全社・部門・チームなど任意の範囲の組織や業務の改善のために行うアンケートのうち、自由記述形式で実施しているものです。
自由記述単体の場合もあれば、選択形式とセットの場合もあります。
選択形式とセットの例としては
- 選択形式
- チームの課題に関して以下の中から選択してください
- 1-5で選択
- 1 - 大きく課題がある
- 2 - ほどほどに課題がある
- 3 - どちらとも言えない
- 4 - 少数の課題がある
- 5 - 全く課題がない
- 自由記述形式
- あなたが最も重要な課題と感じている内容について教えてください
- 課題に対する解決策として提案する内容があれば教えてください
こんな感じです。
アンケートの収集後の流れ
アンケート収集後の流れは、アンケート実施担当の経験がないとその後に起こっている内容が見えにくい面がありそうです。
そのため、マネージャー、リーダーとして動いたり、そういった人たちの活動に同席したり、社外のコミュニティで同様の役割をになった経験がないとわかりにくい部分です。
そこで、未経験の方に向けてアンケート収集後に実施されるであろう大まかなプロセスをまとめます。
だいたいこんな感じでしょう。
- アンケート結果を確認する
- 類似の課題をグルーピングする
- グルーピングした結果の中から対応の必要性を検討する
- 課題の内容が回答から把握できて、重要度やROIを踏まえて対応対象にしたいものに選ぶ
- 情報量が不足していて判断できないものは追加で詳細情報を集めた上で判断する
- それ以外のものは対応外にする
- 課題の内容が回答から把握できて、重要度やROIを踏まえて対応対象にしたいものに選ぶ
- 対応判断をしたものを課題として登録する
- 直近対応する優先度の高い内容を選定する
- 対応時期が来た対象から課題に対する解決策を検討し、解決策を実施する
- 実施完了後、解決有無を確認し、問題なければ対応完了とする
以上の流れに記した通り、すべての回答が必ずしも対応されるとは限りませんし、時期もすぐとは限りません。
そのため、仮に自分が課題として問題提起した内容が扱われなかった場合
- 対応が不要なものと判断された
- 記載内容が理解できなかった
- 記載内容を理解した上で対応不要と判断した
- 対応は必要だが優先度の都合上、積み課題になっている
のどれかになります。
自由記述形式のアンケートの回答内容の分類
アンケートの収集後の流れを踏まえると、回答する目線として気にする必要があるのは、回答内容によって自分が考えている課題感が適切に伝わるかどうかです。仮に、自分自身は非常に重要だと考えている課題を報告した場合でも、内容の粒度が荒かったり、伝え方に誤解が発生しやすかったり、攻撃的だったりすると本来の意図通りに伝わらない場合があります。それは、回答する本人にとっても本意ではないでしょう。
そこで、回答内容を4つに分類してみます。
- 十分な情報量で課題の解決につながるパターン
- 課題の解決のためには追加調査が必要なパターン
- 誤った意思決定につながりかねないパターン
- 関係者にダメージを与えつつ解決にもつながらないパターン
1 十分な情報量で課題の解決につながるパターン
十分な情報量で課題の解決につながるパターンは以下のようなものです。
- 「具体的な課題」「理想像」「解決への提案」が区別してまとまっていている
- 「解決への提案」をする際に「具体的な課題」を省略せず、記載している
- 「課題」を伝える場合に、具体的な内容が伝わる粒度で記載している
例えば
- 具体的な課題
- 隣のチームと連携が必要な部分の情報が閲覧権限の不足みえない
- お互いの守備範囲が見えないことによる作業の重複が発生する
- 都度相手チームの人に直接聞かないと情報が判明せず全体の進行が遅くなっている
- 全体最適をしたいが、その前提自体が見えない
- 隣のチームと連携が必要な部分の情報が閲覧権限の不足みえない
- 理想像
- 隣のチームが管理している情報でも自分たちのチームに必要な情報は見える状態になること
- 解決への提案
- 何らかの形で必要な情報が双方に見える状態にしたい。方法は実現可能であり、コスパがよければなんでも良い
のような形です。なお、課題の発見が重要であり、解決策の提案はこの段階では必須ではありません。
この形での情報提供ができれば理想ですが、慣れるまでは難しい部分があります。
2 課題の解決のためには追加調査が必要なパターン
課題の解決のためには追加調査が必要なパターンは、例えば課題の存在は分かるが、具体的にどのようなものなのか、本当に重要なのかどうかなどが分からないような内容です。
例えば、
- 課題を感じている部分は大枠で分かるが、それによって具体的に何が問題になっていて、理想的な状態としてどのようなゴールを想定しているかが分からない
- 例
- 部門全体でのコミュニケーションが難しく感じる
- 更に知りたいこと
- 部門全体のコミュニケーションのどのような部分が難しく感じるのか？
- それによってどのような問題が発生しているのか？
- どのような状態が理想だと考えているのか？
- 例
- 要望は分かるが、背景にある課題がわからない
- * 例
- 部門横断の交流機会を増やして欲しい
- 更に知りたいこと
- 部門の交流が不足していることによってどのような問題が発生しているのか？
- 部門の交流機会を増やすことでその問題を解決できるのか？
- * 例
- 表現が曖昧で具体的な課題が把握できない
- 例
- チームの現状は歪んでいる
- 更に知りたいこと
- 具体的にどんな対象がどのようになっていることを「歪んでいる」と捉えているのか？
- 例
- 個人の主観からくる感想であり、本当に重要な課題なのかどうか具体的な部分が分からない
- 例
- 組織課題への対応が遅く感じる
- 更に知りたいこと
- 具体的にどのような事例においてどのくらい時間がかかったときの話なのか？
- 理想的にはどのくらいで解決する必要があると考えているか？
- 例
などです。
「更に知りたいこと」に記したような不明点の把握のためには事後ヒアリングが必要になります。
逆にヒアリングをしない状態で、この内容に対応することは「当てずっぽう」な対応になるため、対策が的を射たものになるかどうかは運まかせになります。
1のパターンが理想ではありますが、2のパターンでも課題の存在は十分に伝わります。むしろ、大半の回答はここに該当するでしょう。そして、2のパターンであればアンケートの実施目的に十分即しています。回答者として更に質の高い回答で貢献したい場合は、次回以降の回答時に1のパターンを目指す形になります。
3 誤った意思決定につながりかねないパターン
誤った意思決定につながりかねないパターンは、存在しない課題に時間を使ったり、重要度を誤って判断したり、報告内容を誤って解釈して対応につながってしまう可能性があります。
例えば、
- 回答内容は推測であり、事実ではない
- 例
- 組織体制が変わった影響でXXXXが悪化したと思うので、YYYYして欲しい
- 例
- 主語、目的語が欠けていたり、指示語が多く、何の話なのか特定できない
- 例
- あの取り組み対する人手が足りていないので、もっとあちらで対応すべきだと思う
- 例
- 推測をもとにした過大なアラートを出す
- 例
- このままでは組織崩壊につながるので絶対に対応してください
- 例
などです。
3のパターンになっている場合、できるだけ1・2のパターンの回答にしていきたいところです。
4 関係者にダメージを与えつつ解決にもつながらないパターン
関係者にダメージを与えつつ解決にもつながらないパターンは、回答者が強い不満や憎しみを抱えているということは把握できますが、具体的に何かを解決することにはならないため、回答者の不満や憎しみは継続することになります。また、その上でフィードバック内容を扱う関係者の中には心理的なダメージを受ける人がでることすらあります。
例えば
- XXXXの施策は、おろかであり、無能な判断と言わざるを得ない
などのようなものです。不満や蔑みの感情を伝えていますが、施策が抱える具体的な課題の情報がありません。
4のパターンになっている場合、できるだけ1・2のパターンの回答にしていきたいところです。
自由記述形式のアンケートのポイント
総論としては「システム開発で要件やバグ票を記載するときと同じような観点で回答をする」のが理想といえそうです。
その意味でシステム開発関係者は回答スキルの土台を実はすでに持っていると言えるかもしれません。普段やっていることを抽象化して捉え、他の場面でも適用できればよいわけです。
具体的なポイントを以下に列挙します。
- 提案や要望を出す場合、その背景にあたる課題の情報を欠かさないこと
- 提案や要望よりも課題の情報のほうが重要
- 課題の情報がないと本来存在しない課題に対して取り組んでしまう可能性がある
- 具体的な情報を添える
- 必要に応じて具体例を添える
- 全体の課題ではなく、一部の課題の場合、範囲を絞って伝える
- 課題の共有時に形容詞をつけると主観や曖昧さが増すので、形容詞を避ける
- 程度の表現をする際は数値や日数など、できるだけ定量的な表現を使う
- 事実と推測を区別して伝える
- 事実を伝える事が重要
- 推測を伝える場合
- 推測であることを明確にする
- 推測の上に次の展開の情報を追加しない
- 攻撃にならないような表現にする
- 感情を伝えることはよいが、攻撃にならないような表現にする
- 複数の話題を扱うときは明確に区別して1つずつ記載する
- 見出しを分ける
- 連番を付与する
- 特に重要だと考えている上位数個に注力して伝える
- 大量に伝えすぎると、内容の把握、取捨選択のコストが大きく上がり対応が難しくなる
- 大抵の場合、大量の課題すべてを即時かつ一気に対応することはできない
- 保留の課題が増えるほど課題管理のコストが増える。たいていの場合、棚卸しの際に捨てることになる
- 10個のトピックを荒い粒度で列挙するより、最も重要なトピックを1個について具体的に記載して伝えたほうが実際に改善対象になる可能性が高い
- 大量に伝えすぎると、内容の把握、取捨選択のコストが大きく上がり対応が難しくなる
まとめ
全社、部門、チームなど様々な単位での組織や業務の課題を拾い集めるために自由記述形式のアンケートについてまとめました。
回答の傾向として4つのパターンを紹介しましたが、理想である1のパターンで回答できる人はおそらくごく少数です。
また、できれば避けたい3や4で回答しているケースについても責めたりする対象ではありません。少しずつ伝え方の質を上げることに慣れていけばよいだけです。これは先に触れたように、システム開発で要件やバグ票を記載するときについても最初から完璧にかける人がいないのと同様です。
7
