SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

トップエスイーからのアウトカム ~ ソフトウェア工学の現場から

コードとしてITインフラを定義する――自動化を超えた継続的改善の実現とは

トップエスイーからのアウトカム ~ ソフトウェア工学の現場から 第13回

  • X ポスト
  • このエントリーをはてなブックマークに追加

 社会人エンジニア向けの教育プログラム「トップエスイー」から、エンジニアの皆さんに対して有用な情報をお届けするコーナーです。ITインフラの分野では長らく装置産業的なアプローチが主流でした。いわゆる物理的なモノであるハードウェアを対象として、それを人がコントロールしていく考え方です。しかし、ソフトウェアの活用領域が広がるに従い、ITインフラの分野にも大きな変化が訪れています。その代表例が「コードによってITインフラを制御する」という考え方です。これはスクリプトやツールによる自動化と混同されがちですが、ここには埋めがたい差が存在しています。その差とはシステムに存在する「不確実性」との向き合い方です。ここでは、ITインフラにおいてこの不確実性をどのように対処していくのかを紹介していきます。

  • X ポスト
  • このエントリーをはてなブックマークに追加

ハードウェアとソフトウェア

 従来のシステムはソフトウェアとハードウェアの両輪によって支えられ、私たちにさまざまな恩恵をもたらしてきました。ここで同じ「システム」という領域に分類されるソフトウェアとハードウェアですが、それぞれがどのようにシステムを構築し維持していくかといったアプローチは大きく異なっていました。

 ソフトウェア開発にはトップエスイーが主眼とするソフトウェア工学のアプローチが取られました。ここではソフトウェア開発のためにさまざまな開発方法やプロセスの管理手法が考案され、それが実践され、効果の検証が繰り返し行われて発展してきました。一方で、ハードウェアが属するいわゆるITインフラの分野はソフトウェア工学のアプローチではなく、第二次産業的な装置産業を色濃く受け継ぎ発展してきた経緯があります。すなわち、サーバーやネットワーク機器といった装置や設備があり、それをいかに人が効率的かつ正確にコントロールするかといった考え方です。

図1 ソフトウェアとハードウェアの成り立ちの違い
図1 ソフトウェアとハードウェアの成り立ちの違い

 ハードウェアとソフトウェアは同じシステムに属しつつも、その対象も設計、構築、テストの手法も全く異なるため、長らく「ハードとソフトは別物」という考え方が支配的でした。しかし、新しい技術や新しいプラットフォームが登場したことで、この状態が大きく変わりつつあります。その代表例として、プログラムのコードとしてITインフラを管理する「Infrastructure as Code」(以下IaC)があります。IaCの登場で、ITインフラに関わるさまざまな作業が「人による機械の操作」ではなく「プログラムのコードを書く」という行為に変わっていきます。

自動化を超えた先に

 IaCではITインフラに関わる操作を全てプログラムやソフトウェアのDSL(ドメイン特化言語:特定の世界でのニーズに応じた言語)として定義して管理します。これは一見すると、以前からあったオペレーションの自動化と同じに見えるかもしれません。スクリプトやマクロ、時には専用のツールを使って手順書の一部を自動化していくことで工数の削減や品質の向上、作業スピードのアップを狙うアプローチです。もちろんIaCのアプローチは、こういった実作業の効率化も含まれていますが、それはIaCの一部でしかありません。

 ではIaCの本質とは何でしょうか。それは「ソフトウェアで培われ洗練されたノウハウをITインフラへ適用する」ことです。これは言い換えるならば、装置産業的なアプローチであったITインフラをソフトウェア工学のアプローチへと変えていくための考え方になります。

 それではITインフラがソフトウェア工学的なアプローチに変わっていくことで、どのようなメリットがあるのでしょうか。システム開発では、「不確実性」に対処することを可能にするために、アジャイルやDevOps等に代表される手法が開発されてきました。これらの手法をITインフラの管理にも応用します。

 以前から行われてきた開発手法であるウォーターフォールでは、計画を重視し、入念に検討を行い計画段階で不確実性を排除していくアプローチでした。これは考慮できる不確実性が小さければうまく機能しました。しかしシステムの適用範囲が広がった現代においては、今まで経験したことがない未知の領域でのソフトウェア開発も増えています。さらにシステムの適用範囲の広がりは、取り巻く環境や情勢の変化にシステムが影響を受けやすくなることを意味します。つまり、システムに対して影響を及ぼす不確実性が従来よりも大きくなっていると言えます。

 これらの不確実性に対処し、システムをより良いものであるように構築、運用していくための手法がIaCです。これはオペレーションの自動化とは一線を画す部分なので注意が必要です。

 では、アジャイルやDevOpsの考え方をITインフラへ持ち込んだことで実現されたIaCとは具体的にどのようなものであるか見ていきましょう。

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
不確実性への対処:計画主導と検証主導

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
トップエスイーからのアウトカム ~ ソフトウェア工学の現場から連載記事一覧

もっと読む

この記事の著者

中島 倫明(レッドハット株式会社)(ナカジマ トモアキ)

@irix_jp(Twitter)  国内SIerを経て、現在はレッドハットへ勤務。戦略から実装まで、幅広く企業システムの自動化やクラウド化の促進を支援。その傍らで大学や研究機関での講師を勤め、クラウド時代のIT人材の育成に尽力する。OpenStackやAnsibleなどのユーザー会のメンバー...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11152 2018/10/26 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング