Rubyとシビックテックの素敵な関係！ RailsとDecidimで“DIY”な市民活動に参加しよう

Ruby on Rails（以下「Rails」）はご存じでしょうか？　15年以上の間、活発に開発が続けられている老舗のWebアプリケーションフレームワークです。

RailsはさまざまなジャンルのWebアプリケーション開発に活用されているのですが、その中でも最近筆者が注目しているアプリケーションにDecidimがあります。これは、「シビックテック」と呼ばれる分野と深く関わりのあるアプリケーションです。

この記事では、シビックテック、Railsとその関係について紹介しながら、Decidimが描こうとしている市民社会とテクノロジーの未来について、といったちょっと大きな話を書いてみたいと思います。技術的な細かい話は書かないつもりなので、ITエンジニアだけでなくIT技術に興味のある人にも広くお読みいただけるとうれしいです。

シビックテックとは

最近では「FinTech」「EdTech」などなど、「なんとかテック」という名前（ちょっと気取った言い方では「X-Tech」と呼ぶそうです）の技術をよく聞きます。最近のはやりなんでしょうか。「シビックテック（CivicTech）」はその中でも比較的古参にあたるようで、10年ほど前から使われていた用語になります。

もっとも、シビックテックという言葉は誰かがこれといって提唱したことではなく、「Civic Technology」の略語としてなんとなく自然発生的に生まれたようです。シビックテックという言葉よりも前に使われていた用語に「Government 2.0」（Web 2.0の二番煎じみたいなやつですね）や「e-Government」といったものがあり、これらは政府や行政を電子化する、といったトップダウンの方向が強そうです。それに比べると、シビックテックは草の根型の活動も含めている傾向があります。

具体的な定義としては、例えば「The Civic Tech Field Guide」では、「the use of technology for the public good（公益のためのテクノロジーの活用）」という定義を掲げています。広く公共分野に向けた技術であれば、何でもシビックテックに含めてしまおうというものですね。これはシビックテックの最もシンプル、かつ広義の使われ方でしょう。

もうちょっと限定した表現としては、稲継裕昭氏らによる『シビックテック』という書籍に「市民主体で自らの望む社会を創りあげるための活動とそのためのテクノロジーのこと」という定義が載っています（勁草書房、iiページ）。ここでは「市民主体」が「自ら」創り上げる、というのがポイントで、自分たちのために技術を使う、という意味がこめられています。

これを強調した表現としては「DIY」が分かりやすいかもしれません。現在シビックテックが注目を集めているのは、何かしらの形で市民が積極的に関与できる、ということに対する期待もありそうです。

さらに細かく、具体的なシビックテックのジャンルについて見てみましょう。ジャーナリズムやコミュニティの領域におけるアメリカの非営利財団であるナイト財団のシビックテックの分類によると、以下の表のようにまとめることができます。

さらに、先ほどのThe Civic Tech Field Guideでは、40以上のものジャンルのもと、膨大なシビックテックのプロジェクトが紹介されています。このように、市民と社会に関わるさまざまな活動が、シビックテックというカテゴリーのもとで行われているのです。

もっとも、市民が自分たちで何か新しいことを始めるにしても、何もないところから突然人が集まり、活動が始まることは難しいでしょう。

日本でシビックテックを推進する団体としては、「Code for どこそこ」という地域の名前を冠した団体が、北は札幌（Code for Sapporo）から南は沖縄（Code for Okinawa）まで全国各地にあります（これらは「ブリゲード」と呼ばれているそうです）。

こういった地域の活動母体とは別に、Code for Japanがあります。Code for Japanはシビックテックコミュニティづくり支援や、自治体への民間人材派遣などの事業に取り組む非営利法人で、本記事で紹介するDecidimの運用も行っています。

海外のシビックテック組織としては、g0v（零時政府）があります。こちらは台湾のシビックテックの分散型活動組織で、2012年に設立され、現在でもさまざまな活動を行っています。日本でもよく知られているオードリー・タン（@audreyt）もその中心メンバーの1人です。ちなみにg0vの発端は、Yahoo!台湾のハッカソンに参加した高嘉良（@clkao）たちのチームが優勝した際、その賞金を元手に活動を始めた、ということだそうです。

