Amazon.co.jp： デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
第4回 こんなテスト担当者はイヤだ！ | gihyo.jp
永い間テストに従事していると、日常生活の中でもある種の「職業病」とも思える行動をとっていることがあります。 たとえば 目の前に「ボタン」があると押したくなる。特に2つ以上あると、同時押しをしたくなる。 製品を買っても、常にエラーケースを考えたり、エラー操作をしたくなる。 いつでも再現確認できるように、操作手順を覚えている。 カタログのスペック表をずーっと見ていられる。 ……等々。 今回は、そんな「ソフトウェアテストな人」をご紹介しながら、「人間力」を考えてみます。 “真（円）”を追求する いつも通りに筆者が同僚のM氏とテストを実施中、ふとM氏を見ると何やらごそごそと。よく観察すると、トレーシングペーパーを取り出してディスプレイにあてて書き込んでいる様子です。 筆者： 「何しているの？」 M氏 ： 「今日は、Circleコマンド（円表示）のテストだから、表示の確認だよ」 筆者： 「（筆
【連載】実践ソフトウェアテスト考現学 (1) 調査データから見た日本人が作るシステムの質 | エンタープライズ | マイコミジャーナル
立場によって異なる「もどかしさ」 システム開発を発注するユーザー側でも、受注する側でも、ほとんどの方は業務の中で日常的に、何かしらのもどかしさを感じていることでしょう。 とはいえ「〜がもどかしい」の「〜」の部分に込められる悩みは人それぞれで、当然ながら立場によっても異なるはずです。 例えば、同じ悩みでも発注者と受注者との間で、相手に対するもどかしさの表現は、上のように変わってくると思います。 発注者側のもどかしさ受注者側のもどかしさ はなからサービスインに間に合わせようという意気込みが伝わってこない システム開発のプロであるはずなのに、「欲しいシステム」を提案してくれない 機能として十分な実装ができてないのに、修正を要求すると機能追加や変更扱いにしたがる いつまでたっても仕様を確定させないから、サービスインに間に合わなくなる システムに何が必要なのか、ユーザー自身が整理しきれていない 「あ
納入したソフトの検収を速やかに終えてもらう方法
皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。 ソフトウェア開発は、いくらでもいちゃもんが付けられる 残念ながら、ソフトウェア開発にはバグが付き物である。以前は、「コンピュータ業界はおかしい。欠陥（バグ）があるものを平気で納品する」などという非難をよく聞いた。いまでも同様な考え方をする人がたまにいる。ソフトウェアにバグが発生するのは、ある程度しょうがないということは、裁判所の判例でも認められている。１つ１つ手作りで違うものを作っていくというソフトウェア開発の特性を考えると、バグはやむを得ないことだとも思える。し
笑えないジョーク - 現場からの「協働革新」
友達からソフトウェア開発のステップについてのジョークがメールで送られてきた。ソフトウェア開発の工程は次のようであるらしい。 1. プログラマがコードを書く。バグはないと信じている。 2. 製品テストが行われて30個のバグが発見される。 3. プログラマは20個のバグを修正し、残り10個はバグではないとテストチームに説明する。 4. 再び製品テストが行われ、バグ修正の結果5つの機能が正しく作動しなくなっていることが発見される。さらに15個の新たなバグが発見される。 5. 上記の工程3〜4を数回繰り返す。 6. マーケティング部が楽観的な開発計画に基づいた製品発表を行ったことや、営業部からの圧力により、製品が時期尚早に出荷される。 7. ユーザにより100個のバグが発見される。 8. プログラマが他社に転職する。 9. 緊急で新たに開発チームが組織され、ほぼすべてのバグを修正する。 その過程で
「ITエンジニアは職人気質を取り戻すべき」
「ソフトウェア開発の匠」。このタイトルには、ソフトウェアエンジニアは現代の匠（たくみ）になるべきだという筆者の思いを表現している。現在のソフトウェア開発は、残念ながら多くの人が過去の職人気質（かたぎ）を捨て去り、サラリーマン化しすぎている。ビジネスの価値を高める最適なソフトウェア開発の姿について、自ら描くことをしていない。 しかし、ただ旧来の職人気質を取り戻すだけでは駄目なのである。ヨーロッパのマイスター（匠）のように尊敬されるためには、ビジネスを知り、ビジネス価値を高める職種になることが必要である。それが、ITエンジニアの目指すべき匠である。そのような人材像を「ソフトウェア開発の匠」とし、本連載では、そこに近づくための考え方や解決法を読者にお伝えできればと思う。 まず第1巻（連載第１～2回）では、現在のソフトウェア開発手法が未熟であることを、さまざまな問題を例に述べる。そして、これらの問
第1回 Tracをオススメする，これだけの理由：ITpro
Tracの便利さに惹かれるが，インストールに煩わしさを感じ，Tracを簡単にインストールできるTrac Lightning（旧Trac月）の開発を行う。また，日本のTracコミュニティであるShibuya.tracにてユーザー補完プラグインなどのプラグイン開発にも携わる。 チーム内のタスクや分散開発におけるタスク管理の手段として，プロジェクト管理ツールのTracが注目を集めています。Tracは，Ruby on RailsやSpring IDEなどでも利用されています。本連載では，開発現場を交通整理するために，Tracを利用したプロジェクト管理の効率化を，Tracの基礎から紹介していきます。 ソフトウエア開発において，プロジェクト管理はガントチャート・ベースで行われることが多いでしょう。しかし，ガントチャート・ベースの管理では，詳細を報告するために作業報告書を別途作成する必要があります。 ま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
