初めて会社を起業する人のほとんどは、集団をマネジメントする方法を学ぶ間に、創業当初の従業員を燃え尽き症候群にさせてしまうと思います。 筆者のアドバイスがそのようなケースを減らせるなら、ここに書いておく価値があるでしょう。

筆者は小規模なチームやスタートアップ企業のマネージャーのためにこの記事を書きました。 ほとんどのアドバイスは、大規模な企業のマネジメントには当てはまらないのではないかと思います。 なお、急成長している企業に入社する人への全般的なアドバイスについてはこちらをご覧ください。

筆者について

• 中・小規模のエンジニアリングチームを数チーム管理した経験あり
  • On DeckのCTO
  • CoinListの元エンジニアリング担当VP
    • AngelListの元リモート責任者
    • Product Huntの元CTO

それでは始めましょう。

マネージャーはすべての失敗に責任を負う

分かります……とても前向きなスタートですよね👀

• チームを怒る意味は全くありません
• あなたはプロセスと人材に責任を負います
  • あなたは常にチームより多くの情報を持っていたはずです
• 失敗に至るプロセスを生んだのはあなたです
  • あるいは、誤った人材を採用した（または解雇しなかった）のもあなたです
• 結局、すべてはあなたの責任です

プロセスを管理し、人を導く

• なぜかは分かりませんが、多くの人にとって、「人材のマネジメント」とは部下の仕事をコントロールしなければならないという意味になるようです
  • 彼らはマイクロマネジメントに陥り、目標やスケジュールだけでなく、仕事のやり方まで管理しています
  • あなたがマイクロマネジメントをする時間があるなら、大抵の場合、あなたの代わりにもっと人件費が安くて能力が低い人を採用し、その人に仕事をさせれば良いのです
• 筆者が思うに、こうした行動は、マネージャの役割に関する誤解に起因しています
  • あなたの仕事は人を管理することではありません
  • しかし、プロセスを管理し、人を導くことができます
• マネージャーは、仕事をどのように行うべきか、各メンバーの権限の範囲はどこからどこまでか、どのようにキャリアを形成するか、そしてこれらすべてをどのように議論し、変更できるかに関して、プロセスを管理します
• さらに、手本を示し、共感することで人を導きます
  • メンバーは目標、不安やモチベーションを持っています。仕事以外に問題を抱えていることもよくあります
  • 仮に相手が逆の立場だったら、どう行動してほしいかを考えて行動しましょう

プロセスとは期待を明確にしたもの

• 多くの人は「プロセス」に関する責任をなんとか逃れようとしています
  • そのため「プロセスは多過ぎない方が良い」などと言います
    • 筆者の私見では、これも誤解です
• プロセスとは、人々の行動を複雑な鎖のように結びつけ、膨大な手間を負わせるものではありません
  • プロセスとは期待を明確にしたものです
    • 例えば、「誰も作業を邪魔されないように、毎朝全員で〇〇をする」のようにシンプルなものでも構いません
  • 少数のとても明確なプロセスを定め、それが守られるようにしましょう

意思決定と意見

• あらゆる議論、プロジェクト、問題や状況において、誰が意思決定するのかを明確にする必要があります
  • 他の人は意見を付け加えるにすぎません
  • 理想的には、その後にフォローアップする（あるいはその仕事のリーダーとなる）人が意思決定をすべきです
    • それ以外は全員、意見を追加するだけです
    • 「地位」や給与が高い人も例外ではありません
• マネージャーは意思決定を急に止めるためのハンドブレーキを握っています
  • この力は文字どおりハンドブレーキのように扱いましょう
    • 自動車の運転を想像してください。車を止めなければならないのに、ドライバーが反応しなければ、ハンドブレーキを引く必要があります。その結果、反動でダメージが生じるでしょう
    • 絶対に必要なときにのみハンドブレーキを引き、その後に状況をどう修正するか議論します
• 採用は意思決定スキルの優劣に基づいて判断します
  • 解雇も意思決定スキルの優劣に基づいて判断します
    • 優れた意思決定スキルには他人の意見を聞くことが含まれます
  • 疑問に思う場合は、意思決定者を最初から信頼できるか考えてみてください

当事者意識

• 従業員が問題に対して完全な当事者意識を持つようにするのは困難です
  • しかし、それが目標です
    • それがふさわしくない従業員なら解雇もできます
• フィードバックを提供し、支援しましょう
  • 従業員を信頼し、失敗を認めてください（損害を許容できる範囲で）
  • 失敗を「従業員のレベルアップ」と捉えましょう
• 最悪なのは、あなたが何度も介入し、従業員が仕事と自分を無関係と感じるようになることです
  • 彼らは当事者意識を持たず、言われたことをするだけのドローンになってしまいます
  • それがあなたの目的なら、人件費が安くて能力が低い人を採用すれば良いでしょう

堂々巡りを避ける

• プロセスを定めるときは、堂々巡りを避けましょう
  • 例えば、何かについてフィードバックを提供するときは、相手が言われたとおりにするか、あるいはそれができない理由を答えるだろうと考えてください
  • 承認されることを期待してはいけません
    • 誰もそんなことをしている暇はありません

