【後編】DX時代のIT品質とは？　-リーヌスの法則と品質の守備範囲-

前半ではITシステム品質についてもDX（デジタル変革）に適した考え方をして欲しいことを述べました。この後半では、トピックス的な2つの話題を取り上げてみます。

【前編】DX時代のIT品質とは？-「価値」に目を向ける-

バグが全部なくなるまで製品やサービスを提供しちゃいけないの？

ITシステムの新規開発や変更の際の問題点（いわゆる“バグ”）は、そのITシステムを使い始める前に除去しておきたいというのは当然のことです。それを否定するつもりはありません。ただ、従来の品質への取り組みでは、この不具合の除去に極端に偏っていたのでは無いかという問題意識を前半で述べました。

サービス提供した後でITシステム障害の原因になる様な問題点は除去しないといけないのは当然と言えば当然ですが、事前に決めた仕様と徹底的に付き合わせて（検査して）100％の「仕様通り」を達成しないといけないのでしょうか。言い換えると、「100％仕様通りを宣言すること」が目的化して、微に入り細に入り、詳細な仕様を強引に事前に決めようとしていないでしょうか。

Linux開発者である Linus Torvalds が言ったとされる「リーヌスの法則」というのがあります。余談ですが、Linusさんの読み方が「リーヌス」か「リーナス」か「ライナス」か、Linuxが普及し始めた頃に話題になったことがありますが、それが決着したのかどうか定かではありません。ここでは「伽藍とバザール」の山形浩生さんの日本語訳（[4]） に合わせました。リーヌスの法則とは次の様なものです。

「目玉の数さえ十分あれば、どんなバグも深刻ではない」 

このくだけた表現はOSS（オープンソースソフトウェア）関係者の間では有名ですが、別の言い方もあります。 

「ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず」 

こちらはちょっと堅苦しくて、ITエンジニアにしか通じないでしょうから、前者のカジュアル表現の方がいいでしょう。さらに、別の表現もあります。伝えたいことはほぼ同じです。こちらが一番わかりやすいかもしれません。

「はやめのリリース、しょっちゅうリリース」 

この法則が主張していることは「バグがあっても誰かがすぐに見つけてくれるし、その方が手っ取り早いから、多少のバグは残っているかもしれないけど、とっととリリースしちゃおうぜ」です。（筆者流の解釈が色濃く出ていますがご容赦を）

そして、OSS関係者の界隈ではこれがうまくいっています。少なくともOSS関係者はそう思っています。このやり方（バザール方式）は、OSSの開発体制が脆弱なためにそうせざるを得なく、やむを得ずやっている逃げ道というわけではありません。むしろこの方が優れたやり方だと信じられています。　 

ITシステムがどんなに複雑で大規模なものだったとしても、それ自体が目的なのではなくて、結局は何かを達成するための手段であり部品です。ならば、ITシステムの品質が「合格かどうか」は、使ってくれる人たちに一部委ねることも検討する価値はあるんじゃ無いでしょうか。ただし、どこでこの法則を適用するかはよく考えないといけませんけれど。

ソフトウェアは品質に関わるほんの一部

このコラムでは、前半と後半を通して「ITシステムの品質」という言い方をしています。また、ITシステムに問題があるときに「バグ」という言葉もよく使っています。「バグってソフトウェア（プログラム）の問題点のことだよね？」というのは正しいのですが、ITシステム品質として考えないといけないのは、ソフトウェアだけではありません。けれどなぜか、ITシステムの品質＝ソフトウェア品質に矮小化して考えられてしまうことが多いようです。

昔々、メインフレームと呼ばれていた共通の稼働基盤の上にすべてのアプリケーションサービス（ソフトウェア）を稼働させていた時代、それぞれのサービスの品質の差は開発したソフトウェアの品質の差であって、それ以外の部分では差が無くて、しかも「誰かにおまかせ」で良かったのかもしれません。

しかし、提供するITサービスごとにハードウェア環境、ネットワーク環境、ミドルウェア、運用組織、さらにはユーザの価値観まで違う時代に、事前に決めた開発ソフトウェアの仕様とのズレを一生懸命洗い出すアプローチは、品質のほんの一部しか見ていないことになります。

この環境変化はつい最近に（DXが騒がれるようになってから）そうなったわけではなくて、平成になった頃にはすでに変わり始めていて、21世紀になった頃にはすっかり変容していたはずです。令和になったこの時期に、いまだに「品質＝ソフトウェアの守備範囲」だと扱ってしまうのは大きな見落としにつながる危険があります。

品質課題の守備範囲はこれらの全てのはず
（[5]JISA「2023 年版 情報サービス産業における情報技術マップに関する調査報告」より IT ディレクトリの構造および SI 要素技術)

「非機能要求グレード」（[6]）というガイドがあります。これは、ITシステムが達成すべき信頼性（可用性や耐障害性）や性能などを可視化するアプローチを示したものですが、ソフトウェア、IT基盤（ハードウェアやネットワークなどを含む基盤環境）、そして運用面も含めた総合的な品質課題を取り扱ったものです。

Googleが提唱しているSRE（[7]）は、提供するITサービスの運用品質への取り組みと言えるでしょう。また、少し違う視点では、インターネットでの大規模DDos攻撃（Distributed Denial of Service attack）も通信事業者の通信障害による影響も品質問題です。これらの、IT基盤、運用、通信環境の問題は、ソフトウェアのバグと比べてどうでもいい問題というわけではありません。ITシステム品質を見落とし無く、全方位的に見直していただければと思います。

さいごに

ITシステムは昔に比べると明らかに複雑化・高度化しているので、分業体制が当たり前になっています。それなのに、DX（デジタル変革）が叫ばれて、ユーザ企業や事業部門による内製化という要求も出ています。ITシステムの品質とは何か、そして見るべき所がどこかは、以前と同じ考え方では済まなくなっていますし、ITベンダにおまかせしておけば大丈夫というわけでは無くなっています。

ITシステム品質への取り組みは、対処（問題点の除去）ではミクロな視点での作業ももちろん必要です。たとえばプログラムコードを1つずつ追いかけないとプログラムのバグは取れません。この部分は専門スタッフに委ねる部分でしょう。

DX（デジタル変革）の目標を見定める方は、システムの成長や見直しの時間軸、対象範囲の空間軸の両方について、広い視点でITシステム品質をとらえていただくことを望みます。

この後半で取り上げた2つの話題は、IPAがメンバとして参加しているDXITフォーラム（[1]）の有志が集まった「DX時代の品質課題を考えるワーキンググループ」がまとめたコラム集（[3]）で筆者が記したものを元に、DX SQUARE向けに加筆しました。このコラム集には他にも興味深い内容がありますので、お読みいただければありがたく思います。

参考情報