【ITニュース解説】Melbourne SaaS Founders: The PH Engineering Playbook

ソフトウェア開発の現場では、予期せぬ問題に直面することが日常茶飯事である。例えば、アメリカのクライアント向けに開発していた決済システムの連携機能で、深夜に及ぶデバッグ作業を経験したことがある。問題は自らのコードではなく、特定の曜日のみで発生するサードパーティ製APIの奇妙な挙動に起因していた。このように、世界中でソフトウェアを世に出すことは、常に挑戦の連続である。

現在、オーストラリアのメルボルンにおけるSaaS（Software as a Service）業界は活況を呈しているが、エンジニアリングチームを効率的に拡大することは常に課題となっている。そこで注目されるのが、フィリピンの豊富な開発者人材である。これは単なる安価な労働力を求めるものではなく、高いスキルを持つプロフェッショナルへのスマートで費用対効果の高いアクセスを意味し、より迅速で高品質なソフトウェア提供を可能にする。しかし、異なる文化圏のチームと効果的に協業するには、いくつかの重要な学びがあった。

第一の教訓は、信頼関係の構築が単なるチャットツールでのやり取り以上に重要であることだ。当初、フィリピンのチームを他のリモートチームと同様に扱い、仕様を送り、デイリースタンドアップを求め、皆が同じ理解をしていると想定していた。しかし、複雑なPOSシステムを開発する中で、このアプローチが間違いであることに気づいた。例えば、優秀なフィリピン人開発者が、問題提起や代替案の提案にためらいを見せることがあった。これは、フィリピンの多くの職場文化において、権威に疑問を呈することや、能力がないように見られることを避ける傾向が強いことに起因していた。アメリカのテック業界で一般的な直接的なフィードバックは、彼らには攻撃的または見下しているように聞こえる可能性があった。結果として、開発者が懸念を表明できなかったために、プロジェクトの遅延により資金を浪費する事態も発生した。この問題を解決するため、コードレビューだけでなく、家族や週末の過ごし方、好きな料理など、個人的な話題を交えるための1対1のビデオ通話を始めた。フィードバックの伝え方も、「これは間違っている」ではなく、「これをより良くするために、どのようにすれば良いか一緒に考えてほしい。この課題についてどう思うか」というように、協力的な問題解決の形に変化させた。これにより、チームメンバーが安心して意見を言えるようになり、潜在的な脆弱性を早期に発見し、より安全な実装へと改善できた事例もあった。このようなコミュニケーションの変化は、単に親切にするだけでなく、チームの能力を最大限に引き出す上で極めて重要であった。

第二の教訓は、非同期コミュニケーションを効果的に活用しつつ、同期コミュニケーションの適切なタイミングを見極めることだ。例えば、ソーシャルディスカバリーアプリのバージョン2を再構築する際、マニラ、セブ、そしてアメリカに分散したチームで作業していた。12〜15時間という時差がある中で、すべてのミーティングを同期的に行おうとすると、開発者が深夜に参加せざるを得なくなり、持続不可能で非効率的であった。そこで、徹底的に非同期コミュニケーションへと移行した。詳細なドキュメント作成にはNotionを、複雑な機能やバグの説明には画面録画ツールのLoomを、タスク管理にはGitHub Issuesをそれぞれ活用した。すべてのコード変更には、詳細なプルリクエストの説明を添えた。例えば、メッセージングシステムの「リアルタイムタイピングインジケーター」機能の実装では、目標、ユーザー体験、技術的な実装、受け入れ基準などをNotionに明確に文書化した。これにより、開発者は自身のスケジュールでタスクに取り組み、要件を理解し、進捗を報告することが可能になった。結果として、同期的な会議は、ステータス報告ではなく、高価値な問題解決や戦略的議論のために使われるようになった。しかし、非同期に頼りすぎると孤立感が生じることも分かった。重要な意思決定や複雑なアーキテクチャの議論には、適切なタイミングでのビデオ通話が非常に有効である。例えば、データベース移行戦略を決定する際には、仮想ホワイトボードを使って図を描きながら1時間のビデオ通話を行うことで、長いメールのやり取りよりもはるかに速く合意に達することができた。重要なのは、いつ同期的なやり取りを行うかを意図的に決めることである。

第三の教訓は、人材だけでなく、インフラにも積極的に投資することだ。最初のいくつかのプロジェクトでは、ひたすら機能開発に集中し、インフラの整備は後回しになりがちであった。この軽視は、人材情報システムを開発していた際に深刻な問題を引き起こした。ユーザーベースの拡大に伴い、基本的なインフラ環境ではパフォーマンスが低下し、デプロイが遅くなり、時折サービス停止が発生した。このインフラ軽視の代償は大きく、システムが負荷に対応できず、潜在的なエンタープライズクライアントを失った。エンジニアリングチームは、新しい機能開発に時間を割く代わりに、トラブルシューティングに追われることになった。ダウンタイムと失われた収益の合計は、年間で数万ドルにも上った。現在のプロジェクトでは、インフラを最優先事項とし、AWSを使用し、インフラをコードで管理するTerraformを導入した。また、GitHub Actionsを用いた堅牢なCI/CD（継続的インテグレーション・継続的デプロイ）パイプラインを構築し、監視とアラートのためにNew Relicなどのツールも導入した。このような事前の投資は、立ち上げ当初のスタートアップにとっては贅沢に思えるかもしれないが、長期的には大きな利益をもたらす。例えば、大規模な更新をデプロイする際、ダウンタイムなしで本番環境に展開し、ロールバックも確実に行えるようになった。監視ツールはデプロイ後すぐにわずかなパフォーマンス異常を検知し、ユーザーに影響が出る前に修正できた。インフラとツールのコストは、生産性の損失や顧客離れによるコストに比べればわずかなものである。堅牢なツールと自動化に事前に投資することで、フィリピンのエンジニアリングチームは、不安定なデプロイや遅いサーバーと格闘するのではなく、価値あるものづくりに集中できるのである。

もし今からプロジェクトを始めるならば、マイクロマネジメントは絶対に避けるべきことの一つだ。特定の開発者に対して料金を支払っていると、あらゆるタスクに関与したくなる誘惑に駆られがちである。しかし、それでは場所を問わず高性能なチームを構築することはできない。タスクを割り当てて毎時間進捗を確認するのではなく、明確な成果を定義し、測定可能な目標を設定し、チームが「どのように」達成するかを自律的に考えられるよう権限を与えるべきである。開発者たちが自らの仕事を遂行することを信頼するのだ。自身の役割は、タスク管理から、チームを支援し、戦略的な方向性を示すガイドへと変化する。

これらの学びを自身のチームに適用するための具体的なステップを以下に示す。まず、今週中に重要なリモートエンジニアと1対1のミーティングをスケジュールすることだ。この時、コードの話はせず、彼らの日常、仕事以外の課題、役割の中で最も楽しいことなどについて話す。人間的なつながりを築くことを目的とする。次に、自身の知識ベースにある複雑なプロセスや機能の一つを文書化してみる。短時間のウォークスルーをLoomで記録し、情報が非同期的に共有されるべきテンプレートとして活用する。最後に、自身のCI/CDパイプラインと監視設定を確認する。デプロイは高速で信頼性が高いか、重要なメトリクスに対するアラートは設定されているか。もし改善点があるならば、今週中に一つでも小さな改善を行うことを検討すべきである。