千葉小4虐待死事件から自動相談所の問題点について多くが語られるようになりました。自動相談所の対応が杜撰だったと「質」を批判する声が上がるとともに、児童相談所の職員はそもそも足りておらず、対応が追いつかないと「量」の問題を提起する声も上がりました。実を言えば「質」の問題はなかなか解決が難しく、「量」の問題の方が解決しやすいです。
実際に安倍晋三首相は2019年2月9日に児童相談所の専門職員を5000人体制にする意向を表明しました。現在は3200人で、来年度から4200人に増やし、その後5000人体制にするそうです。まずは、「量」の問題を解決する姿勢を示しました。
「量」の問題と「質」の問題の解決方法
もちろん「量」の問題を解決するのは大切です。「量」の問題とはベースとなる数字の問題です。例えば10+10=20で例えれば「10」を「40」にして10+40=50にするのが「量」の問題の解決方法です。そもそも50必要なのに10しかないのであれば、まずは40足すしかないでしょう。
一方で、「質」の問題は演算子の問題です。同じ10+10=20をたとえに使えば、「+足し算」を「×掛け算」にして10×10=100にするのが「質」の問題の解決方法です。「質」の問題の解決方法はスタートアップでは「スケールするやり方を見つける」と言います。例えば、「数が足りていれば児童相談所は誤った判断をしなかったのか？」という問題です。正しい判断が個人に依存せずに（できる／できない）というのは質の問題です。
それでは、いきなり「+足し算」を「×掛け算」にできるかと言えばそんなことはありません。「スケールしない方法」から学び、徐々に「スケールするやり方を見つける」必要があります。じゃあ、そうすればいいじゃない？と思いますよね。しかし、これがなかなかできません。
「質」の問題解決に転換できない原因
誰しも「悪いことをしてやろう」とか「子供なんて適当にしておけばいい」なんて思っているはずはなく、それは児童相談所で働く人たちも同じです。たくさん人数がいるので、ひょっとしたらいるかもしれませんが、それほど多くないはずです。だから、「質」の問題と言われると抵抗感を感じることもあるでしょう。
「こんなにガンバっているのに」
問題は個人の頑張りではなく、仕組みです。「10」はどれだけ頑張っても「10」ですし、残業して「12」にしても長続きはしません。つまり、スケールしません。「スケールするやり方を見つける」というのは個人が頑張らなくてもできる仕組みを作るということです。
この、仕組みを作るというのは「言うは易く行うは難し」です。特に児童相談所のような公共サービスはそうです。様々なステークホルダーがいますし、法律など従わなければいけない規則もあります。
優先順位と信念
自分自身、様々なサービスのプロジェクトに関わった経験上、日本のプロジェクトでデザインプリンシプルを定めているケースはあまりないように感じます。「質」の問題があるとしたら、第一の理由はここにです。プリンシプルというのは日本語では「原理原則」です。法律でいえば憲法のようなものです。
イギリス政府のデジタル公共サービスの場合ですとデザインプリンシプルは以下になります。
- ユーザー起点（Start with users）
- なるべく少なく（Do less）
- データに基づいて設計する（Design with data）
- シンプルにするために頑張る（Do the hard work to make it simple）
- 繰り返し改善（Iterate. Then iterate again）
- 全ての人のために（This is for everyone）
- 背景を理解する（Understand context）
- Webサイトではなくデジタルサービスを作る（Build digital services, not websites）
- 統一性ではなく、一貫性を持たせる（Be consistent, not uniform）
- オープンにする。オープンにすれば良くなる（Make things open: it makes things better）
おそらく特徴的なのは6番目の「全ての人のために（This is for everyone）」でしょう。これは公共サービスならではです。民間のサービスですと、ターゲット顧客がいて、そのターゲット顧客に最適かすることで効率化を行います。しかし、公共サービスですと市民全員がユーザーですので、インクルーシブなデザインを心がける必要があります。
しかし、一番重要なのは1番目の「ユーザー起点」でしょう。ユーザーからはじめる。これを原理原則とする。そのためにはまずはユーザーを理解しなければいけません。では、どのようにユーザーを理解すればいいのでしょうか。
ユーザー起点で考える公共サービスデザイン
サービスデザインの考え方ではユーザーは二種類あります。一つはサービスを受ける側。もう一つはサービスを提供する側です。児童相談所の場合、相談をする児童や関係者がサービスを受ける側で、児童相談所の職員やその関係者がサービスを提供する側になります。この関係性を描く図式をサービスブループリント（以下の図）と言います。
サービスブループリントではサービスを舞台に見立て、サービスを受ける側の舞台を「フロントステージ」、サービスを提供する側の舞台を「バックステージ」と呼びます。そして、左から右へプロセスを書いていきます。フロントステージのユーザーが右端まで来るとき、問題が解決されていなければいけません。
それを「バックステージ」のユーザーのユーザーがどのようなプロセスや仕組みで「フロントステージ」のユーザーを助けるのかを「バックステージ」のプロセスとして描きます。サービスブループリントを描くためには「フロントステージ」と「バックステージ」双方のユーザープロセスとそれを支える仕組みを棚卸しなければいけません。上記のデザインプリンシプルでは7番目の「背景を理解する（Understand context）」がここにあたります。その時に重要なのが「タッチポイント」の概念です。
例えば、児童相談所に相談したい児童がいた場合、その児童がどのように最初のコンタクトを児童相談所にするのか？何か書類があるのか？Webサイトから申し込むのか？それとも、児童相談所に直接行くか、電話をするのか？その場合、児童相談所の住所や電話番号はどうやって調べるのか？Googleで検索するのか？このハイライトした部分が全てタッチポイントです。タッチポイントは「フロントエンド」と「バックエンド」をつなぐラインです。ユーザーである児童がLINEをよく使うのであれば、LINEが最も適切なタッチポイントである可能性は高いです。ユーザー起点でタッチポイントを考えるというのはこういうことです。
このラインが断線しているとサービスを受けることができません。例えば、児童相談所の住所や電話番号がわかりづらければサービスは断線してしまいます。また、脱線してしまうと、本来受けたいサービスが受けられずにたらいまわしになります。所得税なのか住民税なのかで税金を納める場所が違いますが、こういう場合は脱線が起きやすいです。この断線と脱線の概念もサービスデザインやUXでは非常に重要な概念です。
事実をベースにデザインする
このようにサービスを「フロントステージ」と「バックステージ」に分けて整理をするとどこで断線が起きるのか、どこで脱線するのか、どこで停滞するのかが見えるようになります。これは観察から導き出してもいいですし、何かシステムを使ってデータをとってもいいです。何れにせよ「なんとなくそう思う」ではなく、事実ベースで整理整頓をすることが必要になります。3番目のデザインプリンシプルである「データに基づいて設計する」です。
この整理整頓のフェーズとデザインのフェーズでは必ず憲法であるデザインプリンシプルに従っているのかを確認する必要があります。特に2番目の「なるべく少なく」や4番目の「シンプルにするために頑張る」は常に意識しないとできません。
多くのプロジェクトは仕組みを作ることがゴールとなってしまいます。そのため結果を振り返ることは稀です。振り返らなければ学びは失われます。そこで重要なのが5番目のデザインプリンシプルである「繰り返し改善」です。仕組みを作ることがゴールではなく、ユーザーの問題を解決することがゴールです。そのためには常にデータを取り、データに基づいて繰り返し改善をする必要があります。
イギリスの公共サービスデザインから学ぶ
イギリスの公共サービスデザインからは学ぶことが多くあります。多くの事例をこのブログでは翻訳していますので、ぜひ参考にしてみてください。
