久々のSI業界
3，4年前にSI業界を去り、そっから自社開発等を転々とし、最近たまたまSI業界の現場に戻ってきた。 なんていうか、なんにも変わってない気がした。 相も変わらずの人月開発。 デスマにおちいり、とにかく人増やし。 テスターだけは増えたけど、回す人がいないため、空き稼働が多発。意味なし。 申請書類だけは山のよう。 だれが何やってるかわからず。 管理G、管理チーム、管理者、多々いるにもかかわらず、 なんかの会議で状況を誰も把握できずに、担当者を直呼び出し。 テストは当然手動確認。 前後のインタフェースが当然バグだらけ。 単体レベルのバグが総合で頻発し、全然試験進まず。 管理者はEXCELの表に値を埋めることしか頭になく。 終電、徹夜、始発帰り、ホテル住まい、タクシー帰り当たり前。 世の中探せば、ましな職場はいくらでもあるのに、 なんでこんな現場に留まってるのか理解に苦しむ。 また何年か後に顔出して
金融再編残酷物語「システム統合の正攻法」
Day2の大本営発表。 Day2とは"Project Day 2"のことで、東京三菱とUFJの勘定系を統合させた、史上最大のプロジェクトだ。本書は、日経コンピュータの記事を元に、Day2のケーススタディとして編纂されている。プロジェクトマネジメントとシステム統合の文字通り「生きた教科書」といえる。ただし鵜呑むのは禁止な、経営層の大本営発表を元に作られているのだから。「涙の数だけ強く慣れるよ」（誤字ではない）とつぶやきながら読むべし。 Day2がいかにデカいかは、次の数字が物語る。 11万人月 2500億円 開発に3年 6000人の技術者 8万人のシステム利用者 比較のために添えておくと、みずほ銀行のシステム統合（2004.12完了）は9万人月、郵政民営・分社化に伴うシステム対応（2007.10完了）は、4万3000人月になる。Day2がいかにケタ違いであるかがよく分かる。これに加え、チーム
ガラパゴス化する日本の開発環境
とある日本企業との仕事で衝撃を受けたことを前回のエントリーで書いたのだが、より驚いたのが、それに対していただいたコメントやはてぶのほとんどが別に驚きもしない、うちもおなじ、というものだった。 ・いや、おそらく日本では普通だと思います。 ・そもそも人事部が採用する時に、技術スキルの高い人は取ろうとしませんし、ユニットテストのような基礎知識さえも全く知らない人が大半を占めます。 ・見直すための工数は悪、辻褄合わせるのが正義。 ・以前、某ERPパッケージの下請けで働いていましたが、テストを手動でやり続けるのに嫌気がさして、辞めました。あれは鬱になる...。 ・日本では専門家を軽視して、「ビジネスゴールを最優先して考える俺は偉い。技術馬鹿、専門馬鹿とは違う」っていうタイプの人材が評価される組織が結構多いのですよね。 ・あるあるすぎて、笑えない。 ・請負的な開発はこういった傾向が強いと思う。残念なが
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について（METI/経済産業省）
本件の概要 経済産業省では、情報システムの取引において、現行の「人月方式」以外での価格決定方法を模索するため、情報システムの付加価値に着目して価格を決定する「パフォーマンスベース契約」について検討を行ってまいりました。 今般、「情報システムのパフォーマンスベース契約に関する調査研究」報告書として取りまとめましたので、公表いたします。 担当 商務情報政策局 情報処理振興課 公表日 平成21年7月31日(金) 発表資料名 「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について(PDF形式：12KB) 報告書(PDF形式：2,175KB) Acrobat Readerをダウンロード（Adobeサイトへ） このページの先頭へ
「レガシーコード改善ガイド」のススメ 第1回：レガシーコードの定義、テストの重要性とは
「レガシーコード」とは何か 最初に1つ質問です。皆さんは、「レガシーコード」と聞いて何を想像するでしょうか？ 多くの方はCOBOLなどで書かれたメインフレームで動くコードを真っ先に思い浮かべるのではないかと思います。しかし、本当にそれだけでしょうか？ ここでは「レガシーコード」という言葉を『何年も前に誰かが作り、内容が複雑で何をしているのかよく分からず、まともな仕様書もない』というコードを指すものとします。そう考えると、必ずしもメインフレームだけの話ではなくなります。この記事を読んでいる皆さんなら、そのようなコードを少なからず目にしていることでしょう。 現在の業務システムは、Java EEや.NETなどの基盤上に構築される、いわゆるオープンシステムが主流になっています。このようなオープンシステムであっても、構築されてから既に5年以上経過していることが珍しくなく、何度も手が加えられたコードは
2007-08-28
救われない「不運」について: マーケットの馬車馬 リンク先の本題は「不運ヘッジ」について、およびマクロな政策は（当然ながら）目の前の困窮者を救い得ない、という話だが、 もうひとつのムチは、非正規雇用者の組合をもっと充実させること。最近になって非正規雇用者の数が増えているということは、組織化すれば一定の交渉力を獲得できるということでもある。ただし、この組合は会社だけでなく正規雇用者の労働組合を敵に回すことになるので（労働組合にとって、非正規雇用者や失業者は自分の職を奪いかねない敵である）、実現のハードルは高い。 に引っかかってみる。 当たり前の話だが脳内整理メモ。 労働組合が望むのは「現状の固定化と安定化」であるということ。 僕らの世代が労組ときくと真っ先に連想する「賃上げ要求」は賃金の変化への要求ではなく「毎年賃上げされる状況」の固定化の要求にすぎない。 自由競争社会が健全に機能するために
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
プロジェクト管理やテスト工程をクラウド化する - プログラマの思索
Hudsonの下記記事を読んだ感想をメモ書き。 【元ネタ】 Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記 近年、HadoopやSeleniumなど、複数のサーバ上で動作する事が前提のツールが増えてきており、マルチコア化・クラウド絡みで、このトレンドは今後も続くと予想されます。 ところが、こういったツールはセットアップと運用保守に手間がかかるという欠点があります。 Hudsonで僕がやろうと思っている事の一つは、Hudsonのクラスタ上にこういったツールをインストールするのを簡単にすることです。 Hudsonのクラスタはインストールがとても簡単ですし、プラグインのインストールも容易なので、この環境の上に他のツールをオーバーレイすることで、手間なく様々なツールを利用できるようになります。 「ThoughtWorksアンソロ
DB設計時のサイズ見積もり - よねのはてな
ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
銀行の言語事情 - novtan別館
といってもグローバルに活躍するためのマルチリンガルな話ではありませんよ。 今やメガバンクになってしまいましたが、僕がIT業界に入ったときはまだ都銀と呼ばれていた某銀行でのお話。用語について一切説明せずに行ってみる。世代チェッカーかも。 ホスト系 今やメインフレームだからといってホストでもない時代ではありますが、都銀のシステムはトランザクション量やダウンタイムの問題からやっぱりメインフレーム、で、過去の遺産がありすぎてホスト型。 言語はCOBOLが中心ですが、コア部分に近づくとPL/Iだったりアセンブラだったりする。大事なスキルはJCLを書けること。まあ、JCL自体はシェルプログラミングと変わりません。VOL-=SELの指定とか面倒だけど。基本的に端末のI/Fを想定しているから、SNAとかFNAとかで通信しなきゃいけなくて手続きはめんどくさい。メモリとかディスクの容量が少なかったときの設計を
要件定義カード1枚8万円──脱・人月商売宣言 － ＠IT
「1タスク8万円」という価格体系を提示し、人月商売からの脱却を宣言するスターロジック代表取締役兼CEO 羽生章洋氏 「二度と人月商売はしません」──スターロジックは7月19日、都内で開催した自社イベント「StarLogic Conference2007」において、エンドユーザー自身による要件定義に基づき、「要件定義のカード1枚当たり8万円（税別）」という価格体系でシステム構築ビジネスを進めていくと発表した。従来の「人月」に基づく見積もりと比べて、1/3から1/5の価格になるという。 「人月換算でコストを請求する商習慣こそが、SI業界のさまざまな問題の根源。人月から脱却するには、納得でき、分かりやすい価格体系を提示することだ」（スターロジック代表取締役兼CEO 羽生章洋氏）。 低コストにできる理由は、ユーザー自ら要件定義を行い仕様を最初に明確にする点と、実装段階で自動生成により生産性を追求し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情シス、ベンダーがそれぞれの仕事を全うすることがベストな関係を生む～良品計画がシステムを内製する理由
サービス終了のお知らせ