daisuzz.log

「経産省と本気でアジャイル開発をやってみた!〜」 参加レポート

先日、「経産省と本気でアジャイル開発をやってみた!制度ナビPJで見えたGovTechのリアルと未来」というイベントに参加してきたので、イベントの様子や参加して感じたことを書き連ねていきたいと思います。

議事録のようなものではなく、あくまで登壇者の発表を聞いて感じたことを一個人が書いているエントリなのでそこは、ご理解ください。また聞き逃しや勘違いをしている箇所があるかもしれないので、その場合はコメントで指摘していただけると助かります。

イベントの雰囲気

  • 主催はCode for Japanさん
  • 会場は経産省の地下2F
  • 約250名参加
    • 会場のアンケートでは参加者の割合では開発者の方が多かった
    • 省庁関係者の方らしき人もたくさんいたように感じた

挨拶&Code for Japan紹介

  • Code for Japan代表理事 関 治之 さんによる発表
  • イベント全体で質問したいことはslido.jpを使って集約
  • 今回のイベントは、以下のテーマを発表
  • このイベントの目的
  • Code For Japanとは
  • なぜ行政にアジャイルが必要か?
    • 完璧な仕様は書けない
    • プロジェクトが失敗したときのリスクが大きい
    • 異動が前提
    • デジタル化についての経験値が浅い
  • なぜ行政でアジャイルが難しいか?
    • 年度単位の予算
    • 知識不足
    • 受発注者間の信頼関係構築の難しさ
    • 失敗を忌避する文化

スマート公共サービス官民協議会から見えてきたこと

  • Code for Japan理事、前総務省大臣補佐官 太田 直樹 さんによる発表
  • 太田さんのブログで発表
  • スマート公共サービス官民協議会
    • 未来投資会議の一つ
      • 6月の未来投資戦略のための会議
      • 未来投資戦略によって次年度の予算が決まるため未来投資会議は重要
  • スマート公共サービス

    • GovTech
    • 公民の連携
    • データのオープン化
    • API連携の整備
    • LGWAN問題
      • 10年前は省庁のインターネットが遮断されていたらしい
    • 会津若松, 益田市, 加古川市などの官民連携事例
      • 行政の外にDBがあって公民連携
      • 同意した利用者のデータを集めている(オプトイン)
      • このデータをベースにサービスを作っている
      • 官民連携すればよい行政サービスが作れるのではないか?
    • 自治体向けアプリマーケットの事例
      • アプリの開発者と利用者の密なコミュニケーションを実現するため自治体向けアプリマーケットというものを作った
      • 残念ながらオープンデータを作るのは自治体だけど、活用するのは民間にお任せという考えを持っている人もいる
  • 失敗を通して組織の垣根を超えて学んでいくことが重要

経産省DXの取り組み

  • 経済産業省情報プロジェクト室 室長補佐 吉田 泰己 さんによる発表
  • 行政サービスと民間サービスの質の差が見過ごせなくなってきた
  • デジタルトランスフォーメーションという取り組みを行なっている
  • 解決したい問題
    • 国民、事業者にとって不便なサービス
    • 職員の業務効率が非効率
  • ユーザ中心のサービス作り
  • 優れたUI/UXからデータが集まるという認識
  • ビズリーチを使いながら民間から人材を集めてデジタル化を進めている
  • アジャイル支援を行っているベンダーと一緒にものを作っている
  • tableauを使ってデータ分析をしている
  • 認証やデータの連携基盤を標準化し、サービス間で利用できるようにする
  • 目指すこと
    • UI/UXの整備
    • データ分析基盤の整備
    • 行政サービスを民間と同じ水準に

制度ナビPJ紹介&デモンストレーション

  • 経済産業省中小企業庁 松原 匠 さんによる発表
  • なぜ制度ナビを作ったか
    • 職員でも適切な情報を探せる気がしなかったから笑
    • 電話帳みたいなガイドブック
    • ミラサポという既存のwebサービス
      • 施策マップがユーザの要求を満たす機能ではなかった
      • ユーザ目線になっていない
  • 制度ナビ
    • メール通知ではなくプッシュ通知
    • 補助金の人気はある程度固まっている
    • 検索結果の表示(ページング)
  • 導入したアジャイルプロセス
  • 3つの制度の問題
    • 定義の違い
      • 制度や法律によって定期が異なる
      • 定義があいまい
      • 説明を読んでも補助金の対象化わからない
    • 補助金リテラシー問題
      • 補助金交付要項分厚過ぎる
      • ルールが複雑
      • 毎年変わる
    • アプリの実証に使えるデータがない
      • データのフォーマットがなく組織ごとに独自フォーマット
      • 委託していて役所がデータを持っていないケースも
  • どうやって改善してくか
    • 行政の担当者の意識改善
    • 利用者から不便を訴えていく
      • 行政はなるべく手間をかけずにサービスを作っている

