DX予算を通す提案術

予算が通らないという壁

「現場の業務をもっと効率化したい」——そう考えて動き出しても、いざ予算を申請する段階で稟議が止まってしまう。そんな経験を持つDX担当者は少なくない。決裁者にとってDXは、効果が見えにくく費用ばかりが先に立つ「わかりにくい投資」に映りがちだ。熱意や正論だけでは、残念ながら財布のひもは緩まない。まずは、なぜ自分の提案が通らないのか、その理由を冷静に見つめ直すことから始めたい。

不満ではなく「数字」で語る

提案が通らない本当の理由は、多くの場合「効果が数字で語られていない」ことにある。「なんとなく効率化できる」で終わらせず、どの業務にどれだけの時間と費用がかかっているのかを、一つひとつ具体的に洗い出していく。この棚卸しを飛ばして予算だけを求めても、決裁者の判断材料は揃わない。まずは現状で洗い出した課題を、決裁者が判断できる「数字」へと翻訳することから始めたい。

ROIとPower Appsという武器

決裁者を動かす鍵は、ROI(費用対効果)を「時間」の観点から具体的に示すことだ。たとえば「毎月の集計作業に3人が20時間かけている」という現状を、「年間で720時間、人件費に換算すれば約200万円」と翻訳すれば、削減効果が一気に伝わる。決裁者が本当に知りたいのは、その投資が何ヶ月で回収できるのかという一点だからだ。ここで有効なのが、Microsoftが提供するローコードツール「Power Apps」である。多くの企業がすでに契約しているMicrosoft 365に含まれる場合も多く、新たなツールを一から購入するよりも初期費用を抑えられる。投資額と回収効果を並べて示すことで、DXは漠然とした夢物語ではなく、計算できる経営判断へと姿を変える。

スモールスタートで実績を積む

とはいえ、いきなり全社規模の大きな予算を求めても、決裁者の不安は拭えない。そこで有効なのが「スモールスタート」だ。まずは一つの部署、一つの業務に絞って小さく早く動かし、目に見える成果を作る。Power Appsは小さく作って試すことに向いており、最初の一歩を軽くしてくれる。そして「この規模でこれだけの時間を削減できた」という実績こそが、次のより大きな予算を通すための最強の材料になる。大切なのは、一度予算を勝ち取って終わりにしないことだ。小さな成功を現場に定着させ、その成果を根拠に次の改善へとつなげていく。この循環を描いて見せられれば、決裁者は提案を「一度きりの出費」ではなく「育てる投資」として受け止めてくれるはずだ。

まとめ

DX予算を通す提案術の本質は、担当者の熱意を決裁者に伝わる「数字」に翻訳し、大きな理想を実行できる「小さな一歩」に分解することにある。ROIを時間とコストの両面から具体的に示し、スモールスタートで確かな実績を作る。そして、その成果を次の予算へとつなげる改善の循環を描く。この三つの視点を押さえれば、これまで止まっていた稟議も、ぐっと通りやすくなるはずだ。

関連記事

技術的負債の返済方法

負債の本質

技術的負債には、設計負債やコード負債がある。金銭的な負債であれば借入金やマイナスの表記で数字化できるのだが、技術的負債においては数字化できないことがとても難しい点である。経営に関するほとんどのことは定量化や定性化が可能だが、たとえば企業創業者の発想する「野生の勘」を直接的に数字化できないように技術的負債も一筋縄では見える化しない。

設計時の対策

技術的負債の中でもコード負債については、システム開発の現場からよく発想されるリファクタリングや再構築などを行うことで比較的わかりやすい返済方法となる。知らない人が作ったプログラムや古くなったプログラムのバージョンなど、リスクを表現し対応することができる。何よりも最初の企画設計段階で負債が積みあがりにくい仕組みを考えることが大切である。

高負担な設計

技術的負債の中でも利息の高い負債が設計負債である。単体機能における設計であれば、モジュールごとの再設計によって返済が可能である。しかし、プログラムは複数のモジュールが絡まり合っていることがほとんどなので、複雑なオペになってしまう。また、稼働中のシステムにわざわざ再設計したプログラムを導入するリスクに対して、得れるメリットも少ないので見過ごされがちである。設計能力は例えば、紙というオブジェクトのメソッド(振る舞い)とプロパティ(保持する情報)を聞いて正しい答えが帰ってくれば多少安心であろう。紙の振る舞いは燃えるであり保持する情報は面積などがある。

根本的解決

しかし、技術的負債はこのように目に見えやすい設計負債やコード負債が致命的になることは少なく、やはりその上層でどのような指針に基づいてシステム運用がなされてきたか、また長期視点で一貫したメンテナンスを行うことが必要である。システムの維持には保守費用や運用費用を払っていることが多いと思うが、これだけでは将来の負債を減らしていくことはできない。やはり、鳥の目を持つITコンサルタントやITアナリストなどの役割を持つメンバーが必要である。

