Guild・リソース管理ガイドライン ver1.0
👳🏻‍♂️

Guild・リソース管理ガイドライン ver1.0

ステータス

過去の履歴
  • 2021/1/6 Guildの案件名2021の年号を2022に変更

背景

  • 将来の稼働予測を元に受注や採用判断を行う必要がある
  • チーム毎およびグループ全体の稼働の最適を行う上で稼働状況が可視化される必要がある
  • Guildと呼ばれる社内リソース管理システムを構築した
  • ZACコード報告ガイドライン ver0.9は別のページに記載
  • Guildのガイドラインも必要になったので、Guild・リソースガイドラインとして名称変更

目的

  • 稼働の可視化を行い最適なアサインを行う

リソース管理システム

記載ガイド

  • 時間軸
    • 当月を含む、将来のリソース計画を記載する
  • 記載内容
    • 確定済みの各プロジェクト計画における「プロジェクトリソース計画」を反映させる
      • 例)「どのプロジェクトに対して、何月に何%稼働する」といった内容
    • 未確定の場合でも、確度が高い場合には記載する
      • 例えば、見積もり中で、ほぼほぼ問題なくOKであることが想像される場合など

役割分担

各メンバー

初期設定
日常作業

チームRep

Repの役割

PM

案件情報の追加・編集をお願いします。(「マスタ管理」から)
「リソース計画」を記入ください
見積提案中の案件のリソースの仮割当を行う事ができます

営業

マスター管理「会社」から顧客マスターを登録して下さい
見積提案中の案件のリソースの仮割当を行う事ができます
口頭受注のステータス変更

稼働率の定義

その人の1ヶ月あたりの想定稼働時間を100%として記載ください
ただし、1週間以上の休暇をとる場合は、(同じ100%とした場合に明らかに他のメンバーと異なるため)「休暇」案件を入力して、稼働工数に割り当てるようにしてください

「空き」の定義

「プロジェクトリソース計画」で計画された稼働が100%にならない場合「空き」があると定義する

その他

  • システムの操作・入力内容で困ったら以下のチャネルに相談する
  • #002_help_guild-稼働予測管理システム
  • 下記の1ヶ月前のルールの運用含め、稼働に関する調整はリソースマネジメント担当が行い、定期的にリソース会議で調整する
    • サーバーサイド: 阿部
    • iOS: 海保
    • Android; 静 高志
    • フロントエンド: 青木(基)

1ヶ月前ルール

  • 内容
    • PMは必ず、確定している1ヶ月先のリソース計画を各チームに確保依頼してください
    • メンバーはPMから「来月この作業をお願いしたい」と言われたとしても、1ヶ月前ルールに基づいて、原則は1ヶ月先に時期調整を行う事ができます
  • 目的
    • 最低限、常に1ヶ月先の予定が確定されている状態にする
  • 背景
    • パートナーさんとの契約延長も1ヶ月前である
    • 当月にリソース確保依頼があるからといって待機しておくと、仮にその確保依頼がなくなった時に空きが発生するリスクとなる
    • したがって、明確に確定した依頼ベースでしか動かないようにしていく必要がある

Guildで利用可能な案件一覧

Title内容
研究開発
研究開発プロジェクト計画のリソース計画に基づいて記載してください10%ルールの中でも、研究開発として事後でアウトプットをする活動の場合はこの名前を使ってください
jinji
カジュアル面談、採用業務、コーディングチェックなどで1ヶ月の稼働が16時間以上を占める人の場合
テックリード業務
将来起こる不足の事態に備えてリソース計画上、全体バッファとして必要な為、リードチームに限定して利用してください
研究開発業務2022_研修
オンボーディング、新人オリエン、社内研修などの受講
研究開発業務2022_プロジェクト学習
案件参加で必要となる学習工数 新卒や中途新人がプロフェッショナル1人月のパフォーマンスと比較した場合に不足する場合の調整工数 案件のスイッチングコスト
委員会活動_2022
オンボーディング実施、オリエン実施、研修など教える側の稼働含む 稼働が空いた場合に行う、チームのカイゼン活動や、予めまとまった工数が必要な委員会のチケットを実施する事が決まっている場合は、本案件にリソースを割り当ててください。グループ全体最適のために必要な冗長化、設計見直し、大幅なリファクタリング・リデザイン、経験学習が必要な職種の育成投資(例:リードエンジニア、リードクリエーター、アーキテクト、PMなどがあるが、それに限らない)など、目安として1人月を超える工数の稼働は委員会へのプロリクで決定をする(ZACコードもI委員会活動でつける)
休暇
長期休暇などで10%以上、アウトカムが控除される場合は、休暇の項目としてリソース計画を記入しておいて正確な出来高が可視化されるようにしてください
overhead(廃止)→ 研究開発業務2021_プロジェクト学習でつける
他案件支援として0.2など残り稼働で支援する場合・案件理解工数・マルチプロジェクトのスイッチングコスト工数などオーバーヘッドとして付随する間接工数が発生しているikuseiと同様の考え方でプロジェクト稼働ではなく「overhead」という調整工数としてGuildをつける事を可能とする(必要に応じて)実績については、ZACにおける「project_learning」など、プロジェクト毎の間接作業の売上項目につける

上記のマスターネームをプロジェクト名として利用して記載ください

FAQ

10%ルールは記載しても良いか?
空き稼働がある場合はどう入力すれば良いか?
空き稼働が予測されていた中で、実際に当月などに稼働が空いた場合はどのように行動すれば良いか?
過去の月の稼働実績は実態に合わせて修正する必要はありますか?
見積提案中のリソース計画はどのように反映すればいいですか?(2/16〜)
口頭発注の場合のGuildに反映できないか?
100%というのは160時間を意味しますでしょうか?
テックリードチームで横断してプロジェクト支援する場合のGuild/ZACの案件登録は?
採用活動に関わっている場合は、どのプロジェクトに割り当てれば良いでしょうか?
経営会議・取締役会ではどのようにGuildの情報が活用されていますか?
委員会稼働と案件稼働の優先度を教えてください?(5/10〜)