アジャイル開発の原価管理（中編）工程とコストドライバー

前編では、ハードウェア製造業とウォーターフォール開発の原価管理についてみてきました。中編では、アジャイル開発の原価管理について探っていきましょう。

特に、アジャイル開発において原価企画的な発想は可能なのか、フロントローディングは機能するのか、これらを中心に考察します。

それぞれの工程

原価、特にライフサイクルコストを考える上で工程の概念が欠かせません。ソフトウェア開発の工程、特にウォーターフォール開発では、

• 企画
• 設計
• プログラミング（製造）
• テスト

といった、作業の順番や段階を示すことが多いでしょう。工程から工程へと順次アウトプットが受け渡されていく段取りです。

しかしこれらの段取りをソフトウェア開発上の工程とするには、少々疑問があります。

ある工程が完了しそのアウトプットを、次の工程にインプットする。
もし、その工程が完了しているのであれば、アウトプットの品質は保証されていなければなりません。つまり、

• ある工程におけるアウトプットの品質が検証できなければならない。

ということです。検証可能でなければ工程ではないといえるでしょう。

検証可能ということは使って試せるということです。使って試せなければ工程とはいい難いのではないでしょうか。

例えば「設計」。設計を終えた段階ではその設計が正しいことを試す術がありません。ソフトウェアはインテグレーションを実施したその後でなければ本物で試すことが出来ないのです。

前編でも触れたように、実際に使って試せなければ検証可能とは言えません。
アウトプットつまり次の工程へのインプットが検証できないのですから、工程とはいい難いのです。

そのため、企画、設計、プログラミング、テストなどを、ソフトウェア開発の工程と考えるのは少々無理がありそうです。ハードウェアの開発工程は、試作品を文字どおり「作り」そして「試して」いますから工程であるといえるでしょう。

ハードウェアの工程

開発と製造が分離

ハードウェアは開発工程と製造工程が分離されています。開発工程では試作品と製品設計情報が、製造工程では使用に供するための製品が、それぞれアウトプットされます。

開発と製造が分離されたハードウェアにおいては、

という特質を利用してフロントローディングを実現しています。

開発段階で既にコストドライバーがつくりこまれているため、製造工程では原価改善は微々たる効果しかあげない。それゆえ企画設計段階のいわば源流から「コスト」のみならず「納期」や「品質」もつくりこむ活動がフロントローディングです。

また、ハードウェアでは開発と製造が分離されているからこそコンカレントエンジニアリングやクロスファンクショナルチームによって、（さっさと試すための）フロントローディングを実現したといえるでしょう。

ハードウェアは、開発と製造が分離されていることをうまく利用しています。

ソフトウェアの工程

設計と製造が同時進行

ハードウェアの場合には開発と製造が分離されています。一方、ソフトウェア開発、特にアジャイル開発では設計と製造（実装）が同時に進行しています。

一般に製造と呼ばれるプログラミングは、詳細な論理構造を明確にする設計行為でもあり、既に決定された設計情報に基づいただけの単なる製造とはいえません。 つまりソフトウェアでは設計工程と製造工程が同時一体として進行しているのです。決して分離してはいません。

ソフトウェア開発の工程とは実際に試せる単位、検証可能な単位でなくてはならず、それは顧客にとっての価値が発生する「1機能のつくりこみ（設計/コード/テストの一連の作業のまとまり）の単位」、「反復の単位」あるいは供用の単位である「リリース」である。と考えるのが妥当ではないでしょうか。

ソフトハードの違い

ソフトウェアとハードウェアでは、特徴にいくつかの違いがあります。

この差を越えて、あるいはこの差を利用して、ハードウェアにおける原価管理の知見をソフトウェア開発へと持ち込むことが必要でしょう。

ソフトウェア開発のコスト

ソフトウェア開発のコストについて（前編でも述べましたが）、アラン・M・デイビスは、自身著作『ソフトウェア開発201の鉄則』でこう述べています。

下の左側の図のように、時間が経つにつれて右肩上がりになるということです。

左側の図のようにならないよう、時間が経過しても平らに（上図の右側のように）する。つまり、時間の経過にかかわらず変更コストを一定にする作戦をとれれば、アラン・M・デイビスの主張する現象を回避することができるでしょう。

アジャイル開発の工程

ハードウェアの場合、開発工程の後工程は製造工程でした。では、アジャイル開発の場合はどうでしょうか？

アジャイル開発は、顧客が利用可能な単位である「ストーリー」ごとに設計、コード、テストを実施する増加的（インクリメンタル）な開発です。また、1～2週間のイテレーション（またはスプリント）と呼ばれる期間を1単位として反復的（イテレーティブ）な性質もあります。さらには、1～複数のイテレーションごとに実際に顧客へのリリースを実施します。

