2014年11月17日月曜日

浪江町と政府のシステム調達について

以前、「"費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた」というブログ記事を書いた時に、政府のシステム調達案件の問題について考えさせられたわけですが、政府の調達案件の問題は世界中で起こっているようで。

調査によると、「アメリカの連邦政府による大規模システム調達案件の失敗率は過去10年間に渡り 94% にものぼり、半数以上が納期遅延、予算オーバーもしくは期待された機能を下回っており、41.4% が完全な失敗に終わっている」そうな。その最たるものが日本でも報道されていたオバマケアこと Healthcare.gov なわけですが、いずれにせよ最近は「政府のシステム調達のあり方自体が機能してない」という話はあちこちで叫ばれており、昨今はそれを直すために非常に様々な試みが行われています。

"94% of large federal information technology projects over the past 10 years were unsuccessful — more than half were delayed, over budget, or didn’t meet user expectations, and 41.4% failed completely"

記事の原文はこちら: Why the Government Never Gets Tech Right

ちなみに Healthcare.gov については Google で SRE をやっていた Mikey Dickerson はじめ何人かの Google 社員が呼び出されて直しに行っているのですが、そのめちゃくちゃな状況を知りたい人は Mikey があちこちで講演をしているので、その動画を見るとよいかと思います。一例はこちら:



ちなみにアメリカでは、この状況では全くお話にならないので、Mikey が Google を辞めてホワイトハウスに転職し、U.S. Digital Service を立ち上げ、シリコンバレーから Google 社員をはじめ、たくさんのテクノロジストを引っこ抜き、Healthcare.gov のようなことが今後起きないよう、各省庁できちんとシステム調達・開発が行われるようにビシバシ直しに行きました。Googler だった Megan Smith もホワイトハウスに引き抜かれ、アメリカ合衆国の CTO に任命されました。というわけで、これからホワイトハウスの中で色々な改革が起きると信じたいです。時間はかかるでしょうが。

さて、政府のシステム調達の問題は色々なレイヤーで起きているので「これが理由です」と一つ指摘したら全て解決するような問題ではありませんが、2013 年の Code for America Summit で色々語られているのでちょっとご紹介しておくと、Clay Johnson は「政府調達の根本的な問題は "fear-based procurement” にある」と説きます。



"Fear-based procurement" についてはその後もたくさんの人が取り上げていますが、簡単にいうと、失敗しまいと恐れるあまり、リスクを取らない、新しいことをやらない、いつもの調達方法、いつものベンダー、いつものやり方で調達を行おうとする。テクノロジー業界はどんどん進んでいるのに、従来通りのやり方を踏襲しようとするので、古臭いシステムしか出てこない。昔ながらの入札システムは既存の政府調達ベンダーに有利にできていて、新しいベンチャーには応札が難しい。イノベーションを起こせるようなスタートアップは最初から入札に参加するのを諦め、結果として政府はイノベーションを享受できず、どんどん時代遅れになっていく。まあ古臭くても動けばいいけど、上述の通り fear-based procurement のままだと結局 94% が失敗しているのが現状。結局、リスクを取って調達の方法をデザインから変えていかないといけない。そういう時代になっている。。。というのが簡単なまとめ。

で、たくさんの試みの中で私のお気に入りは当時フィラデルフィアの Chief Data Officer だった Mark Headd が行った、GitHub を使った政府調達。

こちらの 2013 年の Code for America の動画からどうぞ: "Redesigning Government"



Mark が GitHub を使った政府調達を行った理由を要約すると:
1) 彼らはオープンソース・ソフトウェアやコラボレーションによるソフトウェア開発を尊重しており、そうした価値観を共有できる会社と仕事をしたいと考えていた。そうした価値観を持っているテクノロジスト達が使っているプラットフォームは、といえばやはり GitHub であり、GitHub を調達のプラットフォームとすることで、価値観を共有できる会社を見つけることができると考えた。
2) 応札してきた企業の GitHub レポジトリを見れば、過去のプロジェクトでどんなソリューションを提供してきたのかやどんなプロジェクトにどれだけアクティブに参加しているのかを見て、事前にそのクオリティについて予見することができる。
3) チームはクリエイティブな提案、既存ベンダーによる市の調達案件では見たこともないような新しい提案を求めていた。

ちなみにこの調達案件は myPhillyRising というプロジェクトで、RFP (Request for Proposal) は GitHub Gist にアップされています。

https://gist.github.com/PhillyCDO/4666456

この Gist は誰でも見ることができ、公開コメントを使って誰でも質問をすることができ、すべての回答を誰でも見ることができます。ベンダーが応札したいと思った場合は GitHub のレポジトリを作り、提案はそこにアップすることになっています。また、Mark とチームは GitHub issues をベンダー評価にも使用。送られてきた提案をタグ付けして、チーム内で評価プロセスに沿ってバグをファイルし、メンバーにアサインすることでベンダーの評価を進めていました。

