【保存必須】大規模システムのチームリーダー1年やって学んだこと取り組むべきこと

大規模なシステムのチームリーダーを1年やってみて、これやってみてよかったなとか、もっとこうすればよかったなとか、次年度はここを強化していけば、もっとチームリーダーとして上手くいくなといったことをまとめてみました。

そもそもなぜ、この記事を書こうと思ったかなんですが、大規模なシステムのチームリーダーをやったことがなくてチームリーダーをやった結果、対応が後手後手に回ってしまい、反省点が多かったからです。

1年経験したからこそ、振り返ってみてチームリーダーとしての全体像や要領が掴めたので、備忘録と次年度に向けての改善という意味合いで記事を書いてみました。

この記事を読んでほしい人は、以下のような人が対象です。
・これからチームリーダーとして頑張りたい人
・チームリーダーをやっているけど、どうすればいいか悩んでいる人
・チームリーダーで上手く立ち回りたい人

大規模なシステムってどれぐらい？

私がチームリーダーをしている大規模なシステムですが、非常に多くの方が利用するシステムになります。データベース数も1000を超えるし、改修するとなると影響範囲も大きいシステムで複雑になります。

私は着任して、半年後ぐらいにチームリーダーを担当することになりました。チームリーダーとして、もがき苦しみながら、体調も崩しながらなんとかチームリーダーとしての1年目を乗り越えたので、私の経験談などが参考になればいいかなと思います。

チームリーダーをする前の心境

チームリーダーをやることの抵抗はありつつも、将来的なキャリアを築く上でマネジメント経験は必要だと思い、不安だけど挑戦してみようと思いました。

なぜなら、エンジニアはたくさんいるけれどマネジメント経験があるエンジニアが将来的に残っていくだろうし、希少性生まれるだろうし、エンジニア以外の仕事でも役に立つだろうと思ったからです。

不安に関して言えば、働き過ぎて病まないか、エンジニアとしての技術的なスキルは停滞しないか、もしチームリーダーをやってみて合わなかったらどうしようと言う感じで、とりあえずやってみようと思いながらチームリーダーになりました。

とはいえ、チームリーダーのイメージをつけるためにも何かインプットしておかなきゃな〜と思い、下記のような本は読んだ記憶があります。

amazonでもベストセラーになっており、プレーヤーからマネージャーに視点をシフトすることが書かれています。

チームリーダーをやった後の心境

チームリーダーを1年やっての心境としては、辛いことの方が多かったですが、学びの多い経験となりました。

なぜなら、今まではプレイヤーとして業務を行ってきましたが、チームメンバーの進捗を管理したり、チームメンバーの業務支援を行ったり、ときにはメンバーの仕事を巻き取ったりなど、仕事のあり業務支援方の視野が広がったからです。

今やAIが台頭してきて、コードの生成はAIに任せたりなどありますが、チームリーダーの経験は、これからのエンジニア人生やエンジニア以外の人生においても役立つし、希少性がさらに高まっていくので、もう少しリーダー経験を積んでいこうと思いました。

また、今年の反省点を踏まえて来年度に向けて現在業務改善を行っているところで、そういった業務改善を考える事もやりがいがあると感じています。

チームリーダーをやってみないと見えなかった視点があるので、私の経験が皆さんの役に立てば良いと思っています。

マスタースケジュールを作成すること

まずは、全体のスケジュールをざっくりと示すためにマスタースケジュールを作成した方がいいと思います。

マスタースケジュールとは、プロジェクト全体の開始からリリース完了までの主要な「山場」を、1枚のガントチャートなどで可視化した全体計画のことです。

マスタースケジュールを作成することで、年間スケジュールがわかるのでどの時期にどこまで終わっていればいいのか、チームリーダーとメンバーと共通認識を持つことができます。

マスタースケジュールを作成するときの注意点

私がマスタースケジュールを作成するときは、あくまでもマスタースケジュールなので作り込まないことと、メンバーにもしっかりとスケジュールを浸透させることが重要だと思いました。

なぜなら、マスタースケジュールを作り込みすぎると、作成工数と作成後のメンテナンスが大変です。リーダーは他にもやることがあるので、最低限の工数で作成しましょう。

また、メンバーにスケジュールが浸透していないと、どこまでに何が終わっていればいいのかメンバーもわかりません。朝会などを活用して、マスタースケジュールの共有を繰り返し行いました。

マスタースケジュールの作成例

いつリリースがあるのか、いつ結合テストやシナリオテストがあるのか、要件定義〜単体テストはいつまでかぐらいをざっくりと線を引くぐらいで問題ありません。

あくまでも一例ですが、マスタースケジュールのサンプルを作成してみましたので、参考にしてみてください。

マイルストーンを作成すること

マスタースケジュールのほかにマイルストーンを作成すると、進捗管理として良いでしょう。
マスタースケジュールが長期的で全体がわかるスケジュールとすれば、マイルストーンは中期的なスケジュールを立てるのに役立ちます。

例えばリリースごとにスケジュールを立てたり、タスクにかかりそうな工数やタスクの期限日や視覚的にわかりやすくするのであれば、日付のスケジュール付きで管理するのも良いでしょう。

イメージとしてはマスタースケジュールは1ヵ月を4分割して、ざっくりとスケジュールを確認するもので、マイルストーンは1週間ごとの進捗を管理するものとなります。

マイルストーンを作成する例

私が実際にマイルストーンを作成するとなると、現場ではこのように作成しています。あくまでも一例ですし、現場のものをコピーするわけにはいかないので、一部調整しています。

マイルストーンの作成例です。

機能としては最低限ですが、下記のような機能となってます。

・土日の場合は列が自動的にグレーアウトする
・開始日と期限日を入力すると、自動的にスケジュールのセルの背景色が変わる(緑色になる)
・タスクのタイトル以外の担当者や期限日などはグループ化して非表示にできる
・EとF列は固定にしている

マイルストーンを作成するときの注意点

進捗管理にありがちなのが、進捗の管理する項目数がついつい多くなってしまうことです。項目数が多すぎると管理をする個数が増えてしまい、結果的に管理を苦しめます。

タスク概要や優先度や期限完了はまだと思いますが、それ以外はぶっちゃけ不要です。私はスケジュールが視覚的にわかりやすいように日付スケジュールも導入して、タスクの開始日から期限日までを自動的にセルの背景色を変えるようにして管理しています。

タスクに重みづけをすること

タスクに重みをつけると言うのは、どれだけ影響範囲が大きいのか、どれだけ仕様が複雑なのか、どれだけ優先順位が高いのか、どれだけ難しいのかを1タスクごとに客観的に算出したものと定義します。

機能	内容	備考
A機能	1画面の画面レイアウトに文言修正がある	影響範囲は非常に少なく、仕様の理解も簡単で調査時間もほぼなし
B機能	外部APIとデータ連携して、データを取得する	外部連携APIの仕様書の入手や、仕様の理解やエラーハンドリングなど設計や実装が難しい。

例えば、上記のようなA機能、B機能をそれぞれ1タスクとして考えると、影響範囲や仕様の複雑さにばらつきがあります。このままリリースまでのタスク全体の進捗度を見たときに、下記のような状況になりがちです。

機能Aと機能Bを同じ「1タスク」としてカウントして進捗管理を行うと、プロジェクトの後半で「進捗率は高いのに、終わる気配がない」という深刻な状況に陥ります。

理由としては、以下のようなことが挙げられます。

「進捗率」と「残り工数」の乖離

着手しやすい機能Aから消化すると、タスク数ベースの進捗率は「50%完了！」と順調に見えます。しかし、実際には全工数の20%程度しか消化できていないというギャップが生じます。

リスクの顕在化が遅れる

リリースの直前になって「実は技術的に実現不可能だった」「大幅な仕様変更が必要」といった致命的な問題が発覚し、リカバリーが不可能になります。

人員配置のミス

すべてのタスクを均等に見積もると、ジュニア層に機能Bを割り当ててしまい、パンクさせてしまうといったミスが起こります。