さきほど、

と述べました。

であれば、アジャイル開発の場合、開発工程の後工程は開発工程である。といえそうです。

アジャイル開発のフロントローディング

アジャイル開発の工程をストーリー、イテレーションあるいはリリースなど機能単位で完結すると捉えることで、フロントローディングの考え方が応用できそうです。つまり工程のより上流で、不具合やコストドライバーを検知し、削減抑制することで品質をつくりこみ、ライフサイクルコストを下げ、製品リリースの時間を短縮することを狙えそうだということです。

それには、アジャイル開発のコストドライバーを明確にする必要があります。

アジャイル開発のコストドライバー

コストドライバーとはコストの発生要因のことです。さらに、アジャイル開発では、開発工程の後工程は開発工程でした。開発工程の前工程も開発工程です。「前工程である開発工程」がつくりこむ「後工程である開発工程」におけるコストドライバーは以下の2点であるといえるでしょう。

• 改修の難しさ
• 試験の難しさ

開発工程の後工程は開発工程。つまり改修に改修を重ね、改修のたびに試験を繰り返すアジャイル開発では、改修そのものの難しさ（容易さ）と試験の難しさ（容易さ）がもっとも大きなコストです。
しかも改修の対象は（不具合・故障の改修であっても、機能の追加・更新であっても）予想できません。事前にすべてを予見し計画することは不可能なのです。

品質特性

ISO/IEC 25010では、ソフトウェアの品質特性をいくつかに分類しています。そのうち「保守性」はソフトウェアの改修・機能更新を有効に効率的にできる度合いであるとされており、保守性もさらにいくつかの副特性に分類されています。上に述べた「改修の難しさ』や「試験の難しさ」は、保守性の副特性である「修正性」や「試験性」に該当するでしょう。 修正性とは品質を低下させることなく安定的に修正できる度合いのことであり、試験性とはOK/NGが判定容易な試験を有効的に効率的に実行できる度合いのことです。

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

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

また、修正性や試験性とともに「解析性」や「モジュール性」も保守性の副特性として挙げられています。解析性とは欠陥故障の原因のわかりやすさや改修箇所の特定のしやすさの度合いであり、モジュール性とはソフトウェアを構成する要素が他の要素に影響を与えないように分離されている度合いのことです。よって、解析性やモジュール性は、修正性や試験性に大きな影響を与える要因であるといってよいでしょう。

また、解析性やモジュール性はソフトウェアの構造に起因する特性であり、修正性や試験性も同じくソフトウェアの構造に起因する特性であるといえます。

EoCとEoT

コストドライバーとして挙げた「改修の難しさ」や「試験の難しさ」は、修正性や試験性のネガティブ表現であり、それぞれ「EoC（Ease Of Changing：修正容易性）」、「EoT：（Ease Of Testing）試験容易性」と呼ばれることがあります。

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

もっとも、フロントローディング（負荷の前倒し）とはいえ、アジャイル開発では初期に負荷が偏るのではなく、下図の右側のように平坦な負荷状態になります。

とはいえ、アラン・M・デイビスの主張する「後期に負荷が偏る現象（上図の左側）」と比較すると、相対的にはフロントローディングされています。

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

参考文献

• Alan M. Davis (原著), 松原 友夫 (翻訳).『ソフトウェア開発201の鉄則』.1996-3-22.日経BP.ISBN-10:4822290026
• ケント・ベック,『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』. ピアソンエデュケーション. 2000/12, ISBN-10:489471275X.
• 永和システムマネジメント.平鍋健児.『XP：EXtreme Programming：ソフトウェア開発プロセスの新潮流 -前編：XP概要とその周辺-』.2002-04-15.情報処理43巻4号.書誌レコードID AN00116625
• Mary Poppendieck, Tom Poppendieck. “Implementing Lean Software Development: From Concept to Cash”. Pearson Education, 2006, 304p, ISBN 978-0321437389.
• Ken Auer(原著),Roy Miller(原著),平鍋 健児(翻訳),遠藤 真奈美 (翻訳),高嶋 優子 (翻訳),山田 禎一 (翻訳).「XPエクストリーム・プログラミング適用編―ビジネスで勝つためのXP」.ピアソンエデュケーション. 2002/08,ISBN-10:4894715554
• 日本工業規格『システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル』JIS X25010：2013(ISO/IEC 25010：2011)
• 平鍋健児. An Agile Way『ソフトウェア開発とフロントローディング』.
  https://blogs.itmedia.co.jp/hiranabe/2008/01/post-3a7f.html
• 和田卓人.『質とスピード（2020春版）』.
  https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition