アイロベックスメールマガジン　携帯版

実際のところ、当社は100%受託開発を行っています。

もちろん、ユーザー様との直案件だけでなく、大手ベンダーの営業さんや、システムソリューション部隊からも、お仕事をご紹介いただいています。

受託開発で全部、社内で賄っていくというのは、ある意味、奇跡に近く、営業がいないわけですから、仕事が来る経路はいくらあっても構いません。

どうしても、「営業がいない」→「営業に無関心」ということになりがちですが、それは必ずしも、そうであるとも言えません。

なぜなら、飛び込みや電話による「新規営業」はしなくても、Webをご覧になったお客さまから、直接のお問い合わせがあることもあるのです。

また、営業がいない為の苦しみというものを散々味わっているので、案件に対しては、必死に食らいつこうとする根性は生まれます。

営業部隊がお客様に提出している提案書にも、興味津々です。

さて、開発費用が数千万以上になると思われるシステム提案書を集めてみると、どの提案書も似た形式で書かれていることに気づきます。

企業の基幹業務についてのシステム・リニューアルを例にとってみますと、御社業界の状況、御社の置かれた状況、御社の課題、問題点といった、お客さまの現在状況を分析し、そこから問題点を抽出して、どうやってその課題を解決するのかといったことを中心に、将来像、あるべきシステム展開を絵にして語るといった、「提案型」がほとんどを占めているのです。

正直、提案書の書き方といった書籍を読んだり、いろいろな提案書を集めてみると、こういうものがほとんどです。

もちろん、「提案書」だから、「提案型」であるべきだと考えることはよく分かります。

しかし、こういう提案書を幾つか見ますと、同じ業界であれば使い回し、同じ業界でなくても、文書管理、在庫管理といった、共通のシステム内容であれば使い回しが行われていることが、見た瞬間に分かります。

つまり、汎用的で抽象的な「カッコいい言葉の羅列」の提案書にすぎず、お客様に対しての関心や思いやり、サイズに合った提案が入っていることが少ないと言いたいのです。

「これを受け取ったユーザー企業の担当者は、どこを見るんだろうか」と考えると、「機能一覧＋スケジュール＋コスト」だけのような気がします（すみません）。

結局、経営者や情報システム部が余りにも忙しいのか、ITシステムに興味がないのか、両方なのか分かりませんが、こういったコンサルタント的提案書（決してほめ言葉ではありません）が、まかり通っていることが本当に不思議です。

では、多少、近視眼的だとは思いますが、私が考える「よく出来た提案書」について考えてみたいと思います。

それは、現場なり、ユーザーのシステム部の方々が見たときに、「当社のことがよくわかっている」とか、「ここまでいろいろなことを考えてくれるんだ」と思わせるような、気持ちを揺さぶる提案書なのです。

その為には、提案書は、「こうあるべきだ」の形ではなく、お客様が、個別に自社向けに提案されたと実感できる機能を、具体的な運用と同時に表現し、盛り込んで、その中の「お勧め」が、はっきりと具体的に書かれていることではないでしょうか。

「とにかく営業しなければ仕事が無い」、「提案しなければ始まらない」というのは確かなことです。

しかし、IT技術力を使うことで企業文化なり状況を画期的に変える、素晴らしい提案書を作ることが使命だと思っているのか、ともすれば、「絵に描いた餅」のようなビジョン系のシステム提案を作り、お客様を見下したような提案書の形が多いのが気になります。

提案先の企業の文化の変革を唱えながらも、一方では、使い回しした提案書がまかり回っているのも事実だから、矛盾していると思うのです。

もちろん、「万事がこれ」とは言いたくありませんし、中小企業のソフトハウスとは違うんだと言われてしまえば、そうなのかもしれません。

ただ、相手によって、また、場合によって、提案書の中身をちょっと違う視点で発想してみることも、必要ではないかと思うのです。

なぜなら、「ルーチン化」してしまうことが、仕事の最大の敵だと思っているからなのです。

「ユーザー企業がシステム開発を考えた場合、最も安く上げる方法は、開発しないことである」
これは、もはや常識とされています。

