昨日、アジャイルで開発すると品質は高くなるのか？という話を書いた。
そこで書いた話は、
・仕様がまとまっていない段階でも、アジャイルでは開発に入れるが、
・そうすると、度重なる仕様変更がおこり、
・プログラムが崩壊し、
・デスマーチ化する
という話だった。
で、今日は、その「仕様がまとまっていない段階で」どうして、開発に入らないといけないか？っていう話です。
■要求仕様がまとめられないから
この理由は、一言で言うと、
「要求仕様がまとめられないから」
この結果、要求仕様の段階で、結構月日がたってしまう。
そーすると、後工程が遅れてしまうので、最悪の「できたところからやろう」という発想になる（＝できないところはいつまでたってもできない。それをやるとき、大幅仕様変更になり、無駄になるかもしれないけど、ともかく、やってしまう）。
そのため、わかんないところをブラックボックス化して開発してしまう（とりあえず、クラスとメソッドを作って、ダミーを返す）。もう、要求仕様の段階で時間が足りないのだから、テストも、単体は省略となる（というか、アジャイルでやっていて、とくにJUnitでやっている場合、青くなっているのでコーディング完了と判断したわけだから、その時点で単体テスト完といわれても、まあ、間違いじゃない）。
で、結合に入るが。。
そもそも、要求仕様がまとまらないのであれば、要求仕様に矛盾があって当たり前で、そうすると、結合でその矛盾は露呈し。。仕様変更となる。。そのうち仕様変更が何回もおこり、崩壊していく。。。
つまり、要求仕様がまとまらず、開発期間を押してくるので、見切り発車せざるを得なくなるが、それにアジャイルは向いているということです。でも、要求仕様がまとまってないんだから。。。品質は低いですよね。
なお、開発期間を押さないケースでも、要求仕様をあいまいに定義するという場合もあります。この場合も、アジャイルは向いているということです。でも、要求仕様があいまいだから。。。品質は低いですよね。
■要求仕様がまとまらない理由
では、問題は、要求仕様がまとまらない理由です。
で、この前書いたとおり、もし、完璧なヒアリングができているのであれば、その後工程というのは、もはや、述語をどうする、名詞句をどうするというレベルで、ER、DFDないしはUMLの図やクラスに展開できます。
ってことは、完璧なヒアリング（にかぎらず、業務の情報収集）ができないってことです。あともうひとつのケースがあって、無茶なことを要求するって言う場合もあります。そのフレームワークでそれはできないってっていうかんじ。。
まとめると、こんなかんじ
（A)無茶な要求
→そもそも、できないってことを営業が気づかない(気づいていてもあおる）
新しい技術で本当はできるかどうかわからない(実はだれも成功してない）
そのSE、営業自体、本当は知識がない（会社や業界には成功事例はある）
可能だが、期間的、予算的に無理！
：
（B)完璧な情報収集(ヒアリング、帳票分析ふくむ）ができない（業務も要望も）
B-1、SEに、情報が伝わらない、情報収集できない
→ヒアリングで言ってる内容をSEが理解できない
関連業務などをSEが知らない
B-2、会社が業務を表現できない
→業務は、矛盾なく、滞りなくできているが、それを言葉で的確に
表現できない。要望も、的確に表現できない
B-3、会社自体、本当は業務をちゃんと行ってない
→適当なローカルルールや臨機応変という名の恣意的な判断で
どうにかこうにか回っているので、業務自体、決まったやり方がない
→新規事業で実は、だれもやったことはない。
→改善案なのだが、それでできるかどうかわからない。
この場合、B-2,B-3の場合、誰がやっても、ユーザー自体が言葉にできないのだから、それをヒアリングしても、要件はまとまらない。
で、会社の業務スピードが上がり、十分な引継ぎもできず、専門外でもやらなければならない昨今、ユーザー企業は、B-2,B-3のケースに陥っているケースが多いと思う。
■もはや業務すべてを言語化できない
つまり、ユーザーは「もはや業務すべてを言語化できない」状態に陥っている。
したがって、SEのほうで、業務をみきって、まとめる力がないと、要件はいつまでたってもまとまらない。
でも、SE自体も業務知識を軽視し、UMLなどの技術論に向かう傾向にある。
ここで、UMLをどんなにやっても、ユーザーが、「業務すべてを言語化できない」のだから、システムには仕様漏れがでる。
結果として
ユーザーは「もはや業務すべてを言語化できない」
↓
SEも、業務知識は軽視しているので、業務をみきって、まとめる力はない。
↓
その結果、言語化されない仕様漏れ、
言語化しなかったことによる論理矛盾や勘違いが生まれ
↓
それを見切り発車すると
↓
どっかで矛盾が発覚し
↓
仕様変更となり（仕様変更が続発し）
↓
そのうち、プログラムが崩壊し、単体レベルのバグが多発してきて
↓
システムが崩壊し
↓
デスマーチ化する
っていう構図になっていると思う。
■つーことは
すんげー単純な話、各業界の業務を標準化し、明確化(言語化）し
自社はどこが違うかだけを明示すればいいようにすればいいんだよね。
そのためには、いままでの技術中心から、業界知識中心(中心までしなくていいけど、多少重視）に方向転換すればいいんだけど。。
それをしてないってこと。。
アクセス
トータル
ランキング
