2017年07月

14

クラウドとデザイン思考 Vol.1 ~そもそも最近よく聞くデザイン思考って何?~

最近「デザイン思考」という言葉をよく聞くようになってきました。IBM社が大量のデザイナーを採用していると話題となっています。そんな中、そろそろ「デザイン思考」って何?自社も取り組むべきなの?と、疑問に思っている方も多いのではないでしょうか。

Wikipedia によると「デザイン思考」とは、

” デザイン思考(でざいんしこう、英: Design thinking)とは、デザイナーが
デザインを行う過程で用いる特有の認知的活動を指す言葉である。”

とのことですが、正直いいまして、私には全く理解できませんでした。

もう少しわかりやすい定義はないかと探してみますと、イノベーション創出サービスを提供する btrax の記事によると、

” 全てを “Why” から始め、最終的にイノベーションを創り出すプロセス”
出展: btrax, 「【やっぱりよくわからない】デザイン思考ってなに?

とあり、問いを元にイノベーションを創出するための過程とのことで、おぼろげにその概要が見えてきました。

しかし、これでもデザイン思考とは何なのかを理解するにはなかなか難しいと感じました。
そこで、最近よく聞くこの「デザイン思考」について書いてみたいと思います。

 

ユーザー中心の思考法からイノベーションを生み出す

 

思考法としての起源は1960年代後半にさかのぼるようです。ビジネスへの応用は、スタンフォード大学で、後に IDEO を創業するデビッド・ケリーによって開始されたと言われています。 ※ IDEO :カリフォルニア州パロアルトに本拠を置くデザインコンサルタント会社

デザイン思考の「デザイン」とは、いわゆる、デザイナーが絵を描いたり、色を塗ったりすることではありません。デザインには、「新しい機会を見つける為の問題解決プロセス」という定義もあり、デザイン思考においては、この意味になります。

デザイン思考のビジネス応用の研究をスタートさせたスタンフォード大学には d.school という学科横断型のプログラムがあります。機械工学、コンピュータサイエンス、ビジネス、法律、文学など様々な学部学科から学生や教職員が集結、デザイン思考を学びながら、分野を越えてイノベーションを生み出していく力を身につけています。

その d.School 発行のデザインガイドによるとデザイン思考には、5つのステップがあります。

DesignThinkingProcessImage_600px

デザイン思考、人間中心の協調的問題解決アプローチ

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 上で、デザイン思考を活用し、イノベーションを実現する、これらは非常に相性の良い組み合わせかと容易に想像できます。

 

今後もデザイン思考の取り組みにも注目していただければ幸いです。次回は「デザイン思考導入を阻むもの」について考えてみたいと思います。

 

その他の記事

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); }

2025年10月22日

今こそ着手すべきセキュリティ対策:サイバーレジリエンス法(CRA)とSBOMの関係

