認定スクラムマスター(LSM)になりました

LSMを取得しました

先日、Scrum.inc https://scrum.esm.co.jp/ 認定資格セミナーを受講し、 無事に認定スクラムマスター(LSM)となりました。

f:id:mad-berry:20181206095704p:plain

学ぶきっかけ

スクラムチームでの開発やスクラム導入をフリーランス・正社員時代から6年程経験がありました。 スクラムマスターの役割を時折してきましたが、 今年度からは明確な役割としてスクラムマスターとしてチームをファシリテートしてきました。

プロジェクトに入ると、スクラムを導入する事が多くなっているのですが、スクラムチームメンバーでスクラム経験者が少なく、私の経験的プロセスでコーチするにも自分の中で曖昧な部分が多かった為、 長期休暇の取得とセミナーの開催日が重なった事を機会に、受講を決めました。

主に学べたこと

学べて良かったこと

基本的に全て良いインプットが出来ましたが、個人的にとても理解が進んだ部分です。

  • リリースプランニング。仕様が曖昧な大きなユーザーストーリーをプランニングし、プロダクトオーナーやステークホルダーと共にリリースプランを作り上げる方法
  • リリースプランニングからスプリントプランニングまでの間に行うイベント、プロダクトバックログリファインメントやストーリーマッピングの方法

詳細にはセミナーの内容になってしまうので書けませんが、大きな学びでした。

振り返り

2日間の受講でしたが、LSMを取得するまでの振り返りを書きたいと思います。

Keep

  • スクラムでは実現しにくいと思っていたリリースプランや、ウォーターフォールの一部を残しつつ手探りに導入していた部分がこのセミナーを受けて鮮明になり、導入支援に自信がついた。
  • バッファの設け方を知った
  • プロダクトオーナー・スクラムマスター・チームのロールが明確になった
  • ベロシティを上げていくプランの中に、アジャイルマインドがベースになっており、コードのリファクタ・品質向上も含まれており、ずっと意識してきた事が間違っていないと確信できた。
  • マイクロマネジメントに対する対処を学べた。
  • システム開発の業界ではスクラム導入が多くないことを学べた

Problem

  • 講中の翻訳機が片耳だったので聞き取りにくかった
  • 2日間という短い受講時間の中で概念・実践を全て盛り込まれていた為、進みが早く感じる部分もあった
  • セミナー受講者の中でスクラム経験が一番長かった。半分以上がスクラム未経験者の方で、質問を受けることもあり、もっと早く受講するべきであった
  • 実際の試験まで数日空いたので、そわそわした
  • 受講者に配布された資料がモノクロだった為、見づらい。
  • フリーランスの為、受講費用が全額自腹だ。

Try

  • T字型人材になれるよう努力する
  • 今まで以上にチームをファシリテートできるよう努力する

感想

  • スクラム導入については各社さまざまで、かんばんだけ取り入れたり、デイリースクラムはするけど振り返りはしなかったり、 また、各社が公開しているツールでスクラムを体現していると思いますが、中にはスプリントという概念がなかったり、ウォーターフォールと混在したツールを提供していることも多く、ベロシティの計測が出来ない場合もあります。こういったことがスクラムについての曖昧さをもたらせてしまっていると感じました。 今まで「スクラムを導入しているよ!」と自信を持って手を挙げて来た人達もこのセミナーで、なんちゃってスクラムをしてきた事が浮き彫りになったのではないかと思います。 私は主にJIRAをベースにスクラムをしてきたので混乱する部分が少なかったですが、ツールに惑わされて混乱してしまう人も発生しいるように感じました。
  • とても有意義な受講となりました。スクラムをかじっている人にはとてもお薦めです。

DecoratorパターンとActiveModel::Callback

フリーランス@amyroi です。 スカウトメールで、2月の記事を「古い記事」と言われたので、最近の資料を上げておきます w

外部用というより、参加プロジェクトのサーバーサイドエンジニア向けに発表した資料です。 その為、プロジェクト特有の仕様を考慮したオブジェクト思考の構成にしています。

主に以下についての話です。

  • オブジェクト思考の基本的思考
  • concern
  • DecoratorパターンとActiveModel::Callback

speakerdeck.com

RubyRailsの開発を初めたけど、オブジェクト指向についてはまだあまり取り入れていない。 なんてチーム向けにこういったオブジェクト指向の考え方を伝えて指導したりレビューしたりする事が多いです。

enum-i18nの話し

この記事はみんなのウェディング Advent Calendar 2017 - Qiita 22日目の記事です。

