ツナワタリマイライフ

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

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

はじめに

読んだ。

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

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

レジーさんは以前から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、サカナクションRADWIMPSSuchmos
  3. このフェスの功労者 ... Dragon Ashエレファントカシマシ
  4. 今のロックシーン・フェスシーンにおける地位を確立している存在 ... the HIATUSMONOEYES10-FEETマキシマムザホルモン
  5. 今のロックシーン・フェスシーンでの足場を固めつつある存在 ... KANA-BOON、[Alexandros]、WANIMA

(p101-103)

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

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

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

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

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

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

はじめに

読んだ。

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

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

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」読んだ

はじめに

読みました。

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に参加した

はじめに

参加しました。

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で働きたいです!

おわりに

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

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

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

「GitLab実践ガイド」を読んだ

はじめに

読んだ。

GitLab実践ガイド (impress top gear)

GitLab実践ガイド (impress top gear)

Git大好きエンジニアで、もちろんGitLabも仕事で愛用してますし、もう社内のGitLabなしでは僕は仕事できません(笑) 仕事のすべてをGitLabにおいてるので。。。まぁlocalでは作業できるけど。。。

そんなGitLab大好きマン、この書籍出るっていうのでまぁまず買うよね。

軽く内容をさらいつつ、気になる点はgitlab.comで試してみる。

第1章 GitLabが目指す開発スタイル

まずはプロダクトの思想から。大事ですよね。

DevOpsの考えを前提とした上で、ConvDev(Conversational Development)というスタイルを推奨しています。

ConvDevは、開発プロセスフロー全体において、グループメンバー同士のコミュニケーションを重視してアプリケーション開発を行う自然な開発スタイルです。具体的には、開発者は一貫性のある方法で、開発プロセスの一つひとつを追跡することが求められます。ConvDevでは、アイデアから展開までのコラボレーションと知識共有を促進することで、開発ライフサイクルを加速することを目指しています。

わかりづらいですが、DevOpsを支えるためには、コミュニケーションの促進だったり、課題の見える化が必要で、それを支える機能を取り込もうという思想ですね。

GitHubGitHub is how people build softwareと同じですね。GitHubはソフトウェア開発そのものだ、というのと似ていて、GitLabはソフトウェア開発で必要になるコラボレーションまで含めて支援していくという思想です。

プロダクト/サービスをどう変えていくか、どう作るか、どいったアイデアを生み、それを開発に落とし込み、さらにそれを実際にプロダクト/サービスに反映する、このサイクルを促進する仕組みを持ち合わせています。

CI/CDをサポートしている、といえば味気ないですが、単なるテストやビルド、デプロイの自動化ではなく、継続的なプロダクト、ビジネスの改善という広い視野を持っている、といったところでしょうか。

第2章 GitLabの導入

内部コンポーネントの解説があるのはいいですね。いざ自分がオンプレで運用するようになったときのトラブルシューティングに役立ちそうです。今回は流し読みしました。

あとはインストール、セットアップ方法なので、ここも適宜必要なときに参照すればいいかなと思います。すでに導入済みなので流し読みしました。

にしてもGitLabのomnibusパッケージはinstallもupdateもすっごい楽ですね。すばらしい。最近8系から10系にupgradeしましたが、postgresのupgradeが必要だったぐらいで、あとはなんなくできました。

第3章 GitLabを使ってみよう

この章はGitLabの使い方で、自分は知ってるので流し読み。ユーザ/グループの概念の説明、登録方法。あとは基本的なGitの使い方。本当にはじめて導入するひとに対してやさしいですね。

Gitの概念、使い方は本当にわかりやすく、実際のコマンド含めコンパクトにまとまっているので初心者向けの説明に重宝しそうです。活用します。

第4章 開発ワークフロー

1章で述べたビジネス解決のためのアイデア共有のための仕組み紹介です。まずはslackクローンのchatシステムであるmattermost。社内ではオンプレにmattemrostとgitlabそれぞれ展開してますが、gitlabに付属してるmattermostは使ったことありませんでした。連携が若干楽になったりするのかな?とりあえず今の所は自分で立てているgitlabでmattermostは使わないと思います。

社内共有のgitlabでmattermostが使えるかどうかは確認したいところ。

あとはissueを使ってチケットトラッキング的なことができるので、redmineいらないんですよね。カンバンボードもついていて、commitやMRと紐づけられるのが本当に便利です。

リソースの参照で、#がissueなのは知ってたけど、!はMR、あとはマイルストーンスニペットもあるんですね。知らなかった。

あとはブランチ戦略ですね。GitLab-flowが紹介されています。

第5章 継続的インテグレーション

この章はgitlab-ci.ymでコントロールできるCI設定と、そのためのgitlabci-runnerについての説明ですね。ここも既知だったので読み飛ばし。gitlabの最大の利点はここにあると個人的には思ってます。githubだとcircleciだtravisciだ外部サービスを使わなきゃいけないので。gitlab-ciは本当によくできている。

Executerはdocker一択かなぁと思います。

第6章 継続的デプロイ

ここで扱う内容は今までやったことなかったんですが、deploy先はどこになるかというと、コンテナでdeployした環境になるんですね。

この本で見る限りは、まぁintegration testはコンテナを使ってgitlabでテストすることはまぁわかるんですが、本番deployが例えばAWS上とか、別の区域のクラウド上とかそういう場合はどうするのかな?っていうのが疑問です。

runnerを本番とステージングでわけて、本番構築用の環境からrunnerが反応するようにしておけばどこのクラウドだろうができるって感じですかね。docker(コンテナ)っていう前提ですが。

本番がgitlabとIPでreachするかどうかが重要ですね。

例えば僕が持ってる静的webサイトの本番deployはcircle-ci上でS3とsyncさせてやってます。本番環境にrunnerを動かしておいて、コンテナdeployできる環境があればgitlab-ci.ymlの定義で簡単にできそうですが、クラウドが当たり前の現在で、例えばECSとかと連携が楽にできるのかな?ってのは気になりました。ECS使ったことないのでなんともですが。

Review appsは使いどころというか、条件がいまいちわかりませんでした。本番deployをmanualにして、stagingで状態を確認してからdeployってのはとてもいいと思いました。

最後、container registry付属ってのもとてもいいですね。docker-hubに出せないイメージもあるでしょうから、imageをbuild、登録して、それを展開してdeployしてテストするということができる。container registryは使ったことないので自分の環境で有効にしてみようと思います。

第7章 フィードバック

deployしたあとのパフォーマンス計測としてprometheusが内蔵されています。すごいな。

そもそもgitlabサーバそのもののメトリクスを収集できるようになるのはまぁわかるのですが、やっぱりdeployしたアプリケーションをどうやって監視するのかがわかりませんでした。

本書p243でもGitLabのOmnibusパッケージに付属しているPrometheusは、デフォルトでgitLabをモニタリングするためのメトリクスが設定されているため、アプリケーションのパドーマンスモニタリングに利用するのはおすすめできません。ここでは別途Prometheusを導入する方法を紹介しますって書いてあってなんだそれってなりました。

また、Cycle Analyticsでは各ステージの時間を計測できます。これも使ったことないですね。issueやMRの時間も計測されるみたいなので、GitLab Flowのブランチ戦略にしたがって運用する必要がありそうです。

issueが立ち上げられてから本番deployまでのそれぞれの時間が図れるというのだから、これはすばらしいフィードバックですよね。継続的改善のために必要な指標が簡単に得られる。

また、現在ベータ版で、10系から導入されたAuto DevOpsの紹介が簡単にされています。これは興味ありますね。ただ、kubernetesを別途用意しないといけないのかな?

おわりに

普段から毎日お世話になっているGitLabの最新情報がまとまった一冊。Git含め知識0の方から今すぐDevOpsがはじめられる一冊になってると思います。個人的にはデプロイまわりがまだ触れてないので、GitLabを今後も使い倒していきたいと思います。

みんなで強くなるチームビルディングを支える脱・属人化

はじめに

今日もポエムです。どうした。ポエムはいいからコードをかけ。そんな声は聞こえないようにして続けます。

なんで属人化をころしたいの

僕自身が強く興味を持っていることが属人化を殺す、ということなんです。なんでそれをしようと思っているかというと、子育てのため休職する先輩の穴を埋めるため異動してと抜ける当日に言われ、引き継ぎもクソもない状態で仕事をはじめることになった経験がでかいと思います。

一応、その最終日の午後にあきらめつつ会話したんですが、「僕が知ってることはリーダーさんが知ってるから大丈夫。僕しか知ってることはない。」と言って去りましたが、リーダーさんが知っていることはその担当の方の仕事の大局的な進捗だけで、実際のオペレーションレベルでは共有されるはずもありません。

別に異動になったときに引き継げばよくない?

だからその引き継ぎのコストがバカにならないんだってー!

