はじめに

みなさん、こんにちは。テクノロジックアートの設楽と申します。この度、アジャイル開発についてのコラムを連載させていただくことになりました。よろしくお願いします。

日々アジャイル開発に携わっておりますが、ここ1,2年でアジャイルに対する風向きが随分と変わってきているように感じます。具体的には、ボトムアップに先鋭的な開発者が普及に奔走していた頃と比べると、組織として本格的にアジャイルに取り組むところが増えてきています。

そのような中、本連載では、アジャイル開発をこれから導入してみようという方向けに、「⁠そもそもアジャイル開発ってどういうものなんだ?」という疑問の答えを、再整理してみたいと思います。

アジャイル開発については、一言で本質を言い表すのはなかなか難しいものがあります。既に、変化の抱擁とか、俊敏な開発とか、早くて安い、みたいなものまで多種多様な表現をされています。ある意味、いずれもアジャイルの特性を表現しているのですが、誤解を与えがちな表現とも言えるでしょう。そこで、本連載では「透明性」というキーワードで、その特徴を説明していこうと思います。

第一回である今回は、「⁠透明性とは何か?」についてご説明します。簡単に言うと、風通しを良くしておかないと変化には適応できないよ、という話です。最初に、変化とは何かについて整理しておきましょう。

変化を歓迎するアジャイル

アジャイル開発は、変化に強い開発手法です。変化とは、環境の変化でもあり、要求仕様の変化であり、最終的には仕様変更として表出するものです。なぜ変化への強さを求めたかというと、顧客の本当に欲しいもの(=ニーズ)は、顧客本人ですら事前に明確に定義(=要求仕様)することは難しいという状況に対応するためです。ニーズと要求仕様との間のギャップを解消する必要があります。

例えば、あるソフトウェアの受託開発の現場を想定します。完成し納品後、顧客から使ってみて初めてわかる要求がでてきました。

「もっとこうなっていればよかったのに。。。」

これは、本来あったニーズを、要求仕様としてまとめあげることができなかったことを意味します。新たに出てきた要求仕様を実装する為には、仕様変更として二次開発を発注することになるでしょう。このようなニーズと要求仕様のギャップは、最初からキチンとニーズを分析・整理していれば回避できたコスト(=無駄)とであると考え、極力開発に着手する前に回避すべく働くのがこれまでの考え方でした。

しかし、アジャイル開発では違います。

開発の途中・途中でフィードバックをすることで、ニーズの再認識を促し、一次開発の途中で要求仕様を変更する機会を顧客に提供します。開発途中でも軌道修正(=仕様変更)をすることで、無駄を最小限に抑えようとするのです。

そのやり方が正しいという論拠としては、開発期間中に環境変化で要件が変わってしまうくらい変化の激しい状況を考えているというのが一面にあります(ニーズそのものの変化)。また、解決したい問題の本質は、問題を抱えている本人にすら分からない、といった要件定義段階での困難さへの解決方法という側面もあります(認知によるギャップ)。更には、上流工程で抽象的なレベルで顧客のニーズを掘り出すよりは、実際に動くものを見ながらの方が結果的に低コストで要件定義できるというコスト面の優位性からの判断でもあるのです(低コストでのギャップ解消)。

このように、現状の要求仕様が、本当に顧客のニーズとマッチするのかを絶えず検証し、可能な限りそのブレを修正していくのがアジャイル開発手法のスタンスです。つまり、アジャイル開発においては、変化はニーズと要求仕様のギャップの検出ととらえ、積極的に見つけ出していくものなのです。

変化を受け入れるには透明性が必要

アジャイル開発では、変化を受け入れることがポイントとなることを説明してきました。具体的には、以下のようなアプローチがあります。

• ニーズの再検証等により、認知されたニーズと実装と間のギャップを発見します。(変化の検出)
• 変化に伴い軌道修正をするかどうかを正しく判断する必要があります。(変化の判断)

そこで必要になるのが十分で正確な情報の伝達です。もともとソフトウェア開発においては、現場のニーズと成果物の適合性が問題になることが往々にしてありました。これは、認知されたニーズと要求仕様の間のギャップ、もしくは、要求仕様と実装のギャップに大別できます。

