Skip to content

Category: GSN-practice

安全分析の説明技術ーHAZOPやFTAの結果をGSNを使って可視化する

デンソークリエイト 小林展英様による、HAZOPやFTA等の安全分析の結果を、GSNを使って説明する手法についてのチュートリアルです­。

Advertisements

ISO26262指向 安全コンセプトの記述法 (Part 2/2)

DNV GLの山下さんによる、今、自動車業界で大変話題になっている「ISO26262」規格の「安全コンセプト表記法」の紹介。2回目の本レクチャーでは、設計成果物について、例を用いで解説くださいました。

GSN の記述例〜RAMS(IEC62278)

「モデリングしてますか?」 今日は、産総研 (AIST: 産業技術総合研究所)の相馬さん、本日2回目になりますが、今回は、GSNの具体的な記述例を、ご紹介いただけるという事です。では、よろしくお願いします。  鉄道の機能安全規格 IEC62278 – RAMSのドキュメントをGSNで描いた例 産総研の相馬です。 本日は、鉄道の機能安全規格であるIEC62278、RAMSと呼ばれる規格のGSNによる記述について、ご紹介したいと思います。 まず簡単に、RAMSのご説明をさせていただきたいと思いますが、鉄道分野の機能安全規格の最上位のものになります。 ソフトウェア、ハードウェア、それから通信といった規格もありますが、それら全ての上位の規格となります。 RAMSは、全部で14の段階からなっており、コンセプト、それから実装等を経て最終的に廃棄の段階まであります。 この各14段階、それぞれを段階ごとに、今回はGSNによる記述を行いました。 今日ご紹介するのは、第3段階のリスク分析に関する部分です。それともう1つ、RAMSに関してですが、各段階で5つの構成要素からなっています。目的であるObjective、その段階へのInput、要求事項Requirementその段階で作成される成果物Deliverableと呼ばれるものです。そして最後にVerification、検証、といった5つの項目から必ず成り立っております。 では、どのように記述していくのか、まずは第3段階リスク分析のフェーズになりますが、このリスク分析のフェーズが十分行われている、実施されているという事をトップのゴールとしておいて議論を展開していきます。左側に関しては、RAMSの目的Objectivesがきちんと達成されている事に関する議論、右側は、入力が適切なものを持ってきているという議論になります。 このようにアーキテクチャーをまず決定してから、GSNを構成していきます。今日は、この上位概念部分のGSNの記述と、ある1つの目的に関する議論の部分を紹介します。 こちらが、IEC6788 RAMSの実際の記述内容になります。一部抜粋してきております。 まずはじめに、トップゴールを置いて、先ほど述べたように「目的が達成されているという議論」、それと「入力が適切であるという議論」に分解していきます。 更に、目的は、このように4つあります。全ての目的が達成されている、各目的に対して議論を展開すると。ただ、全ての目的とかいても、いくつあるのか、というのが分からないので、それをコンテキストで補うようにします。 実際に、4つの各目的が達成されているゴールを配置していきます。このように上位概念を構成していきます。 それでは、1つの目的である「十分なハザードが特定されている」というゴールに対する議論になります。 目的を達成するためにしなくてはならないこと、要求事項、それから、検証といった部分に記述されています。 例えば、要求事項、検証等から「どのような事を達成すれば十分なハザードが特定できているのか」、ここでは体系的な手法によるハザード特定が行われていること、さらにハザードの原因となる所に関して、全て網羅的に考慮されていること、そして実際にハザード特定を行う方の力量が示されている、ちゃんと力量を持った方が、ハザード特定を行っているということがサブゴールとして配置されます。 さらに、ハザード特定の方法に関しては、セーフティプランという計画で考えられていた方法通りのものが用いられていること、もしくは、ハザード特定の範囲がきちんと定義され、その範囲内で行われている事などが、コンテキストとして配置されております。 実際に行われたハザード特定であったり、力量を示す資料などが、Deliverable(成果物)として作成されておりますので、これらが、最終的なソリューションとして配置されるという事になります。 IEC 62788 RAMSをGSNで描くと、このような形になります。 […]

「アシュアランス・セーフティーケース概論」〜歴史的背景と制度〜

