【ITニュース解説】🏁ASPICE Literacy: Episode 5 — From Paper to Practice: Evidence, Work Products, and the Art of “Show, Don’t Tell” 📂➡️🛠️

自動車業界でソフトウェア開発の品質を評価する国際的な基準としてASPICEというものがある。この基準は、単に書類が整っているかを見るだけでなく、実際に開発プロセスが適切に行われているか、そしてその結果として作られた製品が安全で高品質であるかを保証することを目的としている。しかし、現状では多くの現場で、管理層への報告や評価のための形式的な書類作成に終始し、実際の開発とはかけ離れた「見せかけ」の活動が行われることがある。例えば、評価の直前になって急いで資料を作成し、表面上は問題がないように見せかけることで、一時的に管理層を安心させ、評価を乗り切ろうとする傾向が見られる。しかし、このような形式的な対応は、実際に製品が顧客の手に渡った際に問題が発生し、最終的に顧客を失望させる結果につながる危険性がある。ASPICEは、開発の現実を照らし出す懐中電灯のような役割を果たすべきであり、表面を飾るための舞台照明であってはならない。

ここで重要になるのが「エビデンス（証拠）」という概念である。多くの人はエビデンスと聞くと、誰も読まないような分厚い書類の束を想像しがちだが、それは誤解である。エビデンスとは、本来、システム開発の過程で自然に生まれる「活動の痕跡」を指す。例えば、顧客からの「要求」、開発中に見つかった「バグ報告」、設計段階での「検討メモ」、テストを実行した際の「ログ」、ソースコードの品質を確認するための「レビュー記録」、機能変更に伴う「変更要求」などがそれにあたる。これらは、ASPICEのために特別に作成されるものではなく、良い製品を作るために必然的に発生する副産物である。ASPICEが求めているのは、これらの開発活動の痕跡を、誰が見ても理解できるように明確にし、一貫性を持たせ、互いに関連付けて記録することである。これにより、製品がどのようなニーズから生まれ、どのようなプロセスを経て開発され、最終的にどのように検証されたのかという一連のストーリーを、誰もが追跡できるようになる。真のエビデンスは、形式的な書類の中に存在するのではなく、開発という実際的な作業の中に息づいているのだ。

次に、「ワークプロダクト（成果物）」について考える。これは、エビデンスを具体的に形にしたものである。信頼できる開発プロセスとは、一貫した「証拠の連鎖」を構築することである。例えば、顧客の要望から生まれた「要求仕様書」があり、その要求に対して複数の選択肢を検討した「レビュー記録」があり、そこから決定された「設計書」がある。その設計に基づいて実装された「システム構成」があり、さらにそのシステムの動作が要求通りであることを確認するための「テスト計画」や「テスト結果ログ」がある。そして最後に、すべての要件が満たされていることを証明する「検証報告書」が存在する。これらの各ステップは、前のステップの存在理由を説明し、次のステップへと繋がっていく。このような原因と結果の明確な繋がりこそが、単なる「成果物」を「エビデンス」へと昇華させる。もし、この連鎖のどこか一部が欠けていたり、評価の直前に急遽作成されたものであったりすれば、その開発ストーリーは信頼性を失ってしまう。

実際の評価の場では、「Show, Don’t Tell（見せて、語るな）」という原則が非常に重要になる。評価者は、準備されたスライドや rehearsed な説明を求めているわけではない。彼らが本当に知りたいのは、開発者が実際に作業に使っているパソコンの画面を開き、具体的なツール上で、例えば「この顧客要求は、このメールやチケットから生まれたものである」と示し、次に「その要求に対して、このような設計の検討が行われ、このトレードオフ（複数の選択肢を比較検討して一つの解決策を選び取るプロセス）が記録されている」と見せることである。さらに、「その設計に基づいて、このテストが実行され、動作が証明されているテストログがある」と提示し、「そして、最終的にこの検証記録で、すべてのプロセスが完了したことが確認できる」と一連の流れを実際に見せることを求めている。もし開発者がこれらの情報を10分以内でスムーズに提示できるのであれば、それは日々の業務の中で、適切な開発プロセスが定着している証拠である。しかし、もしスライドを棒読みしたり、情報を探すのに手間取ったりするようであれば、それは単なる「見せかけ」の活動に過ぎないと言える。ここで重要な役割を果たすのが「リエゾン（橋渡し役）」と呼ばれる人物である。プロジェクト全体を熟知し、実際の成果物がASPICEの要求事項のどこに該当するかを理解しているリエゾンがいれば、評価は尋問ではなく、スムーズなデモンストレーションへと変化する。これは評価者を欺くためではなく、開発の真実を透明に開示するために不可欠な役割である。

