開発会社との定例が回らない。兼任情シスが最低限維持すべき連絡体制

開発会社との「月1回の定例ミーティング」を設定したのは半年前です。最初の2回は開催できました。3回目は決算対応と重なって延期し、4回目は別部署から急な問い合わせが入って15分で切り上げ、5回目はそもそも予定を入れ忘れました。今は「そういえば最近、開発会社と話していない」と気づいて焦る、というサイクルが定着しています。

これは怠慢ではありません。総務や経理の本業を7割抱えたまま情シスを兼任している場合、月1回・1時間の定例を毎回同じ質量で確保し続けること自体が、そもそも設計として無理があります。定例ミーティングの正しい回し方を知っていても、それを維持する時間がなければ意味がありません。専任の情シス担当者であれば「先月の課題を持ち越さず、毎月きっちり棚卸しする」運用が理想ですが、兼任者にその理想をそのまま当てはめると、理想に届かない自分を責め続けることになります。

このガイドは、「定例を頑張って続ける」方向ではなく、「定例が飛んでも最低限壊れない連絡体制」をどう設計するかを扱います。結論を先に言うと、鍵になるのは頻度を上げることではなく、同期(リアルタイムのやり取り)と非同期(記録に残るやり取り)の役割を分けることです。この記事では、その分け方を「常設層・定期層・記録層」という3つの層として具体的に設計し、それぞれの層で兼任者が今日から着手できる作業に落とし込みます。

なぜ「月1定例」だけの体制は兼任者に向かないのか

月1回の定例ミーティングは、担当者が専任でフルタイム対応できることを前提にした設計です。開発会社側もその前提でスケジュールを組んでいます。ところが兼任情シスの実態は、月によって使える時間が大きく変動します。決算期・繁忙期には情シス業務に割ける時間がほぼゼロになる月もあれば、逆に落ち着いている月には数時間確保できることもあります。

この「月による可処分時間の増減」を無視して固定頻度の定例だけに依存すると、忙しい月に定例が飛び、そのまま次の月も次の月も再設定を後回しにして、気づけば3ヶ月連絡していない、という状態に陥りやすくなります。定例ミーティングの運営方法自体は開発プロジェクトの定例ミーティングの回し方で扱っていますが、それは「定例を開催できること」が前提の話です。このガイドは、その前提が崩れがちな兼任者に向けて、定例を「唯一の連絡手段」から「複数ある連絡手段の1つ」に格下げする設計を示します。

さらに厄介なのは、定例が形骸化していく過程が本人にも見えにくい点です。1回飛ばした時点では「今月はしかたない」で済みますが、2回目、3回目と続くと、開発会社側にも「この会社は連絡が来なくなった」という印象が定着し始めます。連絡が来ない顧客に対して、開発会社側から積極的に「そろそろ定例をどうしますか」と催促してくれるとは限りません。多くの開発会社は受け身の姿勢を取り、顧客側からの連絡を待つ形になりがちです。結果として、双方が「相手から連絡が来るはず」と思い込んだまま、連絡の空白期間だけが延びていくという構図が生まれます。

この構図の怖いところは、空白期間の間にもシステムは動き続けているという点です。障害が起きなければ問題は表面化しませんが、いざ障害が起きたときに「そういえば最近の担当者の連絡先が分からない」「保守契約の内容を誰も覚えていない」という状態で対応を始めることになれば、初動が大きく遅れます。定例の頻度そのものより、この「いざというときに繋がる経路」が保たれているかどうかのほうが、実務上ははるかに重要です。

連絡体制を3層に分解する

最低限の連絡体制は、頻度も重さも違う3つの層に分けて設計します。1つの窓口・1つの頻度で全てをカバーしようとするから破綻するのであって、層ごとに求められる即応性が違うと理解すれば、兼任者でも維持可能な形に落とし込めます。

