cassetteを運営する延澤です！
developer-cassette.hatenablog.jp
前回の解決編を書きます(すごい日にちが空いてしまった)
振り返り
前回のポイント
- プロジェクト管理の本質は「人同士の関わり方」である
- 過去にも未来にも同じプロジェクトは存在しない
以上のポイントも踏まえた上での解決方法になります。
解決方法
1. 目標はメンバーのパフォーマンスを2倍以上に引き上げる！
上手くいっていないプロジェクトは数値化されていないことが多いです。
数値化出来る対象とは、見積もり、残タスク、スケジュール、進捗状況、優先順位です。
数値化すると何が嬉しいかというと、現在の状況やゴールに対しての道筋が見えてくるということです。
例えば、メンバーがタスクを「今週中に出来ます」と見積もったとします。
この表現は数値化が出来ていない典型的な事例になります。
他の作業を優先して後半の2日間で終わらせるつもりなのか、それとも他の作業と並行して5日間かかるのか、この表現では分かりませんよね。
「今週中に出来ます」という曖昧な表現から、2日間へ具体的に数値化し達成できれば、メンバーのパフォーマンスを2倍以上に引き上げることも可能になります。
2. やり方を常に変化させていく
新しいプロジェクトが新しいメンバーで始まったのに、プロジェクトリーダーが以前その人が携わっていた案件と同じ方法でプロジェクトを進めようとしているのを見たことはありませんか？
これは僕から言わせれば思考停止状態です。
過去にも未来にも同じプロジェクトは存在しません。
それなのに、メンバー及びチーム状況を無視して既存のやり方でやるのは適切とは言えません。
例えば海外のアジャイルのやり方をそのまま導入することがあります。しかし、メンバーがそもそもアジャイルの正しいやり方を理解していなかったり、必要性を感じていない場合はほぼ100%といっていいほど失敗します。ビーフストロガノフの作り方を知らない人達が集まって、よしやろう！でいきなりビーフストロガノフが作れないのと一緒です。（ビーフストロガノフをあなたが知らないように、他のメンバーもアジャイルを知らない可能性が高いということです）
その場合は、アジャイルについての技術書の読書会を実施・現在のチームの問題点の認識合わせの下準備がまず必要になります。（なかなか面倒な作業が発生するのは想像に難くないですよね）
私が理想なのは進化するチームです。既存のやり方だったとしても、「やっぱりこれは要らないよね、こういうのは必要だよね」というやり方を常に変えていけるチームです。チームの状況はプロジェクトの進捗によって常に変化していきます。それなのに、最初に決めたやり方に固執することはいいやり方とは言えません。
もう一度言います、重要なのはやり方を常に変えていけるチームです。
３. 全部自分でやりたがり自意識過剰クソ野郎問題
チームの意思決定と行動が遅い、もしくはプロジェクトリーダーの作業量が大きく偏っているパターンはありませんか？
これはプロジェクトリーダーが全てを把握し、決定したがる現象に見られるパターンです。プロジェクトリーダー自身が優秀だったり、自意識過剰の場合全てを決定と情報をコントロールしたくなるケースがあります。
しかし、プロジェクトの規模が大きい程人間一人では全てに対処できません。やがて、プロジェクトリーダー自身がプロジェクトのボトルネックとなり、リスク要因にもなりかねます。本来、リスクを管理するプロジェクトリーダー自身がリスクとなる本末転倒なケースです。これはプロジェクトリーダーが実はメンバーを信頼していない根が深い問題です。信頼されていないと感じるメンバーがプロジェクトで力を発揮することは難しいです。
解決方法として、プロジェクトリーダーはメンバーに適切に権限を委譲しましょう。
例えば、検索機能の設計と実装をメンバーに任せます。この場合、相談は随時受けつつ、マイルストーンごとにレビューを課していくことで権限の委譲は出来ます。
以上の権限委譲が出来ないプロジェクトリーダーは全部自分でやりたがり自意識過剰クソ野郎と呼ばれてもしょうがありません。
総評
優秀なエンジニアと普通のエンジニアの能力は１０倍の開きがあると言われます。しかし、優秀なエンジニアと下手なプロジェクトリーダー組み合わせは、優秀なエンジニアの能力をマイナスのレベルまで引き下げます。
逆に優秀なプロジェクトリーダーの場合、メンバー全員の力を３〜５倍引き上げることが可能だと本気で私は信じてます。最近の技術志向の風潮からプロジェクトリーダーの力は軽視されがちですが、サービスを作っていく上では重要なキーパーソンです。
最後にプロジェクトリーダーに大切なのは「メンバーが仕事しやすい環境を構築すること」にとにかくフォーカスすることです。プロジェクトリーダーが優秀でメンバーが当事者意識を持ち、風通しが良いプロジェクトで炎上することは決してありえません。
