生産的に働くことについて考える / 『管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう』を読んで①

ふとFacebookのタイムラインから流れてきた「管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう」という本。今まで技術書ばかり読んできていて組織や人に関する本には手をつけていなかったのですが、最近は積極的に読むようにしています。この本を読みながら改めて気付かされる点が非常に多かったため、自分のためにも書評を書きます!

目次

以下が目次となっていて、この記事では太文字の「第1部 生産的に働く ~楽に成果をあげるために“見直す”」に注目します。

  • はじめに
  • 第1部 生産的に働く ~楽に成果をあげるために“見直す”
    • やり方を見直す ~「ふりかえり」で抜本的に生産性を改善する
    • 生産性を見直す ~「時間対効果」の高い仕事をする
    • タスクを見直す ~「タスクばらし」で小口化する
    • やる気を見直す ~無理に上げない、なくさない状況をつくる
    • 信頼関係を見直す ~「心理的安全性」を生み出す環境
    • 会議を見直す ~口を動かすだけでなく、いっしょに手を動かす
    • 雑談を見直す ~ホウレンソウから「ザッソウ」へ
    • 社内業務を見直す ~人手に頼らない「業務ハック」で改善を続ける
    • 価値を見直す ~受託脳よりも提案脳で考える
  • 第2部 自律的に働く ~人を支配しているものを“なくす”
    • 管理をなくす ~セルフマネジメントで働くチームをつくる
    • 階層をなくす ~「ホラクラシー」組織を実現する仕組み
    • 評価をなくす ~個人の成長と会社の貢献の「すりあわせ」をする
    • 数字をなくす ~組織のビジョンよりも自分のためならがんばれる
    • 組織の壁をなくす ~信頼しあえる企業文化の育て方
    • 急募をなくす ~仕事があっても、いい人がいなければ採用しない
    • 教育をなくす ~自分の頭で考える社員の育て方
    • 制度をなくす ~本質ありきで考える「そもそも思考」
    • 通勤をなくす ~働く場所に縛られない「リモートチーム」
  • 第3部 独創的に働く ~常識や慣習に従うことを“やめる”
    • 既存のビジネスモデルに従うのをやめる ~納品のない受託開発
    • 顧客を説得する営業をやめる ~対等な関係を作るマーケティング
    • 新規事業の指示命令をやめる ~部活から生まれるイノベーション
    • 規模を追求することをやめる ~組織の大きさもコントロールしない
    • 会社らしくすることをやめる ~文化をつないでいくコミュニティ
  • おわりに

「精神論」でふりかえりをしてはいけない

「やり方を見直す」方法として「ふりかえり」の大切さが述べられています。

ふりかえりの4つのポイント

  1. KPT(Keep・Problem・Try)でふりかえりをする
  2. とにかく全員で出し切ることを優先する
  3. 精神論ではなく、具体的なアクションに落とし込む
  4. 週に一度、1時間のふりかえりから始める

特に3番目は多くの人が陥る問題だと思います。何か問題(Problem)があって、それを改善するための試み(Try)を考えた場合、どうしても「次はこうならないように気をつける」と精神論を言ってしまいがちです。

そういった精神論ではなく、以下のように具体的なアクションに落とし込むことが大事だと述べられています。

Problem「2日連続で寝坊してしまった」
↓
【NG】Try「早起きするように気をつける」
【OK】Try「目覚まし時計を買う」

僕もついつい「がんばる」や「気をつける」と言ってしまいがちですが、常にこの点は意識していきたいです。

100%の品質と完成度は目指さない

80%の完成度には2割の時間でよくて、残り20%を高めるためには8割の時間がかかる

というパレートの法則の引用を用いて、完璧を目指してはいけないという点が紹介されています。

ja.wikipedia.org

完璧を目指そうとすると考え込むことが多くなり、ひたすら時間だけが過ぎていくことが多くなります。また、そもそも完璧の定義自体が自分で決めたものなので、完璧かどうかなんてわかりません。

80%であってもリリースをしてみて、「もっとこうしてほしい」点や「これは必要ない」点について早い段階で見つけて改善していくことが大事だと述べられています。

最後にFacebook創業者のマーク・ザッカーバーグの引用も紹介されています。

Done is better than perfect.

この考え方は最近読んだ「エンジニアの心を整える技術」でも紹介されていて、非常に大事だと感じています。

booth.pm

作業じゃなくて仕事をまかせる

本書では「仕事」と「作業」は違うものだと述べられています。

  • 作業
    • 事前に定められた手続きに従っておこなう活動
    • 手を動かすことに価値がある
    • わかりやすい結果や指標がある
    • 進め方に創意工夫の余地がない
  • 仕事
    • だれかに価値を届けるための活動
    • 「価値とは何か」をそもそも考えなければいけない
    • わかりやすい結果や指標がない
    • 進め方に創意工夫の余地がある

作業の進め方に「創意工夫の余地がない」かどうかは議論の余地がありそうですが、僕自身も作業を依頼していることが今まで多かったかなと感じます。

作業には事前に定められた手続きが必要になるので、依頼する側の負担が大きいです。さらに、「依頼」をされると、された側は自分の仕事として考えるのが難しいと本書では述べられています。

仕事には「わかりやすい結果や指標がない」かわりに「進め方に創意工夫の余地がある」ことで、仕事をする側は 主体性をもって取り組む ことができます。

主体性をもつ→自律的に成長する→モチベーションが上がる→生産性も上がる

というような好循環が生まれる。上の表現だけでは単純に見えますが実際には「仕事の全体像や目的の伝え方」、「コミュニケーションの方法」、「フィードバック」について気をつけるべき点があり、本書では別途詳しく紹介されています。

社会人になって2、3年もすれば後輩ができたり、チームメンバーの入れ替えなどがあってコラボレーションを主体的に行っていく必要性が増していきます。そのときには作業ではなく、仕事をまかせることが大事なんだと改めて考えさせられました。

「ホウ・レン・ソウ」から「ザッ・ソウ」

本書ではホウ(報告)・レン(連絡)・ソウ(相談)の大切さについて述べられつつも、より大事なのはザッ(雑談)・ソウ(相談)だと述べられています。「雑談が大事」なのは既に知っている人も多いと思いますが、問題はどうやったら雑談を増やせるか?という点です。雑談は「よし、雑談をしよう!」と言ってなかなかできるものでは無いですし、信頼関係など前提条件が揃っている必要があります。

そこで本書では「雑談をうまくするポイント」が3つ紹介されています。

  1. 雑談と仕事の場所をツールで分けない
  2. 社内で起きている雑談の様子を見える化する
  3. 定期的に雑談する機会をつくる

雑談と仕事の場所をツールで分けない

この点についてはハッとさせられました。確かに、例えばSlackのチャンネルに「#雑談」というチャンネルがあったとしたら、そのチャンネルに投稿するということは「よし、今から雑談するぞ!」という気持ちが先に発生する人が多いと思います。もちろん人によってこれは変わるのでしょうけど、雑談をする前に「雑談 or NOT 雑談?」というオーバーヘッドが生まれるのがあまり良くないというのには納得させれました。流れるように自然に雑談ができる環境がベストですよね。

社内で起きている雑談の様子を見える化する

この点については前提として社内全体の高い信頼関係が必要だとは感じます。それが無い状態ではどうしても前節にも述べられているように、発言の前に「こんな内容(雑談)を投稿していいだろうか?」というマインドが発生してしまうからです。

また、もう一つ注意する点については、(これは雑談に限った話ではないですが)公開される情報が多くなるということはSlackのようなツールの場合にそれだけ「通知」も多くなります。これによって気になることが多くなり、生産性が落ちてしまう可能性も含まれていると思います。

f:id:kenev:20190520060707p:plain
気になる通知

そこで僕が追加で紹介したいのはポモドーロ・テクニックです。

「25分間はとにかく決めたタスクに集中し、5分間休憩を挟む」ということを1セットとして繰り返すテクニックのことです。この25分間の間、通知が来たとしても無視します。無視するというのは、Slackであれば「離席中」にして通知が来ないようにするレベルです。

この記事では詳しくは述べませんが、以下の記事がとてもよくまとまっているのでポモドーロ・テクニックに馴染みの無い人はぜひ読むことをお薦めします!

kakakakakku.hatenablog.com

話が少し逸れましたが、「雑談の見える化」は見ようと思えば誰でも見えるような状態にしておくことが一つのポイントなのかなと僕は解釈しています。これもSlackの例えになりますが、可能な限りチャンネルはすべてPublicにしておくことがその手法の一つかと考えています。「他のチームの様子はどんな感じだろ?」となったときに「チラッ」と覗けたり、チャンネルにJoinできたりする環境が大事だと思います。

この点についてはSlackのJulia Graceさんによる「Building Engineering Teams Under Pressure(英語)」という公演でも述べられていて、合わせて視聴することをお薦めします。

www.youtube.com

まとめ

「管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう」の「第1部 生産的に働く ~楽に成果をあげるために“見直す”」を読みました!個人的には「ふりかえり」することと「雑談」することが2つの大きなポイントだと感じました。「生産的に働くこと」については常に意識しつつ今後も仕事に取り組んでいきたいと思います!

また、セルフマネジメントについては、以下の記事で書きました!

kenfdev.hateblo.jp

おまけ

生産的に働くこととDeveloper Happinessも強く関連していると思います。この点については以前書いた下の記事で「Developer HappinessとEmployee Retention」というトピックでも紹介していますので興味があればぜひ読んでみてください!

kenfdev.hateblo.jp

Algolia Searchの速さに鳥肌が立った話

algolia.connpass.com

「Algolia Community Party in 京都 - 2019年5月10日」に参加し、LTしてきました!

発表資料

ストーリー

業務でAlgoliaのスパイクをうつ機会があったので、そのときに経験した 圧倒的な爆速っぷり について完全なる自己満でそのときの気持ちを伝えました!

SPA(Single Page Application)の入門チュートリアルで「検索バーでフィルタリング」する簡単なアプリを作った記憶は無いでしょうか?

下のCodePenのような簡単なフィルタリングアプリです。

f:id:kenev:20190514230100p:plain
https://codepen.io/tiana-p/full/XGJgPo

ここで検索バーに文字を入力すると、リアルタイムにフィルタリングが適用されます。 とても速いのですが、Amazon楽天市場価格.comで使うような「大量のデータから検索」する機能で同じようなUXを実現しようとすると かなり難しい です。

なぜなら、上のフィルタリングアプリは 最初から ブラウザがインメモリに持っている情報に対してフィルタリングしているのに対して、「大量のデータから検索」する場合には外部のAPIにリクエストして、さらにそのAPIが外部のデータベース内のデータを取得しにいったりするからです。これをどうにか高速化するにはインデックスを頑張ったり、キャッシュを頑張ったりと、涙ぐましい努力が必要になります。そしてその努力をしたとしても、上のフィルタリングアプリのようなスピードを実現するのはかなり難しいと思います。

なので、大量のデータから検索するときに、 ちょっと時間がかかる っていうのは「ある程度は仕方ないかな」と妥協することが多いはずです。

ただし! 外部にデータがあったとしても爆速で検索できてしまうのがAlgoliaなんです!

下のデモサイトで体験ができるのでぜひ体感してみてください。

community.algolia.com

今まで様々な技術スパイクをうってきましたが、隣の同僚にまで「これ、やばいっすよ」って感動を伝えたのはAlgoliaが初めてです。

13万件のサンプルデータを入れてみて、多少パフォーマンスが変わるかと思いきや検索には 3ms しかかかりませんでした!(ただし、ネットワークの時間を含めると20~40ms)

イベントレポート

下のイベントレポートが両者とも非常にわかりやすくまとまっています!

Algoliaの @shinodogg さんのイベントレポート

shinodogg.com

@silver_birder さん のイベントレポート

silverbirder180.hatenablog.com

まとめ

まだAlgoliaのさわりの部分しか使えていないので

  • Query Rules(「cheap camera」って検索したら「cheap」が「< 10,000」に変換できて、10,000円以内のカメラに絞れたりする)
  • Personalization(検索で行った行動などから、ユーザー毎にサジェストをパーソナライズできたりする)
  • Internationalization(多言語に対する検索インデックスの管理方法)
  • Multi-tenancy(マルチテナントなデータの管理方法)

あたりのトピックを今後は深掘りしていきたいです!

幸運な巡り合わせのおかげで突如3日前に参加&LTが決まったイベントでしたが、Algoliaの中のEiji Shinohara( @shinodogg )さんやフランスからかけつけて下さったMichaël Sokol( @_ms123 )さんともお話できて本当によかったです!

「誰」が「何」をできるかをOPAのレスポンスで返す

OPA(Open Policy Agent)で「○○をやっていいですか?」に対して「Allow/Deny」の返答がくるパターンについていくつか記事にしました。

今回は、 「誰」が「何」をしていいか をOPAからのレスポンスで知る方法について検証したので共有します。

どういった場面でこれを知りたくなるかと言うと、

例えばSPA(Single Page Application)で、 ログイン中のユーザー が「何」をして良いか知りたいときが考えられます。

この情報があることによって、

  • 新規作成ボタンを表示する
  • 編集ボタンを表示する
  • 削除ボタンを表示する
  • 特定のメニューを表示する

などの判断をSPA側で行うことができるようになります。

今回の記事で作成するPolicyもOPAのSlackでやりとりがされていた内容をちょっとカスタマイズさせてもらったものになります。

ドキュメントには登場しないようなユースケースがコアメンバーによってPlaygroundでシェアされていたりするので、OPAに興味がある方はぜひSlackに参加することをおすすめします!

slack.openpolicyagent.org

権限の定義

今回の例では以下のような状況があると仮定します。

  • article というリソースがある
  • alicearticleread できるし write もできる権限がある
  • bobarticleread する権限しかもっていない

これをOPAのRegoで表現すると次のようになります。

package foo.bar

permission["alice"] = [
    { "resources": ["article"], "actions": ["read", "write"] }
]
permission["bob"] = [
    { "resources": ["article"], "actions": ["read"]}
]

実際はこの permission をハードコードすることは無く、データベースなりどこかに保持されているところからOPAに読みこませることになりますが、Playground上で表現するために直でデータを書いておきます。

指定したユーザーの権限を取得

では、データが用意されたのでここから aliceの権限を取得 したいとなったらどうすれば良いか。 欲しいのは以下の情報です。

[
    { "resources": ["article"], "actions": ["read", "write"] }
]

OPAでは「Allow/Deny」な答えを返すことが多いのですが、オブジェクトを返すこともできます。 これがドキュメントにも書かれている「Generating Objects」をする方法です。

www.openpolicyagent.org

OPAへのリクエストの input{ "user": "alice" } とした場合に、 alice の権限が返ってくるようにするには次のようなルールを定義します。

user_permission = perm {
    perm := permission[input.user]
}

ここでポイントとなる点は user_permission = perm の、 = perm の部分です。 普通のルールの場合は key だけ指定して value 側を指定することはありません。

value 側を指定(ここで言う perm )し、その値をルールの中身で用意することでレスポンスとして返すことができます。

実際に試してみましょう!下図はPlayground実行している様子です。

PlaygroundにはちょっとしたTipsがあって、図のように、選択した部分のルールのみを実行してOutputを確認することができます。

f:id:kenev:20190506222034p:plain

下記リンクからPlaygroundが実行できるので、ぜひ試してみてください!

play.openpolicyagent.org

Inputを

{
  "user": "alice"
}

としたことで、 user_permission のみを実行した結果が

[
  {
    "actions": [
      "read",
      "write"
    ],
    "resources": [
      "article"
    ]
  }
]

となり、 alice の権限がレスポンスとしてオブジェクトで返ってきているのがわかります。

また、 bob であれば以下のように、 article に対して read しか許可されていないのがわかります。

[
  {
    "actions": [
      "read"
    ],
    "resources": [
      "article"
    ]
  }
]

このように、「Allow/Deny」のレスポンス以外にも、オブジェクトでレスポンスを返すことができるということもわかりました!

そして、例えばこのレスポンスを使ってUI側では

  • write があるから新規作成、編集、削除ボタンを表示する

という処理が書けて、ログインしているユーザーの権限に応じて画面の見た目を変えることができます。

やっていいかどうかの判断

「誰」が「何」をしていいか を確認する方法についてはこれでOKですが、実際に「やっていいかどうか」の判断も必要になります。

具体的には以下の質問への答えが必要になります。

  • alicearticlewrite できますか?
  • bobarticlewrite できますか?

この質問をするときのInputはきっとこんなJSONになると思います。

{
  "user": "alice",
  "action": "write",
  "resource": "article"
}

そしてこの質問に対して、「Allow/Deny」の答えを出すためのRuleはRegoで以下のように表現することができます。

default allow = false
allow {
    permission[input.user][i].resources[_] == input.resource
    permission[input.user][i].actions[_] == input.action
}
  • permission["alice"] の中のデータを順番にチェック
  • i番目の情報の resourcesarticle が含まれるかチェック
  • i番目の情報の actionswrite が含まれるかチェック

結果として、 alice{ "resources": ["article"], "actions": ["read", "write"] } という permission を持っているので、すべて true となるので、結果も true です!

逆に bob の情報を下のように渡してみるとどうなるでしょう?

{
  "user": "bob",
  "action": "write",
  "resource": "article"
}

bob には { "resources": ["article"], "actions": ["read"]} という permission しか定義されていないので、 write できるかという質問に対しては false になります。

よって、このリクエストの結果は false になります。

まとめ

  • OPAは「Allow/Deny」以外にもオブジェクトをレスポンスとして返すことができる
  • 「誰」が「何」をできるか、を返すことでUIでその情報を使うことができる(ボタンの表示・非表示など)

『JSJ 358: Pickle.js, Tooling, and Developer Happiness with Anatoliy Zaslavskiy』を聴いて

僕のお気に入りのPodcastの一つにJavaScript Jabberというものがあります。

devchat.tv

JavaScript」とPodcastのタイトルには書いてありますが、ゴリッとJavaScriptのテクニカルな話をするわけではないです(昔はそうだったかも)。 どちらかと言うとJavaScript界隈に何かしら関わりのある人物をゲストに呼んで、その人と一つのテーマについて1時間ほどトークをするという流れです。 ホストは Charles Max Wood氏 です。Ruby Rogues, Adventures in Angularなど様々なPodcastを配信している方です。

なんとなーくジョギングなりしながら聴いているのですが、先日聴いたエピソードが結構面白かったので紹介したいと思います。英語ですが、トピックに興味がある方はぜひ聴いてください!

Pickle.js, Tooling, and Developer Happiness

今回のゲストはAnatoliy Zaslavskiy氏というHover Inc.所属のSenior JavaScript R&D Developerでした。

devchat.tv

当初のテーマはきっとAnatoliy氏が作ったPickle.jsと自動テストに関する話だったと思うのですが、途中からDeveloper Happinessに話が逸れ(?)ます。

このDeveloper Happinessに関する議論が特に興味深かったです。

目次

  • [00:00] イントロ(Pickle.jsの紹介)
  • [11:38] テスト文化にまつわるよくある問題
  • [17:30] 自動テストの意義
  • [28:24] Employee Retention(従業員をどう定着させるか)
  • [38:24] なぜSeniorよりJunior Developerを雇うほうがスケールするのか
  • [47:10] ツールやライブラリを作っていく上で注意すること
  • [54:15] Picks

時間は、Podcast内でトピックが話されているだいたいの時間を示してます。Picksとは、毎回Podcastの最後に参加者が全員何かしら記事だったり技術ネタだったり、視聴者にシェアしたい内容を紹介するコーナーです。

Pickle.js

ゲストのAnatoliy氏が作っているPickle.jsというのはe2eテストフレームワークです。

www.picklejs.com

僕もまだ触れていないので、このPodcastと公式サイトから得た情報をまとめると

  • Cucumber っぽく(Gherkin Syntaxで)ノンプログラマーでもテストを書ける
  • 既存のテストフレームワーク(執筆時点ではCypressだけ)を拡張して実装しているので、理論上はテストフレームワークを変えてもテストが動く
  • ページ内の要素を選択するためのセレクターは一箇所にKey Valueで定義し、そのKeyをテストの文章内で使用できる

ポイントは以下のスライドでも簡潔に紹介されています。

僕の中ではpython製の Robot Framework に似てるのかなという印象があります。

robotframework.org

自動テストがなぜ必要か?

なぜ自動テストが必要なのかというトピックについて、「自動テストの無い大企業でのプロジェクトの問題」が例に出されています。

  • プロジェクトに多数のエンジニア(数100)が関わっている
  • ある機能を開発者が実装する
  • QAがその機能をテストして、1週間後にバグなどフィードバックする
  • 開発者はバグを修正してQAに再び渡す
  • また1週間後に、今度はさらに発生したバグなどフィードバックする

ここでの大きな問題としては開発者が、自分の実装した範囲が他にどのような影響を及ぼすのかということを知る術が無い(コード全体を熟知しない限り)。

そして、何かを壊してしまった場合に即座にフィードバックを得ることができないという点です。

流れが悪いために時間はどんどん過ぎていき、エンジニアとしてはほとんどバグを直していることしかしていないという負のスパイラルに陥ります。

自動テストを導入することで、フィードバックのスピードが劇的に早くなるため、上の問題の改善に大きく貢献するというトークをしています。

自分が行った変更が 既存の機能を壊していない ということが 一定のレベル保証される ことで、開発者も変更を加えるときに心理的安全性を保つことができるようになります。

トーク内でも「Eliminate the fear of change(変更することへの恐怖を排除する)」することで「Innovative(革新的)」になれると言っています。

この意見には僕もとても賛同しているのですが、「一定のレベル保証される」というところが、「良いテスト」を書いていることが前提になっていることを忘れちゃいけないのかなとは思います。

「良いテスト」の定義がまた難しいのと、トーク内にも特に触れられていない部分なのですが、以下の書籍の内容が僕は好きです。

The Way of the Web Tester: A Beginner's Guide to Automating Tests

The Way of the Web Tester: A Beginner's Guide to Automating Tests

日本語版はこちら

  • 意味のあるテストになっているか
  • 壊れやすいテストを書いていないか
  • 本当に意図したテストを行っているか(テスト自体がバグってないか)

などいろいろな観点がありますが、「ただテストをたくさん書けばいい」というわけではないという点がポイントです。

Developer HappinessとEmployee Retention

後半はDeveloper HappinessとEmployee Retentionに関する話題になります。ここが結構ヒートアップして前半の内容が薄れちゃいます(笑)

なぜエンジニアは会社を辞めるのか?

エンジニアが会社を辞める理由としてCharles氏は2つの観点を述べています。

  • 人(People)
  • プロジェクトそのもの(Project)

自分と「合わない」人と毎日仕事を続けるのはしんどいですし、そもそもプロジェクトが解決しようとしている問題に興味が無ければモチベーションも上がりません。 これには僕も同意見です。これに加えて「給料」も結構大きな理由なのではないかと思います。

同じ仕事条件で、より給料の高いオファーがあったとしたら会社を変えるのは結構自然だと思います。

ただし、「仕事条件」は僕の中では「仕事場の環境(人)」も含まれていると思うので、 単純な比較にはならない とも思います。

Anatoliy氏は「辞める」のは「Unhappy」だからであり、「Unhappiness」は「Cognitive dissonance(認知的不協和)」から来ると述べています。

ja.wikipedia.org

  • 自分がやるべきこと
  • 自分が実際にやっていること

のギャップに苦しんでいるが、その「現状の状態」に慣れ過ぎちゃっているがために、どうしたら改善できるか 想像ができない状況に陥ってしまう と。

この状況に陥ったときにどうすべきかの意見がCharles氏とAnatoliy氏で異なった点が面白いです。

IT業界は今のところ人手不足なので、転職してしまうのが一番シンプルだとCharles氏は述べています。

それに対してAnatoliy氏は恋愛を例に出します。

「好きだと思った女性と付き合うが、付き合ってみたらなんか違ったので別れてまた違う女性と付き合う。」

ということを繰り返して良いのかどうかという点に注目します。

「問題は付き合っている女性側にあるのではなく、自分にあるのではないか。」

という視点の切り替えが必要なのではないかと問います。

この視点の切り替えとは「課題の分離」を行うということなのかなと僕は感じました。

  • 自分の課題
  • 他者の課題

を整理することで、自分の課題に気づいたり、他者の課題に踏み込んでしまっていることに気づいたりできると思います。

「課題の分離」について以下2つの書籍を最近読んで僕も「なるほどー」とうなづく点が多かったので合わせて載せておきます!

booth.pm

嫌われる勇気―――自己啓発の源流「アドラー」の教え

嫌われる勇気―――自己啓発の源流「アドラー」の教え

「課題の分離」を行うことで、「現状」を改善する道筋が見えてくるかもしれないというのは確かにその通りだなと感じました。

ただし、それでも尚道筋が見えない環境、抜け出した方が良い環境(Toxic Environment)もあるというのは双方で一致している意見でしたし、僕もそう思います。

補足:僕は付き合う相手を変えることについて否定的ではないです。自分に本当に合う人をそうやって見つけられるとも思います!

エンジニアのRetentionを上げる

エンジニアのRetentionを上げるポイントとして述べられているのは「エンジニアは多種多様であると理解すること」と言っています。

  • いろんな感情を持っている
  • 興味の対象は人それぞれ
  • ワークスタイルも人それぞれ

人それぞれで異なるものをうまく組み合わせて活用(utilize)できるようにする、と述べていますがこれはとても難しいと思います。

人・組織・リーダーシップに関わってくる話だと僕は捉えていますが、まだまだ僕はこの点について勉強中で、特に以下の書籍を読んで整理したいと思っています。

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー

ピープルウエア 第3版

ピープルウエア 第3版

また、 僕のブログメンターでもある カックさん の以下記事も参考になる情報満載なので要チェックです!

kakakakakku.hatenablog.com

まとめ

Developer Happinessの議論がとても勉強になりました。「これだ!」という単純な答えが無いのが難しいんですけど、様々な人のこう言った話を聴きながら、自分の生き方も改善していきたいと強く感じました。

後半のトークが濃すぎてPickle.jsの話がだいぶ薄れた印象があります(笑)Pickle.jsのコンセプトは面白いので試してみたいです。

参考

  • Testabilityという観点で画面(View)の状態をカタログのように可視化して管理できるStorybookが紹介されました

storybook.js.org

  • Picksで紹介されたDevOpsの本。物語になっていて読みやすくて面白い本です。

The DevOps 逆転だ!

The DevOps 逆転だ!

OPAでANDとORの条件を組み合わせる

OPAのSlackでやりとりされている内容とかが流れていってしまうのが勿体無いので残していこうと思います。(将来的に索引にできたら良いかなと)

f:id:kenev:20190331164752p:plain

上図のようなパターンを考えてみましょう。文で表現すると以下のとおりです。

p1, p2, p3, additional_pがすべてtrueの場合に許可する。additional_pはp9またはp10がtrueであれば良い。

これをRegoで書くと次のようになります。

package play

default allow = false

# this rule says "allow is true if p1 and p2 and p3 and additional_p"
allow {
    p1
    p2
    p3
    additional_p
}

p1 { input.x == 1 }
p2 { input.y == 2 }
p3 { input.z == 3 }

# additional_p is true if p9 or p10
additional_p {
    p9
}

additional_p {
    p10
}

p9 {
    input.a == "foo"
}

p10 {
    input.a == "bar"
}

ポイントは以下のとおりかと!

  • ルールから別のルールを参照できる
  • ルールの中身に書いた式は暗黙的にANDとして扱われる(allowの中のp1, p2, p3, additional_p)
  • 同名のルールは暗黙的にORとして扱われる(additional_p)

試してみましょう!

次のJSONをInputに入れてみます。

{
  "a": "bar",
  "x": 1,
  "y": 2,
  "z": 3
}

そうするとOutputは次のようになります。

{
  "result": {
    "additional_p": true,
    "allow": true,
    "p1": true,
    "p10": true,
    "p2": true,
    "p3": true
  }
}

true の結果が全部返ってくるのでちょっと見づらいですけど、 allowtrue なのがわかります。

Inputの "a": "foo" とした場合でも allowtrue です! なぜなら p9 OR p10 であれば( input.afoo または bar であれば ) additional_ptrue だからです。

Rego Playgroundは下になりますので実際にInputを変えてみてOutputを確認してみると動きの違いを実際にみることができます!

play.openpolicyagent.org

