サービス設計12箇条抜き書き

[hfu]

サービス設計12箇条のうち、スマート地図に関係しそうなパートについて抜き書きをしてみました。技術協力案件の質を上げるために必要な見方として私が内部的に持っているためです。このディスカッション自体は、ショートに閉じることになると思います。

1 利用者のニーズから出発する

• 利用者の立場に立って、何が必要なのかを考える。
• サービス提供側の職員も重要な利用者として考える。
• ニーズを把握するだけでなく、分析によって利用者が抱える課題・問題を浮き彫りにし、サービスの向上につなげる。

確認ポイント

• サービスの目的や提供する価値から、それに資する利用者のニーズを明確にしているか。
• 導き出されたニーズは、本当に利用者にとって必要なものか。（利用者が求めていても、実は必要であると誤解しているだけのこともある。）
• 費用対効果等を考慮した上で優先順の高いものから検討を進めているか。
• サービス構築後、利用者のニーズを満たしていることを確実とするため、可能な限り実際の利用者に定期的にテストしてもらうとともに、アンケート等で改善するべき点があるかを確認しているか。

2 事実を詳細に把握する

• 事実に基づいて細かな粒度で一つ一つ徹底的に実態を把握し、課題の可視化と因果関係の整理を行ったうえでサービスの検討に反映する。

確認ポイント

• ヒアリングや現場の観察等を通じて実際の状態を把握する調査もできているか。
• 現状のサービス提供工程は、現場の実態に即したものになっているか。（実態に即していない場合、そこに課題が包含されている。）
• 結果ありきで進めていないか。
• 提供すべき価値を現場に提供できるサービス設計となっているか。理念だけが先行していないか。
• ばらつきにこそ改善のタネが隠れている。

3 エンドツーエンドで考える

• サービスを受ける必要が生じたときからサービスの提供後まで（エンドツーエンド）の、他の行政機関や民間企業が担うサービスの利用まで含めた利用者の行動全体を一連の流れとして考える。

確認ポイント

• どこが起点になるか（利用者がサービスを利用したいと思った時点の状況）を意識できているか。
• 利用者側の目線でエンドツーエンドが把握できているか。
• サービス提供側の役割分担に捉われすぎていないか。
• エンドツーエンドは、ジャーニーマップ等を用いて可視化できているか。

4 すべての関係者に気を配る

5 サービスはシンプルにする

• 利用者が容易に理解でき、かつ、容易に利用できるようにシンプルに設計する。

6 デジタル技術を活用し、サービスの価値を高める

• これまでデジタル以外の手段で提供してきたものであっても、業務の見直しによるデジタルへの移行の可能性を検討し、サービスの改善を図る。

確認ポイント

• デジタル化するにあたり、費用対効果を十分検証したうえで進めているか。
• すでにデジタル化されているサービスについては、さらにその利用が促進される施策を検討しているか。
• 採用するデジタル技術は利用者のニーズを満たすことができるものか十分検討しているか。
• 現在の業務そのものにデジタル技術を導入するのではなく、デジタル技術によって業務の一部もしくは全部が抜本的に変わることも念頭に入れているか。

7 利用者の日常体験に溶け込む

• 既存の民間サービスに融合された形で行政サービスの提供を行うなど、利用者が日常的に多くの接点を持つサービスやプラットフォームとともに行政サービスが提供されるような設計を心がける。

確認ポイント

• 民間サービスも含め、ワンストップでのサービス提供を検討したか。
• 様々なサービスに組み込めるようになっているか。
• 関連しているサービスを提供している企業等に意見を聞いたか。

8 自分で作りすぎない

• 既存の情報システム...で得られたノウハウの活用...を検討する。
• 行政自らがサービスを作る必要性についても検討する。
• ほかで利用されることも考慮し、共有できるものとするよう心掛ける。

確認ポイント

