侵蝕軟體項目開發的10種典型錯誤

10 classic mistakes that plague software development projects

By Justin James

Takeaway: When you combine project management pitfalls with software development challenges, you have a recipe for some big (but often preventable) problems.

Project management is never an exact science, but when you combine it with the vagaries of software development, you have a recipe for disaster. I have seen a fair number of common mistakes that project managers make when working with software development projects. Some of these mistakes are not exclusive to software development, but they are especially prevalent and damaging in that context.

1: The “pregnant woman” mistake

Fred Brooks illustrated a common project management mistake with his famous statement that just because one woman can have a baby in nine months does not mean that nine women can have a baby in one month. And we still see this come up time and time again — the idea that throwing more people at a problem can make it be fixed quicker. Sadly, this is just not true.

Every person you add to a project adds friction to the project as well –  things like the time needed to bring them up to speed or coordinate their work with other people. In fact, my experience has been that there is a tipping point where adding people actually slows the work down more than it speeds things up, especially for the first few months. And there are many tasks that just can’t be split up to be done by many people or teams at once. They simply have to be done “one foot in front of the other.”

2: The wrong metrics

Managers need metrics for variety of reasons: measuring “success” or status, performance reviews and analysis, and so on. The mistake I see too often is that the easier it is to collect a metric, the more likely that it’s not measuring anything useful. Of course, the easiest metrics to collect or understand are also the most likely to be used. Let’s take “bug tickets” as an example.

It is easy to count how many tickets get entered. But that is not a good measure of quality, because how many of those tickets are user error or truly “features”? So managers often look to the next level of metric: ticket resolution rate (tickets closed per day or week or iteration or whatever). If you have ever dealt with a help desk that constantly closes tickets for things that aren’t actually fixed, causing a proliferation of tickets, you know what it’s like dealing with an organization driven by this metric!

Instead of actually getting work done or helping the user (for example, leaving tickets open until the user accepts the resolution), the organization exists solely to open as many tickets as possible and then close them as quickly as possible, so it can get its resolution rate up. A better number would be the hardest to measure: ratio of true “bug tickets” created in relationship to features deployed, changes made, or something similar. Needless to say, that is not an easy number to understand or to collect and report on. The result is that organizations choose to make decisions based on the wrong metrics rather than the right ones, due to convenience.

3: Estimating times too far out

A common problem I see with certain project management methodologies is that they like to play “just so stories” with timelines and time estimates. Project manager who honestly think they know what pieces of functionality any given developer will be working on more than a month or two out (unless it is a very large, broad piece of functionality) are likely to be disappointed and mistaken. Software development is just too unpredictable. Even if you can prevent or account for all the usual things that alter timelines and priorities, there is still little guarantee that things will take the time you think they will.

4: Estimating times too broadly

Another typical issue with time estimates involves not breaking tasks down into small enough pieces. If I’m told that a piece of work will take one week, I’ll ask where exactly that number is coming from. Unless someone has analyzed all the minor pieces of work in the whole, a “one-week” time estimate is nothing but pure conjecture and should be disregarded.

5: Failing to account for tasks

How many times have you seen a deadline blown because it was established without accounting for a critical task like testing? That is another reason why you cannot and should not ever accept a task on a timeline that is not broken down into its component tasks. There is a chance that the estimate omits something important.

6: Poor communications

It is important to keep everyone in the loop on project status, but it is easy to forget to do it. This is where a lot of the mistrust between IT and the business team comes from: The business does not feel like it has a good handle on what’s happening with its projects. And the more it feels left in the dark, the more likely it is to start trying to micromanage or force things to happen the way it feels it should be done. You can mitigate this problem by letting people know where things stand, both on a regular basis and when milestones are accomplished or the status changes.

7: Disconnected business priorities

There is often a wide gap between the priorities of projects within the development organization, the priority of the project in the view of the overall business, and the priority of the project in the eyes of the requester. A common issue is that a “high priority” project for one department is not viewed as important by the business because it does not generate revenues, and so the developers also downgrade it. Everyone needs to be on the same page with priorities, and a large part of that is to ensure that business units are not evaluated on the basis of projects that the overall business considers lower priority.

8: Constructing a wall of process

