公共部門のソフトウェア工学とプラットフォーム

公共価値にとってなぜ重要か

今日、市民が接するほぼすべての公共サービス――出生の登録、給付の申請、税金の支払い、裁判の日程の予約――は、カウンターや画面の背後のどこかでソフトウェアの上で動いている。そのソフトウェアは、一回限りの購入であることはめったにない。それは国家の恒久的なインフラの一部になり、しばしば、それを委託した政権、それを構築した供給者、そしてそのエンジニアが訓練を受けたプログラミング言語よりも長く存続する。公共機関は、その資産の状態が目に見える建物や道路を経験するようには、ソフトウェアを経験しない。ソフトウェアは目に見えない形で劣化し、その劣化の請求書は何年も後に緊急事態として届く。

このトピックを推進する緊張関係は構造的である。ソフトウェアは本質的に反復的である――要件は、利用者が機能するシステムとやり取りするにつれてより明確になり、最良の工学的実践は、何か小さなものを構築し、学び、適応することである。対照的に、公共調達と説明責任のサイクル(トピック3.7「公共調達と委託」を参照)は、資本事業と防衛契約のために構築された。固定された仕様、単一の大規模な授与、マイルストーン支払い、そして提供が始まる何年も前に承認される事業計画書である。議会や監査人が固定価格、固定範囲の契約を期待し、エンジニアリングチームが最初のリリース後に方向転換する必要があるとき、その不一致は、範囲の拡大、予算超過、あるいは2019年には正しく仕様化されたが出荷される頃には陳腐化しているシステムとして現れる。

このトピックのエンジニアリングの実践が構築するために存在するプラットフォーム――共有された本人確認システム、支払いレール、省庁間で再利用される事案管理ツール――はトピック5.1の主題である(トピック5.1「デジタル政府とデジタル変革」を参照)。このトピックは、そのようなプラットフォーム、あるいは単一のサービスを、それをたまたま最初に書いた供給者ではなく、それに依存する公共機関によって所有される、信頼できて置き換え可能なものにするソフトウェアを構築し購入する規律を扱う。

中核概念

構築か購入かの決定とは、一つの組織のニーズのために書かれたオーダーメイドのソフトウェアを委託することと、類似の買い手の市場のためにすでに構築された設定可能な商用ソフトウェアを採用することの間の選択である。真に独特ではないニーズ――給与計算、電子メール、標準的な事案管理――にとっては、通常、購入のほうが安価でリスクが低い一方、構築は、要件があまりに異なるためいかなる設定可能な製品も合わない場合、あるいはその能力そのものが組織が所有し発展させる必要のある戦略的資産である場合にのみ正当化される。

技術的負債とは、ソフトウェア技術者ワード・カニンガムが1992年に作り出した比喩であり、より徹底的でより時間のかかる方法よりも、今すぐソフトウェアを出荷する便宜的な方法を選ぶことの蓄積された費用を指す。技術的負債は、金融的な負債と同様に、それを負うこと自体が本質的に誤っているわけではない――カニンガム自身の論点は、機能するコードを速く出荷し、後でリファクタリングすることが正しい判断でありうるというものだった――が、決して返済されない負債は、より遅い提供、より多くの欠陥、上昇するリスクとして利子を蓄積し、自らの負債を見ることができない公共機関は、それを返済するかそれを複利で増大させるままにするかを決めることができない。

レガシーシステムとは、時代遅れであるにもかかわらず活発に使われ続けている古い技術、アプリケーション、あるいはプラットフォームであり、しばしば、それを置き換えるのが高価であるか、組織に残っている誰もそれが何をするかを完全には理解していないためである。レガシーシステムは政府において特に持続的である。中核となる税、給付、社会保険のシステムは、行政計算のために1960年に設計されたコモン・ビジネス指向言語であるCOBOLのような言語で数十年前に書かれ、今もなお数百万人の市民のための取引を処理している。なぜなら、それらのシステムは機能しており、それらを安全に廃止するために必要な制度的知識は、しばしばそれ自体が先に退職してしまっているからである。

