ITエンジニアのチームマネジメント論

　プロジェクトリーダーは、プロジェクトを成功に導くためにチームを適切にマネジメントする責務を負います。

　プロジェクトリーダーが責務を果たすために行うこととは一体何でしょうか。実はそんなに難しいことはやっていません。

プロジェクトの要件を分析する

　プロジェクトの要件は、プロジェクトによってさまざまです。新規開発、機能改修をはじめ、研究や分析など、多岐にわたります。

　プロジェクトリーダーは、プロジェクトの要件を正確に把握し、俯瞰することが何よりも大切です。

　リーダーの役割のひとつは、成果物を要件の充足度および品質の観点から評価し、プロジェクトの方向性を常に操舵することです。

　プロジェクトは、コントロールを失うと容易に誤った方向へ迷走します。これを防ぐ為には、常に俯瞰した、客観的な目線を持ち、プロジェクトの方向性を見失わないことが重要となります。

　プロジェクトマネージャと決定的に違う点は、プロジェクトの損益をそこまで気にする必要がないということです。要するに、プロジェクトの損益といった経営的側面はプロジェクトマネージャに任せてしまい、自身はプロジェクト自体のマネジメントに徹することとなります。

メンバーとの関係

　さて、本題に入る前にチームメンバーとリーダーの関係性に少し触れておきます。

　大前提として、プロジェクトに上下関係はありません。豊富な経験を積んだアーキテクトも、研修を負えたての全くの新人も、等しく敬意を持って接するべきです。敬意を持って接するというのは、丁寧な言葉遣いで接するということではなく、相手を尊重し、信頼するということです。

　プロジェクトリーダーは、プロジェクトリーダーとしての仕事をするだけの単なるロールであり、偉いわけではありません。他もまた然り。

　相手を信頼し、仕事を任せる。チームマネジメントはここから始まります。

プロジェクトを進める仕組みを作る

　現在は、昔と比べると様々なプロジェクト管理ツールが開発され、また様々な開発手法が提唱されています。

　ウォーターフォールは、要件がはっきりしており、明確なスケジューリングが求められる場合や、開発規模が非常に大きい場合に有効です。反面、要件が出揃わない場合や、ユーザーインターフェースが重要な場合には、プロトタイピングやアジャイルなどの手法を選択する必要があります。

　開発手法は重要です。これが噛み合わなければ、プロジェクト管理コスト、ひいては開発コストまでも大きく増大します。柔軟な考え方で、かつ慎重に手法を選択することが大切です。

要求をコントロールする

　プロダクトマネージャ（プロダクトオーナー）は、良いプロダクトを作るのが仕事です。しかし、プロジェクト人数や、スケジュールなどの極めて無視できない要素が存在します。

　つまり、プロダクトのある機能を盛り込んでしまうと、プロジェクトが赤字になるか、スケジュールが遅延する可能性がある場合、トレードオフを考慮せねばならないわけです。

　しかし、スケジュールを考えるのは要求を出す側のプロダクトマネージャの仕事ではありません。プロダクトマネージャからの要求を受けて、調整するのはプロジェクトマネージャもしくはリーダーの仕事です。

　勿論、リーダーとプロダクトマネージャの目的は「良いプロダクトを作る」という点において一致しているべきです。その上で、現実的な落とし所を探らなければなりません。これを怠ると、プロジェクトは瞬く間に炎上し、最悪の場合頓挫します。

　プロジェクトリーダーは、徹底的な現実主義者である必要があります。

進捗どうですか？

　プロジェクト管理は、報告も重要です。かといって、毎日、日報をメールで出させるようなことはあまり良くありません。メンバーにとっては報告するコストもかかります。

　もし、プロジェクト管理ツールなどで定量的に俯瞰できる場合は、その更新をプロジェクトとして習慣付け、ミーティングで棚卸しをする程度にしておくのが良いかもしれません。ステークホルダへの報告のような面倒な業務は、リーダーが全て請け負うべきです。

　チケット（Issue）管理なら、プルリクエストやマージイベントにフックして進捗状況を更新したりもできます。

開発に集中できる環境を作る

　世界的にも、目前のコードにだけ集中できるような仕組みが広まってきています。例えばAWSなどのクラウド技術によって、開発者はインフラやネットワークのことを考える必要がなくなりました。CIによってデプロイを自動化することで、驚異の1日10回というデプロイを実現しているチームもあります。

　こういった環境を整えることも怠ってはいけません。環境整備は、始めるのが早ければ早いほどプロジェクト進捗に寄与します。最初期の環境整備は先行投資ですが、プロジェクト後期の環境整備は、借金の借換に過ぎません。

