ローコード開発≠安い

DX推進とAIツール活用

2025年現在、DX推進において生成AIツールの活用は避けて通れないテーマとなっている。調査によれば国内ソフトウェア開発におけるAIコード生成の利用率は49％に達し、資料作成においても従来の60％以上の時間短縮が報告されている。しかし現場では「どのツールを選べばよいかわからない」「導入したものの活用が進まない」という声も多い。本記事では、デザイン・ドキュメント作成・コーディング・業務自動化の4分野において、DX担当者が即活用できる実践的なツールを具体的に紹介する。

デザイン・資料作成の効率化

デザイン・UI/UX分野では「Figma AI」と「Canva AI」が二大勢力として君臨している。Figma AIはプロトタイプ生成やレイヤー名の自動整理が可能で、Config2025で発表された「Figma Make」ではテキスト指示だけでコード生成まで実現する。Canvaは非デザイナー向けに画像編集・自動翻訳・音声生成を統合し、SNS投稿やプレゼン資料を短時間で仕上げられる点が強みである。資料作成分野では「Gamma」がテキスト入力のみでプロ級スライドを自動生成し、「Notion AI」は要約・文章生成・議事録作成をワンストップで対応する。Microsoft 365環境なら「Copilot」がWord・Excel・PowerPointと連携し、既存資産を活かした効率化が図れる。

コーディング支援AIの進化

コーディング・開発分野では「GitHub Copilot」が依然としてデファクトスタンダードの地位を維持している。VS CodeやJetBrains IDEとの深い統合によりコード補完・生成・テスト作成をシームレスに実行でき、NTTドコモやカカクコムなど大手企業での導入事例も増加中である。一方で2023年登場の「Cursor」はAIネイティブエディタとして進化を続け、2025年10月のバージョン2.0では専用モデル「Composer 1」とマルチエージェント実行機能を搭載した。プロジェクト全体を理解しながら複数ファイルを横断編集できる点が特徴である。さらにAnthropicの「Claude Code」はターミナル上で動作し、自然言語指示だけでコード生成からデバッグ・リファクタリングまで対応する。開発チームの規模や既存環境に応じた使い分けが重要となる。

業務自動化によるDX改革

業務自動化分野では「Microsoft Power Automate」がMicrosoft 365との統合度の高さで優位性を発揮している。2025年のアップデートではAIファーストの設計思想のもと、自然言語でフローを作成・編集できるCopilot機能が強化された。「Zapier」は7,000以上の外部サービスと連携可能で、異なるアプリ間のデータ転送を直感的なUIで自動化できる。エンタープライズ向けでは「UiPath」が世界的シェアを持ち、教育コンテンツとコミュニティが充実している点で社内人材育成にも適している。ただしツール導入においては、セキュリティポリシーの策定・情報漏洩対策・ライセンス管理が不可欠である。生成AIが業務データを扱う以上、社内ルールに沿った運用設計を先行させることが成功の分岐点となる。

開発手法の選択基準

大がかりなシステム開発においては、ウォーターフォールモデルという開発手法がとられ、設計書などのドキュメント類も整理してから、プログラミングへ着手する。逆に中小規模なシステム開発においては、アジャイル開発と呼ばれ、プログラミングをしながらシステム開発が進められたり、ドキュメント類は簡易にして、プログラミング工程へ着手するといった方法がとられる。状況に応じて開発手法は使い分ける必要がある。

設計書の必要と課題

建築では図面なく建物を建てることはないが、中小規模のシステムについては簡単な概要だけでシステムの開発ができてしまう。もちろん設計書をしっかりと書いて、要件を詰めてシステム開発を進めることができれば、トラブルもなくていいのではないかと言われる。しかし、設計書を作成するにはシステムをプログラミングすることと同じくらい費用が掛かる。

設計書の粒度と要因

中小規模のシステム開発において設計書が簡易になってしまう理由は、ユーザー側や発注側の予算が乏しいという理由がある。建築のパターンの場合は、法律によって作成しなければならない図面や、施主から同意をもらうべき書類などが決められている。システム開発には法的に作成しなければならない書類が明確にされているわけではないため、この粒度が各社・各エンジニアによりバラツキが発生する。

文書管理の現状

中小規模のシステム開発において、最悪の場合は設計書がないケースもある。小さなプロジェクトの場合は予算も少なく特にドキュメント類がないが多くある。あるいは、システムはアップデートされ続けているのにドキュメントはアップデートされていなかったり、ひどい場合にはシステム保守ベンダーが紛失している場合もある。

まとめ

システム開発に時間がかかる理由は、設計書から作成することでプログラミング作業の2倍以上の時間がかかると言われる。いわゆる動作検証の工程まで入れるとプログラミング作業の3倍程度は時間がかかる。また、システム開発はほとんどが人件費である場合が多く、かかる時間に応じて費用が上がる。つまり、非エンジニアが単純に開発費用を値切ると、プログラミング以外の重要な情報を削っていくことになる。

ゾンビファイル

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

作成者不明問題

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

市民開発解決法

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

専門家活用法

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

まとめ

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