今週の振り返り(2020/01/18)

DroidKaigiアプリのコントリビュート

github.com

昨年度はeasyラベルのissue1つだけだったので、今年は3つやりたい。ただ、アサイン埋まっているものばかりで辛い。

ConstraintLayoutのGuideLine

LinerLayoutで階層を作るのが可読性が良いと考えていたが、GuideLineを使えば基準を明示できるので良さそうだと感じた。これまでLinerLayoutのPaddingやMarginで調整していた部分を、オブジェクトとして管理できるのでわかりやすいし、ViewGroupの生成コストを抑えられそう

社内のテスト勉強会

DeNAの方を招いて社内のテスト勉強会があったので参加した。今回はユニットテストで、テストコードの設計に関するところが勉強になった。
直前になって報告ブログ書くように言われて焦ったが、とりあえず来週公開されることになったので良かった。

報告用社内ブログの書き方

良い書き方を知らないが、過去の社内のブログを確認してなんとなく方針が決まった. - 画像と文章を交互に表示することで、内容にリズムを作る - 簡単な内容は文章で自身の感想を交えて書く。 - 詳細な内容(細かい用語や図が出てくる箇所)はスライドを直接貼ることで、省力化する

ホントは自身の経験を踏まえて意見を入れていくのが良いのだが、分からない分野の報告に関しては読みやすさや見栄えを意識して書いていこうと思う。

Android勉強会

BonfireAndroidに参加した。懇親会でとあるスタートアップの方と前職の同僚の話をしたら、一緒に働いているとのことだったので、この業界は狭いな〜と思った

