gantt
開発のリードタイムを短くしたいという話は、たいてい「作業を速くしよう」という結論に流れます。ところが実際に日数を分解すると、手が動いている時間よりも、順番を待っている時間のほうが長いことが珍しくありません。この記事では、開発のリードタイムをどこからどこまで数えるのかという線引きから始めて、測る手順、短縮の方法、そして短くしようとしたときに壊れるものまでを順に並べます。
先に言葉を揃えておきます。開発のリードタイムという言い方は、業界によって指す範囲が違います。同じ会議で違う意味のまま話していると、短縮の打ち手がかみ合いません。
製造業の文脈では、次のように説明されることが多い言葉です。
開発リードタイムとは、製品の企画・設計から実際に開発に取り掛かるまでの期間を指します。新しい製品を世に出す際、アイデアを形にするまでにかかる時間と考えるとわかりやすいかもしれません。 出典: cct-inc.co.jp
つまり、着手までの助走を含めた期間です。設計や試作の検討、社内の承認、部門をまたぐ調整。手を動かし始める前の段取りが、ここに入ります。
ソフトウェアや受託の制作では、もっと狭い意味で使われることがあります。1つの依頼が入ってから、それが動く形で世に出るまでの期間です。さらに細かく、着手してから完了までを別の言葉で呼び分けている現場もあります。
どちらが正しいという話ではありません。困るのは、片方が「着手前の待ちを含む期間」の話をしているのに、もう片方が「手を動かしていた期間」の話で返すときです。前者を縮めるには承認や段取りに手を入れる必要があり、後者を縮めるには人と技術に手を入れる必要があります。打ち手を当てる場所が別なので、最初に範囲を合わせてください。
合わせ方は難しくありません。ホワイトボードに1本の線を引いて、依頼が来た日、着手した日、出した日の3点を書き込みます。この3点のうちどの区間を数えるのかを、その場で決めるだけです。区間の名前は社内で通じる言い方で構いません。
リードタイムを分解して驚かれるのがこの点です。ある案件の日数を、待っていた日と手が動いていた日に分けると、待ちのほうが長くなることがよくあります。
待ちが生まれる場所は限られています。前の案件が終わるのを待っている、決める人の返事を待っている、他部署の作業を待っている、必要な素材や情報を待っている。この4つでほぼ説明が付きます。
ここに、稼働率と待ちの関係が絡みます。担当者の予定を隙間なく埋めると、1件あたりの待ちは必ず伸びます。全員の手が常にふさがっている状態では、新しく入ってきた依頼は、誰かの手が空くまで列に並ぶしかありません。列が長くなるほど、並んでいる時間がリードタイムに積み上がります。
だから、稼働率を上げる取り組みと、リードタイムを短くする取り組みは、同じ方向を向いていません。片方を追うともう片方が悪くなります。どちらを優先するのかは、その組織が何で評価されているかによります。納期の約束を守ることが最優先なら、あえて手を空けておく設計が要ります。
とりまとめる立場で先にやるべきなのは、待ちの日数を見える形にすることです。案件ごとに、依頼が来た日と着手した日を記録するだけで足ります。この差が平均10日を超えているなら、作業の速さに手を入れる前に、列の長さに手を入れたほうが効きます。
測り始める前に決めることが2つあります。着手をどう定義するか、完了をどう定義するか。ここが曖昧なまま集計すると、数字が揺れて比べられません。
着手の定義でよく揉めるのは、調査や見積りを着手に含めるかどうかです。含める方式なら、依頼を受けた時点から数え始めます。含めない方式なら、見積りが承認された時点から数えます。どちらでも構いませんが、途中で変えないでください。変えた前後で比べると、改善したように見えるだけの数字が出ます。
完了の定義はもっと揉めます。作った人が「できた」と言った時点、確認が終わった時点、出した時点、相手が使い始めた時点。この4つは、案件によって数日から数週間ずれます。どこを完了にするかで、短縮の打ち手も変わります。確認が終わった時点を完了にすると、確認の待ちが自分たちの数字に入るので、確認を早める働きかけが自然に始まります。
決めた定義は、記録を残す場所の脇に書いておいてください。半年経つと、誰も覚えていません。カードの説明欄や、板の運用の手引きに1行書いておけば十分です。
もう1つ、除外する期間を決めておくと数字が落ち着きます。相手の都合で止まっていた期間、年末年始のような一斉の休み、仕様が白紙に戻った期間。これらを含めた数字は、改善の対象として扱えません。ただし除外しすぎると実態から離れるので、除外した日数も別に記録しておくのが無難です。除外の合計が全体の3割を超えたら、そこが本題だという合図です。
大がかりな仕組みは要りません。次の4つで測れます。
ステップ1、記録する日付を3つに絞る。 依頼が来た日、着手した日、出した日。この3つだけを、案件ごとに必ず残します。項目を増やすと、記録する人が付いてきません。工程ごとの開始と終了を全部残そうとした現場は、2週間で誰も更新しなくなると言われています。
ステップ2、案件の単位を揃える。 大きな案件と小さな案件を同じ表に並べると、日数の差が規模の差なのか、進め方の差なのか分かりません。規模で3つくらいに分けて、その中だけで比べてください。分け方は工数の見込みで構いません。
ステップ3、2か月分そろえてから見る。 1週間や2週間では、たまたま重なった案件の影響が消えません。最低でも2か月、できれば四半期分をそろえてから見ます。急いで結論を出すと、季節の波を改善の成果と勘違いします。
ステップ4、分布で見る。 平均だけを見ると打ち手を間違います。詳しくは後の節で扱いますが、見るのは長いほうの端です。
この4ステップで大事なのは、記録が自動で残る形にすることです。人が別の表に転記する作りにすると、忙しい週に穴が空きます。穴が空いた月は比べられないので、そこまでの努力が無駄になります。仕事を進める場所そのものに日付が残る形を選んでください。
待ちが原因だと分かったら、打ち手は限られます。
決める場面を前に寄せる。 着手してから決まっていなかったことが出ると、そこで止まります。止まっている間、その案件は列に戻ります。製造業では、この考え方が前倒しの設計として整理されてきました。
従来のウォーターフォール型開発では、企画・設計・試作を経てから製造部門の出番になるので、開発リードタイムが長くなり、市場投入が遅れるという大きな課題がありました。さらに開発リードタイムが長期化すれば、開発コストも膨れ上がります。 出典: keyence.co.jp
後工程の担当者を、前の段階の打ち合わせに呼ぶ。これだけで、あとで戻ってくる指摘が減ります。
並行できるものを並行にする。 順番に並んでいる工程のうち、本当に前が終わらないと始められないものはどれかを確かめます。慣習で順番になっているだけの工程が混ざっていることが多いです。
案件を小さく割る。 大きな1件を小さな3件に割ると、最初の1件が早く出ます。全部が出そろう日は変わらなくても、相手が確認を始められる日が前に来ます。確認が前に来れば、直しも前に来ます。
承認の待ちに期限を付ける。 返事を待つ期間そのものに、あらかじめ日数を決めておきます。3営業日で返らなければ担当の判断で進める、という取り決めを先に作る。取り決めがないと、待ちは無限に伸びます。
着手の同時本数に上限を決める。 手をつけている案件の数を増やすと、1件あたりは必ず遅くなります。同時に進める本数を先に決めて、それを超えたら列に並ばせる。この上限を守ると、1件あたりの日数が縮みます。全体の本数が減るわけではありません。
リードタイムを縮める目的を、速さそのものにしないでください。縮んだ結果として手に入るものが3つあります。
約束ができるようになる。 日数が安定すると、相手に期限を言えます。「だいたい1か月です」ではなく「多くは3週間で、長いときは5週間です」と言える。この差は信用に直結します。安定していない状態でいくら急いでも、約束はできません。
手戻りが減る。 出すまでの期間が短いと、相手の確認が早く入ります。早く入れば、方向のずれが小さいうちに直せます。期間が長い案件ほど、出した時点でのずれが大きくなります。
人の入れ替わりに強くなる。 1件が数か月かかる進め方では、途中で人が抜けたときの引き継ぎが重くなります。1件が数週間で閉じる進め方なら、抜ける影響が小さい範囲に収まります。
この3つは、どれも速さの話ではありません。予測できることの価値です。とりまとめる立場の人が上に説明しやすいのも、速くなったことより、ばらつきが小さくなったことのほうです。
急ぎすぎたときに何が起きるかも、先に知っておいてください。
確認の工程が削られる。 一番削りやすいのがここです。削ると、当面の日数は縮みます。代わりに、あとで戻ってくる件数が増えます。戻ってきた分は次の案件の列に割り込むので、他の案件のリードタイムが伸びます。全体では悪化します。
記録が残らなくなる。 急いでいるときほど、決めた理由が残りません。半年後に同じ議論をやり直すことになります。
人が同時に持つ本数が増える。 「早く出せ」と言われた担当者は、待っている案件にも手を付け始めます。同時に持つ本数が増えると、切り替えの時間が積み上がって、1件あたりはさらに遅くなります。急がせたことが原因で遅くなる、という形です。
数字だけが良くなる。 完了の定義が緩いままだと、完了に印を付けるのが早くなるだけのことが起きます。定義を先に固める話をしたのは、このためです。
短縮の取り組みを始めるときは、同時に見る指標をもう1つ用意してください。戻ってきた件数、または出したあとに直した件数です。この数が増えているなら、日数が縮んでいても改善ではありません。
記録の保存先は、大きく4つに分かれます。
表計算。 誰でも作れて、最初の1か月はこれで足ります。弱いのは、1人が開いている間に他の人が書けないことと、日付を手で入れる作業が続かないことです。案件が月20件を超えたあたりから、記録の穴が目立ち始めます。
課題管理の道具。 1件ごとに状態が変わった日時が自動で残るので、測るには向いています。設定の自由度が高い分、最初に決めることが多く、開発以外の職種が混ざるチームでは入力が続かないことがあります。
ボード型の道具。 列を移した日時が残るので、待ちと作業の境目が取れます。日々の進行と測定が同じ場所で済むのが強みです。案件の期間を横に並べて見たいときは、横棒の表示があるかを確かめてください。列の形と横棒の形を行き来できるかどうかで、使い勝手が変わります。機能で絞らず、区切るのは人数とボードの数だけという料金の考え方なら、記録のために席を減らす判断をしなくて済みます。何ができるかはできることのページで、区切りの単位は料金のページで確かめられます。
専用の計測の道具。 日数の分布や工程ごとの滞留を出すことに特化した道具もあります。既に別の道具で記録が残っている場合の上乗せとして向きます。記録が無い状態で入れても、出すものがありません。
いま使っている道具を変えるかどうかの判断は、機能表の比較よりも、記録が自動で残るかどうかで決めたほうが早いです。他の道具との違いは比較の一覧にまとまっています。すでにボードで進行を管理しているなら、Trelloからの移行のように既存のカードをそのまま運べる経路があるかも見ておくと、移る手間の見積りが立ちます。
集計の仕方で結論が変わります。ここは注意が要る場所です。
案件の日数を並べると、ほとんどが短い側に集まって、少数が長い側に伸びる形になります。この形のとき、平均は実態を表しません。長い側の数件に引っ張られて、多数派の実感とずれた数字が出ます。
見るべきものは2つです。真ん中の値と、長いほうの端です。 真ん中の値は、多数派がどのくらいで終わっているかを示します。長いほうの端は、約束できる上限を示します。相手に期限を伝えるときに使うのは、平均ではなく端のほうです。
そして改善の対象は、端にいる案件です。多数派が2週間で終わっていて、一部が10週間かかっているなら、見るのは10週間の案件です。何が違ったのかを1件ずつたどると、同じ原因が並びます。よく出るのは、依頼の時点で決まっていなかったことがある、途中で担当が変わった、他部署の返事を待った、の3つです。
平均を追う取り組みは、多数派をさらに短くする方向に向かいます。そこは既に短いので、伸びる余地が小さい場所です。端を短くする取り組みのほうが、全体のばらつきに効きます。
記録を取るだけで終わっている現場が多いので、使い道も決めておいてください。
見積りの根拠にする。 似た規模の過去の案件が、実績で何日かかったか。その分布をそのまま見積りの根拠に使います。担当者の勘で出した日数より、過去の分布のほうが当たります。勘は、手が動く時間しか数えないので、待ちが抜け落ちます。
約束の言い方を変える。 「2週間で出します」ではなく「多くは2週間、遅くとも4週間で出します」と言う。幅を先に伝えると、遅れたときの説明が要らなくなります。幅を出すには分布が必要で、分布には記録が必要です。
列の長さを相手に見せる。 依頼が来た時点で、いま何件並んでいるかを伝えます。割り込みを頼む相手も、列の長さが見えていれば、何を後ろに回すかを一緒に決められます。見えていないと、全部を最優先で頼まれます。
振り返りの題材にする。 長かった案件を月に1件ずつ取り上げて、どこで待ったかだけを確かめます。人を責める場にしないために、見るのは日付だけにしてください。よくある疑問への答え方はよくある質問のような形で社内にも残しておくと、同じ説明を繰り返さずに済みます。
同じ言葉で測っていても、待ちが生まれる場所は仕事の形によって違います。打ち手を選ぶ前に、自分たちがどの形なのかを確かめてください。
受託の制作。 待ちの大半が相手側に発生します。素材が届かない、確認の返事が来ない、検収が動かない。自分たちの手を速くしても縮まらない部分が、最初から含まれています。だからこの形では、契約や見積りの条件に確認の期限を入れられるかどうかが、そのままリードタイムに効きます。見積りの段階で「素材の支給は着手の3営業日前まで」「初稿の確認は5営業日以内」と書けるなら、待ちの上限を先に決められます。書けない相手の案件は、日数の見込みを別枠で持つのが安全です。
社内の開発。 待ちの出どころは優先順位の決め直しです。要望を受け付ける窓口が複数あると、列の順番が人によって違って見えます。営業から直接頼まれた件と、会議で決まった件が並んでいて、どちらが先か誰も言えない。この状態では、着手までの日数が読めません。受付の窓口を1つにまとめるだけで、待ちの日数のばらつきが落ち着きます。
兼務が多い少人数のチーム。 運用の対応や問い合わせが割り込みます。割り込みは記録に残りにくいので、リードタイムが伸びた原因として説明できません。割り込みが入った日だけでもカードに残しておくと、月末に「この週は割り込みで2日分消えていた」と言えるようになります。人を増やす相談をするときの材料にもなります。
外部の協力者が入る場合。 相手の稼働日が週の何日かに限られていると、待ちが構造として発生します。金曜に依頼すると次の稼働日まで動かない、という形です。この場合は、依頼を出す曜日を相手の稼働日の前日に合わせるだけで、1件あたり数日縮みます。手を速くする話ではなく、渡す日を合わせる話です。
3つの日付で全体の日数が見えたら、次は1段だけ細かくします。細かくするのは1段だけにしてください。それ以上割ると、記録する人が付いてきません。
割り方は4つで足ります。決める、作る、確かめる、出す。この4つの間で日付を残すと、どこが太っているかが分かります。工程の境目は、担当が変わるところで区切ってください。受け渡しが起きるたびに待ちが生まれるので、受け渡しの場所と工程の境目を合わせると、待ちがどの工程に属するのかで揉めなくなります。
見るのは各工程の滞留日数です。4つに分けると、たいてい太っている工程は1つか2つに絞られます。よくあるのは、決める工程と確かめる工程です。作る工程が一番長いと思われていて、実際に測ると3番目だったという結果が出ることも珍しくありません。
あわせて受け渡しの回数も数えてください。1つの案件で担当が5回変わるなら、待ちが生まれる場所が5か所あります。回数を減らせるなら、そのほうが個々の待ちを短くするより効きます。担当をまたがずに1人で通せる範囲を広げる、という打ち手がここから出ます。
注意したいのは、工程ごとの数字を人の評価に使わないことです。使った瞬間に、日付の記録が実態から離れます。確かめる工程が長いと分かったとき、見るのは確かめる人の速さではなく、確かめる人に渡る前の状態です。渡されたものが荒いと、確認は必ず長くなります。
測り始めると必ず出てくるのが、途中で仕様や範囲が変わった案件です。ここの扱いを決めていないと、集計する人が毎回迷って、月によって数え方が変わります。
考え方は2つあります。1つは、変更が入った時点で元の案件を終わりにして、新しい案件として数え直す方式です。日数は短く出ますが、実際に相手が待った期間は隠れます。もう1つは、同じ案件として日数を伸ばす方式です。実態には近い代わりに、長い側の端が変更のあった案件で埋まって、進め方の問題が見えにくくなります。
現実的なのは、同じ案件として伸ばしつつ、変更が入った印だけをカードに残す方式です。集計のときに、印が付いている案件と付いていない案件を分けて見られます。分けて見ると、変更のあった案件だけが長いのか、変更が無くても長いのかが判別できます。前者なら手を入れる場所は仕様の固め方で、後者なら進め方です。
判別できるようにしておく価値は高く、変更が入る割合そのものも見えてきます。案件のうち4割以上に変更の印が付いているなら、着手の判断が早すぎる可能性があります。決まっていないうちに始めているので、あとで戻ってきます。この場合の打ち手は、着手の条件を1つ増やすことです。決めておくべき項目の一覧を作って、全部そろってから着手する。始まりが遅くなるように見えて、全体の日数は縮みます。
変更を歓迎する進め方をしている場合は、別の数え方に切り替えてください。案件全体の日数ではなく、1回の受け渡しにかかった日数を測ります。変わることが前提なら、全体の期間を短くする目標は立てられません。1回の往復を短くすることだけが、手元で改善できる範囲です。
資料や記事に出てくる「平均で何日」という数字は、そのまま目標に使えません。理由は3つあります。
定義が違う。 着手をどこから数えているか、完了をどこにしているかが書かれていない数字は、比べる相手になりません。この記事の前半で定義の話を長く書いたのは、社外の数字と混ざることを防ぐためです。
業種と規模が違う。 製造業の開発リードタイムと、受託の制作の日数は、桁が違います。同じ言葉で語られていても、含まれている工程が別です。
良い数字だけが公開される。 社外に出る事例は、うまくいった案件が選ばれています。分布の長いほうの端は、たいてい書かれていません。
比べる相手は、自分たちの過去の数字にしてください。同じ定義で、同じチームで、前の四半期と比べる。これだけが、改善したかどうかを言える比べ方です。公開されている調査を参考にするときは、情報処理推進機構のような公的な機関の資料で、調査の対象と定義が書かれているものを選んでください。定義が読めない数字は、会議で引用しないほうが安全です。
目標の決め方も、外の数字ではなく自分たちの分布から決めます。長いほうの端が10週間なら、次の四半期の目標は8週間です。多数派の2週間を1週間にする目標は、達成しても全体のばらつきに効きません。どこを目標にするかで、取り組みの向き先が変わります。
最後に、記録が1つの板に集まっていると何が見えるようになるのかを整理します。
列ごとの滞留日数。 カードが今の列に入ってから何日経ったか。これが見えると、どの工程で詰まっているかがその場で分かります。集計を待たずに、朝見た瞬間に分かるのが利点です。滞留が長いカードに印を付けておくと、会議の議題がそのまま決まります。
着手前の列の長さ。 着手していないカードが並んでいる列の枚数を数えるだけで、次に入ってくる依頼が何日待つかの見当が付きます。枚数が増え続けているなら、受ける量と出す量が釣り合っていません。
横棒で見る後工程への影響。 1件が遅れたときに、後ろの案件がどれだけずれるか。期間を横棒で並べて見ると、その場で分かります。横棒をドラッグして開始日と締切を動かせる形なら、遅れが分かった時点で調整の相談を始められます。日数の計算をやり直してから相談する形だと、相談が数日遅れます。
待ちの原因の分類。 止まった理由をカードに一言だけ残しておくと、月末に並べたときに原因の偏りが出ます。決める人の返事待ちが多いのか、素材待ちが多いのか。偏りが分かれば、手を入れる場所が1つに絞れます。
同じ依頼元の傾向。 依頼元ごとに待ちの日数を並べると、返事が早い相手と遅い相手が分かれます。遅い相手には、確認の期限を契約や見積りの条件に入れる相談ができます。相手を責める話ではなく、段取りを合わせる話として持ち出せます。
記録の保存先そのものの安心。 案件の日付や社外との取り決めが残る場所なので、誰がどこまで見られるかは先に確かめてください。考え方は安全性の考え方のページにまとまっています。
なお、いまの進め方のままでよい場合もあります。案件が月に3件で、担当が2人で、待ちがほとんど発生していない。この条件なら、測る手間のほうが大きくなります。測り始める目安は、依頼が来てから着手するまでの待ちが月に合計30日分を超えているかどうかです。超えているなら、そこに縮められる余地が残っています。
別のものです。納期は相手と約束した期日で、リードタイムは依頼から完了までに実際にかかった期間です。リードタイムの分布が分かっていないと、納期は勘で決めることになります。過去の実績の真ん中の値と長いほうの端を見てから、余裕を持たせた期日を約束するのが安全です。
最初は必要ありません。依頼が来た日、着手した日、出した日の3つを案件ごとに残せば測れます。表計算でも始められます。案件が月20件を超えて記録に穴が空き始めたら、進行を管理する道具の中で日付が自動で残る形に移すことを検討してください。
日数の分布が偏っているためです。多くの案件が短く終わり、一部が極端に長いとき、平均は多数派に寄って短く出ます。現場の実感は長い案件のほうに残るので、ずれが生まれます。真ん中の値と、長いほうの端の両方を見てください。
同時に手を付ける案件の本数に上限を決めることです。上限を超えた分は着手前の列に並べます。手を広げる案件が減ると、1件あたりの日数が縮みます。あわせて、承認の返事を待つ期間に3営業日などの区切りを設けると、止まる時間が減ります。