ノルウェーのソフトウェア開発ポッドキャスト"utviklingslandet.no"でホストを務めるAugust Lilleaas氏が先頃、組織の複雑性とソフトウェア品質との相関関係に関する記事を書いた。2008年のMicrosoftの論文"The Influence of Organizational Structure On Software Quality: An Empirical Case Study"を取り上げたこの記事の中で、Likkeaas氏は、コラボレーションする個人同士の組織階層上の距離に基いた、ソフトウェア製品品質の高精度な予測の可能なモデルについて解説している。Rapid Software Testing Methotologyを開発したJames Bach氏も先頃、"Assess Quality. Don't Mesure It"と題した記事の中で、品質に関する主観的な測定値の解釈に注意を促すとともに、顧客満足を見失わないことの重要性について述べている。先日のTeam Topologiesの著者たちとのInfoQのインタビューでも、組織構造がソフトウェアプロダクトの健全性に及ぼす好影響が話題として取り上げられた。
その元になった研究の要約として、Lilleaas氏は、"組織の複雑性"を考慮したモデルがソフトウェア品質の予測に極めて有効であることを論証している。この手法は、特定タイプの静的分析やソフトウェア関連のメトリクスを多用する従来モデルとは対照的なものだ。
Lilleaas氏が説明するMicrosoftのモデルでは、組織内でコラボレーションを行うもの同士の階層とコミュニケーションパスに基いたいくつかのファクタを活用して、ソフトウェア品質を予測する。 Lilleaas氏は、Windows Visaのモジュールコンポーネントの"障害多発性(failure-proneness)"を高い信頼性で予測する上で、このモデルで使用されているファクタをいくつか挙げた。
- ひとつ以上のソフトウェアプロダクト内で使用されている"モジュールに従事する開発者の数"
- そのモジュールに過去に携わった開発者の数
- モジュールに関与した組織の割合
- モジュールに影響する共同作業者間の組織内における分離の割合。例えば、"開発者と意思決定者との間の組織的距離"
モジュールを見ればソフトウェアの品質問題を高い精度で予測可能であるという事実から、Lilleaas氏は次のような結論を導き出している。
意思決定者との距離やプロジェクトに従事する開発者の数が、コードベースの将来的な問題を予測する上で最高の方法であることは、明白で疑う余地がありません。
先日のInfoQとのQ&Aで、"Team Topologies"の著者であるMatthew Skelton、Manuel Pais両氏は、組織内にコラボレーションの良好なチームを効率的に構築するための現代的なパターンについて述べた。氏らの著書では、組織の複雑さがソフトウェアアーキテクチャに与えるネガティブな影響を軽減するためのパターンが紹介されている。組織の変化によって起こり得るソフトウェアへの影響と、それがリーダにとって問題となる理由について、氏らは次のように説明する。
組織の設計は事実上、"ソリューション検索空間"を制限するものです。そのため、組織設計によっては、ある種のソリューションは発見できなくなります。これは経営層にとって、戦略上の懸念となります。
逆コーンウェイ戦略(Reverse Conway Maneuver)の特質に関する質問に答えて、Slelton、Pais両氏は、コミュニケーションラインの必要性を意図的に反映した組織構造が、ソフトウェアやアーキテクチャの複雑性の低減に組織的影響を与えることができる、と論じている。これが万能薬でないのは明らかだが、プロダクトの全般的な品質向上に益するものであることは確かだ。
逆コーンウェイ戦略がソフトウェアデリバリに有効であるという保証はないが、組織とソフトウェアの間のコミュニケーションミスマッチに抗うよりも、ビジネス上の目標達成のために時間と労力を費やすことはできる。
品質に関する定量的指標の有用性について、Bach氏は、一定の価値を認めながらも、プロダクト全体の関連性を考慮した場合、品質指標の大部分が本質的に主観的なものである、と論じている。"測定とはつまり、番号付けをすることだ"、と説明した上で、氏は、プロダクトの品質の真の評価を定量的な指標のみで理解することはできない、と主張する。Bach氏は言う。
私たちが知りたいのは製品の状態なのですが、他のものと同じように、プロダクトの品質を測定することはできません。少なくとも、"プロダクトの品質が優れている"かどうかを顧客、利用者、ビジネス関係者が語っている時に、それらすべてを網羅するような測定は、あらゆる意味において不可能なのです。
"そもそもが不合理な管理プロセスに科学的オーラを纏わせる目的で、数値を儀礼的に使用する"ことに警鐘を発するBach氏は、ソフトウェア品質の測定について次のように述べている。
例えばテストケースのように、数えても意味のないものを数えようとする人たちが後を絶ちません。テストケースはそもそもテストの実行に関連するものを集めたファイルなのであって、それを数えるというのは、ビジネスマンがビル内にあるビジネバッグや引き出しやキャビネットを数えるのと同じことです... "42,564個もあるぞ、すばらしいビジネスだ！"、というように。
このような代用的指標は、その価値を論ずるのではなく、ユーザの幸福度を重視した品質評価の継続的プロセスの一環として、注意を払いながら解釈するべきだ、というのがBach氏の基本的な教示だ。"代用手段"を使って"ゴールを変えたゲーム"をするのは極めて簡単だが、それではエンドユーザの焦点を失うことになる、と氏は警告する。
品質の測定という難しい問題に対峙する時、人々が行いがちなのが、顧客の理解するものから、制限された律法主義的なものに再定義するという方法です。彼らは要件を、厳密な契約条件で定義します。その上で、一連の"受け入れテスト"を作成して、どのテストにも"失敗"しなければ"プロダクトが機能する"ことを証明できたのだ、と主張するのです。
Bach氏は最後に、顧客を満足させるという、プロダクト品質の包括的な指標を見失わないように呼びかけて、自身の記事を締め括っている。
顧客がそのゲームをプレーする(目標の移動や変更を受け入れて、プロダクトに満足したいという要求を諦める)ことに同意して、あなたのプロダクトに対して彼らが本当にハッピーかどうかを気にかけないことにすれば、あなた自身は幸せかも知れません。しかしテクノロジの歴史は、捉え難いが永続的な品質の現実を無視したがために放棄されたプロダクトや衰退した企業で満ちているのです。私個人としては、ユーザに不愉快な思いをさせて金持ちになりたいとは思っていません。あなたもそうですか？