“お客様のため” の “お客様” とは誰のことか、そして "ため" とは具体的に何をさすのか、自分の言葉で説明してみる

法人向け業務アプリケーション開発を行っているシステム開発会社(以降、SIerと記します)の多くは、社是として "お客様のため” を標榜しています。これ自体は正しい方針でしょう。しかし、ここでいう “お客様” とは誰のことか、そして “(お客様の)ため” とは具体的にどういうことか、についてもう一歩踏み込んでみませんか? という話をします。

前提:SoR と SoE は目的が違う

過去のブログで何度も触れていますが、現代の (IT) システムは、SoR と SoE に大別されます。SoR は社内の事務作業を効率化し、最終的に正しい数字(売上と利益)を確定することにつなげる一連のシステムです。SoE はその会社の先にある不特定多数のお客様向けサービスです。以降は SoR に絞って話をします。

SoR の目的はコストの削減です。業務プロセスの無理、無駄をなくし、ヒトの負担を減らすことは企業にとって(間接業務の)人件費削減につながります。よって費用対効果とは、システムの導入でどのくらい経費を削減できるか、のことです。

何をいまさら感がありますが、現実に起こっていることは、このシステムの開発費と運用費が膨らんでしまって、もともとの経費削減効果がなくなってしまうどころか、さらに経費がかかってしまうという本末転倒な状況になっていることです。発注側の経営陣はこの状況に不満をもっており、その削減を現場に指示します。ところが現場はその指示を開発や運用工程の見直しではなく、携わるエンジニアの人件費削減にすり替えたため、業界全体を巻き込んだ壮大な負のスパイラルが生み出されました。誰もがこの問題をなんとかしたいと願いつつも、どこから手をつけていくべきかという指針もなく、それゆえ改善の見通しも立っていません。

現場からみた “お客様” は、システムの利用者のことである

私がよく目にする "SIer 悪玉論” は、お客様の要求をすべて実現するという建前のもと、開発工数を増やすことで、ちゃっかり売上を伸ばすという話です。しかし私が現場をヒアリングしている限りでは、(結果的にはそうなったとしても)意図的に工数を増やそうとしていることはないのです。むしろ工数が増えないようにお客様に提案するのですが、お客様がそれを受け入れず、工数が増える方向に倒されるといった状況を何度も見てきました。しかもそこまでして頑張ってつくった画面や機能は、納品後は使われなかったというオチがつくことさえあります。

ここでわかることは、現場の開発者からみた “お客様” は、システムの利用者です。そしてこの場合の利用者は、自らの要求実現のためにいくら開発費が上乗せされるか(または現場に過剰な負荷を要求しているか)を意識していません。自らの財布が痛まなければ何でも言えます。その究極が(開発サイドにとってもっとも悪名の高い)”現行どおり” という要求です。これは既存の業務プロセスや、旧システムのUIをいっさい変更せず、単純にデジタル化もしくは保守切れ直前のシステム更改を果たすだけのもので、SoRの真の目的である “コストの削減” にまったくつながりません。

ほとんどの SIer は、ここに切り込むことができていません。現場レベルではまず話ができません。下手をするとお客様からの印象が悪化し、開発の仕事そのものを失うリスクがあるためです。このレベルの話を現場で解決させようとすること自体が、そもそも間違いで、SIer のトップが関わるべきです。お客様のトップと膝を詰めて交渉し、SoR の真の目的を達成するための協力関係を敷くことができれば変わると思います。

超高速開発への誤解と、それを乗り越えたお客様の思想

実はこの解決策の一つとして有力視されたのが超高速開発手法です。私もその一人で、実際に Wagby というツールを作る側として活動しています。おかげさまで10年以上このテーマに関わっていますが、未だ革新的な変化を起こすに至っていません。

