アシアルブログ

アシアルの中の人が技術と想いのたけをつづるブログです

Macでも手軽に使えるガントチャート描画ソフトGanttProject

こんにちは、DJ担当の浦本です。

今日は、Macでも手軽に使えるガントチャート描画ソフト「GanttProject」を紹介します。
GanttProjectJava製&オープンソースで、MacのみならずLinux/Windowsにも対応しています。
もちろん、フリーで利用できます(←ここ重要!)。

GanttProject website: http://www.ganttproject.biz/

GanttProject付属のサンプルプロジェクトはこんな感じ。

まずは、初期設定から



【祝日設定を行う】
日本の祝日が休日としてカウントされるように設定しましょう。
メニューから「Project → Properties...」を開きます。
Holiday calendarとしてJapanを選択します。



【チャートの見た目をカスタマイズ】
メニューから「Edit → Settings」を開きます。
Task detailsの欄から、バーの上下左右に表示する情報を選ぶことができます。


私のお気に入りは、左側にタスク名、下側に日数、右側に担当者名を表示する設定です。
しかしチャートをよりコンパクトにしたいという方は、左右のみ選ぶと良いでしょう。

3秒で分かる基本操作



【タスクを作成する】
時計ボタンを押すとタスクが新規作成されるので、タスク名を入力します。


できたバーをダブルクリックすると、タスク編集画面が開きます。

ここで開始日、終了日、進行率などを入力できます。

マウス操作だけでも、簡単にタスク編集を行うことができます。
・終了日をずらすには、右端をドラッグ
・開始日をずらすには、左上隅をドラッグ
・進行率を増減するには、左隅の真ん中あたりをドラッグ

【担当者(リソース)をアサインする】
まず新規リソースを登録するために、メニューから「Resources → New Resource」を開きます。
このリソース登録画面だけ日本語が入力できないため、日本語はコピペで入力して登録してください。


登録したらResources Chartにリソースが追加されたことを確認し、
Ganttを押してガントチャートへ戻ります。


アサイン先タスクのタスク編集画面を開き、Resourcesタブからリソースをアサインします。
Unitがアサイン率を表します。

Coordinatorにチェックを入れた人は進行役の扱いとなり、ガントチャート上には括弧{}付きで表示されます。


アサイン後にResources Chartを開くとアサイン状況が表示されているので、
誰がいつ暇なのか把握することができます。


【先行タスクを設定する】
先行タスクから後続タスクに向けて、バーの中央部をドラッグします。


このように、タスクの前後関係が矢印として表示されるようになります。


先行タスクを後ろにずらすと、後続タスクも所要日数を保ったまま、後ろにずれます。


【サブタスクを設定する】
右矢印ボタンを押すと、選択中のタスクは、上にある親タスクのサブタスクになります。


親タスクは見た目が変わって黒い枠として表示されるようになります。


ガントチャートを画像にエクスポートする】
メニューから「Project → Export」を開きます。
ここで形式はPNGを選択します。

画像出力するときのコツは日付範囲を2週間ほど広めに設定しておくことです。そうするとバーの周りに表示しているテキストが長くても途切れません。

以上、なんだかマニュアルみたいな内容になってしまいましたが、GanttProjectに少しでも興味を持って頂けたら幸いです。
それでは、ビッグサイトでは熱中症にならないように気を付けていきましょう!




2013/10/30追記:
Mac版では Alt+Click によるタスクバーの移動ができませんが、
代わりに以下のようにして Shift+Click を用いることができます。

「/Applications/GanttProject\ 2.6.1.app/Contents/Resources/Java/plugins/net.sourceforge.ganttproject/data/resources/mouse.properties」を編集し、「mouse.drag.task=Shift+Button1」とする。

出典: https://code.google.com/p/ganttproject/issues/detail?id=706

3分で使えるRedmine(チケットで課題管理)

こんにちは、岡本です。

プロジェクト管理にRedmineを使っていて、改めて便利だなと思ったので、今更ですが紹介したいと思います。

RedmineRubyで書かれたオープンソースのシステムで、2006年に作られ2007年辺りから日本でも利用され始めた、比較的新しいプロジェクト管理ツールです。

残念ながらPHPでは無いのですが、CakePHPに移植しようと頑張っている方々もいらっしゃいます。
CakePHP開発合宿開始!&candycaneを開発します


さて、Redmineを使えばシステム運用で生じる、不具合や質問・要望等を、チケットという概念でひと括りにして、Web上で管理することができます。

Redmineは元々プロジェクトの工程管理も行える高機能なソフトなのですが、チケットの機能を使って楽をするだけだったら

「3分で使えます。」

トップページ画像

※一部機能をOFFにしています。

学習コストが低くスムーズに導入できるため、アシアル社内でも様々なプロジェクトの課題管理で利用しており、お客様と共同で作業する際にも活用した実績があります。

■実際の運用の流れ
 実際の利用の流れは、お客様やテスター様!がチケットとして不具合や質問項目を【新規】登録し、開発者が泣きながらチケットを【解決】し、問題がなければお客様やテスター様が【終了】するといった流れになります。

チケット作成画面


テスター様:川原様
開発者:岡本

A.「新規」でチケットが発生し、一回の修正で「終了」する場合
ステータスの遷移:新規(川原様)→解決(岡本)→終了(川原様)

終了後のチケット画面


B.「新規」でチケットが発生し、2回目の修正で問題が終了する場合
新規(川原様)→解決(岡本)→フィードバック(川原様)→解決(岡本)→終了(川原様)

C.「新規」でチケットが発生し、却下となった場合
新規(川原様)→却下(岡本)→終了(川原様)


チケットを更新するたびに、お互いにコメントや添付ファイルを残せるため、不具合の起きた画面のキャプチャを張り付けたりして、容易に意思の疎通を図ることが行えます。