ソフトウェアの近代化とは、レガシーシステムを現在のアーキテクチャ、言語、あるいはプラットフォームに変換、書き換え、あるいは移行することの一般的な用語である。ソフトウェアの近代化は、完全な書き換えから、同じコードを現代のインフラに再ホストするといったより保守的な選択肢まで、一つの連続体にまたがり、それらの間の選択は、技術的な決定であると同時にリスク管理の決定でもある。

ストラングラー・フィグ・パターンとは、宿主の木の周りで成長し徐々にそれを置き換えるつる植物にちなんで名づけられた、増分的な近代化アプローチであり、新しい機能がレガシーシステムと並行して構築され、トラフィックが、単一の切り替えでシステム全体を置き換えるのではなく、一片ずつそちらに転送される。ストラングラー・フィグ・パターンが重要なのは、それが、サービス全体を停止させることなく、各増分を検証し、ロールバックし、あるいは一時停止できるようにするからである――これは、古いシステムが停止され新しいシステムが単一の瞬間に起動され、何かが間違っていても後戻りする方法がない、ビッグバン置換とは正反対である。

ベンダーロックインとは、顧客が単一の供給者の独自技術、データ形式、あるいは契約条件にあまりに依存するようになり、別の供給者への切り替えが法外な費用やリスクを伴うようになることである。ベンダーロックインは、公共部門のソフトウェアにおいて特有の危険である。なぜなら、買い手は、重要なサービスを運営しているシステムから立ち去る実務上の能力が限られた、繰り返しの顧客であり、これがすべてのその後の更新における交渉力を弱めるからである。

自由でオープンソースのソフトウェアとは、利用者にソースコードを使用し、学習し、修正し、再配布する自由を与えるライセンスのもとで配布されるソフトウェアである。自由でオープンソースのソフトウェアは、「オープンソース・バイ・デフォルト」の方針の基盤であり、この方針のもとでは、公共機関は、セキュリティ上の機微さや第三者の権利といった特定の理由がそれを差し控えることを正当化しない限り、委託するソースコードを公表することを既定とする。その論拠は通常「公金、公共のコード」と要約される。一度公金で支払われたソフトウェアは、異なる法域で、同じ問題を解決する別の公共機関によって、再び支払われる必要があるべきではない。

デジタル公共財とは、商業的な利益を生み出すためではなく、公共の開発やガバナンスの目標を達成するのを助けるために設計された、開かれたライセンスのもとで公開される、開かれたソフトウェア、データ、あるいはコンテンツである。デジタル公共財は、ある政府のオープンソースの公開を、単なる内部の透明性のジェスチャーとしてではなく、他の政府や市民社会組織が直接活用できる、より広い共有されたインフラの一部として再構成する。

アジャイルソフトウェア開発とは、事前に合意された固定計画に従うことよりも、機能するソフトウェア、頻繁な提供、変化への対応を優先する、ソフトウェア構築への反復的なアプローチの包括的な用語である。アジャイルソフトウェア開発は、要件、設計、構築、検証がそれぞれ次が始まる前に完全に完了する逐次的なアプローチであるウォーターフォールモデルと対照をなす。ウォーターフォールの公共機関への魅力は常に、そのマイルストーンが固定価格契約と年次予算サイクルにきれいに対応することだった。これが、提供が真にアジャイルである場合でさえ、これほど多くの調達法が今もなおそれを前提としている理由である。

実用最小限の製品とは、それが機能するかどうかを検証し、次に何を構築すべきかを学ぶために、実際の利用者にリリースできるサービスの最小のバージョンである。公共部門のデジタルサービスのプレイブックに適応させられた実用最小限の製品の概念は、反復的なチームに、完全な範囲が完成するずっと前に、資金提供者や監査人に何か実在し機能するものを示す弁護可能な方法を与える――ただし、その説明責任のプロセスが、それを別の名前の完成品として扱うのではなく、真に最小限のリリースを受け入れることが条件である。

ベストプラクティス

