【PublicNotes特集】COCOAはなぜ機能しないのか（中編）～開発体制にひそんでいた３つの落とし穴～
【Public Notes】とはミレニアル世代のシンクタンクPublicMeetsInnovationがイノベーターに知ってもらいたいイノベーションとルールメイキングに纏わる情報をお届けする記事です。
前編はこちら。
契約関係から見えてくるCOCOAの課題これでCOCOA契約に至るおおよその全体像が浮かび上がってきました。しかしここでまた次なる疑問が沸いてきます。
果たしてパーソルはCOCOA開発の受託先として適切だったのでしょうか？
うえで述べたとおり、委託先がパーソルに決定した背景には、COCOA開発にとってパーソルが最適なパートナーだったから、というより、時間的制約、技術的制約（HERSYSとの連動）があるなかで、消去法的に選ばざるを得なかったという事情が垣間見えます。パーソル側もどの程度この受託に積極的だったのかは正直分かりません。
実際、うえでご紹介したパーソルにCOCOA開発もお願いするための「再委託変更申請書」（5月27日）の中では、パーソルは再委託の理由を「モバイルアプリ開発のノウハウがあるメンバーのアサインが困難であること」としており、パーソル自体にはモバイルアプリ開発の経験者が（少なくとも十分な人数が）いなかったことがうかがえます。
結果、再委託先である株式会社MTIが「接触確認アプリ開発の一部、リリース後のヘルプデスク／保守運用業務」、日本マイクロソフトが「PMO（プロジェクトマネジメントオフィス、統括的な管理やサポートを行う）や技術支援」、株式会社イーガーディアンが「アプリ利用者向けのサポート業務」、ディザイア―ド株式会社が「初期検収業務の一部、保守開発準備業務の一部」を担うという非常に分断された業務構造となりました。
一方、アプリ開発等の経験者からすると、この構造で短期間に質のいいアプリが作れるのかは非常に疑問だと言います。その理由を３つご紹介しましょう。
（１）設計とコーディングが完全に分離されてしまっており、フィードバックループが作れない
基本的にアプリ開発においては、アプリは作って終わりではなく、企画から設計、コーディング、テスト、評価に至るループを何周もすることによって、バグの改善やよりよい仕様を追求していきます（写真はWEBWONDERSから引用）。
しかし、すでにご覧いただいたように、基本的に委託→再委託の関係はこの矢印が一方通行であり、上から発注があってそれを納入して終わり、という非常に単純な関係性に陥りがちです。
特に今回のCOCOAは、Apple、Googleが提供するAPIが非常に頻繁に変更になったことから、タイムリーかつ迅速なフィードバックループが求められましたが、それをこの複数の再委託先に業務が細分化され、かつ委託先のパーソル自体にもアプリ開発の経験者が不十分だった環境で実現することが可能だったのか、疑問に思わざるをえません。
（２）事前に保守・運用の規模が想定しにくい
もう一点は、より本質的な委託契約の問題点です。
アプリ開発の委託は、大きく分けると①アプリそのもの（ソースコード）の開発と②保守運用業務の２つから構成されます。実際今回のパーソルとの契約書のなかでも、それぞれ以下の通り明記されています。
繰り返しになりますが、行政の委託は、仕様書の作成→公示→入札→契約という流れをたどります。委託を受ける事業者は、仕様書を見て「うちにもできる」「これならやる価値がある」と思って参加してくれるわけです。
しかし、今回のCOCOAの場合では、どれくらいの工数（作業数）が必要になるか、どれくらい頻繁なアップデートが必要かは事前に誰にも分かりませんでした。どんな作業が必要になるか分からない中で、あらゆる事態を想定して事前に十分にスキルを持った人材をアサインしておくことは、委託先からするとなかなか難しいという現状もあります。
この難しさが現れた顕著な例が、2月3日に判明した「COCOA利用者の一部が感染者との接触が通知されない」という事態です。
通知が来る来ないということは、何度かテストで試してみれば分かったことだと多くの方が思うかもしれません。それこそ事業者の「サボり」だったというご意見もありますが、この点について、省庁からの委託を頻繁に受けている某事業者の方に話を聞くと、事業者が実機テストをあえて省略することは考えにくいと言います。
（2021.02.14 PMIインタビュー）
省庁に限らずですが、仕事（受託案件）の成果を評価・信頼されることが、事業者の実績・ノウハウの蓄積となり、その後に類似業務の実績・知見を有するものとして活かされることになります。実際今回の件でパーソルは相当評判を落としたわけですし。
そう考えると、信頼を失うリスクを取ってまで、アプリ開発の基本中の基本である実機テストをあえてサボるとは正直考えられません。むしろ、余りの短期間の開発で手が回らなかったとか、再委託先同士の横の連携が取れていなかったとか、別の理由を考える方が自然ではないでしょうか。
また、政府CIO補佐官の楠さんは、実機テスト用の診断サーバーが機能していたのかと疑問を投げかけています。
実機テストを実施していたら、もっと早く事象に気付けた可能性があるけれども、実機テスト用の診断サーバーが保守業者に払い出されていたか、係る診断サーバーを構築できるクラウド・バックエンドエンジニアがアサインされていたか、テストに係る要員・機材の体制が整っていたかを精査する必要がある
— Masanori Kusunoki / 楠 正憲 (@masanork) February 6, 2021
実機テスト用の診断サーバーとは、簡単にいうと実社会で稼働しているCOCOAのサーバーとは別に、テストのためだけに用いるサーバーを別途立てることを意味します。実社会で稼働しているCOCOAのサーバーでテストをしてしまうと、何か起きたときに実社会に混乱が生じてしまうからです（テスト端末の近くにいる人たちみんなにアラートが届くなど）。
そして、診断サーバーを立てるためには、アプリのバックエンド（一番コアになるシステム）に詳しいエンジニアが必要でした。
しかし、アプリそのもののアップデートを見越して、パーソルはむしろフロントエンド（直接ユーザーの目に触れる部分）に強い会社を再委託先に選んでいたようであり、結果的にテスト環境をすぐに整えられなかったという問題が起きたようです。
この点については、診断サーバーがなくてもテストはできたと主張するエンジニアの方もいらっしゃり更なる精査が必要ですが、以下ではいったんこの前提で話を続けます。
では、仮に受託先にテスト環境を構築できる体制がなかったために実機テストができなかったとすると、なぜ新しくバックエンドに詳しいエンジニアをアサインする、新たな再委託先を探すなどの措置が取られなかったのでしょうか。
ここに委託契約の難しさがあったのではないかと考えます（ここから先はあくまで推察ですので、その前提でお読みください）。
実務レベルでは、余りに仕様書段階での想定と異なる作業が発生した場合は「変更契約」という形を取ります。事業者側に掛かってくる費用も変わってくるため、もう一度新しい想定のもと契約をし直すのです。
しかし、変更契約はそう簡単にできるものではありません。
特に今回のようなアプリ開発の場合だと、どれだけApple、GoogleのAPI変更に伴う作業が発生しようと、全て「保守運用業務」の中で読み込めてしまうからです。工数等があらかじめ記載されていれば別ですが、今回のように保守運用業務がざっくりしていて、もともとの契約書で読み込めてしまう場合、委託元からすると（どれだけ追加で作業が増えたとしても）契約そのものを変更する理由は生じていないとみなされてしまいます。
このように、APIの度重なる変更に伴って再委託先での業務が著しく増大しているにも関わらず、それらが全て「保守運用業務」の中で読み込むことができたため、人員を増員させることもできず、テスト環境整備が間に合わなかったのではないか、というのがここでの仮説として考えられます。
実際、保守管理体制が遅れた理由について事業者は、NHKのインタビューに「ほかのアプリ開発の仕事もあるなかで、人繰りの調整が必要だった」と答えています。
（３）テスト体制構築の責任主体が不明確になる
とはいえ、いくら人員に不足していたとしても、アプリの開発において実機テストを抜くことが果たしてありえるのでしょうか。
この点について、明確な理由は現時点では分かりませんが、委託元である厚労省及び受託先かつ委託元でもあるパーソルにアプリ開発に関する知見が不足していたこと、テストの実施について明確な責任体制がなかったこと、再委託先同士の連携が不足していたこと等が原因ではないかと考えています。
委託契約書を見る限り、テストの実施に関しては、以下の一文が掲載されているだけです。
ここでいう「開発者」がどの事業者のことを指すのか明らかにはされておらず、テスト環境の整備や特定のグループをあらかじめテスターとして用意しておくなど、具体的な手法については全く触れられていません。また、上で再委託先の役割に触れましたが、そもそもテスト実施の責任についてどの事業者にも明確に振られていません。
繰り返しになりますが、一般的に委託→受託の関係においては、報酬の代わりに、受託された業務を完了し、成果物を納品するという関係性が出来上がります。
ここには、委託している側の「当然使えるものが委託先から上がってくる」という認識と、委託されている側の「与えられた仕事はやった」という微妙に異なる認識が生まれます。
また、再委託は基本的に孫請けになればなるほど過酷な労働環境になっていきます。当然ながら、受託側からするとできるだけ仕事量を少なくしたいという思いがあり「気にはなっているけど藪蛇になるくらいなら黙っていよう」というインセンティブが生まれてもおかしくありません。
結果、最初の設計図、すなわちどの事業者にどの仕事を振るかの設計図が完璧でない限り、どこかに穴（本来するべきなのに誰もしていない状態）が生まれてきてしまうという構造が生じてしまいます。
この点について、システム開発の経験者はこのように述べています。
（2021.02.18 PMIインタビュー）
はっきり言って、一般的にシステム開発をする者にとって、実機テストとか実環境でのテストを怠るということはあり得ないです。
ただし、今回のようにプロセスが分業になってくると、「お互いがどこかのプロセスでテストをやるのだろう」とお見合いになってしまうケースはよくあります。特に今回のように突貫及び大規模プロジェクトだと、言い出しっぺになって仕事を振られるくらいなら、誰かがやってくれるだろうと見て見ぬふりをしてしまうこともよくあることです。
トータルコーディネートする人がいなかったのかという疑問は残りますね。
もちろん最終的には直接の委託先であるパーソルが実機テストを含めて品質管理を行うことが筋であり、その直接の責任を負っていると考えられますが、HERSYSの開発もありパーソル側での管理が追い付いていなかった、（考えにくいですが）パーソルが本当に実機テストを行う必要性を認識していなかった可能性もあります。
まとめ
以上のように、様々な経緯からパーソルが引き受けたCOCOA開発の委託契約でしたが、①設計とコーディングが完全に分離されてしまっており、フィードバックループが作れない、②事前に保守・運用の規模が想定しにくい、③テスト体制構築の責任主体が不明確になる等の理由から、技術的に効率的、効果的なアプリ開発ができなかったのではないかと考えられます。
もちろんこうした体制が一概に失敗を招くというわけではありません。むしろ問題は、重厚な行政システムを調達・開発するための契約形態を、COCOAのような素早いアップデートが求められるシステムに適用してしまったことにあるのではないかと思います。委託契約の枠組みのなかで今後どのようにアジャイル型のアプリ開発を行っていくことができるかは、デジタル時代を見据えたわが国の大きな課題でもあります。
ここには、政府が直接エンジニアを採用する、より柔軟な委託契約のスキームを検討するといったアイデアも考えられると思います。特に二点目に関しては、2019年に中小企業庁の「制度ナビ」というアプリ開発において柔軟な委託形態が採用されたと聞いたこともあります。
この取組がどう機能したのか詳細まで今回は調べることができませんでしたが、こうした過去のチャレンジについても今後掘り下げていきたいと考えています。
いよいよ次回は最終回（後編）です！
ここまではCOCOAそのものについてお話をしてきましたが、次回はより広い視野から「制度」の中のCOCOAの位置づけ、そしてデジタル社会を見据えた日本の課題について深堀りしていきたいと思います。
この記事が気に入ったらサポートをしてみませんか？