Masteries

技術的なことや仕事に関することを書いていきます.

「アジャイルレトロスペクティブズ」読んだ

年末年始に読んでいました. 「アジャイルサムライ」, 「カイゼン・ジャーニー」, 「アジャイルな見積もりと計画づくり」をお手本にして, チームにアジャイルのエッセンスを取り入れている中で, 「振り返り」をもっと良くしたいという気持ちになっていて, そのためのinputとして年末年始でガッと読みました.

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルのうち, 「振り返り」の部分に特化した本なので, ページ数も思ったより少なくサクッと読めたので良かったです. また, 振り返りをするときに使えるアクティビティがたくさん紹介されており, 付録として, 「どのフェイズでどのアクティビティを使うと良いか」のクイックリファレンスが載っているのも良かったです. 日々のイテレーションで使えるアクティビティ, 複数回のイテレーションを過ごした後に使えるアクティビティ, そしてプロジェクトが終了したり, 一段落したときに使えるアクティビティ... で分類されていて, 「振り返り」の場所(?)を設計するとき, 或いは改善していく時に非常に役立ちそうと思います.

「振り返り」, やはりチームにとって重要で, 例えば今のチームであれば物理カンバンを導入したり, ユーザーストーリーから作っていくフローを整えたり, いろいろ試みていて, 一定の成果は出ていると思っています. 一方でそこで満足してしまったら停滞してしまう... という危機感もあって, そうならないために(チームが常に前に進み続けるために)振り返りが重要, と思っています. 一定期間の自分たちを振り返って, 課題を見つけて, その対策を立てて, しっかり取り組む... その繰り返しが, 改善に繋がって, チームを前に進めてくれる... と信じています.

今回, 「アジャイルレトロスペクティブズ」を読んでみて, チームに活かせそう, と思った部分は結構ありました. ただ, 「これは合わないかも?」という部分や, 咀嚼不足で「どう活かせるかな...?」と思い悩んだ部分も多々ありました. 活かせる部分はすぐにでも取り入れて活かしつつ, 定期的に読み返して, 新たに得た知見を本で得た知見と結びつけたりとか, そういった形でこれからのチームに活かしていきたいですね.

2018年の振り返り

あけましておめでとうございます, 2019年もよろしくお願いいたします. というわけで2018年が終わったので振り返りをします. 今年もKPTでやっていきましょう.

過去の振り返り達

papix.hatenablog.com

papix.hatenablog.com

papix.hatenablog.com

papix.hatenablog.com

K

「2018年にやってみてよかったこと, 2018年も継続して取り組みたいこと」

いろいろと良い結果を残せた

入社して2年目, 徐々に慣れてきたこともあってか, 去年は業務においてそこそこの規模の成果を幾つか出せました. 一番印象的なものは, 2017年からほぼ1年にわたって取り組んでいた「はてなブログのHTTPS化」が無事完遂したことでした.

papix.hatenablog.com

リリースにあたって大きな問題なく出せたのが何より良かったですし, そこで得た知見や気付きなどを, エンジニアセミナーや「Rejectcon 2018」で発表したり, GeekOutでインタビューして頂いたりすることができて, 外に向けて発信出来たのも良かったです. また, 詳しくは後述しますが, Go言語習得の取っ掛かりになったのもHTTPS化の作業がきっかけでした.

もう1つ, 「はてなブログのHTTPS化」より規模は小さいですが, 「はてなブログのPerl 5.28.1化」も思い出深い成果です.

developer.hatenastaff.com

日々の業務の合間にコツコツと5.28化の作業を進めて, 適宜リリースすることで「小さな成功体験」をコンスタントに得ていく進め方をしましたが, 今回はそれが「チームメイトをうまく巻き込む」動きに繋がって, チームメンバーの手厚いサポートの甲斐もあって, 最終的にはこちらもまた特段大きな問題なくリリースまでこぎつけました.

そのための手順書を作る中で意識したこと, 気づいた事をまとめてアドベントカレンダーに書いたところ, なんと人生初(多分)の700ブクマオーバーを達成しました!

papix.hatenablog.com

