前回のPART-Ⅲでは、現場が「動いているのに前に進まない」5つの構造的な理由を整理しました。今回はその中で最も具体的な形として表れやすい問題を取り上げます。設計書はある、仕様もある、担当者もいる。それでも作業が進まない。SES現場でよく見るこの状態の正体を、実体験をもとに整理します。

ShellはJavaやPythonのようなアプリケーション開発言語とは位置づけが異なります。サーバー上でのバッチ処理、ログ整理、定期実行、ファイル操作——インフラエンジニアであれば、業務の中で自然に使いこなしているはずの技術です。「Shellがわからない」は、アプリエンジニアであれば許容されることがあっても、インフラエンジニアにとっては本来そうであってはならない領域です。

ところが、直近まで参画していた現場で、インフラ担当のメンバーがShellの作業で手が止まっていました。話を聞くと、スキルの問題だけではないことがすぐに分かりました。仕様は口頭でしか共有されておらず、Shellを読み解く手がかりになる資料すら存在していませんでした。確認しようにも誰に聞けばいいかも分からない。書けないのではなく、書き始める前提が根本から崩れていたのです。「Shellができない」と「Shellを書く前提が崩れている」は、まったく別の問題です。

この記事では、シェルから目を背け続けることで現場に何が起きるのか、その実態を20年以上の経験をもとに整理します。

「Shellが止まっている」と「Shellがわからない」は別の問題

Shellの作業が止まる理由は、コードが読めないことだけではありません。

このセクションでは、「止まっている」と「わからない」を混同したまま進んでいる現場が、どういう状態にあるのかを整理します。

Shellが書けない現場と、Shellを書く前提が崩れている現場は違う

「Shellが止まっている」という報告を受けたとき、多くの現場では「担当者のスキルが足りないのではないか」という方向で話が進みます。しかし外から見ると、問題の根はもう一段深いところにあります。
直近まで参画していた現場で、スクリプト設計書は存在していました。項目も埋まっていました。しかし読んでも、このShellがなぜ必要なのか、何のシステムのどの処理を担っているのか、どの外部ファイルを読み込むのかが、どこにも書かれていませんでした。読み込む外部スクリプトの名前は日本語に置き換えられており、実際のファイルとの対応がとれません。ドット（.）コマンドで読み込む隠しファイルへの記載は一切なく、設計書を見ても存在すら気づけない状態でした。

問題は、その設計書を使って作業していた担当者が、それを「問題のある設計書だ」と認識していなかったことです。Shellの構造を理解していないと、設計書に何が書かれるべきかが分かりません。書かれるべきものが分からなければ、何が欠けているかも分かりません。形が揃っていれば設計書として成立していると判断してしまいます。「設計書はある。でも作業が進まない。」この状態が続くのは、スキルの問題ではなく、設計書が設計書として機能しているかどうかを判断する基準そのものが担当者の中にないからです。

「誰に聞けばいいかわからない」本当の原因になっているケース

現場で手が止まっているエンジニアに話を聞くと、「誰に確認すればいいかわからない」という言葉が出てくることがあります。一見すると、コミュニケーションの問題に見えます。しかし実態は違います。
Shellを理解していない担当者は、自分が何を確認すべきかも分かっていません。設計書を読んでも、そこに何が足りないかが見えない状態と同じです。確認すべき論点が言語化できないため、誰かに聞こうにも「何を聞けばいいか」が分からないまま止まっています。「確認中です」という言葉が返ってくるとき、多くの場合は確認先を探しているのではなく、何を確認すべきかが整理できていない状態です。

さらに問題を複雑にするのが、聞かれる側の状況です。仕様を知っているはずの人間が、プロジェクトからすでにいなくなっていることがあります。残っているメンバーは「自分は把握していない」と言います。確認しようとしても「少々お待ちください」で止まったままになります。こうなると、設計書の不備を補完する経路そのものが失われています。聞けない、調べられない、設計書も読み解けない。この三重の詰まりが、Shellの作業を完全に止めます。あなたの現場で、仕様の持ち主が今どこにいるか、すぐに答えられますか。

「詰まっている箇所」と「決まっていない箇所」が別物として見える

