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や動画配信など、こだわりを伝えるための手段やツールも身近です。**「趣味」を通じて、仕事と同じように「価値提供のサイクル」を生み出す**下地は整ってきています。

仕事と同じアプローチをとる。つまり、趣味を事業として捉えれば、そこに時間とお金をかけて継続できるはずです。仕事よりも後回しにしてきてしまいましたが、趣味をこれからの人生で十分に楽しんでいける事業のように取り組みたい。「仕事」と「趣味」を同列に扱いたいと構想するようになっていったのです。

構想を実現するべく、自分の時間の使い方も再検討し、仕事においては時間に縛られないような働き方を選択したのです。「仕事」同様、「趣味」に時間を投じ社会への価値提供を行う。これを実現させていくプロセスでは、エンジニアリングや研究にとにかく励んできた10年間が自分を多いに助け、決して無駄な時間ではなかったことにも改めて気付かされました。

## 3. エンジニアリングと研究の手法をプラモデルに応用する

~~こちらも2018年に製作した「MG 1/100 MS-06S シャア専用ザク Ver.2.0」。表面処理や整面処理を勉強して塗装後の表面が綺麗になることを意識した作例です。~~

ゲームとプラモデルという二つの選択肢があるなかで、まずはプラモデルに没頭していこうと思っています。なぜならば、**自分が経験を重ねてきたソフトウェア開発や、研究・論文執筆といった“作品作り”とプラモデル製作には、さまざまな共通点を見出せる**からです。なお、わたしは主にガンプラ（説明不要かもしれませんが、ガンダムのプラモデルのことです）を製作しており、以降は、「プラモデル＝ガンプラ」という前提で筆を進めていきます。

### 塗装のプロセスを、コンポーネント結合に学ぶ

**プラモデル製作における「塗装」は、とくにソフトウェア開発との共通点を感じるプロセス**です。例えばプラモデルでは仮組みといって、一度組み立てた後、分解する工程があります。仮組みすることで「ここのディテールを作り込んでいこう」「ここは、こんな感じの色を塗っていこう」といった方向性を見定めます。

この工程は、さながら**ソフトウェア開発におけるコンポーネント結合**です。いざコンポーネントを結合させていみると、思ってたように動かなかったり、「実はこの実装は、全体としてはあまり性能が要求されないところだから、違う実装を検討すべきでは」といった、思わぬバグや改修箇所が見えてきます。また、実は不要なコンポーネントが存在していた、といった結合前には見えていなかったことに気づけたりします。

各コンポーネントを実装していたり、その実装の細部フォーカスしているだけでは見えてこない、ソフトウェア全体にわたる実装方針と各コンポーネントの改修案が、結合によって改めて検討されだすのではないでしょうか。仕様書の時点ではなかなか想定できなかった問題も見つかることで、仕様へのアップデートを書けることもあるでしょう。

プラモデルの仮組みで得られる視点は、これに似ます。すべてのパーツを“結合”し、完成状態と同じポーズを再現すると、パーツがバラバラの状態ではわからなかった、「よく見える部分、あまり見えない部分」が明確になります。また、ただの直立ポーズではあまり見えなかったであろう間接部分が、実はしっかりと露出する、といったこともわかります。さらに、仮組みをすることで、事前に自分が思い描いていた塗装のイメージが実は違っていた。各パーツ本来の色よりも、もっとこういう色にしたほうが良い、といったアイデアが生まれてきます。自分のなかにあった当初の仕様が、仮組みによってアップデートされるのです。

わたしは仮組みのフェーズで、サーフェイサーという下地塗料を複数色しっかりと塗り、分解後のバラバラのパーツであっても外から見える部分がどこになるかを認識できるようにしています。

このように、**プラモデル製作にはエンジニアリングを通じて得た、さまざまな考え方を適用することができました。**また、以下エントリには他の観点についてもいくつか述べていますので、ぜひご一読ください。

