手順書にまつわる失敗と、どういう改善を考えたか

1.9K Views

March 14, 22

スライド概要

手順書Night 第一回の資料

関連スライド

各ページのテキスト
1.

手順書にまつわる失敗と、 どういう改善を考えたか #手順書Night 第1回(2022/3/10) # 株式会社エーピーコミュニケーションズ ACS事業部 # 東出恵次

2.

はじめに 2

3.

自己紹介 東出 恵次(ひがしで けいじ) ・商社系SIer→通販事業会社→現職(APC)。 ・PMやりつつ開発・インフラ構築・保守運用までやるなんでも屋。 ・現職ではクラウドネイティブ内製化支援のコンサル・設計支援などに従事。 ・スパイス&ハーブ検定2級保持。 ・Twitter:@___KG__ (前:_×3つ/後:_×2つ) (技術的なことはあまりつぶやいていません)(最近はIT大喜利と子育てネタが多め) 3

4.

弊事業部のサービス ホワイトペーパー(Github) サービスのページ 4

5.

今日のお話 5

6.

最近起きたトラブルを例に、、、 京都大学のスパコンデータ消失事件 問題点 改善策? 作業担当者がbashの挙動を認識して なかった? 作業者の認識に依存しない仕組みが 必要 一人で作業してたこと(チェッカー 不在) 作業は二人で実施しよう(言わずも がな) 京大側の確認(監督)が不十分(体 制とか手順) 監督側で体制や手順の妥当性を確認 する仕組みが必要 6

7.

今日お話すること 手順書を有効に機能させるには、事前準備とか作業環境も大事(だと思っている) ⇒自身の経験を元にお話したいと思います 事前準備 - イレギュラー時の対処準備 - リハーサル等による事前確認 - 有識者によるレビュー 作業がうまくいく 手順書 適切な作業環境 - 作業体制(必ず2人でおこなうとか) - 体調をととのえる 7

8.

今日お話すること(補足) ● 扱う題材について ○ ○ ○ SI現場でのリリース作業など、ワンショットの作業が主です 私が過去の所属企業でしくじった経験を紹介します(一次請けの作業責任者と して、失敗した経験です) 現場で起こったトラブルネタなので、一部脚色を入れています 8

9.

失敗事例①:データ移行でのトラブル 9

10.

シチュエーション 諸般の事情により、データベースを片寄せ移行することに CRMシステム A社用 B社用 テナントを分けていたが、片寄す ることに 10

11.

起こったトラブル 作業遅延→統計情報の取得中に開局→パフォーマンストラブル発生 CRMシステム 顧客情報参照時のパフォーマンス が大幅劣化(3秒→1分とか) A社用 B社用のデータを移行後、DBの統計 情報を取り直した B社用 統計情報の再取得が開局時間に間に合わず、業務優先で開局。 ↓ 統計情報が不十分な状態で顧客情報を参照 ↓ 高コストな実行計画になってパフォーマンストラブルになった 11

12.

改善策 ● 作業途中にチェックポイントを設け、イレギュラー時の対処・判断 フローを事前に明確化するようにした 要因 改善策 効果 統計情報が不完全な状態で開局することの 影響について、その場で十分な検討が できなかった(焦り/夜間作業による疲労 から判断力が低下) ・作業途中にチェックポイントを設けて、 イレギュラー時の対処・判断フローを事前 に明確化するようにした 事前に切り戻しポイントと判断基準を設定 ↓ 実際に作業途中でトラブルが発生→切り戻 しポイントまで解消したかった ↓ 切り戻しの合意形成がスムーズにでき、即 座に切り戻し実施できた(本番業務への影 響はなし) ・且つ、上の考え方を社内関係者・エンド ユーザーと共有する 12

13.

失敗事例②:架電テスト時のトラブル 13

14.

シチュエーション 業務システム側の機能改修にともない、お客様環境で架電テストを実施 (夜中に) 電話網 電話システム (PBX/CTI) 業務システム 架電リスト 架電リスト テスト架電先 電話システム(CTI)のDBに リスト登録 ↓ 電話番号をテスト用に変更 本物の顧客の電話番号が含ま れる 手順書に基づき手作業で実施 (作業者とレビュアーのペアで) 14

