安全とソフトウェア変更管理をつなぐ

ソフトウェアを作るとき、特に飛行機の制御システムや医療機器みたいに安全がめっちゃ重要なやつは、慎重にならなあかん。これらのシステムが失敗したら、人がケガしたり環境が悪影響を受ける可能性があるから、常に安全性をチェックし続ける必要があるんや。

安全について考えた証拠を示す方法の一つが、安全保証ケース（SAC）って呼ばれるもんや。SACってのは、システムが安全に使えるっていう理由と証拠のグループやね。安全性の主張を小さな部分に分けて、それをテストやシミュレーションみたいな証拠でサポートするんや。これで、みんなが安全性についての決定をどうやって行ったか理解できるようになる。

これらの安全ケースを作ったり更新したりするのは簡単じゃない、特にソフトウェアが変わったときは。なぜなら、安全に関する作業とソフトウェアに関する作業の間にギャップがあることがあるから。安全に焦点を当ててる人たちは、ソフトウェアのことをあまり知らなかったり、その逆もある。だから、このつながりがないと、ソフトウェアに変更があったときに安全性の議論を更新するのが難しいんや。

多くの場合、安全の専門家は、安全保証ケース（SAC）の変更を効果的に管理する良い方法がないことを指摘してる。だから、ソフトウェアに何か変更があった時、安全専門家がそれが安全にどう影響するかを特定するのが難しい。

ソフトウェアが変わるときに知りたいことは：

1. なぜソフトウェアが変わったの？
2. この変更はどんなリスクを修正しようとしてるの？
3. この変更が安全にどう影響するか？

もっとスムーズにするために、安全に関する議論を直接ソフトウェアの変更に結びつけることができる。つまり、ソフトウェアの重要な部分を安全の理由にリンクさせて、すべての変更を追跡する必要がある。こうすることで、安全に取り組む人たちは、ソフトウェアで何が変わったのか、そしてそれが安全性にどう影響するかを把握できるようになる。

#ソフトウェアと安全をつなげる

この問題を解決するために、ソフトウェアの変更と安全の議論を整理してつなげる方法を提案するで。安全アーティファクトフォレスト分析（SAFA）っていう技術を使うことで、ソフトウェアの変更を自動的に見つけることができる。二つのバージョンのソフトウェアを見て、何が変わったのかを可視化するんや。この可視化を使うことで、安全チームは何が追加されたか、削除されたか、変更されたかを正確に見て、それが安全の議論にどう影響するかを理解できる。

ソフトウェアが変わったとき、私たちの方法はその変更の理由も捉える手助けをする。ソフトウェアに関わる人たち、例えば開発者は、変更についての理由や他の重要な詳細を提供できる。このことで、安全チームはその変更が安全にとって良いのか悪いのか理解できる。

例えば、緊急時に使うドローンのシステムを設計する際、重要な要件の一つはドローンが飛んでいい場所といけない場所を把握することや。これは、ドローンが制限区域に入ったら事故を引き起こす可能性があるから、めっちゃ重要や。

ドローンには、飛行中に空域情報を常にチェックする必要があるっていう要件があったけど、ソフトウェアの新しいバージョンでは、飛行経路を新しく計画する時だけに空域をチェックするように変更された。この変更を私たちのシステムが明確に表示し、安全専門家がこれがまだ安全か評価できるようにする。

#すべての要素をつなげる

安全なシステムを開発するとき、まずは潜在的な危険を特定するところから始める。これを予備危険分析（PHA）って呼ぶ。その後、リスクをよりよく理解するためにフォールトツリー（FT）や故障モード効果危険度分析（FMECA）を作るんや。私たちは主にフォールトツリーに焦点を当ててるけど、同じ考え方はFMECAにも当てはまる。

フォールトツリーは、リスクを小さな部分に分解して、異なる出来事がどのように安全問題を引き起こすかを示してくれる。リスクを理解して管理することが目的や。

私たちの方法では、フォールトツリーと安全保証ケースの関連部分との直接的なリンクがあることを確保する。これにより、安全に関する議論とシステムの設計をつなげることができる。

これらの接続を明確に保ち、更新することで、システム内の変更はリンクされた安全の議論を通じてアラートを送信することになる。こうすることで、ソフトウェアで何かが変わったとき、すぐにそれが安全にどう影響するかを評価できる。

#理由を捉える重要性

変更が安全にどう影響するかを本当に理解するためには、その理由を捉える必要がある。開発者がコードを変更する際、その変更の理由を詳しく説明する必要がある。これには、考慮した代替案や、最終的な決定に至った経緯を含めることができる。

例えば、ドローンの安全要件で「リアルタイムの空域データを取得するべき」って言ってる場合、このやり方が変更されると安全性に影響が出ることがある。これらの要件がどう変化したかについて明確な記録を持つことが重要や。これがあれば、安全アナリストは新しい設計がまだ安全か、もっと予防措置が必要かを評価するために必要な文脈を提供できる。

#直面する課題

安全とソフトウェア開発をつなげる際、まだ多くの課題がある。まずは知識管理が重要なエリアや。安全アナリストが何を知っておく必要があるのか？この情報を効果的に集めるにはどうしたらいいのか？これらは重要な質問や。

もう一つの課題は、変更を賢く分析することや。ソフトウェアの変更はさまざまなレベルで起こる可能性がある。無害な変更と、リスクがある可能性がある変更を区別したい。将来的なアプローチとして、変更を分析して安全が危険にさらされているときに具体的なアクションを提案できるスマートなシステムの活用を考えている。

最後に、このプロセスで使用するツールの改善が必要や。現在のシステムは、安全に関する主張とソフトウェアの変更とのつながりを管理するためのサポートが欠けていることが多い。安全とソフトウェアの変更を維持するのを助けるユーザーフレンドリーなツールを開発することが重要や。

#結論

要するに、特に命がかかってるシステムには、ソフトウェア開発において安全を維持することがめっちゃ大事や。安全要件とソフトウェアの変更の間の点をつなげることが、開発プロセス全体で安全が優先されることを确保するために重要や。

ソフトウェアの変更と安全の議論との明確なリンクを作り、その変更の理由を捉えることで、ソフトウェア開発における安全管理を改善できる。これから進んでいく中で、私たちが直面する課題に対処することが、安全を保ちながら新しい変更に適応できるシステムを作るために必要不可欠になる。