ツナワタリマイライフ

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

「IT業界を楽しく生き抜くためのつまみぐい勉強法」を読んだ

はじめに

読んだ。

IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書)

IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書)

渋川さんのツイートを見て中古で購入。

読んでみると、今は実践できていることもあれば、ウッ、できてない、ってこともあり、1年目の自分に送りたい気持ちと、これからも勉強やっていくぞーって気持ちと両方持ちました。

つまみぐい勉強法とは

本書の「はじめに」に書いてある通り、以下の特性を持つ勉強法のことです。

「多くの先輩達が実践している、楽しく学び続けるための勉強法」

であるとし、

「つまみぐい勉強法」は、次の3つの価値から構成されています。 * えいやで、すぐ始める * ほかの勉強へすばやくスイッチする * 対象は変わっても、勉強自体は続ける

IT業界で働くものとして、業務以外での学びが必要であり、それを継続して行うことが重要です。でも、どうせやるなら、楽しく勉強したい。楽しく学び続けるためのプラクティスがたくさん載っています!

少しだけ紹介します。

第1章 つまみぐい勉強法とは何か?

僕自身、飽きっぽくて、多動なんですよね。集中し続けることが苦手で、いろんなことが気になって、気になってはそれに手をつけてしまう。だから、基本的にかなり多くのタスク、勉強がパラレルで走っている状態です。でも、それでいいんだと思います。

この本の中で「得意技を見つけよう」という考えがあって、好きなので紹介します。

自分に合う勉強というのは、「継続できるかどうか」で判断できると説明しましたが、得意技の特徴は次のとおりです。 * つまみぐいしてきた勉強の中で、思った以上に効果のあるもの * 自分では普通のことなのに、思った以上に他人から評判が良かったもの * 実施していて楽しいもの

つまみぐいですから、いろいろやるんです。いろいろやっては、別のことをやって、って繰り返す。でもそれだけだと、きっと面白くない。どこかで面白いもの、自分の得意技となる勉強対象が見つかるはず、それ見逃さないようにね、というメッセージを受け取りました。その通りだと思います。

本を読んでいても、合わない本ってありますよね。それをせっかく買ったから、ととっておかずに、やらないという選択をする。飽きたらすぐやめて、"別の勉強をする"(何もしないではない)というのは、僕も実践してるところです。

第2章 守りの勉強法

守りの勉強法とは、実際に自分が仕事を与えられたところで、それを自分自身でなるべく解決するために勉強しよう、という趣旨です。仕事外の勉強ではなく、まずは仕事をうまくやるための勉強ということでここでは"守りの勉強法"と書かれています。

この章でいいなと思ったのは、会社というものが、別の視点で捉えられるようになります。単なる自分の所属組織から、人と道具と場所を与えてくれるチャンスの場として捉えられるようになるでしょう(p77)というところです。

言われたことをやるところから、自分自身で仕事の枠を設定し、自分で仕事を設定するようになると、自分でキャリアを築くことができます。そうなれば、上記のように、会社はキャリア形成のチャンスの場、と捉え、好循環がはじまります。こうなるまではなかなか時間かかりますね。

一次情報か二次情報かを気にし、できるだけ一次情報にあたること、ということは僕も最近ようやく意識しはじめたことです、、、

第3章 攻めの勉強法

自分の業務で遭遇したことを学ぶのが守りの勉強法だとして、それ以外の範囲の勉強のことを攻めの勉強と本書では呼んでいます。まとめから引用すると

  • 勉強時間を作る
  • 本は最強の時間短縮メディア
  • 手を動かす
  • ソースコードから学ぶ
  • ブログを書く
  • 翻訳して学ぶ

中でも、これからやっていきたいなーと思ったのは翻訳です。仕事で使うものは、必要に応じて英語のドキュメントを訳してブログに載せてきたりしましたが、それ以外でも翻訳は今後も積極的にやっていきたい。

そのため、yakstというサイトに翻訳者として貢献することにしました。

yakst.com

ちょっとまだ何も動けていないのですが、これからはyakstのプラットフォームに投稿していこうと思います。

4章 勉強法座談会

一言だけ、いいなーと思ったのは最後の渋川さんと牛尾さんの発言。

渋川:僕の高校の先生が「重要なのは若さとバカさだ」と言っていました。ハンドルとブレーキは壊れているけどアクセル全開みたいな。 牛尾:勘違いは重要ですよね。俺イケてるんちゃう?とか。後で絶対鼻を折られるんですがそのエネルギーがないと何も進まないです。(p159-160)

勘違いしてでも、とにかく自分を突き動かすエネルギーを持たないと、何もはじまらないってことですよね。

しかしこの本が出版された2010年時点だと牛尾さんはシンプルアーキテクトという会社の代表だったとか。今はすっかりMSのイメージですが。

はてなダイアリーにはその頃のアカウントがまだ残ってますね。

d.hatena.ne.jphttp://d.hatena.ne.jp/simplearchitect/about

5章 勉強会に行こう

今でこそたくさん社外の勉強会にいくようになりましたが、社会人になって最初はなかなか勇気が持てなかったことを思い出します。本章では勉強会にいくことの価値に加えて、自分で勉強会を主催してみようというところまで書かれています。

勉強会の10のメリットをメモしておきます。

  • ファミリーを作る
  • 日常に変化を与える
  • 方向性を正す
  • リーダーシップをのばす
  • 世の中の流れを知る
  • 初心者レベルからロケットスタートする
  • ストレスへの耐性を付ける
  • 高い目標を発見する
  • 自分のブランドを確立する
  • 出版デビューのチャンスをつかむ

どれもそうだと思いますが、僕は中でも大きいのは「日常に変化を与える」「世の中の流れを知る」ことですね。これから発信することが増えていけば最後の方の「ブランドを確立する」「出版デビュー」もついてくるんだと思いますが。

自分の会社にいるだけだと、結局自分の会社内の世界で完結してしまう。自分自身がどういう価値なのか、世の中的にはどういうことが行われていて、自分の会社ではどうなのかという比較ができる、そこが一番大きいですね。

あとは今でも言われていますが、勉強会に参加しまくるだけじゃなダメ、発信しないとダメ、という話。もちろんそれはそうですけど、僕はそれでも最初は行くだけでも違うと思います。行きまくっていいと思います。ただ、行くだけで何も考えない、行ったことに対して何も発信しないのはさすがに意味がないので、Twitterハッシュタグをつけてでもいいので感想や気づいたことをつぶやくとかでもいいと思います。

登壇しなくたって、勉強会に出て、何か考える、刺激を受ける、新しいことを知ることは、行かないよりいいと思います。

6章 勉強を思考タイプ別に攻略

4種類のタイプを歴史上の人物に例えて説明している章。僕は④勉強法で大切なのは、面白いかどうかだ、で、坂本龍馬タイプでした。

