3
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

日々の作業の進め方について

3
Last updated at Posted at 2023-02-16

作業の進め方について、職場で色々教えて貰ったので、そのことを記事に書きます。

前提

作業を進める前の「やるべきことの洗い出し」を、以下手順で分割します。

 1.タスクの洗い出しと、優先順位を決める
 2.1で洗い出したタスクの見積
 3.2をINPUTに、何をいつまでにやるかを決める(マストと目標の設定)

手順1は、業務の全体像を把握できている人や、実務経験がある人でないと、
中々難しいです。なので、今回は手順2と3をメインに説明します。
また、対象プロジェクトは従来のウォータフォール型とします。

1.タスクの洗い出しと、優先順位を決める

 タスクの洗い出しは、WBS、TODOリスト、メールやチャット等の履歴、個人メモ等をINPUTに、洗い出します。
そして、洗い出したINPUTに優先順位をつけます。
優先順位は、洗い出したINPUTを意思決定のフレームワークに当てはめてたりして決めるといいかも?

◆意思決定のフレームワークの例
 ・MoSCoW法
 ・Kano Model
 ・意思決定マトリクス
 ・緊急度・重要度のマトリクス

自分は、優先順位の付け方はまだ慣れていないので、有識者とすり合わせを行い
問題ないか見て、優先順位を決めます。

2.1で洗い出したタスクの見積

タスクを細かい作業に分割する

洗い出したタスクを、見積のために、更に細かい作業に分割します。
各作業は、WBSのワークパッケージ、もしくはアクティビティレベルを
さらに細かい粒度に分解したイメージになります。
例として、『メンバの一人が、今日は単体テストのタスクを予定している』
という場合、以下のように整理できます。

例)WBSのアクティビティが『機能Aのテスト設計書作成』の場合
 1. テストの目的を整理するためのINPUT集め
 2. テストの目的とゴールを設定
 3. テストの観点の整理
 4. ★チーム内の有識者と、2・3で整理した内容を認識合わせ
 5. テストケースの洗い出し
 6. テストデータの設計
 7. ★チーム内の有識者と、5・6で整理した内容を認識合わせ
 8. テスト設計書作成①(観点用のシートを一部作成)
 9. テスト設計書作成②(テストケース用のシートを一部作成)
 10.★チーム内の有識者と、8・9の内容を認識合わせ
 11.テスト設計書作成③(①、②の内容で他も作成していく)
 12.自己レビュー
 13.内部レビュー
 14.★チーム内の有識者と、内部指摘の内容を認識合わせ
 15.内部レビュー指摘対応
 16.顧客レビュー
 15.★チーム内の有識者と、顧客指摘の内容を認識合わせ
 16.顧客レビュー指摘対応
 17.顧客提出

補足:
※上記『機能Aのテスト設計書作成』は、スコープを設計書作成〜顧客提出までとしています。
 各アクティビティのスコープは、作業前に有識者としっかり認識合わせします。
※自分は、まだ作業に慣れていないので、★印であるチームメンバとの認識合わせを
 意識的に入れて、作業の手戻りを少なくするようにしています。

見積もりの際のコツ

◆定量化を意識する

見積は、定量的な見積もりを意識して、客観的に見積もりの合計がわかる様に作成します。
例1:単体テスト設計書の定量化
  成果物:〇〇〇設計書.xlsx
   ・観点シート
     概要:テスト全体の観点をまとめたシート。
     要素:観点と機能の対応がわかる10×5のテストマップ表が1つ。
   ・テストケースシート
     概要:観点をもとに出したケース一覧シート。
     要素:観点/ケース番号/ケース名称/ケース詳細 をヘッダーに持つ一覧表が3つ。
   ・補足シート
     概要:特殊ケースの説明を行うシート。
     要素:補足説明の図が4つ。

例2:単体テスト結果の定量化
  成果物:〇〇〇結果.xlsx
   ・ケースNo.1のシート
     概要:ケースNo.1のテスト結果をまとめたシート。
     要素:■■■機能の画面のキャプチャが10〜20枚。
  ・テーブルデータシート
     概要:テストで使った生データの表
     要素:▲▲テーブル、●●テーブル、✗✗ビューのSELECT結果

◆バッファを入れる

各作業にはバッファを入れます。大体作業時間の15%の時間を見積もりに追加します。

◆休日・祝日、その他休業日を意識する

見落としがちですが、有識者やレビュー担当者が休みで、作業が進まないパターンも考えられます。
自分の作業に関わる人の休暇情報を、事前に確認しておきます。

3.2をINPUTに、何をいつまでにやるかを決める(マストと目標の設定)

一日または、半日単位で、『今日何をやるべきか、どこまで終わらせるか』のラインを明確にします。
上司への報告は、このラインを達成したか否か、または、達成できそうか否かの形式で報告します。

もし遅延した/している場合、以下の内容を上司に報告します。
 ・現在どのタスクをやっているか
 ・今朝に決めたマストの作業は完了できそうか
 ・どのタスクで遅れているか
 ・何が原因で遅れているか
 ・遅れによる他への影響はないか(後工程はどうなるか、調整は必要か)
  また、遅れによるリカバリーをどうするか

その他補足とか

◆ペース配分を意識する

手順3について、一日単位や半日単位でラインを設けていますが、遅れが積み重なった場合、
上司に報告しづらくなります。
また、何が原因で遅れたのかも忘れてしまったり、色々大変なので、遅れが出たらすぐに検知できるようにします。
具体的な方法として、今からやる作業が、15〜30分単位のペース配分がどれくらいか確認する方法です。
作業の見積は手順2で出しているので、それをベースに、「半分の時間ならここまで進んでいる。」
「そのさらに半分はここまで進んでいる」と、具体的にイメージしてから作業に入ります。

ペースが遅れそうな場合は、その時点で上司に報告して、遅延を最小限に抑えます。
その際の遅延報告は、手順3で挙げた形式で行います。

◆作業に時間がかかった箇所はマーカーする

作業する中で、時間がかかったものは、資料上に色を付けたり、別途メモ帳に残します。
朝会や夕会・進捗報告会などの、まとめて報告する場では、これを使ってスムーズに報告できるようにします。

◆マイルストーンを意識する

手順3の『今日何をやるべきか、どこまで終わらせるか』をさらに意識付けるために、
各案件のマイルストーンを確認します。
マイルストーンについては、以下の記事が参考になった(面白かった?)ので紹介します。

◆慣れないうちは、型に沿って進める

自分自身もまだこの方法に慣れていないので、まずは型に沿って進めます。
慣れてきたら、効率化で無駄なところを省いたりします。
最終的には、この手順を見ずに作業できるようにします。

まとめ

この手順書通り動けたら理想ですが、自分自身も、まだまだ出来ていないところが沢山あります。
まずは、この基本の型をしっかり身につけることを目標に日々仕事をしていきたいと思います。

3
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?