urahiroLog

書きたいことを書きます。プログラム以外のことも

1年弱システム保守チームリーダーやってきてわかったことなど

2023年6月に諸事情あってリーダーになり、わからないなりに試行錯誤して最近安定できてきたので、考えをまとめる。

スペックとか状況は以下みたいな感じ。

  • 社会人4年目
  • システム保守/追加開発の現場
  • メンバー2,3人のチーム(大きな案件で5人まで増えた時期もあった)

リーダー業務の基本の流れ、思考

基本は以下3つだと思う

  1. 計画の立案
  2. 計画の遂行
  3. 問題、リスクの対応

1. 計画の立案

今、見えている情報からゴールまでの道のりを考える。 見えている情報は以下のような情報のこと

  • ゴールの詳細(そもそも目標はなに)
  • リソース状況(人、モノ)
  • 現在の進捗状況(プロジェクト開始後の場合は)

計画の立案と書いているが、やる前に最初から最後までの詳細な計画を立てられるわけがないし、 計画を立てる時点ではそもそもわからないことだったり、まだ決めなくていいこともある。 そういったものに関しては計画を立てる計画を考えておく。 「いつまでに情報を集める」だとか、「〇日には準備が整うはずだからこの日程で考える」みたいな感じで。

2. 計画の遂行

1で立てた計画を実行に移していく。 実行自体はメンバーに任せてしまうほうがいいとは思う。少人数チームだとそうもいかないけども。

このフェーズでのリーダーの仕事は計画と実績のズレを観察すること。 進んでいる場合はいいけど、遅れている場合はリカバリ可能な範囲なのかを常に見ておく。 メンバーが頑張ってもリカバリできない規模のズレが発生したら、計画の変更などのリカバリプランを考える。

3. 問題、リスクの対応

問題とリスクの対応。これは2の遂行の中でやっていくことだけど、重要なのでトピックに挙げる。

それぞれの定義は以下

問題
プロジェクトの成功に影響を与えるもの。バグ、障害など
リスク
上記の問題になる可能性があるもののこと

「飛行機で自宅に帰る」がゴールとした場合、「空港に行ったらチェックイン時間すぎてて乗れなかった」は問題で「この映画を見ると電車がギリギリになってチェックイン時間を過ぎてしまうかも」がリスク
リスクは事実をもとにした予測。

うまくリスクをキャッチできれば問題を未然に防ぐことができる。大抵の場合は問題発生後に対応するより未然に把握して対応した方が楽なのでこれを活用していきたい。

問題(障害、バグ)は来たものを対応すればいいけど、リスクはこちらから能動的に取りにいかないと気付くことができない。
リスクは事実から「かもしれない」と連想するものなので、いろいろな事実を日頃から集めておいてプロジェクトの動きにいち早く気付けるようにしておきたい。かもしれない運転みたいなこと。


大体こんなところだと思う。

これからやっていきたいやつ

まだまだこれからやっていきたい取り組みも書いておく。

メンバーへのフィードバック

メンバーにパフォーマンスだったり日々の動きのフィードバックをしていけるようにしたい。 正直、年上のメンバーしかいないので気が引ける部分もある

そのためには「こう動いてほしい」って考えを持たないといけないからまずはそこから。

属人化している業務を減らす

前々からの課題。GitLab本を参考にドキュメント化を進めていく予定。

自分を含めて全員総入れ替えになっても最悪運用が続けられる状態を目指す。

最後に

プロジェクトマネージャー用の研修で聞いた話とかも多分に含まれるので、どこかで聞いたことがある人もいるかも。実務を通して大事だなって実感したものを書いてる。

最後にこの記事書いた動機を書いておく。

  1. 社会人になって4年、次は5年目になるタイミングで学校の同級生とか同期たちは何の仕事してるんだろうと気になったので、まずは自分の仕事の話を公開しようと思った。

  2. 1年弱やってきて効果を実感できたことを書いたので、リーダーになったばかりとかリーダーになる予定の人のお役にたてれば。

  3. 今、考えてることを後で見返すと楽しそうだからまとめた。

おしまい