開発支援ツールで疲弊しているあなたへ / for exhausted developers with management tools

開発支援ツールを複数プロジェクトに導入したときのつらみや知見をまとめました。

Transcript

1. 開発支援ツールで疲弊しているあなたへ @takamii228
2. 開発支援ツールで疲弊していませんか？
3. ツールはいろいろな種類がある
4. 導入したのはいいけれど・・・ • うまく使いこなせてないかも ... • 全然開発効率が上がらない ... • むしろ管理が面倒で下がってる ... • ...
5. INDEX • 開発支援ツールのアンチパターンとその解決策 ◦ チャット編 ◦ チケット管理編 ◦ ドキュメント（Wiki）編 • まとめ • メッセージ
6. チャット編 • 議論が紛糾し収集がつかず、険悪なムードになった • やけに静かだと思ったら、非公開チャネルが乱立していた • 「チャットに書いた」と主張する人の情報を見逃した
7. 議論が紛糾し収集がつかず、険悪なムードになった • 非対面かつテキストでのコミュニケーションは誤解や認識祖語を生みやすい ◦ 複数開発拠点やリモートでの開発で起きがち • 必要に応じて電話・テレビ会議等の対面や言語でのやりとりに切り替える ◦ WebEx環境、分散拠点に会社携帯電話を配置 • 「三回質問のキャッチボールが続いたら電話する」ルールを作った ◦ 不毛なやりとりは時間の無駄 ◦ 認識齟齬の早期解決が言い争いを防ぐ
8. やけに静かだと思ったら非公開チャネルが乱立していた • 情報の透明性が保たれないので非公開チャネルは使わない ◦ チャネル設計と運用ルールを決める ◦ 1_xxx, 2_yyyなど通番に意味を持たせると分かりやすい • 投稿に対する心理的ハードルを下げる ◦ 雑談チャネルで盛り上がる（面白 botを入れる、誕生日祝う、面白記事共有など） ◦ 毎日の日報を書く（やったこと、やること、困ってること、連絡事項） • 気軽に質問し、お互いに教えあう文化を作る ◦ 自分が知りたいことは他の誰かも知りたいこと ◦ 意外な人が有益な情報を答えてくれる
9. 「チャットに書いた」と主張する人の情報を見逃した • チャットは即時性がある一方で、流れが速いフロー型の情報 ◦ 流量が多いチャネルは情報を種別して分割する • チャットの主な責務は通知（とリモートの人とのコミュニケーション） ◦ みんなが気づくように @channel をつける ◦ 通知情報をチャットに集約して見る頻度を増やす（ Push、チケット更新、リリース情報など） • QAのやり取り結果や決定事項を Wikiにドキュメント化する ◦ チャットの検索は結構貧弱 ◦ 誰かが以前聞いたことは将来の誰かが知りたいこと
10. チケット管理編 • ひたすら増え続けるチケットたち • 何のタスクか全くわからない謎チケットたち • 一向に完了にならないゾンビチケットたち
11. チケット管理ツールで何を管理していますか？ • チケット管理ツールで管理するのはチケットのステータス ◦ チケットのステータスと遷移のワークフローを最初に定義する ◦ ワークフローのルールをチームメンバの共通認識にする • チケットを作るときに十分に詳細化し、「誰」が「いつ」までに完了させるかを書く ◦ 十分に詳細化できていないタスクは入れない or 詳細化の段階を踏む ◦ チケットに期限を入れ、期限が近付いていることが確認できるようにする • チケットを定期的に見直す機会を設ける ◦ 定例、デイリースクラム、振り返り ◦ 滞留しているチケットに気づくきっかけになる
12. 増えるチケット、謎のチケット、ゾンビチケット • 用途やワークフローに応じてボードを分割する ◦ 複数の内容が混在すると量も増えて混乱の原因になる ◦ 乱立するのも情報が散在するので、管理できる数に留める（ 3~5つくらい） • チケットを切る前によく考える ◦ チケットを切る前に詳細化のフェーズを置く ◦ 十分に詳細化し「何のため」に「誰」が「いつ」までに完了させるかを書く ◦ タイトルは「名詞」 +「動詞」の形で書くとわかりやすい • チケットに入れた後は必ず定期的に見直す ◦ 適切なステータスに変更し、進行状況を可視化する ◦ 色付けやフィルターで遅れているものが一目でわかる状態になるとベター
13. ドキュメント(Wiki)編 • 何を書いたらいいか分からず記事が増えない • どこに何が書いてあるか分からないし検索にヒットしない • ようやく見つけた！と思ったら古い情報だった
14. 何を書いたらいいのか分からず記事が増えない • 定例や打合せの議事録から始める ◦ 事前に打ち合わせたい内容を書いておく ◦ 打合せ中に議事メモを記入、参加者でそのままレビューし、終わったらチャットで共有 • 書く心理的ハードルを下げる ◦ チームビルディングに使ってみる（自己紹介ページの作成、近くのおすすめランチ情報など） ◦ 環境構築やリリースの手順をまとめる（再利用性の高い情報こそ載せるべき内容です） • 誰かに聞いてわかった・明らかになったこと、ちょっとしたメモを書く ◦ 自分が聞いたことは他の誰かも知りたいこと、未来のメンバの誰かも知りたいこと ◦ 人は忘れる生き物なので、複雑な内容や覚えられない内容は書くべき
15. どこに何が書いてあるのか分からないし検索でヒットしない • 階層構造をうまく活用する ◦ ファイルサーバの管理と同じ • 記事のタイトル付けを工夫する ◦ 検索キーワードを思い浮かべてタイトル付けする • ツールの検索機能のクセをつかむ ◦ タイトルマッチ、本文マッチ、記入者、タグ付けなど • 他のページへの記載や他ツールにも書いてたどりやすくする ◦ 「Wiki記入」のタスクに URLを張る、チャットに URLを張るなど ◦ Confluence + JIRAはよろしくやってくれる
16. ようやく見つけた！と思ったら古い情報だった • 間違いや古い情報を見つけたら更新する ◦ 古い情報はミスや負債の元になる ◦ 気づいた人が直す文化を作る • Wikiを育てることは、チームの集合知を育てること ◦ 属人性の排除でクロスファンクショナル化を促進する ◦ 新規メンバの立ち上がりも早くなる
17. まとめ
18. これら問題の主な原因 • ツールの目的や得意不得意を考慮した使い方をしていない ◦ チャット 　→　通知、リモートとのやり取り、即時性、フロー型情報 ◦ チケット管理 　→　スケジュール管理、ステータス変更、大人数で更新 ◦ ドキュメント(Wiki)管理　→　ストック型情報、更新が必要、チームで要メンテ • 他でうまくいった方法をそのまま使おうとしている ◦ 背景や前提が異なる ◦ 自分たちのチームに合わせて運用のカスタマイズが必要
19. カイゼンジャーニー ”外から得られた学びを、そのまま自分たちの現場や仕事で適用しよう としてもたいていうまくいかない。自分たちの「状況」に照らし合わせて みることが必要だ。 （中略）私たちは、他者の実践の背景にどんな状況、制約があったのか を理解し、自分たちの状況、制約の下ではどのように実践すべきかを 捉え直さないといけない。 ”
20. まとめ • ツールは目的のための手段の一つにすぎない • 自分たちの置かれた状況を踏まえた運用設計をするべき • 最初から完璧を目指すのではなく、Fit & Gapで改善を繰り返す
21. メッセージ そのツールで実現したいことは何ですか