前回の記事では、DXを外注してしまう構造的な要因について解説しました。
責任の所在の曖昧さ、「内製する覚悟」の欠如。これらの問題は、ツールを入れ替えただけでは解決しません。 では、どうすれば内製化は進むのでしょうか。
今回は、私たちが提供する「ふえん式」が、どのように現場DXを支援し、自走するチームを作っていくのかを解説します。
自走するチームには「安心して挑戦できる環境」が必要
市民開発に必要なのは、現場が自分たちでアプリを作る取り組みです。
しかし、「作っていいよ」と言われただけで、現場は動けるでしょうか。
答えはNoです。
現場が自走するためには、挑戦しても大丈夫だという「安心な環境」が必要です。
「サンドボックス(砂場)」や「遊び場」と言われることがありますが、まさにその通りです。失敗しても誰かに怒られない。試行錯誤が許される。そういう環境があって初めて、現場は一歩を踏み出せます。
発見段階:まずは「自分の困りごと」から始める
ふえん式では、市民開発の成熟度を5つの段階に分けて考えます。
発見段階 → 認知段階 → 試行段階 → 確立段階 → 浸透段階
最初の「発見段階」で現場がやることは、シンプルです。
- 自分がExcelでやっている小さな業務
- 自分の部署だけで使っている管理表
- 自分が「面倒だな」と感じている作業
こういった身近な困りごとを、ノーコードでアプリ化してみる。
大きなシステムを作る必要はありません。まずは自分の業務を少し楽にする。それだけでいいのです。
経営者・上司の役割は「時間と環境を確保すること」
では、この段階で経営者や上司は何をすべきでしょうか。
現場がアプリを作る時間を確保してあげること。
「業務時間外にやれ」「自分で勉強しろ」では、現場は動けません。
「この時間はアプリ作りに使っていいよ」「まずは試してみてほしい」
この許可を出すことが、経営者・上司の最初の仕事です。
安心な環境を作るからこそ、現場は安心して挑戦できる。だからこそ、市民開発の土台が少しずつ積み上がっていくのです。
加えて、IT部門も含め、社内で「市民開発とは何か」を共通認識として持つことが、市民開発を推進していく上での非常に重要な土台になります。
「ヒト」だけに負担をかけない
これまでの現場DXには、典型的な失敗パターンがありました。
「ITが得意“そう”だから任せよう」
と、特定の個人に負担が集中してしまう。
その人が異動したり退職したりすると、すべてが止まる。これが、前の記事でで触れた「Excelマクロ、誰が作ったかわからない問題」の正体です。
ふえん式では、市民開発の定義を「ヒト」だけでなく「ツール」と「仕組み」を含めた3要素で捉えます。
- ヒト:開発する人だけでなく、サポートする人、管理する人
- ツール:現場が使えるノーコードツール
- 仕組み:段階的に進めるためのフレームワーク、チェックリスト、役割分担
この3つが一緒に動いていかないと、市民開発は機能しません。
ヒトだけが努力しても、ツールを導入しただけでも、あるいは仕組みの一部を変えただけでも、十分な成果は得られません。
3つが一緒に動くことで、初めて自走するチームの土台ができるのです。
責任の所在を明確にする
前の記事でも、責任の所在の曖昧さがDXを外注に向かわせる原因だとお伝えしました。
例えば、ふえん式では、始めの段階ではこの責任をシンプルに分けています。
現場の責任:初めての簡単な業務アプリを作ってみること
経営者の責任:それをサポートし、挑戦できる環境を維持すること
現場は「作る責任」を持ち、経営者は「支える責任」を持つ。
もちろん、段階が進むにつれて、登場する人材も増え、役割や責任の範囲も広がっていき具体性が増していきます。
しかし、人材の役割が市民開発成熟度の段階ごとに定義されているからこそ、ふえん式は進めやすいのです。
段階が進んだら「誰が作るか」を判断する
市民開発の段階が進むと、開発内容も少しずつ複雑になっていきます。
そのとき必要になるのが、「誰が作るべきか」を判断するチェックリストです。
- 現場だけで作れる内容か?
- IT部門のサポートが必要か?
- IT部門が主導で作るべきか?
高度な技術が必要だったり、社内の重要なデータを扱う場合は、IT部門がサポートに入る。
このように、案件の内容に応じて役割を分担する仕組みがふえん式には組み込まれています。それらを現場で判断できるように技術観点チェックリストも用意されています。
ふえん式が提供する具体的な判断軸
ふえん式の市民開発には、現場が業務改善をする上でできる限り価値を生み出せるように具体的な判断リストが用意されています。
まず、5つの成熟段階(発見 → 認知 → 試行 → 確立 → 浸透)が定義されており、各段階で「誰が何をすべきか」が明確になっています。
そして、次の段階に進むためのチェックリストも用意されています。
現場が開発するべきか? を判断する技術観点チェックリストを始め、下記の2つのチェックリストも用意されています。
市民開発実現可能性チェックリスト
その業務課題が市民開発に向いているかを、適性・体制・環境・移行の観点で判断する。
ビジネス観点チェックリスト
作ることで本当に価値が出るかを、業務効率・収益・コスト・顧客・従業員の5視点で評価をする。
これらの具体的なチェックリストが段階ごとにあることで、それぞれの役割の人が自分の役割を果たしながら、一緒に改善していく文化を作ることができます。
「次は何をしたらいいのか?」「どう改善すればいいのか?」
業務改善に関わる判断は、抽象度が高く、明確な答えがないことがほとんどです。その結果、「考える」こと自体が目的になってしまい、アクションが止まってしまうことがよくあります。
だからこそ、このようなチェックリストを設けることで、「次に何をするか」というアクションを具体的に示す。これが、学びながら進めていく文化を作りやすくするという「ふえん式」ならではの工夫です。
期待値を「正しく設定する」
“DXを外注”すると、「すぐに何かが変わる」「すぐに効果が出る」という期待を持ってしまいがちです。
市民開発でも同じです。「現場がガツガツアプリを作って、すぐに業務が改善される」という理想を描きがちです。
しかし、それは現実的ではありません。
ふえん式のフレームワークを順番に進めていくことで、自分たちの会社の状況を正しく理解し、適切な期待値を設定できるようになります。
- 過度な期待を押しつけられない現場。
- 何かあっても支える体制のある組織。
この2つが揃えば、社内に安全な環境を作ることができます。
自走するチームは「安全な環境」から生まれる
自走するチームを作るために必要なのは、「優秀な人材」ではありません。
安心して挑戦できる環境です。
- 経営者が時間と環境を確保する
- ヒトだけに負担をかけず、3要素で支える
- 責任の所在を明確にする
- 段階的ごとのゴールやチェックリストに沿って、期待値を正しく設定する
これらが揃うことで、現場は少しずつ自走できるようになっていきます。
ふえん式は、この「自走するチーム」作りをサポートするためのフレームワークです。
次回は2月16日の掲載予定です。



