Zenn
🐝

ソフトウェアのバグはコードそのものよりも組織構造から生じることが多い

2023/03/26に公開
#
バグ
#
論文
#
em
#
テックリード
#
人月の神話
tech

テックリードは組織を忘れられるか

人月の神話にも組織構造とバグの話がある

ソフトウェア開発においてバグなく安定したシステムを作るのは永遠の課題です。バグを防ぐためにコードレビューをしますし、テストコードを書き、モンキーテストやドッグフーディングをすることもあるでしょう。

しかし、しばしば働いている人や組織トポロジーは無視されがちな印象です。Fred Brooksは人月の神話の中で、ソフトウェアシステムにおいて日程の遅延や不具合は異なるチームのミスコミュニケーションから生じることが多いと語っています。離職率が高い組織で知見が共有されずにバグが出たり、隣の部署は役所、チームの境界設計があまく全ての人員が全てに精通している前提の認知負荷の高い組織の話はよく聞く話のように思います。

Microsoft Researchがこういった話を統計的に精査した論文、「The Influence of Organizational Structure On Software Quality: An Empirical Case Study」の中で組織構造の品質への影響を分析しており、今回内容を追ってみます。2008年の研究。

分析に使われたコードはWindows Vista

さてこの論文、残念ながら世の中の全てのソフトウェアプロジェクトについて調べたものではありません。商用プロジェクトのコードと組織構造両方手に入ることが稀なので仕方ないですが、Windows Vistaの組織とコードをベースに分析されています。

5,000万行のコードベースから生成された3400程度のバイナリが対象。リリース後のバグが集計対象です。

VistaはWindows開発経験のある管理職比率が高め

組織構造でいうと

  • 33%のエンジニアがWindows Server 2003かXPの開発経験あり
  • 61%のエンジニアがWindows Server 2003かXPの開発経験のある管理職を持つ
  • 37%の管理職のマネージャー(=部長級)がWindowsの開発経験あり
  • 1つのバイナリを平均31人が変更
    • 平均2/31人がWindows Server 2003と同じバイナリを担当
    • 平均15/31人が前のバージョンのWindowsを担当
    • 平均14/31人が他のWindowsがMicrosoft製品の開発経験あり

になっています。

時たま管理職はコードをわからなくてもいいと言う主張がされることもありますが、 Windows Vistaの開発では同じジャンル(Windows)の開発経験のある管理職が多い印象ですね。Twitter、Metaの管理職にコードを書くよう要求する潮流を見ると、個人的には技術のぽっと出係数が減ってくるとエンジニアリングマネージャーもプレーはしないレビューマネージャーくらいに収束する気もしています。

1バイナリに31人関わるのはtwo pizzaルールの5人〜10人を超えていますが、その中でさらにチームがモジュール化されていることもある模様。数千人開発者がいるようです。

組織かコードか6つの予測モデル

バグを起こすのは組織とコードどちらが多いか分析するために6つのモデルが作られています。

  • 組織構造モデル
    • エンジニアの数(NOE): コードを触る人数は少ない方がいい
    • 退職したエンジニアの数(NOEE): 退職者は少ない方がいい
    • 変更頻度(EF): コード修正は少ない方がいい
    • コード承認者の最大深さ(DMO): 権限移譲されている方がいい
    • 課の人数/部の人数(PO): 担当の組織は凝縮している方がいい
    • コード変更の所有度(OCO): コード変更は同じ課で完結する方がいい
    • エンジニアのコード所有度(OOW): 変更は担当がした方がいい
    • 組織交差度(OIF): 変更は部署外からない方がいい
  • コード変更モデル
    • 変更行数
    • 変更頻度
    • 連続変更頻度
  • コード複雑性モデル
    • 循環的複雑度、LOC、グローバル変数の数など19の指標を元に計算
  • 依存性モデル
  • コードカバレッジモデル
  • リリース前欠陥モデル

組織構造モデルの各要素はそのまま一言で書いても分かりづらいので少し意訳しています。大組織なのでいろんな部署をまたいで1バイナリのソースコードを変更するシーンがあると思ってもらえるとよいかと。

本来コードの変更はある種時系列データですが、論文ではrandom splitしているようです。リリース後のバグを見ているので一応リークはしていないはず。

コード変更モデルのいうコードの変更は要望があるから変更している気はしますが、実装前レビューをある程度すれば減らせるということでしょうか。

リリース前欠陥モデルはかなり後工程なので、バグを防ぐ分析に使えるかというと微妙かもしれない。

結果: 組織構造がバグの一番の原因

結果です。

Precision、Recallを並べて比較しており、組織構造がバグ発生の予測モデルとして一番いいです。なので、ソフトウェアのバグはコードそのものよりも組織構造から生じることが多いと言えると思います。

コードカバレッジはPrecisionが高いですがRecallがかなり低いですね。テストは書いた方がいいですが、テストを書いてもバグは防げないと言えるかもしれません。コード複雑性、依存性の方がRecallは高い。

lintによってはABC Sizeを測ってくれたりしますが、モニタリングまでしている会社は少ない印象です。Four Keysの変更失敗率をどう下げるかといえばコード複雑性、依存性をスコア化してモニタリングすることかもしれない。

Architecture Decision Recordsを書く文化もそういったテストだけではカバーできない部分を補完するために、単なる検討資料とは違う概念として明示化したというのが自分の理解です。

コードオーナーシップが重要

組織構造のどれが一番効いてくるのか知りたいところですが、weightは書いてないですね。。。スピアマンの相関係数のみ。

0.70以上だけ抜き出すと以下なので

変更頻度(EF)と退職したエンジニアの数(NOEE)はエンジニアの数(NOE)で代用できる、コード承認者の最大深さ(D(M)O)、エンジニアのコード所有度(OOW)、課の人数/部の人数(PO)
はコード変更の所有度(OCO)で代用できるとすれば

  • エンジニアの数(NOE)
  • コード変更の所有度(OCO)
  • 組織交差度(OIF)

をモニタリングすればいい感じでしょうか。

エンジニアの数(NOE: Number of Engineers)はバイナリを触って退職していないエンジニアの数です。コードを触る人数は少ない方がいいです。

コード変更の所有度(OCO: Level of Organizational Code Ownership)はコードの変更のうちオーナーに当たるチームが変更した割合。コード変更は同じ課で完結する方がいいです。

組織交差度(OIF: Organization Intersection Factor)はコード変更量のうち10%以上変更した組織の数。変更は部署外からない、少ない方がいいです。

コード変更の所有度、組織交差度はかなり概念が近いですね。エンジニアの数と合わせておおむね同一チームの少ないエンジニアが一貫して該当コードを担当した方がバグは少ないといった感じでしょうか。

所感

管理職をやりたくない技術者ほど、技術とマネジメントは違うと言いがちですが、チームでのソフトウェア開発において技術とマネジメントはそれほど独立に分離できるものではありません。逆に1チームの初期スタートアップだと組織構造のウェイトは低くてもいい気はします。

別の視点で、エンジニアの中には常に新しいものを触っている方が飽きなくていいという人もいるので、そこら辺のストレッチとオーナーシップの安定の割合をうまく調整するのが管理職の腕の見どころかもしれないです。

Discussion