CMMIへの取り組み
当社は2013年にCMMI®(Capability Maturity Model Integration、能力成熟度モデル統合) のレベル3を達成、そして2016年以降継続してレベル4を達成しています。国内でレベル4以上を達成している企業は12社だけで、そのうち地方に本社がある企業は当社のみです(2020/01/01時点)。
CMMIとは、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したもの*1で、CMMI Instituteにより運営されています。
日本においてもCMMIの指針に即して開発プロセスを改善する動きが広がりつつありますが、誰もが知っているものではないため、見栄えだけではないのか、手間やコストをかけるメリットはあるのかなどといった疑問もあるかと思います。本当のところはどうなのか、担当者に話を聞いてみました。

左:晒谷(コーポレート本部本部長) 右:井上(品質管理プロセス改善担当)
CMMIはソフトウェアを開発する組織の成熟度を測る指標
— CMMIとは何ですか?
- 晒谷
- ソフトウェアを開発する組織の成熟度を測る指標です。CMMIの指標をリファレンスとすることで、自分たちの開発プロセスで足りないところを理解して、改善のきっかけにすることができます。
- 井上
- PM(プロジェクトマネージャー)という立場になると、なかなか「教えてもらう」ということがありません。その状況で、何か参考になるものだったり、最低限やるべきことを独力でかき集めてくることが大変でした。後進のPMが、同じ苦労や失敗をしないために何かないかなと探していたところ、CMMIの話があって、僕自身もやってみたいと思いました。
- 晒谷
- プロジェクトマネージメント技術の指標としては、PMP®(プロジェクトマネジメント・プロフェッショナル)という資格もあり、当社ではこちらも取得必須となっています。しかし、PMPだけだと開発のスキルが個々のプロジェクトリーダーに依存してしまいます。
- 井上
- 確かにそうですね。お客さまは個人に対してではなく、会社に対して仕事を発注します。「クオリサイトテクノロジーズに発注すればよい結果が得られる」ということを守るためには、個人の力だけではなく、組織としての力が必要になると思うのです。
狙いは組織としての対応力を上げること
— CMMIの取り組みを始めたきっかけは何ですか?
- 晒谷
- 事業を始めた当初から、組織としての対応力を上げていこうというテーマがありました。また、当初はインドや中国のオフショア開発と比較されることが多かったのですが、インドでCMMIのレベル5を達成した企業が現れたことは大きなインパクトになりました。オフショアの企業と当社の売りは違うのですが、創業当初は実績が何もない。単純に比較されたときにも勝てるようにという意図もありました。
— CMMIを達成しているとお客さまに安心してもらえるのですね?
- 晒谷
- CMMIのレベル4を持っているという意味では、一部そのような効果はあると思うのですが、どちらかというと、お客さまに対して、プロジェクトドリブンではなく、会社としてサポートできることに意義があると考えています。レベル4は達成しましたが、まだ開発がプロジェクト任せになっている部分もあります。会社で組織的に、若いプロジェクトリーダーの離陸を早くしたい、彼らが転んだところでもう一度転ばないようにしたい、お客さまに対してコストパフォーマンスを上げていきたいといった思いがあります。
- 井上
- プロジェクト単位ではなく組織としてPDCAサイクルを回していくので、チームが大きくなったり、増えたりしても、私たちの力は右肩上がりになることが期待できます。そういう意味で、お客さまには、短期よりも長期のお仕事を依頼していただいた方がよりメリットが出せると思います。

お客さまにとってのメリットは成果物の品質向上
— お客さまにとってのメリットは安心感や信頼感だけではないのですね?
- 晒谷
- 当社のスタンスとしては、CMMIを持っていることをアピールするのではなくて、プロジェクトの成果物や成果自体を評価してもらいたいと思っています。社長からはもっとアピールしろと言われていますけど(笑)
- 井上
- 毎年、お客さまにCS(満足度)調査にご協力いただいているのですが、CMMIの取り組みを始めてからは着実にCSはいい方向に上がっています。
書類作成はそれほど大変ではない
— CMMIレベル4を達成する際に大変だったことは何ですか? やはり書類をたくさん作ることですか?
- 晒谷
- いいえ、審査のために書類をメチャクチャ準備したわけではないです。普段のプロジェクトで使っているものが中心になります。むしろ、書類作成においては、アプレイザル(評価)時にアプレイザルメンバーの目線が入ったとき、「確かに…」と思うような弱みや気付きを得られたメリットの方が大きかったです。
- 井上
- ただ、審査期間は大変でした。丸7日間におよぶのですが、最初の2日間は「ドキュメントレビュー」で書類は揃っているか、内容は満たされているか、さらには、整合性はあっているかをひたすら確認していきます。内容が非常に領域が広くて、多岐にわたっているので、長いようであっという間でした。審査の最後の2、3日はさらに厳しくて、アプレイザルメンバー全員で評価が正しいか確認するのですが、中には手厳しい質問もあり泣きそうになりました…。でも、この辺は現場の愚痴だから、あまり書かなくてもいいんじゃないでしょうか(笑)。
品質とコストの関係を分析して予測する
— では、本当に大変だったことは何ですか?
- 井上
- レベル4の特色として、未来を予測するナビゲーションというものがあります。現在起きていることから未来の結果を予測する予測式を作る必要があって、とある事象ととある結果に相関関係があるのかないのかをひたすらデータを分析していくことに年単位で時間がかかりました。ひとつのトライアルは少なくても3か月間はかかります。一発ではうまくいかないので、いろいろな試行錯誤をしました。期間内に本当に成果が出るのか、不安になるときもありました。
- 晒谷
- 何を分析していくかは、何でもよいわけではありません。事業に関係するもの、事業目的に合ったものでないとダメで、たとえば、変な話、休暇取得率を分析してもいいといえばいいのですけど、休暇取得率がうちの事業にクリティカルに直結するというわけではない。プロジェクトや事業の成功につながるテーマが必要です。もちろん、分析するデータ自体も(既存の論文からなどではなく)自社で用意しなくてはいけません。
— 結果としてどんな予測式を立てることができたのですか?
- 井上
- 現状の品質レベルを元に、このままいけば最終的にコスト内に収まるのか収まらないのかを予測する仕組みを作ることができました。品質とコストは反比例の関係にあります。もともと計画で立てているバランスを目指して順調に進んでいるかを判断できます。
- 晒谷
- 具体的には、レビューでの指摘件数が多くなってきたとします。そのことから、この先の品質が悪くなりそうで、リカバリーするコストでプロジェクトの収益も低下してメンバーへの負荷も高まって、さらによくないことになるだろうということを、早期に「おやっ」と気づくきっかけができるようになりました。いまのところ、失敗予測が立つような状況にはどのプロジェクトもなっていないんだけど(笑)。
- 井上
- そうですね、いまのところは順調です。
- 晒谷
- 結果として順調だから、予測式があっているといえばあっている。
- 井上
- (不安定になりがちな)新規のプロジェクトでも試してみたいですね。

