Screaming Loud

日々是精進

プロジェクトを始める前に確認しておきたいこと

Web開発などをスタートする際に、どういうスタートを切ればいいかに困った、プラス、プロジェクトを始めるという経験をして振り返ったときに、こうすればよかったみたいなのがあったので、次のプロジェクトではそれを活かせるように書き留めておこうと思います。

実装よりもまず何をゴールにするか

とりあえずで作り始めるのは、形にしてみないとどうなるかわからないという不安から動いてしまうケースだと思います。 ただ、とりあえず作るというのはゴールが見えていない作成物なので、結果作ったものは結局プロトタイプで、プロダクションに出せるものではありません。 アウトプット期間を短くしたいなら、ゴールを決めたほうがいいかと思います。

じゃあどういうゴール?

何を作りたいかを決めるのは当然のことだと思いますが、どこまで作るのか?ということを握るのが、かなり重要だと思います。 特にステークホルダーがいる場合は、そこといついつまでにどこまで作るかをしっかりすり合わせていないと、炎上する可能性があります。

ゴールを作った上で、マイルストーンを作るのは結構ありかなとも感じました。

もちろん、そのマイルストーンステークホルダー、プロジェクトメンバー全員で共有するということは必須です。

マイルストーンを決めることで、チームのスピード感などが認識できるので、軌道修正の際にわかりやすいと思います。

チーム開発における決まり事

チーム開発をスタートさせる際に、これだけは決めておいたほうがいいと思ったものがいくつかあります。

  1. アプリケーション構成
    暗黙で分かるなんてことはなく、結構みんなの認識はバラバラで、ここにないと思ったっていう会話はかなりもったいないと思います。 レイヤー構成とか、コード規約とか先に決めないとどんどん皆の向き先が乖離していきます。

  2. 仕様書を更新できる環境を作る
    つなぎ込みが多く発生するアプリケーションの場合は、とにかく仕様書を書かないともめます。

  3. 情報を集約する
    メモ - 炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita にも書いてありますが、誰に聞けば分かるという情報を集約する人を決めることが結構重要かなと思いました。

  4. KPT的な振り返りを定期的に行う
    チームでどこが良くてどこが悪かったみたいな話を共有することで、軌道修正をしやすくできます。

一緒に飯を食う

これはどうかわからないですが、普段から昼飯とか一緒に食べてるとコミュニケーションコストが下がって、意見を言いやすくなるのかなと思いました。 ここは、かなり推測ですね。

人生の中で経験できるプロジェクトの個数には限りがあるので、しっかり振り返って次に活かしていきたいですね。