PHILOSOPHY(顧客と同じゴールを持つには)

顧客とゴールは同じか？

我々はまず、顧客とゴールは同じか？というポイントから出発する必要がある。 というのもSIは産業構造的に失敗しやすいという事実があるためだ。 何が失敗かというと、例えばSIのプロジェクトは以下のように階層的になることが多い。

• ①発注者(現場)＝こんなビジネスを実現したい
• ②調整者(システム部門)＝では、こういう機能があるシステムをこの値段で作りたい
• ③受注者(SIer)＝この要件で、この設計で、この画面で作ります
• ④実作業(下請け)＝言われた実作業

①と④は、同じゴールを見てはいない。ビジネス自体の成功を考えているのは①のみだ。 このように全員のゴールが異なる構造的不幸が発生することが多くある。

家を建てる場合は、あらかじめ設計図があって、発注者とも合意のもと建てることができる。 材料などもあらかじめ実物を確認してもらって、この場合、思ったより日のあたりが良くないとか、そういうケースもあるかもしれないが 建築業者は図面などで合意しているので、想定と違うものはできにくい。

システムの場合は、そもそもの実現したいビジネスが流動的な要素があり、 設計書の文言だけでなく、画面の見た目の裏側にも要望の相違があり、かつ検収は発注者が握っているため、受注者は完成するまで対価を得られない。 ①や②の途中でコミュニケーションが誤っていたとしても、発注者が圧倒的に強いという契約やビジネス上の関係がある。 このやり取りの中で、それぞれのゴールが違い、ボタンのかけ違いがある。 ③の受注者(SIer)は、こういったリスクに備えて費用を積み上げることになる。

もう少し本音レベルまで書くと

• ①ビジネスが欲しい(しかし、答えが見えないので都度変えていきたい)
• ②予算内で済ませ、機能を実現したい(ビジネスの実現はその次)
• ③粗利を出せる体制で、検収を受けたい
• ④スケジュールの死守、とにかく作り終えたい

と全員のゴールが異なるプロジェクトが誕生してしまう。 このようにゴールが異なる状況は、どのように打破すべきだろうか。

工数積算型の考え方は良い仕組みではない

工数積算のミスマッチ本来、天才プログラマが一人いれば作り上げてしまうものを、役割の分解などで一気通貫しない構造になっているのはSIerの構造問題である。 結果、打ち合わせに大人数で押し掛けるようなケースが生まれ、そこにそれ相応のコストが乗ることになる。 我々は人を足すからお金をもらえる、システムの規模があるからお金をもらえるという工数積算型の考えだと仕事は顧客から請けるものになる。 工数積算型ビジネス、大手SIerのピラミッド型ビジネス以外の新しい価値観も許容していくことが必要だ。

新しい価値観我々はSIにおいて、顧客との付き合い方を変えたほうが良いと考えている。 単に請ける仕事ではなく協働ビジネスにした方が関係はよくなる。 顧客とゴールを共有し、顧客に隷属せず、チームとして機能する体制を作ることが、ビジネス及びプロジェクトの成功要因となると実体験上考えている。 ゴールを共有しチームになるには、お金のもらい方や契約もそれにふさわしい形がある。 プロフィットシェア、従量課金、共同事業、顧問契約など新しいお金のもらい方、契約を考えることができる。

シグマコンサルティングでは、レベニューシェア、トランザクション型課金、CIO顧問型の主体的な開発 など、単に作って売り上げる以外のお金のもらい方、契約について様々な試みを行ってきた。 それぞれ、成功及び失敗がある。

BtoBビジネスのレベニューシェア

成功うまくいったケースだと、月相当額の売り上げを上げていたBtoBサービスがあった。 顧客名簿と営業体制を持つ企業とWEBサービスと立ち上げるのが得意な企業という組み合わせで相性も良かった。 お互いにないものを補完するケースの場合、成功の確率は高くなる。

失敗パートナーと契約期間を厳密にまとめず、サービス継続で売上もある状態で、パートナー側から契約を切る要望が出て終了。 不具合もなく、改修ポイントもなく、そろそろいいですかね。という言い分。 名簿を持っているところを組むという意味ではうまくいったが、契約の大切さを思い知る機会となった。 たとえ親友の企業とレベニューシェアだとしても、契約の内容(期間)は非常に重要だ。

特定業界の大手とアプリでレベニューシェア

