曖昧さ耐性と役割
曖昧さ耐性とは、心理学で「曖昧な状況をどのぐらいそのまま受け入れることができるか？」と定義されています。
運用設計や改善という活動において、この「曖昧さ耐性」が意外と重要になってくるのでそのあたりをまとめてみたいと思います。
曖昧さとは
株式会社ビジネスリサーチラボ 代表の伊達さんが、コラムの中で曖昧さには2つの要素があると定義しています。
一つは、多義的であること。一つの情報が複数の意味を持つのが多義性の意味するところです。もう一つは、情報が不足していることです。
運用設計を行う上でも、この２つの曖昧さはよく出てきます。
多義的であることは、依頼が抽象的であると言い換えることができます。
お客さんから「効率よく運用がしたい」と言われたとき、「効率よく」という言葉に含まれている意味は多くあるので、お客さんがイメージをすり合わせていく必要があります。
情報が不足している場合は、ドキュメンテーションがされておらず業務が属人化していたりブラックボックス化していることが想定されます。
「既存運用を踏襲したい」と言われても、既存運用資料が無かったり、現場のメンバーしかわからなかったりということがあります。
この場合の曖昧さは、根気よく情報収集して情報を集めていくしかありません。
どちらの曖昧さででも、すぐに回答が提示されてスッキリ解決するということはあまり多くありません。
特にプロジェクト対応では多義的な曖昧さで情報が揃わないことが多く、ある程度プロジェクトが進むまで誰も正しい判断ができないことが多くあります。
それまではどれだけ話し合いをしても抽象的な議論に終始します。
運用設計中でも「曖昧な状態に耐える時間」ということが多くあります。
オペレータから運用設計にキャリアアップした際、曖昧な状態に耐えきれずに心を病んでいく方を少なからず見てきました。
オペレーターから設計者へのキャリアアップで重要なこと
設計を一言でまとめると、抽象的な事柄を具体化していくことです。
システムの利用ケースからユーザーが記入する申請書を作成する。
サービスレベルと監視したい内容から監視項目を決めていく。
障害が発生した際のエスカレーションフローと連絡先をまとめていく。
私もオペレータとしてのキャリアが長かったので、はじめはこれが苦手でした。
オペレータは「決められたことをミスなくこなす」というのがもっとも重要な仕事になります。
何か不測の事態が起こったときでも、「手順書に書いてないことは実施しない」という判断が評価されます。
そして管理者に「今回おこった事象が記載していなかったから、検討して記載してほしい」とクレームまじりの改善依頼を出すことになります。
極端な現場だと、それによってシステムが止まったとしても手順書遵守です。
さすがにそうなると、オペレータとしては間違っていなくてもビジネス継続としてはたまったもんじゃありません。
このオペレータとしての経験が積み重なると「誰かが答えを持っていて、言われた通りにやることが正義」という認識が強化されていきます。
一度この感覚が染みついてしまうと、自分で主体的に設計はできなくなります。
曖昧であることに対する拒否反応が強くなりすぎるのです。
個人的には、これがオペレータから設計者へのキャリアチェンジを妨げている最大の原因かと考えています。
この認識を変えるためには、学習ではなくOJTによる認識の上書きが重要です。
「自分で決めても良い」「どんどん提案しないとお客さんが決めてくれない」「確実性よりも早さが重要な場面が多い」などということを一つずつ認識していけば、いずれオペレータ感覚から脱することができます。
ただ、オペレータが長ければ長いほど、認識の上書きは自己否定に近い形を取ります。
もはや生まれ変わりに近い時もあります。
そのため、本人に主体的な変化の許容がないとメンタルにダメージを食らう可能性があるので注意してください。
とはいえ、まずは知識として運用設計を知りたいという方！
実践形式でシステム運用設計を学べる研修を企業向けに販売しておりますので、ご興味のある方はご連絡ください！
システム運用に関連する書籍も出しています。
この記事が気に入ったらサポートをしてみませんか？