ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

DevLoveイベント"カイゼン・ジャーニー ／ 「一人から始める」を始める。"に参加してきた

本

カイゼン・ジャーニー ／ 「一人から始める」を始める。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

https://devlove.doorkeeper.jp/events/71927

参加してきた。現場でのメモ＋感想をまとめておきます。

感想

  • 少し前に読了して、振り返りブログを書こうとしていたところ、インプットになると思い参加
  • 自分1人＝ぼっちでカイゼンをしていってるけど、広がらないところで悩んでる、ってひとばかりが集まっていた（私もそう）
  • （市谷さんもおっしゃっていたけど）無理に全部変えなくていいんじゃないか、自分がどんどんやって、それで置いていって、その上で会社変えりゃいいんじゃないか、って言っていて、本当にその通りだと思う（僕もそれで転職した）
  • カイゼン・ジャーニーはたぶんアジャイルの話じゃない、カイゼンって、自分や周囲を変えるって、自分からやるしかないんだよ、ってことが、一番のメッセージだと思う

以下はメモ。

第1部 新井さん

speakerdeck.com

  • 同僚を助けることを評価
    • try100
    • 他人を輝かせる
  • 勝手にメンター（尊敬しているひと）、好きを伝える、フィードバックをもらえる

旅路のまとめ

  • 1歩を踏み出す
    • 自分の意思で何かをやろうと決める
    • 自分からGive & Give
  • その結果、社内外の仲間に伝搬
  • 越境している組織になっていた
  • 5つの価値
    • 自分からはじめ
    • 越境
    • フィードバック
    • リフレーミング
    • 巻き込み巻き込まれる

考えすぎちゃダメ

  • たよるものが全部売り切れでも
  • 理屈より心が知ってる
  • Don't think feel
  • ひとの思いは見えるものではなく、気づくものでした
  • パターンの祖先
  • 「無名の質」
    • カンバンの社内導入
    • 研修会場誘致
    • 会社見学ツアー
  • 孤軍奮闘しているあなたの相棒にカイゼンジャーニー

第2部 市谷さん

www.slideshare.net

  • ぼっち
    • 孤立 … 他から離れて一つだけ立っていること
    • 孤独 … 頼りになる人や心の通じ合う人がいなく、ひとりぼっちでさびしい
    • 孤高 … ただひとり高い境地
  • ここでの「ぼっち」周囲より先に気づいて動き始める状態
  • ぼっち曲線（笑）
    • 縦軸は問題の気づきやすさ
    • 横軸は多数->1人
  • 孤立は誤解されるので「ソロ活動」と呼ぼう
    • 音楽性の違い
    • 抱えている仮設（切り口）が特異であればソロよりに
  • これからはソロの時代！
    • 特異な観点、行動力が「組織を牽引する力」として必要とされる
    • 相対的に「際立った個」は貴重
  • 「所属」から「提供」の時代
    • 同時並行的に複数の企業に関与する時代
    • 人が持つ時間を何に配分するのかのポートフォリオの時代へ
  • 大きなる成果をあげるにはチームの力が必要
    • 落合陽一寝てない
    • どんなすごい人でもカレンダーはみんなと一緒
  • キャンプ場のカレー理論
    • 着火剤は自分自身
    • 燃料は周囲
    • かまどはよく燃やすためのお膳立て
    • カレーはWhy(目的)
    • 良い匂いがするともっと周囲を巻き込める
    • くべる燃料が湿っていたら火は燃えない
    • かまどは燃えても、燃料が集まらない？
    • まだカレーを食べたくないのかも？
  • 越境はドラクエと同じ。仲間とスキルが必要
    • 自分のジャーニーをどう描こう
  • 自分の身の程を知る
    • will
    • can
    • should
  • 自分で場を作る
    • まず自分が外で話す
    • 選択肢が増える
  • 越境すると見える風景が変わる
  • ハンガーフライトを企てるような人は結果的に早晩組織を去る
    • 経験が、行動を起こした人への唯一の報酬
    • やったらいろんなことがわかってしまう
    • わかったことから次どうするか考える、自分で判断する
    • バンバンやめたらいい
  • やめても行った先でもぼっちの旅は続く

第3部 座談会

はじめの一歩・プラクティス導入 / 巻き込み方・スクラム導入

  • 火がつかないひとはつかないよね
  • でも実は燃えそうなひとはいる、そこをどう引き込むか
    • ほんのいっぽの背中を押す
    • やってもいいかな？と迷ってる
  • ハードルを徹底的に下げる
    • 3行でいい
    • なんでもいい
  • 新人使うのいいよね
  • メリット、ビジョンを示すとまんなかのひとついてくる

巻き込みたいけど巻き込みにくい、どうする？

  • 仲間を見つける
    • ちょこっとだけ興味あるひと
    • change agent
  • カレー食べたくないひともいるしね、焼肉かな？
  • 遠くにいくならみんなで、はやくいくならひとりで
    • 巻き込まなくていいんじゃねえか

組織風土 / 続けるか辞めるか

  • 間をギュってする
    • えらいひとと平社員、間の中間管理職をギュってする
    • ユーザーと自分たち、間の営業をギュってする
  • 身の回りだけ巻き込んで、徐々に広げてく
    • 変わらないひとは変わらなくていいんじゃないかと思う

著者への質疑

執筆のモチベーション
  • 自分がしたことを意識的に形にしたほうがいい
アジャイル導入、プラクティスだとツール、エモーションだと宗教っぽくなる、どうしたらいい？
  • エモーショナル全開、気にしない
  • プラクティスはどうでもいい、問題ベース
  • 問題があって、プラクティスチャーンス
  • 宗教でいいんじゃない？