Decidimについて

Decidimはシビックテックがその対象としている領域のうち、行政に対する提案・意見・議論や、意思決定の機能を提供するサービスです。……と言ってもいまいち漠然としてよく分からんと言われそうですが、要は物事を「決める」ためのあれやこれやを提供しているのです。「Decidim」という単語自体、スペインのカタルーニャ語で「決めよう」「決める」といった意味だそうなので、まさにそのままですね。

自治体で物事を決めるには、普通は議会や委員会などで決められたり、役所などの行政組織で決められたりするかと思います。しかし、本来であればそこに住む人たちの意見も何かしら取り込めることができるのであれば、それに越したことはないわけです。

とはいえ、Decidimは既存の市区町村の行政組織や議会に取って代わる、というものではありません。それらがある程度機能している前提で、さらに補完する役割を担うことを目的としています。この辺りがシビックテックなところです。

これだけインターネットとSNSが発達し、TwitterやFacebookに大量の言葉があふれる現在、普通にIT技術を使えば住民の意見を集約することくらいできるのでは？　と思うことは不思議ではありません。こういった動きのことを「参加型民主主義（participatory democracy）」とも呼びます。Decidimは「都市や組織のための自由・オープンソースによる参加型民主主義（Free Open-Source participatory democracy for cities and organizations）」のプラットフォームなのです。

もっとも機能だけを見ると、Decidimはちょっと変わったSNSプラットフォームに見えるかもしれません。サービスのアカウントを作り、そこで自分の意見を書いたり、他の人の意見にコメントを返したり、また賛成・反対を示したりします。

Decidimにはさまざまな機能があります。

● 戦略プラン策定 ●参加型予算編成 ●住民参加型計画立案 ●調査（サーベイ） ●討論 ●投票 ●ミーティング開催支援 ●ブログ ●ニュースレター

もっとも、全ての機能を使う必要はありません。むしろ、最初は最小限の機能しか使わない方が良いでしょう。たくさん機能を並べても混乱するだけになりそうです。これらの機能は、サイトの管理者の方でどの機能を使うか・使わないかを選択できるようになっています。

さらに、データの透明性についてはとりわけ配慮されています。参加者が自分のデータをまとめてダウンロードできたりするだけではなく、管理者が複数いる場合、他の管理者が何をしたかのアクションについても全て記録されます。

Decidimは、実は最初はオリジナルのアプリケーションではありませんでした。2015年、バルセロナ市議会がDecidimプロジェクトを始めるにあたっては、CONSULというソフトウェアから派生したアプリケーションとして「Decide Madrid」というサイトが作られました。CONSULもDecidimと同様の参加型民主主義のためのソフトウェアです。

Decide Madridは一定の手応えがあったようなのですが、他の自治体でも利用したいという要望が生まれたことから、2016年、Decidimは利用する組織ごとに自由に拡張できるアーキテクチャーを備えた、別の新たなアプリケーションとして再設計され、生まれ変わりました。これが現在のDecidimになります。

この新生Decidimの開発は、2016年8月17日から始まり、最初に公開されたリリース版であるv0.0.1が公開されたのが2016年の12月、そこからv0.1.0がリリースされたのが2017年の5月と、その後も定期的にリリースを重ねています。現在の最新版はv0.24.3であり、次のv0.25.0がリリース準備されているところです。

DecidimのライセンスはAGPL v3（GNU Affero General Public Licence）です。これは、自由ソフトウェアを進めるGNUが定めたライセンスの中でも最も厳しくソフトウェアの自由を保証するライセンスで、Decidimを修正したプロジェクトはもちろん、SaaS的な提供する場合でもソースコードを開示することを必要とするものです。Decidimは自由なソフトウェアであり続けることを重視しており、そのスタンスが反映されたものだと言えます。

Decidimの開発は、当初はバルセロナ市議会主導で進められていましたが、現在ではdecidim associationが主導しています。また、Decidimの機能追加や修正については、技術的な部分はGitHubから、仕様的な部分はMeta Decidimから参加できます。

Meta Decidimもその実体はDecidimアプリケーションで、ソースコードも公開されています。いわゆるドッグフーディングというやつです。Decidimについての意見集約や意思決定もDecidimで行えるというのは、その目的からすると当然ではあるのですが、ちょっとかっこいいように思えます。

