はじめ

どうもこんにちわダニーです。
今回は、上流工程のプロジェクト工数出しに参加したお話をブログにしようと思います。
この記事は上流工程の見積もりの経験が浅い方向けな記事となります。

経緯

たけむら「ダニーさんこのプロジェクトの工数出しやってくれない？」
という話で唐突に上流工程に参加することが決定しました。（若干フィクション入れてます。若干ね😉）

言わずもがなですが、上流工程とはシステム開発・設計をするときに最初に行う作業です。

やったこと

今回は開発を開始するかの判断のために、まずどれぐらいの規模なのか？を把握するための工期の初期見積もりがほしいというオーダーを完了するのがゴールとなります。
そのため今回の見積もりの範囲は下記となります。

要件定義
基本設計
工数出し
- 各工程の工数
- スケジュール・影響範囲一覧作成（WBS）

今回は私含めて

の3名で見積もり作業に挑戦しました。

プロジェクトの企画の概要説明

まずは見積もり作業をするためにどんな開発なのか？を知るためにプロジェクトの概要をたけむらさんより説明をしてもらいました。

今回のプロジェクトは現行の外部サービス連携の仕様更新に伴い

バッチ処理
フロントエンド
バックエンド
データベース
管理画面
外部データ連携
etc …

など広範囲に影響が発生するということで、全体の影響範囲の規模とその改修にかかる工数の初期見積もりするということがわかりました。

※このときの私は「うわぁ・・・影響えっぐ・・・」と内心聞いててドキドキでした。

まずは3人で打ち合わせ（MTG）

プロジェクトの概要を聞いた後に、

認識の共有
作業内容・方針決め
作業分担

などをするためにMTGをぐっさん・かきびぃと開催。
認識としては「影響えっぐ・・・どこから手を付けて行きますか・・・」など概ね大変そうだなっていう認識は一致してましたｗ
次に作業内容・方針については、「まず見積もりするには何が必要か？」って話になり、

まずは要件の再確認と定義決めていきたいよね？
そのためには影響範囲の洗い出し（リスト化）をしつつ要件の定義を書いていく感じになるよね？
要件決める上で分からない部分はPO・PMに質問する必要あるよね？
そうなると、資料や情報をまとめておく場所もいるよね？
見積もりに関するスケジュール感ってどんな感じなんだろうね？
etc…

という感じでやること（やらないと進まないこと）はたくさんでした。

とりあえず毎日の作業サイクルを決定

とりあえず初動として、毎日下記のサイクルを回すことに決まりました。

毎日朝会（MTG）
一日にやることの洗い出しと作業分担

毎日朝会

これは影響範囲が広範囲に及んでいるために、要件の抜け漏れ防止や各メンバーが「知っていること」「知らないこと」「わからないこと」の共有と解決するサイクルを毎日できるようにサイクルに追加することにしました。

一日にやることの洗い出しと作業分担

朝会で共有した後に下記をします。

やることの洗い出しと精査
作業の分担
- 要件定義
- 基本設計
- 工数出し

前日の作業進捗具合や最初は全容の輪郭が不透明なところをはっきりさせていったり、次にできること・まだできないことなどを柔軟にメンバー間で分担して進めるためにサイクルに追加しました。

結果としてメンバー間でのコミュニケーションが取りやすく、また柔軟に作業の分担もしやすいというメリットを感じました。
デメリットとしては、全容の把握に時間がかかったところですが今回は影響範囲が広いという点もあったので仕方ない部分もあったと思います。

要件定義

しばらくやることのリスト化と見える化に注力して判断材料が用意出来た辺りから要件定義の書き出しが始まりました。
資料作りにはスプレッドシートやドキュメントを使いました。
組織のデフォルトのツールなので共有ツールとして優秀ですねやっぱり。

基本設計

要件定義作成と平行して要件固まった所から設計書作りも開始しました。
画面設計には「draw.io」を採用。
DB設計は ER図に「draw.io」テーブル定義書はGoogleスプレッドシートを使いました。
個人的に「draw.io」の図面ツールの癖が強くて使いづらかった・・・

工数出し（見積もり）

要件定義・基本設計をしていくことで、具体的な要件のイメージがはっきりした所で朝会のタイミングなどを利用してリスト毎の工数を決めていきました。
弊社では普段見積もりを行う際にストーリーポイントでの見積もりを行いますが、今回は開発期間を出すために工期（人月）での見積もりを行います。
工程としては、

まずはストーリーポイントで見積もる
定義を決める
- 1SP ＝ 3時間
- 人日：1日＝ 5.6時間（8時間の70％で算出、30%は間接費用として算出）
- 人月：1ヶ月＝20日（実働）
上記の定義を元に時間を計算：全体のストーリポイントの合計 ✕ 3（時間）
人日を計算： ③ ÷ 5.6（時間）
人月を計算： ④ ÷ 20（日）

という感じで人日と人月を出しました。
ここからは更に工期計算で具体的な月数を出して行きます。
計算に関して、やってみつつ違和感あれば修正で精度上げていった感じですが、
最終的な計算式は「人月の立方根 × 3倍＝工期（月数）」に収まりました。

JUASによると、2020年の最新調査の資料で「全体工期は全体工数の3乗根（立方根）の2.70倍である。」とされていました。
今回のプロジェクトでは、影響する範囲が広いことから余裕をみて「3倍」で計算しています。
この辺の統計情報の参考値は「人月立方根統計」などでググると JUASの資料やいろんな所で情報公開されているので調べてみるといいかもです。

今回参考にした資料のリンクはこちらです。
ソフトウェアメトリックス調査2020_発表会資料_システム開発・保守調査（PDF形式）
ソフトウェアメトリックス調査・IT運用コストメトリックス調査

まとめ（やってみた感想）

普段は下流工程の作業がメインだったので、上流工程の作業新鮮でした。
今は無事見積もりの作業が一段落しましたが、上流工程の大変さがよくわかりました。
上流工程を経験したことで、作業規模の見積もりや要件についての洞察力が上がったかなと思います。
合わせて自社開発システムについての理解も深まったので、メリットが多かったです。
デメリットとしては、最初は右も左もわからん状態からのスタートになる場合もあるので、その点はやっぱり大変で重要な工程だと思います。

まだ上流工程の経験が無い方・浅い方は、最初は大変ですが良い経験となると思いますので、機会があれば是非チャレンジしてみてください。
それでは今回のブログ以上となります！

Post Views: 736