関さんが以前「デジタル庁が立ち上がる今だからこそ、UK GDSの失速について語ろう」という非常によい記事を書いておられましたが、いい機会なので別の角度から：アメリカのUSDSが立ち上がった時のリクルーティングについて、語っておきます。
デジタル庁とは
日本政府が公開した「デジタル社会の実現に向けた改革の基本方針（案）」によると、デジタル庁は、「デジタル社会の形成に関する司令塔として、強力な総合調整機能（勧告権等）を有する組織とし、基本方針を策定するなどの企画立案や、国、地方公共団体、準公共部門等の情報システムの統括・監理を行うととともに、重要なシステムについては自ら整備し、行政サービスを抜本的に向上させる」とのこと。素晴らしい。
背景として、『今般の新型コロナウイルス感染症対応において、マイナンバーシステムをはじめ行政の情報システムが国民が安心して簡単に利用する視点で十分に構築されていなかったことや、国・地方公共団体を通じて情報システムや業務プロセスがバラバラで、地域・組織間で横断的なデータの活用が十分にできないことなど、様々な課題が明らかになった。こうした行政のデジタル化の遅れに対する迅速な対処や、データの蓄積・共有・分析に基づく不断の行政サービスの質の向上こそが行政のデジタル化の真の目的である。また、行政のみならず、国民による社会経済活動全般のデジタル化を推進することは、日本が抱えてきた多くの課題の解決、そして今後の経済成長にも資する。単なる新技術の導入ではなく、制度や政策、組織の在り方等をそれに合わせて変革していく、言わば社会全体のデジタル・トランスフォーメーションが「新たな日常」の原動力となる。』
ビジョンとしてはデジタルの活用により、一人ひとりのニーズに合ったサービスを選ぶことができ、多様な幸せが実現できる社会』を掲げ、『誰一人取り残さない、人に優しいデジタル化』を進める、と。
基本原則は① オープン・透明② 公平・倫理③ 安全・安心④ 継続・安定・強靱⑤ 社会課題の解決⑥ 迅速・柔軟⑦ 包摂・多様性⑧ 浸透⑨ 新たな価値の創造⑩ 飛躍・国際貢献とのことで、説明は上記リンクから原文をお読みください。
デジタル庁の業務としては、①国の情報システム②地方共通のデジタル基盤③マイナンバー④民間のデジタル化支援・準公共部門のデジタル化支援⑤データ利活用⑥サイバーセキュリティの実現⑦デジタル人材の確保。
これで日本がアップグレードされるといいですね！期待しております！
1月に人材募集がかけられて、応募期間も終わったのでコアメンバーが決まっていくところですかね。いい人材が集まるといいですね。結局人ですから。30人の募集に1432人の応募があって、最終的には民間人100人の500人態勢で発足させる予定のようです。
デジタル庁(仮称)の創設に向けて人材募集中。（1月22日に受付終了）
ただ、これを見てて、一つ心配なのは、普通の民間のIT企業と違ってデジタル庁の側で必要なPMとかエンジニアとかが、普通に政府として「人材募集！」と言って来るのかなというところなのです。何も特殊な人材が必要なわけではない。というか、多分これから必要になるのは、まっとうなテクノロジー会社でまっとうな開発をやってきた人たちなのではないかと思うのです。彼らがいきなりデジタル庁の立ち上げを自分ごとに考えて、応募しに来てくれるのかが、ちょっと心配。
Mikey Dickersonの例
アメリカのデジタル庁にあたる USDS を作ったMikey Dickersonの話をしましょう。
日本には国民皆保険という素晴らしい制度があるので、病気になっても怪我をしても、病院に行って保険証を差し出せばどの病院にも行けて医療費もたったの3割負担すればよいという仕組みになっています。
長年、アメリカにはこれがありませんでした。もちろん民間の保険はありますが、低所得者層にとっては保険料自体が高すぎて入れなかったり、持病がある人は医療費がかさむので保険の更新を拒否されたりして、保険に入れない人たちがいました。保険がない状態で治療を受けて高額の医療費を請求されたり、あるいは医療費がないのでお医者さんにかかることができず、病状が悪化しても治せなかったり、場合によっては死に至る。。。というホラーストーリーがかなり聞かれていました。どのくらい高額かというと、日本人の方が盲腸で手術して、術後に腹膜炎を併発して8日間の入院になって7万ドル（約700万円）、腕の骨折で入院治療（1日間）で1万5000ドル（約150万円）請求された、などなど。
これは問題だということでオバマ大統領が成立させたのがPatient Protection and Affordable Care Act、通称オバマケアでした。保険にかかることができない人々5000万人を救ったオバマケア。。。と言えば聞こえはいいのですが、このサービスのスタートは前代未聞の壊滅的な失敗でした。
2013年10月1日にオバマケアへの登録用にローンチした healthcare.gov のサイトはいきなりダウンして使い物にならない。初日に保険に入れたのは何と6人だけというていたらく。
その年の10月中旬、Mikey DickersonはGoogleでエンジニアリングマネージャとして働いており、healthcare.gov のトラブルについてはテレビで報道を見るぐらいの、完全に他人ごとでした。友達とご飯を食べていたら「healthcare.govが大変みたいだから、ちょっとアドバイスとか電話かけて聞いたりするコンサルタントのリストに君を載せてもいいかな。君、Googleでサイトをスケールさせた経験があるからさ」GoogleでSite reliability engineerをやっていたMikeyは「いいよいいよー」と答えておいた。数日後、知らない人に電話をかけさせられる。相手はTodd Park、当時のアメリカのCTOでした。「報道されている通り、healthcare.govのサイトがトラブっているのでちょっと助けてくれないかな。3日ぐらい！」飛行機のチケットを買ってワシントンに赴いたのが10月22日、この数週間サイトはほぼずっと落ち続けていた。
何が問題だったのか。当時の様子をMikeyは赤裸々にあちこちで語っています。例えば2014年夏のVelocityでの講演動画が下記。
Healthcare.govのサイトは、MikeyがワシントンDCに到着した時にはそもそもモニタリング自体がされていなかった。ダッシュボードもない。このサイトを作るのに採用されていた企業は55社いたけれど、「サイトが動いており、ユーザーが使える状態にする」という責任を課せられた会社が一社もなかった。「残り54社を統括する」という責任を課せられた会社も一社もなかった。さまざまな問題が起きる中、ネットワークの問題なのか、OSの問題なのか、アプリケーションレイヤの問題なのか、問題の切り分けがされておらず、一体どこで問題が起きているのかわからない。そしてモニタリングもない。サイトが落ちまくっているのにどの会社もそれが自分の問題であるという切迫感がない。
あまりに色々なことが間違っているので、とにかくやれることから一つ一つ直していくしかない。再度Todd Parkが登場し、「3日のお願いだったけど、君が指摘してくれた問題を解決するまで、あと数週間助けてくれないかな。」約束の3日が3週間に、3ヶ月になり、自宅に帰れたのは1月になってから。平日も土日も休みも一日も取らずに働き続き、平均労働時間は17.5時間。直して、直して、直しまくった。直した内容は、特殊なことではなく、技術的に高度なことでもなく、全てテクノロジー業界的にはあたりまえのことだったと話す。
まずは最初の数日でモニタリングを導入。War roomを作った。一日2回のオペレーションミーティングを始め、各社から100人以上が参加するこのミーティングでは何が起きているのか、何が問題なのかを一個一個、解明していく。
なぜこのマシンが稼働していないのか。「あっちの会社がファイヤーウォールをインストールしなかったから」なんでファイヤーウォールがインストールされていないんだ。「そっちの役人が承認してくれなかったから」なんで承認しなかったんだ。「チケットが来てなかったから」なんでチケット切ってないんだ。「チケットを切るのを担当している別の会社が切ったよ」。。。結論としては、申請する側と承認する側が別のチケットシステムを使っていた。（。。。／(^o^)＼。。。しかしこうやって一個一個解明していかないとわからなかったのかー）万事が万事この調子、ということでこのミーティングを100日間行い、問題を一個一個解決していった。12月1日にはなんとかサイトが動くようになっており、Mikeyがやっているようなオペレーションの仕事をやる人を19人増やし、Mikeyは1月6日にやっと自宅に帰れたというわけだ。オバマケアへの登録は810万人にのぼった。エンジニアとしては普通のことをひたすらやっただけ。特殊なことや高度に技術的なことは何もやっていない。だけど、救ったのは810万人の安全と健康と（場合によっては）命。
Googleに戻って平穏な毎日に戻ったが、これはHealthcare.govだけの問題じゃないんだよなという気がふつふつと沸き起こる。アメリカ政府はITに年間約840億ドル(約8.4兆円)を使っていて、有名な話として、2003年から2012年の間、これらの政府のITプロジェクトのうち94%が失敗に終わっている。（失敗の定義は予算オーバーだったり、納期遅れだったり、納品がされなかったりと様々）。
2014年8月、MikeyはGoogleを退職し、USDSを設立して率いることに。もちろんMikeyがいきなり行って立ち上げたわけではなく、Code for Americaを立ち上げたJennifer Pahlkaが2013年の6月から2014年の6月までの一年間でアメリカの副CTOとしてUSDSの立ち上げ準備を進めていた。そこにリーダーとしてぴったりなMikeyがやってきた、というわけだ。JenがUSDSを立ち上げようとしたきっかけはイギリスのMike Bracken率いるGDSの成功で、そこの成功と失敗から学べることが非常に多くあるということは、関さんが書いておられる通り。GDSをモデルにUSDS設立準備をしていたらhealthcare.govが大コケして、それをガツガツ直したMikeyをGoogleから呼び戻してUSDSのadministratorとしてトップに立ってもらったのでした。
USDSを立ち上げたら、たくさんの省庁から相談が舞い込んでくる。「養護施設の子供の個人情報が流出しやすく、個人情報詐欺にあいやすい」「貧困層の食糧費補助が止まってしまう」「移民のプロセスに謎の費用がかかっている」「退役軍人の問題」。オバマケア以外にも様々な問題がUSDSにはやってきて、対応する人が全然足りない。「皆さんの住むこの国の、本当に大事な問題に取り組んでるんです。皆さんも3日だけ、問題のアセスメントをするのを手伝ってくれませんか？」
実はこの頃、MikeyとUSDSのスタッフたちはこうやってテクノロジー系のカンファレンスでの講演を通じたリクルーティング活動はもちろん、シリコンバレーの会社を一社一社行脚して、healthcare.govの話をし、USDSの話をし、現在アメリカの様々な省庁が抱える様々な問題の話をし、そこで活動することの意義、人を救える、人の命を救える、そんな数々のプロジェクトを紹介し、「USDSに来て手伝ってくれ」というリクルーティング活動を丁寧に絶賛行っていました。私は当時マウンテンビューのGoogleで働いていたので、Googleにも来ていて、話を聞いたら、「今日はひたすらシリコンバレーでリクルーティング。午前はxx社、今Googleでこの後yy社で同様に講演するわ」と話してました。
その後のUSDS
USDS設立から1年経った2015年の夏にMikeyがOSCONで講演する頃には、2年目を迎えたオバマケアは安定して運用されていたため、話題にもならなくなっていました。この、「話題にならないけど様々なシステムを改善している」というのがUSDSの成功のポイントな気がします。ひっそりと愚直に結果を出し続けている。1年で移民関連のシステムも修復し、グリーンカードの発行は紙ベースで数ヶ月かかるプロセスだったのがオンラインに。recreation.govのオーバーホールに伴い、APIとオープンアクセスを含んで他の人達が再利用できるようにする内容のRFPを書くのを手伝い、運輸省の車のリコールを受け付けるサイトが大量のアクセス負荷に耐えうるようにし、エボラ出血熱の対応などに取り組んできた。アメリカ政府の技術やウェブサイトのトラブルがあるたびに駆けつけてきました。
2016年の成果レポート：2016 Report to Congress
中でもプライオリティの高いプロジェクトについてはここにまとめている。
2017年の1月、Mikey DickersonはUSDSのadministerを退任し、後任にはGoogleのsearch qualityのエンジニアのMatt Cuttsが就任。
Mikeyの退職ブログ：You’ll Never Be The Same Again
If you have an opinion about the future of our country, if you’re frustrated with the status quo, if you don’t like the future you currently imagine and you want a better one, it’s time to show up.
国の将来について意見があるなら、現状に文句があるなら、こうなるだろうと思われる将来が気に入らなかったら、もっといい将来になってほしいと思っているなら、立ち上がろう。
2017年1月といえば、トランプ氏が大統領に就任したタイミングです。正直、オバマ政権からトランプ政権に変わることで、USDSのスタッフはみんなやめてしまうのではないかと私は危惧していました。当時、MattがGoogleに講演に来てくれた時にQ&Aでそれを質問した人がいたのですが、Mattの回答は「我々が作っている政府のサービスは、国民のために作っているもの。大統領の座に誰がいようと、国民のためのサービスを使いやすくするというミッションは変わらない。」
Matt Cuttsについては、下記TED2019の講演が5分と短くcrispです。ちなみに彼も「3ヶ月の短期」の予定でUSDSに参加したはずが、6ヶ月に延長し、更にはUSDSを率いることになり、もう4年になります。なんでここまで続けてきたかというと、政府は本当にテクノロジストが必要なのだということがわかったから。
左：Googleのオフィスはビデオ会議の環境もカレンダー等のツールも家具も何もかも完璧。
右：政府の新しいオフィスに引っ越した時。家具もなく、床に座って仕事をし、「電話会議」が必要なので電話を引いてもらってゴミ箱の上に設置して電話会議を行った。
色々なプロジェクトをやってきたが、例えば退役軍人がヘルスケアを受けられるかどうかの確認に、USDSが改革を行う前は紙ベースで、4.5ヶ月かかっていた（左）。これをオンラインにすることで10分で確認できるようになった（右）。
小企業庁の作業をオンライン化することでまったく同じオフィスの、全く同じ人の机の上がこれほど変わった。
「国・州・市それぞれの自治体職員とテクノロジストが協力してプロジェクトを進めるのは、めちゃめちゃイライラすることも多いし、難しいし、ぐちゃぐちゃで、それでも本当に重要で素晴らしい体験ができる。一生やる必要はないけれど、「今」テクノロジスト達が必要されてるんだよ。」
USDS Impact Report Spring 2020
2020年のUSDSのプロジェクトにはどんなものがあったのかは上記報告書に「challenge」（何が問題だったのか）、「solution」（どう解決したのか）、「impact」（その結果どんなインパクトを与えたのか）、「update」（その後のアップデート）をテンプレートにわかりやすくまとめられています。
最後の方にはこの5年間のまとめも。
Purposeが大事
ポイントは、映画の世界では”If you build it, he will come.” 「それをつくれば、彼が来る」でデジタル庁を作れば日本中の最高のエンジニアがデジタル庁に集結するよという夢のようなことが起きるかもしれないけれど、現実的には多くのトップエンジニアたちは当時のMikeyみたいに、「大変だなあと思うけど自分には関係ない」と思っている気がするのです。実際に自分達があたりまえに毎日使っている技術スキルを使って、国民の生活に不可欠な様々なサービスがよりよく提供されることに貢献できるという大きな意義は、丁寧に説明して説得しないと自分ごとにならない気がします。給料の額や労働条件で決めるものではなく、どれだけ国民の生活に大きなインパクトを与える仕事なのか、どれだけ難しいことなのか、そういうことを伝える方が重要なのではないかなと思います。
人によってはお金のために働いている人もいるし、社長になりたくて働いている人もいる。そうではなくて、社会にインパクトを与えたくて働いている人や難しい問題があればあるほど燃えて解決しようと頑張る人もいる。GDS、USDSやデジタル庁みたいなところに優秀な人に来てもらうには、やはり政府の、テクノロジーが関わるプロジェクトそれぞれを丁寧に説明し、その意義、purpose、社会に与えるインパクトを理解してもらうのが重要なのではないかと思います。だって、たいていの人は今の仕事に満足しているし、そういう機会があるとは知らないものだから。
Googleで働いていた2014年当時、Civic Bridgeというプロジェクトを立ち上げました。市役所と提携し、その都市の大きな問題に対して、そこに住む Google 社員をボランティアで派遣し、1ヶ月間フルタイム・3ヶ月 20% プロジェクトの合計4 ヶ月をかけて問題に取り組んでもらうというもの。そのうちの一つのプロジェクトは、住宅事情が逼迫するサンフランシスコで市役所が制作している安価な住宅を見つけるためのポータルサイト構築のコンサルティング。Google社内でこのプロジェクトに参加してくれる人をリクルーティングするときには、市役所の人たちに来てもらって現状の問題について赤裸々に語ってもらい、社員たちに「これは助けないと」と思ってもらいました。そしてこのプロジェクトに関わった社員の一人は、終了後に「自分の技術スキルが政府に行くことで人の生活を救うことになるなんて知らなかったよ。僕はUSDSに行く。人生を変えてくれてありがとう。」と言ってGoogleからUSDSに転職していきました。tech企業で働いていると、政府で働くことの意義が見えないこともある。気づいてもらう努力をなるべくしないといけないのだと思います。
ピンチはチャンス
イギリスのGDSが立ち上がったのも、政府のヘルスケア関連のプロジェクトがうまくいかなかったから。アメリカのUSDSが立ち上がったのも、healthcare.govがうまくいかなかったから。政府のITプロジェクトの成否に人の健康や命がかかっているとわかった時、テクノロジスト達（エンジニアでもデザイナーでもPMでも。。。。）は自分の力で役立てるのでは、と立ち上がってくれるのかもしれません。
2011年に東日本大震災が起きた時、 Google Japanの社員たちが誰に指示されることもなく、様々なプロジェクトを立ち上げ、被災者の皆さんのために何かできないか、動き始めました。
Googleだけではありません。Google, Yahoo, Microsoft,リクルート。。。といったテクノロジー会社に勤める社員達がみんなで協力して Hack for Japanをつくり、この国の危機に、テクノロジーを使って現地で役に立つものを作ろうと立ち上がりました。
テクノロジー企業だけではありません。「東日本大震災からの教訓を全てデータから洗い出し、今後また大きな災害が起きた時に備えよう」ということで、Google, Twitter、朝日新聞、JCC、NHK、ホンダ、レスキューナウ、ゼンリンデータコムがデータを提供し、アカデミック・テクノロジスト・ジャーナリスト・防災の専門家など、様々な分野の方と一緒に「東日本大震災ビッグデータワークショップ — Project 311 -」を行いました。
今回の新型コロナも一つのピンチです。そして、「新型コロナウイルス接触確認アプリ（COCOA) がAndroidできちんと通知が動いていなかった」ということも、場合によっては人の健康と命に影響を与えるかもしれない、ピンチです。現実を捉え、何が問題だったのかを冷静に分析し、今後そのようなことが起こらないよう改革ができるとよいなと思っています。大変難しいプロジェクトを進めてきた皆さんへの感謝とリスペクトを保ちつつ、単なる批判ではなく、「誰が悪かったか」という悪い者探しではなく、今後同様の問題を起こさないための、postmortem「何がうまくいったのか」「何がうまくいかなかったのか」「今回の結果を受けて、次はどういう新しいことにトライすべきなのか」という分析が重要かと思います。
逆にやってはいけないのは「お粗末」の一言で片付けてしまうことや、「関係者を処分すればいい」という発想だと思います。それをやっている限り、問題はなくならない。見せしめになってしまって、優秀な人達が萎縮してデジタル庁に来なくなるかもしれない。問題を隠蔽してしまおうという意識が働き、透明性がますますなくなってしまうかもしれない。それよりは、問題がどこにあったのかを明らかにして、それを今後COCOAで解決しつつ、今後他の政府のプロジェクトで同様のトラブルが起きないように、まとめて、共有して、前向きに次に活かすべきだと思います。
どんなプロジェクトでも大なり小なりトラブルは起きるものです。それらのトラブルを受け止め、解決して、前に進まないといけないのではないでしょうか。デジタル庁が立ち上がってからも、きっとトラブルは起こるでしょう。大変なこと、難しいことをやろうとすればするほどトラブルはつきまといます。マスコミもそれを鬼の首を取ったように取り上げるのをやめてあげた方がよいと思います。小さな成功の積み重ねと、トラブルを体験してそれを一つ一つ解決して成功に導いていくことで、デジタル庁という組織が強くなっていくと思うので。デジタル庁で働いてようと働いてなかろうと、国民みんなが暖かく見守り、できることを支援していくべきだと思います。失敗を恐れて、役に立たないけど安全パイなプロジェクトだけやってても、デジタル庁を作った意味はないですしね。勇気をもって、国民生活を変えるインパクトのあるサービスを作るデジタル庁であってほしいと願います。正直、PMでもエンジニアでもデザイナーでもない私は遠くから応援するしかことぐらいしかできないのですが。。。がんばってー(っ`･ω･´)っ
(╭☞•́∀•̀)╭☞ それな！
Digital Services Playbook
ちなみにUSDSは Digital Services Playbookという物を出しています。13か条あります。それぞれに詳細説明とチェックリスト、重要な問いが書いてあるので、ぜひ原文をお読み頂くのがよいかと思います。
- Understand what people need
- Address the whole experience, from start to finish
- Make it simple and intuitive
- Build the service using agile and iterative practices
- Structure budgets and contracts to support delivery
- Assign one leader and hold that person accountable
- Bring in experienced teams
- Choose a modern technology stack
- Deploy in a flexible hosting environment
- Automate testing and deployments
- Manage security and privacy through reusable processes
- Use data to drive decisions
- Default to open
ひとつひとつ見つつ、報道・公開されていることをベースに、COCOAはどうだったのかなあと考えてみてもいいかもしれません。
人々が必要としていることを理解する。
今回のCOCOAの問題として、実は陽性反応が高すぎて陰性の人たちに通知が行き、保健所の人たちの手が回らなくて困らせてしまった。。。などの問題もあったとか。USDSのPlaybookのチェックリストには「実際の人でプロトタイプをテストしよう」という項目があります。ユーザーや様々なステークホルダー含め、現場のニーズの理解が大事ですね。
2. Address the whole experience, from start to finish
サービス体験の全体を最初から最後まで視野に入れる。オンライン・オフライン含め。
3. Make it simple and intuitive
シンプルで直感的にデザインする。
COCOAのアプリデザインを担当された方たちは、インタビューに答えて『多くの人にわかりやすくするには、狭いアプリ画面の中に必要な情報をうまく詰め込む必要があり、ていねいなUX（ユーザーエクスペリエンス、ユーザー体験）デザインが必要になった。デザインはあえて簡素。狙いは｢感情をあまり揺さぶらないこと｣。新型コロナウイルス感染症は｢マイナスの感情｣をともなう場合が多い。そこで感情を揺さぶるようなウェットな部分のあるデザインにすると、利用者に苦しい思いをさせる可能性も高い。だから、あえての｢シンプル路線｣だ。』と語っていました。
4. Build the service using agile and iterative practices
アジャイルなプロセスで開発し、MVPを早く作ってユーザビリティテストを行う。開発に関わる人達が技術情報をミーティング、戦略室、daily standup、チャットなどを使ってコミュニケーションを図る。小さくてフォーカスした開発チームを作り、機能開発・改善をすばやく行い、プライオリティを明記した機能バックログ、バグバックログを作る。ソースコードのバージョン管理システムを使い、プロジェクトチーム全員にissue trackerとバージョン管理システムへのアクセスを付与。コードのクオリティを保つため、コードレビューを行う。
今回、問題の一つはGoogle側のAPIの仕様変更についていけていなかったことでした。このあたりは開発チームの「技術情報についてのコミュニケーション」というところだけれど、気づくのは難しかったのかもしれない。ただ、Google側もまずいと思っていたのか、大きな変更があったときはExposure Notifications APIのドキュメンテーションに赤枠、赤字でわざわざアラートを出したりはしていたようですね。
今回のAndroidで動かないというバグはGitHubで11月に指摘されていた。このあたりは「バージョン管理システムの利用」の問題とも絡みます。COCOAのソースコードはGitHubに公開されていたが、その理由はGitHubに公開しないとライセンス違反になってしまうからだったらしい。で、COCOAの開発にはバージョン管理システムとしてのGitHubとしては機能しておらず、単に「上げただけ」になっていたようです。なので、去年の11月にGitHub上で「Google/Appleの規定した仕様が変わっており、現在の仕様ではトランスミッションリスクレベルの値がiOSだと0–8なところ、Androidだと1–8になっているのに対し、COCOAは0に設定しているので、0の場合はリスクスコアが1になってそれだとAndroid版では接触が検知されることはないという状態になっちゃうよ」という指摘が行われていたが、開発陣はそれに気づかなかったため、4ヶ月間Android版では通知が行かないという状況が続いてしまったらしい。GitHubにコードをアップしたら、その後きちんとGitHubをチェックするということを責任持ってやらないといけないという共通認識と人のアサインが必要ですね。
5. Structure budgets and contracts to support delivery
予算と契約はサービスデリバリーしやすいように作る。これに関するガイドブックも作った。
報道によると「COCOAと新型コロナウイルス感染者等情報把握・管理支援システム「HER-SYS」の運用はパーソル社に委託していて、パーソルとは2020年4月23日からHER-SYSの契約が始まり、そこに追加される形でCOCOAの運用を6月から委託した、と。同社にはHER-SYSとCOCOAあわせて約16億円の委託料を支払っており、約4億円がCOCOA、残りの12億円がHER-SYSに使われる」ということのようです。ドイツで導入された接触確認アプリは、日本と同じくGoogleとAppleが開発したAPIを利用した仕組みで、アプリの開発に2000万ユーロ（約25億円）、さらにその運用には月額3億～4億円が必要とされているそうな。作った後の「保守運用」の必要性の明文化と予算の確保が大事ですね。 COCOAについては情報開示請求をした方がおられたようで、1.9億から2.9億に変わった時の変更契約書とか再委託の変更承認申請書とかが公開されています。なるほど、変更理由が「接触確認アプリケーション開発及び運用の仕様追加に関して、短期的な納期で対応する必要があることから開発体制及びサポート体制を拡充することを目的として、各業務分野のノウハウを有した事業者への再委託が新たに必要になったため」とあって、変更内容に「リリース後のヘルプデスク /運用保守業務」が入って、担当する株式会社エムティーアイの業務履行能力も「スマートフォンアプリの開発運用実績多数」というところまで書いてありました。ただ、仕様側のアップデートの確認やアプリ側のアップデートの確認とQA、テストの機材や体制はどのくらい整っていたのかな。仕様書に基づいて保守をしようとする＞＞アプリの仕様が変わっちゃったyo！＞＞ なぜならGoogle/Appleの方の仕様が変わったから。。。ということは、これからも度々起きるであろうということを見込まないといけないというのが教訓ですね。
6. Assign one leader and hold that person accountable
リーダーを一人アサインし、その一人が全責任を負う。その人は権限と責任をもち、タスクをアサインしたり、ビジネス・プロダクト・テクニカルな3つの視点の意思決定を行い、そのサービスの成功・失敗の責任を負い、機能開発やバグのマネジメントを行う。
民間のプロダクト開発ではプロダクトマネージャが必ずいてそのプロダクトのCEOみたいな感じで責任を負うのと同じ。COCOAはどうもそれがいなかったように思える。2月12日に平井デジタル改革大臣が不具合の原因がアプリのAPI連携にあったとの話をし、デジタル庁が引き取るのかなと思ったら「今後も厚生労働省主導で進めつつIT室が技術的なサポートを行う」とおっしゃっているので、おそらくデジタル庁で責任者を立てることはなく、今後も厚生労働省でやっていくようですね。
経験豊富なチームを作る。プロダクトマネージャやエンジニア、デザイナーなど。また、外部の力が必要な場合は、USDSではサードパーティの開発業者の技術的な技量の評価の仕方を理解している契約関連の政府役人と協力して調達の契約を行う。
調達の時点で技術評価をできる人を入れるというのはいいですね。当初、Code for JapanとCOCOAの2つが開発されていて、一国一アプリという制限が出てきた時に、金額が安かったCOCOAが選ばれたということのようですが、どのくらい技術評価が行われたのかな。報道によると当初COCOAは「HER-SYS」と連携する予定だったため、厚労省はHER-SYSを管理する契約を結んでいたパーソル社にCOCOAの開発運用も委託することにしたが、パーソル社はアプリの運用は経験が少なかったという問題もあったとのこと。まあ、それで上記の「変更契約」で増額してアプリ開発保守が得意な会社を入れたということですね。多分。
ちなみに、Google/Appleの仕様がコロコロ変わってしまうのはCode for Japanでやったとしても同じ難しさはあったと思いますが、少なくともGitHubでの指摘の放置はしなかったんじゃないかなあとは思います。自分たちのオープンソースプロジェクトへのコミットを「対応しなきゃいけない作業が増えた」と考えるか、「貢献してくれる人が増えた！」と喜ぶかという根本的な考え方の違いもあると思います。
8. Choose a modern technology stack
最新のテクノロジースタックを選ぶべし。開発チームが効率的に働き、サービスが費用対効果がよい形で簡単にスケールできるように、技術選択の意思決定を行うべし。ホスティングのインフラ、データベース、ソフトウェア・フレームワーク、プログラミング言語などのテクノロジースタックはベンダーロックインを避け、最新のコンシューマー及びエンタープライズソフトウェア企業が選ぶような技術を選ぶ。特に、オープンソース・クラウドベース・コモディティソリューションを選ぶべき。これらはたくさんのプロジェクトで使われていて、多くの成功している民間企業で使われている。
政府CIO補佐官の楠さんも「接触確認アプリはAzure Functionsを使ったシステムだったので、ぶっちゃけAWSと比べてエンジニアを見つけるのも難しかったはずだ。XamarinもAzureも、Swift、Kotlin、AWSと比べてエンジニアが少ない。ましてやEN APIに精通したエンジニアはほぼおらず担当してから勉強することに」とツイートされていて、EN APIはまあ世界中で誰も精通はしていないのでしょうがないとして、Xamarinを使ってしまったことで開発も保守運用も大変になってしまったという側面は否めないのかな。
あと、そもそも論になるけど楠さんが「GitHubどころかAppleやGoogleのAPIリファレンスも遮断してる役所の情シスも刮目して見るべき」とツイートしているのも気になりますね。日本の政府ネットワークからはGitHubも見れない、AppleやGoogleのAPIリファレンスも見れないというような、スタッフを暗闇に突っ込むようなことは是非やめていただきたい。デジタル庁の皆さん、ぜひ改善を。
9. Deploy in a flexible hosting environment
フレキシブルなホスティング環境を使う。
10.Automate testing and deployments
テストとデプロイの自動化。
うーん、COCOAの場合は自動化どころかテスト自体ができていなかったのが問題ですね。テスト環境の構築・必要に応じてデバイスの提供・手順書などが必要だったのかもしれません。また、個人情報保護の関係か、EN APIには制限がかかっており、アプリの実機デバッグが非常にやりにくい状態になっている、と。それ自体は仕方ないとして、じゃあテストしやすいようにするにはどうするのということはGoogle/Apple側にフィードバック・ディスカッションして解決した方がよい気がしますね。あと、Google/AppleのAPIを使ってアプリを作っているのは何も日本だけではないので、多分各国のエンジニアがこのAPIについて喧々諤々議論しながら日々開発してフィードバックしているエンジニアコミュニティがあると思うんですよね。多分。そういうところにデジタル庁の皆さんも突っ込んでみるのはいかがでしょうか。なかったら日本からそういうのを作って、「日本はこの落とし穴にハマってしまったので、各国のみんなはハマらないように気を付けてね！」と情報共有・注意喚起をするとか。失敗したら共有して同じ失敗をほかのみんながしないようにする、は重要な気がします。Covid-19は何も日本だけが食らっているわけではないので。
11. Manage security and privacy through reusable processes
セキュリティとプライバシーを再利用可能なプロセスでマネジメントする。政府のサービスは特にセンシティブな情報を扱うので、セキュリティとプライバシーへの配慮が重要です。継続的なレビューと改善が必要で、それをサービスの開発と保守の両方のプロセスの中に組み込んでおくことが大事です。サービスや機能の開発に取り掛かる最初から、プライバシー・セキュリティ・リーガルのオフィサーと、どのような情報を収集するのか、どのように保管されるのか、いつまで保管されるのか、どのように使われ、共有されるのかなどを話しあいます。ローンチ後も継続して、プライバシースペシャリストが個人情報がきちんと管理されていることを確認し続けることが必要です。また、安全なサービスを作るためにテクノロジースタックのそれぞれのレイヤーのコンポーネントについて、セキュリティの脆弱性がないか包括的にテストを行って保証し、ほかのサービスにそのコンポーネントが使われるときにはそれが保証済ということで再利用することができるようになります。
12. Use data to drive decisions
データを元に意思決定を行う。
オープンがデフォルト。オープンな場で協力しながらサービスを開発し、データを公開することで、みんなで政府をよりよくすることができるし、政府のサービスや情報が国民からアクセスしやすく・貢献しやすくなるし、起業家・NPO・他省庁・国民が再利用しやすくなります。
GitHubでのオープンソースでの運用については項目4で書いてしまったので割愛します。
長文になりましたが、デジタル庁にはがんばってほしい！(*^_^*)という結論でした。
