投稿

3月, 2021の投稿を表示しています

結論はCoffee Breakで決まる!?

英語ができない私がグローバル人材!? や 標準化仕様③について でも説明したように、グローバルでの仕事の進め方はビジネス性のカードを利用した交渉と、会議での合意、そして最終生産物であるドキュメントが、基本的な進め方となる。これは標準化でも、その他のビジネスでも大きな違いはないだろう。実は海外の仕事の進め方でも、結局は会議の場以外(オフライン)でのネゴシエーションで議論が進む。 日本の会議との違い 最終的には企業毎に文化が違うためお付き合いする企業や団体に合わせることにはなるが、それでも日本の会議と典型的に違う点があるように感じる。 大人数での参加は好まれない → 意思決定できる人間のみが参加する 資料を見れば分かるような、ただの説明やレポートはあまり会議で時間を割かない → 会議の目的/ゴールを明確にし、必ずその会議で結論を出す 議論用の資料で綺麗な絵を描いたりすると驚かれる → 自分が出す資料はそのままでも良いかもしれない ただし、相手の資料は議論用の資料(簡易&最低限)と、最終生産物(分かり易い&綺麗)は明らかに品質が異なるため、それを理解して議論した方が良い 会議での議論対象 OR 資料配布のみは、議論ポイントの難易度ではなく、本人のモチベーション → Visionや要件の説明は拙い英語でも本人の言葉で話すようにする(資料を配るだけは嫌われる) 逆に難しい議論であったとしても、その議論ポイントの背景や目的をちゃんと理解して貰えると、その意見自体は別途提示されることが多い いくつかの企業や団体と話をしてきて、この辺は根本的な考え方の違いを感じた。 結局交渉はいつするのか? 日本の会議に比べると、先に会議で議論をし見解の相違部分を明確化しておくケースが多いように感じるが、結局のところ交渉はオフライン(会議以外の場)で行うことに変わりはない。日本の飲み会やゴルフ相当が、海外だとCoffee Breakのように感じる。Coffee Breakでは、ビジネス的な交渉が行われ、ここで結論が出されることが多い。 Coffee Breakで、背景を説明したり、妥協ポイントを探ったり、別のビジネスでの取引をしたりすることになる。ここでは比較的本音の議論や意見交換が行われるように感じる。そして最終的には、会議で合意事項を合同で説明することになる。 勿論、Coffee ...

標準化仕様について③「標準化のプロセス」

ETSI  NFV  ISGの標準仕様は、どれが基本仕様でどれが必須のAPIかなどの濃淡は言及されないことが多い。その背景について、標準化の進め方を踏まえながら説明する。 合議制 標準化は基本的に合議制が採用されている。特にETSIの場合、参加者は会社の代表として扱われ、各提案は全員一致制での採決となる。そのため、反対者が1人でもいると提案は承認されず、議長からは「Are there any comments or question?」→「Are there any objection?」→「Approved」という流れで採決を取られる。 言い方を変えれば、サイレント(発言なし)は賛成という意味になる。そのため、採決時に発言をせずに承認された場合、それは賛成しているということになり、その提案をひっくり返すことは大変難しくなる。 他団体ではVote(投票)によって決めるところもあり合議のレベルは団体毎に異なるが、基本的には標準化団体は合議制が取られている。一方で、Open  Sourceの場合はソースコード(Code)をレビューしたReviewerがGoodを付与してN Good以上であればCodeを本体にMergeされるということが多い。 Work Item(WI)と標準化ドキュメント 標準化の場合、多くの場合最終生産物は標準仕様というドキュメントであり、そのドキュメントを作成するための活動がWIと呼ばれる。WIには、そのWIのリーダー(ドキュメントの場合は編集者(Rapporteur))が立候補制で選ばれ、リーダーはドキュメントの作成計画をたて、各社が提案しやすい環境を作り、承認された提案をドキュメントに反映するという作業を行う。 ETSIの場合は、4社以上の参加企業が合同(Supporting  Company)でWIの提案を行い、Supporting CompanyからRapporteurが選ばれる。WIが承認されると、提案者(Contributor)が該当ドキュメントに仕様として記載したい提案(Contribution)を持ち寄り、標準化メンバーで議論して承認を行う。承認(Approved)された提案はそのままドキュメントに反映され、反対によって否決(Noted)または取下(Withdrawn)されるとその提案は破棄され...

標準化仕様について②「NFV仕様の応用例の紹介」

