若手が考えるチーム・プロジェクトマネージメント

## お前 is 誰

- 某企業の研究職
- 在勤5年目
- LED-Campという組込み開発者向け合宿の実行員
    - https://swest.toppers.jp/LED-Camp/
    - **現在、参加者募集中**
    - ここで培ったことを仕事場に導入した話なので、紹介させてください。

## この記事の趣旨

- Qiitaにポエムを投稿するのは気が引けるがプロジェクトマネージメントについて書くので許してください。
- マネージメントに使えそうな、OSSかつオンプレデプロイできるツールの紹介
- **無理せずプロジェクト管理**
- 僕が所属する組織の公式見解ではないので、あしからず。

## 問題提起

- 大企業だからといって、優秀なプロジェクトマネージャーがいるとは限らない
    - マネージに興味がある人って実はあまりいない？（勝手な妄想）
- 最近、マネージ次第でプロジェクト進捗が大きく異なることを痛感している

## よくある事例

- とりあえず定例MTGをやる
    - が、しかし、MTGごとに何を確認して、何を決めるかは定義していない
- 何となく時間が経っていく
    - デカイマイルストーンは決めているが直近の細かいマイルストーンは決めない
- 上記ゆえに、合意形成が遅い
    - 「あれ、〜〜ってどうなったんだっけ？」という事象がよく発生する

## 痺れを切らして、Scrum導入をしてみようと思った

ここから、やっと本記事の本題に入ります。
「よくある事例」にもあるように、なんとなくプロジェクトが進んでしまう、なんてことはどこでもよくあると思います。
いつまでも**気持ち悪い状態**が続くのが耐えられなくなりました。

Scrumは、Qiita読む人だったら、聞いたことある人もいると思うので、詳しくはググってください。
[5分で分かる、「スクラム」の基本まとめ](https://www.atmarkit.co.jp/ait/articles/1208/07/news128.html)

ざっくりいうとチームで仕事を進めるため枠組み（ルール？）を使って、上手いことプロジェクト進めようぜっていうものです。
今風なソフトウェア開発ではよく用いられている手法で、アジャイル開発手法の一種です。

僕は冒頭でも書いた通り、[LED-Camp](https://swest.toppers.jp/LED-Camp/)の実行委員で、たまたま、一応、Scrumを学んだ身でした。

**だから、Scrumやってみっか**、となったわけです。

## ステルスScurmマスター

とは言っても、Scrumって、ルールはシンプルですが、そのルールを持ってリアルに進行するのって難しいんですね。
Scrumやりたい人はもちろん、チームメンバもそのルールを理解する必要があるのと、
**この手法の価値を理解してくれないと結構きついです。**

そこで、僕は、「メンバが気づいたらScrumやってた」状態を目指すため、
**ステルス(自己満)Scrumマスター**になることを決意しました。ちなみに、Scrumマスターとは、Scrumの枠組みを理解してリードする人のことです。

ちなみに、自己満でやるとなぜ良いかというと、
Scurmを回すための負担が僕にしかかからないからです。それゆえ、他のメンバーの負担は少ないため、文句とか言われません。
これで、プロジェクトうまく進んだら、良いっしょ。

## 楽に管理するために

前述した通り、Scrumはリアルに続けるのがしんどいので、楽にするために、
以下のような緩いルールでやってみることにしました

- 1週間：1スプリント
- プロダクトバックログ、スプリントバックログは作るが、価値づけ、作業量の予測はやらない
- タスクの完了の定義は必ずやる
- デイリースクラム（日々のふりかえり)はやらない
-　スプリントのふりかえりはチャットベースでOK
- 適宜MTGは開く

一人で自己満Scrumするためにも、なるべく楽に運用しています。

## プロジェクトマネージするためのツール群 on docker

正直、枠組みをもってマネージするとなると、ツールが必須になると考えています。
しかし、ツール導入が面倒なのは本末転倒です。そこで、Dockerの出番です。まじ、Dockerしゅごい。

実際に活用しているツールを紹介します。
基本的に、Dockerでデプロイできて、かつ`docker-compose up`できるサービスしか使っていません。
docker-composeがいいところは、以下につきます。

- バックアップがクソほど楽
- サーバ移動もクソほど楽
- デプロイがスーパー楽
- 既存環境を壊さない

### Gitlab

用途：コード管理
メリット：コード類のバージョン管理できる
デメリット：Git知らん人いる

**所感**
有名すぎるので、特にコメントなし。

**Docker関連**
[Docker ComposeでGitLabを起動](https://qiita.com/str416yb/items/2932052a6ead78c167e4)

### Growi

用途：Wiki
メリット：Markdownでかける
デメリット：あまり見当たらない

**所感**

- ほんとに気持ちよく書ける
- UIが綺麗
- Markdown知らなくてもいい
- Web内エディタがかなり優秀
- HackMDなる機能があり、同時複数での編集可能
- 検索エンジンも搭載するため、検索性がよい
- マジパナイ

**Docker関連**
[GROWIをDockerで構築する(CodiMD連携)](https://qiita.com/tsumtsumyuma/items/7f0922cb00c6e14280b9)

### Openproject

用途：プロジェクト管理
メリット：綺麗にプロジェクト管理
デメリット：カンバンが有料

**所感**

- redmine的、プロジェクト管理ツール
- Scrumのサンプルプロジェクトが既に用意されているため、真似すればOK
- このツールはScrumのために一番使うので、少し詳しめに別記事で紹介する予定です。

**Docker関連**
[【簡単】OpenProjectを4ステップでインストールする方法](http://kakedashi-xx.com:25214/index.php/2020/10/16/post-986/)

## 今の所のScrum回し方

1. メインタスクと称し**プロダクトバックログ**を作成　on Openproject
1. サブタスクと称し**スプリントバックログ**を　on Openproject
1. プロダクトバックログのアイテムはフェーズに応じて時系列で並べ、検討とかもアイテムに加える。
   <br>システム構想→技術課題抽出→開発要素の絞り込み→機能レベルのアイテム
1. 各アイテムをガントチャートを用いて制限時間を設ける
1. 各タスクに完了条件を定義
1. 1週間ごとにタスク状況をメンバにヒアリングして、タスク状態更新

## 一旦まとめ

- プロジェクトマネージ、最近大事だと思っている
    - しかし、プロジェクトマネージに理解、興味ある人はそんなに多くないと思っている（偏見）
- メンバに負担をかけない自己満Scrumでプロジェクトマネージ
    - しかし、自分も楽できるようなルール作り＋ツール選定

後日、Openprojectの運用例について記事にしたいと思います。
また、このScrumに関しては始めたばかりなので、振り返りは少し時間が経ってからしたいと思います。