2024-03-14

delivery management

2023 年末まで会社でやっていた役割が剥がれて 3 ヶ月程度経った。

どんなことを考えてやっていたのか、忘れないようにメモしておく。

前提

• 全体 100 人+、dev40 名程度のスタートアップ
• stream aligned team 的なチームが 7 つある
• 1 つのチームは…
  • 3~5 名の dev, 1~2 名の ux designer, 1 名の qa から構成される
  • 単一の project に取り組むこともあるが、複数の project を並走させたり、project 的でない粒度の小さい delivery をすすめたりする場合もある（※）
• 自分が担っていた役割は…
  • 1 つのチームの dev の取りまとめ
  • dual track agile における discover/delivery のうち delivery に関する説明責任を負う
  • （※の理由から）個人的には project management を包含する delivery management という概念を想定し、それを担う役割と考えている
• 本記事に現れる各種の役割は大いに会社固有だと思われる

やること

大きくは「進行管理」と「開拓」の 2 つ

進行管理

• チームに振られた各種トピック（project 未満の単位である場合もある）のそれぞれに関して背景や目的を把握する
• 大まかな見積もりを立てて 1 ヶ月程度単位で delivery 進行を組み立てる
• 適切にリスクをヘッジした形でスコープ/納期/リソースを見立て、ステークホルダーと合意をつくる
• チケットレベルのタスクに分解し、優先度をつけ、要件を明確にする
• タスク間の依存関係を同定する
• その過程でメンバーを巻き込み、チケットの自律的な遂行や動機づけのために必要なコミュニケーションをとる
• タスクをメンバーにアサインし、必要に応じてサポートする
• 逐次最新の状況に応じて優先度やタスクの依存関係を更新する
• スコープ/納期/リソースの更新の要否を判断し、更新が必要であればステークホルダーに調整をかけて合意をつくる
• project 全体に共通する開発基盤を整備する（テスト環境やテスト自動化方針など）
• チーム間の連携を行う（コンフリクトリスクの検知や助言の要請など）
• project 的 でなく小さな粒度のタスクに対しても適切にリソースを割り当て実行する（ex. 技術負債の解消や pj の初期スコープから外した改善など）
• その他メンバーが開発に集中できるよう、あらゆる球を拾う

開拓

• チームにおりてくるトピックは、初期的に ux designer が課題仮説/solution 仮説を検討し、一定程度固まると delivery の対象となる
• ux designer と deliver manager のこの境界が固定的で受け身だと、delivery の質もスピードも上がりくい
• よって、ux designer が検討している段階から、以下のことを行う
  • 情報をとる
    • ux designer が何を考えているのかを会話の中で探る
    • 呼ばれていない mtg を覗きにいったり、メンションされてないスレッドを追う
  • 先回りして動く
    • ありえそうな solution について、技術的な事前調査や見立て、場合によっては PoC を行う
    • ux designer の思考に役に立ちそうなデータの収集/分析を行い、提示する
• “開拓”する動きは、そのゴールやプロセスが明瞭でなく、それに従事していることを共有するデメリットがメリットを上回ることが多い
• そのためメンバーに対して明確に示さぬまま動き回ることも時に必要である
• そのような時間の使い方は以前のジュニアな段階では通常行わないため、意識的に実行する必要がある
• メンバーから見て多少動きが不透明であっても、上述の進行管理が適切に為され、開拓によるメリットが発生しているのであれば、メンバーからは「チームのために何か動き回ってくれているようだ」と認識し受け入れてもらえるはずだ