IT業界の品質保証、どう変わる？ “バグがあっても当たり前”からの脱却方法を考察：SIerはどこから来て、どこへ行くのか

他の業界では許されない「バグがあって当たり前」という考え方が、IT業界では常態化してきた。新しい開発手法が主流になるにつれて品質保証の在り方はどう変わるのか。元IPA参与の筆者が考察する。

[室脇慶彦，SCSK株式会社]

この連載について

　ユーザー企業にとって、SIerはITシステムの導入から運用、故障時の対応や更新などに欠かせない存在です。

　しかし、その関係性はと言うと、対等なパートナーと言うよりも、ユーザー企業はSIerに対して丸投げしがちで、SIerも「お客さまであるユーザー企業の要望は断りづらい」ために、ユーザー企業のITシステム全体の最適化よりも、その場その場のニーズへの対応を重視しがちな「御用聞き体質」が指摘されてきました。

　こうした中、DX案件の増加やIT人材の慢性的な不足、ユーザー企業の内製化志向などのさまざまな環境変化によって、ユーザー企業とSIerとの関係は変わらざるを得なくなりつつあります。

　この連載を通じて、SIビジネスを取り巻く構造的な問題を掘り下げ、ユーザー企業とSIerが目指すべき関係の在り方を探っていきます。

　前回は、情報処理の促進に関する法律（情促法）の改正について解説した。従来、IPA（情報処理推進機構）は経済産業省所管の政策執行機関にすぎず、他省庁が所管する業界に対してガイドラインの順守を求める法的根拠はなかった。しかし、内閣総理大臣が主務大臣に加わったことで、IPAは省庁横断的にIT政策を推進する唯一の政策執行機関へと変貌した。

　この法改正は、IT業界が長年抱えてきた「品質問題」にも影響を及ぼす可能性がある。前々回で触れたように、「バグがあって当たり前」という認識は、IT業界以外では通用しない。製造業をはじめとする他産業では、品質に関する基準や検査体制が整備されている。ところがIT業界では、ソフトウェアの品質保証に関する統一的な基準や規制の整備が十分ではなかった。IPAの位置付けが変わった今、ITシステムの品質に関するガイドラインが業界横断で求められる時代が来る可能性もある。

　では、新しい開発手法であるマイクロサービスアーキテクチャ（MSA）において、品質はどのように保証すべきなのか。本連載で繰り返し述べてきたように、従来の「モノリスシステム」（一枚岩の巨大システム）は、ユーザー企業にとって「高い費用」と「長い開発期間」を強いる上に、小さな改修でも広い範囲に影響が及ぶために、ビジネス環境の変化にITシステムが追い付かない状況をもたらすデメリットの大きなシステムだった。

　これに対し、独立した小さなサービスを部品のように組み合わせるMSAでは、品質保証済みの「部品」を再利用することで、開発コストと期間を大幅に圧縮できる。ユーザー企業にとっては、市場の変化に素早く対応したシステム改修が可能になり、DX推進の土台が整うことを意味する。ハードウェアの制約から解放された今、これが開発の主流になると筆者は考えている。今回は、この新しい開発手法において品質をどう保証するかを掘り下げる。

「バグがあっても当たり前」をどう変える？

　筆者は長らく、日本のソフトウェア開発における生産性向上を重要な課題だと認識していた。2010年頃、米国におけるソフトウェア開発に関する調査を開始したとき、どうしても答えてもらえない質問があった。しかも、その答えが得られない質問が発生する案件は、年を追うごとに増えてきた。

　それは、対象となるITシステムの規模の質問だ。「対象となるITシステムのステップ数は幾つですか」あるいは、「対象となるITシステムのファンクションポイントは幾つですか」といった質問だ。

　モノリスシステムの構築経験しかなかった筆者や同僚にとって、ITシステムの規模は開発における生産性を測る上で必要最低限の情報だった。ところが、この質問をすると皆一様に怪訝（けげん）そうな表情を浮かべた。「何を聞いているのか」という顔である。

