チーム総合力の強化～ Visual Studio ソリューションシナリオ

Article
06/27/2013

<< ”Visual Studio 2012 ソリューションシナリオ" では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>

開発プロジェクトが成功するか、不満足な結果に終わってしまうかは、開発メンバーが「チーム」として総合力を如何に発揮できるかにかかっています。開発メンバーに何人かの優れた開発者がいたとしてもチーム全体としての開発力にばらつきがあったり、チーム連携のための負荷が高く作業に集中できない環境であってはチームとしての総合力を十分に発揮することができません。

プロジェクトマネージャーやリーダーは、チームメンバー全員がそれれぞれのスキルや経験をベースに「個」として活躍する一方で、「チーム」全体としても優れた結果を出せるようチームのに総合力強化を進める必要があります。

チームでの開発においては以下のような課題が発生します。

会社や部門単位で設計ガイドや基本アーキテクチャーを定めてドキュメント化しているが、ほとんどのメンバーがドキュメントを参照せずにプロジェクト毎に独自アーキテクチャーを検証、構築してしまう。

開発時にサブシステムやコンポーネント単位で担当を割り振っているため、コードレビューのタイミングでしか他の開発者のコードを確認する機会がない。そのため、優秀な開発者からのスキル伝搬が十分でなく、また担当者が不在の際に他のメンバーで開発業務をカバーできない、といった問題が発生している。
プロジェクトのステークホルダーへの状況報告を行う際に、現状のプロジェクトステータスを把握するために多大な労力と時間がかかってしまう。

開発プロジェクトの成功を期待しないメンバーはいませんが、チームで必要となる作業を手間と感じて後回しにしたり、他のメンバーとのタイムリーなコミュニケーションができていない等のちょっとしたずれが、チームの成果物の品質に大きな影響を与えることがあります。

チームの総合力を高めるために以下のプラクティスを活用しましょう。

参照アーキテクチャーはコードで用意しよう

企業や部門において参照アーキテクチャーを定める場合、その目的は「参照アーキテクチャーを作ること」ではなく、参照アーキテクチャを活用することで「開発における品質のばらつきを押さえ、効率的なプロジェクト運営を支援する」ことではないでしょうか。ドキュメントとしてのみ用意された設計のガイドラインや参照アーキテクチャーは結局のところ実プロジェクトにおいて利用されないことがほとんどです。

開発の目的はソフトウェアの構築それ自体にあるのですから。参照アーキテクチャを用意するのであればこれから開発するソフトウェアの基盤として利用できるコードとして用意し、それをもとに開発を開始すべきです。

コードの共同所有を推進しよう

開発者それぞれに “こだわりのある” コーディングスタイルがあったり、開発スキルにばらつきがある場合、開発するコード領域を分割する（例えば、サブシステムとして分割する）ことで互いの開発者が他のコーディングに立ち入らないようにすることがあります。これは結局のところコーディングスタイルやスキルのばらつきをそのまま放置することと同じであり、チームの総合力の強化には役立たないアプローチになってしまいます。

チームとしての総合力を強化するのであれば、コードの所有者を分離せずに全ての開発メンバーがすべてのコードに対して責任を持ち、アクセスできるようにコードの共同所有を推進すべきです。

コードを共同所有にすることで、経験の少ない開発メンバーも経験豊富なメンバーのコードに触れることができ、またそのコードの改変等を通じてコーディングスタイルを学んでいくことが可能になります。またメンバーが急に休んだ場合などでも、他のメンバーによって作業をリカバリーできるようになりますので、開発プロジェクトのリスクを低減させることにも役立ちます。

使いやすいツールで情報にアクセスしよう

プロジェクトの状況把握にコストがかかる一つの原因は、状況把握の際に利用するツールを使用するために手間がかかったり、あるいはそのようなツールを利用していないために手動で状況把握を行う必要がある、といった点にあります。理想的な環境としては、プロジェクトマネージャーは Excel や MS Project といったツール、開発者であれば開発ツール、といった普段から使い慣れたツールで状況報告や状況の把握ができるように環境を設定すべきです。使い慣れた、普段から使用するツールにそれらの機能が統合されることで、開発メンバーはよりこまめに状況の報告、記録を行うことが可能になり、またプロジェクト状況を確認したい際には新しく情報を集める必要はなく、それら記録された情報をまとめることで状況把握が可能になります。

Visual Studio 2012 では開発チームがこれらのプラクティス実践をスムーズに行えるように、様々な支援機能を提供しています

プラクティス1 ：参照アーキテクチャーはコードで用意しよう

Visual Studio 2012 においては、開発プロジェクトのテンプレートを独自で作成するための機能があります。

