提供するものの価値
過去に何回か書いていますが、我々はパッケージシステムを開発し、ライセンス
を売って、カスタマイズやデータ整備、研修などの導入支援を行い、運用保守を
行うITシステム屋です。
同業他社にはスクラッチ開発を請負うSIerやパッケージソフトを売るベンダー、
クラウドなどのサービスプロバイダなどがあります。
時には提案コンペで張り合ったり、アライアンスを組んで自サービスの付加価値
をあげたりしていますが、共通していえることはお客様に情報システムを使って
もらって対価を頂いている、ということでしょう。
では、その対価の妥当性はどうやって決まるのでしょうか。
むかし、親会社のソフトウェア開発が主な仕事だったころ、そのころ親会社は大
規模システム化プロジェクトを推進しており、当社にもある機能の開発が打診さ
れました。そこで要件をヒアリングして工数を洗い出し、２億円弱の見積りを提
示したのですが、親会社は納得せず、諸事調整がはいり結局１臆をきった金額で
受注、開発を進めることになりました。
その際に聞いた、当時当社の社長の言葉が衝撃的でした。
「うん、まぁ、そうだろうね。その業務は年に一回少人数で行う業務だから、そ
んなにシステムへの投資価値はない。システムの導入効果は２千万円くらいかな」
当時の社長は、親会社出身だったので、業務に精通しての発言です。
開発にかかる作業を積上げて（それが妥当な作業と金額だとしても）も、必ずし
も、それがそのままお客様が必要としている価値にはならない、ということを教
えてくれた出来事でした。
言い換えると、システムなど毎回一から作っていたのではその作業量はバカにな
らず、積上げた作業に対する金額では、お客様にとっての投資対効果としては割
に合わない、ということになります。
そこで、スクラッチ開発のビジネスモデルはやめて、パッケージシステムを開発
することで業務を共通機能化してお客様間で共有。開発作業は個社固有の業務機
能の作成、いわゆるカスタマイズに集中させる、ことで短納期、低コストでシス
テムを導入させる、というビジネスモデルに変更しました。しかもパッケージ部
分はいつでも動くので、導入前からお客様はシステムのイメージが付きやすくFit
＆Gapしやすいメリットもあります。
当然パッケージなので、持っている機能がカバーしている業務を主としているお
客様しか対象にならず市場は狭くなるのですが、マッチしている業態のお客様で
あれば、一から開発するよりコストメリットがでます。
ところが面白いことに提案コンペなどでは、スクラッチ開発を提案している他社
の方が採択される、ということが少なからずおこります。当然、見積価格は当社
よりも高く、ひどいときには一桁以上違う場合もあるにも関わらずにです。
そのような場合、できる範囲でお客様が他社を採択した理由を情報収取をしてみ
るのですが、おおむね以下のような回答があります。
・先方（スクラッチ開発提案会社）は、ドキュメントの作成分までしっかり見
積に入っていたから
・当社にとって重要な基幹システムなので、パッケージだとブラックボックス
化しそうで不安だから
・安すぎて不安
提案コンペでは最初からどこに開発させるかは決まっており、その体裁づくりに
実施される場合もあるので、もらった回答が必ずしも本心とは限りませんが、そ
れにしても求められている価値の違いに驚かされます。お客様は情報システムを
使って、そこから得られる効果によって投資対効果を判断する。言い換えると、
情報システムの開発期間は何も生まないので、なるべく金をかけず期間を短くし
たいのではないか、と考えていたのですが、意外とそうではないお客様がいらっ
しゃるのです。
少し穿った見方をすると、このような判断をされるお客様は、情報システムを丸
投げしたいお客様である傾向があるように感じます。情報システム部門が窓口に
なっている場合、ユーザ部門の業務がわからないので開発や運用のみに重点を置
いている場合。ユーザ部門が窓口になっている場合、現業の忙しさでシステム化
など対応できない、システムがわからないので何をしてよいかわからない場合。
部門を跨ぐシステムの場合、どの部門が責任部門かわからない場合などは、上げ
膳据え膳でパッとシステムができるようなことを期待しているのでしょう。
この辺りは良し悪しの問題ではなく、お客様が何を求められているか、というこ
とだと思います。情報システムはユーザが使うこと以外にも、開発、導入、運用
など付帯作業が発生することは事実なので、何を重要視するかはお客様の判断次
第です。高層階の夜景のきれいなフルサービス高級フランス料理店に行くのか、
早くて安くて旨いけど、セルフサービスな高架下の定食屋を選ぶのかはお客様の
シチュエーション次第。
しかし一方で、お客様自身が自分たちが本当に必要としている価値を見誤って、
壮大な無駄を引き起している状況を目にすることもあります。
綺麗な夜景に最高級のサービス、高価な食材に名のあるシェフが作る料理。あこ
がれではありますが、空腹を満たすには量が足りないかもしれません。もしかし
たら一晩の贅沢のために、次の給料日までカップラーメンで過ごさないといけな
いかもしれません。それが本当に望んでいる事ならばよいのですが、実のところ
本当に必要としている価値ではないことの方が多く、後から後悔する破目になり
ます。しっかり要件定義を行い、しっかりドキュメントを作成し、しっかり試験
を行ったけれども出来上がったシステムは使えなかった、などという話は決して
珍しいものではありませんし、無理して高い金を払って買ったシステムが、一度
も使われず眠ったままになってる、などという話はざらにあります。
どんなに夜景がきれいでも、どんなにおもてなしサービスが素晴らしくても、料
理が粗悪で不味ければ、それはそれでがっかりするのは当たり前だと思います。
やはりシステムは使ってナンボ。いくらドキュメントが充実していても、いくら
納期を順守しても、バグのない完璧な品質でも、使えないシステムに意味はあり
ません。
最後に、情報システム導入から得られる、あまり気づかれない価値について一つ
ご紹介。
以前のコラムでも一度ご紹介させていただいたお客様のことになりますが、この
お客様のシステム部署はとても保守的で、システム開発はW／F方式でないとだ
めだ。クラウド利用は親会社がダメと言っているからＮＧ。要件定義をベンダー
にやらせて手戻りが出ないようにしろ、要件定義、設計、開発の各フェーズにお
いては必ずドキュメントを作成して役員の承認をとれ。等々、慎重に慎重を重ね
た教科書通りのやり方を方針としていました。
当然、情報システム開発の工期と費用は莫大に膨らみます。しびれを切らした業
務主管部門が自分たちでいろいろと調べ、同業他社に実績のあった我々のシステ
ムを見つけ、導入を決めてくれました。機能要件は同じで、お客様固有の機能を
カスタマイズすればよいのでアジャイルでの開発と、サーバはプライベートクラ
ウドにすれば安くてすむ旨、提案しました。
これに反発したのがシステム部署。業務主管が自組織のみで使うシステムですが、
システム導入となるとシステム部署が権限を持つようで、要件定義をしろ。要件
定義をして定義書を出すと、あれの記載がないからやり直せ。クラウドはダメだ
からグループ会社が提供しているホスティングサービスを使え。見積をとると、
ホスティングサービスのサーバは発注から納品まで半年かかり、加えて半導体不
足だからさらに納期が延びる可能性がある、等々。
ついにブチ切れた業務主管が、新制度も始まっているのにそんな状況ではいつま
でたってもシステムが導入できないではないか。どう責任取るんだ！
だったらお前ら勝手にやれ。システム部門は責任を持たない。
あくまで想像上のやりとりですが、どうもこのようなやり取りがあったようで、
業務主管部主導でシステム導入を進めることになりました。
ここからが、すごかった。
業務主管部はアジャイルで進める、と宣言すると、まずは親会社に本当にクラウ
ドはダメなのか、ということを確認。今回の範疇なら問題ないと回答をもらい、
同じグループ会社が提供しているクラウドサーバを選定して導入を決定。専用線
接続や現場からのシステム利用等を諸事できるように調整し、連係が必要となる
他部門との調整。必要なところはRPAを導入し、業務マニュアルの整備、現場へ
の説明会、すべてを自分たちでやりきりました。なにも丸投げしていない！
業務の事や、他部門との調整については自分たちで出来るでしょうが、クラウド
の導入に関してはテクニカルな話がどうしても必要になるので大変だったと思い
ます。特に初めて導入する社内においては、それなりの説明が必要になります。
おかげで当初検討していたホスティングサービスに比べて初期費用が1/10。納期
が1/5（遅延なし）を実現しました。
最初のころはシステム部署があれをしろと言った、これはダメだと言った、依頼
したことをやってくれない、といっていた業務主管部がシステム部署の支援なく
自分たちでアジャイルやクラウドなど新しい方法を導入して、システムを作り上
げた。これは将にこのお客様の組織文化のパラダイムシフトではないでしょうか。
特にDXが求められている昨今、業務とITは不可分です。そういった意味では、
今回の件でこのお客様はDXの下地ができた、と言えるのではないかと思います。
システム導入から得られる価値。これが組織文化のパラダイムシフトであったこ
と。この気づきはとても重要である、と私は考えています。