Visual Studioの開発現場から（第1回）

　Windows用アプリケーションを開発している皆さんの中には，多くの方に弊社のVisual Studioを利用していただいていると思います。そのVisual Studioが，どのようにして開発されているのか興味はありませんか？一般向けのソフトウエア製品とは違って，開発ツールの場合は，作る側も使う側も同じ開発者で，非常に親近感のある存在です。そして開発手法や品質管理，チーム作りなど，共通の問題を抱えています。

イラスト：岡本 敏

　ただ会社が違うと開発手法が異なりますし，ほかの会社の開発手法を参考にしたくても，それを見る機会はあまりないことでしょう。そこで，私たちがVisual Studioを開発しているときに実際に遭遇した問題についてどのように解決したのかを，マイクロソフトでVisual Studioを実際に開発している各担当者が10回の連載で紹介します。

　第1回の今回は，私たちの組織の紹介も兼ねて組織作りを取り上げます。第2～4回では品質管理について，後で詳しく述べるQAチームが担当します。第5～7回では出荷に向けた開発手法についてPMチームが担当し，第8～10回は複数言語対応などに触れる予定です。

　連載途中には，現在まさに開発に取り掛かっているVisual Studio 2005（開発コード名「Whidbey」）のベータ版の出荷という，私たちにとって大きなイベントがあります。それらの開発の裏話にも，折を見て触れようと思っています。

健全な組織作りの第1歩は柔軟な人事体制
　皆さんの周りには，課長に昇進した途端に会社を辞めてしまった技術者はいませんか？これは会社にとって非常に大きな損失です。こんなことが発生しないような組織作りをするために，まず大事なことは「優秀な技術者が必ずしもみな管理職に向いているわけではない」という前提で組織作りをすることです。管理能力と技術力は全くの別物です。それらの能力に応じて適材適所に人員を配置すればよいのですが，言葉で言うほど簡単なことではありません。

　なぜなら人事的な給与体系と大きな矛盾が発生するからです。最近は能力給という形で給与体系も少し柔軟になってきましたが，技術者にとっては完璧とは言えません。ここで言う「能力」には，一般に管理能力も要求されているからです。「課長に昇進するよりもプログラムを書いていたい」もしくは「アーキテクトになりたい」という技術者にも，選択肢を与えられる柔軟な人事体制があれば，理想的な組織を作れるようになります。

図1●一般的な開発組織 上下関係の中で業務が割り振られている。

対等に意見を出し合えるフラットな組織作り
　柔軟な人事体制があれば，昇給のために役職を就けたりする必要がなく，理想的な人員配置ができます。例えば，課長，主任，中堅，新人の4人で構成された部署で開発するとします。課長は管理，主任はスペック作業，中堅がプログラミング，新人がテストという役割分担で作業を始めた場合（図1），果たしてうまくいくのでしょうか？きっとうまくいかないでしょう。

　一番大きな理由は，スペック作業やプログラミングといった各職種が人事的に独立していないため，対立できないからです。別に抗争する必要はないのですが，例えばテストを担当する新人が，中堅の書いたプログラムに対して注文を出すことはなかなか難しいことでしょう。各職種がそれぞれの立場から対等に意見を出し合える環境がないといけません。例えばテストだけに大きな負担がかかると，開発作業のバランスが崩れ，結局開発コストが上がってしまいます。

図2●フラットな開発組織 各業務の担当者同士は対等な関係にある。

　理想的な開発組織に近づけるには，この場合1人の課長の下に3人の部下を同列に置いたフラットな組織にすべきです（図2）。仕事の分担も経験年数だけを基準にするのではなく，個人の得意分野や資質などを考慮して決めるべきです。

　ただ，フラット化に伴う弊害もあります。それは管理です。組織をフラットにすると，1人の上司当たりの評価や管理の対象となる部下の数が，ねずみ算的に増えていきます。そこで必要になってくるのが自己管理と評価手段の確立です。これは何も難しいことではありません。本来普通にしなければいけないことをきちんとやるだけです。

　自己管理に関しては，今まで上司に与えられていた仕事の内容やスケジュールを自分で決めて実行，管理，報告すればよいだけです。評価に関しては，部下が多いと通常の業務を通してだけではすべての部下の成果を把握しきれません。対話が必要です。少なくとも1カ月に1回，できれば2週間に1回は，1対1で話し合う機会を持つべきです。それでもやはり部下10人ぐらいが限界でしょうか。

　マイクロソフトの開発部門の組織は，同じマイクロソフトの他部署と比べてもフラットになっていて，週1回もしくは2週に1回の割合で，上司と1対1の話し合いが行われています。ただし，1対1の話し合いは開発部署に限らず，すべての部署で実践されています。

職種ごとに部署を作ってもう1段大きい組織にする
　先ほどの部署（課長1人部下3人）で対応しきれないような大きな開発案件が入ってきたときはどうでしょうか？まずはシステム全体を構成する各機能に分割して，それぞれを各部署に割り当てる方法が考えられます（図3）。開発案件のシステムの各機能がきれいに分かれていれば，これでも対処できるかもしれません。しかし，各機能が複雑に絡み合っている場合は，各機能を分割して開発すると，その後の統合に大変な労力が必要になってしまいます。各機能は単体なら完璧に動作するのに，それらを統合すると動かなくなるというのはよくある話です。

△　図をクリックすると拡大されます 図3●大規模な開発案件を機能ごとに各部署へ割り当てた場合 機能A，機能B，機能Cを3つの部署に割り当てた。 △　図をクリックすると拡大されます 図4●大規模な開発案件を職種ごとに部署を作って割り当てた場合 スペック作業部署，テスト部署，プログラミング部署というように職種によって専門部署を作る。

　そこで部署を職種ごとに再編成してみるのはどうでしょうか？スペック作りやプログラミング，テストなどの職種ごとに部署を作るのです（図4）。マイクロソフトでもVisual BasicやVisual C++がそれぞれ別々に出荷され，お互いに依存関係が無かったときは製品ごとに部署を作っていました。その後，各製品がVisual Studio .NETとして同じ開発環境を使用するようになってからは，職種ごとに部署を再編成しました。

　それぞれの機能ごとに部署がある場合，横とのつながりが薄くなってしまいがちです。その点，部署を職種ごとに作ると，同一部署の人間が違う機能の作業をしていることになるため，開発対象システムの全体像が見えやすくなります。また，各個人は自分の作業のために，同じ機能を担当している他部署（つまりほかの職種）の担当者と密なコミュニケーションをとることになります。結果として全員から全体像が見えやすく，コミュニケーションも密な組織になります。
（次のページへ続く）