タグ: 開発

原文：”A GDS Story 2014“

2010/2011年｜2012年｜2013年｜2014年｜2015年

1月13日

デザイン融合チームがチェックリストを発表:

このチェックリストはオンラインでサービスを提供するどのような組織でも役に立つように意図しています。これらのチェックリストを満たしていればデジタルサービスはだれでもオンラインに対応できるよう融合している状態になっていることになります。

1月23日

身分証明プログラムベータ

　Janet Hughesが身分証明プログラムについて詳細に説明。身分証明プロバイダー（のちに認定会社に呼称を変えた）の役割など。

1月24日

政府が新しいITの契約ルールについて発表。これはGDSの支出管理の必須要綱ともなる。概要は以下の通り:

• 1億ポンド以上のIT契約は特別な必要性がない限り承認されない。契約の規模を小さくすることでより多くのサービス提供者の参入と競争を促進する。
• サービスのプロビジョニングを提供した会社は、プロビジョニングをしたシステムの構築契約はできない。
• 契約の自動延長はない。完全なビジネスケースがない限り契約は延長しない。
• 2年以上の新たなホスティング契約は結ばない。

Francis Maudeは以下のように書いています:

この明確な線引きにより政府は最良の技術を最良の価格で調達することができる。私たちは納税者の価値のため、恥ずかしげもなく軍隊のような厳格さで適用する。

1月27日

James StewartがGDSでのGitとGitHubの利用について書く。

1月29日

　GDSがロンドンで“200日のデリバリー、さらなる200日”と銘打ってSprint 14を開催。ビデオも作りました。

www.youtube.com

Mike Brackenが以下のように要約:

• トランスフォーメーションプロジェクトはすべて発見のため。
• 4つのベータプロジェクトはすでに10万人に利用された
• 政府をトランスフォーメーションするのに残り200日

(More photos)

1月30日

　ロンドンでSprint GOイベントを開催。政府機関と関連部署がGOV.UKへの移行のため。

(More photos)

2月3日

　政府の公式文書がwww.official-documents.gov.uk (イギリス国立公文書館が管理)からGOV.UKへ移行。

2月6日

デザイナーのGuy MoorhouseがモバイルデバイスでのGOV.UKの改善について解説。

2月11日

身分証明プロジェクトがHMRCのユーザーに対してベータ移行。

12 February

York男爵がGDSを訪問。

2月18日

　GDSが政府のデザイナーに新しいガイドを発表：デザインスタイルガイドとデザインパターンハックパッド。

2月21日

Tom LoosemoreがRenew tax discサービスをリリースしたDVLAを祝福: “敬礼！“

2月25日

GDSが #contentdesignweek を祝う。

2月27日

Neil WilliamsがGOV.UKの進捗をまとめる： “第三フェーズが進行中”

3月

はじめてGOV.UKに単月で5000万人が訪問。

3月2日

読者に誤解を招くWebサイトを報告してもらうようお願いする。一週間後、Ade AdewunmiがGOV.UKからたどり着くサイトでもOKと書く：

もしちょっとしたカラースキームやレイアウトの違いがあってもGOV.UKからリンクされているサイトはすべて大丈夫です。オンライン広告や一般的なGoogleやBingといった検索に限りません。必要以上にサービスに対価を支払ってるかもしれませんし、全くなにもないサービスに支払ってるかもしれません。また、信用できないサイトに個人情報を提供しているかもしれません。

3月5日

　GOV.UKのヘッダーで使われていたタイプフェースをGill Sans からNew Transportに変更。

3月12日

Digital Marketplaceのアルファがスタート。

3月17日

3月18日

　GOV.UK Tax Disc *1 “thank you”ページの変更の結果、35万人の臓器提供者の登録が増加しました。

同日、GDSが正式にCTO室を設置。Alex Holmesが書いています：

私たちは政府の技術でリードをとっています。何をするのかを指示するのではなく、自らのエキスパートチームを作り上げ、正しく行うことを支援します。私たちは以前の必要以上に複雑な政府のITガバナンスをより簡単でシンプルなモデルを構築しました。

3月26日

GDSが最初のSocial Media Playbookを発行。

同日、ライターでコメンテーターのClay ShirkyがGDSを訪問。

3月28日

GOV.UKが新しいインフラに誰にも気づかれずに移行。これはとてもいいこと。

4月1日

　サービス標準が完全にライブ。Tom Scottが最初の50のサービス評価からのフィードバックを通じてどのようにイタレーションをしたかを解説。

4月6日

Public Services Network (PSN) がCTO室内でGDSの一部となる。Andy Bealeが説明をしています：

PSNはネットワークのネットワークです。公共セクターの組織が安全で効率的につながることができます。これにより過去の分離した繋がないネットワークのような複雑さや重複を避けことができます。

4月14日

デジタル融合戦略とデジタル融合憲章の設立。Kathy Settleが書いています：

これは政府が初めてデジタル分離の問題を解決するためにパートナーを集める取り組みです。とても興奮する時期です。私たちはいいアイデアのスケールアップを望んでいます。重複をやめ、人々が簡単に働けるようにしたいと考えます。。

　この仕事の一部としてスケールするデジタル融合があります。各官公庁がユーザーのデジタル融合のニーズを評価することができます

4月23日

　運転免許試験局のMartin RichardsonがInside Governmentのブログに寄稿。たった一文字の変更が600%のクリックスルー増加したことを説明。

5月13日

　Performance Platform上で83にダッシュボードを一日でリリース。

5月22日

　Ben Terrettがスケッチでデザインすることについて解説。

5月23日

　各省庁と政府機関がGOV.UKでのコンテンツのパフォーマンスを確認できるダッシュボードをリリース。

5月29日

　永続的代理権 (Lasting Power of Attorney)がトランスフォーメーションプロジェクトの中ではじめてベータからライブに移行。

　同日、ユーザーリサーチの責任者Leisa Reichelt ユーザーリサーチをどのようにアジャイルでやるヒントを公開。

6月3日

Leisa Reichelt「ユーザーリサーチとユーザーテストは違います。テストされているのはユーザーではなく私たちです。それは良いことです」

6月10日

　Register to Voteが公開。トランスフォーメーションプロジェクトがまた成功。

6月12日

　新しいユーザーリサーチラボを公開。

6月20日

Pete HerlihyがRegister to Voteに働きかけつつ、現状の打破に関する完璧なブログ記事を書く：

今後の法律のドラフトを書くときに私たちとサービスデリバリーチームが共に働くことに関してリーガルチームから合意を得た。これは本当に特別なこと。

6月26日

　身分証明プログラムのベータが新しいサービスを追加：DVLA’s View Driving Record

7月3日

Mike Brackenによる最初の長く詳細なブログ記事。ここでは「サービス変革」の定義について：

私たちが「変革 | Transformation」について語るとき、それを可能にするハードやソフトについてグダグダ言っているわけではありません。私たちはユーザーが望むときに望むサービスを提供するために全体のサービスのことを考え、複数の専門性を併せ持ったチームの力でユーザー体験を変革します。変革とはより良い体験を提供すること、真に生活をよい方向に変えることです。

7月14日

　デザイナーのJoe LanmanがRegister to Voteをデザインしたことからの学びについて書く。

7月15日

　GOV.UKは階層リスト（Miller columns）を使ったナビゲーションの改善を模索。

7月18日

Ben TerrettによるGDSのデザインプロセスの解説：

私たちはワイヤーフレームやPhotoshopのモックアップを作りません。私たちは「デザインが終わったら開発の仕事」のような文化にしたくありません。私たちはハイフィデリティのモックアップもワイヤーフレームも作りません。私たちはモノを作ります。モノのイメージではありません。

7月22日

　Digital Marketplaceがプラベートベータに。

　同日、政府がドキュメントの閲覧と共有にオープンスタンダードを採用。Linda Humphriesによる解説がこちら。

7月28日

Mike Bracken が司法省チームが民事請求のサービス更新の仕事について：

今は2014年です。私たちはビクトリア風の公共サービスを運営すべきではありません。法律自体は数世紀前のものかもしれませんが、人々とコミュニケーションをする言葉はそうあるべきではありません。

 

同日、Tony SingletonがG-Cloudの順調な成長について書く。この月2億ポンドの売り上げ。

8月5日

司法省の民事請求サービスがライブ公開。

8月6日

　内閣府の効率と改革グループの設立者でありGDSの強力な支援者だったStephen Kellyが商業セクターでの新しい役割を引き受けるために政府を去る。Mike Brackenのコメント。

本議会を通じてStephenはGDSと政府のデジタル化全てにおいての確固とした支援者でありチャンピオンでした。彼は大臣へのアクセスを確保してくれ、イベントで講演してくれ、様々な障害を取り除いてくれました。そして何よりも常にポジティブな世界観を持っていました。これが私が一番必要とするものでした。

8月12日

　Performance Platformチームが新しいプロトタイプページについて解説。

8月14日

　デベロッパーのAlice BartletがGOV.UKでの検索のアクセシビリティ改善について。

8月16日

雑誌『エコノミスト』が新しいユーザーリサーチラボについて記事を書く。

GDSは商業セクターでは自然に起きるデジタルのしなやかさを政府に持ち込もうとしている。もし企業がダメなWebサイトを持っていたり、そもそもデジタルを全く無視したら、顧客はどこかへ去っていく。福祉から運転免許証まで独占的な公共サービスの提供者である国家はそのサービスのオンライン化のモチベーションを内部から起こす必要がある。

8月19日

　若い才能を政府に参加してもらうために新しいDigital and Technology Fast Streamの立ち上げ。

8月20日

　トランスフォーメーションプロジェクトの一つ特許更新がライブ公開。

9月5日

Olivia Nealがサービス標準のアップデートについて：

今年の4月からサービス標準は26ポイントで評価をしてきました。サービスはアルファ、ベータ、ライブステージにおいて評価されます。これまで27のアセスメント評価を行い、それぞれ4人から5人のGDSのアセッサーから構成されるパネルで評価されます。では、最初の5ヶ月での評価はどうだったでしょうか？評価をパスしたのは70%で想定どおりでした。トランスフォーメーションプロジェクトはそうでないプログラムより高い確率でパスしました。

9月10日

　Web運用エンジニアのBob WalkerがGOV.UKで「デプロイの穴熊」によるアプリケーションリリースのコントロールについて解説。

9月15日

　トランスフォーメーションプロジェクトの刑務所訪問予約がライブ公開。

9月17日

　身分証明プログラムがGOV.UK Verifyとなる。そして、プライベートベータからパブリックベータへの移行計画が発表される。Janet Hughesのコメント。

私たちはユーザーリサーチプログラムを続け、ラボと大規模な質的リサーチの学びからサービスの構築と改善を続けます。私たちは多くを学び、UIデザインなど多くを改善しました。名前も変えました。サービスをどのように説明したらいいかユーザーとテストしてみました。そしてGOV.UK Verifyがそれ以外の名前よりも理解しやすいことを学びました。パブリックベータではこの名前を使います。

　同日、Ben Hollidayがユーザーリサーチとデータがどのように公開されているサービスを改善するか6つの事例を紹介。

9月23日

　Mike Bracken が新しい見習いトレーニングサービスのベータについて。

見習いトレーニングチームはよくやりました！全く正しいことを行なっています。これが私たちが当初からイメージしていた変革プロセスで、実際にそれが実現していることをうれしく思います。たった3年前はこのような急激なサービスのデザインの変更は無理だと言われていました。

10月7日

　DVLAの運転免許証閲覧サービスがベータからライブ公開。

10月9日

Anna Wojnarowskaが内閣府CTOトランスフォーメーションプロジェクトでのユーザーリサーチについて解説。

10月10日

　ユーザーリサーチはチームスポーツ。

10月14日

　GOV.UK Verifyがパブリックベータに移行。

10月17日

　GOV.UKが二歳の誕生日を迎える

11月6日

　Digital MarketplaceがCloudStoreから完全移行してG-Cloudのクラウドベースのソリューションを購入する唯一の窓口となる。内閣府担当大臣のFrancis MaudeがサービスマネージャーのIvanka Majicの助けを借りながら自分で新しいデジタルサービスを試してみる。

11月13日

　ユーザーリサーチャーのPete GaleがGOV.UK Verifyがパブリックベータへ移行するにあたった変更点を紹介。

6月にユーザーのジャーニー全体を見直すことにして、ボードに描きなおしました。これまでの経験と学びを活かしつつクリーンな状態からはじめることで、シンプルな質問から適切な提案までのデザインを洗練することができました。

11月25日

　Ivanka MajicがG-Cloud、CloudStoreとDigital Marketplaceの歴史を振り返る。

11月26日

　内務省のChris Athertonが翻訳のためのデザインについて書く。

11月27日

　イギリス政府がWorld Wide Web Consortium (W3C)のメンバーとなる。

11月28日

　トランスフォーメーションプロジェクトの求職支援サービスがライブ公開。

　このプロジェクトに関わったGDSメンバーのSteve Woodのコメント。

プレストンの求職支援チームは単に紙をデジタル化にする以上のことをしました。ユーザーリサーチを行い、申し込みプロセスの深い部分まで探り、170の質問事項を取り除きました。これは全体の49%にあたります。求職者は時間があまりないため、これはとても重要なことです。実際にサービスパフォーマンスのデータでは朝の短い時間に利用のスパイクが現れます。

12月3日

　Kate Towseyがリサーチラボの最初の6ヶ月について報告。25%コストダウンで2ヶ月のうちに予約でいっぱい。

12月9日

　GDSがロンドンにて最初のD5*2ミーティングを開催。内閣府大臣のFrancis Maudeがスピーチ。

公共セクターでは過度のリスク回避の傾向があります。人々は何も新しいことができないと感じています。政府はいいアイデアを見つけ、できない理由を探すことが得意です。現状に対して同じような綿密な調査をしません。私たちはより良い新しいやり方を探すため人々に実験してリスクをとることを奨励しなければいけません。たとえそれが常にうまくいかなくてもです。最も大きな過ちは試さないこと、動かないことに固執することです。

