大規模組織で開発者の創造性を伸ばすスペースを創り出す

2025年3月11日 // 1 min read

image

規模の拡大に伴う複雑化を管理しながら創造性を伸ばすスペースを確保する方法

GitHub エグゼクティブ インサイトで公開 | 執筆者: Jakub Oleksy および Matt Nigh

すべてのエンジニアリング組織は、組織の規模が大きくなるにつれて、当初の成功を可能にした創造的エネルギーが、既存のビジネスを維持して成長させる必要性と衝突を起こすようになるという成長ジレンマに直面します。ユーザーが増えると、それだけ複雑性も増します。複雑性が増すと、より多くのプロセスが必要になります。製品を作り上げた革新精神が、突如として幾重ものガードレールの下に埋もれてしまうのです。

これは、GitHub が身をもって経験している課題です。GitHub では、世界中何百万人もの開発者にサービスを提供する需要と、GitHub を形作ってきた創造性や情熱の育成とのバランスを絶えず保たなければなりませんでした。

創造性はオプションではありません。複雑な問題を解決し、パフォーマンスを最適化して、ユーザーを満足させる機能を構築する手段なのです。開発者が他とは違う考え方をし、自由に実験する能力は、企業の成功に直接影響を及ぼします。

規模の拡大に伴う複雑化を管理しながら創造性を伸ばすためのスペースを創り出して保護するにはどうすればよいのでしょうか? 開発者が大規模組織の制約内で作業しながらイノベーションを起こし、実験する能力を維持できるようにするにはどうすればよいのでしょうか?

大規模な課題

組織が成長すると、明らかなパターンが表面化します。数々のアイディアを開花させてきた箇所で、一貫性を求めるようになるのです。大規模に創造性を維持する上で最も大きな成功を収めるアプローチは、標準化や一元的な投資からメリットを得る箇所 (共通のプラットフォーム コンポーネント、セキュリティ、デプロイ、インシデント対応など) に焦点を当てながら、他の箇所でダイバージェンスや探求を可能にすることです。

標準化は制約する代わりに可能性を広げ、明確な境界内で迅速に行動する自信をチームにもたらす必要があります。

例えば、GitHub ではインシデント管理ライフサイクルに投資して標準化しました。この専任チームは、GitHub のすべてのチームが従わなければならない明白なベースラインを設定するツールとプロセスを提供します (一貫的な SLO、モニタリング、アラート プラクティスなど)。また、これらの標準に従うことを簡単かつ効果的にする共通のツールも提供します。共通のダッシュボード作成機能、Slack オートメーション、さらには RCA やその他のインシデントプロセスに使用するシンプルな標準テンプレートにも投資しました。これらの強化機能は革新的ではないものの、こうした機能が提供する一貫性により、全員が互いに理解し合える方法で可用性に関する GitHub 全体での会話を持てるようになりました。

これが皆さんのチームや組織にとってどのような意味を持つかは状況に応じて異なりますが、これを評価する 1 つの方法は、問題となっている分野にイノベーションが必要なのか (既存のエクスペリエンスに AI を導入)、それとも単に効率性を向上させるための標準が必要なのかを考えることです。後者は明らかに、組織全体の負担を取り除き、それを中央チームに任せるための共通の投資が理にかなう状況です。

__規模は複雑性をもたらし、それがリスクへの強い嫌悪感をもたらします。__かつては新しいアプローチを使って自由に実験していたチームが、より大きなシステムとユーザー ベースに影響が及ぶ可能性の懸念に束縛されるようになります。そうなると、組織の安定性に頼る無数のユーザーにサービスを提供するという現実を認めながら、実験の精神を維持することが課題になります。これは、安全な実験を可能にするシステムやツールへの一元的投資が極めて重要になるもう 1 つの箇所です。

最近、GitHub ではフィーチャーフラグ システムの再設計に投資して、リリースを大規模に管理できるようにしました。かつては、単一のウェブサイトの観点からこの問題を考えればよいだけでしたが、現在は GitHub アプローチを進化させて、GitHub.com、データ格納クラウド、サーバー製品全体のフィーチャーフラグに標準管理を導入しています。また、さまざまなセーフ デプロイ プラクティスにも多額の投資を行って、実験を低リスクで実行できる土台を構築しています。

組織が成長するにつれて、イノベーションが特定のチームや分野に集中しがちになり、これら以外のチームや分野は業務を遂行するだけの状態になります。すべてのチームにある程度の創造性をもたらすと同時に、すべてのチーム、そして製品のすべての側面に同じレベルの創造性が必要だとは限らないという点を認識しておくことが重要です。GitHub のような大規模組織でさえも、製品の側面をさまざまなステージに分類することができます。GitHub Copilot への最先端投資のようにスタートアップ的なものもあれば、Advanced Security のように、活発に成長すると同時に革新的でもあるより成熟したビジネスもあります。また、より安定した運用状態のものや、廃止予定のものさえも存在します。これらの各ステージには、さまざまタイプの投資と、さまざまなレベルの創造性が求められます。

