もりはやメモφ(・ω・ )

インフラなエンジニアからSREへ

『ザ・コーチ』を読みました、サクッと読めてやる気が高まり、行動に繋がる良書

『ザ・コーチ』 谷口 貴彦著 を読んだので感想をメモ www.shogakukan.co.jp

”目標の達人” って言葉が読み終わった後にしっくりくる

本書のサブタイトルは「最高の自分に出会える『目標の達人ノート』」ですが、正直に言って読む前は胡散臭さを感じました。自己啓発本と呼ばれるカテゴリーよりは技術書を読んだ方がマシとの偏見を自覚していて、その流れから本書のサブタイトルには懐疑的な状態で読み進めました。

結果、読み終わった後の感想としては「すごい良書、目標の達人になりたい!ならなくちゃ!なってやる!!」だったのでやはり読んでよかったです。

ストーリーと軽快な文章でサクサクと読み進められた

『1分間マネージャ』の時にも感じましたが、良書と呼ばれるものの多くは読みやすさに優れていて、かつ本のボリュームも重厚ではなくて1-2時間でおさまるものなのかもしれません。

これまた技術書との比較になりますが、時には手を動かして手元で検証したり、本の内容を理解するために別の文献を(Googleが多いですが)当たったりする技術書とは異なり、空き時間でスラスラと読み切れるボリュームでした。

目的・目標・ゴール・夢・ビジョン

目的・目標・ゴール・夢・ビジョン、この5つの言葉を自分なりに理解したつもりになれれば、本書を読む恩恵の50%は手にしたと言えると思います。箇条書きにしてしまうと味気ないですが、後で思い出すためにあえて自分の言葉で記録しておきます。

  • 目的: やりがい、いきがい、のような生涯を通して目指すことがら。具体的でなくてよいはず(例、家族を幸せにする、楽しく生きる)
  • 目標: 目的に到達するために到達すべき状態、具体的であり、かつTodoのようなやるやら評価をしない(食べるのに困らない程度の給与を手にする)
  • ゴール: 目的に到達するための、決定的な目標
  • 夢: 雑然とした個人的な望み。レベル感もまちまち
  • ビジョン: 目的に到達した時や、ゴールを達成した時を想像すること。それによりモチベーションを高めて、自らを前進させる

目的から分解されていき、具体的な行動目標となる、かと思いきや目標が通過地点である

多くの考え方の面白さを味わえる本書ですが、特に良かったのが”目標は通過点”という表現です。 目的に向けてやることを整理し、細かな目標を計画してそれに邁進するのは仕事でもよくあることでしたが、本書を読むまでは「目標は達成するか、しないか」と考えていました。期日までに行うことを具体的に決めて、それが期日までにできなければアウト、といった考え方です。

それを本書では「通過する状態」として表現したことで、柔らかい思考で目標に向けて行動を続けられることを認識させてくれました。

加えて、その「通過する状態」に対しての日常的な問いかけとして以下の3パタンを設けることで、適宜行動を修正しながら進めることを良しとしていることは、アジャイルなどの不確実性に対して常に修正しながら細かなアウトプットを出していくことにも通じるのだと感じました。

  • どうすればその目標の状態になれるだろうか?(Howを考える)
  • どうすればさらに早くその目標の状態に近づけるのか?(改善をおこなう)
  • 目標の状態に近づくために、今日、自分は何をやったか?(振り返り)

目標はゴールを知識・ツール・能力に分解した後にそれぞれを変換したもの

本の内容的には順番が前後しますが、ゴールを掲げた後で、それを知識・ツール・能力の3方向から要素に分解していき、それを目標に変換することについても学びがありました。正直にいうとここは読んだつもりで頭に入っておらず、今ブログを書くことで読み直すことができました。やはり振り返りは大事ですね。

一見すると知識と能力は同じに思えますが、知識はインプット、能力はアウトプット(力)と捉えるとスッキリしました。(ここは私なりの定義であるため、著者の意図とは多少のズレがあるかも)

