投稿元:
レビューを見る
「ソリューション営業」は終わり「イノベーション「営業」でなければならないとかいい言葉はいっぱいあったが、個人的にアジャイルとかスパイラルという言葉に嫌悪感があるので★は1個しか付けられなかった。
アジャイルとかスパイラルがなんで嫌いかというと、濃霧の中突き進むシステム開発の方便として使われるから。
家を建てる時に、まずリビングを作って、次にキッチン、と順番に作っていく人はいないはずなんだけどな。
某国では出来上がってからエレベーターがないことに気が付いたマンションがあるらしいが。
投稿元:
レビューを見る
20150811読了
現状のSIビジネスの問題点と、ポストSIビジネスを成功させるための解決策について書かれた本。
SIerは変わらないとジリ貧になる。もう既になっているか。既存事業がうまくいってるうちに次の手を考えること。
投稿元:
レビューを見る
タイトルだけを見るとまるで明日にでもSI業界が無くなってしまうかのように受け取れますが、中を読んでみると全くそんなことは書いてありません。むしろ、さまざまな製品やサービスを組み合わせて顧客の価値を創出するという、本来の意味での「システムインテグレーション」ができるITベンダーこそが今後生き残っていける、という警鐘を込めたタイトルであることが分かります。
ITベンダーが算出する工数をベースとした金額でユーザ企業が発注し、要件定義を実施した後ITベンダーがシステムを開発して納品する、といった従来のSIビジネスにおいては、「ユーザ企業とITベンダーの考え方のギャップ」および「ゴールの不一致、相互不信」といった事象が様々なプロジェクトで起こっています。
このことが、IT業界が「3K(人によっては7Kとも・・・)」と揶揄される要因となっています。当のITベンダーにとってもユーザ企業にとっても、全くうれしくない状況です。
この状況を打開するためには、ITベンダーだけでなくユーザ企業(のIT部門)も変わる必要があります。
私は現在ユーザ企業のIT部門で仕事をしていますから、経営戦略を実現するためにITを使ってどのような施策を講じるのかを常に考えています。まさに本書でいうところの「コンセプト」および「デザイン(全体計画・市場・道筋・体制)」です。これを実現するために、どんなソリューションやテクノロジーを組み合わせれば良いのかを提案してくれることをITベンダーには期待します。
自社製品を押し付けたりエンジニアを派遣する従来のやり方に固執するのではなく、「顧客に価値をもたらすには何がベストか」という観点で、本当の意味でユーザ企業のパートナーとなるのが、これからのITベンダーに求められる役割ではないでしょうか。
投稿元:
レビューを見る
変化の激しさに対応するためにアジャイル開発を。
IT投資が、減る中クラウドやOSSでコストを抑えることでその分IT投資を。
作るから利用するにシフトを。
お客様のCEOに近い立場で。
何年か前から海外で流行ってるものがそのままきた感じ。
流れがまとまっておらず読みにくかったですが、言ってる内容はそのとおりでした。
投稿元:
レビューを見る
先輩の勧めで読了。面白すぎてスイスイ読んでまいました。SI業界に従事してる人は読んで損なしな良本です。感じるところは人それぞれかと思いますが。
投稿元:
レビューを見る
IT業界についての本でおススメされて読んだ一冊。
『システムインテグレーション崩壊』という、SIとして働いている人なら誰もが頭の中にあることを体現したタイトルに思わず目を留める人も多いのではないだろうか。
内容は社会やITの需要の変化から、従来型の工数計算と人月を中心としたシステム開発が成り立たなくなっていく中で、SIはどう対応していくべきかということが示された一冊。
SIは
・資産ビジネスからサービスからビジネスへの転換
・クラウドの活用
・オープンソースの活用
・グローバル化への対応
・新たな役割と存在意義の構築(ユーザーのパートナー、コンサルタント的役割)
に対応することが必要だという。
著者が営業出身、現在は取締役ということもあってか、
この内容は経営層は営業職の人たちにとっては有意義なものとなると思う。
現場の技術職の人たちにとってはより高い視点から自分の置かれた立場を考えさせられる一冊になるとは思うが、目新しさはあまりないのではないかとも思う。
投稿元:
レビューを見る
テクノロジーやノウハウを組み合わせ、ユーザー企業の求める最適なシステムを構築する仕事は今後もなくならない。しかし、SIerの仕事と役割、ユーザー企業との係わり方、収益を上げる手段やスキルは変わらざるをえないーSIerはこれからどうすべきか?現状と未来を豊富な図解とともに明らかにする。
投稿元:
レビューを見る
日本特有のユーザー企業環境で成長してきたシステムインテグレーター業界。昨今の大きな展開要素はこれまでのような「分業思考」ではユーザー企業のビジネス変化のスピードに対応できないという事ではないか。そしてユーザーの抱える課題を解決するソリューション営業ではなく、イノベーション営業の必要性も高まっている。システムインテグレーターがそれらを担えるか、担うべきかは別として、それが現在のユーザー企業が向き合い実情だという事。一方で、イノベーション営業は「やれ」と言われてできるものではないとも強く感じる。人材流動性やオープン性を活性化させないと、理論先行型になってしまうにが1つの課題ではないだろうか。領域毎にイノベーション営業がある程度オープンに集う外部環境を創る必要性を再確認した。
投稿元:
レビューを見る
2018/3/19
・従来のSIビジネスは、ユーザニーズ変化(ビジネススピードUP)・テクノロジー変化にあわせてシフトしていかなければいけない
・サービス型ビジネス(サブスクリプション/レベニューシェア/成功報酬)、クラウドビジネス、OSSの活用
・営業は個人力でなく体制を整えた業務知識を考慮したマーケティング力が必要。顧客のビジョンを自ら導くイノベーション営業が求められる
投稿元:
レビューを見る
日本型SIerはゼネコンと同じく顧客の要望をキッチリと実現してきた。しかしクラウドへのパラダイムシフトは自明のこととなり、事業構造はもちろんのこと、位置づけや役割までもが、現実とズレてきている。ましてや、働き方改革の声の中、業界までもが非難を浴び、人材確保が難しい状況に、、、
本書に記載される次の一手は、目新しいものではなく、一般論としてよく耳にする内容である。しかし、それが実行されてどうだった、という話は少ない。分かってる、でもそれをやるかどうか、が、最も高い壁だろう。
次の世代のためにも、ここがおっちゃんらの頑張りどころだと思う。
投稿元:
レビューを見る
発注元とベンダー間の相反性がとてもうまく描かれている。本来は更にここに複数のベンダーが関わる横の展開と、ベンダーの後ろにいる下請けの縦の展開があり、カオティックであることは間違いがない。
ポイントは「顧客と開発者が同じゴールを見ていない」ことであり(仕組みとして)、それらを解決する手法を見出さなければSIerなど今後淘汰されてしまう。
サービス型への転換は確かに必要であるが、フローが少なくなるために好調であるうちに実施するか、ベンチャーのような機動的な企業のみが対応できる。
バックエンドで評価の仕組みなどを整え、開発のみでなく営業についても役割を更に深化させ、サービスビジネスに特化したビジネス手法の積極的な取り入れが必要。
大きい企業であればあるほど難しいので、小さく、専用の組織を作ってもらいたいところ。そもそもまず「人を動かせない」ところから始まり、開発開始後も基本的には注文がないと仮定すると、顧客との信頼で動くのか、SIドリブンで動くのか、さはさておき空白期間が生じる。ここの説明を求められるためだ。
投稿元:
レビューを見る
大きなストーリーは木村岳史さんの本の主張と同じ。ただ、明確になった点が2点。SIerは人月商売をしているから、必ず人月を増やす方向で提案を膨らませる一方でユーザー側はコスト削減をしたいので、ここに明確に利益相反があるということ。当たり前ですが。
もう一つは、クラウドやオープンソースの活用でリーンなスタート、つまりあまりお金をかけないで情報システムのお試し環境を作れる時代になっていること。そしてこれらの技術は人月商売をやっているSIerが一般的に持つ技術と異なること。ただ、バラックの仮店舗でいいのでスタートさせたいというニーズにはマッチする。人月商売の呪縛から逃れないとこうした新しい技術を取得できずに落ちこぼれてしまう可能性があることが示唆された点で良かったです。
また、人月に依存しないビジネスモデルの提示も良かった。サービス型(サブスプリクション型)やリベニューシェア、成果報酬といった形は、ベンダー側がビジネスのリスクを負っている分、ユーザーとベンダーがWin-Winの関係になっていて利益相反が発生しないのが上手いなと思いました。勉強になります。
投稿元:
レビューを見る
改めて考えてみると、SIerの友達いないなあ。現場で働いてる人の実情を本書と比較してみたい。
日本では米国と比べて、パブリッククラウドを普及させる上で人的コストや管理工数削減がメリットになりにくい話が面白かった。
・ITエンジニアの72%がユーザー企業に所属する米国、75%がSI事業者やベンダーに所属する日本
→SIの人月商売ビジネスモデルと相性の良いソリューションを優先する
・人件費は変動費の米国、固定費の日本
→簡単に人を切れないから、パブリッククラウドの人件費削減の効果がメリットになりにくい
投稿元:
レビューを見る
ウォーターフォール開発が大嫌いな自分としては、意見を代弁してくれていて心地よかった。以下、引用。
■ウォーターフォール型の開発プロセスでは新しい価値を発揮できない
システム開発は、要件定義から始まります。しかし、ユーザーの要求は時間とともに変化します。ビジネスサイクルのスピードが速まるなか、要求が変化するスピードもまた速まっています。すべての要件を定義することからスタートするウォーターフォール開発では、この変化の対応は容易ではありません。
また、早期に仕様を確定しようとすると、ユーザーはリスクを見越して何でも仕様に入れようとします。その結果、使われない機能が盛大に作り込まれることになります。そして、いざ完成してみると、「そんな機能は使えない、使わない」となり、無駄な工数と時間を費やしただけになってしまいます。しかも、瑕疵担保がありますから、工数に関係なく、現場が納得するまで変更要求に応えて改修しなければなりません。
ウォーターフォール開発では、すべてが完成してからユーザーが検証することになります。そのため、リスクは後ろに片寄せされ、最後になって大きな負担を強いられることもめずらしくありません。何を改善すればいいかも、最後にならなければわかりません。そのため、仕様書に忠実であることに専心せざるを得ず、開発の過程で現場の要望に臨機応変に対応する機会を与えられることはありません。
お客様の反応が見えない開発者。
どんなシステムが出来上がってくるのか、最後にならないとわからないユーザー。
両者がそんな不安を抱えながら、開発を進めているのです。
そもそも、ウォーターフォール開発で言う「要件定義書」とは、ユーザーの要求事項を固定し、要件の変更を受け付けないようにするための方便と解釈することもできます。これは、「ユーザーの要件を整理する」と言えば聞こえはいいのですが、ユーザーに要件を全部出させ、「変わっても受け付けませんが、いいですね」といって約束を取り付けているにすぎません。「要件を全部出す」といっても、決まっていないこと、予測のつかないことも多々あります。そのため、「こんなことがあるかもしれない」「何かあったら困るからこの要件も入れておこう」と推測し、どんどん要求を増やしていきます。
たとえ現時点で必要とされる要件を並べても、ビジネス環境が変われば、想定していない事態に遭遇することは避けられません。要件は時間とともに変質します。したがって、「要件が変わらない」という前提には、はじめから無理があるのです。
結果として、開発者は使われないプログラムコードを作ることに手間を費やし、ユーザーは余計な費用を支払わされることになります。
■「アジャイル型請負開発」で高品質・短納期・利益拡大を両立させる
…アジャイル開発の本質は「全部作らない」ことだと理解する必要があります。これが、ウォーターフォール開発と本質的に異なる点です。アジャイル開発は、「業務上必要性が高い機能やプロセスを選別し、優先順位を決めて、そこに��ソースを傾注することで、必要なシステムのみを作り上げよう」という考え方です。結果として、短期間、高品質での開発が実現します。
「ソフトウェアの業界は、これまで、人を大切にしてこなかったと思いますよ。自分たちが何を作っているのか、どんなふうに使われているのかを伝えようとはせず、言われたとおり作ればいいという考え方です。人を工数としか見ていない。そんなことでは仕事にプライドを持てないし、がんばろうという意欲も湧かない。…そんなところで、プログラマの自発性や自律性を前提とするアジャイル開発なんて育ちませんよ」
「顧客開発モデル」や「イノベーション」についてスタンフォード大学などで教鞭を執るスティーブ・ブランク氏は、既存事業を抱える企業が新たな事業を始めるためには、次の4つの取り組みが必要だと述べています。
・既存事業部門の外部に新しい組織を作ること
・10件のうち1件しか成功しないことを覚悟すること
・新しい組織に対し、ヒト、モノ、カネを安定的に提供し続けること
・新しい組織に「創業者」タイプの人間を集めること