BCPにはトランスコーディングよりもローコード開発が効率的な理由
今、仕事に使っているITシステムは、現状のビジネスやモダンな環境に対応していますか?
機能的に不十分で非効率、UIも古くて使いづらく、必ずしもセキュアではない。開発当時の担当者はすでにいないし、メンテナンスもしにくい。しかし、取りあえず動いているのをわざわざ触って、自分の余計な仕事が増えるのはやぶ蛇。見なかったことにしたいけれど、いつかは何とかしなければならないのは、皆、薄々気付いている…
BCP(事業継続計画)としてビジネスの継続性と発展を考えると、レガシーなプログラムを処理する方法として、トランスコーディングやリファクタリングと呼ばれる手法が検討されます。しかし、状況によっては、ローコード開発プラットフォームで作り直す方が効果的かもしれません。
突然の外部サービス終了というリスク
ビジネスかプライベートかに関係なく、サービスの終了は珍しくありません。 通常は、サービス終了がアナウンスされる時に、数ヶ月単位の猶予が示されます。データのバックアップや書き出し、新サービス・他サービスへの移行、アカウント情報の廃棄、アップデート・アップグレードや新規申し込みの終了、契約プランに応じた返金処理などが明示されます。
ただ、いくら時間的な猶予が示されても、バックアップや新しい環境に移行して検証まで完了する作業は、ユーザーには大きな負担です。関連サービスへのAPIの再連携、ライブラリーの移行、サードパーティー製プラグインとの互換性など、いろいろな課題があります。 ユーザーにとって重要なのはアプリケーションではなく、それを使って作られた貴重な資産としてのデータです。しかし、年末年始や年度替わり、長期休暇シーズンや、人が入れ替わる時期に重なると、十分な引き継ぎができないリスクも重なります。
サービス終了の理由は、多くの場合、マーケットニーズに合わなくなったり競合のプレッシャーに破れたりと、ビジネス的な背景が関係します。しかし、技術トレンドの変化に伴ってプログラムコードが膨大になり、メンテナンスや新しい機能追加が厳しくなったケースもあります。そういった事情は、利用するユーザー側には関係ないとはいえ、SaaSなどの外部サービスに依存している限り、大きな影響を直接受けるリスクは常に抱えています。
トランスコーディング/リファクタリングとは?
ソフトウェアは、常に未完成です。OSやデバイス、連携先のソフトウェア、技術トレンド、社内体制、マーケットニーズ、社会環境など、さまざまな要因で起きる変化に常に晒され続けます。これらの変化に柔軟に対応するシステムが、ビジネスを安定して存続・発展させるBCPの視点からも不可欠です。
多くの場合、貴重なデータ資産を活かすために、既存のシステムを改修・更新して、環境の変化にキャッチアップすることを検討するでしょう。そこで、トランスコーディングとリファクタリングという2つの手法があります。
機能は変えずに変換するトランスコーディング
トランスコーディングとは、あるプログラミング言語やフォーマットから別のものに変換するプロセスです。例えば、Javaの古いプログラムから、Pythonの新しいプログラムへ移行するように、現状の機能は維持しつつ、異なる環境での互換性を確保する作業です。
トランスコーディングは、既存のコードを再利用できるため、開発時間の短縮やコスト削減が期待できます。ただ、変換プロセスでの不具合や、パフォーマンスの低下が生じる可能性もあります。
改善して最適化するリファクタリング
一方、リファクタリングとは、外からの見た目や機能は変えずに既存のコードの内部構造を改善し、可読性や保守性を向上させるプロセスです。冗長なコードを削除して最適化したり、関数を分割して再利用しやすく、途中から他者が参加してもストレスなく理解できるように、整理する作業です。
リファクタリングによって、バグの発見や修正が簡単になり、生産性が向上します。その一方で、時間が掛かることで、短期的にはプロジェクト全体の進捗が遅れる可能性もあります。
トランスコーディングとリファクタリングの共通点と違い
両者の共通点や違いも見ておきましょう。トランスコーディングとリファクタリングは、どちらもソフトウェアの改善を目的としていますが、そのアプローチが異なります。
トランスコーディングは、主に言語やフォーマットの変換に焦点を当てていて、新しいプラットフォームへの移行時などに必要になります。一方、リファクタリングは、コードの内部構造の改善に重点を置き、コードが複雑になり過ぎたり、技術的負債が蓄積した時に検討されます。
例えば、ある企業が古いERP(統合基幹業務)システムを新しいクラウドベースのプラットフォームに移行する時には、トランスコーディングが必要になるかもしれません。一方、既存のアプリケーションのパフォーマンスを向上させるには、リファクタリングが有効な可能性はあります。
両者は相反するものでもなく、使い分けられたり組み合わせられ、既存のシステムをアップデートすることに利用されます。
本当に「ソフトウェアの改善」程度で十分なのか?
ただし、トランスコーディングやリファクタリングが果たして最適解なのか?は、十分に検討する必要があります。
レガシーなシステムをそのまま継承することは、応急処置的にアップデートしておくには有効です。社内の稟議や教育、リスク対策も最小限で済むでしょう。
しかし将来を見据えると、むしろその付け焼き刃な対応が、新しいチャレンジの阻害要因になるかもしれません。既存のシステムだけでなくビジネスプロセスをそのまま、最新の環境に適応させたところで、非効率なやり方であっても変わらず、新たな学習機会にもならないからです。
重要なのは、組織全体のDXの文脈で、システムのアップグレードをどのように位置づけるべきか?です。ビジネスのプロセスを根本から見直してイノベーションにつなげる、創造的破壊としてのDXに沿っていなければ、意味はありません。
トランスコーディングやリファクタリングは、単なるソフトウェアの改善ではなく、自社のビジネス全体を俯瞰した大局的な視点から検討することが前提です。その結果として、蓄積されたデータ資産を活かすだけでなく、新たなビジネスチャンスにつなげるには、むしろ新規のシステム開発が効率的だという判断に至ることは、とても自然な結論です。
広い視野で見るローコード開発の強み
トランスコーディングやリファクタリングのプロセスを大幅に簡素化する上で、ローコード開発プラットフォームは有効な手段です。
例えば、OutSystemsはエンタープライズレベルで要求される、さまざまなニーズに応えます。ビジネスで必要とされる豊富なテンプレートやモジュールが提供されている一方、必要な部分ではコードを書くことで処理できる、柔軟性とスケーラビリティーが特徴です。属人化を排除することで、設計・開発だけでなく、保守・運用コストも抑えられます。
▼OutSystems | 株式会社BlueMeme
https://www.bluememe.jp/outsystems/index.html
また、Workatoのようなローコードのインテグレーション基板を使えば、圧倒的なスピードでシステム連携を設定できます。レシピやコネクタと呼ばれるモジュールを使って、AWSやSalesforce、kintoneなど幅広いアプリケーションやプラットフォームをサポート。視覚的・直感的なUIによるドラッグ&ドロップで操作でき、高度なプログラミングの専門知識やDevOpsも不要です。
新しいシステムをゼロから開発する場合も、スピーディーかつ効率的に構築できるので、企業は既存のプロセスや制約から解放されます。より効率的で柔軟なビジネスプロセスから設計し、トランスコーディングやリファクタリングは、必要なところだけに限定できます。
BCP視点で考える、攻めのDXとしてのローコード
冒頭で触れたFinaleの場合、ユーザーである演奏家たちは、コロナ禍の非接触・無観客という条件で、著しく行動を制限されました。一般企業でも、提供するサービスの大転換や、廃業すら迫られた例は珍しくありません。BCPの視点で考えれば、同じようなパンデミックがいつか再び起きることを前提に備えるべきでしょう。
「2025年の崖」が目前に迫り、労働生産人口は減る一方です。驚異的なスピードで普及と機能強化が進む生成AIや、広く影響している気候変動の悪化、株価の乱高下と円安、企業へのサイバー攻撃なども無視できません。パッケージ製品のライフサイクル終了だけでなく、提携先のシステムが変わったり、業務拡大など、組織の内外・大小さまざまな要素がビジネスに深刻な影響を与えています。
トランスコーディングやリファクタリングといったプロセスは、既存システムの維持において重要な役割を果たしています。しかし、DXが叫ばれる—しかし実際には、レガシーな負の遺産からの転換が進まない現代において、企業は急激な変化に対応できる柔軟な方法を模索しています。
ローコード開発プラットフォームは、ビジネスプロセスの根本的な見直しやイノベーションを促進する上で、非常に有効なアプローチです。そのアドバンテージは、技術的負債を軽減し、持続可能なソフトウェア資産を構築するだけに留まりません。新しいエンジニアの確保と育成にもつながる挑戦が、企業にとっての新たな価値を創造し、変化する市場に適応して競争力を高めていきます。