予想以上の反響があって驚いていましたが, 「気づいた事を, 正直に」書いた結果のが良かったのかも? と思っています. そこを参考にしたり, 他山の石にしてもらって, そのリアクションが700ブクマオーバーに繋がったのかなーと思っています.

「気づいた事を, 正直に」と言えば, 2018年はKichijoji.pmで2回, スクラムについての話をしました(詳しくは後述します). これもまた, チームで感じていた課題やそれに対して打った手, そしてそれが半年後にどうなったか... といった部分まで発表した結果, 懇親会でいろいろな方と議論したり, 意見をもらったりして, 非常に学びが多かったです. 今年の「YAPC::Tokyo 2019」では, その総集編的な発表をする予定ですので是非聞きに来てください(宣伝).

papix.hatenablog.com

...そういえば「YAPC::Okinawa」も2018年でしたね. 「Webサービスを監視するときに僕達が考えたこと」という発表をしましたが, ベストトーク賞の2位を頂けたのでした.

これもまた自分にとっては快挙と言える出来事で, 資料を作っている中で(会社のチーフエンジニア陣にレビューしてもらったりして)自分自身学びがあったし, それをしっかりと伝えることが出来た結果なのかなーと思っています. 嬉しかったですし自信が持てましたね.

こうやって振り返ってみると, 結構いろいろな領域で(?)コンスタントに成果を残せた1年だったなあ, と思いますね. 2019年も落ち着いて, コンスタントに成果出していきたいですね.

技術の幅を広げることができた

2017年は「手持ちの道具で戦いすぎた」というProblemを挙げていました. 一方で, 2018年は「道具を増やす」という観点で, 進歩のあった1年だと思います.

まずは前述の「はてなブログのHTTPS化」を通して, Go言語の理解はかなり深まりました. id:aereal さんが書かれた最高のお手本コードがあったというのも大きいですが, やっぱり業務を通して技術を習得するのが自分にとってはスピーディー出来るのかも, と改めて気づけた気がします. その時に学んだ事を活かして, Go言語でMackerelのプラグインを書いたり, サンプルコードをGoで書いたり, 継続してGo言語でコードを書く活動が出来ています.

papix.hatenablog.com

papix.hatenablog.com

papix.hatenablog.com

一番得意なPerlほど素早く/ミスなく書けるレベルには至っていませんが, 若干試行錯誤しつつも微速前進なスピードで, Go言語でモノが作れるようになってきました.

また, 業務の中でReact/ReduxやTypeScriptの理解もだいぶ深まってきました. こちらは id:masawada さんにペアプロしてもらって, はてなブログにおけるReact/ReduxやTypeScriptのお作法(?)を伝授してもらって, 若干の四苦八苦はしつつ機能の追加や改修が出来るようになってきました.

年末年始はChrome拡張を書いたりして, ReactやTypeScript, そしてJavaScriptの開発環境周り(npmやGulpなど...)をキャッチアップしようと試みています.

papix.hatenablog.com

また, スクラムマスターに挑戦したのも良い取り組みでしたし, スクラムの導入を通して, チームをうまく回して前進させるという"技術"を少しずつ得ていくことが出来ました. チームで感じていた課題感を打破するべく挑戦したスクラムマスターでしたが, 正直に言うとちゃんとした(?)教育を受けた経験はなくて, 前職でアジャイルマスターの下でアジャイルをやった経験と, 「アジャイルサムライ」, 「カイゼン・ジャーニー」, 「アジャイルな見積もりと計画づくり」辺りを読み込んだ知識, そして id:daiksy さんのアドバイスを頼りに試行錯誤しながらやっていきました.

軌道修正も多々ありましたが, とはいえタスクの可視化やフローの整備なども含めて, 少しずつですが課題に感じていた部分が解決され, チームとしてまとまって, 前に進めてきた実感があります. とはいえ, チームでの「振り返り」をうまく活かす部分など, まだまだ課題は尽きないので, 引き続き情報や知見のインプットをしつつ, 2019年も試行錯誤を続けていきたいと思っています.

...こうやって振り返ってみると, 2018年は「業務を通して技術の習得に挑戦する」機会がたくさんあって, それが自分にとっては適切だったのか, 割と高速に試行錯誤が出来て, 結果として知見が溜まって技術の幅を広げることが出来た(?)気がします. なので, 2019年もそういうチャンスがあれば積極的に取り組んでいきたいですね. とはいえ, そういう幸運な機会は度々ないと思うので, 業務外でもうまくキャッチアップする仕組みは考えていく必要がありますね...