[ガンプラの全塗装プロセスは現代のソフトウェア開発プロセスそのものであると気づいた - 人間とウェブの未来](https://hb.matsumoto-r.jp/entry/2018/02/19/213021)

### 研究で培った手法でプラモデル製作のフローを可視化する

~~こちらは2019年に製作した「MG 1/100 RX-78-2 ガンダムVer.3.0」です。、金属の質感表現、自分の解釈による20以上の塗り分けなど、わたし独自のディテールを複数取り入れることに挑戦した作例です。ブラックライトを当てると装甲の一部が発光したりします。~~

わたしはソフトウェア開発や論文執筆をする中で、**自動化できるところはどんどん自動化する、あるいは、人の判断なく機械的にできる領域を増やす**、というスタンスを大事にしてきました。そうでないと、本来自分が時間とスキルを投じるべきポイントを、見誤ってしまうと考えているからです。例えば、サーバの内部の設定や、複数のサーバノードをシステムとしてデプロイするにも、かつては、自分でサーバを立ち上げたうえで手動で設定し、お手製の設定ツールを流したりすることで対応していました。

ですが、現在ではそういった設定やデプロイはすべてコードで管理しており、必要なコードを変更すれば自動的にその変更が実際のサーバやシステムに適用されるようになっています。こうした自動化の整備は、「自分がラクになる」以外に、後進の方の理解を助ける、という効果もあるでしょう。**自動化を実現する実装コードやデザインドキュメントは、初学者の方にとって「自動化の仕組み」を学ぶ教材**にもなるわけです。

このような経験から、プラモデル製作においてまず取り組んだのは、「どんな作業をすると、どのような結果が得られるのか。その作業を“当たり前”にこなすためには、なにが必要なのか」の調査でした。プラモデル製作には、本当に多くの情報があふれており、ある一定の理解までにかなりの調査が必要でした。

また、ある作業が完成品のクオリティにどの程度影響するか、という点についてもあまり定義されていないこともあり、実際にどのようなプロセスと機材が必要で、どの程度まで作業すればよいのかという点を理解するのもかなり苦労しました。

そこで、自分は研究者であることと、同じインターネット技術に関する[さくらインターネット研究所](https://research.sakura.ad.jp/about/)の研究者仲間で、プラモデル製作を得意とする[菊地さん](https://twitter.com/kikuzokikuzo)、後進への情報提供の意図から材料工学に関する実験を電子ノート化し公開している[熊谷さん](https://twitter.com/kumagallium)とともに、プラモデル製作の電子実験ノートの整備を始めました。

さて、プラモデル製作フローの電子実験ノートですが、その一部は現在、以下のように整備されています。

~~開発中の電子実験ノート。プラモデル製作のフローを整理しています。~~

**プラモデルを完成させるまでに必要な「プロセス」や「機材」などを、フロー図として整理**しています。さらに、それぞれの機材や塗装の手法、各種処理などについては、必要とされる機器のメーカや機器のタイプ、機器をどのように使うか、例えば、エアブラシの圧力や塗装対象との距離、経口サイズ、塗料の希釈比率、湿度、処理の前後の比較写真などを記載し、これを見れば「この設定でこのようにやれば、このようになる」といった情報をストックしています。また、定量評価が難しい工程の場合は、その工程前後の写真を比較閲覧でき、どう変わればその処理が達成できているかの目安も示されます。例えば以下のようにサーフェイサーの項目をクリックすると、その横に詳細が出てくるようになっています。

~~電子実験ノートに記載された作業項目を触ると、その内容が閲覧できます。~~

電子ノートは、まだまだプロトタイプとして研究中ですが、このノートを見た別の人がノートのとおりに作業を行うことで、**「大体似たようなクオリティのプラモデルが制作できる」**という状態にすることを目標にしています。ノートの情報をもとに製作すれば、あまり悩むことなく一定のクオリティのプラモデルに到達できる。そのうえで、個人の力量やオリジナリティが出る場所はどこなのか、といった議論や検討も、よりやりやすくなるのではないかと考えています。

この電子ノートは、プラモデル製作だけでなく、さまざまな用途に使えるようものにしたいと考えており、プラモデル製作のプロセスは電子ノートサービスそのものをブラッシュアップしていくサンプル材料としてのメリットもあります。また、菊地、熊谷両氏が熱意を持って活動に取り組んでくれることが、わたし自身のモチベーションを刺激してくれる側面もあります。

### プラモデル製作環境を整備する

プラモデルのクオリティを追求するためには、事業同様、環境整備への投資も必要になってきます。以下では、エンジニアリング・研究と並行して整備した、プラモデル製作環境を簡単にご紹介します。

~~塗装ブース。右に積まれた箱は塗装ベースといって、塗装や乾燥の際に、パーツを保持してくれる道具です。~~

塗装ブースもいくつか試してきたのですが、やはりエアブラシの吹き返しが室内にかなりの塗料を散布させることに気づき、吹き返しを上部から廃棄する[GATTOWORKSのネロブース](https://www.gattoworks.net/)に落ち着きました。シロッコファン（円柱状のファン）と150mm経口の排気ダクトのおかげで、室内にはほぼ塗料の匂いなどの影響がなくなりました。

~~塗料はケースに入れて整理しています。~~

最近はキャンディ塗装などの重ね塗りの練習や、さまざまな素材の質感表現を試しており、塗料は随分と増えてきました。今はメタリックやクリア系塗料が好きで、ガイアノーツ社の[スターブライトアイアン](http://shop.gaianotes.com/shopdetail/001003000008)という色は特に気に入っています。また、下地にするサーフェイサーも沢山の色があるので、黒をベースに色々な質感を表現できるように何色か揃えています。注目して使用している塗料は同じく[ガイアノーツのプリズムブルーブラック](https://www.gaianotes.com/products/gaia-color_premium.html)です。この色は過去、限定で販売されていましたが、最近ではレギュラー商品として購入できるようになり、もともと紺色がすごく好だったわたしは、すぐに予約して購入しました。いまはこの色を使い、質感などを試しているところです。

キャンディ塗装の作品例は、以下のようにYouTubeにあげていますので、ぜひご覧ください。

ガンプラ MG クロスボーンガンダム X2 ver.Ka メタルビルドを意識したキャンディ塗装とディテールアップ

ガンプラ MG シャア専用ゲルググ ver.2.0 キャンディ塗装

~~気付くと増えている工具たち。~~

よい作業のためには工具はやはり大事で、定番とされるものを使用しています。BMCタガネやドリルビットやスピンブレードなど（上写真上段、下段右の工具）は、ゴッドハンド社のもので、非常に高品質で使いやすいものが多いです。これら工具はプラモデルを削り立体感を出すといったディテールづくりに欠かせないものですが、作業はなかなか難しく、最初はプラスチックの板などで練習を重ねました。ニッパーも、ランナー（パーツを保持している枠）から切り出す先細薄刃ニッパーや、ゲート（ランナーとパーツをつなぐ部分。切り離した際に生じるバリを削り、きれいな面をつくりだすことを、ゲート処理と呼ぶ）をきれいに処理するためのアルティメットニッパーの2種を使用しています。また、細かいゲート処理の際は、デザインナイフも使用します。[アルティメットニッパー](https://shop.godhandtool.com/shopdetail/000000001029/)と[スピンブレード](https://shop.godhandtool.com/shopdetail/000000004837/)が特にお気に入りです。

~~プラモデル製作では、ほんとうにさまざまな形状、材質のヤスリを使います。~~

プラモデルは金型にプラスチックを流し込んで冷やしてランナーを作る特性上、ヒケ（へこみ）やパーティングライン（バリのような余剰）といった凹凸があり、これらを処理しきれいな面をつくる必要があります。また、ガンプラのパーツは複雑な形をしていますが、入り組んだ部分でもうまく凹凸を削りだせるよう、様々な材質、形状のヤスリを用意しています。布やスポンジ、スポンジでも薄型で曲がりやすいもの、表面の面だしをするための硬めの板型、金属製の細いものから広い面積を削るものだったりと、パーツの場所や形状に合わせて使い分けます。ゴッドハンドの[「神ヤス！」シリーズ](https://www.godhandtool.com/products/category/file/01-kami-yasu/)は言わずもがな、最近では、[シモムラアレックのステンレスヤスリぐるぐるBAR](http://shimomura-alec.co.jp/product/product.html#pdnavi2)が金属ヤスリでありながら繊細に削れるので重宝しています。

~~手前がタミヤ、奥に見えるのがクレオスです。~~

エアブラシはこれで3代目なのですが、5mmと3mm口径のものを主に使っていて、定番のタミヤやクレオスの製品を選んでいます。メタリック塗料だったり、大きな面積に一気に吹きたいときは5mm、それ以外の細かい塗装などでは3mmを使うようにしています。最近、エッジの部分など細く塗装する機会が増えてきたため、2mmの口径のエアブラシも使い始めています。

~~エアブラシに空気を送り込むエアコンプレッサーも塗装時に欠かせないアイテムです。~~

エアーコンプレッサーは[ツールズアイランド](https://www.toolsisland.jp/?pid=44423894)の製品を使っています。価格的にも1万円前後と手頃で、秋葉原にある塗装ブースレンタルのお店でも、このコンプレッサーで十分だという情報を聞き、入手しました。エア圧の調整が少しやりにくかったりはしますが、性能としては今の所十分に感じています。

~~製作用ツール満載の作業部屋です。~~

そして、このような全体的な配置で基本的にはスタンディングデスク（上写真右）で研究やエンジニアリングをこなしつつ、ときにはガンプラ製作などを行いながら日々楽しく生活しています。この記事もここで書いています。

と、以上がわたしのプラモデル製作環境の主な機材です。他にもパテやマスキングテープ、接着剤やウェザリング系の道具、部分塗装用の筆やペンなど、細かいアイテムはここでは説明しきれないほどたくさんありますが、それはまたの機会にお話できればと思います。

## 4. 夢はこれから。プラモデル製作を事業化するためには

現在はこのようにプラモデル製作のプロセスと製作環境の整備を行いつつ、数をこなしてスキルを向上させている途中です。

幸い、インターネットを活用してスキルを学ぶ環境も充実しつつあります。とくにYouTubeには先達のモデラーの方々の動画がたくさん上がっており、これらは格好の学習素材といっていいでしょう。例えば、アーリーチョップさんのチャンネルである『[Chop! Factory](https://www.youtube.com/c/ChopFactory/featured)』はガンプラ製作の手法や考え方について非常に勉強になり、繰り返し見ては、その手法を自分の製作で実践しています。特に、[「ストライクフリーダムガンダム」の作例動画](https://www.youtube.com/watch?v=AwZzbfvTRmQ)は大変素晴らしいです。他にも『[ぷらばん Plaban ガンプラ専門番組 Gunpla Build ch](https://www.youtube.com/channel/UCLhze1aqskkJd7npickz6eg/featured)』や『[TOYBALL FACTORY](https://www.youtube.com/c/TOYBALLFACTORY/featured)』といったチャンネルは、オリジナリティあふれる作品もさることながら、動画そのものが面白く、非常に楽しく勉強させてもらっています。

**ソフトウェア開発、研究、そしてプラモデル製作いずれも、作品づくりにおいては、スキルを高めたうえで自分のオリジナリティをどう出すか、という基本的な姿勢が必要**だと思います。前提となるスキル向上のためには、継続的な作品づくりが重要になってくるでしょう。しかし、製作ペースを維持するにも、時間やお金の投下が必要になってきます。わたしの場合、エンジニアリングや研究の分野で一定の収入を確保できつつあるので、ここで得られたリソースをプラモデル製作スキルの向上に投資していくフェーズであると考えています。これもまた一つの技術投資といえるのかもしれません。

過去、わたしが公開してきたソフトウェアや論文は、世のエンジニアの方や研究者の方が研鑽を積むための参照材料として貢献してきたと自負しています。そして、そういった貢献が回り回って自分への報酬へと繋がり、報酬があるから時間と資金を投じて新たな開発や研究、スキル向上に専念できてきたと考えています。今はプラモデル製作でもこうした状況を実現するべく、さまざまな取り組みを日々行っています。

エンジニアリングや研究で培ったスキルを他の分野で活用すること。

趣味と仕事を同列のものにし、人生を楽しむこと。

まつもとりーさんのプラモデル沼。

エンジニア・研究者が再びプロモデラーを目指す - 「好きなこと」を持続的な事業にするために考えたこと【寄稿：まつもとりー】

【事業内容】
■自社パッケージ商品の開発・販売
■各種ソフトウェア設計・開発・評価／検証
■各種コンピューター／ネットワークのシステムインテグレーション事業
■関連機器のシステムインテグレーション事業
■上記関連分野のサービス事業

【自社パッケージ商品】
■SKYSEA Client View(https://www.skyseaclientview.net/)：情報セキュリティ市場における、クライアント運用管理ソフトウェア
■SKYMENUシリーズ：小・中・高等学校・大学に向けたICT活用教育支援ソフトウェア
   SKYMENU Cloud(https://www.skymenu.net/)
   SKYMENU Class(https://www.skymenu-class.net/)
   SKYMENU Pro(https://www.skymenu.net/skymenupro/)
■SKYMEC IT Manager(https://www.skymec.net/)：医療機関向けIT機器管理システム
■SKYDIV Desktop Client(https://www.skydiv.jp/)：大規模ユーザ向けシンクライアントシステム

【取引先企業】
中央省庁／地方公共団体／独立行政法人／公益法人／一般社団法人／アイシン・エィ・ダブリュ株式会社／アイシン・ソフトウェア株式会社／株式会社アドヴィックス／アルプスアルパイン株式会社／株式会社内田洋行／NECフィールディング株式会社／NTT・TCリース株式会社／株式会社エヌ・ティ・ティ・データ／株式会社大塚商会／オリンパス株式会社／KDDI株式会社／コニカミノルタ株式会社／株式会社JECC／株式会社SUBARU／セコム株式会社／ソニー株式会社／SB C&S株式会社／ダイワボウ情報システム株式会社／株式会社デンソー／株式会社デンソーテン／日本電気株式会社／パーソルキャリア株式会社／パナソニック株式会社／富士電機ITソリューション株式会社／富士フイルムビジネスイノベーション株式会社／パーク24株式会社／三菱HCキャピタル株式会社／ユニアデックス株式会社／株式会社リコー／リコージャパン株式会社

【SNS情報】会社情報や、社内写真など雰囲気が分かるような情報を発信しています。
■キャリア採用専用Twitter(https://twitter.com/sky_career_)
　公式Twitter (https://twitter.com/sky_corporate)
■公式Instagram (https://www.instagram.com/sky_it_corporate/?hl=ja)

【Ｓｋｙ株式会社主催「Sky Technology Fair Virtual 2021」開催】
会期：2021/7/12（月）～9/10（金）
https://www.skygroup.jp/event/technology-fair/

Ｓｋｙ株式会社

**自社でプロダクトを開発したいけどSIerでは請け負いの案件ばかり…。**

そのように考えているエンジニアの方も多いのではないでしょうか。

実際そのようなSIerが多いなか、違った動きを見せているのが、Ｓｋｙ株式会社。

請負開発だけではなく、SKYSEA Client Viewをはじめとした自社パッケージ商品も提供しているＳｋｙ株式会社では、**年間売上3,000億円を目指し、自社パッケージ商品に関しては、10年以内に10個以上の自社パッケージ商品を新しく自社開発し、展開していく**ことを予定しています。

Ｓｋｙ株式会社の手がける自社パッケージ商品とは？その開発ではどのような経験を積むことができる？

Ｓｋｙ株式会社で**自社パッケージ商品の開発を受け持つＩＣＴソリューション事業部で事業部長を務めるI.Kさん**にお話を伺いました。

~~Ｓｋｙ株式会社 ＩＣＴソリューション事業部 事業部長 I.Kさん~~

## コロナ禍での自社パッケージ商品の状況

#### balloon and-engineer left
Ｓｋｙ株式会社の自社パッケージ商品といえば、SKYSEA Client Viewのイメージが非常に強いですが、他の自社パッケージ商品についても教えていただけますでしょうか。

### 学校向け市場で圧倒的シェアを誇る「SKYMENU」

#### balloon sky-inamoto right
まずは文教市場、いわゆる学校向けのサービスである[SKYMENU](https://www.skymenu.net/)でしょうか。
**学校向けの管理サービスとしてはSKYMENUは圧倒的シェアを誇っており、3万校以上に導入**いただいています。

#### balloon sky-inamoto right
**2020年から3年間で小中学校の生徒に一人一台のタブレットを配布するというGIGAスクール構想**が掲げられたんですが、**コロナ禍で在宅学習のニーズも高まりGIGAスクール構想が一気に前倒し**になったんです。

#### balloon sky-inamoto right
急激なニーズの高まりに合わせて、3年計画だった開発を1年で一気に進めました。
ソフトウェア開発が間に合わなければこのコロナ禍で十分なサービスを提供できませんでしたし、メンバーはかなり頑張ってくれました。

#### balloon and-engineer left
3年計画の開発を1年で進めるのは本当にすごいですね…！

#### balloon sky-inamoto right
ただ、これで開発を終えたわけではなくこれからもどんどん機能を追加していきます。
**パスワード等を入れられない低学年向けのQRコードでの認証、進級処理や転校処理、保護者や生徒と学校のコミュニケーションなど、必要な機能はまだまだある**んです。

#### balloon sky-inamoto right
また、これからは**高校の生徒に一人一台のタブレットを配布するGIGAハイスクール構想**もあります。
これまでの小中学校向けとはまた違った機能も求められてくるかと思います。

#### balloon and-engineer left
コロナ禍での需要増だけで終わらせない姿勢ですね。
多くの生徒の手元にデバイスが行き届くなか、そこに何を提供していくのかは面白そうでやりがいがありそうです。

### 大規模な組織の業務を支える「SKYDIV Desktop Client」

#### balloon and-engineer left
仮想環境（シンクライアント）を提供する[SKYDIV Desktop Client](https://www.skydiv.jp/)は、テレワークが一気に推進されるなどの影響で、市況が活発になっていますよね。

~~テレワークを安全・便利に実施するためにSKYDIV Desktop Clientができることのイメージ~~

#### balloon sky-inamoto right
2020年から本格的に販売をしているのですが、現在は自治体の案件が多いです。
背景としては、2015年に自治体セキュリティ強靭化という取り組みが施行され、自治体のネットワークを分離しての管理やセキュリティ向上が必要となりました。
ただ、当時はSKYDIV Desktop Clientはなく外資企業のサービスなどが多く導入されたんです。

#### balloon sky-inamoto right
**その仮想環境に入るソフトとして、SKYSEA Client Viewが端末の管理ツールとして多く導入**いただけました。
その後、**5～6年ほどが経ち仮想環境のサービスがリプレイスになるタイミング**で、SKYSEA Client Viewを導入いただいている自治体の方々に、SKYDIV Desktop Clientをご検討いただく機会が非常に増えているんです。

#### balloon and-engineer left
今がまさにリプレイスのタイミングなんですね。

#### balloon sky-inamoto right
仮想環境を提供する製品は専門性が非常に高く、障害発生時の切り分けやサポートでお困りの声を耳にすることも多いんです。
Ｓｋｙ株式会社は国内顧客向けのサポート体制やフォローが充実している面も評価いただき、安心して導入いただいております。

#### balloon and-engineer left
テレワークの導入が増えてくるなかで、SKYDIV Desktop Clientはどのようなアップデートをしているんでしょうか。

#### balloon sky-inamoto right
これまでは単純に仮想環境をつくり、その安全性を確保するという機能が中心でした。
ただ**テレワークの需要が高まり今後も残り続けると思われるなかで必要な機能は増え**ており、オフィス内外で利用できる機能の制限や、テレワークならではのオンラインMTGへの対応、データ流出を防ぐような仕組みなどを中心に強化をしております。

#### balloon and-engineer left
テレワークのニーズに合わせた機能追加を進めているんですね。
SKYDIV Desktop Clientは自治体向けのリプレイス需要があるということですが、民間企業向けの販売もさらに強化していくのでしょうか。

#### balloon sky-inamoto right
**民間企業のテレワークもやはり増えてきており、仮想環境構築の需要は非常にあります**ので、販売を進めてまいります。
物理サーバーの設置などはハードルがあるので、そのためにもクラウドでも動作するよう開発し、提供を進めています。

## 売上3,000億円の実現に向けた「新しい自社パッケージ製品」

#### balloon and-engineer left
SKYMENUやSKYDIV Desktop Clientのほか、Ｓｋｙ株式会社では**新しい自社パッケージ商品の開発も進めている**んですよね？

#### balloon sky-inamoto right
まさに進めています。
これまでの自社パッケージ商品はすべて単独の部署で開発してきたんですが、新しい自社パッケージ商品は**複数の部署と混合で開発するという、弊社では珍しい開発の形態**をとるなど、新しいチャレンジもしています。

#### balloon and-engineer left
なぜそのような体制にチャレンジを？

#### balloon sky-inamoto right
**それぞれの部署の強みを活かして開発**すべきと判断したんです。

#### balloon sky-inamoto right
今回の新しい自社パッケージ商品はOCR等を活用した情報管理系のシステムです。
OCRや複合機が絡む部分は複合機関連開発の部署、業務系システムとの連携部分は企業向け業務システム開発の部署、クラウドのサーバーやアプリケーション面は自社パッケージ商品の開発が担当しています。

#### balloon and-engineer left
それぞれの部署が専門性の高い領域を担当しているんですね。
この形式の開発でよかった点や大変だった点を教えてください。

#### balloon sky-inamoto right
複合機や業務系など**それぞれの詳しい領域の情報共有やお互いの理解が一層進みましたし、開発効率は非常に良かった**ですね。
それぞれの得意分野を担当したことでスムーズに進みましたし、今後も同様の開発スタイルで商品開発を進める可能性が生まれました。

#### balloon and-engineer left
**様々な領域に質の高い開発チームがいる**Ｓｋｙ株式会社だからこそ実現できた開発形式ですね。
お話を聞いていると、今回のサービスは、これまでＳｋｙ株式会社が手がけてきた自社パッケージ商品とは少し違う分野・違うシーンで使われるものなのかなと感じます。

新しい記事