Code for America のレポジトリで公開されている civic-tech-patterns の内容が興味深いので、適宜注釈も加えつつ記事にしてみたいと思います。原文はかなり柔らかめの英語のように見えるので、この記事の中には、私に起因する誤訳も多く含まれていると思いますが、その点ご容赦ください。
シビックテック・パターンは、シビックテックの構想や設計をする時によくある実施を記述するものだとのことです。ライセンスは3項BSDで「Copyright (c) 2013, Code for America All rights reserved.」とのことですね。テキスト本体については、2018年の9月11日に更新がされているようです。
設計パターン
行動すべきことをわかりやすく示すこと
プロセスを明確にわかりやすく説明したり、次にするべき行動のステップを示したりすることに集中せよ、とのことです。官僚主義の巨大な壁を一気に壊すようなことはこころみず、その壁を登ったり、乗り越えたり、回避したり工夫する人の手を具体的にとることが重要だと言っているようです。
既存のオンラインプラットフォームにいる人を巻き込むこと
一からさいきょうのオンラインプラットフォームを立ち上げるのではなく、既存のオンラインプラットフォームにいる人たちを巻き込むべきだ、とのことです。これも合理的ですね。
実際に行動がされているか、行動が必要なところにリーチする
これは、リアルな現場にリーチするということと、リーチする仕方において積極的かつ伝わりやすいメッセージングを行うということのようですね。
公式採択を目指す
公式採択、あるいは既存のリソースの置き換えを目指すべきであると言っています。そのためには、エンジニアリングプロセスよりもソーシャルプロセスを重視することが必要な場合もある、と言っています。確かに、勝手サービスも良いものですが、アテンションを食い合ってしまうので、公式採択を目指して努力を行うということが、結果的に全体の目標達成に貢献すると思います。目標達成のために努力するつもりが、リソースを細分化することになった、では、もったいないですよね。
アイディアパターン
新解釈をする
あまりに典型的な体験だとか、典型的な巻き込みスタイルではなくて、より創造的で面白く、馬鹿げた巻き込み型をするのがよいとしています。ただし、明確なアクションステップを欠くことがあるので注意、ということのようです。確かに、参加型のプロセスの中で紋切り型の作業を行おうとすると、求心力を失うような気がするので、これも大事な気がしますね。
検索して調べる
トピックやイシューについて Google で検索し、よくある問いやフレーズをおさえよ、と言っています。
また、これも大事なポイントだと思いますが、自分のプロダクトは、既存のトップランクのプロダクトよりも主観的によく、また Google 検索結果でも上位に来るように作れ、と書いてあります。確かに、負ける戦いはしないことが重要ですね。
自分で試す
自分が全機能を and/or 定期的に使うようなアプリを作れと言っています。自分にとってめちゃくちゃ使えるアプリであれば、他の人にとっても意味があるだろう、と言っています。
既存のコミュニティを見つける
問題や痛みを発見し、介入できる可能性を探すなら、既存のコミュニティを見付けだせ、と言っています。そうすることで、ユーザベースを得ることもできるし、何より、問題を既に理解しているユーザ集団を見つけることができます。
プロセスをデジタル化する
既存のプロセスを より簡単に、より速く、より良く、より強くするツールを作れ、と言っています。「それを紙や電話によって、すでに誰かがやっていますか」と聞くところからはじめ、それをデジタル化しようとするプロセスを回すことで重要な社会的やりとり（social interaction）を実現できる、みたいなことを書いている気がします。
social interaction を通じた知見の吸収が重要であるとしているようにも読めるところに、面白さがありますね。
モバイル対応する
閉じられたフォーマットで定式化している情報をスマートフォン対応することで、その情報が必要な時、必要な場所で必要な人に伝わるようにします。
個人的には、スマートフォン上のフォームの技術的寿命とのバランスを見ながら考える必要もあると思いますが、これは、一つのヒットしたパターンだと思います。他方で、やはり管理されなくなったモバイルアプリがアメリカでは散見されており、これをうまく回収していく必要は今後あるように思います。
大事なことをやる
現場にいる人にとって大事なことをやっているか、という観点です。管理スタッフにとって役に立つだけの機能よりは、現場にいる人に役立つことを重視しているようです。
これは、クラシックなエンタープライズアプリケーションにありがちな失敗に対して警戒線を張っているようなところがあるように私には思えて、なかなか興味深いです。
ビジネスモデルを持つ
「これに誰が拠出をし、その拠出はどのくらいなのか」ということを、思考実験の段階からでも問え、と書いています。これを問うことにより、自分たちの企図が非常に明確になってくるからなのだそうですね。顧客を見つけたり、プロダクトの価値を整理したりするにあたっても、ビジネスモデル重要、とのことです。
持続可能なプロダクトを作っていくことで、分野全体の評価も高めていく、という観点から、あらゆる行動がビジネスモデルを持つということは、とても大事だと私も思います。
技術的才能の橋渡しをする
行動が行き詰まっている要因が時間なのか、資金なのか、スキルなのか明確にするということのようです。作業の90%をできる技術的才能を持っているのに、システムからデータを引っ張り出すところができないだけ、といったことがあるかもしれない、と言っています。
これ、重要な観点ながら解決は意外と難しそうですね。技術専門家が気軽に技術の情報を交換できるネットワークが必要です。 Code for America というのは、そういうことができるネットワークであるということに価値があるのかもしれませんね。
開発の前に理解
プロセスをアプリケーションに実装する前に、そのプロセスを他人に説明できるくらい理解しているか確認せよ、ということのようです。そのプロセスを実際にたどった専門家になれているか、と問うています。
これも、とても重要ですし、残念ながらクラシックな役務発注方式だと、これがなかなか実現しづらいというところがありますね。
プロダクトよりイベント（A happening）
ここの原文の意味を、私はよくわかっていないかもしれませんが、こういうことだと思います。恒久的なプロダクトを作るよりも、一過性の経験を提供するほうが変革的になる場合があるので、そういった短くて一回限りの経験を作り出すことも良いパターンだ、ということのようです。
計算機がなんでも記憶できるからといって、計算機が得意とすることばかりに屈服する必要はない、といったことが書いてあります。
設計アンチパターン
アンチパターンは絶対的な悪というわけではなく、コミュニティアウトリーチやコンテンツ作成、コミュニティ管理といった非技術的な要素に非常に依存しているために、頻繁に達成困難になるものである、と書いてあります。それ自体は技術的な絶対悪ではないからこそ、はまりやすいアンチパターンである、ということですね。
ものごとプロセス全体の単位で考える必要がある、ということだと思います。
シビック CMS
「コミュニティカレンダー、ソーシャルネットワーク、ブログ、地図...を備えたサイトが欲しい。」というアイディアはもっとも退屈なやりとりモデルであり、そういうサイトは実現したとしても早晩廃止されてしまうとのことです。
「これを誰が定期的に更新してくれるか。」ということをまずはじめに考えるべきであり、次に「どうしてこれを誰かが読んでくれるだろうか。」と考えるべきだとのこと。
新たな独立 CMS を立ち上げるくらいであれば、Facebook ページやメーリングリスト、Google カレンダーあるいは Twitter フィードを使うべきであると言っています。
SMS もついてます
スマートフォンを所有しない人のために SMS （ショートメッセージサービス、だと思います）に対応します、という発想だと、真にニーズやコンテキストに対応できないというようなことが書いているようです。
確かに、配慮したつもりが、余計な複雑さだとかサービスレベルの低下のようなものを抱え込んでしまう可能性がありますね。やるとしたら、本当にうまくやらないとフォーカスを失うような気がします。
プロセスから人間を排除する
プロセスをオンラインにしてしまうと、効率が下がったり、人間のあいだの貴重なコミュニケーションを無くしてしまう可能性があります。
昔は電話でやりとりをしていた、サービス提供者間での細部の交換が、オンライン化によってされなくなった、というような事例があるそうです。
実際にはゲームではないゲーム
バッチを出すような仕組みは、ゲームではあるかもしれなけれど面白いというわけでもなく、それは面白いというよりは単に中毒性を導入するだけになるそうです。既存の大きなシステムと連動しているというようなことがない限り、そのアプリかぎりのバッチは中毒性すら導入しないとも書いてあります。
「百万人がこのアプリを使ったら...」
百万人がそのアプリを使うことを想像するのではなくて、一人のユーザ（できれば、作者自身）がこのアプリを使うことをまず想像すべきで、次に、２番目のユーザがすぐに得られる利益を想像するべきだとのことです。
Google で見つけてくれるよ / 作れば使ってくれる
実際には、そんなことはありません。
それから、友達に紹介してくれると思う
その人たちが最初の段階に来た人でもない限りは、友達に紹介してくれるというようなことも起こりません。
アイディアアンチパターン
ネガティブな側面に集中する
犯罪マップ、レストラン検査、ごみ、詐欺、虐待、こういったものは有益なアプリケーションではあるものの、シビックテックではこのようなアプリケーションが多すぎる傾向があるそうです。また、こういったアプリケーションは人々の先入観に挑戦するようなところはほとんどなく、作業のはじめに背景となるデータを使って作り上げた適切なプロセス、施策、政治に対して人々を啓発することもないと書いています。
複雑なことを単純化して考える
複雑でニュアンスに富み、よって理解することが難しいプロセスやデータセットを、安易で反射的なアクションに煮詰めてしまうことです。これは、「ネガティブな側面に集中する」と連動することが多いです。
相関関係と因果関係の同一視
酒類販売ライセンスと犯罪率を同じマップに重ね合わせることができるからといって、その重ね合わせをやるべきだということにはなりません。
相関関係と因果関係は同一ではありません。あなたのデータビジュアライゼーションについて語るべき良いストーリーがない限りは、安易にデータを重ね合わせることで人々を道に迷わせるべきではありません。
地図にのせる
そんなことを安易にやりるのはやめるべきで、その代わりに「地図がどんな価値をもたらすのか。」を問うべきです。地図よりも、リストやチャート、あるいは普通のテキストのほうが読者にとって有益かもしれません。
これは耳が痛いと私も思いますね。地図が必要ないところで、ただそれができるからという理由だけで地図がある場合があります。これをやると、本来の文脈にとっても、地図にとっても、良いことがありません。
「これは面白いね」 / まがいものの調査ジャーナリズム
発信は目的をもって行うべきです。ただそれが存在するからという理由だけで、公的なデータセットをオンライン化するべきではありません。銃の所持者の住所リストを、ただそれがあるからという理由で発信した新聞のようになるべきではありません。
ただし、技術を学ぶための演習としてそのようなことを行うのは、例外だとしています。
いきどまり
アクションステップがないのであれば、何の意味があるでしょう。ページが行き止まりであることは、時には問題ないですが、ユーザをそのページに誘導したのであれば、なんらかの理由があるはずです。
ニッチなツール
ニッチなツールを作っているはずが、汎用のよくできたツールのほうが本来のニーズによく答える形になることがある、ということをここでは言っているように見えます。
マネジメントの問題
エンタープライズ的なマネジメントの問題をアプリケーションに実装することの問題をここでは言っているように見えます。
ユーザロールや認可権限、監査システムについて理解を深めたとしても、システム上のデータにアクセスしたり、システムにデータを入力する人々のために何かを簡単にしたかという観点こそが重要であるということを言っているようです。
これは、エンタープライズシステムではよくある話だと思いますし、すごく重要な観点だと私も思います。
競合の発見をしない
すでに何がなされたか、あなたがどこに居場所を見つけるか、あなたがどこに価値をもたらし得るか、既存のサイトは問題ないものであるか、そういったことをしっかり考える必要があるということのようです。
いまだ享受されたことがない機会はたくさんあり、そういった機会を享受するところから始めた方がよいそうです。そうした上で、既存のコミュニティを探すほうがよいとのことです。
実践よりも意図が強い
人々がやりたい(あるいはやるべきだと思う)けれども、結局はやらないことについてアプリをつくる衝動にかられるかもしれません。
例えば、会議後のフォローアップのためのソーシャルネットワークというのは、会議の場では素晴らしいアイディアのように見えますが、実際には使われることはないでしょう。
プロジェクトやタスクの進捗を助けるよりも、むしろ人々を苦しめるようなプロジェクト/タスク管理ツールというのも、そういったものだとのことのようです。
私のためではない
ユーザがやりたいことではなくて、あなたがユーザにやってほしいことを扱うアンチパターンです。あなたは人々にもっと上手に協力してほしいでしょうけれども、その人々はもっと上手に協力したいと思っているでしょうか。そもそも、人々は協力に対して投資したいと考えているでしょうか。
アルゴリズムが決める / 技術的な問題だ
行政の能力の不足や住民の混乱が問題であるのであれば、そういった問題はウェブサイトでは解決されません。それは言った上で、デジタルツールを公式採択のために設計することができるかもしれません。
いつも使ってくれるだろう
私のホームスクリーンにあるのは Google, Facebook, New York Times であって、あなたのアプリではない、ということを認識する必要があるとのこと。
シビックアプリケーションの類型
Esri の記事によれば、シビックアプリケーションは次の７種類に分類できる、と書いてあります。
- Public Information
- Public Reporting
- Solicited Comments
- Unsolicited Comments
- Citizen as Sensor
- Volunteerism
- Citizen as Scientist