おわりに

  • PolicyのORやANDは暗黙的に行われる
  • ルールの中からルールを呼び出すことでルールを整理できる

参考

kenfdev.hateblo.jp

CircleCIで実行バイナリをDLしてCI内でキャッシュしながら使う

CI内でどこかしらから実行バイナリをダウンロードして、それを使うことがあると思います。 最近では僕はOPAのテストをCircleCIで実行したかったので、OPAのバイナリをダウンロードしてテストを実行しました。

kenfdev.hateblo.jp

毎回バイナリをダウンロードしてCircleCIを回すのもコストが高いので、CircleCIのキャッシュを使う方法について共有します!

実行バイナリをDockerイメージに入れてそれをCIで使う方法もありますが、今回は実行バイナリをダウンロードして使う方法でやります!

キャッシュせずにやった場合

まずはキャッシュのことを考えずにCIしてみると、以下のような流れになります。(OPAの例です)

version: 2
jobs:
  build:
    docker:
      - image: circleci/buildpack-deps:jessie

    steps:
      - checkout
      - run:
          name: Download OPA
          command: |
            mkdir .bin
            wget -O .bin/opa https://github.com/open-policy-agent/opa/releases/download/v0.10.6/opa_linux_amd64
            sudo chmod +x .bin/opa
      - run:
          name: Test Policies
          command: .bin/opa test .
  • チェックアウト
  • OPAのバイナリをGitHubからダウンロードして実行権限付与
  • OPAのテスト実行

という感じです。特につまるところは無いと思います。

ただしこれにはパフォーマンスの問題があって、CIの度にOPAのバイナリをGitHubからダウンロードしてくるのが無駄です。 このバイナリもそんなにしょっちゅう変わるものでも無いので、ダウンロードが一度で済ませられたら良いですよね。

そこで使えるのがCircleCIのキャッシュです!

キャッシュして効率化

CircleCIには save_cacherestore_cache という便利な機能があります。

circleci.com

キーを基にCircleCI側にファイルやディレクトリなどをキャッシュしておくことができます。 よく見る場面としては、依存パッケージなどをキャッシュしておくときです。( node_modulesvendors ディレクトリなど)

ポイントとなるのがキャッシュの「キーの決め方」です。

まずはあまり工夫をせずにキャッシュの手順を加えて見ます。

version: 2
jobs:
  build:
    docker:
      - image: circleci/buildpack-deps:jessie

    steps:
      - checkout
      - restore_cache:
          key: opa-cache-0.10.6
      - run:
          name: Download OPA
          command: |
            if [ ! -f .bin/opa ]; then
              mkdir .bin
              wget -O .bin/opa https://github.com/open-policy-agent/opa/releases/download/v0.10.6/opa_linux_amd64
              sudo chmod +x .bin/opa
            fi
      - run:
          name: Test Policies
          command: .bin/opa test .
      - save_cache:
          key: opa-cache-0.10.6
          paths:
            - .bin
  • チェックアウト
  • キャッシュがあれば復元
  • OPAのバイナリが 無ければ GitHubからダウンロードして実行権限付与
  • OPAのテスト実行
  • OPAのバイナリをキャッシュしておく

restore_cachesave_cache のキーには opa-cache-0.10.6 を使っています。

これは、OPAのバイナリのバージョンが変わったらキャッシュもちゃんと変わるようにするためです。 ただし、これってバージョンが変わるたびに少なくとも3箇所( 0.10.6 となってる部分)は変えないといけないので微妙ですよね。

ということでどうにか1箇所に集約できないかと考えてしまいます。

ちょっとトリッキーなのが、環境変数restore_cachesave_cachekey に使えない点です(少なくとも僕の2019/04/19時点での認識では)。

      - restore_cache:
          key: opa-cache-${OPA_VERSION}

上記のように書けるとすっきりしそうなんですけど、これができません。ではどうするかというと、以下のフォーラムでやり方を見つけることができました。

discuss.circleci.com

次のように書き換えることができます。

      - run:
          name: Setup Environment Variables and Version file
          command: |
            echo 'export OPA_VERSION="0.10.6"' >> $BASH_ENV
            echo "${OPA_VERSION}" > _opa_version_
      - restore_cache:
          key: opa-cache-{{ checksum "_opa_version_" }}
  • 環境変数OPA_VERSIONにバージョン番号を入れて
  • バージョン番号を _opa_version_ というファイルにリダイレクト
  • _opa_version_checksum をキャッシュのキーとして使う

言われてみれば「あ、その手があったか!」ってなります。

ということでこの方法で config.yml を書き換えると下のようになります。

