@kazuo_reve ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果
「ワークショップ「ソフトウェア開発におけるHAZOP入門」の結果」の分類
を受けて書き始めた記事です。
<この項は書きかけです。順次追記します。>
目的
安全分析はじめ、分析をする際の抽象的な手法であるHAZOPを、他の手法と併せて利用できるようになる。
成果
実行する前に、個人and/or組織で、作業の目標を立てる。
例：
これまでに想定していない事故、操作を一つ以上記録する。
災害時、非常事態など、複数の要因で機能しない場合の対策を想定する。
顧客、仕入れ先の大事だと思っていることを知り認識合わせを行う。
方法
やり方は、毎回、変更するのがよい。
人数、時間、経験者の密度・深さ、説明の範囲など、考えられるありとあらゆるもの・ことを変更してみる。
組織の都合で、一通り全員作業するまで、同じやり方で作業する必要がある場合には、対象、経験者の組み合わせ、追加する設計規範などをすこしづつ変更し、影響を観察する程度に抑える。
説明
説明はなるべくしない方がよい。
説明すればするほど、成果の範囲が狭くなり、密度が薄くなり、誰がやっても同じ結果しかでず、計算機の機械学習ですれば済むことより少なくなる可能性がある。
１１個の誘導語(guide word)
があることを説明していればよい。
１回目は、一つだけでもよいし、時間があれば３つくらい出せればよい。３人で組めば、３＊３で９つ集まるかもしれない。
２回目以降に、それ以外を考えてみればよい。
一人の作業と班（３人）の作業とを組み合わせる
一人の作業をせずに集まっても、特定の人だけが作業をすることになる可能性が高まり、作業の生産性があがらない。
発想できない人が現れても、その原因を自分の専門性、経験に求めることが大事で、やり方に求めないようにするとよい。
どんなに全く関係のなさそうに見える専門性でも、今考えている対象にも役立つかもしれないことに気が付くまでやり続けるとよい。
誤解は大事な情報源で、利用者が誤解して使用したり、運用者が誤解して操作した時の現象を洗い出すのに役立つ。
データ分類の最初の記録は下記。
https://github.com/kaizen-nagoya/hazop/blob/master/Do/kashiwabara.md
分類(classification)
| 番号 | 分類 |
|---|---|
| 1 | 試行錯誤 |
| 2 | 想定外 |
| 3 | いろんなやり方 |
| 4 | 測定・対策 |
| 5 | 時間・終点 |
| 6 | 訓練 |
分類で並べ替えた一覧は下記。
試行錯誤
| 場所 | 項目 | 順番 | 分類 | 内容 |
|---|---|---|---|---|
| 2 | 1 | 2 | 1 | 思いついたことをメモする |
| 3 | 1 | 19 | 1 | ・アイデアが出やすい雰囲気を作る |
| 1 | 1 | 10 | 1 | ・そんなこと無いだろうと考えずに、ありえなさそうなことも列挙してみること？ |
| 1 | 1 | 23 | 1 | ・とりあえずやってみる。 |
| 2 | 1 | 25 | 1 | ・とりあえず思いつくままに書き出してみる |
| 1 | 1 | 27 | 1 | ・とりあえず発散させる、ガイドワードをもとに |
| 2 | 1 | 39 | 1 | ・一つでも気づけば価値あり |
| 1 | 1 | 4 | 1 | ・見方を切り替える |
| 1 | 1 | 14 | 1 | ・思いついたものは、とりあえず書く |
| 1 | 1 | 39 | 1 | ・思いついたものを書く |
| 1 | 1 | 48 | 1 | ・思いつけたものは何でも・・・ |
| 1 | 1 | 32 | 1 | ・上記に対してとりあえずガイドワードを当ててみる |
| 3 | 1 | 30 | 1 | ・内容に関わらず様々な意見をあげる |
| 3 | 3 | 72 | 1 | ・面白く楽しくできました。 |
想定外
| 場所 | 項目 | 順番 | 分類 | 内容 |
|---|---|---|---|---|
| 3 | 2 | 63 | 2 | ユーザは何をするかわからない |
| 2 | 1 | 17 | 2 | ・「ありえない」ことで打ちけさない。どうなら「ありえるか」を考える |
| 2 | 1 | 16 | 2 | ・「ありえない」と打ち消さない |
| 1 | 2 | 63 | 2 | ・FTA,FMEAではあまり出せない「ユーザー視点の使い方」を想定するには良いかも |
| 1 | 2 | 66 | 2 | ・FTAの故障事象の導出に使う |
| 3 | 1 | 25 | 2 | ・ありえないことも挙げてみる |
| 1 | 1 | 33 | 2 | ・ありえないという思い込みの排除 |
| 2 | 1 | 18 | 2 | ・ありえないと思っても「類」というか、それに似た状況を考えろ |
| 1 | 2 | 60 | 2 | ・ありえなさそうなユーザーの操作 |
| 3 | 1 | 12 | 2 | ・いつもと異なる視点 |
| 3 | 2 | 58 | 2 | ・クリティカルなシステムの強化テスト |
| 1 | 1 | 7 | 2 | ・ぶっとんだ所から細かい所にシフトしていく |
| 2 | 2 | 45 | 2 | ・プログラム仕様上のない使い方だけから |
| 2 | 2 | 50 | 2 | ・ユーザーズマニュアルの注意点・制約に使う |
| 3 | 1 | 13 | 2 | ・ユニークな発想を出そうとする意識をもつ |
| 3 | 2 | 59 | 2 | ・異常系テストのナレッジ作り |
| 3 | 2 | 51 | 2 | ・運転時の事故防止 |
| 1 | 1 | 15 | 2 | ・起こりそうもないケースを考える |
| 2 | 1 | 10 | 2 | ・現物や状況をイメージして”外れ”を出す |
| 3 | 1 | 11 | 2 | ・仕様を作った人以外 |
| 1 | 1 | 29 | 2 | ・書かれていない部分を想像するのに使える |
| 3 | 1 | 35 | 2 | ・相手を否定しない、マウントしない |
| 1 | 1 | 36 | 2 | ・発散させるもの（アイデアを出すツール）？ |
| 3 | 1 | 34 | 2 | ・否定しない/されない（ブレーンストーミング的な） |
| 3 | 1 | 29 | 2 | ・別の立場から新たな視点を得られる |
測定・対策
| 場所 | 項目 | 順番 | 分類 | 内容 |
|---|---|---|---|---|
| 1 | 3 | 86 | 4 | ・対策まで導出するのは難しい |
時間・終点
| 場所 | 項目 | 順番 | 分類 | 内容 |
|---|---|---|---|---|
| 1 | 1 | 49 | 5 | ・どこまでで終わりとするか |
| 3 | 3 | 85 | 5 | ・どのくらいの時間で洗い出すのがよいか |
| 1 | 1 | 19 | 5 | ・詳細仕様に対してやるのは時間がかかる |
| 3 | 3 | 95 | 5 | ・無数にリストアップできるか・・・ |
教育・訓練
自分で指導する場合には、自分が必要だと思う教育をしてみて実施してみてください。
２度、同じ教育をしても、全く異なる成果と反応が帰ってくるかもしれません。
参加される方の分布、人の組み合わせ方の方が、教育の仕方・内容よりも変動要因が大きいというのが経験則です。
三人に一人、設計者を確保できれば、教育は不要だというのも経験則です。
| 場所 | 項目 | 順番 | 分類 | 内容 |
|---|---|---|---|---|
| 3 | 3 | 76 | 6 | 誘導語の考え方の説明 |
| 3 | 3 | 89 | 6 | ・11の言葉がきちんとつかえていたか、実感があまりなかった |
| 3 | 3 | 73 | 6 | ・1回目考え方がまったくわからず、1つも出ませんでした。 |
| 3 | 1 | 9 | 6 | ・1人では出てこない |
| 3 | 1 | 1 | 6 | ・誘導語の意識合わせをすると良い |
| 3 | 3 | 78 | 6 | ・HAZOPの演習をしたくても、やり方を説明できない（3回やったけど、ちょっとわからないところが多い） |
| 3 | 3 | 98 | 6 | ・ガイドワードの認識一致、例が欲しい |
| 3 | 3 | 71 | 6 | ・ガイドワードの例を少し話してから始めるとよいのかもと思いました。ただ思考を狭めるかもしれないのですね。 |
| 1 | 3 | 87 | 6 | ・この１１種の中に「過（Over）」がないのは？*1 |
| 3 | 3 | 86 | 6 | ・そもそもこれは1人でやるもの？今日みたいにワーク式でチームでやるもの？どっちでも？*2 |
| 3 | 3 | 79 | 6 | ・どうやって11のガイドワードに絞ったのだろう？ |
| 3 | 3 | 74 | 6 | ・もう少し考え方の方向性を事前に欲しいです。 |
| 3 | 3 | 82 | 6 | ・何人くらいでやるもの？ |
| 1 | 1 | 2 | 6 | ・業務に使う前に練習する |
| 3 | 1 | 18 | 6 | ・繰り返し（1回目より3回目のほうが出た） |
| 3 | 3 | 81 | 6 | ・使い方がいまだに良くわからない |
| 1 | 1 | 24 | 6 | ・使うまえに演習の事前教育。「こんなもの？」的な経験で障壁を避ける |
| 2 | 3 | 52 | 6 | ・使わないとピンとこない |
| 3 | 3 | 88 | 6 | ・数回やらないと具体的な意見が出てこない気がする |
| 3 | 3 | 77 | 6 | ・説明も抽象的で何やったらいいかわからない… |
| 2 | 1 | 22 | 6 | ・先入観にとらわれて、列挙できないことがあった |
| 2 | 3 | 53 | 6 | ・想像力に依存するので人によってばらつきがある |
| 1 | 3 | 81 | 6 | ・分類が多くてどこに書くか迷う |
| 2 | 1 | 14 | 6 | ・問題を思いつく力（観点） |
| 1 | 1 | 5 | 6 | ・練習が必要 |
| 1 | 1 | 47 | 6 | ・練習して粒度感／スキル向上も必要 |
*1
過ぎる(Over)は、大(More)が代表しています。
設計の上限を超えるのがMoreです。
*2
立場の異なる人が３人で集まって作業するのが効果的です。
３人集まる場合でも、１人での作業をするのが原則です。
出荷までに３回実施するとした場合、製品によってはその間の１回または２回は、一人で作業する場合もあるかもしれません。
いろんなやり方
いろんなやり方を試してみるとよいでしょう。
特定の製品の場合には、特定のやり方が効率的になるかもしれません。
しかし、同じやり方を繰り返していると、想定外は洗い出せなくなるかもしれません。
こうしてみた方がよいのではと思いついたら、その方法でやってみて、その場合の利点と課題を出しておくとよいでしょう。
人依存です。参加された方の能力を最大限発揮してもらうことが大事です。
| 場所 | 項目 | 順番 | 分類 | 内容 |
|---|---|---|---|---|
| 3 | 3 | 84 | 3 | （あくまで思考のきっかけ？） |
| 3 | 3 | 100 | 3 | （立ち位置を変えて読むことで理解しやすくなった） |
| 3 | 3 | 94 | 3 | →最後に洗い出しと評価により、価値あるテストケースの検出が出来そう |
| 2 | 1 | 31 | 3 | ○○が××したら ※○○が仕様や設計、××がガイドワード |
| 3 | 3 | 105 | 3 | これの組み合わせにより、想定外が見い出せるのでは？ |
| 3 | 1 | 17 | 3 | テスト：テストをしている場面、座席にすわっている、ボンネットの中を見ている |
| 3 | 3 | 104 | 3 | リスクドライバの識別は、HAZOPのガイドワードに相当する |
| 3 | 3 | 103 | 3 | リスク発生源の特定は、HAZOPでいうプロセス（運用）パラメータに相当する |
| 2 | 1 | 24 | 3 | 意図しない点になる？ |
| 2 | 1 | 21 | 3 | 観点にないと設計/テストでもれる |
| 3 | 1 | 27 | 3 | 今回はしばられたので、発想が狭まった |
| 2 | 1 | 12 | 3 | 出した外れが仕様内にあれば、完成度が高い |
| 3 | 3 | 75 | 3 | 動作結果が想定外なのか…操作、処理内容が想定外なのか… |
| 2 | 3 | 54 | 3 | 発想を上げるため、ガイドワードがある |
| 2 | 1 | 29 | 3 | 分類にこだわらない |
| 2 | 1 | 3 | 3 | 分類にはこだわらない |
| 3 | 1 | 16 | 3 | 利用者：実際に運転している場面、大雨、黄砂、雪 etc |
| 2 | 1 | 19 | 3 | 例）ワイパーがゴムでない→石がかみこんでいた |
| 3 | 3 | 87 | 3 | ・11の考えが曖昧過ぎるので、人によって個人差が大きくなりそう |
| 3 | 1 | 4 | 3 | ・1人ではなく複数人でだしあうと、さらに新たな想定外ケースが生まれる（人それぞれ観点が異なるので、みんなでケースをおぎなう） |
| 3 | 3 | 80 | 3 | ・3つで十分 |
| 1 | 1 | 16 | 3 | ・３つの視点（設計者、テスター、利用者）以上で考える |
| 2 | 1 | 6 | 3 | ・DBか何かで蓄積しておいて、使えるようにする |
| 2 | 2 | 41 | 3 | ・DR |
| 1 | 2 | 72 | 3 | ・FMEA、FTAの網羅性確認 |
| 1 | 1 | 21 | 3 | ・FTAはTopdown、FMEAはBottomup、HAZOPはdownもupもしない |
| 1 | 2 | 58 | 3 | ・HAZOPは利用者（外部仕様）で使えるかも |
| 1 | 1 | 41 | 3 | ・Outputが被ってきたら、やり方を変える |
| 2 | 2 | 42 | 3 | ・QA（妥当性確認）のテスト前に考えろ |
| 1 | 1 | 22 | 3 | ・アイデアリストだと思っていたよ。定義を正しく。 |
| 3 | 1 | 24 | 3 | ・イメージして、もしを考えていくと想定外が出てきやすい気がした |
| 1 | 1 | 13 | 3 | ・おおまかなテーマを対象にすると議論が発散する |
| 2 | 3 | 61 | 3 | ・ガイドワードから思いつけるとやりやすい |
| 1 | 1 | 46 | 3 | ・ガイドワードから連想できないとリスク分析抽出ができたか不明 |
| 3 | 3 | 83 | 3 | ・ガイドワードが埋まらなくて良いのか？ |
| 2 | 1 | 35 | 3 | ・ガイドワードにこだわらない→思いつかないときに使う |
| 2 | 1 | 28 | 3 | ・ガイドワードに縛られない、無くても思い浮かぶならそれでよい |
| 3 | 1 | 32 | 3 | ・ガイドワードの意識合わせ |
| 1 | 1 | 45 | 3 | ・ガイドワードの選択（偏らないように／製品特性／レビュー対象の特性） |
| 1 | 3 | 84 | 3 | ・ガイドワードの流派みたいなのありません？ |
| 2 | 1 | 1 | 3 | ・ガイドワードは発想のポイント |
| 1 | 1 | 3 | 3 | ・ガイドワードをまんべんなく見る（どこまで見るかわからない） |
| 3 | 3 | 90 | 3 | ・ガイドワードを増やしてもよいのでは（同とか） |
| 1 | 1 | 28 | 3 | ・ガイドワード以外の異常もある→HAZOPで異常を網羅できるわけではない |
| 1 | 2 | 56 | 3 | ・ガイドワード観点でのレビュー前自己チェック |
| 3 | 1 | 10 | 3 | ・かりとりで頭をやわらかくする |
| 3 | 1 | 23 | 3 | ・きっちり作るというより気づきを促すもの（マインドマップみたい） |
| 3 | 1 | 14 | 3 | ・グループの中に皆さんの問題をききました |
| 3 | 2 | 42 | 3 | ・コミニュケーションの場づくり/アイスブレーク。 |
| 3 | 2 | 69 | 3 | ・コミニュケーションの場作り |
| 1 | 2 | 59 | 3 | ・システムの外の環境（変圧とか気温とか）の考え（→システムの外でのふるまい） |
| 1 | 2 | 65 | 3 | ・システム外部要因 |
| 1 | 2 | 71 | 3 | ・システム設計、ソフトウエア設計の検証時 |
| 3 | 2 | 65 | 3 | ・シナリオテスト（テストシナリオ） |
| 3 | 2 | 41 | 3 | ・シナリオテストのパターン。 |
| 3 | 2 | 62 | 3 | ・シナリオテストを作成する時 |
| 1 | 2 | 73 | 3 | ・ソフトウェアIF設計時 |
| 3 | 1 | 22 | 3 | ・そもそもハード面には問題ない前提とか（「レバーは必ずある」とか） |
| 2 | 1 | 5 | 3 | ・それぞれのガイドワードの例や考え方があるとよいかも |
| 3 | 1 | 5 | 3 | ・それぞれの視点で！（設計者＆テスト＆利用者） |
| 3 | 2 | 40 | 3 | ・テスト。 |
| 3 | 2 | 52 | 3 | ・テストケースができたあと（FIX後にもう1回） |
| 1 | 2 | 69 | 3 | ・テストケース作成（発散しない場面） |
| 3 | 2 | 57 | 3 | ・テストだけでなく設計時にも使う、さらに要件の洗い出しにも使える |
| 3 | 2 | 67 | 3 | ・テストデータ（大きいデータはとりあえずいれとけ） |
| 2 | 2 | 43 | 3 | ・テスト結果のレビューの時、ワードを並べればアイデアが浮かぶかも |
| 3 | 2 | 48 | 3 | ・テスト項目作成 |
| 2 | 2 | 46 | 3 | ・テスト設計・テスト実施をする際の観点として（S/W設計者の考慮していない操作や入力で障害が出ないか？） |
| 1 | 2 | 68 | 3 | ・テスト設計で使う |
| 3 | 2 | 45 | 3 | ・テスト設計のイレギュラー項目作成時 |
| 2 | 2 | 49 | 3 | ・テスト設計の観点出し |
| 3 | 2 | 46 | 3 | ・テスト前のディスカッション |
| 3 | 3 | 99 | 3 | ・テスト分析にも活用できたりするのでは？と思いました。 |
| 1 | 2 | 67 | 3 | ・ドキュメントレビューで使う |
| 3 | 1 | 21 | 3 | ・どこまで想定外とするのかのライン |
| 3 | 1 | 3 | 3 | ・とりあえず11種それぞれ1個は出してみる（とんでもない回答（想定外なケース）でOK） |
| 3 | 1 | 8 | 3 | ・なれたら、誘導語に対してどんなイレギュラーがあるかを考えると考えやすくなった |
| 1 | 2 | 61 | 3 | ・ハード取付／イレギュラーパターン |
| 2 | 1 | 36 | 3 | ・ばくぜんと見るのではなく、注目して見る（当てはめる） |
| 2 | 3 | 55 | 3 | ・パターンがあったほがいいのでは |
| 2 | 3 | 58 | 3 | ・パターン化できるとよい |
| 2 | 1 | 30 | 3 | ・フォーマットに当てはめる |
| 2 | 1 | 13 | 3 | ・フォーマットを頭の中にイメージ、出しやすい？ |
| 1 | 2 | 74 | 3 | ・ブレスト |
| 3 | 3 | 93 | 3 | ・ブレスト-多人数-正解なしが良い |
| 2 | 1 | 27 | 3 | ・ブレスト→組み合わせ、役割分担 |
| 1 | 1 | 43 | 3 | ・ブレストで案出しを行って分類する |
| 1 | 2 | 51 | 3 | ・プロジェクト開始時のリスク洗い出し（レビュー観点） |
| 1 | 1 | 35 | 3 | ・ベースのQualityが高いほど良い（仕様の穴をつくもの） |
| 1 | 1 | 6 | 3 | ・まんべんなく出ているか確認 |
| 2 | 3 | 60 | 3 | ・ムリに埋めず、絞っていくとよい |
| 3 | 3 | 102 | 3 | ・リスクの検出→リスクの発生源の特定＋リスクドライバの識別 |
| 1 | 1 | 50 | 3 | ・レビュー観点を明確にして整理すべき |
| 1 | 2 | 79 | 3 | ・レビュー前の事前チェック |
| 1 | 1 | 1 | 3 | ・レビュー対象（観点）によって見方を切り替える→機能仕様orソフトウェア設計書の書き方そのものor書いてある内容 |
| 1 | 1 | 34 | 3 | ・ロールと合わせて、ワードに着目、抜け漏れの確認 |
| 1 | 1 | 44 | 3 | ・ロールと合わせて属性（「無」「早」）を意識するとよいかもしれない 例：「今から「無」の要素を考える！」 |
| 3 | 2 | 43 | 3 | ・依頼元へ確認することを洗い出す。 |
| 1 | 3 | 85 | 3 | ・意地悪漢字との関係性 |
| 1 | 1 | 37 | 3 | ・異常だけではない |
| 1 | 1 | 9 | 3 | ・異常系に対する知識（パターン）が必要になってくる |
| 3 | 2 | 47 | 3 | ・一般消費者が使うシステム、プロダクト（Webサイト上のサービス）使い方の制約がしにくい人たちなので |
| 3 | 2 | 70 | 3 | ・運用時の障害発生リスクの検出 |
| 1 | 2 | 54 | 3 | ・改造よりは新規点の方がよさそう |
| 1 | 1 | 18 | 3 | ・皆でかぶらないと良い |
| 1 | 1 | 40 | 3 | ・各人が被らない役割を担うこと！ |
| 3 | 1 | 6 | 3 | ・各誘導語の説明が手元にある状態でやる。 |
| 1 | 1 | 17 | 3 | ・機能にしぼると良い |
| 1 | 1 | 31 | 3 | ・機能に着目する |
| 1 | 2 | 80 | 3 | ・機能面のヌケモレ洗い出し |
| 2 | 3 | 59 | 3 | ・議論できると広がる |
| 3 | 2 | 38 | 3 | ・経験が浅いとき。 |
| 3 | 2 | 60 | 3 | ・経験が浅い仕様書を作成する時 |
| 3 | 2 | 64 | 3 | ・経験の少ないPJでの要求定義のレビュー |
| 3 | 2 | 50 | 3 | ・原因究明（ミスの） |
| 3 | 1 | 33 | 3 | ・広い視野で考える |
| 3 | 2 | 39 | 3 | ・行き詰った時。 |
| 2 | 2 | 44 | 3 | ・再現しないバグが見つかった時、ガイドワードが条件洗い出しのヒントになるかも |
| 3 | 3 | 106 | 3 | ・最初に設計者視点でやろうとすると、機能仕様書、外部仕様書を見ずに基本設計書を見なければならないことが想定外でした。 |
| 2 | 2 | 51 | 3 | ・仕様・設計へのフィードバック（ちゃんと観点入ってる？） |
| 3 | 2 | 56 | 3 | ・仕様、設計の流れについても考えたので、何も知らない人が最初に行うといいと思った |
| 2 | 1 | 8 | 3 | ・仕様の把握が大変 |
| 2 | 1 | 4 | 3 | ・仕様の要素（入力、処理、出力）の１つ毎にガイドワードをあてはめてみる |
| 2 | 1 | 11 | 3 | ・仕様の理解が弱くても、ガイドワードに沿って出す、その後、仕様とつきあわせる |
| 2 | 3 | 57 | 3 | ・仕様の理解が弱くてもできるのでない |
| 2 | 2 | 47 | 3 | ・仕様レビューをする際の観点として（S/W設計で考慮されているか？） |
| 3 | 1 | 36 | 3 | ・仕様書、設計書の誤りを発見するとすれば、プロセスパラメータをいかにみつけるかが大事 |
| 1 | 1 | 26 | 3 | ・仕様書（ベース）があいまいでないほうが良い |
| 1 | 1 | 25 | 3 | ・仕様書に書かれていないことがあげられる |
| 1 | 2 | 75 | 3 | ・仕様書の課題点を「想像」する時（書かれていないことを想像する時） |
| 3 | 2 | 61 | 3 | ・仕様書を受け取った時 |
| 3 | 2 | 55 | 3 | ・仕様書作成時に抜け漏れを見つけるために利用できる |
| 3 | 2 | 54 | 3 | ・仕様把握（テスト計画前とか） |
| 3 | 1 | 7 | 3 | ・仕様理解の時間をとる（もっと時間ほしい。もっと簡単な仕様ではじめたかった。） |
| 2 | 1 | 9 | 3 | ・使われるシーン |
| 3 | 2 | 68 | 3 | ・市場での不具合が多くあって収束しないとき |
| 2 | 3 | 62 | 3 | ・思いついたものを仕様書から探すというやり方もありそう |
| 2 | 3 | 63 | 3 | ・思いつかないガイドワードを改めて考えたほうがよい |
| 2 | 1 | 7 | 3 | ・指定毎のスコープが定まらず難しいかも |
| 2 | 3 | 56 | 3 | ・視点の違いが不明瞭 |
| 3 | 1 | 28 | 3 | ・視点を分けることに意味がある |
| 1 | 2 | 52 | 3 | ・事故レビューの観点に使えそう |
| 1 | 2 | 76 | 3 | ・自己の行動評価（自己の○○な点をもっと××したい、そのためには・・・） |
| 1 | 2 | 70 | 3 | ・自分を省みるツールとして |
| 2 | 1 | 15 | 3 | ・重なるのはもったいない |
| 3 | 3 | 96 | 3 | ・重要な部分にフォーカスするには？ |
| 2 | 1 | 38 | 3 | ・出してからガイドワードに当てはめる→漏れがあればそこを重点的に |
| 3 | 3 | 101 | 3 | ・小川メソッドで実施した場合、ガイドワードは役に立っていることもあるが、これだと分析者の思いつきによるところが多いのではないかと思います。 |
| 1 | 2 | 62 | 3 | ・上流での要求分析 |
| 1 | 2 | 53 | 3 | ・上流のあいまいな箇所には適用しやすいかも |
| 1 | 3 | 83 | 3 | ・信号→大小早遅・・・あらかじめ作っておけば不測の事象が防げるかも？ |
| 1 | 1 | 30 | 3 | ・信号に着目する |
| 1 | 2 | 78 | 3 | ・新規に制作したもの |
| 3 | 3 | 92 | 3 | ・人の考え方、こだわり、着眼点は様々 |
| 2 | 2 | 40 | 3 | ・製品をリリースする前のリアルワールドを想定した場面のラストに |
| 3 | 2 | 44 | 3 | ・設計＆テスト（フリーデバッグ時） |
| 1 | 2 | 64 | 3 | ・設計レビュー |
| 3 | 1 | 26 | 3 | ・設計書・仕様書に縛られないほうがよい気がした |
| 2 | 1 | 32 | 3 | ・組み合わせた時のガイドワードがあるとよい？（同時、競合、連続など） |
| 1 | 3 | 82 | 3 | ・操作を想定？事象を想定？ |
| 1 | 1 | 12 | 3 | ・属性を意識 |
| 2 | 1 | 37 | 3 | ・他人の発想を利用 |
| 1 | 1 | 38 | 3 | ・対策まで想定することは難しい |
| 3 | 2 | 37 | 3 | ・対象を理解する。 |
| 1 | 1 | 11 | 3 | ・着目ポイント（信号、機能）を明確化 |
| 2 | 1 | 34 | 3 | ・得意・不得意・視点で分担 |
| 3 | 2 | 49 | 3 | ・認識の祖語が生まれそうな作業がテストで事前に対策できる |
| 3 | 1 | 2 | 3 | ・発想を広げる、「これは・・・」と思っても言ってみる |
| 3 | 1 | 31 | 3 | ・発想を広げる時 |
| 3 | 3 | 97 | 3 | ・複数項目の組み合わせも考えてみる |
| 1 | 2 | 77 | 3 | ・分析でMECEさが求められる場合 例：11人キャストを用意してそれぞれの属性の名札を配る |
| 1 | 1 | 8 | 3 | ・分析をするにあたりガイドワードがキーワードになり流出しやすい ※観点 |
| 2 | 1 | 23 | 3 | ・無理に心配点を作り出してしまう可能性がある |
| 2 | 1 | 26 | 3 | ・無理に全部埋めようとしない |
| 2 | 1 | 20 | 3 | ・問題を思いつくことが大前提 |
| 2 | 1 | 33 | 3 | ・問題を出せるか（困ることは？） |
| 3 | 1 | 20 | 3 | ・役割を変えて複数回行う |
| 3 | 2 | 66 | 3 | ・要求レビュー |
| 2 | 2 | 48 | 3 | ・要求仕様の受け入れ→Q&A |
| 3 | 2 | 53 | 3 | ・要件定義終盤 |
| 1 | 1 | 20 | 3 | ・利用シーンに対して使うのはあり |
| 1 | 2 | 55 | 3 | ・利用者観点がよさそう |
| 1 | 2 | 57 | 3 | ・利用者観点は使い易い |
| 3 | 1 | 15 | 3 | ・立場ごとの役割に沿って、その場面を想像する |
| 3 | 3 | 91 | 3 | もしくはガイドワード以外から挙げてもよければ、ルールとして明確化する |
#参考資料(reference)
Copy Table in Excel and Paste as a Markdown Table
https://thisdavej.com/copy-table-in-excel-and-paste-as-a-markdown-table/
自己参照(self reference)
安全分析における三つの仕事
安全分析においてHAZOPで想定外を洗い出すために
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20200310
ver. 0.02 空白補正 20221112
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.