ソフトウェアプロダクトにはもう1つの品質がある
ソフトウェアに対して変更を加える行為は、下手をすると、いわゆる「諸刃の剣」になりかねません。ここで言う「変更」とは、機能追加や機能改善、不具合修正など、ユーザーの価値を高めるために行われる開発全般を指します。片側の刃でこのようなユーザー価値を高めようとする行為が、反対側の刃でソフトウェアそのものを斬りつけてしまう行為となり、その寿命を縮める結果になり得るということです。
これが何を意味するのかを理解するためには、ソフトウェアの品質には2つのタイプが存在することを知っておく必要があります。
見て、触れて、感じられるもの
1つめの品質。それは、ユーザー価値に影響を及ぼす、ソフトウェアが有する特徴です。すなわち、ユーザーが見て、触れて、感じられるもの。洗練されたデザインであり、優れた機能群であり、機敏で快適な動作です。正確であり間違いがないことや、利用したい時にいつでも利用できることもそう。これらの品質が、ユーザーとプロダクトの間で交わされるインタラクションを通し、ユーザー体験として積み重なる。そうやってプロダクトのユーザー価値が形成されていくわけです。
ソフトウェアプロダクト開発における品質の探求は、当たり前のように、ここにばかり集中する傾向があります。それがユーザー価値、ひいてはビジネス価値の探求そのものであるから、それで十分のようにも思えますが、そのように「十分」だと感じてしまうこと自体に問題が潜んでいるのです。その問題とは、ソフトウェアプロダクト開発に携わる多くの人が認識できる品質が、そもそもこの「1つめの品質」のみだということです。もう1つの品質に気づいていない、あるいは、気付いていたとしてもその価値を十分に理解できていないのでしょう。なぜならもう1つの品質は、多くの人にとって、「見えず、触れられず、感じられない」ものだからです。
見えず、触れられず、感じられないもの
ソフトウェアプロダクト開発で注意を向けるべきもう1つの品質とは、ソフトウェア内部の優れた設計やシンプルで理解しやすいコード、適切なアーキテクチャといったものです。それらは、プロダクト開発に携わっていたとしても、ソフトウェアエンジニアでなければブラックボックスです。見ることも、触れることも、感じることもできないでしょう。エンジニアたちがそれを、どのように作り上げているのかを正しくとらえることも難しい。椅子に浅く腰掛けて、腕を組んだまま、睨みつけるようにエンジニアが見つめる黒いスクリーンを肩越しに覗き見ても、そこに映し出されたものが何を意味するのかを理解することはできません。ましてや、リモートワークが主体になった組織では、エンジニアたちがソフトウェアを作り上げている姿を見る機会すらほとんどなくなりました。
この2つめの品質は、ユーザーにとって「見えず、触れられず、感じられない」ものであるから、ユーザー価値とは無縁のようにも思えますが、そうではありません。なぜなら2つめの品質は、ソフトウェアの開発効率に強く影響するものだからです。「変更のスピードのための品質」と言っても良いかもしれません。この品質が良ければ、新たな価値をユーザーに早く届けられます。逆に品質が悪ければ、新たな価値をユーザーに届けるために、多くの時間を要してしまいます。さらに言えば、品質が悪いにも関わらずあまりに無理をして早く価値を届けようと急ぎすぎると、1つめの品質に悪影響を及ぼすことさえあります。その結果、ユーザー価値を逆に貶めることになってしまうでしょう。
ソフトウェアの変更が諸刃の剣となる時
「1つめの品質」「2つめの品質」という呼び方をいつまでも続けるのは煩わしいので、以降は正しい名前で呼ぶことにします。これら2つの品質は、それぞれ「外部品質」「内部品質」と呼ばれるものです。
冒頭で述べた「諸刃の剣」となるソフトウェアの変更とは、外部品質に対して動機を持つ変更であり、内部品質に対して関心がない変更です。しかし、ソフトウェアに変更を加える限り、内部品質は変化します。変更の動機が外部品質であるか、内部品質であるかは関係ありません。そのうえ、外部品質の良さと内部品質の良さは、連動しません。外部品質がいくら優れたものになろうとも、内部品質はボロボロになることもあり得ます。そして、内部品質に注意を向けられずに作られたソフトウェアは、当然ながら内部品質が劣悪な状態になってしまいます。これが、諸刃の剣によってソフトウェア自体を傷つけてしまう状況です。
これは例えるなら、アスリートに対し、結果だけを求めて無謀なトレーニングを繰り返させるようなものです。本番の試合では優れた成績を残せるかもしれませんが、それと引き換えに健康状態を害し、選手生命を縮めてしまう行為です。それがドーピングという手段なら尚更でしょう。ソフトウェアも、このような無謀な変更を繰り返していると、その健康状況たる内部品質を害し、寿命を縮めることになるのです。それはすなわち、開発効率が低下し続け、もはや変更することが実質的に不可能となった状態です。
変更のスピードに感じる矛盾とプレッシャー
内部品質に注意を傾けようとすると、矛盾を感じはじめるかもしれません。内部品質への努力は、ソフトウェアの変更を遅くすると感じるからです。つまり、開発のスピードを得るために、開発のスピードを犠牲にしろと言っているように感じるのです。そこで関係者の意見が分かれてしまいます。内部品質を良くしたほうが速いのか、内部品質を気にしない方が速いのか。しかし一方で、要求された外部品質さえ満たせば、例え内部品質がボロボロであってもリリースすることはできます。そもそも、「ボロボロ」であるかどうか、内部品質の善し悪しは評価が難しい。だったら……。ソフトウェア開発の、恒常的な期日へのプレッシャーは、そんな誘惑を選択する後押しとなってしまいます。
このような矛盾を感じてしまうのは、想定しているスコープが狭いのです。そのイメージを示したのが、下のグラフです。このグラフでは、既存のソフトウェアに対し、一定の間隔で、一定の規模の変更を加えていくことを想定しています。
グラフ中の「内部品質軽視」の開発では、変更の回数を追うごとに内部品質が悪化していき、変更のコストが大きく積み上がっていきます。一方で、「内部品質重視」の開発では、初期の変更コストが「内部品質軽視」の開発より高くなってしまいますが、変更を重ねても、変更のコストが大きく膨れ上がることはありません。ただ、それでも内部品質は徐々に悪化していくために、わずかにコストが高くなっていきます。しかし、この程度の増加であれば、手遅れになる前に一気にクリーンアップしてしまうことも可能でしょう。
リリースサイクルの変化と「保守フェーズ」の終焉
変更のスピードの獲得は、近年のソフトウェアプロダクトにとって益々重要となっています。SaaSやモバイルアプリに代表されるように、ソフトウェアプロダクトはインターネットを介して提供するサービスモデルが主流となりました。旧来のパッケージ販売をしていた頃のような、1年やそれ以上のサイクルでのバージョンアップでは、ユーザーや顧客の期待に応えられず、市場での競争で戦えません。日々の変更による漸進的な進化が求められているのでしょう。
それに、リリースサイクルが今よりも長かった頃のソフトウェアにとって、内部品質はそれほど重要ではなかったようにも思います。開発期間が長い分、マンパワーで押し切れたからです。期日が近づけばプロジェクトは当たり前のように毎度炎上し、それを残業や休日出勤でカバーしていました。また、予算や人員を潤沢に抱える組織であるなら、プロジェクトに多くの人を投入するのは常套手段でした。もちろん、こういったやり方が常に成功したわけではありません。
しかし、リリースサイクルが短くなった今、こんなやり方は続けられません。そんなことをすれば、あっと言う間にエンジニアは燃え尽きてしまいます。また、短期間の開発に大量の人を投入することも現実的ではありません。マンパワーで押しきれないという点からも、内部品質によって開発効率を向上させることに意味があるのだと言えます。
そういった背景からも、私自身の周辺での「保守」という言葉は、もはやフェーズを指すものではなくなり、単に「変更の種類」を指すものとなりました。開発も運用も保守も同一チームが担い、リリースサイクルも短くなった今では保守と呼べる明確なフェーズも無く、それを専任するチームも存在しません。保守とは単にバグフィックスや、各種ソフトウェアおよびプラットフォームのEOL対応などを指す言葉になったのです。
エンジニアの単なる自己満足なのか？
ソフトウェア内部の品質を高めようとする活動に対しては、「エンジニアの単なる自己満足だ」といった批判的な声を時々聞くこともあります。その背景には、本記事で取り上げたように、内部品質というものが理解されにくいことがあるのでしょう。ユーザー価値に直接的な影響を及ぼさない品質に、存在意義があるのか。間接的な影響があると言うのなら、その効果を数値化できるのか。内部品質が良いというのは、何をもってそう言えるのか。そういったことを明確に答えることが難しいのです。そもそも、内部品質が良いからと言って、外部品質が良くなるわけでもありません。結局のところ、扱っているソフトウェアプロダクトが成功しない限り、こういった批判は避けられないのかもしれません。
しかし、短いリリースサイクルがもたらす本質的な価値は、短期間でユーザーからのフィードバックが得られるという点にあるはずです。リリースしたものがユーザーに受け入れられなければ、すぐに変更を加えたり、方向性を変えられる。こういったアジリティの獲得の源泉こそ、内部品質がもたらす真の価値だと思います。