1. 話した内容
1.1. 大森さん
1.1.1. お客さんと話す
1.1.1.1. 人を入れる
1.2. 外村さん
1.2.1. 下につく
2. タスク管理
2.1. 見積もり
2.1.1. 見積に入れる項目
2.1.1.1. 工程外
2.1.1.1.1. 計画
2.1.1.1.2. フィジビリティ
2.1.1.1.3. 事前影響調査
2.1.1.1.4. 開発に向けた環境用意
2.1.1.1.5. システム要件定義
2.1.1.1.6. システムテスト
2.1.1.1.7. UAT
2.1.1.1.8. CI/CD
2.1.1.2. 工程
2.1.1.2.1. システム要件定義
2.1.1.2.2. 外部設計
2.1.1.2.3. 製造
2.1.1.2.4. IT
2.1.1.3. バッファを入れる
2.2. wbs作成
2.2.1. タスク洗い出し
2.2.2. スケジューリング
2.2.2.1. リリース日から逆算
2.2.2.2. ジュニアレベルに任せるときは余裕を持った締め切りを設定
2.2.3. アサイン
2.2.3.1. やりたい部分の希望を聞く
2.2.3.1.1. モチベーションを保つ
2.2.3.1.2. できる領域を増えしてらう
2.2.3.2. 作業のローテーションを意識する
2.2.3.2.1. 各メンバができる作業を増やすように新しいタスクを任せるようにする（スケジュールの許す範囲で）
2.2.3.3. 育てる人と育てない人を分ける
2.2.3.3.1. 全員同じように伸びるわけではない
2.2.3.4. 1人日、1人月フルで作業を埋めない
2.2.3.4.1. 休暇、割り込みもあるから0.6-0.8くらいで埋める
2.3. タスク管理でやること
2.3.1. タスク整理資料作成（外部むけ）
2.3.2. キックオフ
2.3.2.1. キックオフの目的
2.3.2.1.1. 前工程からかかわってるメンバと途中参加のメンバの情報格差埋める
2.3.3. 各メンバの担当タスクの明確化
2.3.3.1. タスク説明資料作成（内部向け）
2.3.4. 進捗状況確認
2.3.4.1. ジュニアレベルへの対応
2.3.4.1.1. 作業分担直後に認識合わせ
2.3.4.1.2. 確認はWeb会議で（チャットだと正確な状況がわからない）
2.3.4.1.3. 早めに方向性を確認
2.3.4.1.4. 序盤からちゃんとレビュー記録は残さない
2.3.4.1.5. 調査系のタスクは資料をまとめるまでをタスクにする
2.3.4.1.6. 細かいチェックポイントを設ける
2.3.4.1.7. wip段階でのレビュー
2.3.4.1.8. 真似する元ネタのポインタ教える
2.3.4.1.9. プロト作成して真似してもらう（プロトはベテランに作ってもらうのもいい）
2.3.4.2. 中堅への対応
2.3.4.2.1. チャットで聞く
2.3.4.3. ベテラン
2.3.4.3.1. 勝手に終わったら連絡くれるから放置
2.3.4.3.2. レビュー依頼がきたらレビューして軽い指摘して終了
2.3.4.4. その他
2.3.4.4.1. 期限前にリマインド
2.3.4.5. 上位者が確認できるようにサマリとなる資料作る
2.3.4.5.1. WBSでいいときもある
2.3.5. 作業遅れている時のリカバリ
2.3.5.1. スケジュールを調整する
2.3.5.1.1. 工程終わる前に次工程着手
2.3.5.1.2. バッファを使う
2.3.5.2. 人増やす
2.3.5.3. 難易度高ければ巻き取る
2.3.6. 全体の整合性をみる
2.3.6.1. 各自自分の担当分しか見てないこと多い
2.3.7. お見合いの防止
2.3.7.1. ｘｘさんがやってるだろ、でお互い手をださないことありがち
2.3.8. 作業のボトルネックの解消
2.3.8.1. 開発で非効率な部分を潰す
2.3.8.1.1. テスト面が少なく順番待ち・・・
2.3.8.1.2. デプロイに時間がかかってREPLが回らない
2.3.8.2. 情報の格差を埋める
2.4. 割り込み作業への対処
3. 体制
3.1. 要員相談（人の入れ替えとか）増減員
3.2. 増員時
3.2.1. 面談調整
3.2.1.1. スキルシート入手
3.2.1.2. スキルシート展開
3.2.1.3. 面談日程調整
3.2.1.4. 所属との調整
3.2.2. 経歴確認
3.2.2.1. 各案件の期間
3.2.2.1.1. 短い人は避ける（よい人なら長くいてもらいたがるはず。）
3.2.2.2. 使ってきた技術
3.2.2.3. かかわった工程
3.2.3. 面談同席
3.2.3.1. 話すこと
3.2.3.1.1. 今のスキルよりキャップの速さが大事
3.2.3.1.2. チームの体制
3.2.3.1.3. 抱えてるプロダクト
3.2.3.1.4. 現在のプロジェクト状況
3.2.3.1.5. 今後のプロジェクト予定
3.2.3.1.6. 勤務時間、昼休み
3.2.3.1.7. フルリモートであること
3.2.3.2. 聞く事
3.2.3.2.1. スキル
3.2.3.2.2. コミュニケーション
3.2.3.2.3. 発言の矛盾ないか
3.2.3.2.4. リーダーシップ
3.2.3.2.5. かかわった工程
3.2.4. 受け入れ
3.2.4.1. 緊急用に電話番号聞く
3.2.4.2. 受け入れ資料作成
3.2.4.2.1. チーム体制
3.2.4.2.2. 担当しているプロダクト
3.2.4.2.3. 案件の状況
3.2.4.2.4. 要件資料のパス
3.2.4.2.5. 設計書のパス
3.2.4.2.6. ソース
3.2.4.2.7. 勤務時間、昼休み
3.2.4.2.8. 現場ルール
3.2.4.3. 申請周り
4. メンバー管理
4.1. 定時に出社しない
4.1.1. 事故、体調不良ではないか確認
4.1.1.1. メッセージ送る
4.1.1.1.1. それでもダメなら電話
4.2. チャットに応答ない
4.2.1. 事故、体調不良ではないか確認
4.2.1.1. メッセージ送る
4.2.1.1.1. それでもダメなら電話
4.3. 聞かない限り何も報告しない
4.3.1. 朝会、夕会で報告求める
4.3.2. 個別チャットで聞く
4.4. 毎日明日終わりますと言う
4.5. 病欠が多い
4.5.1. できる人
4.5.1.1. 何が困るか？
4.5.1.1.1. 作業の引継ぎができない （何がどこまでできててどこにあるかわからない）
4.5.2. できない人
4.5.2.1. 交代
4.5.3. 普通の人
4.5.3.1. 悩む・・・