はじめに
船井総研デジタルはAzure推しなので、そういう技術系の記事が多いのですが、入社したばかりで勉強中の私はまだネタが溜まっていないため、前回に続きポエム寄りのお話です。
エンジニアのジレンマとして良く耳にする話に、「個人の生産性を上げてもチームの生産性に貢献できなければ頭打ちになってしまう」、「なので開発をやりたいのに経験を積むとマネジメントをさせられてしまう」というものがあります。
これらついての是非はいったん置いといて、「生産性」という言葉がバズワードっぽくなっている印象があるので、生産性を上げるとはどういうことなのか、マネジメントで本当に生産性が上がるのかを考えてみました。
エンジニアの生産性とは
生産性の定義を調べてみると、以下のような説明が見つかります。
- 物的生産性（アウトプット÷インプット）
- 付加価値生産性（利益÷コスト）
ざっくり言ってしまうと量ベースか金額ベースかということですね。
会社として目指すべきは付加価値生産性ですが、エンジニアはどの作業がどれだけ利益を生んだか切り分けるのが難しいため、物的生産性で評価することが多いと思います。
では物的生産性を上げるにはどうすればよいのでしょうか。
真っ先に思いつくのは、手を早くするという方法です。
ブラインドタッチができるようになる、IDEの操作や機能を覚える（入力サポート、ショートカットキーなど）、言語の仕様を把握する（文法、組み込み関数、ライブラリなど）といったことで、新人なら調べながら5日かかる作業が、ベテランなら1日で終わるなんてことも珍しくありません。
しかし、手を早くするというのは限度があり、いくら経験を積んでも100倍早くなったりはしません（今後はAIに作らせて整形やチューニングするといった方法で、格差が広がる可能性はありますが）
また、マネジメントで上げるというよりも、個人のスキルアップで上げる部分になります。
設計やアルゴリズム、インフラ構築などはどうでしょうか。
この部分は手の早さよりもできる／できないの差が大きく、新人が100日、もしくは100人で考えても解決できなかったものを、ベテラン1人が数時間で解いてしまうということは十分あり得ます。
倍率で言えば∞倍となりますが、知識や経験によるところが大きいため、こちらもマネジメントで簡単に上げられるものではありません。
というわけで、タイトルの結論に至ります。
上げるべきは生産性なのか
これで終わってしまったら身も蓋もないので、もう少し深掘りしてみましょう。
エンジニアの生産性は物的生産性を指すことが多いというのはわかりました。
では、以下のようなケースを考えてみてください。
| Ａさんは2時間の見積もりの作業を依頼されましたが、依頼内容の不明点を確認したり、連携先の仕様が決まるまでに7時間かかり、その後1時間かけて作業を完了しました。 |
|---|
8時間で2時間分の作業しかできなかったとも言えるし、1時間で2時間分の作業をこなせたとも言えます。
この場合、上げるべきなのはＡさんの生産性でしょうか。
仮にＡさんが生産性を倍にして30分で終わらせたとしても、かかった時間は7時間30分で、2時間の見積もりを大きく超過していることには変わりありません。
問題は、依頼内容がわかりづらい、仕様が決まっていないのに依頼した、手が動かせない時に他の作業を割り振れていない、といった部分であり、生産性を上げても解決しないことがわかると思います。
これらを解決するには、生産性ではなく、生産量という視点が必要となります。
生産性を上げるというのはあくまで手段の1つで、いくら生産性が高くても、生産できる時間が短かったら生産量はあまり上がりません。
このような時に、マネジメントの存在価値が出てきます。
エンジニアの手が止まらず、リソースが空かない状態をできるだけ維持すれば、生産性が上がらなくても生産量を上げられます。
生産量を上げるマネジメント
というわけで改めて、生産性ではなく生産量を上げるマネジメントのために、エンジニアがどのような時に手が止まってしまうのか、リソースが空いてしまうのかを整理し、それを排除する方法を考えてみました。
-
何をすればいいか、どこから着手すればいいかわからない
→ ゴールや成果物、期限、優先順位、エンジニアがどこまで判断してよいかなどを明確にして依頼する
→ 手順書やドキュメントを作成、整理する
→ スキルや適性がマッチしているか、やれそうかをエンジニアと認識合わせする -
業務に直接関係しない、雑務のような作業が多い
→ 本当に必要な作業なのか、自動化やツールで負担が軽減できないか検討する
→ マイクロマネジメントや過干渉になっていないか見直す
→ お客様や他部署からの窓口を一本化する（エンジニアに直接依頼させない、無茶振りを止めたり調整する） -
認識の食い違いや意図が伝わらず、何度もやりとりが発生する
→ お客様や他部署からの窓口を一本化する（相手からの要求をわかりやすくエンジニアに伝える、エンジニアからの確認や報告をわかりやすく相手に伝える）
→ 直接やりとりして問題ないと判断できた場合は、エンジニアに委譲する（自分がボトルネックにならない）
→ やりとりに使用するチャンネルを一本化する（メール、チャットツール、プロジェクト管理ツールなど分散してしまうと、話や仕様が追いづらくなるため） -
外部要因のボトルネックで待機が発生してしまう
→ ボトルネックになりそうな箇所と、それがいつまでに必要かを把握し、間に合うように調整する（お客様相手の場合、間に合わなければ納期や工数に影響すると認識してもらう）
→ 待機が発生してしまった場合に他の作業が割り振れるよう準備しておく、もしくは優先度低の作業として割り振っておく -
複数の方法があったり、要不要が判断できず、迷ってしまう（ぼんやりした表現ですが、設計、実装、調査、成果物など様々なシーンで発生します）
→ 判断基準を伝える
→ どちらでも問題ない場合はエンジニアに任せる
→ エンジニアが判断できない場合は決める -
心身の不調でパフォーマンスが上がらない
→ 休んだり相談する心理的ハードルを下げるような雰囲気、仕組みを作る
→ 常に100%のリソース、100%のパフォーマンスが出せるわけではないという認識で見積もり、スケジュールを立てる
→ 作業量、難易度など負荷が大きい場合はリソースや期限を調整する
私が開発をやっていた時に感じたものを挙げただけなので、問題・対策とも他にも色々ありそうですが、思い当たるものも多いのではないでしょうか。
上記のような問題であれば、マネジメントでチームの生産量に貢献できそうです。
エンジニア自身でできるものもあるため、生産性が上がった割に生産量が上がらないと感じた時は、意識してみるといいかも知れません。
おわりに
生産性が高い＝仕事ができるというイメージになりがちですが、生産性を発揮できる状態を作ることで、より生産量を上げられるというのが少しは伝わったでしょうか。
今回は踏み込みませんでしたが、エンジニアが付加価値生産性をどう上げられるか考えてみるのも面白そうです。
また、マネジメントを管理側という全くの別ポジションではなく、エンジニアが困っていることを改善するポジションとして、興味を持ってもらえると嬉しいです。