窓のない部屋に鮨詰めにされて 会議用の長机とパイプ椅子で 隣の人の肘があたったり、前の人の足が当たって 便所は長い行列で漏れそうになる 当然毎日終電 助けて 関連：【悲報】みずほ銀行の次期システム、デスマプロジェクトが破綻か。完成のメドなく4000億円がパー

昔々、具体的には約1万7千年前の旧石器時代、大学の情報工学科を卒業して、新卒22歳でSIerに就職した男(以下SE)がいました。 SEはある日、上司に言われました。 「2016年くらいに、銀行で大規模な基幹システムが必要になるらしいから、今から君一人で作り始めて。工数は20万人月ね。」 そういうと、上司はシステム企画構想やそれに伴う提案書、ノートPCを1つSEに渡して、自分は狩りに出かけました。 途方にくれるSE氏、ここから彼の約1万7千年(1万6666年)にも及ぶ、20万人月のシステム開発が始まるのでした。 約1万7千年前 |- 要件定義書を作成着手。 | 周りの人達は狩りをしながら生きている。 | 約1万6千年前 |- 要件定義書の作成が完了する。 | 基本設計に着手する。 | 土器を作り始める人が現れる | 徐々に日本列島が大陸から離れ列島になっていく。 | 約1万4100年前 |-

言いたいことがストレートに伝わる良い文章だと思います。 simplearchitect.hatenablog.com ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。 では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。 確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？ 僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエア

ずっと同じことを考えている気がするけど、微妙に違うしれないので書くだけ書く。 人月で工数積算してマージンを抜くビジネスが、そもそもマージン抜けるほどの工数で値段付けするのが通用しなくなってきたよねというのがここ数年の変化だとしましょうか。人を出すだけで金を儲けるなんてそれってITエンジニアの無駄遣いだよねっていう。このモデルが崩壊した場合、今後は誰がどうやってビジネスアプリケーションを作っていくの？ 担い手はいるの？ というのが全然見えて来ないのではないでしょうか。 AWSがいくら破壊的だろうが、あれはプラットフォームのサービスであってアプリケーションのサービスではない。最高のメンテナンスが出来る環境があっても、どんなプラント建てるんですか御社はって問いに答えは出せない。エンプラになればプラントの工程の一部やつなぎをAWSでやるんだろうけどさ。 上流と下流が分断しているのがSI業界の最もあ

6月30日をもって、SIerのちっちゃい会社を辞めました。 7月からはSIerのちっちゃい会社で働きます。 僕が強く主張したいのは、転職タイミング的に夏のボーナスが出ないということです。 皆様のご好意をお待ちしてます！！！切実にビールとか技術書とか！！ ほしい物リスト なんでやめたの？ 特に会社に大きな不満はありませんでした。 それに技術者のはしくれとして飯を食っていけるようになったのは この会社のおかげなのでそこは頭上がりません。 ただ、この会社でやりたいことは全てやったなという 自分の中でのしきい値を超えただけです。 客観的に見てやり尽くしたわけではないでしょうが、 僕個人の主観としてはもうこれ以上はやることないなと。 1年前ぐらいの段階でその結論には至ってて、 あとは環境面、待遇面、業務内容などで良い会社 と巡り合えればなぁという気持ちでした。 これから何やるの？ これからも基本的に

どうも私はIT業界の人たちから、オオカミ少年だと思われているらしい。随分前から「SI（システムインテグレーション）ビジネスの終焉」を騒ぎ立てていたが、SIビジネスは幾多の不況期を乗り越え、しぶとく生き残ってきた。だから私がオオカミ少年だと言われるのは、まあ仕方が無い。だが、あえてまた言う。「今度は本当にオオカミがやって来る」。SIerの余命はあと5年である。 SIビジネスはユーザー企業などからシステム構築を請け負う人月商売だが、日本では“SIガラパゴス”と呼ぶ、世界に類を見ない多重下請け構造のエコシステム（生態系）を発達させてきた。このSIガラパゴスには、零細ベンダーも含めると約1万5000社がひしめき、元請けのSIerを頂点に、顧客である企業や公共機関のシステム構築に関するあらゆるニーズ（≒わがまま）に対応してきた。 これは、システム構築ではERP（統合基幹業務システム）をそのまま使った

