How to run a big(ger) project as a SWE / Manager

How to run a big(ger) project as a SWE / Manager

1. 1. How to run a big(ger) project as a Software Engineer / Manager WTMTokyo 2018, Apr 7 Kinuko Yasuda
2. 2. Who I am Kinuko Yasuda (安田 絹子, kinu@) Google ソフトウェア・エンジニア 10年目 最初の２年は　　 そのあとはずっと その前は大学だったりスタートアップにいたり 少し研究職、あとほぼずっと技術職。2015〜2016年まで兼マネージャ
3. 3. Who I am NOT 伝説の天才エンジニア すてきな会社やNPOの創業者 超人的にすべてをこなすワーキングマザー
4. 4. I am still… かなり成功している機能 (Service Workers) の ex-TL とても良い (と私が信じている) チームを持っている 重要度が高めのプロジェクトをいくつかドライブしている
5. 5. 今日のおはなし ある程度大きいプロジェクトを回すには？ ● Service Workers と私 ● 技術者、そして TL / TLM としての心がけ ● チームやプロジェクトを回す上での心がけ NOTE: Doesn’t really mean I’m great at any of these!!
6. 6. Service Workers の紹介 Google などが提案している Web の新機能 (Chrome の機能ではない) Web の制約を打ち破り、アプリのようなサイトを可能にする 最近ややホットな PWA (Progressive Web App) の基盤技術
7. 7. Service Workers のブラウザ対応状況
8. 8. Service Workers のこれまで ● 2013 年 2 月: 仕様化開始 (github で最初の内容のある commit) ● 2013 年 7 月: Chrome で開発開始 ● 2015 年 1 月: Chrome 40 安定版でローンチ ● 2015 年 12 月: Facebook が Service Workers での Push 通知を開始 ● 2016 年 1月: FireFox 44 安定版でローンチ ● 2017 年12月: Edge と Safari の開発版で使えるように ● 2018 年 3月: iOS Safari で使えるように
9. 9. Service Workers と私 初期メンバーではない 参加半年後には休みでいなくなった でもローンチ時バージョンのコア 実装部分はほぼ私が設計した(と思う) 戻ってきて TLM (TL/Manager) に 2013年9月から kinuko 参加 2014年3月頃から TL / ほぼ東 京メインで開発
10. 10. How I got to working on Service Workers? それまでやっていたプロジェクトは安定状態だった (Comfort Zone) 次のプロジェクトを探しはじめる ● MTV のディレクターや普段話さない人と話した ● 組織全体の優先度と自分のできることを見直した ● よいチャンスをつかめる準備ができていた ● まあ、タイミングと運も
11. 11. 大きなプロジェクトを掴む概ね役に立つ心がけ ● Comfort Zone にいると思ったら次の展開を探す ● チャンスをつかめるように： ○ 組織の大きな優先度や動きにアンテナを張る ○ 組織を動かしている人たちとなるべく話す ○ 地味な努力が大事な部分 ■ 自分のポートフォリオを定期的に見直す ■ 自分の信頼度と認知度をあげる ■ 良いチーム関係を築き上げる
12. 12. 今の私の仕事 Service Workers を含むいくつかのチームやプロジェクトを見ている。 ● すべてのチームに優秀な TL が別にいる ○ チーム・各プロジェクトはTLが実際に回す ○ Uber-TLing: ハイレベルなロードマップの提示、優先度の明確化、長期的・アー キテクチャ的な設計変更の計画、設計やコードのレビューなど ● 全体のポートフォリオを見て新しいプロジェクトを立ち上げる ○ Stake holders への売り込み、プロトタイプの開発、Explainer の公開
13. 13. 技術者がキャリアを築くためにできること 次の３つを分けて考える ● ゴール（例：キャリアを築く、大きなことを成し遂げる） ● 自分がそのために成長させておくべきこと ● 自分が得意なこと キャリアに限らず、必ずゴールやそれに近い理想状態から考える。
14. 14. 技術キャリアを築くのに必要なこととは？ ● 技術力？ ● 英語力？ ● コミュニケーション力？
15. 15. 技術キャリアを築くのに必要なこととは？ ● 技術力？ ● 英語力？ ● コミュニケーション力？ これらは普通はゴールのための手段として成長させると役立つこと （突出させるのに成功できればゴールが勝手にやって来ることもある、けどそれでもゴールから 逆に戦略を考えないと突出させるべき部分を間違える） ×
16. 16. じゃあ、本当に大事なことは？ ● Impact ● Difficulty ● Leadership ● Happiness
17. 17. Impact ● プロジェクト内における個人の影響力 ○ そのプロジェクトを進めるためにどれだけチームに貢献したか？ ○ もしいなかったとしたらそのプロジェクトのどこが成功しなかったか？ ● 組織におけるプロジェクト自体の影響力 ○ そのプロジェクトはユーザや組織や業界にどれだけの貢献があったか？ ○ 利益やユーザ数、人々の幸せ、分野自体の進展にどれくらい影響したか？
18. 18. Difficulty ● どれくらい困難な問題を解いたか？（解けることを示したか？） ○ 困難さは技術的な困難度のみを示すものではない ○ それを成し遂げるのに必要な組織的困難、対外的交渉の困難、問題自体を定義す ることの困難などを含む ○ ジュニアなうちは技術力が、よりシニアになるとそれに加えて定義が曖昧な問題をう まくスコープして前進させられる人が重宝される
19. 19. Leadership ● 他人に影響を与え、組織をリードすることでより大きい Impact を産む ○ ジュニアなうちはどれくらい“self-leadership” が取れるかが大事 ○ 問題の優先度を認識し、必要な人とコミュニケーションを取り、解決までの道のりを 自分でどれだけドライブできるか ○ よりシニアになるとチーム、複数のチーム、そして組織や業界全体への影響力へと スコープが広がる
20. 20. アンチパターン ● 自分ができることの延長線に問題を作ろうとする （例：この技術はかっこいいからそれが使えそうなプロジェクトを作ろう） ● 組織の優先度や技術的に可能なこととゴールが剥離している （例：快適な睡眠を実現するべきだ！けどそれは多分Chrome ではできない） ● 難しい方法で解くことに専念するが、Impact に関係ないか悪影響 （例：時間をかけて複雑なコードを書いたが、ユーザからすると簡単にやったものと結果 は同じでかつその後のコードメンテナンスが困難に）
21. 21. アンチパターン ● Impact がはっきりしてることだけをやりたがる （技術的成長が追いつかずできることが頭打ちになる） ● 他の人のアイディアはサポートしない （実際に得られたはずの組織やチームとしてのImpact や幸せが損なわれる） ● 他人のプロジェクトの助け役に徹してしまう （自分の得意なことばかりになりがち。自分が責任を持って関わったものがないと貢献度 や影響力が測りにくく、成長機会も少なくなる）
22. 22. 重要なこと：Happiness 最終的には自分が情熱を持って Happy にできるものをやるのが一番。 それがマッチしないと思ったら組織やチームを移るのも一つの手 （それが柔軟にできるような自分のポートフォリオを組んでおくのは戦略の一つ）
23. 23. 自分の成長とキャリア 自分のポートフォリオを常に見つめ直すのは必要 ● より大きいゴールを達成するためにどこを伸ばさなければならないか ● Impact に直結しなくても伸ばしておきたいところがあればタイミングや力をか ける割合を調整して投資する ○ どれくらい先にどのImpact に結びつきそうなのかは見積もっておく
24. 24. 他人に影響を与えられる立場に立つ 近道はあまりなくて、本質的には次の３つ４つが必要と思っている： ● （Impact ある仕事などを通じ）存在感を出す、重要な人に認識される ● （技術力や調整力などの成長を通じ）人から信頼されるようになる ● 判断をくだし、それを根拠とともにはっきり述べ、かつその柔軟さを保つ ● 相手の意見には立場に関係なく敬意を払う
25. 25. 「自分」から「チーム」へ ある程度大きなことは、必ず「チームワーク」が必要 天才に見える人も、つまりは「チームとうまくやる」ことができている ((c) Team Geek)
26. 26. チームを Manage する 鉄則とされること ● Humanity （人間性）を大事にし、尊重する ● 必要なフィードバックは可能な限り率直に簡潔に伝える(‘Radical Candor) ● そして：Team Happiness が結局はもっとも生産性に影響する Be nice であり過ぎようとすると最終的に誰も幸せにならない 自主性に任せるのとフィードバックを出さないのには大きな違いがある 良いカルチャーを促す、良いことはみんなで褒め合う。家族や自分の幸せを安心して優先し、それを表立って言 える場であることをできる限り示す
27. 27. ポートフォリオもチームや組織で考える ● 全体としてどこを伸ばすとより強いチームになれるか ● 一方、それぞれの人が幸せに思うポイントはどこか ● どのタイミングでそれぞれの人に良い成長やImpact を見せる機会があるか
28. 28. ミーティング ● 出席者全員に関係あることを優先して話す ● 細かい議論は関係ある人と興味ある人だけであとでやる ● すべてのタスクには明確なOwner を立て、次のアクションを確認 ● プレゼンは基本しない。あらかじめdocument をシェアする ● その場で共有文書に複数人で議事録を取る。確認が必要なことは当事者に直接なおしてもらう ● 全体の優先度やロードマッププランニングは、あらかじめ文書でやったあとミーティングで全員で見ながら 編集する（のが私は好き。自分の仕事以外の文脈がより多く共有されるから）
29. 29. 最後にもう一度：Happiness 細かいTips ● 自分やチームの人がどこで幸せを感じるのか知るのは大事 ● 辛いとき、全力を出せないとき、やり切れないとき： ○ 期待値コントロールに気を使う（周りに状況と期待していいレベルを伝える） ○ ストレスコントロールに気を使う ● 心がうまくついてこないとき ○ 心はコントロールできない。状況や環境や技術はコントロールできる ○ 自分の心が安心しやすいやり方を覚える（空き時間の使い方、運動、 TODOの作り方など）
30. 30. Thank you! Q&A Tell me about yourself!