ローコード開発の現実と私が意識していること

ローコード開発の現実と私が意識していること 作成者：Kohhey 2026/2/21

自己紹介 名前：Kohhey たまにPower Platformコミュニティで登壇してたりする人です。 保有資格：PL-200、AZ-900 X：https://x.com/koh_of_yama docswell：https://www.docswell.com/user/Kohhey 近況：明後日の乃木坂46のライブ当たったのでいってきます！

• https://x.com/koh_of_yama
• https://www.docswell.com/user/Kohhey

アジェンダ 1. はじめに 私がこの話をする理由 2. 起こりがちな問題 現場での失敗パターン 放置するとどうなるか――3つのリスク 3. 私が意識していること ガバナンスの整備 設計思想 4. まとめ

1 はじめに

私がこの話をする理由 -「誰でも作れる時代」が加速 今更ですが、Power Platform(ローコード)で非エンジニアでも業務アプリケーションが開発できる＋バイブコーディングでもソフ トウェア開発より楽に開発ができる時代になり、ソフトウェア開発がより民主化されているなと感じています。 こういった手段でエンジニアではない現場の方が自ら課題を解決できる、これは本当に素晴らしいことだと思っています。 -しかし、作ったら終わりというわけではない 個人的な意見ですが「作れる環境」と「安全に使える枠組み」の両方が揃っていないまま広げると、いずれ必ず問 題が起きます。 そして多くの場合、表面化したときにはすでに手遅れです。 今回は、私が問題が起きないよう意識していることをお話します。この内容が少しでもお役に立てれば幸いです。

2 起こりがちな問題

現場での失敗パターン ローコード推進の失敗は、技術的な問題ではなく推進プロセスの設計不良に起因するケースが多いと認識しています。具体的には、 以下の4段階で問題が顕在化します。 第1段階：導入効果の過大評価 「開発コストの削減」「短期間でのリリース」といったメリットだけが組織内で共有され、設計・運用・保守にかかるコストが議論 されないまま展開が進む。 第2段階：品質管理プロセスの不在 開発フェーズにおける設計レビュー、テスト工程、リリース承認といったソフトウェア開発本来のプロセスが省略される。「動けば リリース」が暗黙の基準となる。 第3段階：運用体制の未整備 リリース後の障害対応・改修・バージョン管理が、アプリ作成者個人に依存する構造になる。組織としての運用設計がなされていな い。 第4段階：技術的負債の蓄積と顕在化 作成者の異動・退職を契機にブラックボックス化が発生。「作り直した方が早い」という判断が繰り返され、負債がさらに積み上が る。

放置するとどうなるか――3つのリスク 「大げさでは？」と思われるかもしれません。では、実際に起きることをお伝えします。 ①担当者が変わるとシステムが止まる（属人化） 「ローコードはコードが少ない」のであって「ロジックが単純」とは限りません。作った人だけが分かる複雑なフロー、ドキュメン トなし。異動・退職の瞬間にブラックボックスになります。「作り直した方が早い」となり、また新たな負債が生まれる。この繰り 返しです。 ② 知らないうちにデータが漏れる（セキュリティリスク） 「外部のサービスと連携してみよう」と気軽に設定した結果、社内の顧客データが外部に送信されていた——これは決して珍しい話 ではありません。IT部門が把握していないアプリが存在すること自体が、すでにリスクです。 ③ 管理コストが膨らみ続ける（野良アプリ乱立） ルールなしで展開すると、組織内に「誰が作ったか分からないアプリ」が野放しで増殖します。重複・放置・矛盾するデータソース が入り乱れ、棚卸しと整理だけでかなりのコストを消費するケースも出てくるのではないでしょうか。

3 私が意識していること

