企業にとって、効率化と価値向上は重要かつ不可欠な活動です。そのために、業務のデジタル化・業務DXを推進する企業が増加傾向にあります。業務のデジタル化・業務DXでは、ローコード開発が効果を発揮します。

今回は、その3つ理由を説明していきましょう

• 理由1. 業務のデジタル化は継続的な開発体制で推進
• 理由2. 企業ごとに競争領域／協調領域が異なり、それに応じたソリューションを選択
• 理由3. 競争領域の業務デジタル化を継続的かつアジャイルに進めるため、ローコード開発プラットフォームを活用

理由１：業務のデジタル化は継続的な開発体制で推進

まず、ローコード開発が必要になる1番目の理由は、業務のデジタル化を継続的かつ主体的に進めていく必要があるからです。重要なのは**継続的**ということです。内製化やエンドユーザーコンピューティングも注目されていますが、自社人材だけでは力不足な場面もあるでしょう。継続的なシステム開発には、強力なパートナーとツールが必要になるのです。

この図は、経済産業省のDXレポート2から引用したDXフレームワークの図です。

ここでは、DXの具体的なアクションを組織の成熟度ごとに設計できるように、DXをデジタイゼーション、デジタライゼーション、デジタルトランスフォーメーションという3つの異なる段階に分解しています。

• デジタイゼーション：アナログ・物理データのデジタルデータ化
• デジタライゼーション：個別の業務プロセスのデジタル化
• デジタルトランスフォーメーション：本来は組織横断/全体の業務プロセスのデジタル化、顧客起点の価値創出のための事業やビジネスモデルの変革を指す

—

業務レベルのDXでは、紙ベース・人力ベースの作業を、PC上の作業としてデジタル化します。それからワークフローなどでプロセスをデジタル化します。最後にお客様とE2E(エンド トゥ エンド)のデジタル化として発展します。

さすがに、紙ベースの作業は減ってきましたが、ほんの少し前までFAXベースで情報をやりとりしているなんてザラにありました。そういうところは、業務規模や相手の都合・システム化予算などの制約で、なかなかデジタル化できなかった領域です。一部分だけ残っていてそこがボトルネックになることもあるでしょう。

一足飛びでは実現できないため、前のステップを実現してから次のステップに取り組む必要があります。

つまり業務のデジタル化は、システムを導入して終わりではなく、継続的に進めていく必要があるのです。そのためには、自社人材だけなく強力なパートナーとツールが不可欠です。

理由２： 企業ごとに競争領域／協調領域が異なり、それに応じたソリューションを選択

2つ目の理由は、企業ごとに協調領域／競争領域が異なり、それに応じたソリューションの選択が重要なことです。

協調領域とは、自社のビジネスの強みと関係が薄く、他社と共通でもいい領域のことです。協調領域では、業務プロセスの標準化を進めパッケージソフトウェアやSaaS・BPO(ビジネスプロセスアウトソーシング)の活用でIT投資を削減させます。

競争領域とは、自社ビジネスの強みになる領域のことです。ここに経営資源・IT投資を集中させる。一方、正解はわからないため、仮説・検証を俊敏に実施する必要があります。アジャイルな開発体制を構築し、市場の変化をとらえながら小規模な開発を繰り返します。

協調領域と競争領域の区別は、経営レベルの判断が必要だと思います。重要な競争領域だと思って現場がスクラッチ開発しても、じつは協調領域だったとなればIT投資はムダになってしまうからです。

たとえば、給与計算とか勤怠管理のWebサービスがたくさんあります。法令に則って給与計算する勤怠管理するなら、個々の会社でそんなに違いはありません。

しかし、給与計算サービスのベンダーは、当然そこが競争力の源泉です。そこにIT投資を集中させて、ユーザーに先駆けて新しい顧客価値を提案していく必要があります。

ですので、まず自社の競争領域／協調領域を見極めて、それに応じたソリューションを選択することが大切なのです。

