PART-Ⅰ・Ⅱで書いたのは、「考えることをやめた状態」がどう生まれるかという話でした。
今回はその続きになります。
現場で止まっているエンジニアを外から見ていると、あるパターンが繰り返し出てきます。スキルが足りないわけではありません。経験が浅いわけでもありません。むしろ10年・20年と現場を渡り歩いてきた人間が、ある時点から「動いているのに前に進まない」状態に入っています。
厄介なのは、止まっているのが個人だけではないことです。気づくとプロジェクト全体が謎の停滞に入っています。全員が動いています。会議も進んでいます。タスクも消化されています。なのにスプリントが終わるたびに「なんか進んでいない」という感覚だけが残ります。誰かをつかまえて「あなたが原因です」と言えるわけでもない。でも確実に、何かが詰まっています。
原因はスキルではなく、構造にあります。
SES現場には、特定の停滞を自然と生み出す構造があります。その構造の中に長くいると、止まっていることに気づきにくくなります。外から見て初めて「ああ、ここで詰まっているのか」とわかります。
この記事では、20年以上現場を見てきた中で見えてきた「プロジェクトが静かに止まるときの5つのパターン」を整理します。

共通点①：仕様の「決め方」を誰も教わっていない現場にいる

会議が終わっても何も決まらない。確認中のタスクが積み上がり続ける。この現象の根本には、「仕様をどう決めるか」というプロセス自体が現場に存在していないという問題があります。

何が起きているか

会議が終わりました。議事録も共有されました。なのに次の週、また同じ話をしています。「あの件、どうなりましたか」「確認中です」「いつ確認が取れますか」「少々お待ちください」——このやり取りが何週間も続くプロジェクトは珍しくありません。担当者が怠けているわけではありません。確認しようとしています。ただ、確認のゴールが決まっていません。何が決まれば前に進めるのかが、誰にも言語化されていません。

「検討します」がタスクになる

もう一つ、見落とされがちなパターンがあります。「持ち帰って検討します」「なるべく早めに処理します」という言葉が、そのまま作業タスクとして認知されてしまうケースです。発言した本人も、受け取った側も、それが「決定に向けたアクション」ではなく「タスクの一つ」として扱われます。結果として、検討することが目的になります。処理することが目的になります。何を決めるための検討なのか、何をもって処理が完了なのかが、誰にも問われないまま次の会議を迎えます。

なぜこうなるのか

SES現場では「作る役割」として参画するケースがほとんどです。仕様を決めるプロセスは発注側や上流工程が持つものという前提で、現場に入ります。その状態が数年・十数年と続くと、「仕様はどこかから降りてくるもの」という感覚が定着します。決め方を知らないのではなく、決める場に関与したことがないまま年数が経っています。「持ち帰る」「検討する」という言葉の中に、本来あるべき「いつまでに・何を・誰が決めるか」が含まれていないことに、誰も違和感を覚えません。

外から見るとこう見える

確認待ちが常態化しており、誰かが決めるまで動けない状態です。本人は動いているつもりです。タスクボードには「検討中」「確認中」の項目が並んでいます。ただ、それらは期限も決定基準も持たないまま滞留しています。プロジェクト全体が、誰かの決断待ちで静かに止まっています。

共通点②：責任の境界が現場内で言語化されていない

誰が何をどこまでやるのか。この問いに答えられる人間が現場にいないまま、プロジェクトが動いています。責任の境界が曖昧なままだと、問題が起きるたびにゼロから話し合いが始まります。

何が起きているか

「それ、うちの範囲ですか？」
この一言が出た瞬間、会議の空気が変わります。誰も悪くありません。ただ、誰も答えを持っていません。口頭で「よろしくお願いします」と言われた作業が、実際にどこまでの責任を伴うのかが最初から曖昧なままです。

PMOが管理ではなくリスケをしている

