Power Apps対kintone

比較で迷う現場

中小企業のDX担当者が必ず通る道が、ローコードツール選びである。なかでもPower Appsとkintoneは、どちらも「現場が自分でアプリを作れる」と評判で、調べるほど甲乙つけがたく感じる。営業に聞けば「うちが一番」と言われ、社内では「結局どっちなのか」と問われる。情報は多いのに決め手がない。本記事では費用・機能・学習コスト・拡張性の4軸で両者を整理し、迷わず選ぶ基準を示す。

比較の4軸

比べるときは、軸を決めると霧が晴れる。本記事の4軸は、費用・機能・学習コスト・拡張性だ。まず費用から見ていく。Power AppsはPremiumプランが1ユーザー月20ドル前後で、最低契約人数の縛りがなく、作れるアプリ数も無制限である。一方kintoneは、スタンダードコースが1ユーザー月1,800円、最低10ユーザーからの契約となり、最低でも月1万8千円から始まる。少人数なら割高に見えるが、サポートや国産ならではの安心感が価格に含まれていると考えると、印象は変わってくる。

機能と学習コスト

ここで視点を変える。費用の次に効いてくるのが、機能と学習コストの関係だ。kintoneは、ドラッグ&ドロップで項目を並べるだけでアプリが完成し、ITに不慣れな現場担当者でもその日から使い始められる。立ち上がりの速さは大きな魅力である。対してPower Appsは、Excelに近い関数や画面設計の考え方を覚える必要があり、最初の学習コストはやや高めだ。しかしMicrosoft 365をすでに使っている企業なら、TeamsやSharePoint、Outlookとそのまま連携でき、覚えた先にできることの幅が一気に広がる。手軽さを取るか、伸びしろを取るか。ここが、両者を分ける最初の大きな分岐点になる。

拡張性が決め手

最後の軸、拡張性が、実は選定の決め手になる。kintoneは外部サービス連携やプラグインが豊富で、追加開発なしでも業務に合わせて育てやすいのが強みだ。Power Appsは、Power AutomateやAI機能、Dataverseと組み合わせることで、基幹システムとつながる本格的な仕組みまで一気通貫で作れる。ここまで来ると見えてくるのは、「どちらが優れているか」ではなく「自社の起点はどこか」という問いである。すでにMicrosoft 365が社内に根づいているならPower Apps、まずは小さく現場主導で始めたいならkintone。この軸で考えると、4つの比較が一本の線でつながり、迷いが消えていく。

まとめ

Power Appsとkintoneは、費用・機能・学習コスト・拡張性の4軸で性格が分かれる。手軽さと現場主導ならkintone、Microsoft 365を活かした拡張ならPower Appsだ。大切なのは、自社の起点から逆算して選ぶことである。

関連記事

要件定義のアプローチ

要件定義の基本

すべてをシステムで解決してしまおうとする要件定義には注意が必要である。システムの成功の可否は要件定義にかかっていると言っても過言ではない。しかし、十分に要件定義の時間を使ったにも関わらず、ITプロジェクトが失敗することがある。

規模別の要件定義

システム構築の規模によって、要件定義の粒度が変わる。小さなITプロジェクトの場合は要件定義をせずにプロトタイプを作りながらシステム構築を進めるといった方法がある。これをアジャイル開発、プロトタイプ開発と呼ぶ。

要件定義の本質

要件定義の粒度は時間を掛ければ細かくなるわけではない。ユーザー側でも要件定義を進めるにつれて、想定している機能の矛盾点が出てくることがある。この矛盾点を解消していくこと自体を要件定義としてはならない。要件定義はあくまで本質的なコアとなる部分から膨らませることが重要である。

対話型要件定義

要件定義フェーズで失敗するパターンは、ユーザー側との対話ではなく、システム会社側がヒアリングに徹する場合である。ユーザー側はITを利用してどのようなことができるかを知らない可能性が高いため、システム専門家がそれを鵜呑みにした仕様で要件を固めてしまうと、製造工程で無駄な工数が発生し予算をオーバーしてしまうことがある。

