試行結果のプレゼン資料：本格導入の前に成果と課題を伝える

試行結果のプレゼン資料では、限定的な試行を拡大するのか、調整するのか、延長するのか、やめるのかを検討できるようにします。事前の成功基準と実際の結果を並べ、成果と負担の兼ね合いを説明しましょう。目立つ指標が改善しても、品質や業務負担の基準を満たさなかったことは帳消しになりません。

何を試し、何が起こり、何がまだ分からず、次に何をするのか。この順に、結果を判断へつなげます。確認済みの説明文をPresentiでスライドの初稿に整理するときも、この流れを残してください。以下では、成果と課題が混在する結果を、安易に「成功」と呼ばずに7枚の報告資料へまとめます。

その試行で判断したかったことから始める

「試行の進捗報告」では、会議の種類は分かっても目的は分かりません。「新しい申請フォームを別の部門にも導入するか、修正してもう一度試すか、現行の手順を続けるか」のように、問いを具体的にします。

参加者、変更した業務手順、実施期間、対象外の範囲を問いのそばに示しましょう。1部門の結果は次の試行を決める材料にはなっても、全社展開を裏付けるとは限りません。

GOV.UK Service Manualの効果測定に関するガイダンスは、ベータ段階の開始時に指標を合意し、継続を判断するときに観測された効果と予測を比較するよう勧めています。試行結果の報告でも、結果を見てから都合のよい指標を選ぶのではなく、当初の基準を持ち込むことが重要です。

基準を事前に合意していなかったなら、その点を明記します。それでも起きたことを説明し、次の試行をどう判断するかは提案できます。後から都合のよい境界値を選び、元からの目標だったことにしてはいけません。

具体例：申請内容の改善と、残るサポートの負担

社内のサービス担当チームが、申請フォームを改訂して試すとします。比較元は旧手順での4週間、試行は1部門での2週間です。以下の数値と基準は説明用に作ったもので、実際の顧客事例でも、Presentiで得られた成果でもありません。

「初回提出時点で情報がそろっているか」は、提出項目と追加確認の記録から判断します。これは処理完了とは別です。必要な情報がそろっていても確認待ちになる場合があり、不足があっても追加確認後に処理が終わる場合があります。複数のメッセージが発生しても、申請は1件と数えます。

試行で未処理の5件も、提出された申請数に含めます。そのうち3件は申請者待ち、2件は確認担当者待ちです。除外すると集計対象が変わり、結果を読み取りにくくなります。

各結果のそばに分母を残す

初回提出時の情報充足率は、76 ÷ 100 = 76%から46 ÷ 50 = 92%へ上がり、差は16パーセントポイントです。「16%増」とは意味が異なります。各集団の規模が分かるよう、割合とともに件数も示してください。

記録された入力ミスの修正率は別の問いに答えます。基準日までに処理を終えた申請のうち、修正が必要だったのは何件か、という指標です。旧手順では4 ÷ 80 = 5%、試行では3 ÷ 45 ≈ 6.7%です。処理済み申請を対象と定義した指標に、3 ÷ 50を使ってはいけません。

試行で記録された修正は3件だけです。その内容と重大さが重要であり、未処理の5件によって、その後の状況が変わる可能性もあります。現時点の数値は観測基準日時点の説明で、長期的に安定した不具合率を示すものではありません。

サポートの数値は120 ÷ 50 = 申請1件あたり2.4分の追加作業です。新しいフォームの利用を支援した担当者の作業時間であり、利用者の待ち時間、処理時間、削減時間ではありません。比較元では同じ支援作業を測っていないため、この表から正味の作業時間の削減や、導入前後の業務負担の変化は判断できません。

混在する結果を、平均して消さない

この例では、チームは試行前に3つの基準を合意していました。基準値はこの架空の判断のために設定したもので、業界の標準ではありません。

「新フォームは成功率92%で試行に合格」という見出しは、未達成の2項目を隠し、情報の充足率を全体の成功率へ置き換えてしまいます。「情報のそろった申請は増加。修正とサポートの目標は未達成」の方が適切です。

3つの指標を平均し、1つの信号色にまとめないでください。対象も単位も異なり、防ぎたい問題も違います。責任者が未達成の基準を承知で先へ進む場合は、判断とその条件を記録し、結果を「合格」に書き換えないようにします。

観察された改善と、その説明を分ける

フォームだけでなく、観測期間が変わり、申請者や申請の種類も変わったかもしれません。この試行は参加しやすい対象で実施しており、無作為割付や同時期の比較群はありません。16ポイントの差だけでは、フォームが改善の原因だったとは証明できません。

