今回はこの二番目のツイートについて掘り下げていこうと思います。

最初の記事はこちら↓

「自社の本当の強み」だけ開発する

これからのシステム開発は、「自社の収益基盤、プロフィットセンターに直結するもののみを限定して開発する」ことが必要になってくると考えています。

実装を外注するか、内製するかという議論の上位の課題意識です。

2017年〜2020年のSaaSブームにより、月額低価格で高機能なSaaSが大量にマーケットに出回っています。

顧客管理、請求書作成、会計アプリ、メルマガ作成、コミュニケーションツール、教育動画、LP作成。

調べればほぼ全ての領域の業務が、やり方さえ覚えればSaaSを利用することで、開発することなく「利用」することができることに気づくと思います。

大量の業務の中で特に競争優位にならない業務をSaaS化して標準化し、1割の競争優位、自社の独自性を持つ業務のみを開発する。

例えばあなたがラーメン屋をしているなら「うちの給与明細のフォーマットは自作ですごい格好いいんだぞ！」とは言わないですよね。

本当にかっこいい給与明細が作れるのかも知れないけど、本当に集中すべきことは美味しいラーメンを作ることです。

ラーメン屋なら、例えば

・安く美味しい材料の仕入れ先の情報がわかる

・競合不在で参入すれば儲かりそうな商圏がわかる

・食券をキャッシュレスで、ユーザーはスマホでピ！で購入でき、オーダーの出し間違えがないように現場管理できる

こういったシステムなら利益に寄与しそうですよね。（あくまで例です）

逆に、「言われてみれば、ただ漫然と経営してきたけど、自社の強みがよくわからない。。。」会社に向けて、業務を整理して競争優位性になりうる要素を抽出して、そのポイントを効率化するまでをワンストップでできるSIerというのは需要が伸びてくるのではないかと考えています。

これが「顧客密着型SIビジネスの可能性」です。

ちなみに「御社にそのシステムは不要です。中小企業のための”失敗しない”IT戦略」にはほとんど言いたいことが書いてありますｗ

DX実現のためには業務フローをシステムに合わせる

DX。デジタルトランスフォーメーション。バズワード化していますが、元々の流れはBPR（ビジネス・プロセス・リエンジニアリング）の流れを組むものだと自分は認識しています。

業務本来の目的に向かって既存の組織や制度を抜本的に見直し、プロセスの視点で、職務、業務フロー、管理機構、情報システムをデザインしなおすこと。

このBPRのプロセスが抜け落ちたシステム開発プロジェクトは高い確率で失敗します。

「既存の業務フローを変えたくないから、既存の紙の業務フローをただパソコンの中に落とした」みたいなシステムでは投資対効果が出ないんです。

それ紙をシステムに転記するだけ無駄を増やしてますよね？みたいなものをよく見かけます。

特にひどい例がパッケージのカスタマイズ。パッケージに業務を合わせればパッケージをそのまま使えるのに、今自分がやってる業務フローに合わないからって高いカスタマイズフィーと保守料を取ってカスタマイズして独自の（特に会社の強みでもない）業務をキープする。当然投資対効果は最悪。

一体何をやっているのかわけがわかりません。

が、これはSaaS以前の文脈、ASPやオンプレ型のパッケージシステムから脈々と受け継がれてきたアンチパターンです。

「システムを業務に合わせるのではなく、業務をシステムに合わせる」

特にノンコア業務のDXプロジェクトでは、これを強く意識する必要があります。

※BPRについての基本的な用語解説はこちら

詳しく知りたい方は「経営のイロハをDX化する「開発しないシステム」導入のポイント」などの書籍を参考にしてみてください。

プログラム単体の部品はSaaSで廉価に調達が可能。多重下請け構造は苦しい立場に

「調べればほとんどのものがSaaSで調達できる」ということを前段で述べましたが、あおりを食らうのが特に商流の深い開発業者でしょう。

今まではいわゆる「ノンコア業務」も「システム開発」の対象となっていたため、開発に対する需要がありました。

しかし業務単体の支援は、SaaSで事足ります。

またOSSがまだ流行っていない頃は「StringUtil」クラスを自作したものです。

が、プログラム単体の部品はOSSで廉価に調達できる時代です。

SaaSもOSSも一切利用できない、全て内製する以外ないセキュリティがガチガチに厳しい金融系プロジェクトでもない限り活躍できる場は今後ますます狭まってくると思います。

そのまま淘汰されていくか、顧客の課題にさらに密に踏み込んで、「ユーザーの本当に求めるもの」をつくる道を選ぶか、今選択の岐路に立たされていると言っても過言ではありません。

まぁ個人的な感想を言うと、多重下請けって法的にもグレーだし不要なコミュニケーションで工数使い果たして全くいいものできないしさっさと顧客と直接話すような覚悟を決めたら？ｗと思います。（あまり言うと後編が書けなくなるのでこのあたりにしておきますｗ）

まとめ

これからのシステム開発では

・自社の強みを分析し、それを加速させるシステムのみを開発すべき

・ノンコア業務はSaaSに業務フローを合わせるべき

・DXが進むと多重下請け構造は苦しくなる

という話について解説しました。

後編はこちら