kakakakakku blog

Weekly Tech Blog: Keep on Learning!

技術ブロガーを育てる!ブログメンタリングで何を教えているのか

週末に開催された「DevLOVE X」に参加し,2日目に発表をしてきた!今回の発表タイトルは「技術ブロガーを育てる!ブログメンタリングで何を教えているのか」で,今まで約1年半続けている「ブログメンタリング」の事例紹介をテーマにした.さらに関連する話題として,「アウトプットの再定義」「ブログを書く理由(モチベーション)」「メンタリングの技術」も話した.発表資料をフォローアップする.

devlove.wixsite.com

発表資料

speakerdeck.com

Public URL-ize

アウトプットの重要性はもう聞き飽きるほど聞いていると思うし,今回の DevLOVE X でも何度も話題に上がっていたけど,僕の発表では,改めてアウトプットを再定義し,うまく言語化したいと考えていた.結果として「Public URL-ize」という言葉にした.意図としては,発表資料にも記載した通り,「URL で誰でもアクセスできて,検索可能な情報を作り出すこと」を意識することにより,多くの人に見てもらえる可能性があるし,フィードバックをもらえる可能性もある.「公開された履歴書」と表現することもできる.

f:id:kakku22:20190623093442p:plain

なぜブログを書くのか?

ブログの習慣化に悩んでいる人と話すと,様々な「書くことを諦める理由」を聞く.例えば「二番煎じだから」とか「誰でも知ってることだから」という理由をよく聞く.もし本当に似た内容の記事が既にあるとしても,自分自身に新しい学びがあったのであれば「自分の学習メモ(学習履歴)」として書き残しておくことに価値はある.最初から「誰かの役に立ちたい」なんて考えなくて良いと思う.「ブログを書く理由(モチベーション)」は段階的なので,まずは「自分のために書く」ことを意識すると続けやすくなると思う.

f:id:kakku22:20190623093509p:plain

なぜブログメンタリングを始めたのか?

アウトプットをしたり,ブログを書くことに価値があることは理解しつつも,実際に習慣化しようとすると挫折してしまう人は多い.そんな状況をどのように打破できるかを考えた結果,もしかしたら「習慣化できた!」という小さな成功体験を感じてもらうことに価値があるのでは?と考えた.そこで,ブログのパーソナルメンターになるべく,約1年半前に「ブログメンタリング」をはじめた.今では「ブログのライザップ」と言われることも増えている.

f:id:kakku22:20190623231502p:plain

過去に発表をした「ブログを書く技術」「習慣化する技術」も,伝えていることは何も変わってなく,参考にしてもらえればと思う.

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

メンタリング技術

後半は「ブログメンタリング」の事例をベースに,よく知られた「メンタリングの技術」に対する僕のスタイルを紹介した.発表資料の下側に青枠で囲っている部分はメンタリングの技術をできる限り抽象化して言語化している.

f:id:kakku22:20190623204804p:plain

僕自身,多くのメンタリング経験があるわけではなく,数年間担当していた「Engineering Manager の経験(1 on 1 など)」「プログラミング講師の経験(マンツーマン)」をベースにしている.さらに2017年に書評を書いた「コーチングの基本」から学んだ内容も自分なりに応用している.例えば「傾聴」「他責/自責」「アクノレッジメント」など.また発表資料にも載せている通り,最近では「エンジニアリング組織論への招待」にも「メンタリングの技術」が詳しく載っている.

kakakakakku.hatenablog.com

発表中

DevLOVE だ!と感じられるポジティブな雰囲気の中で発表できた.冒頭に「笑って OK 😃」という話もしたため,楽しく聞いて頂けたように思う.締めは鬼スベリも覚悟しネタに挑戦した!多くの実況ツイートもして頂き,Togetter を見たら非常に盛り上がっていた!また最前列に座られていた id:yoshidashingo に褒めて頂き,とても嬉しい!

togetter.com

まとめ

「DevLOVE X」に参加し「技術ブロガーを育てる!ブログメンタリングで何を教えているのか」というタイトルで発表をしてきた.「ブログメンタリング」の事例紹介は今までしたことがなく,今回はじめて公開した情報も多くある.ブログの習慣化に悩んでいる人の助けになれば嬉しいし,もし興味があればブログメンティに応募頂ければと思う.

