【レポ】ssmonline #2に、参加しました。
お疲れ様です。inoです。
今回は、先日一部参加させて頂いた、ssmonline #2)の、参加レポートを執筆したいと思います。
宜しくお願いします。
まず、ssmjpの概要について。。。
以下を参照ください(大雑把ｗ)。
https://ssm.pkan.org/
さて、今回はスペシャル会(運用会)でして
波田野さん、沢渡あまねさん、國武さんによる、パネルディスカッションが行われました。
togetter
https://togetter.com/li/1551591
各々の内容を僕のTwitter実況を中心に、肉付けして纏めていきます。
※togetterと、内容がかなり被っていますが…
パネルディスカッション"運用の価値"
ーー運用の価値とはーー
「サービスを継続的にデリバリすること」であり、運用業務の本質は
「事業継続性の実現」
「事業継続」に貢献しているかどうかで、運用の価値が決まる
ーー運用に対する見方/対価ーー
・(会社説明会やコミュニケーションの話題でよく出てくる、
要求と成果物の違う木ブランコを出しながら)
お客様の期待しているサービスと、提供しているサービスのギャップ問題
・後だしじゃんけん。さあ納品するぞー、という段階で急遽要求される
・運用に対して、ちゃんと費用/予算をもらえているか？
他業務の片手間的に、ついでとしての扱いをされていないか？
ーーサービスカタログの提案ーー
・サービスカタログは社内、社外どちらでも
コミュニケーションの手段として有効
・業務を抽象化し、個人にしかできないことにしてしまうことで
属人化が進んでしまう。
・理解の及ばない、腹落ちしない部・人に対してどうするか
ーーゲートウェイーー
・その他で部長を部長を窓口に、
上司をデフォルトゲートウェイにしちゃえ！
・サービスカタログは組織のミッションを決めるもの。(トップダウン)
作業カタログは作業の一覧を網羅するもの。(ボトムアップ)
サービスカタログ→作業カタログ、の順番が正しい
ーーチケットーー
・テレワークはチケット大事。
口頭伝達は論外。
メール洗い出しは闇。
チャットはさらに闇。流れてしまうので、チケットを起票し
ナレッジとして蓄積する
・ドラクエ的チケット起票の提案。
チケットに きひょう しますか？
はい ←
いいえ
ーー業務のお葬式ーー
・組織改編のドタバタでどさくさに紛れて
誰が見てもなくしたほうが良い業務は
積極的に終わらせにかかるとか
ーートホホ経験ーー
・失敗したことでしか得られない経験がある
・トホホ経験値
・実感ですけど
トホホをトホホとしか思えない、そこから何かを
学ぼう/振り返ろうとしない現場は
同じような失敗を繰り返しますね
ーーチケット駆動ーー
・魂の入っていない仕組みはダメ。
チケットの場合、チケット番長的な役割が必要。
・チケット強制クローズは必要だが
それが多い人にはペナルティーを。
・チケット設計できる人が、チケット番長をやる
・放置したチケットは部長へエスカレされる仕組みづくり、とか
・Amazon SQSは一種のチケットシステム
パネルディスカッション"システムの作り逃げ"
ーー作り逃げーー
・20年前のネタでアクセストップ。歴史は繰り返す。
・逃げ遅れたがために運用…
・作り逃げ＝未来の時間泥棒※下図参照
・俺つえー奴によって作られた成果物
(でも中身は運用できない引き継げない)で、未来の時間泥棒が産まれる
ーー手段としてのSaaSーー
・内製(内政？)にこだわる情シスによって
現場では必要ないコード/ツールが量産される
・SaaSを考えるにしても、業務設計ができてから。
枯れた業務には、枯れたSaaS
ーー自分だけで頑張れるところは頑張る。それ以上は切り捨てーー
・自分が変えられる部分は経験になるが、自分だけでは不可能なら
次に行ったほうが良い。
くさった組織は、一回ころさないと。
優秀な人の間で揉まれよう。そのほうが楽しい。
ダメだこりゃ、次行ってみよー。(byいかりや長介)の精神
ーー見極めと感謝とーー
・今ここでしか得られない経験があるなら居てもいい。
自分を不幸にして、頑張れるかどうかを見極める。
成長があるか、感謝があるか
ーーインフラ運用保守のあれこれーー
・インフラや運用保守はあまりやりたがらない。開発構築などの
ついでに押し付けられる。
一つのミスで猛烈に責められる。リスペクトされない
・ふりかえりの機会が設けられれば、運用保守も絶対楽しくなりますが
どうやってその時間/実行権を得るかが課題ですね
・経営陣と運用現場の乖離問題
・運用顧問制度の提案
・できない子もできる子も経験しましたけど
人間、結局適材適所です
ーー教育機能ーー
・運用保守は人を育てる機能も求められている。
ドキュメントを用意すれば、できる子は勝手に読む。
・自分の暗黙知をドキュメントで見える化する。自身の経験にもなる
ーー炎上現場を経験した結果…ーー
・炎上現場で育つのはメンタル…？
育つのは火事場根性と糞雑魚自己否定メンタルだけです…(僕の経験談)
ーーテンションーー
・テンションが上がる職場でないと、スキルも上がっていかない
・トラブル発生でテンションが上がる…わかりみが深い
ーーみんな運用デザインしようよーー
・みんなSaaSにして、運用デザインに切り込んでいったほうが幸せなのでは。
→作り逃げ→業務デザインがないから、だから
業務設計・業務デザインをしっかりやるんだ、という方向に
わりきってしまうのもアリなのでは
・オンプレは置いといて次に行こうよ、IT屋さんは
業務設計をやる人、ビジネスわからない人はエンジニアではない、
みたいな割り切り
→
・ 今、運用やっている人/オペレータの目線低い問題
ーー金払い良いお客様はーー
・金払い良い客は話通じる。悪い客は捨てるのも選択肢
ーー教育相手ーー
・上司も教育する相手
お客様も教育相手
それも仕事の範囲。お客様を教育するのは、AWSが良い例
・お互いの仕事が見えていると強いので
やっぱりサービスカタログが…
ーーマーケティング/エンジニアリングーー
・マーケティングできるエンジニアは一番強い。
営業しかできない人は要らない
・マーケティングとブランディングで組織の価値をどう上げるか
ーー昔の負債ーー
・戦時中と戦後製造業の歪んだ成功体験が負債になっている
・運用でカバー。人でカバー。本当に悪しき習慣
・論理的に考える人/ロジカルに仕事をする人を増やさないと、
ITは動かない。感情で仕事しちゃダメ
→そもそもの日本の教育が問題。感想を強制的に書かせるのは良くない
→(僕の話)国語の、特に現代文の筆者の考えを述べよ系の問題は
苦手でした‥
ーーとにかく、書いてみるーー
・考えるより産む(この場合、書きだす)が易し、か・・
感想
・ssmjpのスペシャル会ということで、とても楽しい時間でしたが
今、運用保守を行っていることもあって
身につまされる/心当たりがあることばかりでした。
・チャットと課題管理のバランスは本当に頭を悩ませます。
チャットだけで課題を把握するのは不可能
(語弊があるかも知れませんが、言い切ります)ですが
だからと言って、全部をチケットツールや課題管理ツールで
やろうとすると
起票/課題提起自体をすることが義務になってしまって
やらなくなってしまって。
チームの特性なんかも加味しないとダメなのかなぁ‥と考えてます。
※↑が人でカバーになってしまうのが、また悩ましいです。
・チケットもそうですし、議題の「作り逃げ」でもそうなのですが
起票した/作成した！で終わりなのではなく、それを活用し
業務を円滑にまわしていく。逆にそのために
チケットやシステムがあるんだ、ということを再認識しなければ。
と感じました。
自分しか関係してないからこれで良いや…ではなくて
成果物を周りが活用する。そのためにはどういった要素を盛り込む
必要があるのか？
そしてその活用のために、周りをどう教育していく必要があるのか？
といった考え方をして行かなければ…と。
業務でモヤっとしてた部分なので、やり方を見直す良いきっかけになりました。
・やはり運用系の会は熱量が凄くて、毎回凄く刺激を受けています。
そろそろ受けてばっかりで申し訳ない気持ちになってきたので
何か登壇のネタを考えて、登壇…してみようかな？(考えただけで緊張してきた💧)
以上です。
最後まで読んでいただき、ありがとうございました！