[http://hamburger.hatenablog.jp/entry/2020/01/16/Bonfire_Android%236%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%97%E3%81%A6%E3%81%8D%E3%81%9F:embed:cite]

LiveDataのset,post

業務のPRレビュー指摘があったので、ちょっと真剣に考えた。
基本的に(Mutable)LiveDataのsetValueはMainThreadで実行されるので、非同期処理中に呼び出されると実行時エラーになる。一方、postValueはIOスレッドで実行されるので、そのようなことはない。そのため今まで何も考えずにpostValueを使っていた。
しかしpostValueはsetValueに比べてコストがあるため、適切に使い分けるほうが良い。一旦、 - Activity,Fragmentから実行されるときはsetValue - それ以外(ViewModel内など)はどのスレッドで実行されるかは保証されないので、postValue ということでチーム内の了解を得た。

LiveDataはUI表示のために利用する

そもそもLiveDataは上記ユースケースを想定して作られている。そのため、最新の状態が画面に反映できれば良いという思想になっている。
するとどうなるかというと、連続してデータが流れてくると途中のデータが落とされる可能性がある。つまりLiveDataで連携されるデータを蓄積して履歴のような使いかたをするのには適さない。
データの信頼性が必要なものはRepository層で適切に管理し、その中からUIに必要なものをLiveDataに流すという考え方じゃないといけない

Android WebView内でのHTML5ビデオタグ

webVIewでビデオ再生をしようとしたらものすごくハマった。。。
AndroidのWebViewは色々と制限がかかっているため、ビデオの再生のようなちょっと難しい?事をしようとすると想定通りに動かない

(そもそもjavascriptの設定もだいたいセットしているのでそういうものと言われたら何も言えないが)

yusuke-hata.hatenablog.com

stackoverflow.com

開発しやすい環境づくり

前職で学んだことの一つに、文化を途中から変えるのは難しいというのがある。ただし例外があって、転職直後は会社に馴染むために社内ルールに従おうとする意識が発生するので、最初に文化を明示しておいてもらえるとスムーズに移行しやすい。
そのため、開発ルールの基本的なことはもちろん、自分の好みのルールがあってチーム内で反対されなかったら、どんどん社内標準ということにして明示化することで、徐々に自分が働きやすい職場にできる。あと、中々アクションを取らない人たちが多い職場で、積極的に行動することで自分の価値が上がる場合もあるので、ある程度打算的に動いて、自分のポジションを設定するのが良さそう。今週やったのは以下の通り

  • コンフルに登録
  • android専門のチャットグループを作って、android dagashiやgithubの情報を垂れ流す
    • 情報のたまり場にしたい
  • 標準ライブラリの利用
    • 驚くべきことに標準の Logクラスが使われていたので、勝手にTimber導入した
  • PRテンプレートの登録

デザイナーなどの職種

前職のデザイナーは優秀な方が多かったなぁと本気で思っていて、その後考えていたのでめも

今までデザイナーという人は、奇抜な絵を書いたり、フォトショをなんやかんやする人だと思っていた。しかし、ソフトウェアエンジニアが関わるデザイナーというのはそんな単純な仕事ではない。
彼らの仕事は求められているユーザストーリーを理解し、それを実現できるUXを検討して、そことソフトウェアをつなぐためのUIを決めているのだと思う。僕らはソフトウェアエンジニアはそのUIに見合う機能を提供しているだけ、という謙虚な気持ちで デザイナーとは接して行こうとか考えてた。
人に対する共感が無いとできない仕事なので、マジリスペクトっす

バトゥーキ新刊

バトゥーキ 6 (ヤングジャンプコミックスDIGITAL)

バトゥーキ 6 (ヤングジャンプコミックスDIGITAL)

敵キャラがブリーチのエスパーダのようにバリエーション豊かで熱い展開

Bonfire Android #6 参加メモ

Yahoo Japanさんが主催しているBonfire Androidに参加してきました。

yj-meetup.connpass.com

目的

  • キャッシュレス × Android のトピックのテーマってなかなか見かけないなと思ったので
  • この辺は流石ヤフーって感じ

内容

新 Kyash Card を支える技術

  • Kyashは人数が少ないので標準に寄せて学習コストを抑えてる
  • カードの描画でConstraintLayoutを使用していて、GuideLineで位置を調整している
    • SpaceやRatioを駆使すれば大概のViewは実現できる
    • ただし、Previewで一見して分からないView( = 可読性が低くて保守できない)は避ける
  • 自前ViewModelからandroidxのviewModelに統一した
    • 複数の画面で共有したいデータはSharedViewModelを活用
  • 以前から導入要望があったNavigatonも利用している
  • SharedVIewModelはデータアクセスを制限するために、interfaceを作成して、それをFragmentごとにInjectしている
  • SharedViewModelの注意点
    • ロジックを持つと複雑になるので、責務は制限すべき
    • まずは使わなくても良いようにすべき
  • SpringAnimation
    • viewにバネのような動きを与えるもの
    • SpringAnimationのほうがバウンスより簡単に自然なアニメーションを作れる
  • UIテストではKakaoを利用
    • EspressoのDSL
    • UIテストを書きやすくなり、時間も短縮できる
    • Espressoから書き換えたときにタイミングやDelayは調整する必要があるかもしれない

Q viewmodel、プロセスkillは?

A savedState使ってる

Q kakaoの他に選定した?

A kaspresso。機能が大きすぎるので依存しそうで避けた

UIテストに関する取り組み

  • 複数の画面サイズ・複数OSバージョン・ライブラリのアップデートの影響調査・minsdkversionの更新の影響調査などを対応したかった
  • アプリサイズが大きくなるに連れ、QAの手動テストが長くなっていった。
    • QAの手動テストを少なくする(なくすのではない)のが目的で導入した -小さく始めてall greenを優先する
  • firebase test labを活用するので、appiumではなくespresso
  • スクリーンショットテスト
    • 画面確認のためにやるので、通信部分はmock化
    • pros 画面開いてスクショ取るだけなので、メンテナンスコストが低い
    • cons そのままだとダイアログが映らない・結局目視が必要
  • ダイアログの問題は自分でダイアログのviewを明示的に取得しに行くか、Falconというライブラリを使う
  • スクショ目視確認問題
    • Facebookは期待値/実際のスクショの比較ライブラリを出している
    • wasabeefさんがブログを出していた
  • インスタルメンテーションテスト
    • 通信部分をmock化しないでテスト。とりあえずハッピーパスを通す
    • 複数端末の確認、初回起動時のみ発生するパターンの確認とかで助かっている ー UIテストはビジネスロジックをそれほど書かないので、慣れると時間がかからなくなる

API通信の状態をsealed classを使って表現する

  • アプリで管理すべき通信状況は主に以下の4種類
    • 初期状態
    • 通信中
    • 通信完了
    • 通信エラー
  • メルカリでは RemoteDataK というライブラリを使用している
    • 内部用のライブラリをOSS化したもの
  • 以下のようなよくある通信状態と意味を変数に持つデータクラスは状態を更新するために必要なロジックが多い
  • いっぽうRemoteDataKだと・・・
    • 拡張関数を使うことで更新ロジックを減らせる
    • そのままだとあまり変わらない
    • 状態をseald classで表現し、値だけ管理することで管理対象を減らせる
  • ただし、Errorは原因に応じたクラスを作成したほうが良いかもしれない

PayPay Androidアプリについて

  • 開発スピードが早いから色々大変
    • 週1のスプリント
    • 月から開発し、水〜金でQA
    • 2019年はios/android合わせて120回のリリース
  • SingleActivityかつFragmentは未使用
    • Fragmentはライフサイクルが複雑
  • lyft/Scoopというライブラリを使っている
    • viewベースに画面遷移を実現する。ライフサイクルがシンプルでわかりやすい
    • ただし、バックグラウンド時などの制御は注意
    • 現在はDeprecated

QA

Androidアプリ開発者の人数は?

  • PayPayが一番多い(2桁)
    • 書いていいのかわからないので具体的な人数は伏せておきます

PayPayはScoopはこれからも使い続けるのか?

  • 剥がすコストが大きいのと今の状態で困っていないのでこのままの予定
  • 新しいメンバーは皆驚くのが悩み
  • scoop利用後に、fragmentTransaction.commitNow()ができたので、Fragmentの辛みが減っているのは理解している。

感想・あとから調査したいこと

  • 全体的に、PayPayの戦略は人数が少なくて学習コストを抑えたいKyashさんと間逆だなぁと感じた
    • 登壇者の方もYahoo本体からの出向らしいので、採用が難しい状況でリソースの融通がきくのは強そう
  • GuideLine はすごく便利そうだと感じた。今まではLinerLayoutのほうが読みやすそうだと思っていたが、複雑なUIになればなるほどメリットが大きそう
    • ちょうどDroidKaigiのアプリで見かけて自分の中のホットトピックだったので、急に興味が湧いてきた
    • ConstraintLayoutを日頃使っている人の中では常識かもしれないが・・・
  • 会社では現在ユニットテストの対応段階なので、UIテストのイメージが少し湧いてきてやる気も出てきた
  • あまり〇〇Payならではの内容はなかったけど、競争が激しいからこそ開発スピードと品質をいかに上げるかを各社頑張っているような印象だった
    • みな自動テストは常識のような顔をしていたのにびっくり
  • 今日一番のパワーワードシュレディンガーのFragment

「攻殻機動隊のような組織が理想」というフレーズの危うさ

会社で思ったので吐き出しておく。断っておくと、なにか嫌なことがあったというよりは、忘れる前に自分のスタンスを言語化しておきたかった


各々が各分野のプロフェッショナルとして活躍できる人材のため、その時の判断でそれぞれが最善だと思うアクション繰り返していくだけで目的を果たせる、というのが攻殻機動隊(主にSAC)を見ていて心震える部分であると思う。そして、攻殻好きのソフトウェアエンジニアは結構多いので組織論を話すときに、公安9課のようなチームが理想だという流れになりやすい(自分の観測範囲では)。

完全に同意で僕も自分が若い頃はそういうチームの一員になりたくてスキルをあげようと頑張った。

担当領域の開発力とセルフマネジメント力、ユーザ(顧客)が何を求めているか正しく理解して 、その時点での最適な設計や技術選定ができ、自分ができない領域は誰に頼めばよいのか把握できて、周囲が自分に何を期待していて何をすることでそれを達成できるか。。。。そのあたりをできる人たちが集まることで理想のチームになるんだと思うが、正直自分はいつになったらそういう人材になれるのかと思うと気が遠くなる。

正直そのレベルの人はあまり見たことがない。googleのような一流企業にはいるかもしれないが。しかも、ベクトルの向き先が同じでも大きさが違うと期待値がずれてしまうので、ほぼ同じレベルの人間が揃う必要がありそう。

もし採用時にレベルが違うなら、チーム全体のレベルを上げつつ、自分もスキルアップしていかないといけないし、モチベーションが同じとは限らないのでそのためのアプローチも一人ひとり異なる。それを人が増えるたびに繰り返さないといけない。そう考えると理想のチームは9課でも、現実でそれを実現するのはかなり難しい。無理なんじゃないのかなぁと思うことも多い。

ここまでが前置きというか前提

世の中にはそのへんをすっ飛ばして、マネジメントしたくない・されたくないという理由で公安9課の例を持ち出す人が結構いる気がしていて、表題のようなフレーズを聞いたら警戒するようにしている。理想はそうだけど、現実は努力が必要だねっていうスタンスの人なら安心だけど。

意識共有の仕組みを整えて、外部からのマイクロマネジメントを徐々に減らす方向にしていくっていうのは必要だと思う。けど、いきなりマネジメント0にしても意識共有できなくなって困るだけだし、新入社員のマネジメントしないのもめっちゃリスキーなので怖い。


ということを考えていたんだけど、結局9課も現場メンバーが好き勝手やってるのを荒巻が超絶マネジメントしていたことを思い出した。結局どんな仕事もマネジメントは一定量必要で、人を理解する仕事なのでそのためのコミュニケーションは絶対必要だよなぁとあらためて思う

そんな感じです

攻殻機動隊 (1)    KCデラックス

攻殻機動隊 (1) KCデラックス

今週のふりかえり 2020-01-11

  • 転職した − 2020/01/06が初出社
  • さすがに転職も慣れてきた。いいか悪いかは別として・・・
  • 入社日の研修が眠くなるのはなぜ − 同期とあまり話すタイミングがなかったのが残念
    • よるごはん誘ってみればよかった
    • 今月末に飲みに行くので、そのときに仲良くなりたい
  • Githubを使って業務するのは初めてなので、ちょっとちぐはぐ
    • レビューのコメントの仕方とか。commentとかapproveとか
    • zenhubは便利だった
  • アプリの設計はMVVMなので、わかりやすいっちゃわかりやすい
  • その分書き方が古い。javaっぽいというかswiftっぽいっというか。。。
    • ひとまずenumseald classにリファクタ人間になろうかと思う
    • あとは、== null?.let に変えたり、timber入れたり、基本的なところも整備していきたい
  • 一応アプリ基盤チームらしい。皆が開発しやすいような環境を作っていきたいので、まずはAndroidアプリの整備をしたい
  • Ciecle CIやbitlize使っている(使い始めている)ので、期待大。
  • マネジメントがあまりしっかりしていないのと、役割もふわっとしているので、そのあたりの整備も自分のミッション?
  • 椅子が割とちゃんとしたやつだったので満足度高い
  • それなりに実務にちゃんと取りかかれそうなので一安心
  • 何気なく磯島のlineのタイムラインにいいねしたら、ご飯食べに行くことになった。元気そうで良かったが、お互い年取ったなぁという印象w

日報 2019-12-31

Navigationコンポーネントの調査

  • 日本語の記事はあまりないので、ちゃんとドキュメントを読むのが近道っぽい
  • 簡単な遷移は良さそうだが、遷移が入り乱れるアプリはどう管理していくのが正解なのかわかっていない
    • そもそも入り乱れるのが良くない?

developer.android.com

www.youtube.com

家族を迎えに行く

  • 雪の中1時間・・・

色々あった2019年だけど新年は心機一転新しい会社でがんばります

日報 2019-12-30

databindingのインスタンス宣言方法が変わっていた

private lateinit var binding: MainFragmentBinding

override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
//      もともと知っていた書き方はこっち
//      binding = DataBindingUtil.inflate(inflater, R.layout.main_fragment, container, false)
//      今はこう
        binding = MainFragmentBinding.inflate(inflater, container, false)
        return binding.root
    }