　Liam Maxwellは以下のように書いています。

D5の目的は世界的な協力体制です。私たちは常にオープンに自分たちの仕事を共有することについて話し合っており、D5はそれを対面で簡単に行うことができます。議論のプラットフォームとなり、お互いを助け合うことができます。私たちは実際的な問題に実際的な解決方法を強調します。

12月11日

　Performance Platformチームがダッシュボードのフルスクリーンモードを実験。

12月15日

　Liam Maxwellが「韓国から学べること」と政府の技術における2010年から2014年にかけてのサプライチェーンの変化について書く。

12月17日

　Mike BrackenがDVLAを訪問。その時の彼の考え。

DVLAは素晴らしい仕事をしています。Webサイトを直し、技術をアップデートし、ユーザー中心のアプローチをするために組織全体を見直しています。これが「変革」でないのであれば、何が変革なのか私にはわかりません。私は本当に感銘を受けています。私が言えるのは「素晴らしい」だけです。DVLAはデジタル政府の申し子です。

12月19日

　トランジションプロジェクトの完了。300の政府機関とその関連組織のWebサイトをGOV.UKに移行完了。Mark Hazelbyのコメント。

私たちのトレーニングチームの例を取りましょう。もし、このプロジェクトの前にGoogleで”climate change uk”と検索したら16の政府系のWebサイトが検索結果として表示されていました。そして、今ではGOV.UKの政策とトピックのページが一番に表示されます。これは市民にとってとても強力です。豊富な政府のコンテンツの中から最適な情報にすぐにアクセスできます。

このプロジェクトのハイライトとなる数字：

• 312の政府機関と組織
• 685のドメインとサブドメインを閉鎖
• 150,000ページ以上をGOV.UKで公開
• 1,200人のスタッフが平坦な英語で書くトレーニングを受ける

12月23日

　GOV.UK Verifyを英国歳入税関庁の確定申告サービスの少数ユーザーでトライアルを実施することを発表。

関連記事

原文：”Wechat Mini Program Part I: What Is It and Why Is It Significant?” by Yelin Qiu

　1月9日にラスベガスでCESが行われていたころ、8億4千万ユーザーを誇る中国の微信（WeChat）がミニプログラムを立ち上げました。ミニプログラムは微信に組み込まれダウンロードもインストールも必要がありません。（技術的には「ミニアプリ」といったほうがいいのですが、Appleが許可しなかったというのがもっぱらの噂）

　これは非常に大きなニュースで、太平洋を越えてアメリカ西海岸のGoogle、AppleやFacebookに寒気を起こさせるのに十分でした。想像してみてください。それほど使わないアプリをダウンロードしなくても済むとしたら？すべてのサービスを一つのアプリから必要な時だけ使えるとしたら？どれだけの時間を節約できて、どれだけスマホの画面が整理されるか。画面が大きく変わるためにスマートフォンのデザインすら変えてしまう可能性は？この微信の最新の動きはApp Storeに大きな一撃を加える可能性があります。そして親会社の2400億ドル（26兆円）の時価総額を誇る騰訊（Tencent）にとって、ミニプログラムはさらに大きな賭けに出る最初の一歩にすぎません。

　微信の熱心なユーザーであり、中国のテックシーンを追いかけている身として、どうしてミニプログラムの立ち上げがそれほど重要なのかを解説したいと思います。

微信の万里の長城

　ミニプログラムによりユーザーはApp Storeからダウンロードすることなく機能を使えることができるようになります。ユーザーは微信に用意された新しいパネル、Facebookのニュースフィードにちかいところからアクセスすることができます。

　アンドロイドではホームスクリーンにミニプログラムのアイコンを普通のアプリのように置くこともできます。

　Facebookと同様に、微信はソーシャル以外のユーザーの時間を占有しようとしています。ただ一日か一週間に一回くらいデリバリーを頼んだりUberを使うみたいな一時的な利用のために、わざわざアプリをダウンロードしないといけないのか？それくらいのことなら容量も食わないしホームスクリーンを散らかす必要のないライトなミニプログラムでいいんじゃない？

これにより微信はOSのなかのOSになる。他のサービスをいろいろと利用できるたった一つのアプリ — WSJ

　微信はユーザーが微信からもっとサービスにアクセスするだろうし、それを気にいると考えている。万里の長城に囲まれた庭園を造り、できる限りその庭園にユーザーに居てもらいたいと。

サービスかコンテントか

　個人と企業はそれぞれ微信を通じてユーザーと接することなるやり方がある。サービスアカウント (服务号)かサブスクリプションアカウント (订阅号)の二つ。違いに関してはいろいろと議論がされているが、大まかには以下のようになる。

　微信はサービスアカウントもサブスクリプションアカウントも同様に補完するサービスが生まれつつあり、健康的なエコシステムにより成長していることに気が付いています。

　しかし、サブスクリプションアカウントはサービスアカウントに比べてユーザーエンゲージメントの観点で遅れがみられます。サービスアカウントは騰訊にとってはB2Bへの進出の糸口となるため非常に重要です。ミニプログラムはサービスアカウントのエンゲージメントとサービス品質の向上のために立ち上げられました。

すべてとつながる

　サービスアカウントではできず、ミニプログラムでできるようになったことはなんでしょうか？それは現実世界とつながることです。

　ユーザーは現実世界で必要な時に必要なアプリを取り出せばいい。使いたい時だけ。ダウンロードもインストールも必要ない。なんか聞いたことありますよね？GoogleのInstant Appsは同じ目的を持っていますが、まだ実現していません。

一般に向けたスピーチで、微信の開発者で創業者の张小龙（Allen Zhang）はミニプログラムの例を二つあげました。

• バス停にいる時、バス停のQRコードをスキャンしてバスの到着時刻を知る
• 長距離バスのバス停で、QRコードをスキャンしてバスのチケットを購入。チケット売り場でわざわざ並ぶ必要なし。

　この現実社会とのコネクションは騰訊のビジョンにとって非常に重要な柱となりつつあります。人と人をつなぐ、人とサービス、人とビジネス、人とモノをつなぐ。

　微信は間違いなく最初の三つにこれまで注力してきました。まだ「人とモノ」に関しては完全には実現していません。

　多くの企業は組込チップやIOTのようなモノやARやVRを使ってモノとデバイスを繋げてきました。

　そして、多くの場合はハードの制約にハマることになりました。しかし、中国では別のやり方で「人とモノ」を繋げることが流行りました。それがQRコードです。

　QRコードは現代の中国においてはどこにでもあります。QRコードを使って支払いをしたり、広告を見たり、そのほかのサービスにアクセスすることに慣れています。QRコードをサービスに関連するモノに取り付けるのは多少のコストと労力がかかります。スキャンしてブランドや価格を知る、バスをスキャンして路線を知る、サインをスキャンして方角を知る。中国でインターネットの潮流は独自の方向へ進んでいます。QRコードはデジタルとリアルのハイパーリンクとして機能しています。

　QRコードの裏側にあるのは具体的な情報やサービスで、微信はミニプログラムによってこれらのサービスに効率的にアクセスできるようにしています。微信にとってミニプログラムはQRコードをさらに普及させ、デジタルとリアルの関係を強化できるかもしれません。

本当のターゲット：オフラインとソーシャル

　ミニプログラムにはあまり直感的ではない（しかし意図的な）機能があります。ユーザーはミニプログラムをモーメント（タイムライン）ができず、スマホに保存されたQRコードでミニプログラムにアクセスすることもできません。

　ユーザーは三つの方法でしかミニプログラムにアクセスできません。

• リアルな世界でQRコードをスキャンする
• 検索（あいまい検索ではなく）
• チャットで直接共有

　最初の方法はオンラインとオンラインのトラフィックの抑制を意味しています。意図的にオンラインのトラフィックを抑制することでオフラインの価値が高まります。微信はプロダクト開発者とサービス提供者がオフラインからのトラフィックに集中させることによってオフラインへの野心を明確にしています。

　最後のポイントは微信がもつソーシャルのビジネス的な可能性を解き放つ意図があります。特にグループチャットの産業別コミュニティー。

　オフラインとソーシャルの可能性をそれぞれ見ていきましょう。

オフラインの可能性を解き放つ

　毎日どれくらいスマホの画面を眺めているでしょう。16時間起きていて、そのうち2時間だとします。その2時間のうちの3/4がソーシャルアプリだとしましょう。つまり50くらいスマホに入っている残りのアプリは毎日残された30分のために競争をしていることになります。平均すれば一日36秒ということになります。

　AppStoreでの過酷な競争を勝ち抜いてホームスクリーンでの場所を獲得したアプリもそれほどのアテンションを獲得できるわけではありません。開発者やサービス提供者にとってこれはあまりいい賭けではありません。

　オンラインのトラフィックの獲得が困難になってきたことで、微信は「ちょっと待て、スクリーンを見ていない残りの14時間はどうよ？」と考えたのでしょう。

　オフラインの14時間は具体的なコンテキストがあります。レストランで食事をしていたり、空港に着いたり、ホテルにチェックインしたり。これらのコンテキストではスマホに時間を独占されていませんし、ここに可能性があります。

　例えば空港に到着した時に航空会社特有のQRコードがあったとします。そしてそれをスキャンすることでチェックインのためのミニプログラムを立ち上げることができます。このチェックインアプリは本来オフラインでチェックインしていたであろう時間を切り取ることとなります。アプリを具体的なコンテキストで使うことは、それ以外でのコンテキストで使うよりも可能性として高くなります。またASO（アプリ版のSEO）につぎ込むか金額を考えれば、ユーザー獲得コストは小さなものです。QRコードをプリントしてオフラインの場所に設置するだけ。

　オフラインのコンテキストはたくさんあります。微信は開発者とユーザーにこの可能性を解き放つよう促しています。

ソーシャルの可能性を解き放つ

　微信はグループチャットが価値のあるビジネスコンテキストだと理解しています。産業別のコミュニティーが集まり、友達同士でオススメをしたり、サービスにすぐにアクセスする場所です。

　例えば友達同士で旅をすることをグループチャットで話していたとします。サービスまでのジャーニーはこんな感じです。

1. メンバーの意見をまとめるリーダーを選ぶ
2. トラベルアプリをダウンロードして予約する（色々と調べながら予約）
3. グループに予約を説明

　ミニプログラムでのジャーニーはこのように変化します。

1. メンバーがトラベルミニプログラムをチャットに送る
2. メンバーが同時に色々調べてコメント
3. メンバーが決めた旅行先をそれぞれ予約

　ミニプログラムはチャットで全てを完了することによりサービスとユーザーのジャーニーを短くします。つまりソーシャルのコンテキストでユーザー獲得とコンバージョンのスピードが増します。そのビジネスの可能性を考えればFacebookのMessengerが同じことを考えてもおかしくないですよね！

ミニプログラム：未来への扉

　ミニプログラムは騰訊（Tencent）が微信のソーシャル帝国を守るための壁だと考える人もいるでしょう。しかし、それは隠されていることでもなく、テック企業ではよくあることです。.

　微信のミニプログラムは私たちに次世代のプロダクトとサービスのあり方を見せてくれています。

• ユーザー獲得コストが低く、利用率／リピート率が高い具体的なオフラインコンテキストに基づいていること
• ジャーニーを短くでき、トラクションが高くなるようなソーシャル／産業コミュニティー

　ミニプログラムがあろうとなかろうと、微信は自らが進む方向に全力疾走していくことでしょう。ユーザーの一人としてその発展を見守っていきたいと思います。

関連記事

原文：”A GDS Story 2013“

2010/2011年｜2012年｜2013年｜2014年｜2015年

2013

1月6日

　Mike Brackenがこれまでのデリバリータイムラインを解説しました。

1月13日

　トランザクションエクスプローラツールは「政府が市民に提供する特に大きな44の公共サービスにおける1トランザクションあたりのコストに関するデータ」を含むように更新されました。当時の内閣府のFrancis Maude大臣は以下のようにブログで書いています

このデータを公開することは透明性の大きな前進です。英国政府にとって初の試みです。

1月15日

1月20日

　GDSはロンドンでSprint 13を開催しました。政府のデジタル改革にフォーカスをあてたイベントで、これが第一回となり毎年行うことになります。Francis Maudeは2年間かけて行う改革プログラムを発表しました。これは特に大きな25公共サービスを更新するプログラムで、のちに手本となるプロジェクトとして知られるようになります。

　その翌日に写真が公開されました。当時の最高経営責任者（CEO）だったStephen Kellyは「政府を改革する400日」を発表しました。（写真）

Sprint 13 Overview

1月31日

　司法省のRoger OldhamがMoJ Digitalの前身となるチームのためにGDSブログを通じて採用を呼びかけました。これはポジティブな前進でした。内閣府のモデルを通じて官公庁も同じことができる例を示しました。

2月22日

　Abby PeelはGDSを訪問する国際的な訪問者を歓迎することについて書きました。

2月28日

　Neil Williamsは前年度の初期ベータ版に入って以来はじめてInside Governmentの変更について書きました。

私たちが作り上げているものはワールドクラスというだけではありません。ワールドファーストです。ニュージーランド、クロアチア、スウェーデン、ノルウェーの各国政府がデザインからコードベース全体まで、私たちが作ったものを再利用してくれる予定です。

3月1日

歳入税関庁のコンテンツをGOV.UKへ移行することについて同庁のRobin Rileyが解説しました：

歳入税関庁はそのほかの官公庁と比べて長い時間がかかりました。どうして？ 率直に言えば私たちは一番後方に位置していました。歳入税関庁サイトの違いを比べてみてください（現在／過去）。違いは劇的です。単なるお化粧直しではありません。歳入税関庁は情報をオンラインで公開する方法を再設計しました。

3月12日

　Tom Loosemoreは政府にアプリの開発をやめるように呼びかけました。私たちはアプリっぽくない。

