個人からチームへ

23 12月

今日のテーマは共同開発です。

 

非常に大事というか、会社に入ると当たり前な話なわけですが。あんまり学校の授業では出てこないみたいで、学生さんには欠けがちな視点みたいですねぇ。

視野の広がり

Visual Studioというのはソフトウェア開発の生産性を上げるためのツールです。ソフトウェア開発と言っても、いろんな視点があって、いろんな機能提供があります。以下の絵は、Visual Studioの新機能追加の歴史のようなものです。

この視点の変化(というか、視野の広がり)は、Visual Studioに限らず、ソフトウェア開発の現場一般に言えることでしょう。視野は、個人からチームへ、開発チームからビジネス全体へと広がっています。

.NET以外の世界でいうと、

  • エディター(Eclipseなど)
  • ソースコード管理(SubversionやGit)
  • 進行管理(TracやRedmine)
  • 継続的インテグレーション(Jenkinsなど)

など、多くのツールを組み合わせて実現します。

Express版

昨日のテストの話でもしましたね、初心者だと無償のExpress版で十分だと。それは、初心者だとだいたい、個人視点に収まるからです。前節の図で言うと、「開発者」に位置する機能は、Express版でもかなり網羅しています(単体テスト機能はないですが)。

一方、図中の右に行くほど、Visual Studioの上位エディションにしかない機能が増えます。

アプリのライフサイクル管理

開発チームという視点から、ビジネス全体へと視野が広がっているのには、時代の変化という背景もあります。

  • パッケージ売りから継続運用への変化
    • 昔は、一度リリースしてしまったらもうおしまい(あるいは、バージョン アップまで結構間が空く)でしたが、今は、ウェブなどで、継続的に要望が入り、継続的に開発を行う必要があります
  • アジャイル開発
    • 最初に要望を聞いて終わりではなく、細かい単位で要望や優先度の見直しが行われるようになっています
    • そもそも、世情の変化も早く、要望自体が短期間で変化します

開発チームだけで閉じていては、世情の変化に迅速に対応することができず、ビジネスの機会を失います。

アプリは、開発だけがすべてではありません。開発の前段階の要求の洗い出し、リリース後の運用、さらに、フィードバックを受けての次段階の検討まで含めたライフサイクルの管理が必要です。この考え方に対して、ここ数年で、ALM(Application Lifecycle Management)という呼び名も生まれました。

ビジネスにかかわる関係各者

開発チームからビジネス全体へという話をもう少し掘り下げてみましょう。

プロジェクトが大きくなればなるほど分業化が進むわけですが、以下のようなポジションに分かれることになります。

  • 統制
    • 意思決定者です
    • 何を作る、何を優先する、何にどれだけのお金を投資するなどの最終判断を下します
    • 受託開発の場合だと、顧客との折衝なども含まれます
  • 開発
    • アプリ開発も、いろいろな人員の協業で成り立っています
    • (狭義に)開発
    • 実際にアプリを設計し、コーディングします
    • 進行管理
      • チーム内の開発状況に遅れがないか、あるなら解決方法は何かなど、チームの進行状況の管理や他チーム/統制との折衝を行います
    • テスト
      • 開発者本人のテスト記述では漏れるような第3者視点でのテスト、結合テスト、手動テストなどを行います
    • UX(ユーザー体験)デザイン
      • 人文科学的視点や、美術的な視点からアプリの操作性や外観を設計します
  • 運用
    • アプリ公開後、継続的にサーバーの管理や不具合報告、エンド ユーザーからのフィードバック受け付けなどを行います

 

個別の視点、個々人の戦術的な視点だけではプロジェクトは成功しません。全体を戦略的に眺める視点が必要です。

広い範囲全体を眺めるというのは、言うほどたやすいことではありません。ソフトウェア開発に対する要求が高度化するにつれ、この全体の把握を補助するツールの存在が重要になっています。

TFS

チーム全体の共同作業を支援するため、(クライアント アプリである)Visual Studioの他に、サーバー製品も提供されています。それが、TFS(Team Foundation Server)です。

Visual Studioとの連携(Visual Studio上からのソースコードや作業項目管理)に加えて、SharePointベースの管理ポータル ウェブ サイトを持っています。

今後は、Azure上に構築され、オン デマンドに使えるクラウド版TFS、Team Foundation Serviceも提供される予定です(現在、招待性のベータ版)。

