#JBUG (東京#10) 失敗談から学ぶプロマネの極意に参加してきた
どうも、y-onoです。Backlog World 2019に引き続き、2019年6月7日に開催されたJBUG東京のコミュニティイベントに参加です。副題の「気づいた後ではもう遅い。経験から振り返る虎の巻」を持ち帰りに来ました。
目次
- Session1. 「コミュニケーション設計をおざなりにしない！」
- Session2. 「盲点 -プロジェクトマネージャーの目は2つ-」
- Session3. 「1人で抱え込みすぎていませんか?私は1人で抱え込みすぎました…開発に必要なのは、チーム力とツールでの共有」
- LT1 . タスク管理における3つの失敗とその対処法
- LT2. Naoyuki_Ikegameさん
- LT3. Backlog課題登録・更新Slack通知ツール～担当者にのみSlackDMで課題情報をお知らせ！
- LT4. Backlog X toggl を活用した時間可視化術
- 最後に
Session1. 「コミュニケーション設計をおざなりにしない！」
極意
関係者の洗い出しと整理
どのレベルで何を同意するのか、
会議の種類と目的の定義
会議での合意事項が後でひっくり返ること、あるあるです。定例会のアジェンダを消化できないまま時間切れや会議延長、あるあるです。
コミュニケーションする相手は適切か？会議体のアジェンダは適切か？参加者は？ロールや役職・レイヤーが異なれば、情報の抽象度を変える必要がある。
合意形成をスムーズに進めるためには、会議設計をちゃんとやる。プロジェクト管理タスクは、すべてに関連し繋がるものなので、個別に独立して考えず、連携させて考える。
所感
会議体のあり方については、同意。アジェンダはあらかじめ共有する、資料も配布するようにしています。また、関係ない会議にはなるべく参加しないようにしています。議事録は、Googleドキュメントでリアルタイムに記録しながら、その場で共有するようにしてますねー。もう、Wordで配布とか、ありえないです。
Session2. 「盲点 -プロジェクトマネージャーの目は2つ-」
www.slideshare.net
- 極意その１「可能な限り管理対象を増やさない」
- 極意その２「人を信用しない」
- 極意その３「自分の目を信用しない」
フルセットのプロジェクト計画書でプロジェクト管理しようとしても、プロジェクトマネージャができる範囲は限られている。なので、管理対象を絞ったり、取捨選択・最適化、物によってはマージして、管理対象を絞るのが極意。ただし、品質は落とさない。
人間は思い込みや認識齟齬によってミスするもの。「進捗８０％完了しました」次回の報告でも「進捗８０％です。」←全然、進捗していない。だが、成果物は嘘をつかない。現物を確認せよ。
「こんちには みさなん おんげき ですか？ わしたは げんき です。」これ、なんとなく読めますよね？人間の目なんて、思い込みや過信によって、都合の良い解釈をするもの。
所感
ある程度経験を得ると、思い込みが出て来ますね。それも、自分の都合のいい解釈をしてしまいがち。「多分、大丈夫だろう。だって、以前もうまくいったから。」でも、プロジェクトは一意性なので、以前うまくいったからといって、今回もうまくいく保証はありません。性悪説というと言葉が強いかもしれませんが、現実主義に立ってプロジェクトを見直してみるいいキッカケになりそうです。
Session3. 「1人で抱え込みすぎていませんか?私は1人で抱え込みすぎました…開発に必要なのは、チーム力とツールでの共有」
フロントエンジニアと、エンジニアでのチーム体制で、複数の案件をチームで対応しているが、案件数が突如伸び出し、増え続ける案件相談。
忙しいけど、意外と乗り切れた・・・。定時すぎると割り込みも減って捗る。
すると、だんだん、アサインされる案件が増えてきた。フロントエンジニアしながら開発している。←よくない兆候。
A案件で要件変更、B案件で要件追加、C案件はお客さんのデータ投入誤り。D案件で新規案件発生。インシデントが重なる。
打ち合わせしながら、開発する。って無理じゃね。だんだん生産性が落ちてくる。リモートワークなので状況が見えない。
アラートが遅れた。作業を優先にして、Backlogなどの入力を後回しにしていた。フォローが入りにくくなっていた。→ 見える化ができていなかった。
やったこと。
- ツールの役割の見直し
- チーム力強化
- 情報共有の徹底
- 価値の見直し
まず、Backlogの使い方を変えてみた。
効果
- 常にチーム内でフォロー。アラートの確認。
- ツールの活用で共有からの、引き継ぎも楽。
- チーム内で絆ができ、「信用」から「信頼」へ。
まとめ
- ツールは活用してこそ意味がある。
- 「あれ？」と思ったら、すぐに整理する。
- ツールの役割を振り返る。
所感
リモートワークが中心となると、アラートのキッカケが難しくなるし、一度乗り切ってしまえると、「あれ、俺って凄くね？」と過信に陥ってしまうのかもしれませんね。『組織は「信用」で回るが、チームは「信頼」で結束する。』非常に良いセンテンスだと思います。
LT1 . タスク管理における3つの失敗とその対処法
www.slideshare.net
いつの間に消えているタスク。成果物が未完成のまま「対応しない」で完了したので、成果物ができたものと誤認してしまった。対策として、完了にしてはならない種別を決めて、毎晩「完了」にしたタスク一覧をメールで通知して、チームに周知するようにした。
LT2. Naoyuki_Ikegameさん
（スライドなし）
稼働は増やさずに、５０％キープ。残りを割り込みタスクに割り当て。 企画案件は、運用に近く、カンバン方式を取る。 案件の稼働時間を可視化、見える化する。
LT3. Backlog課題登録・更新Slack通知ツール～担当者にのみSlackDMで課題情報をお知らせ！
www.slideshare.net
GAS（Google Apps Script）でBacklogAPIを使ってSlack通知。担当者に応じた通知先などのを細かく設定できる。（これ便利そうなので、使ってみたい。）
LT4. Backlog X toggl を活用した時間可視化術
www.slideshare.net
Backlogの「実績時間」を入力が面倒なので、toggleを導入した。Chromeの拡張機能に導入することでBacklogでも対応可能。Backlogの課題にToggleボタンが出てくるので、タイマーが発動してくれる。これで、差し込みタスクに割かれる時間も見える化できる。振り返りに便利。
最後に
JR大崎駅はあまり利用する機会が無いのと、山手線遅延の影響もあり、開始数分前ギリギリに会場到着。汗だくにも関わらず立て続けに缶チューハイ（ヌーラボさん提供）を二本を飲んだので、同テーブルの方々には呂律の回らないおっさんだなぁ、と思われたかもしれません（汗）
さて、プロジェクトマネージメントはまだまだウォーターフォールの影響が強くて、アジャイルのように柔軟さや機動性に欠ける面も多いかと思います。Backlogは使い方次第では、WF型プロジェクトでも、柔軟さや機動性を取り入れられるツールですので、積極的に使っていきたいですね。
集合写真のポーズはBacklogの「b」マークですw