■他の仕組みと比較した場合のメリット
メールやメーリングリストと比較した場合
・課題の数や期限を把握しやすい
・ステータス管理で課題の進捗を管理できる
Redmineはチケットが作成・更新された時にメンバー全員にアラートメールが飛ぶため、
メールからの移行も行いやすくなっています。

表計算ソフトとの比較
・Webベースなので情報を複数のメンバーで共有できる
・一つの課題に対してのやり取りを管理しやすい
・ファイルが添付できる

●その他
・課題の管理フローがある程度決まっているので導入に対する学習コストが低い
・自動的に課題に対して管理番号が付く
・更新が簡単に行えるので、情報の鮮度を保ちやすい

■最後に
Redmineガントチャートやカレンダー機能もあり、かなり高機能なプロジェクト管理システムです。
が、チケットの管理だけでも十分利用する価値のあるシステムです。
Redmineの機能をホスティングで提供されるサービス会社様もあるそうなので、システム開発に限らず、制作を行っているデザイン会社様や一般の企業様でも試す価値はあると思います。

Redmine参考リンク
Ruby on Railsで作られたプロジェクト管理ツールredMineを使ってみよう!
gihyo.jp … 技術評論社

プロジェクトの進め方と各フェーズでの成果物についてまとめ

こんばんは濱田です。
今日のBlogはデザインパターンはお休みしてプロジェクトの進め方と各フェーズでの成果物についてまとめてみます。
まだまだ新米プロジェクトマネージャーなのでこのフェーズではこんなドキュメントを作った方がいいなど、コメントにてご指導頂けるととてもうれしいです。

想定されるプロジェクトの規模
 5名ほどの製造要員がいて半年以上1年未満のプロジェクトを想定する。
システム概要
 次期システム構築PJ
 次期システムとは基幹システムの再構築であり、現行で基幹システムとサブシステムが稼働している、リリース後次期システムはサブシステムと連携して業務が行われる。



1.各フェーズとフェーズ単位に使用・作成する成果物一覧  
 ⅰ.要件定義
  モックアップ
  要件定義書(工数計算のために使用)
  課題管理表
  議事録(課題管理に使用)
  画面設計書

 ⅱ.詳細設計
  ER図
  詳細設計書

 ⅲ.製造・単体テスト
  ER図
  詳細設計書
  設定ファイル一覧
  単体テスト仕様書兼テスト結果報告書
  
※製造・単体テストフェーズでの作業の流れはモジュール単位で以下の作業を繰り返す
詳細設計→単体テスト仕様書作成→製造→単体テスト仕様書→単体テスト

 ⅳ.内部統合テスト
  シナリオテスト仕様書
  テスト結果報告書
 
 ⅴ.結合テスト
  シナリオテスト仕様書
  テスト結果報告書

2.プロジェクトの進め方とドキュメントの関係          
 ⅰ.要件定義
  a)モックアップ
   画面遷移・各ページの項目を提示する
  b)要件定義書
   ユーザからの要求は全て記載し、工数を明記する
   最終的にどこまで要求を実装できるか判断のために使用する
  c)課題管理表
   課題の進捗と漏れが無いかの確認
  d)議事録
   議事録wikiに掲載HTML形式でユーザに提示
  e)画面設計書
   仕様を定義する
 ⅱ.詳細設計
  a)ER図
   DB構造を定義
  b)詳細設計書
   画面設計書に記載されていないロジックを明記する
   またビジネスロジックが複雑な場合は必ず記述し、入力Formがある画面はDBとの関連を明記する。
 ⅲ.製造・単体テスト
  a)設定ファイル一覧
   本プロジェクトではDBにマスターテーブルがなくymlファイルにて設定する仕様とAPの動きもymlファイルにて設定する
   仕様のため一覧を作成する(実際には詳細設計書とER図に明記し、一覧は作成していない)
  b)単体テスト仕様書
   モジュール単位に単体仕様書を作成する
   作成する目的は各々の製造担当者が自己流でテストを行う事によるテスト項目のばらつきを無くすために作成する。
   テスト項目のばらつきを無くすのはテスト結果の判定時にテスト項目数で指標を定めるため。
 ⅳ.統合テスト・結合テスト
   要件定義書を基に機能漏れがないかテストを行うためのテスト仕様を定義する
   
   テスト方法は想定される業務を一連の流れでシナリオ化し、テストを実施する
   
   本プロジェクトでは、納品後次期システムと現行で動いている3つのシステムとを連動してAPが動く必要があるため
   受け入れテスト前に現行システムと時期システムの結合テストを行う。
   
3.単体テスト実施について
 ⅰ.単体テストの観点
  画面設計書に定義されている項目が正しく実装されているか
  各モジュールが要件の期待どおり動作を行うか詳細設計書を基に正常系・異常系のデータを使用し、テストを行う
  異常系データとはハードに起因するエラーは考慮せず、業務で使用されるデータ以外の事を指す
 
 ⅱ.テスト結果の判定
  品質保証をどこまで担保するか指標を決め、指標を満たしているか判定を行う
  製造工数(ステップ数)・テスト項目数・障害抽出件数を指標として策定する
  ステップ数が多いモジュールは必然的にロジックが複雑と考え、テスト項目数と障害抽出件数がステップ数に比例して大きくなる
  本プロジェクトの場合は200ステップ毎に障害抽出件数3件としている
  単体テスト実施後指標を目安に障害抽出件数の妥当性を判断し再テストを行うか判定する
  
  品質管理をする場合はモジュール単位に判定するのではなく、プロジェクト全体を見る必要がある
  
全体の品質を担保するための指標をあげるとバグ曲線の曲線の形や発生箇所の分布図がある


以上です。