古き悪しき”お客さま第一主義”

他の業界ではわかりませんが、ＩＴ業界に限って言えば…さらに言うなら、Ｂ２Ｂでシステム開発を行っているような企業に限って言えば、

　「お客さまは神様だ」

という考えは捨ててください。それは、組織悪、企業悪、そして社会悪となる考え方です。少しでも、ＩＴ調停の内容などに目を通していると、

　「システム開発は、ユーザーとエンジニアとの協同作業である」

とは、昨今の判決の中でも良く聞かれる言葉であることがわかります。

ですが、現実に私の目の届く範囲の開発現場を見ていると、この辺りをきちんと理解できているユーザーやSIer、エンジニアはまだまだ少数派であるというのが実感です。

ユーザーは「お客さま」であり、ＩＴ開発はSIerに"お任せ（丸投げ）"、SIerもユーザーには顔色をうかがい気を遣うばかりで、本来ユーザーが負うべき責任、やるべき作業を怠ってもそれを指摘したり是正したりという努力は十分にはできず、結局ズルズルとプロジェクトが遅れ破綻してしまう状況を幾度見てきたかわかりません。

そうやって進んでいく中で大きな歪みが生まれ、最終的に大問題となっても、ＩＴ企業の中では自分たちの業績ばかりを気にして、稼働分の予算が回収できればなんとなく「問題が無かった」かのように取り扱われることもしばしばです。

が。

実際にはプロジェクト的に見ても、社会的に見ても、コンプライアンス的に見ても大問題です。目先の業績さえ良ければいいと言うものではありません。

そこに関わった、決定権や決裁権を持たない従業員の多く、従業員の人生の多くを犠牲にし、ときに疲弊させ、ときにストレスを蓄積させ、ときに精神疾患や自主退職を余儀なくさせているわけですから、何も問題がないなんて言わせません。

最悪、直接人を殺すよりも残酷なことをしていると言う自覚を持つべきです。

　

そのような状況が生まれる文化は、昔から変わらないＩＴ開発現場でよくみられる、悪しき”お客さま第一主義”が原因です。

本来はユーザーがプロジェクトの一員として責任を持った仕事をすることを、SIerこそがプロジェクトマネジメントの一環として監視し、コントロールするべきことなのですが、特に古くから、お客さまであるユーザー企業を良くも悪しくも大切に考える日本文化ではなかなか頭を切り替えられないというのも事実のようです。

あるユーザー企業が基幹システムの刷新をSIerに依頼し、SIerは要件定義作業の完了後、外部設計、開発、運用準備、移行支援作業の契約を受けて順次実施していった。ユーザーからはフェーズに応じて順次費用の支払いも行われていたが、ある時、突然に後続作業の前渡金支払いを拒絶し、その後、契約解除の通知を送付してきた。

契約解除の理由としてユーザー企業が訴訟において主張したのは、（ベンダーが順次リリースした） 成果物には多数の未納や遅延・不備があり、これは履行遅滞による債務不履行にあたるということだった。

一方で、ベンダーはこの契約解除通知は、民法641条（注文者による請負契約の解除）に基づく解除通知（ユーザーの都合による解除）であるから、ユーザー企業が損害賠償責任を負うと主張し、当初約束した開発費用の支払いを求めた。（東京地方裁判所 平成27年3月24日判決より）

少し補足すると、SIerとしても未納や遅延・不備の存在は認めるものの、そこにはお客さまの協力が不十分だったためであるとの主張をしています。

具体的には以下のようなことです。

　1. 外部インタフェース仕様の整理が遅れたこと
　2. SIerの提示した移行作業方針および
　　移行処理方式の回答をしなかったこと
　3. ソフトウェアを動作させる環境の構築が
　　ユーザー企業の都合で延伸されたこと

つまりプロジェクトが遅れたのは事実ですが、その原因はユーザー企業側にあり、自分達に非はないというのがSIer企業側の主張です。

成果物の未納や遅延・不備がSIerだけの責任であったかどうか、上述の1、2、3が本当にスケジュール遅延や品質の低下をもたらすほどの重大事であったのか、その辺りがこの争いのポイントとなりました。

（未納、遅延・不備について考えてみると） ユーザー企業の分担に係る外部インターフェース仕様整理がされていないためにインターフェース一覧が未納であること、SIerが移行作業方針及び移行処理方式の確認を求めたのに対し、ユーザー企業の回答がないために「システム／データ移行設計書」が作成できなかったこと、環境構築がユーザー企業の都合で延伸されたため未納となっていることが認められる。

上記前提事実によれば、ユーザー企業が未納と主張する成果物は、納品されているか、又は未納となっていることについてベンダーには帰責事由はないと言わざるを得ない。また、各フェーズにおいて、納期に遅れて納品された成果物があることがうかがわれるが、証拠（略）及び弁論の全趣旨によれば、各フェーズにおける個別の成果物の納品の遅滞は、主にユーザー企業による情報提供等の遅れやベンダーの受注範囲外の（中略） 仕様確定の遅れ等に起因するものであって、ベンダーには帰責事由がないと認められる。（東京地方裁判所 平成27年3月24日判決より＜つづき＞）