version: 2
jobs:
  build:
    docker:
      - image: circleci/buildpack-deps:jessie

    steps:
      - checkout
      - run:
          name: Setup Environment Variables and Version file
          command: |
            echo 'export OPA_VERSION="0.10.6"' >> $BASH_ENV
            echo "${OPA_VERSION}" > _opa_version_
      - restore_cache:
          keys:
            - opa-cache-{{ checksum "_opa_version_" }}
      - run:
          name: Download OPA
          command: |
            if [ ! -f .bin/opa ]; then
              mkdir .bin
              wget -O .bin/opa https://github.com/open-policy-agent/opa/releases/download/v${OPA_VERSION}/opa_linux_amd64
              sudo chmod +x .bin/opa
            fi
      - run:
          name: Test Policies
          command: .bin/opa test .
      - save_cache:
          key: opa-cache-{{ checksum "_opa_version_" }}
          paths:
            - .bin

こうすることで下の一行を変えるだけで、OPAの実行バイナリのバージョンを切り替えることができます!

echo 'export OPA_VERSION="0.10.6"' >> $BASH_ENV

今の所の僕の最適解はこのやり方になるのですが、他にも良い方法があればぜひとも知りたいところです!

おわりに

  • 依存ライブラリ以外にもCircleCIの save_cacheresotre_cache は使える
  • 一工夫すればキャッシュのキーに環境変数で設定したバージョン番号を指定できる

参考

ちょうど「CircleCI 福岡ミートアップ」が開催されて、その中でもキャッシュについて触れている発表があったようです!

OPAのテストをCircleCIに乗せる

OPAのPolicyをテストする方法について前回は紹介しました!

kenfdev.hateblo.jp

OPAのバイナリさえあれば opa test コマンドで簡単にテストが実行できます。

ということでOPAのPolicyをCIに乗せて継続的にPolicyのテストができるようにしてみます。

どんなCIでもできますが、今回はCircleCIで試してみたのでその方法を共有します。

リポジトリの準備

Policyを書いたRegoファイルは 前回 のものをそのまま使います。

ファイルの構成は以下のとおり。これがGitHubリポジトリに置いてあることを前提にします。

.
├── iam.rego
└── iam_test.rego

ここに .circleci/config.yml を作ります。

mkdir .circleci

# エディタで編集
vim .circleci/config.yml

YAMLの中身は↓

version: 2
jobs:
  build:
    docker:
      - image: circleci/buildpack-deps:jessie

    steps:
      - checkout
      - run:
          name: Setup Environment Variables and Version file
          command: |
            echo 'export OPA_VERSION="0.10.6"' >> $BASH_ENV
            echo "${OPA_VERSION}" > _opa_version_
      - restore_cache:
          keys:
            - opa-cache-{{ checksum "_opa_version_" }}
      - run:
          name: Download OPA
          command: |
            if [ ! -f .bin/opa ]; then
              mkdir .bin
              wget -O .bin/opa https://github.com/open-policy-agent/opa/releases/download/v${OPA_VERSION}/opa_linux_amd64
              sudo chmod +x .bin/opa
            fi
      - run:
          name: Test Policies
          command: .bin/opa test .
      - save_cache:
          key: opa-cache-{{ checksum "_opa_version_" }}
          paths:
            - .bin

これで概ね準備完了です!

書いてる内容はちょっと多いのですがやってることは下の通り。

  • リポジトリのチェックアウト
  • ダウンロードするOPAのバージョンを環境変数に設定
  • OPAバイナリのキャッシュがあれば復元する
  • キャッシュが無ければダウンロードして実行権限与える
  • Policyを opa test でテストする
  • 次から再利用できるようにOPAバイナリをキャッシュしておく

このYAMLリポジトリにPushします。

CircleCIを設定

以下の公式ドキュメントにもありますが、CircleCIに対象となるリポジトリを追加します。

circleci.com

下の画面に表示されている「Start building」をクリックすることでCIが走ります!

f:id:kenev:20190409220122p:plain

正常にCIが走ればテストも通るはずなので、下のように成功画面になります。

f:id:kenev:20190412225659p:plain

では、わざとテストが失敗するように下のように iam_test.rego を編集しましょう!

f:id:kenev:20190409220846p:plain

新しいbranchで変更し、pushしてからPRを作ってみます。

pushした時点でCIが走るのでPRをGitHub上で作るころには失敗して、下のような画面になっているはずです!

f:id:kenev:20190409221622p:plain

このように、CIに乗せて継続的にPolicyのテストも実行していくことができます。

テスト好きにはたまらないですね!僕はテスト大好きなのでワクワクしてしまいます。

今回のコードは以下リポジトリに置いてますので、参考になればと思います!

github.com

おまけ

バッジもREADMEに載せてちょっと今風にしてみました!

CircleCIでプロジェクトの Settings に行って、Status Badgesに移動します。

すると、README.mdとかに貼り付けられるCircleCIのステータスバッジが下図のように記載されています。

f:id:kenev:20190412201757p:plain

これを貼り付ければ、下のようにCIの状況が表示されるバッジを載せることができます!

f:id:kenev:20190412202440p:plain

こういう取り組みも地味にモチベーションに繋がったりするので大事にしたいです。