CMMI、実践中間報告！（第3回）

CMMIレベル認定に向けた当社の取り組み、前回2回目の中間報告をコラムとしてご報告したのが7月25日。それからもう3ヶ月半が経過しました。その間に、果たしてどこまで進行したのか...？

実は、既にプロジェクトマネジメント、ソフトウェア開発エンジニアリングに関わるプロセス定義のほとんどがver1.0に到達し、一部のプロセスエリアについて、実案件へのプロトタイプ運用を行いました。今回はそれについてのご紹介です。

案件の概要

A社は、自社商品の通信販売業を主業務としている企業です。注文の形態は、電話だったりFAXだったり、またはWebから注文を受けるインタフェースも提供しています。これまで、注文に関わる各種の情報（顧客情報や注文履歴、商品情報など）を、内製で開発した独自のMS-AccessシステムをローカルPCで共有し、情報の管理業務を行っていました。ところが、履歴情報の肥大化や、情報活用ニーズの増大、システム管理者の増加に伴い、専用サーバ中心の本格的なシステム構築を行うこととなり、それが今回の開発プロジェクトの発足となりました。

決して大規模な開発規模ではありませんが、再構築にあたっては、現状業務フローの見直し・データ設計など、基幹業務・期間データに関わってくる上流工程からのスタートです。このコラムが掲載される11月は、要件定義と基本設計フェーズが終わり、実装範囲の決定に向けて、Function Point法をベースとした見積もりプロセスによる開発工程のコスト見積もり作業を行っている段階です。

適用したプロセスエリア

本来のCMMIプロセス適用の姿としては、一部のプロセスエリアをかいつまんで適用するというものではないのですが、今回は、適用することによる発生コストの計測や、現実的な問題点の洗い出しなどを主目的としていましたので、特定のエリアに対してだけの適用としました。適用したのは、下記プロセスエリアです。

• 契約プロセス
• プロジェクト計画プロセス
• プロジェクト監視と制御プロセス
• 要件開発プロセス、要件管理プロセス
• 検証と妥当性確認プロセス

上述した通り、現段階では要件定義と基本設計フェーズが終了した段階であり、プロジェクトに関わる当社スタッフも未だ少ない状態です。ですから、意思決定や議論の調整にしても未だ非常に用意に進めやすい状態なのですが、それでもやはり...いろいろな課題が見つかりました。

数々の課題が...

定義したプロセスそのものに対して改善を要する部分も少なくはありません。ただ、今回はより概念的なところで検討すべき課題について幾つか挙げてみたいと思います。このコラムを読まれている方の中には、CMMIというものに興味を持たれ、導入を検討されている方もいらっしゃるのかもしれません。当社は、ソフトウェア開発という分野では未だ駆け出しの、規模も小さい企業ですので、そんな企業が直面した問題点というような見方で読んでいただければと思います。

（1）顧客側の協力体制

今回のプロジェクトでは、業務フロー設計やデータ設計など基幹情報に関わる内容であったこともあり、A社の主任担当者にもかなりの時間を割いていただきました。10月は、定期的な進捗報告兼仕様検討会を毎週実施し、当社が作業するのは当然ですが、A社のご担当者にも仕様書のレビュー、議事録のレビュー、更に仕様策定そのものに対しての資料準備や社内調整などの業務も発生したことと思いますので、相当な時間を費やしていただいたことになります。
もし、案件規模が大きくなり、顧客側のさまざまな関連部門やさまざまな立場の担当者が関わることになった場合、おそらく議事録の回覧程度でも多くのやり取りが発生すると予想されます。プロセスの中では、重要な事項については、「会議参加者全員の押印（またはサイン）を得る」という定義があるのですが、何でも気安く『押印』と表現するのではなく、顧客側に発生するコストを勘案し、どのような形態で書類の承認達成を確認するか、また、何をもって重要な事項と判断するのか等々、様々なシーンを想定した定義が必要であると感じました。

（2）当社側の開発体制

当社は、システム開発部隊が未だ小さいこともあり、プロジェクトリーダという立場であっても、実際には仕様書作成であったり、場合によってはコーディングであったり、開発作業そのものに関わることが殆どです。今回はプロトタイプ適用ということで、なおさらそういったこれまでの実情を意識したメンバー構成としましたが、実作業を抱えながらプロジェクトマネージメント作業を行うのは事実上難しいかな、という感触を得ました。
大規模なシステム開発であれば、もともと大人数が関わることを前提としていますので、リーダ自身がソフトウェア開発の各工程に関わる必要はありません。しかしながら、規模の大きくない案件に対応する場合、実開発作業に関わらない、マネジメント作業専属の要員を一人設けることは、収益モデルにも影響を及ぼすことになってしまいます。

（3）ISO9001との共存

当社ではISO9001を取得しているため、CMMIのプロセス定義の際にも当然ISO9001で規定しているプロセスとの干渉を意識しながら進めてきてはいたつもりです。ただし、当社は、ソフトウェア開発とは別に、Webコンテンツ制作業務を行っており（むしろ、そちらの方がメイン業務です）、ISO9001やそれを支援する社内システムはWebコンテンツ制作業務に最適化してあります。そのため、ソフトウェア開発に特化したマネジメントプロセスを導入する際には、 ISO9001や社内システムにもそれを反映していかなければなりません。
契約や外注など、顧客を含めた他企業との関わりを考えた場合にどう改修していくべきなのか、という点を深く考えました。

さて、今後

先ず、未完成のプロセス定義を進めていかなければなりません。残すプロセス群は、組織的な営みに関わるプロセスエリアです。こちらは、経営層への社内レビューでも相当な紛糾（笑）が予想されます。実際、これこそが組織としての力を蓄えていく上で大切な部分だと思いますので。また、プロトタイプ運用も続けていく予定です。これから実装工程に入っていきますので、開発に関わるスタッフはますます増えることになります。
それでもゴールは近づいてきました。未だラストスパートの域までは到達していないと思いますが、しっかりペースをつかんで頑張らないと！