まとめ

ITコンサルタントやアナリストは、すぐに利益も生まない、経費を削減するわけでもないといったコストセンターとしてのポジションなので、あまり起用していない中小企業も多いようである。投資に対する効果が見えにくいのは、料理でいう香辛料と同じなのかもしれない。その少しの投資が未来を大きく変えることになる。IT技術は日進月歩で発展するからである。

続きを見る >

伴走型開発で仕様変更地獄を脱出

炎上の元凶

システム開発プロジェクトにおいて「仕様変更地獄」は最も深刻な問題の一つである。開発が進むにつれて次々と変更依頼が発生し、スケジュールは遅延、コストは膨張、開発チームの疲弊が進む。こうした状況に陥った企業では、プロジェクト自体が頓挫するケースも少なくない。特に従来型の開発手法では、仕様を固めてから開発に着手するため、後から変更が入ると大きな手戻りが発生する。ビジネス環境の変化が激しい現代において、この開発スタイルは限界を迎えているのだ。

仕様変更の理由

仕様変更が頻発する背景には、いくつかの構造的な問題がある。第一に、プロジェクト開始時点で業務要件を完璧に定義することは実質的に不可能だという現実である。現場の担当者も、システムが動く姿を見るまで本当に必要な機能が見えない。第二に、開発期間中にビジネス環境や競合状況が変化し、当初の要件では不十分になることがある。第三に、発注側と開発側のコミュニケーション不足により、認識のズレが後から発覚するケースである。これらの問題は、従来の「要件定義→設計→開発」という一方通行の開発プロセスでは解決できない。

伴走型開発の効果

こうした課題を解決するのが「伴走型開発支援」というアプローチである。これは、開発ベンダーが単なる請負業者ではなく、ビジネスパートナーとして顧客企業に寄り添い、プロジェクト全体を通じて継続的に支援する手法だ。具体的には、小さな単位で機能を実装しては確認するアジャイル的な開発サイクルを回し、仕様変更を前提としたプロジェクト管理を行う。重要なのは、変更を「悪」ではなく「ビジネス価値の最大化」として捉え直すことである。定期的なレビューで優先順位を見直し、本当に必要な機能に開発リソースを集中させる。こうすることで、限られた予算と期間の中で最大の成果を生み出せるのだ。

成功の3つの鍵

伴走型開発支援を成功させるには3つのポイントがある。第一に、発注側と開発側が対等なパートナーシップを築き、透明性の高いコミュニケーションを維持することである。進捗状況や課題を隠さず共有し、一緒に解決策を考える姿勢が不可欠だ。第二に、MVP(実用最小限の製品)の考え方で、コア機能から段階的に実装していくことである。すべてを一度に完璧にしようとせず、ユーザーフィードバックを得ながら改善を重ねる。第三に、変更管理のルールを明確にし、影響範囲とコストを可視化することである。無秩序な変更を防ぎながら、本当に価値のある変更は柔軟に取り入れる。このバランスこそが成功の鍵となる。

まとめ

仕様変更地獄から抜け出すには、開発手法そのものを見直す必要がある。伴走型開発支援は、変化を受け入れながらプロジェクトを着実に前進させる現代的なアプローチである。単なる技術提供ではなく、ビジネスゴールの実現に向けた戦略的パートナーシップが、これからのシステム開発には求められているのだ。

続きを見る >

相場の不在

開発の相場観

相場とは、一般的に市場で競争売買によって決まる商品の価格とされているが、ことシステム開発においては、相場というものが存在しない。

比較の難しさ

比較できる同じものであれば競争原理が働き相場が構築されるが、フルスクラッチされるシステム開発においては全く同じものができることはない。しかも、出来上がるものはパッケージシステムやSaaSの利用以外は、未来にしか完成しないので当然比較もできないものとなる。

将来要件判断

比較的ないからこそ、しっかりと吟味する必要があるが、吟味する材料や条件などは現時点で明確になるものが元となる。未来に発生する追加条件や変更される環境などはジャッジする時点にはすべて出そろわないという難しさがある。

変化への対応

システム開発は未来にどのような条件変更やルール変更が行われるかわからないものであるという認識を持つことが大切である。その上で最善のジャッジを行うべきである。その判断は過去を遡って正解か間違いかを評価すべきではない。

まとめ

日本では原点方式の人事評価が行われるため、イノベーションは起こりにくい本質的な問題がある。これを無視して「DXだ」といっている組織があるとすれば、それは本質を見誤っているといえる。

続きを見る >