Power Apps / Dataverse のカスタマイズはどこまでやるか — ラーメン二郎のコールに学ぶ、範囲を絞る設計

ラーメン二郎の話から始めます。

業務システムの会社が何の話だ、と思われるかもしれません。少しだけお付き合いください。最後にちゃんと、Dataverseの話になります。

ラーメン二郎のコールは、4つしかない

二郎で食券を買って席に着き、麺の茹で上がりが近づくと、店員から声がかかります。「ニンニク入れますか」。

あの一言が「コール」です。そしてここで客が指定できるものは、実質4つしかありません。

ニンニク
ヤサイ
アブラ
カラメ（味の濃さ）

しかも指定できるのは、増やすか、減らすか、抜くか。それだけです。麺の量を減らしたければ、コールの場ではなく食券を出すときに「麺少なめ」と事前に申告しておく必要があります。

裏を返すと、それ以外の要望は通りません。「豚をもう少し柔らかく煮てほしい」「スープを別のベースに変えてほしい」「麺を細くしてほしい」。どれも受け付けられません。メニュー自体もほぼ一種類で、選べるのはサイズと豚の量くらいです。

普通のサービス業の感覚で見れば、これは不便です。客の要望に応えていない、と言うこともできます。

私は逆だと思っています。この「4つしかない」ことが、二郎を二郎にしています。

理由は3つあります。

ひとつ、客が迷いません。初めての人でも、聞くべきことは「何を増やして、何を減らすか」だけです。選択肢が4つに絞られているから、その場で判断できます。

ふたつ、店が回ります。行列のできる店で、一人ひとりの細かい注文を聞いて個別に対応していたら、提供は止まります。可変域が決まっているからこそ、あの回転が成り立ちます。

みっつ、そしてこれがいちばん大きいのですが、どの店で食べても二郎になります。店ごとの違いはもちろんありますが、それは店の個性であって、客が注文でいじった結果ではありません。客側の可変域が絞られているから、「二郎とはこういうものだ」という像が壊れずに残ります。

可変域を絞ることが、同一性を守っている。ここが今日の話の芯です。

インスパイア系は「二郎ではない」。それは優劣の話ではない

二郎に影響を受けた店を、俗に「インスパイア系」と呼びます。

先に言っておきますが、インスパイア系はうまいです。私も通っている店があります。スープが洗練されていたり、豚の仕上げが別物だったり、コールできる項目がもっと多かったり、卓上の調味料が充実していたりする。二郎より好きだという人はたくさんいますし、その感想はまったく正当だと思います。

ただ、インスパイア系は二郎ではありません。

これは味の優劣の話ではありません。別の食べ物だ、というだけの話です。実際、多くのインスパイア系の店は自分たちを二郎だとは名乗っていません。それは誠実な態度だと思います。

では、どういうときに問題になるのか。

二郎のつもりで入った人に、インスパイアが出てきたときです。

「これじゃない」と感じるのは、うまいまずいの判断ではありません。頼んだものと出てきたものがズレている、という判断です。同じ丼が、二郎を期待していない人の前に出れば「うまい店を見つけた」になり、二郎を期待していた人の前に出れば「これじゃない」になる。丼は何も変わっていないのに、評価だけが裏返ります。

そしてこのズレは、たいてい後から気づきます。食べ始めて数口経ってからです。

業務システムのカスタマイズで起きるのも、まったく同じ種類のズレです。作っているものが悪いのではなく、頼んだつもりのものと、できあがったものが別物になっている。そして気づくのは、たいてい運用が始まってからです。

Dataverseのカスタマイズにも、コールの範囲がある

Dataverseとモデル駆動型アプリにも、コールに当たる範囲があります。設定だけで変えられる領域です。

テーブルと列の追加
フォームのレイアウト、タブ、セクションの構成
ビューの列構成、並び順、フィルタ条件
ビジネスルール（条件に応じた表示/非表示、必須の切り替え、既定値）
計算列・ロールアップ列
セキュリティロールによる権限設計
サイトマップ（アプリ内の導線）

一覧にすると地味ですが、この範囲でできることは意外に広いです。取引先企業と取引先担当者の関係をどう持たせるか、担当者列をどう設計するか、どのロールにどこまで見せるか。ここは全部「コールの範囲内」ですが、設計としては十分に難しく、腕の差が出ます。

この範囲に共通しているのは、Dataverseの上に乗ったまま変えているという点です。

だからここで変えたものには、次のことが自動的についてきます。

セキュリティロールが効きます。行レベル、列レベル、組織階層まで、権限の判定はプラットフォームがやります
監査ログに残ります。誰がいつ何を変えたかは、設定を有効にすれば記録されます
APIから同じように見えます。Power Automateからも、外部連携からも、同じデータとして扱えます
標準機能がそのまま使えます。高度な検索、Excelへのエクスポート、一括編集、ビューの共有
プラットフォームの更新が来ても、基本的にはそのまま動き続けます

これがコールの範囲です。増やす、減らす、抜く。範囲は決まっていますが、その中でできることは決して狭くありません。

範囲を超えた瞬間に、何を手放すのか

もちろん、範囲の外側に出る手段もあります。プラグイン、カスタムAPI、PCFコントロール、外部のWebアプリ。

誤解のないように言っておくと、これらは悪ではありません。私たちの製品もプラグインで作っています。標準の設定だけでは届かないものは、確かに存在します。日本の業務文書の採番ルール、方眼紙レイアウトの帳票、代理承認を含む稟議フロー。設定だけでは無理だったから、私たちはエンジンを作りました。

問題は、拡張の手段を持つことではありません。画面ごと外に出すことです。

「モデル駆動型アプリだと業務にはまらないので、別のアプリとして作り直しましょう」。この判断は、現場からも開発側からも、とても自然に出てきます。目の前の要件は確かにそれで解決するからです。

ただ、そこで何を手放すのかは、意識しておく価値があります。

セキュリティロールが効かなくなります。 自前で権限判定を書くことになります。Dataverseは行レベル・列レベル・階層・チーム共有まで面倒を見ています。それを手放して、同じものを自分で実装し、自分でテストし、自分で保守することになります。ここを甘く見た結果、「本来見えてはいけないデータが見えていた」という事故が起きます。

監査が別建てになります。 誰がいつ何を変えたかの記録を、自分で設計して自分で持ちます。標準で付いてくるものを、わざわざ作り直すことになります。

標準機能の恩恵から外れます。 高度な検索、Excelエクスポート、一括編集、ビューの切り替え。使えなくなるというより、「使えるように自分で作る」ことになります。地味な機能ほど、無くなってから効いてきます。

プラットフォームの更新が敵に回ります。 標準の枠内にいれば、更新は勝手に入ってきます。外に出た部分は、更新のたびに動作確認が必要な資産になります。

動作の重さの原因が見えにくくなります。 フォームやビューに手を入れすぎると重くなることはありますが、どこから重くなるかはテーブルの構成や列の持ち方で変わります。「何万件を超えたら遅くなる」といった閾値を私が書かないのは、それがテーブルごとに違うからです。標準の枠内なら、遅い理由は標準の仕組みの中で説明がつきます。外に出ると、自前のコードとプラットフォームのどちらが原因かの切り分けから始めることになります。

そして、いちばん後で効いてくるのがこれです。

人が採用できなくなります。 「Power Platformの経験者」を探すことはできます。求人にそう書けば、応募があります。「御社の独自アプリの経験者」は、この世に存在しません。作った人が辞めた瞬間、その仕組みは誰にも引き継げなくなります。

ここまでやってできあがるものは、もう「Dataverseで作った業務システム」ではありません。Dataverseをデータベースとして使っている、別のシステムです。

インスパイア系と同じで、それ自体は悪いことではありません。選んでそうしたのなら、正しい判断です。 標準の枠にどうしても収まらない業務は実際にありますし、そのときは外に出るべきです。私たちもそういう案件はお引き受けします。

まずいのは、Dataverseを選んだつもりのまま、気づいたらそうなっていた場合です。ライセンスはPower Platformの分を払い続けているのに、その恩恵は受け取っていない。そして「これじゃない」と気づくのは、たいてい運用が始まってからです。

二郎を頼んだつもりで、インスパイアが出てきている。丼は悪くないのに、評価だけが裏返る。あの構図とまったく同じです。

私たちが製品を「コール」として作っている理由

私たちは採番・帳票・承認の3つを製品として持っています。どれもプラグインなので、さきほどの分類で言えば「範囲の外側」の道具です。

ただ、作るときに決めていたことがあります。使う側から見たときには、コールの範囲に見えるようにする、ということです。

採番エンジンは、番号の書式を {prefix}-{fy}-{seq:3} のようなパターン文字列で定義します。年度でリセットするかどうかも、部署ごとに独立したカウンタを持つかどうかも、Dataverseのレコードとして設定します。導入した後にコードを書く場面はありません。

帳票エンジンは、Excelテンプレートにプレースホルダを書き込むだけです。レイアウトを直したい業務担当者が、情シスに依頼せず自分で直せます。テンプレートを触るのに開発環境は要りません。

承認エンジンは、代理承認のルールをテーブルで設定します。「来週から2週間、この人に委任」を、フローを組み直さずに書き換えられます。

いずれも、変えられる範囲をこちらで絞っています。 何でもできるようにはしていません。パターン文字列で表現できない採番は、採番エンジンではできません。そういう要件が来たら、別の作り方を提案します。

これは手を抜いているのではなく、そう決めています。可変域を広げるほど設定画面は複雑になり、設定ミスによる事故は増え、最終的に「結局これも情シスしか触れない」に逆戻りするからです。それでは何のために外出ししたのか分かりません。

ニンニクとヤサイとアブラとカラメの4つだけだから、初めての客でもコールできる。設定項目を絞っているのは、それと同じ理由です。

カスタマイズの線引きは、諦めではありません。どこまでを可変にするかを決めることが、設計そのものです。

足せば足すほど良くなるのなら、そもそも設計は要りません。実際にはそうではなく、足した分だけ何かを手放しています。手放してよかったのか、手放したことに気づいていなかったのか。後で効いてくるのは、その差だけです。

機能を足しているのに体験としては引き算になっている、という話はサウナしきじに学ぶ、「困る瞬間」のない業務システム設計にも書きました。今日の話はその線引きを、もう少し手前から見たものです。

どこまでを設定で変えられるようにして、どこから先は作らないと決めるか。ここで迷っている段階のご相談がいちばん役に立てるところなので、お気軽にどうぞ。現状の棚卸しから始めたい場合は、無料の診断でお手伝いしています。