ゼロにはできない運用現場の作業ミス。起きるたびに復旧作業・お客様をはじめとしたステークホルダーへの説明と謝罪・再発防止の策定に莫大な時間を費やし、本質的に効果が期待できないダブルチェックと手順書が積み重なる一方、ステークホルダーの信頼はますます減っていきます。
作業ミスが発生した真因を紐解くと、「入力ミスや手順を飛ばしてしまった」「確認作業やテストが漏れていた」「作業の基になる設計書と実際の環境の設定が異なっていた」「作業中に他の対応が割り込んでしまった」など原因はさまざまです。
このような運用現場の「作業ミスの負の連鎖」から脱却するためには、どのようなことから手をつけていけば良いかを解説します!
ご参加いただき/ご興味を持っていただき、ありがとうございました。
いただいたご意見・ご質問をもとに少し補足します。
作業の正確性や危険察知・回避能力が高いベテランメンバーは全方位に頼られます。レビューやダブルチェックを行い、品質保証の最後の砦としての役割も期待されます。
ところが品質保証の最後の砦であったはずが、やがて品質保証の最初の関門にもなり、すべてを担うことがよくあります。こうしてベテランメンバーしかよく知らないことが増えて、またベテランメンバーだけに頼るようになります。
全体最適の視点ではベテランの能力発揮は、ベテランだからこそ成せること、高難度・高リスク領域や、ベテランに至る育成にあてたいところです。
レビューやダブルチェックという行為そのものは品質保証に価値がありますが、なんでもかんでもレビューやダブルチェックでカバーしようとすると不確実だったり過負荷になります。
このとき”やりかたそのままで人間をソフトウェアで置き換える”あるいは”ソフトウェアのやり方に一気に全部変える”といった極端な方法をとると達成が難しくなります。平成の前半に流行した、紙の書類・書式をそのまま電子化したような仕組みがいかに不便かはみなさんのよく知るところです。最適なゴールは目指しつつ、身の丈に合った範囲で段階的に形を変えていかなくてはなりません。
ソフトウェア開発においては静的解析や自動テストがこの実現を支えています。運用においても同様の取り組みを実現していくと、それだけ実のあるレビューやダブルチェックが増え、全体的に健全化していきます。
育成のほうもソフトウェア開発の取り組みが参考になります。ペアプログラミングや実のあるレビューを通じてコンテキストや文化を継承・醸成してきます。
その時々のチームや事業の状況によって適切な手法やツールは変わります。変わるのは当然なので、そういうものと割り切って変わっていきましょう。ただ”プラットフォームを定める”ことは忘れないでください。
セミナーでは、とにかく少しずつ実践的な改善を小さく積み重ねる話をしました。するとかつてのEnd User Computingのように結局実装が乱立して、のちのち酷いことになるのでは?という心配があります。
その心配はごもっともで、それを防ぐ・管理する目的のプラクティスもあります。となると、それらをあらかじめケアした、ある意味 “正しい” あるいは “より良い” 姿を前提にしたくなります。プラットフォームを構築し、ルールとガイドラインを整備したうえで始めましょう、自動化する対象を定めて場合によっては業務を棚卸しして改めて設計して…となりがちです。
しかしこのとき忘れないでほしいのは “始めないと0は0のまま” ということです。始めないと何も良くなっていないし学びもなく、ずっと0点です。そして0点のまま終わることが往々にしてあります。
とにかくまずは、プログラムを、価値観を、改善活動を少しでも動かすことをお勧めします。
組織内の人員で初動やコツコツ定着させる活動がうまくいかない場合はわたしたちのような外部メンバー(有識者+エンジニア)を頼るのもよい方法です。
無料相談会を実施していますので、下記フォームからご連絡いただき、ぜひ現場の声を聞かせてください。