出来ているものの中から、自社に最適なものを選ぶ。
つまり、パッケージを購入して、一切、カスタマイズしないで使う、これに限るわけです。
住宅でいうなら、建売住宅を購入するといったイメージです。

それでも、選択のミス、安物買いの銭失い、思っていた成果が出ない、といったリスクは伴います。

しかし、パッケージを購入し、カスタマイズせずに使用している企業はどのくらいあるのでしょうか。

これは、システムの種類によりけりでしょう。

たとえば、会計システムや、勤怠システム、給与システムは、パッケージを、そのまま使用することが多いシステムです。

また、たとえカスタマイズしたとしても、企業にあわせてプログラムを作る部分は、そう多くないと思われます。

特に、会計システムは、中小企業においては、どちらかというと、税務署へ提出する決算書等作成のためのシステム、といった度合いが大きく、ルールは簡単で一律なので、パッケージそのままで、使用することができるのです。

これまで、大企業（特に歴史のある会社）は、基幹系システム化の歴史において、過去に手作業で行っていた業務を、テーラーメイドのシステムで、システム化してきました。

しかし、ダウンサイジング（懐かしい響きです）が言い出された頃から、なるべく、共通で使える機能はパッケージを採用し、且つ、カスタマイズで独自の業務を作り出そうとしてきたのです。

パッケージありきの商談でも、カスタマイズの重さによって、金額や納期が決まります。
本体価格の、10倍以上になることさえあるのです。

それでも、パッケージはテーラーメイドよりも安いのでしょうか？

実は、そうとは言えません。
パッケージのカスタマイズであれ、何であれ、システム開発は、30機能を超えた辺りから、大プロジェクトになってきます。

人間のコミュニケーションを考えてみてください。
2人の人間が、コミュニケーションをとるのに比べて、5人の人間が、コミュニケーションをとるのには、10倍の力が必要です。

それは、プログラムも同じです。
10機能くらいであれば、少人数のプログラマだけで、短期間で、設計も開発もできるのですが、50機能、100機能となれば、何十人月といった工数が必要になってくるのです。

これは、プログラム間のコミュニケーションの整合性をとるために、大きな力が必要となるからなのです。
加えて、開発以外のマネジメント、人と人のコミュニケーションのための時間も、大幅に増えます。

正直、システム開発に慣れていなかったり、専任の情報システム担当者がいらっしゃらないお客様に、最初から、大きなテーラーメイドのシステム開発をするのはお勧めしません。

同様に、パッケージのカスタマイズも、30以上の機能を変更・追加するということであれば、やはり、お勧めしません。

むしろ、同じ見積金額であれば、パッケージのカスタマイズの方が、テーラーメイドよりもリスクが高くなります。

自宅を作る場合も、何度も作ると、作るコツがわかって、良いものができるというではありませんか。
システム開発も同じです。

小さなものを作ってみて、経験して、初めてわかることがあるのです。

お客様が思うことに、「システム開発会社はプロだから、注文しなくても、かゆい所に手が届くように、教えてくれるはず」というものがあります

確かに、プロフェッショナルとしては理想です。（わたしもそういう理想のプロのSEになりたいと常々思っています）

しかし、口に出して言わなくても100％理解される、本心を酌んでシステムを作ってくれる、そのような、システム会社を求めるのは、ギャンブルに近いと思います。


《システム開発を成功させる方法》

鉄則 その1．
システム開発は小さく始める。機能は30以下。

「SEには、どんな情報も開示する。システムに関わる基本データは、なるべく早く渡す。ゴミをとって整理してからという考えは良くない」

例えば、パッケージをそのまま導入するとしても、ユーザー側の作業というのは、簡単ではありません。

通常は、システムで使う各種マスタを登録する作業が、一番先に課せられます。

マスタ登録を画面から行う、もしくは、記入用紙に手書きする、はたまたExcelシートで作成する、他のシステムからデータを抜いてきてCSVを作成する。

マスタ登録作業には、こういった作業が考えられます。

データ加工だけであれば、開発会社に請負ってもらうことも十分に考えられます。

