BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Conwayの法則に従った組織の成長

Conwayの法則に従った組織の成長

ブックマーク

原文(投稿日:2016/10/13)へのリンク

CrederaのJason Goth,Micah Blalock,Patricia Andersonの3氏はSpringOneで,技術的アーキテクチャとプロセスを再構築し,低下した生産性の回復と高品質なコード作成を実現する上で,Conwayの法則を利用した自らの経験について説明した。

Conwayの法則とは,“組織の設計するシステムには ... その組織のコミュニケーション構造をそのまま反映した設計になるという制約がある”,というものだ。つまり,チームの開発成果がその組織の内部的なコミュニケーションのあり方によって決まる,という意味である。

顧客の健康管理を行なう独自の分析プラットフォームを開発する過程において,Crederaは,ひとつないし2つの並行開発チームで成功したアーキテクチャやプロセスが,5つの並行開発チームにスケールアップした時には機能しない,ということを知った。対策として同社では,Conwayの法則に対する自らの理解に従って技術的アーキテクチャとプロセスを変更し,その問題を再定義した。その努力の成果として,低下傾向にあった生産性が反転し,高品質のコードを加速度的に構築することが可能になったのだ。2016年8月のSpringOneで同社は,その経験を公開した。

同社は当初,2つのスクラムチームによるコード開発で成功を収め,その成果によって,顧客から新たな業務を受けることができた。この新たな開発では,同時期の納期への対処としてさらに多くの開発チームを並行させる必要があった。このチームを増やしたことによって,彼らのそれまでの成果が機能しなくなったのだ。ごく単純なコード変更が複数のダウンストリームサービスに連鎖的に影響し,チーム間の調整作業が指数関数的に増え,会議が作業時間を侵食した。帰宅時間の早いチームと遅くまで作業するチームが現れるなど,チーム毎のワークロードも劇的に変化した。作業の志気は低下し,納期は延長されることになった。

技術面では,自らのコミュニケーション構造に合わせて,ソフトウェア設計の再編成が行われた。コードの分割可能性を最適化するために,オープン/クローズの原則が適用された。これによって,複数のチームが同じコードを対象に作業することによるコストは削減できたが,チームが重複するコードを書くという,彼らがGARY(Go Ahead, Repeat Yourself)というプラクティスが発生することになった。また,コードの分離を徹底するため,コードの重複によって発生する問題を回避する水平インターフェース領域を設定したが,これによって“容赦ないリファクタ”が何度か発生した。

組織的な面では,Crederaの“Conwayの法則”に反する作業を防ぐための対策がとられた。コードセットを別のものに迅速に移行可能なフレームワークを提供するため,コードの標準化は優先度を他よりも低く設定された。ひとりのメンバに,スクラムを実践する全チームに対するチームリーダの役割を担当させることで,チーム間のコミュニケーションの促進を図った。もうひとりのベテランであるBlalock氏が“生け贄の子羊”になって,既存コードとの関係やユーザミーティングに対応した。一般的な手法ではないが,チームメンバがスプリント中にチームを移行することも行なった。結果としてミーティング回数が減少し,チームのワークロードが正常になり,志気も向上した。最終的には,納期に対する負担感も少なくなった。

氏らの活動は,Fred Brook氏の著書“The Mythical Man Month(人月の神話)”から着想を得ている。その書では,コーディネーションのコストと作業の分割可能性の和が変革の効率に等しい,と定義されている。チームメンバの追加によって効率が向上するのは,その作業が分割できる場合に限られるのだ。

氏らはこのプロジェクトの一部として,マイクロサービスを使用したSpringプラットフォームを採用した。コードはAngularとJavaで記述している。

 

 
 

この記事を評価

関連性
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

BT