信頼

• 自分が神経質になっているのは、他人の仕事と自分の不安のどちらが原因かを常によく考えましょう
  • 他人があなたの感情の面倒を見る必要があるでしょうか？
• 物事がうまくいっているときは、人を信頼するのは簡単です
  • 本当に難しいのは、物事がうまくいかないときです
  • 状況に対するいら立ちと、人に対するいら立ちを常に区別しましょう
• 「距離を置け」と言っているのではありません
  • 輪に加わり、目標を定め、意見を表明すべきですが、課題への対処はチームに任せるべきです。ただし、必要に応じてハンドブレーキを使いましょう

率直な共有を通じて信頼を築く

• 従業員があなたの仕事を信頼するようになるための最も簡単な方法は、何も要求されなくても、成果を率直に共有することです
  • 従業員が探すだろうと思う場所に、すべてを利用可能な状態で置いておきましょう
  • 従業員からの要求を待ってはなりません。ほとんどの従業員は要求をしないからです

信頼は0か1ではない

• 私たちは信頼を0か1と考えがちです
  • 誰かを信頼するか、信頼しないかのどちらかということです
• しかし、これは正しくありません
  • 時とともに、信頼する人や、その人の何をどのように信頼するかは変わります
• 信頼はシステム化できるものだと考えましょう
  • 例えば、チームの新しいメンバーにはどのような信頼を与えますか？
    • 最初の数週間や1か月はどのような仕事をすることを求めますか？

自律と放任を混同しない

• 筆者は、人材を採用した後は「好きなようにさせている」という創業者によく会います
• これは原則としては正しいものの、従業員の成功を支援する責任から解放されることにはなりません

多層的な意思決定

• 会社では、さまざまな階層の人々が、仕事をするうえでお互いに頼りあっています
  • CEOがプロダクトマネージャーの優先順位を認識していなければ、彼らは仕事ができません
• 自分の仕事を社内の他人に押し付けてはなりません
  • 自分の仕事より楽しそうだからという理由だけで、他人の仕事に踏み込むこともやめましょう

乱射型マネジメントを避ける

• ミーティングで自分の意見やアイデアを手当たり次第にぶつけてはなりません
  • あなたは経緯を十分に理解していない可能性が高く、大抵の場合、課題を最後までフォローする当事者になることはないからです
• 単なる意見であって、意思決定ではないことを明確にしてください
  • ただし、「創業者（またはマネージャー）の意見」がほとんどの従業員にとって大きな力を持つことを理解しましょう
  • 一般的に非同期コミュニケーションでは声の「ニュアンス」が伝わりにくいため、fyi（for your opinion 訳注：ご参考までに）タグを利用しましょう

ところで、筆者はこれを乱射型マネジメントと呼んでいます。なぜなら、グループで議論しているところにマネージャーがやってきて、銃を乱射するように要求、変更指示、アイデアを投げかけ、混乱、パニック、カオスを生み出した後、悲惨な状況を残して去っていくからです。

フィードバックを提供する

• 人×文脈 = 成果
• 筆者の経験では、優れた人材でも、環境が悪いと不十分な成果しか出せないことがあります
  • 一方、とても平凡な人材でも、環境が素晴らしければチーム全体を上回る成果をあげることもあります
• フィードバックをする際、通常はその人自身よりも経緯について客観的に議論するほうが簡単です
  • 現在の問題の原因となったのはどのような状況ですか？
  • 何が変わりましたか？現在何が必要とされていますか？
• 若手エンジニアが仕事について行けていない場合
  • それはエンジニア自身の責任ですか？それとも、チームは今の時点では、現在、若手が仕事を覚えるための役に立っていないのでしょうか？
    • すぐに問題になることはありませんが、いずれは解決するか、能力不足を受け入れる（解雇する）ことが必要です
• 本番環境で大きなインシデントが発生した場合
  • そもそも、なぜそのような事態が起きたのですか？
    • エンジニアリングチームは何に注目していましたか？
    • 問題を回避するためのプロセスは導入されていましたか？
    • プロセスを導入する必要はありますか？
  • インシデントを起こした従業員に責任はありません
    • チーム全体が他の優先課題に注目していたからです
    • それは適切な理由（リリースへのプレッシャーなど）によるものでしたか？
      • それとも不適切な理由（知識の不足など）によるものでしたか？
• あなたが採用した人材は、モチベーションが高く、最善を尽くそうとしていると常に想定しましょう
  • そうでない人材は解雇しましょう

解雇は決してサプライズであってはならない

• 従業員にとって、解雇は決してサプライズであってはなりません
  • 状況が変わり、新たな要件が生じたことを伝える必要があります
• 通常、従業員を解雇する理由は状況の変化です
  • 例えば、会社が変化したとき、
  • 役職に求められるものが変化したときや、
  • 誤った採用基準を定めていたことに気づいたときです
  • 大抵の場合、責任は従業員よりもあなたにあります
• 従業員は、自分の努力が新たな要件に足りるものであってほしいと願うかもしれません
  • それでも、あなたが彼らを解雇しようとするときは理解を示すでしょう

