Mail News Archives

TQM

ハードウェアとの違いを踏まえたソフトウェア品質保証　　～ソフト開発の経験が無い管理者の方へ～＜2020年01月21日＞

ソフトウェア品質管理研究会の紹介動画をYouTubeで公開中！

IoT時代を迎え、ソフトの重要性は益々高まるばかりです。様々な機器がインターネットで繋がり、協調して動作しなければなりません。これまでハードのみを製造していた、または、機器単体で動作するごく小規模なソフトを搭載した製品を製造していた企業が大規模化するソフトの品質保証に手を焼いているという話をよく耳にします。よく分からないので、という理由でソフトの品質保証をソフト開発部門に丸投げしてしまっている企業が少なくないようです。そして、ソフト開発部門は適切な開発方法や品質技術を習得する余裕も与えられないまま、ひたすら人海戦術でこなし、疲弊しきっているでしょう。

とは言え、ハード開発や製造現場で培ってきた品質管理、保証の方法をそのままソフトに適用するのは誤りです。筆者は主にソフトの品質改善などに取り組んで来ましたが、ハードを含む製品全体の品質保証に従事していた経験もあります。ソフト、ハード両方の現場を見てきた中で、両者の違いを踏まえた上で、ソフト品質を保証する上で特にすべきことをソフトウェア品質管理（SQiP）研究会の分科会の紹介と併せて解説します。

1.要求仕様を明確化する技術を習得する
ソフト開発において作りたいものはシステムの機能やサービスです。これらは目に見えない概念的なもので、ハードの設計図面のように厳密な記述方法で表現するのが困難です。ユーザーが求める機能やサービス、または、暗黙のニーズや制約事項を総称して、「要求仕様」や「要件」と呼びます。従来は、それまでに人力で行っていたことをシステム化することが多かったため、概念的とは言え、何とか想像しながら記述することが可能でした。近年では、インターネットやIoTだからこそ可能となった全く新しいサービスが登場しています。つまり、想像ではなく創造しながら記述をしなければなりません。ユーザーと開発者がそれぞれ創造しながら検討する要求仕様を齟齬無く正確に記述することは非常に困難なことです。
このような特徴のため、文書化された要求仕様には曖昧さや漏れが、必ずと言ってよいほど存在します。これを放ったまま開発が進み、開発終盤のテストやユーザーの利用時に発覚した場合は、かなり手痛いロスコストが発生します。これを防ぐためには、「レビュー」という技術が有効です。文書をきちんとしたプロセス、技法で精査をして、ロスコストを防ぐことができます。この技術は「ソフトウェアレビュー」研究コースで深めることができます。

また、社会の変化スピードが激しい昨今では、開発の初期段階で全ての要求仕様を明確にするのが困難または得策ではないケースも生じています。そのような場合に「アジャイル」開発といって、要求仕様を段階的に明確化しながら、少しずつ開発を進めていく開発スタイルを取る組織も増えてきました。家を建てる際に、最初から全体の設計図は造らずにお客さんの要望を少しずつ聞き入れながら、増築して行くようなものです。ハード開発ではご法度に思えるスタイルですが、柔軟性に富むソフト開発では可能となります。しかしながら、いくらでも柔軟にして良い訳ではなく、要求仕様の変化の度合いと求められる信頼性を鑑み、柔軟性と規律のバランスを取る必要があります。こういった新たな開発スタイルの品質について研究をするのが、「アジャイルと品質」研究コースとなります。

2.開発工数見積の手段を持つ
「なぜ、ソフト開発は遅れてばかりなんだ！」という上役のセリフを聞くことはありませんか？無理もないことです。実はソフト開発にとって一番難しいのは適正な開発工数を見積ることなのです。この難しさが品質にも大きな影響を与えます。弊社は電子楽器を製造しています。例えば、同系列の電子楽器の新製品を開発するに当たって、ハードの開発量は物理的制約から、それほど大幅に増減することは有りません。つまり、開発と品質保証に必要な工数の変動もそれほど大きくはありません。ところが、ソフトはそういった物理的制約が有りません。機能を増やしたければ、いくらでも増やすことができます。組込機器はROM容量の制約は有りますが、価格はどんどん低下していますので、容量を増やす対応はさほど困難では有りません。結果的にソフトの開発量は同系列の製品でも1桁ほど異なることがあります。

開発しなければならない物の量を誰も見当もできていない状態で、開発がスタートするというのがソフト開発の宿命で、悩みの根源です。まずは、ここにメスを入れなければなりません。ところが、そもそも開発量を把握する術を持っていない組織が多いのです。参考までに弊社ではソフトの開発量を新規に作成したプログラムの行数で測定しています。ITシステムでは入出力画面の数を機能の量と見立て、ファンクションポイントという指標で開発量を把握する組織もあります。いずれの方法も一長一短有りますが、とにかく何らかの手段で開発量を把握することが、適正な工数見積の第一歩です。このように定量的にソフト開発を把握するのが、「メトリクス」という技術です。メトリクスとは指標やデータという意味合いです。「ソフトウェアメトリクス」演習コースで、この技術を習得できます。