組織・管理者向け：ガードレールを作る ここからは、私が失敗しないように意識していることをお話しします。 ガバナンスというと「制限される」と感じる方もいますが、本質は違います。 私はガバナンスとは「安全に走れる道を作ること」と捉えています。 たとえるなら、高速道路にガードレールがあるから、安心して速く走れる。それと同じ発想です。 具体的には4つの施策が有効です。 ① 環境を分ける（開発用・テスト用・本番用） 「個人の実験場」と「社内で使うもの」を明確に分離します。本番環境での直接編集は、万が一の際に即障害につな がります。 ② データの持ち出しルールを決める（DLPポリシー） どのサービスと連携してよいか、してはいけないかをルール化します。Power Platform では「ビジネス」「非ビジ ネス」「ブロック」の3分類でコネクタを管理できます。 ③ 利用状況を見える化する（CoE Starter Kit） 組織内に何のアプリが存在し、誰が使っているかを把握します。Microsoft が無料で提供している CoE Starter Kit が、 この可視化を助けてくれます。 ④ 引き継ぎルールを決める 異動・退職時にアプリの情報をどう渡すか、事前に決めておきます。これだけで属人化のリスクは大幅に下がります。

開発する方向け：私が意識している3つの設計思想 設計思想 ① KISS ――「シンプルに保て」 Keep It Simple, Stupid. 直訳すると「シンプルで愚鈍にする」です。 下の例で出したように、「せっかくだからいろんな機能をつけよう」という発想で取り組むと… やりがちなパターン 申請フォームを作るはずが、部署ごとに表示が変わる条件分岐、自動計算、承認ルートの複数パターン……気づけば自分でも何をしてい るか分からなくなる。 KISSの発想 「このアプリが解決する問題は、たった一つ何ですか？」から始める。余分な機能は、本当に必要になってから追加する。 シンプルなアプリは壊れにくく、直しやすく、引き継ぎやすい。 一言で覚えるなら 「作れるからといって、作りすぎない。」

開発する方向け：私が意識している3つの設計思想 設計思想 ② YAGNI ――「今必要なものだけ作れ」 You Aren‘t Gonna Need It. 「どうせ使わない（から、今は作るな）。」 KISSと似ていますが、こちらは「将来の可能性」に引っ張られないことに焦点を置いています。 やりがちなパターン 「将来、他部署でも使うかもしれないから、汎用的に作っておこう」→ 結果、誰のニーズにも合わない複雑なアプリになる。 「ゆくゆくはCSVだけでなく別の形式のエクスポート機能も」→ 結局使われない。 YAGNIの発想 今、目の前にいるユーザーが、困っていることを解決することだけを考える。 将来のことは、将来また考えればいい。Power Platformは開発速度が速い。それが強みです。 一言で覚えるなら 「"いつか使うかも"は、作らなくていい理由。」

開発する方向け：私が意識している3つの設計思想 設計思想 ③ DRY ――「同じことを二度書くな」 Don‘t Repeat Yourself. 「繰り返すな。」ということ。 これが3つの中で、最も即効性があります。 やりがちなパターン キャンバスアプリを作っていて、複数スクリーンで共通した処理をそれぞれのスクリーンに貼り付けて完成⇒リリース。 機能を修正する際、修正箇所が漏れていてデータの整合性が取れなくなる事態が発生。 DRYの発想 まとめられる処理はカプセル化して呼び出すような作りにする。 例えば、キャンバスアプリ内ならFormulasプロパティを活用する。クラウドフローなら子フローにして呼び出すなど手段がある。 一言で覚えるなら 「コピペよりも共通化」

4 まとめ

まとめ 「誰でも作れる」がゆえに、問題が起きる可能性は十分にある 問題の多くは“技術”ではなく“運用設計”にあるガバナンス不在、プロセス未整備にあると考えています。 安全に広げるには“仕組み”づくりが不可欠 ・環境分離、DLPポリシー、引き継ぎルールでリスクを抑える。 ・開発者は先人に倣った設計思想を持つことが得策 KISS（作りすぎない） YAGNI（今必要なものだけ） DRY（共通化して再利用） 今回ご紹介した仕組みを整えることで、再現性と持続性のある価値を創出できるのではないでしょうか。