docs.google.com

エミュレータ

設定でwindowトップに固定にすると便利

エミュレータ起動->more->settings->Emulator always on top

kotlin-kaptとはなにか

ライブラリなど利用するときに記載するapply plugin: 'kotlin-kapt'が何なのかわかっていなかった。数珠つなぎでそもそものところも調べたのでメモ

kotlin-kaptとは

kotlinでjavaAnnotation Processingを利用できるようにするために必要

Annotation Processingとは

Annotationを使ってコードを自動生成する仕組み。例によく出されるのはJavadocだが、定型コードを自動生成するためにライブラリなどでよく使われている印象

Annotationとは

@アノテーション名で宣言する補足情報・ラベルのこと(例: @Override)

最終出社が終わった

2019/12/20が最終出社日だった。
2020/01/01から新しい職場で、有給消化で少し長めの年末休暇を過ごす予定。
前回の転職とは異なり、(自分の中では)非常に前向きな退職で、かつ色々思うところが多かったため残しておく。

※お酒を飲んで気持ちよくなっている状態で書いているので、文章ぐちゃぐちゃだと思う

何していたか

某web系自社サービス企業の某toC向けサービスのスマートフォンアプリエンジニア。Androidがメインで、iosも一部担当したり案件の調整のような軽いマネジメントもやったりしてた。

なぜやめようと思ったか

きっかけは妻の出産。もともと業務内容にマンネリ感があって思うところはあったが、関わっているサービスが女性向けで、生まれた男の子は将来使わないだろうなぁとかぼんやり考えていて軽い気持ちで転職活動開始した。

転職活動のスケジュール感

  • 9/1 ビズリーチ登録
  • 9月第2,4週 面談
  • 10月週2ペースで面談・面接(計4社)
  • 10/27 2社から内々定をいただき、うち1社の内定受諾。どちらも素晴らしい会社だったので、ギリギリまで悩んだ。

一週間おきにまとめてスケジュール組んでたので、実質1ヶ月くらいの転職活動期間だった

転職活動の戦略