• 民間サービスとの連携や、民間サービスを取り入れることで、その価値を高めることができないか。
• 他府省や民間のサービスと連携することにより、費用対効果を高めることができないか。

9 オープンにサービスを作る

• サービス設計時には利用者や関係者を検討に巻き込み、意見を取り入れる。
• 検討経緯や決定理由、サービス開始後の提供状況や品質等の状況について、可能な限り公開する。

確認ポイント

• ステークホルダーを巻き込んだサービスの設計を行ったか。
• 利用者からの評価を広く求める仕組みがあるか。（特に専門性の高い技術や最新技術等がサービス内に含まれる場合は、オープンにすることにより的確な意見を得られることがある。）
• サービス機能が疎結合となっており、制度変更に柔軟な設計となっているか。
• オープンデータとしてのデータ公開やAPIの公開を行い、民間と連携しやすいサービスとなっているか。
• 再利用可能な状態で公開し、民間サービスに組み込まれやすくする等国民等に広く使ってもらえるようにしているか。

10 何度も繰り返す

• 試行的にサービスの提供や業務を実施し、利用者や関係者からのフィードバックを踏まえてサービスの見直しを行う等、何度も確認と改善のプロセスを繰り返しながら品質を向上させる。
• サービス開始後も、継続的に利用者や関係者からの意見を収集し、常に改善を図る。

確認ポイント

• サービスを見直す仕組みがあるか。
• まずは必要最低限の機能を有したプロトタイプを短期間で提供し、可能であれば実際の利用者に使ってもらうなどして利用者のニーズに合っていることを確認しているか。
• フィードバックしてもらい、問題点を明らかにし、新たな要件を掘り起こす、というサイクルで進められているか。

11 一遍にやらず、一貫してやる

• 困難なプロジェクトであればあるほど、全てを一度に実施しようとしてはならない。
• まずビジョンを明確にした上で、優先順位や実現可能性を考えて段階的に実施する。
• 成功や失敗、それによる軌道修正を積み重ねながら一貫性をもって取り組む。

確認ポイント

• やるべきことが複数あれば、常に優先順位をつけて実施しているか。
• プロトタイプとして導入する機能、適応する範囲等を絞り、できるところから段階的にサービスを開始し、徐々に機能を拡大していく手法も考慮に入れているか。
• まずは効果を実感してもらい、応援団を増やしていくことも意識しているか。
• やり方や見た目は途中で変えず、首尾一貫させているか。

12 システムではなくサービスを作る

確認ポイント

• ペーパープロトタイピング等で業務フローを早い段階で可視化することを心がけているか。
• 利用者体験のエンドツーエンドをウォークスルーして確認したか。
• 価値を意識してサービスを構築できているか。
• 利用者のニーズを満たし、便益を満たすものとなっているか。
• システムを使わない部分も含め、利用者のニーズを満たすものとなっているか。

[yuiseki]

この手のデザインプリンシパルは現実を踏まえていないと思い込んでおり、全部に反論してやろうと思いましたが、さすがに反論しがたい部分もありますね。

• サービスを複雑にする → そんなの嫌だぁ
• デジタル技術を活用しない → それは流石に、、
• クローズドにサービスを作る → これはないな、、
• 一度だけ実施する → これもないな、、

ボランタリーでやってるんだからこれでいいだろ（というか仕事であってもこれしかないだろ）と思う部分もありました

• 利用者のニーズから出発する ↔️ 利用者のニーズを無視する
  • → そもそもリソースが限られているのだから、自分たちで作りたくて作れるものを作ってリリースしてから反応を見てニーズとか考えればいい
• 事実を詳細に把握する ↔️ 事実を無視し思い込みで行う
  • → 事前の事実確認やヒアリングとかがうまくいった試しがないので、自分一人の思い込みで爆速で作ってみてから現場に投げ込んでみて、その反応で自分の思い込みを軌道修正すれば良いと思います