タスクの重み付けをすることで実情に合った進捗を管理できますし、リスクの顕在化につながります。また、早期の人員リソースの確保や優先順位付けにもつながるため、タスクの重み付けは早期の段階にしておきましょう。

タスクの重みづけのサンプル

タスクの重み付けをする際に、私は下記のような方法でタスクの重みづけを行っています。

影響範囲や仕様の複雑度で客観的に算出し、例えば仕様の複雑度が3、影響範囲が2であれば、タスクの重みは6となります。数字が大きくなればなるほどタスクの重みも重くなるため、仕様の複雑度が大きくなり、影響範囲も大きくなります。

タスクの期限と担当者を明確にすること

いつまでに誰が何をやるか？はチームリーダーとして管理すべきことです。
担当者だけ決めておいて、期限を決めないとなると、タスクを先延ばしにしがちなので担当者と期限をちゃんと決めてあげましょう。

納期まで長いタスクがあると、簡単なタスクで優先度も低いやりやすいタスクをしがちです。
タスクの期限と担当者をあらかじめ決めておくことで、チームリーダーの意思をメンバーに共有できますし、指針になります。

私が実際に経験したことでは、タスクの担当者は決めたけど、期限を決めずにタスクがズルズルと対応が後回しになり、メンバーに何度も進捗を確認することになりました。

具体例としては、ガントチャートを作成して、タスクの可視化をすることです。
有料でもいいのであればバックログなどのタスク管理ツールで管理するか、無料ならスプレッドシートで作成するかになります。

メンバーが調査資料をまとめやすいように環境整備すること

チームリーダーはメンバーの進捗状況確認するとともに調査資料やレビュー物の確認をすることもよくあります。

もしメンバーが調査資料にまとめるのが難しい場合であったり、メンバーの調査資料が見づらいといった場合は、細かく指示するのではなく、あらかじめ調査資料に必要な図解やテンプレートを用意しておきましょう。

それがあることで、メンバーの調査がはかどりますし、資料作成も一定の水準を保つことができます。わたし自身も業務をしていて、テキストではなく、頭でイメージした方が理解度が高まります。

そのため、よくチームメンバーにはテキストではなく、シンプルなものでもいいから、処理の流れを頭に表してほしいと伝えてます。では実際に私がどのようなテンプレートやつを用意しているのか、一例だけお見せします。

調査資料のテンプレートやサンプル図の例

ここでは、フローチャート図やデシジョンテーブル等の調査に役立つサンプルを提供します。

処理の流れをわかるりやすくするフローチャート図やシーケンス図についてです。これはエンジニアをやっていれば、聞いたことあると思うので、検索してみてください。

スプレッドシートで図形描画を使ってフローチャート図を作成しても良いのですが、スプレッドシートの図形描画は使いづらい場合もあるので、下記のように枠線だけを使ってフローチャート図を作成することも可能です。

条件の洗い出しなどに役立つデシジョンテーブルのサンプルになります。

デシジョンテーブルでは、条件の項目を記載して、Y= YES(条件に一致) N=Noで表し、アクションはXで表します。

下記の画像の例でいくと、ケースNo.1では条件がプレミアム会員の場合、アクションとして送料を無料にするが期待動作となります。ケースが複雑になっていくほどYやNが増えていくので、ケース作成は大変ですが、表形式で表せるのでもれなくケースを洗い出すことができます。

サブタスクを管理すること

進捗管理するときは、メインタスク以外にもサブタスクを管理するようにします。
メインタスクとは、リリースするときに要件が決まって実装する機能を指してます。

サブタスクとは、問い合わせやアラート対応やメインタスクでは無いけれど、リリースするまでに必要な対応(調査や使用作成など)が含まれます。

サブタスクを管理することで、チーム内のタスク漏れを防ぎます。チームメンバーにあれやっといてねーとか、逆にメンバーからこれ確認しておいてくださいとか、他のチームから調査お願いしますと頼まれた場合、すぐに対応できれば良いのですが、対応できずに後で対応することもあるでしょう。

後で対応することがどんどん積み上がっていくと、サブタスクの管理教えなければ当然タスクが漏れます。そのため、サブタスクを管理しておくことが大事です。

