What Does It Mean to Succeed in Global Organizations — Rethinking Talent in the Age of AI and Cultural Differences

When people hear the term “global talent,” they often picture someone who is fluent in English, has international experience, and possesses strong technical skills.

These qualities certainly matter. However, after many years working in global organizations, I have repeatedly seen situations where they were not enough to be effective in critical moments.

Some individuals are technically excellent and communicate well in English, yet struggle to earn trust when stakes are high. Others may not have perfect English or the latest skills, but are consistently relied upon in global environments.

What creates this difference?

Much of what follows is written from the perspective of working in and with global organizations from outside the English-speaking world.

How the Age of AI Has Changed Assumptions About Global Talent

Advances in AI and machine translation have significantly lowered the barriers to working in English. Tasks such as reading documents or drafting messages, which once required a high level of language proficiency, can now be strongly supported by tools.

As a result, the statement “I can’t work globally because my English isn’t strong enough” has become far less convincing than it once was.

At least when it comes to understanding information and organizing thoughts, AI has become a powerful assistant.

What AI cannot do alone is decide who takes responsibility when interpretations are contested or outcomes are unclear.

AI can help organize information and support decision-making,
but it cannot determine context or take responsibility for the consequences of those decisions.

The Same Behavior Can Be Evaluated Very Differently Across Cultures

Another critical perspective is how behavior is perceived across cultures, particularly how people in Japan are often seen within global organizations.

A useful framework for understanding this is “The Culture Map” by Erin Meyer, which compares cultures across dimensions such as communication, feedback, decision-making, and trust.

Viewed through this lens, Japanese organizations and individuals are often perceived as:

• High-context communicators who rely heavily on shared assumptions
• Indirect in feedback, avoiding open confrontation
• Consensus-driven in decision-making, which takes time
• Reluctant to surface failure or uncertainty openly

Within Japan, these traits frequently function as strengths, supporting stability, trust, and long-term relationships.

From the perspective of global organizations that value speed and clear accountability, however, the same behaviors may be interpreted as:

• Unclear ownership
• Lack of visible decisions
• Decisions being deferred

The key point is not which approach is right or wrong. The same behavior can look very different depending on cultural context.

It is worth adding one important clarification here.

The Culture Map framework is extremely useful for understanding how Japanese professionals may be perceived in global settings.

However, this does not mean that only Japanese employees are expected to adapt.

In reality, global organizations are made up of people from many cultural backgrounds—across Asia, Europe, and the Americas—who are all adjusting aspects of their natural working styles.

Even employees who are not Japanese often need to make conscious efforts to align with headquarters culture, decision-making norms, and communication styles.

This adaptation is not unique to any one country or region.

Working in a global organization does not mean that one culture is inherently correct.

It means that everyone, in some way, is operating outside their cultural comfort zone and taking on a certain amount of adjustment as part of the work.

These cultural dynamics influence how value is perceived,
but they are not the only forces reshaping expectations in the modern workplace.
Another important shift to consider is how employment structures themselves have evolved.

Changes in Employment Structures in the IT Industry

Another important shift that should not be overlooked is the change in employment structures within the IT industry.

In recent years, layoffs have become less of a temporary or cyclical event and more of a structural reality.

This does not mean layoffs are good or bad; rather, the metric by which individuals are valued has shifted toward decision-making under uncertainty.

Many organizations are no longer optimizing for scale or headcount growth, but for operating with leaner teams.

In this environment, market value is less about how busy someone appears to be.

It is increasingly shaped by how individuals operate under uncertainty—how they make decisions, and how those decisions are treated and carried forward within the organization.

This is not meant to create fear or anxiety.

Rather, it reflects a shift toward greater transparency in how value is assessed.

An Era Where Judgments Are Evaluated Before They Are Recovered

In these moments, what is often missing is a clear link between decision assumptions, individual ownership, and organizational responsibility.

Social media has fundamentally changed the conditions under which decisions are made and evaluated.

Once that happens, evaluation tends to happen first, while context follows—if it follows at all.

Organizations need a way to articulate assumptions, ownership, and responsibility, and to recover decisions rather than abandon them.

What Is Ultimately Expected Is the Ability to Take Responsibility

