チームの稼働を可視化、管理したい

業務の稼働を可視化する際は、最初から一つ一つの細かな作業/手順に対して何時間かかるのか？を算出してはいけません。 まずは、全員の稼働状況を参照して、全体観を掴みましょう。 内訳は、以下を参考にして、割合を算出します。 ・業務に関すること(業務の遂行、オペレーション等) ・業務の改善活動に関すること(提案に関する時間、業務の改善に関する時間等) ・業務を管理すること(チームの状況把握、数値管理、MTG等) 業務の稼働を可視化する目的は様々ですが、この割合をまずは把握することで傾向が見えます。 例えば、チーム立ち上げ当初であれば、業務に全てのリソースを集中させていることが多く、業務に関することに比率が偏ります。 その後は、例えば業務を標準化させていくために可視化する、そのための改善時間を確保していく事が必要になります。 比率の目安は、別のコンテンツ「体制に必要な人数算出方法」にも記載していますが、全体の15%が改善に使えることが理想です。 まず稼働管理の第一歩は、このような大枠で整理をすることから始めてください。

人材要件の設定、見直し

人材要件はチームに配属されるメンバーに最低限必要なスキルや適性を定めたものです。 人材要件を定める理由は、チームメンバーや人事部門等の人員配置に関わる部署とでチームに求められるメンバー像を共有し、適切な人材配置を実現するためです。 人材要件の設定方法 人材要件は、業務の特性を考慮し、チームの一定要件に加えて各役割の必要条件を追加してください。 受入基準では主に次の3点「適性」「専門スキル」「ビジネススキル」を明示しましょう。 また受入基準に加えて配属されるメンバーが業務を通じて「どのような経験を得られるか」「どのようなキャリアに繋がるか」を明示すると良いです。 適性 業務特性と候補者の特性がマッチするかを判断する必要があります。 スピード、正確性、共感性など、どのようなことが求められるのか、チームの環境や業務特性によって、候補者に求められる適性は異なります。 特に変化対応が多い業務を進めていくには、柔軟性は重要な適正ポイントになります。 専門スキル 業務を遂行する上で必要な業務経験、専門スキルを第三者が見ても分かるように表記します。 　業務経験(業務内容や経験年数) 　専門スキル(保持資格や過去の成果) ビジネススキル ビジネススキルとは、一般的にビジネスパーソン/社会人として求められる素養のことを指します。以下に具体例を示します。 　コミュニケーションスキル 　リーダーシップ 　仕事に対する姿勢 　社会人としてのモラル 　社会人としての一般常識 人材要件を見直す際は、一定期間の稼働の実績と成果実績から、見直していきます。 例えば、日々・毎週の業務の中で冗長化を目的とした役割変更を行うことが多くあります。 この結果、当初は「スピード」が速い方が良いと想定されていた役割も、実際は「正確性」の高い方が、効率的に仕事が進んだ。 当初は「システムの知識」が必要と想定していたが、実際には知識が要求されるシーンは稀であった、などといった気づきを得ることが多くあります。 このような実績から、改めて要件を見直すとよいです。

面談や1on1を管理したい

プロジェクト、チームの生産性向上、ミッションビジョンバリューの伝達のためのコミュニケーション機会として、1on1や面談は定期的（最低隔週に1回30分程度）に実施してください。会話ではなく、対話・傾聴を意識しておこなってください。管理表はFMTを参考とされてください。日常の声かけなどでコミュニケーション量も担保することも十分に意識ください。 ※ブラウザでのExcelファイルのプレビューは仕様上1シートのみ表示となります。ダウンロードして確認ください。

ナレッジの背景や意味の共有について

チームで得たナレッジを関連ドキュメントに反映することで、チームメンバー全員がナレッジを反映し、たより良い仕事の進め方を実行することができるようになります。 一方ドキュメントに反映された時点では「なぜそうなったのか」「なぜそのやり方なのか」という理由までは反映されないことも多くあります。 純粋に決められた通りに間違いなく作業をすることを目的にするなら大きな問題はありませんが、そうではない場合には以下のような問題も生じます。 １つ目の問題は、状況が異なるケースに遭遇した際に行動ができなくなることです。 例えば他部門からの問い合わせ対応など、業務によっては、必ずしも毎回同じ作業を繰り返すというわけではないことも多くあります。 その場合、具体的な作業を細かく指定するのではなく、「考え方」や「ケース」をガイドする必要があるでしょう。 例えば、「手段Aと手段Bであれば、基本的に手段Aを優先するが、対応時間が大きく増える場合は、B案を優先する」などの考え方です。 2つ目の問題は、ドキュメントに記載されている以外のやり方の方が、自分にとって都合が良いと判断した場合に、別のやり方を選択してしまう可能性があるという問題です。 これは、そのやり方に至った背景、それ以外のやり方のデメリットを理解していないことから発生します。 チームとして大きな失敗をした直後、痛みを共有できているうちは問題ありませんが、時間が経ちその痛みを知らない人員に交代していくとこの問題の発生確率は上がります。 大きな事故を防ぐためなど、内容によっては、やり方そのものと併せて、「なぜそのやり方なのか」という背景を理解することも同じくらい大切になります。必ずドキュメントに反映しましょう。 これらの問題の防止策は、コミュニケーションによる共有が有効です。 このような意味、背景が重要なものは、それも併せてドキュメントに反映することが大事ですが、性質上どうしてもドキュメントへの反映ができない、ないしはそれだけでは足りない場合があります。 そういった場合は、口頭でも構いませんのでナレッジを伝える際に併せて伝えることや、時にそれらを目的とした共有会を開催する等も有効です。特に判断のための考え方等、ニュアンスの難しいものは逆にドキュメントには頼らず、コミュニケーションによる共有を徹底しても良いです。