ネットコマース株式会社　代表取締役　斎藤昌義さんの著書
「システムインテグレーション崩壊」と

株式会社ソニックガーデン　代表取締役　倉貫義人さんの著書
「納品」をなくせばうまくいく


の2冊を読みました！

最近流行っている、SIerモデルの危機が分かりやすく書いてある
話題の書籍 2冊です。

とても興味深い内容だったので、SIモデルも含めて
整理しておきたいと思います。

システムインテグレーション崩壊

IPAのIT人材白書2014によると、
「受託開発からITサービス利用へ継続的にシフトしている」



また、ユーザー企業においては、クラウドサービスなどの「サービス利用」が
着実に拡大している一方で、IT企業における受託開発(開発・運用・SI)の割合が
依然として高く、IT企業における今後の新規/拡大予定(ユーザー企業は利用予定)の
事業内容(枠A、枠B)でも、IT企業とユーザー企業でギャップがある



IPA　IT人材白書2014
https://www.ipa.go.jp/jinzai/j……about.html

SIビジネスの課題

・工数積算で単価が決定するにも関わらず、成果保証（瑕疵担保責任）をおわされる



・構造的不幸
　　ゴールの不一致と相互不信

・テクノロジーの進化
　　求められるスキルの変化

・ユーザーニーズの変化
　　工数積算ビジネスの減少

既存の収益モデルを脅かす　新しい技術や市場

・IaaS、PaaSの普及
　　システム開発、構築、運用の生産性を大幅に高める

・SaaSの普及
　　業務システムのサービス化、パッケージ販売や導入に伴う作業軽減

・オープン化
　　Webやモバイルアプリケーションの開発は
　　オープンソースのフレームを活用が普及

・オフショアの普及
　　従来型の開発であってもオフショアが普及

コモディティ化

・どれも買っても同じ、しかし、なくてはならない存在

・差別化
　お客様の必要を超える完成度となり、違いを訴えても優位性を見いだせない
　技術とは別次元の異なる領域に、差別化が必要
　

SI事業者に内在する３つの壁

・収益区分/事業区分
　１．販売
　２．開発
　３．定期収入（運用・派遣・保守）

　新しいビジネスの創出を阻害する　

・経営資源
　新しいビジネスは、当面の収益が確実に見込めない
　また、根拠のある合理的な事業計画が描けない

・業績評価制度
　人月ｘ単価の積算を拡大し、フローを大きくすることが求められるが
　サービスビジネスは、「顧客との関係を長期継続的に維持」が求められる

所有から使用へ

・情報システムを所有しないことによる、TCOの削減

・システム基盤の維持・運用管理に関わる業務負担からの解放

・運用管理・保守作業から、企画や設計などへ人材のシフト

サービスの直販

・ユーザーに直接提供できる仕組みを考える

・少ない利幅でも、効率よく利益を確保出来るようにする

・顧客のニーズに迅速に対応して、サービスを継続的に改善する

新しい３つの収益モデル

・サブスクリプションモデル
　月額定額でサービスを提供する

・レベニューシェア
　成功報酬型の収益モデル
　システムを利用して得られる収益の中から、一定割合を報酬として受け取る

・成功報酬
　初期費用を負担せず、トランザクション（利用量）に応じて月額料金で精算
　

クラウドビジネス

・クラウドプロバイダー
　自分たちが所有するシステム資源や、独自サービスを提供するビジネスモデル

・クラウドアダプター
　プロバイダーの提供するサービスの課題を補完し、共生するビジネスモデル

・クラウドインテグレーター
　プロバイダーやアダプターのサービスを、お客様個別のニーズに対応して
　組み合わせ、お客様専用のサービスを提供するビジネスモデル　

ウォーターフォール型からの脱却

・スケーラビリティ
　システムを所有しないクラウドは、資源を必要に応じて拡大縮小できる

・アジリティ
　変更や変化に柔軟・迅速に対応できる

・スピード
　意思決定したことを直ちに実行に移せる

これらの価値を引き出すには、ウォーターフォール型の開発では難しい

アジャイル型 請負開発

・全部作らない
　業務上必要性が高い機能やプロセスを選別し、優先順位を決めて
　そこにリソースを傾注することで、必要なシステムのみ作り上げる

　結果として、短納期・高品質の開発が実現する

・ユーザーが本当に使うシステムだけを作ることで、ムダな開発投資をさせない

・ユーザーからの変更要求にも柔軟に対応し
　ユーザーが、納得して使えるシステムを実現する