ぼっちでつらいときどうしたの
  • つらい毎日（笑）
  • コミュニティの仲間
  • お酒
  • (やる気の)角度を0にしない
    • 0から1にするのはきつい
    • 0になりそうなら止める、おいておく

closing session

なんでやってるの

  • "力を貸してくれる人や、後押ししてくれる人がいたら、どんなに心強いか"
  • カイゼン・ジャーニーを通じて、日本中の現場や仕事場にそれぞれの越境ストーリーが紡がれるのを後押ししたい
  • そして私はその物語を読みたい

AWS Route53を使ってムームードメインで取得したドメインをはてなブログPROの独自ドメインに設定する

Infrustructure

はじめに

AWS Route53を使ってムームードメインで取得したドメインをはてなブログPROの独自ドメインに設定する

しました。

メモがてら残しておきます。

ドメイン取得

どこでもいいですがドメインを取得しましょう。

別にまわしもんではないですが私はドメインをムームードメインで取得しています。

muumuu-domain.com

今回はchaspy.meというドメインを取得しました。

Route53

DNSはAWSのroute53で設定します。

chaspy.meとしてhosted zoneを作成します。

そしてCNAME recordを作成します。

f:id:take_she12:20180404000008p:plain

今回はサブドメインをblogとしたので、blog.chaspy.meに対して、valueはhatenablog.com.と設定します。

ドメインへname server設定

ドメイン側にname serverを設定します。上記の画像で伏せてある4つのnameserverをムームードメイン側で設定します。

f:id:take_she12:20180404000312p:plain

はてなブログで独自ドメイン設定

先ほどのCNAME設定通り、一度hatenablog.comに振り分けてから、はてなブログ側で各ドメインに振り分けるようですね。

f:id:take_she12:20180404050602p:plain

待つ

3時間ぐらいかかりました。以下、設定反映前後でのdigの結果。

⋊> ~ dig blog.chaspy.me

; <<>> DiG 9.8.3-P1 <<>> blog.chaspy.me
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2757
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;blog.chaspy.me.            IN  A

;; ANSWER SECTION:
blog.chaspy.me.     600 IN  A   166.78.103.6

;; AUTHORITY SECTION:
chaspy.me.      76585   IN  NS  ns1.muumuu-domain.com.
chaspy.me.      76585   IN  NS  ns2.muumuu-domain.com.

;; ADDITIONAL SECTION:
ns2.muumuu-domain.com.  170527  IN  A   157.7.104.99
ns1.muumuu-domain.com.  170527  IN  A   157.7.104.83

;; Query time: 265 msec
;; SERVER: 10.7.128.252#53(10.7.128.252)
;; WHEN: Tue Apr  3 20:32:57 2018
;; MSG SIZE  rcvd: 133

最初は初期設定であるムームードメインのネームサーバから返却されています。

⋊> ~ dig blog.chaspy.me                                                     20:32:57

; <<>> DiG 9.8.3-P1 <<>> blog.chaspy.me
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16143
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;blog.chaspy.me.            IN  A

;; ANSWER SECTION:
blog.chaspy.me.     300 IN  CNAME   hatenablog.com.
hatenablog.com.     3   IN  A   13.112.159.226
hatenablog.com.     3   IN  A   52.69.186.243

;; Query time: 286 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Tue Apr  3 22:40:57 2018
;; MSG SIZE  rcvd: 92

設定が反映されるとちゃんとhatenablog.comのアドレスが返却されています。

おわりに

ムームーDNSを使えばRoute53の料金を払う必要はないんですが、AWS少しでも使っておこうということで。（安いですし）

ひとまずドメイン1年取ってるのではてなブログPROも1年継続するつもりです。月700円をどう稼いだものか考えないとなー。

「言葉にできるは武器になる」を読んだ

本

はじめに

読んだ。

「言葉にできる」は武器になる。

「言葉にできる」は武器になる。

常に言語化の大切さを考えているひとなので。

とはいえ、この本の言いたいことは"はじめに"で言いつくされている。

  • 「どうやって伝わる言葉を生み出せるのか？」という問い
  • 「言葉をコミュニケーションの道具としてしか考えていないのですか？」と問い返し
  • 「言葉が意見を伝える道具ならば、まず、意見を育てる必要があるのではないか？」と提案する。
  • 「言葉は思考の上澄みに過ぎない」とし、
  • 「思考の深化なくして、言葉だけを成長させることはできない」と結論づけている。

いくら外に発せられる言葉の使い方を、テクニック的に学んだとして、自分自身の中で先立って存在する「内なる言葉」と向き合い、意見そのものを育てなければ伝わることにはならない、ということである。ごもっともすぎる。

実は人間って、実際に言葉に出す前に、自分の頭の中で考える（という名の、内なる言葉を発している）んですね。ひとりのときはそれが外に出て、独り言になってしまったりもします。

まずこの内なる言葉に気づくことが第一ステップ。そしてその言葉の解像度をあげるとおのずと意見が深化し、伝わる言葉を発することができる、というストーリーだ。さすが伝えるプロ、明瞭である。

本章は3つの章からできているので、振り返ってみる。

1. 「内なる言葉」と向き合う

まず前提として、「伝わった」「伝わってない」を4つのレベルに分けている。(p18〜20)

  1. 不理解・理解：そもそも話が伝わっていない、あるいは誤っている
  2. 理解：伝えたことが過不足なく伝わっている。ただし、理解"だけ"できる状態。
  3. 納得：相手が話したことを、頭で理解しただけでなく、腹落ちしている。「なるほど」
  4. 共感・共鳴：理解した上で、心が動かされ、自分の解釈も加わった状態

これを眺めると、2にすら至らない例も周囲を見ていると多いように感じる。。。この本ではやはりコピーライター、その文字、言葉を見て、実際に受け手に"共感"してもらい、行動に移すところまで範疇に入っているのだろう。