飽きっぽいしわりと直感で動くし多動なんですよね。今は自分はそんな人間だって割り切ってますが。

本書のよると以下のような勉強法が向いているらしいです。

  • ひたすら試して飽きたら、すぐに次の興味のあるものに飛びつく
  • 理論は考えずに体感して学ぶ。理論は後からついてくる
  • まったくつながりのない業界の弁y行をして、参考にする

いやーその通りだなーと思いました。理論も大事なんですけどね。。。

7章 家庭を持っているひとの勉強の仕方

家庭持ってませんけど、時間減りますよね。。。朝とか夜になるんだろうなあ。

おわりに

1年目の自分に送りたい気持ちです。もう4年経ってしまった。翻訳と、勉強会での発信は今後やっていきます!

「Container Days Japan v18.04」に参加した

はじめに

行ってきた。

eventregist.com

感想

  • とにかくいいイベントだった!満足感高い
  • ひとの数も多すぎない、参加者は500人程度、ストレスは感じなかった
  • 小さいながらも充電スペースや、コーヒーも飲めたりとうれしい配慮
  • 何より発表内容!自分自身が興味が強いのもあるが、全セッション見るイベントはなかなかない(たいてい1つ休憩する)
  • 8割型Kubernetesだったとはいえ、コンテナ/コンテナオーケストレーションのプロダクション導入事例にみんな飢えてるのは感じた(自分もそうだ)
  • コンテナを含む、アプリケーションプラットフォームは、kubernetesがデファクトとはいえ、まだまだ混沌としていて、少なくとも2,3年は試行錯誤が続きそうな気がした
  • Yahoo(Z Lab)さん、CyberAgentさん、まずOpenStackが安定稼働しているところがすごい、これは他社は真似できない
    • だからこそOpenStackの上でkubernetes-as-a-serviceができる
  • 見たどのセッションもいろんな視点でkubernetes(コンテナ)を見ていて、自分自身これからどうやって活用していくかに役立つ
  • pivotal草間さんのセッションが印象に残った、「適材適所」だがそれが難しい
    • コンテナも、kubernetesも所詮技術、ビジネス解決に何が適しているかを見極めるのがエンジニアリング
    • そのためにはServerlessも、PaaSも、Container Orchestrationも、"正しく理解"しなければならない
  • 最後Zlab五十嵐さんの発表、なんであんなにスライドきれいなんですか。。。
    • istio触りたくなる見事な発表でした
  • 今後もkubernetesを自分も触っていくが、アプリケーションの信頼性、ひいてはアプリケーションが解決するビジネス課題のために技術があるという視点は忘れないようにしたい
  • 次回は12月!参加したい!

公式さんがまとめてくれる前に、@Yukotanさんが資料をまとめてくれています、助かります!

medium.com

以下、メモです。

サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術[Masaya Aoyama(CyberAgent)]

speakerdeck.com

  • AKE(Adtech Container Engine)

  • https://developers.cyberagent.co.jp/blog/archives/12058/

  • 2人で作ったとのこと

  • 構築

    • パッチをあてたkubernetesバイナリをビルド、packerでqcow2に。
    • その後heatで展開
    • バージョン依存、くみあわせ、kubernetes, docker, etcd,,,
    • E2E test
  • key機能

    1. kubernetes, swarm(multi COO)
    2. openstack integration
      • keystone(Identity)
      • cinder(persistent volume)
      • designate(DNS), cluster名をもとに名前解決
      • heat(orchestration)
      • なんで他のツール使わないの?
        • magnum、開発スピード遅い、不安
        • rancher、2.0のGAは5月(2年前になかった)、細かい設定
        • tectonic
      • なんでベアメタルじゃなくてVMにしたのか
        • VMのほうがオーバーヘッドがあるが、
        • ベアメタル、コンテナ詰め込んで落ちると影響範囲が大きい
    3. high performance
    4. add-on mechanism(monitoring, logging), datadog, kibana, elastic
    5. tuning for adtech system
    6. multi container runtime

    7. まとめ

      • Pros
        • なんでもできる
        • kubernetes最高
        • add-techに特化したkubernetes環境を作れる
        • オンプレなので、パブリッククラウドとのハイブリッド構成もできる
      • cons
        • 実装コストが大きい
        • 運用コストが大きい
        • 内部実装を理解する必要がある
    8. あくーえちゃんの飼い主、we are hiring
    9. KubeCon 2018 EU 日本交流会@コペンハーゲン

マイクロサービスアプリケーションとしての機械学習[Takuma Yamaguchi(Mercari)]

speakerdeck.com

  • 画像認識を中心とした機械学習

  • 機械学習基盤の現状と課題

    • 要求性能が高い
    • サーバコストが高い
    • 学習モデルと、ソースコードのバージョンを合わせるのは面倒
    • プロダクション以外にも学習環境が必要
  • 機械学習を使った新機能をリリースしたい、インフラ担当ならどうする?

    • サーバでは1日100万リクエス
    • workerでは常時25GBメモリ
    • 機械学習のモデルのファイルサイズは15GB
    • モデルは定期的に更新し、GPUが必要
  • 回答「とりあえずdockerfileを書いてください、なんとかします」

  • Dockerfileはじめて書いた、シェルスクリプト感覚で1日で書けた

  • 1週間後、動きました

    • 画像はS3、GPUがあるのでAWSと併用
    • 通常の運用で見るのはkubernetes deploy(spinnaker経由)とdatadog(monitoring)
  • なんで一週間でできたのか

    • 複数の開発拠点(日本、サンフランシスコ、ロンドン)
    • マイクロサービス化していて、影響範囲が明確になっていた
  • 今までは「手順書を用意してくれれば構築します」だった、運用の限界は見えていた

  • 機械学習におけるMicroservicesのメリット

    • persistent volumeにモデルが入っている、更新のために毎回作り直す(blue green deploy)
    • 機械学習エンジニアだけで学習モデル以外のシステム運用もできるかも
  • まとめ

    • 実行環境や運用が特殊なことが多くMicroservicesとの親和性が高い
  • 200GBのモデルなんですけど -> 苦笑いながら「とりあえずdockerfileをもってきて」

  • 参考:http://tech.mercari.com/entry/2017/08/21/092743

  • SpinnakerによるContinuous Delivery

"Yahoo! JAPANのKubernetes-as-a-Service"で加速するアプリケーション開発[Masaya Ozawa(Yahoo! Japan)&Kazuki Suda(Z Lab)]

www.slideshare.net

