ソフトウェア開発プロセスの話を少し

皆さま、こんばんは
11期生の静永です。

今日から、6月が始まりました。

今日(6/1)は、プロセス改善に関与している人達の業界団体(JASPIC)の10周年記念イベントというものに参加してきました。

直接ソフトウェア・プログラムを作るよりも、開発プロジェクトをうまく回すためにはどうすれば良いか、複数のプロジェクトを横断して部門・組織レベルでどうすれば良いか、ということを考える業務なので、私がかなり若手に位置するような年齢層の集まりになります。

先日の育成塾最終講義で、現在ソフトウェア開発プロセス改善という業務に従事していることを紹介させていただきました。

その時の10分プレゼンで紹介したCMMI (Capability Maturity Model Integration), SPICE (Software Process Improvement Capability Determination)の話題も今回のイベントで出てきました。また、設立に関わった方から、70年代くらいからのソフトウェア開発プロセスに関する紹介もありました。

ということがあったので、突然ですがこの機会に、少しソフトウェア開発プロセスの話を。

かなり大雑把な言い方ですが、ISO9000の場合、ISOで品質管理システムについての要求事項を示し、その要求事項を満たしているか客観的に示すという論理で、認証期間が監査などをしてお墨付きを与えます。同じような感じで、ソフトウェア開発プロセスでは、CMMIというものが要求事項の役割をはたし、CMMIの発行元であるSEIというところで認められたアセッサーが、SEIで認められたアセスメント手順に従って、お墨付きを与えるようなことが行われています。

このCMMIですが、たしか90年代に、米国国防省がソフトウェア調達先を選定する手段に採択されたことが普及の一因となったものです。

当時でもソフトウェア開発がうまくいかなかった国防省が、能力のあるソフトウェア開発発注先であるかどうか評価する方法として、CMMIの前身(CMM)を基準とし、あるレベルを認められた組織だけに入札を認める、ということをしました。

そのような経緯から、CMMIは今でもレベル認定・お墨付きを取得することが目的になることがあり、その結果現場に無駄な負担が増えてしまうという、これまたISO9000のような現象も起きたりしています。

そんなCMMIですが、その起源の一つはたしか80年代のIBMで、いくつもの工場でソフトウェア開発の生産性や品質をどうすれば向上できるかという調査の結果があります。その調査の結果、生産性・品質が良い組織には共通の特性があるとして、組織成熟度の考え方などが、製造業からソフトウェア開発へ導入されたりします。

かなり纒まりない説明になってしまいましたが、ソフトウェア開発プロセスの話はCMMIだけでもまだまだあり、CMMI以外の話も色々あるので、取り敢えずこの辺で。

最後に、上記で紹介した80年代のIBMでの調査について少し。その資料が以前はweb上で公開されていまして、そのやり方として、現場の人に自分達のやり方を説明してもらう、ということを繰返してたとあります。

その時、現場に聞いていた内容というのが、だいたい以下のようなこと。

• どんなドキュメントを使っているか／作っているか？
• どんなツールを使っているか？
• 品質／正確性／完全性はどう検証してるか？
• どんなチェック／レビュー／承認作業が関わっているか？
• 進捗はどうやって追い掛けているか？
• 必要なスケジュールと要員とは、どうやって見積っているか？
• 変更はどうやって扱っているか(制御／管理してるか)？

これはソフトウェア開発に限らず、「プロセス」について考える時にイメージを湧かせやすい観点だと個人的に思ってて、結構客先でも使ってるネタだったりします。

コンサルの仕事に「プロセス指向」が大事という話をどこかで耳にした記憶があるのですが、これを読んでる方にこのネタが少しでも役立てば幸いです、と殊勝なことを書いたところで今回の記事は終ろうと思います。

最後までお付き合いありがとうございました。