前へIT企業において「プロジェクトマネージャーはコーディングすべきかどうか」の話題はよく議論されてます。開発チームの責任者は現場のエンジニアの仕事をしてもいいかどうかと読み替えても構いません。ネット上の議論では、本題に戻ります。ネットの記事を読むと、この「プロジェクトマネージャーはコーディングすべきか」問題はすごく極論化されます。賛否の主張を簡単にまとめてみました。コーディングすべきでしょう。コーディングもできなきゃ責任者たり資格や説得力が欠けるし、チームメンバーからの信頼も薄い。コーディングできないマネージャーの指示なんか聞けるか!?技術力があるリーダーこそ適切な指示が出せて、判断を下せる。管理論信者の言い分そもそも、プロジェクトマネージャーの仕事は管理だろう。自分の仕事を放棄して現場のことやったら、誰が管理や顧客調整するんだよ。開発人員の不足でコーディングする必要性があるとしても30%以上の時間を費やしてはならない。着目点はいずれもどれくらいコーディングすれば適切かであって、なぜコーディングするのかについて触れられていません。私の考えここで私の薄っぺらい少し考えを述べさせていただきます。プロジェクトマネージャーの優先事項は管理です。それを行う上で開発チームメンバーとの相互協力することが必要不可欠です。技術者視点でチームメンバーの考えを共感できなければいけません。優秀なプロジェクトマネージャーは技術と管理能力を両方備えていることが条件です。コーディングすべきか、どれくらいコーディングが適切について考えるのではなく、どういう状況ならコーディングしてもいいのかを考えるべきです。これを考えることっが難しければ、反対にどういう状況でコーディングしては駄目なのかについて考えてみてもありです。良いシステムを作り上げるのに開発チームにはコーディングだけでなく、様々すべきタスク(設計、テスト、監視、コードレビュー、ドキュメンテーションetc...)があります。これらのタスクを満足にこなせる時間があるのはエンジニアだけであり、プロジェクトマネージャーではありません。プロジェクトマネージャーが自分の好きなコーディングだけしてメンバーに他の面倒なタスク(テスト、監視、レビュー)を押し付けてしまったら、それこそチームメンバーの信用を失いかねません。プロジェクトマネージャーはクリティカルパスのタスクでコーディングしてはいけません。コーディングしてOKの状況では、逆にどういう状況ならコーディングに参加していいのか。以下の場面が当てはまると思います。コードレビュープログラミング作業の10%がコーディングであり、残り90%は設計、調整、テスト、レビューです。プロジェクトマネージャーは必ずしもコーディングしなくてもプログラミングできます。コードレビューを行うことでチームメンバーとの共感が高められ、メンバーの技術力を高めることができ、一石二鳥です。小さなバグ改修なら、大量の時間を使ってコーディングする必要がありません。バグ関連のコードを読むことで、チームメンバーのコーディングスタイルをわかることができます。極端な話、チームメンバーがある朝、突然バスに轢かれて死んでしまったときに、プロジェクトマネージャーはすぐに対象しなければなりません。確率がかなり低いですが、何があっても常に消火できる準備を日頃から心がける必要があります。期待できるお便利ツールを作ることは非常に有意義です。便利ツールでメンバーの負担を減らせますし、自分の技術影響力を高めることができます。ツール作りやメンテナンスがあまり自分の負担にならないように、適切なタイミングでツールを他の人に渡すことをおすすめします。まとめコーディングしても良い状況がわかったところで、プロジェクトマネージャーはどれくらいコーディングしたほうが適切かについて、考えてみましょう。こればかりは正解がありません。プロジェクトマネージャーごとの素質にもよると思います。技術力と管理能力の強さの比重は人それぞれです。その人が無理なくこなせる量のコーディングできれば良いではないでしょうか。プロジェクトマネージャーの第一の目標はプロジェクトを成功に導くことであり、どれくらいコーディングすればいいかについてあんまり考える必要もありません。