はじめて自動車で擦ってしまった話
GW 中の事です。
コロナ禍で不要な外出は控える環境ですが、あまりにも出かけなさすぎで息が詰まったのでドライブに出かけました。 その際に立ち寄った飲食店で、人生ではじめて人の車に擦ってしまいました。 食事中のソーシャルディスタンスには気をつけていたのですが、車同士の間隔を空ける注意力が足りませんでした。 その時の話をしようと思います。
ご飯を食べ終わりお店を後にしようとエンジンを掛けたら、これから自分が空ける駐車スペースを3台の車が狙っていることに気付きました。 駐車場が決して広くはなく(狭いわけではない)、前向き駐車をしたために、そこからバックで出るには窮屈さを感じていました。 3台の車が少しずつ動いていたので、後ろの状況が常に変化しているのが恐いと思い、全神経が後ろに集中しました。
運転が上手な人が見ればこの時点で、オイッ！ってなるかもしれません。
ゆっくりゆっくりと下がっていると、車内に 「コツン・・ガッ！」と音が・・・。 前に神経を戻すと、隣の車に左側のフロントバンパーを擦っていることに気付き、「自分もついにやったな」と思いました。
車を停め直し、一呼吸してするべきことを考えて、真っ先に思い浮かんだのは、車の持ち主を探すことでした。
お店の人に相手方の車のナンバーを伝えて持ち主のお客さんを呼んでもらい、状況の説明と謝罪と傷の確認をしてもらいました。
相手方の車に接触した箇所は後輪のタイヤのホイールについた傷で、ボディには傷やへこみが見つからなかったのもあって、 「これくらいじゃいいよ、正直に言ってきたから許す」と言われました。
予想外の許しに戸惑ったものの、後で傷が見つかったらいけないので「連絡先を教えて下さい」と聞くと断られてしまいました。 その後も謝罪をし、少し話をした後。お店を出て自宅に帰りました。
というお話になります。(後日、警察に相談をしました。)
示談ということで話は終わりましたが、このようなことがあったので事故を起こした時の対処法を知っておかなければいけないと感じました。
ここからは自分の為に事故処理の仕方を調べた内容になります。
事故を起こしてしまった時にすること
対人事故を起こしてしまった場合は、被害者の救護が何よりも優先になります。
次に、事故の状況で二次災害を起こさない注意が必要です。 今回は駐車場なので安全でしたが、安全を確保できない場所であれば、発煙筒を焚いたり、三角表示板を置いたりする対処が必要になります。
そして、今回のような小さな事故でも本来は、警察と保険会社に連絡をします。そして保険会社の人に対応やアドバイスを貰えるとのことです。
事故を起こしたことで冷静に判断出来なくなる事があるので、保険会社の人が適切に指示をくれるそうです。 冷静な判断ができない時の為に、「安全確保・警察・保険会社」の３つを最低限やらなくてはいけないこととして覚えました。
調べてみると相手方に、氏名や住所、電話番号、ナンバーを聞いてメモをしたり、やる事は結構あるのですが、それも保険会社の人が指示をくれるみたいです。
また、調べてみると自分と同じ、相手方が許してくれたので警察へ連絡しなかった。という話は沢山あったのですが、本来は法律上の義務として警察に届け出なくてはいけないそうです。
また、事故を起こしてしまった時はするべきことだけではなく、してはいけないこともあるようです。
事故を起こした時に、してはいけないこと
加害者として、してはいけないことです。
調べてわかった内容は、被害者を守る事だけでなく自分の事も守るのが大事だそうです。 損害賠償の額についてなど事故処理の具体的な話をするべきではないそうです。 トラブルの最中、当事者の判断が冷静とは言えません。 被害者の怒りが収まらない事もあるし、それは状況によっては加害者にもありえます。 逆に加害者としての申し訳無さから、謝罪の誠意を見せようと相手の言う事を全て聞いてしまう事もあります。 冷静とは言えない状態で話を進めてしまうと、本来するべき事故処理以上のトラブルに巻き込まれることもあるそうです。
示談した後日に連絡が来た「身体に異常が出た」「車にキズがついていた」
軽微な事故で示談した後もトラブルが続くケースがあります。こうなった場合、保険会社は一応相談に乗ってくれるそうなのですが、事故の起きたその場でないと証拠になるものが殆ど無くなっています。 当事者達の話だけでは本来されるべき事故処理は難しく。保険金を受け取れる期待は小さくなるそうです。 また事故が大きい程、被害者側の保険会社にも救われる場合があるので、後からのトラブルは避けたいです。
「被害者から事故処理の念書に一筆を求められた」
「事故の原因は全て自分にあり、被害者の損害を全て賠償します」と一筆を書いたら、過失の割合が 10:0 で無かったとしても、原因が全て自分である証拠になる可能性があるそうです。
謝ってはいけない？
「事故の加害者になったとしても、不利になるから謝ってはいけない。」という考え方もあります。 自分もこのように教わっていました。警察や保険会社に事故状況を報告する際に、被害者のペースで話が進み、事実よりも過失があるように判断をされるので、起きたことをちゃんと報告し、それ以外は口にするなと言われてきました。 しかし、調べてみると「全く反省のない加害者」として、裁判まで発展したケースもあるようです。 個人としては謝らないのは気が収まらないので、「謝りすぎてはいけない」が答えだと思います。 迷惑をかけたこと以上には、申し訳ない気持ちにならないように気をつけようと思います。
まとめ
今回事故を起こしてしまって、「どうしたらいいかわからない」となった時は、知らない事は恐いことだということをリアルに感じました。 僕は自分に非がある時は相手の言うままにしがちなので、事故処理の調査をしたことで「被害者だけでなく自分の事も守るべき」という事を学べました。
以下は忘れないようにしたいと思います。 * 事故を起こした時は「安全確保・警察・保険会社」を最低限行うべきとして、事故処理のプロ達にアドバイスを求める。
軽微な事故で示談になっても、後のトラブルに繋がらないようにする。
事故の処理は「その場での解決」ができるように行動する。
JSTQB Foundation テストとは何か？
はじめに
備忘録的なもの
JSTQB Foundation の「テストとは何か？」について印象に残っている部分のメモ起こしです。
目次
テストとは何か？
ソフトウェアシステムは、様々な分野で使われています。ソフトウェアが期待通りに動作しないと、なんらかの不都合をユーザーと開発者に与えることがあります。
ここでいう不都合とは?
不都合は、大きく分けて4つあります。
- 経済的な損失
- 時間の浪費
- 信用の失墜
- 損害や死亡事故
経済的な損失
経済的な損失には、トラブルが発生したソフトウェアの修正や再テストにかかるコスト、クレーム受付などトラブル対応にかかるサポートのコストがあります。
時間の浪費
システムのトラブルによって起こるソフトウェアの修正作業は、本来別の開発に当てるはずだった開発者の時間を浪費させます。
信用の失墜
品質の低下は信用の失墜につながります。会社そのもののブランドイメージの低下になってしまいます。
損害や死亡事故
ソフトウェアの用途によっては、動作が正しくないと死亡事故にも繋がります。
不都合を起こさないためには
ソフトウェアが本番で使われる前に、期待通りの動作をするかを確認するソフテウェアテストをします。 動作しない場合に、その故障が発生しなくなるところまで見届けることで、本番で運用するときにソフトウェアの故障が発生する可能性を低くすることができます。
テストに共通する目的
テストで目的をはっきりさせることで、テストにかける工数や期間、テストを行うメンバーのスキル、開発担当者との関わり方など色々なことが変わってきます。 JSTQBに明記されている、共通して必要と思われるテストの目的は以下になります。
作業成果物の評価
作業成果物のレビューは、正しく書かれているかの確認以外にも、 「間違ってはいないが誤解を招きやすい記述がされていないか」 「構成に一貫性がなく非常に読みづらい」 といった他の観点でも見る必要があります。
要件を満たしていることの検証
どのテストレベルでも作業成果物が要件を満たしているか検証する必要があります。
妥当性の確認
受け入れテストでは、要件の検証だけでなく、それを使うユーザーが期待していると思われる動作内容を確認します。
品質レベルの確証
一部のテストの結果に合格しているだけでは不十分で、全テストレベルで計画したテストの結果や欠陥修正の結果を、マトリクスを使って確認します。
欠陥の作り込みの防止
過去に行ったテストにて検証した故障と修正した欠陥の原因分析を行い、その後の開発を行う際に分析結果を取り入れることで、同じ欠陥を作り込むことを防止します。
故障や欠陥の発見
より多くの故障や欠陥を発見して、ソフトウェアの欠陥を特定して修正します。
意思決定のための情報提供
テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることの確証を得ます。 欠陥の修正が完了しないままリリースをしなければいけない場合には、欠陥がどこまでのインパクトとなるか？、欠陥の回避策、ここまでを考慮して有用な情報となります。
ソフトウェアシステムが、契約上、法律上、または規則上の要件や標準に準拠していることの検証
ソフトウェアが使われる業界ごとに、要件や標準を遵守する必要があります。
テストとデバッグ
テストは、ソフトウェアに存在する欠陥に起因する故障を発見することを目的としています。 デバッグは故障の基になる欠陥を見つけて、原因を解析・修正を目的としています。
その後、テスト担当者がテストを行い、欠陥の修正で故障が解決したことを確認します。
テスト担当者はテストに責任を持ち、開発担当者はデバッグに責任を持つことになります。 ただし、役割が変わることもあります。アジャイル開発では、テスト担当者はアジャイルチームの一員となります。役割分担にとらわれずに、テスト設計をレビューしたり、デバッグのためにソースコードを調べたりすることもあります。
