この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
こんにちは、コンサル部の島川です。
弊社クラスメソッドはANGEL Dojoに参加しています。
実施期間は2020年1月~2020年3月19日、各チームのメンバーは5人でプロジェクトの企画～開発～完成までをやり切ります。日常の業務と並行して進めていきますので、限られた時間の中で成果を出す必要があります。
今回は少し特殊的な状況ではありますが、ANGEL Dojoをどうやって進めているのか？というところをある一日を切り取ってご紹介したいと思います。
ANGEL Dojoもいよいよ大詰めの段階、3/6(金)の最終発表に向けてメンバー一同頑張っております。
※どんな取り組みかについては下記ブログを参考にしてください。
プロジェクトを進める
プロジェクト開発といえば「ウォータフォール」だったり「アジャイル」などの手法があります。弊社チームでは最初「アジャイル」っぽくできたらいいねと話していましたが、以下の理由から明確に手法を決めて進めることが難しかったです。
- 動ける時間が限られていた
- 毎週金曜日をワークDayという形で使います。金曜日以外の平日については講義でAWSサービスはもちろんそれ以外(Gitの使い方)など様々なことを学ぶ時間にあてられます。どうしてもという場合は土曜日も使えたりしますが、実質ちゃんと動けるのは金曜日だけ。
- 毎日集まれる時間がない
- 通常の業務と並行して行います。各メンバー月～木は通常業務に時間を割り当てているので全員同じ時間を確保するのは難しい。
- 全員に同じような開発能力があるわけではない
- 5人中2人は開発経験も能力もありましたが、残り3人はインフラの知識のみでがっつり開発に入ることが難しかった。
どうしたらいいか自分たちで悩んでいてもしょうがなかったので、PM経験のある社員に相談しました。そうしたところ「開発手法に縛られず突貫工事的な感じで進めたほうがいいよ」とアドバイスをもらいました。自分たちでも薄々そう感じておりましたし、今回は特殊な例ではあるので突貫工事まではいかずとも開発手法に縛られずにのびのびやろうと話しました。
ただし全員バラバラに動いては完成に近づくのが難しいので、一日のスケジュールとゴールは固めて進めていこうと決めました。
金曜日の使い方
金曜日(10:00 - 18:00)がめちゃくちゃ大事です。プロジェクトの考案段階では全員同じ作業をしていましたが、開発に入ってからは出来ることに違いがあるため役割を明確に分けて進めることにしました。開発期間の金曜日の一日を切り取って説明します。
金曜日のスケジュール(中間発表後)
中間発表の後でそのまま開発を進める部分、一回考え直さなきゃいけない部分など改めて課題を整理する必要がある状況でした。そのためこの日は開発をやるメンバー、課題を考え直すメンバーに分けて進めることにしました。その時のスケジュールです。
◆この日のゴール
- 最終発表に向けたプレゼン構成が決まること
- 最終発表までに完成する機能が明確になること
- 既に決まっている機能を実装すること
| 時間 | ビジネスメンバー | 開発メンバー | 備考 |
|---|---|---|---|
| 10:00 ~ | 集合＆全体アナウンス | 集合＆全体アナウンス | |
| 10:30 ~ | 一日のゴール共有 | 一日のゴール共有 | GitHubのプロジェクトボードを使用 |
| 11:00 ~ | 中間発表の資料を元に最終発表で話す必要があることをまとめる | 開発 | - |
| 12:00 ~ | 休憩 | - | |
| 13:00 ~ | ホワイトボードで絵に書いてざっと構成を決める/イラストパーツ作成 | 開発 | - |
| 15:00 ~ | 開発チームへレビューを依頼 | プレゼン構成に関しての意見だし | 第三者の意見が欲しかったためこのような形を採用 |
| 16:00 ~ | レビューを元に構成の練り直し | 開発 | - |
| 17:00 ~ | 次週までの個別タスク切り、共有 | 開発 | 共有はGitHubのプロジェクトボード |
| 17:30 ~ | 全体アナウンス＆解散 | 全体アナウンス＆解散 | - |
ある程度時間を区切って整理するタイミング、セーブポイントのようなものを設けることでゴールがぶれることなく進めることができたと感じました。
GitHub Projectでのタスク管理
GitHubのissueを使って課題を作成した後にこのProjectにぺたぺた貼っていくだけです。
これを共有することで、ビジネスチームも開発チームもタスクを共有することができます。さらに現状が追えるので非同期に作業が可能です。スケジュールの中に「17:00 ~次週までの個別タスク切り」とありますが、これは月～木でそれぞれの空き時間で実施することという意味です。
話したことは必ずGitHub wikiにまとめる
GitHubにはwiki機能もあります。あの時何話したっけ...。を防ぐために話したこと、共有したことをwikiにまとめることによりすぐ振り返りができるようにしました。
さいごに
短期間かつ少人数だからがむしゃらに。と思っていましたがそう簡単ではないと思いました。プロジェクトの成功には「目指すところが明確に共有されていること」が大切だと思いました。そのためにはちゃんと話し合って、ちゃんとスケジュール決めるという当たり前のことが当たり前にできている必要があると感じました。
プロジェクトを形にすることは本当に難しいです。このサービスを利用する人は何を求めているのか、何ができたら嬉しいのかなど根本から何度も何度も考え直す必要があります。反面、日々の課題が変わったり、新しいサービス、手法に出会えたりと刺激が多く成長できているなと実感もできます。最終発表まであと少しですがプロジェクトメンバー一同頑張ります！