HPやシステム開発を検討している非ITの事業者必見 part.1(予算編vol.1)

どうもどうも、Lazy(@lazy_Engblog)です。

さて、やれ人工知能だの、やれ人間の職が失われるなどのニュースが多くなり、大企業は人工知能開発、中小企業では業務システムの導入・開発がより盛んになってきたように思います。

その結果、今までITとは無縁で過ごしてきた業界の会社様からもパッケージシステム製品の導入や自社システムの発注のご相談を多く相談されるようになりました。

ありがたいことではございます。

ただ、どうも会社様の方で予想される御見積額を遥かに超えてしまうようで、けっこう冷たい視線を受けることが多いので今日はそういった話。

いきなり結論!開発費用が高いと思うなら頼まないほうがいい!

いきなり結論。しかも、お客さんを一気にいなくなるような結論ですが、この結論は変わりません。

理由は以下の2つ

  1. IT知識が無いことを良いことに開発を大幅に上乗せしている可能性が少なからずある。
  2. まっとうな金額の見積なのに、値下げしてしまうと質の低い製品が完成する恐れがある。(今日のメインの話はここ

今の時代、見積額を大幅に盛るような事業者はほぼいません。

さて、理由1の本来の作業費用プラス正当な利益額を計算した、見積もり額から大幅に膨らましているパターンですが、これはほぼありえません。

見積額に対して納品された製品に質が伴うかどうかは別として(要件を伝えてなかったとか、途中で要件を変えたなどいろいろ原因はあるため)、今のご時世、人工知能だなんだとIT技術がリアリティの世界に影響を与え始めてる時代に、見積を膨らませて儲けようなんて、みみっちい事業者はほとんどいません。

これは、フリーランスでも法人でも同様です。

昔ならインターネットなどが浸透しておらず、地元のシステム会社にしか発注できなかった時代には、そういう話はたくさんあったようですが今では、発注する側にも知識がつき、自分たちでも相場を調べられたり遠方の会社に見積を取ることも可能なので、事業者側もそんなリスキーなことはしません。

もし、口コミで広がってしまっては事業者自身に影響がでますので、、、

もし、そういったところに発注してしまったのなら、発注先を見抜けなかった、相場を調べなかった、アイミツを取るなどの動きを取らなかった自分たちにも非があると思ったほうが今後に役立ちます。

厳しく生意気な意見になりますが、これは「ITリテラシーが低い」と言わざるをえません。

今であれば、過去の成果物や既に制作済みのサービスなどは調べることもできなくはないので。

言い換えるなら、騙す方も悪いですが、騙される方も悪いです。

まっとうな金額で高いと感じても値下げしないようにしましょう!

さて、「どうやってまっとうな金額かを見分けるのか」っていう話もありますが、基本的にどの業界も言えることですが、値下げ交渉なんてしないほうがいいとボクは思っています。

ボクは、外注さんにも当然ですが家電量販店とかでもあまり値下げ交渉なんてしません。

まぁ、想定より高いなぁと思うことはありますが、払えないようなときは自分がやめるべきです。

非IT業界も同じなのでしょうが、IT業界は特に値下げすると基本的に開発したシステムやHPなどのの納品物の質が落ちます。

例えば、お家を作るときは少し予算が超えてしまった場合は、床材などグレードの下げたりして、あくまでも既製品の中で対応できますが、システムの場合は、必要である機能をガッツリ削除したり、あったほうがベターなUI面の配慮とかやるべき入力チェックを外してしまったりします。

UI面の配慮は、郵便番号入れたら自動で住所が入力されるなどです。

入力チェックとは、電話番号の入力欄に、「あいうえお」とか文字を入れてもお問合わせフォームが送信されてしまったりするのを防ぐようなものです。

実際に問い合わせがあったのに、こういう冷やかしみたいなものも防げるようになるわけです。

もっとヒドイのは開発自体の品質が低くなる場合

さて、上記はあった方がいいものを丸ごと削っているわけなので「しばらくは、我慢する」という範囲になります。

後々、追加機能として入れてもいいし、それと同時に改善案件が挙がったりするので、さほどの問題ではなかったりします。

本当にヒドイのは、当初の「発注内容のまま見積を下げる」パターンと「確定した見積のまま追加要件を入れる」パターンです。

日本のIT企業がブラック業界の代表になっている主な原因はこの2つにあります。
それも、日本人の行き過ぎたサービス精神が根底にあるのですが。。。

システム開発は、超ざっくり大きく分けると、「設計工程」、「開発・プログラミング工程」、「テスト工程」が一般的な流れになります。

この2つのパターンの最大の特徴は、「発注内容が減らないなら、開発期間を減らすか、人(頭数または、雇う人のスペック)を減らす」というところになります。

下がった金額の中で対応するようにするためには、どこかを妥協するしかないのです。

時間をかけるべき設計工程をサクッと終わらせて「優秀なプログラマ入れてプログラミングしてもらえれば大丈夫!」という現場もありました。

結果は最悪です、設計書にかかれているべき画面項目がなかったり、そもそもクライアントの要件と全く違うことも。。。

逆に、設計はしっかりやったから、単価の低いプログラマを雇って開発しても同じです。

テスト工程でバグが予想を超えてしまい、どれだけの潜在バグがあるのかが不明確になり、最終的には優秀なプログラマを入れるしかなかったりします。

きちんと、それぞれの工程に必要な時間、必要な人員数を導入するべきです。
そのためには、必要なのが当初出していた見積額になるわけです。

わずか1ヶ月で、10人によって作られた25階建ての高層マンション完成!

って宣伝されても住みたくないですよね。

それよりかは、きちんと設計されて建築関連の法律もクリアして、免震などが施された安心安全のマンションに住みたいものです。

【予算編vol.1】のまとめ

  • 正式な発注前に、実現したいシステム・HPの要件をきちんと伝えること
  • 専門的な業種に手を出すなら、発注先の選定は慎重に行うこと
  • 根拠がなく、相手のサービス精神に期待した値下げ交渉はしないこと

思ったより長くなったので、【予算編vol.2】へ続きます。