Decidimを支えるRuby on Rails

Decidimについて一通り紹介したところで、それを支えるフレームワークであるRuby on Railsについても紹介しましょう（ちなみにConsulもRails製です）。

Railsは、2004年に公開されたWebアプリケーションフレームワークです。「フレームワーク」というだけあって、DBを使ったWebアプリケーションを作るための基本的な機能が一通り揃っており、コマンドラインでのコード生成機能を使うと簡単なアプリケーションの骨組みがさくさく作れる、というものです。

当初はDavid Heinemeier Hansson（通称、DHH）が1人で開発していましたが、現在はRailsコアチームによる開発体制となっています。名前の通り、プログラミング言語Rubyで開発されており、そもそもWeb開発においてRubyの存在を世界中に広める役割を果たしたのが、このRailsになります。

Railsの特徴は、2021年では特にめずらしいところではないですが、いくつか挙げてみます。

● MVCアーキテクチャー（モデル・ビュー・コントローラーに分かれる） ●フルスタックフレームワーク（基本的な機能については個別のライブラリを組み合わせる必要がなく、全部入りになっている） ●設定より規約（統一された命名規則等で細かいことを考えずに済ませつつ、多少の逸脱もできる） ●Active Recordパターンを強化したORマッパー（データベースアクセスが超便利） ●作者の強烈なこだわり（Opinionated softwareとも言われるくらい癖もあるけど慣れると便利）

比較的小規模のチームでDBを駆使するWebアプリケーションを開発するのに向いていて、最近ではAPIを提供するバックエンドサーバーを作ったりするのにも使われます。

ある意味でDecidimはやや大きめのRailsアプリとしては、あまり奇をてらってない、素直な構造になっています。

Railsではアプリケーションを開発するにあたり、MVCそれぞれに対応するクラスをmodels・views・controllersの各ディレクトリ以下に作っていくのですが、ある程度以上の規模になるとMVC以外のクラス用ディレクトリを用意することが多いです。Decidimでも、FormクラスやCommandクラス、Serializerクラスなどを各機能ごとに作るように拡張されたディレクトリ構成になっています。大きめのRailsアプリに触れたことのある人であれば見慣れた雰囲気を感じることができるでしょう。

RailsアプリケーションとしてのDecidimの特徴的な点は、「Rails Engine」を駆使しているところにあります。Rails Engineというのは、Railsアプリケーションに機能を提供する「ミニRailsアプリ」のようなものです。Engine自体にもMVCの各クラスを持たせることができて、そのEngineを使うRailsアプリケーションからそれぞれ利用することができます（逆に、EngineからRailsアプリケーションのMVCを直接参照することはできません）。

Rails EngineはRailsの公式ガイド（日本語訳）にも掲載されている標準的な仕組みではあるのですが、正直使いこなしが難しい大仕掛けの道具で、Engineをほとんど使わないRailsアプリの方が一般的かと思います（貴重な例外が認証によく使われるDeviseライブラリで、Deviseは実はRails Engineになっています）。

ところがDecidimでは、このEngineをめちゃくちゃ駆使しており、管理機能用も合わせると実に50以上のEngineが標準で使われています。むしろDecidimのほとんど全て、99％以上はEngineとして提供されています。実際にDecidimアプリケーションの本体でやることは、Engineを組み込んでちょっといじるだけ、と言っても過言ではありません。

実際、Decidimアプリの一般的なroutingファイル（config/routes.rb）は、以下のようになります。

――――――――――――――――――

require "sidekiq/web" Rails.application.routes.draw do 　mount Decidim::Core::Engine => "/" 　authenticate :user, ->(u) { u.admin? } do 　　mount Sidekiq::Web => "/sidekiq" 　end end

――――――――――――――――――

1行目と、4行目〜6行目はsidekiqという非同期のJob処理基盤の管理画面用なので、sidekiqを使わないことにすれば3行で済んでしまうわけです。Railsのroutingファイルと言えば、普通は数百行・数千行あってもおかしくないレベルなので、このシンプルさはびっくりですね。

