見出し画像

TeamSpiritで工数管理を精緻化したい

Salesforceを利用しているのであれば勤怠管理としてTeamSpiritは強力なパッケージかと思います。またSalesforceを使っているのであれば、商談やプロジェクトなど何かしら企業活動に関わるデータを管理しているのではないかと推測します。工数管理の精緻化はいろいろな側面から求められる課題かと思います。今回は過去に私が実装したSalesforceとTeamSpiritの標準機能を使い、かつノーコードで実装した方法を解説します。

※執筆時点でTeamSpiritの環境がないため、記憶を元に記述しておりますのでその点、ご容赦ください。

コンセプトはプロジェクトベースで工数管理したい?じゃぁプロジェクトの数だけ工数管理のレコードを自動で作ってやんよ!!です。

前提条件

・Salesforceに何かしらプロジェクトなど工数をつける元を管理するオブジェクトがあること
(商談などでも可、ここでは仮にプロジェクトとします。)

実装の概要

プロジェクトが開始されると、勤怠ジョブレコードをプロセスビルダーで自動で作成し、ユーザーが割り当てられる状態にする。
オブジェクトにカスタム項目の実装とプロセスビルダーの実装を行う。

画像1

※補足

勤怠ジョブオブジェクトとは聞き慣れない言葉かと思いますが、TeamSpiritで工数をつけるもととなるジョブを管理をするオブジェクトになります。

下記の簡易マニュアルのP.33~説明されている作業で実際にレコードが格納されるオブジェクトです。

勤怠ジョブレコードが作成されることでユーザーが工数をつけることが可能になります。ユーザーに紐付いて作成されたレコードは勤怠ワークというオブジェクトに格納されます。

プロジェクトオブジェクトの実装

管理したい項目は多々あると思いますが、下記の項目は使う項目となるので作成してください。

・プロジェクト名
・プロジェクトコード(自動採番が望ましい)
・取引先(参照型、なくても可)
・プロジェクト開始日(日付型)※レイアウトで必須にしておくといい
・プロジェクト終了日(日付型)※レイアウトで必須にしておくといい
・勤怠ジョブ(参照型、参照先は勤怠ジョブ)

プロジェクトの予実を見るという意味では、プロジェクト開始予定日、終了予定日、会計と絡ませるなら、請求予定日、計上予定日、入金予定日、計上方法などあるといいですが、それは別の話なので、まずは上記を作成します。

勤怠ジョブオブジェクトの実装

このオブジェクトにカスタム項目を1つだけ作成します。
(TeamSpiritの管理画面ではなく、他のオブジェクトと同様にSalesforceのオブジェクトを編集します)

・プロジェクト(参照関係、参照先はプロジェクト)

プロセスビルダーの実装

処理としては概要でにもありましたが3本作成します(プロセスビルダーの適切な書き方をすると2本で処理できますが便宜上、わかりやすく3本とします)。

・プロジェクトと対になる勤怠ジョブを作成するプロセスビルダー
・プロジェクトの更新に合わせて勤怠ジョブを更新するプロセスビルダー
・プロジェクトに勤怠ジョブ自身のIDを返すプロセスビルダー

勤怠ジョブ自身のIDを返却するプロセスビルダーを実装するのは、勤怠ジョブを更新する際に更新先を特定するために作成します。

勤怠ジョブを作成するプロセスビルダー

画像2

基本的には上図の項目のプロジェクトオブジェクトの項目を勤怠ジョブの対応する項目にわたすプロセスビルダーを作成すればOKです。ただし終了日については、addmonths関数などを使いプロジェクト終了日から3ヶ月程度の日付(会社で定めている標準的な瑕疵担保期間が終了する日付)を勤怠ジョブの終了日に渡すようにしてください。

意図としては、勤怠ジョブの仕様で、設定した終了日以降は工数をつけられないため、瑕疵担保期間を考慮するとこのような設定が必要だったからです。扱っている商材や契約形態によって設定は異なりますので、必要あればプロジェクトオブジェクトに請負なのか準委任契約など契約の種別を管理する項目を設け、その値により入力する値を変更させてもよいかと思います。

プロジェクトの更新に合わせて勤怠ジョブを更新するプロセスビルダー

残念ながら予定通り終わらず遅延するプロジェクトはあります。プロジェクトオブジェクトの終了日が変更されたら、あわせて勤怠ジョブの終了日を更新するプロセスビルダーを組みます。条件としてはプロジェクト終了日が変更されたを最低限考慮しておけば問題ないかと思います。

※瑕疵担保期間中の対応であるにも関わらずプロジェクト期間が延長されたと認識して終了日を伸ばしてしまう人もいるので、これもプロジェクトのステータスの値を完了に変更したら、終了日の変更はできない、プロジェクトのステータスの値も完了から戻せなくするなど、ひと手間かけておくとより精緻にとれるようになるかと思います。

プロジェクトに勤怠ジョブ自身のIDを返すプロセスビルダー

これは、勤怠ジョブが作成されたら、勤怠ジョブのプロジェクト項目に入力されたレコードに対して、自身のIDをプロジェクトの勤怠ジョブに返却するよう記述すればよいです。(お互いに参照関係で相互リンクしている状態にしておかないと、更新のプロセスビルダーがうまく動かない)
これは勤怠ジョブ作成時のみ起動すれば問題ありません。

メリット

勤怠ジョブは一般ユーザーに編集して欲しくない が 勤怠ジョブを随時手動で作成、更新するには運用負荷が高いという問題を解消できます。実際にはユーザーにオブジェクトの編集権限があるのですが、そのことを意識外におくことができます。

ユーザーも通常のプロジェクト更新活動を行えば、自動で勤怠ジョブも更新されるので便利。

レポートでプロジェクトごとの工数が一覧化できる!

デメリット

プロジェクトの数が多い場合検索性が大きく下がる。(幸い自分の場合はプロジェクトコードでプロジェクトを特定して管理する文化があったので、ここはプロジェクトコードで検索してください!の一点で回避した)

適当に工数をつけるユーザーがいるとプロジェクトの収支がおかしくなる。(こればっかりはどうしようもできない)

プロジェクトを誤作成などして削除した場合、勤怠ジョブが宙ぶらりんになってしまいます。このような勤怠ジョブに工数がついてしまい、手作業で修正することがあります。これは私が実装したときにはなかった機能なのですが、削除時のフローをプロジェクトに組んでおけば回避できる問題かもしれません。

まとめ

ざくっとした概要の説明になってしまいましたが、考えるヒントにはなったかと思います。ノーコードでもちょっとした工夫で業務は劇的に改善できます。TeasmSpiritさんの回し者ではありませんが、TSさんのサポートサイト、TScircleにはドキュメントが豊富にあります。承認申請の作り込みなどは、本家Salesforceよりわかりやすいくらいなので、TeamSpiritは使ってるけど、Salesforceはあんまり・・・という方はTScircleを覗いてみるといいですよ。実はレポートのテンプレートなどもおいてあるので、人事労務が見るものと敬遠せずにぜひこれからSalesforceを使っていきたいというAdminの方はご参考にしてください!やろうSalesforce!

この記事が気に入ったらサポートをしてみませんか?