Cloud Penguins

Flying penguins in the cloud.

"Opinionated"をどうスッキリ訳すか

ニュアンスを正確に伝える翻訳って難しい。

 

プラットフォームやフレームワークの文脈でよく使われる単語に Opinionated がある。

 

f:id:jaco-m:20201210013851p:plain

 例えばCloud Foundryというアプリケーションプラットフォームの特徴としてもこの単語が使われている。

The Cloud Foundry cloud-native platform has three defining characteristics: it is structured, opinionated, and open.

- Cloud Foundry: The Definitive Guide  https://www.oreilly.com/library/view/cloud-foundry-the/9781491932421/ch01.html

Opinionatedとはどういう意味か。辞書を引いて意味を調べると、こんな感じだ。

opinionated

自説を曲げない、意固地な
・Someone known to be passive may become opinionated. : 従順だった人が意固地になることがある。

https://eow.alc.co.jp/search?q=opinionated

え、なんかめっちゃネガティブ・・・

 

日本語の記事でも翻訳には苦慮しているようで、なんとか表現を工夫して伝えようとしていることが分かる。

これが同社にとっての「opinionatedな」(自社の考えや提供価値を体現した)アプローチだ。
- CNCFのCOOに聞いた、CNCFとOCI、Docker、Kubernetes、Cloud Foundryとの関係 https://www.atmarkit.co.jp/ait/articles/1612/22/news032.html

 このようにCloud Foundryは、デベロッパーに対して無駄なことをさせずに、アプリケーションを書くことに集中させるため、時に「Opinionated(独善的)」という形容詞が付けられるほどだ。

- ONSのトリはVinton Cerf氏登場 そしてCloud FoundryとKubernetesはどうなる?  https://thinkit.co.jp/article/13794

 このように、そのまま日本語に訳すのではなく、Opinionatedという英単語を直接記した後、日本語の補足を加えるというケースが多く見られる。

ポジティブな意味でのOpinionated

しかしプロダクトの特徴に使われるくらいなのだから、当然ポジティブな意味で使っている。

Cloud Foundryは、アプリケーションを開発してcf pushというコマンドを一発叩くだけで、コンテナイメージへの生成からインターネット上への公開まで全ての作業を自動で行ってくれるプラットフォームだ。

f:id:jaco-m:20201210020242j:plain

 超絶便利な一方で、世の中全てのWebアプリケーションを動かせるというわけではない。Cloud Foundryの恩恵を受けながら動かしていくには、12 Factor Appなどいくつかの制約に従う必要がある。

利用者に制約を課す代わりに高い生産性を提供する=Opinionated というわけだ。

 

Constraints are liberating - 制約は自由をもたらす

OpinionatedなWebフレームワークとしてよく取り上げられるのが、Ruby on Railsだ。フレームワークという存在自体が既にOpinionatedだとも言えるが、Railsはその中でも特にその傾向が強い、そしてそのメリットを強烈に印象づけた先駆けといえる。

設定より規約(Convention over configuration) の考え方に則り、あれこれ設定させるのではなくフレームワークの規約に従って開発をさせることで、重要なことに注力できるようになる。規約から外れたことは出来ないため柔軟性は少し落ちるかもしれないが、それを遥かに上回る生産性というメリットがついてくる。

Railsを表現する言葉として 制約は自由をもたらす(Constraints are liberating) というものがあるが、一見矛盾したこの2つの考え方を両立させるのが、規約を重要視したWebフレームワークであり、Opinionatedな仕組みなのである。

で、どうやって訳すのか

 ここまで読んだ諸兄には、Opinionatedのポジティブな文脈での利用法が伝わったと思うが、じゃあこれをどう訳せば日本語としてスッキリするだろうか。

自分は仕事でCloud Foundryに関わることが多いのだが、口で説明するとこんな感じになってしまう。

「Cloud Foundryの特徴はOpinionatedなところにあり・・・えー、Opinionatedという言葉は日本語にすると『独善的』とも訳されることがあるんですが、そういうネガティブな話では無くもっとポジティブな感じで、制約を課すことでむしろ生産性を上げていくという意味でして・・・」

結局先に上げた記事のように、Opinionatedという英単語をそのまま使いつつ日本語で補足するという形になってしまう。

『こだわり』の翻訳

そう悩むこと数年。ついに出会った、個人的にスッキリくる訳がこれである。

『こだわり』

だいぶ前に読んだ何かの記事で使われていた訳だ。出典はちょっと失念してしまったのだが、『○○は、こだわりの強いプラットフォームであり・・・』といった形の表現をされていてた。

なるほど、これはいいかもしれない。

辞書で引いてみるとこういう説明がなされている。