そして今回は友人たちに発表資料の事前レビューをしてもらったことによりクオリティを高めることができた.本当に感謝!特に id:ykmc とはカフェで打ち合わせをして,ストーリー展開の客観的なフィードバックをもらえて助かった.さらに今回 DevLOVE X という最高のイベントで発表をする機会を頂けた id:HirokiHachisuka に本当に感謝!

おまけ : MigMix 1P

最後に発表資料に使ったフォントを紹介しようと思う.直近2年間は「コーポレート・ロゴ」をずっと使っていた.パッと見たときに惹かれるインパクトがあり,今でも個人的によく使っているけど,今回はフォントを変えてみることにした.様々なフォントを検討した結果「MigMix 1P」にした.丸さのある美しいフォントですごく気に入っている.

発表資料は Keynote を愛用している.「Keynote ベストプラクティス」は以前に公開した記事を見てもらうと良さそう.

kakakakakku.hatenablog.com

Docker Experimental Features を有効化すると使える docker build の --squash オプション

Docker コンテナを本番運用する場合,コンテナイメージのサイズをできる限り小さくすることを意識すると思う.具体的には「レイヤー」を意識することにより,Dockerfile に記述する RUN を減らしたり,一時ファイルを消す場合に同じ RUNrm をする.最近だと「multi-stage builds」を使うこともできる.Dockerfile のベストプラクティスは,以下の公式ドキュメントに載っているし,最近では「Container Build Meetup」といったイベントもある.

docs.docker.com

docker build --squash とは?

Docker には「Docker Experimental Features」と呼ばれる仕組みがあり,有効化すると「実験的機能」を使えるようになる.現在だと「計6種類」の実験的機能があり,その中に docker build で使える --squash オプションがある.--squash オプションを使うと,自動的に「レイヤー」を1個に統合してくれるため,コンテナイメージのサイズを小さくできる.今回は --squash オプションを試すことにした.

Docker Experimental Features を有効化する

Docker for Mac の場合は Preferences の Daemon 画面から Experimental Features を有効化できる.

f:id:kakku22:20190619155418p:plain

一般的な Linux 環境の場合は /etc/docker/daemon.json に以下の JSON を定義し,Docker プロセスを再起動すると有効化できる.

{
    "experimental": true
}

有効化したら docker version コマンドで確認できる.有効化せずに --squash オプションを使うとエラーになる.

$ docker version -f '{{.Server.Experimental}}'
false

$ docker build --squash  .
"--squash" is only supported on a Docker daemon with experimental features enabled

$ docker version -f '{{.Server.Experimental}}'
true

検証 1 : Alpine をビルドする

まず,alpine:3.9FROM に指定した Dockerfile を作成する.

FROM alpine:3.9

kakakakakku/playground:v1 として docker build をすると,5.53MB になる.

$ docker build -t kakakakakku/playground:v1 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED             SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago         5.53MB

検証 2 : 一時ファイルを作成する

次に,dd30MB の一時ファイルを作成する手順を追加した Dockerfile を作成する.

FROM alpine:3.9
RUN dd if=/dev/zero of=file bs=1M count=30

kakakakakku/playground:v2 として docker build をすると,37MB になる.

$ docker build -t kakakakakku/playground:v2 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED             SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago         5.53MB
kakakakakku/playground                                                      v2                  57c261ac2dd3        11 seconds ago      37MB

検証 3 : 一時ファイルを別レイヤーで削除する

「検証 2」Dockerfile に一時ファイルを削除する手順を追加する.

FROM alpine:3.9
RUN dd if=/dev/zero of=file bs=1M count=30
RUN rm file

kakakakakku/playground:v3 として docker build をすると,同じく37MB になる.

$ docker build -t kakakakakku/playground:v3 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED             SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago         5.53MB
kakakakakku/playground                                                      v2                  57c261ac2dd3        42 seconds ago      37MB
kakakakakku/playground                                                      v3                  c54d6c94941b        10 seconds ago      37MB

docker history でレイヤーを確認すると,一時ファイルを作成するレイヤーと一時ファイルを削除するレイヤーが異なっている.よって,コンテナイメージのサイズは減らずに 37MB となる.