アプリはゲームやソーシャルメディアを変えているかもしれません。しかし、公共サービスをWebサイトを通じてさまざまなデバイスで効率的に利用できるようにするアプローチの方が現在では最適と言えます。その方が改善のための実験を繰り返し簡単に行うことができます。市場インパクトを最小化して、サポートするのもはるかに安いです。

3月14日

Mike Brackenが政府全体のITガバナンスを大幅に変更したと発表し、CTOのLiam Maxwellがリードしてきたプロジェクトが表面に浮かび上がってきました：

私たちは予算を多く持っている人たちの間で行われる調達に関する議論を少なくするべきです。立席ではない立ちながらクイックに行うスタンドアップミーティングでユーザーニーズに応えるべく日々のリリースを増やすべきです。私たちはウェブ、デジタルツールとサービスを政府内で活用することによりもっと素早くコラボレーションができるようになります。

　要するに、Maxwellと彼のチームはこれまでの古い政府のITガバナンス体系を以下のように変えました。

…このように。

同日、GDSはデジタルが基本（Digital by Default）のサービススタンダードとサービスマニュアルのベータ版を公開しました：

このスタンダードは2014年4月よりすべての大規模サービスに適用されます。スタンダードのポイントはGOV.UKで公開されているすべてのサービスが利用者にとってわかりやすく便利なのでそれを好んで選択することを確かなものにすることです。そしてAssisted Digitalがオフラインで適切な支援をします。

　私たちは新しいマニュアルとともに映画シリーズも作りました。

Welcome to the Service Design Manual

3月20日

Francis Maudeの庶民院でのスピーチ：

私は紳士閣下がおっしゃることすべてのことに同意します。私たちがまだやっていないという彼の仮説を除いて。私は彼が優れた出版物を生み出したデザイン委員会のメンバーであることを知っています。実際にGDSの創設を含む、政府が取っているいくつかのイニシアティブについては非常に敬意を払ってくださっている。GDSは公共サービスの提供を改革する際に、ユーザーのニーズに合わせてデザインすることにコミットしています。これまで頻繁にそうであったように、政府の利便性を優先するのではなく。

（こちらがそのビデオ）

3月21日

Richard Popeはサービスマニュアルを作成する過程について書いています：

最初は私たちはマニュアルを作っていること意識していませんでした。やろうとしていたのは新しいデジタルサービスがどのような基準で判断されるのかを描くこと。政府のデジタル戦略で掲げられているデジタルが基本（デジタル・バイ・デフォルト）とは何か。官公庁のサービスオーナーとそのチームが優れたデジタルサービスを提供するのに役立つ豊富な詳細を提供する必要があることは認識していました。そして優れたデジタル公共サービスがどのようなものなのかシンプルな定義を共有する必要性を。

3月25日

　Inside Governmentに44の言語をサポートする新しいワールドワイドセクションが追加されました。これは、外務・英連邦省、国際開発省、貿易投資総省、国防省などの省庁にとって大きな一歩でした。

3月26日

　後のCommon Technology Servicesチームになる仕事の最初の公での発表。こちらがそのIT改革グループのTariq Rashidのブログ記事。

3月28日

　GOV.UKにおいて各省庁はあたらしいHTMLのフォーマットを使うことが推奨される。「HTMLがPDF / RTF / Word添付ファイルに代わるデフォルトとしてのデジタル」としてデザインされる。

4月16日

Mike Brackenのポスト：

…このマニュアルは過度な官僚的な考えから政府を解放するようにデザインされています。このブラウザベースのサービスは意思決定を加速し、多くの委員会や会議や扱いにくいプロセスの必要性を排除します。公共サービスがデジタル化されるにつれ、私たちが使用するツールとガバナンスにに反映されるべきです。

4月17日

　GOV.UKは「よく考え抜かれた控えめなデザイン」が認められ、この年のDesign of the Yearを受賞しました。

Daily Telegraphの評論家Deyan Sudjicのコメント：

これは政府が実際に有効なコミュニケーションを理解していることの表れです。シンプルで直接的で礼儀正しい。このような政府から当然受けたいと思っているすべてのことは官僚主義と専門用語の海に沈み、実際に実現されることはありませんでした。GOV.UKはエレガントでほのかな英国らしさがあります。これは1960年代にMargaret Calvertがデザインした古典的なフォントのデザインのおかげかもしれません。それはウェブサイトのポールスミスです。世界は深く感銘を受けています。複数の公共サイトを合理化したため、税金を大きく節約できます。嫌いになる理由がありますか？

　タイポグラファー／デザイナーのMargaret Calvertは上の写真（一番上の列、右から五番目）にいます。彼女は2011年以降、GDSデザインチームに不可欠なアドバイスを提供してきました。GOV.UKは彼女とJock Kinneirが作成したNew Transportフォントを使用します。

4月30日

イギリスにある24すべての省庁、No 10と副首相オフィスのサイトがGOV.UKへ移行しました：

…今日は政府と国民にとって新しい時代のはじまりです。私たちが仕事を正しく行えたのであれば、ほとんどの人はどれほどの大きな変化が起こったことに気付かないでしょう。しかし、プロジェクトを近くで見てきた私たちは、そのインパクトが深いものなのかを理解しています。これから国民（そして国民と政府を取り持つ専門家や仲介業者）は政府が何をしてこれから何をしようとしているのか全体を見渡すことができます。国内で、そして国外で。一つの場所に一貫性があり、整理された、簡単に理解できる形で情報が集まっています。

5月1日

　Tom LoosemoreがこれまでのGOV.UKの歴史を写真とともにまとめました。

5月17日

　GOV.UKの1,000 回目のリリース。

5月21日

　Liam Maxwellが新しいITガバナンスの形について概要を紹介しました。「プラットフォームとしての政府」についての最初の言及となりました：

ユーザーニーズに焦点を当てること、サービスをコモディティー化すること、組織の壁を破りサービスを共有することにより、私たちは納税者のためにコストを節約できます。更に技術革新により公共サービスの改善を後押しします。

5月30日

6月

　G-CloudはGDSに移行されました。これは後にDigital Marketplaceの大きな一部となります。

6月3日

　政府は「事業の基本的改革」により100億ポンドの節減したことを発表しました。 翌週にGDSは5億ポンド以上の貢献についてブログを掲載しました。また、支出をコントロールすることとTechnology Code of Practiceの重要性についても言及しました。

6月7日

　Richard Sergeantは最初のサービスの評価について発表しました。サービス基準にデジタルサービスがどれくらい達しているかを測るものです。

6月13日

　Neil Williams がトランジションツールについて説明しました。

6月18日

デザイナーのGuy MoorhouseGOV.UKで使われていたアイコンをどうして削除したのかを説明しました：

最初にアイコンを導入したときユーザーデータはありませんでした。そのため、推測として正しいことをするしかありませんでした。しかし、時間の経過と共に多くのユーザーテストを実施しました。そしてアイコンが意図した結果を達成していないことが明らかになりました。ユーザーはしばしばアイコンをクリックすれば「何か起きる」と勘違いしてしまいました。

　GDSではこのケースについてその後も言及し続けました。これこそまさに反復的改善の実例だからです。

7月2日

　典型的なプロジェクトの1つである”Lasting Power of Attorney”がパブリックベータに達しました。

　コンテンツデザインの責任者であるSarah Richardsが「私たちは2週間前に“黒い鉛筆”を手にしました」とブログで書いています。D&AD Black Pencilはデザインで最も賞賛される賞の1つです。それは最も特筆すべき作品だけ一年に一つか二つのプロジェクトしか受賞できません。何年か受賞者がいない年もありました。

7月9日

　最初のDigital Services Frameworkのローンチ。これも最終的にはDigital Marketplaceの一部になります。

7月17日

　Sprint AlphaのイベントでMike BrackenがTransformation Programmeのこれまでの進捗を報告しました。そして新しいダッシュボードであるgov.uk/transformationを発表しました。これにより誰でも発見＞アルファ＞ベータ＞ライブのステージを確認することができます。

Mike Beavenが翌日そのフォローアップをブログで書きました：

改革とはWebサイトではありません。全てです。一貫性があり質が高い「デジタル・バイ・デフォルト（デジタルが基本）」のビジネスプロセス全てです。

7月23日

　GOV.UKの見た目を若干アップデートしました。

　同じ日にGDSのチームと王室土地登記所が共同でアルファを公開しました。

7月25日

Sarah RichardsがFAQsを使わない理由を説明：遅すぎるし重複の原因となります。

7月26日

　ニュージーランド政府がGDSのデザインテンプレートを使った新しいWebサイトのベータ版のリリースを発表しました。

8月6日

　Tom LoosemoreがA/Bテストについて書きました。A/BテストがどのようにNHS Organ Donor Register（イギリスの臓器移植ネットワーク）のプロジェクトの助けとなったか：

このGOV.UKにおけるたった一つの小さな変更により臓器提供者が毎月一万人増えました。このたった一つのページはイギリスで三番目に大きな臓器移植の登録サイトです。

8月8日

　GOV.UKがどのようにデザインされているかを説明するブログ記事。これにより特定の組織や個人のページが削除されることはありません：

歴史的に見て政府のWebサイトは歴史家にとって簡単ではありませんでした。省庁や政府機関が政府の機械的な変更により閉鎖、統合、分割、改名されると全く削除されたり、完全に別のページになっていました。GOV.UKではすぐに使いやすいデータを提供し変更が理解できるようになります。後のために保存され、再利用されます。

9月1日

GDSがデザイン原則のポスターを作りました

（日本語版はカタパルトスープレックスデザインで入手できます）

9月4日

GOV.UKのブログプラットフォームのリリース。

9月20日

9月27日

Liam Maxwellによるオープンスタンダードの説明：

オープンスタンダードを選択して利用することは私たちのサービスをよくするだけでなく、サービス提供者の選択肢に柔軟性を与えます。火曜日に二つのユーザー課題を解決するために四つのオープンスタンダードを採用するようボードの提案がありました。

10月1日

数ヶ月の準備の後、最初の300の政府機関のWebサイトがGOV.UKへの移行を開始しました。これは「トランジション」プロジェクトの一部となります。

10月6日

GOV.UKチームによるナビゲーションの改善についての解説。

10月14日

　GOV.UKのローンチから一年が経過して、Tara Stockfordがモバイルからのアクセス増加に気がつく。

10月17日

　GOV.UK一歳の誕生日。Martha Lane Foxの訪問。当然ケーキあり。(More photos.)

データアナリストのPeter Jordanがデータの洞察について書く：「GOV.UKは一週間平均600万のユニークビジターがいる」

当時のGOV.UKの責任者James Thornettが一年の進捗について書く。

Mike BrackenがワシントンD.C.で開催されたCode for Americaサミットでスピーチ。

www.youtube.com

10月18日

　G-Cloudの売り上げが5000万ポンドを超える。

10月25日

　Lisa Scottが新しい内部ツールMaslowについて書く。ユーザーニーズを把握して、そのニーズがWebサイトであっているかパフォーマンスを追跡する。

10月29日

　GDSがCabinetに参加。iPadと大きなスクリーン。内閣府のメンバーが私たちの仕事を明確にわかるように望んだ。

Mike Brackenはのちにこう述べています：

とても励まされたのは大臣たちが私たちの仕事の背景にあるプリンシプルに共感してくれたことです。彼らの質問は全て一つの観点から発せられていました：これはユーザーにとってどんな意味があるのか？どのようにユーザーのニーズを満たすのか？です。ユーザーニーズから始めることは公共サービスを根本的に変える原動力となります。これは大きい。

10月30日

　Identity Assuranceチームがhubのベータ版をリリースしました。これはのちにGOV.UK Verifyとなる重要なコンポーネントの一つです:

The hubはユーザー、サービス提供者、公共サービス提供者の間のコミュニケーションを管理します。ユーザーはIDプロバイダーとして登録しているサービス提供者を選ぶことができ、デジタルサービスが利用できることようになります。

10月31日

Pete Herlihyがデジタル政府を作る上でGDSと関係が深いエストニアを訪問：

おそらくソビエト連邦からの独立のタイミング（1991年）もあって、エストニアは国を運営する上で技術を決定的な要素としてみていた。彼らはビジョンと決意を持った政治的にも公共的にも抜け目ないリーダーグループであり続け、技術の活用を積極的に活用する決意を持っている。

11月1日

Kathy Settleが各官公庁とのデジタル戦略の展開についてアップデートを書きました：

私たちは人事と採用に集中していました。そして正しくデジタルサービスを調達するフレームワークを作っていました。私たちはさらにデジタルを支援するためのリードの仕方、調整の仕方、技術の展開の仕方を変えました。CTO室は政府から参加したTechnology Leadersネットワークと共に戦略的な方向性とデジタルを展開する上でのベストプラクティスを推進しています。

11月6日

　韓国の未来創造科学部長官の崔文基がGDSを訪問し、Francis Maudeと対面しました。Liam Maxwellが韓国訪問について書いています。

　同日、GOV.UKチームは“When do the clocks change?”ページにおける“Test your smoke alarm”のリンクをテストしていました。Paul Cronkはその結果について書いています。

11月7日

　GDSはバーミンガムでのSprint Shareを開催しました。政府のトランスフォーメーションプロジェクトに関わる人たちにとって一同に集まり経験を共有する機会です。

www.youtube.com

11月12日

11月13日

内閣府Technology Transformation (COTT) プロジェクトの開始。Tom Readがこう書いています：

私たちの目的は少なくとも人々が普段家で使うのと同じくらいモダンで柔軟性の高いテクノロジーサービスの提供です。これらのサービスは現在のサービスよりコストが安くなります。

11月14日

　デザイナーのGuy Moorhouseがスタートページの進化について語っています。

11月28日

　後にDigital Marketplaceの一部となるDigital Services Storeが公開されました。

11月29日

Martha Lane Foxが「英国デジタルチャンピオン」を退任しました：