Decidimの機能紹介で挙げた「参加型予算編成」や「討論」「調査」といった各機能は、それぞれ「decidim-budget」「decidim-debates」「decidim-surveys」といったEngineで実装されています。さらに、新しい機能を追加する場合も、新しいEngineとして作成すると、それを取り込むことができるようになります。Rails Engineは、Decidimの根幹を担っています。

Railsのアーキテクチャとシビックテック

ところで、DecidimのようなWebアプリケーションにRailsを使うメリットはどういったところになるのでしょうか。

まあ実際のところは「たまたまRailsで作れそうだったから」という程度の理由しかないのかもしれませんが、勝手に推測してみます。

ここで言う「低コスト」というのは、例えばサーバーの費用等ではなく、主にマンパワーの方のコストです。 シビックテックによくありそうな問題に、開発と運用のための継続的なコストの捻出が難しい点があります。

ビジネスとしてWebサービスを開発するのであれば、サービスが成功すればその収益を元手にしたり、資金調達を行うなどして開発・運用コストを捻出するのが一般的でしょう。ところが、シビックテックでは「成功すれば収益が上がる」というモデルは一般的ではありません。別に参加者が増えたりコメントが増えたりしたところで、運用コストを回収できる何かがあるわけではないのです。

一方、個人サービスであれば、開発者個人が気の向いたタイミングで開発したり、気が向かないときには開発をサボったり運用を中止してしまったりすることも可能でしょう。それで文句を言う人は使わなければよい、と開き直ることもできます。しかし、広く使われるシビックテックのサービスとしては、そこまで割り切ることもできません。何か問題が起きてしまったら、即時ではなくても対処する必要があります。

Railsの場合、もともと小さいチームでも開発しやすいところが特徴ですし、さらに強力な規約のおかげもあり、ちゃんとレールに乗っているアプリケーションであれば（←ここは重要なポイントです）あまりコストをかけずに手を入れることができます。運用についても、変わったことをしていなければ、一般的なRailsの運用ノウハウがそのまま使えるでしょう。

Decidimは「自由かつオープンソースソフトウェア」であること、そしてオープンかつ協同的であることを重視しています。

Decidimのホワイトペーパーを見ても、Google、Microsoft、Amazon、Facebookといった独占的なプラットフォーム企業に対する警戒感を隠していません。一方で、それに対抗するものとして、自由なソフトウェア・ライセンスやクリエイティブ・コモンズ・ライセンスによる自由なデジタルサービスを強力に支持しています。この辺りは、ヨーロッパではアメリカの巨大企業にインフラを独占されてしまうことに対して危機意識が強い、ということも背景としてありそうです。

Railsは特段自由・フリーであることをうたってはいませんが、Rails Doctrineとして「Push up a big tent（大きな傘を広げる）」という項目があります。Railsはもともとクラウドプラットフォームが整備される前から作られていたという経緯もあり、最低限WebサーバーとDBサーバーさえ用意すれば、RedisやAWS S3等を使わなくてもDecidimを稼働させることは可能です。

もっとも、特定のクラウドでしか使えない機能も当然利用できます。例えばAWSを使う場合、画像アップロード等のストレージとしては、ファイルシステムではなくAWS S3等のマネージドなオブジェクトストレージを使ったり、セッション情報のストレージにDynamoDBを使ったりすることもできます。また、ジョブキューの処理にもsidekiqではなくAWS SQSを使うため、AWS SQS Active Jobを使ったり、サードパーティ製のshoryuken gemを使うこともできます。

クラウドプラットフォーム独自のマネージドサービスを利用して省力化を図ることもできるし、そのような独自サービスは一切使わないで運用することもできる、というのがRailsによる中立性の担保となっています。

ところで、Railsの問題点として、モノリスアーキテクチャーである点が指摘されることがあります。マイクロサービスが流行しつつあることを踏まえて、最後にこれも簡単に触れておきます。

マイクロサービスの利点としては、だいたい以下のような点が挙げられます。

１．デプロイ単位を細かく分けられる ２．異なるアーキテクチャーを混在させられる ３．マイクロサービス単位でスケールさせやすくなる ４．独立した機能を疎結合・高凝集にできる

もっとも、マイクロサービスは、どのような言葉で表現したとしても、ある種の分散システムであることには変わりません。前述の運用コストの問題を考えると、多少のメリットがあったとしても、分散システムのようなリスクを考慮しなければなりません。

