開発PJが詰まると、決まって出てくる言葉があります。「今週だけ踏ん張ろう」「人を張れば何とかなる」「まずは手を動かそう」です。現場が必死になる場面はありますし、炎上や火消しそのものを否定したいわけでもありません。
ただし、それを通常運転にしてはいけません。マネジメントの仕事は、人の根性を煽るのではなく、遅れや手戻りを生む条件を減らすことです。
- 優先順位が曖昧
- 作業が大きすぎる
- レビュー待ちが見えない
- 意思決定が遅い
- 完了条件が曖昧
こうした課題を放置したまま「頑張ろう」で前に進めるのは、課題の解決ではなく、マネージャーの不始末をプレイヤーに押し付けてるだけです。
この記事では、スクラム、カンバン、計画駆動(DORA)特有の話は除外します。代わりに、それらを引き合いに出しつつ共通して現れる原則だけを抜き出して、開発PJをどう進めるべきかを整理していきます。
根性を前提にしたマネジメントは、短期的に見えて長期的に遅い
根性論の怖いところは、効いているように見えることです。誰かが夜まで残れば、その日のチケットは閉じます。仕様の曖昧さも、その場の判断で一応つながります。ですが、そのやり方は、遅延の原因を見えなくする副作用があります。
健康面の代償はすでにかなり明確です。WHOとILOは、週55時間以上働く人について推計を公表しています。週35〜40時間働く人に比べ、脳卒中のリスクは35%高く、虚血性心疾患による死亡リスクは17%高いという内容です。2016年には、長時間労働が脳卒中と虚血性心疾患による74.5万人の死亡につながったとしています。根性論は、少なくとも健康コストを前提にしています。 WHOとILOの発表
フローの面でも同じです。DORAは、仕事が多すぎて人が足りないとき、初心者の管理者ほど複数タスクを同時に抱えさせがちだと説明しています。その結果、作業完了は遅くなり、チームは燃え尽きます。つまり「遅れているから同時着手を増やす」は、直感に反して流れを悪くする最悪の判断です。 DORAの仕掛り制限ガイド
言い換えると、根性論は努力の話ではありません。マネジメントで解決すべき課題を人間の耐久力でカバーしています。だから危ないのです。
手法が違っても、残る原則はほぼ同じ
開発手法の議論は、儀式や用語の違いに引っ張られがちです。ですが、公式ガイドの中身を読むと、管理上の骨格は驚くほど似ています。
Scrum Guideは、複雑な仕事を扱うための土台として「透明性」「点検」「適応」を置いています。仕事と意思決定の根拠を見えるようにし、頻繁に点検し、ずれたら早く修正するという考え方です。 Scrum Guide
Kanban Guideの核は3つです。フローを定義して見えるようにすること、フローの中にある作業を能動的に管理すること、フローそのものを改善することです。要するに、今どう流れているかを見えるようにし、その流れを詰まらせないよう管理し、仕組み自体も改善するという整理です。 Kanban Guide
DORAもかなり近いことを言っています。小さいバッチ、価値が届くまでの流れの可視化、仕掛り制限は、ソフトウェアデリバリー性能だけでなく、組織パフォーマンスも予測する能力として扱われています。 DORAの小さいバッチ DORAの流れ全体の可視化 DORAの研究プログラム案内
ここから抜き出せる共通原則は、だいたい次の5つです。
何を達成するのかを先に定める
目標が曖昧なPJでは、人は忙しさを進捗と勘違いします。Scrum Guideでも、製品として目指す目標や、その短い期間で達成する目標を先に言語化してから作業を選ぶ構造をとっています。Kanban Guideでも、まず価値の単位と、どこから始まりどこで終わるのかを定義します。
フローを見えるようにする
見えないものは管理できません。Scrumは透明性を、Kanbanは作業のフローの可視化を、DORAは価値が届くまでのフロー全体の見える化を重視します。設計待ち、レビュー待ち、テスト環境待ち、意思決定待ち。こうした待ち時間を見える形で置かない限り、管理者は「なぜ遅いのか」を判断できません。
作業を小さく切る
Scrum Guideでは、スプリント内の作業を1日以下の粒度まで分解することがよくあると説明されています。DORAも、小さい作業単位は数時間から2日程度で完了できる大きさが望ましく、1週間を超える作業単位は大きすぎるとしています。大きい作業は、実装よりも「分からなさ」を抱えたまま進む時間を増やします。
同時着手を増やしすぎない
Kanban Guideは仕掛りを明示的に制御するよう求めています。DORAも、仕掛り制限はフローを改善し、可視化と組み合わせるとソフトウェアデリバリー性能の改善に効くと述べています。人を空けないために次の仕事を積むマネジメントは、合理的に見えてパフォーマンスを著しく低下させます。
短い周期で見て、ずれたらすぐ変える
Scrumの点検と適応、Kanbanのフローの改善は、どちらも「計画を守り切る」より「ズレを早く知って早く直す」を重視しています。開発PJは、最初の見積もりを当てるゲームではありません。誤差が出る前提で、誤差の扱い方を設計する仕事です。
基礎的な開発PJは、こう進める
ここからは、手法論をいったん抜きにして、最低限の進め方としてまとめます。小さな受託でも、自社開発でも、同じです。
最初に決めるべき5つのこと
最初に決めるべきものは多くありません。最低限、次の5つです。
- 何を達成したら成功か
- いつまでに何を出すか
- 品質の下限はどこか
- 今回は何をやらないか
- 誰が最終判断をするか
この5つが曖昧なまま走ると、現場は作業しながら定義を補うことになります。これはマネジメントの重大な負債です。初期の数時間で決めるべきことを放棄すると、確実に30~40時間で払う負債になるので、絶対に怠けてはいけません。
仕事を1週間未満に区切る
実装項目、設計項目、調査項目のどれでも、1件が長すぎると状況が読めなくなります。目安としては、できれば数時間から2日程度、長くても1週間未満です。DORAもそのくらいの粒度を推していますし、Scrum Guideも日単位まで落とす考え方を採用しています。
もし1週間を超えるなら、次のどれかです。
- 仕事が大きすぎる
- 依存関係が多すぎる
- 完了条件が曖昧
- 先に決めるべきことが未確定
この状態で「まず着手」は、根性論です。先に仕切り直しをしたほうが、結果的に早く仕事が進みます。
フロー全体を1枚で見えるようにする
見える化のやり方は難しくありません。仕事を「着手前」「作業中」「レビュー中」「テスト中」「リリース待ち」「停止中」といった段階ごとに分けて、いまどの仕事がどこで止まっているか分かるようにするだけです。形式はチームに合っていれば十分ですが、着手中の仕事と待ち状態の仕事は区別できるようにします。
ここで大事なのは、作業者の頑張りではなく、待ちを見えるようにすることです。DORAは、アイデアから顧客成果までの流れを可視化し、着手から完了までにかかった時間や、やり直しの多さを見ることを勧めています。ボトルネックは、たいてい実装者の手元より、その前後の待ちにあります。 DORAの流れ全体の可視化
仕掛りを人数より増やさない
メンバーが4人なら、開発中のステータスが8件も並んでいる時点でおかしいです。全員が2件ずつ持つと、レビュー待ち、確認待ち、切り替えコストが膨らみます。Kanban Guideは仕掛りの量を制御することを必須要素にしていますし、DORAも、同時進行中の作業量を絞ることはフロー改善の基本だとしています。
どこかの段階で仕事がたまって先へ進まないなら、未着手の仕事に着手するのではなく、止まっている仕事を先に動かします。例えばレビュー待ちが多いなら、実装を増やすよりレビューを片付けます。テスト環境がなくて止まっているなら、環境準備を急ぎます。意思決定待ちなら、決める人を呼んでその場で詰まりを解消します。マネージャーの役目は、仕事の並列数を増やすことではなく、止まっている仕事がまた前に進む状態を作ることです。
短い周期で「進捗」ではなく「ズレ」を見る
毎日の短い確認で見るべきなのは、何時間働いたかではありません。見るのは次です。
- 目標に対して何が終わったか
- いま最も古い仕掛りは何か
- どこが詰まっているか
- 今日、誰の判断が必要か
- 何を切れば全体が前に進むか
Kanban Guideは最低限のフローの指標として、仕掛りの量、完了件数、着手してからの経過日数、着手から完了までの時間の4つを挙げています。つまり、管理者が見るべきなのは、人のパフォーマンスではなく、流れの状態です。 Kanban Guide
週次では利害関係者も交えて確認します。確認対象は4つです。
- 目標
- 未解決のリスク
- 切るもの
- 次に出すもの
会議の目的は安心感の確保ではありません。あるべき流れから、現状とのズレを早く見つけることです。
残業は例外処理に閉じ込める
残業をゼロにできない局面はあります。障害対応、法改正対応、外部締切など、本当に例外的な事情はあります。問題は、それが定常化しているかどうかです。
残業を認めるなら、最低でも次をセットにします。
- いつ終えるかを決める
- なぜ発生したかを記録する
- 代休や早退で回復時間を確保する
- 再発防止として何を変えるかを決める
ここまでやって初めて、残業は例外運用になります。これがなく、ただ「しばらく大変だけど頑張ろう」で回すのは、管理ではありません。WHOとILOの数字を見れば、長時間労働は無料のバッファではないと分かります。 WHOとILOの発表
マネージャーが毎日するべき問い
根性論のPJでは、問いが間違っています。
- 誰が頑張るか
- 誰に追加で持たせるか
- どこを土日で巻き返すか
仕組みで進めるPJでは、問いが変わります。
- 何がフローを詰まらせているか
- 何をやめたらフローが進むか
- どの判断待ちが一番コストになっているか
- 作業単位は大きすぎないか
- 完了の定義は揃っているか
現場の覚悟を否定する必要はありません。ただし、覚悟を前提にしたマネジメントは早急にやめるべき。根性が必要になる瞬間はあっても、根性がないと成立しないPJは、最初からPJととして破綻しています。
おわりに
開発PJを前に進める力は、人の気合ではなく、流れを整える仕組みから生まれます。目標を揃える。仕事を小さくする。待ちを見えるようにする。仕掛りを絞る。短い周期で見直す。残業は例外に閉じ込める。手法が何であれ、ここはあまり変わりません。
仕組みでゴリ押すべきなのは、人ではなく、課題のほうです。根性論は最後の最後に使う非常口であって、正当化してはいけません。