What differentiates people in global organizations is not skill alone, but whether they are willing and able to take responsibility.

Language skills and technical expertise are important, but they are not sufficient by themselves.

What truly matters is whether someone can:

• Identify what the real problem is
• Clarify the scope of their responsibility
• Step forward and take responsibility for the outcome

Being effective in global organizations ultimately requires the willingness to take responsibility, even when situations are ambiguous or uncomfortable.

What is being asked today is not being carried by the wave of change.

It is the ability to keep judgment moving when assumptions shift, and to continue forward rather than stopping in uncertainty.

What Escalation Really Means - Lessons from Global Cloud Support Operations

In global cloud support organizations, the word escalation is used almost daily.

In simple terms, escalation means “raising an issue to a higher level.”

In reality, however, escalation is far more than a technical handoff.

From my experience working in post-sales and support leadership roles across Japan and APAC, I've found that escalation often reflects people, expectations, and organizational dynamics, not just technology.

Escalations Often Start with Emotion

Many escalations are triggered not by technology alone, but by emotions such as:

• Anxiety
• Urgency
• Frustration
• Misaligned expectations

When a customer asks for an escalation, they are often saying:

“I’m not confident that the current response will resolve my problem.”

Understanding this emotional context is critical to handling escalations professionally.

A Common Misconception: “Just Escalate to HQ”

A phrase frequently heard in support organizations is:

“Let’s escalate this to HQ, and they’ll fix it.”

In practice, poorly prepared escalations often slow resolution rather than accelerate it.

What senior engineers or executives typically need is not:

• Raw technical detail alone
• Emotional urgency
• Severity labels without context

What they do need is:

• Clear customer impact
• Business and operational risk
• Well-structured decision points

Effective Escalation Is Not Translation — It Is Structuring

The role of escalation management is not to simply pass messages upward.

The real value lies in structuring the situation clearly:

• What exactly is happening?
• Why is this a problem?
• What business or operational functions are blocked?
• What decision or action is being requested?

An escalation leader acts as a bridge, not a messenger.

Storytelling Drives Action

Logs, metrics, and error messages are important — but they rarely drive decisions on their own.

What accelerates action is context, for example:

• How many customers are affected
• What operations are stopped
• Time sensitivity and constraints
• Availability of workarounds

People respond faster to a clear story than to raw data.

Effective escalation is the ability to translate technical reality into a narrative that both technical and executive stakeholders can understand.

The Real Difference Appears After Resolution

How an organization behaves after an escalation is resolved reveals its maturity.

High-performing teams:

• Thank contributors across teams
• Share lessons learned
• Improve processes and documentation

Escalations should not be treated as failures, but as inputs for organizational learning.

Conclusion: Escalation Reflects Organizational Strength

Organizations that handle escalations well tend to share common traits:

• Strong customer trust
• Healthy internal communication
• Clear ownership and accountability

Rather than fearing escalation, teams should ask:

“Are we capable of handling escalation well?”

Properly executing escalation without fear is a sign of a resilient and mature organization.

エスカレーションとは何か 〜外資系クラウドサポートの現場から〜

外資系クラウドベンダーでサポートやポストセールスに関わっていると、「エスカレーション」という言葉を日常的に使う機会があります。

英語の escalation は単に「上位へ引き上げる」「報告する」という意味ですが、現場では 技術的な対応以上の意味を持つことが多いと感じます。

エスカレーションは感情から始まる

多くのエスカレーションは、純粋に技術課題だけが原因で発生するわけではなく、

• 不安
• 焦り
• 怒り
• 期待値のズレ

といった感情の動きが絡んで始まります。

特に顧客が「エスカレーションしてほしい」と言うときには、

「現状の対応では安心できない」というシグナルが含まれていることがよくあります。

よくある誤解：「HQに投げれば解決する」

現場でよく見かけるのが、

とりあえず英語で本社(HQ)にエスカレーションすれば何とかなる

という考え方です。

しかし実際には、情報が整理されていないエスカレーションほど、解決までの時間が長くなることが多いです。

 HQや上位エンジニアが必要としているのは、

• 事象そのものよりも「顧客への影響」
• 技術的詳細よりも「ビジネスリスク」
• 感情よりも「判断に必要な材料」

といった、緊急度合いの判断に直結する情報です。