Visual Studio 2010/TFSの機能

現状のVisual Studioが持っている機能を簡単に紹介しておきましょう。「ビジネス全体」の視点の機能は現在も拡充途中で、次期バージョンでもいろいろと新機能が入る予定です。

コーディング

  • コードの補完
  • リアルタイムなビルド/エラー検知
  • コードの構文ハイライト
  • 検索
  • リファクタリング
    • メソッド化、フィールドからプロパティの生成、変数/メンバー名変更
  • メンバー生成
    • 先にメソッドなどを使う側のコードを書いて、そこから未実装のメンバーを作る

デバッグ

  • ステップ実行
    • 1行ずつ実行しながら、変数の状態などの変化を見る
  • ブレイク ポイント
    • 特定の行を通った時に1度実行を止める
  • デバッグ情報の履歴保持(IntelliTrace)
    • デバッグ実行時の状態変化の履歴を、チーム内の別の誰かにそのまま渡して再現する機能

コード分析

  • メトリック(metric: 測定基準、数値化した指標)計算
    • バグを起こしがちなソースコードを判定するための指標を出す
  • プロファイリング
    • 性能分析

テスト

  • 単体テストの生成
  • テストの選択的実行
    • 現在カーソルのあるメソッドに関連する部分だけとか、修正した部分だけとか
  • テストの自動実行
    • TFS上で、ソースコードのコミット直後や、所定の時間にテストを実行
    • テストに通っていないコードをソースコード管理サーバーに反映させないということも可能
  • 多環境テスト
    • 仮想マシン上にいろいろな環境を構築して、その上でのテスト実行
  • 手動テストの作業項目管理/バグ レポート
  • UIの自動テスト
  • 負荷テスト

進捗管理

  • 作業項目管理
  • 状況の可視化
    • 作業項目の消化度合い
    • 残りのバグ数
    • 各種メトリック

補足

 

失敗の教科書

教科書的なプロジェクト管理/評価指標や、ツールによるその補助を軽視していませんか?

「これをやれば成功する」なんてものがないのは明白です。そんなのがあればみんなやります。しかし、「ここを外したら失敗する」みたいなものは、結構あります。教科書は、「成功するためのもの」ではなくても、「失敗しないためのもの」ではありえます。それをおろそかにして、失敗していませんか?

Visual Studioは、Premium版以上を買うと、様々なメトリックを計算して出してくれます。これもその「失敗しないためのもの」の一種です。数字を良くすればプロジェクトが成功するというものではないですが、数字が悪いほどプロジェクト失敗の確率が上がります。

統計的な研究あり

各種メトリックと、プロジェクトの欠陥に関する統計的な研究も、Microsoft Researchから出ていたりします。

ここでは、プロジェクトの欠陥の指標として、「リリース後に発見されたバグの数」と各種メトリックの適合率を求めているようです。Visual Studioが計算してくれるようなコードがらみのメトリックとは、大まかに、70~80%くらいの適合率が出ているようです。

そして、実は、組織的なメトリック(何社かかわっているかとか、チーム内のエンジニアの人数とか、ちょっとだけかかわって辞めていったエンジニアの人数とか)の方が重要で、コードがらみのメトリックよりもプロジェクト欠陥との適合率が高い(85%程度)という報告もあります。

また、地理的な距離よりも、組織的な距離の方が如実に欠陥に現れるそうです。何kmも離れた場所にいる同社同僚の方が、すぐ隣の他社出向社員よりも、心理的には「近い」とか。

マイクロソフト内の開発プロセス

マイクロソフトは、社内の開発プロセスがどういう風になっているかもオープンにしていたりします。

 

マイクロソフトでは、例えばVisual Studioという製品だけを取ってみても3500人以上の人間が開発にかかわっています。これだけの人数を一括して管理できるわけはなくて、以下のような分散管理になっています。

  • 10人程度のチームに分かれています
    • 進行管理1名、開発5名以下、テスト5名以下
  • 開発手法はそれぞれのチームが自由にやっていい。ただし、
    • 報告を義務付け
    • コミット前にクオリティ チェックがある

そして、分散した開発状況全体を把握するために、TFSの可視化機能が使われています。また、開発とテストの比率がほぼ1対1なことも注目に値するでしょう。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。