アジャイルで不幸にした業界、法令工学を応用することで、幸せになれれば。。。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） いいけどね！ せっかくコメント無視、匿名で書いているんだから、 もっと、世間から、反発されるけど、大事なことを、たまには、書いてみたいと思う。 最近、IT業界って、暗いとおもいませんか？ 村上企画官のおことばを待つこともなく、７Kとか１０Kとか、まったくもって、暗い、イメージの悪い業界になってしまったと思います。 こうなった原因の多くは、アジャイルという名のもとに行われる、仕様の五月雨式変更にあるとおもいます。 ウォーターフォールだった、８０年代後半、９０年代前半は、後工程で仕様変更が原則できないため、どの仕様変更を（例外的に）あえてするか、それをした場合にどれほどのインパクトがあるかを計算してから、行われました。つまり、要求仕様が管理されていました。 さらに、テストに関しても、
システムはソースをみれば解かる?
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45664 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
「サービスにはサービス、モノ作りにはモノ作り」でSaaSを考える
SaaSが普及するかどうかという、くだらない議論する人がまだいる。そんなの普及するに決まっているじゃないの。そんなことを言うと、「では、どんな分野で？」と質問される。それも簡単。ものすごくアバウトに言えば「サービス業にはサービス（SaaS）、モノ作りにはモノ作り（ソフト開発）」である。 ここで言うサービス業は、小売なども含めた広い意味でのサービス業で、通信など装置産業は除いたぐらいの意味でとらえてほしい。さて、それを踏まえてサービス業を見渡すと、実はSaaSって既に随分普及しているんだよね。何かというと、既存のASPサービス。POSシステムなんかもASPの形態で提供するのが、既に当たり前になりつつある。 そう言えば、SaaSとASPとは何が違うのかという、これまたくだらない議論があったが、今はさすがにそんなことを言う人も少なくなった。SaaSとASPは機能上の差異ではなく、マーケティング上
雑種路線でいこう - どっこいSIerは簡単になくならない
SIerが変わらなきゃってことには同意。けど日本でSIerは当分なくならない。少なくとも解雇規制がなくならないとね。米国で何故ユーザー企業が専門家を雇えるかというと、要らなくなったらクビにできるからだ。例えば汎用機とCobolのシステムをLinuxとJavaに移行する場合は、汎用機オペレータとCobolプログラマを切って、LinuxオペレータｔJavaプログラマを雇い入れる。そういう世界だ。 日本じゃ簡単にクビを切れないから、潰しのきかない技術者はできるだけ雇いたくない。そこのところはSIerに押しつける訳だ。重層的な下請け構造が何故あるかというと、SIerも簡単にはクビを切れないんでバッファを必要とするからで、6次とか7次になれば会社そのものが吹けば飛ぶ世界で、労働基準法なんか形骸化しているしね。 今後はユーザー企業がどんどん内製で出来るようなシステム作りを支援する方向に向かわねばならな
東葛人的視点 「ソフト販売型の事業モデルが終焉、営業はクビ」という怖い話
« 【Watcher】SE不足の折 | メイン | 【Watcher】システム部門 » 「ソフト販売型の事業モデルが終焉、営業はクビ」という怖い話 ［2006年11月08日］ 日経ソリューションビジネス10月30日号で、NRIの人が興味深い記事を寄稿していた（「米国でソフト販売モデルが終焉？」）。米国では、企業向け業務ソフトを開発するベンチャー企業に停滞感が漂い、“Is Enterprise Software Dead ?”なんて囁かれているそうである。 その記事によると、米国の業務ソフト市場でオラクルやSAP、マイクロソフトなどの寡占が進んだ結果、基幹系の業務ソフトを開発するベンチャー企業の出番がなくなり、巨大企業に買収されることぐらいしか、これらのベンチャー企業にはエグジットがない。しかも、少なくともベンチャー企業においては、もはや従来のソフト販売型の事業モデルは成り立たないという。
ウォーターフォール型開発が失敗する理由 - 酔狂人の異説(新館)
ウォーターフォール型開発が失敗する最大の理由は、コミニュケーションの難しさにある。 開発が成功するには意図を正しく伝える必要があるが、意図が正しく伝わっているか確認するには出来上がったもので確認するしかない。仕様書に意図が正しく反映されている保証はない。「プログラムは、意図した通りに動くのではなく、書いた通りに動く」というように書いた内容と意図した内容とを厳密に一致させることは極めて困難である。書いた内容と意図した内容とが仮に一致したとしても、その仕様書を正しく読み取ることもまた同じくらい困難である。 「ウォーターフォール」という言葉自体が、コミニュケーションの難しさをあらわしている。下記のページに書かれているように、ウォーターフォール型開発のもととなったのは Winston W. Royce の "Managing the Development of Large Software Sy
ITサービス業の産業構造は近い将来、間違いなく崩壊する
ITサービス会社は今、技術者不足に悩んでいる。業界自体が若者に不人気で、プログラマ、SEを志す人も減りつつあるという。それはそれで大きな問題なのだが、あくまでも現象論。少し考えてみてほしい。このままでは、ITサービス業の産業構造、ビジネスモデルは人材面の問題から間違いなく崩壊する。これは論理的必然である。 多くの人がもう忘れ始めているが、ほんの2～3年前にはITサービス業界では技術者が余っていた。優秀な技術者はその頃でも足らなかったという議論があるが、総体としてはやはり過剰だった。多くのITサービス会社が危ない案件の安値受注に走ったのも、技術者の稼働率を維持するためだった。下請け会社が容赦ない料金引き下げ要求にさらされたのも、その頃だ。 もともとITサービス業界はその黎明期から、慢性的な技術者不足が続いていた。ITサービス市場は景気変動の影響をほとんど受けず、基本的には右上がり。人さえ手当
過剰品質の美学 : 小野和俊のブログ
レクサスは半ドアでも走行中に自動でドアがスーっと閉まる。 スーパーで売られている卵は保存が良いように尖った方が下に揃えられているし、パックの中身を確認しなくても、卵が抜けたり割れたりしていることはほとんどない。伊勢丹では販売員は売場をお買場と呼び、コンビニでは弁当の胡麻の数までチェックの対象になる。箱ティッシュには指を入れやすいように小さなミシン目がついており、トイレに行けばウォシュレットがある。 求められている品質を満たすのではなく、 求められていない品質を目指す。 それが過剰品質の美学である。 そしてそれがITの遅れの象徴であるかのように指摘する人もいる。 しかし一方で、 自分たちはオーダーメイドという最高の過剰品質を提供しているのだと誇る声も聞こえてくる。 私はパッケージ製品を開発している立場の人間であり、 オーダーメイドのための最高の部品を提供することが私の目指すところだ。 知人で
儲からないSIから“逃走”する企業とSIで儲ける企業のコントラスト
SIは儲からない。だから、ビジネスの軸をパッケージソフト販売や運用サービスに変える必要がある----これは、ITサービス会社のビジネスモデル変革の公式と言ってよいだろう。富士通の黒川社長も経営戦略説明会などの場で、よくそんな説明をしているらしい。そのココロは「できるだけ作らない」である。だが、トラディショナルな受託ソフト開発会社で高い利益率を上げる企業もある。さて、その辺りのことを、どう考えるべきか。 ITサービスのビジネスのプロセス順に、パッケージ販売、SI、運用サービスを横に並べ、縦軸に利益率をとると“ITサービスのスマイルカーブ”が描ける。なんのことかと言うと、両端のパッケージ販売と運用サービスは利益率が高く、真ん中のSIは利益率が低いので、曲線で結べば、スマイルマークの口元のラインのようになる。 富士通なんかは、ITサービス事業の収益力向上策の説明でこの図を使う。儲からないSIの比
ソリューション提案なんか要らない！ CIOは何故かく語るのか
「IT業界に我々の問題の解決を期待すること、つまりソリューションを求めること自体に無理があった」----。ユーザー企業にこう言い切られてしまっては、“ソリューションプロバイダ”を旗印に掲げるITサービス会社としては切ない。これは、ある大手流通企業のCIOの発言だが、大手企業、いわゆるIT先進企業のIT担当者からは、よくこんな話が出てくる。いい機会だから、手垢が付いた「ソリューション」の意味を考え直してみたい。 日経ソリューションビジネス6月15日号の特集『CIOの直言』には、冒頭のCIOの発言も含め、「問題解決は自分たちの仕事、ソリューション提案なんか要らない」という、ユーザー企業の声で満ちている。ある意味、それは結構なことだ。自社のIT化を担うことに対する強い自負心を感じる。しかし、こうした発言には多少の違和感もある。多くのユーザー企業がITサービス会社に対して、「ソリューションを提案し
“未来の経営者”にも会うコンサル、案件終了が縁の切れ目のSIer
この前、年配のシステムコンサルタントの人たちと話して、顧客とのリレーションの深さについて思い知らされた。この人たちは、顧客の経営トップとのリレーションが10年、20年と切れずに続く。中堅企業のオーナー経営者だけでなく、4～6年で入れ替わる大企業のサラリーマン経営者を相手にしても同じ。経営トップが代替わりしても、次の経営トップどころか、数代先の未来の経営者とも信頼関係ができている。こりゃ強いな、と改めて感心してしまった。 システム・インテグレータにとって、コンサルティング機能の強化は永遠の課題だ。顧客の経営トップやCIOにインタビューし、聞き出した経営課題をシステム案件にまで落としていくシステムコンサルタントがいれば、SI案件を獲得する上で極めて有利な立場に立つことができる。他社よりも早く大型案件を発掘できるし、事実上、無競争でその案件を獲得できる。逆に、顧客の現場の体制が整いそうもないなど
オープンソースと「オープンデザイン」が出会うとき - 設計者の発言
◆オープンソースの台頭 無償で手に入る業務システム向けの開発・実行環境やフレームワークが急速に充実してきた。Apatche,Eclipse,Seasar2,MySQL,Ruby on Rails等々、枚挙にいとまがない。それらの多くが活発なＯＳＳ(open source software)コミュニティを伴っていて、優れたソフトウエアを開発して社会に貢献したいと願う技術者達の情熱の受け皿となっている。その創造的な流れが止むことはないだろう。 そのような変化を、ソフトウエア業界を牛耳ってきた大規模ＳＩｅｒも無視できなくなっている。初めの頃には品質がアテにならないとかドキュメントが貧弱などと言って相手にしていなかったのだが、いつの間にか実務で使えるレベルまで成熟していることに気づきはじめている。クレイトン・クリステンセンが「イノベーションのジレンマ」で示したさまざまな業界での事例と似たことが、ソ
頭数論 (arclamp.jp アークランプ)
なんか盛り上がっているので参加してみます。火元はこちら。 頭数論はSI業界の確かな事実 別に藤田氏の言い方に違和感は覚えません。SI業界では確かな事実です。 SI企業の事業計画を考えてみると良く分かります。SI企業に対するM&Aをされている方から聞いたのですが、買収先の企業に事業計画書を作らせると、目標売上の数字に対して人月単価で割り算した人数が記載されているそうです。その売上の実現性は営業による案件の獲得でもありますが、重要なのは人材採用計画に他なりません。 つまりSI企業の事業計画とは人材採用計画のことであり、売上は人数に比例して増えるのです。 Web2.0企業では頭数に意味はない で、藤田氏の発言に対して「理解が足らん」というメッセージが多く見受けられます。それは、もちろん正しい。 実はWeb2.0的なサービス企業は「理解が足らん」という話だけで頭数論を回避できてしまうのです。
SIer2.0 @ET研 (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 渡辺聡さん主催のEmerging Technology研究会に参加してきました。4月開催のお題は「SIer2.0」です（渡辺さんのレポートはこちら）。 報酬構造の問題 いろいろな議論があったのですが落ちていく先は同じで成果報酬の話でしょうか。特にモノに落ちない成果、いわゆるコンサルや調整などです。 結局、プロジェクトがうまくいくかどうかは「どんなシステムをどう作るのか」という事が現実的であるかに掛かっています。上流で言えばステークホルダー間を調整したり、問題点を明確にしたり。開発現場であれば、良い方式設計を行い良いリソースを集める。 しかし、こうしたシステム作りの環境を整えるという作業に対価が支払われません。上流であればプリ・セールスという言葉で片付けられ、現場では
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
void GraphicWizardsLair( void ); //