アジャイルで不幸にした業界、法令工学を応用することで、幸せになれれば。。。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） いいけどね！ せっかくコメント無視、匿名で書いているんだから、 もっと、世間から、反発されるけど、大事なことを、たまには、書いてみたいと思う。 最近、IT業界って、暗いとおもいませんか？ 村上企画官のおことばを待つこともなく、７Kとか１０Kとか、まったくもって、暗い、イメージの悪い業界になってしまったと思います。 こうなった原因の多くは、アジャイルという名のもとに行われる、仕様の五月雨式変更にあるとおもいます。 ウォーターフォールだった、８０年代後半、９０年代前半は、後工程で仕様変更が原則できないため、どの仕様変更を（例外的に）あえてするか、それをした場合にどれほどのインパクトがあるかを計算してから、行われました。つまり、要求仕様が管理されていました。 さらに、テストに関しても、
404 Blog Not Found:惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら
2007年10月26日01:45 カテゴリ翻訳/紹介Art 惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら 全プログラマーが泣いた。 If architects had to work like programmers... 実は一つだけ「ローカライズ」にあたって変えた前提があります。日本ではこちらの方が実情に沿っているでしょう:) 建築士様、 家を一つ設計施行してくださいな。まだ何が必要か具体的なことはわからないので、そこはよきに計らう方向で。 寝室の数は、2から45までの間。寝室の追加と削除は簡単に出来るようにしといて下さいね。青写真が出来次第あたしが何が気に入ったかを最終判断します。それぞれの青写真について明細書を付けるのをお忘れなく。後で気に入ったのをピックアップできるように。 完成後の家の費用は、今住んでいる家よりも安上がりでないと駄目なことを留意してくださいな。そ
失われた２０年－ソフト業界は変わったのか？ その１２：１９９５年ごろ（５） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ２０年位前、１９８０年代終わりごろから、最近まで、ソフト業界とかその周辺の変遷について、特にソフト開発の立場を中心に見て行く、土日シリーズ「失われた２０年－ソフト業界は変わったのか？」その第１２回目。 今、１９９５～９９年までについてです。今回は、そのころの開発方法論、その２ 構造化分析やDFDについてです。 ■情報関連図からDFDに １９８０年代から、９０年代のはじめころまで、COBOLベースの開発のころは、要求仕様レベルで、機能を書くとき、情報関連図（FIO図っていうのと同じかな？）で書いてました。機能があって、入力、出力を書くものです。 で、これをもっと、機能とデータをはっきり分け、他人でも検証可能な形にしたDFD（データフローダイアグラム）が盛んにつかわれるようになります
SIの稼働率 - essence-s
派遣ビジネスかSIかと考えてたら、派遣もやってるSIだったら、リソースが食われるのは当たり前だということだ。 SIに徹するにはやはり空きがでてしまうのを覚悟するべきなんだろうか。 OOスクエアインタビューより引用。 http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview37.html 私は、SIは宿命的に暇な時間が多いビジネスだと思っているんですよ。SIは可能な仕事量が頭数に限られますし、それぞれ案件も期間が違いますから、 売り物として難しいんですよね。やれなきゃ無理して案件取ったって仕方ありませんし、だからしゃかりきに営業もしない。1人が一ヶ月だけ手が空いているときに、都合よく 1人で一ヶ月の仕事っていうのはありませんから（笑）。派遣ビジネスだとそこで無理に切り売りされちゃうでしょうが、受託開発に徹するとそうはなりません。
NameBright - Coming Soon
michys.com is coming soon This domain is managed at
NECも営業とSEを一体化、その“時代背景”を考えてみた：東葛人的視点 日経BP社
« 続々と登場するオープンソースの | メイン | 内部統制商談ですか、「まず隗よ » NECも営業とSEを一体化、その“時代背景”を考えてみた ［2005年08月25日］ うかつにも今まで知らなかったのだが、昨年の富士通に続き、NECも今年4月にSIビジネスで営業とSEを一体化させたそうだ。“開びゃく”以来、初めて営業とSEを一体化させた富士通とは違い、NECの場合、過去に一体だった営業とSEを分離したことがあり、今回再び元の体制に戻した形だ。SIビジネスにおいて、営業とSEは別組織がいいのか、一体がいいのか、これは永遠のテーマだ。ただ、最近は「一体化すべき」の声が強まってきたようだ。 営業とSEを別組織にするメリットは、それぞれのノウハウがたまりやすいことだ。それぞれ「売ること」「作ること」に集中し、磨きをかけ、それぞれのノウハウを蓄積していくためには、営業とSEは別組織がよい。NEC
東葛人的視点 日経BP社
« NTTデータがグローバル提携、 | メイン | ようやく地に足がついてきたIT » 大失敗プロジェクトとの元凶ともなり得る要件定義、これは誰の仕事なのか ［2005年07月26日］ 要件定義は、いったい誰の仕事か。今の常識では、システム構築を受注したITベンダーの仕事となっているが、よく考えてみると、そう簡単に割り切れない。「大失敗プロジェクトの原因は要件定義にあり」というのは、ユーザー企業、ITベンダーを問わず共通の認識だが、ユーザー企業は「要件定義もまともにできないのか」とITベンダーを声高に非難し、ITベンダーは「ユーザー企業の要求が曖昧で…」と陰口を言う。そもそもの話、要件定義は誰の仕事なのだろうか。 要件定義は言うまでもなく、システム仕様を確定させる作業である。古参のSEやプログラマから言わせれば、システム仕様は契約時に確定しているものだ。ソフト開発がモノ作りと発想すれば、製
チームリーダー日記 : メソッド名の辞典
■メソッド名で悩む頃 メソッド設計を真面目にやっていくと、メソッド名の付け方に悩んだり、他人のメソッド名に違和感をおぼえたりする時期が来るかと思います。 ■メソッド名の規則性 JavaAPIをいろいろ読むと、メソッド名に一定の規則性があることに気づきます。 Singletonなメソッドだと、staticメソッドで、かつ、getInstanceというメソッド名である、とか・・・ 英語がネイティブな人たちだと感覚的に分かるのかもしれません。 ■英語がネイティブじゃない人は、メソッド名の辞典を使おうよ こんな感じです。（スクリーンショット） メソッド名の動詞の部分についてメンバー間で共通理解が出来てくると、ソースを見て理解するまでの時間も短縮されると思います。 ---
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
