2017/04/27 | ビジネス | 766 view | 

小さなシステム会社は、無理せず、甘えずが直受注のカギ


こんにちは、株式会社ampの松崎です。
ゴールデンウィークがすぐそこまで来てますね。
私はいい仕事をするためには、充実したオフの時間が大事だと考えていますので、どうしても避けられない事案がないかぎり、極力長期休暇は楽しみたいと思っています。
うちのような小さな会社だと、無理をしてお客様のご要望にお応えしたいという志向になりがちですが、長期的な視点で考えた場合、その時に無理をしたことが、後々後遺症になって、事業継続できなくなるということもあり得るので、この姿勢は守りたいと思います。

2次受け、3次受けに届くお急ぎ便のクレーム

さて、今日は「小さなシステム開発会社が提案から運用まで対応するための取り組み」について、触れたいと思います。
私は常々、IT技術がモチベーションを持って仕事に取り組むためには、「自分の開発したもの、対応したものの成果をどれだけ近くで実感出来るか」が重要だと考えていました。独立して自分で会社を始めた大きな理由は、「成果を実感出来る環境を作り、IT技術者がモチベーションを維持できる環境」を作りたかったからです。

その環境を作るためには「システム発注者からの直接受注と包括的な対応」が必要だと考えています。理由は様々ですが、わかりやすいものとしては、2次受け、3次受けの場合、システム導入後の喜びの声は届かないことはあっても、クレームは確実に届くからです。問題解決の方針などは顧客と1次受けの会社の間で決まることが多く、1次受けの会社は顧客満足度を落とさないために、顧客が困っている場合は、2次受け以降の会社の状況はあまり考えず「すぐやって」と2次受け以降の会社に依頼の連絡が入ることは少なくありません。

このようなケースでは、実際に対応するIT技術者の言い分などは関係なく、四の五の言わず「即対応」が求められます。モチベーションが上がるわけありませんよね。

1次受けであれば、自社が直接顧客と交渉する事ができ、完全な瑕疵以外であれば、即対応でなくても顧客満足度を下げない方法も提案することが可能です。顧客も無理を重ねて、発注先が疲弊することを望んでいるわけでないのです。
しかしながら、システム発注者の中には 2次受け、3次受けをたくさん抱える大手SIerに発注することが安心だと考え、システム開発能力が足りていても「あの会社は小さな会社だし、今回の大事な仕事をお願いするにはいろいろ不安となので今回は 大手SIerで安心感のある◯◯社にしよう」という判断をする場合が少なくありません。

なぜ小さなシステム会社には大事な仕事を任せられないのか?

なぜ小さなシステム会社には大事な仕事を任せられないのでしょう。
そのようなシステム発注者も、Excelのマクロの改修やデータ入力などは直接任せても問題ないと考える場合があります。そのようなシステム発注者は決してExcelのマクロの改修やデータ入力を軽んじているわけではありません。 Excelのマクロの改修やデータ入力は何か問題があっても、自分たちで対応するなど、リスク回避策をもってるのです。

以前はITシステムを導入する場合、インフラ整備のための調達力が必要であったり、システムで使用するミドルウェアの保守が可能な代理店契約が必要であったり、小さな企業の体力では障壁になるような事項も多かったのですが、クラウドやオープンソース利用が許可されている事案でも、「小さなシステム会社」が対応することをリスクと考える空気が未だにあると思います。

私は以下の点をリスクと捉えているのではないかと想像しています。

・組織的に開発する体制がなく、十分な対応が出来ないのではないか。
・予期せぬ問題が発生した場合に、リカバリー対応が出来ないのではないか。

私の想像通りに、これらをリスクと捉えているのであれば、小さなシステム会社はこのリスクを払拭しなければなりません。

組織的に開発出来る体制づくり

