ハード、ソフトウエア、ホームページの単体保守は過去のもの
保守費用相場にとらわれてはいけない理由

■ハードウェアメーカーが闊歩していた時代

私がIT業界に入ったのはWindows95が登場した頃です。新OSの登場に世間全体が浮き足立っていました。Webが世の中に浸透しだしたのもこの頃です。たいへんエキサイティングな時代でした。

当時、まだビジネスの世界ではワークステーションが幅を利かせ、サン・マイクロシステムズ、デジタルイクイップメント、シリコングラフィックスといったメーカー達が覇を競いあっていました。それらの会社は今はもうありません。

高額なワークステーションとそれを基盤とする多くのパッケージソフトウェアは淘汰されてしまいました。祇園精舎の鐘の声ですね。高額ゆえに保守料も大変高いものでした。やがてダウンサイジングの波に飲まれハードウェアの巨人達はまるで恐竜が絶滅したように忽然と姿を消してしまったのです。

■ソフトウェア保守料も常識だった

あの当時の革新的なソフトウェアパッケージはワークステーションをプラットフォームとしていました。その開発原資を稼ぎだしていたのは保守料だったのです。
ハードウェアもソフトウェアも保守料の月額相場は販売価格の10~15%。販売価格自体が数百万円ですから如何に保守料が収益の大きなウェイトを占めていたかお判りいただけることでしょう。

常に一定額入ってくる保守料は安定的なソフトウェア開発資金になります。保守料で開発されたソフトウェアはバージョンアップとして新機能が保守契約者に提供されていました。

これにより高機能のCADやCGなどが開発され高度な工業製品が作られたり、3次元のゲームメーカーが勃興したりしたわけです。
ある意味保守料が社会基盤になっていたと言っても過言ではないのです。

■クラウドの時代と保守

オンプレミスの時代は保守は必要不可欠でした。何故ならハードウェアは常に顧客のもとにあり、様々な運用環境で様々なOSのバージョンや様々な用途のアプリケーションが稼働していたのです。
企業は多くのカスタマーエンジニアを抱え、サポートを通じて顧客との密な関係を構築してゆきました。

やがてクラウドの時代を迎えます。
多くのアプリケーションはノートパソコンやタブレット、スマートフォンがあればネット接続で使える時代です。
それらの多くは無償で提供され広告によって維持されるようになります。
必然的に広告で収益を上げられるだけのパイを持つ一部の巨大企業に集約されてゆくことになります。従来型の保守という概念が入り込む隙が無いスキームが構築されてゆきます。

■新たな保守の形態

オンプレミスからクラウドへ移行したらある意味ウェブ上での振る舞いはユーザーの自己責任に委ねられるシーンが増えてきたと言えるでしょう。私達は巨大企業と個人単位で対峙しなければならなくなったのです。
ホームページの更新は勿論のこと、セキュリティ確保や細かいオペレーションに至るまで多くのことをユーザー自ら判断しなければならなくなったのです。

クラウドにおけるテクノロジーはどんどん進化してゆくのにユーザー側がついて行けなくなるシーンが増えてきました。そんな状況を第三者的な目線でフォローするサポート体制が求められるようになっています。

例えばホームページ制作ひとつとってもどのCMSを使いどのようにSEO対策を組んでゆけば良いのか、更新はどのような頻度でどこに気をつけてやってゆけば良いのか、適切なアドバイスができるメンターが必要になってきています。
そうでなければ日々押し寄せる情報の大河に呑み込まれてしまうのです。

■ITメンターとしての保守契約

かつてハードウェア、ソフトウエアごとに個別で締結されてきた保守契約は役目を終えました。その一方でシステム全体を俯瞰するITメンターとしての役割が求められています。複数のクラウドサービスを横串にして、最適な運用をアドバイスするだけでなく、日々のデータエントリーを含む運用そのものを担う役割のアウトソーシングサービスです。

もはや保守の枠組みを超えてコンサルティングの領域に入ってきているのですが、それはIT部門だけが対象ではなく実務に直結するものへと広がりを見せています。ITに関する知識不足をカバーするだけでなく、社内のITシステム全般のオペレーションをアウトソーシングする、つまり情報システム部を社外に持つような形態が今後増えてくるものと思われます。

有事の保険としての保守というよりは、業務委託して自立的に動いてくれるITパートナーです。業務委託ですから顧客は事細かな指示を出す必要はありません。日々の運用、SEO、セキュリティといった面倒な問題を黙っていても解決してくれるパートナーです。

■役割の増大にあたって適正な費用を