この出来事があって以来、僕は引き継ぎを不要、つまりいつ自分が職場から抜けてもいい状態にする働き方を僕自身するようになりました。引き継ぎに一週間とか二週間とかかけてる現実がそこら中にありますからね。。。びっくりする。

そもそも引き継ぎ自体のコストがもったいないということと、人材流動自体が頻繁にあります。これが1年に1回ぐらいならまぁいいけど、そうはいかないでしょう。チームメンバーそのものの急な異動、転職は年に数回ありますし、発注先メンバの入れ替わりだって頻繁にあります。

(高いレベルの)技術的な属人化は存在しうる

とはいえ、技術的にその人しかできないことはあるべきであり、高いレベルになるとこれはどうしても存在すると思います。それがプロフェッショナルなんだと思います。僕が言いたいのはその高いレベルの属人化ではなく、笑っちゃうぐらい低いレベルの属人化です。

自分が一度経験して、最初はできなかったけどできるようになったことは、誰かが踏むかもしれませんね。トラブル解決のためのナレッジや、あるいは社内手続きのためのめんどくさい手順だったり、自分のために作ったちょっとしたスクリプトだったり、そういう細かいものをチームに撒いて、自分がいなくてもみんなができるように一手間かけてしておきます。

一度経験すればそのひとは5分で解決できても、初めて出会う人は30分、1時間かかるかもしれません。そういうコストを減らしたいですよね。

みんなで強くなるための委譲

自分しかできないこと、自分しか知らないことに出会ったら、それをすぐ、チームメンバー全員ができるように整備します。

また、自分が受け持っている短期、中期の仕事は、一定期間経ったら別にひとに委譲してしまいましょう。サーバ管理の仕事だったり、ビルド環境の仕事だったり。定型的な仕事は、最初は自分だけができるでいいですが、最終的には誰かに引き継げるようにしておきましょう。その手段が自動化だったり、ドキュメント化です。

ここがちょっとコツで、「自動化しろー!」ってのはよく言われますが、自動化するためには、メンバー自体の技術教育が必要であるということです。属人化をなくすためにはチームの平均レベル向上が不可欠で、この視点を飛ばして自動化してしまうと「誰もメンテできないよー!」ということになります。

「ドキュメント化」にしてもそうです。文章に書き記すスキルというのは実は誰でもできることではありません。アウトプットにもコツがあります。他者が読みやすいドキュメントを書くスキルも、誰もができることではありません。最初はあなたがテンプレートぐらいを用意して書きやすくして、少しずつチームメンバーのドキュメンテーションスキルを向上させる必要があります。

チームビルディング

ここまで書いてきて、脱属人化を志すことは、チームメンバー全員の底上げをする、チームみんなで強くなる行為に他なりません。

これまで、属人化を防ぐことによって、以下のようなものが蓄積され、誰でもできるようになります。

  • 1度やった業務
  • 定型業務

これをするとともに、自動化やドキュメンテーションを行うための技術力も底上げされます。

さらに、こうやって共通でぶつかる壁を徹底的に減らすことによって、全員が未知の問題にしかぶつからなくなります。つまり、全員がチーム内で唯一の存在になります。それにぶつかるたびにそれをチームメンバーにばらまいてまた底上げします。

こうしてチームの成長が加速度的に速くなり、みんなで強くなるチームになります。

おわりに

僕はこういった考えをもとにチームビルディングを行っています。そしてこれを行うために、いろんな方法で仕掛けをチームにばらまいています。そのコツは昨日書きました。

take-she12.hatenablog.com

普段から自分が強く意識していることを、一度文書化しておこうと思って書いてみました。まずはこの考え方をチーム内で共有することからはじめようと思います。

チームに変化を導入するときに心がけていること

はじめに

今日もポエムです。

本当は会社のアドレスで登録しているqiitaにこれを投稿しようと思ったのですが、プログラミングじゃない、ポエムは嫌われそうなので、こちらに書くことにしました。

きっかけは後輩くんとキャリア面談(笑)をしているときに、「なんで(たけさんは)いろんなあたらしいことを見つけて、チームに導入できるんですか」と言われて、自分なりにそのとき考えた答えをまとめておきたかったから。

そしてそれを後輩くんに伝えるためにqiitaに書きたかったんだけど残念。(笑)

何を変えてきたの

