【バグ管理の作法】Trac徹底活用！ 第2回：なぜTracの導入に失敗するのか？ 著者：masuidrive 公開日：2007/12/13（木） Tracの導入現場の今 「第1回：なぜバグ管理システムを使うのか？」でも紹介したように、TracはSubversionと連携するオープンソースのバグ管理システム（BTS：Bug Tracking System）だ。Ruby on Railsなど多くのオープンソースプロジェクトで利用されており、最近では商業開発でもっとも多く使われているツールの1つになっている。 その一方で、Tracの導入効果が出ていないケースも多々ある。それはなぜだろうか？ Tracの肝は「チケット管理」の運用にある！ Tracにはコンテンツを管理するシステムとしてのWiki、Subversionなどのバージョン管理システムのファイルをWebから閲覧するための「リポジトリブラウザ

プロジェクトが上手くいくには以下の４つの要素が必要だと思っている。 １・用件が定義されている。 ２・用件を満たせる人材が用意されている。 ３・トライアル期間を含めスケジュールに余裕がある。 ４・状況を見て、正しく舵を切れるリーダーがいる。 自分はゲーム屋だからそれに準じて書くけど、多分どこも似たようなもんじゃないかと。 それぞれ、何故それが重要な要素だと思っているか、それが満ちていない場合どうごまかしてるかを書いて見る。 １・用件が定義されている。 ゲーム業界でグズグズの残業地獄になり易いのは「用件が定義され難い」から。 １回でも大手の下請けやったらわかるけど、完成品見て「なんか違う」でリテイクを食らう。 そこまで酷くなくても、普通に現場内でも用件定義の甘さによるリテイクはモリモリ発生する。仕様書が甘い、甘いのを解っても質問がなされない。そもそも横の情報流通が甘い。落ちてる情報を拾いにいか

SVN::TracWiki #0 Posted by Gosuke Miyashita Sat, 21 Apr 2007 19:55:57 GMT SVN::TracWiki というツールをつくってみました。svn repos はこちら。 何をするものかというと、Subversion の post-commit スクリプトとして動作して、コミットされたファイルからテキストを抽出、そのファイルの実体へのリンクを付加して、Trac の Wiki へ自動ポストするというもの。 具体的な例としては、PowerPoint ファイルをコミットしたら、そのファイルからテキストのみを抽出して Wiki へ自動ポスト。こんな感じで。 これで何がうれしいかというと、Subversion で管理している PowerPoint ファイルを、Trac 上で検索ができるようになります。こんな感じですね。元ファイルへ

「従来の技術を使って高品質な製品を低コストで“作る”だけでは不十分。新しい技術とそれに基づく新しい製品を“創る”必要がある」。日本企業が進むべき方向として、こう指摘されることが多い。ではどうやったら新しいものを創造できるだろうか。 1つの手として、異なる専門分野の人を集めて意見交換させるやり方がある。同じ専門領域の研究者や技術者だけで議論していても新しいアイデアはなかなか出ないからだ。しかし今度は、創造性の高い研究者であればあるほど共同作業が苦手であるという問題に直面する。 こうした問題への対策として筆者が思い出すのは、著名なコンピュータ・アーキテクトのアラン・ケイ氏が米ゼロックスのパロアルト研究所（PARC）について語った話である。ケイ氏はPARC創設時のメンバーで、現在のパーソナルコンピュータの原型を創った人物として知られている。 筆者はケイ氏が話した内容をIT専門家向けサイトで紹介

