ki-ki-blog Written by ⚽kaz±

【業務依頼する時】責任区分を明確にしてからお願いしよう

WORK Working


こんにちは、カズキです。

自分は先日こういったツイートをしました。

https://twitter.com/kazuki_Walk/status/1317375588001181702
仕事で他者に作業依頼する時って、いかに作業内容や責任区分を明確にするかが大事ですよね。
だって、これを疎かにすると、
・それは〇〇さんがやると思っていた
・指示はここまでだと思っていた
みたいな感じで、自分の想定通りに作業が進まないことがあるので😅
自分はこれで納期前に痛い目に😅

仕事が忙しい時、プロジェクト外メンバに作業を手伝ってもらうことがあるかと思います。

その際、手伝ってもらえることが決まった時点で安心してしまっていませんか?

そうなると、作業の依頼の仕方が雑となってしまい、結果として後から自分が困ってしまいます。

自分はそれで失敗しました。 

なので、実体験をもとに、プロジェクト外メンバに、作業を依頼する際のポイントをお伝えいたします。

先に結論を言うと、何をどこまでやってもらうかを明確にしてからお願いする、ということです。

【理由】「お前がやると思っていた!」となるから

https://www.pakutaso.com/shared/img/thumb/DI_IMG_5780_TP_V.jpg

そもそも、自分が忙しいから、他者に作業をお願いするわけなので、自分としては、お願いした作業には、自分がやることは一切ない、と考えてしまいます。

では、仮に自分(依頼元)がこんな言い方で作業者(依頼先)に作業をお願いしたとしましょう。

  • 「A機能のソフトウェア実装をお願いします」

その際、作業者(依頼先)の意図としては、A機能に関する作業を全部お願いした、という認識でいるので、

「A機能のソフト作成動作確認まで行う(動作確認までしないと、ソフト作成完了とは言えないから)」

こう考えてしまいます。

でも、作業者(依頼先)側としては、こんな考え方もできてしまいます。

  1. 「設計方針の連絡があったら着手しよう(設計方針が決まらないとソフト実装できないので)」
  2. 「依頼内容は”コーディング”なので、動作確認は不要だろう」

こうなると、

  • 1の場合:最悪、作業自体が行われないまま納期が近づいてしまいます。
  • 2の場合:作業依頼後の成果物の認識違いが起こってしまいます。

【失敗事例】レビュー会に呼んだら不信感を持たれた

https://www.pakutaso.com/shared/img/thumb/SAYA072155409_TP_V.jpg

作業依頼して作ってもらった成果物に対するレビュー会を計画し、自分、作業者(作業依頼を受けた方)、上位者でレビューがありました。

その際、自分は成果物の説明を作業者(作業依頼を受けた方)に依頼し、レビュー会を進めたのですが、レビュー会が終わって数日後、他者からこんなことを聞きました。

「なんで俺(作業依頼を受けた方)が説明しないといけないのか!」

「レビュー会の場で説明するなんて聞いていない!」

このようなことをまわりに言っていたらしく、自分は不信感を持たれてしまいました。。。

要はお互いにこういう意識の違いがあったのです。

  • 自分(依頼元):説明は実際作業した人のほうがいいだろう
  • 作業者(依頼先):あくまで依頼は作業そのものだから、説明は依頼元がすべき

事前に「レビューの場で説明もお願いします」と整合していなかった自分がいけなかったのです。。。

RASIC表により、責任区分を明確化しよう

エンジニアの場合、何か仕事を他者に依頼する際、その内容は大きく分けて以下3つとなるかと思います。

  1. 決める:作業の仕方、成果物の定義を決める
  2. 作る:実際に作業する(コーディングする、ドキュメントを作るなど)
  3. 確かめる:動作チェックする、レビューを受ける

依頼先:社内の場合

上記3つ(決める、作る、確かめる)の内、どこまでをお願いするかを明確にし、その上で1~3の各々をどこまでやるのかを整合すればよいかと思います。

依頼先:社外の場合

依頼内容によりコストにも影響してきますので、作業着手前に詳細に責任区分を決めておく必要があります。

【対策】RASICを活用する

 RASICとは、下記の単語の頭文字をとった略であり、責任区分表のことです。

  • RはResponsible(実行責任)
  • AはApprove(承認)
  • SはSupport(支援)
  • IはInform(情報提供)
  • CはConsult(相談対応)
f:id:ki-ki-blog:20200104125037p:plain
RASICの例(プロジェクトマネージャ試験ドットコムから引用)

もちろん、毎回RASIC表を書く必要はない

責任分担を明確にする手法として、RASICを紹介しましたが、毎回こんなんかくのも正直めんどいですよね。。。

開発ってただでさえやることが多いのに、開発以外のことってあまり手がまわらないことも多いですし。

なので、RASIC表自体の作成は、社外へ作業依頼する時に特化してしまってもよいのかなと。

社内ですと、直接会話することである程度は解決できますので。

最後に

と、いうことで、今回は他者に作業依頼する際の心得について解説いたしました。

自分一人で仕事が完結することってなかなかないので、その場合は今回の心得を参考にして、うまいこと作業依頼しないとですね。

作業を依頼する際は、何をどこまでやってもらうかを明確にしてからお願いすることを忘れないようにしましょう。

今回は以上です。