2/18/2017

Googleでのソフトウェア・エンジニアリング (3.3、3.4)

Googleでのソフトウェア・エンジニアリング」と題する論文。

3.3. プロジェクト承認

ローンチ承認のプロセスは明確に定義されているが、Googleではプロジェクトの承認や取り消しは明確に定義されていない。Googleは会社ができて10年近く経つにも関わらず、今もマネージャ自身になっており、私はどのようにそのような決定になったのか完全に理解していない。一つには、これに対する取り組みが会社全体で統一されていないためである。全てのレベルでマネージャは、チームがどのようなプロジェクトを担当するか説明責任と結果責任があり、彼らが適切として裁量権を行使する。場合によっては、そのような決定は完全にボトムアップ方式で行われ、エンジニアがチームの範囲でどのプロジェクトを担当するか選択する自由を与えられる。他の場合では、そのような決定が経営者やマネージャがどのプロジェクトを先に進めるか、リソースの追加を行うか、キャンセルするかについての意思決定がトップダウン方式で行われる。

3.4. 会社の組織再編成

時々、経営判断で大きなプロジェクトを中止することがあり、その時、そのプロジェクトを担当する多くのエンジニアが新しいチームで新しいプロジェクトを見つけなければならない。同様に複数の地理的な場所にわたって分割されたプロジェクトが少数の場所に統合され、これを達成するために一部のエンジニアはチームやプロジェクトを変更する必要がある場合、「デフラグ(defragmentation)」の取り組みが行われる。そのような場合、エンジニアは一般的に、その地理的な場所で、可能な地位の範囲で新しいチームの役割を選ぶ自由が与えられる。あるいはデフラグのケースでは、別の場所に移動することで、同じチームとプロジェクトに残るオプションを与えられるかも知れない。

さらに、チームを統合・分割したり、レポーティング・チェーン(reporting chains)を変更するような会社の組織再編は、どのようにGoogleが他の大企業と比較すればいいか分からないが、かなり頻繁に行われるようだ。多くの場合、テクノロジー主導型の組織では、技術や要件が変化し、組織的な非効率性を回避するため、やや頻繁な再編が必要になる。