SIerの問題点 - zyake_mk2の日記
世間一般では、SIerは非効率、プログラマのスキルが酷い、ガラパゴス化している等、評判が悪く袋叩きにあっているようです。実際にはグローバル水準で戦える高スキル者はいるし、特に某親会社の人達はみな頭の回転が速いし、志が高いです。 一方で私の5年そこそこの短い経験の中でも、世間の評判通り、開発現場の信じられないような体たらくっぷりをたくさん見てきました。すごく立派な看板の裏でのしょぼい設計実装、ミス等 etc... (私も人のことを言えないですが・・・) そこで、私の見える範囲の世界で、どうしてこのような現状なのか考えてみました。 (私の見える範囲なので、他社だと全く状況は違うだろうし、他者には違った世界が見えているかもしれません。) SIerの問題点1. 技術力向上のインセンティブが少ない 恐らく最大の原因はこれではないかと思います。要するに、必死に技術力を磨くインセンティブが乏しいのです。
プログラマ業界の二分化 - きしだのHatena
プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく２つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その２つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で
2014年のSIビジネスとかそのあたり - 急がば回れ、選ぶなら近道
というわけで2014年に突入ですが・・・ 景気が回復しつつある現状で、SIの受注も好調なようです。ユーザー企業でも多少の予算の余裕も出てくるところもあり、システム投資には多少前向きになっているところも感じます。多少のでこぼこや、業界・業種によって色合いは異なるでしょうが、今後数年は景気の回復基調はコンセンサスになりつつあるようです。IT業界も例外ではないでしょう。もたもたしているビッグデータ案件を尻目に、システムリプレースや既存改修、新規でのシステム開発もスタートしつつあり、SI業界の件数ベースは今年は昨年を確実に上回るでしょう。 とはいえ一方で不採算案件も相当増えるように見えます。結果、SIビジネスはトレンド的には案件増・売上増ですが、利益減（または横ばい）というのが実態になるかと。要するに単金はそうそう簡単にはあがりませんが、案件は増えて、人繰りが追いつかず、結果限りなく失敗に近い「よ
「SIをダメにする負のスパイラル」
きしだൠ(K1S) @kis SIの、元請はユーザー企業の業務をよりよくするために、プロダクトを作るんじゃなくて契約書をつくる。で、元請はそれを下請けにつくらせるんだけど、そのときはユーザー企業の業務をよりよくするためではなく契約を満たすためにプロダクトを作らせる。これが負のスパイラルの発端。 2013-11-15 08:17:14 きしだൠ(K1S) @kis 契約を満たすことが目的でプロダクトを作ってるから、実装段階で気づいたアイデアや欠陥は報告されない。納期や金額なんかの契約は満たさないといけないのに追加仕様や変更が発生してやぶへびだもん。品質は悪くなる。 2013-11-15 08:23:58 きしだൠ(K1S) @kis 品質が悪くなってとられる対策は、技術向上ではなく契約の厳密化。設計書を「きっちり」つくるとか、テストのエビデンス(画面キャプチャのかっこいい言い方)をとるとか、
システムの「価値」をどう考えるのか？〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価
なんでもかんでもクラウドにあげるのか？ - 急がば回れ、選ぶなら近道
某エントリーの話で、「なんでもかんでもクラウド化なのか？」というお話もご意見も多数頂戴いたしまして。一応念押しですが、そういうつもりはまったくないですよ。以下、個人的な補足メモです。会社の意見ではありません。一応、会社の公式声明は「できるものは、とっとクラウド化したほうがいいですよ。」です。 クラウド化の是非については、いろいろあるでしょう。ユーザーの所属する産業毎にシステムのあり方・考え方は違うでしょうし、当然クラウド化すべきだという意見や、いやそもそも無理があるという意見もあると思います。ただ、今までのように先例がないから無理、という理屈は通用しなくなっているのが現状でしょう。その意味では無茶な理屈ではなく、普通に選択肢としてクラウド化が候補になっている、と思います。その上で、クラウド化しない、するという議論が普通にできる状態になりつつあると思います。 そんな中でいろいろ思うところをち
「オンプレミス・システムの終わり」の始まり〜AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道
個人的には割と大変だったので、その辺をまとめておきます。 ニュースリリースはこちら。 http://www.nautilus-technologies.com/topics/20130409.html 要するに本部系バックエンド基幹システムの「一式」のクラウド移行です。完全なミッションクリティカルシステムで、止まった段階で業務に確実に影響が出ます。 システムの機能概要 1.売上の確定処理と債権管理 POSデータの直結です。売上確定処理を行います。同時に債権管理も行い、F/Bからの入金データをそのままつなぎ込み、入金処理・債権の消し込み処理を実行します。マッチングは自動処理できるものは処理を行い、ヒューリスティックなものはユーザー判断に従います。 2.仕入・費用の計上と確定処理、および支払いデータの作成 費用・在庫の計上確定処理です。当時に支払データの確定処理を行います。EDI（BMS）との
クラウド上にEDIを「移行する」ということの意味 - 急がば回れ、選ぶなら近道
ニュースリリースというか記事はこちら。日経の中田さんの記事ですね。 http://itpro.nikkeibp.co.jp/article/NEWS/20130306/461423/ この辺の解説を記録のために書いておきます。個人的にはちょっとしたマイルストーンなので。 まずEDIの定義ですが、これはElectronic Data Interchangeの略で、B2Bでの電子データ交換の仕組み自体をさします。歴史的にはITの歴史と同じくらい古い。当然インターネットよりも古い。昔は（場所によっては今も）電話で”ぴー”とか”がー”とかやっていた代物です。多分50年以上の来歴を誇る仕組みですね。業界ごとにその業界に応じたプロトコルが制定されており、いわゆる標準化がもっとも進んだ分野のひとつです。そして、大抵はミッションクリティカルな業務に属します。エンタープライズ系のITでは最下層に位置するレイ
内製化を巡る議論で〜内製化リスク再考。ノイラートの船にどう乗るのか？ - 急がば回れ、選ぶなら近道
諸般の事情で、内製化について各企業さんやお客さんに聞いて回る事が多くなりました。そのあたりで、2013年現在の企業の内製化についての志向や、現状・思うところを記録として残しておきます。 ・前提いわゆるエンタープライズ系を対象にしています。いわゆるWeb系は対象ではないです。安定性よりもスピードに対する要求が強いWeb系では内製化が出来ていない段階で、既にスタートアップのスピードで競合に対してビハインドになります。内製化は必須でしょうし、実際そうなっています。とはいえ、それはフロントのみで、バックエンドは結局従来のSI屋さんに丸投げ状態のところもありますので、そう一概に分類もできないのが現状ではありますが・・とりあえずいわゆるエンタープライズとWeb系は明らかに状況が違うので議論としては分けておきます。 ・内製化に対するスタンス正直、ちょっとビックリするぐらい内製化に対するスタンスはポジティ
やっぱりSIerは終わってる - カレーなる辛口Javaな加齢日記
「SIer / SEは終わってない」http://samuraism.jp/diary/2013/01/07/1357530960000.html うーん，これはヒドイ，と思う． 近年「SIer」、そしてSIerの労働力の多くの割合を占める「SE」が「オワッテル」というような話を良く聞きます。 特に聞くのが「海外では」「欧米では」「アメリカでは」「USでは」といった枕詞を付けて構造・仕組みがおかしいという論調[*1]。 「日本では」、「海外と」「欧米と」「アメリカと」「USと」仕組みが違うので単純な比較は意味がありません。 単純比較に意味は無い．同意． しかし，日本以外にSIerがないのであれば「SIerは必ずしも必要な存在ではない」ということまでは言えるだろう．*1 SIerの仕事のやりかたがおかしいということであれば市場原理が働いて[*2]オカシイ企業は淘汰されていくので心配ありません
内製について考える － 本業とは？ コア業務とは？ - andalusiaの日記
システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道 今の日本の経営陣の基本的なスタンスは一般化すれば、「ITは経営の背骨である。ITがしっかりしていない企業は早晩衰退する」という考えと「うちの本業はITではない」という考え方のふたつに収斂されるでしょう。 多分、そういう答えが返ってくると思います。そして、後者と答えた経営陣に、なぜそう思うのかと尋ねると、「コアコンピタンスに経営資源を集中して資本効率を高めることがグローバル化した市場からの要請で・・・」などという答えが返ってくると思います。 では、市場主義の本家本元の米国ではどうなのでしょうか？ よく言われているとおり、米国では情報システムについては内製が主です。ところが逆に、例えば製造業でのアウトソーシング、EMS*1やODM*2の活用が進んでいるのは、むしろ米国です。実は、米国では必ずしも「本業に経営資源を集中」はしていない
情報システム部はどうであると得するのか？ - 急がば回れ、選ぶなら近道
いまさらの感もあるのですが、特にいろいろと日本全国を飛び回るようになって、いろいろなお客さんにお世話になっています。ということで、その辺りで感じたことで、特にエンドユーザーの情報システム部はどうあると、「有利」なのか、ということを書いてみます。 対象は、お金を湯水のように使えないエンドユーザーさんです。とにかくリスクヘッジのためなら何百億円使おうと問題ではない、というユーザーさんはフルリスクを取れという要求以外であれば、SI屋さんの方から「無理なので、ご遠慮します」ということはありません。そのようなユーザーさんは、例外だとは思いますので、ちょっと対象外です。（なんか最近そうでもない説はありますが） 以下、あくまで自分の経験なので、不快な気分の方は、完全スルーでご容赦をお願いします。ベンダー風情が生意気な事を書きやがって、という方もいらっしゃると思いますので、そういう方には事前に、謝罪してお
みずほ銀行のマルチベンダー化について解説する - novtan別館
はてブではすでにボロクソ言われてますね。フラグ立ちまくりと。ちょっとこれは解説せねばなるまいか… 以下はすべてとある人からの伝聞です。伝聞なんだってば。 みずほ銀行が次期システムの開発をマルチベンダー体制で進めることが日経コンピュータの取材で判明した。富士通、日立製作所、日本IBM、NTTデータの4社に分割発注する。 ［スクープ］みずほの次期システムはマルチベンダー、4社に分割発注 | 日経 xTECH（クロステック） 周知の話だけすると、現行システムにおいては 勘定系（ホスト）…富士通 営業店端末システム…富士通 インターネットチャネル（ダイレクトバンキング）…IBM 情報系システム…IBM 周辺系（中継系）…IBM 外部接続系…日立 コーポレート銀行勘定系…日立 等々、すでにここに出てきているベンダーがマルチベンダーの状態で仕事をしている。また、ここ重要なところだと思うけれども、ベンダ
設計と実装の狭間で - 急がば回れ、選ぶなら近道
・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて（懐古趣味の老人を除いた）皆さんが毛嫌いするCOBOL＋汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず
業務系SEの末路的なお話でして
Statistics Favorites 4 Downloads 0 Comments 0 Embed Views 0 Views on SlideShare 0 Total Views 0 業務系SEの末路的なお話でして — Presentation Transcript 業務系SEの今後について 消費税増税と年金問題が与える影響 2012// 株式会社ノーチラス・テクノロジーズ http://www.nautilus-technologies.com/ mailto:contact@nautilus-technologies.com Tel: 03-6712-0636 Fax: 03-6712-0664 Copyright © 2011-2012 Nautilus Technologies, Inc. All rights reserved.NAUTILUS Proprietary &
業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道
某DevLoveというところで話をしろ、ということでありましたので、いろいろ話をして来ました。 http://devlove.doorkeeper.jp/events/1733 まとめはこちら http://togetter.com/li/387189 あと、しんやさんの詳細なブログがこちら http://d.hatena.ne.jp/absj31/20121009/1349795347 スライドはこちら http://www.slideshare.net/okachimachi/devlove1 以下、ちょっと自分なりにまとめを。 ■自分なりにどう話したか 自分の仕事的にはHadoopとAsakusaでの課題解決が現在の本業です。ただ、Asakusaの位置づけとして、SIのための道具立てという側面が強く、また結果として会社も直接・間接にSIにはかかわっているので、割と現状の問題も意識して
SIerが技術力を求めているという誤解 - SCHWARZGEIST
ＳＩ屋とかゲーム業界について考えてみた。 実はＳＩ産業のクラウド化と、ゲーム業界のソーシャルゲーム化は システムがネットの向こう側から提供されるという共通点以上に、共通点があると考えるからだ。 そしてその動きは、任天堂の「連結決算を開示して以来始めての赤字」や、 「DeNAによるベイスターズ買収」に見られるように、急激な業界構造の変容を生み出している。 キーワードは技術力ＶＳマネジメントだ。 まずはＳＩ業界の話から始めよう。 案件プライムを取ってこれるような大手システムインテグレータでの システムエンジニアの最終的なキャリアパスは、ＰＭである。 システムインテグレータは若手を、ＰＭにいたるまでのキャリアパスへと 導くための初歩的なプログラミング経験や、運用技術の実務経験を積ませていく。 その成長過程で重視され、身につけることを求められているのは、技術力よりもマネジメント能力と業務知識だ。
実録！SIerがネットゲーム事業に参入できない理由
SIerにおける某ネットゲームシステム（以下「NGS」）開発プロジェクトの発言録です。内容はもちろんフィクションですが、SI業界の実情を踏まえて構成してみました。SIerが内部に抱えるネットゲーム事業への参入障壁、さらにはSIerの将来の姿が垣間見えるかも知れません。 プロジェクト計画レビュー部長「NGSは、今年度の重点目標『高利益率ビジネスへの参入』を達成するために立ち上げる非常に重要なプロジェクトです。本部長から直々のご指示を頂き、開発チームのメンバーを集めました。」 PMO事務局「PMOとしてもプロジェクトの成功に向けて最大限貢献したいと考えています。」 部長「それは心強い。ありがとうございます。」 課長「それでは、早速ですが、NGS開発プロジェクトのプロジェクト計画レビューをお願いします。」 PMO事務局「プロジェクトのマスタスケジュールに計画が不明確な箇所が散見されます。βテスト
SIで得るものはあるのか？ - 急がば回れ、選ぶなら近道
「SIで得るものはあるのか？」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか？赤字の度に、そこまでやる意味はあったのか？ 思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。（遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ？」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ
もしSIerのマネージャがFizzBuzz問題を解いたら - GeekFactory
SIerのピーエム*1と呼ばれる人たちはパワーポイントを武器に日々闘っている。 そんなパワーポインターがFizzBuzz問題を解いたらどうなるだろうか？ 作ってみた。 作成手順書 PowerPointを起動する。 スライドマスタを表示し、ページ番号を大きなフォントにして中央に配置する。 空白のページを15ページほど用意する。 3、6、9、12、15ページ目に、Fizzと書いたテキストボックスを配置する。 5、10、15ページ目に、Buzzと書いたテキストボックスを配置する。 1〜15ページをコピーして必要な分だけ貼り付ける。 レビュー指摘管理簿 レビュー出席者：部長、課長、次長、ヒラ（記） レビュー時間：120分 ページ数：60ページ 社内標準のスタイルを使っていない。 会社のコピーライトがない。 プロジェクト関係者の秘密資料であることの表示が入っていない。 フォントがMSゴシックでない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