1. 差別化されていないニーズには購入を既定とし、真に独特なものにのみ構築を取っておけ。 給与計算、電子メール、一般的な事案管理のニーズは、オーダーメイドのソフトウェアを正当化するほど他のいかなる組織のニーズとも異ならないことがめったにない。要件、規模、あるいは数十年にわたってその能力を所有し発展させる必要性が、市場が提供するものと真に異なる場合にのみ構築せよ。
2. どれだけの技術的負債を運ぶかを決める前に、それを可視化せよ。 稼働中のすべてのシステムについて、既知の近道、先延ばしにされた修正、サポートされていない依存関係の登録簿を維持し、定められた周期で見直し、もう一年負債を運ぶことが、誰も見ていないのではなく意図的なトレードオフであるようにせよ。
3. 重要なレガシーシステムから離れる唯一の経路として、単一の不可逆的な切り替えを決して計画するな。 各部分を検証し、元に戻し、段階的に展開できる、ストラングラー・フィグ・パターンのような増分的なアプローチを優先せよ。何百万人もが依存するシステムのビッグバン置換は、何かが失敗しても後戻りする方法のないまま、何年分ものリスクを単一の週末に集中させる。
4. あなたの組織が書かれるために支払うソースコードを、借りているサービスではなく、所有する資産として扱え。 紛争が始まった後ではなく契約の時点で、ソースコードのエスクロー、あるいは完全な所有権を交渉せよ。あなたの重要なサービスのコードの唯一のコピーを保持する供給者は、設計によるベンダーロックインである。
5. ソースコードを既定で開かれたものとして公表し、それを差し控えるには特定の正当化を要求せよ。 一貫して適用される「オープンソース・バイ・デフォルト」の方針は、各省庁の独自に構築されたソフトウェアを、一回限りの費用ではなく共有された政府横断の資産に変え、外部の専門家が、内部のチームだけでは見逃すであろうセキュリティの欠陥を見つけることを可能にする。
6. 反復的な提供を、技術的に可能なだけでなく法的に可能にするソフトウェア契約を書け。 署名時に合意された固定の仕様に対してのみ支払う契約は、チームに、正直なアジャイルの実践と契約上のコンプライアンスとの間の選択を強いる。代わりに、最後の単一のマイルストーンではなく、実証された機能するソフトウェアに結びつけられた段階的な資金供給の関門を用いよ。
7. 近代化を、一回限りの資本プロジェクトとしてではなく、継続的なプログラムとして資金供給せよ。 一度近代化されてからさらに二十年放置されたレガシーシステムは、それが始まったのと同じリスクを蓄積する。世代に一度の壮大な置換ではなく、道路当局が再舗装のために予算を組むように、継続的で増分的な更新のために予算を組め。
8. 商用ソフトウェアを購入する場合でも、開かれた標準と移植可能なデータ形式を選べ。 供給者のシステムに、開かれた文書化された形式でデータを保存しエクスポートすることを要求することは、ソフトウェア自体が独自仕様であっても切り替え費用を低く保ち、しばしば、すべてのシステムがオープンソースであることを主張するよりも達成可能な、ロックインに対する近い将来の保護策である。
9. 完全な範囲にコミットする前に、実用最小限の製品を構築し実際の利用者に見せよ。 真に最小限のバージョンをリリースし、そこから学んだことに基づいて反復することは、誤った前提を、それがまだ安価に修正できるうちに捕捉する。それに対して構築された大規模なシステムの後にではなく。
10. 提供が外部委託されている場合でも、賢明な買い手であるのに十分な社内のエンジニアリング能力を保持せよ。 技術的な専門知識を空洞化させた公共機関は、供給者の提案を評価することも、問題を抱えたプロジェクトの早期警告のサインを見つけることも、ロックインから交渉して抜け出すこともできない。調達規則が紙の上で何を言おうともである。
11. レガシーシステムのユーザーインターフェースよりも先に、そのリスクのプロファイルを廃止せよ。 サポートされていない言語、パッチが当たっていないインフラ、文書化されていない統合――停止と侵害を引き起こす失敗――の置換を、運用上のリスクがはるかに少ない見た目の近代化よりも優先せよ。
12. 予算とスケジュールの乖離だけでなく、エンジニアリングの指標で提供の健全性を測定せよ。 デプロイの頻度、欠陥率、未対応の最も古い技術的負債の項目は、しばしば最後に動く指標である予算通りかどうかよりも、あるプログラムが成功するかどうかについてガバナンス理事会に多くを語る。