良いエスカレーションとは「翻訳」ではなく「構造化」

エスカレーション対応で真に重要なのは、単に顧客の声を上位にそのまま伝えることではありません。

価値を生み出すのは、以下を明確に整理して伝えることです。

• 何が起きているのか
• なぜ問題なのか
• 何が止まっているのか
• 何を判断してほしいのか

この段階でのプロセスが、エスカレーションを単なる手続きから**価値ある行為へと変えていきます。

エスカレーション担当の役割は、「伝言係」ではなく 橋渡し役なのです。

ストーリーがあると、組織は動く

単なるエラーログやビジネスの数字の羅列だけでは、意思決定を促すことは難しいです。

• 影響を受けている顧客数
• 業務停止の内容
• 時間的制約
• 代替手段の有無

このような情報が整理されていれば、グローバルチームの判断は劇的に早くなります。無機的な情報よりも、臨場感のあるストーリーの方が人を動かします。

技術的な事象を“理解されやすい形”に組み直すことこそ、エスカレーションの本質です。

エスカレーション後にこそ差が出る

エスカレーションが解決した後のアクションによって、次のエスカレーションの質に差が出ます。

次のような活動が、組織全体の成熟度を高めるからです。

• 関係者への感謝
• 学びの共有
• プロセスの見直し

エスカレーションは「失敗」や「問題処理」ではなく、組織が成熟するための材料として活用できます。

まとめ：エスカレーションは組織力の鏡

良いエスカレーション対応ができている組織には、共通点があります。

• 顧客との信頼関係が強い
• 内部コミュニケーションが健全
• 役割と責任が明確

我々は、エスカレーションを恐れずに、正しく扱える組織であるかが問われているのです。

極楽エスカレーションのススメ 外資系クラウドベンダー編

前書き

この記事は、外資系クラウドベンダーの中の立場で書いています。実際、社内配信した記事を一部変更した内容です。ユーザの方々にも、我々がこんな苦労をしていると知っていただけると幸いです。

そもそもクラウドベンダーにおけるエスカレーションって何？

「またお客様に怒られちゃったよ。エスカレーションしなきゃ。気が重いなー」
そう、嫌ですよねエスカレーション。そもそも、なんでエスカレーションするの？いや、そもそも、エスカレーションって何でしたっけ？

ウィキペディアを見てみると、こんな風に書いてあります。
エスカレーション（英語:Escalation）とは、業務において、上長の指示を仰いだり、業務を引き継がせること。略語はエスカレまたはエスカ
原義は「上申」や「深刻化」であり、日本語では、「上申」とまで言うと大袈裟な、業務上日常的に発生する、上長への報連相といった意味で使われている。
そうでしたっけ？何か違いますよね。

何故、お客様は、エスカレーションさせたがるんでしょうか？
　それを受けて本社の運用部門や開発部門に情報を求めても、そんな事を要求してくるのは一部のお客様だけだと言われ、下手をするとお客様の期待値コントロールが出来ていないと怒られてしまうことも多々あります。外資系の場合、本社は強い。なかなか日本の言う事を聞いてくれないのですよ。
　でも、お客様だって困っているんです。だって、上司や他の部署、もしくは本社から同じ事を言われているんです。
想像するに、こんな会話がどこかで行われているかもしれません。
「XXXの動きが悪いから納期が遅れる？冗談じゃない。早急に本社にエスカレーションさせて開発責任者に問題の重要さを伝えて貰え！」
　ここで期待値のずれが発生します。お客様は、会社（本社）の上層部に問題の大きさを伝えれば、全ての物事が早く進むものと思いがちです。でも、本当にそれで早まるんでしたっけ？本当は、現場は怠けているわけじゃなくて一生懸命やっているんです。そこに、上から「日本から、君たちの動きが悪いし対応が悪いから、お客様が怒っているって言われているけど、本当にそうなのか？」と言われちゃう。そこで産まれる日本への悪感情。最悪です。じゃあ、どうすれば、上手くエスカレーションして本社を動かすことが出来るんでしょうか？

感情というやっかいな生き物