次の対応が変わるような説明を探しましょう。単純な申請が多く含まれていなかったか。担当者の支援が増えていなかったか。繁忙期を外していなかったか。両集団で情報がそろったと判断するルールは同じだったか。こうした問いは、文末の一律の注意書きではなく、結果のそばで扱います。

架空の試行では、チームは曖昧な入力項目が修正作業を増やしていると疑っています。これは仮説です。共通原因だと述べる前に、修正された3件とサポートの記録を確認します。別々の問題が起きていたなら、1つの項目を書き直すだけではすべてを解決できないかもしれません。

定性的な観察と件数は分けます。参加者の発言は、どこが分かりにくかったかを説明する材料にはなっても、その問題の広がりを示すものではありません。利用が認められ、誰の発言かを示せる言葉がある場合だけ使い、親しみやすい資料にするために発言を作らないでください。

範囲を限定した次の一手を提案する

この例なら、修正が必要だった記録を調べ、根拠に応じて問題の入力項目を明確にしたうえで、拡大前に同程度の範囲で再試行するという提案が考えられます。これは提案であり、承認済みでも、次は目標を達成するという予測でもありません。

次の説明文には、変更後のフォームの版、参加部門、観測期間、サポート体制、指標の定義、判断基準を記載します。同じ問いに答えられるなら、同じ指標を使います。定義を変える場合は理由を示し、何も変わっていないかのように旧数値と比較しないでください。

判断に合った観測期間と参加計画は、分析担当者やサービスの責任者と決めます。「前回は50件で足りた」は統計的な主張の根拠にはなりません。この例では、必要な標本数の計算も有意差検定も行っていません。

責任者がすぐに対象を広げたい場合は、対象部門、支援内容、受け入れる未解決のリスク、どのような観測結果で中断するかを明確にします。全社展開と、もう1チームを試行に加えることでは、判断の重さが異なります。

試行結果を7枚で伝える構成例

1. 提案。修正とサポートの課題を確認した後、範囲を限定して再試行することを提案します。承認はこれからです。
2. 試行範囲。新旧の手順、参加者、期間、基準日、比較上の制約を示します。
3. 当初の基準。結果の前に、合意した3つの基準値を示します。
4. 観察した結果。76/100と46/50、4/80と3/45、120/50分の担当者作業を示し、指標を分けます。
5. 未説明の点。未処理の申請、修正記録、サポートの記録、疑われる入力項目の問題を、原因と断定せずに示します。
6. 次の試行または別案。変更点、比較できるように維持する点、次の観測で支える判断を明確にします。
7. 決定と条件。責任者が実際に合意した内容を記録し、確定後に担当者と事後確認日を示します。

申請ごとのデータと計算は補足資料に残します。本編には、会議中に聞き手がすべての分母を逆算しなくても、提案の理由が分かるだけの情報を載せましょう。

混在する結果を保った入力文を用意する

サービスの責任者が数値を確認したら、PresentiのPaste Text（テキスト貼り付け）入力でメモをスライドの初稿に整理できます。数値とともに定義と限界を入力し、試行が成功かどうかをツールに決めさせないでください。

次の架空の社内フォーム試行から、7枚の試行結果報告資料を作成してください。比較元は4週間で、重複のない申請100件、初回提出時に情報がそろっていた申請76件、処理済み80件、そのうち入力ミスの修正が必要だった申請4件です。試行は1部門で2週間、申請50件、初回提出時に情報がそろっていた申請46件、処理済み45件、そのうち修正が必要だった申請3件、追加の担当者サポート120分です。未処理の5件は、3件が申請者待ち、2件が確認担当者待ちです。情報充足率は76%と92%で差は16パーセントポイント、処理済み申請の修正率は5%と約6.7%、試行の申請1件あたりサポートは2.4分と示してください。この例の事前基準は、情報充足率90%以上、修正率5%以下、サポート2分以下です。達成したのは情報充足率だけです。無作為化試験ではありません。修正とサポートの課題を調べてから同程度の範囲で再試行することを提案し、判断は未承認としてください。因果関係、削減効果、有意差、本格導入の成功を作り上げないでください。

初稿では、各割合に件数が添えられているか、未処理の申請が消えていないか、サポート時間が「削減時間」に変わっていないかを確認します。現時点の試行が拡大の全条件を満たしていないと明言しながら、次の試行を提案することはできます。