“学びながら作るDX” - ふえん式が描く共創モデル

前回の記事でお伝えしたのは、自走するチームは「安全な環境」から生まれるということです。

「業務アプリ作っていいよ」と言われただけで、現場は動けません。

挑戦しても大丈夫だという“安全な環境”があって初めて、現場は一歩を踏み出せます。

では、その安全な環境ができたときに、次に何が起きるのか。

どうすれば、現場が学びながら手を動かし、改善を回し続ける状態に変わっていけるのか。

今回は、ふえん式がそのための“道しるべ”として、どのように組織を支えるのかを整理します。

ふえん式モデル:市民開発は「手を動かす」から始まる

おさらいになりますが、市民開発とは「組織のサポート体制の中で、業務プロセスを理解するIT部門以外の従業員が、ノーコードツールを活用して、アプリケーションを開発・運用する取り組み」です。

そして、市民開発を進める上での第一段階:「発見段階」では、まずIT部門以外の従業員(市民開発者)が初めてのアプリ開発に挑戦するところから始まります。

市民開発者が自分たちでアプリを作り、実際に手を動かす。

ここで大事なのは、作った“成果物”そのものではなく、手を動かすことで、次のことが実感としてわかってくる点です。

• (IT部門外の)自分たちで「どれくらいのアプリが作れるのか」
• ノーコードで「どんな業務アプリを作ることができるのか？」

デジタル化が全てではない

業務アプリを作成する過程で、もう一つ大きい気づきに出会えます。

それは、デジタル化が全てではなく、業務のやり方を変えることが重要だということ。

「ツールを入れる」だけでは、仕事は変わりません。

しかし、アプリを作るプロセスに入ると、

• そもそも入力項目が多すぎる
• 承認ルートが複雑すぎる
• “例外対応”が常態化している

といったような、業務そのものの詰まりが見えてきます。

つまり、市民開発は “アプリ開発” の話であると同時に、業務改善のトレーニングでもあります。

トライ＆エラーが「納得感」を作る

実際にアプリを作るということは、必ずトライ＆エラーをしなければならない状況が生まれます。

このトライ＆エラーは、現場の市民開発者だけでなく、それを見ている経営者や管理者にとっても非常に重要です。

「作ってみたけど、ここが詰まった」

「使ってみたら、ここが想定と違った」

このプロセスを”一緒に見ていくこと”で、業務改善に対する納得感が積み上がっていきます。

DXが進まない組織ほど、“納得がないまま決まる”ことが多いですが、ふえん式は必ず「手を動かしながら進める」という仕組みになっています。

ふえん式は「ガードレール」であり「道しるべ」である

何もないところから1を作るのは非常に難しい。

例えば「DXを推進したい」「デジタル化を始めたい」と思っても、アイデアが浮かばなかったり、「こんなことを実現したい！」と期待値だけが上がってしまい机の上だけで議論が終了してしまうことが多いです。

実際に何をすれば良いか？　というところにまで話を落とし込めずに迷っている方も多いのではないでしょうか？

しかし、「こうすればいい」と考えるための土台があれば、ヒトは動けます。

ふえん式は、まさにこの土台です。

• どこから始めればいいか
• 次に何をすればいいか
• 誰が、何の責任を持つのか

こうした判断を、現場が止まらない形で支える。

ふえん式は、ガードレールであり、道しるべにもなり得ます。

• 

  ※写真のように、段階ごとに何を目指すべきなのか？を明確に示しています。

成熟度モデル:次のステージに進むための“具体”が書いてある

ふえん式を進めていく上で、重要なのが成熟度モデルです。

• 

それぞれ次のステージに進むために、

• チェックリスト
• その段階でのゴール

が細かく記載されています。

そして面白いのは、ここが「押し付け」になっていない点です。

やっていくうちに、

• 「自分の会社にはこれは早いかな」
• 「ここは切り捨てて次に進もう」

という判断ができるようになり、ふえん式をベースに、自分たちのオリジナルの進め方を作れる。

ここが、市民開発を“自分ごと”にする力になります。

認知段階は「IT部門との緩やかな連携」

例えば、成熟度モデルの「認知段階」では、IT部門とのゆるやかな連携体制を作ることがゴールとして書かれています。

• 

IT部門がある会社なら、

• IT部門が、市民開発者が何をやっているかを把握しはじめる
• 市民開発者が困ったときに、IT部門に聞ける体制を作りはじめる

みたいな状態を目指す。

一方で、IT部門がない会社であれば、“自分たちのやりやすい形”に変更しても良いです。

例えば、

• ITが得意な人をサポート役として置く
• ノーコードツールで困ったときに聞ける場所(コミュニティ/窓口)を探しておく
• 困りごとが出たときに相談できる外部ベンダー/外部アドバイザーを確保する

同じゴール:市民開発者が困った際に相談できる体制を作ることを別の手段で実現すれば良いのです。

このように、自分たちの「オリジナルの進め方」を創っていくには必ず市民開発者、経営者、そしてIT部門など、それぞれの役割からの意見を出し合って調整していくことになります。

その中で、協力しながら改善をするという体制を作っていきやすくなるのです。

「課題発見者」という役割

さらに段階が上がってくると、市民開発者だけが頑張るのではなく、現場側に「課題発見者」という役割が誕生します。

課題発見者は、各部門で部署内の課題や改善要望を取りまとめて、意見として“上げる人”。

市民開発推進室などに、自分たちの部門の課題感をしっかり持っていく役です。

普段の「ここ、ちょっと改善したいな」という意見が上がり、それを市民開発者が業務アプリや業務改善の提案という形にして返す。

課題をあげる → 市民開発者が業務アプリを開発する、の流れが回り始めると、「ちゃんと自分の意見は通るんだ」という実感が生まれて、次の声も上がりやすくなります。

• 意見を言ってもいい安心感。
• 改善されていく実感。

それを会社全体で共有できる。

ふえん式では、こういう雰囲気や文化づくりを作り上げて行ける設計になっています。

そして最終的には、社内で協力して改善を回していく“共創モデル”が作りやすくなるのです。

学びながら作るDXは「改善の回転数」と「安心感」で決まる

ふえん式は、現場がノーコードで手を動かしながら学べるように、成熟度モデルとチェックリストで“次の一歩”を具体的に示しています。

• つくる → 使う → 改善/改修する

この改善ループを、現場で回せるようになります。 そして回転数が上がることで、「意見を言っていい」「試していい」という安心感と、「ちゃんと改善された」という実感が積み上がっていく。

ふえん式が目指しているのは、ツール導入の成功ではなく、改善が回り続ける組織を作ることです。

自走するチームは、安心な環境から生まれる。

そして、その環境の上で、改善の回転数を上げていく。それが“学びながら作るDX”です。