「簡単に作れる」の落とし穴 ロー／ノーコードツールが基幹システムを“危険にさらす：SIerはどこから来て、どこへ行くのか

手軽に誰でも利用できるという触れ込みのローコード／ノーコード開発ツール。筆者が基幹システムの開発に同ツールを適用するのは「愚の骨頂」だと主張するのはなぜか。新しい開発手法の適用で起こり得る問題と、リスクを軽減するための手法に迫る。

[室脇慶彦，SCSK株式会社]

この連載について

　ユーザー企業にとって、SIerはITシステムの導入から運用、故障時の対応や更新などに欠かせない存在です。

　しかし、その関係性はと言うと、対等なパートナーと言うよりも、ユーザー企業はSIerに対して丸投げしがちで、SIerも「お客さまであるユーザー企業の要望は断りづらい」ために、ユーザー企業のITシステム全体の最適化よりも、その場その場のニーズへの対応を重視しがちな「御用聞き体質」が指摘されてきました。

　こうした中、DX案件の増加やIT人材の慢性的な不足、ユーザー企業の内製化志向などのさまざまな環境変化によって、ユーザー企業とSIerとの関係は変わらざるを得なくなりつつあります。

　この連載を通じて、SIビジネスを取り巻く構造的な問題を掘り下げ、ユーザー企業とSIerが目指すべき関係の在り方を探っていきます。

　「プログラミングができなくても、誰でも簡単にアプリが作れる」――。こうしたキャッチフレーズを引っさげるローコード／ノーコード開発ツールが急速に普及している。IT人材不足に苦しむ日本のユーザー企業の救世主として期待され、実際に多くの企業が導入を進めている。

　しかし、ここで筆者は警鐘を鳴らしたいと考えている。「簡単に作れる」ことと「適切に管理できる」ことは全く別だ。特に、事業活動の根幹を支える基幹システムの開発にこうしたツールを適用することは、取り返しのつかない技術的負債を生み出す危険性がある。

　前回は、最新のシステム開発手法であるマイクロサービス化における技術的課題である非同期処理の前提とAPI管理などの煩雑さについて述べ、これらの課題に対してサービスメッシュなどの新技術が解決策を提供し始めていることも紹介した。

　今回は、こうした新しい開発手法に対して「従来のプロジェクトマネジメント手法が通用しないことで起こる問題」を掘り下げる。さらに、一見便利に見えるローコード／ノーコードツールを基幹システム開発で利用することがなぜ危険なのか、過去の失敗事例を交えながら解説する。

「作りやすさ」重視がもたらす落とし穴とは？

　近年のシステム開発では、スピードと柔軟性が重視される傾向にある。ビジネス環境の変化に素早く対応するため、従来の大規模な一体型システム（モノリシックアーキテクチャ）から、小さな機能単位に分割したシステム（マイクロサービスアーキテクチャ）への移行が進んでいる。

　この流れの中で、さらに開発のハードルを下げようとローコード／ノーコード開発ツールが登場した。ドラッグ・アンド・ドロップで画面を作り、設定画面でロジックを組み立てることができるため、確かに試作品（プロトタイプ）やシステムの最初の動くバージョンといった初期開発では早く形にできる。しかし、そのシステムがどのような仕組みで動いているのか、なぜそのような設計になっているのかという「設計思想」が見えなくなってしまう。

　これは、かつてのEUC（エンドユーザーコンピューティング）の失敗と全く同じ轍（てつ）を踏もうとしていると筆者は考えている。】

EUCが残した爪痕

　1990年代〜2000年代初頭にかけて、EUCがもてはやされた時期があった。「エンドユーザーが自分でシステムを作れる」という触れ込みで、「Microsoft Excel」のVBA（マクロ機能）や「Microsoft Access」で作り込まれた業務システムが乱立した。

　その結果、何が起きたか。作成者が異動や退職でいなくなった後は、誰もメンテナンスできない「野良システム」が大量に残った。

　プログラムを書き替えるのではなく、パラメータの数値を変更することで将来的な変更に対応する「パラメータ化」は、ユーザーにとって設定画面で数値を変えるだけで動作が変更できる便利な仕組みだ。このパラメータ化を過剰に作り込んだシステムについて、筆者は以前、相談を受けた。