前者のニーズと要求仕様のギャップは、上述のように、要求仕様策定当時からのニーズの変化や潜在的なニーズの認識違い、もしくは要求仕様策定時のニーズの取り違いにより発生します。後者の要求仕様と実装のギャップは、要求仕様の曖昧さに起因することが多いです。

このように、ソフトウェア開発においては、随所に情報の伝達を阻害し、ニーズと実装の食い違いを引き起こすコミュニケーションの壁があります。それらの壁薄くして、開発者と、実際のニーズを持つ顧客(所有者/ユーザ)との間で、密な情報交換ができるようにすることが大切です。すなわち、壁を薄くする = 「⁠透明性」を高めることが必要になるのです。

顧客にとっての透明性

顧客が開発者のやっていることが見えなかったとしたらどうでしょう?アジャイル開発では、開発開始時点では成果物に対する明確な最終形を想定できないことが通常です。すなわち、最終的な成果物の完成リスクを、一部顧客の手元に残すことを意味します。そのような状況の中では、開発の中で何が行われているのか不透明ですので、開発が終了しないと成果物を見ることはできません。顧客がとても不安になるであろうことは想像に難くありません。

開発の透明性を高めるとは、成果物の進捗状況が手に取るように分かり、どのような作業をどのような順番で実施し、どのような問題が起きていたのかがを顧客が閲覧可能にすることです。また閲覧できるのみならず、随時、意思決定を行う機会を与えることが必要です。作業内容を変更したり、作業の順番を変更したりする機会を、適切なタイミングで提供することで、顧客は間接的に開発を制御し、リスクを回避することが可能となります。開発の軌道修正できる自由を手にすることで、より付加価値の高いソフトウェアを手に入れる可能性が生まれます。このメリットがあってはじめて、顧客は安心感を得ることができるのです。

このように開発に関する透明性を顧客に提供することは、アジャイル開発を実施する為の前提条件となります。

開発者にとっての透明性

開発者が顧客の要求が見えていなかったとしたらどうでしょう?アジャイル開発では、詳細設計が固まる前にコーディングに入ります。そしてプログラム一人一人が自分の作成するコードのテストを事前に作成しながらコードを成長させてゆきます。すなわち暗黙的な設計作業を、一人一人のプログラマが実施しているのです。テスト作成や設計作業を行うには、自分がこれからコーディングする機能の意味を理解していなければ、テストコードを作成することはできません。テストに表現した仕様の正しさを顧客に確認する機会がなければ、ただの思いこみにすぎません。

要求仕様の裏にあるニーズを理解することで、移り変わる要求仕様に伴う影響範囲を正確に見積もることができるようになります。そして顧客の判断に必要な適切なフィードバックを返すことができるでしょう。

コードのことを一番よく分かっているのは開発者です。顧客にとっても、開発者側に要求に関する詳細を十分に理解してもらい、適切な見積りと十分な情報提供を得ることは、自分自身が正しく判断を下す為には欠かせません。

つまり、要求に関する透明性を開発者に提供することは、アジャイル開発を実施する為の前提条件となるのです。

フィードバックのスパイラル

このように、実際の利害関係者をつなぎ、「⁠透明性」を高めることで、開発者は、情報(要求仕様等)を正確に受け取り、顧客にフィードバック(成果物等)を返します。顧客は、情報(成果物等)を受け取り、開発者にフィードバック(要求仕様等)を返します。そうすることで、より要求仕様は真に顧客が望むものへと洗練され、成果物はより要求仕様を正しく反映したものへと進化してゆくことが可能となります。

要求仕様の変化が、成果物の姿を代え、成果物からのフィードバックが、要求仕様を変える。

こうしたフィードバックの連鎖でソフトウェアを成長させる、スパイラル型のコミュニケーションこそが、アジャイル開発の基本であり、成功させる秘訣でもあります。このようなスパイラル型コミュニケーションを促進するような頻繁なフィードバックこそが、高い「透明性」の正体なのです。

少し抽象的な話が長くなってしまいました。次回以降では、具体的にどのような仕組みで「透明性」を確保しているのかについて解説してゆきたいと思います。