民間から見た行政のサービス開発

  • ギルドワークス株式会社 代表取締役 市谷 聡啓 さんによる発表

    www.slideshare.net

  • 今回のプロジェクトでは以下の3つの役割で動いた

    • マネジメント, PO支援, スクラムマスター
    • ここからすでに怪しげな雰囲気が感じられる笑
  • 発表のテーマは「現実対越境」
    • 案件はミラサポのリニューアル
    • 行政側がアジャイル開発をしたいということで今回支援にはいった
    • アジャイル開発への暗黙的な期待が感じられた
      • スプリントの空振り
      • 最終スプリントで浮き上がるこれじゃない感
    • まずアジャイル開発をなぜするのか、目指す状態を理解
    • その上で本当に期待と現実があっているのか?を考えた 「提案してー」でもなく「やってきてー」でもなく「自分たちで(も)やる」
    • 大きな問題
      • プロダクトの「全体感欠如」
        • 今回のミラサポ案件はアプリが3つにわかれている
        • ユーザの体験が3つのアプリに分断されてしまう
        • ユーザの統一的なUX設計ができない状態
      • データの境界は「組織の境界」
        • データが組織ごとにバラバラで管理されていたり、そもそもデータがない場合があった
        • データを揃えるのはスケジュール的に到底不可能
    • 現状維持の文化, 流れに立ち向かうには関係者全員が探索的にならないといけない
    • 上であげた2つの大きな問題を解決するのは体制と時間的に困難
    • 自分たちだけでできないのであればユーザを巻き込む
    • 3アプリ合同でユーザテスト実施
  • アジャイルのやり方を学ぶのではなく、なぜやるのかを考えることが大事
  • 「正しいものを正しく作る」という本を出します

民間による行政サービスのアジャイル開発

  • 株式会社グラファー 代表取締役 石井 大地 さんによる発表
  • 民間企業が行政サービスを開発する話
  • Graffer
    • 面倒な行政手続きをシンプルなUI/UXで提供するサービスを提供する企業
      • 46000種類の行政の手続き
    • Grafferは紙, API, スクレイピングで行政と連携
    • サービスは3.5人(0.5は代表の石井さん分)で開発
    • コンセプトを深く議論して〜というサービス開発ではなく、まず作ってみる。作った上で改善を加えていく。というやり方を取っている。
  • 技術力ではなく組織の文化が重要
  • アジャイルプロセスを取り入れたからといってうまくいくわけではない

パネルトーク①「行政は使いやすいデジタルサービスを作れるのか?」

  • 関さん, 松原さん, 林 大輔さん(経済産業省デジタル化推進マネージャ), 市谷さん, 平本 健二さん(内閣官房政府CIO上席補佐官/経済産業省CIO補佐官) によるパネルトーク
  • sli.doの質問に答えるタイム
    • 行政でコラボレーションツールはつかっている?
      • 部署によるがSlackやBackLogを使っているところもある
    • 組織を動かす, 説得するコツは?
      • 利用者視点と対案を用意する
      • 関係者としてプロジェクトに巻き込む
      • 当事者意識を芽生えさせる
      • ワークショップを開く
      • 手を動かす、頭を動かす機会を作る
    • アジャイルの納品っていつ?
      • 納品する側とされる側で優先度をすり合わせて決める
      • トレードオフスライダーを使った
    • 請負契約ではなく準委任契約でやったのか?
      • 準委任契約でやった
      • 準委任契約だが、準委任契約をそのままやるとうまくいかないので請負契約的なことをやった?
    • チャレンジングな取り組みを他に行なっているのか?
  • 行政は使いやすいデジタルサービスを作れるのか?
    • アジャイル開発を取り入れて開発のプロセスは改善できた
    • UXの改善はまだあまりできていないので今後重要なテーマ
    • アナログなプロセスを改善するシステムを目指して、そこからデジタルなものづくりを目指す
    • ユーザの立ち位置に立ってものづくりを考える
    • 行政の中でPdMが不足していることは深刻な問題
      • 人を管理するProjectManagerはいるが、サービスを管理するProductManagerがいない
      • ユーザ視点に立ってものづくりを考える役割を増やしていく
  • トライアルでアジャイル開発をやってきたが今後どのようなプロセスでミラサポを作っていくか?
    • まずはデータの整備
    • PdMを引き継いで部署横断で進めていく
  • 今後行政としてどうやってサービスを作っていくか?
    • 今までは大手ベンダーと連携をとっていくことが多かった
    • 今回新しい取り組みをしている企業と連携を取って新しいことをした
    • これをさらに大人数でやっていきたい

パネルトーク②「民間事業者と考える行政サービスの未来」

  • 吉田さん, 平本さん, 石井さん, 木村 康宏さん(freee株式会社 執行役員)によるパネルトーク
  • こういうAPIがあるといいなというのはある?
    • WebブラウザでできることはAPIで全部できるようにしてほしい
    • 行政プロジェクトにアサインしてエンジニアから不満が出ないような環境を用意してほしい
  • APIをどうやって作っていいのかわからない
    • APIを作ってください、というの要求になってしまっているのが現状
    • APIを作るためのレビュー環境を整えることが重要
    • アメリカではGitHubで仕様書を管理
  • 既存の窓口はユーザインターフェースとしてもっと重要視していいと思うが、現場との距離感はどう取り組んでるか?
    • 現状使われているところでもっと簡単に使えるようにするということが大事
      • データフォーマットの整備
      • 豊富なAPIの提供
    • ただ、行政としても最低限の窓口は持つ必要がある
    • メモ: 国としてはプラットフォームとして民間にデータを提供することに注力していきたいということなんだろうか?
  • 行政の評価の仕組みはどうなっているのか?
    • 行政内外でどれだけコストを減らせたのか(KPI)
    • サービスの利用率(KPI)
    • 正しい失敗を許容して評価していかないといけない
    • そのためには国民も正しい失敗を許容することを理解しないといけない
    • KPIを達成すれば適切な報酬が与えられるためには、公務員も人事制度改革をしていかないといけない
  • アジャイル開発を行う場合の契約どうしたらいい?
    • アジャイル開発用の契約書の雛形みたいなものがあればよい
    • 別の省庁で雛形について議論する機会があった
    • 経産省の今回のプロジェクトが支援をしていく必要がある
  • 行政サービスの未来を考える上で行政側に期待することは?
    • 失敗談を赤裸々に外部に公開してほしい
    • 届きにくい部署に、失敗してもいい文化がある、ということを届かせることが大事
  • サービス利用の契約をしやすくしてほしい