直接作業と間接作業

はじめに

設計やプログラミングに限ったことでは無いが、作業は「直接作業」と「間接作業」に大別される。
スケジュールの遅れの多くは、間接作業に起因していると私は考えている。
間接作業は、見えにくいが大事な作業である。
それでは直接作業と間接作業の違いを見てみよう。

直接作業と間接作業の違い

分かり易くプログラムのクラスに例えるならば、直接作業は「メソッド(関数)」である。
一方の間接作業は「コンストラクタ(初期化処理)/デストラクタ(終了処理)」といった準備/終了作業を担う。
どちらが欠けても正しく動作はしない、表裏一体の関係なのだ。

1.直接作業

まずは直接作業である。
これは実際に「作業時間の対価として、お金を請求できる作業」と置き換えて良い。
具体的には、以下の通り「分かり易い」作業である。
また、アウトプット(成果物)についても明確になっている。
・設計書を作成する
・実装(プログラムを作成する)
・試験手順書を作成し、試験を実施する

2.間接作業

間接作業とは、作業の全貌が見えない「縁の下の力持ち」のような作業が多い。
具体的に以下のような作業である。
・プログラム実装時に設計書(電子ファイル)を探して確認する。
・開発端末の最新化(WindowsUpdate, 開発ツールのバージョンアップ等)
・仕様を確定させる会議の人員や開催日時の調整
・仕様変更の経緯や遡及を確認するため、過去メールを漁る
・作業効率化のバッチやシェルスクリプトを考える

間接作業の何が問題か

前項で列挙した作業を見て分かる通り、間接作業の大半は「直接作業の準備作業」に当たるのだ。
準備不足では、直接作業に影響が出ることは明白である。従って疎かにすることはできない。
あくまで個人的な体感として、直接作業時間に対して、間接作業はその30%くらいの時間が掛かる。
(直接作業を10時間とすると、間接作業は3時間の合計13時間掛かる)

しかも最大のデメリットは周囲から「何もしていない(サボっている)ように見えてしまう」ことだ。
正確には「何かしているようだが、よく分からない」といったところだろう。
特にPM・PLは進捗を「直接作業によって見える化された数字(実績)」しか見ない。

問題の解決策

間接作業に関する扱い(作業内容、作業時間)については、管理者と作業者で観点がことなる。
従って互いの歩み寄り(効率化、間接作業に掛かる時間の考慮)が不可欠である。

まとめ

・作業には「直接作業」と「間接作業」がある。
・間接作業は可視化しにくい作業が多い。
・見えにくい作業だからこそ、管理者とのコミュニケーションが大事になる。

独自理論

Posted by nihon-kawauso