この3層のうち、兼任情シスが最優先で死守すべきは「常設層」です。障害時に誰に何で連絡すればすぐ繋がるか、この1点さえ明確にしておけば、定期層の頻度が多少ぶれても実害には直結しません。逆に、定期層(定例)ばかりを気にして常設層の連絡経路が曖昧なままだと、実際に障害が起きたときに連絡先すら分からず対応が遅れる、という本末転倒が起こります。

3層のバランスを考えるとき、多くの兼任担当者は無意識のうちに「定期層」に一番時間と気力を使ってしまいます。これは、定例ミーティングが「予定に入っている」「開発会社側から出席を求められる」という形で可視化されているためで、常設層や記録層のように「普段は何も起きていないように見える」地味な整備は後回しにされがちです。しかし実際に会社を守るのは、目立たない常設層と記録層のほうです。定期層は言わば「関係を良好に保つための潤滑油」であり、これが多少滞っても関係が即座に壊れるわけではありません。一方で常設層が機能していなければ、障害発生時に直接的な実害が生じます。この優先順位の逆転を正すことが、このガイドの最初の目的です。

常設層: 障害時に「誰に」「何で」連絡するかを1枚にまとめる

まず確認すべきは、契約している開発会社側の障害対応の窓口です。保守契約を結んでいる場合、契約書や見積書に「障害発生時の連絡先」「対応時間帯」が明記されているはずです。書かれていない、あるいは見当たらない場合は、それ自体が契約内容の不備であり、次に開発会社と話す機会に必ず確認すべき項目になります。保守契約でどこまでの対応が含まれているかの読み解き方は月額保守費で何をやってもらえるのかに譲りますが、ここでは「連絡先」という1点だけに絞って押さえておきます。

確認すべきは次の4点です。

• 緊急連絡先: 電話番号かチャットか。担当者個人の連絡先だけに頼っていないか(担当者不在時の代替窓口があるか)
• 対応時間帯: 平日日中のみか、夜間休日も対応するか。対応するなら追加費用が発生するか
• 連絡してよい基準: 「システムが全く動かない」レベルか、「一部機能が使えない」レベルからでもよいのか。基準が曖昧だと、兼任者は「これくらいで連絡していいのか」と毎回迷い、結果として連絡が遅れます
• 一次回答までの目安時間: 即座の解決ではなく、「まず反応が返ってくるまで」の時間感覚を握っておく

これらを確認したら、社内向けに1枚のメモにまとめておきます。自分が休暇中や本業で身動きが取れないときに、他の社員がこのメモを見れば同じ連絡ができる状態にしておくことが目的です。ひとり情シスが不在の間に障害が起きた場合の備えはひとり情シスが安心して休むために作っておく仕組みでも扱っているので、あわせて確認してください。

「連絡してよい基準」を決めておく意味

4つの確認項目の中でも、特に見落とされがちなのが「連絡してよい基準」です。兼任情シスは、システムの専門知識が浅い状態でこの役割を任されていることが多く、目の前で起きている不具合が「開発会社に連絡すべき重大な問題」なのか「様子見でよい軽微な問題」なのかを、自分で判断する自信を持てないケースが少なくありません。

この判断の迷いが積み重なると、2つの悪い方向に振れます。1つは、些細な不具合でも都度連絡してしまい、開発会社側から「軽微な問い合わせが多すぎる」と受け取られ、緊急時の連絡への反応が鈍くなるパターン。もう1つは逆に、連絡を躊躇しているうちに問題が深刻化し、本来もっと早く連絡すべきだったと後から分かるパターンです。

この迷いを解消する最も簡単な方法は、開発会社との間で「連絡してよい基準」をあらかじめ具体的な言葉で合意しておくことです。「システム全体が停止した」「特定の業務フローが使えなくなった」「エラーメッセージが表示されるが操作は続けられる」といった段階を、担当者と話しながら3段階程度に区分けし、どの段階から連絡してよいかを確認しておきます。この合意は口頭でも構いませんが、後述する記録層のルールに従って、必ずメールなどの形で記録に残しておいてください。

