案件・業務の進捗記録と備忘録

「費用対効果」は、基幹システム導入を始め、ウェブ制作・公開、はたまたSEOにまでIT業界でも頻繁に使われる言葉ですが、世間一般では、どのように考えて「使って」「受け止めて」いるのでしょうか。そんな疑問から、当方なりの考え方や波及する事柄について書いてみたくなりました。サービスを導入・もしくは利用しようとする際に、その効果や利得を事前にどう判断するか・についても、触れてみたいと思います。費用対効果と言う観点からのプラス・マイナス評価よりも、その期待値や事後の運用などを考える内容にしていければと思います。

根本的に、費用対効果は対価及び得られた利得を材料として、数量化できる結果から判断します。また、「あらゆる効果は求められる利得に最終的に反映されるべき」と言う考え方から、アイデンティティ・印象・イメージなど無形のものに対しては、費用対効果の評価に含めないものとします(※「当社に広告を出せば貴社のイメージアップになります」のような場合、実際にそのイメージアップという材料が売り上げに繋がったことが証明・反映された時点で評価されると考えておきます)。

費用対効果という言葉自体は頻繁に・また色々なケースで使われていると思われますが、当方は以下のような見地で考えています。

• 基本的に結果から得られるものです。予測は立証が不可能で、ものごとには「絶対」ということがないからです
• 数量化することで、比較材料になります

「広告を出す」という件について考えてみましょう。広告を出す＝商品が売れることが、唯一の効果指標になります。つまり、広告を出した結果が売り上げに直結されなくてはなりません(※広告効果を期待せずに広告を出す、節税やお付き合いのような例は除外します)。

明示できる費用対効果

●●円の対価で広告を出す　→　その広告によってもたらされた営業利益が××円であった

この場合、xx円 / ●●円 の数量化と時間的トレンドなどの条件を加味して費用対効果として判断ができます。ただし、先に述べましたように、このように数量化して判断する費用対効果は、実際に当該サービスを利用してみなければわかりません。そして、事前の目論見や提示される効果や予測は、期待感やセールストークで往々にして大甘に出されるものです。

それでは、当方の考え方とは別に、世間一般ではどうかと考えると、当方のように「数量化した結果のみを費用対効果というデータ値」として使っているケースは、それほど多くないのではと思います。というのは、費用対効果やコストパフォーマンス、ROIと言ったキーワードが、結果が出る以前の営業トークで使われるケースが多いことです。それでも、費用対効果を●●出せます！ROI125をお約束します！というトークは聞いたことがありませんけれども。

そのことを考えると、費用対効果という言葉が最終的に機能しているのは、「納得感」に結びつくような気がします。
「この内容でこれだったら費用対効果は抜群です」
「この事例で過去に費用対効果が出ていない企業はありません」
「費用対効果での収益性は10%アップすると予測できます」
「定量的な費用対効果が見込めるはずです」
「導入企業の8割が費用対効果を感じたとおっしゃっています」
などなど…よく聞くと思いませんか？

ということで、「費用対効果」をあまり気にしてもいけません。と言うのは少々乱暴ですが、具体性を持った数値になるのは事後のことで、それも純粋な抽出の難しさや、評価方法・関連する要素の複雑さなどを考えれば、ある程度の材料で判断を下さざるを得ないからです。相手が「費用対効果」とか言い出したら、まあセールストークのひとつぐらいに考えておくのがいい・というのが、当方の受け止め方です。費用対効果という言葉がセールストークや理論武装に使われることが多いという認識です。

費用対効果というデータは、例えば業務の効率化や人材育成などでは、その効果測定は難しいですし、そもそも他の環境下で得られたデータに踊らされてもよくありません。当方においても、データは分析や予測のひとつの材料ではありますが、全てではないことを常に念頭においています。

--

そこから少し進めて考えると、費用対効果などの言葉に頼ることのない、自分なりの事前調査や吟味が必要になりますね。それには須らく色々なファクターや環境などを考えなくてはなりませんが、誰もが実際にそこまで考えることができるかというと、なかなか難しい。だからと言って、事前の判断を無視したり誤るわけにもいきません。そこで、先ほどの例ですと、まず「広告を出すべきか？そして、そこに出すべきか？」という段階での材料が必要となるわけです。それを、いくつか列挙してみましょう。もちろん広告に限らず、サービスでもいいし提携先の選定でも、色々なケースに応用できます。

1. いろいろ調査をしましょう
   ※サービスそのものよりも、むしろ周辺の状況など。見えなかったものが見えます。
2. 即答は控えましょう
   ※冷静に考える・誰かに相談する・コンサルタントなどに諮問する、そういった時間は必要です。
3. 契約書のドラフトをよく読みましょう
   ※当方の場合、若いときに法務の人間が比較的近くに友人としておりました。その薫陶で、「契約書というものが如何に重要なものなのか・契約書にサインすると言うことがどれだけの重みを持つか」ということを、しっかりと身につけることができました。海外との取引ですと、その重要さは国内よりももっと大きくなります。
4. 有利・不利な契約条項に注目
   ※あまりにも身動きが取れない契約・一方に有利すぎる契約条項があった場合、契約の有効期間と双方の役務と対価を吟味しましょう。
5. 投資を惜しまないこと
   ※考えもなくただただ値引くなと言うことです。判断する目が曇ります。
6. (おまけ)投資を最終決定以降は後悔をしないつもりで
   ※後で嘆いても意味がありませんし、自分の事前調査や決定に責任を持つと、以後の冷静な判断や決断が導き出せます。

--

