チームの構造を決める際に役立つ6つのポイント
以上のような各氏の見解をまとめていくと、エンジニアリングチームの構造を決めるうえで役に立つ手法がいくつか浮かび上がってきた。その手法を6つのポイントにまとめて紹介する。ぜひ、今後の参考にされたい。
1. チームの問題点を明確に理解する
これは、チームの構造を変更する際に役立つものだ。
言うまでもなく、チーム構造の変更は、何らかの問題を解決するために行うものである。ゆにえ、変更のプランを策定する際には、チームが内包する問題点に対する明確な理解が必要不可欠となる。より分かりやすく言えば、チームが抱える問題を洗い出し、それを「コミュケーションの問題」や「コラボレーションの問題」「方針の欠如」といった、簡潔なネーミングの下で定義できるかどうかが重要となる。
チームにおいて解決すべき問題が明確にできれば、チーム構造の変更に向けた作業のおよそ半分は終わったと考えてもよい。
アトラシアンのディジーによれば、エンジニアリングチームの問題点を明確化するうえでは、以下を行うことが重要であるとアドバイスする。
- （アジャイル開発で言うところの）「振り返り」におけるチームの傾向を見出す。
- チームの健全状態を定期的にモニタリングする。
- メンバーの役割と責任範囲が適切かどうかを点検する。
- 全従業員を対象にした年次／隔年の一斉調査（バイタルサインやパルス調査と呼ばれる）に見られる大きな変化を把握する。
2. 常に顧客を中心に据える
エンジニアリングチームにかかわる全ての意思決定は、常に、チームの成果物（プロダクト）を使うエンドユーザー、ないしは顧客を中心に置いて下されるべきである。
したがって、エンジニアリングチームだけではなく、社内のさまざまな人たちからアイデアを募りながら、エンジニアリングチームが目指すべき将来像を“ビッグピクチャー”として描いておくことが重要となる。そのうえで、長期的な使命の達成にメンバー全員を集中させることが重要となる。
3. チーム構造の小さな変更を繰り返す
例えば、2年に1回程度の頻度でチームの構造を変えるのは、チームに与える負の影響が大きくなるので避けるべきである。その代わりに、チーム構造の小さな変更を、より短いスパンで繰り返すようにする。これにより、構造上のより良いデザインが見つかる可能性が高まるほか、チームも変化に慣れ、柔軟に対応できるようになる。
ただし、チーム構造の変更は、組織の規模的な拡大や戦略の変化を起点に行われるべきものでもある。例えば、先に触れたとおり、アトラシアンでは、戦略を起点にエンジニアリングチームの組織構造を決めている。そのため、チームの再編は年次計画策定の直後に毎年実施するようにしている。
また、チーム構造の変更には、たとえそれが小さな変化であっても、一定のストレスをチームにかけるという問題もある。とはいえ、エンジニアリングチームのメンバーが変化を受け入れることで、各メンバーはより優れた“コラボレーター”となり、より優れたエンジニアへと成長すると、チェン氏は指摘する。
「ゆえに、Slack社のエンジニアリングチームは常に変化を受け入れるようにしています。エンジニアリングチームは“納期”に追われているので、変化をネガティブにとらえがちですが、変化は進化であり、自身を成長させるチャンスです。それをポジティブに受け入れることが重要です」（チェン氏）。
4. 役割と責任範囲を明確に決めておく
前述したフラットなトライアド型のチーム構造は、机上の“絵”としては、合理的で美しく見える。ただし、誰がエンジニアリング、プロダクト、デザインそれぞれの最終責任を担い、誰が誰に対して貢献するかを明確に決めておかないと、チームは機能しなくなると、ジャヤスリヤ氏は指摘する。
「例えば、チームの成果物が十分なレベルに達していると最終的に判断するのは誰なのかが明確でなければ、チームの作業は前に進みません。この辺りの問題は、チームが大規模になればなるほど深刻さを増すので、リーダー層を含めたメンバー各人の役割と責任範囲を明確に定義しておくことは非常に重要です」（ジャヤスリヤ氏）。
5. 実験の機会を用意しておく
エンジニアリングチームは、プロダクト作りにおいては新たなアイデアを試すことを恐れないが、組織的な“実験”には恐れを抱く傾向が強い。
ただし、エンジニアリングチームは、組織的な変化も恐れてはならず、プロダクトの開発を反復して行うのと同様に、組織構造についても、実験と検証を反復して行う必要があるとメンデス氏は指摘している。
6. コミュニケーションを密接にとる
エンジニアリングチームの構造変更には、相応の人的コストがかかることが多い。したがってリーダー層は、変更の優先順位を決めたうえで、チームのメンバーと密接にコミュニケーションをとり、変更にどの程度のコストがかかるのかを見定めておくことが重要となる。
また、ジャヤスリヤ氏は、「チームのメンバーにとって最も衝撃の強い組織の変更は、マネージャーの交代です」と語り、次のように続ける。
「マネージャーの交代が、数回立て続けに行われると、メンバーの消耗はかなり激しくなります。というのも、マネージャーはチームメンバーのキャリアパスや報酬について責任を持つ人だからです。その人が頻繁に変われば、メンバーが会社やマネージャーへの不信感を募らせるのは当然の帰結と言えます。そうした不信感を払拭するには、変更に至った経緯について、組織の幹部やマネージャーとメンバーとの頻繁で、オープンなコミュニケーションが必要とされます」
継続的改善を成功させるには
エンジニアリングチームの組織的な変化はコンスタントに発生し、その全てが容易な取り組みではない。そのため、チームを組織したり、改革を行ったりする際には、「なぜ、自分はこの組織モデルを試そうとしているのか」、あるいは「試す必要があるのか」を自問し、それに対する答えを明確にしておくことが重要となる。
多くのエンジニアリングチームの構造には共通性があり、他社のチーム構造を知っておくことは有益であり、自社のチーム構造を考えるうえでの参考にはなる。
ただし、全てのチームは基本的にユニークな存在であり、それぞれが異なる機能を持ち、必要とするモノゴトにも違いがある。そのため、優れたエンジニアリングチームは、どのチームも、一般的な「組織モデル」や他社の成功モデルをそのまま取り込むのではなく、自分たちの利益のために何が必要とされるのかを理解したうえで、組織構造の最適化を図っているようだ。
ゆえに、目標として定めるべきは、構造改革の繰り返しと、それを通じた調整に対する意欲のあるチーム文化を育むことと言える。この文化は、従業員同士の相互信頼や率直さを土台にしたオープンな組織文化と成長へのマインドセットの上に成り立つものでもあり、それらが、エンジニアリングチームをより実り多き領域へと引き上げる推進力となる。
また、エンジニアリングチームのアジリティ（俊敏性）を確保するには、チームのリーダーとチームに多くの権限を与え、トップダウンのマネジメントは行わないことが重要である。
繰り返すようだが、成功企業の組織モデルをコピーしただけで、自分のチームが抱える問題が解決されるわけではない。
まず必要なのは、自分のチームに対する理解を深めて、問題点を徹底的に洗い出すことである。それによって初めて、確立された組織モデルを自チームの問題解決に役立てていくこと、そして、チームの構造をダイナミックに変化させながら、適切な調整、あるいは継続的な改善を行っていくことが可能になるのである。