モデリングしてますか? 今日は産総研(AIST:産業技術研究所)から田口研治さんに来ていただいて、セーフティケースの歴史的背景やGSNについてお話しをいただきたいと思います。 では、田口さん、よろしくお願いします。 産業技術研究所の田口と申します。 本日はセーフティケースの背景から始まって、どのようにGSNという表記法が使われているかについて簡単に説明させていただきたいと思います。    セーフティケースの歴史的背景 まずですね、セーフティケースについて歴史的な背景を説明する際に重要な用語として「セイフティケースレジーム」という言葉があります。これは、セーフティケースというのは単にドキュメントではなくて、やはりその法規的な問題から始まって社会制度としてどのように安全性を保証するかという、相対的なものとして捉える必要があるということです。 セーフティケース自身は有名な話として、パイパー・アルファ(Piper Alpha)という北海の油田の事故から始まりました。 実際に北海の油田の事故においては、その結果ですね、Offshore Installations Regulationという実際に法制度として確立されたという歴史的背景があります。  セーフティケースの定義 セーフティケースの定義ですけれども、英国の防衛規格であるDefence Standard 00-56という定義においては、 「与えられた運用環境におけるシステムの適用に関して、安全であることを、強制的かつ理解可能、妥当な事例として提供する、根拠資料の集まりにより支援された構造化された議論」という定義になっています。 ここでやはり重要なのは「根拠資料の集まりにより支援された構造化された議論である」という、この点だと思います。  セーフティケースが義務付けられている産業分野、規格 実際にセーフティケースが義務づけられている産業分野、規格等は様々あります。 航空機関係では、EUROCONTROLというヨーロッパの航空機管制システムに関する安全性の保証に関するガイドラインがあります。鉄道関係では、Rail Yellow Book(レール・イエロー・ブック)というものや Railway Safety Case Regulations(レールウェイ・セーフティケース・レギュレーションズ)というような英国の規格があります。 国際規格としては IEC62425、ヨーロッパの規格ではEN50129という鉄道システムに関するセーフティケースの規格があります。また車載関係では、ISO26262というものがあります。 […]

技術レビューの現場におけるGSNの活用法(2)〜相手と自分の共通理解をつくるには

「モデリングしてますか?」 DENSOクリエイトの小林さんを再度お招きして、GSNを使ってレビューをする際に問題となる「共通の合意の作り方」についてお話ししていただきたいと思います。では小林さん、よろしくお願いします。   前回「議論においては、前提を相手と合わせる事が大切だ」とお話させていただきましたが、今回は、そこについて簡単に紹介させていただきたいと思います。 まずはじめに、相手と自分の、議論の前提の認識が合っているかどうか、という状況を図示すると、おそらくこういう4ディションになるのではないかと思います。  自分と相手が共に知っている状態 1つ目については「自分と相手が共に知っている状態」。ここは、実際の開発現場で考えると、相手がずっと仕事をやってきて、自分も一緒に仕事をやってきた、というのが、このディションになるのではないかと思います。  相手は知らず、自分のみ知っている状態 – しっかり教える 「相手が知らなくて、自分が知っている」所というのは、自分たちの技術に、お客様が非常に関心を持ってくれている、「新しく仕事を始めよう」という状態、あるいは、お客さんの方の窓口が変わった、という場合は、こういう所になります。 ここでは、自分の知っていることを相手にしっかり説明しておかなければ、相手が、いつまで経っても「自分のこととして仕事に取り組んでくれない」とか「中を見てくれない」といったことになるのではないかと思います。  相手のみ知って、自分が知らない状態 – しっかり教えてもらい明文化する 「相手が知っていて、自分が知らない」という領域については、お客さんが長らくやってきた製品開発の中で、自分たちが参入する、という場合になると思うのですが、ここの前提もしっかり合わせておかないと、後になって「なぜこんな事も分からないのか?」というような話があがるかもしれません。 そういうリスクがあるので、ここの領域については、相手にしっかり教えてもらって、明文化するという事が必要になると思います。 前後しますが、ここ (相手が知らず、自分のみ知っている領域)は「教えてあげる」という事がいりますね。  自分も相手も知らない状態 – 一緒に前提を作り上げる 最後に「自分も知らずに、相手も知らない」という領域については、相手と自分が一緒になってまずは前提を作っていくという作業があって、それに基づいて仕事を始めるとうまくいくのではないかと思います。 ここは「一緒に作り上げる」ということが大切ではないかと思います。 議論自体は、こういう形になると思ってます。  議論の周囲にある「相手と合意しているもの」を明らかにしてから議論を形作る 議論の対象がこのスコープだとします。その時に、先ほどのモデル(相手と自分の状態)を念頭に置きながら、どういった前提文書があるか、相手と合意形成されている前提文書や証拠文書、こういったものをしっかりと洗い出すことが、まず大事だと思います。 その上で、議論の対象となるもの、「何を主張したいか」ということ、例えばこの主張が妥当であることを証明したいのであれば、前提文書等を用いて、この主張を分解していき、相手と合意形成をできる証拠文書に基づいて、ここを証明する、と、こんな形で先ほどの議論モデルを念頭においてまとめてくると、GSNでこういった形で伝わるのではないかと。 そこが合ってることによって、共通理解をもったGSNを書いて、相手に納得してもらえるのではないかと、そういうことを考えています。 はい、ありがとうございました。 […]