$ docker history kakakakakku/playground:v3
IMAGE               CREATED              CREATED BY                                      SIZE                COMMENT
c54d6c94941b        About a minute ago   /bin/sh -c rm file                              0B
57c261ac2dd3        2 minutes ago        /bin/sh -c dd if=/dev/zero of=file bs=1M cou…   31.5MB
055936d39205        5 weeks ago          /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>           5 weeks ago          /bin/sh -c #(nop) ADD file:a86aea1f3a7d68f6a…   5.53MB

検証 4 : 一時ファイルを同じレイヤーで削除する

今度は ddrm を同じ RUN の中で実行することにより,レイヤーを1個にした Dockerfile を作成する.

FROM alpine:3.9
RUN dd if=/dev/zero of=file bs=1M count=30 && \
    rm file

kakakakakku/playground:v4 として docker build をすると,一時ファイルが消えたことにより 5.53MB に戻った.ベストプラクティスに載っている方法と言える.

$ docker build -t kakakakakku/playground:v4 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED              SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago          5.53MB
kakakakakku/playground                                                      v2                  57c261ac2dd3        About a minute ago   37MB
kakakakakku/playground                                                      v3                  c54d6c94941b        43 seconds ago       37MB
kakakakakku/playground                                                      v4                  0d9323b479c5        7 seconds ago        5.53MB

検証 5 : --squash オプションを使う

最後に --squash オプションを試すため,「検証 3」と同じ Dockerfile を作成する.

FROM alpine:3.9
RUN dd if=/dev/zero of=file bs=1M count=30
RUN rm file

kakakakakku/playground:v5 として docker build --squash をすると,なんと 5.53MB になっている!

$ docker build --squash -t kakakakakku/playground:v5 .

$ docker images | egrep 'REPOSITORY|kakakakakku/playground' | sort
REPOSITORY                                                                  TAG                 IMAGE ID            CREATED              SIZE
kakakakakku/playground                                                      v1                  055936d39205        5 weeks ago          5.53MB
kakakakakku/playground                                                      v2                  57c261ac2dd3        About a minute ago   37MB
kakakakakku/playground                                                      v3                  c54d6c94941b        About a minute ago   37MB
kakakakakku/playground                                                      v4                  0d9323b479c5        45 seconds ago       5.53MB
kakakakakku/playground                                                      v5                  46bf29424020        16 seconds ago       5.53MB

docker history でレイヤーを確認すると,COMMENTmerge とあり,レイヤーが1個になっている.確かに --squash されている.

$ docker history kakakakakku/playground:v5
IMAGE               CREATED              CREATED BY                                      SIZE                COMMENT
46bf29424020        50 seconds ago                                                       0B                  merge sha256:c54d6c94941b40e8f54833c0404791482f541deebdad37fcc50456bd279562f6 to sha256:055936d3920576da37aa9bc460d70c5f212028bda1c08c0879aedf03d7a66ea1
<missing>           About a minute ago   /bin/sh -c rm file                              0B
<missing>           2 minutes ago        /bin/sh -c dd if=/dev/zero of=file bs=1M cou…   0B
<missing>           5 weeks ago          /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>           5 weeks ago          /bin/sh -c #(nop) ADD file:a86aea1f3a7d68f6a…   5.53MB

まとめ

  • 「Docker Experimental Features」を有効化すると「実験的機能」を使えるようになる
  • docker build で使える --squash オプションを試した
  • 一時ファイルの削除などを別レイヤーにしていても docker build のときにレイヤーを1個に統合できる

Redis で特定のコマンドを無効化できる設定「rename-command」

最近 Redis の公式ドキュメント「Redis Security」を読んでいたら「Disabling of specific commands」というトピックを発見した.簡単に表現すると redis.confrename-command という設定を定義すると,特定のコマンドを無効化したり,別名のコマンドに変更することができる機能と言える.例えば FLUSHALLFLUSHDB など,もし運用上不要なコマンドがあれば,誤って実行してしまうことを防止することができる.rename-command は今まで使ったことがなく,試してみることにした.

redis.io

検証環境

今回は Mac に brew でインストールした Redis 5.0.5 を使う.

$ redis-server --version
Redis server v=5.0.5 sha=00000000:0 malloc=libc bits=64 build=31cd6e21ec924b46

$ redis-cli --version
redis-cli 5.0.5

CONFIG GET コマンドを実行する

まず,設定値を取得する CONFIG GET コマンドを通常通りに実行する.以下のように portsave の設定値を取得できた.

