ソフトウェア力が抜けてプロセス改善は形骸化した - 「アジャイル勘違い集」を読んで -

オブラブの「アジャイル勘違い集」を見ると、こんな事が書かれていました。

「あなたが用いているのはアジャイルではなく、アジャイルプロセスではありませんか？…(略)…優れたプラクティスを忠実に実践すれば効果を生むこともありますが、その価値と原則を知らなければ、本来の力を発揮することはできません。」

言いたい事はわかるのですが、少し違和感を覚えました。確かに、ここで書かれているプロセスとは、＠IT情報マネジメント用語事典にある「ソフトウェア開発や保守などの業務を構成する一連の作業のこと」だと思えばその通りです。でも、昔は違ったのです。

ハンフリー氏のプロセスの定義

CMM/CMMIで有名なハンフリーさんの「ソフトウェアプロセス成熟度の改善」によれば、ソフトウェアプロセスとは「ソフトウェアの生産および進化の中で使用されている活動、手法、および慣習の集合」(p.268)とされていて、入力から成果物(プロダクト)を生成する間の過程のことで、そこには作業以外のものも含まれています。（その他の定義はIPAセミナーの１番目のPDF資料に載っていますので参考にしてください）

かつて、SEA SPIN(ソフトウェア技術者協会のSoftware Process Improvement Network)の人たちが、CMMを訳した際には、「プロセス成熟度」ではなく「プロセス能力成熟度」とCMMのC(capability)が意識されていました。

また、巻頭の「日本語版へのメッセージ」にはこうあります。

「ソフトウェア力のいかんが、企業の収益性と長期競争の生き残りに影響を与える事を、多くの組織が認識している」

このようなソフトウェア力を高める目的でプロセス改善が行われます。ソフトウェアプロセスの改善と題した節(p.4)では、こう書かれています。

「プロセスを『正しく実行すれば、望ましい結果を作り出してくれる作業(task)の集合』と定義している」

つまり、ソフトウェア力を高めることでプロセスは成熟する。そのために正しく実行する事で、必要なものが実現できればプロセス、そうでなければプロセスでなかったのです。

ソフトウェア力はどこに行った

では、なぜプロセスの定義が望ましい結果と関係が薄くなり、ソフトウェア力の向上があまり注目されにくくなったかを考えてみます。それには、２つの理由があると思います。

一つは、改善の目的とされていたQCD(品質、コスト、納期)が偏っていたからです。CMMのスポンサーはDoD(米国防総省)なので、信頼性(バグが少ない事)が重視されていたからでしょう。品質と言えば主に信頼性(バグが少ない事)を指していたほか、日本ではコストや納期の改善は品質の改善によって達成されるとまで言われていました（他の品質特性を固定すればあながち嘘ではないのですが、そうとは言えないアプリケーションが増えています）。

もう一つは、プロセスを数値や実施の有無で評価していたからです。良いプロセスを実現するためのベストプラクティスがあって、その通りであれば問題がないと考えられたのです。しかし、それは「修身」や「しつけ」の様なものであり、顧客のビジネスがソフトウェアがいつどのような価値を提供できるかによって成否が分かれる事や、開発者の自由な発想や集中できる環境がより良いソフトウェアを開発する上で大切なものであるといった観点が抜けていました。

実は以前にも紹介した様に、ハンフリー氏は人間的な側面も重視されています。特にチームのプロセスを扱ったTSPの書籍では、サーバントリーダーシップと同じ事を説明されています。

しかし、組織のプロセスをまとめたCMMのレベル争いが流行ってしまいました。多くの組織でレベル達成が目的になる事でプロセス改善の形骸化が進み、大切なソフトウェア力の向上への取り組みが抜け落ちてしまったのだと思います。

スクラムは標準による形骸化から逃れられる可能性がある

第２次アジャイルブームの中でスクラムが本格的に普及しつつあります。きっと日本でもスクラムは、アジャイルの標準になると思われます。

そのような中で、スクラムも形骸化するのでしょうか？そうなって欲しくないですが、どうなるかはわかりません。実はCMMブームの時もレベル争いになってはいけないと多くの方が努力され、より良い形で進んだ組織もたくさんありました。しかし、そうでないところもあったのです（やらないよりはましという声も多くありましたが、、）。

さて、スクラムの特徴はCMMで成し遂げられなかったソフトウェア力向上の仕組みが入っていることです。目指している方向性がゆがめられなければ、うまくいく可能性があります。

もちろん標準化されたものですから、そのままで全ての組織に最適ではなく、ある程度カスタマイズが必要かもしれません（アダプタブルウォータフォール(事例)やCCPMなどがふさわしい場合もあるでしょう）。そのように標準からそれる際に方向性を見失わないようにするには、知恵や経験が必要になります。

幸いスクラムなどアジャイル開発には多くのコミュニティやイベントがあります。公式なイベントだけでなく、スクラムブートキャンプ、スクラム道、XPJUG、XP祭り、アジャイルジャパン、アジャイルツアー、デブサミなど、一般の方も参加できる情報収集の機会がたくさんあります。これらが活用されれば方向を見失う事も減るでしょう。

そして、今年はたくさんのスクラムやアジャイル開発の書籍が出版される様です。去年までは「スクラムを活用したアジャイルなプロダクト管理 」のような翻訳書が多かったですが、今年は和書が多く出版される様です。
直近では「アジャイル開発とスクラム 」、「SCRUM BOOT CAMP THE BOOK」があり、この他にも出版予定がある様に聞いていて、大いに期待できます。

これらの活動や書籍によって、ソフトウェア力を備えたより良いプロセスが広まる事を楽しみにしています。