特集・ブログ
Domino が誕生してから35年以上が経過し、IBM から HCL に移管されて丸６年が経ちました。 Domino は、高い開発生産性と堅牢性を兼ね備えたアプリケーション基盤で、長きにわたり企業の業務効率化を支えてきた歴史ある製品です。一方、重ねてきた実績の分だけ、バージョンアップに対する課題も垣間見えます。 今回は、エイチシーエル・ジャパン株式会社 HCLSoftware のテクニカルリードである松浦光様に HCL Domino のビジネス状況や今後の展開など、多岐にわたり話を伺いました。（本ページは後半です［前半も公開中］） 対談者 【ゲスト】 エイチシーエル・ジャパン株式会社 HCLSoftware テクニカルリード 松浦 光 様 【インタビュアー】 エヌアイシー・パートナーズ株式会社 技術企画本部 ソリューション企画部 松田 秀幸 ※対談者情報は2025年6月9日時点 新バージョン V14.5 が刻む新たな一歩 生成AI を Domino の中に ── この夏に新バージョンの出荷が予定されていますね。 松浦： はい、2025年6月にバージョン V14.5 の出荷が予定されています。 ── V14.5 のポイントは何でしょうか？ 松浦： 目玉の１つとして、Domino の中に AI を持つ「Domino IQ」 という機能がリリースされます。 なぜ、わざわざ自社で生成AI を持たなければいけないか、と思われる方もいると思いますが、理由の１つはセキュリティです。 Domino と生成AI の統合「Domino IQ」 自社のベストプラクティスを得られる ── 「Domino IQ」は、どのようなものでしょうか？ 松浦： 完全にローカルで生成AI を持つことで、機密度が高い自社の情報についても問い合わせできるようになります。 加えて、自社の Domino を20～30年使い続けているお客様は結構多く、その積み重ねた情報に注目しています。そこで、今まで溜め込んだナレッジを生成AI に教え込み、ベテランの方が持つナレッジや自社のベストプラクティスを回答する生成AI を作っていく 流れですね。 このような利用も考えて、Domino IQ を開発しています。 ── 生成AI のモデルは、HCL で作っているのですか。 松浦： HCL で開発しているわけではなく、オープンソースの LLM を使っています。今ベータ版で使えるのは、Meta社の Llama3.2 などです。 ゼロから HCL で作ったものではなく、もう既に賢く育てられた LLM を使える点が大きな強みの１つだと思います。RAG を使って LLM に足りない情報を学習させられるようになるので、自社のデータベースで蓄えていた情報を AI が活用できるようになります。 Domino による生成AI の活用方法 ── RAG による拡張はキーになりそうですね。 松浦： Domino に溜まっている色々な情報やデータを社外や国外の生成AI に出さなくても、Domino IQ で新しい使い方が可能です。 ── Domino と生成AI の組み合わせで業務効率も向上しそうですね。 松浦： Domino は、業界用語や社内用語なども扱える 『生き字引き』のような人に代わる存在になっていき、皆さんの業務を支えられる のではないかと考えています。 REST API による効率的なシステム間の連携 ── フロントエンドの作り込みはどうでしょうか。例えば、チャットボット以外の入口を作る必要はありますか？ 松浦： フロントエンドは何でもいいと考えていて、様々な Web やモバイルアプリに組み込むこともできますし、Notesクライアントが好きであれば Notesクライアントでもいいですし、Nomad Web でもいいと思います。Nomad Mobile というスマホやタブレット向けの Notesクライアント相当のものもあるので、それを使ってもいいですね。 ── 他社システムとの連携はどうでしょうか？ 松浦： 前半でも少し触れたディレクトリサービスの連携だけではなく、REST API で他社システムと繋ぐことも想定しています。例えばフロントエンドとしては、チャットボットはもちろん、それ以外にも様々なシステムから入力してもらうこともできます。 Domino IQ 用に設定された Domino Server は、Dbserver プロセスから推論エンジンを起動する。（画像クリックで拡大）（出典：HCL Software｜Configuring / Configuring users and servers / Domino IQ） 松浦： オープンソースの LLM を Dominoサーバーのデータディレクトリの下にインストールし、アプリケーションからの参照は、簡単な Lotus Script の読み込み・書き込みという２つのメソッドで問い合わせる仕様です。 先程も触れましたが、既存の LLM を使える点は大きな強みだと思います。 バージョンアップの鍵は互換性の安心感 新旧バージョンの互換性は移行チェックツールで担保する ── 互換性を気にされる方が多いと思いますが、いかがでしょうか？ 松浦： 12.0.1 については 64bit対応、Open Java への変更があり、10 から 14 のタイミングで足回りをアップデートしました。その対応も含めて確認したところ、アプリケーションの互換性に関しては問題はありませんでした。 それでも互換性に懸念をお持ちのお客様には、NotesConsortium（ノーツコンソーシアム）で会員特典として利用できる移行チェックツールの使用も検討していただきたいと思います。 NotesConsortium（ノーツコンソーシアム） Domino に関する様々な知識やノウハウを交換、蓄積して会員同志で共有するユーザーコミュニティ 引用 以前のバージョンの環境で動作していたプリケーションの互換性（＠関数/LotusScriptのみ） をチェックするツール、アプリケーションコードチェッカー（NDACC）をご提供しています。 カンタン移行判定ツールもご利用頂けます。 引用元：NotesConsortium「会員の特典」｜移行支援ツールの提供 移行チェックツールとその効果 ── 実際に 9、10 から、V14、V14.5 へのバージョンアップは、移行チェックツールで試した場合の非互換はどれぐらいでしょうか。 松浦： 非互換はほとんどありません。 一言で非互換といっても、インパクトの程度は異なります。少し見た目が変わってしまうといった軽微なものから、挙動が変わってしまうという大きなものまであります。 移行チェックツールも過去20年以上の歴史があり、インパクトが小さい内容もチェックする仕組みでしたが、今はインパクトが小さい内容はチェックから外せるようになりました。 ── 非互換性の影響が少なく、迅速かつ正確な対応が可能であれば、安心してバージョンアップできますね。 松浦： もちろんインパクトの大小に関わらずチェックすることもできるので、気になる方は互換性に関するすべての内容を把握できます。すべてを確認していただいても、大きな影響を及ぼすような非互換はほとんどない と思います。 バージョンアップ vs 他社製品への移行 バージョンアップはしないが、移行もしない ── 前半にも話があったとおり、Domino の旧バージョンを利用されているお客様は多いようですね。 松浦： はい、旧バージョンのまま利用されているお客様も多いです。やはり、「バージョンアップをしなくても現状で満足」というのが理由 だと思います。 ── 一方で Domino から別製品への移行を検討されるお客様の声も聞きます。他製品への移行が検討される理由についてはいかがでしょうか。 松浦： DX を旗印に企業の形を大きく変えたいと思われた時に、エンドユーザーが日々使う情報系システムを刷新するのは象徴的だと思います。特に社外から新しい CIO が来たという様なケースだと顕著です。 引用 DX推進の際の障壁としては、「投資するための予算確保が少ない」が最も多くなっており、今後DXをさらに推進していく上で、約4割が「IT投資にかかる予算の増加」に取り組みたいと回答しました。 引用元：一般社団法人 中小企業個人情報セキュリティー推進協会「アンケート調査レポート」｜「DX推進に成功している経営者」の実態調査アンケートの結果について ── DX の観点はひとつの肝かもしれませんね。 松浦： Web対応やモバイル対応、AI対応への再投資に対して、もっと価値を出していけるのではないかと考えています。 ── ただ、基幹的な情報系システムだと、気軽に移行するわけにはいかないですよね。 松浦： 他社ツールへのスイッチングコストの中には教育費を含め色々なものが発生するので、それだけお金をかける価値があるのかということに悩みながら検討されていると感じます。 やはりコストが大きいということで、移行ではなく共存で落ち着く ことがかなり多いですね。 HCL Domino の運用事例 内製化で自社の強みを生かしたDXを実践（日経XTECH） 20年で培ったデジタルカイゼンの文化 エームサービスの現場とIT部門をつなぐNotes（ZDNET Japan） 結論！バージョンアップが最適解 ── 他社製品への移行リスクや未知のコストも考えると、Domino を利用し続けるのがよさそうですね。 松浦： 異なる基盤でも併用して共存でき、互換性も担保されている ので最新バージョンアップでの利用をお勧めします。 ── ここまでの話以外で、他社製品への移行が検討される理由はありますか？ 松浦： お客様から、Notesクライアントの強力な機能は変わらずご評価いただきながらも、そのインストールやセットアップなどの運用管理はやはり大変だ、という声もいただいております。 ── 最新バージョンでも同様でしょうか？ 松浦： 最新バージョンでは改善されています。具体的には、V14 では ブラウザベースで Notesクライアントとほぼ同じようなことができる「HCL Nomad」という機能があります。特長は、専用Notesクライアントのインストールが必要ない点と、ブラウザベースなので複数の端末から使っていただける点です。 ── 「今までNotesクライアントでしかできなかったことが、Web でもできるようになる」ということでしょうか？ 松浦： 例えば、Excelマクロを使った帳票の集計業務などですね。これまでは、Notesクライアント内でオフィス系のアプリケーションを起動するようなものは、ブラウザのセキュリティ制限によりブラウザからの利用ができませんでした。 しかし、2025年6月に出る新バージョン V14.5 は「HCL Nomad Web」が COM をサポートするのが目玉機能の１つで、Nomad Web から Excel や Word や PowerPoint を起動してマクロ実行などができるようになります。 ── V14.5 における進化の１つですね。 松浦： はい、バージョンアップの利点ともいえます。 すでに、以前から使用されているお客様がトライアルを始めている という状況です。 バージョンアップを推奨する理由 新旧バージョンの互換性を担保している。 コミュニケーション基盤が別製品でも、Domino を併用できる。 Domino IQ の実装／HCL Nomad Web の COMサポート HCL Domino について問い合わせる 今後の戦略 V14.5 は 描いたロードマップの答え合わせになるバージョン ── 今後の HCL の Domino のロードマップ、戦略はどのようになっているでしょうか。 松浦： この夏に出荷予定の V14.5 では実行環境のアップデートやスマホ・Web対応の進化や生成AI連携など、HCL になってから大きく描いたロードマップの答え合わせになるバージョンです。 アプリケーションを作り、うまく使ってもらう というのが、Domino の軸になっていると思います。Notesクライアントで動くアプリケーションから Webブラウザやモバイルで動くアプリケーションまで、様々なものがあります。それらを支えていくというのが Domino の DNA です。 ── 確固たる理念と設計思想があるのですね。支えるためには、Web対応や生成AI連携なども見越した拡張性も重要だと。 松浦： 作成したアプリケーションを拡張していくという方向性として API連携が挙げられます。Domino だけで全ての業務が回るとは考えていないので、周辺の製品サービスとの連携が簡単にできる というのがポイントの1つです。 兄弟製品に繋げる二段構えの展開 ── バージョンアップ以外での、ビジネス戦略は何かありますか？ 松浦： アーキテクチャは異なりますが、開発環境の観点も含めれば兄弟製品といえるものがあります。 例えば Volt MX という製品には、モバイルOS を含む様々なプラットフォームのネイティブアプリケーションを作る機能があり、単一の開発環境で作成できます。 ── 開発するアプリケーションによって、戦略の幅が広がりますね。 松浦： Volt MX は一例ですが、プラットフォームを問わず使っていただけるような 本格的なアプリケーションについては兄弟製品 に繋げていく、という二段構えの戦略を考えています。 ── 兄弟製品への横展開…Domino が秘めるビジネスの可能性といえそうですね。 松浦： 今後のロードマップは、我々が描いた V14.5 の評価をユーザーから得ながらアプリケーションの軸はぶらさずに兄弟製品と補完しながら作っていく予定です。 ── Volt MX 以外に、どのような兄弟製品がありますか？ 松浦： Nomad Web Designer、Domino Leap という製品があり、どちらもブラウザで動きます。 Domino Leap は、エンドユーザー様が『ITの専門知識を必要とせずに簡単にアプリケーションを作成したい』というローコードの需要を補完できるツールとして位置づけています。 Nomad Web Designer は今まで Windows PC でしか提供されなかった Domino Designer を MacOS でも同じように使えるようにしたイメージです。 ── いくつもの製品があり今後の展開も楽しみですが、まずは V14.5 からですね。 松浦： 旧バージョンをご利用中のお客様においては、まず他社製品との連携までかと思っています。 今は塩漬けの状態で、Domino の中だけで流通している情報があると思うので、それを他のシステムにも流通させてもらいたいですね。 １つの製品内だけでは情報の流れが停滞することもあると思います。業務の活性化のためにも、他社製品やAIとうまく連携し Domino を『情報の流れを淀ませないような解決策』という位置づけ に持っていきたいという思いもあります。 HCL 様からのメッセージ 過去にとらわれない新たな事例でアプローチ ── 長年 Domino を販売されているパートナー様に、特にお伝えしたいことはありますか。 松浦： HCL に移ってから使っていただいてるお客様から、「色々なツールを使っているが、やはり Domino は凄く良い製品だよね」という声をいただくことがとても増えている気がします。 お客様がやりたいことに耳を傾けると、今までにない新しい使い方 もどんどん出てきます。 弊社サイトで公開しているお客様事例にも掲載しているので、Domino を長らく販売していただいているパートナー様はもちろん、Domino の販売に興味をお持ちの企業様にも、ぜひご覧いただければ嬉しいです。 Domino はかゆいところに手が届く業務アプリを作るには最適なツールだと思うので、そこを強みとしてどんどんビジネスを仕掛けて欲しいと思っています。 インフラの観点においても、堅牢でパフォーマンスのいい製品に仕上がっていますし、他の SaaS製品との連携も充実しているので、「今までの Domino ってこうだよね」という枠の中だけで考えずに 販売していただきたいと思います。 V14.x を避けて V12 にする意味はない ── では最後に、Dominoユーザー様、パートナー様へのメッセージをお願いします。 松浦： Domino に限らず、バージョンアップの際は『どのバージョンにするか』を迷われるケースがよくあります。 今回のバージョンアップは V14.5 と刻まれたバージョンなので、V14 や V12 という実績があるバージョンを検討したいと思われるお客様もいるかと思いますが、この度 V14.0 の非互換検査をしたところ、12.0.1以上であればアップデートされたプラットフォームとして動作が変わらないことが分かりました。つまり、『14.5 もしくは 14 を避けて V12 にする意味はない』 ということなので、ぜひ最新バージョンを検討していただきたいと思います。 14.5 も新機能を使わなければ 14 と同じような挙動なので、保守期間が残っている新バージョンを使っていただいて、興味のある新機能にトライしていただくのが良いのかなと考えています。 ── 本日はありがとうございました。 HCL Domino について問い合わせる まとめ ここまで HCL Domino の新バージョンや今後の展開など、多岐にわたり HCLSoftware 松浦様にお伺いしてきました。 最後に、前半の話を含め HCL Domino の特長となる強みとバージョンアップを推奨する理由をまとめます。 HCL Domino の強み 高い開発生産性と堅牢性 簡潔で迅速なアプリケーションの開発。 長期的に使用されることに適した、運用の安定性。 優れた互換性と柔軟性 チェックツールにより、新旧バージョンの互換性を担保している。 古いバージョンのデータやアプリケーションも最新バージョンで動作可能。 コミュニケーション基盤が別製品でも、Domino を併用できる。 新バージョン V14.5 の新機能「Domino IQ」 セキュリティを確保しながら自社データを活用した生成AI の活用が可能。 過去のナレッジを活用し、業務改善を支援。 Domino の現状とバージョンアップを推奨する理由 Domino の現状 Domino は35年以上にわたり利用されている製品で、現在も市場は活況。 ユーザー数は多く、旧バージョンのまま利用される「塩漬け運用」も多い。 バージョンアップを推奨する理由 サポートが終了したテクノロジーへの脆弱性対応として必要。 新旧バージョンの互換性を担保している。 Domino は他社製品との共存が可能。 新バージョンは V14.5で、新たな機能が追加された。 （本ページは後半です［前半も公開中］） HCL Domino について問い合わせる このページを見ている人におすすめのページ 安定の裏に潜む意外な悩み？HCLに聞く「HCL Domino」のバージョンアップにおける課題と意義（前編） HCL Domino 製品紹介ページ Com-PASS Cloud｜Domino Notes アプリのお預かりサービス .recommend-list{ margin-top: 0px; } ol.recommend-list li { color: #9b9b9b; } #recommend{ font-family: "Noto Sans Japanese"; font-size: 16px; font-weight: 700; color: #9b9b9b; border: none; padding: 0; margin-bottom: 10px; } .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A 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_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; } .interviewee { font-weight: bold; } figcaption { color: #7c7f78; font-size: smaller; } #box03 { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #95ccff; border-radius: 8px; } #box03 .box-title { position: absolute; display: inline-block; top: -13px; left: 10px; padding: 0 9px; line-height: 1; font-size: 19px; background: #FFF; color: #95ccff; font-weight: bold; } #box03 p { margin: 5px; padding: 0; font-weight: bold; } #box04 { position: relative; margin: 4em 0 0 0; padding: 0.5em 1em; border: solid 3px #62c1ce; } #box04 .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #62c1ce; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box04 p { margin: 0; padding: 0; } #box_blockquote { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #8d8d8d; } #box_blockquote .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #8d8d8d; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box_blockquote p { margin: 0; padding: 0; } .memo{ color:#53851b ; background-color: #c8d7b7; font-size:70%; } #blockquote_nicp{ padding:10px; margin-bottom:0px; background-color:#ffffff; } #blockquote_nicp_link{ color:#7c7f78; font-size:70%; } #h5_nicp{ font-size: 12px; padding:4px 10px; border:none; background-color:#afd2f453; }
Domino が誕生してから35年以上が経過し、IBM から HCL に移管されて丸６年が経ちました。 Domino は、高い開発生産性と堅牢性を兼ね備えたアプリケーション基盤で、長きにわたり企業の業務効率化を支えてきた歴史ある製品です。一方、重ねてきた実績の分だけ、バージョンアップに対する課題も垣間見えます。 今回は、エイチシーエル・ジャパン株式会社 HCLSoftware のテクニカルリードである松浦光様に HCL Domino のビジネス状況や今後の展開など、多岐にわたり話を伺いました。前半では「Domino の現状」を中心に、後半では「新バージョンの登場と互換性」をテーマにバージョンアップについてより具体的に語っていただきました。（本ページは前半です［後半も公開中］） 対談者 【ゲスト】 エイチシーエル・ジャパン株式会社 HCLSoftware テクニカルリード 松浦 光 様 【インタビュアー】 エヌアイシー・パートナーズ株式会社 技術企画本部 ソリューション企画部 松田 秀幸 ※対談者情報は2025年6月9日時点 HCL Domino の現状 製品の変遷と現在のビジネス状況 ── Domino が誕生してから35年以上が経過し、IBM から HCL に移管（2019年7月）されてからも丸６年が経ちました。今、HCL としての Domino のビジネス状況はいかがでしょうか。 松浦： 現在も利用していただいているユーザーも多く、市場としては活況です。 見た目や使い勝手も含めた新機能が多く実装されてきた点、バージョンアップのサイクルが非常に良いペース で進んできている点が、ユーザー様、パートナー様から製品投資として評価をいただいてます。 一方、Domino のクラウドに対する対応が SaaS としてではなく Amazon や Google などのクラウドキャリアとの協業による提供に主眼をおいているので、その点が他の SaaS型コミュニケーションツールと比べてもう少しなんとかならないかという声は未だにいただいている状況です。 ── Domino のクラウドに対して、SaaS型コミュニケーションツールとしても期待もされているということですね。 松浦： 運用に関する負荷を下げたいということだと思います。 加えて人材確保やノウハウ継承などの課題に対し、生成AI との連携など新しい領域へのチャレンジがトレンドになっています。 旧バージョンでの利用も多い ── バージョンアップのサイクルといえば、多く利用されているバージョンは何でしょうか？ 松浦： お陰様で現時点の最新バージョンである V14 が順調に立ち上がっています。ただ実は、特定のバージョンでいわゆる『塩付け運用』をされているお客様も多くいます。 そのような状況の中で１点、昨年末にあったケースについてお話しさせてください。 2024年12月13日に重要障害が発生し、多くのお客様と関係者の皆様にご迷惑をおかけいたしました。大変申し訳なく思っております。この場を借りて、お詫び申し上げます。 対応として修正モジュールの適用をお願いしておりますが、実はこの障害は35年前のコードに含まれていたもので、Domino のすべてのバージョンで発生していました。 そのような中で、Domino の塩漬け運用をされているお客様、他社移行の事例記事になっており HCL とまったくお取引がないお客様からもお問い合わせをいただいています。 ── 古いバージョンのまま Domino を利用され続けているユーザー様もまだまだ多くいらっしゃる、ということが分かったのですね。 松浦： はい、良くも悪くも先ほどお話したような状態で、HCL と最近お付き合いがないお客様からもお問い合わせをいただくケースがありました。 古いバージョンを利用する際の注意点 ── 古いバージョンのまま利用することへの懸念は何でしょうか？ 松浦： Java など サポートが終了したテクノロジーへの脆弱性対応 が懸念されます。 また、旧バージョンでは DXに対して十分な役割を果たせるとは言い難いです。新バージョンでは Web対応やモバイル対応、AI対応での活用もイメージしています。 例えば、新バージョンである V14.5 には、Domino と生成AI を統合した機能もあります。 ──『塩付け運用』をされた場合、サポート面はどうでしょうか。 松浦： 多くの塩漬け運用されているお客様からの声をお聞きすると、サポートが終了したバージョンで安定運用ができていたというのが Domino に対する今までの理解だったと思いますが、今回のようなことだけでなく、脆弱性対応も必要になるので、やはり サポートを受けられるバージョンの必要性 を意識していただけたのではないかと考えています。 Domino が選ばれ続ける理由 情報系基幹システムとしての性能と安定性 ── 旧バージョンでの利用も含め、Domino が利用され続ける理由は何でしょうか？ 松浦： 情報系の基幹システムとして必要十分な機能を備えている点が大きいですね。 Domino が誕生した当初から兼ね備えており、「バージョンアップをしなくても現状で満足」というユーザーがいらっしゃる理由になっています。 ── Domino が古いまま使用されるのはなぜか、この点をより詳しくお聞かせください。捨てられないけれどバージョンアップもしない、というのは、なぜでしょうか？ 松浦： 例えば、四半世紀前のデータがそのまま最新バージョンでも読み込めるなど、下位互換、上位互換性が非常に高い。動いてしまうがゆえに、使えてしまう。 便利に使っていただけるのはいいことなのですが、やはり15年前、20年前に作ったアプリケーションなので、見た目が古くなってくるというのは当然あります。 Domino でのアプリ開発の優位性 ── 一般的な市場感として Domino はすでに別製品に移行されてしまったという風潮もありますが、いかがでしょうか？ 松浦： Domino はアプリケーションの開発生産性が非常に高い製品 だというのは、市場の評価として強くあります。 同じようなアプリケーションを、例えば SaaS型の Webベースの他製品、ノーコードの製品やローコードの製品に切り替えることにチャレンジされているお客様はいらっしゃると思うのですが、なかなかうまくいかないということを伺っております。 ── うまくいかないというのは？ 松浦： その製品が悪いとか機能が足りないという話ではなく、Domino だと簡単にでき過ぎてしまうということで、エンドユーザーの満足度を得られないというのが１つの原因だとお客様はおっしゃっています。 他社製品と共存できるメリット ── メールはもう SaaSメールに移行しているという話はよく聞きますが、アプリケーションについては Domino の利用を続けているということでしょうか？ 松浦： コミュニケーション基盤に関しては、在宅勤務やリモートワークが一般的になったので、好みの Web会議サービスに付帯したものへ切り替えたというお客様はいらっしゃると思います。 ただ、先ほどの話にあったように、アプリケーションはなかなか切り替えるのが難しいというのがあります。アプリケーション利用のために Domino が残っているというケース、共存されているというケースなど、多々あると思います。 ── Domino 以外のコミュニケーション基盤とアプリケーション基盤としての Domino を併用し、いわば一つのシステムとして使えると。 松浦： はい、その通りです。コミュニケーション基盤は別の製品を、アプリケーション基盤としては Domino を使っている 事例を、弊社ホームページにも事例記事として掲載しています。 ── コミュニケーション基盤とアプリケーション基盤でそれぞれのいいいとこ取りをされているのですね。 松浦： Domino と他製品が共存ができることは、バージョンアップの観点でも大きなポイントだと思います。 ──「基盤が２つあると運用管理も２倍になるのか」という疑問も出そうですが、どのような運用が可能でしょうか。 松浦： コミュニケーション基盤では、例えば１人に１つメールアドレスを発行するのが一般的だと思います。その場合、そちらのディレクトリシステムをメインにし、Domino は二次ディレクトリとして運用することもできます。 また、LDAP（Lightweight Directory Access Protocol）参照で認証委託をさせることもできますし、Dominoディレクトリと他のディレクトリ…例えばAzure AD（Azure Active Directory）のようなディレクトリサービスと連携させて運用している事例も多くあり、各社のやりたいことと運用負荷のバランスを考えて様々な方法がとれます。 なぜ Domino のバージョンを上げないのか 高い互換性が仇になっている？「動いてしまう」ジレンマ ── 互換性が高いということは、バージョンアップの障壁が低いともいえますね。 松浦： 互換性の高さは、単に過去のデータが「動く」以上の価値を提供していると考えています。 もし他社製品に移行する場合、往々にしてデータ移行が膨大なコストや技術的課題を伴い、互換性の問題が原因で取り残されたデータが発生するケースも見受けられます。Domino の場合、こうした課題を意識することなく 過去の資産を活用し続けることが可能 であり、移行リスクや未知のコストを回避 できる点でも独自の競争力を持っています。 ── 一方で、見た目を新しくすることは、バージョンアップの動機にはならない。 松浦： 見た目を新しくする機能もリリースはしていますが、そこに手をつけるよりは塩漬けで使ってしまおう、その方がお金がかからずに済む、ということで、古いバージョンのまま使うという決断をするお客様もいるのかなと思っています。 ── 確かに Notesクライアントだけを見たら、そんなに大きく変わらないですよね。 松浦： アーキテクチャは変わらないですし、Windows で動いてしまえばクリティカルな障害もなければ、上げる理由も作れなかったというところです（笑）。 最新バージョンは、バージョンアップをする理由になるか ── 大きな障害がなく動かせる状況の中で、上げる理由は何かとなると「最新バージョン V14 で何ができるのか」でしょうか。 松浦： そうですね。お客様が最新バージョンに上げる理由としては DX が多い印象です。再投資をする際の Web対応やモバイル対応、AI対応があります。そのようなところで、もっと価値を出していけるのではないかと考えています。 ── V14.5 については、後半でさらに詳しくお聞かせください。 松浦： 最新バージョンには、Domino と生成AI を統合した機能もあります。V14.5 は、大きく進化した面もあるので是非語らせてください（笑）。 ── 楽しみにしています（笑）。後半では、新バージョン V14.5 の新機能やアップデート、互換性についてお聞かせください。 HCL Domino について問い合わせる まとめ ここまで Domino の現状について、HCLSoftware 松浦様にお伺いしてきました。 最後に、前半のまとめと後半のトピックをご紹介します。 前半のまとめ Domino の現状 Domino は35年以上にわたり利用されている製品で、現在も市場は活況。 ユーザー数は多く、旧バージョンのまま利用されるケースも多い。 長期的に利用される理由は、高い開発生産性と安定性。 利用され続ける理由 Domino は情報系基幹システムとして必要十分な機能を備えている。 高い下位互換性と上位互換性があり、古いデータやアプリケーションが最新バージョンでも問題なく動作する。 旧バージョンの課題 特定バージョンを使い続ける「塩漬け運用」が多く、安定性を理由にアップグレードしないユーザーが多い。 古いままでもシステムが動作するため、アップグレードの動機になりにくい。 見た目の改良も費用対効果が低いとして、アップデートしないケースが多い。 Domino のバージョンアップと他社製品への移行 Domino は他社製品との共存が可能。 新バージョンは V14.5で、新たな機能が追加された。 DX領域での価値提供が、バージョンアップの理由となる可能性を秘めている。 次回予告 後半では、より具体的に新バージョン、互換性についてお届けします。 新バージョン V14.5 の機能はもちろん、今後のビジネス戦略も語って頂きました。 新バージョン V14.5 が刻む新たな一歩 生成AI を Domino の中に Domino と生成AI の統合「Domino IQ」 自社のベストプラクティスを得られる Domino による生成AI の活用方法 REST API による効率的なシステム間の連携 バージョンアップの鍵は互換性の安心感 移行チェックツールとその効果 新旧バージョンの互換性は移行チェックツールで担保する バージョンアップ vs 他社製品への移行 バージョンアップはしないが、移行もしない 結論！バージョンアップが最適解 今後の戦略 V14.5 は 描いたロードマップの答え合わせになるバージョン 兄弟製品に繋げる二段構えの展開 HCL 様からのメッセージ 過去にとらわれない新たな事例でアプローチ V14.x を避けて V12 にする意味はない （本ページは前半です［後半も公開中］） HCL Domino について問い合わせる このページを見ている人におすすめのページ 安定の裏に潜む意外な悩み？HCLに聞く「HCL Domino」のバージョンアップにおける課題と意義（後編） HCL Domino 製品紹介ページ Com-PASS Cloud｜Domino Notes アプリのお預かりサービス .recommend-list{ margin-top: 0px; } ol.recommend-list li { color: #9b9b9b; } #recommend{ font-family: "Noto Sans Japanese"; font-size: 16px; font-weight: 700; color: #9b9b9b; border: none; padding: 0; margin-bottom: 10px; } .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A 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_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; } .interviewee { font-weight: bold; } figcaption { color: #7c7f78; font-size: smaller; } #box03 { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #95ccff; border-radius: 8px; } #box03 .box-title { position: absolute; display: inline-block; top: -13px; left: 10px; padding: 0 9px; line-height: 1; font-size: 19px; background: #FFF; color: #95ccff; font-weight: bold; } #box03 p { margin: 5px; padding: 0; font-weight: bold; } #box04 { position: relative; margin: 4em 0 0 0; padding: 0.5em 1em; border: solid 3px #62c1ce; } #box04 .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #62c1ce; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box04 p { margin: 0; padding: 0; } #box_blockquote { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #8d8d8d; } #box_blockquote .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #8d8d8d; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box_blockquote p { margin: 0; padding: 0; } .memo{ color:#53851b ; background-color: #c8d7b7; font-size:70%; } #blockquote_nicp{ padding:10px; margin-bottom:0px; background-color:#ffffff; } #blockquote_nicp_link{ color:#7c7f78; font-size:70%; } #h5_nicp{ font-size: 12px; padding:4px 10px; border:none; background-color:#afd2f453; }
IBM から HCLSoftware に移管されて丸５年が経った「HCL BigFix」。 HCL BigFix はさらなる進化を遂げ、従来からの強みであるパッチ配信のみならず、脆弱性を可視化して是正するプロセスも含み包括的なサイバーハイジーンソリューションとして高い評価を得ています。 今回は、エイチシーエル・ジャパン株式会社 HCLSoftware の BigFix セールスディレクターである鉄村季哉様に HCL BigFix のビジネス状況にどのような変化があったのか、どのように進化してきたのかなど、多岐にわたり話を伺いました。 対談者 【ゲスト】 エイチシーエル・ジャパン株式会社 HCLSoftware BigFix セールスディレクター 鉄村 季哉 様 【インタビュアー】 エヌアイシー・パートナーズ株式会社 技術企画本部 ソリューション企画部 松田 秀幸 ※対談者情報は2024年12月18日時点 セキュリティの現状と HCL BigFix 高評価ポイントは、使いやすさ・正確性・セキュリティ ── HCL BigFix が IBM から HCLSoftware に移管されて丸５年が経ちました。HCL BigFix のビジネス状況を教えていただけますか。 鉄村：HCL BigFix は毎年右肩上がりの成長を続け、多くの企業様、業種でご導入いただいています。HCL BigFix は急速に技術革新を遂げ、特にセキュリティエリアでの強化が顕著でした。元々パッチ配信に強みを持っていましたが、EDR（Endpoint Detection and Response）、SIEM（Security Information and Event Management）、脆弱性管理など、セキュリティの様々な側面にも対応できるようになりました。ゼロトラストの強化やランサムウェアへの対策も進み、最新のセキュリティパッチを適用することで外部からの攻撃を防ぎ、脆弱性を可視化して是正するプロセスも含まれています。これにより、HCL BigFix は単なるパッチ配信ツールではなく、包括的なサイバーハイジーンソリューションとして進化しています。 ── このような進化を遂げる中で、特に印象的な事例があれば教えてください。 鉄村：自動車業界や家具製造業など、多くの企業が脆弱性管理機能に注目し、HCL BigFix を導入しています。テクノロジーソリューションの評価とレビューが掲載される Gartner Peer Insights においても ユーザーから高く評価 されています。特に 使いやすさ、正確性、セキュリティについては、他社の類似製品に勝る良い評価 をいただいています。 ── HCLSoftware といえば、特に日本では Domino のユーザー様が多くてそのイメージが強いですが、HCL BigFix は HCLSoftware Japan のビジネスとしては現在どのような位置付けでしょうか。 鉄村：確かに Domino のイメージは強いと思います。しかし、Domino 以上に HCL BigFix も成長をしております。現時点では Domino と同等、または業種によっては Domino 以上に製品を導入してるお客様が多くなっています。 脆弱性を可視化して是正する ──「脆弱性の管理」という観点からも新しい機能が付加されたのですね。 鉄村：その通りです。ゼロトラストの強化やランサムウェアの高度化、ハイブリッドな環境への対応が課題となっています。HCL BigFix はこれらの課題に対するソリューションを提供しています。例えば、最新のセキュリティパッチを OS やアプリケーションに適用し、外部からの攻撃を防止します。また、脆弱性を可視化して是正するプロセスも含まれます。外部脅威が増え、インフラネットワーク端末に対してのアタックが多岐に渡ってくるのですが、その中で HCL BigFix ができることが衛生管理（サイバーハイジーン） です。管理されている端末に対して最新のセキュリティパッチをあてて、それが OS であったりアプリレベルで最大限、外部からのアタックを防止します。とはいえ、ゼロトラストであっても必ず悪さをするものです。セキュリティホールを突いてアタックしてくるものがあるので、それも可視化して是正するというプロセスを踏めるのが HCL BigFix です。 ── パッチ配信のみならず様々なセキュリティの課題も広まってきており、それに迅速に対応されているということだと思いますが、特に直近で印象的な事例はありますか。 鉄村：セキュリティ製品なのでお客様名は開示できませんが、例えば自動車業界で HCL BigFix の脆弱性管理機能に目をつけて導入していただいたり、大手の家具製造業様でも脆弱性診断に関心を持たれて導入していただいています。これらのお客様はいくつかの他社製品もご検討されていましたが、先程 Gartner Peer Insights でも HCL BigFix が特に評価されている使いやすさ、正確性、セキュリティーの観点から HCL BigFix を選ばれたとのことです。 他社製品も補完する強力なパッチ配信 業界一高いパッチ適用率を実現できる理由 ── とはいえ HCL BigFix の最大の特長といえば、やはりパッチ配信・ソフトウェア配信でしょうか。 鉄村：HCL BigFix のパッチの適用率は、業界でも一番の適用率を誇っています。 その適用率は 98パーセントですが、言ってみれば「１回やれば１回であたる」。パッチをあてると簡単に言っても、うまくいかないことが多々あり、例えば他社のものでは大体６割程度と言われています。つまり約２回に１回程度は失敗しており、パッチ１つあてるだけでも多くの工数が必要になり無駄な時間が生じます。一方 HCL BigFix の場合、その ターゲットになったパッチに関しては必ずあてられる、完遂できる といったメリットがあります。 ── その適用率 98パーセントをどのように実現しているのかを簡単にご説明いただけますか。 鉄村：通常ですと、管理サーバーからパッチをあてたい管理端末に対してあてにいく「プッシュ型」と呼ばれる手法が取られています。その失敗の理由としては、一度パッチをあてて失敗すればもう一度最初からやり直し、つまりゼロスクラッチになってしまうという仕組みであるためです。それに対し HCL BigFix の強みは、管理サーバーからのプッシュでありつつ、一方で端末には軽いエージェントを導入し、このエージェントがネットワークに繋がっていないオフライン時は何もせず、オンラインになった時点で必要なパッチを自律的に取りにいきます。これを「プル型」と言います。HCL BigFix はプル型・プッシュ型の双方向でコミュニケーションを取る ので、必ずパッチをあてられます。 ── 端末がネットワークに繋がっていない時にプッシュだけしていても、いつまでもパッチ適用されない。しかし繋がった時に端末側からプルで自律的に取りに行くので、必ずパッチ配信作業が行われることになる、ということですね。 必ずパッチをあてる HCL BigFix の独自機能 鉄村：また他社製品にはない「帯域制御機能」があります。例えばパッチをひとつあてるにしても、場合によってはそのネットワークの環境が細くあてられないといったことも多々あります。HCL BigFix の場合だと 帯域制御機能を利用し、10 の帯域があるところにその 0.5 だけパッチのための道を確保する、というイメージです。 ── それは例えば、在宅勤務で人によっては太い回線で契約してる人もいればそうじゃない人もいる。細い回線環境の人が仕事をしていたら突然パッチが配信されて、PC のパフォーマンスが急に落ちて仕事ができなくなる。そのようなことも解消できるのでしょうか。 鉄村：まさにおっしゃる通りです。本当に細いネットワークを使わざるを得ない場合でも、パッチをあてる道として帯域を確保しておけば、時間はかかってもしたとしても必ず完遂するというのが大きいと思います。 WSUS 廃止に対する HCL BigFix の強み ── マイクロソフト様は WSUS の廃止をアナウンスされていますが、HCLSoftware としてはこの点についてはいかがでしょうか。 鉄村：以前から、WSUS は必ずしも初回のパッチ適応ではあたりきれないことがありました。HCL BigFix ではプッシュ＆プル型の構成となっておりますので、初回のパッチ適応で必ずあてられるということが大きな点です。その点で強みはありましたが、今回のマイクロソフト様の発表で、より一層 HCL BigFix の強みが生きてくるのではないかと思います。 引用 クラウドを介したシンプルなWindows管理を目指すビジョンの一環として、Microsoftは将来的にWindows Server Update Services (WSUS) を廃止する計画であることを発表しました。 引用元：Microsoft「Windows Blogs」｜Windows Server Update Services (WSUS) の廃止 ── Windows10 の EOS も 2025年10月に迫っていますが、HCL BigFix でこれに対応できるソリューションはありますか？ 鉄村：Windows11 へのアップグレードには、HCL BigFix の OS展開機能で端末に容易に Windows11 をデプロイメントできます。また Windows10 の EOS以後もマイクロソフトの ESU に加入し利用を続けられるお客様に対しても、HCL BigFix が適切なパッチを提供しますので、ご安心ください。 脆弱性管理と修復 脆弱性の存在を可視化する ── いまお客様のニーズが特に高いソリューションとしては何が挙げられるでしょうか。 鉄村：冒頭でもお伝えした通り、脆弱性管理としても HCL BigFix に着目していただいております。管理されている端末に対して脆弱性があるかどうかを発見し、HCL BigFix を介して必要なセキュリティのパッチセキュリティプログラムをあてられる、というのが大きなポイントです。脆弱性の発見、それを是正するとなると２つのアクションが必要になります。例えば情報システム部が脆弱性を発見し、それをまた別の部隊が是正をするとなるのですが、HCL BigFix ですとこれらの垣根を超えて、HCL BigFix が脆弱性を発見し、それに対して適切なパッチがあればシームレスにそのままの流れで修正できます。 ── HCL BigFix の脆弱性診断というのは、どの機能を使ってどういうことをするのでしょうか？ 鉄村：CyberFOCUS Analytics という機能があります。これは、端末の脆弱性を発見し、それに対して適切なセキュリティパッチプログラムを提供するものです。管理されている端末で、どの脆弱性を帯びているかをグラフとして可視化 して、管理されている方でも容易に何の脆弱性を帯びているのかを発見でき、それに応じて必要なパッチをあてていただけます。MITRE APT や CISA KEV の情報と連携し、管理しているエンドポイントの脆弱性をマッピングし、脅威種類の一覧、パッチ適用が過ぎている日数の把握、深刻度の把握、脆弱性評価などが可能となります。 CyberFOCUS Analytics 機能で CISA による既知の悪用された脆弱性を簡単に把握できる。（画像クリックで拡大） CyberFOCUS Analytics の特長 管理端末の脆弱性を可視化し、パッチの優先順位をつける。 エンドポイント端末に脆弱性可否を確認することによりリスクマネージメントを改善 他社製品と連携し脆弱性の「発見」と「是正」をシームレスに 鉄村：あわせて Insight for Vulnerability Remediation（以下IVR）があります。こちらは他社の脆弱性診断ツールと連携し、そのツールが検知・発見した脆弱性を適切なパッチを適用する機能です。Tenable、Qualys、Rapid7 の３製品の脆弱性診断ツールに対応しています。これらの製品は端末の脆弱性の発見・検知はしますが、その後是正するためには「自らマニュアルで対応してくださいね」となります。しかし HCL BigFix は、これらの脆弱性診断ツールが検知・発見した脆弱性に対して連携し、適切なセキュリティパッチをあてて、本来あるべき姿にします。 Insight for Vulnerability Remediation は Tenable、Qualys、Rapid7 に対応（画像クリックで拡大） Insight for Vulnerability Remediation の特長 脆弱性診断ツール（Tenable、Qualys、Rapid7）との連携 脆弱性診断ツールが検知した脆弱性を BigFix が是正 鉄村：HCL BigFix IVR は、脆弱性診断ツールとの連携を容易にし、セキュリティ管理の効率を大幅に向上させます。脆弱性診断ツールが検出した脆弱性情報を自動的に HCL BigFix に取り込み、該当するデバイスに対して適切なパッチを迅速かつ正確に適用することが可能です。これにより、脆弱性対応の時間を短縮し、セキュリティリスクを効果的に軽減 できます。 ── つまり、脆弱性を可視化し、また診断をするだけではなく、その修復までを一気通貫で行える、ということでしょうか。 鉄村：はい、その通りです。 ── 今お話しいただいた IVR もですが、HCL BigFix は他社製品と連携したり、お客様が競合製品だと思ってるものは実は競合ではなく、お互いのできることできないことを上手く組み合わせるというような使い方ができますね。その観点で良い事例などあるでしょうか。 鉄村：お客様からよく「国産の資産管理ツールの名前はよく耳にします」と言われます。HCL BigFix は確かにそれらの製品とバッティングする部分はありますが、それらが提供していない機能も持っています。よって HCL BigFix と 連携してさらに効果を発揮できる ということもあります。例えばその「国産の資産管理ツール」は、ソフトウェア、ハードウェアネットワーキングの可視化などはできてもパッチ提供はできません。しかしその後にはパッチの提供も行わなければなりません。その際に、例えば Microsoft WSUS（Windows Server Update Services）であったり MCM（Microsoft Configuration Manager）を使用します。しかし冒頭でお話した通りこちらの製品群はパッチの適用率があまりよくないので、その点を補完すべくパッチ配信は HCL BigFix を利用するというお客様もいらっしゃいます。 ── なるほど。例えば他社製品を使っているから HCL BigFix を使う必要はないよ、というわけではないということですね。 鉄村：はい、そうです。他社製資産管理ツールのユーザー様にも、ぜひ HCL BigFix をご検討いただきたいと思います。 AI、MDM など、HCL BigFix の強化点 企業特有の問題点もカバーする HCL BigFix AEX ── HCL BigFix が搭載している AI機能について教えてください。 鉄村：HCL BigFix AEX（AI-driven Employee Experience）という機能があります。これは、ユーザーに対して会話式のスマートでインテリジェントなチャットボットを提供するものです。何か問題があればユーザーがわざわざヘルプデスクに問い合わせなくても自ら問題解決ができます。もちろんセキュリティの問題点をプロンプトで確認するという使い方もありますが、HCL BigFix のパスワードを変更したいといったことでもプロンプトを入力していただければ適切な回答が返ってきます。企業によっては企業特有の問題点であったり、雛形があるかと思います。HCL BigFix AEX を導入する前に、そのような 企業特有の問題点や雛形を事前に HCLSoftware がファインチューニング を行うので、いつでも企業の問題点に対して、質問に対して回答がその場で得られます。 HCL BigFix の全てを盛り込んだのが HCL BigFix Workspace ── ここまでの話には出てこなかったのですが、モバイルデバイス管理も HCL BigFix の機能としてはありますよね。 鉄村：ではここで HCL BigFix Workspace の話をさせてください。Workspace は、HCL BigFix の製品群のバンドルスイートです。HCL BigFix のすべてのライセンスをバンドルし、かつ MDM（Mobile Device Management）を行う HCL BigFix Mobile を付加したものです。 通常、端末というとPC端末やサーバーなどがメインになってくると思いますが、HCL BigFix Mobile で MDM機能を使うことによって、利用されているスマートデバイス、例えば iPhone や iPad、Android ベースのタブレットなども含めて管理ができるようになります。言ってみれば、Workspace が HCL BigFix の総決算 と言いますか、HCL BigFix が持っている全てのもののてんこ盛りです。 ライセンスごとに備えている機能が異なるので、用途に応じた選択ができる。（画像クリックで拡大） ── ひとつのベンダーのひとつの製品で、あらゆるエンドポイントを統合的に管理できると言えるのは、HCL BigFix だけなのでしょうか。 鉄村：はい、現時点では他にはないと思います。 ── ありがとうございます。では最後に一言お願いいたします。 鉄村：HCL BigFix の最大の強みは、セキュリティ、コンプライアンス、資産管理など、エンドポイント管理に必要な機能をすべて持ち合わせている ことです。ぜひ今回の記事をお読みいただき興味をお持ちいただけたようであれば、何なりとエヌアイシーパートナーズ様、HCL までお問合せください。 HCL BigFix について問い合わせる まとめ ここまで HCL BigFix について、HCLSoftware 鉄村様にお伺いしてきました。 最後に、HCL BigFix の特長となる強みをまとめます。 BigFixの強み セキュリティの強化 脆弱性対応の迅速化：リアルタイムで脆弱性を特定し、必要なパッチを即時適用 自動化によるヒューマンエラーの削減：エンドポイント全体に一貫したセキュリティポリシーを適用 コンプライアンスの簡素化 監査準備の効率化：エンドポイントの設定状況やソフトウェアの利用状況を継続的に監視し、必要なコンプライアンス要件を常に満たす状態を維持 詳細なレポート生成：規制対応を証明するための正確でタイムリーなデータ提供 資産管理の最適化 リアルタイム可視化：ネットワークに接続されたすべてのエンドポイントを管理対象として即時に把握可能 ソフトウェアの最適化：使用状況の分析により、不要なライセンスコストを削減 All-in-Oneの利便性 HCL BigFix は、これらすべての機能を単一プラットフォームで実現するため、複数ツールの導入が不要 運用の簡素化、コスト削減、そして迅速な問題解決を可能にし、エンドポイント管理のあらゆるニーズに対応 HCL BigFix について問い合わせる このページを見ている人におすすめのページ HCL BigFix 製品紹介ページ .recommend-list{ margin-top: 0px; } ol.recommend-list li { color: #9b9b9b; } #recommend{ font-family: "Noto Sans Japanese"; font-size: 16px; font-weight: 700; color: #9b9b9b; border: none; padding: 0; margin-bottom: 10px; } .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A 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_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; } .interviewee { font-weight: bold; } figcaption { color: #7c7f78; font-size: smaller; } #box03 { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #95ccff; border-radius: 8px; } #box03 .box-title { position: absolute; display: inline-block; top: -13px; left: 10px; padding: 0 9px; line-height: 1; font-size: 19px; background: #FFF; color: #95ccff; font-weight: bold; } #box03 p { margin: 5px; padding: 0; font-weight: bold; } #box04 { position: relative; margin: 4em 0 0 0; padding: 0.5em 1em; border: solid 3px #62c1ce; } #box04 .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #62c1ce; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box04 p { margin: 0; padding: 0; } #box_blockquote { position: relative; margin: 4em 0; padding: 0.5em 1em; border: solid 3px #8d8d8d; } #box_blockquote .box-title { position: absolute; display: inline-block; top: -27px; left: -3px; padding: 0 9px; height: 25px; line-height: 25px; font-size: 17px; background: #8d8d8d; color: #ffffff; font-weight: bold; border-radius: 5px 5px 0 0; } #box_blockquote p { margin: 0; padding: 0; } .memo{ color:#53851b ; background-color: #c8d7b7; font-size:70%; } #blockquote_nicp{ padding:10px; margin-bottom:0px; background-color:#ffffff; } #blockquote_nicp_link{ color:#7c7f78; font-size:70%; } #h5_nicp{ font-size: 12px; padding:4px 10px; border:none; background-color:#afd2f453; }
2022年7月13日、IBM Power10シリーズにスケールアウト・サーバーとミッドレンジ・サーバーが追加されました。 (さらに…)
IBM Power10 が出荷開始となって、半年あまりが経過しました。エヌアイシー・パートナーズ株式会社（以下 NI+C P）としては、フラッグシップ製品E1080 の売れ行きやお客様からの反響が気になります。 (さらに…)
※当インタビューは「前編」「後編（当記事）」に分けてお送りしています。 登場者 ゲスト 日本アイ・ビー・エム株式会社 テクノロジー事業本部 IBM Power 第二テクニカル・セールス 部長 釘井 睦和 氏 インタビュアー エヌアイシー・パートナーズ株式会社 技術支援本部 テクニカル・サポート部 佐藤 正忠 エヌアイシー・パートナーズ株式会社 技術支援本部 ソリューション推進部 村上 文香 キーワードは「アジリティー」と「摩擦レス」 さらなる経営課題に応えるIBM Power10 - IBM Power10 はセキュリティもかなり強化されているようですね。 釘井) おっしゃるとおりです。IBM Power10 のプロセッサーは、セキュリティ機能をさらに進化させました。 具体的には、コアの暗号化機能を向上させるとともにパフォーマンス劣化のないメモリー暗号化も実現しています。 暗号化という作業を CPU やソフトウェアに頼らずにすみ、自動的な暗号化が可能であるため処理能力の低下というストレスを経験することなく、それでいて、すべてのデータが常に堅牢に守られている、という状態を享受いただけます。 - 最近の産業界では、環境負荷の軽減も強く求められています。 米国のパリ協定復帰を機に、いわゆる "環境関連銘柄" に再び注目が集まるようになり、日本でも「カーボンニュートラル」をサプライチェーン全体で達成しようといった動きが見られます。 あらゆる企業がその一挙手一投足で、都度「それは環境にとって正しい判断か」を考える時代が来ました。 釘井) この点でも IBM Power10 は大きく貢献できます。 最新の 7nm Power10プロセッサーによる高い集約性とリソースの効果的な活用の実現により、IBM Power E1080は、同じワークロードを実行した場合、IBM Power E880C と比べて52%、IBM Power E980 と比べても33％の消費電力削減を達成できます (※IBMによる自社従来品との比較調査 (2021年))。 IBM Power10 にアップグレードすることで、より少ない CO2排出を実現できることになります。 また、エネルギー効率の向上のみならず、リサイクルや環境に優しい材料の活用促進、製品パーツのアップグレード、修理、再製造、再利用によるプロダクトライフサイクル拡大など、IBM Systems全体でハードウェア製品や製造過程における環境面への影響を考慮したイノベーション活動を続けています。 販売に際しても、導入によって年間約20トンの CO2削減を見こむお客様には、製品の一部を割り引く「SDGs割」制度を導入しています。 こちらもぜひ活用いただきたいと思います。 IBM Power10の最も効果的な利用シナリオ - 釘井さんにとって、IBM Power10 はどのように活用するのが最も効果的だと思いますか。 釘井) いろいろお勧めはありますが、ニーズも高くて効果的だと思うのは、最新型ERPシステムの基盤として動かすことです。 ここで重視すべきなのは、CPU の性能です。 7nm Power10プロセッサーは、8スレッドSMT (Simultaneous Multithreading) をチップあたり最大15コア搭載でき、コアあたりの処理能力は、POWER9プロセッサーと比較して約1.3倍のパフォーマンス向上を実現しています。 また、この高い CPUコア処理能力と高密度・高速なメモリー・アーキテクチャーの実現により、アプリケーションが必要なコア数を削減できます。 結果として、サーバー台数の削減や TCO の改善が可能になります。 「クラウドでERPを動かしてみたけれど満足した性能が得られなかった」「完全クラウドシフトはコスト感が合わない」という経験をされたお客様が "脱クラウド" に向かわれる現象も出てきており、IBM Power10 はそうしたお客様の受け皿になれると考えています。 もう1つは、データベースシステム基盤として活用することです。 例えば、これは実際に合ったケースですが、それまで x86ベースで126台のサーバーを運用されていたのが、IBM Power E980 にリプレースすることにより、なんと3台に統合できました。さらに IBM Power E1080 にアップグレードしたとすると2台にまで集約可能です。 これをエネルギーという観点で見ると、102kW から約20kWと1/5に、ライセンス数としても約1/3に削減可能です (※IBMによる自社従来品との比較調査 (2021年))。 いろいろな意味で大きな節約になります。 手が届く存在にする賢い買い方 - E1080 というフラッグシップ製品から登場したこともあって、お客様からは「理想的なシステムであることは認識しているが、当社には『高嶺の花』」といわれることがあります。 釘井) IBM では、IBM Global Financing という組織を通じて様々なお支払い方法の選択肢を用意しています。 一括購入するのではなく分割月額払いにする、分割月額払いにリースを組み合わせる、また、分割月額払いも、均等割ではなく最初は低い金額で開始する、支払い開始時期を後ろに倒す、現在のリース残を新たなリースに包含してすべてリース払いにする、などの方法があります。 冒頭でご紹介した「Dynamic Capacity」も節約術の1つとして活用いただけます。 ぜひ、ご相談ください。 来年以降も新製品を予定しておりますので、楽しみにお待ちください。 - 本日はありがとうございました。 CEOの直面する経営課題の解決策が全部入った1台 新しい時代に突入し、道を切り拓いていくことが求められている現代の企業。 IBM Power10 は、そうした企業の CEO が抱く切実な "思い" を真摯に受け止め、妥協を許さず様々な機能を実現した製品だと実感しました。 NI+C Pも、「リプレース時期が来たら検討する」ではなく「IBM Power10だから検討する」といっていただけるよう、パートナー企業の皆さんを通じて、このサーバーの魅力やメリットを引き続きお伝えしていきたいと思います。 この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 早わかり！ここが進化したIBM Power10 (コラム) - よりスピーディに、よりスマートに、企業活動を発展させ、デジタル競争の勝者となるためには…？ .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 Power 第二テクニカル・セールス 部長 釘井 睦和 氏 インタビュアー エヌアイシー・パートナーズ株式会社 技術支援本部 テクニカル・サポート部 佐藤 正忠 エヌアイシー・パートナーズ株式会社 技術支援本部 ソリューション推進部 村上 文香 キーワードは「アジリティー」と「摩擦レス」 今日、日本の企業は様々な経営課題に直面しています。 さらなるスピード経営の実現、クラウドや AI活用による DX推進で継続的な成長を追求する一方で、情報セキュリティ対策を高度化し、脱炭素社会や SDGs の実現に向けた施策も必要です。 こうした中、IBM Power10 は「アジリティー」と「摩擦レス」をキーワードに、このような経営課題に応えるために誕生しました。 具体的にどのような解決策が提供されているのでしょうか。 日本アイ・ビー・エム (以下 IBM) で Power テクニカル・セールスを担当されている、ITスペシャリスト 釘井 睦和 氏にお話を伺いました。 ※当インタビューは「前編 (当記事)」「後編」に分けてお送りします。 世界のCEOが注目しているテーマは「アジリティー」 - 本日はよろしくお願いいたします。 日ごろ日本企業と対話される中で様々な声を聞かれると思いますが、課題としてはどのようなものが多いでしょうか。 釘井) IBMには、お客様の声を聞く媒体の1つとして、定期的にグローバル経営層に対してアンケート調査を行い、その結果を発表している「IBM CEO Study」があります。 世界中の13,000名以上の CxO (最高責任者) レベルの経営層に、今日のデジタル時代をリードするために何が必要かについて尋ねるものです。 2021年度は前年がコロナ禍に見舞われた転換の年であったため、かつてない規模での調査を実施しているのですが、それによると、56％の CEO が「アジャイルで柔軟なオペレーションを積極的に追求する必要がある」と回答しました (図1)。 「アジャイルである」とは、俊敏であること、機敏であること。つまり、状況に合わせて自在に "伸び縮み" できることを意味します。 アンケート回答の結果は、不確実性の高い時代の危機を乗り切るために、企業にとってこの経営判断や組織づくりにおける俊敏性、機敏性を指す「アジリティー」を持つことが必須となっている状況を表しています。 [caption id="attachment_109017" align="alignnone" width="491"] 図1：今後2,3年で最も良い業績を生み出すための最重要課題とは？出典：IBM CEO Study (グローバル経営陣スタディ)[/caption] 確かに、コロナ禍以降の状況が時々刻々と変化したこの2年を振り返れば誰でも実感できることです。 昨日は可能であったことが今日はそうでなくなり、今日禁じられていたことが明日は許可されるという世界。紙の裏表のように変わる環境に即応して適切な対策を講じることができなければ、企業経営はたやすく危機に陥るリスクをはらんでいました。 「アジリティー」とは、俊敏であること、機敏であること。つまり、状況に合わせて自在に "伸び縮み" できることを意味します。 経営と IT が不可分である今日、このような危機を乗り切ろうと思えば、IT こそがこの「アジリティー」を持つことを強く求められているのです。 そして必然と言えますが、「アジリティー」を担うのが IT です。 - 新しく登場した IBM Power10 はまさに「アジリティー」と「摩擦レス」をキーワードとして誕生していますね。 釘井) そのとおりです。この「アジリティー」を象徴する機能として、IBM Power10 には「Dynamic Capacity」が備わっています。以前の IBM Power でも一部のモデルで提供されていましたが、このバージョンで全面展開となります。 どういう仕組みかというと、同じサーバーモデルでエンタープライズプールという形で "チームを組む" ことによって、コアやメモリーといったリソースを全サーバーで共有が可能になります。 超過して使いそうな可能性がある場合は、従量制課金の考え方でそれぞれのサーバーでリソースを事前購入して搭載しておきます。 このようにしておけば、ふだんは最小限に見積もった容量で利用し、一時的に利用が増えるというときも特段の準備なく用意しておいたリソースで事業を継続できます。超過使用量は分単位で課金計算が行われ、それはハードウェア管理コンソールを通じて Cloud Management Console で自動管理されたデータで確認できます。 そして、一時的な利用増大が終了すればまた元の状態に戻れます。 これまでは、利用が増えればサーバーを追加するしか選択肢がなく、調達するまでのタイムラグをどうしのぐか、という問題がありました。さらに、利用が減っても一度増やしたサーバーを減らすのは簡単ではありません (図2)。 [caption id="attachment_109018" align="alignnone" width="547"] 図2：Dynamic Capacityを用いたシナリオ例[/caption] - なるほど。ちなみにリソースを事前購入しておくのはなぜですか。 Cloud Management Console で使用量が確認できるのであれば、すべてオンデマンドで課金計算してもいいように思います。 釘井) 事前購入の方が、発生するコストを想定しやすいからです。 クラウド利用でも見受けられることですが、日本のお客様はコストが予想以上に膨らむことを懸念されます。事前購入はコストコントロールに配慮した仕組みです。 将来的に「Dynamic Capacity」は、IBM Cloud上で動く IBM Power Virtual Server を含めた利用も可能になる予定です。これを併用することによって、より急激な利用増大ニーズにも対応しやすくなります。 コロナ禍でマスク販売サイトやワクチン接種予約サイトへのアクセス集中を私たちは経験しましたが、産業界でも同様のことは起きています。 システムの拡大・縮小対応がますます現実的になる中、ニーズは高いと思われます。 - いつごろ利用可能になりそうでしょうか。 釘井) 現時点では開発意向表明のみが出ていて提供時期をお伝えすることはできませんが、北米の数社でパイロットとして利用が始まっていると聞いていますので、比較的早い段階で提供できるのではと考えています。 IBM Power10で「ハイブリッドクラウド」と「AI」をどう実現するか 釘井) IBM Power10 は、IBM としての方向性である「ハイブリッドクラウド」と「AI」とも足並みを揃えたシステムになっています。 - IBM Power10 で対応する「ハイブリッドクラウド」とはどのようなものですか。 お客様は実際どのように「ハイブリッドクラウド」環境をお使いでしょうか。 釘井) お客様のクラウドニーズはほんとうに様々です。最も多い利用ケースは、開発・検証環境の実装ですね。 従来オンプレミスシステムでは、開発・検証環境の構築は不自由さを強いられていました。 それなりの環境を基幹システム基盤に環境を確保すれば、本番システムの性能に影響を与えてしまいます。かといって制限を設ければ、十分な開発・検証が実施できません。 その点クラウドであれば、必要なときに必要なボリュームを用意して心ゆくまでリソースを活用、作業が終われば即撤収、という使い方ができます。 また、災害対策としても有効です。 これまでは「途切れない事業継続のためには、本番システムと同様のシステムを遠隔地にご用意ください」と申し上げるしかありませんでした。 しかし、クラウドであればハードウェアを別途調達する必要はありませんから、災害対策コストは軽減されます。 しかも、IBM Cloudのコロケーション環境で仮想環境を提供しているIBM Power Virtual Server を利用すれば、オンプレミスの本番システムとまったく同じアーキテクチャーをもった災害対策環境を、オンデマンドで構築することができます。 必要なデータをクラウド・ストレージにコピーしておく、サービス環境を立ち上げるのに必要な定義情報を IBM Cloud に保管しておく、といった準備は必要です。 こうすることで、平常時は最低限のサーバーのみで運用コストを抑えつつ、万が一のときは災害対策用の業務サーバーを自動作成して迅速に事業継続を図れます。この方法もよく選択されるクラウド活用法です。 システム運用からの解放やクラウド先端技術活用のために全面的なクラウドへのリフト&シフトを進められているお客様があるかと思えば、その一方で、パフォーマンスやコストコントロールの観点から「脱クラウド」を掲げ、オンプレミスシステムへ回帰されるお客様もいらっしゃいます。 IBM Power10 は、これらすべてのニーズに対応します。 つまり、オンプレミスシステム志向からクラウド志向まで、お客様がどのフェーズにおられても、また、どのフェーズに移行されようとしても、IBM Power Virtual Server との連携によって「摩擦レス」にシステムの構築・移行を実現します。 - よくわかりました。 それでは「AI」という方向性についてはいかがですか。 AI活用といえば、お客様は「IBM Power AC922」などを用いてディープラーニングによる機械学習を行ってきたかと思うのですが、それが IBM Power10 でも行えるようになるのでしょうか。 釘井) AI活用には、学習と推論という2つの側面があります。 膨大なシステムリソースが必要になる学習には、引き続き「IBM Power AC922」のようなGPUを搭載したサーバーが有利です。 しかし、完成したモデルにデータを投入して推論させる段階になると、必ずしも GPUマシンを用いる必要はありません。 たとえるなら、レーシングコースを走るなら F1カーが最適ですが、街なかを走行するのにも F1カーに乗りますか？ということになります。 IBM Power10 は「Train Anywhere, Deploy Here」をキーワードに掲げ、データの蓄積された場所、つまり基幹システム上で推論を実行することを想定しています。 その意味では「すでにモデルはいくつか作り上げた、そこに生のデータを当てて検証を繰り返し、さらに精度を向上させていきたい」といった、AI活用がある程度進んだお客様にお勧めしたい機能です。 このサーバーは、Matrix Math Assist (以下 MMA) という行列計算などを専門として処理するエンジンが IBM Power10 のチップに組みこまれており、MMA につながるメモリーまわりの帯域幅やキャッシュ容量も増えているため、膨大なデータを高速に処理することができます。 例えば、同じ筐体内に業務システムを動かす IBM i や AIX の区画、AI を動かす Linux区画を置き、IBM i や AIX の区画に続々入ってくる日時の営業トランザクションや製品の需要情報を Linux区画に送って推論を行い、その最新計算結果をまた業務システム側に反映する、といった利用法が考えられます。 「データのある場所でAIを実行しよう」が、IBM Power10 のメッセージです。 後編「さらなる経営課題に応えるIBM Power10」～へ進む この記事に関するお問い合わせ エヌアイシー・パートナーズ株式会社 企画本部 事業企画部 この記事に関するお問い合せは以下のボタンよりお願いいたします。 お問い合わせ 関連情報 早わかり！ここが進化したIBM Power10 (コラム) - よりスピーディに、よりスマートに、企業活動を発展させ、デジタル競争の勝者となるためには…？ .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; }
interviewee：長尾 政明 氏 IBM iX Creative & Design 統括 IBM デザイン思考推進リーダー IBM Studios Tokyo スタジオリーダー interviewer：NI+C パートナーズ 企画推進部 加古 ～ 前編からのつづき ～ - それでは、IBM がデザインシンキングを導入していった過程についてお聞かせいただけますか。 IBM では、2012 年に IBM におけるデザインプログラム 第2章 として、IBM Design という組織を立ち上げ、最初の IBM デザインシンキングのトレーニングを製品開発チームに対して行いました。その時は、まず希望者を募ったため、各チームから 1,2名ずつの参加となりました。約1週間、デザインシンキングのトレーニングを実施しましたが、トレーニングを受けた後、現場に帰ったその方達は、「周りのチームメンバーが、全然理解できていない。自分達だけが遊んでいるみたいだ」、と感じたのだそうです。 この教訓を活かし、トレーニングには、チーム単位（5～10名）で参加させることにしました。こうして、現場に戻ってもやらざるを得ない環境作りもサポートしたのです。 デザイン・シンキングのトレーニングはマネジメント層にも必須 実は、それで全てが上手くいったわけではなく、プロジェクトを進めていくと、今度は該当製品開発チームのマネージメント層から「何をやっているんだ」、「これまでの尺度で報告しろ」という意見が出るなど、マネージメントがチームの活動を理解してくれない、IBM デザインシンキングのアプローチで推進できないという相談が トレーニング参加者からありました。そこで、トレーニングを受講するチームのマネジメント層もセットで デザインシンキングのトレーニングを受けてもらうようにしました。マネジメント層に対する1週間のトレーニングは難しいため、0.5日から1日で基本的なことと、なぜ必要なのかということを理解してもらいました。更にメンタルモデルの変化、コーチング方法の変更をについても理解してもらい、ようやく回り始めたのではないかと思います。 このように、IBM でも何度か失敗しているのです。個人だけでなくチーム全体、更にマネジメント層まで浸透させ、評価制度まで変えないと、日本の企業においてデザイン・シンキングの導入、更に変化を起こすことは、難しいのだと思います。 ― 日本の IBM 社内では、どのくらいのトレーニングを実施されているのですか？ 営業チームに実施しているのは1日のトレーニングです。1日以上拘束することが、難しいため、与えられた時間で出せる結論までにしています。その内容を元にお客様に提示してみる、営業チームで試してみる、そのように回る仕組みを目指して実施しています。来年からは、少し変更して、デザイン・シンキングそのものだけではなく、 ユーザー・リサーチ（観察）もしっかり実施するようなコース開発も行っています。 e ラーニングも社内では準備しているのですが、デザイン思考に関しては受動的な学習では理解が難しいので、アクティブ・ラーニングによるトレーニングという形を重要視しています。 IBM デザイン・シンキングの進化 ― IBM デザイン・シンキング自体に変化はありますか？ 当初 IBM のデザイン思考は、以下のイメージのように"シーケンシャル"に進むイメージで書かれていました。 上記のように以前は 4ステップ あったのですが、今は単純化されて、「Observe（観察）」、「Reflect（洞察）」、「Make（施策）」の 3ステップ です。 ※※（）内の和訳は、『IBMの思考とデザイン』 からの引用です。 更に、これらはループします。なぜこの形に行き着いたかと言うと、IBM の製品開発がアジャイル的にどんどん進化したからです。その進化の中で、デザイン・シンキングをステップ通りに進めなければならない、とは もはや言えなくなったのです。どのプロセスからも入ることができるモデルが必要となりました。まずは作り、その結果を熟考してみて、その リフレクション（振り返り、学び）を元に変更を加えて...というやり方でも良くなり、もちろん、従来からのお作法通りに進めても良いのです。 ― アジャイルは、IBM の中でも当たり前のように浸透し、そのアジャイルに適応し、融合するため、このモデルの変更されたのですね。 他のプラクティス、アジャイルやリーンスタートアップと融合することでより強力なツールに この新しいモデルが強力なのは、アジャイルという手法に対し、どういうものを作るか？というアイデアを出す部分をデザイン思考が補完するところにあります。補完して、メイク部分をまずはプロト的に紙芝居のようなものでアジャイル的に作り出していく。アジャイルのプレイヤー達と一緒にどんどんこのサイクルを回していく、ということができます。デザイン思考だけではなく、アジャイルもなくてはならない存在です。加えて、お客様の既存システムといったイメージではなく、新しい事業やサービスラインを作るなどの場合は、リーンスタートアップ ※1 的な手法もここに入ってきます。お客様での成果を見て、実際のアイデアと開発内容に反映します。 これらの手法は、絡み合っています。どれか1つだけでは、片手落ちです。デザイン・トランスフォーメーションを例にとると、企業が目指しているものを明確にし、そこに対してデザイン思考、アジャイル、リーン・スタートアップなど、新しい手法を適材適所に組み合わせて実践します。 ※1. 「リーンスタートアップ」： コストをかけず。最低限の製品やサービス、機能の試作品を短期間で作り、顧客に提供し、顧客反応を得て、観察し、観察結果を分析し、改善し、再び顧客に提供する。このサイクルを繰り返す手法。 IBM でデザイン・カルチャーを作る、という目的を実現するための方程式があります。それは、" People "、" Practice "、" Place " が重要という考え方です。 IBM デザイン・シンキングを支える「場」 ― 先ほどお話いただいたのは方程式のなかで、Practice 「実践」の部分だと思いますが、では、Place 「場」についてお聞かせください。 ここ（IBM Studios）は、共創するための場です。一般的な会議室だと、いきなりセッションを実施したとしても難しいことがあります。やはり集まりやすく、ここに来ると何か面白そうなことが起こるのでは？という雰囲気を感じられることがとても重要です。ここはもちろんセキュリティが厳しいのですが、ソニー社では、1階の受付を通らずすぐ入れるような メイクスペースをお持ちです。 Yahoo 社も Yahoo lodge を開設されています。外部の人の入りやすさであったり、社内の人もそこに来る、そんな場で、様々なことが発生する。このような環境づくりもオープン・イノベーションを謳う企業にとって非常に重要な部分になるのでは、と思います。 多種多様な"人を繋ぐ場" とデザイン・シンキング IBM でもこの「場」というものを非常に大切にしています。その場に来るとデザイナーがいて、ノンデザイナーとデザイン思考を使いながら、お客さんと一緒に問題解決をする。共創し、形にするための道具として、デザイン思考があり、様々なバックグラウンドの人々を繋ぐ役目を果たしています。デザイン思考は、仕事の仕方、ひいては働き方のための OS 、インフラやフレームワークのようなものとして機能し、それを有効的に使える 「場」として、 IBM Studios が存在しているのです。IBM Studio は、現在、世界43箇所に設置され、社内外の人が共創活動を行っています。 お客様にも、「ふらっと来て、デザイナーと話せる、相談できる、そのような場を持つことも重要です。」とお伝えするようにしています。中には、「では、空いてる部屋をこれに使おうか」と、自ら場づくり、空気作りにも取り組もうとされているお客様もいらっしゃいます。 ― 確かに、昔ながらの会議室で堅苦しく机を囲んでいるのでは、「さぁ、アイデアを出しましょう！」と言われても活発に思ったことを言い合う雰囲気にはなり辛いですよね。アイデアを出す場合、座っているより、立っている方が良い、ホワイトボードがあって、付箋紙貼れる方が良い、最も重要なのは、多種多様なバックグラウンドを持った人々が気軽に集い参加できる「場」があること、なのですね。 IBM デザイン・シンキングでは特に「人」を重要視している ― それでは、3番目の 「People」 についてお聞かせください。 ありきたりなシステム開発ではなく、ユーザーにとって本当に価値のあるものを見つけ、提供するといった場合、デザイン思考のバックグラウンドを持った人が、ユーザーを理解することから始めます。アイデアを出して簡単に試作をして、評価するということをぐるぐる回して理解します。このような問題の理解から始めないと、本当の価値を見つけ、提供する、ということことはできません。 チーム全体が共感し合うことが大事 その時は、個人的に誰が良くやった、ということではなく「チーム」として成功も失敗も経験するということが重要です。IBM デザインシンキングの中では、特に「チームが大事」ということが言われます。また「共感」が重要とも言われています。ユーザーに共感するだけではなく、チームメンバーにも共感する。チームの各メンバー同士が共感していないと、「私のアイデアが...」といったメンバー間の競争になってしまいます。ユーザーに共感する前に、まずはチームの中で共感し合いながら、お互いの強みや弱みを理解することにより、最大限良いものが出せる、という思想です。 IBM のプロダクト部門があるオースティンを中心にこの取り組みが進んでいます。同じ IBM のオフィスであっても雰囲気が全然違います。助け合いというか、お互いに共感し、オープンな雰囲気があります。そういう意味では、昔の町工場的なイメージです。 単体のチームだけでなく複数チームによる"異種交配の場"をつくる 例えば、オースティンの Watson IoT や Watson Health のような製品開発チームの良い例があるのですが、彼らは、作っているものや、やっている事についての情報を通路に張り出しています。それは、ただ、自分たちが行っていることを発信しているだけでははないのです。その通路に張り出された情報に対し、他のチームの人が自由に意見を書き込んだり、アドバイスしたりと、オープンに意見交換を行っているのです。彼らはこれを花粉の受粉に例えて、"クロスポリネーション"と表現しています。異種の花同士の交配、これを起こさなければならない。チームの中でだけでは新しい意見や発見がなかなか出てこないと考えています。オースティンでは、その中での情報がオープンで共有できる環境をつくるため、オフィスのセキュリティーは非常に厳しく・・・・実は、私は毎度行くたびにロックアウトされてしいまうのです（笑）。ですが、それ位厳しいからこそ、実現できているのだと思います。 異種の芽というのを入れる。デザイン・シンキングそのもののチーム構成は、ビジネスの人だけを入れれば良い、 IT の人だけでチームを構成してしまうと、その分野のエキスパートではありますが、多種多様な意見を引き出すのは難しくなります。様々な人を入れて、問題に対してアプローチする、意見を言ったりする、アイデアを出したりする。異質とか多様性からの創造、チームでもいろんなチームが存在する環境の中で、有機的に交わりながらモノづくりするというのがデザインカルチャーの根底にあるような気がします。 昔の印象とは全然違う姿があり、日本の方がまだまだ個人やチーム間が協力し合っていないイメージにあるように思います。 －そうですね。デザイン・シンキングを実践する人数やメンバー構成を考える上では、やはり出来る限り多様なメンバーを揃えるというのが重要ということですね？ はい、そうだと思います。 人数の部分からお答えすると、決まった人数というのはありません。 IBM の製品開発でのデザイナーとエンジニアの最適な人員構成は、元々は 1:50 だったり、1:33 だったり、色々な数字がありました。今は、1:8 にしようとしています。デザイナーが、1,600 人になって、このデザイナーとエンジニアの比率はこれぐらいが良いのでは、となっています。最近のスタートアップ、例えば創業者がデザイナーの Airbnb では、1:2、1:3 の比率とのことです。IBM は製品が複雑で、専門的なスキルが必要ですので、将来的にもその割合にはならないとは思います。 － そうなのですね、確かに 1:8 ぐらいに落ち着きそうですね。 はい、エンジニアは、これぐらい必要だと思います。 デザイナーを大胆に配置し売り上げが倍増 2010 年に買収された企業から Phil Gilbert が IBM に加わり、 BPM チームを任されました。当初、40 ぐらいあったプロダクトを 4 つに整理しました。人も 1,000 人いたディベロッパーを 600 人減らしました。正確な数字は分からないですが、デザイナーを増やし、プロジェクト・マネージャーと合わせて、700 人ぐらいにしました。人を 30 % 減らし 、更に 4 つにプロダクトラインを減らしたのですが、この次の年の売上は 2 倍増になったとのことです。このような人の構成で、有機的に反応し合い、進めるのが良いということがわかりました。ある意味できすぎた話に聞こえてしまうのですが、 IBM では、オファリングマネージャとデザイナー、エンジニアとデザイナー、など組織での比率を常に意識しているのです。 IBM ではデザイナーとエンジニアの比率は 1:8 を理想としていますが、一般企業で言うとどうでしょうか。IT 部門で何か新しいシステムを作るという場合、 1:50 に近い数字のイメージではないでしょうか。しかし、サービスを作るとなると、デザイナーが重要になってきますので、比率はもっと変わってくるのではないかと思います。 ―最後に今後、デザイン思考やってみようとか試してみようとかという企業やビジネスパートナーに向けて、何から手をつけて良いかアドバイスいただければと思います。 理想から言ってしまいますと、とにかくとりあえずやってみましょう、体験してみましょう、ということになります。 今、 IBM 社内 の営業担当者向けにワークショップを実施しています。その内容を是非パートナーさんにも広めたいと思っています。実現するにはその方法を考えなければならないのですが、ワークショップやセッションという形で体験してみていただければ、その体験を通して、これならお客様とも一緒にできる、という感覚を持っていただけるはずです。まずは、このようなステップを踏んでいただけれたら良いかと考えています。 デザイン思考については、頭で考え始めても悶々とするだけですので、考えるのは体験してからで良いと思います。 デザイン・シンキングはパートナー様の強みにできる 実は、お客様が本当にどう困っているのかが、わかっていないことがありますが、デザイン思考を使って、パートナー様自らリサーチし、仮説を立案することができます。また、自社のセールス・プランニングのツールとしても使うことができます。また、デザイン・シンキングを含む他の手法をアピール材料に、新たなお客様へアプローチする手もあります。 単純にこの製品を入れましょう、ということだけではなく、例えば、マーケティング・オートメーションのツールだとすると、ユーザーは自動でメール配信ができるのは理解したが、では配信効果が出るのはどのタイミングなのか？ということを実際に配信した結果を元に考えませんか？など、デザイン思考ならではの使い方や取り組みができます。 今後、これらのきっかけとなるセッションをどう実現するか、という課題は残ります。もちろん、課題は課題としてとらえ、日本で IBM として、デザイン・シンキングを広めていくためにできることを考えていきたいと思っています。 2回に渡り、IBM デザイン・シンキングについて、特に IBM 社がどのようにデザイン・シンキングを企業の血や肉としてきたかをお聞かせいただきました。 ツールとしてのデザイン思考に注目が集まりがちですが、そのツールを使う「人」や「場」を準備し、ようやく回り始めるという状況だということがわかりました。 また、単純に推進役だけがデザイン思考というツールを知るだけでなく、チーム全体、マネジメント層の理解を得ることももちろんのこと、ひいては評価制度に至るまで、変えていかなければならない、ということに改めて気づかされました。 その上で「日本にはイノベーションの素養がある」と確信し、それには個人個人、そしてチームのマインドセットが重要との認識を更に強めました。 機会があれば、番外編として、「デザイン思考を実現するマインドセット」について考えてみたいと思います。
interviewee：長尾 政明 氏 IBM iX Creative & Design 統括 IBM デザイン思考推進リーダー IBM Studios Tokyo スタジオリーダー 経歴 ・・・ コンサルティングファームにおいて、戦略・トランスフォーメーション領域でのコンサルティングに従事した後、事業会社に移り、新規事業企画 (大手電機メーカー)、グローバルオペレーション企画 (海外通信機器メーカー) 等を経験。 IBMにおいては、電機・電子業界コンサルティング、戦略コンサルティングを経て、現在はC&D 統括として、IBMデザイン思考推進リーダー、IBM Studios Tokyo スタジオリーダーを務める。クライアントと共に、新しい顧客体験の創造とビジネスデザインを実行、またデザインカルチャーの組織への浸透・実践に取り組んでいる。 専門分野・・・IBMデザイン思考、新規事業企画、ビジネスモデル、イノベーション、FORTH公認ファシリテーター interviewer：NI+C パートナーズ 企画推進部 加古 当インタビューの背景 今回のインタビューのきっかけは、「デザイン思考とクラウド」と題した特集記事です。素人ながら"デザイン思考は何かから、クラウドとの親和性について”執筆してきました。考察を進めていくうちに、日本の企業はデザイン思考を効果的に導入することが難しいのではないか？という疑問にたどり着きました。 この疑問を紐解くには、やはり、デザイン思考の推進に実際に取り組んでいる方にお話をお伺いするのが良いのではないか？ということになり、日本 IBM で第一人者の長尾氏にインタビューのお時間をいただくことになりました。 IBM デザイン・シンキングを担う組織 ― お話しにくいかもしれませんが、こういうところが難しいんですよとか、成功、及び失敗事例も含めてざっくばらんにお話いただければと思います。まず初めに、長尾様のお仕事、お立場や役割についてお聞かせください。 私は、 IX （インタラクティブ・エクスペリエンス）担当、コンサルタントとして GBS という組織にいます。 IBM グローバルでは、"デジタル・ストラテジー・アンド・インターラクティブ・エクスペリエンス"という顧客体験やユーザー体験、といったお客様に近い部分を担当するチームというイメージです。私には、クリエイティブ・アンド・ デザイン、ここでは顧客体験を作るにあたってデザインやアプリケーション、その前段のそもそもどういうユーザー体験が求められているのかを考えるミッションがあります。 最近 IBM は、エクスペリエンスを全面に押し出し始めています。 これまでのように戦略や要件定義を理詰めで考え、落としこんでも、結局ユーザーが使いたい、または必要な機能にはならないことが多いということを経験してきました。機能をたくさん詰め込んでしまうと、お腹がいっぱいの状態になってしまうのです。 例えば、（テーブルにあったリモコンを指し）テレビのリモコンにはこんなにボタンがありますが、使うボタンはほんの一部です。ボタンが多すぎるのです。（赤、青、黄色・・・ 等のボタンを指しながら）このボタンは、何かしら投票する時などにしか使わないですよね。そもそも使いこなしている人はほとんどいない。同じように、モバイルやクラウド、特にフロント寄りでは、 IoT、 AI 、何でもできるとして、何でも乗っけたくなるのですが、結局無駄なものができてしまい、響かないのです。 ユーザー体験をエンリッチするために 「響く体験、生き残るためにユーザの体験をエンリッチするものでなければならない」、と言うのが2012年にジニー・ロメッティが就任した時の言葉です。「クライアント・エクスペリエンスの今後が、 IBM 成長の鍵となる」と。この瞬間、デジタル・リインベンション、そしてエクスペリエンスが IBM の中心となりました。このデザインを先頭になってやるというのが、我々のチームです。 その中には UX （User Experience） などの上流工程をデザイン・シンキングを使ってデザインしている者もいれば、それを受けて様々なアプリを開発したり、プロダクトにつながるもの、また簡易的なサービスをデザインする者もいます。更に広告代理店系の人材、デジタルマーケティングとかデジタルクリエイティブという人達もいます。大手広告代理店との差別化として、例えば、デジタルマーケティングと IBM のマーケティング関連のオファリングと上手く組み合わせてサービスを作っていくなど、 全く同じことをやるのではなく、デジタルの世界でも、試行錯誤しているところです。 他にはモバイルとか モバイル・エクスペリエンスの部隊、マーケティング&コマース、セールスフォースの部隊、 エクスペリエンス・アナリティクス、アナリティクス・ ソリューションもあります。 顧客接点のいろいろな体験マーケティングのソリューションを持っているというよりは、後ろに一緒にいて体験を作っていくように関わっていきます。その時の道具として使っているのが IBM デザイン・シンキングです。共創のためのフレームワークと言うアプローチ方法を適応しています。 これらが C&D （クリエイティブ アンド デザイン）がやっていることで、私は、それをリードしています。いわゆるデザイナーやクリエイティブな人材を抱えていますが、普通のコンサルティングと同じ稼働率で評価されるイメージです（笑）。 ― そこは、なかなか変えることが難しいですよね。 確かに、そこは難しいですね。 IBM デザイン・シンキング －では、IBM デザイン・シンキングについてお聞きしてもよろしいでしょうか。 今の IBM デザイン・シンキングの始まりは、2012年、ジニー・ロメッティは就任の際に、「クライアント・エクスペリエンスが重要だ」と語ったところからです。クラウド、 SaaS といったフィジカルなものではなく、お客様がサービスを試し、良かったら採用する形になる。そうであれば、最初から体験が物を言ってくる、これが重要だ、とも言っています。それを受け、テキサスのオースティンにいるフィル・ギルバートという GM がトップとして 「IBM デザイン」という組織を作りました。そのミッションは、「デザインとデザイン・シンキングのカルチャーを IBM に浸透させる」というものです。 今では、デザイナーを1600人以上抱え、デザイン組織としても有数の規模になっていますが、デザイナーを何人にするということよりもデザインカルチャーを IBM にインストールする、それが浸透して全社員がお客様やユーザーに共感して物事を考えて解決していく、というような組織になりたいということなのです。 そして、私には、デザイン・シンキングを日本の IBM 社内で推進するという役目があります。コンサルタントで稼ぐというのと、他の部門に対してのトレーニング実施、さらに浸透させるためのフォローアップ、これらのバランスが結構難しいです。 今は、営業チーム向けのデザイン・シンキング・トレーニングを四半期に 1、2 回程度行っています。GBS の中途採用者に関しては毎月月初にプログラムとして実施しています。他部門でもニーズがあります。先日もクラウド & コグニティブの部門で 3 日間のイベントをお手伝いしました。 もっと展開できると思っていますが、今はトレーニング （その場で実際の問題を解決するために活用するアクティブラーニングの形をとります）を切り口に浸透させていきたいと考えています。 日本企業には、イノベーションの素養がある ― ここで、デザイン・シンキングって本当に難しいの？という問いについてお考えをお聞かせいただけますか。 デザイン・シンキングは去年結構流行ってましたよね？今年も引き続き流行っていますが、そろそろバズワード化してしまって、結局あれは大したことなかったとなる可能性があります。 それが IBM 社内では起こらないように、きちんと理解してもらった上で、日々お客様サービスやトレーニングでも価値が出るように、日々試行錯誤しています。 先ほど、デザイン・シンキングが日本では難しいんじゃないかという話がありましたよね。確かに難しいんですが、アメリカ人に言わせてみると日本で騒がれていること自体が不思議なようです。 デザイン・シンキングのパイオニア達は日本の『下町ロケット』を参考にした？！ デザイン・シンキングは 1990 年から 2000 年にかけてアメリカ西海岸でスタートしました。その前から、もちろんデザイナーが無意識のうちにやっていたと思いますが、明確にそういう言葉が出てきたのはその頃です。Stanford d.School や IDEO （※）のトム・ケリー、デビッド・ケリー、ビル・モグリッジなどが始めたのです。 ※IDEO（アイディオ）は、アメリカ合衆国カリフォルニア州パロアルトに本拠を置くデザインコンサルタント会社。 彼らを含め、アメリカのデザイン・シンキングに関わる人に言わせると「なぜ日本人は騒いでるんだ？（デザイン・シンキングは）日本人が元々やっていたことを割と参考にしながらやってるんだよ」、ということだそうです。これは、よく言われます。 ― はい、私もそう思います。日本の企業には元々"イノベーション"の素養があるということですね。 多分 Honda さんにしても皆さん、下町ロケット（※）の世界で、大部屋で部門や部署がどうとか関係なくお客様や自分たちの課題があってそれに対してみんなでやってみる。任せて、それぞれの英知を発揮してやってみる。試行錯誤しながら進めていくというようなものだったと思います。正にこれはデザイン・シンキングの世界で、日本にはもともとあった素養なのです。海外から効率化といったものが入ってきて、日本は優等生として取り入れてしまった。その結果、組織が出来上がって、サイロ化して、今では隣の部門が何をやっているのかわからない、そんな縦割りの状況が多く見受けられるようになってしまったのです。弊社でも色々チームを作ってしまうと、そこでどうしても垣根ができてしまう。そういったものを見直したのがアメリカの西海岸のスタートアップの人たちだと思うのです。 （※）池井戸潤の小説、2015 年にテレビドラマ化され話題を呼んだ。 ですので、もともと日本にはそういう素養があります。一度"ガラガラポン"してみてみるのは良いのかなとも思います。 重厚長大な組織でもデザイン・シンキングを導入できる IBM でも 2012 年から本格的に全社を挙げてデザイン・シンキングの導入を始めています。グローバルでは、38 万人の社員の内、9 万人ぐらいが IBM デザインシンキングバッジ認定制度での認定を受けて実践しています。日本だとそれが 7,000 人程度の人間が同様の認定を受けています。 GE 社（※）では、デザイン思考を早くから取り入れていて、リーンスタートアップを取り入れた、ファーストワークス手法を作っています。重厚長大な企業もスタートアップかの如く実践しています。日本の企業も頑張れると思います。ただそこに行くきっかけ、壊すきっかけになるような衝撃、というのがまだまだ足りないのかなと思います。しかし、十分危機感はあるような気がするのですが、今の状況だと。まずは、小さくても良いから試してみる、という思いきりが必要じゃないかなと思います。 ※ゼネラル・エレクトリック（英語: General Electric Company、略称: GE）は、アメリカ合衆国コネチカット州に本社を置く、多国籍コングロマリット企業。 － 私も難しいとは言っていますが、日本の企業が元々やっていることというのは、理解しているつもりです。それでも最近の状況にマッチしないんじゃないか、例えば失敗を許さない雰囲気、コンプライアンスだとか、縦割りの組織であるとか。 IBM がデザイン思考をやると、聞いた時に面白いなあ、と思ったんです。ある意味そことは離れた会社という勝手なイメージがあったので。そこに"デザイン思考"を取り入れていくということは、皆さんがどう苦労され、チャレンジされているのかは、多くの日本企業にとって参考になるのではと思っています。 いくら IBM や GE 社あっても、市場に正式に出した段階、正式リリースした段階などで失敗があった、というのはダメです（笑）。ただ、ここでの小さな失敗はすぐにアップデートしたり軌道修正することもできるので、そういった学習サイクルが早く回ることがどのタイミングであっても大事かと。もちろんそうならないように非常に早いタイミング、これまでよりもずっと早いタイミングで試行（失敗）をするというのがやはり重要です。そのタイミングの失敗だったら、許すよというのが大事です。プロジェクトも後半で、より具現化しなきゃいけない、かなりお金も投入したという段階で、ユーザーテストやユーザーと検証してやっぱり失敗でしたというのはダメです。 本当に早い段階で、まずはアイデアを試す。仮説でもいいからアイデアを作ってみる。アイデアを形にして検証して...というサイクルを早く回してみる。その中で失敗した、で終わるのではなく、その失敗から学んだことを活かして次のステップに進む。なぜ失敗したかということを理解する上では、その過程、その行為を評価する、ということが揃って IBM でも許されてるんじゃないかなという風に思います。 マネージメント層のコーチング・スタイルの変化も必須要件 完全に何をしても失敗してもいい、というものでもないですが、アーリーフェイルア、というよりはランニングですね。そこから何を学習するか、最終的に失敗してしまったら失敗ですけれども、途中の失敗はまだ学習の糧です。マネージメント層もそこをちゃんと理解しないといけない、助言するとしてもこれを前提としたコーチングの方法を身につけなければなりません。 かなり早い段階でこれまでと同じ尺度で、「それいくらになるの？」とお金の話を出すとか、失敗したからだめだよねとか。そういうやり方ではなくて、例えば、ある施策を 10 人のうち 2 人だけすごく欲しいと言っているとします。その場合、見極めて完全に方向転換するのか？この二人というのは実は形にして見せて見ると他の人を取り込めるぐらい先見性を持ったユーザーの 2 人なのか？このような問いができるコーチングや助言が必要です。次のステップに進めるために上手くラーニングを回すための助言が必要なのです。 ＞＞ 後編に続く..... 公開済み！ ↓ 「日本企業にもできるデザイン・シンキング、イノベーションの具体的な方法とは？」後編
座談会：画像認識だけじゃない！ディープラーニングの「使いどころ」とは？ AI、ディープラーニングが注目を集めているが、AI のビジネス活用は、「何ができるのか」から、具体的に「何をするか」という実践のフェーズに入ってきた。とはいえ、多くの企業は必要性は感じつつも、「使いどころ」が明確にイメージできていないのが現状だろう。 そこで今回は「ディープラーニング」にフォーカスし、日本IBM の ITスペシャリストの藤岡 英典 氏、頼 伊汝（らい・いる）氏とエヌアイシー・パートナーズの久田 修央 氏に、ビジネスのユースケースや活用のポイントについて聞いてみた。 右から日本アイ・ビー・エム システムズ・ハードウェア事業本部 先進テクノロジー・センター 頼 伊汝氏、藤岡 英典氏、 エヌアイシー・パートナーズ 企画本部 企画推進部 久田 修央氏、ビジネス＋IT編集部 松尾 慎司氏 ディープラーニングは「人間の認識レベル」を超えている まず、AI の現状について、企業における認識の変化などで感じることを教えてください。 藤岡氏：我々がお客さま先に訪問して感じるのは、「AI で何ができるのか」「何に使えるのか」がまだ明確になっていないケースです。AI は注目されているものの、自社の業務にすぐに活用できるというイメージを持っている企業はまだまだ多くないと感じます。 久田氏：AI という言葉が社会に浸透してきて、企業は取り組む必要性を感じています。一方で、高かった期待値の反動というか、「自分たちに今できることは何か」を冷静に見極めようと考える企業が多いように感じます。 では、AI で何ができるのかについて、改めて現状を整理してください。 頼氏：人工知能は「汎用型人工知能」と「特化型人工知能」に分かれます。汎用型は、人と同じような知能を備えた人工知能で、残念ながらこれはまだ実現できていません。 一方、特化型は、ある特定の領域、分野において人間より優れた知能を持ったテクノロジーのことです。コンピューター囲碁や将棋、自動運転、画像認識といった先端事例を目にする方も多いでしょう。 ルールが決まっている、プログラミングできる特定の領域で、大量のデータを学習することで、人間よりも高いパフォーマンスで正解を導き出そうというテクノロジーといえます。 AI というと、テクノロジーの変化が早く、また、マーケットにはさまざまな用語が飛び交い、そこが混乱を招いている側面もあります。そのあたりを整理していただけますか。 頼氏：人工知能は、1960 年代に提唱され、人間の知能を再現するためのソフトウェアや、ロボティクスなども含む幅広い学問の分野です。その中の 1 つのテクノロジーが機械学習。これは大量のデータからパターンをみつけて、未来を予測していくものです。そして、機械学習の 1 つの手法がディープラーニングで「IBM Watson」（Watson）は、機械学習とディープラーニングの双方にまたがっています。 AI 関連の用語の整理 Watson は PaaS としての「IBM Bluemix」上で動作し、自然言語処理、画像認識などの技術を用いて、様々な機能を API として提供しています。ディープラーニングは Watson の基礎技術の 1 つです。 ディープラーニングについて、もう少し詳しく教えてください。 藤岡氏：次の写真を見て欲しいのですが、この中で、写っているのが「唐揚げ」でないのはどれだか分かりますか？ 唐揚げでないのはどれか？ ぱっと見たところでは難しいですね。どれも唐揚げに見えます。 藤岡氏：実は、唐揚げでないのは【2】なのです。写っているのは犬（トイプードル）ですが、このように人が誤認識してしまうかもしれない画像を、正しく認識できることが期待されています。 最先端の画像認識技術を競う世界的なコンテストがありますが、2011 年までは、画像認識のアルゴリズムは機械学習のロジックを用いるのが主流で、誤認識率は 25 ％ あたりが限界値だと思われていました。 これが、2012 年のコンテストでディープラーニングが登場し、一気に 15 ％ くらいまで、誤認識率が 10 ％ ほど改善したのです。その後、さらにテクノロジーが洗練され、2015 年の段階で、誤認識率は 5 ％ 未満に達しました。 人間の誤認識率は平均で 5 ％ といわれます。すでにディープラーニングは人間の認識レベルを超えるところまで進化しているのです。 AI のがそう認識率は人間を越えている すでに製造業の工場や、サービス業などでディープラーニングの活用事例が出てきた では、実際に、ディープラーニングで何ができるのか、もう少し詳しく教えてください。 藤岡氏：AI のゴールは「人間の知能の代わりになること」にあり、特に、知覚、ビジュアルに関する領域でユースケースが広がってきています。たとえば、画像や映像の中に何が映っているかを検出し、それをカテゴリー分けする技術などがあります。 人が物体を見て「何か」を認識、判断するプロセスは、それまで経験してきた膨大なデータ（記憶）から照らし合わせて判断しています。これが 1 つの学習です。AI も同じで、膨大な画像データから、ものの色や大きさ、形状などさまざまな要素を照合し、「これが リンゴ である」と区別しています。 また、画像の一部が欠損している場合に、人間は頭の中で「そこに何が写っているか」を補うことができますが、機械も同じようなことができます。 そうしたことが実現できると、どんなメリットがあるのですか。 藤岡氏：これまでの機械学習は、たとえば、「目が 2 つあって鼻と口があるのは人間ですよ」というように、正解（特徴）を人間が定義する必要がありました。正解を人が機械に教える必要があるという意味で、これを「教師あり学習」といいます。ディープラーニングはそれをしないで、人工知能自身が記憶を洗練させていくことができる特徴があります。 頼氏：これまでの機械学習とディープラーニングの大きな違いは、扱えるデータ量です。従来の機械学習な得意な領域は数値データ。たとえば、小売店でこういう商品が売れた、その傾向から、このお客さまにはこの商品も売れるのではないか、と予測することです。 過去のデータから予測するので、入力する特徴量がシンプルなのです。 一方、ディープラーニングは、画像や音声、テキストといった非構造化データを扱うことが得意です。たとえば、画像は同じ犬の写真でも、複雑で、1 つとして同じ画像がありません。そうしたデータから正解を予測するのは難しく、上述した通り、これまでは誤認識率が高かったのです。 ディープラーニングにより、煩雑なデータに対しても、高い正解率が期待できるようになりました。 では、実際の事例について教えてください。 頼氏：画像認識については、ディープラーニングを用い、半導体などの製造ラインで、傷やゴミ、汚れなどを判別し、不良品を検出する事例や、工場に限らず、高層ビルやダムなど、人が立ち入りにくい場所にある構造物のひび割れなども、ドローンなどと組み合わせることで、より高精度で効率よく検出できるような事例が出てきています。 実際に、国内企業でディープラーニングの取り組みは進んでいるのですか？ 藤岡氏：国内でも徐々に事例が出てきました。ある損保企業では、自動車保険を乗り換える顧客が保有するさまざまな保険証、車検証などを画像データでもらい、色んな会社の書式をディープラーニングで学習することで、契約時の手入力を省力化する業務効率化のツールとして活用しています。 別の会社では、人の視覚を肩代わりして、熟練したエンジニアの作業を代わりに行うとか、熟練エンジニアの作業を学んで、スキル移転のツールに使うといった事例もあります。 企業にディープラーニング活用を提案する立場として感じることはありますか？ 久田氏：ディープラーニングには大きな可能性を感じます。今は代表的な分野として画像認識に注目が集まっていますが、ビッグデータの時代に、データの組み合わせで色々な発想、可能性が広がってくるでしょう。 ユーザー企業に提案する立場としては、お客さまのビジネスに今、何が求められているかを考えることが、AI のユースケースを広げていくことにつながると考えます。 導入には「正しい教師データ」が不可欠。ハードウェアの整備とあわせて進めたい。 では、企業がAI活用をうまく進めていくためのポイントはどこにありますか？ 頼氏：正しい教師データがあるかどうかがポイントです。一般的な数値データであれば、既存の機械学習の手法で、いいスコアが出ることが期待できます。しかし、ディープラーニングは、先のクイズの"唐揚げ"のような画像や動画といったこれまで分析対象ではなかった非構造化データが必要です。 教師データを整備するには、大量の非構造化データをどう溜め、整理するかという課題もあります。 頼氏：分析の精度に関わるのはデータ量で、画像であれば枚数が多ければ多いほどよいです。 久田氏：そう考えると、データを溜める「器」が重要で、サーバやストレージといったデータセンターの整備が欠かせません。 ディープラーニングを取り入れるに際して、導入ステップというか、環境作りをどう進めるかを教えてください。 頼氏：サーバやストレージの他にはポイントは 3 つ あります。 1 つ は「GPU マシン」で、ビッグデータ解析が可能なコンピューティングパワーが必要です。 2 つ目は「フレームワーク」。ここでいう「フレームワーク」とは、ディープラーニングの分析モデルをパーツ化したもので、これを組み合わせる知識が必要です。そして、3 つ目はそのための「プログラミング」スキルです。 最近は、サービス化されたフレームワークも出てきており、分析モデルを指定してデータを投入すれば、学習結果を出力してくれるサービスが出てきています。その意味で、昔に比べると非常に環境構築はやりやすくなりました。 とはいえ、導入のハードルはかなり高いように感じます。 藤岡氏：IBM では、上述したフレームワークを使いこなせるスキルがなくても、画像を入れれば学習結果を返してくれるサービスを開発しています。これが、ノンプログラミングで、既成の学習パターンで学習してくれるサービス「AI Vision」です。これは「データの準備」「モデルの作成」「モデルの学習」「モデルの利用」の 4 ステップで活用できます。 今はディープラーニングも簡単に活用できる！ 画像をアップロードして、学習モデル（例えば、鳥の画像を分類するというような「タスク内容」）を作成すれば、学習結果が得られ、さらにそれを API として利用できるようになるものです。 API は Web で広く使われているREST API に対応しており、例えば、モバイルアプリと連携することも可能です。 ハードウェアのコスト感はどの程度でしょうか？ 藤岡氏：IBM では、GPU を積んだディープラーニング専用のハードウェアを推奨しており、ディープラーニング用のサーバとして「Minsky」を用意しています。 ディープラーニング用のサーバー「Minsky」 GPU を搭載し、画像等のデータを大量に処理する場合に、GPU と RAM の通信を高速化する「NVLink」に対応しています。提供価格 400 万円からで、Minsky と相性のいいストレージ」「ESS （Elastic Storage Server）」を組み合わせれば、並列に分散処理を行う環境を構築することもできます。 「Minsky」と相性の良いストレージ 最後に、今後､AIやディープラーニングはどう進化していくと思いますか？ 藤岡氏：画像以外の領域としては、IoT のセンサーデータから機器のメンテナンスタイミングを予測する予兆分析などにディープラーニングが活用されるようになるでしょう。 あるいは、音声データから文章を要約、テキストを自動生成することや、広告のキャッチコピーを学習して、コピー文案を考えるといった領域での活用が期待されます。 頼氏：これまではロボティクスと AI を結びつけるのは難しいことでした。今後は、例えばディープラーニングの画像認識でモノを認識し、そのモノにあったつかみ方を判断することで、ロボットアームが最適なピッキングをする、というように、AI が現実世界に対してインタラクションするケースが増えてくるでしょう。 久田氏：こうした先端事例が増えていく中で、まずは「AI Vision」のように、お客さまにはディープラーニングに実際に触れる体験をしていただき、弊社でも新しい技術、製品に習熟していくことで、パートナーと一緒に、お客さまのビジネスに最適な提案、ユースケースを考えていきたいです。 本日は、貴重なお話をありがとうございました。 当セミナーの”動画”は、以下にて公開中です。あわせてご視聴ください。 [ダイジェスト動画公開] 7月13日【NI+C P主催】Webセミナー「Watson の基礎技術 今のビジネスに活かせる AI / ディープラーニング とは？」 ~ 繰り返しますが”今”です ~ [動画・資料公開]7月13日【NI+C P主催】「Watson の基礎技術 今のビジネスに活かせる AI / ディープラーニングとは？」~ 繰り返しますが”今”です ~（MERITひろば） ※ビジネスパートナー専用サイト（MERITひろば）のコンテンツです。ログイン or 新規会員登録が必要となります。 ご参考情報 ◆製品発表情報 【新製品発表】 HPC 用 Linux モデルIBM Power System S822LC （8335-GTB） ◆技術情報 "Minsky" POWER8 NVLink Server （日本情報通信株式会社サイト）
