クラウドはSIerのビジネスにどんな影響を与え、SIerはどうするべきなのか？ 情報サービス産業協会がレポートを公開
国内の主要なシステムインテグレータやソフトウェア開発企業で構成する一般社団法人 情報サービス産業協会は、クラウドがシステム開発などの情報サービス事業に与える影響や課題を整理したレポート「クラウドコンピューティングが情報サービス事業者に与える影響とビジネス拡大に向けての提言」（PDF）を、公開しました。 本レポートは、システムインテグレータやソフトウェア開発企業の立場からクラウドによるビジネスの影響を分析し、それに対応したビジネスモデルを提案している点が特徴です。 クラウドの登場などによる「所有から利用へ」の流れは、サーバなどハードウェアの販売や開発案件の減少など、システムインテグレータが依拠してきたビジネスモデルをおびやかそうとしています。その現状分析と今後の対応策をシステムインテグレータ自身がどう考えているのか、このレポートから垣間見ることができます。 新たな4つのビジネスモデルを提言
SIerについて気になったので調べた - Sean_SF’s blog
先日、「SIerという謎の業種」についてブログを書いたが、その後も気になっていた。グローバル企業で働いているので、この、おそらく日本特有の業種がどうして存在するのか、などを知りたかった。同僚に説明するときに必要だ。というわけで、海外との違いという観点を中心に今日は少しググったりしてみた。 ちなみに私が販売しているソフトが海外と同様に、日本でもメジャーになるかどうかの一つのポイントは、この謎の業種にいかに浸透させられるかどうかにかかっているのではないかと思っている（まだ仮説だけど）。 ウィキペディアの「システムインテグレーター」 しかしシステムインテグレーターの隆盛は、日本特有の現象である。実は米国のユーザー企業は独自のシステムを開発する場合は、システムを内製する傾向が強い。情報システム部門がエンジニアを抱えて、社内でシステム開発から運用までを行なう、インハウス開発である。 なお「エスアイア
なぜ依然としてウォーターフォールが残っているのか？ - レベルエンター山本大のブログ
マネージメントに携わるようになってウォーターフォールにも理があると思うことが多い。（もちろん最適解ではないが。） ウォーターフォール・反復に次ぐ、実践的な開発プロセスを検討したいとずっと思ってる。そんな検討をしていこうと思う。 ということで、語りつくされてはいるが「アジャイルかウォーターフォールか？」から考える。 アジャイルかウォーターフォールか？ アジャイルプロセスが提唱されてから既に数年、業界の多くの著名人がアジャイルを推奨し、多くの書籍が揃う。 アジャイルの考え方は、ウォーターフォールプロセスによる開発で「仕様変更」と「コストオーバー」、「スケジュールオーバー」に苦しめられてきた開発者達の、怨念にも似た声から生み出されたものだ。 エンジニアの視点から考えると理想的な開発の進め方のように思う。 しかしながら、やはり実際の開発現場は依然として、ウォーターフォール式の開発プロセスを採用する
システム開発で再利用可能な最大のコンポーネントは開発チームだ。 - レベルエンター山本大のブログ
開発プロジェクトは知識産業です。 プログラムは知識労働の成果ですが、 知識労働の一番大事なエッセンスは、 それを生み出す「過程」にあると思います。 つまり知識労働で別のプロジェクトでも再利用可能なのは 知識とその所有者だと思います。 その考え方を発展させて「再利用可能な最大のコンポーネントは開発チームだ」と言いたいです。 そう言うわけで、以下のひがさんの意見に賛成。 ■ひがやすを blog 〜 SIerが自動車産業をまねしようとするのはいい加減やめなさい 自動車だと、同じマフラーを作り続けることができるけど、システム開発の場合は、同じマフラーを作ることは意味がない。同じプログラムを作り続ける意味がないからね。 （中略） これからのSIerは、分業などせずに全部自前で構築できるようになれることが、重要だと思う。 http://d.hatena.ne.jp/higayasuo/20080305
このままだとSIerの給与水準は下がっていく - ひがやすを技術ブログ
今後のビジネスの方向性として、たいていのSIerは、上流を強化するだとか、上流にシフトするだとか、上流に専念するなんて答える。 下流には、付加価値がつけられないから、自分たちの付加価値をつけるためには、上流を強化するしかないと思っているSIerの人も多い。 でも、みんなが同じ方向を向いたら、最後は価格競争になる。 日本の市場が厳しくなっているので、ブランド力よりも価格が重要視される割合が増えてきているのです。 ブランド力が通用しない市場は、自然と価格競争になるわけですが、今のSIerは、どこも同じような重量級の開発プロセスだから、開発プロセスでは差がつかない。後は、下請けの単価を下げるか、自分たちの給料を下げるかになってしまいます。 つまり、SIerの給与水準は、今後少しずつ下がっていく。負けているわけじゃないけど、ジリ貧みたいな。 ひがやすを氏の会社がプログラミング・ファースト開発を標榜
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
