パルカワ2

PerlとRubyとイチャラブ

ひさいちとの1 on 1 という話をした

hisaichi5518.hatenablog.jp

上記で書いたとおり、CTLとしての振る舞いを改めた。その一環として1 on 1もエンジニアとして成長するためにやることにしたので、スライドに気持ちを認めチームメンバーに共有しましたので、インターネットにも共有します。

最後のFAQにも書いてますが、これは僕が全部考えたわけではなく様々な書籍を参考にしました。

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

10分の面談で部下を伸ばす法

10分の面談で部下を伸ばす法

土日

最近、iOSアプリやってる。やってると言っても機能開発とかはしてない。Jenkinsやめるために調べたり動かしたり申請したりしてる。
テストを動かすためにやってるけど、1ビルド20分とかかかる。1回実行すると20分間待たないといけない。やれやれと思ってたら、Swiftだとビルドが遅いとiOSエンジニアから聞いた。



まあ、Swift以外にも遅い原因はありそうだけど、Swiftの勉強がてらコンパイル時間測ってどの部分が遅いのかどうしたら早くなるのか調べて記録というのを土日にしていた。(ただし実行時間自体はそんなに変わらんだろうと思って考慮していない)

今後のやっていきを事業部の人たちに共有した

社内のGHEに書きましたが、公開しても問題ないので公開します。naoyaさんのこの記事に感銘を受けて、自分の行動をふりかえりました。

伊藤直也氏が語る、マネジメントで本当に大事なのは「問題にフォーカスする」である理由|CodeIQ MAGAZINE

実際にどのように振る舞うのか知るには、一緒に働くのが手っ取り早いと思うので、よろしくお願いします。


このイシューでは、ひさいちがCTLとしてなにをやってきたのかふりかえり、今後どう動いていくのかを書いていきます。同じくCTLのごっちゃんや他事業部のCTLがこれに沿うわけではありません。

🏅 結論 🏅

ひさいちのCTLとしての振る舞いの1つである「プロダクトチーム(主にPO, モバイルチーム)の課題を発見し解決を促すことで事業部の成長を加速させる」を「モバイルチームに関する大きな技術的な課題を発見・解決する事で、事業部の成長を加速させる」に変えます。

🤔 CTLとは 🤔

定義:部門方針・目標に基づき、部門全体の技術選択および技術者組織について方針を決定し、実行する。

💭 ひさいちのこれまでのCTLの捉え方 💭

プロダクトチーム(主にPO, モバイルチーム)の課題を発見し解決を促すことで事業部の成長を加速させる。

また、事業部のモバイルアプリエンジニアの成長・採用・評価などにも関わり、手助けしていく。

💪 ひさいちのこれまでの主なアクション 💪

一例です。

  • 関われているのはプロダクトチームのみ
  • エンジニアの評価と目標設定サポート
  • エンジニアのキャリア形成の手助け
  • ペパカレ(研修)
  • 各エンジニアとの 1 on 1
  • モバイルアプリエンジニアの方向性の決定
  • モバイルアプリチームにおけるプロダクトファシリテーション(かんばん、ふりかえりなど)
  • モバイルアプリリリースの進捗の把握と共有
  • Androidアプリコードレビュー
  • QAの人とのやり取り
  • チームメンバーへの共有
  • 採用や評価などの技術者組織に関すること

開発に関することは、自分がやるとスケールしないと考え、あえてチームメンバーにお任せしてきた。あと誰でも出来るようなタスクを引き受けがちであった。

🤔 CTLとしての課題 🤔

  • モバイルアプリのみに対象を絞っているので、他チームとの関わりが薄い
    • しかし、ごっちゃん + Webチームが事業部のハブになる方針であるので大きな課題と捉えていない
  • プロダクトチームがやるべきところまで、首を突っ込んでいる
    • モバイルアプリにおけるプロダクトファシリテーション
    • モバイルアプリリリースの進捗の把握と共有
  • 誰でも出来るようなタスクが多く、技術的な課題へのコミットが間接的である

スクラムマスターっぽい動きが多く、CTLとして本質的な(技術的な)課題を発見・解決が出来ていないのでは?

💭 今後のひさいちのCTLの捉え方 💭

モバイルチームに関する大きな技術的な課題を発見・解決する事で、事業部の成長を加速させる。