チームで話し合うべき問い

私たちは、どれだけの技術的負債を、システムごとに運んでいるかを実際に知っているか? ほとんどの公共機関はその年の資本予算を述べることができるが、そのソフトウェア資産のどれだけが、サポートされていない構成要素、文書化されていないロジック、あるいは残っている職員の誰も完全には理解していないコードの上で動いているかを、いかなる確信をもっても述べることができない。この問いを使って、室内の各システムの所有者に、自分たちのチームが、誰も予期しなかった何かを壊すことなく、自分たちの最も重要なシステムを安全に変更できると、正直にどれだけ確信しているかを見積もらせよ。これらの見積もりを、重要なエンジニアが去るとともに去ってしまう部族の知識ではなく、定められた周期で見直される実際の登録簿に変えるには何が必要かを議論せよ。また、現在誰がどれだけの負債が許容できるかを決めているか、そしてその決定が意図的なものか既定によるものかも検討せよ。

もし私たちの最も重要なレガシーシステムが今日から置き換えられる必要があったら、私たちはビッグバンの切り替えを計画するだろうか、それとも増分的な移行を計画するだろうか――そしてなぜか? 古いシステムを一度にすべて置き換えるという直感は、しばしば、技術的な必要性よりも予算サイクルとプログラム管理の便宜によって駆動されており、それは巨大なリスクを単一の瞬間に集中させる。この問いを使って、あなたの最も重要なレガシーシステムのストラングラー・フィグ・スタイルの増分的な移行が、一片ずつ実際にどのようなものになるかを具体的にたどれ。今日その経路を選ぶことを妨げているものは何か――単一の稼働開始日を中心に構成された資金供給、単一のきれいなマイルストーンを求めるガバナンスのプロセス、あるいは、このシステムにとって増分的な移行を不可能にする真の技術的制約かを議論せよ。

あなたの組織が構築を委託して支払ったソフトウェアのソースコードを実際に誰が所有しており、私たちはそれを証明できるだろうか? 多くの公共機関は、ある供給者との関係が悪化したときになって初めて、その契約が、自分たちの重要なサービスが依存するコードの明確な所有権やエスクローを一度も確保していなかったことを発見する。この問いを使って、あなたの最も重要なオーダーメイドのシステム三つの契約を取り出し、それぞれがコードの所有権、エスクロー、そしてそのコードを別の供給者に持ち込む権利について具体的に何を述べているかを確認せよ。もし明日、それらの三つのシステムのいずれかのあなたの主要な供給者が廃業する、あるいは関係を続けることを拒否したら何が起きるかを議論せよ。

オープンソース・バイ・デフォルトのアプローチが同じくらいよく、あるいはより良く私たちに仕えるであろうとき、私たちはどこで習慣によって閉じた独自のソフトウェアに既定で頼っているか? オープンソース・バイ・デフォルトの方針は、まさに、ほとんどの公共機関が重なり合う問題を独立して解決しており、それぞれが、別の公共機関がすでに構築し共有できたであろうソフトウェアの完全な費用を支払っているために存在する。この問いを使って、現在構築あるいは仕様化されている一つのシステムを特定し、同等のものがすでに政府の他の場所でオープンソースのソフトウェアとして存在するか、あるいはあなたが構築しているものが他者が再利用するために有用に公表されうるかを問え。この再利用を実際に妨げている具体的な障壁――セキュリティ上の懸念、調達の習慣、明確な方針の欠如――は何かを、それがここでは関連しないと想定するのではなく議論せよ。