このブログをよく読んでくれている読者であれば私たちがよくMarthaのレポートに言及していることを知っているでしょう。それはGDSにとってどれだけ評価しても足りないくらいです。それは政府にGDSを招集する弾みをつけ、ワールドクラスの「デジタル・バイ・デフォルト（デジタルが基本）」のサービスを作るミッションと任務を与えました。

12月12日

　アナリストのAshraf ChohanがパフォーマンスチームによるGOV.UKのリアルタイムデータについて説明しました。

12月20日

　ローンチから500億人がGOV.UKに訪問しました。

関連記事

 

原文：”A GDS Story 2012“

2010/2011年｜2012年｜2013年｜2014年｜2015年

2012年

1月

1月19日

GOV.UKベータのデザインに関するブログ記事：

最初はうまくいかないでしょう。手探りで道を探しながら、地面に杭を指していくでしょう。うまくいきそうなアイデアをスケッチしていき、さまざまなソリューションをテストし、問題を解決する道筋を決める。これは巨大で複雑な作業です。

1月31日

　GOV.UKのパブリックベータ版がローンチされました。それは「私たちの最初の大きなプラットフォーム」と呼ばれました。

　チームはgov.uk/tourを作っていろんな人に見せました。ベータ版はwww.gov.ukで公開されていましたが「非公式」のままでした。まだwww.direct.gov.ukを置き換えていませんでした。移行作業は2012年10月までのかかるはずです。ベータユーザーはGet Satisfactionページからフィードバックを求められました。

　エンゲージメントチームはソーシャルメディアをモニターしました。フィードバックの有用な分析をまとめました。Sotryfulの概要も含めて。

　Tom LoosemoreとMartha Lane FoxがBBCのニュースでインタビューを受けました。

　ベータ公開その日のうちにチームはユーザーのフィードバックに基づいてベータ版を反復改善しました。次の日にはより多くのフィードバック、より多くの反復改善。このような改善作業をひたすら続けました。

　この頃、GDSのメンバーは急速に増えます。Directgovの移行期日までわずか数カ月で、チームはより多くの人手を必要としました。

2月

　必然的に問題がたくさんありました。ベータユーザーは彼らが問題をフィードバックし、チームはそれを修正しました。この場合、火曜日のイースターがベータでは月曜日となっていました。

2月1日

　一般市民からのGOV.UKに最初のプルリクエスト（Github）。Matthew SomervilleはBank Holidaysページの間違いをフィードバックしました（スコットランドのBank Holidaysの間違った日にち）

2月7日

　GDSとGOV.UKのブランドアイデンティティを生み出す – GOV.UKを全て大文字で表現したのがこれが初めて。これ以来ずっとこのように表現しました。

GOV.UKのための斬新なロゴやアイデンティティはありません。これは時間とお金の節約でもあります。またGOV.UKが覚えてもらいたいURLだということもあります。単純にGOV.UKが必要な場所であること。新しい名前やアイデンティティーを発見または理解する必要はありません。しかし、名前を実際のアイデンティティーとするには（あるいは、オフィスで「何か」と言っているように）、常に大文字とすることに決めました。このようなことに多くの時間を費やしていると思われますが、私たちは約10分間でそれを決めました。

2月10日

　Mike Bracken、Francis Maude、Liam Maxwell（当時内閣府のIT改革グループで働いていた）はシリコンバレーのコンタクトを訪問しました。企業と公共部門の連携について視察しました。

2月28日

　gov.uk/government内でInside Governmentのローンチ。

　これはチームの構成と考え方が反映されています。GOV.UKの作業は「主流」と「Inside Government」という2つのプロジェクトと2つのチームに分かれていました。

「メインストリーム」は市民向けのサイトでユーザーニーズに直接対応するもの。

「Inside Government」はそれぞれの官公庁の旧来のページと似ていて、その省庁の仕事と役割について説明していました。

　このブログ記事のコメントは興味深いです。公開された翌日、誰かがアクセシビリティが貧弱だとコメントしました。数時間後チームはそれを改善するために変更を加えました。

　Neil Williamsはブログ記事を書き、Inside Governmentの「ガイド付きツアー」を紹介しました。

　そのブログ記事にある画像の1つはすべての官公庁は同じようにシングルドメインで公開されることを指しています。

3月15日

Ben Terrett：

誰かがいくつかのペルソナポスターを貼って、私はそれに対して怒りました。全ての市民が私たちのユーザーで、いい見た目のペルソナなんかじゃない。私は紙に穴を開けて窓に貼りました。

3月23日

　Mike Brackenは2012年の予算に対応するブログ記事を書きました。彼は財務省からのこれらのコミットメントを強調しました：

 … 2014年から新しいオンラインサービスはそれに責任がある閣僚が自分自身でそのサービスを問題なく利用できることを実証できる場合にのみ公開することとします。また、2012年末までにすべての情報が「GOV.UK」シングルドメインのもとに公開され、2015年までにすべての手続きを「デフォルトでデジタル」アプローチに移行する予定です。

3月28日

　デジタルリーダーの第1回会合。多くの異なる官公庁から集まり、知識と経験を共有するグループ。

デジタルリーダーのRachel Neamanは次のように書いています：

部門内のデジタルは孤独な場所です。しばしばオタクやトレンディな若いものの特殊な場所とみなされています。そのため、真の変化をもたらすための政府機関をまたがるプロフェッショナルのネットワーク作りは遅れています。厄介な問題に取り組んでいる人たちがほかにもいるということはよい発見です。今日も明らかになったことは単純で簡単な解決策はないということです。

4月3日

　デザイン原則アルファ版の公表。Tom Loosemoreのコメント：

原則に従うことでチームは自律的に動くことができます。

　Head of Designのコメント：

デザイン原則がかつようされるにはシンプルで、明確で、役立ち、わかりやすくなければいけません。このデザイン原則が1ページのHTMLでまとめられ、各原則それぞれURLリンクを持っているのはそのためです。多くのデザイン原則は巨大なPDFファイルで読まれません。

　その頃、GOV.UKの開発者（Dafydd VaughanやMosely Melyを含む）数名がNumber 10 Downing Streetを訪れ、技術的な課題を検証しました。

4月30日

悪名高い出来事：Pete HerlihyはInside Governmentチームのアイスボックス（やらなければいけないけどまだ優先順位が付けられていないタスクリスト）を削除してしまいまい、多くの同僚を恐怖の底に突き落としました。

　彼はこの件についてこう書いています：

もしそれが重要なら覚えているはず。…ある時点で、アイスボックスは50ストーリー以上になっていたため、私は全体を削除することに決めました。バックログの信頼性の問題となるので、そうするしかありませんでした。私たちチームのマントラは「覚えているのなら重要」でした。このマントラに従うことで実際にかなり自由になりました。

5月14日

　Inside Governmentベータ終了。Ross Fergusonはそのフィードバック（いいのも悪いのも）について書きました。

5月25日

5月30日

　新しいAssisted Digitalチームの最初のブログ記事。デジタルスキルが高くない人たちが新しいデジタル公共サービスを使えるように支援する。

Rebecca Kemp がassisted digitalについて解説しています：

 Assisted Digitalはユーザーやサービスによって異なります。ユーザー自身がデジタルサービスを利用できるようになるためにインターネットが使えるように支援することかもしれませんし、デジタルサービスの利用のために支援してくれる場所の提供かもしれません。Assisted Dugitalはそれを必要とする人々のために電話または対面サービスを提供します。

6月26日

　Digital Performance Frameworkのアルファ版リリース。これは後にPerformance Platformの重要な部分となります。

　同じ日にChris Heathcoteは開発スピードに関してブログ記事を書きました。ユーザー中心の反復アプローチがどのように小さな変更を迅速かつ容易に行うことができるかを強調しました。

 これに続くのは正式な開発プロセスのスピードアップ版です。プロトタイプを作成し、フィードバックのためにチーム間で共有。改善されていることの確認、コードの変更、コンテンツエディタの変更点のチェック。カレンダーアプリの変更をプレビューサーバーにプッシュし、再びレビューされ、正式公開となります。これは一日で完了します。

7月2日

　GOV.UKの編集スタイルガイドのアルファ版を公開。Sarah Richardsは次のように書いています。

 スタイルとははっきりと、簡潔に、専門用語なしで書くことです。単純さはすべての人に恩恵をもたらします。これを「バカ扱い」とする人たちもいます。しかし、オープンで誰もがアクセスできるのは「バカ」なことではありません。私たちの責務です。

7月3日

　次のリリースの後、デザインチームはGOV.UKのタイポグラフィーの変更についてブログ記事を書きました。

7月11日

　Twitterアカウントを@govukから@gdsteamに変更。チームはGOV.UKとともに他のプロジェクトに取り組むために急速に拡大していたので、それに対応するための変更でした。Louise Kidneyは次のように書いています。

　私たちは成長、変化しました。私たちは私たちのスコープは@govukを越え、市民からの他のサービスについての問い合わせを受けています。現在の状況に対応するため、Twitterアカウントを@govukから@gdsteamに変更します。表面上はあまり大きな変更ではありませんが、私たちのルーツに立ち返った変更でもあります。

　開発チームがGOV.UKのアップデートをタイムラプスビデオにしたのがこちら。

7月18日

　フィードバックとユーザー調査の後、GOV.UKベータ版のフロントページにあるカルーセルが削除され、よりシンプルなテキストベースのリストに置き換えられました：

8月10日

　GDSは貿易関税（Trade Tariff）の改良バージョンをリリースしました。これは当時の重要なビジネスリンクの一部で、チームとしてもとても重要な成果でした。小規模の民間サプライヤーと協力して以前の成功しなかった試みをわずかなコストで完成できました。

8月24日

10月2日

「ホームページを大胆に刷新」 このリリースはブラウジングとナビゲーションの問題を解決しようとしました。

　翌日にブログ記事で解説しました。

10月4日

　当時の身分証明プログラム（Identity Assurance Programme：後にGOV.UK Verifyになる）は全国紙で報道されました。 Steve WreyfordはIDPチームの仕事を支える3つの原則についてブログに書きました。

10月9日

　Directgovからの移行期限が近づいてきたので、Etienne Pollardはこれまでの作業をまとめました。彼はGOV.UKのスコープの「これを満たした入れる」リストを含め、ユーザーニーズを中心に置くことについて書きました。

10月10日

　コンテンツデザイナーのPadma Gillenは市民のためのWebコンテンツと顧客のためのWebコンテンツの違いについてブログ記事を書きました。

政府と関わるのはそれが必要だからです。市民として必要な部分です。できるだけ早く簡単にしたい。そうすれば人生にとって有意義な部分に時間を使える。利益となる動機がないので、行動は変えたくない。

10月11日

　Paul DowneyはDirectgovからGOV.UKへの移行に関してチームがどのように「ひとつのリンクも取り残さない」ことをどのように確認したか解説しました。

10月16日

　2005年からDirectgovに取り組んでいるGraham Francisがその歴史をブログで振り返りました。

　当時の内閣府のFrancis MaudeがブログでGOV.UKの紹介をしました。開発チームはGOV.UKの構築に使用されたソフトウェアを公開しました。

Etienne Pollardは「ビジネス・リンクからすべてをコピーしただけではありません」と説明しました。

これはGOV.UKから「ベータ」ラベルを削除したコード変更です。

10月17日

　すごい日！ GOV.UKはベータからライブに移行し、正式にDirectgovとBusiness Linkを置き換えました。

　開発者のPaul Downey：「国のウェブサイトをローンチした。問題なし」とツィート。 Mike Brackenは「なぜこれは重要なのか」という。ブログ記事書きました。そして私たちは動画をアップしました。

　ケーキを食べました。 このケーキはGDSの伝統と言えるなにか。

10月18日

　Sarah Pragは最初の日の数字を書きました：909,706人のユニークユーザーの1,129,578回の訪問。

10月23日

　パフォーマンスプラットフォームのベータ版。

10月26日

開発者のJames WeinerがGDSを去るときにこれまでを簡単に振り帰りました：

おそらく、これまで働いたどの場所よりもGDSで学んだことは大きかったです。みんなが喜んでたみんなを助け合う。これはいい仕事ができる理由でもあります。お互いの意見や経験を尊重し、なおかつ建設的に批判をします。個人的な気まぐれではなく、使いやすいサービスを作ることを第一の目的としています。

同日、私たちはチームがアジャイルでスケールすることに関する学びについてブログ記事を書きました：

私たちは、本、ブログ記事、専門家がいう通り、より少ない作業をすることにコミットするべきでした。

11月2日

開発者のGareth Rushgroveによる定期的なリリースによるリスク削減について：

小さなカタマリを定期的にリリースすることで、何が変更されるのかがはるかに分かりやすくなります。何か問題が生じた場合は、そのカタマリを元に戻して、無かったことにする方がずっと簡単です。

11月6日

　Government Digital StrategyとDigital Efficiency Reportの発表。

　この戦略には「可能な限り意味があり測定可能なアクション」のリストが含まれています。

1. 官公庁および公共サービスに関わる行政機関のボードメンバーには活発なデジタルリーダーを含むこと
2. 年間10万件以上のトランザクションを処理する公共サービスは経験豊富な権限のあるサービスマネージャーによって再設計、実行、改善すること
3. すべての官公庁は人材を含め組織内に適切なデジタル機能があることを確実にする
4. 内閣府は官公庁のデジタル機能の向上を支援する
5. すべての官公庁は年間10万件以上を処理するサービスを再設計する
6. 2014年4月以降、新しいまたは再設計されるすべての公共サービスはデジタルを基本とする(Digital by Default)
7. 2013年3月までに24全ての官公庁のパブリッシングはGOV.UKに移管し、2014年7月までに関連政府機関や外郭団体のオンラインパブリッシングを移管する
8. 官公庁はデジタルサービスの意識を高め、より多くの人々に周知、利用促進をする
9. デジタルを活用支援するための政府間のアプローチを行う。オンラインを使ったことがない、ほとんど使わない人たちのためにオフラインでもアクセスできるサービスを提供したりデジタルを利用できる支援を行う。
10. 内閣府はより軽量な入札プロセスを提供。規制要件が許す限り、業界でのベストプラクティスに近いレベルまで絞りこむ。
11. 内閣府は次世代デジタルサービスの基盤となる新しい共通プラットフォームの定義と提供をリードします
12. 内閣府は各省庁と継続的に協力し、便利なデジタルサービスの開発を不必要に妨げる立法上の障壁を取り除く
13. 各省庁は内閣府が定める公共サービスのための一貫した管理情報を提供する
14. 政策チームはデジタルツールと技術を駆使して一般の人々と関わりを深め対話していく
15. 公共、営利団体および非営利団体など、セクターをまたがるパートナーと協力してオンラインサービスを人々に提供する協力関係を築く
16. オープンデータを推進することにより、公共以外の新しいサービス構築とユーザーへの情報提供の改善を支援する

