ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。
ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。
プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。
5W1Hを決める
すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。一番最初に明確にしておいたほうがよい。
自分の場合、以下の様に5W1Hを明文化している。
- このプロジェクトはなぜ行うのか、どういう目的で行うのか(Why)
- だれのどういう課題を解決するのか、顧客はどういうものを求めているかなど
- このプロジェクトでは何をするのか、どういう機能を作るのか(What)
- 誰が関係者なのか、Whatに対してそれぞれ誰が担当するのか(Who)
- このプロジェクトはどうなったら完了なのか(Where)
- 締め切りはいつなのか(When)
- 複数の締め切りがあるなら、どのタスクはどの締め切りに間に合わせないといけないのか
- このプロジェクトをどうやって進めていくのか(How)
- タスク管理はどうするのか、コミュニケーションはどのようなツールを用いるのか
この中で一番重要なのはWhy。なぜやるのかというのが明確になっていないと、何をするのかとか、どうなったら完了なのかとかが全て決まらない。
またHowは一番最後に決める。なぜやるのか、何をやるのか、誰が担当するのか、締め切りがいつなのかに従って、適したやり方が変わってくるためである。なのでこういう基本的なことが決まる前にいきなり開発フローとかどういうツールを使うかとかを話し合うのはあまり意味が無いと思っている。
この辺は大体プロジェクトのリーダーが簡単に文章化し、それを元にミーティングをおこなって質問を受けたり議論をしながら、チームの納得のいくものにしていくと良い。
個々の責任範囲を明確にする
5W1Hと並行して、プロジェクトを始めるときには必ず個々の責任範囲を明確にしておきたい。つまり、ある人がどこまでだったら自分の裁量で物事を決めても良いかを明確にしておきたい。
プロジェクトにプロダクトオーナー、スクラムマスター、エンジニア、デザイナーがいたとする。その場合例えば
- プロダクトオーナーは要件の追加や変更を行える。その他の人はプロダクトオーナーと相談なしに追加できない
- スクラムマスターは自分の裁量でチーム全体の開発フローに変更を加える事ができる。それ以外の人はスクラムマスターに一度相談する
- エンジニアは自分の裁量で、エンジニアのみの開発フローに変更を加える事ができる
- デザイナは自分の裁量で、担当しているページのデザインを決めることができる。ただし最終的に決まってから作る前にはプロダクトオーナーに確認を取って欲しい
のように裁量を明確にしておくという感じ。もちろんもうすこし厳密にするか、もうすこし曖昧にするかはプロジェクトの性質によって自由に決めたら良い。
これをおこなう理由としては
- それぞれのメンバーが自分の判断で自律的に動きやすくする
- 自律的に動きやすくなれば、個々の得意分野を発揮しながら良い物を作っていくことができる
- 報告する必要のないことも含め、全てのことをプロダクトオーナーなどに報告してしまい、無駄なコミュニケーションになるということを防ぐ
- 重要な事柄を報告されない、ということを防ぐ
- 自分の裁量で決められるので、モチベーションが向上する
- 人の決めたことをただやるだけだったら、モチベーションが湧かない
- 仕事が分業化され、プロダクトオーナーが全てを見ないといけなくて仕事量が多すぎる、みたいなことが減る
などがある。
上からの命令に従ったプロダクトしか作れなくてモチベーションが湧かないとか、マネージャが忙しすぎて捕まえられないとか、部下が勝手に動きすぎるとか、そういうあるあるネタを防ぐことができるので、責任範囲を明確にしておくのはかなり大事だと思っている。
一つの場所にまとめておく
以上の二点をチームメンバーと共有して、チームメンバー全員の納得が得られたら、プロジェクトまとめとしてどこかに残しておくと良い。普通にA4の紙に書いておいても良いし、Google Docsを利用したり、Githubを利用したり、そのあたりは何を使っても良い。
ただし、気をつけたいことはプロジェクトを進めるごとに、Whenが変わったり、Howをさらに良くしたり、責任範囲の分割の仕方を間違えてたり、ということがあるので、出来る限り編集はしやすくしておいたほうが良さそう。
まとめ
けっこう開発フローの話が話題になるし僕もそういう話は好きなのだけど、自分でプロジェクトを実際に回してみるとそれに至る前に考えないといけないことがいろいろあると思ったのでまとめてみた。そうすると結局5W1Hを全部決めておくことが大事とか、責任範囲を定めておくことが大事とか当たり前のことをちゃんとするのが重要ということが分かってきて面白い。
なんとなく経験でまとめているだけなので、こういう考えもあるのではとか、こういう本読んだら良いとかあったら教えて下さい。