サブタスクを管理する具体例

では、実際にサブタスクの管理の仕方をスプレッドシートを用いて説明します。

メインのタスクとは、切り分けてタスクが管理できれば良いので、以下のようなフォーマットでタスクを管理すると良いでしょう。

簡易的に作成しましたが、条件付き書式で生活が完了になったら行全体をグレーアウトにするだったり、優先度が最優先の場合は、行全体を赤くするなどの工夫があればより視覚的にわかりやすくなるでしょう。

タスクのブロック要因となっていることをいち早く解決すること

タスクのブロック要因となってることを早く解決することで、メンバーのタスク消化につながります。朝会などを活用して、メンバーのタスクのブロック要因を聞き出しチームリーダーはブロック要因を取り除いていく事に注力します。

他のチームと連携する必要があったり、プロジェクトマネージャーと連携する必要も出てくるでしょう。またチーム内にいるメンバーの有識者に頼ってみて問題を解決するでもいいでしょう。

とにかくメンバーのタスクを前に進めることがチームリーダーの役割として重要です。

ブロック要因の具体例としては、例えば性能テストを実施するときに、負荷環境のスケジュール調整をする、画面レイアウトのデザインや文言をデザインチームとあらかじめ調整する、単体テストや結合テストの要員を事前に調整しておくなどが挙げられます。

進捗管理は管理を細かすぎるとよくないこと

進捗管理は管理が細かすぎるとメンテナンスが大変なのでお勧めしません。
管理が細かすぎると言うのは、具体的には、以下のようなことを指します。

• 進捗報告を1日に3回以上求める。
• 1日何をやっているのか、把握するために、1時間ごとの行動を聞く。

人は細かく管理されると、なんだか監視されているような気分になり、嫌気が差して仕事に対するモチベーションが下がります。
マイクロマネジメントと呼ばれますが、ネットで検索してもあまり良い事は聞きません。

私自身、マイクロマネジメントされると、なんだか裁量権を奪われた気持ちになって働きづらさを感じます。
チームメンバーのモチベーションの低下にもつながってしまいますので、マイクロマネジメントは極力避けましょう。

心理的安全性を重視すること

メンバーと会話する中で、特に意識しているのが心理的安全性を重視することです。
心理的安全性が低いことを簡単に言うと、自分の気持ちや意見を言いにくい環境になります。

例えば、あなたが業務をしていて、この設計わからないなぁとか、この実装わからないなと言う場合に誰かに相談したいと思うことでしょう。ただし相談したらこんなこともわからないのかと言われそうで相談しにくい。だから相談せずに黙っておくみたいな環境が、心理的安全性が低いと言えるでしょう。

一方で心理的安全性が高ければチームメンバーが相談しやすい雰囲気になり、リスクの共有や共通認識が共有されて、業務の連携がスムーズに行きます。結果として生産性の向上につながります。

本人はそこまで気にしておらず、勉強になったと話していたのですが、対応としては良くなかったでしょう。
それからはメンバーが調査してくれたものに対して、感謝を込めて内容を聞くようにし、メンバーが相談しやすい雰囲気作りに努めました。

心理的安全性を高めることはチーム作りの上でも重要な要素だなと感じました。下記のような本はおすすめです。ネットからでも情報は拾えますが、本で勉強する方が私は好きです。

知識が体系的に学べるし、ネットの情報よりも信憑性が高いからです。

まとめ

大規模システムのチームリーダーを1年やってみて、技術力以上に「仕組み」と「コミュニケーション」の重要性を痛感しました。

• マスタースケジュールで大きな地図を持つ
• テンプレート化でメンバーの作業負荷を下げる
• 心理的安全性を高めて問題を早期発見する

これらが噛み合ったとき、チームは一番スムーズに動きます。

もし今、あなたがリーダーとして悩んでいるなら、まずは「メンバーが一番困っている資料のテンプレート」を一つ作ることから始めてみてください。
小さな効率化の積み重ねが、いずれ大きな余裕を生み出してくれます。私も2年目はもっとメンバーを頼れるよう、さらに仕組みを磨いていきます！