仕様書がないシステムの仕様を把握する方法

Question

仕様書が存在していないプロジェクトに参加して、システムの仕様を把握するのに苦労しています。

実際の現場に入って2か月目の新人です。

特に、テストデータを用意する場合に、どのようにすれば、正しくデータを構成できるのかいつも悩んでいます。

ソースをすべて読んで、処理を追うことでしか仕様の把握をすることはできないのでしょうか。

システム全体の仕様を仕様書なしで把握する効率的な方法があれば、教えていただきたいと思います。

よろしくお願いいたします。

Answer 1

既にほかの方からの回答にもある通り
「今動いているものが正」として考えていいと思います。

私が実際に設計書が存在しない（あるいは大人の事情で公開できない）PJに参画した時には、
↓のような施策を実施していました。

１．今回のテストシナリオではA機能とB機能を使用する
２．A機能とB機能をテストシナリオに基づいた動作検証し、現状の動作を整理する。
３．（可能であれば）２．の動作をもとにテストデータ作成する。
４．業務有識者に、２．３．の結果を持参し、現在のアプリVer.とデータでテスト続行していいかどうかの確認実施。
５．４．で課題発覚した場合、アプリ修正依頼ORデータ修正ORテストシナリオ修正し、４．に戻る
６．テスト消化

ソースをすべて読んで、処理を追うことでしか仕様の把握をすることはできないのでしょうか。

ソース解析は非常に時間がかかります。
業務全体をある程度把握した上で、発生した障害の検証をする場合には有用でしょうが、まずは業務理解が先決と考えます。

システム全体の仕様を仕様書なしで把握する効率的な方法があれば、教えていただきたいと思います。

業務フロー、処理フローをみながら、とにかくアプリをたたきましょう。
テスト消化に追われてその暇もないということであれば、とにかくテストをこなしてアプリと仲良くなりましょう。
そのうち、「なんでここはこうなってるんだっけ？」という部分が出てきますので、業務有識者に確認しましょう。
そうすればいつのまにか全体の動きがわかってきます。

業務有識者は往々にして多忙であることが多く、聞くタイミングも少ないでしょうから
タイミングを逸しないことと、簡潔に質問できる準備をしておくといいと思います。

頑張ってください。

Comments

[tmak1000]

ARADDIOさんがPJに参画した時のテスト消化フローが凄く参考になりました。

また、今までアプリを動作させてフローを考える割合が、ソースを読むよりも少なかったとも思います。可能な限りアプリをたたいて、業務への疑問を整理してみます。

Answer 2

経験２ヶ月という事を考慮すれば、
ソースからフローチャート起こしてみるのが最善策。

• 一つ一つ処理を把握しながら読む
• 頭にあるものを紙に書く

という事がポイント。
そうすると、データの流れを把握しやすくなって、
処理を完了迄持っていくのに、どういうデータを準備すればよいか見えてくるはずです。

あと、今実装されているものが**「正しい仕様」**と
割りきってしまって良いと思いますよ。
だいたい仕様書のないプロジェクト（仕様書がっても）は、
現実装を正規の仕様としていますので。

ストレスを溜めすぎないよう頑張ってください。

Comments

[tmak1000]

フローチャートを描いてみたら、データの流れが把握しやすくなりましたありがとうございます。

Answer 3

・テストデータについて
残念ながら仕様書を基にテストデータを作るため、正しいテストデータなんて作りようがありません。
また、ソースコードを基にテストデータを、作る事もできません。なぜなら目の前にあるソースコードが正しいかどうかは仕様書に基づくからです、仕様書を完全再現したソースコードがあるなら、そもそも仕様書がないなんて事はあり得ません。

・仕様の効率的理解について
結局のところ、システムにはユーザーがいます。ユーザーの意図が仕様になります。
ユーザーの正しい使い方を正常動作として把握し、あとは自身で例外的な使用方法について検証するしかないと思います。疑問に思ったところを一覧にして、先輩等に確認するといいかもしれないですね。

Answer 4

可能な限り現場を好意的に捉えれば、TDD開発してて要件定義のような文書しかないだけかも
その場合テストコードが存在すると思いますので既に必要なデータが準備されているかもしれませんし、無くてもそこやバージョン管理のログから必要なものが推し量れるかもしれません。

もしウォーターフォール型で仕様書が無いとなると、システムの規模にもよりますが絶望的かも…
先輩に確認しながら時間を掛けて吸収していくしかないんじゃないでしょうか？
仮に「そう有るべき」から発見した不具合を指摘したとしても、作った人個々にPMと合意したローカルルールがあったりしたら意見対立待ったなし（それでも仕事なので報告と確認はしなきゃいけないんですが）ですし、新人だときついですね…。

Answer 5

システムの規模にもよるかもしれませんが、
２か月の新人でそういう現場とは厳しいですね。
先輩や上司の言葉(専門用語など)がすでにわからなかったりな状況だったりしますか？
しかし応援したくなっちゃいますね。

みなさんが回答されていることの繰り返しになるかもしれませんが、
システム全体仕様を手っ取り早く把握するには、いろんなパターンで「実際に動かす」です。
ただ細かい動作はソースを見るしかないと思います。
あと技術者としては微妙ですが「詳しい人に教えてもらう」が最強です。

