松田 幸裕 記
イーロン・マスク氏によるツイッター社での大規模解雇のニュース、驚きましたね。メディアによると、全従業員の半数に当たる約3,700人が突然解雇されたそうです。私自身も過去は外資系企業に勤務していたため、解雇自体はさほど驚きませんが、この短期間でこの規模の人員をバッサリ切るというのは衝撃的でした。
そんな衝撃とともにふと思ったのですが、日本での賃金が低く海外での賃金が高いのは、このようなリスクの有無も関係しているかもしれません。海外ではある程度高い賃金をもらえる代わりに、突然会社都合で解雇される可能性があるという、いわゆる「ハイリスク・ハイリターン」で、日本ではある程度賃金が低い代わりに、突然会社都合で解雇されるようなことはないという、いわゆる「ローリスク・ローリターン」ですね。「日本の賃金の低さは問題」という話がされていますが、生産性が上がらない中で賃金を上げるのであれば、このようなリスクとリターンの関係を考慮して制度を見直していかなければいけないのかもしれませんね。
本題に入ります。最近、「市民開発」、「開発の民主化」のような言葉を見かけることが多くなってきました。前回の投稿「DX時代における各部門の役割は、そして今なすべきことは何か？」で触れたDXと深く関連するテーマのため、この「市民開発」、「開発の民主化」について本投稿で考察してみたいと思います。
「市民開発」、「開発の民主化」とは？
IT部門ではなく現業部門の人たちがアプリケーション開発を行うことを「市民開発」、そのような状況に変化させていくことを「開発の民主化」と呼びます。現業部門の人たちはプログラミング言語を扱えるわけではないため、一般的なアプリケーション開発者のように開発をすることはできません。そこで、「ノーコード開発ツール」、「ローコード開発ツール」という、プログラムをほとんど書かなくてもGUIの操作でアプリケーション開発ができるツールを利用します。（数年前まで、ローコード開発ツールは「超高速開発ツール」と呼ばれていましたが、海外に合わせて呼び名が変更されています。日本にある「超高速開発コミュニティ」という団体も、今は「ローコード開発コミュニティ」という名前になっています。）
過去に、「セルフサービスBI」という用語で、データ分析やレポート作成を現業部門が主導して行うことが推進されましたが、そのアプリケーション開発版ともいえますね。
「開発の民主化」における課題は？
コードを書かなくていいと言っても、アプリケーション実行の流れなどは考える必要がありますし、簡単なツールではないため、「これを実現するにはどこをどう設定すればいいんだろう…」というのを理解するために、ツール利用の学習も必要です。チュートリアルなどに従って、その通りに操作することはできても、いざ実現したいことをアプリケーションに実装するとなると応用が必要で、簡単ではありません。
今まで、多くの企業の情報システム部門の方々から、「うちの社員はITリテラシが低いから…」という話を聞いてきました。全員が使わなければいけないものではなく、現業部門内でITをある程度以上使いこなしている人が開発を行えばいいのですが、それでもかなり苦労するのではないでしょうか。
また、その他にも課題はあります。
「この開発したいアプリケーションでは人事情報が必要。どこからどうやって人事情報を持ってくればいい？」など、データ連携の考慮も必要ですし、ネットワークや他のシステムに悪影響を与えない、またはセキュリティ的に問題のないアプリケーションをつくるための配慮も必要です。
また、長年情報システム部門で業務をしてきた人は、過去に流行った「EUC（エンドユーザーコンピューティング）」という言葉を思い出し、ゾクッとしているかもしれませんね。Officeのマクロなどを現業部門が自由に利用したことによって、OfficeやWindowsのバージョンアップの際に影響が読めず、大変な思いをした企業も多いでしょう。あのような状況の再来を避けるためにも、しっかり課題を見極め、対策を行っておく必要があります。
どのように「開発の民主化」を実現するべきか？
上記のように、「開発の民主化」には多くの壁があります。ここからは前回の投稿と同様、私見が多く入りますが、「開発の民主化」をどのように実現すればよいかを考えてみます。
前回の投稿「DX時代における各部門の役割は、そして今なすべきことは何か？」でも書きましたが、まず、アプリケーションを導入するうえでのガイドラインを策定することや、それを全社へ周知・啓蒙することが必要です。これによって、アプリケーションにおける一定の品質やセキュリティレベルを維持することが可能になります。ここは情報システム部門など、ITの専門部隊が担うことになります。
続いて、「誰が開発するか？」という話ですが、実際多くの企業ではノーコード、ローコード開発ツールと言えども現業部門の人たちで開発することは難しいのではないかと、個人的には考えています。また、日本ではIT人材がユーザー企業の情報システム部門でなくIT企業の方に偏っているため、多くの企業では情報システム部門の人材で現業部門における開発を手助けすることも難しいでしょう。こちらも前回の投稿で述べましたが、IT企業の力をうまく借り、「業務のスペシャリストである現業部門」と「ITのスペシャリストであるIT企業」で協力して進めるのが現実解だと思います。この場合、IT企業に開発してもらうというわけではなく、できればIT企業に手助けしてもらい、現業部門で開発するという形が望ましいでしょう。このようにすることで、自社にノウハウも蓄積されますし、後に一部の修正が必要になったとしても自分たちで行うことができます。
前回に引き続き今回もかなり私見が入っていますが、このように考えてみると「今後、それぞれの部門でどのようなことを進めていく必要があるのか？」が見えてくると思います。上記が正解か否かは別として、各社でこのような全体像を検討し、何をしていくべきかを決めて推進していくことをお勧めします。