p20では「伝わり方は、人間性の評価につながる」とし、伝わらないことの恐ろしさを述べている。それだけ「言葉にできるは武器になる」逆をとれば「言葉にできないは戦えない」ことを示している。

外にしている言葉以外に、みんな「内なる言葉」を発しているが、それを意識できていない。これにより、「内なる言葉」が深くないから「外の言葉」にしても伝わらないことや、逆に「外の言葉」を受け取っても、「内なる言葉」として解釈できないため、実行できない、身にならない、といったことが起きる、

この点は、僕が読書をはじめてしばらくしてから感じたことと一致している。例えば本を読んでも、まずその本の内容や、要点を覚えていないのだ。覚えてないから、他者にどんな本だった？とおすすめすることができない。だから僕は本を読んだ後、必ずブログに書いて何らかの結論を出すようにしている。

これは記憶に残すために外部記憶に出力する、あるいは書き出すという行為で記憶力を高めるという側面ももちろんあるが、ブログに「書く」ことで、「自分の言葉」で書くことで、（この本でいう）「内なる言葉」として解釈できているからに他ならない。

「外の言葉」として書かれている本の「言葉」を、「内なる言葉」と向き合い、自分の意見を育て、深化させたものを、ブログという「外の言葉」に再度吐き出す。このプロセスによって自分の意見が育ち、伝わる言葉として発することができるようになる。

このことを昔は言語化できていなかったように思う。

また、起きたことに対して自分になぜ？を問い続けることも、内なる言葉のノックを繰り返して思考を深化させることに役立つ。あらゆる言葉に疑いを持つことはトレーニングになる。ぼくはこうやって言葉と向き合うのが大好きだ。

できるならそれを友人と話すのはもっと楽しい。

2. 正しく考えを深める「思考サイクル」

この章では「内なる言葉」の解像度をあげる（＝深化させる）ための具体的な方法が書かれている。すでに書いてしまった通り、アウトプットをして、それを連想させたり深化させたりして、横や縦に広げていったり、グループにしたりして、また問いを行って言葉にする、このサイクルを繰り返す。

ここはいろんな手法を紹介しているけど、とにかく「書き出すこと」と「書き出したものへの問い」を繰り返しなさい。と言っているだけである。なぜ書き出すことが大切かというと、人間、なかなか思っていないことは自分の意見として書きづらいものだからだと思う。書けるということは、書くことである"言葉"にするということは、少なくとも自分の中では（最初に紹介した4つのレベルでいう）納得、あるいは共感をしているということになる。これを繰り返すことで、当然他者にとってもそのレベルで伝わる言葉になっている可能性が高い。

ぼくはこれまで300記事以上ブログに記事を書いてきたが、これは間違いないと思う。ここ数年で言語化の能力は向上したと思う。

余談になるが、アウトプットすることで一度脳のメモリから落ちるので、インプットもできるようになるのも感覚的にある。これはかなり昔だが以下の記事に書いた。ブログを書き始めた直後だったかな。

take-she12.hatenablog.com

3. プロが行う「言葉にするプロセス」

最後のこの章は深化した言葉を、さらに相手を動かすに値する言葉にできるか、そのための作戦と、習うべき型が書かれている。

本文でも語られている通り、すでにエッセンスは2章までで完結していて、この章はどちらかというとつけたしのイメージ。

自分自身の気持ちや思いという素材を磨いていく第2章こそが重要出ると考える。そして、内なる言葉を磨いた上で、言葉にする方法について説明するのが、この3章の役割である(p147)

残りはそれこそ「外なる言葉」としてのテクニックであり、冒頭からしつこく言われているように、この3章だけ習得しても何の意味もない。また、コピーライティング的な視点も感じたので、ここでは項目を羅列するだけにとどめる。少なくとも今これを「わかった」ところですぐに活かすのは難しい。

日本語の「型」を知る

  1. たとえる(比喩・擬人)
  2. 繰り返す(反復)
  3. ギャップをつくる(対句)
  4. 言い切る(断定)
  5. 感じる言葉を使う(呼びかけ)(誇張・擬態)

言葉を生み出す「心構え」を持つ

  1. たった1人に伝わればいい(ターゲッティング)
  2. 常套句を排除する(自分の言葉を豊かにする)
  3. １文字でも減らす(先鋭化)
  4. きちんと書いて口にする(リズムの重要性)
  5. 動詞にこだわる(文章に躍動感を持たせる)
  6. 新しい文脈をつくる(意味の発明)
  7. 似て非なる言葉を区別する(意味の解像度をあげる)

おわりに

自分自身がなんとなく感じていたことを見事に言語化していて、自分自身の言語化に対する「内なる言葉」をこうやって深化させて意見としてまとめることができた。

「うまく言葉にできない」ひとが、まず「内なる言葉がある」ことを知り、まず第一歩として何でもいいからアウトプットするきっかけとして、おすすめできる良い本だと思います。

「夏フェス革命」を読んだ

音楽 本

はじめに

読んだ。

夏フェス革命 ー音楽が変わる、社会が変わるー

夏フェス革命 ー音楽が変わる、社会が変わるー

レジーさんは以前からTwitterでフォローしているのと、個人的にも夏フェスって音楽だけ楽しむ感じではなくなってきてるよね、という、本書の主張の1つを感じていたので、購入。

読書メーターには記録したけど、あらためて雑多に感想をブログに書き留めておく。

bookmeter.com

夏フェスがどのように変わっていったかを、客観データのみ使って分析している本。SNSによる可視化と、顧客の価値変更に主催者側も迎合する"協奏"はなるほどその通りと思いました。個人的にはより主催側につっこんで（手を組んで）本当のデータを使っての分析か、最後の章の未来のフェス、あるいは音楽がどう変わっていくかの予測がもっと聞きたかったなと思いました。

