SIS Lab
>
Blog
>
「「納品」をなくせばうまくいく」を読んで生存戦略を考える

「「納品」をなくせばうまくいく」を読んで生存戦略を考える

更新日:2022.07.02 作成日:2015.10.25

#SIer #システム #生存戦略

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

出版社：日本実業出版社

著者:倉貫義人

発売日: 2014/06/12

Amazon Kindle 楽天市場 Yahoo!ショッピング

この本から何を得たいか

「納品のない受託開発」とはどういう開発か
「納品のない受託開発」に至った背景にはどういう考えがあったのか
「納品のない受託開発」をするポイントはどこか
どういったマインドが必要になってくるのか

一括請負の功罪

一括請負での受託開発は、顧客にとって負担が大きくて無駄も多く、開発会社を経営する立場からはリスクは大きい割に利益が出にくい上、現場で働くエンジニアたちを辛い労働環境に追いやっています。つまり、関係者の誰も幸福にしていないビジネスモデルだと分かります。

一括請負ビジネスは、システムインテグレーション崩壊でも触れていたように、顧客と開発側で向かう方向が一致していない。顧客側は、とことん仕様を入れ込もうとするし、開発側は変更を抑えるように働きかける。お互い不幸になるビジネスモデルである。

「システムインテグレーション崩壊」を読んで生存戦略を考える | SIS Lab

書籍システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか? では、顧客側・開発側のお互いが幸せになるビジネスモデルの1つの解として、Sonic Gardenの「納品のない受託開発」を紹介していた。

納品のない受託開発ではどうなのか

「納品のない受託開発」では、以下3つをポイントとしている。

オーダーメイドの開発
納品しない
派遣しない

派遣とは違い時間単位での契約ではなく、顧客の得る「成果と満足度」による契約をすること。

ソフトウェア開発におけるエンジニアの仕事は、時間に換算できるものではない。

時間単価で働くということは、その時間内は仕事場にいることが"価値"になってしまい、どれだけ効率化して早く仕事を仕上げたとしても意味がなくなってしまう。

その中でも、コストを抑えるためにはどうしているか。

LCCから学ぶビジネスモデル

LCC（Low Cost Carrier：ローコストキャリア）では、低価格を実現するために以下を行なっている。

使用する飛行機の機種の統一をすることで、整備費、訓練費を削減
搭乗手続きのオンライン化
一人何役もこなす

一方、納品のない受託開発では、このLCCのポイントを転用し、以下を実行することで低価格を実現している。

扱う技術の統一（Ruby on Rails, AWS/Herokuなど）
クラウドを活用した自動化と合理化（AWS/Heroku）
幅広いスキルを備えたエンジニアの兼務（企画、プログラミング、保守・運用）

いずれも効率化・生産性向上に繋がる。

ナレッジワーカーとしてのプログラマー

この「納品のない受託開発」をする上でのプログラマーは、ただ決まった仕様通りにコンピュータへデータを打ち込むだけの作業者では成り立たない。

企画の段階から考えて、画面のデザイン、仕組みの設計、自らプログラミングして、クラウドの運用・保守までソフトウェア・エンジニアリングに関わるすべての工程をこなせる人にならなければならない。

このナレッジワーカーとして、スキルをあげるためには、経験を伴う教訓こそが最も効果的なフィードバックであるとのこと。

人月を超えるには

「コンサルタントの秘密」では、「成果に対してではなく時間に対してもらえ」としている。これは、「納品のない受託開発」はサービス業ではあるが、目に見える形でのサービスを提供している（顧客が確認できる）ため、コンサルタントとは違っているのだろう。

変化を抱擁する

Embrace Change（変化を抱擁せよ）
Fearless Change（自ら変わることを恐れてはならない）
Social Change

世の中に変わらないものなんてない。変化は必然で、それに対して頑なになるのではなく、いつでも変化に対応できるように準備をしつつも自然体でいることが大事である。

世の中が変わる、身の回りの環境が変わる、仕事内容が変わる。未来永劫同じことなんてないのだから、変化を受け入れつつ、対応できるように自分を変化させていきたい。

「仕事は楽しいかね？」でいうところの、 明日は今日とは違う自分になる かな。

明日は今日とは違う自分になる〜仕事は楽しいかね？〜 - SIS Lab

どこを目指すか

視点を上げる

顧客企業にとって、ソフトウェアは使い始めることで初めて価値が出る。要件定義をして、その通りに作ったとしても価値は生まれない。

開発をしていると、どうしても開発者視点になってしまい、システムを完成させることが何よりの目的になってしまう。少し、視点を上げて、「テクノロジーを使って顧客ビジネス価値を高めること」というシステム・インテグレーションのあるべき姿を考えたい。

巨大システム一括請負もなくならない

自分の仕事の対価は給料じゃないんですよ。顧客が払ってくれるお金です。そこの認識が甘いのに、業界云々語ったりSIオワコンだからって言ってWebサービス会社に移っても、多分あなたを包む閉塞感や問題は何も変わらない。最終的にはビジネスモデルとの相性であり、費用対効果というROIの問題にならざるを得ません。それが何を意味しているかというと、技術力があっても解決できない問題を解決してこそ、その技術力が活かせるし生きてくるんですよ。そこに関心が向かないと。ピンハネをDISって終わりにするのは簡単。あれが悪いこれが悪いなんて誰でも言える。でもそれをひとつ上の観点から整理して何故こうなっているのかという話が出来ないと、業界の立ち位置は変わらないから良くならないし、エンジニアのキャリア設計を考える上でもマイナス。そのたたき台を提供していけたらと思っています。
人月商売が悪だと思っている、イノセントなあなたへ

自分の頭で考えもせずに、人月はすべて悪だーと反応するのはやめて、どういう構造になっているかをもって見定めるようにしたい。また、顧客側・開発側どちらにも言い分はあることを理解したい。