3.正当なエンジニアリングを適用する
開発量の変動もそうですが、開発されたものの質の変動が更に大きいのもソフトの特徴です。ソフト開発は殆ど開発者の頭の中での知的作業です。開発スキル、製品知識、精神状態、等々によって出来栄えが相当に変わってしまいます。この知的作業を製造ラインの作業のように画一的に手順化することは出来ません。とは言え、詩を書くように自由気ままにプログラムを書いてよい訳でもありません。正当な「エンジニアリング」を適用して、制約と自由度のバランスの取れた開発を行う必要が有ります。「ソフトウェア工学の基礎」演習コースで、ソフト特有のエンジニアリングを習得することができます。

4.テスト技術者を育成する
ハードの検証や試験方法は、JIS等の公的規格や社内基準、手順として確立しているものが多いです。あとは部品の実績を考慮した試験項目の取捨選択や、出荷先の違いに応じて試験条件の調整を行うぐらいで、実施内容は比較的固定化されています。それに対し、ソフトの場合は新しい機能を追加した場合は、その部分のテスト項目を毎回新規に作る必要があります。また、テスト項目を作る際に考慮しなければならない入出力、条件、機器の状態といったパラメータが非常に多く、その洗い出しに漏れがあればテスト項目の不足となります。洗い出しがうまく行ったとして、深く考えずにパラメータを振ってテスト項目を作成すると、現実的に実行不可能な項目数になってしまうこともあります。実行可能な数に抑えながら、不具合を発見できる可能性が高いテスト項目を作ることは、高いレベルの知的作業となります。昨今では、テスト項目を作成するにも分析～設計といった開発プロセスを踏む組織も多くなっています。

また、テストは新規に追加された機能だけ行えば良い訳ではありません。ソフトはある機能を追加、変更した場合にその影響がどこまで及ぶかの分析が非常に困難なため、結果的に既存機能に関しても一通りテストせざるを得ません。前述の通り、物理的制約の無さから、機能はモデルチェンジの度に累積的に増える一方なので、テスト量も増える一方です。また、PCやスマホアプリの場合、OSがバージョンアップする度に過去にリリースした製品もテストをして動作保証しなければなりません。これも製品をリリースする度に累積的に増えていきます。この雪だるま式に増えるテスト量を人力で行うのは、もう限界に達しつつあります。テストを自動化しなければ、そのうちに立ち行かなくなることは明らかです。これらのことを推進するには、テスト要員として単に頭数を揃えれば済む話ではなく、テスト技術者を育成する必要があります。「ソフトウェアテスト」研究コースで、テスト技法の習得や研究を行うことができます。

5.ソフト特有の品質保証に対処する
IoT時代となり、一番の脅威はセキュリティです。あらゆる機器がインターネットに繋がることで、自社の製品が攻撃を受けたり、逆に加害者にさせられてしまう危険性もあります。自社の製品は機密情報や個人情報は扱ってないから、と油断してはいけません。例えば、Dos攻撃（攻撃対象システムに高負荷を与えるなどして機能不全を起こさせる）の踏み台にさせられるリスクがあります。踏み台となった自社製品が他社システムをダウンさせ損害が発生した場合の責任はどうなるでしょうか？企業として当然行うべきセキュリティ対策を講じていなかった場合に自社の責任は無いと言い切れるでしょうか。また、AIによる自動運転技術もそう遠くはない将来に実現するでしょう。ロボットが一家に1台という時代もやがて来るかもしれません。ちょっとした誤動作が凶器ともなり兼ねない機器と一緒に暮らしていく時代が目前です。そういった製品を扱う会社ではセーフティの作りこみが不可欠です。「セーフティ&セキュリティ」研究コースでは、開発上流段階からセーフティ、セキュリティを高めるための方法論を習得、実践できます。

品質が良いとは、不具合、セキュリティ問題がないことだけではありません。魅力品質も重要です。製品やサービスの魅力を向上させるために多くの企業がUX（User Experience、顧客体験）に着目しています。そして、UXを左右するのは大部分がソフトウェアとなります。製品、サービスのUXを向上するには、要求仕様の検討時にユーザーの調査が不可欠で、画面や操作子の設計も重要です。また、UX視点での製品、サービスの評価もできなければなりません。これら、調査、設計、評価の各段階で活用できる手法を学ぶことができるのが、「UX（User Experience）」演習コースとなります。

6.進化するテクノロジーにキャッチアップする
IoT、AI、DX等々、IT業界は次々に新しいキーワードが生まれます。ハードウェアメーカーがこれらにすぐに飛びつき、ビジネスに活かさなくてはならない訳ではありませんが、無視して良い訳でもありません。もちろんIoTはハードウェアメーカーとして静観出来ませんが、自動運転のコアテクノロジーとして進化著しいAIについてもキャッチアップが必要でしょう。
AIシステムの特徴として、システム内部がブラックボックス化しており、入力に対する出力が厳密に定義できない点があります。例えば画像認識を考えてみましょう。ある画像を入力して、それが何なのかを認識して、その名称を出力するというシステムです。昨今の画像認識技術はかなり高いレベルにありますが、それでも100％にはなりえません。つまり、誤認識をした場合でもシステムの欠陥と言いきれないのです。このようなシステムをテストするには既存のテスト技術だけでは不十分で、パラダイムシフトが不可欠です。AIシステムの品質保証にAIを活用するといったコンセプトも必要になってくるでしょう。新設の「人工知能とソフトウェア品質」研究コースで、このような新しいテクノロジーについても品質という観点でキャッチアップして行きます。

