なぜ「バグはあって当たり前」なのか？ IT入札制度の“構造的欠陥”に迫る：SIerはどこから来て、どこへ行くのか

日本の製造業は不良品を出さないためのルール作りに取り組んできたが、ソフトウェア開発では「バグは必ずある」と言われがちだ。これはなぜか。筆者がこの要因の一つだと考える、IT調達制度の構造的欠陥に迫る。

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

この連載について

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

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

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

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

　前回は、新しい開発手法における従来のプロジェクトマネジメント手法が通用しない問題について、機能品質の観点から解説した。

　今回は製造品質を取り上げる。特に、なぜIT業界だけが「バグがあるのは当たり前」という認識に甘んじているのか、その構造的な問題をマイクロサービス環境における自動テストの重要性とともに掘り下げる。

　筆者が特に伝えたいのは、「バグは仕方ない」という業界の諦観は、実は日本におけるITシステムの調達の仕組みそのものが、品質を軽視していることに端的に表れている。公的機関の入札制度をみれば、品質を保証する仕組みが欠如したまま価格競争が行われており、これが業界全体の品質への意識を低下させている。2025年6月に公開した「NHKシステム再構築はなぜ“失敗”したのか　『メインフレーム大撤退』時代の課題をひも解く」もその典型例だ。

なぜ「最低品質」すら保証されないのか　入札制度の3つの根本的欠陥

　官公庁や地方自治体といった公的機関は、ITシステム開発の発注に関して入札制度を基本としている。公共放送であるNHKも例外ではない。建設や電気、ガスといった社会インフラ工事の発注に当たっても入札が多く実施されているため、「どちらも同じようなもの」として捉えている方も多いだろうが、ITシステム開発の入札制度について、筆者は極めて懐疑的だ。

　筆者はIPA（情報処理推進機構）在籍時に入札制度を基本とした業者選定の責任者を務めた経験がある。この時にRFP（提案依頼書）を作成し、提案内容を評価するための項目と基準を明確にした。その評価項目は数十項目に及び、かなり細かく策定した。

　このように書くと、「それだけ綿密に策定すれば、良い事業者を選べるはずだ」と思われるかもしれないが、残念ながらそうなる保証はない。では、入札制度の構造的欠陥がどこに潜んでいるのか。ここから解説していこう。

問題点1：　RFP作成の準備時間が足りない

　まず、募集（RFP作成）に取り掛かるまでの時間的な余裕が不足することが多い。

　RFPに書くべき具体的な業務内容、つまりシステムで何をすべきかは法律が成立しないと定義できない。しかし、法律の成立時期は国会運営などの都合でいつ決まるのかは不透明だ。それにもかかわらず、システム稼働日という期限は先に決まる。

　この結果、RFPを作成する期間が短くなり、要求を詰め切れない状況で事業者を募集することになる。

問題点2：　評価基準を細かく設定しても「不合格」にできない

　評価会議では、外部の有識者を交えて提案してきた1社ごとの提案書に対して全評価項目を1日半以上かけて採点する。しかし、制度運用上、不合格の判定を出すことは難しい。明らかにRFPを無視した提案でもない限り、不合格判定は出せない。そもそもREPに書かれた情報の粒度では、各社の提案の優劣を判定できないことも多い。

　最も重要な実現性や技術力が不足していると想定されるケースもこの例外ではない。技術点の項目で大きく減点しても、「不合格」と断定するには情報量が少なすぎる。「できないこと」を証明するのは極めて困難だ。

問題点3：　実は誰でもシステムを設計できる

　建設業界とIT業界を比較すると、ITシステムの入札制度の問題点が明確になる。

　建築物は一級建築士（全ての建築物を設計できる）、あるいは二級建築士（高さが16メートル以下など設計できる建築物に制限がある）が設計しなければ法律違反になる。建築士は、国家試験に合格しなければならない。つまり設計者のスキルを国が保証しているのだ。

　ITにおいても、IPAが情報処理技術者試験を実施し、合格者には経済産業大臣の名前で資格を与えている。ただし、これらの資格を持たない人がITシステムを設計しても、法律違反にはならない。ITシステム設計に関しては、設計者のスキルを誰も保証していない。

　建設業界では、建築基準法をはじめとするさまざまなルールや仕組みが整備されている。設計図（設計図書）についてもJIS規格やJASS（日本建築学会が発行する建築工事標準仕様書）のような標準的な仕様書やルールによって、品質を確保する取り組みが実施されている。

　建築時には建築主が都道府県など公的機関や民間の指定確認検査機関から「確認済証」を取得する必要がある。指定確認検査機関には建築の専門知識を持つ人材が在籍し、設計が建築基準法をはじめとする法令に適合しているかどうかを確認する。

　さらに、建築物の規模に応じて特定の工程が完了した際には中間検査が実施され、確認済証通りに建てられたことを証明する「中間検査合格証」が発行される。公共工事においては予定価格（非公開の入札価格の上限目安）を算出するための統一基準である「公共工事積算基準」がある。入札に参加する建築会社は発注者である公的機関から公開された設計図書とこの積算基準に基づき、自社の技術力を反映して入札価格を提示する。

　つまり、建設業界における公共工事の入札は、建築物が最低品質の確保を目指して整備された法令に適合しているかどうかを、建築確認や検査というプロセスを通じて公的機関が確認した中で実施される。

　一方、ITシステムの設計手法や品質を規制する建築基準法のような法的拘束力を持つ統一ルールは整備されていない。