127.0.0.1:6379> CONFIG GET port
1) "port"
2) "6379"

127.0.0.1:6379> CONFIG GET save
1) "save"
2) "3600 1 300 100 60 10000"

CONFIG コマンドを無効化する

次に,公式ドキュメントに書いてある通りに redis.conf を修正する.

rename-command CONFIG ""

すると,CONFIG GET を実行しても unknown command となり,無効化されていた.

127.0.0.1:6379> CONFIG GET port
(error) ERR unknown command `CONFIG`, with args beginning with: `GET`, `port`,

127.0.0.1:6379> CONFIG GET save
(error) ERR unknown command `CONFIG`, with args beginning with: `GET`, `save`,

CONFIG コマンドを別名に変更する

次も,公式ドキュメントに書いてある通りに redis.conf を修正する.今度は CONFIG コマンドを推測不可能な別名に変更している.

rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

すると,今度は b840fc02d524045429941cc15f59e41cb7be6c52 コマンドを使って,設定値を取得できた.

127.0.0.1:6379> b840fc02d524045429941cc15f59e41cb7be6c52 GET port
1) "port"
2) "6379"

127.0.0.1:6379> b840fc02d524045429941cc15f59e41cb7be6c52 GET save
1) "save"
2) "900 1 300 10 60 10000"

KAKKUSET コマンドと KAKKUGET コマンドを作る

運用上使うことはないけど,例えば KAKKU というプレフィックスを付けたコマンドを作ることもできる.同様に redis.conf を修正する.

rename-command SET KAKKUSET
rename-command GET KAKKUGET

すると,KAKKUSET コマンドと KAKKUGET コマンドを使えるようになる.

127.0.0.1:6379> KAKKUSET mykey "Hello"
OK
127.0.0.1:6379> KAKKUGET mykey
"Hello"

まとめ

  • Redis の公式ドキュメント「Redis Security」を読んでいたら「Disabling of specific commands」というトピックを発見した
  • redis.confrename-command という設定を定義すると,特定のコマンドを無効化したり,別名のコマンドに変更することができる

Shell で「テンプレートエンジン」のような仕組みを実現できる envsubst コマンド

少し前に envsubst コマンドの存在を知った.envsubst コマンドを使うと,変数展開など,Shell で「テンプレートエンジン」のような仕組みを実現できる.例えば,設定ファイルを生成するときなどに使える.なぜ今まで知らなかったんだろう!と思うけど,今回は envsubst の紹介記事を書きたいと思う.

準備

例えば Amazon Linux 2 など,環境によって,最初から envsubst コマンドが使える場合もある.もしインストールする場合は gettext パッケージに含まれているため,yum などを使ってインストールする.

$ yum install -y gettext
$ which envsubst
/usr/bin/envsubst

Mac なら brew を使ってインストールできる.インストール後に brew link を実行することを忘れずに!

$ brew install gettext
$ brew link --force gettext
$ which envsubst
/usr/local/bin/envsubst

なお envsubst コマンドの help を確認すると「環境変数の値を代入する」と記載されていた.

$ envsubst --help
Usage: envsubst [OPTION] [SHELL-FORMAT]

Substitutes the values of environment variables.

echoenvsubst を組み合わせる

まず,以下のように名前を ${NAME} として環境変数にした文字列を作成し,echo で標準出力をすると,そのまま出力される.

$ echo 'Hello ${NAME}'
Hello ${NAME}

次に,export で環境変数を設定して,標準出力を envsubst に流すと,${NAME} の部分が変数展開される.これは便利!

$ export NAME=kakakakakku
$ echo 'Hello ${NAME}' | envsubst
Hello kakakakakku

テンプレートファイルと envsubst を組み合わせる

検証用のテンプレートファイル profile.yaml.template を作成する.namebloggithub を Key とし,Value に環境変数を指定したシンプルな YAML ファイルにする.

name: ${NAME}
blog: ${BLOG_URL}
github: ${GITHUB_URL}

検証用のテンプレートファイルを cat で標準出力をすると,そのまま出力される.

$ cat profile.yaml.template
name: ${NAME}
blog: ${BLOG_URL}
github: ${GITHUB_URL}

次に,先ほどと同様に export で環境変数を設定して,検証用のテンプレートファイルを envsubst に流すと,Value の部分が変数展開される.環境ごとに異なる設定ファイルを生成できるようになった.これは便利!