定期層: 「月1回」を諦めて「隔月」「四半期」に落とす選択肢

定例の頻度自体を見直すことも、兼任者にとっては現実的な選択です。月1回を死守しようとして毎回綱渡りになるより、最初から隔月や四半期に1回と決めて、その代わり毎回確実に開催する方が、開発会社側との信頼関係も維持しやすくなります。

頻度を落とす際に注意すべき点が1つあります。定期層の頻度を下げるほど、記録層(次の見出しで扱う非同期の記録)の役割が重くなるという点です。3ヶ月に1回しか顔を合わせないなら、その間に発生した細かい依頼や確認事項は、口頭で聞くのではなく都度メールやチケットで記録し、定例の場ではその記録を振り返って確認する、という運用に切り替える必要があります。定例の頻度を落としたのに、記録の運用は変えないままだと、3ヶ月分の「言った言わない」が定例の場で噴出し、かえって収拾がつかなくなります。

以下は、頻度を落とす場合に定例の場で最低限確認すべき3項目です。

1. その期間中に発生した障害・不具合とその対応状況
2. 保守費・契約範囲の変更予定の有無
3. 開発会社側の体制変更(担当者交代など)の予定の有無

この3項目さえ定期的に確認できていれば、頻度が月1回でなくても、重大な見落としが発生するリスクはかなり抑えられます。

頻度変更を開発会社にどう切り出すか

「頻度を落としたい」という相談を開発会社に切り出すことに、心理的な抵抗を感じる兼任担当者は少なくありません。「サボっていると思われるのではないか」「開発会社側の稼働計画に迷惑をかけるのではないか」という不安がよぎるためです。しかし、実態を隠したまま定例を設定しては延期する、を繰り返すほうが、開発会社側にとっても予定が立てにくく迷惑になります。

切り出し方としては、「本業との兼任のため、毎月の定例を確実に開催する余裕がありません。隔月にして、その分1回あたりの準備をしっかりする形にしたいのですが、いかがでしょうか」という形で、理由と代替案をセットで伝えるのが基本です。開発会社側も、顧客担当者が兼任であることは多くの場合すでに把握しており、頻度の相談自体を無理な要求と捉えることはまずありません。むしろ、曖昧なまま定例が有名無実化するより、明確に頻度を再設定してもらったほうが、開発会社側もスケジュールを立てやすくなります。

定例の「準備」を軽くする工夫

頻度を落とした分、1回あたりの定例の準備に手間をかけすぎると、結局その準備自体が負担になり本末転倒です。準備は次の3点に絞ることをお勧めします。

• 前回の定例で決まったことのリストを見返す(新規に作らず、前回の議事録を再利用する)
• 記録層に残っている未回答の依頼を洗い出す(メールやチケットを検索すればすぐ出てくる状態にしておく)
• 次の期間で発生しそうな予定(異動・新規SaaS導入など)を1〜2行でメモする

この3点だけであれば、15分もあれば準備が完了します。定例そのものの時間を短縮するより、準備の負担を下げるほうが、兼任者にとっては継続のハードルが下がります。

記録層: 依頼は「言った」ではなく「残した」で成立させる

兼任情シスが最も陥りやすい失敗は、口頭やチャットの一言で開発会社に依頼を出し、それが記録に残らないまま時間が経ち、「言った」「聞いていない」の水掛け論になることです。これは定例の頻度とは独立した問題で、むしろ定例が少ない体制ほど重要度が上がります。

依頼を出すときの最低限のルールは次の2つです。