　つまり、ITシステムは法的な最低品質基準がなく、検査を実施する第三者検査機関が存在しない中で、金額を重視した入札が実施されている。筆者はこれを発注側である官公庁がプロセスの「公明正大さ」を重視するあまり、技術力のない事業者が受注したり、実現不可能な提案が通ったりといったリスクを見て見ぬふりをする危険な選定方法だと考えている。

「ソフトウェアには必ずバグがある」は本当か？

　話を本題である製造品質に戻そう。

　「ソフトウェアには、必ずバグがある」――これを現在の多くのITエンジニアは、当たり前だと感じている。誠に情けない限りだ。

　その他の製造業に携わるエンジニアは、不良品が世の中に出回るなど許されないと考えている。不良品をいかにゼロにするかを日夜考え、努力している。

　そういう意味では、「バグは必ずある」などと平気で言うITエンジニアは「エンジニア」とは呼べないとまで筆者は思っている。若かりし頃から、筆者は「バグゼロ」を真摯（しんし）に求めてきた。

　では、なぜ「ソフトウェアには必ずバグがある」と皆が言うのか。

バグが発生する最大の原因は？

　バグが発生する最大の原因は、特定の状況（ケース）のテスト漏れにある。つまり、バグを発見するために必要な確認項目（ケース）が足りないまま、テストを実施しているのだ。

　ソフトウェアのテストは、従来の開発方式では2つ存在した。「ホワイトボックステスト」と「ブラックボックステスト」だ。

　規模の比較的大きいITシステムにおけるテストは、「単体テスト」「連結テスト」「総合テスト」の3つの工程からなる。これら3つの工程を経てから納品し、顧客企業が「ユーザー受入テスト」を実施し、合格すればリリースとなる。

　単体テスト工程では、プログラム単体で正しく動作しているかどうかを確認する。この場合は、一般的にプログラムの論理的な分岐を全てテストする「全分岐テスト」（ホワイトボックステスト）が実施される。

　しかし、テスト担当者が全ての分岐テストを確認したかどうかを、第三者が検証する体制は通常整備されていない。「テスト担当者の報告内容は全て正しい」ことを前提に品質を判断せざるを得ない。完全なプログラムチェックを実施するためには、大きな体制を作る必要があるからだ。

ITシステムのスクラッチ開発は「手工業」

　連結テストでは、サブシステムの全てのプログラムを実際に接続して整合性を確認する。100〜200本という膨大なプログラム群を接続してテストすることになる。

　このため、全ての論理的なパターンを上げること自体が大変な作業になる。さらに、全ての論理パターンが明確化されていても、全てのパターンをテストすることは物理的に極めて困難だ。つまりこの連結テスト以降は全分岐テストが実施されないことになる。

　そこでサブシステムを設計したエンジニア、および該当サブシステムに造詣の深いエンジニア、場合によってはユーザーも交えて、業務上検証が必要と思われるテストケースを洗い上げてテストを実施することになる。これを「ブラックボックステスト」と呼ぶ。

　さらに、1000本以上のプログラムを接続する総合テストにおける論理的な組み合わせは天文学的な数字になり、ブラックボックステストに頼らざるを得ない。

　そもそも、スクラッチ開発で実施されてきたITシステムは全て新規で手作りする「手工業」であり、IT産業は前時代的な労働集約型産業だといえる。機械に例えると、ネジ1本から全て手作りで仕上げている。その結果、一つ一つの部品の接続を検証するテストケースは膨大になる。

他の製造業はどう品質を保証しているのか

　では、他の製造業は、どういう形で「バグゼロ」を目指しているのか。

　基本的には、段階的な品質保証を行うことで、不良品「ゼロ」を目指している。

　具体的には、JIS規格などを定めたネジなどの最小部品を製造する会社が、ネジなどの全部品の形状や強度などを網羅的に検証することによって不良製品を検出し、合格した部品のみを出荷する。

　品質保証された部品を組み合わせ、自動車でいえばピストンの部品を製造する会社が同様に網羅的に検証し、合格した部品を出荷する。

　さらに、ピストンなどの品質を保証された部品を組み合わせて、自動車でいうとエンジンという部品を同様に網羅的なチェックを経て、出荷することになる。

　最終的には、エンジンなどの部品を組み合わせて自動車本体を完成させ、同様に網羅的なチェックをした上で、自動車として出荷されるのである。

　このように、品質保証された部品を順次組み合わせながら、網羅的な検査を続けて完成品を作っているのである。基本的には、ホワイトボックステストの繰り返し実施することで、品質保証をしており、ブラックボックステストだけで、最終品質を保証していないのである。

ソフトウェア開発における部品化の重要性

　当然、他の製造業も、かつては一つ一つの部品を手作りしていた時代があり、品質のバラつきに頭を悩ませていた。そこで、品質を改善するためにJIS規格が創設された。

　JIS規格を満たす品質が保証された部品を組み合わせることで新たな部品を製造する。品質が保証されたものの集合体とすることで最終製品の品質が確保されるのだ。さらに部品の仕様がJIS規格などによって公開されることで、部品メーカーが部品を供給し、組立メーカーがそれを使うという製造ラインが構築されてきた。

　自動車などの最終製品を製造するためには、まず膨大な部品を製造する部品メーカーが、それぞれ品質を保証した部品を提供する。そして、組立メーカーがそれらの部品を製造ラインで組み上げることで最終製品の品質を保証している。

　この部品化が、ソフトウェア開発でも主流になりつつある。部品化は、オブジェクト指向の重要な概念の一つである「継承」であると筆者は考えている。

　次回は、部品化による新たな品質保証について詳しく解説する。

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

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