　問題になっていたのは、「なぜこのパラメータを設定したのか」という作成者の意図が全く文書化されていない点だった。

　パラメータは何かを実現する手段でしかない。「何のために」という目的に関する情報が失われれば、制度変更や法改正への対応は極めて困難になる。結局、そのシステムはイチから作り直すしかなかった。移行作業は困難を極め、多大なコストと時間を要した。

課題3：「従来の手法が通用しない」時代のプロジェクトマネジメント

　プロジェクトマネジメントの根幹は、QCDの3つだ。

• Q（品質）：　Quality
• C（コスト）：　Cost
• D（納期）：　Delivery

　特にソフトウェアの場合は、「Q（品質）」の見極めが極めて重要だ。そして、新しい開発手法では、この品質管理の考え方を根本から見直す必要がある。

　「Q（品質）」の最終的なゴールは「顧客満足度」にあるが、その達成のためには一般的には、6つの品質特性から品質をとらえる必要がある。筆者は、これらの品質特性を踏まえた上で、該当のプロジェクトの品質を大きく2つにまとめて考えている。

• 機能品質：　顧客（ユーザー企業）から見た使い勝手
• 製造品質：　バグを限りなく「0（ゼロ）」に近づけること

　従来の開発では、これらを一括して管理していた。小さな機能単位で開発を進める新しい手法では、それぞれを独立して管理して継続的に改善する必要がある。

　そこで筆者が提案するのが、機能品質を向上させるための2つの革新的アプローチだ。

1.　要件定義の標準化と「見える化」の重要性

　一般的には、業務フローあるいは画面遷移図などを統一的なルールで記載し、顧客企業が十分に確認できることが重要だ。何よりも大事なことは、該当のITシステムの機能を網羅的に把握できるようにすることだ。

　これにより、顧客企業と開発側の双方に機能品質が可視化され、設計情報を共有することが重要となる。その際に大切なのは、共有された情報を基に第三者が開発に参加できることだ。

　基幹系システムはメンテナンス期間が長く、SEの人数が多い。SEの入れ替わりも頻繁（ひんぱん）だ。当然、顧客企業の担当者も同様に入れ替わりが多くなる。トラブルが発生すればその影響は大きく、トラブルに対応するためにもITシステムの情報が共有される必要がある。

2.　実稼働システムによる検証と素早い改善対応

　実際に稼働するITシステムを顧客企業に見せ、利用に当たっての問題点や改善点を把握できるようにすることが重要だ。改善点に素早く対応することが必須になる。

　これは従来の「完成してからテストする」といったアプローチとは根本的に異なる点だ。「動くシステム」を早期に提供し、フィードバックを受けながら改善するというアジャイル開発の本質的な要素となる。

イテレーション開発における品質管理の新手法

　業務要件を最初に決定できる機能と、幾つかの機能が決定されて初めて業務要件が明らかになる機能がある。具体的に言えば、銀行の勘定系は、口座開設機能を決定して入金処理が決定できる。入金処理の決定を受けて出金処理が決定されるという関係にある。

　従来型のプロジェクトマネージメント手法であれば、全ての機能について同時期に要件定義を終了させる必要がある。これは手戻りを最小化するためだ。ただし、これでは機能の定義が最後になる部位の品質を確保するのは極めて困難だ。つまり、全てを同時に終了させるという従来の手法は無理があった。

　新しい開発方式では、まず独立した一つの機能を開発し、ユーザーに確認する。それとほぼ並行して新たな機能の要件を決定して開発し、ユーザーに確認するといった業務が五月雨式で進行する。この場合、各機能が独立して要件定義から開発できることが前提となる。

　また、五月雨方式は「イテレーション」（反復的な開発サイクル）と呼ばれる場合が多い。イテレーションを繰り返しながら順次リリースする方法だ。

　イテレーション開発は具体的には次のような流れで進む。

1. 第1イテレーション：　机上の要件で作成したITシステムを提供し、改善点の指摘を受ける
2. 第2イテレーション：　改善点が反映されたITシステムを提供し、さらなる改善点等の指摘を受ける（この段階で機能品質が向上している場合は、改善点も少量となる）
3. 第3イテレーション：　最終確認のためのITシステムを提供し、ユーザーサイドで確認・検収後リリース

