Jake Benilov氏は９月27日にブリュッセルで，gov.uk構築時に使用したフィードバックテクニックについて，氏自身のブログ記事 "7 Types of Feedback That Helped Gov.Uk Awesome" に基づいた講演を行う。
ソフトウェアのフィードバックはコストも低く，頻繁に行うことが可能です。ところが奇妙なことに，この業界の製品開発チームのほとんどが，独自に編成したQAチームによる少数の機能テストや非機能テストで満足しているのです。
ブログ記事では，氏が250以上のチームを対象として確認したフィードバック形式が紹介されている：
その氏がAgile Tour Brussels 2013で，GDSチームが日々の作業改善に使用している，革新的なフィードバックテクニックを披露してくれる。InfoQではフィードバックテクニックの利用について，そして氏のチームがユーザリサーチを行うため，動作可能な最小限のプロダクトを使ってチームがリーンスタートアップを適用した方法について，氏にインタビューした。
InfoQ: gov.ukの目指す最終的な目標は何ですか？ その目標を達成するために，開発チームではどのような特別なことを行っているのでしょうか？
Jake: gov.ukは2010から2011年にかけて，"広報業務を立て直す"ことを目的に考え出されました。当時の英国中央政府は多数の情報をオンラインで公開していましたが，それまでのモデルではユーザビリティの問題 (重複する情報が大量に存在する，情報の検索が非常に困難，など) や極端な断片化 (ほとんどの部署や局が自身で公開ポータルを所有し，それぞれが独自の方法で情報の提供やサイトとのやりとりを行う) に悩まされていたのです。
これらの欠点を克服するためgov.ukチームでは，政府機関との間に望まれるすべてのインタラクション (自家用車の道路税支払証明書の取得から，次の銀行休業日の確認に至るまで) に対して，単一のエントリポイントとして機能する，独自の強力なブランドを備えたサイト構築に着手しました。ブランドという面はとても重要です。なぜならそれは，視覚的アイデンティティやインタラクションのデザインに始まって，コンテントを記述する言語や音声に至るまで，すべてに浸透するものだからです。
過去の過ちを繰り返さないためにgov.uk開発チームは，ユーザ(政府ではなく)のニーズの中でも，十分に具体的で把握できているものに対してのみ，サービスを構築することにしました。gov.ukのレガシプラットフォームを移行する間もこの問題に固執し，集中的に取り組むことによって，膨大な量のコンテントとツールを取り除くことに成功しました。それらには，エンドユーザにとって有益と判断できるだけの十分な証拠がなかったからです。
プロジェクトの成功に貢献したもうひとつの要因は，たとえ完璧には程遠いものであっても，動作可能な最小限のプロダクトをリリースする，というチームの意思です。その上で，ユーザからのフィードバックをもとにイテレーションを行うのです。これは同時に，gov.ukは廃止されるまで変化を止めることはない，ということでもあります – 最初の８ヶ月間に実施されたリリースの数は1,000件に達しました。営業日あたり7回のアップデートを行った計算です。
InfoQ: チームにとってフィードバックの獲得が重要なのはなぜでしょう？ どのようなメリットがあるのでしょうか？
Jake: チームが何か新たに構築しようとするとき，そこに特定のユーザニーズが存在するものと仮定をしています。実装がそれらのニーズを満足できるかどうかを判断するためです。プロジェクトの規模が大きくなると，スコープも拡大します。ユーザベースも多様になりますから – 仮定の数も多くなります。フィードバックは，その仮定の妥当性(ないし非妥当性)の判断を可能にするのです。経験豊富なプロジェクトチームならは，仮定もより妥当なものになりますが，それでもミスは誰にもあるものです - 早い時期に，頻繁にフィードバックを得ることで，間違った方向を修正するために必要な時間は短くなるはずです。gov.ukほどの規模と複雑さを持ったプロジェクトでは，フィードバックループが短くなければ，成功は望めないと思っています。
InfoQ: 異なったタイプのフィードバックを数多く使用する理由は何ですか？ タイプが少ない方が簡単だと思うのですが？
Jake: Government Digital Service Design Principles (政府デジタルサービスデザイン原則) の第３の原則は，データに基づくデザインです。異なったタイプのフィードバックは，開発サイクルのさまざまなステージで，異なったデータポイントを提供してくれます – 機能を開発している間は，研究室内テストやリモートユーザテストが欠かせませんが，分析やユーザからの直接のコメントは，それらの機能がローンチ後に有効かどうかを理解するのに役立ちます。
さまざまなフィードバックはお互いに補完し合い，強め合います。例えばDevOps文化が定着していない場所では，早期リリースや頻繁なリリースは困難です – どちらも絶えず失敗を繰り返して，運用チームがフラストレーションで頭を抱えることになるでしょう。別の例として，製品分析(product analytics)は何が(what)起きているのかを教えてくれますが，ユーザリサーチを行わないことには，それがなぜ(why)起きているのかを即座に把握することは多分不可能でしょう。両方とも行うのでなければ，事実の半分を見ることしかできないのです。
InfoQ: チームによるユーザリサーチ，動作可能な最小限のプロダクト，というものが話題に上がりましたが，それらがどのように実施されたのか，例を挙げて頂けますか？
Jake: そうですね，gov.ukが生まれる前の話ですが，gov.ukの前身と並行して稼働していたサイトのアルファバージョンとベータバージョンをリリースしたことがあります。アルファはまさに，Eric Ries氏(リーンスタートアップの提唱者)が定義したような，動作可能な最小限のプロダクトでした – 学習が主たる目的のプロダクトビルドであって，実用が目的ではなかったのです。アルファはわずか12週間で開発，ローンチされました (チームメンバの募集やチームの立ち上げ期間を含めてです)。ですから，チームが実務からのフィードバックを得るのに，数週間しかかかりませんでした。数ヶ月，数年という単位ではありません。ベータ版はプロトタイプよりもう少し複雑でしたが，それでもローンチ時点ではまだ重要な部分が欠落していました。その後たくさんの機能が追加され，既存の機能はテストされて，目的にフィットするまで何度かの再設計や再開発が行われたのです。
例えばホームページは，ユーザテストと一般ユーザからのフィードバックの背景で４回，根本的に再設計されています。ユーザリサーチチームはゲリラテスト(開発環境外で行う簡単で短いユーザテスト)や，もっとフォーマルな開発側テスト，あるいは種類の異なるユーザグループ (プロフェッショナルユーザ，求職者，ビジネスオーナ，退職者，障害者，さまざまな年代やインターネット知識レベルの人たち) の代表者によるリモートユーザテストなどを繰り返し実施しました。これらのテストによって，初期の設計判断の問題が明らかになりました。通常ならば手遅れになるまでキャッチできなかったでしょう。例えばホームページの初期バージョンには，非常に隙間が多く，コンテントのナビゲートをサイト検索に頼っていました。Googleのホームページにアイデアを得たものだったのです。しかしユーザテストを行った結果，このホームページは，検索機能の使用に慣れた人たちにとって有用でない (そもそも彼らは，検索エンジンのリンクをたどって来たのですから) 上に，希望する内容を見つけるのにカテゴリ経由のブラウズを要する人たちには不適切だ，ということが分かりました。この事実が後の再設計時に考慮されて，結果的にgov.ukは，これらのユーザにとって不都合のないホームページをローンチできたのです。
InfoQ: チームではDevOpsも採用して，開発者と運用関係者がコラボレートしていますね。このように部門の境界を越えることで，どのようなメリットがあるとお考えですか？
Jake: 確実なメリットのひとつは，新しいソフトウェアのリリースに際して，形式的な作業の数が少なくなることでしょう。新機能を開発していて，コードレビューやプロダクトオーナの承認を済ませたならば，もういつでもデプロイが可能なのです - 煩雑な運用引き継ぎ作業は必要ありません (ただしリリースに問題があれば，もちろん私の責任です)。これによって，最初のアイデアから機能の実運用まで，極めて速いターンアラウンドが実現できます。しかも，変更の数が少ないことから，個々のリリースの安全性も非常に高くなるのです。
このような体制を取ることで，Webの運用やインフラストラクチャの担当者たちは，プラットフォーム全体の改善に集中できるようにもなります。彼らの持っている専門的なスキルを，アプリケーションの障害追及ではなく，もっと有効なことに活用できるのです。対象的に開発者たちは，実際の運用に使用されるインフラストラクチャに精通することができますから，最終的にはデバッグが容易で，より堅牢性を持ったサービスを構築することができます。