リポジトリに pdf ファイルをアップしただけの会社もあれば、コードを書いてアップしてきた会社もあり、そのコードは市役所側がインストールしてテストをしてみることができました。別のベンダーはユーザーのストーリーを集めて作ったウェブサイトをアップしてきました。

「調達プロセスの設計自体」を変更することにより、今までの入札では見られなかったクリエイティブな会社、共通の価値観をもった会社が参加してくるようになったのです。

このプロジェクトに興味がある方は Mark Headd 自身が書いた記事をどうぞ:
Experiments in GitHub Based Procurement

これは事例の一つに過ぎず、他にもたくさんの事例が出てきています。
How Barcelona and Philadelphia Are Turning Procurement Upside Down

市役所の調達案件の結果は、往々にして市民の生活や利便性に直結します。上記記事では、こうして市役所が、市についての調達の RFP を公開し、一般市民が見られるようにしたことで、「日曜の朝に RFP を読みながら朝食をとりつつ自分の市について考えてる」とツイートした女性の例を挙げ、「調達が政府が扱うひどい物から、市民が参加できる物に変わっていった」と紹介しています。


また、市役所はシステムについて詳しいわけではないので、求めるソリューションを事細かに指定するのではなく、解決したいと考えている問題を明らかにすることで入札者がクリエイティブな提案を行うことができる、「調達に対する考え方を、ソリューションを買うのではなく、問題を解決する、と捉えることで、様々なイノベーションが出てくる可能性が広がる」と書かれています。

さて、本題。

福島の浪江町については今までも何度かブログ記事を書いていますがおさらいしておくと、 福島第一原発の非常に近くに位置している町で、人口は 2 万人強で約 1 万世帯。放射能の影響で市民全員がいまだに避難生活を余儀なくされています。タイムリーに市民に情報を伝えたり、市民同士がコミュニケーションを図るにはインターネットの利用は不可欠と判断し、全世帯にタブレットを配ることを決定。プロジェクトに必要な費用 2.9 億円は復興庁の予算から出ています。ただし、高齢化が進んでいるため市民の 37% 以上が 60 歳を超えており、テクノロジーに詳しくない人でも簡単に使えるようなアプリを提供することが必要です。

そこで今回、Code for Namie チームとタッグを組み、新しいやり方で調達を始めたのですが、あまり日本でも知られていないようなので、ブログにまとめておくことにしました。

まず、こちらのサイトが市民の皆さん向けに公開されており、このタブレット配布事業はどういうプロジェクトなのか、どういうプロセスで調達を行うのかが明らかにされています。

http://www.town.namie.fukushima.jp/soshiki/2/201405tablet.html

1) 「アイデアソン」を 6 回開催 町民の皆さんや技術者(エンジニア・デザイナー)の方々が話し合い、使いやすく便利なタブレットにするための機能のアイデアを出していただくイベントです。 
2) アイデアの整理と選択 アイデアソンで集まったアイデアを事務局で整理し、「ハッカソン」(アプリ開発イベント)のテーマとなるものを選択します。
3) 「ハッカソン」の開催 選択したテーマに基づいて、技術者の皆さんがアプリの試作品を作る2日間のイベントです。ここで作られた多数の試作アプリを、町民の皆さんに評価していただきます。 
4) 仕様書の作成・事業者の選定 評価結果を参考にして町が仕様書を作成し、アプリ開発および配布・運用を担当する事業者の公募・入札を行います。 
5) 申込み受付開始およびタブレット端末操作体験会 全世帯に申込書をお送りし、あわせてテスト機の操作体験会を開催します。また、モニター世帯でテスト機をお使いいただきます。 
6) 配布開始、説明会実施(平成27年1月頃) 体験会やモニター調査の結果をふまえて調整し、完成機を配布します。

アイディアソンの写真:



全ての RFP と質疑応答の内容はこちらで見ることができます。

http://www.town.namie.fukushima.jp/soshiki/1/20140801-proposal.html
http://www.town.namie.fukushima.jp/soshiki/1/8133.html

こちらが仕様書。

http://www.town.namie.fukushima.jp/uploaded/attachment/2870.pdf

提案すべき機能は以下のとおり:

1) ローカルニュース配信関連機能(必須)
2) 放射線量情報配信機能(必須)
3) 行政情報配信機能(必須)
4) 世帯間 SNS 機能(必須)
5) 利用率向上に資する機能(必須)
6) 待ち受けスライドショー機能(必須)
7) 町民間情報共有機能(選択)
8) 浪江町アーカイブ(選択)

これらの機能は、市民の声を元に決められました。下記は市民参加型のアイディアソンで作られた「アイディアスケッチ」ですが、仕様書を見ると、それらが仕様書の中に直接含まれていることがわかります。






また、現在避難中の市民の皆さんのユーザー像分析を元にした「ペルソナ」もRFPには含まれており、入札するベンダーがユーザーがタブレットを使用するシナリオを想像しやすいような作りになっています。

http://www.town.namie.fukushima.jp/uploaded/attachment/2873.pdf