日常的に改善を行ってきたし、課題意識を持って変えてきました。

  • 部/チームにmattermost(slackクローンOSS)導入 -> 今は部の1/3ぐらいがactive user、プロジェクトや開発環境管理にも活用
  • プロジェクトにmattermost分報導入
  • 障害チケットをmattermostに通知する仕組み導入
  • 修正パッチ作成ツールをCI連携し全自動化
  • 仕様書等のドキュメントレビューをgitlabのMRで行うように変更
  • 週の進捗報告で前週との差分が見えるようgitで管理/報告
  • OSS導入、活用推進
    • mattermost
    • knowledge
    • gitlab
    • ...ほか多数

残念ながら商用環境に対して何かを変えて顧客価値、ビジネス価値をもたらした、みたいなことはできていません。

自チーム、部に閉じた範囲では何も言われないので(笑)改善提案して、それを流行らせるってことは結構得意なほうだと思っています。

心がけていること

なんとなく書き出してみて、新しい仕組みの導入には以下の3フェーズがあるような感じがしてきました。

  1. 自分一人で試す
  2. チームに提案する
  3. 少しずつ広める

それぞれのフェーズでコツがありますが、以下フェーズに絡めたり絡めなかったりしつつ心がけていることを紹介します。

変化は小さく、少しずつ

フェーズ問わず、今回変更しようとしている内容全体についてです。

開発運用ガチガチの組織にいきなりDevOpsじゃ、ansibleじゃ、と言っても無理ですよね。

wordとexcelでドキュメントを書いている組織にいきなり今時reSTで書いてCIでpdfにbuildするんじゃ!って言っても無理なわけです。

理想は小さく、少しずつ、段階を踏んで変えていきましょう。一番無理のないところから変えましょう。

まず、自分がやってみせる

1つめのフェーズです。

自分がやらないのに相手にやって、と言ってもなかなかやってもらえません。やり方を書いたとしても、です。

まず、自分が普段から使ってみる。それをチラチラと見せる。(笑) なんかあいつやってんなーという雰囲気を作るところからはじめます。

自分が十分に使って、うわーすごいいいー!という空気を見せてから、具体的導入のための説明をします。

現在の課題を共有する

ここからは2番目の提案について。

改善したいということは、現状何かしらの課題を抱えているはずです。

今はどういう状況で、理想はどういう状況、だからこうしませんか?ということを明らかにして提案しましょう。

メンバーにとって何が変わるのかを示す

今まではこうだったのが、こうなる。変更点だけをシンプルに示すこと。

誰しもが「自分がやってる普段の作業はどうなるの?」が気になるはずです。その不安を埋めましょう。

それをするとどううれしいの?を示す

エンジニアっぽいですよね(笑)

その改善/変更をすることでどううれしいの?ということを示すのが大事です。僕の自己満じゃなく、みんなにとってもうれしいことなんだよ、ということを説明することが重要です。

新人を使う

自分も使ってみせたし、チームに提案もした。それでも全員がやってくれるまでは時間がかかります。3番目のフェーズですね。そこで使えるのが新人さんです。(笑)

いやらしいんですが、新人さんというのは今までやってきたやり方というのを持っていないので、新しくこれでやってみない?と言っても受け入れられやすいです。そしてその感想を聞くこともできます。その新人さんに(悪いけど)実験台になってもらって、その後チームに展開するということができます。

今ちょうど新人さんを見てるのもありますが、インターン生がきたときに新しい仕組みを試して、(mattermost)これはいける、と確信してチームの本格活用に展開した、ということもありました。

完璧を求めない

いざチームで導入が決まっても、それができていないメンバーがいたとしても責めてはいけません。つまり、ルールにしてはいけません。みんなが(強制されてないけど)なんとなくやっていることを変えるんです。この積み重ねが文化を作ります。

頑なにやり方を変えないメンバーがいてもいいです。少しずつ、少しずつ仲間を増やしていきましょう。

おわりに

改善のための変化には三段階あり、まず自分がしれっと使い始めて、メンバーに使って見せて、なんとなく認識させるという、1番目のフェーズが個人的にはとても重要だと思います。この期間をじっくり取らずにはじめると詰まってしまうことが多い。

そのあと、実際にこのメンバーならいける、という確信が得られたら、メンバーが集まる会で提案します。提案するときは「現在の課題」「導入して何が変わるか」「導入して何がうれしいか」を説明しましょう。そこでいいですか?と聞いてダメですという組織だと諦めてください。うちの上司は絶対にダメと言いません。

導入後も継続的にできているかどうかはじっくりフォローしてください。また、完璧を求めないでください。

今後も、プロジェクト/チーム内の課題を、技術を使って解決していきたい。