Image for post
Image for post
Photo by Daniel McCullough on Unsplash

この記事は「GMOペパボエンジニア Advent Calendar 2020」の 4 日目です。3 日目は、あんちぽさんの「ある社会人学生の生活と意見(2020年版) | 栗林健太郎」でした。

普段は minne Android アプリに関わるところでがしがし開発しているので、僕からは開発基盤における改善をお送りします。

目次

2. Rx{Java/Android} を LiveData と Kotlin Coroutines へ

3. GitHub Actions

MVP から MVVM パターンへの移行

もともと minne では創成期の無秩序の状態 (UI クラスにビジネス/プレゼンテーションロジックが記述されている状態) からしばらくして、 MVP (Model-View-Presenter) パタ …


Image for post
Image for post
Photo by Daniel Schludi on Unsplash

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

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

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


Image for post
Image for post
Photo by Toby Stodart on Unsplash

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

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

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

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

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


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

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

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

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

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

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

Image for post
Image for post
この記事を書き始めたときに存在していた Twitter の下書き

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

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


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

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

導入

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

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 をアップロードするリクエストを行う。

Fastlane での apk アップロードリクエスト例

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

AWS Device Farm を使う人向け設定

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

おわりに

便利な世の中だ。


仕事中にはっと気付いてしまった様子
久保ちゃんの電視台を見たときの様子
絢音ちゃんの電視台を見た時の様子。なんでこの時つぶやいたのか覚えていない
割烹まなつに来てた梅さんを見た時の様子。映像研見てから急に気になるようになった。
アスミカさん
麻雀は役を覚えるのが難しいと思っている。花札は覚えている
ゲストと共に乃木坂の名ライブシーンを語る久保ちゃんのコーナー。企画した人と久保ちゃんに感謝
くつろぎながらスマホいじってるある意味自然な光景を見た様子。755 見る分には本人的には不服そうだったけど、ここ本当に良かった
与田ちゃんが大人になってる光景を見ていたら、りんごさんのおかげで真顔になった瞬間。盛り上げ方がうまい
久保チャンネルで、美月ちゃんが久保ちゃんとダブルセンターをした不眠症を挙げた時の様子
1期会でみなみちゃんはいつまでもみなみちゃんだなと感慨深くなった様子
人狼 1巡目でいなくなった悲しみの様子。2回戦は結構残っていた
3期は良いけど結局選べないなという様子
ああ、終わるんだな…と認識した様子。1, 2 日目見ていたときは終わることすら考えていなかったほど熱中していた。
毎日が Brand new day のパフォーマンスを初めて見た様子。アナスターシャも I see… も良かった。
結果来なかった様子。映像研のポスター貼ってあったのでそういう意味でも来るかなと思っていた。
かなりんの伝説。ハッシュタグトレンドのったらしい。めでたい

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


Image for post
Image for post
Photo by Bryan Garces on Unsplash

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

なーちゃんの姿を目に焼き付けないといけないと思い立った様子

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

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

ガールズルールサビで美月ちゃんが抜かれた様子を見た感想

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

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

やっぱ乃木坂だな と噛み締めた様子

Image for post
Image for post
Photo by Ian Kirkland on Unsplash

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

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

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

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

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

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

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

mataku

Club kids never die

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store