進捗管理とは?進捗状況の意味から、測る単位・報告の粒度・遅れを早く見つける仕組みまで【2026年版】

「進捗を聞いても『順調です』しか返ってこない」——開発を外部のチームに任せている方から、こうした相談をよく受けます。週次の定例では問題なしと報告され、管理表の進捗率も伸びている。それなのに、リリースの1か月前になって「テストが終わりません」と告げられる。報告を疑いたくはないが、同じことをまた繰り返すのではないかと不安になる。進捗管理という言葉は誰もが使いますが、その中身が定義されないまま運用されている現場は少なくありません。

結論から言うと、進捗管理とは「仕事の進行状況を把握し、日々の進み具合を調整する活動」です。生産管理用語の規格にもこの定義が置かれています。大事なのは「調整する」まで含まれている点で、見て記録するだけなら進捗管理ではなく、工程表の書き写しにすぎません。そして、遅れが報告されない原因のほとんどは相手の怠慢ではなく、何をもって完了とするかが決まっていない、進捗率が自己申告である、悪い知らせを上げる経路がない、という構造にあります。

この構造が分かると、やるべきことは3つに絞れます。完了の定義を決めること、測る単位を小さくすること、遅れの基準と上げ先を先に決めておくことです。報告の回数を増やす必要はありません。むしろ、この3つが決まっていれば報告は軽くできます。逆に3つを決めないままツールだけを導入すると、入力作業が増えて誰も表を見なくなる。「進捗管理は意味がない」と言われる現場は、たいていここでつまずいています。

本記事では、進捗・進捗状況・進行状況という言葉の意味と工程管理・進行管理との違い、遅れが報告されない5つの構造、進捗を測る3つの単位(タスク完了率・出来高・バーンダウン)と使い分け、報告の粒度と頻度の設計と遅れを早く見つける仕組み、そして離れた拠点で実際にどう運用しているか、よくある質問の順に解説します。進捗管理表の項目は最低限の6つに絞り、表そのものの作り方は扱いません。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社のご相談に乗ってきました。「進捗が見えない」というご相談で実際に困っているのは、報告の回数ではなく報告の中身です。この記事を読み終えるころには、自社の進捗管理で最初に決め直すべき一点が見つかるはずです。

進捗管理とは——「進捗」「進捗状況」の意味と、工程管理・進行管理との違い

進捗管理という言葉は、業種を問わず日常的に使われています。それだけに、人によって指している範囲が違い、同じ会議の中で噛み合わないまま議論が進むことが珍しくありません。まずは言葉の意味を押さえ、混同されやすい工程管理・進行管理・プロジェクト管理との関係を整理します。ここを片づけておくと、後半の「何をどう測るか」がそのまま自社のルールになります。

進捗・進捗状況・進捗率の意味——「進む」と「捗る」を合わせた言葉

進捗は「しんちょく」と読み、「進む」と「捗る(はかどる)」を組み合わせた熟語です。単に時間が経過したことではなく、成果や完成に向けて実質的に前へ進んだことを指します。ここが「経過」との違いで、3か月作業を続けても作るものが決まっていなければ、進捗はゼロということがあり得ます。

進捗状況は、その進み具合が現在どういう状態にあるかを含めて表した言葉です。「進捗は70%」のように数値で言い切るのが進捗率、「一部の機能で遅れが出ているが全体は予定どおり」のように状態まで説明するのが進捗状況、と考えると使い分けやすくなります。本記事では進捗率を、あるタスクや工程がどこまで終わったかを数値化したものと定義して使います。ただし後述するとおり、この数字は完了の定義がなければ意味を持ちません。

規格の定義では「把握」だけでなく「調整」まで含む——見るだけなら書き写し

もう少し厳密な定義を見ておきます。生産管理の用語は日本産業規格 JIS Z 8141「生産管理用語」に番号付きで収録されています(現行は JIS Z 8141:2022。2022年3月22日改正、日本産業標準調査会 審議・日本規格協会 発行の規格票で有効であることを確認)。この規格では進捗管理も用語として定義されており、本記事では「仕事の進み具合を把握し、日々の調整を行う活動」という意味で使います。規格本文は有償で公開されているため、正確な定義文は規格そのものでご確認ください。

