リコールを起こさないということ

本はリアル書店でもインターネット書店でもまず手にとって興味を示してもらわなければその他の本の中に埋もれてしまい誰にも目に触れずに日の目を見ることなく消えてしまいます。だからこそ、手にとってもらうために奇抜なタイトルを付けます。

タイトルに引かれて本を購入した読者に「タイトルに騙された」と言われないために、まじめにソフトウェアの安全や信頼を実現する方法を提案していることを分かったもらうために、このブログで本の一部を紹介していきたいと思います。

【『リコールを起こさないソフトウェアのつくり方』　本書を読む前に－リコールを起こさないということ－より】

ソフトウェアでリコールを起こすということはソフトウェア製品やソフトウェアが搭載された機器の価値を低下させることに他なりません。そのソフトウェアやソフトウェア搭載製品の価値がもともと非常に高かったり、多くの人が使っているものであったり、人の命に関わっていたりすると、利用者に大きな不利益がもたらされ、その後始末をするために組織は多額の費用や工数を負担することになります。
ユーザが被った不利益のフォローアップもさることながら、組織が受けるイメージダウンの影響が大きな痛手になります。消費者、特に日本の消費者は、メーカーのブランドを信用して製品を買う傾向が強いため、リコールを頻発したりしてユーザの信頼を失うと、未来の製品の売上に大きな影響を与えてしまいます。へたをすると会社自体が潰れてしまうこともあるでしょう。

プログラマが直面する状況

Part1では、SESSAMEの演習コンテンツを受講した C言語プログラミングの初心者が書くとんでもないプログラムを見て、ソフトウェアというものはどれほど慎重に作ったとしても、テストをすり抜けて残ってしまうバグが製品の価値を押し下げ、組織の信用を失わせる可能性が十分にあるということを読者のみなさんに実感してもらいます。
製品がどのように使われるかをよく知らないプログラマは、リコールがユーザや組織に与える影響について考えてプログラムを作ることはありません。一方、ベテランプログラマは、日本の小規模なソフトウェアプロジェクトにおいて自分が作っているソフトウェアがユーザにどのように使われるのか、ソフトウェアがユーザの期待を裏切るような振る舞いをするとどのような迷惑がかかるのかを意識しながらプログラムを作っています。
それが、ソフトウェアの規模が大きくなり、ソフトウェアプロジェクトの人数が増え、協力会社にソフトウェア開発を委託することが普通になり、どのようなプロセスで作られたかがわからずソースコードが見えないソフトウェア部品を使うようになって、何をどうすればユーザリスクを最小限にできるのか、長い間ソフトウェアで飯を食ってきたベテランのソフトウェアエンジニアにもわからなくなってきています。

日本のソフトウェアプロジェクトが目指すべきこと

日本のソフトウェアプロジェクトがとるべき舵取りは3 つあると思います。

1. ソフトウェアを利用するユーザのユーザリスクが何かを知り、そのリスクを受容できるレベルまで引き下げるにはどのようにソフトウェアを作ればよいかを分析して設計できる力を身につけること
2. ユーザがソフトウェアやソフトウェア搭載製品を使う場面を想定できない、または想定しないで仕事をするプログラマがプロジェクト内にいると仮定して、彼らが意図せずに作り込んでしまったリスクの種をどのように組織的に取り除いていくかというマネージメントの技術を学ぶこと
3. 再利用可能な信頼性の高いソフトウェア資産を作って、その資産を再利用することで開発効率と品質を同時に高めること

第1 の施策は、ソフトウェアシステムの構造設計者であるアーキテクトの責務であり、航空および宇宙、医療、プラントなどのクリティカルデバイスのソフトウェアの世界では専任のソフトウェア安全分析者の役割になります。
リスクの中には安全に対するリスクだけでなく、携帯電話やデジタル家電、自動車のリコールなどで見られるような経済的なリスクも近年顕著になってきています。したがって、この取り組みはクリティカルデバイスソフトウェアだけに求められているわけではありません。また、これまで日本人の几帳面さや助け合いの気質で品質をカバーしてきたソフトウェアは、その日本人の特性を活かしながらもマネージメントの要素を上手に組み込んでいかなければ品質を保てないほど、規模が拡大しています。そのような意味でも、これからのソフトウェアプロジェクトは、第2 の施策であるソフトウェア品質のマネージメント技術を修得する必要があります。
そして、最後に必要なのはソフトウェアの資産化です。昔からベテランのソフトウェアエンジニアは、枯れたソフトウェアモジュールを再利用することで品質と効率が高まることを肌で感じていました。だからこそ、枯れたソフトウェアを安易に変更せず、後々まで変更しないで済むようによく考えてソフトウェアモジュールを作っていたのです。

ソフトウェアの規模が増大し複雑化した現在では、この昔のベテランエンジニアがとっていたアプローチを体系的に実施していく必要があります。体系的に行うとはいっても、考え方や基本思想は昔と同じです。ユーザに対する価値が凝縮されており、システムのコアとなるソフトウェアモジュールを見つけて、設計（場合によっては再設計）し、資産化してそれを管理するのです。それは、ユーザがソフトウェアやソフトウェア搭載製品にどのような価値を求めているのかを知っているソフトウェアエンジニアにしかできません。ソフトウェア工学の知識を十分に身につけていても、それだけでは足りません。製品や製品を使うユーザのことをよく知っているか、マーケティング担当が分析した情報をユーザの身になって理解できるソフトウェアエンジニアでなければダメなのです。

本書で提案したいこと

本書が他のソフトウェア工学の書籍と異なるのは、ソフトウェアエンジニア、特に日本のソフトウェアエンジニアの気質を強く意識した施策を提唱し、ソフトウェアやソフトウェア搭載製品が使われる市場やユーザを分析対象にしなければ、効率的かつ高品質なソフトウェア開発は実現できないと主張しているところです。そこにはソフトウェアを作る職人の個人商店としての立場と、自分の仕事の成果によってユーザであるお客さんの役に立ちたい、喜んでほしいという気持ちが根底にあります。ただし、そのためにはプロフェッショナルとしてのワザを身につけて、努力するだけではなく、製品の本当の価値を高める成果が伴っていなければなりません。そうでなければ自己満足になってしまうのです。
「リコールを起こさない」という言葉を裏返すと、「製品の価値を高いまま維持する」「いつまでもお客さまに満足し続けてもらう」ということになります。日本のソフトウェアエンジニアは、製品の価値を意識しながらソフトウェアを作るということに長けた人種だと思います。ただ、残念ながら、その気質だけで高品質なソフトウェアを作れる世の中ではなくなっているのです。本書で日本のソフトウェアエンジニアに最もフィットした改善および技術習得の手法を提案したいと考えています。

【引用終わり】