ソフトウェア開発における工数を見積もるということについて

ソフトウェア開発において、重要な作業であるのが工数見積もりです。
ソフトウェアを開発することよりも重要かもしれません。

コストの管理であったり、スケジューリングであったり、要員管理であったり、様々なことに影響するのが「工数」なのです。
それを適切に見積もらなければ、スムーズなソフトウェア開発は不可能です。

工数とは一体なんなのか

ソフトウェア業界では必ず登場するキーワードが「工数」です。
工数とは多くの場合「一人当たりの作業時間」を意味します。
単純に、一人の作業者が作業を行った場合、どのくらいの時間を要する作業なのかを示す数値です。

この数字に基づいて、当該ソフトウェアの完成時期を早めたければ、人数を増やすことになります。

例えば、一人で160時間を要する作業があった場合、二人でやれば80時間、三人でやれば…と、単純計算されます。
実際には単純計算で表現できるわけではないため、工数には様々なリスクを加味して計算していかなければなりません。

工数を計算する

工数を計算するには様々な手法がすでに存在しています。
単純なことで言えば、ソフトウェアを完成させるためには、まず以下の作業が必要になってきます。

  • 要件定義
  • 基本設計
  • 詳細設計
  • ソフトウェア実装
  • 単体試験
  • 結合試験
  • 運用試験

▲これらの作業がどのくらいかかるのかを具体的な数値にしていくのです。
これは単純なようで、非常に難しく、また経験が重要である部分もあるため、工数見積もりを行う者は相応のスキルが問われます。

新人プログラマーが上司に作業の見積もりを求められた場合は、それはある意味では「ひとつ成長」した証とも言えるかもしれません。
上司から「いつまでに終わらせろ」ではなく、「いつまでに終わる?」に変わったタイミングは上司に成長を認められた嬉しいタイミングとも言えます。

もっとも、上記の各種作業を全て見積もらせてもらえる日は当分先になると思います。

作業を細分化する

結局のところ、よく言うように工数の見積もりは細かな作業を積み上げていくことで算出します。
しかし、作業を全て抽出できなければ大きな見積もり謝りに繋がります。

そのため、作業の細分化は非常に重要な作業です。

上気した各種作業を細分化していきたいと思います。

要件定義

多くの場合、このフェーズの工数は度外視することが多々あります。
これが決まらなければ、何を作れば良いか決まりませんし、その他の作業をどのように組み立てれば良いかわからないからです。
また、顧客との打ち合わせであったり、各種メンバが集合する必要があったりと、それぞれのスケジュールが重要となってくる場合もあります。

多忙なメンバーは集まることさえ困難なこともあり、要件定義の実作業そのものが滞ることもあるわけです。

これは、ほとんどのプロジェクトで当てはまると考えていますが、工数は費用につながるわけで、要件定義の工数について明言しておく必要はあるかもしれません。
例)要件定義は工数を算出できない。要件定義が決められなければその後の作業の工数を算出できない。

上記の基本的な情報を認識していない顧客・メンバも存在する可能性があるからです。

また、要件を定義する上で、実現可能性を検証する必要もあります。
この作業も重要であり、要件定義が完了したにもかかわらず、いざ実装してみたら無理だったなんてことは言語道断と言っても過言ではありません。

基本設計

要件定義に基づいて「基本設計」を行うわけですが、要するにソフトウェアとしての振る舞いを定義していきます。
その際に重要なことは、以下の登場人物にとって、理解できるドキュメントになっていることです。

  • ソフトウェアの利用者
  • ソフトウェアの実装者
  • ソフトウェアの評価者

利用者にとっては、多くの場合「基本設計書」が神様となるでしょう。
そのため、利用者にとってわかりやすいドキュメントである必要があります。
また、実装者にとってもこのドキュメントをもとに後の詳細設計などに落とし込んでいくわけです。
そして、出来上がったソフトウェアの評価を行うメンバはこのドキュメントに基づいてテスト項目をピックアップしていきます。

少なくとも3者の視点で理解できる資料になっていなければならないため、これは非常に難易度が高いと言えると思います。

新人プログラマにおいては「基本設計書」の作成は一つの目標になり得るでしょう。

そのようなドキュメントの工数見積もりは慎重に行い、様々なリスクを加味する必要があります。

詳細設計・ソフトウェア実装・単体試験

ここ最近は、これらを一つの作業として工数見積もりを求められる場合が多いです。
詳細設計などは、ほとんどソフトウェア実装とイコールである場合があるため、省く場合もあるでしょう。
また、単体試験においてはほとんどがユニットテストツールそのもののテストケース実装であったりします。

結局のところ、詳細設計・ソフトウェア実装・単体試験を見積もっていくわけですが、工数としては1つとして表現することになるかもしれません。

「単体試験」と言う作業においては、試験によって「バグ」が出た場合には修正をする必要があり、さらにはそのバグの再試験を行うことになります。
また、場合によっては修正に伴うソフトウェア全体のリグレッションテストを行って、品質を担保する必要もあります。

そのため、機能数→テスト項目数→テスト工数では見積もり切れません。
修正・再確認のことも考えて見積もらなければなりません。

どのようなリスクが存在し、工数算出した際にリスクに対する説明も必要になってきますので、大雑把な計算はあってはなりません。

結合試験

パーツごとに作ったソフトウェアを組み合わせてブラックボックス的に試験を行っていきます。
残念ながら、よくあるのが結合テスト実施時に機能仕様の矛盾や不備が見つかる場合もあるのです。

ほとんどの場合、このことを想定していませんし、想定するのはおかしな話でもあります。
そもそもこれらの矛盾が発生しないような十分な時間を機能設計時に算出する必要があります。

また、機能設計の正当性を確認する上でも、機能設計直後に結合テスト項目を抽出します。
このタイミングで機能設計の不備を発見できたりすることもあります。

作業時間と品質のトレードオフを加味して、各種作業の順番を考えるの工数見積もりで必要なことと言えます。

運用試験

運用試験というと最終的な利用者が行うテストですが、これらの算出も結合試験と同様です。

しかし、なぜだか結合試験よりも違った観点の問題が見つかったりすることがあります。
結合試験で品質が担保されていると思い、運用試験の工数を減らしてはいけません。

試験の観点が異なるため、改めてテストとして妥当な時間を考え、もちろんバグなども考慮する必要があることを覚えておく必要があります。

まとめ

簡単にいうと、工数見積もりは細分化した作業やリスクを積み上げていくといった単純作業です。
しかし、いかにして作業・リスクを抽出するのかと言えば、経験などから培われたものが多いのは事実です。

抽出したリスクについては、その重要性であったり根拠を明言する必要があります。
経験の話ばかりで頭でっかちになると、必要以上の工数となる場合もありますし、状況やプロジェクトに応じて柔軟に組み替えていく能力も必要になってきます。

また、失敗から学ぶことも多いことをよく覚えておきたいものです。
(なるべく失敗はしたくないんですけどね。)

あわせて読む

コメントを残す