永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
「ITエンジニア生き残りの条件」について思ったこと - GoTheDistance
日経○○あたりに載りそうなキャリア関係の記事が技術系雑誌のSoftware Design誌にあったので、興味を惹かれて購入しました。 Software Design (ソフトウェア デザイン) 2010年 12月号 [雑誌] 出版社/メーカー: 技術評論社発売日: 2010/11/18メディア: 雑誌購入: 4人 クリック: 80回この商品を含むブログ (15件) を見る 特集記事の「ITエンジニア生き残りの条件」についてちょっと思う所あったので、僕も書いてみます。 ちなみに、僕は雑誌媒体で「SIゼネコン」とハッキリ書かれているのは初めて見ました。これが日経ビジネスに飛び火すればもっと反響がありそうで面白いのに。 特集記事の前半は現状整理。「リーマンショック以降下請けに流せる仕事が無くなった」 & 「クラウドの台頭で今までの価格帯が通用しなくなった」のダブルパンチを受けて、赤壁の合戦の連鎖
営業ができる人とできない人の違い - GoTheDistance
営業という言葉に良いイメージを持ってる人はかなり少ないんじゃないかと思います。特にエンジニアは営業さんに「泣かされた」経験がおありの方が多いですし。また、電話爆撃営業や詐欺に近いような営業も多い中、益々うさんくささが先行しやすいのかなぁと思ったりします。 ホントはそういうもんじゃないだろって思うので、自分１人で顧客の所に赴き、話をしに行くことも増え、発注側として営業さんの話を聞くことも増えてきました。そんな中で、営業について感じたことを書いてみます。 1. できる人は相手に問いかける、できない人は自分が話し続ける 相手とのコミュニケーションの中で距離感をつかみ、お互いが負担にならないようなコミュニケーションの土台をまずつかむこと。これが恐らく営業のはじめの一歩なんじゃないか、と思っています。 その土台を作るのに、まず自分のことを立て板に水を流したように話す営業がいますが、その時点で僕は「も
これからやってくるクラウドの時代とSIerのあり方 - GoTheDistance
PublicKeyの新野さんが刺激的なエントリを書かれているので、便乗してこれからのSIerの未来像を考察してみます。 顧客にとってITコストの削減はSIerにとって売上げの減少になります。顧客がクラウドのサービスをそのまま利用することは、開発やカスタマイズをすることに存在意義があるSIerそのものを脅かします。 クラウドの存在は、SIerにとって逆風のように見えます。そしてSIerの存在もクラウドの普及にとって逆風なのかもしれません。 日本のSIerはクラウド普及の逆風なのか？ － Publickey クラウドとSIerの価値が相反している為、お互いにとって｢目の上のたんこぶ｣ではないかという意見ですが、現状その通りだと思っています。開発せずにスムースにサービスを利用できることがクラウドの強みでもありますが、システム運用をクラウドによって完結させることができる故にシステム基盤の構築･運用
Service Integratorになれる日が来るのだろうか - GoTheDistance
ZEROBASEさんのBlogに書かれていることが、自分の問題意識とシンクロした。この辺で少し整理しておきたい。 要件定義前提のビジネスモデル Webサービスに「システム開発」の側面があるからといって、業務システムのように「ユーザに聞く」とか「要件定義」とか「要求開発」しようとする発想では、うまくいかない。そこで「プロダクトアウト」か「マーケットイン」か、といった二分論での議論も危険。どっちの面も必要に決まってる。 そういう仕事って何？「マーケティング」や「商品企画」ですよね？ で、それってSIerには未知の領域なんだと思います。 SIerはWebサービスを開発できるのか？ SIerがディフェンシブにならざるを得ないのは「要件定義」というプロセスそのものにあるのではないか、と最近思いはじめました。要件定義が基点となって「我々は今回こういうものを作るのです」という取り決めを行いその器の大きさ
他人からの評価は受け止めちゃいけない - GoTheDistance
｢このままではどこか不安だ。自分の今の状態ってどうなんだろ｣っていう意味で、ブログ等で発信を始めたい方はいっぱいいると思います。そんな方へ。 実際には、「自分の考え方を情報発信する」ということは、「批判を受け入れる覚悟を持つ」ということです。 そして「批判を受け入れる覚悟を持ち」「批判を受け入れる」ということは、成長に繋がります。 ビジネスパーソンが、積極的に社外に情報発信すべき理由。そして、最初の一歩としてやるべきこと：永井孝尚のMM21：ITmedia オルタナティブ・ブログ 上記のように｢批判を受け入れる覚悟を持ちなさい｣と説くケースが典型的だと思うんですが、まるで自分に降って来る全ての批判を受け入れなきゃダメなんだ、と解釈されがちではないでしょうか？ 決してそんなことはないですし、これは大きな誤解です。過剰な反論空間は人を歪めるだけです。 批判を恐れずに発信していこうってよく言いま
それでもアジャイルに未来があるとすれば - GoTheDistance
前回のこのエントリの続き。 アジャイルって受託開発との相性が最悪な気がする - GoTheDistance 受託開発との相性の悪さについて問題提起をしてみたのですが、アジャイル開発って内製向きだよね以上のことが言えなかったので、もうちょい掘り下げてみます。 アジャイルや受託という切り口で書いてみたんですが、僕も頂いた様々なフィードバックを鑑みて考えたところ、受託も内製も滝も俊敏も関係なくて、要は｢前工程の成果物を後工程で活用できず断絶されている｣ということが全ての根幹にあるように感じた。 ソフトウェア開発は｢設計→実装→テスト→改善｣のサイクルを回して初めてPDCAが回るのに、我が国では何故か｢設計でPDCA｣→｢実装でPDCA｣→｢テストでPDCA｣という感じになっていて、前工程の成果物が後工程でフィードバックができず、やる必然性の無いことを違うレイヤーで繰り返しているんですね。で、当然
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
大きな会社と小さな会社のどっちで働くべきか迷っている人へ - GoTheDistance
いきなりポイントから入ります。大企業で働くことと中小企業で働くことの違いは、大企業はルールで動き中小は経営者の恣意で動くということです。ココがすごい重要です。 僕は６年近く大企業にいました。その時に考えたことは大企業で働くということ - GoTheDistanceで書きましたが、大企業の根本的な原理原則はルールで仕事が動くということです。異なる立場・異なるレイヤーの人たちを束ねて１つのサイクルを作るには、ルールを作ってその中でサイクルを回すより他ありません。それの累積によって企業文化なるものが形成されます。 大企業にいてよかったことは｢普通に仕事をさせてもらえる｣ことでした。もちろん仕事を選ぶことは基本的に出来ないんですが、明確に自分の役割が与えられ、そのロールに従いすべきことをして、あるべき成果を出してその仕事を終える。あっちいったりこっちいったりということはない。いきなり全く次元の違う
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
