書籍【「納品」をなくせばうまくいく】 [その他]
【納品をなくせばうまくいく】
上の書籍がソフトウェア業界で若干のブームを呼んでいます。(うちのまわりだけ？？？)
ソフトウェア開発とは「納品」が最後にあります。
受託開発は、お客から注文を受けてオーダーメイドでシステム構築を行い、最後に納品です。
それでお金がもらえるのですが、その「納品」を真っ向から否定するタイトルが印象的で
いろいろと賛否両論となっているわけです。
「納品」をなくすということ、これができるとどれだけのエンジニアが救われるでしょうか？
ただ、このタイトルを見て興味をもって調べる人はまず「納品＝なければ楽」ということで
この本に興味をもつと思います。
私もそうでしたが、この本はそういう人が思っていることが楽になる本ではありませんでした。
まず、受託開発の現場の状況を考えましょう。
多くのシステム開発での受託開発は、請負契約で行われており
見積もりに対して請負い、完成したらお金をもらうというところ。
まず、なぜ顧客が「請負」を選択するのか。
この「納品のない・・・・」を実現させたい場合、以下のような現場では無理だとありました。
★お客が、システムの完成リスクのすべてを請け負った会社に背負わせたいと思っている
この前提があるあなたは、残念ながらこのタイトルのようなことを現場で行うのは困難です。
ですが、請負契約を選択する顧客の多くは「最初の注文で金額が決定し予算がたてやすい」
「責任は丸投げ」これにつきるでしょう。
昔からこれがあるから「請負」なんです。
SEの現場では「SES」など時間精算があります。
言われた作業、受けた作業をやった時間分だけお金にかえて支払ってもらいます。
作業ピークになれば当然残業も増えていきますのでお客の負担は増えます。
SESだと働く側の会社からすればだらだら仕事しても時間さえかせいでもらえればお金になるので
というお客の思いと正反対の考えをする営業なども多いです。
この「納品を・・・」の本にあるのは、以下のようなことが書いてあります。
・月額定額制
・見積もりしない
・納期を約束できない
・担当者がずーっとそのシステムの面倒をみていく
などなど
ようするに私が理解したのは、企業の専属弁護士や専属会計士、専属税理士のような位置づけで
専属システムエンジニアを雇うとうなものかなと。
ただこれにも無理があると思いました。
専属〇〇という職業には「国家免許」がありますよね。
エンジニアがとるIPAが提供している情報処理試験という国家資格がありますが
これは免許ではないので必須ではありません。それにこの試験はあまりに実践とかけはなれているので
実務経験のない学生でも本で勉強しまくれば受かれる可能性があるというもので、実際現場でもあまり
重宝されません。（お客さんに売り出す経歴書とかには書くと効果的ですけど）
「納品をなくす」には、まずこのビジネスモデルに賛同する顧客が必要という前提のようです。
あと大規模開発には向いてません。小規模なシステム（書籍ではWebサイト）を1名でずっと月額定額で
エンジニアがメンテしていって、機能追加して欲しいというタイミングで作る、試すということで
そうやって徐々にシステムを顧客の望む形に作り替えていくというものです。
【納品をなくす】というシステム開発の「苦」のひとつがなくなるようなタイトルですが
中身はかなり限定されます。
なので、請負を頼むようなお金のない、またはお金にシビア、責任にシビアな企業ではできないです。
上層の発想が柔軟なベンチャー向きでしょう。
組織化の完成してしまった大企業では無理です。
でもまぁプロセスなどは見習うところがあるとは思うので
請負であっても、納品が存在したとしても、一部分をお客さんに熱弁してとりいれてもらうとか
（例えばメンテナンスも同じエンジニアで継続とか）でもいいかと思います。
まぁそれだとDevOptと何が違うんだという話になりそうですけど・・・。
ただ、今のソフトウェア業界の開発スタイルは
悪しき時代の「人月神話」や「請負」など誰も得しないルールが残ってます。
これって作ってる側も作ってもらう側も誰も得してないと思うんです。
誰も得しないのにこの方法しかないこの状態が異常なのです。
それに対してこんなビジネスモデルどうですか？という提言をしてるのがこの書籍の本質だと思っています。
本当に人月工数とかくだらないと思ってます。
誰もが作っても同じ1人月になるわけがない。
建物ならまだしも知的創造物を誰が作っても同じ時間、同じ品質でできあがるわけがない。
私個人的には、もっとエンジニアにランキングをつけるべきだと思ってますけどね。
IPAがITスキル標準を作ってますけど、これらをもっと細分化して、それこそ国家資格として
国中のエンジニアの格付けをすればいいと思うんです。
格付けで単価が決まればエンジニアの地位も上がるし、蔓延する似非エンジニア(なぜか開発のできないSE）を
排除、淘汰することができますからね。
ただこの書籍はソフトウェア業界に長くいて頭が固くなっちゃった人は読んでて楽しいです。
おすすめです。
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
- 作者: 倉貫 義人
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/06/12
- メディア: 単行本（ソフトカバー）
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/06/20
- メディア: Kindle版
上の書籍がソフトウェア業界で若干のブームを呼んでいます。(うちのまわりだけ？？？)
ソフトウェア開発とは「納品」が最後にあります。
受託開発は、お客から注文を受けてオーダーメイドでシステム構築を行い、最後に納品です。
それでお金がもらえるのですが、その「納品」を真っ向から否定するタイトルが印象的で
いろいろと賛否両論となっているわけです。
「納品」をなくすということ、これができるとどれだけのエンジニアが救われるでしょうか？
ただ、このタイトルを見て興味をもって調べる人はまず「納品＝なければ楽」ということで
この本に興味をもつと思います。
私もそうでしたが、この本はそういう人が思っていることが楽になる本ではありませんでした。
まず、受託開発の現場の状況を考えましょう。
多くのシステム開発での受託開発は、請負契約で行われており
見積もりに対して請負い、完成したらお金をもらうというところ。
まず、なぜ顧客が「請負」を選択するのか。
この「納品のない・・・・」を実現させたい場合、以下のような現場では無理だとありました。
★お客が、システムの完成リスクのすべてを請け負った会社に背負わせたいと思っている
この前提があるあなたは、残念ながらこのタイトルのようなことを現場で行うのは困難です。
ですが、請負契約を選択する顧客の多くは「最初の注文で金額が決定し予算がたてやすい」
「責任は丸投げ」これにつきるでしょう。
昔からこれがあるから「請負」なんです。
SEの現場では「SES」など時間精算があります。
言われた作業、受けた作業をやった時間分だけお金にかえて支払ってもらいます。
作業ピークになれば当然残業も増えていきますのでお客の負担は増えます。
SESだと働く側の会社からすればだらだら仕事しても時間さえかせいでもらえればお金になるので
というお客の思いと正反対の考えをする営業なども多いです。
この「納品を・・・」の本にあるのは、以下のようなことが書いてあります。
・月額定額制
・見積もりしない
・納期を約束できない
・担当者がずーっとそのシステムの面倒をみていく
などなど
ようするに私が理解したのは、企業の専属弁護士や専属会計士、専属税理士のような位置づけで
専属システムエンジニアを雇うとうなものかなと。
ただこれにも無理があると思いました。
専属〇〇という職業には「国家免許」がありますよね。
エンジニアがとるIPAが提供している情報処理試験という国家資格がありますが
これは免許ではないので必須ではありません。それにこの試験はあまりに実践とかけはなれているので
実務経験のない学生でも本で勉強しまくれば受かれる可能性があるというもので、実際現場でもあまり
重宝されません。（お客さんに売り出す経歴書とかには書くと効果的ですけど）
「納品をなくす」には、まずこのビジネスモデルに賛同する顧客が必要という前提のようです。
あと大規模開発には向いてません。小規模なシステム（書籍ではWebサイト）を1名でずっと月額定額で
エンジニアがメンテしていって、機能追加して欲しいというタイミングで作る、試すということで
そうやって徐々にシステムを顧客の望む形に作り替えていくというものです。
【納品をなくす】というシステム開発の「苦」のひとつがなくなるようなタイトルですが
中身はかなり限定されます。
なので、請負を頼むようなお金のない、またはお金にシビア、責任にシビアな企業ではできないです。
上層の発想が柔軟なベンチャー向きでしょう。
組織化の完成してしまった大企業では無理です。
でもまぁプロセスなどは見習うところがあるとは思うので
請負であっても、納品が存在したとしても、一部分をお客さんに熱弁してとりいれてもらうとか
（例えばメンテナンスも同じエンジニアで継続とか）でもいいかと思います。
まぁそれだとDevOptと何が違うんだという話になりそうですけど・・・。
ただ、今のソフトウェア業界の開発スタイルは
悪しき時代の「人月神話」や「請負」など誰も得しないルールが残ってます。
これって作ってる側も作ってもらう側も誰も得してないと思うんです。
誰も得しないのにこの方法しかないこの状態が異常なのです。
それに対してこんなビジネスモデルどうですか？という提言をしてるのがこの書籍の本質だと思っています。
本当に人月工数とかくだらないと思ってます。
誰もが作っても同じ1人月になるわけがない。
建物ならまだしも知的創造物を誰が作っても同じ時間、同じ品質でできあがるわけがない。
私個人的には、もっとエンジニアにランキングをつけるべきだと思ってますけどね。
IPAがITスキル標準を作ってますけど、これらをもっと細分化して、それこそ国家資格として
国中のエンジニアの格付けをすればいいと思うんです。
格付けで単価が決まればエンジニアの地位も上がるし、蔓延する似非エンジニア(なぜか開発のできないSE）を
排除、淘汰することができますからね。
ただこの書籍はソフトウェア業界に長くいて頭が固くなっちゃった人は読んでて楽しいです。
おすすめです。
2014-11-27 02:03
nice!(0)
コメント(0)
トラックバック(0)
コメント 0