　さらに質問を繰り返すと、「規模は分からないが、テストケースの総数なら答えられる」と異口同音に返ってきた。

なぜ規模を聞くことが「ナンセンス」なのか

　当初、筆者には彼らがなぜこう回答するのか、その意味が分からなかった。しかし、MSAを理解するにつれて理由が明らかになった。

　そもそも、MSAを前提とする開発では、部品として活用するマイクロサービスの規模など知る由（よし）もない。品質保証された部品は、開発対象でもテスト対象でもないからだ。つまり、該当マイクロサービスの規模を聞くこと自体がナンセンスな質問だった。

　では、なぜ彼らはテストケース数を挙げたのか。それは、マイクロサービスを作るための工数を算出する根拠がテストケース数にあるからだ。

　彼らにとっての「開発規模」とは、「部品」以外に新たに作る部分を指す。その規模を測る指標は、ステップ数ではなく追加される論理の分岐数なのである。分岐数が多ければテストケースも増える。だからテストケース数が見積もりの根拠になるというわけだ。

　だからテストケース数が見積もりの根拠になる。つまり、MSAでは従来のステップ数やファンクションポイントに基づく見積もり手法は通用しないのだ。

生産性が従来の10倍以上向上

　いずれにしても、システム開発の生産性を上げるためには「部品」の比率を高め、新規に開発する論理を減らすことが重要だ。

　MSAでは、新規で開発する総量を従来の開発手法の10分の1以下に抑えられると筆者は考えている。ゆえに、生産性は10倍以上向上する。同時に品質面で言うと、テスト対象がシステム全体ではなく、限定されることになる。

　MSAにおけるテストは、ソースコードが正しく動いているかどうかを確認するためのホワイトボックステストが中心となる。しかも、そのテストケースは、従来と比べれば極めて少ない。

　さらに、追加開発分のソースコードを入力すれば、AIを活用して全てのテストケースを洗い出すことが可能だ。テストデータはAPIの入出力だけであり、簡単な辞書を学習させればAIで自動作成できる。テスト結果の期待値についても、設計情報をデータ化することで、同様にAIで自動作成が可能になる。

　実際、マイクロサービスの開発では、新たに追加開発されたソースコードとともにテストケースもセットでライブラリー管理されている事例もある。

製造業の考え方に学ぶ品質保証

　MSAでは、それぞれの「部品」とのインタフェースはAPIであり、疎結合で構成されている。各「部品」はホワイトボックステストで品質保証され、それらを組み込んだ本体も同様にホワイトボックステストで品質保証される。さらに上位のマイクロサービスに対しても品質保証をしているもので構築されている。

　製造業では、品質保証された部品を組み合わせることで最終製品の品質を確保する仕組みが、長年かけて整備されてきた。具体的には受入検査、工程内検査、最終検査という多段階の検査プロセスを経る他、ISO 9001などの品質マネジメントシステムに基づく体系的な管理体制が整備されている。MSAも同様の考え方に基づいており、品質保証された「部品」を組み合わせることで、全体の品質を効率的に担保できる可能性がある。さらに、機能間のブラックボックステストを実施することも可能だ。これについては、各機能での工夫が必要になると考えられる。

　ただし、製造業との根本的な違いも認識しておく必要がある。ソフトウェアは一度作成すれば複製コストはほぼゼロであり、物理的な劣化も起きない。出荷後でも比較的容易に修正可能だ。この「後から直せる」という特性が、皮肉にもIT業界で「バグがあって当たり前」という認識を生んだ側面があると筆者は考えている。MSAにおける品質保証を考える際には、これらの違いを踏まえる必要がある。

MSAの「落とし穴」とは？

　製造業では、1つの部品を作るために仕様確認から設計、製造、検査まで複数の担当者が関わり、相互にチェックする体制が整っている。

　ところが、ソフトウェア開発の場合はどうか。1つのチームで複数のマイクロサービスを同時に作成するため、1つのマイクロサービスに対しては開発者1人が担当し、設計から開発まで一貫して担うケースが出てくる。