Visual Studio 2012 で参照アーキテクチャに基づく階層分割、名前空間のルール付け、基本的なコードサンプル、などを含むプロジェクトを作成し、テンプレートとしてエクスポートを行い、企業や部門の参照アーキテクチャとして位置づけます。

開発チームは用意されたテンプレートを利用し、プロジェクトの作成時にそのテンプレートを指定してコーディングを開始するようにします。

このように、企業や部門によって基準とすべき参照アーキテクチャーが存在する場合、それらをドキュメントとしてまとめるだけでなく、実際のプロジェクトテンプレートとして用意し、プロジェクトの開始をそこから行うようにすることで開発プロジェクト毎の品質のばらつきを抑えることが可能になります。

プラクティス2：コードの共同所有を推進しよう

Visual Studio 2012 の Team Foundation Server を利用すると、チーム開発におけるコードのバージョン管理を行うことが可能になります。コードのバージョン管理機能は、サーバーにおいてコードのマスターデータを管理しつつ、メンバーはそれぞれのローカル PC においてコードの変更を行い、ある程度の作業が完了した際にサーバーへその変更を反映する、といった手順で行われます。

コードの変更を行う際には、他のメンバーが該当コードへの変更を行えないように排他的なロックをかけることもできますし、同時並行で変更の実施が可能になるようにしておき、サーバーへのコード変更の反映時に変更の競合解決を行う、といったことも可能です（ローカルPCでコードの変更を開始することを「チェックアウト」と呼び、サーバーにその変更を反映することを「チェックイン」と呼びます）。

Team Foundation Server ではローカル PC での変更をサーバーに反映する前に差分を確認する機能もあります（下記の画面ショットではサーバー（左）のコードとローカルPC（右）のコードを比較しています）

サーバーへの変更反映前にこのような確認を行うことで、誤った変更をチェックインしてしまう可能性を低減させることが可能です。また、コードに対して行った変更は「チェックイン」毎に「変更セット」という単位で記録されているため、変更によってコード全体に問題を発生させてしまった場合などは、変更前のコードに戻すといったことも容易に行うことが可能です。

このほか Team Foundation Server では、複数のファイルに行った変更を一つの「変更セット」として記録します。複数のファイルの変更を行った後にチェックインを行う際、万が一いずれかのファイルのチェックインに失敗したとしても、その時に実施しているすべてのファイルのチェックインが取り消されるため、変更の一部のみがサーバーに反映されてしまう、といったことを防ぐことが可能です。

このようなバージョン管理の機能を利用することで、チームメンバーはプロジェクトのコード全てに自由にアクセスできるようになり、また安心して変更を行うことができるようになります。スキルの浅い開発者であっても、同じチームの優れた技術リーダーが作成したコードに触れ、また変更を行う機会を持つことで、様々なプラクティス、テクニックを学ぶことが可能になします。

プラクティス3：使いやすいツールで情報にアクセスしよう

Visual Studio 2012 では、チームのコミュニケーション基盤となる機能を Team Foundation Server で提供しています。

Team Foundation Server を利用するとプロジェクトの成果物等の「ドキュメント管理」、コードの「バージョン管理」、コードのビルドを実施する「ビルドの自動化」、テスト環境を仮想化し管理する「ラボ管理」、チームの作業（タスク、要件等）を管理する「プロジェクト管理」、そしてプロジェクトの状況を素早く可視化する「プロジェクト状況の可視化」機能を活用することが可能です。

これらの機能は、開発者であれば Visual Studio から、プロジェクトマネージャーであれば Excel や MS Project あるいは Web から、テスト担当者であればテスト用のツールである Test Manager からアクセスすることが可能です。

例えば、開発者であれば Visual Studio を使ってコードを変更した後、その作業の終了をツールを切り替えることなく Visual Studio から報告することが可能です。下記の画面ショットでは、コードの行った変更（赤い枠囲みのうち、下のほうが変更されたファイル）のチェックイン時に、関連する作業項目（赤い枠囲みの上のほう）を関連付けている場面です。

このような機能があることで、開発者は別のツールを立ち上げる、といった煩わしい作業なしに作業の進捗を報告できます。また、Team Foundation Server ではこのような作業項目との関連付けをチェックイン時のルールとして設定することもできますので、関連付けを忘れてしまい情報が不正確になってしまう、といったことを防ぐことが可能です。

また、プロジェクトマネージャーはタスクの進捗状況を Excel や MS Project、あるいは Web から確認することが可能です。開発者が日々更新している作業項目の情報を、特別な手間をかけることなく気軽に使い慣れたツールから確認できるため、プロジェクト進捗に問題が起きそうな場合等でも早期に気づくことが可能になります。