2017年11月

27

【クラウドとデザイン思考】日本企業にはイノベーションの素養がある ~IBM デザイン・シンキング~(後編)

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 社がどのようにデザイン・シンキングを企業の血や肉としてきたかをお聞かせいただきました。
ツールとしてのデザイン思考に注目が集まりがちですが、そのツールを使う「人」や「場」を準備し、ようやく回り始めるという状況だということがわかりました。

また、単純に推進役だけがデザイン思考というツールを知るだけでなく、チーム全体、マネジメント層の理解を得ることももちろんのこと、ひいては評価制度に至るまで、変えていかなければならない、ということに改めて気づかされました。

その上で「日本にはイノベーションの素養がある」と確信し、それには個人個人、そしてチームのマインドセットが重要との認識を更に強めました。

機会があれば、番外編として、「デザイン思考を実現するマインドセット」について考えてみたいと思います。

 

その他の記事

2025年12月11日

【参加レポート】「IBM TechXchange Summit Japan 2025」に参加してきた

IBM TechXchange Summit Japan 2025 オープニング 「あなたのそばにIBMのテクノロジー」をテーマに、12月3日(水)に東京国際フォーラムで開催された「IBM TechXchange Summit Japan 2025」は、日本IBM最大のIT技術者・開発者向けイベントです。弊社は昨年に続き、今年もスポンサーとして協賛させていただきました。 イベントの見どころは、ハイブリッド・クラウドやAIの未来をテーマにした基調講演をはじめ、お客様やパートナー様による登壇を含む100以上の専門セッションでした。特に、最新技術を体験できる30を超える展示やブース、そして技術者コミュニティーが集まり交流を深める「Technology Happy Hour」は、学びやネットワーキングの一大拠点となり、大いに盛り上がりました。 それでは、本イベントに参加した弊社社員から寄せられたコメントや感想を、各カテゴリやブランドごとにご紹介いたします。 目次 基調講演 ブース セッション Storage Power Cloudハンズオン PowerCloudNEXT watsonx IT Automation ワークショップ まとめ お問い合わせ 基調講演 今回の基調講演では、IBMの各分野のエキスパートの方々から、現在直面している課題や今後の展望について多くの示唆を得ることができました。 特に、開会の挨拶で語られた「共創」というキーワードが私の心に深く響きました。 "エンジニア同士が技術を共有し、協力することで新しい世界を創造できる" とするメッセージには、単なる技術論を超えた、日本のエンジニアへの深い信頼と期待が込められていると感じました。 私自身、日々の業務の中で解決策が見いだせず悩むことがあります。 そんなときに仲間からの何気ないアドバイスや知識の共有が救いになる場面は少なくありません。この言葉には自然と共感しました。 近年のITトレンドでは生成AIなどの先進技術に注目が集まりがちです。 しかし、今回の講演で心に残ったのは、それらの話題に触れる前に「インフラの重要性」が強調されたことでした。 「全ての変革は安定稼働から始まる」という言葉は本質を突いており、どれほど優れたAIやアプリケーションであっても、それを支える基盤が不安定ではその力を発揮できないという事実を改めて実感しました。 IBMが提唱する「4つのハイブリッドクラウド&AI戦略」は、以下の4つのレイヤーで構成されています。 インフラストラクチャー ハイブリッド・クラウド データ&AI 自動化 各分野の専門家が具体的な将来像を提示し、ITの未来に向けたビジョンを明確に描いていました。その中でも特に印象的だったのは、AIが「人間の指示を待つ便利な助手」から「目的を理解し、自律して行動する頼れるパートナー」へと進化している点です。 基調講演の様子 その象徴として紹介された事例が「Project Bob」であり、"Bob"は単なるコーディングアシスタントにとどまらず、複雑な設計やテストにも対応する、まさに開発者の「相棒」と呼べる存在です。 IBM社内では、このプロジェクトを活用することで生産性がすでに45%向上しているとのことでした。反復的な作業をBobに任せることで、人間は「何を創るか」「どう課題を解決するか」といった本質的な業務に集中できる環境が生まれていると紹介されました。 このデモを実際に目にし、私は「AIに仕事を奪われる」のではなく、「AIと共創して新たな価値を生み出す」未来が目前に迫っていることを強く感じました。 未来の開発現場はすでに動き始めており、AIが日常業務に深く溶け込んでいる状況は、数年先の話ではなく「今、すでに起きている」現実です。 開発現場が変革の入り口に立つ "いま"、これからAIとの共創がどのような成果をもたらすのかが非常に楽しみになる、感銘深い講演でした。 ブース 展示エリアでは、IBMの26ブースと、9つのスポンサーブースで構成された展示会場が設けられていました。 この展示会場は単なるブースの集まりにとどまらず、例えばフォトスポットとして「Project Bob」のスポットが設置されるなど、さまざまな工夫が凝らされており、魅力的な内容となっていました。 「Project Bob」のフォトスポット また、この展示エリアには、弊社エヌアイシー・パートナーズもブースを出展しました。弊社のブースでは、コンピューターマネージメント株式会社 様、株式会社ライトウェル 様、株式会社ジール 様と連携し、それぞれのサービスを紹介する共同展示を行いました。 各社様には12時を初回として、2時間ずつの持ち時間で順番に対応していただきました。それぞれの時間枠では、IBM製品と連携する各社様の独自サービスについて、具体的で分かりやすい説明が行われました。 具体的な内容は以下の通りです。 コンピューターマネージメント 様:IBM webMethods Hybrid Integration の導入支援サービスについてご紹介いただきました。 株式会社ライトウェル 様:IBM watsonx Orchestrate を活用した業務別ユースケースのデモンストレーションを実施していただきました。 株式会社ジール 様:IBM watsonx Orchestrate とCO-ODEを統合したCO-ODEエージェントの紹介を行っていただきました。 各社様による説明は、現場での具体的な活用事例や実務に直結する視点を交えて行われたため、ブースに足を運んでくださったお客様も非常に興味深く耳を傾けていらっしゃいました。 今後もこのような貴重な機会を活用し、より多くのお客様に価値ある情報をお伝えしていきたいと思います。また、パートナー企業様との連携を強化し、新たな価値創造を目指して引き続き取り組んでまいります。 セッション Storage BroadcomによるVMware買収以降、市場の大きな変化を受け、多くの企業が代替案を模索する中、「Red Hat OpenShift Virtualization」が現実的な移行先として注目を集めています。これに関連するセッションに参加してきました。 セッションでは、IBM Fusion が OpenShift環境に付加するストレージ機能やバックアップ/災害対策機能について紹介されていました。特に、HCI(ハイパーコンバージドインフラ)タイプを選択することで、OpenShift環境の迅速な立ち上げや統合管理、さらにIBMが提供するワンストップのサポート窓口によって運用負荷を軽減できる点が強調されていました。 また、Fusion が単なる外部ストレージとして動作するのではなく、OpenShift上のオペレーターとして機能する点が非常に印象的でした。このおかげで、管理者は慣れ親しんだOpenShiftコンソールを利用して、ストレージ操作やバックアップ設定まで一貫して実行することが可能となるため、大きな利便性を提供します。 さらに、OpenShift環境におけるストレージの選択肢についても議論がありました。通常は、ワーカーノードの内蔵ディスクをSDS(Software-Defined Storage)によって共有ストレージ化するHCI型が一般的ですが、必ずしもHCI型が万能というわけではありません。 HCI型には、ディスクリソースの追加に対する柔軟性の制限や、ディスク障害時にリビルドがパフォーマンスに与える影響などのデメリットもあります。このため、FlashSystem のような外部ストレージがより適した選択肢となるケースもあることが紹介されました。 今回のセッションを通じて、OpenShift環境においてストレージ選定が運用における重要なポイントであることを改めて認識しました。 Power 2025年のPowerブランドは、7月に発表された「Power11」を皮切りに、大きな飛躍を遂げた1年となりました。今年は Power11 や IBM i に関する最新情報が続々と発表され、多くの注目を集めています。その中で、今回は特に話題となっている生成AIに焦点を当ててレポートします。 セッションを通じて強く感じたのは、エンタープライズの信頼性が求められる本番環境にAIを適用する際に、Powerが果たす重要な役割です。 間もなく一般提供(GA)が予定されているAIアクセラレーター「Spyre」は、この分野の鍵を握るテクノロジーだといえます。Spyre は低電力ながら高性能を発揮するという特徴があり、これをPowerとの組み合わせで活用することで、ミッションクリティカルな業務へのAI導入が現実的になります。性能面だけでなく、効率的な電力消費の観点からも、非常に大きな可能性を秘めていると感じました。 また、今回のイベントで特に注目を集めたのが、基調講演でも大々的に取り上げられた「Project Bob」でした。このプロジェクトは、Power分野における IBM i の次世代AIコード開発パートナーとして注目されています。会場内ではBobに関連するパネルが至る所に設置され、来場者の関心の高さと、IBM全社を挙げての取り組み規模の大きさが強く印象に残りました。 私自身も現在、「Project Bob」の早期アクセスプログラムへのノミネートを待っている状況ですが、"Bob"にどのような業務を任せられるのかに大きな期待を寄せています。 AIとPowerが生み出す、さらなる高性能かつ信頼性の高いエンタープライズ環境の未来が、今や目の前まで迫っていると実感できたセッションでした。 Cloud ハンズオン 「さわってみよう — 初めての PowerVS ハンズオン」に参加しました。 本ハンズオンは、セッションに併せて開催され、『AIX・IBM i・Linuxのいずれかを触ったことはあるけれど、IBM Power Virtual Server(PowerVS)は未体験の方向け』という説明どおり、私のような PowerVS 未体験者でも気軽に参加できる内容でした。 今回は、自分の端末を使用してハンズオンを行い、環境準備から操作まで実際の手順をその場で試せたことが非常に良かったです。また、講師の方が丁寧に説明してくださり、つまずいた箇所ではその都度サポートをいただけたため、スムーズに進行することができました。 最終的には、ハンズオンのゴールであるAIX(または IBM i )インスタンスの作成も無事に完了し、とても楽しく有意義な体験となりました。 PowerCloudNEXT 「PowerCloudNEXTとPower11の未来共創」に参加しました。 このセッションでは、柔軟性と可用性に優れたプラットフォームである PowerCloudNEXT の概要が紹介され、その未来像について語られました。 来年には待望の次世代プロセッサ「Power11」の提供が開始されます。Power11 は、前世代の Power9 と比較して性能が45%向上しており、特に注目すべき点としてAI推論チップを内蔵していることが挙げられます。事前検証結果も好調とのことで、性能向上への期待が高まります。 さらに、2026年までのロードマップでは次のような機能やサービスが計画されていることが明らかになりました。 AIを実装した「AI組込ポータル」 データ管理を強化する「ボリュームコピー」 お客様のニーズに対応する「ベアメタル環境」の提供 これにより、ユーザーの選択肢がさらに広がり、より自由度の高い利用が可能になります。 また、IBMの「Project Bob」によるRPGプログラムの開発支援や、「X-Analysis」を活用したシステム保守支援および後継者育成の取り組みについても紹介されました。これらのソリューションは、業務システムの効率化や技術者不足の解消に向けて大きな効果が期待されています。 Power11のリリースとAI技術の本格的な採用により、PowerCloudNEXT はさらに進化すると確信しています。2026年の動向も引き続き注目していきたいと思います。 watsonx watsonx Orchestrateに関するハンズオンでは、11月24日から利用可能となった「GPT-OSS 120B — OpenAI(via Groq)」を活用し、ノーコードでエージェントを作成してその動作を確認しました。 AIエージェントの開発がこれほどまでに簡単に行えることに驚きました。 また、パートナー様セッションでは、AIエージェントの具体的な提案プロセスや経験を基にしたリアルな知見を伺い、大変参考になりました。 watsonx.data Premium に関するハンズオンでは、非構造化データ(PDFのデータ)を取り込み、エンティティを抽出した上でそれに意味付けや分類を施し、構造化テーブル(ICEBERG形式)へ格納する手法を学びました。 これまで非構造化データのキューレーション(UDC:Unstructured Data Curation)は難しいイメージがありましたが、実際に手を動かしてみると想像以上に簡単で、直感的に操作できることに衝撃を受けました。非構造化データが信頼できる情報資産としてフル活用される未来が、すぐそこまで来ていると感じています。 これらのハンズオンやセッションを通じて、watsonxシリーズが提供する先進的な技術やその可能性を体感でき、非常に有意義な時間となりました。 IT Automation ワークショップ IBMの運用自動化ポートフォリオについての解説と、実践的なワークショップを体験しました。 基調講演でも触れられていた「なぜ現在、自動化に取り組むべきなのか」という背景や、自動化がもたらす効果について学んだ後、IBMの運用自動化ソリューションがどのようにそれを実現するかが紹介されました。 自動化と聞くと、「すべてを一括で対応しなければならない」と考えてしまいがちですが、実際には業務の一部を切り出し、段階的に自動化を進めることで効果を得られるということが理解できました。負担を抑えつつ、確実な成果を上げるためのアプローチとして非常に有効だと感じました。 ワークショップの後半では、参加者の関心テーマに基づいたグループワークが実施され、各自が抱える課題に対して具体的な自動化の例や、それを実現するための製品について議論を深めました。このセッションを通じて、運用自動化の可能性についてさらに理解を深めることができました。 まとめ 今回のイベントは、進化を続けるIBMの最新テクノロジーを深く学ぶだけでなく、技術者同士が交流し、新たな知見や繋がりを得る場として、大変活気あふれる充実した内容でした。 さらに、これまで本イベントは年1回の開催でしたが、2026年の「IBM TechXchange Summit Japan」については、春、夏、冬の年3回開催されることが発表されました。これは、より多くの最新情報や交流の機会が提供されることを意味しており、非常に楽しみです。 次回の来春には、どのような新しいテクノロジーやアイデアに出会えるのでしょうか。ますます期待が高まりますね。 東京国際フォーラム 館内 ※本ブログは参加者の主観が含まれており、記載されている情報は正確性に欠ける場合があります。記載内容についてより詳細な情報をご希望される方は、以下の問い合わせ先までご連絡ください。 お問い合わせ エヌアイシー・パートナーズ株式会社技術企画本部E-Mail:nicp_support@NIandC.co.jp   .bigger { font-size: larger; } .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; } .table { border-collapse: collapse; border-spacing: 0; width: 100%; } .td { padding: 10px; vertical-align: top; line-height: 1.5; } .tbody tr td:first-child { font-weight: bold; width: 20%; } .tbody tr td:last-child { width: 80%; } .ul { margin: 0 !important; padding: 0 0 0 20px !important; } .ol { margin: 0 !important; padding: 0 0 0 20px !important; } .tr { height: auto; } .table { margin: 0; } *, *:before, *:after { -webkit-box-sizing: inherit; box-sizing: inherit; } .html { -webkit-box-sizing: border-box; box-sizing: border-box; font-size: 62.5%; } .btn, a.btn, button.btn { font-size: 1.6rem; font-weight: 700; line-height: 1.5; position: relative; display: inline-block; padding: 1rem 4rem; cursor: pointer; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; -webkit-transition: all 0.3s; transition: all 0.3s; text-align: center; vertical-align: middle; text-decoration: none; letter-spacing: 0.1em; color: #212529; border-radius: 0.5rem; } a.btn--orange { color: #fff; background-color: #eb6100; border-bottom: 5px solid #b84c00; } a.btn--orange:hover { margin-top: 3px; color: #fff; background: #f56500; border-bottom: 2px solid #b84c00; } a.btn--shadow { -webkit-box-shadow: 0 3px 5px rgba(0, 0, 0, .3); box-shadow: 0 3px 5px rgba(0, 0, 0, .3); }

2025年11月10日

【早わかり】ILMT導入前の注意点

更新日:2025-11-10 公開日:2023-05-23 *  *  *  *  *  * こんにちは。てくさぽBLOGメンバーの原田です。 IBMソフトウェア(Passport Advantage:以下 PA)ライセンス管理ツールである IBM License Metric Tool(以下 ILMT)を導入するにあたり、ILMT の具体的な構成と導入前の注意事項についてご説明いたします。 ILMT の必要性や基本的な利用ルールついては「【早わかり】仮想化環境でIBMソフトウェアを利用するには」で解説していますので、ぜひご覧ください。 目次 はじめに ILMT9.2管理サーバーの導入タイプ ILMT9.2でサポートされるオペレーティング・システム ILMTサーバー構成に関するよくある質問 さいごに お問い合わせ はじめに ILMT でのライセンス管理にあたっては、ILMT管理サーバーを用意し、ライセンス管理を必要とするサーバーに対して ILMTエージェントを導入する必要があります。 パスポートアドバンテージ契約が必要 ILMT は無償のツールですが、製品のダウンロードや技術サポート受けるにはパスポート・アドバンテージのご契約が必要です。このため、ゼロ円のライセンスの発注が必要な点にご注意ください。 ご契約が締結されていない場合は、製品のダウンロードや技術サポートを受けることができません。また、翌年以降もソフトウェア・サブスクリプション&サポート(以下 SS&S)をゼロ円で注文する必要があります。(※SS&S契約がないとバージョンアップができないため) ILMT管理サーバーは専用サーバー(区画)への導入が前提 ILMT は専用のサーバー機または仮想サーバーにインストールすることが前提とされています。 他のアプリケーションと共存させた場合、リソースやポートの競合が発生する可能性が考えられます。運用開始後に想定外の問題が発生することを避けるためにも、ILMTサーバー用に専用のサーバー機、または仮想サーバーをご用意ください。 ILMTは常に最新のバージョンをご利用ください サブキャパシティ・ライセンスのご契約条件上、ILMT は常に最新のバージョンをご利用いただくことが前提です。 最新バージョンをご利用でない場合は規約違反となり、監査上お客様に不利益が生じる可能性がありますのでご注意ください。 また、最新バージョンには様々な修正が含まれているため、問題の発生を事前に抑制するためにもバージョンアップをご実施ください。 現時点での ILMT最新バージョンは9.2となっています。9.2リリース後も「License Metric Tool -新機能-」(IBMサイト)に記載の通り随時修正がリリースされるため、常に最新化する必要があります。 ILMT9.2管理サーバーの導入タイプ ILMT の現時点最新バージョンは9.2です。ILMT 9.2 における管理サーバーの導入タイプとしては、以下の3種類が用意されています。 License Metric Tool Lite Ansibleを使用したLicense Metric Tool BigFixを使用したLicense Metric Tool 上記のうち1と2については、エージェント側で収集した情報を手動でサーバーに渡す仕組みを検討する必要があるため弊社では「3」のタイプでの導入を推奨しており、今回は「3」のパターンで ILMT管理サーバーを構成する場合についてご説明します。 各導入タイプの詳細については「License Metric Tool -インストール-」(IBMサイト)の資料をご参照ください。 BigFixを使用したLicense Metric Toolの構成概要図 以下図の通り、サブキャパシティー・ライセンス対象のシステム上に導入する BigFixクライアントにて収集したデータを ILMT/BigFixサーバーにアップロードし、ILMTサーバーにて監査レポートを作成します。 BigFixサーバーから最新のソフトウェアカタログを入手するため、インターネット接続が必要です(直接インターネットに接続できない構成の場合はAir-Gapped構成も可能) BigFix は HCL社の製品ですが、ILMT で利用する BigFix については IBMサポートの対象となります ILMT9.2でサポートされるオペレーティング システム 次に、「IBM License Metric Tool」(IBMサイト)を元に、ILMT を導入するサーバーのオペレーティング・システムの前提を確認する必要があります。 [確認手順] 1) 表示される画面で最新バージョン・リリースを選択してください。 2) 次に表示される画面で「Operating Systems」を選択してください。 3) 次に表示される画面で現在サポートされているOS・バージョンをご確認いただけます。 ILMT管理サーバーとエージェントを導入するサーバーでは、サポートされるオペレーティング・システムが異なりますのでご注意ください。 弊社では、LESサーバーを利用した ILMT管理サーバーのサンプル構成(現在は以下に記載の4パターン)を準備しています。 Windows構成 RHEL構成 特徴 1台のマシンにILMTサーバー、BigFixサーバー、BigFixコンソールを同居させる構成 1台のマシンにILMTサーバー、BigFixサーバーを同居させる構成 BigFixコンソール 別途用意は不要 別途PC等で用意が必要(Windowsのみサポート) ILMT管理サーバーのOS Microsoft Windows Serve Red Hat Enterprise Linux(RHEL) データベース MS SQL Server Standard Edition(コアライセンスモデル) Db2(ILMTサーバーライセンスとともに無償提供) 主なHWスペック、オプション モデル:SR250 V3 3年保証CTOモデル CPU:「エンドポイント 最大1,000」パターン:4コア    「エンドポイント 1K~5K」パターン:6コア メモリ:16GB 内蔵ディスク:600GB 10K SAS HDD x 3(RAID1+ホットスペア) 1GbE NIC:オンボード2ポート + 4ポートアダプター x 1 その他:外付けDVD-RW、200V電源コード 保守:5年24x7、メディアお渡しオプション、Value Selection ILMTサーバー構成に関するよくある質問 Windows構成の場合、データベースとして MS SQL Server Expressは利用できますか? IBM License Metric Tool と BigFix を同一コンピューターに導入するオールインワン構成の場合、SQL Server Express はご利用いただけません。また、BigFix は本番環境での SQL Server Express のご利用はサポートされておりません。従いまして、Windows にて IBM License Metric Tool を構築する場合は、有償版の SQL Server が必要となります。 RHEL構成の場合、データベースとして別途Db2ライセンスの購入が必要でしょうか? いいえ。Db2ライセンスはILMTライセンスとともに無償で提供されるため、別途購入は不要です。 RHEL構成の場合、BigFixコンソールは別途必要でしょうか? はい。BigFixコンソールは Windows のみがサポートされるため、別途PC等で BigFixコンソールをご用意いただく必要があります。「オプション A: Linux へのオールインワン・インストール(BigFixシナリオ)」もご参照ください。 さいごに 昨今のシステムでは仮想化やコンテナ化は当たり前になり、仮想化環境やコンテナ環境におけるソフトウェア製品のライセンス管理は必要不可欠となっています。コンテナ環境で IBM PAライセンスをご利用される場合には「IBM Container Licenses」(IBMサイト)をご確認ください。 IBMソフトウェア製品のライセンス管理ツールとして ILMT はおなじみの製品となりましたが、ILMT を取り巻く環境や制度は時代の流れと共に変化しています。ぜひ正しい理解のもとでご利用いただきますようお願いいたします。 また、IBM PAライセンスを管理するツールとして「Flexera One with IBM Observability」という SaaS製品もございます。弊社での導入検証結果を「【やってみた】IT資産管理ソリューション「Flexera One with IBM Observability」を使ってみる -Part1-」でご紹介していすので、ぜひご覧ください。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail:nicp_support@NIandC.co.jp   .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; }