私たちの調達と説明責任のプロセスは実際に正直なアジャイルの提供を許しているか、それとも単にウォーターフォールのマイルストーンをスプリントとして再ラベル付けしているだけか? あるチームが、契約署名時に合意された固定の仕様に対して今もなお資金供給され、統治され、報告されている一方で、名目上はアジャイルな儀式――スタンドアップ、スプリント、バックログ――を実施することはよくあり、これはアジャイルというラベルのもとですべてのウォーターフォールの失敗パターンを再現する。この問いを使って、一つの稼働中のデジタルプログラムを、その事業計画書から現行のガバナンス報告まで追跡し、資金供給の構造が、真の早期のリリースが教えたことに基づいてプログラムが方向を変えることを許容するかを問え。反復的な提供が見せかけではなく本物であるために、プログラムがどう資金供給され報告されるかにおいて何が変わる必要があるかを議論せよ(トピック3.7「公共調達と委託」を参照)。

私たちは、私たちが最も依存するシステムの賢明な買い手であるのに十分な社内のエンジニアリング能力を持っているか? 提供能力だけでなく、その技術的な判断のすべてを外部委託した組織は、供給者の提案が健全かどうか、あるプロジェクトが静かにトラブルに向かっているかどうか、あるいはその仕事にとっての公正な価格が実際に何であるかを判断できない。この問いを使って、あなたの組織の何人が、あなたの最も重要なシステムについての技術アーキテクチャの提案を信頼に足る形で見直せるか、そしてその数が過去五年間でどう変化したかを問え。それが侵食された場所でその能力を再構築するには何が必要か、そしてそれなしで過ごすすべての一年で、提供のリスクと同じくらい交渉の立場において、あなたの組織が何を失うかを議論せよ。

実践において:公共価値の事例

架空の地域政府――例示のみであり、実在するいかなる法域の記述でもない――は、失業給付の申請を、三十年以上前に最初に書かれたシステムを通じて処理しており、その元のプログラミング言語を理解するエンジニアの数は減り続けていた。申請の量はシステムの設計者が予想していたよりもはるかに増加しており、夜間の処理バッチは朝の取引が始まる前に完了できないことが増え、この機関の技術指導部は、給付支払いに影響を与える計画外の停止は、もはや起きるかどうかではなく、いつ起きるかの問題だと警告していた。

この機関の最初の直感は、緊急に感じられる問題への従来型の対応だった。システム全体を近代的なプラットフォームに置き換える単一の大規模な契約を委託し、事前に完全に仕様化し、最後に一度の切り替え週末を伴う固定された二年間のタイムラインで提供させることである。この機関の監査委員会が委託した実施前のレビューは、契約が署名される前に困難な問いを提起した。もし新しいシステムが、本格的な稼働の最初の週に未発見の欠陥を抱えていたら、古いシステムがすでに廃止され後戻りする方法がない状態で、数十万人の申請者への給付支払いに何が起きるか、である。

この機関は方向を変えた。レガシーシステムを記録システムとして稼働させ続け、それと並行して、ストラングラー・フィグのアプローチを用いて、新しい申請受付と資格審査の機能を構築し始めた。各新しいモジュールは、まず小さな割合の新しい申請にリリースされ、古いシステムの並行した出力に照らして検証され、その結果が一致した場合にのみ拡張された。十八か月以内に、大多数の新しい申請が近代的な構成要素を通過する一方、元のシステムは縮小していく残余の案件負荷を処理し、何かがおかしく見えたらいかなる単一の事案も古い経路に戻す能力を保持していた。この機関はまた、この仕事のために発行されるすべての新しい契約において、ソースコードが機関によって所有され、セキュリティレビューが完了次第オープンソースとして公表されることを要求した。それによって、同じ老朽化したメインフレームの問題に直面する他の地域政府が、ゼロから同じ構築を繰り返すのではなく、その構成要素を適応させられるようにした。

レガシーシステムの最後の残余の機能の完全な置換には、ほぼ四年かかった――紙の上では、元の二年間のビッグバン計画が約束していたよりも長い。しかし、移行の間にいかなる申請者も計画外の停止を経験することはなく、各増分は欠陥が見つかったときに数時間以内にロールバックできるだけ小さく、そして二つの隣接する地域政府が、その公表後最初の一年以内に、この機関が公表した資格審査のコードを自分たち自身のシステムのために適応させ始めた。

四つのセクター別視点

地方自治体

