はじめに

これはドリコムAdvent Calendar 2019 の9日目です。
8日目は尾﨑春菜さんによる、「年の瀬Photoshopスクリプト大掃除録」です。 本稿は、自分が6月から始めたタスク記録について話をしたいと思います。

自己紹介

こんにちは、DRIP部の福井です！
業務ではWebフロントエンジニアをやっています。 DRIPはDrecom Invention Project の略称で、ドリコムが発明を生み続けるためのプロジェクトです。

本稿は新卒1年目がタスク管理について奮闘したお話です。

困ったこと

「ゴミ箱のアイコンを表示する」というタスクをやろうとした時、アイコン表示するだけだったため、1時間ぐらいで終わるだろうと。
そんなふうに思っていた時期が私にもありました。 何も考えずに、タスクでやることを雑多に考えて〇〇時間で終わる。のような見積もりは多くの場合遅れていきます。 例えば、あるページにボタンを1つ追加するのに、「ボタンの配置場所を確認する。その後、ボタンの動作確認とCSS当ててスクリーンショットを取る。スクリーンショットをマージリクエストに貼って終わり！」と考えて「30分くらいだな。」というような感じです。 実際に作業してみると、
「追加するボタンはクリックされた後、APIへPOSTする処理をする。URLを確認するためにswaggerというサービスを立ち上げる。そしてPOSTするJSONの形式を確認してデータを準備する。POSTする処理を書き終えたら、ページ遷移をさせる処理を追加する。さらに、ボタンはCSSを使ってマウスオーバーのアニメーションをさせる必要がある。」
といった感じで、意外とやることが多いことに気付きます。 このような感じで想定外の作業が発生したり、単純に自分の力量を見誤っていたりして、見積もりは遅れます。 しかし、なぜ遅れていくのか大体の要因は思いつくものの、定量的にはわかりませんでした。 そこで、タスクの管理と記録をしていこうと思いました。

タスク管理始めました。

• これまでのタスク管理方法
• 新しいタスク管理と記録

の順で話を進めていきます。

これまでのタスク管理方法

元々タスクの管理は大学生の頃から少しやっていました。その時は以下のタスク管理ツールを使っていました。

• todoist
  • デビッド・アレンが提唱したGetting Things Done(GTD)という個人用ワークフローの管理手法を取り入れたタスク管理ツール。
  • わりと直近まで使ってた。
• toodledo
  • 無料で使えて、エクセルのようにタスクをリスト表示できるため、ぱっと見で把握しやすい。
  • todoistを使う前はこれを使っていた。
  • GTDを実践してみたくなったため、todoistへ移行した。
• Trello
  • カンバン方式のタスク管理ツール。
  • 共同作業用時にはお世話になった。
  • 個人タスク管理をするには向いてない。（自分としては優先度や、期限、重要度なんかでソートして、ぱっと見で把握したい）
• Mac カレンダー
  • タスク管理というかイベント管理で使っている。
  • 特定日に必ずやるものはカレンダーに書いてある。
  • 今でも現役です。

新しいタスク管理と記録

タスクの管理は付箋を使い、記録はExcelでおこなっています。 付箋を利用している理由は、タスク書き出し、並び替え、削除が簡単にでき、さらにデスクトップ画面に埋もれることがないため、常に全体を把握し続けることができます。また、色分けによって優先度や緊急度を表現することや、重ねることで、あるタスクをやる前に終わらせなければいけないタスクを表現するなど、様々な使い方ができるからです。 Excelを利用している理由は、1つのタスクに対してポイント（タスク間の相対的な大きさ）や想定時間、実際にかかった時間など、細かな記録を取りたいため。また、後々集計とかしたいな、という思惑があったためです。

どうやっているか

いろいろ試していて、最終的に次のようになりました。

1. 前日の作業を思い出しながら、当日のタスクを確認して付箋を書き出す。
2. 大きさをポイントで見積もる。あのタスクは1ポイント、このタスクは2倍大変そうだから2ポイントみたいな感じ。
3. 作業
4. 実際にかかった時間の記録と最初に決めたポイント見積もりが間違っていないかをチェックする。
5. なぜ想定がずれたのか。遅くなった理由、早く終わった理由を書き残す。

よかった点

• わかりやすい個人目標ができた
• 日々の業務が退屈しなくなった
• ゲーム感覚でこなせる
• 何が原因でずれるのか掴めてきた
• 振り返りによる知識定着がある

悪かった点

• 癖になってんだ。タスク記録とるの
  • 一日５個ぐらいのタスク記録をとって、さらに1日の総括と1週間の総括のまとめ集計していた。
  • 今思えば、目的（タスクの遅れる原因を探る）と手法（タスク記録を取る）が逆転していた。
• そんなに正確に記録取れない
  • 書いたコードのテストを回している間は別タスクやってたり、チャット巡回したりしている。さらに、別タスクの一部をやっていたりするため、正確に時間を区切れない。
• タスクに割り振るポイントの整合性がない
  • 自分で適当に決めているため、本当にそのタスクのポイント合ってるかわからない。
  • ポイント割り振りは元々スクラムの考えから取ってきているが、一人でやっているためポイント見積もりが主観的すぎる。
• タスク完了の定義を明確にしていなかった
  • ざっくりと頭には合ったが、一貫していたとは言えない。
  • タスク完了の定義が曖昧のため、開発速度が上がったかどうかも正確にはわからなくなっている。
  • タスクを書き出すときに、どこまでで終わりとするか明記すれば良かった（ex: マージリクエストを提出するまで、など）
• 記録の仕方を変更し過ぎた
  • 記録を取り始めてから、やり方を模索しながらやっていたため、縦断的な分析ができなくなっていた。
  • 必要だと思ったら記録の項目を増やしていたため、タスク記録自体が重荷になってきていた。

