見出し画像

市民開発一問一答

市民開発についてもやもやしていたので、ソシャゲの周回をしながら壁打ちしたものを残しておきます。

壁打ち相手はGoogleさんちのBardくんにお願いしました。


市民開発とはなんですか?

市民開発とは、IT部門に依存することなく、業務部門の社員がローコード・ノーコードツールを活用して、自ら業務のデジタル化を実現することです。

ローコード・ノーコードツールとは、プログラミングの知識や経験がなくても、直感的に操作してアプリケーションを開発することができるツールのことです。

市民開発のメリットは、以下のとおりです。
・IT人材不足の解消
・開発コストの削減
・開発スピードの向上
・業務部門の主体性の向上

IT人材不足が深刻化するなか、市民開発は、業務部門の社員が自らシステム開発を行うことで、IT人材不足を解消し、開発コストを削減し、開発スピードを向上させ、業務部門の主体性を高めるための有効な手段として注目されています。

市民開発の事例としては、以下のようなものが挙げられます。
・製造業において、生産ラインの稼働状況を可視化するアプリを開発し、生産効率を向上させた
・小売業において、顧客の購買履歴を分析するアプリを開発し、顧客の購買意欲を高めた
・行政において、住民サービスの申請手続きを簡素化するアプリを開発し、住民の利便性を向上させた

市民開発は、今後ますます普及していくことが予想されます。

Bard

なるほどねー。従業員が自律してツールを使って課題解決を行う。そして輝くDX!

まぁそうなんでしょう。
3月に参加したGoogle Workspace Summit 2023でもそんな感じでした。
大企業も地方で平均年齢の高いITとは無縁と思われる業種の老舗企業もローコード・ノーコードツールでDX!業務効率!って流れでしたね。

そこで違和感を覚えたわけです。一定ITに詳しい実務経験者なら確実に懸念されることをわざとスルーしていないか?と。

運用管理についての話が殆どないんです。

紙媒体でやっていたことがデジタル化出来ました。フォームを作ってスプレッドシートにまとめることで担当者の作業量が減りました。それはそれで素晴らしいと思います。
でもそのツール、誰がメンテナンスするのでしょう。誰が品質を保証するのでしょう。誰が類似のツールがあるかどうか横串に見てくれるのでしょう。

データもそうです。類似のデータを部門単位でそれぞれ作っていたら意味がなくないですか?

ということでBardくんに聞いてみましょう。

運用管理は誰が行いますか?

市民開発で作成されたツールは、基本的には市民開発者自身が管理します。しかし、以下の理由から、IT部門や業務部門の担当者による管理が必要になる場合があります。
・ツールの品質やセキュリティの担保
・ツールの利用状況の把握
・ツールの更新や保守

IT部門や業務部門の担当者は、以下の役割を担うことができます。
・ツールの開発プロセスの策定・支援
・ツールのレビュー・承認
・ツールの利用状況の把握・分析
・ツールの更新・保守

市民開発の成功を収めるためには、IT部門と業務部門の協力が不可欠です。IT部門は、市民開発者を支援するための体制を整備し、業務部門は、ツールの開発・運用に積極的に参画することが重要です。

具体的な管理方法としては、以下のようなものが挙げられます。
・ツールを登録・管理するシステムを導入する
・ツールの開発・運用に関するガイドラインを策定する
・ツールのレビュー・承認プロセスを定める
・ツールの利用状況を定期的に把握する

ツールの管理方法は、企業の規模や業務内容によって異なります。企業の状況に合わせて、適切な管理方法を検討することが重要です。

Bard

あれ?管理は市民開発者自身が行うといいながら一部IT部門は見ないといけないようですね。

IT部門はプラットフォームやガイドラインを整備して、市民開発者はその範囲内で積極的に参画することが重要とのことです。
でもIT部門が不在だったりリソースが足りないから依存しない市民開発を推進しているのに、ちょっと本末転倒感といいますか、言ってしまえばBPO案件の匂いがしてきましたね。

結局IT部門の負担が増えていませんか?

市民開発は、IT部門に依存しないという意味では、IT部門の負担を減らすことができます。しかし、市民開発によって作成されたツールの管理や、市民開発者への支援など、IT部門が新たに担うべき役割が発生する可能性があります。

具体的には、以下のようなものが挙げられます。
・ツールの開発プロセスの策定・支援
・ツールのレビュー・承認
・ツールの利用状況の把握・分析
・ツールの更新・保守

これらの役割を担うためには、IT部門の人員や予算の増加が必要になる場合があります。また、IT部門の担当者は、市民開発者とのコミュニケーションや、市民開発の成果を評価するためのスキルを身につける必要があります。

