http://www.atmarkit.co.jp/fbiz/column/fl/reg091/01.html#takahashi
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=1927&forum=15&start=8&15
SE派遣業者に職安が違法警告
ネット時代に対応できない現行の法制度
高橋智明
2002/8/9
SEなどIT関連専門に人材サービスを行っている企業が、労働者派遣法※に違反しているとして公共職業安定所（職安）から警告を受ける事態が起こっている。背景には現行の派遣法が、ネットワーク時代のサービス業の在り方やIT業界での働き方に対応し切れていない点がある。
■業界でありふれた外部委託が違法
- PR -
職安から警告を受けているのは、大手人材派遣業者、S社の子会社で、SEの派遣やシステム開発の請負などを行っているA社である。問題となったのは、次のような形態のサービスだ。
仮に大企業X社が、あるシステム開発をA社に発注したとする。このとき、X社とA社とは業務委託契約を結ぶ。実際の業務は、A社の社員、あるいはA社と契約を結んだ人がX社に詰め掛け勤務することになる。
しかし、仕事のできるSEは昨今どこでも不足がち。A社が確保した人材だけでは足りないことが往々にしてある。こうしたとき、A社は同業のB社を孫請けとして、業務を2次発注する。さらに、B社がC社をひ孫請けとして利用することもある。B社とC社の社員はいずれも「A社の社員」としてX社に来ることになる。X社から見れば、すべてA社の社員という状態だ。
ここまで読まれた読者の多くは、「これは外部業者に委託してシステム開発やソフト開発を行うときの普通のやり方だ」と思われるに違いない。しかし、労働者派遣法を厳密に適用するとこうしたやり方が違法と判定されることもある。
■派遣と業務請負を分ける境界
労働者派遣法では、派遣行為を「自己の雇用する労働者を、当該雇用関係の下に、かつ、他人の指揮命令を受けて、当該他人のために労働に従事させること」と定義している。そして同法は、「労働者派遣の役務の提供を受ける者は、派遣元事業主以外の労働者派遣事業を行う事業主から、労働者派遣の役務の提供を受けてはならない」と二重派遣を禁じている。これは、派遣の丸投げを防いで中間搾取をなくすための項目である。
もしA社やB社、C社の人間が、それぞれの企業の勤怠管理や指揮命令の下に勤務していれば、単なる業務委託であり労働者派遣法の出る幕はない。しかしそうではなく、X社の勤怠管理と指揮命令の下に勤務していると職安が判断すれば、A社からB社やC社への発注は二重派遣となる。実際に職安は、A社のX社に対するサービスは派遣であると認定したからこそ、労働者派遣法に基づいて警告を行ったわけだ。
問題はこうしたサービスの在り方が業界では当たり前のもので、ほかの企業も日常的に提供しているという点である。つまり業界全体が、常に違法状態にあるといってもよい。
ではなぜ、A社だけが職安に目を付けられたのか。実はA社は人材派遣大手のS社の子会社ということで、派遣事業者としての登録を行っている。これに対して同業他社は、自分たちの提供しているサービスが派遣ではなく業務請負としか認識していないのか、派遣事業者として登録している企業はほとんどない。登録がなければ職安の管轄外となり、検査の目が届いていないのだ。
A社は現在、職安に業界の現状を説明するなど交渉を行っているようだが、最悪の場合、登録を取り消される可能性もある。
■ITプロフェッショナルの実情に合わない労働者派遣法
この問題に関しては、そもそもIT関連の人材サービスや業務委託サービスを既存の法制度で取り締まっていいのかという疑問がわいてくる。
労働者派遣法が制定された当時、想定していた派遣サービスとは、中小企業や大企業の現場レベルが比較的短期の人手不足を穴埋めするために利用するようなものだったはずだ。仕事の内容も、アシスタント的な ものが中心になると考えていたに違いない。このため派遣される人の立場は、派遣元や派遣先と比較すると圧倒的に弱いとされ、法律上は相当に保護されることになっている。
しかし現在、IT業界で行われているサービスはこうした想定とは大きく異なる。多いときには100人を超える人間が派遣先に常駐し、個々の人材はスキルを備えたプロフェッショナルである。しかも、企業の命運を左右しかねない戦略システムの開発を任されている、というケースも決して珍しくはない。
インターネットの登場で企業の業務構造が変ぼうしつつあるが、その1つの側面はアウトソーシングの徹底活用である。システムや物流だけでなく、製造やマーケティング、財務、販売など、かつてなら競争力の源泉とされ社内で持つのが当たり前だった業務まで外部に出すようになっている。主体となる企業が手掛けるのは、商品コンセプトの企画とブランドの付与だけという例さえある。
もはや業務を遂行するのが正社員か契約社員か、社内の人間か社外の人間かなど、あまり意味を持たなくなってきている。こうした時代に、勤怠管理の方法うんぬんという基準で規制をかけるのは、労働者保護のメリットよりも業界の活力を失わせるというデメリットの方が大きいのではないだろうか。
※労働者派遣法＝労働者派遣事業の適正な運営の確保及び派遣労働者の就業条件の整備等に関する法律
Tuesday, February 01, 2005
Sunday, January 30, 2005
——幸存者游戏给出的12个启示——
——幸存者游戏给出的12个启示——
前不久，看了一部由美国哥伦比亚广播公司（CBS）制作的名为幸存者（Surviors）的电视游戏纪实片。该片讲述了一场“游戏”，16名来自美国各地的应招者被集中在南中国海的一片海岸丛林里，并且在与外界隔绝的情况下，进行一场为期39天的“幸存者游戏”。他们分成两组（TAGITRIBE和PAGONGTRIBE），这两组每3天进行一场团体比赛，胜方会得到豁免权或他们要求的物品，而负方将举行投票淘汰掉他们中间的一个组员，因此这种比赛又称豁免权比赛。比赛不停地进行下去，而淘汰也不停地进行下去，直到最终只剩下一个人的时候，这个人就是最后的获胜者，也就是“幸存者”，他将拿走100万美元的奖金。
显然，与其说这是“幸存者游戏”，还不如说是一场微型的“生存竞赛”，而游戏的举办者也正是要通过这场微型的“生存竞赛”，直观地向高度紧张和受压的现代人揭示深刻的团队竞争和个体生存的哲理。
好吧，下面让我们看看这场在塔吉族（TAGITRIBE，以下简称T族）和帕公族（PAGONGTRIBE，以下简称P族）之间展开的“幸存者游戏”是如何进行的，以及我们能获得什么启示。
T族的8名成员是：
Hatch,Richard，39岁，通讯顾问。
Wiglesworth,Kelly，女，23岁，水上救生员。
Boesch,Rudy，72岁，美国海军退伍军人。
Hawk,Susan，女，39岁，卡车司机。
Kenniff,Sean，31岁，神经科医生。
Been,Dirk，24岁，农场主兼牧师。
Stillman,Stacey，女，28岁，社团律师。
Christopher,Sonja，女，63岁，医疗志愿者。
P族的8名成员是：
Cordy,Gretchen，女，38岁，幼儿教师。
Buis,Greg，25岁，大学生。
Lewis,Jenna，女，23岁，模特。
Peterson,Gervase，31岁，篮球教练（黑人）。
Haskell,Colleen，女，24岁，大学生。
Klug,Joel，28岁，推销员。
Gray,Ramona，女，29岁，化学药剂师（黑人）。
Andersen,B.B.，64岁，房屋契约人（已退休）。
两族第一次豁免权竞赛是火炬运送比赛，比赛很简单，看哪个族最先把火炬从海上运送到岸边，结果P族胜利，T族失败。究其原因是那位63岁的医疗志愿者—Sonja，在比赛前就把腿磕伤了，不仅行动不便而且还要别人照顾，所以她在第一次族人委员会（以下简称：族会）时被淘汰。
第二次豁免权竞赛是食虫比赛。食虫，就是两族各派一名代表，看谁最先把两条约
10厘米长，3个手指粗的热带丛林肉虫吃下去（虽然有点恶心，但这绝对是纯天然的，绝对无毒）。对此，T族派出社团律师—Stacey，P族派出黑人篮球教练—Gervase，结果律师出色地完成了任务，篮球教练失败。T族胜利，P族被迫举行族会，淘汰了B.B，那位64岁的房屋契约人。之所以淘汰B.B，主要是他视周围的同伴如无物，一上岛就不经别人允许用别人的脸盆洗自己的衣服，并且说谎，于是游戏一开始，他就犯了众怒。
★启示1：在一个团队中，第一批被淘汰的通常是这样一些人，他们要么是有明显的缺陷，要么是刚开始就成了众人厌恶的说谎者。对于前者，明显缺陷使他根本不能适应今后艰苦的竞争，淘汰这样的人无论对他还是整个团队都是明智的和轻易的；对于后者，当游戏刚开始众人就知道他在说谎，无疑，说谎者必须离开。特别是如果你的年龄明显偏大，而又不能充分融入一个年轻的群体中。
两族第三次豁免权竞赛是伤员营救比赛。比赛时，一人模拟伤员，其它族人当营救队，营救队抬着伤员经过复杂的地形把伤员送到指定地点。结果没有任何悬念，拥有较多年轻人的P族获胜。结果T族举行族会淘汰了Stacey，原因是她对族人的抱怨和毁谤。
Stacey终日的抱怨极大干扰着整个T族的正常生活，尤其是公开表示Rudy太老，没有竞争力，应该早点“赶走”他；对于Susan，Stacey也公开表示不信任。后来的事实证明Stacey的判断是非常愚蠢和弱智的。总之，这样一个终日喋喋不休而又肆意诽谤族人的短视者，无疑是应该被淘汰的。
两族第四次豁免权竞赛是寻宝比赛。不用多解释，“寻宝”二字已经说明了一切，结果练达老道的T族获胜（T族拥有医生的细致、军人的严格、救生员的敏锐，比赛简直就是为他们设置的，而与此相反，P族则多是“愣头青”，所以结果是在情理之中的）。P族举行族会，淘汰了黑人化学药剂师—Ramona，原因也是众口一词的，Ramona明显地不合群，不仅公开声称“自己没有白人朋友，不喜欢白人学校”，而且在P族刚刚上岛的几天里，她借口身体不适而不愿和其它族人互相沟通，甚至很少聊天。
★启示2：在一个团队中，第二批被淘汰的人，通常是那些不愿与团队中的成员充分沟通和交流的人，由于大家不知道这些人的想法，所以对与这些“不合群”的人合作没有信心。反之，完全可以想见的是，如果你的做事能力差，但你愿意和其它团队成员充分沟通，你就有可能在与大家的沟通中“碰撞”出“灵感的火花”，从而为整个团队找到“好办法”，这样大家就知道你是有用的人，虽然可能做具体事不太行，但你的地位至少在初期是稳固的。
两族第五次豁免权竞赛是划船比赛。这次比赛要求一名族人划船，其余族人一边游泳，一边护送小船，看哪族最先到达终点。划船似乎对T族很有利，因为P族的Gervase不会游泳，所以他只能划船，而T族的人都会游泳，因而他们可以挑出一个最优秀的族人划船，最终T族选中了23岁的水上救生员—Kelly作为划船手。但事情的结果却出人意料，由于身为篮球教练的Gervase力气很大，而Kelly虽然是水上救生员，她的划船技巧显然很出色，但力量却比Gervase小很多，结果P族以较大的优势获胜。
晚上，T族召开族会一致投票给Dirk，那个身强力壮，却终日只知道躺在树杈间看圣经的农场主兼牧师。特别是，当T族人的草屋被风浪摧毁后，大家需要这个农场主提些建议并且有些行动，结果他却说，他是来游戏的，要充分享受生活，然后说是出海捕鱼，实际上却是躺在船上一边晒太阳，一边看他的圣经。对此族人的愤怒是明显的，而受过严格训练的72岁的美国海军退伍军人—Rudy，对这种人更是不能容忍。他对大家说了一句“名言”：我能想到的带圣经到这里来的唯一原因，那就是我需要手纸。
★启示3：当不合群的人被淘汰后，接下来就是那些有能力为团队工作而又不肯工作，终日懒散而妄图坐享其成的“鸡贼”分子。
跨越障碍比赛是幸存者游戏上半段的最后一次豁免权竞赛，T族的领军任务落在了年富力强的通讯顾问Richard身上。这次T族克服了族人年龄偏大以及岛上生存体力下降的困难，以微弱的优势战胜了P族的年轻人。最终，P族投票淘汰了那个虽然在射击比赛中创造了出色成绩，但却对同族女性表示出蔑视的推销员Joel。
★启示4：居功自傲、藐视同僚的人将是团队初期的最后一批被淘汰者。这种人认为自己有过出色的成绩，于是藐视同僚，把整个团队的竞赛看成是个人英雄的表演。显然，作为团队的竞赛，这种人在初期是有用的，是不可能被淘汰的，而当整个团队开始进一步发展的时候，这种人便会成为整个团队的桎梏。
接下来是游戏的第二个阶段，两族合并成一族，继续以三天为一个周期进行豁免权比赛，但在讲述第二阶段比赛前，通过总结前18天的情况，我们还可以得到两点启示。
经过18天的比赛，幸存者游戏已经从初期进入了中期，而划分这两个阶段的标志是真正的团队领袖（Team-Leader）的出现。
★启示5：一个公司初期和中期的发展，也是以真正的Team-Leader的出现来划分的。此前，团队的发展方向是由整个群体做出的，通常也会是公正的。而当Team-Leader出现后，团队的发展方向将会受到群体意见的影响，也会受到Team-Leader个人意见的左右，换言之，团队的发展将是这两个“分力”的“合力”。
一个优秀的Team-Leader，将是一个有“公心”的，时而能固执己见，力挽狂澜，时而又能因势利导，从善如流的“力学”高手。而你如果总是“因势利导”，就将被认为是缺乏魄力的“老好人”；而你如果总是固执己见，就将被认为是不能虚心纳谏的“偏执狂”；而你如果没有“公心”，甚至结党营私，即使你能“因势利导”，即使你能“从善如流”，那人们也会给你个准确的评价—阴谋家。
另一个有意义的启示是由那个31岁的黑人篮球教练Gervase引出的。他是个十分懒散的人，整天什么都不做，属于那种“吃嘛嘛不剩，干嘛嘛不成”的人，倒是终日里跟大家“甜言蜜语”的。我曾经认为他在越野比赛后就应该被淘汰，但我错了，他一直没被淘汰掉，倒是立过大功的Joel率先成了“替罪羊”。这说明了什么呢？
★启示6：在一个团队里总有一些不会做事，只会“耍嘴皮子”的“甜言蜜语”制造者，而且这些人的地位通常会比人们想象的稳固得多，或者说，一旦当整个团队出现问题时，这种人反而不会被淘汰。这种例子古今中外颇为多见。
幸存者游戏进入第二阶段后，两族合并成了一族，改名叫RATTANA族（RATTANATRIBE，以下简称R族），我们看看还剩了哪10人：
R族的10名成员是：
HatchRichard，39岁，通讯顾问。（原T族）
WiglesworthKelly，女，23岁，水上救生员。（原T族）
BoeschRudy，72岁，美国海军退伍军人。（原T族）
HawkSusan，女，39岁，卡车司机。（原T族）
KenniffSean，31岁，神经科医生。（原T族）
CordyGretchen，女，38岁，幼儿教师。（原P族）
BuisGreg，25岁，大学生。（原P族）
LewisJenna，女，23岁，模特。（原P族）
PetersonGervase，31岁，篮球教练。（原P族）
HaskellColleen，女，24岁，大学生。（原P族）
随着第一阶段比赛的结束，原来的两族已经各自产生了他们自己的Team-Leader。T族的Richard长期负责捕鱼，为大家提供食物，更重要的是别人数次尝试都没有捕到鱼，所以Richard占据了有利的位置，而且他年富力强，在越野赛中是领军人物。当然在好几次的族会中他都机智地回答了主持人的问题，这也为他赢得了人心。Richard还有个副手—卡车司机Susan，他俩经常一起讨论事情，族里的大事他俩大约都能cover。
不过Richard也有问题，他坦承自己是个同性恋者，而且平时经常喜欢裸体，虽然原来的T族人已经习惯了他的裸体，但这肯定会影响他在新族中的形象。
P族的Gretchen是众望所归的领袖，正是她出色的组织使T族在数次非豁免权竞赛中获胜，从而赢得了很多工具和食品。其实Gretchen的脱颖而出也是不难理解的，我们注
意到P族的年龄层次比较年轻，而且这些年轻人虽然充满活力，但尤其不善于管理自己和协调工作，这一点从P族赢得的比赛多是力量型的就可以看出，而身为幼儿园教师的
Gretchen，在教育和组织方面都很出色，从大家日常的接触中可以明显地感到P族的成员对她是拥护的。Gretchen的副手是Greg，他是大家公认的Gretchen最合适的后继者。
现在两族合并成立了一个R族，但从另一个角度看也是Richard率领的原T族和Gretchen率领的原P族之间展开了一场新的竞赛。那么，谁是最终的幸存者？谁将拿走那100万美元？
为了成为最终的幸存者，Richard和Susan开始商量联盟的事，他们联合了原T族的成员Kelly和Rudy，准备在进入游戏的最后阶段以前，通过联手投票的方式逐一淘汰掉
原P族的成员，然后只剩下他们四个再去争夺那100万美元。结果联盟出人意料地形成了，原T族的四人首先把目标对准了Gretchen，真是“擒贼先擒王”。而对此以Gretchen为首的原P族，也意识到了这个问题，但他们没有制订相应的对策。特别是Greg更是公开抵制任何结盟，他崇尚比赛的公正，最终Gretchen采取了稍等和先静观的态度，这或许是P族的第一个败招。
合并后，新的豁免权竞赛—水下憋气比赛开始了，最终是Greg获胜，他成为当晚族会中不能被投票淘汰的人。对于Greg获胜，Gretchen和原P族人都很高兴。但接下来“悲剧”发生了，当晚族会，Gretchen一人独得5票，被淘汰出局。当时不仅Gretchen自己，连所有原P族人都“傻眼了”。现在可以知道那句谚语了：“先下手为强，后下手遭殃”。
★启示7：当两个已经走过初创期，并开始步入发展期的团队合并时，双方会面临很多差异、分歧和碰撞，而当面对一个共同的竞争时，这种碰撞将尤为激烈，而且表现方式是多种多样的，甚至是不择手段的，而一种暗地里的，被称做“阴谋”的东西通常就在这个时候应运而生了。
在投票结果中，我们注意到Richard发起的联盟是“四人团”（Richard、Susan、Kelly和Rudy），而Gretchen却出人意料的得到了五票，那么，是谁投了这恶毒的第五票？
答案是：原T族成员，没参加“四人团”的31岁神经科医生Sean。应该说对于Sean准确的评价是“愚蠢的老好人”，他干活很用心和卖力，而且为了表示自己的公正，他
明确表示不参加任何联盟并公布了自己的投票策略：按照字母序依次投票（多么愚蠢，如果是这样干嘛还要来参加这种激烈的竞争呢？）。当天他恰好该投给Gretchen，于是
他就这样做了，可怜的Gretchen以半数得票而被淘汰。
说Sean愚蠢，是他的举动被人利用了，却还浑然不觉。Richard正是利用了Sean按照字母序投票的规律，而且当天恰好该投给Gretchen了，所以“借力打力”，最终“铲除”了劲敌。俗话说“聪明人同样的错误只犯一次，而蠢人却会犯多次”，Sean愚蠢的投票方式，后来再次被Richard利用来“铲除”对手，而当Sean开始意识到自己的危险时，他已经没有任何反击和自救的机会了，他被全票淘汰。
★启示8：在激烈的团队竞赛中，个人的生存只有两条道路：支持和反对，如果你想走第三条路，一定会失败。很多公司的内部斗争都被简称为“站队”，结果通常是如果你不站在我这一队里，你就是我的敌人，我不仅要防着你，而且迟早要“铲除”你。
其实对于P族来说，在他们意识到对手的联盟将有可能对他们造成严重的伤害时，他们并不是一点反击甚至防守的机会都没有，显然以Richard为首的原T族要先“铲除”Gretchen，这时如果P族不愿结盟，或者想先静待一下的话，他们至少可以通过故意让Gretchen赢得那次水下憋气比赛，来使Gretchen得到豁免权，这样Richard的阴谋不会马上得逞。
但令人遗憾的是：水下憋气比赛对女性来说确实有点难，即便P族人故意让着Gretchen，如果Gretchen表现不是十分出色也是无法得到豁免权。要知道即便抛开T族的女性和72岁高龄的Rudy，38岁的Gretchen与39岁Richard“单练”，只怕也没有多少胜算。这是一招“险棋”，但原P族的那帮“愣头青”既缺乏“敏锐的嗅觉”，更不可能想出这招“险棋”来应战，这一方面是因为最终只有一个人能拿走那100万美元，而Gretchen如果得到豁免权，另一名P族人就会离开，而每个人都想成为最终的“幸存者”；另一方面也是更重要的，“舍小救大”、“唇亡齿寒”是东方人的哲学，可以想见，如果P族是清一色的日本人，那么他们是会想到这招“险棋”的。
P族不可能“弄险”正如在西方世界永远不可能出现围棋的高手一样，其原因并不是在西方国家下围棋的人少，而是东、西方哲学上的差异决定的，而这种哲学上的差异直接影响了人们的方法论。所以当Gretchen错误地判断了形式，对于潜在的危机采取了待观的策略时，P族就已经开始走向失败了。
虽然不幸中的万幸是P族的2号人物Greg还在，P族还不是一盘散沙。但万幸中的不幸是，剩下的P族人对于T族的阴谋还没有十分的警觉并立刻采取具体行动。从后来的结果看，这是P族的第二个败招。毫无洞察力的篮球教练Gervase还在说什么应该联手淘汰掉对方的“老家伙”Rudy，全然不知对方的核心人物是Richard。而Rudy的年龄虽然大，但他受过严格军事训练，在团队生存经验方面远远胜过常人，虽然T族的核心是Richard和Susan，但Rudy早已成为T族仅次于他俩的中坚力量。
两族合并后的第二次豁免权赛是走迷宫比赛，结果“吃嘛嘛不剩，干嘛嘛不成”的Gervase获胜，但悲剧也从这一刻又开始了。当晚族会，P族的2号人物Greg被淘汰。
而愚蠢的Gervase到现在才知道自己以前的判断有多可笑，原来P族的三个人（Jenna，Gervase，Colleen）也才确信了对方的阴谋，并且决定也以联盟的方式对付Richard，但他们的反击为时已晚，原P族剩下的三个人已经无法抗击Richard力量强大的“四人团”了。
★启示9：在一个高度竞争的团队中，你必须有敏感的洞察力，并时刻警惕危险的出现，对于哪怕是潜在的危机，也必须有充分的估计并立即制订有效的对策。而如果你的动作慢了，或者犹豫了，你将面临危险，虽然也许你不会被马上淘汰，但这种危险将使你陷入被动，最终导致无法逆转的恶果。充分估计和快速应对，正符合孙子兵法的名言：“多算胜，少算负，而况于无算乎”。P族的不利境地正是估计不足，反应迟缓造成的。
两族合并后的第三次豁免权竞赛是绳索攀爬比赛，结果原P族的Colleen获胜，显然她当晚是安全的，于是联合了同族的Jenna和Gervase，准备一同投票给Richard，但只有三票，而Richard拥有“四人团”，于是她开始拉拢“四人团”中的Kelly，并许诺准备成立一个女性联盟，而且历数Richard的种种丑行，结果Colleen的游说有点奏效了，但狡猾的Kelly并没有明确地同意加入那个根本不存在的女性联盟，只是给了Colleen一个模棱两可的态度，显然Kelly的模棱两可既使她自己掌握了主动，又使Colleen的女性联盟计划落空了。
当晚族会奇怪的事情发生了，Richard得到了三票，但原P族的Jenna却得到了四票，于是原P族又少了一个族人，Richard则安全脱险。这次Richard之所以能脱险，全靠了那个按字母排序投票的蠢人Sean。按照Sean的字母排序投票，上次应该投给Gervase，但由于Gervase赢得了上次豁免权，所以被跳过，按他的逻辑，跳过的人将列入下一轮字母序，于是他把票投给了无辜的Jenna。Richard再次利用了Sean的字母序，以“借力打力”的手段“铲除”一个对手。
在接下来的一次豁免权竞赛中，他的老战友Rudy获胜，Richard的联盟轻易淘汰了Gervase。三天后，又一次豁免权竞赛，Richard获胜，最终族会毫无悬念地淘汰了
Colleen，至此原P族人被全部被淘汰出局，Richard密谋的“四人团”获全胜。而且进一步的主动权还掌握在他手上。现在新的豁免权竞赛的胜负对他来说已经不重要了，而且蠢人Sean已经没用了，是应该让他离开的时候了，于是愚蠢而可怜的Sean直到这时才有点醒悟，但他已经连挣扎一下的机会都没有了，他被“四人团”一脚踢开。最终原T族的四名族人：Richard、Susan、Kelly和Rudy胜利会师，迎来了整个游戏的最后竞争。
★启示10：在激烈竞争的团队中什么样的人将被最终留下来呢？“四人团”的全胜就是很好的例子：经验最丰富者被留下（Rudy）；最年轻者被留下（Kelly）；最机智而年富力强者被留下（Richard和Susan）。这是自然的选择，是符合正态分布的。
第三阶段的比赛是从四人中（Richard、Susan、Kelly、Rudy）再淘汰两人，最后剩下的两人进入决赛。为了能更清楚地了解最后的比赛，我们再来看看这剩下的四个原T族人：
Richard，男，39岁，通讯顾问。
Kelly，女，23岁，水上救生员。（此次比赛最年轻的参赛者）
Rudy，男，72岁，美国海军退伍军人。（此次比赛最年长的参赛者）
Susan，女，39岁，卡车司机。
随着Sean的出局，原来的“四人团”自然地消亡了。每个人开始想自己也想别人，而最终只有一个目的—夺得那100万美元。于是这四个人开始“各自为政”，其状态就象人们刚刚上岛时一样，每个人都各抒己见，阴谋消失了，比赛又有了公平的气息，这是一种轮回，实际上也是一种螺旋式的上升。正是在这种新的公平气氛中，新的豁免权竞赛—记忆力比赛开始了。对于记忆力比赛，我不用多解释了，现在比赛的结果最重要。
其实这场比赛的胜者很容易猜出来，因为年轻人的记忆力总是最好的，所以新的豁免权得主只能是年轻机智的水上救生员—Kelly。这让我想起了唯心主义哲学家们对造物主的经典的评价：造物主总是用它那无所不在而又无所不能的自然之手，以一种最简明的，而又是不可阻挡的方式推动着一切，最终让事物向着最自然、最符合逻辑的方向发展。
Kelly得到了豁免权，别人不能投票给她了，但她仍可以投票给别人，所以Richard、Susan、Rudy三人中必有一人出局。当晚的族会，卡车司机—Susan得到了三票。于是Richard、Rudy“幸存”了下来。
三天后，Kelly、Richard、Rudy三人迎来了整个游戏的最后一次豁免权竞赛。这是一场耐力比赛，最终，三人同时用手扶着一根豁免神像柱，看谁坚持的时间最长。这次，首先失败的是Richard，顽强的Rudy也没能坚持多久，最终，最年轻的参赛者Kelly再次赢得了这次豁免权，同时也是整个游戏的最后一次豁免权。
由于整个游戏只剩下三个人了，当晚的族会按要求改变了投票规则。只有得到豁免权的人可以投票，其他人只能等待命运的安排，换言之，当晚只有Kelly能投票且只有一票，Kelly投票给谁，谁就被淘汰。最终Kelly选择了Rudy，这位72岁的美国海军退伍军人终于不得不熄灭自己的火炬，并对主持人说：“我没想到我能走这么远，我已经很满足了”。请记住这次投票，这是后来人们议论的一个热点。
★启示11：在团队竞争中年轻人是最有优势的一个群体，他们冲劲十足，虽然经验欠缺，但年龄优势使他们有更多的机会成功。年轻是最有竞争力的因素，所以有人说：年轻就是美丽，年轻没有失败。
为期39天的比赛到了最后阶段，最终的“幸存者”将从年轻机智的Kelly和强壮有力的Richard中产生。想想伟大的塞伦盖蒂草原上的狮群吧！如果一个狮群已经有了一位狮王，而在这个狮群中有一个“年轻人”，它站出来要挑战狮王的地位。毫无疑问，这场“斗争”是在强壮有力和年轻机智间展开的。原来的狮王很可能战胜这只年轻的狮子，但年轻的狮子在今后不断的挑战中迟早会成为新狮王，这是自然的法则。
Richard，男，39岁，通讯顾问。
Kelly，女，23岁，水上救生员。（此次比赛最年轻的参赛者）
按照游戏的规则，这最终的较量将不再进行任何比赛，代之以将此前被淘汰的的七名族人请回，并组成一个“陪审团”，由这个七人陪审团投票选举，谁的票数多谁就是最终的幸存者。其实到现在为止，应该说Kelly和Richard都是获胜者，也都是幸存者，而谁能最终拿走那100万美元，只有祈求造物主了。这个七人陪审团是：
Rudy，男，72岁，美国海军退伍军人。（此次比赛最年长的参赛者）
Susan，女，39岁，卡车司机。
Sean，男，31岁，神经科医生。
Greg，男，25岁，大学生。
Jenna，女，23岁，模特。
Gervase，男，31岁，篮球教练（黑人）。
Colleen，女，24岁，大学生。
结果Kelly三票，Richard四票，最终年富力强，老谋深算的Richard获胜，成为了第一位“幸存者”，并获得了那100万美元的奖金。
对于这样的结果，很多人有不同的议论。有人说Richard是个阴谋家，他获胜实在不公平。有人说Kelly没能利用最后一次豁免权淘汰Richard是个错误，因为如果那次她投票淘汰了Richard，最后站在七人陪审团面前的将是她和Rudy。对于陪审团来说，无疑Kelly比Rudy更有吸引力，那时Kelly肯定能拿走那100万美元的奖金。但所有这些议论都已经不可能发生了，事实就是Richard获胜。
对此，我以为不能简单地讨论公平还是不公平，而应该从团队竞争的角度辨证地看待这个结果。Kelly固然朝气蓬勃，博闻强记，但Richard也年富力强，老谋深算。而且Richard在经验、计谋（也可以说是阴谋）方面确实胜过Kelly，所以一个年富力强而善于机谋的人成了最终的胜者，这样的结果是完全解释得通，完全合理的，因此不能说比赛不公平。
★启示12：很多竞争是只有冠军而没有亚军的，冠军是“幸存者”，而亚军甚至和早就被淘汰的人没有区别。在这种竞争中，最终的“幸存者”会是什么人呢？很好判定，这种人应该具有三个特点：年富力强、善于机谋、在一次最关键的竞争中有极好的“运气”。
个人在团队中生存的总结
☆做个诚实的人。
☆和团队的其它成员充分沟通，让别人了解你。
☆尽自己的力量为团队做事，尤其是在你比较擅长的方面。
☆取得成绩后可以适当表现，但不要过分张扬，更不要藐视他人。
☆虽然你不搞“阴谋”，但不等于“阴谋”不会找上你，所以你还必须保持高度的警惕，对潜在的危机有充分的估计，并且尽快制订出对策。
☆“站队”别站错了！“有志者”“站错了队”是不会被原谅的，而“小蚂蚁”“站错了队”是仍然会被接纳的。
☆当你开始实施你的“计划”时，别忘了祈求造物主在关键时刻给你好运！
前不久，看了一部由美国哥伦比亚广播公司（CBS）制作的名为幸存者（Surviors）的电视游戏纪实片。该片讲述了一场“游戏”，16名来自美国各地的应招者被集中在南中国海的一片海岸丛林里，并且在与外界隔绝的情况下，进行一场为期39天的“幸存者游戏”。他们分成两组（TAGITRIBE和PAGONGTRIBE），这两组每3天进行一场团体比赛，胜方会得到豁免权或他们要求的物品，而负方将举行投票淘汰掉他们中间的一个组员，因此这种比赛又称豁免权比赛。比赛不停地进行下去，而淘汰也不停地进行下去，直到最终只剩下一个人的时候，这个人就是最后的获胜者，也就是“幸存者”，他将拿走100万美元的奖金。
显然，与其说这是“幸存者游戏”，还不如说是一场微型的“生存竞赛”，而游戏的举办者也正是要通过这场微型的“生存竞赛”，直观地向高度紧张和受压的现代人揭示深刻的团队竞争和个体生存的哲理。
好吧，下面让我们看看这场在塔吉族（TAGITRIBE，以下简称T族）和帕公族（PAGONGTRIBE，以下简称P族）之间展开的“幸存者游戏”是如何进行的，以及我们能获得什么启示。
T族的8名成员是：
Hatch,Richard，39岁，通讯顾问。
Wiglesworth,Kelly，女，23岁，水上救生员。
Boesch,Rudy，72岁，美国海军退伍军人。
Hawk,Susan，女，39岁，卡车司机。
Kenniff,Sean，31岁，神经科医生。
Been,Dirk，24岁，农场主兼牧师。
Stillman,Stacey，女，28岁，社团律师。
Christopher,Sonja，女，63岁，医疗志愿者。
P族的8名成员是：
Cordy,Gretchen，女，38岁，幼儿教师。
Buis,Greg，25岁，大学生。
Lewis,Jenna，女，23岁，模特。
Peterson,Gervase，31岁，篮球教练（黑人）。
Haskell,Colleen，女，24岁，大学生。
Klug,Joel，28岁，推销员。
Gray,Ramona，女，29岁，化学药剂师（黑人）。
Andersen,B.B.，64岁，房屋契约人（已退休）。
两族第一次豁免权竞赛是火炬运送比赛，比赛很简单，看哪个族最先把火炬从海上运送到岸边，结果P族胜利，T族失败。究其原因是那位63岁的医疗志愿者—Sonja，在比赛前就把腿磕伤了，不仅行动不便而且还要别人照顾，所以她在第一次族人委员会（以下简称：族会）时被淘汰。
第二次豁免权竞赛是食虫比赛。食虫，就是两族各派一名代表，看谁最先把两条约
10厘米长，3个手指粗的热带丛林肉虫吃下去（虽然有点恶心，但这绝对是纯天然的，绝对无毒）。对此，T族派出社团律师—Stacey，P族派出黑人篮球教练—Gervase，结果律师出色地完成了任务，篮球教练失败。T族胜利，P族被迫举行族会，淘汰了B.B，那位64岁的房屋契约人。之所以淘汰B.B，主要是他视周围的同伴如无物，一上岛就不经别人允许用别人的脸盆洗自己的衣服，并且说谎，于是游戏一开始，他就犯了众怒。
★启示1：在一个团队中，第一批被淘汰的通常是这样一些人，他们要么是有明显的缺陷，要么是刚开始就成了众人厌恶的说谎者。对于前者，明显缺陷使他根本不能适应今后艰苦的竞争，淘汰这样的人无论对他还是整个团队都是明智的和轻易的；对于后者，当游戏刚开始众人就知道他在说谎，无疑，说谎者必须离开。特别是如果你的年龄明显偏大，而又不能充分融入一个年轻的群体中。
两族第三次豁免权竞赛是伤员营救比赛。比赛时，一人模拟伤员，其它族人当营救队，营救队抬着伤员经过复杂的地形把伤员送到指定地点。结果没有任何悬念，拥有较多年轻人的P族获胜。结果T族举行族会淘汰了Stacey，原因是她对族人的抱怨和毁谤。
Stacey终日的抱怨极大干扰着整个T族的正常生活，尤其是公开表示Rudy太老，没有竞争力，应该早点“赶走”他；对于Susan，Stacey也公开表示不信任。后来的事实证明Stacey的判断是非常愚蠢和弱智的。总之，这样一个终日喋喋不休而又肆意诽谤族人的短视者，无疑是应该被淘汰的。
两族第四次豁免权竞赛是寻宝比赛。不用多解释，“寻宝”二字已经说明了一切，结果练达老道的T族获胜（T族拥有医生的细致、军人的严格、救生员的敏锐，比赛简直就是为他们设置的，而与此相反，P族则多是“愣头青”，所以结果是在情理之中的）。P族举行族会，淘汰了黑人化学药剂师—Ramona，原因也是众口一词的，Ramona明显地不合群，不仅公开声称“自己没有白人朋友，不喜欢白人学校”，而且在P族刚刚上岛的几天里，她借口身体不适而不愿和其它族人互相沟通，甚至很少聊天。
★启示2：在一个团队中，第二批被淘汰的人，通常是那些不愿与团队中的成员充分沟通和交流的人，由于大家不知道这些人的想法，所以对与这些“不合群”的人合作没有信心。反之，完全可以想见的是，如果你的做事能力差，但你愿意和其它团队成员充分沟通，你就有可能在与大家的沟通中“碰撞”出“灵感的火花”，从而为整个团队找到“好办法”，这样大家就知道你是有用的人，虽然可能做具体事不太行，但你的地位至少在初期是稳固的。
两族第五次豁免权竞赛是划船比赛。这次比赛要求一名族人划船，其余族人一边游泳，一边护送小船，看哪族最先到达终点。划船似乎对T族很有利，因为P族的Gervase不会游泳，所以他只能划船，而T族的人都会游泳，因而他们可以挑出一个最优秀的族人划船，最终T族选中了23岁的水上救生员—Kelly作为划船手。但事情的结果却出人意料，由于身为篮球教练的Gervase力气很大，而Kelly虽然是水上救生员，她的划船技巧显然很出色，但力量却比Gervase小很多，结果P族以较大的优势获胜。
晚上，T族召开族会一致投票给Dirk，那个身强力壮，却终日只知道躺在树杈间看圣经的农场主兼牧师。特别是，当T族人的草屋被风浪摧毁后，大家需要这个农场主提些建议并且有些行动，结果他却说，他是来游戏的，要充分享受生活，然后说是出海捕鱼，实际上却是躺在船上一边晒太阳，一边看他的圣经。对此族人的愤怒是明显的，而受过严格训练的72岁的美国海军退伍军人—Rudy，对这种人更是不能容忍。他对大家说了一句“名言”：我能想到的带圣经到这里来的唯一原因，那就是我需要手纸。
★启示3：当不合群的人被淘汰后，接下来就是那些有能力为团队工作而又不肯工作，终日懒散而妄图坐享其成的“鸡贼”分子。
跨越障碍比赛是幸存者游戏上半段的最后一次豁免权竞赛，T族的领军任务落在了年富力强的通讯顾问Richard身上。这次T族克服了族人年龄偏大以及岛上生存体力下降的困难，以微弱的优势战胜了P族的年轻人。最终，P族投票淘汰了那个虽然在射击比赛中创造了出色成绩，但却对同族女性表示出蔑视的推销员Joel。
★启示4：居功自傲、藐视同僚的人将是团队初期的最后一批被淘汰者。这种人认为自己有过出色的成绩，于是藐视同僚，把整个团队的竞赛看成是个人英雄的表演。显然，作为团队的竞赛，这种人在初期是有用的，是不可能被淘汰的，而当整个团队开始进一步发展的时候，这种人便会成为整个团队的桎梏。
接下来是游戏的第二个阶段，两族合并成一族，继续以三天为一个周期进行豁免权比赛，但在讲述第二阶段比赛前，通过总结前18天的情况，我们还可以得到两点启示。
经过18天的比赛，幸存者游戏已经从初期进入了中期，而划分这两个阶段的标志是真正的团队领袖（Team-Leader）的出现。
★启示5：一个公司初期和中期的发展，也是以真正的Team-Leader的出现来划分的。此前，团队的发展方向是由整个群体做出的，通常也会是公正的。而当Team-Leader出现后，团队的发展方向将会受到群体意见的影响，也会受到Team-Leader个人意见的左右，换言之，团队的发展将是这两个“分力”的“合力”。
一个优秀的Team-Leader，将是一个有“公心”的，时而能固执己见，力挽狂澜，时而又能因势利导，从善如流的“力学”高手。而你如果总是“因势利导”，就将被认为是缺乏魄力的“老好人”；而你如果总是固执己见，就将被认为是不能虚心纳谏的“偏执狂”；而你如果没有“公心”，甚至结党营私，即使你能“因势利导”，即使你能“从善如流”，那人们也会给你个准确的评价—阴谋家。
另一个有意义的启示是由那个31岁的黑人篮球教练Gervase引出的。他是个十分懒散的人，整天什么都不做，属于那种“吃嘛嘛不剩，干嘛嘛不成”的人，倒是终日里跟大家“甜言蜜语”的。我曾经认为他在越野比赛后就应该被淘汰，但我错了，他一直没被淘汰掉，倒是立过大功的Joel率先成了“替罪羊”。这说明了什么呢？
★启示6：在一个团队里总有一些不会做事，只会“耍嘴皮子”的“甜言蜜语”制造者，而且这些人的地位通常会比人们想象的稳固得多，或者说，一旦当整个团队出现问题时，这种人反而不会被淘汰。这种例子古今中外颇为多见。
幸存者游戏进入第二阶段后，两族合并成了一族，改名叫RATTANA族（RATTANATRIBE，以下简称R族），我们看看还剩了哪10人：
R族的10名成员是：
HatchRichard，39岁，通讯顾问。（原T族）
WiglesworthKelly，女，23岁，水上救生员。（原T族）
BoeschRudy，72岁，美国海军退伍军人。（原T族）
HawkSusan，女，39岁，卡车司机。（原T族）
KenniffSean，31岁，神经科医生。（原T族）
CordyGretchen，女，38岁，幼儿教师。（原P族）
BuisGreg，25岁，大学生。（原P族）
LewisJenna，女，23岁，模特。（原P族）
PetersonGervase，31岁，篮球教练。（原P族）
HaskellColleen，女，24岁，大学生。（原P族）
随着第一阶段比赛的结束，原来的两族已经各自产生了他们自己的Team-Leader。T族的Richard长期负责捕鱼，为大家提供食物，更重要的是别人数次尝试都没有捕到鱼，所以Richard占据了有利的位置，而且他年富力强，在越野赛中是领军人物。当然在好几次的族会中他都机智地回答了主持人的问题，这也为他赢得了人心。Richard还有个副手—卡车司机Susan，他俩经常一起讨论事情，族里的大事他俩大约都能cover。
不过Richard也有问题，他坦承自己是个同性恋者，而且平时经常喜欢裸体，虽然原来的T族人已经习惯了他的裸体，但这肯定会影响他在新族中的形象。
P族的Gretchen是众望所归的领袖，正是她出色的组织使T族在数次非豁免权竞赛中获胜，从而赢得了很多工具和食品。其实Gretchen的脱颖而出也是不难理解的，我们注
意到P族的年龄层次比较年轻，而且这些年轻人虽然充满活力，但尤其不善于管理自己和协调工作，这一点从P族赢得的比赛多是力量型的就可以看出，而身为幼儿园教师的
Gretchen，在教育和组织方面都很出色，从大家日常的接触中可以明显地感到P族的成员对她是拥护的。Gretchen的副手是Greg，他是大家公认的Gretchen最合适的后继者。
现在两族合并成立了一个R族，但从另一个角度看也是Richard率领的原T族和Gretchen率领的原P族之间展开了一场新的竞赛。那么，谁是最终的幸存者？谁将拿走那100万美元？
为了成为最终的幸存者，Richard和Susan开始商量联盟的事，他们联合了原T族的成员Kelly和Rudy，准备在进入游戏的最后阶段以前，通过联手投票的方式逐一淘汰掉
原P族的成员，然后只剩下他们四个再去争夺那100万美元。结果联盟出人意料地形成了，原T族的四人首先把目标对准了Gretchen，真是“擒贼先擒王”。而对此以Gretchen为首的原P族，也意识到了这个问题，但他们没有制订相应的对策。特别是Greg更是公开抵制任何结盟，他崇尚比赛的公正，最终Gretchen采取了稍等和先静观的态度，这或许是P族的第一个败招。
合并后，新的豁免权竞赛—水下憋气比赛开始了，最终是Greg获胜，他成为当晚族会中不能被投票淘汰的人。对于Greg获胜，Gretchen和原P族人都很高兴。但接下来“悲剧”发生了，当晚族会，Gretchen一人独得5票，被淘汰出局。当时不仅Gretchen自己，连所有原P族人都“傻眼了”。现在可以知道那句谚语了：“先下手为强，后下手遭殃”。
★启示7：当两个已经走过初创期，并开始步入发展期的团队合并时，双方会面临很多差异、分歧和碰撞，而当面对一个共同的竞争时，这种碰撞将尤为激烈，而且表现方式是多种多样的，甚至是不择手段的，而一种暗地里的，被称做“阴谋”的东西通常就在这个时候应运而生了。
在投票结果中，我们注意到Richard发起的联盟是“四人团”（Richard、Susan、Kelly和Rudy），而Gretchen却出人意料的得到了五票，那么，是谁投了这恶毒的第五票？
答案是：原T族成员，没参加“四人团”的31岁神经科医生Sean。应该说对于Sean准确的评价是“愚蠢的老好人”，他干活很用心和卖力，而且为了表示自己的公正，他
明确表示不参加任何联盟并公布了自己的投票策略：按照字母序依次投票（多么愚蠢，如果是这样干嘛还要来参加这种激烈的竞争呢？）。当天他恰好该投给Gretchen，于是
他就这样做了，可怜的Gretchen以半数得票而被淘汰。
说Sean愚蠢，是他的举动被人利用了，却还浑然不觉。Richard正是利用了Sean按照字母序投票的规律，而且当天恰好该投给Gretchen了，所以“借力打力”，最终“铲除”了劲敌。俗话说“聪明人同样的错误只犯一次，而蠢人却会犯多次”，Sean愚蠢的投票方式，后来再次被Richard利用来“铲除”对手，而当Sean开始意识到自己的危险时，他已经没有任何反击和自救的机会了，他被全票淘汰。
★启示8：在激烈的团队竞赛中，个人的生存只有两条道路：支持和反对，如果你想走第三条路，一定会失败。很多公司的内部斗争都被简称为“站队”，结果通常是如果你不站在我这一队里，你就是我的敌人，我不仅要防着你，而且迟早要“铲除”你。
其实对于P族来说，在他们意识到对手的联盟将有可能对他们造成严重的伤害时，他们并不是一点反击甚至防守的机会都没有，显然以Richard为首的原T族要先“铲除”Gretchen，这时如果P族不愿结盟，或者想先静待一下的话，他们至少可以通过故意让Gretchen赢得那次水下憋气比赛，来使Gretchen得到豁免权，这样Richard的阴谋不会马上得逞。
但令人遗憾的是：水下憋气比赛对女性来说确实有点难，即便P族人故意让着Gretchen，如果Gretchen表现不是十分出色也是无法得到豁免权。要知道即便抛开T族的女性和72岁高龄的Rudy，38岁的Gretchen与39岁Richard“单练”，只怕也没有多少胜算。这是一招“险棋”，但原P族的那帮“愣头青”既缺乏“敏锐的嗅觉”，更不可能想出这招“险棋”来应战，这一方面是因为最终只有一个人能拿走那100万美元，而Gretchen如果得到豁免权，另一名P族人就会离开，而每个人都想成为最终的“幸存者”；另一方面也是更重要的，“舍小救大”、“唇亡齿寒”是东方人的哲学，可以想见，如果P族是清一色的日本人，那么他们是会想到这招“险棋”的。
P族不可能“弄险”正如在西方世界永远不可能出现围棋的高手一样，其原因并不是在西方国家下围棋的人少，而是东、西方哲学上的差异决定的，而这种哲学上的差异直接影响了人们的方法论。所以当Gretchen错误地判断了形式，对于潜在的危机采取了待观的策略时，P族就已经开始走向失败了。
虽然不幸中的万幸是P族的2号人物Greg还在，P族还不是一盘散沙。但万幸中的不幸是，剩下的P族人对于T族的阴谋还没有十分的警觉并立刻采取具体行动。从后来的结果看，这是P族的第二个败招。毫无洞察力的篮球教练Gervase还在说什么应该联手淘汰掉对方的“老家伙”Rudy，全然不知对方的核心人物是Richard。而Rudy的年龄虽然大，但他受过严格军事训练，在团队生存经验方面远远胜过常人，虽然T族的核心是Richard和Susan，但Rudy早已成为T族仅次于他俩的中坚力量。
两族合并后的第二次豁免权赛是走迷宫比赛，结果“吃嘛嘛不剩，干嘛嘛不成”的Gervase获胜，但悲剧也从这一刻又开始了。当晚族会，P族的2号人物Greg被淘汰。
而愚蠢的Gervase到现在才知道自己以前的判断有多可笑，原来P族的三个人（Jenna，Gervase，Colleen）也才确信了对方的阴谋，并且决定也以联盟的方式对付Richard，但他们的反击为时已晚，原P族剩下的三个人已经无法抗击Richard力量强大的“四人团”了。
★启示9：在一个高度竞争的团队中，你必须有敏感的洞察力，并时刻警惕危险的出现，对于哪怕是潜在的危机，也必须有充分的估计并立即制订有效的对策。而如果你的动作慢了，或者犹豫了，你将面临危险，虽然也许你不会被马上淘汰，但这种危险将使你陷入被动，最终导致无法逆转的恶果。充分估计和快速应对，正符合孙子兵法的名言：“多算胜，少算负，而况于无算乎”。P族的不利境地正是估计不足，反应迟缓造成的。
两族合并后的第三次豁免权竞赛是绳索攀爬比赛，结果原P族的Colleen获胜，显然她当晚是安全的，于是联合了同族的Jenna和Gervase，准备一同投票给Richard，但只有三票，而Richard拥有“四人团”，于是她开始拉拢“四人团”中的Kelly，并许诺准备成立一个女性联盟，而且历数Richard的种种丑行，结果Colleen的游说有点奏效了，但狡猾的Kelly并没有明确地同意加入那个根本不存在的女性联盟，只是给了Colleen一个模棱两可的态度，显然Kelly的模棱两可既使她自己掌握了主动，又使Colleen的女性联盟计划落空了。
当晚族会奇怪的事情发生了，Richard得到了三票，但原P族的Jenna却得到了四票，于是原P族又少了一个族人，Richard则安全脱险。这次Richard之所以能脱险，全靠了那个按字母排序投票的蠢人Sean。按照Sean的字母排序投票，上次应该投给Gervase，但由于Gervase赢得了上次豁免权，所以被跳过，按他的逻辑，跳过的人将列入下一轮字母序，于是他把票投给了无辜的Jenna。Richard再次利用了Sean的字母序，以“借力打力”的手段“铲除”一个对手。
在接下来的一次豁免权竞赛中，他的老战友Rudy获胜，Richard的联盟轻易淘汰了Gervase。三天后，又一次豁免权竞赛，Richard获胜，最终族会毫无悬念地淘汰了
Colleen，至此原P族人被全部被淘汰出局，Richard密谋的“四人团”获全胜。而且进一步的主动权还掌握在他手上。现在新的豁免权竞赛的胜负对他来说已经不重要了，而且蠢人Sean已经没用了，是应该让他离开的时候了，于是愚蠢而可怜的Sean直到这时才有点醒悟，但他已经连挣扎一下的机会都没有了，他被“四人团”一脚踢开。最终原T族的四名族人：Richard、Susan、Kelly和Rudy胜利会师，迎来了整个游戏的最后竞争。
★启示10：在激烈竞争的团队中什么样的人将被最终留下来呢？“四人团”的全胜就是很好的例子：经验最丰富者被留下（Rudy）；最年轻者被留下（Kelly）；最机智而年富力强者被留下（Richard和Susan）。这是自然的选择，是符合正态分布的。
第三阶段的比赛是从四人中（Richard、Susan、Kelly、Rudy）再淘汰两人，最后剩下的两人进入决赛。为了能更清楚地了解最后的比赛，我们再来看看这剩下的四个原T族人：
Richard，男，39岁，通讯顾问。
Kelly，女，23岁，水上救生员。（此次比赛最年轻的参赛者）
Rudy，男，72岁，美国海军退伍军人。（此次比赛最年长的参赛者）
Susan，女，39岁，卡车司机。
随着Sean的出局，原来的“四人团”自然地消亡了。每个人开始想自己也想别人，而最终只有一个目的—夺得那100万美元。于是这四个人开始“各自为政”，其状态就象人们刚刚上岛时一样，每个人都各抒己见，阴谋消失了，比赛又有了公平的气息，这是一种轮回，实际上也是一种螺旋式的上升。正是在这种新的公平气氛中，新的豁免权竞赛—记忆力比赛开始了。对于记忆力比赛，我不用多解释了，现在比赛的结果最重要。
其实这场比赛的胜者很容易猜出来，因为年轻人的记忆力总是最好的，所以新的豁免权得主只能是年轻机智的水上救生员—Kelly。这让我想起了唯心主义哲学家们对造物主的经典的评价：造物主总是用它那无所不在而又无所不能的自然之手，以一种最简明的，而又是不可阻挡的方式推动着一切，最终让事物向着最自然、最符合逻辑的方向发展。
Kelly得到了豁免权，别人不能投票给她了，但她仍可以投票给别人，所以Richard、Susan、Rudy三人中必有一人出局。当晚的族会，卡车司机—Susan得到了三票。于是Richard、Rudy“幸存”了下来。
三天后，Kelly、Richard、Rudy三人迎来了整个游戏的最后一次豁免权竞赛。这是一场耐力比赛，最终，三人同时用手扶着一根豁免神像柱，看谁坚持的时间最长。这次，首先失败的是Richard，顽强的Rudy也没能坚持多久，最终，最年轻的参赛者Kelly再次赢得了这次豁免权，同时也是整个游戏的最后一次豁免权。
由于整个游戏只剩下三个人了，当晚的族会按要求改变了投票规则。只有得到豁免权的人可以投票，其他人只能等待命运的安排，换言之，当晚只有Kelly能投票且只有一票，Kelly投票给谁，谁就被淘汰。最终Kelly选择了Rudy，这位72岁的美国海军退伍军人终于不得不熄灭自己的火炬，并对主持人说：“我没想到我能走这么远，我已经很满足了”。请记住这次投票，这是后来人们议论的一个热点。
★启示11：在团队竞争中年轻人是最有优势的一个群体，他们冲劲十足，虽然经验欠缺，但年龄优势使他们有更多的机会成功。年轻是最有竞争力的因素，所以有人说：年轻就是美丽，年轻没有失败。
为期39天的比赛到了最后阶段，最终的“幸存者”将从年轻机智的Kelly和强壮有力的Richard中产生。想想伟大的塞伦盖蒂草原上的狮群吧！如果一个狮群已经有了一位狮王，而在这个狮群中有一个“年轻人”，它站出来要挑战狮王的地位。毫无疑问，这场“斗争”是在强壮有力和年轻机智间展开的。原来的狮王很可能战胜这只年轻的狮子，但年轻的狮子在今后不断的挑战中迟早会成为新狮王，这是自然的法则。
Richard，男，39岁，通讯顾问。
Kelly，女，23岁，水上救生员。（此次比赛最年轻的参赛者）
按照游戏的规则，这最终的较量将不再进行任何比赛，代之以将此前被淘汰的的七名族人请回，并组成一个“陪审团”，由这个七人陪审团投票选举，谁的票数多谁就是最终的幸存者。其实到现在为止，应该说Kelly和Richard都是获胜者，也都是幸存者，而谁能最终拿走那100万美元，只有祈求造物主了。这个七人陪审团是：
Rudy，男，72岁，美国海军退伍军人。（此次比赛最年长的参赛者）
Susan，女，39岁，卡车司机。
Sean，男，31岁，神经科医生。
Greg，男，25岁，大学生。
Jenna，女，23岁，模特。
Gervase，男，31岁，篮球教练（黑人）。
Colleen，女，24岁，大学生。
结果Kelly三票，Richard四票，最终年富力强，老谋深算的Richard获胜，成为了第一位“幸存者”，并获得了那100万美元的奖金。
对于这样的结果，很多人有不同的议论。有人说Richard是个阴谋家，他获胜实在不公平。有人说Kelly没能利用最后一次豁免权淘汰Richard是个错误，因为如果那次她投票淘汰了Richard，最后站在七人陪审团面前的将是她和Rudy。对于陪审团来说，无疑Kelly比Rudy更有吸引力，那时Kelly肯定能拿走那100万美元的奖金。但所有这些议论都已经不可能发生了，事实就是Richard获胜。
对此，我以为不能简单地讨论公平还是不公平，而应该从团队竞争的角度辨证地看待这个结果。Kelly固然朝气蓬勃，博闻强记，但Richard也年富力强，老谋深算。而且Richard在经验、计谋（也可以说是阴谋）方面确实胜过Kelly，所以一个年富力强而善于机谋的人成了最终的胜者，这样的结果是完全解释得通，完全合理的，因此不能说比赛不公平。
★启示12：很多竞争是只有冠军而没有亚军的，冠军是“幸存者”，而亚军甚至和早就被淘汰的人没有区别。在这种竞争中，最终的“幸存者”会是什么人呢？很好判定，这种人应该具有三个特点：年富力强、善于机谋、在一次最关键的竞争中有极好的“运气”。
个人在团队中生存的总结
☆做个诚实的人。
☆和团队的其它成员充分沟通，让别人了解你。
☆尽自己的力量为团队做事，尤其是在你比较擅长的方面。
☆取得成绩后可以适当表现，但不要过分张扬，更不要藐视他人。
☆虽然你不搞“阴谋”，但不等于“阴谋”不会找上你，所以你还必须保持高度的警惕，对潜在的危机有充分的估计，并且尽快制订出对策。
☆“站队”别站错了！“有志者”“站错了队”是不会被原谅的，而“小蚂蚁”“站错了队”是仍然会被接纳的。
☆当你开始实施你的“计划”时，别忘了祈求造物主在关键时刻给你好运！
Saturday, January 22, 2005
第6回 日本市場攻略で一丸となる大連市と現地IT企業
第6回 日本市場攻略で一丸となる大連市と現地IT企業
http://jibun.atmarkit.co.jp/ljibun01/rensai/noeinjp06/noeinjp01.html
話は少しそれるかもしれないが、最後に、ある中国人のITベンチャー起業家のコメントを紹介しよう。
「われわれ中国大陸の企業は日本や欧米から案件を受注するために開発体制を整えるだけでなく、必死に日本語や英語を学んでいます。これはビジネスを円滑にするためには当然です。日本企業のエンジニアと仕事をするとき、中国語はおろか英語もろくに通用しないので結局、われわれが最初から最後まで日本語をしゃべってあげて仕事をするわけです」
現場レベルでも確かにそのとおりで、耳の痛い話である。筆者自身、中国、特に大連を訪問する際など、ビジネスレベルの英語と中国語を話すことができるにもかかわらず、それにもまして流ちょうな日本語を話す中国人担当者が次々と出てきて、結局すべてを日本語で打ち合わせてしまうことが多々ある。
すべて日本語で打ち合わせできる環境は楽であるし、快適だ。ただし、筆者が「日本語会談」を終えた後、いつも思う漠然とした不安がある。
「いったい、ビジネスパートナーである彼らはいつまで『日本人に合わせて』日本語を使ってくれるのだろうか」、ということだ。
http://jibun.atmarkit.co.jp/ljibun01/rensai/noeinjp06/noeinjp01.html
話は少しそれるかもしれないが、最後に、ある中国人のITベンチャー起業家のコメントを紹介しよう。
「われわれ中国大陸の企業は日本や欧米から案件を受注するために開発体制を整えるだけでなく、必死に日本語や英語を学んでいます。これはビジネスを円滑にするためには当然です。日本企業のエンジニアと仕事をするとき、中国語はおろか英語もろくに通用しないので結局、われわれが最初から最後まで日本語をしゃべってあげて仕事をするわけです」
現場レベルでも確かにそのとおりで、耳の痛い話である。筆者自身、中国、特に大連を訪問する際など、ビジネスレベルの英語と中国語を話すことができるにもかかわらず、それにもまして流ちょうな日本語を話す中国人担当者が次々と出てきて、結局すべてを日本語で打ち合わせてしまうことが多々ある。
すべて日本語で打ち合わせできる環境は楽であるし、快適だ。ただし、筆者が「日本語会談」を終えた後、いつも思う漠然とした不安がある。
「いったい、ビジネスパートナーである彼らはいつまで『日本人に合わせて』日本語を使ってくれるのだろうか」、ということだ。
Monday, January 17, 2005
いいかげんにして！ 日本企業（5）
オフショア開発時代の「開発コーディネータ」（5）
http://www.atmarkit.co.jp/fbiz/cstaff/serial/offshore/05/01.html
続・いいかげんにして！ 日本企業
─理不尽な態度
幸地 司
アイコーチ有限会社
2005/1/12
--------------------------------------------------------------------------------
前回は、オフショア開発を受託する中国側企業の視点に立った際の問題点として、「仕様まとめ能力不足」を例に挙げ、解決方法として仕様の分かりやすい伝達方法などを紹介した。今回は、そのほかの問題点として挙げられていた「仕様変更の段取りの悪さ」や「理不尽な条件の押し付け」などを説明し、対策を紹介する。（→記事要約へ）
--------------------------------------------------------------------------------
- 仕様変更の段取りの悪さ～無意識の不手際～
まず、中国企業から不満の声が多かった日本企業の「仕様変更の段取り悪さ」に関する意見を紹介します。
●「仕様変更を予測して、最初から対応しやすい設計にして欲しい」
上海の有名な観光地「豫園（ユエン）」
この問題は、中国オフショア開発最大の難関の1つです。中国企業の一部から要望のあった「仕様変更に対応しやすい設計」の実現は、オフショアうんぬんの話ではなく、システム開発における永遠の課題であるといえます。
いったいなぜ、中国企業からこのような不満が生まれるのでしょうか。まず、あらかじめ決められたルールに則って仕様変更を行ったにもかかわらず、トラブルが絶えないプロジェクトがあります。一方で、日本側の完全なミスにもかかわらず「後味の良い」終わり方をする仕様変更もあります。
走りながら徐々に要求仕様を決めていくやり方は、典型的な日本型開発アプローチです。ほかにも「責任分担が不明確」や「枝葉末節にこだわる」など、日本独自の商慣習が幅を利かせています。
最悪なのは、こうしたやり方に何の疑問を持たない日本企業が後を絶たないことです。オフショア開発でトラブルが発生したとき、日本型開発アプローチの弊害を知らない日本人担当者は、自分たちの段取りの悪さを棚に上げて、「品質が悪い」や「日本の常識が通用しない」などと中国企業を非難します。
●「仕様変更という名の仕様不備が多い」
「発注者の強みを活かして下請業者に無茶な要求を出す」
- PR -
あなたの周りでも、一度はこのような噂を聞いたことがあることでしょう。中国オフショア開発では、日本企業が指導的な役割を取ることが多いとされています。ところが、日本側が単純なミスを連発してしまうと、中国企業からの信頼を失いかねません。仕様変更自体が問題になることはあまりありません。肝心なのは、仕様変更後の対応です。
「仕様変更を自覚していない」
「トラブルはすべて中国側の責任」
このような態度では、中国企業の信頼をすぐに失ってしまいます。相互信頼に傷が入ってしまったら、オフショア開発プロジェクトは間違いなく失敗するでしょう。
●「仕様変更が発生しても、謝罪の言葉がない」
日本企業は、中国企業からの追加請求を過剰に反応する傾向があります。筆者は、これまで数多くのオフショア開発を経験してきましたが、日中両国が素直に「申し訳ありません」といえるプロジェクトでは、金銭面のトラブルが少なかったような気がします。やはり、仕様変更が発生したら日本側は潔く責任を認めましょう。
最近の中国企業は、仕様変更が多発する「日本的な商慣習」をかなり理解していますので、「仕様変更」による金銭トラブルはずいぶん減ってきました。これまでは、中国人の「どんなに非があっても絶対に責任を認めない」という態度ばかりが目立ってきました。これからのビジネスシーンでは、日本側により大人の対応が求められるようになります。
●「仕様変更に誠実に対応しても感謝されない」
中国企業が仕様変更に対応したら、どんな小さなことでも良いから感謝と称賛を与えましょう。筆者の経験則から、仕様変更を穏便に取りまとめるコツは、「責任の自覚」と「感謝の表明」を日本企業が心掛けることにあると感じています。「仕様変更は中国企業との信頼関係を強化するチャンス」と発想を転換できるようになればしめたものです。
日本側のモチベーションが低いプロジェクトでは、インフォーマルのコミュニケーションが極端に少なくなります。
「これくらいの仕様変更は対応して当然だ」
従来の国内開発では通用した考え方ですが、オフショア開発全盛の今こそ改める時期だといえます。
仕様変更が発生したら、あらかじめ計画した手順に従うしかありません。ところが、杓子定規の対応では済まされないのがオフショア開発の難点です。チェンジマネジメントの要点は、人間の感情マネジメントにほかなりません。要するに、相互の信頼関係があれば、多少の揉め事は担当者間で解決できます。わずかなお金を惜しんで、大事なプロジェクトを棒に振ることがないように、仕様変更には責任を持って対応してください。
担当者の技術力不足～コミュニケーション能力不足～
上海のレストランでの注文風景
日本企業がブリッジSEを選ぶ際は、日本語ができるか否か（中国語ができるか否か）に重点が置かれていて、その人間の能力にまで評価が及ばないことがあります。技術力がなくても、多少語学ができるだけでブリッジSEに任命される。このような安易な基準で選定されたブリッジSEが、オフショア開発の成功を左右する最大の要因となるのはいうまでもありません。
一方、技術力は高いのですが、管理能力やコミュニケーション能力に問題のある担当者がブリッジ役（コーディネータ）に就くケースも珍しくありません。この場合は悲惨です。管理体制が整わないばかりか、優秀な中国人技術者は無能な日本側のブリッジ役（コーディネータ）に愛想が尽きて離職することにもなりかねません。
次に、担当者の技術力不足に関する意見を紹介します。
●「詳細設計を理解していないので会話がなりたたない」
- PR -
このケースでは、2つのケースが考えられます。1つ目は、技術的に未熟な若手社員が中国ベンダとの窓口（ブリッジ役）を務めるケース。本来であれば、上司または先輩社員が若手社員のブリッジ業務を補佐する体制を取るべきですが、さまざまな理由から後輩にオフショア開発の重責を強います。「オフショア開発を支援する部署がない」「トップに言動不一致が見られる」「敗者復活が難しい」「中国企業に偏見を持つ」などが該当する職場でありがちな状況です。
2つ目は、担当者のコミュニケーション能力不足。担当者は詳細設計を十分に理解する技術力を持っているのですが、外国人技術者と会話する異文化コミュニケーション能力に欠ける状況です。
担当者のコミュニケーション能力が不足しているケースは、さらに2つのタイプに大別できます。1つは会話に感情が伴わないタイプ、もう1つは文章が下手で正しい意図が伝えられないタイプ。このようなコミュニケーションのギャップを解決するため、筆者の会社ではオフショア開発のコーディネート業務に特化した研修プログラムを提供しています。中国人と日本人の価値観の違いに着目し、ケーススタディを通して、コミュニケーション手段などを実践的に学ぶスタイルは、「従来の企業研修プログラムとは一味異なる」と評価されています。
●「技術的に困っても、有益なアドバイスが得られない」
このケースは、自社の技術力のなさを棚に上げて中国企業を批判するプロジェクトでよく見られます。また、「丸投げ体質」が染み付いた日本企業でも見られます。過去には、こんな事例がありました。
中国から「性能を保証するために、テストデータのバリエーションをどこまで増やすべきか」という内容の相談がありました。ところが、このときの日本側担当者は、「プロならば自力でテストすべき。それは私の責任ではない。私は中国企業の子守役ではない」と言い切って説明を断ろうとしました。
このようなケースは勘違いも甚だしいといえます。プロジェクトを成功に導くための努力を惜しんではいけません。
●「日本の単純ミスにもかかわらず、独り善がりな指摘がなされる」
日本人の価値観が邪魔をして、相手に迷惑をかける典型的なパターンです。「仕様書を見れば分かる」を根拠に独り善がりな指摘がなされますが、実際にはどこを参照しても正しい答えは載っていません。
日本側のミスで作業の手戻りが発生しても、「詳細設計書の23ページと画面設計書の85ページをよく読めば分かる（実際にはあいまいな内容なので誤解しても仕方ない）」などと主張して、責任を認めません。この手の人間に限って、相手側のミスを口汚く罵ります。
●「不可能な性能要求を強要される」
中国オフショア開発では、計画時に適切な数値目標を提示しなくてはいけません。そのことを意識するあまり、十分な根拠のないまま、無茶な目標が掲げられることもしばしば起きます。
例：
仕様書をまとめる時間がなかったので、十分な検証をしないまま「全機能、2秒以内のレスポンスとする」という性能要求を出した。ところが、設計を進めるうちに不可能な性能要求であることが判明した。
先述の場面でこそ、技術者の真の能力が問われます。繰り返しになりますが、技術者のモチベーションが高ければ、オフショア開発で発生するほとんどのトラブルは解決されます。努力は目標に向かっている限りストレスではありません。大義名分を持たない者がオフショア開発を任されるほど、報われないことはありません。オフショア開発の意義やビジョンを理解しないと、能力の半分も発揮できないと心得えてください。
- 理不尽な条件の押し付け～損をしたくない～
最後に、理不尽な条件の押し付けに関する意見を紹介します。
●「明らかな仕様変更なのに、仕様の詳細化だと主張する」
このような意見は、国内開発でもよくある話です。中国オフショア開発では予算が極端に少ないため、日本企業側も無理を承知で主張するケースがあります。
●「営業と設計者のいっていることがまるっきり異なる」
品質／納期に責任を持つ設計者と、金額に責任を持つ営業の立場が異なるため、話がまるで通じないことがあります。
日本側の設計者が何げなく発言した「了解した」や「すいません」が、中国人リーダーを経由して中国側営業（通常は総経理・幹部クラス）に伝わると、即座に金銭問題に発展するといった事例が過去に何度もありました。
●「計画や目標にないことを、その場の思いつきで口にする」
経験豊富なベテランになるほど、その場の思い付きでモノをいう傾向にあります。本人にとっては“適切な”状況判断かもしれませんが、残念ながら外国人技術者には理解されません。後からどうしても計画や目標を修正したいときは、時間が掛かるかもしれませんが、中国企業の幹部や総経理を通じて根気強く説明する方が安全です。
以上のような「言動不一致」や「理不尽な条件の押し付け」は、特にオフショア開発を始めたばかりの会社に共通して現れます。日本企業の甘えの構造に起因するため、発注者が意識を変えない限り、オフショア開発を受託する側の不満は一向に解消されません。オフショア開発では、ちょっとした不満が品質劣化や納期遅延に直結します。こうした悪循環から抜け出すためには、日本企業の1人1人が「日本型開発アプローチ」のあいまいさを自覚し、コミュニケーションのあり方を根本から見直すことから始めるしかありません。
オフショア開発で利益を得る鍵は、「スケールメリットの追求」と「長期的展望に立った投資」にほかなりません。これまでの対処療法的なトラブルシューティングをあらためて、「損をしないオフショア開発」から「Win－Winのオフショア開発」へと発想の転換を図りましょう。
http://www.atmarkit.co.jp/fbiz/cstaff/serial/offshore/05/01.html
続・いいかげんにして！ 日本企業
─理不尽な態度
幸地 司
アイコーチ有限会社
2005/1/12
--------------------------------------------------------------------------------
前回は、オフショア開発を受託する中国側企業の視点に立った際の問題点として、「仕様まとめ能力不足」を例に挙げ、解決方法として仕様の分かりやすい伝達方法などを紹介した。今回は、そのほかの問題点として挙げられていた「仕様変更の段取りの悪さ」や「理不尽な条件の押し付け」などを説明し、対策を紹介する。（→記事要約
--------------------------------------------------------------------------------
- 仕様変更の段取りの悪さ～無意識の不手際～
まず、中国企業から不満の声が多かった日本企業の「仕様変更の段取り悪さ」に関する意見を紹介します。
●「仕様変更を予測して、最初から対応しやすい設計にして欲しい」
上海の有名な観光地「豫園（ユエン）」
この問題は、中国オフショア開発最大の難関の1つです。中国企業の一部から要望のあった「仕様変更に対応しやすい設計」の実現は、オフショアうんぬんの話ではなく、システム開発における永遠の課題であるといえます。
いったいなぜ、中国企業からこのような不満が生まれるのでしょうか。まず、あらかじめ決められたルールに則って仕様変更を行ったにもかかわらず、トラブルが絶えないプロジェクトがあります。一方で、日本側の完全なミスにもかかわらず「後味の良い」終わり方をする仕様変更もあります。
走りながら徐々に要求仕様を決めていくやり方は、典型的な日本型開発アプローチです。ほかにも「責任分担が不明確」や「枝葉末節にこだわる」など、日本独自の商慣習が幅を利かせています。
最悪なのは、こうしたやり方に何の疑問を持たない日本企業が後を絶たないことです。オフショア開発でトラブルが発生したとき、日本型開発アプローチの弊害を知らない日本人担当者は、自分たちの段取りの悪さを棚に上げて、「品質が悪い」や「日本の常識が通用しない」などと中国企業を非難します。
●「仕様変更という名の仕様不備が多い」
「発注者の強みを活かして下請業者に無茶な要求を出す」
- PR -
あなたの周りでも、一度はこのような噂を聞いたことがあることでしょう。中国オフショア開発では、日本企業が指導的な役割を取ることが多いとされています。ところが、日本側が単純なミスを連発してしまうと、中国企業からの信頼を失いかねません。仕様変更自体が問題になることはあまりありません。肝心なのは、仕様変更後の対応です。
「仕様変更を自覚していない」
「トラブルはすべて中国側の責任」
このような態度では、中国企業の信頼をすぐに失ってしまいます。相互信頼に傷が入ってしまったら、オフショア開発プロジェクトは間違いなく失敗するでしょう。
●「仕様変更が発生しても、謝罪の言葉がない」
日本企業は、中国企業からの追加請求を過剰に反応する傾向があります。筆者は、これまで数多くのオフショア開発を経験してきましたが、日中両国が素直に「申し訳ありません」といえるプロジェクトでは、金銭面のトラブルが少なかったような気がします。やはり、仕様変更が発生したら日本側は潔く責任を認めましょう。
最近の中国企業は、仕様変更が多発する「日本的な商慣習」をかなり理解していますので、「仕様変更」による金銭トラブルはずいぶん減ってきました。これまでは、中国人の「どんなに非があっても絶対に責任を認めない」という態度ばかりが目立ってきました。これからのビジネスシーンでは、日本側により大人の対応が求められるようになります。
●「仕様変更に誠実に対応しても感謝されない」
中国企業が仕様変更に対応したら、どんな小さなことでも良いから感謝と称賛を与えましょう。筆者の経験則から、仕様変更を穏便に取りまとめるコツは、「責任の自覚」と「感謝の表明」を日本企業が心掛けることにあると感じています。「仕様変更は中国企業との信頼関係を強化するチャンス」と発想を転換できるようになればしめたものです。
日本側のモチベーションが低いプロジェクトでは、インフォーマルのコミュニケーションが極端に少なくなります。
「これくらいの仕様変更は対応して当然だ」
従来の国内開発では通用した考え方ですが、オフショア開発全盛の今こそ改める時期だといえます。
仕様変更が発生したら、あらかじめ計画した手順に従うしかありません。ところが、杓子定規の対応では済まされないのがオフショア開発の難点です。チェンジマネジメントの要点は、人間の感情マネジメントにほかなりません。要するに、相互の信頼関係があれば、多少の揉め事は担当者間で解決できます。わずかなお金を惜しんで、大事なプロジェクトを棒に振ることがないように、仕様変更には責任を持って対応してください。
担当者の技術力不足～コミュニケーション能力不足～
上海のレストランでの注文風景
日本企業がブリッジSEを選ぶ際は、日本語ができるか否か（中国語ができるか否か）に重点が置かれていて、その人間の能力にまで評価が及ばないことがあります。技術力がなくても、多少語学ができるだけでブリッジSEに任命される。このような安易な基準で選定されたブリッジSEが、オフショア開発の成功を左右する最大の要因となるのはいうまでもありません。
一方、技術力は高いのですが、管理能力やコミュニケーション能力に問題のある担当者がブリッジ役（コーディネータ）に就くケースも珍しくありません。この場合は悲惨です。管理体制が整わないばかりか、優秀な中国人技術者は無能な日本側のブリッジ役（コーディネータ）に愛想が尽きて離職することにもなりかねません。
次に、担当者の技術力不足に関する意見を紹介します。
●「詳細設計を理解していないので会話がなりたたない」
- PR -
このケースでは、2つのケースが考えられます。1つ目は、技術的に未熟な若手社員が中国ベンダとの窓口（ブリッジ役）を務めるケース。本来であれば、上司または先輩社員が若手社員のブリッジ業務を補佐する体制を取るべきですが、さまざまな理由から後輩にオフショア開発の重責を強います。「オフショア開発を支援する部署がない」「トップに言動不一致が見られる」「敗者復活が難しい」「中国企業に偏見を持つ」などが該当する職場でありがちな状況です。
2つ目は、担当者のコミュニケーション能力不足。担当者は詳細設計を十分に理解する技術力を持っているのですが、外国人技術者と会話する異文化コミュニケーション能力に欠ける状況です。
担当者のコミュニケーション能力が不足しているケースは、さらに2つのタイプに大別できます。1つは会話に感情が伴わないタイプ、もう1つは文章が下手で正しい意図が伝えられないタイプ。このようなコミュニケーションのギャップを解決するため、筆者の会社ではオフショア開発のコーディネート業務に特化した研修プログラムを提供しています。中国人と日本人の価値観の違いに着目し、ケーススタディを通して、コミュニケーション手段などを実践的に学ぶスタイルは、「従来の企業研修プログラムとは一味異なる」と評価されています。
●「技術的に困っても、有益なアドバイスが得られない」
このケースは、自社の技術力のなさを棚に上げて中国企業を批判するプロジェクトでよく見られます。また、「丸投げ体質」が染み付いた日本企業でも見られます。過去には、こんな事例がありました。
中国から「性能を保証するために、テストデータのバリエーションをどこまで増やすべきか」という内容の相談がありました。ところが、このときの日本側担当者は、「プロならば自力でテストすべき。それは私の責任ではない。私は中国企業の子守役ではない」と言い切って説明を断ろうとしました。
このようなケースは勘違いも甚だしいといえます。プロジェクトを成功に導くための努力を惜しんではいけません。
●「日本の単純ミスにもかかわらず、独り善がりな指摘がなされる」
日本人の価値観が邪魔をして、相手に迷惑をかける典型的なパターンです。「仕様書を見れば分かる」を根拠に独り善がりな指摘がなされますが、実際にはどこを参照しても正しい答えは載っていません。
日本側のミスで作業の手戻りが発生しても、「詳細設計書の23ページと画面設計書の85ページをよく読めば分かる（実際にはあいまいな内容なので誤解しても仕方ない）」などと主張して、責任を認めません。この手の人間に限って、相手側のミスを口汚く罵ります。
●「不可能な性能要求を強要される」
中国オフショア開発では、計画時に適切な数値目標を提示しなくてはいけません。そのことを意識するあまり、十分な根拠のないまま、無茶な目標が掲げられることもしばしば起きます。
例：
仕様書をまとめる時間がなかったので、十分な検証をしないまま「全機能、2秒以内のレスポンスとする」という性能要求を出した。ところが、設計を進めるうちに不可能な性能要求であることが判明した。
先述の場面でこそ、技術者の真の能力が問われます。繰り返しになりますが、技術者のモチベーションが高ければ、オフショア開発で発生するほとんどのトラブルは解決されます。努力は目標に向かっている限りストレスではありません。大義名分を持たない者がオフショア開発を任されるほど、報われないことはありません。オフショア開発の意義やビジョンを理解しないと、能力の半分も発揮できないと心得えてください。
- 理不尽な条件の押し付け～損をしたくない～
最後に、理不尽な条件の押し付けに関する意見を紹介します。
●「明らかな仕様変更なのに、仕様の詳細化だと主張する」
このような意見は、国内開発でもよくある話です。中国オフショア開発では予算が極端に少ないため、日本企業側も無理を承知で主張するケースがあります。
●「営業と設計者のいっていることがまるっきり異なる」
品質／納期に責任を持つ設計者と、金額に責任を持つ営業の立場が異なるため、話がまるで通じないことがあります。
日本側の設計者が何げなく発言した「了解した」や「すいません」が、中国人リーダーを経由して中国側営業（通常は総経理・幹部クラス）に伝わると、即座に金銭問題に発展するといった事例が過去に何度もありました。
●「計画や目標にないことを、その場の思いつきで口にする」
経験豊富なベテランになるほど、その場の思い付きでモノをいう傾向にあります。本人にとっては“適切な”状況判断かもしれませんが、残念ながら外国人技術者には理解されません。後からどうしても計画や目標を修正したいときは、時間が掛かるかもしれませんが、中国企業の幹部や総経理を通じて根気強く説明する方が安全です。
以上のような「言動不一致」や「理不尽な条件の押し付け」は、特にオフショア開発を始めたばかりの会社に共通して現れます。日本企業の甘えの構造に起因するため、発注者が意識を変えない限り、オフショア開発を受託する側の不満は一向に解消されません。オフショア開発では、ちょっとした不満が品質劣化や納期遅延に直結します。こうした悪循環から抜け出すためには、日本企業の1人1人が「日本型開発アプローチ」のあいまいさを自覚し、コミュニケーションのあり方を根本から見直すことから始めるしかありません。
オフショア開発で利益を得る鍵は、「スケールメリットの追求」と「長期的展望に立った投資」にほかなりません。これまでの対処療法的なトラブルシューティングをあらためて、「損をしないオフショア開発」から「Win－Winのオフショア開発」へと発想の転換を図りましょう。
Saturday, January 15, 2005
综述：埃森哲CEO乔福汉超越咨询
http://tech.sina.com.cn/it/m/2003-04-03/0946175430.shtml
综述：埃森哲CEO乔福汉超越咨询
--------------------------------------------------------------------------------
http://www.sina.com.cn 2003年04月03日 09:46 计算机世界网
《计算机世界》记者 李云杰
一年前，曾给无数家大公司做过咨询的埃森哲公司CEO乔福汉先生，亲身到中国市场进行调研，为自己执掌的公司做了一次重要的战略咨询。他当时得出的结论是：埃森哲可以在中国开展一些超越传统咨询的业务了。
2002年3月份，上海，埃森哲董事长兼CEO乔福汉(Joe W. Forehand)率领埃森哲全球领导层团队，其中包括50位最高级合伙人齐聚上海，共商在中国的业务战略和发展大计。
乔福汉说：“我们不仅仅是开一个会议，我们拜访了一些客户、更多地了解了中国。”
那次上海之行，乔福汉得出的“咨询”结论是：“中国已经发展得足够好，可以支持我们在这个市场上开始下一步高层次的发展，可以开展一些比传统咨询更多的业务了。”
同时，乔福汉发现了两个机会：第一个机会是埃森哲可以充分利用中国的技术专长和能力来创造软件工厂；第二个机会是埃森哲可以开始在中国市场上试着发展外包业务。
一年后，乔福汉再次访华，这两个机会都成为了现实。
2003年3月13日，大连，埃森哲全球信息技术中心成立。这是埃森哲在中国成立的首家信息技术中心，该中心将为客户提供应用软件开发与维护、系统集成、软件重新设计、业务流程外包等各类信息技术服务，目前主要服务于中国及日本、韩国市场的客户。
乔福汉专程到大连参加该中心的成立典礼。仅一天多的行程安排得很紧，乔福汉略显疲惫但脸上始终洋溢着笑容。乔福汉说：“在大连成立埃森哲信息技术中心，具有里程碑式的重要意义。无论对埃森哲公司、我们的员工还是广大客户来说，今天都是一个意义重大的喜庆节日。能够亲自参加这一盛典，我感到无比的荣幸和自豪。”
令乔福汉自豪的理由还有一个：埃森哲的外包业务在中国开了新篇。不久前，埃森哲在中国拿到了第一个外包合同，向一个国际性船务公司NOL提供在财务系统上的服务。
发现“外包”
中国人眼里的埃森哲是做咨询的，这没错，咨询业务是埃森哲的传统业务，其实外包服务也是埃森哲的主业之一，在国外发展多年。
埃森哲所做的第一个外包的项目是在十年前，当时英国石油把在北海钻油工程的会计部分外包给埃森哲。从此埃森哲涉足外包服务。
在乔福汉看来，外包服务是埃森哲传统咨询服务一个顺理成章的拓展和延伸。他说“现在的公司要成为世界级的公司，都希望自己的各个商业环节能够做到恪守一定的标准并且准确无误。有一些公司就把他们认为不是自己公司核心业务的业务环节转给我们，让我们来运作，应用我们手上的咨询特长和技术帮助他们节约成本。”
毫无疑问，企业的有些商业环节或业务可以外包，有些则是不能外包的。乔福汉认为这要求企业自身必须有一个清晰的判断：哪些业务是他们最擅长的和最有竞争力的。他举了戴尔电脑公司做例子:“毫无疑问,供应链和生产低成本的电脑是他们最拿手的商业环节。”他强调：“客户决定外包哪些环节是有自己特定标准的，这个标准就是外包的商业环节一定是其非核心商业环节和非战略业务环节，一定是一些其他公司可以替自己做，并且他们做的成本比自己做成本更低的商业环节。”
乔福汉很赞同GE公司前CEO杰克·韦尔奇曾经说过的话：“有些人注定做后台，有些人注定做前台。”
“竞争越来越激烈，当客户没有精力做到面面俱到的时候，他们会希望有人来帮助他们实现一些商业环节的运作，这为服务企业发展外包服务提供了机会。”正是看到这样的机会，乔福汉把外包服务确定为埃森哲经营新的增长点。
埃森哲的外包服务业务包括两块，一是财务、会计、人力资源管理等具体商业环节运作上的外包服务；另一块就是IT外包服务。
据乔福汉介绍，埃森哲在IT方面的外包服务基本上是和英国石油的项目同时开始的，“埃森哲最初的一些IT外包合同是在美国市场上拿到的。今天有一些大的公司，像戴尔、杜邦等一些大公司都将他们在信息技术方面的业务外包给我们做。”
尽管从咨询服务向外包服务扩展，埃森哲走得很早，但是乔福汉坦承：实际上在过去的二到三年的时间里，埃森哲才开始对外包服务有非常清晰的了解，才有能力来支持一个不断加快的外包服务的发展。
目前埃森哲在全球收入当中来自于外包收入的比例增长得非常快，从两年前的15%到现如今的30%。乔福汉希望在未来两年内把这个比例提高到50%。
在埃森哲的外包收入中有一半是来自于IT外包服务，一半就是来自于商业流程管理外包服务。而乔福汉特别强调的是，提供的商业流程管理外包服务，也是要有足够的技术来支持。
现在本土IT服务公司基本未进入外包服务市场，他们要进入外包服务领域需要做哪些准备？乔福汉先开了一个很职业的玩笑：“他们应该打电话给埃森哲，咨询一下怎么样做外包服务。”他接着说道，要提供非常有效的外包服务不是容易的事情，外包服务必须能够真正提供从最基层开始的服务，而这种服务是所要求的要远远超过技术的内涵。
掌舵转型
2001年底和2002年初，安然事件被炒得沸沸扬扬，由于与安达信以前的血缘关系，“埃森哲”这三个字也频见报端。
埃森哲的前身是安达信咨询，在1989年脱离安达信独立运作。到了20世纪90年代初，安达信又成立了一个做咨询的子公司，为了解决业务冲突，经过仲裁，2000年8月份，最终实现了从安达信全球结构当中剥离出来。2001年1月1日，公司的新名字“埃森哲”正式启用。
安然事件给安达信造成了毁灭性的打击，但对埃森哲却有有利的方面。受到安然事件影响，更多的公司们会寻找一家独立的咨询公司，而埃森哲恰恰是这样的身份。安然事件也导致很多咨询公司相继出现将审计与咨询这两块业务进行剥离的趋势。由此看来，埃森哲似乎有未卜先知般的运气。
1999年11月，埃森哲前首席执行官乔治·沙欣(George Shaheen)离开了埃森哲，去创办了一家互联网的创业公司(STARTUP)。在此“突然”情况下，乔福汉接任CEO的重任。
乔福汉是位“老埃森哲”，他于1972年加入埃森哲亚特兰大分公司，10年后成为公司合伙人。在担任CEO之前，乔福汉曾在埃森哲18个行业领域中的11个行业担任过领导职务。
乔治·沙欣被认为是咨询业“真正的领袖”之一，在沙欣的领导下，埃森哲公司曾连续5年取得了20%以上的增长，大大超过了业界平均水平。他的突然离任，不可避免地会有人对埃森哲公司的信心产生动摇。
在前任首席执行官耀眼的光环下，乔福汉能否担此重任？当时有人产生疑虑，这无形中也为乔福汉本人带来很大的压力。
然而乔福汉不负众望。为了掌控当时较为混乱的局面，乔福汉制定了一个“百日计划”，核心就是要制定一个快速反应的机制，以便能迅速地执行公司的战略，让公司在整个市场上迅速提升到更高的领导水平上。
在乔福汉掌舵公司以后，埃森哲经历了最艰难的转折：经历了仲裁，正式从安达信全球组织中剥离，并被迫更换公司的名称。
跨国大公司在业务蒸蒸日上之际更名，在世界范围内都不多见，乔福汉很清楚更名难免会对公司产生不利的影响。
新的名称“埃森哲”(Accenture)是在147天之内设计出来并在全球启用的。Accenture是一个合成词，由“注重(Accent)”和“未来(Future)”两个英文词组合而成，也许采用这个名称是为了让人们对公司的未来有信心。
让乔福汉欣慰的是，“埃森哲”这个品牌在比较短的时间内得到了公众的认可。而且，在乔福汉的主导下，埃森哲在2001年7月从原来合伙人式的公司变成了一个上市的公司。
为了使这家老牌咨询公司增添新的活力，乔福汉采取了很多创新的做法。
其中比较“标新立异”的举措是他改变了传统的获领报酬的方式，在公司运作当中提供一种以价值为基础的管理方法，实现叫做“补偿的价值”，就是“把项目的收费与客户取得的效益联系起来，为客户取得的经济效益越多，收入就会越高。”现在埃森哲的咨询顾问们已经不单纯按小时收费，公司收入的80%基于客户使用服务后的业绩以及定价收入。例如，埃森哲的多数服务都有定价，同时还考虑客户使用埃森哲的服务后赚了或节省了多少钱，或者服务得到了多少改进。
更名后的埃森哲正值全球经济走衰，企业越来越精打细算。在不确定的经济环境当中，每个公司都要面临挑战和重新选择，埃森哲公司也不能避免这样的选择。
事实上，企业在咨询方面的开销也越来越“吝啬”，咨询公司从咨询领域获得的收益也日趋紧张。
是专注传统的咨询业务，还是在咨询的基础上超越咨询？乔福汉果敢决定：选择后一条路线。埃森哲进行转型，由传统的咨询业务向IT、外包、风险投资等领域拓展。
点子+方案
面对不确定的经济环境，很多国际大公司掀起一股“减肥”风潮，而埃森哲却选择了一条扩张之路。目前埃森哲的传统咨询业务收入已下降到70%。那么埃森哲还是一家咨询公司吗？
乔福汉似乎不太在意埃森哲是什么。他说：“实际上现在客户对我们的要求越来越多，远远要比做一个调研、做一个报告要多得多，也许你会有一个好点子，但是这是不够的，有了好主意你要把它变成现实。当我们与客户会谈时，越来越多的客户告诉我们说，他们需要两样东西：好的点子和可以执行的商业解决方案。”
伴随着整个环境的变化，客户的需求也发上了变化，乔福汉认为埃森哲选择“管理咨询＋IT集成解决方案”这样的业务方向，就是为了适应客户需求的变化。
“我们有很多新鲜想法，而且有很强的技术力量，所以我们可以不仅为他们提供建议，还可以进一步为他们实施这些建议。”
“把创新变成现实”是埃森哲的一句广告语，埃森哲今年年初发布的一系列全球广告活动便以此为主题。乔福汉希望通过这样的广告语，向人们传达出埃森哲的全新经营理念：“好创意不在多少，关键在于如何付诸现实”。
埃森哲的业务分成三大块：一是管理咨询，给客户们带去最好的咨询建议；二是技术解决方案，这已经成为埃森哲的业务核心。这块还包含了很多合资公司和联盟企业，埃森者称之为联盟网络。第三块是外包业务，在这块业务里埃森哲承担起客户们的部分业务流程和技术方面的业务。在乔福汉看来，把这三块业务整合起来，能够提供给客户更好的服务。
但是在埃森哲的整个业务市场上，既存在像IBM的GLOBAL SERVICE、EDS和惠普这样强有力的IT服务厂商，也有像麦肯锡等这样老资格的专业咨询公司，相比这些竞争对手，埃森哲的优势在哪里？
“与IBM和EDS的咨询业务不一样的是，我们是一家独立的咨询机构，我们已经独立地运营了12年，建立了很强的管理咨询专长和技术咨询专长，不附属于一家技术公司。IBM和EDS这样的公司更偏重于技术咨询，我们比他们多了管理咨询这一块，我们可以为公司提供企业战略，人力资源策略等管理咨询方面的所有内容，而不是为了卖产品而提供硬件、软件等方面的咨询。在外包业务上，我们并不仅仅把客户的技术类工作拿出来运作，并不是简单地买下一个数据中心，然后帮客户运行。我们帮他们转变业务流程和业务模式，然后提供技术解决方案。”
“而麦肯锡这样的公司，更偏重于管理咨询，我们比他们多了技术咨询这一块。”
乔福汉强调，埃森哲的优势就是管理咨询和技术咨询的一种结合。
“在咨询服务中超越咨询，给客户带来实实在在的价值，而非简单的建议。”乔福汉认为这是埃森哲能够在非常严峻的市场环境中战胜竞争对手的主要原因。
从分化到融合
最近两年管理咨询行业发生了很大的变化：IBM收并了五大咨询公司中的普华永道，IBM、惠普等大公司都在向IT服务领域拓展，一些传统的咨询公司在向IT领域扩军。传统咨询与IT咨询呈现融合之势。
最近有消息称，因自身经营出现问题，全球第二大计算机服务提供商EDS也成为收购目标。据英国《金融时报》报道，微软和惠普都在与EDS保持亲密接触，它们都想与EDS达成合作甚至是收购意向，以强化自身IT服务的实力。
“整个行业是在经历一个不断整合的过程，”在乔福汉看来，未来这种一体化的整合会更为明显。
乔福汉发现，客户在咨询审核方面会越来越挑剔，他们会非常仔细地查看被选择的咨询公司的财务报表和经营状况。“在这样的背景下，小型的公司会面临更严峻的挑战，在未来一段时间里在全球咨询市场上会有更多的并购情况出现，小的咨询公司会被大的公司所购买。”
尽管整个行业处于“动荡”的过程中，很多大的咨询服务厂商的收入也在下滑，然而乔福汉对整个咨询服务市场的前景非常乐观。他说：“这是一个非常巨大的市场。如果把全球范围的管理咨询、技术咨询和外包服务算在一起的话，规模能达到5000亿美元。”
乔福汉认为，目前全球咨询市场的现状是“群雄割据”，大家都各自占有一块地盘。“在这样一个大市场当中，即便像IBM全球服务这样的公司也只不过占到了整个市场份额的7%～8%。”
“未来全世界范围内行业内比较强大的公司将会变得越来越强大。”这种整合在乔福汉看来是一种必然的趋势。
乔福汉认识到，要适应这样的竞争环境，需要公司有足够规模而且成为真正全球性的公司。他说：“经常我们会调来10个，甚至20个人来为一个客户工作，同时客户提出的要求也越来越专家化，因此就需要更多的专业技能，提供给客户所需要的专业化知识。而且更为重要的是现在我们的客户要求我们提供的是全方位的、各方面的服务。”埃森哲选择走从咨询管理到技术到外包这样的扩张路线，就是出于公司规模和适应竞争环境的考虑。
乔福汉在最近两次访华期间曾与中国一些国有企业和一些跨国公司在中国的高层管理人员进行过探讨，从中他看到了一个非常清晰的信号，那就是他们都有一个非常强烈的愿望，希望能够进一步提升他们的管理水平和能力。
对于中国的咨询服务市场，乔福汉认为还处于正在形成的过程中，但机会很多。乔福汉说，在中国咨询市场上还没有一个明显的领军企业，埃森哲在中国市场定下的目标就是要在中国咨询市场上建立起领导地位。
在乔福汉看来，中国市场上将会是两类公司共存。一类是在中国本地市场运作的本土公司，另外一类就是埃森哲这样的拥有全球化方法品牌、培训等的全球化公司。
问乔福汉是否知道几家本地咨询公司的名字？他说：“虽然李纲(埃森哲中国区总裁)跟我说过中国本土的几家咨询服务公司，但我记不清它们的名字了。”从乔福汉的回答中可以看出，本土的咨询公司的实力还没有引起他足够的注意。
制胜之道
“财富500强”企业中，基本上是制造业企业的天下，而像埃森哲这样的知识型企业是屈指可数的。
“我们公司永远不可能发展成为一个员工超过5000人的企业。”在20年前埃森哲公司内部就有一些人说过这样的话。已经在埃森哲工作30多年的乔福汉，对这句话记得很清楚。
他们当时之所以下这样的结论不是没有依据的，那就是“以人和知识为基础的企业，通常提供给每一个用户的产品都是不一样的，这种企业要发展成一个很大的企业是非常难以管理和实现的。”
这样的说法，也有经济学依据。按照经济学原理，边际成本会决定规模效益，而从事知识型业务的企业，边际成本很难呈下降的趋势。所以纯粹的知识型企业难以实现规模效益(乔福汉认为现在咨询行业开始呈现整合的趋势，实际上也有这方面的考虑)。
然而现在的埃森哲已经拥有75000人员、年营业收入116亿美元、业务遍布全球47个国家和地区的跨国大企业，并成功地打进“财富500强”。乔福汉的成功经验是什么？
乔福汉回答说：“要把经济学中存在的这种原理克服过来，的确需要有很多方面的因素整合在一起才能够使得我们有这个能力。”
他总结的成功经验有几点：“首先是在公司内部实现标准化方法论、工具以及培训的方法，做到这一点确实能够使得我们把知识型的产品做出来。第二点是，我们招了人才，积累了知识，同时更重要的是把知识传播开去，基于这样的考虑，我们建立了公司内部的全球资源配置的网络，通过这个网络可以将手上的信息和知识传播开去，可以方便不同地方的员工，可以利用这些分散的知识；第三点是要充分地利用在各个市场上本地合伙人的能力，因为哪些决定是对的，哪些决定是不对的，他们最有发言权。同时这样也能避免出现一个过度空心化的管理；最后一点就是向全世界范围内的员工来介绍这种商业的战略和策略是什么，使全球范围内的员工都能够对业务战略和决策有深刻的了解。”
乔福汉特别强调了埃森哲的资源全球调配的运作模式。“通过全球资源配置网络，我们能够非常清晰地定义出不同网络中心所独特的优势是什么，然后通过先进的通信设施，把这些资源进行合作配置。”
他举了一个例子。“比如一个美国的客户可能是由我们在美国的一个机构的200名员工来提供服务的，与此同时也有20多个从马尼拉或者从印度来的人员提供一些专业化、专门化的服务，比如说在软件设计方面的服务。”
“充分利用遍布于全球的资源，实现整个公司内部知识的共享，努力达成人员、技能与业务能力的最佳组合，埃森哲可以保证无论客户身处世界任何角落，都能为他们提供同样出色的服务。”
乔福汉认为这是埃森哲的一大核心竞争优势。
记者点评：中国的机会不仅在中国
“我们重视中国市场”几乎成为近一两年跨国公司老板访华时必说的一句话。
全球市场低迷、中国风景独好，中国已经成为全球商界“大佬”们眼中的“热土”。
仔细分析起来，你会发现他们所说的重视中国市场，大都包含了两层含义，一是在中国本土市场扩大业务规模；另一个就是利用中国市场的资源发展全球市场。
埃森哲进入中国已经到了第十个年头，乔福汉认为现在到了重视中国市场的时候了。乔福汉在此次访华中说：“现在在中国做咨询的时机非常好。我们对中国的投资一直非常认真地在进行着，我们决定在未来的时间里将我们在华的业务推向更高的、更新的水平，我们要确保在这里能够提供真正世界级的服务，能够有非常大的业务规模。”他为埃森哲在中国市场定下的宏伟目标是成为中国咨询市场的霸主。
然而实际情况是，目前中国咨询市场还处于起步阶段，据说目前各大咨询公司在中国市场挣钱都很困难，埃森哲在中国市场也还处于“耕耘”的阶段，估计希望在短时间内在中国市场取得很大的“收获”，不是容易做到的事情。在中国本土市场上挖潜的空间很大，机会很多，但却是“将来时”。
从这个角度看，与其说乔福汉们重视中国市场，不如说他们重视的是中国进入WTO背景下的中国市场对全球市场的重要作用。中国的机会不仅在中国市场内，更在于利用中国市场的资源服务于全球市场，这正是乔福汉们看到的更重要的一面。
埃森哲刚刚在大连成立的全球信息技术中心是埃森哲在中国的首家全球信息技术中心，它是服务于埃森哲全球市场的四个信息技术中心之一。它的主要使命是服务于包括中国在内的全球市场。比如该中心目前正在进行的第一个项目，就是为全球性的保险公司进行信息技术的开发。据介绍，埃森哲中国公司在上海承接的第一个外包客户，也是以上海为中心提供全球性的服务。在上面的项目中，中国本土的人才为埃森哲全球化的平台提供了资源。
埃森哲在中国的首家全球信息技术中心和埃森哲在中国市场拿下第一个外包大单，这两件事对埃森哲来说，的确具有里程碑式的意义。它不仅标志着埃森哲在中国市场的业务开了新篇，更重要的是，埃森哲开始把中国市场纳入其全球整体市场的重要一环，受益的不仅是埃森哲中国公司，而且是整个埃森哲公司。
中国加入WTO以后，越来越多的企业认识到中国市场的重要战略地位，除了拓展在中国本土市场上的业务以外，利用中国市场上的比较优势，把研发机构和生产工厂转移到中国，把中国市场打造成整个公司产业链的重要环节。
中国的机会不仅在中国，相信大多数跨国公司的CEO们都对此产生了共识。
综述：埃森哲CEO乔福汉超越咨询
--------------------------------------------------------------------------------
http://www.sina.com.cn 2003年04月03日 09:46 计算机世界网
《计算机世界》记者 李云杰
一年前，曾给无数家大公司做过咨询的埃森哲公司CEO乔福汉先生，亲身到中国市场进行调研，为自己执掌的公司做了一次重要的战略咨询。他当时得出的结论是：埃森哲可以在中国开展一些超越传统咨询的业务了。
2002年3月份，上海，埃森哲董事长兼CEO乔福汉(Joe W. Forehand)率领埃森哲全球领导层团队，其中包括50位最高级合伙人齐聚上海，共商在中国的业务战略和发展大计。
乔福汉说：“我们不仅仅是开一个会议，我们拜访了一些客户、更多地了解了中国。”
那次上海之行，乔福汉得出的“咨询”结论是：“中国已经发展得足够好，可以支持我们在这个市场上开始下一步高层次的发展，可以开展一些比传统咨询更多的业务了。”
同时，乔福汉发现了两个机会：第一个机会是埃森哲可以充分利用中国的技术专长和能力来创造软件工厂；第二个机会是埃森哲可以开始在中国市场上试着发展外包业务。
一年后，乔福汉再次访华，这两个机会都成为了现实。
2003年3月13日，大连，埃森哲全球信息技术中心成立。这是埃森哲在中国成立的首家信息技术中心，该中心将为客户提供应用软件开发与维护、系统集成、软件重新设计、业务流程外包等各类信息技术服务，目前主要服务于中国及日本、韩国市场的客户。
乔福汉专程到大连参加该中心的成立典礼。仅一天多的行程安排得很紧，乔福汉略显疲惫但脸上始终洋溢着笑容。乔福汉说：“在大连成立埃森哲信息技术中心，具有里程碑式的重要意义。无论对埃森哲公司、我们的员工还是广大客户来说，今天都是一个意义重大的喜庆节日。能够亲自参加这一盛典，我感到无比的荣幸和自豪。”
令乔福汉自豪的理由还有一个：埃森哲的外包业务在中国开了新篇。不久前，埃森哲在中国拿到了第一个外包合同，向一个国际性船务公司NOL提供在财务系统上的服务。
发现“外包”
中国人眼里的埃森哲是做咨询的，这没错，咨询业务是埃森哲的传统业务，其实外包服务也是埃森哲的主业之一，在国外发展多年。
埃森哲所做的第一个外包的项目是在十年前，当时英国石油把在北海钻油工程的会计部分外包给埃森哲。从此埃森哲涉足外包服务。
在乔福汉看来，外包服务是埃森哲传统咨询服务一个顺理成章的拓展和延伸。他说“现在的公司要成为世界级的公司，都希望自己的各个商业环节能够做到恪守一定的标准并且准确无误。有一些公司就把他们认为不是自己公司核心业务的业务环节转给我们，让我们来运作，应用我们手上的咨询特长和技术帮助他们节约成本。”
毫无疑问，企业的有些商业环节或业务可以外包，有些则是不能外包的。乔福汉认为这要求企业自身必须有一个清晰的判断：哪些业务是他们最擅长的和最有竞争力的。他举了戴尔电脑公司做例子:“毫无疑问,供应链和生产低成本的电脑是他们最拿手的商业环节。”他强调：“客户决定外包哪些环节是有自己特定标准的，这个标准就是外包的商业环节一定是其非核心商业环节和非战略业务环节，一定是一些其他公司可以替自己做，并且他们做的成本比自己做成本更低的商业环节。”
乔福汉很赞同GE公司前CEO杰克·韦尔奇曾经说过的话：“有些人注定做后台，有些人注定做前台。”
“竞争越来越激烈，当客户没有精力做到面面俱到的时候，他们会希望有人来帮助他们实现一些商业环节的运作，这为服务企业发展外包服务提供了机会。”正是看到这样的机会，乔福汉把外包服务确定为埃森哲经营新的增长点。
埃森哲的外包服务业务包括两块，一是财务、会计、人力资源管理等具体商业环节运作上的外包服务；另一块就是IT外包服务。
据乔福汉介绍，埃森哲在IT方面的外包服务基本上是和英国石油的项目同时开始的，“埃森哲最初的一些IT外包合同是在美国市场上拿到的。今天有一些大的公司，像戴尔、杜邦等一些大公司都将他们在信息技术方面的业务外包给我们做。”
尽管从咨询服务向外包服务扩展，埃森哲走得很早，但是乔福汉坦承：实际上在过去的二到三年的时间里，埃森哲才开始对外包服务有非常清晰的了解，才有能力来支持一个不断加快的外包服务的发展。
目前埃森哲在全球收入当中来自于外包收入的比例增长得非常快，从两年前的15%到现如今的30%。乔福汉希望在未来两年内把这个比例提高到50%。
在埃森哲的外包收入中有一半是来自于IT外包服务，一半就是来自于商业流程管理外包服务。而乔福汉特别强调的是，提供的商业流程管理外包服务，也是要有足够的技术来支持。
现在本土IT服务公司基本未进入外包服务市场，他们要进入外包服务领域需要做哪些准备？乔福汉先开了一个很职业的玩笑：“他们应该打电话给埃森哲，咨询一下怎么样做外包服务。”他接着说道，要提供非常有效的外包服务不是容易的事情，外包服务必须能够真正提供从最基层开始的服务，而这种服务是所要求的要远远超过技术的内涵。
掌舵转型
2001年底和2002年初，安然事件被炒得沸沸扬扬，由于与安达信以前的血缘关系，“埃森哲”这三个字也频见报端。
埃森哲的前身是安达信咨询，在1989年脱离安达信独立运作。到了20世纪90年代初，安达信又成立了一个做咨询的子公司，为了解决业务冲突，经过仲裁，2000年8月份，最终实现了从安达信全球结构当中剥离出来。2001年1月1日，公司的新名字“埃森哲”正式启用。
安然事件给安达信造成了毁灭性的打击，但对埃森哲却有有利的方面。受到安然事件影响，更多的公司们会寻找一家独立的咨询公司，而埃森哲恰恰是这样的身份。安然事件也导致很多咨询公司相继出现将审计与咨询这两块业务进行剥离的趋势。由此看来，埃森哲似乎有未卜先知般的运气。
1999年11月，埃森哲前首席执行官乔治·沙欣(George Shaheen)离开了埃森哲，去创办了一家互联网的创业公司(STARTUP)。在此“突然”情况下，乔福汉接任CEO的重任。
乔福汉是位“老埃森哲”，他于1972年加入埃森哲亚特兰大分公司，10年后成为公司合伙人。在担任CEO之前，乔福汉曾在埃森哲18个行业领域中的11个行业担任过领导职务。
乔治·沙欣被认为是咨询业“真正的领袖”之一，在沙欣的领导下，埃森哲公司曾连续5年取得了20%以上的增长，大大超过了业界平均水平。他的突然离任，不可避免地会有人对埃森哲公司的信心产生动摇。
在前任首席执行官耀眼的光环下，乔福汉能否担此重任？当时有人产生疑虑，这无形中也为乔福汉本人带来很大的压力。
然而乔福汉不负众望。为了掌控当时较为混乱的局面，乔福汉制定了一个“百日计划”，核心就是要制定一个快速反应的机制，以便能迅速地执行公司的战略，让公司在整个市场上迅速提升到更高的领导水平上。
在乔福汉掌舵公司以后，埃森哲经历了最艰难的转折：经历了仲裁，正式从安达信全球组织中剥离，并被迫更换公司的名称。
跨国大公司在业务蒸蒸日上之际更名，在世界范围内都不多见，乔福汉很清楚更名难免会对公司产生不利的影响。
新的名称“埃森哲”(Accenture)是在147天之内设计出来并在全球启用的。Accenture是一个合成词，由“注重(Accent)”和“未来(Future)”两个英文词组合而成，也许采用这个名称是为了让人们对公司的未来有信心。
让乔福汉欣慰的是，“埃森哲”这个品牌在比较短的时间内得到了公众的认可。而且，在乔福汉的主导下，埃森哲在2001年7月从原来合伙人式的公司变成了一个上市的公司。
为了使这家老牌咨询公司增添新的活力，乔福汉采取了很多创新的做法。
其中比较“标新立异”的举措是他改变了传统的获领报酬的方式，在公司运作当中提供一种以价值为基础的管理方法，实现叫做“补偿的价值”，就是“把项目的收费与客户取得的效益联系起来，为客户取得的经济效益越多，收入就会越高。”现在埃森哲的咨询顾问们已经不单纯按小时收费，公司收入的80%基于客户使用服务后的业绩以及定价收入。例如，埃森哲的多数服务都有定价，同时还考虑客户使用埃森哲的服务后赚了或节省了多少钱，或者服务得到了多少改进。
更名后的埃森哲正值全球经济走衰，企业越来越精打细算。在不确定的经济环境当中，每个公司都要面临挑战和重新选择，埃森哲公司也不能避免这样的选择。
事实上，企业在咨询方面的开销也越来越“吝啬”，咨询公司从咨询领域获得的收益也日趋紧张。
是专注传统的咨询业务，还是在咨询的基础上超越咨询？乔福汉果敢决定：选择后一条路线。埃森哲进行转型，由传统的咨询业务向IT、外包、风险投资等领域拓展。
点子+方案
面对不确定的经济环境，很多国际大公司掀起一股“减肥”风潮，而埃森哲却选择了一条扩张之路。目前埃森哲的传统咨询业务收入已下降到70%。那么埃森哲还是一家咨询公司吗？
乔福汉似乎不太在意埃森哲是什么。他说：“实际上现在客户对我们的要求越来越多，远远要比做一个调研、做一个报告要多得多，也许你会有一个好点子，但是这是不够的，有了好主意你要把它变成现实。当我们与客户会谈时，越来越多的客户告诉我们说，他们需要两样东西：好的点子和可以执行的商业解决方案。”
伴随着整个环境的变化，客户的需求也发上了变化，乔福汉认为埃森哲选择“管理咨询＋IT集成解决方案”这样的业务方向，就是为了适应客户需求的变化。
“我们有很多新鲜想法，而且有很强的技术力量，所以我们可以不仅为他们提供建议，还可以进一步为他们实施这些建议。”
“把创新变成现实”是埃森哲的一句广告语，埃森哲今年年初发布的一系列全球广告活动便以此为主题。乔福汉希望通过这样的广告语，向人们传达出埃森哲的全新经营理念：“好创意不在多少，关键在于如何付诸现实”。
埃森哲的业务分成三大块：一是管理咨询，给客户们带去最好的咨询建议；二是技术解决方案，这已经成为埃森哲的业务核心。这块还包含了很多合资公司和联盟企业，埃森者称之为联盟网络。第三块是外包业务，在这块业务里埃森哲承担起客户们的部分业务流程和技术方面的业务。在乔福汉看来，把这三块业务整合起来，能够提供给客户更好的服务。
但是在埃森哲的整个业务市场上，既存在像IBM的GLOBAL SERVICE、EDS和惠普这样强有力的IT服务厂商，也有像麦肯锡等这样老资格的专业咨询公司，相比这些竞争对手，埃森哲的优势在哪里？
“与IBM和EDS的咨询业务不一样的是，我们是一家独立的咨询机构，我们已经独立地运营了12年，建立了很强的管理咨询专长和技术咨询专长，不附属于一家技术公司。IBM和EDS这样的公司更偏重于技术咨询，我们比他们多了管理咨询这一块，我们可以为公司提供企业战略，人力资源策略等管理咨询方面的所有内容，而不是为了卖产品而提供硬件、软件等方面的咨询。在外包业务上，我们并不仅仅把客户的技术类工作拿出来运作，并不是简单地买下一个数据中心，然后帮客户运行。我们帮他们转变业务流程和业务模式，然后提供技术解决方案。”
“而麦肯锡这样的公司，更偏重于管理咨询，我们比他们多了技术咨询这一块。”
乔福汉强调，埃森哲的优势就是管理咨询和技术咨询的一种结合。
“在咨询服务中超越咨询，给客户带来实实在在的价值，而非简单的建议。”乔福汉认为这是埃森哲能够在非常严峻的市场环境中战胜竞争对手的主要原因。
从分化到融合
最近两年管理咨询行业发生了很大的变化：IBM收并了五大咨询公司中的普华永道，IBM、惠普等大公司都在向IT服务领域拓展，一些传统的咨询公司在向IT领域扩军。传统咨询与IT咨询呈现融合之势。
最近有消息称，因自身经营出现问题，全球第二大计算机服务提供商EDS也成为收购目标。据英国《金融时报》报道，微软和惠普都在与EDS保持亲密接触，它们都想与EDS达成合作甚至是收购意向，以强化自身IT服务的实力。
“整个行业是在经历一个不断整合的过程，”在乔福汉看来，未来这种一体化的整合会更为明显。
乔福汉发现，客户在咨询审核方面会越来越挑剔，他们会非常仔细地查看被选择的咨询公司的财务报表和经营状况。“在这样的背景下，小型的公司会面临更严峻的挑战，在未来一段时间里在全球咨询市场上会有更多的并购情况出现，小的咨询公司会被大的公司所购买。”
尽管整个行业处于“动荡”的过程中，很多大的咨询服务厂商的收入也在下滑，然而乔福汉对整个咨询服务市场的前景非常乐观。他说：“这是一个非常巨大的市场。如果把全球范围的管理咨询、技术咨询和外包服务算在一起的话，规模能达到5000亿美元。”
乔福汉认为，目前全球咨询市场的现状是“群雄割据”，大家都各自占有一块地盘。“在这样一个大市场当中，即便像IBM全球服务这样的公司也只不过占到了整个市场份额的7%～8%。”
“未来全世界范围内行业内比较强大的公司将会变得越来越强大。”这种整合在乔福汉看来是一种必然的趋势。
乔福汉认识到，要适应这样的竞争环境，需要公司有足够规模而且成为真正全球性的公司。他说：“经常我们会调来10个，甚至20个人来为一个客户工作，同时客户提出的要求也越来越专家化，因此就需要更多的专业技能，提供给客户所需要的专业化知识。而且更为重要的是现在我们的客户要求我们提供的是全方位的、各方面的服务。”埃森哲选择走从咨询管理到技术到外包这样的扩张路线，就是出于公司规模和适应竞争环境的考虑。
乔福汉在最近两次访华期间曾与中国一些国有企业和一些跨国公司在中国的高层管理人员进行过探讨，从中他看到了一个非常清晰的信号，那就是他们都有一个非常强烈的愿望，希望能够进一步提升他们的管理水平和能力。
对于中国的咨询服务市场，乔福汉认为还处于正在形成的过程中，但机会很多。乔福汉说，在中国咨询市场上还没有一个明显的领军企业，埃森哲在中国市场定下的目标就是要在中国咨询市场上建立起领导地位。
在乔福汉看来，中国市场上将会是两类公司共存。一类是在中国本地市场运作的本土公司，另外一类就是埃森哲这样的拥有全球化方法品牌、培训等的全球化公司。
问乔福汉是否知道几家本地咨询公司的名字？他说：“虽然李纲(埃森哲中国区总裁)跟我说过中国本土的几家咨询服务公司，但我记不清它们的名字了。”从乔福汉的回答中可以看出，本土的咨询公司的实力还没有引起他足够的注意。
制胜之道
“财富500强”企业中，基本上是制造业企业的天下，而像埃森哲这样的知识型企业是屈指可数的。
“我们公司永远不可能发展成为一个员工超过5000人的企业。”在20年前埃森哲公司内部就有一些人说过这样的话。已经在埃森哲工作30多年的乔福汉，对这句话记得很清楚。
他们当时之所以下这样的结论不是没有依据的，那就是“以人和知识为基础的企业，通常提供给每一个用户的产品都是不一样的，这种企业要发展成一个很大的企业是非常难以管理和实现的。”
这样的说法，也有经济学依据。按照经济学原理，边际成本会决定规模效益，而从事知识型业务的企业，边际成本很难呈下降的趋势。所以纯粹的知识型企业难以实现规模效益(乔福汉认为现在咨询行业开始呈现整合的趋势，实际上也有这方面的考虑)。
然而现在的埃森哲已经拥有75000人员、年营业收入116亿美元、业务遍布全球47个国家和地区的跨国大企业，并成功地打进“财富500强”。乔福汉的成功经验是什么？
乔福汉回答说：“要把经济学中存在的这种原理克服过来，的确需要有很多方面的因素整合在一起才能够使得我们有这个能力。”
他总结的成功经验有几点：“首先是在公司内部实现标准化方法论、工具以及培训的方法，做到这一点确实能够使得我们把知识型的产品做出来。第二点是，我们招了人才，积累了知识，同时更重要的是把知识传播开去，基于这样的考虑，我们建立了公司内部的全球资源配置的网络，通过这个网络可以将手上的信息和知识传播开去，可以方便不同地方的员工，可以利用这些分散的知识；第三点是要充分地利用在各个市场上本地合伙人的能力，因为哪些决定是对的，哪些决定是不对的，他们最有发言权。同时这样也能避免出现一个过度空心化的管理；最后一点就是向全世界范围内的员工来介绍这种商业的战略和策略是什么，使全球范围内的员工都能够对业务战略和决策有深刻的了解。”
乔福汉特别强调了埃森哲的资源全球调配的运作模式。“通过全球资源配置网络，我们能够非常清晰地定义出不同网络中心所独特的优势是什么，然后通过先进的通信设施，把这些资源进行合作配置。”
他举了一个例子。“比如一个美国的客户可能是由我们在美国的一个机构的200名员工来提供服务的，与此同时也有20多个从马尼拉或者从印度来的人员提供一些专业化、专门化的服务，比如说在软件设计方面的服务。”
“充分利用遍布于全球的资源，实现整个公司内部知识的共享，努力达成人员、技能与业务能力的最佳组合，埃森哲可以保证无论客户身处世界任何角落，都能为他们提供同样出色的服务。”
乔福汉认为这是埃森哲的一大核心竞争优势。
记者点评：中国的机会不仅在中国
“我们重视中国市场”几乎成为近一两年跨国公司老板访华时必说的一句话。
全球市场低迷、中国风景独好，中国已经成为全球商界“大佬”们眼中的“热土”。
仔细分析起来，你会发现他们所说的重视中国市场，大都包含了两层含义，一是在中国本土市场扩大业务规模；另一个就是利用中国市场的资源发展全球市场。
埃森哲进入中国已经到了第十个年头，乔福汉认为现在到了重视中国市场的时候了。乔福汉在此次访华中说：“现在在中国做咨询的时机非常好。我们对中国的投资一直非常认真地在进行着，我们决定在未来的时间里将我们在华的业务推向更高的、更新的水平，我们要确保在这里能够提供真正世界级的服务，能够有非常大的业务规模。”他为埃森哲在中国市场定下的宏伟目标是成为中国咨询市场的霸主。
然而实际情况是，目前中国咨询市场还处于起步阶段，据说目前各大咨询公司在中国市场挣钱都很困难，埃森哲在中国市场也还处于“耕耘”的阶段，估计希望在短时间内在中国市场取得很大的“收获”，不是容易做到的事情。在中国本土市场上挖潜的空间很大，机会很多，但却是“将来时”。
从这个角度看，与其说乔福汉们重视中国市场，不如说他们重视的是中国进入WTO背景下的中国市场对全球市场的重要作用。中国的机会不仅在中国市场内，更在于利用中国市场的资源服务于全球市场，这正是乔福汉们看到的更重要的一面。
埃森哲刚刚在大连成立的全球信息技术中心是埃森哲在中国的首家全球信息技术中心，它是服务于埃森哲全球市场的四个信息技术中心之一。它的主要使命是服务于包括中国在内的全球市场。比如该中心目前正在进行的第一个项目，就是为全球性的保险公司进行信息技术的开发。据介绍，埃森哲中国公司在上海承接的第一个外包客户，也是以上海为中心提供全球性的服务。在上面的项目中，中国本土的人才为埃森哲全球化的平台提供了资源。
埃森哲在中国的首家全球信息技术中心和埃森哲在中国市场拿下第一个外包大单，这两件事对埃森哲来说，的确具有里程碑式的意义。它不仅标志着埃森哲在中国市场的业务开了新篇，更重要的是，埃森哲开始把中国市场纳入其全球整体市场的重要一环，受益的不仅是埃森哲中国公司，而且是整个埃森哲公司。
中国加入WTO以后，越来越多的企业认识到中国市场的重要战略地位，除了拓展在中国本土市场上的业务以外，利用中国市场上的比较优势，把研发机构和生产工厂转移到中国，把中国市场打造成整个公司产业链的重要环节。
中国的机会不仅在中国，相信大多数跨国公司的CEO们都对此产生了共识。
埃森哲的启示
埃森哲的启示
汪赂勇
--------------------------------------------------------------------------------
裁员风波之后，大家不禁要问：什么样的人能够在裁员中做不倒翁？最近从裁员前线美国传来的消息是，具备专业知识和对传统产业有精深了解的人继续成为紧俏人才。如果说纳指跌掉的是泡沫，缩掉的是水份，在裁员中，企业往往最不足惜的是没有专业特长的人。可以想像，一个只具备热情，在.com风行时因为胆子大而进入互联网企业的人，肯定不可能在乱糟糟的互联网企业静心摸索出什么专业知识来——因为那个地方太吵了，业务计划几乎每天都要改。难怪有人在那样的公司非常忙却又有无所事事之感。
最近和埃森哲中国区总裁李纲进行一次交流，感觉这个公司活力四射，完全没有觉得他们在这场开始萧条的经济波动中受到什么影响。
有必要介绍一下埃森哲。如果提起安达信公司大家肯定都知道，世界上赫赫有名的会计审计公司。安达信咨询，大家也知道，似乎是安达信的子公司。安盛咨询，知道的人开始少了，安盛咨询只是安达信咨询改的名字。那么埃森哲——只是安盛咨询在2001年1月1日起用的新名字。从安达信咨询到安盛咨询到埃森哲的变化，表明他们已经完全独立，业务越来越壮大，新世纪启用了新名字。
2001年，埃森哲的营业额达到103亿美元，比1999年增长了10%，这意味着脱胎于安达信的埃森哲业绩远远超出了其原来的母体，也反映企业管理和信息咨询业的蓬勃发展。目前埃森哲全球有员工7.13万人，在全球46个国家设有分支公司。这样一个公司，按照中国人的传统观念，是一个完全“空手套白狼”的公司——因为他们从不制造什么硬件，也不生产什么软件，完全靠自己员工的大脑和嘴皮子挣钱。但是如果我们要说知识经济的话，这是最纯粹的知识经济——通过输出自己专业的经验和知识，来帮助企业实施各种改革，以达到企业的健康快速成长。如果告诉一个企业老总，能够让他的企业跑得更快更好，你说这种“灵丹妙药”会不会让人动心。埃森哲厉害就在于——他们不但让人动心，而且开始行动。刚进入中国时，埃森哲的客户名单中70%是外资企业，30％是国内企业；而到了2000年，则有70%是中国企业，30%是外资企业。应该说在中国搞“点子”输出的公司并不新鲜，也不少，可那多少有些连蒙带骗的味道。能够真正经营自己的知识，用金融、管理、信息技术等现代先进的管理运作经验和技术，来实施企业管理改造，这样的企业肯定市场非常广阔。
埃森哲是靠专业知识挣钱的公司，所以在动荡的经济环境中，它受到的影响会比较小。它的客户群体遍布全球，不在乎某一家企业的成败，只要有企业，他们就能够存在。另一个不倒的原因是：他们掌握了专业知识。专业知识往往是不会像股票一样很快贬值的。所以埃森哲的员工无论是在什么时候，都是非常抢手的“人才”。不可否认，网络大潮卷走了埃森哲一些人才，但是这些人才就算再回到管理咨询产业，同样有自己的价值，因为这些专业知识不会因为网站萧条而贬值。这时候我们来体会“知识就是力量”这句话，觉得它太对了。
汪赂勇
--------------------------------------------------------------------------------
裁员风波之后，大家不禁要问：什么样的人能够在裁员中做不倒翁？最近从裁员前线美国传来的消息是，具备专业知识和对传统产业有精深了解的人继续成为紧俏人才。如果说纳指跌掉的是泡沫，缩掉的是水份，在裁员中，企业往往最不足惜的是没有专业特长的人。可以想像，一个只具备热情，在.com风行时因为胆子大而进入互联网企业的人，肯定不可能在乱糟糟的互联网企业静心摸索出什么专业知识来——因为那个地方太吵了，业务计划几乎每天都要改。难怪有人在那样的公司非常忙却又有无所事事之感。
最近和埃森哲中国区总裁李纲进行一次交流，感觉这个公司活力四射，完全没有觉得他们在这场开始萧条的经济波动中受到什么影响。
有必要介绍一下埃森哲。如果提起安达信公司大家肯定都知道，世界上赫赫有名的会计审计公司。安达信咨询，大家也知道，似乎是安达信的子公司。安盛咨询，知道的人开始少了，安盛咨询只是安达信咨询改的名字。那么埃森哲——只是安盛咨询在2001年1月1日起用的新名字。从安达信咨询到安盛咨询到埃森哲的变化，表明他们已经完全独立，业务越来越壮大，新世纪启用了新名字。
2001年，埃森哲的营业额达到103亿美元，比1999年增长了10%，这意味着脱胎于安达信的埃森哲业绩远远超出了其原来的母体，也反映企业管理和信息咨询业的蓬勃发展。目前埃森哲全球有员工7.13万人，在全球46个国家设有分支公司。这样一个公司，按照中国人的传统观念，是一个完全“空手套白狼”的公司——因为他们从不制造什么硬件，也不生产什么软件，完全靠自己员工的大脑和嘴皮子挣钱。但是如果我们要说知识经济的话，这是最纯粹的知识经济——通过输出自己专业的经验和知识，来帮助企业实施各种改革，以达到企业的健康快速成长。如果告诉一个企业老总，能够让他的企业跑得更快更好，你说这种“灵丹妙药”会不会让人动心。埃森哲厉害就在于——他们不但让人动心，而且开始行动。刚进入中国时，埃森哲的客户名单中70%是外资企业，30％是国内企业；而到了2000年，则有70%是中国企业，30%是外资企业。应该说在中国搞“点子”输出的公司并不新鲜，也不少，可那多少有些连蒙带骗的味道。能够真正经营自己的知识，用金融、管理、信息技术等现代先进的管理运作经验和技术，来实施企业管理改造，这样的企业肯定市场非常广阔。
埃森哲是靠专业知识挣钱的公司，所以在动荡的经济环境中，它受到的影响会比较小。它的客户群体遍布全球，不在乎某一家企业的成败，只要有企业，他们就能够存在。另一个不倒的原因是：他们掌握了专业知识。专业知识往往是不会像股票一样很快贬值的。所以埃森哲的员工无论是在什么时候，都是非常抢手的“人才”。不可否认，网络大潮卷走了埃森哲一些人才，但是这些人才就算再回到管理咨询产业，同样有自己的价值，因为这些专业知识不会因为网站萧条而贬值。这时候我们来体会“知识就是力量”这句话，觉得它太对了。
Sunday, January 02, 2005
WorkStyles
個人尊重（Respect for individual）
■お互いをプロフェッショナルとして、尊敬しあう。
私たちは、いかなる職級でも、互いを肩書きでは呼びません。新人が代表取締役と話す時も「森さん」と呼びかけます。そしてパートナーがアナリストに話しかける時も、基本は「さん」付けです。お互いを常に対等な個人として尊び、その多様性を認め合うからこそ"Think straight, talk straight"な風土が生き、あらゆるレベルの人が、その時点の実力をのびのび発揮できる。私たちはそう考えます。
未来への提言
Client first
■顧客に真の価値を提供することが、最優先
多くの社員が「アクセンチュアらしさ」として挙げる言葉が、これです。入ってみて驚いたという社員も少なくありません。お客様の変革を実現するために、徹底的にコミットし、多くの困難を乗越えて実現できてこそ、「コンサルタント」という仕事の存在価値がある。それを不文律として共有し、目的に向かってチーム全力で解を探りつづける。これこそ、アクセンチュアがクライアントから高い評価を受け、初めての試みを実現しつづけてきた理由なのかもしれません。
Continuous learning
■研修制度の充実。教育研修に売上の最低5%を投資
■WEBでいつでも、どこでも先端の知識を学べるMyLearning.com
■個人と会社の成功のためのスキルアップ
■専門知識だけでなく、リーダーシップを養成
コンサルタントにゴールはありません。経済と技術が進化を続ける限り、新たな知識とスキルアップが求められます。
アクセンチュアには、そのための環境が整っています。社内はもちろん、海外や社外も含めた豊富で実戦的な研修プログラム。全世界の最新事例を集めたナレッジエクスチェンジ。直接問い合わせれば、世界中のコンサルタントが必ず返信をくれ、生の情報を教えてくれます。自分の意志さえあれば様々な情報が集まってくる場なのです。個人の成長が企業の成長に直結するビジネスだからこそ、この環境が企業力の源泉です。
Innovative company
Competitive compensation
■年齢・性別・人種など、あらゆる区別を行わない実力主義
■生み出す価値に相応した報酬制度
人一倍価値を発揮して働くからには、それに相応しい報酬を若いうちからしっかり手にしたい。そう考える人も多くいます。入社からの年次などにとらわれず、発揮した価値に応じた収入を得られる環境があります。ポスト不足も関係ありません。自分でビジネスを創る力があれば、パートナーの数に制限はないからです。今後は出資企業の上場益なども分配還元される予定です。
Commitment
■お客様との信頼関係を築くために欠かせない意識
コンサルタントとして、クライアント・プロジェクトの課題に、自ら責任持って深く関わっていくことを指します。企業変革には様々な困難がつきまといますが、どのような状況にあっても変革の実現を目指し、クライアントと二人三脚で徹底的にプロジェクトを成功に導くアクセンチュアの姿勢・責任感を象徴するものとして、日常でもよく使われる言葉です。
"Think straight, talk straight."
■「率直に考え、率直に語れ」。
価値創造を阻む、つまらない常識からは自由になること。コンサルティングという仕事をする以上、相手が上司であれ、クライアントであれ、正しいと思うこと、言わなければならないと思うことはきちんと伝えなければなりません。特に社内では、「議論をする時はみな同列」というのが当たり前。様々な視点からの意見を尊重し、対等・率直に話すからこそ、新しいアイデアが生まれてくる。転職してきた方々が一番驚く点でもあります。
社会貢献
Challenging & interesting work
■アイデアを具現化する過程でのチャレンジとその後の達成感
■具現化されたアイデアが社会に役立つ充実感
■最先端の事例やテクノロジーに常に携わる
■新しい知識やスキル習得の連続
同じ仕事も、同じ一日もない。人間が一人ひとり異なるように、すべてのプロジェクトに新しい課題があります。また、世界初、日本初の試みや、世の中を大きく変えるような案件が集まってくるのもアクセンチュアならではでしょう。驚くような大規模な案件も、専門性の高い少数精鋭のプロジェクトも多数あります。もちろん海外プロジェクトに参加するチャンスも。その時々の自分のキャリアに合った、刺激的な仕事が常に存在する。それがアクセンチュアの強みです。
Enjoyable working environment
■国境や国籍を越えたチームワーク
■職級、年齢の上下や性別の区別なく、率直に意見の言える社風
■キャリアアップをサポートするコミュニティやクラブ活動
■仕事とプライベートのメリハリを奨励
どうせ仕事をするならガムシャラにやれるくらい刺激的に、楽しく。働く喜びを提供するための環境作りをとても大切にしています。「人が足りない」で済ませるのではなく、「じゃあ、ドイツのオフィスから」と必要なプロを呼んでしまう。新人の正しい意見を聞いて、上司が自案を喜んで取り下げる。アクセンチュアへの転職者が驚くのはその合理的で納得度の高い環境です。
"Work hard, enjoy life."
■常に、全力で働き、自分の人生も目一杯楽しむ。
一個人として、家庭人としての生き方が充実してこそ、柔軟な発想や、大胆な挑戦も可能になると考えます。プロジェクト後の数週間の休暇など、リフレッシュの機会を奨励しているのもそのためです。また逆に、飛躍的に成長するためには、ある時期集中的に努力することも必要。そのメリハリが豊かなキャリアと選択肢を可能にすると考えています。個性的なプライベート･ライフを充実させている社員がたくさんいます。
Teamwork
ワークスタイル
WORKSTYLE キーワード
Teamwork
■コンサルタントこそ、仕事はすべてチームワーク。
本当の企業変革を企画し、実現まで導くためには、異なる専門性を持ったコンサルタントや、共にプロジェクトを推進するクライアント企業の方々と、ひとつの目標に向かって力を合わせることが必要です。そこには、だからこそ生み出せる革新があり、価値があります。この仕事の醍醐味はそこにある！と断言するコンサルタントはたくさんいます。
Professional development
■成長しつづけることが、コンサルタントの条件
コンサルタントは常に環境の変化に合わせ成長を続けなければなりません。そして、年次や経験量ではなく、発揮した価値で常に評価され続けます。一見厳しいですが、理不尽な制度や既得権益に邪魔されず、誰もが平等に成功を目指せる環境がここにはあります。ポスト争いではない、正しい実力主義。社長を含めすべての社員が自分の能力についての評価を常に明確に受け、次の目標に向かって努力し続ける風土が息づいているのです。
がむしゃら【我武者羅】
派生語 がむしゃらな(に) reckless(ly)
あまのじゃく【天の邪鬼】
22歳。
就職先にこだわりはなかった。銀行、住宅メーカー、情報関係の出版社、消防士の試験まで受けた。どこも面白そうだったけれど、どこも決め手に欠けた。就職活動のシーズンも終わりに近づいた頃、アクセンチュアのセミナーがあった。そこに行くまで、コンサルタントにはどこか人間味に欠けた冷たいイメージを持っていた。でも、それはまったくの誤解だった。セミナーでも個別面談でも、語りかけてくるアクセンチュアの社員たちは、みんな情熱的で熱かった。彼らの目は、風が吹けば必ず集まってくるウィンドサーファーたちにどこか似ているような気がした。受け身ではなく、自発的にやれるような仕事がしたい。そう思っていた僕にとって、アクセンチュアは最高の場であるように思えた。
25歳。
入社以来、クライアント企業の情報システム部門の仕事に携わることが多い。とても充実した5年間だったけれど、一度だけ会社を辞めようかなと思ったことがある。上司にさりげなく相談したら、僕の気持ちを見透かすように言われた。「おまえは、アクセンチュアでできることをやったのか？」はっとした。その頃の自分は、わがままだった。やりたい仕事ができないと焦り、それを環境や誰かのせいにしていたのだと思う。自発的に働きたくてアクセンチュアに入ったのに、なんのことはない受け身で仕事をしていたのだ。上司の一言で、意識が変わった。与えられた仕事だけでなく、自分から働きかけるようになった。働きかければチャンスはやってくる。コアコンピタンスがないこと。それが僕の強みなんじゃないかと思っている。僕はあらゆることに興味が持てる。環境が変わっても全然苦にならないし、目標に向う瞬発力とスピードにはちょっと自信がある。マネジャーになった今も、「市川をつっこめば、なんとかなる」、と頼られる存在であり続けたい。
■お互いをプロフェッショナルとして、尊敬しあう。
私たちは、いかなる職級でも、互いを肩書きでは呼びません。新人が代表取締役と話す時も「森さん」と呼びかけます。そしてパートナーがアナリストに話しかける時も、基本は「さん」付けです。お互いを常に対等な個人として尊び、その多様性を認め合うからこそ"Think straight, talk straight"な風土が生き、あらゆるレベルの人が、その時点の実力をのびのび発揮できる。私たちはそう考えます。
未来への提言
Client first
■顧客に真の価値を提供することが、最優先
多くの社員が「アクセンチュアらしさ」として挙げる言葉が、これです。入ってみて驚いたという社員も少なくありません。お客様の変革を実現するために、徹底的にコミットし、多くの困難を乗越えて実現できてこそ、「コンサルタント」という仕事の存在価値がある。それを不文律として共有し、目的に向かってチーム全力で解を探りつづける。これこそ、アクセンチュアがクライアントから高い評価を受け、初めての試みを実現しつづけてきた理由なのかもしれません。
Continuous learning
■研修制度の充実。教育研修に売上の最低5%を投資
■WEBでいつでも、どこでも先端の知識を学べるMyLearning.com
■個人と会社の成功のためのスキルアップ
■専門知識だけでなく、リーダーシップを養成
コンサルタントにゴールはありません。経済と技術が進化を続ける限り、新たな知識とスキルアップが求められます。
アクセンチュアには、そのための環境が整っています。社内はもちろん、海外や社外も含めた豊富で実戦的な研修プログラム。全世界の最新事例を集めたナレッジエクスチェンジ。直接問い合わせれば、世界中のコンサルタントが必ず返信をくれ、生の情報を教えてくれます。自分の意志さえあれば様々な情報が集まってくる場なのです。個人の成長が企業の成長に直結するビジネスだからこそ、この環境が企業力の源泉です。
Innovative company
Competitive compensation
■年齢・性別・人種など、あらゆる区別を行わない実力主義
■生み出す価値に相応した報酬制度
人一倍価値を発揮して働くからには、それに相応しい報酬を若いうちからしっかり手にしたい。そう考える人も多くいます。入社からの年次などにとらわれず、発揮した価値に応じた収入を得られる環境があります。ポスト不足も関係ありません。自分でビジネスを創る力があれば、パートナーの数に制限はないからです。今後は出資企業の上場益なども分配還元される予定です。
Commitment
■お客様との信頼関係を築くために欠かせない意識
コンサルタントとして、クライアント・プロジェクトの課題に、自ら責任持って深く関わっていくことを指します。企業変革には様々な困難がつきまといますが、どのような状況にあっても変革の実現を目指し、クライアントと二人三脚で徹底的にプロジェクトを成功に導くアクセンチュアの姿勢・責任感を象徴するものとして、日常でもよく使われる言葉です。
"Think straight, talk straight."
■「率直に考え、率直に語れ」。
価値創造を阻む、つまらない常識からは自由になること。コンサルティングという仕事をする以上、相手が上司であれ、クライアントであれ、正しいと思うこと、言わなければならないと思うことはきちんと伝えなければなりません。特に社内では、「議論をする時はみな同列」というのが当たり前。様々な視点からの意見を尊重し、対等・率直に話すからこそ、新しいアイデアが生まれてくる。転職してきた方々が一番驚く点でもあります。
社会貢献
Challenging & interesting work
■アイデアを具現化する過程でのチャレンジとその後の達成感
■具現化されたアイデアが社会に役立つ充実感
■最先端の事例やテクノロジーに常に携わる
■新しい知識やスキル習得の連続
同じ仕事も、同じ一日もない。人間が一人ひとり異なるように、すべてのプロジェクトに新しい課題があります。また、世界初、日本初の試みや、世の中を大きく変えるような案件が集まってくるのもアクセンチュアならではでしょう。驚くような大規模な案件も、専門性の高い少数精鋭のプロジェクトも多数あります。もちろん海外プロジェクトに参加するチャンスも。その時々の自分のキャリアに合った、刺激的な仕事が常に存在する。それがアクセンチュアの強みです。
Enjoyable working environment
■国境や国籍を越えたチームワーク
■職級、年齢の上下や性別の区別なく、率直に意見の言える社風
■キャリアアップをサポートするコミュニティやクラブ活動
■仕事とプライベートのメリハリを奨励
どうせ仕事をするならガムシャラにやれるくらい刺激的に、楽しく。働く喜びを提供するための環境作りをとても大切にしています。「人が足りない」で済ませるのではなく、「じゃあ、ドイツのオフィスから」と必要なプロを呼んでしまう。新人の正しい意見を聞いて、上司が自案を喜んで取り下げる。アクセンチュアへの転職者が驚くのはその合理的で納得度の高い環境です。
"Work hard, enjoy life."
■常に、全力で働き、自分の人生も目一杯楽しむ。
一個人として、家庭人としての生き方が充実してこそ、柔軟な発想や、大胆な挑戦も可能になると考えます。プロジェクト後の数週間の休暇など、リフレッシュの機会を奨励しているのもそのためです。また逆に、飛躍的に成長するためには、ある時期集中的に努力することも必要。そのメリハリが豊かなキャリアと選択肢を可能にすると考えています。個性的なプライベート･ライフを充実させている社員がたくさんいます。
Teamwork
ワークスタイル
WORKSTYLE キーワード
Teamwork
■コンサルタントこそ、仕事はすべてチームワーク。
本当の企業変革を企画し、実現まで導くためには、異なる専門性を持ったコンサルタントや、共にプロジェクトを推進するクライアント企業の方々と、ひとつの目標に向かって力を合わせることが必要です。そこには、だからこそ生み出せる革新があり、価値があります。この仕事の醍醐味はそこにある！と断言するコンサルタントはたくさんいます。
Professional development
■成長しつづけることが、コンサルタントの条件
コンサルタントは常に環境の変化に合わせ成長を続けなければなりません。そして、年次や経験量ではなく、発揮した価値で常に評価され続けます。一見厳しいですが、理不尽な制度や既得権益に邪魔されず、誰もが平等に成功を目指せる環境がここにはあります。ポスト争いではない、正しい実力主義。社長を含めすべての社員が自分の能力についての評価を常に明確に受け、次の目標に向かって努力し続ける風土が息づいているのです。
がむしゃら【我武者羅】
派生語 がむしゃらな(に) reckless(ly)
あまのじゃく【天の邪鬼】
22歳。
就職先にこだわりはなかった。銀行、住宅メーカー、情報関係の出版社、消防士の試験まで受けた。どこも面白そうだったけれど、どこも決め手に欠けた。就職活動のシーズンも終わりに近づいた頃、アクセンチュアのセミナーがあった。そこに行くまで、コンサルタントにはどこか人間味に欠けた冷たいイメージを持っていた。でも、それはまったくの誤解だった。セミナーでも個別面談でも、語りかけてくるアクセンチュアの社員たちは、みんな情熱的で熱かった。彼らの目は、風が吹けば必ず集まってくるウィンドサーファーたちにどこか似ているような気がした。受け身ではなく、自発的にやれるような仕事がしたい。そう思っていた僕にとって、アクセンチュアは最高の場であるように思えた。
25歳。
入社以来、クライアント企業の情報システム部門の仕事に携わることが多い。とても充実した5年間だったけれど、一度だけ会社を辞めようかなと思ったことがある。上司にさりげなく相談したら、僕の気持ちを見透かすように言われた。「おまえは、アクセンチュアでできることをやったのか？」はっとした。その頃の自分は、わがままだった。やりたい仕事ができないと焦り、それを環境や誰かのせいにしていたのだと思う。自発的に働きたくてアクセンチュアに入ったのに、なんのことはない受け身で仕事をしていたのだ。上司の一言で、意識が変わった。与えられた仕事だけでなく、自分から働きかけるようになった。働きかければチャンスはやってくる。コアコンピタンスがないこと。それが僕の強みなんじゃないかと思っている。僕はあらゆることに興味が持てる。環境が変わっても全然苦にならないし、目標に向う瞬発力とスピードにはちょっと自信がある。マネジャーになった今も、「市川をつっこめば、なんとかなる」、と頼られる存在であり続けたい。
Saturday, January 01, 2005
第4回 コストマネジメントは「時は金なり」でうまくいく
第4回 コストマネジメントは「時は金なり」でうまくいく
杦岡充宏（スカイライトコンサルティング）
2004/8/18
前回（「第3回 タイムマネジメントは急がば回れ」）は、プロジェクトの推進に欠かせないタイムマネジメントについて解説した。タイムマネジメントをきちんとしようと思うと、マネジメント側にもある程度の負荷が発生する。しかしながら、やるべきことをやるべきタイミングでやらなかったため、後で取り返しのつかない事態に発展した悲しい事例も多いのではないだろうか。やるべきことを地道に日々行うこと。一見遠回りなようであるがこれがタイムマネジメントの極意ともいえるであろう。
今回は前回同様プロジェクトの推進には欠かせないコストマネジメントの勘所を解説する。それではまず、PMBOK（Project Management Body Of Knowledge）におけるコストマネジメントの定義を確認しておこう。
■コストマネジメントとは
コストマネジメントとは、承認された予算内でプロジェクトを完了させることを目的とし、前回までのマネジメント領域と同様、「Plan-Do-See-Action」のサイクルになっている。つまり、プロジェクト期間中、コスト見積もりは常に見直され、最新の状態に保たれていなければならない。PMBOKでは、コストマネジメントは以下の4つのプロセスから構成されている。
コストマネジメント
のプロセス 主要成果物 説明
資源計画 必要資源量 機器など物理的にどのくらいの資源が必要かを決定する。
コスト積算（見積もり） コスト見積もりなど プロジェクトの完成費に必要な資源の予想コストの合計。
予算設定（時系列配分） コストベースライン（時系列予算配分） コスト実績を管理するために時系列に予算を配分したもの。
コスト管理 改定コスト見積もり 進ちょく度を測定し、コスト見積もりの変更管理を行う
表1 PMBOKにおけるコストマネジメント
コストマネジメントとは、考え方自体はそれほど難しいものではない。成果物とタスクから必要な人員や機器などの資源を洗い出し、そこから必要な金額を計画する。そしてその計画どおりにプロジェクトを完了させるよう働き掛けていくことである。しかし多くの方が経験しているのではないかと思うが、スケジュール同様、当初計画どおりの予算で終了させることは難しい。特にプロジェクトの規模が大きくなればなるほど困難になるのである。
これは当然のことであろう。そもそも計画を立てる時点では、何をどのように作るかも固まっておらず、全体が見通せない場合も多い。このような見えない状態で正確にいくら必要になるかを導き出すことは困難である。しかし、見えないからといって精度の低い見積りではプロジェクトが予算超過に陥る恐れがある。即ち、計画時点の精度はプロジェクトの成功に大きく影響するのである。
いい換えれば、全体を見通すことができれば、精度の高い見積もりが可能になり、プロジェクトを成功に導く可能性が高くなるということである。
それではどうすれば全体を見通せるようになるのか。実践的な勘所についてケーススタディを通じて紹介することにしよう。
■経験を活用する
あなたの部署にはほぼ時を同じくして始まった2つのプロジェクトがある。
2つのプロジェクトはともに、WBS（Work Breakdown Structure）を定義し、プロジェクトスケジュールを作成しながらコスト見積もりを行っている。2人のマネージャは、ともにこれまで経験したことのない技術環境を用いるとのことでコストの見積りに頭を悩まされているようだ。2人の様子をのぞいてみることにしよう。
矢見雲マネージャの発言
「困ったなあ。開発とテスト要員はどれくらい必要なのだろうか。必要なハードウェアもよく分からんなあ」
「うーん、俺の経験からするとこんなものかなあ。やっぱこういうときは“エイヤっ”しかないよな」
「まあ、この規模だとこんなものだろう。よし、できた！」
出来杉マネージャの発言
「困ったなあ。開発とテスト要員はどれくらい必要なのだろうか。必要なハードウェアもよく分からんなあ」
「社内に似たようなプロジェクトを経験した者はいないだろうか。よし先輩と同僚に聞いてみることにしよう」
「おっ、早速同期からメールで返信があった。ちょうど同じようなプロジェクトをやったことがあるらしい。私が作った見積りを見てもらうようお願いしよう」
コストを見積もるときに、よりどころとなるのは「経験」であろう。幸運にも以前に類したプロジェクトを経験していれば、プロジェクト期間中に必要なタスク、成果物、発生するイベントなども予想できるので容易に見積もりが可能である。しかし、システム開発でいえば、クライアントごとに要件・仕様の大きく異なることが多く、未経験のプロジェクトにアサインされるという経験をした方も多いことであろう。そんな場合どうすればよいのか。
上でいう「経験」とは個人の経験だけでなく組織の経験を活用することも含んでいることに留意してほしい。あなたには経験がなくても上司や同僚、または他部署では経験しているかもしれない。場合によっては、外部ベンダから情報を収集することも有効である。このような経験者・有識者の知見を活用する・しないによって、大きく結果は変わってくる。
上の例で出来杉マネージャは、「先輩・同僚に聞いてみよう」としているが、組織として過去のプロジェクト情報を共有・活用できる仕組みがあることが望ましい。もし貴方の企業・部署が個人の経験にのみ頼って他人の経験を活用できる仕組み・風土がないようであればぜひ「組織としての経験」を活用できるようにすることをお勧めする。
参考までに弊社で行っている主な取り組みを以下に紹介しておく。
各コンサルタントがどのような経験・スキルを有しているかを把握する「スキルDB（データベース）」の活用
全プロジェクトの計画成果物や実行成果物を共有する「ナレッジマネジメントシステム」の活用
文書だけでは見えない実際のノウハウを補うための「プロジェクト勉強会」の実施
重要なことは、見えないままでの見積もりを避けることであり、自分の知らないことは知っている人に聞いて見えるようにすることである。また、このことは、多くの経験を積み自己のスキルに自信があるベテランほどおろそかになりがちなので注意が必要であることを付記しておく。
■計画は努力目標ではなくコミットするもの
プロジェクトによっては、初めから予算とスコープがすでに決められていることも多い。その決定段階において現場が加わることが望ましいのだが、残念ながら現場のあずかり知らぬところで決められていることも多いのではないだろうか。そしてその場合には、実現不可能な低予算と広範なスコープという悲劇がもれなく付いてくることもまれではない。
このような場合、プロジェクトマネージャが取るべき対処法についてケースを通じて考えてみることにしよう。
今回の案件は、顧客の都合で予算の上限が2000万円と決められており、実現すべき機能も大枠固まっている。これは顧客と営業サイドではほぼ合意に達しているようだ。しかし、現場サイドで検証したところ50％の予算超過が予想される結果となった。そして、あなたの部署のマネージャ2人が対応策を考えることになった。
矢見雲マネージャの発言
「この予算でこのスコープは厳しいなあ。とてもじゃないけど無理だよ」
「顧客と再交渉して予算上乗せかスコープを一部カットできれば一番望ましいので、その交渉をお願いできないか」
営業の発言
「それは無理です。できたら苦労はしません」
矢見雲マネージャの発言
「どう少なく見ても設計までに10人月、開発テストを考えると30人月は必要だから最低3000万円は必要だよ」
「よし、どこまで下げられるか分からんが、開発の部分は安い協力会社を探して人件費を下げてみるか」
「これで2000万円を超えた分はメンバーの数を減らして、残ったメンバーに兼務という形で掛け持ちをお願いして頑張ってもらおう」
「2000万円で収まるかどうか分からんが、これでやってみるしかないな」
営業の発言
「じゃあ、よろしくお願いします」
出来杉マネージャの発言
「この予算でこのスコープは厳しいなあ。とてもじゃないけど無理だよ」
「顧客と再交渉して予算上乗せかスコープを一部カットできれば一番望ましいので、その交渉をお願いできないか」
営業の発言
「それは無理です。できたら苦労はしません」
出来杉マネージャの発言
「開発サイドでできることは、開発の部分を協力会社に外注して人件費を下げることくらいだ。これでどこまで下がるか至急見積りを出すが、それでも2000万円は超えるだろう」
「その場合、納品する成果物（ドキュメント）を減らすことと顧客との役割見直しの交渉をお願いしたい。テストやマニュアル作成、データ移行など顧客サイドでできることを洗い出すので、それらを顧客側で担当してもらえれば2000万円で収まりそうだ」
営業の発言
「分かりました。よろしくお願いします」
この例では、コストを削減するための具体的な方法がいくつか挙げられている。スコープのカット、作業の外注化、納品成果物の簡素化、顧客との役割分担の見直し。これら以外にも、設計やテストを自動化するツールを活用して効率化したり、ペアプログラミングやアジャイルなどの開発手法を用いて生産性を向上させることでコスト削減を図っているプロジェクトもあろう。コスト削減の方法は、各プロジェクトやその組織によって実にさまざまであり、そのケースに応じた方策を考えればよい。
むしろここで重要なことは、
プロジェクトマネージャはコミットできない見積りのままプロジェクトを推進せず、あらゆる方策を施しコミットできる形にすること
である。
上の例でいえば、矢見雲マネージャは、「2000万円で収まるかどうか分からんが、これでやってみるしかないな」といっているのに対して、出来杉マネージャは2000万円で収まるまで、いくつも方策を取っている点である。計画は、努力目標ではなくプロジェクトマネージャがコミットすべきものである。
実際には、組織の方針、関係部署や上司の意向など諸事情により無理難題を要求され仕方なく進めてしまうプロジェクトマネージャも中にはいるかもしれない。しかし、無理をして進めた結果、予算を大幅に超過するようなことになれば、必ず顧客、もしくは自分の会社（受注側）や一緒に働くプロジェクトメンバーにも多大な迷惑を掛けることになる。
もしコミットできない予算のままプロジェクトを進めようとしているならば、プロジェクトマネージャとしていま一度このことを自問してみる必要があるのではないか。プロジェクトの結果に責任を負うのはほかならぬわれわれプロジェクトマネージャであるのだから。
■進ちょくの遅れはコスト超過
コストマネジメントは、精度の高いコスト見積もり同様に、プロジェクト期間を通じて予実を管理していくことが重要である。コストを変動させる要因には、要員の人件費、ハードウェア、ソフトウェアから要員のタクシー代や場合によってはプロジェクトスペースの賃料などの経費と、プロジェクトによってさまざまなものがある。しかし、メインとなる要因は人件費であろう。現在の体制ではリカバリーできない進ちょくの遅れや変更要件が発生した場合、要員を追加したいが追加すれば予算を超過してしまう。このような経験は多くのプロジェクトマネージャが経験しているのではないだろうか。
以下のケースを例にコストコントロールの勘所を考えてみたい。
●想定ケース
・プロジェクトメンバーはAさん、Bさんの2人
・プロジェクト期間は2カ月。予算は400万円
・Aさん、Bさんの人件費は月100万円
・Aさん、Bさんとも1カ月に1本プログラムを担当し、プロジェクト全体では計4本仕上げる計画
図1 達成計画価値とコストの支出計画
上の図は、コスト支出計画であり、達成計画価値をグラフ化したものである。達成計画価値とはここでいえば、プロジェクト予算が400万円でプログラムは4本であるから1本当たり100万円の価値と置き換えることができる。従って、予定どおりプロジェクトが進めば1カ月目では、2本のプログラムが終了しているはずなので、その時点での達成計画価値は200万円になる予定ということを意味している。
1カ月目の時点でプロジェクトの進ちょく状況を見てみると、Aさんは予定していたプログラムを完了させたが、Bさんは半分しか終了していないことが分かった。この時点で、各数値は以下のようになる（図2を参照）。
実支出＝200万（Aさん、Bさんの1カ月の人件費＝100万円×2）
実達成価値＝150万（Aさん1本（100万円）＋Bさん0.5本（50万円））
図2 1カ月終了時点の進ちょく状況
ここで2人のマネージャの対応方法を見てみることにしよう。
矢見雲マネージャの発言
「コスト支出は予定どおりであるが、残念ながらこれまで進ちょくに遅れが見られる」
「Bさんは環境に慣れるの時間がかかり進ちょくが遅れていたが、そろそろ環境にも慣れてきたので生産性も上がるだろう」
「AさんにもBさんのフォローを頼んでなんとか当初の計画どおりに2人で4本を終わらせることができるのではないかと考えている」
「来月は残業と休日出勤を覚悟しておいてほしい。大丈夫、君たちならできる。じゃあ、よろしく頼むよ」
出来杉マネージャの発言
「残念ながらこれまで進ちょくに遅れが見られる。このままいけば当初の納期である来月時点では、プログラム1本分が遅れてしまい、完了するまでにさらに1カ月納期遅延となり、完成時のコストも567万円になり予算超過に陥ることにもなる」（図3参照）
図3 このままでプロジェクトを進行した場合
「従って、Bさんの代わりに来月はベテランのCさん（単価月150万円、生産性は1.5倍）を投入することにしよう」
「これだと50万円のコスト超過は起こるが納期どおりに完了させることが可能である」（図4参照）
図4 Bさんの代わりにベテランのCさんを投入した場合
実際のプロジェクトでは、人員交代によって引き継ぎや立ち上がりまでのラーニングカーブ、または交代要員を見つけるまでのリードタイムなども考慮する必要があり、このケースのように簡単にはいかない。しかし、ここでいいたいのは次の点である。
まず、「進ちょくの遅れはコスト超過と同義であること」を認識する必要がある。上の例で矢見雲マネージャは、「実際のコスト支出は予定どおり」としているが、進ちょくの遅れが発生している以上、実質コスト超過を意味していることは図3からもお分かりいただけるであろう。加えて重要なことは「現時点での完了予測」をたてることである。ここでいう現時点での完了予測とは、これまでの進ちょくのままいくとどうなるのかということであり、将来のキャッチアップを見越したものでは決してない。
そうすることで、図4のような策を講じることが可能となるのである。この意識がないと矢見雲マネージャのように「進ちょくの遅れをなんとか現行の体制とスケジュールで収めるることに注力しすぎてしまい、頑張った結果、結局間に合わず土壇場になっての要員追加やリスケジュールを強いられ、後手後手の対応を余儀なくされ、かえって傷口が広がってしまった」というよく聞かれる悲劇に陥る恐れがあることを心に留めておいてほしい。
最後になるが、このケースで触れた進ちょくの達成度合いを金銭価値で置き換えて、実際のコストとともにその予実を一元的金銭価値で管理する考え方をEVM（アーンド・バリュー・マネジメント）という。近年、雑誌・書籍などでも広く紹介されており、PMBOKでも推奨されている。すでにご存じの読者も多いことと推察するが、インターネットで入手可能な情報から学ぶこともできるので、考え方程度はぜひとも押さえておきたい。
■今回のまとめ
・コストマネジメントとは、承認された予算内でプロジェクトを完了させること。
・精度の高い見積もりはプロジェクトの成功に直結する。そして精度の高い見積もりは、プロジェクト全体を見通すことで可能となる。
・プロジェクトマネージャはコミットできない見積もりのままプロジェクトを推進せず、あらゆる方策を施しコミットできる形にすること。
・進ちょくの遅れはコスト超過と同義と認識するとともに、現在までの進ちょくで進めた場合の完了までのコスト予測をたてて、最も合理的なアクションを取ること。
杦岡充宏（スカイライトコンサルティング）
2004/8/18
前回（「第3回 タイムマネジメントは急がば回れ」）は、プロジェクトの推進に欠かせないタイムマネジメントについて解説した。タイムマネジメントをきちんとしようと思うと、マネジメント側にもある程度の負荷が発生する。しかしながら、やるべきことをやるべきタイミングでやらなかったため、後で取り返しのつかない事態に発展した悲しい事例も多いのではないだろうか。やるべきことを地道に日々行うこと。一見遠回りなようであるがこれがタイムマネジメントの極意ともいえるであろう。
今回は前回同様プロジェクトの推進には欠かせないコストマネジメントの勘所を解説する。それではまず、PMBOK（Project Management Body Of Knowledge）におけるコストマネジメントの定義を確認しておこう。
■コストマネジメントとは
コストマネジメントとは、承認された予算内でプロジェクトを完了させることを目的とし、前回までのマネジメント領域と同様、「Plan-Do-See-Action」のサイクルになっている。つまり、プロジェクト期間中、コスト見積もりは常に見直され、最新の状態に保たれていなければならない。PMBOKでは、コストマネジメントは以下の4つのプロセスから構成されている。
コストマネジメント
のプロセス 主要成果物 説明
資源計画 必要資源量 機器など物理的にどのくらいの資源が必要かを決定する。
コスト積算（見積もり） コスト見積もりなど プロジェクトの完成費に必要な資源の予想コストの合計。
予算設定（時系列配分） コストベースライン（時系列予算配分） コスト実績を管理するために時系列に予算を配分したもの。
コスト管理 改定コスト見積もり 進ちょく度を測定し、コスト見積もりの変更管理を行う
表1 PMBOKにおけるコストマネジメント
コストマネジメントとは、考え方自体はそれほど難しいものではない。成果物とタスクから必要な人員や機器などの資源を洗い出し、そこから必要な金額を計画する。そしてその計画どおりにプロジェクトを完了させるよう働き掛けていくことである。しかし多くの方が経験しているのではないかと思うが、スケジュール同様、当初計画どおりの予算で終了させることは難しい。特にプロジェクトの規模が大きくなればなるほど困難になるのである。
これは当然のことであろう。そもそも計画を立てる時点では、何をどのように作るかも固まっておらず、全体が見通せない場合も多い。このような見えない状態で正確にいくら必要になるかを導き出すことは困難である。しかし、見えないからといって精度の低い見積りではプロジェクトが予算超過に陥る恐れがある。即ち、計画時点の精度はプロジェクトの成功に大きく影響するのである。
いい換えれば、全体を見通すことができれば、精度の高い見積もりが可能になり、プロジェクトを成功に導く可能性が高くなるということである。
それではどうすれば全体を見通せるようになるのか。実践的な勘所についてケーススタディを通じて紹介することにしよう。
■経験を活用する
あなたの部署にはほぼ時を同じくして始まった2つのプロジェクトがある。
2つのプロジェクトはともに、WBS（Work Breakdown Structure）を定義し、プロジェクトスケジュールを作成しながらコスト見積もりを行っている。2人のマネージャは、ともにこれまで経験したことのない技術環境を用いるとのことでコストの見積りに頭を悩まされているようだ。2人の様子をのぞいてみることにしよう。
矢見雲マネージャの発言
「困ったなあ。開発とテスト要員はどれくらい必要なのだろうか。必要なハードウェアもよく分からんなあ」
「うーん、俺の経験からするとこんなものかなあ。やっぱこういうときは“エイヤっ”しかないよな」
「まあ、この規模だとこんなものだろう。よし、できた！」
出来杉マネージャの発言
「困ったなあ。開発とテスト要員はどれくらい必要なのだろうか。必要なハードウェアもよく分からんなあ」
「社内に似たようなプロジェクトを経験した者はいないだろうか。よし先輩と同僚に聞いてみることにしよう」
「おっ、早速同期からメールで返信があった。ちょうど同じようなプロジェクトをやったことがあるらしい。私が作った見積りを見てもらうようお願いしよう」
コストを見積もるときに、よりどころとなるのは「経験」であろう。幸運にも以前に類したプロジェクトを経験していれば、プロジェクト期間中に必要なタスク、成果物、発生するイベントなども予想できるので容易に見積もりが可能である。しかし、システム開発でいえば、クライアントごとに要件・仕様の大きく異なることが多く、未経験のプロジェクトにアサインされるという経験をした方も多いことであろう。そんな場合どうすればよいのか。
上でいう「経験」とは個人の経験だけでなく組織の経験を活用することも含んでいることに留意してほしい。あなたには経験がなくても上司や同僚、または他部署では経験しているかもしれない。場合によっては、外部ベンダから情報を収集することも有効である。このような経験者・有識者の知見を活用する・しないによって、大きく結果は変わってくる。
上の例で出来杉マネージャは、「先輩・同僚に聞いてみよう」としているが、組織として過去のプロジェクト情報を共有・活用できる仕組みがあることが望ましい。もし貴方の企業・部署が個人の経験にのみ頼って他人の経験を活用できる仕組み・風土がないようであればぜひ「組織としての経験」を活用できるようにすることをお勧めする。
参考までに弊社で行っている主な取り組みを以下に紹介しておく。
各コンサルタントがどのような経験・スキルを有しているかを把握する「スキルDB（データベース）」の活用
全プロジェクトの計画成果物や実行成果物を共有する「ナレッジマネジメントシステム」の活用
文書だけでは見えない実際のノウハウを補うための「プロジェクト勉強会」の実施
重要なことは、見えないままでの見積もりを避けることであり、自分の知らないことは知っている人に聞いて見えるようにすることである。また、このことは、多くの経験を積み自己のスキルに自信があるベテランほどおろそかになりがちなので注意が必要であることを付記しておく。
■計画は努力目標ではなくコミットするもの
プロジェクトによっては、初めから予算とスコープがすでに決められていることも多い。その決定段階において現場が加わることが望ましいのだが、残念ながら現場のあずかり知らぬところで決められていることも多いのではないだろうか。そしてその場合には、実現不可能な低予算と広範なスコープという悲劇がもれなく付いてくることもまれではない。
このような場合、プロジェクトマネージャが取るべき対処法についてケースを通じて考えてみることにしよう。
今回の案件は、顧客の都合で予算の上限が2000万円と決められており、実現すべき機能も大枠固まっている。これは顧客と営業サイドではほぼ合意に達しているようだ。しかし、現場サイドで検証したところ50％の予算超過が予想される結果となった。そして、あなたの部署のマネージャ2人が対応策を考えることになった。
矢見雲マネージャの発言
「この予算でこのスコープは厳しいなあ。とてもじゃないけど無理だよ」
「顧客と再交渉して予算上乗せかスコープを一部カットできれば一番望ましいので、その交渉をお願いできないか」
営業の発言
「それは無理です。できたら苦労はしません」
矢見雲マネージャの発言
「どう少なく見ても設計までに10人月、開発テストを考えると30人月は必要だから最低3000万円は必要だよ」
「よし、どこまで下げられるか分からんが、開発の部分は安い協力会社を探して人件費を下げてみるか」
「これで2000万円を超えた分はメンバーの数を減らして、残ったメンバーに兼務という形で掛け持ちをお願いして頑張ってもらおう」
「2000万円で収まるかどうか分からんが、これでやってみるしかないな」
営業の発言
「じゃあ、よろしくお願いします」
出来杉マネージャの発言
「この予算でこのスコープは厳しいなあ。とてもじゃないけど無理だよ」
「顧客と再交渉して予算上乗せかスコープを一部カットできれば一番望ましいので、その交渉をお願いできないか」
営業の発言
「それは無理です。できたら苦労はしません」
出来杉マネージャの発言
「開発サイドでできることは、開発の部分を協力会社に外注して人件費を下げることくらいだ。これでどこまで下がるか至急見積りを出すが、それでも2000万円は超えるだろう」
「その場合、納品する成果物（ドキュメント）を減らすことと顧客との役割見直しの交渉をお願いしたい。テストやマニュアル作成、データ移行など顧客サイドでできることを洗い出すので、それらを顧客側で担当してもらえれば2000万円で収まりそうだ」
営業の発言
「分かりました。よろしくお願いします」
この例では、コストを削減するための具体的な方法がいくつか挙げられている。スコープのカット、作業の外注化、納品成果物の簡素化、顧客との役割分担の見直し。これら以外にも、設計やテストを自動化するツールを活用して効率化したり、ペアプログラミングやアジャイルなどの開発手法を用いて生産性を向上させることでコスト削減を図っているプロジェクトもあろう。コスト削減の方法は、各プロジェクトやその組織によって実にさまざまであり、そのケースに応じた方策を考えればよい。
むしろここで重要なことは、
プロジェクトマネージャはコミットできない見積りのままプロジェクトを推進せず、あらゆる方策を施しコミットできる形にすること
である。
上の例でいえば、矢見雲マネージャは、「2000万円で収まるかどうか分からんが、これでやってみるしかないな」といっているのに対して、出来杉マネージャは2000万円で収まるまで、いくつも方策を取っている点である。計画は、努力目標ではなくプロジェクトマネージャがコミットすべきものである。
実際には、組織の方針、関係部署や上司の意向など諸事情により無理難題を要求され仕方なく進めてしまうプロジェクトマネージャも中にはいるかもしれない。しかし、無理をして進めた結果、予算を大幅に超過するようなことになれば、必ず顧客、もしくは自分の会社（受注側）や一緒に働くプロジェクトメンバーにも多大な迷惑を掛けることになる。
もしコミットできない予算のままプロジェクトを進めようとしているならば、プロジェクトマネージャとしていま一度このことを自問してみる必要があるのではないか。プロジェクトの結果に責任を負うのはほかならぬわれわれプロジェクトマネージャであるのだから。
■進ちょくの遅れはコスト超過
コストマネジメントは、精度の高いコスト見積もり同様に、プロジェクト期間を通じて予実を管理していくことが重要である。コストを変動させる要因には、要員の人件費、ハードウェア、ソフトウェアから要員のタクシー代や場合によってはプロジェクトスペースの賃料などの経費と、プロジェクトによってさまざまなものがある。しかし、メインとなる要因は人件費であろう。現在の体制ではリカバリーできない進ちょくの遅れや変更要件が発生した場合、要員を追加したいが追加すれば予算を超過してしまう。このような経験は多くのプロジェクトマネージャが経験しているのではないだろうか。
以下のケースを例にコストコントロールの勘所を考えてみたい。
●想定ケース
・プロジェクトメンバーはAさん、Bさんの2人
・プロジェクト期間は2カ月。予算は400万円
・Aさん、Bさんの人件費は月100万円
・Aさん、Bさんとも1カ月に1本プログラムを担当し、プロジェクト全体では計4本仕上げる計画
図1 達成計画価値とコストの支出計画
上の図は、コスト支出計画であり、達成計画価値をグラフ化したものである。達成計画価値とはここでいえば、プロジェクト予算が400万円でプログラムは4本であるから1本当たり100万円の価値と置き換えることができる。従って、予定どおりプロジェクトが進めば1カ月目では、2本のプログラムが終了しているはずなので、その時点での達成計画価値は200万円になる予定ということを意味している。
1カ月目の時点でプロジェクトの進ちょく状況を見てみると、Aさんは予定していたプログラムを完了させたが、Bさんは半分しか終了していないことが分かった。この時点で、各数値は以下のようになる（図2を参照）。
実支出＝200万（Aさん、Bさんの1カ月の人件費＝100万円×2）
実達成価値＝150万（Aさん1本（100万円）＋Bさん0.5本（50万円））
図2 1カ月終了時点の進ちょく状況
ここで2人のマネージャの対応方法を見てみることにしよう。
矢見雲マネージャの発言
「コスト支出は予定どおりであるが、残念ながらこれまで進ちょくに遅れが見られる」
「Bさんは環境に慣れるの時間がかかり進ちょくが遅れていたが、そろそろ環境にも慣れてきたので生産性も上がるだろう」
「AさんにもBさんのフォローを頼んでなんとか当初の計画どおりに2人で4本を終わらせることができるのではないかと考えている」
「来月は残業と休日出勤を覚悟しておいてほしい。大丈夫、君たちならできる。じゃあ、よろしく頼むよ」
出来杉マネージャの発言
「残念ながらこれまで進ちょくに遅れが見られる。このままいけば当初の納期である来月時点では、プログラム1本分が遅れてしまい、完了するまでにさらに1カ月納期遅延となり、完成時のコストも567万円になり予算超過に陥ることにもなる」（図3参照）
図3 このままでプロジェクトを進行した場合
「従って、Bさんの代わりに来月はベテランのCさん（単価月150万円、生産性は1.5倍）を投入することにしよう」
「これだと50万円のコスト超過は起こるが納期どおりに完了させることが可能である」（図4参照）
図4 Bさんの代わりにベテランのCさんを投入した場合
実際のプロジェクトでは、人員交代によって引き継ぎや立ち上がりまでのラーニングカーブ、または交代要員を見つけるまでのリードタイムなども考慮する必要があり、このケースのように簡単にはいかない。しかし、ここでいいたいのは次の点である。
まず、「進ちょくの遅れはコスト超過と同義であること」を認識する必要がある。上の例で矢見雲マネージャは、「実際のコスト支出は予定どおり」としているが、進ちょくの遅れが発生している以上、実質コスト超過を意味していることは図3からもお分かりいただけるであろう。加えて重要なことは「現時点での完了予測」をたてることである。ここでいう現時点での完了予測とは、これまでの進ちょくのままいくとどうなるのかということであり、将来のキャッチアップを見越したものでは決してない。
そうすることで、図4のような策を講じることが可能となるのである。この意識がないと矢見雲マネージャのように「進ちょくの遅れをなんとか現行の体制とスケジュールで収めるることに注力しすぎてしまい、頑張った結果、結局間に合わず土壇場になっての要員追加やリスケジュールを強いられ、後手後手の対応を余儀なくされ、かえって傷口が広がってしまった」というよく聞かれる悲劇に陥る恐れがあることを心に留めておいてほしい。
最後になるが、このケースで触れた進ちょくの達成度合いを金銭価値で置き換えて、実際のコストとともにその予実を一元的金銭価値で管理する考え方をEVM（アーンド・バリュー・マネジメント）という。近年、雑誌・書籍などでも広く紹介されており、PMBOKでも推奨されている。すでにご存じの読者も多いことと推察するが、インターネットで入手可能な情報から学ぶこともできるので、考え方程度はぜひとも押さえておきたい。
■今回のまとめ
・コストマネジメントとは、承認された予算内でプロジェクトを完了させること。
・精度の高い見積もりはプロジェクトの成功に直結する。そして精度の高い見積もりは、プロジェクト全体を見通すことで可能となる。
・プロジェクトマネージャはコミットできない見積もりのままプロジェクトを推進せず、あらゆる方策を施しコミットできる形にすること。
・進ちょくの遅れはコスト超過と同義と認識するとともに、現在までの進ちょくで進めた場合の完了までのコスト予測をたてて、最も合理的なアクションを取ること。
Friday, December 31, 2004
第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すべてについて、漏れなく作業をリストアップする。常に先を見越して、早めにアクションを取る姿勢も忘れずに。
・実績が計画から乖離した際には、ステークホルダーにタイムリーに情報共有するとともに、是正措置を取る。
・メンバーに時間に対するコスト意識を持たせ、チームとしてのパフォーマンスを高める。
杦岡充宏（スカイライトコンサルティング）
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番については、仕様変更手順に基づき、ステアリングコミッティ（プロジェクト運営委員会）での承認が必要になります。仕様変更依頼書を作成しますので必要事項に記入をお願いします」
顧客：「分かった。ありがとう。よろしく頼むよ」
このケースで重要なポイントは、追加要件に対応することが難しい場合によく行われている「優先順位を付けて対応を考える」ことにある。矢見雲マネージャの例では、個別の要件ごとに判断しているが、このような場合、各要件に必要とされる理由や背景に基づいて判断することになる。しかし、これだとどうしてもあれも重要、これも重要となってしまう、あるいは顧客とこちらで重要度が一致しないということに陥りがちではないだろうか。
重要なのは、どういう基準で優先順位を付けるかについて合意することである。顧客と開発側の双方が容易に判断できるプロジェクト全体を通しての判断基準をておくことにより、お互いに納得のいく意思決定が迅速にできる。
■今回のまとめ
・スコープマネジメントとは、プロジェクトの目標を達成するために必要な成果物とタスクを、プロジェクト期間を通じて定義していき、その内容をやり遂げることを保証すること。
・スコープマネジメントは、プロジェクトの成功／失敗に大きく影響を及ぼすこと。
・スコープを決定する際は、プロジェクトの関係者が誰であるかをしっかり押さえて、関係者「全員」の合意を得ること。
・定義したスコープは、顧客／開発側双方で確認できるよう「可視化」しておき合意を得ること。
・スコープの変更を検討する際に、要件の優先順位を検討する場合は、優先順位付けの判断基準を明確にすること。
杦岡充宏（スカイライトコンサルティング）
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自分戦略研究所 > 自分戦略研究室）
Subscribe to:
Posts (Atom)