When the development team feels overwhelmed, one of the natural reactions is to establish a lot of process to slow things down. I have worked at places where even the most simple of changes required a change request form to be filled out (on paper, of course), in triplicate, physically disseminated, agreed upon, cross-signed by managers, and after all of that, there was still a 45-day minimum time until the work was to be done! Needless to say, this organization was not seen as a “partner” or an “important lever for getting work done” in the business, they were seen as a cost center and treated as such. The wall of process is typically a stopgap measure to deal with deeper issues in the process or company’s culture, and while it is easier to put up the wall than to deal with those issues (and in some companies, the issues are irreconcilable), the wall of process is counterproductive and leads to a hostile environment.

9: The “hit-the-ground-running” myth

When adding people to a project, it is tempting to assume that they can hit the ground running. No one hits the ground running in the world of software development, and those who say they do are mistaken. Every project has an acclimation period, and the farther along the project is, the longer that acclimation period is — there is more and more code to understand and get a handle on. Failing to take this into account will get you into hot water. It may take only a few days or weeks for a developer to come into the project at the beginning, but it could take months for a developer to be fully productive when added to the project long after it has started

10: Multi-tasking

This is another “skill” (like “hitting the ground running”) that people think they have, but they really do not. The more you ask people to multi-task, the worse their work will be and the longer it will take. This applies to multi-tasking at the minute-to-minute level (juggling emails, phone calls, actual work, etc.) as well as the hour-to-hour or day-to-day level (handling multiple projects). The more you demand from people, the more the wheels fall off. To make it even worse, multi-tasking not only is likely to mangle the work, but it grinds people up and sends them looking for another job eventually… forcing you to bring in new people in the middle of a project and causing even more issues.


*****************

ソフトウェア開発プロジェクトを蝕む10の典型的な過ち

プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。

1．「人数を増やせばよい」という誤解

Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。

プロジェクトに人を1人投入すれば、その分だけプロジェクトに摩擦が増える--他の人に追いつくのにかかる時間や、他の人の作業とすりあわせをするのにかかる手間などが増えることになる。実際わたしの経験では、ある点を超えると、人が増えれば増えるほど、特に最初の数カ月間は、仕事のスピードは上がるどころか、かえって遅くなってしまう。そして、多くの人やチームに同時に分担させられない仕事も多い。そういった仕事は、一歩ずつ順番に進めて行くしかない。

2．間違った指標を採用する

マネージャーは、例えば「成功」や状況の度合いを測ったり、業績の評価や分析を行ったりといった、さまざまな理由から指標を必要とする。わたしが非常によく見かける間違いは、集めるのが簡単な指標ほど、何かを測るには役に立たない可能性が高いということだ。もちろん、集めたり理解したりするのが簡単な指標ほど、使われることが多い。例として、「バグチケット」を考えてみよう。

入力されたチケットの数を数えるのは簡単だ。しかし、これは品質を測る指標としてはよいものではない。なぜなら、それらのチケットのうち、どれだけがユーザーのミスが原因か、実際に「機能」の問題が原因かがわからないからだ。このため、マネージャーは次の段階の指標である、チケット解決率（1日または1週間、1リリースなどの、特定の期間当たりに閉じられたチケットの数）に目を向ける。もし、実際には解決していない問題のチケットを閉じるのが常態化しており、チケットの増加を招いているヘルプデスクを扱った経験があれば、この指標を元にして動いている組織を扱うのがどのようなものかはよくおわかりだろう。

実際に仕事をしたりユーザーを助ける（例えば、ユーザーが問題が解決したと認めるまでチケットを開いたままにしておく）かわりに、組織はチケット解決率を上昇させるために、できるだけ多くのチケットを開き、できるだけ素早くそれを閉じようとしてしまうものだ。設けられた機能、施された変更などに関して作成された本当の「バグチケット」率や、それに類似するものなど、より役に立つ数字は、計測するのが難しいだろう。言うまでもなく、これは理解や収集、報告することが簡単な数字ではない。そのため、組織は、便利さゆえに、正しい指標よりも間違った指標に基づいて判断を下すことを選択することになってしまう。

3．現実離れしたスケジュールを組む

一部のプロジェクト管理手法でよく見られる問題は、スケジュールや時間の見積もりに関して現実離れした想定で決めがちだというものだ。どの開発者がどの機能部分に1カ月か2カ月以上作業するかは分かっていると本気で思っているマネージャーがいたとしたら（非常に大きな、幅広い機能でない限り）、おそらく間違っているし、失望する可能性が高いだろう。ソフトウェア開発は非常に予測が難しいものだ。スケジュールや優先順位を変えてしまう可能性のあるあらゆることを防げるか、それらがすべて想定に入れられたとしても、想定通りの時間で仕事が進むという保証はあまりない。

