ステータス
‣
- 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にはアサイン権限はありません（お願いしかできません）ゆめみでは全員CEOとして、自身のアサイン権限を持つのは本人のみとなります
- （参考）メンバーが更新を行った内容はPMにSlackで通知が行くようになっています
「メンバー工数の変更」を行うのはメンバー自身
PMが代理で行うことを妨げるものではありません
チームRep
‣
- チームのリソース調整担当として、グループ毎のリソース調整会議に参加ください
- 参加できない場合は、必ず代理で別の人に参加してもらってください
- チーム毎の週次定例会議を開催してください
- 週次定例会議でメンバーの稼働状況を把握してください
PM
‣
- 全て入力する必要はないですが、案件名・会社・種別・ステータスは必須となります
‣
- リソース計画を入力・更新するのはPMの役割です
- アサイン時の職種・職位についてはプロジェクトに合わせて任意にお願いします
- この部分はまだルール化できてないので、運用しながら作っていきます。最低限・職種と工数だけちゃんとしてれば良いです
‣
- 参考）リソースマネジメント担当（ガイドライン） の役割とは
営業
‣
‣
‣
- 実質的に受注確度が８０％以上、口頭受注相当と判断される場合に、営業担当がプロリクを行う #340_sales_group 宛てに行い、その後、営業担当がGuildを操作して、口頭受注のステータス変更に行う
稼働率の定義
‣
- 例えば、週３勤務の人は、通常と比較すると、６割稼働が少ないですが、週３勤務をした場合の月間稼働時間を１００％とします
‣
- この操作は、メンバー自身で作業をしてください
- こちらも参照 2020/03/12 Guild ニーズ別対応方法整理
「空き」の定義
‣
- ただし上記プロジェクトは、顧客から受注した案件プロジェクトだけでなく、プロリクで確定された社内プロジェクトも含む
その他
- システムの操作・入力内容で困ったら以下のチャネルに相談する
- #002_help_guild-稼働予測管理システム
- 下記の1ヶ月前のルールの運用含め、稼働に関する調整はリソースマネジメント担当が行い、定期的にリソース会議で調整する
- サーバーサイド： 阿部
- iOS： 海保
- Android； 静 高志
- フロントエンド： 青木（基）
１ヶ月前ルール
- 内容
- PMは必ず、確定している１ヶ月先のリソース計画を各チームに確保依頼してください
- メンバーはPMから「来月この作業をお願いしたい」と言われたとしても、１ヶ月前ルールに基づいて、原則は１ヶ月先に時期調整を行う事ができます
- 目的
- 最低限、常に１ヶ月先の予定が確定されている状態にする
- 背景
- パートナーさんとの契約延長も１ヶ月前である
- 当月にリソース確保依頼があるからといって待機しておくと、仮にその確保依頼がなくなった時に空きが発生するリスクとなる
- したがって、明確に確定した依頼ベースでしか動かないようにしていく必要がある
| Title | 内容 |
|---|---|
• 研究開発プロジェクト計画のリソース計画に基づいて記載してください
• １０％ルールの中でも、研究開発として事後でアウトプットをする活動の場合はこの名前を使ってください | |
カジュアル面談、採用業務、コーディングチェックなどで１ヶ月の稼働が１６時間以上を占める人の場合 | |
将来起こる不足の事態に備えてリソース計画上、全体バッファとして必要な為、リードチームに限定して利用してください | |
オンボーディング、新人オリエン、社内研修などの受講 | |
案件参加で必要となる学習工数
新卒や中途新人がプロフェッショナル１人月のパフォーマンスと比較した場合に不足する場合の調整工数
案件のスイッチングコスト | |
オンボーディング実施、オリエン実施、研修など教える側の稼働含む
稼働が空いた場合に行う、チームのカイゼン活動や、予めまとまった工数が必要な委員会のチケットを実施する事が決まっている場合は、本案件にリソースを割り当ててください。グループ全体最適のために必要な冗長化、設計見直し、大幅なリファクタリング・リデザイン、経験学習が必要な職種の育成投資（例：リードエンジニア、リードクリエーター、アーキテクト、PMなどがあるが、それに限らない）など、目安として１人月を超える工数の稼働は委員会へのプロリクで決定をする（ZACコードもI委員会活動でつける） | |
長期休暇などで１０％以上、アウトカムが控除される場合は、休暇の項目としてリソース計画を記入しておいて正確な出来高が可視化されるようにしてください | |
上記のマスターネームをプロジェクト名として利用して記載ください
FAQ
‣
- １０％ルールというプロジェクト名を稼働予測の対象としてGuildに記載することは廃止とします
- １０％ルールの中でも、①研究開発プロジェクト②マーケティング調査の活動に対しては記載可能です。「研究開発」「マーケティング調査」という名称をプロジェクト名として利用してください
- １０％ルールのルールに沿って事後でアウトプットも必要となります
- 次に、１０％ルールの内容が、③自己啓発の場合は、１０％ルールについての活動を切り分けてGuildに記載をする必要はありません
- 例えば毎月１人月、Aというプロジェクトで稼働するというリソース計画の場合、Guildには「プロジェクトA：１００％」として記載してください
- 自己啓発を行う事によって、９０％の稼働で、本人に期待される１人月のアウトカムが安定して出せるのであれば、それは１００％として記載する事を意味するからです
‣
- 将来の空き稼働の実態を把握して受注や採用につなげるのが、Guildの記載の目的です
- したがって、将来の空き稼働が予測される場合も、空いたままにしておいてください
‣
- プロジェクトリソース計画における稼働では１００％にならない場合は「実際に稼働が空いた場合のあるべき動き方」に沿って進めてください
‣
- 必要ありません
- Guildは（当月含む）将来の稼働予測を行うためのものです
- 実態の管理はZACで行います
‣
- 見積提案中のステータスの案件も、リソース計画を入力可能になりました（2/16以降）
- 見積提案中も含めた稼働シミュレーション機能があるので、将来の稼働予測を行うことができます
- 見積提案中の稼働については、営業やPMが中心となって稼働の割り当てを行います。
- 理由としては、まだ提案中であり受注をしていないので実際の詳細の割当を考慮するというよりは、大枠として全く空いていないか、空いているかを判断するために仮の割当で構わない事があるからです
- もちろん、見積提案中の案件の割当であったとしても、確度が実質的に高い稼働については、実際の割当を考慮する必要があったり、特定の技術や経験を要する場合も実態の割当てを考慮する必要はあります
- いずれにしても仮割当をした上で、営業として辞退するかどうかの判断をする為の目的としては、本人による割当を待っていては判断できるタイミングが遅くなり目的が達成されないという事がある為、営業・PMが割り当てを行うとしています
- この見積提案中の割当の際には、本人にSlack通知でアラートはいかないようになっています
‣
- 口頭受注というステータスがあるので、案件ステータスを口頭受注に変更する形になります
- 口頭受注の場合についてはGuildの稼働に反映されます（口頭受注の内訳も表記されます）
‣
- フレックス・ワークフルライフ制度のワークフルライフ制度の適用者の場合、月間稼働する時間ではなく、アウトカムが重要になりますので、必ずしも１６０時間は意味しないです
‣
- 各プロジェクトの案件名登録
- プロジェクト計画上、レビューなどの為、テックリード・デザインリードなどのテックリード工数を用意している場合
- テックリード業務で案件登録
- 事前にテックリード業務を行う事が計画できないで、その場の状況に応じて後方支援する場合
- テックリードチームのコミッターは、その場の状況に応じて機動的に後方支援できるように、毎月１０〜３０％の範囲を目安としてGuildの案件登録を事前に行う事
- ZACは間接業務_2022>テックリード業務 となります
‣
- １ヶ月に１０％以上の稼働（１６時間）を行う場合
- 「jinji」 の案件をGuildで使ってください
- 例として、週３面接をコンスタントに行う人、コードレビューを週８件以上コンスタントに行う場合は１０％以上の稼働になる可能性がありますが、その場合はなるべく他の人と平準化をするべきというサインです
- １０％未満の場合は、Guildの目的に沿うと記載は不要です
‣
- 経営会議や取締役の議事録にあるように、全体の稼働率、稼働が特別に過不足する職種や育成工数などを定点観測しています
‣
- 空き稼働時の動き方のFAQを参考にしてください