漠然とやってても何も変わらないので、やるからにはちゃんと自分の考えの整理して最初の面談に臨んでいた。大まかに、以下のようなところを大事にして選択した

  • ソフトウェアエンジニアとしての成長と家庭との関わりとをどちらも大事にできそうか?
    • 基本はいろんな仕事を通じて成長したいが、何かあったときは心理的ハードルを感じること無く帰宅できるような文化か
  • 面談していただいた担当者の方とのコミュニケーションが辛くないか
    • 年齢を重ねるにつれ、チームの文化が合う・合わないが非常に重要だと思うようになった。特に、人とコミュニケーション取ることが得意ではない自分のパフォーマンスはそういうところに影響を受けそうだと思ったので、第一印象は大事にした
  • 特定分野のスペシャリストとして働くには能力不足だという自覚があるので、ジェネラリストとして広く浅く仕事をして成果を出すタイプであることを理解してくれるか

次の企業に求めたこと

  • 今の会社が嫌でどうしても辞めたいという感覚ではなかったため、辞めても家族が納得してくれるだけのポテンシャルを感じられるような企業
  • 子供が成長したときに社会が良くなっていることを期待できるような企業

上司への退職の連絡

1on1の場で伝えた。チーム・組織として不満に思っているところや課題も伝えたが、今回の退職は自分のわがままの側面も大きいため、誠実に話し合うことは意識したつもり。ただし、相手はそう思わなかったかもしれない(後述)。

退職までに何をしたか

上司に連絡した時点で退職まで2ヶ月弱くらいだったため、多少は余裕があった。可能な限り、自分がいなくても自走できる状態になるようにサポートすることを意識して仕事をした。

チームメンバーの成長を第一に考える

作業興奮的な物を求めて簡単なタスクをたくさんやっていた時期もあったが、自分は絶対できて他メンバーができないレベルのタスクは積極的に移譲した。もちろんフォローは意識的に行い、次一人でやったときになんとかなるように育てることを目的に行動した。逆に自分もメンバーもやればできそうな内容は、自分が引き受けてほかメンバーの学習時間を確保できるようにした

残るメンバーを中心として、自分はサポートするだけの人になる

これは過去の失敗をもとにやってみた。辞めていく人が辞める直前まで全力で仕事をすると、問題が発生してかつ残った人とのレベル差があるときに地獄を見る。極力チームの中心からは距離をおいて、擬似的に退職後の同じ環境になるようにした。

自分の考えを何かしらの形でアウトプットする

引き継ぎ資料をどのような形式で作るかは色々考え方があると思うが、過去から現在にかけてどのような変遷を遂げてきたか?の記憶を失うことが一番チームの損失になるのではと考えた。そのため、自分の意思や好みも踏まえて、考えている内容をwikiに残した

退職日に感じたこと

  • 暇。最終週はほぼニートで技術書を読んだりしてた。案件が自分を素通りして進んでいく状況は、安心と寂しさと両方だった。最後の一日は何をしようとしても集中できず、アプリのテストをしたり、思いだした仕様や課題を口頭で伝えたりしていた
  • チャット上でしかやり取りの無いような人に退職の挨拶に行ったら意外と皆認識してくれていて、念の為自己紹介したら「知ってますよw」みたいなリアクションでホッとした。また、皆口々に「出戻りOKなのでいつでも戻ってきてください」と声をかけてくれ、ちょっと胸に来るものがあった
  • 退職意思を伝えた上司の上司に挨拶したら、望んだ環境を用意できなくて申し訳なかったと言われてしまった。確かに環境の不満もあったが、それは会社を良くしたい気持ちがあって言っただけで謝られるような言い方をしてしまっていたのなら自分の伝え方が悪かった。今の会社は感謝してもしきれないので
  • 最後に全体へ向けた挨拶を終え帰ろうとしたときに、運用メンバーの子が声をかけてくれた。詳細は省くが、過去に何気なく声をかけたことがすごく良い思い出として覚えてくれていたらしい。 開発業務以外で会社の人達から感謝されることってめったに無いのですごく嬉しかった。職種が異なることを理由にコミュニケーションを取らないようにしていた人が大勢いたが、どうせならもっと積極的に関わっていれば気持ちよく働けたのかなぁと反省した
  • サービスに関わるのは開発者だけじゃなく、それ以外の職種の人も大勢いるということを認識できた。そして、その人達たちのおかげで売上がたつということも思い出せた。転職活動前後は開発チームを良くすることばかり考えていたが、良くすべきは会社全体であり開発チームだけではなかった。次の会社は皆が幸せに働ける環境や文化を作れるように少しずつでも貢献していきたい。

最後に

2020/01/01ってキリの良くて中々イケてる日付なので、次は長く勤めたい

チームリーダーをしていて気をつけていること

ここ3ヶ月位チームリーダー1をするようになった。求められている役割としては、

  • 技術的な問題に対して意思決定をする
  • リリーススケジュールを調整する
  • メンバーに対してチケットのアサインをする
  • チーム運営

など。手探りではあるが、少し落ち着いてきて考えがまとまってきたので、まとめておく。

仕事を依頼する際の伝え方

ルールを決めるときや案件をアサインする時、なるべくなぜそうするのか?を丁寧に伝えて理解してもらうようにしている。言い方としては以下のような感じ。

OK -> 「〇〇をしたいという要望があり、✗✗機能を実装すれば実現できそうだと考えています。△△に必要らしいので□□日までにMR出せるようなスケジュール感でお願いします」

NG -> 「□□日までに✗✗機能を実装してください」

おそらく、結論から伝えるというビジネス報連相を踏襲するとNGパターンのような言い方になりがちだと思う。でもこれだとなんのために?が抜けているので細かい部分で適切な考慮がされていないことが多く、レビューで細かく確認する必要が出てくる。作業者側も情報が不足しているため判断しづらい。なるべくユースケースを中心に伝え、それを実現するために仕事をしてもらうという風にすると担当者の自走がしやすくなる。

はじめは担当領域のプログラムを書くことに意識が向いていた人たちが、徐々になんのためにやっているのかを考えてアウトプットを出してくれるようになってきていて2、この方針は一定の成果を上げているのだと思う。

意思決定の納得感

上と重複する部分もあるが、何をするにも周囲が納得感を持ってくれるように気をつけている。大事にするのはあくまで納得感であり合意ではない。
合意を一番にすると意思決定が遅くなるような気がしていて、その一歩前の段階の納得感を感じられたタイミングで自分の判断を決定している。ただ、これは自分の意見を押し通すためではないため、反対意見で僕が納得できれば別の意見を採用することも多い。

