元請から下請に変わって、仕事で理不尽な目に遭うことがなくなった話 - 極北データモデリング
人材募集広告の取材の人が会社に来て、私も転職者代表でインタビューを受けた。 前職と比べて何がよいか聞かれたので、こっちではお客さんに賞賛されたり社内で労われたりすることがあって、そんなこと期待したこともなかったので驚いた話をした。 これは何でなのかというと、以前よりお客さんが儲かるシステムを扱っているからだ。 あたりまえだと思われそうな話だが書いてしまう。 年間1億のコスト削減になるシステムなら、10画面ぐらいのWebアプリに数千万円の予算が付いて、納期もまっとうなものにできる。 逆に、できてもお客さんが大して儲からないシステムを企画すると、予算は付かないし納期も無理なものになる。 先方の担当者の構えも違ってくる。稼動しても社内で評価されないシステムなら、担当者に指名されてもやる気が出ないだろう。 また予算がないと、担当者が我々にタダで追加仕事をさせたくなるので、どうしても不幸なネゴシエー
SIにおけるソフトウェア開発の占める割合は小さいのか - GeekFactory
元請けの視点では、SIの多くを顧客調整が占めていると思います。次に進捗管理。次に資料レビュー。で、ずっと先に、設計書を書いたりコードを書いたり試験したりというソフトウェア開発がある。相対的な割合は小さいと思います。 何の割合かというとプロジェクトの成功を左右する要因です。原価ではない。 近視眼的な見方をすればという注釈が付きますが。要件定義を間違えれば成果物のソフトウェアが間違っているのも確かですが、完璧な要件定義手法が存在しないことも確かです。お客様に見せてみたら追加注文がいくつもきたというのは身近に起こっていることです。 id:kensir0u ＞外注化が必要な理由 もっと端的に、結局はアウトソーシングの原則で 外注化は業務上必要とする資源やサービスを外部から調達するということです。 つまり、製造能力が足りないならプログラマーを外注、マネジメント能力が足りないならマネージャーを外注とい
日本とシリコンバレーの泥事情 - ひがやすを技術ブログ
マドル・スルー（muddle through） シリコンバレーの流儀とも言われる、この言葉。まるで、泥の中に放り入れられたかのように、上下も左右もわからなければ、解決策も見当たらず、出口がどこにあるのかさえも見えない。その泥の中から顔を出すためには、頭で考えているだけではだめで、体を動かし、もがきながらも行動に移さなければならないと、渡辺は自身の経験を振り返って言う。起業直後に襲いかかる極めて困難な状況をマドル・スルーしながらクリアした者だけが、シリコンバレーでは生き残れる。 日本では、否定的な意味で使われることの多い10年泥問題ですが、シリコンバレー的に、この困難を乗り切れたものだけが、成功できると前向きにがんばるほうが成功しそうだよね。 泥の中にいる困難を嘆くより、泥から抜け出して成功することを目指してがんばったほうがいい。
総費用3300億円の巨大プロジェクト、三菱東京UFJ銀のシステム統合が完了
三菱東京UFJ銀行は2008年12月15日、旧東京三菱銀行と旧UFJ銀行の2系統に分かれていた勘定系システムを完全統合した。これにより、すべての店舗で同一の商品・サービスを提供できるようになった。2004年7月の経営統合発表から4年半。総費用3300億円、開発工数14万人月に及ぶ大規模プロジェクトが完了した。 勘定系は基本的に旧東京三菱銀のシステムに片寄せした。ただしATM（現金自動預け払い機）での通帳繰越など一部の商品・サービスは、旧UFJ銀の機能を採用した。旧UFJ銀の勘定系に接続している旧UFJ銀の店舗システムを、旧東京三菱銀の勘定系につなぎ替える移行作業を、この5月から8カ月がかりで進めてきた。 まず5月に、旧UFJ銀の機能を旧東京三菱銀の勘定系システムに搭載。旧東京三菱銀の店舗約250店で、旧UFJ銀と同様の商品やサービスを提供できるようにした。続いて7月から順次、旧UFJ銀の店
システム内製化のメリットはコスト削減ではなく、ITリテラシーが高まること - モジログ
ITpro - ヒトもカネもなくともシステム内製はできる http://itpro.nikkeibp.co.jp/article/COLUMN/20081202/320537/ ＜「ヒトもカネもない中小企業でも，やればできる」---菅雄一氏は関西のある企業のたった一人のシステム担当である。従業員約200人の製造業で，ほぼ独力でネットワークを引きサーバーを立て，社内向けのグループウエアや顧客向けのQ＆A情報検索システム，販売システムなどを構築してきた。 ミドルウエアとして使っているのは，すべてオープンソース・ソフトウエア。ハードウエアの代金と回線料を除けば，費用はほぼ菅氏の人件費だけだ＞。 「Linux好き事務員」として一部では有名な菅雄一氏の事例紹介を軸にした面白い記事。 この菅氏のような熱心な人材がいる中小企業はやや例外的だと思うが、システム内製化の動きが進んでいるのは間違いないようだ。
株式会社マジカジャパンの羽生章洋が書いてるブログ:ITは本当に必要か？ - livedoor Blog（ブログ）
こんなことを書くと自己否定のようにも感じたりしますが、一方で私は経営コンサルタントとしての側面もあるので、色々と考え込んでしまったりします。 あるお店の改善をするとして、ポップ一枚で業績が改善することも現実にあります。IT化以前にやれること・やるべきことが山積みの会社さんも非常に多かったりします。ところが、そういう会社さんに限って「IT化によって一気に会社を良くしたい」と考えがちだったりします。 一方でどうみてもそろそろIT化しないと辛いでしょう、と感じるような状況の会社さんに限って「いや、うちはずっとこうやってきたから」とIT化にはあまり関心を示しません。もちろん業績の改善には当然前向きなのですが、IT化ということについては興味がないのです。 業務システムを導入するというのはソリューションです。商売の基本としてソリューションありきではいかんというのがあります。お客様は、例えば在庫の山をし
銀行系SIerからみた今回の経済問題 - novtan別館
３つの理由とかは入れないようにしようｗ 第一期 サブプライム問題発覚直後 そもそも発覚前の銀行の利益って爆益といってもいいほどあったはずなんだよね。みずほFGで6000億くらい？それが半分以上吹っ飛んだというのも当初はわからなかったんだけど。 キャッシュの大幅な減少は、投資の抑制に繋がる。本当は三菱東京UFJ銀行が統合作業を終わるところで他のメガバンクに人が移動したり、東京三菱UFJが統合の余波を駆って次のシステム投資を行うところのはずだったんだけど。MUFGは統合が終わるまで慎重に、という言い訳で投資を抑制。他のメガバンクも目玉のシステム投資をしなきゃならんので既存のメンテ方面に大きなしわ寄せ。 第二期 巨額損失発覚直後 サブプライムの問題が意外と大きかったことが判明した直後。 もうメンテの案件も削られまくり、単価下降の要請も出る始末。そんななか、いよいよMUFGの統合対応要員が余り始め
今度の不況でSI業界が悲惨な状況に陥りそうな３つの理由 - masayangの日記（ピスト通勤他
釣り 題名に「３つの理由」みたいに数字を入れるとアクセス数が上がると聞いた。 本当かな？ 本題 自分がこの業界で景気後退を経験するのはこれで3度目。 一回目は1990年前半のバブル崩壊後。 二回目は2000年のネットバブル崩壊後。 今回のは1990年前半のそれを、規模・深刻さ共に凌駕すると予想している。 理由(1): 空洞化 「上流＝付加価値の高い仕事」という概念は根強く、開発という「核となる」行程を安い外部に流すようになってしまった。 レバレッジ効果があるから収益向上につながってきた。 が、新たな仕事が来なくなるとレバレッジは逆転を始める。 つまり、外部依存率を下げつつ、利益率向上を目指すという苦痛が待っている。 →開発を忘れた人達には無理。 理由(2): 分業化 1990年代初頭の情報処理試験は「二種」「一種」「特種」しかなかった。 今はなんだよ... 情報処理試験の中の人達に雇用機会
株式会社マジカジャパンの羽生章洋が書いてるブログ:ギョイゾー！の裏側 - livedoor Blog（ブログ）
今日は少し技術的な話です。スタロジはいわゆるウォーターフォール型というスタイルで仕事をしています。そして工程別に担当が分かれています。 ブリスタを使っての打ち合わせが完了したら、ブリスタから設計情報を出力してスタロジの中でファクトリと呼んでいる所謂工場のライン的なチームにそれを回します。すると、プロジェクトごとの段取り替えなど含めておよそ20〜30分程度で実際に納品可能なシステムが一式出来上がります。 ・正規化されたデータベース ・追加・更新・削除の一連の処理 ・権限によるアクセスコントロール ・ワークフロー ・多様な検索 ・検索結果のCSVダウンロード ・入力支援のためのポップアップするマスタ検索画面など ・各種仕様書 およそ業務システムとして必要な一式が完成します。これは画面数やテーブル数などの規模には左右されません。工場となっているサーバのメモリ容量などの物理的成約で作業時間が決まり
IT業界のシュールな現実（2）：下流から見たIT業界：エンジニアライフ
さる官公庁のシステム開発に参加したときのことです。基幹システムをダウンサイジングするという話でした。不勉強な私ですら名前を聞いたことがある有名なシステムです。元請は超大手SIerです。私はその3次請け業者の面談を受けました。技術的に高度なことを矢継ぎ早に質問されてたいへんな面談でしたが、とりあえず合格したようで、来月から来てくれといわれました。 現場に行くと、大部屋に100人以上の人が机を並べていました。官公庁がユーザーであるせいか、空調が高めに設定してあって（いわゆる「クールビズ」です）やたら蒸し暑い。部屋の途中に衝立があって、向こうは2次請けの会社が入っている。私がついた担当SEは、その2次請け会社の人たちにたいへん気を使っていました。ほとんど鼻息をうかがうくらいです。衝立のそのまた向こうに衝立があって、その向こうには元請会社が入っているようですが、こちらはもう“殿上人”のような扱いで
システム内製化に走るユーザー企業とSaaSの親和性
ユーザー企業で再び情報システムの内製化に向けた取り組みが活発になっているという。実際にここ半年ほどでユーザー企業からそんな話をよく聞くようになった。ところで、その一方でSaaSやクラウド・コンピューティングの流れがある。まるで正反対の動きに見えるが、実は同一線上にある。刺激的、かつ表面的に言うと「SIerを外そう」ということだ。 内製化と言っても、いまさらスクラッチでシステムを組み上げる話ではない。日経コンピュータも特集したが、システム開発の外注化で失われた、業務要求の取りまとめ、要件定義、仕様の確定、プロジェクト管理など本来の情報システム部門の能力を取り戻そうという動きだ。もちろんパッケージ・ソフトの活用を前提に開発も行う。外部のITベンダーを使う場合でも、一括請負を止めて、準委任や派遣で手伝ってもらう。つまり、自己責任でシステムを作りましょうというわけだ。 本来なら、これはもう当たり前
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
「小さなソフトウェアベンダー」という選択肢 : 小野和俊のブログ
「Eric Sink on the Business of Software」読了。献本感謝。 みんな大好きジョエル・スポルスキーも大絶賛の本書であるが、とても面白かった。 そして、本書で指摘される図星としか言いようのない的を得た指摘の数々がつぼにはまり、読みながら頻繁に声を出して大笑いしていたので、家の中で不審がられた。 私たちは、独創的なアイデアでソフトウェア業界の勢力図を書き換えてしまった人たちや、一夜にして巨万の富を手にした人たちにばかり興味が向きがちだ。 しかし、著者はそれに対してはっきりと「No.」を突きつける。 自分たちのソフトウェア製品を持ち、しかし大企業化を志向しない企業のあり方を、著者は「小さなISV」と呼ぶ。 それを私たちがなぜしようとしないのか、著者は次のように分析する。 1. 私たちはそれを見たいと思わない (巨大なマーケットばかり意識して、ニッチマーケットで優れ
よかろう、ではIBMの実情について語ろう - novtan別館
といっても観測範囲は決して広くありませんのでこれがすべてではありません。所詮若干付き合いがある先に過ぎません。 日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 はてなブックマーク - 日本IBMで何が起きているのか 訴訟続発に下請けとのトラブル（J-CASTニュース） - Yahoo!ニュース まずこの記事についていっておくと、別々なカテゴリの事案をまとめすぎｗ この中堅企業は開発の規模が膨らんだ時点で、追加支払いの約束をIBMがしたにもかかわらずこの約束が果たされなかったとして、IBMを相手
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
GeekFactory[B!]新着記事・評価 - はてなブックマーク
キーボードショートカット一覧 j次のブックマーク k前のブックマーク lあとで読む eコメント一覧を開く oページを開く ✕
ネジのお話 - GeekFactory
製造業の品質管理は誤差を測っているそうです。例えば、長さ5mmのネジを作る工場があるとすれば、製造したネジの長さを測り、5mmからどれだけ差があるか調べます。そして、基準値域に入らないネジを不良品として取り除いて出荷します。4.9〜5.1mmのネジだけを出荷するわけです。出荷できる製品の割合を歩留まりといいます。 長さ5mmのネジを作るには、設計書と製造プロセスが必要です。設計書には長さや直径、ネジ山の数などのいわゆる仕様が書いてあります。これに対して、製造プロセスはネジの作り方が書いてあります。着目すべきは、設計書は仕様であって作り方ではないことです。 製造プロセスを確立させるまでには、多数の試行錯誤があります。あーでもない、こーでもない、と試作品を作るわけです。試作品を作るときに、設計書の足りないところや実は作ることが不可能だったことに気づきます。このフェーズはいわゆる研究開発といわれ
この事例は泣き寝入りじゃないと思うんだが。 - novtan別館
いやまあね、確かに検収完了しないと納品完了にならないわけだけど、明らかな相手の落ち度にいちいち付き合っているから業界全体が無理難題を聞くものだと見做されるんじゃない？ そして年度末が近づいたある日，長谷川さんは突然呼び出され，検収結果を告げられる。どうやら独立行政法人の担当者は，検収に着手せず放ったらかしにし，年度末が近づいて慌てて実施したようだ。 しかもその内容は，「仕様と違う。バグなので修正してもらいたい。納品されたシステムはデータのソート（並べ替え）対象を一部に限定しているが，もっと多くの項目でソートできるようになっていなければならない」というものだった。長谷川さんは開いた口がふさがらなかった。 ［IT業界の弱者］非常識な「検収」で大赤字 | 日経 xTECH（クロステック） まあ、そうなんだけどさ。仕様と違うのが真実であれば、空いた口が塞がらないのは納品された側だし、そうでないなら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
羽生章洋『SIビジネスに未来はあるか!?』（WEB+DB PRESS Tech Meeting #2）
サイボウズ株式会社