　これらのアクションはGDSにとっての今後の業務範囲の定義となります。Digital Efficiency Reportはこれらのアクションの基礎となっています。

翌日、官僚のSir Bob Kerslakeは次のように書いています：

政府のデジタル化は幅広い利益をもたらします。政府のコスト削減と革新を推進し、国民にとって簡単で使いやすいサービスの提供を可能にします。私はデジタルが基本（Digital by default）を積極的に受け入れます。これはユーザーのニーズを満たすために行うべき正しいことというだけではなく、公共サービスに関わる人間にとって新しいやり方だからです。

11月7日

11月13日

　米国の仲間であるTim O’ReillyとJennifer PahlkaがGDSに初めて訪問*1。

11月15日

　Inside Governmentのローンチ。

　これは長い移行フェーズのはじまりでもあります。各省庁で管理されていた何百もの古いウェブサイトをGOV.UKに移行させました。

Inside Government

11月26日

　Digital Leaders Networkが公式に発表されました。このアドバイザーグループ（政府機関の内外から構成）はシステム全体にわたって新しいガバナンスを構築して実行する上で不可欠でした。 彼らは後でGOV.UK戦略に同意し、それを元に各官公庁のデジタル戦略の開発を推進しました。Kathy Settleはその作業を指導する上で重要な役割を果たしました。

12月10日

　テクニカルアーキテクトのAnna ShipmanはGDSが開発したマイグレーションツール”Migratorator“について解説しました。

12月13日

　改革チームについての短編映画。この時点ではまだまだ小さな規模でしたが、すぐに25の模範プロジェクトからなる組織になりました。2013年から2015年の間のGDSの新しいフォーカストなることが2013年1月のSprint 13で発表されることになります。

12月14日

　GDSはLiam Maxwellが政府の最高技術責任者（CIO）としてGDSに参加すると発表しました。この人事に伴いIT Reform Groupが内閣府からGDSに移管されました。

12月21日

　政府のAssisted Digitalの取り組みが発表されました。

　同日18の官公庁がデジタル戦略を発表しました。Tom Loosemoreは次のように書いています：

これまでではじめて、政府はデジタルの時代にふさわしいユーザーの期待を叶える集合的な野心を持つに至りました。

関連記事

 

原文：”What Really Happened with Vista: An Insider’s Retrospective” by Ben Fathi

必要のない体験を得ることはできない、必要とされるまでは。

 — Steven Wright.

著者のノート：オリジナルの記事はこちらにあります。元々はドッグフーディングに関する自分のブログで発表したものですが、バズってたくさん読まれたためにMediumに再投稿することにしました。

 　Terry Crowleyの注意深く書かれた記事(What Really Happened with Vista)を楽しく読みました。外から観察していて、Terryは元々はOfficeの部門で働いていて、 複雑な機能化に関して素晴らしい仕事をしました。そしてその仕事はWindows Vistaとお蔵入りとなったLonghorn projectにも引き継がれました。

　彼はプロジェクトを頓挫させた多くの問題を明示していて、私はここでその二番煎じをするつもりはありません。私は同じ事象に関して内部の人間からの視点を提供することがフェアだと考えます。Terryのように雄弁で緻密にはなることができませんが、何が本当に上手くいかなかったのか表面化してみましょう。Windows Vistaがリリースされてすでに10年以上の月日が経ちましたが、そこからの学びは今にこそ活きるものです。

　Windowsは野獣です。数千人の開発者、テスター、プログラムマネージャー、マネージャー、セキュリティー専門家、UIデザイナー、アーキテクトなどなど。それだけではなく、人事、採用担当者、マーケティング、営業、法務にそれを管理するマネージャーやディレクターたち。そしてこの全体がさらに何千ものパートナーにサポートされ、ハードウェアからデバイスドライバー、アプリケーションがプラットフォーム上に開発されていきます。

　組織的に言えば当時のWindowsはコア、サーバー、クライアントの3チームでした。コアチームは「配管 “Plumbing”」を作る役割です。全てのWindowsのバージョンと共有するカーネル、ストレージ、セキュリティー、ネットワーク、デバイスドライバー、インストールとアップグレードのモデル、Win32などOSのコアコンポーネントを開発します。サーバーチームはサーバー市場に必要な技術にフォーカスし、クライアントチームはWebブラウザー、メディアプレイヤー、グラフィックスにシェルといったデスクトップやコンシューマー向けの技術に責任をもちます。

　もちろん、組織変更もありましたが基本的なストラクチャーはWindowsの成長とともに組織が大きくなっても変わりませんでした。文化的にも組織的にもコアチームはクライアントチームよりもサーバーチームと近かったと言えるでしょう、少なくともVistaが出荷されるまでは。

　私が1998年のはじめにMicrosoftに入社した時、Windowsと言えばWindows NTでした。アーキテクチャーとしても、組織的にも、製品的にも。Windows 95のコアのほとんどは破棄され、Windows NTがラップトップからサーバーまで全てのWindowsに適用されました。2年後にWindows 95/98のコードベースは悪名高いWindows MEという最後のリリースに再構成されましたが、これは非常に小さなチームによって開発されました。ほとんどの開発者はWindows NTのコードベースに関わっていました。私はWindows 2000の全盛期からWindows 7の完成までの12年間、この野獣の腹のなかで過ごせたことは非常に幸運でした。

　私はストレージ、ファイルシステム、ハイアベイラビリティ、クラスタリング、ファイルレベルのネットワークプロトコル、分散ファイルシステムやそれらに関連する技術を開発するチームのマネージャーとして最初の7年間を過ごしました。その後、1、2年の間だけマイクロソフトのセキュリティーに関わりました。セキュリティーに関するWindowsの技術からアンチウィルスやパッチの緊急対応まで。この時期はWindows Vistaの終わり頃で、ウィルスやワームがWindowsを跪かせ、安全なソフトウェアとしてのマイクロソフトが市場で大きく打撃を受けていた頃です。

　最後の3年から4年はWindows 7の出荷時期で、私は全てのWindowsコアの開発を管理していました。つまりクライアントとサーバーチームが使う技術の「縁の下」全ての開発の責任を負うことになりました。Visutaが出荷された後、Windowsチームは職種によって構成されるようになり、と「トライアード（開発／テスト／PM）」が組織の全てのレベルの責任を持つようになったため、私は開発をリードし、そのほか二人がテストとプログラム管理をリードすることになりました。

　Windowsチームは歴史的に巨大で野心的なプロジェクトに取り組み、多くの場合にそれを捨て去ったり、別の目的で再利用するという歴史を繰り返してきました。最初の頃の例で言えば焼き捨てられたCairoプロジェクトで、一部だけWindows 2000の機能としてサルベージされました。

　私の控えめな意見では、Windowsリリースの最大の問題はリリースの遅れです。平均的にリリースは3年間かかりますが、そのうちの6から7ヶ月くらいしか新しいコードの開発には使われませんでした。それ以外はインテグレーション、テストと数ヶ月のアルファ、ベータ期間です。

　いくつかのプロジェクトは6ヶ月以上必要で、同時進行することで準備ができたらメインのコアコードにマージしました。つまり大きなピースとしては統合され、置き換えられているためメインのツリーは常に半分壊れた状態でした。Windows 7ではよい状態で動くコードであるために、もっと厳密に管理されていましたが、初期のリリースは月に不安定な状態が何日も続くことがありました。

　このような混沌とした開発の性質は「スケジュールチキン（他のチームも非現実的なスケジュールで結局は遅れるだろうと想定して自分たちのスケジュールも非現実的にすること）」の状態になる傾向にあります。つまり自分たちのコードは他の人たちよりもいい状態だろうと自分たちと周りを納得させ、あとは「磨き上げるだけ」ということで、完成した状態でチェックインさせてしまいます。

　三年のリリースサイクルでは、開発を始める段階でリリースするときに外部環境としてどのような競合状態になってエコシステムが存在しているのか知るすべはありません。リリースを延期させるはキャンセルまたはシベリア送りになります。シベリア送りの場合は引き続き他の組織からは見捨てられた機能を開発をして最終的には失敗プロジェクトとなることです。それでもチームや役員があきらめきれずに続けてしまうことがありました。私もいくつかのプロジェクトに関して個人的に責任があります。ことが終わった後の後知恵ではいくらでも完璧な予測ができます。

　それぞれのチームは自分たちのやることで忙しく、その他のコンポーネントやUIとのインテグレーションやテストはおざなりにしがちで、アップグレードのような厄介な問題は後回しにしがちです。そのためにみんなUIやアップグレードテストのために最後の最後に支援を得ようと躍起になることから、いくつかのチームがボトルネックとなります。

　開発中はいつでも複数のメジャーリリースとサイドプロジェクトが進行中でした。それぞれのチームが自分たちのコードベースの各段階に責任を持ち、それは結果的に「金持ちはより金持ちに、貧乏人はより貧乏に」という傾向へと向かいました。遅れるチームはいくつかの理由で常に遅れるようになります。

　プロジェクトが完成に近づくにつれ、PMは次の要求を意識しはじめ、「金持ち」で「健康的」なチームは新しいコードの開発に着手しはじめます。しかし、ほとんどの「貧乏」なチームは現行のリリースに行き詰まります。特にテストチームは出荷までリリースから解放されることはなく、新しいコードはほとんどテストされることはありませんでした。「不健康」なチームは常に遅れ、現行リリースの最終調整によってさらに遅れることとなりました。これらのチームはチームの士気も低く、離職率が高いため、エンジニアたちは自分たちが書いていない理解不能な不安定なコードを引き継ぐことになりました。

　Vista/Longhornの期間において、私はストレージとファイルシステムの技術に責任を持っていました。つまりWinFSについてもです。当時はWindowsチームの姉妹チームであるSQLデータベースが主にリードをしていましたが。

　Bill Gatesは個人的にも細かい点においてまで大きく関わりを持ち、WinFSのPMとまでジョークで言われていました。数百人月（数千でなければ）のエンジニアリソースがこのプロジェクトに投入され消費されました。もしデータベースのクエリー機能とファイルシステムの非構造化データの機能が合わさって全く新しい「リッチ」アプリケーションを生み出す新しいプログラミングのパラダイムとなったとしたら。

　後付けで言えば、Googleが手際よくこの問題を解決しました。非構造化データをシームレスで高速なインデックスエクスペリエンスを実現しました。しかも、彼らはローカルディスクだけでなく、インターネット全体でそれを成し遂げました。さらに言えばその機能を享受するためにアプリケーションを書き直す必要すらありませんでした。WinFSが成功したとしてもそのメリットを享受するためにはアプリケーションの書き換えが何年も必要となったでしょう。

　Longhornがキャンセルとなり、その残り火からVistaがかき集められた時、WinFSはOSのリリースから除外されました。SQLチームによってさらに数年独立したプロジェクトとして進められました。その時にWindowsはインデックスエンジンが組み込まれ、検索エクスペリエンスがインテグレートされていました。コアでない部分でしたのでアプリケーションの変更も必要ありませんでした。そのためにWinFSの必要性はさらに薄まりましたが、それでもプロジェクトは続きました。

　Longhornにおけるセキュリティーに関するアーキテクチャー上の膨大な変更はWindows Vistaの一部として引き継がれました。私たちは急拡大するインターネットの世界からセキュリティーに関して大きく学び、その学びをOSのアーキテクチャーレベルで適応して顧客のために全体のセキュリティーを底上げしたいと考えていました。

　私たちはやるしかありませんでした。Windows XPはその成功の犠牲者となりました。使いやすさのためのデザインはインターネット時代のセキュリティーに必要な現実にそぐわないものになっていました。その対応をするということは、Windows XP Service Pack 2と同時進行で進めなければいけないということでした。Windows XP SP2はその名前から反してLonghornのかなりのリソースを吸い上げたものでした。

　私たちは次のOSのセキュリティーに関して後ろに戻ることはできませんでした。そのために、VistaはこれまでリリースされたどのマイクロソフトのOSよりも強固なセキュリティーを兼ね揃えていました。しかし、その過程でアプリケーションやデバイスドライバーのこれまで経験のない規模のエコシステムにおいて対応する必要がありました。顧客はアプリが動かないからVistaを嫌い、エコシステムのパートナーは対応する時間が少ないためVistaを嫌いました。Vistaは再生しつつあったAppleとの競争のために早くリリースする必要があったからです。

　いずれにせよ、このセキュリティー上の変更はサードパーティーにとってもアーキテクチャーの変更が必要でした。しかし、エコシステムのベンダーは過去のアプリに大きく投資したくありませんでした。いくつかのソリューションはデータ構造に変更を加えるという異例のアプローチをとったり、自分たちの機能を使うためにカーネルのインストラクションに変更を加えました。APIをバイパスし、マルチプロセッサーをロックすることで問題を引き起こしました。アンチウィルスのベンダーがこのようなアプローチを取りがちでした。

