運用系ゆるゆる勉強会という名のよろず知見共有会、それが #ssmjp です。前回の岡島さん回とかまさにそうでしたよね。しかしながら、今回は波田野さん回ということもあって、ガチの運用構造化回です。
構造化なき運用自動化の問題
- 運用が状態を持ってしまう
- モジュールが密に結合してしまう
- 結果、バグの温床になるし、逆に工数が増加する結末になってしまう
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴くやオブジェクトの状態は作らない - 技術をかじる猫というブログ記事があります。構造なき運用自動化というのは、状態管理用の変数をインスタンスに持ちまくることになるのが不可避である…そう思うのです。その弊害については、以上で挙げた記事にかかれている通りです。網羅的にテストできないからバグの温床になる。動かしてみないと何が起こるかわからない。自動化したはずが却って人手がかかるようになった。…考えただけで悲しくなってきます。
運用自動化は、何でなければならないか
運用自動化は、その設計および実装内容を、設計・実装者以外に引き継ぐことを前提に行わなければなりません。そうでなければ、最終的に誰も中身がわからなくなって債務化するということになるでしょう。10年ほど前に問題になった、VBAマクロに起因するExcelレガシーと同根の問題です。こうした問題への言及としては、”Excelレガシー”は真の問題なのか？(1) - 神奈河、神名川、上無川 。あたりのブログ記事の記述が参考になります。
運用自動化は、論理的なものでなければなりません。忖度が入り込んではならず、論理矛盾が存在してもいけません。しかしながら、日本には「ITは忖度してくれる夢の技術」というような間違った認識が横行している、そのことを波田野さんも問題視しているようでした。仕事ごっこの世界…
論理的正しさとは
- As-Isが明確に数値で定義されていなければならない
- To-Beが明確に数値で定義されていなければならない
- 改善度合いも明確に数値で評価できる指標が存在しなければならない
特にAs-Isの数値による定義がおざなりにされるイメージが強いです。現状認識ってパンドラの箱ですし、相当な危機感がなければ忖度働きまくるものになりがちですし…
論理的正しさによって実現できること
論理的に正しい、という世界では、以下のようなTo-Beが実現できます。見れば見るたび、日本のIT、ひいては日本の会社（あるいは、しばしばカタカナ表記のカイシャとして言及される概念）が苦手とする分野なんですよね…
- 高度な反復性、再現性
- 安定性、合理性に価値がある
- 定量評価による合理性を前提に話をする風土
曖昧さや矛盾を排除すること。論理的に正しいドキュメントで客観化できること。そういったことは、論理能力の大前提となります。そう考えると、運用業務を本気で行うには相応に高い教養を有することが求められてきそうです。しかしながら、人月商売前提の職場だと、それだけ高い教養を有する人が寄り付かない気がします。
IT技術は、物理制約の影響が少ない世界です。働き方の自由だって利きやすいですし、少ない元手からアイディア一つで一山当てることだって可能です。それだけに、問題対象の適切な抽象化、および、論理的な推論ができる組織は、波田野さん曰く「テコが効く」組織になります。
ドキュメントは永遠の輝き
実装は一時のものです。組織のワークフローの変化や、外部環境の変化に合わせて、その中身は適切に変わっていくものでなければなりません。
しかしながら、その実装の根幹となった考え方は、きちんと体系化されていれば応用が利きます。可搬性だってあります。そうした体系化の産物、それがドキュメントというものであるはずなのです。そうした問題意識のもとで作られ、問題意識がきちんと継承され続け、中身が最新のものであり続けているドキュメントというのは、ダイヤモンドの如く永遠の輝きを有するものになるでしょう。
…ここまで書いていて気づきました。ドキュメントを輝かせるためには、ドキュメントそのものへのアクセスを確保するための高い検索性を有していなければならないな、と。それこそ、当ssmjpで@Typhon666_deathさんが発表していた「もしそこらへんの運用担当者が波田野 裕一の『運用業務の設計思想 〜 変化に強く、スケールおよび持続可能な運用を実現するために』を読んだら(もしハタ2)」の発表内容がド直球の言及です。
延長戦
波田野さんが「ここまでは全部発表しきる」と宣言していた部分についての言及は以上です。この項については、波田野さんが「時間が来たら打ち切る」と宣言した上で発表した部分についての言及となります。
運用エコシステムとは
- ユーザーよし
- 経営層よし
- 協力組織よし
- 現場要員よし
以上に挙げた諸ステークホルダー、各々が互いに影響しあい、みんなの「よし」を実現するために自己改善していく。そんな自律的生態系を実現していくことができるシステム、といえるのではないかと思います。
IT運用現場単体では、色々やっても効果は限定的なものにならざるを得ません。経営層や取引先、非IT系企業なら本業の現場。運用構造化は、そういった諸ステークホルダーをも巻き込んだ形で展開していく必要があります。第16回redmine.tokyo勉強会における@tKusukawaさんの発表の内容が、まさしく「Redmineを一媒体とした、非IT企業における運用エコシステムの構築」に関する発表だったことを記憶しています。
管理可能性
「原価の管理可能性に基づく分類」とは、原価の発生が一定の管理者層によって管理しうるかどうかの分類であり、原価要素は、この分類基準によってこれを管理可能費と管理不能費とに分類する。
デロイトトーマツによる「原価の管理可能性に基づく分類」の説明です。
「運用構造化は、取引先や協力組織をも巻き込んだ形で展開していく必要がある」という話をしました。しかしながら、自社外のステークホルダーの振る舞い、自社内であっても自分自身が権限も責任も持たない対象の振る舞いについては、自分自身で管理することはできません。自分自身が管理できないところにまで影響を及ぼす必要があるという事実。それは、運用構造化の難しさでもあり、面白さでもあるのだと思います。管理不能なセクターに影響を及ぼす能力を、自社に依存しない形で発揮することができる…そんな人材は、おそらく自社でのポジションを失っても引く手あまたである、そんなことを考えています。
概要設計と詳細設計について
品質のうち、管理可能な範囲を超えるスコープとなるのがサービス品質であり、管理可能な範囲内に収まるスコープとなるのがデリバリ品質…ということになるのではないか、と考えました。
公式性と非公式性
客観的な依頼要件と提供成果を明示した公式な運用サービス
波田野さんは、公式性という言葉についてこのように説明しました。商用サービスであっても、公式なサービス内容を明確に定義できている運用組織は実は少ないのだそうです。特に、お金が絡まないサービスが公式化されている例は非常に少ないのだとか。
以下私見。
- とかく日本の商慣習や社会慣習においては、サービス内容の公式化を恐れる向きが強い
- 「書かれたことが全てである」といえば、公式性のあるサービスと非典型契約（民法）は関係が深いと思う
- 公式性を得ようとすると様々な闇が見えてしまうことになる顕著な例といえば、同人界隈、とりわけ二次創作同人界隈
こんなことを考えた次第です。公式性って、奥も闇も深いテーマですよね。そんな中で、如何にステークホルダー向けのサービスを公式化していくか。これからの仕事というのは、そうしたことも念頭に置いて進めなければならないのではないでしょうか。一筋縄ではいかない時代になったものです。
余談
- 作者: 沢渡あまね
- 出版社/メーカー: 技術評論社
- 発売日: 2019/07/06
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
前回の岡島さん回といい、今回の波田野さん回といい、根っこにある問題意識は類似するものがあるように思います。そのあたりに深く突っ込んでいることが期待できそうな新刊が、沢渡あまねさんによる本著「仕事ごっこ ~その“あたりまえ"、いまどき必要ですか?」です。間もなく7月6日発売予定。早速予約させていただきました。