・ユーザーが納得できる予算の中で、最善の機能を実現し、
　約束した期間の中で、最高の品質を実現する

・アジャイルは開発手法ではなく「働き方」
　職場を作らなければ、手法だけ取り入れてもアジャイル開発はできない

リノベーション営業からイノベーション営業へ

・営業 1.0
　プロダクト営業

・営業 2.0
　ソリューション営業　組み合わせ＝ソリューション　

・営業 3.0
　イノベーション営業　ソリューションをデザイン

「納品」をなくせばうまくいく

納品のない受託開発

・受託開発であっても「納品はしない」

・本当に必要な機能を、本当に必要な順番に、少しずつ開発をしていく

・一括請負開発
　ソフトウェアの「完成リスク」を開発会社が引き受けてくれる
　納品・検収が、一括請負開発のゴールとなる

スタートアップに適したシステム開発

・新規事業と要件定義の相性は最悪
　新規事業は、事業として成立しておらず手探りで正解を探す段階

・スピードとフィードバックを重視する
　市場に投入してみなければ、事業の妥当性が検証できない

　フィードバックの速度に対して、どれだけスピード感をもって
　対応していけるかが事業成功の鍵

・スモールスタート
　スタートアップは、なるべく少ないコストで始め、ユーザー数が増えるにつれ
　徐々に事業規模を拡大していく

「納品のない受託開発」で解決できること

・要件定義をしなくてもよい
　最初に1ヶ月から、最長でも3ヶ月程度の最小限の機能を決めて開発を進める
　なるべく早い段階で、ユーザーへ提供し運用に入る

作らない提案

・顧客の思いつきで考えたような機能は、すぐに作らない

・開発量で売上げが上がるわけではないので、なるべくムダなものは作らない

「何を作るか」よりも「なぜ作るのか」

・なぜソフトウェアが必要なのか、その事業で実現したいこと
　そのために妨げになっている課題は何かを把握する

・顧客のパートナーとして、ビジネスの成長に必要なソフトウェアを
　継続的に改善して提供する

・要件を定義するのではなく、事業の目的を共有する

「完成」から「持続」へ変化

・ソフトウェアを「所有する」という考え方から
　「利用する」という考え方に変える

・「完成する」ことから「持続する」ことへの考え方の転換

・「バグはゼロに」ではなく、すぐに直せること

・落ちないサーバーより、すぐに復旧できるサーバーへ

・「あらかじめ仕込む」よりも「必要になるまで作らない」
　

アジャイル開発によるマネジメント

・「アジャイル開発」の進め方に合わせた、受託開発のビジネスモデル

アジャイルソフトウェア開発宣言

・プロセスやツールよりも　顧客との対話を

・包括的なドキュメントよりも　動くソフトウェアを

・契約交渉よりも　顧客との協調を

・計画に従うことよりも　変化への対応を

価値とする、すなわち左記のことがらに価値があることを認めながらも
私たちは右記のことがらにより価値をおく。

※アジャイルソフトウェア開発宣言より一部抜粋

アジャイル開発の目的

・顧客との協調によって、開発するソフトウェアを通じて
　ビジネスの価値を、生み出すこと

まとめ

どちらの書籍も、分かりやすい事例があり
SIの現状と未来を、説明してくれています。

SIerとして、今が変革の時だと思います。
労働集約的なプログラミング作業による、人月精算には限界が来ていると思います。

工数x単価は、SIerの生産性の指標であって顧客に提示しても
あまり意味がなくなってきています。

工数が増えたら精算する、実費償還契約でもなく
単価が高い安いの話しにしかならないのでは、ないでしょうか？

創るモノに対して、しっかりと価値を付けて販売するモデルにしないと
お互いにメリットが出なくなってきています。

例えば、ラーメン屋さんに行って大将が、どのぐらい仕込みに時間をかけているか？
原材料がいくらか？なんて考えて買わないのと同じです。

クラウドを活用したシステムを、創造していくのに
いよいよ、コモディティ化されてきたため、作る作業そのものの価値は付けにくく
提供する成果物やサービスに対しての価値が、重要なんだと思います。

この作業をしたらいくら、人月いくらのモデルを脱しないと
大きな飛躍は出来ないし、グローバルの競争下では、存続も危ないと思います。

そんな、SIerのみなさんも、そうでない皆さんにも
2冊の本は、オススメです。みなさんも、是非読んでみて下さい♪

システムインテグレーション崩壊


「納品」をなくせばうまくいく

関連記事: