概要
8月6日、DMM.comにて開催された「#ssmjp 2019/08 運用パネルディスカッション〜こうやって続けよう運用自動化〜」の感想等まとめです。
運用自動化を成功に近づけるには
まずは現場や所属部署といったマターの話です。
事業者内観点で見て「運用自動化の成功」というのは、以下の要件を満たしていることであろうと考えています。
- 自社事業にとって、対外的に発表できる・定量的に評価できる形で成果が出ていること
- 現場が納得感を持って運用自動化を継続できていること
- 引き継ぎが可能であること、少なくとも引き継ぎが可能である見通しがついていること
上述のような成功を手に入れるには何が必要か。特に運用現場部署観点で言えば、以下のような事柄が該当しそうです。
- 現場が納得感を持って運用自動化を継続できていること
- 現場の長（現場にとっての直属上司）が納得感を持って運用自動化を継続できていること
「運用自動化を成功に近づけるには」の以降の項目では、上述のテーマについて説明していきます。
現場の納得感の重要性
現場は不条理を感じずに運用自動化を継続できそうか？
以下のような状態にある運用自動化は、現場が不条理を強く感じるでしょう。
- そもそも組織の見栄や体面が運用自動化の根本動機となっている
- 自動化すべき部分が自動化されず、自動化すべきでない部分が自動化されてしまった
- 本質的に複雑な業務が自動化されてしまった
- 逆に本質的に平易な業務が自動化されていない
- 忖度に該当する部分を人力運用させている
- 情報システムに忖度は実装できない
- 技術的に無理を強いるものである
- Web GUIをブラウザ操作自動化アプリケーションで叩かせるような運用自動化は健全ではない
- 必要な情報が開示されない
- インターフェースやAPIの仕様がきちんと開示されていることは重要
現場に不条理を強いる形での運用自動化は、いずれ必ず破綻するのは想像に難くありません。しかもその破綻は、往々にして大規模かつ深刻な形で表面化するものです。
特にミレニアル世代の事業メンバーは、「自分の仕事に対し、自分が納得できる理由や社会的意義を求める」という向きが強く、頭ごなしにやらされることに対して不条理を感じやすい傾向があるとされています。現場に不条理を強いるような仕事をさせ続けていると、「どこかのタイミングで彼らの不満が爆発し、雪崩を打つように大量離職。人員不足で事業そのものの継続が危機的な事態に。」というシナリオに至るリスクも十分にあります。
また、「継続できる」というのも重要なキーワードです。なぜなら、運用自動化というのは、一度導入すればそれで終わりというものではないからです。業務環境の変化に合わせたアップデート、さらに大きな成果を実現するためのアップグレード。これらは継続的に実現していく必要があります。
現場のメンバーが入れ替わったとしても運用自動化を継続できそうか？
「とりあえず正しく動いている。けれど、どのような理屈で動いているかはわからない。どのような理屈で動いているかわからないので、中身に手を付けることもできない。」というのは、運用自動化の典型的なアンチパターンの一つです1。
こうした運用自動化アンチパターンを回避し、現場のメンバーが入れ替わったとしても継続できる、少なくとも継続できそうな見通しが立てられる運用自動化を実現するためには、以下のような事柄が重要であろうと考えています。
- 運用自動化を直接立案したメンバーの目的意識が、後継者に伝えられる形で文書化されていること
- なぜ運用自動化をするのか
- 運用自動化が動き出した時点で何が問題だったのか
- 運用自動化によって何を実現したいのか
- 迷ったときに立ち返るべき原則2
- その自動化要素がどのような構成になっているのかが文書化3されていること
- どのような入力が想定されているか、想定されていないか
- どのようなロジックで動いているのか
- どのような出力が得られるのか
以前の波田野氏の言及にあった「アルバイトレベルの平易化を求めると、運用自動化の現場が死ぬ」というのは、「その自動化要素がどのような構成になっているのかを文書化する」という観点で言って、確かにそのとおりだと思います。「ITリテラシーや論理的思考能力のレベルが想定できない層に対し、情報システムの構成について説明する」というのは、それだけで月単位とか年単位とかのカリキュラムを組むことが求められるレベルの内容でしょう。
直属上司の納得感の重要性
なんだかんだ言って、課長部長といった直属上司の納得感は重要です。多くの場合、現場の問題意識に対して決定を下して経営層に説明できるのは直属上司ですし、実際に施策を進めていく上で必要な決裁権を持っているのも直属上司です4。
経営層への説明や、決裁権の行使。それらを直属上司の仕事と考えると、直属上司が納得しやすいであろう説明は以下のような事柄が含まれている必要があります。
- 現場の現実を伝えること
- モデルや数値により客観化すること
- 結局どうなるのか（良くなるのか悪くなるのか）
これらの事柄は、現場が上司になすべきことの第一ではないでしょうか。
また、「上司の能力を固定的なものと考えてはいけない」というのも重要です。私から見ると、波田野氏の発表にあった「繰り返し説得して、上司に進化してもらう」というのは、その点についての言及が大いに含まれていると思いました。私自身が苦手意識を持ちやすいテーマなので、その印象は強いです。
運用自動化の現実を理想に近づけるには
顧客を巻き込むための方法論
自社事業に対して対価を払い、利益の源泉となるのは、なんだかんだ言って顧客です。経営者といえど、合理的理由なく顧客の意向を無下にするのは得策とはいえないでしょう。というわけで、
- ユーザの課題に敏感であることが大事
- ユーザの生の声を聞くことも大事
とはいえ、ユーザの生の声というのは、とかく「今あるものを、より便利に、より安く」というものに偏りがちです。「今あるものを、より便利に、より安く」を追い求め続けてしまうと、「際限なき値下げ競争と、当たり前となってしまった値段不相応の過剰サービス。結果として現場が疲弊する。」という結末になってしまいかねません。少なくとも現場にとっては不幸な結末でしょう。波田野氏がおっしゃっていた「ユーザの課題や生の声を取捨選択（採用する・しない）することも大事」というのは、そうした不幸な結末を避けるためにも必要なことであろうと思います。
経営者を巻き込むための方法論
「ユーザを現場の味方に引き込んでしまえば、経営層も自ずから巻き込むことができる」というのが波田野氏の基本認識のようでした。「お金を払ってくれる人がいないと、事業活動は継続できない」というのがその理由です。「ユーザを現場の味方に引き込むには」というのは、前述「顧客を巻き込むための方法論」の話になってきます。
経営者を巻き込みきれなかったゆえに起こった「重大インシデント」
www.slideshare.net
後藤芳和氏の発表資料です。元々はJANOG44の発表資料であったそうです。「外に影響が及ぶような損害の発生に至らなかった」という意味で「重大インシデント」という説明にしてみました。
何が重大インシデントだったかといいますと、「運用自動化を行った結果、人員削減された」というものでした。
人を減らされると何が起こるか
- 運用がきちんと回らなくなるリスクが高くなる
- 運用の属人化が進んでしまう
「容易に人を減らされるように見えるところから人を減らす」というのは、バブル崩壊以降の日本企業のあるあるとして、ニュースでもよく取り沙汰される話ですよね。確かに「バブル崩壊以降に競争環境が大きく変化し、人員削減5に手を付けなければならなくなった」とかそういう事情はわかります。しかしながら、事業の実態を直視して運用を構造化することなく「見かけ上容易に人を減らせるところから人を減らす」ということをやってしまうと、上述箇条書きのような問題が出てきてしまいます。そして、現場主導で始める運用構造化というのは、全社的なワークフローの見直しが可能な権限を持つ経営層に知られず、結果全社的なワークフローの見直しまで手が届かないのが常なのですよね。結果、全社的なワークフローの見直しが可能な権限を持つ経営層には運用自動化の表面しか見えず、見かけ上工数が削減されたから人員削減に至った…そういう感じでしょうか。
問題はわかった、では根本問題は何だ。そして対策は何だ
後藤氏がたどり着いた根本問題としては、「運用自動化の範囲が特定のグループに閉じていて、経営層にまで問題意識・目的意識が伝わっていなかった」ということであるということでした。最終的な解決の姿としては、「経営層が有する問題意識・目的意識のもとに、トップダウンで全社的に運用自動化を展開していく。そういう姿を実現する」というように設定されました。
上述の最終的な解決の姿を実現するにはどうするか。「ある範囲で運用自動化が実現したら、その範囲を上にも左右にも拡大していく」というのが、後藤氏の解でした。具体的には以下の2点です。
- 運用自動化の効果を知ってもらうために、その前後を計測する
- 社内勉強会や、社内ワーキンググループなどを立ち上げて、運用自動化の真実を知ってもらう
前者は、主に上（上司や経営層）に範囲を拡大していくための方法論です。前述波田野氏の発表でも、「直属上司が納得しやすいであろう説明は、モデルや数値により客観化されたものである必要がある」という趣旨の主張がなされていましたね。「運用自動化の範囲を上に向かって拡大するためには、その効果が明確かつ客観的に説明できることが必要である」というのは、運用自動化の現場に身を置く少なからぬ人たちに共有されている認識であるようです。
後者は、上と左右（開発部門や他部署）どちらにも適用される方法論です。後藤氏によれば、「特に開発部門は、運用自動化で何か不具合等あった場合におけるエスカレーション先であり、運用自動化の現場で何が起こっているのかを知ってもらうのは重要である」とのことでした。また、後藤氏は「上司や経営層に運用自動化の真実を知ってもらうことは、運用自動化が単なる工数削減ではないことを知ってもらうために重要である」ともおっしゃっていました。「運用自動化が単なる工数削減ではない」というのは、「運用自動化と人員削減は、つなげていいものでは決してない」ということを知ってもらうために、確かに非常に重要なのではないでしょうか。
最後に言いたかったこと
本来は、運用工数が増えても、それ以上に提供価値が増えていればそれでいいはずなのです。…ということでした。
運用自動化の盛大な失敗例…「ザ・大企業の闇」
発表終了後、質疑応答形式での参加者事例共有パート出でてきた事例です。大雑把な筋としては、「障害対応の自動化、ならびにルータ設定の自動化。結果としては失敗した。メンテナンスできる人がいなくなったから。」というものでした。
使われていた技術として挙げられていたのが以下。
なんということでしょう。クライアント側で全てを走らせようとしているではないですか。「VBAマクロで情報システムらしきものを走らせる」のと何ら変わらないですよねこれ…冪等性も何もあったものじゃないですし、エラーを自動報告・自己訂正できる仕組みもありゃしない。
話を聞いていると、どうやら #仕事ごっこ 案件の結果生まれた怪物だったようです。「社内政治」やら「付き合いによる転籍人材の受け入れ」やら「事例づくりそのものが目的である」やら…STOP #仕事ごっこ 。
-
多分「Excel VBAを基幹技術として構築した、個人ないしは部署内でのみ使われる情報システム」の時代から存在するアンチパターンだと思います。↩
-
ある程度の技術レベルを前提とした平易化を想定する場合、「ソースコードとテストケース」そのものを引き継ぎ文書としてもいいのかもしれません。↩
-
情報化時代以前からの歴史のある一般的な日本企業の場合、「まずメンバーの直上に課長がいて、課長の上に部長がいて、部長あたりから決裁権限を持つようになる」という構造になっていることが多いです。指揮命令系統すっ飛ばしていきなり経営層に話を振るのは、一般に越権行為として許されない傾向が強いです。↩
-
削減対象として想定されるのは、往々にして「年功序列的な人事考課体系のもとで量産された、管理職である必然性のない管理職」であるものです。↩
