読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

仕事のバトン、渡っていますか? - プロジェクト管理におけるコミュニケーション基盤作り

Developers Summit 2012 2日目

PJで起きていること
明確なことと曖昧なことが混ざりあう

  • 開発方法論は関係ない
  • 繰り返している場合は明確なことが多い

明確なのが多い ウォーターフォール
曖昧なのが多い アジャイル

パッケージの適用にはウォーターフォールが向いている(繰り返しが多いから)

曖昧なことは明確にする
プロトタイピング フロントローディング

明確になったら計画を立てる
WBS(タスク、見積り、スケジュール)

曖昧なまま見切り発車しないといけないときもある

いつ発生するのか分からない
バグ、問い合わせ、仕様変更など、
「新しく発見したナニカ」

不確定なことにどうやって立ち向かっていくのか

不確定さを予測する

  • このぐらいバグが出る
  • このぐらい仕様変更が出る

「時間枠」の中で、その不確定さの幅に収まっているか判断する

タイムボックス型(アジャイル的に言うと)
時間の枠の中で、何が出来るかを考える

そこで「課題管理」が重要
新しく発生したナニカ

  • 内容
  • 発生日
  • 担当者
  • 重要度
  • デッドライン

プロジェクトマネジメントの初期のレベル
小さい会社だとスケジュールも曖昧だが、
大きな会社だと、課題管理をしないと致命的

メモ帳で全てが回せるならそれでもいいけど。

課題管理の最強ツールExcel
自由にカスタマイズできる(マクロやバリデーション、フィルタ、ピボットな
ども出来る)

多くの人のPCで、印刷して共有できる
それだけじゃ足りない



仕事のバトン
仕事は一人じゃ解決(完結しない)

プロジェクトの構成要素が複雑で、スキルが広範囲に及ぶ
成果物を分解し、タスクにして、プロセスとして並べていく

例:テスト工程

  1. バグ発見
  2. 修正
  3. 修正したものをテストサーバにデプロイ
  4. バグの修正を確認
  1. テスターがバグを発見
  2. エンジニアが修正
  3. デプロイヤがデプロイ
  4. テスターがバグの消滅を確認

1人が複数の役割を兼任することもある

ありがちな問題
どれをリリースするのか?
もう直っているのか?
いつ直ったのか?
誰が担当するのか?

これらの問題はバトンがうまく渡っていないことが原因である

バトンを待っている人からしたら、いつどのようにバトンが渡っているのか
すごく気になるところである。

その課題がプロセス全体のなかでどこにあるのか
プロセスが非同期に実行されているなかで、全体として同期すべきイベントがある
全体としてどういう状況なのか

上記はExcelだけでは足りない(出来なくはないけど…)

チームとしてどのように問題、課題を共有すべきなのか

課題管理ツール(Jira)の実践

  • 個別課題のオーナーや状態を管理
  • 横断的にくくるフラグを制御
  • 全体をリスト化できる

適用への道程(仕事のバトンの渡しかた)

まずはテスト工程(バグ管理)から

  1. テスターが問題をチケット化する
  2. リーダーがチケットをエンジニアに振る
  3. エンジニアがチケットを進行中にし、修正
  4. デプロイヤーはあるていどリリースするものが貯まるまで待つ
  5. リリース(1.0→1.2)
  6. テスターが再度判定
  7. OKだったらチケットをクローズする

担当者の切り替えだけでなく、状態の切り替えとバージョンの管理も行う
プロセスだけでなくフローも考える

テスト以外の適用箇所
顧客とのQA管理 オフショア先のチーム間など。遠隔地に有効
pdfで落とせるよ
設計者or顧客がチケットの中身を作成、確認し、チケットを作成する

双方向リンクを利用することで負荷なく運用できる

顧客→リーダー→エンジニア(バージョンも設定する)→デプロイヤー→テスター

もちろん、チケット管理システムだけでなく、レポジトリ管理やCIツールも
使えばよい

管理のコツ

  • 起票のルールを決める
    • 気遣い重要。特に言葉遣いは丁寧に(くだらないコメントの応酬はやめよう)
    • 事実を書く(バグの書きかたも参考に)
  • プロセスを決める(誰がクローズするのかが一番重要)

運用のコツ

  • 初期はメンバーの教育も必要なので、チェッカーの運用が重要(啓蒙する人が必要)
    • 抱えがちな人には棚卸しを定期的に促す(チケットを引き受けまくる御人好しにいがち)
  • リーダーが状況を把握するのに使う(誰が遅れているかが分かる)
  • 複数プロジェクトで使う場合は事務局が重要(情報資産の管理もあるので、誰にどのような権限があるのか把握する人らが要る)


応用篇

  • 品質管理
    • バーンダウンチャート
    • コンポーネントや独自フィールド(バグの要因など)を利用した分析

課題管理ツールのもう一歩先

注意点
いわゆるチケット駆動開発はレベルが高い
アジャイルは、どのタイミングで新しい作業が発生するのか
分からないときに有効であり、作業発生のタイミングが
はっきり分かっているときはウォーターフォールでよい。

チケット駆動にしたってプロセスが安定するわけではない
(問い合わせベースで開発をやっているひとは、いやでもチケット駆動に
なっていくはずである)
運用・改善フェーズは良い

チケット駆動を意識するより、まずプロセスとフローをちゃんとすることが重要

アンチパターン

  • 計画的なものはJIRAとかを使わず普通にエクセルを使ったほうがよい
  • JIRAは設定しすぎるとダメになる場合が多い
  • タスクを階層化しすぎるのはよくない(無駄に親子関係を発生させるとチケットがカオスになる)
  • 複数のコミュニケーションツールを併用するのはやはりよくない(電話やメールなど窓口を増やしすぎるとわけが分からなくなる)

勿論、JIRAで解決しないものは電話やメールを使ってもいいですよ。


まとめ
そもそも「時間管理」のほうが重要

  • WBSなき課題管理ツールは失敗する
  • 課題管理ツールに先立って、まずはタイムマネジメントが重要
  • ルーチン化した状態(=運用)でもOK

時間枠の中で不確定なことを管理する

  • 計画してても不安定なことはありうる
  • いつどこでどのような問題が発生するのか分からない

使うならまずはバグとQAから

  • 運用フェーズもおすすめ
  • 管理は少しずつ複雑にしていく(複雑になったら捨てる)
  • 仕事のバトンを渡していく工夫をする
  • 課題番号を長く使う

なるべく長く使うことが重要