CMMI、実践中間報告！(第2回）

以前にこのコラムでご報告した、CMMIレベル認定に向けた弊社の取り組み。
開始から約半年が経過した今では、各プロセスエリアの定義も固まりつつあり、間もなくプロトタイプ運用が開始されようとしています。今回は、取り組み中で持ち上がった問題点の紹介などを交え、第2回の中間報告としたいと思います。

プロセス定義を進める上での大きな壁

プロセス定義を進めてきた中で多くの難題はありましたが、その中の一つが次に説明するようなCMMI適用によるマネージメントコストの問題です。

弊社は会社概要をご覧頂ければお分かりの通り、これまでCMMIのレベル認定を受けてきたようなソフトウェア開発各社と比較すればかなり規模の小さい企業です。ですので、社内にマネージメント専属部署があるとは言え、専門領域ではプロジェクトに関わるスタッフ各々が役割に応じて作業コストを賄っていかなければならず、現実的にどの程度までの作業コストを見込めるかという非常に大きな問題点がテーマとなりました。これまでは、属人的にマネジメントを行っていたために、なかなか客観的かつ定量的に見えていなかった部分です。

例えば、これは要件変更発生時にプロジェクトリーダーが行うべき作業の一部を要約したものです。

要件変更の際は、プロジェクトリーダーが変更の内容を変更管理シートへ記載した後、開発スタッフのコミットメントを得るためのミーティングを実施する。また、プロジェクトリーダーは要件変更の影響の大きさを測定し、その結果をプロジェクトマネージャーに報告する。（要件変更管理プロセス定義書から要約）

顧客がどこかのタイミングで要件を変更することで、それを受け入れるために必要なステップの一部です。これだけでも、複数スタッフに関連する実にいろいろな作業が発生することが読み取れるかと思います。「そういった点は、プロジェクトリーダーの判断に任せれば良いのではないか？」「それは、CMMIの最低限の記述要求なのか？それとも、そこまでできたら良いという社内的な判断なのか？」など、特に現場サイドのスタッフからこういった意見が出ます。その都度、一つ一つのステップの目的が何なのか議論し、そのステップがある場合とない場合でシミュレーションを行い、突き詰めて最適な方法を探ってきました。

おそらく、CMMIに限らずプロジェクトマネージメントを考える際には、作業コストということが必ず検討課題として挙がることでしょう。その議論をする上で『全員が同じゴールに向かっていることと』は前提条件であることが間違いありません。弊社の今回の場合で言えば、『なぜCMMIの導入を決めたのか』という目的が共有できていたからこそ、いろいろな議論が紆余曲折はありながらも最終的にはまとまっていけたのではないかと思うのです。そういった点で、非常に志の高いプロジェクトメンバーには深く感謝です。

これからの課題

間もなく一つ目のプロトタイプ運用が始まろうとしています。今回のプロトタイプ運用では、早急に要件の取り決めが大切な基幹系の業務システム案件となります。ただ、顧客企業と弊社間の直接取引であるという点から第一号案件として採用の予定です。

CMMIの実運用に向けては、弊社内の運用とは別に越えなければならないハードルがあり、一プロジェクト内での他企業との協業もその一つです。

ご存知の通り、ソフトウェア業界では建設業界に見られるように、受注元・下請け・孫請けと呼ばれる取引構造が存在します。そういった階層構造の中に弊社が組み込まれた場合に、果たして「顧客」とは誰を指すのか、また「顧客との合意」とは誰との合意を指すのか等、そのような構造を前提とした準備もしなければなりません。場合によっては、弊社がCMMIプロセスに則ってソフトウェア開発を事前に説明し、承諾を頂くような場も必要なのかもしれません。こういった点も、今後運用の開始に伴いケーススタディを一つずつ積み重ねながらスパイラルアップしていくべき点と捉えています。

最後に

従来の「発注したのだから後は任せる」というスタンスは少しずつ変わってきているように感じます。少し前に、情報サービス産業協会（JISA）が作成、公表された「ソフトウェア開発委託モデル契約書」中でも、委託ユーザ側の役割などについてより明確に記載されています。

弊社のシステム開発事業では「顧客と共にゴールを目指す」ということを基本スタンスとしています。これまでには、顧客に対してゴールまで道標を明確に示せないことが何度かありました。しかしながら、今後はこのCMMIプロセス導入も一つのきっかけとし、システムというフィルターを通した顧客企業の経営基盤・業務基盤作りのお手伝いをさせて頂きたいと決意を新たにしています。