しかし、過去のシステム資産にどんなデータが入っているのか、また、それは正しいのか、使っていいのか、といったことを判断できるのは、ユーザー側のシステム管理者、もしくは現場でそのシステムをお使いの人であるはずです。

マスタ登録作業というのは、雑用でもありませんし、誰がやっても良い作業ではありません。

非常に重要な作業であると認識して下さい。

これを、新人など、業務が分かっていない人に任せたり、全営業マンに全部の得意先リストを紙やExcelに書かせて分担したものを自動で入れてしまったりとすることは、あまり良い方法とはいえません。

（もちろん、誰か業務が分かる人が責任をもって行う分には良いのですが）

たとえ移行作業は自社でやるという決まりになっていたとしても、開発会社側を引きずり込んで、「本当に、集めたデータで動くのか」「お互いにシステムについて思い違いはないのか」といったことを検証することが大事なのです。

また、そういったデータの収集は、本番の直前や、尻に火がついてからではなくて、システムのスケジュールが決まった直後に、設計書が出来るかどうかの段階で、なるべく早く行うべきなのです。

（システム設計書ができあがった場合に印を押しますが、この直前直後です）

というのは、ユーザー側から見て、「別に重要でないから」と思って言わなかったことが、システムとしては「超・重要事項」であり、それを聞いているのと聞いていないのとでは、大違いという場合があるのです。

システムの基本情報の真実を知らずして、満足のいく設計はできないのです。

以下、非常に私的、個人的意見だと思って聞いてください。

政府系の仕事に関与したときに「おかしい」と思ったことがあります。

それは、「彼らはマスタ登録を請負い業者に任せて、自分達では登録しない」ということでした。

確かに、優良企業で大会社の場合はアウトソーシングで、そういった場合もあります。

しかし、ほとんどの会社が少しでも経費節約のため、そして、システム構築にも自分たちで参加するために、マスタ登録は自分達で行っているのです。

他の仕事がどんなに大事であろうとも、国民のために仕事をしている人達が、自分たちの使うシステムを、金を使って第三者にお任せして良いのかと思ったのでした。

「厚生年金のシステムが雑であった」といったニュースを聞いて、本当にその思いが強くなりました。

感情的になってしまいました。

では、思い直して。

「ユーザーはマスタやデータの中身をなるべく早く、紙でもいいし、元のデータでもよいので、明確にSEに示すべし」

恥ずかしいから見せたくない、後からでいいや、は厳禁なのです。

そして、システムを成功させるために、基本情報は自分で整備し、チェックしましょう。

もちろん開発側も、アドバイスや、ツール作成など、できることは協力いたします。

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

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

だからこそ、プログラマの人件費が安いオフショアが話題になるし日本国内の開発においても、外国人を使って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つの金額が高くなる条件を書いてみました。

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

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

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

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

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

餅は餅屋に任せる。

しかし、餅屋を選ぶ責任はユーザーにあるのである。

「何を言っているんだ」とお思いでしょうか。

このメルマガでは、かなり突っ込んだこともお話していこうと思っているので、あまり触れたくないところでも入っていかざるをえません。

システム開発をどこかの会社に頼むといったときに、一番良いことは、その会社のSEを信じて、短期的、長期的な視点からのアドバイスを受けるということでしょう。

ところが、相手がアドバイスしてくれないとか、どうもそんなに経験がなさそうだといった場合には、その親方なり上司に相談できるようなところが望ましいでしょう。

システム開発でも何でもそうだと思いますが、お客様とSEの間に信頼関係が無いということが、徹底的に大きな溝を作ってしまうように思います。

初めてのシステム開発でSEへの信頼を持て、と言っても、おそらく無理でしょう。

だからこそ、2週間前の記事で、初めての場合は小さく始めるということをお勧めしたのです。

（参照：2008/06/17-Vol.00148「～ユーザー編　その2～」）
http://www.ilovex.co.jp/mobile_mailmagazine/2008/06/2.html

そこで、大事なことなのですが、「信頼を持てそうもない」ということであれば、素直に申し出て、早めに担当者を変えてもらったほうが良いでしょう。

とにかく、医者でも、建築家でも、SEでも、お客様と担当の間の相性が一番大切なんだと思うのです。