小さなシステム会社であっても、継続的に責任も持って対応するためには、組織的に開発出来る体制は必要です。
システム発注者は小さなシステム会社が提案書に記載する「開発体制」に不安や疑念を持っている場合が少なくありません。
これは、これまで一部の小さな会社がやってきた受注姿勢にも責任があると考えます。
私が知っているケースを紹介します。
開発体制を作る際に、まだ必要な要員が確保出来ていないのに「実際に開発メンバーが揃ったら、メンバー変更を申し出ればいいさ」と、社内の全く関係のないスタッフを実名で記載して、偽った「安心感」を演出して受注、その後、約束した体制が築けなかったことがシステムトラブルにつながり、開発体制が当初と違うことを指摘されて、事後対応として「社内の全く関係のないスタッフ」を動員し、偽りの体制を正当化しました。スキルマッチしないため、当然トラブルは収束せず、そのシステムは使えないシステムとして納品され、システム発注者は「最初から体制できてなかったんじゃないの?」と疑念を持ち、その後、そのシステム会社との取引をやめてしまいました。

こんな「身の丈に合わない演出」をせず、要員を後に確保するのであれば、確保できる根拠を示した上で、開発体制が整っていないことを伝えたほうが、受注できるかどうかはともかく、システム発注者の信用を失うことはありません。
また、オフシュアを活用するという方法もあります。オフシュアの開発会社には自社の設計と規約に沿った開発を依頼し、自社内で保守出来るプログラムコードをオフシュアから受け入れる、という方法であれば、システム発注者に迷惑をかけることもありません。

システム発注者に自信を持って提案できる嘘偽りの無い「身の丈の体制」を作ればいいのです。
また、自社内で属人化しない開発スキームも必要になります。この点について具体的な話は改めて記事化したいと思います。

予期せぬ問題が発生した場合のリカバリー対応

予期せぬ問題が発生し、予定通りにシステムを納品出来ないといったケースについて触れてみたいと思います。
このようなケースは対応するシステム会社の大小にかかわらず発生します。
では、システム発注者は何をリスクと考えているのでしょうか。
これはズバリ、会社の体力的な部分です。小さな会社は数千万円の損害賠償やそれに相当する瑕疵対応が出来ず、会社がなくなってしまうリスクがあります。残念ながらそれが現実です。
そうなってしまうと、システム発注者は、支払った開発費が全て無駄な投資になります。当然のことながらそれは避けたいため、リスクをどうしても考えてしまいます。

では、このリスクは小さなシステム会社には不可避なのでしょうか。
これを解決する方法はあります。「保険」です。
損害賠償保険には「IT企業向けの損害賠償」に最適化した商品があり、小さなシステム会社のキャッシュフローを圧迫せずに数千万円の損害賠償に対応可能です。
商談の際、「保険」に入っていることをシステム発注者に伝え、万一の場合に金銭的な対応が出来ることを示し、責任をもって対応する姿勢を伝えることにより、ウィークポイントをカバーすることが出来ます。
「保険」に頼る必要のない大手SIerも財務的には対応可能でも、予期せぬ問題発生時に即座にリカバリー体制を組めることは少ないため、小さなシステム会社も「保険」により、会社を維持できれば、損害賠償金を支払った上で、リカバリーに必要なサポートをするなど、責任のある対応が可能なのです。

甘えや根拠のない「やります」をなくすこと

前述したとおり、システム発注者は、小さなシステム会社に対して根拠のあるリスクを感じています。
その根拠あるリスクを払拭するには、「根拠のある対応可能な理由」を示す必要があります。
その「根拠のある対応可能な理由」をどう捉えるかはシステム発注者の受け取り方によるので、リスクを完全に払拭できるとは断言できませんが、小さなシステム会社は間接費や体制維持コストが大手SIerよりもかからないため、開発費用を大手SIerよりも抑えることが可能であり、「小さい会社ですから勘弁してください」といった甘えや、根拠のない「やります」をなくすことにより、直接受注の可能性は上がると考えています。

小さなシステム会社は、無理せず、甘えずが直受注のカギなのです。


コメントを入力する

プレミアム会員募集 プレミアム会員募集

コミュニティ企画

  • 新着記事
  • ランキング

BTL TOKYO

TAG

TWITTER

FACEBOOK

RECRUIT

求人
  • 2017年09月号
  • 2017年08月号
  • 2017年07月号

毎月15日発行 クリエイティブ経済誌「BTL TOKYO」は
企画・マーケティング・クリエイティブ職に就く
ビジネスパーソン向け無料の月刊誌です

無料定期購読