第3回 タイムマネジメントは急がば回れ
杦岡充宏（スカイライトコンサルティング）
2004/6/16
前回（「第2回 みんなを幸せにするスコープマネジメント」）は、プロジェクトの成否を分けるスコープの管理について解説した。プロジェクトの関係者全員が満足する結果が得られるようにスコープを設定し、状況に合わせて変更・管理していくことはなかなか難しい。しかし、プロジェクトのゴールを踏まえたうえでスコープを可視化し、優先順位付けの判断基準を明確にし、関係者全員の合意を得る努力をしていれば、おのずと納得のいく意思決定を下せるのではないだろうか。
今回は、プロジェクトの推進に欠かせないタイムマネジメントの勘所を解説する。「第1回 プロジェクトメンバーを1つにまとめる」で触れたようにプロジェクトとは何らかの目的の達成を目指して、「一定期間」に行われる活動である。期限が定められているということがプロジェクトの特徴であり、期限を順守することはプロジェクトマネジメント（PM）において重要な要素であることはいうまでもないだろう。それではまず、PMBOK（Project Management Body Of Knowledge）におけるタイムマネジメントの定義を確認しておこう。
■タイムマネジメントとは
タイムマネジメントとは、プロジェクト開始前の計画段階に必要な作業を洗い出しスケジュールを作成し、そのスケジュールの予定と実績を管理していくことである。前回のスコープマネジメントと同様、「Plan-Do-See-Action」のサイクルになっている。つまり、プロジェクト期間中、スケジュールは常に見直され、最新の状態に保たれていなければならない。PMBOKでは、タイムマネジメントは表1の5つのプロセスから構成されている。
タイムマネジメント
のプロセス 主要成果物 説明
作業定義 作業リスト、WBS更新版 スコープ定義で作成したWBSに基づき、実際の作業に分解する
作業順序設定 プロジェクトネットワーク図 作業間の順序関係を定義する
作業所要時間の見積もり 作業ごとの所要時間見積もり それぞれの作業を完成させるために必要な所要時間を見積もる
スケジュール作成 プロジェクトスケジュール 作業の開始日・終了日を決定する
スケジュール管理 プロジェクトスケジュール更新版 進ちょく度を測定し、スケジュール変更の管理を行う
表1 PMBOKにおけるタイムマネジメント
タイムマネジメントはスケジュールマネジメントとも呼ばれるように、スケジュールを作成しないプロジェクトは存在しないといえよう。スケジュールはプロジェクトを進めていくうえでのよりどころである。しかし、多くのプロジェクトではスケジュールどおりには進まず悪戦苦闘している。どうすればよいのだろうか？
プロジェクトの最初に立てたスケジュールどおりに最後まで終了すればプロジェクトマネージャとしてこんなうれしいことはない。しかし、その場合スケジュールを作成する時点でプロジェクトの成果物、必要な作業、そして各作業の所要工数がすべて確定していることが前提である。しかし、残念ながらこのようなケースは極めて少ない。スケジュールを作成する時点では情報が不足しており、思ったとおりに物事が進まないのが現実である。最初から完ぺきなスケジュールを作成できるとは思っていけないのである。
■作業定義は過不足なく、スケジュール管理は柔軟かつタイムリーに
タイムマネジメントの目的は最初から完ぺきなスケジュールを作成することではなく、「納期どおりにプロジェクトを完了させるために必要な作業をスケジュールどおりに終了させること」である。
完ぺきなスケジュールを組もうとするあまり、管理不能なほど詳細な作業定義を作成してしまったり、過去のプロジェクトで使ったスケジュールを無理に流用し、作業リストがプロジェクトの実態と乖離（かいり）してしまったりすることがある。このように、スケジュールの「体裁」に意識がいってしまうと、本来の目的を見失ってしまいがちである。
重要なことは、
スケジュール作成時点では、納期やフェイズの終了時など重要なマイルストーンに大きな影響を与えないことに重点を置く
予定と差異が見られたときに迅速に適切な対応を取る
である。
誤解のないように付け加えておくが、最初にち密なスケジュールを作成するなといっているわけではない。本来の目的を見失わず、凝り過ぎず、不確実性に対して柔軟に対処する心構えを持とうということだ。
それでは、タイムマネジメントの実践的な勘所について、ケーススタディを通じて紹介していくことにしよう。
■進ちょく度を「判定」するだけではマネジメントとはいえない
あなたの部署で進行中のプロジェクトのうち、納期遅れが心配されているものが2つある。営業担当からの要請を受け、あなたはそれぞれのプロジェクトを調査し、ばん回するためにはどうすればよいのかをエンジニアの立場から助言することになった。
そこで、それぞれのプロジェクトを担当している「矢見雲マネージャ」と「出来杉マネージャ」のもとを訪問し、状況を聞くことにした。
矢見雲マネージャの発言
「正直いって、当初予定していたスケジュールどおりには進んでいない」
「プロジェクトの開始時には、顧客が要求したマイルストーンをメンバーに周知したうえで、問題があれば報告するように伝えておいた」
「スケジュールが厳しいのは最初から承知のうえだ。だからメンバーには走りながら考えるように指示して、立ち上がりからアウトプットを出すように要求していた」
「ところが今回は私が得意としていたクライアント／サーバ系のシステムではなくWeb系のシステムだった。画面遷移が多いため、思っていた以上に設計書のボリュームが増えてしまった。負荷を軽減するために設計文書のフォーマットと作成単位を見直したが、途中まで作った設計文書もこれに合わせるため再度作り直す必要が出てきた」
「このままいくと、設計フェイズのマイルストーンは最低でも3週間遅れとなるが、開発フェイズでばん回できると信じている。顧客にはこれから説明するが、きっと理解を示してくれるだろう」
「メンバーも徹夜続きで大変疲れているが、どうか君を含め応援部隊の力を貸して欲しい。よろしく頼むよ」
出来杉マネージャの発言
「正直いって、当初予定していたスケジュールどおりには進んでいない」
「プロジェクト開始前には、顧客の要求したマイルストーンをクリアできるよう、作業定義を行ってスケジュールを調整しようとした」
「しかし、今回は私が得意としていたクライアント／サーバ系のシステムではなくWeb系のシステムだった。作業リストや作業順序については問題ないと思ったが、設計書のボリュームが読めなかったので従来の見積もりによる作業時間に10%のバッファを持たせることにした」
「この結果、顧客の要求したマイルストーンから2週間ほど遅れる計画となってしまった。」
「しかし、顧客はマイルストーンの変更を受け入れなかったので、何とかこのフェイズでばん回できるよう、スケジュールを短縮する方法を検討した。具体的には、10名のメンバーのうち2名だけ、業務範囲を絞ったうえで作業を先行させ、各作業の生産性データを収集するとともに、作業効率を改善するために何ができるかを検討してもらった」
「その結果、設計文書のフォーマットと作成単位を見直すことによって、作業時間が5％ほど改善することが分かった」
「これで遅れを1週間に縮めるメドがたった。作業を先行させたメンバーについては学習効果により生産性が上がっているので、チーム内における作業分担の見直しによって全体ではさらに期間短縮が可能だろう。メンバーには申し訳ないが、週末に何日か作業すれば十分にばん回できる見込みはあると思っている」
スケジュールは、作業定義、順序、各作業の所要時間が見積もられていて初めて成立する。矢見雲マネージャのように「走りながら考える」というのはいささか乱暴な例ではあるとしても、作業ごとの所要時間まで事前に想定することはなかなか難しいのではないだろうか。PMBOKでは、見積もりの技法の1つとして類推見積もりを挙げている。これは、過去の作業や類似作業の実績値を用いて、作業の所要時間を推定するテクニックである。出来杉マネージャは、この技法を使って保守的な見積もりを行っている。経験を積んだシステム開発会社であれば、スケジュール作成時の方法論や見積もりの基礎となる実績データを全社で共有しているところもあるだろう。
また、出来杉マネージャは先行チームを使って実測値を取り、さらに生産性改善の方策を探っている。大規模なプロジェクトであればあるほど、このような先行チームを持つことの意義は大きくなる。単に「信頼できる」実測値を取ることができるだけでなく、予測不能な問題を検知してプロジェクト全体での手戻りを最小限に食い止めることができるからだ。もちろん、プロジェクトマネージャは先行チームの成果を適切にプロジェクト全体にフィードバックし、共有できるよう配慮しなければならない。プロジェクトマネージャは単にスケジュールどおりに進んでいるかどうかを「判定」するだけでなく、作業を標準化し、負荷を平準化し、作業効率を高めることによって、スケジュールの実績値を「作り込む」努力をしなければならないのである。
■重要なタスクの抜け・漏れが生じる
さて、2つのプロジェクトはその後開発フェイズに入り、単体テストを実施している。それぞれのマネージャの様子を見てみよう。
矢見雲マネージャの発言
「開発フェイズも単体テストに入り、一段落した感がある」
「これからは単体テストの実施に加えて、システムテストの準備をしていく必要がある」
「ところで、現行システムからのデータ移行についてはスケジュール上決まっていないことがほとんどだな」
「システムテストの準備で当面手いっぱいだから、データ移行についてはシステムテストの計画策定後ということにしよう」
「それでも少し不安だから、君を含め応援部隊の力を貸してほしい。よろしく頼むよ」
出来杉マネージャの発言
「開発フェイズも単体テストに入り、いよいよ開発の佳境に入ってきた」
「これからは単体テストの実施に加えて、システムテストの準備をしていく必要がある」
「現行システムからのデータ移行については、プロジェクト開始前の計画によると単体テスト開始後に準備着手ということになっていた。システムテストの後半では、実際に移行データの一部を使ったテストを行う必要があるからだ」
「従って、今後はチームを3つに分けて、単体テスト、システムテストの準備、データ移行の準備を実施していこうと考えている」
「正直いって楽ではないが、この時期に着手しておかないと後で取り返しのつかないことになる。万が一、データ移行の準備につまずいてシステムテストの実施に影響が出ると大変だからな」
「幸い、現行システムの調査については顧客から全面的な協力を得ている。まだまだ気は抜けないが、いまの要員で何とか大丈夫だろう」
作業定義を行う際には、対象となるスコープのWBSすべてについて、漏れなく作業をリストアップする必要がある。その点、矢見雲マネージャは、プロジェクト開始前にデータ移行の作業を定義していなかったばかりでなく、いまの作業に気を取られて、着手すべき時期になっても着手できていない。いずれは、関連する作業（システムテスト）にも影響が出てしまうことは必至である。プロジェクトマネージャには、常に先を見越したうえで先手を打つ姿勢が求められるのである。
■スケジュールと実態が乖離し、有名無実化する
2つのプロジェクトはそれぞれ終盤にさしかかってきた。開発フェイズにおけるメンバーの頑張りもあって、遅れはある程度ばん回できたもようだが、最終納期に向けて予断を許さない状況である。それぞれのマネージャの様子を見てみよう。
矢見雲マネージャの発言
「プロジェクトもいよいよ大詰めだ」
「途中、ある程度はばん回したものの、やはり2週間程度の遅れは致し方ない」
「プロジェクト内部の週次進ちょく会議ではまだ顧客には報告できていないが、状況は理解してくれているので説明すれば分かってくれるだろう」
「来週、プロジェクトオーナーである顧客の取締役を含めた報告会があるので、その場で正直に説明することにしよう」
「遅れの責任の大半はわが社にあるとはいえ、これだけの要求事項を満たしながら頑張ってきたのだから、期間超過分のコストについては請求せざるを得ないだろう」
「まあ、お金の話も含めて交渉だな」
出来杉マネージャの発言
「プロジェクトもいよいよ大詰めだ。」
「途中、ある程度はばん回したものの、やはり1週間程度の遅れは致し方ない」
「すでにプロジェクト内部の週次進ちょく会議では、毎週のように進ちょくを報告してきたのだから、状況は顧客もよく理解している」
「来週、プロジェクトオーナーである顧客の取締役を含めた報告会があるので、その場でどのように説明すべきかということについても、すでに顧客と調整したうえで資料を準備しているところだ」
「これもすでに顧客に報告していることではあるが、今回の遅れの要因は仕様変更要求が多かったことに尽きる。これについては仕様変更管理手続きで承認されたことであるから、期間超過分のコストについては請求しても問題ないだろう」
「ただし稼働日が遅れることによって期待していたコスト削減効果に若干の影響が出るな。これについては年度を通してみれば微々たるものだが、きちんと説明しておく必要があるだろう」
矢見雲マネージャの場合は、プロジェクト内部の週次進ちょく会議を毎週実施しているにもかかわらず、遅れの実態を顧客と共有できていない。こうなってしまうと、スケジュールはあっても意味のないものになってしまう。本来スケジュールの進ちょく度を確認し、問題があれば対策を検討する場であるはずの週次進ちょく会議も、有名無実化してしまっているのである。これは、顧客に対してタイムリーな報告を怠っているというだけでなく、週次進ちょく会議の時間を無駄に費やしているという意味で、二重の問題がある。
プロジェクトの遅れは確かに問題ではあるが、出来杉マネージャのようにすべてを把握し、関係者との調整を適切に行っていれば、必ずしもプロジェクトの成功が危ぶまれるというわけではない。要は適切に管理することが重要なのであって、プロジェクト開始当初の計画を盲目的に守りきることだけが重要なのではない。
最後になるが、こうしたタイムマネジメントを実現するためには、プロジェクトメンバー全体に時間に対するコスト意識を浸透させるべきであることを付け加えておきたい。時間に対するコスト意識が緩んでくると、プロジェクトの全体パフォーマンスが落ちるのである。出社時間が遅くなる、会議に遅刻する、だらだらと必要以上に残業する、などの事象は時間に対するコスト意識が低下しているサインである。こうしたサインが表れると、生産性や品質が低下し、ひいてはスケジュールに影響が及ぶ。時間に対するコスト意識とチームとしてのパフォーマンスには、相関性がある。例えば、野球のメジャーリーグやF1などのプロスポーツの世界では、メンバーの遅刻に対して罰金を科しているチームがある。強豪チームであればあるほど、こうした形で規律が保たれている。罰金を科すことについて、その是非をここで議論することは控えるが、プロジェクトにおけるメンバーの時間に対する意識について、あらためて振り返ってみてはいかがだろうか。
■今回のまとめ
・タイムマネジメントとは、プロジェクト開始前の計画段階に必要な作業を洗い出してスケジュールを作成し、そのスケジュールの予定と実績を管理していくこと。
・タイムマネジメントの目的は最初から完ぺきなスケジュールを作成することではなく、「納期どおりにプロジェクトを完了させるために必要な作業をスケジュールどおりに終了させること」
・作業を標準化し、負荷を平準化し、作業効率を高めることによって、スケジュールの実績値を作り込む努力をすること。
・作業定義を行う際には、対象となるスコープのWBSすべてについて、漏れなく作業をリストアップする。常に先を見越して、早めにアクションを取る姿勢も忘れずに。
・実績が計画から乖離した際には、ステークホルダーにタイムリーに情報共有するとともに、是正措置を取る。
・メンバーに時間に対するコスト意識を持たせ、チームとしてのパフォーマンスを高める。
Friday, December 31, 2004
第2回 みんなを幸せにするスコープマネジメント
第2回 みんなを幸せにするスコープマネジメント
杦岡充宏（スカイライトコンサルティング）
2004/4/14
前回（「第1回 プロジェクトメンバーを1つにまとめる」）は、プロジェクトマネージャの本質的な役割について解説した。それは、「プロジェクトを成功という1つのゴールに向かって導く」ということであった。プロジェクト関係者との情報共有を通じて、みんなの気持ちを1つにすることは大変重要である。これさえうまくいけば、プロジェクトはよいスタートを切れるといえるだろう。
実際にプロジェクトを推進していくうえで、プロジェクトマネージャが具体的に取り組むプロジェクトマネジメント（PM）の仕事には、どんなものがあるだろうか。PMBOKでは、これを9つの要素に分類し、「知識エリア（Knowledge Area）と呼んでいる。
スコープ
時間（スケジュール）
コスト
品質
組織
コミュニケーション
リスク
調達（人・モノ）
統合（上記すべての統合、という意味）
今後の連載では、これら9つの各領域について、現場でよく見られるシチュエーションを取り上げながら、PMの実践的な勘所を解説していきたい。今回はプロジェクトの成功／失敗に大きな影響を及ぼすといわれているスコープマネジメントについて解説する。
■スコープマネジメントとは
まず、スコープマネジメントの定義を確認しておこう。その名前から受ける印象で、プロジェクトの初期段階において「何を」「どこまで」やるかを決定することだと思っている方が多いかもしれない。しかし、「何を」「どこまで」やるかを決定することはスコープマネジメントの一部分でしかない。マネジメントというからには「Plan-Do-See-Action」のサイクルが必要である。つまり、プロジェクト期間中、スコープは常に見直され、最新の状態に保たれていなければならない（なお、これはスコープに限らずスケジュールや予算などほかの要素においても同様である）。
PMBOKの定義に簡単に触れておくと、スコープマネジメントとは「プロジェクトの目標である最終成果物を作成するために必要な作業が過不足なく確実に遂行されることを保証すること」であるとしている（表1）。
スコープマネジメントのプロセス 主要成果物 説明
プロジェクトの立ち上げ プロジェクト憲章
（チャーター） プロジェクトの基本事項（目的・目標・主要成果物、概略予算・見積もりなど）を定義
スコープ計画 スコープ記述書 必要な成果物を定義
スコープ定義 WBS 成果物を遂行するためのタスクを定義
スコープ検収 検証（検収）後成果物 成果物の検証（検収）
スコープ変更管理 変更後スコープ 成果物とタスクの見直し（変更）
表1 PMBOKでのスコープマネジメント（概要）
つまり、スコープマネジメントとは、
プロジェクトの目標を達成するために必要な成果物とタスクを定義する
プロジェクト期間を通じて、必要に応じてその定義を見直していく
必要な成果物とタスクが完成されていることを保証する
ということである。
次に、冒頭で述べた「スコープマネジメントがプロジェクトの成功／失敗に大きく影響を及ぼす」ということに簡単に触れておく。
■スコープマネジメントがプロジェクトの成否を分ける
プロジェクトが成功裡に終了するのは全体の約20～30％、厳しい見方をする人によると1000に3つともいわれる。いかに多くのプロジェクトが失敗に終わっているか、お分かりいただけるだろう。こうした中でプロジェクトの失敗は、スコープマネジメントのまずさによる場合が多いといわれている。なぜだろうか。
このことを考えるに当たり、まず「プロジェクトの成功」について整理しておく必要がある。
プロジェクトの成功とは、しばしば当初定められた「期間どおりに」「予算どおりに」「品質を満たすこと」といわれるが、果たして、これらを満たせばプロジェクトは成功なのだろうか？
当初定められた品質は満たしたが、結果としてユーザーに使ってもらえなかった。または、プロジェクトメンバーが長期間にわたり過酷な労働に陥り、健康を害するメンバーが続出するといったプロジェクトは成功といえるのだろうか？
筆者は、本質的にプロジェクトの成功とは、
「プロジェクトにかかわるすべての利害関係者に満足する結果をもたらすこと」
であると考えている。ここで利害関係者とは、顧客サイドの経営層、スポンサー、発注者、ユーザーなどに加え、受注サイドの営業部門、開発部門、協力会社などの人々を指す。
すべての利害関係者に満足する結果をもたらすためには、「プロジェクト実施前に各関係者が期待するもの」と「プロジェクト実施後に各関係者が得るもの」を一致させなければならない。しかし、両者を一致させることは難しい。「期待」は常に変化するし、「得るもの」は思いどおりに提供できるわけではない。これを実現するためには、「何を」「どこまでやるか」を具体的に決め、実行し、常に見直していくしかない。すなわち、プロジェクトの目的と目標を明確にし、必要な成果物・作業を明確にし、実行計画を策定し確実に遂行するしかないのである。これは先に説明したスコープマネジメントそのものであることがお分かりいただけるだろうか。文字どおり、スコープマネジメントはプロジェクトの成功へ直結するのである。
それでは、スコープマネジメントを「スコープを決める」「決めたスコープをコントロールする」という2つの観点から、実践的な勘所ケーススタディを通じて紹介していくことにしよう。
■スコープの決定にはプロジェクト関係者全員の合意と理解が不可欠
あなたの部署に2つのシステム開発案件が舞い込んできた。どちらの案件も、営業サイドとしては何としても受注したかったため、予算も納期もかなり無理をして取ってきたようである。
あなたの部署の「矢見雲マネージャ」と「出来杉マネージャ」がそれぞれの案件を担当することになり、プロジェクトがスタートした。あなたは、どちらかのプロジェクトに配属されることになり、2人のマネージャからそれぞれのプロジェクトの説明を聞くことにした。
矢見雲マネージャの発言
「私も提案書については、正直、現実的ではないと感じている。提案時にもそういった。しかし、会社の上層部からも受注しないといけない重要なプロジェクトということで念を押されているので、腹をくくって何とかしてやるしかないと思っている」
「ただ、顧客と実現すべき機能や仕様については大枠合意が取れているので、そこは救いだな」
「さっきも話したけど、このプロジェクトはわが社としても非常に重要な案件なので、ぜひ君に力を貸してほしい」
「じゃあ、よろしく頼むよ」
出来杉マネージャの発言
「私も提案書については、正直現実的ではないと感じたので、まず営業サイドに提案書の見積もりの根拠を確認した」
「すると、受注のために明確な根拠なく見積もりを作成していたことが判明したので、急きょ、プロジェクト計画を作り直すことにした」
「まず顧客の要望に使用頻度と重要度が低いと考えられる要望が多く盛り込まれていたので、顧客の要望を再確認した」
「営業サイドからは機能・仕様は、顧客と大枠合意されていると聞いていたが、実はこの顧客、ユーザー部門とは別部署のメンバーで、ユーザー部門に確認する必要があることが判明した」
「再度、ユーザー部門を交えて要望を整理したところ、当初の3割程度が不要な機能であることが判明した」
「それでも再見積もりの結果、当初見積もりの2割増になったが、顧客と営業サイドと上層部に見積もりの根拠を説明するとともに、元の予定でいくと結果的に納期遅延や予算オーバー、そしてプロジェクトが混乱に陥り、成果物の品質も落ちて顧客満足が得られないこことが危惧（きぐ）されることを指摘して納得してもらった」
「正直、これでも楽な計画ではないが、われわれはこの計画に自信を持っている。そしてこの計画の達成には君の力が必要だ。ぜひ、このプロジェクトを一緒に成功に導こうではないか」
先に触れたように、プロジェクトの成功とはプロジェクトにかかわるすべての利害関係者に満足をもたらすことである。プロジェクトの利害関係者とは、顧客サイドにおいても、経営層、スポンサー、発注者、ユーザー、そのほか関係部署と多岐にわたる。また受注サイドにおいても、営業部門、開発部門、場合によっては経営層などが関係する。
これら関係者は、それぞれ立場が異なるので利害を異とすることが一般的である。利害を異とする関係者の満足を達成するには、まず「何をいつまでにいくらで達成すれば満足するか」というプロジェクトの基本事項について、関係者全員の合意と理解を得ずして成し遂げられないことはご理解いただけるであろう。
重要なことは、一部の関係者ではなく「関係者全員」の合意と理解である。
先の矢見雲マネージャの例では、見積もりについて顧客サイドの発注者と受注サイドの営業部門、経営層は合意しているが、開発部門と合意されているとはいえない。また、機能・仕様については、顧客サイドの発注者と受注サイドの営業部門は合意しているが、顧客サイドのユーザーは合意していない。
ここで挙げたケースは、PMBOKでいうところの「プロジェクトの立ち上げ」においてプロジェクトの基本事項を定義する段階の話しであるが、ちまたにあふれる失敗プロジェクトには、プロジェクトの開始時点ですでにこのような全員の合意が得られていないプロジェクトが多いように考えられる。
あなたの周りのプロジェクトではこのようなことが起こっていないだろうか……。
実際にすべての利害関係者の合意と理解を得ることは容易ではないが、読者がもしこれまでこのことを意識していなかったとすれば、まず第一歩として、プロジェクトの利害関係者をすべて洗い出し整理しておくことをお勧めする。話を通すべき相手が分かっているだけでも結果は大きく変わってくるといえよう。
また今回の例では、プロジェクトの初期段階を取り上げたが、関係者全員の合意と理解を得ることは、プロジェクト期間を通じて行わなければならないことを付記しておく。
■スコープを可視化する
先に紹介したプロジェクトはその後数カ月がたち、現在はユーザーによるテストフェイズを迎えている。ところが、この段階でユーザーから数多くの追加要求の声が上がってきた。システムの稼働まではもう1カ月しかない。このような状況における2人のマネージャと顧客側担当者とのやりとりを見てみることにしよう。
矢見雲マネージャの発言
矢見雲：「今回ご指摘いただいたご要望は前フェイズまでにご確認いただいた要件にはありませんでした。これからの追加となるとスケジュール的にも予算的にも厳しいのが正直なところです」
顧客：「困ったなあ。当然盛り込まれているものと思っていたのにどうして入ってないの？」
矢見雲：「われわれとしては要件として明確に確認させていただいたことについて対応させせていただいています。しかし、今回の場合、そういう要件があるということは認識しておりませんでした」
顧客：「そんなのいわなくたって分かっているだろう。いずれにしても、今回の要件は絶対必要なんだよ」
矢見雲：「分かりました。対応方法を検討させてください」
出来杉マネージャの発言
出来杉：「今回ご指摘いただいたご要望は、今回のシステムで実現する機能を網羅的に整理した『機能要件一覧』には含まれていませんでした。これからの追加となるとスケジュール的にも予算的にも厳しいのが正直なところです」
顧客：「そうだったか。ちゃんと確認したつもりだったが漏れていたようだね。でも、いずれにせよ必要な機能なので何とか対応しなくてはならないんだ。何とかならないものか」
出来杉：「分かりました。対応方法を検討させてください」
ポイントは、スコープを「可視化」することにある。矢見雲マネージャの例の問題点は、要件定義の段階で、顧客と双方でスコープ（要件）を確認できる共通の成果物がないことだ。顧客側は要件として当然含まれていると認識しているが、開発側は要件として明確になっていないために、当然スコープには含まれていないと考える。ここで認識のズレが生じていたのである。
出来杉マネージャの例では、「機能要件一覧」を使って、双方でスコープを確認している。例えばスカイライトコンサルティングでは、対象とする「業務」または「システム機能」を階層的に整理し、一覧表の形式にしている。「機能要件一覧」によって顧客側、開発側双方が網羅的にスコープを確認できるため、「抜け漏れを防ぐ」点と「万一、抜け漏れがあった場合の責任の所在が明らかになる」という点で大きな効果がある。
要件の優先順位付けは、個別に見れば全部重要となってしまう
次に、上の例の続きで、実際によく見られるスコープコントロールのケースを紹介しよう。
矢見雲マネージャの発言
矢見雲：「今回ご指摘いただいた要件は3件あります。これら全部に稼働までに対応することは正直困難ですので、優先順位を付けて重要度の高いものから対応していき、そうでないものは稼働以降に対応させていただきたいと考えております」
顧客：「致し方ないな。それでお願いすることにしよう」
矢見雲：「ありがとうございます。では、早速それぞれの要件の検討を進めていきましょう。まず1番の要件ですが……」
顧客：「それは必須だな。それがないと業務が回らない」
矢見雲：「では2番の要件ですが……」
顧客：「それも重要だな。それがないとユーザーの負荷が著しく増加する」
矢見雲：「では3番の要件ですが……」
顧客：「それは当然必要。ないと取引先にも影響を与える。結局、全部必要なんだよ」
矢見雲：「いったん持ち帰らせてもらって開発側でなんとか押し込めないか検討してみます。返事は社に戻って検討した後、ご連絡します」
出来杉マネージャの発言
出来杉：「今回ご指摘いただいた要件は3件あります。これら全部に稼働までに対応することは正直困難ですので、優先順位を付けて重要度の高いものから対応していき、そうでないものは稼働以降に対応させていただきたいと考えております」
顧客：「致し方ないな。それでお願いすることにしよう」
出来杉：「ありがとうございます。では、早速どういう基準で優先順位を付けるかということを検討させてください。まず、取引先など対外的に影響を与えるものは、やはり最優先かと考えていますがいかがですか？」
顧客：「そうだな。外に迷惑をかけることはできないな」
出来杉：「では、これを『重要度：高』としましょう。次にユーザーに与える影響ですが、これは、その要件により影響を受けるユーザー数と業務量に応じて影響の大きさは変わってくると思うので、影響の大きいものは『重要度：中』、そうでないものは『重要度：低』ということでいかがですか」
顧客：「分かった。それでいこう」
出来杉：「そうすると3つの要件はどうなりますか？」
顧客：「3番は『重要度：高』だな。あとの2つは『重要度：低』ということになるな」
出来杉：「分かりました。では、3番だけであれば何とかできる可能性はあるので、スケジュールを検討してみます。あとの2つは稼動後できるだけ早い時期に対応するということで、いつ対応するか別途検討しましょう」
顧客：「そうしよう」
出来杉：「それと対応する方向の3番については、仕様変更手順に基づき、ステアリングコミッティ（プロジェクト運営委員会）での承認が必要になります。仕様変更依頼書を作成しますので必要事項に記入をお願いします」
顧客：「分かった。ありがとう。よろしく頼むよ」
このケースで重要なポイントは、追加要件に対応することが難しい場合によく行われている「優先順位を付けて対応を考える」ことにある。矢見雲マネージャの例では、個別の要件ごとに判断しているが、このような場合、各要件に必要とされる理由や背景に基づいて判断することになる。しかし、これだとどうしてもあれも重要、これも重要となってしまう、あるいは顧客とこちらで重要度が一致しないということに陥りがちではないだろうか。
重要なのは、どういう基準で優先順位を付けるかについて合意することである。顧客と開発側の双方が容易に判断できるプロジェクト全体を通しての判断基準をておくことにより、お互いに納得のいく意思決定が迅速にできる。
■今回のまとめ
・スコープマネジメントとは、プロジェクトの目標を達成するために必要な成果物とタスクを、プロジェクト期間を通じて定義していき、その内容をやり遂げることを保証すること。
・スコープマネジメントは、プロジェクトの成功／失敗に大きく影響を及ぼすこと。
・スコープを決定する際は、プロジェクトの関係者が誰であるかをしっかり押さえて、関係者「全員」の合意を得ること。
・定義したスコープは、顧客／開発側双方で確認できるよう「可視化」しておき合意を得ること。
・スコープの変更を検討する際に、要件の優先順位を検討する場合は、優先順位付けの判断基準を明確にすること。
杦岡充宏（スカイライトコンサルティング）
2004/4/14
前回（「第1回 プロジェクトメンバーを1つにまとめる」）は、プロジェクトマネージャの本質的な役割について解説した。それは、「プロジェクトを成功という1つのゴールに向かって導く」ということであった。プロジェクト関係者との情報共有を通じて、みんなの気持ちを1つにすることは大変重要である。これさえうまくいけば、プロジェクトはよいスタートを切れるといえるだろう。
実際にプロジェクトを推進していくうえで、プロジェクトマネージャが具体的に取り組むプロジェクトマネジメント（PM）の仕事には、どんなものがあるだろうか。PMBOKでは、これを9つの要素に分類し、「知識エリア（Knowledge Area）と呼んでいる。
スコープ
時間（スケジュール）
コスト
品質
組織
コミュニケーション
リスク
調達（人・モノ）
統合（上記すべての統合、という意味）
今後の連載では、これら9つの各領域について、現場でよく見られるシチュエーションを取り上げながら、PMの実践的な勘所を解説していきたい。今回はプロジェクトの成功／失敗に大きな影響を及ぼすといわれているスコープマネジメントについて解説する。
■スコープマネジメントとは
まず、スコープマネジメントの定義を確認しておこう。その名前から受ける印象で、プロジェクトの初期段階において「何を」「どこまで」やるかを決定することだと思っている方が多いかもしれない。しかし、「何を」「どこまで」やるかを決定することはスコープマネジメントの一部分でしかない。マネジメントというからには「Plan-Do-See-Action」のサイクルが必要である。つまり、プロジェクト期間中、スコープは常に見直され、最新の状態に保たれていなければならない（なお、これはスコープに限らずスケジュールや予算などほかの要素においても同様である）。
PMBOKの定義に簡単に触れておくと、スコープマネジメントとは「プロジェクトの目標である最終成果物を作成するために必要な作業が過不足なく確実に遂行されることを保証すること」であるとしている（表1）。
スコープマネジメントのプロセス 主要成果物 説明
プロジェクトの立ち上げ プロジェクト憲章
（チャーター） プロジェクトの基本事項（目的・目標・主要成果物、概略予算・見積もりなど）を定義
スコープ計画 スコープ記述書 必要な成果物を定義
スコープ定義 WBS 成果物を遂行するためのタスクを定義
スコープ検収 検証（検収）後成果物 成果物の検証（検収）
スコープ変更管理 変更後スコープ 成果物とタスクの見直し（変更）
表1 PMBOKでのスコープマネジメント（概要）
つまり、スコープマネジメントとは、
プロジェクトの目標を達成するために必要な成果物とタスクを定義する
プロジェクト期間を通じて、必要に応じてその定義を見直していく
必要な成果物とタスクが完成されていることを保証する
ということである。
次に、冒頭で述べた「スコープマネジメントがプロジェクトの成功／失敗に大きく影響を及ぼす」ということに簡単に触れておく。
■スコープマネジメントがプロジェクトの成否を分ける
プロジェクトが成功裡に終了するのは全体の約20～30％、厳しい見方をする人によると1000に3つともいわれる。いかに多くのプロジェクトが失敗に終わっているか、お分かりいただけるだろう。こうした中でプロジェクトの失敗は、スコープマネジメントのまずさによる場合が多いといわれている。なぜだろうか。
このことを考えるに当たり、まず「プロジェクトの成功」について整理しておく必要がある。
プロジェクトの成功とは、しばしば当初定められた「期間どおりに」「予算どおりに」「品質を満たすこと」といわれるが、果たして、これらを満たせばプロジェクトは成功なのだろうか？
当初定められた品質は満たしたが、結果としてユーザーに使ってもらえなかった。または、プロジェクトメンバーが長期間にわたり過酷な労働に陥り、健康を害するメンバーが続出するといったプロジェクトは成功といえるのだろうか？
筆者は、本質的にプロジェクトの成功とは、
「プロジェクトにかかわるすべての利害関係者に満足する結果をもたらすこと」
であると考えている。ここで利害関係者とは、顧客サイドの経営層、スポンサー、発注者、ユーザーなどに加え、受注サイドの営業部門、開発部門、協力会社などの人々を指す。
すべての利害関係者に満足する結果をもたらすためには、「プロジェクト実施前に各関係者が期待するもの」と「プロジェクト実施後に各関係者が得るもの」を一致させなければならない。しかし、両者を一致させることは難しい。「期待」は常に変化するし、「得るもの」は思いどおりに提供できるわけではない。これを実現するためには、「何を」「どこまでやるか」を具体的に決め、実行し、常に見直していくしかない。すなわち、プロジェクトの目的と目標を明確にし、必要な成果物・作業を明確にし、実行計画を策定し確実に遂行するしかないのである。これは先に説明したスコープマネジメントそのものであることがお分かりいただけるだろうか。文字どおり、スコープマネジメントはプロジェクトの成功へ直結するのである。
それでは、スコープマネジメントを「スコープを決める」「決めたスコープをコントロールする」という2つの観点から、実践的な勘所ケーススタディを通じて紹介していくことにしよう。
■スコープの決定にはプロジェクト関係者全員の合意と理解が不可欠
あなたの部署に2つのシステム開発案件が舞い込んできた。どちらの案件も、営業サイドとしては何としても受注したかったため、予算も納期もかなり無理をして取ってきたようである。
あなたの部署の「矢見雲マネージャ」と「出来杉マネージャ」がそれぞれの案件を担当することになり、プロジェクトがスタートした。あなたは、どちらかのプロジェクトに配属されることになり、2人のマネージャからそれぞれのプロジェクトの説明を聞くことにした。
矢見雲マネージャの発言
「私も提案書については、正直、現実的ではないと感じている。提案時にもそういった。しかし、会社の上層部からも受注しないといけない重要なプロジェクトということで念を押されているので、腹をくくって何とかしてやるしかないと思っている」
「ただ、顧客と実現すべき機能や仕様については大枠合意が取れているので、そこは救いだな」
「さっきも話したけど、このプロジェクトはわが社としても非常に重要な案件なので、ぜひ君に力を貸してほしい」
「じゃあ、よろしく頼むよ」
出来杉マネージャの発言
「私も提案書については、正直現実的ではないと感じたので、まず営業サイドに提案書の見積もりの根拠を確認した」
「すると、受注のために明確な根拠なく見積もりを作成していたことが判明したので、急きょ、プロジェクト計画を作り直すことにした」
「まず顧客の要望に使用頻度と重要度が低いと考えられる要望が多く盛り込まれていたので、顧客の要望を再確認した」
「営業サイドからは機能・仕様は、顧客と大枠合意されていると聞いていたが、実はこの顧客、ユーザー部門とは別部署のメンバーで、ユーザー部門に確認する必要があることが判明した」
「再度、ユーザー部門を交えて要望を整理したところ、当初の3割程度が不要な機能であることが判明した」
「それでも再見積もりの結果、当初見積もりの2割増になったが、顧客と営業サイドと上層部に見積もりの根拠を説明するとともに、元の予定でいくと結果的に納期遅延や予算オーバー、そしてプロジェクトが混乱に陥り、成果物の品質も落ちて顧客満足が得られないこことが危惧（きぐ）されることを指摘して納得してもらった」
「正直、これでも楽な計画ではないが、われわれはこの計画に自信を持っている。そしてこの計画の達成には君の力が必要だ。ぜひ、このプロジェクトを一緒に成功に導こうではないか」
先に触れたように、プロジェクトの成功とはプロジェクトにかかわるすべての利害関係者に満足をもたらすことである。プロジェクトの利害関係者とは、顧客サイドにおいても、経営層、スポンサー、発注者、ユーザー、そのほか関係部署と多岐にわたる。また受注サイドにおいても、営業部門、開発部門、場合によっては経営層などが関係する。
これら関係者は、それぞれ立場が異なるので利害を異とすることが一般的である。利害を異とする関係者の満足を達成するには、まず「何をいつまでにいくらで達成すれば満足するか」というプロジェクトの基本事項について、関係者全員の合意と理解を得ずして成し遂げられないことはご理解いただけるであろう。
重要なことは、一部の関係者ではなく「関係者全員」の合意と理解である。
先の矢見雲マネージャの例では、見積もりについて顧客サイドの発注者と受注サイドの営業部門、経営層は合意しているが、開発部門と合意されているとはいえない。また、機能・仕様については、顧客サイドの発注者と受注サイドの営業部門は合意しているが、顧客サイドのユーザーは合意していない。
ここで挙げたケースは、PMBOKでいうところの「プロジェクトの立ち上げ」においてプロジェクトの基本事項を定義する段階の話しであるが、ちまたにあふれる失敗プロジェクトには、プロジェクトの開始時点ですでにこのような全員の合意が得られていないプロジェクトが多いように考えられる。
あなたの周りのプロジェクトではこのようなことが起こっていないだろうか……。
実際にすべての利害関係者の合意と理解を得ることは容易ではないが、読者がもしこれまでこのことを意識していなかったとすれば、まず第一歩として、プロジェクトの利害関係者をすべて洗い出し整理しておくことをお勧めする。話を通すべき相手が分かっているだけでも結果は大きく変わってくるといえよう。
また今回の例では、プロジェクトの初期段階を取り上げたが、関係者全員の合意と理解を得ることは、プロジェクト期間を通じて行わなければならないことを付記しておく。
■スコープを可視化する
先に紹介したプロジェクトはその後数カ月がたち、現在はユーザーによるテストフェイズを迎えている。ところが、この段階でユーザーから数多くの追加要求の声が上がってきた。システムの稼働まではもう1カ月しかない。このような状況における2人のマネージャと顧客側担当者とのやりとりを見てみることにしよう。
矢見雲マネージャの発言
矢見雲：「今回ご指摘いただいたご要望は前フェイズまでにご確認いただいた要件にはありませんでした。これからの追加となるとスケジュール的にも予算的にも厳しいのが正直なところです」
顧客：「困ったなあ。当然盛り込まれているものと思っていたのにどうして入ってないの？」
矢見雲：「われわれとしては要件として明確に確認させていただいたことについて対応させせていただいています。しかし、今回の場合、そういう要件があるということは認識しておりませんでした」
顧客：「そんなのいわなくたって分かっているだろう。いずれにしても、今回の要件は絶対必要なんだよ」
矢見雲：「分かりました。対応方法を検討させてください」
出来杉マネージャの発言
出来杉：「今回ご指摘いただいたご要望は、今回のシステムで実現する機能を網羅的に整理した『機能要件一覧』には含まれていませんでした。これからの追加となるとスケジュール的にも予算的にも厳しいのが正直なところです」
顧客：「そうだったか。ちゃんと確認したつもりだったが漏れていたようだね。でも、いずれにせよ必要な機能なので何とか対応しなくてはならないんだ。何とかならないものか」
出来杉：「分かりました。対応方法を検討させてください」
ポイントは、スコープを「可視化」することにある。矢見雲マネージャの例の問題点は、要件定義の段階で、顧客と双方でスコープ（要件）を確認できる共通の成果物がないことだ。顧客側は要件として当然含まれていると認識しているが、開発側は要件として明確になっていないために、当然スコープには含まれていないと考える。ここで認識のズレが生じていたのである。
出来杉マネージャの例では、「機能要件一覧」を使って、双方でスコープを確認している。例えばスカイライトコンサルティングでは、対象とする「業務」または「システム機能」を階層的に整理し、一覧表の形式にしている。「機能要件一覧」によって顧客側、開発側双方が網羅的にスコープを確認できるため、「抜け漏れを防ぐ」点と「万一、抜け漏れがあった場合の責任の所在が明らかになる」という点で大きな効果がある。
要件の優先順位付けは、個別に見れば全部重要となってしまう
次に、上の例の続きで、実際によく見られるスコープコントロールのケースを紹介しよう。
矢見雲マネージャの発言
矢見雲：「今回ご指摘いただいた要件は3件あります。これら全部に稼働までに対応することは正直困難ですので、優先順位を付けて重要度の高いものから対応していき、そうでないものは稼働以降に対応させていただきたいと考えております」
顧客：「致し方ないな。それでお願いすることにしよう」
矢見雲：「ありがとうございます。では、早速それぞれの要件の検討を進めていきましょう。まず1番の要件ですが……」
顧客：「それは必須だな。それがないと業務が回らない」
矢見雲：「では2番の要件ですが……」
顧客：「それも重要だな。それがないとユーザーの負荷が著しく増加する」
矢見雲：「では3番の要件ですが……」
顧客：「それは当然必要。ないと取引先にも影響を与える。結局、全部必要なんだよ」
矢見雲：「いったん持ち帰らせてもらって開発側でなんとか押し込めないか検討してみます。返事は社に戻って検討した後、ご連絡します」
出来杉マネージャの発言
出来杉：「今回ご指摘いただいた要件は3件あります。これら全部に稼働までに対応することは正直困難ですので、優先順位を付けて重要度の高いものから対応していき、そうでないものは稼働以降に対応させていただきたいと考えております」
顧客：「致し方ないな。それでお願いすることにしよう」
出来杉：「ありがとうございます。では、早速どういう基準で優先順位を付けるかということを検討させてください。まず、取引先など対外的に影響を与えるものは、やはり最優先かと考えていますがいかがですか？」
顧客：「そうだな。外に迷惑をかけることはできないな」
出来杉：「では、これを『重要度：高』としましょう。次にユーザーに与える影響ですが、これは、その要件により影響を受けるユーザー数と業務量に応じて影響の大きさは変わってくると思うので、影響の大きいものは『重要度：中』、そうでないものは『重要度：低』ということでいかがですか」
顧客：「分かった。それでいこう」
出来杉：「そうすると3つの要件はどうなりますか？」
顧客：「3番は『重要度：高』だな。あとの2つは『重要度：低』ということになるな」
出来杉：「分かりました。では、3番だけであれば何とかできる可能性はあるので、スケジュールを検討してみます。あとの2つは稼動後できるだけ早い時期に対応するということで、いつ対応するか別途検討しましょう」
顧客：「そうしよう」
出来杉：「それと対応する方向の3番については、仕様変更手順に基づき、ステアリングコミッティ（プロジェクト運営委員会）での承認が必要になります。仕様変更依頼書を作成しますので必要事項に記入をお願いします」
顧客：「分かった。ありがとう。よろしく頼むよ」
このケースで重要なポイントは、追加要件に対応することが難しい場合によく行われている「優先順位を付けて対応を考える」ことにある。矢見雲マネージャの例では、個別の要件ごとに判断しているが、このような場合、各要件に必要とされる理由や背景に基づいて判断することになる。しかし、これだとどうしてもあれも重要、これも重要となってしまう、あるいは顧客とこちらで重要度が一致しないということに陥りがちではないだろうか。
重要なのは、どういう基準で優先順位を付けるかについて合意することである。顧客と開発側の双方が容易に判断できるプロジェクト全体を通しての判断基準をておくことにより、お互いに納得のいく意思決定が迅速にできる。
■今回のまとめ
・スコープマネジメントとは、プロジェクトの目標を達成するために必要な成果物とタスクを、プロジェクト期間を通じて定義していき、その内容をやり遂げることを保証すること。
・スコープマネジメントは、プロジェクトの成功／失敗に大きく影響を及ぼすこと。
・スコープを決定する際は、プロジェクトの関係者が誰であるかをしっかり押さえて、関係者「全員」の合意を得ること。
・定義したスコープは、顧客／開発側双方で確認できるよう「可視化」しておき合意を得ること。
・スコープの変更を検討する際に、要件の優先順位を検討する場合は、優先順位付けの判断基準を明確にすること。
第1回 プロジェクトメンバーを1つにまとめる
http://jibun.atmarkit.co.jp/lskill01/rensai/pm01/pm01.html
第1回 プロジェクトメンバーを1つにまとめる
杦岡充宏（スカイライトコンサルティング）
2004/2/4
エンジニアとしてキャリアアップを考える際、ぜひ身に付けておきたいのがプロジェクトマネジメント（PM）のスキルだ。特に近年のシステム開発プロジェクトは低予算化・短期化が進んでおり、ただでさえ計画どおりにプロジェクトを運営することは困難になっている。こうした中、多くの現場で「経験のあるプロジェクトマネージャが不足している」という声を聞く。
しかし、PMスキルを実際に習得するとなると、これがなかなか難しい。ちまたにはPMBOK（Project Management Body Of Knowledge）をはじめとするPM関連の本があふれ、体系的に学習できる素材はそろってきた。しかし、実践的なものは少なく、理論と現場のギャップに戸惑うことも多々あろう。
そこで、この連載では実際の現場でよく見られるシチュエーションを取り上げながら、PMの実践的な勘所をケーススタディ形式で紹介していく。これからプロジェクトマネージャを目指す方はもちろん、すでにプロジェクトマネージャとして活躍されている方にも、「知識」としてではなく現場で使える「スキル」を磨くうえで役立てていただければ幸いである。
■プロジェクトマネージャとは
プロジェクトマネージャとは、何をする人だろうか。あなたの身近にいるプロジェクトマネージャを、ちょっと想像してみてほしい。
一般に「プロジェクト」とは、何らかの目的の達成を目指して、一定期間に行われる活動のことをいう。目的の大小や期間の長短は関係ない。会計システムの導入も、Webページの制作も、プロジェクトという意味では同じである。仕事に限らず、受験や就職、結婚や出産といった人生のイベントすべてがプロジェクトであるという人もいる。そういう意味では、あなたはすでに何らかのプロジェクトを手掛けた経験を持っているはずだ。あなたの身近にいるプロジェクトマネージャは、あなたよりほんの少し複雑で、ほんの少しリスクの高いプロジェクトを手掛けているにすぎない。
では、その人は普段どんな仕事をしているだろうか。プロジェクトの進ちょくの管理、顧客やユーザーとの折衝、人件費や費用の管理、要員の確保と配置、関係者への報告……。数え上げればきりがないほど、種々雑多な仕事が思い浮かんでくるに違いない。
しかし、プロジェクトマネージャの仕事は、本質的にはたった1つだ。それは、
プロジェクトを成功という1つのゴールに向かって導く
ということだ。
プロジェクトには目的があり、期限があるという点で、決まった作業を繰り返す「ルーチンワーク」とは異なる。中には、期間が数年にわたるような長期のプロジェクトもあるだろう。そういったプロジェクトの中にいると、ルーチンワークをこなしているような感覚に陥ってしまうことがあるかもしれない。しかし、あなたの気付かない間にも、プロジェクトの状況は刻々と変化している。期限に向かって、1日1日が費やされているのである。こうした中で、プロジェクトマネージャはプロジェクトを成功に導くために、「必要なことすべて」を行うのである。
しかし、「必要なことすべて」を思いつくまま漫然とやっていては、労力も無駄だし、抜けや漏れが生じる。「必要なこと」をやらなかったばかりに、後になって「本来やらなくてもよかったこと」までやる羽目になってしまうこともある。そこで本稿では、プロジェクトマネージャがプロジェクトを成功に導くためにやるべき「必要なこと」に焦点を当て、ケーススタディ方式で紹介していくことにしよう。
■メンバーの動機付け
今回は、プロジェクトを1つにまとめるコミュニケーションの勘所を紹介しよう。
例えば、あなたがあるプロジェクトに参画することになったとしよう。その初日に、マネージャからプロジェクトのオリエンテーションがあるということで、あなたは打ち合わせに出席することになった。さて、ここでタイプの異なる2人のマネージャが登場する。
矢見雲マネージャの発言
「今日は朝から忙しくて、ミーティングの予定でびっしり埋まってるんだよ」
「時間が取れないから、今日はプロジェクトに関するこの資料を読んでおいて」
「何か分からないことがあったら、後で質問するように」
「細かいことは、実際の作業をこなしながらキャッチアップしてくれよ」
「じゃあ、後はよろしく」
出来杉マネージャの発言
「今日は朝から忙しくて、ミーティングの予定でびっしり埋まってるんだよ」
「このミーティングには15分しか取れないから、要点を押さえて簡潔に進めよう」
「事前に渡しておいた資料は読んでもらったかな？ 質問もまとめてきたね？」
「資料からだけでは読み取れない部分もあったと思うので、私から補足して説明しよう」
「まず、このプロジェクトの目的とその意義は……」
「次に、このプロジェクトのスケジュールと主なマイルストーンは……」
「次に、このプロジェクトのチャレンジ（克服すべき困難）は……」
「最後に、このプロジェクトの体制とあなたに期待する役割は…」
「では、残りの時間で、まとめてもらってきた質問のうち、いまの説明で不明な点があれば質問してほしい。じゃあ、始めようか」
さて、あなたは矢見雲マネージャのプロジェクトと、出来杉マネージャのプロジェクト、どちらに参加したいだろうか。
いきなりプロジェクトに投げ込まれ、右も左も分からないような状態に陥ることを望む人はいないだろう。やる気が起きるわけがない。プロジェクトにメンバーを新規で配属する際には、できるだけ明確にプロジェクトの重要事項、すなわち目的と期限、リスクと期待役割について説明しておくべきだ。
重要なのは、この動機づけをプロジェクト全体で一貫した形で行い、使命感を共有することだ。こうすることによって、細かい指示を与えなくても各自が状況に応じて適切に判断を下せるようになる。大きなプロジェクトであれば、新人向けの説明資料をひとまとめにしておくとよいだろう。プロジェクト開始時の企画書や提案書、計画書などを抜粋して、バインダーに綴じるなり、ファイルサーバの所定の場所に置くだけでよい。これだけの作業と、ちょっとした配慮だけで、新規にプロジェクトに参加するメンバーの不安を解消し、同じ方向に気持ちを向けさせることができる。
プロジェクトによっては、最初からスコープが流動的だったり、スケジュールが確定していなかったりすることがある。筆者の経験上、そのような場合は包み隠さず情報を公開した方がよい結果を生むことが多い。「ここまでは決まっているが、ここから先は決まっていない。最悪の場合、こういう事態に発展するケースが考えられる」というように、メンバーとリスクを共有して初めて、プロジェクトに一体感が生まれるのではないだろうか。
ちなみに、スカイライトコンサルティングでは、プロジェクトマネージャは新規のメンバーに対してプロジェクトの内容を説明することが義務付けられている。説明すべき事項が記載されたチェックリストは社員にも開示されているので、詳細に知りたいと思ったら、進んで説明を求めることができるようになっている。
■チームを形成する
さて、オリエンテーションも終わり、あなたはいよいよプロジェクトメンバーとして作業を開始したとしよう。しかし、これまでの経験とは異なり、プロジェクトの進め方やコミュニケーションなど、勝手が違うことに戸惑いを覚えてしまった。周りのメンバーも同じように感じているようだ。そこで、あなたはマネージャに相談することにした。
矢見雲マネージャの発言
「はじめは、多少そういうこともあるだろう」
「慣れれば大丈夫だと思うから、もう少し様子を見て」
「問題があれば、また相談してくれよ」
「じゃあ、後はよろしく」
出来杉マネージャの発言
「プロジェクトの出だしで顧客とのミーティングが重なりバタバタしてしまった。申し訳ない」
「チームとして作業を進めていくに当たって、キックオフミーティングを開催しよう」
「そこで作業の進め方やコミュニケーションについての案を私から説明するので、みんなからも意見があればそこで出してもらって、このプロジェクトのやり方を決めよう」
「それから、新メンバーも加わったことだし、歓迎会をやろう。どんなところでやりたいか、皆考えておいてくれよ」
いくら優秀なメンバーが入り、適切に動機付けされたといっても、日々の具体的な作業がどのように進められていくかが決まっていなければ、足並みはそろわない。結果としてチームのパフォーマンスを引き出すことはできない。
プロジェクトマネージャは、個人の持っているパフォーマンスを、チームとして最大限に引き出すことができるよう、「円滑に連携」させる仕掛けをつくる必要がある。それが、「キックオフミーティング」に代表される、チームビルディングのためのイベントである。
キックオフミーティングでは、前項で取り上げたプロジェクトの重要事項の説明をさらに詳しく行うとともに、次のようなトピックについて説明しよう。
体制
コミュニケーションフロー（レポートラインやメール・掲示板による連絡ルールなど）
作業の進め方、進ちょく管理の方法
各種会議体とその位置付け、出席者
これによって日々の作業をどう進めていくか、ほかのメンバーとどのように協調すべきなのかが明確になる。特に会議体については、顧客や協力会社など、外部メンバーとの重要な接点であると同時に、何らかの意思決定の場でもあり、大変重要です。プロジェクト計画時にきちんと定義しておくべきであることはいうまでもないが、運営面で形骸化してしまわないよう、キックオフミーティングの場などでその位置付けを再確認し、メンバーの理解を高めておく必要がある。
さらに、出来杉マネージャが最後に「歓迎会」の開催を提案していたように、プロジェクトマネージャは次のような点にも配慮すべきだろう。
メンバー間のコミュニケーション促進
一体感の醸成
一見、仕事には直接関係ないことのようにも思えるが、プロジェクトの初期段階でメンバー同士がお互いに打ち解けた関係になっておくことは、非常に重要だ。欧米では、プロジェクトに限らずセミナーやワークショップなどでも「アイスブレーキング」といって簡単なゲームをやってリラックスした雰囲気を短時間で作ってしまうことが多い。日本では酒席をもうけることが一般的だが、やり方に関係なく共通しているのは、「お互いを知り仲よくなる」ことではないだろうか。それによって相手を気遣い、円満にコミュニケーションをしていく素地が出来上がる。
最後にもう一点、メンバーとのコミュニケーションは双方向でなければならない。プロジェクトマネージャは、自分のやり方を一方的に押し付けるのではなく、メンバーから意見を吸い上げる姿勢を持つことが大事である。これは、何もメンバーの意見すべてを尊重しろといっているのではなく、「現場に問題が生じたときに、速やかに情報を吸い上げる」環境をつくることが大事だということだ。
よく、食事時などにプロジェクトや上司の陰口をたたくような光景が見らることがあるが、これはあまり褒められたことではない。そういう場合は、得てしてプロジェクト内のコミュニケーションがうまくいっていない。メンバーが現場の問題や不満を抱え込まずに、素直に相談できる環境をつくることによって、初めてプロジェクトのリスクをコントロールできるようになるといえる。
■プロジェクトの阻害要因を適切にコントロールする
あなたがプロジェクトについてから1カ月が経過した。プロジェクトにも慣れ、忙しい日が続いている。しかし、作業を進めるにつれ、チーム内では仕様に関する課題が目立ってきて、遅れが出てきた。そんなある日のチームミーティングで……。
矢見雲マネージャの発言
「スケジュールが遅れているとはどういうことなんだ！！」
「みんなスケジュールは分かっているだろ！」
「深夜残業しても、土日を使ってでも、来週までにはなんとかキャッチアップしておくように」
「じゃあ、後はよろしく」
出来杉マネージャの発言
「当初のスケジュールに対して遅れが出ているようだが、原因は何だろう？」
「いろんな原因があるようだな。仕様が不明確で、顧客に対してその確認に時間を要しているメンバーが体調を崩して3日間休んだ。ユーザーから新たな要望が出ている……、などだ」
「遅れとなっている課題をクリアして、どうすればばん回可能か、担当者と一緒に考えてみよう」
実際にプロジェクトが進んでいくと、目的を達成するまでの道のりは決して平たんではなく、さまざまな阻害要因が発生する。プロジェクトマネージャは、これらの阻害要因を取り除きゴールへ導くことが求められる。これらの阻害要因は、PMBOKの定義に合わせると、以下の要素（エリア）に分類される。
スコープ
時間（スケジュール）
コスト
品質
組織
コミュニケーション
リスク
調達（人・モノ）
統合（上記すべての統合、という意味）
伝統的な日本のPMは、3K（経験・根性・気合）とかKKD（経験・根性・度胸）などといわれてきたが、今日ではPMBOKを中心とする体系的なPMのあり方が整理されている。
次回以降は、これらの各エリアに対して、実際のプロジェクトに見られるシチュエーションとPMBOKなどが書かれているPM上のテクニックを織り交ぜながら解説していきたいと思う。
■今回のまとめ
・プロジェクトマネージャの本質的な役割とは、「プロジェクトを成功という1つのゴールに向かって導く」こと。
・メンバーがプロジェクトに参画した際には、プロジェクトの重要事項を明確に伝え、適切に動機付けをさせなければならない。
・チームとしてのパフォーマンスを最大化するために、チームメンバーが円滑に連携できるよう配慮する。良好な人間関係を形成することも重要。
・プロジェクトの阻害要因を適切にコントロールする。
筆者プロフィール
杦岡充宏（すぎおかみつひろ）
スカイライトコンサルティング(www.skylight.co.jp) シニアマネジャー。米国PMI認定PMP。関西学院大学商学部卒業後、アンダーセンコンサルティング（現アクセンチュア）を経て現職。製造業や流通業のCRM領域において、業務改革やシステム構築のPM（プロジェクトマネジメント）の実績多数。特に大規模かつ複雑な案件を得意とする。外部からの依頼に基づき、プロジェクトの困難な状況の立て直しにも従事、PMの重要性を痛感。現在は、同社においてPMの活動そのものをコンサルティングの対象とするサービスを展開している。
第1回 プロジェクトメンバーを1つにまとめる
杦岡充宏（スカイライトコンサルティング）
2004/2/4
エンジニアとしてキャリアアップを考える際、ぜひ身に付けておきたいのがプロジェクトマネジメント（PM）のスキルだ。特に近年のシステム開発プロジェクトは低予算化・短期化が進んでおり、ただでさえ計画どおりにプロジェクトを運営することは困難になっている。こうした中、多くの現場で「経験のあるプロジェクトマネージャが不足している」という声を聞く。
しかし、PMスキルを実際に習得するとなると、これがなかなか難しい。ちまたにはPMBOK（Project Management Body Of Knowledge）をはじめとするPM関連の本があふれ、体系的に学習できる素材はそろってきた。しかし、実践的なものは少なく、理論と現場のギャップに戸惑うことも多々あろう。
そこで、この連載では実際の現場でよく見られるシチュエーションを取り上げながら、PMの実践的な勘所をケーススタディ形式で紹介していく。これからプロジェクトマネージャを目指す方はもちろん、すでにプロジェクトマネージャとして活躍されている方にも、「知識」としてではなく現場で使える「スキル」を磨くうえで役立てていただければ幸いである。
■プロジェクトマネージャとは
プロジェクトマネージャとは、何をする人だろうか。あなたの身近にいるプロジェクトマネージャを、ちょっと想像してみてほしい。
一般に「プロジェクト」とは、何らかの目的の達成を目指して、一定期間に行われる活動のことをいう。目的の大小や期間の長短は関係ない。会計システムの導入も、Webページの制作も、プロジェクトという意味では同じである。仕事に限らず、受験や就職、結婚や出産といった人生のイベントすべてがプロジェクトであるという人もいる。そういう意味では、あなたはすでに何らかのプロジェクトを手掛けた経験を持っているはずだ。あなたの身近にいるプロジェクトマネージャは、あなたよりほんの少し複雑で、ほんの少しリスクの高いプロジェクトを手掛けているにすぎない。
では、その人は普段どんな仕事をしているだろうか。プロジェクトの進ちょくの管理、顧客やユーザーとの折衝、人件費や費用の管理、要員の確保と配置、関係者への報告……。数え上げればきりがないほど、種々雑多な仕事が思い浮かんでくるに違いない。
しかし、プロジェクトマネージャの仕事は、本質的にはたった1つだ。それは、
プロジェクトを成功という1つのゴールに向かって導く
ということだ。
プロジェクトには目的があり、期限があるという点で、決まった作業を繰り返す「ルーチンワーク」とは異なる。中には、期間が数年にわたるような長期のプロジェクトもあるだろう。そういったプロジェクトの中にいると、ルーチンワークをこなしているような感覚に陥ってしまうことがあるかもしれない。しかし、あなたの気付かない間にも、プロジェクトの状況は刻々と変化している。期限に向かって、1日1日が費やされているのである。こうした中で、プロジェクトマネージャはプロジェクトを成功に導くために、「必要なことすべて」を行うのである。
しかし、「必要なことすべて」を思いつくまま漫然とやっていては、労力も無駄だし、抜けや漏れが生じる。「必要なこと」をやらなかったばかりに、後になって「本来やらなくてもよかったこと」までやる羽目になってしまうこともある。そこで本稿では、プロジェクトマネージャがプロジェクトを成功に導くためにやるべき「必要なこと」に焦点を当て、ケーススタディ方式で紹介していくことにしよう。
■メンバーの動機付け
今回は、プロジェクトを1つにまとめるコミュニケーションの勘所を紹介しよう。
例えば、あなたがあるプロジェクトに参画することになったとしよう。その初日に、マネージャからプロジェクトのオリエンテーションがあるということで、あなたは打ち合わせに出席することになった。さて、ここでタイプの異なる2人のマネージャが登場する。
矢見雲マネージャの発言
「今日は朝から忙しくて、ミーティングの予定でびっしり埋まってるんだよ」
「時間が取れないから、今日はプロジェクトに関するこの資料を読んでおいて」
「何か分からないことがあったら、後で質問するように」
「細かいことは、実際の作業をこなしながらキャッチアップしてくれよ」
「じゃあ、後はよろしく」
出来杉マネージャの発言
「今日は朝から忙しくて、ミーティングの予定でびっしり埋まってるんだよ」
「このミーティングには15分しか取れないから、要点を押さえて簡潔に進めよう」
「事前に渡しておいた資料は読んでもらったかな？ 質問もまとめてきたね？」
「資料からだけでは読み取れない部分もあったと思うので、私から補足して説明しよう」
「まず、このプロジェクトの目的とその意義は……」
「次に、このプロジェクトのスケジュールと主なマイルストーンは……」
「次に、このプロジェクトのチャレンジ（克服すべき困難）は……」
「最後に、このプロジェクトの体制とあなたに期待する役割は…」
「では、残りの時間で、まとめてもらってきた質問のうち、いまの説明で不明な点があれば質問してほしい。じゃあ、始めようか」
さて、あなたは矢見雲マネージャのプロジェクトと、出来杉マネージャのプロジェクト、どちらに参加したいだろうか。
いきなりプロジェクトに投げ込まれ、右も左も分からないような状態に陥ることを望む人はいないだろう。やる気が起きるわけがない。プロジェクトにメンバーを新規で配属する際には、できるだけ明確にプロジェクトの重要事項、すなわち目的と期限、リスクと期待役割について説明しておくべきだ。
重要なのは、この動機づけをプロジェクト全体で一貫した形で行い、使命感を共有することだ。こうすることによって、細かい指示を与えなくても各自が状況に応じて適切に判断を下せるようになる。大きなプロジェクトであれば、新人向けの説明資料をひとまとめにしておくとよいだろう。プロジェクト開始時の企画書や提案書、計画書などを抜粋して、バインダーに綴じるなり、ファイルサーバの所定の場所に置くだけでよい。これだけの作業と、ちょっとした配慮だけで、新規にプロジェクトに参加するメンバーの不安を解消し、同じ方向に気持ちを向けさせることができる。
プロジェクトによっては、最初からスコープが流動的だったり、スケジュールが確定していなかったりすることがある。筆者の経験上、そのような場合は包み隠さず情報を公開した方がよい結果を生むことが多い。「ここまでは決まっているが、ここから先は決まっていない。最悪の場合、こういう事態に発展するケースが考えられる」というように、メンバーとリスクを共有して初めて、プロジェクトに一体感が生まれるのではないだろうか。
ちなみに、スカイライトコンサルティングでは、プロジェクトマネージャは新規のメンバーに対してプロジェクトの内容を説明することが義務付けられている。説明すべき事項が記載されたチェックリストは社員にも開示されているので、詳細に知りたいと思ったら、進んで説明を求めることができるようになっている。
■チームを形成する
さて、オリエンテーションも終わり、あなたはいよいよプロジェクトメンバーとして作業を開始したとしよう。しかし、これまでの経験とは異なり、プロジェクトの進め方やコミュニケーションなど、勝手が違うことに戸惑いを覚えてしまった。周りのメンバーも同じように感じているようだ。そこで、あなたはマネージャに相談することにした。
矢見雲マネージャの発言
「はじめは、多少そういうこともあるだろう」
「慣れれば大丈夫だと思うから、もう少し様子を見て」
「問題があれば、また相談してくれよ」
「じゃあ、後はよろしく」
出来杉マネージャの発言
「プロジェクトの出だしで顧客とのミーティングが重なりバタバタしてしまった。申し訳ない」
「チームとして作業を進めていくに当たって、キックオフミーティングを開催しよう」
「そこで作業の進め方やコミュニケーションについての案を私から説明するので、みんなからも意見があればそこで出してもらって、このプロジェクトのやり方を決めよう」
「それから、新メンバーも加わったことだし、歓迎会をやろう。どんなところでやりたいか、皆考えておいてくれよ」
いくら優秀なメンバーが入り、適切に動機付けされたといっても、日々の具体的な作業がどのように進められていくかが決まっていなければ、足並みはそろわない。結果としてチームのパフォーマンスを引き出すことはできない。
プロジェクトマネージャは、個人の持っているパフォーマンスを、チームとして最大限に引き出すことができるよう、「円滑に連携」させる仕掛けをつくる必要がある。それが、「キックオフミーティング」に代表される、チームビルディングのためのイベントである。
キックオフミーティングでは、前項で取り上げたプロジェクトの重要事項の説明をさらに詳しく行うとともに、次のようなトピックについて説明しよう。
体制
コミュニケーションフロー（レポートラインやメール・掲示板による連絡ルールなど）
作業の進め方、進ちょく管理の方法
各種会議体とその位置付け、出席者
これによって日々の作業をどう進めていくか、ほかのメンバーとどのように協調すべきなのかが明確になる。特に会議体については、顧客や協力会社など、外部メンバーとの重要な接点であると同時に、何らかの意思決定の場でもあり、大変重要です。プロジェクト計画時にきちんと定義しておくべきであることはいうまでもないが、運営面で形骸化してしまわないよう、キックオフミーティングの場などでその位置付けを再確認し、メンバーの理解を高めておく必要がある。
さらに、出来杉マネージャが最後に「歓迎会」の開催を提案していたように、プロジェクトマネージャは次のような点にも配慮すべきだろう。
メンバー間のコミュニケーション促進
一体感の醸成
一見、仕事には直接関係ないことのようにも思えるが、プロジェクトの初期段階でメンバー同士がお互いに打ち解けた関係になっておくことは、非常に重要だ。欧米では、プロジェクトに限らずセミナーやワークショップなどでも「アイスブレーキング」といって簡単なゲームをやってリラックスした雰囲気を短時間で作ってしまうことが多い。日本では酒席をもうけることが一般的だが、やり方に関係なく共通しているのは、「お互いを知り仲よくなる」ことではないだろうか。それによって相手を気遣い、円満にコミュニケーションをしていく素地が出来上がる。
最後にもう一点、メンバーとのコミュニケーションは双方向でなければならない。プロジェクトマネージャは、自分のやり方を一方的に押し付けるのではなく、メンバーから意見を吸い上げる姿勢を持つことが大事である。これは、何もメンバーの意見すべてを尊重しろといっているのではなく、「現場に問題が生じたときに、速やかに情報を吸い上げる」環境をつくることが大事だということだ。
よく、食事時などにプロジェクトや上司の陰口をたたくような光景が見らることがあるが、これはあまり褒められたことではない。そういう場合は、得てしてプロジェクト内のコミュニケーションがうまくいっていない。メンバーが現場の問題や不満を抱え込まずに、素直に相談できる環境をつくることによって、初めてプロジェクトのリスクをコントロールできるようになるといえる。
■プロジェクトの阻害要因を適切にコントロールする
あなたがプロジェクトについてから1カ月が経過した。プロジェクトにも慣れ、忙しい日が続いている。しかし、作業を進めるにつれ、チーム内では仕様に関する課題が目立ってきて、遅れが出てきた。そんなある日のチームミーティングで……。
矢見雲マネージャの発言
「スケジュールが遅れているとはどういうことなんだ！！」
「みんなスケジュールは分かっているだろ！」
「深夜残業しても、土日を使ってでも、来週までにはなんとかキャッチアップしておくように」
「じゃあ、後はよろしく」
出来杉マネージャの発言
「当初のスケジュールに対して遅れが出ているようだが、原因は何だろう？」
「いろんな原因があるようだな。仕様が不明確で、顧客に対してその確認に時間を要しているメンバーが体調を崩して3日間休んだ。ユーザーから新たな要望が出ている……、などだ」
「遅れとなっている課題をクリアして、どうすればばん回可能か、担当者と一緒に考えてみよう」
実際にプロジェクトが進んでいくと、目的を達成するまでの道のりは決して平たんではなく、さまざまな阻害要因が発生する。プロジェクトマネージャは、これらの阻害要因を取り除きゴールへ導くことが求められる。これらの阻害要因は、PMBOKの定義に合わせると、以下の要素（エリア）に分類される。
スコープ
時間（スケジュール）
コスト
品質
組織
コミュニケーション
リスク
調達（人・モノ）
統合（上記すべての統合、という意味）
伝統的な日本のPMは、3K（経験・根性・気合）とかKKD（経験・根性・度胸）などといわれてきたが、今日ではPMBOKを中心とする体系的なPMのあり方が整理されている。
次回以降は、これらの各エリアに対して、実際のプロジェクトに見られるシチュエーションとPMBOKなどが書かれているPM上のテクニックを織り交ぜながら解説していきたいと思う。
■今回のまとめ
・プロジェクトマネージャの本質的な役割とは、「プロジェクトを成功という1つのゴールに向かって導く」こと。
・メンバーがプロジェクトに参画した際には、プロジェクトの重要事項を明確に伝え、適切に動機付けをさせなければならない。
・チームとしてのパフォーマンスを最大化するために、チームメンバーが円滑に連携できるよう配慮する。良好な人間関係を形成することも重要。
・プロジェクトの阻害要因を適切にコントロールする。
筆者プロフィール
杦岡充宏（すぎおかみつひろ）
スカイライトコンサルティング(www.skylight.co.jp) シニアマネジャー。米国PMI認定PMP。関西学院大学商学部卒業後、アンダーセンコンサルティング（現アクセンチュア）を経て現職。製造業や流通業のCRM領域において、業務改革やシステム構築のPM（プロジェクトマネジメント）の実績多数。特に大規模かつ複雑な案件を得意とする。外部からの依頼に基づき、プロジェクトの困難な状況の立て直しにも従事、PMの重要性を痛感。現在は、同社においてPMの活動そのものをコンサルティングの対象とするサービスを展開している。
SEとコンサルタントの大きな違い
SEとコンサルタントの大きな違い
～求められるスキルとマインドはこんなに違った！～
堀内浩二（「起-動線 for atmarkIT」エバンジェリスト）
2003/11/20
こんにちは、起-動線 for atmarkITの堀内です。今回は、先日相談に乗ったITエンジニアの矢木浩一郎氏（仮名・28歳）との会話から紹介します。彼は、＠IT自分戦略研究所のコンテンツでも取り上げられる「コンサルタント」という職種に興味があるとのことでした。
■SEの先にはどんなキャリアがあるのか
起-動線 for atmarkITは、自分戦略をつかみ、実現するための情報やサービスを提供しています。詳しくは起-動線 for atmarkITのコーナーをご覧ください。
矢木 突然ですが、エンジニアとコンサルタントの違いって何ですか。堀内さんはSEとコンサルタント、両方の職種の経験がありますよね。
堀内 どうしてまた急に？ なにかきっかけがあったのですか。
矢木 大学卒業後、社会人を5年間やってきて、「このプラットフォームの詳細設計と開発だったら、かなり質の高いモノが作れる」という自信みたいなものがついてきました。今後のキャリアを考えると、SEから一歩抜け出してコンサルタントを目指すべきなのかと思いまして……。いまの会社では、「もう少し上流の設計を覚えてからプロジェクトマネージャへ」というのが標準的なキャリアパス。特にコンサルタントという肩書きを持つ職種はありません。
堀内 このままシステム開発のプロとしてキャリアを積んでいくと、一般的にその延長にはコンサルタントがあるのか、あるいはまったく異なるキャリアがあるのか、ということを知りたいのですね？
矢木 そのとおりです。いままではSEとしてスキルアップすることしか考えていなかったので……。
■ITスキル標準で定義するコンサルタント
堀内 うーん、コンサルタントは、一種のはやり言葉でもあります。「ITスキル標準」は見ましたか。経済産業省がIT業界で仕事をする人のスキルレベルを職種別に定義したものです。基本的にはITエンジニアの教育に携わる組織向けのものですが、当事者のITエンジニアも目を通しておくといいですよ。自分のスキルレベルがどの程度にあるのかを、客観的に知る1つのモノサシになりますからね。ITスキル標準は経済産業省のホームページで見ることができます。いろいろと職種はありますが、矢木さんの場合は「ソフトウエアデベロップメント」になりますね。
矢木 かなり細かく定義分けされていますね……。
堀内 まずは、細かいところは省き、最初の「職種の概要」をじっくり読んでください。
☆「ソフトウエアデベロップメント」とは～ITスキル標準より引用
市場ニーズに基づくソフトウエア製品の企画、仕様設定、設計、プログラミング及びテストを実施する。また、上位レベルにおいては、ソフトウエア製品に関連したビジネス戦略の立案や適用コンサルテーションを実施する。
矢木 あれ、職種の説明欄に「コンサルテーション」が入っていますよ。レベルごとの達成度指標には「コンサル」という文字は見当たりませんが……。
堀内 ええ、およそ助言や提案を含む仕事は、コンサルテーションに含まれるものですからね。開発したソフトウエアを顧客に導入することになれば、自然とコンサルテーションは必要になります。矢木さんの会社でも、コンサルタントの肩書きなしに、コンサルテーションの仕事をしている方は少なからずいるはずですよ。
では比較のために、コンサルタントの「職種の説明」を見てみましょうか。
☆「コンサルタント」とは～ITスキル標準より引用
ビジネス上の課題に対して解決のための助言、提案及びカウンセリングを実施する。IT投資の局面においては、経営戦略策定（目標及びビジョンの策定、ビジネス戦略策定）及び戦略的情報化企画（課題整理及び分析、ビジネス及びIT)を主な活動領域として以下を実施する……。
■スキルに加えて「マインドセット」が異なる
矢木 うーん、なんだか難しそうだなあ……。
堀内 難しい、易しいというよりも、まず職種の違いを見てください。職種が違うと、何が変わってくると思いますか。
矢木 仕事の内容はまず違いますよね。それと求められるスキルの違いですか？
堀内 そうですね。ITスキル標準は、職種別の「仕事の内容」と「スキル」の“辞書”を作ろうとしているわけです。
矢木 なるほど。もしコンサルタントを目指すのであれば、このスキル標準をチェックリストにして、足りないスキルを埋めていけばいいのですね。
堀内 スキルの観点ではそうですが、職種の違いを考えるときには、もう1つ別の観点から考える必要があります。それは「マインドセット」という言葉が妥当ですかね。
矢木 マインドセットですか。心構えみたいなものでしょうか。
堀内 「何を目当てに仕事をするか」「仕事の報酬は何か」という方が近いかな。もちろん仕事はお金を得るための手段なのですが、それ以外にも無形の仕事の喜びってありますよね。
矢木 ヤリガイやダイゴ味ですか。
堀内 ええ。あまり紋切り型のことをいうつもりはありませんが、エンジニアリングのダイゴ味は、仮説を立てて検証していく問題解決のプロセスや、実践的に（工学的に）何かを作り上げることだったりしますよね。
それに比べると、コンサルティングのダイゴ味は、「顧客の成功を分かち合う」といったソフトな喜び、人に関係する喜びが多いと思います。仮に、「職種の説明」にあるように「コンサルティング・メソドロジ」なるものを学び、「経営戦略策定」に必要な知識を身につけたとしましょう。しかし、いざコンサルタントになってみると、ちっとも面白くないかもしれない。
■やりたい仕事のイメージを明確に持つ
矢木 そういうことは、ITスキル標準を読んでも分かりませんよね。
堀内 ITスキル標準はあくまで「スキルの標準」ですから。文書の性格としては間違っていません。しかし、業務を遂行するのは人です。職種が違えば、その仕事から得られる喜びの種類も異なることを考えておいた方がいいのではないでしょうか。
ソフトウエアデベロップメントという職種でコンサルテーション業務をすることと、ITスキル標準で定義されているようなコンサルタントの仕事には、そういう意味で違いがあると思います。
矢木 うーん、そうはいっても、なにしろやったことがない仕事ですからねえ……。自分の適性にマッチする面白い仕事かどうかなんて想像できないのではないでしょうか。
堀内 そのとおりです。わたしがいいたいのは、「期待値を明確に持って仕事に臨もうよ」ということ。例えば、エンジニアリングであれば実験の前に仮説を立てますよね。
矢木 なるほど。で、期待値を明確に持つにはどうすればいいのですか？
堀内 月並みですが、まずは矢木さんがやりたいと思うような仕事をすでにしている人の話を聞いたり、本を読んだりしてイメージを膨らませてみることではないでしょうか。
■コンサルタントの適性とは
矢木 では、堀内さんが考えるコンサルタント像とは何ですか？
堀内 そうきましたか。わたしの経験は非常に限られていますし、ここに定義されているような格好いい仕事ではなかったような気がします（笑）。ただ、コンサルタントに求められるものは何かを、コンサルティング企業を離れてからもいろいろ考えました……。大ざっぱにいえば3つあります。
・顧客以上に顧客の成功にコミットすること
・堂々と正論を述べること
・無知を認めること。その代わりに「学びの速さ」を武器にすること
こういうことができて、しかもそのプロセスに喜びを見いだせる人は、コンサルタントの適性があると思います。
矢木 うーむ、あまり自分には合わない仕事かも（笑）。僕はどちらかといえば、いいモノを作るというところでお客さんに喜んでもらいたいなあ。
堀内 いろいろな人に聞いてください。ITスキル標準を眺めていると、コンサルタントという独立した職種がありますが、世の中の仕事がすべてITスキル標準のとおりに分類されているわけではないですから。
～求められるスキルとマインドはこんなに違った！～
堀内浩二（「起-動線 for atmarkIT」エバンジェリスト）
2003/11/20
こんにちは、起-動線 for atmarkITの堀内です。今回は、先日相談に乗ったITエンジニアの矢木浩一郎氏（仮名・28歳）との会話から紹介します。彼は、＠IT自分戦略研究所のコンテンツでも取り上げられる「コンサルタント」という職種に興味があるとのことでした。
■SEの先にはどんなキャリアがあるのか
起-動線 for atmarkITは、自分戦略をつかみ、実現するための情報やサービスを提供しています。詳しくは起-動線 for atmarkITのコーナーをご覧ください。
矢木 突然ですが、エンジニアとコンサルタントの違いって何ですか。堀内さんはSEとコンサルタント、両方の職種の経験がありますよね。
堀内 どうしてまた急に？ なにかきっかけがあったのですか。
矢木 大学卒業後、社会人を5年間やってきて、「このプラットフォームの詳細設計と開発だったら、かなり質の高いモノが作れる」という自信みたいなものがついてきました。今後のキャリアを考えると、SEから一歩抜け出してコンサルタントを目指すべきなのかと思いまして……。いまの会社では、「もう少し上流の設計を覚えてからプロジェクトマネージャへ」というのが標準的なキャリアパス。特にコンサルタントという肩書きを持つ職種はありません。
堀内 このままシステム開発のプロとしてキャリアを積んでいくと、一般的にその延長にはコンサルタントがあるのか、あるいはまったく異なるキャリアがあるのか、ということを知りたいのですね？
矢木 そのとおりです。いままではSEとしてスキルアップすることしか考えていなかったので……。
■ITスキル標準で定義するコンサルタント
堀内 うーん、コンサルタントは、一種のはやり言葉でもあります。「ITスキル標準」は見ましたか。経済産業省がIT業界で仕事をする人のスキルレベルを職種別に定義したものです。基本的にはITエンジニアの教育に携わる組織向けのものですが、当事者のITエンジニアも目を通しておくといいですよ。自分のスキルレベルがどの程度にあるのかを、客観的に知る1つのモノサシになりますからね。ITスキル標準は経済産業省のホームページで見ることができます。いろいろと職種はありますが、矢木さんの場合は「ソフトウエアデベロップメント」になりますね。
矢木 かなり細かく定義分けされていますね……。
堀内 まずは、細かいところは省き、最初の「職種の概要」をじっくり読んでください。
☆「ソフトウエアデベロップメント」とは～ITスキル標準より引用
市場ニーズに基づくソフトウエア製品の企画、仕様設定、設計、プログラミング及びテストを実施する。また、上位レベルにおいては、ソフトウエア製品に関連したビジネス戦略の立案や適用コンサルテーションを実施する。
矢木 あれ、職種の説明欄に「コンサルテーション」が入っていますよ。レベルごとの達成度指標には「コンサル」という文字は見当たりませんが……。
堀内 ええ、およそ助言や提案を含む仕事は、コンサルテーションに含まれるものですからね。開発したソフトウエアを顧客に導入することになれば、自然とコンサルテーションは必要になります。矢木さんの会社でも、コンサルタントの肩書きなしに、コンサルテーションの仕事をしている方は少なからずいるはずですよ。
では比較のために、コンサルタントの「職種の説明」を見てみましょうか。
☆「コンサルタント」とは～ITスキル標準より引用
ビジネス上の課題に対して解決のための助言、提案及びカウンセリングを実施する。IT投資の局面においては、経営戦略策定（目標及びビジョンの策定、ビジネス戦略策定）及び戦略的情報化企画（課題整理及び分析、ビジネス及びIT)を主な活動領域として以下を実施する……。
■スキルに加えて「マインドセット」が異なる
矢木 うーん、なんだか難しそうだなあ……。
堀内 難しい、易しいというよりも、まず職種の違いを見てください。職種が違うと、何が変わってくると思いますか。
矢木 仕事の内容はまず違いますよね。それと求められるスキルの違いですか？
堀内 そうですね。ITスキル標準は、職種別の「仕事の内容」と「スキル」の“辞書”を作ろうとしているわけです。
矢木 なるほど。もしコンサルタントを目指すのであれば、このスキル標準をチェックリストにして、足りないスキルを埋めていけばいいのですね。
堀内 スキルの観点ではそうですが、職種の違いを考えるときには、もう1つ別の観点から考える必要があります。それは「マインドセット」という言葉が妥当ですかね。
矢木 マインドセットですか。心構えみたいなものでしょうか。
堀内 「何を目当てに仕事をするか」「仕事の報酬は何か」という方が近いかな。もちろん仕事はお金を得るための手段なのですが、それ以外にも無形の仕事の喜びってありますよね。
矢木 ヤリガイやダイゴ味ですか。
堀内 ええ。あまり紋切り型のことをいうつもりはありませんが、エンジニアリングのダイゴ味は、仮説を立てて検証していく問題解決のプロセスや、実践的に（工学的に）何かを作り上げることだったりしますよね。
それに比べると、コンサルティングのダイゴ味は、「顧客の成功を分かち合う」といったソフトな喜び、人に関係する喜びが多いと思います。仮に、「職種の説明」にあるように「コンサルティング・メソドロジ」なるものを学び、「経営戦略策定」に必要な知識を身につけたとしましょう。しかし、いざコンサルタントになってみると、ちっとも面白くないかもしれない。
■やりたい仕事のイメージを明確に持つ
矢木 そういうことは、ITスキル標準を読んでも分かりませんよね。
堀内 ITスキル標準はあくまで「スキルの標準」ですから。文書の性格としては間違っていません。しかし、業務を遂行するのは人です。職種が違えば、その仕事から得られる喜びの種類も異なることを考えておいた方がいいのではないでしょうか。
ソフトウエアデベロップメントという職種でコンサルテーション業務をすることと、ITスキル標準で定義されているようなコンサルタントの仕事には、そういう意味で違いがあると思います。
矢木 うーん、そうはいっても、なにしろやったことがない仕事ですからねえ……。自分の適性にマッチする面白い仕事かどうかなんて想像できないのではないでしょうか。
堀内 そのとおりです。わたしがいいたいのは、「期待値を明確に持って仕事に臨もうよ」ということ。例えば、エンジニアリングであれば実験の前に仮説を立てますよね。
矢木 なるほど。で、期待値を明確に持つにはどうすればいいのですか？
堀内 月並みですが、まずは矢木さんがやりたいと思うような仕事をすでにしている人の話を聞いたり、本を読んだりしてイメージを膨らませてみることではないでしょうか。
■コンサルタントの適性とは
矢木 では、堀内さんが考えるコンサルタント像とは何ですか？
堀内 そうきましたか。わたしの経験は非常に限られていますし、ここに定義されているような格好いい仕事ではなかったような気がします（笑）。ただ、コンサルタントに求められるものは何かを、コンサルティング企業を離れてからもいろいろ考えました……。大ざっぱにいえば3つあります。
・顧客以上に顧客の成功にコミットすること
・堂々と正論を述べること
・無知を認めること。その代わりに「学びの速さ」を武器にすること
こういうことができて、しかもそのプロセスに喜びを見いだせる人は、コンサルタントの適性があると思います。
矢木 うーむ、あまり自分には合わない仕事かも（笑）。僕はどちらかといえば、いいモノを作るというところでお客さんに喜んでもらいたいなあ。
堀内 いろいろな人に聞いてください。ITスキル標準を眺めていると、コンサルタントという独立した職種がありますが、世の中の仕事がすべてITスキル標準のとおりに分類されているわけではないですから。
Thursday, December 30, 2004
中国進出ブームの死角──逼迫するIT人材
中国進出ブームの死角──逼迫するIT人材
佐々木俊尚
2004/8/7
--------------------------------------------------------------------------------
「世界の工場」として、「巨大マーケット」として、ビジネス界は中国に熱い視線を投げかけている。しかし、昔から中国進出に苦労した企業は多い。現在ではビジネスのオペレーションに欠かせないITの面でも同様だという（→記事要約へ）
--------------------------------------------------------------------------------
- 再び盛り上がる中国進出
企業の中国進出に、再びブームが訪れている。従来のように大企業や製造業だけでなく、2000年をまたぐころから、ITベンチャーをはじめとしてさまざまな業種・規模の企業が中国に進出するようになった。その数は1万5000に迫るとされている。
中国ビジネスについて、少し歴史を振り返ってみよう。日本企業の中国進出が本格的に始まったのは、中国政府の改革開放路線が定着してきた1980年代後半からである。だが当時は法も商慣習もまったく異なる社会主義国への進出というハードルは恐ろしく高く、海外進出に日本企業があまり慣れていなかったことも手伝い、失敗に終わったケースが少なくなかった。そして1989年には天安門事件が起き、中国ブームは一気に冷めてしまう。
事件の余波が落ち着いた1990年代半ばには日本企業の対中投資熱は再燃するが、1997年にはアジア通貨危機が勃発（ぼっぱつ）し、対アジア投資自体が抑制される結果となった。現在の中国進出ブームは、通貨危機が去り、アジア各国が力を再び取り戻してきた2000年ごろから続いているといえるだろう。「第3次中国投資ブーム」とでもいえるかもしれない。
- さま変わりする“チャイナ・リスク”
昔に比べると、中国におけるビジネスの状況は大きく変わった。
中国が大きく市場経済へと転換を始めたのは、1980年代である。アジア通貨危機の荒波をくぐり抜ける中で、中国の改革開放路線に対する各国の信頼は揺るぎのないものとなった。2001年12月には世界貿易機構（WTO）への加盟を果たし、前世紀の遺物だった統制経済と完全に決別したのである。
この時期から金融や通信など、従来は国有企業が独占していた業種への外国企業参入が認められるようになり、そして株式市場も登場し、資本主義化に成功して成長を遂げつつある大型国有企業の上場などが始まっている。IT系のベンチャー企業も次々と登場し、莫大（ばくだい）な富を手にした新富裕層も出現した。ここ数年は政府目標を上回る勢いでの経済成長が続いており、スイスの経営開発国際研究所（IMD）が発表した2004年版の世界競争力年鑑では、中国は世界第24位にランキングされた。中国経済のあまりの過熱ぶりに「バブルではないか」という懸念も出ているほどだ。
日本 中国 韓国 台湾 香港 シンガポール
2000年 21 24 29 17 9 2
2001年 23 26 29 16 4 3
2002年 27 28 29 20 13 8
2003年 25 29 37 17 10 4
2004年 23 24 35 12 6 2
表1 世界競争力ランキング（順位）
出所：World Competitiveness Yearbook 2004（IMD）
こうした状況の中で、対中投資のリスクの中身も、大きく変ぼうを遂げている。以前のように、官僚的で閉鎖的な中国人の対応が、日系企業を苦しめるということはない。以前と比べれば、中国経済ははるかに資本主義化され、ソフィストケートされている。
だが一方で、新たな問題も生じつつある。中国を生産拠点に利用するだけでなく、巨大市場ととらえ、10億人市場での商品販売に乗り出した日系企業の多くはなかなか進まない代金回収に苦闘し、次々と現れるコピー商品対策にも手を焼いている。また企業所得税の減免措置など、外資系企業に与えられていたは優遇制度が撤廃の方向に進んでいることも、日系企業の間では大きな不安材料となっている。何しろ相手は大国とはいえ、資本主義への道を歩き出したのはわずか二十数年前のことなのである。そう簡単にリスクがなくなるわけがない。
- 中国拠点におけるIT化の課題
- PR -
同時に、中国の現地法人における情報システムの問題も顕在化しつつある。1990年代以降、日本企業のビジネスプロセスそのものがIT化されてきた中で、海外拠点ともネットワークで接続し、さまざまなシステムをグローバルに統合していかなければならなくなってきたからだ。
だが中国拠点のIT化は、同じアジアでもIT先進国である韓国や香港、台湾、シンガポールなどと比べれば、相変わらず甚だしい困難さが続いているといっていい。そもそも「どうやって通信インフラを現地オフィスに整備すればいいのか？」という基礎的なレベルから、つまずいてしまう企業もあるのである。
日本オラクル アジアパシフィック事業開発室から中国オラクルに出向し、上海を拠点に活動している佐藤友朋氏は、「中国でのビジネス経験がなければ、どう対応していいのか途方に暮れてしまう日系企業担当者もいる。相変わらず苦労の連続のようだ」と話す。
日本オラクルではもともと、日本国内に限ってサービスを提供していた。グローバルに展開する多国籍企業であるオラクルは、各国ごとにオラクル現地法人が存在し、各法人が自国内の顧客に製品を提供するというのが原則となっているからだ。日本企業は国内では日本オラクルから製品を購入するが、中国に拠点を作れば、そこでは中国オラクルからサービスの提供を受けなければならない。
だが日本企業の中国進出に関しては、中国という特殊事情に加え、日本企業が高度なサービスを求めていることなど、従来のルールではうまく回らないことが予想された。このため日中のオラクルが協力して、日本法人側が日系企業の顧客に対応し、中国オラクルの支援を行うという体制を作り上げたという。そして日本オラクル・アジアパシフィック事業開発室から6人の日本人スタッフが、中国オラクル日系企業営業部に出向し、上海の事務所に常駐して日本の顧客のサポートに追われているのである。
上海に駐在しているスタッフたちは、日本企業からさまざまな相談を受けている。中国でどのようにして通信インフラを整備すればいいのかという最初の難関から、国境をまたいでデータをどう統合するのかといったシステムの問題。さらには日中の会計制度の違いや著作権侵害への対応、情報漏えいに対する考え方など、多岐にわたっているという。日本オラクル上海スタッフたちの奮闘を見ていくと、そこには日本企業の中国進出の困難さが浮き彫りになってくるようだ。
その中から、今回はその代表的な苦労――人材採用を紹介しよう。
今日的中国人の生き方
ここ数年、日系企業の苦労がますます高まっているのは、いかにして質の良い中国人技術者を確保するのかという難問だという。
中国企業は従来、情報システム部門さえ持っていない企業が多かったから、システム管理ができるようなレベルの技術者は非常に少ない。もちろんITに関する教育熱は非常に高く、優秀な人材は次々と育っている。だがその多くは米国や日本などに海外留学し、帰国せずにそのまま海外企業に就職する道を選ぶのが一般的だ。その方が、圧倒的に給料が高いからである。それでも帰国して就職するという道を選ぶ人もわずかながらいるが、その大半は中国での会社設立を目指す「起業家予備軍」である。
日本オラクル アジアパシフィック事業開発室 佐藤友朋氏
佐藤氏は「日本のように、大手企業に就職して一生を技術者として過ごしたり、ITのスペシャリストを目指すという生き方を選ぶ人はほとんどいない。大半は将来の起業を目指しており、技術の習得はそのステップアップのためだ」と説明する。日本人の「技術者気質」みたいなものを期待すると、肩透かしに終わる可能性が高いということだろう。
そして起業を目指して海外留学から帰国した若手技術者たちは、多くは外資系のIT企業に就職してしまう。そしてこの「外資系企業」には、日系企業は含まれていないという。理由は簡単だ――給料が安く、おまけに決して現地法人のトップに就任できないから。日系企業現地法人の経営者は、日本の本社からの出向者で完全に独占されているのである。
まして、一般の製造業や食品業など、ITユーザーサイドの企業の情報システム部門に入社してくれる可能性は、非常に少ない。ユーザー企業のIT部門は、中国人技術者たちにとってはキャリアパスにならないのだ（肩書きに“マネージャ”と付けば、別かもしれないが）。もちろん、目標地点となることは絶対にない。厳しい話であるが、これが中国IT事情の現実なのである。
- 中国人エンジニアは確保できるか？
- PR -
そんな需給の逼迫もあり、中国ではIT技術者の処遇は極めて高い。経験を積んだエンジニアであれば、現地法人の経営幹部やマネージャクラスよりも高い給与が支払われているケースもあるという。
こうした高給の技術者をそれでも探して雇おうという場合、ちゃんと日本企業向けの人材派遣会社というのがある。現時点で3社が存在しているといい、これらの派遣会社とどう交渉するのかが、日系企業の採用担当者の重要な仕事となっているようだ。「これだけの数を採用するから、いい人材も入れてくれ」とあれこれ要求するのである。
一方で、中国には終身雇用制は存在しない。このため人材の流動性もきわめて高い。要するに、次々と転職し、どんどん会社を辞めていってしまうのである。せっかく優秀な人材を採用できても、その人物が来年も在籍してくれている保証は何もないのだ。佐藤氏は「たいていは1年ぐらいで転職していくため、大手企業でも教育プログラムなどは一切用意していないところが多い。教育が無駄な投資になってしまうから」と話す。人材採用に関しては長期的な計画を立てるのも難しく、かなり厳しい状況であるということなのだろう。
次回以降、日本オラクル・アジアパシフィック事業開発室の面々の奮闘ぶりを紹介しながら、中国におけるITのさまざまな難題を見ていきたい。
佐々木俊尚
2004/8/7
--------------------------------------------------------------------------------
「世界の工場」として、「巨大マーケット」として、ビジネス界は中国に熱い視線を投げかけている。しかし、昔から中国進出に苦労した企業は多い。現在ではビジネスのオペレーションに欠かせないITの面でも同様だという（→記事要約
--------------------------------------------------------------------------------
- 再び盛り上がる中国進出
企業の中国進出に、再びブームが訪れている。従来のように大企業や製造業だけでなく、2000年をまたぐころから、ITベンチャーをはじめとしてさまざまな業種・規模の企業が中国に進出するようになった。その数は1万5000に迫るとされている。
中国ビジネスについて、少し歴史を振り返ってみよう。日本企業の中国進出が本格的に始まったのは、中国政府の改革開放路線が定着してきた1980年代後半からである。だが当時は法も商慣習もまったく異なる社会主義国への進出というハードルは恐ろしく高く、海外進出に日本企業があまり慣れていなかったことも手伝い、失敗に終わったケースが少なくなかった。そして1989年には天安門事件が起き、中国ブームは一気に冷めてしまう。
事件の余波が落ち着いた1990年代半ばには日本企業の対中投資熱は再燃するが、1997年にはアジア通貨危機が勃発（ぼっぱつ）し、対アジア投資自体が抑制される結果となった。現在の中国進出ブームは、通貨危機が去り、アジア各国が力を再び取り戻してきた2000年ごろから続いているといえるだろう。「第3次中国投資ブーム」とでもいえるかもしれない。
- さま変わりする“チャイナ・リスク”
昔に比べると、中国におけるビジネスの状況は大きく変わった。
中国が大きく市場経済へと転換を始めたのは、1980年代である。アジア通貨危機の荒波をくぐり抜ける中で、中国の改革開放路線に対する各国の信頼は揺るぎのないものとなった。2001年12月には世界貿易機構（WTO）への加盟を果たし、前世紀の遺物だった統制経済と完全に決別したのである。
この時期から金融や通信など、従来は国有企業が独占していた業種への外国企業参入が認められるようになり、そして株式市場も登場し、資本主義化に成功して成長を遂げつつある大型国有企業の上場などが始まっている。IT系のベンチャー企業も次々と登場し、莫大（ばくだい）な富を手にした新富裕層も出現した。ここ数年は政府目標を上回る勢いでの経済成長が続いており、スイスの経営開発国際研究所（IMD）が発表した2004年版の世界競争力年鑑では、中国は世界第24位にランキングされた。中国経済のあまりの過熱ぶりに「バブルではないか」という懸念も出ているほどだ。
日本 中国 韓国 台湾 香港 シンガポール
2000年 21 24 29 17 9 2
2001年 23 26 29 16 4 3
2002年 27 28 29 20 13 8
2003年 25 29 37 17 10 4
2004年 23 24 35 12 6 2
表1 世界競争力ランキング（順位）
出所：World Competitiveness Yearbook 2004（IMD）
こうした状況の中で、対中投資のリスクの中身も、大きく変ぼうを遂げている。以前のように、官僚的で閉鎖的な中国人の対応が、日系企業を苦しめるということはない。以前と比べれば、中国経済ははるかに資本主義化され、ソフィストケートされている。
だが一方で、新たな問題も生じつつある。中国を生産拠点に利用するだけでなく、巨大市場ととらえ、10億人市場での商品販売に乗り出した日系企業の多くはなかなか進まない代金回収に苦闘し、次々と現れるコピー商品対策にも手を焼いている。また企業所得税の減免措置など、外資系企業に与えられていたは優遇制度が撤廃の方向に進んでいることも、日系企業の間では大きな不安材料となっている。何しろ相手は大国とはいえ、資本主義への道を歩き出したのはわずか二十数年前のことなのである。そう簡単にリスクがなくなるわけがない。
- 中国拠点におけるIT化の課題
- PR -
同時に、中国の現地法人における情報システムの問題も顕在化しつつある。1990年代以降、日本企業のビジネスプロセスそのものがIT化されてきた中で、海外拠点ともネットワークで接続し、さまざまなシステムをグローバルに統合していかなければならなくなってきたからだ。
だが中国拠点のIT化は、同じアジアでもIT先進国である韓国や香港、台湾、シンガポールなどと比べれば、相変わらず甚だしい困難さが続いているといっていい。そもそも「どうやって通信インフラを現地オフィスに整備すればいいのか？」という基礎的なレベルから、つまずいてしまう企業もあるのである。
日本オラクル アジアパシフィック事業開発室から中国オラクルに出向し、上海を拠点に活動している佐藤友朋氏は、「中国でのビジネス経験がなければ、どう対応していいのか途方に暮れてしまう日系企業担当者もいる。相変わらず苦労の連続のようだ」と話す。
日本オラクルではもともと、日本国内に限ってサービスを提供していた。グローバルに展開する多国籍企業であるオラクルは、各国ごとにオラクル現地法人が存在し、各法人が自国内の顧客に製品を提供するというのが原則となっているからだ。日本企業は国内では日本オラクルから製品を購入するが、中国に拠点を作れば、そこでは中国オラクルからサービスの提供を受けなければならない。
だが日本企業の中国進出に関しては、中国という特殊事情に加え、日本企業が高度なサービスを求めていることなど、従来のルールではうまく回らないことが予想された。このため日中のオラクルが協力して、日本法人側が日系企業の顧客に対応し、中国オラクルの支援を行うという体制を作り上げたという。そして日本オラクル・アジアパシフィック事業開発室から6人の日本人スタッフが、中国オラクル日系企業営業部に出向し、上海の事務所に常駐して日本の顧客のサポートに追われているのである。
上海に駐在しているスタッフたちは、日本企業からさまざまな相談を受けている。中国でどのようにして通信インフラを整備すればいいのかという最初の難関から、国境をまたいでデータをどう統合するのかといったシステムの問題。さらには日中の会計制度の違いや著作権侵害への対応、情報漏えいに対する考え方など、多岐にわたっているという。日本オラクル上海スタッフたちの奮闘を見ていくと、そこには日本企業の中国進出の困難さが浮き彫りになってくるようだ。
その中から、今回はその代表的な苦労――人材採用を紹介しよう。
今日的中国人の生き方
ここ数年、日系企業の苦労がますます高まっているのは、いかにして質の良い中国人技術者を確保するのかという難問だという。
中国企業は従来、情報システム部門さえ持っていない企業が多かったから、システム管理ができるようなレベルの技術者は非常に少ない。もちろんITに関する教育熱は非常に高く、優秀な人材は次々と育っている。だがその多くは米国や日本などに海外留学し、帰国せずにそのまま海外企業に就職する道を選ぶのが一般的だ。その方が、圧倒的に給料が高いからである。それでも帰国して就職するという道を選ぶ人もわずかながらいるが、その大半は中国での会社設立を目指す「起業家予備軍」である。
日本オラクル アジアパシフィック事業開発室 佐藤友朋氏
佐藤氏は「日本のように、大手企業に就職して一生を技術者として過ごしたり、ITのスペシャリストを目指すという生き方を選ぶ人はほとんどいない。大半は将来の起業を目指しており、技術の習得はそのステップアップのためだ」と説明する。日本人の「技術者気質」みたいなものを期待すると、肩透かしに終わる可能性が高いということだろう。
そして起業を目指して海外留学から帰国した若手技術者たちは、多くは外資系のIT企業に就職してしまう。そしてこの「外資系企業」には、日系企業は含まれていないという。理由は簡単だ――給料が安く、おまけに決して現地法人のトップに就任できないから。日系企業現地法人の経営者は、日本の本社からの出向者で完全に独占されているのである。
まして、一般の製造業や食品業など、ITユーザーサイドの企業の情報システム部門に入社してくれる可能性は、非常に少ない。ユーザー企業のIT部門は、中国人技術者たちにとってはキャリアパスにならないのだ（肩書きに“マネージャ”と付けば、別かもしれないが）。もちろん、目標地点となることは絶対にない。厳しい話であるが、これが中国IT事情の現実なのである。
- 中国人エンジニアは確保できるか？
- PR -
そんな需給の逼迫もあり、中国ではIT技術者の処遇は極めて高い。経験を積んだエンジニアであれば、現地法人の経営幹部やマネージャクラスよりも高い給与が支払われているケースもあるという。
こうした高給の技術者をそれでも探して雇おうという場合、ちゃんと日本企業向けの人材派遣会社というのがある。現時点で3社が存在しているといい、これらの派遣会社とどう交渉するのかが、日系企業の採用担当者の重要な仕事となっているようだ。「これだけの数を採用するから、いい人材も入れてくれ」とあれこれ要求するのである。
一方で、中国には終身雇用制は存在しない。このため人材の流動性もきわめて高い。要するに、次々と転職し、どんどん会社を辞めていってしまうのである。せっかく優秀な人材を採用できても、その人物が来年も在籍してくれている保証は何もないのだ。佐藤氏は「たいていは1年ぐらいで転職していくため、大手企業でも教育プログラムなどは一切用意していないところが多い。教育が無駄な投資になってしまうから」と話す。人材採用に関しては長期的な計画を立てるのも難しく、かなり厳しい状況であるということなのだろう。
次回以降、日本オラクル・アジアパシフィック事業開発室の面々の奮闘ぶりを紹介しながら、中国におけるITのさまざまな難題を見ていきたい。
第1回 オフショア開発でハッピーになれましたか？
http://www.atmarkit.co.jp/farc/rensai/bottleneck01/bottleneck01.html
第1回 オフショア開発でハッピーになれましたか？
ボーランド
今村智
2004/2/21
開発プロセスブームも一段落した感がある中、最近は、原点回帰ともいえる“ソフトウェア要求”に関する話題が目に付くようになりました。この短期連載では、ソフトウェア開発、特に企業情報システムのSIの現場でよく見聞きする取り組みと、そのほとんどが失敗している原因に“ソフトウェア要求”の存在があること、そういった取り組みを成功させるためには、どのように考え、何を行っていくべきかをお伝えしたいと思います。
第1回は、「オフショア開発でハッピーになれましたか？」と題して、すでに痛い目に遭った方（プロジェクト）も多いにもかかわらず、相変わらずの低コスト化圧力への即効薬として重宝されているオフショア開発について考えてみます。
（1）オフショア開発の実態
近年、ソフトウェア開発の現場もほかの業界同様に、非常に厳しい価格競争を強いられているのは皆さんもご存じのとおりです。そして、そのような状況に対処するための手段として、人件費の安い海外に開発拠点を置くという状況もまったくもってほかの製造業界と同じです。製造業においては、教育レベル、文化、慣習の違いなどから、現地人スタッフの教育で苦労したという話も聞くものの、オフショア“生産”は、製造業においてはすでに成功モデルとして確立しているのも確かです。
“生産”としたことには理由があります。製造業におけるオフショアリソースの活用は、開発済みの技術、仕様に基づいた大量生産フェイズという労働集約的な部分が中心であるのに対して、ソフトウェア開発のそれは、ユーザー要求を実現するための創作活動＝“開発”が中心となっています。本質を見極めずにとにかく製造業の“改善”を取り込もうとすることには疑問を持っていますが、取りあえず本稿では脇に置いておくことにします。
- PR -
しかし、ソフトウェア開発においてはどうでしょうか？ 少なくとも筆者の経験、それからほかの経験者から聞き及んだ範囲においては、オフショア開発が成功モデルであるとはいえません。むしろ、日本人同士で、国内で開発をする場合よりも悲惨な結果を招いていることが圧倒的に多いようです。ここで、成功という言葉を使いましたが、本稿における“成功”とは単純に、“ソフトウェア開発プロジェクトを予算内で収めること”とします。
もちろん、プロジェクトメンバーのプロジェクト内作業にかかる残業代は100％支給され、コストとして計上されることとします。あえて残業について言及したのは、かつて、「プロジェクトの成功は、納期を守ることであり、プロジェクトのリスクは残業代が支給されない上級SEの投入でヘッジする」ということを公然というプロジェクトマネージャがいたからです。そのようなマネージャのプロジェクトにアサインされたSEの方は本当にお気の毒です。プロジェクト初期から、燃え尽きるまで走り続けさせられます。
少し脱線してしまいましたが、ソフトウェア開発におけるオフショア開発では、手痛い失敗が非常に多いのです。ここでいう失敗とは先の成功の定義から、予算オーバーか、納品できなかったか、あるいはその両方ということになります。そして、その理由を探ってみると、「要求を正しく理解してもらえない」「日本人であれば行間を読んで要求の不備をカバーするということがあるが、オフショア開発者にはそのようなことはそもそも無理」「出来上がったプログラムを引き取ってテストしてみると、品質が悪く、まともに動作しない」といった要求仕様の理解や、品質に関するものが圧倒的に多いのです。
また、「納期を厳守するということの重要性の認識が薄い」といった文化、慣習の違いによると思われるものも多くはありませんが耳にします。でも、要求仕様の理解や品質に関する問題は、何もオフショア開発だからというものではないと思いませんか？ そもそも、オフショア開発を行わなければならないようなプロジェクトとは、ある程度の規模と期間を要するものです。
そして、そのような規模の開発であれば、日本人同士で行ったとしてもうまくいかないことが多いのです。ここで、明確にどのくらいの規模、期間かを指針として出せないのは、どの程度のスキルのメンバーをそろえられるか、チーム構成の工夫によって、必要なコミュニケーションラインをどれだけ単純に（少なく）できるか、といったことによって大きく変動するからです。ただ、経験からいえることは数十人程度の開発者のチームや、プロジェクト期間が半年以内のものであれば、優秀な国内の開発者を使う方がはるかに安全に成功を手にする可能性を高めることができると思います。
それ以上の開発者を1つのプロジェクト内でコントロールしなければならないという場合には、まず本当にそれだけの人数を1つのプロジェクトメンバーとして必要なのかを再考すべきです。そのような規模のプロジェクトでは、ほとんどの場合、サブプロジェクトに分割し、個々のプロジェクト活動が、ほかのサブプロジェクトを意識しないようにすることが可能です。
（2）ブリッジSEの役割
チームの規模による1人当たりの生産性の変化と、チーム全体の生産高の変化については、『アジャイルプロジェクト管理』（アリスター・コーバーン著、長瀬嘉秀、今野睦訳、ピアソン・エデュケーション）に詳しく説明されていますが、簡単に解説すると、開発者1人当たりの生産性は、プロジェクト規模が大きくなるに従って落ちていくのですが、まったくのゼロになることはありませんから、ある規模を超えると、チームとしての生産高が、少数精鋭のチームの生産高を超えることになるということです。ですから、この分岐点を越えるような人海戦術的なケースでは、オフショア開発が有力な選択肢として重宝されるのですが、先に述べたような、要求仕様の理解や品質に関する問題は、人海戦術では解決しないどころか、さらに悪化することになります。
オフショア開発では、この問題に対処するために、さらにブリッジSEと呼ばれる役割を担う人を投入します。ブリッジSEとは、ユーザーからの要求仕様を、オフショアの開発者へ伝え、オフショアの開発者との質疑応答に対応することが主な仕事になりますから、オフショアの開発者の数が増えればそれだけブリッジSEの人数も増やさなければなりません。ところが、ブリッジSEが増えても最終的に対応するのは真の要求者である顧客メンバーですから、彼らの処理能力が増えない限りはボトルネックが移動するだけとなります。
また、オフショアでは日本との時差も数時間ありますので、同じ日本国内であればユーザーとの仕様調整、仕様確認が日付をまたがることなく済んだものが、日付をまたがらざるを得ないケースが頻発します。これは、回復不可能な時間の損失としてあっという間に蓄積されます。それでもリリースの日付が変更されることはありませんので、結果として、開発の現場では単体テストコードどころか、手動での動作確認さえもままならない状態となってしまいます。
ここまでの、ソフトウェアにおけるオフショア開発の問題を整理してみると、
要求仕様が正しく伝わらないことによって、低品質のプログラムが出来上がる
要求仕様の正しい理解を助けるためにブリッジSEを必要とし、コストメリットが増幅すると考えられる大規模開発になればなるほど、コスト増大、スケジュール遅延を招いている
ということになります（いうまでもなく、これらは実はオフショア開発に限った問題ではありません）。もちろんこれら以外にも、言葉の問題もありますし、文化、慣習の違いがあるのは先に述べたとおりです。しかし、この要求仕様を起点とする問題に対処することで、オフショアの人材を有効に活用することが可能です。上記問題点を見ればお分かりのとおり、要求仕様に含まれるあいまいさが少なければ少ないほど、これらの問題による影響を少なくすることになります。
（3）要求仕様のあいまいさをなくす
要求仕様のあいまいさをなくすために有効な方法として、要求仕様がテスト可能であるかを確認するということが挙げられます。開発の進め方として、一般的には図1の進め方をよく見掛けます。しかし、この進め方では、要求仕様を書いた時点ですぐにその要求がテスト可能であるかを確認することができず、しばらく間が空いて、テストシナリオの作成段階において要求仕様がテスト不可能であることが判明し、それまでに済んでしまった設計、実装までもが見直し、再作業を必要とする事態が多く発生します。なお、ここでのテストシナリオとは、単体テストのパターンではなく、ユーザー要求に対するテストシナリオを指しています。つまり、どのようにすればユーザー要求（機能要求、システム要求ではなく）を満たしていることを確認できるのか、というものです。
図1 よく見掛ける開発ライフサイクル
なぜ、このようなプロセスを行っているのか、私はいままで一度も納得のできる説明を聞いたことはありません。一番よく聞く説明は、「いままでずっとそうしてきたから」というものです。ではなぜ、最初にそのようにしたのかというと、
テスト担当は、開発チームとは別のテスト専門の部隊に所属し、テストシナリオ作成とテスト実施および結果のレポートが責務となっている
開発ライフサイクルが比較的長いウォーターフォール型の開発においては、テスト部隊のリソース管理上、テストシナリオ作成期間とテスト実施期間との間が開いてしまうのを避けたいために、テストシナリオ作成が、テスト実施の直前に完了するように計画する
ということです。つまり、大きな組織で、分業化が進んでいる状態で、個々の部隊の効率的なリソースマネージメントを行うためであり、プロジェクトの品質確保のためではないのです。
ところで、米国でのソフトウェア開発プロジェクトの実態調査の１つでは、「ソフトウェアの問題（バグ、性能問題など）の30％は、“要求”に起因するものであった」という報告があります。30％とは、私の経験に照らし合わせると、かなり控えめな数値です。実際、ほかの調査報告では、「ソフトウェアシステムの問題の60％は、要求とその分析の過程において作り込まれていた」というものもあります。いずれの調査も、特定のプロジェクトを対象としたものではなく、複数のプロジェクトに対する調査結果をまとめたものです。
図2 要求に起因する問題の発見タイミングとその修正にかかるコスト
図2は、そのような“要求”に起因する問題の発見されるタイミングが遅ければ遅いほど、その修正にかかるコストが飛躍的に増大することを表しています（Source：Boehm, Barry W. 『Software Engineering Economics』. Englewood Cliffs, NJ：Prentice-Hall, 1981）。
具体的な数値は置いておくとしても、このような傾向は、遅ければ遅いほど、それまでに行ったすべての作業に見直しと再作業が必要になることから明らかです。
ですから、“要求”の問題はとにかく早く発見する方がよく、そのために有効な手段である、要求がテスト可能であることの確認、つまりテストシナリオの検討、作成を早く行うことが重要になってきます。図3はテストシナリオ作成を、要求定義と並行して行う様を表しています。
図3 要求の品質を上げるための開発ライフサイクル
要求定義とテストシナリオ作成を同時期に、反復的に行うことによって、すべての要求定義が完了するタイミングが、従来のやり方に比べて遅れるとしても、その効果はそれを補って余りあるものとなります。テスト可能であるためには、要求に矛盾点がなく、あいまいさもない状態でなければなりません。ですから、テストシナリオを考えたときに、合否の判断基準が明確ではない場合は、要求としては不適切だと判断し、見直すことができるのです。
このようにして、あいまいさがなく、高品質な要求仕様を定義することができれば、現状のオフショア開発で直面している問題のかなりの部分を解決することができますし、さらにいうと、そのような要求仕様の定義をすることで、わざわざオフショア開発をするまでもなく競争力を持つことができるはずです。もちろん、すべてのソフトウェア開発プロジェクトでこれが実行されれば、またしても価格競争に陥ることになるかもしれませんが、幸か不幸か、まだまだオフショア開発以前のところでの改善ポイントがありますから心配には及びません。
今回は、開発ライフサイクルからのアプローチによって、ソフトウェア要求の問題を改善し、オフショア開発が行える要求定義を行う、という内容でしたが、実際にどのような要求定義（要求開発）を行えばよいのかというより実践的な内容については、また別の機会にお伝えできればと思います。
次回は、「コンポーネント再利用できていますか？」というタイトルでお伝えする予定です。
第1回 オフショア開発でハッピーになれましたか？
ボーランド
今村智
2004/2/21
開発プロセスブームも一段落した感がある中、最近は、原点回帰ともいえる“ソフトウェア要求”に関する話題が目に付くようになりました。この短期連載では、ソフトウェア開発、特に企業情報システムのSIの現場でよく見聞きする取り組みと、そのほとんどが失敗している原因に“ソフトウェア要求”の存在があること、そういった取り組みを成功させるためには、どのように考え、何を行っていくべきかをお伝えしたいと思います。
第1回は、「オフショア開発でハッピーになれましたか？」と題して、すでに痛い目に遭った方（プロジェクト）も多いにもかかわらず、相変わらずの低コスト化圧力への即効薬として重宝されているオフショア開発について考えてみます。
（1）オフショア開発の実態
近年、ソフトウェア開発の現場もほかの業界同様に、非常に厳しい価格競争を強いられているのは皆さんもご存じのとおりです。そして、そのような状況に対処するための手段として、人件費の安い海外に開発拠点を置くという状況もまったくもってほかの製造業界と同じです。製造業においては、教育レベル、文化、慣習の違いなどから、現地人スタッフの教育で苦労したという話も聞くものの、オフショア“生産”は、製造業においてはすでに成功モデルとして確立しているのも確かです。
“生産”としたことには理由があります。製造業におけるオフショアリソースの活用は、開発済みの技術、仕様に基づいた大量生産フェイズという労働集約的な部分が中心であるのに対して、ソフトウェア開発のそれは、ユーザー要求を実現するための創作活動＝“開発”が中心となっています。本質を見極めずにとにかく製造業の“改善”を取り込もうとすることには疑問を持っていますが、取りあえず本稿では脇に置いておくことにします。
- PR -
しかし、ソフトウェア開発においてはどうでしょうか？ 少なくとも筆者の経験、それからほかの経験者から聞き及んだ範囲においては、オフショア開発が成功モデルであるとはいえません。むしろ、日本人同士で、国内で開発をする場合よりも悲惨な結果を招いていることが圧倒的に多いようです。ここで、成功という言葉を使いましたが、本稿における“成功”とは単純に、“ソフトウェア開発プロジェクトを予算内で収めること”とします。
もちろん、プロジェクトメンバーのプロジェクト内作業にかかる残業代は100％支給され、コストとして計上されることとします。あえて残業について言及したのは、かつて、「プロジェクトの成功は、納期を守ることであり、プロジェクトのリスクは残業代が支給されない上級SEの投入でヘッジする」ということを公然というプロジェクトマネージャがいたからです。そのようなマネージャのプロジェクトにアサインされたSEの方は本当にお気の毒です。プロジェクト初期から、燃え尽きるまで走り続けさせられます。
少し脱線してしまいましたが、ソフトウェア開発におけるオフショア開発では、手痛い失敗が非常に多いのです。ここでいう失敗とは先の成功の定義から、予算オーバーか、納品できなかったか、あるいはその両方ということになります。そして、その理由を探ってみると、「要求を正しく理解してもらえない」「日本人であれば行間を読んで要求の不備をカバーするということがあるが、オフショア開発者にはそのようなことはそもそも無理」「出来上がったプログラムを引き取ってテストしてみると、品質が悪く、まともに動作しない」といった要求仕様の理解や、品質に関するものが圧倒的に多いのです。
また、「納期を厳守するということの重要性の認識が薄い」といった文化、慣習の違いによると思われるものも多くはありませんが耳にします。でも、要求仕様の理解や品質に関する問題は、何もオフショア開発だからというものではないと思いませんか？ そもそも、オフショア開発を行わなければならないようなプロジェクトとは、ある程度の規模と期間を要するものです。
そして、そのような規模の開発であれば、日本人同士で行ったとしてもうまくいかないことが多いのです。ここで、明確にどのくらいの規模、期間かを指針として出せないのは、どの程度のスキルのメンバーをそろえられるか、チーム構成の工夫によって、必要なコミュニケーションラインをどれだけ単純に（少なく）できるか、といったことによって大きく変動するからです。ただ、経験からいえることは数十人程度の開発者のチームや、プロジェクト期間が半年以内のものであれば、優秀な国内の開発者を使う方がはるかに安全に成功を手にする可能性を高めることができると思います。
それ以上の開発者を1つのプロジェクト内でコントロールしなければならないという場合には、まず本当にそれだけの人数を1つのプロジェクトメンバーとして必要なのかを再考すべきです。そのような規模のプロジェクトでは、ほとんどの場合、サブプロジェクトに分割し、個々のプロジェクト活動が、ほかのサブプロジェクトを意識しないようにすることが可能です。
（2）ブリッジSEの役割
チームの規模による1人当たりの生産性の変化と、チーム全体の生産高の変化については、『アジャイルプロジェクト管理』（アリスター・コーバーン著、長瀬嘉秀、今野睦訳、ピアソン・エデュケーション）に詳しく説明されていますが、簡単に解説すると、開発者1人当たりの生産性は、プロジェクト規模が大きくなるに従って落ちていくのですが、まったくのゼロになることはありませんから、ある規模を超えると、チームとしての生産高が、少数精鋭のチームの生産高を超えることになるということです。ですから、この分岐点を越えるような人海戦術的なケースでは、オフショア開発が有力な選択肢として重宝されるのですが、先に述べたような、要求仕様の理解や品質に関する問題は、人海戦術では解決しないどころか、さらに悪化することになります。
オフショア開発では、この問題に対処するために、さらにブリッジSEと呼ばれる役割を担う人を投入します。ブリッジSEとは、ユーザーからの要求仕様を、オフショアの開発者へ伝え、オフショアの開発者との質疑応答に対応することが主な仕事になりますから、オフショアの開発者の数が増えればそれだけブリッジSEの人数も増やさなければなりません。ところが、ブリッジSEが増えても最終的に対応するのは真の要求者である顧客メンバーですから、彼らの処理能力が増えない限りはボトルネックが移動するだけとなります。
また、オフショアでは日本との時差も数時間ありますので、同じ日本国内であればユーザーとの仕様調整、仕様確認が日付をまたがることなく済んだものが、日付をまたがらざるを得ないケースが頻発します。これは、回復不可能な時間の損失としてあっという間に蓄積されます。それでもリリースの日付が変更されることはありませんので、結果として、開発の現場では単体テストコードどころか、手動での動作確認さえもままならない状態となってしまいます。
ここまでの、ソフトウェアにおけるオフショア開発の問題を整理してみると、
要求仕様が正しく伝わらないことによって、低品質のプログラムが出来上がる
要求仕様の正しい理解を助けるためにブリッジSEを必要とし、コストメリットが増幅すると考えられる大規模開発になればなるほど、コスト増大、スケジュール遅延を招いている
ということになります（いうまでもなく、これらは実はオフショア開発に限った問題ではありません）。もちろんこれら以外にも、言葉の問題もありますし、文化、慣習の違いがあるのは先に述べたとおりです。しかし、この要求仕様を起点とする問題に対処することで、オフショアの人材を有効に活用することが可能です。上記問題点を見ればお分かりのとおり、要求仕様に含まれるあいまいさが少なければ少ないほど、これらの問題による影響を少なくすることになります。
（3）要求仕様のあいまいさをなくす
要求仕様のあいまいさをなくすために有効な方法として、要求仕様がテスト可能であるかを確認するということが挙げられます。開発の進め方として、一般的には図1の進め方をよく見掛けます。しかし、この進め方では、要求仕様を書いた時点ですぐにその要求がテスト可能であるかを確認することができず、しばらく間が空いて、テストシナリオの作成段階において要求仕様がテスト不可能であることが判明し、それまでに済んでしまった設計、実装までもが見直し、再作業を必要とする事態が多く発生します。なお、ここでのテストシナリオとは、単体テストのパターンではなく、ユーザー要求に対するテストシナリオを指しています。つまり、どのようにすればユーザー要求（機能要求、システム要求ではなく）を満たしていることを確認できるのか、というものです。
図1 よく見掛ける開発ライフサイクル
なぜ、このようなプロセスを行っているのか、私はいままで一度も納得のできる説明を聞いたことはありません。一番よく聞く説明は、「いままでずっとそうしてきたから」というものです。ではなぜ、最初にそのようにしたのかというと、
テスト担当は、開発チームとは別のテスト専門の部隊に所属し、テストシナリオ作成とテスト実施および結果のレポートが責務となっている
開発ライフサイクルが比較的長いウォーターフォール型の開発においては、テスト部隊のリソース管理上、テストシナリオ作成期間とテスト実施期間との間が開いてしまうのを避けたいために、テストシナリオ作成が、テスト実施の直前に完了するように計画する
ということです。つまり、大きな組織で、分業化が進んでいる状態で、個々の部隊の効率的なリソースマネージメントを行うためであり、プロジェクトの品質確保のためではないのです。
ところで、米国でのソフトウェア開発プロジェクトの実態調査の１つでは、「ソフトウェアの問題（バグ、性能問題など）の30％は、“要求”に起因するものであった」という報告があります。30％とは、私の経験に照らし合わせると、かなり控えめな数値です。実際、ほかの調査報告では、「ソフトウェアシステムの問題の60％は、要求とその分析の過程において作り込まれていた」というものもあります。いずれの調査も、特定のプロジェクトを対象としたものではなく、複数のプロジェクトに対する調査結果をまとめたものです。
図2 要求に起因する問題の発見タイミングとその修正にかかるコスト
図2は、そのような“要求”に起因する問題の発見されるタイミングが遅ければ遅いほど、その修正にかかるコストが飛躍的に増大することを表しています（Source：Boehm, Barry W. 『Software Engineering Economics』. Englewood Cliffs, NJ：Prentice-Hall, 1981）。
具体的な数値は置いておくとしても、このような傾向は、遅ければ遅いほど、それまでに行ったすべての作業に見直しと再作業が必要になることから明らかです。
ですから、“要求”の問題はとにかく早く発見する方がよく、そのために有効な手段である、要求がテスト可能であることの確認、つまりテストシナリオの検討、作成を早く行うことが重要になってきます。図3はテストシナリオ作成を、要求定義と並行して行う様を表しています。
図3 要求の品質を上げるための開発ライフサイクル
要求定義とテストシナリオ作成を同時期に、反復的に行うことによって、すべての要求定義が完了するタイミングが、従来のやり方に比べて遅れるとしても、その効果はそれを補って余りあるものとなります。テスト可能であるためには、要求に矛盾点がなく、あいまいさもない状態でなければなりません。ですから、テストシナリオを考えたときに、合否の判断基準が明確ではない場合は、要求としては不適切だと判断し、見直すことができるのです。
このようにして、あいまいさがなく、高品質な要求仕様を定義することができれば、現状のオフショア開発で直面している問題のかなりの部分を解決することができますし、さらにいうと、そのような要求仕様の定義をすることで、わざわざオフショア開発をするまでもなく競争力を持つことができるはずです。もちろん、すべてのソフトウェア開発プロジェクトでこれが実行されれば、またしても価格競争に陥ることになるかもしれませんが、幸か不幸か、まだまだオフショア開発以前のところでの改善ポイントがありますから心配には及びません。
今回は、開発ライフサイクルからのアプローチによって、ソフトウェア要求の問題を改善し、オフショア開発が行える要求定義を行う、という内容でしたが、実際にどのような要求定義（要求開発）を行えばよいのかというより実践的な内容については、また別の機会にお伝えできればと思います。
次回は、「コンポーネント再利用できていますか？」というタイトルでお伝えする予定です。
第3回 なぜ、中国オフショア開発の見積もりは高いのか？
なぜ、中国オフショア開発の見積もりは高いのか？
幸地 司
アイコーチ有限会社
2004/11/12
--------------------------------------------------------------------------------
「コスト削減のためにオフショア開発を取り入れたものの、実際には納期と品質を確保するだけで精いっぱい」、このように訴える日本企業は多い。今回は、オフショア開発の隠れたコスト要因を明らかにして、効果的なプロジェクト計画書の作り方やスムーズなオフショア開発立ち上げを実現するアプローチを紹介する。（→記事要約へ）
--------------------------------------------------------------------------------
- 日本の甘え体質では、やっていけなくなる
「トップはオフショア開発によるコスト削減をうたっているが、現場の感覚はまったく別だ。こちらとしては採算を度外視して、納期と品質を確保するだけで精いっぱいである」
ある大手メーカーに勤めるプロジェクトマネージャの話です。従来の日本企業は、ライバル会社に後れを取らないことを優先して、オフショア開発拠点の整備を急いできました。
- PR -
海外ベンダのレベルアップが著しい昨今、開発を請け負うメーカーやベンダだけではなく、発注元のユーザー企業が直接オフショア開発を試行するようになりました。日本の経済状況の悪化で、開発会社にプロジェクトを丸投げする“甘え体質”では、情報システム部門もやっていけなくなってきています。
いままでの日本企業は「海外発注の実績作り」に焦点を当ててきましたが、これからは、本来のプロジェクト目標達成を前提とした、オフショア開発が求められる時代になります。
オフショア開発というビジネスは、海外ベンダとの信頼関係の確立から始まります。特に最初の発注では、相手国の文化や特性、リスクを十分に考慮したプロジェクト計画が成功の鍵を握ります。
今回は見積もり交渉の事例紹介からオフショア開発の隠れたコスト要因を明らかにして、効果的なプロジェクト計画書の作り方と、スムーズにオフショア開発立ち上げを実現するアプローチを紹介します。
- 中国ベンダの見積もりは高過ぎるのか？
ある中堅ベンダで企画が進んでいる中国オフショア開発の事例を紹介します。社内のプロジェクト計画がまとまり、発注候補先の中国ベンダと最終的な見積もり交渉を行っていました。ところが、中国ベンダの回答にあった見積もり内訳書に目を通していると、隣に座っていたプロジェクトマネージャが渋い顔でこうつぶやきました。
「日本で詳細設計が完成しているのに、この見積もり工数は多過ぎませんか？」
コミュニケーションや見えない管理作業などのオーバーヘッドを考慮すると、国内開発と比べてオフショア開発の作業効率はかなり悪くなります。米調査会社META Groupは、「オフショア開発におけるコスト削減率は15％程度」とレポートしていますが、この数値は私の経験とも一致しています。
一般に、中国オフショア開発で要する作業工数は、すべて日本人が担当した場合と比較すると、1.5倍以上に膨れ上がります。オープンソースのソフトウェア部品を再利用するIT系アプリケーション開発であっても、やはり日本企業の予想をはるかに超える見積もり回答が多数を占めます。
「中国人はすぐにふっかけてくるので、架空の作業工程をでっち上げて実際よりも水増し請求をしてくるのではないか？」。あなたが、初めて中国ベンダと取引する担当者なら、このような不信感を抱くのはやむを得えないことかもしれません。
例えば、ある日本人にとってはシステム開発に含まれる「コーディング工程」には、単体テストが含まれます。しかし、別の中国人に聞くと、「コーディングと単体テストはまったく別作業だ」と言い切ります。さらに、「テスト結果をまとめて報告書を作成するドキュメント作業は、単体テスト工程には含まれない」とも主張します。いったい、どの考えが正しいのでしょうか。
これまでの国内開発では、発注側の常識や社内事情を一方的に下請企業に押し付けるスタイルがほとんどでした。ところが、オフショア開発では、従来の日本的な開発スタイルはまったく機能しないといっても過言ではありません。
なぜ、中国オフショア開発では、日本企業の予想よりも作業工数が増大するのでしょうか？ 「日本式開発スタイルの認識不足」が原因でしょうか。それとも「中国人プロジェクトマネージャの力量不足」に問題があるのでしょうか。確かに、それらの原因には一理あります。しかし、中国ベンダ側にも弁明の余地があります。ここでは、中国側の主張にも少し耳を傾けてみましょう。
中国では1人1人が明確に異なる作業工程を担当する
翻訳に手間取る
オフショア開発終了後に発生する保守費用の請求が難しい
まず、「1人1人が明確に異なる作業工程を担当する」を考えてみましょう。これはつまりこういうことです。一般の中国ベンダは「ドキュメント作成」が行える技術者と「実装、単体テスト」のみが行える技術者のレイヤを分けて対応します。これは、技術者の仕事の範囲、内容、どこまでが自己の考えや意思で仕事ができるかが、きちんと決まっていることに起因します。
中国企業では仕事内容、範囲、権限、責任が個人ごとに明確であり、仕事の成果は直接昇進や昇給と連動します。欧米の外資系企業がそうであるように、年齢、性別、社歴に関係なく仕事で結果を出した人が、きちんとリタ－ンを受けられるという常識が成り立つからです。
次に「翻訳に手間取る」について考えます。これは前述の1とも深く関連します。1人1人が明確に異なる作業工程を担当する、つまり「ドキュメント作成」と「実装、単体テスト」に別々の担当者を割り当てることは、翻訳の問題でも小さくありません。
日本語を母国語とする国内企業では、どちらの作業も同じ技術者で対応できるのですが、日本語レベルがまちまちな中国ベンダではそうはいきません。主要な中国ベンダでは、プログラマーの大半は大卒1～3年目の若手社員で占められるため、プログラマーまたはテスタは、まずドキュメント作成に携わらないと考えて間違いないでしょう。
3番目の「オフショア開発終了後に発生する保守費用の請求が難しい」についてはどうでしょうか。中国オフショア開発の見積もり工数が膨らむ要因の1つに、システムを納品した後の顧客対応、いわゆる「システム保守に相当する作業」に関する問題があります。
オフショア拠点からのシステム保守とは、電話やメール対応による即時性の高いサービスを想定しています。これまで説明してきたように、中国オフショア開発は、数少ない優秀なリーダを中心とした、典型的なピラミッド型のプロジェクトチームによって運営されています。
ところが、一般的な中国ベンダは、あるプロジェクトが完了したら、間を置かずに別のプロジェクトに技術者を投入する方針で経営されています。その理由は、技術者の稼働率が低下すると会社の資金繰りが悪化するだけではなく、優秀な技術者が転職してしまう恐れがあるからです。
従って、日本企業へ納品が済んだ直後に中国ベンダの担当者を呼び出そうとしても、「すでに別プロジェクトにアサインされました」と平然と回答されてしまいます。まだ「日本側の検収が済んでいない」にもかかわらず、このような事態が発生します。
一方で、何かトラブルが発生すると、運用側で原因を追究する努力を怠り、自動的に開発元に問い合わせる「日本型問題対応」と呼ばれる慣行にも問題があります。何時であっても、問題が発生したら迅速に対応すべきである、という過剰な顧客サービスが習慣化した結果だと推測されます。
さらに悪いことに、多くのオフショア開発では、「コスト削減」という大義名分が掲げられているため、開発委託契約とは別に保守契約を締結するケースはほとんど見られません。
このような背景から、中国ではオフショア開発の見積もりに「保守サービスの工数を上乗せする」という知恵が発達しました。中国ベンダの見積もり内容を評価する際には、この辺りの事情をよく理解して交渉に臨む必要があります。
リスクを考慮したプロジェクト計画を策定する
オフショア開発にはさまざまな形態がありますが、基本的には以下の流れに沿って進められます。今回は、特に立ち上げの段階で注意すべき点を整理します。
■中国オフショア開発の目標、範囲と前提条件を明確化する
- PR -
中国オフショア開発では、中期的な目標を詳細に打ち出し、当該プロジェクトの委託範囲や前提条件などを定め、プロジェクト計画書に記載します。中国オフショア開発に必要な条件はすべて明確に文書化することが第1のポイントです。
プロジェクト計画書は、社内だけで用いる形式的な帳票ではありません。開発委託契約を交わす前に、中国ベンダに対して十分に説明する義務があります。そして、双方が納得したうえでプロジェクトをスタートする方が望ましいでしょう。
（中国オフショア開発プロジェクト計画書の作成）
通常、中国オフショア開発の方針が決定してから実際に発注に至るまで、2カ月程度はかかります。ベンダ選定に手間取ると、その期間が半年以上になることも珍しくありません。その間は、発注元、契約や輸出手続きの管理部署、および中国オフショア開発コーディネータの3者で意識合わせを行うことにより、立ち上げ作業の円滑化を図ります。
発注対象となるプロジェクトの概要、開発技術、発注工程、阻害要因などを洗い出して、中国オフショア開発のプロジェクト計画書にまとめましょう。
プロジェクト計画書の内容 1. プロジェクト概要
2. 適用範囲と適用期間
3. スケジュール
4. 体制と役割分担
5. コミュニケーション計画
6. 品質計画
7. セキュリティ計画
8. サービスレベルの管理項目・管理指標
- オフショア開発をスムーズに立ち上げるアプローチ
■質問
中国ベンダから見積もり回答がありましたが、日本企業の感覚とは少し違うようです。どのように評価すればよいでしょうか？（東京都Nさん、ほか多数）
■回答
中国ベンダが作成した見積もり／スケジュールを評価する際には、必要な作業がすべて洗い出されているか、それらがスケジュールに反映されているかどうかを確認します。中国固有のコスト／工数の一覧表を作成して、中国ベンダと共同で漏れがないかどうかをチェックしてください。
●留意すべき中国オフショア開発固有のコスト
ブリッジSE／開発コーディネータ費用
中国側の開発環境構築費用
日本側技術者の訪中費用
仕様変更管理費用
●忘れがちな作業項目
納入ドキュメントや定型帳票のサンプル（記入凡例）の整備
Q＆A／レビューに迅速に対応するための日本側の体制構築
中国ベンダ教育工数
輸出管理工数
■解説
オフショア開発の委託先を「パートナーではなく格下の部品調達先」としてとらえていると、相手方が提示した見積もり／スケジュールを共同レビューするという発想は生まれないかもしれません。
正式発注前に共同レビューを必要とする背景には、現状の中国ベンダの見積もり能力は、日本企業と対等に議論する域に達していない、という考えがあります。中国オフショア開発では、長期的な取引の後で初めてコストメリットにありつけます。中国ベンダが妙な悪知恵を付ける前に、自社好みの契約方針を教え込んだ方が賢明だというわけです。
株式会社エス・キュー・シーの倉田克徳氏は、現在のオフショア開発は「グローバル・ソーシング・モデル」と呼ばれる『世界規模の調達モデル』に発展すると予想しています。そこは、従来の「お客さまvs.業者」といった枠組みを超えた新しい価値観が支配するマーケットです。先進的な欧米企業の一部は、グローバル・マーケットを見据えた戦略的な取り組みに着手しています。オフショア開発に活路を見いだす日本企業にとっては、また新しい挑戦が始まろうとしているのです。
関連記事
海外へのアウトソーシングの是非（＠IT自分戦略研究所 > 自分戦略研究室）
中国進出ブームの死角──逼迫するIT人材（＠IT情報マネジメント > 情報化戦略・投資）
幸地 司
アイコーチ有限会社
2004/11/12
--------------------------------------------------------------------------------
「コスト削減のためにオフショア開発を取り入れたものの、実際には納期と品質を確保するだけで精いっぱい」、このように訴える日本企業は多い。今回は、オフショア開発の隠れたコスト要因を明らかにして、効果的なプロジェクト計画書の作り方やスムーズなオフショア開発立ち上げを実現するアプローチを紹介する。（→記事要約
--------------------------------------------------------------------------------
- 日本の甘え体質では、やっていけなくなる
「トップはオフショア開発によるコスト削減をうたっているが、現場の感覚はまったく別だ。こちらとしては採算を度外視して、納期と品質を確保するだけで精いっぱいである」
ある大手メーカーに勤めるプロジェクトマネージャの話です。従来の日本企業は、ライバル会社に後れを取らないことを優先して、オフショア開発拠点の整備を急いできました。
- PR -
海外ベンダのレベルアップが著しい昨今、開発を請け負うメーカーやベンダだけではなく、発注元のユーザー企業が直接オフショア開発を試行するようになりました。日本の経済状況の悪化で、開発会社にプロジェクトを丸投げする“甘え体質”では、情報システム部門もやっていけなくなってきています。
いままでの日本企業は「海外発注の実績作り」に焦点を当ててきましたが、これからは、本来のプロジェクト目標達成を前提とした、オフショア開発が求められる時代になります。
オフショア開発というビジネスは、海外ベンダとの信頼関係の確立から始まります。特に最初の発注では、相手国の文化や特性、リスクを十分に考慮したプロジェクト計画が成功の鍵を握ります。
今回は見積もり交渉の事例紹介からオフショア開発の隠れたコスト要因を明らかにして、効果的なプロジェクト計画書の作り方と、スムーズにオフショア開発立ち上げを実現するアプローチを紹介します。
- 中国ベンダの見積もりは高過ぎるのか？
ある中堅ベンダで企画が進んでいる中国オフショア開発の事例を紹介します。社内のプロジェクト計画がまとまり、発注候補先の中国ベンダと最終的な見積もり交渉を行っていました。ところが、中国ベンダの回答にあった見積もり内訳書に目を通していると、隣に座っていたプロジェクトマネージャが渋い顔でこうつぶやきました。
「日本で詳細設計が完成しているのに、この見積もり工数は多過ぎませんか？」
コミュニケーションや見えない管理作業などのオーバーヘッドを考慮すると、国内開発と比べてオフショア開発の作業効率はかなり悪くなります。米調査会社META Groupは、「オフショア開発におけるコスト削減率は15％程度」とレポートしていますが、この数値は私の経験とも一致しています。
一般に、中国オフショア開発で要する作業工数は、すべて日本人が担当した場合と比較すると、1.5倍以上に膨れ上がります。オープンソースのソフトウェア部品を再利用するIT系アプリケーション開発であっても、やはり日本企業の予想をはるかに超える見積もり回答が多数を占めます。
「中国人はすぐにふっかけてくるので、架空の作業工程をでっち上げて実際よりも水増し請求をしてくるのではないか？」。あなたが、初めて中国ベンダと取引する担当者なら、このような不信感を抱くのはやむを得えないことかもしれません。
例えば、ある日本人にとってはシステム開発に含まれる「コーディング工程」には、単体テストが含まれます。しかし、別の中国人に聞くと、「コーディングと単体テストはまったく別作業だ」と言い切ります。さらに、「テスト結果をまとめて報告書を作成するドキュメント作業は、単体テスト工程には含まれない」とも主張します。いったい、どの考えが正しいのでしょうか。
これまでの国内開発では、発注側の常識や社内事情を一方的に下請企業に押し付けるスタイルがほとんどでした。ところが、オフショア開発では、従来の日本的な開発スタイルはまったく機能しないといっても過言ではありません。
なぜ、中国オフショア開発では、日本企業の予想よりも作業工数が増大するのでしょうか？ 「日本式開発スタイルの認識不足」が原因でしょうか。それとも「中国人プロジェクトマネージャの力量不足」に問題があるのでしょうか。確かに、それらの原因には一理あります。しかし、中国ベンダ側にも弁明の余地があります。ここでは、中国側の主張にも少し耳を傾けてみましょう。
中国では1人1人が明確に異なる作業工程を担当する
翻訳に手間取る
オフショア開発終了後に発生する保守費用の請求が難しい
まず、「1人1人が明確に異なる作業工程を担当する」を考えてみましょう。これはつまりこういうことです。一般の中国ベンダは「ドキュメント作成」が行える技術者と「実装、単体テスト」のみが行える技術者のレイヤを分けて対応します。これは、技術者の仕事の範囲、内容、どこまでが自己の考えや意思で仕事ができるかが、きちんと決まっていることに起因します。
中国企業では仕事内容、範囲、権限、責任が個人ごとに明確であり、仕事の成果は直接昇進や昇給と連動します。欧米の外資系企業がそうであるように、年齢、性別、社歴に関係なく仕事で結果を出した人が、きちんとリタ－ンを受けられるという常識が成り立つからです。
次に「翻訳に手間取る」について考えます。これは前述の1とも深く関連します。1人1人が明確に異なる作業工程を担当する、つまり「ドキュメント作成」と「実装、単体テスト」に別々の担当者を割り当てることは、翻訳の問題でも小さくありません。
日本語を母国語とする国内企業では、どちらの作業も同じ技術者で対応できるのですが、日本語レベルがまちまちな中国ベンダではそうはいきません。主要な中国ベンダでは、プログラマーの大半は大卒1～3年目の若手社員で占められるため、プログラマーまたはテスタは、まずドキュメント作成に携わらないと考えて間違いないでしょう。
3番目の「オフショア開発終了後に発生する保守費用の請求が難しい」についてはどうでしょうか。中国オフショア開発の見積もり工数が膨らむ要因の1つに、システムを納品した後の顧客対応、いわゆる「システム保守に相当する作業」に関する問題があります。
オフショア拠点からのシステム保守とは、電話やメール対応による即時性の高いサービスを想定しています。これまで説明してきたように、中国オフショア開発は、数少ない優秀なリーダを中心とした、典型的なピラミッド型のプロジェクトチームによって運営されています。
ところが、一般的な中国ベンダは、あるプロジェクトが完了したら、間を置かずに別のプロジェクトに技術者を投入する方針で経営されています。その理由は、技術者の稼働率が低下すると会社の資金繰りが悪化するだけではなく、優秀な技術者が転職してしまう恐れがあるからです。
従って、日本企業へ納品が済んだ直後に中国ベンダの担当者を呼び出そうとしても、「すでに別プロジェクトにアサインされました」と平然と回答されてしまいます。まだ「日本側の検収が済んでいない」にもかかわらず、このような事態が発生します。
一方で、何かトラブルが発生すると、運用側で原因を追究する努力を怠り、自動的に開発元に問い合わせる「日本型問題対応」と呼ばれる慣行にも問題があります。何時であっても、問題が発生したら迅速に対応すべきである、という過剰な顧客サービスが習慣化した結果だと推測されます。
さらに悪いことに、多くのオフショア開発では、「コスト削減」という大義名分が掲げられているため、開発委託契約とは別に保守契約を締結するケースはほとんど見られません。
このような背景から、中国ではオフショア開発の見積もりに「保守サービスの工数を上乗せする」という知恵が発達しました。中国ベンダの見積もり内容を評価する際には、この辺りの事情をよく理解して交渉に臨む必要があります。
リスクを考慮したプロジェクト計画を策定する
オフショア開発にはさまざまな形態がありますが、基本的には以下の流れに沿って進められます。今回は、特に立ち上げの段階で注意すべき点を整理します。
■中国オフショア開発の目標、範囲と前提条件を明確化する
- PR -
中国オフショア開発では、中期的な目標を詳細に打ち出し、当該プロジェクトの委託範囲や前提条件などを定め、プロジェクト計画書に記載します。中国オフショア開発に必要な条件はすべて明確に文書化することが第1のポイントです。
プロジェクト計画書は、社内だけで用いる形式的な帳票ではありません。開発委託契約を交わす前に、中国ベンダに対して十分に説明する義務があります。そして、双方が納得したうえでプロジェクトをスタートする方が望ましいでしょう。
（中国オフショア開発プロジェクト計画書の作成）
通常、中国オフショア開発の方針が決定してから実際に発注に至るまで、2カ月程度はかかります。ベンダ選定に手間取ると、その期間が半年以上になることも珍しくありません。その間は、発注元、契約や輸出手続きの管理部署、および中国オフショア開発コーディネータの3者で意識合わせを行うことにより、立ち上げ作業の円滑化を図ります。
発注対象となるプロジェクトの概要、開発技術、発注工程、阻害要因などを洗い出して、中国オフショア開発のプロジェクト計画書にまとめましょう。
プロジェクト計画書の内容 1. プロジェクト概要
2. 適用範囲と適用期間
3. スケジュール
4. 体制と役割分担
5. コミュニケーション計画
6. 品質計画
7. セキュリティ計画
8. サービスレベルの管理項目・管理指標
- オフショア開発をスムーズに立ち上げるアプローチ
■質問
中国ベンダから見積もり回答がありましたが、日本企業の感覚とは少し違うようです。どのように評価すればよいでしょうか？（東京都Nさん、ほか多数）
■回答
中国ベンダが作成した見積もり／スケジュールを評価する際には、必要な作業がすべて洗い出されているか、それらがスケジュールに反映されているかどうかを確認します。中国固有のコスト／工数の一覧表を作成して、中国ベンダと共同で漏れがないかどうかをチェックしてください。
●留意すべき中国オフショア開発固有のコスト
ブリッジSE／開発コーディネータ費用
中国側の開発環境構築費用
日本側技術者の訪中費用
仕様変更管理費用
●忘れがちな作業項目
納入ドキュメントや定型帳票のサンプル（記入凡例）の整備
Q＆A／レビューに迅速に対応するための日本側の体制構築
中国ベンダ教育工数
輸出管理工数
■解説
オフショア開発の委託先を「パートナーではなく格下の部品調達先」としてとらえていると、相手方が提示した見積もり／スケジュールを共同レビューするという発想は生まれないかもしれません。
正式発注前に共同レビューを必要とする背景には、現状の中国ベンダの見積もり能力は、日本企業と対等に議論する域に達していない、という考えがあります。中国オフショア開発では、長期的な取引の後で初めてコストメリットにありつけます。中国ベンダが妙な悪知恵を付ける前に、自社好みの契約方針を教え込んだ方が賢明だというわけです。
株式会社エス・キュー・シーの倉田克徳氏は、現在のオフショア開発は「グローバル・ソーシング・モデル」と呼ばれる『世界規模の調達モデル』に発展すると予想しています。そこは、従来の「お客さまvs.業者」といった枠組みを超えた新しい価値観が支配するマーケットです。先進的な欧米企業の一部は、グローバル・マーケットを見据えた戦略的な取り組みに着手しています。オフショア開発に活路を見いだす日本企業にとっては、また新しい挑戦が始まろうとしているのです。
関連記事
海外へのアウトソーシングの是非（＠IT自分戦略研究所 > 自分戦略研究室）
中国進出ブームの死角──逼迫するIT人材（＠IT情報マネジメント > 情報化戦略・投資）
第２回 中国オフショア開発の成功と失敗の実態
中国オフショア開発の成功と失敗の実態
幸地 司
アイコーチ有限会社
2004/10/13
--------------------------------------------------------------------------------
中国でのオフショア開発を成功させるためには、「『何を』達成すべきかという事業目的を明確にすることだ」と前回述べた。今回は実際に中国で体験した失敗例や、事例を研究して得た教訓などを紹介する。（→記事要約へ）
--------------------------------------------------------------------------------
- なぜ日本は中国で失敗し続けるのか？
なぜ多くの日本企業は、中国オフショア開発で失敗し続けるのでしょうか？
これまで日本企業はシステム開発に関して数ある選択肢の中から、中国オフショア開発を選択してきました。それが、今日のIT業界は私たちが好むと好まざるとにかかわらず、中国やインドなど海外IT企業との共存が必要不可欠になってきています。日本企業の担当者が中国渡航しなくても、彼らの方から日本に押し寄せて、日本語で立派なプレゼンテーションを披露する時代になりました。
- 事例から原因を研究する
■不信感だらけのソースコードレビュー
ある中国オフショア開発プロジェクトの検収結果が届きました。いくつかのバグが見つかったため、残念ながら一発では検収が通りませんでした。よく調べてみると、コーディング規約に従ってないソースコードの書き方も若干あります。ソースコードレビューは何回もしていたはずなのに……。
日本企業の開発コーディネータ（以下、日本）は、バグの原因を探り、再発防止に努めなくてはいけません。開発コーディネータと中国ベンダの開発リーダー（以下、中国）は、以下のような会話をしています。
日本 「中国側のソースコードレビューはどうなっているのですか？ 先日報告されたソースコードレビューの報告書を読みましたが、何をどのようにレビューしたのか、よく理解できませんでした」
中国 「ソースコードレビューで重点を置くのは、コーディング規約の確認です。ソースコードレビューは、別部署のリーダーである李さんに応援してもらい、既に3回も実施しました。李さんは、当社でも特に技術力に優れている人物です」
ところが、中国側の報告内容には次のような不信な点があります。
ツールを使ってコーディング規約をチェックしているのに、なぜか規約違反がある
ソースコードレビュー会議で発言したのは、なぜか李さん1人しかいない
日本人の開発コーディネータは、ソースコードレビューの形骸化を懸念しています。ソースコードを1行ずつ丹念にチェックする根気強さが、中国側には不足していると感じています。実際、検収は一発では通りませんでした。そこで、開発コーディネータは中国側リーダーに対して、ソースコードレビューを再度実施するように指示します。ところが、中国側の回答は意外な内容でした。
日本 「コーディング規約を準拠しているかを再度見直すとともに、机上でのデバッグをもう1度実施してください」
中国 「ご要望は分かりました。しかし、机上でのデバッグですが、その作業工数は非常に多いと思います。通常、当社では実施しません。紙の上でソースコードを追いながら要求仕様を確認する方法などは、コーディングやり直しと実質的に変わりません。要求仕様の確認は、PC画面上からのテストで検証するものです。本当に必要でしょうか？」
さらにこう続けます。
中国 「検収で見つかったバグはもうすぐ修正されるので、プログラムは安定稼動します。したがって、わざわざ追加費用をかけてもう1度ソースコードレビューを実施しても、その効果には疑問があります。もし、机上のレビューだけですべてのバグは防止できるとなると、バグ摘出目標を上げる品質指標値の意味がないですね」
その言い分は理解できますが、開発コーディネータはどうしても納得できません。日本側が反論する前に、中国ベンダのリーダーはさらに追い討ちをかけます。
中国 「当社の方針では、最も重要なのは納期を守ること、そして品質を確保することです。品質保証はプログラムの動作確認テストが効果的です。画面上から動作確認するテストが最も優れていると思います。
テスト項目を増やし、何度も繰り返してテストするとバグ摘出率は高くなります。ソースコードの仕様チェックの概念はいいと思いますが、効率は良くないのではないでしょうか。例えば、あるプログラムを1時間かけてテストすると、効率よくバグが発見できるでしょう。
ところが、机上でのデバッグとなると、レビュー者と担当プログラマが2人で一緒にソースコードレビューしなければなりません。2人で半日かけてレビューしても、バグの発見は難しいのではないでしょうか。
また今回のプログラムには、複雑な計算アルゴリズムなどはありませんから、その観点での机上でのデバッグは必要ないと思います。
従って、当社としては動作確認テストを優先し、もし時間に余裕があれば、後からソースコードの仕様チェックを行う。これでよろしいでしょうか？」
以上が、中国オフショア開発の一例です。
中国オフショア開発の教訓
■教訓「報告をうのみにした開発コーディネータ」
- PR -
中国ビジネスで日本人が成功できない理由の1つとして、「相手を信じ過ぎる」ことが原因というのが定説となっています。中国オフショア開発では、「すべて確認しました。もう大丈夫です！」などの作業報告をうのみにする事象が当てはまります。
オフショア開発で成功する企業には、相手国の文化やコミュニケーションの傾向を察知する目の肥えたコーディネータが欠かせません。“目の肥えた”コーディネータとは、失敗事例から教訓を得て、日本流のプロジェクトマネジメントとオフショア開発委託先の企業文化を見事に融合させることができる人物です。
■教訓「経験不足のうえに土俵が異なるようでは、成功はおぼつかない」
中国ベンダでは、20代後半から30代の若手SEが、主に全体の統括リーダーを務めています。大半のリーダーは技術的に優れているのですが、やはりコミュニケーションに不安が残ります。納品したシステムに重大なバグが見つかるなど何か問題が生じたとき、日本から厳重に抗議しても、その重大性がベンダ幹部に報告されないことがあります。
中国ベンダ社内で情報が伝わらないのは、主として情報管理体制の甘さから来るものですが、同じくらい重大な理由として技術者の気質の問題が考えられます。ただし、中国人は品質意識が低いとか、頭が悪いとか、そういう次元ではありません。単に、日本流のきめ細かな報告・連絡・相談の経験が、決定的に不足しているからだといえるでしょう。
今回取り上げた事例では、中国のレビューに対する考え方が日本の教科書的な考え方とは根本的に異なることを示しています。
日本 中国
ソースコードレビューの目的 要求仕様との整合性などあらゆる面から、ソースコードの細部までを厳密にチェックすること コーディング規約やプログラミング技法の指導や確認
アプローチ ボトムアップ的な改善 トップダウン的な指示
レビュー実施者 関係者全員 理解している者1人
レビュー指摘事項の周知方法 みんなで頭を突き合わせて検討するので、その場で関係者全員に周知 有識者が1人でレビューした結果を、後からおのおのの担当者に伝達。指摘事項が全体で共有されることはない
以上の教訓を踏まえて、この失敗例への対策を次のように整理しました。
日本流の開発プロセスの指導強化
結果報告をうのみにせず、プロセスの実施状況をしっかりと確認
その他の事例では
そのほか、中国オフショア開発の失敗例をまとめました。
■中国オフショア開発の失敗例
上流工程から任せてほしいというベンダの主張を受け入れ基本設計から委託したが、実際には最初から最後まで日本人技術者が中国に常駐しており、コスト削減の効果はほとんどなかった。
契約締結時にベンダへ自社の開発標準マニュアルを提供した。ところが、いざふたを開けてみると、マニュアルは十数年前に制定されたレガシーシステム開発を対象とした内容であり、オープン系開発ではまったく役に立たなかった。
試験発注の小規模プロジェクトで成功したので、次は本格的に大規模プロジェクトを発注した。ところが、前回担当したプロジェクトリーダーはすでに離職しており、また最初から説明をし直すことになった。
ベンダとの契約交渉時に、過去プロジェクトで用いたドキュメントのサンプルを見せてほしいと依頼したら、顧客名が記載された設計ドキュメントのコピーをそのまま提示してきた。機密保持の意識がまったくないようだ。
大連のあるベンダは、日本語のできる社員が豊富に在籍しているといううたい文句であったが、実際には同じ人物が異なる名義を使って複数の顧客に対してそれぞれメールを出していることが判明した。
中国ベンダから技術者を日本に招聘（しょうへい）したが、社内の中国人留学生のアルバイト時給を知り、自分の給与水準と比較して不満を外に吐き散らすようになった。やがてモチベーションが低下した彼は、プロジェクト全体の和を乱し、プロジェクト半ばで強制的に帰国させられた。その後、彼はすぐに別の会社に転職したらしい。
仕様変更が発生したので専用の連絡票を使って詳しく説明したところ、「了解しました」との回答が得られたので安心していた。ところが、随分後になってプログラムが修正されていないことが発覚。それをバグ（修正漏れ）だと抗議したが、中国ベンダは真っ向から反論してきた。「当時は連絡票で説明を受けたが、正式に仕様書が修正されていない。だから仕様変更の依頼は受け付けていない」。
日本企業側で、若い人に国際感覚を持たせたいと称して、語学はおろか、基本的なプロジェクトマネジメント知識すら不足している社員をオフショア開発の交渉窓口に就けた。ところが、自分より能力のないものに対して、中国人は反抗的な態度を取ることがある。案の定、中国ベンダは若手社員のいうことを聞かなくなり、プロジェクトは破綻した。
■中国オフショア開発の成功例
もちろん、中国オフショア開発には次のような成功事例も数多くあります。
業務アプリケーション開発や組み込みアプリケーション開発など、さまざまな分野での原価削減、およびプロジェクト損益の改善に寄与
中国人を意識することで、仕様書や設計力が向上
中国ベンダに指導することで、自社のベンダ管理能力が向上
オフショア開発の機会を通して国際感覚を磨き、海外進出の足掛かりとする
お刺し身文化と麻婆豆腐文化
先日、都内のある中国人社長から聞いた、日中両国の文化の違いをよく表す例え話を紹介します。
日本式文化：「お刺し身文化」
日本はお刺し身文化です。
お刺し身とは、説明するまでもなく生魚の切り身ですが、この調理法は恐らく何千年も前から日本に存在していたでしょう。21世紀になった現代でも、北海道から沖縄まで全国どこであっても、基本的な味や形は変わりません。もちろん海外であっても、魚の種類は違えどもお刺し身は依然としてお刺し身の味がします。お刺し身の一部は、芸術の域にまで達しています。
中国文化：「麻婆豆腐文化」
一方、中国は麻婆豆腐文化です。
本場四川省では想像を絶するほど辛いのは有名な話。ところが、北京では味が随分まろやかになりますし、東京ではまったく味がしないと不満を漏らす中国人がいるほど。つまり、麻婆豆腐は地域、あるいはその土地の人々の好みに合わせて辛さがまったく異なります。
- PR -
面白いことに、麻婆豆腐は偶然の産物だとする説が有力です（麻婆豆腐の起源には諸説あり）。さらに、中国四川省では豆腐ですら偶然から生まれたという話を聞いたことがあります。なんとも「いいかげん」な料理です。
この例え話には、中国オフショア開発の重要な鍵が示唆されています。規律・過程・美徳を重んじる日本人、臨機応変を好み結果重視の中国人。麻婆豆腐文化の中国は、ずさんな品質管理を露呈する一方で、日本でも難しいロケット打ち上げに成功するほどの高度な技術力を持ちます。目的を理解し、視覚化された適切な目標があれば、ソフトウェア分野でも正確で高度な仕事を遂行するでしょう。
読者の中には、前半に紹介した失敗事例と似たような体験をされた方が大勢いるでしょう。でも、失敗を経験したからといって、中国ベンダは品質意識に乏しいソフトウェア開発後進国だと判断するのは感心できません。それは、私たちのお刺し身文化的な均一した価値観にすぎないのです。
大切なのは、日本と中国が同じ土俵で議論することです。誰でも分かる客観的なデータを用意して、納得のいくまで議論します。ソフトウェア分野のプロジェクトマネジメントにおいては日本に一日の長があるので、必要なことは遠慮せずにどんどん要求しましょう。出来上がった最終結果だけではなく、開発プロセスが正しく実施されているかどうかの途中確認はオフショア開発の成功を左右する重要な鍵となります。
このような相互確認を怠らなければ、過去の多くの失敗を未然に防げたに違いありません。今後の皆さまの検討をお祈り申し上げます。
幸地 司
アイコーチ有限会社
2004/10/13
--------------------------------------------------------------------------------
中国でのオフショア開発を成功させるためには、「『何を』達成すべきかという事業目的を明確にすることだ」と前回述べた。今回は実際に中国で体験した失敗例や、事例を研究して得た教訓などを紹介する。（→記事要約
--------------------------------------------------------------------------------
- なぜ日本は中国で失敗し続けるのか？
なぜ多くの日本企業は、中国オフショア開発で失敗し続けるのでしょうか？
これまで日本企業はシステム開発に関して数ある選択肢の中から、中国オフショア開発を選択してきました。それが、今日のIT業界は私たちが好むと好まざるとにかかわらず、中国やインドなど海外IT企業との共存が必要不可欠になってきています。日本企業の担当者が中国渡航しなくても、彼らの方から日本に押し寄せて、日本語で立派なプレゼンテーションを披露する時代になりました。
- 事例から原因を研究する
■不信感だらけのソースコードレビュー
ある中国オフショア開発プロジェクトの検収結果が届きました。いくつかのバグが見つかったため、残念ながら一発では検収が通りませんでした。よく調べてみると、コーディング規約に従ってないソースコードの書き方も若干あります。ソースコードレビューは何回もしていたはずなのに……。
日本企業の開発コーディネータ（以下、日本）は、バグの原因を探り、再発防止に努めなくてはいけません。開発コーディネータと中国ベンダの開発リーダー（以下、中国）は、以下のような会話をしています。
日本 「中国側のソースコードレビューはどうなっているのですか？ 先日報告されたソースコードレビューの報告書を読みましたが、何をどのようにレビューしたのか、よく理解できませんでした」
中国 「ソースコードレビューで重点を置くのは、コーディング規約の確認です。ソースコードレビューは、別部署のリーダーである李さんに応援してもらい、既に3回も実施しました。李さんは、当社でも特に技術力に優れている人物です」
ところが、中国側の報告内容には次のような不信な点があります。
ツールを使ってコーディング規約をチェックしているのに、なぜか規約違反がある
ソースコードレビュー会議で発言したのは、なぜか李さん1人しかいない
日本人の開発コーディネータは、ソースコードレビューの形骸化を懸念しています。ソースコードを1行ずつ丹念にチェックする根気強さが、中国側には不足していると感じています。実際、検収は一発では通りませんでした。そこで、開発コーディネータは中国側リーダーに対して、ソースコードレビューを再度実施するように指示します。ところが、中国側の回答は意外な内容でした。
日本 「コーディング規約を準拠しているかを再度見直すとともに、机上でのデバッグをもう1度実施してください」
中国 「ご要望は分かりました。しかし、机上でのデバッグですが、その作業工数は非常に多いと思います。通常、当社では実施しません。紙の上でソースコードを追いながら要求仕様を確認する方法などは、コーディングやり直しと実質的に変わりません。要求仕様の確認は、PC画面上からのテストで検証するものです。本当に必要でしょうか？」
さらにこう続けます。
中国 「検収で見つかったバグはもうすぐ修正されるので、プログラムは安定稼動します。したがって、わざわざ追加費用をかけてもう1度ソースコードレビューを実施しても、その効果には疑問があります。もし、机上のレビューだけですべてのバグは防止できるとなると、バグ摘出目標を上げる品質指標値の意味がないですね」
その言い分は理解できますが、開発コーディネータはどうしても納得できません。日本側が反論する前に、中国ベンダのリーダーはさらに追い討ちをかけます。
中国 「当社の方針では、最も重要なのは納期を守ること、そして品質を確保することです。品質保証はプログラムの動作確認テストが効果的です。画面上から動作確認するテストが最も優れていると思います。
テスト項目を増やし、何度も繰り返してテストするとバグ摘出率は高くなります。ソースコードの仕様チェックの概念はいいと思いますが、効率は良くないのではないでしょうか。例えば、あるプログラムを1時間かけてテストすると、効率よくバグが発見できるでしょう。
ところが、机上でのデバッグとなると、レビュー者と担当プログラマが2人で一緒にソースコードレビューしなければなりません。2人で半日かけてレビューしても、バグの発見は難しいのではないでしょうか。
また今回のプログラムには、複雑な計算アルゴリズムなどはありませんから、その観点での机上でのデバッグは必要ないと思います。
従って、当社としては動作確認テストを優先し、もし時間に余裕があれば、後からソースコードの仕様チェックを行う。これでよろしいでしょうか？」
以上が、中国オフショア開発の一例です。
中国オフショア開発の教訓
■教訓「報告をうのみにした開発コーディネータ」
- PR -
中国ビジネスで日本人が成功できない理由の1つとして、「相手を信じ過ぎる」ことが原因というのが定説となっています。中国オフショア開発では、「すべて確認しました。もう大丈夫です！」などの作業報告をうのみにする事象が当てはまります。
オフショア開発で成功する企業には、相手国の文化やコミュニケーションの傾向を察知する目の肥えたコーディネータが欠かせません。“目の肥えた”コーディネータとは、失敗事例から教訓を得て、日本流のプロジェクトマネジメントとオフショア開発委託先の企業文化を見事に融合させることができる人物です。
■教訓「経験不足のうえに土俵が異なるようでは、成功はおぼつかない」
中国ベンダでは、20代後半から30代の若手SEが、主に全体の統括リーダーを務めています。大半のリーダーは技術的に優れているのですが、やはりコミュニケーションに不安が残ります。納品したシステムに重大なバグが見つかるなど何か問題が生じたとき、日本から厳重に抗議しても、その重大性がベンダ幹部に報告されないことがあります。
中国ベンダ社内で情報が伝わらないのは、主として情報管理体制の甘さから来るものですが、同じくらい重大な理由として技術者の気質の問題が考えられます。ただし、中国人は品質意識が低いとか、頭が悪いとか、そういう次元ではありません。単に、日本流のきめ細かな報告・連絡・相談の経験が、決定的に不足しているからだといえるでしょう。
今回取り上げた事例では、中国のレビューに対する考え方が日本の教科書的な考え方とは根本的に異なることを示しています。
日本 中国
ソースコードレビューの目的 要求仕様との整合性などあらゆる面から、ソースコードの細部までを厳密にチェックすること コーディング規約やプログラミング技法の指導や確認
アプローチ ボトムアップ的な改善 トップダウン的な指示
レビュー実施者 関係者全員 理解している者1人
レビュー指摘事項の周知方法 みんなで頭を突き合わせて検討するので、その場で関係者全員に周知 有識者が1人でレビューした結果を、後からおのおのの担当者に伝達。指摘事項が全体で共有されることはない
以上の教訓を踏まえて、この失敗例への対策を次のように整理しました。
日本流の開発プロセスの指導強化
結果報告をうのみにせず、プロセスの実施状況をしっかりと確認
その他の事例では
そのほか、中国オフショア開発の失敗例をまとめました。
■中国オフショア開発の失敗例
上流工程から任せてほしいというベンダの主張を受け入れ基本設計から委託したが、実際には最初から最後まで日本人技術者が中国に常駐しており、コスト削減の効果はほとんどなかった。
契約締結時にベンダへ自社の開発標準マニュアルを提供した。ところが、いざふたを開けてみると、マニュアルは十数年前に制定されたレガシーシステム開発を対象とした内容であり、オープン系開発ではまったく役に立たなかった。
試験発注の小規模プロジェクトで成功したので、次は本格的に大規模プロジェクトを発注した。ところが、前回担当したプロジェクトリーダーはすでに離職しており、また最初から説明をし直すことになった。
ベンダとの契約交渉時に、過去プロジェクトで用いたドキュメントのサンプルを見せてほしいと依頼したら、顧客名が記載された設計ドキュメントのコピーをそのまま提示してきた。機密保持の意識がまったくないようだ。
大連のあるベンダは、日本語のできる社員が豊富に在籍しているといううたい文句であったが、実際には同じ人物が異なる名義を使って複数の顧客に対してそれぞれメールを出していることが判明した。
中国ベンダから技術者を日本に招聘（しょうへい）したが、社内の中国人留学生のアルバイト時給を知り、自分の給与水準と比較して不満を外に吐き散らすようになった。やがてモチベーションが低下した彼は、プロジェクト全体の和を乱し、プロジェクト半ばで強制的に帰国させられた。その後、彼はすぐに別の会社に転職したらしい。
仕様変更が発生したので専用の連絡票を使って詳しく説明したところ、「了解しました」との回答が得られたので安心していた。ところが、随分後になってプログラムが修正されていないことが発覚。それをバグ（修正漏れ）だと抗議したが、中国ベンダは真っ向から反論してきた。「当時は連絡票で説明を受けたが、正式に仕様書が修正されていない。だから仕様変更の依頼は受け付けていない」。
日本企業側で、若い人に国際感覚を持たせたいと称して、語学はおろか、基本的なプロジェクトマネジメント知識すら不足している社員をオフショア開発の交渉窓口に就けた。ところが、自分より能力のないものに対して、中国人は反抗的な態度を取ることがある。案の定、中国ベンダは若手社員のいうことを聞かなくなり、プロジェクトは破綻した。
■中国オフショア開発の成功例
もちろん、中国オフショア開発には次のような成功事例も数多くあります。
業務アプリケーション開発や組み込みアプリケーション開発など、さまざまな分野での原価削減、およびプロジェクト損益の改善に寄与
中国人を意識することで、仕様書や設計力が向上
中国ベンダに指導することで、自社のベンダ管理能力が向上
オフショア開発の機会を通して国際感覚を磨き、海外進出の足掛かりとする
お刺し身文化と麻婆豆腐文化
先日、都内のある中国人社長から聞いた、日中両国の文化の違いをよく表す例え話を紹介します。
日本式文化：「お刺し身文化」
日本はお刺し身文化です。
お刺し身とは、説明するまでもなく生魚の切り身ですが、この調理法は恐らく何千年も前から日本に存在していたでしょう。21世紀になった現代でも、北海道から沖縄まで全国どこであっても、基本的な味や形は変わりません。もちろん海外であっても、魚の種類は違えどもお刺し身は依然としてお刺し身の味がします。お刺し身の一部は、芸術の域にまで達しています。
中国文化：「麻婆豆腐文化」
一方、中国は麻婆豆腐文化です。
本場四川省では想像を絶するほど辛いのは有名な話。ところが、北京では味が随分まろやかになりますし、東京ではまったく味がしないと不満を漏らす中国人がいるほど。つまり、麻婆豆腐は地域、あるいはその土地の人々の好みに合わせて辛さがまったく異なります。
- PR -
面白いことに、麻婆豆腐は偶然の産物だとする説が有力です（麻婆豆腐の起源には諸説あり）。さらに、中国四川省では豆腐ですら偶然から生まれたという話を聞いたことがあります。なんとも「いいかげん」な料理です。
この例え話には、中国オフショア開発の重要な鍵が示唆されています。規律・過程・美徳を重んじる日本人、臨機応変を好み結果重視の中国人。麻婆豆腐文化の中国は、ずさんな品質管理を露呈する一方で、日本でも難しいロケット打ち上げに成功するほどの高度な技術力を持ちます。目的を理解し、視覚化された適切な目標があれば、ソフトウェア分野でも正確で高度な仕事を遂行するでしょう。
読者の中には、前半に紹介した失敗事例と似たような体験をされた方が大勢いるでしょう。でも、失敗を経験したからといって、中国ベンダは品質意識に乏しいソフトウェア開発後進国だと判断するのは感心できません。それは、私たちのお刺し身文化的な均一した価値観にすぎないのです。
大切なのは、日本と中国が同じ土俵で議論することです。誰でも分かる客観的なデータを用意して、納得のいくまで議論します。ソフトウェア分野のプロジェクトマネジメントにおいては日本に一日の長があるので、必要なことは遠慮せずにどんどん要求しましょう。出来上がった最終結果だけではなく、開発プロセスが正しく実施されているかどうかの途中確認はオフショア開発の成功を左右する重要な鍵となります。
このような相互確認を怠らなければ、過去の多くの失敗を未然に防げたに違いありません。今後の皆さまの検討をお祈り申し上げます。
第1回 中国ソフトウェア業界の実力とオフショア開発の勘所
http://www.atmarkit.co.jp/fbiz/cstaff/serial/offshore/01/01.html
第1回 中国ソフトウェア業界の実力とオフショア開発の勘所
幸地 司
アイコーチ有限会社
2004/9/14
--------------------------------------------------------------------------------
「オフショア開発」という言葉がよく聞かれるようになってきた。オフショア開発に取り組み、成功したという事例が伝えられる一方、失敗・苦闘の話も漏れ聞く。オフショア開発を成功に導く“コーディネータ”とはどのような存在だろうか？（→記事要約へ）
--------------------------------------------------------------------------------
- 選択の余地がない中国シフト
ある日、あなたに対して会社の経営陣から次のような通達がありました。
「今年度のIT投資予算のうち、20％を中国オフショア開発で実施することが決まった。そこで、キミが抱えている案件の一部を中国に発注したい。直ちに準備するように」
- PR -
今日、会社トップからの指令で、案件の選定がなされるより先に中国オフショア開発の実施が決まっていることがあります。いったん方針が打ち出されると、情報マネージャの意思にかかわらず、青写真だけを頼りに話が進められることもしばしばです。ある日、あなたの案件が突然オフショア開発の対象となるわけです。今後はこのようなことが増えてくるかもしれません。誰も人事（ひとごと）だと笑えない時代になってきました。
この連載記事は、企業の情報化推進プロジェクトに責任を持つ情報マネージャ、あるいは実際の開発現場で常に泥沼のデスマーチに巻き込まれるシステムインテグレータのSEマネージャを対象に企画されたものです。
中国オフショア開発は、いつわが身に降りかかってくるか誰も予想がつきません。本連載記事では、えりすぐりの旬のテーマを中心に、現場でいますぐに役立つ情報が入手できるよう配慮されています。これまで、担当者や特定企業の勘や暗黙知に頼ることの多かった中国オフショア開発の成功の秘訣やスタッフ育成の鍵を分かりやすく全6回に分けて連載します。
ここから学んだことを活用して、ご自身の手でITサービス提供者のプロフェッショナル集団を形成していただければ幸いです。
- オフショア開発の状況
■海外拠点で開発すること
ところで、読者の中には「中国オフショア開発って何？」と疑問に思われる方がいらっしゃるかもしれません。オフショア開発とは何でしょうか？
平たくいうと、オフショア開発とは国内のソフトウェア開発を海外拠点に委託することです。具体的には、オフショア開発の主な受注先としてはインドや中国の企業が挙げられます。ほかにも、韓国やフィリピン、ロシア、東欧諸国などへもオフショア開発が展開されています。
オフショア開発の最大の魅力は、何といっても大幅な原価削減が期待できること。これまでは、システムインテグレータが先駆けとなって、オフショア開発の開拓を担ってきましたが、これからは情報システム部門が自ら海外に乗り出すケースも増えるでしょう。
先行する一部の企業では、海外で採用した現地社員の能力不足が露呈するなど、納期や品質に関するトラブルが少なくありません。それでも、オフショア開発にはこれらの困難を補って余りあるほどの可能性があるわけで、これからも海外拠点の充実がますます加速されていくことでしょう。
■欧米諸国はいち早くBPR／BPOを模索
オフショア開発は、米国を中心とする欧米諸国を発祥とします。もともとは、経費削減などのコストメリットに関係者の注目が集まっていましたが、近年では抜本的な業務改革（BPR／BPO）を伴う新しいビジネス形態として期待されています。米調査会社のMETA Groupによると、オフショア開発は今後2年間20～25％増で成長するとされています。
アジアパシフィックにおいては、特に中国大連の発展が目覚ましく、今後の動向から目を離せない状況にあります。
■日本ではインドと中国が人気を二分
このように、オフショア開発は世界各国で実施されていますが、わが国においてはどのような状況でしょうか。IT業界では、技術や経済の変化によってさまざまなブームが到来しますが、オフショア開発の分野ではインドと中国がその人気を二分しています。
近年では、沖縄県の有利なIT産業振興施策を活用したITアウトソーシングも盛んに展開されています。沖縄では、東京―沖縄間で実施されるソフトウェア分散開発のことも、オフショア開発と呼びます。
中国、インド、あるいは沖縄で繰り広げられるオフショア開発では、プロジェクトの立ち上げから完了までの間に、実にさまざまなドラマがあります。
「オフショア開発への対応は、開発部門だけに任せるべき課題ではない」
「従来の古い開発標準を改めて、UMLを採用したスパイラル型開発モデルを検討せよ」
「品質が約束されない限り、プロジェクトリーダーとしては海外発注を認めない」
「オフショア開発を特別に恐れることはない。本来の正しいシステム開発を実践すれば相手が外国企業であろうともきっと成功するはずだ」
最近、日常的にオフショア開発に関するうわさを耳にします。日本におけるオフショア開発の歴史はまだ浅く、こと中国に関しては、まだ手探りの状態といっていいでしょう。一部からは、中国オフショア開発を悲観する声が聞かれますが、他方数は少ないですが中国オフショア開発の成功事例も出始めています。
このような状況を踏まえて、本連載では主に中国オフショア開発に特化した記事をお届けします。
中国オフショア開発の可能性と問題点
■中国オフショア開発の可能性
- PR -
ここからは、日本企業にとっての中国オフショア開発に特化して話を進めます。
まず、中国ITアウトソーシング全般について考えてみましょう。中国へのアウトソーシングビジネスは、大きく2種類に大別されます。
技術者派遣モデル
サービスプロバイダ・モデル
技術者派遣モデルとは、技術者1人当たりの人月単価を定めて、一定期間確保する業種です。研究室のように一定の技術者を確保することから「ラボ」とも呼ばれます。一方、サービスプロバイダ・モデルとは、受託開発や保守運用、さらには付加価値の高い業務サービスを提供する業種のことを指します。現在のサービスプロバイダ・モデルでは、次のような業務が対象となります。
フルアウトソーシングサービス
総務／人事サービス
テクニカルサービス
調査会社
ロジスティクスサービス
コールセンターサービス
……ほか
一般に日本企業になじみが深いのは、前者の技術者派遣モデルです。
しかしながら、現在の中国ソフトウェア業界の人材分布をかんがみると、“均一な人材”を大量に要する対日ITアウトソーシング業務が確立されるのは、もう少し時間がかかりそうな気がします。なぜなら、中国ベンダが一丸となってプロジェクトを推進するには、まだ個人の協調性が成熟しているとはいい難いからです。
その一方で、サービスプロバイダ・モデルは魅力があります。このモデルは、少数精鋭のリーダー層と普通の保守運用要員の組み合わせでも十分に運営が成り立つからです。実際、欧米やインドでは、こちらの方が主流になっています。しばらくは、中国市場の動向に歩調を合わせながら着実に成長を続けるでしょう。
コラム
総務／人事に関するサービスプロバイダ・モデルの事例を1つ紹介します。
2004年7月、人事・給与パッケージで有名なワークスアプリケーションズは、中国系企業とパートナーシップを結び、中国大連にBPO（ビジネスプロセス・アウトソーシング）とASPサービスを提供する合弁会社を設立しました。生産拠点の中国移転に伴い、生産管理ソフトベンダが中国進出する例はよく耳にします。ところが、人事・給与パッケージベンダの中国進出は珍しいといえるでしょう。BPOは大連を中心に盛り上がっており、同社の初年度販売目標は3億円で、5年後に100億円以上を目指しています。なお、この分野では外資系企業が先行しています。
一足先に中国進出を果たした製造業では、国際的なサプライチェーン・マネジメントシステムを軸にして、経済レベルの上位国でルール作りを行い、下位国では生産を行いつつマーケットを形成していくことが成長モデルとなっています。
将来的には、わが国のソフトウェア業界でも、単純な受託案件を中国オフショアで開発するだけではなく、自社製品を中国市場で販売したり、他製品と連携させるなどさまざまな可能性を探りながら展開していくべきでしょう。
■中国オフショア開発の問題点
大規模プロジェクトを通じて大幅な原価削減を図る際には、中国オフショア開発は大きな魅力があります。しかし、単に費用削減を狙った中国オフショア開発では、期待どおりの効果が上がらないこともあります。
近年、加熱気味の中国シフトに対して、各方面からさまざまな警告がなされています。最悪の場合、中国人社員の定着率の悪さから、事業継続が困難になるという事態が発生します。以下に代表的な問題点を4つ挙げます。
セキュリティや知的財産の侵害
納期遅延、開発予算超過
言葉や文化の違いによる感情のあつれき
生産性の著しい低下
日本企業の取り組み
■中国オフショア開発をちゅうちょする声
最近では、中国オフショア開発を重要な経営戦略の一環として認識して、企業トップが自らその推進に当たる会社が増えています。しかしながら、関係者の多くは、中国オフショア開発への疑問を抱きつつ、仕方なくトップに追随しているように感じられます。
- PR -
欧米の顧客がソフトウェア開発を国外に委託するのは、海外の安い人材を利用して本国のソフトウェアパッケージ製品に生かすのが主な目的です。それに加えて、一般的なソフトウェアの委託開発と異なり、完成した製品の知的財産権は顧客にあるのも魅力の1つだといわれてきました。これにより、欧米企業では、社員1人1人がオフショア開発の利益を十分に理解したうえで行動してきたといわれます。
ところが、国内のオフショア開発関係者は上記とは違った意見を持ちます。
「何度も何度もやりとりをして要件を伝えたのに、出来上がったものは想像したものと少しずれてしまう」
「バグを直しても、直しても、少しだけ残ってしまう」
「拡張性、移植性、セキュリティ面の考慮が足りないまま、完成させてしまう」
はっきりいって、「分かっちゃいるけどオフショア開発はご勘弁」というのが現場を預かる情報マネージャの本音です。オフショア開発推進チームのモチベーションが上がらない原因の1つがここにあります。
■エンジニアのいい分
日本企業が社内で最初に中国オフショア開発の可能性を検討する際、一般には組織横断的な人事を断行し、複数の部署から人をかき集めて専門の検討チームを結成します。ところが実際には、専任で中国オフショア開発の推進を担う者は少なく、ほとんどは元の部署の“本業”と兼務しています。つまり、忙しい間を縫って“片手間”で対応することになります。
このような状況下でオフショア開発推進の会議を開催しても、参加者から発せられる言葉は少し寂しいものになってしまいます。
「例の○×案件がトラブって、社内アンケートを集計する時間がありませんでした」
「雑誌◇△のコピーをお配りします」（自分は動かず、コピー資料を配布するだけ）
でも、彼らは決して保身のために中国オフショア開発を避けているのではありません。自分が楽をするために情報マネージャの仕事を邪魔したいわけでもありません。
彼らは日常の運用業務を滞らせるわけにはいきませんし、お客が望む最高のサービスを提供するよう常に心掛けています。情報システム部門の性質上、自分たちが提供するITサービスの品質を一定以上に保つためのリスクヘッジは絶対に欠かせません。そのエンジニア魂が結果としてオフショア開発推進の抵抗勢力となってしまうのです。
こんなときに、中国オフショア開発の重要性を認識している情報マネージャは、どのような言葉をかけてあげればよいでしょうか？ オフショア開発が生み出すメリットを担当者1人1人に分かりやすく伝えるにはどうすればよいでしょうか。
あなたの周りでも、このような声が聞こえてきませんか。
「うちの会社は仕様変更が多いから、中国オフショア開発はしばらく無理ですよ」
「自分は忙しい、なぜ私が中国ベンダの面倒を見なければならないのか？」
「結局、中国は安かろう悪かろうの世界ですよね」
「……」
- 変化するシステム開発のスタイル
米国とインドとの間に始まったオフショア開発は、着実に日本にも浸透しつつあります。昨年のSARS騒動が鎮静化した2004年の夏、中国ソフトウェア業界は活況を取り戻しました。
その結果、企業にとって中国オフショア開発は単なるブームから、生き残りをかけた重要な企業戦略の1つとして位置付けられるようになりました。残念ながら、ユーザー企業もシステムインテグレータも、中国シフトの波から逃れられるすべはありません。
中国オフショア開発のプロジェクト管理技術が進歩することにより、近い将来には、システム開発のコストが大幅に削減され、優秀な人材が大量に安く導入できるような時代がやって来ることでしょう。
これまで特定の情報システム分野だけしか知らない、あるいは、レガシー技術に頼ってきた技術者にとっては、苦難の時代がやって来ます。新しい技術や能力を身に付けなければ、市場からそっぽを向かれてしまいます。
一般の情報スタッフにとって受難の時代がもうそこまでやって来ています。情報マネージャのあなたは、どのように対処すればよいでしょうか。
中国オフショア開発時代に求められる情報部門スタッフ
■異文化コミュニケーション能力
- PR -
全国の技術者求人情報を欠かさずチェックしていると、情報スタッフに対する期待がおおよそ把握できます。結論を先に述べると、日本人情報スタッフの仕事が急激に減ることはしばらくあり得ません。
幸い私たち日本人技術者は、外国籍技術者と比べて、顧客の希望や要求を察する感度が非常に優れています。また、日本固有の「あうんの呼吸」文化は、外国産パッケージ製品や海外オフショア開発にとって、高い参入障壁となってきました。最近はその弊害がよく指摘されますが、これらは長年私たちがはぐくんできた歴史・文化に基づく結果なので、特に恥じることはありません。
ただし、これからの情報スタッフには、外国籍技術者といかにうまく付き合うかという異文化コミュニケーション能力が求められるようになるでしょう。その先導を切るのが、情報マネージャ／SEマネージャ自身であることはいうまでもありません。
■中国オフショア全盛時代に求められる成功の2カ条
中国オフショア開発の機運が高まるにつれて、企業トップや情報マネージャは、従来の開発手法や慣習を見直さなければ、生き残れないという危機感を強く持つようになりました。
システムの利用者、情報システム部門、ならびに中国のベンダを含むビジネスパートナーが互いにメリットを享受できるWin-Win体制の構築を急がなければなりません。さもなければ、経営者や株主のIT投資への不信感はますます強くなっていく一方です。私たちがうまく対応できなければ、IT産業は結果的にゼネコン業界の後塵を拝することになりかねません。
バブル崩壊以降、経済の停滞による厳しい現実が日本企業の目の前に突き付けられています。これから真剣に中国オフショア開発に取り組んでいくためには、下記の2カ条に従うことが必須条件です。
トップによる明確なコスト削減目標と情報マネージャの正義感
利用者、情報システム部門、およびビジネスパートナーを巻き込んだ、中国オフショア開発スタッフの育成（中国オフショア開発コーディネータ）
中国オフショア開発をスタートさせる際、初めにやるべきことは、「何を」達成すべきかという事業目的を明確にすることです。ここでは、トップダウンによる強力な推進機能と、情報マネージャのコミットメントが問われます。
次に重要なのが「どのように」やるかの標準ガイドラインを設定して、関係者全員が合意すること。ここでは、中国オフショア開発スタッフが中心となって、次のような事業基盤を構築します。
中国オフショア開発の標準プラットフォーム構築
プロジェクトマネジメント手法の構築
チェンジマネジメント手法の構築
見積もり評価支援
コンポーネント／フレームワーク活用支援
このような新しい情報スタッフの育成に関しては、情報システム部門だけではなく、ビジネスパートナーや専門のコンサルタントを交えて、利用者のための強いシステム構築コミュニティを形成していくことが望ましいと考えています。
- 戦略遂行としてのオフショア開発
企業の中国オフショア開発への関心は、単なる興味レベルからこれを前提に企業戦略を策定するレベルにまで発展しています。これからの情報マネージャは、海外担当部署と歩調を合わせながら、本社機能の重要な一部として戦略的に行動することが求められます。そこでは、従来のように大手システムインテグレータに開発案件を丸投げするといった機能はすでに成り立たなくなってきています。
情報マネージャの多くは、中国オフショア開発の将来性を評価する一方で、実際にはどう始めるか、どうスタッフを育成するのか、具体的なアイデアに乏しいのではないでしょうか。これから中国オフショア開発を推進する情報マネージャは、部下やビジネスパートナーの持つ中国オフショア開発への不安や不満を十分に理解することがとても大切になってきます。
中国オフショア開発の導入は、企業にとって大きな変化を伴います。
世の中の流れから、いまが変革を実行するまたとないタイミングではないでしょうか。そのためには、変革のプロセスをできる限りシンプルにしていく必要があります。変革の中では得する者もいれば既得権益を失う者もいますが、最も多いのは損得どころか変革の意味さえ分からない者でしょう。
そのため高い理念を持つ「教義」はもちろん重要ですが、「南無阿弥陀仏」のように実行プロセスを分かりやすくすることも大変重要になってきます。この連載記事が、その役割の一端を担うことになるでしょう。
関連記事
オフショア開発でハッピーになれましたか？（＠IT > IT Architect）
日本市場攻略で一丸となる大連市と現地IT企業（＠IT自分戦略研究所 > 自分戦略研究室）
第1回 中国ソフトウェア業界の実力とオフショア開発の勘所
幸地 司
アイコーチ有限会社
2004/9/14
--------------------------------------------------------------------------------
「オフショア開発」という言葉がよく聞かれるようになってきた。オフショア開発に取り組み、成功したという事例が伝えられる一方、失敗・苦闘の話も漏れ聞く。オフショア開発を成功に導く“コーディネータ”とはどのような存在だろうか？（→記事要約
--------------------------------------------------------------------------------
- 選択の余地がない中国シフト
ある日、あなたに対して会社の経営陣から次のような通達がありました。
「今年度のIT投資予算のうち、20％を中国オフショア開発で実施することが決まった。そこで、キミが抱えている案件の一部を中国に発注したい。直ちに準備するように」
- PR -
今日、会社トップからの指令で、案件の選定がなされるより先に中国オフショア開発の実施が決まっていることがあります。いったん方針が打ち出されると、情報マネージャの意思にかかわらず、青写真だけを頼りに話が進められることもしばしばです。ある日、あなたの案件が突然オフショア開発の対象となるわけです。今後はこのようなことが増えてくるかもしれません。誰も人事（ひとごと）だと笑えない時代になってきました。
この連載記事は、企業の情報化推進プロジェクトに責任を持つ情報マネージャ、あるいは実際の開発現場で常に泥沼のデスマーチに巻き込まれるシステムインテグレータのSEマネージャを対象に企画されたものです。
中国オフショア開発は、いつわが身に降りかかってくるか誰も予想がつきません。本連載記事では、えりすぐりの旬のテーマを中心に、現場でいますぐに役立つ情報が入手できるよう配慮されています。これまで、担当者や特定企業の勘や暗黙知に頼ることの多かった中国オフショア開発の成功の秘訣やスタッフ育成の鍵を分かりやすく全6回に分けて連載します。
ここから学んだことを活用して、ご自身の手でITサービス提供者のプロフェッショナル集団を形成していただければ幸いです。
- オフショア開発の状況
■海外拠点で開発すること
ところで、読者の中には「中国オフショア開発って何？」と疑問に思われる方がいらっしゃるかもしれません。オフショア開発とは何でしょうか？
平たくいうと、オフショア開発とは国内のソフトウェア開発を海外拠点に委託することです。具体的には、オフショア開発の主な受注先としてはインドや中国の企業が挙げられます。ほかにも、韓国やフィリピン、ロシア、東欧諸国などへもオフショア開発が展開されています。
オフショア開発の最大の魅力は、何といっても大幅な原価削減が期待できること。これまでは、システムインテグレータが先駆けとなって、オフショア開発の開拓を担ってきましたが、これからは情報システム部門が自ら海外に乗り出すケースも増えるでしょう。
先行する一部の企業では、海外で採用した現地社員の能力不足が露呈するなど、納期や品質に関するトラブルが少なくありません。それでも、オフショア開発にはこれらの困難を補って余りあるほどの可能性があるわけで、これからも海外拠点の充実がますます加速されていくことでしょう。
■欧米諸国はいち早くBPR／BPOを模索
オフショア開発は、米国を中心とする欧米諸国を発祥とします。もともとは、経費削減などのコストメリットに関係者の注目が集まっていましたが、近年では抜本的な業務改革（BPR／BPO）を伴う新しいビジネス形態として期待されています。米調査会社のMETA Groupによると、オフショア開発は今後2年間20～25％増で成長するとされています。
アジアパシフィックにおいては、特に中国大連の発展が目覚ましく、今後の動向から目を離せない状況にあります。
■日本ではインドと中国が人気を二分
このように、オフショア開発は世界各国で実施されていますが、わが国においてはどのような状況でしょうか。IT業界では、技術や経済の変化によってさまざまなブームが到来しますが、オフショア開発の分野ではインドと中国がその人気を二分しています。
近年では、沖縄県の有利なIT産業振興施策を活用したITアウトソーシングも盛んに展開されています。沖縄では、東京―沖縄間で実施されるソフトウェア分散開発のことも、オフショア開発と呼びます。
中国、インド、あるいは沖縄で繰り広げられるオフショア開発では、プロジェクトの立ち上げから完了までの間に、実にさまざまなドラマがあります。
「オフショア開発への対応は、開発部門だけに任せるべき課題ではない」
「従来の古い開発標準を改めて、UMLを採用したスパイラル型開発モデルを検討せよ」
「品質が約束されない限り、プロジェクトリーダーとしては海外発注を認めない」
「オフショア開発を特別に恐れることはない。本来の正しいシステム開発を実践すれば相手が外国企業であろうともきっと成功するはずだ」
最近、日常的にオフショア開発に関するうわさを耳にします。日本におけるオフショア開発の歴史はまだ浅く、こと中国に関しては、まだ手探りの状態といっていいでしょう。一部からは、中国オフショア開発を悲観する声が聞かれますが、他方数は少ないですが中国オフショア開発の成功事例も出始めています。
このような状況を踏まえて、本連載では主に中国オフショア開発に特化した記事をお届けします。
中国オフショア開発の可能性と問題点
■中国オフショア開発の可能性
- PR -
ここからは、日本企業にとっての中国オフショア開発に特化して話を進めます。
まず、中国ITアウトソーシング全般について考えてみましょう。中国へのアウトソーシングビジネスは、大きく2種類に大別されます。
技術者派遣モデル
サービスプロバイダ・モデル
技術者派遣モデルとは、技術者1人当たりの人月単価を定めて、一定期間確保する業種です。研究室のように一定の技術者を確保することから「ラボ」とも呼ばれます。一方、サービスプロバイダ・モデルとは、受託開発や保守運用、さらには付加価値の高い業務サービスを提供する業種のことを指します。現在のサービスプロバイダ・モデルでは、次のような業務が対象となります。
フルアウトソーシングサービス
総務／人事サービス
テクニカルサービス
調査会社
ロジスティクスサービス
コールセンターサービス
……ほか
一般に日本企業になじみが深いのは、前者の技術者派遣モデルです。
しかしながら、現在の中国ソフトウェア業界の人材分布をかんがみると、“均一な人材”を大量に要する対日ITアウトソーシング業務が確立されるのは、もう少し時間がかかりそうな気がします。なぜなら、中国ベンダが一丸となってプロジェクトを推進するには、まだ個人の協調性が成熟しているとはいい難いからです。
その一方で、サービスプロバイダ・モデルは魅力があります。このモデルは、少数精鋭のリーダー層と普通の保守運用要員の組み合わせでも十分に運営が成り立つからです。実際、欧米やインドでは、こちらの方が主流になっています。しばらくは、中国市場の動向に歩調を合わせながら着実に成長を続けるでしょう。
コラム
総務／人事に関するサービスプロバイダ・モデルの事例を1つ紹介します。
2004年7月、人事・給与パッケージで有名なワークスアプリケーションズは、中国系企業とパートナーシップを結び、中国大連にBPO（ビジネスプロセス・アウトソーシング）とASPサービスを提供する合弁会社を設立しました。生産拠点の中国移転に伴い、生産管理ソフトベンダが中国進出する例はよく耳にします。ところが、人事・給与パッケージベンダの中国進出は珍しいといえるでしょう。BPOは大連を中心に盛り上がっており、同社の初年度販売目標は3億円で、5年後に100億円以上を目指しています。なお、この分野では外資系企業が先行しています。
一足先に中国進出を果たした製造業では、国際的なサプライチェーン・マネジメントシステムを軸にして、経済レベルの上位国でルール作りを行い、下位国では生産を行いつつマーケットを形成していくことが成長モデルとなっています。
将来的には、わが国のソフトウェア業界でも、単純な受託案件を中国オフショアで開発するだけではなく、自社製品を中国市場で販売したり、他製品と連携させるなどさまざまな可能性を探りながら展開していくべきでしょう。
■中国オフショア開発の問題点
大規模プロジェクトを通じて大幅な原価削減を図る際には、中国オフショア開発は大きな魅力があります。しかし、単に費用削減を狙った中国オフショア開発では、期待どおりの効果が上がらないこともあります。
近年、加熱気味の中国シフトに対して、各方面からさまざまな警告がなされています。最悪の場合、中国人社員の定着率の悪さから、事業継続が困難になるという事態が発生します。以下に代表的な問題点を4つ挙げます。
セキュリティや知的財産の侵害
納期遅延、開発予算超過
言葉や文化の違いによる感情のあつれき
生産性の著しい低下
日本企業の取り組み
■中国オフショア開発をちゅうちょする声
最近では、中国オフショア開発を重要な経営戦略の一環として認識して、企業トップが自らその推進に当たる会社が増えています。しかしながら、関係者の多くは、中国オフショア開発への疑問を抱きつつ、仕方なくトップに追随しているように感じられます。
- PR -
欧米の顧客がソフトウェア開発を国外に委託するのは、海外の安い人材を利用して本国のソフトウェアパッケージ製品に生かすのが主な目的です。それに加えて、一般的なソフトウェアの委託開発と異なり、完成した製品の知的財産権は顧客にあるのも魅力の1つだといわれてきました。これにより、欧米企業では、社員1人1人がオフショア開発の利益を十分に理解したうえで行動してきたといわれます。
ところが、国内のオフショア開発関係者は上記とは違った意見を持ちます。
「何度も何度もやりとりをして要件を伝えたのに、出来上がったものは想像したものと少しずれてしまう」
「バグを直しても、直しても、少しだけ残ってしまう」
「拡張性、移植性、セキュリティ面の考慮が足りないまま、完成させてしまう」
はっきりいって、「分かっちゃいるけどオフショア開発はご勘弁」というのが現場を預かる情報マネージャの本音です。オフショア開発推進チームのモチベーションが上がらない原因の1つがここにあります。
■エンジニアのいい分
日本企業が社内で最初に中国オフショア開発の可能性を検討する際、一般には組織横断的な人事を断行し、複数の部署から人をかき集めて専門の検討チームを結成します。ところが実際には、専任で中国オフショア開発の推進を担う者は少なく、ほとんどは元の部署の“本業”と兼務しています。つまり、忙しい間を縫って“片手間”で対応することになります。
このような状況下でオフショア開発推進の会議を開催しても、参加者から発せられる言葉は少し寂しいものになってしまいます。
「例の○×案件がトラブって、社内アンケートを集計する時間がありませんでした」
「雑誌◇△のコピーをお配りします」（自分は動かず、コピー資料を配布するだけ）
でも、彼らは決して保身のために中国オフショア開発を避けているのではありません。自分が楽をするために情報マネージャの仕事を邪魔したいわけでもありません。
彼らは日常の運用業務を滞らせるわけにはいきませんし、お客が望む最高のサービスを提供するよう常に心掛けています。情報システム部門の性質上、自分たちが提供するITサービスの品質を一定以上に保つためのリスクヘッジは絶対に欠かせません。そのエンジニア魂が結果としてオフショア開発推進の抵抗勢力となってしまうのです。
こんなときに、中国オフショア開発の重要性を認識している情報マネージャは、どのような言葉をかけてあげればよいでしょうか？ オフショア開発が生み出すメリットを担当者1人1人に分かりやすく伝えるにはどうすればよいでしょうか。
あなたの周りでも、このような声が聞こえてきませんか。
「うちの会社は仕様変更が多いから、中国オフショア開発はしばらく無理ですよ」
「自分は忙しい、なぜ私が中国ベンダの面倒を見なければならないのか？」
「結局、中国は安かろう悪かろうの世界ですよね」
「……」
- 変化するシステム開発のスタイル
米国とインドとの間に始まったオフショア開発は、着実に日本にも浸透しつつあります。昨年のSARS騒動が鎮静化した2004年の夏、中国ソフトウェア業界は活況を取り戻しました。
その結果、企業にとって中国オフショア開発は単なるブームから、生き残りをかけた重要な企業戦略の1つとして位置付けられるようになりました。残念ながら、ユーザー企業もシステムインテグレータも、中国シフトの波から逃れられるすべはありません。
中国オフショア開発のプロジェクト管理技術が進歩することにより、近い将来には、システム開発のコストが大幅に削減され、優秀な人材が大量に安く導入できるような時代がやって来ることでしょう。
これまで特定の情報システム分野だけしか知らない、あるいは、レガシー技術に頼ってきた技術者にとっては、苦難の時代がやって来ます。新しい技術や能力を身に付けなければ、市場からそっぽを向かれてしまいます。
一般の情報スタッフにとって受難の時代がもうそこまでやって来ています。情報マネージャのあなたは、どのように対処すればよいでしょうか。
中国オフショア開発時代に求められる情報部門スタッフ
■異文化コミュニケーション能力
- PR -
全国の技術者求人情報を欠かさずチェックしていると、情報スタッフに対する期待がおおよそ把握できます。結論を先に述べると、日本人情報スタッフの仕事が急激に減ることはしばらくあり得ません。
幸い私たち日本人技術者は、外国籍技術者と比べて、顧客の希望や要求を察する感度が非常に優れています。また、日本固有の「あうんの呼吸」文化は、外国産パッケージ製品や海外オフショア開発にとって、高い参入障壁となってきました。最近はその弊害がよく指摘されますが、これらは長年私たちがはぐくんできた歴史・文化に基づく結果なので、特に恥じることはありません。
ただし、これからの情報スタッフには、外国籍技術者といかにうまく付き合うかという異文化コミュニケーション能力が求められるようになるでしょう。その先導を切るのが、情報マネージャ／SEマネージャ自身であることはいうまでもありません。
■中国オフショア全盛時代に求められる成功の2カ条
中国オフショア開発の機運が高まるにつれて、企業トップや情報マネージャは、従来の開発手法や慣習を見直さなければ、生き残れないという危機感を強く持つようになりました。
システムの利用者、情報システム部門、ならびに中国のベンダを含むビジネスパートナーが互いにメリットを享受できるWin-Win体制の構築を急がなければなりません。さもなければ、経営者や株主のIT投資への不信感はますます強くなっていく一方です。私たちがうまく対応できなければ、IT産業は結果的にゼネコン業界の後塵を拝することになりかねません。
バブル崩壊以降、経済の停滞による厳しい現実が日本企業の目の前に突き付けられています。これから真剣に中国オフショア開発に取り組んでいくためには、下記の2カ条に従うことが必須条件です。
トップによる明確なコスト削減目標と情報マネージャの正義感
利用者、情報システム部門、およびビジネスパートナーを巻き込んだ、中国オフショア開発スタッフの育成（中国オフショア開発コーディネータ）
中国オフショア開発をスタートさせる際、初めにやるべきことは、「何を」達成すべきかという事業目的を明確にすることです。ここでは、トップダウンによる強力な推進機能と、情報マネージャのコミットメントが問われます。
次に重要なのが「どのように」やるかの標準ガイドラインを設定して、関係者全員が合意すること。ここでは、中国オフショア開発スタッフが中心となって、次のような事業基盤を構築します。
中国オフショア開発の標準プラットフォーム構築
プロジェクトマネジメント手法の構築
チェンジマネジメント手法の構築
見積もり評価支援
コンポーネント／フレームワーク活用支援
このような新しい情報スタッフの育成に関しては、情報システム部門だけではなく、ビジネスパートナーや専門のコンサルタントを交えて、利用者のための強いシステム構築コミュニティを形成していくことが望ましいと考えています。
- 戦略遂行としてのオフショア開発
企業の中国オフショア開発への関心は、単なる興味レベルからこれを前提に企業戦略を策定するレベルにまで発展しています。これからの情報マネージャは、海外担当部署と歩調を合わせながら、本社機能の重要な一部として戦略的に行動することが求められます。そこでは、従来のように大手システムインテグレータに開発案件を丸投げするといった機能はすでに成り立たなくなってきています。
情報マネージャの多くは、中国オフショア開発の将来性を評価する一方で、実際にはどう始めるか、どうスタッフを育成するのか、具体的なアイデアに乏しいのではないでしょうか。これから中国オフショア開発を推進する情報マネージャは、部下やビジネスパートナーの持つ中国オフショア開発への不安や不満を十分に理解することがとても大切になってきます。
中国オフショア開発の導入は、企業にとって大きな変化を伴います。
世の中の流れから、いまが変革を実行するまたとないタイミングではないでしょうか。そのためには、変革のプロセスをできる限りシンプルにしていく必要があります。変革の中では得する者もいれば既得権益を失う者もいますが、最も多いのは損得どころか変革の意味さえ分からない者でしょう。
そのため高い理念を持つ「教義」はもちろん重要ですが、「南無阿弥陀仏」のように実行プロセスを分かりやすくすることも大変重要になってきます。この連載記事が、その役割の一端を担うことになるでしょう。
関連記事
オフショア開発でハッピーになれましたか？（＠IT > IT Architect）
日本市場攻略で一丸となる大連市と現地IT企業（＠IT自分戦略研究所 > 自分戦略研究室）
第４回 いいかげんにして！ 日本企業─中国に嫌われる理由
いいかげんにして！ 日本企業
─中国に嫌われる理由
http://www.atmarkit.co.jp/fbiz/cstaff/serial/offshore/04/01.html
幸地 司
アイコーチ有限会社
2004/12/16
--------------------------------------------------------------------------------
前回までは、主に日本企業側から見た中国オフショア開発のメリット・デメリットを紹介してきた。一方で、開発を受託する中国側企業の視点に立つと、プロジェクト計画書や仕様書の問題や日本側が中国を見下す姿勢の問題など、日本企業にも多くの問題を抱えていることが分かる。ここでは、前編となる今回と、後編となる次回の2回に分けて、中国企業側から見た日本企業の問題を明らかにしていく。（→記事要約へ）
--------------------------------------------------------------------------------
- 中国側から日本を見てみると……
これまでは、主に日本企業の立場から中国オフショア開発における問題点を指摘してきました。第1回の「中国ソフトウェア業界の実力とオフショア開発の勘所」では、社内のオフショア開発に対する不安を払しょくする方法と、オフショア開発を推進するコミュニティの形成について紹介しました。
第2回では、実際に中国で体験した失敗例や事例を研究して得た教訓などについて言及し、さらに第3回では効果的なプロジェクト立ち上げを実現するアプローチを紹介しました。
一方、オフショア開発を受託する中国側の立場から指摘された問題点を見てみると、実にさまざまなバリエーションがあることに気付きます。それは、中国視察旅行のマナーに関する問題、契約締結までに時間がかかり過ぎる問題、プロジェクト計画書や仕様書の問題、現場のコミュニケーションの問題、日本側が中国を見下す姿勢の問題、担当者の技術力不足の問題、責任分担があいまいで管理体制が立ち上がらない問題、管理層が不在で若手社員や中国側に丸投げする問題などです。
これらの問題は昔から中国企業に根強く存在しますが、その多くは中国側の品質問題の陰に隠れてしまい、これまでほとんど疑問視されることはありませんでした。今回と次回では、これら中国側が感じるオフショア開発の問題点を大きく4つに分類し、それぞれの問題点について詳しく解説していきます。
仕様まとめ能力不足
仕様変更の段取りの悪さ
担当者の技術力不足
理不尽な条件の押し付け
- 仕様まとめ能力不足 ～木を見て森を見ず～
中国企業から最も多く寄せられる意見は、「仕様書のまとめ」に関する不満の声です。その代表的なコメントをいくつか紹介します。
「全体的に仕様が確定しないまま、開発に着手せざるを得ない」
「どの仕様が確定していて、どこが未確定なのかがあいまい」
「全体構成と個別説明の対応が不明りょう」
「要件の網羅性が悪く、論理的にすっきりまとまった資料が少ない」
ただし、ここで注意していただきたいのは「仕様が固まらず失敗するのは、国内開発でも同じだ。オフショア開発固有の問題ではない」などと結論を急がないでほしいのです。なぜならば、国内開発においては、走りながら徐々に暫定仕様を確定させる「日本型開発アプローチ」であっても、過去に多くの成功事例があることを読者の皆さんは知っているからです。
- PR -
では、なぜ従来の日本型開発アプローチは、オフショア開発では通用しないのでしょうか。日本型開発アプローチでは、発注側の業務分析が足りない場合に、受注側のシステム開発会社や下請け業者が努力して仕様書の行間を埋めることが当たり前とされています。ところが、相手が中国企業となると、日本語で書かれた仕様書の行間が読めないばかりか、「トラブルがトラブルを呼ぶ」ような状況にまで悪化し、プロジェクトマネージャの裁量だけでは収拾がつかなくなってしまいます。
一方、仕様書そのものにも問題があります。最近は、機能単位の細かい仕様に目が行き過ぎて、漏れなくダブりなく考える論理的思考（MECE）に欠ける仕様書が目立つようになりました。ある中国企業担当者は、日本企業が提供する仕様書のほとんどが「木を見て森を見ず」だと指摘しています。
日本企業の長年の努力により、穴埋め式に記述する定型フォーマットを使えば、誰でも簡単に仕様書が作れます。そこに、マニュアル教育の1つの落とし穴があります。ちまたでは「中国ベンダは、異常系や境界／限界系の実装漏れが多く困っている」といわれますが、実際には日本の仕様書にも大いに問題があることを理解しましょう。
ある中国IT企業の風景
あるオフショア開発では、日本企業が提供した要件定義書がまったく役立たなかったため、わざわざ中国で作り直したという事例があります。これは、ユースケースがまちまちの粒度で記述されていたため、中国語に翻訳してもほとんど使えないと判断されたからでした。こういった無駄の積み重ねが、オフショア開発のコストを押し上げる要因の1つとなってしまっています。
日本側の「木を見て森を見ず」、すなわち論理的思考に欠ける仕様書の例を数え上げるときりがありません。最近の中国オフショア開発では、Webアプリケーションの案件が主流の1つとなっていますが、同じような問題を抱えた仕様書は少なくありません。
さらに詳しく説明しましょう。
Webアプリケーション開発では、画面1枚ごとに1つの画面設計資料を作成します。しかし、システム全体を適切なサブシステムに分割することができないため、さまざまな矛盾や修正漏れが発生する恐れがあります。
画面間の関連性があいまいであるため、全体の業務フローが把握しにくい
共通化すべき事項が設計書に点在するので、設計書の版管理に支障を来たす恐れがある
こうなってしまうと、外国人技術者の誤解を生むのは必至です。ところが、日本側に罪の意識が乏しいことから、後工程において「誰の責任でバグが生じたのか」を特定する際にもめることがあります。こんなことから、やがて両国の技術者の間に溝が生じて、プロジェクトの進行の妨げになることもしばしばあります。
そのほか、中国企業からは、このような声も多く聞こえました。
「同じミスが多い。日本側の類似見直しも足りない」
「提供されたサンプルのとおりに実装したら、仕様が違うといわれた（本来は、サンプルの提示ミス）」
正確で分かりやすい仕様伝達の方法
- PR -
中国オフショア開発を成功させるためには、初期段階から要求仕様を固めることに加えて、中国企業側に日本語コミュニケーション能力の優れたリーダーを確保できていることが大前提です。そのうえで、中国人は「行間が読めない」ことを意識しながら、仕様書を作成しなければなりません。文章だけで細かいニュアンスを伝えるのではなく、図面やサンプルを多用し、できるだけ実データに近い資料やサンプルを補足資料として提供すると良いでしょう。
■仕様書作成のコツ、口頭説明のコツ
正確で分かりやすい仕様伝達のコツは、正しく文書化すること、そして口頭で正確に説明すること、この2点に絞られます。
仕様書作成のコツ
●正常系と異常系の仕様を明記
ある研究によると、システム開発における異常系処理の約7割は、プログラマが独断で決定するとされています。特に日本的なシステム開発アプローチでは、仕様書の網羅性が低いために気を付けなくてはいけません。オフショア開発における仕様書では、事前にどこが暫定仕様なのかを特定し、さらに暫定仕様が確定する時期も併せて盛り込んでおくとよいでしょう。
●すべての処理条件を明記
判定条件や条件分岐の処理に関しては、すべての内容を明確に記述します。日本人なら常識的に理解できる内容であっても、外国人技術者が理解できるとは限らないからです。
例1
判定条件 検索結果が1～99件 ならば、1ページに検索結果を表示する
検索結果が100件以上ならば、2ページに分けて検索結果を表示する
問題点 →検索結果が0件の場合の仕様があいまい
→検索結果が200件の場合は3ページに分けて検索結果を表示するのか？
例2
判定条件 ユーザーが役員の場合、処理Aを実行
ユーザーが部長の場合、処理Bを実行
ユーザーが課長の場合、処理Dを実行
そのほかの場合、処理Eを実行
問題点 →そのほかの場合があいまい。例えば、社長、派遣社員、アルバイトの扱いはどうなるのか？
→このような記述方法だと、ユーザー権限定義を別途参照しなくてはならず、仕様誤解の大きな原因となる
●障害発生時の処理を予測
原則として、運用で発生し得る障害パターンは、すべて事前に洗い出しておかなくてはいけません。特に、日本がシステムを保守運用する契約になっている場合には、発注側が障害発生時の仕様について責任を持つことが重要です。
●サンプルやデータを補足資料として活用
文章だけの抽象的な説明はできるだけ避けて、個条書きや図面を添付することも重要です。サンプルやデータは補足資料として有効だからです。特に、実際の業務に即した個別説明が最も効果的であるといえます。
●用語の統一
無用な混乱を避けるため、仕様書で用いる用語は統一します。中には日本と中国とで意味が異なる用語があるので、特に注意しなくてはいけません。
用語 日本での意味 中国での意味
空白 スペース スペースまたはNULL
空色 青色 無色透明と誤解される恐れあり
年度末 3月末 12月末
中国企業が感じるオフショア開発の問題点は“仕様関連”が最も多いとされます。そこで、中国企業向けに仕様書を記述する際には、常に具体的かつ個別説明を意識することが肝心です。そして、仕様を伝えるときには、日本から一方通行的に提示するのではなく、相手方の理解度を必ず口頭で確認しながら、進めた方が効果的です。全体の仕様理解度を測るには、中国企業が苦手とする「異常系、境界／限界系」の理解度に着目するとよいでしょう。ぜひお試しください。
◇
次回は、日本企業の問題点として挙げられた残りの問題「仕様変更の段取りの悪さ」「担当者の技術力不足」「理不尽な条件の押し付け」などを紹介します。
─中国に嫌われる理由
http://www.atmarkit.co.jp/fbiz/cstaff/serial/offshore/04/01.html
幸地 司
アイコーチ有限会社
2004/12/16
--------------------------------------------------------------------------------
前回までは、主に日本企業側から見た中国オフショア開発のメリット・デメリットを紹介してきた。一方で、開発を受託する中国側企業の視点に立つと、プロジェクト計画書や仕様書の問題や日本側が中国を見下す姿勢の問題など、日本企業にも多くの問題を抱えていることが分かる。ここでは、前編となる今回と、後編となる次回の2回に分けて、中国企業側から見た日本企業の問題を明らかにしていく。（→記事要約
--------------------------------------------------------------------------------
- 中国側から日本を見てみると……
これまでは、主に日本企業の立場から中国オフショア開発における問題点を指摘してきました。第1回の「中国ソフトウェア業界の実力とオフショア開発の勘所」では、社内のオフショア開発に対する不安を払しょくする方法と、オフショア開発を推進するコミュニティの形成について紹介しました。
第2回では、実際に中国で体験した失敗例や事例を研究して得た教訓などについて言及し、さらに第3回では効果的なプロジェクト立ち上げを実現するアプローチを紹介しました。
一方、オフショア開発を受託する中国側の立場から指摘された問題点を見てみると、実にさまざまなバリエーションがあることに気付きます。それは、中国視察旅行のマナーに関する問題、契約締結までに時間がかかり過ぎる問題、プロジェクト計画書や仕様書の問題、現場のコミュニケーションの問題、日本側が中国を見下す姿勢の問題、担当者の技術力不足の問題、責任分担があいまいで管理体制が立ち上がらない問題、管理層が不在で若手社員や中国側に丸投げする問題などです。
これらの問題は昔から中国企業に根強く存在しますが、その多くは中国側の品質問題の陰に隠れてしまい、これまでほとんど疑問視されることはありませんでした。今回と次回では、これら中国側が感じるオフショア開発の問題点を大きく4つに分類し、それぞれの問題点について詳しく解説していきます。
仕様まとめ能力不足
仕様変更の段取りの悪さ
担当者の技術力不足
理不尽な条件の押し付け
- 仕様まとめ能力不足 ～木を見て森を見ず～
中国企業から最も多く寄せられる意見は、「仕様書のまとめ」に関する不満の声です。その代表的なコメントをいくつか紹介します。
「全体的に仕様が確定しないまま、開発に着手せざるを得ない」
「どの仕様が確定していて、どこが未確定なのかがあいまい」
「全体構成と個別説明の対応が不明りょう」
「要件の網羅性が悪く、論理的にすっきりまとまった資料が少ない」
ただし、ここで注意していただきたいのは「仕様が固まらず失敗するのは、国内開発でも同じだ。オフショア開発固有の問題ではない」などと結論を急がないでほしいのです。なぜならば、国内開発においては、走りながら徐々に暫定仕様を確定させる「日本型開発アプローチ」であっても、過去に多くの成功事例があることを読者の皆さんは知っているからです。
- PR -
では、なぜ従来の日本型開発アプローチは、オフショア開発では通用しないのでしょうか。日本型開発アプローチでは、発注側の業務分析が足りない場合に、受注側のシステム開発会社や下請け業者が努力して仕様書の行間を埋めることが当たり前とされています。ところが、相手が中国企業となると、日本語で書かれた仕様書の行間が読めないばかりか、「トラブルがトラブルを呼ぶ」ような状況にまで悪化し、プロジェクトマネージャの裁量だけでは収拾がつかなくなってしまいます。
一方、仕様書そのものにも問題があります。最近は、機能単位の細かい仕様に目が行き過ぎて、漏れなくダブりなく考える論理的思考（MECE）に欠ける仕様書が目立つようになりました。ある中国企業担当者は、日本企業が提供する仕様書のほとんどが「木を見て森を見ず」だと指摘しています。
日本企業の長年の努力により、穴埋め式に記述する定型フォーマットを使えば、誰でも簡単に仕様書が作れます。そこに、マニュアル教育の1つの落とし穴があります。ちまたでは「中国ベンダは、異常系や境界／限界系の実装漏れが多く困っている」といわれますが、実際には日本の仕様書にも大いに問題があることを理解しましょう。
ある中国IT企業の風景
あるオフショア開発では、日本企業が提供した要件定義書がまったく役立たなかったため、わざわざ中国で作り直したという事例があります。これは、ユースケースがまちまちの粒度で記述されていたため、中国語に翻訳してもほとんど使えないと判断されたからでした。こういった無駄の積み重ねが、オフショア開発のコストを押し上げる要因の1つとなってしまっています。
日本側の「木を見て森を見ず」、すなわち論理的思考に欠ける仕様書の例を数え上げるときりがありません。最近の中国オフショア開発では、Webアプリケーションの案件が主流の1つとなっていますが、同じような問題を抱えた仕様書は少なくありません。
さらに詳しく説明しましょう。
Webアプリケーション開発では、画面1枚ごとに1つの画面設計資料を作成します。しかし、システム全体を適切なサブシステムに分割することができないため、さまざまな矛盾や修正漏れが発生する恐れがあります。
画面間の関連性があいまいであるため、全体の業務フローが把握しにくい
共通化すべき事項が設計書に点在するので、設計書の版管理に支障を来たす恐れがある
こうなってしまうと、外国人技術者の誤解を生むのは必至です。ところが、日本側に罪の意識が乏しいことから、後工程において「誰の責任でバグが生じたのか」を特定する際にもめることがあります。こんなことから、やがて両国の技術者の間に溝が生じて、プロジェクトの進行の妨げになることもしばしばあります。
そのほか、中国企業からは、このような声も多く聞こえました。
「同じミスが多い。日本側の類似見直しも足りない」
「提供されたサンプルのとおりに実装したら、仕様が違うといわれた（本来は、サンプルの提示ミス）」
正確で分かりやすい仕様伝達の方法
- PR -
中国オフショア開発を成功させるためには、初期段階から要求仕様を固めることに加えて、中国企業側に日本語コミュニケーション能力の優れたリーダーを確保できていることが大前提です。そのうえで、中国人は「行間が読めない」ことを意識しながら、仕様書を作成しなければなりません。文章だけで細かいニュアンスを伝えるのではなく、図面やサンプルを多用し、できるだけ実データに近い資料やサンプルを補足資料として提供すると良いでしょう。
■仕様書作成のコツ、口頭説明のコツ
正確で分かりやすい仕様伝達のコツは、正しく文書化すること、そして口頭で正確に説明すること、この2点に絞られます。
仕様書作成のコツ
●正常系と異常系の仕様を明記
ある研究によると、システム開発における異常系処理の約7割は、プログラマが独断で決定するとされています。特に日本的なシステム開発アプローチでは、仕様書の網羅性が低いために気を付けなくてはいけません。オフショア開発における仕様書では、事前にどこが暫定仕様なのかを特定し、さらに暫定仕様が確定する時期も併せて盛り込んでおくとよいでしょう。
●すべての処理条件を明記
判定条件や条件分岐の処理に関しては、すべての内容を明確に記述します。日本人なら常識的に理解できる内容であっても、外国人技術者が理解できるとは限らないからです。
例1
判定条件 検索結果が1～99件 ならば、1ページに検索結果を表示する
検索結果が100件以上ならば、2ページに分けて検索結果を表示する
問題点 →検索結果が0件の場合の仕様があいまい
→検索結果が200件の場合は3ページに分けて検索結果を表示するのか？
例2
判定条件 ユーザーが役員の場合、処理Aを実行
ユーザーが部長の場合、処理Bを実行
ユーザーが課長の場合、処理Dを実行
そのほかの場合、処理Eを実行
問題点 →そのほかの場合があいまい。例えば、社長、派遣社員、アルバイトの扱いはどうなるのか？
→このような記述方法だと、ユーザー権限定義を別途参照しなくてはならず、仕様誤解の大きな原因となる
●障害発生時の処理を予測
原則として、運用で発生し得る障害パターンは、すべて事前に洗い出しておかなくてはいけません。特に、日本がシステムを保守運用する契約になっている場合には、発注側が障害発生時の仕様について責任を持つことが重要です。
●サンプルやデータを補足資料として活用
文章だけの抽象的な説明はできるだけ避けて、個条書きや図面を添付することも重要です。サンプルやデータは補足資料として有効だからです。特に、実際の業務に即した個別説明が最も効果的であるといえます。
●用語の統一
無用な混乱を避けるため、仕様書で用いる用語は統一します。中には日本と中国とで意味が異なる用語があるので、特に注意しなくてはいけません。
用語 日本での意味 中国での意味
空白 スペース スペースまたはNULL
空色 青色 無色透明と誤解される恐れあり
年度末 3月末 12月末
中国企業が感じるオフショア開発の問題点は“仕様関連”が最も多いとされます。そこで、中国企業向けに仕様書を記述する際には、常に具体的かつ個別説明を意識することが肝心です。そして、仕様を伝えるときには、日本から一方通行的に提示するのではなく、相手方の理解度を必ず口頭で確認しながら、進めた方が効果的です。全体の仕様理解度を測るには、中国企業が苦手とする「異常系、境界／限界系」の理解度に着目するとよいでしょう。ぜひお試しください。
◇
次回は、日本企業の問題点として挙げられた残りの問題「仕様変更の段取りの悪さ」「担当者の技術力不足」「理不尽な条件の押し付け」などを紹介します。
夢見る、負けず嫌い
16歳。
中学時代までの私は、どちらかといえば頭でっかちで感情をあまり表に出さないタイプだった。好きだったアマチュア無線に自分を閉じ込めていた。そんな自分を変えたくて、高校でテニス部に入部した。それから自分を思い切って表現できるようになった。スポーツは自分のやってきたことが勝ち負けという結果ではっきり出て、言い訳がきかない。負けた時は、なぜ負けたのかを考えて絶対克服してやるぞってガムシャラに練習した。苦手だったバックハンドもいつの間にか得意になっていた。できないことも、理由を見つけて解決すれば必ずできるようになる。テニスで学んだことは、今の仕事にも生きている。
24歳。
大学は工学部。電気電子を専攻して、大学院では風力発電の研究をしていた。テーマとしては非常に面白かったが、それを仕事にすることには疑問を感じていた。教授の推薦で、あるメーカーを受けてみたもののどうもしっくりこない。同じインフラに関わる仕事なら、研究室に閉じこもってやるのではなく、ヒューマンなコミュニケーションを通して実践したかった。どうせ働くなら社会のフロントに立ち、世界を股にかけるような大きな仕事をしてみたいとも思っていた。悩んでいた時、就職情報誌で見つけたのがアクセンチュアだった。コンサルティングという仕事については何もわからなかったけれど、自分の想いを実現できそうな気がした。目の前にいくつかの選択肢がある時、私は自分がより前向きに生きられそうな方を選ぶ。
28歳。
入社4年目、企画系のプロジェクトに初めて携わった。それまで担当していたシステム系のプロジェクトと比較すると、与えられる課題も解決方法もまったく違っていた。戸惑いの中で参加した最初のプロジェクトは、自分としては明らかに失敗だった。自分なりに一生懸命やったものの期待に添うことができなかった。アクセンチュアは積極的な失敗には寛容な会社だと思う。でも、同じことで二度の失敗は許されない。自分は企画系には向いていない。リスクだけを考えれば、そう決断を下してそのプロジェクトを離れることもできなくはなかったが、それだけはイヤだった。もしあの時に逃げていたら、今の仕事との出会いはなかったと思う。
32歳。
今、ある業界に今までにないビジネスの仕組みを導入するプロジェクトを担当している。海外での様々なプロジェクト経験や業界の方々とのお付き合いを通して「自分の頭の中に思い描いていたこと」と、社会の環境がピタッと合ってスタートしたプロジェクト。業界全体の旗振りのような役割をしているので大きな責任とプレッシャーを感じている。でも、実現したら業界のビジネスそのものを大きく変革することができる。アクセンチュアでやりたいと思っていたことに、ようやく辿り着けた。このプロジェクトを死んでもものにしたい。コンサルタントという職業の面白さと醍醐味は、夢を語れるところにある。一プレイヤーでは語れない夢も、コンサルタントなら語れる。だから、コンサルタントを目指す人には夢を語って欲しい。そつのない答えばかりじゃつまらないよ。
中学時代までの私は、どちらかといえば頭でっかちで感情をあまり表に出さないタイプだった。好きだったアマチュア無線に自分を閉じ込めていた。そんな自分を変えたくて、高校でテニス部に入部した。それから自分を思い切って表現できるようになった。スポーツは自分のやってきたことが勝ち負けという結果ではっきり出て、言い訳がきかない。負けた時は、なぜ負けたのかを考えて絶対克服してやるぞってガムシャラに練習した。苦手だったバックハンドもいつの間にか得意になっていた。できないことも、理由を見つけて解決すれば必ずできるようになる。テニスで学んだことは、今の仕事にも生きている。
24歳。
大学は工学部。電気電子を専攻して、大学院では風力発電の研究をしていた。テーマとしては非常に面白かったが、それを仕事にすることには疑問を感じていた。教授の推薦で、あるメーカーを受けてみたもののどうもしっくりこない。同じインフラに関わる仕事なら、研究室に閉じこもってやるのではなく、ヒューマンなコミュニケーションを通して実践したかった。どうせ働くなら社会のフロントに立ち、世界を股にかけるような大きな仕事をしてみたいとも思っていた。悩んでいた時、就職情報誌で見つけたのがアクセンチュアだった。コンサルティングという仕事については何もわからなかったけれど、自分の想いを実現できそうな気がした。目の前にいくつかの選択肢がある時、私は自分がより前向きに生きられそうな方を選ぶ。
28歳。
入社4年目、企画系のプロジェクトに初めて携わった。それまで担当していたシステム系のプロジェクトと比較すると、与えられる課題も解決方法もまったく違っていた。戸惑いの中で参加した最初のプロジェクトは、自分としては明らかに失敗だった。自分なりに一生懸命やったものの期待に添うことができなかった。アクセンチュアは積極的な失敗には寛容な会社だと思う。でも、同じことで二度の失敗は許されない。自分は企画系には向いていない。リスクだけを考えれば、そう決断を下してそのプロジェクトを離れることもできなくはなかったが、それだけはイヤだった。もしあの時に逃げていたら、今の仕事との出会いはなかったと思う。
32歳。
今、ある業界に今までにないビジネスの仕組みを導入するプロジェクトを担当している。海外での様々なプロジェクト経験や業界の方々とのお付き合いを通して「自分の頭の中に思い描いていたこと」と、社会の環境がピタッと合ってスタートしたプロジェクト。業界全体の旗振りのような役割をしているので大きな責任とプレッシャーを感じている。でも、実現したら業界のビジネスそのものを大きく変革することができる。アクセンチュアでやりたいと思っていたことに、ようやく辿り着けた。このプロジェクトを死んでもものにしたい。コンサルタントという職業の面白さと醍醐味は、夢を語れるところにある。一プレイヤーでは語れない夢も、コンサルタントなら語れる。だから、コンサルタントを目指す人には夢を語って欲しい。そつのない答えばかりじゃつまらないよ。
どっか抜けてる、ストイック
高校時代。
自分で言うのもなんだけれど、小・中学校時代は真面目を絵に描いたような模範的な子供だった。そのせいか高校に入って反動が出た。きっかけは軽音楽部で知り合った友人たちだった。バンドを組んで、音楽ばっかりやっていて、授業はしょっちゅうさぼったし、不良を気取ってバカなこともした。でも、ほんとに魅力的な仲間たちだった。バンド仲間のうち3人は大学に行かずに自分の好きな道を選んだが、それは進学校だったその高校でちょっとした事件だった。自分にはそこまでの勇気はなかった。「将来、何になりたい？」という問いには、まだ答えられなかった。
浪人時代。
今から考えると、不思議な1年だった。浪人中に昭和天皇が亡くなり、バブルはそのピークを迎えようとしていた。19歳の自分の目にも、世の中が大きく変わろうとしているのがわかった。経済やビジネスというものに、初めて興味を持った。いま目の前で起こっている出来事の原因や本質はどこにあるんだろう？ いろんな人がいろんなことを言っていたが、どれもこれも何か違うような気がして、自分なりに調べてみることにした。そんなことばかりやっていたら、志望学部を落ちた。
大学時代。
新しく知り合った仲間たちとバンド活動を再開したが、浪人時代に目覚めた興味は音楽だけには留まっていなかった。海外旅行もそのひとつ。お金を貯めて年に一度海外でホームステイした。旅行の度に自分の思考のフレームが大きくなっていくような気がした。海外に行くと、そこにあって日本にないものを探した。コレは日本に持ってきたら絶対当たるなと思ったら、次の年に商社が輸入したりして、自分の感覚にちょっと自信を持った。当時ブームだった学生起業家の話を聞きに行ったりしたこともある。こんなふうにして私のやりたいことは、音楽からビジネスに入れ替わった。でも、ずっと一緒にやってきたバンド仲間に、音楽を辞めると言い出すのはつらかった。自分以外のメンバーはプロ志向で、デビューの可能性があっただけになおさらだ。最後のライブ。楽屋で泣いた。あの時から楽器には触っていない。
アクセンチュア入社後。
面接で会った人たちにインスピレーションを感じて、アクセンチュアに入社して以来9年。これまでさまざまな業種のクライアントを相手にプロジェクトを経験してきた。すべてのプロジェクトが思い出深く、その度に自分は成長できたと思っている。延べ2年間にわたる海外での経験も、より高い視点を持つ時間として有意義だった。他の会社で働いた経験はないけれど、アクセンチュアのような環境を提供してくれる会社はそうはないと思っている。でも、この環境に甘えたくない。仕事にはいつも後がないという気持ちで向かい、それがコンサルタントとして生きている最低限の心構えだと思っている。失敗してもどうにかなるだろう、転職すればいいやとは絶対に思いたくない。それに、もしそんないい加減な気持ちでこの仕事をしていたら、あの仲間たちに笑われてしまう。「なんだよ、お前が音楽の代わりに選んだものって、そんなもんだったのかよ」って、ね。
自分で言うのもなんだけれど、小・中学校時代は真面目を絵に描いたような模範的な子供だった。そのせいか高校に入って反動が出た。きっかけは軽音楽部で知り合った友人たちだった。バンドを組んで、音楽ばっかりやっていて、授業はしょっちゅうさぼったし、不良を気取ってバカなこともした。でも、ほんとに魅力的な仲間たちだった。バンド仲間のうち3人は大学に行かずに自分の好きな道を選んだが、それは進学校だったその高校でちょっとした事件だった。自分にはそこまでの勇気はなかった。「将来、何になりたい？」という問いには、まだ答えられなかった。
浪人時代。
今から考えると、不思議な1年だった。浪人中に昭和天皇が亡くなり、バブルはそのピークを迎えようとしていた。19歳の自分の目にも、世の中が大きく変わろうとしているのがわかった。経済やビジネスというものに、初めて興味を持った。いま目の前で起こっている出来事の原因や本質はどこにあるんだろう？ いろんな人がいろんなことを言っていたが、どれもこれも何か違うような気がして、自分なりに調べてみることにした。そんなことばかりやっていたら、志望学部を落ちた。
大学時代。
新しく知り合った仲間たちとバンド活動を再開したが、浪人時代に目覚めた興味は音楽だけには留まっていなかった。海外旅行もそのひとつ。お金を貯めて年に一度海外でホームステイした。旅行の度に自分の思考のフレームが大きくなっていくような気がした。海外に行くと、そこにあって日本にないものを探した。コレは日本に持ってきたら絶対当たるなと思ったら、次の年に商社が輸入したりして、自分の感覚にちょっと自信を持った。当時ブームだった学生起業家の話を聞きに行ったりしたこともある。こんなふうにして私のやりたいことは、音楽からビジネスに入れ替わった。でも、ずっと一緒にやってきたバンド仲間に、音楽を辞めると言い出すのはつらかった。自分以外のメンバーはプロ志向で、デビューの可能性があっただけになおさらだ。最後のライブ。楽屋で泣いた。あの時から楽器には触っていない。
アクセンチュア入社後。
面接で会った人たちにインスピレーションを感じて、アクセンチュアに入社して以来9年。これまでさまざまな業種のクライアントを相手にプロジェクトを経験してきた。すべてのプロジェクトが思い出深く、その度に自分は成長できたと思っている。延べ2年間にわたる海外での経験も、より高い視点を持つ時間として有意義だった。他の会社で働いた経験はないけれど、アクセンチュアのような環境を提供してくれる会社はそうはないと思っている。でも、この環境に甘えたくない。仕事にはいつも後がないという気持ちで向かい、それがコンサルタントとして生きている最低限の心構えだと思っている。失敗してもどうにかなるだろう、転職すればいいやとは絶対に思いたくない。それに、もしそんないい加減な気持ちでこの仕事をしていたら、あの仲間たちに笑われてしまう。「なんだよ、お前が音楽の代わりに選んだものって、そんなもんだったのかよ」って、ね。
天邪鬼な情熱家
16歳。
あまのじゃくな性格、だと思う。他人とは違うことをやりたいという気持ちが、いつもどこかにある。高校時代は絵を描いていた。普通科の進学校。賢いやつらばかりの中で、自分の賢さが消えた時、アイデンティティを表現するのは好きな絵しかないと思った。内緒でアルバイトをして、稼いだお金で美大の受験予備校に通っていた。シュールレアリスムやダダイズムに憧れて、無意識を絵にしたいと思った。あの頃の絵を見ると、暗くて、青臭くて、恥ずかしい。でも、いろんな矛盾を抱えながら必死になって闘っていた10代の自分が確かにそこにいたんだなって、思う。
18歳。
結局、絵の道は諦めて、英文科へ進んだ。しばらくは特にやることもなく、ぶらぶらしていた夏、地元の木曽川べりを車で走っていたら、ウィンドサーファーたちが風に乗ってかっとんでいた。なぜか無性に感動し、これだ！と思った。すぐにショップに駆け込んで、道具一式をローンで買った。その日から、ウィンドサーフィンが生活の一部になる。風のある日は、いつも海か川にいて、そこには、いつもの仲間たちがいた。3年の時、ライダーと呼ばれるスポンサー付きのセミプロになった。できることなら、プロになりたかった。でも、ウィンドだけじゃ食っていけないこともわかっていたから、すぱっと諦めた。中途半端は好きじゃない。
22歳。
就職先にこだわりはなかった。銀行、住宅メーカー、情報関係の出版社、消防士の試験まで受けた。どこも面白そうだったけれど、どこも決め手に欠けた。就職活動のシーズンも終わりに近づいた頃、アクセンチュアのセミナーがあった。そこに行くまで、コンサルタントにはどこか人間味に欠けた冷たいイメージを持っていた。でも、それはまったくの誤解だった。セミナーでも個別面談でも、語りかけてくるアクセンチュアの社員たちは、みんな情熱的で熱かった。彼らの目は、風が吹けば必ず集まってくるウィンドサーファーたちにどこか似ているような気がした。受け身ではなく、自発的にやれるような仕事がしたい。そう思っていた僕にとって、アクセンチュアは最高の場であるように思えた。
25歳。
入社以来、クライアント企業の情報システム部門の仕事に携わることが多い。とても充実した5年間だったけれど、一度だけ会社を辞めようかなと思ったことがある。上司にさりげなく相談したら、僕の気持ちを見透かすように言われた。「おまえは、アクセンチュアでできることをやったのか？」はっとした。その頃の自分は、わがままだった。やりたい仕事ができないと焦り、それを環境や誰かのせいにしていたのだと思う。自発的に働きたくてアクセンチュアに入ったのに、なんのことはない受け身で仕事をしていたのだ。上司の一言で、意識が変わった。与えられた仕事だけでなく、自分から働きかけるようになった。働きかければチャンスはやってくる。コアコンピタンスがないこと。それが僕の強みなんじゃないかと思っている。僕はあらゆることに興味が持てる。環境が変わっても全然苦にならないし、目標に向う瞬発力とスピードにはちょっと自信がある。マネジャーになった今も、「市川をつっこめば、なんとかなる」、と頼られる存在であり続けたい。
あまのじゃくな性格、だと思う。他人とは違うことをやりたいという気持ちが、いつもどこかにある。高校時代は絵を描いていた。普通科の進学校。賢いやつらばかりの中で、自分の賢さが消えた時、アイデンティティを表現するのは好きな絵しかないと思った。内緒でアルバイトをして、稼いだお金で美大の受験予備校に通っていた。シュールレアリスムやダダイズムに憧れて、無意識を絵にしたいと思った。あの頃の絵を見ると、暗くて、青臭くて、恥ずかしい。でも、いろんな矛盾を抱えながら必死になって闘っていた10代の自分が確かにそこにいたんだなって、思う。
18歳。
結局、絵の道は諦めて、英文科へ進んだ。しばらくは特にやることもなく、ぶらぶらしていた夏、地元の木曽川べりを車で走っていたら、ウィンドサーファーたちが風に乗ってかっとんでいた。なぜか無性に感動し、これだ！と思った。すぐにショップに駆け込んで、道具一式をローンで買った。その日から、ウィンドサーフィンが生活の一部になる。風のある日は、いつも海か川にいて、そこには、いつもの仲間たちがいた。3年の時、ライダーと呼ばれるスポンサー付きのセミプロになった。できることなら、プロになりたかった。でも、ウィンドだけじゃ食っていけないこともわかっていたから、すぱっと諦めた。中途半端は好きじゃない。
22歳。
就職先にこだわりはなかった。銀行、住宅メーカー、情報関係の出版社、消防士の試験まで受けた。どこも面白そうだったけれど、どこも決め手に欠けた。就職活動のシーズンも終わりに近づいた頃、アクセンチュアのセミナーがあった。そこに行くまで、コンサルタントにはどこか人間味に欠けた冷たいイメージを持っていた。でも、それはまったくの誤解だった。セミナーでも個別面談でも、語りかけてくるアクセンチュアの社員たちは、みんな情熱的で熱かった。彼らの目は、風が吹けば必ず集まってくるウィンドサーファーたちにどこか似ているような気がした。受け身ではなく、自発的にやれるような仕事がしたい。そう思っていた僕にとって、アクセンチュアは最高の場であるように思えた。
25歳。
入社以来、クライアント企業の情報システム部門の仕事に携わることが多い。とても充実した5年間だったけれど、一度だけ会社を辞めようかなと思ったことがある。上司にさりげなく相談したら、僕の気持ちを見透かすように言われた。「おまえは、アクセンチュアでできることをやったのか？」はっとした。その頃の自分は、わがままだった。やりたい仕事ができないと焦り、それを環境や誰かのせいにしていたのだと思う。自発的に働きたくてアクセンチュアに入ったのに、なんのことはない受け身で仕事をしていたのだ。上司の一言で、意識が変わった。与えられた仕事だけでなく、自分から働きかけるようになった。働きかければチャンスはやってくる。コアコンピタンスがないこと。それが僕の強みなんじゃないかと思っている。僕はあらゆることに興味が持てる。環境が変わっても全然苦にならないし、目標に向う瞬発力とスピードにはちょっと自信がある。マネジャーになった今も、「市川をつっこめば、なんとかなる」、と頼られる存在であり続けたい。
NECソフトが中国でのオフショア開発に失敗で20億円の損
NECソフトは中国でのオフショア開発に失敗し、多額の損失を出した。中国に発注していたJavaによる大規模な販売物流システムの開発が難航し、このプロジェクトだけで上半期に約10億円の損失を出した。下半期と合わせると損失は20億円程度に膨らむ模様だ。オフショア開発は、コスト削減を目的に海外のソフト会社へ開発を委託すること。
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20031024/135886/
---
人件費の安い中国に、生産拠点を移す製造業と同じように、実はコンピュータの世界でも開発拠点を中国に求めるパターンは多いのです。
以前は、インドに発注するパターンも多かったようですね。
このニュースから２つのことが読み取れるのです。
１．オフショア開発を進めるにあたっては、今までの日本の下請けソフトハウスに発注するのと同じ感覚で発注するのは非常に困難。
それは、言葉の壁、文化の違い、開発拠点との距離の
問題などが原因として挙げられる。
ただ、それは開発「管理」のスキルでカバーが可能だし、事実そうすべき。
今回は不幸にもNECソフトのこのプロジェクトにそれだけのスキルが備わっていなかった、ということ。
実は私の関与している企業でも、中国へのオフショア開発を行っていて、連絡体制の整備は必須の課題となっているのです。
２．オフショア開発でもなぜ中国でこの問題が起こりやすいのか。それは、現在の入国管理行政も一部影響している。
オフショア開発を行うのであれば、連絡窓口としてのコーディネータを配置するのが望ましい。それも、ある程度のシステムスキルを持ち、窓口となる国の言語に堪能で、その国の文化を理解している。。となると、中国での開発ならば、日本人でその役目を担う人材はなかなかいないのではないだろうか？
逆にインドならば、開発に携わる人材に限定すれば、英語でのコミュニケートは可能、欧米のビジネス文化にも精通している、ということで、「共通言語」と「共通ビジネス基盤」を持つことになるので、作業がすすめやすく、日本人がコーディネーターとなることができる。
とすると、中国での開発の場合、必然的に中国人のコーディネータを当てることになるのだが、現在の入管行政では外国人の就労については一定の制限を課しているため、容易に日本にやってこれない。仮に日本に滞在できる中国人の場合は、人件費が非常に高いため、コスト削減の目的でのオフショア開発にはうまみが出ない。
ということで、いわゆる人材不足の分野となっているのだ。
この「コーディネータ」をいかなる場合でも確保できなければ、オフショア開発は成功しない。
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20031024/135886/
---
人件費の安い中国に、生産拠点を移す製造業と同じように、実はコンピュータの世界でも開発拠点を中国に求めるパターンは多いのです。
以前は、インドに発注するパターンも多かったようですね。
このニュースから２つのことが読み取れるのです。
１．オフショア開発を進めるにあたっては、今までの日本の下請けソフトハウスに発注するのと同じ感覚で発注するのは非常に困難。
それは、言葉の壁、文化の違い、開発拠点との距離の
問題などが原因として挙げられる。
ただ、それは開発「管理」のスキルでカバーが可能だし、事実そうすべき。
今回は不幸にもNECソフトのこのプロジェクトにそれだけのスキルが備わっていなかった、ということ。
実は私の関与している企業でも、中国へのオフショア開発を行っていて、連絡体制の整備は必須の課題となっているのです。
２．オフショア開発でもなぜ中国でこの問題が起こりやすいのか。それは、現在の入国管理行政も一部影響している。
オフショア開発を行うのであれば、連絡窓口としてのコーディネータを配置するのが望ましい。それも、ある程度のシステムスキルを持ち、窓口となる国の言語に堪能で、その国の文化を理解している。。となると、中国での開発ならば、日本人でその役目を担う人材はなかなかいないのではないだろうか？
逆にインドならば、開発に携わる人材に限定すれば、英語でのコミュニケートは可能、欧米のビジネス文化にも精通している、ということで、「共通言語」と「共通ビジネス基盤」を持つことになるので、作業がすすめやすく、日本人がコーディネーターとなることができる。
とすると、中国での開発の場合、必然的に中国人のコーディネータを当てることになるのだが、現在の入管行政では外国人の就労については一定の制限を課しているため、容易に日本にやってこれない。仮に日本に滞在できる中国人の場合は、人件費が非常に高いため、コスト削減の目的でのオフショア開発にはうまみが出ない。
ということで、いわゆる人材不足の分野となっているのだ。
この「コーディネータ」をいかなる場合でも確保できなければ、オフショア開発は成功しない。
オフショア開発成功の決め手「ブリッジＳＥとは？」
◆日本だけが特殊なのかも知れない。マネジメントのグローバル化
今回はシステム開発コストの削減で注目を集める「オフショア開発」（海外開発）をテーマに、株式会社プライムシステム社主催のもと、実際にオフショア開発に携わるベンダーの方々などを迎え、議論を展開しました。
「オフショア開発」を語るとき、外国の文化に根ざしたマネジメント風土の違いが必ず大きな論点になる。日本の風土や商慣習に慣れ親しんでいると外国のやり方に不満が募ることは少なくない。「日本では当り前のことが通じない。」「日本人のように言外を読むことができない。」など。
日本では、基本的に発注元や上司が出すオーダーに対して、細かく指図しなくても『常識』という共通概念で細部を埋めてくれることを期待する。その常識の範囲内に「ずれ」はない。しかし海外にいくと、その常識に大きな誤差が生じる。また、納期に関して、日本では途中のマイルストーンに(不条理な)変更があっても最終的な納期は必ず守るのが「常識」だが、海外では、途中で何か変更があると納期も当然のことながらずれる。それが顧客の業務に重大な支障をきたすかどうかは関係ない。解決すべき問題が残っていても定時になれば帰る。
確かに問題は多い。しかし「だからオフショア開発は困難だ。うまくいかない。」と言うのは早計である。異なる文化・慣習を持つ外国に行って仕事をするのである。「日本流」が通じないのは当り前である。積極的にオフショアに進出し、成功している企業はまず、「日本だけが特殊である。」という風に発想そのものから転換している。そして現地の文化・慣習を理解するよう務めている。
例えば「言外が読めない」のであれば、日本ではわざわざ言及する必要のない細部まで契約書に明記する。
・契約書で稼動時間を日本の営業時間に合わせるよう明記する。
・情報流出や人材流出を防ぐためのペナルティを盛り込む
など、これらによって防げるトラブルは多い。
そして時間をかけることによって所謂「日本流」も理解され、現地に定着させることが可能だ。しかしこの場合重要なのは、「正しいスタイルである日本流に直させる」のではなく、「日本という国と付き合う上での特殊なレギュレーションとして理解させる」スタンスが必要なことである。つまり、飽くまで「特殊なお客さんの事情に合わせる」ということなのだ。
◆ブリッジＳＥは現地エンジニアの上司たれ。
そうは言ってもマネジメントの真髄は世界中どこへ言っても変わらない。個人主義、契約主義とは言っても、モチベーションが人を動かすことは世界共通の原則である。納期ギリギリの追い込み作業、或いは個人の判断力が問われる業務において高いパフォーマンスを発揮させるには上司との信頼関係が必要である。ここで重要な役割を果たすのが「ブリッジＳＥ」である。ブリッジＳＥというと海外の開発会社に属して日本との橋渡しになる外国人ＳＥのことを指すことが多いが、今回の主催者であるプライムシステムの場合は飽くまで日本に常駐して海外との橋渡しになる日本人ＳＥのことである。
日本のクライアントに直接接して、クラアントの要望を誤解のないように海外に伝え、その進捗をしっかり管理する。オフショア開発の成否はこのブリッジＳＥが優秀か否かにかかっていると言っても過言ではない。しかしブリッジＳＥは発注元の意を汲んだお目付け役ではない。飽くまでオフショアに軸足を置いた現地エンジニアたちの上司の立場にならなければいけない。現地エンジニアの成長に貢献し、成長の喜びを分かち合う役割なのである。そういう信頼関係が築けたときに「この人の依頼なら何とかしよう」というモチベーションからくるダイナミックなパワーが生まれる。
そのような信頼関係を醸成するためにはどうすれば良いのか。同社のブリッジＳＥ鈴木氏はさまざまな細かいテクニックを持っている。しかし、基本的なことは彼らの文化や気質を尊重し、理解したうえでともに成長していこうという意識である。彼らと同じ目線に立たずして信頼関係は生まれない。世界のどこにおいてもあてはまる当り前のことであるが、日本人が海外に進出する際にはとかく忘れがちになることである。
◆コスト削減効果は２５～３０％
オフショアのエンジニアの単価は確かに低い。エンジニア単価だけで考えると日本の３分の１や半分ということになる。ならばＴＣＯも半分か。それは誤解である。まず現状「オフショア開発」と言ったとき、上流の要件定義や基本設計は日本で受けて、詳細設計以降の工程を海外に出すことがほとんどである。当然上流部分は日本で開発するのと同じコストになる。そして優秀なブリッジＳＥがつけばコストもかかる。平均すると国内開発に較べて２５～３０％のコスト削減と言われている。
実力をつけてきた海外開発先が上流部分から受けるケースは将来的には増えるだろう。しかししばらくはコスト削減の期待値はこのレベルの推移と思われる。オフショア開発に対する評価はＴＣＯの削減率だけではなく、オフショア開発に取り組むことによるプロジェクトマネジメントのナレッジを積み上げることも合わせて考えるべきである。オフショアに取り組むことは、結果的に必ずグローバルなマネジメントスタイルとは何かを知ることになるからだ。
今回はシステム開発コストの削減で注目を集める「オフショア開発」（海外開発）をテーマに、株式会社プライムシステム社主催のもと、実際にオフショア開発に携わるベンダーの方々などを迎え、議論を展開しました。
「オフショア開発」を語るとき、外国の文化に根ざしたマネジメント風土の違いが必ず大きな論点になる。日本の風土や商慣習に慣れ親しんでいると外国のやり方に不満が募ることは少なくない。「日本では当り前のことが通じない。」「日本人のように言外を読むことができない。」など。
日本では、基本的に発注元や上司が出すオーダーに対して、細かく指図しなくても『常識』という共通概念で細部を埋めてくれることを期待する。その常識の範囲内に「ずれ」はない。しかし海外にいくと、その常識に大きな誤差が生じる。また、納期に関して、日本では途中のマイルストーンに(不条理な)変更があっても最終的な納期は必ず守るのが「常識」だが、海外では、途中で何か変更があると納期も当然のことながらずれる。それが顧客の業務に重大な支障をきたすかどうかは関係ない。解決すべき問題が残っていても定時になれば帰る。
確かに問題は多い。しかし「だからオフショア開発は困難だ。うまくいかない。」と言うのは早計である。異なる文化・慣習を持つ外国に行って仕事をするのである。「日本流」が通じないのは当り前である。積極的にオフショアに進出し、成功している企業はまず、「日本だけが特殊である。」という風に発想そのものから転換している。そして現地の文化・慣習を理解するよう務めている。
例えば「言外が読めない」のであれば、日本ではわざわざ言及する必要のない細部まで契約書に明記する。
・契約書で稼動時間を日本の営業時間に合わせるよう明記する。
・情報流出や人材流出を防ぐためのペナルティを盛り込む
など、これらによって防げるトラブルは多い。
そして時間をかけることによって所謂「日本流」も理解され、現地に定着させることが可能だ。しかしこの場合重要なのは、「正しいスタイルである日本流に直させる」のではなく、「日本という国と付き合う上での特殊なレギュレーションとして理解させる」スタンスが必要なことである。つまり、飽くまで「特殊なお客さんの事情に合わせる」ということなのだ。
◆ブリッジＳＥは現地エンジニアの上司たれ。
そうは言ってもマネジメントの真髄は世界中どこへ言っても変わらない。個人主義、契約主義とは言っても、モチベーションが人を動かすことは世界共通の原則である。納期ギリギリの追い込み作業、或いは個人の判断力が問われる業務において高いパフォーマンスを発揮させるには上司との信頼関係が必要である。ここで重要な役割を果たすのが「ブリッジＳＥ」である。ブリッジＳＥというと海外の開発会社に属して日本との橋渡しになる外国人ＳＥのことを指すことが多いが、今回の主催者であるプライムシステムの場合は飽くまで日本に常駐して海外との橋渡しになる日本人ＳＥのことである。
日本のクライアントに直接接して、クラアントの要望を誤解のないように海外に伝え、その進捗をしっかり管理する。オフショア開発の成否はこのブリッジＳＥが優秀か否かにかかっていると言っても過言ではない。しかしブリッジＳＥは発注元の意を汲んだお目付け役ではない。飽くまでオフショアに軸足を置いた現地エンジニアたちの上司の立場にならなければいけない。現地エンジニアの成長に貢献し、成長の喜びを分かち合う役割なのである。そういう信頼関係が築けたときに「この人の依頼なら何とかしよう」というモチベーションからくるダイナミックなパワーが生まれる。
そのような信頼関係を醸成するためにはどうすれば良いのか。同社のブリッジＳＥ鈴木氏はさまざまな細かいテクニックを持っている。しかし、基本的なことは彼らの文化や気質を尊重し、理解したうえでともに成長していこうという意識である。彼らと同じ目線に立たずして信頼関係は生まれない。世界のどこにおいてもあてはまる当り前のことであるが、日本人が海外に進出する際にはとかく忘れがちになることである。
◆コスト削減効果は２５～３０％
オフショアのエンジニアの単価は確かに低い。エンジニア単価だけで考えると日本の３分の１や半分ということになる。ならばＴＣＯも半分か。それは誤解である。まず現状「オフショア開発」と言ったとき、上流の要件定義や基本設計は日本で受けて、詳細設計以降の工程を海外に出すことがほとんどである。当然上流部分は日本で開発するのと同じコストになる。そして優秀なブリッジＳＥがつけばコストもかかる。平均すると国内開発に較べて２５～３０％のコスト削減と言われている。
実力をつけてきた海外開発先が上流部分から受けるケースは将来的には増えるだろう。しかししばらくはコスト削減の期待値はこのレベルの推移と思われる。オフショア開発に対する評価はＴＣＯの削減率だけではなく、オフショア開発に取り組むことによるプロジェクトマネジメントのナレッジを積み上げることも合わせて考えるべきである。オフショアに取り組むことは、結果的に必ずグローバルなマネジメントスタイルとは何かを知ることになるからだ。
オフショア開発こそ専門家を使うべき
中国オフショア開発実践セミナー
http://www.ai-coach.com/seminar/top.html
http://www.ai-coach.com/backno/cip0137.html
●成功するブリッジＳＥと失敗するブリッジＳＥを分ける秘訣、そ
れは、「ブリッジＳＥが自分の職務領域を正しく理解している」こ
とである。
●しかしながら、開発知識があり、プロジェクト管理能力に優れ、
しかも日本文化や商慣習の理解も含めた日本語能力がある中国人SE
を調達するのは至難の業である。
●そのような事情から、多くの日本企業では入社1-3年目の若い中国
人社員にブリッジＳＥという肩書きを与えて、開発プロジェクトの
真っ只中に投入する習慣が出来上がってしまった。
●「中国オフショア開発は新規事業である」
私が日ごろからそう訴えているにもかかわらず、無計画のままオフ
ショア開発に若手社員を投入する企業が後を絶たない。
●「彼は日本での留学経験もあるから大丈夫！」などを理由に、入
社間もない中国人社員がブリッジＳＥに仕立て上げられる。中国ベ
ンダにとっても、本人にとっても、ましてや発注側の日本企業にとっ
ても不幸な話だ。
●「オフショア開発こそ、プロジェクトマネジメントの専門家を使
うべきである」
過去にオフショア開発で成功してきた会社には、３年先を見据えた
しっかりとした人材戦略がある。
●では、自社に中国人ＳＥがいないとオフショア開発に挑戦する資
格がないのだろうか？いややい、決してそうではない。以下の条件
が整えば、中国を全く知らない日本人でもオフショア開発のコーディ
ネート業務は十分に可能だ。
・中国に好意的であること
・オフショア開発に前向きであること
・サブリーダの経験があること
・専門家から正しい指導を受けられること
●あなたの会社でも、今すぐ開発コーディネータの育成に着手しよ
う。プロジェクトリーダとしての技術基盤、異文化コミュニケーショ
ン能力、そして専門的な対中交渉テクニックを学ぶ仕組みがオフショ
ア開発における人材育成の要諦だ。
http://www.ai-coach.com/seminar/top.html
http://www.ai-coach.com/backno/cip0137.html
●成功するブリッジＳＥと失敗するブリッジＳＥを分ける秘訣、そ
れは、「ブリッジＳＥが自分の職務領域を正しく理解している」こ
とである。
●しかしながら、開発知識があり、プロジェクト管理能力に優れ、
しかも日本文化や商慣習の理解も含めた日本語能力がある中国人SE
を調達するのは至難の業である。
●そのような事情から、多くの日本企業では入社1-3年目の若い中国
人社員にブリッジＳＥという肩書きを与えて、開発プロジェクトの
真っ只中に投入する習慣が出来上がってしまった。
●「中国オフショア開発は新規事業である」
私が日ごろからそう訴えているにもかかわらず、無計画のままオフ
ショア開発に若手社員を投入する企業が後を絶たない。
●「彼は日本での留学経験もあるから大丈夫！」などを理由に、入
社間もない中国人社員がブリッジＳＥに仕立て上げられる。中国ベ
ンダにとっても、本人にとっても、ましてや発注側の日本企業にとっ
ても不幸な話だ。
●「オフショア開発こそ、プロジェクトマネジメントの専門家を使
うべきである」
過去にオフショア開発で成功してきた会社には、３年先を見据えた
しっかりとした人材戦略がある。
●では、自社に中国人ＳＥがいないとオフショア開発に挑戦する資
格がないのだろうか？いややい、決してそうではない。以下の条件
が整えば、中国を全く知らない日本人でもオフショア開発のコーディ
ネート業務は十分に可能だ。
・中国に好意的であること
・オフショア開発に前向きであること
・サブリーダの経験があること
・専門家から正しい指導を受けられること
●あなたの会社でも、今すぐ開発コーディネータの育成に着手しよ
う。プロジェクトリーダとしての技術基盤、異文化コミュニケーショ
ン能力、そして専門的な対中交渉テクニックを学ぶ仕組みがオフショ
ア開発における人材育成の要諦だ。
オフショア開発、現実のコスト削減率は15％程度
米調査会社のMETA Groupによると、インドなどに開発作業を委託するオフショアアウトソーシング開発プロジェクトで、多くの企業は十分なリスク分析を行っていないという。同社は、実際のコスト削減は予想ほど高くないと指摘し、関心を集めているオフショア開発の導入上の注意を呼びかけている。
META Groupによると、多くの企業は、最大のコスト要因である人件費の削減率がプロジェクト全体の削減率に比例すると期待するが、実際はそうではないという。例えば、インドの開発者の人件費は米国の同レベルのスキルを持つ開発者の6割と言われているが、プロジェクト運行モデルの違いや、隠れたコストが発生することなどから、初年度の実際のコスト削減は15％～20％減にとどまるという。
オフショア開発は、経費削減などのメリットから、米国を中心に近年高い注目を集めており、今後2年間20％～25％増で成長するとされている。同社はこのような傾向に対し、4つのリスク要因を挙げてリスク分析の重要性を訴えている。リスク要因としては、（1）セキュリティ侵害や知的財産保護などの危険性（2）開発費が予算を超えることが多く、15％程度増となることもある（3）文化の違い（4）現地ベンダーへのIT部門間の知識移転で初年度は生産性が下がる―ことを挙げている。
META Groupによると、多くの企業は、最大のコスト要因である人件費の削減率がプロジェクト全体の削減率に比例すると期待するが、実際はそうではないという。例えば、インドの開発者の人件費は米国の同レベルのスキルを持つ開発者の6割と言われているが、プロジェクト運行モデルの違いや、隠れたコストが発生することなどから、初年度の実際のコスト削減は15％～20％減にとどまるという。
オフショア開発は、経費削減などのメリットから、米国を中心に近年高い注目を集めており、今後2年間20％～25％増で成長するとされている。同社はこのような傾向に対し、4つのリスク要因を挙げてリスク分析の重要性を訴えている。リスク要因としては、（1）セキュリティ侵害や知的財産保護などの危険性（2）開発費が予算を超えることが多く、15％程度増となることもある（3）文化の違い（4）現地ベンダーへのIT部門間の知識移転で初年度は生産性が下がる―ことを挙げている。
Wednesday, December 29, 2004
プロジェクトファイル（コンサルティング）
PROJECT FILE 1 旭化成プロジェクト
■「化学業界にeコマースを」
「化学業界はeコマースで進化できるはずだ」とするアクセンチュアと、「eコマースを全社で体系的に導入したい」旭化成の考えが一致。プランニングを任されることに。
エピソード
化学業界の経営革新に深く関わってきた歴史と欧米などで蓄積されたスキルをもとに、アクセンチュアはかなり早い時期から、業界各社へ、eコマースへの取り組みや考え方の啓蒙を行なっていた。そうした中で、もっともすばやく、そしてもっとも熱心な反応を示したのが旭化成であった。業界大手だからこそ、eコマースを通じた経営革新の必要性を感じ取り、時代に先んじて、顧客との関係や社内の仕組みを見直し、最適な形に作り込みたい。まさに、アクセンチュアの提言と旭化成の思考が一致。その瞬間、新たなビジネスがスタートを切った。
■3つの主要事業部門にeコマース・プランニング
経営トップはあえて主要事業からのスタートを決断。
アクセンチュアの提案が各部門のトップを本気にさせた。
そして主導権は、本社から各部門へ。
エピソード
プランニングを行なうにあたって、プレゼンテーションの相手がこれまでの旭化成本社の企画部門から化学関連部門へ移行。ここでも、アクセンチュアの化学業界に対する知識の深さ、そして、その提案内容が部門トップの心を捉えた。トップたちの琴線に触れたのは、化学業界の事例よりも他業界のeコマースの活用例であった。たとえば自動車業界での例。これまで隠すことが常識だった新車開発のプロセスを、デザインの段階からインターネットで公開し、ユーザーと一緒に開発を進めていった某自動車メーカー等のやり方を、化学業界にどう取り込んでいけるか。旭化成のeコマースにどう導入できるのか。こうした新鮮な視点、視野を広げる提案が、ついに各部門トップを本気にさせた。本社から貰った予算ではなく、各部門が自ら予算を投資して、積極的にeコマースに取り組むことを決定したのだ。そしていよいよ、本格的にプロジェクトが発足する。
■プロジェクト発足
プロジェクト発足にあたってメンバーを増員。
3ヵ月間のプランニング・フェーズがスタートし、まずは徹底した情報収集を行なった。
エピソード
プランニングに先立ち、パートナーは、いま一度、世界中のeコマースの先端事例やトレンドについて入念な調査・検証を行った。化学業界に対する本格的なeコマースは日本でも初めての事例。他社が実際に企画し、導入する過程で起こった細かい問題点や解決策まで徹底的に調査し、実現までのプランの方向性を綿密に検証したのだ。プロジェクトのトップであるパートナーが膨大な英語の資料と格闘しながら検証を行なっている間、マネージャーたちは、旭化成社内のヒヤリングに着手。技術部門や営業部門などの課長・部長クラス50人へヒヤリングを行ない、経営トップが把握しきれない現場の声からも現状を把握し、浮き彫りにしていったのである。
■eコマース、それも旭化成ならではの。
実際のプラン策定に向け、顧客との激しい議論が生まれた。徹底したディスカッションを行ない、月に1度の報告会で旭化成との調整を図りながら、彼らに必要な、最適なeコマース・プランを策定していった。
エピソード
実は、最初の報告会は、激しい議論の応酬になった。第1回目の報告ということもあり、アクセンチュア側は基本コンセプトをまとめることに重点を置いていた。eコマース導入後のイメージが明確にならない苛立ちと、導入後への期待感が大きい旭化成側は、コンセプト主体の話から具体像を掴むことができず、「ありきたりなプラン」という誤解を生んでしまったのだ。プロジェクトチームは期待に応えるべく、奮起し、議論を重ね、旭化成にとって必要な2つのeコマースを提示する。業界のトップを切って始めることで価値のある「成功確率の高いスタンダードな、あたり前のeコマース」。これは、あとから他社が真似をする可能性もあるが、最初に始めることで得られるメリットの大きさを明確化して提案した。そしてもうひとつ必要なもの。それが「旭化成ならではの強みを発揮するeコマース」である。事業ごとのマーケットやポジションの強み、サプライチェーン上の強み、競合に対しての強みなど、さまざまな面で旭化成が持っている「強さ」をより高めるeコマースを「あたり前のeコマース」と組み合わせることによって、他社には真似のできない、旭化成オリジナルのeコマースにしていくのだ。旭化成バージョンといえるeコマースを構築する。その答えで両者の視点は一致し、実行段階へのジャンプに成功することができた。
■大型投資家が決定、いよいよeコマース＆経営革新へ
ついに、旭化成の信頼を勝ち取ることに成功。さらにスタッフを増員して、いよいよ開発フェーズへ突入した。しかし、まだその道のりは長い……。
エピソード
「成功確立の高いスタンダードな、あたり前のeコマース」と「旭化成ならではの強みを発揮するeコマース」との組み合わせに、旭化成も納得。大型投資が決定した。これによりアクセンチュアのプロジェクトチームはさらなる増員を決定。業務改革とそれを実現するシステム開発に必要な人材を投入し、実現へと大きく踏み出した。
この時期、旭化成の現場サイドからネガティブな意見が続出する。海外事例をそのまま旭化成に持ってきても、日本でその通りにできるはずがない。現状の業務が一番良いはず・・・というのだ。しかし、アクセンチュアが目指しているものは海外の焼き直しではなく、あくまでも旭化成バージョンのオリジナルeコマースである。それを理解してもらうため、より具体的なeコマースのカタチを提示する必要性をコンサルタントたちは感じ取っていた。
■イメージよりも実物主義で
イメージや一般論ではなく実際の画面に近いHTMLを作り、旭化成の現場スタッフに業務を変革するための具体的な作業を実感してもらうことに。
エピソード
現場スタッフの一部には、「ものすごいものができるのでは」という過度の期待があった。それは、自分たちの今の状況を変えたいという思いによるものではあったが、同時に、eコマースを魔法の杖のように思ってしまっていたからでもあった。そうした状況ではイメージや一般論を語れば語るほど、アクセンチュアが考えている現実的なeコマースの姿と、旭化成スタッフの考える夢のeコマースとがかけ離れていくばかりである。そこでアクセンチュアは、より具体的な作業を実感してもらい、業務を改革していくのは彼ら自身であることを感じてもらうため、実際のシステム画面に近いHTMLをつくり、毎日の業務がどう変わり進化するのかを実感してもらうことにした。 特に「旭化成ならではの強みを発揮するeコマース」の実現にあたっては、業務イメージを正確に伝えていく必要性から、コンサルタントたちは毎週金曜日に集まり、最大の効果を引き出すための業務のあり方は何かを考え、それを実現させるためのロジックを形にしたHTMLを作成。その意図や思想を徹底してディスカッションした。最終的に作られたHTMLは1000枚にものぼったが、実際に使用したのはその1/4にすぎない。一見ムダとも思える作業だが、これがコンサルタント間の意思統一に役立つとともに、旭化成現場スタッフのeコマースへの理解を深め、お互いのイメージ共有にも大きな役割を果たしたのだ。本当の改革を実現するためには、必要不可欠のプロセスだった。
■機能設計スタート
お互いの理解を深めシステムが具体的になるにつれ、eコマース・プランはアクセンチュアと旭化成とのコラボレーションという意識に変化していく。
エピソード
これまで、アクセンチュアには旭化成スタッフをリードしなくては、という思いが強かった。それは、自分たちがプロであり、eコマースについて深い知識があるからこその思いであった。しかし、実際にeコマースを実行するのはアクセンチュアではなく、旭化成のスタッフである。そこで、システム開発が具体化する時期を見計らい、アクセンチュアはナビゲーター役となって一歩後ろへ引き、プロジェクトの主導権を旭化成スタッフへ移行することにした。 すると旭化成スタッフの目の色が、それまでとは変わった。リアクションの少なかったミーティングでも、率直な意見や本音がどんどん飛び出すようになり、議論は活発化した。その結果、「変わりたい」という思いや、「こうしたい」というアイデアは日増しに強まり、トップを動かして決断を得るまで強固なものになっていった。現場がこれほど真剣に、そして本気になったことで、アクセンチュアはこのプロジェクトの成功を確信する。
■システムチェックとユーザーテスト
いよいよシステム完成間近。アクセンチュア側のシステムチェックと、旭化成によるユーザーテストを開始した。
エピソード
ようやくゴールが見え始めたシステム開発。その最終段階として、システムチェックとユーザーテストが始まった。今回のeコマース・システムは、いろいろな面において「初めて」という要素が多い。それだけにシステムチェックでスクラップ＆ビルドを繰り返し、システムの質を高めていく必要がある。また、細かな部分については、システムを実際に使う人たちによるユーザーテストが必要となる。それは単なるシステムテストではなく、人の動きや働き方をどう変えるか、業務をどう変革し結果を生み出すか、という重要なプロセスなのだ。人とビジネスとシステムの全てを知るプロの仕事である。
システムをテストしてもらった時の第一声は「よくできている」であった。それは、アクセンチュアがシステムの裏にある業務を深く理解したうえでシステムを作り、チェックしてきたことの結果である。現場スタッフとコミュニケーションを密にし、積み重ねてきたことのすべてが結実した瞬間であった。
■システム導入
システムは完成した。
2001年春、2001年夏と立て続けに「成功確立の高いスタンダードなeコマース」の導入を行い、稼動させた。
一方、2002年初夏「旭化成ならではの強みを発揮するeコマース」はパイロット運用というカタチで船出をする。
エピソード
なぜ「旭化成ならではの強みを発揮するeコマース」を、既に稼動しているeコマースと同様にシステム完成後いきなり実践投入しないのか？ 今回の「旭化成ならでは」のeコマースには大きな業務改革が必要であり、しかも、旭化成はこれまでにも多くの業務改革を実行してきた経験（しかもすべてに成果が出ているとはいいがたい経験）から、大きな変革をともなう新たなシステム導入に対してネガティブな人が旭化成社内に存在することも事実だったのである。そうした人々に、今回のeコマース・システムが有効なものであることを示すためにも、また、前例のないシステムで実績を作る意味でも、パイロット運用が必要なのだ。特定の企業を相手に試運転を行ない、実績を上げることで、その価値を認識してもらおうという考えだった。まもなくパイロット運用が稼動する。それが成功した時、旭化成バージョンのeコマースは、本当のスタートを切ることになる。
■「化学業界にeコマースを」
「化学業界はeコマースで進化できるはずだ」とするアクセンチュアと、「eコマースを全社で体系的に導入したい」旭化成の考えが一致。プランニングを任されることに。
エピソード
化学業界の経営革新に深く関わってきた歴史と欧米などで蓄積されたスキルをもとに、アクセンチュアはかなり早い時期から、業界各社へ、eコマースへの取り組みや考え方の啓蒙を行なっていた。そうした中で、もっともすばやく、そしてもっとも熱心な反応を示したのが旭化成であった。業界大手だからこそ、eコマースを通じた経営革新の必要性を感じ取り、時代に先んじて、顧客との関係や社内の仕組みを見直し、最適な形に作り込みたい。まさに、アクセンチュアの提言と旭化成の思考が一致。その瞬間、新たなビジネスがスタートを切った。
■3つの主要事業部門にeコマース・プランニング
経営トップはあえて主要事業からのスタートを決断。
アクセンチュアの提案が各部門のトップを本気にさせた。
そして主導権は、本社から各部門へ。
エピソード
プランニングを行なうにあたって、プレゼンテーションの相手がこれまでの旭化成本社の企画部門から化学関連部門へ移行。ここでも、アクセンチュアの化学業界に対する知識の深さ、そして、その提案内容が部門トップの心を捉えた。トップたちの琴線に触れたのは、化学業界の事例よりも他業界のeコマースの活用例であった。たとえば自動車業界での例。これまで隠すことが常識だった新車開発のプロセスを、デザインの段階からインターネットで公開し、ユーザーと一緒に開発を進めていった某自動車メーカー等のやり方を、化学業界にどう取り込んでいけるか。旭化成のeコマースにどう導入できるのか。こうした新鮮な視点、視野を広げる提案が、ついに各部門トップを本気にさせた。本社から貰った予算ではなく、各部門が自ら予算を投資して、積極的にeコマースに取り組むことを決定したのだ。そしていよいよ、本格的にプロジェクトが発足する。
■プロジェクト発足
プロジェクト発足にあたってメンバーを増員。
3ヵ月間のプランニング・フェーズがスタートし、まずは徹底した情報収集を行なった。
エピソード
プランニングに先立ち、パートナーは、いま一度、世界中のeコマースの先端事例やトレンドについて入念な調査・検証を行った。化学業界に対する本格的なeコマースは日本でも初めての事例。他社が実際に企画し、導入する過程で起こった細かい問題点や解決策まで徹底的に調査し、実現までのプランの方向性を綿密に検証したのだ。プロジェクトのトップであるパートナーが膨大な英語の資料と格闘しながら検証を行なっている間、マネージャーたちは、旭化成社内のヒヤリングに着手。技術部門や営業部門などの課長・部長クラス50人へヒヤリングを行ない、経営トップが把握しきれない現場の声からも現状を把握し、浮き彫りにしていったのである。
■eコマース、それも旭化成ならではの。
実際のプラン策定に向け、顧客との激しい議論が生まれた。徹底したディスカッションを行ない、月に1度の報告会で旭化成との調整を図りながら、彼らに必要な、最適なeコマース・プランを策定していった。
エピソード
実は、最初の報告会は、激しい議論の応酬になった。第1回目の報告ということもあり、アクセンチュア側は基本コンセプトをまとめることに重点を置いていた。eコマース導入後のイメージが明確にならない苛立ちと、導入後への期待感が大きい旭化成側は、コンセプト主体の話から具体像を掴むことができず、「ありきたりなプラン」という誤解を生んでしまったのだ。プロジェクトチームは期待に応えるべく、奮起し、議論を重ね、旭化成にとって必要な2つのeコマースを提示する。業界のトップを切って始めることで価値のある「成功確率の高いスタンダードな、あたり前のeコマース」。これは、あとから他社が真似をする可能性もあるが、最初に始めることで得られるメリットの大きさを明確化して提案した。そしてもうひとつ必要なもの。それが「旭化成ならではの強みを発揮するeコマース」である。事業ごとのマーケットやポジションの強み、サプライチェーン上の強み、競合に対しての強みなど、さまざまな面で旭化成が持っている「強さ」をより高めるeコマースを「あたり前のeコマース」と組み合わせることによって、他社には真似のできない、旭化成オリジナルのeコマースにしていくのだ。旭化成バージョンといえるeコマースを構築する。その答えで両者の視点は一致し、実行段階へのジャンプに成功することができた。
■大型投資家が決定、いよいよeコマース＆経営革新へ
ついに、旭化成の信頼を勝ち取ることに成功。さらにスタッフを増員して、いよいよ開発フェーズへ突入した。しかし、まだその道のりは長い……。
エピソード
「成功確立の高いスタンダードな、あたり前のeコマース」と「旭化成ならではの強みを発揮するeコマース」との組み合わせに、旭化成も納得。大型投資が決定した。これによりアクセンチュアのプロジェクトチームはさらなる増員を決定。業務改革とそれを実現するシステム開発に必要な人材を投入し、実現へと大きく踏み出した。
この時期、旭化成の現場サイドからネガティブな意見が続出する。海外事例をそのまま旭化成に持ってきても、日本でその通りにできるはずがない。現状の業務が一番良いはず・・・というのだ。しかし、アクセンチュアが目指しているものは海外の焼き直しではなく、あくまでも旭化成バージョンのオリジナルeコマースである。それを理解してもらうため、より具体的なeコマースのカタチを提示する必要性をコンサルタントたちは感じ取っていた。
■イメージよりも実物主義で
イメージや一般論ではなく実際の画面に近いHTMLを作り、旭化成の現場スタッフに業務を変革するための具体的な作業を実感してもらうことに。
エピソード
現場スタッフの一部には、「ものすごいものができるのでは」という過度の期待があった。それは、自分たちの今の状況を変えたいという思いによるものではあったが、同時に、eコマースを魔法の杖のように思ってしまっていたからでもあった。そうした状況ではイメージや一般論を語れば語るほど、アクセンチュアが考えている現実的なeコマースの姿と、旭化成スタッフの考える夢のeコマースとがかけ離れていくばかりである。そこでアクセンチュアは、より具体的な作業を実感してもらい、業務を改革していくのは彼ら自身であることを感じてもらうため、実際のシステム画面に近いHTMLをつくり、毎日の業務がどう変わり進化するのかを実感してもらうことにした。 特に「旭化成ならではの強みを発揮するeコマース」の実現にあたっては、業務イメージを正確に伝えていく必要性から、コンサルタントたちは毎週金曜日に集まり、最大の効果を引き出すための業務のあり方は何かを考え、それを実現させるためのロジックを形にしたHTMLを作成。その意図や思想を徹底してディスカッションした。最終的に作られたHTMLは1000枚にものぼったが、実際に使用したのはその1/4にすぎない。一見ムダとも思える作業だが、これがコンサルタント間の意思統一に役立つとともに、旭化成現場スタッフのeコマースへの理解を深め、お互いのイメージ共有にも大きな役割を果たしたのだ。本当の改革を実現するためには、必要不可欠のプロセスだった。
■機能設計スタート
お互いの理解を深めシステムが具体的になるにつれ、eコマース・プランはアクセンチュアと旭化成とのコラボレーションという意識に変化していく。
エピソード
これまで、アクセンチュアには旭化成スタッフをリードしなくては、という思いが強かった。それは、自分たちがプロであり、eコマースについて深い知識があるからこその思いであった。しかし、実際にeコマースを実行するのはアクセンチュアではなく、旭化成のスタッフである。そこで、システム開発が具体化する時期を見計らい、アクセンチュアはナビゲーター役となって一歩後ろへ引き、プロジェクトの主導権を旭化成スタッフへ移行することにした。 すると旭化成スタッフの目の色が、それまでとは変わった。リアクションの少なかったミーティングでも、率直な意見や本音がどんどん飛び出すようになり、議論は活発化した。その結果、「変わりたい」という思いや、「こうしたい」というアイデアは日増しに強まり、トップを動かして決断を得るまで強固なものになっていった。現場がこれほど真剣に、そして本気になったことで、アクセンチュアはこのプロジェクトの成功を確信する。
■システムチェックとユーザーテスト
いよいよシステム完成間近。アクセンチュア側のシステムチェックと、旭化成によるユーザーテストを開始した。
エピソード
ようやくゴールが見え始めたシステム開発。その最終段階として、システムチェックとユーザーテストが始まった。今回のeコマース・システムは、いろいろな面において「初めて」という要素が多い。それだけにシステムチェックでスクラップ＆ビルドを繰り返し、システムの質を高めていく必要がある。また、細かな部分については、システムを実際に使う人たちによるユーザーテストが必要となる。それは単なるシステムテストではなく、人の動きや働き方をどう変えるか、業務をどう変革し結果を生み出すか、という重要なプロセスなのだ。人とビジネスとシステムの全てを知るプロの仕事である。
システムをテストしてもらった時の第一声は「よくできている」であった。それは、アクセンチュアがシステムの裏にある業務を深く理解したうえでシステムを作り、チェックしてきたことの結果である。現場スタッフとコミュニケーションを密にし、積み重ねてきたことのすべてが結実した瞬間であった。
■システム導入
システムは完成した。
2001年春、2001年夏と立て続けに「成功確立の高いスタンダードなeコマース」の導入を行い、稼動させた。
一方、2002年初夏「旭化成ならではの強みを発揮するeコマース」はパイロット運用というカタチで船出をする。
エピソード
なぜ「旭化成ならではの強みを発揮するeコマース」を、既に稼動しているeコマースと同様にシステム完成後いきなり実践投入しないのか？ 今回の「旭化成ならでは」のeコマースには大きな業務改革が必要であり、しかも、旭化成はこれまでにも多くの業務改革を実行してきた経験（しかもすべてに成果が出ているとはいいがたい経験）から、大きな変革をともなう新たなシステム導入に対してネガティブな人が旭化成社内に存在することも事実だったのである。そうした人々に、今回のeコマース・システムが有効なものであることを示すためにも、また、前例のないシステムで実績を作る意味でも、パイロット運用が必要なのだ。特定の企業を相手に試運転を行ない、実績を上げることで、その価値を認識してもらおうという考えだった。まもなくパイロット運用が稼動する。それが成功した時、旭化成バージョンのeコマースは、本当のスタートを切ることになる。
Sunday, September 26, 2004
给中国学生的第三封信：成功、自信、快乐
http://home.comcast.net/~kaifulee/kflwritings/Letter3.htm
给中国学生的第三封信：成功、自信、快乐
李开复2004年5月
此前，我和中国学生的多次交流都是围绕如何达到优秀和卓越、如何成为领导人才而展开的。最近，在新浪网的聊天室和我收到的许多电子邮件中，我发现更多的中国学生需要知道的不是如何从优秀到卓越，而是如何从迷茫到积极、从失败到成功、从自卑到自信、从惆怅到快乐、从恐惧到乐观。
一个极端的例子是2004年2月发生在云南大学的马加爵事件。马加爵残忍地杀害了自己的4名同学。但从马家爵被捕后与心理学家的对话内容看来，他应该不是一个邪恶的人，而是一个迷失方向、缺乏自信、性格封闭的孩子。他和很多大学生一样，迫切希望知道如何才能获得成功、自信和快乐。
我这一封信是写给那些渴望成功但又觉得成功遥不可及，渴望自信却又总是自怨自艾，渴望快乐但又不知快乐为何物的学生看的。希望这封信能够带给读者一个关于成功的崭新定义，鼓励读者认识和肯定自己，做一个快乐的人。也希望这封信能够帮助读者理解成功、自信、快乐是一个良性循环：从成功里可以得到自信和快乐，从自信里可以得到快乐和成功，从快乐里可以得到成功和自信。
成功就是成为最好的你自己
美国作家威廉·福克纳说过：“不要竭尽全力去和你的同僚竞争。你应该在乎的是，你要比现在的你强。”
中国社会有个通病，就是希望每个人都照一个模式发展，衡量每个人是否“成功”采用的也是一元化的标准：在学校看成绩，进入社会看名利。尤其是在今天的中国,人们对财富的追求首当其冲，各行各业,对一个人的成功的评价，更多地以个人财富为指标。但是，有了最好的成绩就能对社会有所贡献吗？有名利就一定能快乐吗？
真正的成功应是多元化的。成功可能是你创造了新的财富或技术，可能是你为他人带来了快乐，可能是你在工作岗位上得到了别人的信任，也可能是你找到了回归自我、与世无争的生活方式。每个人的成功都是独一无二的。所以，凌志军在其《成长》一书中得出的重要结论是“成为最好的你自己”。也就是说，成功不是要和别人相比，而是要了解自己，发掘自己的目标和兴趣，努力不懈地追求进步，让自己的每一天都比昨天更好。
成功的第一步：把握人生目标，做一个主动的人
在新浪聊天室里，当网友问我的人生目标是什么时，我是这么回答的：“人生只有一次，我认为最重要的就是要有最大的影响力（impact），能够帮助自己、帮助家庭、帮助国家、帮助世界、帮助后人，能够让他们的日子过得更好、更有效率，能够为他们带来幸福和快乐。”我回答这个问题时丝毫不需要思考，因为我从大学二年级起就把“影响力”当作自己的人生目标。
对我来说，人生目标不是一个口号，而是我最好的智囊，它曾多次帮我解决工作和生活中的难题。我当初放弃在美国的工作，只身来到中国创立微软中国研究院，就是因为我觉得后一项工作有更大的影响力，和我的人生目标更加吻合。此外，当我收到一封封迷茫学生的来信，给他们写回信时，我也会想：“如何让回信有更大的影响力？”我先后公开的三封“给中国学生的信”都是如此诞生的。
马加爵也悟出了他的人生目标，只可惜他是在案发被捕后才悟出的。他说：“姐，现在我对你讲一次真心话，我这个人最大的问题就是出在我觉得人生的意义到底是为了什么？……在这次事情以后，此时此刻我明白了，我错了。其实人生的意义在于人间有真情。”如果马加爵能早几个月悟出人生目标，他在做傻事前就会问问自己，充满真情的父母、姐姐会怎么看待这件事？这样，他可能就不会走上歧途了。
所以，无论是为了真情，为了影响力，还是为了快乐、家人、道德、宁静、求知、创新……一旦确定了人生目标，你就可以像我一样在人生目标的指引下，果断地做出人生中的重大决定。每个人的人生目标都是独特的。最重要的是，你要主动把握自己的人生目标。但你千万不能操之过急，更不要为了追求所谓的“崇高”，或为了模仿他人而随便确定自己的目标。
那么，该怎么去发现自己的目标呢？许多同学问我他们的目标该是什么？我无法回答，因为只有一个人能告诉你人生的目标是什么，那个人就是你自己。只有一个地方你能找到你的目标，那就是你心里。
我建议你闭上眼睛，把第一个浮现在你脑海里的理想记录下来，因为不经过思考的答案是最真诚的。或者，你也可以回顾过去，在你最快乐、最有成就感的时光里，是否存在某些共同点？它们很可能就是最能激励你的人生目标了。再者，你也可以想象一下，十五年后，当你达到完美的人生状态时，你将会处在何种环境下？从事什么工作？其中最快乐的事情是什么？当然，你也不妨多和亲友谈谈，听听他们的意见。
成功的第二步：尝试新的领域、发掘你的兴趣
为了成为最好的你自己，最重要的是要发挥自己所有的潜力，追逐最感兴趣和最有激情的事情。当你对某个领域感兴趣时，你会在走路、上课或洗澡时都对它念念不忘，你在该领域内就更容易取得成功。更进一步，如果你对该领域有激情，你就可能为它废寝忘食，连睡觉时想起一个主意，都会跳起来。这时候，你已经不是为了成功而工作，而是为了“享受”而工作了。毫无疑问的，你将会从此得到成功。
相对来说，做自己没有兴趣的事情只会事倍功半，有可能一事无成。即便你靠着资质或才华可以把它做好，你也绝对没有释放出所有的潜力。因此，我不赞同每个学生都追逐最热门的专业，我认为，每个人都应了解自己的兴趣、激情和能力（也就是情商中所说的“自觉”），并在自己热爱的领域里充分发挥自己的潜力。
比尔·盖茨曾说：“每天清晨当你醒来的时候，都会为技术进步给人类生活带来的发展和改进而激动不已。”从这句话中，我们可看出他对软件技术的兴趣和激情。1977年，因为对软件的热爱，比尔·盖茨放弃了数学专业。如果他留在哈佛继续读数学，并成为数学教授，你能想象他的潜力将被压抑到什么程度吗？2002年，比尔·盖茨在领导微软25年后，却又毅然把首席执行官的工作交给了鲍尔默，因为只有这样他才能投身于他最喜爱的工作——担任首席软件架构师，专注于软件技术的创新。虽然比尔·盖茨曾是一个出色的首席执行官，但当他改任首席软件架构师后，他对公司的技术方向做出了重大贡献，更重要的是，他更有激情、更快乐了，这也鼓舞了所有员工的士气。
比尔·盖茨的好朋友，美国最优秀的投资家，华伦·巴菲特也同样认可激情的重要性。当学生请他指示方向时，他总这么回答：“我和你没有什么差别。如果你一定要找一个差别，那可能就是我每天有机会做我最爱的工作。如果你要我给你忠告，这这是我能给你的最好忠告了。”
比尔·盖茨和华伦·巴菲特给我们的另一个启示是，他们热爱的并不是庸俗的、一元化的名利，他们的名利是他们的理想和激情带来的。美国一所著名的经管学院曾做过一个调查，结果发现，虽然大多数学生在入学时都想追逐名利，但在拥有最多名利的校友中，有90%是入学时追逐理想、而非追逐名利的人。
我刚进入大学时，想从事法律或政治工作。一年多后我才发现自己对它没有兴趣，学习成绩也只在中游。但我爱上了计算机，每天疯狂地编程，很快就引起了老师、同学的重视。终于，大二的一天，我做了一个重大的决定：放弃此前一年多在全美前三名的哥伦比亚大学法律系已经修成的学分，转入哥伦比亚大学默默无名的计算机系。我告诉自己，人生只有一次，不应浪费在没有快乐、没有成就感的领域。当时也有朋友对我说，改变专业会付出很多代价，但我对他们说，做一个没有激情的工作将付出更大的代价。那一天，我心花怒放、精神振奋，我对自己承诺，大学后三年每一门功课都要拿A。若不是那天的决定，今天我就不会拥有在计算机领域所取得的成就，而我很可能只是在美国某个小镇上做一个既不成功又不快乐的律师。
即便如此，我对职业的激情还远不能和我父亲相比。我从小一直以为父亲是个不苟言笑的人，直到去年见到父亲最喜爱的两个学生（他们现在都是教授），我才知道父亲是多么热爱他的工作。他的学生告诉我：“李老师见到我们总是眉开眼笑，他为了让我们更喜欢我们的学科，常在我们最喜欢的餐馆讨论。他在我们身上花的时间和金钱，远远超过了他微薄的收入。”我父亲是在70岁高龄，经过从军、从政、写作等职业后才找到了他的最爱——教学。他过世后，学生在他抽屉里找到他勉励自己的两句话：“老牛明知夕阳短，不用扬鞭自奋蹄。”最令人欣慰的是，他在人生的最后一段路上，找到了自己的最爱。
那么，如何寻找兴趣和激情呢？首先，你要把兴趣和才华分开。做自己有才华的事容易出成果，但不要因为自己做得好就认为那是你的兴趣所在。为了找到真正的兴趣和激情，你可以问自己：对于某件事，你是否十分渴望重复它，是否能愉快地、成功地完成它？你过去是不是一直向往它？是否总能很快地学习它？它是否总能让你满足？你是否由衷地从心里（而不只是从脑海里）喜爱它？你的人生中最快乐的事情是不是和它有关？当你这样问自己时，注意不要把你父母的期望、社会的价值观和朋友的影响融入你的答案。
如果你能明确回答上述问题，那你就是幸运的，因为大多数学生在大学四年里都在摸索或悔恨。如果你仍未找到这些问题的答案，那我只有一个建议：给自己最多的机会去接触最多的选择。记得我刚进卡内基·梅隆的博士班时，学校有一个机制，允许学生挑老师。在第一个月里，每个老师都使尽全身解数吸引学生。正因为有了这个机制，我才幸运地碰到了我的恩师瑞迪教授，选择了我的博士题目“语音识别”。虽然并不是所有学校都有这样的机制，但你完全可以自己去了解不同的学校、专业、课题和老师，然后从中挑选你的兴趣。你也可以通过图书馆、网络、讲座、社团活动、朋友交流、电子邮件等方式寻找兴趣爱好。唯有接触你才能尝试，唯有尝试你才能找到你的最爱。
我的同事张亚勤曾经说：“那些敢于去尝试的人一定是聪明人。他们不会输，因为他们即使不成功，也能从中学到教训。所以，只有那些不敢尝试的人，才是绝对的失败者。”希望各位同学尽力开拓自己的视野，不但能从中得到教益，而且也能找到自己的兴趣所在。
成功的第三步：针对兴趣，定阶段性目标，一步步迈进
找到了你的兴趣，下一步该做的就是制定具体的阶段性目标，一步步向自己的理想迈进。
首先，你应客观地评估距离自己的兴趣和理想还差些什么？是需要学习一门课、读一本书、做一个更合群的人、控制自己的脾气还是成为更好的演讲者？十五年后成为最好的自己和今天的自己会有什么差别？还是其他方面？你应尽力弥补这些差距。例如，当我决定我一生的目的是要让我的影响力最大化时，我发现我最欠缺的是演讲和沟通能力。我以前是一个和人交谈都会脸红，上台演讲就会恐惧的学生。我做助教时表现特别差，学生甚至给我取了个“开复剧场”的绰号。因此，为了实现我的理想，我给自己设定了多个提高演讲和沟通技巧的具体目标。
其次，你应定阶段性的、具体的目标，再充分发挥中国人的传统美德——勤奋、向上和毅力，努力完成目标。比如，我要求自己每个月做两次演讲，而且每次都要我的同学或朋友去旁听，给我反馈意见。我对自己承诺，不排练三次，决不上台演讲。我要求自己每个月去听演讲，并向优秀的演讲者求教。有一个演讲者教了我克服恐惧的几种方法，他说，如果你看着观众的眼睛会紧张，那你可以看观众的头顶，而观众会依然认为你在看他们的脸，此外，手中最好不要拿纸而要握起拳来，那样，颤抖的手就不会引起观众的注意。当我反复练习演讲技巧后，我自己又发现了许多秘诀，比如：不用讲稿，通过讲故事的方式来表达时，我会表现得更好，于是，我仍准备讲稿但只在排练时使用；我发现我回答问题的能力超过了我演讲的能力，于是，我一般要求多留时间回答问题；我发现自己不感兴趣的东西就无法讲好，于是，我就不再答应讲那些我没有兴趣的题目。几年后，我周围的人都夸我演讲得好，甚至有人认为我是个天生的好演说家，其实，我只是实践了中国人勤奋、向上和毅力等传统美德而已。
任何目标都必须是实际的、可衡量的目标，不能只是停留在思想上的口号或空话。制定目标的目的是为了进步，不去衡量你就无法知道自己是否取得了进步。所以，你必须把抽象的、无法实施的、不可衡量的大目标简化成为实际的、可衡量的小目标。举例来说，几年前，我有一个目标是扩大我在公司里的人际关系网，但“多认识人”或“增加影响力”的目标是无法衡量和实施的，我需要找一个实际的、可衡量的目标。于是，我要求自己“每周和一位有影响力的人吃饭，在吃饭的过程，要这个人再介绍一个有影响的人给我”。衡量这个目标的标准是“每周与一人一餐、餐后再认识一人”。当然，我不会满足于这些基本的“指标”。扩大人际关系网的目的是使工作更成功，所以，我还会衡量“每周一餐”中得到了多少信息，有多少我的部门雇用的人是在这样的人际网中认识的。一年后，我的确从这些衡量标准中，看到了自己的关系网有了显著的扩大。
制定具体目标时必须了解自己的能力。目标设定过高固然不切实际，但目标也不可定得太低。对目标还要做及时的调整：如果超出自己的期望，可以把期望提高；如果未达到自己的期望，可以把期望调低。达成了一个目标后，可以再制定更有挑战性的目标；失败时要坦然接受，认真总结教训。
最后，再一次提醒同学们，目标都是属于你的，只有你知道自己需要什么。制定最合适的目标，主动提升自己，并在提升过程中客观地衡量进度，这样才能获得成功，才能成为更好的你自己。
自信是自觉而非自傲
自信的人敢于尝试新的领域，能更快地发展自己的兴趣和才华，更容易获得成功。自信的人也更快乐，因为他不会时刻担心和提防失败。
很多人认为自信就是成功。一个学生老得第一名，他有了自信。一个员工总是被提升，他也有了自信。但这只是一元化的成功和一元化的自信。
其实，自信不一定都是好事。没有自觉的自信会成为自傲，反而会失去了别人的尊重和信赖。好的自信是自觉的，即很清楚自己能做什么，不能做什么。自觉的人自信时，他成功的概率非常大；自觉的人不自信时，他仍可努力尝试，但会将风险坦诚地告诉别人。自觉的人不需要靠成功来增强自信，也不会因失败而丧失自信。
自信的第一步：不要小看自己，多给自己打气
“自”信的关键在于自己。如果你自己总认为自己不行，你是无法得到自信的。例如，马加爵曾说：“我觉得我太失败的，同学都看不起我……很多人比我老练，让我很自卑。”虽然马加爵很聪明也很优秀，但他从没有真正自信过。
自信的秘密是相信自己有能力。中国古谚：“天生我才必有用”，“一枝草，一点露”，每个人都有自己的特性和长处，值得看重和发挥。我记得我11岁刚到美国时，课堂上一句英语都听不懂，有一次老师问“1/7换算成小数等于几？”我虽然不懂英文，但认得黑板上的“1/7”，这是我以前“背”过的。我立刻举手并正确回答了这个问题。不会“背书”的美国老师诧异地认为我是个“数学天才”，并送我去参加数学竞赛，鼓励我加入数学夏令营，帮助同学学习数学。她的鼓励和同学的认可给了我自信。我开始告诉自己，我有数学的天分。这时，我特别想把英文学好，因为只有这样才能学习更多的数学知识。这种教育方式不但提高了我的自信，也帮助我在各方面取得了长足的进步。
中国式教育认为人的成长是不断克服缺点的过程，所以老师更多是在批评学生，让学生弥补最差的学科。虽然应把每科都学得“足够好”，但人才的价值在于充分发挥个人最大的优点。美国盖洛普公司最近出了一本畅销书《现在，发掘你的优势》。盖洛普的研究人员发现：大部分人在成长过程中都试着“改变自己的缺点，希望把缺点变为优点”，但他们却碰到了更多的困难和痛苦；而少数最快乐、最成功的人的秘诀是“加强自己的优点，并管理自己的缺点”。“管理自己的缺点”就是在不足的地方做得足够好，“加强自己的优点”就是把大部分精力花在自己有兴趣的事情上，从而获得无比的自信。
凌志军的《成长》一书里还有很多得到自信的例子：微软亚洲工程院院长张宏江说他从小就“相信我是最聪明的。即使再后来的日子里我常常不如别人，但我还是对自己说：我能比别人做得好”；微软亚洲研究院的主任研究员周明小时候在“学生劳动”中刷了108个瓶子，打破了纪录，从而获得自信。他说：“我原来一直是没有自信心的，但是这件事给了我自信。这是我一生中最快乐的经验，散发着一种迷人的力量，一直持续到今天。我发现了天才的全部秘密，其实只有6个字：不要小看自己。”
自信是一种感觉，你没有办法用背书的方法“学习”自信，而唯一靠“学习”提升自信的方法是以实例“训练”你的大脑。要得到自信，你必须成为自己最好的拉拉队，每晚入睡前不妨想想，今天发生了什么值得你自豪的事情？你得到了好的成绩吗？你帮助了别人吗？有什么超出了你的期望吗？有谁夸奖了你吗？我相信每个人每天都可以找到一件成功的事情，你会慢慢发现，这些“小成功”可能会越来越有意义。
有个著名教练在每次球赛前，总会要求队员回忆自己最得意的一次比赛。他甚至让队员把最得意的比赛和一个动作（如紧握拳头）联系起来，以便使自己每次做这个动作时，就会下意识地想到得意的事，然后在每次比赛前反复做这个动作以“训练”大脑，提升自信。
希望同学们都能成为自己最好的拉拉队，同时多结交为你打气的朋友，多回味过去的成功，千万不要小看自己。
自信的第二步：用毅力、勇气，从成功里获得自信，从失败里增加自觉
当你感觉到自信时，无论多么小的成功，你都会特别期望再一次得到自己或别人的肯定，这时，你需要有足够的毅力。只要你有毅力，就会像周明所说的那样，“什么事情只要我肯干，就一定可以干好。你能学会你想学会的任何东西，这不是你能不能学会的问题，而是你想不想学的问题。如果你对自己手里的东西有强烈的欲望，你就会有一种坚韧不拔的精神，尤其当你是普通人的时候。”
有时，你可能没做过某一件事，不知道能不能做成。这时，除了毅力外，你还需要勇气。我以前在工作中，一般的沟通没有问题，但到了总裁面前，总是不敢讲话，怕说错话。直到有一天，公司要做改组，总裁召集十多个人开会，他要求每个人轮流发言。我当时想，既然一定要讲，那不如把心里话讲出来。于是，我鼓足勇气说：“我们这个公司，员工的智商比谁都高，但是我们的效率比谁都差，因为我们整天改组，不顾到员工的感受和想法……”我说完后，整个会议室鸦雀无声。会后，很多同事给我发电子邮件说：“你说得真好，真希望我也有你的胆子这么说。”结果，总裁不但接受了我的建议，改变了公司在改组方面的政策，而且还经常引用我的话。从此，我充满了自信，不惧怕在任何人面前发言。这个例子充分印证了“你没有试过，你怎么知道你不能”这句话。
有勇气尝试新事物的同时，也必须有勇气面对失败。大家不能只凭匹夫之勇去做注定要失败的事。但当你畏惧失败时，不妨想一想，你怕失去什么？最坏的下场是什么？你不能接受吗？在上面的例子中，如果总裁否定了我的看法，他会不尊重我吗？不但不会，别人很可能还会认为我勇气可嘉。而且，自觉的人会从失败中学习，认识到自己不适合做什么事情，再提升自己的自觉。因此，不要畏惧失败，只要你尽了力，愿意向自己的极限挑战，你就应为自己的勇气而自豪。
一个自信和自觉的人，如果能勇敢地尝试新的事物，并有毅力把它做好，他就会从成功里获得自信，从失败里增加自觉。
自信的第三步：自觉地定具体的目标，虚心地听他人的评估
培养自信也要设定具体的目标，一步步地迈进。这些目标也必须是可衡量的。我曾把我在总裁面前发言的例子讲给我女儿听，因为她的老师认为她很害羞，在学校不举手发言，我希望鼓励她勇于发言。她同意试一试，但她认为只有在适当的时候，有最好的意见时才愿意发言。但是，我认为有了“最好的意见”这个主观的评估，目标就很难衡量。于是，我和她制定了一个可衡量的、实际的目标：她每天举一次手，如果坚持一个月就有奖励。然后，我们慢慢增加举手的次数。一年后，老师注意到，她对课堂发言有了足够的自信。
自信绝非自我偏执、不容许自己犯错，或过度自我中心，失去客观的立场。我有个绝顶聪明的同事，他一生认准了“我永远不会错”这句“真理”。他表现得无比自信，一旦证明他某句话是对的，他就会提醒所有人几个月前他早就说过了。但因为他几乎是为了自信而活着，一旦证明他某句话是错的，他就会顾左右而言他，或根本否认此事。虽然他的正确率高达95%，但5%的错误让他失去了自己的信誉和他人的尊敬。这个例子告诉我们，自傲的自信或不自觉的自信甚至比不自信更加危险。
情商中的自觉有两个层面：对自己和环境皆能俱到，掌握主客观的情势。有自觉的人不会过度地自我批评，也不会天真地乐观，他们能客观地评估自己。所以，他们会坦诚地面对自己的能力极限，不会轻易地接受自己能力范围外的工作。当然，他们仍乐于接受挑战，但会在接受挑战时做客观的风险评估。这样的人不但对自己坦诚，对他人也坦诚。坦诚地面对失败会得到别人的信赖，因为他们知道你接受了教训。坦诚地面对自己的缺点也会得到别人的尊敬，因为他们知道你不会自不量力。所以，自觉的人容易成功，也容易自信。
自觉的人不但公平地评价自己，还主动要求周围的人给自己批评和反馈。他们明白，虽然自己很自觉，但别人眼中的自己是更为重要的。一方面，别人眼中的自己更为客观，另一方面，别人眼中的自己才是真正存在的自己（“Perception is reality”），也就是说，如果别人都认为你错了，只有你自认为没有错，那么在社会、学校或公司眼中，你就是错了。所以，你必须虚心地理解和接受别人的想法，而且以别人的想法作为最终的目标。比如，我女儿可以每天评估自己的发言，但最终，只有当老师和同学们认为她是个开朗的、有想法的学生时，她才达到了最终的目标。
获得坦诚的反馈特别是负面的回馈并不容易。所以，你最好能有一些勇敢坦诚的知心好友，他们愿意在私下对你说真心话。当然，你不能对负面的反馈有任何不满，否则你以后就听不到真心话了。除了私下的反馈外，在美国的公司里，还有一种“360度”意见调查，可以对员工的上司、下属同时做多方面的调查。因为这种调查是匿名的，它往往能获得真实的意见，如果很多人都说你在某方面仍须改进，这样的说法就比自己的或老板的看法更有说服力。虽然在学校里没有这种正式的调查，但是你仍然可以尽力地去理解他人对你的想法。我的父亲常教诲我们凡事谋之于众，就是指开放心胸，切勿以井观天，局限了自己的视野。
马加爵说：“同学都看不起我。”其实，如果他有勇气向他信任的同学求证，他也许会发现自己错怪了同学，也许会发现交错了朋友，也许会证实同学确实看不起他并了解其中的原因，然后自我改进。坦诚的交流和真心的朋友或许都可以帮助马加爵避免悲剧的发生。
有自觉的人会为自己制定现实的目标，客观地衡量自己，并会请他人帮助评估。这样的人能持续提升自己的自信，并能避免自信发展为自傲。
快乐比成功更重要
科学研究证明：心情好的人最能发挥潜力；快乐能提高效率、创造力和正确决策的概率；快乐的人有开明的思想，愿意帮助别人。但与其说快乐带来成功，还不如说成功的目的是带来快乐。我曾建议同学们追逐自己的理想和兴趣，其实做自己理想的、有兴趣的事情就是一种快乐。所以，快乐比成功更应成为我们的最终目标。
快乐的第一步：接受你的父母、环境、自己
不快乐的人总对一些无奈的事生闷气，不喜欢自己、父母和老师，不愿意读枯燥的书、不愿意应付考试。对于这些无奈的事，我希望同学们能学会坦然地接受它们。
在所有“不能改变的事情” 中，最不能改变的是父母，最应接受的也是父母。有不少学生说：“父母不理解我，不接受我，不体会我的想法，总要求我用他们的价值观和理念来做事、读书、求学。所以我总是避开他们，越来越孤独。”对这些同学，我的回答包括以下两个方面：
第一，你应该接受你的父母，千万不要因为感觉父母不理解你而自我封闭。父母的成长环境不同，思维方式不同，他们对成功的定义可能也不同，对你的期望与你对自己的期望就有较大的差异。但他们人生的路走得比你长，经验比你丰富，你不能先入为主地排斥他们。另外，你必须理解，父母是世界上最爱你的人，他们也是唯一可以无条件为你付出的人，你应该无条件地接受你的父母。作子女的经常把父母亲过度理想化，而疏忽了绝大多数的父母，在他们生长的环境中，比我们更为匮乏、不足，他们可能没有机会学习如何当一个称职的父母，但以他们的条件，也尽力了。如果我们鄙视、排斥父母，无异是对自己生命的来源不敬，那如何能快乐？
第二，你可以试着去改变父母的想法，但你首先应反问，你理解和接受你的父母吗？你能体会父母的想法吗？当你抱怨父母总是期望你完美时，难道你不也是在期望父母完美吗？凌志军建议说：“父母对你们的期望没有错，只是你们应该让父母了解，你们对他们的期望。”所以，在要求他们理解你之前，你应先去理解他们，这样才能更成功地和他们沟通。相互了解后，也许你们仍有不同意见但能彼此谅解，也许你或他们会改变原来的看法而达到共识。为此，你首先应和父母建立一个坦诚的沟通关系。也许起初你们会觉得别扭，但我相信你们很快就会体会到亲情与温馨。
除了接受父母，你还应接受环境中不能改变的事情。有些同学期望着不必考他们认为没用的题目，不必上他们认为没用的课，不必听他们不信任的老师讲课。但在社会中生存，我们必须学会接受那些不能改变的事。凌志军说：“如果我遇到‘应该做的事情’和‘喜欢做的事情’之间的冲突，我会给自己安排一个时间表，每天在规定的时间里完成‘应该做的事情’——时间表能激励你集中精力并提高效率。然后去做‘喜欢做的事情’。”人生是有限的，大家应把有限的时间用在“喜欢做的事情”上，但必须先把“应该做的事情”做得足够好。
最无谓的“发愁”就是对自己不满意。这不但浪费了时间，而且会造成事倍功半。所以，同学们一方面要培养自己的自信，以每一个小的成功来激励自己，另一方面也必须能接受自己，理解你们是为自己而生活的。为自己而生活就是要为了自己的快乐、兴趣和人生目标而努力，不要活在别人的价值观里。微软亚洲研究院院长沈向洋小时候一直活在别人的价值观里，为了“第一名”拼命，但是有一天，“我忽然意识到原来的想法错了。打败别人，得第一名，不是最重要的。最重要的是，你能不能学会尊重你自己，能不能发现自己的价值在哪里。”
当你开始为自己而生活，接受并喜欢你自己，接受并接近你的父母，接受环境中不能改变的事情，你就会发现你开始快乐了。
快乐的第二步：宣泄你的情感，控制你的脾气
心理学家认为，马加爵“在精神上一直是孤独的，因为他总不愿与人交流，不愿说出自己真实的感受……是一个情绪反应相当激烈的人，但是他外表上又是一个相当压抑的人。”马加爵给亲人的信上也写道：“我这个人动情的话历来就讲不出口。”如果马加爵能直接地宣泄自己的感情，他也许可以防止悲剧发生。事后马加爵也想到：“逃亡的时候觉得自己傻，可以选择吵架就算了，没有必要杀人。”
中国人总认为矜持、含蓄是美德。但我认为，在今天的时代里，直截了当的沟通更为重要。拐弯抹角、言不由衷、瞻前顾后、当面不说、背后乱讲都是坏习惯。有一位中国老板和他的下属吵架，他问我是不是该请第三者调解，我给他的建议是：因为这是情感的事情，你应该直接去和下属沟通；第三者为了做和事佬，可能会说出违背你或你的下属意愿的话（例如谎称你已经认错，但其实你没有），这反而会造成更多的麻烦。
当然，在情感问题上，直接沟通也需要技巧。例如，那位老板如果第一句话就对下属说：“你错了，但是我不和你计较。”那么下属肯定会反感。如果老板说：“你在那么多人面前骂我，很显然是你想抢我的工作。”结果就更不堪设想。显然，当你直接沟通时，不要论对错，不要猜测别人的动机，更不要再趁机补一句。最有效的沟通就是直接谈到你的感情，比如那位老板可以说：“当你在那么多人面前骂我时，我感到失去尊严，非常为难。”这样一句话是不能反驳的，甚至可能会引发理解和同情。
当你怒火中烧时，把愤怒的话转变成感性的话并不容易。要做到这一点，我们又需要依靠“自觉”和 “自控”。自觉不只是认识自己的能力，更是认识自己的感情。自觉的人知道自己何时会喜怒哀乐，也理解喜怒哀乐的宣泄会造成何种后果。如果他感到气愤，他不会瞬间爆炸，因为他知道爆炸的后果，但他也不会压抑自己的感情，因为那会对心灵造成很大的伤害，他通常会尽量自控地用最有建设性的方式处理。正面、感性的沟通可以降低火爆的气氛。感情和沟通都是最有感染性的，你完全可以用有建设性的、宽容的态度来与他人沟通并影响他人。
自控是一种内心的自我对话，可以提醒自己不要落入恶劣态度的陷阱。除了上溯的理智分析外，深呼吸是最快、最简单的情绪调节方法，中国人说：“心浮气躁”、“心神不宁”、“心乱如麻”、“心焦如焚”，指的都是心情紊乱和情绪及精神状态的关系，而“气定神闲”、“心安理得”最方便的作法就是深呼吸，也就藉由调气调息，把气调顺了，比较能摆脱情绪的牵扯，回到理性思考。美国对有暴力行为的加害人，都会施以团体教育，而教导他们认清暴力的毁灭性，学习控制自己的冲动，也就是懂得“叫停”或“离开现场”，以保护自己和对方的安全，避免铸成大错。
如果认为自控不容易，那么，你可以请你的知心好友随时提醒你。我过去的一个老板常常一生气就一发不可收拾，而且他生气都有前兆：他会先用刁钻的问题考倒你，然后他开始战抖，最后他才发脾气。但他想改掉这个毛病，于是他要求我在每次看到前兆时，用一句“密语”（如“让我们言归正传吧”）来提醒他。几次“密语”提醒之后，他就有了自觉和自控的能力，再也不需要别人提醒了。
快乐的第三步：有人分享快乐加倍，有人分担痛苦减半
科学研究告诉我们，调节自己的心情最好的方法就是找到知心的人倾诉和沟通。科学的根据是，感情源于人脑的lymbic系统，而该系统主要靠与他人的接触调节。科学证明，在一起交谈的两个人会慢慢达到同样的心理状态（喜怒哀乐）和生理状态（体温、心跳等）。因此，若想达到感情的平衡，我们必须懂得依靠别人。与人沟通是提升你的情商和快乐的唯一方法。与世隔绝的人只会越来越苦闷。西方有一古谚：“有人分享快乐加倍，有人分担痛苦减半。”马加爵所谓的真情，应该就是指能分享心情、内心的人吧！
所以，如果你情绪不好，或受了委屈时，应多向父母、朋友倾诉，不要像马加爵那样总把话闷在心里，只对日记倾诉。马加爵很苦闷，却没有倾诉苦闷的渠道。他说：“我在学校一个朋友也没有，我在学校那么落魄……在各种孤独中间，人最怕精神上的孤独。”马加爵在人际交往中碰到很多障碍，这些障碍带给他苦闷，而这些苦闷又没有渠道宣泄，进而造成更大的苦闷。这个恶性循环最终导致了悲剧的发生。其实，马加爵的内心独白，证明他是一个有自觉的人，他能看清自己的困境，可惜他将自己锁在自我封闭的牢笼里，让仇恨把他带向毁灭。记得去年，非典风波，最恐怖的威胁就是被隔离，可是平日里我们却常忽略了心里的孤立，使我们和快乐绝缘。
要得到快乐，你需要幽默、乐观的想法和沟通。在所有的沟通中，“笑”的感染力是最大的。耶鲁大学的研究发现，“笑”的感染力超过了所有其他感情，人们总会反射式地以微笑来回报你的微笑，而开怀的大笑更能迅速创造一个轻松的气氛，此外，幽默的笑也能促进相互信任，激发灵感。乐观、正面思考的力量是无穷的。近年来忧郁症已成为全世界来势汹汹的心理疾病，而其和负面思考有极大的关系，有些人习惯钻牛角尖，往悲观无助的方向想，困在死胡同中。如果能换个角度，半杯水有一半满的而非一半空的！现在的不如意，代表有无限成长进步的空间。学习检查自己，常保正念。
无论是驱逐悲伤或是获取快乐，我们都需要从倾诉和沟通中得到正面的激励。最自然的沟通对象可能是你的亲人，特别是你的父母。我相信，所有的父母都愿意听孩子的倾诉。
但是，“在家靠父母，出外靠朋友”，所以我们也需要和知心朋友沟通、倾诉。交朋友时不要只看朋友的嗜好和个性，更重要的是，你需要一些会鼓励人的、乐观的、幽默的、诚恳的、有同理心的、乐于助人的、愿意听人诉说的朋友。也许你会说：“我没有这样的朋友，也不敢去乱找朋友，如果别人拒绝怎么办？”如果别人拒绝你，你没有失去任何东西，但如果别人接受你，你可能因此找到你自己。
我希望你也会在寻找好友的过程中，也让自己成为这样一个会鼓励人的、乐观的、幽默的、诚恳的、有同理心的、乐于助人的、愿意听人诉说的人，并尽力去帮助你周围的亲人和朋友。唯有更多人愿意付出，快乐才能更迅速地通过人际网扩散。
给中国学生的祝福
我一直信奉以下做事的三原则：有勇气来改变可以改变的事情，有度量接受不可改变的事情，有智慧来分辨两者的不同。
祝福中国的学生，当你碰到挫折时，能用这三个原则，以度量、勇气、智慧来帮助你渡过难关。
祝福中国的学生，当你追求成功、自信、快乐时，不要忘了成功是多元化的，不要忘了自信是自觉而非自傲，不要忘了快乐的人总能理解、接受和喜欢自己。
祝福中国的学生，当你逐步获得成功、自信、快乐时，会发现一个良性循环：从成功里得到自信和快乐，从自信里得到快乐和成功，从快乐里得到成功和自信。
祝福中国的学生，当你拥有成功、自信、快乐后，不要忘了帮助他人获得成功、自信和快乐。
给中国学生的第三封信：成功、自信、快乐
李开复2004年5月
此前，我和中国学生的多次交流都是围绕如何达到优秀和卓越、如何成为领导人才而展开的。最近，在新浪网的聊天室和我收到的许多电子邮件中，我发现更多的中国学生需要知道的不是如何从优秀到卓越，而是如何从迷茫到积极、从失败到成功、从自卑到自信、从惆怅到快乐、从恐惧到乐观。
一个极端的例子是2004年2月发生在云南大学的马加爵事件。马加爵残忍地杀害了自己的4名同学。但从马家爵被捕后与心理学家的对话内容看来，他应该不是一个邪恶的人，而是一个迷失方向、缺乏自信、性格封闭的孩子。他和很多大学生一样，迫切希望知道如何才能获得成功、自信和快乐。
我这一封信是写给那些渴望成功但又觉得成功遥不可及，渴望自信却又总是自怨自艾，渴望快乐但又不知快乐为何物的学生看的。希望这封信能够带给读者一个关于成功的崭新定义，鼓励读者认识和肯定自己，做一个快乐的人。也希望这封信能够帮助读者理解成功、自信、快乐是一个良性循环：从成功里可以得到自信和快乐，从自信里可以得到快乐和成功，从快乐里可以得到成功和自信。
成功就是成为最好的你自己
美国作家威廉·福克纳说过：“不要竭尽全力去和你的同僚竞争。你应该在乎的是，你要比现在的你强。”
中国社会有个通病，就是希望每个人都照一个模式发展，衡量每个人是否“成功”采用的也是一元化的标准：在学校看成绩，进入社会看名利。尤其是在今天的中国,人们对财富的追求首当其冲，各行各业,对一个人的成功的评价，更多地以个人财富为指标。但是，有了最好的成绩就能对社会有所贡献吗？有名利就一定能快乐吗？
真正的成功应是多元化的。成功可能是你创造了新的财富或技术，可能是你为他人带来了快乐，可能是你在工作岗位上得到了别人的信任，也可能是你找到了回归自我、与世无争的生活方式。每个人的成功都是独一无二的。所以，凌志军在其《成长》一书中得出的重要结论是“成为最好的你自己”。也就是说，成功不是要和别人相比，而是要了解自己，发掘自己的目标和兴趣，努力不懈地追求进步，让自己的每一天都比昨天更好。
成功的第一步：把握人生目标，做一个主动的人
在新浪聊天室里，当网友问我的人生目标是什么时，我是这么回答的：“人生只有一次，我认为最重要的就是要有最大的影响力（impact），能够帮助自己、帮助家庭、帮助国家、帮助世界、帮助后人，能够让他们的日子过得更好、更有效率，能够为他们带来幸福和快乐。”我回答这个问题时丝毫不需要思考，因为我从大学二年级起就把“影响力”当作自己的人生目标。
对我来说，人生目标不是一个口号，而是我最好的智囊，它曾多次帮我解决工作和生活中的难题。我当初放弃在美国的工作，只身来到中国创立微软中国研究院，就是因为我觉得后一项工作有更大的影响力，和我的人生目标更加吻合。此外，当我收到一封封迷茫学生的来信，给他们写回信时，我也会想：“如何让回信有更大的影响力？”我先后公开的三封“给中国学生的信”都是如此诞生的。
马加爵也悟出了他的人生目标，只可惜他是在案发被捕后才悟出的。他说：“姐，现在我对你讲一次真心话，我这个人最大的问题就是出在我觉得人生的意义到底是为了什么？……在这次事情以后，此时此刻我明白了，我错了。其实人生的意义在于人间有真情。”如果马加爵能早几个月悟出人生目标，他在做傻事前就会问问自己，充满真情的父母、姐姐会怎么看待这件事？这样，他可能就不会走上歧途了。
所以，无论是为了真情，为了影响力，还是为了快乐、家人、道德、宁静、求知、创新……一旦确定了人生目标，你就可以像我一样在人生目标的指引下，果断地做出人生中的重大决定。每个人的人生目标都是独特的。最重要的是，你要主动把握自己的人生目标。但你千万不能操之过急，更不要为了追求所谓的“崇高”，或为了模仿他人而随便确定自己的目标。
那么，该怎么去发现自己的目标呢？许多同学问我他们的目标该是什么？我无法回答，因为只有一个人能告诉你人生的目标是什么，那个人就是你自己。只有一个地方你能找到你的目标，那就是你心里。
我建议你闭上眼睛，把第一个浮现在你脑海里的理想记录下来，因为不经过思考的答案是最真诚的。或者，你也可以回顾过去，在你最快乐、最有成就感的时光里，是否存在某些共同点？它们很可能就是最能激励你的人生目标了。再者，你也可以想象一下，十五年后，当你达到完美的人生状态时，你将会处在何种环境下？从事什么工作？其中最快乐的事情是什么？当然，你也不妨多和亲友谈谈，听听他们的意见。
成功的第二步：尝试新的领域、发掘你的兴趣
为了成为最好的你自己，最重要的是要发挥自己所有的潜力，追逐最感兴趣和最有激情的事情。当你对某个领域感兴趣时，你会在走路、上课或洗澡时都对它念念不忘，你在该领域内就更容易取得成功。更进一步，如果你对该领域有激情，你就可能为它废寝忘食，连睡觉时想起一个主意，都会跳起来。这时候，你已经不是为了成功而工作，而是为了“享受”而工作了。毫无疑问的，你将会从此得到成功。
相对来说，做自己没有兴趣的事情只会事倍功半，有可能一事无成。即便你靠着资质或才华可以把它做好，你也绝对没有释放出所有的潜力。因此，我不赞同每个学生都追逐最热门的专业，我认为，每个人都应了解自己的兴趣、激情和能力（也就是情商中所说的“自觉”），并在自己热爱的领域里充分发挥自己的潜力。
比尔·盖茨曾说：“每天清晨当你醒来的时候，都会为技术进步给人类生活带来的发展和改进而激动不已。”从这句话中，我们可看出他对软件技术的兴趣和激情。1977年，因为对软件的热爱，比尔·盖茨放弃了数学专业。如果他留在哈佛继续读数学，并成为数学教授，你能想象他的潜力将被压抑到什么程度吗？2002年，比尔·盖茨在领导微软25年后，却又毅然把首席执行官的工作交给了鲍尔默，因为只有这样他才能投身于他最喜爱的工作——担任首席软件架构师，专注于软件技术的创新。虽然比尔·盖茨曾是一个出色的首席执行官，但当他改任首席软件架构师后，他对公司的技术方向做出了重大贡献，更重要的是，他更有激情、更快乐了，这也鼓舞了所有员工的士气。
比尔·盖茨的好朋友，美国最优秀的投资家，华伦·巴菲特也同样认可激情的重要性。当学生请他指示方向时，他总这么回答：“我和你没有什么差别。如果你一定要找一个差别，那可能就是我每天有机会做我最爱的工作。如果你要我给你忠告，这这是我能给你的最好忠告了。”
比尔·盖茨和华伦·巴菲特给我们的另一个启示是，他们热爱的并不是庸俗的、一元化的名利，他们的名利是他们的理想和激情带来的。美国一所著名的经管学院曾做过一个调查，结果发现，虽然大多数学生在入学时都想追逐名利，但在拥有最多名利的校友中，有90%是入学时追逐理想、而非追逐名利的人。
我刚进入大学时，想从事法律或政治工作。一年多后我才发现自己对它没有兴趣，学习成绩也只在中游。但我爱上了计算机，每天疯狂地编程，很快就引起了老师、同学的重视。终于，大二的一天，我做了一个重大的决定：放弃此前一年多在全美前三名的哥伦比亚大学法律系已经修成的学分，转入哥伦比亚大学默默无名的计算机系。我告诉自己，人生只有一次，不应浪费在没有快乐、没有成就感的领域。当时也有朋友对我说，改变专业会付出很多代价，但我对他们说，做一个没有激情的工作将付出更大的代价。那一天，我心花怒放、精神振奋，我对自己承诺，大学后三年每一门功课都要拿A。若不是那天的决定，今天我就不会拥有在计算机领域所取得的成就，而我很可能只是在美国某个小镇上做一个既不成功又不快乐的律师。
即便如此，我对职业的激情还远不能和我父亲相比。我从小一直以为父亲是个不苟言笑的人，直到去年见到父亲最喜爱的两个学生（他们现在都是教授），我才知道父亲是多么热爱他的工作。他的学生告诉我：“李老师见到我们总是眉开眼笑，他为了让我们更喜欢我们的学科，常在我们最喜欢的餐馆讨论。他在我们身上花的时间和金钱，远远超过了他微薄的收入。”我父亲是在70岁高龄，经过从军、从政、写作等职业后才找到了他的最爱——教学。他过世后，学生在他抽屉里找到他勉励自己的两句话：“老牛明知夕阳短，不用扬鞭自奋蹄。”最令人欣慰的是，他在人生的最后一段路上，找到了自己的最爱。
那么，如何寻找兴趣和激情呢？首先，你要把兴趣和才华分开。做自己有才华的事容易出成果，但不要因为自己做得好就认为那是你的兴趣所在。为了找到真正的兴趣和激情，你可以问自己：对于某件事，你是否十分渴望重复它，是否能愉快地、成功地完成它？你过去是不是一直向往它？是否总能很快地学习它？它是否总能让你满足？你是否由衷地从心里（而不只是从脑海里）喜爱它？你的人生中最快乐的事情是不是和它有关？当你这样问自己时，注意不要把你父母的期望、社会的价值观和朋友的影响融入你的答案。
如果你能明确回答上述问题，那你就是幸运的，因为大多数学生在大学四年里都在摸索或悔恨。如果你仍未找到这些问题的答案，那我只有一个建议：给自己最多的机会去接触最多的选择。记得我刚进卡内基·梅隆的博士班时，学校有一个机制，允许学生挑老师。在第一个月里，每个老师都使尽全身解数吸引学生。正因为有了这个机制，我才幸运地碰到了我的恩师瑞迪教授，选择了我的博士题目“语音识别”。虽然并不是所有学校都有这样的机制，但你完全可以自己去了解不同的学校、专业、课题和老师，然后从中挑选你的兴趣。你也可以通过图书馆、网络、讲座、社团活动、朋友交流、电子邮件等方式寻找兴趣爱好。唯有接触你才能尝试，唯有尝试你才能找到你的最爱。
我的同事张亚勤曾经说：“那些敢于去尝试的人一定是聪明人。他们不会输，因为他们即使不成功，也能从中学到教训。所以，只有那些不敢尝试的人，才是绝对的失败者。”希望各位同学尽力开拓自己的视野，不但能从中得到教益，而且也能找到自己的兴趣所在。
成功的第三步：针对兴趣，定阶段性目标，一步步迈进
找到了你的兴趣，下一步该做的就是制定具体的阶段性目标，一步步向自己的理想迈进。
首先，你应客观地评估距离自己的兴趣和理想还差些什么？是需要学习一门课、读一本书、做一个更合群的人、控制自己的脾气还是成为更好的演讲者？十五年后成为最好的自己和今天的自己会有什么差别？还是其他方面？你应尽力弥补这些差距。例如，当我决定我一生的目的是要让我的影响力最大化时，我发现我最欠缺的是演讲和沟通能力。我以前是一个和人交谈都会脸红，上台演讲就会恐惧的学生。我做助教时表现特别差，学生甚至给我取了个“开复剧场”的绰号。因此，为了实现我的理想，我给自己设定了多个提高演讲和沟通技巧的具体目标。
其次，你应定阶段性的、具体的目标，再充分发挥中国人的传统美德——勤奋、向上和毅力，努力完成目标。比如，我要求自己每个月做两次演讲，而且每次都要我的同学或朋友去旁听，给我反馈意见。我对自己承诺，不排练三次，决不上台演讲。我要求自己每个月去听演讲，并向优秀的演讲者求教。有一个演讲者教了我克服恐惧的几种方法，他说，如果你看着观众的眼睛会紧张，那你可以看观众的头顶，而观众会依然认为你在看他们的脸，此外，手中最好不要拿纸而要握起拳来，那样，颤抖的手就不会引起观众的注意。当我反复练习演讲技巧后，我自己又发现了许多秘诀，比如：不用讲稿，通过讲故事的方式来表达时，我会表现得更好，于是，我仍准备讲稿但只在排练时使用；我发现我回答问题的能力超过了我演讲的能力，于是，我一般要求多留时间回答问题；我发现自己不感兴趣的东西就无法讲好，于是，我就不再答应讲那些我没有兴趣的题目。几年后，我周围的人都夸我演讲得好，甚至有人认为我是个天生的好演说家，其实，我只是实践了中国人勤奋、向上和毅力等传统美德而已。
任何目标都必须是实际的、可衡量的目标，不能只是停留在思想上的口号或空话。制定目标的目的是为了进步，不去衡量你就无法知道自己是否取得了进步。所以，你必须把抽象的、无法实施的、不可衡量的大目标简化成为实际的、可衡量的小目标。举例来说，几年前，我有一个目标是扩大我在公司里的人际关系网，但“多认识人”或“增加影响力”的目标是无法衡量和实施的，我需要找一个实际的、可衡量的目标。于是，我要求自己“每周和一位有影响力的人吃饭，在吃饭的过程，要这个人再介绍一个有影响的人给我”。衡量这个目标的标准是“每周与一人一餐、餐后再认识一人”。当然，我不会满足于这些基本的“指标”。扩大人际关系网的目的是使工作更成功，所以，我还会衡量“每周一餐”中得到了多少信息，有多少我的部门雇用的人是在这样的人际网中认识的。一年后，我的确从这些衡量标准中，看到了自己的关系网有了显著的扩大。
制定具体目标时必须了解自己的能力。目标设定过高固然不切实际，但目标也不可定得太低。对目标还要做及时的调整：如果超出自己的期望，可以把期望提高；如果未达到自己的期望，可以把期望调低。达成了一个目标后，可以再制定更有挑战性的目标；失败时要坦然接受，认真总结教训。
最后，再一次提醒同学们，目标都是属于你的，只有你知道自己需要什么。制定最合适的目标，主动提升自己，并在提升过程中客观地衡量进度，这样才能获得成功，才能成为更好的你自己。
自信是自觉而非自傲
自信的人敢于尝试新的领域，能更快地发展自己的兴趣和才华，更容易获得成功。自信的人也更快乐，因为他不会时刻担心和提防失败。
很多人认为自信就是成功。一个学生老得第一名，他有了自信。一个员工总是被提升，他也有了自信。但这只是一元化的成功和一元化的自信。
其实，自信不一定都是好事。没有自觉的自信会成为自傲，反而会失去了别人的尊重和信赖。好的自信是自觉的，即很清楚自己能做什么，不能做什么。自觉的人自信时，他成功的概率非常大；自觉的人不自信时，他仍可努力尝试，但会将风险坦诚地告诉别人。自觉的人不需要靠成功来增强自信，也不会因失败而丧失自信。
自信的第一步：不要小看自己，多给自己打气
“自”信的关键在于自己。如果你自己总认为自己不行，你是无法得到自信的。例如，马加爵曾说：“我觉得我太失败的，同学都看不起我……很多人比我老练，让我很自卑。”虽然马加爵很聪明也很优秀，但他从没有真正自信过。
自信的秘密是相信自己有能力。中国古谚：“天生我才必有用”，“一枝草，一点露”，每个人都有自己的特性和长处，值得看重和发挥。我记得我11岁刚到美国时，课堂上一句英语都听不懂，有一次老师问“1/7换算成小数等于几？”我虽然不懂英文，但认得黑板上的“1/7”，这是我以前“背”过的。我立刻举手并正确回答了这个问题。不会“背书”的美国老师诧异地认为我是个“数学天才”，并送我去参加数学竞赛，鼓励我加入数学夏令营，帮助同学学习数学。她的鼓励和同学的认可给了我自信。我开始告诉自己，我有数学的天分。这时，我特别想把英文学好，因为只有这样才能学习更多的数学知识。这种教育方式不但提高了我的自信，也帮助我在各方面取得了长足的进步。
中国式教育认为人的成长是不断克服缺点的过程，所以老师更多是在批评学生，让学生弥补最差的学科。虽然应把每科都学得“足够好”，但人才的价值在于充分发挥个人最大的优点。美国盖洛普公司最近出了一本畅销书《现在，发掘你的优势》。盖洛普的研究人员发现：大部分人在成长过程中都试着“改变自己的缺点，希望把缺点变为优点”，但他们却碰到了更多的困难和痛苦；而少数最快乐、最成功的人的秘诀是“加强自己的优点，并管理自己的缺点”。“管理自己的缺点”就是在不足的地方做得足够好，“加强自己的优点”就是把大部分精力花在自己有兴趣的事情上，从而获得无比的自信。
凌志军的《成长》一书里还有很多得到自信的例子：微软亚洲工程院院长张宏江说他从小就“相信我是最聪明的。即使再后来的日子里我常常不如别人，但我还是对自己说：我能比别人做得好”；微软亚洲研究院的主任研究员周明小时候在“学生劳动”中刷了108个瓶子，打破了纪录，从而获得自信。他说：“我原来一直是没有自信心的，但是这件事给了我自信。这是我一生中最快乐的经验，散发着一种迷人的力量，一直持续到今天。我发现了天才的全部秘密，其实只有6个字：不要小看自己。”
自信是一种感觉，你没有办法用背书的方法“学习”自信，而唯一靠“学习”提升自信的方法是以实例“训练”你的大脑。要得到自信，你必须成为自己最好的拉拉队，每晚入睡前不妨想想，今天发生了什么值得你自豪的事情？你得到了好的成绩吗？你帮助了别人吗？有什么超出了你的期望吗？有谁夸奖了你吗？我相信每个人每天都可以找到一件成功的事情，你会慢慢发现，这些“小成功”可能会越来越有意义。
有个著名教练在每次球赛前，总会要求队员回忆自己最得意的一次比赛。他甚至让队员把最得意的比赛和一个动作（如紧握拳头）联系起来，以便使自己每次做这个动作时，就会下意识地想到得意的事，然后在每次比赛前反复做这个动作以“训练”大脑，提升自信。
希望同学们都能成为自己最好的拉拉队，同时多结交为你打气的朋友，多回味过去的成功，千万不要小看自己。
自信的第二步：用毅力、勇气，从成功里获得自信，从失败里增加自觉
当你感觉到自信时，无论多么小的成功，你都会特别期望再一次得到自己或别人的肯定，这时，你需要有足够的毅力。只要你有毅力，就会像周明所说的那样，“什么事情只要我肯干，就一定可以干好。你能学会你想学会的任何东西，这不是你能不能学会的问题，而是你想不想学的问题。如果你对自己手里的东西有强烈的欲望，你就会有一种坚韧不拔的精神，尤其当你是普通人的时候。”
有时，你可能没做过某一件事，不知道能不能做成。这时，除了毅力外，你还需要勇气。我以前在工作中，一般的沟通没有问题，但到了总裁面前，总是不敢讲话，怕说错话。直到有一天，公司要做改组，总裁召集十多个人开会，他要求每个人轮流发言。我当时想，既然一定要讲，那不如把心里话讲出来。于是，我鼓足勇气说：“我们这个公司，员工的智商比谁都高，但是我们的效率比谁都差，因为我们整天改组，不顾到员工的感受和想法……”我说完后，整个会议室鸦雀无声。会后，很多同事给我发电子邮件说：“你说得真好，真希望我也有你的胆子这么说。”结果，总裁不但接受了我的建议，改变了公司在改组方面的政策，而且还经常引用我的话。从此，我充满了自信，不惧怕在任何人面前发言。这个例子充分印证了“你没有试过，你怎么知道你不能”这句话。
有勇气尝试新事物的同时，也必须有勇气面对失败。大家不能只凭匹夫之勇去做注定要失败的事。但当你畏惧失败时，不妨想一想，你怕失去什么？最坏的下场是什么？你不能接受吗？在上面的例子中，如果总裁否定了我的看法，他会不尊重我吗？不但不会，别人很可能还会认为我勇气可嘉。而且，自觉的人会从失败中学习，认识到自己不适合做什么事情，再提升自己的自觉。因此，不要畏惧失败，只要你尽了力，愿意向自己的极限挑战，你就应为自己的勇气而自豪。
一个自信和自觉的人，如果能勇敢地尝试新的事物，并有毅力把它做好，他就会从成功里获得自信，从失败里增加自觉。
自信的第三步：自觉地定具体的目标，虚心地听他人的评估
培养自信也要设定具体的目标，一步步地迈进。这些目标也必须是可衡量的。我曾把我在总裁面前发言的例子讲给我女儿听，因为她的老师认为她很害羞，在学校不举手发言，我希望鼓励她勇于发言。她同意试一试，但她认为只有在适当的时候，有最好的意见时才愿意发言。但是，我认为有了“最好的意见”这个主观的评估，目标就很难衡量。于是，我和她制定了一个可衡量的、实际的目标：她每天举一次手，如果坚持一个月就有奖励。然后，我们慢慢增加举手的次数。一年后，老师注意到，她对课堂发言有了足够的自信。
自信绝非自我偏执、不容许自己犯错，或过度自我中心，失去客观的立场。我有个绝顶聪明的同事，他一生认准了“我永远不会错”这句“真理”。他表现得无比自信，一旦证明他某句话是对的，他就会提醒所有人几个月前他早就说过了。但因为他几乎是为了自信而活着，一旦证明他某句话是错的，他就会顾左右而言他，或根本否认此事。虽然他的正确率高达95%，但5%的错误让他失去了自己的信誉和他人的尊敬。这个例子告诉我们，自傲的自信或不自觉的自信甚至比不自信更加危险。
情商中的自觉有两个层面：对自己和环境皆能俱到，掌握主客观的情势。有自觉的人不会过度地自我批评，也不会天真地乐观，他们能客观地评估自己。所以，他们会坦诚地面对自己的能力极限，不会轻易地接受自己能力范围外的工作。当然，他们仍乐于接受挑战，但会在接受挑战时做客观的风险评估。这样的人不但对自己坦诚，对他人也坦诚。坦诚地面对失败会得到别人的信赖，因为他们知道你接受了教训。坦诚地面对自己的缺点也会得到别人的尊敬，因为他们知道你不会自不量力。所以，自觉的人容易成功，也容易自信。
自觉的人不但公平地评价自己，还主动要求周围的人给自己批评和反馈。他们明白，虽然自己很自觉，但别人眼中的自己是更为重要的。一方面，别人眼中的自己更为客观，另一方面，别人眼中的自己才是真正存在的自己（“Perception is reality”），也就是说，如果别人都认为你错了，只有你自认为没有错，那么在社会、学校或公司眼中，你就是错了。所以，你必须虚心地理解和接受别人的想法，而且以别人的想法作为最终的目标。比如，我女儿可以每天评估自己的发言，但最终，只有当老师和同学们认为她是个开朗的、有想法的学生时，她才达到了最终的目标。
获得坦诚的反馈特别是负面的回馈并不容易。所以，你最好能有一些勇敢坦诚的知心好友，他们愿意在私下对你说真心话。当然，你不能对负面的反馈有任何不满，否则你以后就听不到真心话了。除了私下的反馈外，在美国的公司里，还有一种“360度”意见调查，可以对员工的上司、下属同时做多方面的调查。因为这种调查是匿名的，它往往能获得真实的意见，如果很多人都说你在某方面仍须改进，这样的说法就比自己的或老板的看法更有说服力。虽然在学校里没有这种正式的调查，但是你仍然可以尽力地去理解他人对你的想法。我的父亲常教诲我们凡事谋之于众，就是指开放心胸，切勿以井观天，局限了自己的视野。
马加爵说：“同学都看不起我。”其实，如果他有勇气向他信任的同学求证，他也许会发现自己错怪了同学，也许会发现交错了朋友，也许会证实同学确实看不起他并了解其中的原因，然后自我改进。坦诚的交流和真心的朋友或许都可以帮助马加爵避免悲剧的发生。
有自觉的人会为自己制定现实的目标，客观地衡量自己，并会请他人帮助评估。这样的人能持续提升自己的自信，并能避免自信发展为自傲。
快乐比成功更重要
科学研究证明：心情好的人最能发挥潜力；快乐能提高效率、创造力和正确决策的概率；快乐的人有开明的思想，愿意帮助别人。但与其说快乐带来成功，还不如说成功的目的是带来快乐。我曾建议同学们追逐自己的理想和兴趣，其实做自己理想的、有兴趣的事情就是一种快乐。所以，快乐比成功更应成为我们的最终目标。
快乐的第一步：接受你的父母、环境、自己
不快乐的人总对一些无奈的事生闷气，不喜欢自己、父母和老师，不愿意读枯燥的书、不愿意应付考试。对于这些无奈的事，我希望同学们能学会坦然地接受它们。
在所有“不能改变的事情” 中，最不能改变的是父母，最应接受的也是父母。有不少学生说：“父母不理解我，不接受我，不体会我的想法，总要求我用他们的价值观和理念来做事、读书、求学。所以我总是避开他们，越来越孤独。”对这些同学，我的回答包括以下两个方面：
第一，你应该接受你的父母，千万不要因为感觉父母不理解你而自我封闭。父母的成长环境不同，思维方式不同，他们对成功的定义可能也不同，对你的期望与你对自己的期望就有较大的差异。但他们人生的路走得比你长，经验比你丰富，你不能先入为主地排斥他们。另外，你必须理解，父母是世界上最爱你的人，他们也是唯一可以无条件为你付出的人，你应该无条件地接受你的父母。作子女的经常把父母亲过度理想化，而疏忽了绝大多数的父母，在他们生长的环境中，比我们更为匮乏、不足，他们可能没有机会学习如何当一个称职的父母，但以他们的条件，也尽力了。如果我们鄙视、排斥父母，无异是对自己生命的来源不敬，那如何能快乐？
第二，你可以试着去改变父母的想法，但你首先应反问，你理解和接受你的父母吗？你能体会父母的想法吗？当你抱怨父母总是期望你完美时，难道你不也是在期望父母完美吗？凌志军建议说：“父母对你们的期望没有错，只是你们应该让父母了解，你们对他们的期望。”所以，在要求他们理解你之前，你应先去理解他们，这样才能更成功地和他们沟通。相互了解后，也许你们仍有不同意见但能彼此谅解，也许你或他们会改变原来的看法而达到共识。为此，你首先应和父母建立一个坦诚的沟通关系。也许起初你们会觉得别扭，但我相信你们很快就会体会到亲情与温馨。
除了接受父母，你还应接受环境中不能改变的事情。有些同学期望着不必考他们认为没用的题目，不必上他们认为没用的课，不必听他们不信任的老师讲课。但在社会中生存，我们必须学会接受那些不能改变的事。凌志军说：“如果我遇到‘应该做的事情’和‘喜欢做的事情’之间的冲突，我会给自己安排一个时间表，每天在规定的时间里完成‘应该做的事情’——时间表能激励你集中精力并提高效率。然后去做‘喜欢做的事情’。”人生是有限的，大家应把有限的时间用在“喜欢做的事情”上，但必须先把“应该做的事情”做得足够好。
最无谓的“发愁”就是对自己不满意。这不但浪费了时间，而且会造成事倍功半。所以，同学们一方面要培养自己的自信，以每一个小的成功来激励自己，另一方面也必须能接受自己，理解你们是为自己而生活的。为自己而生活就是要为了自己的快乐、兴趣和人生目标而努力，不要活在别人的价值观里。微软亚洲研究院院长沈向洋小时候一直活在别人的价值观里，为了“第一名”拼命，但是有一天，“我忽然意识到原来的想法错了。打败别人，得第一名，不是最重要的。最重要的是，你能不能学会尊重你自己，能不能发现自己的价值在哪里。”
当你开始为自己而生活，接受并喜欢你自己，接受并接近你的父母，接受环境中不能改变的事情，你就会发现你开始快乐了。
快乐的第二步：宣泄你的情感，控制你的脾气
心理学家认为，马加爵“在精神上一直是孤独的，因为他总不愿与人交流，不愿说出自己真实的感受……是一个情绪反应相当激烈的人，但是他外表上又是一个相当压抑的人。”马加爵给亲人的信上也写道：“我这个人动情的话历来就讲不出口。”如果马加爵能直接地宣泄自己的感情，他也许可以防止悲剧发生。事后马加爵也想到：“逃亡的时候觉得自己傻，可以选择吵架就算了，没有必要杀人。”
中国人总认为矜持、含蓄是美德。但我认为，在今天的时代里，直截了当的沟通更为重要。拐弯抹角、言不由衷、瞻前顾后、当面不说、背后乱讲都是坏习惯。有一位中国老板和他的下属吵架，他问我是不是该请第三者调解，我给他的建议是：因为这是情感的事情，你应该直接去和下属沟通；第三者为了做和事佬，可能会说出违背你或你的下属意愿的话（例如谎称你已经认错，但其实你没有），这反而会造成更多的麻烦。
当然，在情感问题上，直接沟通也需要技巧。例如，那位老板如果第一句话就对下属说：“你错了，但是我不和你计较。”那么下属肯定会反感。如果老板说：“你在那么多人面前骂我，很显然是你想抢我的工作。”结果就更不堪设想。显然，当你直接沟通时，不要论对错，不要猜测别人的动机，更不要再趁机补一句。最有效的沟通就是直接谈到你的感情，比如那位老板可以说：“当你在那么多人面前骂我时，我感到失去尊严，非常为难。”这样一句话是不能反驳的，甚至可能会引发理解和同情。
当你怒火中烧时，把愤怒的话转变成感性的话并不容易。要做到这一点，我们又需要依靠“自觉”和 “自控”。自觉不只是认识自己的能力，更是认识自己的感情。自觉的人知道自己何时会喜怒哀乐，也理解喜怒哀乐的宣泄会造成何种后果。如果他感到气愤，他不会瞬间爆炸，因为他知道爆炸的后果，但他也不会压抑自己的感情，因为那会对心灵造成很大的伤害，他通常会尽量自控地用最有建设性的方式处理。正面、感性的沟通可以降低火爆的气氛。感情和沟通都是最有感染性的，你完全可以用有建设性的、宽容的态度来与他人沟通并影响他人。
自控是一种内心的自我对话，可以提醒自己不要落入恶劣态度的陷阱。除了上溯的理智分析外，深呼吸是最快、最简单的情绪调节方法，中国人说：“心浮气躁”、“心神不宁”、“心乱如麻”、“心焦如焚”，指的都是心情紊乱和情绪及精神状态的关系，而“气定神闲”、“心安理得”最方便的作法就是深呼吸，也就藉由调气调息，把气调顺了，比较能摆脱情绪的牵扯，回到理性思考。美国对有暴力行为的加害人，都会施以团体教育，而教导他们认清暴力的毁灭性，学习控制自己的冲动，也就是懂得“叫停”或“离开现场”，以保护自己和对方的安全，避免铸成大错。
如果认为自控不容易，那么，你可以请你的知心好友随时提醒你。我过去的一个老板常常一生气就一发不可收拾，而且他生气都有前兆：他会先用刁钻的问题考倒你，然后他开始战抖，最后他才发脾气。但他想改掉这个毛病，于是他要求我在每次看到前兆时，用一句“密语”（如“让我们言归正传吧”）来提醒他。几次“密语”提醒之后，他就有了自觉和自控的能力，再也不需要别人提醒了。
快乐的第三步：有人分享快乐加倍，有人分担痛苦减半
科学研究告诉我们，调节自己的心情最好的方法就是找到知心的人倾诉和沟通。科学的根据是，感情源于人脑的lymbic系统，而该系统主要靠与他人的接触调节。科学证明，在一起交谈的两个人会慢慢达到同样的心理状态（喜怒哀乐）和生理状态（体温、心跳等）。因此，若想达到感情的平衡，我们必须懂得依靠别人。与人沟通是提升你的情商和快乐的唯一方法。与世隔绝的人只会越来越苦闷。西方有一古谚：“有人分享快乐加倍，有人分担痛苦减半。”马加爵所谓的真情，应该就是指能分享心情、内心的人吧！
所以，如果你情绪不好，或受了委屈时，应多向父母、朋友倾诉，不要像马加爵那样总把话闷在心里，只对日记倾诉。马加爵很苦闷，却没有倾诉苦闷的渠道。他说：“我在学校一个朋友也没有，我在学校那么落魄……在各种孤独中间，人最怕精神上的孤独。”马加爵在人际交往中碰到很多障碍，这些障碍带给他苦闷，而这些苦闷又没有渠道宣泄，进而造成更大的苦闷。这个恶性循环最终导致了悲剧的发生。其实，马加爵的内心独白，证明他是一个有自觉的人，他能看清自己的困境，可惜他将自己锁在自我封闭的牢笼里，让仇恨把他带向毁灭。记得去年，非典风波，最恐怖的威胁就是被隔离，可是平日里我们却常忽略了心里的孤立，使我们和快乐绝缘。
要得到快乐，你需要幽默、乐观的想法和沟通。在所有的沟通中，“笑”的感染力是最大的。耶鲁大学的研究发现，“笑”的感染力超过了所有其他感情，人们总会反射式地以微笑来回报你的微笑，而开怀的大笑更能迅速创造一个轻松的气氛，此外，幽默的笑也能促进相互信任，激发灵感。乐观、正面思考的力量是无穷的。近年来忧郁症已成为全世界来势汹汹的心理疾病，而其和负面思考有极大的关系，有些人习惯钻牛角尖，往悲观无助的方向想，困在死胡同中。如果能换个角度，半杯水有一半满的而非一半空的！现在的不如意，代表有无限成长进步的空间。学习检查自己，常保正念。
无论是驱逐悲伤或是获取快乐，我们都需要从倾诉和沟通中得到正面的激励。最自然的沟通对象可能是你的亲人，特别是你的父母。我相信，所有的父母都愿意听孩子的倾诉。
但是，“在家靠父母，出外靠朋友”，所以我们也需要和知心朋友沟通、倾诉。交朋友时不要只看朋友的嗜好和个性，更重要的是，你需要一些会鼓励人的、乐观的、幽默的、诚恳的、有同理心的、乐于助人的、愿意听人诉说的朋友。也许你会说：“我没有这样的朋友，也不敢去乱找朋友，如果别人拒绝怎么办？”如果别人拒绝你，你没有失去任何东西，但如果别人接受你，你可能因此找到你自己。
我希望你也会在寻找好友的过程中，也让自己成为这样一个会鼓励人的、乐观的、幽默的、诚恳的、有同理心的、乐于助人的、愿意听人诉说的人，并尽力去帮助你周围的亲人和朋友。唯有更多人愿意付出，快乐才能更迅速地通过人际网扩散。
给中国学生的祝福
我一直信奉以下做事的三原则：有勇气来改变可以改变的事情，有度量接受不可改变的事情，有智慧来分辨两者的不同。
祝福中国的学生，当你碰到挫折时，能用这三个原则，以度量、勇气、智慧来帮助你渡过难关。
祝福中国的学生，当你追求成功、自信、快乐时，不要忘了成功是多元化的，不要忘了自信是自觉而非自傲，不要忘了快乐的人总能理解、接受和喜欢自己。
祝福中国的学生，当你逐步获得成功、自信、快乐时，会发现一个良性循环：从成功里得到自信和快乐，从自信里得到快乐和成功，从快乐里得到成功和自信。
祝福中国的学生，当你拥有成功、自信、快乐后，不要忘了帮助他人获得成功、自信和快乐。
给中国学生的第二封信：从优秀到卓越
http://home.comcast.net/~kaifulee/kflwritings/Letter2.htm
给中国学生的第二封信：从优秀到卓越
李开复
2003年12月
三年前离开中国时，我在《给中国学生的一封信》中，与广大青年学生一道，讨论了一些大家共同关心的话题，并结合自己的学习和工作经历，就青年学生如何对待机遇、学业、工作、他人、自己等问题，阐述了我的个人意见。我提出诚信和正直、主动意识、交流和沟通、努力一生学习这几个个人素质方面值得中国学生高度重视，
在这三年，许多中国学生，经过电子邮件、讲座后的问答、座谈、和其他渠道（例如在电视节目“对话”中），常对我提到“如何成才”的问题。对于这个大家关注的问题，我整理了许多材料，集成这封“第二封信”。
在第一封信力所提到的个人素质或“价值观”是成材的必要的基础。但是，除了素质之外，成才同样的需要领导能力（leadership）。很多人误以为领导能力最重视的是天资、号召力、管理能力。但是，根据我个人的经验，和最近一些研究的结论，如果你想成为一名成功的领导，最重要的不是你的智商（IQ）,而是你的情商（EQ）。最重要的不是要成为一个有号召力令人信服的领导，而是要成为一个有 “谦虚”、“执著”和“勇气” 的领导。
这“给中国学生的第二封信”是为那些希望不断提高自己，不断学习事业成功所必需的基本技能和领导艺术的人所写的。第一部分重申了《给中国学生的一封信》中讨论过的有关个人素质的话题；第二部分阐释了领导能力中最重要的情商；第三部分给出了卓越的领导所必须具备的、有别于普通人的基本特质。
如何提高个人素质
诚信和正直
一个人的人品如何直接决定了这个人对于社会的价值。而在与人品相关的各种因素之中，诚信又是最为重要的一点。微软公司在用人时非常强调诚信，我们只雇佣那些最值得信赖的人。去年，当微软列出对员工期望的“核心价值观”时，诚信（honesty and integrity）被列为一位。
在我发表“第一封信”后，曾经有一位同学问我：为什么一个公司要涉入员工的道德呢？我回答：这是为了公司自己的利益。例如，一位应聘者在面试时曾对我说，如果他能加入微软公司，他就可以把他在前一家公司所做的发明成果带过来。对这样的人，无论他的技术水平如何，我都不会雇用他。他既然可以在加入微软时损害先前公司的利益，那他也一定会在加入微软后损害微软公司的利益。
另外有一位同学看了“对话”后问我，为什么我会把诚信放在智慧之前呢？难道我们会去衡量员工的诚信和他们的智慧而给诚信更高的比重？其实，我们的衡量都在直接的工作目标上，并不会对诚信或智慧做直接的衡量。但是，作为第一“核心价值”，诚信是我们对员工最基本的要求。 我们根本不会去雇用没有诚信的人。如果一个员工发生了严重诚信的问题，他会被立刻解雇。
当一个公司这么重视诚信，员工一定更值得信赖。因此，公司对员工也能够完全信任，让他们发挥自己的才能。在微软公司，公司的各级管理者都会给员工较大的自由和空间发展他们的事业，并在工作和生活上充分信任、支持和帮助员工。只要是微软录用的人，微软就会百分之百地信任他。和一些软件企业对员工处处提防的做法不同，微软公司内的员工可以看到许多源代码，接触到很多技术或商业方面的机密。正因为如此得到公司的信任，微软的员工对公司才有更强的责任心和更高的工作热情。
培养主动意识
坦白地说，中国的学生和职员大多属于比较内向的类型，在学习和工作中还不够主动。在学校时，学生们往往需要老师安排学习任务，或是按照老师的思路做课题研究。在公司里，中国职员常常要等老板吩咐做什么事、怎么做之后，才开始工作。此外，许多中国人并不善于推销和宣传自己，这恐怕和中国自古以来讲求中庸的文化氛围有很大关系。
但是，要想在现代企业中获得成功，就必须努力培养自己的主动意识：在工作中要勇于承担责任，主动为自己设定工作目标，并不断改进方式和方法；此外，还应当培养推销自己的能力，在领导或同事面前要善于表现自己的优点，有了研究成果或技术创新之后要通过演讲、展示、交流、论文等方式和同事或同行分享，在工作中犯了错误也要勇于承认。只有积极主动的人才能在瞬息万变的竞争环境中获得成功，只有善于展示自己的人才能在工作中获得真正的机会。
客观、直接的交流和沟通
开诚布公的交流和沟通是团队合作中最重要的环节。人与人之间遮遮掩掩、言不由衷甚至挑拨是非的做法都会严重破坏团队中的工作氛围，阻碍团队成员间的正常交流，并最终导致项目或企业经营失败。
比如，在开会讨论问题的时候，与会的所有人员都应当坦诚地交换意见，这样才能做出正确的决定。如果某个人因为考虑到某些其他因素（比如不愿反驳上级领导的意见）而在会议上不敢表达自己的观点，一味地唯唯诺诺，会后到了洗手间里再和别人说“其实我不同意他的观点”，这种戴着假面具工作的人不但不能坚持自己的观点，还会破坏公司内部的沟通和交流渠道，对工作产生负面的影响。
微软公司有一个非常好的文化叫“开放式交流（Open communication）”，它要求所有员工在任何交流或沟通的场合里都能敞开心扉，完整地表达自己的观点。在微软开会时，大家如果意见的不统一，一定要表达出来，否则公司可能错过良机。当Internet刚开始时，很多微软的领导者不理解、不赞成花太多精力做这个“不挣钱”的技术。但是有几位技术人员，他们不断地提出他们的意见和建议，虽然他们的上司不理解，但是仍然支持他们“开放式交流”的权利。后来，他们的声音很快的达到比尔•盖茨的耳里，促成比尔改变公司方向，彻底支持Internet。从这个例子我们可以看到，这种开放的交流环境对微软公司保持企业活力和创新能力都是非常重要的。
彻底的开放式交流也有缺点。开放式交流有时会造成激烈的辩论甚至是争吵，而吵到气头上有时会说出不尊重别人的语言，会破坏人与人之间的关系。因此，微软公司的总裁史蒂夫•鲍尔默去年在微软的核心价值观中，提出我们要把这种开放式交流文化改进成“开放并相互尊重（Open and respectful）”。这要求我们在相互交流时充分尊重对方。当我们不同意对方的意见时，一定要用建设性的语言提出。
挑战自我、学无止境
从一名大学生到一名程序员，再到一位管理者，在软件人才的成长历程中，学习是永无止境的。在大学期间，我们要打好基础，培养自己各方面的素质和能力；工作以后，我们应当努力在实际工作中学习新的技术并积累相关经验；即使走上了管理岗位，我们也应当不断学习，不断提高自己。软件产业本身就是一个每天都会有新技术、新概念诞生，充满了活力和创造力的产业。作为软件产业的从业人员，如果只知道闭门造车、抱残守缺，我们就必然会落伍，必然会被市场淘汰。
许多中国学生喜欢与别人竞争，但这种竞争更多地表现为一种“零和游戏”，无法使自己和他人得到真正的提高。我建议大家最好能不断和自己竞争——不要总想着胜过别人，而要努力超越自我，不断在自身的水平上取得进步。
在学习的过程中，打好基础最为重要。从软件产业对人才的需求来看，我们必须学好数学和英语这两门基础学科。数学是所有工程科学的基础，无论是软件产品的开发，还是软件技术的研究，都要大量使用数学方法和数学原理。英文则是软件行业中的国际语言，要想了解国际上软件技术的发展趋势，掌握最新的研究成果，或是与国外同行进行技术交流，就必须掌握英文的听、说、读、写，能够在工作中熟练使用英文来解决问题。
情商和领导能力
同学们都希望增进自己的leadership skills（领导能力）。从我的经验和一些最近的研究结果看来，领导能力中最重要的是所谓的“情商”( EQ）。
智商（IQ）反映人的智慧水平，情商则反映了人在情感、情绪方面的自控和协调能力。在高新技术企业中，大家都知道智慧的重要，但是情商的重要性甚至超过了智商。我看过一篇文章，该文的作者调查了188个公司，他用心理学方法测试了这些公司里每一名员工的智商和情商，并将测试结果和该员工在工作上的表现联系在一起进行分析。经过研究，该文的作者发现，在对个人工作业绩的影响方面，情商的影响力是智商的两倍。此外，他还专门对公司中的高级管理者进行了分析。他发现在高级管理者中，情商对于个人成败的影响力是智商的九倍。这说明，智商略逊他人的人如果拥有更高的情商指数，也一样可以获得成功；反之，智商很高，但情商不足的人欠缺“领导能力”，很难成为一个成功的领导。
什么是情商？
在现代社会，如果你只知道智商而不晓得情商的话，你至少在意识上已经落伍了。许多心理学家早已明确地指出，单单使用智商的标准考察一个人在才智方面的表现，并不足以准确预测这个人在事业上可能取得的成就。为了全面考察个人能力，特别是考察个人在社会生活中的适应能力和创造能力，心理学家们提出了情商的概念。
情商主要是指那些与认识自我、控制情绪、激励自己以及处理人际关系等相关的个人能力。在情商所描述的各项能力因素中，自觉、同理心、自律和人际关系是四种对现代人的事业成败起决定性作用的关键因素。
智商是先天赋予的，但是情商是可以培养的。多花功夫理解和应用这四种情商的关键因素。除此之外，因为情商不是自己能看清楚的，我建议可多理解别人对你的看法、多吸取别人（尤其是情商高的人）的意见。
自觉
中国人常说，人贵有自知之明。这实际上是说，社会生活中的每个人都应当对自己的素质、潜能、特长、缺陷、经验等各种基本能力有一个清醒的认识，对自己在社会工作生活中可能扮演的角色有一个明确的定位。心理学上把这种有自知之明的能力称为“自觉”，这通常包括察觉自己的情绪对言行的影响，了解并正确评估自己的资质、能力与局限，相信自己的价值和能力等几个方面。
我的下属中有一个“自觉心”明显不足的人：他虽然有一些能力，但是他自视甚高，总是对自己目前的职位不满意，随时随地自吹自擂，总是不满现状。前一段时间，他认为我不识才，没有重用他，决定离开我的组，并期望在微软其他组中另谋高就。但是，他最终发现，自己不但找不到更好的工作，公司里的同事也都对他颇有微辞，认为他缺少自知之明，期望和现实相距太远。最近，他沮丧地离开了公司。接替他职位的人，是一个能力很强，而且很有“自觉心”的人。虽然这个人在上一个职位工作时不很成功，但他理解自己升迁太快，愿意自降一级来做这份工作，以便打好基础。他现在的确做得很出色。
简单地说，一个人既不能对自己的能力判断过高，也不能轻易低估自己的潜能。对自己判断过高的人往往容易浮躁、冒进，不善于和他人合作，在事业遭到挫折时心理落差较大，难以平静对待客观事实；低估了自己的能力的人，则会在工作中畏首畏尾、踟蹰不前，没有承担责任和肩负重担的勇气，也没有主动请缨的积极性。无论是上述哪一种情况，个人的潜力都不能得到充分的发挥，个人事业也不可能取得最大的成功。
有自知之明的人既能够在他人面前展示自己的特长，也不会刻意掩盖自己的欠缺。谈成自己的不足而向他人求教不但不会降低了自己，反而可以表示出自己虚心和自信，赢得他人的青睐。比如，当一个领导对某个职员说“在技术上你是专家，我不如你，我要多向你学习”的时候，职员不但认为这个领导非常谦虚，也一定会对这个领导更加信任，因为他理解自己的能力。
在微软公司，大家在技术上互帮互学，在工作中互相鼓励，没有谁天天都摆出盛气凌人的架子，也没有谁自觉矮人一头，这就自然营造出了一种坦诚、开放的工作氛围。
有自知之明的人在工作遇到挫折的时候不会轻言失败，在工作取得成绩时也不会沾沾自喜。认识自我，准确定位自我价值的能力不仅仅可以帮助个人找到自己合适的空间及发展方向，也可以帮助企业建立起各司其职、协同工作的优秀团队。有自知之明的人让人感觉他是一个自信、谦虚、真诚的人。
同理心
同理心（Empathy）是一个比较抽象的心理学概念，但解释起来非常简单：同理心指的是人们常说的设身处地、将心比心的做法。也就是说，在发生冲突或误解的时候，当事人如果能把自己放在对方的处境中想一想，也许就可以更容易地了解对方的初衷，消除误解。我们在生活中常说“人同此心，心同此理”，就是这个道理。
人与人之间的关系没有固定的公式可循，要从关心别人、体谅别人的角度出发，做事时为他人留下空间和余地，发生误会时要替他人着想，主动反省自己的过失，勇于承担责任。只要有了同理心，我们在工作和生活中就能避免许多抱怨、责难、嘲笑和讥讽，大家就可以在一个充满鼓励、谅解、支持和尊重的环境中愉快地工作和生活。
对于软件企业中的管理者来说，体现同理心的最重要一点就是要体谅和重视职员的想法，要让职员们觉得你是一个非常在乎他们的领导。拿我自己来说，我在工作中不会盲目地褒奖下属，不会动不动就给职员一些“非常好”、“不错”、“棒极了”等泛泛的评价，但是我会在职员确实做出了成绩的时候及时并具体地指出他对公司的贡献，并将他的业绩公之于众。例如，我会给部门内的全体职员发电子邮件说某个员工在上一周的工作中取得了出色的成绩，并详细说明他的工作成果，列举他的工作对于公司的重要价值，给出具体的表彰意见。这种激励员工的方式能够真正赢得员工的信任和支持，能够对企业的凝聚力产生巨大的影响。
同理心也是一种了解和认识他人的有效方法。我被调到新部门担任领导职位的时候，部门中有400多名员工，我都不认识。于是，我每周选出了10名员工，与他们共进午餐。在午餐时，我详细了解了每一个人的姓名、履历、工作情况以及他们对部门工作的建议。这些信息对于一个部门领导来说非常重要。在午餐会后，我立即根据这10名员工对部门的建议，安排部署相关的工作，并给这10名员工一一发回反馈意见，告诉他们我的处理方法。我的计划是在一个不长的时间里，认识并了解部门中的每一位员工，并在充分听取员工意见的基础上合理地安排工作。
自律
自律（Self-Regulation）指的是自我控制和自我调整的能力。这包括：自我控制不安定的情绪或冲动，在压力面前保持清晰的头脑；以诚实赢得信任，并且随时都清晰地理解自己的行为将影响他人。
自律对于领导者来说更为重要。作为软件企业的领导，要管理别人，要让下属信服，就要先从自我做起。这是因为，领导的做法通常是大家做事的目标和榜样，领导的每一次举手投足都会给下属留下深刻的印象，如果处理不好的话，可能会造成负面的影响。特别是当公司或团队处于危急时刻，需要领导带领大家克服困难、冲出重围的时候，如果领导表现得比职员还要急躁，翻来覆去拿不定主意，大家就会对领导丧失信心，公司或团队也会因此而走向失败。
有一次，我见过公司里的两个组即将被合并。第一个组的经理缺少自律，开会时对他的队伍说合并不是他的决定，他自己也不知下一步该怎么办。这个经理对未来没有信心，并猜测自己的队伍可能会被裁员。而第二个组的经理则在合并后告诉他的队伍这次合并对公司的好处。他也坦诚地说自己并不掌握所有的信息，但是他承诺会提醒上级尽快地做决定。并且，第二个经理还告诉大家他会尽其所能，帮助每一个员工安排最合理、最公平的出路。最后的结果是，第一个组的人很快就散了，他们的经理离开了公司，而第二个组的经理接管了合并后的机构。
自律必须建立在诚信的基础上。为了表现所谓的“自律”而在他人面前粉饰、遮掩自己的缺点，刻意表演的做法是非常不可取的。只有在赢得他人信任的基础上，严于律己、宽以待人，才能真正获得他人的尊重和赞许。
人际关系
人际关系包括在社会交往中的影响力、倾听与沟通的能力，处理冲突的能力、建立关系、合作与协调的能力，说服与影响的能力等等。
有些人在人际交往中的影响力是与生俱来的，他们在参加酒会或庆典的时候，只要很短的时间就能和所有人交上朋友。但也有些人并不具备这样的天赋，他们在社交活动中常常比较内向，宁愿一个人躲在角落里也不愿主动与人交谈。
我个人就缺乏人际交往的倾向。以前，我并不认为这有什么不妥，直到我遇到了一位非常具有个人影响力的经理为止。那个经理没有超人的智慧，但是他自称他认识了公司中几乎每一个有能力的人，并和其中的许多人成为了非常要好的朋友。我不知道他是怎么做到这一点的，但我很快就发现，他的这种能力对公司非常有用。比如，我需要在公司内部选拔一些职员到我的部门工作时，我就可以从他那里获得许多有关该职员的详细信息；与公司其他部门协调工作时，他的人际关系网也可以发挥非常大的作用。从那时起，我发现处理人际关系的能力对于一个人，特别是一个领导者来说非常重要，我开始特别注重培养自己在人际关系方面的影响力。
在技术研究和开发方面，沟通和说服的能力也至关重要。比如，我们开发出了一项先进的技术，要把它变成公司的产品。这首先要说服公司的决策层。我们必须细心准备我们的产品建议书，并通过精彩的演讲和现场展示让领导者相信我们研究出的技术对公司来说大有裨益，让决策层认为即将开发的产品可以在市场上取得成功。这些工作都需要我们具备处理人际关系、展示自己、影响他人的能力。
从优秀到卓越
在著名企业管理学家吉姆·柯林斯的《从优秀到卓越》（中信出版社，2002年）一书中，作者通过大量的案例调查和统计，讨论并分析了一家企业或一位企业的领导者是如何从优秀（Good）上升到卓越（Great）的层次的。柯林斯和他的研究小组耗费了10.5个人年，阅读并系统整理了6000多篇文章，记录了2000多页的专访内容，对1435家企业进行了问卷调查，收集了28家公司过去50年甚至更早的信息，进行了大范围的定性和定量分析，得出了如何使公司和公司的管理者从优秀跨越到卓越的令人惊异而振奋的答案。
根据吉姆·柯林斯得出的结论，优秀的公司和优秀的领导者很多，许多公司都可以在各自的行业里取得不俗的业绩。但如果以卓越的标准来衡量公司和个人的成绩，那么，能够保持持续健康增长的企业和能够不断取得事业成功的领导者都非常少。一位企业的领导者在成功的基础上，要想进一步提高自己，使自己的企业保持持续增长，使自己的个人能力从优秀向卓越迈进，就必须努力培养自己在“谦虚”、“执著”和“勇气”这三个方面的品质。
谦虚使人进步。许多领导者在工作中唯我独尊，不能听取他人的规谏，不能容忍他人和自己意见相左，这些不懂得谦虚谨慎的领导者也许可以取得暂时的成功，但却无法在事业上不断进步，达到卓越的境界。这是因为，一个人的力量终究有限，在瞬息万变的商业环境中，领导者必须不断学习，善于综合他人的意见，否则就将陷入一意孤行的泥潭，被市场所淘汰。比尔·盖茨就是一个非常谦虚的人。例如，他在每一次演讲结束后，请撰写演讲稿的人分析一下他的演讲有哪些不足之处，以便下一次改进。
执着是指我们坚持正确方向，矢志不移的决心和意志。无论是公司也好，还是个人也好，一旦认明了工作的方向，就必须在该方向的指引下锲而不舍地努力工作。在工作中轻言放弃或者朝三暮四的做法都不能取得真正的成功。微软公司在Windows 95操作系统取得了巨大的成功之后，比尔·盖茨仍然坚持发展企业级的Windows NT和Windows 2000操作系统。这是因为，他看到了企业级市场的广阔前景和微软在此方面的巨大潜力。经过几年的发展，微软公司的企业级操作系统终于在原本被Unix统治的市场上取得了成功，现在，包括个人操作系统在内的所有Windows产品都已经被构建在了更加安全、可靠的Windows NT架构之上。
成功者需要有足够的勇气来面对挑战。任何事业上的成就都不是轻易就可以取得的。一个人想要在工作中出类拔萃，就必须面对各种各样的艰难险阻，必须正视事业上的挫折和失败。只有那些有勇气正视现实，有勇气迎接挑战的人才能真正实现超越自我的目标，达到卓越的境界。正如马克·吐温所说：“勇气不是缺少恐惧心理，而是对恐惧心理的抵御和控制能力。”
结论
很多人认为，在IT和其他高科技领域内，西方人表现得更为出色，因此中国人只有吸取西方的企业文化才能获得一席之地。的确，IT产业内的一些新观点、新理念，与中国古老的东方文化之间确实有差异（例如，西方文化直截了当的沟通和主动参与的意识）。
不过，从本文中我们不难发现，成功所需要的一些最重要、最基本的素质大多还是中华的传统美德。在故宫里，我看到“正大光明”的匾额，其含义也就是“诚信和正直”；“学无止境”、“人贵有自知之明”、“将心比心”、“严于律己、宽以待人”都是中国历来推崇的道德观；人际关系更是在西方人公认在中国成功的秘诀；而最重要的“谦虚”、“执著”、“勇气”这三点则是中国传统文化的直接体现。因此，我认为中国人的EQ决不低于西方人，我对中国卓越的人才无比乐观。
在今天这个充满机遇和挑战的时代里，在软件产业这个高速发展、不断创新的领域内，只有那些不懈努力、善于把握自己、勇于迎接挑战的人才能取得真正的成功。我个人衷心地希望中国高新技术产业能够在新世纪中蓬勃发展，中国的人才能够在事业上不断取得成功，实现从优秀到卓越的跨越。
给中国学生的第二封信：从优秀到卓越
李开复
2003年12月
三年前离开中国时，我在《给中国学生的一封信》中，与广大青年学生一道，讨论了一些大家共同关心的话题，并结合自己的学习和工作经历，就青年学生如何对待机遇、学业、工作、他人、自己等问题，阐述了我的个人意见。我提出诚信和正直、主动意识、交流和沟通、努力一生学习这几个个人素质方面值得中国学生高度重视，
在这三年，许多中国学生，经过电子邮件、讲座后的问答、座谈、和其他渠道（例如在电视节目“对话”中），常对我提到“如何成才”的问题。对于这个大家关注的问题，我整理了许多材料，集成这封“第二封信”。
在第一封信力所提到的个人素质或“价值观”是成材的必要的基础。但是，除了素质之外，成才同样的需要领导能力（leadership）。很多人误以为领导能力最重视的是天资、号召力、管理能力。但是，根据我个人的经验，和最近一些研究的结论，如果你想成为一名成功的领导，最重要的不是你的智商（IQ）,而是你的情商（EQ）。最重要的不是要成为一个有号召力令人信服的领导，而是要成为一个有 “谦虚”、“执著”和“勇气” 的领导。
这“给中国学生的第二封信”是为那些希望不断提高自己，不断学习事业成功所必需的基本技能和领导艺术的人所写的。第一部分重申了《给中国学生的一封信》中讨论过的有关个人素质的话题；第二部分阐释了领导能力中最重要的情商；第三部分给出了卓越的领导所必须具备的、有别于普通人的基本特质。
如何提高个人素质
诚信和正直
一个人的人品如何直接决定了这个人对于社会的价值。而在与人品相关的各种因素之中，诚信又是最为重要的一点。微软公司在用人时非常强调诚信，我们只雇佣那些最值得信赖的人。去年，当微软列出对员工期望的“核心价值观”时，诚信（honesty and integrity）被列为一位。
在我发表“第一封信”后，曾经有一位同学问我：为什么一个公司要涉入员工的道德呢？我回答：这是为了公司自己的利益。例如，一位应聘者在面试时曾对我说，如果他能加入微软公司，他就可以把他在前一家公司所做的发明成果带过来。对这样的人，无论他的技术水平如何，我都不会雇用他。他既然可以在加入微软时损害先前公司的利益，那他也一定会在加入微软后损害微软公司的利益。
另外有一位同学看了“对话”后问我，为什么我会把诚信放在智慧之前呢？难道我们会去衡量员工的诚信和他们的智慧而给诚信更高的比重？其实，我们的衡量都在直接的工作目标上，并不会对诚信或智慧做直接的衡量。但是，作为第一“核心价值”，诚信是我们对员工最基本的要求。 我们根本不会去雇用没有诚信的人。如果一个员工发生了严重诚信的问题，他会被立刻解雇。
当一个公司这么重视诚信，员工一定更值得信赖。因此，公司对员工也能够完全信任，让他们发挥自己的才能。在微软公司，公司的各级管理者都会给员工较大的自由和空间发展他们的事业，并在工作和生活上充分信任、支持和帮助员工。只要是微软录用的人，微软就会百分之百地信任他。和一些软件企业对员工处处提防的做法不同，微软公司内的员工可以看到许多源代码，接触到很多技术或商业方面的机密。正因为如此得到公司的信任，微软的员工对公司才有更强的责任心和更高的工作热情。
培养主动意识
坦白地说，中国的学生和职员大多属于比较内向的类型，在学习和工作中还不够主动。在学校时，学生们往往需要老师安排学习任务，或是按照老师的思路做课题研究。在公司里，中国职员常常要等老板吩咐做什么事、怎么做之后，才开始工作。此外，许多中国人并不善于推销和宣传自己，这恐怕和中国自古以来讲求中庸的文化氛围有很大关系。
但是，要想在现代企业中获得成功，就必须努力培养自己的主动意识：在工作中要勇于承担责任，主动为自己设定工作目标，并不断改进方式和方法；此外，还应当培养推销自己的能力，在领导或同事面前要善于表现自己的优点，有了研究成果或技术创新之后要通过演讲、展示、交流、论文等方式和同事或同行分享，在工作中犯了错误也要勇于承认。只有积极主动的人才能在瞬息万变的竞争环境中获得成功，只有善于展示自己的人才能在工作中获得真正的机会。
客观、直接的交流和沟通
开诚布公的交流和沟通是团队合作中最重要的环节。人与人之间遮遮掩掩、言不由衷甚至挑拨是非的做法都会严重破坏团队中的工作氛围，阻碍团队成员间的正常交流，并最终导致项目或企业经营失败。
比如，在开会讨论问题的时候，与会的所有人员都应当坦诚地交换意见，这样才能做出正确的决定。如果某个人因为考虑到某些其他因素（比如不愿反驳上级领导的意见）而在会议上不敢表达自己的观点，一味地唯唯诺诺，会后到了洗手间里再和别人说“其实我不同意他的观点”，这种戴着假面具工作的人不但不能坚持自己的观点，还会破坏公司内部的沟通和交流渠道，对工作产生负面的影响。
微软公司有一个非常好的文化叫“开放式交流（Open communication）”，它要求所有员工在任何交流或沟通的场合里都能敞开心扉，完整地表达自己的观点。在微软开会时，大家如果意见的不统一，一定要表达出来，否则公司可能错过良机。当Internet刚开始时，很多微软的领导者不理解、不赞成花太多精力做这个“不挣钱”的技术。但是有几位技术人员，他们不断地提出他们的意见和建议，虽然他们的上司不理解，但是仍然支持他们“开放式交流”的权利。后来，他们的声音很快的达到比尔•盖茨的耳里，促成比尔改变公司方向，彻底支持Internet。从这个例子我们可以看到，这种开放的交流环境对微软公司保持企业活力和创新能力都是非常重要的。
彻底的开放式交流也有缺点。开放式交流有时会造成激烈的辩论甚至是争吵，而吵到气头上有时会说出不尊重别人的语言，会破坏人与人之间的关系。因此，微软公司的总裁史蒂夫•鲍尔默去年在微软的核心价值观中，提出我们要把这种开放式交流文化改进成“开放并相互尊重（Open and respectful）”。这要求我们在相互交流时充分尊重对方。当我们不同意对方的意见时，一定要用建设性的语言提出。
挑战自我、学无止境
从一名大学生到一名程序员，再到一位管理者，在软件人才的成长历程中，学习是永无止境的。在大学期间，我们要打好基础，培养自己各方面的素质和能力；工作以后，我们应当努力在实际工作中学习新的技术并积累相关经验；即使走上了管理岗位，我们也应当不断学习，不断提高自己。软件产业本身就是一个每天都会有新技术、新概念诞生，充满了活力和创造力的产业。作为软件产业的从业人员，如果只知道闭门造车、抱残守缺，我们就必然会落伍，必然会被市场淘汰。
许多中国学生喜欢与别人竞争，但这种竞争更多地表现为一种“零和游戏”，无法使自己和他人得到真正的提高。我建议大家最好能不断和自己竞争——不要总想着胜过别人，而要努力超越自我，不断在自身的水平上取得进步。
在学习的过程中，打好基础最为重要。从软件产业对人才的需求来看，我们必须学好数学和英语这两门基础学科。数学是所有工程科学的基础，无论是软件产品的开发，还是软件技术的研究，都要大量使用数学方法和数学原理。英文则是软件行业中的国际语言，要想了解国际上软件技术的发展趋势，掌握最新的研究成果，或是与国外同行进行技术交流，就必须掌握英文的听、说、读、写，能够在工作中熟练使用英文来解决问题。
情商和领导能力
同学们都希望增进自己的leadership skills（领导能力）。从我的经验和一些最近的研究结果看来，领导能力中最重要的是所谓的“情商”( EQ）。
智商（IQ）反映人的智慧水平，情商则反映了人在情感、情绪方面的自控和协调能力。在高新技术企业中，大家都知道智慧的重要，但是情商的重要性甚至超过了智商。我看过一篇文章，该文的作者调查了188个公司，他用心理学方法测试了这些公司里每一名员工的智商和情商，并将测试结果和该员工在工作上的表现联系在一起进行分析。经过研究，该文的作者发现，在对个人工作业绩的影响方面，情商的影响力是智商的两倍。此外，他还专门对公司中的高级管理者进行了分析。他发现在高级管理者中，情商对于个人成败的影响力是智商的九倍。这说明，智商略逊他人的人如果拥有更高的情商指数，也一样可以获得成功；反之，智商很高，但情商不足的人欠缺“领导能力”，很难成为一个成功的领导。
什么是情商？
在现代社会，如果你只知道智商而不晓得情商的话，你至少在意识上已经落伍了。许多心理学家早已明确地指出，单单使用智商的标准考察一个人在才智方面的表现，并不足以准确预测这个人在事业上可能取得的成就。为了全面考察个人能力，特别是考察个人在社会生活中的适应能力和创造能力，心理学家们提出了情商的概念。
情商主要是指那些与认识自我、控制情绪、激励自己以及处理人际关系等相关的个人能力。在情商所描述的各项能力因素中，自觉、同理心、自律和人际关系是四种对现代人的事业成败起决定性作用的关键因素。
智商是先天赋予的，但是情商是可以培养的。多花功夫理解和应用这四种情商的关键因素。除此之外，因为情商不是自己能看清楚的，我建议可多理解别人对你的看法、多吸取别人（尤其是情商高的人）的意见。
自觉
中国人常说，人贵有自知之明。这实际上是说，社会生活中的每个人都应当对自己的素质、潜能、特长、缺陷、经验等各种基本能力有一个清醒的认识，对自己在社会工作生活中可能扮演的角色有一个明确的定位。心理学上把这种有自知之明的能力称为“自觉”，这通常包括察觉自己的情绪对言行的影响，了解并正确评估自己的资质、能力与局限，相信自己的价值和能力等几个方面。
我的下属中有一个“自觉心”明显不足的人：他虽然有一些能力，但是他自视甚高，总是对自己目前的职位不满意，随时随地自吹自擂，总是不满现状。前一段时间，他认为我不识才，没有重用他，决定离开我的组，并期望在微软其他组中另谋高就。但是，他最终发现，自己不但找不到更好的工作，公司里的同事也都对他颇有微辞，认为他缺少自知之明，期望和现实相距太远。最近，他沮丧地离开了公司。接替他职位的人，是一个能力很强，而且很有“自觉心”的人。虽然这个人在上一个职位工作时不很成功，但他理解自己升迁太快，愿意自降一级来做这份工作，以便打好基础。他现在的确做得很出色。
简单地说，一个人既不能对自己的能力判断过高，也不能轻易低估自己的潜能。对自己判断过高的人往往容易浮躁、冒进，不善于和他人合作，在事业遭到挫折时心理落差较大，难以平静对待客观事实；低估了自己的能力的人，则会在工作中畏首畏尾、踟蹰不前，没有承担责任和肩负重担的勇气，也没有主动请缨的积极性。无论是上述哪一种情况，个人的潜力都不能得到充分的发挥，个人事业也不可能取得最大的成功。
有自知之明的人既能够在他人面前展示自己的特长，也不会刻意掩盖自己的欠缺。谈成自己的不足而向他人求教不但不会降低了自己，反而可以表示出自己虚心和自信，赢得他人的青睐。比如，当一个领导对某个职员说“在技术上你是专家，我不如你，我要多向你学习”的时候，职员不但认为这个领导非常谦虚，也一定会对这个领导更加信任，因为他理解自己的能力。
在微软公司，大家在技术上互帮互学，在工作中互相鼓励，没有谁天天都摆出盛气凌人的架子，也没有谁自觉矮人一头，这就自然营造出了一种坦诚、开放的工作氛围。
有自知之明的人在工作遇到挫折的时候不会轻言失败，在工作取得成绩时也不会沾沾自喜。认识自我，准确定位自我价值的能力不仅仅可以帮助个人找到自己合适的空间及发展方向，也可以帮助企业建立起各司其职、协同工作的优秀团队。有自知之明的人让人感觉他是一个自信、谦虚、真诚的人。
同理心
同理心（Empathy）是一个比较抽象的心理学概念，但解释起来非常简单：同理心指的是人们常说的设身处地、将心比心的做法。也就是说，在发生冲突或误解的时候，当事人如果能把自己放在对方的处境中想一想，也许就可以更容易地了解对方的初衷，消除误解。我们在生活中常说“人同此心，心同此理”，就是这个道理。
人与人之间的关系没有固定的公式可循，要从关心别人、体谅别人的角度出发，做事时为他人留下空间和余地，发生误会时要替他人着想，主动反省自己的过失，勇于承担责任。只要有了同理心，我们在工作和生活中就能避免许多抱怨、责难、嘲笑和讥讽，大家就可以在一个充满鼓励、谅解、支持和尊重的环境中愉快地工作和生活。
对于软件企业中的管理者来说，体现同理心的最重要一点就是要体谅和重视职员的想法，要让职员们觉得你是一个非常在乎他们的领导。拿我自己来说，我在工作中不会盲目地褒奖下属，不会动不动就给职员一些“非常好”、“不错”、“棒极了”等泛泛的评价，但是我会在职员确实做出了成绩的时候及时并具体地指出他对公司的贡献，并将他的业绩公之于众。例如，我会给部门内的全体职员发电子邮件说某个员工在上一周的工作中取得了出色的成绩，并详细说明他的工作成果，列举他的工作对于公司的重要价值，给出具体的表彰意见。这种激励员工的方式能够真正赢得员工的信任和支持，能够对企业的凝聚力产生巨大的影响。
同理心也是一种了解和认识他人的有效方法。我被调到新部门担任领导职位的时候，部门中有400多名员工，我都不认识。于是，我每周选出了10名员工，与他们共进午餐。在午餐时，我详细了解了每一个人的姓名、履历、工作情况以及他们对部门工作的建议。这些信息对于一个部门领导来说非常重要。在午餐会后，我立即根据这10名员工对部门的建议，安排部署相关的工作，并给这10名员工一一发回反馈意见，告诉他们我的处理方法。我的计划是在一个不长的时间里，认识并了解部门中的每一位员工，并在充分听取员工意见的基础上合理地安排工作。
自律
自律（Self-Regulation）指的是自我控制和自我调整的能力。这包括：自我控制不安定的情绪或冲动，在压力面前保持清晰的头脑；以诚实赢得信任，并且随时都清晰地理解自己的行为将影响他人。
自律对于领导者来说更为重要。作为软件企业的领导，要管理别人，要让下属信服，就要先从自我做起。这是因为，领导的做法通常是大家做事的目标和榜样，领导的每一次举手投足都会给下属留下深刻的印象，如果处理不好的话，可能会造成负面的影响。特别是当公司或团队处于危急时刻，需要领导带领大家克服困难、冲出重围的时候，如果领导表现得比职员还要急躁，翻来覆去拿不定主意，大家就会对领导丧失信心，公司或团队也会因此而走向失败。
有一次，我见过公司里的两个组即将被合并。第一个组的经理缺少自律，开会时对他的队伍说合并不是他的决定，他自己也不知下一步该怎么办。这个经理对未来没有信心，并猜测自己的队伍可能会被裁员。而第二个组的经理则在合并后告诉他的队伍这次合并对公司的好处。他也坦诚地说自己并不掌握所有的信息，但是他承诺会提醒上级尽快地做决定。并且，第二个经理还告诉大家他会尽其所能，帮助每一个员工安排最合理、最公平的出路。最后的结果是，第一个组的人很快就散了，他们的经理离开了公司，而第二个组的经理接管了合并后的机构。
自律必须建立在诚信的基础上。为了表现所谓的“自律”而在他人面前粉饰、遮掩自己的缺点，刻意表演的做法是非常不可取的。只有在赢得他人信任的基础上，严于律己、宽以待人，才能真正获得他人的尊重和赞许。
人际关系
人际关系包括在社会交往中的影响力、倾听与沟通的能力，处理冲突的能力、建立关系、合作与协调的能力，说服与影响的能力等等。
有些人在人际交往中的影响力是与生俱来的，他们在参加酒会或庆典的时候，只要很短的时间就能和所有人交上朋友。但也有些人并不具备这样的天赋，他们在社交活动中常常比较内向，宁愿一个人躲在角落里也不愿主动与人交谈。
我个人就缺乏人际交往的倾向。以前，我并不认为这有什么不妥，直到我遇到了一位非常具有个人影响力的经理为止。那个经理没有超人的智慧，但是他自称他认识了公司中几乎每一个有能力的人，并和其中的许多人成为了非常要好的朋友。我不知道他是怎么做到这一点的，但我很快就发现，他的这种能力对公司非常有用。比如，我需要在公司内部选拔一些职员到我的部门工作时，我就可以从他那里获得许多有关该职员的详细信息；与公司其他部门协调工作时，他的人际关系网也可以发挥非常大的作用。从那时起，我发现处理人际关系的能力对于一个人，特别是一个领导者来说非常重要，我开始特别注重培养自己在人际关系方面的影响力。
在技术研究和开发方面，沟通和说服的能力也至关重要。比如，我们开发出了一项先进的技术，要把它变成公司的产品。这首先要说服公司的决策层。我们必须细心准备我们的产品建议书，并通过精彩的演讲和现场展示让领导者相信我们研究出的技术对公司来说大有裨益，让决策层认为即将开发的产品可以在市场上取得成功。这些工作都需要我们具备处理人际关系、展示自己、影响他人的能力。
从优秀到卓越
在著名企业管理学家吉姆·柯林斯的《从优秀到卓越》（中信出版社，2002年）一书中，作者通过大量的案例调查和统计，讨论并分析了一家企业或一位企业的领导者是如何从优秀（Good）上升到卓越（Great）的层次的。柯林斯和他的研究小组耗费了10.5个人年，阅读并系统整理了6000多篇文章，记录了2000多页的专访内容，对1435家企业进行了问卷调查，收集了28家公司过去50年甚至更早的信息，进行了大范围的定性和定量分析，得出了如何使公司和公司的管理者从优秀跨越到卓越的令人惊异而振奋的答案。
根据吉姆·柯林斯得出的结论，优秀的公司和优秀的领导者很多，许多公司都可以在各自的行业里取得不俗的业绩。但如果以卓越的标准来衡量公司和个人的成绩，那么，能够保持持续健康增长的企业和能够不断取得事业成功的领导者都非常少。一位企业的领导者在成功的基础上，要想进一步提高自己，使自己的企业保持持续增长，使自己的个人能力从优秀向卓越迈进，就必须努力培养自己在“谦虚”、“执著”和“勇气”这三个方面的品质。
谦虚使人进步。许多领导者在工作中唯我独尊，不能听取他人的规谏，不能容忍他人和自己意见相左，这些不懂得谦虚谨慎的领导者也许可以取得暂时的成功，但却无法在事业上不断进步，达到卓越的境界。这是因为，一个人的力量终究有限，在瞬息万变的商业环境中，领导者必须不断学习，善于综合他人的意见，否则就将陷入一意孤行的泥潭，被市场所淘汰。比尔·盖茨就是一个非常谦虚的人。例如，他在每一次演讲结束后，请撰写演讲稿的人分析一下他的演讲有哪些不足之处，以便下一次改进。
执着是指我们坚持正确方向，矢志不移的决心和意志。无论是公司也好，还是个人也好，一旦认明了工作的方向，就必须在该方向的指引下锲而不舍地努力工作。在工作中轻言放弃或者朝三暮四的做法都不能取得真正的成功。微软公司在Windows 95操作系统取得了巨大的成功之后，比尔·盖茨仍然坚持发展企业级的Windows NT和Windows 2000操作系统。这是因为，他看到了企业级市场的广阔前景和微软在此方面的巨大潜力。经过几年的发展，微软公司的企业级操作系统终于在原本被Unix统治的市场上取得了成功，现在，包括个人操作系统在内的所有Windows产品都已经被构建在了更加安全、可靠的Windows NT架构之上。
成功者需要有足够的勇气来面对挑战。任何事业上的成就都不是轻易就可以取得的。一个人想要在工作中出类拔萃，就必须面对各种各样的艰难险阻，必须正视事业上的挫折和失败。只有那些有勇气正视现实，有勇气迎接挑战的人才能真正实现超越自我的目标，达到卓越的境界。正如马克·吐温所说：“勇气不是缺少恐惧心理，而是对恐惧心理的抵御和控制能力。”
结论
很多人认为，在IT和其他高科技领域内，西方人表现得更为出色，因此中国人只有吸取西方的企业文化才能获得一席之地。的确，IT产业内的一些新观点、新理念，与中国古老的东方文化之间确实有差异（例如，西方文化直截了当的沟通和主动参与的意识）。
不过，从本文中我们不难发现，成功所需要的一些最重要、最基本的素质大多还是中华的传统美德。在故宫里，我看到“正大光明”的匾额，其含义也就是“诚信和正直”；“学无止境”、“人贵有自知之明”、“将心比心”、“严于律己、宽以待人”都是中国历来推崇的道德观；人际关系更是在西方人公认在中国成功的秘诀；而最重要的“谦虚”、“执著”、“勇气”这三点则是中国传统文化的直接体现。因此，我认为中国人的EQ决不低于西方人，我对中国卓越的人才无比乐观。
在今天这个充满机遇和挑战的时代里，在软件产业这个高速发展、不断创新的领域内，只有那些不懈努力、善于把握自己、勇于迎接挑战的人才能取得真正的成功。我个人衷心地希望中国高新技术产业能够在新世纪中蓬勃发展，中国的人才能够在事业上不断取得成功，实现从优秀到卓越的跨越。
Subscribe to:
Posts (Atom)