その原因の一つは、コスト削減を優先したいお客様(トップ層)と、業務プロセスを変えずに、いびつなプロセスのままシステム化するがために、カスタマイズにこだわりたいお客様(利用者層)のコミュニケーションがとれていないことです。そしてSIerはこの関係を調整する役割を担うことはありません。ところで超高速開発とは「開発費、運用費のコストを削減する」ことを目的とし、そのために「個別の要求仕様を、ツールが提案する標準化手法に合わせる」ことを前提とする技術体系です。ここに誤解があり、どんな複雑な画面や機能もノンプログラミングで何でも実現できる魔法のツールと思い込んでいると、うまくいかないのです。

他社製のツールも含め、さまざまなセミナーに参加して、いわゆる成功事例を拝聴してきましたが、共通しているのは、お客様自身の(ツール利用の)方針が明確なところは満足度が高いということです。ツールの特徴を活かして…というのは抽象的すぎる言い方でしょう。ずばり、どのツールもノンプログラミングで提供する標準機能と、何らかのコードを付加して実現するカスタマイズ機能があります。標準機能だけで必要な業務を実現できれば満足度が高いのは当然ですが、そう簡単にはいきません。どこまでをカスタマイズ要件として取り込むか、という軸をもっているかどうか、がポイントになります。

私見では、業務処理は取り込むことが必須ですが、UI は妥協すべきラインが存在します。ツールをつくる側としては、業務処理の実現のために妥協はないが、UI は「ここまでは可能」と「これはできない」ということを説明し、了承いただくことが必要と考えています。業務項目やボタン類を画面に配置するルールも明確であり、だからこそ超高速開発を実現できる反面、現行システムとまったく同じ画面レイアウトとすることはできません。

そして満足度の高いお客様は、現行システムの画面や業務プロセスにこだわらず、ツールが生成した画面に慣れるとともに、新しい業務プロセスに自らを合わせるよう変化させています。これを乗り越えることができれば、あとは超高速開発が本来提供している価値である「少人数で、大規模システムを、短期間に、アジャイルで」開発できるというメリットを享受できます。

SIer は新しい価値の提案力を収益の源泉にできる

この数年、SI を「工数ビジネス」から「価値提供ビジネス」に転換しようという掛け声は多く聞かれるようになりましたが、実践されているのはまだまだ少数派です。これを変えようとしているのが私たちのビジネスの本質であり、そこが変わっていないということは、まだ私たちがやるべきことが残っているということでもあります。

何度でも主張しますが、SI を工数ビジネスと捉えている間は、この業界は 3K の呪縛から逃れることができません。SI はそもそも価値提供ビジネスであり、SoR の視点からいうお客様にとっての価値とは「コスト削減」のことです。そのために超高速開発は有効な手法ですが、その種明かしは「(ツールが提案する)標準化手法に合わせる」ことです。

ツールの標準化手法と相容れない、自社の独自仕様を是とし、その実現のためにカスタマイズを厭わないのであれば、元々の目的であるコスト削減は遠のくばかりですが、それをもって超高速開発は合わない、というのであれば、それはもう最初からずれているとしか言いようがありません。

SIer は本気でお客様に対して「コスト削減」をアピールすることができるのか、そのために現行システムの UI や、現行の業務プロセスを見直すという大きな提案を行うことができるのか、そこが問われています。超高速開発の普及とは単にツールが売れたということではなく、SoR 市場全体を変えることにつながっています。それだけに時間がかかっているのですが、あえて火中の栗を拾うプレイヤーがいないと、最後は日本全体の競争力が低下するという、経済産業省がいう “DXレポート” の最悪のシナリオが現実味を帯びてきます。地味で面倒な分野ですが、必ず役に立つという信念をもってビジネスに取組んでいこうではありませんか。そして私たち Wagby 陣営は、Wagby というツールを入り口に、そのような気持ちを共有できる SIer と出会うことが喜びでもあります。

今月末のイベント Wagby Developer Day 2018 で、多くの方とお話しできることを楽しみしています。

Wagby Developer Day 2019