　私のマイクロソフトのセキュリティー責任者としての役割において、アンチウィルスベンダーに個人的にも何年もなぜカーネルのインストラクションとメモリ上のデータ構造に「パッチ」を当てることを許可しないのか、なぜそれがセキュリティー上のリスクになるのか、なぜ彼らは正式なAPIを使わなければいけないのか、Windowsカーネルに深く関わるレガシーのアプリをサポートしないのかを説明しなければいけませんでした。それらは顧客のシステムを攻撃するハッカーと同じアプローチです。私たちのアンチウィルスベンダーの「友人たち」は独占を利用して彼らの生きる権利を奪っているということで私たちを裁判で訴えました。このような友達と一緒でどんな敵が必要でしょうか？彼らは昔のやり方を変えたくなかっただけです。それがお互いの顧客のセキュリティーを犠牲にすることであっても。

　この頃、コンピューター業界では非常に重要なシフトがたくさん起きていました。インターネットの到来、モバイルの勃興、クラウドコンピューティングの出現、新しい広告ベースのビジネスモデル、ソーシャルメディアのバイラル、ムーアの法則の更新。オープンソースの人気はWindowsを襲う全方位攻撃の一つのファクターでした。

　大きく成功した企業では驚くに値しませんが、その対応はイノベーションのジレンマそのものであり、頑なに既存のシステムを累積的に改善していくのみでした。こオードがさらに追加され、複雑さが増し、エコシステムは大きくなり続け、それに伴い競争の先を行くことができませんでした。

　競合だけでは足りず、この頃は多くのエンジニアが何時間、何日、何週間、何ヶ月も司法省の代表者と企業弁護士と時間を共にしなければいけませんでした。反トラスト法における裁判の判決に従い以前のリリースにおいての既存のAPIを文章化しなければいけませんでした。

　純然たる現実としてWindowsのメジャーリリースが3年かかるというライフサイクルは市場の速度に対して遅すぎました。WinFS、セキュリティー、、マネージドコードはLonghornの巨大プロジェクトの一部であり、それ以外に何百ものより小さなプロジェクトが存在していました。

　数千人の組織と数億人の顧客がいるとき、誰でもそれぞれの意見を持っています。今後のタブレットやスマートフォンで動くOSはラップトップでも動くことが期待されます。データセンターで稼働するサーバーは”Powered by Windows”のNASでも稼働することが期待されます。当然ながらクラウドでのハイパーバイザー（HiperV）でも同様です。これらの要件は全てのセグメントにおいて同時に進もうとするチームを反対側に引き寄せました。

　Longhorn抜きでVistaを語ることはできません。Windows 2000／XPとWindows Server 2008 and Windows 7、そのリリース前後を見ることによってどのように業界が変わったのか。

　Windowsは自らの成功の犠牲者でした。様々な市場で成功し、その市場でOSのデザインに関する異なる、時として対立する方向に影響力が動きました。これらの異なる要求に答えるということは、全てにおいて完全に応えることはできないことでもあります。

　90年代に成功したアーキテクチャーは10年後に行き詰ることになりました。世界はより早く変化し、組織はそれになかなか追いつけませんでした。それらのトレンドに気づいていなかったのではなく、それに対応しようとしていました。しかし、比喩を使わせてもらえば、三年のリリース期間の間に二年間の妊娠をしているときに飛行機を急旋回することはとても難しいのです。

　つまり、三年、四年前に計画していたことは出荷するときには笑ってしまうくらい時代遅れで、時には大きく間違っていました。当時できたベストなことは簡潔なデバイスにフリクション無しに蓄積型のアップデートができるクラウド型のサービスだったかもしれません。その代わり私たちはリリースまでに多くの時間が必要なクライアント型のモノリスに機能を追加し続け、スピードが必要な時に速度を落としてしまいました。そして、昔の機能を以前のWindowsとのアプリケーション互換性という理由で削除はしませんでした。

　同じOSを十数年以上の長い期間数億のユーザー、数百万の企業、数千のパートナー、数百のシナリオに数十のフォームファクターをサポートし続ける。徐々に互換性の悪夢に気が付きはじめます。

　後から思えば、Linuxはこの観点でずっと成功しています。オープンソースコミュニティーとソフトウェア開発のアプローチは間違いなく解決方法の一つです。UnixとLinuxのモジュラー型でプラグ型のアーキテクチャーもアーキテクチャーの観点から大きな改善でした。

　組織は組織図をプロダクトとして出荷する。Windowsの組織も同じです。オープンソースはこのような問題はありません。

　これに加えて、社内の組織的なダイナミックスと個性があります。私たちはそれぞれ好みの機能があります。私たちのエコシステムパートナーは新しいスタンダードの適応を求めてきます。彼らのソリューションをプラットフォームで明確にするために、特定のシナリオを実現するAPIを追加するために。私たちはみんな私たちの技術とアイデアが戦いに勝つ野心を持っていました。もし、次のWindowsのリリースに入り、数百の顧客がいれば。私たちは計画の会議やウォールームで戦う意義を信じていました。私たちには昇進して自分の影響力をチームの大きさを測るマネージャーたちがいました。

　開発とテストチームは常に対立していました。開発はコードをチェックインしようとし、後者は実際の顧客では起こりえないようなテストケースを作って優秀さを示そうとしました。社内のダイナミックスは複雑です。年に一回は組織変更があり、新しい組織のダイナミックに対応する必要もありました。

　これらは言い訳でも謝罪でもありません。そのような意図で書いていません。

「私たちは間違えを犯したか？」

　はい、大いに。

「私たちは意図的に間違った判断をしたか？」

　いいえ、私の知る限りでは。

「ものすごく複雑で大きなエコシステムを持つ製品でしたか（少なくとも当時は世界で一番）？」

　はい、そうです。

「もっといい仕事ができたはず？」

　はい、もちろん。

「いまだったら違う決定をした？」

　はい、でも後付けではいくらでも言えます。いま知っていることを当時は知る由もありません。

「私たちは落胆と後悔と共に振り返らなければいけない？」

　いいえ、むしろ学びを得るようにしたいです。同じ間違いをこれからのプロジェクトで犯すことはないでしょう。私たちは体験から学びます。つまり、次はまた別の間違いを犯すということです。間違えるのが人間です。

原文：”A GDS Story 2010” and “A GDS Story 2011“

2010/2011年｜2012年｜2013年｜2014年｜2015年

イントロダクション

GDSに訪れる訪問者に最もよく聞かれる質問は以下の三つ。

• どうやってはじまったんですか？
• どうやってここまで来たんですか？
• どうやったら私たちの政府／チーム／組織は同じことができますか？

　これはこれらの質問に答えようとする試みです。これは慎重に組織の記憶をくみ出すことでもあります。わたしたちは常に自分たちのデザイン原則を信じています。そのひとつに「オープンにして、改善する」があります。これは私たちのスタート地点とこれまでの道のりについてのオープンな物語です。

一つだけ注意点

　このストーリーは網羅的ではありません。物語のすべてではありません。そのためタイトルは “a story”であり “the story”ではないのです。間違いや抜け漏れなどいろいろと問題もあるでしょう。なにか不具合を見つけたら私たちに連絡してください。

2010年

夏

　「英国デジタルチャンピオン」に任命されたMartha Lane Foxは当時の主要政府のウェブサイトであるDirectgovのレビューを行うよう依頼を受けました。彼女はTom Loosemoreを含むチームを招集しました。また、すでに独自の調査を行っていたコンサルティング会社のTransformも参加しました。

　Directgovに取り組んでいるチームは何百ものウェブサイトを閉鎖する野心的なプロジェクトにすでに取り組んでいました。数年後、Sarah Ricards（後にGOV.UKのコンテンツデザイン担当ヘッドになる）は次のように書いています。

私と素敵なチームがすべてのルールを守れば、決して何もなしえなかったでしょう。私たちは個人的な関係を使い一丸となって働き、上から跨いだり下を潜ったりしました。やれることすべて。ピカピカに光ったものができた？いいえ。素晴らしいものができた？いいえ。前よりいいものができた？はい。DirectgovがなかったらGOV.UKをローンチできなかったでしょう。

10月14日

　Martha Lane Foxは当時の内閣官僚だったFrancis Maude宛てに手紙を書きました。その手紙で「進化ではなく革命を」と要請しました。

私はDirectgovだけを切り出してレビューしません。政府がインターネットを活用して国民との会話ややりとりを改善すること。インターネットへシフトすることにより大幅に効率性を改善する一環と捉えています。

この手紙がきっかけとなりGDSが設立されることとなりました。

11月

　Martha Lane FoxsのFrancis Maude宛の手紙と彼の返信はTransformによるサマリーとともに公開されました。

　官僚のChris Chantが責任者としてこの新しい組織の責任者に任命され、GOV.UKアルファ計画を立てました（この時点では、プロジェクトは「alphagov」と呼ばれていました）。 Chantの任命は翌年の2月まで正式には発表されませんでした。Tom Loosemoreはチームづくりを任されました。Chantは彼に「キミが必要とする人材を集めよう」と言いました。そして、アルファを構築するチームを探しはじめました。 早い段階で、David MannとNeil Williams（後にGDSでGOV.UKのヘッドになる）に声をかけました。

12月

　クリスマスの直前、ホワイトホール向かいのデジタル人間達が仕事の後にランバート・ノースのパブに集まり、実際にMarthaのビジョンをどのように実装するかを議論しました。そのうちの2人、Neil WilliamsとWill Callaghanはワイヤーフレームのモックアップで考えを図案に落とし込んでいきました。

2011年

1月

　最初のアルファチームがウォータールー駅の近くの政府ビルHercules Houseに集められました。Tom Loosemore、Richard Pope、David MannとJamie Arnoldです。

2月

　2月からさらに多くのメンバーが参加しました。James Stewart、James Weiner、Paul Annett、Relly Annett-Baker、Lisa Scott、Ben Griffiths、Matt Patterson、Joshua Marshall、Helen Lippell、Russell GarnerとPeter Jordanです。

March

　アルファチームの仕事がはじまりました。Tom Loosemoreがブリーフィングをしました。「閣僚達に”この中のどれかが欲しい”と言わせるものを作る」

　チームは壁にプロジェクトのマインドマップを描きました。

　Richard Popeによるこの初期のスケッチはチームのアイデアが後期のものとどれほど違っているのかを表しています。そしてDirectgovとも大きく異なっていました。このスケッチでは、ページの上部にバナー広告風のCTAスペースがあると想定されていました。ページの多くのスペースは中央の検索窓が確保し「あなたのしたいことはなんですか？」という大きな見出しがありました。初期段階の名前は”ukgov.gov.uk”でした。

　リチャードはFlickrに数百点のスケッチをポストしました。

　数週間のアイデア出しとプロトタイプの後、チームは野心的でありすぎることを認識しはじめました。最初のアプローチはあまり適切ではなかった。Richard Popeは「もっと適切な方法を取らないといけない」と主張しました。ユーザーのニーズを優先しないといけない。そこでアルファのスコープを100人のユーザーのニーズに絞り込むことにしました。100人のユーザーニーズを付箋紙に書き、壁に分類しました。

3月15日

　Government Digital Serviceについての公での初めての小さな告知。「Directgovとそのほかの小さなチームを統合した新組織」

3月29日

　alphagovプロジェクトが公式に発表された。Tom Loosemoreが責任者（Foreign and Commonwealth OfficeにおけるHead of DigitalのJimmy Leachの助けを借りて）。 ブログで率直な宣言がなされました：

通常「アルファ」は公開されません。そのあとの「ベータ」ではじめてドアが開けられます。今回はユーザーからの実際のフィードバックを得るためにとても急進的なアプローチをとります。

4月

　5回目のスプリントに入りアルファチームは作業量と人手不足に苦しんでいました。 アルファが公開された後にJamie Arnoldはこの問題について書きました：

私たち（あるいはむしろ私）はすべてを正しくできていなかった。スプリント5が終わる頃にExcelを閉じて英国王立動物虐待防止協会に逃げ込む準備ができていました。

　チームが完全に集まってからメンバーリストを発表しました。

4月7日

　これが最初に公開されたアルファの画面。The Daily Telegraphで報じられる。

4月28日

　Richard Popeは「少ない労力で」「すぐにやれることを見つける」「統一性ではなく一貫性」など、最初のデザインルールに関するブログ記事を書きました。これらは後にデザイン原則の基礎となりました。

5月9日

　アルファチームのメンバーであるDavid Mannが政府横断のデジタルプロジェクトについて書きました。そしてそれはGDSがはじめての試みでないことも指摘しました。

私たちのプロジェクトは官公庁の広い支持者とともに進める文化的ムーブメントです。よりアジャイルで反復検証するユーザーのニーズに基づくデジタルプロダクトの開発を追求します。

5月11日

　アルファのローンチ（予定より1日遅れ）

　オリンピックスタジアムの写真がのちに追加されました。「西海岸な感じ」を出すようにと言われていました。ゴールは当時の他の政府系のウェブサイトとは根本的に違ったものを作り出すこと。

　反応は概ね好意的でした。しかしいくつか批評もありました。Leisa Reichelt（後にHead of User ReserchとしてGDSに参加）はユーザーエクスペリエンスのリーダーを雇っていないと批判しました（他にもありましたが）。

ユーザーエクスペリエンスの実践者として、残念ながらうんざりとした気持ちです。エンドユーザーを中心におくとか、政府のニーズや要望よりもユーザーニーズを優先させるとされてきましたが、口だけで実行されていません。他のプロジェクトが参考にすべき点はあまりありません。

　数週間後、Tom Loosemoreはブログで彼の考えについて書きました：

 プロトタイプは12週間で261,000ポンド（約4000万円）で開発されました…従来の枠を外した実験的プロトタイプ（またはMVP: Minimum Viable Product）です。社内のチームがオープンかつアジャイルな方法で作業し、ユーザーのニーズを設計のコア プロセス。 これは新しいアプローチではありませんが、まだ政府全体では非常に斬新なアプローチです。

　もう一つのアルファページ。これは財務省のホームページ。 部門別のニュースはTwitterフィード風になっています。

　Paul Annet（アルファチームのデザインリード）はブログで当時考えていたビジュアル言語について説明しました。また奥付リストツールを作りました。

　アルファはその目標（プロダクトとしての完成ではなく）としていたポイントを達成しつつありました。その点で成功と言えました。数週間で次の段階がはじまります：ベータ。

