記事

予算ブレの原因

開発の変動要因

システム開発は長期にわたることが多く、また未来の不確実性の中で予算を策定しなくてはいけないことがある。セキュリティーをはじめ動作環境の変化や人員の欠如、予期していなかった仕様の発覚などが原因だ。

目標変化と予算

進捗率は目的地が明確に設定されていれば数字を負うことで予算達成率を算出することができる。しかし、目的地が近い遠いのは無しではなく、根本的な目的地がなくなったり、複数になったりすることがシステム予算の策定の難しいところである。

計画型開発法

システムに未来を見ることができればブレない、見えないことをすべて調査の上で着手できれば確実な予算と実行が可能である。進捗率の報告が可能になる。フォーターフォールモデルなのでコストがかかることと時間がかかることの覚悟が必要だ。途中での方向修正は原則できない。

柔軟な開発手法

逆に低予算で早く導入するなら、見えにくくなるデメリットがある。状況によって対応を素早く変化させる必要があるため進捗率を算出しにくい。アジャイル開発と呼ばれるものであり、社内開発であることが理想である。途中で出てくる条件に対しても柔軟に方向性を変化させることが可能である。

まとめ

アジャイル開発で予算を立てるときは、1.5-2.5倍くらいを目安に余裕を持って設定することを推奨する。

ローコード開発≠安い 前の記事 内製化の成功術 次の記事

関連記事

記事

開発の相場

相場の不在

フルスクラッチでのシステム開発に相場はない。相場とは商品が一般的に流通している商品など数が多い場合は、競争原理も働き、金額がある一定の範囲に収まってくるものである。

建築との差異

たとえば、一戸建て建築であれば、建物の規模と資材、それに加えて職人の人工で金額が決まる。フルスクラッチのシステム開発は、つまり極めて特殊な特注品を作るようなものであるため、システム開発に相場という概念が基本的にはないのである。

人件費の実態

システム（ソフトウェア）は一戸建てのように、基本的には材料費はかからない。システム開発の費用のほとんどは人件費である。大工職人の人工と同じように人月単価と呼ばれるSE1人が1ヶ月働く金額で相場を知ることができるのである。

工期の変動

建物を建てることと比べるとシステムやソフトウェアは無形の物となるため、1ヶ月の労働力を推し量ることは困難である。個人のプログラミングの早さによって、納期が早くなったり遅くなったりするのである。

まとめ

SEは過去のプロジェクト参画実績から、同じようなプロジェクトに何度も参画していれば手練れでスキルが高いと評価される。システムに関わる人材の評価が困難な点は、プロジェクトに参画する経験値と、本当の意味でのスキルが比例するわけではないことである。本当の意味でのスキルとはプロジェクトを成功させられるかどうかを指すのである。

続きを見る >
記事

DX疲れの実態と対策

DX疲れとは何か

DXを推進しなければならないというプレッシャーの中で、現場の担当者が静かに疲弊しているケースが増えている。新しいツールの導入、業務フローの見直し、社内への説明と調整。やるべきことが次々と降りかかり、通常業務との両立に限界を感じている方も少なくない。実はこの「DX疲れ」は個人の能力不足が原因ではなく、組織全体の進め方に根本的な問題が潜んでいることが多いのである。まずはその実態を正しく理解することが、改善への第一歩となる。

疲弊する現場の共通点

DX疲れが広がる現場には、いくつかの共通した特徴がある。まず、DX推進の担当者が少人数、あるいは一人に集中しているケースである。経営層からの期待は大きい一方で、具体的なサポート体制が整っておらず、担当者が孤立してしまう。さらに、短期間で成果を求められることも大きな負担である。DXは本来、段階的に進めるべき取り組みだが、「早く結果を出せ」という圧力が現場を追い詰める。加えて、現場の社員からの抵抗や非協力的な態度も、担当者の精神的な消耗を加速させる要因である。こうした環境では、どれほど優秀な人材でも疲弊するのは当然のことなのだ。

ペース配分という処方箋

では、DX疲れを防ぎながら着実に成果を出すにはどうすればよいのか。最も重要なのは「ペース配分」の見直しである。すべてを一度に変えようとするのではなく、優先順位をつけて段階的に進めることが欠かせない。たとえば、まずは一つの業務プロセスに絞ってデジタル化を試み、小さな成功体験を積み重ねていく方法が効果的だ。また、DX推進を特定の個人に依存させず、チームとして取り組む体制を構築することも大切である。定期的な振り返りの場を設け、進捗と課題を共有することで担当者の孤立を防げる。経営層も「すぐに成果が出るもの」という認識を改め、中長期的な視点でDXを支援する姿勢が求められる。焦らず、しかし確実に前進する意識こそが、組織全体の持続的なDX推進を可能にするのである。

持続可能なDXの実現

DX疲れは、放置すれば担当者の離職やプロジェクトの頓挫といった深刻な結果を招く。しかし、正しいペース配分と組織的なサポート体制があれば、無理なくDXを前進させることは十分に可能だ。大切なのは、DXを「特別なプロジェクト」として切り離すのではなく、日常業務の延長線上に位置づけることである。現場の声に耳を傾け、小さな改善を積み重ねることで、社員一人ひとりがDXの意義を実感できるようになる。また、外部の専門家の力を借りることで、社内だけでは見えなかった課題が明確になり、効率的な推進が可能になるケースも少なくない。DXは短距離走ではなくマラソンである。走り続けられる環境をつくることこそが、真のデジタル変革への近道なのだ。

まとめ

DX疲れは、現場の担当者だけの問題ではなく、組織全体で向き合うべき課題である。無理のないペース配分、チーム体制の構築、そして経営層の理解と支援があれば、持続可能なDX推進は実現できる。まずは自社の現状を見つめ直し、できることから一歩ずつ進めていくべきだ。DXの進め方に悩んだら、こちらの書籍もぜひ参考にしてほしい。

続きを見る >
記事

要件定義のアプローチ

要件定義の基本

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

規模別の要件定義

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

要件定義の本質

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

対話型要件定義

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

まとめ

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

続きを見る >