4．時間の見積もりが大雑把すぎる

時間の見積もりに関するもう1つの典型的な問題は、作業を十分に小さく分割しないというものだ。もしわたしが、ある仕事に1週間かかるだろうと言われたら、その数字はどこから来たのかと聞き返すだろう。その作業に含まれている小さな作業をすべて分析したのでない限り、「1週間」という時間の見積もりは単なる推測であり、無視すべきだ。

5．作業を計算に入れ忘れる

テストのような必要不可欠な作業を計算に入れずに決められたために、破られた締め切りがいくつあったことか。これが、作業を部分的なタスクに分割しないままスケジュールが決められた仕事を決して引き受けてはならないもう1つの理由だ。そのスケジュールの見積もりには、なにか重要なことが抜けている可能性がある。

6．コミュニケーション不足

常に全員にプロジェクトの状況を周知徹底しておくことは非常に重要であるにも関わらず、忘れられがちだ。これが原因でIT部門と事業部門の間に不信感が生じることも多い。事業部門が、プロジェクトで起こっていることを十分に掌握していないと感じるのだ。また、暗闇に取り残されていると感じるほど、事業部門はIT部門に対してマイクロマネジメントをし始めようとしたり、やり方を強制しようとする。関係者に対して、定期的に報告をし、また一定の節目を迎えたり状況が変わったりしたときに状況を知らせておけば、この問題を緩和することができる。

7．ビジネス上の優先順位を無視する

開発を進めている組織内でのプロジェクトの優先順位と、全体的なビジネスの観点から見たプロジェクトの優先順位、そして開発を要求している側から見たプロジェクトの優先順位の間には、大きなギャップがあることが多い。よくある問題は、ある部門にとって「優先順位の高い」プロジェクトが、収益を生まないためビジネスの観点からは重要視されず、このため開発者もそのプロジェクトの優先順位を下げてしまうというものだ。全員の優先順位が一致している必要があり、そのためには、ビジネス全体から見て優先順位が低いと見なされているプロジェクトを元に、事業部門が評価されないということを保証する必要がある。

8．手続きによる壁を作る

開発チームが追い詰められていると感じる場合、それに対する自然な反応の1つは、物事のスピードを落とすために、多くの手続きを作ることだ。わたしはどんな簡単な変更でも変更申請書（もちろん紙で）を3通作成して稟議にかけ、関係するマネージャーのサインを集める必要があり、その上で作業が終わるまでに最短で45日間かかるという職場で働いたことがある。言うまでもないが、この組織はビジネスでは「パートナー」や「仕事をするために重要な相手」と見られることはなく、コストセンターであると見なされ、そのように扱われた。手続きによる壁は、手続きの中にあるより根が深い問題や、企業文化の問題に対処するための対症療法であり、壁を作ることはそういった問題そのものを解決するよりも簡単だが（一部の企業では、問題が解決不可能な場合もある）、手続きによる壁を作ることは非生産的であり、敵意に満ちた環境につながる。

9．「すぐに本格的な作業を始められる」という神話

プロジェクトに人を増やす時には、すぐに本格的な活動を開始できると仮定しがちだ。ソフトウェア開発の世界にはすぐに本格的な作業を始められるということはあり得ないし、そういう発言をする人は間違っている。すべてのプロジェクトには順応期間があり、プロジェクトが大きくなるほど順応期間も長くなる。これは、あらかじめ理解し、掌握しなければならないコードの量が多くなるからだ。これを計算に入れるのを忘れると、大きなトラブルになる。プロジェクトの初期にはこれに数日から数週間しかかからないかもしれないが、プロジェクトが始まって長い時間経ってから参加した開発者が生産性を完全に発揮するには、何カ月もかかる可能性がある。

10．マルチタスク

