ぜぜ日記

ブログです

システム開発が残念なことになってしまう問題について業界構造から考えてみた

システムインテグレータの中の人と話していて業界の構造が問題案件を生み続けてるのかなと考えてみたので簡単に書いてみます。主観ばかりです為念。

1.前置き。システムインテグレータについて

システムインテグレータとは顧客が使うシステムを提供する業種です。社内システムからeコマース、銀行の勘定系からお役所まわりのシステムをつくっていて運用したりしてます。SIerとも言われますが、これは和製英語だそうです。ネット上でたまにIT土方デスマーチと揶揄される舞台となるところでもあります。

こんなおもしろくなさそうなテーマの記事を読むのは、システム開発に関係する人くらいな気がするので、前提はカットします。興味がある人は、「SIer」でタグ検索(人気順) - はてなブックマークでも見てください。暗澹とした気持ちになること請け合いです。


2.現状。増え続ける問題案件。デスマだわーい!

大手システムインテグレータまわりで問題案件がたくさん発生してます。最近だと特許庁やスルガ銀の案件はマスコミにも取り上げられました。

このほかにも、大小を問わず、炎上してデスマーチになってしまう問題案件は増え続けているらしい、です。不採算案件の数などはどこも公表するわけないのでわかりませんが・・。
そして、会社としての売上・利益こそ下がっていなくとも、国内マーケットの縮小に加えてこういう不採算案件が多発してると、システムインテグレータだけでなく、それにシステムを依存しているユーザ企業もリスクが大きくなっている気がします。状況の収拾に追われて先行投資や教育も後手後手になってる印象もあります。

3.原因はなにか?なぜ変えられないのか

ソフトウェア開発の方法論も進化しているし、生産性の高い言語やフレームワークも普及していて、なにより失敗の積み重ねという反省の機会があるのになぜ問題案件は増えているのでしょうか。建築では、橋が落ちたり建物が崩れたりするときちんと原因が分析されて、再発しないようになっています。


先の2つの失敗案件の公開されている報告書などを読むと、どちらも技術上の問題というよりは要件定義あたりのコミュニケーションの問題が大きいようです。いろいろ話を聞いたり考えてみると、要件を調整できないダメサイクルに陥っているように思えます。
そこで、自分が見聞きしたこと思ったことから問題プロジェクトの原因を考えてみます。といってもすでに書き古されたテーマなので焼き直しでしかないかもしれませんが、業界構造、顧客とシステムインテグレータの関係を分析したものはあまりないようなので適当分析ですがご容赦ください。ばしばし叩いて穴とか指摘して欲しいです。


3.1 遠すぎるエンドユーザ。要件を調整できないシステム部門。

まず登場人物について、それなりの規模のシステムをつくる際、一般には次のような関係者がいるようです。(違うケースも当然あります)

  1. ユーザ(ECとかだと一般市民、社内システムだと社員)
  2. 顧客企業システム部門
  3. システムインテグレータ(元請け)
  4. 下請け企業(含 オフショア先)

そしてシステムをつくる際には、いきなりエンジニアがバリバリコードを書いていくのではなく、まず要件をどう定義するかが重要になります。スーパーエンジニアがたくさんいても、残念ながらシステムはつくれません。残念ながら・・。
要件とは要するにどんな機能が欲しいか、ということです。外野から考えると、システムをつくるといったん決めたのなら自ずと決まってくるのでは?と思うかもですが、これが難しい。ユーザがどんな機能が欲しいか分かっていない場合もあるし、人がいれば人がいるだけ意見が合って対立・矛盾があることも多いです。

要件を定義してもころころ変わってしまうこともあります。そしてエンドユーザに振り回される顧客システム部門、に振り回されるシステムインテグレータ、に振り回される下請け・・というだめだめな構造になってしまっているのも散見されます。ダメトリクルダウンです。勘弁してくれ。

本来は、顧客企業システム部門がきっちり要件を調整、定義してシステムインテグレータを使えば、問題も少なく費用も少なく完成できるはず。むしろ要件定義がちゃんとできれば直接にオフショア先などに出しても作れるはずなのです。バカ高いシステムインテグレータに依存しなくてもいいね!聞くところでは欧米の企業ではそういう開発が多いらしいです。

日本では、顧客企業のシステム部門がうまく要件を定義できないことが多いように感じます(他国とちゃんと比較してるわけではないですが話を聞く限り)。
それはシステム部門の人が無能だからとかではなく、顧客企業の中で、システム部門がコストセンターとして軽視されているからなようです。そのために人員も少なく、社内システムの運用・サポートばかりで開発の経験が少ないひとが多くなっています。すると開発に際して、社内ユーザから、次はこんな機能をいれてくれとか、これが欲しいとか、あの機能がないとかありえないでしょみたいな意見をまとめることができません。その結果として、社内の意見をそのままシステムインテグレータに流さざるを得ないことになる。

