予算ブレの原因

開発の変動要因

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

目標変化と予算

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

計画型開発法

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

柔軟な開発手法

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

まとめ

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

関連記事

開発費用値下げの危険性

開発手法の選択基準

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

設計書の必要と課題

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

設計書の粒度と要因

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

文書管理の現状

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

まとめ

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

続きを見る >

開発遅延の打開策

システム開発の現状と課題

数名で開発した初期のシステム構築から、システム会社を変更して大がかりなリプレイスを行い、保守運用を実施しているが、月々の費用が高額であるわりに、開発スピードも遅い。開発スピードが遅いため、新しい機能を実装していけない。

不具合と開発の不透明性

リリースから何年も経っているのに不具合がなくならない。開発会社からの報告が曖昧で何にお金を支払っているのか謎のままであることが多い。

コスト削減と資源最適化

開発スピードを上げるには、システム開発コストの削減をしなければならない。コストを削減するということは、それで浮いたコストを開発に割り当てることができるため、結果的に開発スピードがあがることを意味する。

開発の透明性と妥当性

そのためにしなければならないことは、開発工程や開発過程の見える化および妥当性を担保することである。システムの比較検討ができないため、システム開発のコミュニケーションは一般的なものであると思い込んでいる。システム発注の担当者はシステムのことがわからないから、システム開発の進め方に違和感があったとしても技術者が言うことを信用するほかないと思っている。

まとめ

結果として、技術者の工数と称して月々の費用や、ひどいものでは言語のバージョンアップと称して、何もしていないことに費用を支払っていることもある。不明点はシステム発注の担当者が理解できるまで聞くべきである。

続きを見る >

DX前の業務整理

DX推進の落とし穴

多くの企業がDX推進を急ぐあまり、業務改善ツールやシステムの導入を最優先にしてしまう傾向がある。しかし、現状の業務プロセスを整理しないままツールを導入することは、非効率な作業をそのままデジタル化するだけに終わる危険性がある。DXの本質は単なるIT化ではなく、業務そのものの変革にある。

非効率のデジタル化の罠

いきなりツールを導入すると、既存の非効率な業務フローがそのままシステムに組み込まれてしまう。例えば、不要な承認プロセスや重複した作業がデジタル上で再現され、かえって業務が複雑化するケースも少なくない。また、現場の実態に合わないツールを選定してしまい、導入後に使われなくなるという失敗も頻発している。結果として、多大なコストと時間を費やしながら、期待した効果を得られないまま頓挫するプロジェクトが後を絶たない。

業務可視化から始めるDX

DXを成功させるためには、ツール導入の前に徹底した業務整理が不可欠である。まず、現在の業務フローを可視化し、各プロセスの目的と必要性を検証する。次に、重複作業や不要な承認ステップを洗い出し、業務そのものをシンプルにする。この段階で「なぜこの作業をしているのか」を問い直すことが重要である。形骸化したルールや慣習的に続けてきた作業を見直すことで、本当に必要な業務が明確になる。整理された業務プロセスに対して最適なツールを選定することで、初めてDXの効果を最大化できる。

業務整理の成果

業務整理を先行させることで、ツール導入の目的が明確になり、適切な選定が可能になる。整理された業務フローは現場の理解も得やすく、ツールの定着率も大幅に向上する。さらに、業務整理の過程で発見された課題は、DXだけでなく組織全体の改善にもつながる。属人化していた業務の標準化や、部門間の連携強化など、副次的な効果も期待できる。DXは一度きりのプロジェクトではなく、継続的な改善活動である。まず業務を整理し、その上でツールを活用するという順序を守ることが、持続可能なDX推進の鍵となる。

まとめ

DX成功の鍵は、ツール導入前の業務整理にある。非効率な業務をそのままデジタル化しても効果は得られない。まず業務フローを可視化し、不要なプロセスを排除してから最適なツールを選定することで、DXの本来の効果を発揮できる。

続きを見る >