More than 1 year has passed since last update.

Power Platform におけるフュージョン開発

Last updated at 2022-07-09Posted at 2022-06-22

みなさま、こんにちは！
日本マイクロソフトのカスタマーサクセスマネージャーの岩田です。
今回は、前回の投稿 Power Platform ローコード開発を促進するための、揃えるべき7つのピースで書かせていただいた7つのピースから、フュージョン開発に関して掘り下げていきたいと思います。
前半では、Power Platform におけるフュージョン開発の説明、後半では架空の企業のユースケースを元に、フュージョン開発のハンズオンを実践します。

前半：フュージョン開発の説明

テックインテンシティ

フュージョン開発の説明に入る前に、その上位の考え方であるテックインテンシティに関して説明します。
企業のテックインテンシティには3つの側面があります。
① テクノロジーの積極的な採用
② テクノロジーを利活用する個人の能力向上
③ テクノロジー利活用に対しての組織の信頼
上の「テクノロジー」という言葉を「Power Platform」に置き換えてみてください。それがPower Platform におけるテックインテンシティです。

テックインテンシティの目的は、組織のサイロを解体し、チームの生産性を向上させることです。
テックインテンシティの実践には「業務上の問題を解決するために、組織全体から集まった人たち」の力が必要で、これから説明する「フュージョンチーム」につながっていきます。

フュージョンとは

Googleで「フュージョン」を翻訳すると「融合」と表示されました。
フュージョンと聞いて、皆様は何を思い浮かべますか？
私は音楽のジャンルを思い浮かべました。フュージョンとは、Jazzをベースに、ラテン音楽、ロック、テクノ、クラシックなどの要素をミックスさせたジャンルの音楽です。
ドラゴンボール世代であれば、孫悟天とトランクスの技を思い浮かべた方もいるかもしれません。
孫悟天とトランクスが「フュージョン」という掛け声とともに融合し、強力な力を得る"あの技"です。
Power Platform に置き換えると、様々なプロフェッショナルの知見の融合で、強力なソリューションを作ることができることを意味します。

Power Platformにおけるフュージョン開発の必要性

前回の投稿で、企業におけるPower Platformによるローコード開発には、以下3者の役割分担が存在するとお伝えしました。
① 市民開発者：業務の知識を活用し、Power Platform を使用してアプリケーションを作成する業務部門の人
② プロ開発者：高度なプログラミング技術を要し、アプリケーションを開発する人
③ IT管理者：IT部門。運用・保守・セキュリティやガバナンスに目を配る人

ビジネス要件を理解している市民開発者は、Power Platformを習得することで、最小限のコーディングで迅速にアプリケーションを組み立てることができます。
一方、Power Platform 単体では満たされない、より複雑な状況が常に存在します。
例えば、Power Platform 側に接続コネクタが用意されていない既存システムとの連携や、データの一貫性を維持するために追加のビジネスロジックを構築する必要なケースなどです。
このような問題に対処するには、フュージョン開発チームとして3者が協業し、解決策を生み出す必要があります。

フュージョン開発ライフサイクル

フュージョン開発により、業務上の問題をすばやく適切に解決するアプリケーションを作成できます。
以下の図は、Power Platform におけるフュージョン開発のライフサイクルです。
ポイントは、下図の一番下の「Power Apps with Custom Functionality」です。

市民開発者がPower Platform でアプリケーションのプロトタイプを作成した後、プロ開発者は、外部システムと連携するカスタムコネクタ（Web API等）をIT管理者の協力を得て作成し、市民開発者に提供します。
市民開発者は、プロ開発者から提供されたカスタムコネクタ利用することで、Power Apps から外部システムのデータを参照・更新するなどの処理を加えることができます。
開発したアプリはすぐに現場の利用者に試してもらい、フィードバックを受け、改良を加えていきます。

このライフサイクルを頻繁に回していくことで、"現場でちゃんと使われる"クオリティの高いアプリが作られます。

カスタムコネクタの作成

フュージョン開発における最も重要なポイントである、カスタムコネクタを説明します。
カスタムコネクタとは、Power Platform のアプリケーションが、外部システムにアクセスするためのカスタムメイドのコネクタです。
カスタムコネクタ作成と利用の一連の流れは、以下の通りです。
① 外部システムと接続するWeb API を作成（プロ開発者）
② 作成した Web APIをAzure API Management に登録し、カスタムコネクタとして該当組織のPower Apps環境に公開（IT管理者）
③ 公開されたカスタムAPIをPower Platform アプリケーションに組み込む（市民開発者）