地方自治体は通常、一握りの国規模のプラットフォームではなく、多数のより小さな、接続されていないシステムを運営しており、これは、一つの目に見える旗艦システムにではなく、別々に調達され別々に維持される多くのアプリケーションにわたって技術的負債が蓄積することを意味する。地方自治体は通常、いかなる政府レベルの中でも最も少ない社内のエンジニアリング能力しか持たず、これは、オーダーメイドの構築よりも設定可能な商用ソフトウェアを購入することの論拠を特に強くし、共有された地域や国のプラットフォーム――トピック5.1の主題(トピック5.1「デジタル政府とデジタル変革」を参照)――を、各自治体が同じ能力を別々に再構築することを避けるための特に価値の高い経路にする。

国の政府

国の政府は、最も古く最も重大なレガシーシステムが位置する傾向にある場所である――中核となる税、社会保険、給付の行政である――なぜなら、これらはしばしば政府における最初の大規模なコンピュータ化の取り組みの一つであり、今やいかなる近代化の失敗にとっても最も高い利害を伴うからである。国の政府は通常、真に増分的な近代化プログラムを実施し、その契約に真のコード所有権を交渉する専門の商業的・工学的能力を持ち、通常、政府横断の再利用を実際に起こさせるだけの規模を伴ってオープンソース・バイ・デフォルトの方針を設定するのに最も適した政府レベルである。

社会セクターと非営利団体

非営利団体や慈善団体は、自ら大規模なカスタムプラットフォームを構築することはめったにないが、頻繁に、政府の資金提供者によって委託または義務づけられたソフトウェア――報告ポータル、助成金や契約がそれを使うよう求める事案管理システム――の受け手側にいる。その設計、その技術的負債、あるいはその供給者にほとんど影響力を持たない。政府が義務づけたシステムに依存する社会セクターの組織は、それを修正するための影響力をまったく受け継がないまま、そのシステムの失敗パターンを受け継ぐ。これは、成果に基づく資金供給関係が、成果指標そのものだけでなく、義務づけられた技術の運用上の負担を考慮する必要がある理由をもう一つ加えている(トピック3.7「公共調達と委託」を参照)。

多国間・国際機関

多国間機関や開発機関は、ある国の公共行政のために構築されたソフトウェアを、それぞれの政府が民間の供給者に完全な費用で同等のシステムを委託するのではなく、他の国々が適応できる再利用可能なデジタル公共財として、ますます推進している。ここに特有のリスクは、ある国の法的・行政的な文脈のために構築されたデジタル公共財が、あまりに少ない適応で他の場所に採用され、本人確認、資格、あるいはプロセスについての、実際には移転しない前提を輸入してしまうことである。共有され開かれたインフラの約束は現実だが、それは真の地元の適応能力がコードに伴う場合に限られる。

よくある失敗パターン