15.

起こったトラブル 電話番号をテスト用に変更する手順を飛ばして、本物の顧客に架電して しまった(しかも夜中に) 電話網 電話システム (PBX/CTI) 業務システム レビュアーも作業し始め る(進捗遅れてて、巻き 返すために) 本物の顧客に架電 してしまう 架電リスト 電話システム(CTI)のDBに リスト登録 ↓ 電話番号をテスト用に変更 架電リスト 本物の顧客の電話番号が含ま れる 一人で作業実施&眠たい ↓ 作業手順飛ばす この手順飛ばした 15

16.

改善策 ヨシッ! ● 必ず二人で作業する ● (少なくとも)危ない作業をする際には必ず指差呼称でチェック 要因 改善策 効果 ・そもそも一人で作業をさせてしまったの がNG ・必ず二人で作業する ・同様のテストを以降、何度も実施するも 同様のトラブルは発生せず ・夜中で眠たいので集中力が低下していた ・少なくとも危ない作業をする際には、必 ず手順やチェック結果を指差呼称で確認す る(※) ・他の作業でも同要因のトラブル発生は発 生せず ※声に出すことで緊張感・集中力を高める効果を狙う 参考:厚生労働省 安全衛生キーワード 指差呼称 16

17.

失敗事例③:ソフトウェアアップグレード時のトラブル 17

18.

シチュエーション とあるシステムのアップグレードを実施(不具合解消を目的として) お客様 不具合多くておこ 私が当時 いた会社 不具合多くておこ システム 納入元 ソフトウェアのアップグレードを提案 メーカー 18

19.

起こったトラブル アップグレードがうまくいかない×2回(3回目で成功) 1回目 ・(ワイ)手順書どおりで大丈夫? ・(納入元)大丈夫やで! ⇒失敗 2回目 ・(ワイ)1回目の原因以外も大丈夫? ・(納入元)大丈夫やで! ⇒失敗 ・手順書の妥当性を私 が判断できず ・リハしてなかった ・・・次はあんじょう頼むで お客様 ・手順書の妥当性を私 が判断できず ・リハしてなかった ええかげんにせぇよ(# ゚Д゚) お客様 3回目 ・(ワイ)本番機の設定使ってテストして! ・(納入元)やったで! ・(ワイ)(エビデンスチェックして)大丈夫やな! ⇒成功(とはいえ、、、) 本番環境の設定で実機 テスト・リハ実施 ようやっとやな、ご苦労さん! (せやけど品質悪いな、、、) お客様 19

20.

改善策 ● 詳しくないシステムに関する、手順の妥当性検証プロセスを定義 ● 極力リハーサルの実施をする/求めるようにした 要因 改善策 効果 ・自身が詳しいシステムではないので、手 順の妥当性について踏み込んだ指摘ができ なかった ・手順をチェックする際の観点において、 有識者不在の場合における確認方法を決め た ・手順の妥当性がきちんとしている作業に おいては、作業完遂に影響するようなトラ ブルは起こさなくなった - 妥当性の根拠や検証手順を確認するようにした ・「踏み込んだ指摘ができない」ことは認 識していたものの、その点について対策を 打たなかった ・根拠等に疑念がある場合にはリハーサル の実施をおこなう(依頼する)ようにした - それにかかる追加コストは事前に考慮しておく ・予めリハーサルの依頼をすることで、 (依頼先側の)作業計画も立てやすくなる ので、モメなくなった 20

21.

今日お話すること(再掲) 手順書を有効に機能させるには、事前準備とか作業環境も大事(だと思っている) 事前準備 - イレギュラー時の対処準備 - リハーサル等による事前確認 - 有識者によるレビュー 作業がうまくいく 手順書 適切な作業環境 - 作業体制(必ず2人でおこなうとか) - 体調をととのえる 21

22.

質疑応答 22

23.

ご清聴、誠にありがとうございました 23