運用保守チームの課題を考える会

これはなに

そういう会です。

考える

  • とりあえず、考える。
    • どんな課題があって、どんな解決方法があるのか
  • 課題
    • 業務としての認知負荷の高さ
      • 全ての業務領域を知ってないといけない
      • →業務に対する知識、しらんなら調べる力、関係性作る力?
    • システムとしての認知負荷の高さ
      • 巨大な泥団子
      • 機能が豊富
      • 責任範囲も豊富(ITS, ITR、流入後から契約まで?)
      • 社内のシステム間連携
      • 社内のAPI利用
      • ストレージ
      • メールとか通知する系のやつが多い
      • 大量のバッチ処理
      • 仕様バグがある
    • 開発を取り巻く環境
      • 開発の要望が多い? 少なくとも追いつけていない
      • 納期がだいたいタイト?
      • 保守的な姿勢(バグを生まない、悪くしない、改善活動のハレーションを気にしないといけない)が求められる、と思っている
    • ドキュメント
      • 古い情報と新しい情報が混在している
      • (機能が多いため)どこに該当の設計書があるのか、記述があるのかわかってない
    • ミドルウェア、ネットワーク、インフラなどアプリケーションレイヤー以外の観点
      • 関連があまりに多いとDBの制約とかを導入しにくい?
    • 外部環境
      • 法改正への対応
      • 疾病、言語、地理、そこら辺は現状なさそうだが。。
    • 運用面の、なんだ? まあとにかく運用
      • 止まるといろんなところに影響が出る
      • データ多すぎて重くなる
      • バージョンアップ対応に対応できてない
      • 大量にあるバッチ処理
      • アラートがばんばん飛んでくる
      • データ不整合を生み出す運用クエリ
      • 複雑なSQLかかないといけないこと多い
      • データ修正要望
      • 運用タスクが多いし急ぎがあって時間取られがち
    • 障害の起点が多い?
      • 関連システムとの連携でワーッとなる
      • 運用クエリ
      • バッチ処理
      • メールとか通知する系のやつが多い?
      • いろんなAPIとか連携システムを使う
    • 事業部接点
      • 事業部とのコミュニケーションをしないといけない
      • 機能提供しているのはこのシステムだなあ
      • 直接的に価値提供できる
      • システムを通じたコミュニケーション
      • 問い合わせを通じたコミュニケーション
    • チームビルディング・開発者体験
      • 長い歴史のシステムになると初期メンバーがいなくなってて、システムに対するオーナーシップが欠如する
      • お守りになりがち(なのでモチベーションが保ち辛い? お守りとは? 新規開発が少ないってこと?)
      • 新しい技術の導入、挑戦できる機会が少ない?
      • テストが書けてない
      • 適切なスクラムの導入方法がまだ手探り
      • 守備範囲が広いので、広く浅くになりがち
      • 生産性を測れていない
      • スケジュールを後ろ倒しにしがち

書いてみての感想

  • これメンバーが前に書いてたスライド見てもいいかも
    • 取り込んだ
  • あとこれうちのシステムの課題だな、それどどういう問題を解決したいのか? とは微妙にズレてる気がする
    • つまり、なんだろ、運用保守チームなので、メンテ的な活動が多くなって、そこでこういう改善ができるね、まで話が進んでない?
    • 問い合わせなら問い合わせフローを分かりやすくするとか
      • これはサービス視点で、システム外のサービスの設計をしている。そういうスキルと言える
    • なんなら、システムのトップにスラックリンクつけたらどうか?
      • ここもサービスとしての視点。問い合わせも機能の内なので、そこを整備している。
  • それと、こう、サービスとしてみたときに、技術力で対応する必要が必ずしもないものが結構あって、そこが割とでかい気がする
    • これはなぜかというと、えー、具体的にはそれが何を指しているのかというと
      • 問い合わせ対応
      • 事業部とのコミュニケーション
    • ここら辺かな? 別にそんなデカくはないな
    • ほんで、そこは、うーん、顧客が違うからかな。例えば基盤チームの顧客は、利用者ではないもんな、というのは問い合わせを受けたりはしない。顧客は技術者がちな気がする、知らんけど

書いてみての感想その2

  • 対応方法が(雑)となるところがちらほら
    • ここは経験が足りなかったり想像力の及ばないところなので、人に聞けるところ
  • 重複するやつ
    • 運用でデータ不整合、複雑なSQL、急ぎのデータ修正、あたりに対して、SQL慣れる程度の解決策しか出てこない
      • →テーブル構成を知るとかはあるかも
  • 当たり前のことがあるね?
    • 使用している技術に精通する
    • システム自体の知識をつける
    • webシステム一般についての知識
      • セッション管理とか…
  • 一旦課題と対策について綺麗にしようか。重複とかを省いて
  • あと、ヒアリングで聞きたい項目をあげる
    • あなたのシステムの概要
    • どんな問題を感じているか?
    • (ハード/ソフトスキル問わず)どんな対策が具体的にあるのか?
    • 連絡先と調査結果がまとまったら送って欲しいか否か

人に聞く

  • とりあえず自分の意見まとめた上で、くれさんと喋ったり、あとmeety使って聞いてくる

人に見せるためのやつ