Internet-era ways of working
「Internet-era 」- インターネット時代の働き方とマインドセット
この記事はIDEOと同じkyuグループに属するPublic Digitalのブログエントリーを翻訳しています。IDEOはPublic DigitalとPrivate Sectorの業務において提携しています。
アルゼンチン政府は、これまでの紙とプラスチックのカードに代わり、ユーザーのスマートフォンにデジタル文書を安全に保存する新しいデジタル自動車運転免許証の導入を発表しました。このサービスはわずか65日で、一から開発されたものです。
「インターネット時代の文化、プロセス、ビジネスモデルとテクノロジーを適応させ、人々の期待値の高まりに応える。」これが私たちPublic Digitalが考えるデジタルの定義です。
これを聞いた人からは、必ず次のような質問が来ます。「分かった。でもどうするのか。自分の組織で、それをどうやったら実現できるのか。」
良い質問です。
私たちは長い時間をかけて、この問いに対する答えを考えてきました。ここだけの話ですが、過去20年以上に及ぶデジタル実装の経験の中で、実は私たちは数多くの失敗を経験し、その一つ一つから学んできました。そこから出てきた答えは「インターネット時代の働き方を実行に移すためにすべきことのリスト」とでも呼べるものでした。
我々も携わった、英国政府のデザイン指針をご存じの方なら、耳慣れた項目もいくつか並んでいると思います。このリストの原型と考えることのできる指針だと言えます。Public Digitalではその後、英国政府だけでなく現在は他の国でに、非政府機関との連携も始めたので、このデザイン指針を理解しているのか、把握できるようになりましたが、今度はそれを実施するための方法について、助け舟を出したいと思います。
よって、このリストはデザイン指針に代わるものとして作られたわけではありません。むしろ、それに新たな知見や文脈を付け加えたと言えるでしょう。また、今後さらにアップデートしていくことが必要なことは間違いありません。
Internet era of working - インターネット時代の働き方
1. 組織の都合ではなく、ユーザーのニーズに合わせてデザインする。
直観よりもデータを信頼すること。ただし、そのどちらよりも、ユーザー調査から得られたインサイトのほうを信頼すること。
アーリーアダプター（初期採用者）を観察することにより、新しいテクノロジーが人々の行動をどのように変えたり、新たに作り出したりしうるかに対する認識を高めること。
2. 最もリスクが大きい仮説を実際のユーザーで検証する。
オペレーション・モデルとテクノロジーのほか、ビジネスモデルまたはサービス・デザインに関する想定や仮説を明らかにし、検証すること。
そもそもチームのメンバー同士がうまくやってゆけるかどうかが、最もリスクの大きい想定の一つとなることが多いため、この可能性も加味すること。これを明確にし、別の想定も検証してみること。
チームが想定やリスクについてを包み隠さずに話せる雰囲気と文化を創造すること。確実性を装うことは魅力的ではあっても危険。
3. 実装ユニットは権限を持った領域横断的チームとする。
適切な能力を持った人材だけでなく、最適な心構えや姿勢を兼ね備えたスペシャリストを起用すること。ロックスターは要らない。
当初からオペレーションやバックオフィスの担当者を関与させること。例えば、法務やセキュリティなど、関連領域の専門家をチームに加えること。
担当チームがこのプロセスのオーナーシップを持つようにすること。、プロセス自体にチームが支配されないこと。
スケールを図る際には、チーム自体を大きくするのではなく、新たなチームを設け足していくこと。これは事前にプランニングし、それに従うのではなく、必要に応じて有機的にかつ漸増的に行うこと。
既存の組織構造の中にチームを位置づけられないことがあっても、気にしないこと。むしろ、それは良いことである可能性も大きい。
失敗を覚悟してデザイン、実践し、失敗から学ぶこと。
各チームの中で1人のプロダクトオーナーを定めること。、彼・彼女が優先順位に関する最終決定に明確な責任を負うようにすること。
チームに仕事を成し遂げるために必要なツールと環境(プロジェクトルームなど)を与えること。
4. シンプルにしていくために心血を注ぐ。
チームは、常にそのサービスが簡単に理解でき、簡単に使え、簡単に仕様変更もできることにこだわるべき。
それは時に、望まれるアウトカムから逆算して、最初からやり直し、あらゆる要素をリデザインすることを意味する。
既存のサービスについては、最初の原則や指針に立ち返り、ユーザーに複雑性や混乱をもたらすあらゆるルールや慣習、実践に疑問を投げかけること。
最新のテクノロジーや「イノベーション」を疑問視すること。まずは壊れたものをすべて修正すること。そのうえで、Failure Demand (対応を怠ったことで生じた需要)を測定、削減すること。
5. セキュリティを確保することはレジリエンスを高めることと同じ。
じっとしていては、もうセキュリティを確保できない。アジャイル性と脅威認識を盾にすること。
セキュリティに対する認識をチームのマインドセットのほか、サービスデザイン、業務の進め方、テクノロジーなど全てに叩きこむこと。
潜在的な脅威、特に、データはどのように悪用されるおそれがあるかを理解したうえで、自社またはそのユーザーに損害を与えようと目論む者の企てをできる限りやりにくくすること。
あなたの義務は、ネットワークの内側で完結しない。統制下にあるインフラだけでなく、自社のソフトウェアやデータ・サプライチェーンに内在するリスクを理解、評価、管理すること。
6. ユーザーと、保有するユーザー・データに対する注意義務を認識する。
ユーザーに関して保有するデータを最小限に抑えることにより、リスクを極小化すること。プライバシー・バイ・デザインを実践すること。
ユーザーに関してどのようなデータを保有しているか、これをどのように利用しているか、その責任者は誰かをユーザーに説明すること。
あなたがユーザーに関して保有するデータを、ユーザーが管理できるようにすること。これは、悪用を防ぐユーザーの権利を尊重し、ユーザーを詐欺から守ることにも役立つ。
大量のデータ共有ではなく、継続可能な最低限のデータ・アクセスを念頭にデザインすること。
ユーザーに問題を簡単に是正できる手段を与えること。
7. 小さく始めて、イテレーションを念頭に最適化する。イテレーションとインクリメントを繰り返す。
変革の実装は数カ月ではなく、数時間単位で必要なため、ソフトウェアの変更を簡単かつ安全に行えるようにすること。プログラムの 継続的実装は譲れない必須条件。継続的展開 は尚可。
フィードバック・ループは現実のユーザーの観察を参考とするのがベスト。
プログラムにテストがなければ、機能しない。
問題に対する1つの潜在的ソリューションに拘泥せず、研究とプロトタイピングを通じて可能性空間を探索すること。
イテレーションはソフトウェアだけでなく、社内の方針や実践にも同様に適用することが必要。
8. オープンにすることで改善を図る。
実物を見せること。アジャイル・コミュニケーションを実践すること。
当初は、プロトタイプを使ってストーリーを語り、ビジョンを定め、共通の理解を構築すること。そのうえで、プロトタイプを捨てること。
オープン・インターネットのツールを利用し、オープンソースに開かれた存在となること。
オープン・スタンダードを採用すれば、専売権付ソフトウェア・ベンダーに囚われ、身動きができなくなる事態を避けることに役立つ。
証拠書類の作成や「ターゲット・オペレーティング・モデル」、進捗状況報告書よりも、実際のユーザーにプロダクトを届けることのほうに重きを置くこと。
開放性や定期的な発表会、ピア・レビューを通じた査定を用いて、進捗を実証するとともに、製品の方向性を変えたり、全面的に廃止したりするためのやり方を把握すること。
実効的ガバナンスとは、定期的に出かけ、自分の目で確かめることを指す。
9. プロジェクトではなく、プロダクト・チームに資金を出す。
プロジェクトとプログラムはしばしば、レガシー創造の原因となるため、むしろプロダクト・チームのほうに継続的な資金供給を行うこと。
実装の方法だけでなく、何を実装するかさえも決定づけるビジネスケースや財務プロセス、契約に注意すること。「リーン／アジャイル・フレンドリー」なビジネスケース・プロセスは中期的に不可欠。
継続的改善の予算を確保すること。必要なスキルの構成やチームの規模は、時とともに変化する。これに対する財務チームの適応を支援すること。
うまく行かないことに資金を使うのを止める勇気を持つこと（アジャイルなビジネスケースは、早めの中止決定を容易にするはず）。
10. つながりをもつ一連の小さなテクノロジーの方を大事にする姿勢を示す。
テクノロジーは決して立ち止まらないという認識のもと、最新技術がコモディティ化した時のことを考えて、恒常的な進化を可能にするシステム・デザインを心がけること。
潜在的な共有能力を突き止める組織的能力を育成し、共通のコンポーネントやプラットフォームを製作するチームに投資すること。
自前で何を構築し、何を拡張し、何を調達するかを、厳密に、批判的に考える（ただし、リスク自体をアウトソースすることできないことに留意する）こと。
テクノロジーや実践がどのように進化しているかを、常に把握できるケーパビリティを築き上げ、備えること。また、新たな機会があれば、それを活用してクリエイティブに試す、実験を行うケーパビリティも構築すること。そのためには、ワードレイ・マップのような技法を用いながら、チームに探索できる余白を与えることも必要。
11. データをインフラとして扱う。
データの海を当てもなく泳ぎ回るのではなく、良質のデータを明確な責任をもって利用すること。
データの管理責任を明確にするとともに、これを組織全体の共有リソースとするためのインセンティブを導入すること。
可能な限り、標準化され、合意の得られた識別子を用いること。
バッチよりもリアルタイムを優先すること。
12. デジタルを単なるオンライン・チャネルとしない。
これらのアプローチをレターや対面ミーティング、物理的空間、パッケージングなどのオフライン部分を含め、サービス全体に適用すること。
アプリやウェブサイト、各チャネルに個別に取り組むのではなく、サービス全体をひとまとまりとしてデザインすること。
サービスのオフライン部分でも、オンライン部分とまったく同じ基礎的データやツールを用い、サービスを一体化すること。
そして最後に、思慮の浅い、荒削りな施策をとるくらいなら、上記のどのルールでも破ってしまっても構わないということ。来るはずのない完璧な状況を待って、何の前進も果たせないよりも、現実的に実践できる、ある程度の前進を遂げるほうがましだからです。
このリストは変更ができないわけではありません。出発点は多くありますが、そのすべてをあらゆる場所で一気に導入しようとはしないでください。いつもと同じく、小さく始めて、最初のプロジェクトを慎重に選び、自分の組織に最も妥当だと感じられるものにフォーカスしてください。あなたの組織で、あなたのチームが実装することに役立つ要素で、イテレーションを行いましょう。将来的に、このリストに独自の項目を加えられるよう、独自の過ちを犯すための時間と空間を取っておいてください。
インターネットの時代は、まだ始まったばかりです。私たち全員が、それに合った働き方をしてゆく時間は残されています。
この記事はPublic Digitalのブログの内容を翻訳しています。
Oct 2018