SEEDS株式会社(http://www.seeds-inc.jp/)のホームページを読んでいたら、ディレクター氏による「忙しくて眠れない」話があった。サビ残がどうとか、生産性がどうとか、そんな議論とは次元の違う、清清しい文章。 Q4.　逆に、“辛い・しんどい” 　と感じるのは、どんな事に対してですか？ 仕事が終わらなくて、眠くても眠くても眠れない時です（笑）。 〜〜〜中略〜〜〜 一ヶ月会社に泊まり込み、毎日睡眠時間４時間ほどでひたすら仕事をし続ける…その辺りをリアルに想像してみて、「ゲェー」と思った人は、この仕事は向いてないでしょう。 〜〜〜後略〜〜〜 http://www.seeds-inc.jp/site/staff/kamiya.html 向いてるかどうかはともかく、僕もだいたいそんな感じになる。間違いない、ゲームの花は夜開く。 でも、他業種の人から「なんでそんなに忙しいの？」と聞

List ●ポストモーテム 間違った反省会からの脱却（2006/1/1） 「銀の弾丸」になってしまう仕組み（2006/1/1） 間違った反省会からの脱却 TSP（Team Software Process）を原書で取り寄せて中を覗いてみて目に付いたのは「Chapter 10 　The Post Mortem」というタイトルでした。３０数年、この世界にいて初めて目にするものでした。辞書で調べてみると「検死解剖」という意味だと分かって妙に納得したことを、いまでも鮮明に覚えています。同時に「どうしてこんなタイトルが考えつくのだろう」とも思ったものでした。（“やっかみ”が含まれていますね） プロジェクトは、多くの場合、満足な結果で終わっていません。途中で仕様変更の頻発に見舞われて混乱し、さらにテストの段階では品質問題で大幅な手戻り工数が発生し、最終的に納期を数ヶ月オーバーして終了するのです。もち

Your system administrator has blocked your computer or device. Please contact the system administrator.

生産理論のひろば UPDATE ・ No.6　生産ラインの基本要素と基本特性　(NEW) ・ No.5　生産ラインの最も重要な特性はなにか？ (NEW) ・ No.4    帰納的アプローチと演繹的アプローチ ・ No.3　TPS導入失敗の責任者は誰だ！ ・ No.2  Lean、シックス・シグマ、SCM・・・欠けているものは？ ・ ひろばのたわごとNo.1　ユニバーサルな生産理論の構築をめざして ・ 不確定性についてアップデートしました。 生産理論の主要要素と範囲 生産理論について、簡単に触れておきます。生産理論に似ているもの、あるいは関連するものを挙げれば、生産管理、生産技術、工程管理、在庫管理、、、などが思い浮かびます。品質管理や原価管理なども含むでしょう。少し広く捉えれば工場管理やサプライ・チェーン・マネジメントなども関係があります。では、生産理論とは？ 「ものづくり」に必要な主な

『ソフトウェア開発２０１の鉄則』の解説 はこちら 長く IEEE Software 誌の chief editor を勤めている Alan M. Davis 氏の本に、「201 PRINCIPLES OF SOFTWARE DEVELOPMENT」（邦訳名：「ソフトウェア開発２０１の鉄則」松原友夫訳、日経ＢＰ刊、\1,600 見当）という名著があります。いわゆる「ベスト・プラクティス」の集大成で、著者以外にも多くの人の「Principle」を集めたもので、ソフトウェア・エンジニアだけでなく、マネージャーにとっても、とても参考になる本と私は評価しています。ただ、この本は、２０１項の「Principle」を集めたもので、それぞれの原理を味わい、読者自身の仕事に活かすには、多くの知識と経験を必要とするため、おそらく、「もっとなこと」という感想だけで終わってしまう可能性があります。そこで『ＳＣだよ

Index：『ソフトウェア開発２０１の鉄則』の解説 『ＳＣだより』のインデックス・ページのサイズが大きくなりすぎましたので、『ソフトウェア開発２０１の鉄則』の解説のインデックスをこちらに移しました。 この項は、今回（第５３回）で最終回です。

将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップのスキルは生まれつきのものか この連載も今回で5回目になりました。連載の趣旨は、プロジェクトマネージャ、およびプロジェクトマネージャになりたい人のための心構えを解説することです。いい換えれば、プロジェクトマネージャに必要な「リーダーシップ」の解説を意図しています。 連載開始以来、さまざまなご意見をいただきました。リーダーシップに関するご意見の中には、「前向きにリーダーシップを身に付けたい！」というも