4つの章で構成されている。章ごとに振り返っていこう。

1章 フェスは「協奏」によって拡大した

すべての章に登場しているように、本書では「協奏」が大きなキーワードとなっている。ここで本書より「協奏のサイクル」の定義を引用しよう。

  1. 商品/サービスの提供
  2. ユーザーによる顕在化していない価値への着目
  3. ユーザー起点での新たな遊び方の創出(異なる概念との組み合わせ含む)
  4. 企業が当初想定していたクラスターとは異なる層によるファンベースの拡大
  5. 企業による新たなユーザー層・楽しみ方の取り込みとそれに合わせたリポジショニング (p64)

フェスは自由だ。ユーザー（参加者）は自由に、自分の楽しさを見つけることができる。

SNS時代において、そのユーザーの声が可視化されやすい状況になり、主催者側がその声や、新たな楽しみ方を容易に確認することができる。その可視化によって、当初想定していなかったユーザーが流入し、また新たな楽しみ方が可視化される。

このサイクルの後、可視化された楽しみ方に合わせて主催者は別の価値を提示する。このサイクルを本書では「協奏のサイクル」と呼んでいる。

当初はコアな音楽ファンだけが知っている、過酷なフェスが、今や音楽を必ずしも第一と考えていない層も気軽に楽しめる、快適なフェスへと変遷していることをうまく説明していると思う。

2章 ケーススタディ：「協奏」視点で見るロック・イン・ジャパンの歴史

本章ではたくさんあるフェスの中から、「ロック・イン・ジャパンフェス」に着目、どのような歴史をたどって変化してきたかを解説している。

ヒットチャートとしての側面、出演者の特色（ロックの定義）、快適さへの追求など、一度ロッキンに参加したことがあるひとなら納得するだろう。

ただ個人的にはGRASS STAGEに立つアーティストの分類がいまいちしっくりこなかった。MECEではないというか、曖昧というか。。。

  1. 超大物 ... 桑田佳祐、B'z、ゆず、ポルノグラフィティ
  2. 幅広く知られており、特に若年層から強い支持を受けているアーティスト ... Perfume、ももいろクローバーZ、欅坂46、きゃりーぱみゅぱみゅ、miwa、back number、サカナクション、RADWIMPS、Suchmos
  3. このフェスの功労者 ... Dragon Ash、エレファントカシマシ
  4. 今のロックシーン・フェスシーンにおける地位を確立している存在 ... the HIATUS、MONOEYES、10-FEET、マキシマムザホルモン
  5. 今のロックシーン・フェスシーンでの足場を固めつつある存在 ... KANA-BOON、[Alexandros]、WANIMA

(p101-103)

面白いのはロッキング・オン創刊時の「読者投稿」から作り上げる、という性質から今のフェスの「協奏」はDNAとしてあったのでは、という分析。

徹底した顧客視点、顧客体験を第一にする企業姿勢が関係しているというのは確かにそうかもしれないと思った。

3章 フェスにおける「協奏」の背景

冒頭で述べたが、フェスの変遷、「協奏」の背景としての社会の変化にフォーカスした章。具体的にはSNS(mixi)の流行、そしてTwitterが情報インフラとして機能しはじめたという分析もごもっとも。ファッション誌や漫画（モテキ）などの影響で社会的なフェスの価値観の変せんを追いかけている。客観情報のみでよくまとめ、分析できていると思う。

4章 「協奏」の先にあるもの

3章の最後で、以下のような挑戦が書かれている。

フェスが「時代を先取りするメディア」だとすると、現在のフェスにはこの先の時代のあり方がすでに投影されている可能性がある。そして、そんな「社会を見通す力」を持ち始めたフェスは、音楽業界のあり方にも当然影響を及ぼしている。(p203)

この章では2章でも触れたフェスがヒットチャート化していることや、フェスを中心にリリーススケジュールを組むことからフェスが音楽の中心であるという指摘があるが、「この先の時代のあり方が投影されている」ことへの解答にはなっていない気がする。

時代の変化があって、それにフェスが追随するのが「協奏」だとするならば、いち早く追随はされるかもしれないが、未来が投影されている論理にはならない気がするが、どうだろう。傾向を見て予測することはできそうだ。

今後の技術発展を鑑みると、「音楽だけを聴きに来ている」層は自宅からVR /5G等の技術を用いて自宅から1人で楽しみ、集団で一体感を楽しむ層や、音楽以外の快適さを目的にくる層だけが現地に来るようになると予想しており、それは正しいと思う。

以下は私見だが、フェスは確かにヒットチャート的な役割を果たしていて、かなり日本の音楽の中心となっているのはまぎれもない事実だが、個人的にはまだまだフェスは多様化していくんじゃないかと思う。今後、日本でもサブスクリプション型音楽サービス(聴き放題)が増えていくはず。そうなれば1つのアーティストを熱心に追いかけるというより、シーン、感情、季節、テーマ、、、様々な文脈に適した音楽が求められるようになり、ユーザーの需要も多様化していくだろう。

フェスが「協奏のサイクル」で変化していくことが今後も続くのであれば、現在の大手フェスで起こっている"一体感"や"レジャー"としての需要に応えるフェスもあれば、そのような一体感が不要なユーザーに対して、例えばヒットチャートに載らないようなニッチな音楽やジャンルを提供するフェスもあれば、例えば衣食住に徹底してこだわったフェスも出てくるだろう。