公開日:2025-10-22 目次 はじめに:CRAとSBOMがもたらす変革 CRAが企業に課す義務とタイムライン SBOMの必要性・重要性:CRA対応を超えて CRAとSBOMの具体的な関係 SBOM生成・活用ツールのご紹介 まとめ:SBOMはCRA準拠と持続的な品質維持の鍵 お問い合わせ はじめに:CRAとSBOMがもたらす変革 「サイバーレジリエンス法(CRA)」は、EU市場で流通する「デジタル要素を持つ製品」(ハードウェア、ソフトウェア、IoTデバイスなど)のセキュリティ水準向上を目指し、EUが策定した新たな規制です。この法規制への対応において、中核的な役割を果たすのが「SBOM(Software Bill of Materials:ソフトウェア部品表)」です。 SBOMは、CRA対応に不可欠な構成要素であると同時に、本来ソフトウェアの脆弱性管理やセキュリティ維持を実現するための根本的な情報基盤です。CRAの有無にかかわらず、自社製品の安全性と品質管理の観点から、その導入は急務と言えます。 本記事では、CRA対応に求められるSBOMの具体的な要件と、それが企業のセキュリティにもたらす本質的な貢献についてご説明いたします。 CRAが企業に課す義務とタイムライン CRAは、製品開発の設計段階(Secure by Design)からのセキュリティ考慮を徹底し、製品提供後の脆弱性管理までを一連の義務として企業に課します。主な要件は以下のとおりです。 Secure by Designの文書化:設計段階でセキュリティを考慮した証拠を文書として整備し、補完すること。 脆弱性の特定と報告:製品に含まれる脆弱性を特定・文書化し、迅速に公開する義務。 SBOMの整備:製品構成を「一般的な形式で機械可読」な形で作成し、技術文書の一部とすること。 特に日本企業が留意すべき適用スケジュールは以下の通りです。 日付 義務内容 内容 2026年9月11日 脆弱性およびインシデントの報告義務の適用開始 悪用された脆弱性やセキュリティインシデントについて、EU内の当局へ24時間以内に報告することが求められます。 2027年12月11日 CRA全面施行、CEマーク非取得製品の販売禁止 この日以降、CRAの全要件を満たしCEマークを取得しない製品は、EU市場での販売が原則として禁止されます。 SBOMの必要性・重要性:CRA対応を超えて SBOMは、ソフトウェアに含まれるすべてのコンポーネントや依存関係を網羅的に記録し、脆弱性発生時の迅速な影響範囲の特定と市場対応を可能にするリストです。 2021年12月のLog4j問題*1が示したように、SBOMの有無は企業の対応速度を決定づけます。SBOMが整備されていれば、脆弱性の影響範囲を素早く特定し、迅速な対応が可能となります。逆にSBOMがなければ、企業は重大な潜在的脆弱性を抱えた製品を市場に出し続け、ユーザーのセキュリティリスクを増大させることになります。 このように、CRAの法的要求以前に、SBOMは製品構造を把握し、リスクを継続的に管理するための不可欠なツールです。 *1.脆弱性の重大度を示すCVSSスコアが10点中10点であった、極めて重大な脆弱性。 CRAとSBOMの具体的な関係 CRAは、SBOMを技術文書の一部として位置づけ、「製品の最上位レベルの依存関係を網羅し、一般的に使用される機械可読な形式で作成すること」を義務付けています(附属書I、Part II (1))。 脆弱性への迅速な対応の根幹 SBOMがなければ、製品に含まれるオープンソースの脆弱性情報を把握できず、CRAが求める迅速な脆弱性公開と対応(ユーザーやWebサイトでの情報提供)は実現困難です。CRAが求める「脆弱性を速やかに提出せよ」という要求に応えるための基盤情報こそがSBOMです。 技術文書としての準拠証明 CRAでは、市場監査当局から要請があった場合、製品が要求事項に準拠していることを証明するための情報・文書の提供が義務付けられています。SBOMは、「Secure by Design」の設計思想と継続的な脆弱性管理が実施されていることの客観的な証拠として、極めて重要な役割を果たします。 SBOMは、ソフトウェアの構造把握による脆弱性管理という主目的とともに、CRA準拠を達成するための重要な鍵となります。 SBOM生成・活用ツールのご紹介 CRA準拠のためには、製品の提供形態や開発プロセスに応じ、適切なツールを利用してSBOMを効率的かつ正確に生成・管理する必要があります。 ソースコードを所持している場合:SCA(ソフトウェア・コンポジション解析) オープンソース活用が不可欠なソフトウェア開発では、使用しているライブラリと、それに内在する脆弱性を把握するために、「SCA(Software Composition Analysis/ソフトウェア・コンポジション解析)」が必要です。 ソリューション:HCL AppScan on Cloud の SCA 機能 HCL AppScan on Cloud の SCA 機能は、ソースコード内の依存関係ファイルを解析し、ソフトウェア内のOSSコンポーネントを検出、脆弱性を持つものを特定します。 OSS情報の検出と脆弱性特定:ソースコードからOSS情報を検出し、脆弱性を持つコンポーネントを特定します。 業界標準フォーマット対応:SBOM出力の業界標準の一つであるSPDX 2.3フォーマットに対応。これはCRAが要求する「一般的に使用され、機械可読な形式」でのSBOM作成に貢献します。 バイナリデータからSBOMを生成する場合 組み込みソフトウェアやファームウェア、あるいはサプライヤーから受け取ったソースコードがない(またはアクセスできない)バイナリデータのセキュリティを検証したい場合に有効なのが、バイナリ解析ツールです。 ソリューション:SBOMスキャナ サイエンスパーク社の「SBOMスキャナ」は、以下のユニークな特色を持ちます。 バイナリデータからのSBOM生成: PCアプリケーションやWebサイトだけでなく、監視カメラ、ネットワーク機器、IoTデバイスなどの組み込みソフトウェアのバイナリデータからも、簡単にSBOMを生成します。 脆弱性レポートの生成:生成したSBOM情報(OSSのベンダー、プロダクト、バージョン)とCVE(Common Vulnerabilities and Exposures:脆弱性に付与される識別番号)を突き合わせ、脆弱性レポートを迅速に生成します。 オフライン対応:オフライン環境での利用が可能であり、機密性の高い環境でも安心して利用できます。 まとめ:SBOMはCRA準拠と持続的な品質維持の鍵 CRAの適用期限が目前に迫る今、SBOMによる効率的な脆弱性管理が、CRA準拠を成功させる鍵です。 SBOMは単なる法対応のための手段ではなく、企業が持続的にソフトウェアの品質を維持し、安全な製品を市場に提供するための基本情報基盤です。 法施行に向けたタイムラインを強く意識し、本記事で紹介したような適切なツールを活用して、迅速にSBOMの整備に着手することが、企業の競争力維持に不可欠です。 ご紹介したソリューション 【HCL AppScan on Cloud】 HCL AppScan(エヌアイシー・パートナーズ株式会社 サイト (AppScan 全般)) HCL AppScan on Cloud(HCLSoftware サイト(開発元)) ※HCL AppScan on Cloud の SCA 機能は、HCL AppScan on Cloudのオプションです。 【SBOMスキャナ】 SBOMスキャナ(エヌアイシー・パートナーズ株式会社 サイト) SBOMスキャナ(株式会社サイエンスパーク サイト(開発元)) お問い合わせ 上記製品についてのお問い合わせ、ご説明のご依頼、お見積り依頼など、エヌアイシー・パートナーズまでご相談ください。 エヌアイシー・パートナーズ株式会社技術企画本部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); }