　ここに「落とし穴」がある。疎結合でマイクロサービス単位にリリースできる環境では、開発者が何らかの勘違いをしたまま設計した場合、そのまま開発が進みリリースされてしまう可能性がある。たとえAIがチェックしても、開発者による当初の勘違いを「是」として判定する可能性がある。AIは設計情報やソースコードの「論理的な矛盾」を検知することは得意だが、その設計自体が「ユーザーが求めている真の意図」に合致しているかどうかという、前提となる仕様の誤りは判断できないからだ。つまり、AIによるチェック体制は、開発者の勘違いで進む開発の歯止めにはならない。

モノリスシステムでは検出できていたバグが見逃される

　従来のモノリスシステムでは、連結テストや総合テストは開発者以外の第三者によって実施されていた。そのため、勘違いで開発されたプログラムはバグとして検出されていた。しかし、MSAの場合は、このチェックが実施されない可能性がある。これは大問題だ。

　そこで、必要になるのが2人がペアで設計・開発する「ペアプログラミング」だと筆者は考えている。別人格の技術者が同一の勘違いを起こす確率は低いと想定されるからだ

　実際、Pivotal Software（ピボタルソフトウェア）という会社のエンジニアに筆者の考えを確認したところ、「そうなんですよ。なかなか理解していただけないのですが……」という回答が得られた。

　Pivotalは、クラウドネイティブな開発環境をサービスとして提供している会社だ。顧客とプロジェクトを共同実施し、Pivotalの開発環境でプロジェクトを進めることによって、サービスの有用性とクラウドネイティブな開発方式への理解を促している。顧客が開発したソフトウェアの利用者が増えるごとに収益が上がるという面白いビジネスモデルだ。本当かどうかは分からないが、「『Salesforce』などを育てたのもわれわれだ」と説明された。

2人で開発すると余計な工数がかかる？

　読者の皆さんも気になっているだろうが、2人で開発すれば工数がかかるのは当然だ。ただし、MSAでの開発は「部品」を活用することによって開発工数が大幅に抑制される。テストの工数も削減され、連結テストなども削減される。全体的な工数から見ると、本工程での重複は非常に小さいと推察される。

　特に基幹系のITシステムでは品質確保が極めて重要であり、ペアプログラミングの活用は必須だと筆者は考えている。

　いずれにしても、MSAにおける品質を保証するためにペアプログラミングは重要だ。クリティカルなITシステムではベテラン技術者2名で、さらにクリティカルなITシステムの場合は3人の技術者が担当するなど、ターゲットとなるITシステムに応じて品質保証方式を設計することがプロジェクトマネジャー（PM）の重要な仕事になるだろう。

SBOMによる部品管理も重要に

　もう一つ重要なのが部品管理だ。マイクロサービスを自機能のオブジェクト（呼び出し先）として活用する場合、該当するマイクロサービスが修正されたら、自サービス側のマイクロサービスの整合性を確認し、必要に応じて更新しなければならない。そういう意味で、各マイクロサービスの部品管理が重要になる。いわゆるSBOM（Software Bill of Materials：ソフトウェア部品表）の整備も、品質を確保する上で欠かせない。

　ソフトウェアの生産方式だけでなく、プロジェクトマネジメント技術の革新も求められる。当たり前だが、これはプロジェクトを成功させるためには避けて通れないポイントだ。

　今回は、MSAを採用するためには見積もりや品質保証などの革新が必要であることを述べてきた。次回は、開発方法論についてお話ししよう。

著者紹介：室脇慶彦（SCSK顧問）

むろわき　よしひこ：大阪大学基礎工学部卒。野村コンピュータシステム（現野村総合研究所）執行役員金融システム事業本部副本部長等を経て常務執行役員品質・生産革新本部長、理事。独立行政法人　情報処理推進機構　参与。2019年より現職。専門はITプロジェクトマネジメント、IT生産技術、年金制度など。総務省・経産省・内閣府の各種委員等、情報サービス産業協会理事等歴任。著書に『SIer企業の進む道』（日経BP）、『プロフェッショナルPMの神髄』（日経BP）など。