これも、多くの人が自分が持っていると考えているが、本当には持っていない「スキル」の1つだ（「すぐに本格的な活動を始める」スキルと同じように）。マルチタスクを要求すればするほど、仕事の質は落ち、時間もかかるようになる。これは、数分単位のマルチタスク（電子メール、電話、実際の仕事などを切り替える）にも、数時間から数日単位のマルチタスク（複数のプロジェクトを処理する）にも当てはまる。人材に対して多くを要求するほど、歯車の狂いは大きくなる。さらに悪いことに、マルチタスクは仕事をダメにしがちなだけでなく、人間を押しつぶし、最終的にその人は他の仕事を探し始めることになる。その結果、プロジェクトの最中に新しい人材を迎え入れざるをえなくなり、さらに問題は大きくなってしまう。

中國游客日本購物風向大變，不再狂購

來源：山田太郎，優樂福環球事業公司社長

“最近，到日本來的中國富人們購物越來越少。這是因為已經膩煩了日本的商品？還是說中國人的愛好變了？”

　　因東日本大地震和核輻射問題而銳減的赴日中國游客數量似在漸漸回升。抵達大阪參觀USJ（日本環球影城），看富士山后住宿箱根，來到東京最后在秋葉原購物。這種日本游的老套路如今還依然健在。東京的主要百貨商場和零售店都能刷銀聯卡，售貨員對使用中文收貨也是熱心不已。

　　然而，據說現在無論哪家商店都不如以往那樣生意好做了。半年前，筆者曾經接待過一個來自中國的日本訪問團，這個團的團員們都財大氣粗，一聊到誰購物曾經花了100萬日元，就爭相表示“那我花200萬”，“我花300萬”，金額水漲船高。這個團還有這樣一件奇聞。他們中的一位在成田機場打開皮包接受安檢時，在皮包里發現了兩捆1000萬日元的鈔票。聽到海關人員說“100萬日元以上禁止攜帶入境，如果沒有申報要處以罰款”，對方竟然放出豪言，“給我留下10萬日元回家，剩下的就算捐給日本政府了”。

　　當然，中國人并不全都如此。常有人說中國“貧富差距正在擴大，尤其是地方群體事件頻發”。在有如此巨大貧富差距的中國，此前曾有極其便宜和極其昂貴的商品必須一應俱全，否則就做不成買賣的說法。以此為出發點考慮問題的日本商人為了向中國的富人推銷產品而絞盡腦汁，挑選商品。

　　但時至今日，風向似乎發生了變化。5月赴日的訪問團的購物金額竟然少了兩位數。團員們只花了幾萬日元就滿意而歸。不買東西，在盡情品味、了解日本的風土人情后踏上歸途。與之前可謂相差迥異。

　　這樣的訪問團并非特例。進入2012年后，面向中國人銷售商品的工作人員都一致證實“富裕層的消費動態發生了變化”。“從這兒到這兒我都要了，給我來100萬日元的”中國式購物已不見了蹤影。

　　有報道稱中國經濟已經迎來了“泡沫破裂”的局面，經濟狀況發生了巨大變化。倘若果真如此，購物金額將受到巨大影響。然而，身處中國的筆者卻還沒有感覺到泡沫破裂這一嚴重局面的到來。中國沿海地區老百姓的生活看起來反倒比日本更加富裕。開著私家車周末住市中心酒店，年輕男女穿著時髦。他們并非富豪，而是中等收入階層。這些人群如今已經過上了富裕的生活。

　　順便一提，在上海周邊，大學畢業白領的平均起薪約為5000元。但上海的物價高。貴的商品價格甚至與日本不相上下。在上海，星巴克隨處可見，價格與日本并無兩樣。牛肉飯甚至還是日本更便宜。在中國沿海地區，如此高價的商品十分暢銷。5000元的工資如何能過上奢侈的生活，這種現象令筆者百思不解。

　　這其中的蹊蹺似乎在于政府統計。日本人在市場研究中經常使用公共機構的統計數字。但中國人的實際收入與政府的統計數值存在出入。實際上可支配收入其實遠高于統計數值。

　　首先，副業收入多。有的人除了白天上班，晚上還會做其他的兼職。因為雙職工普遍，家庭收入應該是兩人合計。而且，客戶會給回扣，政府官員家屬因為有關系而會有人上貢的灰色臨時收入，再加上父母還有贊助。因為實施獨生子女政策，年輕夫婦往往兩人都是獨生子女。雙方的父母和祖父母都會給予他們經濟上的幫助。