　例えば、10人規模のプロジェクトでCIなどの環境を整備するのに5日（40時間＝2400分）かかったとして、それによって1日たった5分の定常業務が削減されただけでも、2400分÷5分×10人で、48日以上プロジェクトが継続する場合は無駄なコストにならない、ということです。逆に、上記の例で48日も掛からない場合など、コストのバランスが取れないときは、自動化をしない選択肢も当然あります。

チーム文化を形成する

　チームが効率的かつ能動的に動くためには、優れた文化が必要です。とりわけ、「失敗を許す」文化や、「自由に意見が言える」文化は重要で、チームを萎縮させないための第一歩となります。

失敗を許す文化

　失敗から学ぶことは多いです。手痛い失敗であればあるほど、その体験は強烈なものになり、二度と失敗しないように頭を働かせます。結果、新しい発明が生まれたりすることは、歴史的に見ても、そう珍しいことではありません。

　しかし、失敗が許されない文化になると、失敗を恐れるあまり保守的な行動しか取らなくなります。結果、日々周りが進歩する中で20年前の技術が現役であるという都市伝説のようなチームが出来上がります。

意見を言いやすい文化

　他人から学ぶことは多くあります。それが経験や技術力の全くない新人であっても、ベテラン技術者に見えないものが見えていたりする事もあります。自由に意見が言える環境でなければ、その事に気付くことは難しいでしょう。

適材適所を極める

　チームの人数が多ければ多いほど、様々な特性を持つメンバーがいることに気付くでしょう。テストが巧く、誰もが見落とすようなバグを発見できる人、コード品質が高く、まるで優れた文章を読むかのような感覚で読めるソースコードを書く人、カリスマ性があり、人を惹きつける人。

　しかし、例えばいくらテストが巧いからといってテストばかり任せるのは考え物です。人は「やりたいことをやっているとき」に最もパフォーマンスを発揮する生き物です。その人が何をやりたがっているかを正確に見極め、仕事を任せるわけです。

　得意なこととやりたいことが一致している人ばかりではありませんから、役割を的確にマネジメントすることが重要です。やりたくないことばかりやらされると、人は疲弊し、チームを離脱するに充分な理由を与えてしまいます。

面白くない仕事を昇華する

　テストは良い例で、進んでやりたい人はあまりいなかったりします。

　だからこそ、自動化したりコード化して、テストする人にとって楽しくなるように工夫します。どう工夫するかは、チームで話し合って決めるとよいでしょう。リーダーはあくまで問題提起に留めることです。

人を育てる

　メンバーは、各々のキャリアプランを持ってチームにいます。人を育てることは、チームの利益になり、会社の利益になり、その人の利益になります。

　少しの時間を掛けるだけで、数ヶ月後には数倍の生産性を発揮してくれるかもしれません。そう考えると、人を育てることは短期的に見ても、長期的に見ても、なぜやらないのか疑問になるほど割の良い投資ではないでしょうか。

バッファのバランス

　プロジェクトは、そのリスクを常に観測し、何かが起こることを予測しておく必要があります。想定外の出来事が起こった場合のハンドリングを行うためのバッファを多くとるチームもありますが、健全とは言い難いです。

　失敗が許されない文化を形成したチームは、このバッファが比較的多く取られる傾向にあります。遅れ＝悪だからです。

　この部分を全く取らないのもリスクマネジメントとして不適切かもしれませんが、多く取りすぎるのも当然不適切で、バランスが重要です。当初予定のスケジュールに対し、早く終わっても遅く終わってもベストではありません。ある意味、プロジェクトの最も難しいところで、過去も現在も、この問題を解決するために四苦八苦しているわけです。

プロダクト品質を高める

　もし、そのプロダクトが誰かの依頼によって作られているなら、その品質に責任を持つのはリーダーの責務です。

　その為には、いわゆる「コミュニケーション」が必要になります。コミュニケーションを取る相手はプロダクトに対するステークホルダで、エンドユーザー、プロダクトマネージャ、あるいは経営責任者かもしれません。

　高い品質のプロダクトとは、バグが無い、ということではありません。プロダクトを求めている相手の要求に沿っているかが最も重要です。

　今作っているものが要求に沿っているかは、その相手にしかわかりません。プロジェクトリーダーは、その相手と密にコミュニケーションを取り、プロジェクトが誤った方向へ進んでいないかを常にチェックするわけです。これは過度なくらいが丁度よく、ここを怠ると、チームの自己満足を満たすためだけのプロダクトが完成します。