P

「2018年で良くなかったところ, 2019年に改善していきたいところ」

去年の振り返りを活かせなかった

今回2018年の振り返りを書くにあたって, 2018年の冒頭に書いた2017年の振り返りを改めて読んでみたのですが... 「あ, あの時はこんなことを思ってたんだ...」というのが正直な感想で, それは要するに2017年の振り返りをうまく2018年に活かせていなかった... という事に他ならないなーと痛感しました.

今半期から, 期末の振り返りに向けて, 1〜1.5ヶ月に1回のペースで定期的な振り返りをするようになったので, 2019年はその中で「2018年の振り返り(= これ)」も見返すようにして, 初志を思い出したり, 軌道修正したりしていきたいですね.

秋〜冬にかけての体調が最悪だった

2017年の振り返りでも体調をProblemに挙げていたのですが, 2018年も秋から冬にかけて体調を崩してしまっていました. 特に10月末〜11月辺りは非常に厳しい時期が続いていて, 通院したり, 体調芳しくなく朝起きれなかったりで, 勤怠の状況も極めて厳しい状況に陥っていました. 12月になって若干持ち直してきましたが, とはいえまだまだ油断のならない状況と思っています.

2019年はいよいよ30歳になるので, 体調管理にはこれまで以上に気をつけたい所です...

あまりにも危機感を感じなくなった

2017年に引き続き, 2018年も体調は芳しくなかったものの精神衛生状態は1年通して平穏な状態が続きました. とはいえこれは裏を返せば, 精神衛生に影響が出るほど危機感を感じることがなくなった, と言えます. 個人的には, 程よい「危機感」は爆発的な成長の糧になると思っていて, そういう意味では2018年はいろいろと得るもの, 成長したことはあったけれど, とはいえ勢いはなかったと感じています.

とはいえ, これまで危機感を感じていた時は, 主に「自分と他人を比べる」時の, 劣等感とか不甲斐なさとかを噛みしめる中で感じる事が多くて, 結構これはコントロールが難しいし, そもそも最近は他人に対して感じた劣等感や不甲斐なさから自分を追い込むことがなくなってきたので, 2019年は他の, なるべくコントロール可能なやり方で, 程よく自分を追い込んで, 危機感を煽ってみたい(?)と思っています.

...その辺り踏まえて, 2019年のTryとして, 「もっとチャレンジする」を掲げようと思っています.

T

「2018年, 改めてチャレンジしていきたいところ」

もっとチャレンジする

前述した通り, 今年でいよいよ30歳になります. 前職時代に中途採用に関わる機会があって, その時に思ったのは「20代のうちはある程度ポテンシャルを見込んで評価してくれるが, 30代は実力でしか評価されない」というのが大なり小なりあると思っていて, それを踏まえて今の自分を見つめると, まだまだ実力不足でしかないですね. なので, 2019年はもっとたくさん経験を積んで, 実力の糧にしていかないといけないと思っています.

そのために, チャレンジして自分を追い込むのも必要だと思っていて, 30歳になるといういい節目もあるので, 例えば「ロールを変える」という挑戦をしてみるのもアリかも, と考えたりしています. 例えばエンジニア兼任ディレクターのようなポジションをやってみたり, 或いはSREとしてインフラ周りの仕組みを再整備したり... 引き続き「教育」的な部分にも関心があるので, そういった挑戦もしてみたいという気持ちもあります. とはいえアレもやりたい, コレもやりたい! だと大抵中途半端な結果に終わるので, しっかり上長やメンター, 関係する人たちと相談して, いい感じの(負担になりすぎない)チャレンジをしていきたいです.

海外に行く

去年も書いていたのだけれど, 去年は結局海外のカンファレンスに行く機会がなかったですね. 2019年は, ひとまずThe Perl Conference in Riga(TPCiR)に行くぞ! という気持ちを高めています. はてなブログの開発の様子を通じて, 日本におけるPerlを使ったWeb開発事情の現状をお話する, みたいなトークをしたいと思っています. これもまたチャレンジの一環ですね.

