Watson をきっかけに、最新のクラウド技術やAIのことをあちこち渉猟しているうちに、今思っていることをつらつらと書いてみたくなりました。

情報システムを「クラウドネイティブのアーキテクチャー」に一新したり、「AI的なITシステム」を導入するためには、自社内にITエンジニアを永続的に「社員として」抱えることが必須となる。

でも、こうした「アーキテクチャーを変える」を決断するのは、関ヶ原の戦を前にして西軍につくか東軍につくかを決めるぐらい重いことかもしれない。いや、「タネガシマ」と呼ばれた鉄砲を堺の商人から買って主力として使うかどうかを決めることぐらいの嗅覚と決断力かもしれないのです。

ただ言えるのは、「変化すること」と「変化しないこと」と、「生き残れること」と「生き残れないこと」とは、別に相関はしないのです。そこには確率があるだけなのです。きっと「自ら決める者だけが、時代とともに生きている感覚を持てる」というだけなんだと思う。

＊

自社内にエンジニアを採用する。というこの状況は、一見、1980年代（昭和50年代から60年代にかけて）の大手企業における「システム総合職」と似ているかもしれない。でもその後、システム開発そのものや、日々の運用までも外注化され、企業内の情報システム部門の社内SEは非エンジニア化していきました。でも、ここにきて「クラウドネイティブ」＆「AI（データサイエンス）」なITシステムへの移行が潮流となる中、いち早くそれに身を投じて「勝っている会社」は自社に優秀なエンジニアを社員として抱えています。

例えば、メルカリは2018年10月9日の記事で、こんなことを話しています。

メルカリは現在300人程度の開発者を1000人規模にする目標を掲げており、それに合わせてパフォーマンスを発揮させるためにマイクロサービスアーキテクチャを1年前から採用し始めました。

開発者のパフォーマンスを発揮してもらう。つまり、ITエンジニアに「その会社のITシステムを担いたい」と思われるかどうかが、優秀なエンジニアを吸い寄せる鍵となるんです。きっと。

では、エンジニアが燃える（萌える）のってどんな状況でしょう。

それはエンジニアでなくても働く人の立場として、ゾクゾクする状況がそこにあるか。ということだと思います。そこで一番のベースになるのは、その企業が掲げるミッション（社会における使命）に共感できることが前提ですね。

その上で、

●自分たちの周りをとりまく状況の認識がリーダーや指揮官と共有されている
●ミッションクリティカル（任務や業務の遂行に必要不可欠な要素）がリーダーと共有されている
●オーナシップ（自ら責任を持って決断）が発揮できる範囲と状況が保証されている

ということではないでしょうか。

これまでを振り返ると、1990年代にバブルがはじけても、企業にはシステム化を待っている社内業務があちこちにあって、外部の力を借りなければとてもシステム開発を成し遂げることができませんでした。そこには大きなお金が動いていましたし、ハードウエアの導入やソフトウエアの開発を専門とするコンピュータ企業の営業やエンジニアの人たちは、最先端の技術を纏った、まさに「ITのプロ」という感じで、みなさんとてもカッコよかった。

なので、日本でのITエンジニアの就職先といえば、「ITベンダー」と呼ばれる「IT専門技術者集団」企業が主流となり、一般企業の社内SEは、エンジニアというよりも企画したり社内調整したり予算管理したりと、どちらかというと「政治的」な技量へとシフトしてしまいました。

そうした日本での状況は、このグラフが示す通り「自社開発（自社内エンジニアが自らシステム開発する）」という割合が減る一方となりました。

デジタルトランスフォーメーションD X レポート2 中間取りまとめ(概要)
令和2年（2020年）12月28日 
経済産業省　デジタルトランスフォーメーションの加速に向けた研究会　より
（資料PDF）
https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation_kasoku/pdf/20201228_2.pdf

この圧倒的な割合を占める「受注」を請け負うITベンダーのSE（システムエンジニア）のミッションは「受注先のシステム開発」です。なので、客先での開発を終えて「カタをつける」と、次のミッションに向かってさっさとその場を去っていきます。基本はノマド（遊牧民）なのです。（あー、行かないで〜。と何度思ったことか）そして、もう一方の「発注元」の社内SEは、企業に定住する人として「開発後のシステムの面倒」を永遠にみなくてはいけない。

さらに一旦、一通りの社内業務のシステム化が完了してしまったあとは、情報システム部門の案件は、OSのバージョン切れへの対応を含む「数年振りのシステム再構築」ということが多くなり、その開発作業も外部のベンダーに委託しました（委託することしかできない）ので、ITエンジニアにとっての「エンジニア魂が燃える（萌える）」働き場は、一般企業にもITベンダーにも「どこにもない」状況になってしまいました。