現場の中にいると、「Shellの作業が進まない」という事実だけが見えています。なぜ進まないのかの原因が、技術的な詰まりなのか、仕様が決まっていないのか、設計書が機能していないのかが、混然とした状態になっています。担当者本人も、自分がどこで止まっているのかを正確に説明できないことがほとんどです。

さらにこの状況を悪化させるのが、PMOの動き方です。進捗を管理する立場にあるPMO自身も、Shellの構造を理解していないことがあります。なぜ詰まっているのかの原因が分からないまま、「なぜ進まないのか」「いつ終わるのか」という問いだけが担当者に向かいます。担当者は原因を説明できない。PMOは原因を理解できない。その状態で進捗確認だけが繰り返されます。傍から見ていると、詰まっている担当者がさらに追い詰められていく構図になっていて、問題の解決ではなく消耗だけが進んでいきます。

外から入ると、この混然とした状態を切り分けることができます。詰まっているのか、決まっていないのか。設計書が機能していないのか、仕様の持ち主がいないのか。原因の種類が違えば、対処の順番が変わります。この切り分けができない限り、担当者への圧力を強めても現場は動きません。外から見て初めて見える景色が、ここにあります。

外から入って最初にやること——まず「何が決まっていないか」を出す

「外から整理する」という言葉は抽象的に聞こえますが、実際にやることは具体的な作業です。このセクションでは、整理という行為を動作レベルで分解します。何を、どの順番で確認するのかを見ていきます。

入力・出力・対象ファイル・実行タイミングを一覧に落とす

外から入って最初にやることは、Shellに関わる情報を一覧に落とすことです。確認する項目は決まっています。このShellは何を受け取るのか（入力）。何を出力するのか（出力）。どのファイルを対象にするのか（対象ファイル）。いつ実行されるのか（実行タイミング）。この4項目を起点に、レビュー・承認者まで含めた整理シートを一枚作ります。

ここで重要なのが、この整理シートを図解まで落とすことです。文字だけの一覧では、現場の担当者には伝わっても、上層部や関係部署を巻き込む段階で止まります。図解にすることで、Shellの構造を知らない人間でも「何が決まっていて、何が決まっていないか」が一目で分かります。確認が必要な相手を引き込むには、相手が理解できる形で情報を出すことが前提です。図解は、孤独な作業を関係者全員の問題に変えるための道具です。

この整理に時間がかかることがあります。半日かかることもあります。しかし20年以上現場を見てきた経験から言えるのは、この時間を惜しんで先に進もうとした現場のほうが、はるかに大きな時間を後で失っているということです。整理なしで書き始めたShellは、途中で必ず止まります。書き直しが発生します。レビューが通りません。誰かが引き継げません。整理に使った半日は、後工程で発生する数日分の手戻りを防ぎます。多少時間がかかっても、整理を先に入れたほうが、最終的には遥かに早く、遥かに遠くまで進めます。

一人で抱えて悩み続ける前に、この一枚を作ることで状況が変わります。「何が決まっていないか」が見えると、誰に何を確認すればいいかが分かります。孤独に詰まっていた状態から、巻き込むべき相手と話せる状態に変わります。図解することは、自分のためではなく、相手に伝えるための準備です。

この整理シートで重要なのは、完成させることではありません。埋まらない項目が出た時点で、そこが止まっている原因です。「対象ファイル」欄には実ファイル名を記載します。日本語化された名前や省略は禁止です。「確認先」欄が空欄の項目は、その時点で責任者が不在であることを意味します。一人では答えが出ないのは当然で、この欄が空欄であること自体を、巻き込むべき相手への説明材料として使います。

「誰が何に責任を持つか」の境界線を引く

入力・出力・対象ファイルを一覧に落とすと、必ず「この項目は誰が決めるのか」という問いが出てきます。ここで責任の境界線を引きます。入力ファイルの仕様は業務チームが持っているのか、アプリ開発側が持っているのか。実行後のログ確認は運用チームの範囲か、開発側の範囲か。外部スクリプトの仕様は誰が管理しているのか。

この境界が曖昧なまま作業が進むと、完成したShellを誰もレビューできない状態になります。さらにPART-Ⅲで整理したように、PMOがこの境界を把握していない現場では、問題が起きたときに「それはどちらの範囲ですか」という話し合いがゼロから始まります。その話し合い自体に時間と労力が取られ、本来の作業が止まります。

