IT業界の「デスマーチ」がもたらすものは、長時間労働や人材の疲弊だけではない。もっと深刻だ。
IT業界が外部の人間から敬遠される理由の一つに「デスマーチ」がある。 ほとんど実現不可能に思える無理なスケジュールで、深夜におよぶ残業、休日出勤の連続、人海戦術でほとんど役に立たない新人までが駆り出され、終わりの見えないプロジェクトの完成にひた走る、これがデスマーチである。 そこではプログラマは一人また一人と過労に倒れ、うつろな目でキーボードを叩き続けるプログラマの連続勤務時間は20時間を優に超える、といった光景が見られる。 このようなデスマーチについて、人材の疲弊やそれに伴う退職など、ITベンダー側の不利益が語られることは多いが、クライアント側の不利益、もっといえばプロジェクトの成果物自体がデスマーチで台無しになってしまうことはあまり知られていない。 デスマーチのきっかけ 営業の無謀な受注、仕様の調整不足などで、システムの実装行程が確保できず、どうやっても通常の開発体制ではシステムの完成
デスマーチの恐ろしさはヤバい
全員真面目で有能でいい人ばかりが毎日毎晩全力で仕事をしているのに、何ヶ月経ってもものがさっぱりでき上がらない どういう理屈なんだあれ
硬直しきったプロジェクトで働いた思い出 - tehepero note(・ω<)
2015-04-29 硬直しきったプロジェクトで働いた思い出 ふと昔いたプロジェクトについて思い出したので書く。 経歴 2006-2009 中小SIer 2009-2012 フリーランス 2012-現在 サイバーエージェント 今日の話は中小SIer時代のこと。本エントリでは所属会社と呼ばせてもらう。 所属会社について 社員30名くらいで、当時で設立8年目くらい。 自称ベンチャー企業 自社製品もあったが、基本客先に常駐するスタイル。いわゆるSES契約というやつ。月に一度、帰社日というやつがある。 プロジェクトジョインの経緯 2008年当時、体力の無い所属会社はリーマン・ショックの影響で火の車。1・2年目社員の多くが社内失業者に。 会社としては、社内失業者を何とか現場に出したい。3年目以降で会社の主力メンバーと共に、社内失業者がバーターでジョインできる現場が優先された。 所属会社の1年目若手（
泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
ソフトウェアの開発にかかる時間の見積を廃止したいプログラマーたち | スラド デベロッパー
ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。 記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
2人の若者
2人の若者が同じプロジェクトにアサインされました。 一人はできる君、ひとりは残念君と言いました。 そのプロジェクトは優秀なPMとモチベーションの高いメンバーで構成されており、スケジュールやタスクなど大変見通しがよく、整理された進行状態を保っていました。極楽プロジェクトと呼びましょう。 できる君はプロジェクトの全体を把握し、自発的に自分にできそうなタスクを探し、プロジェクトに貢献しはじめました。すぐに重要なタスクを任されるようになりました。 残念君はプロジェクトを見通せておらず、自分に何ができるかも分かりませんでしたが、PJメンバーが彼にちょうど良いタスクを探したり作ったりして、彼に仕事を振っていました。残念君も頑張ってはいますが、重要な仕事はまだできませんし、PJのリソースを奪っている面も否定できません。 ある日残念君に転機が訪れます。ダメなPMが仕切り、モチベーションの低いメンバーが集め
人事給与システムの怪
2014.08.11 人事給与関係業務情報システムというものがある。 人事院が管理する省庁の人事、給与、共済、統計などの業務のためのシステムだ。 もともとは分散型システムのはずだったのが、途中で方向転換して、集中型システムになった。 １１府省が利用し(府省と言っても宮内庁、衆議院、会計検査院、公正取引委員会なども使っている)、平成２８年度末までには最高裁判所や参議院を含め、すべての省庁が利用することになっている。 元々の計画では初期投資に８４億円、毎年の運用経費が１５億円というはずだった。 しかし、初期投資の予算から各府省のシステム移行経費４２億円が漏れていたりして、結果的には１４３億円の初期投資と２７億円のランニングコストがかかっている。 しかも平成２２年度に導入されたシステムなのに、いまだにソフトウェアに大きな問題がある。 例えば、人事の発令に併任がかかっていたり、あるパターンの発令が
コメント欄 - （追記しました）現場の人からシステムさんに一言、いや二言三言いわせてほしい - 矛盾銀行株式会社
2013-12-06 現場の人からシステムさんに一言、いや二言三言いわせてほしい 日常業務四方山話 読んだ。 エクセルでできることができない何百万のシステム・・ いや、そうなんだよ。そうなんだよ。２回も言ってしまった。 ぼくもそう思ってた。ぼくもシステムに関してはじくじたる思いがあるので、ちょっと言わせてほしい。 ぼくもこの増田さんと同じように、社内のシステムさんとあれこれ打合わせすること多かったんだけど、いつも「それってExcelでできないのかね」と思ってた。Excelにはデータベース仕様あるじゃん。VBAあるじゃん。WEBクエリあるじゃん。素人感覚で「ちょいちょいっ」てできそうじゃん。 いや、本当にExcelで作ってほしいと思っているわけではないし、ましてExcelを作ってほしいわけではない。ただ、「現場の人間」の感覚からすると、システムさんのことって本当によくわからないのですよ。だか
紙でできた巨塔（1） プロジェクトはもう死んでいる：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 「なんだ、これは？」 静かなオフィスに机を叩く音が響いた。 北斗野 健（きとや けん）。先日、彼はここ、竹尾ゼネラルカンパニーのプロジェクト「G7」の追加要員として、派遣会社から仕事を請け負った。普段はサーバの構築、管理を行っているが、スクリプトの類を組むのが得意で、コードも読めた。そして、ドキュメントの作成には定評があった。 京都の事務所から東京へ出向が決まり、単身、東京へやってきた。もともと1人暮らしだったので特に困ることはなかった。そして竹尾ゼネラルカンパニーには、以前、難局を共にした同じ派遣会社の先輩、開発者の南野 将（みなみの しょう）がいた。また彼と仕事ができることが楽しみであった。 プロジェクト「G7」とは、防衛庁より受注したシステムの構築案件だ。サー
派遣PG時代の思い出
@vjroba 某N社で「メソッドを作ると処理が上下に飛んで可読性が落ちるので、出来る限り一つにまとめてください」と言われたことがある。僕は300行で挫折したが、1万行メソッドを書ききった強者がいた。クラスを作るには申請書が必要だった。 2010-05-11 12:42:06
DeclineAndFallOfAgile - アジャイルの衰退と凋落
DeclineAndFallOfAgile - アジャイルの衰退と凋落 目次 この文書について アジャイルの衰退と凋落 最近の状況 Scrum の役割 Scrum の誤用 君のやりかたは間違っている 真っ最中での失敗 アジャイルの衰退と凋落 この文書について "The Decline and Fall of Agile" の日本語訳です http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... James Shore アジャイル運動の衰退や凋落について話すのはおかしなことだ. 今やとても人気があるものなのだから. けれど本当のところ, ここ数年のアジャイル運動は、衰退の途にあると私は思う. 最近の状況 自分の商売がここ数年で変化していることに私は気がついた.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
上司「お前のプログラムはモジュールと関数が多すぎるからもっとグローバル変数とか使ってまとめろ」
基幹システム プログラマー不要 富士通がソフト、開発費４割減 ：日本経済新聞
オフィスコミュニケーションについて