$ export NAME=kakakakakku
$ export BLOG_URL=https://kakakakakku.hatenablog.com
$ export GITHUB_URL=https://github.com/kakakakakku

$ cat profile.yaml.template | envsubst
name: kakakakakku
blog: https://kakakakakku.hatenablog.com
github: https://github.com/kakakakakku

なお,ファイルと組み合わせる場合は cat を使わずに,直接流し込むこともできる.

$ envsubst < profile.yaml.template
name: kakakakakku
blog: https://kakakakakku.hatenablog.com
github: https://github.com/kakakakakku

まとめ

  • envsubst コマンドを使うと,Shell で「テンプレートエンジン」のような仕組みを実現できる
  • 設定ファイルを生成するときなどに使えて便利!

文化である DevOps の誤解を紐解こう /「Effective DevOps」を読んだ

先週から「Effective DevOps」を読んでいた.去年出版されたときにパラパラと気になる箇所を読んだけど,書評記事を書いていなかったこともあり,改めて読み直すことにした.本書は「DevOps」をテーマにしつつ,その本質としてはサブタイトルにもある「4本柱による持続可能な組織文化の育て方」となる.よって,タイトルだけを見て「DevOps の技術面」を学べるのかなと期待すると,ある意味期待を裏切られる可能性もあり,まず目次を見てみると良いかと.そのためにも目次を載せておく.

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

目次

  • 第 Ⅰ 部 : devopsとは何か
    • 1章 : 大局を見る
    • 2章 : devopsとは何か
    • 3章 : devopsの歴史
    • 4章 : 基本的な用語と概念
    • 5章 : devopsに対する誤解とアンチパターン
    • 6章 : 効果的なdevopsのための4本柱
  • 第 Ⅱ 部 : コラボレーション
    • 7章 : コラボレーション:ともに仕事をする個人たち
    • 8章 : コラボレーション:誤解と問題解決
  • 第 Ⅲ 部 : アフィニティ
    • 9章 : アフィニティ:個人からチームへ
    • 10章 : アフィニティ:誤解と問題解決
  • 第 Ⅳ 部 : ツール
    • 11章 : ツール :エコシステムの概要
    • 12章 : ツール:文化を加速させるもの
    • 13章 : ツール:誤解と問題解決
  • 第 Ⅴ 部 : スケーリング
    • 14章 : スケーリング:変曲点
    • 15章 : スケーリング:誤解と問題解決
  • 第 Ⅵ 部 : devops文化への架け橋
    • 16章 : devopsの4本柱を使って架け橋をつくる
    • 17章 : devops文化への架け橋:ストーリーから学ぶ
    • 18章 : devops文化への架け橋:人と人のつながりを育てる
    • 19章 : まとめ
    • 20章 : さらに深く学習するために

DevOps と devops

本書のタイトルは「Effective DevOps」だし,僕が今までブログ記事や発表資料に書いてきた表記も「DevOps」だけど,本書(タイトルを除く)では「devops」に統一されている.本書の冒頭に「Dev と Ops の対立ではなく,ビジネスを持続可能に進めていく手法」として,意図的に小文字表記にしたと書かれていた.とは言え,個人的に見慣れた表記は「DevOps」なので,本記事では「DevOps」に統一する.

誤解と問題解決

本書全体を通して興味深いのは,DevOps に対する「誤解」を問題提起し「問題解決」のために「誤解」を紐解くという観点でまとまっているところで,ある意味「アンチパターン集」としても活用できる.逆に言うと「こうすると DevOps である」という明確な定義はなく,そこは組織ごとに考える必要がある.

DevOps に対する誤解

本書には,よく聞く「DevOps の誤解」がまとまっていて,読みながら何度も頷いてしまった.その一部を以下に紹介する.

  • DevOps はチームである
  • DevOps は肩書だ
  • DevOps はウェブ系のスタートアップだけの問題だ
  • DevOps はツールの問題だ
  • DevOps とは自動化のことだ

確かに最近だと「DevOps = 自動化」というコンテキストの発表も多いけど,正確には「自動化も重要だけど,組織の透明性やコラボレーションを意識しないと,自動化が未知のリスクになる」と書いてあり,考えさせられる.また,僕自身も2017年に一時期「DevOps エンジニア」と自己紹介をしていた時期もあり,恥ずかしくもある.

