SEそのものの投資効果

Systems Engineering, KM_Metrics

Abstract#

SE活動に対する投資を正当化しようとした際、マネージャーは、Return On Investment、つまりROIを求めることが多いです。その件について、ここでは、議論しています。結論は。。。意味のある投資効果の定量化は非常に難しい、ということ？

Topic#

みんな数字がほしいのです。もし、SEを導入した効果の金額がでてくれば、これほど楽な決断はありません。投資額と、その導入効果の額を比較し、後者の方が高ければGO、低ければNGとすればいいのです。

定量的な効果はわからない#

[1]の論文の中で、過去の研究で、SW-CMMをやれば1ドル当たり、4ドルから8.8ドルのReturnがあるという結果に対し、Sheardさんは、Returnが何を指すかあいまいだ、サンプルの数が足りない、偏見が混ざっている、環境に依存する話で、一般的な環境に適用できる話ではない、などと言って、切り捨てています。上司を説得する材料の一つになりえる情報だとは思いますが。彼女がいいたのは、要は、そんな便利な数は存在しないんだと、そういうことです。
無理して具体的な数字を作っても、誰も信じないよ、ってSheardさんは言います[1]。いや、やらねばならぬときがあるはず！

じゃあどうするか#

でもマネージャーを投資にGOを出すように説得しないといけない。そんなときは、以下の方法で行けばいいんじゃないか、とSheardさんは提案してます。ようは、意思決定をサポートする材料を出せばよいという考え方と理解します。
前年度SEにかかった経費とか（うーん、それは、初期投資をする時に使えるのかな。。）。投資の正当化する数字であれば、効果を直接金額で表していなくてもいいんじゃないかと。数字が事実に基づいていることが重要。うーん、それが難しいんだよね。つまり、目標と評価指標をきめて、目標が達成されるようにその数字を見せようということか。まあ、普段からやっていることだよね。
具体的な効果を数字でみせるのではなく、小話で伝えようということ。つまり定性的に伝えるということかな。説得材料として、例えば、技術的なジャーナルにある実際にあった事例を紹介して、「うちの状況ともよく一致していて、これをやれば、うちにも相当のメリットがあるに違いない！」って説明するのでしょう。
競合相手がCMMIのレベル3を取ったよ、うちも取らないとまずいよ、とかいって説得する。まあ、よくある話でもあるけど、なんか、誰もやってなくて、やればアドバンテージをとれるような施策は、難しそう。

こんな経験があります。自分が発注側の立場で、受注側の立場の人に言われたこととして、「うちの中にも抵抗勢力がいるんですよ。外部から圧力かからないとなかなか動きません。」うまく利用すれば、ですね。
SEで何をしたいのか。何を改善したいのかを明確にして相手に伝えることが重要。同じような例として、ISO9000を取るために品質改善を行うのではなく、品質改善のために改善活動をする、など。
問題を示し、その問題を解決するためにSEをやる！という。リソースが不足していて、仕事がうまく回っていません。SE活動をして、プロセスを改善し、問題を解決します。とか。。。負のスパイラルに陥ってます！何とかしないといけません。SE活動をすれば解決できます！とか。。。
常に問題の根本的な原因がなんなのかを考え、正しく解決に向けたSE活動をしましょう。
最初からあまり大規模に行わず、小さくやって拡大させていく戦略をとりましょう。うんうん。
自分たちの成功と失敗から学びましょう。うんうん。でもなぜこれがここで出てくるのかな。
ようは、無理してお金に落とし込まなくてもいいんじゃないかということと理解。効果を無理してお金に換算するのがあまり意味がないということについては、かなり賛成できる。自分がこれまで行ってきた効果の定量化、いくらCostを削減できたかという定量化は、はっきり言って、自分でいうのもなんだが、たくさん仮定があって、あまり意味のあるものだとは思っていませんでした。ただ、どこからかの要求に従って仕方なく無理やりやっていたことでした。ただ、本当に全く無駄なのでしょうか。チャレンジすることに意味があったりするのでしょうか。そういう意識を持つことが重要だったりしなのでしょうか。評価・・・悩みは尽きません。

Reference#

  1. [#1]Sheard, Sarah A., Miller, Christopher L., "The Shangri*La of ROI" In Proceedings, Tenth Annual International Symposium of the International Council on Systems Engineering. Brighton, England: June 2000.