本記事で解決できること
“The formulation of the problem is often more essential than its solution.”
― Albert Einstein
ノーコード・ローコードの普及によって、現場部門の社員が自ら業務アプリや小さな仕組みをつくる、いわゆる「市民開発」は一気に現実味を帯びるようになりました。
実際、以前であれば情報システム部門やベンダーに依頼しなければ形にならなかったものが、今では現場起点でもある程度まで試作できるようになっています。
しかし一方で、市民開発は「誰でも作れるようになった」からこそ、別のところで止まりやすくなっています。
それが、何を作るべきかが定まらないという状態です。
現場には不便さや非効率があります。ただし、それがそのまま開発テーマになるとは限りません。業務上の違和感はあっても、それが本当に解くべき課題なのか、誰にとっての不便なのか、どこを変えれば価値になるのかが整理されていなければ、手が止まります。
市民開発の初期で詰まりやすいのは、実装ではなく、課題のあたりをつける段階です。
生成AIというと、資料の要約や議事録作成、メール文面の下書きなど、既存業務を効率化する用途がまず想起されがちです。もちろん、それらは実務上きわめて有用です。
ただし、生成AIの価値はそれだけにとどまりません。むしろ重要なのは、まだ形になっていない課題や、うまく言語化できていない違和感に対して、仮説を高速で返せる点にあります。言い換えれば、生成AIは「正解を出す装置」というより、「問いを展開し、思考を補助する装置」として捉えた方が実態に近いでしょう。
市民開発の初期段階では、仕様を詰める前に「そもそも何に困っているのか」「どのような不満が潜在しているのか」を掘り起こす必要があります。このとき、AIに要約させるだけでは不十分です。必要なのは、AIを使って課題の輪郭をあぶり出すことです。
その際に有効なのが、既存の製品やサービス、あるいは業務のあり方に対して、利用者がどのようなストレスを感じているかをAIに整理させる使い方です。例えば、プロンプトとしては次のような形になります。
従業員が〈既存の業務・ツール・運用〉に関してストレスを感じる要因は何ですか?
一見すると非常にシンプルですが、この問いには意味があります。
通常、現場で課題を聞くと、「特に困っていない」「昔からこのやり方だから」といった答えが返ってくることは珍しくありません。長く使われてきた仕組みほど、それに伴う不便さが“当たり前”として内面化されているためです。しかし、利用者が意識していないストレスであっても、業務やサービスの改善余地としては十分に存在します。
改善テーマがまだ固まっていないときや、現場ヒアリングの前、「特に困っていない」と言われがちな業務に対して、この問いは特に有効です。例えば、勤怠や申請業務、Excel管理、社内ポータルなど、日常的に使われているものを一つ選び、この問いを投げてみるだけで構いません。
生成AIにこの観点で問いを投げることで、表面的な要望ではなく、潜在的な不便や不満を仮説として洗い出すことができます。手間の多さや手順のわかりにくさ、ミスの起きやすさ、属人化といった「よくあるストレス構造」を仮説として提示してきます。これらはそのまま事実ではありませんし、そのように受け取るべきでもありませんが、「どこに着目すべきか」を考える出発点としては十分に機能します。インタビューやヒアリングの前段として仮説を立てる材料として有効です。
さらに、この使い方を一段深めるポイントがあります。それは、利用者を単なる属性ではなく、行動の違いで分けることです。「若手社員」「管理職」といった属性で分けると、一見わかりやすく見えます。しかし実際には、同じ役職や年代であっても、業務への慣れ方や情報収集の仕方、ツールへの抵抗感は大きく異なります。例えば、同じ申請業務であっても、毎日のように処理する人と、月に1回しか触れない人とでは、感じるストレスは異なります。前者は「もっと早く処理したい」と感じるかもしれませんし、後者は「そもそも手順がわからず不安」と感じるかもしれません。
そのため、AIに問いを投げるときも、単に「ユーザーは何に困っているか」と聞くより、「頻繁にその業務を行う人」と「たまにしか行わない人」といった形で、行動ベースで分けた方が、出力の質は上がりやすい傾向があります。この違いを捉えずに一つの解決策でまとめてしまうと、誰にも刺さらない中途半端な改善案が出来上がります。
このプロンプトの使い方の基本手順
(※当該プロンプトは、UX設計でいうところの「Jobs To Be Done(JTBD)」に近い考え方を応用したものとなっていますが、本記事ではフレームワークとしてではなく、実務で使える形に落としています。)
この方法が市民開発と相性がよい理由は、単なる「アイデア出し」にとどまらず、そのまま改善テーマの候補になりやすいからです。
市民開発でありがちなのは、「便利そうだから作る」「作れそうだから作る」という順序です。しかし、その順番で始めると、出来上がったものが現場に定着しないことが少なくありません。この順番のまま進むと、「誰のためのものかわからない」「結局使われない」といった結果になりやすくなります。一方で、先にストレス構造を整理しておけば、
が見えるため、作るべきものの方向が定まりやすくなります。
つまり、生成AIはここで、開発そのものを代替するのではなく、開発テーマを定義する補助線として機能するわけです。これは、市民開発の成功率を上げるうえで、かなり重要な使い方だといえます。
市民開発という言葉を聞くと、多くの人はノーコードツールの使い方や、画面の作り方、ワークフローの組み方を思い浮かべるかもしれません。もちろんそれらは重要です。
ただし、より本質的なのは、その前段階です。
何を課題として捉えるのか。誰のどのストレスを解消するのか。いまの業務やサービスのどこに改善余地があるのか。
これらの問いに対して、ある程度の仮説が持てていなければ、ツールを使えることと、価値あるものを作れることは一致しません。そういう意味で、市民開発の第ゼロ歩とは、「作ること」ではなく、「作るに値する課題を見つけること」だといえるでしょう。
そして、そのための思考の補助として、生成AIはかなり有効です。
従来、業務改善の初期段階では、現場ヒアリングを重ね、課題を整理し、要件を定義し、それからようやく開発に進むという流れが一般的でした。
しかし、生成AIの登場によって、この最初の構想フェーズは大きく変わり始めています。
もちろん、AIが現場理解そのものを代替するわけではありません。実務上の制約や組織の文脈、制度上の条件まで含めて正確に捉えるには、人間の判断が不可欠です。
ただし、課題の仮説を出すスピード、視点の広げ方、見落としていた不満を言語化する能力において、AIはすでに実務的な価値を持ち始めています。
これは、市民開発を「ツールの民主化」としてだけ捉えるのではなく、「課題設定の民主化」として捉え直す必要があることを示しています。
生成AIを業務に取り入れるとき、つい要約や文章生成といったわかりやすい用途から入りがちです。それ自体は有効ですが、市民開発との接続を考えるなら、それだけでは不十分です。
重要なのは、AIを使って「何を作るべきか」を考えることです。
この順番で考えることで、市民開発は単なる思いつきではなく、仮説に基づく改善活動になります。
市民開発の第ゼロ歩とは、ノーコードツールを開くことではありません。その前に、課題を問いとして捉え直し、構造化することです。そして、その最初の壁を越えるための相棒として、生成AIはかなり有力な選択肢になりつつあります。
もし「自社の業務だと、どこから問いを立てればよいかわからない」と感じた場合は、第三者の視点を入れるのも一つの手です。
筆者:W.S.
ITガバナンスおよび市民開発推進を得意領域とするコンサルタント。中堅〜大手企業のIT統制設計・DX推進支援に従事。
個人開発者としてJavaScriptおよびFirebaseを用いたWebアプリ開発にも取り組み、開発現場と統治設計の両面からDXを研究している。
同志社大学大学院経済学研究科博士後期課程修了単位取得退学。
\今なら無料!/
【30分DX無料相談 実施中】
「業務を効率化したいけれど、どこから手をつければいいかわからない…」「どのツールが自社に合っているのか、比較検討したい…」「市民開発をどのように推進すればよいか、専門家の意見を聞きたい…」
そんな悩みに、経験豊富なDX推進コンサルタントが個別に対応!
→ お申込みはこちら:https://www.qloba.com/forms/10862?_gl=1*1iahbda*_g...