さて、少し時間を戻しましょう。
お客様に怒られてエスカレーションしろと言われた時、我々にどういう感情が生まれますか？
気持ちよく、「はい！分かりました！」となる方は、よほど大人か、状況が分かっていないか、どちらかだと思います。
ここで、少し豆知識を。
キュープラー・ロスの喪失の5段階というのはご存じでしょうか？
元々は死の受容時の感情の動きを表したものなのですが、これをベースにショッキングな事が起きた時の心理変化に置き換えて説明する事も多いらしいです。
その5段階は、大体、以下のような感じです。

第１段階：否定
　「そんなことは起こらないから大丈夫」と自分に言い聞かせる
第２段階：怒り
　`本当に変化が起きたことに対して怒りを感じる
第３段階：分析
　これから起こる変化を予測し、対応について考えを巡らす
第４段階：受容する努力
　現実として受け止め、適応することを試みる
第５段階：コミットメントの成長
　変化の良い点を見出し、前向きになる

　完全に合致はしないかも知れませんが、お客様に厳しく言われた時には、第一段階から第二段階に近い感情が生まれているはずです。ですので、その感情を持ったままエスカレーションに望むのではなく、自分の感情をできる限り早く第三段階に進めるのが重要ですね。エスカレーションで怒りをぶつけてしまうのは御法度です。

エスカレーションには何が必要なのか？

「さて、感情も収まったし、早速エスカレーションだ。
　お客様の売り上げを書いて、どれだけ営業損失があるかを訴えなきゃ」

ちょっと待った。それだけで本当に大丈夫ですか？
何か忘れていませんか？
本社開発部門の優先順位を上げるためには、カスタマーシナリオが必要です。
では、カスタマーシナリオって何でしょうか？

・お客様は何を困っているのか？
・何故、この問題がお客様にとって重要なのか？
・これをやらないことで、お客様と我々に、どのような不利益が生じるのか？
・あるいは、やったことで、何が解決して、どのようなメリットがあるのか？

「そう言われてもちゃんと書いてますよ。この問題が解決しないと1千万円の損失ですもの」
違います。それはカスタマーシナリオではありません。
何故損失になるのか？その理由と背景にあるストーリーをしっかりと伝える努力をしましょう。
お客様が困っている姿をビジュアルで想像出来るようなストーリーになってますか？
開発部門が、「確かに、それは困るよね」と言ってくれるような内容になってますか？
そこを意識したカスタマーストーリーを伝えるだけで、エスカレーションの結果は変わってくるはずです。

エスカレーションの結果、お客様が納得する対応が出来たけど、それで終わりだっけ？

やっと終わった。これで一安心。日本のチームの皆さんありがとうございます。サポートも営業も頑張ったね。
何か忘れてませんか？その感謝、グローバルの人達にも伝えてますか？
ぜひ、問題が片付いてほっとした後に、協力してくれたグローバルの人達にも感謝を伝えて下さい。
それによって、次回のエスカレーションでのグローバルの対応も変わってくるはずです。One Teamってそういう事ですよね。

まだまだ伝えたい事は沢山ありますが、本日はここまで。
ただでさえ辛くて大変なエスカレーションですから、ここは楽しむつもりで、チーム一丸となって頑張って行きましょう。

AIに支配された明るい未来を考えてみた

　柔らかな朝の日差しが部屋をつつんでいる。そろそろ起きる時間だ。

　鳥のさえずりと川のせせらぎをBGMに目覚めると、バーチャルスクリーンに睡眠指数を表示してみる。睡眠の評価は良好のようだ。ただ、お勧めの睡眠環境が追加されている。予想値として、睡眠の質が５％アップするらしい。試してみるか。

　次に、朝食のお勧めから和朝食を選び、３０分後のデリバリーを予約する。塩分少なめオプションをお勧めされていたが、今日は良いだろう。残念ながらカロリーオーバーのメニューは選べないので、少し運動を増やしてみるか。

　朝食が来るまで、少しランニングマシンで走りながら、今日の過ごし方のダッシュボードを眺めていく。

　今、登録している仕事はメインが５つ、ボランティアが３つ、そして、趣味が７つある。それ以外にも、スキル習得中の仕事が３つある。もちろん、何もせずにゆっくり過ごすオプションも選べる。

　どうしようかな。午前中は、都市環境プログラムの追加機能を考えて、午後は料理メニューの試作をやってみよう。

　今の世の中では、生活の改善や娯楽などの新しいアイデアを出す事が人間の仕事になっている。生活に必要な製造やメンテナンス、修理まで全て自動化されており、農作物や工業製品、食事や娯楽品まで、好きな物が選べるようになっている。もちろんお金はかからない。そもそも、お金という概念がないのである。また、所有という概念もないので、使い終わったら返すだけである。消耗品も自動的に補充される。

　朝食を食べ終わったので、仕事に出かける事にする。どこのオフィスにしようかな。

　歯磨きやシャワーは寝ている間に済ましているので、お勧めの服装から適当なものを選んで着替える。出勤の手段も、運動量に応じて好きな方法を選べるけれど、今日は自動車で渋谷オフィス行くことにする。オフィスといっても、会社のオフィスではない。そもそも会社という概念がないので、仕事場と言った方が良いかもしれない。

　自動車は文字通りオートパイロットでどこでも連れて行ってくれる。到着するまで今日のニュースをチェックする。

　オフィスに到着して適当な部屋に入ると、予め設定してあった自分のオフィス環境が適用される。机のレイアウトや壁の色、それ以外も全て再現されるので、いつも通りの落ち着いたオフィスになる。ただ、今日は少し気分を変えて、窓の大きさを変えてみるか。

　バーチャル会議室に入ると、チームメイト達が既に集まっていた。もちろんVRなので、世界中のオフィスから繋いでいる。

　「やあ、すぐる。今日は渋谷からか。窓から見えるスクランブル交差点だが、誰も居ないみたいだな」

　「マーク、おはよう。今日は自宅からか。歴史的なシンボルみたいな物だから、来るのは観光客ぐらいだね。人混みとか渋滞とか、懐かしいよ」

「そういえば、地球環境や温暖化のデータを解析予想して、使用エネルギーを最適化するってプロジェクト、うまく行ってるのか？」

「最適化の対象を、どこまで増やすかが難しくてね。牛のげっぷを入れるかどうかで議論が分かれてるよ」

「そこは最適化じゃなくて、げっぷを空気中に拡散させない方法を考えた方がいいんじゃないか？」

「なるほどな。検討してみるよ」

そんな話をしながら、アイデアをコンソールに打ち込んで行く。明日になれば、解析結果と推奨値が得られるはずだ。効果がありそうだったら、実施検討に進めれば良い。後は、ボランティアの投票で実施するかどうか決まる。仕事をしていない人たちも、殆ど、このボランティア投票には参加している。

　仕事をしていると、息子からメッセージが届いた。

　そろそろ仕事が出来る年になるので、何かスキルを習得しているようだ。最初は仕事をしなくても良いと思っていたようだが、お勧めの仕事からやりたい物が見つかったらしい。

　そういえば、スキルアッププログラムのアイデアを出すという仕事もあったな。それも面白そうだな。仕事の候補に入れておこう。おっと、そういえば、息子の誕生日が近いのを忘れていたな。さて、どうしようか。

　この時代では好きな物が手に入るので、みんな物欲がない。なので、むしろプレゼントの選択には悩むのである。必然的に芸術的な物が多くなる。

　そうだな。オリジナルの映画を１本作ってプレゼントするか。

　早速、ストーリーや配役を考える。俳優もスケジュールが空いていれば、選びたい放題である。脚本家はAIか人かを選べるが、今回は時間が無いのでAIで我慢するか。大体のイメージを考えて発注すると、納期は２日後と出た。やれやれ、なんとか間に合いそうだ。

　「おーい。誰かランチに行かないか？」

　渋谷オフィス内の知り合いがランチ仲間を探しているようだ。今日はVRの同僚じゃなくて、彼と一緒にランチにするか。

　４人の仲間とレストランスペースに行って席を作ってもらう。席を探す必要はない。人数に合わせて勝手に席が出来上がる。

　さて、今日はどこの店にしようかな。

　レストランスペースには、世界中のレストランのメニューが揃っている。なので、選んで待つだけである。合成しているわけではない。食材が常にストックされており、レストランスペース間で共有・管理されているのである。

「そういえば、先週、ターミネータ１８を観に行ったよ。これが傑作でね」

「へー、どんな内容なの？」

「なんと、ランボーがサプライズゲストで出てきて、最後にターミネーターと戦うんだ。でも、ランボーも実はターミネーターで、殴り合いの後に仲間だと気がついて友情が生まれるんだ。感動したよ」

「なんだそりゃ」

　そんな話をしながらランチを済ませてオフィスに戻ると、そこでは、予想も出来ない大変な事態が起きていた。

　多分、続く・・・かな？

できるエンジニア 実践 企業が欲しがる人材とは

出来るエンジニアってどんな人？

「だから結局、できるやつは何でもできるし、できないやつは何にもできないってだけの話だろ」

　映画 「桐島、部活やめるってよ」の有名な台詞の引用ですが、自分が出来ると思っている奴は時として残酷な事を言うわけですね。しかし、宏樹君。それでは、あなたはプロにはなれないですよ。実際、器用貧乏だし、やりたい事も見つかっていないじゃない。

　え？映画見てないから分からない？そりゃそうですね。

　では、某SNSにも書きましたが、私が欲しいエンジニアは、

「どこかにスクラッチからの開発が出来て目を見張るような技術センスとスキルがあって市場のトレンドをしっかりと追いつつ自分の意見もあって日本語と英語のコミュニケーションスキルが高くグローバルでも戦えててエンジニアとしての向上心があってチームワークの重要性が分かっていて謙虚だけれどプライドもあって上とぶつかる事を恐れずに改革を起こせてカリスマ性があってプリセールス、ポストセールスのビジネスと会社の求める物を理解して後輩の育成も出来て自分のキャリアの方向性もしっかり持っていてユーモアや皮肉も理解して人としても尊敬出来る人格で新しい働き方にチャレンジ出来て会社のレッテルに依存しないで将来的にはリーダーやマネージメントの業務にも臆せずに挑戦したいと考えていて楽しく仕事が出来るエンジニアは居ないだろうか。」

　嘘です。

　いや、半分本気ですが、なかなか居ないって、そんな人。

　では、何が重要なのか、と言うと、ずばり「ポテンシャル」、日本語で言うところの「将来性」なのです。

　でも、その話を深掘りする前に・・・

エンジニアの悩みあるある

・会社の方針やマネージャの変更により評価やキャリアが変わってしまう。

・エンジニアのキャリアが不透明。マネージャになる以外のキャリアパスって無いの？

・シニアなエンジニアが何も教えてくれない。怖い、偉そう、話しかけ辛い、忙しそう、いつもイライラしている。

 ・マネージャに技術的な事やトラブルを相談しても、何もアドバイスをくれない。もしかして、理解していないのでは・・・

・忙しすぎる、燃え尽きそう、でも、振る先も居ない。マネージャに相談したら謝られた。更にしつこく苦情を言ったら怒られた。

・なんだか自分ばっかり大変な仕事をやっている気がする。でも、マネージャは簡単な仕事を沢山やっているエンジニアがお気に入りみたい。

・お客様や営業の言うことばっかり聞いちゃって、全部、エンジニアにしわ寄せじゃん。

・残業もダメで休日出勤もするなって、働き方改革の前に仕事量を減らしてくれ。

・会社の決めたゴールって数字ばっかりじゃん。それを達成する事だけが目標になってないかな。

　あー、やんなっちゃったな。そういえば、友達が転職した会社でエンジニアを募集してたな。そっちに行っちゃおうかな。

　まあ、それも良いでしょう。

　でもね、その時、マネージャはどんな風に考えているんでしょうかね。

マネージャの悩みあるある

・どうやっても人が足りない。でも、経費削減で採用を止められちゃったよ。

・優秀な人材が欲しいけど、なかなか良い人が応募して来ないよ。

・エンジニアのモチベーションを上げるため、キャリアモデルを作らないと人が辞めて行っちゃうよ。自分が成長したと感じて貰うにはどうすれば良いかな。

・プロモーションや昇給させてあげたいけど、枠が少なすぎるよ。

・また上から数字目標が下りて来たよ。これを達成しないと、余計な仕事が増えそうだな。

・みんな働き過ぎだから、休ませてあげたいな。でも、不公平にならないようにしないと。

・シニアなエンジニアは扱いづらいな。なかなか言う事をきいてくれないし、理屈っぽくて苦手なんだよね。でも、うまくコミュニケーションを取って、きちんと機会を与えないと。

・今日のみんなの体調やメンタルの調子はどうかな。心配な人には積極的に話しかけて様子を見てみよう。

・お客様や営業の要求事項、ほとんど跳ね返したけど、これだけは無理だったな。

・上の言う働き方改革、いいんだけど、本当に現場の事分かって言ってるのかな。

書き過ぎましたかね。

当然、誇張してますし、実際にはこんなに酷くは無いと信じたい。

ここで言いたいのは、何も愚痴を並べて頭を前に振らせる事ではありません。気がつきましたよね。

ここで重要なのは「すれ違い」です。

ちゃんとチームや業務を改善するために、エンジニアとマネージャも協業しなきゃ。

One teamって何？

  　じゃあ、マネージャやメンバーの空気を読んで、チームの勝利のために全力で戦えばいいんでしょ？それがOne teamだよね。

　残念。ちょっと違う。

　では、以前、某社でシニアなエンジニア達だけのチームをマネージしていた事があるんですが、そこで決めた行動規範を一部紹介しましょう。

（当時の社内用語は、別の用語に変更しています）

エンジニア同士での協業と教育

・前向きにエンジニア同士で協業・教育に取り組んでいるか？

・その時のコミュニケーション時の態度は適切か？

・協業・教育のタイミング、内容に問題はないか？

・スムーズな協業・教育に向けて、常に改善を心がけて取り込んでいるか？

・協業・教育の際に、問題の解決やお客様を意識しているか？

ホット案件、困難な案件の対応

・ホットな案件や困難な案件に積極的に関与しているか？

・エスカレーション案件に積極的に関与しているか？

・困難な問題を解決に導く役割を意識しているか？

・困難な問題を自分で抱え込まずに周囲と協力していく姿勢があるか？

・まわりの困難な問題を助けていこうという姿勢が見られるか？

本社関連部門へのリクエスト・フィードバック

・本社関連部署と良好な関係を築いているか？

・前向きに本社関連部署との交渉を行っているか？

・本社関連部署へのリクエストのタイミング・内容に問題はないか？

・本社関連部署とのやり取りを遅延なく適切に行っているか？

コミュニケーション

・お客様とのコミュニケーションに問題はないか？

・エンジニア同士のコミュニケーションに問題はないか？

・マネージャ、リーダーとのコミュニケーションに問題はないか？

・サービス部門とのコミュニケーションに問題はないか？

・他製品部門もしくは他チームとのコミュニケーションに問題はないか？

・きちんと自分の意見を周りに伝え、なおかつ人の意見を聞くことが出来ているか？

デベロップメント

・自分の技術力やスキル・知識、英語力を高める努力を怠らずに継続しているか？

・他のエンジニアの技術力やスキル・知識を高めるために努力しているか？

 ここで重要視しているのは、自分の強みを生かし、誰とでも良好な関係を築き上げ、どこからでも学び合い、高め合う事です。そして、結果的に、自分の市場価値が上がっていく。もしかすると、職場環境だってマネージャと一緒になって改善出来るかもしれません。

　つまり、大事なのはポテンシャル＝どこからでも、何からでも、誰からでも吸収して成長して行く、そういう事だと思うんですよね。

　もちろん、上司や企業によって色々な考え方や意見がありますので、これが全てではありません。でも、悪い考え方では無いと思いませんか？

　ちなみに、こんな話をアメリカ人の今の上司にしたところ、「それはスポンジだね」と言っておりました。それを聞いて、スポンジボブのTVアニメが大好きなビショップ博士*1を思い出したのは秘密です。

*1:何を言っているか分からない人は、アメリカのテレビ番組「フリンジ」を見るように。今をときめくスターウォーズ監督のJJエイブラムスが製作総指揮しているシリーズですよ。

相手が唸る障害報告とは？

何故報告書が必要なのか？

　公開されている情報だけでは、どうにも収まらない報告書。

　何故、お客様は、そんなに細かい部分を気にして知りたがるんでしょうか？

　運用部門や開発部門に情報を求めても、そんな事を要求してくるのは一部のお客様だけだと言われ、下手をするとお客様の期待値コントロールが出来ていないと怒られてしまうこともありますよね。

　でも、お客様だって困っているんです。だって、誰かに報告しなきゃいけないんだもの。

　そう。ほとんどの場合、報告書は更に報告されて行くのです。

　報告書をお客様に渡した後、どこでどんな風に使われているのか考えてみましょう。

　相手の報告先を想定しておくと、良い報告書のイメージが掴みやすいです。

主要な3つのポイント

1.　結局何が問題だったのか？（バグ？プロセス？オペミス？）

2.　何に対して謝るのか？（出来ていなかった事は何？）

3.　本来あるべき姿は何なのか？（短期、長期の再発防止策）

報告書のコツ

1. 報告書は最短で結論が分かる様に書く。ほとんどの人は詳細は読まない。
2. 項目分け、箇条書きの有効活用。
3. 書かなくて良いことは書かない。報告書7割、口頭3割
4. 報告書のレビューの仕方。何も知らない人が理解出来る事が重要。
5. 内容だけではなく、文節の順番、長さ、見やすさ、も見直そう。

　　内容を知らない第3者にレビューして貰おう！

 

報告会ってなんでやるの？

　障害や不具合が発生すると、お客様だって不安なのです。

　この製品・サービスは継続して安心して使えるんだろうか？せっかく社内を説得して採用したのに、もしかして、選定に誤ったかも？

　こんなお客様の不安を払拭し、安心して製品・サービスを継続して使って貰いたいですよね。

　でも、お客様は怒っているし、また怒らせたらどうしよう。

　報告会は不安なのは当たり前。誰でも緊張します。

では、平常心を保つには？

• 　　とにかくビビらない。
• 　　お客様への承認欲求を断つ。（認められたい、気に入られたいという気持ちは、一時的にストップ。正確に正しい事を伝える方が大事です）
• 　　お客様のキーパーソンを見極める　　
• 　　場の空気を支配する。お客様のペースに乗りすぎない。

話し方や全体の流れの注意事項

• お客様の前で報告書は読み上げない。顔を伏せない。自分の言葉で説明しよう。（なので、内容を頭に入れておくのです）
• 人は緊張すると早口で単調な口調になる。「言いたい事を伝えなければ」、と焦らない。
• 自分で読んで分からない事は、お客様も分からない。なるべく簡単な言葉で報告する。
• 必ず要所要所で、お客様の疑問点を確認する。
• プレッシャーで長時間沈黙してはいけない。
• お客様のご意見を聞く姿勢で。そこから可能なアクションを提案して行く。
• 出来ない事を約束してはいけない。

何故どなられ続けるのか、叱られるのか？

　なぜでしょうね。

　でも、そんな時、自分が悪いわけじゃないのに、早く逃げたい、終わらせたい、と思ってませんか？

　その気持ち、お客様に見えてます。

　人間には弱い者を攻撃する本能がある。表情や声のトーンで弱みを見せない。

• 怒りが続いて終わらない場合、言いたい事を理解した事を伝えて話を終わらせる。

「申し訳ございません。xx様のおっしゃる通りです。そこは私としても弊社の課題だと考えております」「はい。その通りです」等々、合いの手を入れて、きちんと理解している事をお客様にもしっかり伝える。

• お客様の話を遮らずに、伝えたい事をしっかり伝えよう。「xx様の仰るように」という枕詞は効果的
• お客様の言葉を捉えて、リピートして話しを繋げる。
• お客様を飽きさせない。手を使う、立つ、指さす、ホワイトボードを使う、質問してみる。
• 「すみません、申し訳ございません」、よりも、「有り難うございます」が有効。謝るだけじゃなくて、フィードバックに感謝しよう。

報告会は終わったけど、それで終わりだっけ？

言われた事やご要望は議事録に残し、必ずその日のうちにメールで出す。

メリット：

•   記憶の新しいうちに合意した内容を明記する
•   会議の内容の主導権を握る
•   言った、言わない問題の防止

電話で話して合意した内容も、必ずメールや文章に残して共有する

いや、大変でしたね。

でも、こんな時に、お客様が頼れるのは製品やサービスの提供者だけなのです。

お客様の立場の方にも、我々が日々どんな事を考えているかを知って頂けると嬉しいです。