皆さまが Power Platform に出会ったのはいつ頃ですか？
私は2017年6月なので、Power と付き合って間もなく満6年になります。近づけたと思ったら急に遠くに行ってしまう、掴みどころのない奴です（？）
そんな魅力的な Power ちゃんですが、縁あってこれまでハンズオンも含めると延べ100名以上の方に Power Platform（主にキャンバスアプリ）の利用方法を教育（登壇発表を除く）させていただく機会をいただきました。ありがとうございます。教育業務大好物です（？）
ということで、今日はその拙い経験の中で感じたポイントについてまとめてみました。
1. 2種類の対象者
対象者は大きく分けると ①業務部門の方など開発未経験の方 ②何らかのプログラム開発経験者の方 の2種類いらっしゃったのですが、それぞれお伝えすべきポイントが異なるなーと感じていますので、それぞれ分けて所感を書いてみました。
1-1. 開発"未経験者"が押さえておくとよいポイント
①の開発未経験の方はアプリを作るというイメージ自体がついていない方が多かったため、ポイントを押さえるというよりは手取り足取りお伝えしていくことが多かったです。
が、一通り操作感を掴んでいただいた後に多くの方が陥っていたのが「データとは？」という壁でした。
例えばこういう勤務シフト表を作りたい！となった時に、データベースを設計できない方が多かった印象です。この見た目そのままデータベースにしちゃうんですよね。
Excel 上でこういうものを見る方が多かったせいなのか、この見た目そのままで日付情報を列として横持ちしちゃう方もいらっしゃいます。
（正解はいくつかあると思いますが、ひとつの解は「日付」「担当者」「シフトパターン」を列として定義し、ひたすらレコードとしてためる）
これはその方が悪いのではなく、データ設計の基本を知らなければそうなるのも当たり前な話で、開発未経験の方には「データとは？」を習得いただくことをお勧めしています。
これは「第N正規形の定義をそれぞれ述べよ！」みたいな小難しい話ではなくて、データを貯めたいというときにどういう列を定義すればよいのか？、正規化とは何か？くらいが理解できればある程度は作成できるかなと思っています。
ちなみに私が前々々職の時に社内向けに勉強会を開催した時はこの辺りをご紹介していました。もしこれからデータの基礎を学ばれる方がいらっしゃいましたら、ご参考になれば幸いです。
【新人教育 資料】SQLへの道 〜DB編〜
https://qiita.com/devopsCoordinator/items/9b70e506150888e190be
そもそもデータベースとは？基礎から分かるデータベース入門
https://proengineer.internous.co.jp/content/columnfeature/6411
まったくの初心者もこれでバッチリ 12のキーワードから学ぶデータベース基本中のキホン（前編）
https://codezine.jp/article/detail/3261
やめた方がいいテーブル設計 〜重複データのカラム持ち〜
https://b-kimagure.hatenablog.com/entry/2019/05/25/112530
正規化の要点を理解する
https://qiita.com/mochichoco/items/2904384b2856db2bf46c
DBを正規化するということ
https://qiita.com/yukihirasawa1206/items/c2dedcc51c01c1bd8ccc
1-2. 開発"経験者"が押さえておくとよいポイント
今日の本題はこちらです。
何らかのプログラム開発をご経験されてきた方の多くは、少なくとも私が担当させていただいた方は総じてデータベースの基礎をお持ちで、「こんなコントロールがありまして、こんな感じで書きましてー」と伝えるだけでサクサクとモノを作れちゃう方が多かったです。
ただ、私もそうだったのですが、上から下まで順番に処理を実行するようなプログラムに慣れていらっしゃる方や、何もないところから１つ１つ作り上げることに慣れていらっしゃる方、概要の情報だけである程度「これとこれを組み合わせればできちゃうんじゃね？」とピンとくる方こそ、気が付いたら随分違う方向に進んでいらっしゃっていた、ということがよくありました。
そんな経験から、ここを最初に押さえておくと方向ずれずに進めるかも？という３つのポイントを整理してみました。
リアクティブであること（正確には、リアクティブな部分が半分以上を占めること）
型を意識すること
標準機能を知り、それを利用すること
1-2-1. ポイント１
1つ目は、リアクティブの話です。
これは、ここで説明するよりも盟友やまさんの記事をご参照いただくのが一番かと思います。
が、やまさんの記事を強引に要約してみると…
プログラミング言語の多くは何かをきっかけに１つずつ命令を実行していくイメージが多いと思うのですが（言語あまり知らず、誤解を生む表現だったらすみません）、SharePoint リストから自動生成したキャンバスアプリの画面の1枚目って、検索処理を実行するための検索ボタンってないんですよね。
むしろ、検索結果を表示する側のギャラリーコントロールの方に検索処理が書いてあって、検索窓の値を参照しているんですよね。
Excel の Sum 関数を思い出していただくと分かりやすい気がするのですが、合計を計算するのって、どこかに計算ボタンがあるわけじゃなくて、計算結果を表示する側のセルに計算するための関数が書いてありますよね。
それと同じような動きをするんだと思っていただけるとよいかなと思います。
で、実際に開発経験者の方がよく間違えていらっしゃる代表例が、ボタンコントロールの OnSelect プロパティに「ラベルコントロール.Text = 計算結果」と記述することです。
たしかエラーも表示されなかったかなと思いますので、なんでラベルに値が入らないのか一見気付かないんですよね。もちろん私も最初同じことしました。
もちろん変数に値を代入するような時はいわゆるプログラミング的な発想で記述したりもするので紛らわしいこともあるのですが（笑）、上記のリアクティブの概念と、コントロールのプロパティに値を直接代入したりはできないというポイントを押さえておけば、すぐに回避できるポイントかなと思いました。
1-2-2. ポイント２
2つ目は、型の話です。
プログラミング経験者なら型なんて基本中の基本中の基本中の基本だろ！！と怒られそうなポイントなので、もうちょっとかみ砕いて書いてみます。
キャンバスアプリには、プログラミングの世界でもおなじみの数値型や文字列型などの考え方があり、これについては開発経験者の方は難なくご理解いただけます。
ただ、キャンバスアプリには上記以外の型の中でも特に押さえておくとよい「テーブル型」と「レコード型」という型が存在します。
もちろんプログラミング言語の中には配列やクラス、構造体など上記でいうテーブル型に似たような概念が存在しまし、具体的に「ギャラリーコントロールの Items プロパティにはテーブルを入れる」というところまではすんなりご理解いただけることが多いです。
ただ、別の種類のコントロールにある Items プロパティにもテーブルが設定できるよ、というところまですぐにご理解いただける方は少なかった印象です。
具体的な話として、以前開発経験者の方にキャンバスアプリをお教えしていた時のことです。
フォームコントロールの添付ファイルコントロールに SharePoint ドキュメントライブラリのファイル情報をN個表示したいが方法が分からないと相談いただいたことがありました。
この解は意外とシンプルで、添付ファイルコントロールって Items プロパティを持っているので、普通に SharePoint コネクタを使ってドキュメントライブラリを指定すれば表示できるんですよね。
型を意識すれば、もとい型だけを意識すれば意外とすんなりできちゃうことが多いので、どのプロパティがどの型なのか、あと「テーブル型」と「レコード型」の違いは何なのかを押さえておくと、世界が一気に広がる気がしています。
1-2-3. ポイント３
3つ目は、標準機能の話です。
開発をご経験されていると、キャンバスアプリの概要（コントロール、プロパティあたり）を理解するだけで、感覚である程度形にできる方が多いです。
もちろんそれで何の問題もないのですが、ちょっと複雑なコントロール（ギャラリーコントロール、フォームコントロールなど）を使うと標準でどのようなことができるのかを最初に把握しておくことで、より幸せな開発ができるのではと思ったことがありました。
以前、何かしらの入力フォーム画面を作りましょうとなった際に、それこそラベルやテキスト入力、ボタンなどの主要なコントロールを把握された方が、それらを使ってゼロからフォーム画面を作成されたことがありました。
入力フォームってゼロから自作してしまうと、各列のラベル表示やバリデーションチェック（入力エラー判定）、入力したすべての情報を各列に登録する処理も自作しなきゃいけないんですよね。
でも、編集フォームコントロールがあれば、列のラベル表示もバリデーションチェックも値の登録処理もコントロールの整列も、勝手にやってくれます。
もちろん編集フォームコントロールで実現できない要件がたまにあったりもしますが、闇雲に自作に走ってしまうとバグのリスクも増えますし、余計な単体テストが増える要因にもなります。
設計イメージがピンとくる優秀さゆえ標準機能の理解が後回しになりがちな傾向がある気がしますので、よく使うコントロール（そんな多くない）は初めのうちに押さえておくとよい気がします。
おまけ：さすが開発経験者の方だなぁと思ったポイント
何だか開発経験者の方を責めてしまっているような記事になってしまって申し訳ない感満載なので、逆に「さすが開発経験者の方だなぁー」と思ったポイントも書いておきます。
● なるべくグローバル変数（キャンバスアプリでいう Set 関数で定義した変数）の使用を控える
グローバル変数の多用はどのスクリーンで値がどう書き換えられてしまうかをトレースしにくくなりバグのリスクを高めてしまうため、むやみに使用しないことをお勧めするのですが、開発経験者の方は何も言わずとも使い分けていただけることが多いです。嬉しい。
● プロパティの処理にコメントを書く
ローコードであってもプロパティの関数の行数が多くなると処理の内容や理由が把握しづらくなるものですが、開発経験者の方は何も言わずともコメントを追記していただけることが多いです。嬉しい。
● エラーが発生しても自己解決する
エラーって怖いですよね。私もプログラミング学んで１年目の時は「先生ーなんか赤い文字が出てきたんですけどー」と質問して「エラー読め」と怒られたことをよく覚えていますので、開発初心者の方が戸惑ってしまうのは当然だと思います。でも開発経験者の方はエラー慣れしているのか（？）、速攻でググって解決されるあたり、さすがだなーと思います。素敵。
何だか生意気な記事になってしまってすみません。
ただ、これだけ Power Platform が普及してきた現在において、教える側の方も多様な相手に対してどのように教えるべきか、最低限押さえていただくべきポイントは何なのかを悩まれることが増えてきているのではと思い、自分なりの考えではありますがまとめてみました。
欲しいアプリは欲しい人が作る時代へ。
少しでもご参考になれば幸いです。
