要件定義の問題点

素人仕様と開発遅延

なぜ、システム開発の進捗が悪いのか？
それは、ずばり素人が考えた仕様を開発者に伝えてしまうからである。
すべての原因ではないが、もしシステムのユーザー側の現場担当者や営業担当者がシステム仕様を決めている場合は、ほとんどの場合で満足のいくスピード感はだせていない。

潜む技術的負債

システム仕様さえ伝えていれば、きちんと動くものを作ってくれるので、あとはスピードを上げるだけ。と考えているようであれば、技術的負債が溜まっていることに気付けていない。非エンジニアが決して理解できない技術的負債の怖さは、開発スピードが遅いということだけではない。開発者側から見てシステムが複雑になっていて、メンテナンス性も低い状態になっている。

「できます」の罠

非エンジニアには技術的負債は見えないし説明もわからないことと思う。しかし、技術力でカバーしてくれているから、きちんと動いているのだと思っているなら、それは実は技術力ではない。
「技術的にはできます」このような言葉を聞いたことはないか？
システムエンジニアは「できない」と言えない。「できないことはない」ということが価値なので、素人が考えたシステム仕様でも、言われた通りに作ってしまう。

持続可能な開発へ

システムエンジニアから「技術的にはできます」を聞いたときは、いったん立ち止まるべきである。
エンジニアには、様々な影響範囲や未来のメンテナンス性への懸念などが見えている。これを必要以上のコストだと考えるのか、必要コストと考えるのかで、技術的負債は変わる。

まとめ

自分の理解の範囲でしか人間は発想しないので、システムのことを知らない非エンジニアは、システム仕様を考えるべきではないと言える。また逆に、システムにおいてはシステムエンジニアの方が発想の幅は広いが、業務に関する知識は乏しい。
システムをよく知り業務のこともわかるシステムエンジニアがシステム仕様を考えるべきだが、そんな万能な人は多くはない。だから、その間を取り持つ人間が重要なのである。

DX推進の落とし穴

デジタルトランスフォーメーション（DX）に取り組む企業が増える一方で、期待した成果を得られずに頓挫するケースが後を絶たない。経済産業省の調査でも、DXに成功したと実感している企業はわずか数パーセントに留まっている。なぜ多くの企業がDXで失敗してしまうのか。本記事では、失敗する会社に共通する特徴を分析し、成功へ導くための視点を紹介する。

失敗企業の共通点

DXが失敗する会社には、いくつかの共通点がある。第一に「目的の不明確さ」である。ツール導入そのものが目的化し、何を解決したいのかが曖昧なまま進めてしまう。第二に「経営層の関与不足」が挙げられる。DXは全社的な変革であり、現場任せでは推進力が生まれない。第三に「現場との乖離」である。実際に業務を担う社員の声を聞かず、使われないシステムが構築されるケースが多発している。これらの問題は単独ではなく、複合的に絡み合って失敗を引き起こす。

成功企業の原則

では、成功している企業は何が違うのか。成功企業に共通するのは「ビジネス課題起点の発想」である。まず解決すべき経営課題を明確にし、その手段としてデジタル技術を選定する。また、経営者自身がDXの旗振り役となり、変革の必要性を全社に浸透させている。さらに重要なのが「スモールスタート」の姿勢である。最初から大規模なシステム刷新を狙うのではなく、小さな成功体験を積み重ねることで社内の理解と協力を得ていく。加えて、外部パートナーを活用して専門知識を補い、客観的な視点で推進状況を評価する仕組みを持っている。

成功は準備次第

DXの成否は、取り組む前の「準備」で大きく左右される。自社の現状を正しく把握し、何のためにDXを行うのかという目的を明文化することが第一歩である。その上で、経営層から現場まで一貫したビジョンを共有し、段階的に進める計画を立てるべきだ。失敗を恐れて動かないことが最大のリスクである。しかし、闇雲に進めても成果は出ない。重要なのは、正しい方向性を持って着実に歩みを進めることである。自社だけで判断が難しい場合は、DX推進の実績を持つ専門家の力を借りることも有効な選択肢となる。

まとめ

DXが失敗する会社には、目的の不明確さ、経営層の関与不足、現場との乖離という共通点がある。成功するためには、ビジネス課題を起点とした発想、経営者主導の推進体制、スモールスタートによる段階的な取り組みが不可欠である。正しい準備と専門家の支援を活用し、着実なDX推進を目指すべきだ。

比較で迷う現場

中小企業の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だ。大切なのは、自社の起点から逆算して選ぶことである。