インストール

easy_install でインストールですね。

> easy_install http://trac-hacks.org/svn/calendarpopupplugin/0.11/

とりあえず使ってみる

wiki のHowto をみて設定してみます。

「まずは、ポップアップを表示したい input field のHTML-IDとファイル名を特定しましょう。」。。。もしかして、自分で1づつ指定しないといけないんですね。。
とりあえず、例の通りにやってみます。

[calendarpopup]
ids=duedate=MM/dd/yy  << これがDOM ID
files=milestone_edit.html << これがファイル名

どうやら、マイルストーンの期限にポップアップをつけるようです。

設定したら、マイルストーンページを確認してみます。

お、でました。

MM/DD/YY で入力できましたね。

さらに設定して使う

他に日付入力を探してみたんですが、意外とないです。。
マイルストーンの完了日は 時間も入力することになっていますが、ここにもポップアップを設定してみます。

今度は管理画面から設定

以下のように入力します。
files
- milestone_edit.html
ids
- completeddate,duedate=MM/dd/yy

フォーマットが。。。。そのまま更新したらエラーになってしまいました。。
フォーマットは id ごとに指定していくことになっているみたいです。

files
- milestone_edit.html
ids
- completeddate=MM/dd/yy,duedate=MM/dd/yy

チケットのカスタムフィールドで期限とか運用しているととっても便利な気がします。

何がすごいと言ってるかというと、チケットへのファイルの添付をチケット作成前にできる。ということみたいです。
たしかに、tracではチケットに添付ファイルをつけるときは一度チケットを作ったあとに添付しないといけないので、画像を添付するときは
1. チケット作成
2. 画像ファイルを添付
3. 画像ファイルを展開するマクロ [[Image()]] をチケット本文に追加
みたいに面倒な感じでした。

0.11 版だけしか提供されていないですが、インストールしてみます。

インストール

まずはeasy_install コマンドでインストールします。

> easy_install http://trac-hacks.org/svn/awesomeattachmentsplugin/0.11

trac.ini には [components] セクションに2行書き足します。
この辺、マニュアルの通りですね。

trac.ticket.web_ui.TicketModule = off
awesome.awesomattachments.* = enabled

管理画面でプラグインを確認

enableになっています。

では、チケットを作ってみましょう。
チケット作成画面にアップロード用のフォームが追加されています。

プラスボタンで複数添付もできるようです。

画像をアップロードすると、なんと本文に自動的に Image マクロが追加されました。うーん、これは便利。

そんなわけで、チケットを作ると、画像が開いた状態で表示されます。

これはなかなか便利かもしれません。

Awesome Attachments Plugin

チケット作成時にファイルの添付をすることができる : プラグインページ

Selectable calendar pop-up

任意の入力フィールドにカレンダー入力を追加できる : プラグインページ

あなたのチームでは朝会はやっていますか?
会社やチームによってやり方は異なると思いますが、アジャイルソフトウェア開発手法を取り入れている ciklone 開発チームでは毎日朝会をやっています。

アジャイル開発の朝会といっても特別なことは何もなく、以下の点に気をつけて開催しています。

朝会のポイント

• 立ってやる(スタンドアップミーティング)
• 毎日決まった時間に開催する(20分以内)
• 問題解決の場ではないことを説明
• 話すこと
  • 前回から何をやったのか?
  • 今日何をするか?
  • 気付いた点・問題点
  • (あれば)良いルール、やってうまくいったこと

仕事(開発)を始める前に、「定例、立って」がポイントだと思います。
進捗を確認する場ではないので、リラックスして話すことから始めるようにしています。

それでは、これから紹介するダッシュボード機能とは、チームリーダーやプロジェクト管理者にとって便利な機能です。もちろん、チームメンバーも。

プロジェクトの活動状況（活発なのか、そうでないのか）を一覧で確認できます。
アクセス方法は ciklone にログイン後、右上のメニューから「ダッシュボード」をクリックします。

次に簡単な機能を紹介します。

1. スター

複数のプロジェクトがあるとき、スター付けることができます。スターは特別な意味をもちます。重要なプロジェクトや比較したいプロジェクト、自分がメンバーであるプロジェクトにスターをつけることで、すべてのスター付きプロジェクトを確認することが出来ます。あなたのプロジェクトのスターをクリックしてみてください。

2. プロジェクト活動状況

プロジェクトの1ヶ月(または、1年)の時間でプロジェクトの活動状況をグラフで見ることが出来ます。

