第3回 タイムマネジメントは急がば回れ

第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すべてについて、漏れなく作業をリストアップする。常に先を見越して、早めにアクションを取る姿勢も忘れずに。
・実績が計画から乖離した際には、ステークホルダーにタイムリーに情報共有するとともに、是正措置を取る。
・メンバーに時間に対するコスト意識を持たせ、チームとしてのパフォーマンスを高める。

第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番については、仕様変更手順に基づき、ステアリングコミッティ（プロジェクト運営委員会）での承認が必要になります。仕様変更依頼書を作成しますので必要事項に記入をお願いします」
顧客：「分かった。ありがとう。よろしく頼むよ」

　このケースで重要なポイントは、追加要件に対応することが難しい場合によく行われている「優先順位を付けて対応を考える」ことにある。矢見雲マネージャの例では、個別の要件ごとに判断しているが、このような場合、各要件に必要とされる理由や背景に基づいて判断することになる。しかし、これだとどうしてもあれも重要、これも重要となってしまう、あるいは顧客とこちらで重要度が一致しないということに陥りがちではないだろうか。

　重要なのは、どういう基準で優先順位を付けるかについて合意することである。顧客と開発側の双方が容易に判断できるプロジェクト全体を通しての判断基準をておくことにより、お互いに納得のいく意思決定が迅速にできる。

■今回のまとめ

・スコープマネジメントとは、プロジェクトの目標を達成するために必要な成果物とタスクを、プロジェクト期間を通じて定義していき、その内容をやり遂げることを保証すること。
・スコープマネジメントは、プロジェクトの成功／失敗に大きく影響を及ぼすこと。
・スコープを決定する際は、プロジェクトの関係者が誰であるかをしっかり押さえて、関係者「全員」の合意を得ること。
・定義したスコープは、顧客／開発側双方で確認できるよう「可視化」しておき合意を得ること。
・スコープの変更を検討する際に、要件の優先順位を検討する場合は、優先順位付けの判断基準を明確にすること。

第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の活動そのものをコンサルティングの対象とするサービスを展開している。

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スキル標準のとおりに分類されているわけではないですから。

中国進出ブームの死角──逼迫する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のさまざまな難題を見ていきたい。

第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 要求の品質を上げるための開発ライフサイクル

　要求定義とテストシナリオ作成を同時期に、反復的に行うことによって、すべての要求定義が完了するタイミングが、従来のやり方に比べて遅れるとしても、その効果はそれを補って余りあるものとなります。テスト可能であるためには、要求に矛盾点がなく、あいまいさもない状態でなければなりません。ですから、テストシナリオを考えたときに、合否の判断基準が明確ではない場合は、要求としては不適切だと判断し、見直すことができるのです。

　このようにして、あいまいさがなく、高品質な要求仕様を定義することができれば、現状のオフショア開発で直面している問題のかなりの部分を解決することができますし、さらにいうと、そのような要求仕様の定義をすることで、わざわざオフショア開発をするまでもなく競争力を持つことができるはずです。もちろん、すべてのソフトウェア開発プロジェクトでこれが実行されれば、またしても価格競争に陥ることになるかもしれませんが、幸か不幸か、まだまだオフショア開発以前のところでの改善ポイントがありますから心配には及びません。

　今回は、開発ライフサイクルからのアプローチによって、ソフトウェア要求の問題を改善し、オフショア開発が行える要求定義を行う、という内容でしたが、実際にどのような要求定義（要求開発）を行えばよいのかというより実践的な内容については、また別の機会にお伝えできればと思います。

　次回は、「コンポーネント再利用できていますか？」というタイトルでお伝えする予定です。

第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/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自分戦略研究所 > 自分戦略研究室）

第４回 いいかげんにして！ 日本企業─中国に嫌われる理由

いいかげんにして！ 日本企業
─中国に嫌われる理由
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歳。

今、ある業界に今までにないビジネスの仕組みを導入するプロジェクトを担当している。海外での様々なプロジェクト経験や業界の方々とのお付き合いを通して「自分の頭の中に思い描いていたこと」と、社会の環境がピタッと合ってスタートしたプロジェクト。業界全体の旗振りのような役割をしているので大きな責任とプレッシャーを感じている。でも、実現したら業界のビジネスそのものを大きく変革することができる。アクセンチュアでやりたいと思っていたことに、ようやく辿り着けた。このプロジェクトを死んでもものにしたい。コンサルタントという職業の面白さと醍醐味は、夢を語れるところにある。一プレイヤーでは語れない夢も、コンサルタントなら語れる。だから、コンサルタントを目指す人には夢を語って欲しい。そつのない答えばかりじゃつまらないよ。

どっか抜けてる、ストイック

高校時代。