• 口頭で依頼したら、直後に1行でもメールで内容を追記する: 電話や立ち話で依頼した内容は、その場では合意できても記録には残りません。「先ほどお電話でお伝えした件、〇〇の対応をお願いします」という短いメールを送るだけで、証跡化されます
• 返信が来ない依頼は、期限を決めて再送する: 「そのうち返事が来るだろう」と待ち続けると、忙しい兼任者ほど忘れがちです。依頼を出したら「〇日までに返信がなければ再送する」というルールを自分の中で決めておくと、放置を防げます

開発会社からの返信が遅くなってきたと感じた場合の対処は開発会社の返信が遅い・つかまりにくい。関係が壊れる前にできる対処で詳しく扱っています。記録層の運用を徹底していれば、この記事で紹介されている「感覚を記録に変える」というステップの土台がすでにできている状態になります。

「電話で済ませたほうが早い」という判断は、その場のスピードだけを見ればおそらく正しい。しかし記録に残らない依頼は、後から自分自身を守る材料にもならない。1行のメールを追記する数十秒のコストは、後で「言った言わない」を検証する数時間のコストと比べれば、はるかに安い。

記録の粒度はどこまで細かくすべきか

記録層の運用を始めようとすると、多くの兼任担当者は「どこまで細かく記録すればよいのか」で迷い、結局面倒になって続かなくなります。目安としては、次の2種類に絞って記録すれば十分です。

1. 金銭・仕様が変わる依頼: 追加費用が発生する可能性がある依頼、仕様や動作の変更を伴う依頼は、必ず記録に残します。これらは後から「言った言わない」になった場合の影響が大きいためです
2. 障害・不具合の報告とその対応結果: いつ・何が起きて・どう対応されたかは、次に似た問題が起きたときの判断材料になります。特に同じ不具合が繰り返し発生している場合、記録がなければ「これが初めてなのか、何度目なのか」すら分からなくなります

逆に、日常的な軽微な問い合わせ(操作方法の確認など)まで一つひとつ厳密に記録する必要はありません。全てを同じ精度で記録しようとすると、記録作業自体が新たな負担になり、結局続かなくなります。「金額・仕様が変わるか」「障害かどうか」という2つのフィルターで、記録すべきものだけを絞り込むことが継続のコツです。

メールとチャットツール、どちらで記録すべきか

開発会社によっては、SlackやChatworkなどのチャットツールで日常のやり取りをすることも多いでしょう。チャットツール自体は記録として機能しますが、1つ注意点があります。それは、チャットのログは検索性が低く、後から特定の依頼を探し出すのに時間がかかるという点です。

依頼が発生した際は、チャットで気軽にやり取りした内容であっても、金額や仕様に関わる重要な依頼だけは、件名をつけたメールとして改めて送る、という運用をお勧めします。メールであれば件名検索で後から探しやすく、また多くの企業でメールはバックアップ対象になっているため、記録の耐久性という点でもチャットログより優れています。

兼任者が連絡窓口を1人に集中させるリスク

もう1つ、体制設計上の注意点があります。兼任情シスである自分自身が、開発会社との唯一の連絡窓口になっている状態は、単一障害点(自分が休んだり退職したりすると連絡そのものが止まる状態)を作っていることに他なりません。

これを避けるには、次の2つの手当てが有効です。

1. 社内に「自分がいないときの代理連絡先」を最低1人決めておく: 直属の上司でも、他部署の担当者でも構いません。開発会社側の緊急連絡先メモ(前述)を共有しておくだけでも、代理は成立します
2. 開発会社側にも複数の連絡窓口があるか確認する: 開発会社の担当者が1人しかいない体制だと、その担当者が不在のときに開発会社側も対応できなくなります。開発会社の担当者変更時の引き継ぎについては開発会社の担当者が変わったときの引き継ぎ確認で扱っていますが、平時から「担当者は1人か、チーム体制か」を確認しておくと、いざというときの備えになります

代理連絡先を立てる際は、その人に「開発会社との関係の全てを引き継ぐ」ことまでは求めなくて構いません。あくまで「緊急時に一次連絡ができる」「連絡先メモの在り処を知っている」という最低限の役割で十分です。むしろ役割を広げすぎると、代理を頼まれた側の負担が大きくなり、協力を得にくくなります。