わかったこと

やったことのない作業と「調査系」タスクは見積もりできない

例えば初めてReduxを使ったコンポーネント作成をする時、見積もりをするためには全体の把握が必要です。しかし、作成したことがないので、どのくらいのコード量になるかわからず、また、Reduxそのものについても知識がないため、適当に書いても動かない上に、エラーに頭を悩ませて時間を消費することになります。 「調査系」タスクは、「〇〇の使い方について調べる」というタスクです。これも「知らないから調べている」わけであって、「知らないなら見積もりできない」ものです。 それでも見積もる必要があるので、タスク始める前にやったことのない作業を書き出して、どのくらいあるのか確認し、マージンを多めに取るようにしてます。

ちまちまとタスクをやると無駄

チマチマタスクは無駄が多いです。
タスクを切り替えるたびに、前回までにやっていた箇所を思い出して、頭を切り替え、必要ならアプリケーションを切り替える。できるなら、一気に一つのタスクをやった方が効率がいいです。 「このタスクは、日を跨いでちまちまやるタスクだな」と思ったら、分解できないか、一気にやれるタイミングを図るか考え直した方がいいと思いました。

依存関係にあるタスクを併走させると最悪

依存関係にあるタスクは併走するととんでもないことになります。
Aというタスクに依存したBというタスクがある時、Aのレビュー待ちをしている最中にBというタスクをやるとします。一見、併走させることで全体の完了時間が短くなるように感じますが、Aのタスクで変更が加わるとBの全部を書き直す可能性が出ます。 タスクに手をつける前に、依存関係にあるタスクが未完了かは、気をつけた方がいいと思いました。

まとめ

タスクがなぜ遅れていくのか、原因を知りたいため、タスクの記録をしました。Excelを使ってタスクの記録を行い、なぜ想定とずれてしまったのか、どんなタスクが想定とずれるのかを記録していきました。 想定の難しいタスクの発見や、タスクへの取り組み方の試行錯誤をすることで、どうして想定がずれていくのか、どうしたら良いかを考えることができました。 今は、1タスクごとに記録を取っていると時間がかかってしまうため、1日をまとめて記録を取るようにしました。 どんなタスクにつまづくのかわかってきたため、タスクを切り出す時は、「やったことのない作業」「依存タスク」「完了条件（ちまちまタスクにならないか確認のため）」に気をつけて付箋で管理をしています。 今後も今回のことで得た知見を活かして行こうと思います。

余談

どんなタスクにつまづきやすかったか？

技術的に細々した話になるため、余談にまとめておきます。

• fetch系作業
  • APIとの連携を取る処理。
  • 動作確認が面倒だったり、非同期処理している処理を追うのが意外と面倒。
  • なぜか毎回エラー吐く
• Reduxを使う作業
  • Reduxを使うとactionとreducerを用意して、コンポーネントにもReduxを使うためのコードを用意しないといけない。
  • 難しいわけじゃないけどコード量が一気に増える
• 機能コピー作業
  • 例えば、あるページにある「ページング機能」を別のページにも適用したいって時
  • コピペ作業で終わればいいが、大抵はそのページに依存しているコードであることが多く、必要なら機能そのものをモジュール化する作業も発生する
• ライブラリ追加
  • yarnで入れるだけ、import書くだけとか思ってた。実際は使い方を調べたり、ちょっとコード書いて動作確認したりする必要がある。
• css
  • 要素にスタイルを当てるだけだと思っていた。
  • ブラウザによって動作が異なったり、動作端末で動作しないプロパティを使っていないかチェックする必要があった。
  • あるプロパティを設定していないと機能しないプロパティが存在することを知らずに、なぜ動かないのかわからずに時間を浪費した。

取っていた記録について

• 日付
  • 何日に取り組んだか
• 分類
  • 大まかな分類。ex: issue番号, 1on1シート, 会議準備
• 属性
  • そのタスクの作業を端的に表す。3つまで。ex: 調査,作業,MR修正,React,コピペ
  • どんな属性をもつタスクが想定とずれるのか、時間がかかるのかを知るために記録をつけていた
  • この項目のおかげで、fetch系やRedux系は時間がかかるんだなと気づく
• タスク名
  • ざっくりとタスクに名前をつける ex: 全タスクをissue登録する, GridLayoutについて調べる, ヘッダー部の固定
  • あとで思い出すために記録
• ポイント
  • そのタスクの大きさを書く。とあるタスクが3ポイントならこのタスクは5ポイントだな。みたいな感じで。
  • フィボナッチ数列という制約をつける 。（なんでかはスクラム本準拠）
• 最小時間、最大時間
  • そのタスクにかかる時間の最小時間と最大時間を見積もる。
  • 最小時間から最大時間の間に収まれば良い。早すぎても遅すぎてもダメ
  • やったことのない作業が多く含まれるタスクは、最小時間と最大時間の開きが大きくなる
  • ポイントの大きいタスク も最小時間と最大時間の開きが大きくなる
  • 文字書くだけとか、確認するだけのタスクは、最小時間と最大時間の開きが小さくなる
• 修正ポイント
  • そのタスクが終わった後に書く。振り返ってみて最初に見積もったポイントがダメなら修正ポイントに書いておく。
  • なぜ修正が入ったかはコメントに記載する。
• 消費時間
  • そのタスクにかかった時間
  • 正確には取れないので、ざっくりと取る。
  • 15分、30分、45分、1時間、1.5時間、2時間、3時間のどれかを記入
• コメント
  • 反省文、感想文。

さいごに

明日は廣田洋平さんの記事です。 ドリコムでは一緒に働くメンバーを募集しています！ 募集一覧はコチラを御覧ください！