00:05
おはようございます、Rayです。
本日もRay Wow FMの時間がやってまいりました。
Ray Wow FMでは、主に株式会社耳に関する様々なテーマを扱って、時にはゲストもお招きしながら、ゆるくやっていくラジオとなっております。
今日は、Androidテックリードの靴さんをお招きして、Androidの日常について色々とお話しできたと思います。
よろしくお願いします。
靴さんは、実は皆さんも知っているかもしれませんが、耳にもともと関わってもらっていて、退職して1年半くらい前に再度入社してきたというところがあったのですが、
2006年から入社して、
大手のお客様のPMとかアーキテクトという形でプロジェクトを推進していってもらって、
技術部分ができていないというところがあって、エンジニアにジョブチェンジして、当時もAndroidですかね。
そうですね、最初は。
フロントはNodeかな、Node.jsとかでしたっけ。
そうですね。
一部やってもらっていて。
そうですね。
比較的にAndroidエンジニアとしてやっていきたいというところで、退職を10年くらい退職したんですかね。
11年くらいですかね。
退職して、ずっとAndroidエンジニアで活躍していく中で、前職でもAndroidを開発してもらう中で、
組織的なところの組織づくりとかに関わっていきたい。
関わっていきたいというところで、たまたまに耳はそういうところでやっていこうというタイミングもあって、再度入社してくれたという感じですかね。
はい。
合ってます?
合ってます。
はい。
で、屈算化すると本当にそれできるの?みたいなところの不安とか部分もあったかもしれないですけれども、入社して1年半経つ中で、だいぶ組織づくり、人数も増えたんですけれども、
それだけじゃなくて、
アンドロイドグループっていうところで、今26名で26個のアプリやってるんですよ、実は。
多い。
多いんですけれども、普通に考えると結構、よくよく考えるとなかなかそういう、ゲーム系除いて、そういうだけのサービス系のアプリやってる会社って意外に少ないんじゃないかなと思っていて、
普通であれば、プロジェクト性であると、プロジェクトにエンジニアがロックインされがちだし、じゃあっていうので、プロジェクトをいくつかまとめて、
03:04
5名とかいくつかのチームまとめて、ユニットみたいな感じにすると、ユニット間の人の移動とか連携っていうところが結局しにくくなるっていうところを、
いかにね、この26名がうまく連携できるようにするかっていうところの組織づくりを、ミミミとしても挑戦して、変革してっていうので、ミミミマトリック組織っていうのをやってきたんですけれども、
その中で構造として、アンドロイド委員会っていう委員会組織がありまして、
はい。
そこの委員会組織は主に作戦本部みたいな形で、技術標準やどこに技術投資をしていこうとか、育成であったりとか、そういう大きな方針を立てて、
その方針に沿って、特に各今、アンドロイドチームが動いていくんですけれども、特徴的なのが、テックリードチームと呼ばれるチームがあります。
そのチームは、テックリードが集まって、主にどこかのプロジェクトにリードエンジニアっていう形で、
コードエンジニアっていう形で推進していくというよりは、その横にいて支援していくというところで、設計レビューとかコードレビューを行うっていう形で、
この作戦本部がいて、アンドロイド委員会。
で、アンドロイドテックリードチームという支援部隊がいて、で、各プロジェクトごとのリードエンジニアとかアンドロイドエンジニアっていう実行部隊がいると。
この3つの構造で強調してやっていると思うんですけれども、まず組織作りっていう形で、
はい。
クスさんが入社して、何か最初に取り組んだこととかって何かありましたっけ?
とりあえずですね、最初に取り組んだのが、まだGitHubって全面的に使ってなかったんですよ。
GitLabとかだったり。
GitLabとか、また違うGitHubがあったり。
そうですね。今、GitHubビジネス、いわゆるエンタープライズのSaaS版ですね。
そうですね。
そうですね。
そうですね。
そういうのがメインになってますけども、当時はそうでしたね。
なので、社内のエンジニアもどこに何のソースがあるのかっていうのが、ずるがしなんだろうな。
ブックマークしてるやつしか知らないような状態だったので。
そうですね。
なので、それを一箇所にまとめるっていう意味で、早い段階で全部GitHubにしてもらいました。
あと、いろんなCIとかバラバラだったり、あまり連携してなかったりとか。
そうですね。チェンキンス、チェンキンスの一部使ってたんですけど、もう1年半前の時点で、なんかレガシーな感じになってきてましたね。
ちょっと運用が難しいっていう。
なので、ビットライズですね。あれ全面以降。
意外に良かったですよね。サークルCIとか使ってる会社もありますけど。
ビットライズはすごい簡単に使えるので、いいですね。
投票判いいですね。ビットライズ。
はい。
06:00
あれも今後も使っていくかなと。
そうですね。
逆になんか、CIとかって一生懸命やってる人がそんなになかったので。
なんですかね。
特になんか反発もないというか、みんなそれほどやってないんで。
良いものができたって感じでしたね。
一気にこうできたって感じです。
その他どういう取り組みを?
あとはですね、フォーマッターが揃ってなかったんですよ。
なので、プルリクを送るたびに差分がものすごい発生するとか、人によってすごい書き方が異なるっていう状態だったので。
今後プルリクを重要に、デビューを重要にしていくっていうのを決めてたので、まずフォーマッターを揃えるっていうのになりましたね。
大事ですね。
あとなんかそれを自動的にチェックする仕組みみたいな。
なるほど。そういう活動をまずはなんかこう、福祉さんが単独でやっていたりする。
単独というか、みんなで協力して。
そうですね。早い段階から組織ですかね、方針を決めた上で、委員会という形を少しずつ作りながら、みんな巻き込んでやっていった感じですかね。
逆に委員会はあんまりそんなに、なんですかね。
テクリートチームと委員会ってなんかちょっと、住み分けが、今もそんなに、これどっちなんだろうっていうのがあるので。
うん。
テクリートチームは3人しかいないので、何だろうな。なんか競技するっていうのは、こともそんなになくて、普通に3人くらいなんで。
やりましょうっていう感じで。
伝わっちゃうような感じなので。
そうですね。
あんまりなんか会議してるって感じでは。
うん。
もちろん、もちろん。
ないですよね。
そのほか、決まっていったこととかですか?
まず、Android担当の部屋みたいな形で、ナレッジポータルみたいなものを作って、過去の不具合とかハマりポイントみたいなものをまとめる活動も推進されたなと思ったんですけど。
ヤナセさんが?
うん。
そうですね。もう一人のテクリートの。
出てたんですが。
2018年の3月くらいからスタートしてますね。
はい。
そっちはあまりそんなにまだ売り切れないような感じがしますね。
まだこう、網羅的には溜まってない感じですか?
うん。
それなりにコンテンツは溜まってはいますけども、パッと見た感じ。
09:00
うん。なんか、継続的になんかまだ溜まってる感じはしてないので。
うん。
だから、各チームに浸透してもっとこう、ナレッジが溜まっていくような流れができると、今後いいかなっていう感じですかね。
うーん。
委員会としてはなんかそういう方針決めて。
そうですね。
今までちょっと拾っていった感じですかね。
はい。
テクリートの人が気になるところをこう、コンフルのナレッジポータルでまとめてるみたいな感じか、メンバー自身がこれちょっと気になったやつをまとめるみたいな流れになるといいかなという感じですかね。
そうなんですよね。
はい。でもまあ、それなりの情報レールになってますね。
あとは、レビュー体制っていったときに、今で言うと26個のアプリがあって、それをこう、もちろんチーム内でピアレビューはする部分もあると思うんですけども、リードエンジニアが全部レビューするとかなると負担もあるから、そこを支援部隊っていう形で、テックリードの人が3名分担しながら、それもチームとして支援できるようになってます。
はい。
はい。
それで、支援っていう形でレビューしていくっていう構造も少しずつできてきたんじゃないかなと思うんですけど。
はい。
その辺りもどうですか?レビュー。
そうですね。レビューはもう早い段階でできてましたね、分担も。3人で最初にどれやるってことなので。
そうですね。優先順位決めて。
はい。
それも最初の頃はもう週1でちゃんと分担調整してやってたので、今はそんなに一生懸命調整してないんですけど。
してなくても。
そうですね。
みんながみんな見れるようになってきたっていうところもあるんですかね。
それもあると思いますね。
うん。
今は普通に、なんていうんですかね。
今はテックリードがメインでレビューするっていうのをやるけど、ピアレビューで、プロジェクト内でもなるべくピアレビューしてもらうっていう方向性ですよね。
はい。
結構そうしないと、他の担当者がやった工夫とかも学べない。
そうですよね。
はい。
できるだけチーム内でレビューする。
チーム内で。
うん。
あとは、技術的な標準みたいな形で、この開発標準を使いましょうとか、設計はこれやりましょうとか、こういうガイドラインについてやりましょう的なことにベースの中、作ったものありましたか、進めていったり。
えっとですね、これ実はドキュメントにはまとめてないんですけど、基本的にGoogleの標準のものを全部使っていくっていう。
うん。
そういう感じになってるので、なんかレビューを通してそれを。
なるほど。
やってる感じですね。
うん。
標準は。プロジェクトの最初の構成のときに、大体レビューしちゃうので、そのときになんか標準的なものが入ってるみたいになってると思います。
12:08
うんうんうん。
最初のイミミの場合だと、設計、レビューが基本、新規のプロジェクトの場合がありますけど、そのときに開発標準として、どういうライブラリーとかどういうものを使っていこうかっていうのがあるんですね。
はい。
どういうものを使っていこうかっていうところで、レビューが入ってこれ使いましょうみたいな感じだと思うんですけど。
そうですね。
そのときになんか新しい、この1年半の中でも新しい技術スタックって出てきたと思うんですけど。
はい。
割とテックリードチームの役割としては、新しく導入するときにリスクがないように、少し先回りして検証して、これ使えるよとか、使う場合これこういうふうに使うといいよってちょっとハンズオンも含めてやるっていうのも動きとしてあると思うんですけど。
はい。
また新しくこう導入し始めたものとかっていうのもありますか?
うーん、そうですね。
Androidに関しては結構なんかトレンドというのにすごい意識はしてるので。
コトリのこうルーチンとかもそうですし。
あとDIですね。
ディペンデンシーインセクションとかいろいろありますし。
うん。
あとAndroidアーキテクチャーコンポーネントとかっていう。
うん。
コンテナライブラリーとかっていうのは、もちろん個人的には最初に自分で手元で触って、触った上で入れてるんですけども。
うん。
はい。
これはどの商用のプロダクトで導入するタイミングっていうのはどういうふうに見極めたりしてるんですか?
えっとですね、世間的に勘ですね。
世間的に。
使われそうかな。
使われそうかなっていう、そろそろ。
いけそうかなっていうのは。
うん。
タイミング結構大事ですよね。
大事なのと。
うん。
結構見切って。
何ですかね。
結構もう見切って。
うん。
見切り発車ね。
見切り発車。
早いかもしれない。
まあまあ。
大事ですね。
でもそれをやっていけるっていうのは。
はい。
あとは何だろう。
イメミのエンジニアもそれ、新しいのを持ってきた人が多いから。
そうですね。
うん。
結構何ですかね。
うん。
セクリートチームからこうなんか、お願いするとかって。
うん。
プロジェクトのメンバーが先に入れちゃうみたいな。
うん。
ああ、そういうのもあったんですね。
はい。
いいですね、その動きは。
なので、よっぽどひどければ、それはなんか止めるんですけど、あんまりそういうこともないので。
うん。
はい。
なるほど。
はい。で、そこで僕もなんか、こっちもそれを学んだ上で、別のプロジェクトで展開したりとか。
そうですよね。
そういう全体見るテクニックは、あ、これいいじゃんっていうのを拾い上げて、みんなにね、普及させていく。
15:01
はい。
あるいは、委員会でこれを標準にしましょうって、上げていくのはいい動きですね。
そうですね。なんで、半々ぐらいですかね。
うん。
こっちで調べて、みんなとキャッチアップすると。
なるほど。
あと、まあこの1年半で、結構イメミのメンバーもかなりアウトプットするみたいなところの行動量って、相当上がったと思うんですけども。
はい。
クッサンが入った1年半前、実はまあそこまで今ほど活発じゃなくて、まあなんかこうイメミのメンバーって、割とこう内向きというかね、外にあんまり出ないよねとか、勉強会とかっていうのをまあ言ってたぐらいだったんですけども、最近はもうすごい勢いで外に出たり。
そうですね。
まあ勉強会も自社で開催してるので、なんかようやく時代がクッサンに応じてたなという感じですか。
いやー。
まあ僕もやってたわけじゃないですけど、そこまで。
まあアウトプットはもう習慣化してますもんね。
そうですね、たまに。
うん。
なんか半年に1回ぐらいは外で。
ああ、大きなアウトプット。
うん。
ドロイド会議とか。
ドロイド会議とか。
採択されれば。
東京周辺、あの辺の勉強会が多いので。
うん、ありますよね。
半年に1回ぐらいって決めてるんですよ、自分は。
うん。
で、そこに向けて、なんか新しい活躍やって、そこでアウトプットしてっていう、いいライフサイクルですね。
はい。
あと発表が、まあ元々苦手だったっていう。
ああ。
なんですかね。
へえ。
じゃあ自分に勉強する。
練習する。
練習するために。
まあ確かに、なんかあの、ドロイド会議以前の時も、なんかとりあえずこうテーマ決めて、ぶん投げて、自分もよく知らないけど。
採択されたら勉強するぐらいの。
知らないこと、知ってることやってもないじゃん。
まあそうですよね。
使い回しみたいなね。
そうなんですよ。
ちょっと背伸びするぐらい。
なるほど。
じゃないと。
ああ、いいですね。
コツベーションがわからないですね。
結構シニアになっていくにしたがって、そういうのってね、おっくうになっちゃいがちですけど、そういう姿勢はすごいいいなと思いますね。
逆になんかこう、まあ結構、アンドロイド、耳のアンドロイドエンジニア、いろんな人いますけども、クスさんから見て、なんかこういうタイプの人が多いなとか、なんかあります?そういう特徴とか。
比較的、他のグループに比べたらあまりそんなに、なんだろうな、ガツガツしてる。
ああ、そうですね。俺が俺がみたいな。
そんな人はいないね。
iOSグループと違いますね。
結構、落ち着いた人が。
落ち着いた人。
うん。僕もそう思いますね。
多いんですけど、やっぱりみんな優秀だなとは思いますね。着実にこう、力をつけてるなっていうふうに思いますけどね。
なんか、もう物静かなけど、すごい明晰なね、思考してる人も結構多いし、なんかお願いしたらすごい、心よく引き受けてくれたり。
そうですね。
割とね、そういう人、実直な人もいいですよね。
あと、僕が、なんだろう、外で発表できるようになったのも、30超えてからだと思うんで。
18:00
ああ、そっかそっか。
なんかね、あまり自分でやってもなかったことを、あまり。
うん。俺はどやーみたいな感じでね。
あれだと思うので、なんか本人が、みんながなんか外でやりたいっていうふうに、どういうことが重要かなと思って。
そうですね。
あまりなんか、そういうのを押し付けたりは。
うん。
してない感じですね。
そうですね。でもなんかこう、外で勉強会っていうよりは、今、社内のライトニングトークとかもね。
そうですね。
社内的に今、ライトニングトーク、勉強会、アンドロイドグループでもやってるんですけども、その流れがまあ、自然に広がっていって、外の人も呼んでっていう感じでね。
そうですね。
MMAPKとか、なんかそういうので、勉強会も開催できればなとは、今年は思ってますね。
そうですね。昔と違ってなんか、なんだろう、社内でもいろいろやってるんで。
うん。
はい。それでもいいですね。
あとは、逆にこう、なんていうんですかね。こう、もうちょっと新しい動きとして、コトリンっていうところの広がりとして、サーバーサイドコトリンっていうね。
はい。
ネイティブではないですけども、サーバーサイドコトリンっていうところの取り組みも行ったり、なんかそういう動きも進む中で、一部のね、アンドロイドエンジニアの人。
はい。
サーバーサイドコトリンやったり。
そうですね。
まぁ、少しちょっと離れてはいますけれども、親和性があるって意味で言うと、フラッターだとというか。
はい。
そこも耳の中で今取り組んでる中で、ほとんどアンドロイドエンジニアの人がフラッターに興味持って。
そうですね。
クロスプラットフォーム開発やろうっていうところの機運もあったりとか。
はい。
結構貪欲だなと思いましたね。
うん。アンドロイドが嫌なんです。
アンドロイドが嫌だ。
結構やっぱ、アンドロイドエンジニア、いろいろやりたがりますよね。
いやいや、すごく結局、アンドロイドはまだまだね、こう、なんかもっと広がるし、基盤、コトリン。
うん。
なんか、別にキャリアとして不安っていうっていうよりは、なんか技術的に興味あるから、みんななんかね、新しいなっていうのかな。
まぁでも、サーバーサイドでも芸能会社っていうのもあるし、みんなコトリンがだいぶ気に入ってるっていうのが。
気に入ってるっていうのがあるんですかね。
はい。
コトリンの可能性っていうところで。
あとやっぱりアンドロイドエンジニアだと、iOS。
うん。
そんなにできないので。
うん。
やっぱりマルチプラッタとかっていうのは、興味持つんでしょうね。
うん。
あの、自分でできないので。
うん。
なるほど。
うん。
そういう動きもあって、いいなと思いましたね。
はい。
まぁ、動力で。
うん。
あとはあれですかね、こう、技術的不採とか、まぁそういう部分の解消、あるいはリファクトリングとか、そういう部分への取り組みっていうところに関しては、どうですかね。
うん。
なんか継続的にできてるっていうわけじゃないんですよね。
うん。
やっぱりあの、クライアントワークっていうのもあるので。
うん。
まぁ、勝手に大きく変えて、こう、不具合出すのもできないので。
そうですね。
まぁ、ちゃんと回帰テストもね、必要になっちゃいますからね。
ただ、できるとしたら、なんか大きなタイミングで。
開発のタイミング。
開発のタイミングでやるっていう感じですよね。
はい。
21:00
この辺は何だろう。
まぁ、対戦もあるし。
うん。
あの、iOSグループだと、あの、テストがかけてね。
うん。
あの、iOSグループだと、テストがかけてない部分のプロジェクトもあったので、あの、耳
まだ一部
今動いてるのはそんなにはないですよね
じゃあちょっとずつこう変えていくみたいな
よくしていく
リファクタリングしていくみたいな感じなんですかね
ただテストがそこまでいっぱいかけてるわけじゃないので
これ今後やっていきたいなとは思いますので
テストを書くっていうのは習慣づいてる感じですか
いや人それぞれ
まずテストを書ける構造になってないっていうのがあるので
その辺は今後なんか支援しながら
テストコードを増やしていきたいなって
ちょっと過去のね
長く続くプロダクトが多いので
イメミの場合って
一部だとイメミが設計してないコードベースを引き継いで
他社さんが引き継いでるものもあったりするので
ちょっと苦労してる部分もあるんですけども
方向性としては
どんどんリファクタリングしていって
テストも入れて
そうですね
って感じですよね
今日は逆になんかここがまだできてないなっていうところ
まあそういう委員会でもそうですし
テクニックチームでもいいですし
現場のメンバーとかプロダクト見てて
ここがちょっと今後のチャンスだなというか
伸ばしていけるポイントだなとか
あったりしますか
まだですねデザインチームとあまり
個々のメンバーでは繋がりがあるんですけども
まあグループとしてちゃんと連携できていなかったり
あと素材のやり取りとかっていうのも
ちゃんと統一していないので
あとはなんか先進的なUIとかUXっていうのも
確かに
そういうの取り組めてないので
その辺の連携がまずできたんだねっていうのと
イメミの場合
その大きな隔たりっていうところはないし
まあプロジェクト単位だとやり取りはしているものの
やっぱりそのUXUIデザイナーの人が
例えばiOSとAndroidのヘーマーインターフェースガイドラインの
違いを意識して
お客さんとかプランナーが決める
例えばヘーマーインターフェースガイドラインっていうか
インターフェースがiOSと同じにしてみたいな形の要望で
なんかこうAndroid側が
その実装の容易性っていう感じで
それっていうのもなんかよくある話じゃないですか
だからそのコミュニケーションが悪いというよりは
そもそもの理解レベルとして統一したりとか
24:03
さっき言ったようにその素材とか
そのデータの受け渡しの方法っていうところも
決めてやらないとなんか手戻りとかね
発生するから
そのあたりなんか見てて
これ課題だなと思ったのってありました?
いやそこまではないんですけど
もっとよくできるんじゃないかってところですかね
もっと法律化できそうな感じがしますよね
マテリアルデザインちゃんと理解しろよみたいな
まあでもお互いちょっと
うん
取り組みは悪くないですよね
確かにね両方大事ですよねそこは
今少しデザイングループの人が
ああいうAndroid以外も入ってきたりとか
そういう動きはある
そうですよね
大体なので
なるほど
ただ取り組みはできつつあるんですけど
まあこれから
これからっていう感じですかね
先進的なUX UIっていうところって
Androidでもなんかそういうところって
ありますね
あるんですかやっぱり
やっぱり新しいマテリアルデザインの
あとジェスチャーとかもありますし
マテリアルデザインも更新されてますし
そこじゃあアップデートしていくってことですね
どうぞどうぞ
その割とこうモーションデザインとか動きがあるような
心地よさとかそういうのを追求したそうなAndroid Engineでもいます?
そうですねまあいると思いますね
なんかこうゲーム
元々やりたくて
そういうところの動きもこだわりたいって人もいたりしますよね
Androidでも
やっていってほしいなとは思いますけどね
なるほど
それ以外になんかこうこういうところもっと
ゲームのAndroidグループとして
あとはやっぱり先ほど言ったようにテストコードがあまり
テスト
それを増やしていかないといけないっていうのと
あと部品化とかライブラリ化っていったら回っていけないっていうのがあって
そうですよねあと部品化とかライブラリ化っていったら回っていけないっていうのがあって
アンドロイドだと客的にできやすいですよね?
いや、なんかね、結構汎用的なライブラリ作るのは難しいんですよ
結構ビューというか、見た目に関するライブラリを作ったとしても
お客さんごとに違うので、結構使い回しが難しいっていうのと
あとビューっていうか、見た目以外のライブラリって
結構定番のライブラリがあるんですね、すでに
なので、あまり社内で共通化して作るっていうのは難しいですよね
なんかMock Server作るとこはそういう動きがあるんですけど
そういう周辺の環境とか、そういうのを統一したり用意していくといいけども
ライブラリっていう単位で見たときに
確かに
27:00
逆にそれが不採になっちゃったりもありがち
今は手順を統一化してるだけで、コードはその影響をつかしてるわけですよね
UIテストとかはどうですか?
まだですね、一部の案件はできないんですけど、今後増やしていきたい
そうですね
定番的なアプリも、今ニュースアプリとかいくつかあるじゃないですか?
うん
ああいうところで、かつ割とクリティカルなアプリはアプリで多くの人が使われてるっていうときに
基本的なUI部分のテスト、大きくUI変わらないんで
そうですね
多分ミスケのアプリとか、ベーシックのアプリって
そういうのは良さそうですよね、やると
そうですね、正常フローだけで
あとアナログバイアのSDKのレベルでちょっとハマったりするので
なんですよね、その辺も各APKのレベルでこう正常フローを通してというテストぐらいはちゃんとしたいですね
いわゆるパフォーマンス例えば起動速度とか всемのルルル感とかそういうところも、安蔵zykaってどうなんですか?要求されたりするんですかね?
そこまで、あんまりないんですか?
ビブレースフラップルだとそんなに
そこまで?
求められた noisesかないかも、特にね
かもしれないですけど アンドロイドはどうなんですかねその難しさってどういうところにあるんですか
アンドロイドアプリの開発って うーんやっぱりですね
ライフサイクルというか
ちょっと難しいんですよ
アンドロイドSDKの方というか
何ですかね画面が生きてたり死んでたり 状態があったりというのがあるので
なんかその辺を意識しないとして行動を 言っていけないんですけど
色々な状態があって 頭がこうパンクゾーンになるんですよね
その辺が難しいと思う あとはやっぱり
変化が激しいですよね Googleの方は 割と激しいですよね
変化が激しいですよね Googleの方は 割と激しいですよね Googleの方は 割と激しいですよね
変化が激しいですよね Googleの方は 割と激しいですよね
この辺もついていかないといけないという ここですからね
そうですね
組織的にはそういう これを手分けして調べて検証して
実案件に入れていくというところを もしかしたら手分けして
入っていかないといけない AWSとかはまさにそうなってるじゃないですか
アンドロイドとか各技術スタッフが そうなり始めてるなと思ってるんで
要するに 激しいですよ
この辺もそうですね 手分けしてやっていかないといけないんです
30:02
ちなみに ドロイド会議の2020プラチナスポンサーやってますけども
割とそこの公式アプリって 新しいのを挑戦的に
美術に取り入れてやってるみたいなところで ありましたよね
僕も見てます
ちょっとブルーリークもやったりしたり したり
うちのメンバーも勉強会に行ったりするんですよ あっやってるってことについてはね
見ながら 行ったりしてましたけども
いいですよね 取りました
そういう中でまぁなんだろう 今後
なんだろうアンドロイド 委員会こういうアンドロイドグループ全体
なぁ
やっていく中でどういう人が足りないというか こういう人がいるとさらに何か違った変化がありそうだかなーって思うがあります
やっぱりあの
他の委員会に比べてこう 勉強会とか
外にね出していくのが 確実
指摘するとかが多いのに この辺をなんか
指導してくれそうですよね みんなものすごい実力あるけどなんかこう
どやーっていうのはね 謙虚だから
いろいろ持ってるんですけどねノウハウとか まあそのあたりはねあの
いろんな新しい人が入ってくる中で その組織的な活動は じゃあぜひ強化していきたいなと思いますね確かに
カラーでもあるなぁと思います 性格が現れるなぁと同じネイティブアプリ エンジニアでもiOSとアンドロイドやっぱり違う
それを選ぶ理由ってあるんだなっていう そうなんですかね 全然僕からするともう違う人だなと思うぐらい
面白いなぁと思いますね iOSはAppleの思想とかAppleのそういう考えに乗っかって
どうすごいみたいな感じでやっぱり すごいでしょって言ってもらう
ところに喜びを感じる人が多いんですけど Androidとか
やってる人たちは何でもできますけど どうぞなんて言ってくだされば何でもやりますよみたいな感じですごく
割と全然違うなぁっていう
今後いろんな広がりがあるのでKotlinbaseもそうですし まだまだAndroidも進化していきますし
耳のAndroidグループも今後もいろんな課題が いい意味でのチャレンジっていうところは継続して
やっていく
そういう一つの結構体制はできてきた感じですね そうですね
26名もいてそんな連携してやってるのってないですよね本当に意外に大きな
サービスのアプリやってる チームねあのスタートアップとか見ても
33:05
スタートアップって結構大きなベンチャー見ても何か数人しかいないってよくありますもんね
そうですね全然
たった3人なんかそういうのも結構きますね有名なアプリでも
まあもちろんその人数が多ければいいというわけではないんですけどもいろんな プロダクトをね関われたりいろんな人と関われたり
さっきのように組織的にいろんな新しいことを取り入れてやっていくっていう意味では 比較的いい環境がね
できてきたなぁと思っているん いやーとは本当に1年半でだいぶね変わっていたなぁと思うのでまた今後もっと楽しみ
はしてるんですけどねどういうふうに 伸ばっていくか
プスさん自体はその今Androidに専念してやってもらっていると思うんですけど 技術的には他のも何か興味あったりするんですかやっぱりやっぱりあれですね
アプリのサーバー側ですね あの辺やりたいなーってちょっと思っているなと思っている
何ですかね 僕は区切りをつけて
半分くらいはサーバー側にやりたいなと思っています
そうそうそう油断ですけどAndroidテックリードチームって割とこう 3人今いてそれぞれ結構いろんな技術スタッフやってますもんね
柳瀬さんとか サーバーサイドもやってるしフロントエンドもやってるし
大坂さんもなんか普通に以前まではサーバーサイドでちょっとヘルプ的に入ってもらってバリバリやってもらってたりとか
そうですねやってましたね
だからその幅広い視点みんなテックリード持ってるのであんまりこうAndroidの技術に関する部分だけじゃなくて開発プロセスとか
なんかその仕事の手順であったりとかそういうところも含めてなんかこう なんかメンタリングっていうかこういう考え方で仕事をするんだよっていうところも含めて
みんな親切になんか
なんか教えてるなーって印象ちょっとありましたけどね
テックリードチームはやっぱり年齢層が経験が長いっていうのもやっぱりあるんでみんなサーバーサイド変えてますよね
だから結構なんか理想的だなぁと思っていやそのAndroidだけこういうライブラリ使っとるよとかこういう書き方した方がいいよだけじゃなくて
なんかコミュニケーションするときはねこういう風にのこと気をつけてやりましょうとかねなんかいろんなことまで
まあ支援サポートするって意味ではいいなあと思うんですけど
僕あんまりできないです
ヤンセ君とかね
福坂さんとかも
チケットの切り方とか開発サイクル回し方とか
まあそういう意味でもなんかまあテックリードの人自身も単に技術の部分だけずっとね見るだけじゃなくていろんな技術
AndroidだけならAndroidだけじゃなくていろんな技術スタックをね今の構造で
ちょっとだとあのちょこちょこ手出せる
36:01
そうですね
というふうにはあるので
結構あの他のことやってちょっとまた新しいシステムでAndroid見れるっていうのがあると思うので
ヤンセ君うまいことやってるなあと思いますねAndroidの部分を維持しながらもなんかサーバーサイト行ったりフロントエンド行ったりあちこち
そうですね
やってるんで面白い動き方かなあと思う
っていうところでまあいろんな形でこう今まで
実際入ってもらってから大きく変わったAndroidグループなんですけどまた引き続きに今後も新たな展開をできてぜひ期待してますっていうところではい以上となります
はいありがとうございました
