エンジニアリング組織における課題
アジャイル開発を前提にしてエンジニアリング組織を立ち上げる上では、技術・プロセス・文化にまたがる多面的なアプローチが求められます。既存のソフトウェア開発組織からアジャイル手法を導入する場合、フィードバックによる改善や反復的開発といった考え方になじむよう、文化的な変革が求められます。これまでの手法に慣れている人ほど、異なるやり方に抵抗を感じる傾向があります。また、開発から運用にまたがる複数チームが協業しなければならないので、目標の異なる複数チームを一致団結させるのは困難です。さらに、顧客からのフィードバックによって改善を続けるアジャイル開発では、ユーザーの意見を吸い上げる仕組みが求められます。
技術的にはDevOpsやCI/CDといった仕組み・プロセスを導入するのが、アジャイル開発を推進するポイントです。既存の組織で、これらのスキルを持った人がいなければ、導入の難易度はさらに上がっていくでしょう。また、スクラムマスター、プロダクトオーナーといったアジャイル特有の役割があります。これらの役割を果たせる人材を育成していかなければなりません。
アジャイル開発を継続していくと、それを大規模に展開していく必要があります。アジャイル開発は、小規模で小回りが利く状態で実施される印象を抱く人もいるかもしれませんが、製品やサービスが成長するにつれて、アジャイルの仕組みを、より広く組織に広げていかなければなりません。プロセスのシンプルさを保ちながらも、大規模で高い品質を保つよう、考慮が必要です。加えて、アジャイル開発を続けていると、各時点で最適だった設計が、後になって非効率に見えてしまう技術的負債の問題が避けられません。品質を保つよう、技術的負債を上手に管理するプロセスも必要です。
コンウェイの法則が成立するのはなぜか
エンジニアリング組織の構成を考える際に興味深いのが「コンウェイの法則」です。この法則は「システム設計は、組織構造を反映する」と言った解釈がなされています。例えば、サプライチェーン・システムを開発しているときに、在庫・決済・配送といったチームを構成していれば、アーキテクチャーも各チームで個別になりがちです。一方、フロントエンド・バックエンド・データベースといったチームを作っていれば、アーキテクチャーもその3層を想定したものになるでしょう。
システム開発は人間同士のコミュニケーションが大きな役割を果たします。アーキテクチャーとチームが関連してしまうのは、チーム内のコミュニケーションが容易なのに対し、チーム間ではそうもいかないからです。利害が異なり、調整が必要なため、チームごとにシステムが独自の進化を遂げる恐れがあります。
チーム間の衝突が起きたり、確認事項・ミーティングが多発したりした場合は、チームとアーキテクチャーが合っていないのかもしれません。共通の機能を複数のチームが使用しているのに、どこか一つのチームが抱えてしまっていては、コミュニケーションがうまく図れません。その場合は、共通の機能として切り出し、チームも分けてしまうといった考え方があります。
ある時期ではうまく動いていたチーム構成が、チームが拡大するにつれて、うまく働かなくなるケースもあります。アジャイル開発は少ないチームでの共同作業を推奨しているので、それぞれのチームが自律的に動けるよう、チームを分割する必要があります。また、将来のアーキテクチャーを考えた上で、チーム編成を構成するといった考え方もあります。
有名企業の組織図から分かる企業文化と戦略
米国大手テック企業の組織図を模した有名なジョークがあります。数年前に作られた画像ですが、未だに人気があります。Amazonは典型的な階層構造。Googleは二人の共同創業者と一人の経営者を筆頭に、Webのような複雑なパスを構成しています。Facebookはつながりを意識した製品のように、自律分散型のネットワークのようです。Microsoftは強力な各製品部門が相互に張り合うような状況が描かれています。Appleはカリスマである創業者スティーブ・ジョブスを中心に成り立ち、また、Oracleは買収と裁判で大きくなってきました。
出展: Bonkers World.
あくまで冗談で描かれたものであり、正確な組織図でなければ、現状を表したものでもありません。しかし、企業文化や製品戦略と組織は関係していることは確かです。また、どの組織図が優れているかというものでもありません。文化や戦略に合致しているかどうかが重要であり、明らかな正解もなければ、永遠に適用可能な組織図もありません。
アジャイル組織の成功例「Spotify モデル」
極めて現代的なアジャイル組織として有名になったのがSpotifyの組織構造です。音楽配信サービスを提供する同社は、プレイリストや音楽プレイヤー等、複数の機能を有しています。一方で、それらに共通してフロントエンド・バックエンド・Web・アプリといった要素があります。どの組織にもみられるものですが、Spotifyでもクロス・ファンクショナルな組織が必要になりました。また、全世界にユーザーを持つ同社は拡張性を重視しており、ユーザーが増えても耐えられる頑健な組織を求めていました。
Spotifyはスカッドと呼ばれる小さな組織をアジャイル・チームの小単位としています。そのチームが自律的に動けるよう支援します。まるで一つのベンチャー企業のように、製品計画から開発・テストを実施します。管理よりも自律性を重視した方法です。
スカッド間での協力が必要な際は、同じ役割を持った人同士が横串でコミュニケーションを取ります。チャプターと呼ばれる組織が組成され、必要な情報を共有します。例えば、デザインのチャプターがあれば、スカッド間で共有するべきデザイン方針が策定可能です。
スカッドとチャプターをまとめて、一つのトライブを構成します。トライブが一つの製品群と捉えられます。また、複数のトライブがあれば、ポートフォリオとして管理するようになるでしょう。
さらに、全ての組織をまたがったアドホックなチームを、ギルドと名付けました。研究会やサークルのような位置づけで、どの組織構成にも当てはまらない自発的なグループを指します。
自社のエンジニアリング組織をどう作るか
様々なエンジニアリング組織論を踏まえて、自社の開発チームをどう考えればよいのでしょうか。Spotifyのアジャイル組織が有名になった後、数年たち、様々なトレンドが発生してきました。
マイクロサービスは一つのキーワードです。アーキテクチャーの各要素を小さい単位で切り出して、疎結合に保ちます。コンウェイの法則に従い、チーム編成も同様になるでしょう。システムの複雑さを取り除き、開発を容易にします。
DevOpsの進歩も大きな影響を与えます。開発チームと運用チームをまたがって、素早いリリースを安定して行えるDevOpsの技術が、開発環境を改善してきました。マイクロサービス化とDevOpsが正常に機能すれば、あるチームのリリースが他のチームに影響しないといったメリットが考えられます。
アジャイル開発を前提としてエンジニアリング組織を作る際には、まず、現在の組織・プロセスと、あるべき姿とのギャップを評価するステップから始めるべきです。あるべき姿としては、顧客の要望へ柔軟に応えるとか、市場へ製品を投入するまでのサイクルを短縮するといった経営面から見たビジョンが影響を与えます。現在と将来を比較して、足りていない知識やリソースがあれば、それを準備する作業が求められます。
組織変革においては、小規模で比較的簡単なプロジェクトからパイロットとして試してみることが推奨されます。リスクを軽減しながら、より短い時間で効果を実感できれば、組織全体でアジャイル開発を導入する価値を理解することが可能です。コンウェイの法則を踏まえ、アーキテクチャーとチームを構成し、組織横断的な取り組みを行います。
新たな組織体制では、役割やコミュニケーションパスの整理が必須です。誰が何に責任を持つのか、誰に情報を伝達するべきか、どのような会議体を設けるのか、といった事項を決定します。アジャイル方法論には、デイリースタンドアップのような会議体に関する推奨があるので、自社に合わせて最適な方法を選択します。また、経営陣からのサポートは欠かせません。経営面からみて組織変革が必要であるというメッセージを継続的に伝えていくべきです。
アジャイル開発は反復的開発を推奨しますが、組織作り自体にも反復的な取り組みが必要です。小規模で試した後、何がうまくいったのか、改善するべきものは何かといったことを、メンバー全員で議論し、より良い環境を作れるよう目指します。
アジャイル組織立ち上げの経験談
筆者がアジャイル組織の立ち上げに携わった際には、開発の特性に応じて組織を分割する経験をしました。ある一つのチームでは、Webプラットフォームの開発を行っており、いわゆるアジャイル方法論へより準拠し、開発サイクルを回すといったプロセスを採用しています。もう一方のチームは、機械学習やAIアルゴリズムを開発する組織であり、より研究開発型のプロセスとなりました。アジャイル方法論は緩く採用するにとどめ、ユーザーからの要求は踏まえた上で、長期的なR&Dを並行して行えることとしています。組織構造やアーキテクチャーは、一度作ったら終わりというものではなく、継続的に見直していくべきものです。時には不満を覚えるメンバーもいますが、重要なのは、チームからのフィードバックを吸い上げる仕組みを設け、たとえ時間がかかったとしても、日々、組織やプロセスを改善させていくことが重要なのだと思います。
