ソフトウェア要求をヒアリングしていくと、要求を出した人達が何をしたいのかが分かってくる。要求を良く理解する事で、システム要件が整理でき、結果としてシステムの品質を上げられる。以下に成功例と失敗例を挙げる。
【成功事例】チラシ同梱機能の修正①
商品発送時に宣伝チラシを同梱するシステムを改修する事になった。最初にヒアリングしたとき、顧客が出してきたシステム要件は以下であった。
■ 最初のシステム要件
チラシA、B、CをまとめてチラシXにしたので、システムもそれに合わせて修正してほしい。
■ 修正前のシステム
調べてみると、システムは以下の状況であった。
〇 商品ごとに同梱するチラシを決めて同梱を行う。
- 商品A → チラシA
- 商品B → チラシB
- 商品C → チラシC
これを顧客の出してきた要件そのままに修正した場合、おそらく以下になるだろう。
■ 修正後のシステム(案1)
- 商品A → チラシX
- 商品B → チラシX
- 商品C → チラシX
■ 整理後のシステム要件
しかし、もうちょっと要求を掘り下げてみると、システム要件を整理できる事が分かった。整理した後のシステム要件は以下である。
- 定期お届け商品発送時にチラシXを同梱する。
商品A,B,Cは全て定期お届け商品であり、それらの商品の発送時に同梱するチラシをチラシXに統一した、という事であった。
■ 修正後のシステム(案2)
整理後のシステム要件に従えば、そもそも商品ごとに入れるチラシではなく、定期お届け商品に入れるチラシという事になるので、システムの改修は以下になるだろう。
- 定期お届け商品(商品A,商品B,商品C, …) → チラシX
案1と比較したとき、この方式には以下の利点がある。
- 商品ではなく、定期お届け商品という商品カテゴリにチラシが紐付いている事が明確になる。
- 今後新しい商品が販売されても、カテゴリだけ決めれば自動的にチラシの同梱要否が決定されるため、変更に強い。
-
チラシを同梱するべきか否かの判定ロジックが一か所にまとまるので、システムがシンプルになり、改修にかかる工数を削減できる。
■ まとめ
顧客の要求をヒアリングする中で、システム要件を整理でき、案2にたどり着いた。案2の一番良い点は、顧客の要求をそのまま実装している点である。
【失敗事例】チラシ同梱機能の修正②
これは焦って実装して失敗した例である。
■ システム要件
定期お届け商品をお届けするにあたり、3回発送するごとに他の商品を紹介するチラシを同梱してほしい。
■ 修正前のシステム
定期お届け商品の発送回数を指定して、チラシを同梱する機能があった。
■ 修正後のシステム
発送回数指定のチラシ同梱機能に、今回向けの指定を追加する事にした。
追加する指定回数は以下である。
・3,6,9,12,15
こうする事で5回は同梱できる。5回以上の定期発送が発生したら、またデータ指定を追加する。
■ この修正のデメリット
- システム要件と実装があっていない。「3回ごと」というシステム要件を実装するのは容易であるにも関わらず、「指定回数でチラシを同梱する」という別の機能を使っているため、一々データを正しく設定しなければならなくなっている。これでは手間がかかり、間違いが起きる可能性も高くなる。それはまた、保守要員の作業が増える事でもあるので、人件費という形で費用もかかる。
- 修正後の同梱仕様を画面で確認すると、指定した回数が画面上に羅列され、「3回ごとに同梱する」という設定になっているのか確認できない。3回ごとなのかどうか、自分で数えて判断する必要がある。
■ なぜ失敗したか
顧客の要求をシステム上で表現できていない事が失敗の原因である。システム要件を実現するために別の機能を代用したため、手間がかかり、かつ分かりにくいシステムになってしまった。
幸い、このシステムを修正する事は容易であり、単に指定回数ごとにチラシを同梱する機能を追加してやれば良い。
【全体のまとめ】
システム要件を整理する事が根本的なリファクタリングになる。
システムが複雑になっている要因を以下のふたつに分けて考えてみる。
1. システム要件自体の複雑性
上記の例のように、システム要件を整理する。これはシステム要件のリファクタリングであると言っても良いと思う。
2. ソースコードが整理されていない
システム要件を素直に表現したコードにしていくのが大切であると思う。後はいわゆるコードリファクタリングであるが、この記事の目的ではないから省略する。