波乱万丈の 2020 年は、ソフトウェア デリバリー チームにとってスムーズにサイクルを回せる体制が競争上の優位性となることが明らかになった年でもありました。だれもが COVID-19 (新型コロナウイルス感染症) に見舞われ、リモート中心どころかリモートのみで業務を行わねばならなくなる中、数多くのエンジニアリング チームが数多くの手動プロセスを見直す必要に迫られました。だれかのデスクにビルド用マシンがあるという前提や、マシンに問題が発生したら再起動すればよいという前提が突然崩れたのです。まったく唐突に、すべてを自動化しなければなりませんでした。
この自動化という概念、つまり業務の高速化と信頼性向上の取り組みは、もはや “あったら便利” というものではなく、今やソフトウェア デリバリー チームの中核的な責務となっています。私は幸運にも、エンジニアに価値を提供することに重点を置いた、開発者ファーストの企業を率いているのみならず、世界中の何千もの素晴らしいチームが構想からデリバリーまでコードを作り上げることをサポートできています。個人的に、エンジニアリング チームに自動化を推進する最適な方法については確固たるアイデアをいくつも持っています。しかし、1 つ確かなのは、どれだけ高度で便利な自動化ツールであっても、成功要因として “人” が欠かせないことです。
企業において、パンデミック下における最初のフェーズはシステムに関連するもの、つまり、業務の完全リモート化のためのテクノロジー スタックの構築と更新でした。次のフェーズでは、チームと人材に焦点が当たることでしょう。
教訓: 困難に強いソフトウェア チームを作るには
チームの規模は、日常業務もこなしつつイノベーションもできるほど十分に大きくすることが不可欠です。このことは、ユーザーの期待と要求が劇的に大きくなったこの時代に特に重要になっています。継続的に増える保守やエスカレーションの負担に対処するには、十分な人数のコントリビューターが必要です。チームが小さすぎると、イノベーションのペースも下がります。
ホースの圧力を保つこと、つまり前進する意欲を保つことが、チームにも顧客にも重要であり、一定のリズムでイノベーションを続ける必要があります。コミュニティの要望に応え続けていくことで、一定のリズムと、確実に前進しているという手応えを与えることができます。
困難に強いソフトウェア デリバリー チームの構成は、次のようになっていることが望ましいでしょう。
- ユーザー本位の機能の担当者が 50% (プロダクト開発の目的は、ユーザーの生活をより良くすること)
- 技術的投資の担当者が 25% (システムの保守をするには何をする必要があるのか。つまずくとしたらどこか)
- エスカレーションや不具合の担当者が 25% (期待どおりにシステムが動かなくなっていないか。システムが壊れたことで、ユーザーが開発できなくなっていないか)
システムが大きくなるにつれ、保守に割かれる時間も当然増加します。ユーザーを重視した作業の割合を維持するには、チームの規模を大きくしなければなりません。その結果、チームが大きくなりすぎたら、小さなグループに分割しましょう。いわゆる、Amazon の “チームのメンバー数はピザ 2 枚分” ルールです。
理想的なチームの規模は、経験、全体的な責任範囲、オンコール業務の量などにより左右されますが、5 人から 20 人のコード コントリビューターが適切だと言えます。もちろん、コミュニケーションや調整のコストがかさむため規模の拡大にも限界はあります。それでも、サービスの保守とイノベーションの継続を両立できるだけの人数の開発者を確保することが常に必要です。
現在は特に、チームは大きいほどベターであると個人的に考えています。その理由は、どれだけ綿密に計画を立てていても人生は思いどおりにはいかないということを 2020 年に実感したためです。チームが小さすぎると、だれかが長期休暇を取ったり、緊急事態に陥ったり、あるいは単に休息が必要になったりしたときに、業務の継続が困難になる可能性が高くなります。
チームには、人生の中で起こる不測の事態を吸収できるほどの人手が必要なのです。
分散型チームを目指すには
困難に強いチーム作りそのものが難しいなら、それを分散型チームで実現するのはなおさら大変でしょう。どんなチームでも直面するような課題の多くは、離れた場所にいて時差がある場合にはさらに難問になるからです。どれほど効率的にチームを構築して指揮できる方法であっても、安易に適用することはできません。そのため、リーダーとして想像力を発揮することが求められる場面が増えるのです。
個人的な経験でいうと、成功を収めるリーダーとは、体制を構築し、つながり、コミュニケーション、コラボレーションをサポートすることに専念する人でした。
私たち人間は、大きな目的を達成するためにつながろうとします。それだけでなく、周囲の人々とのつながりを感じていたいとも思う生き物です。会話の相手がいつもビデオ通話画面のピクセルやチャット アプリのアイコンとして表示されていると、画面の向こう側にいるのが人間であることをつい忘れてしまいそうになります。何よりもまず、チームメイトを 1 人の人間として捉えて興味を持ち、そのやる気の源について理解する必要があります。
リーダーには、期待する基準を常にチームの全員に明確に伝える責任もあります。急成長中の組織では、その重要性がひときわ高まります。CircleCI のエンジニアリング チームは数年前、前年比で 2 倍の規模になり、グローバル展開をさらに広げました。対照的に、経営陣は驚くほど少人数でした。エンジニアリング チームがこれだけの成長を遂げた結果として、エンジニアリング文化の変化にまつわる課題にも直面しました。知識を共有できていないことが多々あり、ビジネスを拡大するための方法を見つける必要がありました。
そこで私たちは、エンジニアリング コンピテンシー マトリックスを作成し、採用から体系的なフィードバック、業績評価まで、あらゆる場面で活用することにしました。このマトリックスは、全員に同じ基準を遵守させ、ビジネスの拡大に伴って変化する期待を明確にするために役立っています。
コラボレーションも重要です。分散型チームではどうしても、タイムゾーンの近いメンバーどうしで小さな “サブチーム” に分かれてしまいがちです。この事態を回避する方法の 1 つが、タイムゾーンをまたぐ作業を積極的に行う “ピンポン ペアリング” です。ピンポン ペアリングとは、従来の “ペアプログラミング” の非同期バージョンです。
ピンポン、つまり役割交替をスムーズに行うコツは、次のとおりです。
- 進行中の作業のカードは 3 枚までに抑える。こうすることで、新しい作業を開始する前に、進行中のチケットを確認する習慣が身につきます。
- 進行中の作業のプル リクエスト (PR) はなるべく早くポストする。その時点でそのタスクに取り組んでいる担当者がいなければ、他のだれかが PR や関連するやり取りに目を通し、タスクを引き継げるようにします。
- 進行中の作業をハンドオフする。Slack を使用して非リアルタイムでハンドオフする方法もありますが、もし他のメンバーと勤務時間が重なっているなら、ビデオ通話でハンドオフしてもかまいません。一方のメンバーの終業時刻ともう一方のメンバーの始業時刻が重なるタイミングがお勧めです。
結局のところ、プラットフォームやサービス、テクノロジーの耐久性が、CI/CD 手法、クラウドベースの監視、テストなどの DevOps プロセスの質によって左右されてしまうのはたしかです。しかし、重要なのは人です。
パフォーマンスの低下が見られるようになったら、それは疲労のサインです。困難に強いシステムやチームを、今すぐ、そして長期的に構築できるかどうかは、私たちビジネス リーダーの手腕にかかっています。効率的なソフトウェア デリバリー チームを作成するために欠かせない要素の 1 つは、それらを実際に動かしている人々を優先することです。
困難に強いソフトウェア チームを作成する方法に興味を持たれた方は、ぜひ『2020 年版ソフトウェア デリバリーに関する現状調査レポート』をご覧ください。
この記事の出典: DevProJournal(英語)
