メンバの業務のアサイメントの考え方

SESのプロジェクトから抜けてきたエンジニアを引き合いの案件に放り込むようなケースではなく、ビジネス、組織の体制づくり、エンジニアの育成の機会、動機付けを目的として。

エンジニアが非稼動だからと、どんな案件でも働いている方がいいだろうとエンジニアをプロジェクトにアサイメントするのはろくなことが起きない。そんなことを続けていたら、優秀なエンジニアから辞めてしまう。

今は採用もままならないくらいだから、エンジニアの引き合いも強いのだろう。体感的には10年以上、そんな感覚である。

エンジニアの業務へのアサイメントとは、プロジェクトなり自社の業務なりにエンジニアのリソースを割り当てるということである。リソースを割り当て、そこからエンジニアのリソースを予算に紐付けてコスト化をする。それだけで考えてしまうと、単に、非稼動を稼動させているだけである。

エンジニアを業務に付かせることでえられるのはコスト化だけではない。

担当事業の拡大
エンジニアのステップアップによる体制づくり
エンジニアのキャリアの伸長の機会づくり

もちろん、都合よく前述の項目のいずれかに該当するとは限らない。担当させたい業務とエンジニアの専門技術や伸長させたいスキル、アサインしたいロールとエンジニアの志向などパラメータは様々だ。

あらかた、アサイメントしたい業務とエンジニアがフィットすればいいが、フィットしなくてもその業務を誰かエンジニアがやらなけばならない理由があるとき、何かしらの策を考えなければならない。

建前や言い訳や、押し付けではなく。

いや、アサイメントのほとんどは押し付けかもしれないが。

そうした環境下で、マネージャは、エンジニアに対して動機付けをしなければならない。

その業務をすることで、エンジニアにどのような経験を与えられるのか。業務なので、事業貢献は当たり前である。そのための業務なのだから。

そうではなく、アサイメントするエンジニアがその業務をする価値を見出す。

自分は、アサイメントされた業務で何をえられるか、設定をするのはエンジニア自身でやれば良いと考えるが、それは自分の中での話である。ただ、そう思っている、というだけである。それを部下とはいえ、押し付けるものではない。共感してくれるなら良いのだが。こうした話は目標設定、OKRの中で話すが価値観に基づくものなので、そうそう広まるものでもない。

そうしたことも踏まえると、アサイメントするときに動機付けするのである。それをどう受け止めるかは、エンジニア次第であるけれど。