ITの隊長のブログ

ITの隊長のブログです。Rubyを使って仕事しています。最近も色々やっているお(^ω^ = ^ω^)

【感想】「「納品」をなくせばうまくいく」を読んだ

スポンサードリンク

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

率直な感想は。。。おもしろかった!!!!

私は主に受託開発担当です。

ユーザーからお問い合わせがあり、要望を聞いて、提案しながら要件定義を固め、予算を伺い、見積もりを出す。

んで、契約したら、1ヶ月〜3ヶ月掛けて開発。長ければ1年〜2年。ユーザーへレビュー。そして納品。

その後はバグがあれば修正するし、要望があれば追加発注。

この流れってほとんどの会社にある流れだと思うんです。みんなやっていると思います。

で、ほとんどの人が経験していると思いますが、100%その通りにいった要件ってありましたでしょうか? 私はありませんでした。というか、まれに作り直しが発生したりとどっちかといえば、すごく大変なこともありましました。これがプログラマーが残業が多い仕事の原因でもあるんじゃないかなと思います。

でも、単純に作業が多くなったら残業が多いってことにつなげるのは安直だと思います。もっと他に原因はあるんじゃないかなと思いながらも、「他の会社も同じだし、ま、いいか」などと、これまで深く考えたことはありませんでした。

それをこの本はすべてを吹き飛ばしてくれました。勝手に「常識」と思っていたことが「常識」ではなくなりました。これはもっと早く出会うべきでした。

すべてのことがうまくいくとは限らないと思うけど、私は是非試してみたいと思ったことが色々あったので、メモまとめみたいな感じで感想を書いていく。

納品してからスタートだということ

当たり前のことだが、お客さんはシステムを使うことが目的ではない。システムを使って利益向上や効率化などを求めている。

しかし、私が日々対応している受託開発はお客に喜んで貰えるフローにはなっていない。お客さんの立場になれば現状のフローに不安がいくつかある。

  • 要件定義が決まった、または納品した後に変更をお願いすると、いわゆる追加発注となる
  • そういったことから、ITはよくわからないが要件定義に必死になる
  • 実際に動くものを使ってみないとよくわらないので、すっきりしない。不安である

開発側から見てもうれしくはない。仕様変更を追加発注してくれると企業的に嬉しいかもしれないが、これは相手が中小企業さんだと中々通らない。一緒にやってくれと無料で受注することが多く、そんなことを多くのプロジェクトごとに受けてしまうと開発者が疲弊する。

おかげで「仕様変更」って言葉にちょっと抵抗を持っていると言ってもいいぐらい。

また、お客さんは納品してからスタートなのだ。初めてそこから使い始めて、本当に使いやすいのか。ユーザーの反応はどうなのかなどなど分析してまた試行錯誤していきたいと思っている。なのに、それから要望を出すと「追加発注」となる。

ユーザービリティを得るためにはABテストなどの施策、仕様変更を繰り返し行い、試行錯誤していくとことで向上していくものだと学んだことがある。

ここまで書くと、本当変なフロー(ウォーターフォールのことではない)だと思う。ユーザービリティを上げると喜ぶはずのお客さんが「仕様変更」するたびに「追加発注」しなければいけない。多くの資産を持っていれば可能かもしれないが、中小企業では苦しいはず。また大手企業だったとしても見積もりにうるさいし、中々下まで大きな金額を落としてくれない。またプロジェクトによっては初回の見積もり金額で受ける場合もある。

この流れが続くといったい誰が喜ぶのか。少なくともWin-Winな関係ではないと思う。

根本的な原因として「要件定義」「納品」この2つが大きな縛りを生み出してきたんじゃないかなと思う。大切なことだけどそこに大きな金額が伴うのでお客と企業、どちらも中々踏み出せないのかなと思う。

そこでこの本のタイトルにもある、そもそも「納品」をなくそうというチャレンジですよ。

