20％ルールとは、勤務時間の一部を、社員が選んだ業務関連の探索や改善に使えるようにする考え方です。
制度の価値は、勤務時間の正確な2割を自由に使うことではなく、通常業務では後回しになりやすい仮説を、小さく安全に試せる点にあります。
Googleは公式ブログの20％プロジェクト紹介で、会社に価値をもたらす可能性のある業務関連の課題に取り組む仕組みとして説明しています。
自社に導入するときはGoogleの運用をそのまま再現せず、業務量、職種、情報管理、人事評価に合わせて設計する必要があります。
20％ルールで決める四つの要素
「20％」という数字だけを制度にしても、参加者と管理者の判断はそろいません。
目的、対象、時間、成果物の四つを先に定義すると、自由放任と過度な管理の両方を避けやすくなります。
| 項目 | 決める内容 | 確認する問い |
|---|---|---|
| 目的 | 業務改善、新しい機能の試作、利用者調査など | どの課題を学習対象にするか |
| 対象 | 参加できる職種、雇用区分、チーム | 参加機会に不合理な偏りがないか |
| 時間 | 上限、実施時期、本務との優先順位 | 就業時間内に確保できるか |
| 成果物 | 試作品、検証記録、手順書、判断結果 | 第三者が学びを再利用できるか |
したがって、「毎週必ず丸一日を使う」「好きなテーマなら何でもよい」という意味ではありません。
20％は上限や目安として扱い、繁忙期の調整方法と、後で時間を取り戻すかどうかも事前に決めます。
制度設計で外せない五つの条件
本務との優先順位を明文化する
参加者の善意だけに任せると、20％活動が残業へ押し出されるか、本務の遅延として扱われます。
実施時間を業務計画に含め、緊急対応や締切が重なった場合の判断者を決めておきます。
テーマの承認基準をそろえる
承認では完成度よりも、解決したい課題、想定する利用者、検証方法、安全上の懸念を確認します。
事業との関係を一文で説明できないテーマは、範囲を狭めるか、個人の学習活動と分けて扱います。
小さく試せる環境を用意する
サンドボックスとは、本番環境や実データに影響を与えずに試作するための隔離された検証環境です。
ダミーデータ、テスト用アカウント、費用上限を用意し、本番への反映は別の審査に分けます。
知財と公開範囲を個別に確認する
成果物の権利、外部サービスの利用条件、社外発表の手順は、雇用契約や社内規程によって異なります。
「すべて会社に帰属する」と一律に決めつけず、法務、情報セキュリティ、広報などの担当者が必要な案件を早めに選別します。
終了条件を先に置く
実験には期限と判断日を設け、続行、方向転換、停止、本務への移管のいずれかを選びます。
停止は失敗の隠蔽ではなく、追加投資をしない根拠を残す判断です。
実験ブリーフでテーマを具体化する
実験ブリーフとは、試す前に目的と判断基準を一枚程度へまとめる短い計画書です。
長い企画書を求めると探索の速度が落ちるため、次の項目に絞ります。
- 課題：誰が、どの場面で困っているか
- 仮説：何を変えると、どの指標がどう動くと考えるか
- 方法：対象範囲、期間、必要なデータと費用
- 安全確認：個人情報、機密情報、法務、ブランドへの影響
- 成果物：試作品、検証記録、手順書など
- 判断基準：続行、方向転換、停止を選ぶ条件
似たテーマがすでに動いている場合は、重複を機械的に止めるのではなく、統合するか、異なる仮説として並行検証するかを決めます。
仮説と指標の作り方
指標は成果を約束する数字ではなく、仮説を採用するか退けるかを判断する材料です。
次の表は実績ではなく、テーマを測定可能な形へ直すための例です。
| 場面 | 仮説の例 | 確認する指標 |
|---|---|---|
| プロダクト | 通知の時間帯を調整すると、必要な情報へ気付きやすくなる | 開封率、解除率、アプリ起動率 |
| バックオフィス | 申請書の要点を先に示すと、確認の往復が減る | 承認時間、差し戻し率、質問件数 |
| 店舗 | 補充動線を短くすると、作業負荷を下げられる | 補充時間、歩数、利用者からの問い合わせ |
| アクセシビリティ | キーボード操作とフォーカス表示を改善すると、操作を完了できる利用者が増える | 操作完了率、検出した障壁、利用者テストの結果 |
改善率を先に断定せず、測定前の数値は「目標」または「仮説」と明記します。
数値だけでは理由が分からない場合は、利用者の観察記録や自由記述も残します。
一つの実験を判断まで進める流れ
- 課題を登録する：困りごと、対象者、現状を短く記録します。
- 範囲を絞る：一つの画面、一つの作業、一つの部署など、影響を限定します。
- 安全を確認する：データ、権限、費用、外部公開の可否を確認します。
- 試作品を作る：完成品ではなく、仮説を確かめる最小限の形にします。
- 結果を共有する：数字、観察、限界、再現手順を記録します。
- 次の扱いを決める：続行、方向転換、停止、本務への移管を選びます。
会議の回数や実験期間は固定せず、リスクと検証に必要な時間に合わせます。
ただし、判断日だけは先にカレンダーへ入れ、検証が目的のない開発へ変わるのを防ぎます。
成果と学びを分けて評価する
採用された機能の数だけで評価すると、参加者は安全なテーマを選び、失敗を隠しやすくなります。
評価は、結果、学び、進め方の三つに分けると扱いやすくなります。
- 結果：本務へ移した成果、利用状況、確認できた効果
- 学び：退けた仮説、再利用できる記録、次に試す条件
- 進め方：安全確認、関係者との合意、他チームへの共有
本人、支援者、上長が同じ記録を見て振り返り、活動時間の長さや発表の巧さだけで評価しないようにします。
想定されるリスクと対策
| リスク | 対策 |
|---|---|
| 本務の遅延 | 時間の上限と優先順位を業務計画に入れ、縮小を判断する担当者を決める |
| 隠れ残業 | 就業時間内の活動とし、時間外の自主参加を成果評価の条件にしない |
| テーマの重複 | テーマ一覧を検索できるようにし、統合と並行検証を選べるようにする |
| 技術的負債 | 試作品と本番コードを分離し、本番化の前に設計、テスト、保守担当を確認する |
| 情報漏えい | ダミーデータを基本とし、実データが必要な場合は権限と利用目的を確認する |
| 参加機会の偏り | 申請、発表、レビューに複数の方法を用意し、職種や勤務条件による不利を点検する |
アクセシビリティを参加条件に組み込む
制度の入口が使いにくいと、良い案がないのではなく、提案できる人だけが限られます。
Webアクセシビリティの基本はWebサイトだけの話ではなく、社内の申請画面や共有資料にも応用できます。
- 申請書は見出し、要点、根拠の順にし、略語を説明する
- テキスト、録画、非同期レビューなど、複数の提出方法を用意する
- 申請画面をキーボードとスクリーンリーダーで操作できるようにする
- 色だけで状態を示さず、文字やアイコンを併用する
- 育児、介護、通院、時差勤務を考慮し、発表方法と時間帯を選べるようにする
成果は使った時間ではなく、検証の質と共有された学びで評価します。
最初の試行を始める手順
- 一つか二つのチームに対象を絞る
- 時間の上限、対象テーマ、禁止事項、判断者を一枚にまとめる
- 実験ブリーフと結果記録のテンプレートを用意する
- 一回の試行を終え、参加者と管理者の負荷を確認する
- 残すルール、変えるルール、廃止するルールを決める
最初から全社制度を完成させるより、一回の試行で運用上の詰まりを見つけるほうが、修正範囲を限定できます。
開発チームで始める場合は、開発効率化の実践フレームワークも、待ち時間や手戻りをテーマへ分解する参考になります。
20％ルールのよくある質問
毎週20％を必ず使う制度ですか
必ずしも固定の時間割にする必要はありません。
自社では上限や目安として定義し、まとめて確保する方法も含めて、本務との調整方法を決めます。
忙しくて時間を確保できない場合はどうしますか
まず、20％活動を時間外へ移さず、業務計画に含めます。
それでも確保できない場合は、テーマ数を減らすか、短い検証へ分割します。
アイデアが出ない場合はどうしますか
問い合わせ、差し戻し、手入力、待ち時間など、繰り返し発生する小さな手間から探します。
解決案より先に困りごとを共有すると、別の職種から仮説が集まりやすくなります。
成果が出なかった実験は評価できますか
仮説を退けた根拠と再現手順が残っていれば、同じ投資を繰り返さないための学びになります。
ただし、記録がなく安全確認もしていない活動まで、失敗という理由だけで評価するものではありません。
小さな実験を組織の選択肢に変える
20％ルールは自由時間を配る制度ではなく、通常業務の外側にある仮説を、期限と安全条件を設けて確かめる仕組みです。
時間の上限、実験ブリーフ、隔離された環境、判断日、共有記録をそろえると、採用した成果と採用しなかった学びの両方を残せます。
まずは一つの困りごとを選び、試す範囲と終了条件を一枚に書くところから始めます。
この記事に関連する株式会社greedenの取り組み
20％ルールで見つけた業務課題を試作から本番運用へつなげるには、検証結果を要件に落とし込む工程が欠かせません。
株式会社greedenは、Webシステム開発を企画、設計、実装、保守まで一貫して支援します。