テックリード(自称)としてのやっていき / Rakus Meetup Tokyo #1 / Yatteiki TechLead

73560128b23de542e47a318145bc781a?s=47 Yu Kawanami
September 13, 2018

テックリード(自称)としてのやっていき / Rakus Meetup Tokyo #1 / Yatteiki TechLead

「Rakus Meetup Tokyo #1 終わらないスクラム」の発表資料 #RakusMeetup
https://rakus.connpass.com/event/97795/
https://twitter.com/hashtag/RakusMeetup

73560128b23de542e47a318145bc781a?s=128

Yu Kawanami

September 13, 2018
Tweet

Transcript

  1. テックリード(自称) としての やっていき Rakus Meetup Tokyo #1 on 2018.09.13 @kawanamiyuu

  2. Tech Blog 書いてます! 自己紹介 ▪ かわなみゆう ▪ @kawanamiyuu ▪ 楽楽精算の開発

    ▪ テックリード ▪ スペシャリスト(SP) ▪ PHP がすき 2 http://tech-blog.rakus.co.jp/
  3. 3 背景

  4. 楽楽精算の iOS アプリ開発(新規) 4 https://itunes.apple.com/jp/app/id1352852886

  5. 開発期間 5 ▪ 1 月から本格的に開発スタート ▪ 会社として初めての iOS アプリ開発 ▪

    エンジニアも全員 Swift 未経験 ▪ 自身の プロジェクト参画が決まったのが 12 月 ▪ 控えめに言って正月休みめっちゃ勉強した 企画、プロトタイピング (〜2017/10) 技術調査 (2017/11〜12) 1st リリース開発 (2018/01〜03)
  6. スクラム 6 ▪ 開発チーム プロダクトオーナー (UI/UX デザイナー兼任) ステークホルダー (事業部(企画、CS、営業)) ス

    ク ラ ム マ ス タ | API サーバ開発 ・ベテラン(SP) ・ベテラン(派遣) ・若手(1 年目 ※当時) iOS アプリ開発 ・自分(SP) ・ベテラン ・若手(2 年目 ※当時) ← 12 月から参画
  7. 開発チームに対して感じていた不安 7 ▪ 全体視点 ▪ 新しい物事に対するリーダーシップ □ 開発プロセス □ アーキテクチャ

    ▪ バランス感 □ 開発速度と品質(UI/UX、コード)
  8. やっていき 8

  9. やっていき 9 ▪ 仕組み化する = 開発インフラを整える ▪ コード品質 = コードレビュー

    ▪ バランスをとる = 情報共有の Hub になる
  10. 仕組み化する 10

  11. アーキテクチャ 11 ▪ DDD(レイヤーアーキテクチャ)風 ▪ iOS アプリ開発のノウハウがないので厳密には頑張らない ▪ どういう責務の単位でクラスを作って、どこに置くか、の認識 を合わせる

    ※参考にした情報は Appendix を参照
  12. 12

  13. メンバーの役割 13 ▪ ノウハウが必要な UI 実装はあえて属人化させることで、開 発スピード、品質を担保した □ 結果的にはビジネスロジックの多くも担当してもらうこと になり負担を掛けてしまった

    ▪ 自身が稼働不足によりボトルネックになることは予想できた ので、極力ボリュームの大きな実装タスクは持たず、レ ビューに徹した
  14. ベテラン 若手 自分 14

  15. 開発規約 15 ▪

  16. Issue テンプレート 16 ▪

  17. Merge Request テンプレート 17 ▪

  18. CI 環境の構築 18 ▪

  19. コード品質 19

  20. コードレビュー 20 ▪ 重視したレビュー観点 □ 命名 □ 責務 ▪ 修正要否の見極め

    □ 今やっつけないと近い将来(1st リリースまで)の障害と なるか □ 不確実性に対して過度な設計、実装でないか
  21. None
  22. バランスをとる 22

  23. 情報共有の Hub になる 23 ▪ 開発チーム全体のデイリースクラム(朝会)後に、iOS チーム 固有の情報(課題・ノウハウなど)の共有 ▪ バックログの消化状況の把握、進め方の調整

    ▪ 技術面および仕様面の負債の把握、管理 ▪ 開発速度と品質のバランスの舵取り □ 不確実性に対してやりすぎない
  24. None
  25. 25

  26. やってみて 26

  27. できたこと、やってよかったこと 27 ▪ 仕組み化することでスキルにばらつきがあるチームでも業務 品質を確保 ▪ 戦略的な属人化で開発スピード、品質を確保 ▪ ちょうどよいコード品質 □

    自分を信じて(戦略的に)レビューしてよかった □ 必要なタイミングで負債を返せた
  28. もっとやりたかったこと、むずかしかっ たこと 28 ▪ 技術面のリード ▪ 技術的な課題、リスクの把握、予見 ▪ リーダシップ(≠ マネジメント)

    ▪ 自分でやらない ▪ 開発を前に進めることと育成のバランス
  29. 所感 29 ▪ スペシャリスト職にとっての「テックリード」というキャリア ▪ リーダーシップむずかしい、でも楽しそう ▪ エンジニアリングももっと頑張りたい ▪ これれからもやっていきたい(やっていく)

  30. “ 30 知識は実践してはじめて価値がある。 Knowledge is of no value unless you

    put it into practice. - Anton Chekhov -
  31. Appendix 31

  32. やっていき 32 ▪ yatteiki.fm □ https://yatteiki.fm ▪ やっていき、のっていき □ https://speakerdeck.com/kentaro/the-secret-of-leade

    rship-and-followership
  33. 良いテックリード、悪いテックリード 33 【現実主義】 良いテックリードは現実主義で、正しい事を行うことと仕事を片付けることのバラン スを心得ている。時には近道を通ろうとするがそれは怠惰だからではない。最低限 必要な仕組みをローンチするために、全体の進捗の妨げになっている問題を回避 したり一時的に棚上げすることをチームに推奨することもある。良いテックリードに とって細部はとても重要である。コードの品質、コードレビュー、そしてテスト。こうし たことを製品を予定通り出荷するのと同じくらい重要だと考える。 http://tannomizuki.hatenablog.com/entry/2018/02/22/180410

  34. Swift(言語仕様) 34 ▪ プログラミング経験者のためのSwift最速入門 ▪ 詳細!Swift 4 iPhoneアプリ開発 入門ノート Swift

    4+Xcode 9対応
  35. Swift(言語仕様) 35 ▪ プログラミング言語 Swift □ https://github.com/hatena/Hatena-Textbook/blob/ma ster/swift-programming-language.md ▪ どこよりも分かりやすい

    Swift の "?" と "!" □ https://qiita.com/maiki055/items/b24378a3707bd35a 31a8
  36. iOS アプリ開発(ノウハウ) 36 ▪ iOSアプリ新規開発のノウハウ □ http://nsblogger.hatenablog.com/entry/2017/12/13/io s_development_know_how ▪ iOSアプリを作るときのおすすめ構成

    2017年末版 □ https://medium.com/swift-column/ios-2017-4f04d00a 5804
  37. iOS アプリ開発(アーキテクチャ) 37 ▪ iOS 開発で Clean Architecture を採用した際のイイ感じの ディレクトリ構成とは

    □ https://qiita.com/shymst/items/de7ea5fc2594b8da59 88 ▪ Swift/iosで開発するドメイン駆動 ~DDD(風)なモダンなアー キテクチャ □ https://qiita.com/ko2ic/items/6ac7321189e8c3ac166 5
  38. リーダーシップ・組織 38 ▪ スモールリーダーシップ ▪ エラスティックリーダーシップ ▪ マンガでやさしくわかる学習する組織 ▪ エンジニアリング組織論への招待

  39. スクラム 39 ▪ SCRUM BOOT CAMP ▪ カイゼン・ジャーニー