となり、裁判所はSIer側の主張をほぼ全面的に認めて、損害賠償の支払いをユーザー企業に命じました。

ユーザー企業からすれば結局、業務に寄与するシステムを手にすることなくただ数億円のお金を支払えというわけですから、まさに踏んだり蹴ったりと言っても良いでしょう。

しかし、これこそが客とは神でもなんでもないことの証左です。

もしもお客さまが神様だったら、人の手によって判決することなく、ユーザー企業の言いなりになればいいだけです。ですがそうはなりません。

考えてもみてください。

ユーザー企業がＩＴ会社にシステム開発の依頼を持ち込んだとします。そこでエンジニアたちに「何を作ってほしいか」「どのようなイメージにして欲しいか」「〇〇の場合はどうするべきか」などのいわゆる仕様を伝えない…と言うのは

あるレストランにお客さまが入店してきました。
お客さまは老人で杖をついています。見た目、70代後半～80代に見えます。

お客さまはテーブルにつきました。
ホールは、お客さまのところに駆けつけ
「ご注文はいかがいたしましょうか？」
と尋ねますが、お客さまは答える様子がありません。

さらにホールは尋ねます。
「お任せでよろしければ、何かお持ちいたしますが、
　アレルギー等、お身体に影響のある食材等ございますでしょうか？」
と尋ねますが、やはりお客さまは答えません。

こんな態度をとっているということです。

みなさまがレストラン側の立場だったとしたら、そのようなお客さまにどう対応しますか？

挙句の果てにいろいろ気を使ってお出しした料理を、ちょっと味見しただけで「不味い！」「この店はこんな品を出すのか！！」「金は払わんぞ！」と言い出すお客さま相手に、どのような対応をされるのでしょう。

お客さまは、お客さまにとって必要なものを一緒に作り上げるためのビジネスパートナーです。それ以上でもそれ以下でもありません。ビジネスを成立させようと思って、ＩＴ会社の門戸をたたいた以上、それはＩＴ会社が最低限要求するルールを守らなければなりません。パートナーである以上、互いに利を得るため、それぞれにはそれぞれの役割分担があるのです。

テニスでいえばダブルスの前衛と後衛の役割のようなものだと考えてください。

そしてユーザーが、ユーザーの都合で自らの役割を果たそうとしない場合、それを当たり前だと思って、SIerはユーザーの問題をコントロールしないまま試合を続けて、勝つことが（成功することが）できるでしょうか？

　「外部インタフェース仕様整理遅延」
　「移行作業方針及び移行処理方式への未回答」
　「環境の構築の延伸」

これらはいずれもソフトウェアの中核を開発するというより、新規に開発するシステム導入に向けた準備に関連するような作業であり、作業の優先順を考えると、多少遅れても何とかなりそうに見えるものではあります。

マネジメントに長けた人物がフロントに立っていれば、クリティカルパスの間隙を縫って、無事に事を納められたかもしれません。

これくらいのことが遅れるのは、それほどの重大事にはなるまいと、ユーザー企業が考えたとしても不思議ではありませんし、事実このユーザー企業もそうだったのでしょう。

（実際にはそんなことはないのですが）移行方式なんて今やらなくても、ベSIerも開発に忙しいし自分達にも本来の仕事がある。少しくらいは待たせても全体への影響は限定的なはず。実際、そんなユーザー企業の担当者の言葉を私も何度か聞いたことがあります。なんなら、プライムのSIerからでさえ聞いたことがあるほどです。

確かに、ソフトウェア開発でユーザーが担当する作業の中には今すぐにやらないでもなんとかなるものも含まれています。１年スパンのプロジェクトの中でなら、２～３ヶ月くらいは「待っていてもいいかな？」なんて懸案はよくあります。

　「この部分の要件定義は今月中となってますが、
　　多少なら遅れてもなんとかなります」

SIerがそう言ってくれる作業もあるにはあるわけです。

しかし、そういう特別な作業はむしろ少数派でしょう。多くの場合、スケジュールは余裕なく組まれており、SIerにもユーザーの作業遅れを吸収する余裕などないのが普通です。

そう言う見積りになっていなければ、それはかなり余剰を残した『ぼったくり』である可能性が高くなります。

当初決めたスケジュール通りにユーザーが作業をしてくれたり、判断をしたり、あるいは情報提供をしてくれないことには、最終的な納期を守れないということの方が圧倒的に多いのは確かで、そう言うマネジメントをするのが一般です。

つまり、この例に挙げられた裁判というのは結局、

　ユーザーが自分の作業の納期を守ることの大切さ、
　守れなかったときの影響の大きさを十分に認識していない、
　そういう甘さが招いた失敗の典型的な例

ということができるのです。

とは言え、「SIer企業に一切の非がないか？」と言うとどうでしょう。クリティカルパスに影響を与える遅延をそのまま見過ごしていた行為は、決して良いとは言えません。

