（完）ソリューション・システム：事例売上高ITコスト比率を下げるには

photo by kirtaph

続ソリューション・システム：事例売上高ITコスト比率を下げるには - usabo's diary

の続きになります。3部作になってしまいました。

3. 解決策を検証・評価する

1つ1つ検証の方法をあげてみます。

1.個別解決策の検証ーファクトベースでチェックする

1. 調達単価の削減

相見積り、コンペの競争

→これ自体がある種の検証です。

一社の言い値ではなく同業他社の単価を見た上で

価格の確からしさを評価します。

より安い単価への乗り換え

→上級SEではなく若手でもできないか、

国内ではなくオフショアでもできないか、など考えられますが

”品質を下げずに”というところが難しいのが実情です。

あまりユーザ企業側から持ち掛けることはすべきではないでしょう。

スケールメリットの適用

→アウトソーシングなどで多くを委託している場合は

交渉の余地があるかもしれません。

2. 開発生産性向上

標準化、部品化

→これによりどれだけのコード数、ステップ数が減るかを見た上で

同種の開発規模の修正の前後の工数比較ができるとよいです。

ツール化

→ソース自動生成やテストの自動化など生産性向上が見込めるツールは増えました。

ただし実開発でどれだけ工数削減につながっているかは使っている開発者のスキルにも依存するので実績工数で比較するほうがよいです。

3. 運用業務の効率化

手順整備

→単価交渉などとは違い地道な作業です。ベンダ側もユーザ側も協力して対応が必要です。コストインパクトは大きくはありませんがノウハウ蓄積や障害時対応など後々に響いてきます。

ツール導入

→影響分析、チェックツールやテストの自動化ツールです。開発時に使っていたものを引き受けることもあれば稼働後に導入する場合もあります。いずれにしても実績工数の前後比較です。

4. 要求仕様の見直し

代替手段のある仕様の削減

→ユーザ企業のIT部門の力の見せどころです。ユーザ部門は現行と変わる部分は難色を示すことがありますが業務をわかった上で代替手段が提示できるものは削減するのも一案です。

利用頻度の低い仕様の削減

→現行機能の利用頻度や稼働後に実際のアクセスログを使って利用頻度を見てむやみに改修や機能追加を行わないことです。

5. サービスレベルの見直し

サービス時間の見直し

→本当に24時間365日必要かどうか。提供している側も人なので体制を組む分だけコストはかかります。

構成やリソースの見直し

→過剰な構成やリソースになっていないか。

6. 監視体制整備

メトリクスの取得・分析

→過剰なメトリクスを取得していないか。

2. 総合解決策の評価ーハードとソフトの両面から判断する

上記の個別策を最低限実施したものと最大限実施したものなどいくつかの案を用意します。その上で下記の観点で評価を行い、案を決定します。案を決めたら後は実行するのみです。実行段階になっても新たな課題が出たり想定と状況が変わることもあるため、必要に応じて評価、検証は実施します。「ベスト」を考えるよりも、「ベター」を実行です。