先ほ不安から解決していくと

  • 1週間に一度MTGをして、本当に必要と判断したものを決めてから開発する
  • 要件定義書は作らない。常に変化するかもしれないためそもそも必要ない
  • 開発したものをユーザーに実際に体験してもらい本当に望んでいたものか答え合わせする

さらにこれをソニックガーデンさんは月額で契約しているらしい。そのため、「追加発注」などの概念がない! こりゃすごい。

恐らく利益率を確保して金額を決めていると思うので、無茶なボリュームを受け取らないようにすれば開発陣は疲弊しないだろう。

アジャイルの手法で進めていて、月額にしてしまえば、「納品」という概念が消える。これはお客さんは不安はほとんどなくなり喜ぶんじゃないかなと思う。

「契約」は「結婚」

私が初めて務めた会社は「BtoB」を主にした会社でした。

ITも初めてだったので、技術的なことで自由に遊ばせてもらいました。

ただ、努めて年数もたったころ、役職も頂いたことにより、営業的なことを担当したとき。「こっちが悪くても謝らない」「自分以外は敵」「強豪に死んでも負けたくない」「1位を目指さないとダメだ」「相手をコントロールしろ」などなど、「ここは戦国か修羅なのか・・・」なんてことを教わりました。

人と素直に話すことが好きで、人の嫌がることは極端に嫌い、また嘘がすごく下手くそな私にはすごく辛い日々が続きました。いやー。正直二度とやりたくないw

おかげ様でどんな会議もあんまり怖くない度胸はつきましたよと。相手のいうことはあんまり鵜呑みしない残念な感性が身につきましたよと。

その会社は色々あってやめたんですけど、次に務めた会社は「BtoC」の会社かなと思います。お問い合わせのほとんどは企業さんなんですけど、実際使うのは企業さんなので「C」に当てはまるんじゃないかなと思います。

そんな話さておき。驚いたことは、お客さんの声です。開発陣もディレクターとついていくことは多からずともあったので、お客の声を目の前で聞くことがありました。クレームも中にはあるんですけど、嬉しい声もあり「すごく反響があったよ!」「仕事が楽になったよ!」などなど聞くとうれしくないはずはありません。それは前の会社では体験することができなかったことでした。

そんなこんな経験した私は当時から自分以外は敵だ!と教えこまれてた中で疑問を持っていたとしても、「こんなちょっとのことで!?(´・ω・`;)」なんて思い、お客さんの喜びは素直に受け取ることはできませんでした。本当残念な感性。。。

お客様は敵だ! => お客様はもしかしていい人? なんて感性を取り戻しつつありました。

さて、話は代わり。この本が言うには顧客はパートナーであり、「契約は結婚」みたいなことと書いてありました。これには衝撃!

「納品のない受託開発」は、顧客のパートナーとしてずっと支えていくことを目指しています。それは、顧客の事業が続く限り、私たちもサポートして続けたいということで、それはまるで、会社同士の”結婚”みたいなものだと思っています。(P69)

何度も繰り返し書いてありますが、我々はサービス業でお客さんの事業がうまくいかないことには契約してもらえません。契約が続くことがありません。

会社があるから仕事ができるのではなく、お客さんの事業が続いているから仕事を頂いていることが本質だと改めて認識しました。

なので、次はこれでいこう!なんてお願いする仕様変更を嫌がるなんてことはそもそも本末転倒なんですね。反省します。

感想

「ソニックガーデン」という会社のファンになりました。この1年から2年の間に「ギルド」ってとこに参加したい。

今はまだ副業みたいなことはできない(知識的にもスピードでも足りない)ので、勉強・経験あるのみ。

はやくこの人達に追いつきたいなと思う。

また、重量課金制で汎用的なawsみたいなサービスが盛り上がるのもなんかわかるような気がしてきた。

自分がお客であり、どうしてこのサービスを使っているか。などなど分析してあげるともっと面白いことがわかるかもしれない。

なんて、色々知見や夢が膨らみわくわくさせられたそんな本でした。読んでよかった。

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

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