タグ

SIerに関するpeketaminのブックマーク (42)

  • だめなITベンダー・SIerの行動特性:ITソリューション塾:オルタナティブ・ブログ

    もし、あなたが、次のようなことをしているのであれば、これは大いに反省すべきだ。 自分たちの「できること」でしか解決策を示そうとしない。 機能や性能については説明できるが経営や事業の成果にどのような貢献ができるのか説明できない。 これからのテクノロジーやその可能性について分かりやすく説明できない。 お客様が新しい方法論や見積を求めても旧来のやり方で提案しようとする。 新しい方法論やテクノロジーの適用を求めると保証できない、実績がない、時期尚早などのネガティブ・ワードで翻意を迫る。 やがて、お客様から愛想を尽かされてしまうだろう。 工数の需要がなくなるわけではない。ただ、作業工数に応じた労働力に対価を支払うというやり方は、自動化ツールやクラウド・サービスとの競合や人口の減少と相まって、そこでの収益の拡大を期待することができなくなる。 また、工数需要そのものの内容が変わる。例えば、「コードを書く

    だめなITベンダー・SIerの行動特性:ITソリューション塾:オルタナティブ・ブログ
  • 拡散された記事についておわび - ここもちろぐ

    こんにちは。もちです。 某案件の記事を投稿したら、だいぶ拡散されてしまいました。 支持だけでなく批判の声も出たため、まずいなと思い記事を削除いたしました。 少しでも案件に関係された方々、大変申し訳ございません。 情報発信には気を付けていたつもりですが、まずい部分もあったかと思い、大変反省しております。 拡散こわすぎです・・・ ブログ初めて1ヵ月もいかないブログに対して、20,000/日を軽く突破するアクセスがあって、最初は何かのバグかなと思いました。 もし、「アクセス数増えて嬉しかったか?」 という問いがあったとしたら、わたしは、こう答えます。 「まったく、嬉しくない!!!」 そもそもブログを始めた理由は何なのか。 少なくとも良し悪し関わらず拡散されたいから始めたわけではありません。 気づいたときには拡散しまくられていて、アクセス数が秒で増える感覚はこわすぎでした。 当にごめんなさい。。

    拡散された記事についておわび - ここもちろぐ
  • 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance

    言いたいことがストレートに伝わる良い文章だと思います。 simplearchitect.hatenablog.com ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。 では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。 確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ? その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの? 僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエア

    事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance
  • de:code 2016 「拝啓『変わらない開発現場』を嘆く皆様へ」を担当して

    実に2年ぶりのエントリになりますが;、今日はこちらの話題を。 少し前の話になりますが、5 月下旬に弊社イベント de:code 2016 で、ちょっと変わったセッション「拝啓『変わらない開発現場』を嘆く皆様へ ~エンプラ系 SI 開発現場の「今」を変えていくために~」を担当させていただきました。内容は、エンプラ系 SIer のプロパー(PL, PjM, SE)の方々向けに、設計やテスト手法の改善テクニックの要点などを通して、開発現場を改善していくための考え方を解説する、というもの。未来をお届けするイベントなのに最新技術を一切説明しないという異色のセッションにもかかわらず、参加者満足度(NSAT)ランキングで全 125 セッション中 2 位という結果になったことに大変感謝する一方で、私自身、いかに日のエンプラ系 SI の闇が深いのか、を改めて実感することになりました。 セッションの内容につ

    de:code 2016 「拝啓『変わらない開発現場』を嘆く皆様へ」を担当して
  • 「情報システム産業では、2000年代後半から協力会社を中心として労働環境の悪化が相次ぎ受託開発ビジネスの限界に直面。丸投げ委託、多重下請けと人月ビジネスの横行等により、業界全体の魅力が低下した」という経済産業省の産業構造審議会の公式見解について

    経済産業省の「産業構造審議会 商務流通情報分科会 情報経済小委員会 IT人材ワーキンググループ(第1回)」の「資料4-1 IT人材を巡る現状について(PDF形式:2,745KB)」から気になった箇所を抜粋し、この問題と関連すると感じた投稿をまとめました。

    「情報システム産業では、2000年代後半から協力会社を中心として労働環境の悪化が相次ぎ受託開発ビジネスの限界に直面。丸投げ委託、多重下請けと人月ビジネスの横行等により、業界全体の魅力が低下した」という経済産業省の産業構造審議会の公式見解について
  • 巨大銀行の巨大システム開発で大変素晴らしい経験を得たという話

    最近まで、ネット上のIT系ニュースで度々システム障害で我々にネタを提供してくれる某巨大都市銀行の次期システム開発に下請けとして新卒から参画していた。「某巨大都市銀行の次期システム」という時点でどこの銀行かピンとくると思う。次期システムとは大雑把にいうと80年代に構築され今なお稼働しているシステムのうち、外為、内為、預金などの業務にて稼働するサービス(実際のプログラムになる)を疎結合化してそれぞれのサービスを部品として再利用性やメンテナンス性の向上を図る、いわゆるSOA(サービス指向アーキテクチャ)で作り直そうというものだ。この辺も心当たりのある銀行と次期システムとかでググれば出てくると思う。銀行システムをSOAで構築するのは日では初めて!!すごい!!先進的!!!という触れ込みだったらしいが、立ち上げからいるわけでもなくSOAの利点も結局実感できぬままこの業界から去ってしまったので当に謎

    peketamin
    peketamin 2015/01/28
    天国は下に地獄が無いと成立しないのか
  • 法外な開発料金の見積もり根拠、「客には絶対に言えません」

    基幹系システムの再構築案件でITベンダーから法外な料金を提示され、激昂しているシステム部長から話を聞いたことがある。「ITベンダーに見積もり根拠を示せと言っても、明確なことは何も言わないのだよ。ぼったくろうとしているとしか思えない」。その人は憤懣やるかたない様子だった。 この話をユーザー企業のIT部門の人とITベンダーの人にすると、両者で反応が全く違うから面白い。IT部門の人は、ほぼ間違いなく「ITベンダーはけしからんですね」といった反応になり、人によっては「ひょっとして、そのベンダーは○○○社じゃないですか」と聞いてきたりする。まるで自分が被ったITベンダーの過去の仕打ちと、この話を重ねているかのようだ。 一方、ITベンダーの人は「なるほど」「そういうことですか」と言ったきり、大概はこの話をスルーする。実はITベンダーにとって、こうした話は日常茶飯事のこと。営業担当者なら自分自身が過去に

    法外な開発料金の見積もり根拠、「客には絶対に言えません」
    peketamin
    peketamin 2014/12/01
    困った客用のお断り価格、または諸々のリスクを見込んだリスクヘッジした上での価格設定のハナシ。または依頼側がすべき心構えの話。
  • 人月アドベントカレンダのご提案

    受託開発やSIer、そこで採られる人月での見積と契約はスタートアップ・Web系・ベンチャーな方々から軽蔑されがちです。 けれど社会のインフラや企業の基幹を担うこともある重要なシステムでは残念ながらこれらの手法をとらざるを得ないのが現状となっています。 これを打破するイノベイティブでエポックメイキングでパラダイムシフトな変革は期待されていますが、文化や慣習、人手不足とレガシーコードはなかなかそれを許してくれません。やり玉にされがちなSIerのスタンスだけに帰せる問題ではないのです。 そんな状況でもわれわれSEは社会の繁栄のために、愛する(現在の/未来の)家族のために、そしてご飯をべていくために働く必要があります。 しかし、この業界で難しいのは流動性が高い割にキャリア形成が難しいこと、自分の精神的・肉体的な健康を損ないやすいという問題があることで、苦労されている方も多いかと思います。 そして

    人月アドベントカレンダのご提案
  • 木村の主張「人月商売や多重下請けは滅びの道」、読者はどう考えるか

    私が書いた前回の「記者の眼」で、人月商売と多重下請け構造に代表される日IT業界の現状と今後について、読者に意見を求めた(関連記事:読者に問う! IT業界の二大悪「人月商売」「多重下請け」の今後)。私自身はIT業界の悪弊とも言える人月商売と多重下請け構造は解体に向かうと考えるが、はたして皆さんはどう思っているのだろうか。 この人月商売と多重下請け構造の問題は、IT関連の仕事に携わる多くの人にとって重大な関心事。そのため、SIerや下請けの受託ソフトウエア開発会社の技術者、経営層、営業担当者、さらにユーザー企業のIT部門の技術者など83人に上る読者から真摯な意見が寄せられた。今回は、そうした意見を紹介しつつ、はたしてIT業界が変わり得るのか否について深掘りしたいと思う。 そもそも読者に意見を求めようと考えた発端は、やはり以前この「記者の眼」で書いた記事だ(関連記事:IT業界の人月商売、多重

    木村の主張「人月商売や多重下請けは滅びの道」、読者はどう考えるか
  • SierからWEB系に転職した人教えて下さい 転職して良かったですか? 特に何が良かったですか?

    SierからWEB系に転職した人教えて下さい 転職して良かったですか? 特に何が良かったですか?

    peketamin
    peketamin 2014/09/01
    Web系からSIerに転職した人の意見に興味が湧いた
  • 年金相談マニュアル(機器操作編) - 日本年金機構

    年金相談マニュアル 機器操作編 目 次 第1章 窓口装置の操作方法 ·······················································1 第2章 システムの概要 ···························································5 1 システムの構成 ·····························································6 2 ファイルの種類と内容 ·······················································8 第3章 被保険者記録に関する照会 ················································13 1 被保険者記録に関する照会の種類 ·······

  • システムインテグレーション崩壊、斎藤昌義著、読了 - 未来のいつか/hyoshiokの日記

    システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?を読んだ。 編集の傳さんから直々の献。ありがとうございます。 先日読んだ、倉貫さんの「納品」をなくせばうまくいくが面白かったという日記 *1 を読んだ傳さんが送ってくれた。 刺激的なタイトルである。副題が「これからのSIerはどう生き残ればいいか?」である。このままでいいのか、いやいいわけはない、という問題意識のである。 わたしは、SIerでもないし、SIerに勤めた経験もないので、あくまで部外者の感想にしかすぎないのだけど、書で述べられていることはいちいちその通り、おっしゃる通りである。 IPAの「IT人材白書2014」からの引用があるが、それが衝撃的で、ユーザー企業が今後新規/拡大をしていく分野(SaaSやPaaSなど)、IDCサービスへのSIerの関心は低く、SIerの今後の新規/拡大を予定している事業に

    システムインテグレーション崩壊、斎藤昌義著、読了 - 未来のいつか/hyoshiokの日記
  • 「ソフトを他人に作らせる日本、自分で作る米国」が指摘する日本のITの課題 - ジャスミンソフト日記

    きたる2014年4月25日に、超高速開発コミュニティ第一回総会が開催されます。 http://www.x-rad.jp/ その記念講演として、日経BPビジョナリー経営研究所の谷島 宣之氏をお迎えしました。近著「ソフトを他人に作らせる日、自分で作る米国」についてお話いただきます。 日経コンピュータや日経ビジネスなどで谷島氏の記事を読まれたというビジネスマンは多いと思います。かくいう私もその一人です。当日は直接、谷島氏のお話を伺える絶好の機会です。講演会は無料ですので、是非ともご参加ください。(なお、続く交流会への参加者へは、書の贈呈もあります。これは超高速開発コミュニティからのプレゼントですので、お得です!) ということで私も当日は交流会参加時点で一冊いただけるわけですが、実は総会に先立って購入しました。事前に読んで講演を拝聴するとさらによくわかるだろう...ということで、読後の感想を綴

    「ソフトを他人に作らせる日本、自分で作る米国」が指摘する日本のITの課題 - ジャスミンソフト日記
  • ベンダーとIT部門がぶち切れた“仕打ち”の理由

    「素晴らしいご提案ですね」と、ある製造業のシステム部長は唸った。その企業はグローバル展開の強化に向けて、SCM(サプライチェーン管理)関連で新たなシステムを導入しようとしていた。この分野でのシステム構築に多くの実績があるSIerに提案を依頼したところ、このSIerはまさに唸るような提案を出してきたのだ・・・。 あらかじめ断っておく、これから始まる“悲劇”は実話ではない。ただし架空の話でもない。複数のITベンダーの営業担当者やユーザー企業のシステム部長らから聞いた話を基に組み立てたストーリーである。だが、ここまで劇的な展開ではないとしても、特に大企業がやってしまう“人でなしの所業”とその結果生じるトラブルには思い当たる読者も多いはずだ。 さて、この製造業のシステム部長がSIerの提案を評価したのは、単にその内容が素晴らしいからだけではなかった。彼らが2カ月かけて経営層や事業部門に対して行った

    ベンダーとIT部門がぶち切れた“仕打ち”の理由
  • 4月からSIerで社会に飛び込むあなたに - novtan別館

    新人社員のみなさま、まずは無事社会人になられたことをお祝い申し上げます。そして、このタイミングで、ともすれば斜陽産業とも言われるSIerに入るということで期待と不安がないまぜになっているのではないかと思います。 SIerというのはエンジニアの自覚を持たずしても生き抜くことが出来てしまう可能性の高い職種です。しかし、10年前ならいざしらず、今この激動の時代において、エンジニアにならずして生き抜くことが可能かどうかはもはや疑問です。 そこで、みなさんにはSIerにいながらにしてエンジニアとして成長するためにいくつかの心構えを与えましょう。 技術力はまず目の前のパソコンから PCを使い慣れた人にとってはSIerに入って気づくことが一つあります。先輩たちは驚くほどPCのことを知りません。PCに詳しくても業務システムを作れないからです。でも、それって当にいいんでしょうか。目の前のPCがどう動くかも

    4月からSIerで社会に飛び込むあなたに - novtan別館
  • みずほ銀、巨大システム刷新 苦い教訓生かせるか - 日本経済新聞

    みずほ銀行が基幹システムの統合にいよいよ乗り出す。世界のIT(情報技術)業界でも類をみない巨大プロジェクトとなる。当初は16年春の切り替え開始を目指していたが、仕様検討や設計に遅延が発生。2月に1年の延期を決めた。延期の代償は大きかった。総投資額は3千数百億円に達し、開発規模は三菱東京UFJ銀行のシステム統合の1.8倍に膨らむ。「今は基設計がほぼ終わり、詳細設計に入りつつある」(みずほフィナ

    みずほ銀、巨大システム刷新 苦い教訓生かせるか - 日本経済新聞
  • SI業界がIT化してないとか酷いことを言ってしまった – 上田ブログ

    続編はこちら 日は久々に心に余裕を持った状態で休日を過ごすことができました。心が緩んだのかこんなdisりツイートをしてしまったところ、私のようにシュールなことしかつぶやかない人間には大変珍しいことですが、リツイートの数が10を超えました。誰からも恨まれないようにコソコソと生きようとしているのに、これはいけません。責任をとって弁明いたします。 ITの進んでない分野 = SI業界 — Ryuichi UEDA (@ryuichiueda) 2014, 3月 8 言い訳 たぶん、個別の事象を並べてもそれは個別の事象なので、単に愚痴にしかなりませんし、私もそんなに長くあの世界にいたわけではありません。理由を説明するなら、ちゃんと構造から切り込んでいかないといけません。 構造的な話をすると、月並みなんですけど、やっぱり人月でお金をもらって業者が仕事をしているからで、そんなところに効率化の波が押し寄

  • 神秘かつ壮大な銀行システム建造物、みずほ銀行の「桜田ファミリア」 : 市況かぶ全力2階建

    決算発表が出ないことを怪しんでストップ高まで買われたエックスネット、TOBされるどころか逆に資提携解消で切られて過剰にお金が流出するお笑い劇場に

    神秘かつ壮大な銀行システム建造物、みずほ銀行の「桜田ファミリア」 : 市況かぶ全力2階建
  • ユーザー企業が開発するということ - 未来のいつか/hyoshiokの日記

    ウェブ系のサービスを提供しているところは常識なんだけど、世間ではあまり知られていないことは、サービスは基的には自社で作るということだ。 日において、ITシステムはユーザー企業が作るのではなく、それを専業にしているベンダーが作る事が多い。SI (System Integrater)と呼ばれる企業だ。ハードウェアベンダーのSI部隊であったり、独立系と呼ばれるベンダーだったりする。統計では受注ソフトウェアの売上になる。 *1 わたしはSI企業にいた経験がないので、当の実態を知る立場にはないけど、想像するに、大手ベンダーが受注したシステム開発の案件を、誰かが要求定義して、それを文書にして、その文書をもとに誰かが設計して、その設計書をもとに、誰かが実装をする。テスト仕様書を誰かが作って、誰かがテストをする。発注側とシステムを受注する企業が別の場合は、何をいくらでいつまでに作るかというのを契約で

    ユーザー企業が開発するということ - 未来のいつか/hyoshiokの日記
    peketamin
    peketamin 2014/02/22
    「一度自社でやってみようとしたんですがうまくいかなくてー…」っていうお客さんは一緒にやりやすかったような記憶があるような。まずはトライしてもらうよう仕向けていきたいです。
  • 想像以上にガラパゴス化した日本のIT業界? - 達人プログラマーを目指して

    出版されている技術書のタイトルやネット上での情報を元に、なんとなくシステム開発で使われる技術が国によって差があるように感じるということを、これまでいろいろな記事で書いてきたのですが、はたして実際のところはどうなのでしょうか?300年前なら、Manningのin actionシリーズの表紙に描かれている人物*1のように国ごとにいろいろな衣装があって多様な文化が存在していたのでしょうけれど、文明化された現代では、服装もべ物もそれほど違いがないというところがあります。IT業界は文字通り情報を扱う産業なのですから、世界中の最新の情報が集まってきてしかるべきなわけであり、どの国でも大差がないはずという推測もできないわけではありません。 あくまでも目安なのですが、Google Insights for Searchというサービスを利用すると、単語の検索回数を地域ごとに集計することで、各地域でどういっ

    想像以上にガラパゴス化した日本のIT業界? - 達人プログラマーを目指して