　上記と並行して別の機能（Bとする）の開発を進める。最初の機能（Aとする）の第1イテレーションの段階で機能Bについて机上の要件定義をし、機能Aの第2イテレーション時に同時に要件定義で作成したITシステムの改善点の指摘を受ける。さらにまた別の機能（Cとする）は、機能Aの第2イテレーションイテレーションと同時に机上の要件定義を実施し、Aの第3イテレーション時に要件定義で作成したITシステムの改善点の指摘を受けることになる。

　つまり、要件Aの第3イテレーション時には、3つの異なる機能のイテレーションが同時に実施されることになる。機能ごとに品質を評価することになる。

　これらを技術的に実現するには、疎結合であるマイクロサービスアーキテクチャと、短期間の開発サイクルを反復するアジャイル型開発の行動規範が同時に求められる。

　そして、各イテレーションの終了基準を明確にし、プロジェクトの品質を評価することが重要だ。

　机上の設計があまりにずさんであれば、大幅な設計変更と多くの改善点が発生し、イテレーションの回数を増やす必要が出てくる。イテレーションの各フェーズで品質を確保する、あるいは品質状況を的確に把握する必要がある。

　特に大規模システムを開発する場合は、チームが複数になり、チームごとの品質を的確に把握して対応するマネージメントが必要になる。そのためにも、品質状況の定量的な把握に努めながら、客観的な品質指標を新たに蓄積することが求められる。

ローコード／ノーコード開発はなぜ基幹システムに「向かない」のか？

　ローコード／ノーコード開発ツールがもてはやされているが、システム仕様が属人化しやすい傾向を認識して適用すべきだ。開発の簡単さを重視し、本来は不可欠な設計情報の可視化を無視して重要なITシステムにローコード／ノーコード開発ツールを適用するのは、筆者に言わせれば「愚の骨頂」だ。

　リリース時には各チームで設計情報を公開することが、重要な最終終了基準になる。アジャイル型開発であろうと基幹系システムを開発する以上、必要な情報を正しく維持・管理するのは当たり前だ。

　ローコード／ノーコード開発ツールで作られたシステムも、表面的には動作する。しかし、その内部のロジックは開発ツール固有の形式で保存され、他システムとの連携や将来的な拡張が極めて困難になる。

　さらに深刻なのは、開発ツールベンダーへの依存度が高まることだ。ツールのサポート終了やベンダーの事業撤退にシステム全体の継続性が脅かされる。基幹システムのような長期運用が前提のシステムにとって、これは致命的なリスクとなる。

モダン開発で守るべき原則、変革すべきものは？

　では、モダン開発において致命的なリスクを避けるためにすべきことは何か。ITシステムには、寿命や重要性などさまざまな特性がある。それらを踏まえた上で、維持すべき情報は決まる。これはモダンな開発でも変わることはない。

　ただし、機能品質の見極め方一つとっても、従来型の開発方式におけるプロジェクトマネジメント手法と大きく異なることは間違いない。守るべきものと変革すべきものをSEとして見極めながら、モダンな開発における機能や品質を測定することが求められる。

　ローコード／ノーコード開発ツールは、プロトタイプの作成や部門レベルで利用する簡易的なアプリケーションの開発には有効だ。短期間で成果を出し、ユーザーの反応を見ながら改善する用途にローコード／ノーコード開発ツールは適している。

　しかし、基幹系システムのような企業の根幹を支えるシステムには、設計思想の透明性と長期的な保守性を最優先すべきである。「簡単に作れる」という魅力に惑わされず、10年後、20年後を見据えた技術選択が必要だ。

　次回は、製造品質について詳しく説明する。特に、マイクロサービス環境における自動テストの重要性と、継続的インテグレーション／継続的デリバリー（CI/CD）の実践的な適用方法について掘り下げていきたい。

著者紹介：室脇慶彦（SCSK顧問）

むろわき　よしひこ：大阪大学基礎工学部卒。野村コンピュータシステム（現野村総合研究所）執行役員金融システム事業本部副本部長等を経て常務執行役員品質・生産革新本部長、理事。独立行政法人　情報処理推進機構　参与。2019年より現職。専門はITプロジェクトマネジメント、IT生産技術、年金制度など。総務省・経産省・内閣府の各種委員等、情報サービス産業協会理事等歴任。著書に『SIer企業の進む道』（日経BP）、『プロフェッショナルPMの神髄』（日経BP）など。