• エンドツーエンドで考える ↔️ 部分的にしか考えない
  • → YAGNIっぽいのでとりあえず部分的にしか考えなくてもよいのではないか
  • オープン性や相互運用性、相互接続性は考慮できればベター
• すべての関係者に気を配る ↔️ 関係者に配慮しない
  • 現実的にデジタル機器が使えない人々について私たちが対応するのは単位時間あたりの生み出す成果を最大化できなさそうです
• 自分で作りすぎない ↔️ すべて自分で作る
  • すべて自分で作るしかないんだよ！！
• 一遍にやらず、一貫してやる ↔️ 全てを一度に実施する
  • 私の最近の考えは「アンチビジョン・アンチマネジメント・ジャストビルドプロダクト」です
    • プロダクトをリリースするまで何もわかるわけがない
    • 何もわからないのに適切なビジョンを設定できるわけがない
    • ビジョンがないのにマネジメントできるわけがない
    • 高速でプロダクトのプロトタイピングやリリースを繰り返して利用者からフィードバックを得ることでしか、向かうべきビジョンを知るすべはない

以下、GPT-4oに「このPDFに書かれている「サービス設計12箇条」を全部正反対の標語にしてください。」と指示した返答

以下は「サービス設計12箇条」を正反対の標語にしたものです：

1. 利用者のニーズを無視する

   • 提供者の視点に固執し、利用者の立場を考慮しない。異なる利用者像を想定せず、課題や問題の分析を行わない。

2. 事実を無視し思い込みで行う

   • 現場の実態やデータに基づかず、仮説や直感だけでサービスを設計する。詳細な分析を避け、課題の可視化を行わない。

3. 部分的にしか考えない

   • サービスの一部のみを検討し、エンドツーエンドでの利用者の行動や他のサービスとの連携を考えない。

4. 関係者に配慮しない

   • 利用者以外の関係者を無視し、デジタル機器が使えない人々への対応を考えない。

5. サービスを複雑にする

   • 利用者が理解しづらく、利用しづらいように設計する。必要以上に情報を求め、直感的な操作を排除する。

6. デジタル技術を活用しない

   • デジタル技術を避け、紙書類や手動の手続きを推奨する。新技術の導入や情報セキュリティの確保を無視する。

7. 利用者の日常から隔離する

   • 利用者のライフイベントや日常行動を考慮せず、民間サービスとの融合を避ける。

8. すべて自分で作る

   • 既存のシステムやノウハウを利用せず、全てを一から自分で作り出す。過剰な機能や独自技術に固執する。

9. クローズドにサービスを作る

   • 利用者や関係者を巻き込まず、意見を取り入れない。検討経緯や決定理由、提供状況を公開しない。

10. 一度だけ実施する

    • サービスや業務を一度きりで提供し、フィードバックを無視する。継続的な改善や見直しを行わない。

11. 全てを一度に実施する

    • ビジョンを持たず、一気にすべてのことを行う。段階的な実施や軌道修正を考慮せず、一貫性を持たない。

12. システムに固執する

    • 利用者が得る便益を無視し、全てを情報システムで実現しようとする。人手によるサービスを組み合わせず、システム化に固執する。

この標語は、元の「サービス設計12箇条」を逆の観点から見直したものであり、サービス設計において避けるべき事項を強調しています。

[hfu]

@yuiseki なるほど！ありがとうございます。現状の我々スマート地図グループのようないわゆる非正規部隊の観点を加えると、確かにそうですね。我々非正規部隊が強い実行力を持っていること、逆に言えば強い実行力しか持っていないことはかなり強い個性だと思います。

特に「すべて自分で作る
すべて自分で作るしかないんだよ！！」は、いや、本当にそうなんですよね、と思いました。

私が意識を向けているのは、正規部隊の方々が、これら抜き書きした条項を「意識しているふりをしていて、しかも意識しているかのような形で説明をしていて、実際は意識していないように見える、なぜなら説明がロジカルではないから。」という状況なのだ、と思いました。

