ちょっと特別編。
ちょうど3回目を書いた時に、ん？もう一つあるな、と思いついたので。
長編SoRとSoEの3回目でこんなこと書きました。
（前略）
前回申し上げたEaaSの話にまたなっちゃいますけど、社内システムから見れば、利用者は顧客なんですよ。顧客が満足しないシステム作ってるのがいわゆる社内情シスですからね？
（中略）
働き方改革が叫ばれ生産性向上が急務と言われても、実は働いてもらう環境が生産性を上げてない。
（後略）
（太字は今回改めて強調）
今所属している企業もそうなのですが、いわゆる基幹系と呼ばれるシステムって「お客様」が管理する側なので使いにくいシステムが仕上がります。最近はもっと悪い方にシフトしているような。
ただ、ここまで書いておきながら悲観していません。
いわゆる社内情シスが「お客様」を見るという意識になってきているのは肌感でわかります。
ただ、本当のお客様はユーザーであり、SoRで記録する側ではないはずなのです。
いわゆる社内情シスが「お客様のために」より効率を、より効果を求める姿勢は進展しつつあると思いますが、残念ながら顧客を「SoRを使う」側（SoRに使われる側ではなく）にしているため、どうやって効果効率的に記録を取るかに焦点が当たっていて、余計残念なシステムの出来上がりです。
ですが、いずれ変化します。システムは今まさに外部との競争にさらされ、本当に必要なシステムのあり方について徐々にですが舵を切っています。企業が残っていれば、ですがいずれ変化すると思っています。
それよりも。
これらシステムが乗るいわゆるインフラストラクチャ、簡単に言えば、ネットワークからハード、MW、OS層ですが、これらが本当に働いてもらう環境として生産性を上げることを意識しているかと言われると疑問が残ります。特にネットワーク。
今のネットワーク層は社内と社外を明確に区別し、守ることが至上命題になっています。
勿論、それは正しいです。ただ、それだけが正しいわけではなく、区別しつつ、必要なところと必要な時につなぐ事、それが本来のあるべき姿だと思うわけです。
先ほども申し上げた通り、「お客様」に寄り添ったシステムは積極的に社外から社内につながって来ようとしています。
また、SoEは社外の方が何かと都合が良い上に、お客様は社外にいるので自然、社外にシステムというか窓口は置かれていきます。従って、お客様と繋ぐものは外、記録するものは内、という流れができてきます。今はまさにその過渡期。余談ですが最終的には「社内」「社外」という区別のない世界になるでしょうし、していきたい。
しかし、そうなってくると困ったことになります。
今の過渡期のタイミング、社内のシステムに記録する方法が無い、または、記録する際に必ずGWを通るが故にGWの通信が逼迫する、または、記録するためには必ず人手の加工が必要になる。など。簡単に言えば、「人手を介するので調整先が増える」
本稿通じて何度も申し上げますが、エンドツーエンドのサービス、つまり、「お客様」からお客様が支払ってくださったものやお客様の情報などを記録するところまでをワンサービスと考えると今の内外を区別し、審査するインフラの考え方では絶対に自動化できず、働き方の改革なんてできないんです。
どこかでモノや情報は滞留し、どこかでバッチ処理をするか通信が破裂して全体影響が出ます。
例えば、バッチ処理は特定の時間になるまでWIPとして溜まり、かつそのデータが不良か否か（正確には欲しい情報になっているかは分からないとも言いますかね）は処理するまではわかりません。つまり、確かめる方法がない。
また、GWに流れる通信量の肥大はどのような通信をしているのかを追いかけ続けないとわかりませんが、それだけのリソースや予算はあり得ないので、破裂するまでは理解できないはずです。
実はこれらシステムやインフラが、「バッチ処理」や「とりあえず集中監視」をしている状況が効率化できない働き方の原因なんだという事を認識せねばならないと思います。
余談ですが、社内情シスとしてこの懸念を発信しておりましたが、受け入れてはもらえませんでした。致し方ないと思います。私の言い方も悪かったです。社内情シスを離れ、こういう発信手段を手に入れるまでは私もちゃんと説明できませんでしたし。もっとも、「社内」と「社外」の境界が曖昧になることは失礼ながら馬鹿でもわかる事なので、何か別の理由があるのかもしれませんが。
いずれにせよ、日本に足りていないのは、実はSRE（Site Reliability Engineering）ではなくて、今作った造語ですがSIE（Service Infrastructure Engineering）ではないかと思います。
つまり、サービスを提供する上で必要となるインフラにおいて論理的にも物理的にも全世界でエンドツーエンドで物事を見られるエンジニアです。
インフラ領域を仮想化して抽象化し、ビジネス（アプリ）に影響が出ないようにすることは非常に難しいですが、それが理想です。サービスに必要なアプリの設計に気が回っても、それがどのようにインフラに影響が出るか分からないためです。というか、わかりようがないです。論理構成図と物理構成図、さらに言えばどのような通信や処理がインフラそうで行われているかなんて可視化する仕組みないですから。
そして、仮に分かったとしても、そこを通すために調整する時間なんてビジネスサイドからすればもったいなくてやってらんない。要は、安心安全に通してくれ、それ以外求める要件なんかないのです。
ではどうするかというと、抽象化を維持するためにリアルな世界を知っているエンジニアが必要ですが……いると思います？
どのような通信、どのようなインフラが存在し、そこで何が行われているかを肌感で分かっているエンジニアです。そして、そんな彼ら彼女らはビジネス側に精通し、ビジネス側のスピードに合わせてインフラを増強し、かつ何がバズるか分かってる人。いませんよ。
わかりますか？外部から人持ってくる。運用エンジニアを外出しする。そんなやり方をしてきた結果、自社内で通用する社内SEいなくなるんです。
今までのような長い時間をかけてジェネラリストを養成するようなことをしていては間に合いません。そして、アウトソースしまくった結果、社内にいません。
システムや構成を知っていて、その上のレイヤに既存のサービスやシステムを重ねることが出来て、かつその役割を知っていて表現できて、そのさらに上に新しいサービスやシステムのトポロジを乗せて危機感に対するアンテナを張れる人材。私が知る限り、そんなのいないです。
だから抽象化し、俊敏なインフラに変える必要があるんです。さらに、サービスが立ち上がるときに肌感でこういうサービスを組むならこんな仕組みにしないと危険だぞ？と思えたり、可視化できる人材も。
もしくは、極論ですが、WANなんてものはなくしてしまえばいい。そうすれば、少なくともネットワークのインフラエンジニアは不要です。守るべきWANがないので。
こういう時、一般的なITサービスマネージャなら、「SKMSやCMSを作りましょう」となるのでしょうが。
SKMSはあくまで概念に過ぎないと思っているのでまぁ、それはおいておきましょう。
話が予想以上に長くなりましたのでちと強引にまとめますが。
働いてもらう環境、整ってますか？仕事をしたいと思っている人間が社内調整に駆け回っていませんか？
本来為すべきことを出来る環境、整えてあげてますか？
アプリ、つまりビジネスを支える直接的な物は今後もっと自動化、ローコード化が進むでしょう。そうなった時、インフラはそのカオスを支える仕組みを持たねばならない。それを人手で回すのは絶対的に不可能なのです。
人の神経回路と同程度のスピードで流れ、かつ人の脳みその容量（記憶によれば5テラ？ギガ？バイトだったような）を超えるデータを支える仕組みを人が保守運用することなんかできるわけがないのです。それは人間の限界を超えている。
人間で処理できる限界を超えたものを人手で回すことなどどう考えても不可能です。これは人手不足などという話ではありません。人の限界を超えている話なのです。
故に、インフラストラクチャは抽象化し、仮想化し、ビジネスの成功を願う者たちを影で支える黒子に徹する仕組みに変える。黒子なので、表舞台の調整ごとなんぞに出てきません。調整する時間もムダなのでムダなことをしないように変化する必要があるのです。
「仕事」を表舞台の人間にしてもらうために、調整などというその人間達の「業務」をなくして差し上げる。それこそが、社内情シスに求められる「仕事」なのだと思います。社内から調整ゴトのメールが送られてきた時点で、インフラの職責を果たしていない。そういう時代なのではないかと思います。
ちとトゲがありすぎます気もしますが、今、まさにインフラを守る方々の仕事を揶揄しているわけではありません。インフラの仕事が変わったということを申し上げたいだけです。今までのように調整ごとやCABを開く事が仕事ではないと。アプリを扱う人々に調整ごとを投げかけない環境を守る事が、インフラの仕事なのだと。そういう意味では、SREに似ていなくもないのですが。ただ、私の唱えるSIEは、それらSREが面倒見るサービスの維持というよりも、もう少し大きく、全社的な意味合いでの調整役（対人間ではなく、対システム間の調整という意味で）です。
そして、それをできていない企業のインフラは、インターネットに飲み込まれ、職場を失う。そう思います。
そして、アプリの方々にも言いたい。今、「お客様」を見たサービス設計できてますか？企業の最終目標は、決算として表現する事です。つまり、会計仕訳を施して、記録する事で、本来のサービスの成果が見えてきます。
お客様の支持を獲得しているか否かは、究極的にはこれでしか測れません。
いわゆるビッグデータや分析基盤とうたわれるようなものを作っても、所詮は数字（でデータ）遊びに過ぎず、お金がどれぐらい儲かったか。これにつきます。
したがって、全ての仕事はこの会計仕訳に向かって進んでいくはずです。裏を返せば、この方向に向かって進む限りにおいては、「調整ゴト」は全て無駄です。もっと言えば、会計仕訳を作る作業なんて無駄の極致です。（決算書を作るというお仕事を言っていません、仕訳を作る作業そのものです）
本来は、何かを売りそれが確定すれば、次の瞬間には会計仕訳として記録されてなければいけない。ムダを究極に排除するならば。
いやいや、売るだけが仕事じゃない？そうですね。でも、なにがしかの作業をして給与という対価を得ているなら、そこに人件費かかってますよね？つまり、一ヶ月に一回は会計仕訳に貴方に支払った給与は記録されるべきですし、そこにかかったコスト（光熱費やパソコンのリース料、または減価償却などなど）が乗ってくるはずです。マイナスの記録が。つまり、一般管理費が乗っかってくるということです。売上総利益（粗利）をどこまで精緻に出すかによりますが、今回たとえにあげた人件費なんてものは、月末締めの翌月払いであれば、支払い日前には確定しているはずです。一般管理費を仕入原価と雑経費と人件費と仮定すれば（そんなわけないのですが、あくまで例として）、少なくとも翌月第一営業日には確定できるはずなのです。なぜできないんでしょうか？
それが、サービスを使う目的であり、理由であると思うのです。
