インフラは誰が構築するの？Software Defined時代の現場感
2026年01月05日 月曜日
CONTENTS
はじめに
三河からこんにちは。名古屋支社の北河です。
前回記事を書いたときは暑すぎ問題がありましたが、今度はすっかり寒すぎ問題が勃発しています。寒すぎといえば、インフラとアプリの関係を思い浮かべます。思い浮かびましたよね！
本当はHotな関係であるべきなんですが、なんか寒い関係になっていませんか？「あれはインフラの領域」「それはアプリの領域だよ」みたいな。
ということで、今回はインフラの構築とアプリケーションについて記事を書いてみたいと思います。
インフラを構築する
「インフラを構築する」クラウドが当たり前になった今でも、よく使う言葉だと思います。でも、この言葉を口にするとき、一体なにを「構築」しているのかイメージ出来ていますか？
クラウドの世界では、サーバをラックに並べて配線するわけではないし、クラウドコンソールを開き、マウスでポチポチして作るわけでもない。
むしろ最近では、Terraform や CloudFormation のように、コードで環境を定義(IaC)して作るのが一般的になっています。
つまり、インフラを「構築する」と言いながら、実は「ソフトウェアを開発する」ことに近づいているなーと感じています。
ということで、本稿ではその変化を「誰が構築するのか？」という観点から少し掘り下げてみたいと思います。
インフラという言葉の変化
まず、インフラという言葉を少し掘り下げてみます。
クラウド以前やオンプレのインフラは、まさしく物理そのものです。
ハードウェアを調達し、ネットワークを設計し、電源容量やラック位置まで気にしながら構築する。
導入までには長いリードタイムがあり、一度設置したら簡単には変えられません。
だからこそ、最初にすべてを設計し、変更は極力避ける、所謂ウォーターフォール型の進め方がごく自然でした。
要するに、「一発で成功させる前提」の世界です。
ミスったらすぐにやり直せないもん。だからこそ設計段階できっちり詰める必要があります。
なので構築といえば、慎重さそのものを意味していたかなーと思います。
そして、ここは今も変わらず重要だと思います。クラウドも、その裏側では大量のサーバやネットワーク機器が物理的に正しくつながっているからです。
IIJ もそういった物理レイヤをもちろんやっていて、そのおかげで私たちは「クラウド」「IaC」「アプリ開発」を当たり前して扱えています。
このブログは、その物理レイヤを軽視する話ではなく、その一段上のレイヤの話だと思って読んでいただけると嬉しいです。
さて話を戻し、仮想化やクラウドが普及すると状況が変わり、環境はAPIやコードで再現でき、瞬時につくり直せるようになりました。
Software Defined Infrastructure (SDI) という言葉が登場し、「物理を組む」 から「定義して展開する」 へと、構築の性質が大きく変化したと思います。
こうなると、「最初にきっちり決めてから構築」ではなく、「必要に応じて構築する」ほうが自然です。
つまり、インフラもアプリと同じように試行錯誤しながら進化させる対象になったと感じました。
それでも現場では分かれている
とはいえ、現場を見てみると、インフラとアプリが別チームで進むケースは多いと思います。
ベンダーが異なり、契約も発注も別。責任を明確にするという点では合理的ですが、スピードが求められる領域では「うーん、ちょっとなぁ…」と感じてしまうこともあります。
クラウドであれば「瞬時に環境を作れる」はずなのに、実際には設計、構築、引き渡し、といった工程が組織的に存在し、工程間の往復がリードタイムを押し上げてしまうこともあります。
もちろん、この構造自体を否定するつもりはなく、安全性・責任分界・リスク分散など、分けることで守られている側面があることももちろん理解しています。
ただ、技術的な速度と組織の速度がずれているという現実は、多くのチームで感じられるところではないでしょうか。
開発の進め方が体制を決めている
インフラとアプリが分かれている理由のひとつは、技術だけではなく開発の進め方にもあると思っています。
ウォーターフォール型の開発では、最初に要件・設計を固めて進めます。
インフラもその段階で決まり、構築が完了してからアプリ開発が始まる、そんな順序が一般的です。物理インフラの制約を考えれば、それは当然の流れかなーと思います。
一方、アジャイル開発のように「小さく作って改善する」進め方では、環境も同じリズムで変えていく必要があると思います。
アプリを改善するたびに、環境側も変化を許容する…、このときインフラとアプリが別チームだと、リズムのズレがそのままボトルネックになるのは、あるあるの話です。
「どう開発を進めるか」が「どうチームを分けるか」を決めているとも読み取れます。
アジャイル開発が増えてきた今、進め方に合わせて体制を柔軟に組み直す時代に入っているのだと思います。
ここまで読んで、「それってDevOpsの話では？」と思われた方もいるかもしれませんが、確かに開発と運用の壁をなくし、協調して進めるという意味では同じ方向かなーと思います。
しかし、今回の話は「文化としてのDevOps」ではなく、インフラ構築の性質が変わった結果として、自然とDevOps的になっているという見方に近いと思っています。
物理インフラでは、開発と運用を分けざるを得なかった。でも、Software Defined な時代では、分ける理由がどんどん薄れている。
つまり、意識して「DevOpsを導入する」のではなく、「インフラの変化に合わせたらDevOps的になった」という流れです。
名古屋支社 技術4課での取り組み
では「お前たちのところはどうなんだい！」と感じた方もいるかと思いますが、私たちの組織(名古屋支社 技術4課)では、インフラとアプリを分けず、同じチームの中で扱う形を取っています。
(※ 誤解があるといけないので補足しますが、これはIIJ全体や名古屋支社全体の話ではなく、あくまでも私たちの組織での話となります)
私たちはアジャイル開発を主戦場としており、環境構築もアプリ修正も、同じスプリントの中で進めています。
つまり「環境を作る」も「アプリを改善する」も同じリズムで進めています。
このやり方が唯一の正解だとは思っていませんが、リリース速度や待ち時間、チーム全体の理解は、分業していたころと比べると随分良くなった、といった実感はあります！
おわりに
いかがだったでしょうか？
「インフラを構築する」という言葉の意味は、時代とともに変わりました。
物理を積み上げていた頃は「設計して固める」ことが構築、クラウド時代は「定義して繰り返す」ことが構築なのでは思います。
分ける・分けないの話は、どちらが正しいかという話ではないと思っていますが、技術が変われば前提も変わります。
だからこそ、「今のやり方が今の技術に合っているか？」の観点で定期的に見直すことが必要だと思います。
最後に宣伝です。私が所属するIIJ 名古屋支社の開発チームは、開発ベンダーでありながらアジャイルでお客様のビジネス拡大に貢献したい！と日々取り組んでいます。
アジャイルの実践や今回のアクティビティのリアルな話、もっと聞いてみたい方は、個人やIIJのXでも大歓迎です。ぜひ気軽にご連絡ください！
| 執筆者X | @nk_tamago ※意見は個人のものです |
