犬猿の仲であるアプリとインフラ、なぜそうなるのか。

アプリとインフラは仲が悪い。SIerに勤務していた人なら、一度はそう思ったことがあるだろう。
ちょっとググッてみても、そういう例は枚挙に暇がないようだ。なぜ、そうなるのか。アプリ・インフラ両部門においての自分の経験をもとに考えてみる。
※念のため、アプリはシステム設計～開発、インフラは基盤構築およびその後のセキュリティパッチ適用などを指す。

一番は、アプリ部門とインフラ部門のインセンティブの違いだろう。インフラは動いて当たり前。例えば、電力、ガス、水道、電信、どれも片時でもサービス停止すれば非難の嵐になる。システムも同じで、株式取引システムの場合、相場開局中に取引ができないということがあれば、エンドユーザ（トレーダーなど）の損失は計り知れない。

そのため、インフラ部門としてはそのようなシステム停止の原因となる芽（セキュリティホールによる外部攻撃、OSのバグ）を取り除く必要があり、その対応としてパッチ適用やアップデートをする。しかし、それらのパッチが本当にアプリに影響を与えない保障はないので、アプリ側が正常に動作するか試験をする必要がある。

しかし、アプリ部門にとっては、ここで以下の問題が出てくる。
１．アプリ部門はインフラ部門と別の工数で仕事をするため、そのような試験をどちらの工数でやるのか。
２．アプリ案件で忙しいのに、インフラの手伝いをしたくない。

インフラ部門としてはパッチを当てないことで問題が発生したときの責任を回避したいため、非常にレアケースで起こるバグも潰したいが、アプリはそんなにたくさんのテストをやる余裕がないし、インフラ起因の障害が起きてもアプリ部門の責任はないため、どうしても後回しになる。
つまり、アプリ部門の優先度としてはどうしても　「アプリ案件＞インフラ案件」となってしまう。

以上のようなインセンティブの違いを解消するには、アプリ・インフラを横断して案件の優先度を決めればよいのだが、そのような両部門に対し超越的な権限を持つ部門がない。そのため、なんとなくのアプリ、インフラ部門のパワーバランスで物事が決まっていく。両者が納得できる「優先すべき基準」があればよいのだが、結局社内におけるパワー（企業で働く人は、こういうエートスが存在するのが分かると思う）がものを言ってしまうので、その軋みによって相手に対し悪い心象を抱くようになるのだろう。悪いのは「相手」ではなく、「組織の形」であるのだが。

これを解決するには最終的にはSIerに仕事を委託する事業会社ということになるのだが、案件をやらなかった場合のリスクに基づき優先順位をつけるための情報は、一次請けSIer内にある。そのため、適切な判断は難しい。結局は、これも多重下請構造の悪しき点だろう。