ローコード開発にはビジネスの可視化手法とアジャイルのフレームワークが不可欠の理由。

ローコード・ノーコード開発とは

システム開発まわりで最近多く聞かれるようになったのが、ローコード開発あるいはノーコード開発という言葉です。

プログラム言語やコーディングの知識を前提にしないため、誰でもアプリケーションの開発が可能になる。DX（デジタル・トランスフォーメーション）の推進にも欠かせないと言われています。

今、DXが注目されているのは、コロナ禍を持ち出すまでもなく、ビジネス環境の激しい変化に対応するため、今までの古い体制をトランスフォーム即ち「生まれ変わらせる」必要があるためです。

そのためには、システムの入れ替えがどうのこうのというレベルの話ではなく、人材の育成や業務改革、そしてビジネス開発などを実行する組織文化の改革も考える必要があります。
無論こういった変革は、一気に実現できるものではなく、一歩一歩、理想の組織体制に向けて変わり続けていくしかありません。

システムを創るにしても、とりあえず要件定義をして、あとはシステム会社に丸投げという今までのやり方では当然対応できるものではなく、自分たち自身で、試行錯誤を重ねながら構築していく必要があります。

そのためシステムの内製化に取り組む必要のあるケースが増え、IT部門や業務部門自らが必要とするアプリケーションを開発するノーコードやローコードツールが注目されているわけです。

ローコードやノーコードの開発であれば、IT部門だけでなく業務部門の人も開発に参加できます。
これは開発のスピードを上げることに繋がりますし、現場で起こる様々なことや、ビジネス環境の変化にも迅速に対応できるようになる。また、現場で一定の成果が見えてくることで、さらなる改革への取り組みも期待できます。

試行錯誤しながら進める開発を、いちいちシステム会社に丸投げしていけば、そのたびに要求仕様の変更を繰り返すことになり、これでは予算や時間がいくらあっても足りなくなりますし、ビジネス環境の変化に対応することも難しくなります。
また開発の経験や知識が社内に貯まらないため、システムのことは「他人事」となって業務との乖離が拡がるとともに、外部システム会社との共同作業を効率させることも難しくなります。

そのお手本のような（？）事例が、みずほ銀行で何度も頻発したシステム障害で、「経営陣」―「IT部門」―「システム会社」の３者の関係が、それぞれ「丸投げ」で連携が全く取れていない体制であり、また、過去のシステム障害時の経験や教訓が、その後の体制ではほとんど生かされていなかったことなどが、報道からも伺うことができますね。

みずほ、３トップ来春退任　金融庁が２度目改善命令
―「経営責任重大」・システム障害（JIJI.COM）

ローコード開発で必要なビジネスモデル可視化とシステムモデリングの手法

ローコード・ノーコード開発では、上述のようにプログラム言語やコーディングの知識が要求されない代わり、ビジネスモデルの可視化とそれをシステムモデリングに繋げるスキルが問われます。

「ビジネスモデルの可視化」とは、現在のビジネスの状況を把握するとともに、その課題点を洗い出し、さらに変化するビジネス環境を見据えながら、新たなビジネスモデルを明確化することです。
さらにそれをDXに繋げるためには、「システムモデリング」、すなわちビジネスモデルをシステムモデルに落とし込むスキルも必要です。
それができないと、素晴らしいビジネスのアイデアも、具体的な形にすることができないからです。

システムの内製支援ができるエンジニアはわずか３％

ローコード開発やノーコード開発が浸透しつつある中、システムの内製化を検討する企業は増えてきています。
ただやはり前項に記したスキルを持つ人材の確保は難しいので、システム会社に依頼したり、あるいは内部のIT部門と共創する形で外部のシステム会社に開発を「指導」してほしいという要望も少なくないようです。
また、システム会社の側も、ローコード・ノーコード開発支援を唱えるベンダーも増えてきたように感じます。

ただし、この場合依頼する際に注意してほしいのが、そのようなシステム会社が、ツールの使い方の説明はできても、果たしてビジネスモデリングやそれをシステムに落とし込む指導やコンサルティングが本当にできるのかどうか見極めが必要なことです。

なぜなら、日本にシステムエンジニアは１００万人いると言われていますが、その中で「内製支援に対応できるエンジニアは３万人以下、つまり３％にも満たない」と言われているからです。（※）

日本のシステム会社がゼネコンのような多重下請け構造になっているのはよく知られていますが、そのような構造の中で、エンジニアの多くは上（元請け）から降ってきた「仕様書」に従ってシステムを作る。つまり「定められた要件定義どおりに正しくシステムを構築する」ことには長けていても、顧客のビジネスを分析したり、問題や課題を抽出しその課題解決を行うことは、「やったことがない」のが大半なのです。

だから会計や業務管理のような定まったシステムを作ることはできても、新たな「価値を創出するシステム」を顧客と議論しながら創出することはうまくいかない。例えば新型コロナ対応アプリのCOCOAのように、（税金で）４億円もかけて作ったシステムが、事実上無用の長物となったような話があちこちで起こるわけです。

　
これからの時代、システム会社に求められるのは、顧客と一緒になって課題を解決し試行錯誤を重ねながら目標に向かってシステムを構築すること、つまりアジャイルなアプローチなのですが、仕様書通りにつくることが前提の、ゼネコン階層型に慣れきった多くのシステム会社には、対応が難しいわけです。

ビジネスモデルの可視化とシステムへ繋げるフレームワーク

ローコードやノーコード開発を導入して、さらにDXを成功させるには、今まで求められていた「顧客の要件をもとに仕様書をまとめるスキル」「仕様書の通りプログラムをするスキル」では全く通用しない。
求められるのは、「「高度な知識を持ち、ビジネスサイドと対等にコミュニケーションを取りながら知識を応用し、デジタルビジネスを創っていく人」。ビジネスサイドと共に、どうすれば最善のシステムが作れるか考え、ときに提案し、ときにいさめ、場合によっては反論も辞さない「ものいう技術者」です。（※）」

弊社で開発されたビジネスモデル創出フレームワークの「ICONIX for Business Design」は、アジャイルの設計などで活用されている「ICONIXプロセス」をもとに、ビジネスモデルデザインを行うためのフレームワークです。

日本ビジネスモデル学会の今年度（2021年度）の学会誌で論文が採択され公開されました。

フレームワーク活用も含めたDXワークショップや、ソフトウェア（イノベーションテック・ツール）Blue Logicなどを通じ、日本の企業にDXが広がり、世界の中で競争力を取り戻す一助になるべく、今後も活動を続けていきたいと考えています。
　