新人技術者のためのロジカル・シンキング入門（4） ―― 直したバグがゾンビのごとく復活する

【3】大規模な開発は階層化・分業化で対応

　以上で述べてきたようなソース管理の運営は，比較的小規模な開発の場合なら，そのまま適用することが可能です．しかし，世の中で行われている商用の組み込みシステム開発の中には非常に規模の大きいものもあります．最後に，そのような開発の場合について，少しだけ考えてみることにしましょう．

　図8を見てください．ここでは30のチームからなる開発を考えました．管理ツールは導入済みであったとしても，これだけ規模が大きくなると，ソース・コード全体が巨大になります．ですから，すべてまとめて更新するとなると，扱いに困ることがあります．

図 8　30のチームからなる非常に大規模な開発の例
「ソース・コード全体が巨大で扱いづらい」，「どれが最新版かわかりにくい」という問題点が生じる．小規模の開発と同じようにソースを管理していたのでは，追いつかない

　管理ツールがあるので，ソースの最新版はサーバ上でつねに把握されている状態を保てるでしょう．しかし，巨大なソースをまるごとソース・コードのまま扱っていると，最新版の開発を各開発チームに強いるのはだんだん難しくなってくるはずです．なぜなら，多くのチームが頻繁に更新を繰り返すため，どのような組み合わせのソース・コードが最新版であるのか，だれにもわからなくなってしまうからです．最新版のソース・コードを確定しつつ，安定して開発を進めるためにはさらにくふうが必要となってきます．

　このような場合には，図9のような解決策があるでしょう．ポイントは階層化です．開発チームが開発するソース・コードの全体をビルドアップする別のチームを用意して，定期的にビルドを行うようにするのです．各開発チームはビルドのアナウンスを受けて最新のバイナリを入手し，必要なプロジェクトのみソース・コードで入手することになります．

図 9　大規模開発は階層化で対応
規模が大きすぎて，全体像が見えない場合，階層化してしまうのが一つの解決策．ソース・コードをビルドしてできるバイナリ・コードとソース・コードの管理を分ける．定期的にバイナリをビルドし直す体制を整え，必要なソース・コードのみを入手して開発できるようにする

　さらに開発が大規模化した場合も，階層化・分業化で乗り切ることができるでしょう．バイナリ・コードが巨大化し，一つでは管理しきれなくなったら，機能ごとに分化して別管理とし，最後にパッケージ化する方法が考えられます（図10）．各開発チームはパッケージ・バイナリ・ソースの必要なものを入手して開発することになります．まとめとして，図11に大規模開発向けのソース管理方針について示します．

図 10　さらなる大規模開発は階層化・分業化で対応
バイナリも多様に存在して管理が容易でなくなった場合には，全体をパッケージ化してしまい，必要なバイナリとソースだけ入手すれば開発できる体制を作る．もちろん，各階層には専用の管理者が必要となる

図 11　大規模開発向けのソース管理方針の全体像
管理対象が巨大化したら，必要な範囲で階層化し，各階層に管理者を設けて対応する，というのが解決策のポイント．実際の開発でどの階層まで必要かは，個別の事情による

● ソース管理はソフトウェア品質管理の根幹

　ソース管理のミスは，一見くだらないミスであるかのような印象を与えます．にもかかわらず，ソース管理はソフトウェアの品質の根幹にかかわる重要なものです．ですから，ソースを管理するということは，検討するとたいへんに奥の深いものなのです．

　ソース管理の巧みなリーダは，恐らくほかの事象の管理も巧みにこなせるのではないかと，筆者は個人的に考えています．

さえき・はじめ
＜筆者プロフィール＞
冴木 元．システム・エンジニア．最近，ブログがはやりだが，いまだにやろうとしたことがない．知り合いにも少なからずブログをつけている者がいるのだが，なぜかつける気にならない．小学生のときにつけさせられた絵日記がよほどこたえたのか？