注目すべきは「調整する活動」という一句です。定義の後半に調整が入っている以上、遅れを見つけた後に誰が何を決めるのかが決まっていなければ、進捗管理は半分しか成立していません。朝礼で工程表に赤ペンを入れる作業を進捗管理と呼んでいる現場は多いのですが、それは状況の書き写しであって、調整ではないのが実情です。遅れが赤く見えていても、決裁が翌週の会議まで動かないのであれば、早く気づいたことが成果に変換されません。

工程管理・進行管理・プロジェクト管理との違い(比較表)

生産管理の分野では、工程管理は生産統制の言い換えとして使われ、その内側に現品管理・余力管理・進捗管理の3機能が並ぶ整理が一般的です。つまり工程管理と進捗管理は横並びの選択肢ではなく、工程管理が進捗管理を含む入れ子の関係にあります。ただし実務の会話では、工程管理が計画の立案から改善までを指すことがあり、話す人によって範囲が二段階ずれます。

社内文書や要件定義書では、規格に寄せて「工程管理の中の進捗管理」と書いたほうが、後の混乱が少なくなります。一方で、計画を引く人と現場を回す人が同じ担当者である小さな組織なら、呼び分けを持ち込まないほうが速く動けます。区別が必要になるのは、要件定義書を書くとき、部門や会社をまたいで責任を分けるとき、そして投資の効果を説明するときの3場面だと考えてください。

社内は「進捗」、社外への報告は「進行状況」——進捗確認の聞き方と答え方

言葉の使い分けにも触れておきます。進捗は簡潔で専門的な表現として、社内の定例やチャットで頻繁に使われます。一方、進行状況はより説明的で丁寧な表現で、顧客への報告書や役員への説明といったフォーマルな場面で使われます。「進捗どう?」は社内向け、「進行状況をご報告します」は社外向け、という程度の理解で十分です。

進捗確認の場面では、聞き方が返ってくる答えを決めます。「進捗はどうですか」と聞けば「順調です」しか返ってきません。「今週終わったチケットはどれで、残っているのはどれですか」「今つまずいていることは何ですか」と聞けば、事実が返ってきます。答える側も同じで、「順調です」ではなく「20件中14件がレビュー済み、残り6件のうち2件は外部APIの仕様待ち」と書けば、相手が判断できます。言葉を丁寧にすることよりも、事実の粒度を上げることのほうが、はるかに関係を良くします。ではなぜ、多くの現場でその事実が上がってこないのか。次章で構造を分解します。

なぜ遅れは報告されないのか——進捗が見えなくなる5つの構造

進捗が見えない現場の話を聞くと、報告が来ていないケースはほとんどありません。報告は毎週届いていて、管理表も更新されている。それでも遅れが直前まで分からない。原因を担当者の意識に求めても再発します。見えなくなるのには構造があり、その構造を1つずつ外していくほうが確実です。ここでは5つに分けて整理します。

遅れが報告されない5つの構造(一覧表)

5つのうち1と2が根っこで、3・4・5はそれを増幅させる条件です。順番としては、まず完了の定義を決め、次に自己申告に頼らない測り方へ移し、それから報告の経路と頻度を整える。この順序を逆にすると、報告の書式だけが増えて中身が変わりません。

完了の定義がないと進捗率は90%で止まる——90%症候群

進捗管理でもっともよく見る現象が、進捗率が90%から先に進まない状態です。いわゆる90%症候群と呼ばれます。本記事では、提唱者や原典をたどれる学説としてではなく、現場で繰り返し観測される現象の呼び名としてこの言葉を使います。起きている中身は単純で、何をすれば完了なのかが決まっていないために、進捗率が90%のまま動かなくなる、ということです。

なぜ90%で止まるのか。実装そのものは全体の作業のうち半分程度で、残りはレビュー、結合、テスト、指摘の反映、ドキュメントの整備です。ところが作業者の感覚では「コードを書き終えた=ほぼ終わり」なので、90%と申告してしまう。そこから先の残り半分が数字に現れないため、90%のまま時間だけが過ぎます。

対策は単純で、完了を「動いた」ではなく「第三者が確認できた状態」で定義することです。レビュー済みか、テストが通っているか、受け入れ基準を満たしているか。この定義を先に決め、満たすまでは進捗を0%か100%のどちらかでしか数えない、という運用にすると、90%症候群はほぼ消えます。中間の数字を許すから、中間で止まるわけです。

