パルカワ2

最近はFlutterをやっています

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

社内の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ペパボ株式会社

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン を読んだ

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

1部の第2章まで読んだあとに3部48パターンにざっくり目を通して、1部の第3章から第12章まで読んだ。2部の事例紹介は読んでない。
僕は組織に対して「こういうことやりたい」という人間であるのだけど、まだチーム内だとかで範囲が狭いので会社全体に適応させるのと比べるとある程度やりやすい。ただ範囲が狭い状態でも起きうることや非常に大事なことが書かれているので、大小問わず組織に対して「こういうことをやりたい」というのを言いたいと思ってる人は読むといいと思った。

リアルかんばんやめたいという話をチームにした


話をしたというかモバイルチームメンバーにスライドを共有しただけです。

リアルかんばんをやめたいとは言いましたが、リアルかんばんの良いところである「かんばんの前で話しやすい」というのは捨てられないとiOSメンバーの1人から聞こえてきたので、事業部のiPad Proを使ってTrelloを表示してます。こんな感じ。立って見るとちょっと低めなのでもうちょい高めにしたいところ。
f:id:hisaichi5518:20170323193616j:plain

あと見積もりも時間でやってたんですが、相対見積もりをするようにしました。

スプリント計画で出てきたタスクをざっくり「S」「M」「L」に分けて、Mで一番タスク内容が想像しやすいものを3ポイントとし、この3ポイントのタスクと比べて他のタスクは「1, 2, 3, 5, 8, 13」の中ではどのポイントか?と見積もっていきました。