理由３：競争領域の業務デジタル化を継続的かつアジャイルに進めるため、ローコード開発プラットフォームを活用

このような企業の競争領域／協調領域に応じたソリューションを選択する場合、競争領域の業務デジタル化に効果を発揮するのが、ローコード開発プラットフォームです。

現在、多くのノーコード開発ツール・ローコード開発ツールがあります。これを大きく4つに分類してみましょう

特定領域のノーコード開発ツール

CMSやマーケティングツールがノーコードツールに分類されています。当社でも、マーケティングのメンバーが、自分たちでマーケティングオートメーションツールやWordpressの運用をやっています。特定の業務に合致してシステム規模が小さなうちはノーコード開発ツールでも対応できます。

汎用のノーコードツール

これは、エンドユーザーコンピューティングですね。以前Notesでやっていた領域です。

エンドユーザーが、自分たちの業務の合間に兼業でデジタル化できるのであれば、スピーディかつ高い柔軟性が得られるでしょう。

最近のクラウド型Webデータベースであれば、Notesの問題点を解消できかもしれません。一方で、汎用といっても守備範囲が限られているので、そのなかで実現していくことになります。野良ツール化の防止、アクセス制御やアップデートができればいいんじゃないかと思います。

ローコード開発プラットフォーム

システム規模が大きくなったり、競争領域でばりばりアジャイル開発していこうとすると兼業では対応しきれなくなります。そうすると、フルタイム化・内製化が必要になります。

そのとき、汎用のノーコード開発ツールでは柔軟性が不足するため、もうすこしエンジニアにとって使いやすく素早く開発できるローコード開発プラットフォームが選択肢に上がってきます。開発支援ツールや開発プロセス・情報共有の仕組みも不可欠です。

しかし、ビジネス側に主体性が不足していると、結局、内製化チームに丸投げになる場合も多くなります。また内製化チームの採用やマネジメントも大変です。

ローコード開発プラットフォーム + 開発パートナー

そこでローコード開発プラットフォーム + 開発パートナーという開発体制が効果的だと思います。ローコード開発プラットフォームで、素早く柔軟な開発を維持しながら、開発パートナーの高度な開発ノウハウと経験を活用するのです。

ローコード開発プラットフォームを活用したパートナーがビジネス開発の伴走者になる

ここで重要になるのは、結局のところビジネス開発側の主体性です。

最近、このアジャイル開発が注目を集めていますが、アジャイルだけを採用してもうまくいかず、ミニウォーターフォールになってしまうという話も聞きます。

スクラムというアジャイル手法では、短い期間での開発と仮説検証による調整を繰り返します。この仮説検証をビジネスを開発する側が実施します。

重要なことは、ビジネス側が主体性を持ってビジネス開発していくことだと思います。最初に決めた機能リストを分割して、ちょっとづつ開発していくだけならミニウォータフォールに過ぎません。

アジャイルと並走して、ビジネス側が市場との対話、仮説・検証を繰り返していくことが重要なのです。スプリントで上がってきたものをビジネス開発サイドが素早く市場で検証して、そのフィードバックを元に次のスプリントで作るものを調整する訳です。

開発チームは、ローコード開発プラットフォームを活用して、ビジネス開発を主導するプロダクトオーナーの伴走者になるのです。

実は、こうした仮説・検証のことは、アジャイル開発やスクラム開発について調べてもなかなか出てきません。「リーンスタートアップ」や「リーン開発」として整理されているので興味があれば調べてみてください。

まとめ

ここまで、業務DXではローコード開発が効果的である理由についてふれてきました。そして、企業と開発パートナーが併走しつつ、自社の強みである競争領域のデジタル化を推進していく必要性を整理してきました。

ローコード開発に対して、どのように取り組めばよいのかを知ることでプロジェクトを推進しやすくなります。自社の経営課題や戦略に合わせて、クリアしたい課題や現状を見つめなおし、業務のデジタル化・業務DXを進めていきましょう。