境界線を引くことは、今の作業を前に進めるためだけではありません。後で誰かが同じ場所で詰まらないための準備でもあります。そしてこの境界線は、一人で決めるものではありません。整理シートの「確認先・責任者」欄を埋める作業そのものが、境界線を引く行為です。空欄が残った項目は、巻き込むべき相手がまだいないことを意味します。そこを放置したまま進むと、必ず同じ場所で詰まります。

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

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

論点を整理することで、「書けない」ではなく「決まっていない」が見えてくる

入力・出力・責任境界を整理した段階で、多くの現場では「Shellが書けない理由」の正体が変わります。「書けない」と思っていた状態が、「決まっていないから書けない」という状態に変わります。この変換が起きることで、次に何をすべきかが明確になります。「この項目を誰が決めるのか」「いつまでに確認が取れるのか」という具体的なアクションに変わります。

担当者がPMOから「なぜ進まないのか」と問い詰められていた状況も、ここで初めて説明できる状態になります。「Shellが書けない」ではなく「この3項目が未決定のため着手できない」という言葉に変わります。論点が整理されると、担当者を追い詰めていた圧力の向き先が、人から問題へと移ります。これが、外から整理することの最初の効果です。

整理が入ると現場で何が変わるか

整理が入った後の現場は、作業の質だけでなく会話の質が変わります。このセクションでは、具体的な現場の場面を使って「整理された状態」がどういうものかを見ていきます。

Shellの仕様が1枚あるだけで、レビューの会話が変わる

整理が入った状態の象徴が、「Shellの仕様が1枚にまとまっている」という状態です。入力・出力・対象ファイル・実行タイミング・責任者が1枚に落ちていると、レビューの場で起きる会話が変わります。「この引数の意味は何ですか」「このファイルパスは固定ですか変数ですか」という基本確認がなくなります。代わりに「このエラー時の処理はどうするか」「リラン時の挙動は想定されているか」という、本来すべき議論ができるようになります。レビューが機能するかどうかは、仕様の言語化ができているかどうかにかかっています。

「あとはコードを書くだけ」という状態にするのが整理のゴール

外から整理する作業のゴールは、「あとはコードを書くだけ」という状態を作ることです。逆に言えば、この状態になるまでは着手するタイミングではありません。仕様が固まっていない状態で書き始めると、途中で必ず止まります。書き直しが発生します。レビューが通りません。整理にかかる時間は、後工程で発生する手戻りの時間よりはるかに短いです。あなたの現場で、「あとはコードを書くだけ」と言える状態になってからShellを書き始めていますか。

整理が入らないまま進んだ現場の末路

以前、外から参画したある現場で、APサーバーの起動制御まわりで障害が起きている状態で呼ばれたことがありました。「動いているはずなのに、ポートがおかしい」という状態でした。原因を調べると、あるメンバーが設計書に定められた起動方式を無視して、直接起動コマンドで実行していました。

問題はそのメンバー個人の話ではありませんでした。APサーバーの起動がなぜsystemd経由でなければならないのか、その理由を現場の誰も説明できていなかったのです。systemdを介することで、serviceファイルが読み込まれ、server.xmlで指定されたポート番号が正しく適用される。この一連の仕組みが、チーム全員の共通理解になっていませんでした。

設計書に「systemd経由で起動する」と書いてあっても、なぜそうしなければならないかが共有されていなければ、理解の浅いメンバーが自己流で動かしてしまいます。そしてこの原因を特定するだけで、複数のメンバーが数人月を費やしました。仕組みの整理と共有が先に入っていれば、こうはなりませんでした。

外から整理できる人が現場にいない構造的な理由

現場が止まっているとき、「なぜ誰も整理しないのか」という疑問が生まれます。能力の問題ではありません。整理する役割が、構造的に生まれにくい現場になっているのです。しかしこの構造は、誰かが意図して作ったものでもありません。

SES現場特有の役割分担の曖昧さ、エージェントによるアサインの問題、そして長くその環境にいることで育たなくなる危機感。これらが重なることで、整理できる人間が現場に生まれにくい状態が自然と出来上がっています。このセクションでは、その構造を責める視点を外して、一つひとつ説明します。

現場の中にいると「止まっていること」自体が見えなくなる

