オランダのIT - INGグループ
最初の記事のKubernetesの事例ですが、オランダからの事例の一つにINGグループのものがあります。
銀行業界は早くからコンピュータを取り入れてきただけあって、レガシーと呼ばれるような古いシステムを抱えがちでしたし、今も抱えているところもあるでしょう。
INGグループがどのくらい早くからコンピュータを取り入れてきたかをWikipediaのINGの年表からご紹介すると、導入は1961年のようです。振替の自動化のために使用されたのはIBM-1401。1965年に自動化が完了し、従業員数を半分に削減したそうです。
給料の支払いのために現金送受用の袋を使うのではなく、磁気テープのやり取りでできるようになるのが重要なインセンティブだったのだそうです。（キャッシュレスです。オランダ最初のキャッシュレス決済システムは1917年とのこと、日本の元号は大正。第一次世界大戦中のことです。）
INGグループについては、日本語でも「ING アジャイル」で検索すると、アジャイルな組織作りの事例がヒットします。
以前書いたように、アジャイルやDevOpsの力を発揮させるためにはそれができる文化や組織に変えていくことが重要と言われます。文化に合わせて知識や技術を変えるのが和魂洋才だとしたら、それとは逆のアプローチといえるかもしれません。
ここではそちら方面ではなく、日本語でも紹介されている2017年のマッキンゼー社の記事よりも少し前、2014年のCA Worldのセッションのスライドに改善に関する数字が散見されますので、これを､勝手に超訳の抄訳でご紹介します。スピーチを取り込めていない度合いからすると『スライドからだけ』に近いほうなので、ちゃんと理解したい方、雰囲気も味わいたい方はオリジナルをご覧いただくのが良いかと思います。
動画から拾った部分に※をつけ、拙超訳者の補足を（）で書いています。また、登壇者がノーネクタイという、少しカジュアル寄りな雰囲気を反映したい意図で、TVでよくある洋物の再現ビデオを意識して、やや砕けた文体にしています。
【ING銀行の事例：DevOpsと継続的デリバリーで市場投入までの期間を劇的改善】
オリジナル：
https://www.youtube.com/watch?v=9jqY_bvI5vk
◆INGグループのご紹介：
INGはグローバル金融サービスグループで、3300万超の顧客、40ヶ国、6万4000人の従業員。そのうち1万5000人がIT関係（！）。
オランダでは5分間に1億ユーロがディーリングルームとINGのシステムで扱われている。
◆前ふり：
さて、10年でスマホは0台から1億台になった。
顧客も従業員も期待は膨らむ一方で、いつでも、どこでも、どんなふうにでもアクセスしたいと思っている。
※Amazed（思ってるよりすごかった！斜め上ですごくね？）が今時は重要。
顧客は何が欲しいか知らないと、かのスティーブ・ジョブスも言っている。
昔の銀行は人々が持って来たお金を預かって ※物理的に 安全に保管して厳重にチェックして扱っていた。150年間そうだったけれど、それだけの銀行は、今はもう必要とされない。テクノロジーが沢山の、予想外の競合に門戸を開いてしまった。
みんな、バンク（銀行業の会社）ではなくバンキング（銀行の機能）を求めるようになった。なのに、銀行がその求められる先にいないとしたら、まずいことだ。
◆これまでのアプリ開発：
もし、バンキングのためにアプリをウォーターフォール式に作るとしよう。
（ウォーターフォールというのはこうだ。）
こういうのが欲しいなという夢がある、この夢は具体的には何のことでどうすればつくれるぞと設計して、こういう要求があるからと仕様を決めて、PiD（プロジェクト立ち上げ文書？)にして、開発して。…といったように順番に区切りをつけつつ段階を踏みながら計画通りにやる方法だ。
そうしたいのに現実には、それじゃ使えないといわれ、後になってデザインのイケてないところが見つかって、テストしたら失敗し、開発の問題も出てきて、結果はボロボロ。卵型のジュエリーケースを作ろうとしたら、潰れた生卵になってしまったようなものだ。
こういうことを止めるには、アプリを作るサイクルをもっと早くしないといけない。
※段階をふんでいる場合ではなく、早めに「使えるものだ」ということを証明していかないと大変なことになってしまう。
◆2014より少し前のアプリ開発：
INGの場合、スクラムという名前の、アプリを作る仕事の管理の仕方が最初の1歩になった。次の問題は製品を作ってお客様に届けるときのボトルネックだ。
INGでは継続的デリバリー（スマホでしょっちゅうアプリが更新されて「新しいアップデート」がありますと言われるあれを、継続的にできるようにすることを、アプリを提供する側ではこう呼んでいる）という方法を使っている。そのために、変更したものは全て、お客様が使ってるのとなるべく同じような環境にした場所でテストされる。
リリース前段階では、テストをそれ専用の場所でするけれど、テストする場所は1日に何回も何回も「新しいアップデート」が発生するので、その中から本当にどれをお客様に届けるかは、ソフトの直接の作り手ではなく、（会社としてどんなサービスや商品を一番にお客様に届けたいか、という基準、つまり）ビジネス判断で決めることになる。
どんなプログラムがあってどう変更されたかが一目でわかるようにするための管理も、テストも、お客様がアプリを更新することで欲しかった機能を使えるようにお届けすることも、全てが自動化される、というより自動化しないと「早く」はできない。
「早く」のためには、もっといいもの新しいものを作る側＝開発＝Devと、安心して使ってもらえるようにする側＝運用＝Opsにあるギャップを何とかしないといけない。（というのは、新しいものは、嬉しい時もあれば喜べない時も正直あって、喜べない状態をなんとかするために目に見えないところで動かし方を工夫したり、カスタマーサポートのような形でお客様へのフォローをしたりするのが運用の仕事になるから。もう新しくはなくなったものはエラーがあったとしても問題にならないように対策済みなので、新しいものを作る役割にいる側と安心して使ってもらう役割にいる側ではギャップが出来がちだ）
ギャップにならないようにするやりかた、DevOpsでは開発と運用がともに、バックログという、何をお届けしたいかがリストアップされたものをもとに、一つのチームで働く。
新しい働き方だ。
（なんで新しいと言うのか？それは、ここ十数年くらい、DevとOpsをしっかり分けた方がいい、組織も全く別でいいというのが定説だったからだ）
2014年（そのセッションがあった当時）のアプリ開発：
それじゃあ今度は、新しいやり方で、バンキングのためにアプリをDevOps式に作るとしよう。どうなるか。
こういうのが欲しいなという夢がある、絵に描くなど、作りこんでしまう前に、もっと手間をかけずに目に見えるようにしたものでデモンストレーションして、小さな小さな、でも（ハリボテでなく、本当に製品を使う人に使ってもらえるくらいの）本当に動く製品を作り、使ってもらいながら、その時その時の夢をつど反映していく。
こんな感じで、INGでのモバイルアプリの開発数は、2011年11月から始まって、2014年8月には月に17,000を超えてきている。
だから、ナイトビルド（作ったよ、とアップしておいたら夜中にテストが終わってるというやりかた。夜中にテストが終わるので、朝出勤したら結果が分かる仕組み。）を利用して、継続的にアップデートできるようにするための、完全な「継続的デリバリー」のテストをやっている。
※モバイルアプリの場合、いろんな機種がいっぱいあるから簡単では全くない。でも自動でテストできるようにする。（デモビデオでは、3台のタブレットと、８台のスマホを使って、新しいバージョンを配布、相互に通信しつつテストして、結果が記録される様子が、オライリーより出版のClassic Shell Scripting（邦題「詳解 シェルスクリプト」と一緒に写っている）
テストの結果は、それ用のアプリを使って開発する人全員と共有する。
3ー6週くらいで、「新しいアップデート」の更新機能の一つとしてお届けするのだけれど、INGでは優先度はiStoreのお客様の評価から決める。
だからお客様に注目してもらえるよう、キャンペーンをしたりもしている。
※ここでキャンペーン用動画によるデモ。
BGMはTavares の A Penny For Your Thoughtsの女性コーラス部分。１ペニーあげるからなにを考えているか教えて、と考え込んでいる人にいう軽口がタイトルの曲。
登山中のスマホを使う男性と自宅にいるタブレットを使う女性がINGのバンキングアプリのメッセージ欄で会話している。男性側は昼、女性側は夜（時差がある）。
男性「今君のことを考えてる。君は何を考えてる？」英語で曲名のA penny for your thoughts、とメッセージをつけて0.01ユーロを送る。今だと1.3円くらい。（ペニーは１セント硬貨）
女性はオランダ語で「あなたのこと:) 」
男性「A nickel for kiss♡（キスの代わりだよ）」今度は0.05ユーロ。
（ニッケルは５セント銅貨のこと）
女性から英語で、歌の歌詞通り「 A dime if you tell me that you love me...」
（キスでニッケルなら）「愛してるだったらダイムね」（ダイムは10セント）
男性から0.10ユーロとともに「Ik Hou Van Je」(オランダ語で「愛してる」）
男性も女性もにっこにこのデレデレ。
最後にキャッチコピー
「いつでもどこでも、そこは銀行がある場所」
「モバイルバンキングアプリをダウンロードしよう」
デモはここまで。
※この動画はアメイジング、コミュニケーティングフル、お金への信頼、ライフスタイルへの訴求をこめたチャレンジだ。
モバイルアプリ以外：
また、「新しいアップデート」式なのはWebアプリだけでない。INGの基幹部分も対象だ。基幹というのは普通預金、ローン、当座の口座に関わる根幹の部分を言っている。1200万口座に対して、10のDevOpsチームが取り組んでいる。
（この機能や商品をお届けしようと決めてからそうできるまでにかかる時間、Time To Market）TTMは20週以上から4日になった。
テストでカバーできる機能の割合は３０％から８０％になったし、テストにかかる時間も4週間から6時間になった。
年4回だけだったのが3週ごとにお届けできるようになった。
（天災やそれに匹敵するくらい突拍子もないことに対応できるような仕事の仕方と、そのために用意するアプリやシステムのことをディザスタリカバリ、略してDRというのだけど、）DRのテストに必要な時間は4時間から12分になった。来年末には10秒でできるようにしたいと思っている。
次に、インフラのプロビジョニング。(インフラというと、水を届けるための浄水場や水道管、電気を届けるための発電所や電線がピンときやすいと思うけど、アプリや情報システムだと、通信するための回線や、アプリが通信してる先で動いている機械やOS、その機械に近いところで動いているソフトウェアのことと思ってもらっていい）それはどうか。
○○をしているのは△さんで、△さんなら信頼できるので権限を与える、のではなくて○○をするという役割に対して何をしてよいかを決めるロールベースのアクセス、モニタリング（監視）、（ちゃんとつながるよねという）接続性。大事なことだけれど、そういうものをちゃんと準備するのにどれだけ時間がかかるか。INGではかつて200日超だった。
※それを、時間単位にしようとしている。
最大のチャレンジ：
さて、ここまでアプリとかシステムの話をしてきたけれど、実は、一番大きなチャレンジは「人」に関わるところだ。具体的には、こんなもの。
マインドセットと行動
エンジニアリングの文化
ステークホルダー
サプライヤ
（マインドセットはすっごくはしょって端的に言うと「何が君の幸せ？何をして喜ぶ？」、エンジニアリングは「この科学や技術を人のために役立てるには何をどうやってすればいいか、の体系と実践」）
スマホでよく見る「新しいアップデート」は、実は、適正なマインドセットと行動なしには失敗するものなんだ。
最初は痛みを伴う。けど、3か月ごとに改善を実感する。だから我慢。
人が働くことで得られる力を、こういうことができる性質のものにトランスフォームするために何をするかというと、こうだと考えている。
トレーニング
世界中から才能をひきつける
（「新しいアップデート」をちゃんとタイミングよくお届けできるための）継続的デリバリーができる才能はレアだ。だからといって札束をぶら下げればいいってもんじゃない。エンジニアはすごいエンジニアリングを探している。お金じゃない。（ここを間違っちゃ才能が呼び込めないし呼び込めても居着ない。）
ビジネスのステークホルダー（多分協業するパートナーのこと）やサプライヤ（多分開発の委託先のこと）にも触れたい。
ステークホルダー
継続的デリバリー前：デリバリー間に合いません。あなたのわかってないところでお金がいるんです
継続的デリバリー後：バックログの優先度をダイレクトに信頼、一緒に「ちゃんと動く最小の製品」をきめていける
サプライヤ
継続的デリバリー前：６－１２ヶ月先のリリースになります。なぜならSLAがこうだから。
継続的デリバリー後：小さい範囲のリリース、可用性１００％が、（アウトではなく）協調ソーシングでできる
（こんなに違う。つまり）ビジネスは『テクノロジに依存している』
継続的デリバリーのパイプライン（新機能を作ってテストまたはそのあとのリリースまでを一気に行うこと）は100%使い切るべきだ。
将来：
（「INGはすべきことをやり切っているのか？」といわれると、）まだ道半ばかもと思っている。今後やりたいことにはこんなことがある。
・セキュリティ自動化 パイプラインの一部としてセキュリティ設定をデプロイ
・"CD pipeline as a service"～ 自動化が目的ではなく、（自動化ということを通じてソフトウエアを使ったサービスで、）バンキング（への期待に応えていくこと）を大事にしたい
結び：
銀行の継続的デリバリーはどこまで行くのか。
GoogleとNetflixとかSpotifyと同じ方向を追うのは正直危ない気がしている。金融はストリーミングとは違うのだから。
ご清聴ありがとう。
紹介内容は以上です。
これを書くためにいろいろ見ていて新しく知ったことが多方面で沢山ありました。事例をオープンにしてくださったINGグループ、情報にアクセスできるようにしてくれたインターネットと沢山のサービスに感謝します。
小ネタ：
上記ラブラブ動画：
登壇者よりこの通りにやってトラブルになっても責任は負いません的なセルフツッコミがありましたが、 INGグループはオランダで何番目どころか、S&Pグローバルマーケットインテリジェンスによる資産額による世界巨大銀行ランキング25位なのです。日本の銀行と比較すると、農林中央金庫（こちらが金額は近い）とみずほHDの間にいるわけです。日本の大手銀行のCMと比較すると…。これがヨーロッパのユーザーエクスペリエンスへの訴求、その意欲恐るべし。
超訳といえば：
シドニー・シェルダン作「ゲームの達人」を思い浮かべる方もいらっしゃると思います。「超訳」は「自然な日本語を目指して進める新しい考えの翻訳：として、アカデミー出版により商標登録されているそうです。
「ゲームの達人」では、原著と超訳で「少なからぬ差異」を見つける部分があることは上記リンクのブログでも書かれていますが、日本とオリジナルの出版国のコンテキストが違いすぎることは多々ある中で、それをカバーしようとした努力が爆売れにつながったのだと思うと、商業的にグッジョブだったのは間違いないのでしょう。
日本のコンピュータ導入：
1959年（昭和34年）に三和銀行（今の三菱UFJ銀行）がIBM 650を導入したのが最初で、リアルタイム性を要求されない事務を一括で処理していたようです。真空管の時代です。
IBM 1401：
「IBM 1401 A USER'S MANUAL」という音楽CDがあります。
弦楽四重奏、オルガン、電子機器によるダンス音楽をオーケストラ化した楽曲が収録されているのですが、オーケストラ化の際にIBM 1401による調べも加えられたそうです。
（経緯からすると、編曲前の「電子楽器」にもIBM 1401が含まれている気がしないでもないのですが…）
トラックタイトルは
"Part 1 / IBM 1401 Processing Unit"
"Part 2 / IBM 1403 Printer"
"Part 3 / IBM 1402 Card Read-Punch"
"Part 4 / IBM 729 II Magnetic Tape Unit" (vocals by Erna Ómarsdóttir)
のように、メーカー名、型番、製品説明?です。この1403プリンタのマニュアルを読み上げた録音が使われていて、タイトルの由来になっているそうです。今は存じ上げませんが、IBMの人は4桁(-3桁)の製品番号で会話ができたりしてました。 たとえば、「あの時納めたThinkPad」ではなく、「あの時納めた2625-4J9」と呼ぶといった具合です。タイトルに型番が含まれているほうが、IBM的には自然なことなのです（多分）。型番で有名なのは、なんといってもホストの端末であった3270でしょうか。
IBM 1401は、カリフォルニア州マウンテンビューのコンピュータ歴史博物館に、ボランティアにより稼働できる状態で復元され、所蔵されているそうです。
CDは今も日本でもAmazonで買えます。
1917年：
日本で名だたる企業が設立されています。
TOTO（の前身）
ビオフェルミン（の前身：乳酸菌等製薬）
森永乳業（の前身）
明治（の前身明治乳業）
加えて、チチヤスが日本で初めてのヨーグルトを発売
牛乳が滋養飲料、体格改善によいと唱えられながら日本で普及していく時期だったそうなのですが、それにしても1917年頃に、乳業でエポックメイキングなことがあったのでしょうか？
トランスフォーム：
転換と訳しますが、ここではすんごい長いトラックというかコンボイが背の高いいかついロボットに変わる、というように、全然違うものに変わる感じでしょうか。もっというと、善悪で理解されると不適切なたとえになってしまうののですが、そうではなく価値観が違うという意味で、上下関係と指示命令で動く発想とやり方（デストロン式）を、協調的な発想とやり方（サイバトロン式）に変えるみたいな感じと言ってみるのはどうでしょうか（トランスフォーマー的比喩）
素朴な疑問「DevOpsになるとメインフレームはなくなるのか？」：
INGグループでも無くなってはいないようです。求人広告を見かけました。
一方、こういう記事もあります。
今回はここまで。
(2019/12/19)