開発工程管理のポイント

2. 設計工程管理のポイント | 4. 試験工程管理のポイント

3. 実装工程管理のポイント

基本はブレークダウンと統計的管理

担当者が報告してくる進捗率が、あるところでいつまでたっても先に進まなくなる。「今週中には完了します」という報告が、何週間たっても繰り返される。これは実装工程でもよく目にする光景です。原因は単純で、担当者自身が「何と何を作ったら実装工程が完了となるのか」を正確に把握していないことにあります。本当に規模が小さなソフトウェアであれば話は別ですが、規模が一定以上のソフトウェアの全体像を正確にイメージして、進捗状況を正確に把握するといったことは熟練したソフトウェア開発者であっても非常に困難です。

ではどうするかというと、基本はやはりブレークダウンです。ただし、実装工程でブレークダウンを行うのではなく、その前工程でブレークダウンが行われていなければなりません。ウォーターフォール的な要素を持つ開発プロセスの場合には、設計の工程でソフトウェアは適切な数・適切なサイズのモジュールにブレークダウンされているはずです。アジャイル型と呼ばれる開発プロセスの場合にも、何を行わなければならないのかの一覧を、プログラミング(実装)への着手に先立って洗い出しています(ブレークダウンされた各作業は、タスクカードやチケットと呼ばれるもので管理されます)。

ブレークダウンが行われると、ブレークダウンされた要素(モジュール、もしくはタスクカードやチケット)について統計的管理を行うことができます。つまり、「N個のモジュールのうちM個が完成していて、L個の実装に着手できている」というような管理を行うのです。もちろん、要素(この場合はモジュール)によってサイズや実装の難しさに違いはありますから、単純に「進捗率はM/N」(あるいは、Lも加味して{M+L/2}/Nなど)とは言いきれないでしょう。ですが、担当者が「勘」で報告する進捗率よりははるかに正確な状況把握ができるはずです。また、要素ごとのサイズや難易度の差についても、ある程度は対処することができます。第一に、予めなるべくサイズにばらつきがないようなブレークダウンを行っておくということがあります。他と比べて明らかに大きなモジュール、明らかに大きなタスクは、もう一段ブレークダウンしてサイズをできるだけ揃えるように努めるべきです。第二に、開発者は要素ごとのサイズや難易度の違いを認識しているはずなので、それをヒアリングしましょう。「N個のモジュールのうちM個が完成していて、L個の実装に着手できている」という定量的管理を行いつつも、「ただし、サイズが大きい○○モジュールと難易度が高い××モジュールが残っているので、進捗率はM/Nよりも低い」というような定性的な情報も併用してください。

図1. 実装工程管理の方法

「実装工程」のカバー範囲に注意

実装工程の管理では、一つ気をつけなければならないことがあります。それは、「実装工程」と定義されている工程に、コードの単体試験が含まれているのかどうかということです。これは、開発者によって方針が大きく異なるところです。また、同じ開発者であっても、状況に応じて方針を変えるということはよくあることです。テスト駆動開発(コーディング・プログラミングに先立ってテストを用意しておく開発スタイル)の場合には必然的にコードの単体テストが実装工程に含まれますし、純然たるウォーターフォール開発を志向した場合には実装工程とコードの単体テストの工程を切り分けるかもしれません。

一言に「実装工程が完了した」と言っても、コードの単体テストを含んでいたのといなかったのとでは、出来上がったプログラムの質が格段に違います。開発完了までに要する残りの工数もまるで異なります。したがって、実装工程にコードの単体テストを含むのか含まないのかは、計画段階で明確にしていなければなりません。また、稀に見かける「コードの単体テストを行うかどうかは、実装担当者に任せる」という方針も問題があるでしょう。体系的・統一的な品質管理ができなくなりますし、進捗管理も非常に複雑になってしまいます。

図2. 実装工程にユニットテストを含む場合と含まない場合

無料小冊子のお申込みはこちら

株式会社システム計画研究所のオフィシャルサイトはこちら

通信・ネットワークシステム開発に関するご相談はこちら

サーバ監視・ネットワーク監視ツール isNetSentry-S のサイトはこちら

信頼できるITシステムの開発と利用を支援する技術情報提供サイト「信頼のシステム開発.COM」はこちら