カタパルトスープレックス

興味がない人は無理して読まなくていいんだぜ。

アメリカ政府の視点:オープンソースのソフトウェアは実際どれだけ再利用ができるのか?

f:id:kazuya_nakamura:20171028181637j:plain

原文:"How reusable is open source software?" by Laura Gerhardt, Innovation Specialist at 18F, October 23, 2017

 ここTechnology Transformation Services(TTS)に所属する私たちはオープンソースソフトウェアの大ファンです。オープンソースは納税者に透明性とコスト効率を提供する重要な方法の1つです。ホワイトハウスのオープンソースポリシーはオープンソースソフトウェアを「誰でもアクセス、使用、変更、共有できるソフトウェア」と定義しています。TTSは開発したすべてのコードをパブリックドメインとして誰でも複製または再利用できるオンラインリポジトリにリリースしています。このソフトウェアを構築する際には既存のオープンソースコードライブラリを組み込んでコードライセンス管理の必要性を最小限に抑えます。

 オープンソースソフトウェアにより政府、ベンダーや外部の貢献者が協力して作業することも可能になります。これにより柔軟な使用とカスタマイズが可能になり、政府はソフトウェアライセンスを節約することができます。セキュリティー上の恩恵もあります。監査能力を向上させ、開発者にセキュリティーに対する強い姿勢を最初から持たせることができます。コードはパブリックドメインであるため、誰でもコードを再利用または再配布することができます。18Fのオープンソースポリシーでは「オープンソースライセンスではない限定的なライセンスのプロジェクトにも統合することができる"としています。

 この記事は政府のカスタムソフトウェア開発プロジェクトにおけるオープンソースコードの使用に関するいくつかの誤解を明らかにし、特定の問題を明確にすることを目指しています。

再利用の限界

 オープンソースのコードが再利用可能であるというだけで、すぐに利用できるというわけではありません。

 すべての政府サービスのなり立ちには長い歴史があります。当時利用可能だった技術、複雑に絡み合った法的要件や関わった人たちなどです。

 その影響は多岐に渡ります。特定の免責事項を含む必要性、特定の形式の電子署名でサインすること、特定のフォームフィールドを更新すること、または独自の承認プロセスを持つなどです。

 このようなユニークな状況では政府サービスが望む厳密な形ですぐに使えるソフトウェアソリューションがない可能性が高いです。オープンソースかどうかに関わらず。ITチームが既存のコードベースをそのままインポートしようとすれば、ユーザーが絶対的に必要とする機能が不足している可能性があり、エンドユーザはそのサービスに満足できないでしょう。追加のメンテナンス費用を必要とする使用しない様々なものが含まれている可能性もあります。プロプライエタリなソフトウェアの場合、ワークフローとユーザーの構成によってシステムの制限がある可能性があります。

 ユーザーのニーズを満たすためには、ほとんどの場合カスタム開発が必要になります。オープンソースの柔軟性は必要なモジュールを組み込み、それらのユーザーニーズを満たす助けとなります。さらにプロプライエタリなソフトウェアに対する高価なライセンス料を払う必要もありません。Ruby on RailsやDjango(Python用)のようないくつかの既存のフレームワークによりユーザーと関係機関のニーズを満たすツールの開発に開発者がすぐに取りかかることができます。

 例えば、私たち18FはC2という米連邦政府一般調達局の公共建築物サービス(PBS)の購入カード承認アプリケーション構築の支援をしました。私たちの開発者はRuby on Railsを活用して承認ワークフローを構築しました。これにより承認者が必要とする情報を組み込むことができ、PBSの既存の独自のビジネスプロセスと同じ個別の購入ごとのレビューレベルを実装することができました。

 今後、他のチームがこの購入カード承認アプリケーションを使用する可能性があります。しかし、アプリケーションを大幅に変更することなく使用するのは困難でしょう。内部の承認プロセスが異なるからです。しかし、C2はオープンソースソフトウェアであるため外部の開発者はC2のコードをその目的に合わせて変えたり、少なくとも開発者がどのように問題対してアプローチを取ったか確認することができます。