5月20日

　内閣府のExecutive Director for DigitalとしてMike Brackenが公式に発表されました。

この役割は責任範囲はDirectgovの最高責任者、政府期間をまたがるデジタル改革のリード、デジタルエンゲージメントと透明性のためのディレクターの仕事の一部が含まれます。彼は政府の最高執行責任者（COO）であるIan Watmoreを上長とし、内閣府でGovernment Digital Service（GDS）の100人以上のスタッフを統括します。

　その舞台裏ではGDSが形を作りはじめていました。ベータのスコープの定義をはじめました。

　前回のアルファと同様に壁にマインドマップを描くことからはじめました。

7月

　GOV.UKベータはDirectgovと並行しての作業でした。それを置き換えるまでは。（GOV.UKをDirectgovと置き換えることはJames StewartとEtienne Pollardによってコーヒーを飲みながら2012年の早い時期に決められました。この日は第二候補でした。第一候補の日は政党会議のシーズンだったのです）

　すべてのユーザーのニーズをインデックスカードに書き出して床一面に広げました。それ以外にこれほど多くのニーズを広げてカテゴリー分けと優先順位付けの作業をする広さがある場所はありませんでした。

　Sarah Rishardsはコンテンツデザイナーがどうして必要で、どうやってその役割を作ったかを2016年のブログで説明しています。

デジタルコンテンツは単なる文字ではないことが私にとって熱意となりました。コンテンツが人々が許可されている以上に多くのことができることを政府は理解する必要がありました。ターゲットとするユーザーが情報として消費できることがコンテンツを絞り込むベストの方法です。そのコンテンツとはツール、電卓、カレンダーやビデオかもしれません。コンテンツは文字ではなく意味を持つコンテンツです。そして私たちは英国政府のために「コンテンツデザイナー」という役割を作ることを決めました。

7月4日

「オープンなコーディング」アプローチの最初の兆候が現れました。それは後にJames Stewartのブログ記事で説明されています。

7月29日

　GDSは最初のプロダクトをローンチしました：オンライン嘆願サービス。これはアジャイル手法で8週間で開発されました。ちょとした使い切りのプロジェクトで自分たちの力を示すいい機会でした。この請願サービスは2015年にGDSと議会チームの協力の元にアップデート、再構築しました。

　同じ日にMike Brackenは最初のブログを書きました。それはGOV.UK Verify（認証サービス）となる仕事を示唆するものでした：

これまでの学びの二つ目は政府のサービス全体に利用できる認証の重要性です。市民としてユーザーとしてデジタルサービスについて地方政府のものなのか国としてのものなのかはわかっていますが、その責任部門はあまり意識されません。政府をまたがるデジタルサービスの準備するにあたりこのユーザー行動を原理とすることを3週間に渡り繰り返し考え続けました。

8月

　Mike Beavenが夏にチームに加わりました。彼の最初の仕事は再編成です。新しくなったGDSで人と役割をマッピング。ほとんどのスタッフは新しいチーム内の仕事に再就職しなければなりませんでした。

　8月に参加したもう一人はChris Thorpe。戦略的思考を行い閣僚への説明を担当しました。”Trust, users, delivery”というタグラインは彼によるものです。

8月10日

　David Rennieは後にGOV.UK Verifyとなる身分証明プロジェクトを紹介しました。

デジタル時代に信頼関係を築くためのより良い方法が必要です。長いユーザーリストや映画の名前よりいいセキュリティー確保の方法が必要です。GDS身分証明プログラムを通じてこれらの問題に取り組みます。

8月11日

GOV.UKのベータが正式にブログで発表されました：

alpha.gov.ukからの学びに基づいて開発し、さらに積み残された多くのギャップも埋めていくつもりです。これまでになかった最も使いやすくアクセスしやすい公共のウェブサイトを作りたいと考えています。単に「アクセス可能」というボックスをチェックするだけでは不十分です。誰にとっても使いやすく、実際に使われるものではければいけません。

ベータには3つの目標がありました：

• 市民に対するコンテンツ配信としてのパブリックベータ（内部的に「メインストリーム」と呼ばれる）
• 新しいパブリッシングプラットフォームとしてのプライベートベータ（各政府機関のスタッフがGOV.UKのページを追加したり管理したりする）
• GOV.UKのビジュアルアイデンティティと明確なユーザーエクスペリエンスを提供する「グローバルなエクスペリエンス言語」を開発する

9月19日

　Richard PopeがNeedotronについて書きました。これは何百ものユーザーニーズと、それを満たすであろうページとページの形式を追跡する内部ツールです。

10月

　Mike Brackenの任命前にGDSの暫定責任者だったChris Chantは今では有名となった「容認できない」演説を政府研究所で発表したしました。これが、その現状の公共におけるITを批判したスピーチの一部です。

私は12ヶ月以上契約を締結するのは今の時点では全く受け入れられないと考えます。このITの世界において2年前にiPadが出ることを予測できませんでした。それでいて2年、3年、5年、7年さらに10年後まで予測できると考えているのです。まったくのナンセンスです。まったく容認できません。どのようなシステムを所有し、どれくらいコストがかかり、そもそも使うかどうかもわからないのに。

　そしてGDSのブログにこの問題をどう直していくのかを書きました。

11月

　GDSはHolbornのAviation Houseの6階にある新しいオフィスに移りました。

　Ben TerrettとRussell Daviesがチームに加わりました。Benは小規模なデザインチームを率いて、それを拡大していきました。彼はガーター勲章を訪れ、GOV.UKで王冠を使用する許可を求めました。そして許可されました。

11月4日

　当社は身分証明プログラム（Identity Assurance Programme）のために1,000万ポンド（約15億円）の資金を発表しました（これは後にGOV.UK Verifyとなります）

11月10日

　Chris Chantは中小企業（SME）を招いて政府との対談の場を設けました。GDSと協力してすべてのITサプライヤーが広く競争力を高める方法について話しました。これは後にデジタルマーケットプレイスの一部となりました。

12月1日

　Emer ColemanがDeputy Director of Digital EngagementとしてGDSに参加しました。

12月8日

　すでに1年間ほど作業しているのですが、GDSの正式な組織としての「オープン」がこのブログで発表されました。

　GDSはオープニングイベントを主催し、プレスを招待しました（イベントの写真）。記事は非常にポジティブでした：

• Wired (インターネットアーカイブより)：公共サービスはデジタルが前提（Digital by Default）でなければいけない
• Telegraph：失敗したWebサービスは納税者にとって10億ポンド（1500億円）の負担
• Computer World：GDSが始動

関連記事

原文：”Blockchain Infrastructure Landscape: A First Principles Framing” by Trent McConaghy, July 15, 2017

分散アプリにおけるストレージ、コンピューティングおよびコミュニケーションを明らかにする

　Ethereum、IPFS/Filecoin、BigchainDBはどのように補完しあっているのでしょうか？Golem、Polkadot、Interledgerは？このような質問をよく受けます。だから、私はこれらの質問に答えてみることにしました。

簡単な答え：魔法のようにすべてを行う「ブロックチェーン」という魔法のシステムはありません。分散化アプリケーションを効率的に開発するために組み合わせて利用できる優れたビルディングブロックならあります。Ethereumはその役割があり、BigchainDBも役割があり、それ以外にも多くの技術がビルディングブロックを形作っています。それを今から見ていきましょう。

背景

　コンピューター処理の要素は、ストレージ、コンピューティングとコミュニケーションの三つです。メインフレーム、PC、モバイル、クラウドは共通してこれらの要素を独自の方法で実現しています。特殊なビルディングブロックがこれらの要素のトレードオフを補完する形で生まれることもあります。

　たとえば、ストレージ要素にはファイルシステムとデータベースがあります。ファイルシステムはディレクトリーとファイルの階層にmp3のようなブロブを格納するためのものです。データベースは構造化メタデータを格納するためのものでSQL*1のようなクエリインタフェースを備えています。集中型のクラウドに置き換えて考えると、ブロブストレージにAmazon S3、データベースはMongoDB Atlas、プロセッシングはAmazon EC2に相当します。

　この記事ではコンピューター処理の各要素のブロックとシステムの例を中心にブロックチェーンの視点で説明します。

ブロックチェーンのビルディングブロック

以下がそれぞれの要素と関連する分散化のビルディングブロックです：

• ストレージ：トークンストレージ、データベース、ファイルシステム/ブロブ
• ブロセッシング：ステートフル／ステートレスなビジネスロジック、ハイパフォーマンスコンピューティング
• コミュニケーション：データ、バリュー、ステートのネットワークを繋げる

ブロックチェーンのインフラにおけるランドスケープ

　ブロックチェーン技術は以下のようにコンピューター処理の要素にマッピングすることができます。

ストレージ

　基本的なコンピューター処理におけるストレージ要素は次のビルディングブロックがあります。

トークンストレージ

　トークンは価値（資産や証券など）を格納します。例えばBitcoins、飛行機のマイレージ、デジタルアートの著作権などです。トークンストレージシステムは二重支出を防ぎながらバリアントとともにトークンを発行／トランスファーします。

　BitcoinとZcashはトークンにフォーカスした代表的な「ピュアプレイ」システムです。 Ethereumは世界のコンピュータとなるミッションの実現のためトークンをサービスで利用しています。これらはすべてネットワークインフラストラクチャを運用するための内部インセンティブとして使われるトークンの例です。

　その他のトークンはネットワーク自体に力を供給するための内部性を持ちません。より低いレベルのインフラストラクチャが実際にトークンを格納する上位ネットワークのインセンティブに使用します。Ethereumメインネットの上のGolem（GNT）のようなERC20トークンは一つの例です。IPDBネットワーク上で動作するEnvokeのIPライセンストークンももう一つの例です。

　最後にほとんどのブロックチェーンシステムにトークンストレージの仕組みがあることを示すために”.*“をリストしました。

データベース：データベースは構造化されたメタデータの格納に特化しています。例えばテーブル（リレーショナルデータベース）、ドキュメントストア（JSONなど）、KVS、時系列、グラフなどです。クエリ（SQLなど）を介してデータを迅速に取得することができます。

　MongoDBやCassandraのような伝統的な分散型（ただし集中化された）データベースは数百テラバイト、さらにはペタバイトのデータを毎秒100万回書き込むことができます（Netflixの事例）。

　SQLのようなクエリ言語は実装と仕様を分離しているため特定のアプリケーションに縛られません。SQLは何十年にもわたる標準です。同じデータベースシステムをさまざまな業界で使用することができるのはこのためです。

　別の言い方をすれば、アプリケーション固有のコードを使わずBitcoinを超えてブロックチェーンのアプリケーションを一般的なものにするためにチューリング完全性を徹底する必要はありません。データベースが必要なだけです。これには単純さと規模のメリットがあります。ただし、いくつかの場面でチューリング完全性を持つ大きな意味がまだあります。これについては「分散処理」のセクションでさらに解説します。

　BigchainDBは分散データベースソフトウェアです。具体的にはドキュメントストアです。MongoDB（またはRethinkDB）上に構築されているため、Mongoのクエリとスケールを継承しています。さらに分散制御、耐タンパー性、トークンサポートなどのブロックチェーン特性も備えています。IPDBはBigchainDBのガバナンス機能を持った公開ネットインスタンスです。

　また、IOTAはブロックチェーン分野における時系列データベースと考えることもできます。

ファイルシステム／データブロブストレージ

　これらは大きなファイル（ムービー、mp3、大規模なデータセット）を格納するためのシステムで、ディレクトリとファイルの階層構造をとります。

　IPFSとTahoe-LAFSは分散型のファイルシステムで、分散型／集中型のブロブストレージをラッピングします。FileCoin、Storj、SiaやTieronは分散型ブロブストレージです。古き良きBitTorrentもそうですトークンではなくtit-for-tatスキームを使用します。 Ethereum Swarm、Dat、Swarm-JSは基本的に両方を行います。

データマーケットプレイス

　これらのシステムはデータ所有者（企業など）とデータ消費者（AIスタートアップなど）を仲介します。本来ならデータベースやファイルシステムよりも高いレイヤーのものですが、データを必要とする無数のアプリケーション（AIなど）がそのようなサービスに依存するため、コアインフラストラクチャにもなります。Oceanはデータマーケットプレイスを構築することができるプロトコルとネットワークの例です。アプリケーション固有のマーケットプレイスもあります：暗号市場のEnigma Catalyst、個人データ用のDatum、 IoTストリーム用のDataBroker DAO [2]などです。

プロセッシング

　次に基本的なコンピューター処理のプロセッシング要素について説明しましょう。

「スマートコントラクト」は分散型の処理を行うシステムにとって人気のある呼び方です*2。 実際にはステートレス（コンビネーショナル）ビジネスロジックとステートフル（シーケンシャル）ビジネスロジックの2つのサブセットがあります。ステートレスとステートフルは複雑さや検証可能性などにおいて根本的に違うものです。さらにHPC（ハイパフォーマンスコンピューティング）という3つ目の分散処理ブロックがあります。

ステートレス（コンビネーショナル）ビジネスロジック

　内部的にステートを保持しない任意のロジックです。電気工学用語では組合せ論理回路と位置づけられます。ロジックは真理値表、回路図、または条件文を保持するコード（if / then、and、orを組み合わせたもの）として表現されます。ステートを持たないため、大きなステートレスなスマートコントラクトを検証するのは容易です。このため大規模な検証/安全なシステムを構築することができます。N個の入力と1個の出力を検証するためにO（2 ^ N）回の計算が必要です。

　インターレジャープロトコル（ILP）には組み合わせ回路を明確に指定する暗号条件（クリプトコンディション：CC）プロトコルを含みます。CCはIETFを通じてインターネット標準となっているため、知っておいたほうがいい技術です。またILPは集中管理と分散管理の両方のペイメントネットワーク（例：75以上の銀行がRippleを介した取引）で普及しています。CCはJavaScript、Python、Javaなどのスタンドアロン実装があります。 BigchainDBやRippleなどのシステムはCCを使用し、組み合わせビジネスロジック／スマートコントラクトをサポートします。

