概要
オープンソースのプロジェクト管理・課題管理ソフトウェアであるredmineを使って、
ローカル環境でマネジメントのハンズオンをやろうって記事になります。
PMPとか座学は後回しにしたいぜ!まずは手を動かして勉強したいぜ!って方向けです。
具体的にはredmineでPJキックオフまでにやっておくべきことをハンズオンで紹介します。
あとWBSの作成についても少し触れます。
想定しているPJについて
- 業界はコインランドリー
- PJはオンライン宅配サービスの構築
- 要件定義から運用保守までが作業範囲
- 期間は4/1 - 7/31の4ヶ月
- 開発手法はウォーターホール
- メンバは自分含めて10人(PM1人、PL1人, 上級PG2人, 下級PG5人, インフラSE1人)
※PJについて
コインランドリーチェーンが、新規サービスとして宅配サービスを行う。
WEBサイトで利用者が依頼を行うと、自宅まで洗濯物を取りに来てくれて、コインランドリーで洗濯/乾燥まで行った上で自宅まで配送してくれる。
※メンバの内訳について
PM:上級管理職。社内の業務調整や予算関、資材調達の調達を行う。
PL:中間管理職。PJのマネジメントを行う。私でありあなた。管理職であり設計や実装は行わない。
上級PG：システムの設計や複雑な実装を行うことができるプログラマー。レビューも行う。
下級PG：簡単な実装業務や試験業務を行うことができるプログラマー。レビューは行えない。
インフラSE：インフラ関係の調整を行う。他プロジェクトととの兼ね合いもあり0.5人月のみの参画。
使用ツール一覧
- docker
- redmine
前準備：redmine導入
まずはredmineをローカル環境に入れます。
dockerのインストール
docker公式サイト(日本語化プロジェクト)からダウンロードします
Macならこちら
Windows環境ならこちら
redmineコンテナの起動
dockerのインストールが完了したので、ローカル環境で起動させましょう。
起動コマンド
docker run --publish 3000:3000 --detach --name some-redmine redmine
実行中コンテナ確認コマンド
docker ps
レスポンス
下記のようにコンテナが起動していることが確認できれば成功です。
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d1231113985e redmine "/docker-entrypoint.…" 1 minutes ago Up 1 minutes 0.0.0.0:3000->3000/tcp, :::3000->3000/tcp some-redmine
redmineコンテナの停止/再起動/削除
実行中のコンテナを停止させるコマンド
docker stop some-redmine
停止していたコンテナの再起動
docker start some-redmine
実行中にかかわらずコンテナを削除するコマンド
docker rm --force some-redmine
redmineにログイン
redmineコンソールへ接続
下記URLでログインできます。
http://localhost:3000
ただし、コンテナをバックグランド起動したので、コンテナ起動直後にはログインできないことがあります。
少し待ってからコンソールへアクセスしてみてください。
redmineへログイン
コンソールにログインできたら、右上のログインリンクからログインします。
IDとパスはどちらもadminです
ログインしたらパスワード変更を求められるので、適当なものに変更しておきます。
redmineの初期設定
デフォルト設定のインポート
初期設定だとアクセス権限などが設定されていないため、デフォルトの初期設定をしておきます。
左上の「管理」をクリックするとデフォルトの初期設定を促す表示がされるのでインポートしておきます。
新しいチケットタブの表示
デフォルト設定だとチケットの新規作成タブが表示されないので、設定しておきます。
管理 ⇨ 設定 ⇨ 表示
ここの「新規オブジェクト作成タブ」を「”新しいチケット”タブを表示」に変更し保存しておきます。
以上で前準備は完了となります。
本題：マネジメントハンズオン
ここまでで前準備が完了しました。
本題であるマネジメントのハンズオンを進めていきます。
1.PJ開始前の準備
まずはredmine上でPJ開始に向けて準備をしていきましょう。
本格的にメンバが入る前にwikiとドキュメントを整備します。
準備一覧
PJの特性やメンバの得意な管理手法にもよりますが、
最低でも下記は準備しておくとトラブルはグッと減らせるかと思います。
| No | 項目 | 説明 |
|---|---|---|
| 1 | アカウント作成 | 各種権限設定とメンバーのアカウント作成 |
| 3 | ドキュメント管理ルール | フォーマットやディレクトリなどのルール |
| 4 | git管理ルール | リポジトリ、ブランチの管理ルール |
| 5 | チケット管理ルール | チケットの運用方針 |
| 6 | コミュニケーションルール | コミュニケーションルールと連絡先 |
| 7 | 会議体 | 日次や週次などの会議体について記載 |
| 8 | 推奨ツール | PJで使用しているツールの一覧 |
| 9 | その他 | 資産管理台帳や休暇申請のルールなど業務外の事柄を記載 |
| 2 | 導入資料 | 新規参画者向けの説明と導入手続き |
ただし下記の点には注意が必要です。
-
それぞれのルールを詳細にしすぎる
⇨メンバがルールを覚えるのが大変になり、管理コストも高くなります。
適度にグレーゾーンを残しておくことも重要かと思います -
一度決めたルールを絶対に変えない
⇨そもそもレガシーなマネジメント方法を採用していてメンバが不満を感じている場合や、
現状に会わなくなったルールが適用され続けている場合改善のチャンスです。
プロジェクト作成
まずはredmineでプロジェクトを作成します。
左上「プロジェクト」 ⇨ 上部右「新しいプロジェクト」でプロジェクトの作成を行います。
プロジェクトは一般的なシステム開発ではではシステム単位で作成されることが多いです。
そのため、今回作成するプロジェクトもシステム単位で作成します。
ここで作成した内容が今後このPJに参加する人が初めに見る情報になります。
そのため、このPJの全容が理解できるようにしておきます。
ここでは例として、よく記載される項目について紹介させていただきます。
PJの特性や皆さんが必要だと感じている点があれば追加してください。
| 項目 | 説明 |
|---|---|
| 背景 | このプロジェクトが発足された背景を記載します |
| 目的 | このプロジェクトの目的を記載します。背景と同じ内容の場合は省きます |
| 除外項目 | 除外項目を記載します。明示的に記載しない場合、PJスコープが拡大解釈され炎上の原因となります。 |
| スケジュール | 全体的なスケジュール記載します。現時点で判明しているマイルストーンがあればそれも記載しておきます。 |
| 成果物 | 最終的なこのPJの成果物を記載しておきます |
上記を踏まえた上で今回作成したものは下記になります。
アカウント作成
ユーザの作成
管理 ⇨ ユーザ ⇨ 新しいユーザ
ここの設定は後から変えられますが、ユーザ名は変更できないので注意します。
今回は10人のPJなので10人分作成します。
1人ずつ作成すると下記のように行いますが、10人分作成するのはきついので一括作成機能を使用します。
一括作成に使用するCSVファイルの内容は下記の通りです。
ログインID 名 姓 メールアドレス 言語 パスワード 次回ログイン時にパスワード変更を強制
PM PM PM PM@example.net ja xxxxxxxxxx はい
PL PL PL PL@example.net ja xxxxxxxxxx はい
senior_pg_1 上級 PG1 senior_pg_1@example.net ja xxxxxxxxxx はい
senior_pg_2 上級 PG2 senior_pg_2@example.net ja xxxxxxxxxx はい
lower_pg_1 下級 PG1 lower_pg_1@example.net ja xxxxxxxxxx はい
lower_pg_2 下級 PG2 lower_pg_2@example.net ja xxxxxxxxxx はい
lower_pg_3 下級 PG3 lower_pg_3@example.net ja xxxxxxxxxx はい
lower_pg_4 下級 PG4 lower_pg_4@example.net ja xxxxxxxxxx はい
lower_pg_5 下級 PG5 lower_pg_5@example.net ja xxxxxxxxxx はい
infra_se インフラ SE infra_se@example.net ja xxxxxxxxxx はい
CSVファイルの作成方法は使いやすいツールで問題ないですが、
今回はgoogle spreadsheetを使用しました。
作成したら左上の ファイル ⇨ ダウンロード ⇨ カンマ区切りの値 でCSVファイルとしてダウンロードできます。
ファイルを作成したら一括でインポートします。
管理 ⇨ ユーザ ⇨ 新しいユーザの隣の三点リーダ ⇨ インポート
CSVファイルを選択し、エンコーディングをutf-8に変更し取り込み実行します。
読み込みページになったら下記のように設定し作成を実行するとユーザを一括で作成できます。
グループの作成
ユーザを作成しただけだと、プロジェクトへの権限がなく作業がまだできないため、権限を設定します。
グループを作成し、そのグループを各ユーザにアタッチすることで一括で設定できるようにします。
管理 ⇨ グループ ⇨ 新しいグループ
まずはグループを作成します。
作成したグループにプロジェクトを開発者権限で紐付けます。
続いてユーザタブを選択し、一括でユーザとグループを紐づけます。
これでメンバは本PJで活動することができるようになりました。
ドキュメント管理ルール
ドキュメントに関わるルールをwikiに作成します。
プロジェクト ⇨ WEB宅配サービス構築 ⇨ wiki ⇨ 3点リーダ(・・・) ⇨ 新しいwikiページ
ここでは、下記の点を記載します。
-
ドキュメント保存場所
ドキュメント管理ツールが複数ある場合、基本的には一箇所にまとめておいた方が良いです。
redmineとgoolge driveを使用している場合、ファイルの配置場所が2箇所になるので、どちらかにします。
今回はバージョン管理ができるgoolge driveにします。 -
使用ツール
どのドキュメントにはどのツールを使用するか明記します。
office製品はバージョンも存在しているため、推奨しているバージョンがあれば記載します。 -
ディレクトリ構造
メンバーが感覚的に把握できるディレクトリ構造にします。
また、ディレクトリ構造が決まったら作成をしておきます。
google driveの場合ディレクトリごとアップロードできるので、
ローカルで作成したディレクトリ構造をアップロードするだけで作成が完了します。 -
ドキュメントフォーマット
各ドキュメントにおいてフォーマットが決まっている場合はその点を明記します。 -
ドキュメント更新ルール
各ドキュメントには改版履歴のページを設ける。
ドキュメントの更新をする場合は、改版履歴ページを更新する。
ファイルをコピーし、ファイル末尾に更新日付を記載する方法は許可しない。
例として、上記を考慮したwikiを挙げます。
git管理ルール
ブランチに関わるルールをwikiに作成します。
プロジェクト ⇨ WEB宅配サービス構築 ⇨ wiki ⇨ 3点リーダ(・・・) ⇨ 新しいwikiページ
ここでは、下記の点を記載します。
-
リポジトリ一覧
gitで管理するリポジトリ一覧を記載します。
backlogなどgitのwebhookがある場合は必要ありませんが、redmineの場合はwebhookがないので必要です。 -
ブランチ一覧
ブランチ戦略に従ったブランチ一覧を記載します。 -
ライフサイクル
各リポジトリやブランチのライフサイクルを記載します。
例として、上記を考慮したwikiを挙げます。
チケット管理ルール
チケット管理に関わるルールをwikiに作成します。
プロジェクト ⇨ WEB宅配サービス構築 ⇨ wiki ⇨ 3点リーダ(・・・) ⇨ 新しいwikiページ
ここでは、下記の点を記載します。
チケットのライフサイクルと管理方法について規定します。
PJがうまく回るために、マネジメントがしやすく、かつメンバの負担が少なくなるようにします。
チケット管理のルールを厳密にしていくとマネジメントは楽になりますが、一方でメンバの負担は多くなるため、必要最低限にするようにします。
- チケット作成ルール
- チケットライフサイクル
例として、上記を考慮したwikiを挙げます。
また、作成したチケットルールに即したトラッカーとステータス、チケットテンプレートを作成しておきます。
作成方法については下記参照ください。
| No | 作業名 |
|---|---|
| 1 | トラッカーの追加 |
| 2 | ステータスの追加 |
| 3 | テンプレートの作成 |
コミュニケーションルール
コミュニケーションに関わるルールをwikiに作成します。
プロジェクト ⇨ WEB宅配サービス構築 ⇨ wiki ⇨ 3点リーダ(・・・) ⇨ 新しいwikiページ
ここでは、下記の点を記載します。
- 体制図
- 会議体
- 使用ツール
例として、上記を考慮したwikiを挙げます。
推奨ツール
ドキュメントに関わるルールをwikiに作成します。
プロジェクト ⇨ WEB宅配サービス構築 ⇨ wiki ⇨ 3点リーダ(・・・) ⇨ 新しいwikiページ
ここでは、PJで推奨しているツールの一覧を作成します。
redmineの表作成機能を使用して一覧を作成しておきます。
その他
そのほかPJに直接関係ないものの、メンバが把握しておくべき事柄に関して記載します。
プロジェクト ⇨ WEB宅配サービス構築 ⇨ wiki ⇨ 3点リーダ(・・・) ⇨ 新しいwikiページ
ここでは、主に下記の点を記載します。
- 勤怠連絡手順
- 有給申請手順
- 資産管理台帳
ここは所属している企業に即したルールを記載するページのため、例を挙げません。
導入資料
新規参画者に対しての導入資料を作成します。
PMPでいうインセプションデッキです。あるいはアルバイトのチェックリストです。
導入資料の目的は、新規参画者がPJに円滑に参画することです。
そのために、ここまでで作成したプロジェクト説明やルールをwikiのmainページに一覧化し、さらに必要な対応を盛り込んでおきます。
wikiページのリンク方法はこちらを参考にしてください。
新規に盛り込む内容は主に下記です。
- システム概要説明
- 作成するアカウント一覧
- ローカル環境構築手順
上記を考慮すると、下記のようになります。
2.スケジュール作成
PJの基本ルールは決めたので、スケジュールを作成します。
google spreadsheetにはテンプレートでガントチャートがあるため、そちらを利用します。
整合性検証
WBSを作成したら下記の点を確認してください。
| No | 観点 | 確認方法 |
|---|---|---|
| 1 | 休日 | 土日祝日も働く計算になっていないか |
| 2 | 勤務時間 | 勤務時間の計算は営業時間内(8時間)に収まっているか |
| 3 | 実労働時間 | 事務作業や定例会への出席は考慮されているか |
| 4 | 管理業務 | PM, PLが作業者になっていないか |
| 5 | アサイン条件 | インフラSEは0.5人月だが考慮されているか |
| 6 | 一日の作業量 | １作業者の作業量が1人日を超えていないか |
| 7 | 作業順番 | 設計の前に実装が始まるなど、作業の順番が逆転していることはないか |
| 8 | 協力会社調整 | 協力会社などの外部からのレスポンスを含むスケジュールはレスポンス期間を含んでいるか |
妥当性検証
整合性の検証が完了したら、作成したスケジュールが妥当かどうか確認します。
wbs作成して翌日に確認すると、めちゃくちゃなスケジュールだったりします。
| No | 観点 | 確認方法 |
|---|---|---|
| 1 | バッファ | 作業予定にバッファは含まれているか。10%は含んでおくと良いとされる |
| 2 | 作業量 | 各タスクの工数は各メンバの力量を考慮しているか。不当に短くないか |
redmineへ反映
作成したwbsをredmineへ反映します。
redmineには一括作成機能があるため、こちらを利用します。
これでPJの開始準備が全て整いました。
クロージング
振り返り
ここまでで、redmineでのPJ管理ルールの作成と、WBSの作成を行いました。
これまでの作業内容を振り返って、自分が新規参画者になった際に疑問点が浮かばなければ良いPJ準備ができていると思います。
一方で、これは理解するのが大変だ!とか、ここの部分はどうするべきなんだ?という点があったらそこは改善するべきポイントになります。
PJの特性や得意なマネジメントの手法により改善していただければと思います。
redmineの後処理
削除
再利用しない場合は削除したほうがストレージ上は良いです。
今回作成したredmineコンテナは下記コマンドで削除できます。
docker rm --force some-redmine
感想
ここまで長い記事を読んでいただき本当にありがとうございます。
この記事がどなたかの一助になれば幸いです。
参考資料
今回の記事を作成するにあたり、下記記事を参考にさせていただいています。
本当にありがとうございます。
| 記事名 | 説明 |
|---|---|
| Markdown記法 チートシート | Qiita記事のマークダウン記法 |
| Docker ドキュメント日本語化プロジェクト | dockerのローカル環境構築 |
| docker redmine | dockerのredmineコンテナ |
| Redmine.JP | redmineの(非公式)日本語サイト |
| Redmine.JP Blog | remineに関するブログ記事 |