そうなると, 引き続き壊滅的な英語についても何とかしないといけない気がしますが, とはいえ体調管理のことなどを考えると, 英語しっかり勉強するぞ! と心に決めても途中で挫折するのは容易に想像が出来るので, まずはヒアリングを突破口にするのはどうか? とか考えたりしています. 英語で会話していて困るのが「何を言っているかわからない...」というところで, そこが改善できれば聞き取れた単語から会話の内容を想像したり... 出来るのではないか...?

後はライブの日程とTPCiRの日程が重ならないことを祈るのみですね. 重なったら... いろいろ検討します...

まとめ

こうやって振り返ってみると, 2018年は割といろいろ成果残しつつ学びも多い, よい1年でした. これも日々お世話になった皆様のお陰だと思っています. 本当にありがとうございました.

一方で, 引き続き体調面など不安はたくさんで, 2019年はその改善をしながら, いろいろなチャレンジを通して経験を積んで, 実力というか, エンジニアとしての戦闘力を高めていける1年にしたいと思っています. 至らぬ点もまだまだ多いですが, 2019年も引き続き, ご指導ご鞭撻の程よろしくお願いいたします!

今開いているタブのURLをクリップボードにコピー出来る「chrome-copy-url」を書いた

年末年始, ちょっとはJavaScriptを書いて慣れを深めよう, という気持ちの元, 簡単なChrome拡張を書いてみることにしました.

github.com

出来ることは, このエントリのタイトルに書いた通り, 「Chromeで今開いているタブのURLをクリップボードにコピー出来る」, のみです. この拡張を導入すると, 次の画像のようにcみたいなボタンが出てくるので(多少はかっこよくしたい...), それを押すとクリップボードへのコピーが実行されます.

f:id:papix:20181230034447p:plain

調べていないけれど, 多分同じような事が出来るChrome拡張はたくさんありそうで, そういう意味ではJavaScript練習のための車輪の再発明をしている, という感じですね.

今後の展望

クリップボードに格納する前にフィルターをかける機能を実装してみようと思っています. 例えば...

  • URLエンコードされたURLをコピーしたら文字列を復元されてクリップボードにコピーされる
  • 予め指定した, 不必要なクエリパラメータを削除出来る機能

...とかあったら便利かも? と思ったので, そういった機能を実装しつつ, JavaScriptの練習をしていこうと思っています.

雑なチェックプラグインを書いた話

こんにちは, id:papix です. この記事は, 「Mackerel Advent Calendar 2018」の16日目の記事です.

qiita.com

昨日は, id:albacore さんの「学生サークルでMackerelを運用してみた話」でした. 闇に飲まれよ! (お疲れ様です!)

albacore.hateblo.jp

雑なチェックプラグインを書いた話

さて, 担当の日が来たにも関わらず, 良いネタがなかったので, 最近書いた雑なチェックプラグインの話をします.

自分は自宅にEdgeRouter Xを置いていて, 更に契約した回線がグローバルIP付きだったので, EdgeRouter XでVPNを使えるようにしたり, いろいろ遊んでいました. その時に書いた記事がこの辺りの記事です:

papix.hatenablog.com

先日, 外出中に自宅にあるEdgeRouter XへVPN接続をしようとしたところ, どうも繋がりませんでした. 「アレ?」と思って, VPN接続のために設定していたIPと, Mackerelに登録されているEdgeRouter XのグローバルIPを確認すると... なんと違うIPアドレスになっていました.

...ハイ, 要するに「グローバルIPは割り当てるが, それは固定ではない」というオチでした. 確かに契約している回線の公式サイトとかを見に行くとそのように書いてあって, 要するに自宅にある通信会社から貸与された機器(終端装置みたいなもの?)の電源が落ちたり, メンテナンスがある度に, 使えるグローバルIPが割り当てられる... という仕組みになっているようです.

check-gip

せめて, グローバルIPが変わった時に気づけるようになりたい. ...ということでMackerelで使えるチェックプラグインを作ってみました. 2時間くらいで雑に作ったので, 名前も「check-gip」という, なんかよくわからん感じの名前になっています.

github.com

