BacklogWorld/国籍・職種・働き方の違いを乗り越えよう!ハカルス流プロジェクト管理術
ハカルスは、フィリピンと日本にエンジニアチームがあり、そのチームと一緒に管理栄養士、健康運動指導士の資格をもつメンバーが働いています。またパートタイムで参加しているメンバーもおり、まさに国籍も職種も働き方も多様なチームで日々仕事をしているスタートアップです。そこでの Backlog や Git を中心としたプロジェクトの進め方をご紹介します。多様なメンバーで構成されるチームや、スタートアップや新規事業などにおいて、Backlog をはじめとしたツールの導入やプロセスの改善を進める方のヒントになれば幸いです。
メンバー構成が多様
管理栄養士とか
フルリモートの鍵愛メンバー
うち三人は大学時代から友人関係
パートタイムとフルタイムがほぼ同数
京都の会社
学生やパートタイムディレクターなど
ジョイン後の初仕事
フィリピンチーム立ち上げ
日本とフィリピンを連携
「初めまして」から「3ヶ月後にリリース」
プロセスは極力シンプルに
Slack + Github + Cacoo
プロセスは走りながら定める
結果として定められなかったに近い
唯一決めたのはGitのブランチの運用
海外チームだと成果が分かるのはコードなので、コードの運用をちゃんとやる
master / develop / topic-branchみたいな
導入に失敗したプロセス
チケット駆動開発
チケット書いても見てもらえない
書いたつもりが伝わってない
当たり前過ぎてメリットの説明をおろそかにしてしまった
人数少ないうちはSlackと定期的な対面ミーティングで乗り切るのはあり
導入に成功したプロセス
プルリクベースのレビュー
ブランチ運用ルールがベースにあったので自然に受け入れられた
UIに関するものはキャプチャと一緒にレビュー
こまめなレビューはエンジニアにとってもマネージャにとっても安心
黎明期の振り返り
フィリピンチームとの文化的な差異
思っていることのベースラインが違う ☞ 最初にテキストで全部渡しても伝わらない
Cacooで画面イメージとかを出すとフィードバックもらえてよかった
開発パートナーとの期待感のずれ
過去の成功体験とのギャップに引きずられた
コミュニケーションの活性化
並行に走る複数プロジェクト
フィリピン・パートタイムメンバーの増加
タスク管理の課題
非エンジニアはAsana
Githubはエンジニア向けすぎる
エンジニアはGithub
コミュニケーションのボトルネックが顕在化
そこでBacklogを導入した
一つのツールで開発もそれ以外のタスクも管理
タスクの期限を明確にして運用
エンジニア・非エンジニアが対話するように
導入時の注意点
対海外メンバー
日本でのBacklogの人気っぷりを共有
フィリピンの人はAtlassianに慣れてる人が多い
ポピュラーなツールを使うんだよという感情面の説得
期限日や親子課題といったGithubになくBacklogにある機能の重要性を説明
Githubとの違いを説明して機能面での説得
いきなり全部を移行せずにタスク管理だけを移行
対非エンジニア
タスク管理なんぞや、から説明
使わなくていい機能を説明
最初はタスクを一緒にあげるようにした
サルでもわかるプロジェクト管理入門
その他の工夫
更新をWebhookでSlackに流す
テーマ・アイコンをプロジェクト毎に設定
ことある毎に「タスクをあげて」とお願い
スターをつけまくる
導入時の失敗
プロジェクトのルールを定めなかった
開発タスクが複数プロジェクトに分散
通知に気づかない
フルタイムと同じ感覚でパートタイムとコミュニケーションしてはいけない
通知に気づいておらず、指示が伝わっていなかった
導入後に改善したこと
チケット駆動開発が徐々に浸透
エンジニア・非エンジニアのコミュニケーションの活発化
展開期の振り返り
ツール導入の意義とか利点の説明が超重要
タスクにおろすことで忘れることができる
ツールを変えるときはこまめにモニタリング
ハカルスの今
混乱期から統一期に向かいつつある
職種の壁は少しずつなくなってきている
言語の壁・時間の壁はまだこれから
ホラクラシーとかT型組織とかはまだ早い
目指すのはツッコミあい
情報の透明性を確保
「知らないことがある」と思うと発言しにくくなる
「気づき」をすぐ伝えられる仕組み
ツール上のコミュニケーションの雰囲気
メンバー同士の関係性
F2Fで会う機会はちゃんと作る
背景の違いは何度も話す
チームへの携わり方
フルタイムか、パートタイムか、
日本か海外か
個人の性格・知識・調子
ITリテラシー
シャイとか元気そうとか
相互理解が相当大事
ツールは二の次?
まずは人間
まずはプロセス
まずはコミュニケーション
とか言うけれど、
いえ、ツールは超重要
分散チームはツールを介するコミュニケーションが主体
コミュニケーションの取り方はツールに一定レベル支配される
ツールの感情・印象はその人のツールとの向き合い方に影響する
多様性を許容するために
コミュニケーションは色々実験する
よっぽどな失敗でない限りはこじれない
ツールはプロセスと同じくらい真剣に運用する
ツールは文化を形成する
過去の成功体験は持ちつつ、とらわれない
人が変われば、やり方を変える
万能メソッドは無い
おまけ
元ヌーラボ中の人として「これやっときゃよかったな」
Jupyter Notebookのプレビュー
機械学習プロジェクトには必須
ファイルの外部共有用リンク
Google Drive / Box はダメなクライアントさんがちらほら
日本の大手企業さんだとある
Backlogは通る
ワンタイムリンク的なもの
git push -mirror 対応
Slack連携
課題の利用項目をプロジェクトごとに設定
etc..