記事要約
インフラエンジニアの仕事は業務に変化をもたらす仕事なので開発ですよ、という記事です。
開発と運用
まず、開発と運用の定義を下記のように考えたいと思います。
開発、運用という言葉の利用時にはだいたいこのような感じで認識されているかと思います。
- 開発
- 製品をつくりあげるために使用する材料や部品、その量、製造手順が不明確で、それらを明確化するプロセス。
開発と言っても純粋な開発から製造に近い開発までグラデーションがあるが、純粋な開発に近いタスクであればあるほど、結果と工数は未確定になる。 - 運用
- 定まっている製品・サービスの仕様を下に、その仕様を活用する形で製品・サービスを提供するプロセス。
製品やサービスを新たに作ることはなく、製品やサービスの仕様の変化ももたらさない。
システムを取り巻くアクター
別記事システムを取り巻く3つのアクターで使った図を少し表現を変えて再掲します。
業務をエンドユーザー業務、ITサービス提供業務、ITサービス開発業務の3つで見たときに、それぞれに開発(エンジニアリング)プロセスと、運用プロセスが存在します。
この図の中でのインフラエンジニアの立ち位置を考えてみます。
インフラエンジニアの担当範囲
一般的にシステム開発で、インフラエンジニアは下記の表の赤い部分を担当します。
エンドユーザー向け業務システムのインフラ設計や構築を担当しますし、ログ収集や監視の仕組みづくりといったITサービス提供業務の仕組みづくりもします。また、CI/CD環境の整備といった開発プロセスの仕組みづくりもします。
これらは業務に変化を起こしていく仕事なので、全て開発です。
運用を担当することもあるかもしれませんが、インフラエンジニアがITサービス提供に関わるシステム導入支援やユーザーサポート(問い合わせ対応業務)などをメインで対応することはないですし、担当するにしてもテクニカルサポートのL2〜L3の部分くらいかと思います。
SREはどうか
2010年代半ばからインフラエンジニアをSREと呼ぶ組織が多くなってきたと思います。(インフラエンジニアをSREと呼ぶべきかの議論はここではしません)
SREの視点では、主に下図の赤い部分を中心に語られることになります。
それにプラスして開発プロセスエンジニアリング部分も担当していることもあるかもしれません。
インフラエンジニアの仕事は開発であって運用ではない
ということでインフラエンジニアの仕事は開発であって運用ではありません。
「インフラエンジニアの仕事は運用」、「インフラエンジニアのコストは運用コスト」とみなすと少しおかしな議論になったり、判断を誤ったり、実態の把握を間違えるので気をつけましょう。