ソフトウェアテストからプロジェクトマネジメントを眺めてみると・・・

先日、TEF(ソフトウェアテスト技術者交流会)東海の方々と名古屋市内で飲む機会がありました。
私もメンバーとして活動しているPMI日本支部 中部地域サービスとTEF東海でコラボ企画をやろう!という話が以前から持ち上がっており、その第一弾でとりあえず合同飲み会をすることになった、というのがこの飲み会の経緯です。
TEFはソフトウェアテスト技術者、PMIはプロジェクトマネージャを対象とするコミュニティですので、双方の観点から様々な意見が出されて非常に有意義な飲み会でした。
いろいろお話を聞いているうちに、「ソフトウェアテスト」を基点にプロジェクトマネジメントを考えることにより、PM活動がもっと楽しくかつアクティブ(上手い表現が見つかりません・・・)なものになるのではないか、という考え(妄想)が私の脳の中に湧いて出てきたので、忘れないうちに書き留めておこうと筆を取った次第です。
1.「手戻り」の正体
ソフトウェア開発において最も大きなムダの1つが「手戻り」であることに異論は無いと思います。手戻りが発生する要因としては、コミュニケーション上の齟齬であったり、判断ミスであったりと様々ですが、「手戻りが発生した」ことが発覚するきっかけがテストであることが多々あります。
プロジェクトマネジメントの視点でいうと、こうした手戻りは「教訓」として次のプロジェクトなりイテレーションに活かすべき、ということになるのですが、日々発生する細かい「手戻り」はあまり把握できていないのではないかと思います。(物凄いインパクトを与える手戻りはずっと記憶に残りますけどね・・・)
細かい手戻りも積み重ねてみたら「山」になっていた、ということもあり得ますので、PMとしては日々発生する「手戻り」を見える化する仕組みを作っておくべきなのかも知れません。
2.テストで得た知見をプロセス改善に活かす
教訓を活かす、という意味では 1.と若干被りますが、テストで見つかった障害の根本原因を探っていくと、開発プロセスそのものに問題があった、というケースがよくあります。(ここでレビューしておくべきだった、インタフェース部分の設計が不足していた・・等)
もちろんプロジェクト固有の特性もあるので注意は必要ですが、次のプロジェクト/イテレーションへの気づきとして活かさない手はありません。
3.テストの目的は品質の検証だけではない
ソフトウェア開発におけるテストの目的として、「出来上がったプログラムが正しく動くかどうか検証すること」だと考える人は多いと思います。
もちろんそれも大きな目的の1つですが、これだけがテストの全てだと捉えると途端にテストがツマラナイものになってしまいます。
ソフトウェアテストには

  • 開発を推進する
  • 進むべき道が正しいことを示す
  • 改善への気づきを与える

という重要な側面があることを見逃してはいけません。
これはテストエンジニアの方がよく強調することで、私も本当にそのとおりだと思います。
例えば、テストで得られた結果を開発者に随時フィードバックすることで開発のリズムを作る、プロジェクト全体がどの方向(悪い方向か?良い方向か?)に向かっているかの判断材料に使うなど、品質保証以外にもテストの持つ役割は多岐に渡ることが分かります。
4.監視・コントロール
プロジェクトマネジメントには様々なプロセスがありますが、それらはすべて「立ち上げ」「計画」「実施」「終結」そして「監視・コントロール」のいずれかに分類されます。(この5つを「プロセス群」と言います)
3.で書いた「プロジェクト全体が正しい方向に向かっているかどうかを評価する」という活動は正に「監視・コントロール」に該当します。やはり、テストとプロジェクトマネジメントは切っても切れない関係にあるのです。
5.計画
4.であげたプロセス群のうち「計画」もテストとは密接に関わってきます。計画段階における最も重要なアウトプットが「プロジェクト計画書」ですが、ソフトウェア開発においては「テスト計画」がプロジェクト全体の計画に与える影響が大きいと(個人的には)考えています。
テスト計画はプロジェクト計画の一部であるだけでなく相互に作用し合っている、とでもいいますか・・・
6.リスク管理
テストの観点でプロジェクトを見つめ直すことで、リスク管理にも役立ちそうです。プロジェクトマネジメントにおけるリスク管理の活動をざっと書き出すと、

  • リスクの洗い出し
  • リスクの評価
  • 対応策の検討
  • リスクの監視
  • 対応策の実施
  • 対応策実施の評価
  • etc

があげられます。
これをプロジェクト期間中継続して行うのですが、特に「リスクの洗い出し」の部分でテストエンジニアの知識や経験を活かすことは非常に有効なことだと考えます。
7.データモデルの正しさをいかに検証するか?
「データモデル」という言葉自体は、プロジェクトマネジメントとは直接関係ありません。ただ「データモデルは顧客の業務を表現したもの」だと考えると、ステークホルダー間でスコープを共有するツールとして、プロジェクトマネジメント的にも重要な存在だと個人的に考えています。
特にプロジェクト初期の段階で作成したデータモデルがイマイチだと、システムの品質にも重大な(悪い)影響を与えます。(まさに「プロジェクトの進む方向を誤る」)
「データモデルが正しいことを検証する手段はないものかなぁ」と前々から考えていたところ、12月14日に実施されたDAMA日本支部の分科会で「データモデルの抽象化」に関する発表の中で「実際のデータを入れてシミュレーションすることでデータモデルの正しさを検証する」というお話を拝聴する機会がありました。
これを「テスト」と呼んで良いものかどうか分かりませんが、プロジェクト初期の段階で「プロジェクトが正しい方向を向いているか」を担保するという意味でも非常に興味深いお話だったので、紹介させていただきました。
さいごに
いろいろと脈絡もなく書き連ねましたが、テストとプロジェクトマネジメントは互いに絡み合うところが多く、両者の知見をうまく活用し合うことで、プロジェクト活動がもっと効果的で楽しいものになるのではないでしょうか。( ´∀`)b
(終)
**参考書籍**