仕事のゴールは目標を達成すること

改めて仕事とはなんだと考えた話です。

現在、他部署に異動するための引き継ぎ作業を実施していますが、引き継ぎ先の担当者(女性:45歳)と会話していて違和感を感じることがありました。
私はクライアントともやりとりしつつ、いくつかシステムを開発しているので、案件の状況共有、これからの見通しの話、それと既存システムの保守のための設計情報について引き継がなければなりません。
特にシステムについては1年間続いたプロジェクトなので複雑になっている部分もあるので、システム概要、処理フロー、各モジュールの処理詳細をまとめた上で説明し、あとは実際のプログラムを見てもらうことにしました。

後日、プログラムの内容がわからないので、プログラムの解説書を作ってくれという依頼がありました。たしかに内容が複雑になっているので、面倒だなとは思いつつも致し方ない部分もあるかと作成することにしました。

ここまでは仕方ないのですが、驚くべきところはこれに加えて、
「今後の修正依頼がくるとしたらどんな修正がくるのか。またその場合どこを修正するのか教えて欲しい」
と言われたので、これにはかなりびっくりしました。

来てもいない修正依頼を想像して考えて、それに対する修正方法および影響範囲を教えてくれということです。
まだ理解していないシステムの保守および改修をしてくれ、という話なので不安なのはわかります。ただ、だからといって私にはよくわからないのでそこらへんを考えてほしいと依頼するのは、仕事放棄以外のなにものでもないと直感的に思ってしまいました。それは実際に依頼がきたときにあなたが考える内容です。

それでは私が考えている仕事とはなんだという話ですが、目標に向かうための手段というか向かっている状態かと思います。
今回の場合では、既存のシステムについて、相手の要望を反映するというのが今後の担当者の仕事で、それを遂行している状態が仕事をしている状態になります。
私の想像にはなりますが、彼女の中ではきっと今後の相手の要望に答えるために、具体的な内容と方法について前任者の私にまとめてもらおうということです。

では、私はその仕事(=きてもいない改修の対応想定をまとめる)をした結果、彼女の目指す目標に達成するでしょうか?
当たり前ですが、Yesとはいえません。想定した改修が発生するかわからないからです。従って、彼女のゴールにはつながるかわかりません。彼女が少し安心するだけです。
というか、そもそも彼女を安心させることが私の仕事ではありません。「後任の担当者がクライアントの要望を応えられるように既存のシステムについて十分なインプットをすること」が私の仕事です。

彼女の立場で考えると、これをみれば全てわかるというドキュメントがほしいわけです。
クライアントから質問が飛んできてもここに答えが書いてあって、修正の依頼が来たら修正パターンに応じて対応マニュアルを参照すれば良い状態にしたいのです。いわゆる想定質問集および対応マニュアルです。
気持ちはなんとなくわかります。ただ一方でそれがあれば、あなたは必要ないという話なのです。取って代われる存在になってしまうわけです。それでいいのかという話です。

今後がとても心配です。彼女ではなくてクライアントのことです。
一方で、私はこれから彼女と一緒に仕事をすることがなくなって良かったと内心思っています。ゴールに向かわない無駄な作業をしなくて済むので。

ゴールを見据えた仕事を心がけていこうと改めて思いました、私も自戒を込めて。

この記事が気に入ったらサポートをしてみませんか?