市民開発者が1人で抱え込まないためには？「Distributed Development」を踏まえた体制づくり

市民開発の強みのひとつは、業務アプリをつくるヒトが、業務を知る現場の人材であるという点です。自らの業務を深く理解し、その現場課題を起点にアプリを構築することで、現場に根ざした改善をスピーディに実現できます。このように、ユーザーと開発者が重なり合う構図は、今までのシステム開発にはなかった市民開発ならではの特徴です。

これまでの記事では、市民開発を推進する上での定義や、その基盤となる三つの要素「ヒト」「ツール」「仕組み」について触れ、ただ個人のスキルや熱意に依存するのではなく、市民開発者を組織の中でどのようにサポートし、定着させていくかの仕組みづくりが重要だと紹介しました。

しかし、現実的には、組織の中で市民開発に適した人材が現れると、ついその人に業務を任せたくなってしまいます。スキルや意欲のあるメンバーに対して、自然と期待が集まりすぎてしまうことで、市民開発者への負担に偏りが出るケースも少なくありません。こうした状態を防ぐためには、それぞれの役割や責任を個人任せにせず、組織としてしっかりと仕組みに落とし込むことが大切です。

そんな時に意識しておくべき考え方が「役割の所在を明らかにすること」です。今回は、2023年のノーコードサミットで登壇されていたJack Marrowさんが提唱する「市民開発者が“ひとりで抱え込まなくていい”ようにする体制づくり：Distributed Developmentの考え方」について紹介します。

Distributed Developmentという体制づくり

Distributed Development（ディストリビューテッド・ディベロップメント）とは：
組織によるサポート体制の中で、市民開発者がソリューションアーキテクトから技術的なサポートを受けながら、現場の業務改善に取り組む体制のことです。そして、現場で生まれたアイデアやアプリが会社全体の業務にも活用され、必要に応じて社内外の専門家やベンダーの支援を受けられること、と定義されています。

この考え方は、市民開発者をはじめ、関わるヒトそれぞれが「自分はどんな役割を担うのか？」という役割分担が明確になっていることが大切だとしています。

Distributed Developmentは直訳すると「分散型開発」となります。一般的には、ソフトウェアやシステム開発において、複数の拠点やチームが連携して作業を進める開発スタイルとして使われる言葉ですが、ここでは市民開発における新しい考え方、体制づくりの意味として登場しています。

市民開発が抱える矛盾、市民開発者は“ただの市民”に？

この考え方が必要とされている背景には、市民開発が抱える矛盾にあるとMarrowさんは話しています。

市民開発者が、現場で価値のあるアプリを生み出し成功事例が増えるほどに、社内で開発依頼が増えたり、期待を一心に集めるようになります。一見、ポジティブなことに思えるかもしれません。しかしその結果、自身の本来の業務との両立が難しくなり、やがて「市民」としての立場から外れ、開発者そのもののような役割を求められるようになってしまうケースもあると言います。
またMarrowさんは、皮肉とも捉えられる次のような一文を、登壇の中で言いました。

“Punished with more work（成功の代償としての業務負荷）”

そして、ついには市民開発に関わることそのものが負担となり、開発から離れ、ただの「市民」に戻ってしまう、そうしたケースも実際に見受けられる、とも指摘。

このような状況は、珍しいことではありません。市民開発の導入の可否を問わず多くの企業が、その人の得意・不得意やスキルに応じて業務が属人的に振り分けられることがあります。たとえば、現場の若手に対して「できるから任せる」「頼りにしているよ」といったポジティブな意図のもとで、結果的に業務に関する負担を一人に集中させてしまう構造が存在してしまいます。その結果、アプリを開発した本人が退職・異動した後に業務が止まってしまう、修正方法がわからないなどのブラックボックス状態を生む事例も少なくありません。

こうした“「優しさ」にみえる任せ方”が、実際には属人化と責任の押し付けを招いています。そんな経験を持つ企業は多いのではないでしょうか？

“ひとりで抱え込まなくていい”ようにする体制を支える3つの役割

このような矛盾や課題を解決するために、Marrowさんは「役割の分担」とそれを支える体制の整備が不可欠であると話しています。Distributed Developmentを構成するのは、次の3つの役割です。

1. 市民開発者（Citizen Developer）

• 業務を理解し、ノーコードで自ら課題解決を行う現場の人
• 実務に即したアイデアと行動力を持つが、支えられる存在であることが前提

2. ソリューションアーキテクト（Solution Architect）

• 技術的視点から、市民開発の成果をスケール可能な形に育てるサポーター
• セキュリティ、拡張性、全体最適といった観点から課題の整理・構造化を担う人材

3. 市民開発推進室（Center of Excellence）

• ガバナンス、ポリシー、リスク管理などを通じて市民開発全体を支える専門部門
• 必要に応じて外部ベンダーと連携し、体制づくりと人材育成を行う

市民開発者は現場の課題をもとにアプリを構築する役割を持ち、ソリューションアーキテクトは全体最適や技術面からの支援を担う役割、市民開発推進室は支える仕組みを整える役割を持ちます。

この3つの役割はそれぞれが責任を持ちながらも、市民開発者は技術的な判断をソリューションアーキテクトに任せることができます。ソリューションアーキテクトはガバナンスやリスク管理といった全社的な統制を市民開発推進室に委ねることで、連携しながら市民開発を支える体制をつくることができます。

これこそが、市民開発者が“ひとりで抱え込まなくていい”ようにする体制です。このように役割と、それに伴う責任の所在を明らかにすることが、持続可能な市民開発を支える鍵になります。

どのように自社に取り入れていくのか？

この考え方は海外の大企業の事例などをベースに作成されたという要素が強いため、そのまま日本の中小企業やチーム単位に導入するのは難しいと感じられるかもしれません。

しかしDistributed Developmentの本質は、「責任の所在を明確にし、支える仕組みを整えること」にあります。

• どのような支援体制があるのか
• 誰がどの範囲まで考える（責任を持つ）必要があるのか

といったポイントを明確にし、組織全体で共有・認識しておくことが重要です。単に「サポートするよ！」と伝えるだけでなく、「どう支えるのか」を仕組みとして構築しておくことが重要です。

ノーコードが広がり、「自分たちで業務アプリをつくりたい」「内製化したい」という企業が増えています。その際に、どうしても「どのツールを使う？」「誰がアプリつくる？」というようにヒトとツールに注目が集まりがちです。

市民開発の取り組みが進んでいる企業も、これから始めようとしている企業も、一度立ち止まって「いま、誰がどの責任を担っているのか？」「その人を支える仕組みはあるか？」を見直してみることで、より持続可能で広がりのある市民開発へと進めることができるのではないでしょうか。

初めから大きな体制を整える必要はありません。まずは、小さく役割分担から始めてみる。Distributed Developmentの視点は、業務改善を持続させる仕組みづくりの第一歩です。

これまでの連載記事一覧

執筆者

Text：樋口舞美