自分で言うのもなんだけれど、小・中学校時代は真面目を絵に描いたような模範的な子供だった。そのせいか高校に入って反動が出た。きっかけは軽音楽部で知り合った友人たちだった。バンドを組んで、音楽ばっかりやっていて、授業はしょっちゅうさぼったし、不良を気取ってバカなこともした。でも、ほんとに魅力的な仲間たちだった。バンド仲間のうち3人は大学に行かずに自分の好きな道を選んだが、それは進学校だったその高校でちょっとした事件だった。自分にはそこまでの勇気はなかった。「将来、何になりたい？」という問いには、まだ答えられなかった。



浪人時代。

今から考えると、不思議な1年だった。浪人中に昭和天皇が亡くなり、バブルはそのピークを迎えようとしていた。19歳の自分の目にも、世の中が大きく変わろうとしているのがわかった。経済やビジネスというものに、初めて興味を持った。いま目の前で起こっている出来事の原因や本質はどこにあるんだろう？　いろんな人がいろんなことを言っていたが、どれもこれも何か違うような気がして、自分なりに調べてみることにした。そんなことばかりやっていたら、志望学部を落ちた。



大学時代。

新しく知り合った仲間たちとバンド活動を再開したが、浪人時代に目覚めた興味は音楽だけには留まっていなかった。海外旅行もそのひとつ。お金を貯めて年に一度海外でホームステイした。旅行の度に自分の思考のフレームが大きくなっていくような気がした。海外に行くと、そこにあって日本にないものを探した。コレは日本に持ってきたら絶対当たるなと思ったら、次の年に商社が輸入したりして、自分の感覚にちょっと自信を持った。当時ブームだった学生起業家の話を聞きに行ったりしたこともある。こんなふうにして私のやりたいことは、音楽からビジネスに入れ替わった。でも、ずっと一緒にやってきたバンド仲間に、音楽を辞めると言い出すのはつらかった。自分以外のメンバーはプロ志向で、デビューの可能性があっただけになおさらだ。最後のライブ。楽屋で泣いた。あの時から楽器には触っていない。



アクセンチュア入社後。

面接で会った人たちにインスピレーションを感じて、アクセンチュアに入社して以来9年。これまでさまざまな業種のクライアントを相手にプロジェクトを経験してきた。すべてのプロジェクトが思い出深く、その度に自分は成長できたと思っている。延べ2年間にわたる海外での経験も、より高い視点を持つ時間として有意義だった。他の会社で働いた経験はないけれど、アクセンチュアのような環境を提供してくれる会社はそうはないと思っている。でも、この環境に甘えたくない。仕事にはいつも後がないという気持ちで向かい、それがコンサルタントとして生きている最低限の心構えだと思っている。失敗してもどうにかなるだろう、転職すればいいやとは絶対に思いたくない。それに、もしそんないい加減な気持ちでこの仕事をしていたら、あの仲間たちに笑われてしまう。「なんだよ、お前が音楽の代わりに選んだものって、そんなもんだったのかよ」って、ね。

天邪鬼な情熱家

16歳。

あまのじゃくな性格、だと思う。他人とは違うことをやりたいという気持ちが、いつもどこかにある。高校時代は絵を描いていた。普通科の進学校。賢いやつらばかりの中で、自分の賢さが消えた時、アイデンティティを表現するのは好きな絵しかないと思った。内緒でアルバイトをして、稼いだお金で美大の受験予備校に通っていた。シュールレアリスムやダダイズムに憧れて、無意識を絵にしたいと思った。あの頃の絵を見ると、暗くて、青臭くて、恥ずかしい。でも、いろんな矛盾を抱えながら必死になって闘っていた10代の自分が確かにそこにいたんだなって、思う。



18歳。

結局、絵の道は諦めて、英文科へ進んだ。しばらくは特にやることもなく、ぶらぶらしていた夏、地元の木曽川べりを車で走っていたら、ウィンドサーファーたちが風に乗ってかっとんでいた。なぜか無性に感動し、これだ！と思った。すぐにショップに駆け込んで、道具一式をローンで買った。その日から、ウィンドサーフィンが生活の一部になる。風のある日は、いつも海か川にいて、そこには、いつもの仲間たちがいた。3年の時、ライダーと呼ばれるスポンサー付きのセミプロになった。できることなら、プロになりたかった。でも、ウィンドだけじゃ食っていけないこともわかっていたから、すぱっと諦めた。中途半端は好きじゃない。



22歳。