悪い知らせほど上がってこない——叱責が報告を遅らせる

構造の3つ目は人の問題ですが、感情論ではなく設計の問題として扱えます。遅れが生じたときに担当者が叱責されたり、担当者の作業を上長が取り上げて代行したりすると、次から遅れは報告されなくなります。報告のコストが上がるためです。当社が離れた拠点で開発を回してきた経験でも、遅れの報告が止まる原因の多くは、遅れそのものより、遅れを伝えたあとに何が起きるかの予想にあります。

発注者と受注者の関係では、これがさらに強く働きます。受注側にとって遅れの報告は、責められるだけでなく、次の契約に響くかもしれない情報です。当社にご相談にみえる方の中には「遅れを隠されていたのではないか」と疑っている方がいますが、多くの場合、隠したというより「報告してよい形式と閾値が決まっていなかった」だけです。「◯日以上の遅れが見込まれたら、原因と見込みだけを翌営業日までに一報する」と決めておき、その一報に対しては原因追及ではなく打ち手の相談から入る。これだけで、上がってくる速さが変わります。

私が受けた相談に共通するもの——「順調です」が3か月続いた後の2か月遅延

私は2018年からホーチミンで約100社の開発体制のご相談に乗ってきましたが、進捗の相談にはよく似た形があります。週次の定例で3か月間「順調です」と報告を受け続け、リリースの1か月前になって「テストが終わらない」と告げられ、結果として公開が2か月遅れる。話を分解すると、決まって同じ2つが欠けています。1つ目は完了の定義で、実装が終わった時点を完了として数えていたこと。2つ目は測り方で、進捗率が担当者の申告だったことです。

逆に言えば、この2つを決めるだけで大半は防げます。報告の回数を週1から週3に増やしても、数え方が主観のままなら、主観が週3回届くだけです。数える単位を変えることが先で、頻度の設計はその後。次章では、進捗を何で測るのかを3つの単位に分けて整理します。

進捗を測る単位——タスク完了率・出来高・バーンダウンの使い分け

進捗を「何%」で語る前に、その%が何を数えた結果なのかを決める必要があります。実務で使われている測り方は、大きく3つです。どれが優れているという話ではなく、案件の性質と、報告を受け取る相手が何を知りたいかで選びます。3つを比べたうえで、どれを選んでも先に決めなければならない共通の前提を示します。

3つの測り方の比較表(何を数えるか・向く場面・落とし穴)

補助的に使われる図もあわせて押さえておきます。本記事でガントチャートと呼ぶのは、縦軸にタスク、横軸に日付を取り、計画と実績を上下に並べて差分を一目で見せる図のことです。同じくカンバンと呼ぶのは、「未着手・進行中・完了」といった列にカードを移し、どこで作業が滞留しているかを見せる形式のことです。どちらも数え方そのものではなく、数えた結果を見せる形式だと理解しておくと、選定で迷いません。

実務では、日々の運用をタスク完了率で回し、経営層への月次報告で出来高を使い、反復開発のチーム内ではバーンダウンを見る、という併用が現実的です。1つに絞る必要はありませんが、同じ数字を複数の場所で別の数え方をすると混乱します。どの場面でどれを使うかを最初に決めておいてください。

測る前に「完了の定義」を決める——レビュー済みか、テスト済みか、リリース済みか

3つのどれを選んでも、先に決めるべきことは同じです。1件を「完了」と数える条件、いわゆる完了の定義です。これが曖昧だと、どんな測り方を採用しても数字は主観になります。

定義の作り方は難しくありません。開発であれば、次のうちどこまでを完了とするかを決めるだけです。(1) 実装が終わった、(2) コードレビューが通った、(3) 単体テストが通った、(4) 結合テストと受け入れ確認が通った、(5) 本番にリリースされた。当社では原則として(2)のコードレビューが通った状態を作業者側の完了とし、Gitのプルリクエストが承認されて取り込まれたことをもって1件と数えています。そのうえで、受け入れ確認の完了はお客様側の判断としています。

もう1つの決め事は、中間の数字を許さないことです。0%か100%のどちらかでしか数えない運用にすると、90%症候群が起きません。「半分終わった」と言いたくなるタスクは、半分に割ってください。割れないなら、それは完了条件が決まっていない証拠です。