　　既然有了這么多收入，公共費用和基本生活費也就不在話下。如上所述，星巴克之類的個人喜好的商品雖然價格高，但交通費、水電費非常低。大致為地鐵起價3元，出租車12元，電費1個月大約400～500元，燃氣費40元，水費30元。房租方面，2LDK的高級公寓為1萬元，一般住宅區約為3000元。不太講究的話，午飯只要10塊錢就能搞定。

　　而且在中國，白領的薪水漲得非常快。應屆畢業生1年升主任，3～5年升經理，不到10年就能升到部長或是更高的職位。如果30歲當上經理，月薪就能達到2萬元～3萬元。如果按家庭來看，雙職工的收入還要翻番。家庭收入甚至比有的日本家庭還要多。

　　升職快的一個原因是因文革影響，45歲～50來歲的資深人士極少。因此，中國企業的高管人才梯隊畸形，董事要么是60歲以上，要么是30來歲的情況十分常見。這些30來歲的人被稱為80后，其中不少是曾在美國等海外留學的海歸。

　　而且，中國還獨有一種現象：35歲之后，獨立心旺盛的年輕人都紛紛獨立創業。40來歲還在公司上班反而會讓人懷疑沒能力。這都源于無論企業大小，是“老板”就受尊敬的風氣。其實，希望當上老板，過上富裕生活的中國年輕人比比皆是。這些人構成了相對富裕的中等收入階層。

　　地震后，赴日旅游的中國人的主角似乎從富人變成了中等收入階層。除了中間層崛起的原因外，富人已經基本上都到過日本了也是原因之一。

　　中等收入階層過著副業收入和可支配收入豐厚的富裕生活，但他們并不打算在日本鋪張浪費撐面子。是一群根據自己的生活方式享受購物樂趣的聰明消費者。

　　豪華高價商品不愁賣的時代也許已經終結。面對新的消費主體——中等收入階層，日本人應該做些什么、賣些什么？如今或許已經到了拋棄過去的成功經驗，從頭開始重新思考的時候了。

************************
中国人観光客の買い物戦線に異常あり

「最近、来日する中国人富裕層の方々がとんと買ってくれなくなったんです。もう、日本の商品に飽きてしまったのでしょうか。それとも、中国人の好みが変わってしまったのでしょうか」

　東日本大地震と放射能問題で激減した日本への中国人観光客も徐々にその数は回復してきているようだ。大阪に着いてUSJ（ユニバーサル・スタジオ・ジャパン）を見学し、富士山を見て箱根に泊まり、東京にやって来て秋葉原で最後のお買いもの。そんな定番コースは今も健在だ。東京の主だったデパートや小売店は銀聯カードに対応しており、販売員は中国語での売り込みに余念がない。

　しかし、以前のようにはどの店も売れないという。半年前、私は中国からのある日本訪問団を受け入れたのだが、このメンバーみなかなりの金持ちで、誰かが100万円の買い物をしたという話になったら、では自分は200万、それなら私は300万円と、金額はどんどん上昇していった。こんな逸話もある。彼らの仲間が成田空港で鞄を開けたら1000万円の束が2つも見つかった。税関職員に「100万円以上の国内持ち込みは違反、申告をしないと罰金だ」と指摘されたら、「帰れなくなるので10万円は残して欲しいけど、後は日本政府に寄付します」と言い放ったという。

　もちろん、中国人がみなそうだというわけではない。中国では「貧富の差が拡大し、特に地方において暴動が頻発している」と言われている。温家宝首相もそのことに触れ、初めて「このままでいくと文化大革命のようなことが起こる」と発言した。「文革」という言葉は長い間、中国ではタブーとされてきたが、それを引き合いに出さなければならないほど貧富格差の問題は深刻なのである。

　こうした貧富の差があるため中国では、極端に安いものか極端に高価なものを扱わないと商売が成り立たないというのがこれまでの定説であった。これをベースとして日本の商売人たちは、中国の富裕層にモノを売り込むために知恵を絞り、商品を仕込んできた。

　ところがここにきて、風向きが変わってきたようだ。先月来日した訪問団の買い物の金額は、ケタが２ケタも違う。数万単位の買い物をして満足しているのだ。モノは買わず、しっかりと日本を観光し、勉強して帰っていった。えらい変わり様である。

　このグループが特殊だというわけではないようだ。今年に入ってから「富裕層の動向が変わってきた」と中国人向けに商品を販売しているスタッフたちは口をそろえて証言する。中国式の「ここからここまで全部で100万円分ください」といった買い方をする人をとんと見なくなったというのだ。