dotenv+itamae環境をconfig+yaml_vaultに移行した話 - amyroi's logの記事に引き続き@amyroiが担当します。

enum-i18n

Rails4のEnumI18nに対応するイケているgemがなかったので 簡単に作ったものを後日gemにしました。 こちらについて書いていこうと思います。

https://rubygems.org/gems/enum-i18n

以前HatenaBlogの記事で簡単な紹介をしました。 amyroi.hateblo.jp

みんなのウェディングではこのgemを使っていません!

  • 社内ではモンキーパッチとしてリポジトリ内に配置しています。

作った背景

  • プロジェクト内のI18nの構成を綺麗にした。
  • models, viewsで綺麗な構成になったけどenumカラムに対応させてない。
  • enumerizeみたいにRailsEnumも対応させたい! https://github.com/brainspec/enumerize
  • Rails本体にはいつから対応するのかな。まだされない。。

なぜ社内で使えないのか

https://github.com/amyroi/enum-i18n/blob/master/lib/enum-i18n.rb#L10

ライブラリ内部でActiveModel::Name#model_nameメソッドを呼んでいます。

name = model_name.try(:i18n_key).to_s

しかし弊社ではmodel_nameというカラムがschemaに存在します。 そのため、特定のテーブルに対するロジックを書く必要があり、 モンキーパッチとして置くことになりました。

name = (self.class == ::User) ? 'user' : model_name.try(:i18n_key).to_s

残念!

gemにした理由

とても個人的な理由で作りました。

  1. 2017年の抱負を決めずに過ごしてきたので年内に何か残したかったから。
  2. gitのsubmoduleでライブラリを作った記憶はあるけどOSS化はしていなかった。
  3. フリーランスで活動する上でOSS活動について聞かれる事が増えてきたから。

増やしたいメソッド

  • enumカラムの翻訳対応された一覧を取得できるoptionsを追加していきたい。

Contributing

PR送ってくれたら喜びます。

明日のAdvent Calendarは?

みんなのウェディング Advent Calendar 2017 23日目は@matsuhisa_h さんの記事です。

dotenv+itamae環境をconfig+yaml_vaultに移行した話

この記事はみんなのウェディング Advent Calendar 2017 - Qiita 19日目の記事です。
現在業務委託エンジニアとして開発基盤まわりのお手伝いをしている@amyroiです。
12月は各社のAdvent Calendarが盛り上がっていますね。

環境変数管理をdotenvからconfigへのスムーズな移行手順

弊社ではプロジェクトの環境変数管理をDotenv+itamaeで管理していましたが、
Dotenvの廃止をフリーランスでジョインした会社で2回(2社)経験するという珍しい体験をしたので、 今回はその手順、ノウハウを書いていこうと思います。

どうして廃止するの

  • プロジェクトのリポジトリに公開したくない秘密情報をdotenvで管理してhost毎に管理する為によく使われるdotenvですが、host側の管理となると会社の規模によってはインフラ担当者に依頼が発生し、いちエンジニアが管理できない。
  • dotenvファイルを暗号化する機構を別で持つ事もあり、一つの環境変数を変更するのにインフラから作業が切り離せない。
  • host毎の環境変数管理を管理する便利なgemがちゃんとあるのでconfigに変更しようよ。

実現できた事

  • 環境変数をconfigに変更しいちエンジニア側で管理を完結できるようになった。
  • itamaeなどの構成管理が不要になる。
  • 暗号化復号化の機構もリポジトリ内で完結
  • 暗号化用のkeyをAWSのKMSを使い、エンジニア毎・ホスト毎のkeyを一度作るだけでOK。
  • 暗号化復号化処理を自動化させることによりプロジェクトに参加したばかりのエンジニアでも意識する必要がない。

いいことづくめですね

何を使うの?

実際に対応したRails,Rubyのバージョンと実現するために使ったgemを紹介します。 新たに追加したのはconfig, yaml_vault, AWS KMSです。

始める前に

  • 事前調査と設計をしてから手をつけるのが得策です。
  • 事前準備(調査)編と導入編に分けました。
  • 2回目となるconfigへの移行作業の規模が大きく、なかなか大掛かりとなりました。調査と設計をしっかりしていくのがポイントとなります。

事前準備(調査)編

dotenvで管理している機構を確認する

まずはdotenvがリリース環境で展開されどのような構成で動作しているのかを確認します。

  1. dotenvの各enviromentsでの管理の仕方を確認
  2. インフラ側の管理の仕組みを確認
  3. 暗号化の仕組みを確認
  4. 各enviroment環境で復号化される機構の確認
  5. dotenvで管理している環境変数の種類の確認

実例
dotenvの各ホストへの配布にitamae,暗号化にyaml_vaultを利用していました。こちらは全てインフラ側で行われていました。 またdotenvとは別に独自環境変数のclass定義がありました。

enviromentsの目的を明確にする。

プロジェクトで使われているproduction, staging, development, testのenviromentsの意味を明確にします。

実例 developmentとlocal環境、ローカルでのtestとcircle ciでのテストで使っている環境変数に相違がある場合がありました。 みなさんはそんな事しないと思いますが何があるか分かりませんね。ここは前もって整理しておきましょう。

使っている環境変数を確認

  1. 各enviromentsで使われいてる環境変数を復号化して一覧にします。
  2. dotenv以外の独自環境変数classがないかチェックし移行対象にします。
  3. 必要のない環境変数の洗い出しをします。

実例 dotenv以外に独自にclassからYAML.loadさせてアプリ固有の環境変数を作っていました。 そして一部の変数はdotenvから呼び出すというスパゲッティ。

既に使われていない環境変数が残っている事、独自定義の環境変数もどきと重複のチェックも行います。

環境変数の呼び出し元の種類を確認

呼び出し元が統一されていたら楽ですが、そうもいきません。

  • シンゴルクオーテーションとダブルコーテーションの違い
  • exists?を使っているところ
# 3種類ありました。
ENV['GOOGLE_CLIENT_ID']
ENV["GOOGLE_CLIENT_ID"]
ENV.exists?('GOOGLE_CLIENT_ID')

プロジェクト内でRails.env.{enviroment}?で制御している箇所を洗い出す

環境変数をつかっているのにRails.env.{enviroment}?でif分制御している箇所があったりします。 これは [enviromentsの目的を明確にする]でローカルとdevelopmentで違う値を使いたいときなどにハードコーディングしている場合がありますのでリファクタしていくことにしましょう。

導入(設計)編

まだ実装しません。暗号化の仕組みを選定し、設計をしていきます。

暗号化の仕組みを選定する

候補