開発会社側の体制もあわせて確認する

自社の連絡窓口の分散を考えると同時に、開発会社側の体制がどうなっているかも確認しておく価値があります。特に、規模の小さい開発会社や個人事業主に近い体制で契約している場合、担当者が1人しかおらず、その担当者が体調を崩したり退職したりすると、開発会社側からの対応そのものが止まってしまうリスクがあります。

これは契約前であれば開発会社の選び方: 規模別・得意分野別の見極めで確認すべき観点ですが、すでに契約中の場合は、次の定例(または随時の確認)で「もし担当者が対応できなくなった場合、代わりに誰が対応しますか」と一度尋ねておくとよいでしょう。答えが曖昧であれば、それは自社にとってのリスクとして認識し、常設層の連絡先メモに「担当者以外の連絡先が存在しない」旨を明記しておくべきです。

定例が飛んだときの「詫び」より「復帰の一言」を優先する

心理的なハードルとして、「定例をすっぽかしてしまった」「3ヶ月連絡していない」という状態から再開するとき、多くの兼任担当者は気まずさから連絡自体を先延ばしにしがちです。しかし、この先延ばしこそが関係を最も悪化させます。

再開の連絡は、長い謝罪文である必要はありません。「本業が立て込んでご連絡が滞っておりました。現状の共有と、次回の定例日程の相談をさせてください」という数行で十分です。開発会社側も、顧客からの連絡が途絶えがちなことには一定の理解を持っていることが多く、重要なのは「連絡が止まっている状態を自分から動いて解消する」という行動そのものです。

再開の連絡をした後、初回の定例(あるいは電話)では、空白期間中に起きたことを次の順番で確認すると、話がまとまりやすくなります。

1. その期間中に障害や不具合はあったか、あった場合はどう対応されたか
2. 保守契約や見積の内容に変更はあったか
3. 開発会社側の体制(担当者)に変更はあったか
4. 今後の連絡頻度をどうするか、あらためて合意する

この4点を確認すれば、空白期間の「何が起きていたか分からない」という不安は大部分解消できます。空白の長さそのものを気に病むより、再開後にこの4点を丁寧に埋め直すほうが、実務上は意味があります。

よくある落とし穴: 「返信が来ないから連絡しなくていい」という誤解

連絡体制を整えようとする過程で、意外と多い落とし穴があります。それは、開発会社からの返信がないことを「向こうから連絡が来ないなら、こちらも急ぐ必要はない」と解釈してしまうことです。

しかし、返信が来ない理由は様々です。担当者が多忙で単純に埋もれている場合もあれば、依頼の優先度が低いと判断されている場合、あるいは依頼内容が不明瞭で開発会社側も対応に困っている場合もあります。いずれにせよ、返信が来ないことを「問題なし」のシグナルとして受け取るのは危険です。

前述した「返信が来ない依頼は、期限を決めて再送する」というルールは、この落とし穴を避けるための具体的な対処です。再送してもなお反応がない場合は、それ自体が開発会社の返信が遅い・つかまりにくいで扱っているエスカレーションを検討すべきサインになります。

兼任者が使えるツールで体制を軽量化する

3層の体制を「気合いと記憶力」だけで回そうとすると、いずれ破綻します。専任の情シス担当がいる会社であれば専用のヘルプデスクツールやチケット管理システムを導入することもありますが、兼任者の場合、新しいツールを導入して覚えること自体が負担になりかねません。ここでは、既に社内にある可能性が高いツールだけで3層を軽量に運用する方法を紹介します。

