計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

「なぜウチではうまくいかないか?」を考える開発コンテキストの解説

»

「別のところでうまくいったと評判の技法、テクニック、プロセス、プラクティスを自分が関わるソフトウェア開発に適用してみたが、いまいち期待はずれだった」ということは誰にでもあるだろう。単純にマネるだけではうまくいかないことが多い。その理由はソフトウェアやプロジェクトを取り巻く状況が多岐にわたり、それらが同一か類似でないと、期待する効果が出ないからだ。

技法、テクニック、プロセス、プラクティスの成功要因の解釈方法の1つに「コンテキスト(開発の状況や事情等、文脈といえるようなもの)」と「結果」をセットにする方法がある。たとえば「A, B, Cの状況下(コンテキスト)では、技法Xは期待通りの効果をもたらす。それは、BとCという前提とXの間で整合性がきちんと取れているからだ」のように解釈する。で、マネをしようとしているソフトウェアの文脈がB, Cとどれくらい類似していたり、一致していたりするかを解釈し、期待通りの結果をもたらすかを推測する。

たとえば、コードレビューは一部のコンテキストにおいて非常によい結果をもたらす一方で、別のコンテキストでは時間がとられるだけで、特に効果を得られないという状況を想定してみる。今後20年以上メンテナンスすることが決まっていて、機能追加リリースが頻繁に実施されることがわかっている場合のコードレビューと次のバージョンで再設計、再実装が決まっているソースコードを対象として実施するコードレビューでは、同じやり方でコードレビューを実施しても得られる効果が異なる。「20年以上で頻繁に機能追加リリース」「次のバージョンで再設計、再実装が決定している」がコンテキストに該当する部分。コンテキストに応じて活動の価値もかわる。

コンテキストを明確にして結果を評価するというのは、エンピリカルソフトウェア工学で推奨されている評価、考察の方法だ。うまくいったのは、どんな状況下で制約を満たしていたからかという分析を進め、他のプロジェクトやソフトウェアでの効果を推測できるようにする。

ソフトウェアレビューでのコンテキストの話、レビューがもたらす価値の話をEM West vol.2に寄稿しようとしている。目次はこちら

また、7/23開催のソフトウェアテストシンポジウム2010関西の冒頭セッションで、この考え方を説明する。実際にシンポジウム中のたくさんの講演を聴講いただくことで、やり方を体験いただけるのではないかと思う。午前中のセッションだけでも、メトリクス利用を社内に、オフショアでの受け入れテスト、ユーザ視点から見たテスト、と盛りだくさんであり、コンテキストを推測するためにも適している。参加者どうしの議論の場も提供している。シンポジウムの概要と参加申込みはここから。

Comment(2)

コメント

森崎先生。例えば、レビューの目的をはっきりはせる前に、その目的が必要なるコンテキストの説明が必要という風に考えることができるのでしょうか?

そのとおりです。まずは、目的とコンテキストをあわせる必要があります。
どういう条件下でどのような目的を設定するかという点が重要です。

コメントを投稿する