TechBlog
薬師神 慧

カオスなシステムがなぜ製造されるのかと、システムベンダーにいいようにやられないためにはどうしたらいいか

IT業界話 経験談 考察

# 概要

ある程度業界経験あるエンジニアなら遭遇するであろう、他人（他社）が作ったシステムを引き継いで開発だったり運用保守をやること。 そしてその時にとんでもないカオスなシステムを担当しなければならないこと。。。

最近久々にそういうことに遭遇したため、なぜそういう悲劇が繰り返されるのかを考える。

# 前置き

特定の企業や人を悪く言うのではなく、こういった構造的な問題が少しでも解決され IT 業界が少しでも良くなっていけばという思いで思ったことをただひたすら書いている。

# とんでもないカオスなシステムとは？

# どんなシステムか？

いろんなパターンがあるが大きな粒度で挙げると、よくある事例として、

  • ドキュメントない or 更新されてなくて古い
  • 開発環境まともに動かすことができない、開発はおろかテストもできない
  • コードぐちゃぐちゃ、デッドコードだらけ、バグだらけ
  • DB ぶっ壊れてる
  • インフラ構成めちゃくちゃ、EOL 祭り

等といった形で、もちろん引き継ぎは一切なく仕様や業務要件を聞ける人はいないのがデフォルト。

# なぜそういうシステムが世に解き放たれるのか

「発注側（事業者側）がシステムベンダーにいいようにやられてる」のが理由。ではなぜそれが起きるのか、防ぐことはできないのかを考える。

# なぜシステムベンダーにいいようにやられるのか

だいたい以下の 2 つが重なったときだと思ってる

# ① 事業者側に IT わかる人がいない

何にどれくらいの時間やお金がかかるか感覚がないと、システムベンダーのいいなりになり、また、どこに対しコストをかけるべきかを理解していないと、重要なところを削ったり不要なところを削減できなかったりする。

また、ドキュメントや品質のチェックがちゃんとできず、依頼した業務要件がとりあえず満たせればいいという形になりがちになってしまう。

# ② システムベンダー側の利益追求

100%全力でやっても手を抜いてやっても報酬の金額は同じであり、言い換えると手を抜いてやったほうが得。システムベンダーも当然会社なので、利益を追求する為には少ないコストで多くの売り上げをあげるために、そこは常に最適化をし続けている。

例えば若手の教育現場とさせたり、本来必要な人数の半分のリソースでやったり、他の PJ で使ったコードを無理やり再利用したりとか。

# システムベンダー側からの視点

上記の ② の内容を、システムベンダー側の立ち位置である私の視点で、開発と運用保守が同じシステムベンダーかどうか、パターンを分けて少し深堀りする。

# 開発と運用保守が別ベンダーのパターン

いわば開発側は納品して検収もらってさよなら～後は知らん！という感じになるので、運用保守を考えた作りや、品質向上の取り組みなどはほぼやらない。

運用保守を考慮した設計開発となれば、コードの変更しやすさや拡張性、性能や負荷、セキュリティなど様々なことを考え実装が必要になり、ただ動くものを作るだけとは雲泥の差がある。作り逃げするようなビジネスモデルである種成功体験を繰り返し、そういう会社がまた開発だけをやることで、いつまでたってもその会社や人のスキルがあがらず、また新たな悲劇を生む悪循環となる。

また、運用保守側はある種それは織り込み済みで、自分たちが作ったんじゃないのでこれはうちの瑕疵ではない、あ～大変だ～的な被害者ムーブができ、障害起きたり修正に時間かかったとしても怒られないよう防壁が張れる。

本来ならば改善義務や効率化義務もあるが、それをやるよりボロボロの環境で効率悪い運用保守をしたほうが、会社的にも楽だしリスクもないので、基本やらない、提案しない、やれと言ってもあれこれ理由をつけて結局やらない。

# 開発と運用保守が同じベンダーのパターン

自分たちが保守するのである程度ちゃんとしたつくりにするが、あえてドキュメント化しなかったり自社独自の実装を入れたりして、ベンダーロックを意図的に仕組む悪い輩がたまにいる。

そうなると、他のベンダーだとなかなか対応ができず、ほぼそのベンダーの言いなりで保守費用とられ続ける。

そしてそれにしびれを切らし思い切ってベンダーを変えると、だいたいもめる感じになって引継ぎもちゃんとやってくれずほぼぶん投げのような形で新しいベンダーがやる形となる。 そうなると、当然実装意図や注意点などがわけわからず、その状態で追加機能開発やバグ修正などを繰り返して、バグや障害が発生したり、つぎはぎだらけのどんどん悪いシステムになっていく、そしてまたそれでベンダー変更や撤退し繰り返し。

こういった爆弾リレーをやっていくとどこかで必ず爆発し、その時やっていたシステムベンダーがババを引き割を食う形となるのが良くある話。

# 発注側はどうすればシステムベンダーにいいようにやられないか？

# 先に結論

正解だけを簡単に言ってしまうと、システムベンダーのエンジニアより上位互換な技術を持った自社社員を担当につかせてベンダーマネジメントする。これだけ。

# 現実的な話

ただそれが昨今の IT エンジニア不足なども相まって、それなりの知名度ある会社や大手の会社でなければなかなかできないと思う。

なので、それが難しい場合は外部の信頼できる優秀なエンジニアを確保するしかない。

WARNING

その際のアンチパターンとして、人材紹介系の会社にエンジニアを探してもらうパターン。人材紹介系の会社は商品（エンジニア）を如何に高く売るかしか基本考えてない（それが悪いと言ってるわけでなくそういうビジネスなので企業の利益追求として当然のこと）ので、本当にできる人かや自社の為に尽力してくれる人かなどはほぼ期待できない。

# ではどうやってそれを確保するか？

リファラルで探すことがベストだと思っていて、自社と同じ業界やシステム会社に外注をしている会社と積極的に交流を取り、今現在一緒に働いていて実績がある信頼できる会社を紹介してもらうのが一番いいと思ってる。

なので、SNS でのつながりや、交流会などに参加して、人材ネットワークを広げていくのがなんだかんだいいと思っている。

その際、発注者と受注者が交流するようなところにはいかないほうがいい。そこに来ている受注者は営業で来ていて、いいことしか言わないので。あくまで発注者のネットワークを広げそこ経由で実績あるシステム会社やエンジニアを紹介してもらうのがベスト。

# まとめや所感など

つらつらと書いたけど多分この問題や構造はずっと解消しないと思うので、やっぱシステム開発は内製に限る、と元も子もない事を言ってしまう。