アジャイル開発の原価管理（後編）品質とコスト

中編では、アジャイル開発においては「改修の難しさ」や「試験の難しさ」がコストドライバーであり、EoCとEoTを高めることが、アジャイル開発における原価管理の要諦であり、フロントローディングであると述べました。

ここでは、アジャイル開発ではどのようにEoCやEoTを維持向上させているのかをみていきます。

コストドライバーの制圧

ウォーターフォール開発におけるコストドライバーの制圧方針は、「計画どおりにやる」、「間違えないようにやる」ことでした。コストドライバーは設計時に決定済みであるため、分業しやすい設計や経験済みのノウハウ（フレームワーク、チェックリストなど）の横展開、あるいは専業分業体制によって、コストドライバーを制圧してきたのです。

これに対してアジャイル開発では、開発工程の後工程が開発工程であるため、コストドライバーを常につくり込み続けるリスクがありました。このため、コストドライバーそのものを最小化する作戦をとる必要があります。変更しやすい（EoC）設計、試験しやすい（EoT）設計でコストドライバーを制圧する必要があるということです。

それはすなわちEoCとEoT、ISOでは修正性と試験性、そして解析性とモジュール性を向上させるように、ソフトウェア構造を維持改善し続けるということです。

アジャイルプラクティスで制圧

アジャイル開発では、コストドライバーをいくつかのアジャイルプラクティスで制圧しています。
アジャイルプラクティス、具体的にはXP（eXtreme Programming：エクストリームプログラミング）のいくつかのプラクティスです。

XPのプラクティスのうち、『開発のプラクティス』と呼ばれるプラクティスを見てみましょう。

• ペアプログラミング
  1台のPCを使い、2人で一緒にプログラミングします。
  実装だけではなく、調査、設計、実装、テストなどの開発作業をペアで一緒に実行します。問題の発見、解決策の実行が即座に実施されるため、機能提供の時間が短縮されるとともに品質が向上します。テストプログラムも同時に作成実行するため、よりテストしやすく、わかりやすい実装と設計が2人の視点で磨かれていきます。
• リファクタリング
  外部から見た動作を変えずに、ソフトウェア構造を改善します。
  自動化されたテスト（あるいは、手動で実施すべきテストが明らかになっていること）が必須です。テストとは仕様そのものであり、仕様を変化させずに、わかりやすく、テストしやすく、他の構成要素に影響を与えない構造へと継続的に改善させます。
• テスト駆動開発
  まずテストプログラム（＝仕様）をつくってから実装する開発です。
  仕様とは単体レベルから機能レベルまでの仕様を含みます。つくるものを明確に絞って順に実装し、デグレードなく機能と品質を積み重ねます。そしてその過程にはリファクタリングが必須であり、ソフトウェアの設計を継続的に進化させます。
• 継続的インテグレーション：CI（Continues Integration：常時結合）
  開発中のソフトウェアを自動的にかつ即座にビルド、テストします。
  「いつでも出荷できる状態」を継続的に保つことが目的です。「統合、テストされていない時間」を最小化することで問題の発生をすぐに検知し意図せぬ不具合の混入を最小化します。
• YAGNI
  そんなものは必要にならない。You Are not Going to Need It. あるいは、 You Ain't Gonna Need It.の略です。いま要るものだけを必要最小限に実装します。
  要るかもしれない（というだけ）ものをつくりこめば、設計や実装の複雑度は増し、テストも必要となり、同時着手の仕事（WIP：Work In Progress）も増え、統合のリスクも増します。またリードタイムも長くなるため、不具合の検知も遅れ改修のコストが増加します。 YAGNIはこれら設計や実装の複雑度、統合のリスク、回収コストのリスクを最小化します。

このように、これらのプラクティスはソフトウェアの保守性を成す修正性（修正容易性、EoC：Ease Of Changing）や試験性（試験容易性、EoT：Ease Of Testing）を直接的に高めるとともに、修正性や試験性に寄与する解析性やモジュール性も高めています。

表「品質特性～システム／ソフトウェア製品品質」

（日本工業規格 JIS X25010：2013(ISO/IEC 25010：2011)を参照して作成）

XPのプラクティスはコストドライバーを制圧しているといってよいでしょう。

マネジメントプラクティス

ここまで見てきたXPのプラクティスは、技術的プラクティスであるといわれているようです。しかしそうでしょうか？

図 『Planning and feedback loops in extreme programming』（wikipedia "Extreme programming"https://en.wikipedia.org/wiki/Extreme_programmingより引用）

上図を眺めてみると、そうではないように思われてなりません。PlanningとFeedbackのループ、しかも大小さまざまな相似的なループはマネジメントサイクルを表していると判断せざるを得ません。

XPのプラクティスはマネジメントプラクティスである。ただし技術がなければ実践できないマネジメントプラクティスである。といえるでしょう。

