「社内のシステムリプレイス、君が窓口やってね」 「開発会社との定例会議、進捗管理だけお願いできる？」
ある日突然、上司からそんなふうに言われたことはありませんか？ あなたはプログラミングなんてしたことがない。サーバーとクラウドの違いもあやふや。普段は経理や総務、あるいは営業事務として、まったく別の仕事をしていたはずです。
「管理だけなら、いつもやっている業務と同じだろう」 そう思って引き受けたが最後、あなたは未知のジャングルに放り込まれます。
プロジェクトは待ってくれません。 WBS？ Git？ API？ デプロイ？ リファクタリング？ 飛び交う専門用語。 進まないスケジュール。 不機嫌になるエンジニアと、「まだできないのか」と焦る経営陣。 間に挟まれて、胃が痛くなる毎日。
この記事は、技術の専門家ではない「バックオフィス（事務・管理部門）」の視点から、エンジニアチームといかに協調し、炎上しがちな開発プロジェクトをゴールまで導くか。その「調整と対話の泥臭い実務」をまとめたものです。
教科書的なPMO（プロジェクトマネジメント）論ではありません。 PMPの資格も、アジャイル開発の深い知識も不要です。 必要なのは、相手へのリスペクトと、ほんの少しの処世術。 明日から使える、現場のサバイバルガイドをお届けします。
1. なぜ、エンジニアとの調整はこんなにも疲れるのか
まず、前提を共有しましょう。あなたが疲弊しているのは、あなたの能力が不足しているからではありません。「言語」と「時間感覚」、そして「価値観」が全く異なる部族の間に入っているからです。
ビジネスサイド vs エンジニアサイドのズレ
私たちバックオフィスや営業（ビジネスサイド）は、「納期」や「約束」を絶対視します。 「来週までにやると言ったからには、残業してでもやる」「お客様との約束は絶対」というのが、昭和的かもしれませんが、一般的なビジネスの現場の感覚です。ここでは「気合」や「根性」がある程度機能します。
一方、エンジニア（クリエイターサイド）は、「論理」と「品質」を重視します。 彼らにとって、バグがある状態でシステムをリリースすることは、ブレーキの効かない車を納車するのと同じ、「罪」に近い行為です。 また、プログラミングは「論理的なパズル」であり、気合で解決できるものではありません。1+1が2になるように、動かないコードはどれだけ祈っても動きません。
だから、「納期なので出します」という理屈に対して、「物理的に動きません」「セキュリティリスクがあります」と頑として譲らない場面が出てきます。
この「気合でなんとかしたいビジネス側」と「物理的に無理なものは無理なエンジニア側」の板挟みになるのが、調整役のポジションです。 ここを理解しておくだけで、「なんでやってくれないの！」というイライラが少し減ります。彼らはサボっているのではなく、エンジニアとしての職業倫理を守っていることが多いのです。
「メーカースケジュール」と「マネージャースケジュール」
もう一つ、決定的な違いがあります。それは時間の使い方です。これは著名な投資家ポール・グレアムが提唱した概念ですが、理解しておくとエンジニアとの付き合い方が劇的に変わります。
- マネージャースケジュール（事務・営業・管理職）
1日は1時間刻みの予定で構成されます。会議の合間にメールを返し、電話に出る。予定が変わることにも慣れています。「空き時間」があれば、そこに別のタスクを詰め込むことができます。 - メーカースケジュール（エンジニア・デザイナー・作家）
1日は「半日」単位の巨大なブロックで構成されます。プログラミングは、頭の中に巨大な論理構造（変数の値、関数の依存関係、データの流れなど）を組み立てる作業です。この「城」を脳内に構築するのに30分〜1時間かかります。
ここで、事務の方が良かれと思ってやる「5分だけ進捗確認ミーティング」が、エンジニアにとっては悲劇となります。 たった一本の電話、たった一回の「ちょっといい？」で、脳内の城は崩れ去ります。一度崩れると、元の集中状態（ゾーン）に戻るのにまた30分かかります。つまり、あなたの「5分の確認」は、エンジニアの「午後の生産性すべて」を破壊する可能性があるのです。
この温度差が、コミュニケーション不全の大きな原因です。「なんでちょっと聞くだけなのに不機嫌になるの？」と思ったら、この話を思い出してください。
2. WBSは「希望的観測」の塊であると知る
プロジェクト開始時に作成される「WBS（スケジュール表）」。 綺麗に階段状に並んだガントチャートを見ると安心しますが、バックオフィス担当者がまず心に刻むべきは、「WBSは生き物であり、初版はただの願望である」という事実です。
スケジュールが崩壊する「3つの魔物」
なぜ、エンジニアさんが引いたスケジュール、あるいはベンダーが出してきたスケジュールは必ず遅れるのでしょうか。悪意があるわけでも、能力が低いわけでもありません。システム開発特有の「魔物」がいるからです。
① 「見えない作業」が隠れている
WBSに「機能A実装：3日」とあっても、その前後に膨大な作業があります。これらがタスクとして可視化されていない場合、確実に3日では終わりません。
- 仕様の調査（ドキュメント読み込み）
既存のコードがどう動いているか調べる時間。これが意外と長いのです。 - 開発環境の構築・メンテ
そもそもプログラムを書くための準備。PCの設定、サーバーの準備など。 - 他機能との干渉チェック
Aを直したらBが壊れないか確認する作業。 - コードレビューと修正
書いたコードを他の人がチェックし、指摘事項を直す往復の時間。エンジニアが一人でない限り、必ず発生します。 - マージ作業とコンフリクト解消
複数人のコードを合体させる際のエラー対応。
② 「技術的負債」という名の地雷
「ちょっとボタンを追加するだけ」と思っても、蓋を開けてみたら、既存のコードがスパゲッティのように絡まり合っていることがあります。 一箇所直すと別の一箇所が壊れる、継ぎ接ぎだらけの古いシステム。これを「技術的負債」と呼びます。
リフォーム工事で壁を剥がしてみたら、柱がシロアリに食われていたようなものです。これを直すための時間は、実際に壁を剥がして（コードを見て）みるまで、熟練のエンジニアでも正確には読めません。「やってみないとわからない」と言われるのはこのためです。
③ 外部要因による待ち時間
エンジニアの手が止まる要因は外部にも溢れています。これはエンジニアの努力ではどうにもなりません。
- クライアントからのAPIキー提供待ち
- デザインデータの修正待ち
- Apple/Googleのストア審査待ち（数日かかることもザラです。リジェクトされればやり直しです）
- 利用している外部サービス（AWS、Firebase、決済システムなど）の障害
バックオフィスができる対策：バッファの確保
私たちにできることは、エンジニアを急かすことではありません。 「バッファ（予備日）を確保し、死守すること」です。
WBSを引く際、エンジニアさんが「5日でできます」と言ったら、心の中で（何かあったときのために2日足しておこう…）と計算し、上司やクライアントには「検証含めて7〜8日かかります」と伝えます。
このバッファは「サボるための時間」ではなく、「必ず起きるトラブルに対処するための保険」です。 もし早く終われば「予定より早くできました！」と報告すれば良いだけ。逆にトラブルが起きれば「想定内です」と涼しい顔で対応できます。この「見えないクッション」を挟んでおくことが、後半戦で自分自身の胃を守り、チームの品質を守ることになります。
3. 「通訳」としてのバックオフィスの役割
非エンジニアの最大の強みは「わからない人の気持ちがわかる」ことです。
エンジニアさんが専門用語で説明する内容を、経営陣やクライアントは理解できません。 「DBのインデックスが貼られていなくて、クエリがフルスキャンしちゃってるんで重いんです」 と報告されても、社長は「で、いつ直るの？」としか思いませんし、「言い訳はいいから早くして」と思ってしまいます。これではエンジニアが可哀想です。
ここであなたが間に入ります。
【実録】バックオフィス翻訳実例
エンジニアの言葉を、ビジネスの言葉（お金、時間、リスク）に変換しましょう。
| エンジニアの発言（専門語） | 経営陣・クライアントへの翻訳（ビジネス語） |
|---|---|
| 「DBのインデックスが貼られてなくて重い」 | 「データ量が増えて読み込みに時間がかかっています。整理が必要ですが、すぐ対応可能です」 |
| 「ライブラリのバージョンアップで依存関係が壊れた」 | 「利用している外部ソフトの更新により、一時的な調整作業が発生しています。セキュリティ上必要な対応です」 |
| 「仕様が決まらないと実装に入れません」 | 「手戻りを防ぐため、まずは要件を確定させてから着手した方が、結果的にコストが安く済みます」 |
| 「その変更はアーキテクチャに関わります」 | 「家の基礎工事からやり直すような大きな変更になるため、追加費用と期間が必要です」 |
| 「リファクタリングさせてください」 | 「将来の不具合を防ぎ、今後の開発スピードを落とさないために、内部の清掃・整理時間をください」 |
| 「それは技術的に可能です」 | 「（理論上は可能ですが）膨大なコストと時間がかかりますが、本当にやりますか？」 |
逆翻訳：ビジネスからエンジニアへ
逆に、ビジネス側の理不尽な要求をエンジニアに伝えるときも翻訳が必要です。 単に「社長がやれって言ってるから」と伝えると、エンジニアはモチベーションを失います。
- 悪い例
「明日までにこれ追加して。急ぎで」 - 良い翻訳
「実はクライアントにとってこの機能が、来週の展示会での一番の売りになるそうなんです。他のタスクを止めてでも優先したいのですが、可能でしょうか？」
このように「背景（Why）」と「優先順位の変更許可」をセットで伝えることで、エンジニアは「やらされている」のではなく「課題解決に協力している」という意識で動いてくれます。
4. エンジニアに「嫌われない」ための進捗確認フレーズ集
毎日「進捗どうですか？」と聞くのは、エンジニアさんにとって「早くしろ」と言われているのと同義で、プレッシャーになります。 進捗確認は「尋問」ではなく「支援の申し出」であるべきです。聞き方ひとつで、返ってくる情報の質が変わります。
NG例 ❌
- 「まだ終わりませんか？」
- →（心の声：「終わってないからやってるんだよ！」）
- 「なんで遅れてるんですか？」
- →（心の声：「予想外のバグが出たんだよ、説明してもわからないでしょ」）
- 「とりあえず今日中にやってください」
- →（心の声：「品質無視していいならやるけど、後でバグ出ても知らないよ？ 深夜残業確定か…」）
OK例（寄り添い型） ⭕
- 「今、手を止めているブロッカー（障害）はありますか？」
- （理由：技術的な問題なのか、誰かの返信打ちなのかを切り分ける。もし「〇〇さんの承認待ち」なら、あなたがボールを奪い取って進められます）
- 「スケジュール通りに進めるために、私が調整できることはありますか？」
- （理由：味方であることを示す。「じゃあ、この資料作成お願い」と頼ってもらえる関係を作る）
- 「もしこのまま進めると、どんなリスクがありそうですか？」
- （理由：遅れを責めるのではなく、未来のリスク管理として聞く。「実は検証時間が足りなくなるかも」という本音を引き出す）
- 「悪いニュースほど、早めに教えてもらえると助かります（私が上を抑えますので）」
- （理由：心理的安全性を確保する。怒られないとわかれば、致命的なバグ報告も隠蔽されずに上がってきます。これが一番重要です）
タイミングの重要性
聞くタイミングも重要です。前述の通り、集中している午後に話しかけるのは避けるとよいでしょう。
- 朝会（スタンドアップミーティング） で短く聞く。
- Slackなどのチャット で、「お手隙の際に」と投げておく。
これだけで、エンジニアのストレスは激減します。
5. コードが書けなくてもできる「神サポート」実務一覧
「私は技術力がないから…」と引け目を感じる必要はありません。 開発現場には、コードを書く以外にもやるべき「泥臭いタスク」が山のようにあります。これらはエンジニアにとって「やりたくないけどやらなきゃいけない面倒事」です。 これらを巻き取ることで、開発スピードは確実に上がります。
① ドキュメントの整地（情報の交通整理）
仕様書、要件定義書、デザインデータ…。これらがSlackやメール、Chatworkに散らばっていませんか？ 「どれが最新版かわからない」「あの仕様変更、どこで決まったっけ？」という捜索時間は、開発手戻りの最大の原因であり、時間の無駄です。
- GoogleドライブやNotionのフォルダ階層を整理する。
- ファイル名に日付とバージョン（v1.0, v1.1…）を明記するルールを作る。
- 決定事項を議事録に残し、「言った言わない」の水掛け論を防ぐ。
- Slackのチャンネルを整理し、重要な告知が流れないようにする。
これだけで、エンジニアの脳内メモリを無駄遣いさせずに済みます。
② テストデータ・アカウントの量産
システムテストの際、「ユーザーAからZまでの26パターンでテストしたい」「異常な入力値で試したい」という要望が出ます。 時給の高いエンジニアさんにテストデータを作らせるのはコストの無駄です。
- Excelでテスト用のアカウント一覧を作る。
- ダミーの会員画像や商品画像を100枚用意する（猫の画像でもなんでもいいのです）。
- 長いテキスト（1万文字）や、特殊文字（絵文字や旧字体）を含んだテスト用文章を用意する。
こういう「単純作業だけど量が必要なこと」を率先して引き受けると、神様のように感謝されます。
③ 問い合わせの一次受け（最強の防波堤）
社内やクライアントからの「ここ使いにくい」「バグじゃないか？」「エラーが出た」という問い合わせ。 これをそのままエンジニアに転送していませんか？ それは一番やってはいけないことです。
- 再現確認
まず自分で触ってみる。（再現しなければ、ユーザーの勘違いや環境の問題かもしれません） - 情報収集
OS、ブラウザ、発生日時、スクリーンショットを集める。 - トリアージ
緊急度（S：今すぐ止まる / A：早急に / B：次でいい）をつける。 - チケット化
ここまで整理して初めて、エンジニアに渡す。
ノイズをフィルタリングして、整理された情報だけをエンジニアに渡す。これができれば、開発チームの守護神となれます。
④ 会議のファシリテーション（タイムキーパー）
エンジニアは「目的のない長い会議」が嫌いです。議論が白熱して時間が伸びると、その後の作業時間が削られます。 バックオフィスのあなたが司会に入りましょう。
- 「残り10分です。結論をまとめましょう」
- 「技術的な細かい話は、担当者同士で別途やってもらえますか？」
- 「今日の決定事項はこれとこれですね」
冷徹なタイムキーパーがいるだけで、会議の生産性は劇的に向上します。また、エンジニアが出なくていい会議（政治的な調整など）には、「私が聞いておきます」と代わりに出席するのも最高のサポートです。
⑤ 雰囲気作りと「お菓子」
リモートワークでもオフィスでも、空気がピリピリしているとバグが出ます。 心理的安全性が低いチームでは、「バグを見つけたけど、報告すると怒られるから黙っておこう」という最悪の事態が起きます。
- Slackで感謝のスタンプを多めに押す。「ありがとう」「助かりました」と言葉にする。
- ミーティングの冒頭で少し雑談を入れる。
- 物理出社なら、糖分（お菓子）やコーヒーを補充しておく。
「そんなこと？」と思うかもしれませんが、人間の脳はリラックスしている時の方が論理的思考力が働きます。バックオフィスはチームのメンタルヘルスキーパーでもあるのです。
6. まとめ：調整役という「専門職」
エンジニアさんと働くバックオフィスの皆さん。 日々の調整、本当にお疲れ様です。
システムが完成したとき、光が当たるのは開発したエンジニアや、企画したリーダーかもしれません。 「スケジュール通りで当たり前」「トラブルがなくて当たり前」と思われがちな調整業務は、なかなか評価されにくいものです。加点法ではなく減点法で見られがちな仕事です。
でも、自信を持ってください。 あなたが引いたWBSのバッファがなければ、プロジェクトは破綻していました。 あなたが整えたドキュメントがなければ、手戻りで納期は守れませんでした。 あなたが間に入って通訳したから、喧嘩別れせずに済みました。
「開発を成功させるための環境を作る」 これは立派な専門スキルであり、ひとつの技術です。コードが書けなくても、あなたはプロジェクトの重要人物（キーパーソン）です。
もし今、 「社内にエンジニアとの調整ができる人がいない」 「開発以外の雑務に追われて、エンジニアが疲弊している」 「そもそも、どうやって開発体制を整えればいいかわからない」
そんな悩みを抱えているなら、一度「うしろぽっけ」にご相談ください。
私たちは、技術コンサルティング会社ではありません。 皆さんのような「現場のバックオフィス」の視点に立ち、開発チームの「うしろぽっけ」に入っているかのように、細々とした調整、資料作成、進捗管理のサポートを行うチームです。
派手な改革提案や、高価なツールの導入は提案しません。 でも、あなたのデスクに積み上がった「調整業務」の山を、一緒に崩して整地することは得意です。 エンジニアの言葉を翻訳し、WBSを引き直し、泥臭いテストデータの作成もお手伝いします。
エンジニアさんも、そしてあなた自身も、もう少し楽に働けるプロジェクトへ。 まずは愚痴をこぼすような感覚で、お問い合わせフォームから話しかけてみてください。