拘わる
読み方:こだわる・かかわる
別表記:拘る

拘わるとは、比較的どうでもいい事を気にしすぎて、いつまでも気にかけたり必要以上に手を加えたりしたがることを意味する表現。「かかずらう(拘う)」ともいう。

「拘わる(こだわる・かかわる)」の意味や使い方 Weblio辞書

おおう、ネガティブ。

そう、『拘る』という言葉は本来ネガティブな意味で使われる言葉だ。しかしご存じのように、『シェフのこだわりランチ』のような形でポジティブな用法もある。これは比較的最近生まれた用法らしい。

ネガティブな用法で使うときは『拘り』と漢字にし、ポジティブな用法で使うときはひらがなにすることが多い。

この二面性がある感じ、Opinionatedと一緒ではないか。

 

「Cloud Foundryって結構こだわりが強いプラットフォームなんです。Kubernetesほどなんでもアリなプラットフォームではないんですが、12 Factor Appsに従ってアプリを作ることで、cf pushだけでアプリをデプロイできて。」

 

うん、だいぶスッキリしたな。

 

「イラストでわかるDockerとKubernetes」は完全に良書

すごいタイミングですごい本が出たもんだ。

本日はKubernetes Advent Calendar 2020 その1 向けのエントリー。

本当はCF for k8sの記事を書くつもりだったのだけど、先週盛り上がりまくったDockershimのDeprecated話の後ですごーく良い本が出てきたので、これは紹介せねばということで急遽内容を変更。

jaco.udcp.info

CF for k8sの話も途中まで書いちゃっているのでまた日を改めて公開する。

あの神資料が本になったよ

ということで今日の話題はこちら。

今ではDockerやKubernetesに関する本もだいぶ出揃い、使い方を学ぶのには困らなくなってきた。それに、基本的な使い方だけであれば書籍で体系的に学ばなくとも、ネット上に転がっているサンプルをそのままコピペするだけで難なく動かせてしまう。

10年前であればセットアップだけで数日かかっていたような複雑なソフトウェアでさえ、 docker-compose up するだけで動かせてしまう。これはDockerを学び始めた人の誰もが体感するところだろう。

これ自体はとても良いことなのだけど、言い方を変えると仕組みを理解しないまま使い続けられてしまう。例えば先ほどの『Docker非推奨問題』で不必要に慌ててしまったり、環境をKubernetesへステップアップさせていく際の支障となったり。こういった『何らしかの躓きポイント』は、出来る限り早めに取り除いておきたい。

ぜんぜんわからない 俺たちは雰囲気でDockerをやっている

しかし毎日車に乗っている人が必ずしも車の仕組みに詳しくないのと同様に、毎日 dockerkubectl を叩いていても、なかなか仕組みには詳しくならない。仕組みを理解していくには、世の中の膨大な資料を自分で調べたり、あるいは Kubernetes The Hard Way のようにステップバイステップで触っていくなどの努力が必要だ。

この分野で食っていく人にはそうして欲しいのだけど、Dockerを触る全ての人がそうすべきだとは思わない。もっと素早く、体系的に学べる資料があったほうが良いだろう。

ということで、これまではNTTの徳永さんの、この神資料を紹介していた。

www.slideshare.net

で、今回。この神資料が本になったのだ!

これでSlideShareを社内ネットワークから接続拒否しているようなエンタープライズ企業の人にも勧められる!

仕組みを理解するのに簡潔かつ明快な章立て

徳永さんによって書かれた本書。目次は以下のようになっている。

(目次)
第1章 コンテナ技術の概要
1-1 コンテナを見てみよう
1-2 コンテナ技術の基本的な特徴
1-3 本書で注目するDockerとKubernetes
第2章 Dockerの概要
2-1 DockerによるBuild、Ship、Run
2-2 コンテナのレイヤ構造
2-3 DockerのアーキテクチャとOCIランタイム
2-4 まとめ
第3章 Kubernetesの概要
3-1 Kubernetesの特徴
3-2 Kubernetesクラスタとkubectl
3-3 Kubernetesにおける基本的なデプロイ単位
3-4 KubernetesにおけるPod群のデプロイにまつわるリソース
3-5 設定項目やボリュームに関するリソース
3-6 Kubernetesにおけるサービスディスカバリ
3-7 KubernetesのPodとCRIコンテナランタイム
3-8 まとめ
第4章 コンテナランタイムとコンテナの標準仕様の概要
4-1 コンテナランタイムと2つのレイヤ
4-2 いろいろな高レベルランタイム
4-3 いろいろな低レベルランタイム
4-4 OCIの標準仕様
4-5 runcを用いたコンテナ実行
4-6 実行環境作成に用いられる要素技術

