五味弘

とかく難解なIoT時代の組み込み系ソフトウェア品質を問う際、1つの指針となるのがIPA/SECのガイドブックである。今回はこの冊子を元に、「IoT開発と運用での13問答」を例示したい。

製品とともに行動してこそ品質は変わる。行動することで、品質は製品の「おもてなし」になり、「究極の品質」でもてなすことができる。

ソフトウェアの品質管理はつらくて面倒だ。品質計測や品質制御は効果をすぐに実感できるが、品質管理の効果は後でしか得られない。「面倒だが後が楽になる」と分かってはいても面倒は面倒である。こんな品質管理を楽しくする方法はあるのだろうか。

品質はヒトが制御する。機械でも人工知能でも神様でもなく、ヒトが品質を制御し、品質を作る。今回は視点を変えて、ヒトを中心に品質を見ていくことにする。どんなに立派な品質活動でもヒトが継続的に実施しなければ、いずれ絶えてなくなるからである。

品質を守る最後の砦が「テスト」であれば、品質向上の最強の武器は「上流工程での品質活動」である。しかし、この武器は効率的かつ小気味よく扱わねば、お飾りとなる。そこで今回はこの「上流工程における品質活動」について確認する。

テストは品質を守る最後の守護者であるが、品質はテストだけで守られる訳ではない。しかしその関係は深く、テストは品質を導く水先案内人といえる。ここでは、テストが品質に対して「できること」と「できないこと」を説明したい。

組み込みソフトウェアの「品質」を計測した後には、その向上を図らなければならない。しかし品質はむやみに向上させるものではなく、状況に応じた最適な品質になるように制御するものである。

ソフトウェア品質を高めるためには、計測が第一のステップとなる。しかし、無形のモノを「はかる」ことには細心の注意を要する。ここではソフトウェア品質を「はかる」ことでの向上を目指す際の心得を紹介したい。

ソフトウェアが無形のモノである以上、その「品質」も推して知るべし。把握も容易ではない。まずは「ソフトウェアとは何者か」を考察した上で、組み込みソフトウェア品質についての歩みを進めたい。

組み込みソフトウェアにおける「品質」とは、一体、何者であろうか。多用されている言葉であるがその実態はようとしてしれない。この連載では「IoT時代の組み込み系ソフトウェアの品質」をテーマに開発現場の目線で見ていく。まずはこの品質の正体を見破ることから始めたい。

AIが一般化してもソフトウェアテストを取り巻く環境は厳しいままなのだろうか？ソフトウェアテストの過去をひもときながら、その未来を予想する。完全自動のテスト、あるいはテストのいらないプログラミングは実現するのだろうか。

IoTやAIが一般化する未来においても、ソフトウェアテストは険しい道のりを歩むことになるのだろうか。まずはテスト技術者に焦点を当て、その生きる道と道しるべである教育について見ていきたい。

新時代のテストに向けて立派な施策を打ち立てても、それを継続的かつ効果的に運用しなければ、絵に描いた餅である。今回は従来テスト運用を振り返りつつ、新時代のテスト運用について見ていく。

変化する時代の中で、ソフトウェアテストはどのようにあるべきか。変わらなくてはならないならば、どう変わるべきか。今回はこれらの質問に対する解として、「新時代のテスト施策」について考察する。

IoTやAI、ビッグデータのソフトウェアテストにどんな試練と障壁が待ち受けていて、その壁は登り越えられるのか。今回から新時代のソフトウェアテストの試練について見ていく。まずはテストに深く関係する「ソフトウェア開発」について振り返る。

IoTとAI、ビッグデータが一般化した時代に求められるソフトウェアテストとは、どのようなものになるのか、今回は新時代に求められるテストの必要条件とは何かを見ていくことにする。

何らかの判断でソフトウェアテストの手法が選択できても、「どう実施するか」の施策もまた、重要な要素である。プログラマー個人からチーム、会社レベルまで、どのような施策をもってテストを実施すべきか検討していく。

ソフトウェアテストの選択はケースバイケースであり絶対な正解はないが、ベターな選択は存在する。そこでテスト手法の詳細を知り、選択基準を見てゆくことにする。

IoTやAI、ビッグデータなどの概念が身近になった昨今、ソフトウェアテストはその複雑さを増している。そんな時代の中で実行力を持つソフトウェアテストの手法と施策を検証していく。

ソフトウェアテストの最大の問題である、「テストにかけるコスト」と「得られる品質」のバランスをどのように取るのか。この関係について、開発現場と経営者的視線である「上から目線」の双方から考えていく。

言うまでもなくソフトウェアテストは重要だが、IoTやAIなどの新しい概念によってソフトウェア自体の在り方が変わりつつある中、旧来からのテストを踏襲するだけでは成果は得られない。新時代のソフトウェアテストについて、考察する。

連載「プロジェクトを成功させるモデリングの極意」の総集編として、今回はモデリングとは何か？からその運用までをFAQ（Q&A）形式でまとめました。プロジェクトを成功させる極意としてご利用ください。

今回はモデリングで失敗しないだけでなく、さらにモデリングを成功させ、継続するための方法を探ります。失敗しないコツが盾であるならば、成功と持続のコツは矛に相当しますので、これらを学んでモデリングを持続可能（sustainable）なものとしていきましょう。

モデリングを失敗しないためには、失敗の原因と失敗しないためのコツを知ることが肝要です。今回は失敗しないための実践的なコツを紹介します。

誰もが失敗したくてモデリングする訳ではないのに、失敗しているモデリングを見る機会は減りません。今回はモデルの失敗例を通じてその原因を探ります。

「モデリングはいつ誰が何をどのようにするのか」――今回はソフトウェア開発の現場で、モデリングを実際にどのように実施しているのか見ていきましょう。またUMLやSysMLの使いにくいところを、開発現場ではどのようにカバーしているのかも見ていきます。

前編では「モデル」の目的とその効果、具体的なモデル手法について代表的なものを説明しましたが、後編ではその手法を実践するツールを紹介します。

モデリングの手法やツールの基礎を覚えるだけでなく、モデリングの目的やその本質をつかんで、ソフトウェアの開発現場で実際に役立つように基本を学んでいきましょう。

今回は連載の総集編として、ここまでで解説してきたポイントをFAQ形式でまとめてみました。本稿を、ソフトウエアテストで「考え過ぎた」ときに、リファレンスとして使ってみてください。詳細を確認したい場合は連載各回の解説を確認してみましょう。

組み合わせテスト実施時の判断のコツは分かったけれど、どのくらいの「強さ」で、どの手法を組み合わせればいい？ 筆者の経験から、判断基準やテストのPDCAにおける「トレードオフ」の正しい悩み方、賢い対策の考え方を紹介します。

オールペア法や直交表は組み合わせテストの品質を一定に保ち、テストケースを合理的に削減できる利点を持ちます。しかし、ツールでやみくもにテストケースを削減してはいけません。そこには勘も経験則もコツも必要です。筆者がコツを伝授します。

あらゆる条件を網羅したテストを実行することは現実的ではありません。しかし、職人技と勘、あるいは闇雲にテストツールに頼っても、科学的に品質を保証できません。最小のコストで品質を保証するための手法と、その考え方、制約がどのようなものかをじっくり見ていきましょう。

手法やツールだけでなく、そもそもテストとは何か、トレードオフを適切に判断するために必要な知識は何かをじっくり考えてみましょう。