これをないがしろにするとチーム内の信頼関係が薄れたり、主体性の低下につながると思っているので(自分がそう)、誰がリーダーやマネージャーになるのかといった組織に関することを決定する際も、エンジニアリングスキルと同じくらい重視すべきと考えている。

コミュニケーションのチャネルを増やす

今のチームでのコミュニケーションは、オフライン・slack・PRレビュー・MTGが主な手段である。それぞれプロコンがあり、どれかに偏るのは避けるべきだと考えている

オフライン

pros

  • 表情や声のトーンで文字以外の情報のフィードバックがある
  • 伝える際のハードルが低い

cons

  • 話し相手以外に情報が伝わらない

slack

pros

  • 情報が残る
  • 推敲できるので適切な内容を伝えやすい

cons

  • 発言する側のリテラシーが必要(適切な関係者に伝わるようにメンション・チャンネルを設定する必要がある)
  • 流れやすく印象に残りにくい

PRレビュー

pros

  • チケットのコンテキストがあるので、事前説明無くプログラムに関する議論ができる
  • 技術共有しやすい

cons

  • チケット以外の話題は伝えにくい
  • 汎用的な技術情報はPRレビューよりslackのほうがチームのメリットになる

MTG

pros

  • 会議室予約が面倒
  • 発言が個人向けではなく、暗黙的に出席者全員向けと解釈される

cons

  • 良くも悪くも、MTGの成果が進行役のスキルに左右されやすい
  • 全員向け以外の議論をしてしまうと途端にコスパが悪くなる

今の僕の方針

slackのprivateチャンネルは避ける

よほどのことがない限り、個人チャットやprivateチャンネルはさけ、情報をpublicにしている。仮に皆が見ていなくても、アクセスできるようにしていくことが意思決定フローの納得感につながる

1日2回はオフラインで話す

完全に守りきれているわけではないが、午前と午後に何かしら話題でオフラインコミュニケーションを取るようにしている。
いつでも話しかけて良いとは言っているものの、デフォルトでイヤホンをしている(良くないなぁと思いつつ、自分が作業できる時間帯は極力集中したい)ため話しかけづらいだろうなぁというのが一つ。あと、それをきっかけに色々話すことが多いので。本当はそういうことをしなくても話せる空気を作りたいが、話しかけても良い・毎日必ず会話するという意思表示をすることで、心理的安全性向上に一役買ってそう

定例MTG

いわゆる進捗共有的なものだとチームの課題が把握しづらく、発言者以外の当事者意識が低下しがち。そのため自身の進捗共有のような内容は各メンバーのタイミングで行うようにし(開始・終了・遅延)、定例ではやりたい仕事や困っていることの吸い上げを第一にしている。 この場ではサーヴァント型リーダーとして振る舞い、言われた内容のうちすぐできそうなもの(例えば〇〇の手続きがわからない的なもの)はすぐ対応する。また、忘れずにslack上でフィードバックする。伝えたことが改善されるという実感が持てると、次回MTGも積極的に参加してくれる。

自分が嫌いなパターン

なぜそう考えるに至ったかというと、非常に嫌なコミュニケーションをする人が世の中には一定数いて、それに対するストレスが自分のパフォーマンスに影響ありそうだったから。反面教師にすることで、少なくとも自分の同じ考えの人のパフォーマンスは下げないようにしたかった。自戒も込めていくつか書いておく

slackオンリーマン

距離感・重要性関係なくslackで会話したがる人。一見合理的なんだけど、文章量を減らした結果最初のNGパターンのような文章ばっかりだったり、そもそも情報共有が下手で読む側に理解するコストがかかってた

オフラインマン

ずっと口頭ベース。表情や声のトーンに情報を付加してくるため、物事を雰囲気で伝えようとしてくる人だった。チーム内で情報格差が出てくるので、それをカバーするために定例MTG増やしがち

仲の良い人にだけオフライン

個人的には一番ストレスの元凶だった人。仲の良い人にだけ口頭で詳細まで伝えるくせに、それ以外の関係者には簡素なチケットとリンクのみ送りつけてた。 情報格差が発生している自覚が無く、結果的に仲の良い人のみ仕事の成果を出しやすい環境になる

まとめ

  • いろんな方法でコミュニケーションをとる
  • チーム内の納得感を大事にする
  • 自分が嫌だった振る舞いはしない

  1. 正確には、サービス内のスマホアプリエンジニアリーダーでサービス開発チームのチームリーダーポジションではない

  2. レビュー指摘でも何度かユースケース実現を意識してほしい旨は伝えた

「Being Geek」を読んだ

昔読んだのに全く記憶がないのであらためて読んでみた。
経験を積んだからかもしれないが、すごく学びと納得感がある内容だった。 マネジメントする側になったからかもしれない。引用交えつつ感じたことを書いてみる

予想外の出来事に対する備えをせよ

自分は成長しているのか

  • 最近何かを失敗したか
  • 自分に異議を唱える人が身近にいるか
  • この一週間の間に学んだことはあるか?それについて説明できるか?

自分が転職を意識しだすのは、1つ目と2つ目がなくなったことに危機感を感じたときだったように思う。何かに挑戦をし、上手くいかず、周囲に正されるという経験をどれだけ積めたかが経験値として溜まっていくものであるはず。何も試行錯誤せず成功することもあるが、それは自分のレベルより低いものをいい感じにできただけのことが多い。そしてそれは、適切なレベルの仲間がいたほうがやりやすい事で、自分のレベルが低いからこそ、優秀な人達の意見を自分の知識として吸収していきたい。

自分は今、何をしているか?
自分はこれから何をしていくべきか
自分にとって何が重要か?最も考えるべきことはなにか?

自分の現在地と目的地を常に意識して、選択をしていきたい

転職先の価値

  • 会社に独自の価値があるか?
  • そこで本当に自分のやりたいことができるか

「相性が合う」と感じたか

電話選抜を受ける側の項だったが、日頃採用面接していて薄々感じていたことだったのでやっぱりというところだった。

私は、質問の答え方で「この人が会社からいなくなったら寂しいと思うか」を見極めることにしている
30分話してもコミュニケーションをどう取っていいかわからない人は、チームに入ってもおそらくみんなと上手くやっていけないと考える

若い頃は、人格やコミュニケーション力よりも技術力が大事だ!と思っていたが、リーダーをしているとそれが半分当たっていて半分間違っていたことに気づいてくる。もちろん技術力を伸ばしていくのは大前提だが、基礎能力としての当たり障りなくコミュニケーションを取れる必要がある。意外と、世の中には技術力のみに特化した情報共有に支障をきたすような人物が多くいる。そういう人がいるチームは総じて情報共有が下手で、チームで働くメリットが薄れてしまう。チームで働くなら、スケールしやすいような状態を意識しないといけないし、そのため必要な要素は技術力だけではないと思う

組織の上下関係

組織内に上下関係が設けられているからには、そこにやはり意味があるのだ
地位を飛び越えて情報を伝えてしまうと、その情報が伝えられるべき人に伝わらず、伝えられなかった人が孤立するのだ

上下関係を意識することで必要な人に情報を伝えることを矯正されるというのは、クリーンアーキテクチャーで各コンポーネント間の依存度を下げようとするのと同じことなんじゃないか。必要なレイヤーの適切な人物を通して情報伝達することで、安定した意思決定が可能になるのかもしれない。

愚かな上司

発生した問題を上司に報告するのは、一つはその問題について話し合うためであり、一つは協力を養成するためである
しかし、報告した上司が愚か者であれば、そのどちらの目的も達せられない

ここ読んでるとき、皆誰かの顔を思い浮かべて読んでるんだろうなぁ。。。
悩みを相談しても、受け止めて吸収してなんの変化も起こさない上司は何人かした。先を見据えて積極的に介入し、かつ自分がすべて解決できるとは考えず謙虚な気持ちを忘れないように・・・できるといいけど難しい

とっさの反応の分類

自分が驚いたときのとっさの反応は、「固まる」「(落ち着け落ち着け。。。)と心のなかで反芻する」「ゆっくり見回し、落ち着いて整理する」だと思う。どちらかというと逃避かも。

ソフトウェア開発をゲーム化する

雑にまとめると、 - ギークはゲームが好きだ。 - 繰り返し試行錯誤して仕組みを理解し、最適化するような過程が楽しい - そしてそのレベルがどの程度なのかは測る指標があるとなお良い - 仕事をゲーム化することで、ギークは熱心に仕事に取り組むはず みたいな感じ。ルールをハックしていく感覚に高揚感を覚えるのはなんとなくわかる気がする。
バグ対応をゲーム化できるようなチームが良いなぁ

採用通知を出して終わりではない

転職はギークが苦手な安定を壊す行為であり、精神的なコストが非常に大きい。本当に来てほしい人材には繰り返しメッセージを贈り、いかにその人を待っているか、来てほしいかを伝え続けるくらいがちょうどよい。とはいえ中々行動に移せない内容

日々のタスクの管理

タスク管理するというタスクが生まれると、タスク管理が面倒になるというのはなるほどなといったところ。雑に余白をもたせて管理することで、低コストで自分の状況を把握できる様になる。あくまでタスク消化の手助けが目的で、完全な管理をすることは目指さない

危機と創造

危機を解決するのは自分の責任だが、同時に聞きを招いたのも自分の責任である可能性が高い

確かにその立場で危機が生まれたら、自分のせいだよなぁ
危機の解消は気持ちがいいものであるが、そればかりだと戦略が失われ、使った労力に見合ったものを作り出せない

無意味なことをする

仕事から離れ、いつもの自分にはないものを取り入れることで脳の中で新しいなにかが生まれる。それを行うには、書店で雑多な情報におぼれてみるのが一番。確かに書店はいろんなインスピレーションのきっかけになっている気がする

3つの役割

時間、品質、機能以外にも、ソフトウェア開発には調整可能な要素がある。それを3つの役割で判断して行くことで白か黒ではなく、一番最善のグレーを見つけられる。

ビット

製品つくりを担う役割

機能

製品の内容を決定する役割

真実

正しい情報を把握して提供する役割

マネージャのお仕事

  • コミュニケーションのハブ
  • 情報の抽象化とフィルタリング
  • 部署ごとに必要な言語を選択する
  • 最前線でドラマを見る
  • 変化球への対処
  • エス・ノーという
  • 自分のスキルをスケーリングする

読書中のメモはどうするべきか

子供が生まれて休日の勉強時間が取れないため、最近は平日の帰宅時にカフェなどによって技術書を読むようにしている。読んだからには他の人みたいに感想をブログに残しておきたいがうまくいかない。理由として、良いと思った点があってもすぐ忘れる、覚えててもページを探せなくて細部が思い出せないなどがある。

後から思い出せるようにいくつかの方法を試してみたが、どれもうまくいかなかった。

例えば本に付箋を貼る場合、剥がれたり付箋を忘れたりして定着しない。あと。なんとなく付箋を貼っている本を読んでいるのが恥ずかしい感覚もあり、重要性が低いなと判断して剥がしたりしてしまう。他にもノートのメモは書くのが面倒、PCのメモはPCの持ち歩きがしんどいなど(MBP15inch2012midは重い)。

で、ある日突然思いついたのが、google keepに該当ページの写真を貼っていく方法。これがなかなか良い。

特別な道具がいらない。スマホがあれば良く、カフェの小さいテーブルでもじゃまにならない。メリットはそれだけだが最高だと思う。
まだ試していないが、google lensで写真のテキストコピーもできそうなので、引用したい場合もある程度手間をかけずにやれる(はず)。

f:id:burgerham:20191127013847p:plain
適当に撮りだめていけるのが良い

これでブログ三日坊主卒業できるかもしれない!!!と期待しながらBeingGeek読んでる途中。

「Java言語で学ぶデザインパターン入門」を読んだ

目的

  • 自身のコードレビューをより良くしたかった。今はバグが発生しないか?やtypoやコード規約レベルの内容ばかり指摘していて、長期的に良いプロダクトを作るのにつながるような議論ができていないように感じる
  • アーキテクチャに関する議論をしているときに、前提知識として必要になっているなと感じるシチュエーションが度々発生していた。ある意味エンジニア間の共通言語として必要不可欠な知識となっている気がする