よんてんごP @yontengoP 手取りが30　手取りが30 何しよう～♪　何しよう～♪ 何もしないで　何もしないで 寝ていたい～♪　寝ていたい～♪ (『グーチョキパーでなにつくろう』) 同僚「朝から何を」 俺「また電車の中で思いついちゃったんだよなぁ… #社畜童謡 #大人の童謡 ってネタを」 2014-10-02 09:16:40 よんてんごP @yontengoP 土日が休み　土日が休み 何しよう～♪　何しよう～♪ 何もしないで　何もしないで 寝ていたい～♪　寝ていたい～♪ (『グーチョキパーでなにつくろう』) 同僚「展開同じじゃないですか」 俺「それだけ俺の決意は変わらん、ってことだよ」 #社畜童謡 #大人の童謡 2014-10-02 09:18:07

コミュニケーションが生まれるツイートまとめツール

以前以下のようにツイートした話だけど、OSSの開発モデルを社内開発にそのまま持ち込むのは危険。 チーム開発の場合、簡単にコメント返せないようなPR送られた時点で負けだと思ってる。無駄なコードが生産されないよう事前に設計を詰める作業をすべき / “雑なレビュー - ✘╹◡╹✘” http://htn.to/by5or1 https://twitter.com/kazuho/status/431602421068877824 今日一般的に想定される「OSSの開発モデル」はEric S. Raymondの有名なエッセーである「伽藍とバザール」によって解説されたところの「バザール」である。 「バザール」モデルにおいては、多くの改善提案の中から最善と考えられる実装が取り入れられ、コミュニティで共有されるようになる。同エッセーから引用するなら、 ふりかえってみると、Linux の手法や成功の前例は G

ITの世界には「銀の弾丸は存在しない」という合言葉がある。これはどうやら狼やドラキュラを退治するときの道具が「銀の弾」らしく、古典的な名著であり、未だに参照され続けている『人月の神話』という本に収められている論文から来ているらしい。なぜ、「銀の弾丸は存在しない」と言われるのかというと、ある諸問題に関して一気に片付けられるような、そういう解決策は無い。少なくともそれらの問題に関しては泥臭く、忍耐を持って接しないといけないという話だ。川を綺麗にするためには根気よく缶を拾ったりしなければいけないのと似たようなものだろう。 元のドラキュラの話を知らないので、Wikipediaで聞きかじりに語るのだが、そもそも「銀の弾丸」といったところで、その「銀の弾丸」を使う存在というものがいる。ドラキュラの場合、それが「ヘルシング教授」である。ヘルシングといえば平野耕太の漫画を思い出すが、どうやら原作のドラキュ

http://anond.hatelabo.jp/20131003212934 うんうん、そうですね。 何もIT知識のない素人企業を、スキあらば適当な見積もりでボッタクろうとするシステム屋ばかりでここはひどいインターネッツですよ。 世知辛い世の中です。 ●要求は最初になるべく細かく紙に書いて突きつけましょう システム屋を呼ぶときにノー資料ではいけません。思いつくまま口頭で話しても、彼らは都合よく曖昧に解釈するだけです。できあがるシステムはそりゃあもう役立たずですよ。 箇条書きで良いので、システム化したい業務フローは全部書き出しましょう。正常な業務フローだけじゃなくて、イレギュラーパターンもちゃんと明記しておかないと、実装の際に彼ら絶対サボりますよ！ 整合性の取れたそいつで彼らの頬をペチペチ叩いてやれば、彼らはあなたのことを素人のカモとは見なさなくなります。 ●予算感は最初に伝えましょう シ

