2018年振り返り

2017年の振り返りに引き続き2018年の振り返りです。 仕事でもプライベートでも求められた役割を受け入れて過ごした1年でした。

お仕事

2018年一年はフリーランスで二社の会社とお仕事をさせていただきました。 同時稼働もしていた時期があり、プライベートも忙しすぎたので、頑張りすぎた感がありました。

仕事内容

プロダクト

  • 口コミサイト
  • AIエージェントサービスの作成ツール

業務内容

  • プロジェクトチームメンバーのマネジメント(PM)
  • スクラムマスター
  • スクラム導入
  • 開発基盤整備
  • CI/CD 整備
  • バックエンドエンジニア
  • コードレビュー

詳細

年始は2017年からジョインした会社に引き続き継続で ありがたい事に常駐から一部リモートを許可していただいて開発基盤とコードレビュー中心の仕事をしていました。 ただ、リモート許可をいただいていた業務委託メンバーは私一人で優遇していただいており、介護生活になる事も申告していたので 申し訳ない気持ちも高まり、フルリモートが可能な会社を探すことになりました。

2017年末に付き合いのあったエージェント経由で大手通信会社のプロジェクトからのオファーをいただき、 数ヶ月お待ちいただいたりもしましたが、リモートベースチームのマネジメントと開発整備、新規プロジェクト開発のお仕事をさせていただきました。

AIエージェントサービスという最新の分野のお仕事に携わることが出来、未知の部分が多いなりに勉強しつつお仕事させていただきました。

感想

マネジメントの仕事は介護をする傍らできるとは思えずこの時も断っていましたが、ジョインすると結局逃れることはできず、またこの頃になるとスクラムの導入は勝手に身体が動く状態になっていました。 結果PM兼スクラムマスターといった事をさせていただき、機能開発やレビューも行い、パツパツになりました。

マネジメントの仕事は増えてきましたが、技術者としての苦手分野はまだまだ解消できず、得意な方に投げてしまうのは今年も変わらずで成長しきれていない部分があります。

インプット

スクラムの経験年数が長くなり、改めて今年認定スクラムマスターを取得しました。

amyroi.hateblo.jp

プライベート

介護

仕事との関わり

2017年末から始まった介護生活により3時間以上の外出は難しくなり、半日以上の外出になる週1の打ち合わせは看護師派遣を依頼し来てもらうことにしました。 それ以外の外出時も看護師を依頼するので、長時間の勉強会・飲み会も看護師に来てもらっていました。

必然的に引きこもりになるわけですが、週1~週2で通院生活をしていて動き回っていたのと、リモート環境は整っていたので、仕事と介護だけに集中していました。

夏前にはこの生活がすでに限界に来ていましたが、8ヶ月間の介護生活が終わった後もプロジェクトの区切りである秋が来るのを待っていました。 そしてまたありがたいことに、12月から長期休暇をいただきました。

終わりが見えない介護で、手術費、入院費、外注費を考え仕事を続けることを選択しましたが、1年休業の選択もあったなと今は思っています。

業務委託にも関わらず、両社共理解をしていただいて、お仕事をさせてもらった事にはとても感謝です。 少しだけ休んで来年に同じ職場に復帰予定です。

インプット

医師、看護師のレクチャーの元、レンタルした医療機器を使えるようになったり、一人で点滴ができるようになりました。(医師の許可あり)

ツール

介護に使えたツール

Amazon echo スマートスピーカーは仕事でも使うので購入。 スマートホーム化と定形アクション、リマインダーをフル活用しました。 後半はリマインダーを2時間起きにアレクサが教えてくれたのでタスク管理にも役立ちました。

www.amazon.co.jp

alfred.camera 専用のカメラを購入する事なくスマホ2台で監視カメラを導入できます。 声かけもできるのと、動画の保存もでき、PCでも閲覧ができとても便利でした。

alfred.camera

twitter 介護用のアカウントを開設したら、暖かく迎えてくれる方がとても多く情報交換も積極的で、助けてくれました。

twitter.com

これ以外にも便利ツールがたくさんありましたが、ガジェット系は以上です。

まとめ

2017年までには無かったインプットが2018年の忙しい日々の中、仕事・プライベート共に出来た事は2019年の励みになりそうです。

2017年振り返り

2017年振り返り

2018年ではなく2017年の振り返りです。 猛烈に忙しかったため下書きのままでいましたが、読み返すと自分なりの事はやれたなと思ったのでOPENにする事にしました。 毎年旧正月にあたる2月が節目になる事が多く、2017年の1年と1ヶ月の振り返りをしたいと思います

お仕事

wondershake

Locari の開発基盤と新規サービスのリリースから始まりました。 正社員で関わりました。 locari.jp milcoco https://milcoco.jp/milcoco.jp

PM、スクラムマスター

新規事業で開発未経験のメンバーしかいなかった為、新規プロジェクトの一からの立ち上げに携わりました。 βリリースに向けてのプロジェクト管理、仕様決定、採用、デザイン、ロゴ決め、外注管理、倉庫連携。 事業のメンバーも若く、プロジェクト遂行経験のないメンバーしかいないチームで全て一から教えこむのは骨が折れました。

また同時並行でのRailsプロジェクトのPM、スクラムマスターに携わり、無事リリース。 こちらは最近までRailsプロジェクトで動いていましたが先日Closeしたようです。

フリーランス業務

5月より某社でのRailsプロジェクト開発基盤チームで開発基盤を担当しました。 また、完全リモートでEC関連でRails+Anguler.jsのお仕事も携わりました。

開発基盤チームでやった事

各社の基盤チームでやった事

  • 各種API連携バージョンアップ対応
  • RubyRails update
  • 各種gemのバージョンアップ対応
  • 各暗号化処理の整備
  • TDD環境再整備
  • コード品質管理再整備
  • Rubocop、Reek、Lint系整備
  • コードレビュー
  • スクラム導入
  • データベース暗号化仕様変更の大規模データ移行
  • その他大規模リファクタ

感想

2017年は開発基盤でのお仕事ができて、実装を久しぶりにできて嬉しかったです。 またRailsを導入しても改善が必要なプロジェクトが多い事に気付かされました。

管理業務について

  • システム側の管理についてはそれほどやることが変わった事はありませんでしたが、若いメンバーと働くことが多かったにも関わらず、分からない事を分からない、スケジュールの遅延の共有をなかなかしてくれずとても困った年でした。
  • 世の中シニアエンジニアの扱いに困るという風潮もありますが、若手メンバーの扱いにくさを肌で感じました。
  • よくある話で管理をすると実装ができなくなりgithubに草が生えなくなると技術に触れられていない自分に対する一重に不安が押し寄せてくる。

フリーランス業務

  • Railsエンジニアとしてジョインすることがほとんどですが、Railsエンジニアの採用問題は未だに根深い事を実感。
  • 会社によってエンジニアのスキルの差はとても大きい。
  • ここ数年フリーランスでジョインする場合、開発基盤チームでやった事で書いた事 + 時々マネジメントを同じように求められている。
  • 開発基盤チームでやった事をやって欲しいから呼ばれているという事をより強く認識するようになった。
  • フリーランス協会に加入した

勉強会

  • しばらくお休みしていた勉強会参加も復活し、インプットを増やせた。
  • いくつかアウトプット出来た

実現した事

2016年に引き続き、若いメンバーからの刺激を多く受けた年でした。 しばらくお休みしていた勉強会参加も復活し、インプットを増やせた。

出来なかった事

正社員でジョインしていた会社では基盤開発より新規プロジェクトの管理がメインとなってしまい、基盤開発はおろか実装も出来ず不安な日々と溢れかえるタスクに消耗した。

プライベート

猫娘が20歳になり年の瀬に計画的手術の予定が、急性腎不全を発症し入院。 入院が長引き、病院近くに寝泊まり、退院後も自宅治療が必須となり、ついに自宅治療生活。 介護や自宅治療にについて勉強する日々。 ペットシッターや看護師派遣などに依頼しながら通勤する日々となりました。

認定スクラムマスター(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 さんの記事です。