2025年10月10日

現地からお届け!【参加レポート】IBM TechXchange 2025 Orlando

公開日:2025-10-10 こんにちは。 現在エヌアイシー・パートナーズ 技術企画本部のメンバーで、アメリカのオーランドで開催されている「IBM TechXchange 2025」に参加しています。 (現地時間:2025年10月9日、日本時間:2025年10月10日時点) 本記事では 現地からの速報 として、このイベントの概要や見どころ、最新情報をお伝えいたします。 目次 イベント概要 IBM Techxchange 2025 主要メッセージ - 1. Anthropicとのパートナーシップ発表 - 2. コード開発AI Agent「Project Bob」 - 3. AI基盤のための「Project Infragraph」 AI Accelerator “Spyre” Observability さいごに お問い合わせ イベント概要 IBM TechXchange は世界各国のIBMファンが集う年に1度の技術者向けイベントで、今年は3回目となりました。 年々規模も参加者も拡大しており、IBM TechXchange 2025 では、1,800以上の技術者向けセッションがあり、その中で400以上のハンズオンラボやデモが展開されています。 今年はアメリカのフロリダ州にあるオーランドの Orange Country Convention Center にて10月6日から10月9日の4日間で開催中で、日本から100名近くの方々が参加しています。 今年のテーマは「we are GO / Explore Build Launch 」です。 IBM Techxchange 2025 主要メッセージ TechXchange 2025の基調講演では、AIエージェントを活用・展開するために必要となる4つの要素を紹介していました。 この4つの要素のうちEcosystem・Developer Tools・AI infrastructure managementについてお伝えします。 Ecosystem IBMが単独でAIエージェントを開発・展開するのではなくパートナーシップやIBMパートナーがAIエージェントを開発・運用することでOpenな展開をしていくという方針となります。 この方針を実現するためにAgent Connectプログラムを展開しており、多数のAIエージェントを早期に提供することを目指しています。 Developer Tools Developer Toolsとしてドメインエージェントの提供があります。 ドメインエージェントとは、業務特化型のエージェントを指します。例えば購買業務に特化したエージェントであったり、人事業務に特化したエージェントです。 AI infrastructure management AIを利用する上で必要となる基盤の管理を指します。これを実現するためにProject “Infragraph” というプロジェクトでソリューション提供を目指しています。   他にも、TechXchangeでは様々な新しい発表がありました。その発表の中から今後大注目となる3点について共有します。 1.  Anthropicとのパートナーシップ発表 既に日本でもニュースとなっているので認識されている方も多いと思いますが、Anthropicとのパートナーシップの発表がありました。 IBMはAIのガバナンス、セキュリティ、オブザーバビリティ分野でソリューションを提供しており、これがIBMの強みとなっています。Anthropicとの協業は、この強みを背景とした補完的なパートナーシップであると思われます。 このパートナーシップの目的は、LLMであるClaudeをIBMソリューションに組み込むことだけではありません。企業ユースでAIエージェントを開発・運用する時に検討が必要となる要素を体系化した「Architecting secure enterprise AI agents with MCP」をIBMが作成し、Anthropicがそれを検証する協業も行っています。 このガイドを参照してAIエージェントを開発することで、今後拡大が見込まれるAIエージェントを安全かつ安心して活用できるベースとすることができます。 2.  コード開発AI Agent「Project Bob」 統合開発環境(IDE)をエージェント型で提供する「Project Bob」が発表されました。 このニュースと共にかわいらしいマスコットのBobもお披露目になりました。 Project Bobを利用することで、コードをバージョンアップするための設計、テストの自動化、本番運用、コンプライアンス維持と開発のライフサイクル全体をAIエージェントを用いて自動化することができます。 Project Bobは、発表と共にPublicプレビュー段階に入りました。 開発者のワークフロー負荷を軽減してくれるProject Bob の提供開始が楽しみですね! 3.  AI基盤のための「Project Infragraph」 HashiCorpが主体となって開発している基盤自動化のためのプロジェクトです。 詳細は不明ですが、以下の実現を目指しています。 サイロを横断した統合インサイト クラウドインフラストラクチャーリソースを単一のビューで把握できます。 実用的なインテリジェンス コストの最適化、ガバナンスの強化、リスクの軽減に役立つコンテキストを提供します。 自動化の基盤 インフラストラクチャークラウド全体にわたる、次世代のインテリジェントなAI駆動型運用を実現します。 AI Accelerator “Spyre” IBM Spyre Accelerator はエンタープライズワークフロー向けのAIソリューションを提供し、AIサービスを簡単にインストール・構成・移動できる統合された推論プラットフォームとアクセラレートされたインフラストラクチャーを備えています。 Spyreのユースケースとしては、IT運用、開発、ERP、銀行・金融、ヘルスケア、保険、公共分野など、様々な業界でデジタルアシスタント、データ・コンテンツ管理、ディーププロセス統合などのプリビルドAIサービスを提供します。 Observability AI Firstとして各種機能提供、Intelligent、Integrated experienceとしてUIやDataレイヤーの統合がされるという情報が共有されました。 またAIキーワードとしてはLLMやAIのワークロードをInstanaでObservabilityする機能が2025 4Qのロードマップとして示されました。 さいごに 2日目の夜のお楽しみとして「Evening Entertainment at Universal Orlando Resorts Islands of Adventure」が開催されました。 世界各国から集まった技術者とともに過ごした Universal Orlando Resorts Islands of Adventure での一夜は格別な体験となりました。 さて、本日、来年のTechXchangeがアメリカ ジョージア州の「アトランタ」で開催されることが正式に発表されました。 次回のイベントにも期待が高まります! お問い合わせ エヌアイシー・パートナーズ株式会社 技術企画本部 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