Yahoo!ズバトク on kubernetes

  • おとくなくじやキャンペーンを掲載するためのキャンペーンプラットフォーム
  • yahooズバトクの技術スタック:openstack, jenkins, 社内独自パッケージシステム、php
  • 課題
    • スケールアウト、スケールアップができない
    • リリース自動化ができてない
    • パフォーマンステストのための本番同等の環境がなかった
  • kubernetesを使おう
    • 技術スタック:openstack、kubernetes、docker、Concourse CI、Java
    • concourse CIを使い、開発デプロイ、プルリク作成、本番デプロイできるように
    • GitHub上の操作で完結できるようなフローになった
    • ログも集約され、障害発生時もも簡単に(splunk)
  • Kubernetes移行
    • 考え方、設計方針のスイッチ
      • Cloud Native的な考え方

Yahoo Japanのkubernetes as a service

  • zlabのkaasについて
    • セルフサービス
    • オートヒーリング
    • ゼロダウンタイムアップグレード
    • クラスタアドオン
  • kaasの価値
    • 煩雑なkubernetesのオペレーションから運用者を解放する
    • AUTOMATE ALL THE THINGS
  • kaasの要件
    • スケーラブル、管理対象が数万台でも動く
    • 非同期モデル、マシン(VM)準備など処理完了まで時間かかることも
    • 堅牢性
  • CustomResourceDefinitions(CRD)

まとめ

  • kaas導入によりビジネスロジックに集中できるように
  • ソフトウェアですべてを自動化
  • kubernetes-as-a-service on kubernetes

Kubernetes x PaaS - コンテナアプリケーションのNoOpsへの挑戦[Yoichi Kawasaki(Microsoft)]

www.slideshare.net

  • venture -> yahoo -> microsoft
  • cloud app dev専門
  • NoOps
    • システムに自立運用(自己回復性)をもたせて運用コストを最小限にする
    • エンドユーザーにとってはサービス停止時間が最小に、高いサービスレベルを享受
    • 運用担当にとってもSRE的な運用機能に注力
    • デブサミ2018 NoOps
    • https://www.slideshare.net/hiromasaoka/noops-88082246
  • 特徴

    • self healing
    • in-flight renewing(無停止メンテ)
    • adaptive scale
  • kubernetes

    • self healing
      • pod's phase
      • probe
        • lieness 生きているかどうか、再起動の判断
        • readiness probne トラフィック受付可能かどうか、通信先決定の判断
      • restart policy、再起動判断
      • deploymentとreplicasetの仕組み
    • in-flight renewing
      • deployment配下を段階的に入れ替える
    • autoscale
      • podのhorizontal pod autoscale(HPA)
      • cluster autoscaler(CA0 クラスタレベルのオートスケール
        • node追加する
        • リソース不足でこれ以上podを増やせなくなった動く
  • マネージドサービス、PaaS、Serverlessを活用?
    • kubernetesは強いけど向かない例もあるよね
    • 無理にしなくていいよ
    • Kelsey Hightowerさん
    • ステートフルなもの、StatefulSetsやVolumesとかあるけど、まだまだ経験が必要な段階
    • こういうのはプラットフォームとして回復性がネイティブ実装されたPaaSやServerlessを可能なかぎり選ぶべき
    • Open Service Broker API
      • もともとCloud Foundryで考えられたものを汎用化
      • 外部サービスのprovisioning、更新、削除、bindingなどを自動化
    • Service Catalog
      • kubernetesがService Brokeと簡単に連携する
    • kubernetesはService Catalogを通じて、OpenService Broker APIともしもしし、Service Broker(各種ベンダ製プラットフォーム)とやりとりする
    • AWSのRDS(MySQL)を使う例
      • credentialな情報はSecretへ
  • マネージド型kubernetesの活用
    • masterの可用性、めんどくさいよね、オフロードしたいよね
    • AKS(Azure Container Service)
      • コマンド一発でクラスタアップグレードできるよ
      • ノードのjoinもコマンド一発
  • クラスタフリー&サーバレスコンテナサービス
  • Service Mesh
    • Service間通信の課題を解決するソフツェアレイヤー
    • コードを変更することなく回復性機能を追加できる
    • podの中でenvoyをサイドカー的にいれて、プロキシ的振る舞い
    • 1行かけばバグは生まれる、コーディングレスにこしたことはない
  • CI/CDは重要
    • Helm、パッケージャ
      • Service, ingress, pods, deployment… yaml、煩雑
      • これらを1つのパッケージとして面倒見る
      • ひとかたまりごとにrollbackできる
  • モニタリングとログ収集
    • クラスタ全体で何が起きてるかを把握できることが重要
    • それに対してテクノロジ選択、いろいろあります
  • Cloud Native Landscape
    • エコシステム広大
  • まとめ
    • kubernetes非常に強力だけど完璧じゃない
    • オフロードが可能であるなら回復力がもったマネージド、Paas、serverless活用
    • 足りない部分はエコシステムを活用して賢くギャップを埋めよ
    • NoOpsの目的は運用負荷を最小にして空いた時間をさらなるイノベーションに埋めよう

Cloud Native Apps入門[Takuya Noguchi(iRidge/dockerjp)]

speakerdeck.com

  • @tnir
  • アプリケーションエンジニアに普段からClod Native Appを使ってほしいな

Cloud native appsとは

  • CNCF
    1. Container packaged -> containerization
    2. Dynamically managed -> orchestration
    3. Micro-services oriented -> service mesh
  • 20プロジェクトある
    • 昨年kubernetesがgraduate
  • CNCF CI dashboard
  • certification kubernetes認定プログラム
    • 個人の認定資格もある, administratorとdevelopper
  • cloud aoolication maturity
  • twelve factor app
  • GitLab CI評価高い
    • ソースはどれだろ

まとめ

  • どんなワークロードでもkubernetesで実行できる世界を目指しましょう(アプリのcloud native化)
  • cloud nativeなアプリを開発していける仕組み化が重要(?
  • スタートとしてmicroservicesにこだわらないことも大事
  • コミュニティの皆様に支えられてやってこれ、社内のコンテナ標準化ができた

Spinnakerを利用したKubernetesへの継続的デリバリ[Takashi Mizouchi(AP Communications)]

speakerdeck.com

  • APCommunication、7割がインフラエンジニア
  • ミランティスとのジョイントベンチャーミランティス・ジャパン株式会社
  • コンテナのメリット
    • ポータビリティ、別環境で実行可能
    • 軽量、VMイメージより軽い
    • 実行環境の隔離
  • コンテナの管理、以下の課題をkubernetesが解決
    • 複数のDockerホストの管理
    • コンテナの死活監視
    • 障害発生時のセルフヒーリング
    • ロードバランサー
    • 永続的なデータ管理
    • ログの管理
  • kubernetesでも解決が難しい問題?
    • CI/CDの機能がない
  • SpinnakerはCDツール。kubernetesをdeployできる。
  • Spinnekerの特徴
    • マルチクラウド対応CDツール
    • 自動デプロイに必要な機能を搭載
      • パイプライン、
      • 様々なdeploy方法
        • blue/green deploy
        • rolling deploy
        • canary deploy
    • GUIでパイプライン(ワークフロー)を作成できる
      • パイプライン中にカスタムスクリプトの実行が可能
        • serverspecとか
        • 他のパイプライン(jenkinsやgitlab-ci)でもできそうな気がする。。。
    • 連携できるCIツールはJenkinsとtravisCI
    • manual jadgementはよさそう
    • write-listed execution windows
      • よく使う時間(日中、9時ー17時とか)をデプロイ禁止にできる
    • chaos monkey integration - ツールがついてる?そう動くんだろ
    • enable monitoring
      • datadog
      • prometheus
      • stackdriver
    • spinaker <->k8sのマッピング
    • 今後
      • 2ヶ月毎のvup
      • k8sのmanifestをデプロイする機能
      • カナリアテストを自動で行うOSS Kayenta

Helmを利用したKubernetes as a Serviceの実装[Motohiro Otsuka(NEC Solution Innovators)]

speakerdeck.com

  • keynoteのyahooさんとかぶって、、、
  • 自前で運用してたけど、運用したくない!
  • kubernetesはクラウドネイティブなアプリケーションの運用管理基盤
  • helm、kubernetesのパッケージマネージャ
    • 一般的なアプリケーションですらmanifest書いてた
    • chartって単位で共有できる
    • https://kubeapps.com
  • kubernetes as a serviceは、ユーザごとにクラスタを提供する
    • 共有してnamsespaceで切ってもいいんだけど、それぞれのupdateポリシーにあわせたりできる
    • コントロールプレーンをKaaSでフルマネージド、ノードだけユーザはもらう
    • GKEやAKS、コントロールプレーンの管理費は含まれない
  • クラウドに対抗するkaasを出すには?
    • コントロールプレーンのデプロイ、管理を自動化する
    • kubernetesがあるのでは?
  • kubernetes on kubernetesですよね
    • 自然な発想ですよね
    • kubernetesだってクラウドネイティブアプリケーションですし

Google Kubernetes Engineにおけるバッチ処理のパターン[Shota Yoshikai(Kabuku)]

speakerdeck.com

  • バッチ処理
    • 数秒から数時間以上かかる処理
    • 非同期
  • バッチ処理パターン
    • kubernetes標準のジョブ
    • メッセージキューイングの組み合わせ
  • kubernetesのjob
    • 一度切りの処理を実行させるコンテナ
  • ジョブのみを使う構成
    • メリット、シンプルでいい
    • デメリット
      • ジョブの数が増えると管理が大変、labelつけてもいいけどつら
      • 一度に大量のジョブを作るとリソースの上限に達してしまう
  • 公式での解決策
    • parallel processing using expansions
    • rabbitmqやredisと組み合わせる
  • MQと組み合わせる
    • 検討すべき点が増える、MQのサービスどれ使うか
    • pushかpullか
    • ネットワーク構成
  • クラウドのMQ
    • GCP、Cloud Pub/Sub
    • フルマネージド
    • 負荷は札束で殴って解決
    • 通信経路がk8sのネットワーク外
  • 経路:client -> Cloud Messqge Queue -> k8s pod
  • ミドルウェアのメッセージキューイング
    • rabbit mqとか
  • 経路:client -> k8s middleware message queue -> k8s pod
    • k8sに中にいる
  • 構築例
    • いろいろあって、、、いけてないところも、、、
    • 課題、httpやめたい
  • 検討したもの
    • Cloud Pub/Sub ACKの期限が最大10分
    • Cloud Tasks、アルファなので本番使えない
    • Redis、シンプルで早いけど必要な機能たりない
    • RabbitMQ、重いけど多機能。かわいい
  • まとめ

『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法![Kazuto Kusama(Pivotal)]

www.slideshare.net

  • アンケートによると参加者の46%がコンテナを商用活用してる、、、?
  • そんなわけじゃないよね
  • 参加者偏ってる、選りすぐり、それでも46%
    • 平日昼間に参加可能
    • 5000円も払ってきてる
  • ゴール:正しいテクノロジースタックを選択してもらう知識を得てもらう
  • なんでコンテナが普及しないのか?
    • コンテナ技術、楽しいよね
    • コンテナいれると幸せになれましたか?
    • コンテナいれて業務は劇的に改善した
  • コンテナ辛い
    • Dockerfileつらい
    • 教えるのもつらい
  • コンテナ技術は抽象度が低い、エンジニアがカバーする必要あり
  • kubernetesはgoogleのborgが元、すばらしいけどエンジニアのスキルの高さが前提
  • SREも同じ、日本でやるには熱意と覚悟が必要
  • テクノロジーの流れ
    • 高い抽象化と自動化の繰り返し
    • 一度抽象化、自動化したものが戻ることはない
  • コンテナの次になにがくる?
    • より高度に抽象化、自動化されたもの
    • Dockerfile書かなくていい
    • 運用もみてくれる
    • 何も指定しなくても勝手にスケールしてくれる
    • あれ?
  • PaaS?昔からあるような?
    • Herokuは2007年
    • CloudFoundryは2011年
  • PaaSの多くは内部でコンテナ技術使ってるから、時代遅れとかじゃないよ
  • Serverless、コンテナ関係ない、、、?そうではない
  • CaaS、PaaS、Serverless、何を採用すべきか?
  • [CNCF Serverless Whitepapter](https://github.com/cncf/wg-serverless/tree/master/whitepaper
  • 目的をしっかり考えよう
    • 強靭性
    • スケーラビリティ
    • ステートレス、ステートフル
    • アプリの更新頻度
    • 既存資産の流用
    • Dev, Opsの人数
  • 潜在的なコストを考慮しよう
    • 誰もがイチからアプリを作れる恵まれた環境にいるわけではない
    • lift & shiftは楽だけど長期的にはコストかかるかも?
    • Serverless化するとインフラコストは下がるけど、アプリ書き換えコストに見合うとは限らない
    • ServerlessはRDBとの相性が良くない、LambdaだとDynamoDBのほうが向いてる
  • PaaSやserverlessはopinionated。プラットフォームにあわせて開発しないといけない、その代わり合わせると生産性はあがる
  • kubernetesはless-opinionated。自由度は高いが、、、生産性は?
  • Serverlessは究極のロックイン(今のところ)
    • コード自体は一般的な言語が使えるし、フレームワークもあるが
    • 仕組み上他サービスと組み合わせるので結果ロックイン
    • ロックインが別に悪いってわけじゃない
  • 得意不得意があるので組み合わせよう
    • ただし自動化はしっかりしよう
  • 「戦うWebデザイン」制約は創造性をはぐくむ
    • railsの設定より規約
    • 適度な制約があると本来すべきことに注力し、創造性、生産性を高められる

Istioと共にマイクロサービスに立ち向かえ![Aya Igarashi(Z Lab)]

speakerdeck.com

  • Istioの解決方法
  • Microserviceにありがちな問題
  • Microservices
    • よくあるモノリシックとの比較
    • スケールアウトしやすい
    • 変更しやすい
    • 大人数で開発しやすい
  • 銀の弾丸ではない、複雑になる
  • 複雑なサービスメッシュの管理が追いつかない、という問題を解決するOSS
  • サービスメッシュ:アプリケーション間でメッシュ上に交差するネットワーク
    • どうやって管理?envoyがappにくっつく
    • controle planeがenvoyに向かって情報書き換える
    • envoy
      • c++、L4/L7 LoadBalancer
      • ナウい機能ついてる
        • Lyftが開発
        • HTTP2, GRPC対応
        • API経由で動的に設定変更できる
        • 設定変更時にrestart不要
    1. ServiseMeshを制御しきれない問題
      • アプリケーションのコードにServiceMeshの設定が埋め込まれている場合
        • 修正毎に再デプロイ
        • 運用、開発双方に負荷
      • ServiceMeshの設定を分離
      • k8sにappをdeploy
      • k8s、init containr、iptableを書き換える
      • containers、app+envoyを立てる
    1. 鍵と証明書を管理しきれない問題
      • システムによってはアプリケーション間通信の暗号化は必須、、、
      • 鍵と証明書の生成、配布、更新、廃止に対応
    1. システムの全体像が把握できない問題
      • ドキュメントは更新されなくなるよね
      • 可視化ツールとの連携
        • metrics prometheus/grafana
        • traces: zipkin
        • ServiceGraph Graphbiz/Prometheus
    1. 障害発生時に何が起こるかわからない問題

      • 障害を起こすテストを起こすのはコストがかかる
      • 結局障害が起こるまで対策が打たれない
      • Fault Injection(chaos enginering)
      • Circuit Brakerで被害を最小限
  • istio入門チャート
    • GKEがらく
    • quickstartを参考にistioインストール
  • こまったとき
    • トラシューガイド
    • FAQ(めっちゃ充実)
    • StackOverFlowやGitHubのIssue

「Japan Container Days v18.04 Meetup」に参加した

はじめに

行ってきた。もちろん本編も参加した。

eventregist.com

感想

  • 会場提供はリクルートテクノロジーズさん、アルコールありでした
  • 翌日本編の事前登録&事前配布もあり、前日meetupとして有益な取り組みあり、素晴らしい
  • IppeiSuzukiさんのCNCFに投稿された記事の分析は面白い、もっと詳細な分析を聞きたかった
    • kubernetesは新たにレイヤを作り、その上か下か、という考え方ははじめて知った
  • Ryoma Fujiwaraさんの発表は個人的に示唆に富む、興味深い発表
    • ワンボタンデプロイ=自動化、チーム/組織でデプロイ&運用を考える姿勢良いですね
  • DataDogさんの話ももっと時間かけて聞きたい内容だった、DataDogさんだからこそ持つ情報がたくさん
  • 本編CFP出しての40分枠を5分に圧縮してもらってるので時間超過は堪忍な、という説明あり

以下、メモ。

CNCF(Cloud Native Computing Foundation)の最新動向 Ippei Suzuki

kubernetes導入事例分析

  • kubernetes.ioの導入事例を整理
  • CNCF、kubernetesだけに絞った、まずはkubernetes nativeに絞りたかった
    • docker
    • redhat,openshiftとかあるけど...
  • kubernetes導入の悩みはkubernetesだけじゃない
    • あえて新しいレイヤーを載せる意味とは?
    • ノースバウンド、サウスバウンド
      • SDN業界で使う言葉
      • あるレイヤーを境に、上半分か下半分かを指す
      • kubernetesのノースバウンドはアプリケーションそのもの
    • kubernetesの導入が目的じゃない、ノースバウンドのために導入し、運用が変わる
      • サウスバウンドのひと(情シス)にとってはレイヤー増えるだけ、メリットがない

Kubernetes導入、国別の分類

  • アメリカがぶっちぎり多いが。。。
  • ヨーロッパ
  • 中国(バイドゥ、JD、2社)

コンテナ化の対象は何か?

  • 会社のIT業務をコンテナファースにする決断、比率的に多い
    • とはいえ突然そうしたわけじゃないよね
  • データ分析基盤
  • インフラ(KubernetesをOpenStackに乗せた事例、サウスバウンド側の事例)

Kubernetes導入のプラットフォーム

  • オンプレとクラウドが半々ぐらい?
  • AWSよりGCPのほうが多い、たまたまか?
  • レガシーなデータセンターの上にkubernetes載せてる例もある
  • ベアメタルクラウドの上も
  • インフラのこと話してない会社もある(アプリケーションのことだけ)

Kubernetes導入事例紹介

  • Amadeus
  • 飛行機の予約システム
  • メインフレームの時代から、オンラインで飛行機予約システム出してた
  • 拠点はドイツ、世界中にデータセンターをおいてる
  • トランザクションが多い
  • 24/265
  • 以前はOpenShift
  • トランザクションを止めずに導入
    • マイクロサービス化の促進
  • 35万個のコンテナが動いている

エンジニアの異常な愛情 ~または私は如何にして心配するのをやめてワンボタンデプロイを愛するようになったか~ (Ryoma Fujiwara)

  • コンテナ関連の先進アーキテクチャ事業
  • RancherJPコアメンバー
  • 先行事例に学ぶKuberntes...

  • デプロイの重要性

    • デプロイされなければ、公開されなければ何も意味がない
  • ワンボタンデプロイ
    • sshログインなんでせずに、1回クリックするだけでデプロイできる
    • 頑張って作り上げてもいつのまにか使われなくなる
  • ワンボタンデプロイはなぜ使われなくなるのか
    • 環境ごとに後世に乖離が発生しまって動かなくなる
    • 失敗した時にリカバリできなくなる
  • どう解決する?
    • Docker+kubernetesでアプリケーション層の構成の差異を埋めましょう
    • パブリッククラウドを使えばカバーできそう?
    • 環境構成の乖離を防ぐのはインフラエンジニアの腕の見せ所
      • docker+k8sは強力
  • 失敗した時リカバリできなくなる問題
    • チームで頑張れ
  • ワンボタンデプロイのこだわる理由
    • 絶対に成功か絶対に失敗する、に近づけたい
    • 誰のせいで失敗した、は悲しい
    • AMデプロイしたらPM仕事にならない(魂抜ける)
    • 作業者/作業管理者がいると、作業者が非難されるのはつらいp
  • ピープルウェア/Effective DevOps

    • エラー大歓迎(from ピープルウェア)

      • チャレンジしてるってこと
    • 非難のない文化(from Effective DevOps)

      • 個人じゃなくて組織として考えるってこと
  • ワンボタンデプロイにこだわる理由(2)

    • 曖昧さを排除する

      • 作業前に実はこのコマンド事前に打ってるとか
      • 開発商用不一致を避ける
      • 継続的デプロイ、何が嬉しいかってすぐに戻せること
    • 個人を非難から守る

      • コードレビューするよね
      • 個人の責任が希薄化、組織として責任持つようになる

まとめ

  • デプロイ大事
  • ワンボタンデプロイ
    • 作業者の負担軽減
    • 個人の批判集中軽減
    • チャレンジが継続的に行われ、イノベーションが起きる組織に
    • 失敗から学べる組織に

~Dockerfileの開発を劇的に楽にする~ Dockerfile開発環境 EDGE (Tatsunori Saito)

www.slideshare.net

  • TIS
  • Docker、コンテナ使うメリット
    • ホスト環境汚さない
    • 迅速にアプリ起動
    • 高いポータビリティ
  • Dockerfileからコンテナイメージができるまで
    • docker buildコマンド、パラメタ指定、大変
    • 期待したコンテナかのテスト、execで入るとか、修正してまたbuildするとか
    • やってられっかい!
  • Dockerfile開発環境を作った
    • Elastic dockerfile Generating environment
    • TDD実践できる
      1. テストコード(Serverspec)
      2. Dockerfile書く
        • ビルド変数はiniファイルで定義
      3. bin/build test
      4. bin/edge spec build_test
    • https://github.com/bbrfkr/edge

CoreOS Container Linuxで始めるベアメタルKubernetes ( Shoichi Kagawa)

speakerdeck.com

  • coreos
  • bootcube
    • self hosted kubernetes
      • k8sを使ってk8sのマスターコンポーネントをデプロイする
      • kubernetes meetup tokyo #8で詳しい解説されてる
  • MatchBox
  • Typhoonというterraformモジュール
  • 学習コストは高い
    • 一度環境を整えると楽になるよ
    • Typhoonカスタマイズしたいな

そろそろLambda編(CI/CD編) Akira Koyasu

www.slideshare.net

  • AWSの話です
  • EmotionTech
  • AWS LambdaをCI/CDする
  • やりたいことの確認(絵に意味はない)
    • ファンクションを書いて、リポジトリへpushしたらチェンジセットのステータスによって確認環境やら本番環境やらにデプロイできる
    • 😕
  • AWS SAM
    • 依存リソース含め管理できる
    • ローカルはSAM Local
  • CodeBuild / CodePipeline
    • お金払っただけビルドできる

Kubernetes 採用トレンド 2018 (Masahiro Hattori)

www.slideshare.net

  • https://www.slideshare.net/MasahiroHattori2/docker-adoption-in-datadog-japan-container-days-v1804-20180418
  • Datadoc
  • @toolyee さん
  • 用語
    • Adopter: Docker採用ユーザー、稼働ホスト50%以上
    • Dabbler:Docker利用しているが、50%以下?
    • Aamdoner:Dockerを過去に使ったことがあるユーザー
  • Dockerの利用者、1年に40%増
    • Datadocの中で15%ユーザーがdocker使ってる
    • 規模が大きい企業ほどDocker採用進んでる
  • コンテナのオーケストレーターは?
    • Dockerを稼働させている40%のユーザーがオーケストレーターを利用
    • Kubernetesのシェアは41%
  • オーケストレーターを使うことでDockerホストのライフタイムを40%縮小
    • kubernetesがコンテナのライフタイムを平均で1.5日まで縮小
  • コンテナ集積度
    • すべてのコンテナユーザーでは1ホストあたり平均7コンテナが稼働
    • 25%のユーザーのうち14以上のコンテナを稼働させてもいる
    • ECSだと3コンテナ
  • ...最後かけあし、データたくさん!!!もっとみたい!

安全で軽いコンテナを目指して minachi katsuya

  • @int_tt さん
  • Dockerfile
    • 雑に書いてもちゃんと動くのすごい
    • レイヤー数減らして軽くする
    • 便利な書き方、使い方紹介します
  • buildするためにinstallするの遅いよね
  • dockerのキャッシュ
    • layerは親子関係、順番がある。親に変更が入ると以降のキャッシュは使わない
    • add,copy以外のコマンドはコマンド事態に変更がなければキャッシュを利用する
    • add,copyは転送されるファイルのチェックサムを見る
  • package installを先に持ってこよう
  • multi-stage-buildめっちゃ便利
    • 複数のビルドコンテキスト間でファイルのやり取りができる
    • build専用ステージ作って、生成物だけ取り出したり
    • docker-composeで結合テストもできる
  • まとめ
    • layer cacheをうまく使おう
    • build時にtestまわそう
    • 結合テストもdocker-composeで実行
    • テスト通過済みの安全で軽いイメージを維持
    • docker公式にbest practiceに全部描いてあった
    • google container-struture-test

gitlab.comのgitlab-ciとmkdocsでmarkdown + pagesでの静的サイト作成がドチャクソ便利

はじめに

gitlab.comのgitlab-ciとmkdocsでmarkdown + pagesでの静的サイト作成がドチャクソ便利

です。

さて、GitLabではgitlab-ci機能を内包しており、.gitlab-ci.ymlというファイルをリポジトリのルートに置くだけでCIを実現できます。

about.gitlab.com

GitLabが実現しようとしている世界はこちらを参照してください。

blog.chaspy.me

自前でgitlabを運用するのであればrunnerの設定が必要ですが、gitlab.comではshared runnerが使えるのでその準備も不要です。

本当に5分で実現できるので、markdownをgitlab pagesとしてデプロイしてみましょう。

使用するビルドツールを選択する

GitLab pages exampleというグループから好みのツールを選択し、行った先の指示に従いましょう。

gitlab.com

今回はmkdocsを利用します。

gitlab.com

Forkする

Forkしましょう。

Fork後は、関連付けを解除しておきましょう。

Setting -> Advanced Settings -> Remove fork relationship

f:id:take_she12:20180418101506p:plain

プロジェクト名を変更する

任意のプロジェクト名に変更しましょう。

今回はmkdocs-sampleとしてみました。

f:id:take_she12:20180418101759p:plain

urlとtitleを変更する

mkdocs.ymlを変更します。

gitlab.com

1番最初はgroup名か自分のuser名を指定します。

コミット後、CIが実行され、passするとページが公開されています!

f:id:take_she12:20180418102144p:plain

http://chaspy.gitlab.io/mkdocs-sample にアクセスしてみましょう。

chaspy.gitlab.io

markdownを編集する

docs以下にmarkdownファイルがあるので、こちらを編集しましょう。

urlを追加するcommitをしてみました。

gitlab.com

CIがまわりきれば更新されます。

注意

shared runnerは共有リソースなので、込み合っていたり、gitlab.comがbusyだとpendingとなることがあります。昨夜1時頃実施したんですが、CIがまわったのは朝8時ごろでした。そういうこともあるので、pendingになった場合は一晩寝かしてみてください。

どうやって実現しているのか

そもそもgitlab pagesはどうすれば利用できるのか?公式ドキュメントを見てみる。

docs.gitlab.com

今回やった手順しか書いてないですね。

.gitlab-ci.ymlを眺めてみる。

image: python:alpine

before_script:
  - pip install mkdocs
  # Add your custom theme if not inside a theme_dir
  # (https://github.com/mkdocs/mkdocs/wiki/MkDocs-Themes)
  # - pip install mkdocs-material

pages:
  script:
  - mkdocs build
  - mv site public
  artifacts:
    paths:
    - public
  only:
  - master

mkdocs buildを実行すると、docs以下のディレクトリをbuildし、siteというディレクトリでhtmlが生成される。

www.mkdocs.org

siteというディレクトリをpublicにrenameし、artifactsとして登録してやる。

gitlab pagesではpublicディレクトリのみを対象とするようです。根拠はここ。

docs.gitlab.com

pagesというjob名であること、publicというディレクトリであること、artifactsとして登録すること、この3つがあれがgitlab pagesとして公開されるようですね。

docs.gitlab.com

おわりに

gitlab-ciや、buildツールであるmkdocsの知識がなくても、GitLab Pagesと組み合わせて静的サイトとして簡単に公開できます。ちょっとしたポータルページをささっと作ることができるのは本当にすごい。

gitlab-ci含め、最近のGitLabができることはこの本を参考に。

GitLab実践ガイド (impress top gear)

GitLab実践ガイド (impress top gear)

blog.chaspy.me

GitHubのProjectボードをお試しがてら技術本の進捗管理をしてみる

はじめに

GitLabではissue board使えるけど、GitHubでも使えるらしい。

soudai.hatenablog.com

で、まぁ仕事でissueでタスク管理しないといけないほどの規模でGitHub使ってるわけでもないので、がっつり使いこむことはなさそうなんだけど、とりあえず使ってみました。

使ってみる

github.com

とりあえず技術書の進捗をボードにながめてえへへってしてみるの巻。

github.com

もはや意味があるかわからんが読書メーターに雑にメモったあと、たいてい復習をかねてブログに書くまで通して消化(完了)としています。

よくインプットした(読み終わった)はいいけどブログに書いてない、みたいな状態でたまることがあるので、それの可視化もかねて。

あと積ん読をしすぎないように、という意味もかねて。。。

今後

  • とりあえず2018/2Q何冊いけるか楽しみなので様子見る
  • せっかくGitHubなので消化状況をREADMEに書ければいい
    • どうせならGitHub APIの練習がてらissueから情報ひっぱってきてpushできるといい
  • なんなら自動ビルドしてGitHub Pagesとして公開できるといい
  • ciercleci組み合わせたい
  • 他人もissue投稿できるわけだから、おすすめの本を登録してくれてもうれしい

とやるかどうかわかりませんがいろいろ考えましたとさ。

技術者の、技術書の登録/管理システムをGitHubのみで作れたら素敵だよねって感じです。

「GitLab Meetup Tokyo #7: 新年度応援&GitLab 11.0」に参加してきた

GitLab Meetup Tokyo #7: 新年度応援&GitLab 11.0

してきた。しかもブログ枠で。

gitlab-jp.connpass.com

みんなちゃんと読むんだよ〜〜〜という会でした。(癒着ではない)

GitLab実践ガイド (impress top gear)

GitLab実践ガイド (impress top gear)

ちなみにぼくはちゃんと読んでいった。サインもらってるひといて、持って行けばよかったーと。(思いつかなかった)

blog.chaspy.me

感想

  • GitLabのビジョンをちゃんとわかった上で、GitLabを使い倒すのが大事
  • ただのコードリポジトリではない、CI/CDを含む、サービス開発の全てをGitLabで完結させることを目指している
  • GitLabをオンプレで運用している人向けのmeetupや、情報がもっと増えてもいいかなと思った
    • 僕も社内サービスで使ってるし、個人でも立てて運用してる
    • 今日はGitalyの話が聞けてよかった
  • アイコンはたぬき
  • 2ヶ月後に11.0リリース、今後もさらなるGitLabの進化に目が離せない

以下、当日のメモを乗せて簡単ですが終わりたいと思います。若干ですがリンク補完してるところあります。

発表者のスライドが見つかれば載せていこうと思います。

Complete DevOps

speakerdeck.com

  • Shingo Kitayamaさん
  • ansible実践ガイドの作者さん

twitter.com

1. Gitlab complete DevOps

  • ビジョンの話
  • ツールって何かしら目的があるよね
  • Gitlabのビジョンは"enterpriseのソフトウェアをデプロイする時間を短縮したい"
  • ideaがslackで生まれて、jira, githug, jenkins, chef, kubernetes... ツールが多い
  • "変更を容易にするためのツールチェーンの管理をなくし、開発者と運用者のコラボレーションを促進するカルチャー"

2. GitLab Development lifecicle

  • Plan ... 進捗管理、タスクの優先順位
    • chat(mattermost), issue management
      • redmineやjiraいれなくてもいい
  • Create ... 設計、コード化、ビルド、ブランチ管理
    • version control, code review(Merge Request)
  • Verify ... 静的解析、会期テスト、脆弱性分析、パフォーマンス
  • Package …. パッケージ管理、トリガーリリース
    • artifactって成果物をarchiveしただけと思うよね
    • 並行してdocker imageを作ってregistoryも登録していく
  • Release … リリース調整、デプロイ、フォールバック、スケジュールリリース
    • gitlabがデプロイ環境を持ってるわけじゃない
    • kubernetesに向けてトリガーきっかけに実行する
    • Continous Delivery, Release Automation
    • カナリアデプロイもできる
  • Configure … インフラの展開、再デプロイ
    • Infrastructure Configuration, Application Control Panel
  • Monitor … パフォーマンス測定、ユーザー経験
    • Application Performance Monitoring
    • Prometheus
    • Grafana

まだまだこれから機能は増えていく(特にConfigure, monitor...)

3. Gitlab Cloud Native Application

  • Cloud Native(CNCF)
  • メリット
    • 開発者の時間を海部
    • スケールしてコスト節約
    • 速いリリースとフィードバック
    • システム開発からビジネス開発へ時間をシフトする
  • kubernetes on GCP、ボタン一発でいける

How does Gitlab manage git repositories?

  • @sota yamashita さん
  • Locki
  • 404ページ
  • たぬきなのかよ(笑)

twitter.com

Gitalyについて

  • A Git RPCservice for handling al the git calls made by GitLab
  • GitalyはGo言語製

Gitaly <> Railsサーバ with gRPC

  • GitalyはNFSサーバに対してリポジトリを探しに行く
  • なんでgRPC?
    • 最初はREST APIを考えてた
    • gRPCの利点
      • リクエスト、レスポンスに片付けて切る
      • Protocol BuffersがGoやJava、Nodejsなどをサポートしている
      • HTTP/2を活かした高速通信ができる
  • 普通にGoの中でgitコマンドを実行してる

まとめ今後やりたいこと

  • GItaly without Gitlab
  • Gitalyをgitサーバとして使って見ることをやってみている

GitLabのイシュートラッカー活用術

www.slideshare.net

  • 吉村潤平さん(@jumpyoshim)
  • iRidge
  • タスク管理ツールを併用してた(Backlog)
  • Gitlab実践ガイドに出会った(会場笑)
  • Issue Label、アイデアレベルのものを出しやすくなった
  • Slack NotificationでMRやissueを見逃さなくなった
  • Description Templatesを活用、テンプレで作成しやすくなった
  • External issue trackerで外部タスク管理ツールとの連携
    • backlog未対応。。。
  • Gitlabのビジョンを知りどう使うべきなのか考えてみる
  • イシュートラッカーを便利に使うための機能がたくさんある
  • Gitlab実践ガイドおすすめ

twitter.com

GitLab CI & Docker-inDocker

  • Yasuhiro HARAさん(@toricls)
  • GitLabがdockerを使う方法
    • shell
    • docker-in-docker
    • docker-socket binding
  • 普通にdockerコンテナでdocker buildしてもdockerコマンドないとか、permission deniedとか
  • services: -docker:dindと書けばいい
  • docker pullしてもホスト上にはない、わぁclean

twitter.com

カッブラボ

  • @t_nakayama0714さん
  • もっとお金ほしい
  • マネーキングダムというgitlab group
  • gitlab pagesを日次で更新
  • いいよ、gitLab.com
    • GitLab Pages
    • GitLab CI
    • ぐいぐいバージョンあがる
    • 無料
  • お金を稼げたか?結果は、、、うっ

twitter.com

GitLab-CEのContributionとGitLab 11.0の展望

speakerdeck.com

  • @tnirさん
  • github.comにもgitlabhqというリポジトリ
  • 20000star超えてるプロジェクトは196しかない
  • rails appの中で2番目
  • 11.0は2018-06-22にrelease

github.com

CREATION LINEさん寿司スポンサーセッション

  • CHEF, Docker, GitLab、日本への展開
  • リセールパートナー
  • @hiroponzさんjoin (MVPに3回選ばれた)

www.creationline.com

「カイゼン・ジャーニー」を読んだ

はじめに

読んだ。

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

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

イベントにも行った。

blog.chaspy.me

タイトルでビビっときて、デブサミで買った。常日頃から改善活動をしているので、何か共感するところがあると思ったから。

中身はアジャイルプラクティスを現場に導入していくストーリー。特にアジャイルを学びたいと思っていたわけではないので、中身自体はふんふんと読み進めていった。

ただ、この物語にはアジャイルをやること以外にきっと重要なメッセージがあるはず。そこを考えてみたい。

第1部 一人から始める

何かを変えるとき、改善するとき。コツは自分の仕事場の外に出ることだとあって、本当にそう思う。

もっと仕事のやり方を良くしたい、変えたい、新たな取り組みを始めたいと思ったときに、何からやっていけば良いのか、どうすれば良いのかとっかかりがわからず前に進めない時がある。(略)私としては、自分がいつもいる場所から外に出てみることをお勧めしたい。(p12)

1つの組織にずっといてはいけない。だからエンジニアは勉強会に出て外の空気を吸いにいくんだと思います。僕もそれをしてきたから改善できたし転職もできたなーって思う。

そして何かを変えるときに僕が大事だと思っていること、"小さくはじめる"ことと、"許可を求めるな謝罪せよ"ということもちゃんと書かれている。まず怒られない範囲で、勝手にやってしまう、やったあと広める。たいていそれでうまくいく。

自分1人からはじめて、そして自分1人で振り返りをする。それがまず第一歩ですね。

ちなみにプライベートの目標管理については時間の経過とともにやりたいことや自分の趣味嗜好が変わってしまうことがわかってるのであんまり厳密にしないようにしている。そのとき情熱を持ってやりたいことをやる、それに向かう可処分時間をできるだけ増やすようにしたいと思っている。

第2部 チームで強くなる

チームで強くなるというところも僕が普段から仕事をしているときに考えていることの1つ。

スプリントプランニングや、プロダクトバックログなど、アジャイルアジャイルしい(笑)プラクティスが紹介される章です。大切だと思うけど、僕はこんなにがっつりアジャイル開発をすることはなさそうなのでわりと流し読み。

それぞれのプラクティスは知っておくと、いざそれが必要になった場面で試せるからいいですね。

これは先のイベントで著者の方々も言ってました。別に全部やんなくていいし、手段ベースで考えちゃダメで、必要になった時に必要なだけやればいいだけだよって。その通りですね。

第3部 みんなを巻き込む

この章も様々な困難にぶちあたりつつ、アジャイルプラクティスを実践していって、優先度を見極め、チームをゴールに導いていくストーリーですね。わりとプラクティス自体にはあんまり興味がなくて、ここも流し読み。

第3部で言いたいことは、たぶん問題の見極めですよね。第2部でチームとして1つのゴールに対して向かっていくことはできた、次はどうしようもない困難にぶつかったとき、そもそもゴールは何なのか。課題は何なのか。issueは何なのか。Whyからはじめよ、というのはそういうことですよね。だからプランニングポーカー、仮設キャンパス、ビジネスモデルキャンパス/リーンキャンパスといったことが出てくる。

まだビジネスに近いところで仕事をしたことがないのでちょっと今の自分にはピンと来づらいところではあったけど、いずれやるときには思い返したい。

blog.chaspy.me

おわりに

カイゼン・ジャーニーは、自分たちの組織にアジャイルを導入したいひとにとってはど真ん中で役にたつだろう。だけど、今の仕事を、今の職場を、今のチームを、ほんの少しでも今よりよくしたいと思うひとが読んだらいいと思う。

僕はこの本の一番のメッセージは、みんな1人からはじめるんだよ、ということだと思う。著者たちだってそうだった。

巻き込み方、強くなり方はチームによって違う。この本が紹介しているのはほんの一例。だからこそあなたの「カイゼン・ジャーニー」を描いてくれ、というのがメッセージだ。

僕もこれから自分のカイゼン・ジャーニーを描いていきたい。