全体を通して

  • 個別のパターンについて細かく覚えられてはいないが、よく聞くパターンや用語について理解することができた(Observerパターンなど)。
  • なぜそれが必要なのか、どういうときに役立つのかを あなたの考えを広げるためのヒント で解説してあるため、サンプルプログラムと自身の過去の経験と照らし合わせて想像できた
  • 昔、サンプルプログラムとUMLの理解を意識しすぎて挫折していたた、後半の解説を腑に落ちるように自分で咀嚼するのを繰り返したら、楽に読み進められた。次読むときはきちんと練習問題もやるつもり(今回は挫折する前に読み切ることを第一に考えたので飛ばした)

メモ

Adapter

  • すでにある機能をに変更を加えたい時、直接変更を加えるのではなくラッパークラスを作って振る舞いを変更するようにすると、テストすべき影響範囲が減る。もちろん、処理速度やわかりやすさ等でデメリットが発生する場合もあるが、急いでいるとき等の選択肢の一つとして持っておきたい

Builder

  • 昔よくわからなかったものの一つ。最近必要性がわかるようになってきた
  • インスタンス生成に複雑なステップを踏むクラスがあり、それがいろいろなところから使用されている場合は検討すべき。利用側が知る必要がない項目を隠蔽でき、修正が必要になった場合も影響範囲を少なくすることができる

Strategy

  • 処理ロジックを差し替えたい時等に使える
  • 昔やった案件の、〇〇会社のときと✗✗会社のときで金額計算ロジックが違う、みたいなシチュエーションで役立ちそうな考え方

Decorator

  • 弊社のRailsで採用しているレイヤ
  • データ本体を、View用に装飾するために利用する。データの中身と共通IFにすることで同一視できる(透過的インターフェース)

Facade

  • 複雑なものをシンプルに扱えるようにする窓口
  • 青い銀行のシステムの中に出てきていた気がする。当時はそういう固有名詞としか教えられなかったので全然理解できなかったが、デザインパターンの一つだったならそう言ってもらえればよかったのに。。。
  • 複数の複雑な機能を無理に共通IFに揃えるのではなく、ファサードの役割のクラスが最小限のpublicメソッドを公開して適切に利用できるようにしておけば解決しそうな部分がありそう

Mediator

  • なんとなくFacadeとカブる部分がある。おそらくまだ理解が足りない
  • FacadeはIF、Mediatorは内部の処理ロジックの抽象化・カプセル化を扱っているという理解

Observer

  • よく聞くやつ。Pub-Subモデルとか
  • Observeに通知して、購読者がそれをまつ

State

  • Kotlinの seald class は状態を表す用途に最適であるとあらためて感じた

「Kotlin Fest 2019」に少しだけ行ってきた

kotlin.connpass.com

セッション一覧

Kotlin Fest 2019 セッション一覧

全体の感想

  • kotlin固有でAndroidに限らないテーマが中心なので、MPP関連が多かった気がする
  • 普段は言語仕様をそこまで意識しないので、深く考えるきっかけになる
  • 皆発表上手

以下、特に印象に残っている内容について

Kotlinの型実践入門

speakerdeck.com

Nothing

  • 値が存在しないことを示す
  • これはコードを見るのが早い
// 処理失敗でUnitを返してしまうと
val unitPattern : Any = if (isHoge) { // Any型になる
  "success"
} else {
  Unit
}

// Nothingにすると 
val nothingPattern : String = if (isHoge) { // Nothing以外で返却される型になる
  "success"
} else {
  Nothing
}
  • プロダクトで利用する良い例が思いつかないけど、失敗時にExceptionを発行するような処理を書くときに使えそう

改めて学ぶContracts

speakerdeck.com

  • そもそもContractsを知らなかったので、この発表を聞きながら理解を深めていった
  • 関数の結果をContract(契約)によって表現する
  • String?.isNullOrBrank のチェック後にアンラップされるのは、結果がnullでないことを関数側から契約で定められてるから、みたいなイメージ。もう少し勉強が必要

Kotlin Serialization ことはじめ

  • jsonでもProtobufでもkotlinでシリアライズできる
  • パフォーマンスはそれほど変わらない
  • jsonのみのAPIならmoshiとかで良い
  • 帰る直前だったので記憶が曖昧。。。資料公開されたらもう一度見たい

「Google Play APP DOJO #38 Android Q 新機能詳細 - ダークテーマから共有機能まで -」に参加してきた

f:id:burgerham:20190618024035j:plain

目的

Google I/O で発表された新機能について、アプリ開発者向けに説明していただけそうだったため(IOの動画をちゃんと見てない・・・)。英語動画が厳しい自分でもキャッチアップできるかなと思った

Twitter -> #appdojojp

全体の感想

内容のボリュームや難易度がちょうどよく、非常にわかりやすかった。なんとなく技術記事で見たような気がする話題も、改めて人に説明してもらうことで理解が深まった気がする。

第 1 部 Android Q 新機能詳細

プライバシー

チェックリストを確認しよう

位置情報

バックグラウンドで位置情報を取得するためには追加でパーミッションが必要になる

Scoped Storage

  • /sdcard以下へのアクセス制限
  • ただし、自分で作成したファイルへはアクセス可能
  • Android Rからは、FileSystemでアクセスできなくなる予定

ダーク テーマ

  • 以前から存在するが、OS設定としてできるようになった
  • 非対応アプリが少数派になったときに、ダークモード設定で未対応アプリを起動したときに悪目立ちする

対応方法

下記のような対応で、ある程度自動でやってくれるとのこと。

  1. テーマ変更 -> Theme.AppCompat.DayNight
  2. 細かく設定することもできる -> values/styles.xmlvalues-night/styles.xml を用意
  3. テーマそのまま、プロパティ追加でも -> これでも結構いい感じになるらしい
<style name="AppTheme" parent="Theme.hogehoge.Light">
    <item name="android:forceDarkAllowed">true</item>
    # hogehoge
</style>

# 一部を除外したいとき
<ImageView
    android:layout_width="match_parent"
    android:forceDarkAllowed="false"  # これ

もちろんxmlファイル上で色を直接指定している場合は変換されない。UIの内容をxml側で表現している場合、ひとまずstyleにまとめていくなどして、きたるべき日に備えていくのが良さそうだと感じた

