参加していないソフトウェア開発プロジェクトの事後分析方法②
前回に引き続き、参加していないプロジェクトの事後分析を行ったときの経験を書きたいと思います。
今日は、「構成のおかしなシステム」を受け取ったときの話です。
《成果物の構成から分かること》
成果物の品質評価には、仕様書などの資料にも目を通す必要があり、時間がかかります。
しかし、「成果物の構成」を観察するだけでも、分かることがあります。
私が受取ったそのシステムには、不可解な点がいくつかありました。
いくつかの潜在的な問題が、システム構成に現れていたのです。
◎コンウェイの法則の影響
そのシステムは、不自然に 2 つのブロックに分かれていました。
もちろん、綺麗にカテゴライズされているのなら問題ありません。
しかし、そうではありませんでした。それぞれのブロックの中身に統一感がありません。
実は、このシステムは、もともと一つの部署で開発を進めていたのですが、途中から 2 部署の合同体制に変わったらしいのです。
その影響で、組織構造に引っ張られて成果物が分かれてしまったわけです。
これは、コンウェイの法則 と言われるもので、設計に合わせた開発体制を整えていないために起きる現象です。
【コンウェイの法則】
システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう。
私の経験上、組織構造が強固な製造業でソフトウェアを開発したときに起きやすいと感じています。
◎要求の経路が不明確
そして、このシステムにはもうひとつ不可解な点がありました。
それぞれの成果物に、機能のダブり があったのです。
部署同士のエンジニアたちは、ちゃんとコミュニケーションを取りながら開発を進めていたようです。
しかし、要求を統一的に管理する担当者がいませんでした。
エンジニアたちは、「要求に素早く応える」ことを心がけているため、現場に要求が下りてきた時点で実装に取り掛かってしまいます。
要求管理が杜撰だと、特に規模の大きな開発では、作業のダブり・手戻り が頻発してしまい、成果物の品質に大きな影響を与えます。
《まとめ》
成果物の構成に違和感を感じたら、開発体制の問題を疑ってみましょう。
開発体制に不備があると、現場のエンジニアたちに落ち度が無くても、おかしな成果物が出来上がってしまうことがあります。
◇ 成果物の構成に統一感がない
⇒ 設計に合わせた開発体制は作られていたのか？
◇ 無駄と思われる機能がある
⇒ 要求は管理されていたのか？
実は、このときは、これらの問題がシステムの品質には大きな影響を与えているわけではありませんでした。
（不具合が多いわけでも、パフォーマンスが悪いわけでもなかった。）
なので、この会社内で行われた事後分析では、これらの問題は指摘をされていませんでした。
しかし、管理コストが高くなり、無駄な作業も発生しています。大きな問題として顕在化する前に対応をすべきリスクです。
(2024-12-26 追記)
続編を公開しました。