amareloのブログ(仮)

IT系勉強会で感じた想いや知見をメインに書いていきます。

ssmonline #2 参加レポート

6/30(火)、ssmonline #2 に参加しましたので、レポートを書きます。

今回は、沢渡さん、波田野さん、國武さんの3人のパネルディスカッション形式で進行しました。國武さんのツイートがきっかけで今回の座談会が実現したとのこと。久々のささみがガチ運用会でとても楽しく参加できましたが、身につまされる思いで拝聴していました。

目次

イベントページ

ssmjp.connpass.com

Togetter

togetter.com

概要

Togetterに書いてあることと被る部分もありますが、自分がメモしたことをまとめます。

パネルディスカッション"運用の価値
  • 運用とは?

    • サービスを継続的にデリバリすること
    • 運用業務の本質は「事業継続性」の実現
    • 「事業継続」に貢献しているかどうかで「運用」の価値が決まる
  • 運用できちんとお金を貰えているか?

    • 商用であれば、営業がお客様からお金をいただけているか
    • 社内であれば、ちゃんと予算を確保できているか
      • サービス保守の名目でお金をいただけるよう、営業担当者に意識させなければならない
    • コロナ禍でITが追い風になっている。ITにお金がかかるところをメニュー化して投資できるかがカギとなる
  • 運用のサービスカタログを作成する

    • 社外、社内どちらにおいてもコミュニケーションの基盤となる
    • 日本人は仕事を曖昧にして自分しかできないようにする(属人化)。
      • それが力の源泉になっているところもあるが、可視化して周りに理解してもらう必要がある
  • 運用の価値を上げ、予算を確保するためには、上司をデフォルトゲートウェイにするのも手

    • 言われたことばかりやっているだけでなく、上司をコントロールしてWinWinの関係を目指す。
    • 社内の場合、顧客は予算を確保してくれる人。つまり上司となる。
  • サービスカタログは組織のミッション。作業カタログは組織のカード。

    • 自分たちがのてんわやんわしている作業を整理するために、作業カタログが必要
    • 作業カタログの棚卸も必要。誰もがなくした方がよいと思う業務は、積極的に終わらせた方がよい。
      • サービスのライフサイクルを意識する。
  • 失敗は体力があるうちにしておくこと

    • 成功だけでなく、失敗をして良い経験を得ることが大事。
パネルディスカッション"システムの作り逃げ"
  • 「作り逃げ」=「未来の時間泥棒」

    • 雑に作り逃げされたシステムを押し付けられて現場が炎上する
    • 何も考えずにコピペしたり設計書を流用することで、 運用できない、引き継げない問題に直面する。
    • 個性的なオレオレコードでマウンティングすると、職場の雰囲気も悪くなる。
      • 結果、未来の時間泥棒となる。
  • サービスレベルに対してどのように業務設計するかを考える。

    • SaaSありき、道具ありきでは考えない。
    • どんな道具(SaaSなど)があっても、業務設計ができなければならない。
  • 組織を自分の力で変えられるかどうか

    • 変えられるならば、自分の経験値アップになるので良い。
    • 自分一人の力で変えられないならば「次行ってみよ~!」の考えで別の場所に行って、優秀な人たちと仕事した方が楽しい。
    • ただ、今いる場所で得られるものを見込んでいるならば、頑張るべき。
  • インフラ、運用保守をやりたがる人がいない問題

    • 開発は失敗があってもリカバリできることがあるが、運用保守はミスをすると責められる
    • リスペクトされない
      • 運用保守は事業継続。開発する人だけいれば事業継続できるのかを、理詰めで話す必要がある。
  • 運用現場に人を育てる機能が求められている。

    • 知見をドキュメントで非同期に渡せるとよい。
    • ドキュメント作成をボランティアにするのではなく、人事評価制度としてあるべき。
      • ドキュメントを作るのは、自分の教育にもなる。ドキュメントを書いた人が育つ。
      • ドキュメントがあれば読んで勝手に育つ人もいる。
    • 学習・成長戦略を言葉にすること。
    • テンション上がる職場でないと、スキルは上がらない。辛さの中に楽しみがあるのは良いが、辛さのない仕事はない。
  • エンジニアは業務設計ができる人に

    • 運用でビジネスへの貢献を。
    • そのために上司も顧客も教育をすることが仕事となる。
      • リテラシーを上げて仕事をしやすくするために。
      • 顧客の教育についてはAWS社が良い例。
    • 最終的には、サービスカタログが大事
    • マーケティングをできるエンジニアが強い。
    • マーケティングブランディングで組織の価値をどう上げていくかを考える。
    • ロジカルに仕事をできる人と増やさないとITは動かない。
    • 視野を広げて仕事相手のことを考えて自分たちの仕事を見つめなおすこと。
      • 何が自分たちの業務のサービスカタログかが見えてくる。
      • 最終的にはサービスカタログが重要。

感想とまとめ

最初に書いた通り、とても楽しく参加することができましたが、身につまされる思いでいっぱいでした。 「事業継続性」を十分に意識した仕事ができておらず、自分の仕事が結果的に他者の時間泥棒になっているんじゃないか?と思いました。 ビジネスへの貢献を継続させるためには自分一人の考えや力だけでなく、関係者全員で考えられるようにしたいと思いました。 ツールを導入、新規の業務、物やサービスの販売や推進、それらありきで考えるのはあまり良くない。どんな組織にしたいのか、他者にどうなってほしいのか、それを実現できることかと他者に与える影響(良いことも悪いことも)をよく考えてから始められるようになりたいです。それができないと、ビジネスに十分に貢献できないし関係者に対して時間泥棒になってしまいます。改めて気づかされて、最近モヤっとしていた自分の仕事への向き合い方を見直すきっかけになりました。

まずは仕事の関係者全員へのリスペクトを忘れないこと、サービスカタログ化を常に意識しながら仕事できるようになりたいです。

それにしても、ささみに登壇する方は皆さん熱量があっていつも刺激を貰えます。久々の参加となりましたが、楽しい時を過ごせました。しばらくはオンラインになるかもしれませんが、次月以降もできる限り参加したいです。また登壇もしたいので、早く話すことを決めて登壇申込しよう!