Backlogを利用したAgileのProject管理でみられる言葉の中に
（〇〇出来る）というものがある

これを用いたのか要件定義書の中の要件内容にこれと同じ文面を見かける事がある
がしかしこの場合において私的にはこの書き方が違和感そのものであり目障りだったりする

要件定義書ならここは機能区分として整理する方が望ましいと思っているからだ
なので小生であればCRUDに特化した機能名と機能区分を明記するだろうか

更に気に触るのは要件定義と称しているのに記載されている内容が要求事項に対する変更内容を羅列してあるだけだったりする

AgileであればここからBacklogに整理しながら仕様のまとめと実装と試験を順に作業していく事になる

だがWHなどの従来の開発手法だとこの様な文書内容では要件定義の根幹となる機能要件定義が不十分のため後続の設計や更にその先の実装で不確かな仕様が作業者に伝わってしまうので却って混乱を招く事になってしまう

AgileはBacklogに仕様をまとめながら優先順位を決めてTaskを話し合って決めていく
なのでBacklogそのものが仕様書として確立していく

一方要件定義から始まる開発であれば現行の機能分析をまず行い現行の機能要件をまとめるものだ

そして要望事項に照らし合わせながら機能要件と非機能要件を整理していくのだ

だから要件定義で（○○できる）だけでは一体なんの事やらさっぱりわからない

この文書を引き継いだ設計は結局要件定義のやり直しを余儀なくされるが既にある設計工数以上の工数を浪費することは容易に予測できる

そもそも設計の段階で業務FlowもSystem Flowも機能詳細もない状態ではおはなしにならない

よく画面仕様と現行のSource Codeだけで設計に進める開発もあるが必ず設計作業が遅れBacklogなどを使えば炎上IconだらけのTask処理でProjectの立て直しが必要になる

画面はUser Interfaceであり決して機能ではない
またSource Codeの中に業務FlowやSystem Flowは含まれていない
せいぜい表現できるのはAPI仕様書などI/Fの仕様ぐらいだ

利用者の問い合わせに応じる対面処理やその後の工程管理は業務Flowに図式化されるものだし
一個々の業務に関わるSystem側の振る舞いはSystem Flowに図式化されているものだ

要件分析の段階で現行要件に関する業務FlowやSystem Flowが整理出来ていない事がそもそも要件定義を失敗させる要因なのだから

要件分析事にこれらの資料がなければまず準備するのがProjectを成功させる最低限の条件である

その工程を全てすっ飛ばして（○○できる）と要件定義を済ませてしまえば結果として要件定義は出来ていないに等しいのだ

要件定義の品質保証においてもこれから何をどう開発するのか道標も目標も定められていないのだから作業工程において品質保証を満たす事は極めて難しくなっていく

しかし一万歩譲って見方を変えてこの要件定義書を外部の者が覗き見たとしよう

まず現行要件を理解できないので機密漏洩対策にはこの文書を対策用に使うのはありかもしれない
とは言え内部の次工程の作業者にとっては解析が難儀な暗号である事には変わりないが（笑）

だが実際にはこんな品雑な文章を要件定義書として設計工程に回すProjectも少なくない
そして技術者は忖度するままに上位に従い工数内に無理やり収めようと作業を強いられるのだ

私的に言わせてもらえば疑問を持って接するが技術者の資質であるので忖度する時点で技術者としての芽は摘まれたと言ってもいいだろう

この現場にもう３年もいますけど業務FlowもSystem Flowも見た事がありませんという技術者は多くいるが
これこそが技術向上を放棄した哀れな姿なのである

こんな品雑な文書を以てスピード感（小生が片仮名を使うときは使う者を揶揄する時である）と言っている管理者もまた滑稽だ
こんな文書で作業効率が上がる道理もない
彼らは自ら作業効率を下げている事を認識もしていないだろう

そんな品雑なほとんど用をなさない文書から設計書を作っても次は実装でまた機能仕様の確認が発生する

そもそも要件定義において機能要件とは何か？である

一言で言えばCRUDに特化した機能処理の内容をServiceとして具現化することにある
そしてその目的のために機能仕様書などの複数の文書により機能要件が明確化されるのだ

工程管理は個々のTaskの工数を管理するのが目的ではなく個々のTaskが正常に割り振られ検証しながら進められていく者である
なので実装工程においてProgramerが何を実装し何を単体試験すれば良いのか分かる様に管理するのが大事である

さてなんだかんだと品雑な文書管理を無理やり進めたしよう
Projectは炎上しつつ深夜残業や休日残業を経て幾度のBugと戦いつつ試験をやっと終えて漸くお披露目となった頃には作業者の疲労困憊はもう拷問そのものであろうか

それでもお披露目後に利用者からの苦情が殺到しその対応で保守作業のお祭りが始まる

ここで更にBugと戦い漸く本当に落ち着ける頃になるのだがその頃当初の作業員で残っているものはどれだけだろうか？

作業遅延によりほぼこのProjectの人員は解散に追いやられ巻き取りのために別のTeamが編成される

そして新たな編成Teamで改修の対応にはいるための要件定義が行われる
ところが渡された要件定義文書には（○○できる）と書かれたのみ

なのでまた現行要件調査からやり直す事になるだろう
これの何処が（できる）なのだろうか？

つまり最初の現行要件分析を疎かにしてしまえば設計どころか次の改修でも手間を取る事になるのだ

今回はいい加減な要件定義がもたらす弊害を簡素にまとめてみた
では次回をおたのしみに