下図は、カスタムコネクタを取り巻く構成要素のスライドで、Power Appsアプリケーション、Azure API Management、Web API、外部システムの位置づけを示しています。

左側が市民開発者が作成したPower Platform のアプリです。右側の地球儀のようなマークが、プロ開発者がC#やPythonなどを利用して作成したWeb APIです。
真ん中のAzure API Management（Gateway）の作成は、組織のAPIを管理する機能なので、通常、IT管理者が作成します。 API Management は、プロ開発者が開発したWeb APIを安全に組織で利用してもらうためのセキュリティ層を提供し、どのクライアントがどの操作にアクセスできるかを詳細に監視および制御する機能を持っています。

後半：フュージョン開発のハンズオン

フュージョン開発ハンズオン（VanArsdel社のストーリー）

ここからは、実際、皆様の会社でフュージョンチームを組み、サンプルシナリオに沿ってフュージョン開発を実践してみましょう。
サンプルシナリオは、Ebook: Fusion development approach to building apps using Power Appsです。

※PDF版はこちら
まずは、このサンプルシナリオを読み解いて、架空の企業であるVanArsdel社の背景と課題、フュージョンチームのメンバー、作成するアプリケーションを要約してお伝えします。

VanArsdel社の背景と課題

VanArsdel（ベナースデル）は、空調の設置と修理において世界をリードする企業です。
事業の中核は、フィールド作業員を顧客に派遣し、あらゆるブランドの暖房/冷却装置の設置と修理を行うことです。
この1年で事業は飛躍的に成長する一方、重要なビジネスアプリケーションの拡張に問題が生じています。
VanArsdel のソフトウェア開発チームは手が回らなくなっており、積み重なったバックログをできる限り迅速に処理するだけで手一杯です。一方、業務部門は、書類作業の多い手動の業務プロセスに依存しており、それによって会社全体に過度の非効率性が生じています。

フュージョンチームのメンバー

「業務上の問題を解決するために、組織全体から集まった人たち」が「フュージョンチーム」です。

Maria（マリア）：市民開発者
在庫管理の担当者。倉庫に十分な部品があることを確認し、なければ、Kiana が作成した既存システムを使用して注文を行います。
実は、空き時間にPower Apps の勉強をしており、その有用性を認識しています。
今回のシナリオで業務が分かる市民開発者の位置づけで、Power Appsでアプリを作成します。

Kiana（キアナ）：プロ開発者
C# と .NET が専門のソフトウェアアーキテクトです。 Kiana は VanArsdel のアプリケーションの多くを作成、設計してきましたが、新しいリクエストが多いために手が回らなくなっています。 Kiana には Power Apps について大まかな知識があり、社内の市民開発者をサポートする方法を学びたいと考えています。

Preeti（プリティ）：IT管理者
ITシステムが正常に稼働している状態を維持する役割を担っています。セキュリティの懸念から「新しいアプリは簡単に制御、管理できるものにしなければならない」という立場です。

Caleb（ケルブ）：アプリ利用者
VanArsdel社の主任フィールド作業員で、非常に知識が豊富で、経験の浅い技術者のメンタリングをしています。
彼の時間は非常に貴重で、VanArsdel社は、彼が毎日できるだけ多くの高価値顧客を訪問するようにしたいと考えています。
今回のフュージョン開発チームでは、アプリの利用者として、使い勝手のフィードバックを行う立場です。

フュージョン開発のテーマ：フィールド在庫管理システム

フィールド作業員Calebのある一日

顧客先で修理サービスを実行する際、Caleb は、必要な部品が自分のトラックに積まれていないことに気が付きます。
彼は近くにいる別の技術者に電話して、彼らが持っている部品を使えるかどうか確認することもあります。そうすることができない場合、彼は中央倉庫に戻って、部品を持ち出したことを示す書類に記入する必要があります。
部品が倉庫にない場合、Caleb は部品を注文するための別の書類に記入する必要があります。

課題

