QCon Plusカンファレンスは2020年11月に3週間にわたって開催された。11月11日水曜日、Randy Shoup氏は、テクニカルリーダを対象とし、効果的なチーム内外のコミュニケーションとコラボレーションに必要な重要な人材スキルのいくつかに焦点を当てた、テクニカルフォーク向けの非テクニカルスキルトラックを主催した。
最初の講演は、CircleCIの製品エンジニアリング担当副社長であるLena Reinhard氏によるものだ。「What Engineering Teams Need from Leaders Right Now (エンジニアリングチームにリーダが今必要なこと)」というタイトルの話は、変化、不確実性、急速な成長の時代を通じて、彼女が主要な組織から学んだ重要な教訓を共有することについてだった。
彼女は、世界の現状、人々が2020年のすべての課題にどのように対処しているか、そして統制の欠如が私たちの有効性に与えている影響について考えることから始めた。彼女は、さまざまなリーダシップの視野を見て、それを超えて取り組むことについてのアイデアを提示した。リーダとして、私たちはさまざまな運用範囲 (財団、短期、中期、長期) にわたって運用を展開し、それらの間で意図的に焦点を移すことができる必要がある。
基本的な側面について、彼女は、リーダにとって重要な出発点は、何よりもまず自分自身を管理する能力であると述べた。これには、深い内省で思考を管理すること、何がエネルギーを与え、何があなたを消耗させるかを知るためにエネルギーを管理すること、そして毅然とした優先順位付けと自己組織化を通じて時間を管理することが含まれる。また、運用範囲を管理し、戦略的思考のための時間を作り、現在の瞬間を超えたものに取り組む必要がある。
彼女は人のコアニーズのBICEPSモデルを提示した:
- Belonging (所属)
- Improvement (改善)
- Choice (選択)
- Equality (平等)
- Predictability (予測可能性)
- Significance (意義)
リーダとしての私たちの仕事は、これらがチームにどのように現れるかを理解し、効果的に現れることができる環境を作ることだ。彼女は、これらのコアニーズを、パフォーマンスの高いチームを可能にするものと、心理的安全性、信頼性、構造、意味、影響などの要素が人間のコアニーズとどのように一致するかを調査するため関連付けた。
チームには、自分たちのニーズを理解しているリーダが必要です。リーダにとって最も重要なツールは、チームのニーズを真に理解するために、真の好奇心を持って良い質問をする能力だ。
チームには強いリレーションシップが必要です。人々が同僚と知り合い、アイデアを共有できる環境を作りましょう。彼女は、リモートペアプログラミング、定期的な炉辺談話、読書クラブ、部門全体の会議、メンタリングプログラムの例を挙げた。
全体像 (戦略、ビジョン、私たちが行うすべての作業を導くより高いレベルのコンテキスト) に移ると、彼女は、最も重要なリーダシップのタスクの1つは、チームのリーダシップを奨励することであると述べた。
彼女は、管理 (複雑さに対処する) とリーダシップ (曖昧さに対処する) を対比し、リーダシップのスキルをあらゆるレベルで適用する必要があることを強調した。これには、さまざまな動作が求められる:
- 制御ではなくコンテキストをリードし、作業がどのような影響を与えるかを人々が理解できるようにし、人々が正しいことを行えるようにする
- OKRなどの手法を使用して、活動やタスクではなく、価値観、原則、成果に焦点を当てる
- 所有権を分散し、作業の流れのボトルネックと依存関係を取り除く
その後、彼女は現在の仕事について話し、リーダが組織全体でどのように連携を確保する必要があるかについて話した:
- 人々がさまざまなチャネルで何を期待できるかを知るためのコミュニケーションパターンを作成する
- 人々が知らないこと、そしてあなたのメッセージが確実に聞こえるようにするためにあなたが繰り返しコミュニケーションをとる必要があると仮定する
- ビジョンと戦略を絶え間なく伝える
- それを受け取る人々へのコミュニケーションを調整する
- クリアなフィードバスを見せる
- イルカになる - 一度にたくさんのコミュニケーションを試みるのではなく、頻繁に小さなバーストで浮上してコミュニケーションする
彼女は、リーダが小さな実験、非難のないインシデントレビュー、レトロスペクティブなどの手法を使用して継続的な学習の環境を作成できる方法について話した。回復力は、リーダがチームで育てることができるもう1つの重要な特性だ。彼女は、人々が新しい状況を発見し、受け入れ、受け入れるのを助ける1つのツールとして、Bridges Transition Model (ブリッジ移行モデル) を指摘した。
彼女は聴衆に尋ねることで終えた:
今、リーダとしてチームにどのように表しますか?
eBayのエンジニアリング担当副社長兼チーフアーキテクトであるトラックの主催者Randy Shoup氏が、2番目の講演「Communicating Effectively with Your Business Partners (ビジネスパートナーとの効果的なコミュニケーション)」を行った。この講演では、エンジニアが非エンジニアと効果的に傾聴し、理解し、コミュニケーションするために必要な考え方とテクニックについて説明した。
彼は、あらゆるコミュニケーションにおける信頼の重要性に関する基礎を築くことから始め、信頼につながる3つの側面を探求した:
- 動機 - 正しいものによって動機づけられているか?
- 誠実さ - 開放性、正直さ、透明性
- 能力 - 私たちが言ったことをする能力はあるか?
彼は動機に取り組み、アウトプットよりも成果に焦点を当てる必要があると指摘した。価値は、その仕事の量ではなく、私たちが行う仕事から顧客と組織が得る利益にある。これを達成するには、達成しようとしているビジネス指標と、それらが組織にとって重要である理由を理解する必要がある。また、ビジネス指標に寄与する顧客指標を明確に理解する必要がある。彼は、顧客とビジネスの指標につながる主要なエンジニアリング指標があることを指摘した (書籍 Accelerate「LeanとDevOpsの科学」を参照)。彼は、いくつかのエンジニアリングアウトプットを管理するのではなく、追跡することの重要性を指摘した。
彼は、エンジニアが尋ねる最も重要な質問を述べた:
私たちはどのような問題を解決しようとしていますか?
彼は、エンジニアは規律ある問題解決の訓練を受けており、これは、この分野のスキルを必ずしも持っていない非エンジニアの人々との会話にもたらすことができるスキルセットであると指摘した。このアプローチを導入して、顧客とビジネスの問題を明確にし、改善することが仕事である。
彼は指摘した:
誠実さについて議論し、彼は (それがそうであるようにそれを伝える) オープンで透明性のあるコミュニケーションの重要性を強調した。良いニュースと悪いニュースの両方を共有し、実際の状況を隠したり、曖昧にしたりしないでください。共有コンテキストを作成するには、エンジニアリングコンテキストを共有し、エンジニア以外に状況を明確にする必要がある。彼は、私たちがコンセンサスを得ることができない場合の意見の相違とコミットの必要性を指摘した。
誠実さのもう1つの重要な側面は、構造化されたコミュニケーションの定期的なリズムの価値だ。このコミュニケーションは、事態が悪化しているときだけでなく、一貫していなければならない。彼はSteve McConnell氏を引用した:
信頼の半減期は6週間です
彼は、透明性が信頼と尊敬を築くと指摘した。
コンピテンシーについて、彼は、私たちが一貫してメインの仕事をし、顧客の問題を解決し、価値を増す一貫した軌道を示す必要があることを指摘した。彼は、並行作業が多すぎて大量のバッチが発生する危険性を調査し、価値を頻繁に提供することで、変化する優先順位に適応し、ビジネスパートナとの信頼を維持できることを指摘した。
コンピテンシーのもう1つの側面は、見積りだ。見積りは、エンジニアにとって、およびエンジニアとビジネス/製品パートナの間の共通のストレスポイントだ。彼は、見積りが必要であり、見積りの要求を尊重することが重要であると指摘した。これは、組織の他の領域全体で計画する必要のあるビジネスの依存関係があるためだ。見積りを行うときは、見積りプロセスの不確実性レベルを明確にする必要がある。単一点の数値ではなく範囲を使用して不確実性を示し、作業の中で学習に基づいて見積りを調整する。
次に、エンジニアリングマネージャがビジネス/製品の人々とコミュニケーションをとる一般的な状況を使用して、これら3つの側面がどのように適用されるかを説明した:
- より速く進むための圧力
- 技術的負債
- サイトインシデント
彼はMartin Fowler氏を引用して終えた:
組織を変えることができなければ、組織を変えてください。
トラックの3番目の講演は、OptimizelyのDavid Van Couvering氏によるもので、「Lean and Accelerate: Delivering Value as an Engineering Leader (リーンとAccelerate: エンジニアリングリーダとしての価値の提供)」というタイトルだ。彼はリーン原則を調査し、それらが機能する理由と、ソフトウェアエンジニアリングで実際にどのように適用できるかを説明した。
彼は2つの情報源を使用して、トピックの重要な側面を特定した。Donald G. Reinertsen氏による The Principles of Product Development Flow と、Nicole Forsgren博士、Jez Humble氏、Gene Kim氏による Accelerate 「LeanとDevOpsの科学」 だ。
Accelerate「LeanとDevOpsの科学」の書籍について話すと、彼は、本の根底にある深い研究が、彼らが探求する実践が、チームの士気と関与だけでなく、ビジネス目標の達成に関してより良い成果をもたらすことを明確に示していると指摘した。著者は、高パフォーマンスを達成するための主要な貢献者として、無駄のない管理と開発の実践を呼びかけている。
Reinertsen氏の研究を参照して、彼は本の中にある深い数学と、ソフトウェア開発の機能を優先するときにしばしば無視される重要な概念が遅延のコストだと指摘した。製品のリリース時の遅延により、価値が大幅に低下する可能性がある。
彼は、バリューストリームの概念と、開発プロセスのすべてのステップが完了した場合にのみバリューを実現する方法、およびキューがプロセスの遅延と浪費を引き起こす大きさについて説明した。彼は、ソフトウェアデリバリキューは一般的に見えないため、公開および対処されないことが多いと指摘した。次に、サイクルタイムとその結果のキューの長さを計算する方法としてリトルの法則を導入した。累積フロー図は、処理時間とキューの長さを視覚化するための便利なツールだ。
彼は、待ち行列理論が、忙しいチームが結果として生じる待機時間のために指数関数的に長いサイクルタイムを意味することが、どのように意味するかを示した。これは直感に反し、マネージャがチームをフルキャパシティーにロードすることを回避する必要があることを意味する。より効果的なスループットを実現するには、スラックキャパシティーが必要だ。多くのマネージャは反対のアプローチを採用している。彼は、Reinertsen氏の調査から、10年以上にわたってマネージャが98.5％の容量でチームを運営していると、キューが非常に多くなり、スループットが低下することを示した。チームがこのような高キュー状態になると、この状態から抜け出して低キュー状態になるのはほとんど不可能である。
次に、キューの長さを短縮し、スループット率を向上させる方法についていくつかのアイデアを提示した。
最初のアイデアは、バッチサイズを小さくすることだ。小さなバッチには、次のような追加の利点がある:
- より速いフィードバック
- リソースのより効率的な使用
- システムの圧倒を回避する
- 変動を減らし、予測可能性を向上させる
- 無駄と書き直しを減らす（エラーはより早くキャッチされる）
- 管理オーバーヘッドを削減する
- モチベーションとエンゲージメントを向上させる
彼は、最適なバッチサイズは、調査中のシステムのコンテキストに基づいて計算する必要があると指摘した。
2番目のアプローチは、仕掛を制限する (WIP) ことだ。個人またはチームが一度に作業できるアイテムの数に上限を設定すると、中断されて別のタスクに切り替える必要がなくなり、結果としてコンテキストスイッチが発生するのではなく、1つの作業の完了に集中できる。次に、キュー内でのシーケンス作業を支援する手法を導入した。最初に最短ジョブを重み付ける。
彼は、WIPの制限をできるように成功させるには、リーダシップのサポートが必要であると説明した。この考え方は直感に反するものであり、WIPをどのように制限するかを説明することが重要だ。