ここまで来ると保守というよりは業務委託の一形態になりますので実際にかかる工数とノウハウの提供に対して費用が発生することになります。月の拘束時間+技術料で難易度によって金額が変わってきます。

一般的には人日計算を根拠に費用が決まってゆくことでしょう。
単価は請け負う仕事の内容次第、請け負うエンジニアの能力次第ということになります。
例えば人月単価が60万のエンジニアであれば月の三分の一の拘束で20万といった単純な計算が成り立ちます。

それでも考えてみてください。
社内に専門のエンジニアを雇用するよりは断然安上がりになるのです。
人を育てる期間や費用もかかりません。ITはプロに任せて本来の業務に邁進することはビジネスの効率を高める一つの戦略に成り得るのです。

■パートナーの選定基準

もともと保守という言葉はシステムトラブル時の保険のようなイメージですが、ここまでで述べてきたようにオンプレミスのウェイトは低下して、サーバは仮想サーバ、アプリはオープンソース、場合によってサービス全体が外部のクラウドをプラットフォームとするケースが増えてきました。

トラブル時の保守要員というよりはITシステム全般を俯瞰できるコンサルタントという位置付けになるため、請ける側も受け入れる側もつまりはパートナーとしての関係性を意識すべきでしょう。つまり請ける側は顧客の立場に立ってアドバイスや提案を迅速に行える能力が求められ、受け入れる側は単なる作業員としてではなく、ITメンターとして聞く耳を持つことが求められます。

顧客の役に立つことで対価を得る仕事ですから提供するノウハウや信頼の重さに応じて単価もアップしてゆく余地はあるでしょう。要はパートナーとして必要不可欠か否かが重要で、業務効率化で目に見える形で運用コストの圧縮がはかれれば、そこで単価アップも自信をもって要求できますし、また受け入れる側もそうした視点で金額は柔軟に考えるべきでしょう。結局保守費用を相場で考えること自体がナンセンスでサービスへの対価に応じて決まるのです。

システム開発工数見積もり方法の奥義を探れ!

■プロジェクトの成否はまず見積もりから

のっけから難しいテーマです。
見積もり金額の正確性いかんによってプロジェクトの成否が決まると言っても過言ではありません。

高ければコンペに勝てませんし、かといって安すぎればリスクヘッジできません。
ERP構築とか基幹システムが絡むものであれば数億の赤字プロジェクトなんてこともあり得るのですから大手SIerの単価が高いのもある程度はやむを得ないと思います。

一方でフリーエンジニアは数万円の案件を叩き合っているというのもこれまた現実であります。一人で開発できるレベルのものであればおおよその工数予測というのは経験から導き出されるものなので、受注単価はお客様が納得していただける算定根拠さえ示せればあとは人柄勝負かもしれません。

■システムの見積もり金額って何故バラバラなの?

ではある程度の規模を持ったシステムの開発工数算定について明確な指標というのはあるのでしょうか?
人月単価、ステップ数、ファンクションポイント等々色々手法はあるものの、管理工数や設計、テスト、打ち合わせなど製造以外の工数は結構多く、最終的な算定根拠は見積もり担当者の匙加減というのが残念ながら現状です。大手と中小企業や個人事業者では同じシステムでもヘタすると10倍くらい見積もり金額に差が出たりします。これは実際のところ瑕疵担保責任能力の有無による安心料が大部分を占めています。

お客様がどこに価値を求めるのか、目先のコストなのか、確実なプロジェクトの成功なのか、はたまた無難に波風立たずに終わることなのか、ご担当者の立場や指向によってそこは変わってくる訳です。わたし失敗しないんですといくらフリーエンジニアが叫んでも大手の体制には敵わないですし、逆に個人中小の小回りには大手は敵わないものです。

あなたが発注者側であれば開発業者に何を期待するかを、受注者側であればお客様が何を期待しているのかをしっかり把握する、その辺がおかしな見積もりに翻弄されないポイントになってくるでしょう。そのためにはどうすれば良いでしょうか。

■適当な見積もりには悲劇が待っている!

現在某プロジェクトに御意見番として参加しています。PMOなんて格好いいものではありません。
なんせプロジェクトの途中で呼ばれて参加したのですから。
先ずどんなシステムを開発中なのか把握するところからスタートしました。

社内SNSでこれまでの経緯が管理されているということなので一通り見ていったのですが、場当たり的な議事録だけでまともなドキュメントが見当たりません。
見積もり仕様書は? 要件定義書は? 基本設計書は?
このプロジェクト、web案件ではありますが、単純なホームページ作成の類ではありません。千万円単位の受発注金額であるにも関わらず、発注者側からも受注者側からもろくなドキュメントが出ていなかったのです。