さらに問題を複雑にするのが、PMOやプロジェクト推進担当の動き方です。責任の境界が曖昧なまま作業が進み、スケジュールが遅れ始めたとき、確認されるのはこの一言です。
「WBSの期限までに完了できますか？　できなければリスケします。」
一見、進捗管理をしているように見えます。ただ、これは管理ではありません。期限を守るための障害を取り除くことも、責任の所在を明確にすることも行わず、遅れた事実だけを受け取って期限を書き換えています。リスケが繰り返されると、本来の期限からどれだけ遅延しているかが見えなくなります。最初の計画との乖離が数週間・数ヶ月に及んでいても、直近のリスケ後の期限を基準にするため、誰も遅延の深刻さを正確に把握できません。本来、スケジュールの期限をリスケすることは、特別な理由がない限り許されるべきではありません。ただ、「できなければリスケ」が選択肢として当たり前に存在している現場では、期限の重みが失われていきます。

認識合わせが計画されていない

そして、責任分界が曖昧なまま進むプロジェクトには、もう一つの構造的な問題があります。ステークホルダー間の認識合わせが計画されていないことです。
プロジェクトの序盤、各関係者が「自分はこういう理解で進めている」という前提を持ったまま作業が始まります。その前提のズレを早期に確認する場が設けられていないため、後工程になって初めて食い違いが表面化します。「そういう理解だったんですか」という会話が、設計が終わった後、あるいは実装が進んだ後に発生します。

予定外の帳尻合わせが工数を圧迫する

このとき発生するのが、予定外の帳尻合わせ作業です。本来であれば最初の認識合わせで防げた手戻りが、後工程で大規模な修正として跳ね返ってきます。設計書を書き直します。仕様を再定義します。場合によっては、初めからやり直しになります。この帳尻合わせの作業は、見積に含まれていません。誰かの工数を削って対応するしかなく、プロジェクト全体の余裕が一気に失われます。

なぜこうなるのか

多重下請け構造のSES現場では、責任分界を明文化するインセンティブが発注側にも受注側にもありません。明文化すると、どちらかが不利になる可能性があります。曖昧なままにしておく方が、その場の関係が保てます。ステークホルダーへの認識合わせも、「やった方がいい」とわかっていながら、誰の仕事にもなっていないまま省略されます。結果として、境界を引く文化が根づかない現場が生まれます。PMOやプロジェクト推進担当も、責任の境界を引く役割だという認識がないまま、進捗確認とリスケ調整だけを繰り返します。

外から見るとこう見える

何かトラブルが起きたとき、「それはどちらの範囲か」という話し合いがゼロから始まります。その話し合い自体に時間と労力が取られ、本来の作業が止まります。リスケが重なったWBSは、計画としての意味を失っています。帳尻合わせの作業が積み上がるたびに、現場の工数は圧迫されていきます。問題が起きる前に境界を引く習慣がないため、問題が起きるたびに同じことが繰り返されます。

PMBOK責任分界表｜理想と実態

表1は本来あるべき責任分界、表2はSES現場で起きがちな実態を示しています。

---

共通点③：成果物の完了定義が暗黙のままになっている

何が揃えば「完了」なのか。この定義がないまま作業が始まると、レビューのたびに終わりのゴールが変わります。誰も手を抜いていないのに、いつまでも終わらない状態がここから生まれます。

何が起きているか

「一旦動くものを作りました」
この報告の後、レビューで差し戻されます。理由を聞くと、前回とは違う指摘が返ってきます。何を直せば終わりなのかが、作る側にも確認する側にも共有されていません。次の差し戻しでまた別の指摘が来ます。終わりが見えません。
問題は、誰も意地悪をしていないことです。レビュアーはその都度、気になった点を正直に伝えています。作る側も、指摘された箇所をきちんと直しています。ただ、「これが揃えば完了」という定義がないまま作業が始まっているため、ゴールが毎回後から決まります。

レビュアーとレビュイーの観点が揃っていない

レビューの目的が言語化されていない現場では、レビュアーによって確認する観点がバラバラになります。ある人は動作確認を重視します。別の人は命名規則を見ます。また別の人は仕様との整合性を確認します。同じ成果物に対して、レビュアーが変わるたびに指摘の種類が変わります。作る側からすると、何を直せば本当に終わりなのかが最後までわかりません。

単体とITで確認すべき項目が整理されていない