いずれにしても、音楽の多様化、ユーザーの好みの多様化にともなって、これまでの「音楽フェス」という、アーティストが演奏して、それを見に行くという形はどんどん輪郭を崩し、他の文化と融合していくんじゃないかと思う。音楽が主役でいられる時代が終わってしまうのは、音楽好きとしては少し寂しいけれど。

おわりに

夏フェスの変化に対して、多様な切り口で分析していて楽しく読むことができた。

個人的には年に1回フェスに行くか行かないかになってしまったし、好きな音楽を好きなだけ見つつ、酒を飲むことを楽しんでいる派なので、音楽というよりはレジャーとして楽しんでいる。

この変化は良い悪いじゃなく、おのおのが自分に合ったフェスや音楽を探して、それこそ"自由"に楽しんでいられればそれでいいと思う。

「プロダクションレディマイクロサービス」を読んだ

Infrustructure

はじめに

読んだ。

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

SRE本を読んだあとぐらいに発売されて、買ってはいたんですがなかなか読めてなかった。なかなかコンパクトなのでわりとすぐ読み終えた。しかしいい本です。

この本はマイクロサービスを本番環境に提供するための準備、"本番対応(Production Ready)"のためのガイドです。本番対応のために何が必要なのか？体型的にまとめっています。

順に復習しておきます。

1章 マイクロサービス

この章ではマイクロサービスはどのようなもので、モノリシックなアプリケーションをどのようにマイクロサービスするかについて説明されています。なかでも興味深かったのは1.4 組織的な課題ですね。

1.4.1 逆コンウェイの法則

コンウェイの法則、"システムのアーキテクチャは、コミュニケーションと企業の組織構造によって決まる(p26)"というものがありますが、その逆、すなわち"企業の組織構造はシステムのアーキテクチャによって決まる"ということもまた真です。(これを逆コンウェイの法則と呼ぶ)

当然、マイクロサービスアーキテクチャでサービスを作る場合は、小さなチームがたくさんできることになります。しかも、マイクロサービスである前提から、各組織は単一(あるいは狭い範囲の)責任を持ち、他のチームとは独立してしまうことになります。

もちろん、インフラストラクチャチームと(マイクロな)開発チームも別ですし、仮にDevとOpsが別のチームであれば、Opsも別のチームとなるでしょう。

以下は本書で言及されているものではありませんが、僕はSREこそが開発、インフラ、運用の橋渡しとなる存在になるべきだと思います。協力するのはもちろんですが、SREは技術的な運用、リリース、開発の解決に加えて、サービス全体の信頼性のために、各チームに対して仕組みを提供する、そういう役割もあると思っています。技術的解決以外にも、組織/人間/チームに対するアプローチも必要な、大切な役割だと思います。

1.4.2 技術的スプロール

スプロール現象が、"都市が無秩序に拡大していくこと"であるので、技術的スプロールは、拡大していく組織が、(使用技術に関して)無秩序になってしまうさまでしょう。

スプロール現象 - Wikipedia

マイクロサービスの性質上、各チームは好きな言語を使ってもいいでしょうし、好きなツールを使ってもいいでしょう。これはマイクロサービスの利点としてよく語られます。

しかし、これまたサービス全体で見たときに不利益が出てきます。（極端な話)100のマイクロサービス、100種類の別の言語を使っていれば、組織間の人材流動は容易ではなくなってしまいますし、メンテナンスコストもあがってくる。

いろんな会社の方と話しても、やっぱり使用言語は統一させたいと聞きますね。メイン言語と、サブ言語の2つぐらいにするところが多いようです。

上記いずれも、マイクロサービスで組織が分断されたとき、1サービスとして考えると課題になってくる点だと思います。

2章 本番対応

この章では今後の章で出てくる5つの観点の説明と、それを標準化することの必要性を説いています。

開発者は反対するかもしれませんが、サービス全体で標準化を進め、サイトの信頼性を高めていく必要があります。

3章 安定性と信頼性

この章ではマイクロサービスの安定性と信頼性が書かれていますが、何も運用中に限った話ばかりではありません。

CI/CDやDevOpsまわりで語られることが多い開発サイクル(ブランチ戦略や各種テスト、自動化)からはじまり、本番へのデプロイパイプライン(カナリアデプロイ、ステージング環境)、そして各マイクロサービスの依存関係の追跡(おそらく後のドキュメント化のところでされるんでしょう)。あとは障害検出(健全性チェック)を備えること(そして健全ではない場合はトラフィックを正式にルーティングしないこと)、APIに関してはユーザに対して非推奨と廃止を通告することですね。よくdeprecated、と書かれてしばらく様子見されますよね。

開発環境や本番デプロイまわりの整備はまずやるとして、個人的に一番難しいのは依存関係だと思います。私もマイクロサービスの開発をしていて、普段は自分のサービスだけに閉じたことだけを気にしていればいいですが、たちまち自分のサービスが停止しないといけないときに、その追跡調査に非常に苦労しました。何せ依存関係はどこにもドキュメント化されておらず、各チームにヒアリングした結果を自分自身でまとめなければなりませんでした。

安定性、信頼性のために重要なことだと思います。

4章 スケーラビリティとパフォーマンス

この章で興味があったのは成長の判断基準に"質"と"量"を区別している点。

RPS(Request Per Sec)といった性能基準は量的な判断基準。そうではなくビジネスサイドから見たユーザ数、契約数といったものを質的な判断基準と呼んでいます。マイクロサービスは様々な依存関係を含んでいるので、大きいものであれば複雑系とも言えるぐらい、内部の単一性能だけを見て評価することは難しいんでしょう。

重要かつ難しいのはキャパシティプランニングですよね。ハードウェア調達ってなかなか稟議降りず、結果キャパシティオーバーなんてことも。

スケーラブルで、同時平衡性にすぐれる言語、もしくはそういったフレームワークをサポートできる言語かという点も興味深いですね。(4.8.1 プログラミング言語の限界)

