（永遠のβ版）
ステータス
過去の履歴
2019/9/9 ガイドライン ver0.9リリース
2020/7/9 ASDI委員会の案件を追記、また空いたときの動き方としての優先順位４として委員会活動を追記
2020/7/9
グループ全体最適のために必要な冗長化、設計見直し、大幅なリファクタリング・リデザインなどは委員会へのプロリクで決定をする（ZACコードもASDI委員会でつける）
稼働が空いた場合の優先順について整理、平準化という言葉を改めて整理した。（稼働）平準化と冗長化を特に区別できるようにした。
（業務）カイゼンというカタカナのカイゼンの中に、業務標準化・業務効率化・冗長化の３つを含める事にした
2020/10/16 Guildの口頭受注ステータスの変更を営業判断で実施できるようにした
2020/12/7 委員会での投資対象範囲として、経験学習を対象とする職種における育成投資を含む（例としてリードエンジニア、アーキテクト、PMがあるが、それに限らない）
2021/2/16 Guildにおいて見積提案中の案件のリソース計画入力およびシミュレーション機能がリリースされた
2021/9/8 研究開発業務2021_研修、プロジェクト学習を追加して、ikusei、overheadを廃止
2021/1/6 Guildの案件名2021の年号を2022に変更
背景
将来の稼働予測を元に受注や採用判断を行う必要がある
チーム毎およびグループ全体の稼働の最適を行う上で稼働状況が可視化される必要がある
Guildと呼ばれる社内リソース管理システムを構築した
ZACコード報告ガイドライン ver0.9は別のページに記載
Guildのガイドラインも必要になったので、Guild・リソースガイドラインとして名称変更
目的
将来の空き稼働の実態を可視化して受注や採用、リソース調整につなげるのがGuildの記載の目的です
リソース管理システム
記載ガイド
記載方針
当月を含む、将来のリソース計画の実態として最も確からしい数値を記載する
記載内容
確定済みの各プロジェクト計画における「プロジェクトリソース計画」を反映させる
例）「どのプロジェクトに対して、何月に何％稼働する」といった内容
未確定の場合でも、確度が高い場合には記載する
例えば、見積もり中で、ほぼほぼ問題なくOKであることが想像される場合など
役割分担
各メンバー
初期設定
Guild(上記URL)にログインできることを確認してください
ログインできない場合、Yumetami (社員API)にデータが登録されてない可能性がある）
ユーザー稼働計画が閲覧でき、自分の所属等が正しいかを確認する
同様にこちらに誤りがある場合は、Yumetami (社員API)に
こちらを参照ユーザー情報更新方法｜Guild
日常作業
原則的、案件のアサインを行いとなります（重要）
「メンバー工数の変更」を行うのはメンバー自身
一方で、混乱が無いように、あるいは作業効率の関係上、
PMが代理で行うことを妨げるものではありません
もちろん、アサイン決定の前には、チーム内やPMとの調整が入る事が多いので、結果としてメンバー自身以外の人が入力するという事は発生して良いです
PMにはアサイン権限はありません（お願いしかできません）ゆめみでは全員CEOとして、自身のアサイン権限を持つのは本人のみとなります
（参考）メンバーが更新を行った内容はPMにSlackで通知が行くようになっています
チームRep
Repの役割
チームのリソース調整担当として、グループ毎のリソース調整会議に参加ください
参加できない場合は、必ず代理で別の人に参加してもらってください
チーム毎の週次定例会議を開催してください
週次定例会議でメンバーの稼働状況を把握してください
PM
案件情報の追加・編集をお願いします。（「マスタ管理」から）
全て入力する必要はないですが、案件名・会社・種別・ステータスは必須となります
「リソース計画」を記入ください
リソース計画を入力・更新するのはPMの役割です
アサイン時の職種・職位についてはプロジェクトに合わせて任意にお願いします
この部分はまだルール化できてないので、運用しながら作っていきます。最低限・職種と工数だけちゃんとしてれば良いです
見積提案中の案件のリソースの仮割当を行う事ができます
参考）リソースマネジメント担当（ガイドライン） の役割とは
営業
マスター管理「会社」から顧客マスターを登録して下さい
見積提案中の案件のリソースの仮割当を行う事ができます
口頭受注のステータス変更
実質的に受注確度が８０％以上、口頭受注相当と判断される場合に、営業担当がプロリクを行う #340_sales_group 宛てに行い、その後、営業担当がGuildを操作して、口頭受注のステータス変更に行う
稼働率の定義
その人の１ヶ月あたりの想定稼働時間を１００％として記載ください
例えば、週３勤務の人は、通常と比較すると、６割稼働が少ないですが、週３勤務をした場合の月間稼働時間を１００％とします
ただし、１週間以上の休暇をとる場合は、（同じ１００％とした場合に明らかに他のメンバーと異なるため）「休暇」案件を入力して、稼働工数に割り当てるようにしてください
この操作は、メンバー自身で作業をしてください
こちらも参照 2020/03/12 Guild ニーズ別対応方法整理
「空き」の定義
「プロジェクトリソース計画」で計画された稼働が１００％にならない場合「空き」があると定義する
ただし上記プロジェクトは、顧客から受注した案件プロジェクトだけでなく、プロリクで確定された社内プロジェクトも含む
その他
システムの操作・入力内容で困ったら以下のチャネルに相談する
下記の1ヶ月前のルールの運用含め、稼働に関する調整はリソースマネジメント担当が行い、定期的にリソース会議で調整する
サーバーサイド： 阿部
iOS： 石垣
Android； 静
フロントエンド： 青木（基）
１ヶ月前ルール
内容
PMは必ず、確定している１ヶ月先のリソース計画を各チームに確保依頼してください
メンバーはPMから「来月この作業をお願いしたい」と言われたとしても、１ヶ月前ルールに基づいて、原則は１ヶ月先に時期調整を行う事ができます
目的
最低限、常に１ヶ月先の予定が確定されている状態にする
背景
パートナーさんとの契約延長も１ヶ月前である
当月にリソース確保依頼があるからといって待機しておくと、仮にその確保依頼がなくなった時に空きが発生するリスクとなる
したがって、明確に確定した依頼ベースでしか動かないようにしていく必要がある
上記のマスターネームをプロジェクト名として利用して記載ください
FAQ
１０％ルールは記載しても良いか？
１０％ルールというプロジェクト名を稼働予測の対象としてGuildに記載することは廃止とします
１０％ルールの中でも、①研究開発プロジェクト②マーケティング調査の活動に対しては記載可能です。「研究開発」「マーケティング調査」という名称をプロジェクト名として利用してください
１０％ルールのルールに沿って事後でアウトプットも必要となります
次に、１０％ルールの内容が、③自己啓発の場合は、１０％ルールについての活動を切り分けてGuildに記載をする必要はありません
例えば毎月１人月、Aというプロジェクトで稼働するというリソース計画の場合、Guildには「プロジェクトA：１００％」として記載してください
自己啓発を行う事によって、９０％の稼働で、本人に期待される１人月のアウトカムが安定して出せるのであれば、それは１００％として記載する事を意味するからです
空き稼働がある場合はどう入力すれば良いか？
将来の空き稼働の実態を把握して受注や採用につなげるのが、Guildの記載の目的です
したがって、将来の空き稼働が予測される場合も、空いたままにしておいてください
空き稼働が予測されていた中で、実際に当月などに稼働が空いた場合はどのように行動すれば良いか？
プロジェクトリソース計画における稼働では１００％にならない場合は「実際に稼働が空いた場合のあるべき動き方」に沿って進めてください
過去の月の稼働実績は実態に合わせて修正する必要はありますか？
必要ありません
Guildは（当月含む）将来の稼働予測を行うためのものです
実態の管理はZACで行います
見積提案中のリソース計画はどのように反映すればいいですか？（2/16〜）
見積提案中のステータスの案件も、リソース計画を入力可能になりました（2/16以降）
見積提案中も含めた稼働シミュレーション機能があるので、将来の稼働予測を行うことができます
見積提案中の稼働については、営業やPMが中心となって稼働の割り当てを行います。
理由としては、まだ提案中であり受注をしていないので実際の詳細の割当を考慮するというよりは、大枠として全く空いていないか、空いているかを判断するために仮の割当で構わない事があるからです
もちろん、見積提案中の案件の割当であったとしても、確度が実質的に高い稼働については、実際の割当を考慮する必要があったり、特定の技術や経験を要する場合も実態の割当てを考慮する必要はあります
いずれにしても仮割当をした上で、営業として辞退するかどうかの判断をする為の目的としては、本人による割当を待っていては判断できるタイミングが遅くなり目的が達成されないという事がある為、営業・PMが割り当てを行うとしています
この見積提案中の割当の際には、本人にSlack通知でアラートはいかないようになっています
口頭発注の場合のGuildに反映できないか？
口頭受注というステータスがあるので、案件ステータスを口頭受注に変更する形になります
口頭受注の場合についてはGuildの稼働に反映されます（口頭受注の内訳も表記されます）
１００％というのは１６０時間を意味しますでしょうか？
フレックス・ワークフルライフ制度のワークフルライフ制度の適用者の場合、月間稼働する時間ではなく、アウトカムが重要になりますので、必ずしも１６０時間は意味しないです
テックリードチームで横断してプロジェクト支援する場合のGuild/ZACの案件登録は？
各プロジェクトの案件名登録
プロジェクト計画上、レビューなどの為、テックリード・デザインリードなどのテックリード工数を用意している場合
テックリード業務で案件登録
事前にテックリード業務を行う事が計画できないで、その場の状況に応じて後方支援する場合
テックリードチームのコミッターは、その場の状況に応じて機動的に後方支援できるように、毎月１０〜３０％の範囲を目安としてGuildの案件登録を事前に行う事
ZACは間接業務_2022>テックリード業務 となります
採用活動に関わっている場合は、どのプロジェクトに割り当てれば良いでしょうか？
１ヶ月に１０％以上の稼働（１６時間）を行う場合
「jinji」 の案件をGuildで使ってください
例として、週３面接をコンスタントに行う人、コードレビューを週８件以上コンスタントに行う場合は１０％以上の稼働になる可能性がありますが、その場合はなるべく他の人と平準化をするべきというサインです
１０％未満の場合は、Guildの目的に沿うと記載は不要です
経営会議・取締役会ではどのようにGuildの情報が活用されていますか？
経営会議や取締役の議事録にあるように、全体の稼働率、稼働が特別に過不足する職種や育成工数などを定点観測しています
委員会稼働と案件稼働の優先度を教えてください？（5/10〜）
空き稼働時の動き方のFAQを参考にしてください