障害の火種となる隙間は，プロジェクト・マネージャ（PM）同士，開発者同士，運用担当者同士など，同じ役割の担当者間に生じることもある。
実際のシステム障害をひも解くと，同じ役割の担当者同士だからといって，隙間が生じる要因に特別なものはない。隙間は，担当者同士の力関係やスキル・セットといった微妙な違いで生まれてくる。担当者同士がまったく対等であったとしても，相手に対する無関心や遠慮から隙間ができてしまう。こうした構図自体は，役割の異なる担当者同士の隙間と大差はない。
特徴があるとすれば，長時間かけて隙間が冷え固まっていくということ。同じ役割の担当者は，同じ部署内やグループ企業内などで長期にわたって付き合う。プロジェクト単位で担当者が変わる，必要なときだけ顔を合わせれば済む――といった場合とは，関係の固まり具合が違う。
冷え固まってしまうだけに，後から隙間を埋めようとしても，なかなかうまくいかない。担当者レベルで隙間を解消しようと努力しても，空回りしてしまうケースが多い。結果的に，隙間は埋まらず，障害も繰り返されがちとなる。
「あれほどテストを徹底するように頼んだのに，何で正しい請求書が出ないんだ。氏名と住所が入れ違うような単純なミスを見逃したのかっ？！」。大手SI会社でPMを担当する石上信二氏（仮名）と，その子会社でPMを担当する熊谷健太郎氏（仮名）は，印刷された請求書を突き付けて怒鳴る顧客の勢いに，後ずさりした。
2人は3日前に大手企業の基幹システムの改修プロジェクトを完了させたばかり。石上氏は元請けとして基幹システムの，熊谷氏は下請けとして帳票システムの，それぞれ改修を担当した。無事にカットオーバーしたと思った矢先，顧客から呼び出され，顔を見るなり怒鳴られたのだ。「総合テストでは正しく出力されたのに」――熊谷氏は印刷された請求書を見て目を疑った。
帳票システム担当だった熊谷氏は，会社に戻って原因を探ったが，問題は見つからない。仕様に間違いはないし，コーディング・ミスもない。総合テストの結果も正しかった。焦りが募る。そんな中，ログを解析していた熊谷氏の部下が叫んだ。「基幹システムから送られたデータの形式が，総合テストの時とは違う！」。
子会社で下請けという立場では，石上氏に強く問いただすことはできない。熊谷氏は，おずおずと確認を求めた。しかし石上氏は，基幹システムに問題はないと言い張るだけ。やむを得ず，お互いの仕様書を突き合わせて確認することになった。その席上，石上氏は驚きの声を上げた。「おい，これはいつの仕様だ？ 総合テスト後に顧客から入った仕様変更が反映されていないじゃないか！」。熊谷氏も驚いた。「そんな仕様変更，いつあったんですか？聞かされていませんよ」――。
実は石上氏は，総合テスト直後に顧客から画面や帳票の項目の並び順を入れ替えたいとの依頼を受けていた。石上氏は基幹システムの変更を優先し，自社（親会社）のメンバーにだけ仕様変更の内容を説明した。ちょうどその頃，帳票システムの開発完了を報告するために熊谷氏が石上氏を訪ねていたのだが，石上氏は仕様変更への対処で忙殺されていたため，「今忙しい。後で来て」と会おうともしなかった。「後から伝えたのでは時間的に厳しくなるが，何とかするだろう」――石上氏は思った。だが，プロジェクト終盤のドタバタの中で石上氏は仕様変更を熊谷氏に伝え忘れ，そのまま熊谷氏は“完成”した帳票システムを納品した。
仕様変更が伝わっていないことに気づいた石上氏は真っ赤な顔で声を荒げた。「後で来るように頼んだのになぜ来なかった！ 顧客には子会社が仕様変更を忘れたと報告するからな」――。
この障害の直接原因は，帳票システムに仕様変更が反映されていなかったこと。石上氏は，自分の担当する基幹システムへの対処を優先させ，熊谷氏への仕様変更の伝達を先送りにした。この隙間により，仕様変更の情報が伝わらないというミスが生まれた。
総合テスト後の仕様変更が，基幹システムはもちろん帳票システムにとっても重大な影響を及ぼすことは，PMである石上氏には分かっていたはず。にもかかわらず，石上氏は基幹システムのことしか頭になかった。この顧客が品質に極端に厳しく，自分の直接の担当範囲をこなすのに精いっぱいだったという理由もあるのだが，それだけではない。
隙間の背後には，親会社と子会社，元請けと下請けという，担当者レベルでは変えがたい力関係が見え隠れする。石上氏は，子会社で下請けという弱い立場の熊谷氏に，後から伝えても「何とかするだろう」と気楽に考えた。しかも本来ならば，石上氏がミーティングなどを通じて仕様変更を周知徹底すべきなのに，実際には熊谷氏が“ご用聞き”に回って教えてもらうという運用が常態化していた。
力関係から生まれた隙間が冷え固まってしまった以上，障害は繰り返されてしまう。現に，この障害から1年後，再び画面と帳票のレイアウトを変更した際に，仕様変更の伝達漏れが判明した。このときはテストで見つけられたが，障害の火種が消えていないことがはからずも実証された。
