ITごはん

ITを活用したい人、ITで何か作りたい人、そんなITでごはんを食べる人のためのブログ

【書評】「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

はじめに

我が国が技術立国であることには、言を俟たないですが、 ことITについてはどうでしょうか。

製造業では新興国に押されているとはいえ、 部品・素材やインフラ系など変わらず重要な地位を占めていると言えるでしょう。

しかし、ITについては、国際比較の中では、 産業規模こそ大きいものの、 米国や中国のように、世界的影響力をもつビッグプレイヤーが出てきていないと言えます。

また、米国を見てみると、 Googleのエンジニアは1,400万円の年収を得られ、 ITエンジニアは高年収ランキングの10位以内に入っています。

一方、我が国のITエンジニアは決して恵まれた環境ではなく、 新卒の学生から、憧れる職業ではなくなっていると聞きます。

このような我が国の特殊な状況は 多重請負や、人月問題、etcが根底にあると言われています。

本書の倉貫氏は、こういっった日本のIT業界全体の課題に 果敢に挑んでいる内容が本書に収められています。

「納品がおこしてきた問題」

本書ではIT業界で一般に行われる一括請負契約をベースとした、 納品がある契約を納品のある開発とし、 「納品がおこしてきた問題」として、以下を挙げています。

1 ソフトウェアの「完成リスク」を開発会社が引き受けてくれる
2 リスク引受(バッファ)による高価格化
3 創意工夫を阻む保守的な開発
4 開発会社の価値は保険
5 駄目なエンジニアほど儲かる
6 最大負荷をベースとしたハードウェア購入による高費用化
7 開発と運用が別なことによる、保守性を無視した設計・開発

これらは、業界に知見のある人であれば、 頷くことが出来ると思います。

そして、これらの解決の手段として、 倉貫氏とその会社のソニックガーデン社において、 提案・実行されているのが「納品のない開発」ということになります。

「納品のない開発」では、以下の様な特徴を持ちます。

1 月額定額(納品がない)で「できる範囲」で精一杯の「開発と運用」を行う
2 時間単位の作業の提供ではなく、顧客の成果と満足度をベースにした契約
3 同じ担当者が提案や開発・運用まで責任をもつ顧問ビジネス化
4 毎週のミーティングと非常駐

イメージとしては、自社に開発・運用を面倒みる システム担当者がいるようなものでしょうか。 また、開発手法としては、一般にアジャイル開発として 認識されているものに近いと思いますが、 あくまで中長期的なパートナーシップをベースとしているところに、 大きな特徴があるでしょう。

例えば、「3 同じ担当者が提案や開発・運用まで責任をもつ顧問ビジネス化」 一つをとっても、経験的に共感できるところがあります。

いわゆるシステムは開発の期間より、 実際に使用する運用の期間の方が圧倒的に長いです。 これは、開発期間の20倍を超えることも珍しくありません。

しかし、多くの場合、開発時の効率ばかりを考え、 運用期間におけるメンテナンスを考慮した設計・コーディングが 行われることが少ないです。

これは、開発会社が、運用を行う想定がない場合などは、 顕著にこの問題が起こる可能性があります。 (この場合の開発会社は、運用を考慮するインセンティブがありません)

中長期な視点のあるプログラムというのと、 開発の急場しのぎのプログラムというのは、 外側から見ると同じように見えますが、全く異なります。 それは、いざメンテナンスする際などに、 バグが多い、変更の自由が効かない、または修正コストが大きい といった形で返って来ます。

顧客にとっての「納品のない開発」

また、「納品のない開発」の顧客にとってのメリットは、 以下のように記載されています。

1 要件を1度に決めなくて良い、いくらでも仕様変更ができる
2 気軽に相談ができる
3 開発費用の低コスト化(請負にくらべ比較的安いそうです)

一般のシステム開発では、要件定義や外部設計等のフェイズを通して、 仕様を決めていくことが行われますが、 これは進捗するに従って、要件が変更ができなくなることを意味します。

ビジネス環境の変化が激しい現代において、このようなスタイルがマッチしないケースが 出てきていますが、「納品のない開発」では、 いくらでも仕様変更できる、というメリットは大きいでしょう。

「納品のない開発」は広がるか

こう見ていくと、「納品のない開発」は大変魅力的に写ります。 それではなぜ、一般に広がらないのでしょうか。

筆者も「納品のない開発」の限定性(大規模プロジェクトには向かない)を指摘していますが、 1つには、発注側の意識改革が進まないことがあげられるでしょう。

実際問題として、発注者側から見ると、 これまでのシステム開発モデルと比較して、 リスクを開発会社に転嫁できない分、不利のような印象を受けるでしょう。

このことは、顧客側は、ITに関して、一括丸投げモデルから、 一緒に考えるモデルへの変更が迫られることになります。 この意識変革を受け入れることができるか、というのが大きいように思います。

そして、この「納品のない開発」への期待としては、 現状のITエンジニアの環境改善にいくらか貢献するではないかと思います。

さきほど、米国のITエンジニアは高収入であると、 話をしましたが、彼らは日本のエンジニアと比べると、 明らかに業務の範囲が広いです。

彼らはIT技術に精通していることはもちろん、 ビジネスにも精通している人が多いです。

それは、米国のエンジニアの72%がユーザー企業(内製)で、 一緒にビジネスを遂行している結果だと思います。

日本のITエンジニアは、技術を磨いていますが、 ビジネス感覚に乏しいことは幾度となく指摘されています。 その結果として、顧客の「もっと提案して欲しい」という 要望はいたるところで聞けます。

「納品のない開発」の中で、中長期に顧客とともに ビジネスを成功に導くという経験は、非常に重要なように思います。

最後に、「納品のない開発」の主要顧客はスタートアップが多いそうですが、 そういったスタートアップから、成功事例が増えることで、 「納品のない開発」がより広く認知され、 冒頭で挙げたような業界の不幸な状況に風穴を開けてくれることを期待しています。