そのため、市民開発によってIT部門の負担が増える可能性は否定できません。しかし、IT部門が市民開発を積極的に支援することで、業務部門の主体性を高め、DXを推進する上で大きな効果を得ることができます。

IT部門と業務部門が協力して、市民開発を成功に導くことが重要です。

Bard

なるほど単純に楽になるよ、というよりは別の作業が増えるので短期的には変わらないかむしろ負担増。中長期的に見れば負担減という感じのようです。
市民開発で重要なのは、自律的に自分ごととして業務改善に向き合う現場担当者と、改善したいという意志をちゃんと具現化出来る環境を整えるIT部門担当者のどちらも欠けてはいけないわけですね。

と、ここでIT部門側はベンダーに丸投げする企業が頭をかすめました。
まぁ確かにそういう経営者もいそうではあります。ベンダーじゃなくてもとりあえず環境ができればOKと思ってる経営者なら、適当にコンサル連れてきてハイ終わり、的なこと考えそうだなぁ。
なんせ短期的には変わらない可能性のほうが高いわけですから、その場しのぎの経営者なら上記の方向で説得しようとしてもピンとこないでしょう。

一旦IT部門に依存することのデメリットを確認してみましょう。

IT部門に依存することで発生する負担とは?


IT部門に依存することで発生する負担は、以下のとおりです。

・業務部門の主体性の低下
IT部門に依存していると、業務部門はIT部門に頼りきりになり、主体的に業務を改善することが難しくなります。

・業務スピードの低下
IT部門の業務量が増えると、業務部門の要望に迅速に対応できなくなり、業務スピードが低下する可能性があります。

・コストの増加
IT部門の人員や予算が不足すると、IT部門の業務を外部に委託する必要があり、コストが増加する可能性があります。

・セキュリティリスクの増加
IT部門のセキュリティ対策が不十分だと、業務部門のシステムやデータがサイバー攻撃の対象となり、セキュリティリスクが増加する可能性があります。

市民開発を導入することで、これらの負担を軽減することができます。
具体的には、以下のメリットがあります。

・業務部門の主体性の向上
業務部門は、自らITシステムを開発することで、業務を改善するための主体性やスキルを身につけることができます。

・業務スピードの向上
業務部門は、IT部門に依存することなく、自らITシステムを開発・運用できるため、業務スピードを向上させることができます。

・コストの削減
IT部門の人員や予算を削減できるため、コストを削減することができます。

・セキュリティリスクの低減
業務部門は、IT部門のセキュリティ対策に協力することで、セキュリティリスクを低減することができます。

ただし、市民開発を導入する際には、以下の注意点があります。

・ガバナンスの確立
市民開発で作成されたツールの品質やセキュリティを担保するために、ガバナンスの確立が必要です。

・教育・研修の実施
業務部門の社員がITシステムを開発・運用できるように、教育・研修の実施が必要です。

・IT部門との協力
IT部門の支援を受けることで、市民開発を成功に導くことができます。

IT部門と業務部門が協力して、市民開発を導入・運用することで、業務の効率化やDXの推進につながります。

Bard

おお、具体的な負担とそれに合わせたメリット、注意点も教えてくれました。

確かにIT部門がボトルネックになって事業速度が低下するのは避けたいですね。コストに関しては状況によるのでなんとも言えませんが、少なくとも全員参加のメリットというのは打ち出せそうです。

さて、事業部門も巻き込んだ市民開発のメリットはある程度わかりました。
しかし情シス的にはバックエンド側、つまりデータについても着目しておきたいですね。
同じプラットフォームで開発することでどの部門も同じノウハウが使えるのは魅力的です。
更に同じDBを使って一元管理出来るとよりシナジー効果を得られるのは言うまでもないことです。

その辺の言及がまだないので聞いてみましょう。

データの横断的な利活用や全体最適化はどうなの?

業務部門だけで開発をすると、データの横断的な利活用や全体最適化を行う人がいないというご指摘は、ごもっともだと思います。

業務部門は、自部門の業務を効率化するためにシステムを開発することが多いため、自部門のデータやシステムにしか関心がない場合が多くあります。そのため、他の部門のデータやシステムと連携するような開発を行うことは、なかなか難しいのが現状です。

データの横断的な利活用や全体最適化を行うためには、業務部門とIT部門が連携して取り組むことが重要です。IT部門は、全社のデータやシステムを把握しており、全体最適化の視点を持っています。そのため、業務部門が開発したシステムを、全社のデータやシステムと連携させるための支援を行うことができます。