この混乱をさらに深刻にしているのが、単体テストとITで確認すべき項目の区別がついていないことです。
単体で確認すべきことがあります。個々のモジュールや機能が、仕様通りに単独で動くかどうかです。ITで確認すべきことがあります。複数の機能やシステムが連携したとき、全体として正しく動くかどうかです。この二つは確認する観点も、確認するタイミングも、担当者も異なります。
ところが現場では、この区別が曖昧なまま進むことがあります。単体で潰しておくべき問題をITまで持ち越します。ITで初めて発覚した問題が、実は単体レベルの確認漏れだったということが起きます。ITの工程に入ってから単体レベルの修正が走り、結合の確認が止まります。どこで何を確認するかが整理されていないため、後工程になるほど問題の切り分けに時間がかかります。「これは単体の問題か、ITの問題か」という議論から始まり、原因の特定だけで半日が過ぎることがあります。

有識者はタスクだらけでレビューができない

さらに問題を深くしているのが、レビューを誰が担当するかという現場の力学です。
有識者には自然と仕事が集中します。設計も、判断も、調整も、気づけば特定の人間に集まっています。その結果、本来レビューを担うべき有識者がタスクだらけでレビューをしている時間を取れない状態になります。「手の空いているやつがやればいい」という判断が下され、レビュー作業はスキルの低い担当者へ回されます。
この判断が起きる背景には、レビューが「直接進捗を動かす作業」として見えにくいことがあります。コードを書く、設計書を埋める、テストを実行する——こうした作業は進捗として目に見えます。一方、レビューは何かを生み出しているように見えません。結果として、優先度が下げられます。

形だけのレビューが問題を引き起こす

スキルの低い担当者がレビューを担うとき、何が起きるか。
担当者本人も、上層部も、そのレビューに実質的な責任を持てないことを暗黙のうちに理解しています。担当者は責任を持ちたくありません。上層部は「あの担当者のレビューでは担保できない」と思っています。その認識が一致しているにもかかわらず、レビューというプロセスだけが形として消化されます。承認の印が押されます。完了の記録が残ります。ただ、中身は確認されていません。
この形だけのレビューが後工程で問題を引き起こします。見落とされた仕様の矛盾が、実装の終盤や結合テストの段階で表面化します。そのとき修正にかかるコストは、レビュー時点で発見した場合の何倍にも膨らんでいます。

なぜこうなるのか

SES現場では「動けばよい」という暗黙の完了基準が定着しやすい構造があります。完了の定義を作業開始前に合意する文化がないため、「終わった」の基準が人によって、タイミングによって変わります。単体とITで確認すべき項目を整理しないまま工程が進むため、問題の発見が遅れ、修正コストが膨らみます。レビューの目的と観点を事前に揃える習慣がなく、誰がレビューするかも成り行きで決まります。完了定義を作ること自体が、誰の仕事にもなっていません。

外から見るとこう見える

作業は終わっています。ただ「終わった」と言えない状態が続いています。差し戻しのたびに手戻りが発生し、スケジュールが後ろにずれていきます。単体で潰せていなかった問題がITで噴出し、工程をまたいだ修正対応が走ります。形だけのレビューを通過した成果物が後工程で問題を起こし、そのたびに予定外の修正作業が発生します。誰も手を抜いていません。ただ、完了の定義がないまま動いているため、問題が起きる構造だけが静かに積み上がっています。

共通点④：「聞ける相手」の構造的な不在

詰まったとき、誰に聞けばいいかわからない。SES現場では、技術的な相談を安全にできる相手が構造的に存在しにくい状況があります。この「聞けない構造」が、現場に二つの問題を同時に生み出します。

何が起きているか

詰まっています。聞きたいことがあります。ただ、誰に聞けばいいかわかりません。
上長に聞くと「それは自分で考えて」と返ってきます。隣のメンバーに聞くと「私もわからない」と言われます。発注側に聞こうとすると「窓口を通してください」と言われます。窓口に投げると、返答が来るまで数日かかります。その間、作業は止まっています。
詰まっていることは自覚しています。ただ、聞く先がありません。結果として、自分の中で抱えたまま、何となく動き続けます。

聞く側と聞かれる側の非対称な負担

ここに、見落とされがちな構造的な問題があります。聞く側にとっては「聞けばいい」で完結しますが、聞かれる側にとって最もストレスになるのは、聞き手が自分で考えようとしないことです。
やり取りはこういう形になります。
「何をすればよいですか？」「これをしてください」「しましたがエラーが出ました」
ここで終わりです。エラーが出た事実を報告して、次の指示を待ちます。自分でエラーの内容を調べる、原因を考える、試してみる——そこには進みません。考えることをやめてしまっています。