オープンソースは自分で作るときに最高

 デジタルサービスの場合、オープンソースコードを再利用しやすいケースは二つあります。パッケージが同じビジネスプロセスをサポートしている場合とビジネスプロセスに関係なく同じソフトウェア問題を解決する場合です。オープンソースコードでは、開発者やデザイナーが既存のコードを自由に必要に応じて採用し、ユーザーのニーズを満たす開発作業に集中することができるからです。

 たとえばDigital Analytics Programのためにに開発されたソフトウェアは都市によって15回以上再利用されています。再利用されたオープンソースプロジェクトとしての成功の要因の一つは多くの政府機関がGoogle Analyticsを使ってトラフィックを監視していたからです。それによりソフトウェアのデータソースは常に同じ場所から同じ形式で提供されます。使用法とデータパイプラインが同じであれば、開発者は政府のブランドを組み入れるか、既存の機能の上に開発することができます。Digital Analytics Programソフトウェアは共通かつ限定的なビジネスケースをサポートすることによりオープンソースの再利用性を高めています。

 同様にU.S. Web Design Standardsは開発者にとって使いやすいユーザーインタラクションライブラリを提供しています。これによりパブリックかプライベートの開発者は自らが関わるプロジェクトのビジネス課題に集中してソフトウェアを開発することができます。アプリケーション設計者達によると、すべてのプロジェクトでボタンサイズのような設計上の意思決定を行う必要がないため開発期間が短縮できたそうです。U.S. Web Design Standardはオープンソースなので開発者は政府機関のスタイルガイドを満たし、元のコードに含まれていない追加のデザイン資産も自由に追加できます。

 展開プロセスはオープンソースソフトウェアを組織に組み込むもう1つの良い方法です。開発プロセスはビジネスプロセスとは異なることが多くあります。継続的デプロイメント(CI)などは他の組織が開発したオープンソースのソフトウェアを追加する方が容易な場合があります。これらのツールはプロジェクトへの頻繁で小さなコード更新がコードの他の部分を壊さないようにするのに役立ちます。展開のパイプラインの標準化をサポートし、インフラストラクチャと環境の構築とプロビジョニングに費やす時間を削減することができます。これにより開発者は何がユーザーと顧客にとって本当に必要なのかを探ることに時間を使うことができます。

 政府がオープンソースソフトウェアへのIT投資の効果を最大限に高めることを考えている場合、ビジネスプロセス特有のコードを分けておくとわかりやすいです。例えば、データやワークフロー、インタラクションコンポーネントやデータベース、ホスティングリソースなどです。これらビジネスプロセス特有の要件はほぼ確実にカスタマイズする必要があります。しかし、コンポーネントと開発者のリソースを相互に活用することは共同投資と再利用の恩恵をもたらします。

 再利用可能な18Fプロジェクトは以前のブログ記事を参照してください。詳細を知りたい場合は、公開Slackチャンネル#opensource-publicに参加して、GitHubプロフィールをチェックしてください。

解説

この記事は米連邦政府一般調達局、テクノロジー・トランスフォーメーション・サービス(TTS)の一部門である18Fに所属するイノベーションスペシャリストのLaura Gerhardt氏によるブログ記事"How reusable is open source software?"の翻訳です。

前回『大規模デザインシステムを作る:いかにしてアメリカ連邦政府のデザインシステムを作り上げたか』はデザイン標準の話でしたが、今回はオープンソースを使った開発の取り組み方に関してです。デザインチームと開発チームが18Fという一つの部署にいるのは大きな強みですよね。

SlackとかGithubとかバリバリ使ってるのが単純にかっこいいなあ。

カタパルトスープレックスなかむらかずや

関連記事