まとめ

本質的な要件をコミュニケーションによって、はっきりさせていく作業こそが要件定義と言えるのである。さまざまな視点から何度も繰り返し要件をなぞることで粒度が落ちていき、適切な要件定義書となる。何でもかんでもシステム化せず、オペレーションとの関係性を見合わせながら進めることが望ましい。

続きを見る >

システム開発の混迷

営業依存の弊害

業務システムがうまくいかないのはベンダーやSEの問題だけではない。SEを取り巻く環境もシステム開発には重要である。業務システム開発を依頼するベンダーであれば営業担当者が挟まる。日本の縦割り社会の中で営業担当者は非エンジニアである場合が多く、プロジェクトの成功が目的ではない場合がある。

役割の細分化

SEをプロジェクトマネージャーとしている場合も注意が必要である。日本ではシステムエンジニアは細分化されておらず、建築でいうと参加者の全員が職人という扱いであることが多い。システムに関わる人全員がSEとしてしまっている間違いである。

開発の本質

SEやベンダーのプロジェクトマネージャーはそれ自体がプロジェクトと考えていることも多く、ビジネスとしてのプロジェクトとして捉えることができていないことがある。本来はビジネスが中心にあって、その中に業務システムが位置するはずである。それが見えているか否かで、業務システム開発の成功の確率は変わるのである。

相互理解

逆に、システムのことはSEに任せているというような場合も注意が必要である。システムのプロジェクトを経験したことがある、というだけでは、システムに関連するプロジェクトを成功させるのは困難である可能性が高い。プログラミングの経験がなければ、SEやベンダーが持つ心境を察することができないからである。最も重要なことはシステム導入時のイメージである。

まとめ

欧米では当たり前のように、間接的に関与する売上や利益の向上を管掌する部門や役職があるが、日本では良くも悪くもロジカルであり、数字がなければ行動に移せない厳密なルールがある。

続きを見る >

マクロからPower Appsへ

ゾンビファイル

今から十数年前に作られたExcelやAccessでのマクロプログラムが今もなお残り続けている。表計算ソフトと呼ばれるデータベースに似たツールを背景にユーザーインターフェースやロジックを付け足したものである。もはやゾンビファイルと言っても過言ではない。これらのシステムは当初の目的を果たしていても、時代の変化とともに保守性や拡張性に大きな課題を抱えるようになっている。

作成者不明問題

社内に残る通称「マクロ」は、今はいない人が作成していたり、一部の人が独自に作ったものであることが多くある。作った人がいる場合はまだしも、退職している場合はその中のプログラムも見ることができないので、いつ止まるか分からないシステムを業務の中心で使い続けていくことになる。このような状況では、エラーが発生した際の対処法が不明で、業務継続に深刻なリスクをもたらす可能性がある。

市民開発解決法

ブラックボックス化したマクロを情報システム部に解決をお願いするのではなく、市民開発にて解決するには多少のコツが必要になる。ポイントは完全にブラックボックス化している状態や、何から手を付けていいか分からない状態のマクロ群は、残念ながらまずは専門家に情報の整理を依頼することが必要になるだろう。自社だけでの解決を試みる前に、適切な専門知識を持つパートナーとの連携を検討することが成功への近道となる。

専門家活用法

専門家に依頼したほうがいい理由として、マクロファイルの解析だけを切り離した作業としてしまうと、その後の市民開発へ繋ぎにくくなるからである。マクロファイルのインプット/アウトプットを解析した上で、それをどのように今後の市民開発のベース作りに活かすのか。ITコンサルやシステム開発会社の腕の見せどころである。単純な解析作業ではなく、将来的な発展性を見据えた戦略的なアプローチが求められる領域といえるだろう。

まとめ

ExcelやAccessはMicrosoft社の製品であるので、そのままMicrosoft社が提供するPower PlatformやPower Appsへの移行がスマートである。間違ってもマクロをスクラッチ開発でのWebシステムに移管すべきではない。親和性の問題や閲覧性などに課題がのこることが多いようである。

続きを見る >