多くの人が、実際に手を出してみてから、「お、これは正解だった」とか、「ああ！しまった！失敗した！」と考えます。ITではないですけれども、投資話の詐欺や出資法違反の事例など、いつも絶えることがありません。多くは心の大元に欲があって、その欲をくすぐる手練の営業マンの甘言に乗っかったせいなのですが、今の世の中は「自己責任」の及ぶ範囲が、もっともっと広くなっています。事前の調査はできるところまでしっかりとやったほうが良さそうな時代です。

長い間使っていたサーバを新しくしました。１月前半の作業割合としては、このサーバ更新がかなりを占めたのですが、どのような理由にせよ、サーバを換えるにはコストが掛かります。linux関連の記事では、サーバを替える際の技術情報が多く取り扱われるのが通例ですが、この記事では、経営者や部門責任者を対象に、「コスト管理」について、当方でのリプレースの流れを追いながら、さまざまなケースを併記してみたいと思います。

サーバを換える理由は？

当方の今回のケースでは、機材の一新とLinuxの入れ直しとなり、以下を目論見としました。

• 機材の老朽化対策(※壊れていたわけではありませんが、連続で３年程度稼動していました)
• OSの基本(カーネル)、各種サーバソフトウェアのアップデート

まず、機材を換えるとランニングコスト(光熱費)の低下＋パフォーマンスの向上が見込めます。ハードウェア技術の進化に伴って効率的な運用が可能になりますので、基本的にサーバは新しいほうが良いと考えられますが、これから述べるサーバ調達コスト・ソフトウェアのインストール等の直接経費、また社内でプロジェクトを走らせることによって発生する損失、そういった事とのトレードオフで検討する必要があるでしょう。当方での考えの流れを参考までに。

1. 機材は古いが、ハードウェア監視情報・目視による検査では、異常の要因は見つからない
2. ただし、サーバのハードウェア自身が古いために、更新でランニングコストを下げることが出来るだろう。
3. 同時に、明らかなパフォーマンスの向上が見込める
4. メンテナンスモードに入っているソフトウェアが動作している。それをバージョンアップするためには、基本のカーネルからのアップデートが必要となる
5. 以上から、サーバの変更を実施することに決定する
6. では、リプレースのコストはどうだろうか？機材調達については●●円
7. では、リプレースに伴う実務、コストの発生と損失見込はどうだろうか？

サーバを換えるために、どういったコストを見積もるか？

ハードウェア調達などの直接経費となるものについては、見積もりが簡単なので省きます。問題は、間接的に発生する内容です。計画を実施する際に発生するコスト・計画を実施することによって発生する損失を考えます。いずれも、サーバ運用・メンテナンス部門があれば、その部門内での年次計画などでコストを算出せざるをえませんので、問題はありません。サーバ運用を外注に委託している場合も、社内的なコスト管理は易しくなります。それが、パソコンに詳しい人などが中途半端に管理を兼任している(※ないしは業務命令で兼任させられている)場合、問題が発生します。そのような場合、技術レベルの問題もありますが、躓く原因はどこにでもあります。中小企業の場合、「兼任」においてその役務を担える環境下であるかどうか・その「兼任」が組織運営として失敗しているかどうかが問われます。残念ながら、トラブルの例を見ると、「兼任」は曖昧な環境下で行われている例が多く、兼任の負担などで、社外に管理させるよりも余計にコストがかかり、また波及して損失を発生させてしまうケースがままありますので、ご注意ください。では、当方の例ではどのように考えて進めたかを例示します。

1. 直接担当者(※自分)の能力であれば、最終的に稼動が完了するまで4時間@1人×5日、更に検証や調整などに2時間@1人×3日程度で完了するだろう
2. サーバリプレースは直接利益を出さないが、その期間に対する直接担当者(※自分)の間接作業として実施できる
3. 計画の上では、リプレース業務に携わっている間、直接担当者(※自分)の他業務には支障が出ないと予測できる、即ち損失はほぼ無い
4. サーバに依存している直接利益は損なわれない(ゆらぎ範囲である)

「予測できない」問題とコストの発生があることを「予測する」

スムースに移行が進まないケースもありますので、時間コストにゆとりを持たせることが必要です。取り分け、ソフトウェア関連でのコンフィグレーションやり直しやデータベースの移行、プログラミングなどの作業が発生する場合、それらの作業がリストアップされていたとしても、習熟度や環境によって、時間が掛かる場合があります。

問題を発生させないために

• コスト算出をきちんと行う。出費はコストに含まれますが、出費＝コストではありません。
• 必ず着手前にプランニングする
• 担当内容の役務を明確に

サーバを変えるといっても、業務としての考え方自体は、他と変わりありません。不確定要素が少ない分、むしろ簡単だといえます。目的を決めて→失敗しないように計画を立てて→できる人が行う・だけなので、プロジェクト作成とコスト算出をきちんと行えば、納得のいくコスト計算とスムースな移行が効率よく得られるでしょう。

参考までに。当方が入れ替えたOSはCentOS5.1(32bit)＋RAID1による冗長化、メールサーバはPostfix2、データベースはMySQL4→5、ウェブ関連としてApache1.3+PHP4→Apache2+PHP5です。バージョンの変更に伴って、データベースのダンプと読み込み・PHPコードの若干の書き換えの手間などが若干発生しましたが、昔からの情報収集や準備によって慌てることもなく完了できました。気になっていた消費電力は50W→37Wとなり、また新しいハードウェアによる底上げで、サーバのパフォーマンスが向上しました。心なしか、sshで接続していてもレスポンスがいいような気がします。