深夜障害が露わにするもの

実際に起きた話を書きます。
深夜に障害の連絡が入りました。監視サービスのオペレーターから電話で叩き起こされました。

オペレーター：「エラーが発生しました」
「どんなエラーかわかりますか？」

オペレーター：「どこを見ればわかりますか？」
「ログに何か出ていませんか？」

オペレーター：「インテル インサイドって書いてあります」
「……それ、あなたが使っている作業端末のシールですよね。ログを見てください」

オペレーター：「どうやって見ればよいですか？」
「まずサーバーへログインしてください」

オペレーター：「どうやってログインすればよいですか？」
「……もういいです。今から現場に向かいます」

深夜に叩き起こされ、電話口でこのやり取りをして、それでも自分が現場に向かうことになりました。障害対応の責任を負っているのは自分だからです。オペレーターは「エラーが発生しました」と報告した時点で、自分の仕事を終えています。
これが極端な例だと思う人がいるかもしれません。ただ、程度の差はあっても、構造は同じです。「わかりません」を起点に思考を止め、次の指示を待つ。その先に何が起きているかを、自分ごととして考えない。この動き方が許容されている現場では、必ずどこかに「深夜に現場へ向かう人間」が生まれます。

なぜこうなるのか

SESは現場に常駐していても、組織的には孤立しています。技術的な相談を安全にできる関係が、社内にも現場にも作りにくい構造があります。同じ会社の先輩・上司は別の現場にいます。現場のメンバーは別会社の人間です。どちらにも「踏み込んで聞く」のが難しい距離感があります。
その距離感の中で、「聞けばなんとかなる」という行動パターンが定着した人間と、「自分で考えて動く」ことを求められ続けた人間の間に、埋めようのない溝が生まれます。考えることをやめた側は気づきません。考え続けている側だけが、その溝の深さを知っています。
聞かれる有識者の側は、この繰り返しをいつしか「無駄な時間」と割り切るようになります。教えることへの意欲が失われていきます。それだけではありません。不満の根本には、もっと深い非対称さがあります。同じ現場に、同じ条件で入っています。にもかかわらず、「わかりません」が免罪符のように機能している人間がいます。一方で有識者は、判断を求められ、品質の担保を求められ、何か問題が起きたとき矢面に立たされます。同じ現場にいながら、負っているものがまったく違います。

外から見るとこう見える

詰まっても発信しない人と、詰まりを丸ごと投げる人が、同じ現場に混在しています。前者は問題を抱え込んでプロジェクトを止め、後者は有識者の時間を削ってプロジェクトを止めます。どちらの方向からも、静かに止まっていきます。有識者が疲弊するほど、現場全体の判断力が落ちていきます。止まっている原因が「聞き方の構造」にあると気づくのに、時間がかかります。

共通点⑤：論点整理を「誰かの仕事」だと全員が思っている

会議を重ねても何も決まらない。その原因の多くは、論点を整理して引き取る役割が現場内に存在しないことにあります。特定の条件が重なったとき、この問題はさらに深刻になります。

何が起きているか

会議が発散します。1時間話して、決まったことがありません。次回また同じアジェンダで集まります。
誰もさぼっていません。全員が意見を出しています。ただ、出た意見を整理して「論点はここです、決めるべきはこれです」と引き取る人間がいません。発言は続きます。時間だけが過ぎます。
終了5分前に「では次回までに各自確認しておきましょう」という着地になります。次回も同じです。

PMが途中で変わったプロジェクトで起きること

この状況が特に深刻になるのが、何らかの事情でPMが途中交代したプロジェクトです。
前任のPMが持っていた文脈、判断の経緯、関係者間の合意内容——これらは引き継ぎ資料に残っていないことがほとんどです。後任のPMは「自分が決めていいのか」という判断を常に迫られます。前任者が決めたことを覆すリスクを取りたくありません。結果として、決められるべきことが「確認中」のまま宙に浮きます。論点整理は誰かがやるべきことのまま、誰もやりません。

当時のメンバーがいないリニューアル案件で起きること

