DX(デジタルトランスフォーメーション)トレンドを背景に、「ニーズに応えるアプリケーションをいかにスピーディーに届けられるか」がビジネス差別化のカギとなっている。これを受けて内製化に乗り出す企業も増えつつある中、その実践手段としてローコード開発ツールが注目を集めている。だが従来のノンコード開発ツールとは、受け止められ方、使われ方は全く異なる――本特集ではローコード開発ツールの意義、成果、そして開発者とIT部門の役割を考える。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
「ITの力を使った体験価値」の創出力と提供スピードがビジネス最大の差別化要素となっている中、アプリケーション開発の在り方が多くの企業に見直されている。特に近年はクラウドネイティブの潮流を背景に、収益に直結する社外向けアプリケーションの開発において、コンテナやコンテナオーケストレーションを利用してCI/CD(継続的インテグレーション/継続的デリバリー)を実践する動きが、金融、保険、製造など一般的な企業にも及んでいる。
経営環境が刻々と変化し、先を見通すことが難しい中では、入念にビジネスの計画を立て、一定の時間をかけてアプリケーションを開発するウォーターフォールのアプローチではニーズに追従することは難しい。アジャイルやDevOpsのアプローチによって、俊敏に価値を届け、柔軟に変化に対応していくアプローチがおのずと不可欠になる。こうした考え方は10年以上前から注目されていたが、デジタルビジネスが浸透した近年になってようやく当たり前になり、実践例は着実に増えつつある。
無論、スピードや柔軟性が求められるのは社外向けアプリケーションだけではない。社内向けの業務システムについてもほほ同じことがいえる。市場ニーズの変化に応じて事業部門のビジネスニーズも変化する。ビジネスプロセスが変わり、これまでは合理的だったシステムが非合理的になることもある。こうした時、即座に変化に対応できなければ、便利だった既存システムは技術的負債と化してしまう。
とはいえ、日本企業においてはベンダーやSIerへの外注文化が一般的だ。ベンダーとの単なる仲介役のような役割を持たされているIT部門も少なくない。ニーズに対応するには、どうしても数カ月単位の時間と一定以上のコストがかかってしまう。さらに、ITをコストと見る日本企業の悪しき慣習もある。そもそもITが経営戦略とは切り離されているために、IT部門やIT子会社は事業部門からの要請を半ば一方的、かつ受動的にしか受けられないといった事情もある。
結果、事業部門がシステムの整備や改善を要求しても、ビジネス理解を基に主体的に対応することが難しく、「なかなかリクエストに応えてくれない」といった不満を抱かれ、これがSaaSの勝手導入などシャドーITを招き、ITガバナンス/コンプライアンスのリスクまでも呼び寄せることになる――こうした悪循環が繰り返されてきたのが多くの日本企業の実態だと言えるだろう。
だが前述のように、ビジネスとITが直結している今、ビジネス価値を届けるアプリケーション開発・提供の在り方は、「ビジネス展開の在り方」とほぼ同義になっている。こうした理解が浸透する中で、改めて「内製化」が重視されているわけだが、背景にあるのは以前のような「コスト効率」や「スピード」に対する期待だけではないだろう。
「ビジネス理解に基づいた、本当に使えるアプリケーションを開発する」ことへの期待や、「リクエストに迅速かつ丁寧に応えてくれるIT部門」実現への期待も大いに含まれているはずだ。DXトレンドが進展する中で、IT部門やIT子会社の役割が、改めて問われているといえるのではないだろうか。
だが「内製化」と一言で言っても、そもそも人的リソースやスキル、予算も限定的なことが一般的な中で、いきなり実現するのは難しい。
こうした中で、近年注目を集めているのがローコード開発ツールだ。
ご存じのように、設計支援ツールやコード自動生成ツール、保守ツールなどを組み合わせた統合CASE(Computer Aided System Engineering)ツールや、用意された機能部品をGUI(グラフィカルユーザーインタフェース)上でつなぎ合わせてアプリケーションを設計し、ソースコードを自動生成するRAD(Rapid Application Development)ツールなど、ノンコード開発ツールは以前から使われてきた。だが、シンプル・簡単になることの裏返しとして課題も存在した。
具体的には、ツールの仕様に縛られるため細かな要件に対応しにくい、構築後の機能拡張や他システムとの連携が難しいなど、柔軟性に欠ける側面が指摘されてきた。例えば社内の一部門における比較的シンプルなアプリケーションなら十分に対応可能だ。だが、ビジネス展開や収益に影響するようなアプリケーションの場合、変化対応力が低いことは致命傷となる。設計書を基にテンプレートを自動生成し、下流工程まで支援する統合CASEツールのようなウォーターフォール型開発を前提としたツールも、ビジネスニーズの変化に柔軟に対応することは難しい。
また、今求められているのは、「アプリケーションを速く作ること」ではなく、「価値を速く届けること」だ。コーディングは全開発工程のうちの一部に過ぎない。コーディングだけ自動化しても「提供するまでのリードタイム短縮」に資する効果は限定的だ。その点、ローコード開発ツールは、コードを書くこともでき細かな仕様や変更に対応できる、拡張性が高い、UIやロジックも含めてアプリケーション全体を構築できるなど、ノンコード開発ツールの課題を解消するものとなっている。
一般に、ノンコード開発ツールは、「シンプルなアプリケーションなら、IT部門の手を借りなくても事業部門が作れるようになる」といったEUC(エンドユーザーコンピューティング)の文脈で語られることも多かった。ローコード開発ツールはそれとは異なり、「開発者の負荷を下げ、プログラミングに集中できるようにするツール」「収益向上のためのアプリケーションをスピーディーに作るための武器」といった捉え方が正しいだろう。
というのも、今求められているのは「価値創出の高速化」であり、「コーディングの高速化」ではないためだ。ITがビジネスを直接的に支えている以上、社外向け、社内向けを問わず、ビジネス目的をエンドユーザーと共有し、確かなビジネス理解の下、「ビジネス/サービスで行う一連のこと」を迅速に“プログラミング”し形に変えることが求められている。コーディングはその実装作業の一つに過ぎない。
ビジネスとITの分断が長年の間、課題とされ、役に立たないシステム、使ってもらえないシステムが量産されてきたのも、こうした“プログラミングの部分”でビジネスとの連携が薄かった故だ。だがエンドユーザーと共に「価値」を追求する、技術者としての観点からより効率的な提案をする、といったスタンスが開発者に強く求められている。それを実践してビジネスを作り出している、ビジネスに寄与している開発者も増えている今、ローコード開発ツールは単に開発効率化やコスト削減に役立つだけではなく、開発者の創造性を拡張させるツールにもなり得る。
では貴社の場合、これをどう位置付け、どう使うのか? 「ビジネスに寄与する」ための環境が整う中で、開発者やIT部門の役割が今改めて問われている――本特集では数々の事例を通じて、ローコード開発の意義、成果、そして開発者とIT部門の役割を考える。
DXトレンドが進展し、ビジネスニーズに応えるスピードが差別化の一大要件となっている。それが社内向け、社外向けであるかを問わず、「ニーズに応えるアプリケーション」開発を、従来のように逐一外部に依頼するスタイルでは、現在のビジネススピードに対応することは難しい。特に、ITがビジネスとほぼ同義になっている今、SoE領域/競争領域のアプリ開発を外部に依頼することは、ビジネスノウハウという無形資産の流出にも等しい。とはいえ、社内に十分な開発リソースを持つ企業は限定的な他、新たに開発人材を雇用することもハードルが高い――こうした中で、今改めて注目を集めているのが「ローコード開発」だ。では具体的に、ローコード開発はDX推進に何をもたらすのか、情シスやIT部門にどのような影響を与えるのか。本特集では“既存の見方”も踏まえつつ、事例も含めて「ローコード開発の今」を徹底解説する。
Copyright © ITmedia, Inc. All Rights Reserved.