成功コンテンツを持つ大手と、WEBサービス込のアプリ開発を行う弊社の組み合わせ。 そもそもアプリには類似性や競合があるものが多く、簡単に成功できないが、コンテンツ力と技術力で勝つ想定の利害関係が一致した。 大手とでも、利害関係が一致すれば、レベニューシェア関係を結べることを学んだ。

失敗アプリを出せば、既存コンテンツも有効活用できて一気にそのジャンルのTOPになることができるはず。。 という算段があったが、蓋を開けるとコンテンツには著作権が多くついていて、思ったように使えず、サービスは伸び悩み。 ３か月の企画期間と２か月の実装期間。レベニューシェア的には数万円しかあがらず。。。 AppStoreでの評価をSEOなり広告で買わなければ勝てないというモデルになってしまい、全く利益を生まなかった。

CIO顧問型の開発

成功CIOの立場で特定システム機能を立て直し、ついでシステム全体や運用の再構築等企業の立て直しを行うパターンでいくつか携わっている。 通常のベンダー的な立場として感じていたことは、意思決定層の理解を得ることが難しいケースが多い。 その点、意思決定層の合意を取り付けるためには、CIOという顧問的な立場、先生的な立場が有用と考えたため、その艇を多く取っている。 また、納品有無よりビジネスの成否を問われるので、責任は非常に重いが継続して仕事がしやすい。 先生である必要があるため、SalesForceやKintoneを使ってシンプルな仕様を低額で作るサブスクリプションモデルとは多少異なると考えている。 より企業の中枢、競争力の原動となる部分のシステムを担当することが多い。 社名にコンサルティングとついている所も、単にシステムを作るのではなく、こういったCIO役が多いことがある。

良くも悪くもCIOはビジネスの成否や社内政治に関わることになる。稼働しているサービスの成果を中心に見る。 一部機能を連続してリリース。細かい確認。システムリプレースは成功と主要な立場を抑えることによって、 サービス開発が思ったようにうまくいくケースは多かった。

失敗社内政治に関する反面として、最終的には支援していた企業が買収されて、新しいオーナーとは方針が異なり、 契約を継続することが難しくなったケースがあった。 他にも、どうしても納得のいかない(利益を落とすような)実装を経営者の意思につきあう形で、失敗するなどの失敗を経験している。 いくつか試しているが、簡単ではなく、企業固有の問題と闘うことも多い。

準委任契約に対する抵抗感の解決方法を探る

レベニューシェアや顧問型を進めようとすると、請負契約ではなく、準委任契約がベースとなる。 結局予算もあり、日本の場合は開始前、もしくは前年度に概ね決まってしまい変動させにくい点もあり、 予算内で、どこまで作れるのか？というのが議論になることが多い。 その結果、完成契約ではない、この準委任が理解できない、認められないお客さんも少なくない。

失敗を糧に組み方、進め方に関しては、成果をもとにした信頼関係で成り立つ形を実感している。

意思決定層と理解しあう

意思決定層と常に調整、ネゴシエーションできるように努力し続ける事も重要なポイントと思う。 意思決定層が現場のリーダーに権限を委譲できるよう、そのメリットを説く必要もある。 多重請負構造では、自らの立場で意思決定層とコミュニケーションできず、技術力が最大限生かせない。 直接契約する、顧客とのゴールを共有することが必要だ。

顧客とゴールを一致できない構造には加わらない

例えば、大手SIerを起点とした下請け構造で多層になると、そもそもコミュニケーション的に本当の発注者とゴールを共有する、顔を合わせることすら難しい。 我々は人を足すからお金をもらえる、システムの規模があるからお金をもらえるという形になり、顧客のゴール(ビジネスが欲しい) とは、どうしてもゴールの一致が難しくなる。 前述の通り、工数積算だと、複雑で手間のかかる選択肢ほど儲かる形になり、顧客とゴールを共有しづらくなる。 会社の売り上げを損ねることがあっても、この構造には加わらないようにしている。

工数積算型の考えを捨てたい。人をコンクリートのように扱わない。 人をつぎ込み解決するという価値観を見直さなくてはいけない。 人の数でコンピューティングを解決する手法を続けない。 やはり、この業界には圧倒的な個の力で成果を出すエンジニアがいる。

最後に、SIerでは実現できないのか？

「そもそも人が人のためにコードを書くことは間違っているのではないだろうか？」 創業から８期目まで一緒に戦った共同経営者ははそう言い、最後には「Youtuberに俺はなる！」そう言い残して去っていった…。 顧客とSI企業のゴールが異なるという仕組みをなくす戦いは現在も継続中だ。