品質保証者の憂鬱「計測できないものは制御できないは本当か？」

前回の投稿から１か月以上も期間があいてしまいました。
少し時間が取れるようになってきたので、今回もソフトウェア品質について少し語っていきたいと思います。

ソフトウェア開発業界に限らず、何らかの開発作業に従事している人であれば次の言葉を聞いたことがあるのではないでしょうか。

計測できないものは制御できない

この言葉は1982年にトム・デマルコ氏によって語られました。
デマルコ氏は、ソフトウェア開発の分野で著名な人物であり、ソフトウェア開発プロジェクトの管理と制御に関する重要な考え方をいくつも提唱してきました。
その彼の言葉の1つが「計測できないものは制御できない」というものです。

デマルコ氏の書著で有名なものに以下のものがあります。

• ピープルウェア：
  ソフトウェア開発プロジェクトで技術よりも大事なものは何かを説いた名著。ティモシー・リスター氏との共著になっています。
• 熊とワルツを：
  ソフトウェア開発プロジェクトのリスク管理に焦点を当てています。ティモシー・リスター氏との共著になっています。
• ゆとりの法則：
  ゆとり教育の”ゆとり”のことではなく、ソフトウェア開発で効率ばかりを追い求めていてはいけないと警鐘を鳴らし、効率至上主義の弊害を説いています。
• デッドライン：
  プロジェクトを成功に導く指南書といった立ち位置でしょうか。

上記の書籍を通してデマルコ氏が一貫して説いているのは「人」の重要性です。
そんなデマルコ氏が「計測できないものは制御できない」と述べていることは非常に興味深いものがありました。
「計測できないものは制御できない」という言葉は、ソフトウェア開発プロジェクトを管理する際に、進捗や品質などの要素を定量的に測定することの重要性を示唆しています。
デマルコ氏は、計測可能な指標を使用することで、プロジェクトの進行状況や品質に対する洞察を得ることができ、それに基づいて適切な制御や改善策を実施できると主張していました。

具体的には、プロジェクトの進捗状況を定量的に把握するために、タスクの完了率や残り作業量、経過時間などの指標を使用したり、バグの数や重要な機能のテストカバレッジ、顧客の満足度などの指標を利用するなどの施策が考えられます。

筆者も上記の主張に完全に同意します。
これまで多くのソフトウェア開発プロジェクトに参加してきましたが、多くのプロジェクトでは次のような問題が起こり、プロジェクトがちゃんと進捗せず、デスマーチ（”死の行進”という意味の英語表現で、悲惨なソフトウェア開発プロジェクトの現場を表す）に陥ることがほとんどでした。
筆者は40年近くソフトウェア開発現場に身をおいてきましたが、悪魔に導かれるように、どのプロジェクトも「デスマーチ」に突入してしまうのです。あたかも「悪魔の計画」通りに物事が進んでいるかの如く。

筆者の肌感覚になりますが、プロジェクトの進捗状況を定量的に把握することを軽視しているプロジェクトでは以下のような兆候が現れます。

• リスクや不確実性の評価ができない。
  リスクや不確実性を正しく評価することが困難になる。予測や計画立案に基づくリソースの割り当てやスケジュール管理が不十分になり、プロジェクトの進行が予測できなくなる。

• 進捗が見通せなくなり、リカバリ機会を逸する。
  プロジェクトの進捗状況やタスクの完了度が見えにくくなり、プロジェクトマネージャーやチームメンバーは問題を早期に発見できず、遅延や予算超過などの課題に直面する。

• 課題出しやパフォーマンス評価が困難になる。
  品質やパフォーマンスの評価が困難になる。品質管理やプロセス改善のためのデータ駆動のアプローチが欠如すると、バグの発見や修正、顧客の要求への適応などが遅れ、プロジェクトの破綻につながる。

このような悲惨な状況を避けるため、デマルコ氏はソフトウェア開発プロジェクトを管理する際に、進捗や品質などの要素を定量的に測定することの重要性を説いたのだと思います。

KKDとは以下の言葉をローマ字で表記したときの頭文字を取ったものです。

• 経験（KEIKEN）
• 勘（KAN）
• 度胸（DOKYOU）

要は職人（匠）の技として昔から受け継がれてきた手法と言えます。
（個人的には「手法」に分類してよいかどうかは疑問ですが）

