コラムカテゴリー：ITコンサルティング
ユーザー企業(主にITを主管する情報システム部門)に所属する方で、ITベンダーからの提案や報告に対して、以下のような主観的な情報に基づいた判断を行っていませんか？
「今まで付き合っているITベンダーだから、内容はよく分からないけどきっと良いシステムが出来上がるだろう。」
「なんとなく見積り金額が高い気はするけど、世間一般的に見て高いか安いか分からない。今までと同じ単価だし、この金額でお願いしよう。」
ユーザー企業の業界、IT業界の動向は日々変化しているにも関わらず、「今までと同じだから問題ない」といった主観的な情報を基に判断した結果が正しいとは限りません。では、適切な判断を行うためには、どのように妥当性を確認すればよいのでしょうか。今回は、妥当性を確認するための観点や方法についてご紹介させて頂きます。
妥当性の定義と必要性
そもそも「妥当である」とは一体どういう状態のことを指すのでしょうか？
それは、「要求を満たし、かつ『ムダ・ムラがない状態』」と定義できます。
具体的に言うと、年に数回しか発生しない例外的な業務(業務の重要度も低い)に多額の投資をして高機能なシステムを構築する場合、要求は満たしていますが必要以上に品質を上げ、コストをかけ過ぎているため、妥当ではないといえます。ここでは極端な例を挙げましたが、要求が満たされていれば良いと考え、品質やコストが妥当ではないケースは往々にしてあるため、『ムダ・ムラがない状態』になっているかという点がポイントとなります。
では、なぜ妥当性を確認する必要があるのかというと、ITベンダーは自身の提案や報告に対して客観的に評価することが出来ないからです。ITベンダーの立場に立って考えると、お客様に対してより良いものを提供したいという思いから、必要以上に品質を上げコストをかけたシステム構築の提案を行ってしまう可能性があります。したがって、自社で客観的に評価する必要があります。
妥当性確認の方法
自社で客観的な評価を行うために、どのように妥当性を確認すればよいか、その観点と基準について紹介させて頂きます。
（1）観点
妥当性確認の観点の一つとして、今回はモノづくりにおける重要な要素である『QCD（※）』を取り上げます。
※ Quality（品質）、Cost（コスト）、Delivery（納期）の頭文字をつなげた略語。
次に、QCDの各観点で確認する指標を客観的な情報の中から選択します。客観的な情報は、経済産業省や一般社団法人 日本情報システム・ユーザー協会（以下、JUASという）、独立行政法人 情報処理機構（以下、IPAという）等から公開されている調査結果が該当します。具体的な指標例は以下の通りです。
Q（品質）
- 新規システム構築時
-
- テスト時のテストケース密度や障害密度（※1）
- 画面数・帳票数と全体工数との比率（※2）
- 既存システム運用時
-
- 重大障害、軽微な障害の発生件数（※3）
C（コスト）
- 新規システム構築時
-
- ITベンダーの要員単価（※2）
- 工程別工数比率（※1）
- 既存システム運用時
-
- 維持・メンテナンス費用(＝IT投資金額)（※3）
D（納期）
- 新規システム構築時
-
- 工程の期間比率（※2）
※1 参考：IPA 報告書・成果物（リンク切れ： http://www.ipa.go.jp/sec/reports/index.html）
※2 参考：JUAS 調査研究資料（リンク切れ： http://www.juas.or.jp/servey/index.html）
※3 参考：経済産業省 情報処理実態調査資料（廃止済み）
（2）基準
妥当性を評価するためには基準が必要です。「妥当である」とは『ムダ・ムラがない状態』であり、多過ぎず少な過ぎない、つまり適切な範囲に収まっている状態を指します。よって、適切な範囲に収まっていれば妥当であると評価出来ます。
では、適切な範囲はどのように設定すればよいのでしょうか。一つの考え方として、客観的な情報である世間一般の実績を基準として捉え、その実績と乖離がなければ適切な範囲に収まっている、ということがいえます。世間一般の実績とは、先ほどご紹介したIPAやJUASから公表されている情報であるため、これらの情報を判断基準として活用すべきである、と考えられます。
以上から、（1）で選択した指標と（2）の基準を比較することで妥当性を確認することが出来ます。
妥当性確認後にやるべきこと
妥当性の確認方法について述べてきましたが、ユーザー企業にとって妥当性確認はあくまでも手段であり、最終的には妥当な状態を目指す必要があります。したがって、妥当でないことが分かった場合には、何かしらの対策が必要となります。
ここで注意したいのは、以下の例のように表面上の問題に対して対策を打ってしまうことです。
- 世間一般の実績より自社の障害数が大幅に多く、品質が悪いため全機能に対して追加テストをする。
- 世間一般の実績より自社のIT投資金額が大幅に大きいためITベンダーへ値引き交渉をする。
上記例では根本的な原因に対する対策になっていないため、効果が出ない可能性があります。
どこに問題があるのか（問題の特定）、なぜ問題が発生するのか（原因分析）を検討した上で、根本的な原因に対して対策を打つべきだということです。
然るべき問題解決の手順を踏むことで、着実にムダ・ムラのない妥当な状態を目指すことが出来ます。
まとめ
今回は妥当性確認の方法をご紹介させて頂きましたが、上述した観点や基準が全てではありません。
企業が使うシステムには企業ごとに特性があるためです。
「今までと同じだから問題ない」、つまり今までと同じ状態が妥当であるという考えをお持ちであれば、 「今までと同じだけど、本当に問題ないのか」という観点でぜひ一度妥当性の確認をご検討されてみてはいかがでしょうか。
また「妥当性を確認したが、問題はなかった」というケースも当然考えられます。この場合、対策を打つ必要はないため、妥当性を確認することに何の効果もなかったと思われがちですが、目に見えない効果を得ることが出来ると考えられます。それはITベンダーとの信頼関係です。ITベンダーにとっては自分達がやってきたことが正当に評価されます。一方、ユーザー企業にとってはITベンダーに任せて良かったということが分かり、お互いを認め合うことで信頼関係が強くなるためです。
最後に
「そうは言っても現業が忙しく手間をかけられない。」
「理屈は分かるが本当に効果が得られるのか、まだ分からない。」
このようにお思いの方がいらっしゃいましたら、ぜひ弊社にお手伝いさせて頂ければと思っております。また、妥当性確認後の問題解決につきましても、併せてお手伝いさせて頂ければ幸いです。
関連サービス
2014年10月19日 (日)
青山システムコンサルティング株式会社