5章 耐障害性と大惨事対応

SPOF(単一障害点)を取り除くこと、障害は必ず発生するので、各レイヤー(ハードウェア、ソフトウェア、依存関係、マイクロサービス内部)での起こりうる障害の例、テスト(特に負荷テストをしておくこと)、そしてnetflixで有名なChaosテスト。そして障害発生時の対処についてまとまっています。

これはかなり大事な本番対応ですね。ほんと起きてからじゃ遅いからな、、、

www.publickey1.jp

6章 監視

監視に必要な主要なメトリック、ロギングの方法や注意点、一目で状況がわかるダッシュボード、そして監視した結果あげるアラート(必ずすべきアクションが定義されていること)、オンコールローテーション。

言うまでもなく重要な本番対応です。

7章 ドキュメントと組織的な理解

ドキュメントは僕がもっとも強い関心を持つ部分です。

冒頭のカラマーゾフの兄弟を引用している点がいいですね。"いつでも葱を与えよ(p148)"。

すべてのマイクロサービスに包括的で最新の状態に合わせて更新されたドキュメントを用意することの重要性は、いくら強調しても足りません。

なぜか開発者ってドキュメントに関心ないですよね、、、僕のまわりだけでしょうか。

ドキュメントがないとひとに聞かないといけない、聞く方もしんどいし聞かれるほうもしんどい、コミュニケーションコストが増大しているのになぜ解決しようとしないんだろう、と思ったこともありますが、ドキュメントもスキルの一種なんですよね。簡単ではない。

書かれるべきドキュメント。

  • マイクロサービスの説明
  • アーキテクチャ図
  • 連絡先とオンコール情報
  • 重要な情報へのリンク
  • オンボーディング/開発ガイド
  • リクエストフロー、エンドポイント、依存関係
  • オンコールランブック
  • FAQ

関係するあらゆるひとへ葱を与えましょう、そのためにドキュメントは重要です。

おわりに

本書はマイクロサービス・アーキテクチャを採用したサービスを本番にデプロイするために必要な準備をコンパクトに、5つの観点でまとまっています。どれも欠かすことない、重要な点と言えると思います。

マイクロサービスは開発者にとっては自由だけども、ここで述べられた最低限の標準化だけは守ろうな、そしてみんな自分のことだけ関心を向けるんじゃなく、1サービスの信頼性向上のために協力しようね(葱を与えようね)という感じです。

付録にはチェックリストがあり、ここだけ見て本番対応ができているかどうか確認することができます。よい！

今後自分がサービスを作るときにこの本をまた見返したいです。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Sre in Practice

Sre in Practice

「Principles of Container-based Application Design」読んだ

Infrustructure

はじめに

読みました。

blog.kubernetes.io

The Twelve-Factor Appのように、ベストプラクティスというものは知っておくと役に立ちますよね。昨今はコンテナオーケストレーションを使うのが当たり前のようになってくるでしょうから、押さえておきましょう。

12factor.net

Principles of Container-based Application Design

コンテナベースアプリケーション設計の原則

It’s possible nowadays to put almost any application in a container and run it.

最近ではほとんどのアプリケーションがコンテナ上に配置され、動かすことが可能です。

Creating cloud-native applications, however—containerized applications that are automated and orchestrated effectively by a cloud-native platform such as Kubernetes—requires additional effort.

しかし、Kuberenetesのような、クラウドネイティブプラットフォームによって自動配備されるコンテナ化されたアプリケーションを作るときはさらなる努力が必要です。

Cloud-native applications anticipate failure; they run and scale reliably even when their infrastructure experiences outages.

クラウドネイティブアプリケーションは障害を予想します。自身のインフラストラクチャが停止しても確実に実行/拡張します。

To offer such capabilities, cloud-native platforms like Kubernetes impose a set of contracts and constraints on applications.

このような効果を提供するために、kubernetesのようなクラウドネイティブプラットフォームはアプリケーションに一連の制約と契約を課します。

These contracts ensure that applications they run conform to certain constraints and allow the platform to automate application management.

これらの契約は実行するアプリケーションがプラットフォームにアプリケーション管理を自動化させ、制約に適合させることを保証します。

seven principles

7つの原則

buildtimeとruntimeという2つの領域にわけられます。構築時の原則と実行時の原則かな。

Build time

  • Single Concern: Each container addresses a single concern and does it well.

単一の関心：それぞれのコンテナは1つのことをうまくやる（UNIX哲学ですね）

  • Self-Containment: A container relies only on the presence of the Linux kernel. Additional libraries are added when the container is built.

自己完結：コンテナはLinux kernelのみに依存します。追加のライブラリはビルド時に追加されます。

  • Image Immutability: Containerized applications are meant to be immutable, and once built are not expected to change between different environments.

不変イメージ：コンテナアプリケーションは不変であることを意味し、1度ビルドされると異なる環境間での変更は期待されません。

Runtime

  • High Observability: Every container must implement all necessary APIs to help the platform observe and manage the application in the best way possible.

高い可観測性：すべてのコンテナは可能な限りプラットフォームがアプリケーションを管理/観測するために必要なAPIを実装すべきです。

  • Lifecycle Conformance: A container must have a way to read events coming from the platform and conform by reacting to those events.

ライフルサイクルの適合：コンテナはプラットフォームからのイベントを読み取り、イベントに反応して適合するための手段を持つ必要があります。

  • Process Disposability: Containerized applications must be as ephemeral as possible and ready to be replaced by another container instance at any point in time.

プロセス廃棄性：コンテナアプリケーションは可能な限り短命であり、任意に他のコンテナインスタンスを置き換え可能であるべきです。

  • Runtime Confinement: Every container must declare its resource requirements and restrict resource use to the requirements indicated.

