なんでテストフェーズに入ると不具合を起こしまくるのか。ここでスムーズに行けば納期に間に合うのにどうして大量の修正に時間をとられるのか。そんな風に思うプロジェクトマネージャーは多いはずだ。僕はPMでないが今すごく思っている。なんせ自分の作った機能ではないところの不具合をまんべんなく割り振られているからだ。そのおかげで対応不具合数のカウントだけ積み上がり、僕がバグを出しまくっているみたいに見える。僕が出したバグに対応するのはいいが、他人の不具合まで回されたんじゃ困る。 思うにプログラマというのは川で言うところの最下流に位置するので、川上から工場排水やゴミが流れてくると、一番汚染されるのが下流域である。そのためプログラマが不具合を出しまくるのは、プロジェクトの失敗の全てがそこにつまっている証拠だ。10年もエンジニアをして、少なくとも日本のIT環境で決定的にできていないものが見えてきた。 おおむね
日本のIT業界の関係者は、自分たちの業界が建設業界によく似ていると思っている。さらに心ある人は「ITはハイテク産業のはずなのに労働集約型の建設と同じだから、日本のIT業界はダメなんだ」と嘆く。確かに多重下請け構造は建設業界にそっくり。米グーグル(Google)や米アマゾン・ドット・コム(Amazon.com)などの巨大プラットフォーマーが主導し、知識集約型あるいは資本集約型の産業として進化を続ける米国のIT業界と比べて、ため息をつくしかない。 しかし、建設業界の人から言わせると「冗談じゃない!」ということらしい。以前、大手ゼネコンのCIO(最高情報責任者)から聞いた話だが、この人はIT業界の多重下請け構造のひどさを知ったとき、あきれ果てたという。IT業界で大手ゼネコンに相当する大手SIerが元請けとなったプロジェクトでも、設計やプロジェクトマネジメント(建設業では施行管理)がいい加減だし、
どうもしんざきです。曲がりくねったSQLを読んで、モニターを威嚇しつつ不要なjoinを削除しまくる仕事で主に生計を立てています。 こんなまとめを読みました。 某大手企業の本社を辞めるという人『古い会社は社内の体制も古い。癒着してるシステム会社も全然ダメでテキストの左揃えを右揃えに変えるだけで300万取られる』(現在は非公開) ワイの妹ト○タの本社やめて転職するらしいんだけど、「古い会社は社内の体制も古くてダメ。癒着してるシステム会社も全然ダメで、テキストの左揃えを右揃えに変えるだけで300万取られる上、バグ(仕様)だらけで仕事にならない」って言ってたの印象深い。 これ、もともとの話の情報量が全然なくって、何のシステムの話かも分からなければシステムの規模も分からないので、300万が高いのか安いのか妥当なのか、というのは勿論なんとも言えないです。 もしかするとこれはぼったくり案件なのかもしれま
どうもしんざきです。好きなギャラリーフェイクの単行本は23巻です。 最近、「理不尽なクレーム」と「それを受け入れてしまう組織」についての議論を観測する機会が何回かありました。 直近記憶に新しいのは、消防車でうどん店に寄って昼食をとった消防団員が注意を受けていた件で、「別にいいんじゃね?」という声も結構上がっていたと記憶しています。 消防車でうどん店寄る 一宮市消防団員7人 愛知県一宮市消防団の50代の分団長を含む男性団員7人が、制服姿のまま消防ポンプ車で市内のうどん店に行き、昼食を取っていたことが分かった。市消防本部(同市緑1)は25日、全25分団長に口頭で注意を促した。近く文書で全団員にも呼び掛ける。 同本部は、消防車は消防活動以外に使わないと市内の消防団と申し合わせている。同本部によると、16日午前9時半から同本部で消防操法大会の説明会があり、出場予定の団員ら50人が大会で使うポンプ車
ネット上ではSIer批判=技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。 自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。 なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。 対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか? 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
この1度目のシステム障害を、対応ベンダのうちの1社として見ていた者です。 確かに、ここまで掘り下げるのは大変だったでしょう。しかしながら、例えば、実務レベルの暗闘や困惑は 不十分というか、日経という立ち位置からか書かれていません。 私自身は別プロジェクトに居ましたが、ATM系の開発を社(当時)が請け負っており、そのマネージャーが 懇意の同僚でした。彼は、オブザーバとしてながら、実際の実務レベルミーティングに参加していたのです。 真の原因は、統合するシステムそのものの設計書・仕様書レベルで、負け組(=新システム開発に乗れな かったカイシャ)が、意図的なイヤガラセで、「現状」の仕様や設計を開示しなかったことにあります。 システムというのは、使えば必ず手直し(所謂、バグだけでなく、法律改正に対応する修正もあります)が 多々発生します。都度、「その場しのぎのパッチ当て」から「キチンと予算を組んだ修
先日、会社のチームリーダーと面談を行った。 リーダーから「この会社で働いていて楽しい? 困ったことはない?」と尋ねられ、 僕は即座に「すごく楽しいですよ。日本で働いていた会社とは大違いです」と答えた。 「日本では毎日2時間から3時間残業するのが当たり前でした。 ときには週末を潰したり、徹夜でバグ修正を行ったりすることもありました。 それに比べてこの会社では残業が全然ないし、毎日適度な作業量を与えられて集中して仕事ができるから最高ですよ」 彼女はこれを聞いて、驚いたような呆れたような表情を見せこう語った。 「その日本の会社、マネジメントがひどい。 いくら長時間仕事をしたところで仕事が終わるなんてありえないのに」 いくら働いても問題は無くならない 「それは生産性が落ちるからってことですか?」と尋ねる僕に、彼女はこう続けた。 「例えば、いま未解決のバグが10個ある。 すべて直すのに80時間かかる
日々流れてゆく膨大な情報量の中からおいしいネタを敏感に察知し、ネット界隈を賑わせてくれるWeb業界の異端児・村上福之氏。同氏独自の経験と価値観から、「キャラ立ちエンジニア」の思考回路を紐解いていく。 株式会社クレイジーワークス 代表取締役 総裁 村上福之(@fukuyuki) ケータイを中心としたソリューションとシステム開発会社を運営。歯に衣着せぬ物言いで、インターネットというバーチャル空間で注目を集める。時々、マジなのかネタなのかが紙一重な発言でネットの住民たちを驚かせてくれるプログラマーだ 先日、ソフトウエアエンジニアの中で、この話題がバズってましたね。有名なコミッタさんを雇おうとしたら、会社の偉い人が「プログラマーに年800万円なんてのは馬鹿げてる! プログラマーに出せるのは年400万円までだろう!」と言い放ったという話です。 >> 著名なOSSコミッタを年収400万円で雇おうとした
よくある「開発スピードを優先させるか技術的負債をなるべく発生させないようにするか」という議論、ケースバイケースだとは思うけど、ことプロダクトの立ち上げ段階では、悩んだら「開発スピード」を優先させるようにするべきだと自分は思ってる。 理由は 市場は待ってくれないから。どんなにいいプロダクトでもユーザーに使われなくては意味がないのと、プロダクトを取り巻く外部の環境(競合プロダクトや市場でのニーズ)は自分ではコントロールできないものなのに対して、技術的負債については適切に管理されていればコントロールしながら返済できるから。もちろんバランスも重要だとは思うので、どんな技術的負債も生み出していいかと言われるとそうではないけど。 というわけで自分は「ああこれクソコードだけど機能は満たしてるからそのままリリースしたいなぁ」というのはだいたいクソコードのままリリースしています。(こうやって免罪符を作ってい
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とかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く