2025年11月05日

クラウド環境のインフラストラクチャ自動化にIaCツール「IBM Terraform」が活用される理由

公開日:2025-11-04 企業の中で、さまざまなシステムが存在する今、環境が変わっても、システムが同じ動きをしなければ、開発者の負担となるだけでなく、ユーザーからのクレームを招くことにもなります。 特に、大量のリクエストを捌くためのシステムでは、コンテナを活用してサーバー台数を自動で増減させるような仕組みが必要です。 そこで今、企業に求められているものが、インフラストラクチャの効率的な管理を実現する自動化です。 本コラムでは、インフラストラクチャの自動化において注目されている、「コードとしてのインフラストラクチャ : Infrastructure as Code(IaC)」の活用メリットと、今、世界のクラウド環境でもっとも多く利用されているIaC ツール「Terraform」をご紹介します。 目次 規模と複雑さが増大し続けるITインフラストラクチャに対して、企業に求められる課題 ITインフラストラクチャの自動化が必要な理由 「Infrastructure as Code(IaC)」による自動化のメリット クラウド環境でもっとも利用されている IaC ツール「Terraform」 Terraformが選ばれる理由 TerraformとAnsibleの連携で実現するエンドツーエンドのハイブリッド・クラウド・プラットフォーム まとめ お問い合わせ 規模と複雑さが増大し続けるITインフラストラクチャに対して、企業に求められる課題 多くの企業が、1日に何百ものアプリケーションを本番環境にデプロイしています。そこでは常に、ITインフラストラクチャが要求に応じて立ち上げられ、あるいは削減され、その規模は頻繁に拡大や縮小が行われています。そのため、ITインフラストラクチャを安全かつ効率的に、構築、変更、バージョン管理することが、企業が提供するビジネスの品質・スピード・競争力を左右する最も重要な要素となりました。 しかし、企業や組織のITインフラストラクチャの規模と複雑さが増大する一方で、時間やスタッフの数には限りがあり、ITチームは従来の手法ではこの拡大に対応するのが精一杯となっています。その結果、システムの更新やパッチの適用、リソースの提供に遅れが生じ始めている状況です。 そこで今、企業が急ぎ導入を進めているのが、「ITインフラストラクチャの自動化」です。 ITインフラストラクチャの自動化によって、プロビジョニング、構成、デプロイ、撤去などの一般的な管理タスクを含む幅広い運用を単純化できるほか、ITインフラストラクチャに対する制御力や可視性を取り戻すことが可能となります。 そのため、企業においてITインフラストラクチャの自動化は、コストを管理し、リスクを低減し、新たなビジネスチャンスや競争上の脅威に迅速に対応するためには不可欠な施策となっています。 ITインフラストラクチャの自動化が必要な理由 ITインフラストラクチャの自動化の必要性には、具体的に次のようなものが挙げられます。 マルチクラウドやハイブリッドクラウドの活用 マルチクラウドやハイブリッドクラウドの活用している場合、ITインフラストラクチャの管理において、多種多様な複数クラウドを管理するだけでなく、マルチクラウド間でのリソース移行や追加が求められます。また、クラウドネイティブアーキテクチャの採用においては、Kubernetesやサーバレスリソースのプロビジョニングなど、柔軟なリソース展開とスケーリングにも対応しなければなりません。 コンプライアンスとセキュリティへの対応 ITインフラストラクチャの管理において、コンプライアンスとセキュリティに対応するためには、変更履歴のトレーサビリティを確保しつつ、セキュリティ要件と一貫性のある構成変更を行うことが重要となります。また、リソースコストの最適化を図るだけでなく、複数リージョンの管理と迅速な障害復旧によるグローバルな運用と展開を実現することも必要です。 クラウドコストの削減 クラウドに対する企業のコストは年々増加しており、クラウドコストの削減も大きな懸念事項となっています。 正しいクラウドのライフサイクル管理を行えば回避可能なインフラストラクチャ関連コストとしては、 ワークロードに対するリソースのオーバー・プロビジョニング 未使用または十分に活用されていない開発/テスト用環境などのリソース 標準化された共有サービス不足による専門知識、一貫したワークフロー、引き継ぎ不足 環境削除のための有効期限未設定による一時的なクラウドリソースの稼働継続 などがありますが、これらの無駄なクラウドコストを削減するためには、初期プロビジョニングだけでなく、ライフサイクル全体の管理が必要です。 「Infrastructure as Code(IaC)」による自動化のメリット ITインフラストラクチャの自動化において、多くの企業から注目されているのが、インフラストラクチャをコードベースで管理・自動化できる「Infrastructure as Code(IaC)」です。 IaC は、サーバーやネットワークといったITインフラストラクチャの構成と管理に、手動プロセスではなく、高レベルの記述モデルで記述的なコーディング言語(プログラム)を用いる手法です。ネットワーク、仮想マシン、ロード・バランサー、クラスター、サービス、および接続トポロジーなど、組織のITインフラストラクチャの管理およびプロビジョニングを自動化することで、リスクとコストを抑えながら、より迅速なクラウド・アプリケーションの開発・導入・拡張を可能にします。 また IaC は、ソフトウェア・デリバリー・ライフサイクルに欠かせない DevOps において、競争力のあるペースを生み出すための必須の手法でもあります。DevOpsチームは IaC を活用することで、ソースコードのバージョン管理を行うのと同じ感覚でインフラストラクチャを迅速に作成し、バージョンを管理し、バージョンを追跡することで、デプロイ時にIT環境間の不整合による深刻な問題を引き起こす可能性を回避することができます。 その結果、IaC を活用することで、ソフトウェア・アプリケーションの開発、テスト、またはデプロイのたびに、サーバー、オペレーティング・システム、データベース接続、ストレージなどのインフラストラクチャを手動でプロビジョニングおよび管理する必要がなくなることから、 (1)オートメーションによる構成の編集、共有、再利用の高速化 (2)ITインフラストラクチャ管理の信頼性向上 (3)意図しない設定変更や設定ミスによる構成の差異による構成ドリフトの防止 (4)実験・テスト・最適化をサポートし新しいインフラストラクチャを迅速にスケールアップ を実現し、クラウド・アプリケーションの開発・展開・拡張の迅速化とともに、リスクの軽減とコストの削減への効果が期待できます。 クラウド環境でもっとも利用されている IaC ツール「Terraform」 IaC ツールは数多くありますが、AWSやGoogle Cloud 環境において、それぞれのクラウドベンダーが提供するネイティブな IaC ツールよりも多くの企業に採用されている IaC ツールが「Terraform」です。Terraformは、クラウドインフラのプロビジョニングで業界標準ツールとして、デファクトスタンダートの位置付けにあります。 Terraformは、クラウドネイティブな環境におけるインフラ運用の自動化を実現するソフトウェアです。宣言型のプロビジョニングおよびインフラストラクチャ・オーケストレーションにも対応しており、大規模なシステムやマルチクラウド環境において特に高い効果を発揮し、インフラ管理の効率化と安定化に大きく貢献します。また、インフラの設定をコードで記述し、それを基にインフラを構築・管理することで、手作業による人為的な設定ミスを減らし、環境の再現性を高めることができます。 さらに、AWS、Azure、Google Cloud Platformなど、複数の主要なクラウド・プロバイダーに対応しており、プロビジョニング対象のリソースが豊富であることもTerraformの大きな特徴で、クラウドサービスの対応数は300以上に登ります。そのため、物理的なサーバーや DNSサーバー、複数のプロバイダーのリソースを同時に構築する自動化が可能です。さらに、様々な言語で書かれたアプリケーションを提供することができます。 これにより、企業のクラウドベース、オンプレミスを問わず、すべてのインフラストラクチャの全側面のプロビジョニングを自動化し、クラウド環境やオンプレミス環境のインフラを効率的に管理します。また、クラウド環境で調達するサーバーの構成についても、「どのクラウドサービスで」「どのようなスペックを持つ仮想サーバーやリソースを使うか」といった指定をコードで記述することで、各クラウドのITリソースを調達し、需要に応じてリソースを割り当てるなど、効率的なシステムやサービスの運用を可能にします。 Terraformが選ばれる理由 Terraformが企業に選ばれる理由には、次のようなものが挙げられます。 プラットフォームにとらわれない 他のほとんどのIaCツールは、単一のクラウド・プロバイダーで動作するように設計されていますが、Terraformは、プラットフォームにとらわれず、任意のクラウド・サービス・プロバイダーで利用することが可能です。 イミュータブル・インフラストラクチャ Terraformは、「イミュータブル・インフラストラクチャ」の思想に基づき設計されています。これは、一度構築したサーバーやコンテナなどのインフラに直接変更を加えず、変更が必要になった場合、新しいインフラを構築して入れ替える運用思想です。これにより、構成のずれ(環境差分)を防ぎ、システムの安定性を高め、セキュリティリスクを低減し、運用効率を向上させます。環境を変更するたびに、現在の構成は変更を考慮した新しい構成に置き換えられ、インフラストラクチャが再プロビジョニングされるため、以前の構成をバージョンとして保持したまま、意図しない設定変更や設定ミスによる構成の差異による構成ドリフトを防止し、必要あるいは要望に応じてロールバックを可能にします。 マルチクラウドやハイブリッドクラウドの活用マルチクラウドやハイブリッドクラウドの活用 Terraformが提供するのは、複数クラウドを管理できる統一的なフレームワークです。そのため、マルチクラウド間でのリソース移行や追加が簡易なだけでなく、多種多様なクラウドへの対応を可能にして、クラウド・アプリケーションの開発・展開・拡張を迅速化します。 クラウドネイティブアーキテクチャの採用とクラウドコストの最適化 クラウドネイティブアーキテクチャを採用しているTerraformは、Kubernetesやサーバレスリソースのプロビジョニングに対応しています。そのため、柔軟なリソース展開とスケーリングを簡単に実現することが可能です。また、動的なリソースプロビジョニングと削除を自動化し、コスト分析ツールとのタグ統合でリソースコストを可視化することで、無駄なクラウドを精査してクラウドコストを最適化します。 コンプライアンスとセキュリティ対応に基づくグローバルな運用・展開 Terraformは、変更履歴のトレーサビリティを確保し、ポリシー管理ツールでセキュリティ要件を自動化することで、一貫性のある構成変更と自動化のコンプライアンスとセキュリティ対応を可能にします。このコンプライアンスとセキュリティ対応を担保したままモジュール化されたコードで、グローバルに展開することも可能で、複数リージョンの管理を自動化し、迅速な障害復旧も実現して、より信頼性のあるITインフラストラクチャ管理が可能になります。 TerraformとAnsibleの連携で実現するエンドツーエンドのハイブリッド・クラウド・プラットフォーム IBMは、Terraformを開発した HashiCorp社を2025年2月に買収しました。この買収を通じてIBMは、ハイブリッドクラウドとマルチクラウド環境におけるエンドツーエンドの自動化機能の提供と、AI時代に対応するお客様の複雑なITシステムの管理を支援することを目指しています。 その中でも特に、ハイブリッドクラウド環境におけるアプリケーションのプロビジョニングと構成の簡素化に大きく貢献するものとして期待されているのが、ITインフラのプロビジョニングとライフサイクル管理を自動化する「Terraform」と、オーケストレーションおよび構成管理を得意とする「Ansible」の組み合わせです。 IBMのHashiCorpの買収は、そのシナジー効果を見込んだものでもあります。 Ansibleは、IBM傘下のRedHatが開発するプロビジョニング、構成管理、およびアプリケーションのデプロイメントを自動化することを目的としたIaC ツールです。シンプルでエージェントレスなアーキテクチャを採用しており、IT運用の効率化やDevOpsの実践を支援することから、Docker コンテナや Kubernetes のデプロイメントのプロビジョニングを自動化するために多くの企業に選ばれています。 ここで重要なのは、同じIaC ツールでありながら、TerraformとAnsibleでは得意な領域が違うことです。そして、両製品は競合させるのではなく、連携させることで効果が大きくなります。 Terraformが、特定のインフラベンダに依存せず、さまざまなクラウドインフラのプロビジョニング情報のIaC (による自動化を実現する)ツールであるに対して、Ansibleは、インフラ上のOSやミドルウェアの構成管理で業界標準の位置付けであり、豊富なミドルウェアの自動構成・設定機能で、ITインフラの構成管理やアプリケーションデプロイメントを自動化します。 「インフラ層の構成管理」を得意とするTerraformと、「OS・ミドルウェア層の構成管理」を得意とするAnsibleは、それぞれ異なるプロビジョニングレイヤを担っており、対象となるリソースのライフサイクルも異なります。そのため、双方を効果的に使い分けることで、IaCの効果を最大化することができるのです。 図版-1「インフラ層の構成管理」を得意とする Terraformと「OS・ミドルウェア層の構成管理」を得意とするAnsibleの最適な組み合わせ まとめ NI+C Pは、IBM ソフトウェア(SW)とハードウェア(HW)の認定ディストリビューターとして、Terraform をはじめとするIBM のIaC製品において豊富な取扱い実績を有しています。 Terraform については、Ansibleとの連携だけでなく、「Cloudability 」や「Turbonomic」などのIBMの他製品との連携についても、お客様のニーズや要件に合わせて、IBM の SW と HW を組み合わせた最適な提案やカスタマイズの支援、 IBM 製品の特徴や利点をお客様にわかりやすく説明し、お客様・パートナー様のビジネスに最適な提案をサポートいたします。 インフラ環境の複雑化とともに、さらなるニーズの高まりを見せているIaCの活用および Terraform の導入について、弊社の技術支援チームによるスキルイネーブルメント(座学勉強会や技術者認定試験の取得支援、ご提案サポート)、 また、Terraform を絡めたIaC製品セールスのサポートへのご要望があれば、いつでもお気軽にお問い合わせ・ご相談ください。 お問い合わせ この記事に関するお問い合せは以下のボタンよりお願いいたします。お問い合わせ   .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:26px; } .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; }