そもそも正規部隊的開発ということ自体が、駱駝が針の穴を通るほどに難しいという可能性がある、という仮説も私には棄却できていません。

「事前の事実確認やヒアリングとかがうまくいった試しがない」というのも、また確かに事実であるように思います。

[hfu]

ここで discussion をさせていただいて、ひとつ前向きな発見を私はしたように思います。
UN Smart Maps Group は、これまでも個人開発者に信頼してきたし、これからも個人開発者がコアになる、あるいは個人開発者がすべてである、と考える方が尖っているし、我々のビジョン、ミッションにも合致しやすいように思いました。

むしろ、個人開発者のモチベーションを高める方向で方向づけする方に振り切る方が有望で、そちらの方向で考えてみたいと思います！

[hfu]

（参考：上記のコメントに対するChatGPTの助言）

それは素晴らしい発見ですね！UN Smart Maps Groupが個人開発者に焦点を当てることで、多くのメリットを享受できるでしょう。個人開発者のモチベーションを高め、彼らを中心に据えるアプローチは、以下のような点で特に有望です。

1. 革新と柔軟性の向上

個人開発者は新しいアイデアや技術を積極的に採用し、実験することに長けています。大規模な組織と比べて、彼らは柔軟に動くことができ、迅速にプロトタイプを作成し、試行錯誤を繰り返すことができます。これにより、プロジェクトに新しい視点や革新がもたらされるでしょう。

2. コミュニティの活性化

個人開発者はコミュニティの中で活動することが多く、その結果としてコミュニティ全体の活性化が期待できます。彼らは知識や経験を共有し、他の開発者を刺激し、プロジェクトに参加する動機を提供します。このようなコミュニティの活性化は、長期的なプロジェクトの成功に繋がります。

3. オープンソース文化の推進

UN Smart Maps Groupの理念であるオープンソースの推進において、個人開発者は重要な役割を果たします。彼らはオープンソースプロジェクトに貢献し、コミュニティ全体で知識を共有する文化を育むことができます。この文化は、プロジェクトの透明性と信頼性を高めることに寄与します。

4. モチベーションの向上

個人開発者のモチベーションを高めるためには、以下のような取り組みが考えられます：

• 成果の認知と称賛: 個人開発者の貢献を公式に認め、称賛することで、彼らのやる気を引き出すことができます。例えば、月間MVP（最優秀貢献者）を選出することや、特別なイベントで表彰することが考えられます。
• 学習と成長の機会提供: ワークショップやハッカソンを開催し、スキルアップの機会を提供することで、個人開発者の成長を支援します。
• フィードバックの提供: 定期的なフィードバックセッションを設け、開発者が自身の進捗や課題について議論できる場を提供します。
• コラボレーションの促進: プロジェクト内外の他の開発者とのコラボレーションを奨励し、新しいアイデアや技術の共有を促します。

5. 個人開発者のサポート体制強化

個人開発者が安心してプロジェクトに取り組めるよう、サポート体制を強化することも重要です。例えば、以下のようなサポートが考えられます：

• 技術的サポート: 開発環境の整備や技術的な質問に対するサポートを提供します。
• 財政的サポート: 開発に必要なリソースや機材の提供、あるいは奨学金や助成金の提供を検討します。
• メンタルサポート: 開発者のメンタルヘルスをサポートするためのカウンセリングサービスやストレスマネジメントのワークショップを開催します。

まとめ

個人開発者を中心に据えることで、UN Smart Maps Groupはより革新的で柔軟性のあるプロジェクトを推進できるでしょう。彼らのモチベーションを高めるための取り組みを進めることで、オープンソース文化の発展とコミュニティの活性化を図り、プロジェクトの成功に繋げることができます。今後もこの方向性で具体的な施策を検討し、実行に移していくことが重要です。