単体テストの観点がプロマネと開発者では違う
今回はプロマネと開発者での「単体テスト」の観点の違いについて書いてみたいと思います。
このブログを読んでくださってる方は、システム開発のプロマネの方が多いと感じています。そんな中で単体テストの観点が開発者と違っていることに気づいていますか？ 管理人が気づいた違いをいくつか書いていきますのでお付き合いください。
単体テストの観点の違い（プロマネと開発者）
ズバリ結論から書きます。プロマネの管理すべき単体テストと開発者が管理すべき単体テストの観点の違いは次の通りです。
プロマネの観点
機能単位である
これは、機能一覧などで代表される単位を意味しています。エンドユーザーが使う機能メニューなどで使用される単位と考えてもらってよいでしょう。プロマネはこの単位で管理していることが多いでしょう。管理人も通常はこの単位で管理しています。
ただし、数百人月の中〜大規模なウォーターフォールによるシステム開発を想定しているので、もう少し小さい開発規模の場合やアジャイルによる開発では異なることをご承知おきください。
開発者の観点
ユニット単位（クラス単位）である
これは、1機能に含まれるユニット（クラス）単位に管理していくということです。管理人が想定している開発対象は、Java、C＃などで構築するエンタープライズ開発なので、違う言語やフレームワークでの開発では異なることをご承知おきください。
詳細設計〜プログラム設計の間で、ユニット一覧（クラス一覧）を作成しますが、そのユニット単位での管理をしていくということが求められます。
なぜ違うのか
なぜ、プロマネと開発者では単体テストの観点が異なるのでしょうか？それは管理単位の違いです。それではなぜ管理単位が異なるのでしょうか？
管理人は次のように考えています。
- 視点の相違
- 役割分担の違い
視点の相違
まず、視点が違うことが挙げられます。当然、開発者とプロマネでは視点が異なります。それに異論はないでしょう。ではどのように異なっているのでしょうか？
プロマネの視点は？
プロマネはプロジェクト全体を視野に入れています。自社の開発チームはもちろん、お客の主体作業も含め全体を見ています。
開発者の視点は？
開発者は、自分たちの開発対象を中心に考えています。自分の開発対象が完璧であることがまず求められるからです。
差が生まれる
ここでまず大きな差が生まれてきます。当然担務が異なるので当たり前といえば当たり前なのですが、このことを認識していない人たちが多いことが、齟齬を生む原因の一つと管理人は考えています。
役割分担の違い
各工程の役割分担
この記事で意味するプロマネはSier（元請）を指しています。一般的に、Sier（元請）は製造工程をパートナー企業に発注する形態を多く取っています。
一部は自社で開発する場合もありますが、多くは基本設計（概要設計、ユーザーインターフェース設計などとも呼びます）から詳細設計を終えた後の製造工程（プログラム設計〜プログラムテスト）は、パートナー企業の力を借りることが多いでしょう。
管理人の場合は、仕様理解のために詳細設計の工程から一部はパートナー企業のシステムエンジニア(SE)に入ってもらい、製造工程はパートナー企業にお願いするという形態をとることが多いですね。（丸投げではないですよ）
プロマネの管理方法
そこで、Sierであるプロマネはどう管理していくのでしょうか？
プロマネは製造工程全体の管理をパートナー企業に任せるのです。プロマネは機能単位に管理していき、機能単位での進捗・品質を管理していきます。
なぜでしょうか？ パートナー企業と契約する製造工程の契約形態が「請負契約」であることが大きな理由です。請負契約に関しては、次の記事をご覧ください。
完成した成果物は機能単位に納品されます。そのため発注元であるSierは機能単位での受け入れをします。すなわち機能単位でのテストです。よってこの機能単位での管理をしていきます。
開発者の管理方法
製造工程を受託した開発者（パートナー企業）の場合は、違った管理になることは言わずとも知れたことでしょう。
モノを作る上では、さらに詳細な粒度まで落とさないとモノは作れませんから。一つの機能を詳細に分割していき、最終的にはユニット（クラス）やファンクションなどの単位まで落とし、コーディングをします。
そして出来上がったユニット（クラス）単位にテストします。一般的に言われるユニットテストのことです。
そして、完成したユニット（クラス）を結合させていき、最終的には一つの機能として完成します。（ここでも、結合テストの定義が異なります）
このため、開発者はユニット（クラス）単位での管理をしていきます。「ユニット（クラス）が正しく製造されているかをテストする」ということです。
実は結合テストの定義も違っている
そのため、開発者の視点では「機能」のテストは「結合テスト」と読んでいる場合もあります。ここでいう結合は、ユニット（クラス）を結合させていくということです。
プロマネの考える結合テストは、ひとつひとつの「機能」を結合させて、プロセス（またはサブシステム）単位での整合性を担保するテストのことを指しています。
相違があることの問題点
このようにプロマネと開発者とでは、単体テストに関する相違があることがお分かりになったと思います。このことで何か問題が起こるのでしょうか。
プロマネ・開発者双方でお互いの役割や立場を理解していれば、問題は起こりません。しかし、理解していない場合は次のような問題が起こるのではないでしょうか？
- プロマネが作った単体テストで開発者も管理している
- 開発者が作成した単体テストスケジュールでプロマネが管理している
プロマネが作った単体テストで開発者も管理している
これは開発者側が「開発者がやらねばならない管理ができていない」ことを表します。本来ユニット（クラス）単位でのテストをしなければならないこと（すなわちユニット（クラス）単位でのテストエビデンスが必要）が実施できていないということです。
これでは「ユニット（クラス）単位での整合性が取れている担保」が確認できません。結果としてユニット（クラス）を結合した結果のテスト仕様書で合否の判定はできるでしょう。しかし「ユニット（クラス）単位が正常に動作できているのか」といった詳細の把握が容易ではありません。
挙げ句の果てには、プログラム設計書が存在しないか、非常に粒度が粗い設計書の場合があります。詳細設計書に少々追記した程度のものだったりします。
こうなると、さらに先の工程で問題が発覚した場合に、ソースレベルでの調査をしなければならなくなります。
こうならないようにプロマネは、事前に開発者側の管理方法をレクチャしておくことや、随時成果物がきちんと作成されているかを確認することが必要です。
開発者が作成した単体テストスケジュールでプロマネが管理している
これは「細かい管理をしたがる」プロマネが陥る問題です。開発者側が作成した単体テストスケジュールを、自分で管理しようという意気込みは買います。しかしこれを始めると、プロマネに求められるプロジェクト全体の把握が難しくなります。
ユニット（クラス）単位で管理される成果物は、機能単位を1とすれば、少なくとも10倍以上はあるのではないでしょうか？ それをひとつひとつプロマネが管理することは時間がいくらあっても足りないと思います。当然、時間が足りなくなるので、他作業の進捗管理などがおろそかになっていきます。
開発者上がりの若いプロマネが陥りやすいでしょう。管理人のような老獪？なプロマネになると、餅は餅屋ということで、パートナー企業の開発リーダーにある程度任せて、サマリされた結果を眺めながら課題や問題に対処していくような形をとっています。
まとめ
プロマネが押さえる単体テストと開発者が押さえる単体テストの違いについて書いてきました。ちょっと管理人の独りよがりなところもあったでしょうがご容赦ください。管理人の認識違いやご意見等あれば遠慮なく指摘してもらえると助かります。
プロマネとしては、開発者側の管理方法についても当然熟知しておく必要があります。そうでないとプロマネと開発者での視点の違いから、単体テストの定義が異なるので話や議論が噛み合わない場合が発生します。
そのような場合、より上位の視点を持つプロマネが齟齬を起こしている原因を把握し、開発者に寄り添い、視点の違いを説明するなど、歩み寄る姿勢をとってください。
また開発者の立場であれば、プロマネの視点をいきないり認識するのは難しいでしょう。しかし将来プロマネになる可能性もあるので、プロマネの管理方法を学んでおくことも無駄ではないと思います。
そのようにして双方の立場を尊重することで、不要な誤解からくるトラブルを避けられるのではと感じています。