山崎屋の技術メモ

IT業界で働く中でテクノロジーを愛するSIerのシステムエンジニア👨‍💻 | AndroidとWebアプリの二刀流🧙‍♂️ | コードの裏にあるストーリーを綴るブログ執筆者✍️ | 日々進化するデジタル世界で学び続ける探究者🚀 | #TechLover #CodeArtisan、気になること、メモしておきたいことを書いていきます。

システム開発の「訴えてやる!」

f:id:yyama1556:20160514130059j:plain

仕事がら、@ITのページをよく読む。

www.atmarkit.co.jp

 

SIerに所属するSEとして、勉強になる興味深い内容の記事を無料で読めるので重宝している。なかでも、失敗プロジェクトから訴訟に発展した実話をもとにトラブル予防策を提言している「訴えてやる!」のシリーズが好きだ。発注側の企業にとっても勉強になると思う。

やじうま感覚で、最近公開された次の記事について考えてみた。

www.atmarkit.co.jp

 

ちなみにSI(システムインテグレーション)とは「システムの受託開発」。平たく言えば、ユーザに「こういうもの作って」と要求され、そのとおりのシステムを作って納品し、お金を受け取る商売のこと。SIerエスアイヤー)とはSIを生業とする会社のこと。

それに対し、自社サービスを自社で開発するサービス提供会社(クックパットとか)やスマホゲーム会社(コロプラとか)がある。

あらすじ

あるITコンサルタント会社(以下、SIベンダー)は、鉄鋼工業者(以下、ユーザー)から、生産管理システムの開発を請け負った。開発はパッケージソフトをカスタマイズして行われることになり、その開発企業(以下、パッケージベンダー)もプロジェクトに参加し、カスタマイズ部分の設計・開発を請け負った。


ところが、プロジェクトはパッケージソフトのカスタマイズ要件を定められずに、スケジュールが遅れ、このままでは、要件定義の完了も、それを受けて作成するカスタマイズ仕様書も、全く完了する見込みがなかったことから、ユーザーは契約を解除した。


これについて、SIベンダーは要件定義が完了しなかったのは、パッケージベンダーの債務不履行であるとして、これに損害賠償を請求し、訴訟に至った。

http://www.atmarkit.co.jp/ait/articles/1605/10/news022_2.html


設計・開発が遅延とかならよく聞くが、要件定義で頓挫とか、ユーザ・ベンダー・パッケージベンダーとも何がやりたかったのか。


f:id:yyama1556:20160514130150j:plain

ダメだこりゃのベンダー

おそらく担当者は、大手SIerの社員で、下請け業者に丸投げすれば、自分は線表(スケジュール表)を眺めているだけでシステムが完成すると思っていたのだろう。

一昔前であれば、SIer専門の下請け業者が、契約上の役割分担なんて気にせず阿吽の呼吸でうまくやってくれていたが、予算の関係かなにかで、パッケージベンダーに直接注文することになったのか?

パッケージベンダーが今まで使っていた下請けと同じようにいろいろやってくれると思っていて、蓋をあけたら、「要件定義はそっちの仕事でしょ?」とかいわれてしまい、「えっ!?」ってなった担当者の顔が目に浮かぶようだ。

たしかに、日本のSIの仕事は役割分担が結構あいまいで、SIならではの(プロジェクトの空気を読みながら自分の役割を探していくような)ノウハウが必要だったりする。

自社製品の開発を主にやっているパッケージベンダーでは、そのあたりの(いいのか悪いのかわからないが)ノウハウがなかったのであろう。

『「出番が来たら、仕事します。それまでは何か質問があれば言ってください」というパッケージベンダー態度』と批判的に記事中にはあるが、パッケージベンダーとしては、むしろこれが本来の姿だ。ただし、プロジェクトの成功という共通の目的をこのパッケージベンダーが持っていることが前提になるが。

兎にも角にも、「パッケージベンダーが非協力的で要件定義ができなかった」というベンダーの言い訳は通用するはずがない。要件定義くらいできるだろう。そのための元受ベンダーだろう。それをやらなくて何をするつもりだったのか。中間マージンを搾取するだけで、利益を上げようとしているベンダーだとしたら、滅びたほうが世のためになる。


f:id:yyama1556:20160514130847j:plain

ユーザ企業の問題

ユーザ企業にも問題がある。

このパッケージを実際の業務に当てはめて、どのように使うのかまったく考えていなかったのではないかと思う。もしこれを真剣に考えていれば、要件定義(の一部になる業務の整理)などそんなに難しくないのだ。

話は飛躍するが、日本ではユーザ企業(の現場レベル)がシステム開発について関心が薄いと考えている。たしかに、従来のやり方を変えることは面倒くさいし、その心情も理解できる。しかし、要件定義(の一部)くらい自分たちでやったほうが、早いし正確だし安いのだ。もちろんプログラミングスキルなど必要ない。自分たちがどのように仕事を進めているのか、整理するだけだ。

たとえば、

電話で注文を受ける→倉庫に電話をかけ在庫を調べる→在庫があったら予約する→正式受注する→発送手配する→請求書を送る→振込みを確認する。

とか、かなり大雑把に書いたがこんなことだ。これを改めて整理すると、自分たちで無駄な業務に気づくかもしれない。業務改善のチャンスでもある。

これを業務を知らないベンダーにやらせているのが今の要件定義だ。自分たちが、暗黙の了解も含む習慣でまわしていた業務を、外のベンダーが正確に把握するのは難しい。そして本来の業務が忙しく、ベンダーの質問に答えている時間も限られる。

しかも、その代償(システム開発費の高騰)を自分たちが支払っていることに気づいていない。もしくは、現場レベルでは気づいているかもしれないが、上を動かしてまで改善する気にはならないのだろう。

f:id:yyama1556:20160514130406j:plain

まとめ

ビジネスの国際などに伴い、旧来の阿吽の呼吸が通用しない外資ベンダーやパッケージベンダーと直接プロジェクトを推進していくことも増えていくだろう。このような訴訟問題に発展しないためにも、SIerは自社の役割・他社の役割を明確にし、自分の役割が十分果たしていけるような組織作りをしていかないといけない。自戒もこめて。

まして、何のスキルもない社員(これを「管理能力のある社員」とか言っている)を抱え、中間マージンだけを得るビジネスは時代遅れになるだろう。