FUJITSU アドベントカレンダー21日目の記事です
掲載内容は私個人の見解であり, 富士通グループを代表するものではありません。
12/19にイベント(JEITA主催)でキーノートをさせていただきました。そのスライドはこれになります。タイトルは「Cloud Native ～不確実な世界と戦う～」。
https://speakerdeck.com/hiro_kamezawa/cloudnative-bu-que-shi-nashi-jie-tozhan-u-20191219jeita
しゃべりがないとわかりにくいスライドだろうと思うのと、そもそもなんでこんなセッションをやったのか含めてちょっと書いてみようと思います。長いけどひたすらポエムなので技術的な話はありません。スライドを見ながらかスライドを見てからどうぞ。
予測不可能な世界
冒頭数枚を使って世界は予測不能だよ、という話をしています。予測することを商売にしている人には悪いですが、ニコラス・タレブの言うように「ブラックスワン＝絶対にありえないことは起こる」というのがそうだろうなと思っていますし、昨日、今日とあったことが明日も続くという保証は全くないわけです。そうすると「ありえない事への備え」「リスクヘッジ」ということが重要になる。この辺はタレブの「反脆弱性」という本がとても良いです。読んでると腹が立ってくるので大変ですが。
この本に刺激を受けたわけですが、クラウドネイティブに代表される技術や考え方・プロセスは「予測不能性」への対処能力を備えるための進化の方向性だと考えると投資する価値が説明出来るんじゃないか・・・・と思って書いてみたのが今回のスライドになります。道半ばで挫折して反脆弱性までは説明していないんですけども・・
以下、スライドの中からいくつかつまんで言いたかった事を書き出してみます。
お楽しみいただければ幸いです。
「わが社の中期計画は3カ月です。長期計画は一年です。3ヵ年？それはdreamと呼びます」
これはシリコンバレーで聞いたという話を覚えていたので書きましたが、うちの会社にいると三ヵ年や五ヵ年の計画を出せと言われるんですよね。まだ売り出してもないのにわからないよ・・・・
米国企業なんかは1年以上先の予定は教えてくれないことが結構ある印象なんですが、一年以上先はDreamだというのはそうだろうなというのと、予想はできないということを受け入れて投資や財務もアジャイルに判断が行われる会社全体のスピード感がちょっと羨ましいわけです。
※競争や変化がないところでは数年がかりのスケジュールを立ててじっくりやるのも理にはかなうと思いますが・・・
Plans are noting, Planning is everything.
好きな言葉にも挙げてますし、冒頭のスライドの中でも紹介していますがこれは米国のアイゼンハワー大統領の言葉ですね。当時の英国首相のチャーチルも似たようなことを言っていますが「戦艦や空母が想定された戦場につくまでに2カ月かかるとして、その間に状況は変わってしまう。だから、計画を立てることは重要だが、計画そのものを守る必要はない」という意味だと聞いています。計画が大事じゃないのに計画を立てるのが重要なのは計画を立てないと何を変えて何を変えないかが判断できないてことなんですよね。
計画を立てて出港するけど、状況を見て計画は変更し続けろという話になります。ここに一つ「未来の不確実性」に対処するためのヒントが隠れていますよね。ミッション＝目的達成のための計画だけど計画を主にして金科玉条のように守りだすとしんどいんですよねぇ。
計画を変えると怒る人がいたり、「約束」があるとしんどいのですがいい考え方はないですかねぇ...
機敏さを持つ
アプリケーションファースト
このデッキで一番？クラウドネイティブの話っぽいスライドですが、社内で話しててもあまり理解されてないことに「クラウドならリソースは後付け（財布があれば）」
という話があります。この話はこっちでどっぷり書いたのですが。
https://speakerdeck.com/hiro_kamezawa/kuraudoneiteibutokubernetes-daitaiatuterukuraudoneiteibu
VMっぽく使ってしまうと下のレイヤーから積み上げでしまうんですよね。リソースを調達する部分がAPIとコンテナでハックされてOpsが自動化され、結果高速化した。インフラ部分の記述可能性があがることでちょっと世界が変わったという話ですね。
この話はDevによるOpsのハックという文脈で理解しているんですが今のFaaSなんかはハック済の状態でポンと提示されるのでここから始めるとちょっとわかりずらいんですよね。
多分これからクラウドに来る人たちには常識になっちゃうからわからなくもいいのかもしれませんが。
SaaS
次のスライドでSaaSを使おうと言っていますがこれは自分達のサービス開発の中でも経験したことで、何かを作るときには設計が一番時間がかかるのですよね。注力しても儲けにならないようなところで時間を使うのも阿保らしいのでさっさとSaaSを使うって話になります。
特にアジャイルでやるときはせいぜい１チーム７－８人で全部やろうとしたら死にますからSaaSをどこで使うかは重要になります.
突然SaaSが終わったり値上げしたり思ったよりお金がかかったりすると代替案が必要になってきますけども・・
テスト戦略
この話はサイボウズさんにお邪魔したときに教えてもらったのですよね。テストの(時間的)バジェットは管理されてますかと。
うちの某基幹システムのお客さんだとレグレッションテストが３カ月分・・・とか機敏さと対局にあるような状況にあるわけです。品質はとれてるけどやってる本人達もつらいと言っている。
機敏になりたければテストにどれだけ時間をかけてよいのかはちゃんと予実化する。CICDを回すのは基本ですけどCIだって一時間もかかるようだと非常にしんどいわけです（頑張って並列化するなどする）悩ましいなと。
twadaさんの言うようにテストを減らして品質を犠牲にするのはありえないのでその辺はリスクヘッジの仕組みとのさじ加減になります。手探りなんですよね。
いつまでにお客様に届けるか、リリース時間まで含めて品質だって言ったら言い過ぎなのかわかりませんがそれくらいの意識でもいいんじゃないかと。小さく作れ、マイクロサービスなんてのはテストを小さくする効果があることは付け加えたいと思います（しゃべった時は言わなかったんだけど）
Mission Command
OODAの話…この話は実際のところこれだけで３時間くらいしゃべれるネタなのであれなんですが、上で紹介しているもう一つの資料の４章以降で少しガッツリ紹介しています。
スライドで引用している自衛隊の人の資料は良い資料だと思うのでご参考にしてください。
ちょっとだけ説明しておくと、O-O-D-Aを回してるよって話なんですが、大まかに下のような話が出てきます。
１．【早く回せ】
OODAは高速化できます。訓練で。例えば野球でワンアウト一塁でショートゴロなら２塁になげてダブルプレーを狙いますよね。この時に考えてるかっていうと、考えてないんですよね（違ったらごめんなさい）。訓練をすることで状況に対する対処が決まっていれば Orient->Decideを速くできる。訓練しようって話です。サッカーなんかでアイコンタクトが起きる状況は最高に速いですね。
２．【遅くしろ】
OODA Loopの絵をよく見ると、O->O->O->O, O->O->D->O->O->D-> というループもあることに気が付きます。つまりDecideできないからActできないのです。この効果を狙うのが例えば同時多発テロで、相手を麻痺させる戦い方の話なんですよね。
AWSなんかが山ほど機能を出してくるのはこういうところもあるんじゃないかなと思うわけです。旧来型の企業はライバルが何か出して来たらそれを分解してモノマネ製品をつくってたわけで、いくつかの日本企業の得意技でもありました。でも、半年ごとに機能がどんちゃかでてくるとそんなわけにはいかない、指をくわえて見るしかないOODA Loopの罠にはまることになります。
３．【視界を広げろ】
このOODA Loopを作ったジョン・ボイド大佐は朝鮮戦争でのロシアの戦闘機と米国の戦闘機の戦績を分析しておかしなことに気が付きました。米軍が圧倒していることがある。スペックだけみるとロシアの戦闘機のほうがいいし、米軍のパイロットのほうが圧倒的に優秀というのも考え難い。
分析の結果として、米軍の戦闘機のほうがキャノピーの視認性が良く、敵が良く見えたというというところからOODA Loopの着想があったそうです。F15なんかはそういう思想が入ってるみたいですね。
４．【ミッションを与えろ】
小さなチームでOODA Loopを回すのはいいんですが、大部隊で回すことが難しいことはすぐにわかりました。現場指揮官の現場の判断で状況を変えないといけないわけです。これをどうアラインするのかというと、各チームのリーダーを鍛え上げ、ミッションを徹底的に共有するという方針がとられました。これをミッションコマンドと呼びます。
どこかで聞いた話ですね。そう、マイクロサービスでも似たような話が出てきます。
５．【情報を共有する】
OODAの成功はクエート奪還作戦（一日でサダムフセインのイラク軍百万をクエートから追い出した作戦）で確信されたんですが、ミッションを共有するだけじゃだめなんですよね。Network Centric Warfare (ネットワーク中心の戦争）という米軍の軍装の話があるんですが、イージス艦や哨戒機を中心に情報兵装から得られた情報が瞬時に前線と共有するようになってるんだそうです。で、各部隊からの報告もリアルタイムに共有されていく。
そりゃそうですよね、ミッションを共有しても目隠し状態だと何もできません。
企業においてもこのような話はあって、OODAの話をするときはこういう話を踏まえましょうってことですね。
選択肢を持つ
この辺が「反脆弱性」ネタの一つではあるんですが書ききれなかったところでもあります。選択肢を持つことで未来に対してリスクヘッジをする、オプション性という概念の話であります。「損をしない」負のオプション性と、「宝くじが当たる」正のオプション性という話があって世の中設けてる人たちはその組み合わせで動いてるという話。
※たぶん自分でも理解しきれていないことを言っております。
オープンソース
オープンソースがオプション性を持つというのはこれは自明でいいのかなと思いますが、多数のデベロッパーが参加している特定の企業に依存しないオープンソースというのは良いオプションになります。マネージドサービスが高すぎてもOSSを使って自前で構築するオプションがとれるわけで。
アプリケーションファーストだ、SaaSだ、と前段で言っていましたがそこに対するリスクヘッジは「オープンソース」「標準化」というところで見るのがいいのじゃないかというのが私の意見です。何か見落としてる気がしないでもないですが・・・
停止コストを下げる
企業で開発をしていて一番困るのは儲からないのにつづけなきゃいけないとか、方向がずれてることがわかったのに方針転換できないとかそういう話じゃないかなと思います。たぶん、若くて勢いのある企業だとこのあたりのルールは整備されているのじゃないかと思いますが・・・
アプリケーションファーストでSaaSを使うってことをしていると停止コストは下がるんじゃないかなと（相対的に投資が減るから）。リリース単位を細かくしながらユーザにぶつけながら機能開発するというのもそうですよね。
この辺、前段のテスト戦略とも組み合わせて考えたいんですが、テストを減らす分、トラブルがあったときに取り戻す、リリースをやめる、そのために小さくリリースする手段との組み合わせかなと。逆に、停止とリリースのコストを減らさない限り、テストを減らすのは難しいんじゃないかなと思うわけです。
多様性と直観
これは、「正のオプション性」の話になります。つまり偶然良くなる・・という余地をどう残すか。
そんないい加減ことがあるかと思う人もいるかもしれませんが、進化論の肝は突然変異ですし、蟻が餌までの最短ルートを最適化する仕掛けも偶然をシステムの中に織り込んでるんですよね。
うちのチームもなんですが、チームが健全だと「ちょっとやってみたんですけど見てもらえますか」って人が出てきます。「○○さんが一晩でやってくれました」というやつですね。こういうのをうまくシステムとして取り込む余地がチームにほしいんですよね。
ちなみに私はうまくいってなくて、チームメンバーの提案に「おぉ」と思ってもその場で取り込めず、ずっとタスクの下の方に積まれつづけている「グッドアイデア」がちょこちょこあります。
チームに活性を出すにはどうすればいいんですかね。決断の問題なのかもしれませんが考え方の問題かもしれないしプロセスの問題もあるんだろなと。
予測に頼らない
予測できない世界で戦うんだから予測に頼っちゃだめだよね、という話で・・・人って信じたいものを信じちゃいますからね。余談ですがサブプライムローン問題の裏側で逆張りして大儲けした人たちの映画「マネー・ショート」はお勧めです。
ヒューマンエラーの扱い
AWSのレポートを例に挙げてますが、ヒューマンエラーだと認めた上でツールを直しているんですよね。これがベンダーのSIだったらどうなるかというと、「ツールを直します」「じゃ、バグ、瑕疵だね。損害賠償」まぁそんな感じですよね。そうするとどうなるか、「使用法誤解です」となって対処法は「二人で作業します」となっちゃうわけです。
※実際はもっと建設的な会話がされてると思いますが
ダブルチェックってやっぱりだめなやつで厚生労働省が病院向けに「ダブルチェックをやめましょう」
https://kouseikyoku.mhlw.go.jp/shikoku/kenko_fukushi/000085434.pdf
というレポートを出しているんですよね。
そもそも人がエラーする状況をハックするというのがやはりエンジニアリング的には正しいわけで、やっぱりAWSは大したもんだな～と思うわけです。
品質検証部門がヒューマンエラーを減らすものづくりみたいな観点で出荷前に検査してたりするのでうちの会社でもやってないわけじゃないんですが、出荷した後のツールを直すという意識は注意したいものです。
そもそもで言うと、弓とアーチェリー、将棋のコマとチェスのコマ、箸とフォーク・ナイフとかを考えると日本人って「うまく使えないのは修行が足りない」と言いがちなのできっちり意識した方がいいんじゃないかなと思ってます。
ブラックボックス
SaaSを使えとも言ってますが、ブラックボックスをあつかう場面が増えるんですよね。でまぁ、APIで繋ぐんですが、昔からネットワーク周りで言うこととして「入力には寛容に、出力は厳密に」ということがあります。
後、マイクロサービスに近づくと自分以外はブラックボックスなんですよね。「隣の奴が突然DOSアタッカーになった」なんて話もありますから各サービスが自分で防御する仕掛け、サーキットブレーカーとかを組み込む必要があります。
この辺、この記事なんかが好きなんですが
https://anond.hatelabo.jp/20111018190933
サービスを分割するってことはブラックボックスに囲まれるってことでもあるので扱い方は作戦を練る必要があるんじゃないかなってことですね。
終わりに
ちょっと疲れたのでこの辺で。
なんかまとまりのない話になりましたが、想いとしては最後から二枚目の「世界はハックできる」
というところをどう理解するかでcloud nativeの活用法も変わってくると思います。大事にしたいですね。
私の来年の課題としてはチームを健全に回す、お金を稼ぐってのはもちろんなんですが、オプション性をチームの活動やアーキテクチャの中にどう取り込んでいくか、それによってリスクヘッジと進化の能力をどう取り込めるのか、そのためとプロセス・システムや仕掛けは？というところを考えたいですね。
文字ばっかりで読みにくかったと思いますが、ではよいお年を。