PR

アーキテクチャー検討にも積極的に関与

 3つめのアーキテクチャーの整理では、構成管理をしやすいアーキテクチャーを採用するよう、構成管理担当者がアーキテクチャー検討チームに関与する。例えば、アーキテクチャーによってリリースの手順が変わる。これがプロジェクトの開発手法や開発体制と合っていないと、リリースに時間がかかったり、必要以上の手間がかかったりする。

 昨今は大規模システムでのOSS(オープンソースソフトウエア)の採用が増えており、アーキテクチャーの整理の重要性が高まっている。OSSはシステム開発の低コスト化、プロジェクトの短期化に役立つが、OSSの内部構造を詳しく理解できている開発者は少ない。そのため、アーキテクチャー検討チームがOSSを隠ぺいする独自フレームワークを開発する場合が多い。

 こうした独自フレームワークの開発時、構成管理の面の考慮が漏れがちだ。アーキテクチャー検討チームは技術の専門家だが、大規模システム開発の構成管理の難しさを知っているとは限らない。そのため、構成管理担当者がアーキテクチャーの検討に参加するようにしたほうがいい。

 例えば、共有ライブラリを利用するアーキテクチャーを採用したとする。こうしたアーキテクチャーでは、共有ライブラリの開発者への配布が課題となる。「Maven」などのライブラリ自動インストールツールの使用が有効な手段だが、実施には共有リポジトリーを立てて開発初期から自動ビルドの仕組みを構築しておく必要がある。構成管理チームとアーキテクチャーチームが協力しないと、このような仕組みを開発初期に構築するのは難しい。

 OSSの組み込みに便利という理由で、IDE(統合開発環境)内のライブラリに依存したアーキテクチャーを採用するのも注意が必要だ。構成管理チームは大量のプログラムを一斉にビルドする必要があるため、IDEではなくMakefileやシェル、バッチコードなどを利用する場合が多い。開発者がIDEでビルドした結果と構成管理チームでビルドした結果が異なるという事態が生じたり、構成管理チームにIDEを利用したビルドを要求して1回のリリースに丸1日かかってしまったりする。

 重要なのは、構成管理担当者がアーキテクチャーを理解し、ビルド・リリースをするのに必要な情報を把握しておくことだ。場合によっては、構成管理を実施しやすいようにアーキテクチャーの変更を協議する。結合テストフェーズに入ってからだとアーキテクチャーの変更は実質不可能になる。検討段階から構成管理チームが加わっていく必要がある。


 今回解説したように、構成管理はソフトウエア開発プロジェクトの根幹を担う重要なプロセスだ。だが、ともすると準備不足のままプロジェクトに突入し、サブチームや開発者がバラバラに実施することになりがち。今回挙げた3つのポイントを参考に、円滑なプロジェクトの進行を支える構成管理を実践してもらえると幸いだ。

榎 亮(えのき りょう)
SHIFT
ビジネストランスフォーメーション事業本部 サービス事業部 エンタープライズビジネスユニット 技術支援グループ 構成管理Function ファンクションマネージャー
榎 亮(えのき りょう) ITコンサル企業にて、10年にわたりシステム開発やコンサルティングに従事。 2017年4月にSHIFTに入社。金融系部門のアカウントマネージャーを経て、技術支援のファンクションマネージャーを歴任。ソフトウェアアーキテクトの企画・構築や、業務・システム両面の視点からのコンサルティングを得意とし、数多くの品質改善プロジェクトを推進。