• wiki ･･･だれでも編集できるWikiシステムでページを作成・更新した状況を表示
• チェンジセット･･･バージョン管理システムを使ってソースコードやドキュメントを更新した状況を表示

• チケット･･･バグやタスクを作成、更新した状況を表示

3. 機能へのショートカット

あなたのプロジェクトにある各機能へショートカットするためのリンク集です。

4. プロジェクトの統計情報

あなたのプロジェクトの統計情報が表示されます。表示される情報は、ドキュメント/Wiki、マイルストーン、コミット、チケットの簡易統計が表示されます。

sugimotoです。

昨日のエントリでインストールしたTracですが、設定を日本語にしても日本語化されませんでした。。

0.12 からデフォルトでLocalizationに対応してるって聞いたのに。。

わざわざBabelをインストールしたし。

と思いながら、インストールマニュアルを読み直すと、書いていました。。

$ python ./setup.py compile_catalog -f

これですね。。
ちなみに easy_install ではだめみたいですね。

レポジトリからチェックアウトして、setup.py でインストールしなおしです。

> svn co http://svn.edgewall.org/repos/trac/trunk
> cd trunk
> python setup.py compile_catalog -f
> python setup.py install
> /etc/init.d/httpd reload

うまく日本語化されました。

Cikloneなら1分でサインアップできます。

TracをLinuxにインストールする手順です。
今回は以下の構成でセットアップしています。

• CentOS5.4
• Aapache
• WSGI
• Trac0.12
• SQLite

途中、エラーなど出て半日くらいかかりました。
今すぐ使いたい人は、Cikloneにサインアップして、今すぐ使いましょう。

必要なパッケージのインストール

インストールドキュメントには以下のパッケージが必要だと書いています。

• Python
• setuptools
• Genshi
• SQLite
• Babel

それでは早速インストール

> yum install python

TracはPython 2.4以上で動作可能です。
CentOSでの最新バージョンは2.4.3でした。ちょっと古いがぎりぎりセーフですね。

> yum install sqlite

SQLite 3.3.6がインストールされました。

Python 2.4 の場合、SQLiteでTracを使うにはPySqliteが必要になります。
こちらのサイトからダウンロードします。

• http://code.google.com/p/pysqlite/downloads/list

そして、PySqliteのページの要領でインストールします。

> wget http://pysqlite.googlecode.com/files/pysqlite-2.6.0.tar.gz
> tar xzvf pysqlite-2.6.0.tar.gz
> cd pysqlite-2.6.0
> python setup.py build_static install

setuptools のインストール

以下のサイトから egg ファイルをダウンロードします。

• http://pypi.python.org/pypi/setuptool

> wget http://pypi.python.org/packages/2.4/s/setuptools/setuptools-0.6c11-py2.4.egg#md5=bd639f9b0eac4c42497034dec2ec0c2b

shellのように起動せよ。ということなので、起動すると、インストールできたようです。

> sh setuptools-0.6c11-py2.4.egg
Processing setuptools-0.6c11-py2.4.egg
creating /usr/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg
Extracting setuptools-0.6c11-py2.4.egg to /usr/lib/python2.4/site-packages
Adding setuptools 0.6c11 to easy-install.pth file
Installing easy_install script to /usr/bin
Installing easy_install-2.4 script to /usr/bin

Installed /usr/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg
Processing dependencies for setuptools==0.6c11
Finished processing dependencies for setuptools==0.6c11

コマンドが使えることを確認

> easy_install -h

GenshiとBabelをインストール

GenshiとBabelはともに eash_install コマンドでインストールできます。

> easy_install Genshi
Searching for Genshi
Reading http://pypi.python.org/simple/Genshi/
Reading http://genshi.edgewall.org/
Reading http://genshi.edgewall.org/wiki/Download
Best match: Genshi 0.6
Downloading http://ftp.edgewall.com/pub/genshi/Genshi-0.6-py2.4.egg
Processing Genshi-0.6-py2.4.egg
Moving Genshi-0.6-py2.4.egg to /usr/lib/python2.4/site-packages
Adding Genshi 0.6 to easy-install.pth file

Genshi 0.6 がインストールできました。簡単です。

Babelも同じようにインストールします。

