- 適切な目標設定・・大、中、小の規模で区切る(数値管理ができれば理想)
- タスク&リソースの可視化 → 業務フローの確立・・シンプルであること
- モニタリング&フィードバック・・メンバー間の作業の進捗把握、問題提起、フィードバック
- コミュニケーション・・コミュニケーションコストの意識
- 定義が明確であること(数値化ができていればベスト)
- 進捗が%がはかれる(どのくらい目標に達成しているかがわかること)
- 達成可能であること
- 規模に応じた長さであること(大〜小規模に分かれていること。リリースポイントとスプリントゴールが決まっていること)
- 大きいリリースに備えて小さいリリースポイント(スプリント)が設定されていること
-
タスクの可視化
- 作業が何らかの目に見えている状態になっているか(Redmine、Backlog、GitHub などで一覧できる状態になっているか)
- 作業だけでなく作業の意図、本来の目的、Value がしっかりとかかれている
- 何をやればいいかが明確(テンプレート的なもので可視化できればベスト)
- 終了条件がしっかり定義されている
- 終わっている状態などが明確
- どんなに時間がかかっても MAX2,3 日でおわる粒度にする
- タスク同士の依存状態(プロックポイント)などがすぐわかる
- 数字(進捗率)がすぐに目に見える → これを追いかけることができているか
- 進捗率や異常の検知(進んでいないことがすぐに明確化できる)が楽か
- リソースの紐付けがあるか(時間、お金など)
- 期限が必要なものは明記し、別軸のアラートをあげる(カレンダーアプリなど)
- 関連タスクについて(このタスクが終わった後の別タスクへの影響)
- ラベルなどでフィルタリングが容易になるようにする
- クエリなどでみたい情報が一目でわかるようにする
- 独自のルールや担当チーム内だけでなく、ノウハウが関係者全員に共有されており、誰でも情報にアクセスできる(独自管理ツールみたいなものをなるべく使わない)
- 管理手法として、ミスを誘発しない仕組みがある
- 抜漏れを担保する仕組みなどが整っている(ヒューマンエラーに頼らないチェック方法がある)
- 二重管理になっていない
- 作業量の見積りがとれているか
-
リソース
- リソース・・自分の権限だとお金を扱うことはできないので、多くの場合は時間(=こなせるタスク)の管理
- できればこなせるタスク量がみえるとよいため何らかの統一的な単位があるとよい(人ごとにこなせる量があるとよい。スクラム開発で言う StoryPoint)
- バッファをつねに考慮(特にフェーズ間の移行でトラブルが発生することが多い)
-
業務フロー(タスクの集合体、連動)の構築
- 一覧できる情報として可視化、マニュアル化されているか
- 過度に複雑すぎずに直ぐに馴染めるものか
- シンプルで、それをやった方が得な仕組み(負荷が少ない)になっているか・・めんどくさいと続かなくなる。続けざるを得ない、続けた方がラクな仕組みができるか。
- 入力資料は入力欄が少なく、上から下、左から右に目をすすめるだけですべての情報が記録できるか(1 つのラインですべてをこなせるが)
- チェックリストなどで漏れを減らすような工夫ができているか
- 属人性を排除するような仕組みができているか
- 作業員の 8 割以上がすぐに馴染めるものか
- 個人の気づきに頼らないような仕組みができているか(ルーチン化された作業が存在しているか)
- プロジェクトマネジメントを行う上で、チケットを細かく分けた方が良いかもしれない。(タスク同士の横の関連でなく、階層上の関連)
- Epic(マイルストーン。リリース単位で顧客に価値提供できる単位。システム的なことよりもユーザーの困りごとや悩みといったレベルのほうがよいかも)
- Feature(上記を解決するための一塊の機能。結果として後述する Task の集合体)
- Task(行動できる最小単位)
- 現場が混乱しない(誰でもつかいこなせる、手段が目的化せず、機能する)ようにするには最大 3 階層ぐらいが限界だと思う。
- 仕事を進める上では Task だけでもなんとかなってきたとおもうけど、確かに Task の紐付きがわかると、システムを俯瞰できる(機能の価値がわかる)メリットはある。
https://qiita.com/syantien/items/b4fee1ec54940c3db198 https://rainbow-engine.com/epic-userstory-feature/
- メンバーの成果などがある程度、数値化できるようになっているか
- ボトルネックの発見
- 各人が自分の数値や問題点を把握できるようになっているか
- 適度な目標管理により、ある程度の短い期間(2 週間程度が望ましい)でフィードバックができるようになっているか
- KPT などでつづけることと問題点の把握、改善点などを付与する仕組みができているか
- リソースの費用対効果を最大限になるような技術的提案&改善ができているか(メリデメの理解)
- 既存の消化タスク量により見通しが正確になる(希望ではなく記録を！)
-
コミュニケーションコスト(時間、めんどくささ)を考えたコミュニケーションをとれているか
- 要点をわかりやすく伝える
- めんどくさくない手法
- テレワークのメリデメ
-
会議
- 本当に必要性を考えているか（参加者全員の時間を拘束する必要があるかを問えているか）
- コストを減らす仕組みができているか
- 会議のゴールは明確か(一言で言えるか)
- 事前の情報提供があり、参加者の知識をあげるような工夫があるか
- 問題点がある程度上がるようになっているか
- サマリー(議事録)の記録と参照 → 特に会議中にこれを参照することで議論の流れが直ぐにおえるようになっているか
-
文化づくり、人間関係の構築
-
積極的な働きかけをリーダー(上位者)からできているか
- いったことは聞かなくても、文化は伝染する
- 文化や習慣は一度できると当たり前になると、いい意味でも悪い意味でも覆すのが困難
-
問題点の提案
- 人格否定にならずに言い合えるような文化ができているか
- リスペクト 立場が上・・あくまで仕事上の責務であり、人間的な部分は別の次元であることを理解できるか
- データや記録に基づいた客観的な指摘ができているか(× 地頭、コミュニケーション能力)
-
- 「誰も教えてくれない 計画するスキル」
- 「紙 1 枚に書くだけでうまくいく プロジェクト進行の技術が身につく本」
- 「図解 これ以上やさしく書けない プロジェクトマネジメントのトリセツ」
- 「ひとつ上の GTD ストレスフリーの整理術 実践編」
- 「クラウド時代のタスク管理の技術」