実行時制限：すべてのコンテナはリソース要件を宣言し、指定された要件に制約されるべきです。

The build time principles ensure that containers have the right granularity, consistency, and structure in place.

構築時原則はコンテナが正しい粒度、一貫性、構成を確保できていることを保証します。

The runtime principles dictate what functionalities must be implemented in order for containerized applications to possess cloud-native function.

実行時原則はコンテナアプリケーションがクラウドネイティブ機能を所有するために実装されるべき機能を列挙しました。

Adhering to these principles helps ensure that your applications are suitable for automation in Kubernetes.

これらの原則に従うことで、アプリケーションがkubernetesによって自動的に最適化されることを保証します。

おわりに

kubernetesのような自己修復機能を備えたコンテナプラットフォームの上でうまく動くために必要な原則と、コンテナ構築時の原則と、実行時の原則に分けて説明されました。

構築時の原則は単一コンテナであれそもそも必要なことのように感じました。kubernetesで動かすために大事なのは後者の実行時原則ですが、これをどう"適合"させるのか、というのはkubernetesを学ばないとちょっとわからないですね。

今後はkubernetesガンガン触っていこうと思います。

Cloud Native Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic Environment

Cloud Native Infrastructure: Patterns for Scalable Infrastructure and Applications in a Dynamic Environment

読んでないのですが、Cloud Nativeという言葉がでてきたのでこの本も関係あるかな？

入門 Kubernetes (オライリー・ジャパン)

入門 Kubernetes (オライリー・ジャパン)

これは読む予定。

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

これは名著。

デブサミ2018に参加した

Programming

はじめに

参加しました。

event.shoeisha.jp

あまりのひとの多さに参加したのは1日目のみ。

見たセッションや気になったセッションをまとめておきます。

【15-D-1】技術選定の審美眼

若干遅れて入りました。以下の記事がよくまとまってますね。

www.publickey1.jp

時間が余ったら話そうとしていたものも聞きたかったですね。

togetter.com

speakerdeck.com

  • 長く変わらない技術には強い抽象という共通点がある。
  • 技術には螺旋があって各周回ごとに差がある

結局何を持って審美眼を養えばいいのか。

今の時代が、前の時代と何が違うのかを見抜くこと。(螺旋の差)、変わらないものには強い抽象がある。今ホットな技術にそれがあるか？ということですね。

【15-E-2】Googleのネットワーク開発に見るITエンジニアリングの本質

JTF2017で発表されてるものと同じようだったので、すでに聞いていたので抜けちゃいました。

Googleのテクノロジーから見えてくるITエンジニアリングの発想「ITエンジニアの本質」を考える～July Tech Festa 2017 基調講演 (1/3)：CodeZine（コードジン）

【15-B-L】Spinnakerで実現するデプロイの自動化

登壇資料はアップされてないんですかね？残念。自分のメモ貼ってみる。

アップされてました！

www.slideshare.net

  • どのアプリでも同じデプロイがしたい => API差異を吸収する必要があった
  • pipeline
    • bake (AMIイメージ作成) (中ではpackerが動いている)
    • deploy
    • ...
  • サポートプロバイダ
  • 検証した
    • staging) github -> jenkins -> spinaker -> slack通知 -> 承認
      • deploy okのslackメッセージは変更できない
      • spinekerからサーバ状態が一目でわかる
    • production) blue/green deployment -> 切り戻し
  • メリット
    • あると便利なデプロイ手法を網羅(blue/greenのこと)
    • 1つのspinekerの画面だけで進捗状況を確認できる
  • デメリット
    • 若干動作不安定
    • AWSだとサブネット名が決まった名前しかつけられない
    • AWSだとセキュリティグループ送信元/送信先IPアドレスを指定できない？
      • じゃあどうするの？AWSコンソール上で作るしかない
  • まとめ
    • spinekerのトラシュ苦労(spinekerがマイクロサービスで、追いかけるのが大変)
    • 発展途上のOSS、まだまだこれから。
  • 疑問
    • どこまで自分たちで設定して、どこまでspinekerがやってくれる？
      • 抽象化された設定をかけばどのプロバイダでもできる？
      • terraformのGUIでリッチにしたversion？
    • この例は文字表示させるだけのweb appだったけど、どんなappが向いてる/向いてないはある？
    • マルチクラウド対応
      • 移行は何もせずできる？
      • 複数をまたがってデプロイできる？

興味はわきましたが、terraformのGUI＋リッチな感じ？といったイメージでした。使ってみたいですね。

【15-D-3】人生20年説・好きな事と得意な事を仕事にしていけるかも知れないエンジニア人生のヒント

google中井さんのこちらの発表は聞きました。

togetter.com

