なぜ複数のローコード環境を使うのか？メリットとデメリットは？
kotobato
リープリーパー
マルチローコード成功の鍵を握るのは次世代のエンジニア人材だ！
kotobato
前回までの記事で見たように、一つのローコード・ノーコード開発環境にしがみついて、多様な業務を処理することは、現実的ではありません。複数のプラットフォームを使い分けた方が、現実的・合理的です。
しかし、現場のニーズに振り回されてばかりでは、収拾が付かなくなるはず。運用や情シス部門が疲弊するのも目に見えています。では、マルチ戦略を成功させるには、どのような人材やチームが必要でしょうか？
経験豊富なエンジニアの存在は不可欠
ローコード・ノーコードといえば、非エンジニアでもコードを手入力することなく、自分が必要なアプリを簡単に開発できる点が、とかくフィーチャーされがちです。しかし、サービスが混在して管理が煩雑になれば、トータルコストは膨らむばかり。連携が不十分だと、ノウハウや人材もサイロ化・縦割りになってしまいます。DX推進のために社内での内製化を目標としていたはずが、複雑さや膨大な手間が負担になって、結局、社外のSIerに委託する状態に逆戻り…。
複雑なプラットフォーム群を最大限に使いこなすには、状況を俯瞰的に判断して決断できる、経験と実績に優れたエンジニアの存在が不可欠です。また、以下のような多様なスキルや意識を持つ人材も重要です。
- 単なるITシステムだけでない、ビジネス面のビジョンと強力なガバナンス
- 複数のプラットフォームを効率的に活用する、アーキテクチャー設計
- 異なる環境や既存システム間のシームレスな統合、トレードオフのバランス
- エコシステム全体で目標を実現する、コミュニケーションとリーダーシップ
- 特定のニーズに対する、社外SIerやベンダーとの戦略的パートナーシップ
業務+IT両方に精通したビジネスアーキテクトの重要性
ビジネスアーキテクトという存在は、現代のビジネスに不可欠です。これは、ビジネスとITの両方を深く理解する人材のこと。自社や顧客のコアビジネスを深く理解し、ゴールを達成するために、ITシステムを自身で開発できる人材です。
従来型の企業では、例えば営業/開発/運用のように、部署や役割が縦割りに分かれていました。組織の構成上、今もこの棲み分けは残っていますが、これらを横断的・俯瞰的にマネージメントできる職種が重要になっています。
顧客にとって真のゴールを達成するには、システムとしてどのような機能が必要か？それを達成する技術要件や、必要な人材の確保や育成は？運用を見越すとどの部分がネックになりそうか？テクノロジーやマーケットのトレンド分析は？どのローコード・ノーコードを組み合わせるのがベストか？
また、プロジェクトの司令塔として働くビジネスアーキテクトには、多様なスキルを持つメンバーで構成されたチームを率いるリーダーシップも不可欠です。
高速開発に適応したテストエンジニアも要注目
ローコード・ノーコード開発によって、設計→開発→テスト→デプロイ→リリース→運用というサイクルは、高速化する一方。しかし、品質を担保するテスト工程が不要になることはありません。
ローコード開発プラットフォームの多くには、優れたテスト機能があります。また、テストに特化したローコードツールもあり、開発側のサービスと強力に連携できます。この分野にもAIが導入されることで、開発に合わせたシナリオの自動作成やアップデート、開発へのフィードバックなども大きな魅力となっています。
これらを最大限に利用した上で、人間でなくてはならない判断を適切に下せるのが、上級テストエンジニアです。テストは開発工程の一部ですが、前述のビジネスアーキテクト的な視点も持ち、より効果的・合理的なテストを設計・管理できるエンジニアには、より高い価値が認められます。
複数のローコード環境で情シスにも変化が必須
情報システム部門の担当者といえば、忙しい様子が日頃から漏れ聞こえてきます。通常業務をこなすのが精一杯で、IT関連部署とはいえ、とてもDXの実践にまで手が付けられないという、本末転倒気味の悲鳴も。
日々のトラブルシューティングやインシデント対応がある一方、今あるツールの管理だけでなく、オンプレミスのシステムからの移行、野良AIやRPAなどのシャドーIT対策、レガシーシステムの問題が目白押し。ローコード・ノーコードのマルチ化と聞けば、担当者の不安や抵抗は十分想像できます。しかし、求められる変化は、仕事量や内容というより役割や意識です。
マルチプラットフォーム戦略によって、インテグレーションやセキュリティー、ガバナンスの面で複雑さが増します。しかも、マルチ化そのものは、従来のシステム運用・保守と同様に、ビジネスの売上に直接は貢献しません。
情シスは、多様な環境を効果的に監督する、ワンランク上の新しいスキルを身につける必要があります。マルチ化によって実現できる、市場投入までの時間の短縮というビジネスのアジリティーを支える立場から、開発と一体化したDevOps的な活動も期待されます。収益とコスト削減に対する直接・間接的な貢献を、組織で正しく評価されるプレゼンスを示すことも重要でしょう。
マルチプラットフォームで協働するデジタルレイバー
マルチプラットフォームを成功させるには、この他にもさまざまな人材が必要ですが、特にもう「一人」デジタルレイバーという存在が不可欠です。これは、AIやRPA、そしてローコードによって自動化された仮想労働者のこと。人間を助けてくれる、デジタルの同僚です。
優秀な仮想労働者の助けを借りることで、ローコード→ローコードへの変換が実現できます。むしろ、今後さらに複雑さを増すシステムで、手間や時間、難易度、安全性を総合的に考えると、人力だけで対処することは非現実的。開発だけがローコード化されるだけでなく、移行や管理が複雑になりがちなマルチプラットフォームの自動化・効率化にもローコードが使われます。
データ入力や変更などのアクションをトリガーとして、一つのシステムがそれを分析・判断し、APIで連携された次のシステムへと引き継ぎます。24時間365日稼働し、ミスや癇癪も起こさない。高度に複雑化し、アジャイルなアップデートが必要なシステム運用は、デジタルレイバーという存在なくしては実現できません。
人間がすべきことは、パラメーターの調整や出力結果の判断、ステークホルダーへの説明責任です。つまり、デジタルレイバーが優秀に活躍すればするほど、人間としての役割が問われます。
多様性や連携が求められるチームのヒント
多数のプラットフォーム同士が連携できるとはいえ、すべてを使いこなすには専門的・横断的なスキルがあることが理想です。しかし、そんなスーパーエンジニアはなかなか見つからず、いたとしても超高単価なはず。また、属人化し過ぎることもリスクになります。
マルチローコード・ノーコード時代には、プロのエンジニアと非エンジニアの両方を含む、多様な人材でチームを構成することが、さらに重要になります。
技術的ギャップの相互補完
プロのエンジニアには、テクニカルな深い知識、システム設計のスキル、そして必要に応じて複雑なインテグレーションやカスタムコードを処理できる能力が求められます。プラットフォームの潜在的な限界を理解し、技術的ノウハウやベストプラクティスをチームに提供します。
一方、非エンジニア（シチズンデベロッパー）は、各自の専門領域とビジネスプロセスの知識を備え、アイデアを高速にプロトタイプ化し、反復・改善していくことが必要とされます。エンジニアがビジネス要件やユーザーニーズをよりよく理解できるように、具体的なフィードバックで貢献します。
プラットフォームごとの専門化と多様性
チームメンバーによって、異なるプラットフォームの強みを活かせます。例えば、高度なエンタープライズアプリはOutSystems、オートメーションはWorkato、テストはmabl、CRM関連の開発はCreatioなど、それぞれに特化することで、各プラットフォームのメリットを最大限に引き出せます。
ただし、クローズドになるとサイロ化・属人化するので、エコシステム全体にわたる透明性と、スムーズなデータフロー、機能性を確保するバランスが重要です。
▼OutSystems | 株式会社BlueMeme
https://www.bluememe.jp/outsystems/index.html
オープンなコミュニケーション
エンジニアと非エンジニアメンバーのコラボレーションには、チーム全体のコミュニケーションが不可欠です。IT企業の多くが、コロナ禍以降に出社へと回帰するハイブリッドなワークスタイルを選択したことも、これを示しています。
また、両者のどちらにもトレーニングとスキルアップが必要で、変化し続ける環境を効果的に学習できる、包括的なトレーニングプログラムが組織に求められます。
この他、組織全体のガバナンスや企業文化の醸成などについては、次回の記事に譲ります。
開発環境だけでなく人材と関係もマルチに
つまり、プラットフォームのAPI連携だけでなく、チームの人材構成も柔軟にコネクトするようなもの。複数の環境を連携させて効率化・省力化を目指すと同時に、人間の側もマルチなコミュニケーションが不可欠です。
それぞれの人材が所属する部署の責任や役割分担、権限の違いはありつつ、部門横断型のチームワークが重視されます。各自の多様なスキルを最大限に活かすには、バランスの取れたチーム作りが鍵です。
次世代のエンジニアたちによって構成される優れたチーム体制があれば、混沌とした状況で複雑に変化するビジネスニーズにも、フレキシブルに対応できます。
さて、この連載も終盤ですが、2024年12月も後半になりました。ということは、あの「2025年の崖」が現実にやってくるわけです。来たるべき新しい年は、実は昭和でカウントすると100年！では、マルチプラットフォーム戦略のために、具体的に何をすべきでしょうか？
ABOUT ME
企画制作や広告クリエイティブ畑をずっと彷徨ってきました。狙って作るという点ではライティングもデザインの一つだし、オンラインはリアルの別レイヤーで、効率化は愛すべき無駄を作り出すため。各種ジェネレーティブAIと戯れる日々です。
kotobatoの記事一覧
kotobatoの記事一覧