4本柱

本書では「DevOps とは何か?」という概論と歴史の紹介に続き,サブタイトルにもある「4本柱」の解説があり,以下のように定義されている.記事の冒頭にも書いた通り,文化面の話が中心になっている.それぞれ紹介していこうと思う.

  • コラボレーション
  • アフィニティ
  • ツール
  • スケーリング

4本柱「コラボレーション」

4本柱の1個目「コラボレーション」は,メンバー同士うまく協力することを意味している.協力とは言え,内容は幅広く,コミュニケーションの手段(即時性/負担/コンテキストなど)を適切に選んだり,傾聴を通じて共感と信頼を育てたり,双方向メンタリングを行うなども紹介されている.

特に「人それぞれ異なる目標(モチベーション)を持っている」という話は,今までも意識してきたものの,改めて考えさせられた.具体的には,現在のキャリアを重要視している人もいれば,カンファレンス参加などのネットワーキングを重要視している人もいれば,収入のための仕事であると割り切っている人もいる.エンジニアリングマネージャーやプロジェクトリーダーにも役立つ内容になっている.

なお,コミュニケーションの手段としては,即時性の観点で「雑談」も入っていたらもっと良さそうだなと思う.僕自身は「雑談」を大切にしていて,以下のような内容を発表したこともある.

f:id:kakku22:20190531014953j:plain

kakakakakku.hatenablog.com

4本柱「アフィニティ」

4本柱の2個目「アフィニティ」は,チーム間の関係を築き,チーム目標の違いを乗り越えることで,4本柱の1個目「コラボレーション」の延長線上にあるとも言える.

「アフィニティの誤解」の中に「運用エンジニアは企業にとって開発者ほど役に立たない」という内容があるが,過去の経験として,運用エンジニアに限らず,特定のチームの価値を正しく理解できず,必要性を疑ってしまったこともある.今になって,うまく関係を築けていなかったなと反省している.心理的安全性という言葉でまとめるのが適切かどうかはわからないけど,チーム間の相互理解に悩みがあれば,読んでみるのが良いと思う.

4本柱「ツール」

4本柱の3個目「ツール」で,やっと技術面の話だ!と思うかもしれないけど,文化を改善するために目的意識を持ってツールを選定しようという内容になっている.DevOps を支える技術の詳細に興味があれば,例えば「Infrastructure as Code」などを合わせて読むと良さそう.

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

読み進めていたら「ツールの選定」という内容に興味を持った.ツールを選定するときに,機能の有無や予算だけではなく,以下を考慮するべきと書かれていた.確かに「バージョンアップの頻度」「プルリクエストの滞留具合」などは気になるし,日本語の解説記事なども,少なければ積極的に書くモチベーションには繋がるけど,ツールを選定する立場になると,コミュニティの健全性もしくは浸透度を考える必要もありそう.

  • 製品の開発状況
  • コミュニティの健全性
  • 内部でのカスタマイズの可能性

また,自動化に対するスタンスとして「残りものの原則」という表現が紹介されている.「自動化に適切ではないタスクもある」という納得できる話なんだけど,引用元の論文タイトルに笑った.「Automation Should Be Like Iron Man, Not Ultron」ってもう.

queue.acm.org

4本柱「スケーリング」

4本柱の4個目「スケーリング」は,もしかしたら「インフラストラクチャのスケーリング」をイメージするかもしれないけど,組織変革など,組織が成長していくことを意味している.育成や採用,報酬やカルチャーフィットなど,どんな組織規模でも悩む内容がまとまっていて,一読の価値がある.

また「スケーリングの誤解」の中には「改革を始めるためには経営陣の全面的な支持が必要だ」という内容もあり,本書にも書いてある通り,裁量を与えてもらうべき場面と経営陣を巻き込むべき場面があり,適材適所に判断するのが良いと思う.個人的にも似た経験があり,以下にリンクを載せておく.全ては組織規模とフェーズによって異なると思う.

developers.cyberagent.co.jp

kakakakakku.hatenablog.com

まとめ

  • 「Effective DevOps」を読んだ
  • 本書は「DevOps」をテーマにしつつ,本質的には「DevOps の文化面」を事例と共に深く学べる内容になっている
  • 特に「誤解」「問題解決」という観点でまとまっているのは過去の経験を想起しながら読むことができて非常に良かった

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方