2025年10月29日

水冷サーバーの違いとは?(レノボの水冷サーバー#2)

公開日:2025-10-29 こんにちは。ソリューション企画部 柳澤です。 前回レノボの水冷サーバーについてのブログを書かせていただき、いろいろなお客様にブログを読んでいただきました。 前回の記事はこちら 昨今、お客様ご自身の身の回りでもChatGPTの普及などでAIについて皆様も身近に感じてこられるようになってきたかと思います。 今後はさらにAI、機械学習、HPCの台頭による計算能力の劇的な向上が見込まれます。 それに伴う発熱量の増加で、従来の空冷システムの限界により水冷技術への注目度が高まっています。 レノボの水冷と聞いて、レノボが今年初めて水冷サーバーを発表したのでは?と思うお客様もいらっしゃるかもしれません。しかし、レノボの水冷は2012年に発表された製品であり、その導入事例も世界に多数あります。 弊社としましては、レノボの水冷サーバーについてラインナップの多さ、その歴史と導入事例の多さから、今後のAIやHPCの需要が高まる時代を取り巻く中で皆様にぜひご提案させていただきたく、今回もレノボの水冷サーバーにテーマを絞ってブログを掲載させていただきたいと思います。 では早速ですが、前回お伝えできなかった部分もふくめて、下記にてさらにレノボの水冷サーバーについて、ご紹介させていただきます。 目次 レノボの水冷サーバーの歴史と導入事例 Lenovo Neptune®とは レノボの水冷サーバーと他メーカーの違いとは レノボの水冷サーバーの問題解決対策について 関連情報 お問い合わせ レノボの水冷サーバーの歴史と導入事例 前述のとおり、レノボの水冷サーバーは発表されてからすでに12年以上経っており、水冷サーバーについては業界をリードする存在です。 導入事例も多数あり、下記の導入事例を含め、世界トップ10のパブリッククラウドプロバイダーで8社を支えるインフラとなっています。各国の研究機関や、企業でも導入が進んでおり、スーパーコンピューターから小規模な拠点まで採用されており、日本でも今後採用が進むことと思われます また以前は空冷サーバーにくらべて10〜20%の追加コストが発生していましたが、これまでの空冷サーバーとの部品共通化でコストの違いはそこまで大きなものにならなくなってきています。 Lenovo Neptune®とは 「Lenovo Neptune®」はLenovoが展開する水冷技術ブランドであり、以下の3つの技術カテゴリで構成されています。 Neptune® :システム全体の温水冷却により温水再利用を実現 Neptune® Core :コンポーネントレベル冷却(CPU、GPU、メモリ)により通気要件を削減 Neptune® Air :空冷ベースシステムでの液体補助冷却 本稿で取り上げるのはこのうちの「Neptune®」の直接液体冷却構成となります。サーバー筐体からラック全体に至るまで、純水を用いた直接水冷(DWC)によって冷却を最適化。空冷ファンを排除し、最大40%の電力削減と100%の熱除去を実現します。AI・HPC用途に最適化された設計で、静音性・省スペース・環境対応の面でも優れています。 導入事例から見るNeptune®の実力 DreamWorks AnimationNeptune®導入により、レンダリング性能20%向上、電力コスト削減を達成。MoonRayレンダラーやArrasクラウド計算システムの性能を最大限に引き出している。事例詳細 韓国気象庁(KMA)8000台のNeptune®搭載サーバーで、気象予測の高速化と省エネを実現。SD650 V2およびSD530サーバーを活用し、精度の高い気象モデルを運用。事例詳細 ハーバード大学同じスペースで従来の4倍の計算性能を実現。Neptune®による完全ファンレス運用で、研究成果の加速に貢献。事例詳細 レノボの水冷サーバーと他メーカーの違いとは 前回の記事でもふれましたが、水冷にはレノボや多くのIAサーバーメーカーが採用している直接液冷と、専用メーカーが採用している液浸冷却などいくつかの方式があります。 直接液冷は発熱源に直接アプローチすることで効率的な冷却と省電力・静音性を実現します。液浸冷却はサーバー全体を冷却液に浸すことで非常に高い冷却能力と省エネ性能、高密度化を可能にしますが、設備投資が高額というデメリットもあります。 では直接液冷のレノボのNeptuneと直接液体冷却方式を採用しているメーカーとの比較とレノボの優位性がある部分はどうなっているのでしょうか。 主な違いは下図のようになっています。 直接液体冷却方式のレノボと他メーカーとの違い レノボの水冷サーバーの問題解決対策について 水冷サーバーというと液体を扱うサーバーゆえにこぼれたり、漏れたりするのではないか、とおっしゃるお客様もいらっしゃいます。 そのための対策もレノボでは下の表のように対策されています。 いやいや、でもAI×水冷サーバーといったってよくわからないし、というお客様にはレノボさんでAIディスカバリーワークショップもやっていただけます。 ワークショップ→POC→アセスメント→本番環境導入という流れで実施となりますので、ご提案や、ご不明な点などございましたら、ぜひ弊社へお問い合わせいただければと思います。 関連情報 Lenovo サーバー/ストレージ 製品 【参加レポート】Lenovo TechDay @ Interop Tokyo 2025 レノボのファンレス常温水冷サーバーって? 第6世代のLenovo Neptune液体冷却が AI 時代を牽引(Lenovoサイト) 【AI電力消費40%削減事例も】レノボの「直接水冷」Lenovo Neptune™(YouTube) お問い合わせ エヌアイシー・パートナーズ株式会社E-mail:voice_partners@niandc.co.jp   .bigger { font-size: larger; } .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; } .table { border-collapse: collapse; border-spacing: 0; width: 100%; } .td { padding: 10px; vertical-align: top; line-height: 1.5; } .tbody tr td:first-child { font-weight: bold; width: 20%; } .tbody tr td:last-child { width: 80%; } .ul { margin: 0 !important; padding: 0 0 0 20px !important; } .ol { margin: 0 !important; padding: 0 0 0 20px !important; } .tr { height: auto; } .table { margin: 0; } *, *:before, *:after { -webkit-box-sizing: inherit; box-sizing: inherit; } .html { -webkit-box-sizing: border-box; box-sizing: border-box; font-size: 62.5%; } .btn, a.btn, button.btn { font-size: 1.6rem; font-weight: 700; line-height: 1.5; position: relative; display: inline-block; padding: 1rem 4rem; cursor: pointer; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; -webkit-transition: all 0.3s; transition: all 0.3s; text-align: center; vertical-align: middle; text-decoration: none; letter-spacing: 0.1em; color: #212529; border-radius: 0.5rem; } a.btn--orange { color: #fff; background-color: #eb6100; border-bottom: 5px solid #b84c00; } a.btn--orange:hover { margin-top: 3px; color: #fff; background: #f56500; border-bottom: 2px solid #b84c00; } a.btn--shadow { -webkit-box-shadow: 0 3px 5px rgba(0, 0, 0, .3); box-shadow: 0 3px 5px rgba(0, 0, 0, .3); }

back to top