これらのチームの異なる性質を考えると、チームや個人の士気の現状に対処する必要もあります。全員が一人ひとり異なり、イノベーションが起こるこのパターンの進歩主義的な面に関与することを好む人もいれば、成長、最適化、継続性のためのより持続的でしばしば大規模な技術的問題を好む人もいます。

リーダーとしての私たちの課題は、これらのチームと個人それぞれのために創造性を可能にすることです。

基盤: 時間

最も生産性が高かった日のことについて開発者にたずねてみてください。開発者はおそらく、コードに完全に没頭できた、めったとない完璧な瞬間について話してくれるでしょう。時間があっという間に過ぎ、複雑な問題が自然に解き明かされ、解決策がおどろくほどはっきりと浮かび上がってきます。これが「フロー」であり、開発者の創造性におけるバックボーンです。

GitHub で実施される開発者満足度アンケートでは、Sync Meeting が生産性と創造性を殺しているという厳しい現実が常に浮き彫りにされます。「簡単な」ミーティングやチェックインは、スケジュール時間を浪費するだけでなく、集中力も台無しにしてしまいます。

コンテキスト切り替えのたびに、中断そのものにかかる時間よりもはるかに多くの損失が生じます。開発者がフローを達成できなければ、時間よりも多くのものが失われます。これには以下が含まれます。

  • 深い洞察力を伴う問題解決能力
  • 複雑な課題に対する創造的な解決策
  • コードの品質と保守性
  • 開発者の満足度

中断のないまとまった作業時間を優先することで、イノベーションが自然に生み出されるようになります。

検討できる 1 つアプローチは、1 週間の勤務時間を 5 個の午前ブロックと 5 個の午後ブロックの 10 ブロックに分割することです。開発者のためにこれらのブロックをいくつ確保できるでしょうか?

創造的なスペースを創り出すための 3 つのアプローチ

個人レベルで時間を確保することは重要な基盤ですが、時間確保の問題はより体系的にアプローチすることもできます。

1. リングフェンスされたイノベーションチーム

創造性を大規模に維持する 1 つの方法は、イノベーションだけに焦点を当てる専任チームを組織することです。GitHub ではこのチームを「GitHub Next」と呼んでおり、GitHub Copilot などの最も変革的なアイディアのいくつかがこのチームで生み出されました。

GitHub Next の成功における鍵の 1 つは、日常的な業務上の制約からの意図的な分離です。これらの開発者は、オンコール ローテーションを通じてより大きな組織のサポートに駆り出されたり、緊急の本番環境問題に気を取られたりすることがありません。その代わり、探求し、実験して、開発の未来について深く考える自由があります。

自由があるからといって、方向性がないわけではありません。GitHub Next は、開発者が作業する方法を根本的に変える可能性のあるテクノロジーを探求するという明確な期待のもとで業務を行っています。チームには、この目標の追求方法について大幅な自主性が認められていますが、最終的により広範な開発者コミュニティにメリットをもたらすことができるイノベーションの実現に対する責任を常に負っています。

2. 日常業務への創造性の組み込み

すべての組織が 1 つのチーム全体を専属にできるとは限らず、そうすべきでもありません。創造性は、既存のエンジニアリングチーム内で発展する必要もあります。これは、キャパシティを管理する方法から始まります。

100% のキャパシティで運営される高速道路は何と呼ぶでしょう? 駐車場です。これはチームにも当てはまります。すべての時間を差し迫ったニーズに割り振っていると、創造的な考え方をする余裕はなく、イノベーションのためのスペースもなければ、予期しない事柄に対応するキャパシティもありません。

チームは、意図的にキャパシティにゆとりを持たせておく必要があります。呼び名が 20% タイムまたはイノベーション スペースであるかにかかわらず、創造性には余白が必要だという原則は変わりません。

3. 創造性キラーの排除

創造性を脅かすのはトイル、つまりエネルギーを消耗させ、可能性の無駄にする反復的な手作業です。GitHub では、膨大な時間と精神的エネルギーが消費される可能性のある手動での操作がチーム内で行われているのを目にしてきました。

例えば、GitHub のインフラストラクチャチームは以前、サーバーの管理やインシデント対応の処理を手動で行うために大量の時間を費やしていました。この絶え間ない業務上の負担は、時間を消費するだけでなく、士気も失わせていました。複雑なアーキテクチャ課題を解決する代わりにサーバーを手動で再起動するプリンシパルエンジニアになった自分を想像してみてください。

それ以来、GitHub ではオートメーションを最優先事項とし、トイルの排除は単に効率性に関するものではなく、創造性を活気づけるスペースの創出に関するものであることに気付きました。定形化されたタスクを自動化することで、開発者は困難でもやりがいのある作業に焦点を当てることができるようになります。

