IT投資の意思決定において、「どのような仕組みを作るか」という機能要件と並んで重要なことは、「いくらで、いつまでにできる」というコストと時間の見積です。場合によっては、見積が機能要件を超える意思決定要素になることもあります。
無い袖は振れない、という言葉があるように、実際、どんなに素晴らしいIT投資案件でも、お金がなければ投資することはできません。逆に、少ないコストであれば、取り敢えず導入してみるか、という判断があり得ます。
IT投資の意思決定をする実際の現場では、IT投資にかかる見積を早い段階で正確に知るということは、極めて重要なことなのです。
見積の精度を向上させるためには、「今わかっていること」に「将来わかること」を加えなくてはなりません。例えば、システム開発のライフサイクルをウォーターフォールモデルとした場合、システムの構想段階で、次工程のシステム企画で明らかになることを知ることができれば、見積精度は確実に向上します。また、要件定義段階で、設計の要素を知ることもしかりです。極論すれば、システムをリリースしてから見積を行えば、すべてが今わかっていることになるわけですから、完璧な見積ができることになります。
ということは、設計まで行ってから見積を行い、それを持って意思決定すればいい、という選択肢が考えられますが、意思決定するということは、投資を見合わせることもあるわけですから、見積までにかかったコストをどうするか、という問題が出てきます。
この問題へのひとつの解として、共通フレーム2007などでは、システム開発の工程によって契約を分割することで、ユーザーと開発側のリスクをヘッジすることが推奨されています。なるほど、理にかなった手法です。しかし、ユーザー(組織)は、その理屈を知ったうえでも早く未来を約束することを開発側に求めてきます。現実問題として、いや、一般論ではなく、少なくとも私の所属している組織では、予算時にかなりの精度の見積を示す必要があります。なにしろトップが、「予算とは会社に対するコミットメントである」と宣言しているのですから、『アジャイルな見積もりと計画づくり』を共有するには相当な時間を必要とするでしょう。
私は実務を行わなければなりません。また、個人としてどんなに異なる意見を持っていたとしても、組織として意思決定されたことには従わなければなりません。当たり前ですよね、民法上の使用人ですから。
私は、予算という名の見積を会社にコミットメントすることを要求されているのです。そこで、IT投資かかる見積の精度を向上することは、私の重要な使命となります。
では、どうするのか?
これが現在の私の問題の中心です。そして特に、要件定義から生じる見積を高い精度にするためには、要件定義に「将来わかること」の何を加えればいいのか?(しかも効率的に…) そんなところを試行錯誤しているのが現在連載中の『Open Knowledge System』です。
RDRAベースの要件定義工程に、ICONIXプロセスを組み合わせることにより、予備設計という要素を加えることで、ユーザーが求める将来価値と現在価値のギャップを解消したい。上流工程に関わる開発者として、何としても成果を出したいという思いを実現するための「戦術を研究する」テーマです。
予想される結論として、要件定義のアウトプットを改善しただけではこの問題は解決しないでしょう。『アジャイルな見積もりと計画づくり』や共通フレーム2007に紹介される思想を組織に広めることも必要です。そうしたさまざまなアプローチが、いつの日か、相互理解による価値の共有という理想へ辿り着かせるのだと思います。そして、その理想のひとつが、私が「流麗なシステム開発の上流工程」と称しているものです。これについては、来年から本格的に活動を開始する予定です。
0 件のコメント:
コメントを投稿