これまで何度か, Mackerelのプラグインを作ったことはありましたが, 多分チェックプラグインを作るのは初めてです. とはいえ, Mackerelの場合は公式で提供しているチェックプラグイン集があり, それをお手本として作れば, そこまで苦労することはありませんでした.

github.com

使い方

今の自宅では, 通信会社から貸与された機器からLANケーブルがEdge Router Xのeth0に繋がっていて, ここにグローバルIPが割り当てられています. なので, グローバルIPを適当なドメインと紐づけて, その名前解決の結果と, Edge Router Xのeth0に割り当てられたグローバルIPアドレスを比較するプラグインを作ることにしました.

名前解決はnet.LookupHostで, インターフェイスからIPアドレスを取得する部分はGoのnetパッケージを使って強引に実装しました. 例えば, myhome.example.comにグローバルIPが設定されていて, それとチェックプラグインが動いてるサーバのeth0に割り当てられたIPアドレスをチェックするなら, このように設定します:

[plugin.checks.check_gip]
command = "check-gip --host myhome.example.com -i eth0"

これで, 例えばeth0に割り当てられたIPアドレスが変わってしまったりしたら, Mackerel上でアラートが出るようになります.

さいごに

最近書いた雑なプラグインの話をしました. ...ここまで書いていて, これよりも, 「指定したインターフェイスに割り当てられたIPアドレスと, 引数で渡したIPアドレスをチェックする」みたいな実装にして, check-interface-addressみたいな感じで提供した方が汎用性ありそう, と思いました. そういう感じで書き換えることも検討したいです.

...言いたかった事としては, Mackerelはチェックプラグインも割と簡単に作れるので, このような「俺得チェックプラグイン」をサクッと作って(今回はGoで書きましたが, 別にPerlでもRubyでもシェルスクリプトでも何でも作れます!)使えると便利! っていう感じです. 皆さんも是非俺得チェックプラグインを作ってみましょう!!!

明日は...

明日の担当は miwarin さんです. お楽しみに!

「手順書」のススメ

こんにちは, id:papix です. この記事は, 「はてなエンジニア Advent Calendar 2018」の9日目の記事です.

qiita.com

昨日は id:wtatsuru さんによる, 「基盤開発観点からみたはてなのAWS活用のこれまでとこれから」でした.

wtatsuru.hatenadiary.com

「手順書」のススメ

さて, 早速本題に入っていきましょう. 皆さんは「手順書」を書いていますか? 自分はと言うと, 最近そこそこの規模のオペレーションが必要なタスクを担当する機会が多く, その度に手順書を書いて, レビューしてもらってからオペレーションをするようにしています. 例えば, 今年実施した「はてなが提供するドメインを利用したブログのHTTPS化対応」のリリースの時は, このような手順書を書いていました:

この時は, GitHubのIssueに手順書を用意していました. GitHubの場合, IssueやPull Requestに,

- [ ] ほげほげ...

といったフォーマットで手順書を書いておくと, [ ]の部分が自動的にチェックボックスになるので, 非常に便利です. ちなみにチェックを入れると[ ][x]に変わります.

「手順書」の利点

手順書を用意する際の問題点は, やはり「用意に時間がかかる」という点でしょう. オペレーションを実施するにあたって, 役立つ手順書を作り込むには, レビューの時間を含めてそこそこに時間がかかります. とはいえ, 手順書を用意すると, そのコストを上回る利点があると思っています. 具体的には...

  • オペレーションの際, 考えることが減る
    • 予め, 必要な作業やそれを実現するためのコマンドを網羅しておくことで, オペレーション中に「どうすればいいんだっけ?」と悩む機会が減ります
      • オペレーション中に悩み始めると, 特に時間がかかればかかるほど, 焦りに繋がります. 焦りはオペレーションミスの原因になりがちなので, それを防ぐのは非常に重要です
    • また, オペレーションの中止基準についても事前に手順書で定めておくと, 実際にトラブルが起きた時悩まずに判断出来ます
      • 例えば, 「○○の作業後, エラーレートがXX%を越えたらオペレーションを中止して切り戻す」とか...
      • これもまた, 事前に手順書で定めておかないと都度考慮する必要があり, 焦りに繋がります
  • 事前にオペレーションの内容を共有できる/レビュー出来る
    • 個人的には, これが一番大きなメリットだと思います
    • 実施する作業を一度手順書という形で文章に落とし込むことで, チームメイトからレビューしてもらうことができます
      • レビューすることで, より良い作業手順を練り上げることができます
    • 知識の共有という点でも有用です
      • 新しく入ったメンバーは, 手順書を読むことで, 「○○を実施するためには, ✕✕をすればよい」といった勘所を掴むことができます
      • また, レビューの中で, 「実はこのオペレーションは不要」だとか, 「こうやった方が楽」といった知見の共有も出来ます
  • 時と場合によっては再利用が出来る
    • 例えばミドルウェアのバージョンアップの手順書を一度用意しておけば, 将来更に次のバージョンへアップグレードをする際, 概ね再利用できるはずです

