SIerの生き残る2つの道：『システムインテグレーション崩壊』を読んで

比較的新刊なこちらを読みました。IBMの営業畑出身で現在独立してIT企業向けコンサル会社をされている著者、さすが書名がキャッチー。

中身はひとつひとつのトピックを取れば目新しさはないものの、「SIは崩壊する」と言い切ったのは日本の書籍としてはおそらく初だろうし、各トピックがうまくまとまっていて良かった。ただこれはITの本ではなくて、ビジネス書、いやむしろ経営書な内容なので注意。1プログラマや、非経営層向けというよりも、SIerの経営者、むしろSIerと呼べないソフト開発会社の経営者向けと理解した。

SIの本質とは何か

僕は7年間SIの現場にいたが、本だったりWeb記事だったり、周りから聞いた話だったりで「SIとは何か」に対して明確な答え、定義を持っていたのは本書が初めてだと思う。

まず、本書ではSIの「本質的な」定義を以下のようにしている。シンプルかつ、的を射た非常に良い定義だと思う。

本来、SIは、テクノロジーやノウハウを組み合わせ、ユーザー企業の求める最適なシステムを構築する請負型ビジネスを意味します。*1

一方で「SIが崩壊する」という文脈で使う場合の「既存の」SIの定義は以下の通り。

ここでいうシステムインテグレーション（SI）とは、「工数積算を前提としたビジネス全般」のことです。

我が国のSIは、工数で見積もりする一方で、納期と完成の責任を負わされるビジネス形態です。

つまり、「提示した見積工数と納期に対して発注者にコミットするようなSI形態は崩壊する」と言っているのだ。これはSIerにいる人々の実感にも近いだろうし、事実その可能性は高い。

アジャイル型請負開発

そしてその崩壊の元凶の1つとされているのがウォーターフォール型開発だ。その理由はそこかしこで議論されていることとそれほど大差ないため割愛するが、それに対するカウンターとして著者は「アジャイル型請負開発」を提唱している。これはアジャイル開発をある程度現実味を持って請負開発に適用しているのでなかなか面白い。要点をまとめると、以下の3点になる。

業務を遂行するうえでなくてはならない要件に絞り、それ以外を外した工数・期間を算出し、請負契約を締結
各要件に対して優先度に従い開発を進める
開発途中に優先度が変わった場合は合意した工数・期間内で未対応の案件と入れ替え可能

さて、これはこれまでの一般的な請負開発とどこが違うのか。

まず「全部作らない」というところだろう。最初に業務遂行に必須な部分に絞っているのでこれまで「使うか分からないけど今入れないと作ってもらえないから入れとこう」といって入っていた要件が省かれる。これは短期的には開発のボリュームを減らすことになるので受託者としてはマイナスだが、要求の純度（必須度合い）は上がるため最終的には双方にとってプラスになるだろう。ただそのためには現場を押さえる力が必要だ。

次に要件定義フェーズ後も要件の入れ替えが可能なところ。これも双方にとってプラスではあるが気をつけなければいけない点がある。新しく優先度の高い要件が発生した場合にはノーコストで入れ替えが可能なわけではないのだ。新しい要件はまだ要件定義が行われていないので追加で要件定義コストが発生するし、既に開発済の機能に対して新しい要件が適合するように影響分析を行う必要がある。得てして要件定義や影響分析が可能な要員と開発要員は異なるので、最初から要件の入れ替えを見越して要件定義・影響分析が可能な要員も残しておかなければならない（そして入れ替えが発生しなければその要員が浮いてしまうリスクを取らなければならない）。

しかしそれよりも大きな問題は、最初の時点で請負契約を締結するためその際の工数・期間の見積もりに誤りは許されない（誤っていた場合はその分受注者＝SIerが瑕疵担保として補償しなければならない）ことだ。これは「（特に初期段階の）見積もりは間違っているもの」というアジャイルの原則を逸脱しているため厳密な意味でのアジャイル開発ではない。純粋なアジャイル開発は請負契約では行えない。だから「アジャイル型請負開発」という別名になっているとも言える。

するとどうなるかというと、誤りのない見積もりが必要になる。そのためには要求仕様に対して精査し、きっちりと要件定義を完了させる必要がある。とすると、本書がいうように「おおよその工数と期間の見通しを立てて金額を決め、請負契約を締結」するというのは現実的ではなく、引き続き長期間の要件定義フェーズが必要となってしまう。もちろん上記は「業務を遂行するうえでなくてはならない」プロセス・機能だけに対して行えばいいわけで、それ以外（必要かどうかわからない、あったほうがいいかもしれない）ものについてはその時点で必要ない。その分だけ早く要件定義を切り上げられた分のスピードアップにはなるが、抜本的解決にはならないと感じる。

そういう意味で、本当は純粋なアジャイル開発を行いたいのだけれどもこれまでの慣習に囚われたこの業界での妥協策として「アジャイル型請負開発」を提唱している、と考えたほうがいいかと思う。契約形態と開発手法でマトリクスを作ると、以下のようになるはず。

f:id:hnishim:20140813195826p:plain

生き残る道は2つ？

しかし本書ではアジャイル型請負開発だけを唯一の将来的SIer像として描いているわけではない。もうひとつはクラウドを活用したサービスビジネスだ。*2

これはクラウドを使う、使わないという単純な話ではなく、（そのベースがパッケージ製品かを問わず）1つの顧客に対してしか使えないシステムを開発することと、不特定多数の企業を潜在顧客として先行投資でサービスを開発することという決定的な差が存在する。後者はむしろ製品販売・開発を行う企業に近しい。

そのため筆者は「売り方」がまったく異なると主張する。これまでのように「個人力で売る」やり方から、「仕組みで売る」やり方に転換が必要で、そのためにはマーケティングの方法を変えなければならないという。これはその通りだろう。このあたり、やはり営業出身の著者だと思う。

一方で変えなければならないのは売り方だけではない。作り方も変えていかなければならない。顧客に聞けば要件が出てくるわけではないし、そもそも要件定義・設計・開発といったフェーズ分けもナンセンスになってくる。1度のリリースで完了というわけにもいかなくなり、Ver1.0リリース後の不断の改善が必要になってくるので「ゴール」があいまいになる。この点は1箇所だけ触れていたと記憶しているが（どこだったか思い出せない）、十分と言えるほど言及されていなかったところが惜しまれる。

つまり、SIerがサービスプロバイダに転身するには売り方と作り方、両方のパラダイムシフトが必要になる。これはかなりの障壁であるものの、出来ない話ではないはずだ。個人的にはこの道を是非模索していきたい。