kakakakakku blog

Weekly Tech Blog: Keep on Learning!

ストレッチ + リフレクション + エンジョイメント /「経験学習」入門を読んだ

「経験学習」とは,経験から学び成長することで,例えば,難易度の高かった仕事/個人プロジェクトなど,日々何かしらの「経験学習」をしていると思う.自分自身が今後どのように「経験学習」をしていけば良いのか,そして技術講師として学びを伝えるためにどんなことを意識すれば良いのか,そのあたりを知るために,今回『「経験学習」入門』を読んだ.本書の導入部分にも書いてあるけど,もっと成長したい人,育成に悩んでいる人,チームマネジメントをしている人などが読者層かなと.

「経験学習」入門

「経験学習」入門

経験学習モデル

組織行動学者のコルブによって提唱された「経験学習モデル」とは,以下の学習サイクルを繰り返しながら成長するという理論で,個人的には「省察(言い換えると,リフレクション,振り返り)」が特に重要だと思う.

  • 経験 (Concrete Experience)
  • 省察 (Reflective Observation)
  • 概念化 (Abstract Conceptualization)
  • 実践 (Active Experimentation)

ちなみに,最近読んだ「教育研修ファシリテーター」にも「経験学習モデル」の話が載っていて,また出たー!感がある.

kakakakakku.hatenablog.com

3要素

本書では「経験から学ぶ力のモデル」として,以下の3要素が挙がっていた.

  • ストレッチ(挑戦)
  • リフレクション(振り返る)
  • エンジョイメント(楽しむ)

常に挑戦するというのは重要なことだけど,ストイックすぎても続かないため,好奇心を持ち,楽しむことも大切だという意味で「エンジョイメント」が3要素の中に挙がっているのは良かった.そのためには,淡々と仕事を進めるのではなく「なぜこの仕事が必要なのか?」という本質を考えることが必要だと書かれていた.また「内発的動機」に関しても言及があった.「内発的動機」に関しては「モチベーション3.0」に詳しく書いてある.仕事/メンタリング/セルフコーチングなど,どんなシチュエーションでも「ストレッチ + リフレクション + エンジョイメント」を意識すると良さそう.

kakakakakku.hatenablog.com

70:20:10 の法則

成長を決める要素の比率として「70:20:10 の法則」が紹介されていた.

  • 70% : 直接経験
  • 20% : 間接経験(フィードバック)
  • 10% : 間接経験(読書/研修)

比率に異論はないけど,個人的には「フィードバックをもらうこと」をとても大切にしていて,むしろ「フィードバックをもらえなくなったら成長は止まる」とも思っているので,工夫次第では「20%」以上の価値がある要素になると思う.本書には「ポジティブ・フィードバック」も「ネガティブ・フィードバック」もどちらも言及があった.「ポジティブ・フィードバック」は,ただ褒めるだけではなく,良いことを良いと適切に伝えることができる点がポイントで,「ネガティブ・フィードバック」は異なる価値観を気付かせることがポイントだと思う.本書にも「批判にオープンになる」という話があって良かった.

能力的成長と精神的成長

成長を分類すると「能力的成長」「精神的成長」に分類できると書いてあった.特に「精神的成長」とは,仕事に対する信念/価値観が変わり,自己中心的なものから,他社/社会と繋がり影響を与えていくようになるということで,組織を客観的に見て,組織の課題解決に向き合ったりするのは「精神的成長」に分類されるのかもしれないと感じた.

まとめ

『「経験学習」入門』を読んだ.内容的にはそこまで新しいものはなく,これまで読んできた「自己啓発」関連の本と「メンタリング」関連の本とカブっている部分も多かったけど,改めて「経験学習」のサイクルを学び直せたのは良かった.どこまでもストイックに挑戦していく性格なので,よりエンジョイメントの比率を高くし,もっと間接経験(フィードバック)をもらいながら成長できるように頑張りたいなと!

依存パッケージを更新するサービス「Dependabot」で Dockerfile の更新をチェックする

Dependabot は依存パッケージの更新を定期的にチェックし,更新があった場合にプルリクエストを作成してくれるサービスで,現時点で「Ruby, JavaScript, Python, PHP」など,多くのプログラミング言語がサポートされている.他にも「Go, .NET」などは BETA & ALPHA 版でサポートされている.依存パッケージの更新が重要なのはわかっていても,月に1回など,定期的なイベントとして実施しているチームも多いと思うので,Dependabot を使うメリットがある.

dependabot.com

Dependabot 以外だと GreenkeeperTachikoma.io を使っているチームもあるし,CircleCI などと組み合わせて独自実装で実現しているチームもある.あえて自動化はせず「チームメンバーの教育目的で手動で依存パッケージを更新する」というチームの話も聞いたことがある.

Docker サポートとは?

Dependabot がサポートしているプログラミング言語の中に「Docker」があり,具体的に何をしてくれるんだろう?と興味があったので,実際に試してみた.結論から言うと「Dockerfile のベースイメージに更新があったら Dockerfile を更新するプルリクエストを作成してくれる機能」だった.これは便利では!?

f:id:kakku22:20181012190403p:plain

インストール & 設定

Dependabot は GitHub Marketplace からインストールし,次にリポジトリを登録しておく.パブリックリポジトリなら無料で使えるので,すぐに試すことができる.あとはチェック設定をするだけで,今回は以下のように Dockerfile を管理しているリポジトリを登録してみた.Docker の場合,以下のオプションを追加で指定することができる.

  • Directory (optional)
  • Target branch (optional)
  • Automatic PR merging
    • Runtime dependency PRs to merge automatically
    • Development dependency PRs to merge automatically

なお,スケジュールは以下の3種類から選ぶことができる.

  • Daily updates
  • Weekly updates
  • Monthly updates

f:id:kakku22:20181012190354p:plain

プルリクエスト

以下のように alpine:3.7alpine:3.8 に更新するプルリクエストが作成された.常に最新バージョンを確認しているわけではないので,Dependabot が定期的にチェックしてくれるのは便利だった.常に最新という意味で alpine:latest を指定しているのであれば,プルリクエストは出ないと思う.

github.com

f:id:kakku22:20181012190342p:plain

ChatOps

Dependabot は ChatOps に対応しているので,プルリクエストのコメントで以下のようなメンションをすると,トリガーすることができる.今回は自分でプルリクエストをマージするのではなく @dependabot merge を使ってマージした.

  • @dependabot rebase
  • @dependabot merge
  • @dependabot cancel merge
  • @dependabot reopen
  • @dependabot ignore this [patch|minor|major] version
  • @dependabot ignore this dependency
  • @dependabot use these labels
  • @dependabot use these reviewers
  • @dependabot use these assignees
  • @dependabot use this milestone
  • @dependabot badge me

Flexible monorepo support

サイトには Flexible monorepo support と書いてあるけど,実際にディレクトリ / で登録しようとすると Repo must contain a Dockerfile. とエラーが出て使えなかった(なぜ?).今回はディレクトリごとに登録をした.

Using a monorepo? No problem - you can specify one or many directories within a repo for Dependabot to look for Dockerfiles in.

まとめ

  • 依存パッケージの更新を定期的にチェックしてくれる Dependabot は便利
  • Dependabot は Dockerfile もサポートしているので,ベースイメージの更新をチェックできる
  • すごく便利なので Dependabot がもっと人気になれば良いな!

最新バージョン Redash v5 をすぐに試せる「Redash ハンズオン資料」

Redash v4 のリリースから約5ヶ月,正式に Redash v5 がリリースされた 🎉🎉🎉

blog.redash.io

Redash v5 とは?

約1ヶ月間のベータ期間を経て,現在は Redash v5.0.1 が最新バージョンになっている.デザインの大幅な変更があった v4 から,順当に便利になっていると感じている.特に以下は個人的な目玉機能と言える.

  • クエリに「お気に入り登録」「タグ登録」をできるようになった
  • ダッシュボードに「お気に入り登録」「タグ登録」をできるようになった
  • ユーザーを無効化できるようになった
  • パラメータで日付の範囲指定ができるようになった
  • クエリ編集画面でレイアウトを変更するショートカットが使えるようになった
    • Alt + D : テーブル一覧とクエリエディタを非表示にする
    • Alt + Shift + D : テーブル一覧を非表示にする

詳細な Changelog は GitHub のリリース情報にまとまっている.

Redash ハンズオン資料 v5 対応

そして今日「Redash ハンズオン資料 v5 対応」をリリースした 🎉🎉🎉

github.com

主な変更点を以下にまとめる.

  • 全てのスクリーンキャプチャを撮り直した
  • 新コンテンツ
    • クエリの「お気に入り登録」「タグ登録」
    • ダッシュボードの「お気に入り登録」「タグ登録」
    • ユーザー追加とユーザー無効化
  • MySQL の Docker Image を kakakakakku/mysql-world-database:5.7 に変更した

Docker Image に関して,今まで使っていた kakakakakku/mysql-57-world-database は,バージョンごとにイメージ化していて,さらに Docker Hub のアップロードを手動でやっていたので,運用面で課題があった.今回から使うことにした kakakakakku/mysql-world-database:5.7 は,バージョンごとにイメージタグを切って,さらに Docker Hub の AUTOMATED BUILD を使っている.既に MySQL 8.0 も用意しているので,試すこともできる.

github.com

Redash v4.0.2

ちなみに,長らく最新バージョンとなっていた Redash v4.0.1 に Google OAuth 関連のセキュリティ問題が発覚し,急遽 Redash v4.0.2 がリリースされた経緯がある.詳しくは Arik のブログに書いてある.

https://blog.redash.io/important-redash-security-update-%EF%B8%8F-2fb8134ca689blog.redash.io

それに伴って,Redash ハンズオンも v4.0.2 に対応してある.v4 でハンズオンを試す場合は,是非 v4.0.2 を使って頂ければと!

まとめ

「Redash ハンズオン資料」を使って Redash v5 を学ぼう!

github.com

関連記事

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ

2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ.タイトルの通り,コンテナのデザインパターンがまとまっていて,これからコンテナ設計をする人も,既にコンテナを運用している人も,デザインパターンを学べるのは価値があると思う.一部ミスリードをしているかもしれない.

論文も公開されている.

パターン一覧

  • Single-container management patterns(コンテナ管理用の単一コンテナパターン)
  • Single-node, multi-container application patterns(シングルノードでのマルチコンテナパターン)
    • Sidecar pattern(サイドカーパターン)
    • Ambassador pattern(アンバサダーパターン)
    • Adapter pattern(アダプターパターン)
  • Multi-node application patterns(分散システムのためのマルチノードでのパターン)
    • Leader election pattern(リーダー選出パターン)
    • Work queue pattern(ワークキューパターン)
    • Scatter/gather pattern(スキャッター/ギャザーパターン)

Single-container management patterns(コンテナ管理用の単一コンテナパターン)

  • コンテナは境界を提供するため,アプリケーションだけではなく,管理用(オーケストレーション)としても使える
  • コンテナを止めるときに SIGKILL シグナルを送り強制停止するのではなく,SIGTERM でコンテナの終了処理を実行できるようにする
  • "upward" : 監視メトリクスやプロファイリング情報やヘルスチェックを取得することができる(コンテナに対する管理)
  • "downward" : 優先順位の高いタスクのために,優先順位の低いタスクを終了することができる(コンテナ内部のプロセスに対する管理)

Single-node, multi-container application patterns(シングルノードでのマルチコンテナパターン)

Sidecar pattern(サイドカーパターン)

  • メインコンテナを拡張し,強化する
  • ウェブサーバがメインコンテナだとすると,ホスト側のディスクを読むログ保存コンテナはサイドカーになる
  • 他にも Git リポジトリからコンテンツを取得して,ホスト側に定期的に同期するサイドカーもある

個人的に経験があるのはログ収集用に使う Fluentd コンテナで,まさに同じユースケースと言える.サイドカーが異常になった場合も,メインコンテナに影響しないというのがポイントだと思う.

Ambassador pattern(アンバサダーパターン)

  • メインコンテナが外部とコミュニケーションをするときのプロキシになる
  • 例えば Memcached プロキシの twemproxy など
  • メインコンテナは localhost の Memcached に接続するように見えるけど,実際にはアンバサダーがプロキシをしている

ロードバランサーにも似ていて,外部とコミュニケーションをするという関心事をアンバサダーにオフロードしているのがポイントだと思う.他にも Microservices を構築するときに考える Service Mesh (Envoy / Linkerd) での Circuit Breaker もアンバサダーに分類されるかな?

Adapter pattern(アダプターパターン)

  • アンバサダーとは異なり,外部とのインターフェースを標準化する
  • システム内の全てのコンテナが同じモニタリングインターフェースを持つ

海外旅行で使う電源変換アダプタのイメージと言える.具体的には Prometheus のようなプル型のモニタリングシステムと相性が良さそう.

f:id:kakku22:20180923120447j:plain

(構成図を作った)

Multi-node application patterns(分散システムのためのマルチノードでのパターン)

Leader election pattern(リーダー選出パターン)

  • 分散システムのよく知られた課題に「リーダー選出」がある
  • 複数のノードに分散したコンテナ同士で通信をする
  • リーダー選出の実装は複雑になることが多いので,実装言語を気にせずコンテナを再利用することができる

今まで経験があるのは Consul のリーダー選出(内部的には Paxos?Raft?)ぐらいで,その他は経験がないけど,リーダー選出という複雑な部分をコンテナに押し込めるのはメリットがあると思う.ただし,論文にもあまり詳細は書かれていなかった.

Work queue pattern(ワークキューパターン)

  • リクエストを非同期に処理するため,一度キューに入れてからワーカーコンテナで処理をする
  • ワーカーコンテナは直接キューに接続するのではなく,コーディネーターコンテナからメッセージを受ける

読んでいるときに「一般的なキューとワーカーの組み合わせと何が違うんだろう?」と疑問だったけど,キューからメッセージを受ける部分もコーディネーターにオフロードすることで,キューの種類が変わっても(例えば Kafka, SQS, ActiveMQ, RabbitMQ など)ワーカーは影響を受けない構造になっていて,納得できた.個人的に1番学びのあるデザインパターンだった.

f:id:kakku22:20180923120508j:plain

(構成図を作った)

Scatter/gather pattern(スキャッター/ギャザーパターン)

  • ルートノード or 親ノードにリクエストを送る
  • そこから子ノードに並行してリクエストをファンアウトする
  • 子ノードの結果をマージするマージコンテナもある

Scatter(散布)と Gather(収集)という意味で,具体的な例で言えば MapReduce と同じ構成と言える.

f:id:kakku22:20180923120518j:plain

(構成図を作った)

まとめ

  • 論文「Design patterns for container-based distributed systems」を読んだ
  • 論文などアカデミックな情報源から学べることも多いので,継続的に読んでいきたい
  • これからコンテナ設計をする人も,既にコンテナを運用している人も,デザインパターンを学べるのは価値がある
  • 最近はコンピュータサイエンスの論文の解説が聞けるポッドキャスト「Misreading Chat」がお気に入りでずっと聞いている

misreading.chat

Cloud Computing Concepts, Part 1

Coursera で「Cloud Computing Concepts, Part 1」という講義を受講することができる.これは「分散システム」を学ぶ講義になっているので,興味がある人がいたら是非オススメしたい.僕が受講したときのメモは全て以下の記事にまとめてある.

kakakakakku.hatenablog.com

本当の「学び」を創り出す /「教育研修ファシリテーター」を読んだ

「教育研修ファシリテーター」を読んだ.どのように学びのある教育研修を創り出すのか?という講師のためのノウハウ本ではあるけど,サブタイトルに「組織・人材開発を促進する」と書いてある通り,チームビルディングをしたり,メンバーに何かを伝える場面が多い人にも役立つ本だった.例えば,エンジニアリングマネージャー,スクラムマスターなどのポジションを担当する人にもオススメできる.僕自身は技術講師(本書の表現だとファシリテーター)をしているので,実務経験だけでは学べないような,教育研修のノウハウとマインドセットを学ぶために読んだ.

前提

本書では,従来の研修と比較をするために,同じような意味で使われる言葉を明確に表現している.今回の記事も,本書の言葉通りに書いているので,前提として整理しておく.特に「受講者」という表現はよく使っているので,今後は意識的に「参加者」と表現しようと思う(とは言え,組織的に表現が決まっている場合もあると思う).

  • インストラクター(講師)
    • 「教える」ことを目的とした研修を進める人
    • 教えられる側を「受講者」と呼ぶ
  • ファシリテーター(教育研修ファシリテーター)
    • 「学び合い」を促進する人
    • 教えられる側を「参加者」と呼ぶ

「3つのスタイル」と「9つの学習法」

従来の研修と比較して,ファシリテーターは「3つのスタイル」「9つの学習法」を組み合わせるべきと書いてあった.参加して印象に残る研修は,講義だけじゃなく,ディスカッションがあったり,フィードバックがあったりするので,こういう分類があったんだなと理解できた.

  • レクチャー(講義)
    • 聴く
    • 見る
    • 考える
  • ワークショップ(協働)
    • 話し合う
    • 体験する
    • 創作する
  • リフレクション(省察)
    • 分かち合う
    • 内省する
    • 深め合う

研修の構成要素

研修の構成要素として,3つの要素が紹介されていた.

  • チーム
  • プログラム
  • ファシリテーター

特に参加者と場をコントロールするための「チーム」は参考になった.まずは参加者の属性(部署,役職など)と研修に参加した経緯などをヒアリングすることにより,期待値を調整することができる.また,参加者の年代によって価値観,スピード感が異なるので,話すスピードを調整したり,比喩を使うにしても時代を意識したり,カジュアルな言葉を使うかどうかを意識したりする必要がある.本書を読んでいて「ファシリテーターのプレゼンテーションにも TPO があるんだな」と気付けたところに学びがあった.

他には,場をコントロールするために,部屋のレイアウトにもこだわると書いてあった.特にレイアウト変更のときには参加者にも手伝ってもらうことで,その単純作業がキッカケになり,チームビルディングに繋がるというのは知れて良かった.あと,研修センターに行くとよく飴などお菓子が置いてあるのも,場をコントロールするためだったんだとわかった.

  • レクチャー(講義)
    • スクール型
    • シアター(劇場)型
  • ワークショップ(協働)
    • アイランド(島)型
    • ラウンドテーブル型
  • リフレクション(省察)
    • サークル型
    • バズ型

予定調和にならないように

本書を読んでいると,繰り返し「予定調和にならないように」という表現が出てくる.インストラクターは「予定調和(落語)」で,ファシリテーターは「ライブ(大喜利)」という比喩も出てくる.予定調和という意味は,ただテキストの通りに進めるということだけではなく,例えば,ブレストなどのワークショップをしたときに,チームごとの独自性のあるアイデアを活かさず,事前に用意したテンプレートでフィードバックをすることも予定調和と書かれていた.e-Learning では体験できない学びを創り出すためにも,ライブ感を届けられるようなファシリテーターになりたい.僕の大好きな本「Fearless Change」から引用すると「テーラーメイド」とも言えるかな.

ワークショップ手法

本書では,ところどころにワークショップ手法の紹介が入っている.体験したことがあるものも多かったけど,実施する背景だったり,コツなども整理されているので,実施する側として,改めて考え直すことができた.

  • 参加者チェック
  • 自己紹介
  • クイズ
  • グループ分け
  • バズ
  • ペアインタビュー
  • グループ討議
  • ディベート
  • 親和図法
  • ダイアログ
  • ロールプレイング
  • 研修ゲーム
  • 体験学習ゲーム
  • ケーススタディ
  • 言葉づくり
  • フレームワーク
  • 作品づくり
  • 演劇
  • チェックイン/アウト
  • フリップ
  • プレゼンテーション
  • バザール
  • セルフチェック
  • 振り返り
  • フィードバック
  • フィッシュボウル

今回はすぐに使えそうなワークショップを2個紹介したいと思う.

バズ

隣同士など,少人数で軽く話をするワークショップで,全員の前だと話にくいけど,少人数なら話せるという心理的安全性を重視したものになっている.自己紹介でも良いし,ミニディスカッションでも良いし,様々な場面で使える.複数日の研修なら,バズの組み合わせを変えたり,人数を徐々に増やしたりするのも良いと思う.

チェックイン/アウト

「今の気持ちはどう?」という質問に気軽に答えるというワークショップで,自己紹介とセットで実施しても良さそうだった.研修に対する意気込みを伝えても良いし,もっと身近な例で「朝,満員電車が大変でー」というような体験を話しても良いと思う.参加者の笑いを誘う自己紹介をする人は,チェックインが上手なんだと思う.また,チェックアウトも忘れずに実施することが重要と書いてあった.ポイントは「気軽に今の気持ちを伝える」という点かなと思う.

フィードバック

本書の後半に「フィードバックの4原則」が出てくる.自分のことは自分で気付きにくいので,フィードバックをもらうことは大切だけど,最低限のグラウンドルールを守らないと雰囲気が悪くなってしまう.

  • 両者が一致した建設的な目的のためにおこなう
  • 相手の態度・行動についてのみ伝える
  • 自分の観察・印象・判断のみを伝える
  • 具体的かつ明確に描写する

「建設的な目的」と書いてあるけど,個人的にフィードバックで大切だと思っているのは,良い点だけではなく悪い点も伝えてあげることなので,だからこそ攻撃的にならないように注意したいところ.そして,ファシリテーターとしては「今はフィードバックの時間ですよ」という雰囲気を作り,参加者同士で深め合ってもらえるようにしたいと思う.やはり「深め合ってもらう」ために場を促進するのがファシリテーターの役割なので,ファシリテーターがドヤ顔でフィードバックしてしまうことも気を付ける必要がある.本書にも「一言多いファシリテーターは要注意」と書いてあり,読んでいて「ウッ」となった.

まとめ

  • 教育研修のノウハウとマインドセットを学ぶことができた
    • 今回まとめたところ以外にもたくさん良いところがあり,1度読んだだけなのに付箋とマーカーだらけになった
  • 教育研修の場だけでなく,スクラムマスターなど,開発現場でも応用できるノウハウもたくさんあった
  • ファシリテーターとしての実務経験を繰り返しながら,定期的に読み直したい
    • 本当の「学び」を創り出せるファシリテーターになりたい