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

マイクロソフト開発部門の職種
　ここでマイクロソフトの開発部門にある職種を紹介しましょう。以下のような5種類の職種を置いています。

PM：Program Managerの略で「ピーエム」と呼びます（マーケティング部門にはProduct Managerの略で，同じくPMと呼ばれる人がいて，少し紛らわしいです）。主にスペック作成や開発管理などを担当します。出荷するために開発部門内の各部署と折衝したり，マーケティング部門や他製品との窓口になったりなど何でもします。自分が担当している製品以外で何か困ったことがあったら，その製品のPMに相談するのが社内では一般的です。対外的な窓口でもあります。

イラスト：岡本 敏

・Dev：開発者のことです。Developerの頭の3文字だけを使って「デブ」と呼びます。文字通りプログラムを書いている人たちです。あまり社外には出ません。

・QA：Quality Assuranceの略で「キューエー」と呼びます。マイクロソフトにはQA専門の部署があります。私が以前勤めていた会社では，プログラムを書いた本人や新人がテストしていました。今考えると恐ろしいことです。QAチームを持った部署で働くと，QAチームなしで開発する暴挙に出ることはできなくなります。皆さんの会社にはQAチームがありますか？

・UE：User Educationの略で「ユーイー」と呼びます。直訳するとユーザー教育係となるので違和感がありますが，実際はマニュアル作成部署のことです。日本語版の開発ではほとんどが翻訳になりますが，彼らが翻訳だけをやっているかというとそうではありません。翻訳のためのツールを開発したり，マクロを書いたりと，結構いろいろなことをしています。

・プランニング：私はここに属しています。開発ツール以外の製品にはあまり見られない例外的な部署です。主な仕事は製品の改善要求を出すことです。通常，開発作業は開発人数とスケジュールにきつく縛られています。限られた人数とスケジュールに縛られて開発を進めていくと，出荷スケジュールに間に合わないので，ある機能の実装をあきらめることもあります。あってはならないことですが，テストが不十分でバグが残ったままになると，場合によってはユーザーに到底受け入れられない製品になってしまうことも，ないとはいえません。このような製品品質の低下を開発内部で事前に防ぐため，開発工程の全体を開発の当事者から一歩引いたところで監視するのが私の仕事です。まあ，外部コンサルティングみたいな役割です。当然，人数やスケジュールに縛られないので，他部署には任せにくいその他もろもろの仕事も，私の役目です。

・その他：開発部門以外ではサポート，マーケティング，営業などがあります。また，製品を使った開発を支援するSEやコンサルティングの部署もあります。

「3人寄れば文殊の知恵」方式で職種を配置
　職種の設定と配置は，プロジェクトの大きさや種類によって様々なやり方があるでしょう。ただ，1つだけいつも頭の隅に置いてほしい考え方があります。それは「3人寄れば文殊の知恵」方式です。弊社の本社がある米国にこのことわざがあるのかどうか知りません。意図的にそうしたのか，結果的にこうなったのかは定かではありませんが，マイクロソフトではそのような構成になっています。

　例えば，ある作業に関係する部署が2つの場合は，うまく行っている時はいいのですが，互いに意見が合わなくなった時に仲たがいしてしまい，作業が進まなくなってしまう危険性があります。逆に4つや5つなど多くの部署が関係すると，意見がまとまらずに作業が進まなくなる危険性があります。作業を迅速に効率よく行うためには，その作業に関係する部署を3つにすることが望ましいのです。

　マイクロソフトでは次のようにしています。
・開発作業…Dev，PM，QAの3つ。
・マニュアル作成作業…UE，PM，QAの3つ。
・出荷作業…PM，マーケティング，サポートの3つ。

△　図をクリックすると拡大されます 図5●マイクロソフトの組織はこのような三角形の複合体を成している

　各作業について各職種の関係を，こういった3角形の複合体で配置することにより，円滑なコミュニケーションを生かして迅速に開発を進められます（図5）。もちろん，このときも組織をフラットにすべきです。各職種間に人事上の上下関係があると柔軟性が損なわれる危険性があります。

社内技術説明会で専門家を育成する
　昔から技術者の教育といえば，丁稚奉公と相場は決まっていますが，わざわざフラットな組織を作ったのに丁稚制度ではうまく対応できません。基礎的な技術教育などは，人事部が中心となって会社単位で行う教育で十分ですし，最新情報であれば外部セミナーや雑誌などがあります。でも，これらの教育を受けさせるだけで，本当に十分でしょうか？