目次を見るだけで気づくかもしれないが、例の問題はこの本を読めば完全に理解できる

対象となる読者はコンテナ入門者。ただしDockerを学びたい人が1冊目に読む本ではない。他の本やWebの資料を基に基本的な使い方を理解した人が、二冊目として本書を利用して仕組みの理解を深めるとよさそうだ。

仕組みの説明をするとどうしても分量が多くなってしまうものだが、本書は目次や索引含めて148ページしかない。2時間程度でさっくり読めてしまうだろう。そういった意味でも、二冊目として最適なものだと言える

図が多くて分かりやすい

前回の自分の記事の対するコメントでもいくつか頂いたのだが、やはり仕組みの説明には図を使うのが分かりやすい。

前述の徳永さんの資料も図解が素晴らしかったのだが、本書は図+文章でより理解しやすくなっている。 f:id:jaco-m:20201208211454j:plain

特にコンテナランタイムの図解は必見。コンテナランタイムは高レベルランタイムと低レベルランタイムで役割が異なるのだが、学び初めはどうしても混同しやすい。図を頭に入れて置くことで、スッキリ理解しながら読み進めることができるだろう。

プログラミングの学習では、書籍をそのまま丸写ししていく写経が良いと言われるが、本書の図を手書きして自分の言葉で説明ができるよう、模写していくのもありかもしれない。

f:id:jaco-m:20201208213010j:plain ちなみにこちらは自分が先日の記事を書く前に、とある人に説明する際に描いた絵

やっぱり難しいKubernetes部分

若干気になったのはKubernetesに関する図解。Kubernetes自体の規模が大きく複雑なのもあるからか、やや抽象化されすぎて分かりづらいものもあった。また、Kubernetesの7角形に拘った表現が多かったが、紙面ならばもうちょっと表現の工夫が出来たのではないかなと思うところがあった。

ただそれでも、相当分かりやすい部類の説明であることには変わりないので、是非読んでみて欲しい。

Kubernetesの部分を特に掘り下げて理解していきたい場合は、Kubernetes完全ガイドにステップアップしていくのが良いだろう。この本も図解が非常に豊富で、Kubernetesを学ぶのには最強の本だ。

ということで

「イラストでわかるDockerとKubernetes」、本当におすすめです。

Dockerは非推奨じゃないし今すぐ騒ぐのをやめろ

今話題のこれ。

kubernetes.io

これに関しての日本語情報として、 @inductor が相当詳細に記事を書いてくれている。

blog.inductor.me

blog.inductor.me

にも関わらず、未だに完全に間違った解釈をしている人が多く観測される。記事をちゃんと読めば理解できるはずなのだけど、たぶんタイトルしか読んでいない

タイトルしか読まないのであれば、あえて強めのタイトルにしておけば目にはつくかなと思い、改めて書いてみることとした。

Dockerは非推奨じゃないし、これからもバンバン使え

まず @inductorが解説しているとおり、k8sを使っていない人には全く関係のない話なので、今まで通りDockerを使って良い。 が、もう一つ誤解を解いておきたいのが

自分の環境でDockerを使ってイメージ作成し、Kubernetesにデプロイしている人にも、今回の件は関係が無い

Kubernetesを使っていてもDockerはバンバン使っていいし、今のあなたたちが行っているワークフローには何の変化もない

今回の件で騒いでいる人たちは、この部分を勘違いしているように思う。

今までもこれからも、Dockerを使うことは推奨するし、本番で動かすときはDockerで作ったイメージをKubernetesに持って行って良い。

じゃあ何で非推奨って話になったのか

今回の件は、Kubernetes内部のコンテナランタイムとしてDockerを利用するのがDeprecatedになったという話。言い方を変えると、Kubernetesを自前で構築して使ってる人くらいにしか影響がない。 上記の記事で十分に説明されていると思うけど、自分が他の人に説明する際に使った絵を使うとこんな感じだ。

普通にDockerを使う場合

普段 docker run のようなコマンドを使っていると思うが、内部的にはざっくりこんな感じの動きになっている。 docker コマンドはDockerのAPIを通じて、最終的には裏側にいるコンテナランタイムによって実行される。Dockerは内部で containerd という仕組みを使っていて、そこで動く。 f:id:jaco-m:20201203162951p:plain

KubernetesでDockerを使っている場合

KubernetesのコンテナランタイムでDockerを指定している場合はこうなる。人間がdockerコマンドを叩く代わりに、kubernetesの中の人がDocker APIを叩いてくれるイメージだ。 f:id:jaco-m:20201203163334p:plain