入札に参加したのは 6 社で、全ての提案を誰でも見ることができます。 提案時のプレゼンテーションファイルやプレゼンの動画も町のサイトにアップされており、評価のスコアも、評価のコメント内容も全て見ることができます。非常に透明性高く行われていることがわかるかと思います。

http://www.town.namie.fukushima.jp/soshiki/1/8028.html




動画を見てみると、全ての会社のプレゼンの前に「浪江町の市民の方々も参加されているので、誰にでもわかりやすく説明してください」と念押しされています。ベンダーの一社が質疑応答で「今回は KPI によって指標に対しての提示がございましたが、定量的な数字に対しては社内でも検討したのですが、出ておりませんでした。開始直後にマーケティングデータ、定量的な数字でしっかり答えていくようにしたいと考えております。」と回答したのに対し、「今頂いた言葉が全部わからないんですけど」とバシリ。

また、質問者の一人がほぼ全てのベンダーに同じ質問を投げかけており、「浪江町の 60 歳以上の人口の割合を知っていますか?」「県外に避難している市民の割合を知っていますか?」と非常に基礎的な事実を押さえているのかを聞いています。ちなみにこれらの質問の回答は RFP の最初の方に全部明記されているので、RFP をちゃんと読んでいればわかることなのですが、意外と答えられないベンダーさんもいるんだなと思いました。

契約を勝ち取ったのは富士通さんで、こちらが提案スライドと動画です。

スライド:



http://www.town.namie.fukushima.jp/uploaded/life/8028_24220_misc.pdf

動画:



こちらが全てのベンダーの評価が掲載された採点結果表の要約版。

http://www.town.namie.fukushima.jp/uploaded/life/8028_24299_misc.pdf



こちらが詳細版。

http://www.town.namie.fukushima.jp/uploaded/life/8028_24201_misc.pdf

一目見てあれっと思うのが「なんで NTT ドコモがこんなに低いの?」ということだと思います。NTT ドコモは被災地でこうした案件を既に手がけているはずで、タブレットアプリ開発のノウハウもあるはず。動画を見てみると、どうやら彼らは似たような機能を提供できる ASP サービスを既に開発しており、福島県内の他の町で既に導入済。それを浪江町向けにカスタマイズして提供するという提案を行っていました。直感的には非常に正しい判断です。全ての町で一からアプリを作っていてはきりがないので、良い物をひとつ作って水平展開し、個別対応が必要な機能についてはカスタマイズする方が効率がよいに決まってます。NTT ドコモが残念ながら理解していなかったのは、このプロジェクトは市民参加型で、市民を巻き込みながら、市民と一緒にプロトタイプを作り、テストし、フィードバックを得て、改善し、更にフィードバックを得て改善を重ねていくというプロセス自体を重視していたということ。「役所がシステムを作って市民に与える」のではなく、「一緒に作る」ことに意味があったのです。(実施要項にも、「本事業は、徹底的に町民目線・町民協働での開発を行う事により、町民に必要とされるサービスを提供する。具体的には、ユーザーインタビューやユーザーの実地検証を取り入れ、町民の要望を機能として積極的に取り込んで開発するプロセスを盛り込んでいる。このようなプロセスで事業を推進するためには、民間事業者による創意工夫を生かしたサービスの提案と、住民要望に応じた柔軟な対応を実施できる民間事業者の体制が不可欠であると考えている。」という記述があります。)

また、浪江の皆さんはドコモのシステムが既に導入されている他の町での評判も調べており、稼働率が低いことにも質疑応答で言及。既存のASPを使っているにもかかわらずイニシャルコスト・ランニングコストが高額なこともあって、こうした評価になってしまったようです。

なお、今回のプロジェクトではほぼ全ての調達ステップでオープンで市民参加型の方法が取られています。すなわち:

1) 市民参加型で RFP を作成。市民は「何を求めているか」のアイディアを提供。
2) 市民がハッカソンに参加し、開発者が作ったプロトタイプにフィードバックを提供。
3) 市民がベンダーのプレゼンおよび質疑応答に参加。
4) 市民がモニターとしてアプリを試用したり体験イベントに参加することにより、全体への配布の前にフィードバックを行い、改善に貢献。

フィラデルフィアのように GitHub を使ったりしていないし、ドキュメントは全て pdf だったりするけど、そんな些細なことはどうでもよくて、この小さくて、高齢化が進み、福島原発の被害が著しい町で、システム開発の経験もそれほどない中、こうしてオープンなプロセスで、市民参加型で浪江の未来にとって必要不可欠な役に立つ物を作っているのが素晴らしい。ベンダー選定が決まり、開発はこれからが本番です。浪江町の皆さん、頑張ってください!!

英語ブログはこちら:

"How Open and Inclusive Can Government Procurement Be? - Example from Fukushima" http://fumiopen.blogspot.com/2014/11/how-open-can-open-procurement-be.html

Disclaimer このブログは山崎富美の個人的なものです。ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には一切の関係はありません。