2013年IT業界のトレンドキーワードとして注目を浴びている”DevOps”ですが、これをテーマにしているカンファレンスが存在します。その名を”DEVOPS DAYS”といいます。DEVOPS DAYSは世界中で開催されている有志の団体であり、DevOpsを実践している企業の担当者が事例紹介を行います。

実はこのカンファレンス、先月、日本で開催されました。それが”DevOps Day Tokyo 2013”です。今回は日本国内の事例としてクックパッドのシステム運用が取り上げられました。

要点は以下の通り。

【要旨】
・承認フローを作るとOpsが権威的になってDevのやる気が損なわれる。
  -> 開発者のオーナーシップが減退する
  -> 承認を通すための政治が重要になってしまう

・Opsにとっての「完璧さ」ではなくBizから見た「健全さ」を志向する。
  -> 開発初期からBizにとって最適なやり方をDevとOpsが議論する
  -> 問題が発生しても速やかに対処できる方策を考えておく

・Ops担当もDev担当と同程度のソースコード読解力が必要になる。
  -> DevとOpsが相談しながらチューニングできる体制を敷く
  -> Dev担当をOps担当へシフトさせる

 (補足)
・クックパッドではエンジニアが約60人。
  -> 運用:Opsとして、インフラチームが5人
  -> 開発:Devとして、アプリ開発チームが40人、技術部エンジニアが12人

・デプロイは以下のルールに従って行われる。
  -> 開発者自身がデプロイ&動作確認を行い、不具合があれば即ロールバック
  -> 営業時間のみデプロイ可能(深夜リリースは基本的になし)

 ※プレゼン内容はPublic Keyが詳しく取り上げられています。
http://www.publickey1.jp/blog/13/devopsdevops_day_tokyo_2013_2.html

 

私がこのエントリーで触れておきたいのは、「開発担当と運用担当の新陳代謝」です。

 多くのIT部門では、開発部門よりも運用部門の方が低い地位に甘んじています。その理由は、開発部門の方が高スキル人材が多いからです。過去の経験則ですが、両者の能力を比べれば、こんな傾向がみられるものと思われます。

 【技術知識】 : 開発担当 > 運用担当
 【自己主張】 : 開発担当 > 運用担当

 システムの維持管理業務をこなすだけなら、アプリの詳しい知識を持たずとも十分です。しかし、開発を行うなら、自分がコードを書けなければなりませんから、より多くの技術知識が求められます。それに伴い、知らないことを学ぶ積極的な姿勢を開発担当は身につけるようになり、コミュニケーション面でも差が出てきます。

これでは相対的に開発部門の発言力が増すのも当然です。その結果、開発部門の判断で運用方法も決まってしまうという状況が当たり前になり、運用部門は単にシステムの維持管理をするだけになってしまうわけです。

こうした事態を防ぐために、クックパッドでは開発担当を運用担当へシフトさせることを行っています。そうすることで、開発側につっこみを入れられる運用体制を作ることに成功しています。事例では読み取れませんでしたが、同じように、運用担当を開発側へシフトさせることで、運用を意識した開発体制を構築することができますね。

このやり方を大規模なシステム開発・運用の現場で実践するのは難しい場面もあると思います。障害が組織や社会的混乱につながるミッションクリティカルなシステムは手堅い承認フローを導入した方が、Bizにとって健全です。

しかし、そうしたシステムは世の中、思ったよりも多くありません。基幹系を除くシステムなら、クックパッドが実践しているスタイルもアリではないかと思います。もちろん、向こう1週間くらいのリリーススケジュールはBiz-Dev-Opsの間で共有される連絡会や情報共有ツールが必要ですけどね。

ちなみに私のこれまでの経験の中で最もうまく廻っていたIT組織は、Dev-Opsに加えてTestという組織を切り出し、Dev→Test→Opsという3グループをシフトしながらITスタッフの能力を高めていくやり方を実践していました。

中規模以上のシステムでは、結合テスト~総合テスト用の専門部隊を作ってテストフェーズを進めるやり方が一般的かと思いますが、だからこそ、DevとTestの組織は明確に分けた上で、スタッフを定期的に他グループへシフトさせて経験を積ませるという行為が、各グループの相互理解を高めることに有用でした。

いずれにせよ、開発側と運用側の新陳代謝を促す仕組みを設けることは、お互いが尊重し合って協働するDevOpsにとって大変重要であるということは明白でしょう。

------------------------------