それだけでもシステムの要件は肥大化します。システムインテグレータからこの機能はどうするかという話があっても、システム部門は中継するだけでオーバーヘッドが大きくなるし、なかなか決められないことと調整コストが大きいことから、システムインテグレータはエンドユーザではなく顧客企業のシステム部門のためだけにシステムをつくることになってしまいます。

流行りのアジャイル開発では、顧客を巻き込むということが成功の秘訣となっていますけれど、巨大な規模のシステムで多数の関係者がいるなかでは巻き込むことは難しいです。実際にお金を稼いでいる現場の人は、直接にはお金にならないシステム部門にそうそう時間を割いてはくれません。

というわけで要件が決められなかったり、あとで変更になったりすることで問題案件が増えていきます・・・。


3.2 技術よりもコミュ力を重視するシステムインテグレータ

ここまでは顧客企業に原因があるという風だったけれど、システムインテグレータ側にも原因があります。


前節で触れたように、かつての問題案件では、技術よりも要件を定義するという顧客と調整する力がボトルネックでした。それで今で言う、コミュニケーション力のようなものを重視するようになっています。中途採用でも、技術力ではなく、業務知識などを必要とするものが多いのが見て取れます。

これと並行して、お金の問題でも技術から離れるようになっています。かつてはみなプログラマから、経験を積んでプロジェクトマネージャーになっていましたが、プログラマの単価が低いからと、コーディングは下請けに出して、新卒からプロジェクトマネージャー的な業務(ドキュメント作ったり管理したりとか)するようになっている。
いまでは入社1年でコーディングするひとが何割いるんだよという超大手システムインテグレータでも、かつては新入社員研修でJavaの言語仕様などを読んだりしていたこともあるらしいです(何年前だろ)。

その結果、システムのつくりがわかっている人が少なくなっているように思えます。すると顧客との調整で要件の調整やリスクの見積りが難しくなってうるような・・。別要因で設計や開発の機会が減っているのもあります。

このために、目先の要件定義ができないという問題を解決するためにコミュニケ-ション力重視になって、技術力が低下、それによって要件定義ができなくなるという気がしています。


3.3 原因まとめ:相互依存の末に

なんで顧客企業ではシステム部門が弱いかというと、経営者のIT軽視だけでなく、かつてシステムインテグレータがシステム部門の代わりにわたしたちがやりますよと甘言を弄して、骨抜きにしているというのもある気がします。ユーザ企業とシステムインテグレータが合同でつくった会社がどういう経緯でできたか考えるとちょっとこわくなります。

ところがシステムインテグレータも技術を下請けに依存するようになっています。ますます技術と顧客の距離が開いてオーバーヘッドは大きくなっているような・・・。
顧客とシステムインテグレータがお互いに依存していながら距離が開いているという、まるでお互いに依存しながら足を引っ張るダメカップルのようです。


4. 対策:顧客のできること、システムインテグレータのできること

こういう構造なんじゃないかという指摘が主題なのであまり対策は・・・。

月並みなことしか書けないですが、顧客は直接開発会社に出せるくらい要件を整理する。もしくは内製する。システムインテグレータはお客さんを巻き込んで仕様を調整できるくらい業務知識に精通した強力な技術営業が必要。くらいでしょうか。あとは契約体系を変えて小さなスコープごとに反復ウォーターフォールとかかなあという気がします。

とはいいつつ、そう簡単にできれば問題でもなんでもないので、どちらも肥大化してブラックボックス化した化物システムに押しつぶされる気がして良くないです。。


で、それに翻弄される開発者たちはアジャイル開発やろうという方々と、これまで通りにウォーターフォールでいいんだというのに分かれているように思えます。そしてウォーターフォール派はアジャイル推進派を急進的な極左冒険主義と罵り、アジャイル派はウォータフォール派を日和見右翼どもと軽蔑する。そしてかつての革マル派中核派のように血で血をあがなう内ゲバが吹き荒れるのであります。というところまではいかずにどっちの派閥も現在の火を噴き出しているプロジェクトの収拾に追われて中長期のことを考えることができないという状態で一日一日を戦っているのが現状でしょう。
ほげー

* * *

所属組織の見解とは関係なく、個人の想像です為念。ここでだらだら書いたことは検証してませんしどう検証すればいいかも分かりません為念。ぺぇぺぇの世迷い言かも。
システムインテグレータはどうしたらいいかとかヒントになりそな記事や本があれば教えてください。



顧客主導でシステムを開発するお話。たぶんほとんどの会社だと無理。

昔に書いた記事
システム投資はどーなるのか。「ITに巨額投資はもう必要ない-600億円の基幹システムを60億円で構築した Jメソッド導入法」を読んで - 自律分散うんこ製造システムに関する考察メモ



口語でなぜか読みにくいし読んでて不愉快になる本