Android Architecture Components の ViewModel, LiveData の登場により、長年仕事で携わっているプロダクトでも MVP アーキテクチャを卒業して MVVM にするか〜となった。

MVVM にするにあたり、いくつかのルールを制定したのだが、都度これに即したクラス群 (ViewModel. ViewModelTest など…) を作るのが面倒だったので、Android Studio による template のグループ機能を利用して自動生成するようにした。デフォルトでも Activity や Fragmemt をはじめとする様々なテンプレートが用意されている。

テンプレートから作成する様子は、ぽちぽちでやるとこんな感じ。

リリース前に動作確認したいのでアプリを配布したい、という場合に DeployGate をずっと用いていたが、Firebase が提供している Firebase App Distribution もさわり心地特に問題なかったので、どうアップロードを自動化できるかというのを調べた。

CI で Workflow 組もうと思ったら 2020/07 時点では権限周りが少しめんどかったのでメモ。

CI サービスで動かそうとしているので、属人化を防ぐためにサービスアカウントに権限付与し、そのアカウントで認証して Firebase CLI を使うのが良い。Fastlane に乗る。

サービスアカウントの作成

該当の Firebase project 配下にサービスアカウントを作成し、秘密鍵 (JSON) をダウンロードしてどこかに配置して …

2020 年はコードをばしばし書きつつも、エンジニアリングマネジメントについて考え始めた年と言える。その中でどうマネジメントやっていくかということを意識的に考えていく作業は結構負荷があった。合わせて上半期のタスク管理としてそんなに余裕がなかったこともあり、押し寄せるストレスを体感した。

基本的にストレスは自分が考える理想とのギャップから生まれるものと自覚しており、他人から受けるストレスはそうない。マネジメント上という意味ではないことを前提にして書くと、他人に興味がないからだと思われる。

そんな中で、なんかストレスでもやもやしてきたなと感じたら、以下の流れを踏んでいた。

1. 「キレそう」とどこでもいいので書く
2. キレそうと思っている自分を認識し、客観的思考を持ってできるだけ他人にする
3. 抽象化された事象を具体化していくように、なぜキレそうなのかその人に聞いていく形で、キレそうの下に生やすように書き出していく (キレそうツリーと呼んでいる)
4. どうすればよいか見えてくるので冷める

大体、並行して複数の物事を考えているときに起きがちなので、脳内でこれらをやろうとするとぐちゃぐちゃになってしまうこともあり、どこかに書き出してもやもやのまとまりを見つけ出していた。軽めのやつは 1 から 4 に飛んだりする。

オフィスにいたときはあーとかうぉーといった、ひとりごとを言ってた気がする。良い意味で僕よりひどい人がちらほらいたので言うのに抵抗がなく自然と出ていたなあと思い出したけど、 家だとひとりごとが出ないということに気付いた。まあでも言わない形で運用できているので良い。

軽いやつは大体 Twitter に書き出すことが多いので、こんな感じで下書き状態として残ってしまい笑ってしまうのが欠点か。

親知らずに続いて、へこみ具合の大きい体調不良が来た。割と病院にお世話になることもなく健康だったので、頻度高くこういうのが来ると精神的にくるものがある。今年は色々身の回りが変わったせいもあるのかなあ。

世間の様子に影響を受けすぎているせいで、これがアラサーか…という感情を覚えた。しかしこの世に普通の人間などいないと思っているので、普通のアラサーってなんや…と思うくらいには回復してきたので明日から頑張ろう。

最近会社ではリモートワーク体制になったことで、プッシュ通知設定の確認やアプリ内バナー表示といった、非モバイルアプリ開発者によるちょっとした動作確認に属人化が生まれたので、AWS Device Farm でなんとかした。

がっつり開発用途で使うとなれば、物理端末を購入するほうがコスト面において良い。しかし今回は毎日必要でないのと、1 日多くて 10 分程度のちょっとした確認であった。端末の購入コスト及び管理コストを踏まえると、AWS Device Farm のようなツールが良いと判断している。

導入

AWS 自体は省略。以下の流れで行った。

1. 使用感を確かめつつコスト試算してマネージャーと話しつけておく

2. 対象のチームに試してもらい、使用感問題なさそうか聞く

3. 困った時に参照するドキュメントを整備

4. 必要であれば運用しやすくする仕組みを作成

書いてみるとまあそうだよねみたいな気持ちになった。

ドキュメントにはAWS Device Farm の使い方や、困ったときにはここへメンションしてといったような、運用する上で必要な事項を聞いた上で文書化している。文字だけ書かれても理解しづらいと思われるので、画像 (動く様子は GIF) をのせることで理解しやすいようにした。

