2020年10月、とあるインディーソーシャルゲームがこの世に生み出されました。

なんとこのゲーム、**うんこを題材としたゲーム**なのです。

衝撃的なタイトルでデビューしたそのゲームは、「*課金の代わりにうんこの報告をする*」という斬新なシステムで、SNSなどで有名になりました。

~~ 課金する代わりに、便の形状や色を報告するシステムとなっている。 ~~

一見、かなりのバカゲーのように見えるこのゲーム。
しかし開発の背景には、**一人の医師のいたって真面目な目的**と、*それに共感し開発を手伝う開発メンバーの思い*がありました。

今回は、『うんコレ』製作者にして医師である石井洋介さんと、エンジニアとして開発を担当した宮崎さんに、『うんコレ』の開発秘話、そして「うんコレ」に込めた思いを伺いました。

~~ 氏名: 石井洋介 2010年高知大学医学部を卒業後、初期臨床研修中にコンテンツによるブランディングにより高知県の臨床研修医増加をもたらした「コーチレジ」を立ち上げた。その後、大腸癌等の知識普及を目的としたスマホゲーム「うんコレ」の開発・監修、「日本うんこ学会」の設立を行う。また、ゲームだけでなくニコニコ超会議に医療ブースを出展するなど、エンターテイメントファーストな医療情報の発信による健康情報格差の是正の可能性を模索し、多方面から活動している。 ~~

~~ とあるシステム会社のSE。実務では開発の上流から下流まで工程にとらわれずシステム開発を実施。「ヘルスケアハッカソン」にて「日本うんこ学会」に出会い入会。以降私的活動として「うんコレ」の開発に携わりつつ、アプリ開発の進行取りまとめも実施。「うんコレ」のリリースへと導く。 ~~

## 「うんこ」で行動変容！？うんコレが目指す健康とは

#### balloon and-engineer left
全年齢対象でうんこを題材にしたゲームってなかなか攻めてますよね…。
どうして「うんコレ」を開発しようと思ったんですか？

#### balloon uncolle-dr-isi right
ゲームの名前から悪ふざけとかノリだと思われがちですが、真剣な理由があります。
「うんコレ」は*大腸がんなどの消化器系の病気で苦しむ人を１人でも減らす*ためのゲームなんです。

#### balloon and-engineer left
どういうことでしょう？

#### balloon uncolle-dr-isi right
うんコレでは、ガチャを回すために自身のうんこを観察する「**観便**」をして、ゲーム内で報告しなければなりません。
この観便がキモで、観便によって**消化器系の疾患を早期発見できる場合がある**んです。

~~ うんコレでの観便の報告の様子。観便し報告することで、ガチャを回すことができる。 ~~

#### balloon uncolle-dr-isi right
*よりよいキャラを手に入れるために必死になっていたら、いつの間にか観便をしている。*
それによって便の異常に気づき、ひいては消化器系の病気を発見できるという仕組みです。

#### balloon and-engineer left
ゲームを遊んでいたらいつの間にか病気が見つかるなんて、私みたいなズボラな人間にはすごくありがたいです。
でも、*ここまで「うんこ」を全面に押し出すのはちょっとためらいません…？*

#### balloon uncolle-dr-isi right
むしろ**「うんこ」というワードが重要なんです。**
2013年の※バカサミットで知ったのですが、「うんこ」はSNSのバズワードなんです。
うんコレの拡散には、タイトルにうんこを入れたことも寄与していると考えています。

※日本を代表する先進バカ企業が集う進化系イベント