メモをはっておく

  • 裏話
    • 個人枠できた
    • AMはgoogleのスポンサー枠、余ってたから喋ってと言われてきた
  • 1971大阪生まれ->京都大学修士課程(物理)->株式会社アップ->IBM->レッドハット->グーグルクラウドジャパン
  • 人生20年説？
    • 森つよし
    • 長い人生1つのことだけやれなくない？人生20年と割り切って、20年が4回あると思おう
  • 中井さんの場合は人生5年説
    • 5年やると一通りわかったしもういいかな感
    • 変化が激しいIT業界とはいえ、別領域にいくのはチャレンジング
  • キャリアアップを支えた（る）技術
    • 転機になるイベントがあった
      • 海外カンファレンス
      • 書籍出版
    • IBM時代に編集者に声かけられた
      • 流行りのもの書いても長く読まれない
      • 自分の得意分野、地に足ついたような分野のほうがいいよ
      • 「自分の経験を読者に伝えてください」「本を書くために勉強しなくていい」
    • 書籍執筆を支えた経験
      • 大学院->予備校講師
        • 理解すると教えたくなる
  • キャリアアップを支えた技術(まとめ)
    • 複数の得意分野を併せ持つことで「自分だけの価値」を生み出してみましょう
    • 「今の自分には不要かもしれないけれど、面白そう」と思えるトピックを見つけて学び続けることをお勧めします
    • 変化の激しいIT業界で「長く効く」のはとにかく原理原則を学ぶこと
      • 全然関係ない分野でも根本が同じ、とかはよくある
  • 疑問k
  • これまで身につけた技術
    • 最先端物理はある程度やりきった、博士課程(生み出す)のはいいかなあ
      • 大学院時代にUnixシステム管理は並列でやってた
    • 予備校講師は別にやりたいわけではなかった
      • 就活の仕方よくわからなくて、マイナビ登録してレスがきて物理なら教えられるかなーで採用
      • アプリシステム開発を並列してやってた
        • 先生用の成績管理システム作った
      • 毎年5年間同じこと教えてるとやりきった感(もういいかな)
    • 大手ITベンダいろんあところに応募して、IBMだけから返事きた
      • 人手少なかったらしい
      • IBM時代もLinux勉強してた
    • RedHatへ
      • Linuxのプリセールスしてたけど、IBMでは物足りなかった
      • Linuxより一段上のレイヤーに目をつけていた
      • RedHatのクラウドビジネス立ち上げますと面接で言った
    • Google Cloud Japanへ
  • 感想
    • 同期に原理原則を学ぶやついるけどやっぱり理解のスピードが速いからその通りなんだろうなと思う
    • ちょうど中井さんは次に流行りそうなことを趣味でやってたわけだけど、誰もがそういうものを持ってないだろうなぁ

【15-C-4】多様なビジネスドメイン、サービスフェーズが混在する中での組織戦略と技術戦略

speakerdeck.com

やってきたことが情報量が多くいまいちわかりづらかったんですが、組織的なアプローチで解消したんでしょうが。

ボトムアップで改善や挑戦があがるのはとても良い組織ですが、リクルートほど大きい組織だと当然難しいところもでるはずで、もっと話を聞いてみたいと思いました。

【15-D-6】GitHubの開発フローにおけるサポートエンジニアの役割

個人的に1番聞いてよかった公演。

speakerdeck.com

  • 自己紹介
    • dblmkt
    • ykst
    • 入門Kubernetes翻訳
  • GitHub is how people build software
  • GitHubを動かす技術
  • GitHubでの開発の流れ
    • GitHub上で完結している
    • GitHub-flow
    • デプロイしてからマージ(マージしてからデプロイではない)
      • ChatOps
      • masterは常にデプロイ可能な状態
      • hubotでデプロイキュー管理
      • HAYSTACKというところにすべてのエラーがくるのでデプロイ後はここを見る
  • GitHub Enterprise Support
    • 仮想マシンにのったgithub.com + 管理機能
    • github.comの問い合わせ
      • git/githubの使い方
      • 間違って消したリポジトリの復旧依頼
      • バグ報告、機能改善要望
    • github enterpriseの問い合わせ
      • 管理者からの問い合わせが多い
        • ユーザアクションの管理
        • レプリケーションの設定方法
        • パフォーマンス問題の解決方法
          • インフラよりの知識が求められる
        • 管理機能のバグ報告、機能改善要望
    • githubのサポート
      • レベルわけしない
      • Tier1,2,3...とわけない
    • 全世界をタイムゾーンで3つにわけで、8時間ずつ、トータル24時間サポートできるようにしている
      • 日本語サポート、3名
  • サポートエンジニアの開発への関わり方
    • バグ報告
      • 全体の3割がサポートからのissue
    • 修正の必要に迫られる(開発に手があいてるひとがいない)
    • 日本にGithub enterprise開発者がいない
      • APACリージョンにはいるけど、数が少ない
      • 時差によるコミュニケーションのオーバーヘッド
      • マルチバイト文字の扱い
    • 開発したい気持ちがある
      • サポートだけだと新しいことを覚えにくい(お客様対応だけしてると)
      • 主業務はサポートだけど、開発に関わるのは推奨してる
      • 結果、PRも4割がサポートエンジニアから（すごい！）
    • サポートエンジニアはお客様のSRE
      • SREは自社サービス
      • サポートエンジニアはお客様のサービスの信頼性を担保(SRE)
    • SREは50%以上開発に時間を充てるべき
      • サポートエンジニアも同じ？
    • サポートエンジニアも開発に積極的に関わろう
    • 開発したいエンジニアのキャリアパスとしてもあり
  • 登壇者について
    • 前職はインフラエンジニアだった
    • 今の職種になってからコード触るようになった、
    • 開発もしたいけどお客様とのやりとりもしたいって人にもオススメ
    • テクニカルであるけど、お客様とやりとりがある
  • おわりに
    • 日本語サポートあるよ
    • 日本語ドキュメントもうすぐでるよ(翻訳中)
    • 日本語Webサイト3月にでるよ
    • Sattelite Tokyo開催決定！3月下旬に情報公開されます
  • We are hiring

入門kubernetes買うし、githubで働きたいです！

おわりに

とにかくひとが多くて、移動もストレスだし、はやくいかないと座れないのはしんどいですね。個人的にはもう少しゆとりのあるイベントのほうが好みです。

公演は聞けなかったのですが、カイゼンジャーニーは購入しました。たぶん作者のひとが通りすがりに「その本いいよ」って言ってくれたのが面白かったです。

デブサミの公演はそれなりに厳選されたひとが発表していると思うので来年もどちらかは参加したいしできるなら登壇したいですね。