ワークショップ「ソフトウェア開発におけるHAZOP入門」を3回開催した。
その結果（参加者の所感）を記録する。
開催シンポジウム
ソフトウェアテストシンポジウム（JaSST ： Japan Symposium on Software Testing）でワークショップを開催させていただいた。
http://www.jasst.jp/
- JaSST'18 Tokai（参加者：13名）
- JaSST'19 Tokai（参加者：8名）
- JaSST'19 Shikoku（参加者：19名）
参考文献
[1]小川清, 「一人HAZOPを組み合わせた効率的な分析作業」, WOCS2011, JAXA/IPA, 2011
[2]日高隆博, 山崎二三雄, 中本幸一, 本田晋也, 高田広章, 「HAZOP分析によるソフトウェア異常動作検出条件の導出手法の提案と実装」, 組込みシステム(EMB) Vol.2009-EMB-14 ,情報処理学会研究報告, 情報処理学会, 2009,ページ1-8, ISSN 1884-0930
[3]河野哲也, 「ソフトウェア要求仕様におけるHAZOPを応用したリスク項目設計法」, ソフトウェアテストシンポジウム2012, 2012
[4]小川明秀, 小川清, 「安全分析において，HAZOP, FMEA, FTAの組み合わせによる リスクアセスメントの進め方」, 安全工学シンポジウム2015, 日本学術会議, 2015
[5]相澤孝一, 「マルチベンダー構成システムの信頼性向上を目的としたフェールセーフ設計に対する点検手法 ～HAZOPを活用した例外事象を含む応答のモデル化～」, ソフトウェア品質シンポジウム2018, 2018
[6]梅田浩貴, 波平晃佑, 植田泰士, 片平真史, 森崎修司, 「リスクシナリオに繋がるコンテキスト情報を抽出するレビューメタモデルの提案」, ソフトウェア品質シンポジウム2019, 2019
HAZOPのやり方
名古屋市工業研究所の小川さん（@kaizen_nagoya さん）の資料を参考にさせていただき、ワークショップを設計した。
https://www.slideshare.net/kaizenjapan/hazopogawa2015
https://www.slideshare.net/kaizenjapan/hazop-safety-and-security-swest
https://www.slideshare.net/kaizenjapan/hazop-tokyo201809
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446
https://qiita.com/kaizen_nagoya/items/9fdda3edaead39d3690c
小川さんのHAZOPワークショップに2回参加し、その経験をもとに、今度は自分がワークショップを運営した。
ワークショップ内容
目標
- HAZOPをやってみる（3回以上）
- HAZOPの経験から利用するときのポイントを洗い出す（1つ以上）
- HAZOPの経験から利用場面を洗い出す（1つ以上）
HAZOP演習
名古屋市工業研究所の小川さん（@kaizen_nagoya さん）が考案されたメソッドに沿って演習を実施。
スケジュール
- HAZOP ：30分×3
- 一人作業：10分
- 班作業（すべて共有）：10分
- 全体報告（1件）：5分
- 休憩・場所移動：5分
- 振り返り：15分
- 一人作業：5分
- ディスカッション：10分
ワークショップの結果
全てのワークショップで全員が経験を得る（HAZOPを3回実施する）という最大の目標を達成。
振り返り結果
HAZOPを利用するときのポイント
JaSST'18 Tokai
・レビュー対象（観点）によって見方を切り替える→機能仕様orソフトウェア設計書の書き方そのものor書いてある内容
・業務に使う前に練習する
・ガイドワードをまんべんなく見る（どこまで見るかわからない）
・見方を切り替える
・練習が必要
・まんべんなく出ているか確認
・ぶっとんだ所から細かい所にシフトしていく
・分析をするにあたりガイドワードがキーワードになり流出しやすい ※観点
・異常系に対する知識（パターン）が必要になってくる
・そんなこと無いだろうと考えずに、ありえなさそうなことも列挙してみること？
・着目ポイント（信号、機能）を明確化
・属性を意識
・おおまかなテーマを対象にすると議論が発散する
・思いついたものは、とりあえず書く
・起こりそうもないケースを考える
・３つの視点（設計者、テスター、利用者）以上で考える
・機能にしぼると良い
・皆でかぶらないと良い
・詳細仕様に対してやるのは時間がかかる
・利用シーンに対して使うのはあり
・FTAはTopdown、FMEAはBottomup、HAZOPはdownもupもしない
・アイデアリストだと思っていたよ。定義を正しく。
・とりあえずやってみる。
・使うまえに演習の事前教育。「こんなもの？」的な経験で障壁を避ける
・仕様書に書かれていないことがあげられる
・仕様書（ベース）があいまいでないほうが良い
・とりあえず発散させる、ガイドワードをもとに
・ガイドワード以外の異常もある→HAZOPで異常を網羅できるわけではない
・書かれていない部分を想像するのに使える
・信号に着目する
・機能に着目する
・上記に対してとりあえずガイドワードを当ててみる
・ありえないという思い込みの排除
・ロールと合わせて、ワードに着目、抜け漏れの確認
・ベースのQualityが高いほど良い（仕様の穴をつくもの）
・発散させるもの（アイデアを出すツール）？
・異常だけではない
・対策まで想定することは難しい
・思いついたものを書く
・各人が被らない役割を担うこと！
・Outputが被ってきたら、やり方を変える
・「小川清 HAZOP」で検索
・ブレストで案出しを行って分類する
・ロールと合わせて属性（「無」「早」）を意識するとよいかもしれない 例：「今から「無」の要素を考える！」
・ガイドワードの選択（偏らないように／製品特性／レビュー対象の特性）
・ガイドワードから連想できないとリスク分析抽出ができたか不明
・練習して粒度感／スキル向上も必要
・思いつけたものは何でも・・・
・どこまでで終わりとするか
・レビュー観点を明確にして整理すべき
JaSST'19 Tokai
・ガイドワードは発想のポイント
思いついたことをメモする
分類にはこだわらない
・仕様の要素（入力、処理、出力）の１つ毎にガイドワードをあてはめてみる
・それぞれのガイドワードの例や考え方があるとよいかも
・DBか何かで蓄積しておいて、使えるようにする
・指定毎のスコープが定まらず難しいかも
・仕様の把握が大変
・使われるシーン
・現物や状況をイメージして”外れ”を出す
・仕様の理解が弱くても、ガイドワードに沿って出す、その後、仕様とつきあわせる
出した外れが仕様内にあれば、完成度が高い
・フォーマットを頭の中にイメージ、出しやすい？
・問題を思いつく力（観点）
・重なるのはもったいない
・「ありえない」と打ち消さない
・「ありえない」ことで打ちけさない。どうなら「ありえるか」を考える
・ありえないと思っても「類」というか、それに似た状況を考えろ
例）ワイパーがゴムでない→石がかみこんでいた
・問題を思いつくことが大前提
観点にないと設計/テストでもれる
・先入観にとらわれて、列挙できないことがあった
・無理に心配点を作り出してしまう可能性がある
意図しない点になる？
・とりあえず思いつくままに書き出してみる
・無理に全部埋めようとしない
・ブレスト→組み合わせ、役割分担
・ガイドワードに縛られない、無くても思い浮かぶならそれでよい
分類にこだわらない
・フォーマットに当てはめる
○○が××したら ※○○が仕様や設計、××がガイドワード
・組み合わせた時のガイドワードがあるとよい？（同時、競合、連続など）
・問題を出せるか（困ることは？）
・得意・不得意・視点で分担
・ガイドワードにこだわらない→思いつかないときに使う
・ばくぜんと見るのではなく、注目して見る（当てはめる）
・他人の発想を利用
・出してからガイドワードに当てはめる→漏れがあればそこを重点的に
・一つでも気づけば価値あり
JaSST'19 Shikoku
・誘導語の意識合わせをすると良い
・発想を広げる、「これは・・・」と思っても言ってみる
・とりあえず11種それぞれ1個は出してみる（とんでもない回答（想定外なケース）でOK）
・1人ではなく複数人でだしあうと、さらに新たな想定外ケースが生まれる（人それぞれ観点が異なるので、みんなでケースをおぎなう）
・それぞれの視点で！（設計者＆テスト＆利用者）
・各誘導語の説明が手元にある状態でやる。
・仕様理解の時間をとる（もっと時間ほしい。もっと簡単な仕様ではじめたかった。）
・なれたら、誘導語に対してどんなイレギュラーがあるかを考えると考えやすくなった
・1人では出てこない
・かりとりで頭をやわらかくする
・仕様を作った人以外
・いつもと異なる視点
・ユニークな発想を出そうとする意識をもつ
・グループの中に皆さんの問題をききました
・立場ごとの役割に沿って、その場面を想像する
利用者：実際に運転している場面、大雨、黄砂、雪 etc
テスト：テストをしている場面、座席にすわっている、ボンネットの中を見ている
・繰り返し（1回目より3回目のほうが出た）
・アイデアが出やすい雰囲気を作る
・役割を変えて複数回行う
・どこまで想定外とするのかのライン
・そもそもハード面には問題ない前提とか（「レバーは必ずある」とか）
・きっちり作るというより気づきを促すもの（マインドマップみたい）
・イメージして、もしを考えていくと想定外が出てきやすい気がした
・ありえないことも挙げてみる
・設計書・仕様書に縛られないほうがよい気がした
今回はしばられたので、発想が狭まった
・視点を分けることに意味がある
・別の立場から新たな視点を得られる
・内容に関わらず様々な意見をあげる
・発想を広げる時
・ガイドワードの意識合わせ
・広い視野で考える
・否定しない/されない（ブレーンストーミング的な）
・相手を否定しない、マウントしない
・仕様書、設計書の誤りを発見するとすれば、プロセスパラメータをいかにみつけるかが大事
##HAZOPを利用するとよさそうな場面
JaSST'18 Tokai
・プロジェクト開始時のリスク洗い出し（レビュー観点）
・事故レビューの観点に使えそう
・上流のあいまいな箇所には適用しやすいかも
・改造よりは新規点の方がよさそう
・利用者間手がよさそう
・ガイドワード観点でのレビュー前自己チェック
・利用者観点は使い易い
・HAZOPは利用者（外部仕様）で使えるかも
・システムの外の環境（変圧とか気温とか）の考え（→システムの外でのふるまい）
・ありえなさそうなユーザーの操作
・ハード取付／イレギュラーパターン
・上流での要求分析
・FTA,FMEAではあまり出せない「ユーザー視点の使い方」を想定するには良いかも
・設計レビュー
・システム外部要因
・FTAの故障事象の導出に使う
・ドキュメントレビューで使う
・テスト設計で使う
・テストケース作成（発散しない場面）
・自分を省みるツールとして
・システム設計、ソフトウエア設計の検証時
・FMEA、FTAの網羅性確認
・ソフトウェアIF設計時
・ブレスト
・仕様書の課題点を「想像」する時（書かれていないことを想像する時）
・自己の行動評価（自己の○○な点をもっと××したい、そのためには・・・）
・分析でMECEさが求められる場合 例：11人キャストを用意してそれぞれの属性の名札を配る
・新規に制作したもの
・レビュー前の事前チェック
・機能面のヌケモレ洗い出し
JaSST'19 Tokai
・製品をリリースする前のリアルワールドを想定した場面のラストに
・DR
・QA（妥当性確認）のテスト前に考えろ
・テスト結果のレビューの時、ワードを並べればアイデアが浮かぶかも
・再現しないバグが見つかった時、ガイドワードが条件洗い出しのヒントになるかも
・プログラム仕様上のない使い方だけから
・テスト設計・テスト実施をする際の観点として（S/W設計者の考慮していない操作や入力で障害が出ないか？）
・仕様レビューをする際の観点として（S/W設計で考慮されているか？）
・要求仕様の受け入れ→Q&A
・テスト設計の観点出し
・ユーザーズマニュアルの注意点・制約に使う
・仕様・設計へのフィードバック（ちゃんと観点入ってる？）
JaSST'19 Shikoku
・対象を理解する。
・経験が浅いとき。
・行き詰った時。
・テスト。
・シナリオテストのパターン。
・コミニュケーションの場づくり/アイスブレーク。
・依頼元へ確認することを洗い出す。
・設計＆テスト（フリーデバッグ時）
・テスト設計のイレギュラー項目作成時
・テスト前のディスカッション
・一般消費者が使うシステム、プロダクト（Webサイト上のサービス）
使い方の制約がしにくい人たちなので
・テスト項目作成
・認識の祖語が生まれそうな作業がテストで事前に対策できる
・原因究明（ミスの）
・運転時の事故防止
・テストケースができたあと（FIX後にもう1回）
・要件定義終盤
・仕様把握（テスト計画前とか）
・仕様書作成時に抜け漏れを見つけるために利用できる
・仕様、設計の流れについても考えたので、何も知らない人が最初に行うといいと思った
・テストだけでなく設計時にも使う、さらに要件の洗い出しにも使える
・クリティカルなシステムの強化テスト
・異常系テストのナレッジ作り
・経験が浅い仕様書を作成する時
・仕様書を受け取った時
・シナリオテストを作成する時
ユーザは何をするかわからない
・経験の少ないPJでの要求定義のレビュー
・シナリオテスト（テストシナリオ）
・要求レビュー
・テストデータ（大きいデータはとりあえずいれとけ）
・市場での不具合が多くあって収束しないとき
・コミニュケーションの場作り
・運用時の障害発生リスクの検出
##その他（気づいたこと、疑問点、など）
JaSST'18 Tokai
・分類が多くてどこに書くか迷う
・操作を想定？事象を想定？
・信号→大小早遅・・・あらかじめ作っておけば不測の事象が防げるかも？
・ガイドワードの流派みたいなのありません？
・意地悪漢字との関係性
・対策まで導出するのは難しい
・この１１種の中に「過（Over）」がないのは？
JaSST'19 Tokai
・使わないとピンとこない
・想像力に依存するので人におってばらつきがある
発想を上げるため、ガイドワードがある
・パターンがあったほがいいのでは
・視点の違いが不明瞭
・仕様の理解が弱くてもできるのでない
・パターン化できるとよい
・議論できると広がる
・ムリに埋めず、絞っていくとよい
・ガイドワードから思いつけるとやりやすい
・思いついたものを仕様書から探すというやり方もありそう
・思いつかないガイドワードを改めて考えたほうがよい
JaSST'19 Shikoku
・ガイドワードの例を少し話してから始めるとよいのかもと思いました。ただ思考を狭めるかもしれないのですね。
・面白く楽しくできました。
・1回目考え方がまったくわからず、1つも出ませんでした。
・もう少し考え方の方向性を事前に欲しいです。
動作結果が想定外なのか…操作、処理内容が想定外なのか…
誘導語の考え方の説明
・説明も抽象的で何やったらいいかわからない…
・HAZOPの演習をしたくても、やり方を説明できない（3回やったけど、ちょっとわからないところが多い）
・どうやって11のガイドワードに絞ったのだろう？
・3つで十分
・使い方がいまだに良くわからない
・何人くらいでやるもの？
・ガイドワードが埋まらなくて良いのか？
（あくまで思考のきっかけ？）
・どのくらいの時間で洗い出すのがよいか
・そもそもこれは1人でやるもの？今日みたいにワーク式でチームでやるもの？どっちでも？
・11の考えが曖昧過ぎるので、人によって個人差が大きくなりそう
・数回やらないと具体的な意見が出てこない気がする
・11の言葉がきちんとつかえていたか、実感があまりなかった
・ガイドワードを増やしてもよいのでは（同とか）
もしくはガイドワード以外から挙げてもよければ、ルールとして明確化する
・人の考え方、こだわり、着眼点は様々
・ブレスト-多人数-正解なしが良い
→最後に洗い出しと評価により、価値あるテストケースの検出が出来そう
・無数にリストアップできるか・・・
・重要な部分にフォーカスするには？
・複数項目の組み合わせも考えてみる
・ガイドワードの認識一致、例が欲しい
・テスト分析にも活用できたりするのでは？と思いました。
（立ち位置を変えて読むことで理解しやすくなった）
・小川メソッドで実施した場合、ガイドワードは役に立っていることもあるが、これだと分析者の思いつきによるところが多いのではないかと思います。
・リスクの検出→リスクの発生源の特定＋リスクドライバの識別
リスク発生源の特定は、HAZOPでいうプロセス（運用）パラメータに相当する
リスクドライバの識別は、HAZOPのガイドワードに相当する
これの組み合わせにより、想定外が見い出せるのでは？
・最初に設計者視点でやろうとすると、機能仕様書、外部仕様書を見ずに基本設計書を見なければならないことが想定外でした。
ワークショップで私が得た知見
-
想定外に気づくために、「ありえない」と切り捨てない。
- 「ありえない」と思った状況・条件であっても、それと似た状況・条件がないかを考えてみる。
- 一瞬「ありえない」と思った事象でも、どういう状況・条件なら「ありえるか」を考えてみる。
-
ガイドワードを使うことが、漠然と対象を見るのではなく、注目して対象を見ることに繋がりそう。
-
分析で想定外を洗い出すために、
- みんなと同じということではなく、違うということに価値がある
- 何を考えても何を発言してもいい、間違いはない、という空気をつくる
- あえて、人と逆のことを考えてみる
- あえて、違う方向（否定ではない）の発言をしてみる
- あえて、人と違うことをしてみる
- 「あーー、」という反応があるのは、いい傾向
- たまに笑顔・笑いがあるのは、いい傾向
- 全員が同じ反応をしているのは、よくない傾向
謝辞
ワークショップにご参加いただきました皆様に、感謝申し上げます。ありがとうございました。
ワークショップを一緒に運営していただきました小川さん、村上さんに、感謝申し上げます。ありがとうございました。
ワークショップの機会を与えていただいたJaSST実行委員の皆様に、感謝申し上げます。ありがとうございました。
#参考記事
https://qiita.com/kaizen_nagoya/items/e62e91cb019c6275d6c1
#あとがき
ソフトウェア品質シンポジウム2021で、本記事の内容を参照した発表をします。
タイトル「DRBFMにおける一人HAZOPの活用方法の提案」
https://www.juse.jp/sqip/symposium/detail/day1/#a2-3