7.ソフト開発プロセスを構築し、プロセスを監視する
ハードは開発から生産までに段階があり、それぞれ複数の部門や業者が担当します。例えば、メカ設計者が図面を書き、金型メーカーが金型を製作し、生産技術部門が成形条件を決めて、生産部門が作業手順書を作る、という具合です。これらを全て一人で行うということは一般的に考えられません。そのため、各段階で行うことや入出力を明確にするというプロセスアプローチが必然です。ところが、ソフトの場合は、ある機能の要求仕様の提示を受けたら、あとは設計、コーディング（プログラミング）、テストといった各段階を全て一人の開発者が担当するというケースが珍しくありません。私は以前に開発計画書の中で、ハードは緻密に各プロセスやマイルストーンが記された線表が引かれているのに対し、ソフトはコーディングとデバッグの2本の線しか引かれていないスケジュールを見たことがあります。これでは、進捗状況が見えずに開発が遅れるのも当然ですし、途中段階での品質確認もできません。なので、半ば強制的にプロセスアプローチを導入する必要があります。こういったプロセスを考え、文書化するには、専門の知識が必要になります。単にソフト屋としてプログラムを書いたことがあるだけでは不十分です。このような専門家をSEPG（Software Engineering Process Group）と言います。

また、プロセスを決めたとしても、前後のプロセスを実施する人が同じであれば、ないがしろにして元のやり方でやっても誰も気づくことはありません。例えば、設計、設計書レビュー、コーディングと３つのプロセスに分けたとしても、それぞれのプロセスがきちんと行われたかを誰もチェックしなければ、軽く設計メモを作って、レビューはやったことにして、あとはひたすらコーディングということがまかり通ってしまいます。そのため、各プロセスがきちんと行われたかを確認する人が必要になります。そのようなスタッフをSQA（Software Quarity Assurance）と言います。

ただでさえ人が足りないソフト開発部門にSEPG、SQAといったプログラムを書かないスタッフを置くのは非常に大きな決断が必要かもしれません。ですが、製造現場においては、手順書を作るのは現場の作業者ではなく、スタッフであることが一般的ですし、作業者が手順を守っているかをスタッフが工程監査することも珍しくないです。それと同じことと考えて欲しいものです。こういったSEPG、SQAになるためにはソフトウェア開発プロセス、品質保証の知識が不可欠です。「ソフトウェア品質保証の基礎」コースでは、プロセス、品質保証の全体像を学び、ディスカッションを通じて各社の取組みなどを知ることができます。「ソフトウェアプロセス評価・改善」研究コースは、専門家として、プロセスについて深く研究することができます。

8.品質を高めるには、トップの強い意志とたゆまぬ課題解決
ビジネスを成功させるには、QCDの確保が欠かせません。コスト、デリバリーはリリース時点であからさまに結果が出ますが、品質はユーザーに使われてから初めて良否が判明するため、リリース時点では神のみぞ知ることとなります。そのため、こと品質に関しては楽観的になってしまう組織が少なくないようです。そして、そのしっぺ返しで、市場クレームが出て、その対応で新製品開発のリソースが食われ、十分に品質保証できずにリリースし・・・という負のスパイラルに陥ってしまいます。このスパイラルを断ち切るには、トップの強い意志が不可欠です。そして、そのトップの意志を具現化、実践する力強いリーダーがいなければ絵に描いた餅となります。「品質技術の実践」コースは、そういった自社の課題を自らの強い意志で解決する人を担当主査、副主査はもちろん、研究会の講師陣が全面的にバックアップします。

このようにSQiP研究会では、ソフトウェア品質を向上させるために必要な技術領域のコースを豊富に取り揃えています。そして、各分科会の講師陣はその領域のスペシャリスト揃いです。課題が明確な場合は該当領域の分科会を、どこから着手すれば良いか分からないという場合は、まずは「ソフトウェア品質保証の基礎」コースに参加することをお勧めします。本寄稿が皆様の製品、サービスの品質向上のきっかけになれば幸いです。長文をお読み頂き、ありがとうございました。

ソフトウェア品質管理研究会

ページトップへ戻る

　　　　　　小池利和氏
ヤマハ株式会社
品質保証部グローバル品質戦略G

SEPG、SQAとしてソフトウェアメトリクスの実践活用に従事後、現在は海外工場などで統計的品質管理を指導。著書に『データ指向のソフトウェア品質マネジメント』（2013年日経品質管理文献賞受賞）、『ソフトウェアメトリクス統計分析入門』。社外活動として、日科技連ソフトウェア品質管理研究会運営委員会委員長、同研究会ソフトウェアメトリクス演習コース主査、SQiP運営委員、データ分析勉強会主催など。