　せっかくですから，技術力の底上げだけではなく，専門家を育てましょう。実際の業務が目の前にぶら下がっている状態で，各自がすべての最新技術情報を勉強するのは無理でしょう。できたとしても効率的とはいえません。そこで個人ごとにテーマを決めて，社内のメンバーにプレゼンテーション形式で，技術説明会をさせましょう。例えば，新しいツールの採用が決まったら，その使い方を1人が勉強して全員にプレゼンすればよいのです。最新技術に関しても細分化して同じように教育できます。例えば，社内で初めてXMLを開発に取り入れた部署があったら，XMLの概要，採用理由，実際にどのように採用したか，評価などをプレゼンすれば非常に実践的な教育ができます。

　プレゼンする側の利点もたくさんあります。相当真剣に勉強するでしょうし，プレゼン後もそのテーマについて相談され，どんどんその分野の専門家になって行きます。人前でプレゼンテーションを行う機会そのものが少ない技術者にとっては，よい経験にもなります。すべてのプレゼンテーションが一巡するころには，普段は違う仕事をしているためによく知らなかった人が何を担当していて，何の専門家なのかが分かり，ますますコミュニケーションが活性化するでしょう。

健全な組織の運用を阻害するドンブリ制度
　最後に，ソフトウエア技術者に対する評価について触れておきます。

　パッケージ・ソフトの場合は，売れたかどうかによってその製品が市場から評価されます。それによって開発した技術者も自分のプログラムの評価を知ることができます。これは技術者のやる気を持続させるという意味で非常に大切なものです。

　では受注ソフトの場合はどうでしょうか？例えば，すべての技術者に均一にSE（システム・エンジニア）という肩書きを付け，実際の開発にかかる人月計算から受注価格が決められている場合を想定してみます。現在のソフトウエア業界では一般的な方法です。

　受注ソフトの場合，開発が終了して運用期間に入ってしまうと，大きな問題が起きたとき以外，なかなか技術者までその評価は入ってきません。客観的な評価となるのは，会社の売り上げぐらいしかありません。

　人月計算方式は，かかった人件費に応じて販売価格が決まるので，経営者から考えると一番リスクの少ない考え方です。しかし，技術者にとって仕事の評価の物差しとしてみた場合はどうでしょうか？優秀な技術者が1カ月で開発した（私はこれをいろいろな意味を込めて「1ドンブリ」と呼んでいます）プログラムと，別の技術者が2カ月で開発した（2ドンブリ）同じ機能を持つプログラムの価値はどちらが上でしょうか？同じ機能のプログラムであれば，その価値は同じはずです。そして，短時間で開発した1ドンブリの開発者の方が，生産性が高いことになり，優秀なはずです。

　ところが，会社への貢献度としてはどちらの方が高いのでしょうか？通常，1ドンブリのものより，2ドンブリの方がコスト高のため，販売価格は高くなるでしょう。つまり，技術者が優秀であればあるほど，会社の売り上げが下がることになります。このようなドンブリ制度がある限り，優秀な技術者は自分を正しく評価できなくなります。

　人月計算以外にもソース・コードの行数で価値を判断する方法があります。しかし，これも正しくありません。例えば，C++で書かれたプログラムと，Visual Basicで書かれたプログラムの行数は大幅に違いますが，書かれたプログラム自身の機能が同じならば，価値は同一のはずです。

　プログラムの本当の価値そのものに対して，対価を払うという制度改革なくして，長期にわたる健全な組織の運用はできません。一番変わらなければいけないのは，発注側の意識かもしれませんが，それを支えるために開発者側の改革を進めなければいけません。

最後に
　今回は組織紹介も兼ねたため，少し漠然とした組織作りの話になってしまいましたが，ほんの少しでも参考になることがあれば幸いです。

　次回はQAの担当者が，どういう仕事の仕方をしているのかをより具体的に説明する予定です。実際，私がマイクロソフトに入社して，一番カルチャー・ショックを受けたのは，やはりQAの存在でした。入社するまでは，QAという職種があることや，QAの専門家がいるなんて考えたこともありませんでした。ではこの辺で，次回の担当者にバトンタッチします。