なぜプロジェクトは炎上するのか？炎上しやすい4つの傾向と、炎上を防ぐ3つの対策 - paiza開発日誌
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。 あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。 という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると 「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をし
開発途中で退職したエンジニアの責任 東京地判平27.3.26（平26ワ12971） - IT・システム判例メモ
ソーシャルゲームの開発中に退職した従業員らが，会社から開発頓挫の責任を追及された事例。 事案の概要 Xは，ソーシャルゲーム（本件ゲーム）の開発を目的として設立された会社である。Yらは，Xの設立前から，Xのグループ会社の依頼を受け，本件ゲームの開発に関わり，Xが設立された後には，Xの従業員となって，本件ゲームの開発に従事した。 本件ゲームのリリースは，当初定められていた時期には間に合わず，延期された。 その後，Yらが，いずれも本件ゲームのリリース前に退職したところ，Xは，Yらが開発設計仕様書も作成せず，突然の退職によって本件ゲームの開発が頓挫して損害を被ったとして，主位的に不法行為に基づく損害賠償として，予備的に労働契約上の債務不履行に基づく損害賠償として，5400万円の賠償を求めた。 ここで取り上げる争点 Yらは，信義則上，あるいは労働契約上の義務として，開発設計仕様書を作成する義務があっ
ITアーキテクトの「やってはいけない」：ITpro
ITアーキテクトが知っておくべきアンチパターンを徹底解説 情報システムのアーキテクチャや実装方式を決定するITアーキテクト。データベースやネットワーク，プラットフォームなど，さまざまな技術分野の知識を持ち，全体最適でシステム開発を成功に導かなければならない。しかしそこには，つい陥りがちな「やってはいけないこと」（アンチパターン）が，数多く潜んでいる。そこでここでは，ITアーキテクトが知っておくべきアンチパターンを解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル3～レベル1の3段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■機器増設編 ■業務分析編 ■Windows 7編 ■Android/iPhone編 ■プライベートクラウド編 ■パブリッククラウド編 ■次世代DB編 ■運用管理編 ■プラットフォーム編 ■セキュリティ編
工数管理
プロジェクトを成功させる上で、重要なのは、工数管理です。工数を正確に見積もり、スケジューリングし、また機能追加や修正要求に対して適切に対応することです。不確定な要素が多い中で、プロジェクトを期間内に成功裡に終わらせるのは、奇跡に近いものがあります。 プロジェクトの失敗の多くは、工数管理ができていないことにあります。 客が時間を取れずに要件がまとまらない 頻繁な仕様変更・機能追加 工数の過小評価 無理なスケジュール 仕様のバグ 設計ミス 拡張性のない設計 実装方針ミス 要員のスキルの低さ 無理な要件（性能要件など） など、プロジェクトの進捗を妨げる多くの要因があります。 工数の過小評価 なかでも、工数の過小評価は重大なものです。見積もりの段階ではざっくばらんに見積もってしまうため、実際プロジェクトが始まってみたら作業量は数倍になんてこともあります。また簡単にできると思われたことが、プラットフ
ソースコード解析ツール Understand
派生開発・差分開発では、以下のような課題はございませんでしょうか？ ドキュメントが不足/不十分な状態のため、クラスや関数の処理構造を把握するのに時間がかかる/誤った認識をしてしまう コードが巨大化・複雑化し、修正時/テスト時の影響範囲調査に時間がかかる コードレビュー時に、変更した箇所や確認すべきポイントの洗い出しに時間がかかる ソースコードの解析結果をグラフィカルに表示。ソフトウェアの開発環境を飛躍的に向上させます。 Understandは、C/C++、Java、VB.NET、C#、Python、JavaScript、TypeScript などで開発されたプログラムを高速解析し、プログラムの制御フローや構造、 クラス継承、関数や変数の呼び出し関係といった要素間の関係を、グラフィカルに可視化し、不毛なソースコードリーディングから開発者を解放します。 Understandを利用することにより
ソフトウエア開発のどこまでを設計と呼ぶか？：ITpro
筆者には，現役でソフトウエア開発をしていたころから抱いている疑問がある。それは「ソフトウエア開発にとって，どこまでが設計なのか？」ということだ。その疑問は，エンジニアから記者に転職し，さまざまなSEやプログラマを取材するようになって，ますます深まるようになった。 一般にビジネス・アプリケーションのソフトウエア開発は，設計工程と製造（コーディング）工程に分かれる。ソフトウエア開発者は，設計者（主にSE）とプログラマとに分類され，設計者が書いた「仕様書（設計書）」にしたがってプログラマがコーディングする。仕様書にはさまざまな様式がある。オリジナルなものから，DFD(data flow diagram)，ERD（entity-relationship diagram），最近ではUML(unified modeling language)を使う場合もあるだろう。つまり設計とは「設計者が仕様書を書き
【ハウツー】Webプログラマ待望の最新版「Firebug 1.5.0」を試してみた! (1) Firebug 1.5.0リリース - 注目の更新箇所は | エンタープライズ | マイコミジャーナル
20日(米国時間)、Firebugの最新版であるFirebug 1.5.0がリリースされた。FirebugはFirefoxアドオンのひとつで、閲覧しているWebページのHTMLやCSS・JavaScriptを解析するWebデバッガだ。Firebug 1.5.0ではブレーク機能に関する機能が大幅に追加され、より直感的にデバッグが可能となった。概要やアップグレードの手順については「Firebug 1.5.0、登場」に詳しくまとめられているので併せて参照されたい。 おもな更新点は次のとおり(「Firebug 1.5.0、登場」より引用。詳細はリリースノートを参照)。 機能拡張されこれまででもっとも堅固なインスペクタ機能 新しいデバッグ機能「ブレークオン」の導入 MathMLおよびSVGネームスペースのサポート HTML編集機能の改善 Netパネルのタイミング表示をより正確なものへ改善 XHRにお
MySQLに纏わる10の都市伝説
誰の口から飛び出したのかは定かではないが、巷ではMySQLにまつわる様々な「都市伝説」がまことしやかに囁かれているようだ。恐らくMySQLに対する理解が低い人や、MySQLがあまり好きではない面々によってFUDっぽく言われているのだと思うが、世の中にはそのような「都市伝説」を真に受けてしまう人が居るのもまた事実であである。MySQLにおける昨今の開発スピードには目覚ましいものがあり、MySQLは性能・安定性・使い易さ共に進化し続けている。（特に先日リリースされたMySQL 5.5は性能・安定性・使い易さを両立している優れたバージョンだ！！）しかし「都市伝説」で語られることは総じて「MySQLはダメな子ちゃん」であるという烙印を押すものばかりであり、MySQLerとしてはそのような言われ無き汚名を全身全霊をもって晴らさなければならない使命を背負っている。そこで、今日はMySQLについて語られ
ネットワーク側から見たヨドバシカメラ問題 - なぷさく
ヨドバシカメラのサイトがリニューアルに失敗してレスポンスが著しく低下している。ただでさえ重いところに、「ほらほらみてみて、重くなってるよ！見に行ってみてよ」なんてGIGAZINEが煽ったり、yahooニュースに飛び火したりしてさらにリクエストが増えて、瀕死の重病人いよいよまさに往生せんとす、といった雰囲気である。構築した会社は今頃針のむしろだろうし、ヨドバシ側の担当者もきっと現場からは「使い物にならんぞ！」と突き上げを食らい、上からは「なんでこんなところに依頼したんだ！」と怒られて社内キャリアはぶっ吹っ飛んだだろうし、まあ他人事ながら同情申し上げる。すでにあちこちで、CMSが腐ってるとか構築会社の社長がすごいとかいろいろ言われているが、基本に立ち返って外側から見える現象をひとつずつチェックしてみよう。1. DNSは問題なし大阪吹田にあるどっかの会社のサーバでDNS引いてみた。 $ dig
[okyuu.com] ソーシャルITメディア
マイミク認証対応のRP作ってみませんか? 特集：いますぐ使えるOpenID｜gihyo.jp … 技術評論社の内容に加えて SSL 接続でのサーバ証明書の検証,mixi のマイミク認証についても解説されている。
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
肥え続けるTomcatと胃を痛めるトラブルハッカー (1/3) - ＠IT
肥え続けるTomcatと胃を痛めるトラブルハッカー：現場から学ぶWebアプリ開発のトラブルハック（8）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） メモリリークと聞いて、良いイメージを思い浮かべる開発者は少ないだろう。経験したことのある人にとっては、思い出したくない過去の記憶がよみがえるかもしれない。もしかしたら、その単語を聞くだけで胃が痛くなる人もいるかもしれない。筆者もかつてはその1人であった。 前々回の記事では、WebサーバとTomcatの間の接続において、スレッド数の不整合により発生したトラブル事例を、前回はTomcatとDBサーバの間のトラブル事例を紹介した。今回もTom
疑りぶかいあなたのためのオブジェクト指向再入門
このページは、「オブジェクト指向再入門」とあるように、 オブジェクト指向を勉強しようとして挫折した人向けの文書です。 タイトルに「疑り深いあなたのための」とありますが、 これは決して揶揄して言っているわけではありません。 現在世間に蔓延しているオブジェクト指向の説明では、 むしろ納得しない方がまともだとさえ思えます。 「オブジェクト指向を使えば、生産性が飛躍的に上がり、 プログラムの見通しがよくなり、再利用性も高まる」と聞かされて、 「ホントかあ?」と思える人は、一度読んでみてください。 本稿の対象読者は「既に他の手続き型言語を習得しているが、 オブジェクト指向が理解しがたいと感じている人」です。 言語としてはJavaを使用します。 手続き指向型の言語の例としては、C言語を使用します。 特にCに習熟している必要はないようにしたいのですが、 Cで言うところの「構造体」「ポインタ」「動的メモリ
「渡された仕様書を実装するサラリーマンプログラマ」の悲哀
@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − ＠ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ
I, newbie » プログラマへのお願い
インストールに必要な要件を書いてください。なにが必要で、なにがオプションなのか書いてください。 配布物のファイル名はてきとーにしないでください。package-$major-$minor.tgzでなぜだめですか。package-$major-rc4-$date-beta.tgzとか嫌がらせですか。 同じファイル名で違う内容の配布物を再リリースしないでください。hash値ってファイル名とその内容に対して作成されるんですよ。どんな小さな修正でもバージョンを上げてリリースしてください。 インストーラを再発明しないでください。対話的なインストーラだからインストールが簡単ですよって、人間がインストールすると仮定しないでください。そういうのはパッケージ管理システムに任せてください。 エラーをSTDOUTに出力しないでください。通常の出力はSTDOUT、エラーなどはSTDERRであることが期待されていま
サイレントシステム トップページ
オンラインショップをご利用の方へ 個別にメールでやりとりをして代引きで発送可能ですので ご希望の製品があれば shop@silentsystem.jp 宛にご連絡ください
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして: 佐藤正美: 本
プロジェクトメンバーが必ず押さえておくべきマナー～ブランチ戦略の基本
IE ToolbarをC#で作る