創造性イネーブラーとしてのオートメーション

定型化されたタスクから解放された開発者は、イノベーションに必要な精神的な余裕を取り戻します。

オートメーションで成功を収めるための鍵は、すべてを一度に自動化しようとすることではありません。その代わりに、次の質問を問うことで高インパクトな機会を探します。

  • 開発者をフロー状態から繰り返し引きずり出すタスクは何か?
  • 人為的エラーが最も発生しやすい手動プロセスはどれか?
  • 開発者が最も多くの不満を示すのはどの箇所か?

開発者満足度アンケートを実施して、開発者からフィードバックを集めます。開発者が一貫して骨の折れるデプロイ プロセスや単調で退屈な設定タスクに言及する場合、オートメーションが最も大きな影響をもたらすという指標になります。

__オートメーション文化の創造__に投資して、チームが手作業に関するチームの考え方を変えましょう。これは、以下を行うことで実現します。

  • オートメーションを副次的なタスクと見なすのではなく、第一級プロジェクトとして扱う
  • 最も大きな影響を生み出す分野でのオートメーション作業を優先する
  • オートメーションを通じて手動 KTLO (Keeping the lights on、現状維持) 業務に携わるチームが費やす時間を削減する
  • オートメーション作業がチームの OKR (または同様の計画プロセス) に反映されることを確実にする
  • オートメーション作業にかかる明確な時間をチームに知らせる
  • リーダーシップにオートメーションの成功を称賛し、公に後押ししてもらう
  • これらの投資の価値を実証するデータを追跡して進捗状況を測定する

創造性マルチプライヤーとしての AI

GitHub Copilot は、開発者がフローと生産性を維持する方法を根本的に変革します。使い慣れないコードベースを使用していて、問題にぶつかった開発者を想像してみてください。従来、この状況はコンテキスト切り替えを意味していました。ブラウザを開き、ドキュメンテーションを検索し、同僚に質問するのです。この作業は、開発者のフローを中断し、進捗を遅らせます。

GitHub Copilot は AI 支援を統合開発環境に直接組み込みます。開発者は、開発環境から離れる代わりに作業しているその場でオプションを検討し、提案を受けることができます。これは、開発者が以下を行う上で役立ちます。

  • フロー状態を維持する: フローを中断させることなく、質問の回答とパターンの提案を受け取ります。
  • 探求を通じて学ぶ: 開発者は、さまざまなアプローチをすばやくテストして新しいパターンをリアルタイムで学ぶことができるため、学習が迅速化され、創造性が育まれます。
  • 精神的なオーバーヘッドを削減する: 開発者は、複数の言語とフレームワークにまたがって作業します。GitHub Copilot は、コンテキストに基づいた提案を提供し、開発者がその創造的エネルギーを重要な問題の解決に向けることができるようにすることで、この複雑性の管理を支援します。

GitHub Copilot は、コーディングの定形的な側面を処理し、統合開発環境内アシスタンスを提供することによって、開発者が人間のインサイトを必要とする創造的な課題に集中できるようにします。GitHub Copilot の機能向上は留まるところを知らず、最近の進歩は GitHub Copilot をペア プログラマーから、開発者に代わって複雑な作業をこなすことができるピア プログラマーへと変え始めています。さまざまなエージェント中心のエクスペリエンスに対するこれらの投資は、開発者とチームの生産性をさらに向上させていくでしょう。

まとめ

組織は、プロセスと創造性間、そして安定性とイノベーション間の絶え間ない緊張関係に直面しています。しかし、これは両極端の一方を選択するということではありません。両方を保護するシステムを思慮深く設計するということなのです。

最も大きな成功を収めたエンジニアリング組織は、開発者の創造性を運任せにしません。チームを構成し、時間を管理して、成功を測定する方法に関する意図的な選択を通じて、創造性をその DNA に組み組みます。

GitHub は、これがどのように展開するのかを実際に見てきました。

  • 不必要な中断から開発者の時間を保護することで、より有意義なソリューションがもたらされる
  • 安全に実験する空間をチームに提供することで、イノベーションが自然に生み出される
  • 開発者のトイルを削減することで、不満と中断の両方が少なくなる
  • 開発者の満足度を測定することで、集中的に取り組む箇所がわかる

一晩ですべてを変革する必要はありません。1 つのチームから始めましょう。スペースを創り出し、インパクトを測定して、学び、調整します。ミーティングがない日を実施する、小規模なイノベーションチームを編成する、または単に手作業を減らすかにかかわらず、創造的なスペースの確保に向けたステップそれぞれが勢いを生み出すのです。

GitHub での AI やその他のイノベーションの戦略的役割について、さらに詳しく知りたいですか? エグゼクティブ インサイトで、テクノロジーとビジネスの将来について、ソート リーダーシップの詳細をご覧ください。

Tags