ウチのチームでKPTが根付いた話
本日はあまりにもネタがないため、今所属しているチームでKPTが根付いた話をしたいと思います。
気づいたら1年くらい続いておりすっかりチームの文化になりました(これは本当に素晴らしいことだなと思ってます🌞)
KPTとは何か?
振り返りのフレームワークのことですが、詳しくはググッてくださいw
いろんな企業での事例もあるし、本もいくつか出ていますね。
ソニックガーデンの↓の記事や
クックパッドの↓の記事
なんかは素晴らしいですね!
KPT導入が成功したポイント
(ウチのチームで)導入成功の要因だと思われるモノをいくつかご紹介したいと思います。
KPTの本を買って、みんなで読んだ
チームに入った人には↓の本を読むようにしてもらっています。
わかりやすく、内容もコンパクトなのでオススメです。
毎週決まった日時に繰り返し開催
毎週火曜日、決まった時間に開催してます。
繰り返し決まった時間に行うと習慣化しやすいです。
ちなみに、月曜日は祝日でよく潰れてリズムが崩れるのでオススメしませんw
アナログにやる
当初、デジタルでやっていたのですが、上手くいかず、ホワイトボード+付箋+サインペンのアナログ運用に切り替えてから上手く回り始めた気がします。
司会はみんなで持ち回り
社内Wikiに進行手順をドキュメント化して、誰でも司会役ができるようにしました。
KPTの理解が深まる、KPTのミーティングの時間を自分事として見れるようになるという点で、上手く機能している気がします。
KPTの進行手順自体をKPTで改良
ちなみにKPTの進行手順は「これだけ!KPT」の本に書かれている内容をベースとして、KPTを繰り返す中でチームに馴染むように改良していきました。
だいぶ安定はしてますが、今でもたまに手順を変更することもあります。
たとえば、当初はスタンダードなKEEP,PROBLEM, TRYだけで進行していましたが、途中でTODOという項目を追加したりしています(TRYからやることを選択して、この項目に移動させる。「これだけ!KPT」によれば、KPT2というやり方だそう)
KPTを導入してどんなメリットがあった・・・?
感覚的にはかなりプラスになっていると思います。
- チームで仕事を進めている感が出た
- 非効率・無駄な仕事を見直すいい機会
- チームの問題を指摘して正したりできることで精神的な支えになる(イライラしない)
というあたり。
最後に
KPTオススメです。
興味はあるけど、いまいち導入に踏み切れない人はぜひ↓の本を読んでみてくださいw
オライリー本を全冊購入するといくらなのか?(ワンライナーバージョン)
コチラを見て、頭の体操程度で。
こんなコマンドで
curl -s https://www.oreilly.co.jp/catalog/ | perl -lnE 's/.+"price">([\d,]+).+/$1/ && (tr/,//d, $c++, $s+=$_); END{ say "合計 $c冊 $s円"}'
結果
合計 445冊 1533060円
結構増えてますね。
Reflect.applyとFunction.prototype.applyの速度を計測してみた
ESLintのprefer-reflect
というルールをONにした
最近、Node.js v6が出たのでバージョンアップがてら、ESLintのprefer-reflect
というルールをONにしました。
そして、既存のソースに早速ESLintをかけたところ・・・
警告ががが
既存のソースに早速ESLintをかけたところ func.call(obj, a)
みたいに書いている箇所で警告を受けました。
http://eslint.org/docs/rules/prefer-reflectによれば、下記の古いメソッドはReflect.xxxに置き換えられると。
Reflect.apply effectively deprecates Function.prototype.apply and Function.prototype.call
Reflect.deleteProperty effectively deprecates the delete keyword
Reflect.getOwnPropertyDescriptor effectively deprecates Object.getOwnPropertyDescriptor
Reflect.getPrototypeOf effectively deprecates Object.getPrototypeOf
Reflect.setPrototypeOf effectively deprecates Object.setPrototypeOf
Reflect.preventExtensions effectively deprecates Object.preventExtensions
Functionのcall
やapply
はReflect.apply
に書き換えなさいとのこと。
ESLintのルールに従い、素直に書き換えよう!とは思ったのですが、速度が激遅にならないかが気になりました。
そこで超ざっくり計測
console.time
にてざっくりと。
'use strict'; function log(i) { return String(i); } for (let n = 1; n <= 10; n++) { console.log(`------------${n}回目-----------`); console.time('Function.apply'); for (let i = 0; i < 100000; i++) { log.apply(log, [i]); } console.timeEnd('Function.apply'); console.time('Reflect.apply'); for (let i = 0; i < 100000; i++) { Reflect.apply(log, undefined, [i]); } console.timeEnd('Reflect.apply'); }
結果。
------------1回目----------- Function.apply: 13.736ms Reflect.apply: 11.770ms ------------2回目----------- Function.apply: 13.979ms Reflect.apply: 8.198ms ------------3回目----------- Function.apply: 10.134ms Reflect.apply: 9.899ms ------------4回目----------- Function.apply: 9.800ms Reflect.apply: 11.548ms ------------5回目----------- Function.apply: 11.939ms Reflect.apply: 7.979ms ------------6回目----------- Function.apply: 8.048ms Reflect.apply: 8.330ms ------------7回目----------- Function.apply: 11.209ms Reflect.apply: 12.215ms ------------8回目----------- Function.apply: 11.397ms Reflect.apply: 8.974ms ------------9回目----------- Function.apply: 9.948ms Reflect.apply: 10.000ms ------------10回目----------- Function.apply: 8.923ms Reflect.apply: 11.215ms
結論
遅いということはなさそうなので、安心して使えそう。
Invokeを少し触ってみた
Invokeとは?
Python製のタスクランナーだそう。make, rake, gulpみたいな。
↓みたいにタスクを書いて、invoke clean build
みたいに実行できると。
from invoke import run, task @task def clean(docs=False, bytecode=False, extra=''): patterns = ['build'] if docs: patterns.append('docs/_build') if bytecode: patterns.append('**/*.pyc') if extra: patterns.append(extra) for pattern in patterns: run("rm -rf %s" % pattern) @task def build(docs=False): run("python setup.py build") if docs: run("sphinx-build docs docs/_build")
どこで使われている?
Fabric(https://github.com/fabric/fabric/)で。
http://www.pyinvoke.org/faq.html#why-was-invoke-split-off-from-the-fabric-project
↑を読むと、Fabricが仕事し過ぎなため、ライブラリを分割した模様。
サンプルは?
非常にシンプルで直感的に使えるのですが、事例が少ない。。
日本語ではこちらのサイトくらい www.hexacosa.net
一番いいのはFabricの事例と、作者のタスク集みたいなのを見ること。
実戦で使ってみる?
ちょっと悩む。
makeとかrakeで何とかならんこともないし。
While fully usable, Invoke is still pre-1.0 software and has no backwards compatibility
なので、API変更もあり得るし。
どうしてもPythonで全部統一したい人は使ってみたらよいのではないでしょうか・・・
Google Cloud DNSで設定ファイルをimport/exportする
Cloud Deployment Manager にはGoogle Cloud DNSを設定する機能がないっぽいですが、代わりにgcloud dns
コマンドが使えそうです。
コマンド例
エクスポート
↓のコマンドを打つと
gcloud dns record-sets export -z example-com-zone example-com-zone.yml
↓のようなYAML形式で出力されます。
--- kind: dns#resourceRecordSet name: example.com. rrdatas: - ns-cloud-c1.googledomains.com. - ns-cloud-c2.googledomains.com. - ns-cloud-c3.googledomains.com. - ns-cloud-c4.googledomains.com. ttl: 21600 type: NS --- kind: dns#resourceRecordSet name: example.com. rrdatas: - ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 3 21600 3600 1209600 300 ttl: 21600 type: SOA
インポート
↓のコマンドでYAML形式のファイルをインポートできます。
gcloud dns record-sets import --delete-all-existing -z example-com-zone example-com-zone.yml
ポイント
- インポート時には
--delete-all-existing
を指定しないとダメなよう - 書式にエラーがある場合は更新されないので、中途半端な状態にならないかは気にしなくて大丈夫なよう
Slackで絵文字をskin-toneを変えた絵文字全てをクリップボードにコピー
ESLintで拡張子をみてテキストをゴニョゴニョできる話
久しぶりにESLintの話題を。
公式ドキュメントに書いてあるのですが、ESLintプラグインでは拡張子毎にprocessorを設定できるそう。
http://eslint.org/docs/developer-guide/working-with-plugins#processors-in-plugins
processor is 何?
このeslint-plugin-markdownがわかりやすいかもしれません。
markdownからJavaScriptのコード部分だけを抜き出し、lintできるというプラグインです。
↓のpreprocess
という関数の部分を見ればわかりますが、markdownのテキストからJavaScriptのコード部分だけを抜き出すということをやっています。
https://github.com/eslint/eslint-plugin-markdown/blob/f97e0c01beb7cc6dad21d828ea80e4fbe55317af/lib/processor.js#L43
抜き出したコード部分を配列で返せば、ESLint本体側でそれらをlintしてくれる挙動になっています。
※ちなみにmarkdownをパースする箇所では、昨日の記事で書いたプレゼンテーションツールのremarkが使われていましたw
どんな場合に使えるか?
ぱっとプラグインが見つからなかったですが、HTMLファイルの
<script>〜</script>
の中身のチェックにも使えそう
→ ありました eslint-plugin-html - npm (mysticateaさん、ありがとうございます)テキストの中身をみて、pluginをOFFにするとか (eslint-plugin-disable がまさにそれ)
/* eslint no-var: 0 */
みたいなコメントを一行目に強引につけて、ファイルの中身に応じて、動的にルールをON/OFFする(ES2015とES5が混じっている環境で使いたい)
など。
まとめ
使いたい(使うかも)