ご参考までに「教えてもらう」の立ち回りを書いておきます。
１．わからないことや確認したいことを一覧にする
一般的に言うとＱＡ一覧でしょうか。
有識者に毎回聞くとそのたびに相手の作業が中断してしまうためです。

２．自分なりの理解をMy資料にする
処理の概要から詳細まで自分なりに理解したことを資料にします。
何を聞けばよいのかがわかってくることもあります。

３．認識合わせと疑問点の解消
有識者に時間を取ってもらいましょう。
作成したMy資料とわからない点の一覧を使って打合せをします。
目的は以下です。
・自分の理解で正しいかを確認する
・現時点で出てきた疑問点を解消する。

おそらく最終的にはあなたに仕様書を作ってもらいたいのではないかな？と思います。
頑張ってください。

Comments

[tmak1000]

回答ありがとうございます。
　・実際に動かす。
　・QA一覧作成、My資料を作成して詳しい人に疑問点を聞く。
　・最終的に仕様書作成を目的としてみる。
を実践してみたいと思います。

Answer 6

そのような仕様書のない現場というの非常に多いです。

納品してから仕様書を書くなんてこともあります。

さて、把握する方法ですが、ご自分の受け持っている範囲内の分岐を把握し、これは何をする処理なのかを考えます。
次に、明らかにおかしい値と絶対通る値でテストします。
不安でしたら全パターンテストをお勧めします

Comments

[tmak1000]

ありがとうございます。

実際に動かす際に
　・分岐の把握
　・明らかにおかしい値と絶対通る値でテスト
　・可能ならば全パターンテスト　
を重視して進めて行きます。

Answer 7

非常に厄介な状況ですね…

既に皆様がご回答くださっている通りなのですが、誤解を恐れずにざっくりとした表現の仕方をすると

• 「仕様書」は、システムのあるべき姿（何が正しいか）についてクライアントと合意した内容＝「定規」
• 「テスト」とは、システムの実際の挙動が「定規」からズレていないことを確かめる作業

なので、「定規」である「仕様書」がなければ、そもそもテストをする意味がなくなってしまう訳です。

とはいえプロジェクトが発足した以上、何としてでもタスクを遂行してゆく必要があるので…
（言葉で書くとゴチャゴチャして分かりにくいですが）

まず、以下のような点について再確認してください。

• プロジェクトの目的は何ですか？「品質向上」それとも「機能追加/改善」ですか？
• テストのどの工程のデータ作りを想定していますか？「単体/連結/総合」

仕様書がない以上、「現在稼働しているシステム」が正解（仕様書に記載されているはずの内容に最も近い）とみなして作業を進める、つまり『現新比較』の結果を拠り所とするしかありません。

対象のシステムがどのようなものか分からないと具体的な回答は無理なので、以下はWebベースの業務システムを想定して記載します。

もし「品質向上」（＝潜在的なバグの洗い出し）が目的なのであれば、現新比較しても無意味です。
その場合には、もう一度、業務フローやシステムの入力データとなる帳票類を分析して、十分なバリエーションのテストデータを作成するとともに、それらのデータに対して期待される結果が得られるかを、エンドユーザに確認してもらうしかありません。

「機能追加/改善」が目的なら、ソースの「分岐」部分に着目し、実装時点で境界値とみなされていた値を洗い出します。
そして境界値と考えられる値を中心に、業務上の要件も考慮して十分な量のテストデータを作成し、追加/修正対象の機能以外については変更のないことを現新比較によって確かめながら、手を加える部分の新しい仕様に従って細かいテストを実施します。

うまくまとめられませんでそたが…少しでもご参考になれば幸いです。

Answer 8

ソースを読んで理解をしてテストをするのは正直、お勧めできません。
ソースよりも任されているテスト作業範囲の業務理解と業務データの流れ、データのCRUDについて知るのが優先だと思います。
これは業務サイドや現場の先輩に少しづつでも時間を取ってもらい教えてもらうべきだと思いますし、教えるべきとも思います。
誤っているソースをベースにテストケースを作ってもテストにはなりません。
ケアレスミスだけでなく条件すらソースから漏れている場合もあります。
結果としてテストも二度手間になりますし品質面でも問題がある進め方だと感じます。

Answer 9

まず、対象とするシステムにUIがあるのなら使いまくること。対象が何者なのかもわからずコードを見ても無駄。かならず間違う。
もし、ネットワーク関係の機器みたいにシステム仕様書がなければ、どういうことをやっているのか調査する。操作マニュアルとかぐらいはあるでしょう。なければつかっている人に聞く。
システムをBlackBoxとしてIN-OUTを把握していくのです。
イメージとして、OSSをHACKする場合も、何のOSSか把握してからコードを見ますが、それと同じです。
そう！システムをHACKするのです。
その後、ラッキーにもコードがあれば、動かしたときのことを思い出してコードを見ていきます。
最悪の場合、ネットワークの口から通信内容を把握して、動作を類推して、制御プログラムを作ることも可能です。