ジェスチャー ナビゲーション

  • Android Qからは見た目iosのようなジェスチャー操作になる
  • 現在のシステム設定では既存の3ボタン or 戻る/ホームバーの2ボタンが存在するが、Android R以降は 3ボタン or ホームバー1ボタン の2種類になる
  • ジェスチャーの下までコンテンツを表示してるといい感じ
<style name="AppTheme" parent="hogehoge">
    <item name="android:navigationBarColor">@color/red</item>
    <item name="android:statusBarColor">@color/blue</item>
view.systemUiVisibility = View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION or View.SYSTEM_UI_FLAG_LAYOUT_STABLE
  • 既存のスワイプ操作とのコンフリクトは、コード側で対応可能
  • 標準のドロワーレイアウトであれば、ライブラリのアップデートでOK

Bubbles

  • FacebookMessenger等で表示される、アプリ長押しで表示できる画面
  • Androidチーム的にはシステムアラートウィンドウは将来消したいらしい
    • フリーダムすぎるらしい
    • Goでも非搭載なので、消えるのは確定みたい
  • Bubblesはそれの代替手段として用意された機能
  • ただし、Android Qでもプレビュー版しか提供されないので、開発者オプションで設定する

有機能の強化

  • Android Mから搭載された、共有パネルが改善
  • DirectShare(名前あってるか自信ない)の領域の表示遅延が改善

SettingsPanel

  • 画面遷移しなくても設定画面を表示できる
  • パーミッション取得時に設定に飛ばしてる画面があるので、そこで活用できそう
  • 表示できるのは設定項目4種類
  • 表示しているのはあくまで設定項目であって、パーミッションではない(QAにて)

QA

  • NavigationDrowerとジェスチャーは動作がコンフリクトするが、NavigationDrowerがなくなるというわけではない
  • ジェスチャーUIになったときに、クリック要素がナビゲーションバーとかぶるのは避けたほうが良い(bottomBarとか広告とか)
    • addApplyInsetsListener (?)の引数で必要な高さが取得できるので、それを活用してマージンを設定するのが良い

第 2 部 Jetpack 最新情報

既存のライブラリの新機能

ここはコードが多かったので概要だけ

LiveData & ViewModels

kotlin firstの一環で、いろんな構文がより短くスマートにかけるようになった

DataBinding

Android Studio 3.5で書きやすくなった -> インクリメンタルアノテーションプロセッサー

savedState

ViewModelはメモリ上にデータを保持するので、プロセスが中断されるとデータが消えてしまう。そういう場合もデータを保持したい場合はviewModelで SavedStateHundle を使おう

WorkManager

foregroundでもつかえるようにする予定(WorkManager自体よくわかっていないので記憶が薄い)

Room

Paging

  • ネットワークからの取得を用意に
  • ヘッダー、フッダー
  • RxJava

CameraX

  • 内部でcamera2apiを使っているが、抽象化して簡単になっている

ベンチマークライブラリ

  • Junit等で結果を出力できる
  • これだけでよくなるわけではないが、CIで監視することで品質が一定であることを証明できる

セキュリティ

端末から抜き出せないようになっている秘密鍵を使って暗号化することで、万が一データを見られても解読できないようにする

  • EncryptedFile
  • EncryptedSharedPreferences
    • tokenなどをSharedPreferencesに保存してたので、これはめちゃくちゃ便利そう

QA

  • 今後cameraXの機能追加はあるのか
  • フォーラムから要望を出してくれれば、検討して実装されるかもしれない。実際今もどんどん改善されている

APP DOJO プログラムマイナーチェンジについて

developers-jp.googleblog.com

  • Playストア表示ロジックが変更される
  • 良いアプリはより目立つ位置に掲載され、それが反映されるようなランキングロジックになる
  • これに則した活動になるように改善される予定とのこと

DroidKaigi2019/02/08(二日目)

Android App Improvement Challenge Part1: 機能実装編

  • 機能追加した
  • 30分だけ参加だったのでリストに時間を表示するissueのみ

Slice Your App: Inside Slices and How to build it

  • Google検索やAssistantにコンテンツ表示する際に使用する
  • AppIndexingの仕組みと一緒
  • Sliceのスレッドで通信やレスポンスを一定時間内に返却できない場合に死んでしまうので、一度ローディングViewを表示した後データ取得後に再描画すれば良い
    • Sliceはアプリ内ローカルデータしか表示できないものだと勘違いしてた
  • パラメータとして時間を持っているため、単純比較のassertではテストできないので、パラメータを適切にフィルタリングする必要がある

Android App Improvement Challenge Part 2: リファクタ編

  • ヒントブランチ読んでたら終わってしまった・・・

Android Studio設定見直してみませんか?

  • とにかく楽しめた
  • 自分用リストを作ることに決めた

今日から始める依存性の注入

  • 外部から依存関係を注入することで疎結合を実現する。それをすることでアプリを拡張しやすくなったりテストしやすくなる
  • DIにもスコープがある
  • なんとなくわかってきたらgithub上のコードを読んでいくのが理解への近道とのこと

multi-module Androidアプリケーション

  • メリット
    • ビルドの高速化につながる
    • build variantの変更で開発ビルドを分けている場合、プロジェクト外のコードはリファクタ対象外なので修正しづらい。その辺が解消する
  • compile→api or implementationに変更
  • api 参照先が変更されたらすべて再コンパイル
  • implementation 直下が変更されたときだけ再コンパイル
  • どのような構成だと恩恵を受けられるか
    • 資料参照
  • 既存モノリシックプロジェクトをマルチモジュール化する場合
    • 一旦最低限必要なもの(applucationクラス)とそれ以外で分ける
    • 新規機能は個別のモジュールに
    • 新規機能と既存機能で共通する機能を別モジュールに
    • 既存機能は必要以上にモジュール分割しないほうが良い(機能開発が進まなくなるので)

実践 WorkManager

  • WorkManagerを使ってバックグラウンドで画像をキャッシュした話
  • タイムアウトがあるので分割必要

Google Play Consoleのリリーストラックを有効活用してリリースフローの最適化を行った話

  • masterブランチを自動でアルファリリースするようにfastlaneを書いた
  • リリース前レポートを軽いテストとして活用しようとしたが、通知が貧弱だったため断念
  • アルファ→本番リリースは手動