技術レビューにおけるGSN, D-Caseの現場活用法(1)〜レビューの前提となる基準を作る

モデリングしてますか? 今日は、DENSOクリエイトの小林さんをお招きしてGSNを現場のレビューで活用する、という例についてお話をしていただきます。 では、小林さん、よろしくお願いします。   クリエイトの小林です。今日は、平鍋さんに機会をいただきましてGSN(Goal Structuring Notation)の現場活用についてお話させていただきます。    GSN(Goal Structuring Notation)の記述ルール 先ずはじめに、GSNの簡単な記述ルールですが、GSNとは、トップに自分の主張したいものの状態を置きまして、それを、相手と合意形成している前提に基づいてサブの主張に分解していく、と、最終的に、そのサブの主張が、証拠に基づいて証明される、といった記法になっております。  GSNを使って解決したいこと 実際これを開発現場で、どう活用していこうかという事なんですが、現状は、現場が抱えている問題としまして、皆様もよく感じられる事があると思うのですが、上位の方が、部下の成果を見た時に「この内容って、何でこういう形になってるの?」という事が分からない、とか、そういった話がよくあると思います。又は「僕の思った通りに作ってくれないじゃないか」といったような事もあるんじゃないかと思います。また部下の視点からいくと、上司の人に見てもらったんだけど何回見てもらってもOKがでない、といった事もあるように思います。 それを簡単に図示した絵が、こちらの絵になるのですが、この絵の中では、作成者の方が、成果物を、自分の考えに基づいて作成し、上位の方も、自分の経験に基づいて確認する、といったことになっています。 当然ここで、上位の方と部下の方、作成者の方ですね。ここの考え方というのが合ってるはずがないので、その結果、度重なるやり直しとか、手戻りといったことが発生しているのではないかと考えております。 そうしたものを解決するために、一番簡単なのが「上司の方と部下の方の認識を合わせる」「考え方を共通化する」という事が大事だろうと。 ですので、こちらの図に書かれていますように、色んな基準というものレベルがあると思うのですが、それを上位と会議の担当者の方と合わせることによって、作成者の方はその基準に基づいてものを作り、上位の方は、その基準に基づいて成果物をレビューする、と、そうすることによって、手戻りなく、うまく仕事ができるんじゃないかなという風に考えて、こういった活動を現場に投入していこうと、いま考えております。 GSNを使って解決する方法としましては、こちらの図に示しましたように、相手と自分の考え方を共通化する、という上司と部下の認識を合わせることによって、部下の方は、成果物をそれに基づいて作成し、上司の方は、それに基づいて部下の成果を確認する、という仕組みを作ることで、うまく仕事が回るようになるのではないかと思っております。 ということは、このコンテキストの所に、「基準」というものを書いていく、ということによって全体の考え方が、上司と部下、あるいはレビュイーとレビューワーの間で合意を先に作っておく、ということで、このGSNが、よりレビューしやすくなるという風に考えればいいですね。 この続きについては、次のビデオでご紹介します。

GSN解説(2) – GSNの基礎とその構成要素

こんにちは。名古屋大学の山本修一郎です。 GSNは「あるシステムやプロセスが、基準を満たす」ということを説明するための手段です。 ですので、まず「主張」というものがあります。 この主張は、システムや基準、原則がありまして「こういうシステムや基準を対象にして、システムが、ある基準や原則を満たす」ということを説明するための手段です。 これを説明するためには、例えば「システムの構成で説明する」という事になります。 そうすると、システムの構成というのは、例えばこのシステムには構成要素があるので、 「構成要素がこの基準や原則を満たすこと」と 「構成要素の関係が原則を満たす」 この2つを説明する必要が有ります。 それぞれについて、確かに関係が原則を満たす客観的な「証拠」があります。要素についての証拠もあります。 そうすると、今度はこの要素に基づいて、確かにシステムが、こういった原則を満たしているということを、第三者に対して論理的、合理的に説明することができます。 これが、GSNの最も基本的な考え方なんです。 [関連記事] – GSN解説(1) – GSN (Goal Structuring Notation)とは何か? – 【対談】GSN, D-Caseの動向と必要性 – 名古屋大学 山本先生 x 平鍋対談