自分自身, 最近ちょっとしたバージョンアップを実施するための手順書を書く機会があったのですが, その中でこれまでうろ覚えだったインフラ周りのオペレーション方法について整理することが出来て, 非常に有用でした. チーム異動や転職などで新しい環境に至った時, 「手順書を書いてみる」というのは, そのチームに慣れる良い方法の1つかも...? と思います(すでにチームで手順書が用意されているなら, 少し冗長に(丁寧に)したものを作ってみる, というのも有用でしょう).

「手順書」を書く時に気をつけていること

  • 必要な連絡/周知なども網羅する
    • 「手順書」と言うと, 実際にコマンドを入力したりして作業する部分に注目しがちですが, 実際に業務の中でオペレーションをする際は, それ以外の手順も必要になりがちです
    • 例えば, リリース前に然るべきメンバーに周知したり, 関係部署に共有したりするのも, 立派な手順の1つです
      • そういった作業を忘れないように, 手順書に織り込んでおきましょう
  • 実際に入力するコマンドまで丁寧に書く
    • 「○○する」だけでなく, 「○○するために, サーバ上でxxxxxxというコマンドを入力する」まで書いておく... というイメージです
    • 特に, コマンドのオプションが多い/長い時は, 予め手順書にコマンドとオプションを書いておいて, 実行するときはそれをコピペする... くらいにしておいた方がミスを防げます
      • 実際に作業を始めた時, コマンドやオプションを間違えて覚えてしまっていると非常に焦ります... なので, 手順書に書いておいて, 事前にレビューしてもらうのが大事です
  • 中止基準や切り戻し方法も定めておく
    • 中止基準を定めておくと, 問題が発生した時に, 進むか中止するかの判断を悩まずに済む... というのは, 利点でも述べました
    • そういった事態はなるべく防ぎたいですが, とはいえそうなってしまった時のために, 作業を中止し, 作業開始前の状態に戻す方法についても, 手順書に書いておくのが大事です
      • 特に複雑なオペレーションをする場合, 作業を中止する, と決めたはいいものの, そこから原状復帰する方法がまとまっていないと, 非常に焦ります
        • 得てしてこういう時にミスが起きて, 二次災害が起きたりします...
      • そうならないように, 原状復帰の方法についても手順書に盛り込み, またレビューしてもらいましょう

実際に手順書を書いている中で自分自身で気づいたり, 或いはレビューの中で指摘してもらったりして, 上記のようなポイントを意識しながら手順書を書くようにしています. これらを意識しながら手順書を用意すると, そこそこ時間はかかる(オペレーションの規模にもよりますが, それなりの規模の作業をするのであれば, 準備とレビューで3日くらいは普通に準備期間として必要になると思って良いと思います)とは思いますが, 先に述べたようにそれを上回るメリットがあると思っています.

...まあ, ここまで書いておいて, 「割とエンジニアって日常的に手順書を書くのでは...?」と思ったりしたのですが, もし, 「手順書, 書いたことないな...」とか, 「既に用意してある/用意してもらった手順書を, 作業するだけだったな...」という方が, もしもいらっしゃったら, 自分自身の手で手順書を書いてみると, いろいろ気づきや学びがあると思うので, 是非やってみて頂きたいと思います.

明日は...

明日の「はてなエンジニア Advent Calendar 2018」は, id:masawada さんが担当です. 果たしてどのような後頭部が見れるのか, 楽しみですね.