ツールは知識と能力を高めるためのあらゆる具体的な物や手段で、参考書や計画表、このブログもその一つと言えるでしょう。 その3方向からゴールとして掲げた「目的にいたるための決定的な目標(状態)」へ自分を届けるために、あらゆる要素を列挙したうえで、その要素を「ゴールに到達するための通過する状態=目標」として定義する。

....こうして書くと言葉遊び感がなきにしもあらずですが、しかし本書を読むと、これがしっくりときますし、実際にモチベーションにつながるのですから驚きと言えます。

まとめ

ただ本を読んだだけでは何も変わらないのですが、そこから学び、その後の行動を変えることができます。 本書は基本的に前向きではあるのものの、多忙や生来の近視眼的な性格から迷走しがちな自分にとって、目標を掲げるノウハウを理論的に教えてくれた素晴らしい本でした。

本書の言葉を借りるなら「効果的な目標を立てるための知識」を効率よく学ぶために大変効果的な「ツール」であると言えますので、前に進みたい方にお勧めできる一冊です。

『データ視覚化のデザイン』を読みました

『データ視覚化のデザイン』 永田 ゆかり(著) を読みましたので感想をメモ。

www.sbcr.jp

最初にまとめな感想

読み切った直後のツイートを貼っておきますが、データ分析者やプレゼン資料を作る人だけでなく、読み手としても日常生活に活用できる情報が大量にありましたので、広くお勧めできる一冊です。

本書を読もうと思ったきっかけ

認知したのはTwitterでTLに流れてきたことですが、読もうと思ったのは日頃からMackerelやDatadogやその他モニタリングSaaSでグラフをたくさん見ており、かつ自前のダッシュボードを整備していく矢先だったためです。

冒頭から学びしかない

