経済産業省 Digital Service playbook
わたしたちは政府のデジタル化に挑戦を続ける、経済産業省DX室のメンバーです。 このplaybookには、わたしたちが日頃デジタルサービスを生み出すうえで大事にしていることが詰まっています。 古い行政組織カルチャーから抜け出し、何よりもユーザにとって使いやすいサービスを追求し続けるという熱いマインドを政府・自治体のデジタル化にかかわるすべての人に、そしてこれから続く後進者に伝えるため、このplaybookをシェアします。
目次
なぜこのPlaybookを作るのか
我々経済産業省DX室が目指すのはユーザーにとって利用しやすいデジタルサービスを、効率的、効果的に開発することである。一方で現状はユーザーに寄り添ったサービスデザインがまだあまりなされておらず、その手法も省内で確立していない。加えて、ツールやソフトウェアの共有、開発プロセスのベストプラクティスの共有が効率的、効果的になされていない。
良い取組が再現され、さらにその上に良いやり方が生まれるといった状況にならなければ、いつまでも最短距離で良いデジタルサービスを組織として作っていくことはできない。 シェアすることは大きな価値を持つ。シェアを通じて自分が行なっていることが相対化され、組織の「カルチャー」を作っていくことにつながる。これを形にして残していくことで「ルール」が生まれる。 現在の行政組織のカルチャーは古く、これに併せた形ではいつまでも旧来型の「行政システム開発」の「ルール」から抜け出すことはできない。
CIO補佐官、デジタル化推進マネージャーといったエキスパート集団が経産省の中で新しいプラクティスを重ねていくことで、初めて新しい「カルチャー」・「ルール」が生まれ、組織が変革されるとともに国としても良いサービスが提供できるようになるはずだ。
やり方を変え続け、洗練させなければ、良いものは生まれない。現状の組織のあり方に文句を言うのでなく、新しいカルチャーを経産省に作るという強い意志を持ってこのプレイブックを発展させていく。
1.DXオフィスのカルチャー
以下DX室として、エキスパート集団として、どういったマインドセットで働くべきか、皆でカルチャー・ルールを作っていく上で共有すべき行動規範を示す。
1. セルフスターターであること
- 自分がプロジェクトのオーナーであるとの自覚と責任を持つこと。
- 行政のデジタル化は日本を変革する大事な役割であるという認識の下に、①大局的な視点と②プロジェクト単位の視点の両方を持つ。
- ①の視点は自分が政府の、経済産業省のDXにおいてどんな役割を果たすべきかを客観的に把握できる。
- ②は個別のサービスをコントロールする上で必ず必要。それぞれのプロジェクトにアサインされている行政官、ベンダーの力量を把握し、自分がどこまでの働きをするべきか考える。
2.フラットな立場で議論し、関係者を巻き込むこと
- 職場において上下関係はない、役割の違いがあるだけだと考える。議論の際も、相手の役職にこだわらず課題を議論する。
- 一方で人格的に課題のある人と仕事をすることもあるかもしれない。その際は相手の立場に立ってみて、その人がこだわっている点は何なのかを探り、その点について安心感を与えてあげるように誘導していく。
- また、省内・外部のステークホルダーとの関係構築の感度を高め、アンテナを立てておく。省内の人は部署が変わっても一緒に仕事をした経験などつながりがあれば、支援者になってくれるかもしれない。外部の人は連携することで自分の課題解決の糸口が見つかるかもしれない。
- 課題解決のアイディアと同じくらい、それを実現するために必要な支援者のプールを持つことは重要。
3. 情報をシェアし、助けあうこと
- 自分が学びの中で得たインサイトや、他の人にも知ってもらいたいと思うことを積極的にシェアする。
- シェア内容は①自分の業務の内容、②自分の関心事項の二つがあるが、両方をシェアすること。
- ①のシェアで、同じ課題にぶつかった際の解決速度は上がり、サービスの連携等による付加価値は上がる。
- ②のシェアで、自分の関心分野のフラッグを立てられるだけでなく、新しい技術トレンドやサービスに関する感度を高め、クリエイティビティが増す。
- シェアを通じて、課題にぶつかった時に誰に助けを求めればよいかがわかる。助け合うことでチームとしての一体感が生まれる。いつでも助けを頼める関係性を皆で作っていく。
4. 失敗を恐れずチャレンジすること
- 失敗する、課題が生じるということはそれだけ難しいことにチャレンジしているという証拠であり、これらにぶつからないということは現状に甘んじているということである。
- おかしいと思ったことは戦い、攻めきれるところまで攻める。その一歩が世の中を変えると信じる。
- 組織内の課題解決が必要な時は行政官に助けを求め、2人３脚で突破する。失敗したとしてもサービスはワンショットでは終わらない。そこから学んだことを次のフェーズで反映させれば良い。
- 2.①のシェアは、失敗の経験、そこから何を学べたかも含む。プラクティスを蓄積し、失敗を成功への道につなげる。
5. ワクワクする仕事をすること
- 直面している仕事は辛いものかもしれない。でもそれが成功したら日本はどう変わるだろうか。サービスの対象者はどれだけ楽になるだろうか。その仕事の先の未来にワクワクできるならそれを少しでも楽しむ。
- 我々のイマジネーションがサービスデザインを変え、日本のあり方を変える。自分が信じなかったら、誰が信じるだろうか。
- 世の中の多くの既成概念は一握りの人たちが盲目的に従った結果としてできている。我々はデジタルサービスを提供するとともに、その既成概念をぶち壊す仕事をしている。
- 新しいデジタルインフラを作る仕事をしている。ワクワクしないだろうか。新しい社会をデジタルでデザインしよう。
2.サービス開発の基本的な考え方
本プレイブックでは開発のフェーズを3つに分けて整理する。その基本的な考え方について以下に示す。
1. サービスをデザインする
- まずは現状にどんな課題があり、それをどのようなデジタルサービスで解決するのかといったことを整理し、基本的な設計、デザインを行う必要がある。
- 重要なのは誰にとってのどのような課題を解決するかを特定することである。その結果として目指すべき理想像を明らかにし、そのギャップを明らかにする。
- その上でユーザーの体験をどのようにデザインするかといったサービスデザインの検討が必要である。実際のユーザーの立場に立ち、どのようなペインがあるのかをサービスのジャーニーを追うことで明らかにし、そのペインの解消をどのようなサービスで行うのが望ましいかを検討する。
- その際に、既存のシステム、プロセスが確立されている場合にはそれがデジタルテクノロジーを前提として効率化されているかを見直す必要があり、BPRを通じて、サービスの裏側のオペレーションにおいても不要なデータや、人の介在を最小限にするデザインを考える。
- これらを検討した上でデジタルサービスに求められる要件定義、仕様書作成を行うことで、実現したいサービスの全体像を取りまとめる。仕様書においては、経産省として標準的に利用するツールや、接続する既存サービスなどについても整理しておく。
- また、この段階で実際にサービスの効果を検証する上でのKGI、KPIや費用対効果などについても整理しておくことで、実際にサービスが開始した後の効果検証の方法についてもあらかじめデザインしておく必要がある。
◆フェーズ詳細
2. サービスを形にする
- サービスのデザインができた上で、どのように開発を行うかを検討していく。サービスの性質を考えた上で、既存のツールを利用し内製で開発可能なのか、それともITベンダーへの委託が必要なのかを判断する。
- ITベンダーに委託する際にはそのベンダーの能力を評価するための評価基準を持つ必要があるだけでなく、幅広い市場のプレーヤーについてソーシング可能な環境を持つ必要がある。加えて、ベンダーが特定されたとしても、実際に開発に携わるチームが２人３脚で走れるメンバーなのか、実力があるのかを把握するためにハッカソンなどを通じてその実力を評価する仕掛けも必要である。
- 開発に当たってはアジャイル型の開発手法を取るのか、ウォーターフォール型の手法を取るのか判断する必要がある。
- ユーザーの使いやすさが重視されるフロントエンドのサービス、システムオブエンゲージメント（SoE）の場合は、作りながら、ユーザーテストを行い、反応を見て改善していくアジャイル型の開発が望ましいと考えられるのに対し、データベース等、きちんと仕組みとして安定稼働が求められ、開発方法も確立しているシステムオブレコード（SoR）の場合には、ウォーターフォール型の開発も考えられる。開発の内容、チームの能力に応じて、どのような開発を行うのか選択する必要がある。
- またチームメンバーの役割についてもベンダーだけでなく、経済産業省サイドでも予め割り当て、どのようなフォーメーション、責任分担で開発を進めるのかを整理しておく必要がある。
- サービス開発に当たっては、経産省全体のシステムとの関係でどのように位置付けられるのか、どのような連携の可能性があるのかも念頭に置きながら進める。更に他省庁のシステムや、民間のデジタルサービスも含め、ソフトウェアエコシステム全体においてユーザーにとって最適な構成を考え、APIでの接続関係をデザインする必要がある。
- 政府・経済産業省で作成したサービスであることを示し、ブランディングを進める上では、デザインシステムの導入等を通じて開発されたサービスの統一感も意識する。
- システムセキュリティや取り扱うデータの機密性の扱いについても配慮しながら構築を進め、テスト工程もなるべく自動化を進めていく必要がある。
- 構築したサービスについてはスモールグループのユーザーによるレビューなどを通じてユーザビリティテストを行い、実際のユーザーにとって使いづらい部分がないかを確認し、リリース前の調整を行う。
- ソフトウェア資産を統一的に管理し、開発したベンダーのみがソースを理解できるといったことが生じないような仕組みを検討し、経産省が運用する統一的なガバナンス体制を構築する。
◆フェーズ詳細
3. サービスを育てる
- DevOpsのコンセプトを持ち込み、開発と運用を一体的に行い、自動化を進めることで、ヒューマンエラーを減らし、安定的なシステム運用と機能の拡充の両方を実現していく必要がある。
- サービスをリリースした後もこれが利用されるように育てていく、より便利にしていく必要がある。既存ユーザーのエンゲージメントを高めるにはユーザーがサービス利用で行き詰まった際に手厚くサポートすることが望まれる。ユーザーが行き詰まった箇所がわかれば、その箇所の機能に課題があることがわかり、サービス改善の糸口にもなりうる。
- 加えて、当初のサービスの目的を達成しているかを評価するため、KGI、KPIの推移を評価していく必要がある。その他ユーザーデータに着目することで、本当に利用しているユーザーは誰で、どの機能を使っているのか、新しい機能へのニーズはないのかを追いながら改善を繰り返していく必要がある。
- 利用率を高めるためには、マーケティングを通じユーザーがアクセスするチャネルで認知を高め、利用へのコンバージョンを高めていくことが望まれる。
- サービスはリリースしたら終わりではなく、継続した改善を通じて真にユーザーに使いやすい状況を追求し続ける姿勢が重要であり、これこそが行政サービスに欠けている姿勢である。
- 分析結果を通じて、再度課題を問い直し、サービスを改善することが重要であり、サービスを「デザインする、形にする、育てる」のプロセスはループして何度も繰り返されるべきものである。
◆フェーズ詳細