~~ 2013年に第5回を迎えたバカサミット。[バカサミットHP](http://www.baka3310.com/)より ~~

#### balloon uncolle-miyazakisan right
もちろん、扱っているテーマが「うんこ」だからこそ、*気をつけた部分もあります。*
UIやSEは女性にもプレイしていただけるように、なるべく**爽やかさ**を出せるように意識しました。

#### balloon and-engineer left
様々な人にプレイしてもらうための工夫をされているんですね。

#### balloon uncolle-dr-isi right
爽やかさを意識する、というアイデアは女性のデザイナーの方が提案してくださったんです。
実はうんコレのクリエイティブチームって、**女性が多いんです。**

#### balloon and-engineer left
うんこがテーマなんて男子小学生が考えたようなゲームなのに、女性が多いんですか!?

#### balloon uncolle-dr-isi right
そうなんですよ。
我々も最初は理由がわからなかったので、女性メンバーになぜ協力してくれる気になったのか聞いてみたんです。
すると、*女性は便秘などお通じの問題で悩むことが多く、うんこに関心を持っている方が多い*ということがわかりました。

#### balloon uncolle-dr-isi right
私は消化器外科医をしていますが、男性なこともあって女性にうんこについて詳しく聞く機会ってほとんどないんです。
だからこそ、**女性がうんこ関心層**だというのは改めての気づきでした。
便秘で悩んでいる人が多いことは知っていましたが、*医師に相談しにくいから一人で悩んで自力解決を目指していたんです。*
普段の医師としての活動の中では聞きづらいことを聞けたので、医師としても勉強になりました。

~~ 左が開発途中の画面で、右がリリース時の画面。淡い色が多くなり、爽やかさが増している。 ~~

#### balloon and-engineer left
**女性だからこそうんこに思い入れがある**場合があるんですね。
手段として「ゲーム」を選ばれたことにも、理由はあったんですか？

#### balloon uncolle-dr-isi right
ゲームが、*健康に興味のない人に医療情報を届ける手段*だったからです。
いわゆる医療情報発信アプリを作っても、**健康に興味のない人は見てくれないんです。**
でも、健康に興味のない人でも、大腸がんなどの消化器系疾患を発症しますよね。

#### balloon uncolle-dr-isi right
*医療情報が届かなかったために発症に気づかず、手遅れになることは少なくありません。*
医師として多くの手術を経験してきましたが、病気が進行しきっていて助けられなかった患者さんもたくさんいます。
それに、*私自身も血便が出ていたことを重大なことと認識できず*、病状が悪化してから病院を受診し、潰瘍性大腸炎と診断を受けました。
その後もなかなか医師の言うことを受け入れられずに悪化し、**人工肛門になった**という経緯がありました。

~~ 大腸がんは、がん死亡数の順位でも上位にきている。また、症状もがんが進行しないと出ないため、「サイレントキラー」と呼ばれている。[最新がん統計 国立がん研究センターHP](https://ganjoho.jp/reg_stat/statistics/stat/summary.html#anchor1)より ~~

#### balloon uncolle-dr-isi right
そういった人たちを1人でも少なくするために、ゲームという形で情報発信をすることに決めました。
それにゲーム、特にソシャゲは*ユーザの方の熱量も大きい*ので、その熱量がうまく働けば、ユーザの観便を促進できるんじゃないかと考えています。

#### balloon and-engineer left
普通の方法だとアクセスできないユーザに医療情報を届けるために、ゲームを選択されたんですね。

#### balloon uncolle-dr-isi right
そうですね。
*医療情報は知りたい人にだけ届ければいいわけではない*ですから、そこが一般の商業サービスと違って難しい部分です。

## マネタイズを諦めることで、クリエイターが全力を出せる場所へ

#### balloon and-engineer left
うんコレはフルボイスですし、非商業用にしてはすごくリッチなゲームですよね。
企画からリリースまではどのくらいかかったんですか？

#### balloon uncolle-dr-isi right
プロジェクトの原案ができてからリリースまで、という意味だと**7年**くらいかかりました。

#### balloon and-engineer left
7年…！
かなり長期のプロジェクトなんですね。
なぜそれほど長い開発期間になってしまったのでしょうか？

#### balloon uncolle-dr-isi right
**開発をすべてボランティアでやってもらっている**のが大きな理由です。
メンバーの稼働量をグリップできないので、どうしても開発が不安定になってしまいます。
リリース後も、*アップデート頻度が不安定になりがち*なので、いまでも悩みの種です。

~~ うんコレ開発メンバーの募集ページ [日本うんこ学会HP](https://unkogakkai.jp/bosyu)より ~~

#### balloon and-engineer left
7年もかかるのであれば、お金を払ってコミットしてもらったほうが良かったんじゃないですか？
これだけ話題になるゲームなら、広告やガチャで回収できそうですし…。

#### balloon uncolle-dr-isi right
うんコレは*広告もガチャへの課金もあまり期待するべきではない*と思ったのです。
課金は募金という形で一応できるようになっているのですが、デイリーパスのように観便を報告してもらったときの報酬を増やせることがお得なようにしてあり、**可能な限り観便をしてもらうという意欲が落ちない**ように設計しました。

~~ うんコレの募金画面。うんコレ保険証を買ってかんべん報告をするのがお得なシステムになっている。 ~~

#### balloon and-engineer left
もったいなくないですか！？
課金してもらえれば人も雇えるし広告も打てるしで、もっと多くの人に使ってもらえそうなのに。

#### balloon uncolle-dr-isi right
私も悩んだんですが、うんコレの性質上これはしょうがなかったんです。
たしかに健康食品の健康に関する広告は入れれたかもしれません。
しかし、*広告を入れてしまうと、どうしても特定の商品が売れるように誘導する必要が出てきます。*
これは*医療者としてちょっと看過できない*ので、広告を入れることはしませんでした。

#### balloon and-engineer left
ガチャへの課金はなぜ導入しなかったんですか？

#### balloon uncolle-dr-isi right
課金してガチャを回せるということはすなわち、観便の代わりにお金を払ってもらうことになります。
*我々はユーザにお金を払ってほしいのではなく観便をしてほしい*ので、ガチャへの課金を導入してしまうと本末転倒だったんです。
うんコレは、スタート時点から私の**医療者としてのこだわりのせいでマネタイズできない**運命だったんです。

#### balloon and-engineer left
ソシャゲなのにマネタイズを捨ててたんですね…！
ちょっともったいない気もしますが。

#### balloon uncolle-dr-isi right
まぁそうですね、セオリーが何もわかってないとよく言われます（笑）
ただ、*マネタイズしないことによるいい部分もたくさんありました。*
制約が少ないままでいけるので、あらゆる場面で開発メンバーが楽しいと思う方向に思い切って舵をろうと意思決定することができたんです。

#### balloon uncolle-miyazakisan right
僕自身も普段はWebエンジニアなんですが、触ってみたかったクラウドやUnityに挑戦させてもらいました。
なんならエンジニアはゲーム開発経験があるメンバーはほとんどいませんでしたし、みんなで勉強しながら進めてましたね。

#### balloon and-engineer left
これだけ大きなプロジェクトで好きに経験を積める、というのはたしかに魅力的ですね。
エンジニア以外の方々はどういったモチベーションで参加されていたのでしょうか？

#### balloon uncolle-dr-isi right
モチベーションは様々なので一概には言えないのですが、あるクリエイターの方が、「うんコレは*初めて思い切って自分の能力を投資できる場所*」だと言ってくださったのが印象深いです。
*自分のクリエイティブな能力が医療の役に立つかも知れない*、というのが大きかったんだと思います。

#### balloon uncolle-dr-isi right
そのクリエイターの方はソシャゲの開発に関わられていたのですが、普段の彼らのクリエイティブに求められることは、*いかに熱中させ課金させるかだったようです。*
当時、子供の重課金が問題視されていた時期でもあり、**大好きだったゲームが子供に対して悪影響を与えている**と批判されるのはとても辛かったようです。

~~ 消費者庁のオンライゲームトラブルのページ。重課金はソシャゲの普及ともに問題となっていった。[消費者庁HP](https://www.caa.go.jp/policies/policy/consumer_policy/caution/internet/trouble/online.html)より ~~

#### balloon uncolle-dr-isi right
ただ、その技術が正しく使われれば、*何らか人の役に立てる可能性を持っている*のではとも考えていたときに、僕の話を聞いて参加を決めてくれました。
うんコレではクリエイティブの目的は**ユーザに健康になってもらう**ことなので、同じ技術でも惜しみなく全力を発揮できたとおっしゃっていました。

#### balloon and-engineer left
うんコレの開発は社会貢献でもある、ということですね。

## 「仕様書を書かない」ことで開発速度を維持!?

#### balloon and-engineer left
うんコレは規模の大きいプロジェクトだと思いますが、何人くらい開発に関わられてるんですか？

#### balloon uncolle-dr-isi right
クラウドファンディングで支援していただいた方も含めると500人ほどになりますが、*開発に関わってくれた方だけでも50人以上です。*
最初のころは各々知り合いを誘って輪を広げていましたが、ニュースになるなど注目されていくと、「1枚手伝いたい」という方がTwitterなどのSNSを介して集まってくれました。

#### balloon and-engineer left
50人！やはりたくさんの人が関わっているプロジェクトなんですね。
内訳が気になりますが、どんな方が多かったんでしょうか？
やはりゲームエンジニアの方ですか？

#### balloon uncolle-dr-isi right
*キャラクターを描いてくれるイラストレイター*や、*SEやBGM、ボイスといった音声を提供してくださるクリエイターの方*が多かったです。
絵や音声といったクリエイティブは一点物でお手伝いしていただくことが可能なので、参加しやすかったのが大きかったと思います。

~~ 背景や敵キャラクターのイラストをクリエイターの方が提供してくれたことにより、ゲームのクオリティが上がっていった。 ~~

#### balloon uncolle-miyazakisan right
逆にエンジニアの方は少なくて、開発にかかわってくれたのが10人、アクティブに開発していたのが3、4人くらいです。

#### balloon and-engineer left
エンジニアの方はそんなに少なかったんですね。
なにかワケがあるのでしょうか？

#### balloon uncolle-miyazakisan right
*「うんコレ」は仕様がほとんど決まっておらず、*一機能だけ開発してもらうみたいな参加方法がとりづらかったのが大きかったと思います。
参加してもらうのであれば、*コードの変更が必要になった場合に対応していただけるくらいのコミットをしてもらう必要があったんです。*

#### balloon and-engineer left
仕様書がなかったんですか！？
エンジニアが一番嫌がる現場だ…。

#### balloon uncolle-miyazakisan right
Readmeのような開発済みの機能の詳細すら、ほとんど書けていません。
機能の詳細が知りたいときには、**開発した人に聞きに行ってました（笑）**

#### balloon and-engineer left
もしかして、リリースが遅れた原因って、開発がカオスだったからですか…？

#### balloon uncolle-miyazakisan right
むしろ逆で、仕様を丁寧に決めて、Readmeも書いて…って進め方だったら、**あと5年はリリースできなかったと思います。**

#### balloon and-engineer left
段階を踏んだ開発をしていたらリリースが遅れる…？
どういうことでしょうか？

#### balloon uncolle-miyazakisan right
うんコレの開発がボランティアだということはお伝えしましたよね。
では開発が何によって進むかというと、**参加者のモチベーションなんです。**
つまり、参加者がやる気になれれば開発が進むし、気の進まない作業ばかりだと開発が滞ってしまいます。

#### balloon uncolle-miyazakisan right
だからこそ時間をかけて仕様をガチガチに決めるといった、*みんながやりたくないことは極力やらないようにすることが重要だったんです。*
企業でやるんだったら完全にバッドな方法ですけど、「うんコレ」の開発ではこれでよかったと思っています。

#### balloon and-engineer left
参加者の方のモチベーションに開発速度が依存してしまうのは、ボランティアならではの難しさですね。

## インディーゲーム開発者にメリハリをもたらすのは、「ゲームショウ」

#### balloon and-engineer left
7年間開発をされてきた中で、完成させるために意識されたことはありますか？

#### balloon uncolle-miyazakisan right
**ニコニコ超会議やゲームショウに出すのは意識してやっていました。**
毎年3、4件くらいは出したと思います。

#### balloon and-engineer left
たくさん出展されてきたんですね。
でも、かなり準備や申込み含め大変なんじゃないでしょうか？

#### balloon uncolle-miyazakisan right
デメリットを上回るメリットがあるんです。
まず、プロジェクト外の方にプレイしていただけるため、**ゲームに対する率直なフィードバック**がもらえます。
ボタンの配置からゲームデザインまで、*色々な面で改善すべきポイントを把握できるんです。*
いただいた意見や反響は、モチベーションにもなります。

企画：ニコニコ医学会〜今、医師としてみんなに伝えたいこと〜 | ニコニコ超会議2019 公式サイト

~~ ニコニコ超会議2019にも、石井先生が参加している出展がある。 ~~

#### balloon uncolle-miyazakisan right
これは普通の企業だとユーザテストとして常日頃からやられていることなので、当たり前だと思われるかも知れません。
しかし、我々のようなボランティアでの開発や個人開発などの小規模な開発だと、*ユーザテストの機会を持つことが費用・時間の観点からなかなか難しいんです。*

#### balloon and-engineer left
ユーザテストの場として役立つ、ということですね。

#### balloon uncolle-miyazakisan right
あとは、イベント出展を決めると、**間に合わせるために開発が進むんです。**
区切りを設けることで、開発にメリハリを産むことができます。
*個人開発やボランティアでの開発だとどうしても間延びしがち*なので、いい目標になったかなと思います。

#### balloon and-engineer left
他のことで忙しくて開発を後回しにしてしまい、結果としていつまでも完成しない…みたい話は個人開発でもあるあるですよね。
ゲームショウへの出展は、個人開発の中でもゲーム開発をしている人たちは特に参考にできそうです。

#### balloon uncolle-dr-isi right
個人でゲームを開発されている方の中には、*完成度の低い段階で出展することを恥ずかしいと感じる方もいらっしゃると思います。*
ですが、ゲームデザインのミスなど、**開発が進んでしまうと修正しづらい問題点**に気づけることのメリットは大きいです。
ラフな段階でもどんどん出していくという心意気が大事だと思います。

## 病気の発見も！うんコレがもつ健康への影響とは

#### balloon and-engineer left
リリースされて※７ヶ月ですが、反響はいかがでしょうか？

※ 2020年5月にインタビューを実施

#### balloon uncolle-dr-isi right
やっぱり、**うんコレのおかげで病気が見つかった**という報告をいただけたのは嬉しかったです。
アプリ内観便を報告したらアラートが出て、病院に行ってみたら*本当に腸炎になっていた*そうです。

う○こをテーマにした衝撃のゲーム「うんコレ」。おふざけで作られたゲームかと思いきや、消化器外科医の代表のもと、50人以上のエンジニア・クリエイターがボランティア参加した健康増進のためのアプリでした。今回は消化器外科医で代表の石井さんとエンジニアの宮崎さんに、うんコレのリリースまでの開発秘話をインタビューしました。


うんコレはふざけたゲームではなく、健康行動の普及・促進を目的としたゲーム

うんコレは開発段階でマネタイズを諦めたが、そのおかげでクリエイターが全力を発揮できるようになった

インディーゲーム開発にメリハリを持たせるための鍵は「ゲームショウへの出展」

うんコレはユーザだけでなく、開発者の健康にも寄与している

う○こなのに社会派!? 大便の報告でガチャを回すゲーム「うんコレ」をボランティアで開発できた理由とは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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](https://consulproject.org/en/)というソフトウェアから派生したアプリケーションとして「[Decide Madrid](https://decide.madrid.es/)」というサイトが作られました。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](https://www.gnu.org/licenses/agpl-3.0.ja.html)（GNU Affero General Public Licence）です。これは、自由ソフトウェアを進めるGNUが定めたライセンスの中でも最も厳しくソフトウェアの自由を保証するライセンスで、Decidimを修正したプロジェクトはもちろん、SaaS的な提供する場合でもソースコードを開示することを必要とするものです。Decidimは自由なソフトウェアであり続けることを重視しており、そのスタンスが反映されたものだと言えます。

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

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

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

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

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

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

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

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

### DecidimでのRailsアーキテクチャ

ある意味で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の[公式ガイド](https://guides.rubyonrails.org/engines.html)（[日本語訳](https://railsguides.jp/engines.html)）にも掲載されている標準的な仕組みではあるのですが、正直使いこなしが難しい大仕掛けの道具で、Engineをほとんど使わないRailsアプリの方が一般的かと思います（貴重な例外が認証によく使われる[Devise](https://github.com/heartcombo/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の[ホワイトペーパー](https://docs.decidim.org/en/whitepaper/decidim-a-brief-overview/)を見ても、Google、Microsoft、Amazon、Facebookといった独占的なプラットフォーム企業に対する警戒感を隠していません。一方で、それに対抗するものとして、自由なソフトウェア・ライセンスやクリエイティブ・コモンズ・ライセンスによる自由なデジタルサービスを強力に支持しています。この辺りは、ヨーロッパではアメリカの巨大企業にインフラを独占されてしまうことに対して危機意識が強い、ということも背景としてありそうです。

Railsは特段自由・フリーであることをうたってはいませんが、[Rails Doctrine](https://qiita.com/takahashim/items/85380dff5eec3bd99a6c)として「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による中立性の担保**となっています。

### モジュラーモノリスとしてのDecidim

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

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

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

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

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

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

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

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

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

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

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

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

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

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

スペイン生まれの「Decidim」は「シビックテック」をサポートするオープンソースソフトウェアで、Ruby on Railsの自由で中立なアーキテクチャの利点を反映しています。

「シビックテック」とは、市民が公益のためにテクノロジーを積極的に活用する草の根型の活動

スペイン生まれの「Decidim」は、参加型民主主義をサポートするオープンソースソフトウェア

Ruby on Railsで実装されたDecidimは、Railsの自由で中立なアーキテクチャの利点を反映している

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

こんにちは。松本亮介と申します。インターネットやSNS上では「[まつもとりー](https://twitter.com/matsumotory)」と呼ばれることが多いです。

わたしは、インターネットやWebサービスの基盤技術に関するエンジニアを経て、現在はインターネット基盤技術について研究をしている研究者です。また、複数の企業において、事業組織の改善や事業・プロダクトマネージメント、技術的課題、技術ブランディングなどに関するアドバイス活動に技術顧問として取り組んでいます。これまでの実績は、[松本 亮介（まつもと りょうすけ）の研究・開発業績ページ](https://research.matsumoto-r.jp/)に書いています。

そんなわたしが、本稿でテーマとするのは**「プラモデル製作 / プロモデラー」**です。エンジニアリングでも、インターネット基盤技術でもなく、プラモデル。この時点で頭の中にはてなマークが出ている読者もいることでしょう。実はわたしは、2018年ころより、かなりのリソースをプラモデル製作に投下してきました。本稿ではなぜわたしがプラモデルに傾注するのか、その理由、経緯、思いなどをお伝えしていこうと思います。いたって本気で本稿を書いておりますが、まずは面白半分に読んでいただければと思います。

実はこの写真は僕の作業場です。

~~エンジニアリング、研究、そしてプラモデル製作を行う部屋の様子です。~~

この記事も以下の写真の机で書いています。

~~作業部屋を別の角度から。このスタンディングデスクで研究開発しています。~~

## 1. 「趣味」と割り切り、自分の気持ちに蓋をする後ろめたさ

2008年あたりから2018年まで、とにかくエンジニアリングと研究に没頭してきました。さらにさかのぼり、大学生であった2005〜2007年あたりも、多数のサーバを置いたデータセンターかのような自室で遊んでいました。さまざまな「技術」が常にわたしの傍らにありましたが、特に深くのめり込んだのは、**課題解決や新しいテクノロジーを生み出すためのプログラミング**でした。わたしにとって、最初は課題解決の手段という位置づけにすぎないプログラミングでしたが、徐々にそれ自体におもしろさにを感じるようになっていったのです。また、プログラミングを「ひとつのソフトウェア」にまとめ上げ公開し、他者に使ってもらいフィードバックを得て、自身がつくったソフトウェアがよりよいものへと洗練されていくプロセスも、自分にとってとても気持ちよく、刺激的なものでした。

その結果、2014年には[第9回日本OSS奨励賞](https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%ACOSS%E5%A5%A8%E5%8A%B1%E8%B3%9E)を受賞し、また、より深く技術を突き詰めるべく進学した[京都大学大学院情報学研究科では、2017年5月に京都大学博士（情報学）も取得](https://rand.pepabo.com/article/2017/05/24/doctor-matsumotory/)できました。

このように、それなりにキャリアを築いてきた自負がある一方で、ゲームやプラモデルといった、「エンジニアリングや研究以外で人生で取り組んできたもの」とはかなり疎遠になっていたのです。「まあ、これらは趣味だから仕事が忙しければ疎遠になるのも仕方ない」と思い込むことで、気持ちを落ち着かせようとする自分がいました。

### 小学生の頃から最も時間をかけたゲームとプラモデル

ゲームとプラモデルは、わたしが小学生のころから自主性を持って傾倒してきたものでした。特に格闘ゲームに熱中し、ゲームセンターで大人にまぎれながら、ストリートファイターや餓狼伝説、龍虎の拳といったシリーズを夢中でプレイしていました。大学生になると週7でゲームセンターに通い、強者が集まるゲームセンターに遠征するほどの没頭ぶりで、いつしか、ゲームセンターの[KOF98の大会で優勝](http://www.hoshikari.com/testtama/tennpo/keka/n_result.htm#200504)したり、[全国大会に出場できるような腕前になっていったのです。](http://www.a-cho.com/ac/200607_12/duel98_20060916.html)

ゲームと並行して、プラモデルも小学生のころからたくさん作ってきました。誕生日などでは必ずといっていいほどプラモデルを買ってもらい、ガンプラや戦艦、歴史的建造物といった、さまざまなプラモデルを夢中で組んでいました。小学校低学年のとき、兄と一緒に片道10kmの山道を歩き、SD戦国伝の闇皇帝((SDガンダム BB戦士というプラモデルシリーズの1体))を買いに行ったことを、いまでもはっきりと覚えています。

### プロゲーマーを簡単に諦めた過去

大学までに人生で一番真剣かつ継続的に取り組んだのはゲームとプラモデルといっても過言ではありません。ですが、就活の時期になると、当たり前のように周りや社会に流され、ゲームやプラモデルを仕事にする、なんてことは視界から消えていきました。「ゲームはどうせ趣味」。こう考えるようになると、熱量は徐々に失われ、いつしかゲームセンターに行くことすらなくなっていったのです。

その後、就職し数年たったころ、かつてわたしと同じように格闘ゲームをプレイし、全国大会で顔を合わせていた人たちが、プロゲーマーとして活躍し始めている、と見聞きするようになりました。こうしたニュースに触れるほどに、わたしの心はざわつき、かつての自分の考えの浅さに、押しつぶされそうになっていたのです。

ゲームだけでなく、プラモデルも同じでした。「プロモデラーになど、わたしはなれない」と勝手に思い込み、人生の選択肢からも簡単に外していたのです。いま振り返ると、当時のわたしには、「好きなこと」への覚悟や情熱が足りなかったのでしょう。むしろ、「好きなこと」を趣味として処理することが、理性的で賢明な選択だとさえ思っていたのです。

### やりたいことを諦めた後にとにかく心身削って学び続けた10年

ゲームやプラモデルづくりからから遠ざかる一方で、エンジニアリングや研究にどんどん没頭していく自分もいます。高い技術を持つ先達の背中を追いかけ、毎日のように朝まで課題解決のためにコードや論文を書き、成長が実感できる日々に快感や楽しさを感じていることに気付きます。**コードを書いて作り上げたソフトウェアや、研究を進めて得られた新規性や有効性をまとめた論文などのアウトプットを、いつからか自分の「作品」と感じるようにもなっていたのです。**

## 2. 転職後、自分の幸せを見直し再びプラモデルへ

~~2018年に製作した「MG 1/100 MSN-06S シナンジュ・スタイン Ver.Ka」です。当時は説明書通りにいかにちゃんと作るかにこだわっていました。~~

心身を削りプログラミングと研究に励む10年を経て、わたしにも転機が訪れました。現在の職場である、[さくらインターネット研究所に転職](https://hb.matsumoto-r.jp/entry/2018/09/11/191601)し、比較的ゆっくりとマイペースに研究に取り組める環境を得たのです。いくらか時間に余裕ができ、改めて**「自分の幸せはなにか？仕事ってなんなんだろうか？」**と考えるようになっていったのです。

プログラミングや研究は確かに好きなことであり、これから先も生きがいにしていきたいと思える対象です。しかし、その生きがいのために「趣味」の優先度を低くしたままでいいのか。仕事が忙しければ「趣味」に時間は割けない、と仕事と趣味が主従関係にあることが本当に自分にとって幸せなのだろうか。こんな疑問が次々と生まれます。

プログラミングや研究は仕事でありながら、趣味同様、「好きなこと」として10年にわたり時間やお金を投じることができました。なぜ仕事に関しては熱量を維持し、継続的な取り組みにできたのか、と考えると、仕事のなかに、**「わたしと社会、相互の価値提供」**を見出していたからだと思います。仕事で得られる成果をソフトウェアや論文という形で社会に提供する。提供するから、社会からフィードバックや、ときに評価という形で、わたしにも価値が還元される。そうして得られた価値を、わたしの次なる仕事に回す。とても単純なサイクルですが、こうしたサイクルがあったからこそ、「趣味」のように仕事を楽しみ、「もっとスキルを向上させて、より良い価値を提供したい」と、モチベーションも保たれていたのでしょう。では、こうしたサイクルは仕事でなければ生み出せないのか。もしかしたら、**「趣味」として片付けていたものであっても、同じように価値提供のサイクルを作れるのではないか。自分の好きなこと諦めない人生を創出できるのでは。**こんな風に考えるようになっていったのです。

### 好きなことを、持続的な事業として捉える

例えば、YouTuberの方の活動は、特徴的な生活や活動で人々を楽しませ価値提供し、自身にその対価が還元されていると解釈できます。わたしを仕事に没頭させた「価値提供のサイクル」と同じと言っていいでしょう。

わたしが「趣味」の優先度を下げてしまったのは、YouTuberのように趣味を通じて社会に価値提供できず、また、提供するための手段が揃っていなかったという要因があるでしょう。しかしいま、ありきたりな情報が蔓延して刺激が薄れつつある時代にあって、人々のこだわった趣味こそ、多くの人を楽しませ、価値を提供できるかもしれません。また、SNSや動画配信など、こだわりを伝えるための手段やツールも身近です。**「趣味」を通じて、仕事と同じように「価値提供のサイクル」を生み出す**下地は整ってきています。

新しい記事