善意で手伝っても感謝されない

これは失敗談なのかもしれない。ただ、視点を変えて、組織の業務として捉えるとその選択肢しか他になかったので、どちらを選んでも何かしら棘が残る選択になるのかもしれない。

業務概要
メンバが担当している業務は1人でやっている。年間の活動計画の説明資料を作り、関係部署に説明し、実施してもらう。
アウトプット
その業務を分掌とした時点で、時間的に余裕がないなと感じた。それは、その時点での資料の主旨が理解できかねるものであったためだ。わざわざ担当者を集め『たったそれだけを伝えるのか』的な程度であったし、書かれている内容も感想文かポエムのようなものであった。
所感
資料を見せてもらい話を聞くと、どうまとめて良いのかわからないという。いやいや、1年以上この仕事やってきたんでしょう、新米エンジニアじゃないでしょう、何をすればいいかは決まっているし、それ自体は去年と変わらないでしょうと内心思ったのが正直なところ。
指示
これまで主体的にやってきたのであるから、継続的に主担当としてやって欲しいのでマイクロマネジメントのような事細かい指示はせず、目次の章立て程度の観点で整理をしなおしたらどうかとコメントするだけに留める。背景的には、担当業務をやり切らないと評価はされにくくなるためである。
進捗
暫くたって資料を見せてもらうと、この期間で変わったところはたったそれだけなのか、と驚く。実質、コンテンツとしては何も変わっていない。
日程
打ち合わせの日取りだけ決まっており、数日後、的なところまで迫っている。
対応
一言断った上で、選択肢の一つになればと、スライドをざっと作る。座学で一方的なモノにならないように設計した。参加者同士で会話し、課題に気づくように。
反応
端的に言えば、担当エンジニアはこの業務から身を引くような感じで仕事をするようになった。物言いとしては、裏方が好きなのだとか、いくつかのいいかをしていたが、作業の主体者であることを避けようとし始めた。場は何度かあったが説明は出だしだけで、あとはアンケート回収と次の場の日程調整だけしかやらなくなった。
反省
一言断っているが、それはこちらから進んで言った形になっている。見方を変えれば、介入された、仕事の成果にダメ出しをされた、と受け取ったのかもしれない。つまり、助けてくれてた、という状況になっていない。仕事なので感謝をされたいとかいうことは一切なく、純粋に数日後に迎える場で担当者の成果を手助けするためであったのだが、繰り返すと、目線を変えるとそうは思われない可能性があったということだ。想像力が足らないと言われればそれまでであるが、自分の優先順位と担当の困りごとの状態と当日の達成する内容とのバランスがあまりにも違いすぎた。
とは言え、場に参加される方々のリソースを無駄にするわけにもいかず、担当エンジニアが受けるダメ出し感を与えないようにするには、担当エンジニアから手伝って欲しいと言わせなければならない。他には担当エンジニアの作成したスライドに朱書きを入れる方法もあるがこれもマイクロマネジメントになるため、結果は同じだったろう。
さて、どうすればよかったのか。