前回はETSI  NFV  ISGの仕様の読み方について説明した。今回はその続きで、NFV仕様の応用例を紹介する。  ネットワークの仮想化に追加で求められていること MANOという新しい機能が提供されることで、更なる運用の改善が検討されている。これらはETSI NFV ISGでは Feature と呼ばれFEAT[通番]として管理されている。2021年3月時点で26のFeatureが定義されているが、基本仕様からの応用的な利用という観点からは以下に分類できるだろう。 MANOによる既存業務の改善:MANOのカバー機能の拡張、自動化促進 装置がソフトウェア化されたことによる機能拡張:VNFの更新 新技術との融合:現在標準化中(今後の期待) NFV仕様の応用 携帯電話のネットワークを構成する交換機や基地局の専用装置部分を仮想化技術によってエミュレートしたVNFのVNF LCMを基本仕様としつつ、NFV仕様は幾つかの応用的な機能を提供している。 MANOのカバー機能拡張 VNFのカタログ管理:VNF Package Management (NFV-SOL 005) 故障管理:Fault  Management 処理量(トラヒック)管理:Performance Management VNF間の接続管理:Network Service (NFV-SOL 005) VNFのバックアップ管理:VNF Snapshot Management、VNF Snapshot Package  Management VNFの更新 VNFのHardware構成変更:Change VNF Flavour VNFの接続Network変更:Change external VNF connectivity VNFの後継機へマイグレーション:Change current VNF Package (Rel3機能) VNFのConfiguration変更:Modify VNF info 自動化促進 自動処理ロジックの管理:Policy Management (Rel3機能 NFV-SOL 012) MANO自体のOperation Annd Management:MANO OAM (Rel3機能 NFV-SOL 009) 標準化は様々な企業や国がそれぞれの要件...

標準化仕様について①「基本仕様の見分け方」

少し前から、通信の世界では仮想化がトレンドになってきており、 総務省のWhite Paper を見ても、5G以降の世界ではクラウドネイティブ、 仮想化 、AIが主要技術と位置づけられている。本日はグローバルで通信の仮想化を推進している標準化団体である ETSI NFV について紹介したい。 通信の仮想化 CMでお馴染みの 楽天 をはじめ、 ドコモ 、 au  、 Softbank と全モバイル事業社が仮想化を謳っている。共通していることは、専用装置から脱却し汎用サーバを利用することである。元々携帯電話のネットワークは、携帯電話と電波で通信する 基地局 、通信の回線を接続する 回線交換機 、そしてそれらを結ぶ 伝送路 で構成されており、基地局と交換機は専用装置を利用している。これらの基地局や交換機を仮想化技術によりエミュレートすることで、物理装置に依存せず携帯電話のネットワークを提供できるようにすることが通信の仮想化である。 物理装置非依存になることで、物理装置はクラウドデータセンタで利用されているような安価な汎用サーバを利用できるようになり、装置単価の削減と運用の簡易化が期待できる。一方で、専用装置をソフトウェアでエミュレートしているので専用装置より性能や信頼性で問題が出る可能性がある。この仮想化の効果を高めつつ、仮想化の弱点を補完する仕組みがNetwork Function Virtualization(NFV)であり、このNFVの仕様を策定・推進している組織がETSI NFV ISGである。 ETSI NFV ISGの基本仕様 ETSI NFV ISGのサイトにも記載されている通り、ETSI NFV ISGの ドキュメント は100を超えており、この全容を理解することは非常に大変な作業である。ETSI NFV ISGの仕様(NFV仕様)入門としてはETSI NFV ISG 副議長の中島氏の 講演資料 が分かりやすいだろう。 NFV仕様は、専用装置に対して人手で行われていた設置〜修理〜廃棄の一連の作業(ライフサイクル)をVirtual Network  Function Lifecycle  Management (VNF LCM)と呼んでAPI化することをコンセプトとしている。VNF LCMを実現するためには、仮想化技術によってエミュ...

英語ができない私がグローバル人材!?

 TOIEC300点台の私が、突然海外の企業とお付き合いしたり、国際標準化団体で活動することになった。グローバル化に伴い、国内だけで完結する仕事は少なくなっているのかもしれない。このブログでは、英語のできない私が、海外の方とお仕事する姿を紹介し、グローバル人材とは何か、今後どのようなスキルが求められているのかを考えていきたい。 通訳がいても海外の人と会話ができない!? 海外の方にプレゼンして、会話ができずに戸惑った人は少ないと思う。私は英語が苦手だったので、始めから会話が成立するはずもないと思っていたが、どうやら原因は英語のスキルだけではなかった。そもそも考え方が違うようだ。 詳細の積み上げ→結論(日本人) vs 全体概念→具体例(海外) 主語の省略(日本語) vs 主語の明示(英語) ○✖️ or OK/NGによる比較表 vs 議論ポイントのみ記載 順番に説明すると、私はとある仕様追加の議論のために、海外の方と議論することになった。そこで私は丁寧に資料を作り、通訳さんに翻訳して貰って会議に臨んだ。しかし、結果は「合意どころか、議論が始まりもしなかった」。 私は、現在の仕様の技術的な課題(Problems)と、その解決策(Solutions)を丁寧に説明する資料を作った。しかし、海外の方は、背景(Rational / Background)と、議論の範囲(Scope)、この会議後のアウトプット(Goal  / Decesion  Points)の説明を求めた。海外では、背景や文化、目的が異なることは当たり前なので、Background → Goal → 今日のScopeの説明が先にないと、議論すらして貰えないのだ。私はこれ以降、自己紹介、自社のビジネス上で問題となっている背景(Background)、本日の会議のGoalとNext Stepを最初に記載するよう心がけるようにしている。 次の問題は主語の問題だ。日本は多くの場合、主語を省略できる。例えば、“X装置がBに対してAという処理をする“、という場合、日本語は“BはAによって処理される“と書いてしまい、X装置が抜けてしまう。これを通訳さんに英語にしてもらうと、X装置が無いので英語化できない。その結果、実は自分の意図と全く異なる仕様を説明する仕様になっていたようだ。通訳さんによってはそれ...