測る単位を小さくする——1〜3日で終わる粒度に割ると遅れが翌日に出る

完了の定義を決めたら、次は粒度です。WBS(Work Breakdown Structure)は作業を階層的に分解する手法ですが、どこまで分解するかの基準がないと、分解した気になって終わります。当社が離れた拠点で開発を回すときの基準は明快で、1件が1〜3日で終わる大きさまで割ることにしています。業界の標準としてどこかで定められた数字ではなく、遅れを翌日に表面化させるために当社が置いている運用上の基準です。

なぜこの粒度かというと、遅れが表面化する速さが変わるからです。1件が2週間のタスクなら、遅れは早くても2週間後にしか分かりません。1件が2日なら、翌日には「終わるはずのものが終わっていない」という事実が立ち上がります。遅れを早く見つける仕組みの半分は、この粒度の設計で決まります。

粒度を小さくすると管理が重くなるのではないか、と心配されることがあります。実際は逆で、見積もりの精度が上がるため、手戻りと再計画の回数が減ります。ただし、割ったタスクの1件ごとに報告を求めると本末転倒です。粒度は細かく、報告は集約する。この組み合わせが要点で、報告の設計は次章で扱います。粒度を決めずにツールだけ導入するのは、失敗のもとです。

報告の粒度と頻度を設計し、遅れを早く見つける仕組みを作る

測る単位が決まったら、次はその数字をいつ、誰が、どの粒度で見るかの設計です。ここを決めずに「毎日報告してください」と言うと、報告のための作業が増え、数か月で形骸化します。頻度を上げるほど実態には近づきますが、報告の負荷で入力の質が落ちる。この二律背反は、頻度ごとに見るものを分ければ解消できます。

日次・週次・月次で見るものを分ける(設計表)

日次はあくまで非同期で軽く、会議にしないのが要点です。毎朝30分の会議を開くと、参加者全員の時間が毎月10時間以上消えます。日次に必要なのは合議ではなく、止まっているものが可視化されることだけです。逆に週次は、報告のためではなく決めるための場にします。事前に読めば分かる情報を会議で読み上げるのは、時間の使い方として要注意です。

遅れを早く見つける4つの仕組み——先行指標、しきい値とエスカレーション、未完作業、動くもの

頻度を設計したうえで、遅れを検知する仕掛けを4つ入れます。

1つ目は先行指標を見ることです。完了件数は結果であり、遅れは後から分かります。先に動くのは、着手したまま3日以上完了していない件数、レビュー待ちで滞留している件数、仕様の確認待ちで止まっている件数です。この3つが増え始めた時点で、完了件数が落ちる前に手を打てます。

2つ目はしきい値とエスカレーションを先に決めることです。遅れを見つけても、誰が何を決めるかが決まっていなければ調整は始まりません。「遅れが見込まれた段階で開発リーダーがその日のうちに作業順を入れ替える」「作業順の入れ替えでは吸収できない遅れになったら発注側の担当者に一報し、優先順位の入れ替えかスコープの調整を判断する」「日程の前提が崩れる遅れになったら責任者会議で日程そのものを引き直す」。この3段階を、どの程度の遅れをどの段にあてるかという日数まで含めて契約や体制の合意時に決めておくと、遅れの報告が事故報告ではなく手続きになります。日数は案件の期間と体制で変わるため、自社の過去の実績から決めてください。

3つ目は未完作業で見ることです。完了した分ではなく、これから必要な作業量と工数を見積もり直します。進捗80%より「残り12件・約15人日」のほうが、終わりの見込みを判断できます。

4つ目は動くもので見ることです。報告書ではなく、実際に動く画面や機能を定例で見る。デモが出せない週が2回続いたら、何かが止まっています。報告の文章は取り繕えますが、動くものは取り繕えません。

進捗管理表に最低限必要な6項目——テンプレートより先に決めること

表の形式に悩む前に、最低限どの列が必要かだけ押さえておきます。(1) タスク名(1〜3日で終わる粒度)、(2) 担当者、(3) 完了予定日、(4) 状態(未着手・着手中・レビュー待ち・完了)、(5) 完了の定義を満たしたかの確認欄、(6) ブロッカーと確認待ちの相手。この6つがあれば、日次の把握と週次の差分は取れます。