【DevOpsが変える開発と運用[#0]】 DevOpsではなく、TechOpsでIT運用管理を変える

【DevOpsが変える開発と運用[#1]】 DevOpsは開発と運用の分離と対立するのか?

【DevOpsが変える開発と運用[#2]】 開発と運用のコラボレーションはそこにあるか:日本CAの提案

NAKA

DevOpsが運用と開発の関係性を「対立」から「協調」へ促すものであることは[#1]のエントリーで分かりました。しかし、内部統制の強化に端を発したこの対立路線を解消する手立てはあるのでしょうか。

これについて、ITサービス管理製品を数多く提供している日本CAのプリンシパル・コンサルタントの方が夏サミ2013でプレゼンした資料から、いくつかの示唆を得ることができます。

『【夏サミ2013】4つの視点から読み解くDevOpsにおける改善活動のポイント 』
http://codezine.jp/article/detail/7349

プレゼンの中で、DevOpsという言葉の定義が人によって異なっている点が触れられていたので、そこから主要リサーチ機関である2社の表現を抜粋します。

■フォレスターリサーチの定義
「アプリケーション開発、インフラ、運用、品質管理を担当するIT部門間において一緒になりコミュニケーションをとり、コラボレーションや統合することでより目的にあったタイムリーなソフトウェアやサービスを生むための一連プロセスや手法、システムである。」

■ガートナーの定義
「クラウドサービスから始まったもので、オンラインビジネスの増加により、運用チームと開発チームがコラボレーションすることで、効率性を向上させることに着目した概念である。」

フォレスターは具体的な方法であると考えているのに対して、ガートナーは概念だと捉えているのは、対比として面白いです。一方で、両者が共通して述べているのは、「開発と運用のコラボレーションがそこにあること」です。つまり、人によって枝葉の違いはあるとしても、本質的に、開発と運用の協調路線に舵を取っていれば、そこにDevOpsが求められてくるのです。

しかし、このコラボレーションが難しい。たとえばプレゼン資料には、開発と運用の対立を示す簡単なイメージが示されていました。

開発側:「本当にうちのアプリが原因?」
運用側:「障害発生、協力してよ」

開発側:「開発環境で再現するまで待って」
運用側:「早く修正してよ」

開発側:「頼んだリリース、早くやってよ」
運用側:「リリース以外にも作業が山積みだよ」

開発側:「本番環境の設定を教えて」
運用側:「また?このあいだ教えてじゃん」

開発側:「本番環境へのアクセス制限多すぎ」
運用側:「間違いが起きてからじゃ遅いんだよ」

ほとんどの人が身に覚えのあるやりとりじゃないでしょうか?こうしたことの積み重ねによって、開発の人は運用の人に頼みごとをしづらくなるし、運用の人は開発の人からの問い合わせが自分の仕事を増やすだけだと不毛に感じてしまう傾向が高まります。

では、DevOpsがうまく実践されている開発と運用の現場はどのようなコラボレーションがなされるようになるのでしょうか。プレゼン資料には以下の参考例が挙げられています。

開発側:「うちが原因かもしれないからすぐ調べるね」
運用側:「障害発生、そっちが原因かもしれない」

開発側:「原因が分かったからリリース手順を自動化したよ」
運用側:「こっちの手間を減らしてくれてありがとう」

開発側:「本番環境の設定を確認する仕組みを用意したよ」
運用側:「似たような問い合わせが減って助かるよ」

開発側:「本番環境へのアクセス申請も自動化したよ」
運用側:「決められたルールに基づくアクセスだから安心だね」

こうしたやりとりを現実にするために日本CAが示したキーワードが「ゼロタッチ・デプロイメント」、すなわち、人手を極力介さないリリース管理プロセスです。

数年前にランブックオートメーションという運用業務の自動化ソリューションが登場し、仮想化製品が当たり前になった現在ではプロビジョニング(システムリソースの動的割り当て)も実装例を見かけるようになっています。これをもう一歩推し進めるゼロタッチ・デプロイメントでは、アプリテストの最適環境、つまり本番と同等だと感じさせる環境を開発サイドに構築することを提唱しています。

冒頭のリンク先記事に書かれているこれらのことは、15年以上前にオブジェクト指向言語のJavaがWebシステムの構築用途で広まった頃の登場技術を私に思い出させます。

例えば、リリース手順の自動化については、当時からAntを使うことで、リポジトリに格納されたリソースをベースに開発→本番環境のオートデプロイを実現できていました。外部システムと連携する分散システムは、インターフェース先の挙動を模して動くスタブクラスを設けることで、試験スケジュールの柔軟性を確保していました。

これらのソリューションがクラウドソリューション向けに焼き直しされているように見えるのは、DevOpsの必要性をもっとも強く感じているのが、この界隈の人たちだからなのかもしれません。

DevOpsを実現するためには、そのオペレーションを支えるツールの存在が大変重要です。今後、ITサービス管理製品を取り扱うベンダーからは、ますます関連製品が登場することでしょう。今回は日本CAを取り上げましたが、他のベンダー製品についても見ていこうと思います。

------------------------------

【DevOpsが変える開発と運用[#0]】 DevOpsではなく、TechOpsでIT運用管理を変える

【DevOpsが変える開発と運用[#1]】 DevOpsは開発と運用の分離と対立するのか?

NAKA

一時期は下火になっていましたが、ここ1、2年でDevOps(デブオプス)というキーワードが再び聞かれるようになってきたように思えます。このブログでも、5カ月前に関連するエントリーを投稿しています。

『DevOpsではなく、TechOpsでIT運用管理を変える』
http://blogs.itmedia.co.jp/infra/2013/04/tech-8307.html

ITmedia系列のTech Targetでは、DevOpsというキーワードをこんな言葉で紹介されていました。

『「DevOps」という言葉が注目を集めている。一言でいえば「Dev(開発担当者)とOps(運用担当者)が連携してサービスのリリースサイクルを速める」といった概念だ。この言葉が企業の関心を集める背景には市場競争の激化があるといわれている。』
http://techtarget.itmedia.co.jp/tt/news/1306/28/news05.html

この説明文を見る限りでは、昨今の加速するIT開発事情が背景にあるように読み取れます。たしかにガートナーのハイプサイクルによれば、2011年版の段階でクラウド関連技術における黎明期技術で登場しており、2012年版でもまだ黎明期に位置づけられていますね。

http://blog.discountasp.net/the-cloud-2012-gartner-hype-cycle-update/
Gartner Hype Cycle for Cloud Computing 2012

これだけを見ると最近の流行のように思えますが、「DevOps」が初めて登場したのは、私の知る限り、実は4年前の2009年にまで遡ることができます。

『10+ Deploys Per Day: Dev and Ops Cooperation at Flickr』
http://www.youtube.com/watch?v=LdOe18KhtT4

DevOpsが提唱され始めた頃は、開発部門と運用部門の対立が激化していたように思えます。開発部門はリリースにかける手間を極力減らしたいと考えますが、運用部門は本番環境の安定を守るための手順を順守するよう求めます。時にスケジュールがひっ迫している状況では、この類の姿勢の違いは組織間の争いに発展するものであり、開発部門と運用部門が殺伐とした企業も珍しくありませんでした。

例えば、既存システムの追加機能に関するカットオーバーが寸前に迫っているのにバグが収束しないという状況であったとして、開発部門は少しでも多くのバグフィックスをするために本番環境上で開発者が作業することを求めるでしょう。しかし、運用部門としては、安定稼働している既存機能への影響を加味して、あらかじめテスト環境で検証済みの手順でしか作業してはいけないとの姿勢を示したとします。少しでも時間の惜しい開発部門にとっては、「そんなルールでやっていたらバグが収束する前にカットオーバーを迎えてしまう!」と憤りを覚える人が出てくるでしょう。こうしたことが積み重なると、双方部門の仲は着実に悪化します。

なぜ開発と運用の現場が争うようになってしまったのか、その根源を考えると、2002年のSOX法に端を発する内部統制の強化が一因にあるということに同意する人は多いと思います。なにせ、内部統制では、不正な本番環境への変更を抑止するために、開発担当と運用担当を明確に区分することが望ましいとしているのですから、必然的に組織も分かれて、双方が自組織の立ち位置でしかモノゴトを考えない傾向が強まってしまいます。

ですが、開発と運用を分離させることは、性悪説に耐えるIT管理を可能とする内部統制の観点から死守すべきものです。これを否定してしまうということは、性善説によるIT管理しかできなかった20世紀の混沌期にまで退行することになりかねません。

はたして、内部統制を維持したままで開発と運用が協力する体制を確立することはできるのでしょうか。その答えがDevOpsというキーワードにあります。ひとまず、具体的なソリューションに触れているリンクをこの場で紹介しておきます。

http://www.atmarkit.co.jp/ait/articles/1309/18/news008.html
http://codezine.jp/article/detail/7349
http://www.infoq.com/jp/news/2013/05/integrate-devops-itil

今後、DevOpsを理解し、実践するための情報をシリーズとして扱っていこうと思います。

------------------------------

【DevOpsが変える開発と運用[#0]】 DevOpsではなく、TechOpsでIT運用管理を変える

NAKA

8/2(金)のウォールストリートジャーナルにて、『日本の株・外為投資家が身構える「ジブリの呪い」』というエントリーが話題になっていましたが、どうやら今回のラピュタもその法則に当てはまってしまったようです。

以下のリンク先は日経の円ドル為替レート表なのですが、日本時間8/2(金)21時30分から、無慈悲なほどのドル暴落が発生しています。なんと、 たった15分で99.94円→98.91円になりました。一気に2円下がったわけです。朝9時から12時間かけて0.5円上がってきたところを、わずか 15分でその4倍下振れしました。

http://www.forexchannel.jp/%E7%82%BA%E6%9B%BF%E3%83%81%E3%83%A3%E3%83%BC%E3%83%88/USD/JPY_5min.html

Ws000002_2

その原因ですが、予想通り、7月の米雇用統計が市場予想を下回ってしまったからでした。

『2日朝方のニュー ヨーク外国為替市場で、円相場が対ドルで上昇に転じた。1ドル=99円台前半で推移している。午前8時半発表の7月の米雇用統計で、非農業部門の雇用者数 は前月比で16万2000人増だった。伸びが18万人程度との市場予想を下回り、緩和的な金融政策の正常化へ向けたハードルが高まったとの見方が浮上。円 相場は雇用統計発表直前には99円台後半で推移していたが、円買い・ドル売りが広がった。』
(日本経済新聞より)
http://www.nikkei.com/markets/kawase/summary.aspx?g=DGXNASFL020OC_02082013000000

なぜジブリ映画のタイミングで発表される政府統計は、ことごとく市場の期待を下回ってしまうのでしょうね。不思議です。

ちなみに、今回の「バルス」は23時22分45秒だそうです。Twitterのサーバは今回持ちこたえることができるでしょうか。LINEも狙われている模様ということで、インフラ担当者の方々は、期せずして負荷テストを経験することになりそうです。

NAKA

「TechOps(テックオプス)」という言葉を知っていますか?

おそらく、耳馴染みがない言葉じゃないかと思います。開発と運用の融合を目指したDevOps(デブオプス)なら知っている、という人はいるでしょう。

(参考:エンタープライズの世界にも「DevOps」は浸透するのか)
「DevOpsは、開発と運用を密に連携させるための手法や概念などを総称したもの。例えば、ソフトウェアの新機能や改修などの開発からリリースまでの期間を大幅に短縮し、サイクルを早く回すことで、ソフトウェア品質を向上させる、あるいは、エンドユーザーに対するサービスを強化するといった効果が挙げられる。」
http://www.itmedia.co.jp/enterprise/articles/1304/11/news012.html

TechOpsとはTechnical Operationsを省略した用語であり、日本語で表現するなら、技術運用と表現できるでしょう。これはIT部門の主要業務であって、ユーザーの依頼を受けて、システムリソースの割り当て変更や業務サポート、加えて業務システム自体の維持管理を含みます。ITILでいうなら、Service Operation(サービスオペレーション)中に行うアプリ・インフラ管理に係るプロセス群のあたりの話です。

TechOpsがうまくできていない組織は、トラブル発生時の損失が大きくなります。たとえば、ブラックベリーで有名なRIM社(現ブラックベリー社)は2011年10月にコアスイッチ障害によって世界中のユーザのメッセージングサービスが数日間使えなくなりました。その数週間後、バンクオブアメリカのウェブサイトは、世界的なDDoS攻撃を受けて全面ダウンしました。

一般論として、業種・業界に依らず、多くの組織でイベント管理と問題管理に改善の余地があります。特段の管理ルールも定められず、アドホックで属人的な対応に留まっているところが多数を占めているのが現状であり、昨今のITのトレンドを踏まえると、以下に挙げる観点は特に気を付けなければなりません。

  1. 仮想化拡大(Virtualization Expansion)
    ・仮想化の乱用による仮想サーバの無秩序な増大
    ・ライセンスやコンプライアンスへの注意不足によるトラブル
  2. パッチ管理(Patch Management)
    ・ネットワーク環境の複雑性増大によってHW、OS、アプリに対するパッチ適用頻度も増大
  3. クラウドコンピューティング(Cloud Computing)
    ・情報セキュリティとコンプライアンスへの取り組み
    ・キャパシティとエンドユーザーにフォーカスしたイベント管理に対する新しい取り組み
    ・リソース使用率の監視と課金ルールの構築
  4. データセンター内の密度(Datacenter Density)
    ・IT担当者とファシリティ担当者の十分ではないやりとり
    ・電力消費の増大と発熱量管理に係る手間の増大
    ・CPU利用増にともなうキャパシティ管理の重要性増大
  5. ビッグデータ
    ・IT環境の拡散によるデバイスや構成アイテム増加に対する効果的な管理
    ・業務側の要求に見合ったサポートを実現するインフラの構築
  6. パターン&アナリティクス
    ・アクション可能な情報やパターンを運用データから抽出・特定を行える分析が必要
    ・セルフラーニングのサポート、入手可能な情報の拡大のためにビッグデータの概念が必要
  7. IT要員体系の構築
    ・これまでの役割や運用スキルに置き換わるコモディティ化したITサービスが増加中
    ・TechOps、トレーニング/リクルーティングリソースのための新しいスキルセット定義

こういった重要点に対する有効手法は、端的に述べるなら、「ITシステムが抱えるデータの爆発的な増大に対して、IT組織が比例した形で工数・費用増大を招かないよう、運用保守業務の品質と効率を高めるプロセスやツールの導入に向けて考えなければいけないこと」という話です。今後のIT運用管理、保守管理において、以下に挙げる6点への取り組みを具体化することで、現在のIT運用保守のレベルが自然低下していくことを防ぐものになります。

  • DevOps
    →DevOps(デブオプス)は、開発組織と運用組織の間におけるコミュニケーション・コラボレーション・インテグレーションの規則・方法論・実践法のこと。
    →DevOpsは、減少するスコープ変更、増大する調整と自動化を通して、無駄が少なく責任感の強いチームを育てる。
  • IT Automation
    →自動化は、仮想化・クラウド環境の管理方法を変え、複雑な業務要求をサポートできる。
    →自動化は、データ統合とビッグデータ管理における重要な役割を果たす。
  • Capacity Optimization
    →キャパシティ最適化はROIとサービス品質の改善に向けた余地を識別する。
    →不必要なサービス、保守切れサーバ、SWの旧ライセンス、ストレージ不足の解消によるコスト抑制。
  • Monitoring Solutions
    →モニタリング アズ ア サービスとしてリモート監視を提供し、現地付帯業務としての監視を不要とする。
    →モニタリングサービスを提供するベンダーには社内の様々なコンポーネントにアクセスさせることもできるため、注意深くベンダーを選定する必要がある。
  • Predictive Analytics
    →データを統計的に分析し、将来のトレンド予測と傾向対策を行う。
    →大規模データ活用はモニタリングツールの今後に関する重要要素になる。
  • Vendor Optimization
    →サービスおよび提供ベンダーにおける統合によって、コスト抑制・ビジネスアジリティ向上、サービス品質の改善を促す。
    →複雑性と重要性に基づくサービスとアプリケーションの分類整理は、サービス要件の適切な定義を実現する。

文章で表現するとさらっと述べることができますが、これを具体的にどうやって取り組んでいけばいいのか、イメージすることは簡単ではありません。そこで、このエントリーでは、そのヒントとなるTechOpsを構成する技術要素ぐらいまでは触れておきます。(1)ITサービスを調達すること、(2)ITサービスの品質を保証すること、(3)ITサービスを運用すること、という3つの領域に分類した上で個々の施策に取り組むことになります。

●サービスフルフィルメント(Service Fulfillment)
・コネクティビティ・サービス(Connectivity Services)
・プロビジョニング(Provisioning)

▲サービスアシュアランス Service Assurance
・機器管理(Element Management)
・性能・可用性管理(Performance and Availability Mgmt)

■ITオペレーション IT Operations
・システム管理サービス(System Management Services)
・ストレージ管理サービス(Storage Management Services)
・アプリ技術サービス(Application Technical Services)
・バッチスケジュール管理(Batch Scheduling & Management)
・災害復旧(Disaster Recovery)
・ホストベース侵入検知・保護(Host based Intrusion Detection & Prevention)
・設備運用(Facilities Operations)

●&▲:
・クラウド管理(Cloud Management)

全共通:

・サービス導入(Service Introduction)
・自動化管理(Automation Management)
・ガバナンス(Governance)

それぞれを具体化するためのベンダー製品の組み合わせについては、まず自分がWeb上で情報を集めるところから始めてみることをお勧めします。人から与えられたものをそのまま鵜呑みするのではなく、情報を集める過程で、自組織の問題点・解決を急がなくても構わない点が見えてくるようになります。こういった領域はやりはじめると際限がありません。ベンダーやコンサルの活用範囲が最適になるよう、まずは自分自身が解決の方向性をイメージできるようになってから、外部にソリューションを求めるようにしましょう。

NAKA

皆さんの中にはご存知の方も多いかと思いますが、2011年10月にガートナーから「2012年に注目すべき10の戦略的テクノロジ」が発表されました。

今後3年間間の中長期戦略において、企業が影響を受ける可能性を持つテクノロジーを「戦略的テクノロジ」と定義し、ITやビジネスに革新的変化をもたらすものや、大規模な投資を要するもの、また導入しなければビジネス上のリスクが拡大するものなどがリストアップされています。

私の所属するアクセンチュアも「テクノロジートレンド」というものを毎年発表しており、2011年からの5年間は、データ・アナリティクス、センサーネットワーク、ソーシャルプラットフォーム、データプライバシー、それにユーザー・エクスペリエンスが注目に値するテクノロジーであると述べています。

http://www.accenture.com/us-en/technology/technology-labs/Pages/insight-accenture-technology-vision-2011.aspx

話を戻しましょう。
ガートナーが今回選んだ10の戦略的テクノロジは以下のものです。

【2012年に注目すべき技術】
http://www.gartner.co.jp/press/html/ref20111129-01.html

・メディア・タブレットと次世代型製品
・モバイル・セントリック・アプリケーションとインタフェース
・コンテキストとソーシャル・ユーザー・エクスペリエンス
・インターネット・オブ・シングス ※センサーNW
・アプリケーション・ストアとマーケットプレース
・次世代アナリティクス
・ビッグ・データ
・インメモリ・コンピューティング
・超低消費電力サーバ
・クラウド・コンピューティング

アクセンチュアが2011年に発表したテクノロジービジョンと半分は被りますが、さらにデータアナリティクスを意識した技術、たとえばビッグデータ、インターネット・オブ・シングス、大量データ処理を意識したインメモリ・コンピューティングがランクインしています。

現在の技術では、ビッグデータを蓄積することはできても、それを適切に分析できるモデル(ポリシー)やそれを(リアルタイムレベルで)処理するハードウェアは研究段階に留まっており、完全な商用化はされていません。それは、あのなんでもやってしまうGoogleがビッグデータ分析によるサービスを検索以外で打ち出せていないことが何よりの証左とも言えます。

これら技術が2012年にどう花開いていくのかは楽しみですが、一方で、過去に発表された「戦略的テクノロジ」はどうなったのでしょうか。気になってしまったので、過去にガートナーが発表した情報を探してみました。

すると、2008年末に「2009年の戦略的テクノロジ」を発表したのが一番最初であり、それまでガートナーはこういった情報を発表していなかったようです。ということで、2009年分~2011年分までを以下に列挙してみました。複数年に渡って登場している技術(類似を含む)は、一番最初に登場したものを★でマーキングしてみます。

【2011年に注目すべき技術】
http://www.gartner.co.jp/press/html/pr20101025-02.html

・クラウド・コンピューティング
・モバイル・アプリケーションおよびメディア・タブレット
・ソーシャル・コミュニケーションおよびコラボレーション
★ビデオ
・次世代型分析
・ソーシャル分析
★コンテキスト・アウェア・コンピューティング
・ストレージ・クラス・メモリ
・ユビキタス・コンピューティング
★ファブリック・ベースのインフラストラクチャおよびコンピュータ

【2010年に注目すべき技術】
http://www.gartner.co.jp/press/html/pr20091111-01.html

・クラウド・コンピューティング
★高度な分析
★クライアント・コンピューティング
・ITによるグリーン化
★データセンター再構築
・ソーシャル・コンピューティング
★セキュリティ - アクティビティ・モニタリング
★フラッシュ・メモリ
・可用性のための仮想化
★モバイル・アプリケーション

【2009年に注目すべき技術】
http://www.gartner.co.jp/press/html/pr20081027-01.html

★仮想化
★クラウド・コンピューティング
★サーバ (ブレードを超えたもの)
★Web指向アーキテクチャ (WOA)
★エンタプライズ・マッシュアップ
★「特化型」システム
★ソーシャル・ソフトウェアとソーシャル・ネットワーキング
★ユニファイド・コミュニケーション
★ビジネス・インテリジェンス (BI)
★グリーンIT

今見返してみると、2009年の注目技術で挙げられている内容が非常に懐かしく感じます。

グリーンITという言葉は途中で消えかけましたが、日本で起きた東日本大震災を機にまた存在感を増してきました。BIはBA(ビジネス・アナリティクス)に名前を変えています。ユニファイド・コミュニケーションは、マイクロソフトやCISCOの営業努力もあって、世の中にかなり浸透してきたと思います。エンタープライズ・マッシュアップ、WOAはクラウド・コンピューティングの中に取り込まれていった感じがします。「特化型」システムとサーバ(ブレードを超えたもの)は、大容量データ処理(インメモリ・コンピューティング)やセンサーネットワークという方面に発展しているのかなと思えます。ソーシャルなんたらは、まさにこのまま発展していると言えるでしょう。

過去の技術トレンドを遡って、皆さんは何か発見はありましたか?

NAKA

過去、世界の工場として飛躍的な発展を果たしてきた中国ですが、その一番の原動力はコスト優位性に他なりませんでした。圧倒的な人件費の安さに魅力を感じて、世界中の多くの企業が中国内に工場を設立していることは誰もが知っていることだと思います。

近年は、元の切り上げや頻繁な従業員の給与引き上げによって、コスト面での魅力が徐々に薄れつつあり、先にあげたコスト重視の企業は、人件費がまだ安価なベトナムやタイに生産拠点を移す動きをみせていますが、それでもまだ多くの企業は中国内での生産を続けています。

そんななか、週末に少し驚くニュースを目にしました。

『中国パソコン最大手のレノボ・グループのミルコ・ファン・ドュイル上席副社長は8日、読売新聞のインタビューに応じ、レノボブランドの日本市場向けパソコンの生産を、中国などから国内に切り替える検討を進めていることを明らかにした。

 生産効率化とブランド力強化を進め、国内シェア(市場占有率)3割を目指す。

 レノボは今年7月、NECとパソコンの合弁会社「レノボNECホールディングス」を設立。「ラヴィ」などNECブランドのパソコンは米沢事業場(山形県米沢市)で生産し、「シンクパッド」などレノボブランドは海外の企業に生産委託などをしている。

 ドュイル副社長は「消費者に近いところで生産することは重要」と述べ、今後は法人向けノート型パソコン「シンクパッド」や、個人向けノート型の「アイデアパッド」など、すべてのレノボブランドの商品を米沢事業場で生産することを検討する方針を表明した。』
http://www.yomiuri.co.jp/atmoney/news/20111210-OYT1T00166.htm

前述の文脈に沿って、単に欧米や日本のグローバル企業が生産拠点を変えたという話ではありません。私が驚いたのは次の2点です。

 #1.中国の生産拠点を「日本」の東北地区に移したこと
 #2.これはLenovoという中国PC大手企業が決断したということ

Lenovo(聯想)はPC事業をNECと一緒にやっているわけですが、中国企業が自国の生産拠点を捨てて、日本のモノづくり産地を選んだというのは、生産効率性(高度化)を高めることで中国国内の生産総コストよりも抑制できる見通しがあるからだと思われます。さらに、”MADE IN JAPAN”というブランドを活用して、セールスの拡大を狙いたいという思惑も、報道内容からは伺えます。

PCといえばIT産業の代表的な製品ですが、こういったレベルの製品については、中国国内で敢えて作らずとも、全体コスト(輸送費含めて)と品質(サプライチェーン上のリードタイムを含めて)の総体で考えれば、先進国の労務コストでも十分戦えるステージになってきたということですね。

NAKA

先日のエントリーにて、「iPad」という商標を中国本土で使ってはいけない、という判決が中国国内の裁判所から示されたとお伝えしましたが、その後、予想通り、iPad商標の中国内での権利を有する唯冠科技から損害賠償の訴えが提示されました。その額、1200億円(100億元)とのこと。


『9日付の中国紙、南方都市報によると、広東省深セン市のIT関連企業、唯冠科技が米アップルを相手取り、中国国内で唯冠科技がもつ「iPad」の商標権を侵害されたとして100億元(約1200億円)の損害賠償を求める裁判を同市人民法院(地裁)に起こした。同時にアップルのタブレット端末「iPad」の中国での販売差し止めを求める仮処分も申し立てた。

唯冠科技の台湾親会社が2000年に全世界で「iPad」を商標登録し、01年に唯冠科技が中国で登録していたため、アップルは09年、唯冠台北から「iPad」の商標を買い取る一方、中国国内での商標権の確認を求めて唯冠科技を訴えていた。だが同法院は今月5日、中国の商標権は唯冠科技に属するとしてアップルの訴えを棄却した。』
http://headlines.yahoo.co.jp/hl?a=20111209-00000007-fsi-bus_all


商標権があまりにも高額になる場合、アップルは「iPad」という表現を諦めて、名称の変更(漢字の当て字を用いる等)の可能性もあると取り沙汰されてきましたが、それが俄然実現性を帯びてきた様相です。

中国では、アップル社は「蘋果公司」という音の当て字で表現することもできますし、スティーブ・ジョブズも「史蒂夫·乔布斯」と表現できるのですから、iPadも漢字表記で統一してしまえ、という決断が下されることがあってもおかしくはありません。

実際、日本ではiPhoneを日本語表記するには、アイフォンではなくて「アイフォーン」としなければならなかったのは、その商標を日本の別の企業が登録していたからです。

『アイホン、iPhoneの商標問題でAppleと「友好的合意」』
http://www.itmedia.co.jp/news/articles/0803/24/news102.html

今分かっている情報から察する限りでは、このまま正面から戦っても、アップルが敗訴することは間違いないのではないかと思えます。なにせ、訴えを起こしている企業はリーマンショック後の経営不振ですでに銀行による資産接収がなされ、北京のコンサルティング会社「和君創業」が管財人となっているとのことですから、これは明らかに金目当ての訴訟であることは疑いようがなく、もしアップルが商標の譲渡を狙うなら、先の損害賠償金に加えてさらに多額を要求されることでしょう。

「取れるところから可能な限りふんだくる」

そういうマインドを持ったところと円満な交渉は期待できません。ならば、いっその事、iPadを使用しなくてもアップルは全然困らないという状況を自ら引き起こすことで、肩透かしを食らわせてやればいいではないか、と思う次第です。

NAKA

LinkedInというビジネスパーソン向けのSNSがあります。先日、日本語対応をして話題になっていたやつですが、このSNS内のニュースサイトで、「お金よりも従業員のモチベーションを高める9つのもの」(9 Things That Motivate Employees More Than Money)というエントリーがありました。

紹介されていたのは次の9つのコトです。

【1】惜しみない称賛を送る
    (Be generous with praise)
【2】管理職をなくす
    (Get rid of the managers)
【3】自分が考えたように思わせる
    (Make your ideas theirs)
【4】批判や訂正を決してしない
    (Never criticize or correct)
【5】ひとりひとりをリーダーにする
    (Make everyone a leader)
【6】週に1回はみんなでランチに行く
    (Take an employee to lunch once a week)
【7】成果を讃えて報いる
    (Give recognition and small rewards)
【8】会社でパーティを催す
    (Throw company parties)
【9】喜びと失望を共有する
    (Share the rewards—and the pain)

http://www.linkedin.com/news?actionBar=&articleID=960869492&ids=0TcPsPd30VdjAIdPsMdP4SczoVb3kOd3AQcjwReiMNdPgMczgMdzAIczAQejoUc3oV&aag=true&freq=weekly&trk=eml-tod2-b-ttl-0&ut=2JgVT5I9Azz501

このエントリーを読み終わって気づいたのは、私が所属しているアクセンチュアという会社は、この全てを実践しているということでした。上記の9つをざっくり分類すると、次の3パターンに収まるかと思います。
※もっとしっくりくる分類があったらコメント下さい。

  •  キミの成果を認めるよ系 :1、4、7、9
  •  仕事の裁量を増やすよ系 :2、3、5
  •  楽しいイベントやるよ系 :6、8

相手の心情に寄り掛かって共感し、やることの裁量を広げて、楽しく一緒に過ごす時間を提供する。今のアクセンチュアはこの仕組みがちゃんと備わっているんだな、と改めて実感した次第です。

 

ちょっと話は逸れますが、アクセンチュアに3つのコアバリューと読んでいる社訓みたいなものがあります。全部英語ですけど、直訳だとニュアンスが伝わりにくいので、私なりに意訳してみました。

 ■ Value Creator (価値を提供しよう)
 ■ People Developpr (ヒトを育てよう)
 ■ Business Operator (責任を果たそう)

「価値」というのは、付加価値のことです。自分が加わることによって、どんなプラスアルファを相手に与えることができるのかをいつも自問し、相手が期待する以上の成果を出すことを心がけてほしいということです。

「ヒト」が指すものは部下だけではありません。同僚、お客さん、時には上司に対しても、相手を成長させる何かをすることができる人材となって、自分の周囲にいる人たちの成長を促進させるようになってほしいということです。

「責任」という言葉は、自分への向けられている期待と言い換えることができます。直接自分に与えられた仕事だけをやるのではなく、期待されている役目を率先して果たすために、やるべきことやる姿勢を持ってほしいということです。

これら3つのコアバリューを意識して、組織のリーダーが行動を実践すると、Value Creatorは「成果を認める系」と重なり、Business Operatorは「裁量を増やすよ系」と被り、People Developerは上記2つに加えて「イベントやるよ系」を含むことになるので、『人材のモチベーションを高める仕組みがアクセンチュアにはある』というなんとも手前味噌な結論に、恥ずかしながらというか、別に恥ずかしくもないですが、至った次第です。

 

こういう視点で会社を評価するということができる就活生がいるといいですね。

採用活動で受身にならず、自分がこの先活躍できる場を提供してくれる組織なのかを問い掛けることは、優れた組織を見極めることができるという自分自身のメリットの他に、採用する側として登場する管理職クラスの人たちへ何らかの気づきを与えることができるかもしれませんし、少なくともそういう意識を持った人材を評価するところは少なくないと思います。

就職活動というものは、多くの就活生における人生の重大イベントであり、自分自身のことで手一杯だという方はきっと多いと思います。でも、学校の友達やグループディスカッションで同席した仲間、面接で応対してくれた会社の先輩とのやりとりで、相手から何を得られるか&自分は相手にどんなプラスアルファを与えることができるのか、を考えて行動することを心がけると、これまでとちょっと違った風景が目に入ってくると思いますし、何かが変わると思いますよ。

これから就職活動はさらに活発になってくるでしょうが、体調には気をつけて、気持ちに張りを持ってまっすぐに、でも時々周りを見渡しながら、しっかりと前に進んで下さい。

NAKA

アップルといえば、iPhoneやiPadが代表的な製品ですが、「iPad」という商標を中国本土で使ってはいけない、という判決が12/5に中国国内の裁判所から示されたことが話題になっています。

中国メディアによると、米電子機器大手アップルなどが中国国内における多機能端末「iPad」の商標権所有の確認などを求めていた訴訟で、広東省深セン市の中級人民法院(地裁)は6日までに、同社の訴えを退ける判決を言い渡した。

 報道によると、被告となった深センのIT企業は2001年、中国国内で「iPad」を商標登録。アップル側は09年、各国で「iPad」を商標登録していた被告会社と同グループの台湾企業から、3・5万ポンド(約420万円)で全世界の商標権を譲り受けることで合意した。

 判決は、商標権の譲渡契約は所有者と結ばなければならないと指摘。台湾企業は被告会社の「代理者」には当たらず、訴えは法的根拠がないと判断した。
http://www.47news.jp/CN/201112/CN2011120601002216.html

 

訴訟を起こしたのは唯冠科技(深圳)公司という企業です。

2006年、アップルがiPadの販売を計画していた頃、当時の世界大手ディスプレイメーカーだった唯冠国際の台湾子会社が世界各地で「iPad」の商標権を獲得していたため、400万円程度で商標を買い上げたのですが、実はこれは中国本土でのiPadという商標権利が含まれていなかったのです。このため、前述のような訴訟が起こり、アップルは敗訴となったというわけです。

この結果、このまま何もしなければ、アップルは中国本土でiPadという名称を利用できなくなりますから、商標譲渡に向けた交渉を唯冠科技(深圳)公司とすることになるのでしょうけど、今回はすでにビッグネームとなったiPadについて、かなりの金額が要求されることになるでしょう。武闘派のアップルですから、これに控訴して徹底抗戦を仕掛ける可能性もあり、その場合は、中国本土でのiPad正式販売は遅れてしまいます。

アップルは見事に嵌められてしまいましたね。これは推測ですが、訴訟を起こした唯冠科技は、自分たちの中国本土におけるiPadの価値を理解した上で、ギリギリまで沈黙を保っていたのでしょう。そして、iPadの商標を最も高値で買い取ってもらえるタイミングを見極めていたのではないかと思います。さもなければ、この訴訟は不自然過ぎです。

この件については、以下のサイトで詳しく触れているので、そちらを御覧ください。
http://kinbricksnow.com/archives/51760501.html

中国における商標権のトラブルはこれまでもたくさんありました。少し調べてみただけでも色々と出てきましたが、きりがないので、その一部を列挙してみます。いずれの訴訟も、基本的には同義に即した結審となっていますが、決着までに数年経過しているものが多数あり、訴訟コストと労力は相当なモノであることは容易に想像できますね。

○マクドナルド (2011年)
2001年に赤い背景に黄色の『W』ロゴを記した「万代福(ワンダフルワンダフー)」という名の商標を中国企業が登録。マクドナルドはすぐに『W』のロゴは『M』と酷似しており、撤回するように求めたが、商標局はこれを棄却。その後、2010年に「食堂やカフェなどでの使用は禁止」との決定を下したが、現在も係争中。

○ランドローバー (2011年)
英自動車メーカー「LANDROVER」が、中国自動車メーカー吉利社が有する商標「路虎」(LANDROVERを中国語で表記したもの)の商標登録の取消を求めたが、訴えは却下された。その後、ランドローバー社は控訴し、「路虎」の商標登録を取り消す判決が出された。

○セコム (2010年)
セコムの登録商標である「SECOM」と類似するマークの使用中止を求めて、2007年に深圳世強電訊有限公司を提訴。2009年10月にセコムの主張を認め、8万元の損害賠償と「SECOM」と類似するマークの使用を直ちに停止するよう命じる判決を言い渡し、2010年9月に判決が確定した。

○クレヨンしんちゃん (2009年)
中国企業の「商標の登録行為に関しての悪意性を認めた」が、登録から無効請求までに5年以上が過ぎているとして双葉社の訴えを却下し、中国企業の商標登録を認めた。

○青森 (2008年)
2002年7月に広東省広州市のデザイン会社が「青森」の商標登録出願をしたところ、2003年4月に日本の青森県・青森市及び県内24団体が中国商標局に異議申し立てを行い、同年7月に受理された。約4年半経過した2008年2月、中国商標局が日本側の主張を認める裁定を出した。

○バイアグラ (2008年)
中国国内でのED治療薬バイアグラの商標登録をめぐる訴訟は約10年に渡って行われ、2008年4月に中国北京の裁判所で大手製薬会社ファイザー社と広州ウェルマン薬業公司など3社の間で争われた商標侵害の訴訟に関する最終審判決が下り、ファイザー製薬が敗訴した。

○ヤマハ (2007年)
自社商標の無断使用について、ヤマハ発動機が中国の二輪車メーカーなど計4社を相手取り、損害賠償などを求め、最高人民法院は中国メーカーなどに約830万元(約1億3000万円)の支払いを命じる判決を言い渡した。

○無印良品 (2006年)
JBIが中国における「無印良品」および「MUJI」の商標を不正に先行登録。2000年5月、JBIの商標登録の無効取消を求めて訴訟し、取消審決が2005年11月に下された。その後、JBIは出訴したものの、2006年8月に結審。

○トヨタエンブレム (2003年)
トヨタ自動車が、中国の自動車メーカーの吉利汽車(ギーリー)の使っているエンブレムが類似しているとして使用差し止めを求めた商標権訴訟で、北京市第2中級人民法院は、「双方のロゴは明らかに異なり、混乱を招かない」としてトヨタの訴えを棄却する判決を言い渡した。

NAKA


プロフィール

<!-- include:/infra/profile_name.html -->中 寛之<!-- /include:/infra/profile_name.html -->

中 寛之

アクセンチュアに勤務。
ITIL Managerとして、システムインフラのコンサルティングを中心に、業務領域まで幅広く担当しています。

詳しいプロフィール

Special

- PR -
カレンダー
2014年11月
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            

オルタナティブ・ブログは、専門スタッフにより、企画・構成されています。入力頂いた内容は、アイティメディアの他、オルタナティブ・ブログ、及び本記事執筆会社に提供されます。


サイトマップ | 利用規約 | プライバシーポリシー | 広告案内 | お問い合わせ