today::エンジニアに憧れる非エンジニア

今のところは、エンジニアとは言えないところの職種です。しかしエンジニア的なものの考え方に興味津津。

【まとめ】#ssmjp 2019年05月…波田野裕一氏「運用自動化の基本原則 その2」

speakerdeck.com

「40分でスライド80枚(!)」という、壮大な発表でした。中身が大変に興味深い。

運用自動化の位置づけ

運用自動化というのは、戦略・作戦・戦術でいえば、戦術フェーズに属する事柄であると認識しています。事業継続性の向上という戦略方針、運用の構造化という作戦方針のもとに、運用自動化という戦術が適用されるわけなのです。

運用自動化の達成度を判断するための必要条件

波田野氏によれば、運用自動化の達成度を判断するための必要条件は以下であるそうです。

  • 事業継続性の向上に資すること
  • サービス価値の向上に資すること
  • デリバリ価値の向上に資すること

サービス価値というのは、運用の現場に携わる人が抱える問題の解決、というように読み取りました。具体的には、「オペレーションミスの削減」「工数の削減」「品質の平準化」といった内容のものです。

デリバリ価値というのは、サービス価値の向上度合いを定量的に評価し示せること、というふうに読み取りました。±3σ範囲・有意性・分散と標準偏差、こういったキーワードと関連性が深い分野です。

平易な業務とは

波田野氏によれば、平易な業務の定義は以下であるそうです。

  • 業務の成果を明確に示すことができる
  • 業務内容を精密に把握することができる
  • 例外の発生がほとんどない

製造業の工場における業務は、平易な業務が占める比率が高い業務分野です。だからこそ、業務における改善手法は製造業から発達してきたのだと思います。業務内容の精密な把握のための手法であるサーブリック分析とか。主に業務の成果を明確に示すための手法であるQC7つ道具とか。ITが絡む運用自動化でも、製造業に学ぶべき点はまだまだ多いのではないでしょうか。

※一方で、新QC7つ道具のほうは、平易な業務と複雑な業務の切り分けという別フェーズに有用な手法であると認識しています。

複雑な業務を自動化しようとしてはいけない

「複雑な業務を自動化しようとしてはいけない」というのは重要な指摘です。

複雑な業務の自動化は劇薬

複雑な業務を自動化すると、短期的には劇的な効果を得られるかもしれません。しかしながら、波田野氏によれば、以下のような理由により最終的には反作用のほうが大きくなるとのことです。

  • 仕様に不明確性が残る
  • 責務の境界が曖昧
    • モジュールの結合度は高くならざるを得ない
  • 保守が困難
    • 引き継ぎできない

特定の業務がサイロ化してしまい、同一企業内での断絶が深まる…そういう帰結が想像できます。

経営的観点から見た複雑な業務

というか、複雑で属人性を排除できない業務というのは、経営者が取り組むべきたくさんの仕事の源泉となると思います。

複雑な業務をより丁寧に紐解くことにより、自社のコアコンピタンスに気づくことができる可能性があります。不可能と思われるところまで運用を構造化して、なお自動化できない複雑な業務というのは、思考して結論を出すプロセスであることが多いです。特にコンサルタントのような無形商材を売るビジネスだと、そのような業務の比重は高くなるでしょう。思考に至るまでの前提となるスキルやノウハウが何なのか、どのような思考を経て業務を遂行するのか。まさしくコアコンピタンスというに値するものではないでしょうか。

複雑な業務を動かすのに必要欠くべからざるメンバーは、自社事業にとって必要欠くべからざるメンバーです。相応に高い報酬を以て応えるべきであり、そのために必要な人事制度を構築する必要があります。

考えつく経営的観点から言っても、複雑な業務は自動化の対象としてはいけないと思います。

平易化の原則とキャリアパス

エンジニアとしてのキャリアアップは、「いかにして複雑性が武器となる業務分野に入り込むか」というのが重要なのではないかと思います。大きな分野分けとしては技術・経営・法律。一口で技術と言っても、凄腕プログラマーという道もありますし、CTO(最高技術責任者)のような技術コンサルタントという道もあります。

逆に、複雑さが排除された分野における仕事というのは、遅かれ早かれ労働集約的な仕事に収斂されていくのではないでしょうか。時間をお金に換える類の仕事です。そうなると、最終的に行き着く先は、学生アルバイトや主婦パート並みの低賃金労働である、そんな気がします。