具体的には、以下のようなものが挙げられます。
・データ連携のための仕組みの提供
・全体最適化のための設計・提案
・技術的な支援

IT部門は、これらの支援を行うことで、業務部門が開発したシステムを、データの横断的な利活用や全体最適化を実現するためのツールに変えることができます。

また、業務部門は、IT部門の支援を受けながら、データの横断的な利活用や全体最適化の視点を理解し、自部門のシステム開発に反映していくことが重要です。

業務部門とIT部門が連携して、データの横断的な利活用や全体最適化を実現することで、企業の競争力強化につながります。

やはりIT部門は全体最適化の要として、ノウハウは持ちつつも手を動かすのは最小限にし、業務部門の底上げに注力することで企業全体のアジリティを向上させるのが本命のようです。

一人情シスなどPCのキッティングや問い合わせ対応が定常業務の中心となっている場合は、この時点で人欲しいですねぇ…。

市民開発を行う時点で人員増加が必要?

はい、その通りだと思います。

IT部門がPCのキッティングや問い合わせ対応が業務時間の大半を占めている場合は、市民開発によって、これらの業務の一部を業務部門に移管することができます。

しかし、市民開発によって移管される業務の量によっては、IT部門の人員や予算の増加が必要になる場合があります。

具体的には、以下の要因によって、IT部門の人員や予算の増加が必要になる可能性があります。
・市民開発によって移管される業務の量
・市民開発で作成されたツールの管理・運用のコスト
・IT部門の支援体制の整備にかかるコスト

IT部門が市民開発を導入する際には、これらの要因を検討して、必要な人員や予算を計画することが重要です。

また、IT部門と業務部門が協力して、市民開発を円滑に運用するための体制を整えることも重要です。

Bard

おお、これで人員不足へのアプローチはできそうな気がしてきました。

市民開発(語弊があるのは飲み込んでいっそのことDXと言ってもいいかもしれない)とは家電のようにシステムを導入するだけでおしまいではなく、ちゃんと運用管理が必要で、そのための人員も専任で必要ということで積極的な採用を持ちかけることはできそうです。

しかし、説得するにはもうちょっと解像度が高くほしいところですね。
単純にコスト増業務量増と言っても具体的にどの程度なのかわからないことには経営者も意思決定しにくいでしょう。

市民開発によって移管される業務量とは?(経理を例に)

市民開発によって移管される業務の量を事前に見積るのは、確かに難しいと思います。

経理部門の業務を例に挙げると、以下のようなものが移管の対象となり得ます。
・請求書の作成・処理
・入出金の記録・管理
・月次決算・決算書の作成
・予算管理
・資金繰り管理
・税務申告

これらの業務のうち、以下のようなものは、比較的市民開発によって移管しやすいと考えられます。
・請求書の作成・処理
・入出金の記録・管理

これらの業務は、データ入力や単純な計算などの作業が中心であり、ローコード・ノーコードツールを活用することで、比較的簡単に自動化することができます。

一方、以下のようなものは、市民開発によって移管するのが難しいと考えられます。
・月次決算・決算書の作成
・予算管理
・資金繰り管理
・税務申告

これらの業務は、専門的な知識やスキルが必要な業務が多く、市民開発者による開発が難しい場合があります。

また、市民開発によって移管された業務であっても、IT部門による支援が必要になる場合があります。

例えば、以下のようなものが挙げられます。
・ツールの開発・運用に関するガイドラインの策定
・ツールのレビュー・承認
・ツールの利用状況の把握・分析
・ツールの更新・保守

IT部門と業務部門が協力して、市民開発を円滑に運用するための体制を整えることが重要です。

なお、市民開発によって移管される業務の量を事前に見積もるためには、以下の方法が考えられます。
・業務分析
・ヒアリング
・PoC(概念実証)

業務分析では、経理部門の業務内容や業務量を把握します。ヒアリングでは、業務担当者の意見や要望を収集します。PoCでは、実際にローコード・ノーコードツールを活用して、業務の自動化を検証します。

これらの方法を組み合わせることで、市民開発によって移管される業務の量をより正確に把握することができます。

Bard

専門性の強い領域は引き続き業務部門に任せつつ、出来る所をヒアリングなどを経てシステムに落とし込む、まさに王道ですね。

業務分析、ヒアリング、PoCもこの順番で行うことで納得感は得られると思いますし、その過程で両部門のキーパーソンを巻き込むことで水面下での事前合意はできそうです。

こういう泥臭い部分こそが情シスの本懐なので、モチベーション上がる人は情シス向いてると思いますねー。是非報われる世の中になって欲しいです。

この記事が気に入ったらサポートをしてみませんか?