私のゴールは「開発メンバーに最高に楽しい開発を経験してもらうこと」です。そんな環境を作るためにPL・PMを目指しています。
今回はそのゴールを実現するためにもPL・PMがやってはいけない事をまとめました。
（この記事は私のPL・PMとしての理想像を元に書かれているため、現実ではなかなか実現できない箇所もあると思います。）

Doneの定義をコロコロ変えてはいけない

メンバーの作業が終わってレビューの段階になってから「あれもやって欲しかったんだよなー」と追加注文をしない。作業が終わらなくなってしまいます。
何を持って完了とするかは事前に見える化する。あとから変更がある場合は先に「変更があるかもしれない」と一言説明をしておく。これでメンバーのストレスがだいぶ減ります。

プロセスではなく、人で管理してはいけない

例えば何かしらの不具合が発生した時「誰がやった！」と犯人探しを始めるのは良くありません。
「どの工程で発生したのか？」「何が原因だったか？」「今回の対応策と今後の対応策は？」といった不具合に至るまでのプロセスを一旦見直し、それから担当者の責任について話をするべきです。
逆に仕事ができる人に「あの人に任せておけば大丈夫」と言うのも同じく危険です。優秀な人の仕事の仕方からチーム内のプロセス改善を行うことで、一部の人に作業が集中する状況を無くし、チーム全体の生産性の向上を目指したい。

わからないことは誰にも見えないところで聞く雰囲気を作らない

「こんな事もわからないと思われるなんて恥ずかしい！」と思い、個人チャットとかで質問しがちになり、結局一部の人に色んな人から似たような質問が来ること、よくあると思います。
これはみんなが見える場所で質問できる雰囲気があるとコミュニケーションコストがだいぶ減ります。

指示を口頭で済まそうとしない

口頭で指示を出すと最初と最後で言うことが違ったり、いわゆる「言った言わない問題」に繋がりやすいです。
面倒でも文字にしたり証跡に残したりしたほうが手戻りが少なくなります。

レビューアとしてレビューの品質向上を怠らない

レビューしても不具合が見つかる理由の一つにレビューアによるレビューの品質があげられると思います。どんなにメンバーが品質改善に取り組んでもレビューアの指摘が的はずれだとどんどんコストが増えてしまいます。PL・PMは知識と技術について怠らない努力を常にする必要があります。

まとめ

名著ピープルウェアにこう記されています。

プログラミングコンテストのデータから見つかった生産性向上の要因のなかでも、意外だったものがある。それは誰とチームを組んでいるかである。例えば、パートナーの成績が良ければ、もう一人もやはり優秀な成績をあげた。一方、いつまでたってもプログラムの出来上がらなかったプログラマの相手も、どういうわけか同じことになった。さらに途中で投げ出したプログラマも、もう一人はやはり同じ結果となった。

いわゆる「何をするかではなく誰とするかが大事」という事を指していて、確かにその通りだと思います。

ただ、私は誰とチームを組むことになっても最後にはメンバーには優秀になって欲しい。チームとして機能して欲しい。楽しく開発をやってほしい。
常にそういった環境を作れるようになるために、今回はべからず集といった形で記事にしてみました。