1章「データ視覚化 キモのキモ」を読んだ時点で大量の学びがあり、以下は読みながらメモった語群です。

  • アンスコムの例(Anscombe's Quartet)
    • 数字だけでは違いがわりづらいデータを、視覚化することの偉大さがわかる代表例


  • カラーパレットも種類がある
    • シーケンシャルカラー
    • ダイバージェントカラー(中間からレンジ、2色のシーケンシャルカラー)
    • カテゴリカルカラー
    • ハイライトカラー(特定のデータだけ色を付ける)



  • 認知的負荷を下げる
    • これが最大の方針
    • データインクレシオ が少なければ少ないほど良い


  • ゲシュタルトの法則
    • 近接の法則(Law of Proximity)
    • 類同の法則(Law of Similarity)
    • 囲みの法則(Law of Enclosure)
    • 閉合の法則(Law of Closure)
    • 連続の法則(Law of Continuity)
    • 接合の法則(Law of Connection)

特に感銘を受けたのが”ポリティカル・コネクトレス”の部分で、色覚異常や性別、人種、国家などなどに対する中立的な表現を心がけることへの言及は、なんとなくは体感していたものの改めて認識することができたのは素晴らしい体験でした。

2章からは役に立つ技法の宝庫

1章で色や視覚の理論について学び、2章からはグッと技術的な内容でした。視線の移動や色使い、チャート選択などのノウハウがつまっていました。以下は読書しながらメモった語群です。

  • 色は3−4色に抑える
  • テキストの活用
  • ラベル付けで罫線を無くす
  • BaN
  • "ダッシュボードとは「データを見て理解を促進させる視覚的表現」と定義した"


  • ダッシュボードは二種類
    • 探索型(Exploratory)
    • 説明型(Explanatory)



  • 視線の遷移はFで、左上から
    • ゆえに左上に重要なデータを置く


  • ファネル(漏斗)チャートはステップごとの減少が分かりやすい(どこで失注したか)
    • 日本では利用が少ないが使いどころがあるチャート
  • eNPS - Employee Net Promoter Score
    • 従業員エンゲージメント


  • リッカート尺度
    • いわゆる5択のアンケート。満足している、していない。。。


  • ベンフォードの法則
    • 1で始まるものが多い


  • モバイルデバイスならではの仕様も意識する
    • 小さな画面で伝えたいことをさらに絞る

最終章が「どうやって組織へ根付かせるか」ですごい

最終章の5章「本当に組織に根付かせるために」もとても良い内容です。技術書の多くは技術についてのみ語られていて、それをどう活用していくかは読み手に任されていることが多いと考えていました。

本書では”視覚化”のための技法などに終始せず、それを組織にどのように根付かせるかについても言及されており

  • オーディエンス(利用者)を徹底的に意識すること
  • 統一感
  • フィードバックの重要さ
  • アジャイル的発想でスモールスタートする
  • 経営層のコミット

などのキーワードを押さえながらデータ活用に向けた要点が語られており、見られなければ意味がない”データの視覚化”について、見せながら進化させていくことの大切さを意識させられつつ読了しました。

まとめ

本書を読み終わって2週間ほどが経過していますが、日常や仕事で早くも効果を実感しています。それは以下の様なケースです。

  • 同僚氏のプレゼン資料のレイアウトレビュー
  • DatadogやMackerelなどのダッシュボードの読み方、作り方
  • 日常生活で見るさまざまなグラフやチャートの読み方

今後も本棚に置いて時々手にして思い出すことになる良書だと感じています。おすすめです。

Ansible で複数台サーバの結果を順番(Sequential)に取得する

ansible コマンドって便利なんですよ

日頃から大量のサーバを管理する中で、Ansible の Adhock な実行はとても便利です。 もちろんサーバの構成管理であったり、Packerから呼び出す初期セットアップとしての Ansible Playbook も愛用していますが、なんだかんだでワンライナーとしての ansible コマンドも運用に欠かせません。

良くあるケースとして以下などがあります。

  • shell モジュールを活用したログの一括...
    • grep で設定ファイルのパラメタ確認
    • ps などでサーバの状態確認
    • ls などでファイルの作成有無
  • fetch モジュールを利用した設定ファイルの一括取得
  • service モジュールを利用したアプリの起動/停止

しかし、そんな便利な ansible コマンドですが少々悩みがありました。

課題: 便利なんですがちょっと使いづらいところ

何が使いづらいかというと、 ansible コマンドの結果がデフォルトでは順番になりません。サンプルとしては以下のような結果です。 本当は01から09まで順番に出て欲しいのですが、完全にバラバラです。

これは DEFAULT_FORKS で実行時の並列数が5となっており、同時に実行された結果がばらばらに返ってくるためです。

[morihaya@morihaya ~]$ ansible -i inventories/all morihaya0? -m shell -a "date"
morihaya04 | CHANGED | rc=0 >>
Sun Aug 23 20:40:09 JST 2020
morihaya07 | CHANGED | rc=0 >>
Sun Aug 23 20:40:09 JST 2020
morihaya05 | CHANGED | rc=0 >>
Sun Aug 23 20:40:09 JST 2020
morihaya06 | CHANGED | rc=0 >>
Sun Aug 23 20:40:09 JST 2020
morihaya09 | CHANGED | rc=0 >>
Sun Aug 23 20:40:09 JST 2020
morihaya02 | CHANGED | rc=0 >>
Sun Aug 23 20:40:09 JST 2020
morihaya03 | CHANGED | rc=0 >>
Sun Aug 23 20:40:09 JST 2020
morihaya01 | CHANGED | rc=0 >>
Sun Aug 23 20:40:09 JST 2020
morihaya08 | CHANGED | rc=0 >>
Sun Aug 23 20:40:09 JST 2020
[morihaya@morihaya ~]$

対策: 並列で順番がバラバラになるなら1つずつやれば良い

当初はansible.cfgに以下のように記載することで対応しました。

[defaults]
forks = 1

それに対してAnsible界のスーパー金魚さんから -f <N> を教えてもらいました。

ドキュメントの Docs » User Guide » Working with command line tools » ansible を参照して以下を確認しました。

  • -f , --forks
    • specify number of parallel processes to use (default=5)

つまり、コマンドの実行時間が伸びることもありますが、以下のように -f 1 を付与することで、サーバの順番が綺麗に並んだ結果を得られるのです!!

[morihaya@morihaya ~]$ ansible -i inventories/all morihaya0? -m shell -a "date" -f 1
morihaya01 | CHANGED | rc=0 >>
Sun Aug 23 21:03:41 JST 2020
morihaya02 | CHANGED | rc=0 >>
Sun Aug 23 21:03:43 JST 2020
morihaya03 | CHANGED | rc=0 >>
Sun Aug 23 21:03:45 JST 2020
morihaya04 | CHANGED | rc=0 >>
Sun Aug 23 21:03:48 JST 2020
morihaya05 | CHANGED | rc=0 >>
Sun Aug 23 21:03:50 JST 2020
morihaya06 | CHANGED | rc=0 >>
Sun Aug 23 21:03:52 JST 2020
morihaya07 | CHANGED | rc=0 >>
Sun Aug 23 21:03:54 JST 2020
morihaya08 | CHANGED | rc=0 >>
Sun Aug 23 21:03:56 JST 2020
morihaya09 | CHANGED | rc=0 >>
Sun Aug 23 21:03:59 JST 2020
[morihaya@morihaya ~]$

余談: 順番を意識する必要を本当はなくしたい

クラウドネイティブな今の時代、本来であればサーバの順番やホスト名を意識することは良くありません。数年前は "cattle vs pets" という言葉も良く見かけましたが、クラウドでサーバが簡単に使い捨てができ、コンテナがそれをさらに加速し、オンプレミスであってもESXiなどでVMの使い捨てができる現在では、サーバそれぞれに名前をつけて大事に運用するのは良い方法ではないことも認識してます。

...が、そうもなかなかいかないのも事実で今回のようなハックが必要でした。*1

*1:例えば奇数系と偶数系のサーバでDBへのアクセスを分散してたりするわけですね

AWS CodeCommitで不要なブランチを一気に削除する

プライベートなGitLabからCodeCommitへ移設したとあるリポジトリについて、大量のブランチがあって今すぐ消したい!!となったので簡単なシェル芸で対応したのでメモ。

課題: 直面したブランチ多すぎ問題

例えばこんな感じだった。

  • 謎のポリシーでブランチを消さない文化で育ってしまったリポジトリ
  • ブランチ確認のページ数がたくさん
  • CodeCommitのGUIでは、ブランチ削除は1つずつしかできない <-たくさんやるには超大変

f:id:morihaya:20200817224106p:plain

大量にあるブランチに対して一つずつ確認画面でぽちぽちやるのは辛すぎる f:id:morihaya:20200817224515p:plain

対策: AWS CLIと簡単なシェル芸

結論としてはこう。

# 対象のリポジトリ名を設定
REPOSITORY=morihaya-test

# ループで回す
for BRANCH in $(aws codecommit list-branches --repository-name ${REPOSITORY} | jq .branches[] -r | grep -vE "master|<消したくないブランチ>")
do
  aws codecommit delete-branch --repository-name ${REPOSITORY} --branch-name ${BRANCH}
done

雑な解説

以下でブランチ一覧を取得。

aws codecommit list-branches --repository-name ${REPOSITORY}

jqに渡してJSONからただの文字列の一覧に皮むき。-r でクォーテーションを外したのはただの癖。

 | jq .branches[] -r 

以下は削除したくないブランチを除外するためのgrep。masterブランチは守られているので実は除外不要。

| grep -vE "master|<消したくないブランチ>"

実際に削除を行うのはこのコマンド。

aws codecommit delete-branch --repository-name ${REPOSITORY} --branch-name ${BRANCH}

余談

余談1

実はmasterブランチも勢いで消してしまいかけたのですが、Default Branchは以下のエラーで守られているので安心でした。

An error occurred (DefaultBranchCannotBeDeletedException) when calling the DeleteBranch operation: The current default branch refs/heads/master cannot be deleted

余談2

作業自体は会社のリポジトリでしたがさすがにスクショはまずかったので、テスト用のリポジトリを作成してブランチを増やしました。 コマンドは対策と似たようなシェル芸です。

# 対象のリポジトリ名を設定
REPOSITORY=morihaya-test

# 複製するCommitのIDを指定する
COMMITID=XXXXXXXXXXX

# ループで回す
for NO in $(seq 1 50)
do
  aws codecommit create-branch --repository-name ${REPOSITORY} --commit-id ${COMMITID} --branch-name test-${NO}
done

余談3

削除した時はメッセージがでるが、作成した時はなにもでないらしいです。 aws-cliのバージョンは2.0.40で確認。

bash-3.2$ aws --version
aws-cli/2.0.40 Python/3.8.5 Darwin/19.6.0 source/x86_64

削除する時は以下のようなメッセージがでる。

{
    "deletedBranch": {
        "branchName": "test-5",
        "commitId": "XXXXXXXXXXXXXXXXXXXX"
    }
}

まとめ

作業時間短縮のための雑なCLIは正義だと思っているし、ちょっとしたシェル芸は身を助けますね。

『1分間エンパワーメント』を読みました

ダイヤモンド社の『社員の力で最高のチームをつくる〈新版〉1分間エンパワーメント』を読みました。

www.diamond.co.jp

https://www.diamond.co.jp/images/book/7/9784478100677.jpg

先週読んだ『1分間マネージャ』と同じ著者 ケン・ブランチャード氏のシリーズです。 きっかけは以下で、同僚の @kobase555 からお勧めしてくれた&図書館にあったのですぐに読むことにしました。*1

エンパワーメントってなに?

タイトルでもある”エンパワーメント”という言葉ですが、私は初耳でしたし、単語を聞いてもいまいち内容を想像できませんでした。 ”エンパワーメント”の定義については本文の1ページ目できちんと紹介されます。それによると

エンパワーメントとは、自立した社員が自らの力で仕事を進めていける環境を作ろうとする取り組みです。

とのことで、わかるような気はするがどういうこと?という疑問を抱きながら読み進めることになりました。

1分間マネージャとの違い

同じ著者とのことで『1分間マネージャ』との違いを意識しながら読みましたが、冒頭から監訳者の星野リゾート代表 星野 佳路氏のまえがきで始まることもあり、全体的にマネージャよりもさらに上位、経営者向けの内容だと感じました。 要点だけなら星野氏のまえがきでほぼ語られているくらいにはシンプルな内容で、以下の3つの鍵がエンパワーメントの鍵として提示されます。

  1. 全ての社員と情報を共有する
  2. 境界線によって自立した働き方を促す
  3. セルフマネジメントチームを育てる

このシリーズはサクサク読める(2作しか読んでないけど)

『1分間マネージャ』を読んだ時にも感じましたが、本書も読みやすい文体でサクサクと読めました。 私は章を区切りに他のこともしながら読みましたが、読了までに実時間では3時間も要していない印象です。*2

本の構成として、悩める経営者の主人公がエンパワーメントに成功した会社を訪問し、トップおよび各所のマネージャ達と苦労と成功の経験談を聴きながら、自分たちの課題にどう向き合っていくかを考えていくシチュエーションは『1分間マネージャ』と同じで、構成的な登場人物とのコミュニケーションは分かりやすくて映像が浮かぶような楽しさがありました。

刺さったポイント

特に面白いと感じた2点つについてメモしておきます。

1つは「5 第2の鍵 境界線によって自立した働き方を促す」の章です。 この章では”境界線”について語られており、自由な裁量を社員に与えはするもののそれは何をやってもいいわけではなく、明確な目的やビジョンの元に定義された境界線の中での自由である事や、ガイドラインによって方向性がある程度は定まった方がより強い力が出るといった事が語られます。

では実際にどのように境界線を決めるのかという具体例として、コンビニエンスストアを例題に経営者側と労働者側の双方から10個ずつ仕事を書き出すという”トップ10プランナー”というリストのすり合わせがあり、その目線の違いが対照的に提示されてとても印象的でしたし、読者へ気づきを促していたように感じました。


もう1つは「監訳者のあとがき」で、まえがきも書かれていた星野氏による星野リゾートのエンパワーメントの旅が書かれており、舞台が日本の地方の温泉旅館と大変親しみが湧きやすくて全体的にイメージがしやすかったです。その中でも特に面白いのが自律的な改善行動を始めた社員からのコストが増える提案に対して「社員達の目は輝き始めているのに、(経営者である)私の目が曇り始めるという逆転現象が起こったのだ。」の部分です。

この”やる気から出てくるコストを(深く)考えない提案”は自分もやってきたことでしたし、その都度上役からコストと効果についてのバランスについて考慮を促されたことが記憶に蘇りました。

あとがきの中ではその状況への対策として会社の収益情報を社員に公開しつつ、明確なコストと利益の関係を共有と教育する事でより精度の高い提案を社員に促した、という流れが大変良かったです。

さいごに

本書を読むことで、平社員である自分からすると少し目線が上に伸びる体験と、かつエンパワーメントされる側としてどのように感じて行動することが良いのかを考える良い機会になったと感じています。

また、自分の現在置かれてる環境を振り返ると、結構エンパワーメントされた環境であることに気づくこともできましたので、これも大変よい学びでありました。

*1:友人や同僚など、身近な人のお勧めというのはできるだけ実際に手を伸ばしたいマインドがあります、社交辞令で終わってしまうのは勿体ないので

*2:私の読書スピードは平均より早い方ではないはず

『新1分間リーダーシップ』を読みました

『新1分間リーダーシップ』を読んだので所感をメモしておきます。

www.diamond.co.jp

読むまでの動機

動機はいくつかありまして以下が大きいです。

  • 4月からマネージャって肩書きがついた
  • マネージャなんもわからん
  • SRE Nextで聴いたそのっつさんのマネージャ目線の素晴らしいプレゼンのなかで紹介されてた*1

読んでみて

期待以上にサクッと読める良書でした。わかりやすい分類とそれぞれに対する手法が読みやすい文体で紹介されており、迷ったときの参考例としてふとしたときに思い出せるようなノウハウが学べたと感じています。*2

状況対応型リーダ

”状況対応型リーダ”の言葉自体は本書で知りましたが、メンバに対して画一的な対応を行わず、それぞれにあったやり方を行う点は漠然と「それはそうだろう」と思ったので期待せずに読み進めたところ、人だけでなく、その人が対応するタスクによってどの段階かを整理し、指導方針を本人との合意の上で変化させていく点が興味深く納得感を得ました。

個人的にもちょうど2020年の上期が終了し、初めてメンバを評価する*3責務を終えたばかりだったこともあり、組織にとって人材を評価し、査定を行う過程で最終的には形式的なランク付けをする必要があることを体感していた事も納得感につながったのでしょう。*4

社会人になってからのキャリアを振り返ると、基本的にはプレイヤとしてパフォーマンスを出していくことに取り組んできたのでこれは新鮮な体験でした。

求められる3つのスキル

前半部分で状況対応型リーダに求められる主要スキルは以下の3つだと説明があります。

  1. 目標設定
  2. 診断
  3. マッチング

目標設定

”始め半分”なんて言葉もありますが、本書でも目標の重要性が語られており、それは”SMART”という語呂合わせで紹介されています。 詳細は省きますが項目だけ並べると以下の通りで、これらを満たした目標を設定するように心がけるべしとありました。

  • Specific - 具体性
  • Motivating - 動機付け
  • Attainable - 達成可能性
  • Relevant - 関連性
  • Trackable - 追跡可能性

字面だけだと分かりづらかったのが”関連性”で、これは会社、チーム、他のタスクとの関連性のことで、良い効果があるか、優先度は高いかを意識しましょうと理解しました。

診断

SMARTで適切な目標を設定した後は、診断してマッチングをしながらコーチングをするフェーズです。

診断では以下の2つの軸から、

  • 技術
  • 意欲

以下の4つのレベルに診断し、

  1. 技能(低) 、意欲(高)
  2. 技能(低から中)、意欲(低)
  3. 技能(中から高い)、意欲(不安定)
  4. 技能(高)、意欲(高)

それぞれに合ったコーチング(付き合い方)でマッチングさせていくとありました。これは一見するとシンプルに分割しすぎているようにも感じましたが、以下のように考えるとある程度納得できました。

  1. 「やっていき」
  2. 「力ついてくるけど飽きてくる」
  3. 「”完全に理解した!”と”何もわからん”」
  4. 「チョットデキル」

マッチング(付き合い方)

診断した後は、フェーズにあった付き合い方をすべしとのことで、4つのやり方を柔軟に使い分けましょうとあります。*5

  1. 指示型
  2. コーチ型
  3. 支援型
  4. 委任型

本書ではそれぞれの型について登場人物を変えながらわかりやすい説明がされており、考え方として参考になりました。

プレイヤとしての自分は基本的に”委任型”が最も好きなやり方で、困ったときだけ”コーチ型” or "支援型"を相手に感謝しつつも申し訳ない気持ちで受け入れるようなところがありましたが、トータルで考えると初速を他者からの指導で加速するのは総合的にメリットが大きいことを体感することが多いです。*6

さて、自分を振り返るとシンプルじゃない感

ここまでざっと書いてきたように、本の中では箇条書きにできてしまうようなシンプルな分類やノウハウが紹介されており、それらはわかりやすくて参考にはなりましたが、自分で消化して多少なりとも良い方向に持って行くかを検討すると「これは大変だな」となります。

みんな基本的に自分より強い

素晴らしいことに、自分より優れてるスキルを持った人ばかりなので全部”委任型”でいいじゃんとなりがち問題があります。

しかしこれは思考放棄だと思い直して、対応するフェーズやタスクが求めるスキルによっては意識的に”委任型”だけではないやり方を模索したいです。

目標設定むずかしい

書内の”SMARTな目標設定”については納得感を持ったものの、実際の組織としての目標設定とは文脈が異なる部分もあって、SMARTエッセンスを適用して考えると結構足りてない部分がすでにありました。

一番難しいと感じているのが’T’の”Trackable(追跡可能性)”で、目標に対して適切な計測指標を設定して、進捗を可視化するのは、目標の質にもよりますが難しい部分もあるなと。

ただ、これはそのままSREの文脈でいうSLI/SLOの話でもあって、それを専門とするチームでもあるはずですから、そんなチームの目標のTrackableがゆるふわなのは苦々しいのでチームで少しずつ修正していく。

まとめ

冒頭にも書いた通りで、シンプルでわかりやすいエッセンスが詰まった良書でした。

読んだだけでは何もならず、日々のなかで自分なりの行動につなげていく必要があるのと、杓子定規に頭でっかちになるまいという自戒も味わえた点で価値ある読書体験になったと言えます。よっておすすめです!

余談:今一つふに落ちないエピソード

”委任型”についての解説でちょっとしたエピソードが紹介されているのですが、この落ちの面白さがわからずにもやっとしました。

とある家庭(両親と幼い娘さん)の話で、母親が家に仕事を持ち帰って夜遅くまで働いているのをみて娘が「お母さんをできない子のグループにすればよいのに」と父親に言うのが面白ポイントで、さらに「だったら、もっと委任すれば良いのに」がより良い回答として落ちとして提示されます。

ここの解釈は以下だと考えていますが、確信には至っていません(どうでもいいですね...)*7

  • 母親は、忙しいのだからもっと他のメンバに委任するべきだった?
  • 母親を「できない子グループにいれる」発言をする娘さんの大人びた発言が面白ポイント?

*1:本当に素晴らしい発表だったし、動画も公開されてます

*2:一方で人間こんなシンプルでもない感もあります

*3:評価と書くと多少語弊があって、会社に対してメンバがどのように貢献し、成長したかを伝えるための文章を書いたがより近い表現

*4:考えてみれば小学生から通知表で無機質な数値にランク付されてきたのだけれど感覚を忘れていた

*5:sonotsさんの資料ではこの部分を引用されていた

*6:新しい技術を教えてもらうことを通して

*7:もやっとして妻にも相談したところ「こんな発言をする娘さんが一番心配」と言われて、それはふに落ちました

Dockerが利用するサブネットを変更する

EC2で稼働していたDockerのサブネットを後から変更したのでメモします。 大体はこちらのブログの通りです。感謝。

support.getjoan.com

経緯

Apache Guacamoleという便利なソフトウェアをご存知でしょうか。簡単に言えば「RDPやVNCの集約ツール」です。WindowsやGUIを有効にしたLinuxなどへのログインを集約できます。

guacamole.apache.org

いずれEKSに載せようと思いつつも、適当に立てたEC2にdocker-composeでインストールした状態で便利に利用していたのですが、特定のサブネットのサーバにだけアクセスできない問題が発生していました。

  • 同じサブネット = 同じRouteTable
  • 同じSG

のEC2からは問題なく疎通ができていたので不思議に思ったのですが、基本に戻ってサーバのルーティングテーブルを確認したところ、Dockerが利用しているサーバ内部のネットワークと、接続できないサーバのネットワークアドレスが重複していました。

これを受けて、Dockerが使用するサブネットの変更を行うことにしました。

なおdocker-compose.ymlについてはGitHubでスターを集めていた以下を少し改変したものを利用しています。こちらも感謝。

github.com

手順

基本的な流れは以下の通りです。

  1. 稼働中のコンテナを停止
  2. 1で消えなかったネットワークがあれば docer network rm で削除
  3. /etc/docker/daemon.json を作成して default-address-pools を指定
  4. docker restart
  5. コンテナを起動

稼働中のコンテナを停止

まずは起動中のコンテナを停止します。docker-composeを利用していたので、 docker-compose down でNetwork Interfaceも削除します。 もちろん停止前にアプリケーションについてはバックアップを行うべきです(今回はGuacamoleのPostgresは事前バックアップ済みでした)

$ cd <docker-compose ファイルのある場所>
$ docker-compose down

ログは以下のような形ででます。

[root@morihaya-101 guacamole]# docker-compose down
Stopping guacamole_guacamole_1 ... done
Stopping guacamole_postgres_1  ... done
Stopping guacamole_guacd_1     ... done
Removing guacamole_guacamole_1 ... done
Removing guacamole_postgres_1  ... done
Removing guacamole_guacd_1     ... done
Removing network guacamole_guacnetwork_compose

消えなかったネットワークがあれば docer network rm で削除

以下のコマンドで、Dockerのnetworkがきれいになったことを確認しましょう。 残っていた場合は docker network rm xxxx で削除します。

ip a
docker network ls

/etc/docker/daemon.json を作成して default-address-pools を指定

daemon.jsonを作成し、Dockerが利用するネットワークを指定します。既存システムが使わないものにしましょう。

vim /etc/docker/daemon.json

jsonの内容は以下です。IP部分はシステムによりますね。

{
 "default-address-pools":
 [
 {"base":"10.254.0.0/16","size":24}
 ]
}

docker restart

dockerを再起動します。

systemctl restart docker.service

コンテナを起動

コンテナを再起動します。

docker-compose up -d

これで無事に既存システムと重複しないサブネットでコンテナを起動することができ、疎通も行えました。

余談

Apache Guacamoleですが、リリース周期は1年ごとと勝手に思っていたところ、5ヶ月間で1.20をリリースしていたのに気付きました。

  • 0.914 (2018-01-18)
  • 1.00 (2019-01-08)
  • 1.10 (2020-01-29)
  • 1.20 (2020-06-28)

guacamole.apache.org

1.20の冒頭にはserverとclientにプロジェクトを分割したなどが書かれていて、開発に動きがあったようで今後も動きが活発になるのかもしれません。

Apache Guacamole is split into two subprojects: "guacamole-client", the HTML5 web application which serves the Guacamole client to users, and "guacamole-server"