列を増やすほど記入率は下がります。進捗率のパーセント欄、実績工数、コメント欄などは、使う目的がはっきりしてから足してください。表の作り方とテンプレートについては「進捗管理表 テンプレート」の記事で別途扱います。

ツールに頼る前に決める4つのこと——定義・粒度・頻度・決める人

進捗管理ツールは、更新と共有を速くします。ただし、速くなるのは「決まっていること」だけです。決まっていないものを入れると、入力の手間が増えるだけで終わります。導入の前に、次の4つを文章で書けるか確かめてください。

1つ目は完了の定義。どの状態をもって1件を完了と数えるか。2つ目は粒度。1件あたり何日で終わる大きさに割るか。3つ目は頻度。日次・週次・月次で何を見るか。4つ目は決める人。遅れが出たときに、作業順の入れ替え、優先順位の変更、日程の引き直しを、それぞれ誰が決めるか。

この4つが書けていれば、ツールは何でもそれなりに機能します。書けていなければ、どのツールを入れても同じ場所でつまずきます。自社の進捗管理で、今この4つのうち何が書けていないでしょうか。

離れた拠点での進捗管理の実務——オフショア開発で当社がやっていること

ここまでの設計は、チームが同じ部屋にいても離れていても変わりません。ただし、離れている場合は前章の5つ目の構造——「聞かれなければ言わない」——が強く働きます。対面なら雑談のついでに漏れてくる不安が、非同期のチャットでは上がってきません。当社がベトナム・ホーチミンの開発チームで実際にやっていることを、4点に絞って紹介します。なお、オフショア開発全体の進め方は「オフショア開発 進め方」の記事、役割分担をどこまで任せられるかは「システム開発 外注 丸投げ」の記事で扱っています。

時差2時間と日本人PMのフロント——その日のうちに調整できる距離

ベトナムと日本の時差は2時間で、日本の午前10時はホーチミンの午前8時です。日本の営業時間とほぼ重なるため、午前中に見つけた遅れをその日のうちに調整できます。進捗管理の定義に「調整する活動」が含まれる以上、この距離の短さは運用上の意味を持ちます。欧州や南米の拠点のように半日ずれる体制では、1往復に1日かかり、同じ設計をしても検知から調整までが倍に伸びます。

体制は2パターンをご用意しています。パターンAは日本人PMまたはブリッジSEをフロントに置き、その後ろにエンジニアを配置する形で、進捗管理の観点では推奨です。パターンBはエンジニアのみで、発注側にPMがいる場合に選ばれます。パターンAでは、日々の状況把握とチーム内の作業順の調整を日本人PMが巻き取るため、発注側にお願いするのは週次の判断が中心になります。日本人PMの役割そのものは「オフショア開発 日本人PM」の記事に詳しく書いています。

週次の定例でお客様に決めていただくのは、優先順位と「何をもって完成とするか」

当社の週次定例で、お客様に決めていただくことは2つに絞っています。次の1〜2週間で何を先にやるかという優先順位と、今作っているものを何をもって完成とするかという受け入れの判断です。報告を聞いていただく時間ではなく、決めていただく時間として設計しています。

介護記録SaaS「CareViewer」の開発では、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、要件が動くことを前提に、この週次の優先順位判断を続けて継続開発しています。要件が固まりきらない段階で始まるサービス開発では、計画を精緻に作り込むより、判断の場を毎週持つほうが結果的に速く進むというのが実情です。

Gitのプルリクエストとチケットで、自己申告に頼らない進捗にする

日々の進捗は、担当者の申告ではなく記録から読みます。当社ではコードレビューをGitのプルリクエストで標準化しており、承認されて取り込まれたプルリクエストの数と、チケットのステータスが進捗の実体です。加えて、日本人PMによる設計レビューとリリース前のダブルチェックを品質の仕組みとして置いています。

この形にすると、進捗率を聞く必要がほとんどなくなります。レビュー待ちで滞留している件数、着手から3日以上動いていない件数といった先行指標も、同じ場所から取れるためです。エンジニアはグループで保有する2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインしており、協力会社を経由しないため、誰が何をしているかが商流の途中で見えなくなることもありません。