　「ベンダ―には、ユーザーのプロジェクトへに対する関与を管理し、
　　必要に応じて是正を求める義務がある」

とは、他の裁判の判決文でも頻繁に見られる言葉ですが、この裁判の場合、このプロジェクトマネジメント義務を本当にSIerが十分に果たしていたのか？ということには個人的に若干の疑問を覚えます。

国際標準でもあるプロジェクトマネジメントの知識体系「PMBOK（ピンボック）」では、こうしたユーザー関与への働きかけや管理を

　"ステークホルダーマネジメント"
　（多くの場合、ステークホルダーと言うと、お客さまや協働他社のこと）

と言います。

「1.ステークホルダー特定」で、このプロジェクトにどんな人が関わっているのかを明らかにし、「2.ステークホルダー・マネジメント計画」でどんな作業、どんなマイルストーンで、どの人にどう関わってもらうかを決定し、「3.ステークホルダー・エンゲージメント・マネジメント」で計画通りに関わってもらうように常に働きかけ、「4.ステークホルダー・エンゲージメント・コントロール」で、実際のステークホルダーの関わり具合を監視し、上手く関われるように微調整を行うのです。

そもそもシステム開発プロジェクトにおいて、ユーザーの作業というのは何かと遅れがちなものです。

ＩＴのプロでもなく、他に仕事を抱えるユーザー側の担当者が開発における重要性を認識できず、開発に関する作業を劣後させてしまうことは頻繁にあることです。

SIerは開発プロジェクト運営のプロとして、そうしたことも含んだ上で、スケジュールを検討し、且つ一旦決まったスケジュールについてはユーザにも守ってもらう、それができない場合には納期遅延も了承してもらうしかない、ということをユーザー側にも正しく理解してもらわなければなりません。

プロジェクトの開始時点で、スケジュール上どうしても遅れてしまっては困るデッドラインをユーザー企業に説明し、ユーザー…なかでも決定権や決裁権を持つ、"重要なステークホルダー"から合意を得ておく必要があるのです。

具体的に言えば、たとえば

　・マスタスケジュール上にユーザの作業をマイルストーンとして設定し、
　　それが終らないと進められない作業との依存関係の線を引くなどする

あるいは

　・ＷＢＳには必ず後続タスクを入れて、
　　やはり遅延による影響を受ける作業を明らかにする

と言ったことを繰り返し説明し、周知し、オープンなリスクとして共有することが重要になります。このようにしてクリティカルパス（臨界経路）を明らかにし、

　「それを遵守するためには、どうしてもユーザー様にも
　　守ってもらわなければならない期限がある」

ということを、ユーザー企業とのキックオフミーティングまでの段階で、しっかりと合意しておくべきだったと私は考えます。

「お客さま目線」と「お客さま第一主義」は全くの別物です。

「お客さま目線」とは、ニーズ発信者の本質的に求めているものが何かを明確にするための視点の切り替えです。「お客さま第一主義」とは、お客さまを最上位において、すべての指示、依頼に無条件に従う考え方です。

ですが、そもそもビジネスにおいて「上下関係」と言うものは本来ありません。もしも、お客さまがお客さま第一主義を要求し、それを受けなければ「他のSIerに切り替える」と言うのであれば、それは

　「技術的、価格的に、私たちでなければならない理由がない」

さらに直球で言い換えると私たち自身が競合他社と比べて"強みがない"わけですので、あえて固執する必要もないと思います。

社員や部下に奴隷のような対応を強制し、その人の人生を蔑ろにするくらいなら顧客１つ失うくらい屁でもないはずです（従業員たちが今後何年、何十年稼いできてくれる売上や利益を思えば）。

なぜなら、そんなことしか要求しない顧客なんて、他のSIerからも忌避され、いずれ体質を改めなければ顧客自身のＩＴ化が推進できなくなってしまうからです。

短期的に見れば顧客を失うことは確かに痛手です。それはわかります。

ですが中長期で見た場合、社員をズタボロにされて失うことのリスクと比較すればどうでしょう。人的リソースを失うだけでなく、最悪の場合は転職サイトなどで口コミに晒される可能性だってあるわけです。仮に会社に誹謗中傷させないように誓約させたとしても、そもそも労働者の保護義務を満たせていない以上、事を大きくすればより被害を受けるのは企業側です。そう考えれば、社員を不適切な扱いによって失うことと言うのは相当なリスクになるのです。

そういった"モンスターカスタマー"を生み出す土壌は、古き悪しき"お客さま第一主義"を未だに続けようとするSIerが後を絶たないせいでもあります。

システム開発と言う「プロジェクト活動を成功させる」という共通の目標を果たすためにも、

　ユーザーにはプロジェクトに"協力する"義務があり、
　SIerには"協力させる"義務がある。

と言うことを双方がもう一度考えることが、ビジネスに必要なコトだと思います。ただただ、お客さまに媚びへつらい、言いなりになるだけで、お仕事を頂戴するというのは丁稚奉公のすることで、ビジネスとは呼びません。