Pipedrive（パイプドライブ）のCTOであり、テクノロジーと組織のスケーリングの専門家であるAgur Jõgi（アグル・ヨギ）氏。イノベーター、創業者、Cレベル管理職としての経験を持つ。
すべてのテクノロジー企業は、チームが成長するにつれて現れる課題を認識している。品質を高く保つための取り組みが、初期の仕事を特別なものにした「火花」を鈍らせてしまうこともある。従業員数が増えるにつれ、好奇心をコンプライアンスに置き換えてしまうのは残念ながらあまりにも簡単だ。しかし、必ずしもそうなる必要はない。私は、それが必要なトレードオフではなく、構造と「魂」は互いを強化できると信じている。そのように設計すれば可能なのだ。
企業が設立された当初、小規模なチームは一般的に顧客に近い位置にいる。プロダクトビジョンは鮮明で、エンジニアはすべてのチケットの背後にいる人々の顔を見ることができる。残念ながら、規模の拡大はこのダイナミクスを変え、距離を生み出してしまう。ワークフローにユーザー共感を取り入れることで、その距離を縮めることができる。それには、リーダーが計画とインセンティブを調整する前に、彼らが解決している問題とその理由について明確なナラティブを共有することが含まれる。価値観はスローガンではなく、日々の選択を形作るガードレールなのだ。
妥協せずに素早く動く
自律的なチームを中心にビジネスを組織することは、焦点を失わずに成長する一つの方法だ。各チームは永続的なバックログではなく、ミッションと一連の成果を所有する。これにより、物事の進め方を選択する柔軟性を提供しながら、その選択と共に生きる責任を植え付ける。
もちろん、自律性にはガードレールが必要だ。それは共有プラットフォーム、明確なAPIコントラクト、健全なデータ管理、あるいはシステムの観察、セキュリティ、デプロイに対する一貫したアプローチかもしれない。チームが現場で意思決定できるようになれば、彼らは素早く効果的に動くことができる。
ここで透明性のあるアーキテクチャが大きな違いを生み出す。チームが正しい選択をするための明確な道筋が必要だからだ。構造化されたスタックは、少数の言語、フレームワーク、ツールと共に、デフォルト、テンプレート、レビュールールを使用する。これにより、ほとんどの決定を一度行い、チーム間で共有することができ、認知負荷を軽減できる。
もちろん、これは柔軟性がないということではない。実験するスペースを与え、もはや有用でなくなった慣行を廃止することも重要だ。アーキテクチャを開発者向けの製品のように扱おう—それにはユーザー、ドキュメント、バージョン、フィードバックループがある。
より大きな視点を考慮する
過度な最適化を避けることも重要だ。組織が成長するにつれ、企業に悪影響を与える可能性のある小さな勝利を追求するのはあまりにも簡単だ。変更を加える前に、3つの重要な質問をすることが不可欠だ：それは顧客体験を向上させるか？システムの信頼性を高めるか？チームの動きを維持できるか？これらのいずれかに対する答えがノーであれば、その変更は実装する価値がないかもしれない。
レビュー、承認、チェックリストなどのプロセスにも同じことが当てはまる。本当に報酬がある場合—あるいはそうしないリスクがある場合—にのみプロセスにステップを追加し、もはや必要でなくなった場合は削除することを検討しよう。結果をエンドツーエンドで測定し、数字を共有し、同僚にそれらを解釈する方法を教えよう。
組織が成長するにつれ、リーダーは部屋で最も賢い人物であることから、他者を最も良く増幅する存在へと移行すべきだ。つまり、より高いレベルで活躍できる人材を雇い、マネージャーに最高の人材を引き付けるよう指導し、エンジニアが率直に話せる環境を構築することだ。リトマス試験は簡単だ—あなたが不在でもシステムが機能し続ける、あるいは改善さえするなら、その構造は効果的だ。
組織の生命と魂
実用的な「儀式」も組織の魂を生き生きと保つことができる。顧客との会話は、オプションではなく、不可欠なビジネス慣行の一部として予定され、実施される。デモはスライドデッキではなく、成果に関するものだ。アーキテクチャレビューは、プラットフォームと製品を中心とした会話として枠組みされる。
可逆的な決定を許可し、チームが適応し学ぶことを可能にする一方で、不可逆的な選択はまれな、影響力の高い賭けのために取っておくことが重要だ。効率的に刈り込まれたコードや削除されたサービスを新機能と同じように称えよう。なぜなら、シンプルさは成功を助けるものだからだ。また、現時点で意図的に最適化していない領域の短い公開リストを保持することも価値がある。明確さは常に漠然とした野心に勝るからだ。
あなたの価値観はこれらの選択の基盤となるべきだ。例えば、それらはAPIの設計方法に現れ、コードレビューでは巧妙さよりも明確さが好まれる。そのような価値観はまた、チームは人間であり、人々は目的、勢い、成長するスペースを必要としていることを思い出させる役割も果たす。
結論
ビジネスのスケーリングは、あらゆる組織の初期段階で行われたすべての前提を試す。しかし、ガードレールを備えた自律性、決して停滞させない構造化されたアーキテクチャ、過度な最適化に対する規律を選択すれば、優秀さと俊敏性をトレードオフする必要はない。
エンジニアがユーザーの痛みを感じるため、あなたの製品ビジョンは鮮明なままであり、会社の魂はソフトウェアに見えるままだ。そして重要なのは、エンジニアリングチームのためのサポートシステムを構築し、そのチームが今度は顧客が愛する製品を構築することだ。
