開発の相場

相場の不在

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

建築との差異

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

人件費の実態

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

工期の変動

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

まとめ

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

関連記事

要件定義のアプローチ

要件定義の基本

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

規模別の要件定義

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

要件定義の本質

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

対話型要件定義

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

まとめ

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

続きを見る >

予算ブレの原因

開発の変動要因

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

目標変化と予算

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

計画型開発法

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

柔軟な開発手法

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

まとめ

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

続きを見る >

Power Appsで簡単に業務改善

システム開発の高コストと複雑化

多くの企業では、情報システム部門や外部システム会社にシステム開発を依頼すると、仕様確認が繰り返される。「この機能はどうするか?」「ステータスはこれで全てか?」など、質問が多く、時間とコストが増大。結果、システムは複雑化し、現場のニーズに即したシンプルな解決策から遠ざかる。

野良プログラムのリスク

システム開発の手間を避けるため、各部署でExcelマクロによる「野良プログラム」が横行する。これらは各人のPCに保存され、最新版の確認が困難になり、メンテナンスも不透明。担当者がいなくなるとブラックボックス化し、セキュリティリスクも増加。放置すれば、企業全体の業務効率が低下し、情報漏洩の危険もある。

Power Appsで迅速なシステム構築

こうした問題を解決するのが、MicrosoftのPower Appsだ。従来の複雑な開発プロセスを排除し、現場担当者が自らアプリを構築できる。ドラッグ&ドロップで簡単に操作でき、セキュリティもMicrosoft標準に準拠。野良プログラムの乱立を防ぎ、システム管理とメンテナンスも容易になる。さらに、ユーザー自身がアプリを修正できるため、柔軟性も確保できる。

定量化困難な業務もデジタル化

業務のデジタル化は、数値で説明可能なタスクは簡単だが、現場には「説明しにくい」業務も多い。こうした業務は経験に依存しがちで、担当者に頼ることが多い。Power Appsは、このような曖昧な業務も迅速にアプリ化し、標準化と効率化を同時に実現する。

まとめ

Power Appsは、現場主導でアプリを作成・管理できる柔軟性を提供し、野良プログラムのリスクも解消する。複雑な開発プロセスを省き、数値化しにくい業務も効率的にデジタル化することができる。

続きを見る >