現行システムの見える化---目次
「度重なる改修やドキュメントの不備などで現行システムがブラックボックス化し，調査工数の増加や予期せぬ障害を招いている。この特集では，現行システムの見える化の実態とそのテクニックを解説する。 第1回 6割はいらないコードだった 第2回 設計書がない！担当者がいない！ 第3回 コードの調査だけで数カ月！ 第4回 データの「見える化」ならDFDを使おう 第5回 システムと業務をUMLでマッピングしよう 第6回 「見えない」システムが増殖する 第7回 こんな見える化は失敗する 第8回 業務とシステムを関連付けたい！ 第9回 効率よくヒアリングしたい！ 第10回 ソースコードのロジックを見える化したい！ 第11回 インフラを見える化したい！ 第12回 稼働中のシステムを見える化したい！ 第13回 障害原因を見える化したい！ 第14回 変化に強いシステムかどうかを見極めよう
[ThinkIT] プロジェクト管理TOP
【プロジェクト管理術】 ドラッカー流、リーダーの方程式 第5回：成果が上がる人、上がらない人 著者：エンプレックス株式会社 藤田 勝利 2008/10/31
IT業界のシュールな現実（2）：下流から見たIT業界：エンジニアライフ
さる官公庁のシステム開発に参加したときのことです。基幹システムをダウンサイジングするという話でした。不勉強な私ですら名前を聞いたことがある有名なシステムです。元請は超大手SIerです。私はその3次請け業者の面談を受けました。技術的に高度なことを矢継ぎ早に質問されてたいへんな面談でしたが、とりあえず合格したようで、来月から来てくれといわれました。 現場に行くと、大部屋に100人以上の人が机を並べていました。官公庁がユーザーであるせいか、空調が高めに設定してあって（いわゆる「クールビズ」です）やたら蒸し暑い。部屋の途中に衝立があって、向こうは2次請けの会社が入っている。私がついた担当SEは、その2次請け会社の人たちにたいへん気を使っていました。ほとんど鼻息をうかがうくらいです。衝立のそのまた向こうに衝立があって、その向こうには元請会社が入っているようですが、こちらはもう“殿上人”のような扱いで
Google 工藤拓さん講演「大規模ソフトウェア開発を支えるGoogleのテクノロジー」
NAISTにてMeCabの作者としても有名な工藤拓さんの講演が行われました。Googleの開発体制とそれを支えるツールのお話です。 学校と拓さんの双方からブログへの掲載許可が得られたので、まとめを公開します。この講義はNAISTのソフトウェア開発管理講義の一環です。 iPhoneカメラしかなかったので、画像が荒くて済みません・・・。 会場は大入り！ 工藤拓さん NAIST自然言語処理学講座出身 Googleに入社してから大規模開発やインフラを経験 MeCabを開発 NTTコミュニケーション科学基礎研究所に所属 その後Googleへ 研究より開発寄り Googleでの仕事 日本語のウェブ検索 「もしかして」機能 ダジャレサーチ エイプリルフールネタを1ヶ月かけて実装 何千人もの開発者が単一のソースコードリポジトリの上で開発を行っている 大規模開発をサポートするインフラが不可欠 Mondria
第11回 1日中デスク作業のあなたに贈る気分転換法：ITpro
デバッグで行き詰まった。設計がうまくイメージできない。ドキュメント作成に飽き飽きしてきた。作業中にPCが落ちた……。こうしたことがきっかけで集中力が切れて，「もうダメ！ もうヤダ！」と気が滅入ってしまうこと，ありますよね。でも片付けなければならない仕事は残っている。だから早く気持ちを入れ替えて，仕事を進めなくちゃと焦る。こんなとき皆さんはどのようにして気分転換を図っていますか？ 気分転換は社外で？社内で？ 先日，ITベンダーで営業を担当している友人2人と，3人で会う機会があったので，気分転換法について聞いてみました。友人Aは，こう言います。 「気分が滅入ったときは，お客様訪問かな。社外の空気も吸えるし，違う会社の中で打ち合わせすると嫌でも気分転換になるね」。 友人Bも同じ意見です。「私もお客様訪問。アポを入れてなくても，訪問することもあるよ。その帰りにカフェに寄るのが目的なんだけど
プログラミングは人生だ――まつもとゆきひろ ― ＠IT
私がプログラミングを始めたのは中学校３年生のときでした。父が買ってきたシャープのポケットコンピュータ（PC-1210）でBASICを使うようになったのです。わずか400ステップしか入力できない小さなコンピュータでしたが、それでも自分の命令したとおりに動作するポケコンを見ていると、自分にはなんでもできるようなそんな「万能感」を感じさせてくれました。 それから四半世紀以上たちましたが、私がプログラミングから感じる「わくわく」は少しも減ることはありません。むしろ、どんどん増えているように感じます。長いプログラム経験を踏まえて、いま、感じるのは、 プログラミングは人生だ ということです。プログラムには人生のあらゆる側面が詰め込まれています。文字どおり、人生そのものといってもいい過ぎではないでしょう。……うーん、やっぱり、いい過ぎかな。 プログラミングはスポーツだ 皆さんの多くは若いときにスポーツに
Joel on Software -
プログラマのためのユーザインタフェースデザイン 第 1 章 第 2 章 第 3 章 第 4 章 第 5 章 第 6 章 第 7 章 第 8 章 第 9 章 ストラテジーレターV 2002年6月12日 ミクロ経済学の補完財の原理について考えていて、私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由と言うときの自由」に浮かれるようになったわけではないということだ。ストラテジーレターⅤ 5つの世界 2002年5月6日 5つの世界：すべてのソフトウェア開発が同じではない。 追記：インターナルシステム、コンサルウェア、パッケージソフトの間には大きなグレーゾーンがあり、この3つの世界はしばし
6000人が作ったシステムは必ず動く：ITpro
最盛期の開発要員6000人，開発工数11万人月，投資額2500億円，取引件数1日1億件。三菱東京UFJ銀行が「Day2」と呼ぶ，勘定系システム一本化プロジェクトの成果物である。6000人のシステムズエンジニア（SE）が作り上げた巨大システムは，2008年5月の連休明けに必ず動くはずだ。 23年間にわたって情報システム開発プロジェクトの取材を続けているが，6000人のSEを集めた事例は過去に一度も見聞きしたことがない。世界を見渡してもおそらく例がないはずだ。これから何年間，記者を続けるのか分からないが，今回の三菱東京UFJ銀行を除けば，6000人を動員するプロジェクトを取材する機会は二度とないだろう。 6000人のSEが同時期に集まったのであって，「6000人月」ではない。開発工数は先に書いた通り，11万人月である。この数字も凄い。一体何を作ったのかと思ってしまう。正確にはこのSEパワーは開
プログラマの心の健康
目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードを食べながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。
ソフトウェア工学とは何か
ソフトウェア設計とは何か？ （原文： What Is Software Design?） by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は，Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 本記事では，オブジェクト指向プログラミング言語の代表として C++ を挙げていますが，これは本記事が執筆された当時，一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java，Delphi，C# といったオブジェクト指向言語が利用可能となっていますが，そんな今でさえこの記事は古さを感じないものとなっており，ソフトウェア開発の本質，現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W.
Teach Yourself Programming in Ten Years 日本語訳
以下の文章は、Peter Norvig による Teach Yourself Programming in Ten Years の日本語訳である。 本翻訳文書については、以下の方々にご教示を頂きました。ありがとうございました。 Shiro Kawai さん：誤訳の訂正 三好博之さん：誤訳の訂正 竹中明夫さん：2001年7月改版分の訳、誤訳の訂正（共訳者にクレジット） Toshihiko Ono さん：誤訳の訂正 アクビさん：訳注３に関する情報 どうしてみんなそんなに急ぐの？ どの本屋に足を運んでも、『7日で学ぶ Java』といったハウツー本を見かけるし、そのそばには Visual Basic や Windows やインターネットなどについて、同じように数日や数時間で学べると売りこむ本が無限のバリエーションで並んでいる。Amazon.com で以下の条件で検索してみたところ、 pubdate
素早く正規形を見抜く実践テクニック（1/4） － ＠IT
今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。 ではなぜ「第3正規化まで行えば問題ない」のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿
Getting Real by 37signals
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> �LN�U �u�M�U Getting Real The smarter, faster, easier way to build a successful web application Start reading →
O'Reilly Japan - オープンソースソフトウエア Web版
目次 訳者まえがき 謝辞 1 はじめに クリス・ディボナ／サム・オックマン／マーク・ストーン 2 真のプログラマ（hacker）たちの国――概略史 エリック・S・レイモンド 3 バークレー版UNIXの20年 （UNIXが、AT&Tの所有物からオープンソースソフトウェアになるまで） マーシャル・カーク・マクージック 4 インターネット・エンジニアリング・タスクフォース スコット・ブラドナー 5 GNUシステムとフリーウェア運動 リハード・ストールマン 6 シグナスソリューションズ社の将来性（創業者からの報告） マイケル・ティーマン 7 オープンソース開発におけるソフトウェア工学的側面 ボール・ヴィクシー 8 Linuxの強味 リーナス・トーバルズ 9 ユーザにすべてを提供するビジネスモデル ロバート・ヤング 10 努力、忍耐、謙遜 ラリー・ウォール 11
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
上流工程-設計---目次
ソフトウェア開発の落し穴