こんにちは。saki( @yensaki )です。 社内では pixivFACTORY の開発リーダーとRailsエンジニアをしています。
さて、プロダクト開発では時折、開発メンバー全員で数ヶ月かけるプロジェクトもあると思います。pixivFACTORY でもそのような取り組みはあり、何十個ものタスクが発生します。このようなプロジェクトの進め方は多種ありますが、今回は私が行っている手法を紹介いたします。
フロー
開発フローの概略としては下記のような流れです。
- タスクリストを書き出す
- 見積もりを立てる
- PERT図を作成する
- 見直しを繰り返す
タスクリストを書き出す
まずは開始時点で判明しているタスクリストを書き出します。これはWBSで一般的に行われていることですのでざっくりとだけ紹介します。大まかには洗い出し・細分化を行っています。
洗い出し
プロジェクトの初期段階ですべてのタスクを洗い出すことはほぼ不可能です。ですが、さくっと洗い出せる分はリストアップしたいところです。 私はそれぞれのユーザーストーリーを満たすのに必要なタスク、という観点で洗い出しています。セキュリティタスクなどユーザーストーリーに分類するのが難しいタスクもあるので柔軟にではありますが。
細分化
見積もり視点では、1タスクが20日や30日になっていると都合が悪いです。あまりに曖昧な見積もりになりますし、進捗度合いもわかりません。そのためWBSに則って適切な粒度に細分化します。概ね数日程度で終わり、作業内容が想像できるタスクにします。
見積もりを立てる
細分化したタスクそれぞれに対して見積もりを立てます。見積もりというと「タスクAには5.5日かかります」とピンポイントで言うことが多いですが、その5.5日ちょうどで完了するということはそうありません。開始当初の情報は曖昧でそれほど正確な見積もりはできません。
3点見積もり
上述のように初期に正確な見積もりはできません。そこで、見積もりは範囲で行うものという認識で行い、その幅を見積もるという手法を採ります。 具体的には開発担当者に「最良ケース」の見積もり、「最悪ケース」の見積もり、さらに現実的に「最有力と思えるケース」の見積りの3点を記入してもらいます。1点で見積もると楽観的に考え、最良ケースに近い見積もりをする傾向があるのですが、最悪ケースも出すことであらゆる起こり得る要素に意識を巡らせることができます。
一方で、プロジェクトとしてはどのあたりまでには一定確率で完了しそうか、ということも可能ならば知りたくなります。そのために最有力ケースを使います。最有力ケースは開発担当者の経験による見込み値です。そのため正確とは言えないですが、期待値を求める参考には使えるでしょう。
この3点見積もりでは下記の式で期待値を予測します。最有力ケースに重みをつけてそれぞれ反映した形ですね。この計算結果を含めた4点の見積もりをタスクリストの横に表記して見積りデータとします。
期待値 = (最良ケース + 4 * 最有力ケース + 最悪ケース) / 6
以上は「ソフトウェア見積り 人月の暗黙知を解き明かす」(スティーブ・マコネル/溝口真理子/田沢恵/久手堅憲之) 第9章「専門家の判断」 を参考にしています。
掛けられる時間の割合
また、忘れやすいのですがプロジェクト以外にも各種作業はあるのでプロジェクトに使える時間割合を考慮します。運用系の案件・不具合対応・定例ミーティング・事務作業などでしょうか。これを考慮しないとその分だけ作業が進まずに遅延になってしまいます。
プロジェクトの作業に充てられるのが何割程度なのかはチームで確認し、見積もりの前提認識を揃えておきましょう。 pixivFACTORY では、開発メンバーや時期ごとに充てられる時間の割合も異なるので、日数としては1日8時間で計算し、算出される見積もりはプロジェクトとしての純粋な所要日数としています。
PERT図を作成
タスクを洗い出しても好きなタスクから着手できるわけではなく、他のタスクが完了しないと着手できないケースは多々あります。複雑で把握が困難な場合は PERT図 を活用するとスムーズに整理できます。
PERT図はタスク間の依存をネットワーク図で示したもので、タスクの着手順位を決定できます。また、見積もり日数を各タスクに添えることでクリティカルパスを決定し、プロジェクト全体の所要日数を見積もることも可能です。
PERT図作成ツールは種々ありますが、私はバージョン管理でき、diffの把握や巻き戻しが容易という点でテキスト形式で作成することを好みます。そのため、UMLのコンポジット構造図をベースにしてPlantUMLで作成することにしました。社内で活用している esa はデフォルトでPlantUMLが使えるのでesaを選択しました。
最初は雑にホワイトボードでまとめ、矢印を整理してから esa に清書します。記述しつつUMLのプレビューが確認できるので大変便利です。
また、これは私の場合なのですが、タスクだけでなく状態もPERT図に折り込みます。基本的にはタスク間の依存関係を表す図ですが、複数のタスクが独立して完了することでユーザーストーリーなどの状態が完成する場合は、その状態もPERT図に入れます。
下図を例に説明します。最下部のタスクは独立して完了でき、全てが完了したときに「プレビュー保存機能(が使える)」という状態が満たされます。それに依存して後続のタスクが着手可能になるため、「プレビュー保存機能」というタスクではない状態をPERT図の中に折り込みます。
見直しを繰り返す
上記のようにプロジェクトのタスクを整理しますが、大型プロジェクトは後半になるに従い、曖昧だった部分が明瞭になって気づいてなかったタスクも出てきます。さらに見積もりの誤差も出てきます。
それらを放置してしまうと実態と乖離していくので定期的に見直していくことが重要です。増えたタスクはタスクリストに加えてPERT図にも反映させます。増えたタスクの見積もりを加えるのはもちろん、プロジェクトの進行実績から見積もりが甘いように見えたら適宜修正するべきでしょう。
私の反省なのですが、プロジェクト管理と開発を兼務で行った結果、開発に集中しすぎて見直しが疎かになりがちでした。見直しの旗持ちは開発者と別に置いてもいいかもしれません。
終わりに
私のチームでのプロジェクト管理例を紹介いたしました。組織によって適正なものは異なるのでチーム内でよく相談してみてください。みなさんのプロジェクト管理の参考になれば幸いです。
弊社では、プロジェクト管理にも興味のあるエンジニアやRailsエンジニアを募集中です！
