なぜソフトウェア開発者をマイクロマネジメントするのは良くないのか?

なぜソフトウェア開発者をマイクロマネジメントするのは良くないのか?

前書き

常に誰かに肩越しに見られているとしたら、あなたはどう感じるだろうか?

仕事を片付けようとしているときに、マネジャーから何度も電話がかかってきて、進捗状況の報告を求められたらどうだろう?

控えめに言っても悔しいだろう? それでは生産性が落ちるだろう?

クリエイティブな仕事を与え、そのやり方を段階的に指示してくれるマネージャーを持つというのはどうだろう? それでは、創造性を発揮する余地はあまりないだろう?

これがマイクロマネジメントというものだ。

マイクロマネジメントとは何か?

チームをコントロールすることと、彼らにインスピレーションを与えることの境界線は、少し混乱するかもしれない。 しかし、どこで境界線が曖昧になり、イライラさせるマネージャーになってしまうのかを知ることは重要だ。 マイクロマネジメントでは、マネジャーは常にチームのやることなすことすべてをコントロールしようとし、変更を提案し、プロジェクトについて、特に好ましくないものについてはコメントをする。 才能があり、熟練し、経験を積んだプロフェッショナルは、このようなことをまったく意に介さない。 これは事実上すべての仕事に当てはまるが、ソフトウェア開発の分野では特にそうだ。

多くの場合、企業はソフトウェア開発者を雇い、特定のソフトウェア開発プロジェクトを管理した経験のないマネージャーを雇う。

マイクロマネジメントを嫌うのはソフトウェア開発者だけでなく、彼らはそのプロセスを生産性の邪魔をするものと考えている。 開発者の焦点は

  • 速度を向上させる
  • コードのデプロイ頻度の向上
  • リアルタイムのパフォーマンス目標

スクラムの開発者チームは、毎スプリントの終わりにパフォーマンスレビューがあり、毎週コードレビューがあるので、このような年ごと、半年ごと、四半期ごとのパフォーマンスレビューは時間の無駄に思える。

では、開発者を不幸にすることなく、彼らの仕事を管理することは可能なのだろうか? 組織は依然として、ソフトウェア開発者が期待、ビジネス目標、パフォーマンスを満たしているか/超えているかを確認する方法を使用する必要がある。

マイクロマネジメントを避け、それでも仕事を成し遂げるためのヒント

マイクロマネジメントはチームのストレスや不安を高める可能性があるため、全員のプロセスを楽にする方法を考え出さなければならない。

職場における自主性の促進

職場に自主性を重んじる文化を築くことで、チームは活気づき、より良い仕事ができるようになる。 チームに十分な自主性を与えるマネジャーは、仕事を成功させる可能性が高い。 彼らに指示を与えるのではなく、チームが本能と経験に従い、仕事を成し遂げるようにするのだ。 利用可能なツールやフレームワークをフルに活用させ、スケジュールを決めさせる。 ひとたび道具を手に入れれば、彼らは可能な限り最善の方法で仕事をする。 彼らが最善と考える仕事を自由に行うことは、彼らを逐一監視するよりも、より多くの成功をもたらすだろう。

事業目標に沿った目標と主な成果

チームマネージャーと開発者チームは互いに協力し、目標と主要な結果が技術的目標とビジネス目標とが一致していることを確認しなければならない。 バランスの取れた方法でこれを行うことで、両者が目的を見失わないようにする。 チームはマネージャーと一緒に、アプリ開発のさまざまな側面について議論し、討論し、結果を決定する。

スプリントとリリースのコミットメントが守られているかをチェックする。

納期を守ることは、チームの規律を測り、プロジェクトを通じてチームが守ってきた基準を揃えるひとつの方法である。 マネジャーは、常に崖っぷちに立たされるのではなく、すべてのスプリントで期待値の高低を設定し、それぞれのスプリントでのパフォーマンスを見直すことができる。 これは、品質基準を満たしているかどうかをチェックする有効な方法のひとつである。

ステークホルダーとプロダクトオーナーからの満足度調査の活用

すべてのプロジェクトは、ステークホルダーとプロダクトオーナーの満足を確保することを目的としている。 それを測定する1つのツールは、アジャイル開発者にフィードバックするための満足度調査である。 こうすることで、ステークホルダーとプロダクトオーナーの両方の視点から、行われた作業や改善点に関する現在のフィードバックを収集することができる。 結局のところ、アジャイル・マニフェストは「契約交渉よりも顧客とのコラボレーション」という中核的価値を明確に定義している。

チームに適したリソース

開発者チームは時間通りに働くことはなく、自律的に働いて初めてうまくいく。 それでも、仕事で彼らのスタイルに合ういくつかのリソースを持つことはできる。 トラッキング・ツールはそのようなツールの1つであり、スプリントやプロジェクトのデータを収集したり、プロジェクトのスケジュールを予測したりするのに使うことができる。

優秀な人材を採用する

適切なチームを雇えば、もうマイクロマネジメントをする必要はない。 彼らは何をすべきか、どのように提供すべきかを知っている。 会社が競争力のある給与と充実した福利厚生を提供すれば、チームの優秀な人材や成果を上げる人材が集まってくる。

ピアレビューのプロセスを作る

ピアレビューは、開発者がメンテナンス可能なコードや有用な文書を開発するために自分の仕事をしているかどうかを判断するための素晴らしい方法です。 同業者がコードの読みやすさについてコメントしたり、ドキュメントに評価を与えたり、マイクロサービスやAPIなどを統合するための調査を行ったりする。

結論

ソフトウェア開発分野の急速な発展により、開発者はこれらの技術や方法論を採用することが必須となっている。 そして、新しいツールを探求し、ベストプラクティスを採用するための自主性が必要なのだ。 マイクロマネジメントは、チームのやる気を失わせ、混乱させる可能性があるため、彼らの自由を制限する。

開発者は異なる人種であり、マイクロマネジメントされると、自分の貢献が評価されていない、尊重されていないと感じるかもしれない。 開発者チームがマイクロマネジメントされると、必要でない決断を迫られる可能性があり、それが仕事の質に影響するかもしれないので、ミスが起こる可能性が高くなる。

チームを率いるマネジャーがいる場合、彼らの仕事は実際、彼らが必要とするすべてのリソースを提供し、必要であればリソースとガイダンスを提供し、そして文字通り、邪魔をしないことだ!

興味深いリンク:

マイクロマネジメントをせずにソフトウェア開発者を管理する方法

あなたがプロジェクトをマイクロマネジメントしていることを示すいくつかの兆候

写真:Canva


著者:Sascha Thattilは、YUHIROグループの一員であるSoftware-Developer-India.comで働いています。 YUHIROは、IT企業、代理店、IT部門にプログラマーを提供するドイツとインドの企業です。

コメントする

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください