改めて考えてみると、SIerの友達いないなあ。現場で働いてる人の実情を本書と比較してみたい。 日本では米国と比べて、パブリッククラウドを普及させる上で人的コストや管理工数削減がメリットになりにくい話が面白かった。 ・ITエンジニアの72%がユーザー企業に所属する米国、75%がSI事業者やベンダーに所属する日本 →SIの人月商売ビジネスモデルと相性の良いソリューションを優先する ・人件費は変動費の米国、固定費の日本 →簡単に人を切れないから、パブリッククラウドの人件費削減の効果がメリットになりにくい

大きなストーリーは木村岳史さんの本の主張と同じ。ただ、明確になった点が2点。SIerは人月商売をしているから、必ず人月を増やす方向で提案を膨らませる一方でユーザー側はコスト削減をしたいので、ここに明確に利益相反があるということ。当たり前ですが。 もう一つは、クラウドやオープンソースの活用でリーンなスタート、つまりあまりお金をかけないで情報システムのお試し環境を作れる時代になっていること。そしてこれらの技術は人月商売をやっているSIerが一般的に持つ技術と異なること。ただ、バラックの仮店舗でいいのでスタートさせたいというニーズにはマッチする。人月商売の呪縛から逃れないとこうした新しい技術を取得できずに落ちこぼれてしまう可能性があることが示唆された点で良かったです。 また、人月に依存しないビジネスモデルの提示も良かった。サービス型（サブスプリクション型）やリベニューシェア、成果報酬といった形は、ベンダー側がビジネスのリスクを負っている分、ユーザーとベンダーがWin-Winの関係になっていて利益相反が発生しないのが上手いなと思いました。勉強になります。

ウォーターフォール開発が大嫌いな自分としては、意見を代弁してくれていて心地よかった。以下、引用。 ■ウォーターフォール型の開発プロセスでは新しい価値を発揮できない 　システム開発は、要件定義から始まります。しかし、ユーザーの要求は時間とともに変化します。ビジネスサイクルのスピードが速まるなか、要求が変化するスピードもまた速まっています。すべての要件を定義することからスタートするウォーターフォール開発では、この変化の対応は容易ではありません。 　また、早期に仕様を確定しようとすると、ユーザーはリスクを見越して何でも仕様に入れようとします。その結果、使われない機能が盛大に作り込まれることになります。そして、いざ完成してみると、「そんな機能は使えない、使わない」となり、無駄な工数と時間を費やしただけになってしまいます。しかも、瑕疵担保がありますから、工数に関係なく、現場が納得するまで変更要求に応えて改修しなければなりません。 　ウォーターフォール開発では、すべてが完成してからユーザーが検証することになります。そのため、リスクは後ろに片寄せされ、最後になって大きな負担を強いられることもめずらしくありません。何を改善すればいいかも、最後にならなければわかりません。そのため、仕様書に忠実であることに専心せざるを得ず、開発の過程で現場の要望に臨機応変に対応する機会を与えられることはありません。 　 　お客様の反応が見えない開発者。 　どんなシステムが出来上がってくるのか、最後にならないとわからないユーザー。 　両者がそんな不安を抱えながら、開発を進めているのです。 　そもそも、ウォーターフォール開発で言う「要件定義書」とは、ユーザーの要求事項を固定し、要件の変更を受け付けないようにするための方便と解釈することもできます。これは、「ユーザーの要件を整理する」と言えば聞こえはいいのですが、ユーザーに要件を全部出させ、「変わっても受け付けませんが、いいですね」といって約束を取り付けているにすぎません。「要件を全部出す」といっても、決まっていないこと、予測のつかないことも多々あります。そのため、「こんなことがあるかもしれない」「何かあったら困るからこの要件も入れておこう」と推測し、どんどん要求を増やしていきます。 　たとえ現時点で必要とされる要件を並べても、ビジネス環境が変われば、想定していない事態に遭遇することは避けられません。要件は時間とともに変質します。したがって、「要件が変わらない」という前提には、はじめから無理があるのです。 　結果として、開発者は使われないプログラムコードを作ることに手間を費やし、ユーザーは余計な費用を支払わされることになります。 ■「アジャイル型請負開発」で高品質・短納期・利益拡大を両立させる 　…アジャイル開発の本質は「全部作らない」ことだと理解する必要があります。これが、ウォーターフォール開発と本質的に異なる点です。アジャイル開発は、「業務上必要性が高い機能やプロセスを選別し、優先順位を決めて、そこにリソースを傾注することで、必要なシステムのみを作り上げよう」という考え方です。結果として、短期間、高品質での開発が実現します。 「ソフトウェアの業界は、これまで、人を大切にしてこなかったと思いますよ。自分たちが何を作っているのか、どんなふうに使われているのかを伝えようとはせず、言われたとおり作ればいいという考え方です。人を工数としか見ていない。そんなことでは仕事にプライドを持てないし、がんばろうという意欲も湧かない。…そんなところで、プログラマの自発性や自律性を前提とするアジャイル開発なんて育ちませんよ」 「顧客開発モデル」や「イノベーション」についてスタンフォード大学などで教鞭を執るスティーブ・ブランク氏は、既存事業を抱える企業が新たな事業を始めるためには、次の４つの取り組みが必要だと述べています。 ・既存事業部門の外部に新しい組織を作ること ・10件のうち１件しか成功しないことを覚悟すること ・新しい組織に対し、ヒト、モノ、カネを安定的に提供し続けること ・新しい組織に「創業者」タイプの人間を集めること