過去のシステムのリニューアル案件では、さらに別の問題が加わります。
当時の設計判断がなぜそうなったのかを知っているメンバーが、現場にいません。ドキュメントには「こういう仕様です」と書いてあります。ただ、「なぜそうなったのか」は書いていません。リニューアルの過程で「この仕様、変えていいのか」という論点が出てきます。変えていい理由も、変えてはいけない理由も、誰も説明できません。
全員が「それは自分が判断することではない」と思っています。当時を知っている人間がいないため、誰かが引き取ることへの根拠が持てません。論点は宙に浮いたまま、作業だけが先に進みます。後工程で「なぜこうなっているのか」が問題になったとき、答えられる人間が現場にいません。

なぜこうなるのか

論点整理やファシリテーションはPMやリーダーの仕事という暗黙の前提があります。その役割が機能していないとき、他の誰かが引き取る文化がありません。「それは自分の仕事ではない」という認識が全員の中にある状態では、論点は宙に浮いたまま次の会議に持ち越されます。
PMが交代したプロジェクトでは、その前提がさらに崩れます。誰が論点整理の責任者なのかが、組織的にも役割的にも不明確になります。リニューアル案件では、過去の経緯という「本来あるべき判断の根拠」が最初から欠落しています。どちらの場合も、現場の構造が論点を誰も引き取れない状態を自然に生み出しています。

外から見るとこう見える

整理する人間が現場内にいないため、会議を重ねるほど論点が増えていきます。決まらないまま作業が進み、後工程で矛盾が出てきます。その矛盾の解消に時間が取られ、またプロジェクトが止まります。PMが交代したプロジェクトでは、止まるたびに「前任者はどう考えていたのか」という議論が始まり、答えが出ないまま時間が過ぎます。リニューアル案件では、誰も説明できない仕様がそのまま次のシステムに引き継がれます。止まっている原因が「決まっていないこと」だと気づくのに時間がかかります。気づいたころには、決め直すコストが最初の何倍にも膨らんでいます。

おわりに

5つのパターンを並べると、こう感じる人がいるかもしれません。「結局、個人の意識や能力の問題ではないか」と。そうではありません。仕様の決め方を知らないのは、決める場に関与させてもらえなかったからです。責任の境界を引かないのは、引く文化がない現場にいるからです。完了定義を作らないのは、作ることが誰の仕事にもなっていないからです。考えることをやめてしまったのは、考えなくても回る構造の中に長くいたからです。論点を誰も引き取らないのは、引き取るべき役割が機能していないからです。どれも、現場の構造が生み出しているパターンです。

10年ぶりにSES案件に入って見えたこと

今回、10年ぶりにSES案件に携わる機会がありました。知人からのヘルプ要請で参画した案件でしたが、抜け際になって気づいたことがあります。気づけば論点整理も仕様整理も責任の切り分けも、すべて一人で引き受けていました。「この人がいないと回らない」という状態が、いつの間にか出来上がっていました。
抜けようとすると引き伸ばしにかかってきました。理由を聞いてみると、「ビープロさんが抜けるなら、他のメンバーも引き上げてください」という話になっていました。
そのとき、嫌気が差したのは引き止めそのものではありませんでした。構造への違和感でした。

SES構造の歪み

エンジニアが責任を背負い込むことで、間に入るエージェントが利益を得る仕組みになっています。ただ、本来の筋はむしろ逆ではないかと思っています。仕事を処理するエンジニア側が適切な対価を受け取り、エージェントはその流通を支援することで取り分を得る。その順番が、SESの構造ではどこかで逆転しています。
責任だけが現場に集まり、利益は別のところに流れていく。この歪みが、現場を静かに止めていく構造の根っこにあると感じています。

構造は内側からだけでは変えにくい

論点が整理されていない現場で、論点を整理しようとしても、どこから手をつければいいかがわかりません。責任の境界が曖昧な現場で、境界を引こうとしても、引く根拠が持てません。外から見て初めて、「ここで詰まっている」とわかります。
プロジェクトが謎の停滞に入ったとき、原因は特定の誰かではなく、現場の構造にあることがほとんどです。
次のPART-Ⅳでは、Shellが止まっている現場を外から見たとき、何が見えるのかを書きます。論点整理・仕様整理を外から行うとはどういうことか、具体的に整理します。