sekrets(https://github.com/ahoward/sekrets)

Rails5.1から導入される秘密情報の暗号化の参考にされているsekretsが有力候補でしたが、ファイル事暗号化してしまう為、環境変数名がリポジトリ上で確認できません。

yaml_vault(https://github.com/joker1007/yaml_vault)

jokerさんのyaml_vault、vaultキー配下のkeyのvalueだけ暗号化してくれます。 key管理にKMSが使える。

決定

本来ならsekretsにするところですが、key名までも暗号化されてしまうと変数名すらわからない状態になってしまう為、yaml_vaultを採用しました。より運用しやすくするためにrakeタスクを作成することにしました。

暗号化・復号化の仕組みを考える

  • リポジトリには暗号化されたファイルをcommit
  • 復号化されたファイルは.gitignore対象にしコミットしない
  • 復号化のキーはAWS KMSで管理

復号化するタイミングを決める

環境構築時

bin/setup 内で復号化

capistranoデプロイ時

deployコマンドに仕込みます。

code deploy デプロイ時

deployタスクに仕込みます。

導入(実装)編

やっと実装していきます。

config導入

構成

暗号化対象と対象外のファイル、配置構成を下記としました。

config/secret.yml # cookie,sessionkey等。暗号化対象外
config/settings.yml #  enviroments共通の設定ファイル。暗号化対象外
config/settings/ # 復号化されたenviroment毎の設定ファイル(gitignore対象)
|
| - development.yml
| - staging.yml
| - test.yml
| - production.yml
|
config/encrypted/ # 暗号化されたenviroment毎の設定ファイル
|
| - development.yml
| - stging.yml
| - test.yml
| - production.yml

configファイルに環境変数を移動する。

整理した環境変数をconfigファイルに移動していきます。 命名規則も綺麗にしていきましょう。

  • サンプル
ENV['GOOGLE_CLIENT_ID']

=>

Settings.google.client_id

dotenvとconfigの変数の対応表を作ります。

主にRspecでの単体テスト用に作っていきます。 懐かしいjpmobileの絵文字のconversion_tableを思い出して作りました。

このconversion_tableがあれば動作テストを減らすこともできますし、もし移行によるバグが発生しても変更された変数名が他のエンジニアでも容易にチェックできます。

SETTINGS_TABLE_FOR_ENV =
{ 
  GOOGLE_CLIENT_ID: 'google.client_id'
}

削除対象の環境変数は対応表にはいれません。 その代わりSpecに検証対象外のkeyとして残しておきます。

yaml_vaultのrakeタスクを作成する。

さてここでyaml_vaultのrakeタスクを作ります。

理由

  • yaml_vaultのISSUEにも上がっていますが、現時点(2017/08/04)でyaml_vaultは暗号化対象yamlのvaultキー配下をデフォルトで暗号化します。
  • configファイルにvaultキーを作るとSettings.vault.google.client_id となりかっこ悪い
  • オプションで暗号化対象のkeyを渡すとvaultキー以外でも暗号化してくれますが、全て指定しないと他が暗号化されないまま出力されてしまう。
  • エンジニアの日々の運用をしやすいようにSettingsファイル配下のkey一覧を取得して、keyを指定せずに暗号化復号化できるようにrakeタスクを作りました。

実例をお見せしたいですが、ここは公開していないコードになる為割愛します。

実行タスクは下記のようにしました。

暗号化

  • config/encrypted/{enviroment}.ymlからconfig/settings/{enviroment}.ymlを作成
  • config/settings/{enviroment}.ymlが存在する状態で実行
# 全enviromentsを暗号化
$ bundle exec rake yaml_vault:encrypt
# enviroment指定
$ bundle exec rake yaml_vault:encrypt['development']

復号化

  • config/encrypted/{enviroment}.ymlから config/settings/{enviroment}.ymlを作成
# 全enviromentsを復号化
$ bundle exec rake yaml_vault:decrypt

# enviroment指定
$ bundle exec rake yaml_vault:decrypt['development']

暗号化復号化をbin/setup, デプロイタスクに組み込む

環境開発時、検証環境・本番サーバーへのデプロイ時のタスクにそれぞれ上記で作ったrakeタスクを組み込んでいきます。

namespace :config do
  task :decrypted do
    on roles(:app) do
      execute :rake, 'yaml_vault:decrypt["staging"]'
    end
  end
end

after 'deploy:updated', 'config:decrypted'

dotenvからconfig移行のテストを書く

これが一番大事ですね。 rakeタスクのspecはもちろんですが、dotenvとconfigの変数の対応表を使い、specを作っていきます。

  • 各enviroments毎にループさせ、Dotenv.loadをした値と、復号化したconfigファイルの値が一致しているのかのテストを書いていきます。

ここで値チェックは終わりです。あと少し!

dotenvの呼び出し元をconfigの変数名に置換

環境変数の削除の準備ができましたのでconfigの変数名に置換していきます。 ここは対応表を使って置換していくのがいいでしょう。

コードのリファクタ

  • 独自環境変数用のクラス、if分制御している箇所をリファクタしていきます。

動作テスト

  • 各enviroments用のテスト環境を作り、動作テストを行います。

dotenv削除

  1. gem dotenv削除
  2. itamae側のdotenv配置ロジックを削除
  3. リポジトリ内にサンプルのdotenv等があればそちらも削除

リリース!

  • 移行作業を行います。
  • 変更点が多いので監視をしましょう。

後処理

  • 動作テストしてリリースしたら後処理を行います。
  • リリース後ホスト内にあるdotenvファイル群を削除していきます。

移行完了

お疲れ様でした!

最後に(感想など)

  • KMSの設定やテスト環境の構築などは省略しました。
  • dotenvをリリース環境で使っているプロジェクトもまだまだあるんだなというのが正直な感想。
  • 元々インフラチームが管理していた構成は移行作業にもインフラとの密な連携が必要となるのでやるなら早めにした方がよいよ。
  • 調査・設計・実装・テスト・デプロイも全て担当したのでやった感あり。
  • これから移行して行こうと思っている方々の参考になるかな。
  • 最後まで読んでいただきありがとうございます

明日のAdvent Calendarは?

みんなのウェディング Advent Calendar 2017 - Qiita 20日目は@yasukexxx さんの記事です。

RailsのEnumのi18n対応gemを作成しました

RailsEnumi18n対応gemを作成しました

Rails4.1に入ったEnumですがRails5.1になってもi18nに対応していなかったので gemのEnumelizeを使うこともあったと思いますが、 できればRails標準のEnumを使いたかったので、gemを作りました。

enum-i18n | RubyGems.org | your community gem host

f:id:mad-berry:20171008180612p:plain

動くサンプルもこちらに作っています。

github.com

特徴

  • ApplicationRecordにincludeする事により、enum設定してあるカラム全てに自動でi18nの翻訳を対応できるようにしています。
  • i18nのスコープが独自の階層で定義していてもscopを引数に渡すことで既存のi18n定義も呼び出せるようにしています。

その他

Contributingも募集していますのでお気軽にどうぞ