運用組織のTo-BeとAs-Is
To-Be
- 経営陣が運用概要を設計する
- 現場が部分最適・付加価値部分を設計する
As-Is
- 経営層の現場へのアプローチがない
- 現場は個別で最適化しようとする
引き継ぎについて
- 若い人が運用設計や実装に関わるのは重要
- 引き継げない運用自動化は、一生抱えるくらいの覚悟が必要になる
「あえて引き継げないものを作って、自分が一生食うに困らない仕事を作る」という生存戦略もあるっちゃあります。しかしながら、そういう利権的現場（後述）を作る生存戦略は実に昭和的であり、不安定・不明確・複雑・不確実を旨とする今の時代に通用するものではありません。引き継げるものを作り、後進に未来を託す…運用自動化にもそのくらいのビジョンが必要なのではないでしょうか。
運用業務の言語化
全て、とはいうものの
四角四面に全ての業務を言語化することはできません。なぜなら…
人間は時として、言語化できないor言語化が極めて困難なほど複雑な行動を無意識レベルでやってしまう生き物です。しかし、人間は有限の時間しか生きられません。有限の時間にできることは有限です。本当に全てを言語化しようとすると、時間がいくらあっても足りないのです。
というわけで、波田野氏は「言語化する業務の範囲」として、以下の前提条件を定義しています。
- 言語化できる業務であること
- 論理的な説明が可能な業務であること
言語化されていない運用業務
言語化されていない運用業務の現場では、往々にして以下のような事態が発生するものです。
- 現場が何をすべきかわからない
- 経営陣は現場が何をしているかわからない
- 共通認識がない、論理的整合性もない
現場サイドとしても、「自分が何をやっているかわからない、何をやっているか言葉で説明できない」というのは、画一的働き方が風化真っ只中にある現在において非常にまずいことではないかと思います。言葉で説明できない仕事は職務経歴書に書けないですし、職務経歴書に書けない仕事は外部労働市場で評価されません。そんな仕事に従事して時間が過ぎてゆくと、現場従業員のエンプロイアビリティ（雇用されうる能力）を損ねてしまいます。
運用業務の言語化に必要なこと
- 運用業務の範囲を明確にする
- 言語化対象の業務を明確にする
- コンテキストを揃える
以上が波田野氏の主張でした。
「運用業務の範囲」や「言語化対象の業務」というのは、前回ssmjpの波田野氏発表（当Blogにおける感想記事）で言及されていた「公式性（客観的な依頼要件・提供成果が明示されていること）を持つ運用サービス」と重なる話です。特に「サービスカタログ（ITmediaエンタープライズ 情報マネジメント用語辞典における当該用語の解説）に入っているものが、言語化の最大範囲である」という主張に力点が置かれていました。
「コンテキストを揃える」というのを実現するためには、後述する「平易さの定義」が重要になってきます。
平易とは
平易の基準
波田野氏は、「一口に「平易さ」と言っても、そのレベルとして考えられるものは複数ある」とおっしゃっていました。例えば以下のような感じです。
- 情報工学の博士レベルの「平易」
- ハイレベルエンジニアレベルの「平易」
- 高度情報処理技術者よりさらに高い知識レベルを問われる上位ベンダー資格を取得するクラスのエンジニア
- ミドルレベルエンジニアレベルの「平易」
- 高度区分の情報処理技術者試験に合格するクラスのエンジニア
- ジュニアレベルエンジニアレベルの「平易」
- 応用情報技術者試験に合格するクラスのエンジニア
- アルバイトレベルの「平易」
学術の世界においても、「同ジャンルの専門研究者が読むことを前提とした査読付き学術雑誌」と「一般向け学術書」では、読者の知識レベルとしてどれくらいを想定するかは大きく違ってきます。「自分の知見を共有し、新たな研究に使ってもらうこと」や「一緒に仕事を進めていくこと」を見据えた言語化の場合、相応に高度な前提知識を要件とすることには確かに合理性があると思います。
アルバイトレベルの「平易」を考えてしまう、それゆえの問題
日本の運用現場においては「アルバイトレベルの「平易」を要求されることが多い」「「誰でもできること」が重視されがちである」…波田野氏もそのような趣旨の指摘をしていたことを記憶しています。また、日本マイクロソフトの西脇資哲氏は、「（中国大陸などと比べて）日本社会は、ITリテラシーが低い人に優しすぎる」という発言をしておりました（7月13日「夢ある未来の描き方Ⅱ」発表にて）。実際、「仕事ごっこ」なるものが社会問題化する背景には、この「「誰でもできること」が重視されすぎる」という問題があるように思います。
- 作者: 沢渡あまね
- 出版社/メーカー: 技術評論社
- 発売日: 2019/07/06
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
知識集約型事業を前提とするならば、波田野氏がおっしゃっていた「アルバイトレベルの「平易」を考えてしまうと、無限の工数がかかる上に低品質なものになりがち」というのは私も同意です（そういえば、前回ssmjpにおけるちゃんほ氏の発表もそうした現場がテーマの発表でした。）。逆に、「アルバイトレベルの「平易」を実現する必要がある産業は、それ自体が労働集約的事業である」というのも言えるのではないでしょうか。ちょっと暴論っぽくなってしまうかもしれませんが、「アルバイトレベルの「平易」を求めていることを公言した時点で、その事業者は自らが労働集約的ビジネスモデルであると宣言しているようなものだ」とも言えるのではないでしょうか。
コンテキストを揃えるために大事なこと
- 「平易さ」の基準はTo-Beに置く
- コンテキストを揃える過程で、並行して学習を進め、現場の「平易さ」の基準をTo-Beに引き上げる
波田野氏は上述の趣旨のことをおっしゃっていました。
エンジニアは専門職。「誰でもできる」というのは捨てよ。現場の「平易さ」はミドルレベルを基準とし、足りない部分は学習で補う、それがあるべき姿、実現すべき姿。…特に仕事が楽しくて仕方がないような人においては、これらの熱い主張に共感できる人は多いのではないでしょうか。私も斯様な現場で働きたいものです。この項の最後に一言。
エンジニアよ、自らの仕事が知識集約なものであることに誇りを持て。
ドキュメントの構造化
ドキュメントの構造化について、波田野氏は「ドキュメントの構造化を行う場合、外部のドキュメントをincludeする仕組みが実装されていることは必要条件である」という趣旨のことをおっしゃっていました。この主張には、おそらく「ドキュメンテーションにもDRY原則が適用されるべきである」といった考え方が根底にあるのだと思います（私もこの考え方には同意ですし、実現していきたいと思っています）。良い設計において仕様変更の影響は局所化されているものであり、仕様変更を局所化するための方法論として「外部のドキュメントをincludeする仕組み」というのは有用性が高いのです。
波田野氏の主張は、さらに「ゆえに、外部のドキュメントをincludeする仕組みが実装されておらず、一つの文書で閉じてしまうMarkdownはオワコン。時代はreStructuredTextとSphinxである。Sphinxもっと流行れ。」という風に続きます。この文脈におけるreStructuredTextというのは、「外部のドキュメントをincludeする仕組み」を実現する具体的技術の一つです。reStructuredTextの類似技術としては、AsciiDocやRe:VIEWが挙げられます。いずれも外部のドキュメントをincludeする仕組みが実装された軽量マークアップ技術です。これら各々の違いは、いったい何なのでしょうか。興味があります。
- reStructuredText入門
- Asciidoctor 文法クイックリファレンス(日本語訳)
- 書籍制作を支援するソフトウェア「Re:VIEW」を使う - Ubuntu Weekly Recipe - gihyo.jp
利権的な現場とその弊害
- 運用に依頼できることを知っている人は依頼できるけど、知らない人は依頼できない
- 予算を持っている人、声が大きい人が通りやすい
- 頼める人、頼めない人がいる
こうした状況にある現場を、波田野氏は「利権的」と形容しています。利権的な現場においては、既得権側にいれば居心地がいい一方、アウトサイダーは居心地がいいと思えません。
不安定・不明確・複雑・不確実を旨とし、社会に自らの存在価値を求める向きがメインストリームとなっているのが今の時代です。そんな時代における利権的な現場というのは、将来を担う年齢層の働き手からは敬遠され、時として糾弾される（SNSで晒し上げとか）ものであると言えます。
