DXのソリューションとしてローコードが注目される背景
最近何かにつけてDXというキーワードを耳にします。一昔前、クラウドというキーワードが流行った時を思い出しますが、その具体的なイメージが曖昧なままで言葉だけが独り歩きしている感じがします。Wikipedia では、「企業がテクノロジー（IT）を利用して事業の業績や対象範囲を根底から変化させる」と定義されています。
これはITの位置づけにおけるパラダイムシフトを意味します。
これまでのITは「ビジネスの支援ツール」という位置づけでした。
実際企業の中でIT部門はビジネス推進部門の支援部隊であり、コストセンターという位置づけであることが一般的でした。
DXによりITは企業のコアコンピタンスの軸へと変化しています。
高度なIT技術はそれ自体を動力源としてビジネスをドライブしていき利益の源泉へと昇華していきました。
このような状況は一部の企業においてはDXという言葉が出てくる10年以上前、具体的には2000年初頭にはすでに実践されていますが、これは明確な方針があってそうしていた企業もあれば、当初は業務支援のためのITが自然発生的にその企業のコアコンピタンスに昇華していった企業もあります。
このようにITによってアジリティを高めることこそがビジネスの価値を高め、利益を生み出す源泉となる流れの中で、プロ開発者でなくとも MVP（Minimum Viable Product）を素早くデリバリー可能で、フィードバックを受け改善版を素早くリリース可能で、アプリのデリバリーのスピードと生み出す価値にフォーカスできるツールの必要性が高まってきました。
そのソリューションとしてDXではローコードプラットフォーム（以下、LCP）が注目されています。
アジリティと継続的な価値提供を維持するためにはアプリのユーザーである業務部門のメンバー自身が「アプリの開発はビジネスの創造そのものであり、自分たちこそがアプリ開発チームの中心である」というスタンスで、業務自体に継続定期なアプリの開発と改善を推進することがポイントとなります。
ローコードプラットフォームにおけるPower Platformの強み
次に、LCPは数多くありますが、Power Platform の強みを見ていきましょう。Power Platform の強みは何といっても Microsoft 365 や Azure と連携できることです。
ここには2つの大きなメリットがあります。
１つ目はセキュリティ面のメリットです Power Platform、Microsoft 365、Azure など Microsoft のサービス間の相互の通信は Microsoft のバックボーンネットワーク内の通信となり、決してパブリックインターネットを経由しません。
参考情報：マイクロソフトのグローバル ネットワーク – 最高のクラウド ネットワークの実現
https://learn.microsoft.com/ja-jp/azure/networking/microsoft-global-network#get-the-premium-cloud-network
出典：（マイクロソフト株式会社）
既存システムとの連携がある場合も、既存システムをクラウドリフトすることで、アプリ内の各種通信を Microsoft のバックボーンネットワーク内に閉じさせることができます。
これにより様々な企業が提供するサービスを組み合わせるシナリオよりもセキュリティの考慮事項を減らすことができるためサービス提供のハードルが低くなります。
2つ目は Microsoft 365、Azure との連携です。LCPを使うならデリバリースピードと価値提供を最大化しつつも可能な限り開発工数は削減したいものです。自社独自のUXやビジネスフローのみを Power Platform で開発し、それに付随するコンテンツの共有やユーザーとのコミュニケーションなどの汎用的な機能は SharePoint Online や Teams などのサービスと連携することで工数の大幅削減が可能です。SharePointやTeamsはすでに導入企業も多く慣れ親しんだユーザーが多いためあらたに導入におけるハードルも低くなります。
また、Power Platform では作り切れない複雑な機能や負荷の高い機能がある場合でも、バックエンドでAzure Function や Azure Batch はじめとする様々なAzure のサービスを利用することでどのような機能でも実現できます。
Power Platform導入の際の注意点
1つ目として、これは他のLCPでも同じですが、現状完全にプロ開発者を排除してPower Platformでアプリを構築することは不可能です。
業務ロジックについては努力次第でプロ開発者なしでも構築可能ですが、Power Platform、Microsoft 365、Azure を連携させる基盤の構築に関しては、ネットワーク、クラウド、アプリのコーディングといった複数領域を横断した高度なスキルが必要とされるためプロ開発者が必須であり、その要求レベルも従来のアプリよりさらに高度なレベルが要求されます。
実際 Power Platform、Microsoft 365、Azure単体での高スキル人材はそれになりに存在しますが、横断的に連携させる基盤とアプリ両面を統合的に扱える高スキル人材はまだ絶対数が少ないため確保に苦労することでしょう。
2つ目として、コストの見通しの問題があります。繰り返しになりますが、大前提として Power Platform を含むLCPはコスト削減に着目するものではなく、アジリティとビジネスの価値を高めることに着目することが重要です。
LCP導入におけるコスト増大の要因として、ハイスキル人材の確保や業務部門メンバーへの教育などの投資があげられます。
そしてコストに関する最大の課題として、Power Platform、Microsoft 365、Azure 基盤は定期的に更新されていくので継続的な情報のウォッチと基盤およびアプリ更新が必須となります（これは他のLCPでも同じです）。
これまでアプリのように1回作ったら放置するというようないわゆる「塩漬け」にすることはできないため注意が必要です。
また、基盤の更新タイミングは事前予測が難しく、マイクロソフト側のタイミングに依存した継続的なアプリの改善や基盤の更新に対応するコストの確保が必要となります。
これに対して、日本で一般的な数年分の運用コストを事前に稟議を通して確保するやり方を適用しようとすると稟議を申請する側に重い負担がかかります。
この負担は基盤全体を横断的に俯瞰できるハイスキル人材に集中してしまう傾向がありますが、ハイスキル人材は引く手あまたのため、このような稟議のための稼働による負担をばかばかしく感じてしまい、あっという間に転職していってしまいます。
なお、ベンチャー企業ではこのような稟議に関する負担は少ないため、ベンチャー企業に転職するパターンが多くみられます。
よってDXを推進する場合には、導入を決めた時点で断固たる覚悟でシステム導入のための決裁プロセスを見直す必要があります。
特に「前例がないから」「ルールだから」という考え方を押し付けると技術者の離職につながりやすいので、あくまでも、個別のケースにおいて具体的な事実をもとに理論的に判断していくプロセスを構築することが重要です。
3つ目として、Power Platform を含むクラウドサービスはこれまでの「境界型防御」と相性が良くないため、各企業に最適なクラウドサービスに対応した新たなセキュリティポリシーの策定や実際の設定値を煮詰める必要があります。
そして、ほとんどの場合これまでのルールがなじまず、何らかのルール変更が必要になります。この作業も高度なエンジニアの知見が必要となります。
この承認を得るプロセスも2つ目同様ハイスキル人材に負担をかけるケースが多いので、2つ目の注意点と同様に個別のケースにおいて具体的な事実をもとに理論的に判断していくことが重要です。
おわりに
最後に補足しますが、すべてをPower Platform のようなLCPにする必要はありません、特定の業務支援にフォーカスした閉じたアプリであれば、従来のアプリ開発の方がメリットを享受できます。
環境的に閉じているためセキュリティもコントロールしやすく、塩漬けも可能でコストの見通しも容易です。
あくまでもそれぞれのケースにおいて個別具体的に検討し、アプリの基盤を選択することが重要です。
次回は、どのようなケースでPower Platformが有効であり、どのようなケースで従来のアプリ開発を適用すべきなのか、その見極めポイントについてご説明いたします。
※記載されている会社名、商品名、またはサービス名は、各社の登録商標または商標です。