新型コロナ関連システムはアジャイル開発すべきなのか

3年近く前
鈴木 雄介
代表取締役社長
鈴木 雄介

unsafe:

50315926536_1ca99538d7_k_header.jpg Syringe with Covid-19 vaccine CC BY 2.0

弊社および私は、新型コロナに関するシステム開発に直接的にも間接的にも関わっていません。ですが、私の友人数名が直接的あるいは間接的に関わっています。ただ、私はそれらの友人と、これらの件について深い話をしたことはなく、いわゆる内情を知る機会はありませんでした。よって公開されている情報だけを基にコメントをしています。

昨今、COCOA(新型コロナウイルス接触確認アプリ)だけではなく、HER-SYS(新型コロナウイルス感染者等情報把握・管理支援システム)やVRS(ワクチン接種記録システム)などについても、品質が悪く、利用が進んでいない記事が出ています。

私は「COCOAの開発手法は適切だった?政府謹製「アジャイル開発ガイド」誕生のワケ」という解説記事にコメントを寄せさせてもらいました。コメントの抜粋は以下。

  • アジャイル開発は単にツールの開発ではなく、サービス開発のための手法だ
  • (HER-SYSであれば)『保健所の業務負担を軽減し感染状況を把握するサービス』を提供する視点に立つべきであり、HER-SYSというシステム開発に閉じてしまうとアジャイル開発の良さが生きない。こうしたサービスを提供すると考え、その上で自治体や医療機関にどうやって使ってもらうかという姿勢が、政府のシステム開発では不足しているのではないか
  • アジャイルで開発すること自体は適切だが、多くのユーザーに使ってもらうためにも、実用最小限の製品(MVP)を設定して順次展開していく必要がある。それが適切にできていなかった
  • ユーザーを絞り込むことになるMVPの設定は難しく、省庁側に強い意志がないとなかなかできない

アジャイル開発は適切だった

取材は「これらのシステムはアジャイル開発でやるべきだったのか?」という問いから始まりました。

内閣官房情報通信技術(IT)総合戦略室が2021年3月末に公開した「アジャイル開発実践ガイドブック」のP1「背景と目的」には、以下のように記載されています。

現実的には開発期間を潤沢に確保することは難しく、要求とその仕様の詳細をすべて記述するのに費やせるほどの時間をあてられないことも少なくありません。また、実際の利用における望ましい挙動を実現するためには、作成されたアウトプットを使ってみて、そのフィードバックを元に洗練させていくアプローチの方が効率的かつ効果的であるケースが往々にしてあります。特に、政府情報システムの利用は府省職員だけではなく、自治体や国民をもその範囲とするため、昨今の社会環境の変化や多様化に基づく様々なニーズに迅速に応えていく必要性が高まっています。こうした状況下では、システム開発にも変更に対して柔軟に適応することが求められます。

新型コロナウィルス関連システムは、間違いなくこの定義に当てはまるものでしょう。時間がない中で刻々と情勢は変化し、全ての国民と全国の自治体・医療機関と連携する必要があります。まさに「昨今の社会環境の変化や多様化に基づく様々なニーズに迅速に応えていく必要性」があります。

公平なサービスには不平等な機能が必要

では、アジャイル開発を適用したにもかかわず、なぜ問題がおきたのでしょうか?私は平等と公平、そしてサービスとシステムの違いを意識する必要があると考えています。

この絵は平等(Equality)と公平(Equity)を示したものです(元ネタ The Evolution of an Accidental Meme)。

僕がこの画像から解釈するのは「公平なサービスのためには、不平等な機能が必要」ということです。国民、あるいは全国の自治体や医療機関のおかれた環境は異なり、それぞれのニーズは多様です。その対象者に対して公平なサービスを提供するためには、それぞれに合わせた適切な機能を提供していく必要性があります。

システム開発では「1つの機能で全てのユーザーをまかなう」という圧力がかかりやすいです。なぜなら、1つの機能であれば、もっともお金がかからないからです。これは社内システムなど、内部のユーザーを対象にした場合には許容されます。ユーザーの置かれた環境が似通っており、かつ、利用を強制できる(経費精算など、嫌でも使わなければならない)からです。

しかし、外部のユーザーを前提にした瞬間、この論理は通じません。外部のユーザーには強制できないので「使っていただく」という姿勢が必要になります。

