Swiftの勉強がてらSwiftのコンパイル時間を図って記録するというのをやってたんですが、合ってるのかもよくわからないので公開しました。(ベンチマークって難しいよね……)
ひさいちとの1 on 1 という話をした
上記で書いたとおり、CTLとしての振る舞いを改めた。その一環として1 on 1もエンジニアとして成長するためにやることにしたので、スライドに気持ちを認めチームメンバーに共有しましたので、インターネットにも共有します。
最後のFAQにも書いてますが、これは僕が全部考えたわけではなく様々な書籍を参考にしました。
ヤフーの1on1―――部下を成長させるコミュニケーションの技法
- 作者: 本間浩輔
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/03/25
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)
- 作者: 中原淳
- 出版社/メーカー: PHP研究所
- 発売日: 2017/02/18
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 山根孝一
- 出版社/メーカー: アニモ出版
- 発売日: 2013/08/08
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
土日
最近、iOSアプリやってる。やってると言っても機能開発とかはしてない。Jenkinsやめるために調べたり動かしたり申請したりしてる。
テストを動かすためにやってるけど、1ビルド20分とかかかる。1回実行すると20分間待たないといけない。やれやれと思ってたら、Swiftだとビルドが遅いとiOSエンジニアから聞いた。
Swiftのビルド高速化について調べてたら、型推論させない・三項演算子をやめるなど書かれていて楽に生きることの難しさを学ぶこととなった。
— ひさいち (@hisaichi5518) 2017年6月10日
こういうのSwiftのバージョンが上がるたび変わるだろうし考えながら書くのも大変だなと思ったけど、Perlの時は実行時間も鑑みてどっちで書くかみたいなの考えてた気もする。
— ひさいち (@hisaichi5518) 2017年6月10日
2017年にビルド時間を考慮してプログラム書かなきゃいけないの嫌すぎるのでエンジニア全員に最強のマシンを買うしかない
— ひさいち (@hisaichi5518) 2017年6月10日
まあ、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に関することをやる時期と分けます
- モバイルアプリエンジニアの成長に関すること
- エンジニアの評価と目標設定サポート
- エンジニアのキャリア形成の手助け
- 各エンジニアとの 1 on 1
- 今チームのなかで困っている事にフォーカスするのではなく、1 on 1する人がエンジニアとして成長することにフォーカスします
- ペパカレ(研修)
- 次やるときも、大きく時間をとってやる可能性が高いです
- モバイルアプリエンジニアの方向性の決定
- 採用や評価など技術者組織に関すること
❓ ありそうなFAQ ❓
- すべて同時にやるの?
- いいえ
- すべて同時に出来ないと考えています。例えば、ペパカレと大きな技術的な課題の発見と解決は同時進行すると両方とも関わりが中途半端になってしまう。
- なので、どれかをやる時期・やらない時期があります。
- 具体的にどういうことをやっていくのか?
#6417(見せられないよ)こういうことをやっていきます- iOS は Jenkins で疲弊してる感じがあるので、そのあたりかな?とあたりは付けていますが、それ以外をやる可能性はあります
ユーザーと開発者の両方をしあわせにすることを目指す「しあわせ推進委員会」
- アプリの信頼性を高める(ユーザーのしあわせ)
- 開発の高速化(開発者のしあわせ)
を目指す「しあわせ推進委員会」をiOSチームメンバーでつくった。
AndroidチームはすでにMVPアーキテクチャを導入したりそういう地盤が出来ているので、別の取り組みをやり始めた。なのでAndroidチームでしあわせ推進委員会を作るというのはしていない。
例によって、委員会メンバーには簡単にお話したので、それの資料です。
当初アーキテクチャ変更だけによせようと思ってたんだけど、委員会メンバーと問題意識の共有をしたらアーキテクチャ以外のこともやる必要あるねってなったのでアーキテクチャ変更を軸にそれ以外もやります。
またスライドにある通り、やったこと・話したことは記録を取っていて、従業員であれば全員読めるので、詳細を知りたい同じ会社の人はGithub Enterpriseでしあわせ推進委員会で検索して出てきたイシューを見るといいです。まだ従業員でない人は、今すぐ以下から応募してください。