---
title: サーベイへの私たちのアプローチが拠って立つもの
description: この手法の根底にあるのは、継続的改善の原則です。小さな変化、結果の検証、次の一歩。以下では、質問がどこから生まれるのか、Yosenoが回答をどのように読み解くのか、そしてこの手法があえてしないことを説明します。
type: page
locale: ja
canonical: 'https://yoseno.com/ja/methodology'
---

# サーベイへの私たちのアプローチが拠って立つもの

この手法の根底にあるのは、継続的改善の原則です。小さな変化、結果の検証、次の一歩。以下では、質問がどこから生まれるのか、Yosenoが回答をどのように読み解くのか、そしてこの手法があえてしないことを説明します。

サイクルは閉じます。最後のステップが最初のステップへと戻ります。

- **改善サイクル:** 4つのフェーズ

尋ねる → 見る → 話し合う → 検証する

```mermaid
flowchart LR
  A["尋ねる"] --> B["見る"] --> C["話し合う"] --> D["検証する"]
```

## なぜ普通のサーベイでは、何も変わらないのか

問題は、チームが気乗りせずに回答することではありません。普通のサーベイは原因を取りこぼし、量を処理しきれず、回答者に結果を返せていません。

1. **数字が違いを均してしまう:** ある人の「3点」の背後にはタスクの混乱があり、別の人の「3点」の背後には誰が何を担当しているのか分からないということがあります。平均値は緊張の高さを伝える一方で、その原因、つまり実際に働きかけられる唯一のものを失わせてしまうのです。
2. **量を、定期実施のたびに読み解くことはできない:** 100件の自由記述回答を手作業で読み解けるのは一度きりです。それを毎サイクル行うことはできません。定期的な実施がなければサイクルは閉じず、声は再び数字へと縮められてしまいます。
3. **結果につながらない声は、消えていく:** 回答が何も変えなければ、次回の人は上の空で答えます。恐怖からではなく、虚しさからです。率直さは一度得られれば終わりではなく、支え続けなければなりません。

## この手法の土台となる6つの考え方

どれも目新しい考え方ではありません。一つひとつを、人は自分の仕事の中で何らかの形で経験してきています。重要なのは、それぞれがプロダクトの仕組みの中でどのような形に変わったかです。

1. **改善は、一度きりの出来事ではなく、ループです:** 組織は一度直せば終わりではありません。新しい人が入り、新しい課題が生まれ、以前の解決策が合わなくなります。重要なのは、個別のステップではなく、サイクルを閉じることです。理解を伴わない測定期間はただの数字であり、行動を伴わない理解はただの話し合いであり、再測定期間を伴わない行動は「良くなったはず」という希望的観測にすぎません。
   - **プロダクトでは:** 測定期間は、管理上の区切りではなく、改善ループの一巡です。新しい測定期間は前回を消し去るのではなく、そのとなりに並びます。チームは同じテーマに回答し、最も緊張が高かった場所の緊張が和らいだかどうかを確認できます。
2. **平均値よりも、正直な声が大切です:** 評価スケールで自分の仕事を評価するよう求められると、人は数字で答えます。しかし、数字の向こう側では、その人が言いたかったことが消えてしまいます。一人はタスクの混乱に疲れ、もう一人は自分の役割の境界が分からない。それでも数字はどちらも同じです。
   - **プロダクトでは:** 評価スケールの横には、いつでも言葉を書く場所があります。短い回答や感情的な回答には、AIファシリテーターがフォローアップ質問を1つ投げかけます。これで通常は、曖昧な「複雑です」が具体的なシグナルになります。
3. **本音は、心理的安全性の上に成り立ちます:** 仕事の本音が語られるのは、率直さが不利益につながらない環境です。これは個人の勇気の問題ではなく、環境の問題です。安全でない環境では、どんなに率直な人でも言葉を和らげます。
   - **プロダクトでは:** 生の回答は誰にも表示されません。外に出るのは匿名化された結果だけであり、しかもその質問への回答が5件以上集まった場合に限られます。組織自体も匿名運用が可能です。
4. **何百もの声が、共通の認識へとまとまる:** 仕事のしくみについての知識は、一人ひとりの頭の中に分散しています。それを活かすには、声の大きい人も小さい人も取りこぼさず、断片をひとつに集めなければなりません。これまでは量が壁でした。100件の本音の回答を読み解くのは一度はできても、毎サイクルはできません。
   - **プロダクトでは:** アルゴリズムは意味の近い回答をまとめ、質問・カテゴリ・組織ごとに要約し、マネジメントのテーマにひもづけます。散らばった声は、チームのどこに緊張があり、どこが良好なのかを示す全体像になります。
5. **小さな一歩は、めったにない大きな一歩よりも確実です:** 大規模な立て直しは、思い切った対応に見えます。しかし、規模が大きいがゆえに最後までやり遂げるのは難しく、すべてが一度に変わると原因と結果の関係も見えにくくなります。小さな一歩は、始めるコストが低く、「前」と「後」の違いがはっきりしていて、合わなければ取り消すこともできます。
   - **プロダクトでは:** 結果として得られるのは、総合的な診断ではなく、範囲を絞り込んだ複数の改善点です。それぞれに個別に、無理のないペースで取り組むことができます。
6. **変化が定着するのは、チームがそれを自分ごととして進めるときです:** 上から降ろされた決定は、実行されてもチームのものにならず、機会があればすぐに慣れた方法へ戻ってしまいます。チーム自身が出した決定は、自分たちの理解に支えられているため、根づきます。
   - **プロダクトでは:** 結果はチームに開かれており、非公開のレポートとして上層部にだけ渡るわけではありません。改善点の周りには、匿名運用の組織であっても、アイデアや話し合いの余地が残されています。担当者は、その改善点を共有の場から消すことなく、自身の業務として進めます。