その上、ITシステムを外部に丸投げしているうちに、企業自身も「もともとの大切なこと」や「その在り処」がよくわからないという状況が生まれ、そのために、ITシステムは自社の事業運営の要（かなめ）の事であるのにかかわらず、肝心なところで自発的にメリハリのあるオーダーができなくなってしまったのです。

かわいそうな「情報システム」。

そんな状況が危惧される中、政府までもDXを掲げるようになった背景の一つには「クラウドネイティブ」と「AI」というキーワードが最近特に浮上してきたことがあるようです。

「クラウドをネイティブとするアーキテクチャー」というのは、「クラウド」の出現とともに誕生した「構築様式」です。「クラウド」という基盤が宿命的に持つ特性を、克服すると同時に最大限に活かした「クラウドネイティブ」なコンピュータシステムは、スタンフォード大学の博士課程にいた二人の学生が生み出した種を、Googleが苗代のように育ててきた過程で形作られ洗練されてきました。

それは、ふわふわした雲のような世界の中に、微かな兆しの芽生えを見出した『古事記』の最初のような感じで誕生したのです。

次に国稚（くにわか）く浮（うか）べる脂（あぶら）のごとくして、久羅下那州多陀用弊流（くらげなすただよへる）之時（とき）に、葦牙（あしかび）の如（ごと）く萌（も）え騰（あが）る物（もの）に因（より）て成（な）る神の名は、宇摩志阿斯訶備比古遅神（うましあしかびひこぢのかみ）。次に天之常立神（あめのとこたちのかみ）。此の二柱の神も、並独神（なみひとりがみ）と成り坐して、身（み）を隠（かくしき）。
【古事記　天地初発】より

インターネットがまだ若った1996年に、萌えるように誕生してITネットワークの広がりとともに成長したGoogle は「検索」という方法を体現しました。すでにあった Yahoo にも検索がありましたが、Yahooはお金を払わなくては検索されることがなかったので、テキストだけをもとに検索される Google の「ニュートラルさ」には清々しい感動がありました。それはまるで東大寺の三月堂にある「不空羂索観音（ふくうけんじゃくかんのん）」のように言葉を掬い上げていたのです。
＊不空羂索観音：心念不空の索をもってあらゆる衆生をもれなく救済する観音

そのGoogle は世界中のあらゆるWebサイトの検索を担うにあたって、当初から、高価な高可用性ハードウェアに投資するのではなく、低コストの汎用サーバーによるデータセンター能力の構築を意図していました。

「クラウドネイティブ」というアーキテクチャー（構築様式）は、
　①比較的安価なサーバーの集合体を使う。
　②24時間365日止めないサービスを実現する。
　③世界中のWebサイトのインデックス（検索キー）をデータベース化する。
　④高速な検索を実現する。
というミッションの元、Google が長い間培って発展進化させてきたアーキテクチャです。

そして2015年に、彼らの技術の一部を「シード技術（種となる技術）」として世に出して、オープンソースという、誰でも自由に使えて、誰でも自由に参加できる多様な技術者のコラボレーションの場を作ったのです。

そのオープンソースの名前が「Kubernetes」といいます。

うーん。読みにくい。覚えにくい。
もともとはギリシャ語なのでラテン系語的に「クベルネテス」と読みたいところです。Wikiには「クバネティス/クバネテス/クーべネティス」とあって、綴りが長いために「K8s」と略記されることもあるようです。
「操舵手 やパイロット」という意味で、サイバネティクス（人工頭脳学）の語源でもあります。この新しいアーキテクチャーにこの名前（Kubernetes）と付けたところに、開発を続けてきた人たちの深い心意気を感じます。

また、この Kubernetes をつくっているプログラム言語が「Go」という名前なので、最近本屋さんのIT関連のところに
　『プログラミング言語Go』
　『みんなのGo言語』
　『スターティングGo言語』
　『Goプログラミング実践入門 標準ライブラリでゼロからWebアプリを作る』
　『Go言語による並行処理』
とかとか並んでいるんですね。

この「クラウドネイティブ 」という新しい様式を説明するときには、これまでの「ITシステム」では聞いたことのない言葉が並びます。

例えば、「分散型」「疎結合」「クラスタ」「コンテナ」「マイクロサービス」「オーケストレーション」「デプロイ」といったキーワードです。

＜クラウドネイティブ な感じ＞
・ハードもソフトも、構成要素が「分散」していて、繋がり方が「疎結合」
・ハード故障や切断のリスクに備えてチームとしてスタンバイする「クラスタ」
・単一の機能をだけを行う小さな単位の「マイクロサービス」
・「マイクロサービス」とそれに必要な部品をセットにして格納した「コンテナ」
・「コンテナ」をコーディネイトして自動的に一つのシステムに組み上げる「オーケストレーション」
・リリース時にシステムを止めないで「デプロイ」（配布）できる