　BitsharesとEosはステートレスなビジネスロジックもサポートしています。

　ステートフルロジックはステートレスロジックのスーパーセットであるため、ステートフルロジックをサポートするシステムは（複雑さと検証の難しさを犠牲にして）ステートレスロジックもサポートします。

　BigchainDB、BitsharesとEosはイベントもサポートしています（例）。このためステートフルなビジネスロジックに近いレベルの永続性を与えます。

ステートフル（シーケンシャル）ビジネスロジック

　内部的にステートを保持する任意のロジックです。つまりメモリーを保持します。または少なくとも1つのフィードバックループ（およびクロック）を備えた組み合わせ論理回路です。たとえばマイクロプロセッサには内部レジスタがあり、それに送られるマシンコード命令に従って更新されます。より一般的にはステートフルなビジネスロジックは、一連の入力を受け取り、一連の出力を返すチューリングマシンです。このようなシステムはチューリング完全システムと呼ばれています*3。

　Ethereumはステートフルなビジネスロジック／スマートコントラクトを直接チェーン上で実行する最も有名なブロックチェーンシステムです。 Lisk、RChain、DFINITY、Aeternity、Tezos、Fabric、Sawtoothなど多くががこれを実装しています。実行コードが「ちょうどそこに、どこかに」というのは多くのユースケースを適用することのできる強力なコンセプトです。これこそがEthereumが立ち上がった理由です。そして、そのエコシステムが成長して、それ自身がプラットフォームである理由です。このビルディングブロックに多くの強豪が参入してくる理由でもあります。

　シーケンシャルロジックは組み合わせロジックのスーパーセットであるため、これらのシステムは組み合わせロジックもサポートします。

　The DAOのハッキング事件でも示されたとおり、コードの小さな間違いは重大な結果を招く可能性があります。正式な検証はチップ業界を助けたように役立ちます。 Ethereum Foundationはこれに取り組んでいます。しかしスケールには限界があります。内部変数がすべてブール値であると仮定して、組み合わせ回路の場合可能なマッピングの数は2 ^（入力数）です。シーケンシャルの場合、内部状態の数は2 ^（内部ステート変数の数）です。たとえば、3入力の組み合わせ回路を使用している場合、²³ =8のsステートの可能性を検証する必要があります。これが32ビットレジスタを持つ順序回路であれば、²²= 42億のステートを検証する必要があることになります。このように順序回路の複雑さが制限されます（仮に信頼したい場合）。 Rchainがrho calculusで行ったように、ステートフルなスマートコントラクトを信頼するもう1つのアプローチは「Correct-by-construction」です。

　分散処理が必要な場合はより簡単なアプローチがあります。プロセッシングをJavaScriptやSwiftでブラウザやモバイルデバイスなどクライアントで行うのです。この方法ではクライアントでの処理を信頼する必要がありますが、手元のデバイスにおいてそれは許容されることが多いです。これを「ファットプロトコル」の代替としての「ファットクライアント」だと考えています。 このアーキテクチャはメインストリームのWeb開発者にとっては簡単です。多くのWebアプリケーションに必要なのはアプリケーションステートです。これを構築するにはJavaScriptとIPDB（js-bigchaindb-driverを使用）を使うだけです。また、アプリにブロブストレージとペイメントが必要な場合はJSクライアントバージョンのIPFS（ipfs.js）とEthereum（web3.js）を追加します。以下の図がその例となります。

ハイパフォーマンスコンピューティング（HPC）

　レンダリング、機械学習、回路シミュレーション、天気予報、タンパク質フォールディングなど「重い」計算を行う処理です。ここでの計算ジョブはマシンのクラスタ（CPU、GPU、場合によってはTPU）で数時間から数週間かかることがあります。

　HPCの分散処理にはいくつかのアプローチがあります：

• GolemとiEx.ecは分散型スーパーコンピュータとそれに関連するアプリの組み合わせとしてとらえています。
• Nyriadはストレージ処理としてとらえています。基本的に処理は分散ストレージ（Nyriadにも解決策があります）と隣接しています。
• TrueBitはサードパーティが計算。その計算後のチェックを行います（可能な場合は暗黙的にチェックし、質問が発生した場合は明示的にチェックします）。
• 一部の人々は単にVMまたはDockerコンテナで重い計算を実行し、その結果（最終的なVMステートまたは計算結果のみ）をアクセスが制限されたブロブストレージに格納します。次にトークン化された読み取り権限などを利用してコンテナへのアクセスを販売します。このアプローチはクライアントに結果検証をより多く要求しますが、今日使える技術で全てできることが利点です。これはTrueBitが成熟するにつれてTrueBitと自然に統合されます。

コミュニケーション

　ここでは第3の基本的なコンピューティング要素のコミュニケーションについて説明します。コミュニケーションをとらえるには多くの方法があります。ここではネットワークへの接続に焦点を当てます。データ、価値、ステートの3つのレベルがあります。

データ

　私たちは60年代にARPAnetを手に入れました。この成功はNPLやCYCLADESのようないくつかの同様のネットワークを生み出しました。そして新しい問題も生まれました。異なるネットワークはお互い会話ができませんでした。CerfとKahnは70年代にTCP/IPを開発して現在インターネットと呼ばれるネットワークのネットワークを作りました。 TCP/IPは現在ネットワークを接続する事実上の標準になっています。OSIは競合するプロトコルでしたが衰退していきました。しかし、皮肉なことに、そのモデルは有用であることが証明されています。したがって、長い年月が経っているにもかかわらず、TCP/IPはデータのネットワークをつなぐための分散ビルディングブロックです。

　Torプロジェクトはユーザーのプライバシーを保護するためのTCP/IPオーバーレイと見なすことができます。しかし、アメリカ国防総省からの資金提供はいうまでもないことですが、集中化の側面があります。トークン化されたTorのようなプロジェクトが出現しはじめています。今しばらくお待ちください[2]。

価値

　TCP/IPはネットワークをデータレベルでのみ接続します。TCP/IPではパケットを二重に使うことがあります（一度に複数の宛先に同じパケットを送ります）がそれは気にしません。しかし、ネットワークに接続して価値を送る場合はどうでしょうか？たとえばBitcoinやEthereum、あるいはSWIFT決済ネットワークからRippleのXRPネットワーク。トークンを一度に一つの宛先だけに送りたいはずです。交換機は二重支出を防ぎながらネットワークに接続する方法の一つです。しかし交換機の利用はかなり重いです。ただし暗号エスクローを使用することで、交換機の本質部分だけ抽出してスリム化し、仲介人の必要性を取り除くことができます。アリスはMalloryを介してボブに送金することができます。Malloryはファンドを送りますが、使うことはできません（そしてMalloryは永遠にファンドを留めることができないので、その場合はタイムアウトとなります）。これがインターレジャープロトコル（ILP）の本質です。双方向ペグ（サイドチェーン）とステートチャンネル（LightningとRaiden）とコンセプト的には同じです。しかし、価値のネットワーク接続に100％フォーカスしています。 ILPに加えてCosmosもあります。Cosmosはより利便性を高めるために複雑さを少し増しています。

ステート

　価値をネットワークにつなぐ先は何でしょうか？ あるネットワークから別のネットワークにジャンプすることができる独自のBitcoinウォレットを備えたコンピュータウイルスを想像してみてください。またEthereumメインネット内のスマートコントラクトがその状態を別のEthereumネットうあ別の互換性のあるネットに移すことができたら？またはAI DAOを1つのネットに制限するのはなぜですか？

　Polkadotはこのためにあります。ステートをネットワークでつなぐ。Aeternityは価値のネットワークとステートのネットワークの間のどこかにあてはまります。

ビルディングブロックを組み合わせた事例

　ここまでコンピューティングの3つの要素（ストレージ、プロセッシング、コミュニケーション）と、それぞれのビルディングブロックおよびサンプルプロジェクトを紹介してきました。

　人々は組み合わせながらシステムを構築しはじめています。二つのブロックの多くの組み合わせるプロジェクトはたくさんあります。通常はIPFSとEthereumまたはIPFSとIPDBの組み合わせです。そして三つ以上のブロックを組み合わせる事例もあります。ここでいくつかの最先端の事例を紹介します。

Ujoの事例

UjoではIPFS|Swarm + IPDB + Ethereumの組み合わせで分散型音楽サービスを実現しています。IPFSまたはSwarmはファイルシステムとブロブストレージとして、IPDBとBigchainDBはメタデータの格納とクエリに、Ethereumはトークンの格納とステートフルなビジネスロジックに使用されます。

Innogyの事例

Innogyではサプライチェーン／IoTアプリケーションにIPFS + IPDB + IOTAを使用しています。IPFSはファイルシステムとブロブストレージとして、IPDBとBigchainDBはメタデータの格納とクエリに、IOTAは時系列データに使用されます。

そのほかのフレーミング

　ブロックチェーンコミュニティにおける他の人たちによる他のフレーミングも紹介します。それぞれの人たちとの会話を私は大いに楽しみました。

　Joel Monegroの”Fat Protocols“は各ビルディングブロックをプロトコルとして位置づけています。なかなかクールなフレーミングの方法だと思っていますが、それはビルディングブロックがネットワークプロトコルを介してのみ会話をすることとなります。別の方法もあります。ブロックは単に1つの「インポート」ステートメントまたはライブラリ呼び出しとする。

　インポートを使用する理由は（a）レイテンシを短くすること：ネットワークコールに時間がかかりユーザビリティを損なう可能性がある（b）シンプルさ：ライブラリ（または埋め込みコード）の利用はネットワークでの接続、トークンの支払いなどより簡単（c）より成熟している：プロトコルスタックが誕生してきています。私たちは数十年にわたる素晴らしいUnixライブラリを持っています。PythonとJavaScriptのブロックも15年以上経過しています。

　Fred Ehrsamの “Dapp Developer Stack“はWebビジネスモデルに重点を置いています。 このフレーミングも非常に有益ですが、特定のコンピューティング要素（ファイルシステムとデータベースの違いなど）のブロックをさらに区別することを目的としていません。

　BigchainDBのホワイトペーパー[PDF]（2016年2月に公開）図1は、このポストのスタックの初期バージョンです。以下のチャートがそれです：

　この図ではプロセッシング、ファイルシステムおよびデータベースのビルディングブロックにフォーカスしています。「コンピューティングの要素」という観点からは枠組みを構成しておらず、分散処理の種類も区別していませんでした。私がこの記事はこのホワイトペーパーを書いた一年半からの私の考えの進化とも言えます。私の考えは段階的に進化していき5月22日のConcensus 2017でのトークはこの記事と非常によく似ています。そしてこの記事を書いた理由はこのトークをきちんと形にするリクエストをたくさん受けたからです 🙂

　この図は完全集中化（左）から完全分散化（右）までのスペクトラムがあることを示しています。このような表現は既存のシステムを徐々に分権化する上で、どこが最も分散化の恩恵を受けるのか理解するのに役立ちます。

　Stephan Tualの “Web 3.0 Revisited“はこの記事と精神的な部分で近いですが、よりEthereumに重点を置いています。多くのプロジェクトを類似のビルディングブロックにグループ化することでコミュニティに役立つ貢献をしています。自分の考え方ととても似ていることに喜んで驚いていました。しかしアプリケーション（メッセージング、ストレージ、コンセンサス、ガバナンスなどのブロック）を構成するブロックに「アプリ」「What」「How」の3つの要素が混ざり合っています。私にとってはブロックは「What」でなければなりません。したがって、メッセージングは​​アプリです（アプリケーションレベル）。ストレージはより細分化する必要があります。コンセンサスは「How」の一部です。ガバナンスも「How」です。また下位のブロックとして（ネットワーク）プロトコルがあります。私はライブラリの呼び出しと同様にブロックが互いに話すことができる方法の一つだと考えています。それにもかかわらず、私はこれが優れた記事とスタックだと思います 🙂

　Alexander Ruppertの“Mapping the decentralized world”には約20のグループに整理され、x軸はインフラストラクチャ層からアプリケーション層まで4つの上位レベルのグループを表していて、ミドルウェアと流動性を中間レベルに位置づけています。これも素晴らしいやり方です。私はAlexのマップを手伝うことができてうれしいです。コアインフラストラクチャーに重点を置いておらず、より幅広いトレンドに焦点を当てています。これもコアインフラストラクチャに関する第一原則フレーミングです。

将来

　UjoのプロジェクトではIPFSとSwarm（ブロブ）+ Ethereum（トークンとビジネスロジック）+ IPDBとBigchainDB（データベースと高速クエリ）を組み合わせて全てのメリットを享受しています。

　この傾向はビルディングブロックの関係性の理解が進むにつれて増えていくと考えます。「ブロックチェーン」という大きなモノリスにすべてを詰め込むより生産的です。

　このスタック自体も分散型エコシステムとともに絶えず進化するでしょう。AWSはブロブストレージ用のS3というたった一つのサービスからはじまりました。 それからプロセッシングのためのEC2が追加され、AWSのサービスは増え続けています。ここにAWSのリリースタイムラインがあります。現在AWSには50以上のブロックがあります。以下はすべてのAWSサービスの現在のスナップショットです。

　AWSで起きたことが分散化の分野でも起きると予想しています。おそらく現在ある全てのAWSブロックは分散化されるでしょう。もちろんクラウド、モバイル、分散システムにはそれぞれ独自のブロックがあります。分散システムであればトークンストレージなどです。これからの将来はとても楽しみです。

 

　ここ数年、このスタックについて私にフィードバックをくれた無数の人々に感謝します。Carly Sheridan、Troy McConaghy、Dimi de Jongheの編集協力に感謝します。最後にビルディングブロックを改善し続け、さらに興味深いアプリケーションを開発し続けている宇宙の皆様に感謝します:)

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

関連記事

 

原文：”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プロフィールをチェックしてください。

関連記事