アジャイルとか格好いいキーワードがありますが、千万円単位のプロジェクトはアジャイルで進行することはできません。
それは場当たり的というのです。
結局実態把握はしつこいヒアリングとその時点での成果物を見ることによって何とかなったのですが、案の定要求仕様に対して成果物は穴だらけ。検証するのも憚られるような代物でした。

■発注者側にも問題が。見積書請求前に必要なこと

そんなこんなで客観的な指摘をしていったことがきっかけで、お客様と業者の和気あいあいとしたプロジェクトの空気は吹き飛び、プロジェクトリーダー交代、基本設計やり直し、システムは作り直しとなりました。図らずも私はデストロイヤーとなってしまい、顧客からは感謝されたものの、業者側からは恨み辛みの嵐です。

ただ既に発注済み案件なので何とか予算内で収まるように仕様に対して色々首を突っ込みました。
難しいアルゴリズムで考えられていたものをweb標準のAPIに変える提案をしたり、システムそのものの単純化を提案することで、逆に業者側のプライドが喚起され困難な状況を何とか脱することが出来ました。

ここでお気付きになったかと思いますが、見積もり段階でも見積もり仕様書つまりRFP(提案依頼書)が必要だということです。
最低限のドキュメント作成は実は発注者側にも義務があって、小さなプロジェクトを対象とした下請法にもその辺は明記されています。要求仕様無きところに見積もりはありません。お客側から提示が無ければしつこく聴くしかありません。

■システム開発の上流工程と下流工程を切り離す!

発注者側の立場からすればそもそもRFPを書けるだけのスキルが無いよというケースもままあると思います。
そんな場合の解決策ですがITコンサルタントの活用が考えられます。
ある程度大きなプロジェクトであれば最上流工程を別で予算化するわけです。別に超高額なシンクタンクに依頼せよと言っているのではありません。
今はフリーエージェントのコンサルが結構いるので、1名分の人月単価で一定期間予算化し、そこで内部的に要件をしっかりまとめるわけです。

RFPがあれば業者側も安心して見積もりが出せますし、各社ごとの見積もり精度についてはコンサルタントがジャッジできます。

■予算化のための見積もり依頼

それでもそんな手順は踏めないよというケース、予算化の観点でアバウトな見積もりを依頼するされる場面は結構多いと思います。
今度は業者側の立場として考えてみましょう。

PERT(Program Evaluation and Review Technique)というスケジュール管理の考え方があります。
これは楽観的、悲観的、中庸の3つのケースを想定して工数算定を行うものです。予算化の段階であればバッファは許されると思います。
お客様に対してしっかりリスクの説明をして一応松竹梅を提示したうえで金額の高い方を出すわけです。
この段階でこれは高過ぎるとか色々顧客の反応は探れるわけですから最終的に相見積もりになった場合でも根拠を明示した適切な見積もり金額を提示できることでしょう。

あとは第三者のレビューを受けることもたいへん有効です。見積もりも第三者の視点にさらされればそれが適正か否か気付かなかった点まで指摘してくれます。

■結局工数見積もり方法の奥義はあるのか?

ここまで読まれて見積もり金額というのは発注者側の立場、受注者側の体制や立場によって大きく変わるものだということはご理解いただけたかと思います。フリーコンサルの活用やPERTや第三者レビューといった方法論もご紹介してきましたが、結局のところ工数見積もり方法の究極の奥義は存在するのでしょうか?

いい加減な見積もり依頼、それにもましていい加減な見積もりが無くならないのは、単純な話でお客様の側も請ける側も要求仕様が見えていないためです。本末転倒な結論かもしれませんがプロジェクトはヒアリングが全ての成否を握ります。お客様から要求仕様の提示がなければ訊いてください。しつこく訊く、それしかありません。それによってお客様が気付くこともあるでしょう。もしそこで回答を拒否されるようであればそのプロジェクトは請けてはいけません。リスクがありすぎます。

逆に発注する側の立場で考えた場合、何も訊いてこない、何も提案してこない業者を信用してはいけません。ただ金額だけで判断すればあとで思わぬ失敗の連鎖が待っています。結局のところ失敗しない工数見積もりの奥義はコミュニケーションに尽きると思います。

難しい方法論を求めていた読者には肩透かしかもしれませんが、コミュニケーションがシステム開発に限らずビジネスの本質です。皆さまのプロジェクトの成功をお祈り申し上げます。