コンテンツへスキップ

チーム運用方針として心がけていること

ITインフラの構築チームリーダーとして心がけていることや、普段からチームメンバーと共有していることを改めて書いてみました。

チーム方針として

  •  アップデートは細かく行い細かく転ける
    • 最新化への対応をする方がセキュリティにも寄与する
    • バージョンアップをため込むと転けたときの問題切り分けが難しくなる
    • 脆弱性は可能な限り早めに、Deprecated(非推奨)・Warning・Noticeは先回りして潰す
      • 外の世界(クラウドベンダー側のアップデートや攻撃者)は待ってくれない
    • 「細かく転ける」部分の学習として継続的インテグレーションの習得・啓発にも取り組む
  • 勤務時間内の学習時間を確保し、特に「組織外の風」を受けてくる
    • 勤務時間外の「個人の努力」に乗っからない
    • 社内のなれ合いや「勉強しない空気」とは一線を引く
    • 社内には無い視点を学ぶことができる
    • 勉強会に居るエンジニアは学習意欲の旺盛な人が多く、努力するエンジニアとの交流には価値がある
  • 「定期的に改善する仕組み」を作り、組織のアップデートを続ける
    • ふりかえりを行い「問題点から改善案を出すこと」を定期的にすること
      • 改善案を無理矢理ひねり出す必要はない
      • 「タスク」と「改善」は別
    • 「作りっぱなし」「リリースがゴール」「運用でカバー」などの無責任な仕事はしない
    • 出てきた改善案はチームで対応策・優先順位を決める
      • 絶対に上位層による黙殺・握り潰しをしないこと。問題に取り組む姿勢や改善案に対する返答がなければ案は出なくなる
  • ベストプラクティスを追求する
    • 動いたからヨシ!ではない
    • 暗黙的なデフォルト値を期待しない(バージョンアップで挙動が変わったりするため)
  • 本番環境以外での失敗は成果物と捉えて気にしない
    • 反省が前提ではあるが、ヒヤリハットも良い経験
    • ただし何らかのやらかしは記録に残す(後述)
  • ドキュメントを残し後々参照できるようにしておく
  • 「人対人」ではなく「問題対チーム」
    • チームとして問題を解決するのが最優先
    • マウント合戦や非難をしない
      • ただし「言いがかり」にはきちんと技術と知識で打ち返す
      • 稀にログも見ず思い込みだけで言ってくる人も居る
  • 業務範囲を狭めない
    • インフラでもアプリケーション(フロントエンド・バックエンド・データベース・テスト)の挙動を知る努力をする
    • インフラタスクの前段タスクに取り組む動きがなければ、他のロールとして立ち回ってでも他所に働きかける
      • 例)PMがインフラの稟議をいつまでも出さない、名前(ドメイン)を決めない、規約・法律の確認が行われていない、など
      • ※異なるロールの責任やタスクを背負うことになるため、ここに関しては諸刃の剣
    • 余所のチームでも困りごとには首を突っ込んでみる
      • 他者のトラブルシューティングは経験値アップの良い機会
      • 自身に責任はない上、第三者視点で問題を切り分けできる
      • 「上手くいったらラッキー程度で思ってくださいね」的に立ち回れば感謝されることはあっても、恨まれたりはしない(はず)
        • トラブルに対してトドメを刺さないようにだけ注意する

チームリーダーとして

  • 「報告・連絡・相談」ができる環境の維持
    • 話しやすい環境づくりをする
    • 具体的には「~~が正常じゃないかもしれない」「~~を作り直したい」など良くない部分があることを言い出せる環境だと良い
    • ちなみに、Wikipediaにもある通り「報・連・相」は部下の努力目標ではない
  • チームメンバーのモチベーション維持
    • テンションが上がる技術要素の学習には時間を割く
    • (チームメンバー内外に限らず)誰が何に対して興味を持っているか把握しておく
      • 自動化が好きな人には自動化のタスクや課題を振るなど
      • 一方で、「話を合わせてくるだけの人」に注意する。時間の無駄
        • 「興味があるんですよ~」と言う人ではなくて「○○試して××の課題があって~」って言う人の方が信頼性が高い
    • 資格取得奨励金の追加を会社に働きかける
    • ベンダーの技術サポート契約やビジネスパートナーの調整を行い、頼れるエンジニアとの橋渡しをする
  • 「漠然とした不安」を拾う
    • エンジニアの嫌な予感は大抵当たる
    • 不安を深掘りして優先順位高めのタスクにする
  • 充分な安全マージンを取った作業時間の確保
    • 初期の調査・検証の時間
    • 後半のクオリティアップの時間
    • 次回使いまわし材料作成の時間
      • 「安全マージン込み作業時間の確保+自動化による工期短縮+学習時間の確保」のコンボを狙っている
      • 次の案件が来ても「使いまわし+学習内容」ですぐ作って後は勉強時間に充てられるように立ち回る
      • 技術習得や学習に時間を充て、リーダー・マネジメント層はそれに加えて組織改善も
  • 休みやすい環境
    • 率先して有休を消化することで休みやすく
      • (と言うのはほぼ言い訳で、単に自分が遊びに出かけたいだけ)

 

 

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA