Pleasanterの期限付きテーブルでタスク・工数管理を快適化してみた！
つたない文章・長文ではございますが、何卒ご容赦ください。
また、本記事に掲載しておりますキャプチャが少しぼやけており見えにくいことをあらかじめご了承ください。
はじめに
私はSI案件にて、とある製造業のお客様とお仕事をさせていただいております。開発当初から参画させていただき、現在は運用・保守を担当させていただいております。
運用・保守では課題管理として、毎日さまざまな課題が起票されるため、私自身のタスク管理が行き届いておりませんでした。さらに、SI案件に使える工数が決まっていますが、こちらの工数管理も同時にできておりませんでした(ちなみに、今期の目標です)。
そのため、今回の投稿内容にあるようにタスク管理＆工数管理をするためにPleasater(プリザンター)の期限付きテーブルに標準機能とJavaScriptを実装したテーブルを作成しました。
また、こちらのテーブルでは、ユーザの操作を最小限にできるような工夫を実現しています。これにより、時間をかけずに正確な予定工数の計算ができ、工数の予実差とタスクのスケジュールが可視化できました。
前提
本記事でご紹介する各テーブルには標準機能をいくつか利用しております。また、JavaScriptを使った実装も行っております。
各項目の説明に関しては、後述の「参考リンク」からご参照ください(Pleasanterのユーザマニュアルの各サイトに遷移します)。
テーブルの概要
キャプチャのように構成は下記のようになっております。
Entity
親テーブル：メインタスク管理
子テーブル：サブタスク管理
その他リンクテーブル：KPT
Relation
メインタスク管理：サブタスク管理 = 1：多
メインタスク管理：KPT = 1：1
サブタスク管理：KPT = 1：1
KPTは必ず存在するわけではありません。
各テーブルの概要(ステータス遷移に沿って説明します)
本テーブルの構成にした理由としては、ひとつの課題に対応するメインタスクがあり、メインタスクを完了させるためにいくつかのサブタスクで管理しようと考えたからです。なお、ひとつのサブタスクを完了させるためのサブタスクは考慮しておりません。
タスク起票時
メインタスク管理テーブル
新規作成画面
必須項目は「メインタスク」です。
項目入力後、画面下部の準備プロセスボタンをクリックします。
項目入力後
準備プロセス実行後、画面下部にリンクボタンサブタスク管理とKPTが表示されます。
準備プロセス実行後
これでメインタスク(メインタスク1)の起票が完了しました。これにより、メインタスクID(レコードID)が確定します。
サブタスク管理をクリックし、メインタスク1のサブタスク1を作成します。
サブタスク管理テーブル
サブタスク管理クリック後、先ほど起票したメインタスク1に紐づいた新規作成画面が開きます。
画面上部にあるタスクIDには、メインタスク1のレコードIDがリンクにより登録されています。
サブタスク管理クリック後
必須項目は「サブタスク名」と「開始予定」と「完了予定」です。
項目入力後、画面下部の作成ボタンをクリックします。
項目入力後
作成ボタンクリック後、リンクテーブルに先ほど作成したサブタスク1が登録されていることがわかります。
作成ボタンクリック後
同じ要領でサブタスク2を作成します。
サブタスク2作成後
各テーブル機能紹介：タスク起票時点
上記手順実施後(各タスクを起票後)、レコード上にはそれぞれ予定工数が記録されています。
メインタスク管理テーブル
タスク起票時、メインタスクレコードをのぞいてみると予定工数と実工数に「90」という数字が設定されていることがわかります。こちらはサーバスクリプトを利用し、メインタスク1のレコードに紐づくサブタスク1・2レコードの予定工数と実工数を集計し、メインタスク1の予定工数と実工数を登録します。
メインタスク1に紐づくサブタスク1・2を特定するために、サブタスク1・2にタスクID項目を設定し、こちらにメインタスク1のメインタスクIDを登録しています。
サブタスク管理テーブル：サブタスク1
サブタスク管理テーブルでは、サーバスクリプトで終了予定項目から開始予定項目を引き算し、分単位で予定工数項目と実工数項目に値を設定しています。
紐づいているメインタスク1を特定するためにタスクID項目にメインタスク1のメインタスクIDが設定されていることがわかります。
サブタスク管理テーブル：サブタスク2
各サブタスクレコードを特定するために、タスク明細ID項目を設定しています。
タスク明細ID項目では、タスクIDに自動採番を実装することで一意の数値が設定されます。
各テーブルの機能紹介：タスク着手開始
各タスクに着手する場合、作業開始プロセスボタンをクリックします。これにより、状況が実施中に遷移します。
メインタスク管理テーブル
作業開始プロセスボタンをクリックすると、状況が実施中となり、開始項目に作業開始プロセス実行時の日時が設定されます。
サブタスク管理テーブル：サブタスク1
こちらも同様に、作業開始プロセスボタンをクリックすることで、状況が実施中に、開始項目に作業開始プロセス実行時の日時が設定されます。
サブタスク管理テーブル；サブタスク2
各テーブルの機能紹介：レビュー時
もし、あるタスクに関して上司や先輩にレビューをお願いするときはレビュー実施プロセスボタンをクリックします。これにより、状況がレビューに遷移します。
こちらのプロセスをスキップして、完了プロセスを実行することも可能です。
サブタスク管理テーブル：サブタスク1
今回はサブタスク1に関して、レビュー依頼を出します。
各テーブルの機能紹介：タスク完了時
タスクが完了したら完了プロセスボタンをクリックします。これにより、状況が完了に遷移します。
サブタスク管理テーブル：サブタスク1
サブタスク1のレビューが完了したため、完了プロセスをクリックし、状況を完了に変更しました。ここで注目していただきたいのが、完了項目と実工数と予実差項目です。
完了項目はプロセスの標準機能でボタンをクリックした時点の日時を設定しております。実工数項目と予実差項目は完了項目から開始項目を引き算し、差を実工数とし分単位で実工数項目に設定しています。
メインタスク管理テーブル
現在のタスクの状況としては、サブタスク1は完了し、サブタスク2は実施中です。すべてのサブタスクが完了していないため、メインタスク1は実施中です。その状態でメインタスク1をのぞいてみると、実工数項目と予実差項目の値が変更されていることがわかります。
こちらは上記で記載したようにサーバスクリプトによって、各サブタスクから予定工数と予実差を集計し、実工数を計算しています。
解釈としては、現状予定工数が90分に対して、実工数が20分のため予実差が70分であると解釈されます。したがって、メインタスク1における残りの工数としては、70分であると解釈されます。
各テーブルの機能紹介：タスク不要時
ある理由からタスクが不要になった場合、不要プロセスボタンをクリックします。これにより、状況が不要に変更され、不要チェック項目にチェックがつきます。
サブタスク管理テーブル：サブタスク2
しかし、ここで問題が発生しました。実施中だったサブタスク2が必要なくなったのです。
メインタスク完了にはサブタスク2が必要だと見込んでおりましたが、必要ないことに気づきました。その時は不要プロセスをクリックし、状況を不要に変更し、不要チェック項目にチェックを付けます。
メインタスク管理テーブル
この状況でメインタスク1をのぞいてみましょう。
すると、不要になったサブタスク2はリンクテーブルから除外され、予定工数項目と実工数項目と予実差項目にはサブタスク1のみを対象に計算されていることがわかります。
各テーブルの機能紹介：タスク必要時
不要に設定したタスクが必要になった場合、必要プロセスボタンをクリックします。これにより、状況が未着手に変更され、不要チェック項目のチェックが外れます。
サブタスク管理テーブル：サブタスク2
運用上必要になる可能性があるため、必要プロセスを設定しています。先ほど、不要プロセスで不要チェック項目にチェックを入れましたが、今回は不要チェック項目のチェックを外します。
必要プロセスでは初期状態(状況が未着手)に設定されるため、再度作業開始プロセスをクリックします。
実際の運用では、不要にしたレコードは利用せず、新しく起票しなおします・・・(少し面倒ですが)
メインタスク管理テーブル
不要チェック項目にチェックが外れたことでメインタスク1のリンクテーブルにサブタスク2が復活しました。
もちろん、予定工数項目と実工数項目と予実差項目も再計算されます。
各テーブルの機能紹介：タスク完了時
サブタスク管理テーブル：サブタスク2
サブタスク2が完了しました。完了プロセスをクリックすることで、状況を完了に変更し、「実作業 > 完了」項目と「サマリ > 実工数」と「予実差」項目にそれぞれ値を設定します(こちらはサブタスク1の説明と同様です)。
サブタスク1では予実差+10分でタスクを完了することができましたが、サブタスク2は予実差-60分となっています。
メインタスク管理テーブル
メインタスク1をのぞいてみると、しっかり計算されて予実差が-50となっていることがわかります。
しかし、ここで気が付きました。サブタスク2に着手している最中にお昼休憩をとったことを。そのため、お昼休憩分(60分)調整しようと思います。
サブタスク管理テーブル：サブタスク2
再度サブタスク2を開き、調整項目にお昼休憩分の「-60」を設定し、更新ボタンをクリックします。
すると、実工数項目と予実差項目の各値が変更されました(お昼休憩分工数から差し引かれました)。
メインタスク管理テーブル
再度メインタスク1を開くとサブタスク2の各工数項目の値が修正された数値が反映されていることがわかります(予実差が+10となっています)。
すべてのサブタスクが完了したため、完了プロセスをクリックします。
課題
12月からこちらのテーブルを実際に用いて、工数計算や工数見積もりの精度を上げようと試みております。直近で追加したい機能としては下記2点があげられます。
- メインタスクレコードの開始予定項目と完了予定項目の自動設定
- 全サブタスクの予定工数・実工数・予実差の自動計算
メインタスクレコードの開始予定項目と完了予定項目の自動設定
こちらはサーバスクリプトで実装する予定です。
設計としては、メインタスクに紐づくサブタスクを特定し、サブタスクにある最初の開始予定項目の値をメインタスクの開始予定項目に、サブタスクにある最後の終了予定項目の値をメインタスクの終了予定項目に設定します。
こちらの機能はよりユーザの操作を減らすための実装となります。現在の仕様上メインタスクの開始予定項目と完了予定項目はサブタスクの最初の開始予定項目から最後の終了予定項目を基準に手動で設定しているため、こちらの機能を実装しより快適にタスク管理ができるようにします。
全サブタスクの予定工数・実工数・予実差の自動計算
こちらもサーバスクリプトで実装する予定です。
こちらはメインタスクの一覧テーブル実行します。選択されたメインタスクに紐づく全サブタスクを特定し、サブタスクにあるサマリ配下の各項目を集計し、自動計算します。
こちらの機能は対象の予定工数が既定工数を上回っていないかなどの調査に使います。また、最終的な実工数の計算などの計算を自動で行いたいため実装したいと考えました。
さいごに
いかがでしたでしょうか。アドベントカレンダーに掲載するということで、Pleasanterの期限付きテーブルを使って、タスク・工数管理の快適化を個人的に目指したテーブルのご紹介をさせていただきました。
機能はとても充実していると思いますが、実装しているためエンジニア向けになるかもしれません。
こちらの記事が好評でしたら、続編として、さらに詳細な設定や実装内容も公開させていただこうと思っております。
また、サーバスクリプトで実装している箇所等が標準機能で置き換えできる可能性もあります。