上記の絵を、もうちょっと付け加えるとこう。Kubernetesがコンテナランタイムと喋るときにはCRIという仕様を元に行うのだけど、DockerはCRIに対応していない。なので、 dockershim というブリッジを経由して通信を行っている。 f:id:jaco-m:20201203163809p:plain

今回の話

でも実は、Docker内部の containerd は、CRIに対応しているのである。 え、じゃあcontainerdと直接通信すれば、dockershimもdocker apiも要らないんじゃない?

f:id:jaco-m:20201203164237p:plain

そう、今回の話は、ただそれだけの話なのである。

ふつうに考えればcontainerdを直接叩いた方が運用の面でも、セキュリティの面でも、リソース効率の面でも効率がいい。実際多くのディストリビューションがcontainerdやcri-oといったCRIを喋れるコンテナランタイムを直接使うようになっている。

ならば、もうそろそろDockerのところは必要性が薄れてきたよね、となったのが今回の話。

Dockerが大きく普及したのが2013年ごろ。Kubernetesが登場したのが2014年。この段階ではKubernetesがDockerをコントロールする構図は自然な流れだった。

その後様々なコンテナ規格の乱立が始まったため、標準規格を定めようという動きになったのが2015年から2016年にかけて起こり、そこでcontainerdやCRIが登場した。こうした歴史的な経緯を経て、より効率の良い方向へと変わってきたわけだ。

これからもバンバンDockerを使えというワケ

繰り返しになるが、今回の件はKubernetes内部の一部品としてDockerが使われなくなるというだけなので、Kubernetesの利用者には何の影響もないと言って良い

ごく一部の利用者には影響があるかもしれないが、そういった深い使い方をしている人であれば、そもそも今回の件で慌てることはないだろう。

利用者には影響はないという理由

Dockerがここまで普及したのは、Build, Ship, Runというワークフローを確立したところにある。

f:id:jaco-m:20201203165855p:plain

  • Dockerfileを書き、 docker build コマンドでイメージを作成する。
  • docker push コマンドでイメージをRegistryにpushする
    • 他の人がpushしたイメージをそのまま使うことも出来る
  • docker run でコンテナを実行する
    • docker-compose を使うとより便利

Kubernetesを使う場合も、このワークフローはそのまま利用することが出来る。

f:id:jaco-m:20201203170245p:plain

Build, Shipのフェーズはそのままで、Runのところが変わる。 docker rundocker-compose up する代わりに、YAMLでManifestを書き kubectl apply するわけだ。開発のワークフローはそのままに、より高度な運用(Run)が出来るようになったのがKubernetesの利点である。

じゃあ今回の件で何が変わるか? 何も変わらない

f:id:jaco-m:20201203170725p:plain

今まで通りにDockerfileを書いてDocker image作ればいいし、kubectl apply するところも全く同一だ。 デプロイした先でのKubernetesの内部コンポーネントの通信先がちょこっと変わっているだけである。

そう、だからDockerは今まで通り便利なツールとして使い続けられるし、もちろんDocker以外のツールを使ってもいい。

標準規格によって、利用者はどんなツールを使っても互換性の問題に悩むこと無く恩恵にあずかれるのが、今のCloud Native技術だしCNCFの存在意義である。そして今回の話は、標準規格がしっかりしているからこそ出来た、極めて健全な発展を裏付けるものなのだ。 だって大きな互換問題が発生するんであればこうも簡単にDeprecatedに出来ないよね。

互換性の問題でレガシーを引きずるソフトウェアがごまんとある中でこういった移行ができるのは、むしろ賞賛されるべきことだと考える。

ビジネスとしてのDocker(社)の動きについて

Docker社がビジネス的な観点で大きなチャンスをモノにできなかった話は、言わんとすることは分かるし自分としても思うところはたくさんある。

しかし、今回の件は決してDockerがビジネス的に衰退したから切り捨てられるってわけじゃなくて、技術的にあるべき形に進化したというだけだ。

そりゃ確かにDocker swarmあたりを成功させていれば、ここまでのKubernetes1強にはならなかったかもしれない。しかしそれは全く別次元の話であって、今回の件に絡めて『Dockerはオワコン』みたいな話に持って行くのも、なんか違うんじゃないかな。

結論

もう何度目の繰り返しになるか分からないけど、 DockerもKubernetesも超便利な仕組みだし、まだまだ発展していくのでこれからも便利に使っていこう。

追記

良いタイミングで良い本が出たので紹介。今回の件で慌てちゃった人にはすごくお勧め

jaco.udcp.info

世界に誇れるプラットフォームチームをつくる(CNDT2020)

event.cloudnativedays.jp

