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

  • 59人登録
  • 4.04評価
    • (10)
    • (5)
    • (9)
    • (0)
    • (0)
  • 11レビュー
著者 : 倉貫義人
  • 日本実業出版社 (2014年6月20日発売)
  • Amazon.co.jp ・電子書籍 (183ページ)

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
伊賀 泰代
ジェームス W....
クリス・アンダー...
ウォルター・アイ...
岸見 一郎
有効な右矢印 無効な右矢印

「納品」をなくせばうまくいくの感想・レビュー・書評

  • アジャイル信者による納品なしビジネスモデルの本。



    序盤に事例紹介、中盤にビジネスモデル、終盤に考え方について書かれている。作者はアジャイル信者で、アジャイルっぽく仕事しようとしたらこういうビジネスモデルになったらしい。感覚的なところは俺とそっくりだったので、非常に驚いた。俺はアジャイルとかどうでもいいから。



    モノ作りがしたいだけの俺の考え方を述べると、以下のような感じになる。

    【モノ作りがしたいだけの俺の考え方】
    納期を守りたくない。
    ⇒しんどいから。
    納品したくない。
    ⇒めんどくさい。変更する度に納品とかやってられるか。
    終わりのない仕事はしたくない。
    ⇒デスマーチは嫌だ。同じことをずっとやるのも嫌。
    顧客と話したくない。
    ⇒リスクを丸投げしてるだけのくせして、いいたいことだけいうな。
    ドキュメント書きたくない。
    ⇒メンテナンスしないなら作るだけ無駄。

    俺の思考回路でこれを改善する方法を考えると次の流れになる。ITが業界ごとブラックな原因のすべてが1にあるので、これをなくさないとダメだ。なので、納期を約束しないようにする。納品とかめんどくさいので、WEBサイトに公開して、自分で保守しよう。サービスとして使ってもらおう。サービス化して使ってもらってフィードバックもらえば、4はやらなくてよさそう。自分でサービス作ったら、好きに止めれるから3も解決だな。5は作るの止めればすむ。ということで、俺の結論は、「自分で会社を作って株主になってサービスを作って提供して売れたら、好きなモノ作りだけできる」というものだ。


    俺のやり方はヒットしないと生きていけない大博打だが、作者のやり方は少しずつ積み上げていけるやり方だ。1、2、5を解決し、3と4を我慢する妥協案かな。そこからさらに突き詰めていて、これをやると必然的に顧客がかわってくる。既存のウォーターフォールモデルだと「リスクを外出しできる」規模に限られるが、納品なしモデルだと「大きすぎるリスクをいっしょに背負ってくれる」感覚に近くなるためだ。


    思考回路は違うために結論が違っているが、途中の感性は似すぎてて気持ち悪かったw




    俺はアジャイルに全く興味がない。アジャイルは技術者視点で作られたもので、顧客視点がなかったから。出てきたときからうさんくさいと考えてた。今もうさんくさいと思ってる。開発方法論の中でビジネスを語っても何の説得力もないから。今も昔もシステム開発がうまくやる方法はたったひとつで、それは「顧客と仲良くなること」だ。要するに、リスクを外出しする仕事の仕方ではなく、パートナーとしていっしょにやっていこうと思っている顧客とだけうまく仕事が回る。それはウォーターフォールとかアジャイルとか関係ないよね。というのが俺の見解。

    単純に開発方法論だけ変更してもうまくいく訳ない。こいつらあほか。というのがアジャイル信者に対する俺の素直な感想だ。作者はそれをビジネスの問題に結び付けれているところがすごい。



    作者のビジネスモデルでいくと、あとは、ギルド自体の質の問題だろうな。ギルドの規模が大きくなると、悪い素材が混じってくるから、そういうのをはじき出せるようにしないと、一発で他のSIerやコンサルと差がなくなるからね。


    それ以外には、人と話をしたくないエンジニアは非常に多いから、ほとんどすべての開発者を救う訳でもないというところに注意が必要か。


    いや、一番はあまり儲からないというところかw



    一括請負保険業モデルから二人三脚モデルに変更したら、顧客層が変わってしまった。というのが一言で言い表したときの表現だなw

  • ソフトウェア開発の形態は難しいのですが、すごく分かりやすく読みやすく理解しやすくまとまっています。技術者の本は大抵ちゃんと説明しようとするがために字が多くなり難解になりがちですが、倉貫さんの説明にはそれがなく、仕事と同様に読み手のことをよく考えられた文章なのだなと思いました。
    アジャイル、リーンスタートアップ、ワークライフバランス、、そういったことを経験から導き出されて結果、実践されていると感じました。形から入ったとか全く感じられません。だから説得力があってすごく納得しました。ターゲットもはっきりしています。
    技術本などよりこちらを読んだ方が勉強になるんじゃないかと思いました。
    この方法はこれまで納品で死んでいたソフトウェアを、納品で産まれて育っていくものに変えてくれると思います。ソフトウェアが本当に(社会に、企業(経営)に、人生に)役立つものとしての地位を確立できるのではないでしょうか。日本はこれが苦手だったように思います。これを機にソフトウェアが日本の強みに変わっていけたらいいなと思いました。

  • ソフトウェア業界定番のビジネスモデルである「一括請負」受託開発に対して、よりモダンな開発手法でもって変革を試みる会社のお話。

    ソフトウェア開発会社にとっては「納品」がゴールだが、そのシステムを利用する側にとってはそこからがスタートである。であるならば、「納品」をゴールにするのではなく、システムを作りそして成長させるという納品の先までを見据えることが真の顧客サービスに繋がるという主張には頷くばかり。

    SI業界の今後を先んじて体現しているかのような稀有な会社像をかいま見える良い本でした。

  • お客さんにとってもエンジニアにとっても理想的な枠組みだと思いました。現状、なかなか既存の仕組みからは抜け出せないですが、ぜひこのムーブメントが広がっていくのをこの期待したいです。

  • 変化が加速する時代のソフトウェア開発モデルの実験。権力の分散(『第五の権力』)に伴うビジネスモデルの変革の実例。

  • 著者の倉貫さんの考えが全て語られている。すでに知っている内容がほとんどだったけど、月額いくらなのかが知りたい^ ^

  • IT関連に就いていない自分には、難しい内容かと思われたが、ITに限らず、広く職業観を問う内容であったので、多くの人に読んでもらいたい本。
    ただノルマを達成するための身に働くのでは、過労になりやすく、働くことの意義を探しながら、常に成長していくことの大切さを学ぶことのできた本。

  • 納品のない受託開発とは、従来の受託開発とは以下の点において異なる。
    ①ウォーターフォール型でなくアジャイル型
    ②一人のエンジニアがオーナーシップを持って顧客と対峙
    これらを実現するために以下を徹底している。
    ①会議はTV会議か、会社に訪問してもらう。
    ②不要なドキュメントは一切作らない。
    ③システム要件を聞く前に事業内容を聞いてその事業に共感する。
    ④納品するのではなく利用してもらう。
    ⑤用いる技術は社内で共通化する。(言語:rubyかruby on rails、サーバ:AWSか何か)
    ものすごく勉強になるが、正直長ったらしいし反復感が多いなという印象だった。こういった環境に身をおけると成長も実感できそうですね。

  • 久しぶりにマーカー箇所が多い本に出会った。 アジャイル開発を、パートナーと実践的に行う為のガイドブック。 開発一括請負・納品形態から、月額固定モデルへ。 まあ、実際難しい処は現実問題多いのだけれども。

  • たぶん、色々なところでこの理念を説明してきたんだろうなと思えるくらい、よくまとまっていてわかりやすい内容。
    こう言われれば、「合う」顧客からは絶大な支持を受けるだろうし、意識の高い技術者からすると一種の理想的な働き場所に見える気がする。
    顧客からすると情報システム部門を外出しできる感じになり、これはアリでこれからの1つの形態になりそうだなと思えた。
    人月モデルの悪い点はおっしゃるとおりでそれに対する1つの解であることは間違いない。

    顧客と、納期などは約束しないというのはかなり信頼関係がないと成り立たないなと一方思った。

全11件中 1 - 11件を表示

外部サイトの商品情報・レビュー

「納品」をなくせばうまくいくを本棚に「いま読んでる」で登録しているひと

「納品」をなくせばうまくいくを本棚に「読み終わった」で登録しているひと

「納品」をなくせばうまくいくはこんな電子書籍です

「納品」をなくせばうまくいくの単行本

ツイートする