« システム開発を成功させるためにはどうすればよいか・・・ ~ユーザー編 その2~ | メイン | システム開発を成功させるためにはどうすればよいか・・・ ~ユーザー編 その4~ »

システム開発を成功させるためにはどうすればよいか・・・ ~ユーザー編 その3~

システム開発の見積金額ですが、最初のお打合せから最後の納品立会い運用支援までを考えた場合、一番お金がかかるところはどこかご存じでしょうか。

「何のシステムを作るか」がわかっている場合にはなんと、プログラミングの金額が一番高くなるのです。

だからこそ、プログラマの人件費が安いオフショアが話題になるし日本国内の開発においても、外国人を使ってOKなのかNGなのかといったことが言われてしまうのです。

オフショアのお話については別の機会に譲って、今回はプログラミングを考えた場合に「何が高いか?」を説明します。

内容によっては設計とも関わってくる部分もありますがまずはプログラミングの視点、つまり、自分がプログラマだったら高く見積るというところ、そして、市場的に高いと思われているところをご紹介します。

▼こうするとプログラム費用は高くなる。

(1)OSやツール、DB(俗にいう開発環境)が「ニッチ」な場合は高くなる。

これは、開発環境、テスト環境を指します。
安く抑えるためには、OSであれば、Winows, Linux, Unix のいずれかそして、最新のバージョンから2、3バージョン前までのものとします。

Windowsでいえば、Vista, WindowsXP, Windows2000です。
(実際には、まだまだVistaは制限付きとなっているようですが・・・)

言語でいうと、Java, .NET(ドットネット), PHPくらいがセーフです。
これ以外は、開発者も経験者も限られてしまうため金額が高くなってしまいます。
需要と供給の関係から、開発者を探すのが難しい場合は高くなるのです。

ニッチな場合には、金額だけでなく「何かあった場合」の問い合わせ先が限られているので、リスクが伴います。

これに関連して、新システムを組む場合は、「JavaとOracleで作ってほしい」という要望よりは、「ツールは何でもいいから」の方が安くなりますね。


(2)納期が短期の場合は高くなる。

開発者がたまたま空いていて、短期でも、通常のシフトで間に合う場合は例外です。

今月末までに絶対納品というようなタイトなスケジュールを提示され「社長命令だ」、「これが条件です」など、「絶対」と言われてしまうと最終的には「金で人を探して」集めるしか方法がなくなってしまうので高くなるのです。


(3)帳票や画面照会系よりも画面入力系が多い場合は高くなる。

システムから出力するものと、入力するものとのリスクの違いという意味もあるのですが、一般的に「入力画面」は技術度が高く難しいことが普通です。

ただし、次の(4)とも関係してきますが、画面の動き、設計についてはシステム開発会社にお任せして、それで納得できる場合は別となります。


(4)画面の動きにこだわり過ぎると高くなる。

インターネットのGoogleや、ネットショッピングのサイトで見た使い方がよかったから同じ動きをしてほしい、今まで使っていたパッケージと同じ動きにしてほしい(今までのシステムはWEBでは無かったにも関わらず)といった場合には、プログラマの持っている技術資産がそれに対応していないことがあります。

プロが行う見積りは、すでに標準的に持っている技術資産で仕事をしていくらという見積りです。
例外的に、新しく技術を磨いて作成するという時間が含まれていません。

この場合はプロトタイプを作ってもらい、確認、承認して互いに納得してから着手することをお勧めします。

この確認を曖昧にすると、互いに幸せにはなれません。
開発側も1本目は慎重にゆっくりと作るのが通常ですから、データ更新(画面で入力したデータを呼び出せるところ)を含めないで画面の動きだけであれば、プロトタイプを作ることをいとわないはずです。


(5)個々の画面プログラムの繋がりを複数持とうとすると高くなる。

システムにもプログラムにも、セオリというものがあります。
メニューから機能を選んで起動する、機能が終了したらメニューに戻るといった動きを、通常はセオリ通りの動きとします。

しかし、売上伝票を入力しながら得意先マスタを登録したい、という複数のプログラムから互いに自由に呼び出せるような仕組みを作ると設計、そして確認作業、テストも複雑になります。


(6)後から設定を自由に変更できるようにすると高くなる。

例えば、商品マスタを区分けする商品分類を自由に追加、修正するこれは通常の要求です。

しかし、どんなものでも同様にということは、プログラマに負担をかけることになります。

例えば、画面に初期表示する対象期間範囲を「1週間前~当日」で表示するという仕様があったとします。

この仕様を、将来的に変更する可能性がある場合(実際にはあるかもしれない程度です)、このときに後からのプログラム修正料金を恐れて管理者がいつでも自由にこの期間設定を変更できるようにすると後からのプログラム修正の方が、よっぽど安かったということもあります。


(7)仕様が不明確で、いつまでも決まらないと高くなる。

例えばの話ですが、誰が運用しているのかわからないような機能があったとします。

以前のシステムには、その処理が入っていたので入れておきたい。
しかし、プログラミング設計をする前に、お客様の運用仕様が明確でない。

「後からこの仕様のこの部分については引き継ぎますから残りの部分だけで動くようにしておいてください」とお客様が営業に頼みSEも承諾したとします。

プログラマは、実はこういった仕事が一番嫌いなのです。
彼らのモチベーションを高めるためにも、曖昧な部分になるべく早く決着をつけるようにしてください。

プログラマは、「わからないものがある」ということに大きな不安を抱くのです。


以上、7つの金額が高くなる条件を書いてみました。

結局は技術者一人一人の意識や技術、そしてチームワークが大事な仕事です。

彼らがやる気になって、全力を尽くせるような発注の仕方がよいシステム発注のコツともなるわけです。

プログラマも技術者ですから、「難易度が高い仕事がしたい」という気持ちがあるのが普通です。

しかし、本当にその意味があるのか難易度を高くしてまでプログラミングする意味があるのかということも彼らは非常に気にしています。

コストパフォーマンスを気にしているのは、実はお客様だけではないのです。

Vol.00149

トラックバック

このエントリーのトラックバックURL:
http://www.ilovex.co.jp/scripts/intra/mt/mt-tb.cgi/2534

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2008年06月24日 11:30に投稿されたエントリーのページです。

ひとつ前の投稿は「システム開発を成功させるためにはどうすればよいか・・・ ~ユーザー編 その2~」です。

次の投稿は「システム開発を成功させるためにはどうすればよいか・・・ ~ユーザー編 その4~」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type 3.38