• 稼働開始で失敗するビッグバンの切り替え。 重要なレガシーシステムが、本番環境での実際の運用にさらされることのない何年もの開発の後、単一の不可逆的な切り替えで置き換えられ、実際の規模あるいは誰も検証しなかったエッジケースでのみ現れる欠陥が、完全な稼働の初日に表面化する。古いシステムはすでに廃止されているため、後戻りする方法はない。その代償は、見逃された支払い、拒否されたサービス、あるいはそのシステムが奉仕するために存在するまさにその市民に影響を与える停止として、最悪の瞬間に――誰もが置換が機能することに頼っていた瞬間に――測定される。
• 静かな技術的負債の蓄積。 締め切りの圧力が、既知の近道を修正するために必要な時間との議論に繰り返し勝ち、それぞれの先延ばしは個別には弁護可能であるが、蓄積された負債はやがて、小さな変更さえ不釣り合いに高価でリスクの高いものにしてしまう。その代償は何年も後に、誰も安全に修正できないシステム、最も緊急なパッチ以外の何かを試みることを静かにやめてしまった人材、そして、継続的でより小規模な更新であったであろうよりもはるかに大規模で高価な最終的な近代化プログラムとして表面化する。
• 安定性と取り違えられたベンダーロックイン。 公共機関が、切り替えが試みるにはあまりに破壊的に見えるという理由だけで、真の切り替え費用が何であるかを一度も検証することも、それらの費用を管理可能に保つであろうコードの所有権や開かれたデータ形式を交渉することもなく、同じ供給者の契約を繰り返し更新する。その代償は、価格と条件における恒久的に弱められた交渉の立場であり、供給者のサービスの質が低下するか、その価格が上昇し、公共機関が信頼できる代替案を持たないことに気づいたときにのみ発見される。
• 見せかけのアジャイル。 ある提供チームがアジャイルの儀式――スタンドアップ、スプリント、バックログ――を採用するが、根底にある契約、資金供給、ガバナンスの構造は今もなお固定された仕様と単一の実施可否のマイルストーンを前提としており、そのためチームはスプリントの速度を報告しながら、実際にはその下でウォーターフォール計画に対して提供している。その代償は、アジャイルの真の便益――方向を変える早期の利用者のフィードバック、早期に表面化するリスク――のいずれも実現しない一方、現代的な実践の見た目が、監督機関が根底にある硬直性を見て異議を唱えることをより困難にすることである。
• 維持計画のないオープンソース方針。 ある公共機関が、オープンソース・バイ・デフォルトの方針を満たすためにソースコードを公表するが、その公表を、外部の貢献を見直すため、脆弱性にパッチを当てるため、あるいは文書を維持するための資源配分なしに、一回限りのコンプライアンスの段階として扱う。その代償は、開かれて見えるが維持されない行き止まりとして機能する公表されたリポジトリであり、これは、一度も公表しなかった場合よりも、より広いオープンソース・バイ・デフォルトのプログラムへの信頼を損なう。

成熟度モデル

チェックリスト

• すべての重要なシステムの技術的負債を棚卸しし、定められた周期で登録簿を見直す。
• いかなる重要な新しいソフトウェアにコミットする前にも、文書化された構築か購入かの枠組みを適用する。
• いかなるレガシーシステムの置換についても、増分的な移行手法を既定とし、ビッグバンの切り替えには明示的な正当化を要求する。
• 署名前に、すべてのソフトウェア契約においてソースコードの所有権あるいはエスクローの条件を確認する。
• オープンソース・バイ・デフォルトの方針のもとでソースコードを公表し、文書化された例外プロセスを備える。
• その方針のもとで公表されたすべてのリポジトリについて、その最初のリリースだけでなく、継続的な維持のために資源配分する。
• 根底にあるソフトウェアが独自仕様であっても、開かれた文書化されたデータ形式を要求する。
• 単一の固定仕様のマイルストーンではなく、実証された機能するソフトウェアを中心に資金供給の関門を構成する。
• 完全な範囲にコミットする前に、実際の利用者とともに実用最小限の製品を構築し検証する。
• デプロイの頻度、欠陥率、未解決の技術的負債を常設のガバナンス指標として追跡する。
• 賢明な買い手であるために必要なものに照らして社内のエンジニアリング能力を評価し、特定されたギャップを埋める。
• サポートされていないインフラと文書化されていない統合を、見た目の近代化よりも優先する。

主要情報源

• GOV.UK Service Standard, Government Digital Service, United Kingdom — 公共サービスのための反復的でユーザー中心の提供と開かれた標準を要求する国のデジタルサービス基準。
• Office of Management and Budget, Federal Source Code Policy (M-16-21), United States — カスタム開発された政府のソフトウェアについて、省庁に再利用とオープンソースの公表を検討するよう要求する連邦の方針。
• Free Software Foundation Europe, Public Money, Public Code campaign — 欧州の聞き手のために発展させられた、公金で資金供給されたソフトウェアのソースコードを自由でオープンソースのライセンスのもとで公表することの論拠。
• Ward Cunningham, 'The WyCash Portfolio Management System' (OOPSLA 1992 experience report) — 技術的負債の比喩の原初の言明。
• Digital Public Goods Alliance — 公共の開発目標に仕えるよう設計された開かれたソフトウェア、データ、コンテンツのための基準と登録簿を維持する、複数の利害関係者による取り組み。

参考文献

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. 'The WyCash Portfolio Management System' (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/