CNDT2020で発表する、『世界に誇れるプラットフォームチームをつくる』 の補足ページです。 収録したら90分くらいになってしまったものを、バカスカ編集して切り落としていった結果、伝えきれなかったものも多くなってしまったのでこのページで補足しようという趣旨です

なお、この記事は反応をみながら随時追記していきます。

スライドアップロードしました

speakerdeck.com

このセッションで言いたかったこと

プラットフォームはプロダクトだという意識を持つべき

社内向けプラットフォームであっても、プラットフォームを利用する人は顧客であり、顧客への価値を最大化するようにプロダクトをマネジメントしていくべき。

プロダクトマネジメントについては世の中に知見がまとまりつつあるので、プラットフォームの開発・運用に携わる人も、ぜひ学んでいきましょう。

頂いた質問

取り入れていく考え方の中にSREもあるけど全く言及されてない?

全く言及してないですね・・・。発表したのがCNDTだったんで、SREの考え方は改めて説明する必要はないかなと思い、特に記載はしませんでした。 プラットフォームチームの技術面を支えていくのに重要な考え方だと思うので、世の中にあるSREの資料を見ながら実践していくといいんじゃないかと思います。

Platformってよくあるプロダクトに比べると時間がかかるんでは? リーンにいけるの?

確かに、世の中のプロダクトマネジメントで言われるようなプロダクトよりはリードタイムが長いです。ただ、言い方を変えると一つ要らないものを作ってしまうだけで多くの時間を無駄にしてしまうリスクがあるということなんですよね。 なので、やはりMVPを作ってリーンにプロダクトを作っていったほうが良いと考えています。

参考資料・参考リンク

動画中で2度ほど「このあと紹介する資料を…」っていうシーンがあるのですが、紹介が収まりきらなかったのでこちらで。

VSMの参考資料

CNDT2020 Rejektsのときにmosukeさんが発表されていた動画が参考になります


【CNDT2020 Rejekts】効果を出すための真のクラウドネイティブDevOps実現への道 / 森 真也

Team Topologiesの参考資料

Cloud Operator Days Tokyo 2020で鳥居さんが発表されていた資料が参考になります

speakerdeck.com

本家はこちら

teamtopologies.com

deeeetさんも書籍のレビューを書かれていました

Team Topologiesを読んだ | SOTA

参考書籍

amzn.to

amzn.to

amzn.to

amzn.to

IBM Cloudの課金問題、解決(・・・と、DevRelはダメだという話) ※追記の追記あり

背景

一部の界隈をざわつかせたこちらの件。

IBM Cloud (旧Bluemix) のアカウントを持っている人は今すぐクレジットカードの請求を確認すべき ※追記の追記あり - Cloud Penguins

IBM Cloudからの不意打ち請求はあろうことか2重請求だった ※追記あり - Cloud Penguins

解決

IBM Cloudの利用者にはメールでも通知されていると思うが、3月4月分の返金を行うということで方針がきまったそう。一番の問題点であった、一部ユーザーにプラン変更の通知メールが飛ばなかった原因については現在も調査中とのことだが、結果がわかり次第公開してもらえるとのこと。

www.ibm.com

調査結果も纏められているので、今回の問題に当たってしまった方は読んでおくと良いかも。

ひとまず利用者にとってはベストな形の対応方法をとってもらえることになったので、個人的にはこれで解決かなと思う。

しかし上記報告の中にある

その後の調査によって、44件のクレジットカードへの二重請求があったことが分かり、うち43件は2度の決済処理が原因でした。1件は2度の決済処理のうち1回がエラーで決済できなかったため、書面での振込依頼を行ってしまいました。

よりによってその1件の特殊ケースがウチだったんだなぁ。振込依頼のメールがなければ今回の問題に気づくのは大分後になったと思うので、また違った展開になったかもしれないね。あと、二重決済をきちんとブロックした楽天カードGJ

解決に至るまでの経緯

5/15(金)

  • 昼 カード決済が出来なかったから振り込みをしろというメールが来る
  • 14時頃 メールに気づく。最初は自分のミスかと思いアチャーとなるが、調べてみると事前通知がない。そりゃー無いでしょとPaaS勉強会のSlackにボヤく。 f:id:jaco-m:20200522205841p:plain
  • 15時頃 サポートに課金が不当である旨のチケットを上げて、仕事に戻る
  • 夜 FacebookのBluemix User Groupに、『そういや3/1に有料化したからチェックしといてね~』的な投稿が行われているのに気づく。いやいやそれ有料化前に告知すべき内容でしょとイラッとする。IBMのデベロッパーアドボケイトに文句を言うがガン無視される

