« アジャイルではなく「プロトタイピング」を | トップページ | 「WEBサービスで稼ぐ企業の業務システム」のモデリング »

2016.08.03

「仕様の的確さ」と「アプリ品質」のバランスをはかる

 前回記事で「仕様の的確さ」をプロジェクトの初期段階で確保することが重要だと説明したが、「仕様の的確さ」と同程度に重要な軸がもうひとつある。アプリの品質、つまり、「アプリが仕様どおりに動作すること」である。そして、「仕様の的確さ」と「アプリの品質」の経時的変化を考えることで、プロジェクトの状況がよくわかるし、プロジェクト運営に関する貴重なヒントも得られる。

 まずは各量の意味を定義しておこう。「仕様の的確さ」とは、「整合的かつシステム導入の目的にかなう仕様要素の含有量」として、これを「適仕様度」と呼んでおく。「アプリの品質」とは、「適仕様かどうかはわからないが、仕様どおりに動作するソフトウエアの含有量」として、「適アプリ度」と呼んでおこう。やや概念的だが、いずれも測定可能な量だ。

 まず、納期に至っても「仕様が的外れだし、アプリの品質も悪い」という残念プロジェクトの様相を見よう。そのようなプロジェクトでは、図1のような経時変化が起こっている。適仕様度も適アプリ度も緩慢にしか推移していない。

図1.「仕様が的外れでアプリの品質も悪い案件」のテコ入れ効果
20160803_1_2

 このようなプロジェクトではたいてい、最終段階になって大量人員の追加投入によるテコ入れがなされるのだが、問題は解決しない。図中で示したように、テコ入れによって適アプリ度が改善されても、適仕様度が改善されないからだ。なぜか。「アプリ品質の劣悪さ」が「仕様の的外れ具合」を覆い隠してしまうためだ。「仕様どおりに動作するアプリ」を用いてユーザが仕様の的確さを検証できないのだから、当たり前である。

 仮に、テコ入れ時に仕様が的外れであることに気づけたとしても、その問題に対処するには、主任設計者をすげ替えてDB設計からやり直すような荒療治が要る。しかしさすがにこれは実施困難なので、人員を増やしても工期を伸ばしても、適仕様度がなかなか向上しない――それがデスマーチの痛ましい実相である。

 では、「アプリの品質は良いが、仕様は的外れ」なプロジェクトはどうだろう。そんなプロジェクトが本当にあるのかと思われるかもしれないが、適仕様度に大きな注意を払わずに「テスト駆動」などの品質管理手法ばかりを徹底すると、そんなアダ花が生みだされる。いくら適アプリ度が良かろうが、適仕様度が悪ければ失敗プロジェクトであることに変わりはない。

 ただし、その失敗は案外顕在化しない。品質が高いゆえに、納期に至ってクライアントも開発者も何やら満足して、プロジェクトはいったんカットオーバーできてしまうからだ(図2)。運用が安定した頃になって、システムがひどく使いにくいことが明らかになる。しかし、莫大な費用を投下した結果なので、本格的な見直しは次の刷新まで先送りにされる。それまではユーザや保守担当者が苦労する。

図2.アプリの品質は良いが仕様が的外れな案件
20160803_2_2

 こんどは、「仕様は的確だが、アプリの品質は悪い」プロジェクトだ(図3)。上述したように、アプリ品質の劣悪さが仕様の的外れ具合を覆い隠してしまいがちなので、そのようなケースは少ないだろうが、あるとすればまだまともなプロジェクトといえる。なぜなら、テコ入れ策がそれなりにうまく作用するからだ。ただし、納期は先送りになるし、テコ入れ費用についてはベンダーが負担することになるので、悲惨であることに変わりはない。

図3.「仕様は的確だがアプリの品質は悪い案件」のテコ入れ効果
20160803_3

 つぎに、「仕様は的確だし、アプリの品質も良い」ケースを見よう。図4のように推移すると思えるかもしれないが、これは悪い例である。このパターンでは「品質は良いが仕様が的外れなアプリ」が余分に生み出されるからだ。それらのアプリは捨てられるか修正されることになるので、開発メンバーが無駄に残業する羽目になる。「(うまくいった場合の)アジャイル手法」はちょうどこんな形になりそうだ。

図4.仕様が的確でアプリの品質も良いが、非効率
20160803_4_2

 では、「品質は良いが仕様が的外れなアプリ」を作らないためにはどうしたらよいのか。図5のような動きを狙えばよい。すなわち、適仕様度は「フロントローディング(前積み)」で、適アプリ度は「バックローディング(後積み)」で進める。まさに、適アプリ度については「あわてる乞食はもらいが少ない」のである。

図5.仕様が的確でアプリの品質も良く、効率的
20160803_5_4

 そうは言うものの、アプリの仕様が的確であるかどうかを知るのは簡単なことではない。少なくとも、アプリを仕様どおりに作って動かしてみなければ、どうしてもわからないところがある。どうすればよいのか。

 「本番実装」の前にモデリングやプロトタイピングを実施すればよい(図6)。初期フェーズでは、モデリングツールを使って大胆に試行錯誤を重ねながら仕様の大枠を確立する。モデルとしてまとまったら、それをプロトタイピングツール上で仕様書に変換する。すると仕様書は「仕様書どおりに組み立てられたアプリ」として動作するので、これを使って適仕様度をさらに高める。その後で、「的確さが検証された仕様書」にもとづいて、一挙に本番アプリを製造する。結果的に「品質は良いが仕様が的外れな本番アプリ」の無駄が最小限度に抑えられる。

図6.モデリング&プロトタイピングの効果
20160803_6_4

 興味深いことに、「モデリング、プロトタイピング、本番実装」の局面分けは、従来型手法である局面開発法(ウォーターフォール方式,WF)での「基本設計、詳細設計、製造」に意味合いがきれいに対応する。異なる点は、それぞれの局面を支援する「専用ツール」を用いているかどうかだ。

 WFの問題として、基本設計や詳細設計において専用ツールで成果物を管理することを強制していなかった点を指摘できる。Excelあたりの汎用ツールを使っていては、適仕様度どころか仕様の整合性を確保することさえ難しい。しかも作業効率が極端に悪いので、無駄に多くの人員が要る。専用ツールを使えば、通常の案件規模(参考記事)であれば、プロトタイピングまでひとりの開発者でまかなえるのとは対照的だ。結果的に、WFでは図7のように推移する。けっきょくのところ、「アプリの品質は良いが仕様が的外れ(図2)」の類型である。

図7.ウォーターフォール方式の効果
20160803_7

 まとめよう。人員の追加投入、工期延長、テスト駆動、アジャイル、WF、といったさまざまな施策は、製造段階までに仕様の的確さが確保されていなければ意味がない。とどのつまり、それらの施策の必要性とも関係なく、「仕様の的確さを大急ぎで高めること」こそが、システム開発の成功のカギである。あなたのプロジェクトの「適仕様度」はいかがだろう。

<勉強会のお知らせ>
2016/08/12関西勉強宴会「モデリング&プロトタイピング基礎と演習」

|

« アジャイルではなく「プロトタイピング」を | トップページ | 「WEBサービスで稼ぐ企業の業務システム」のモデリング »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「仕様の的確さ」と「アプリ品質」のバランスをはかる:

« アジャイルではなく「プロトタイピング」を | トップページ | 「WEBサービスで稼ぐ企業の業務システム」のモデリング »