人と仕事の話をするときに、指示する・されるという話がよくわからなかった(そういう風にはしていなかった、と思ってる…)ので、とりあえず書いて晒して確認してみようという意図で書きました。

※マズかったら消す。でも多分マズくはないはず……
※あまり詳しく書くと恥ずかしいTwitterアカウントがバレてマズいというのはある

前提

メンバー

• リーダー (サブシステム A～C担当)
• SE1 (主にサブシステムAとC担当)
• SE2 (主にサブシステムB担当)
• PG1 (主にサブシステムAとB担当)
• PG2 = 自分 (主にサブシステムCとD担当)

※ここの「～を担当」は、一番詳しいとかその程度の意味で、明確に線引はされていない。
※SEとPGは職務等級が違うだけでやることは同じ。
※プログラミングは元請けからの別の外注さん

契約形態

持ち帰りの請負。(SESではない)

ざっくりした業務内容

• ホスト(COBOL系)のシステムや、ホストと連携するWindowsのCSのシステムの保守
• 機能追加や修正、調査・データ抽出など

案件の流れ

それぞれがフェーズを持つというより、それぞれが案件を持つ形で案件を進めていきました。

※基本的に担当者(リーダー～PG2のうちの誰か)目線で書いています。主語や目的語がなければ担当者。

①案件の発生

• 元請けさんから電話かメールで問い合わせが来る
  • 一旦、一番詳しそうな人に投げる
  • 最終的に受け取った人(= 担当者)とリーダーさんで、こんな案件が来ましたよ―対応しますよーっていう話をする
    • みんなが聞こえるように相談して情報共有
      • 例えばリーダーさんとSE1で相談してるときに横からPG1・PG2がツッコミをいれることも普通にある
  • だいたいどんな案件か決まったところで案件のリスト(Excel)に追記する
    • 自側の担当者・元請側の担当者・本番日(決まっている場合)を書く
• 週次の打ち合わせで案件整理
  • 基本的に元請け側・自側全員出席する
  • 案件の担当者を決定(決めていなかった場合)
  • 進捗や情況の確認
  • 保留のまま流れた案件の除去など
• 調査系とプロジェクト系で分岐
  • 調査系: 後でメール + 説明の電話でクローズ
  • プロジェクト系: 次のステップへ(見積もり)

②見積もり

• 対応範囲・工数・請求額を見積もる
  • サブシステムに跨るときや、自分以外にも詳しそうな人がいる場合は積極的に相談する
  • 元請けさんにも案件のことを根掘り葉掘り聞く
    • 予算も確認する
    • 納期や予算の関係で捨てる部分なども打ち合わせる
• 見積もりができたら内部レビュー
  • 上下関係関係なくレビューが必要
  • 規模が大きいとき(1人月超)は全員でレビュー
  • 小規模でも、忙しくないときは全員でレビュー
• 見積書に含めるもの
  • 各工程の工数
  • 対応期間(人数や作業の順番の考慮があるので、工数と対応期間は別)
  • 納期(本番日)
  • 対応範囲
    • やること・やらないこと
    • 例えばテストを一部省くだとか、元請けさんにテストをやってもらって値引くとかそういうことはちゃんと書く
• 見積もりができたら、作業の計画はざっくり完了している

③設計・テスト

• 設計書を書いたりプログラム作成を依頼したりテストをしたりする
• 本番作業が絡むものや日付に意味がある場合は対応スケジュールを作成する
  • 入れ替えは16日以降20日以前じゃないとダメ、とかそういう時
• 設計・テストの両方で、内部レビューと外部レビューを行う
  • 内部レビューは基本的に全員で実施。忙しい場合は最低限、リーダーと担当者で実施。
    • このとき、(ついでに)担当外の人にノウハウを共有したりもする
      • ノウハウの共有は、後で「ああ、そういえばあんな単語聞いたことあるなぁ…」と思わせる程度からじわじわ始める
  • 外部レビューは基本的に元請けさんと自側全員で実施。忙しい場合は最低限、元請けさんとリーダーと担当者で。

④本番

• リリース前にリーダーにチェックしてもらってリリース。リーダーは他の人にチェックしてもらってリリース。
  • 忙しくない場合は全員でチェック

まとめ

• こんな感じでそれぞれが案件を持ってそれぞれ動いていて、あんまり指示したりされたり、っていう感じでは……
• 指示というより、相談が多かったかも。