2021年現在、オープンソースアプリケーションとして何十何百といった環境で動かす前提のソフトウェアをマイクロサービスとして開発し提供し、本家の開発チームとは特に関係ない人が運用する、というのは、限定された用途のアプリケーションだったり、特定のクラウドのマネージドサービスを使う前提のアプリケーションだったりする以外では難しいのではないかと思います。

上記の利点で最も気になるのは、最後の疎結合と高凝集の点でしょうか。マイクロサービスは各サービスごとに境界がはっきりしており、サービスごとの結合は疎に保ちつつ、サービス内の凝集度を高める形を強いられます。これはDecidimのようなアプリケーションでも大きなメリットになるかもしれません。

整理されていないRailsアプリの場合、依存関係がこんがらがっていて、どこで何が起きるか分からなくなってしまうことは十分ありえます。そうなると、手を入れるコストが無視できなくなる可能性もあります。Railsでも、何かしらのモジュール化を行いたくなります。

そのようなモジュール化されたモノリスには、「モジュラーモノリス」という名前がつけられています。モジュラーモノリスは、「デプロイユニットは依然として単一であるものの、それは静的にリンクされた複数のモジュールで構成される」ものであり、「マイクロサービスアーキテクチャの課題の多くを回避しつつ、多くのメリットを提供できる」ものとされています（Sam Newman『モノリスからマイクロサービスへ』O'Reilly Japan、79ページ）。

Rails Engineは、まさにRailsでモジュラーモノリスを実現するための強力な武器です。マイクロサービスの集合で1つのアプリケーションを作るのと似た効果が、Engineの集合で1つのRailsアプリケーションを作ることによって生み出されています。Decidimのような複雑な機能を持つRailsアプリケーションは、モジュラーモノリスの恩恵を享受しています。

おわりに

g0vが2014年に公開した「First Year of g0v.tw（初年のg0v.tw）」の冒頭では、「我々は、過去20年以上に渡り自由ソフトウェアのコミュニティによって確立されたモデルに従い、（略）ソーシャルメディアをソーシャルプロダクションのためのプラットフォームへと変容させた。」と書かれています。

現在ではオープンソースソフトウェアはごく当たり前の存在になっており、Webアプリケーションやスマートフォンアプリの開発などでは、オープンソースソフトウェアを一切使わないという選択肢はほぼ現実的ではありません。オープンソースのムーブメントにとって「仮想敵」と言っても過言ではないほど激しい対立関係にあったマイクロソフトですら、その技術力を注ぎ込んでいる自社開発のソフトウェアがVisual Studio CodeやTypeScriptというオープンソースソフトウェアであり、それが広くIT業界を席巻しつつある時代です。

一方で、「ソフトウェアが世界を飲み込む」ことが本格化しつつある現在、市民社会に対してもソフトウェアが強い影響を与えつつあります。もちろん、ソフトウェアそのものが影響力を持っているのですが、実際のソフトウェアの開発にはその開発スタイルも密接に関わっており、開発・運用のための技術とその文化がソフトウェアとともに進化しています。

2014年、g0vはひまわり学生運動（学生による台湾立法院の占拠）において、HackfoldrやHackpad等による情報の集約・提供や、現地でのネットワークと配信作業などを行っていました。オードリー・タンはこの活動について、OSDC.tw 2014で行った発表の中で、「中立性（Neutrality）」と「オープン性（Openness）」と「透明性（Transparency）」の重要性を強調しています。中立性を保つこと。オープンであること。透明性を守ること。これはまさに「自由ソフトウェアのコミュニティによって確立されたモデル」の中で培われてきた価値観ですが、その価値観こそが、ひまわり学生運動を支える原動力となっていたのでした。

「市民社会を良くする活動」と「FLOSS（自由ソフトウェアとオープンソース）の活動」とは一見かけ離れており、また安易に比較することも慎むべきかもしれませんが、そこにはお互いに学ぶべきことが多々あるようにも感じられます。そして、2020年代のITにおけるオープンネスの文化は、このような社会とITとの密接な関わりの中から生まれていくのかもしれません。

編集：はてな編集部