KKDは「長年培ってきた経験」をベースにしているので「既知の問題・課題」には”それなりに”対応できます。
また、これまで経験したことの無い課題に対しても「研ぎ澄まされた勘」を頼りとし、迷ったときには「思い切って（度胸で）」判断することである程度は対応可能です。
計画を立案・実行する人が熟練者の場合、意外とうまくいくことも多いので、プロジェクトに熟練者が多い場合には頼りにされていたと思います。

しかし、すべてのプロジェクトに適正な人数の熟練者が配置されるとは限らず、また昨今の開発事情では「全く経験の無い分野」に積極的にトライする案件も多いと思います。

筆者の経験的には、プロジェクトに必要な知見をメンバーの半数以上が有していない場合、プロジェクトがデスマーチに突入する確率はグンと上がると思います。

昔、筆者がまだまだ駆け出しエンジニアだった頃は定量的にプロジェクトを管理するよりも、年配者リーダーの指揮のもとに「無闇に突撃して玉砕」するプロジェクトが多かったように思います。
その失敗から学べば問題ないのですが、多くの場合「あれは運が悪かった」と言って反省せずに次のプロジェクトに進軍するので、同じ過ちが量産されました。
当時は「デスマーチ」なんて言い方はしていなくて「八甲田山」と呼んでいました。（やっぱり年代が古いですね）

筆者はアナライザー気質なので、どちらかというとデータ指向で物事を考えます。
ただ、当然と言えば当然ですが、データは万能ではありません。

デマルコ氏は2009年に自身の「計測できないものは制御できない」という言葉に批判的な意見を発表しました。（こちらを参照）
上記のデマルコ氏の主張を読むと、これまではソフトウェア工学という名のもとに「制御」に重心をおいてきたが、ソフトウエアを開発するという行為は、これまでの「工学としての常識」では説明できない要素で価値が決まると言っているように聞こえます。

もともとデマルコ氏は「ピープルウェア」の著者であり、ソフトウェア開発における「人」の重要性を最初から説いていたので、このように考えを改めたと言及しても不思議ではないと思いました。

ソフトウェア開発現場においては、インプットからアウトプットを生成するプロセスを工学的な方程式のようなものだけで記述できるはずもなく、何かもっと不確実な力による影響が多いのがソフトウェア開発ということなのでしょう。

工学的な視点で言えば「データ」は重要です。
しかし、データだけを盲信すると痛い目に遭います。
プロジェクトに対して過度に定量的評価（データ計測・分析など）を強要した場合、プロジェクトメンバーがプレッシャーに耐えきれず「データを改ざん」する危険性が生まれます。

「人間は追い詰められるとどんな嘘でもつく」

この言葉は、筆者が昔お世話になった上司が言っていたことです。
改ざんされたデータを元にその場を取り繕い続けても、結果が好転することはありません。
データを改ざんした結果、会社の信用に傷が付き、取り返しの付かない事態になることもありえます。

プロジェクトを進めている時、使えるデータが少なく、不確実な情報しか得られないケースもあるでしょう。
そんな環境下では「計測できない状態でも開発を進めるしかない」状況が生まれます。

しかし、データが”全く存在しない世界”は無いと思っています。
人間がテレパシーで会話しない限り、何かのドキュメントは書かれますし、AIが開発しない限り人間がソースコードを書きます。（最近のAIの進歩は凄まじいですが）

これまで筆者が従事したソフトウェア開発プロジェクトの中には「これからはアジャイル開発だ！」という号令のもとにアジャイル開発にトライしたプロジェクトが多くありましたが、その90％以上がうまくいきませんでした。
アジャイル型開発を”自分に都合のよい”ように勘違いしているケースが多かった印象です。

• アジャイルだからドキュメントは書きません
• 設計している時間が勿体ないのですぐにソースコードを書きます

こんなことを平気で言う勢力がはびこり、当然の結果としてデスマーチに突入することがほとんどでした。

デマルコ氏は晩年「制御がすべてではない」とは言っていますが、だからといって「計測することが無意味になった」わけではないのです。

極端な施策は必ずしっぺ返しを喰らいます。

プロジェクトに無謀な「定量的な評価」を持ち込むと、不正確なデータが量産され見当違いな経営判断をすることになりかねません。

かと言って「定量的な評価」をまったく実施しない場合は「属人」という沼にハマってしまい、期待する結果にならないことがほとんどです。

闇夜の晩に、自動車のライトが壊れている状態の車のアクセルを全踏み込みする人はいないと思います。
まずは自分たちの身の丈に合った羅針盤を用意して、少なくとも”足元”くらいは照らしながら進むようにしたいものです。

足元が見えて来たらもう少し先を。
そして、更に周囲を。
「千里の道も一歩から」と言いますし。