SIer選定を行う際に注意すべき点①
これまで多くのトラブルプロジェクトやお客さまの不満に触れてきて、私なりに「よいSIer、ダメなSIer」というものが徐々に何となく言語化できるようになってきました。
今は、お客さま側…ユーザー側に立ってSIerと向き合う立場にあることもあって、ますますそうしたユーザー側の「失敗」を黙って見過ごせない、そんな気持ちになっています。
当たり前ですけど、SIer…いわゆるＩＴ企業もピンキリです。
大きい会社だからいいとか悪いとか、価格設定が良心的だからいいとか悪いとか、そういう見方もあるでしょう。決してそれがダメというわけではありません。
しかし、それ"だけ"ではダメだと断言できます。
数多くのトラブルプロジェクトを見てきたからこそ、ほかの誰よりも「そうである」とハッキリ言いきることができます。もちろん発注者…ユーザー側に問題があってトラブルになるケースも多く存在するのですが、どちらにしても請負や準委任などで業務を委託された以上、プロジェクトマネジメント義務の範疇において正しくその義務を遂行できなかった受注側…ＩＴ企業側に問題があるのは否めません。
いくらユーザー側にＩＴリテラシーと呼べるものが全くなかったとしても、そういうＩＴ化プロジェクトの責任者や担当者に選ばれたのであれば、多少はＩＴ企業というものを理解する努力が必要になります。
もちろん独学では難しいでしょう。
そうした内容を教えてくれる書籍等はなかなかお目にかかれません。あってもSIer選定を目的とした書籍ではなく、あくまで派生したネタとして書かれていたりするため表紙やタイトルなどからでは探しにくいという背景もあります。
それに企業の存在丸ごとを「否定せざるを得ない」ほど酷いというケースも相当珍しいと思います。
通常は、企業の中のごく一部の開発メンバーや部署だけがおかしなことをしているケースがほとんどで、企業丸ごとが信用ならないほど腐っているということはあり得ません。そんな企業があったらもっと早く社会的に問題となっています。そのため、企業名だけで良し悪しを特定できない…というのがこの業界の通例です（いやまぁ、一部でも腐っている時点で、その会社の人事制度や採用基準、教育制度等どーなってんの？という疑いはあるわけですけども）。
とはいえ一般的な入札条件のように「価格点」や「技術点」だけでは測れない…全く異なる側面からの評価ができないようでは今後もSIer選定、ベンダー選定の時点で失敗する可能性を回避できません。
できるだけ失敗や苦労をしたくないのであれば、これからは別の角度からの観点も加えていくことをオススメします。
閑話休題
ちょっとその前に。
「SIer」とか「ベンダー」って何？と思った方もいらっしゃるかもしれません。
私もこれまでさんざん書いてきてて今更な気がしないでもないですが、念のためここで振り返っておきたいと思います。
現在、国内には43,000社以上（令和３年時点のＩＴ企業は43,006社（内 中小企業は 42,454社））のＩＴ企業が存在しています。そのすべてがSIerというわけではありませんが、それでもやはり競合する客層や業界は重複することが多くしのぎをけずっています。
SIer（エスアイヤー）
ＳＩ（System Integration）というサービスを提供してくれる企業のことです。SIに「～する人」という接尾辞「-er」を付けてできた造語で日本国内でしか通用しません。「システムインテグレーター」とも言いますが同名の企業がすでに存在しており、混乱を避けるため一般的には用いません。
SIerには大別して「メーカー系」「ユーザー系」「独立系」が存在しています。
メーカー
ハードウェアやソフトウェア等、自社製品を製造・販売する企業のことです。ＩＴ業界では比較的珍しいかもしれませんが、パッケージ製品を作成・販売している一部の企業などはメーカーと呼べるかもしれません。しかし自社製品のみを販売する…という形態の企業は決して多くありません。
ベンダー（ITベンダー）
ハードウェアやソフトウェアを販売・提供する企業のことです。しかしメーカーとは呼びません。その販売する製品のなかにOEM（Original Equipment Manufacturing：他社ブランド製品）を含む場合はベンダーと呼びます。たとえば、自社のハードウェアに他社のOSやミドルウェアを抱き合わせで販売することはＩＴ業界では珍しくありません（というかそのケースがほとんど）。
ベンダーとSIerの境界はなかなか難しいところで、多くの場合はSIer兼ベンダーとして活動していることのほうが多いかもしれません。今どきは他社ブランドの製品を利用したり、パートナーシップを結んで営業したり…なんてことは珍しくもありませんしね。
では、そんなベンダーやSIerを選定するうえで、できるだけハズレのプロジェクトチームや企業を引かなくていいようにするにはどうすればいいのでしょう。
非常に多くの判断基準があると思いますが、少しずつ紐解いていきたいと思います。
選定の心得「導入実績の見せ方」
よいSIerというものは、導入後の顧客満足度でアピールすることが多いものです。
導入後に顧客満足を図る企業は多いと思いますが、その効果測定結果をわざわざ提示するのは自信の表れともいえるからです。ここで「導入後に顧客満足を図る企業は多い」と言いましたが、なかでもQMS（ISO/IEC 9001）の資格を取得している企業であれば間違いなくしているといっていいでしょう。
なぜなら、QMSの定める規格の要求事項にそれらしいことが記述されており、資格を維持し続けるためにはその要求事項を満たし続けなくてはならないからです。
9.1.2 顧客満足
組織は，顧客のニーズ及び期待が満たされている程度について，顧客がどのように受け止めているかを監視しなければならない。組織は，この情報の入手，監視及びレビューの方法を決定しなければならない。
注記：顧客の受け止め方の監視には，例えば，顧客調査，提供した製品及びサービスに関する顧客からのフィードバック，顧客との会合，市場シェアの分析，顧客からの賛辞，補償請求及びディーラ報告が含まれ得る。
しかし、QMSはプライバシーマークのように事業所全体が取得しなければならないものではありません。一部の拠点や一部の部署のみが取得することも可能です。実際、ある程度の規模を持つSIerやベンダーであればそうしている企業も多いでしょう。でも、だからこそ
「企業内ではQMSを取得している部署や拠点もあるのに
提案してきた開発チームの所属する部署は取得していない場合
ＱＭＳ程度の品質維持も難しい組織が提案にきているのかもしれない」
ということが予測できます。
こういったことは、価格点や技術点のみでしか測れないようでは致命傷となりかねません。契約を結んでしまってからトラブルを起こされた場合、損害賠償請求などはできるかもしれませんが、そこに費やした時間は帰ってきません。自社内の人件費なども返っては来ないでしょう。結果、ビジネスチャンスを逸してしまい、大きな機会損失まで生み出してしまう可能性があります。
もちろんQMSを取得しているからと言って末端のプロジェクトマネージャーやエンジニアがその仕組みや規格の要求事項をあまり理解していない…というのは、長年私自身もＩＴ企業内でQMSやプライバシーマークを運営してきた手前、嫌というほどわかっています。現実には、管理職や経営層ですらろくに理解していない人ばかり…という企業も多いのではないでしょうか。
正直、ＩＴ企業に限って言えば、
「QMSを取得しているというだけで、信用できる要素は微塵もありません」
酷なことを言うようですが、規格の要求事項を理解し、体現しようとしているプロジェクトマネージャーやエンジニアなんて一人もいないのではないでしょうか。少なくとも私が見てきた何千人という人々のなかには一人もいませんでした。
それでも年に１度の審査用にエビデンスを捏造したり、模範解答を用意したりで資格の維持をし続けるのには、公共入札への参加資格を得るためであったり、箔をつけたいという思いもあるのでしょう。
資格を与える認証機関としても審査対象が減ると収益が落ちるため、仮にその審査が出来レースだったとしてもよほどの事故・事件でも起こさない限りは体裁が整っている以上、資格喪失させるようなことはしないでしょう。
QMSの資格を維持するには、どんなに中身が形骸化しているといっても必ず多少なりとも負担（課長で２～３人日/年、末端の担当者なら0.5人日/年未満）を負うことになります。それすらも負うことができない部署…というのは、日頃からの業務の質が相当悪い（組織的なプロセスになっていない）可能性が高いことを意味します。
企業そのものがQMSに無関心であるのならばともかく（維持費もバカになりませんし）企業内の一部が取得しているにもかかわらず、提案してきた部署は取得していない…というケースでは、このような背景まで見え隠れするということを覚えておいてください。
また、だからといってQMSを取得している部署だったとしても安心はできません。
顧客満足度をアピールポイントとしている場合は多少なりとも信用できますが、もしも単純な導入件数や事例でアピールしてくるような場合は要注意です。
その時は導入先の客層をチェックしてみてください。
お客さまが点々としている場合
過去の事例を見たとき、顧客あたりのプロジェクトが単発のみで終了していることが多く、保守開発やリプレースなどにあまりつながっていないような場合、あるいはグループ企業であるにもかかわらず他の部署や企業への展開がほとんどされていないような場合は、一応顧客に納めはしたもののあまり良い評価を得られず、次のビジネスにつながらなかった可能性…つまりは顧客満足度が低い進め方しかできなかった可能性があります。
社会的な事故を起こすようなレベルでない限り、業務システムの内情などはあまり口コミで広がったりはしませんので、噂の届かないお客さまをとっかえひっかえして実績数だけ稼いできた…というケースも少なくありません。
多くの場合ではリリース後、しばらく保守も引き受けているのでしょうが、その期間が切れた後の改造やリプレースに携わっていない場合などは、相当お客さまに愛想を尽かされていることも念頭に入れておいたほうがいいでしょう。
顧客満足度が高ければ、お客さまは必ずその後も任せたいと思います。
ただでさえ何千万、何億、何十億…時には百億以上ともなるシステム開発プロジェクトです。お客さま側もそうそう簡単に新しいSIerに切り替えたくはありません。未知のSIerを選ぶ責任というのはかなり分の悪いギャンブルだからです。
そのため、本当に満足できるSIerだった場合、次の更改の際にも継続してお願いしたくなるものなのです。
偏った業界ばかり実績がある場合
たとえば「販売管理」や「生産管理」などというと、取り扱う商材は違えどほとんどの企業で似たようなビジネスモデルが採用されているはずです。そういったシステムの場合、そもそも客層が偏る必要がありません。むしろ顧客開拓をしたいのであれば、様々な実績を積みたいはずですから、業界を手広く拡大したほうがいいに決まっています。
しかし、かなり絞り込まれた業界のみにばかり長年かかわっていると、そこでどんなに成功を収めても、ほんのちょっと異なる業界に踏み出したときに思わぬ衝突を生み出すことがあります。
みなさんもご存じのように、ある程度思考が固まってしまうと、人は過去の実績に固執してしまう傾向があります。
「前はこれでうまくいった」
などという言い訳をする人を見たことがありませんか？
これを つぶしがきかない 状態といいます。
開発側のプロジェクトマネージャーやエンジニアがこの言葉を言い出して、何の説明責任も果たそうとせずにお客さまのニーズや要求をはねのけようとした際には相当マズい状況と思っておいたほうがいいでしょう。
今後、同じようなことがみなさんの前でも繰り広げられる可能性があるからです。
SIer…というかプロジェクトマネージャーやエンジニアは
これまでの実績を積み重ねた業界 ≠ これから関わる業界
となった場合、これまでのやり方に固執して目の前にいるお客さまのニーズや事情を軽視してしまうことがあります。「これまでのやり方」を前面に推してくるようなSIerの場合は注意してください。現行システムが提供してくれていた業務サービスすらも無視して自分たちのエゴを前面に押し出してきて、結果ユーザーニーズを置いてけぼりにしてしまう可能性もあります。
ＩＴリテラシーに疎いからと、SIerに任せっぱなしにしていると自分たちが望んだものとはずいぶんかけ離れたシステムとなってしまっていることになりかねません。その結果、現場ではロクに利用されず、何十億、何百億ものお金をドブに捨てた発注者…というのも１つや２つでは済まないほど見てきました。
リピート率が高い場合
意外と思うかもしれませんが、客層は狭いわりにリピート率が高い場合も要注意です。その際は、導入されたシステムアーキテクチャに注目してください。もしも
ベンダーロックインの可能性
がありそうであればそれは危険信号かもしれません。表向き、ユーザーニーズを一応は満たしてくれるかもしれませんが、後々データや業務を人質に取られたような状態となりかねません。
よほど満足度の高いシステムやサービスであれば、むしろベンダーロックインしてもらったほうがいいのかもしれませんが、５年後10年後を見据えたときに「別のSIerやITベンダーに切り替えたい」といった際、それまでのシステムやデータのすべてを失う覚悟がなければ止めておいたほうがいいでしょう。
ある程度の年数が経つと否応なく保守費等がバカみたいに高くなります。
当時の技術を知る人が少なくなっているということもあるし、すでにサポートが切れたライセンスやソフトウェア、ハードウェアを使っていると、その保障などのためにも高額化しかねません。だからこそ定期的にリプレース（再構築）することになるのですが、その際にベンダーロックインはとてつもない足枷となりかねないのです。
選定の心得「要件定義の進め方」
SIer選定の際、あまり実施される発注者は見たことありませんが、可能であれば「要件定義」工程や「基本設計」工程の具体的な進め方についてきちんと提案してもらっておくといいでしょう。
特に「要件定義」から始める場合は、要件定義に注目です。
従来、システム開発をするというのは、発注者にとって現状の運用では何かしらの問題、あるいは課題が生じたということを意味します。それら問題や課題を解決するからこそ、多くのＩＴ企業では「ソリューション（=解決）」という名称を企業名や部署名に多用するようになりました。
そのため、要件定義とは
①AsIs（現状）を正確に把握し
②そのうえでToBe（理想）をお客さまから抽出し
③AsIsとTobeの間にあるGapを整理して
④具体的にどのようにするかを定義する
という順で言語化することが求められます。
これは最低限必須といってもいいでしょう。
これが１つでも行われていない要件定義は、お客さまの真に求めているニーズを何も理解しないまま、開発チームが好き勝手に予算と時間を食い散らかしてトラブルを起こさせるということにほかなりません。
もし、今まさにＩＴプロジェクトが進行しているお客さまの要件定義において
「AsIs（現状）の詳細把握」
「ToBe（理想）の要求整理」
「AsIsとToBeのギャップ分析」
いずれか一つでも不足しているようであればとにかく疑ってかかってください。契約形態なんて関係ありません。開発側のチームがどう考えているか、どう認識したかなんて一切関係ありません。作り手のノイズが入り込んでいい隙なんて一部もありません。
「お客さまが何がどう変わることを望んでいるか」
要件定義のなかではそれだけがすべてです。
それができていない、実施しない、する気がないということは、「お客さまの要望を叶えない」と言っているのと同義です。
この大前提を理解している開発チームであれば前述のとおり、AsIsとTobeをすべて洗い出すことに注力するはずです。１つでも漏れていればお客さまの業務に支障をきたす可能性があり、内容によっては致命的な問題となりかねないからです。
ですから、SIer選定において提案プレゼンをしてもらう際には是非とも聞いてみてください。
「御社ではどのようにRFPにある当社の課題を解決していただけるのでしょうか。
まずは要件定義の段階でどのようなアプローチを想定しているのか、
具体的な計画を交え、ご説明いただけますでしょうか」
この時点で概算以上の見積りが済んでいるのであれば、答えられるはずです。具体性が伴わなければ見積り結果についても精査できていないのと同義ですし、そんな状態で上司や会社は見積書の提示を許可するはずがありません。
超概算の場合はそこまで説明することは難しいでしょうが、概算といえば既にお客さま側でも予算確保のために動けるレベルの精度となっていなければなりません。正式見積ならなおさらです。
そのため、多くの場合において「工数 × 単価」で見積もりを行うであろうSIerはその工数見積りの根拠を明確にし、それなりの確度をもって提案しに来る以上、当然ながら各工程の作業内容や作成成果物、必要な要員などもそれなりにバッファも積みながら洗い出しているはずです。
であれば、要件定義をどのように進めようとしているか、そのシナリオも説明できないはずがありません。
もし説明できないのだとすれば、それは見積根拠の方を疑うしかありません。
というか答えられない時点でもう信用の欠片もないと言っていいでしょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。