特集・ブログ
災害など緊急事態における対策を定める「BCP」。新型コロナウイルスの感染拡大もあり、今、改めて注目を集めています。 ですが、「なんとなくわかっているけれど、システムごとに最適な対策をできているかは自信がない」「きちんと対策できているか不安」という企業も多いのではないでしょうか？ また、従来の自然災害やパンデミックは比較的短期間で収束することを想定していましたが、予想を超える大雨の頻発、さらに新型コロナウイルス感染も収束の兆しが見えず問題が長期化するなか、BCP 対策に求められるものも大きく変化しています。 では具体的にどうすればよいのか、BCP の基本から、今、企業がすべきことを解説します。 Index BCPの基本とは？策定までに検討すべきポイント BCP対策におけるシステムの役割 BCP観点で有効な「データ保全」の方法 この記事に関するお問い合わせ 関連情報 BCPの基本とは？策定までに検討すべきポイント BCP とは、Business Continuity Plan（事業継続計画）の略であり、自然災害やテロなどの緊急事態において、事業を継続するための方法などを取り決めた計画を指します。つまり、通常のオフィスやシステムが利用できない事態に陥っても、素早く体制を復旧し事業を続けるためにあらかじめ具体的な計画を定めておく、ということです。 事業継続と言っても、緊急事態ですからすべて通常と同じように復旧できるとは限りません。どの業務を優先して継続すべきかを判断し、体制を整えるのが基本。まずは以下の流れで検討し、BCP 策定を目指しましょう。 優先すべき中核事業や、ビジネスに影響が大きい業務を特定する 上記、事業・業務の目標復旧時間を決める 事業を継続するための代替案を用意する BCP を発動する基準や、体制を明確にする 具体的な対策が社会情勢や事業の変化によって変わっても、この基本は変わりません。自社が守るべき事業や業務をきちんと見極めることが大切です。 BCP対策におけるシステムの役割 BCP で検討すべきことは、オフィスや工場・店舗など “場所” の確保、取引先との連携、顧客へのフォローなど多岐に渡りますが、システムが担う役割も大きくなります。「業務システムをどう継続するか」「オフィスに出社できないなかで従業員と、どう連絡をとるのか」といった観点のほか、緊急時に在宅勤務できる体制の整備も必要になるでしょう。 特に、コロナ禍により緊急事態が長期化するなか、対策すべき範囲が拡大しています。 在宅勤務では、オフィスのファイルサーバなどにアクセスできないといった課題が浮き彫りになり、クラウド化を進める企業も増加。緊急避難的な対策に留まらず、業務プロセス自体の効率化やモバイル端末活用推進、さらにはオンライン研修など、根本的な見直しを行うケースも今後増えると予想されます。 しかし、これだけのことを一気に進めるのは難しいでしょう。こちらも優先度をつけ、順次進めることをお勧めします。 なかでも最初にやっておきたいのが、「データ保全」です。災害であれパンデミックであれ、データがなくなってしまっては事業の復旧・継続は困難になります。 データを異なる拠点やクラウドなどに保管し、万が一の事態にも損なわれないよう備えることが、BCP において基本中の基本と言えるでしょう。 BCP観点で有効な「データ保全」の方法 データ保全の方法は様々ですが、「事業を継続する」という観点からはデータやシステムの情報を異なる場所で同期する「レプリケーション」が有効です。 レプリケーションでは、決まった時刻のバックアップデータを取得・保管するのではなく最新の情報をリアルタイムに同期するため、本番環境が利用できなくなった際にはフェイルオーバーすることで即座にレプリケーション先の環境に切り替えることが可能。 これにより、データを複数個所で保存しながら、ダウンタイムを最小限にしてシステムを利用し続けることができます。 レプリケーション先はクラウド（IaaS）も有力候補にはなりますが、セキュリティなどの観点からオンプレミスの拠点同士で構成するケースも。例えば、東京と大阪の拠点間でレプリケーションすれば、災害時の対策としても十分有効です。 どこにレプリケーションするのがベストなのか、自社の状況やシステムの規模などを踏まえて検討しましょう。 もう1つ、レプリケーションを実現する製品を選ぶ際には、データ圧縮や転送速度などの基本スペックとあわせて緊急時における対応のしやすさも確認することをお勧めします。 ストレージ自体にレプリケーション機能を搭載するものもありますが、この場合、製品ごとにツールを使い分ける必要があります。「IBM Spectrum Virtualize」は、外部ストレージ仮想化機能を提供します。 「IBM FlashSystem」や「IBM SAN Volume Controller」に搭載することで、異なるベンダのストレージを一括管理することが可能です。 IBM Spectrum Virtualize は、異なるベンダのストレージも一元的にレプリケーションでき、復旧時にもまとめて対処できるのでスムーズです。 BCP は、「一度考えたらOK」というものではありません。社会情勢の変化だけでなく、自社の中核事業や業務が変わることもあるでしょう。 ですが、そのなかでもデータを守る仕組みは不可欠。基盤となるデータ保全を確実に行いつつ、随時対策を見直し、適切な計画を検討する姿勢こそが重要です。 BCP 対策の第一歩として、IBM Spectrum Virtualize などを活用したデータ保全対策を整備しておくことをお勧めします。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 DRで考えるべきITシステム復旧の3つの指標と、実現方法を解説。BCPとの違いは？効率的な対策は？ (コラム) - 近年、大規模な自然災害が増加していることから DR の重要性が高まっています。今、改めて押さえておきたい DR の基本・指標と、実現するための方法とは？ .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
コロナ禍で売上が落ち込んでいる企業を中心に、IT投資を再検討する動きが広まっています。 オンプレミスのシステムを運用するケースでは、膨大な更改コストを回避するため初期費用を抑えて利用開始できるクラウドに移行する企業が増えており、コロナ禍を機に企業のクラウドシフトが一気に進みそうな予感です。 本コラムでは、ミッションクリティカルな領域である基幹システムにおける新たな課題について触れつつ、クラウド移行を検討する企業に向けて、お勧めのマネージド型クラウドサービスについて紹介します。 Index コロナ禍を機に、基幹システムのクラウドシフトが加速 コストだけじゃない！基幹システムクラウド移行の様々なメリット 「Cloud Power」の活用シナリオ この記事に関するお問い合わせ 関連情報 コロナ禍を機に、基幹システムのクラウドシフトが加速 コロナ禍で産業全体の売り上げが減少する中、IT 業界において売り上げを伸ばしている領域が「テレワーク関連」や「クラウドサービス」などです。 クラウドに対するニーズが高まっている背景には、コロナ禍で経済の先行きに不透明感が漂い、大規模な投資を避けたい（もしくは、投資ができない）企業の考えがあります。こうした動きは、これまでクラウド移行をためらうケースが多かった基幹系システムにも拡がっています。 実際、IBM Power Systems などのハードウェアに加え、IBM Power Systems ベースのマネージド型クラウドサービス「Cloud Power※」を販売するエヌアイシー・パートナーズ株式会社（以下 NI+C P）によれば、コロナ禍に突入して以降、オンプレミス更改とクラウド移行を並行して検討していた企業がクラウド一本に絞って進めるケースが増えており、同サービスの成約率が倍増していると言います。（下グラフ参照） ※NI+C P のパートナー、日本情報通信株式会社（以下 NI＋C）が自社データセンター上で提供するクラウドサービス コストだけじゃない！ 基幹システムクラウド移行の様々なメリット コロナ禍で企業が基幹システムのクラウド移行へ踏み切ることになった背景としては、もうひとつ "ヒトを守る" という直接的な要因もあります。 それは、オンプレミスの機器入れ替えや設定などの作業過程における情シス部門やパートナー企業の人間が、入り乱れる "密" 状態の発生を回避したいという、ヒトの生命・安全を守る観点です。 もちろん、クラウド移行に踏み切る理由はこうしたコロナ禍によるものだけではありません。 そのメリットをしっかり評価・認識して近い将来クラウドに移行しようと考えていた企業において、コロナ禍で前倒しして、あるいは、コロナ禍で "ふんぎり" がついた、というケースが多いようです。 そこで、「Cloud Power」の場合、IBM i/AIX などのオンプレミスシステムを「Cloud Power」に移行することで、下記のような数々のメリットを享受することができます。 システム運用保守のアウトソースで人材不足に対応 情シス部門は、OSアップデートやセキュリティパッチ適用など、作業工数のかかる不定期メンテナンスをクラウド提供ベンダーに一任することで、人員リソースをデータ活用などの競争力強化に向けた異なる業務に配分・専任できるようになります。 また、IBM i/AIX という特殊なスキルを持った SE の不足や、熟練者退職にともなう業務運用継続の不安など、情シス部門の課題解決に貢献します。 EOS を心配することなく、常に最新の環境を利用できる ハードウェア・ファームウェアのアップデートや機器の更新は、提供事業者である NI＋C によって適宜おこなわれるため、導入企業はハードウェアの EOS を心配することなく利用し続けることができます。IBM Power Systems の Live Partition Mobility※ 機能によって、メンテナンスにともなうシステム停止の影響もありません。 ※稼働中の論理区画を別の物理的システムに移動する事を可能にする IBM Power Systems の有料フィーチャー 堅牢＆高セキュリティの横浜 DC で安心 「Cloud Power」が提供される横浜データセンターは、東日本大震災の時にも稼働し続けた実績があります。 一般的なオフィスビルとは比較にならない、ファシリティの圧倒的な堅牢性とネットワークを含めたハイレベルのセキュリティにより、重要なデータを守り、安心して利用いただけます。 BCP オプションで、投資を抑えて簡単に BCP 対策 「Cloud Power」のデータセンターは関西にもあり、両データセンター間でデータを同期し万一の時に切り替える「BCP オプション」メニュー（DC 間回線も含む）も提供しています。 オンプレミスでは、大規模な投資が避けられない災害対策サイト構築を、コストを抑えて手軽に実現します。 IAサーバーを含めた全面クラウド移行も可能 「Cloud Power」では、IBM i（AS400）や AIX のほか、Linux や Windowsなどの IAサーバーも同一セグメントで提供でき、オンプレミスで運用する各種システムの全面クラウドも可能です。 この他、エクイニクス社との契約により、AWS など他社クラウドとの接続・連携も容易です。 「Cloud Power」の活用シナリオ Linux や Windows のクラウド型マネージドサービスは数多く存在するなか、「Cloud Power」は、IBM i や AIX などミッションクリティカルな領域における数少ないマネージドサービスの1つです。 クラウドインフラからオフィスとデータセンター/データセンター間をつなぐセキュアな回線まで、必要なモノ・コトをオールインワンで提供しています。オンプレシステムの更改先やオンプレミス本番サイトの災害対策サイトのほか、下記のようなシナリオにもお勧めです。 ハードウェア EOS にともなうシステム延命 IBM i や AIX の古いシステム（オンプレミス）を SaaS に移行するプロジェクトを進めているが、その前にハードウェアが EOS を迎えてしまう…といったケースで、EOS のタイミングで旧システムを「Cloud Power」に移行し、SaaS 移行までの期間を延命することができます。 一定期間の開発・検証用途 当面オンプレミスを維持し続ける計画だが、開発・検証のためのリソースを用意するのが大変！といったケースでは、必要な期間だけ利用できるクラウドのメリットを活かし、「Cloud Power」を一定期間だけ契約して開発・検証をおこなうことでムダを排除できます。 社外プロフェッショナルへの BPO 推進 ベテラン社員の退職を機に、オンプレミスの IBM i や AIX システムを「Cloud Power」に移行。高度なスキルが要求される運用管理を全面的にアウトソーシングすることで、限られたリソースを AI によるデータ分析や RPA での業務自動化などに振り向けることができるようになります。 IBM i × 3種類 / AIX × 5種類の基本メニューに加え、多彩なオプションが用意される「Cloud Power」。 ニューノーマルに向け ITインフラ投資の最適化をお考えの企業は、ぜひ、お気軽にお問合せください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 Cloud Power (製品情報) - IBM i (AS400)、AIX を国内シェアNo.1 のクラウド環境でご提供します！ IBM Power Systemsユーザーのクラウド移行ニーズに寄り添う「Cloud Power」の魅力に迫る (コラム) - IBM Power Systemsのメリット（特長）にフォーカスしつつ、具体的な導入事例についてもご紹介します。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
文字、音声、画像、位置情報など、私たちの身の回りには多種多様なデータが存在しています。 「ビッグデータ活用」や「データドリブン経営」といった言葉が旬なキーワードとなっていますが、理由の1つとして市場やニーズの変化が速い、ということがあります。 この変化の激しい時代において、大量データを市場環境の分析や顧客ニーズの把握などに活かしていくことは、今日の企業にとって競争を勝ち抜くための重要な経営課題となっています。 すでに一部の企業はデータ分析基盤を導入し、多種多様なデータを効率的に分析することで市場の変化を迅速に捉え、自社製品・サービスの改善に活用しています。 そこで本コラムでは、データ分析基盤の基本的な構成や選定ポイントなどを解説します。 Index データ分析基盤とは？ データ分析基盤選定で押さえるべき5つのポイント IBM Cloud Pak for Dataについて この記事に関するお問い合わせ 関連情報 データ分析基盤とは？ データ分析基盤は、多種多様なデータを統合した上で分析・活用するためのソリューションです。Excel や CSVファイルを数個利用してデータを分析するだけであれば、大がかりなデータ分析基盤を用意する必要はないでしょう。 しかし、「大量のデータを分析したい」「複数の担当者で分担して分析したい」といった場合には、効率よく分析を行うためにデータ分析基盤の構築が必要となります。 代表的なのは AI を利用する際です。定期的かつ繰り返し分析を行う必要があるので、データ分析基盤があるとスピーディーに手間をかけず結果を出すことができるようになります。 データ分析基盤は主に以下の機能があります。 データを貯める 貯めたデータを分析するために整形・加工・クレンジングする 分析ツールを実行するためにデータを保管する 1.データを貯める（データレイク） データレイク（Data Lake）は、業務システムやデータベースといったデータソースから収集したデータを保管する役割を担う、まさに「データの湖」のような存在です。 データレイクには、何ら加工を加えていない生データ（ローデータ）の状態でデータを保管します。データ分析の過程では、その目的や扱うデータの内容に応じて、非構造化データの構造化データへの変換、データ形式の変換、データクレンジングといった様々な加工を施します。 一方で、加工したデータを元の状態に戻さなければならない場合もあります。そのような場合にも、データレイクに生データを保管していれば、速やかに加工前の元データを手に入れることが可能です。 2.貯めたデータを分析するために整形・加工・クレンジングする （データウェアハウス） データウェアハウス（Data Warehouse）はデータレイクとは異なり、分析しやすいように加工したデータを保管する役割を担います。 データレイクや個別のデータソースに存在しているデータを ETL（Extract/Transform/Load）ツールで抽出し、分析用途に合わせて加工した上でデータウェアハウスに格納します。 幅広いデータソースから収集した多種多様なデータを用いて分析を行うという場合には、あらかじめ加工済みのデータをデータウェアハウスに集めておいた方が分析をスムーズに進めることができます。 3.分析ツールを実行するためにデータを保管する（データマート） データマート （Data Mart）は、特定の用途で必要となる加工済みのデータのみを保管する役割を担います。 データウェアハウスは、データレイクや個別のデータソースから取り出して加工したデータをすべて保管します。 一方でデータマートは、「売上分析」「顧客行動分析」といった用途に合わせたデータのみを格納します。用途が限られている分、データウェアハウスよりも小規模なサイズでコストを抑えて構築することが可能です。 そのため、データ分析の目的が限定的な場合にはデータウェアハウスを用いることなく、データマートのみでデータ分析基盤を構築する場合もあります。 データ分析基盤選定で押さえるべき5つのポイント 実際にデータ分析基盤を選定する際には、次の5つのポイントを押さえることが重要です。 1. 属人化を防止できること データ分析基盤の構築・運用には高い専門性が欠かせないため、専門スキルを持った一部のデータエンジニアだけが利用するといった形で属人化してしまいがちです。 属人化した状態では担当者の退職や異動にともなう引き継ぎがうまくいかず、データ分析の継続が困難になってしまう可能性があります。そのため、データ分析基盤選びでは属人化を防止できるかどうかが重要な選定ポイントになります。 例えば、分析用途に合わせたデータを管理画面上で簡単に抽出できるようなデータ分析基盤であれば、より幅広いメンバーがデータ分析を担うことができるようになり、属人化の防止につながるでしょう。 2. 一気通貫でデータ分析基盤を利用できること 前述のとおり、一般的にデータ分析基盤は、データレイク・データウェアハウス・データマートといった複数のソリューションを組み合わせて構築します。 この構築段階で設計を最適化することができず、「構築後の改修や別のソリューションの追加などで思わぬコストが発生してしまった…」というのはよく聞くところです。 さらに、ソリューション間でのデータ連携の不具合によるサイロ化も懸念されます。 このようなリスクを低減するには、複数のソリューションを組み合わせるのではなく、データエンジニアやデータサイエンティスト、ビジネスユーザーといった様々な役割の人が一気通貫で利用できるようなソリューションを選ぶ必要があります。 3. スピーディーに分析を開始できること 分析にあたってデータマートを作成することは珍しくありませんが、データウェアハウスからバッチ処理で物理的にデータを抽出してくるので、データ量が多い場合にはどうしても時間がかかってしまいます。 一方で、データをマッピングすることで仮想的なデータセットを作成できるソリューションも登場しています。このようなソリューションであれば、バッチ処理によって物理的にデータを抽出するよりも素早くデータ分析を開始することが可能です。 4. 非構造化データを扱えること 従来、企業が扱うデータの多くはリレーショナルデータベースや CSVデータのように、列と行の概念を持った構造化データでした。 一方で、最近では電子メール、会議を録音した音声ファイル、PDF形式の契約書といった列と行の概念を持たない非構造化データが多くなっています。 IoTやスマートデバイスの進歩によってさらに膨大な量の非構造化データが流通するようになっている状況を踏まえると、非構造化データにも対応したデータ分析基盤を選ぶことが重要です。 最近では、AIを活用することで非構造化データの分析を効率化しているデータ分析基盤も出てきています。 5. 拡張性が高いこと スマートデバイスや IoT の普及によってデータ流通量が急増。2022年の世界のデータ流通量は、2017年時点と比べて3倍以上に達すると予測されています（※1）。 このような状況を踏まえると、データ量の増大を見越してホストやリソースの追加が容易で拡張性の高いデータ分析基盤を選ぶ必要があります。 ※1：総務省「令和元年版 情報通信白書」 IBM Cloud Pak for Dataについて 本コラムは、データ分析基盤の構成要素や選定時のポイントについて解説しました。 IBM Cloud Pak for Data は、企業のデータ活用を強力に推進するデータ分析基盤です。Red Hat OpenShift Container Platform 上で稼働し、クラウド・自社データセンターなど環境を選ばずに利用することができます。 また、IBM Cloud Pak for Data はコンテナ化されているため、自社のデータ環境に合わせてリソース・可用性を柔軟に調整することができます。まさに企業で利用するためのデータ分析基盤として最適な製品です。 こちらのホワイトペーパーでは、今回ご紹介したデータ分析基盤選定のポイントと合わせて IBM Cloud Pak for Data が選ばれる理由を解説しています。データ分析基盤の導入をご検討中の方は、ぜひ、ご一読ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBM Cloud Pak for Data (製品情報) - データを洞察へと変換する方法をよりシンプルにし、自動化します。 IBM Cloud Pak for Dataが企業のデータ活用に選ばれる3つの理由 (ホワイトペーパー) - データ分析基盤選定で押さえるべき5つのポイントもご紹介！ 今、デジタルサービスに求められる必須要件とは!?アプリケーションのコンテナ化で得られる5つのメリット (コラム) - 今注目されている「コンテナ化」。コンテナ化とは？そのメリットとは？ 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した (ブログ) - 全世界から9万人以上の参加者が！ IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
IBM Cloud Pak for Applicationsの新規販売は終了いたしました。 今後のアプリケーションランタイムソリューションは、2021年1月15日に発表されたWebSphere Hybrid Editionとなります。 アプリケーションを稼働させる環境として、コンテナに注目が集まっています。 デジタルサービスに対する顧客のニーズが多様化し、かつ加速度的に変化している中、その顧客ニーズに対応しようとしている企業にとって、DevOps によるアプリケーションの開発・運用と共にコンテナ化には様々なメリットがあるのがその理由です。 本記事では、そんなアプリケーションの迅速な開発・展開が可能となるコンテナ化について、従来の仮想マシン上でアプリケーションを稼働させる場合との違いやメリットを解説します。 Index コンテナとは？ コンテナと従来の仮想化技術との違い コンテナのメリット コンテナ化の注意点 今日のビジネスにおけるコンテナの活用シーン IBM Cloud Pak for Applications について この記事に関するお問い合わせ 関連情報 コンテナとは？ コンテナとは、アプリケーション本体やライブラリといったアプリケーションの実行環境をパッケージングした上で、ホスト OS のコンテナエンジン上でプロセスやネットワークといったリソースを切り離して仮想環境を構築する技術のことです。 コンテナの中核をなしているソフトウェアは、主に以下の2つです。 コンテナエンジン コンテナエンジンは、ホスト OS 上でのコンテナの作成、削除、実行などを担います。代表的なコンテナエンジンとしては Docker がよく知られています。 オーケストレーションツール 単に開発環境としてではなく本番環境もコンテナ化する場合には、コンテナの運用管理を徹底する必要があります。そこで登場したのが、オーケストレーションツールです。 オーケストレーションツールは、コンテナ起動中のロールアウトやロールバック、データを保持するための外部ストレージのマウント、クラスタの構成、各コンテナの管理やログといったコンテナの運用に関わる様々な役割を担います。 代表的なオーケストレーションツールとしては、Kubernetes や OpenShift がよく知られています。 コンテナと従来の仮想化技術との違い これまで、アプリケーション稼働環境の構築手法としては仮想マシン型が一般的でした。 仮想マシン型の場合、物理サーバー上にアプリケーションやライブラリのほかにゲスト OS を含む仮想マシンを複数実装することで仮想環境を構築し、リソースの効率的な利用を実現します。 一方でコンテナの場合、各コンテナはアプリケーション本体やライブラリなどで構成されており、ゲスト OS は含みません。コンテナエンジンがホスト OS からネットワークやリソースを切り離した上で、単一のホスト OS 上での複数アプリケーション（コンテナ）の実行を制御しているからです。 これにより、仮想マシン型と比べるとより小さなリソース（CPU・メモリ・ディスク）でアプリケーションを稼働させることができるようになります。 コンテナのメリット 前項で述べたコンテナと仮想マシン型の仮想環境の実装を比べると、コンテナには次のようなメリットがあります。 1. 起動が速い 仮想マシン型の場合、アプリケーションを起動するためにはゲスト OS の起動をともなうため、アプリケーションが利用可能となるまでに数分から数十分程度の待ち時間が発生します。 一方コンテナの場合、アプリケーションを実行するための各コンテナはゲスト OS を含まないので、ゲスト OS を起動する待ち時間が発生しません。そのため、コンテナ起動後は数秒から数十秒程度でアプリケーションの利用を開始できます。 2. 処理が速い 仮想マシン型の場合、各仮想マシンからハードウェアにアクセスする際にハイパーバイザーとホストOS を経由します。そのため、物理環境と比べると処理速度が低下する難点があります。 コンテナの場合には、各コンテナからハードウェアへのアクセスをホスト OS が直接制御します。そのため、仮想マシン型と比べて物理環境に近い処理速度で仮想環境を利用可能です。 3. ハードウェアのリソース消費を減らせる 仮想マシン型の場合、アプリケーションを実行するためのサーバーを増やす（スケールアウト）にはアプリケーションやライブラリのほかにゲスト OS を含む仮想マシンを追加しなければなりません。 特にゲストOS自身が多くのリソースを消費するので、スケールアウトすることによってハードウェアのリソースを消費し、アプリケーションで利用できるリソースが逼迫してしまいます。 繰り返しになりますが、コンテナの場合、各コンテナはゲストOS を含みません。 そのため、ハードウェアのリソース消費を抑えながらアプリケーションをスケールアウトすることができます。 4. 環境を選ばず実行できる ゲスト OS を含む OS 単位で構成された仮想環境の仮想マシン型とは異なり、コンテナはアプリケーション単位で構成された仮想環境です。 そのため、作成したコンテナは、パブリッククラウドやオンプレミスといったアプリケーションの配置場所や物理サーバー・仮想サーバーのようなサーバー環境の違いに依存せずに実行できます。 5. ほかのアプリケーションから分離された開発環境で作業できる エンジニアは、コンテナ上で開発したアプリケーションをほかのアプリケーションから分離された開発環境で扱えるようになります。 また、コンテナには特定のバージョンのプログラミング言語ランタイムやライブラリ、アプリケーションの実行に関わる依存関係などを組み込めるので、最終的にそのコンテナがどの環境にデプロイされてもアプリケーションとしての一貫性を保つことが可能です。 コンテナ化の注意点 前項で挙げたように、アプリケーションのコンテナ化には様々なメリットがあります。 一方で、コンテナ内でデータを保持する場合には注意が必要です。コンテナを削除すると、コンテナ内のデータも一緒に削除されるからです。 したがって、コンテナで扱うデータを保持する場合には、データを永続化させるための構成を検討する必要があります。 具体的な方法としては2つあります。 コンテナエンジンを稼働させているホスト OS 上にデータを保管する 外部（共有）ストレージにデータを保管する 1.では、コンテナ上で保存するデータをホストOS上の領域に保管する設定ができます。 しかし、サービスを提供する本番環境では可用性・拡張性を確保する必要があり、一般的には複数台のホストOS 環境を用意することになります。 この方法の問題点として一番大きいのは、アプリケーションのスケールアウトや、障害対応のために当初稼働していたホストOS とは別のホストOS でコンテナを稼働させるといった場合に、データの引き継ぎが行われず結果としてデータロストが発生してしまう可能性があります。 2.では、複数のホストOS からアクセス可能な共有ストレージにデータを保管します。 その場合は1.で実現できなかったホストOS をまたいだコンテナのスケールアウト・移動にも対応できるようになります。 また、コンテナを停止するとコンテナ内に保存していたデータが消えるという特性上、仮想マシン型のようなバックアップ取得は難しくなります。 そのため、アプリケーション内にバックアップ機能を追加する、データの保管先を意識した設計に変えるといった考慮が必要になります。 今日では、コンテナ化にあたっての懸念材料となるデータの永続化について、バックアップ機能を持ったオーケストレーションツールや NAS とのパッケージングなどによって解消できるソリューションも登場しています。 今日のビジネスにおけるコンテナの活用シーン ここまで解説したように、アプリケーションのコンテナ化には様々なメリットがあります。冒頭でも述べたように、これらのメリットは顧客ニーズの多様化に対して自社のデジタルサービスをスピーディーに適合させようとしている企業にとって大きなインパクトがあります。 今日のようにビジネス環境の変化が著しい中で、企業は顧客ニーズを自社サービスに素早く反映することが求められています。 とはいえ、これまでの「ウォーターフォール」型手法ではスピーディーな実現が難しくなります。「アジャイル開発」的な発想で自社のデジタルサービスを日々アップデートしていく必要があります。 これまで、デジタルサービスはモノシリックな形で作り上げるのが一般的でした。モノシリックとは、単一のアプリケーションとしてデジタルサービスを作り上げるソフトウェアのアーキテクチャのことです。 小規模なデジタルサービスの開発には適していますが、コードベースの拡大に伴って修正・テストに時間がかかる・コードのバージョン管理といったメンテナンスが煩雑化しやすいという難点があります。 そのため、サービスの改修や追加をスピーディーに実行することが難しく、高頻度でのアップデートを前提としたデジタルサービスを開発するアーキテクチャに適しているとは言えません。 こうした中で、多くの企業の関心を得ているのがデジタルサービスのマイクロサービス化です。 マイクロサービスとは、細分化された個々のサービスを連携させて1つのデジタルサービスを作り上げるというソフトウェアのアーキテクチャです。すでに一部の企業は、自社のデジタルサービスをマイクロサービス化した上で、それぞれを高頻度でアップデートすることにより顧客ニーズに素早く対応しています。 そして、前述したようにアプリケーションをコンテナ化することによって、開発者はほかのアプリケーションから分離された環境で開発を行うことができるようになります。 これはつまり、アプリケーションをマイクロサービス化・コンテナ化することによって、コンテナ上で開発したアプリケーションをマイクロサービス化した機能単位でスピーディーに開発できるようになるということです。 したがって、アプリケーションのコンテナ化・マイクロサービス化によってマイクロサービス単位のアップデートを繰り返すことが容易にになり、顧客ニーズを早期にキャッチアップした継続的なアップデートを行うことで顧客満足度を向上し企業価値を高めることができます。 IBM Cloud Pak for Applications について 本コラムは、アプリケーションのコンテナ化とそのメリットについて解説しました。 今日、デジタルサービスに求められる必須要件としてのアプリケーションのコンテナ化をスピーディーに実現できるツールの1つが、IBM Cloud Pak for Applications です。 IBM Cloud Pak for Applications は、Red Hat OpenShift を基盤としてアプリケーションのモダナイゼーションを支援する製品です。 Cloud Pak シリーズには他に、データ管理、システム連携、マルチクラウド管理、セキュリティといった様々な機能に特化した製品があります。 ユーザーは、IBM が築き上げたベストプラクティスとして提供されるコンテナ・イメージを活用できるので、オンプレミスやクラウドといった環境を問わず、IBM Cloud Pak for Applications を利用して既存アプリケーションのコンテナ化を実現できます。 アプリケーションのコンテナ化に関心をお持ちの方は、ぜひ、IBM Cloud Pak for Applications をご検討ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 全ての企業が AI カンパニーになる！「IBM THINK Digital 2020」に参加した (ブログ) - 全世界から9万人以上の参加者が！ 【やってみた】IBM Cloud Pak for Applications導入してみた：概要編 (ブログ) - シリーズ第1回目！概要編として検証の目的・背景や環境周りをご紹介します。 IBM Cloud Paks シリーズ ご紹介資料 (資料) ※会員専用ページ - 6つの Cloud Paks について、お客様の理解度に応じて必要な資料を選択できる形式になっています。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
AI 活用が期待される分野の1つが「需要予測」です。 工場での生産量や仕入れ、販売量から営業成績、不動産の価格変動など、従来はベテランスタッフの経験や勘に頼ることが多かった領域を AI で代替できれば大きな効果につながります。 AI・機械学習のなかでも導入が進んでいる需要予測ですが、いざ自社で導入するとなると懸念も大きいもの。 本記事では、需要予測に成功したケースと失敗したケースの違いとともに、その分岐点がどこにあるのかを考えます。 Index 「需要予測」では、精度UPのための試行錯誤が必須 成功・失敗の分岐点は「必要なデータが揃っているか」 データサイエンティストに代わるツールの登場で、AI導入のハードルは下がっている 「H2O Driverless AI」をPoC環境でお試しいただけます この記事に関するお問い合わせ 関連情報 「需要予測」では、精度UPのための試行錯誤が必須 AI による「需要予測」では、過去のデータや気象情報、周辺市場といった変動要素などを学習し、変化のトレンドを導き出すことで次の変化を予測します。 「ベテランの経験や勘」と言われているものもこれらの情報をベースにしているはずですが、どの情報をもとに考えているのか明確になっていないケースが多く、「経験や勘」を別のメンバーに引き継ぐにはかなりの時間がかかってしまいます。 AI を利用すれば「どの情報が関連しているか」「より影響が大きい情報がどれか」などが可視化され、データをもとにした需要予測が可能になります。 もちろん AI も最初から正確な予測ができるわけではなく、様々なデータを学習させ、試行錯誤しながら精度を改善する必要があります。 一般的には、直近1年間について AI による予測データと実績データを突き合わせることで検証し、相関性の高いデータや結果への影響度が大きいデータを見極めながらチューニングを繰り返します。 成功・失敗の分岐点は「必要なデータが揃っているか」 AI による需要予測も、成功するケースと精度があがらず失敗に終わるケースがあります。両者の違いはどこにあるのでしょうか？ 成功ケースを見ると、信用できるデータを大量に確保できており、その中から需要予測につながるデータを特定することで高い精度での予測を実現しています。 一方失敗したケースの要因としては、関連するデータの種類が少ない、データの精度が信用できない、予測モデルの設計に問題がある、などが挙げられます。 このように、成功と失敗の分岐点には「必要なデータが揃っているかどうか」が大きく関わってきます。 上述したとおり、AI にできるのは「大量のデータから相関関係を導くこと」です。そのために必要なデータがなければ、AI を導入しても期待する成果は得られません。 また、必要なデータといっても予測したい内容に直接関係するものばかりでなく、様々な観点から関連するデータが揃っていることも重要ですし、適切な予測モデルを採用したうえでデータごとに関連性・重みづけをチューニングする必要があります。 需要予測を成功させるためには、関連するデータの質と量を揃えるとともに、適切なモデルを設計できるデータサイエンティストの存在が不可欠と言えそうです。 データサイエンティストに代わるツールの登場で、 AI導入のハードルは下がっている AI 導入を成功させるには必要なデータを揃えることが重要…とはいえ、データを用意するのは一筋縄ではいきません。 「社内にどのようなデータがあるのか分からない」「必要なデータがどこにあるか分からない」「手入力のためデータの精度が不安定」「部門間で連携できない」など様々なハードルがあるほか、そもそも「属人的な要素が強く、データ化できない」というケースも。 まずはデータ連携を進め、データを統合管理できる環境を整備することも大切です。 予測モデルの設計やデータの重みづけに関しては、専門知識・スキルを持つデータサイエンティストが担っており、精度を上げるためにチューニングを繰り返し、かなりの時間がかかるのが一般的でした。 しかし、これらの作業を自動化する "H2O Driverless AI" のようなツールが登場したことでハードルが大きく下がっているのも事実。高い分析スキルを持つ人材がいなくても、短期間で一定の成果を導くことは十分可能になってきています。 これまで二の足を踏んでいた企業も、そろそろ本格的に AI 導入を検討するタイミングと言えるのではないでしょうか？ 「H2O Driverless AI」をPoC環境でお試しいただけます 記事内で取り上げた「H2O Driverless AI」のPoC環境をご用意していますので、検証などの用途でご利用いただけます。ご利用いただき効果や使い易さなど、検証から導入の可否を判断できるのが大きなメリットです。 AIによる機械学習の導入をお考えの企業様には、要件定義前の検討段階でのご利用をおすすめしております。 PoC環境の利用をご希望の場合は、お取引のあるパートナー様経由での申請をお願いいたします。お取引のあるパートナー様が不明の場合はお問い合わせください。 ※競合製品取り扱い企業様のお申し込みについてはお断りする場合がありますので、予めご了承ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBM Maximo Visual Inspection (旧 IBM Visual Insights) (製品情報) - D/L の経験とノウハウを、誰もが使いやすい GUI でのツールとして画像・動画に関するディープラーニングに特化して提供します。 AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) - よく聞かれるAIの5つのハードルについて、解決策とあわせて解説します。 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その1) (ブログ) - Driverless AI で競馬の予測 (回帰分析) に挑戦しました。 【やってみた】超簡単データ分析！H2O Driverless AI を使ってみた (ブログ) - 「本当に初心者でもできるのかな？」ということで、今回実際にその Driverless AI を試してみました！ 普及が進む、機械学習による異常検知。導入の課題はここまで解決している (コラム) - 機械学習の活用が進む現状。導入の課題とその解決策までをまとめて紹介します。 Driverless AI ご紹介資料 (資料) ※会員専用ページ - IBM i や AIX ユーザへの提案のポイントを取り纏めた資料です。 IBM AI ソリューションの事例ご紹介（IBM PowerAI Vison、Driverless AI）(事例) ※会員専用ページ - 業種毎の活用ケースや導入事例をはじめ、案件発掘事例についてご紹介しています。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
様々な用途への活用が進む機械学習。なかでも実用化が進んでいる分野の1つが異常検知です。 従来は人がチェックしていた異常を機械学習で検知することにより、負担軽減・精度向上などにつながると期待を集めています。 また、モデル生成などを自動化する機械学習ソリューションが登場、導入のハードルが大きく下がったことも後押しとなり、普及が本格化しつつあります。 本記事では、活用が進む現状とともに、導入の課題とその解決策までをまとめて紹介します。 Index 機械学習の異常検知では、何を検知できるのか？ 人材・データ・インフラ、異常検知導入を阻む3つのハードル 導入のハードルを大きく下げる、最新ツール・ソリューションとは 「H2O Driverless AI」をPoC環境でお試しいただけます この記事に関するお問い合わせ 関連情報 機械学習の異常検知では、何を検知できるのか？ 機械学習の異常検知はセンサーデータや画像データなどを学習させ、正常として定義したデータとマッチしないデータパターンを検知することで実現します。 大きく、期待されるデータと異なるデータが現れたときに検知する「外れ値検知」、異常が起きているタイミングを部分的に検知する「異常部位検出」、データの急激な変化を検知する「変化点検知」の3つの手法があります。 これらの手法や機械学習のモデルなどを用途にあわせて選択、チューニングすることで、精度を高めていくのです。 実際に活用が進んでいる事例として、製造業における検品作業があります。設備から出力されるセンサーデータから問題発生を検知するのとあわせ、画像データからキズや欠陥がないかを検知することで高い精度を実現。ベテランスタッフのスキル継承、検品作業の負担軽減、人件費削減など大きな効果につながっています。 ほかにも、小売業では店舗における人の振る舞いの異常検知や、売り場の状態（欠品や位置ずれなど）を監視・分析することで売り場メンテナンスの効率化につなげる事例、金融業における不正検知など様々なシーンで導入されています。 人材・データ・インフラ、異常検知導入を阻む3つのハードル このように活用が進む異常検知ですが、いざ自社で取り入れるとなるとハードルが高いもの。なかでもまず挙げられるのが「人材」です。 機械学習の手法やモデルから自社の目的にあったものを適用し、精度を上げるには専門知識が欠かせません。 これらの知識・スキルを持つデータサイエンティストが、自社にそろっている企業は少ないのではないでしょうか。 また、もう1つ課題となるのが「データ」。 機械学習を行うには適切なデータがそろっていることが前提であり、データ量が多ければ多いほど精度が上がります。ですが、「機械学習に使える適切なデータがない」「データ量が少ない」といったケースは多く、この準備に機械学習のワークロードのうち大半を費やすとも言われています。 最後に検討が必要なのがインフラです。 クラウドファーストが当たり前になった今、特に機械学習のような最新技術はクラウド上に構築するケースも多く見られます。 しかし、利用するデータは機密レベルが高いことが多く、精度を上げるためにデータ量を増やすとネットワークのコスト増にもつながります。また、機械学習では様々なデータで試行錯誤し精度を上げるため、その都度、大量のデータをクラウドにアップロードする必要があります。 予算・パフォーマンス・セキュリティのバランスを考慮すると、オンプレミスでの導入が有力候補に。オンプレミスでどのように機械学習の環境を構築するかも大きなハードルとなるのです。 導入のハードルを大きく下げる、最新ツール・ソリューションとは 上記の状況の解決策として今注目されているのが、モデル生成など従来データサイエンティストが担っていた部分を自動化し、コーディング不要で機械学習を開発できるツールです。 なかでも「H2O Driverless AI」は使いやすいUIで、精度の高いモデルを作成できることが強み。「どのデータが結果への影響が大きいか」といった重みづけも自動でおこなうため、データサイエンティストのような専門家がいなくても自社で導入することが可能になります。 もちろん「期待する結果を得るために、どういったデータが影響するか、そのデータはどこにあるのか」といったツールを活用する前段階の作業が必要なことは変わりません。ただし、これらは自社業務に密接にかかわるもの。社内業務に精通した人材で対応できるケースも多いでしょう。 こういったソリューションを利用することで、環境構築のハードルは大きく下がるはずです。オンプレミスでの導入が容易になれば、クラウドにはあげられなかったデータを分析できるなど活用の幅も広がります。 従来、人が手作業でしていた異常のチェックを機械学習で自動化することにより、業務効率化・コスト削減・負担軽減・品質向上など得られる効果は大きいもの。すでにこのようなツールを駆使し、機械学習による異常検知を導入している企業も増えています。「業務に活用するとしたら、どこに取り入られるのか」をまずは検討してみてはいかがでしょうか。 「H2O Driverless AI」をPoC環境でお試しいただけます 記事内で取り上げた「H2O Driverless AI」のPoC環境をご用意していますので、検証などの用途でご利用いただけます。ご利用いただき効果や使い易さなど、検証から導入の可否を判断できるのが大きなメリットです。 AIによる機械学習の導入をお考えの企業様には、要件定義前の検討段階でのご利用をおすすめしております。 PoC環境の利用をご希望の場合は、お取引のあるパートナー様経由での申請をお願いいたします。お取引のあるパートナー様が不明の場合はお問い合わせください。 ※競合製品取り扱い企業様のお申し込みについてはお断りする場合がありますので、予めご了承ください。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 IBM Maximo Visual Inspection (旧 IBM Visual Insights) (製品情報) - D/L の経験とノウハウを、誰もが使いやすい GUI でのツールとして画像・動画に関するディープラーニングに特化して提供します。 AI導入はどこまで現実的？ 5大ハードルとその解決策を解説 (ホワイトペーパー) - よく聞かれるAIの5つのハードルについて、解決策とあわせて解説します。 【やってみた】H2O DriverlessAIをIBM Power System AC922で動かして競馬予想する (その1) (ブログ) - Driverless AI で競馬の予測 (回帰分析) に挑戦しました。 【やってみた】超簡単データ分析！H2O Driverless AI を使ってみた (ブログ) - 「本当に初心者でもできるのかな？」ということで、今回実際にその Driverless AI を試してみました！ AIによる需要予測は、どこまで使えるのか？成功と失敗の分岐点を解説 (コラム) - 需要予測に成功したケースと失敗したケースの違いとともに、その分岐点がどこにあるのかを考えます。 Driverless AI ご紹介資料 (資料) ※会員専用ページ - IBM i や AIX ユーザへの提案のポイントを取り纏めた資料です。 IBM AI ソリューションの事例ご紹介（IBM PowerAI Vison、Driverless AI）(事例) ※会員専用ページ - 業種毎の活用ケースや導入事例をはじめ、案件発掘事例についてご紹介しています。 .btn_B{ height:25px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_B a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
前回の Vol.1 ～そもそも最近よく聞くデザイン思考って何？～ では、デザイン思考とは、そしてクラウドとデザイン思考の関係について考えてみました。 IBM のクラウド戦略、そして、その根幹である Bluemix がデザイン思考を元に生まれた製品だと、お伝えしました。また、IBM を始めとする IT ジャイアント各社が、かなりの勢いで、デザイン思考を担う「デザイナー」を採用していることもお伝えしました。 さて、そのデザイン思考ですが、日本での盛り上がりもある一方、デザイン思考の採用が難しい現実も見え隠れしています。 前回の特集では、IBM における成功事例として、Bluemix を挙げました。今回は失敗事例というわけではありませんが、デザイン思考の導入を難しくするものについて、考察を深めてみたいと思います。 デザイン思考、その前に... 前回もデザイン思考の効果的な実践は難しいかも、ということについて触れました。 日本の多くの企業は、成功を前提に（成功事例を基に）ビジネス展開を考えることが多いのではないでしょうか。この「成功」という意味も広いのですが、"成功を前提に"と言うのは、"失敗しないことを前提に"とも言い換えられます。計画を練り、リスクを排除し、とにかく"失敗しないように"プロジェクトを進めます。しかし、デザイン思考の場合、失敗を前提に（できるだけ小さい失敗を重ね失敗から学びながら）、をコンセプトとして、プロジェクトを進めるのです。 このプロジェクトの進め方は今までのものとは対照的あり、"失敗しないようにする"ことに慣れているチームや担当者が急に「失敗前提」でと言われても、なかなかリスクに飛び込めないものです。デザイン思考への移行には、"失敗しない前提"の他にも以下のような課題があります。 期間や予算の予想が通常のプロジェクトとは異なる 複雑な承認プロセスが短期、繰返し型のプロジェクトの足かせとなる 縦割りの組織や、パートナー企業を含む複雑なプロジェクト推進体制もネックに 組織を横断した、また外部からの人選が重要 プロジェクトの評価方法や人事考課が減点方式となると、失敗前提の評価が難しい う～ん、こう考えると暗い気持ちになってきます。何だか日本には向いていない思考法なのかも... と思われたかもしれません。 いいえ、そんなことはありません。デザイン思考には日本の製造業を中心としたモノづくりの方法やアイデアもふんだんに取り入れられています。もちろん、デザイン思考は万能なものではありませんが、イノベーションに悩む日本企業にとって、その方法を学んだり、試したりする価値はあるはずです。 デザイン思考教育の現状 前回の特集を読まれた方で、不思議に思った方も多かったかも知れません。IT ジャイアント企業の求人で、なぜそんなに「デザイナー」が募集されているのかと。日本でもデザイン思考を導入するのであればさっさと雇ってしまえば良いのではと... しかし、そう簡単ではない現状があります。 まず、デザイン思考に積極的に取り組んでいる海外の大学や大学院を見てみましょう。 Stanford University d.School Illinois Institute of Technology Institute of Design MIT Integrated Design & Management Harvard MS/MBA Aalto University Integrated Design Business Management (Helsinki) 日本では、 京都大学デザインイノーべションコンソーシアム 東京大学 i.school 千葉工業大学 創造工学部 慶応義塾大学大学院メディアデザイン研究科 などがあります。 もちろん、日本の大学でもデザイン思考を学ぶことはできるのですが、現在、世界のデザインスクールとして上位にランキングされている大学は見受けられないのが現状です。そもそも学部やデザイン・スクールで学べる人の数が少ない、実質的に外部や社会人に開かれていない、学部横断ではない、などがその理由として考えられます。 海外では、スタンフォード大学を例にとると、d.School など学部横断型の組織を持つところも多く、企業での盛り上がりを機に、新たにデザインスクールや学部を設けるところも増えているようです。 また、『デザイン思考家が知っておくべき39のメソッド -the d.school bootcamp bootleg- 』に出てくる、デザインプロセスを進めるにあたって必須のスキルを学ぶ体制が整っているか？ということもあります。それは、インタビューの方法であったり、様々なブレーンストーミングの方法であったりします。 日本人に聞き慣れない例でいえば、『デザイン思考家が知っておくべき39のメソッド』の一つにインプロ（ Improvisation ： 即興演劇／即興コメディ、またその教育手法）があります。欧米では、Google、Facebook、Pixar など多くの企業でインプロを使ったワークショップが実施されています。 即興の教育手法を使い、高度なコミュニケーション能力や発想力を養い、チームビルディングを実現しています。 スタンフォード大学の起業家育成コースでは、1学期を通したインプロのクラス受講の必須としています。これは専属のインプロの先生が指導し、起業家に必須の能力のひとつとして、また、デザイン思考に必要なメソッドとして学んでいます。 このように、デザイン思考そのものだけではなく、そのための予備知識やスキルを学ぶ体制が整っていることもデザイナーを多く輩出できる要因ではないかと考えられます。 更に、重要な点ですが、学生の受け皿である企業が「デザイン思考」を重視しているか？ということも大きいように思います。 IBM の取り組み 以前に IBM が主催するデザイン思考に関するセミナーに参加しました。様々な学びがありましたが、その中でも某航空会社での事例の話は大変興味深いものでした。 その事例の航空会社は、伝統的なウォーターフォール型の開発手法を行っており、IBM が提供するデザイン思考を取り入れたサービスプログラムを実施した際、いったん反発（Resistance）にあったという非常に親近感のわく内容でした。 米国においても歴史のある企業や業界、またその企業文化や企業内の中心的となる年代、世代によって、デザイン思考やアジャイル開発への抵抗感や順応性は異なるようです。 では、IBM ではそのような企業にどのようなアプローチを行っているのでしょうか。 IBM には、IBM Bluemix Garage というデジタル・トランスフォーメーションをサポートするサービスがあります。 前述の某航空会社での事例では、航空会社のエンジニアと IBM のエンジニアがペアになって開発を進めるなど、単純にコンサルタントが助言するイメージではないのが特長的です。 デザイン思考、リーンスタートアップ、アジャイル開発、DevOps など Bluemix 上で短期間にプロトタイプを開発する支援サービスは、非常に体験的なものであり、"助言し実施する"、というより "一緒に実践する" というものであることがわかります。 ウォーターフォール型に慣れ親しんだ企業であってもこのような体系的、かつ体験的なサポート（一緒にやってみせること）により、プロトタイプ開発を一通り経験することができるようです。 IBM Bluemix Garage のメニュー とは言っても、当セミナーでの本音トーク部分では、「現場は選ぶ」と話されていました。デザイン思考に向いている開発現場は、 内製化されている ビジネスと開発が密接に関わっている 失敗を許す文化がある のがポイントになるようです。 また、日本の典型的な IT 現場である、「サイロ化や SIer が絡む」、といった部分も上手くいかない原因になり得てしまう、とのことでした。 やはり、デザイン思考を取り入れていく中で、プロジェクトの規模やテーマ、メンバー選定、さらにサービスに至るまでの準備やマインドセット...等々 高度にコミュニケーションできて、創造的にアイデアを出し合えて、さっさとプロトタイプ開発できるような前準備が大事ポイントとなるのだと、と感じました。 デザイン思考は、プロセスから能力へ 最後に本質的な課題を一つ。実はイノベーションが出てこないことやその枯渇が問題ではなく、そもそも製品企画や開発の「プロセス」が問題、となることがあります。このような場合、一通り、コストをかけてデザイン思考のプロセスを回してみても「何も生まれなかった、平凡なアイデアしか生まれなかった」となることが多々あります。 実はまず課題解決すべきは、製品やサービスの「イノベーション」の部分ではなく、その発生プロセスである場合が多いのです。このイノベーション・プロセスをデザイン思考を通じて立て直していく、再構築するということが、「イノベーション」への遠いようで近道となるのかもしれません。 そこで重要になるのが、「何のためにツールを使うのか」という目的設定であり、縦割りではなく組織を横断的に、時には外部にも広げられる柔軟さではないでしょうか。 デザイン思考の世界的広がりの中心であるスタンフォード大学での今の流れを説明した記事を引用して終わりにしたいと思います。 デザインのやり方にお手本はない 現代はとかく忙しいものです。でも何かを究めるには時間と忍耐と実践が必要です。時には初心者にプロセスに従ったデザインを勧めるのも理解できますが、そのプロセスは絶対的でもお手本でもないことをしっかりと理解して下さい。それによって少しはできるようになった気がするかもしれません。デザインは常に進化し続け、多かれ少なかれプロジェクトにポジティブなインパクトを与える洗練された触媒なのです。しかし、そこに至る道には決まりきったプロセスなどないのです。 Medium Japan「デザイン・プロセスの話はもうやめよう」、Carissa Carter （2016年11月19日） もはや、d.School では、型通りのプロセス（レシピ）を重視しておらず、料理で言えばそのレシピ通りではないオリジナリティあふれる料理を生む「能力」を重視しているとのことです。 当然と言えば当然なのですが、ここに「デザイン思考」の難しさというか、面白さがあるのではないでしょうか。 次回は、本特集の最終回、デザイン思考の事例として IBM Studios Tokyo を訪ね、いろいろお話をお聞きしたいと思っています。
最近「デザイン思考」という言葉をよく聞くようになってきました。IBM社が大量のデザイナーを採用していると話題となっています。そんな中、そろそろ「デザイン思考」って何？自社も取り組むべきなの？と、疑問に思っている方も多いのではないでしょうか。 Wikipedia によると「デザイン思考」とは、 " デザイン思考（でざいんしこう、英: Design thinking）とは、デザイナーが デザインを行う過程で用いる特有の認知的活動を指す言葉である。" とのことですが、正直いいまして、私には全く理解できませんでした。 もう少しわかりやすい定義はないかと探してみますと、イノベーション創出サービスを提供する btrax の記事によると、 " 全てを “Why” から始め、最終的にイノベーションを創り出すプロセス" 出展： btrax, 「【やっぱりよくわからない】デザイン思考ってなに？」 とあり、問いを元にイノベーションを創出するための過程とのことで、おぼろげにその概要が見えてきました。 しかし、これでもデザイン思考とは何なのかを理解するにはなかなか難しいと感じました。 そこで、最近よく聞くこの「デザイン思考」について書いてみたいと思います。 ユーザー中心の思考法からイノベーションを生み出す 思考法としての起源は1960年代後半にさかのぼるようです。ビジネスへの応用は、スタンフォード大学で、後に IDEO を創業するデビッド・ケリーによって開始されたと言われています。 ※ IDEO ：カリフォルニア州パロアルトに本拠を置くデザインコンサルタント会社 デザイン思考の「デザイン」とは、いわゆる、デザイナーが絵を描いたり、色を塗ったりすることではありません。デザインには、「新しい機会を見つける為の問題解決プロセス」という定義もあり、デザイン思考においては、この意味になります。 デザイン思考のビジネス応用の研究をスタートさせたスタンフォード大学には d.school という学科横断型のプログラムがあります。機械工学、コンピュータサイエンス、ビジネス、法律、文学など様々な学部学科から学生や教職員が集結、デザイン思考を学びながら、分野を越えてイノベーションを生み出していく力を身につけています。 その d.School 発行のデザインガイドによるとデザイン思考には、5つのステップがあります。 デザイン思考、人間中心の協調的問題解決アプローチ Step1： 共感（Empathize） ・・・ 共感のためのヒアリング Step2： 問題定義（Define） ・・・ 本当に解決すべき問題を定義する Step3： 創造（Ideate） ・・・ 問題解決のアイデアを拡散させる Step4： プロトタイプ（Prototype） ・・・学びを得るために試行する Step5： テスト（Test） ・・・ 解決策を改善し評価する ※ 上記のステップを繰り返し改善する これらを進め、繰り返していくことで、既成概念を排除し、ユーザーに焦点を当てた商品やサービス、またチーム全員が同じ方向を目指して、デザインすることが可能となります。 デザイン思考において最も重要なことは、「ユーザーに焦点を当てる」ということです。とにかく、デザイン思考は、ユーザー中心、ユーザー・ドリヴンな思考法ということがポイントです。 なぜいまデザイン思考なのか？ それでは、なぜ今、デザイン思考が注目されているのでしょうか。 現在、グローバルエコノミーにおける先進企業は、生き残りをかけ、イノベーションを生み出し続けなければならい状況にあります。日本では、優等生とされていた大企業の没落、海外企業への身売りなど、これまでのビジネスモデルや製品サイクルが急激に変化する状況にあります。 日本のみならず、全世界的に新興国発の企業、またベンチャー企業などから攻勢を受け、競争も激化し、大胆に収益モデルの転換を余儀なくされています。 また、スマートフォンを始めとするテクノロジーはどんどん進化するものの、成熟した社会におていては、ヒット商品が生まれにくい状況にあります。単なる性能強化や機能の充実では消費者を満足させ続けられなくなってきています。 このような状況下において、顧客が真に欲するもの、顧客すら気づいていないニーズを掘り起こす、「イノベーションを生み出し続ける」ユーザー中心の思考法としてデザイン思考が注目されているのです。 IT 業界と「デザイン思考」 さて、それでは我々の IT 業界でのデザイン思考の浸透度はどのようなものになっているのでしょうか。 日経ビジネスオンラインによると IBM 社はグローバルで、 "2012年には375人にすぎなかったIBMの社内デザイナーの数は、2015年には1100人にまで増加。さらに2017年には1500人に増やす計画だ。" 出展： 日経ビジネスオンライン, 「米IBM、2017年にはデザイナー1500人体制へ」, 2016年7月28日 としており、デザイン思考を現場で実践するためのデザイナーを相当な勢いで増やしています。 また、 "独ソフトウェア大手SAPも変革の手段としてデザイン思考を活用したグローバル企業です。直近5年で全世界の売り上げを1.4兆円から2.7兆円まで2倍近く伸ばした背景に、デザイン思考がありました。” 出展： Forbes, 「世界的企業は今、なぜ「デザインx経営」なのか？」, 2017年3月29日 とあり、SAP は、デザイン思考によって既に結果を出している企業の一つとのことです。余談ではありますが、スタンフォード大学の d.School は、SAP 創始者のハッソ・プラットナーの個人の寄付により設立されたことからも早い段階から SAP がデザイン思考に注目していたことがわかります。 Salesforce 社でも Ignite と呼ばれるデザイン思考の専門支援チームが、顧客のためのデジタル・トランスフォーメーションのビジョン作りを支援しています。 例を挙げるときりがないほど、多くの IT 企業でデザイナーが活躍し、デザイン思考が活用されていることがわかります。 以下は Techcrunch が、IT関連企業でのデザイナーの需要はこれまでになく高まっているとし、6社でのザイナーとディベロッパーの比率を割り出したもののまとめです。 明らかに、IT 関連大手企業でのデザイナーの採用が増えていることがわかります。 Atlassian Dropbox Intercom 2012年 2017年 1:25 → 1:9 2013年 2017年 1:10 → 1:6 2017年 1:5 LinkedIn Uber IBM 2010年 2017年 1:11 → 1:8 2017年 1:8 2012年 2017年 1:72 → 1:8 出典： Techcrunch, 「過去5年間でデザイナーの採用目標が倍増― ―大手6社のデータに見るデザイン人材の動向, 2017年6月2日 とは言ってもデザイン思考ってそんなに簡単なの？ それでは、デザイン思考を日本の IT 企業が実践していくことは、簡単なのでしょうか。 これは、「その会社による」としか言えません。 単純に「デザイナー」と呼ばれる方を社員として迎えたり、プロジェクトごとに配置したりすれば成功するようなものでもありません。前述の d.School がまとめた「デザイン思考に必要な39のメソッド」では、その題名だけからも 39 ものメソッドが必要というこで、その難しさを物語っています。 日本でもデザイン思考を大学で教えたり、研修が受けられるようになったりしてきました。しかし、短期研修ではなかなか上手く実践するところまで到達するのは難しく、また大学で勉強してきたとしても受け入れ側の態勢が整っていない、というのが現状のようです。 そこでまずは、自社が「デザイン思考」のメリットを享受しやすい文化にあるか？というところからチェックしてみるのはいかがでしょうか。 ＜デザイン思考のための社風チェック＞ 行動よりも先にリスクに目が行ってしまう 製品開発は、プロセスごとに縦割り、分業で、企画から製造までメンバーが共に創っている感覚がない ユーザーの声を傾聴するよりもコントロールすべきだと考えている ブレーンストーミングをやったことがない、やっても上手くいかない 会議ではいつも決まった人が発言している 上記に一つでも当てはまることがあれば、デザイン思考を実践する前に自社のマインドセットを切り替えに注目した方がよいかもしれません。 多くのデザイナーを採用している IBM 社であっても、デザイン思考の導入には以下のようなアプローチを踏んでいます。 " IBMは巨大かつ複雑な組織で、製品のテクノロジーも複雑です。デザイナーが入社後、それぞれのチームに入る前に“橋”をかけるようなサポートを行う必要がありました。現在、新たなデザイナーに対して3カ月のブートキャンプ・プログラムを実施していますが、私は、その設計と運営、管理を行いました。 また、このデザイナー向けのプログラムを実施していく中で、IBM全社員に対しても、デザイン及びデザイン思考について教育を行い、会社を変化させないといけないことがわかりました。なぜなら、全社員も、企業としてどのような方向に変化していくのかを知る必要がありますから。 そこで一人でも多くのIBM社員がデザイン及びデザイン思考を体験し理解するための教育プログラムをつくりました。デザイナー向けから全社員向けに、私の役割はここ数年でこうした変化を遂げてきました。" 出典： Forbes, 「IBMがデザイナーを1000人雇い、デザイン思考を推める理由」, 2017年3月24日 まずは、デザイン思考を知り、この思考法を社内で展開できる雰囲気か判断し、そうでなければまずは、その目的づけ、会議や打ち合わせのやり方、ユーザーとの接し方、縦割りのプロセスなどを見直すところから始めてみてはいかがでしょうか。 いきなり、「デザイン思考」ありきからスタートすると、単なる思考法マニュアルになってしまい、「デザイン思考でやってみたが何も起こらない」となってしまう可能性があります。 それでは、デザイン思考そのものの恩恵を十分享受し、真のイノベーションに到達することは難しいでしょう。 クラウドとデザイン思考 では、具体的に何か製品開発にデザイン思考を応用した例はないかと探してみると、身近な良い例がありました。それはBluemix です。Bluemix はデザイン思考を元に開発された製品なのです。 ”The Bluemix team used IBM Design Thinking to focus on users—not functions or capabilities—with the goal of letting developers focus on their work, rather than on infrastructure and configuration. 【抄訳】Bluemix チームは、IBM デザイン・シンキングを使用して、インフラやコンフィグではなく、開発者が自分の仕事に集中できるように、「ユーザー」～ 機能や能力ではない ～ に焦点を当てました。" 出展： IBM Design, 「Case study: IBM Bluemix」, 2014年7月17日 また、当プロジェクトでは、多くの人数と時間をユーザーとの時間に費やし、マネジメント、エンジニアリング、設計、マーケティングに至るまで、一同が関わり、共創することで、計画より半年以上前倒しして、Bluemix を完成させることができたとのことです。 ここでは、多くを触れませんが、このような形で、IBM 社のクラウド戦略の根幹をなす製品開発にデザイン思考が活用され、成果が出ていることがわかります。 Bluemix でのケーススタディでもわかる通り、イノベーションのプラットフォームとしてのクラウド活用が今後進んでいくことは間違いないでしょう。それは、Bluemix の特長を例にとると、 100以上のサービス連携が提供される これらの組み合わせで、より早く幅広いアプリケーションを作ることが容易 使用インスタンス等で課金されるため都度必要な分のコストで小さく始められる など、デザイン思考のような、プロトタイピングを重視する早期実行型の思考法にマッチしやすいと考えられるからです。 今後は、IT企業だけではなく、別業態からもクラウドを中心にイノベーションを進めていく企業がどんどん増えるはずです。これらの企業や迎え撃つ既存の IT企業の開発者は、サーバー構築や運用の労力にとらわれず、プログラミングに集中できるBluemix をベースに新たなサービスを模索したり、構築を進めたりすることは自然な選択ではないでしょうか。 更に、デザイン思考をベースに開発された Bluemix 上で、デザイン思考を活用し、イノベーションを実現する、これらは非常に相性の良い組み合わせかと容易に想像できます。 今後もデザイン思考の取り組みにも注目していただければ幸いです。次回は「デザイン思考導入を阻むもの」について考えてみたいと思います。
ITトレンドとして「ハイブリッド・クラウド」という流れがありますが、一般的に「ハイブリッド」と言えば「ハイブリッドカー」が思い浮かぶのではないでしょうか。ということで、今回は、ITトレンドのハイブリッド・クラウドをハイブリッドカーの歴史を紐解くところから、考えていきたいと思います。やや強引ではございますが、お付き合いいただければ幸いです。 ハイブリッドカーの歴史 世界初の「量産ハイブリッドカー」として、1997年12月 プリウスは"21世紀に間に合いました"のキャッチコピーのもと、発売が開始されました。価格は、215万円、当時同じガソリン車の4ドアセダンと比較すると50万円ほど割高な価格設定でしたが、最新テクノロジー車としては破格の低価格で、補助金も追い風となり、販売台数を伸ばしました。 発売時点で欧米の自動車メーカーの反応は、非常に冷ややかなものでした。それは、「ハイブリッドカーはつなぎの技術」という認識で、次世代カーは、電気自動車や燃料電池車であり、ハイブリッド・カーには利点はないと考えられていました。 しかし、日本では、補助金の追い風、ホンダ、日産など、トヨタ以外の自動車メーカーの意欲的な追随、更に燃費が悪いのが当たり前だったミニバンへの搭載など、徐々に「環境にやさしい車」としての地位を築いていきました。また、アメリカでは、環境意識の高いハリウッドセレブたちがこぞってアカデミー賞の授賞式にプリウスで乗り付けるなど、欧米でも注目を集めるようになりました。 プリウス発売から遅れること10年、GM がシボレー・ボルトを、2009年にはメルセデス・ベンツが S400 ハイブリッドを発売しました。いまや、欧米メーカー各社からハイブリッドカーが、更に大型車や軽自動車にもハイブリッド技術が採用され、スタンダードなテクノロジーとして確立されていることは皆さんもご承知のとおりです。 クラウド・コンピューティングの流れ さて、前置きが長くなりましたが、クラウド・コンピューティングの世界に話を移しましょう。 今、クラウド環境は、目覚ましい勢いで様々な企業に利用されています。日本でも大手銀行が大規模導入を発表するなど、大企業でのクラウドへの移行は更に加速するものとみられています。 料金体系のバリエーションが増え、アプリケーションをオンプレミスからクラウドに移行するツールの発達、また、ハイパー・コンバージド・システムなどの新たな技術がクラウド環境の構築や運用の簡略化の推進に貢献しています。 注目されるハイブリッド・クラウド 前述の自動車の世界では「ガソリン車から電気自動車／燃料電池車へ」と考えられている間に、現実解となるハイブリッドカーでプリウスが成功を収めました。 IT トレンドでも「オンプレミスのクラウド型 IT インフラか、パブリック・クラウドか」という二つの選択肢の中で自動車業界と同じようにやはり、「ハイブリッド・クラウド」が注目されています。「ハイブリッド・クラウド」とは、 ”オンプレミスとパブリックという異種のクラウドを連携して使い分け、両者のメリットを最大限活用すること、およびそのための仕組み” 出展：IT Leaders【最終回】ハイブリッドクラウドはオンプレミスもクラウド型に変革 2015年12月22日 とのことです。プライベート、およびパブリックを上手く使い分け、そのメリットを享受することが今、常識といっても過言ではない状況になっています。しかしながら、クラウド導入の際に、オンプレミス型のクラウドか、パブリック・クラウドか、どちらを選択するか？という悩みは尽きません。日経クラウドファーストの記事によると "パブリッククラウドをコスト削減を目的に導入しようとして、実はかえって高コストになってしまった" というケースが多いとのことです。 参考： 日経クラウドファースト 「知らない間に高額請求、クラウド破産にご用心」 2017/02/22 上記の記事のように、先進企業でのクラウド利用が広がったことにより、各種クラウドのメリット・デメリットが見えてきています。 パブリック・クラウドを利用することで、構築を容易にし、短期間でアプリケーションをまわし始めることが可能になります。しかし、経験として、アプリケーションの成熟とともにかえってコストが高くなってしまう場合があるということがわかってきました。システムによっては、オンプレミス型のクラウドの方がコスト安となる場合があり、このことからも、パブリック、プライベートの両方の利用を最適化する「ハイブリッド・クラウド」は過渡期のつなぎの技術ではなく必然的な流れとしてとらえることが自然と考えられます。 ハイブリッド・クラウドの利用状況 「70%の企業が従来型ITとクラウドが混在した環境を今後も利用する」 と回答、 IBM 社の調査によると "従来型ITとクラウドが混在した環境を今後も利用すると回答した企業が70%に及んでいる" 出展:『躍進するハイブリッドクラウド-デジタル変革を加速する- 』日本IBM 2016年2月 とのこと。クラウド環境のハイブリッド化は常識との認識より、企業がパブリック・クラウドとプライベート・クラウドの両方を採用する状況は今後も続くと考えられます。 ハイブリッド・クラウド利用で成果を挙げる企業 ハイブリッド・クラウドの利用で成果を挙げる企業でチェイサー（利用の初期段階）とフロントランナー（競争優位を獲得している先行企業）では、各領域においての成果の割合は2～4倍の差があります。 出展：『躍進するハイブリッドクラウド - デジタル変革を加速する -』日本IBM 2016年2月 先進企業とこれからチャレンジする企業とで大きく差があるのが「デジタル・ビジネスの推進」です。再び IBM 社の調査によると "デジタル・リーチの重要性を認識しているフロントランナーの中で、ハイブリッド・クラウドを利用して付加価値を高めると同時に、プラットフォームを問わずシームレスなユーザー体験ができる新しいデジタル・サービスを提供する割合が、チェイサーに比べて 4 倍高いことが明らかになりました。 驚くべきことに、フロントランナーの 82 パーセントは、ハイブリッド・クラウドにおいて設定可能な API を組み合わせて用いることにより、製品やサービスの革新を迅速かつ頻繁に行っています。また、ハイブリッド・クラウドは、イノベーションのプロセスをワークフローの合理化を通じて加速することができます。" 出展:『躍進するハイブリッドクラウド-デジタル変革を加速する-』日本IBM2016年2月 としており、デジタル・サービスを提供している企業が4倍多く、さらに製品サービスのイノベーションをハイブリッド・クラウドを活用して実現していることを物語っています。 オンプレミス型の既存 IT システムをパブリック・クラウドを経由して素早く API として公開するなど、デジタル・ビジネスを推進することが可能です。既存の企業情報資産を API として公開することにより、外部の開発者が自ら利用できるようになり、革新的なアイデアをアプリ化し、そのことにより新たな顧客体験を提供したり、企業のブランド価値を引き上げることができるのです。 まとめ ハイブリッドカー、そしてクラウド・・・ 前述のハイブリッドカーは当初、エンジン車から電気自動車や燃料電池車への移行の過渡期に出てきた技術のように思われていました。しかし、プリウスの成功により、電気自動車や燃料電池車への投資を推し進めていた欧米の自動車メーカーはハイブリッドカーへの投資を数歩遅れて開始し、後塵を拝しました。 もちろん、電気自動車や燃料電池車への切り替えは、益々進むと思われますが、ハイブリッドカーが一世を風靡したという、この流れは今の IT テクノロジーを考える上で示唆を与えてくれていると思います。 クラウド・コンピューティングのこれからは、既定路線としてハイブリッド・クラウドを見据え、その活用を検討することが重要です。また、レガシー・システムと新しいテクノロジーを理解した人材を確保し、適切に配置することもポイントとなるでしょう。 ハイブリッド・クラウドによって成果を挙げるには様々な領域でのアプローチが可能です。セキュリティや経験の少なさから二の足を踏んでしまっているのであれば、企業内の情報資産に目を向け、ハイブリッド・クラウドを活用し、安心して API を公開することで、新たな企業価値を生むことも一つの検討材料になるのではないでしょうか。 ハイブリッド・クラウド環境に欠かせない！「IBM API Connect」 IBM API Connect は、オンプレミス環境およびクラウド環境の両方で、API ライフサイクルの重要な局面を支援するための API 管理ソリューションです。 モバイルやクラウド、B2B 等への対応のため、企業に対する API 開放圧力は高まり続けています。IBM API Connect は直感的なユーザー・インターフェースと実績あるゲートウェイ・アプライアンスによって、セキュアかつコントロールされた企業 API エンドポイントの作成・保護・実行・管理を可能にします。 簡単操作での API 公開： API の作成から公開まで、コーディング無しに Web GUI から簡単に設定可能 開発者ポータル：カスタマイズ可能なポータルで API 仕様の公開やアプリ・キーの発行、開発ユーザー管理を実現 セキュリティー：暗号化、認証、アプリ・キー管理、OAuth2.0 サポートなど、多様なセキュリティー機能をゲートウェイ上に実装 実績あるゲートウェイ：長年に渡り Web サービスを保護してきた実績を持つ、堅牢かつ高性能な DataPower を活用 柔軟な提供形態：オンプレミスや IaaS の専用環境や Bluemix 上の SaaS サービスとして利用可能、相互移行もシンプル 当特集記事が、ハイブリッド・クラウドや API 管理ソリューションのご検討に、少しでもご参考になれば幸いです。
前回は、以下の記事で、セキュリティ・トレンドである SIEM の基本についてご紹介しました。 ▼【今さら聞けない】セキュリティ・トレンド「SIEM」って？ 今回は、増え続けるモバイル・デバイスとそのセキュリティ対策の基本について考察してみたいと思います。 増え続けるモバイル・デバイスとセキュリティ対策の遅れ カバンや上着のポケットにいくつものモバイル機器が入っている方も多いのではないでしょうか。 会社貸与の PC や携帯、私用のスマホ、タブレット PC などなど、マルチデバイス化がかなりのスピードで進んでいます。会社からノート PC は支給されているが、個人持ちのスマホも業務に使用し、企業が認識していない IT 機器として"シャドー IT" と言われるようになって久しい昨今です。 ふと不安になるのは、このカバンを無くしたら大変なことになってしまう、ということです。 会社は紛失等の注意喚起や発生後に罰則を科すことはしますが、ある意味紛失等のリスクを個人に押し付けているとも言えます。いくら、各個人が気を付けていても盗難にあったり、紛失してしまったりすることは発生してしまうものです。 MMD 研究所の「スマートフォンの業務利用動向調査」によると、 私物のスマートフォンを業務利用していると回答した人を対象に、「私物スマートフォンのセキュリティ対策」について質問したところ、「対策をしていない」と回答した人は60.6％に上った。 出展：「業務で私物スマホを使う人の6割が「セキュリティ対策をしていない」と回答--MMD調査」、2016/11/18、CNET Japan とのことで、業務で使用している私用のスマホが何も対策がなされていない危機的な状況にあることがわかります。 モバイル・デバイスの企業利用のリスクとその対策 それでは、このような増え続けるモバイル端末に、どのようなリスクがあり、対策がとれるかを考えていきたいと思います。 ◆増大するモバイル・セキュリティ市場 まず、IDC Japan がまとめたモバイル・セキュリティの市場規模予想から企業向けのモバイル・セキュリティー市場の注目度を見てみましょう。 IDC Japan は2016年10月25日、国内の企業向けモバイルセキュリティ市場に関する調査結果を発表した。2015 年の市場規模は前年比 21.3 ％増の 56 億円。2015～2020年の年間平均成長率は16.1％で、2020年の市場規模は118億円に拡大すると予測した。 出展：「広がるモバイルセキュリティ市場、2020 年まで毎年 16 ％で成長」、2016/11/04, ITpro クラウド・サービスの利用拡大、さらに情報系システムだけでなく、基幹システムまでもモバイル・デバイスの活用が広がるとの見込みもあり、企業向けのモバイル・セキュリティ市場は拡大傾向にあることがわかります。 ◆企業システムのゲートウェイ（入口）として標的にされるモバイル・デバイス 紛失した PC やスマホ が、悪意ある取得者の手に渡れば、ログインやパスコードは破られてしまうという危機感を持っていることが重要です。また、今後は、スマホが企業をターゲットにした攻撃の開始ポイントになるとの認識が必要です。 チェック・ポイント・ソフトウェア・テクノロジーズ社は、以下のようなサイバー・セキュリティ動向予測を発表しています。 現在は、企業・組織に標的型メールを送り付けることで内部への侵入を試みるケースが多いが、今後は、そこに属する人のモバイルデバイスをターゲットとする手法が増えると予測する。「モバイル端末に入りこみ、それをゲートウェイ（入口）にする。攻撃の開始ポイントになり得る」と卯城氏は話す。 モバイルデバイスに対する攻撃はすでにいくつも確認されており、同氏は16年8月に発見された iOS のゼロデイ脆弱性「トライデント」を悪用した例を紹介した。あるジャーナリストの iPhone にスパイウェアを送り込み、その活動をモニタリングし、情報を取得していた例が確認されているという。 出展：「チェック・ポイントが2017年のサイバー攻撃を予測 ―― モバイル・IoTデバイスが標的に」、2016/12/01、business network.jp 前回の特集で 大手旅行代理店のケース をご紹介しましたように、これまで標的型の攻撃は "メール" が主流でしたが、今後はシャドーIT を含む "モバイル・デバイス" に対する標的型の攻撃に気を付ける必要がありそうです。 モバイル・セキュリティを確保する MDM（Mobile Device Management）とは 企業のモバイル・デバイス活用は、今後進めざるを得ない状況です。そのような中で、モバイル・セキュリティを確保するには、各端末のセキュリティ設定や紛失時の対応など、様々な種類のモバイル・デバイスを統合的に効率よく管理する仕組み、MDM と呼ばれるソリューションが必要となります。 e-Wrds によると、MDM の以下のように定義されています。 MDM とは、企業などで社員に支給するスマートフォンなどの携帯情報端末のシステム設定などを統合的・効率的に管理する手法。また、それを実現するソフトウェアや情報システムなどのこと。 MDM では、社員が使用する端末の設定などを管理部門で一元的に管理し、社の方針に沿ったセキュリティ設定を施したり、使用するソフトウェアの種類やバージョンを揃えたり、利用できる機能に制限を加えたり、勝手に私用のソフトやデータを導入できないようにする。端末の紛失時に遠隔からデータを消去したり、操作できないようロックをかけたり、GPS 機能で社員の居場所をリアルタイムに把握する製品などもある。 出展：「MDM 【 Mobile Device Management 】 モバイルデバイス管理」、 e-Words MDM のソリューションにより 企業での利用が増え続けるモバイル・デバイスを統合的、かつ効率的に管理し、セキュリティ・リスクを低減することが可能となります。 モバイル・セキュリティ・ソリューション導入のポイント それでは、MDM 関連の企業のモバイル・セキュリティ・ソリューションを導入する場合のポイントを具体的に見ていきましょう。 【ポイント1】デバイス、コンテンツ、データの保護 はじめに、モバイル・デバイスはその性質上、端末自体を社外に持出し利用します。リモート・ワークも増えることが予想され、個人所有のデバイスの利活用の課題も含め紛失、盗難にあった場合の対策を検討すべきです。その対策の実現には、以下の機能を有した製品、ソリューションの選定が必要となります。 会社から貸与、および個人所有のデバイス（BYOD）まで、多彩なモバイル端末に実装して管理できる 企業が独自開発のモバイル・アプリケーションを安全化し、データ漏えいから保護できる （※1） モバイル端末で安全にファイルや文書を利用・共有できる（※2） 【ポイント2】不正アクセスと詐欺の検知・対策 次に、不正アクセスや詐欺といった脅威のターゲットがモバイル・デバイスにも広がりつつあります。会社提供、個人所有に限らずインストールできるアプリケーションやアクセスできるサイトを抑止し、不正を検知する必要があります。以下の対応が重要なポイントになります。 無許可のモバイル・アクセスを防ぐことができる モバイル・マルウェアや不正アプリケーションを検知できる クラウド・ベースの脅威インテリジェンス（最後に確認された場所などの情報の集合体）をもとにした分析ができる 【ポイント3】セキュリティ・インテリジェンス（※3）への対応 最後に、現在では、セキュリティ・ポイント毎の脅威の監視・検知だけの対策では限界となってきており、脅威の侵入を前提とした統合的な対策が求められています。モバイル・デバイスが脅威の入口として、また脅威そのものとして、その振る舞いの傾向を監視対象とすべきです。 モバイルを含むセキュリティ・イベント全体での傾向を特定できる 企業が潜在的な攻撃に素早く対処でき、誤検出の結果を排除できる イベントやセキュリティ・ログなどの情報をリアルタイム収集し、手間なく分析が可能である MDM を始めとし、モバイル・アプリケーション管理（MAM）（※1）やモバイル・コンテンツ管理（MCM）（※2） を統合的に実現するモバイル・セキュリティ・ソリューションを導入することにより、社員個人に任せていたモバイル・セキュリティ対策を企業全体の課題として人的コストを増大せずに実現することが可能です。 （※1） モバイル・アプリケーション管理（MAM）："ラッピング"、"モバイル・アプリコンテナ"などの技術を使って、デバイス全体ではなく、業務アプリケーションとそのデータを管理するシステム （※2） モバイル・コンテンツ管理（MCM） ： モバイル・デバイスを対象として、閲覧、コピー、期限設定による削除など企業文書を安全に管理する機能を提供するシステム （※3）セキュリティ・インテリジェンス ： イベントログやセキュリティ・ログに加えて、ネットワーク・トラフィック情報をリアルタイム収集し、自動的に正規化、知見を活かした提供ルールに基づいて分析する機能 まとめ 企業で活用が進むモバイル・デバイスですが、個人所有の端末を含め、そのセキュリティー対策は遅れており、MDM などの対策は急務となっています。今回の特集"モバイル・セキュリティ"に関する当記事のポイントは以下になります。 企業でのモバイル・デバイスの活用は更に進むが、個人デバイスやシャドーIT 含め、対策が遅れている モバイル・セキュリティーの市場規模は年 16 % 以上の伸びで推移することが予測されており、拡大傾向である 今後、モバイル・デバイスは、標的型攻撃のゲートウェイとしてターゲットになる可能性がある MDM（Mobile Device Management）はモバイル・デバイスのシステム設定などを統合的に管理する手法でモバイル・セキュリティを確保する上で必要なソリューション モバイル・セキュリティ・ソリューション導入のポイントは、以下の3つ デバイス、コンテンツ、データの保護 不正アクセスと詐欺の管理 セキュリティ・インテリジェンスへの対応 モバイル・セキュリティの実現はIBM MaaS360で 今回は、企業のモバイル・セキュリティの確保のための MDM、そして、MAM、MCM の重要性について考えてきました。ここで、それらの機能を有する IBM の統合的なモバイル・セキュリティ・ソリューション、IBM MaaS360 をご紹介したいと思います。 IBM MaaS360 は、スマートフォンやタブレット端末に対して、自社のセキュリティ・ポリシーに応じ、遠隔操作（リモートロック/ワイプ）や端末管理を、異種混在の状態でも一元管理することができるソリューションです。 モバイル・デバイス管理（MDM）、モバイル・アプリケーション管理（MAM）、モバイル・コンテンツ管理（MCM）、を包括した、エンタープライズ・モビリティ管理（EMM）を実現するソリューションで、SaaS型、自社運用型（オンプレミス）の２つのタイプを提供します。 ＜ IBM MaaS360 の特長 ＞ MDM 機能 ロック、ワイプ、パスワード変更、位置情報 迅速なモバイル・デバイス登録を実現、管理者、ユーザそれぞれ負担を軽減 インベントリーやデバイス・ポリシーの管理と制御を提供 MAM 機能 企業領域から私用領域へのコピーが制限 特にユーザー所有のデバイスから安全にメールやWeb アクセスができるアプリケーションを提供 企業領域から私用領域へのコピーが制限 MCM 機能 データ漏えい防止機能で重要情報を保護 コンテナ向けにドキュメントを配布、認証によって使用許可を与えます データ漏えい防止機能で重要情報を保護 モバイル関連のイベントやセキュリティ・ログも次世代SIEMのIBM QRadarで "モバイル・セキュリティ・ソリューション導入のポイント" の3つ目に "セキュリティ・インテリジェンスへの対応" について述べましたが、各セキュリティ・ポイント毎の監視・検知では、日々進化する脅威を完全に防ぐことはできません。企業のモバイル・デバイスの活用が進み、攻撃のゲートウェイとして注目されている中、モバイル関連のイベント、セキュリティ・ログなどの情報を収集し、統合的に検知・分析する仕組みが必須です。 前回の特集でも紹介しました次世代 SIEM の IBM QRadar 製品は、デバイス・サポート・モジュール (DSM) と呼ばれるプラグイン・ファイルを使用することにより、各種セキュリティ製品からのイベントの収集を行うことができます。MaaS360 もサポートしており、MaaS360用の DSM を使用し MaaS360コンソールよりイベント・ログを収集することができます。 包括的なモバイル・セキュリティ、および管理を実現する、IBM MaaS360、モバイル関連のイベント、セキュリティ・ログ情報を含む、次世代SIEM を実現する IBM Security Qradar をご紹介しました。 当特集記事が、今後 モバイル・セキュリティを検討する中で、少しでもご参考になれば幸いです。
