副業時代のプロジェクトマネジメント

Transcript

1. 副業時代の プロジェクトマネジメント 2019/01/26 Backlog World 2019 株式会社オムニス 吉次 洋毅

2. 話すこと • 自己紹介 • 副業「チーム」とは？ • チームマネジメント • プロジェクトマネジメント •

   まとめ

3. 自己紹介 • 吉次 洋毅（ヨシツグ ヒロキ） • 1991年生（27歳） • 徳山高専 専攻科修了

   • 経歴 ◦ 2014/4〜2016/11: 某飲食店検索サービス企業（主にサー バサイドエンジニア） ◦ 2016/12〜 某HR企業 （主にフロントエンドエンジニア+いろいろ） ◦ 2018/8〜: オムニス（副業リードエンジニア） ◦ プロジェクトマネジメント的な仕事は割と得意だったので ずっとやってきました

4. 今の働き方 平日の日中は正社員とし てWebサイトを開発する など 土日や平日夜間は フリーランスエンジニア 本業 オムニス フレックス！ リモートOK！

   （※部署による） 基本リモート！

5. オムニスの開発体制（例） https://unbuilt.jp 【プロダクト】 【常駐チーム】 ・平日日中稼動 ・基本的には同時間帯 【副業チーム】 ・夜間 / 土日稼動

   ・曜日、時間帯バラバラ ・現在3人 １つのプロダクトに異なる性質の２つのチームが関わっている コミュニケーション

6. 背景... 副業「チーム」がもともともと存在したわけではなく、 吉次がジョインするタイミングで出てきた新しい試みだった

7. 課題の抽出と分析（まずやったこと） • 目指すべき状態 ◦ 副業メンバーがチームとして成り立つこと ◦ 副業メンバーのモチベーションが高いこと ◦ プロダクトに対しての成果を最大化させるために最適なコ ミュニケーションが取れること

   • 課題としては大別して2種類 ◦ そもそも副業「チーム」がうまくワークするか →①チームマネジメント戦略 ◦ 常駐チームとうまく連携して、業務を進められるか →②プロジェクトマネジメント戦略

8. これを https://unbuilt.jp 【プロダクト】 常駐チーム 副業チーム

9. こうしたい https://unbuilt.jp 【プロダクト】 常駐チーム 副業チーム

10. ？？

11. これを！ https://unbuilt.jp 【プロダクト】 常駐チーム 副業チーム

12. こうしたい！ https://unbuilt.jp 【プロダクト】 常駐チーム 副業チーム

13. どういうことかというと… https://unbuilt.jp 【プロダクト】 ②常駐チームー副業チー ム間のコミュニケーション の最適化 ①副業「チーム」としての成 果最大化 常駐チーム 副業チーム

14. ①＋②＝プロダクト価値の最大化

15. 組織を起点に 仕組みを考える

16. ①チームマネジメント戦略 組織の話

17. 個々のモチベーションとパフォーマンスの最大化 • モチベーションの維持＆向上、不安の排除 ◦ 時間的な制約を受けやすい副業では、細切れ時間を使っ て成果を積み上げていく必要がある ◦ 故に、「成果が見えづらい状況」はかなり辛い →適切な粒度でのタスク分割 →適切な粒度での情報伝達

    モチベーションを下支えする仕組みづくりが必要 ※具体的にどうやるかは「プロジェクトマネジメント」パートでのお話

18. マネジメントにあたっての意識 • バランス感覚 ◦ フリーランスとしてジョインする会社・社員の方に求めるこ と ◦ 会社員としてフリーランス（≒副業メンバー）に求めること → どちらかの立場に視点が偏らないように意識的に振る舞う

    → 全体最適の狙いを持って異なる立場の人にアプローチする

19. 副業リードエンジニアとしての振る舞い • コミュニケーションの吸収 ◦ いざ副業メンバー（開発やりたくて参加している）が手を動 かすとなったときに、いろんな確認が発生するのはもった いない ◦ タスク発生時点で内容を確認して、手を動かすために必要 な情報を揃えておく

20. 副業リードエンジニアとしての振る舞い • 「決める」こと ◦ いつもやりやすい状態でタスクが切られるわけではない ◦ 異なる働き方をする人同士のコミュニケーションは簡単で ない ◦ タスクを切る側からすると「それはやる人が決めてほしい」

    ということも多々ある（会社員としての立場） ◦ 不確定要素には意思決定。仮決定と提案をあわせて行っ てとにかく前に進める ◦ 立場や肩書きがあると決めやすい

21. ②プロジェクトマネジメント戦略 仕組みの話

22. 副業メンバーの稼動・工数管理 • Googleカレンダーの活用 ◦ 稼働予定を1ヶ月単位程度で登録 ◦ 大体の消化可能なタスク量を把握 ◦ プロジェクトのスケジュールと各人の稼動予定に応じて副業 チームに回ってくるタスクをアサイン

    ◦ バッファは自分

23. ミーティングの実施 • ミーティングの実施 ◦ ずっと非同期、非対面は結構厳しい ▪ 人となりの理解 ▪ ちょっとした息抜き ◦

    適切な粒度で情報を伝える場が必要 ▪ 「見といて」だけだとちょっと乱暴 ◦ 一緒に仕事をしている感覚（重要！） ▪ モチベーションの維持・向上、心理的安全性 ◦ プロジェクト状況の棚卸し ▪ 全体把握の視点

24. コミュニケーション設計 仕事の模式図

25. コミュニケーションはタスクから生まれ、タスクはプロ ジェクトから生まれる。 良いコミュニケーションのためには良いプロジェクト/ タスク管理が必要。

26. ツールの整理

27. ツールの整理 寿命の長い情報 アドホックなやりと り

28. みんなだいすきBacklog！

29. Backlogの使い方 • タスクの発生から完了までの流れを定義 • チケットに記載する基本的な情報の定義 ◦ テンプレートの作成 • 基本的なルール ◦

    担当者を必ず入れる ◦ 期限日を必ず入れる ◦ 完了条件を記載する ◦ チケットの分割、統合は担当者に任せる ※細かい部分は時間が無いので省略...

30. BacklogとSlackの使い分け基準 • Backlogを使ったほうが良いこと ◦ タスクに関係する質問 ◦ 記録しておいたほうが良いこと ◦ 質問から回答まで時間がかかりそうなもの ◦

    非同期で進める必要があること • Slackを使ったほうが良いこと ◦ 同期的に進められること ◦ 軽いコミュニケーション（すぐに解決しそうな質問など） ◦ 共有（タスクとして管理する必要が無いもの）

31. ベースラインを合わせる これらの情報をKiberaにまとめて、新しくジョインした人もベースが揃うようにしてい る

32. まとめ • まずはモチベーション ◦ モチベーション抜きにしていい仕事は生まれない ◦ 共通認識やチーム感がパフォーマンスに寄与する ◦ 下がる要因の排除が重要 •

    その次に仕組み ◦ モチベーションを支え、プロジェクト進行に有用な仕組みづ くりを行う • 苦しみは必ずある ◦ ビジネスにもテクノロジーにも、何かと事情がついて回る。 ときには歯を食いしばって気合で乗り切る覚悟も必要。

33. ありがとうございました！ ※スライドはSpeaker Deckで公開します 　@gyarasu