5/16(土)

  • 朝 カードに課金が行われていることに気づく。このときは二重課金かどうか確証がなかった。
  • 夕方 FBやTwitterで同様の課金を食らっている人が居ることに気づく。
  • 夕方 再度デベロッパーアドボケイトに文句を言うもガン無視される。埒があかないので問題をまとめて公開することを決める。
  • 一つ目の記事公開

5/17(日)

  • 朝 利用額等をチェックして二重課金であることを確信する。
  • 夕方 サポートチケットに二重課金の問題も追記する。まだ返信は無し。
  • 夕方 周囲のIBM関係者からも一切反応がない。これでは埒があかない(2度目) と感じ2つめの記事も公開

5/18(月)

  • 朝 Bluemix User Groupの投稿で、サポートチケットに日本語で送っても対応してもらえないことを知る。Blogじゃなくてもっと分かる場所に書いて欲しいな。
  • 昼 上記ブログに、電話とチャットなら日本語で受け付けしていると書いてあるのを見て、電話をする。 しかしバリバリ英語での対応であった。(こうなることは予感していたので、心の準備はしていた)。 内容が内容なので、日本人に代われない?と聞いたところ、電話では日本語対応していないがチャットならOKだよと言われる。
  • チャットを開始する。しかし英語で返ってくる。まぁそうじゃないかと思ってたよ。 billingについて聞きたいことがあるから日本人に代わっておくれと言ったところ、日本人の営業が出てくる。
  • なんで営業?と思いつつ、今回の問題と返金要求をぶちまける。返答がしばらく無く、ここで昼休憩が終わってしまう。
  • 14時ごろ 上記チャットにサポート担当から返事があることに気づく。『プラン変更についてはメールで通知したはず』『3月分の請求に関しては返金対応を行う』『4月分に関してはまだ請求を行っていないので、請求されたら返金するから再度チケットを上げて欲しい』との返信でチャットがクローズされていた。
  • 返金対応が行われる点については良かったが、メール通知を行ったという主張には不満を抱いた。
  • 夜 クラウド&コグニティブ・ソフトウェア事業本部の方から直接コンタクトがあり、対話を開始。『あるべき通知が送られていないケースを確認できており、急ぎ対応方法を検討している、ユーザーにはWebおよびメールで経過報告を行う』という旨を連絡いただく。 非常に真摯な対応でだいぶ溜飲が下がる

5/19(火)

5/22(金)

まとめ

月曜にコンタクト頂いて以降の対応はとても真摯で好感の持てるものだった。自分も外資にいる身として、本国と話し合いながら対応策を決めていく大変さは理解しているので、あの規模でこの対応速度というのは、恐らく相当な危機感をもって対応して頂けたんじゃないかなと思う。

他の利用者についても一律返金ということで、ひとまず良い形に落ちたと思う。声を上げた人しか対応してもらえないというケースもあり得たので、この点でも評価出来るのではないか。

自分としてはこの件はこれにて終了と思っている。

おまけ

それにしても、改めて感じるのが、 DevRelって何なんだろうねと。

経緯を読んでいただければ分かると思うが、初期対応が非常に悪かった。お金に関する問題というサービスとして最もクリティカルな問題に対して、完全にダンマリを決め込まれてしまった。

本来、ユーザーに近い立ち位置で信頼関係を築き上げていくのがエバンジェリストやアドボケイトという仕事なんじゃなかろうか。しかし、今回は信頼関係を築くどころか全力でぶち壊すような動きをされたため、こちらとして出来る対応が事実関係をまとめて書くくらいしか無くなってしまった。

ただ、今回の件に限らず世の中のDevRelに関する人たちの動きはこれまでもずっとモニョモニョしたものを抱えていた。もちろん全員が問題という気は全くなく、本当に技術を愛してユーザーのことを考えている、尊敬できる人たちも沢山居る。

でも、この人は本当に技術のことが好きなのか? 単にミートアップやってキャッキャウフフして、気持ちよく喋りたいだけなんでは? という人も本当に多い。本当の本当に多い。

そろそろ、DevRelのあり方について見直す時期に来てるんじゃなかろうか。そう強く感じる一件だった。自分の関わるサービスの問題に当事者意識を持てないなら、DevRelなんてやめちまえよ。

追記

(感情逆撫でしてくるようなツイートがあったので記載していたがここに書くのはアンフェアすぎる感があったので削除)

追記の追記

デベロッパーアドボケイトのようなDevRelの人にサポートを求めるのは違うんじゃない? という意見があったので補足。確かにこの部分は自分がアドボケイトに何を求めているか不明瞭だったと思う。

職掌の違いについては自分も理解していて、経緯にも書いたように問題が発覚した後は即座にサポートにチケットを上げている。ここはどのベンダーにおいても共通だと思う。