昔は技術的に出来なかった為に運用でカバーしてきた慣習が残り続けているけれども、実は今の技術で考え直すともっと無駄なく簡単に出来ることって、多くの業界で起きているように思います。 もちろん、ソフトウェアの受託開発の世界でも起きています。ソフトウェア開発を生業とする私たちの会社で考えたのは、昔ながらの商習慣によって様々な問題を引き起こしているのは「納品」ではないか、ということでした。 この記事ではソフトウェアにおける「納品」のもたらす問題と、私たちの会社で解決している方法「納品のない受託開発」について書きました。（自社のウェブサイト用に書いた原稿をブログにしただけなので、それっぽい表現になってます。） 「納品」が引き起こしている問題 私たちソニックガーデンの受託開発では、一括委託を行っていません。ソフトウェア開発における「一括請負での受託開発」のビジネスモデルは、多くの問題を生み出してきたから

ユーザがベンダに対し，ベンダが一方的に開発契約を解除したとして，損害賠償を求めたが棄却された事例。 事案の概要 ユーザＸは，ベンダＹに対し，平成14年9月18日に，Ｘの人材派遣業務に必要なシステムとして２つのシステムの開発を委託した（契約金額の合計は840万円）。 その後，Ｙは，9月25日にはソフトウェアの概要仕様を記載したシステム設計書を交付したが，Ｘは内容不十分であるとして記名押印を拒絶したためシステム設計書は確定しなかった。さらに，下請業者が交替するなどして，翌平成15年9月になってプロトタイプを作成するとともに再度ドキュメントを提出したが，Ｘは，やはり記名捺印を拒絶し，確定しなかった。その後もＹからはドキュメントが提出されているが，Ｘはやはり拒絶した。Ｙは，Ｘに対し「弊社は契約書の範囲内で最後まで誠意をもって開発を行います。」などと記載した書面を交付した。結局，平成16年9月になっ

[居酒屋。サラリーマン風の男がグラスを片手にくだを巻いている。] もうさ、システムエンジニアなんて免許制にしちまえよ。 こんな複雑で難しい仕事、ロクにソフトウェア工学も修めてないトーシロがやろうってのが間違いなのよ。いやおれも含めての話よ？ 何か開発でポカやるじゃん。 ポカやったら、レビューが足りなかったとかさ、チェックが甘いとかさ、なるじゃん。 でもって、誰でもできるようにチェックリスト作ろうとか、手順書作ろうとかって話になるじゃんね。 違うんだよ。 例えばさ、医者の診察考えてみ？あれってチェックリストがあれば誰でもできるの？違うでしょ？ 6年間も大学通ってさ、人のからだの仕組みを隅から隅まで全部勉強して、国家試験パスして、研修医として経験積んで、それでようやく診察できるようになるわけでしょ。 今のIT業界、それもほんとに能力ある人が集まらない、底辺のIT業界って、 医者が足りない、でも

「SIで得るものはあるのか？」 おそらくここ10年以上、日本各地で自問自答された問いでありまして。かくいう自分もその一人であります。デスマの度に、ここまでやる意味はあるのか？赤字の度に、そこまでやる意味はあったのか？　思わなかった人はいないはずです。特にここ数年は、見るもの聞くもの、酷いプロジェクトが自分の周りでも多く、「いいから、そのまま回れ右」という行動パターンの機械学習全開です。（遠い目 他方、「構築をやらないと確実に実装力は落ちる」こういう声もあるでしょう。これもまた真実ではあります。特に、SIの中身丸投げモードのスイッチが入りっぱなしで液漏れ寸前なところは、もはや経験不足を通り越して「リバース・プロキシーって何をするんだっけ？」って真顔で聞くPMの方もいらっしゃる状態もありまして。実際にやらないとわからない、ということは普通におきます。特にアーキテクチャやインフラ周りは、そうなっ