しかも秒単位から月単位までの相似ループは、品質、コスト、デリバリー、スコープを同時にマネジメントするサイクルであると見てとれます。コストだけを切り離してマネジメントしている訳ではありません。アジャイル開発（特にXP）では、WIPを絞ってデリバリーを短縮し、インクリメンタル＆イテレーティブなプロセスによって品質を積み上げると同時に、コスト（コストドライバー）を制圧する作戦をとっているといえます。

チームの能力と開発者のスキル

ここまで、アジャイル開発ではプラクティスによってコストドライバーを制圧すると述べました。しかし、プラクティスは制圧の機会を確保しているにすぎません。機会を利用してEoCやEoTを向上させているのは開発者であり、開発チームに他なりません。

下図は、テクノロジーコラム「アジャイル開発とは（中編）スクラムとエクストリームプログラミング（XP）」で紹介した、アジャイル開発プロセスの概要です。

開発プロセスのアウトプットは、ソフトウェアだけではなく「改善されたプロセス」、「新たに生み出されたプラクティス」そして能力が高まったチームメンバー（開発者たち）であることを示しています。この図に示したイテレーションサイクルだけではなく、図 『Planning and feedback loops in extreme programming』で示した（秒単位から月単位まで）大小さまざまなサイクルの中で、個人の知見や知識が伝搬され、開発技術者のスキル、チームの開発能力が向上します。コストドライバーの制圧だけではなく、制圧能力自体も高めているのです。

エンタープライズアジャイルの原価管理

テクノロジーコラム「大規模アジャイル開発の可能性（後編）アジャイル開発は大規模に耐えられるのか？」で、

と述べました。「統制と自律の調和」とは「トップダウンとボトムアップの調和」であり、「コストとスピードの調和」は、「規模とスピードの調和」です。これはつまり、ウォーターフォールとアジャイルの調和に他なりません。

「統制と自律の調和」、「コストとスピードの調和」という課題をハードウェア製造業では既に気づき解決していました。
JIT（Just In Time）です。

アジャイル開発にあっても、エンタープライズアジャイルの進展による大規模化が進めば「なにをどれだけつくるか？」の変動がコストドライバーになります。これを制圧するための解決策がPPMになり得そうです。

最後に

ウォーターフォール開発に慣れ親しんだ方々の中には、「アジャイル開発では、リファクタリングやペアプログラミングなど、コスト増を招くだけで機能性を高めることもない習慣を推奨している」と、眉をひそめる方もまだまだいらっしゃいます。原価低減による利益確保を習慣としてきた方々にとっては当然の発想なのかもしれません。

確かに、リファクタリングやペアプログラミング、それにテスト駆動開発も付加価値や機能性を高めることは無いでしょう。しかし、これらはコストのみを高める活動ではなく、コストドライバーを制圧する活動です。制圧能力を高める活動なのです。

実は、ハードウェア製造業にもリファクタリングに似た活動があります。

5Sと呼ばれる活動がそれです。製造工程おもに生産現場で活動するのが5S（整理：Seiri、整頓：Seiton、清掃：Seisou、清潔：Seiketsu、躾：Shitsuke）です。要るものと要らないものを分けて要らないものを捨てる、あるべき場所にあるべきものを格納する、いつでも使えるようにする、誰が見てもわかりやすい状態を維持する、ルールや規律を習慣づける。これらの活動のことです。

製造業の方々は概ね5Sの活動を大切にされています。これらの活動はそこで働く人々の意欲や能力を高め、原価低減に寄与します。しかし、既に開発工程で決定済みのコストドライバーを製造工程で制圧することは叶いません。

原価企画やフロントローディングなど、ハードウェア製造業によって培われた知見を持ち込むにあたり、開発工程でつくり込まれ得るコストドライバーをアジャイルプラクティスによって制圧することは、『ソフトウェアであること』そして『ソフトウェアは開発と製造が同時進行すること』をうまく利用した原価管理であるといえるでしょう。

参考文献

• Kent Beck. “Extreme Programming Explained: Embrace Change”. Addison-Wesley Professional, 1999, 224p, ISBN 978-0201616415.
• Kent Beck, Cynthia Andres. “Extreme Programming Explained: Embrace Change”. 2nd ed., Addison-Wesley Professional, 2004, 224p, ISBN 978-0321278654.
• Roy Miller.“「XP の真髄」に立ち戻る 第1回 XPの誇大宣伝を詳しく検討する”. IBM Developer Works.
  https://www.ibm.com/developerworks/jp/java/library/j-xp0813/(配信 2002-08-01).
• Roy Miller, Christopher Collins(共著).“XP の真髄 Javaプロジェクトにおいてより大きな成功を収める方法 - XPは私達に何をもたらすのか”. IBM Developer Works.
  https://www.ibm.com/developerworks/jp/java/library/j-xp/ (配信 2001-03-01).
• Wikipedia 『Extreme Programming』
  https://en.wikipedia.org/wiki/Extreme_programming
• 日本工業規格『システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル』JIS X25010：2013(ISO/IEC 25010：2011)
• 門田安弘. “トヨタプロダクションシステム―その理論と体系”. ダイヤモンド社, 2006/02, ISBN 978-4478460085.