情報経済論期末レポート
E07-0808A宮澤 淳
序章 ････････････････････････････････････････････････････････････P.2
第一章 Microsoftの誕生、そして ･････････････････････････････････P.3
第一節 Microsoftの誕生、そして
第二章 最高経営責任者の在り方 ･･････････････････････････････････P.4
第一節 最高経営責任者の在り方
第二節 製品市場と職能を軸とした柔軟な組織の育成
第三節 管理者たる人材の重要性
第四節 優秀な管理者に仕える人材
第三章 構成者たちの在り方 ･･････････････････････････････････････P.12
第一節 一員としての新入社員
第二節 チーム編成の小数化と責任共有
第三節 職能別の採用基準
第四章 未来に向かって ･･････････････････････････････････････････P.16
第一節 Microsoftからみる未来型企業像
終章 ････････････････････････････････････････････････････････････P.18
参考資料
Michael A.Cusumano & Richard W.Selby 日本経済新聞社
Michael A.Cusumano & Richard W.Selby 日本経済新聞社
序章―――――――――――――――――――――――
情報経済論の講義内容は、情報端末をようやく道具として使いこなせるようになってきた私にとって、非常に興味深いものであった。実在の企業名を用いた実例の数々を一年間聴講するうちに、私は期末レポートで、かつて感じていた思いを採り上げてみようと思うようになった。それは「世界に名を馳せる『Microsoft』の経営はどういう理念の基に動いているのか」という思いである。
Personal Computer（以下PC）に関する知識もほとんどない私が、初めてPCを購入したときに単に「有名」というだけでDOS/V互換機を購入し、現在までApple社やNEC社製品に興味を持てなかったのも、Microsoftの強大な経営戦略の産物である「世界標準の知名度」に自分が圧倒されていたためと今になって思う。「世界標準：Global Standard」はどのように築かれたのか知りたい、そして現在も維持発展するその経営体制・手法の理念はぜひとも学んでおきたいという思いから、ここにレポートを記す。
しかし、現実問題として私がアポイントを持てるMicrosoft社関係者の方はいない為、真の内部事情を知り得ることは不可能である。そこで既に発行されている様々な文献を使用して学ぶこととする。さまざま「 Microsoft本」が出版されているのは皆様ご存知とおもうが、単にそれらを引用するだけでなく、新聞や雑誌等も活用する。
第一章ではMicrosoft社の誕生期の経営組織とその管理体制を調べ、創業期のメンバーがなにを考えて動いていたのか考える。
第二章では最高経営責任者（chief executive officer：以下CEO）ゲイツとその周辺をとりまく管理する側のMicrosoftに対する理念を述べる。
第三章では雇用される側に求められる性質を挙げ、実際に社員として機能している人はなにを求めているのかを述べる。
第四章では今後ソフトウェア産業が伸び続けていくとして、将来なにを視野にいれるべきか、Microsoftの経営から判断できることをまとめる。
第一章 Microsoftの誕生、そして―――――――――
1960年代当時、タイムシェアリングコンピューターの利用がようやく活発化してきたときである。いまでこそ当然だが、それぞれの利用者が送ってくる異なる命令を一定時間（数百万分の一秒）ごとに次々と処理し、それぞれの利用者に結果を送り返すシステムである。大企業や大学の研究室にしかなかった高額なコンピューターを、テレタイプとモデムを使って電話料金と使用料金を支払って学生が自由に使えるようになったのである。
13歳のゲイツは15歳のアレンとともにレイクサイドスクールのコンピュータールームでBASIC言語を学んだ。タイムシェアリング方式でコンピュータを時間貸しする会社シアトル･コンピューター･カンパニー（CCC）で、PDP−10という対話型コンピューターを土日曜日に終日熱中し利用することから、プログラマーとして成長していった。二人はプログラムを書くという「労働」を売ることから、次第に、プログラムそのものを「作品」として販売するという方向に移行していくのである。
企業の成功の一角は、CEOの指導力、経営能力、技術とビジネスに対する洞察力から生まれる。1973年、ゲイツはポール･アレンとともにニューメキシコ州アルバカーキーに引っ越しす。世界で最初のPC「アルテア」を開発したエド･ロバーツに三つの異なるBASICのライセンス契約を結んだ後、三人の社員で世界で初めての本格的なソフトウェア会社を設立した。
設立したMicrosoftは、当初優秀な人材だけを採用し、小さなチームを組むことによって優れた開発者同士で仕事をしていた。
しかし、企業の成長は問題に直面するのが当然である。それは、「日々変化する会社や業界の動きを把握し、増加する自社製品ラインはもちろん、競合企業の製品にも精通しているため、絶えず研究をしていなければならない。」「毎日の製品管理と様々な要項の決定をする。」等である。
第二章 最高経営責任者の在り方 ―――――――――
第一に、経営者ゲイツはプロジェクト進歩状況報告書に目を通す。毎月プロジェクトチームは、ゲイツらの営業幹部と関連プロジェクトの責任者に報告書を送ることになっている。これは、経営陣が開発状況をプロジェクトチームから報告を受け、互いに意思疎通を図る為の主要な手段となっている。中間目標などのスケジュール、仕様の変更やコードの完成予定などを報告し、担当管理者や開発者に電子メールで返答して情報をプログラムレビュー会議資料とするわけだが、肝心な点は「報告書が相互に依存しあうすべてのグループのすべての管理者に読まれることを利用して、問題の提起を促すことができる。」ことと、「スケジュールの遅れ、製品機能の削りすぎ、仕様変更の必要性などに注意し検討を大勢とできること。」である。
ゲイツの目的は、進歩状況報告書で全体のコミュニケーションをとることによって、グループ内のコンセンサスにしてしまうことにある。
第二に、プロジェクト毎のプログラムレビュー会議で、混乱していないか助言をすることである。Microsoft社は約三ヶ月毎にゲイツら経営幹部同席のレビュー会議を行う。レビュー会議の焦点は進歩状況報告書と似ているが、内容はプログラム管理やソフト開発、テストや製品管理やユーザー教育など各職能分野の経営幹部の前で、徹底的にプロジェクトの関係による利害調整である。
製品スピードの遅れを10倍おそくならないことを証明しろと指摘し、追加機能が果たして本当に性能を向上させて汎用性を高められるのかどうか指摘したりと、各職能分野ごとの理解度・共有度を確かめるのである。
市場の環境変化で仕様変更を余儀なくされるとき等、会議に出る前は周到な準備をし、電子メールは駆け巡る。CEOであるゲイツは、開発者に、開発者同士の依存関係をすべて理解させ、それらを組み合わせることによってプロジェクトの困難な状況を打破するために助言しているのである。助言は社内でも14級か15級（同社の技術者で最高の職級）の開発者にたいして行うこととしている。
第三に、製品開発の管理である。特にプログラムレビューに関しては、各グループ同士の協力状態と連動する製品やコードを共有する製品の調整がうまくいっているか、又、スケジュール通りに開発が進んでいるかを確認する。はじめ全てのコードをひとりで書いていたゲイツも、「開発する製品の全体的な構想については他人にまかせないこと。」と「仕様設計を確認すること。」を現在管理してるだけである。しかし、その行動は、将来の方向性と予想される競合企業の動きを考え、その観点からMicrosoftの製品ライン全体を見据えるためなのである。そして、技術とビジネスから二者択一の決定を下すのであしている。
以上CEOの仕事を三つを挙げた。ただし、企業として面白いのは、社員とゲイツが議論したり、ゲイツの提案に異議を唱えるのは日常茶飯事であることだ。自分がなにをしようとしてるのか、また、なぜそうするのかを十分にゲイツに報告することで、ゲイツの提案にも即座に具体的な説明と技術的な根拠の山で否定することのできる社員を経営幹部は求めている。個人的、感情的な主張や駆け引きはMicrosoftには必要ないのである。
有能な者の中に、全てが自分の下で機能していないと気のすまない者がいる。そういった者がトップになった場合、ある意味企業にとってそれは正しいといえるであろうが、一方偏狭なものにもなりうる危険性も持ち合わせている。Microsoft社もその例外ではなかった。第一節で述べたように、優秀なものは優秀なもの同士で仕事のパートナーを組みたがるものである。多くの企業がそうであるように、Microsoftもその例外ではない。組織構造の変換は非常に興味深い。以下年毎に追っていく。
1980年代初め、アプリケーション･プログラムを開発するエンドユーザー部門を設立し、これによってシステム部門とアプリケーション部門が別々に発展するようになった。ただしこの時点では職能部門、とくにテスターの技術がまだまだ低く、品質管理やプロジェクト管理の仕組みの悪さから問題も発生していた。
1984年、開発部門からようやくテスト部門が独立し、第三者からの客観的な判断を取り入れることに成功する。それはIBMなどソフト開発で評されている企業に習って、独立したテスト部門を作る以外にないという結論に達した。当時Microsoftは、出荷したIBMのPC用BASICのバグに対し、同社から強くソフト開発と品質管理プロセス改善を要求されている。購入した個人ユーザーから苦情が出てきたためである。ただ、IBMのように、大規模な組織の中で仕様書からコード、テストの計画などソフトのすべての項目をレビューし、開発の様々な段階で幹部の「承認」をもとめるような官僚的な手法はとらずに、独立した部門の設立やテストの自動化など、Microsoftに効果的なものだけを取り入れるようにした。
そして、製品管理とソフト開発からプログラム管理という職能分野が確実に別れてきたが、皮肉な問題が起こる。開発分野とテストチームを明確に分化した結果、開発者の仕事に対する正確さが失われることになってしまったのである。つまり、今まで開発者はぺログラムのテストを自分で行っていたのだが、その役目がテスト部門に移行したため、コードのチェックが甘くなってしまったのだ。Mac Word3.0に約700のバグが見つかり、リリースから二ヶ月後に無料アップデート版を送付したのは有名な話である。Windows Word開発（当時のオーパスプロジェクト）では「終わりの無い欠陥」といわれるようになった。テスト部門のバグ発見スピードが、開発者のバグ処理スピードを上回って閉まったのである。混乱するプロジェクトを管理するしかゲイツは思い付かなかった。
1988年、マイク･メープルズがIBMから移籍し、システム部門、アプリケーション部門のなかに規模の小さな事業部門をつくる決定を下した。これは各事業ごとの焦点を一段と明確にするといった非常に重要な意識改変を起こした。毎週のプロジェクトに支障が生まれると人員の移動が起こるが、メープルズは「効率的でない」として事業部門制を決定した。ゲイツの人的資源を浮かしてはならないという考えに相反するものである。しかし、人的部門という資源プールに継続性をもたせることによる幅広い責任を持たせる計画の重要さ、多数の管理職が育つという成果を説いた。
「なにを優先し、なにを切り捨てるかを決定する。二者択一、取捨選択、これは組織づくりの全てである。組織改編によって、製品部門の求心力は最大限に高まった。この製品でなにをしようとしているのか。どの機能を盛り込み、どの機能をはずすべきか。製品を出荷したか、レビューをとったか。この組織再編で専門化の方向は消える。」とゲイツは語る。製品部門制より、事業部門制の重要性をとったのである。個々のグループは自主的に行動し、比較的小さな開発センターとして、目標の市場に製品を出荷することだけに専念が出来るようになっている。
その確固たる理念が述べられているのが1989年のクリスメイスンが「無欠点コード」である。以下に一部抜粋する。「当社の製品でバグが増え続けているようにみえる理由はたくさんある。当社の製品が複雑になっているのは事実だが、複雑化に対応して開発方法を変えていないことである。」「社員の側でなく開発方法の側に欠陥の原因があることをはっきりさせる。」「製品が複雑であるためにバグが生じるのは、個々の部分が全体としてどううごくのか理解していないからである。」「何十万という個人ユーザーと企業が当社の製品をたよっている。バグによって、莫大な時間と金が失われかねない。表計算ソフトなど各種アプリケーションソフトにバグが見つかれば、企業にとって致命的な打撃になり兼ねない。われわれは、この問題をもっと真剣に考える必要がある。」
管理者の“優秀さ”とはなにをもってはかるのであるか。構想力豊かであり、同時に帳簿係の視点もかねそなえていることは当然であろうが、その外には何があるだろう。思うに、時代を読むある種の鋭さ、新しい事実をを吸収する能力が必要である。しかし、ある状況におかれたときに、状態を咀嚼し、すぐさま質問が出来るくらいの理解力、記憶力を持ち合わせ、ある種の想像力によって効率的に動けるということも重要であろう。ゲイツの言葉にあるが、「一見関係なさそうにみえる領域を関連づけて考える」ことも力なのである。
Microsoftにはブレーン･トラストという集団がある。その中枢は十数人の幹部で構成されている。意思決定や、重要なプロジェクトや活動を監督するのを補佐する体制をしいていて、そのメンバーは経営幹部、トップランクの開発者とプログラム管理者などである。ただしどこにも名簿は存在せず、非凡な知識と経験がみとめられている人々の集まりである。ただ、その経験と知識のある社員は若い段階で経営幹部になることがおおく、企業の急速な成長に対して、技術とビジネス、そして人事管理能力もそなえた中間管理職が不足気味になっているのは皮肉なことである。
人事管理とその方法は企業の改善と成功に大きな影響を及ぼす。IBMやMicrosoftに共通するのは、社員の評価、監督、報酬に一貫性を持たせることである。査定や昇給の体系に組み入れられて「規格化」されるより、社員をグループ間で移動させ、昇給体系の指針や思想、職級を明確にする方が、賃金や期待度などに大きな格差を発生させにくいのではないだろうか。そのためには、当然のことながら、賢い管理職の育成も忘れてはいない。保養施設で管理者会議をひらくことにより、電子メールでは出来ない「全員が顔を突き合わせて話し合うことの出来る場で、共通の問題を議論する」ことを可能にしている。そして、職級を明確にすることによる部門間の対立やなわばり争いなど組織の弊害になるものを発生させないようにブレーントラストは苦心している。
第二節で職能ごとの理解度、共有度を確かめると述べたが、職能を軸に組織を作る限り、部門間の壁ができ敵対意識が強くなるのは確かであり、最後には壁を越えることが出来なくなり、社員構成が崩壊する危険性は確かにある。しかし、Microsoftはチームの結束力を売りにしているだけでなく、開発者の意識、つまり開発者あってのテスト担当者という意識は他の企業より薄いと言いきっている。それが当社の文化であるとメープルズは考えているのだ。そしてゲイツも自分のプロジェクトのためでも、自分のキャリアのためでもなく、Microsoftにとって何が利益になるかを考えるように社員にもとめている。
ここで、節のはじめに取り上げたIBMとMicrosoftの経営方法の根本的な違いをみる。IBMの経営方法は対立を意図的に作り出すことによって、狭い見地からの主張をするようになっている。自部門のことを他部門全部から事実を報告してもらうことによって正しい判断を求めるのである。しかし、ここには、IBM全体の利益を考えてはいない。悪く言えば他部門のあらを探すだけで、全体の向上には結びつかないのである。Microsoftはここが違う。順調にすすんでいたプロジェクトが部外に通達しなかったばかりに突然中止するようなこともなく、たがいに電子メールなどで意見を交換しあうことも裏切り行為の意味で捉えたりしないのである。
そして、プロセスのそれぞれのプロジェクトでの決定を認めている。製品開発においてプロセスは部門別に決めようという管理者の思考が重要なのである。メープルズは標準を各部門全体に押し付けようとはしていない。最終目標でなく、部門の中間目標に向かっていくことの重要さを説いているのである。どの職能分野でも、管理者は大抵経営幹部になったのちも各職能の仕事も続ける。プロセスの決定には、実際の仕事内容が理解でき、同時に参加でき、問題をすばやく察知して対応できる管理者が必要なのである。つまり、管理者が、管理が忙しくてプログラミングなどやっていられないという者では組織のトップに立てないということである。
「管理者＝指導者」である。こうした地位につくには、二つの必須条件のどちらかを満たしていなければならない。一つ目は、同僚や部下になる社員と同等の技術力を持たねばならないこと。二つ目は、魅力、つまりカリスマ性を身に纏わねばならぬことである。管理者にも階層があり、上に行くほど管理能力と技術力がたかくなっていく。知識の豊富な者を若いうちから経営幹部にしてきた急成長企業Microsoftは、この管理職の責任者を見つけることが現在の難関であるとしている。ただおおきな業績をあげたり、押しが強ければ管理者になれるという訳ではなくなっているのである。
多くの企業では、新入社員を雇用した後に大掛かりなを行い、しだいに組織人になるように仕向けることが多いだろう。企業の色や規則に適応させるにはそれしか方法がないためである。企業の中身をしらない人間を雇用し、実情を社内研修によって知らせるのである。新入社員はそこではじめて自分の会社に尽くせる能力や決意、判断を知る機会を得るのである。
どの企業も、東大や京大、MITやハーバードの中で技術力や判断力などをみがいたトップレベルの学生を採用できるわけではない。ほとんどの会社のシステムが、そのような学生を視野に入れて、低いレベルでの出発を前提としているのは決して責められることではない。では、本当に欲しい人材の採用基準はどういったものであろうか。もちろん、大掛かりな社内研修を行わずとも、文書になった規則や指針がほとんど無くとも、自分で行動を起こし、学び取る能力があり、適切な判断を即座にくだせる人材である。経験もなく訓練も積んでいない者に、社内研修だけで複雑な技術を理解する基礎を与え、なおかつすばらしい働きをする「優秀」な社員にしたてるにはかなりの労力と時間を要するだろう。
そこで、「優秀な」社員が多くなるとどのような利点が創出できるのかかんがえる。それは、管理者が利用できる「資源」の量が格段に増加することである。当然のことだが、重要な点である。たとえば、Ａプログラマーの一ヶ月当たり生産性が1.05、Ｂプログラマーの一ヶ月当たり生産性が1.1であるとしよう。二者同時に雇用し、それぞれが個人で現在１の仕事を半年したとして、どれだけ差が生まれるだろうか。計算すると、Ａは約1.477、Ｂは約2.143となる。わずか半年の単独作業でＡとＢは2:3になってしまうのである。これが個人でなく、グループでの作業だったとし、更に様々な要因を含めたとしても、差は決して縮まらないのである。
Microsoftで大事なのは、製品の出荷であり、いくつ製品を出荷してきたかである。肩書きだけでは、よりよい製品を出荷することはできない。個人と個人の能力によって力関係が成立していて、例えば責任者がずばぬけて優秀で、機能の開発方法や出荷に関することを熟知していれば、自然と権限と責任はそこに集まる。それは規則でもなんでもなく、部下の力量に合わせているだけなのである。
では、利点の創出に対する弊害も述べておこう。利点の逆をつかれる形となるのであるが、「規則」が無くても動けるがために、他人からの命令や助言に難色を示す点である。自分自身で解決方法を模索し、オリジナルつまり自分が生み出したことや学んだことを共用することを嫌う傾向があることだ。製品を出荷することつまり利益を出すことMicrosoftの理念なのだから、問題が発生したとき第一に考えることは個人レベルでなく会社全体の利益なのである。そのためには、苦労してプログラムした自分の担当ソフト機能が、別の開発ソフトに組み込まれる提案がたとえ突然にあったとしても、業界に最も貢献することのできる仕事をするためのひとつの方法であるという観点で考えねばならない。勿論、重要な結合には、開発者同士でなく、CEOも話し合いに加わることはいうまでもない。
第三章 構成員たちの在り方――――――――――――
第一章第五節で優秀な社員のスキルは資源である、と述べた。現実問題として、技術能力が高く、その能力を活かしてソフトを開発、販売して利益を上げることに熱意を持っている人材を多く見つけるために、Microsoftでは採用に当たって候補者を厳しく選別している。具体的には、個々の職能の専門性にあっていて小さなチームでうまくやっていける人材をさがす。管理者は一般に、社風に適応できる若者を見つけだそうとする。だが何もせずに最初から機能できる人材はいないのである。
そこで、実務と教育を同時にする、しかも、自分で学んでいける人材を採用しようとしている。つまり、研修制度や、多数の規則や手続き、製品に関する膨大な文書の作成などに多額の投資をするのではなく、実務を通じて学ばせることによって、プロジェクトの中に入れてしまうのである。製品の設計に関する知識を得るために口頭で教えてもらったり、コードを読んだり、自分で使ってみるといった方法がとられ、新人は先輩社員の作業を見て学び、試行錯誤を繰り返して学ぶことを余儀なくされた。これによって自分がプロジェクトの一部を支えているといった満足感を得て、社内での役割を認識し、広げていくことができるようになるのである。当然、新人の質問によって仕事が遮られることも多々あるだろう。コストが高くつく失敗もするだろう。早く仕事を覚えなければ他企業に足をすくわれかねないこの大量ソフト販売の世界では、とにかくミスを少なくし、新人を一人前にすることから全てははじまるのである。
入社するとまず一文で説明できるような機能分野をひとつ与えられ、責任をもたせる製品の出荷に自分の機能分野が出荷を遅らせる原因にしないために、安定性や機能性の分でも適当な水準を維持するという完璧な責任を与え、努力をさせるのである。そこで成果が認められるようになると、少し大きな機能分野でおなじような仕事を任せられるが、管理は緩やかになる。こうして時間が経つと、次第におおきなプロジェクトを任される。プロジェクトになると、プログラム管理者はじぶんひとりになるかもしれないが、最初の発想から出荷まで全て自分ですることを乗り越えてこそ「キャリア」がうまれるのである。キャリアを手にした時には、自分の職能分野が何であるかはあまり問題視せず、会社にとって必要なことを視野にいれるようになるのだ。
新人をいきなり実務につかせることは、Microsoftの生い立ちについてのビデオを30分みせるよりも効果的であるとしている。「とっくに知っているはずのことを見せても、士気を失わせてしまうだけだ。ここに初めてやってきた瞬間は、その後のキャリアで決して忘れないドキドキした瞬間でなくてはならない。だから、プロジェクトでは、新人をはじめからチームに加えたいと考えている。初日からだ。」とデーブ･ムーアは言う。だからといって、新人が書いたコードは機能チームのリード、その分野の専門家、担当のメンターなど先輩の開発者が、チェックを欠かすことはない。
また、各製品部門では、新人テスト担当者に製品やテスト支援ツールについて教えるため、独自の方法をとっており、製品分野がちがっても内容はかなり共通している。主要な部門ではマニュアルを用意しており、テストの考え方、テスト計画の見本、テストが終わったかどうかを決定するのに役立つチェックリストなどが掲載されている。テスト担当者も10人程の機能チームの中でベテランと共に学んでいくのである。
機能チームにベテランと新人が存在することは前節で述べた。この節では両者がチームの中でどのように作用しあい、仕事をしているのか述べる。
職能の中で、業務内容の確定と人材の確保が最も難しいといわれているのはプログラム管理である。主に、製品の仕様書作成や開発目標、スケジュールの設定、また製品開発グループ間の調整など、Microsoft創業期にゲイツが主に果たしていた役割である。ただし、プログラム管理が開発やマーケティングと完全に分離することは避けていた。小人数化したのは、チームの中で開発者とともに助け合って動き、時には責任を共有して、あるときには立場をわけて働いて欲しいからである。このような責任共有や堅密な相互協力関係がないかぎり、職能分野の確立は困難なのである。
現在では、ユーザー･サポートや開発者、ゲイツら経営幹部など社内からの情報を基に、開発目標書をまとめたうえ、製品仕様書をプログラム管理者と開発者が機能について議論し、プロトタイプをつくるとともにこの仕様書は改定されるようになっている。そのため、Microsoftでは設計書を書くソフト設計者と、設計書をもとにコードを書く職種がどういつの部署にある。つねに改定される仕様書を見続けるには、全過程に管理者が携わっていなければならないからである。
ただ、全過程に携わるといっても、実際に作業する個々のチームに対しては行使可能な権限はほとんどないといってよい。ただ、機能を削るうえで取捨選択をしたり、プロトタイプによって機能結果をチェックしたりするといった「判断」業務が多いのである。開発や製品管理、ユーザー教育からの情報で、プロジェクトの進歩状況をチェックし、チームのメンバーと中間目標について話し合い、製品を出荷できるのかどうかを議論する。機能チーム間のコミュニケーションが円滑にいくよう情報の交換をする役割と同時に、次の中間目標について経営陣と製品仕様についての入念な打ち合わせをに情報を提供し、ようやく最終目標である「製品の出荷」にこぎつけるのである。情報交換を迅速にするには、プロジェクト内のチームの規模が小さくなくてはならない。どうしてもプロジェクトがおおきくなると、製品の内容についての情報交換比率が低下してしまう。問題の整合性がない製品が多く、内部の製品の実際の機能とすこし違っていたりするし、整合性がない製品が出来ることになる。それを解決をするのがプログラム管理で情報交換の役割を担っているのである。また、優秀がために特殊で専門的になりがちなチームを、マーケティングからかけ離れさせないようにするのも重要な役目である。
第一章第三節で述べたように、1984年にテスト部門は独立した。 Microsoftの研修マニュアルでは、社内で認められている独立理由を三つ指摘している。第一に、開発者が完璧なコードを書くわけでなく、プログラム管理者も完璧な仕様書を書くわけではない。第二に、仕様書やコードの作成とかかわりのない第三者が、先入観無しに製品の品質を見極める必要がある。第三に、開発プロセスの出来るだけ早い段階、つまり、コードがまだ複雑になっていない段階でバグを発見して修正する方がコストがかからず、開発者にとって容易だし、さらには、製品の信頼性と顧客の満足度を高めることになる。
1995年のデータを見ると、テスト担当者は約4500人の開発スタッフ中、1850人である。これは大変に高い比率である。小人数チームを形成するのに何故ここまでテスト担当者が必要なのだろうか。それは、重大なバグの為に製品を回収･交換することをさけるための保険なのである。つねに改定されていく仕様書にたいして、機能やコンポーネントを少しずつ改良していく柔軟性が重要であって、製品の完成後に重要な欠陥を修正するのでは間に合わないという考えなのである。プロジェクトの初期段階からテスト担当者が機能し、製品の同じ部分を受け持つテスト担当者を管理するテスト･リードをおき、さらに、製品部門全体を統括するテスト責任者がいる。ここまで製品部門の開発に関わる責任者として、そして保険として置いているのである。Microsoft社内ではテスト担当者は余分人員ではないのである。
採用面接はすべて、製品部門内の職能部門の人間がおこなう。多くの日本企業のように人事課が一括して採用し、入社後に各部署へ振り分けるのではない。開発者の候補者ならばかならず開発者が面接する。それぞれが希望する職についてどれほどの知識を持っているかに留まらず、抽象的な意味でどの程度の能力があるかを見極めることを考えているのである。しかも、質問の答えの如何はたいして問題でなく、問題の分析方法をみているのである。素質や才能、自分の力で考える能力が判断される。各自が全員に面接結果を報告するので、多くの情報がスムーズに交換されるし、評価書に対する意識も相互に高めあう結果となる。
開発者とは、Ｃ言語に堪能でアセンブラ言語に精通している技術者であることを前提として、論理的思考能力がしっかりしていて、プレッシャーがかかったときに正確な仕事ができる人物である。どこの企業でも欲しがる人材である。ただ、違うのは、自己の可能性を追求し、市場に製品を出荷すること、そして本人にも会社にも利益をもたらすことに喜びを見つけ出す人材を求めている面である。ただ組織に従順な人間ではないのである。このことは第一章第四節で詳しく述べている。
また、プログラム管理者とは、製品を設計する過程に興味を持つ人間であるとしている。マーケティングの知識やコードを書くことよりも、ソフトを開発することに情熱を持っていて、自分のソフトに強烈な責任感があることが大切である。そして、情熱を持つ中にも冷静な全体的視野を兼ね備えている者である。別の角度から状況を検討できる者なのである。
最後に、約4500人の開発スタッフ中、1850人いるテスト担当者（1995年）に関してだが、ひとことで言えるのではないだろうか。それは、「疑い深い人間」である。あたらしく開発されたソフトを理解し、マニュアルが手元になくてもコンセプトを理解できる技術や能力は勿論持っていなければ、「疑い深く」はなれない。ソフトがうまく動くよりも、むしろ動かないことを期待するくらいでなければならないのである。しかも、できればテストは未経験で有能な人物を望んでいる。同社のテスト方式を短期間に習得し、低賃金で高い生産性をという同社の方針に合う可能性が高いからだ。
だが、結局はどの職能分野でも長時間勤務がかかせないのは言うまでもなく、どうしても仕事人間をうみだしてしまう。作業の膨大さに燃え尽きてしまう者も毎年10％程いる。しかし、事実、Microsoftは攻撃的で積極的なタイプを採用し、担当する仕事に責任感と誇りを持たせることにしている。多少少なめに採用することで、仕事に対する誇りを生み出させるのである。経営陣の査定の一つにある「生産性の低い下位5％の社員に退社勧告する」こともそれに拍車をかけているのだろう。
つまり、この企業は社員をやる気にさせることに秀でているのである。新入社員中で、募集、選考、燃え尽き症候群を切り抜けて残っていられるのは、有能で野心があり、長い目で見た収入のためなら、長時間勤務をもいとわない社員である。結局はゲイツら創業期の経営幹部にきわめて似たタイプの人物が社員として長く勤務可能なのである。
第四章 未来に向かって―――――――――――――
「企業の成功の一角は、CEOの指導力、経営能力、技術とビジネスに対する洞察力から生まれる。」ことであった。CEOゲイツは優秀な指導者であり、そのうえ、自分を支える優秀な「ブレーン･トラスト」をつくっている。その理念は、創業当時から存在していたのである。未来に向かってきわめて効率的に事業を進めるにあたって、その基礎となった部分をこの章であげていきたいと思う。
まずは、経営幹部の知識と技術の豊富さである。これは、現存するさまざまな企業と比較しても遜色ない。企業が利益を上げるには組織をどうしたらよいかを知っているという点では、急速に進化し、拡大する市場で競争していくのに適した経営幹部であるといえよう。そのような経営幹部の下で、社員がきわめて効率的で、統一の取れた競争戦略と目標をもっていることは大変な強みである。製品を市場に出荷することが重要であると第二章で述べた。Microsoftでは規則や手続きが足かせとなって、製品の出荷がおくれるようなことはあってはならないのである。ユーザーがその価値を求めている製品の出荷を遅らせるということは、利益をへらすことであることを経営陣は熟知している。利益を刺激することにすべてのことは機能しなければならない。小人数のグループで責任を分担しながら作業をすすめ、官僚的な管理を極力すくなくすることを重視する。
IBMのように肥大化した巨大組織が、段階を踏まえることを重視するあまり肝心のスピードをうしなうようでは、市場獲得競争に敗れてしまうのである。大量販売市場はスピードでシェアを獲得できるチャンスなのである。業界標準となる製品を開発して売り上げと利益を伸ばすとともに、業界標準メーカーMicrosoftの立場を築くべく、機能を強化し、追加し、段階的に改良し、膨大な数にのぼる既存のユーザーと製品を利用していかねばなるまい。
それには、製品の開発と組織の拡大に現時点よりもより柔軟で段階的な方法をとるべきである。確かに、Microsoftはプロジェクト内で管理者の承認の下で、基本設計や仕様書を「凍結」せず柔軟に変更してよいとされている。最初に設定した漠然とした計画を随行し、最終段階で膨大なバグ出しをするような企業よりは断然効率的であるといってよい。ユーザーの具体的な活動に目標をおきながら、機能を段階的に進化させて製品をつくりあげることができる為だ。それほどユーザーの機能反応をプロジェクト初期に予想するのは困難なのである。技術と市場の移り変わりを読んで、社員を異動させ、新たな部門をつくり、絶えず組織を再編する。そして製品、プロジェクト、会社全体の組織の変化を管理し、規則や手続きに縛られる仕事は極力減らすことが重要である。
組織の変化を管理して効率性を保つには、膨大なデータ（知識）の蓄積と、プロジェクトにこだわらずツールとコンポーネントを共有することからはじまる。つまり、規模の経済と範囲の経済の利点を活かすのである。大量の新製品を売り出し、その利益によって研究開発費をまかなう。また、製品開発でもそれ以外の活動でも、数多くの作業を同時平行で進め、各職能部門の責任範囲と技術が重なるようにし、仕事を小人数の多機能チームに割り当てて、いくつかの中間目標を掲げてそれぞれの段階でいくつかの機能を安定化させる方針をとり、効率性と柔軟性を保たねばならない。開発の局面を順次たどる「ウォーターフォール」型プロセスをとらずに、開発とテストを平行して行うのだ。
終章――――――――――――――――――――――
年功序列や官僚的体制に代表される「日本型経営」が批評されて久しい。
「リエンジニアリング革命」（Michael Hammer & James Champy）中で定義されるリエンジニアリングの定義は、「コスト、品質、サービス、スピードのような、重大で現代的なパフォーマンス基準を劇的に改善するために、ビジネス･プロセスを根本的に考え直し、抜本的にそれをデザインし直すこと。」とされている。論文中で述べてきたように、Microsoftはビジネス･プロセスを「製品を市場に出荷すること」のみに焦点をあてて作業をすすめてきた。他企業に例を求めず、“Microsoft流”を築いてきたのだ。「根本的」「抜本的」「劇的」「プロセス」の四つのキーワードを軸にして、ただの小規模ソフトウェア会社を現在まで育てたのである。IBMという巨大な汎用コンピュータメーカーが支配する情報機器市場に、未来を見据えた選別眼と管理者としての類いまれな才能をもって登場したのである。そこで自他共にみとめる「企業の根本的な理念」を築き上げたのだった。
機能が弱まっているとされる日本的経営を今後も続けていくとしたら、世界の潮流に取り残されるのはいうまでもなく、グローバル化を見据えた企業の躍進を望むならば当然検討せねばならぬ問題なのである。
そして大切なのは、「社員の知識＝会社の資源」という考えだ。資源は社内で共有しなければ効率性を高められない。共有可能な資源が豊富になればなるほどプロジェクトは活発化して相互作用しながら目標に向かって動きやすくなるのである。流動性のある資源活用の出来ない企業は次第に淘汰されていくのである。