Caleb のチームは中央倉庫から部品をピックアップし、すぐに顧客の現場に戻って修理を完了する必要があるため、倉庫から部品を持ち出したことを記入するのを忘れてしまい、在庫数が合わなくなります。そのため、Maria のチームは、手動で在庫を監査する必要があります。
また Maria は、部品が注文され在庫が最新の状態になるように、部品を注文する書類を 1 日に何度も確認する必要があります。
Maria は、Kiana が開発した既存のウェブアプリケーションを使用して、VanArsdel の内部倉庫の在庫を最新に保ち、必要な部品を仕入先に注文しています。Kiana は、このアプリケーションの修正の必要性を感じていましたが、優先度の高い他の案件を処理するため後回しになっていました。（従って、今回のフュージョン開発のテーマとして、このフィールド在庫管理システムが取り上げられることになりました）

作成するアプリの全体像とフュージョンチームの各担当箇所

下図が作成するアプリの全体像になります。
皆様の会社でこのハンズオンを実践するにあたり、Maria（市民開発者）、Kiana（プロ開発者）、Preeti（IT管理者）を決めてください。

ハンズオンの実践

フュージョンチームが決まりましたら、あとは、E-Bookのガイドに従って、ハンズオンを実践してください。
Ebook: Fusion development approach to building apps using Power Apps

といっても、これだけでは、大海原へ放り出されたような感じになると思います。
私も実践してみましたが、特にKianaのパートはC#を理解していないと、非常に難しい内容です。また、手順書としても誤植が多いため、実践している内容を理解しながら進めれば誤植に気が付きますが、単純にコピペで進めるとつまづきます。
誤植を直している時間はないため、私の方で完成形のコード（Power AppsのアプリとC#のコード）を、以下GitHub上にアップしておきます。
もしつまずいた場合、こちらのコードを参照してください。
Nagaaki Iwata fusion-dev-ebook 完成版
特に、Kiana担当のWeb API作成の手順は、.NET5.0ベースで記載されているため、最新の.NET6.0ベースで作成し直しました。
※.NET6.0ではコードジェネレートした際Startup.csファイルが作成されませんが（必要なくなっているため）、Statup.cs自体は.NET6.0でもサポートされているため、Startup.csありきのコードをアップしています。

事前準備

Power Appsアプリが参照する既存在庫システムのデータベースで、下図の赤枠部分です。ハンズオンでは、Azure SQL上にデータベースを作成します。

手順はこちらです。
私は東日本リージョンに作成しました。

Maria（市民開発者）のポイント

Mariaは、Power Appsで、まずは画面回りのプロトタイプを作成するため、接続するデータベースは事前準備で設定したAzure SQL（既存システムのDBという想定）ではなく、Excelです。
手順はこちら
接続用のExcelはこちら

最終的にはカスタムコネクタを利用して既存システム（Azure SQL）と接続します。
手順では、部品の注文処理は、Azure Logic Appsが利用されています。
ただ、Azure Logic Appsの必要性は薄いので、私が作成した完成バージョンでは、Power Appsを押した際に発動するトリガーを用いて、Power Automateで作成しています。

Kiana（プロ開発者）のポイント

Kianaの役割は、既存在庫システムと接続するWeb APIを作成することです。最終的には、Mariaが作成したPower Appsのアプリは、Kianaの作成したWeb APIを介して既存在庫システムとつながります。
手順はこちら
2022年5月時点では、Web APIをホストするAzure App Service側が、この手順で示している.NET5.0ベースのフレームワークをサポートしていなかったため、.NET6.0で作成しましたので参考にしてください。
.NET6.0 SDKのダウンロードはこちら
.NET6.0ベースで作成したWeb APIのコードはこちら

作成したコードをWeb APIとしてAzure App Serviceに公開すると、以下のようにブラウザからアクセスすると、事前準備で設定したAzure SQL（既存システムのDBという想定）のデータを、JSON形式で取得できるようになります。

Preeti（IT管理者）のポイント

Preetiの役割は、Kianaが作成した Web APIをAzure API Management に登録し、カスタムコネクタとして組織のPower Apps環境に公開することです。
手順はこちら
API Managementサービスを追加し、Kianaが作成したWeb APIの情報をもとに、OpenAPIの形式で登録します。

TestタブからAPIの動作確認ができます。
Sendボタンを押して正常に値が返されるか確認してください。

API Managementサービスの左メニューに「Power Platform」メニューがあります。

登録したAPIをPower Platformの環境で使えるように、カスタムコネクタとして公開します。

Maria（市民開発者）は、Power Appsでカスタムコネクタを利用できるようになります。