DevOpsの前にAppsInfraである

ご存知のとおり、DevOpsとは開発と運用を「上手いことやろうね」という開発手法なので、そうした手法が必要だということの裏を返せば開発と運用は良い関係でない組織が多い、という証左なんですね。

確かに、開発プロジェクトで運用までを考えて非機能要件を真面目に考えているケースってどれだけあるのかな、と天を仰ぎたくなることもなくもないですけど。

顧客によっては、非機能要件や非機能の機能仕様には全く関心がなく、機能要件や機能仕様だけしか関心がないこともありますから。まあ、そうした顧客は自分でお守りをすることをしないし、作った後の運用は運用業者に丸投げしているからかもしれませんが。

このDevOpsは割とわかりやすいのですよね。少なくとも契約が開発と維持管理で分けますので。どうして分けるかというと、開発は請負契約だったり請負契約と準委任の混合契約だったりする一方、維持管理は請け負うような性格のものではないので準委任契約（保守契約みたいな言い方もしますが）と契約自体を一緒にしないものなので。

それよりもう少しなんとかした方が良いのはAppsInfraです。Appsはアプリケーション開発でInfraはインフラストラクチャー、つまりインフラ基盤ですね。こちらの方がプロジェクトの中でのせめぎ合いが（観測範囲では）激しいです。

過去に経験した超大規模プロジェクトではそれはそれでバトルってましたから。

はたから見ていた感想ですけど、あれはインフラが「不憫だな」と思いましたもの。契約はアプリもインフラも同じようにするか、得てしてアプリを先行させます。なぜなら、インフラはアプリ要件で機能要件やキャパプラが左右されるから。

その上、アプリと同時か後からスタートするのにアプリ要件が出てこないとフェーズをexitできないという依存関係ができてしまうんですよね。まあ、だからインフラをクラウドで買って、後から気軽にスケールアウトしようと思うわけですが。

あとはせっせとアプリの非機能要件を聞き出してパラメータに落として作ってしまいたいのがインフラ屋の気持ちなんですが、アプリはアプリで顧客が決めないからと中々スペックを出さない。で、とりあえずでいいからとか、いついつまでに諸元を出さないと

「デフォルト値で構築しちゃうゾ』

とか言い合いになってアンニュイな気持ちになるわけです。

それを解決するには、アプリとかインフラとかのレイヤーで分けるプロジェクトチームの組織ではなくて、業務機能をある程度のサイズでクリップする方が良いのです。

ただ、それでは問題があるですよね。

例えば、工数的なものでは、アプリはガバッとバジェットを確保する（しやすい）のは顧客の業務要件を実現するのがアプリなので。一方、インフラは残りカスみたいなバジェットだったりするわけです。少ないインフラの工数を業務機能でクリップ単位に振り分けできるほどの単位かどうかということです。

更に言えば、技術エリアの話です。インフラシステムを作るための技術領域ってめっちゃ広いし、深いです。だから、インフラエンジニアは専門で細分化されすぎているという面もありますが。

それをアプリのメンバも含めて技術的なカバレッジができるか、と。廃れた言葉を使えばフルスタックエンジニア、みたいなもののライト版でもいいからカバーできるかどうか、と。

スクラム開発のLeSS（Large-Scale scrum in scrum）だとその辺はどうするんでしょうね。やっぱりアプリに専念して、まあアプリ基盤的なものでクラウドインフラのあたりは吸収してもらって、って感じでしょうか。

DevOpsだと開発エンジニアが維持管理エンジニアになる（残る）ケースも一般的ですから、対応する技術エリアのカバレッジは増えるにしてもAppsInfraのような畑の違う感じではないので、割とシームレスだと思うのです。モチベーションは別ですが。

AppsInfraは技術的なシームレス化とか技術の共有はムズそうですなぁ。

変革の軌跡 【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】