- [回答の保護の仕組み](https://yoseno.com/ja/security.md)

## ひとつの回答から次の測定期間まで

この方法論の基盤は、すべてのリンクが一つ前のリンクから導き出される、一本のチェーンです。リンクの順序はどのサーベイでも同じで、質問とテーマは変わっても、道筋は変わりません。

回答 → テーマ → 歪み → 改善点 → プラクティス → 次の測定期間

```mermaid
flowchart LR
  A["回答"] --> B["テーマ"] --> C["歪み"] --> D["改善点"] --> E["プラクティス"] --> F["次の測定期間"]
```

1. **回答:** 各質問は、あらかじめ1〜4つのマネジメントテーマに紐づけられています。回答には、シグナルの種類（苦情・アイデア・中立）、トーン、広がりといったマーカーが付与されます。
2. **テーマ:** 回答は、質問に紐づくテーマのプロファイルを強化します。テーマは分析の単位であるため、異なるサーベイも同じ言葉で語られます。
3. **歪み:** 結果の集計では、意味の近い回答がまとめられ、どのテーマで歪みが大きく、プロセスのどこにギャップがあるのかが見えてきます。
4. **改善点:** 最も歪みの大きいテーマは、改善点として作成されます。改善点とは、回答によって裏付けられた、繰り返し現れるテーマまたは業務上の歪みです。批判とともに提案があった場合は、その提案も説明に含まれます。
5. **プラクティス:** 改善点のテーマには、ナレッジベースからプラクティスが選定されます。ナレッジベースには、公開中のカードが現在 118 件あります。推奨事項はテーマから導き出されるものであり、回答を言い換えたものではありません。
6. **次の測定期間:** 新しい測定期間は、そのテーマの歪みが解消されたかどうかを示します。解消されていなければ、それは別のアプローチが必要であることを示す正直なシグナルです。

## 分析が共通のテーマ辞書に基づく理由

テーマとは、チームの状態を測るためのマネジメントプロセスです。テーマ辞書はすべてのメソッドで共通であり、現在 61 件が登録されています。そのため、異なるサーベイも同じナレッジベースに基づき、再測定期間では比較可能な対象を比較できます。

**質問の例:** 誰が何に対して責任を持っているか、あなたには明確ですか？

- **role\_clarity:** 役割と境界の明確性 — 自分の担当範囲、役割に対する期待、隣接する役割の機能内容を理解していること。
- **process\_transparency:** プロセスの透明性 — 業務プロセス、意思決定ルール、成功基準が明確であること。

1つの質問が2つのテーマを同時に検証し、回答がそれぞれのテーマのプロファイルを強化します。

一部のテーマは、確立されたモデルに基づいています。消耗とシニシズムはMaslachモデルに沿って定義され、変化への準備はADKARモデルに沿って定義されています。

チームがテーマ辞書にない話題を挙げた場合は、テーマが動的に作成されます。そのため、独自に組み立てたサーベイでも、重要な内容が失われることはありません。

## サーベイは、アンケートではなく、ファシリテーションされた対話です

質問数は8〜16問です。深さを得るには十分で、疲れない程度の少なさです。質問はカテゴリにまとめることができます。

各質問に込められているもの:

- 回答者に向けた質問文と焦点。
- 回答が短い場合や感情的な場合にどこを深掘りすべきかを示す、AIファシリテーター向けの隠れたヒント。
- 1〜4つのマネジメントテーマとのつながり。

**設計の規律:** 各メソッドは目的に合わせて設計されています。事前に、チームと何を話し合うのか、意図的に省くテーマは何かが決められています。テーマとカテゴリは厳密に区別され、シグナルに二重の解釈の余地を残しません。各評価スケールには対話への誘いが用意されています。価値ある文脈は言葉の中から生まれるからです。そして、結論は判定としてではなく、対話の出発点として提示されます。

チームでサーベイを作成・実施する方法については、 [ドキュメント](https://yoseno.com/ja/docs/surveys/overview.md).

## AIが負担を軽減し、判断は人が下す

このメソッドの考え方は本質的にシンプルですが、実践では常に同じ障壁、すなわち手作業の量に突き当たります。ここでAIが必要なのは、チームの判断を代替するためではなく、サイクルを本当に繰り返し可能にするためです。

サーベイの実施中は、感情を具体的なシグナルへと変える手助けをします。結果の集計では、似通った回答をまとめてテーマごとに整理し、どのテーマのひずみが大きいかを示し、そのひずみに合った既成のプラクティスを選び出します。それらをどう扱うかを決めるのは人です。

## このメソッドが行わないこと

このメソッドは、限界をはっきり示すことで、より誠実になります。

- **単独の取り組みの効果は証明しません:** 測定期間の比較は、テーマに関するひずみが変わったかどうかを示します。しかし、同じ期間に他のすべての要素も変化しているため、その変化が一つの施策によるものだと断定することはできません。
- **人やチームに診断を下すものではありません:** 改善点は、仕事のしくみに関するものです。人を評価するための根拠ではなく、特定の個人についての結論でもありません。
- **組織に代わって意思決定はしません:** ナレッジベースのプラクティスは、チームで議論し、状況に合わせて調整できるマネジメント施策です。選択と責任はチームに委ねられています。
- **率直さを保証するものではありません:** フィードバックが何も変えなければ、次のサイクルで得られる反応は少なくなります。このメソッドは率直な対話のための条件を整えますが、耳を傾ける姿勢の代わりにはなりません。
- **すべてを明らかにするわけではありません:** 匿名化された結果は、その質問に十分な回答が集まった場合にのみ表示されます。そのため、少人数のグループでは一部のセグメントが非表示のままになります。これは、率直な回答を得るための意図的なトレードオフです。