DevRelをタップしたのは、User Groupに5/15になってから『3/1にプラン変えたから改めてチェックしておいてね』という投稿があったのがきっかけ。改めてとか言いながら過去には一切の通知はなかった。1ヶ月半も経ってから言うのが遅すぎるでしょうと。 まずこの点に関して意識が希薄すぎない?というのが1点。

実際アドボケイト主催のIBM Developer Dojoが契機となって今回のトラブルに当たっている人もいるので、アドボケイトは無関係どころか当事者ど真ん中なのだ。

どういう対応を期待していたかというと、ほんの一言でいいから何らしかの反応があればそれだけで大きく違ったように思う。

また、User Groupの方が、チケットだと日本語対応していないこと、電話したほうが早く対応してくれることなどを、この記事とともに教えてくれた。

www.ibm.com

こういう適切なディレクションをすること自体も、DevRelな人に求められていることじゃなかろうか。

大きな組織になってくると、何でもかんでも一人で対応するのは難しい。一方で、組織内の壁によりユーザーへの対応が二の次になってしまうのも、また問題だ。だからこそ、ユーザーに近い立ち位置で、組織の壁をうまくカバーするようユルユルっと動く。それがDevRelなんじゃないかと思っているし、自分がすごいと思っているDevRelの方々もそう動いているように見える。

別にDevRelにサポートをしてほしいって話ではないのでした。

(解決済み) IBM Cloudからの不意打ち請求はあろうことか2重請求だった

追記の追記

本件、解決しました。

jaco.udcp.info

以下本文

事の発端は前の記事を参照

jaco.udcp.info

本人に通知のないまま行われた有料化によって突然の請求が行われたこの案件。 よくよくチェックしてみるとさらに信じ難いことが起こっていた。

クレジットカードで決済出来ないから銀行振込しろ ⇒ 普通に決済出来ていた

前回の記事にも書いたのだが、 今回の件はクレジットカード決済出来なかったから銀行振込で支払えというメールが5/15に来たことで問題が発覚した。

f:id:jaco-m:20200517190016p:plain

メールには、令和2年3月の利用分について、 3,207円を銀行振込しろと書いてある。 通知のないまま行われた決済なので、サポートに苦情を上げているのは前回書いたとおり。胸糞悪い話ではあるが、まずはサポートがどう対応するか数日待ってみようと思っていた。

週末にまで胸糞悪い思いを引きずるのは嫌なので、一旦日常生活に戻るべく、ルーチンで行っているマネーフォワードでの家計簿チェックを始めたのだが、ふと見慣れない支出があることに気づいた。

f:id:jaco-m:20200517180005p:plain

…え。

これは一体どういうことか。いや、確かに前回の記事のタイトルに『今すぐクレジットカードの請求のチェックしろ』って書いた。他の人も不正な請求が行われてるかもしれないと思ったから、そう書いた。が、自分の請求に関しては実はちゃんとチェックしていなかったのだ。だってクレカ決済失敗したから振り込めって連絡が来てたので、自分のクレカはセーフだと思い込んでしまっていた。

ちょっと信じられないが、時系列に整理するとこうだ。

  • 5/8 クレジットカードから3,207円分の引き落としが行われている
  • 5/15 クレジットカード決済失敗したから 3,207円を振り込めというメールが来た

おかしいな、なんか違う世界線に来てしまったのかな。

もうちょっと情報収集する

カードの2重請求っていうのはよく聞く話だ。決済処理中のエラーや店員が誤って端末に2回通してしまったというトラブルだ。 しかし、今回はカードの2重請求ではなくて、カード決済が出来ているのにも関わらず銀行振込を要求されているのだ。こんなザルな請求管理が大企業であり得るのだろうか。

この件に関してもまずは自分を疑った。

メールの文面には、令和2年3月分の請求と書いてある。 今は5月だ。つまり、カード側の何らしかのトラブルで3月分の決済ができず銀行振込になり、4月分がカードの請求に戻ったのではないかと。であれば納得がいく。いや、不意打ち料金変更については納得いっていないが。

しかし、時間単位のpay-as-you-goプランで3月と4月の料金が同じなんてことはあり得るのだろうか?

ポータルにログインしてBilling and usage -> Usageの中身をチェックする。

まず3月。2,916円。消費税加味すると3,207円で一致する。

f:id:jaco-m:20200517183614p:plain

次に4月。2,822円。消費税加味すると3,104円になる。

f:id:jaco-m:20200517183857p:plain

…つまり、3,207円の請求は3月のものであり4月ではない。 自分はクレジットカードで引き落とされた上に銀行振込まで要求されたということで確定した。