> easy_install Babel
Searching for Babel
Reading http://pypi.python.org/simple/Babel/
Reading http://babel.edgewall.org/
Reading http://babel.edgewall.org/wiki/Download
Best match: Babel 0.9.5
Downloading http://ftp.edgewall.com/pub/babel/Babel-0.9.5-py2.4.egg
Processing Babel-0.9.5-py2.4.egg
creating /usr/lib/python2.4/site-packages/Babel-0.9.5-py2.4.egg
Extracting Babel-0.9.5-py2.4.egg to /usr/lib/python2.4/site-packages
Adding Babel 0.9.5 to easy-install.pth file
Installing pybabel script to /usr/bin

Installed /usr/lib/python2.4/site-packages/Babel-0.9.5-py2.4.egg
Processing dependencies for Babel
Finished processing dependencies for Babel

Babel 0.9.5 プロジェクトページからダウンロード出来るのと同じ、最新版です。

Tracには最近はやりのMercurialやGit用のプラグインもありますが、デフォルトのソース管理となるSubverionはインストールしておきましょう。

> yum install subversion

Subversion 1.4.2 がインストールされました。Tracの正式サポートは 1.5, 1.6 みたいですね。。
「1.4 でも動くはずだけどね。」みたいに書いてます。。がんばれ。

Tracのインストールとプロジェクトの作成

さて、いよいよ Trac のインストールです。
今回は最新が使いたいので、0.12 ベータをインストールします。

> easy_install Trac==0.12b1

バージョンは == で指定するんですね。なんとも独特な。

2010/05/14追記: Tracを多言語対応するにはインストール前に言語ファイルのコンパイルが必要です。Tracを日本語化する場合は翌日の日記=>「日本語化したTracをインストールする」の方法でインストールしてください。

TracEnvの作成

Tracがインストールできたので、さっそくプロジェクトを作りましょう。
initenv コマンドを実行するとプロジェクト名など聞かれますので適宜入力します。

> mkdir -p /var/share/trac/projects/sandbox
> trac-admin /var/share/trac/projects/sandbox initenv

うまくいったようです。

> ll /var/share/trac/projects/sandbox/
total 36
drwxr-xr-x 2 root root 4096 May 13 18:19 attachments
drwxr-xr-x 2 root root 4096 May 13 18:19 conf
drwxr-xr-x 2 root root 4096 May 13 18:19 db
drwxr-xr-x 2 root root 4096 May 13 18:19 htdocs
drwxr-xr-x 2 root root 4096 May 13 18:19 log
drwxr-xr-x 2 root root 4096 May 13 18:19 plugins
-rw-r--r-- 1 root root   98 May 13 18:19 README
drwxr-xr-x 2 root root 4096 May 13 18:19 templates
-rw-r--r-- 1 root root   27 May 13 18:19 VERSION

ちゃんとプロジェクトが出来てますね。
デプロイ用のコマンドでCGIなどのファイルを作成しておきます。

