詳細設計書が滅亡しない理由 - kagamihogeの日記
IT 業界というか SIer の枠組みの中で働いている人であれば、一度は詳細設計書ないし詳細仕様書というドキュメントを見たか書いたことがあるだろう。 Excel 方眼紙の悪夢 詳細設計書の話の前にちょっと触れておきたいのが「Excel 方眼紙」 これまでのプロジェクト経験とネットの情報を見る限り、詳細設計書はほぼ 100% コレで書かれている。Excel 方眼紙がどのようなものかは こんな感じ である。典型的な使われ方は 【図解!!コレが方眼紙Excelだ！】:島国大和のド畜生 がわかりやすい。 「Excel 方眼紙」でググるとわかのだが、コイツは猛烈に嫌われている。一発作り捨てならば、図や表を交えたドキュメントをそこそこ作りやすいという利点はある。プレゼンや紙印刷を考えないならば、個人差はあれど PowerPoint 並の使い勝手を覚える人はいる。 がしかし、Excel 方眼紙はそのメリ
会社潰すのは簡単、アイツがいれば勝てる、と思った人間を雇えば良い
最近話題の エンジニアよ、ゼネラリストなんて目指すな！―VASILY 金山裕樹のキャリア論（http://japan.internet.com/busnews/20121130/3.html）を見て・・・ コードを書くことが目的化しちゃってる人も多いので全否定するつもりはないけど、コードが汚くても「アイツがいれば勝てる」と思わせる人間を素人判断で雇うことが如何に危険かプログラマ視点でまとめてみる。以下何度も見てきた典型的な失敗パターン、設計と実装が完全に分業化されてる分野は知らないけどWeb業界などそうでない所のお話。 手抜きプログラマは人を騙す非エンジニアを騙して手抜きするのは簡単。余程のヘタレでない限り手抜きをしても絶対にばれない。コードにコメントがなくてもモジュール化されてなくてもコピペ満載でもマジックナンバーだらけでも動いてさえいればユーザーは気にしない。 手抜きプログラマの評価は
アビームコンサルティング 「うちは泥イト」――給料安い事業会社チックなSI系コンサル
2004年にＮＥＣと提携関係を結んで以来、段階的に資本関係を強めていったアビームコンサルティング。今やすっかりＮＥＣの子会社（議決権の99.9％を保有）に収まったが、そのＮＥＣが２０１２年３月期に１１０３億円の最終赤字に陥り、この7月から40歳以上を対象に希望退職の募集を開始。株価も遂に100円割れで、ただでさえ低めな給与は基本給4％カットと賃下げ中だ。その子会社に、しわ寄せが来ないはずがないのだった。 Digest 「ＮＥＣの奴らにしゃべらせるな」 社名の由来は「趣味がヨットだから」 うちは「泥イト」だから リース業界とＮＥＣ系がメイン 定年退職者がいるコンサル会社 炎上した巨大プロジェクト 「バジェットによる」残業代 ロッカーも1人1個ない 「ＮＥＣの奴らにしゃべらせるな」 そもそもの両社の提携は、ＮＥＣの幅広い顧客基盤が欲しかったアビームと、ＩＴコンサルの人材・ノウハウが欲しかったＮ
IT企業の東京進出とブラック化 - カレーなる辛口Javaな加齢日記
http://d.hatena.ne.jp/tomoya/20120612/1339486204 7月から東京へ引っ越します。 さて、実は我々ラングリッチ一同は、事業拡大のためこの7月から東京へ移転することになりました。一部の方には既に簡単にお伝えしておりましたが、ここで正式に発表致します。 東京方面にお住まいの方々、今後より一層仲良くして下さい! メンバー募集！！！ なんとなく，これを見て暗い気分になった． これまで、我々はフィリピンと日本の神戸という名の明石との、2拠点で活動を行なってきたのですが、お陰様で無事に事業拡大することができ、徐々に人手が足らなくなってきました。 ただ、神戸やフィリピンでは残念ながら、良い人に声をかけたくても地理的な問題極大で、現実問題ひじょーに難しく、このままでは主に僕が死に至る可能性が出て参りました。 そこで、この問題を抜本的に解決すべく、全てが集まる東京
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
世界的IT企業におけるそれぞれの組織図（画像） | naglly.com
Amazon、Google、Facebook、Microsoft、Apple、Oracleそれぞれにおける、組織図のチャート一覧です。 参照元はこちら。 Organizational charts for tech companies http://www.bonkersworld.net/2011/06/27/organizational-charts/ 本当に組織がこうなっているのかはとりあえず置いてといて、「なるほど。これは、ありえそうだな。」と思わせてしまう所が素晴らしいです。 IT企業における理想の組織図は一体どれなんですかね。やっぱりGoogleかAppleかな。Microsoftは...もはや、普通の企業じゃん。 その他の参照元はこちらです。 The Org Charts Of All The Major Tech Companies (Humor) http://www.b
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
SEとPG、どっちが頭がいい？（2）：下流から見たIT業界：エンジニアライフ
刺戟的な題名で続けます。 前回は日本独特のSE／PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日本にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE（システムエンジニア）だというものでした。 ●C言語＠UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ
「ＩＴって、何？」質問2： ＩＴを理解している人を見分けるにはどうしたらいいの？ | タイム・コンサルタントの日誌から
＜ データと情報の違い ＞ 「じゃあ、次の質問、いきます。 ＩＴを理解している人を見分けるにはどうしたらいいの？」 －－それはいい質問だね。見分ける方法か・・。 そうだな、こういうふうに訊ねてみるといいかもしれない。『データと情報はどこがちがうか？』 この質問にはっきり答えられる人はＩＴの本質について洞察をもっている人だ。逆に、いかにパソコンにくわしくても、この質問の意味が分からない人は、ＩＴの意義を理解できていないと思った方がいい。 「データと情報？ それって何がちがうの？ 同じものかと思ってた。」 －－たいていの人は「データ」と「情報」という二つの言葉を、あまり区別せずにつかってる。専門書ですら、ときにはあいまいにしている。しかし、ＩＴを理解する上では、この両者ははっきりと区別する必要があるんだ。 「情報」とは、人間にとって意味をもたらすものさ。人間の話す言葉、書く言葉は意味を伝達する
旧態然とした会社と最新技術をおいかけまわす会社、以外の会社 - monjudoh’s diary
それが本当に「間違っている」のであればそれはいずれ淘汰されます。だけれども旧態然とした会社と最新技術をおいかけまわす会社、5年後にどちらが存続しているかは結構微妙な勝負なのではないかと思います。 現在もそんなやり方をつづけられているのであれば、やり方としては間違っているけれども全体としては最善手ではないにしても適手なのでしょう。 http://d.hatena.ne.jp/kuippa/20100814/1281767643 思うに非効率なプロレスをうまくやっている会社=旧態然とした会社は、 最新技術をおいかけまわす会社と5年後の存続可能性が五分五分だとしても、 その時点で主流の言語で非効率なプロレスをやらされてる下請けは 五分五分じゃなくて高確率で消えてたりするんじゃないの? 旧態然とした会社はその時代その時代で別の下請けを使って、 上手くプロレスをやるから存続できるって話なんじゃないの
日本とアメリカのITに関連する違い - 余道を愉しむ
日本とアメリカのITに関係するビジネスモデルやらなにやらが異なるおかげで、頭の中がモヤモヤしっぱなしなので、メモ代わりに書いておく。 (1)SIerが居ない 僕は日本ではSI企業に勤めているのですが、その立場から感じる日米の一番大きな違い（そして一番の大きな悩み）はこれだと思う。 アメリカの企業はシステムの開発／導入／運用を基本的に自社内のエンジニアが行う。日本のようにSIerにアウトソースして、一切を任せるということはない。このため、米国のベンダー企業(Cisco,HP,Oracle,EMCなど)から直接機材を調達するという構図ができている。もちろんSIerが全くない訳ではなく、展示会などに行くと、システム構築をお手伝いする企業だとか、運用を請け負う企業だとかは見かけるのですが、彼らは、リソースが足りなく、スケジュールが厳しく、かつコスト対効果が見合うときにのみ声がかかるいわばピンチヒッ
日本のソフトは「擦り合わせ」で米国に負けた - 雑種路線でいこう
ものづくり研究では伝統的に日本が得意とされてきた「擦り合わせ」が、デジタル家電や携帯電話の世界で必ずしも機能せず「ガラパゴス現象」を招いた背景に何があるのだろうか。 しばしばソフトウェアの世界で重層的な下請構造が問題とされがちだが、この構造は雇用慣行や産業構造に起因しており、必ずしもソフトウェアに限ったものではない。例えば昔の繊維産業や現代の自動車も多段的な下請構造を抱えているが、決してガラパゴス化していない。これから述べることは一般論に基づく仮説であり、いずれ実証分析したいので、間違っているところは是非ともご指摘いただきたい。 自動車や家庭用ゲーム機・デジカメ等と比べてガラパゴス化している携帯電話・地デジ・業務ソフトウェア等で共通しているのは、まず機器メーカーが最上位にいないことである。最上位に電話会社・銀行といった大口顧客やテレビ局のような鍵となるステークホルダがおり、主契約企業が下請
今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page
[この発想はなかった] 専任のSubversionオペレータなる人がいるらしく、受理された申請書と変更ファイル(を入れたUSBメモリ)をSubversionオペレータさんに手渡すと、あとはオペレータの人が代わりにコミットしてくれるみたいですよ。
どこへゆく大手SIer：IT業界来し方行く末：オルタナティブ・ブログ
大規模システムを受注し、プロマネだけやって、実務は協力会社に任せていた会社が、ここに来て内製化に切り替えている。 今日聞いた話だが、内製化したのはいいが、社員に技術力が無く、大量データのレスポンスを確保できない。 このままでは訴訟になるのではないかとの話だった。
デブサミからもらったものをデブサミに返してきました。 - The Dragon Scroll
2010年のデブサミが、自分にとってこれまでと違うデブサミになりそうだと最初に考えたのは、DevLOVEコミュニティで97本の読書会を開いた時だった。 読書会後の懇親会で、この本の監修者であるyusukeさんに、「デブサミで話してみないか」という誘いを受けた。私はその時、yusukeさんが冗談を言っているのだと思った。 そもそも、デブサミは私にとって特別なイベントであり、その特別な場所で私が壇上に立って、話すというのは、好きなプロ野球球団から、バッターボックスに立ってみないかと言われているのと同じことを意味した。 ところが、yusukeさんの次の一言が深く自分に突き刺さり、「デブサミで話す」ということがリアリティのある話として感じられるようになった。 「聞きに来る人が、たとえ10人でも1人でもいいではないか。何を考えているのか、少なくとも私は聞いてみたい。」 こんな嬉しい言葉を一体人生で何
「日本のIT業界に未来がない」のはデフォ - カレーなる辛口Javaな加齢日記
http://japan.cnet.com/marketing/story/0,3800080523,20406924,00.htm http://blog.livedoor.jp/insidears/archives/52176903.html http://workingnews.blog117.fc2.com/blog-entry-2524.html http://www.asahi.com/digital/cnet/CNT201001190058.html IT人材の約半数が転職を意識--理由は「会社の先行きが不安」 「(日本の)IT業界に将来がない」のは既に共通認識だと思う．失われた20年の傷跡があまりに大きすぎた． 「あとは何年後に何社(何十社，あるいは何百社)潰れるのか？」の問題だな． 個人年収が下落している人ほど転職を検討している割合は上がり、過去1年間で個人年収が15〜2
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
Whyも書け - イトウ アスカ blog
重要なことなので何度だって言いますよ。 コンピュータシステムの仕様書を書くとき、以下の項目が文章として残されていますか？ What - 何を（入力の形式） Where,Who - どこの誰が（どのコンピュータが） When - いつ（処理のタイミング。オンデマンド／バッチ。さらにはこのシステムが作られた日） How - どのようにするのか そして Why - なぜこのシステムが必要なのか。システムの狙いは？
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ベリーズに死す：IT業界の狂犬ジョン・マカフィーと頽廃の王国
一山いくらで人月見積の大手ベンダーを外し始めたユーザー企業のITガバナンス