現場の中にいると、「詰まっている状態」が日常になります。本来であれば、このままではまずいという感覚が肌で分かるはずです。進んでいない、決まっていない、誰も責任を持っていない。その違和感は、外から見れば明らかです。

しかし長くその環境にいると、その違和感すら感じなくなります。止まっている状態が「普通」になり、危機感を持つこと自体がなくなっていきます。問題なのはそれが自覚されないまま育ってしまうことです。実際に「この状態はまずい」と指摘すると、「なんでそんなことを気にするんですか」という反応が返ってくる現場がありました。気にしないのではなく、気にする基準そのものが形成されていないのです。

こうなると、外から整理が入っても最初は機能しません。「整理が必要だ」という前提を共有するところから始めなければならないからです。止まっていることに気づいていない人間に、止まっている原因を説明することはできません。外から入って最初にやることの中には、この「気づきの共有」も含まれています。

整理役割の不在とSESエージェントが生むアサインミスの構造

整理する役割は、明示的にアサインされない限り誰の仕事にもなりません。PMOはスケジュール管理をしています。開発担当は実装をしています。レビュアーは成果物を確認しています。その隙間に落ちているのが「仕様の論点整理」です。

現場の多くの人間は「言われていないからやらない」という判断をします。悪意はありません。ただ、自分の役割の範囲外だと認識しているのです。さらに問題を複雑にしているのが、SESエージェントの構造です。エンジニアを現場に送り込むことを仕事とするエージェントの多くは、技術をほぼ理解していません。

「Shellができる人が必要」という現場の要件が、どのレベルのShellを指しているのかを正確に把握できないままアサインします。現場に入った時点ですでに前提が崩れているにもかかわらず、それを誰も把握していないまま作業が始まります。整理役割の不在と、入口でのアサインミスが重なることで、現場のShellが止まる土台はプロジェクト開始前から出来上がっています。

「手が止まる前に整理が入れば」という話が、外部支援の本質

整理をしないままここまで来ると、必ずしわ寄せが来るという確信は、経験の積み重ねから生まれます。あの判断をしなかったから後でああなった。あの整理を先にしていれば。そういう失敗を繰り返す中で、「このままではまずい」という臆病さが育ちます。ところが20年選手でもその臆病さが育っていない人間が、現場には少なくありませんでした。経験の年数と、失敗から学ぶ感度は、必ずしも比例しません。言われたことだけをこなし続けた20年は、臆病さを育てません。自分の判断で動き、その結果を引き受けてきた経験だけが、この感覚を育てます。

外部から支援を受けるということは、「できないことを代わりにやってもらう」ことではありません。「現場の中にいると見えないものを、外から見て整理する」ことです。Shellが止まってから呼ばれるより、止まる前に論点を整理できれば、手戻りは最小になります。仕様が決まっていない状態でコードを書き始めるより、整理が先に入れば、作業は最短で進みます。外部支援の本質は、現場が動き続けるための構造を整えることにあります。

まとめ

このシリーズを通じて書いてきた「考えることをやめた状態」「動いているのに前に進まない構造」。その具体的な姿が、Shellが止まっているSES現場には凝縮されています。今回はその現場に外から入ったとき、最初に何をするのかを整理しました。

「Shellが止まっている」と「Shellがわからない」は別の問題であり、混同したまま対処しても現場は動きません。外から入って最初にやることは、入力・出力・対象ファイル・実行タイミングを一覧に落とし、「決まっていない箇所」を可視化することです。一人で抱えて悩む前に図解まで落とすことで、巻き込むべき相手と話せる状態が生まれます。

整理が入ることでレビューの会話が変わり、設計書があっても仕組みの共有がなければ障害になるという現実も、実体験として見てきました。整理する人が現場にいないのは能力の問題ではなく、その役割が誰にもアサインされていない構造の問題です。SESエージェントが技術を理解しないままアサインするという入口の問題も重なり、現場のミスマッチは最初から始まっています。そして長くその環境にいると、まずいという臆病さすら育たなくなります。

外から整理が入る本当の意味は、書類を作ることではありません。現場全員が同じ目線で動ける状態を作ることです。
次回PART-Ⅴでは、設計書が実作業に落ちない本当の理由と、整理の手順を取り上げます。