AWS Device Farm プロジェクトの制限

AWS Device Farm ではプロジェクト単位でファイルをアップロードし管理することができる。

Android apk もアップロードすることができ、そのインストールをマウスぽちぽちでできるため、Play ストアに公開してないアプリでも簡単にインストールして動作確認できる。ただ、アップロードしたファイルを 30 日間しか保持しないので、定期的にアップロードするための仕組みを作成しておくのが無難。

権限を付与した専用のサービスアカウントを作成し、なんらかのタイミングでアップロードする。

必要な権限を持つサービスアカウントの作成

属人化を防ぐ意味で、apk をアップロードするためのサービスアカウントを作成する。miam を使うなら以下のようにユーザを作成し、access key id と access key secret を発行しておく。

devicefarm:UpdateUpload もあるが、Android apk は対応してないため、apk を更新するには削除と新規アップロードのステップが必要。

apk のアップロード

aws-sdk-devicefarm gem のように、様々な言語実装による SDK があるのでどれかを使うのが便利。僕はこの gem を利用し、Fastlane にのっかっている。

create_upload メソッドによって署名付き URL が含まれるレスポンスが返ってくるので、その URL に対して apk をアップロードするリクエストを行う。

アプリのリリースフローに入れたり、毎週どこかの曜日で実行するなど、30 日より短いスパンで実行されるようなスケジュールを組んでおく。

AWS Device Farm を使う人向け設定

権限付与用の group を作成し、それをユーザに割り当てるのが良い。以下も miam を用いた場合の例。

おわりに

便利な世の中だ。

ステッカー大好きなので買った。何が良いかって、公式ロゴステッカーも一緒についてくるところ。意外と手に入れる機会がそうない気がしている。商品ページはこちらです。

毎回適当な写真を Unsplash で検索してねじ込んでいるが、欅坂46/乃木坂46 って繋がっているロゴっぽくて笑った。

7th は全曲披露なのが特に良かった。今年で楽曲が 200 曲になろうとする中、4 日かけて披露するのはめちゃめちゃ大変なんだろうな..くらいの思いを馳せることしかできない。

だけど今までの曲を新しいメンバーでやる、もしくは新しいメンバーが入ってパフォーマンスする光景を見ることで、新たな発見に出会うことが本当に好きなので、幸せだなと感じる。あーこの人めっちゃいいダンスするな、いい表情するなという気付きがあるのはお得。

久保ちゃんきっかけで 3期生に注目する機会が増えたので、選択を迫られた場合は無意識に 3 期生を目で追っていた。美月ちゃんが惹きつけるダンス踊ってたり、桃ちゃん泣かずに笑顔で歌ってるな、今までの曲のフォーメーションに入るのを見られる、というのは全曲披露のおかげなので、値段以上の価値を感じる。

オリジナルを聴いたその瞬間がめっちゃ良いのは当たり前なんだけど、上記のような体験もあるので好きな曲が姿を変えて生き続ける光景に出会うのも楽しい。行くあてや環状六号線、他の星からや不等号など挙げればきりがない。

1on1 について、促す側はどうするのがより良いかについて考える機会があったので、手始めに読んだ。

1on1 はずっと促される側で受けてきたのもあり、いかに課題を解決するかを考える場という認識。そのため、課題を自分ごとにして解決するための方法を捻出するというのを常に考えながら過ごしていた。

その癖で促す立場が全部自分ごとにする振る舞いをしてしまうと、短期的には効果があるかもしれない。しかし、促す側への依存関係が生まれる上に、組織が大きくなっていくにつれ中長期的には効果をなさない。というのも、組織の力は噛み砕くと個人個人の力の集合体が主な要素になるからと考えており、個人の継続的な学習へつながらなくなってしまうから。

そんなことをぼんやりと考えていたときに、ヤフーの 1on1 を読んだことで方向性は間違ってないことを認識した。それとともに 1on1 を自分主体で捉えていたという自覚にも気付くことができ、相手のためにやるものというスタンスを強く自分の中に植え付けられたように、視点をうまく変えられたなと感じた。

そうなってくると、自発的な行動をどう引き出していくか？というところに行き着く。ただそもそも相手がどう思っているかなんて聞かないと分からない。対話をちゃんとやっていく。

いかに自分がどう組織へ貢献するかという面で生きてきたが、どう組織を底上げしていくかという面を考えながら生きていくことになる。

個々人、チーム全体で生まれる価値をどう最大化するか、といったところの明文化を早急にやる必要があったが、個人においてはとっかかりを作ることができた。悩みの方向性がここ数ヶ月で急激に変わっているのを観測しているのでとても面白い。