リファレンスとしてCMMIを選ぶ
— ソフトウェア開発会社のなかでも、CMMIに関心がある会社と、ない会社があるかと思いますが、何が違うと思いますか?
- 晒谷
- 私自身は、組織の改善に興味のない会社はないと思っています。組織の改善のために、我々はCMMIというリファレンスを使っただけ。我々は歴史もないし、ゼロから作っていく必要があったので、ある程度公的なリファレンスを参照しました。それがゆえに、短期間での成長があった。取り組んでいない会社はダメだとは思わないし、その会社ごとのビジネススタイルがあるのではないかなと思っています。CMMIの達成はしんどいんじゃないかという先入観もあるんじゃないかとは思いますが…。
- 井上
- 軸となる標準というものがない文化で成長した会社は、型に合わない亜流がたくさんあるはずなので、その亜流を揃えることは、大きい企業であれば相当しんどいはずです。途中からCMMIを導入するというよりは、我々みたいな芽が出た会社がやっていくと、将来的にはいい幹に育つんじゃないかと思います。
- 晒谷
- 当社でも、他社のSIerと一緒にやっているプロジェクトなど、すでにやり方があったり、やり方が違ったりするケースもあります。それも含めて整合性をとっていく、最適化していくことは、アプレイザルの審査がしんどかった最大の理由でもあります。
- 井上
- 成功しているプロジェクトに対して「やり方が決まったからこれに変えてくれ」ということは、基本的にはないので。

プロジェクトがきちんと管理されているとエンジニアも働きやすい
— 会社で働くエンジニアにとってもメリットはありますか?
- 晒谷
- 先ほど井上さんが言ったことですが、組織としての経験が少ない状態でプロジェクトリーダーを作っていかないといけないなかで、オーソドックスなやり方、スタンダードなやり方を参照できるようにしていくのは意味があるんじゃないかと。そうやって、プロジェクトマネージメントの精度が上がってくると、そこで働くエンジニアにとっても、当然、開発に集中できるので、いいのではないかと思います。
今後の展望と改善点
— CMMIのレベル4を達成しましたが、まだ改善できるところはありますか?
- 晒谷
- 終わりはないと思っています。これ以上改善する個所がないことは絶対に訪れない。我々自身のレベルが上がっていけば、それに応じて組織の仕組みも当然ながらよくなっていかないといけないわけですから。
- 井上
- レベルが上がれば、上がっただけレベルの高い課題が出ると予想されます。改善点はずっとあると思います。
— 今後はレベル5を目指しますか?
- 晒谷
- 目指してないわけではないけど、レベル4でもまだまだ取り組むことがあるかなと思うので、しばらくは4の維持かなと思います。
- 井上
- いいんじゃないですか、「目指します!」で(笑)
- 晒谷
- まあ、自分たちの改善がうまく進んでいけば自然体でレベル5になっていくんじゃないかなと思います。
- 井上
- とりあえず、やり続けて、愚直に成長していけばいい。その結果、各プロジェクトがHAPPYになればいいと。品質管理部の立場としては、品質管理部からの押し付けでプロジェクトが苦労するようなことはしたくありません。HAPPYな会社になるためのきっかけだったり、手法をみんなで共有できるように頑張ります。
*1 Wikipedia 能力成熟度モデル統合 より
※ CMMIおよびCapability Maturity Modelは、アメリカ合衆国特許商標庁に登録されています。
※ PMPはプロジェクトマネジメント協会 (Project Management Institute, Inc.) の登録商標です。