内製化を推進するための手段として、ローコード開発に注目が集まっている。だが、現実のアプリケーション開発現場では必ずしも期待通りに物事が進むとは限らない。ローコード開発ツールを活用する先行企業から寄せられた“SOS”に応えてきたという識者に、ローコード開発×内製化の取り組みに失敗した事例とその真因、成功に導くポイントを聞いた。
アプリケーション開発をもっと速く、簡単に――そんなニーズに応える技術として、ソースコードの量を減らすことで開発効率を高める「ローコード開発」ツールが近年注目を集めている。その背景にあるのが、これまで外部に委託していたアプリケーション開発を自社で内製する「内製開発」だ。
なぜ多くの企業が内製開発を目指すのか。最大の理由は開発期間の短縮に対する要求がより一層高まったことにある。「スマートフォンやデジタルサービスの利便性が当たり前になった今、高度なITサービスを迅速に提供することが企業に求められています」と語るのは、ビルドシステムの新川博己氏だ。B2C(Business to Consumer)領域で新しいデジタルサービスが短時間で次々と登場する今、1つの業務システムの開発に数年をかけることは競争力の低下につながりかねないというわけだ。
開発期間の短縮は経営層も重視している。「デジタルビジネスにおいてサービスを差別化するためには、やはりスピードが命となっています」と語るのは、ビルドシステムの鈴木裕太氏だ。「競合各社が同じようなデータや既存資産を持っているため、サービスが似てしまうのは当然です。競合より一刻も早くサービスを世に出して顧客を獲得しないと、先行者利益を得られません」と指摘する。
とはいえ多くの企業は、コーディングができる人材がそもそもいないか、不足しているというのが現状だ。IT部門は既存のアプリケーションの運用やメンテナンス(改善)で手いっぱいであり、サービスの新規開発は容易ではない。外部のソフトウェア開発企業に委託しようにも、業界の慣習や従来の業務プロセスを把握するまでに一定の時間がかかってしまう。
そこで、「エンジニアでない事業部門のメンバーでもアプリケーションを開発できる」ことをうたうローコード開発ツールへの期待が高まり、活用が進んでいるというわけだ。事業部門がアプリケーションの開発を内製化できれば、業務理解の期間をスキップできて、開発期間をその分短縮できる。
もっとも、物事はそれほど単純ではない。「ローコード開発ツールによる内製開発を試みたが、目的を果たせなかった企業も多い」と新川氏は言い、ビルドシステムに相談が寄せられた3つの失敗事例を紹介する。
1つ目は、事業部門主導でアプリケーション開発を目指した企業Aのケースだ。事業部門の2人とIT部門の若手1人でチームを組み、ローコード開発をOJTで学びながら2カ月でアプリケーションを完成させた。「ところが、設計とテストが不十分だったために、本番運用を始めた直後に動作が不安定でまともに動かないことが判明しました。チームの実力では動作が安定しない原因を突き止めることができず、結果的にアプリケーションを作り直すことになりました」(新川氏)
2つ目の企業Bは、ローコード開発を「若手エンジニアの登竜門」と位置付けて、新卒と若手を中心とするメンバーで開発チームを編成。ローコード開発なら短期間でスキルが身に付くだろうと考え、実戦投入した。その結果、アプリケーションこそ完成したものの、拡張性と保守性に乏しい設計、実装だったために稼働後もメンテナンス作業が延々と続くことになった。「確かにローコード開発の学習コストは比較的低いです。しかし『何をどう作るか』の基礎的な設計力や品質意識を育成するには、座学と実践の両面からの支援が欠かせません」(新川氏)
3つ目の企業Cは、検索、分析系のフロントアプリケーションをローコードで開発しようとした。だが、検索スピードが業務要件を大幅に下回り、実用に堪えないことが結合テストの段階で判明した。大量データの取り扱いを想定した設計と実装をしていなかったことが原因だ。採用したアーキテクチャが適切ではなく、パフォーマンスチューニングも奏功しなかった。「開発環境で少量のテストデータで試した際には『ちょっと遅いかな?』というレベルで済んでも、本番に近い数十万件、数百万件といったデータを使う結合テストでパフォーマンスの問題が判明するケースは珍しくありません」と新川氏は指摘する。
3つの事例から読み取れる教訓は、2つある。
まず、ローコードによる内製開発であっても、開発チームにはコーディングできる開発経験者を何割か含めておかなければならないということだ。アーキテクチャ設計を含むシステム設計は事業部門の未経験者にとって難しく、処理速度低下などのトラブルが起きたときのパフォーマンスチューニングも困難だ。コーディングできるメンバーにはその部分を補完する役割が求められるため、経験が浅い新卒や若手ではなく、経験者を充てるべきだといえる。
もう一つが、ローコード開発ツールを活用するとはいえ、入念なアーキテクチャ設計は欠かせないということだ。「DB(データベース)の設計をプロが見れば、パフォーマンス問題に発展するかどうかは一目で分かります」と鈴木氏。ローコード開発ツール側の内部動作は容易には分からないため、ツールの知見、ノウハウを持つパートナー企業に検証を依頼するのも一つの手段だろう。
ビルドシステムは、シーメンスのローコード開発プラットフォーム「Mendix」を軸とする5種類のサービスを提供している。
5種類のサービスのうち、新規開発プロジェクトを伴走支援するのが「Mendix App構築支援サービス」だ。
Mendix App構築支援サービスの最大の特徴は、ウオーターフォール開発プロセスとスクラム開発プロセスを組み合わせた「ハイブリッド開発手法」で行う点にある。同社がハイブリッド開発を重視するのは、「現実には、スクラムなどのアジャイル開発手法で開発の全てを行うのは難しい」(新川氏)ことや「ピュアなアジャイル、スクラム開発を実施することには無理があるので、どこかに妥協点を見いださなければならない」(鈴木氏)と考えているためだ。設計工程のプロトタイプ作成までをウオーターフォール開発、設計の後続部分である開発、実装、テストの各工程をスクラム開発プロセスで進める。
スクラム開発プロセスでは、基本的に、顧客(発注者)がプロダクトオーナー(PO)となり、ビルドシステムのエンジニアがスクラムマスター(SM)として開発チームを率いる形をとる。開発チームは毎朝の朝会でその日に取り組むべき作業を確認し合った上で、Mendixで開発作業を実施。スプリント(1回の開発)は1週間から4週間の期間を標準とし、1回のスプリントが終了する際のレビューでPOの承認を得てから次のスプリントを進める。
ビルドシステムは「トラブルに陥ったローコード開発案件」の支援も引き受けている。Mendixの豊富な知見と経験を持つ同社は、Mendixで開発したアプリケーションの内部動作を可視化するためのツールも独自に構築している。ビルドシステムの独自ツールやDB管理ツールで取得したログを基に、問題の真因を突き止めて、改善のためのコンサルティングをするというのが大まかな流れだ。
「繰り返し処理内で行われていたDBアクセスをループ外に移すことで、DBにアクセスする回数を100分の1程度に減らし、アプリケーションの応答時間を大幅に短縮できた事例もあります」(鈴木氏)
新川氏は「Mendixエンジニアが多く在籍し、多数の開発実績を持つ当社は、Mendixアカデミー公式パートナーとしてお客さまの内製開発を支援します」と胸を張る。
ビルドシステムは今後の活動テーマの一つに「データの民主化」を掲げる。アプリケーションをローコードでスピーディーに内製開発できても、データレイクなどに蓄積されたデータを活用できなければ、DX(デジタルトランスフォーメーション)は成し遂げられない。ビルドシステムはシーメンスと共に、データ探索に強いデータウェアハウス「Snowflake」とMendixを連携させ、データを活用しやすくする構成を用意する。
業務に詳しい人が自らアプリケーションを作ることによってDXを促進し、企業の変革を実現する――ローコード開発ツールへの期待は大きく膨らんでいる。だが、簡単な道のりではない。ローコード開発や内製化に不安があるなら、ビルドシステムのように知見やノウハウを持つ外部パートナーの力を借りながら取り組みを進めてみてはいかがだろうか。
Copyright © ITmedia, Inc. All Rights Reserved.
提供:株式会社ビルドシステム
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2025年7月5日