• 常設層: 緊急連絡先メモは、Excelやスプレッドシートの1枚で十分です。特別なツールは不要で、むしろ普段使っているツールの中で誰でもすぐ開ける場所に置くことが重要です。共有ドライブの分かりやすい場所、あるいは社内Wikiがあればそこに置きます
• 定期層: 定例の議事録は、凝った書式を作らず、日付・出席者・決定事項・次回までのToDoの4項目だけをメモ書きで残せば十分です。議事録作成そのものに時間をかけすぎると、それも兼任者の負担になります
• 記録層: 新たにチケット管理ツールを導入する必要はなく、メールの中で依頼ごとにフォルダ分け、あるいはラベル付けをするだけでも検索性は大きく向上します。件名の先頭に「【依頼】」「【障害報告】」のような接頭辞をつけるルールを自分の中で決めておくと、後から検索しやすくなります

ツールを新しく導入することよりも、今あるツールの使い方に一貫したルールを持たせることのほうが、兼任者にとっては継続可能性が高くなります。

ケースで考える: 半年間連絡が途絶えていた場合の立て直し手順

ここまでの内容を、実際によくある状況に当てはめて整理します。「気づいたら開発会社と半年間まともに連絡を取っていなかった」という状態から立て直す場合、次の順番で動くことをお勧めします。

1. まず自社の状況を確認する: この半年で障害は起きていないか、システムに気になる挙動はないか、社内の他の担当者に聞いて回ります
2. 開発会社に現状報告を兼ねた連絡を入れる: 前述の「復帰の一言」の要領で、長い謝罪ではなく簡潔に連絡を再開します
3. 常設層の情報を最新化する: 半年の間に開発会社側の担当者が変わっている可能性もあるため、緊急連絡先メモの内容が今も有効か確認します
4. 保守契約の内容を確認する: 半年間連絡が途絶えていたということは、保守契約の内容自体を忘れている可能性が高い状態です。契約の中身が分からなくなっている場合は、前任者が結んだ契約を洗い出す手順にあらためて取り組む価値があります
5. 今後の定期層の頻度を再設定する: 「月1回」に戻すのではなく、今回なぜ連絡が途絶えたのかを踏まえて、無理のない頻度(隔月・四半期)を新たに合意します

この5ステップは、いずれも1回あたり数十分程度で完了する規模の作業です。「半年分をまとめて取り戻さなければならない」と身構えると着手が重くなりますが、実際には各ステップを分割して、本業の合間の隙間時間に少しずつ進めることができます。

この体制を成り立たせるための最低ライン: まとめ

兼任情シスが開発会社との関係で壊してはいけないのは、「定例の頻度」ではなく「何かあったときに繋がる経路」です。整理すると、次の3点が最低ラインになります。

• 常設層: 障害時の連絡先・対応時間帯・連絡基準を1枚のメモにして社内共有する
• 定期層: 月1回にこだわらず、隔月・四半期でも「確実に開催できる頻度」に設計し直す
• 記録層: 口頭依頼には必ず1行のメールを添え、返信がない依頼は期限を決めて再送する

この3層を意識して設計すれば、定例が本業の都合で何度か飛んでも、開発会社との関係そのものが壊れることは防げます。逆に言えば、定例の頻度だけを気にして常設層と記録層を疎かにすると、表面上は毎月連絡しているように見えても、いざというときに機能しない体制になりかねません。

最後に強調しておきたいのは、この3層の設計は一度作って終わりではなく、会社の状況(従業員数の増加、システムの追加、開発会社側の体制変更など)に応じて定期的に見直す必要があるという点です。半年に1回程度、常設層の連絡先メモが最新の状態か、記録層のルールが実際に運用できているかを振り返る機会を作っておくと、体制の形骸化を防げます。

自分の会社の連絡体制がどの程度整っているか客観的に確認したい場合は、ひとり情シス危険度診断もあわせて活用してください。また、開発会社との関係を整理する最初の一歩、初めての検収で失敗しないための確認、前任者が結んだ契約の内容を洗い出す方法については、当メディアの他のガイド記事でも扱っています。