タスクストップウォッチ

ワークログの作成・分析支援ツール

所属　奈良先端科学技術大学院大学氏名　笹野　仁

仮説：仕事のログをリアルタイムで共有することで問題を早期に解決できる？

タスクストップウォッチ-概要

タスク名と予定時間を取り組み直前に入力し全員で共有

● 予定時間を大幅に超過→問題が発生している可能性. 本システムでは問題の早期発見が可能. 相談,手助けなど早期の対応を補助.

● ログを分析し活用→時間のかかりやすい仕事や,未着手の仕事への取り組みにかかる時間を予想.

時間

スキル不足により時間超過　　＝無駄発生中！

時間の超過を早期に発見すれば仕事もスムーズ

タスクの情報を共有していれば・・・

対象とするユーザーと期待される効果対象：仕事の経験が少ない新入社員の方など効果：時間の見積もり・効率的に仕事に取り組む方法などを知らないために発生する時間の無駄の検知

本システムは情報を共有することでこれらの無駄の解決を目的とします.

無駄の原因

　個人で解決できない仕事は無駄の原因.

例：話し合いが必要なタスクで都合が合わない.

例：便利なライブラリ、知らずに自前で実装してしまった.

リアルタイムログを全員で共有する機能

おそらくほかに似たような機能を持つアプリはない(と思います.)

ログを活用し無駄を解決

　ログを後から見直し→不必要な作業の削減. 作業優先度を再検討.

　ログを分析→機械学習や自然言語処理の応用の可能性.

例：タスク名から時間が遅れそうなタスクを予想.

タスクストップウォッチ-概要

ユーザはタスクに取り組む直前にタスクを登録→slack上の指定のチャンネルで[予定時間] : [タスク名] : [コメント]の形式で発言するとbotが自動で発言を登録

ストップウォッチを停止させる場合は新しいタスクを登録→旧タスクのストップウォッチの停止と新タスクのストップウォッチの開始は同時に行われる

ストップウォッチが停止されない場合時間の超過が発生→超過分は表が赤くなる

集めたデータを分析し、仕事の効率化に貢献（予定）

アプリケーションのシステム構成図

(slack bot)

タスクストップウォッチ-構成

ユーザー(ローカルPC)

いまから30分コーディング動作確認する

30:コーディング :動作確認する60:企画スライド作成

一定時間ごとに取り組み状況を表で報告

いまから60分企画スライド作成

タスクストップウォッチ-期待される効果

・問題の周知、共有　問題・改善点の把握　迅速な問題解決　社員の能力の把握

・結果の分析　ログをもとに業務を見直し　タスクにかかる時間の予測　→機械学習・自然言語処理への応用　　

機械学習によるサービスの提供にはまず役に立ちそうな場面（＝データ）が必要　→今回のインターンでの取り組みのコンセプトはまずユーザからなるべく少な　い負担でデータを集めれるシステムの作成.

システムを社員の皆様に実際に利用してもらい、システムの使用感を評価していただきました.

評価項目は以下の３つ

● 使いやすさ● 役に立つと思えるかどうか● これから使おうと思うかどうか

評価指標

デモ

https://github.com/SSN817/TIS-internship

デモ

https://github.com/SSN817/TIS-internship

実験結果

使いやすさはどうでしたか？ このシステムは業務の改善に

役立つと思いますか？

このシステムを今後使いたいと

思いましたか？

実際に社員の方に利用していただき、使用感に関してアンケートしました.

実験結果

■仕事を進め方を見直す機会になった

■何にどれだけ使ったのかを可視化することで、行動の改善につなげられるデータを取れたのは良いと思う。課題としては、以下の点があげられる。

□・入力インターフェースの改善

□・チャットボットでなければいけない理由

■効果があるとはまだなんとも言えない。でも、みんなの状況が図で見られるのは良かった。

■Slackを見ていない人への対応が課題と思います。

■設定した時間内にタスクが終わっていないようだったら、「調子どう？」みたいに聞きに行ったらいいと思う（現在の自分の進捗を確認するため）

■【良い点】

□・一目で予定から遅延しているの人がわかる（赤いゾーンが多い人は遅延している）

□・人に状況を強制的に見られることによる、中だるみがなくなる？？

□□【疑問点・悪い点・改善点】

□・入力されていてもフォローが入るかどうかは周囲の人次第

□　　→今回の本丸はココであったと思うので、何故フォローが入らなかったのか検討が必要。

□・任意のタイミングで確認図を見ることができるとよかった

□・入力周りの改善（入力補助、編集・削除機能）

□・予定を場当たり的に変更していると、一見問題がないように見えてもまずいケースがありそう。

□　　→60:ある画面のプログラミング

□　　→15:サーバーのロジック PG□　　→20:フロントエンドの PG□　　　⇛予定は 60分でプログラミング予定だったが、実際は 95分かかっている

ご意見がありましたらご自由にご記入ください

考察

・企画、実装、評価までを最低現実行できた。

・うっかりミス大事なものを紛失する.gitに公開しちゃいけない情報を出してしまう.

・時間の管理時間配分を誤り、締め切りに合わせて無理に仕事をする状態になった.

・相談を渋る疑問や問題が発生した場合は１時間は最低でも考えていた.

・技術的な知識の不足webアプリ、linuxに関する知識がかなり不足.

・ミスに一層の注意を払う再発防止策を参考にする.

・すぐに相談する３０分考えてわからないなら相談.

・時間の管理大事なことは何かを考える。重要度の高いものから順に取り掛かる.

・勉強をする今回の取り組みを自分１人で行えるようにする.

Keep Problem Try

やるべきことは100分の1にできる全てはイシュー(ryに書いてある！