解雇を先延ばししない

• 従業員を解雇すると決定したら、すぐに行動しましょう
• 従業員をゾンビのような状態で雇い続けていることはよくあります
  • 「彼を解雇すべきだ」
  • そう思っても解雇しないのです
    • 従業員のためになりません
    • 従業員はおそらく今の環境に満足していないでしょう
      • 評価が低く、
      • 良い仕事もできないからです
    • 大抵の場合、あなたが解雇を避けるのは自分のためです
      • なぜなら、誰かを解雇するのは良い気分ではないからです
      • 自分の感情や未来を、従業員の感情や未来より気にすることはやめるべきです
• 面談を設定し、解雇を伝えます
  • 最初に余計なおしゃべりをするのはやめましょう
  • 本題を率直に切り出し、次のステップを明確にしましょう
    • 必ず真剣な事実として伝えます
    • 解雇を伝えるときには、あなたの感情や問題は重要ではないことを忘れないでください
• その後、従業員が新たな仕事を探せるように支援します
  • 従業員はかつてキャリアをあなたに委ねたのですから、その信頼を維持しましょう
• 最後に：一部の国では、従業員を解雇するのに月によっては数日かかる場合もあります
  • どちらにせよ、解雇のプロセスを主体的に管理し、あなたを信頼している人に敬意を持って接するようにしましょう
  • 彼らはあなたのチームにキャリアを委ねたのです
  • ほとんどの場合、従業員が去るのは自らの責任ではなく、状況の変化によるものです
    • 彼らが自分に適した新しい仕事を見つけられるように支援しましょう

明確 > 不明確

• ミーティング後の明確な意思決定
  • 明確な意思決定がなされていない場合は、その事実を明確にしましょう
• 明確な責任者
  • 明確な責任者がいない場合は、その事実を明確にしましょう
• 全員の意見を聞く
  • 誰が意思決定するかを明確にしましょう
  • 意思決定の内容も明確にします
• などなど

ベストプラクティス：「現実は正しい」という認識から始める

• チームやプロセスの中でベストプラクティスや変化を求めるときは、まずは既存の自然に生まれたものに必ず注目しましょう
  • 優れた人材を採用していれば、通常は彼らが自然と解決策を探し始めています
  • その解決策は適切でしょうか？もしそうなら明確にしましょう
    • 「現実は正しい」という認識が重要です
  • もし適切でないなら、それを変える方法について議論しましょう

会社は数カ月ごとにリファクタリングされるものと考える

• 急成長しているスタートアップ企業は、3～6カ月ごとに事業の進め方を社内でリファクタリングする必要があります
  • 現在必要な最低限の変化のみに取り組みましょう
• 決定的な最終バージョンは存在しません
  • あなたは会社のプロセスに対して常に不満を感じ続けるでしょう
  • 伸び悩みに直面しない限り、成長痛は続くはずです
• コードをリファクタリングするときと同じ原則を適用しましょう
  • 以下の点に気を付けてください
    • まずは小規模な隔離された環境でテストする
    • ピアレビューを行う
    • すべてを一度に変えようとしない
    • オーバーエンジニアリングを回避する
    • などなど

燃え尽き症候群

• よくある誤解は、燃え尽き症候群は働き過ぎが原因というものです
• 実際の原因は、仕事をコントロールできない、自分が影響を与えられていないと感じることです
  • 仕事がほとんどないにもかかわらず、従業員（あるいは自分）が燃え尽きる場合があることを忘れないでください
• 従業員が自らの影響をコントロールできるようにするには、どうすれば良いのでしょうか？
  • どうすれば従業員と周囲の混沌とした状況の間に境界線を引けるのでしょうか？

混乱を生み出す人間はそれに気づきにくい

• 創業者のよくある不満は、チームが変化について来られないというものです
  • 創業者は、大抵は変化に至る背景をよく理解し、変化の前段階を把握しています。また最も重要な点として、創業者は変化をコントロールできます
  • 従業員はそうではありません

自分の部下よりもマネージャーに多くのことを要求すべし

• 基本的に、失敗はチームの責任ではなく、マネージャーの責任です
  • 物事に関する率直な意見をマネージャーと個人的に共有しましょう
• 基本的に、マネージャーが意思決定できるように信頼すべきです
• マネージャーは結果に対する説明責任を負います
  • すべての失敗に責任があります
  • しかし、成功はマネージャーの手柄ではありません
    • 成功はチームの手柄です
• マネージャーは、可能なときはいつでも、成功を一人占めするのではなくチームにスポットライトを当てるべきです
  • ポイントは簡単です。チームに与える権限を増やすとともに、チームが輝くための方法を増やしましょう

気分が明るくなるような結論ですね😬

とにかく……この記事が誰かの役に立つことを願っています🙏

当然、筆者が見逃していることも数多くあるでしょう。ですから、twitterでお気軽にご質問ください。また、この記事を改善するためのアイデアがあれば、プルリクエストをお送りください。

この記事が気に入ったらシェアしていただけると幸いです。

追伸：筆者のチームは人材を募集中です