就職先にこだわりはなかった。銀行、住宅メーカー、情報関係の出版社、消防士の試験まで受けた。どこも面白そうだったけれど、どこも決め手に欠けた。就職活動のシーズンも終わりに近づいた頃、アクセンチュアのセミナーがあった。そこに行くまで、コンサルタントにはどこか人間味に欠けた冷たいイメージを持っていた。でも、それはまったくの誤解だった。セミナーでも個別面談でも、語りかけてくるアクセンチュアの社員たちは、みんな情熱的で熱かった。彼らの目は、風が吹けば必ず集まってくるウィンドサーファーたちにどこか似ているような気がした。受け身ではなく、自発的にやれるような仕事がしたい。そう思っていた僕にとって、アクセンチュアは最高の場であるように思えた。



25歳。

入社以来、クライアント企業の情報システム部門の仕事に携わることが多い。とても充実した5年間だったけれど、一度だけ会社を辞めようかなと思ったことがある。上司にさりげなく相談したら、僕の気持ちを見透かすように言われた。「おまえは、アクセンチュアでできることをやったのか？」はっとした。その頃の自分は、わがままだった。やりたい仕事ができないと焦り、それを環境や誰かのせいにしていたのだと思う。自発的に働きたくてアクセンチュアに入ったのに、なんのことはない受け身で仕事をしていたのだ。上司の一言で、意識が変わった。与えられた仕事だけでなく、自分から働きかけるようになった。働きかければチャンスはやってくる。コアコンピタンスがないこと。それが僕の強みなんじゃないかと思っている。僕はあらゆることに興味が持てる。環境が変わっても全然苦にならないし、目標に向う瞬発力とスピードにはちょっと自信がある。マネジャーになった今も、「市川をつっこめば、なんとかなる」、と頼られる存在であり続けたい。

NECソフトが中国でのオフショア開発に失敗で20億円の損

NECソフトは中国でのオフショア開発に失敗し、多額の損失を出した。中国に発注していたJavaによる大規模な販売物流システムの開発が難航し、このプロジェクトだけで上半期に約10億円の損失を出した。下半期と合わせると損失は20億円程度に膨らむ模様だ。オフショア開発は、コスト削減を目的に海外のソフト会社へ開発を委託すること。

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年目の若い中国
人社員にブリッジＳＥという肩書きを与えて、開発プロジェクトの
真っ只中に投入する習慣が出来上がってしまった。

●「中国オフショア開発は新規事業である」
私が日ごろからそう訴えているにもかかわらず、無計画のままオフ
ショア開発に若手社員を投入する企業が後を絶たない。

●「彼は日本での留学経験もあるから大丈夫！」などを理由に、入
社間もない中国人社員がブリッジＳＥに仕立て上げられる。中国ベ
ンダにとっても、本人にとっても、ましてや発注側の日本企業にとっ
ても不幸な話だ。

●「オフショア開発こそ、プロジェクトマネジメントの専門家を使
うべきである」
過去にオフショア開発で成功してきた会社には、３年先を見据えた
しっかりとした人材戦略がある。

●では、自社に中国人ＳＥがいないとオフショア開発に挑戦する資
格がないのだろうか？いややい、決してそうではない。以下の条件
が整えば、中国を全く知らない日本人でもオフショア開発のコーディ
ネート業務は十分に可能だ。

・中国に好意的であること
・オフショア開発に前向きであること
・サブリーダの経験があること
・専門家から正しい指導を受けられること

●あなたの会社でも、今すぐ開発コーディネータの育成に着手しよ
う。プロジェクトリーダとしての技術基盤、異文化コミュニケーショ
ン能力、そして専門的な対中交渉テクニックを学ぶ仕組みがオフショ
ア開発における人材育成の要諦だ。

オフショア開発、現実のコスト削減率は15％程度

　米調査会社のMETA Groupによると、インドなどに開発作業を委託するオフショアアウトソーシング開発プロジェクトで、多くの企業は十分なリスク分析を行っていないという。同社は、実際のコスト削減は予想ほど高くないと指摘し、関心を集めているオフショア開発の導入上の注意を呼びかけている。

　META Groupによると、多くの企業は、最大のコスト要因である人件費の削減率がプロジェクト全体の削減率に比例すると期待するが、実際はそうではないという。例えば、インドの開発者の人件費は米国の同レベルのスキルを持つ開発者の6割と言われているが、プロジェクト運行モデルの違いや、隠れたコストが発生することなどから、初年度の実際のコスト削減は15％～20％減にとどまるという。

　オフショア開発は、経費削減などのメリットから、米国を中心に近年高い注目を集めており、今後2年間20％～25％増で成長するとされている。同社はこのような傾向に対し、4つのリスク要因を挙げてリスク分析の重要性を訴えている。リスク要因としては、（1）セキュリティ侵害や知的財産保護などの危険性（2）開発費が予算を超えることが多く、15％程度増となることもある（3）文化の違い（4）現地ベンダーへのIT部門間の知識移転で初年度は生産性が下がる―ことを挙げている。

プロジェクトファイル（コンサルティング）

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コマースは、本当のスタートを切ることになる。