　中国経済は「バブル崩壊」の局面を迎え、経済状況がかなり変わってきたとの報道がある。そうであれば、それが買い物の金額に大きく影響を及ぼしていると考えられる。けれど中国での状況をみる限り、バブル崩壊といった深刻な局面を迎えているようには感じられない。中国の沿岸部の庶民の生活はむしろ日本より豊かに見える。車を持って週末は都心のホテルを利用し、若い男女は大いに着飾っている。彼らはいわゆる富裕層ではなく、中間層。こうした層の人達が豊かさを謳歌し始めている。

　ちなみに、大卒のホワイトカラーの平均初任給は上海近辺では約5000元（６万円）である。しかし、上海の物価は高い。高いものは、ほぼ日本と変わらない価格で売られている。上海でもスターバックスがあちらこちらにできたが、日本の値段とほぼ変わらない。牛丼に至っては、日本の方が安いなどという状況だ。中国沿岸部では、そんな高いものが飛ぶように売れている。5000元の給料でどうしてこのような暮らしができるのか、かなり不思議である。
　そのからくりは、どうも政府統計にあるようだ。日本人はマーケティングリサーチに公的機関の統計数字をよく利用する。しかし、中国人の収入は、統計数値とはあまり合致していない。実際には、統計の数値よりかなり可処分所得が多いのだ。

　まず、副収入が多い。昼間の商売とは別に夜は別のバイトにいそしむ。夫婦は共稼ぎが当たり前だから、世帯収入は男性の稼ぎの倍と考えなくてはならない。さらに、得意先からのキックバック、政府関係者に親戚がいれば口利き料などの臨時収入があり、さらには親のスネもかじる。一人っ子政策によって、若い夫婦の二人共が一人っ子である場合が多い。こうした夫婦をそれぞれの両親、祖父母が経済的に支援しているわけだ。

　これだけ収入がありながら、公共料金や基本の生活費はかなり安い。先に取り上げたようにスターバックスのような嗜好品は高いのだが、その他の交通費、光熱費は非常に安い。地下鉄は、初乗り3元（36円）、タクシーは12元（144円）、電気代は1カ月約400～500元（約6000円）、ガス代は40元（480円）、水道代は30元（360円）といったところだ。家賃は、2LDKマンションで1万元（12万円）、団地だと3000元（3.6万円）程度である。安く済ませば、昼飯は10元（120円）で十分食べることができる。

　しかも中国では、ホワイトカラーは非常に昇給が早い。新卒から1年で主任、3～5年もたてば課長（マネジャー）、10年もしないうちに部長かそれ以上ということになる。30歳で課長以上になれば、月給は2万元（24万円）～3万元（36万円）になる。世帯でみれば、共稼ぎで収入はその倍。日本の世帯より収入が多かったりするのである。

　出世が早い理由の一つは、文革で極端に40歳代後半から50歳代の働き手が少ないということだ。だから、中国企業の役員構成はどこもイビツで、役員は60歳以上、そうでなければ30歳代というケースが多い。こうした30歳代は80后と呼ばれ、米国など海外に留学していた海亀族（帰国組）が多い。

　30歳代後半になってくると独立心旺盛な若者がどんどん独立して起業するという中国ならではの実態もある。40歳代で会社勤めというと逆に実力がないのでないのか、と疑われてしまう。どんなに小さな企業であっても「老板（ラオバン・経営者）」であれば尊敬される、という風潮があるためである。実際、老板として豊かな生活を目指す中国の若者が多い。こうした人たちが、豊かな中間層なのである。

　震災後に来日する中国人の主役は、富裕層に代わりこの中間層の人たちになってきているようだ。中間層が豊かになったことに加え、富裕層の来日はすでに一巡してしまったということもあるだろう。

　こうした中間層の人たちは、副収入や可処分所得が多いから豊かな生活をしている。けれど、日本で無駄遣いをしてまで面子を張ろうとは考えていない。自分たちのライフスタイルに合わせて買い物を楽しむ賢い消費者層なのだ。

　豪華な高額商品を並べておけば買ってもらえる時代は終わったと考えるべきなのだろう。新たな消費の担い手である中間層の人たちを相手に日本人は何をすべきか、何を売るべきかを、過去の成功体験を捨て、一から考え直す時期にきているのかもしれない。