ちょっとこれは本当にどうなのか。IBM Cloudはごくごく基本の請求管理が出来ていない。

前回の記事では主に無料枠で運用していたユーザー向けへの注意喚起であったが、今回の件によって判明したことは IBM Cloudを業務で利用している全てのユーザーは、過去の支払いに誤りがないか、2重請求されていないかを確認する必要がある、ということだ。

この2重請求についてもサポートに苦情を上げた。しかしあまりにも度が過ぎているように思うので、サポートから真摯な対応が得られない場合は然るべき対処を取るつもりだ。

追記

やはり2重請求だったようで、ごめんなさい連絡が。 f:id:jaco-m:20200519102730p:plain

そもそも請求の正当性についてはまた別途調整が進んでいる様子。

(解決済み) IBM Cloud (旧Bluemix) のアカウントを持っている人は今すぐクレジットカードの請求を確認すべき

追記の追記の追記

本件、解決しました。

jaco.udcp.info

以下本文

ちょっと常識では考えづらいことが起こっているようなのでまとめる。

TL;DR

  • IBM Cloudの料金プランが、本人への通知がないまま変更された(無料枠の削除)
  • かつてお試しでアプリを上げたユーザーに、思わぬ課金が行われている可能性がある
  • かつて一度でも使ったことがあるユーザーは、クレジットカードの請求を確認すべし

発端

昨日突然こんなメールが届いた。

f:id:jaco-m:20200516190755p:plain

IBM Cloudは旧称であるBluemix時代からCloud Foundryベースのサービスを提供しており、クレジットカード登録をしておくことで一定分のリソースについては無償、超えた部分は課金という料金体系だった。

『カード登録しても一定以内であれば費用かからないのでどんどん試して』と言われていたので、ワークショップでちょっとしたアプリを動作確認兼ねて上げてみたのが4年ほど前。 試しで上げたアプリは存在すら忘れて今日に至っていた。

それが突然の請求だ。

自分も元々クラウドサービス提供者側におり、マネタイズの難しさは理解している。儲からないのでフリーミアムモデルを取り止めるという意思決定自体は、サービス提供側の視点に立てば特に不思議ではない。

突然の請求を受けてしまったということは、どうやら有料化のお知らせの通知を見落としてしまったようだ。 一応自分に届くメールはタイトルだけでも確認しているつもりだが、うっかり見逃していることもゼロではないだろう。やっちゃったなー、と思い過去のメールを確認した。登録していたメールアドレスには独自のエイリアスをつけているので、エイリアスで検索するだけで絞り込める。

f:id:jaco-m:20200516192954p:plain

しかし、ないのだ。 料金体系変更のお知らせが一つもないのだ。流石に目を疑って何度か確認したが、そこににあるのはメンテナンスと障害通知のみで、料金体系については一つも無かった。

今回届いたメールの文面を見るとこんなことが書いてある。

IBM Cloud Foundry Public はデフォルトの標準プランを変更しており、この内容は、2019年12月10日付のブログ(英語)にて発表しています。

IBM Cloud Foundry Public プラン変更のお知らせ | IBM ソリューション ブログ

つまりだ。IBM Cloudは、ユーザー本人に直接通知をすることなく、ブログでこそっと記載をするのみでいきなり有償化を行ったわけだ。

さすがにこれはあり得ないのではなかろうか。ユーザーのうちどれだけが公式のブログを細かくチェックしているというのだ。こんなの通知のうちに入るわけがない。

かれこれ20年近く、さまざまなWebサービスを利用してきたがこんな形で突然の課金を食らったのは初めてだ。ええぇ・・・。

Twitterでも被害にあった人がちらほら。FBでも同様な被害報告があった。

自分の場合はたまたま登録していたクレジットカードが決済できなかったため、振込依頼のメールが来て今回の件に気づいた。が、有効なクレジットカードを登録している人はいつの間にか課金が行われている可能性がある。 IBM Cloudを使ったことある人は、急ぎ不慮の請求がないか確認した方が良い。

このような通知がないままの料金改定はあまりに非常識なので、サポートに不服申し立てのチケットを上げた。こちらについても回答があり次第掲載する。

※注釈

2017年末から始まったIBM Cloudライト・アカウントについては、そもそもクレジットカード登録が不要とのことで今回の問題には当たっていないと思われる。しかし、このようなポリシーで運用しているクラウドサービスを利用し続けて良いかどうかは、検討の余地ありだろう。

追記

被害者続々見つかる。 本当になんの通知もなく行われたので、クレジットカード明細を細かく確認している人でないと気づいていない可能性が高い。IBM Cloudを使っていた方は、一刻も早く請求を確認しよう

追記の追記

jaco.udcp.info