一方、これまでの（従来の）「ITシステム」のアーキテクチャを名指すために、「モノリシック」とか「オンプレミス」とかの言葉が使われるようになりました。

【モノリシック】monolithic
mono（単一な） + lith（stone:石） + -ic（のような）
直訳すると「がっしりとかたまっている」「一枚岩のような」という意味。この様子を以って、全てを同一のモジュールとして強固に作り上げられたシステムやアプリケーションを形容しています。
＊「クラウドネイティブ 」のマイクロサービスに対して、従来のアプリケーションを区別するために使われるようになった言葉です。

【オンプレミス】on-premises
on（設置された）+ premise（土地付きの施設）s（複数形）
自社施設内にハードウエア（サーバーなど）を設置して利用すること。
＊クラウド（実物を見ることができないどこかの場所にあるサーバー）が出現して、それに対して、従来のサーバーの置かれ方を区別するために使われるようになった言葉です。

＊

もう一方の新しいシステムである「AI的なITシステム」のこと。

AI的なITシステムをみるときにポイントとなるのは、

◎これまでのITシステムは「プロセス」と「データの器」を構築し、プロセスは変化しない
◎AIを使ったITシステムは「プロセス」と「データ」の合わせ技で構築され、データによってプロセスが刻々と変化していく

ですので、AI的なITシステムではインプットされる「データの質」がそのシステムそのものの質を決定していきます。

なので、最近いろんなAIに関する講座が開かれていますが、講師の方々が口を揃えて仰ることは

◎ AIにおいてデータセットの質が最も大事

ということになります。

実は、AIに学習させたり、判断をさせるためのデータセットには「タグ」や「ラベル」が必要になります。このデータの内容は「●●である」ということを示すラベルですね。

そして、その最初の最初は人が判断して、人の手で、「これは何を意味している」ということを指示・設定していかなくてはいけないのです。それも大量に。

こうしたデータセットを準備して学習させることで、AIの中に学習内容がある程度蓄積されて、そこで初めて深層学習ができるようになるのです。

そして、AIシステムは「アジャイルで開発」すべき。というのは「なかなかスケジュール通りいかない」ということが背景にありますが、この「スケジュール通りにいかない」という部分の大半が、この「データセットの質の担保」に関わっているのです。

この「データの質の担保」を実現するためには、データの内容を理解している人が、責任感をもって「ラベリング」に取り組む必要があることから、自社（の社員）で行うことが必要で、環境の変化に応じて変更やチューニングを継続的に行うために、データセットをつくるための自社内（社員による）のオペレーションの構築がもっとも重要になるんですね。

さらには、データのインプット源となるユーザーサイドのデバイス(iPhoneなどのスマホ)でのアプリケーションと連携させて、SOE（System Of Engagement）として自社事業の核にしていくためのシステム構築（ガンガン作り変える）が、競争力の源になるんです。

そんなことを知るうちに、冒頭に書いた

情報システムを「クラウドネイティブのアーキテクチャー」に一新したり、「AI的なITシステム」を導入するためには、自社内にITエンジニアを永続的に「社員として」抱えることが必須となる。

と、思うこの頃なのです。

そして、その自社の ITエンジニアたちの頭（カシラ）となるのが CTO【Chief Technology Officer】(最高技術責任者)なのですね。

アーキテクチャー【architecture】という言葉は、建築術、建築学、建築様式、建物、構造、構成とかの日本語訳が並びますが、語源的には　

　arkhi- → chief
　teks-  → 織ること、作り上げること。context、text、technologyなどの由来

で、 アーキテクト【architect】は、chief builder、principal craftsman が本来の意味で、アーキテクチャーというのは「親方（チーフ）が決める【構築様式】」のこと。

自社のITシステムのアーキテクチャーを決定することは、 CIO(最高情報責任者)とCTO(最高技術責任者)の肝心要の役割なのです。

日本では、CTOという役職名がついた人はまだほとんどいないようで、CIOですら専任として存在している企業の割合は、とても少ないのです。
これでは、次世代型とよばれる「クラウドネイティブ のシステム」への移行や、もしくは「しない」ということを、誰が腹をくくって決定して、推進できるというのでしょうか。

年度別CIO(最高情報責任者)の配置状況
(出典)「企業IT動向調査報告書2020」 一般社団法人日本システム・ユーザー協会(2020年4月)
＊経済産業省　デジタルトランスフォーメーションD X レポート2 中間取りまとめ(概要) より

CTOという役職があることを知って、実際にそういう人がいるのを初めて見たのがこの記事でした。

そして、ここのエンジニアの人たちのなんと萌えていることか。

＊

PS.
因みに、最近メルカリで売れたミルクピッチャー。近所の郵便局から埼玉の方へ、お互いに匿名で送りました。

＊