> trac-admin /usr/share/trac/projects/sandbox deploy /tmp/deploy
> mv /tmp/deploy/* /usr/share/trac/.
> rm -fR /tmp/deploy

Apache で使うつもりなので、permissionも変えておきましょう。

> chown -R apache:apache sandbox

Apacheとmod_wsgiの設定

インストールマニュアルにはfcgiかmod_wsgiを推奨すると書いてあるので、今回は mod_wsgi でTracを使うことにします。
mod_wsgi はyumではインストール出来ません。
もう少しなんですが、ちょっとめんどくさくなってきましたね。。

> wget http://modwsgi.googlecode.com/files/mod_wsgi-3.2.tar.gz
> tar xzvf mod_wsgi-3.2.tar.gz
> cd mod_wsgi-3.2
> ./configure
checking for apxs2... no
checking for apxs... no
checking Apache version... ./configure: line 1704: apxs: command not found
./configure: line 1704: apxs: command not found
./configure: line 1705: apxs: command not found
./configure: line 1708: /: is a directory

checking for python... /usr/bin/python
./configure: line 1877: apxs: command not found
configure: creating ./config.status
config.status: error: cannot find input file: Makefile.in

エラーです。httpd-devel のコマンドが必要みたいです。
しょうがないので、インストールしましょう。

> yum install httpd-devel
> ./configure
> make
/usr/sbin/apxs -c -I/usr/include/python2.4 -DNDEBUG -D_GNU_SOURCE   mod_wsgi.c -L/usr/lib -L/usr/lib/python2.4/config  -lpython2.4 -lpthread -ldl  -lutil -lm
/usr/lib/apr-1/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -fno-strict-aliasing  -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread -I/usr/include/httpd  -I/usr/include/apr-1   -I/usr/include/apr-1  -I/usr/include/python2.4 -DNDEBUG -D_GNU_SOURCE  -c -o mod_wsgi.lo mod_wsgi.c && touch mod_wsgi.slo
mod_wsgi.c:135:20: error: Python.h: No such file or directory
mod_wsgi.c:138:2: error: #error Sorry, Python developer package does not appear to be installed.
mod_wsgi.c:142:2: error: #error Sorry, mod_wsgi requires at least Python 2.3.0 for Python 2.X.
mod_wsgi.c:150:2: error: #error Sorry, mod_wsgi requires that Python supporting thread.

またまたエラーです。
プロジェクトホームページに解説がありました。

通常のLinuxパッケージでインストールしたPythonにはヘッダーファイルが無いので
dev パッケージを入れなさいと言っています。

> yum install python-devel
> ./configure
> make
> make install

今度はうまくいきました。

では Apacheに mod_wsgi をロードして、trac環境を作りましょう。

/etc/httpd/conf.d/trac.conf を以下のように作成します。

LoadModule wsgi_module modules/mod_wsgi.so
WSGIScriptAlias / /usr/share/trac/cgi-bin/trac.wsgi

    WSGIApplicationGroup %{GLOBAL}
    Order deny,allow
    Allow from all

やっとセットアップが終了、かなり大変でした。。
Apacheを起動して、確認します。

> /etc/init.d/httpd start

一応、Tracの画面が表示されました。

でも使う前に、まだやることがあるようです。。。

• サイトの日本語化
• チケット作ろうと思ったら、認証情報がないといわれた。。
• Subversionとの連携
• プラグインとか入れたい

Cikloneなら1分でサインアップできます。

ソフトウェアのバグもそんなにあったら嫌だなあと最近つくづくと感じています。

バグ数の推定

そもそも、システム開発工程でバグを作りこまないようにすればいいのですが、必ずと言っていいほど作りこまれてしまいます。設計書の誤り、誤解や思い込み、錯覚あるいは検討もれなど、原因はたくさんありますが、どうやら人間の行動にはミスがつきまとうものだと理解した方がよさそうです。

設計者ならば、どれくらいバグが潜んでいるのか興味があると思いますが、信頼性予測のモデルによってソフトウェアの信頼性を数理的なモデルで計量化して予測する方法もあります。プログラム開発者が意図的にプログラム中にバグを埋め込んでおき、デバッグにより発見したバグのうち意図的に埋め込んだバグの発見率から全体のバグの数を推定するのです。

次のような式になります。（詳細はこちらを参照のこと）

（発見済み埋め込みバグ数）/（埋め込みバグ数）

＝（発見済み潜在バグ数）/（潜在バグ数）

ソフトウェア開発者の能力によりバグの作りこみ数も変わってくるような気もしますが、バグの収束を願う設計者の気持ちはひしひしと伝わってきます。

テストの達人とは

バグを見つけるためには効果的なテストが必要ですが、どんなテストをすれば重大なバグが素早く見つかるのでしょうか。一般的なテスト作業では、コンポーネントとして実装したプログラムが要求仕様とおりに動作することを単体テストで確認し、結合テストによりさらに大きなモジュール単位での動作を確認します。当然のことながら、どんなテストツールを使うか、どんな体制でテストチームがテストを進めるかが重要になってきます。テスト工程を管理するテストツールも沢山出ているので、うまく利用すれば自動テストや結果分析も効率化できると思います。

デバッグとは関係ありませんが、2つの似た絵があって右の絵と左の絵でどこが違うのか探すような、間違い探しのクイズを考えてみてください。答えを見れば、何だそんな所か、とわかるのですが、意外なところ、想定外のところに違いがあると案外と見つかりにくいものです。もちろん、得手、不得手はありますが、ちょっと見方を変えることでバグが見つかるということがあります。他の人の見方や意見を参考にするのも、新鮮な視点を持つという点で、効果的です。開発者は、失敗を繰り返しながら、テストの達人に成長していくものなのでしょう。

ある先輩が言っていた言葉を思い出します。
「バグを全部見つけるのは無理だが、事故再発防止により品質向上できる」
類似不良を出さないことが最低限必要なのだと理解しましたが、これはいつの時代も通用することだと思います。

cikloneによるバグ管理

バグ管理システムcikloneでは、チーム開発の進捗、wikiによる情報共有基盤を備えています。そのため、プロジェクトのチームメンバと情報交換をしながら、テストも進められます。バグ管理データベースで過去の類似バグも管理しているので、同じ失敗を繰り返さないようにできます。

無料版での利用が可能なので、皆さまも是非、御検討下さい。

cikloneは、チーム主導によるアジャイルソフトウェア開発を実現できる「ソフトウェアエンジニアのための開発プラットフォームを提供するクラウドサービス」です。この点で、管理者が進捗を管理するだけ、説明のためのWBSを作成するだけの、従来のプロジェクト管理システムとは全く異なっています。

アジャイルって何？という方もいらっしゃると思いますので、念のため、Wikipedeiaによると：

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。

私達は、ソフトウェア開発に重要なキーワードは次の３つだと考えています。

1. だれでも簡単に使える情報共有基盤
2. チーム開発の進捗を管理し、課題・バグに漏れなく対応するためのシステム基盤
3. ソフトウェア開発のライフサイクルで作成される成果物・ソースコードを管理するためのシステム基盤

cikloneを使って情報共有・課題管理を実現するには

ソフトウェア開発に重要な3つの要件を実現するために、cikloneは次のソリューションを提供しています。

1. バージョン管理システム
2. ソースコード管理と連携したバグ管理システム(BTS)
3. チーム開発の進捗、wikiによる情報共有システム

cikloneを利用する事で、情報共有や課題管理を実現するシステム基盤が60秒であなたのチームに導入できます。そして、システムをあなたのチームに適用するための、ciklone導入・運用サポートが柔軟に対応します。

ciklone導入サポートで解決！

「ciklone導入サポート」を利用することで、これまでバージョン管理システムやバグ管理システム（BTS）を使ったことがないユーザに対してもスムーズに導入し、チームのため、エンドユーザのためのシステム開発が実現できます。

• cikloneプロジェクト管理システムの導入
• 管理者向け教育
• 一般ユーザ向け教育

お客様は当サービスにより

• システムをスムーズに導入できます。
• 教育コストを削減し、先進的なクラウドサービスのメリットを享受できます。
• 過去に導入がうまくいかなかった場合も、導入～運用まで十分サポートします。

チーム主導での開発が重要

さて、チーム主導での開発とは何でしょうか？

あなたのチームに、次の項目があてはまるかどうか、ちょっと考えてみて下さい。

• 管理者の効率化を優先し、進捗報告は数字だけによる管理をしている。進捗率30％は本当なのか?
• 現場のプログラマーまで、エンドユーザの声が届かない。プログラマーにとってベストな機能を開発。方向が違うのでは?
• 障害情報、クレーム情報、エンドユーザ要求・・・日々大量のメールが流れ、忘れ去られているのではないかという不安があるのでは?

もしも、上記項目のどれかに思いあたる点があれば、チーム開発の進め方、ルール、仕事のやり方に改善の余地があります。あなたのチームでも考えてみてはいかがでしょうか?

私達が理想とするのは、「エンドユーザ、管理者、開発者の情報格差を減少させ、必要な情報を必要な人に伝える」ことです。
正しい情報が伝えられて初めて、正しい答えを見つけることができます。

前回は、cikloneを使って、部門レベルにおいて課題、バグ情報の共有を実現したE社様の導入事例を紹介しましたが、「そもそもバグ管理には何が必要なの？」という基本的なことに戻って書いてみます。

Wikipediaによると

バグ管理システム（バグかんりシステム）とはプロジェクトのバグを登録し、修正状況を追跡するシステム。バグトラッキングシステム（Bug Tracking System：BTS）とも呼ぶ。バグ管理システムの多くは、Webサーバ上で動作し、Webブラウザ経由でアクセスできるようになっている。バグ管理システムはソフトウェアを開発する上での必須アイテムになりつつある。

さらに、バグ管理に必要な基本的な機能として、バグのライフサイクルのワークフローによる一元管理（バグの投稿〜完了までのバグ情報の管理）、バグの検索と履歴管理、バグ更新時のメール通知機能などが挙げられます。

バグ管理に必要な5つの条件とは

私達は、バグ管理に必要な条件は次の5つだと考えました。

1. プロジェクトメンバー全員が確認できること
2. 最新版が管理されていること
3. 問題の解決状況がひとめでわかること
4. 過去のバグも管理されていること
5. 担当者、対応期日が管理されていること

そこで、cikloneではバグ管理の条件を満たすバグデータベースに加えて、プロジェクトメンバーのタスク管理やバージョン管理（ソースコード管理）、コミュニケーション環境を備えることによって、Wikipediaによる定義以上の「協調・反復アプローチによるソフトウェア開発」を実現するのです。ここがとても重要なポイントだと思います。

バグデータベースの構築

cikloneでバグや課題のデータベースを作成すると、常に、「だれが、いつ、なにをする|しなければいけない」というタスク管理ができ、過去のプロジェクトにおいて発生した障害、ナレッジ情報を検索できます。でも、導入のためのバグデータベースを一から構築するのは大変そうだなあ、という不安をお持ちの皆さんには朗報です！

1. ブラウザさえあれば、すぐに利用できます
2. 1プロジェクト無料で利用し続けることができます
3. スプレッドシートで管理していたバグをＷｅｂから簡単登録できます
4. バグの最新状態もレポートで確認できます
5. バグを１件ごとに履歴管理します（「現在のバグ数」「対応状況」「期限」「担当者」ごとに把握）

このようにして、一旦バグデータベースを作ってしまえば、過去のバグも簡単に全文検索できますし、過去のプロジェクト事例、対応事例などのノウハウも活用できるのです。

あともうひとつ重要な点は、cikloneにはプロジェクトの進捗と共にノウハウ・文書化をしていく仕掛けがあることなのです。この点については、後日にでもご紹介いたしましょう。

無料版での利用が可能なので、皆さまも是非、御検討下さい。

今回は、cikloneを使って、部門レベルにおいて課題、バグ情報の共有を実現したE社様の導入事例をご紹介いたします。

課題やバグ情報を共有したい

E社様では、新製品の開発や既存製品の顧客の声、設計障害、クレームをプロジェクトごとに管理し、情報共有はすべてメールで行っていました。しかし、次の問題点がありました。

• • 日々処理すべきメールの量が多く、現場では全てのバグ・クレームに対応できない
  • 本当に対応が必要な未処理のバグについての対処状況が把握できない
  • バグ・故障の対処を過去に遡って追跡できない
  • 優先度が低いが重要な作業など、対処されないまま放置されるバグ・クレームが過去にあった

そこで、cikloneを全部門に導入して、製品の設計・開発で発生する設計上のミス、ソフトウェアバグの障害に対して、漏れなく記録するためのバグ管理データベースを構築する必要がありました。

Ｅ社様では、情報共有方法としてメールが浸透していたため、「バグ・クレームがcikloneに登録・更新されるとメールによるアラート通知を行う」ワークフローを採用することにしました。

ciklone導入によるワークフロー検討

下図に示すワークフローに従って、バグ・クレームのcikloneへの登録・更新作業を行います。

チケットのワークフロー

1. 発行者からのメールに対応してチケットを登録（バグの発生・起票）
2. プロジェクト管理者がソフトウェアチームにアサイン（担当グループ振分）
3. 担当部署が異なっていたためインフラチームに再アサイン
4. インフラチームの担当者に振分（担当者振分）
5. 担当者が調査内容をアップロード
6. バグ修正をソースに反映（バージョン管理）し、 テスターによる動作確認完了後に、プロジェクト管理者がバグのクローズを宣言

新ワークフローの評価

上記①から⑦の流れにより、バグの発生から完了までをバグ管理データベースで管理できるので、利用者からは次のような評価をいただきました。

問題点の登録作業が容易になった

問題発見者と設計者、品質管理チームの情報共有ができるようになった

障害内容が即座に共有できるので、開発者の製品に対する問題認識が上がった

バグ報告書の作成や履歴管理が不要なので、作業効率が向上した

サーバ側で情報を一元管理するため、二重修正、修正漏れ、認識誤りなどがなくなった

導入の決め手

cikloneで現場主導による課題、バグを漏れなく管理できるようになったことが導入の決め手でした。クレームの対処が確実にできるようになっただけではなく、お客様からの情報を収集・分析してフィードバックするしかけもできたので、E社様の今後の製品開発が期待できますね。

なお、E社様ではcikloneを導入するために、各ユーザに利用してもらうための自社にあった運用ルールの作成、社員への研修が必要だったのですが、弊社の「導入研修サービス」によってスムーズに利用をはじめることが出来ました。

cikloneは無料版での利用が可能です。皆さまも是非、御検討下さい。