向く案件と向かない案件も、正直にお伝えしておきます。向くのは、継続的に開発があり、週1回は優先順位を判断できる方が発注側にいる案件です。向かないのは、要件が確定していて変更の余地がなく、完成した成果物だけを受け取りたい案件と、週次の判断に出られる方が社内にいない案件です。後者は、進捗管理の仕組みをどれだけ作っても、調整の意思決定が誰にも割り当てられないまま止まります。仕組みは判断を速くしますが、判断そのものを代わりにはできません。

進捗管理に関するよくある質問

進捗管理について、ご相談の場で繰り返し聞かれる質問を5つにまとめました。社内のルールづくりの参考にしてください。

Q1. 進捗管理と工程管理はどちらが上位の概念ですか?

生産管理の分野では、工程管理は生産統制の言い換えとして使われ、その内側に現品管理・余力管理・進捗管理の3機能が置かれます。したがって工程管理が進捗管理を含む関係です。ただし実務では工程管理が計画の立案まで含む語として使われることがあるため、要件定義書や社内規程では範囲を書き添えてください。進行管理は制作・広告業界での用法が多く、全体の統括を指します。

Q2. 社外への報告では「進捗状況」と「進行状況」のどちらを使うべきですか?

どちらでも失礼にはなりません。一般には、進捗は簡潔で社内向き、進行状況はより説明的で社外向けのフォーマルな場面に向くとされます。迷うなら「進行状況をご報告します」で始めれば無難です。ただし、言葉より中身が重要です。「順調です」ではなく「20件中14件が完了、残り6件のうち2件は仕様のご確認待ち」と書いてください。

Q3. 進捗率が90%から動きません。どうすればよいですか?

完了の定義を決め直してください。実装が終わった状態を完了として数えていると、レビュー・テスト・指摘反映という残り半分が数字に出ません。完了を「第三者が確認できた状態」に定義し、中間の数字を使わず0%か100%でのみ数える運用に変えると、この現象はほぼ解消します。あわせて、1件を1〜3日で終わる粒度まで割ってください。

Q4. 定例は週1回で足りますか?

週1回の定例だけで進捗を把握しようとすると、遅れの発覚が最大で1週間遅れます。日次はチケットのステータスと止まっている件の共有を非同期で行い、週次の定例は決めることに使う、という分担にしてください。会議を増やすのではなく、日次を会議にしないことが要点です。

Q5. 進捗管理ツールを導入すれば解決しますか?

ツールが速くするのは、すでに決まっていることの更新と共有です。完了の定義、粒度、頻度、遅れが出たときに決める人。この4つが文章で書けていない状態で導入すると、入力の手間が増えて数か月で使われなくなります。決めるのが先、道具はその後。

まとめ: 進捗管理は「完了の定義・粒度・上げ先」の3つの取り決めから始まる

進捗管理とは、仕事の進行状況を把握し、日々の進み具合を調整するところまでを含む活動です。生産管理用語の規格でも定義の後半に「調整する活動」が置かれており、見て記録するだけなら工程表の書き写しにすぎません。言葉の使い分けとしては、社内では「進捗」、社外への丁寧な報告では「進行状況」が選ばれますが、言葉を整えることよりも、報告に載る事実の粒度を上げることのほうが効きます。

遅れが報告されない原因は、相手の怠慢ではなく5つの構造にあります。完了の定義がない、進捗率が自己申告である、悪い知らせを上げる経路がない、計画が更新されない、離れた拠点では聞かれなければ言わない。外し方の順序は決まっていて、まず完了を「第三者が確認できた状態」で定義し、1件を1〜3日で終わる粒度に割り、日次は非同期で止まっているものだけを見える形にし、週次の定例は決めるための場にする。そのうえで、遅れのしきい値と上げ先を3行で決めておけば、遅れの報告は事故報告ではなく手続きになります。ツールを比べるのは、この4つ(定義・粒度・頻度・決める人)を文章で書けてからで十分です。

離れた拠点が相手でも、設計そのものは変わりません。当社では日本との時差2時間を活かして日本人PMがフロントに立ち、週次の定例ではお客様に優先順位と「何をもって完成とするか」を決めていただき、日々の進捗はGitのプルリクエストとチケットという記録から読んでいます。一方で、要件が確定していて成果物だけを受け取りたい案件や、週次の判断に出られる方が社内にいない案件には向きません。オフショア開発全体の手順はオフショア開発の進め方、日本人PMがどこまで巻き取れるかはオフショア開発の日本人PMもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、進捗をどう可視化するかの設計と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。