00:05
おはようございます、Rayです。本日もRay Wow FMの時間がやってまいりました。
Ray Wow FMでは、主に株式会社耳に関する様々なテーマを扱って、時にはゲストもお招きしながら、ゆるくやっていくラジオとなっております。
よろしくお願いします。
今日は、福岡本社で今勤務している、テックリードの志さんをゲストとしてお招きしております。
よろしくお願いします。
よろしくお願いします。
今日はですね、iOSのグループ、いめみにはいろんな技術的な職能のグループがあるんですけれども、その中のiOSグループですね。
今、iOSエンジニアが26名くらいかな、もういるんですかね。
30名弱いる中で、どういう風な形で仕事をしているかみたいなところの、
話をした上で、志さんが所属しているテックリードチームですね、そこのチームの取り組み状況とか、
いめみのSwiftに対する取り組みとか、その辺りを聞ければなと思っているんですけれども、
最初にまずちょっと僕の方から、iOSグループの話をしたいと思うんですけれども、
うちのいめみの場合はですね、およそ20とか、そういう、多くの、
はい。
アプリを20何人みたいな形のエンジニアが携わっているんですけれども、
普通の会社だと、プロジェクトごと、プロダクトごとに担当のiOSエンジニアが割り当てられて、
比較的その一つのプロダクトとか、プロジェクトをずっと携わるみたいな形の、
プロジェクト性、プロダクト性っていうところの軸が結構強いと思うんですけれども、
場合は結構職能の軸として、iOSなら、
iOSエンジニアグループっていうのがあって、
グループは5人から7人のチームに分かれているので、
大体その5名、5、6チーム、iOSグループにはチームが分かれているんですけれども、
そのチームごとに、その複数のプロジェクト、プロダクトを担当していて、
チームでみんなでいろんなプロダクトを作るようにしましょうっていうところがあるので、
いわゆる一人が一つのプロジェクトとかプロダクトにロックインされないで、
いろんなプロジェクト、プロダクトをタブサーレジェンスしようっていう、
そういう実は構造がありますと。
で、その中でもTech LeadチームっていうのはそのiOSチームの一つのチームで、
いわゆる他のチームを広報支援、側面支援するみたいな形で、
実際には設計デビューとかコードデビューとかハンズオンしたりとか、
03:02
本当に困ってる状況であれば、
直接そのプロジェクトのメンバーとして支援するみたいなことを、
行っている、そういうTech Leadの集まりなんですけれども、
こういう構造にしてやっぱり良かった点としては、
チーム間でサポートし合えるっていう、
そういう支援関係が作れたっていうことと、
やっぱりそのリードエンジニアがどうしても頑張るみたいなところを側面から、
Tech Leadも支援するっていう形で、
技術面であったりとか、
いろんな課題が起きたときにもサポートするっていう意味では、
組織として、
こう連携できるっていうところが、
増えたなとは思うんですけども、
その中でこう、実際、
志さんの方は今福岡に勤務しているので、
リモートっていうところもあると思うんですけども、
その中で、
実際普段どういうふうに、
その他のiOSチームに関わったりとか、
プロジェクトに関わってるかみたいな、
なんかその仕事の仕方みたいなところを、
簡単に教えてもらってもいいですか?
はい。
えーと、そうです。今、
福岡で一番メインな仕事は、
プロジェクトに上がってきているプロジェクトを、
レビューをすることが一番多いですかね。
今、大体3つ、4つぐらいのプロジェクトを、
同時に進行してて、
それらが常にプロジェクトに上がってきているので、
それらがプロジェクトに対して、
なんか技術的なレビューをしたり、
あと、ここをもう少し、書き換え、
書き換えを合わせるよとか、
そういったところを、
そういう指摘をするのが一番多い仕事ですかね。
で、それ以外に多いのは、
そうですね。採用面接の仕事ですかね。
はい。
今、テクリードチームがあるんですけども、
テクリードチームが3人体制で、
今のところ3人体制で、
で、3人交代で、
なるべく1人の応募者に対して、
2人のテクリードが面接に当たっている、と。
で、3人交代で、なるべく1人の応募者に対して、
2人のテクリードが面接に当たっている、と。
で、3人のテクリードが面接に当たっている、と。
で、3人のテクリードが面接に当たっている、と。
そんな仕組みにはなっています。
はい。
はい。
ありがとうございます。
こういうテクリードチームの体制ができたのは、
この、どうですかね。
半年以内ぐらいですかね。
ちゃんとした体制ができたのは。
実際にこう、テクリードチームの体制をして、
側面支援するっていうところが、
ある程度できるようになってきた、
っていう意味では、どうですかね。
以前と比べて。
そうですね。
とりあえず、テクリード同士、
もともとテクリードチームの今の3人のメンバー、
どうやって選出されたかというと、
元々いった、
それぞれのIOSのチームがあって、
で、そのチームの中の比較的に
一番技術力があるとか、
一番面倒見がいい人とを選んで、
テクリードチームを作ってたんで。
06:00
たので、
この三人、
元々それぞれ違うチームに所属していた、
この3人がIOSテクリードチームになっていて、
それぞれ、違うチームに所属していた、
それのおかげで、だいぶチーム横断の連携というか、技術交流というかが、よりはだいぶ活発にはなっているかなという気はしています。
なるほど。テックリードのチームの中で、ここのプロジェクトをこういうやり方をやっているみたいなという感じですかね。
チームメンバーと同じことを共有したりということは、だいぶやりやすくなっているので。
そうですね。この辺りの構造というのは、いわゆるマトリックス型組織において、いわゆるプロジェクト性、スクラムチームとかも含めて、
フィーチャーチームという形で、機能推進とかプロダクト推進という力が強い、そういう状況がほとんどの会社多いと思っていて、
いくらそこに横断したエンジニアリングマネージャーがついて、
あ、いわゆるマトリックス型組織において、プロジェクト性、スクラムチームとかも含めて、フィーチャーチームという形で、
のラインのマネージャーとして
いくら連携取ろうと思っても
なかなかこうね
プロジェクトの人からすると
他のプロジェクトがね
大変って言っても
うちのプロジェクトも大変なんだからみたいな感じでね
絶対人貸してくれない
っていうことがね
これは耳でももう10年
ずっと続いてきたところをようやく
ようやくちょっとくさびを打つことが
できたなと思っていて
そういう意味ではすごく横断した
技術の
技術力の底上げってできてるかなと思ってるんですけど
今日はちょっとね
話だけじゃなくて
全然まだダメだよねみたいな
いい意味でね
課題点問題点ってたくさんあると思うんで
そういう話もできたらなと思うんですけど
最近だと
関西かな関西の方の
プロジェクトの中で
やっぱり
リファクトリング
しないともあるんじゃねえかみたいな形で
社内ちょっと投資というか
持ち出しで
リファクトリングしたプロジェクトが
あったと思うんですけども
そのあたりは結構やっぱり
負の遺産
そこまでは
技術的な
負の遺産というところまでは
負債ではないんですけども
なんかどういうところが課題で
それで資産の方も
そうですね
京都のチームで
今私の方で担当してる
リファクトリングをやっている
プロジェクトとしては
まず構造がだいぶレガシーで
になっていて
それで
いわゆる
密結合になっている箇所が多いですね
それのせいで
結構どっかを
修正したら別の関係なさそうな
ところがなぜか影響を受けて
09:01
バグったとか
皆さんのことがよくあるのと
そもそもテストもなかったんで
そうですね
ただでさえ
影響を受けやすい密結合になっているのに
テストもないから保証も
なかなか難しいという
ある意味テストがないからこそ
こういう密結合になっちゃったっていうのもあるので
今はまずテストをくじ込んで
そのとりあえずテストを作るところまで
とりあえず作って
作ってたところで
次にできるところから
リファクトリングをやっていって
それだいぶ最近は
ちょっとずつ
サマーにはなってきてはいるんですけれど
ただ今後の課題としては
そのプロジェクト自体は
結構継続的にバージョンリリースをしているので
逆に言うと大規模なリファクトリングになると
いきなり本番プロダクトに
適用させられるかというと
ちょっと難しいよねというところなので
なので今はちょっとまあ
あの
昔に言われますね
定期的な新機能追加のリリースと
リファクトリングのブランチが同時に並行させていって
リリースするものがまだ古い
作りのままで
とりあえず新機能追加していって
それがある程度落ち着いてきたら
リファクトリングのやつを適用させて
一から
適用した後に
最初から
細かい
動作テストだとか
もう一回検証した上で
次のリファクトリングした
をリリースという
結構時間をかかる
プロセスを取らざるを得ないというのが
難しいところですかね
確かにね
そうですね
やはり根本的な構造が
変わってしまうので
やはり
回帰テストをちゃんと全部やらないと
エンジニアとしてもやはり不安が
結構強いので
そうですね
それをどのタイミングでやるかみたいな感じで
とりあえず
ちょこちょこある機能が落ち着いて
リファクトリングも
落ち着いて
というタイミングですよね
でも今回そういう技術的な
あれもともと
外部の会社さんでしたっけ
に確か開発をお願いして
確か社内に巻き取ったやつだと思うんですけども
まあいずれにしても
そういうレガシーというか
技術的負債を解消するっていうところに
投資をしていくっていうところができたのは
良かったなと思いますけども
やっぱりとはいえ
12:01
なんていうのかな
そのままになってたりというか
テストもないままで
プロジェクトとしてやっぱり進んでいたので
そこの部分でテストをやるっていうところの
意識というか浸透させたいっていうところが
そうですね
とりあえず
テストを標準化というよりも
とりあえず
何か自分が何か機能でもいいし
何かの修正でもいいしをする前に
まずテストを書くという意識を
社内のiOSエンジニアに追いつきたいな
という気持ちですね
そうですよね
まあある程度
もう浸透はしてきているものの
その過去のコードがテストないから
そのままで
というふうに捉えずに
いやいや
テストがないと
それも根本的に駄目でしょ
テストがないと
レビュアさんとしても
ちょっとこの動きちゃんと正しいですか
っていうのもちょっと分かりにくいところもあるし
さらにぶっちゃけ言うと
3ヶ月後の自分は他人という名言も
我々の業界にはあるので
今この瞬間でこれは正しい動作だって
すごい強い自信を持ててても
3ヶ月経ったら
あれ俺何を考えてこのコードを書いたっけ
っていうことになるので
やはりテストがないとね
そうですね
そういった意味では横断してチーム
今のいめいめのマトリックス組織だと
他のチームが困っていれば
すぐにそこに入って
手伝えるようにするって意味でもいいですよね
分かりました
その他にやっぱまだまだ課題があるので
そうですね
ちょっと技術力の平準化というか
やはりチームメンバーに応じて
やはり技術力それぞれ違うので
そこと底上げすればいいのかとか
の課題がまだ残ってはいます
これに関してはやはり
ペアプロだとかプロだとかを
ちょっと推奨していきたいなという気持ちは
ありますが
今あるにはあるんですけれども
何せ私一人だけ福岡にいるので
リモート環境で
リモート環境でどうやって
ペアプロとも構築すればいいのかというのを
ちょっとこれから模索していかないといけないのが
そうですね
のが一つあるのと
あとやはりですね
立ち寄りの連携がね
まだまだ改善していく余地はあるなという
気持ちはあります
毎週のリソース定例会で
チームによって
すごい忙しいチームと
カードがちょっと空いちゃってるチームが
15:00
毎週毎週出てきちゃうので
完全に
気につかせるのは
やはり難しいなとは
思いますけれども
もう少し改善する余地はあるのかなとは
なるほどね
それは
その
ソースの部分で
さっきの形で平準化するっていうところだけじゃなくて
ソースの部分で標準化するっていうところだけじゃなくて
技術面でのバランスもありますし
かなり難しいというところ
あとやはりプロジェクトごとに
やはり全然使ってる
バックエンドの技術も違ったりするので
エンドポイントがどうなっているかとか
APIどうなっているかとか
そういうの全然プロジェクトによって
全然違ったりするので
やはりいきなり入ったとしても
慣れるまで時間がかかるっていうのが
どうしても発生するから
なのでもし可能でしたら
今後はもうちょっと
チームに所属しておきながら
別チームの案件も
ちょっと触れるような
体制ができたら
もしかするともっといいのかなという
もうちょっと
そうですね
もうちょっとそれができればね
もうちょっと
もうちょっと
なんでしょうな
プロジェクトの促進感も
それをあれですね
さらに解消されるので
多分ね
まだ他のチームを手伝う以前に
自チームの担当してるプロダクトを
そうですね
自チーム内で手伝えるように
そもそも自分のチームのプロダクトを
理解するまでに
ちょっと時間がかかりますよね
入社して
はいはい
まだ割と新しい人も多いですからね
新入社に
2人入ってきましたね
今年
うん
うん
ね
でもなんか
いみみの新しい人を含めて
みんな
なんか学ぶ意欲とか
吸収力はすごい
早いので
そうですね
テクニドとしてはあれですかね
どんどん盗んでいってほしいって感じですか
テクニドチームメンバーも
増やしたいなという気持ちですね
そうですね
確かに増やしたいという
やはりそもそも
そもそも面接の時から
勉強があんまり得意じゃない人
そもそも面接で
多分おそらく10兆枠落ちちゃうので
そうですね
ちょっと厳しいかもしれないですね
でも
そうですね
はい
アイオイスも動き早いですからね
ついていける人じゃないと
はいはい
そういった意味では
いみみスイフトっていうね
定期的に
いみみスイフトの勉強会っていうのも
いみみで開催できていて
そういう意味でも
すごい積極的に
そうですね
いみみスイフトは
18:01
テクニドチームというので
グループ全体
iOS委員会という
委員会主導でやっていますので
委員会ですね
一応説明しておくと
委員会っていうのは
グループ全体の
作戦本部みたいな形で
iOSに関する技術標準を決めたり
投資方針を決めたり
PRを決めたり
PRとか外部向けの採用方法とか
そういういわゆるマネジメントの部分も含めて
融資が集まって
みんなで決めていくっていうね
そうですね
そこでいみみスイフトをやろうと
おかげさまで最近
大体月1ぐらいで
ほぼほぼ定期的にできておりまして
そうですね
うん
すごいね
なかなかiOSって
愛好会でしたっけ
愛好会とかはあるけど
月1の頻度で
会社主導でできてる勉強会は
今のところないかな
コミュニティ主導でしたらありますね
ないかもしれないですね
自分が知ってる限り
会社主導でやってる月1のは
あんまりないかもしれません
iOSでは
うん
ありがとうございます
そういう意味ではすごい
すごいなと思います
あと他の会社主導の
iOS勉強会とちょっと違うところは
発表メンバーもですね
社内メンバーだけじゃなくて
社外のメンバーも発表が可能というのが
そうですね
半分
いいですね
半分半分ぐらいですね
半分が社外メンバーの公募した発表という感じですね
大体の会社主導の発表会ですと
割と社内メンバーだけの発表が多いので
そうですね
そういった意味では
お互い学んでいきましょうっていう
そういう関係ですよね
みんなで
うちの技術をどうですかって発表する場ではないですよね
あとあれですね
iOSグループっていうところで言うと
そうですね
社内のNCGは毎週
ほぼほぼ毎週やってるんですけれども
たまに本当にYouTubeが忙しくて
発表メンバーがいない週もたまにあるので
なるべく週NC会を開けるようにはやっています
あとはあれですね
各種カンファレンスのスポンサードも
そうですね
積極的に去年ぐらいからやってるので
iOSDCとかTrials Listとか
そういうところもね
21:00
スポンサードしてブース作ったりとかっていう意味で
はい
そうですね
外部の最近結構
どんどん出ていってますよね
うん
よく見かけるようになったと
割と周りの友達にも言われてます
なんか露出が上がってますねと
そうですね
本当にいい感じになってきてるなと思いますね
あと技術的にはどうですか
今後のアプリ
Safeという範囲もあるとは思うんですけれども
あとSwiftからだとテストとか
なんかちょっと書籍も出て盛り上がってきてますけど
技術的には今後どういうところを
Safeというのは出てはいるんですけど
まだプロダクトに使えるかどうかで言われると
まだちょっと難しいなという
分かりやすく言うとですね
昔のSwift1.0、2.0の時代みたいな
まだ未完成品ですよね
出たばっかり
つけて追っていくのも大事ですけど
そんなにそこまでSwiftUIにまだ
すごい体力かけてやるべきものかって言われると
そうでもないかなという感じです
もちろん個人でやるの全然問題ないと思うんですけども
とはいえ私も自分の個人プロジェクトで
SwiftUIを使ったりしてるんで
ずっと出す出すだけ言ってた
個人アプリをようやく出せました
ありがとうございます
個人アプリをついに出せましたね
ありがとうございます個人アプリをついに出せましたね
他に
おめでとうございます
他に
すっきりしましたね
追っかけたほうが技術っていうと
やはりテスト回りですね
やはり最終的に
テスト回りとあと
そうですね
技術はやっぱり時代とともに
ずっと移り変わっていくんですけれども
根本的な考え方はそんなに変わらないので
設計が
具体的な設計
設計が
MVCだとかMVVMだとか
Viperだとか
クリアアーキテクチャだとか
最近なんかやたらと
新しいアーキテクチャがどんどん増えてきてるんですけれども
中に根本的にある考え方
素結合だとか
CQSだとか
そういった根本的なところは
やはりあまり変わらないので
そういった根本的なところを
抑えるのが大事かなという
そうですね
どんなアーキテクチャ
ファンシーなアーキテクチャでも
やはり
時代
一時期例えばMVVMが
結構話題になってたんですけれども
最近ちょっとそんなに
そこまで話題性がないというか
いい意味が悪い意味が別として
アーキテクチャがファンシーだから
といって
別にそれがこのプロジェクトが
イケてるかどうかとは
関係ないかなという
それよりも
24:01
このプロジェクトがちゃんと
CQSのままに
持ってるかどうかだとか
テストちゃんと
動作補修してるかどうかだとか
そこら辺やはり大事なので
そうですね
そういった意味では
変わらない部分
そうですね
自分が書いたその本
iOSアプリ設計パターン入門という本
自分が書いた章の内容ではないんですけれども
タカセックさんという
すごい著者の方が書いた章で
アーキテクチャはどう決めればいいか
というところがあったんですね
結局いきなり最適なアーキテクチャが
なかなか決まれないんですね
リクエストというか
お客さんの要望も常に変わってきてるし
いろいろあるので
いきなり最初から最適なアーキテクチャを
決めるのはなかなか難しいし
やっぱりやっていくうちに
全然アーキテクチャが変わっていくので
なので第一なのは
アーキテクチャじゃなくて
補修のしやすさですね
いきなりやっぱりこっちのアーキテクチャが
適してるんじゃねってなった時にも
スパッとそっちのアーキテクチャに
移行できるような
そうですね
やっぱり組織
進化的アーキテクチャみたいな
常に変わってるというか
そうですね
アプリのアーキテクチャも同じようなものが
常に変わってるものなので
じゃあ変わっていくと
でも動作が補償されるように
そうですね
そのアーキテクチャ変わっても
動作が補償できるかどうかというのは
やはりテストでそこを補償しているので
そこ大事かなという感じです
そこはすごい理解してます
まあそういうね
どういうアーキテクチャであっても
そのいわゆる公務員の法則じゃなくて
組織がね
そのアーキテクチャを実行する制約に
ならないように
いったい耳のね
組織アーキテクチャ上はかなり
そういう柔軟な構造には今なっているので
ありがとうございます
思想はすごく分かります
そうですね
まあでもチャレンジングでいいですね
今後の
iOSはでも面白いなと思う
Androidと比べて
やっぱ思想とか設計思想とか
流派がやっぱり
特に2年前1年前あったなと思ってて
まあそこの
部分もどうなんですかね
ちょっとずつ
そうですねみんな結局なんでしょうが
同じような方向に向いてるというか
セーフトUIも
セーフトUI根本的に何かというと
宣言的UIというか
それは結局最初
フロントへのDSMから
それを取り入れて
今iOSもセーフトUIでそれを取り入れて
27:00
やはりみんな向いてる方向性は
同じような方向かなというような
はい
分かりました
では今日はそういう形で
iOSグループも
そうですねよりさらに
まあ進化をしていきながら
ねこう
今年は多分露出な話で
アピールね多分していくと思うんですけども
いろんなね人も
カンファレンスで登壇するみたいな形も
やってもらうといいですよね
はい分かりました
では今日はそういう形で
iOSグループも
iOSグループ上にテックリードの話を
教えていただきました
ありがとうございます