サービス開発の視点が欠けている

感染者情報を収集し管理するHER-SYSについては、「新型コロナ集計がようやく「HER-SYS」へ移行、それでも残る課題」という記事に

システムを急造して2020年5月末にHER-SYSの運用を開始したものの様々な問題が頻発したため、データは長らく使い物にならず公表もされてこなかった。「紙よりも入力の負担が重い」と医師らの不評を買ったためデータ入力が進まなかっただけでなく、誤入力が多発するなどデータの信頼性も担保できなかったためだ。

使い勝手も2020年秋からの機能改修で改善した。発生届に必要な情報と、疫学調査に使う情報などを別のタブ画面で入力するよう画面設計を改め、画面のレイアウトも紙の発生届の書式に近づけた。これによって医師などによる誤入力が減った。また入力支援機能も実装し、発生届の日付や患者の年齢などにエラーチェック機能を設け、ありえない日付は訂正を促すようにした。システムの使い勝手が良くなり誤入力も減少したことでデータ精度が大きく改善。

リリース当初から120個の項目は全て正しく保存されていたでしょう。それはそれで正しい動作です。しかし、サービスとして捉えた場合、120個の項目が並んでいるだけでは使い物にならなかったのです。重要なのはサービスの質であって、道具であるシステムの質は直接的には関係ありません。

大事なことは「どうサービスを提供し、その中で、どう道具としてのシステムを使ってもらうか」という視点です。HER-SYSであれば、保健所や医療機関に使ってもらわなくては意味がないので、当然、そうした視点が必要だったはずです。

ユーザーから学び、段階的に拡げていく

では、どのようにサービスの視点を持ちながら、システムを育てていくべきでしょうか。もっとも効率的なのは小さな機能からはじめて、どんどん拡充していく方法です。こちらの絵も有名です(元ネタ「Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable」)。

何を作るべきか明快に正解がわかっているなら、上のやり方が最適で効率的です。しかし、何を作るべきかが曖昧な時は、下のように小さく初めて育てていく進め方が効率的になります。

下の絵の最初で重要なのは「目的を達成できるが、満足度が低い」という点です。この絵は「A地点からB地点へ移動する」ことが目的です。早く作れるからと言って「実物大の模型」では目的が達成できません。 次に満足度が低いというのは「一部の人の状況に最適化されている」「使える人に制限がある」と言った状態を示します。全員の満足度が低いのではなく、ある一部の人には大満足という状態を目指します。

HER-SYSも3ヶ月という短期間で投入したので「小さく始める」ということは意識していたはずです。しかし、小さく始めることが、きちんとサービス開発の視点で考えられていたのかは検証が必要になります。導入試験もあったようですが、そのステップが有効に機能していたのかが重要になります。 また、段階的な導入を行うということは自治体や医療機関に優先順位を付けることを意味します。この優先順位付けは省庁側は主導して整理が必要となります。

まとめ

色々と書きましたが、アジャイル開発の導入にチャレンジしたことは評価すべきであり、今回の経験を糧に、よりよいシステム開発が実現されるはずです。新型コロナウィルスの状況は刻々と変わっていきます。アジャイル開発であったメリットが必ずや活きてくるでしょう。

一方で、政府系の案件では調達が請負契約が前提になっているおり、このことからアジャイル開発の前提である同じチーム体制を維持することが困難になっています。もちろん、仕様書に基づく調達は国民への説明責任として実施される必要があります。そのため「何をやるかは曖昧だが人だけを雇う」というようなことはできません。簡単な話ではありませんが、もっとアジャイル開発が実施しやすい環境整備を進めていく必要があります。

また、メディアは単に失敗を責めるのではなく、新しい挑戦への正しい評価と、その成果の見守り方について冷静な視点が欲しいと思います。税金を使っている以上、無駄は許されませんが、新しい挑戦をしないことが非効率を招き、膨大な無駄を産むことにつながります。

今後も「昨今の社会環境の変化や多様化に基づく様々なニーズに迅速に応えていく必要性」は、益々増えていくはずです。政府や自治体のサービスがITによって、より良くなることを心から願っています。

【アトラシアン製品】Jira Core CloudがJira Work Managementに変わります リレーブログ#01.5 おまけ
SHARE