また、事業部のモバイルアプリエンジニアの成長・採用・評価などにも関わり、手助けしていく。

🕵 変更ポイント 🕵

  • まだモバイルチームに絞る
    • ごっちゃんやWebチームとやることが被っても意味がないし、コードが別れた2プラットフォームあるので広げても中途半端になる
  • 技術的な課題解決にフォーカスする
    • チームのことはチームに任せる(スクラムマスターっぽいことはしません)

💪 実際に行っていくアクション 💪

一例です。

  • プロダクトチームのことはプロダクトチームに任せます
    • リリース, QAのフローに大きく関わるのをやめます
  • モバイルチームに関する大きな技術的な課題を発見・解決します
  • Androidに関することをやる時期・iOSに関することをやる時期と分けます
    • 6月からはiOSアプリのコードを理解し、課題の発見を行います
    • そのあと具体的に課題の解決に向けて動きます
    • Androidアプリにおいては、リード制度を設けてあるので、まずはチームメンバーに任せます
      • もちろん、今まで通り相談には乗ります
  • モバイルアプリエンジニアの成長に関すること
    • エンジニアの評価と目標設定サポート
    • エンジニアのキャリア形成の手助け
    • 各エンジニアとの 1 on 1
      • 今チームのなかで困っている事にフォーカスするのではなく、1 on 1する人がエンジニアとして成長することにフォーカスします
    • ペパカレ(研修)
      • 次やるときも、大きく時間をとってやる可能性が高いです
  • モバイルアプリエンジニアの方向性の決定
  • 採用や評価など技術者組織に関すること

❓ ありそうなFAQ ❓

  • すべて同時にやるの?
    • いいえ
    • すべて同時に出来ないと考えています。例えば、ペパカレと大きな技術的な課題の発見と解決は同時進行すると両方とも関わりが中途半端になってしまう。
    • なので、どれかをやる時期・やらない時期があります。
  • 具体的にどういうことをやっていくのか?
    • #6417 (見せられないよ)こういうことをやっていきます
    • iOS は Jenkins で疲弊してる感じがあるので、そのあたりかな?とあたりは付けていますが、それ以外をやる可能性はあります

AppCodeでテストが通らなかった

Xcodeでテストが通るようにはなったがAppCodeで通らない。エラーログがなにも表示されないので困った。
よく見るとテスト実行時、実機を選択していたので、シミュレータを選択したら動いた。そういうものなの?🤔
それ以外だとOSのバージョンが関係しているかもしれないと思ってシミュレータ増やして確かめてみたけど、そうでもないようだった。

一方、XcodeはProcessing symbol filesで固まっている…。
(実機ビルドをするとそうなるからシミュレータを使いましょうという話になりました)

Carthageのbootstrapで固まってた

ログも出ないし、bootstrapを実行すると一向に終わらない。
bootstrapしても固まらないチームメンバーとCarthageのバージョンを合わせたりしてたけど、一向に終わらなくてなんでだろう?ってなってた。ふとCartfile見るとgitが使われていて、git cloneするときにssh認証するときのパスフレーズを求められていたことに気づいて\(^o^)/\(^o^)/

ユーザーと開発者の両方をしあわせにすることを目指す「しあわせ推進委員会」

  • アプリの信頼性を高める(ユーザーのしあわせ)
  • 開発の高速化(開発者のしあわせ)

を目指す「しあわせ推進委員会」をiOSチームメンバーでつくった。
AndroidチームはすでにMVPアーキテクチャを導入したりそういう地盤が出来ているので、別の取り組みをやり始めた。なのでAndroidチームでしあわせ推進委員会を作るというのはしていない。

例によって、委員会メンバーには簡単にお話したので、それの資料です。

当初アーキテクチャ変更だけによせようと思ってたんだけど、委員会メンバーと問題意識の共有をしたらアーキテクチャ以外のこともやる必要あるねってなったのでアーキテクチャ変更を軸にそれ以外もやります。

またスライドにある通り、やったこと・話したことは記録を取っていて、従業員であれば全員読めるので、詳細を知りたい同じ会社の人はGithub Enterpriseでしあわせ推進委員会で検索して出てきたイシューを見るといいです。まだ従業員でない人は、今すぐ以下から応募してください。

【minne】iOSアプリエンジニア / GMOペパボ株式会社