一方で、プレッシャーと不安から、手っ取り早い「近道」に走ってしまう危険な例も存在する。例えば、誰も実行しない形式だけのプロセスを作成して書類を提出する、実際にはテストを実行していないのに偽のログを作成する、問題が見つかっても「後で解決する」と約束して一旦は「解決済み」とマークする、あるいは形式的な評価を好む評価者を探し回る、といった行為が挙げられる。これらは一見すると賢い回避策のように見えるかもしれないが、実際には問題の解決を先送りしているだけであり、最終的には必ず破綻を招く。表面上は「問題なし」を示す緑色のダッシュボードは、一時的に管理層を喜ばせるかもしれないが、顧客が製品の問題を発見した時に、その欺瞞が露呈する。偽のエビデンスがもたらす本当の代償は、単に評価で指摘を受けることではない。それは、フィールドでの重大な製品事故であり、スライドを信じていた全ての人々にとっては、なぜ問題が起きたのかが全く理解できない「謎」として映ることになる。

では、実質的なエビデンスを生み出し、厳格な評価にも耐えうる品質を確保するためには、どのような実践的な行動が必要なのだろうか。まず、エビデンスの作成を日々の業務フローに組み込むことが重要である。例えば、タスク管理チケット、ソースコードのコミット（変更履歴）、テストの実行結果、各種レポートなどを自動的に連携させる仕組みを構築する。次に、バージョン管理システムやテスト実行ツールといった、開発で日常的に使用するツールを有効活用し、一時的なExcelファイルに情報をまとめて提出するといった場当たり的な対応を避ける。そして、なぜそれぞれの成果物（ドキュメントやデータ）が存在するのか、その理由を開発チーム全員に理解させることで、人々が正しい目的意識を持って成果物を作成するように促す。さらに、プロジェクト全体と評価のロジックの両方を深く理解した、冷静な橋渡し役となるリエゾンを任命することも効果的である。そして何よりも重要なのは、「非難しない文化」を確立することである。正直な情報、つまり真実が表面化するのは、人々が正直に報告しても罰せられないという安心感がある場合に限られる。また、近年注目されるAI技術についても、その活用方法は慎重に検討すべきである。AIは、情報の一貫性の欠如を見つけたり、欠落しているリンクを特定したり、エビデンスを事前に整理したりする作業を支援するために用いるべきであり、人間による判断の代替とすべきではない。なぜなら、最終的に製品の品質と安全性を検証するのは、アルゴリズムではなく、実際の使用環境での試験だからである。これらは、決して追加の官僚的な負担を増やすものではない。これらは、ASPICEの評価を単なる形式的な手続きではなく、開発プロセスを継続的に改善するための機会へと変える、実践的で効果的な習慣であると言える。

結論として、どれだけ見栄えの良いスライドや報告書を作成したとしても、その内容が実際の製品の品質を反映していなければ意味がない。表面上は問題がないように見えるダッシュボードと、実際に問題が発生する製品は、残念ながら同時に存在することが多い。ASPICEが本当に役立つのは、エビデンスが現実の開発状況を正確に示している場合であり、現実が特定のストーリーに合うように加工される場合ではない。もしASPICEを顧客保護のための有効な手段としたいのであれば、エビデンスを、開発活動から自然に生まれる結果として捉え、最後の最後に付け足される小道具として扱ってはならない。大切なのは「見せて、語るな」である。製品は必ず真実を語る。その語る内容が、確かな根拠に基づいていることを確認しなければならない。