このエントリーをはてなブックマークに追加LINEで送る

5.3. 作業指示

ハッピィ・エンジニアリング表紙

 システム開発工数のうち、多くの無駄となっているものが作業のやり直しである。このことは誰もが納得しているだろう。日常的に行われるやり直し作業としては、ドキュメントの書き直しやプログラムのデバッグ作業などがある。

 

 これらのやり直し作業が発生する理由は技術者のスキルにだけあるのではない。根本的な理由は、以下の2者に分類される。

 

  • 作業者のスキルに合わせて指示を出していない
  • 作業指示自体が不明確である

 

号令、命令、訓令

 本来であれば、断片的な作業依頼ではなく、完結する一貫した作業を依頼し、責任感を持って仕事をしてもらいたいところである。しかし、一貫した作業を完結するスキルを持たないメンバに、責任のある仕事を任せるわけにはいかない。つまり、作業指示は、作業者の持つスキルに合わせて行うべきである。作業者のスキルに合わせて「号令」「命令」「訓令」を使い分けることが、やり直しを避けるポイントである。

 

● 号令

 「号令」とは、与える任務のみを明確にした作業指示である。「このドキュメントを5部コピーせよ」「この手順書の通りに操作してインストール作業をせよ」「障害票を印刷して、完了・未完了の件数を集計せよ」というような、手順が明確な作業指示である。単なる作業内容を示すのみで、その目的や意図は説明する必要はない。つまり、「号令」による指示は単純作業に限られる。

 

 当然のことながら、作業目的や前提条件が明確になっていないため、作業を完了できない場合が発生する。上記の例であれば、手順書に誤りがあればインストール作業は完了しない。作業を完結させるためのフォローは作業を指示する側の責任である。作業指示者は、作業が完了したか、何か理由があり作業が完了できなかったかを迅速に把握しなければならない。

 

 つまり、「号令」は、常に決まった前提条件の中で、決められた作業を指示通りにこなすワーカへの作業指示である。このような単純作業は、考える要素がないため、自主的に仕事ができるメンバには行うべきではない。「号令」は、「命令」で十分な成果を出せないメンバにのみ行うべきである。

 

● 命令

 「命令」とは、その作業目的を明確にしたうえで、その具体的な手順や方法を与える作業指示である。一般的な作業指示は「命令」に当たる。目的と手順を示すことで、部下は目的意識を持ったうえで作業をすることができる。この経験の積み重ねにより人は育つのである。きちんとした「命令」を行うポイントは後述する。

 

● 訓令

 「訓令」とは、その作業目的のみを明確にした作業指示である。つまり、方法や手順は作業者の裁量に任される。基本的には、リーダクラスのメンバに対してのみ通用する作業指示である。

 

 例えば、「次の開発プロジェクトに活用するために、今回のプロジェクトの問題点と改善案をまとめておいてほしい」というような指示が訓令である。「訓令」を与えられ、さらに部下に指示を出す際に、たいていの場合は「命令」に変換する必要があるだろう。

 

命令のポイント

 作業のやり直しは、どのような成果物を作成するのかについて、指示する者と指示を受ける者の両者が共通の認識を持たないために発生することが多い。つまり、プロジェクトマネージャやリーダの指示の出し方に大きな問題がある。頻繁に発生する間違った指示としては、以下のようなものがある。

 

  • 要件が確定していない段階での指示
  • 「とりあえず動くものを」というようなプロセスを無視した指示
  • 「これ作っておいて」程度の具体性のない指示

 

 要件が確定していないのであれば、要件を調整し仕様を固めることが先決である。そもそも、要件の調整すらしていないものから利用可能なものを生み出すことは不可能である。

 

 特にプログラム開発上では「とりあえず動くものを」という要求は非常に多い。しかし、システム開発は概要から詳細に落としていく作業である。要求から設計、個々のプログラムの仕様に詳細化されていく。この詳細化作業は、開発対象を明確にするうえで重要なものであり、仕様書の作成はモノ作りに優先するべきである。プログラムが完成しても、それが要求にマッチしたものであることを保証するために、後からプログラムを読み直す作業が発生するのは二度手間であろう。実際のモノ作りには、書類を作成するのと同等の思考が働く。それを書式化するだけの時間を省略することに、大きな意味はない。

 

 これらの間違った指示が一度に発生することもある。要件が確定していないものを、顧客との調整なしにプログラミングさせるような場合である。指示を受けたほうは、情報の不足が問題であるのに、自分の理解力が足りないと勘違いして、解決しない問題に長い時間をかけて考え続けてしまう。結果は見るまでもない。見切り発車して開発した場合には、「使えない」プログラムが残るだけである。最初からやり直したほうが早い場合が多いが、断片的な情報を基に修正し続けるような不毛な作業に陥りがちである。

 

 作業を具体的に指示するためには、言うまでもなく、5W1Hが具体的になっていることが必要である。

 

  1. What なに(作成対象)
  2. 何を作成するのか、対象は誰なのかを明確にする

  3. Why なぜ(目的)
  4. 作成する目的を明確にする

  5. Where どこ(前提)
  6. 前提となる情報や条件を明確にする

  7. How どのように(解決手段)
  8. 前提からゴールに至るまでの作業プロセスを明確にする

  9. When いつまでに(実現時期)
  10. テストやレビュータイミングなどをふまえてスケジュールを明確にする

  11. Who 誰が(実施体制)
  12. 担当者を明確にする

 

 ある程度の経験を持った技術者に作業を依頼する場合、この中で重要なことは、その作業が持つ目的をしっかりと伝えることである。ある程度の経験があれば、その作業のやり方がわからないということは少ない。対象と目的が明確になっていれば、無駄なやり直し作業は必然的に少なくなるだろう。

 

 さらに、その指示を具体的にするために、作業指示書を添えて指示することが望ましい。双方が作成するものに対する認識を高め、作り直さなくて済むようにするためである。つまり、作業指示書は、指示者が作成する必要はなく、指示を受ける者が作成し、作業指示者が承認する形式を取ることも可能である。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

5.3. 作業指示 ハッピィ・エンジニアリング関連ページ

5.1. 検討と意思決定
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
5.2. 共感、納得、同意
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング