はじめに
ここ最近、仕事で要件を考える、擦り合わせるという機会が増えてきており その重要性を改めて実感しています。
設計が決まっているものをただ、実装する能力は身についている一方 要件定義や仕様書作成の能力が まだ足りないと感じることが多かったので今回は備忘録として「要求を仕様化する技術・表現する技術」で自分が覚えておきたいポイントをまとめていきます。
殴り書きの側面が強いかもしれませんが、ご容赦ください。
第１章
大きなシステムでは、5000件を超えるようなバグが発生することもある。
そのバグを修正するためには数万時間にも達するとのこと、時間にすると1人の作業員の10年分にも相当する。
ここで注目したいのは、バグの過半が、要求仕様に関連するものということ。
1.1 どこで問題が発生しているか?
- バグなどの "エラー" の原因プロセス
- 5:3:2(仕様:設計:実装) の割合でプロセスエラーが発生している
- 設計者テストが十分にできているところでは...
- 7:2:1(仕様:設計:実装) の割合でプロセスエラーが発生している
- 実装上の仕様を設計の中で決めていくという考え方を変える必要がある
- 変えていかないと、派生開発での変更モレが起きる
自分のイメージだと、 3:3:4(仕様:設計:実装)の感覚でした。
ここから見るに、要件定義が重要ということがよくわかると思います。
1.2 要件仕様のトラブルの実態
- トラブルのケースは以下のようなものがある
- 要求していた仕様が実現していない
- 途中で変更を指示した部分が十分に調整されていない
- 仕様のモレが次々と発見されて、テストがまともに進まない
- 仕様漏れ
- 仕様として記述するのが漏れてたために、対応するソースコードが書かれなかった状態
- 例えば...
- 本来なら受け取ったところで、必要な項目をチェックして問題ないことを確かめてから使用すべきだったがされていなかった(チェックすることが仕様書に書かれていなかった)
- そのまま数値を計算したところ累積データに異常な値が更新されてしまった
- 解釈に違い
- 単純な仕様漏れと比べて、複雑である
- 例えば...
- 顧客(要件を出す人)と設計者の間での解釈の違い
- 設計者同士の認識の違い
- 仕様の衝突
- 個々の機能で必要または有効と考えられる仕様をすべて実現しようとすると、異なる機能のいくつかの仕様間で衝突するという状態
- 早い段階で全体の仕様化を進めないと防げない
1.3 曖昧な状態で作業に入っている
- 構造が傷ついていく
- 現場では、「納期に間に合わない」という圧力がかかる
- 強引に送信のタイミングを遅らせたり、データをグローバルで参照したり
- 結果、プログラムの構造が崩れていく
- 潜在バグの意味
- 潜在バグとは、今回自分が埋め込んだバグではない、前の人が埋め込んで発見されないままになっていたのを"たまたま" 自分が掘り出してしまった
- 潜在バグとして、分類した瞬間原因を踏み込んで探すことがなくなってしまう
- 次の担当者に向けた潜在バグを仕込む ことになる
1.4 顧客からの仕様変更
- 仕様の変更率が 50% を超える組織もある
- 設計者がプログラムのコーディングを進めていく中で仕様な曖昧な箇所に遭遇
- そこで、依頼者に質問メールや確認のメールを発して仕様変更へ...
- 最後になって機能に制限がつく
- 担当者も、ソースコードには「具体的な仕様」が必要になり、「具体的な仕様を見つける目」になっている
1.5 要求した機能を満たしていない
- 要求を満たさない最大の理由
- 1.「要件仕様書」が「仕様」といえるレベルに達していない
- 2.完成品として含まれるべき 「品質要求」も記述されていない
- 3.関係者が、その不十分さに気づくためのスキルを持ち合わせていないこと
関係者が、仕様書の不十分さに気づかない、仕様と呼ばれるレベルに達していないことはよくある事象ですね。
1.6 納期の遅れとなって表面化する
- 要件の仕様化が不十分だと、"予定通り"に設計工程に入っても何をやれば良いかわからない
- 結果として、設計作業 が進まなくなる
- 何度も作り直している
- 仕様には設計方法を
誘導する力がある- 仕様によって設計する際のデータ構造の選択や処理方法が決まっていく
1.7 品質要求に応えられないSE
- 保守性要求に居直るソフト会社
- 「品質要求」を加えた顧客に対して、追加で料金をもらおうとする
- 家を建てる際に、
使いやすさを要求して追加料金を請求された - それでいてコピペで3000行にも達するプログラムを平気で作ってしまう...
- 品質要求を課さなかった発注側にも責任はある
1.8 派生開発での仕様トラブル
- 派生開発はトラブルが多い
- 逆にいうと、派生開発の中でこそ、要求の捉え方と仕様化の能力が試される
- ソースから仕様を理解できるか
- 人のソースコードを読んで、要求の具現化の様子や設計の理解には、相当の修練と適切な経験が必要c
- 変更要求(仕様)が表現されていない
1.9 設計書が省かれてしまう原因になっている
- 要求仕様書がうまく書かれない原因
- 「適切な設計書」が書かれていない
- 設計レベルの仕様と混同
- 「設計仕様書」として書かれている
- 設計書に仕様が捕捉されている
- 仕様書と呼ばれるものが複数ある
- 「設計仕様書」として書かれている
まとめ
いかがでしたでしょうか。
「仕様のモレが次々と発見されて、テストがまともに進まない」 というのは、皆さんもあるのではないでしょうか。
自分も直近のプロジェクトで、要件定義が甘かったために、後戻りが多くなり、実装が進まないという状況になってしまいました。
特に、仕様を決めた後に実装を進めてる最中に仕様が曖昧なところを見つける(見つけてもらう)という部分に近いこともありこの本の内容は非常に役立ちそうだと感じました。
単純に実装するスキルもそうですが、自分のためも兼ねて2章以降もまとめていきたいと思います。
参照