仕様書に書かれていないこと

質問

大まかにそのプログラムの機能が書かれている仕様書を見て、プログラムを作る事になり、途中でミーティングを入れても、最終段階になって、機能漏れ（間違い？）が見つかり、それが元で、ロジックも変わってしまうということがあります。これから逃れる方法はあるでしょうか？見逃しやすいポイントというものがあるのでしょうか。そこからのスケジュール管理はどのようにするのでしょうか（．．）

回答No.1

PAPA0427 · ベストアンサー

それは、ＳＥがへぼだからです。

たまに、あるという事なら１００％ミスしない人間はいませんからしょうがないでしょう。でも度々あるのなら、ＳＥがへぼです。

つまり、簡単な仕様書からそのまま作るから最終段階でミスが発生するんです。

最初は簡単でも、途中でＰＧからの報告なり、疑問点が出てくるはずなんです。お客様に確認を取らないで、想像で「こうだろう」ですると、そうなっちゃいます。

ＩＮＰＵＴとＯＵＴＰＵＴを押さえれば、途中の機能は必然的に決まります。また複数の人間で開発するのなら絶対に紙ベースでする事です。

つまりどういった入力（データ）があって、最終的に帳票なり、データ加工するのか。を１００％はムリでも、限りなく確認する事です。そうすれば、作成側とお客様側の認識にズレも分かってきますよ。

また、機能一覧表を作って、これもお客様と確認を行う事が重要です。

上記ができて初めてスケジュールも正確なものがかけると思いますよ。

お礼

エラーメッセージで考えますと、一つのエラーメッセージが、プログラムでは、いろいろなパターンで発生しますよね。仕様書を書く方は「書いてあるじゃありませんか。」と強く出られますが、こちらはそこまで分からず、責めを負うことになります。これを逃れる方法は無いものでしょうか？ありがとうございました。

回答No.8

root139

顧客や仕様責任者へのフィードバックを、公式・非公式を問わず、常時、行っていくしかないと思います。お話を聞く限りでは、詳細な仕様が書かれた文書が下りてくることを期待できないようですので。
もちろん、コーディングに入る前に全ての仕様が明確な文書が有ることが理想だとは思いますが。

まずは、仕様で曖昧な点が見えてきたら、すべて担当のSEさんに確認するのが良いでしょう。SEさんに聞くまでも無いと思えるような詳細な点についても「これこれについて、この程度のことはこちらで判断しても良いですか？」という様な確認はしておいた方が良いでしょう。
うるさがられるかも知れませんが、PGからの仕様についての質問に答えるのもSEの仕事ですから。遠慮せずにどんどん聞いた方が最終的にはお互いのためになると思います。ただし、相手の仕事が一段落したときを狙う、質問はある程度まとめる、など、聞き方は工夫したほうが良いでしょう。直接言うよりも、e-mailの方が、時間のある時に回答して貰えるので良いかもしれません。

また、各工程で、目に見える成果物・出力がある場合は、こまめに担当のSEさんに確認してもらうことも必要だと思います。

・コーディングが終わった時点で、画面、メッセージ、出力ファイルなどが出せれば、それを確認してもらう。
・単体試験の試験項目表を作っている場合は、それが出来た時点で確認してもらう。

など、他にもいろいろ有ると思います。
大きな障害がある場合は、これらのものにざっと目を通すだけでも、障害が見つかることが良くありますので、出来るだけ担当のSEさんをつかまえて確認してもらうと良いです。

最近注目されているアジャイルと呼ばれる種類の開発プロセスでも、顧客へのフィードバックは、とても重要視されています。

参考URL：

http://www.atmarkit.co.jp/fjava/devs/process01/process01.html,http://www.atmarkit.co.jp/fjava/devs/redge01/redge01.html

お礼

指定されたホームページをざっと流し読みして、理解していません。何度も読み、場数を踏み、また読み、そうしたら理解できるのでしょうか。ドキュメントの修正が問題ならば、新規の時は添付資料にして、開発が完了したら捨ててしまえば良いと思うのですが。詳細設計はプログラムの中に盛り込むのなら、いらなくなるものだと思うのですが。全くないよりは、出来上がるまではドキュメントとしてあってもいいのではないでしょうか。説明するのにも、ドキュメントがあったほうが、忘れることなく良いと思うのですが…。ありがとうございました。

回答No.7

taka_tetsu

根本的には、仕様書を書いた人の責任ですね。
ただ、プログラマが業務を理解してくれば、矛盾点や
仕様漏れ見えてくるということが往々にしてあります。
疑問点を感じたら設計者に確認すればいいのですから。

なので、逃れるポイントというと、ただ漠然と仕様書に
沿ってコーディングしていくのではなく、業務を
理解しようという意識の元で作業を進めていけば、
多少はなんとかなるのではということになります。

ただ、どうしても仕様漏れ、間違いというのは設計者も
人間なので発生します。ユーザとの認識違いなんてのも
ありますし。

スケジュール管理という点では、あらかじめバッファを取っておくということでしょうかね、やっぱり。
使い切ったらアウトですが。

お礼

コーディングしている段階では理解できているつもりなのです。結局ケース漏れです。バグが発生してから、業務が分かるということがありました。あまり良く分かるので、もしかしたら、仕様書を書いた人もこの頃作るものがわかったのではと思うこともあります。意思の疎通ができていなかったのでしょうが。最初の段階でこれで良いと思い込んでしまったのでしょうか。ありがとうございました。

回答No.6

PAPA0427

なるほど、ＰＧとしてのご質問でしたか。

＞仕様書を書く方は「書いてあるじゃありませんか。」と強く出られますが、こちらはそこまで分からず、責めを負うことになります。
という事ですが、

＞エラーメッセージで考えますと、一つのエラーメッセージが、プログラムでは、いろいろなパターンで発生しますよね。
当たり前の話です。パターン表はお作りになりましたか？つまり仕様書の分析不足かもしれませんね。

１００％の仕様書は存在しませんし、時間などで結構いいかげんだったりします。そこで仕様の不具合や不明点を把握する事が大事になります。初期段階でこの作業をおやりになると、後でＳＥより「書いてあるでしょう」というのは言われなくなります。ＳＥだって１００％分かって書いている訳ではないからですね。矛盾点を探しだして突きつけるのもＰＧの仕事ですよ。

そういった訓練を積んでＳＥになっていくのですから。

お礼

仕事は前詰めにしましょうと言われると、パターン表を作る余裕はなくなり、先にコーディングをはじめとにかく進捗が進んでいるように発表しています。そして問題になります。ということは、最初に厳しく言われても、とにかく我慢しないといけないのですね。ありがとうございました。

回答No.5

yfujii

業務の請負は当然契約ですので作業範囲は明確にしておく必要があります。機能仕様書作成段階で確認（テスト）項目が具体的で明確にしてありましたでしょうか。何々が出来るという程度でも構いませんが、具体的であればある程、問題が起きません。（５Ｗ１Ｈがあるか意識して下さい）プログラムの仕事は作成後、仕様書の実施テストが終了した段階で終了で、後はメンテナンスです。また機能仕様書には会社間、部門間、担当者間の確認印をおしてありますでしょうか。打ち合わせの議事録は残して参加者の確認印は取ってありますか。もしそこまで全員の一致で仕事を進めたのであれば、仕様変更となった時点で営業を含めて別料金請求でしょう。別途請求であれば機能漏れなど無いよう初めから真剣に仕様書が作成されるはずです。仕事は無料奉仕ではありません。各人の立場と責任範囲を明確にし、その業務に対してお金が動いていることを意識して働いて下さい。もしこの責任範囲が最初から明確でないと感じられるなら各担当者の責任範囲を決める所から文書で決める所からが仕事の開始です。頑張って下さい。

お礼

テスト項目の洗い出しのために時間をとらされた記憶もありますが、プログラムを渡されて、テスト項目の洗い出しもこちらでやってくださいと言うのが、いつものパターンです。確認印が重要だと聞いてはいますが、そのようなことを考えている余裕がありませんでした。私の考える仕様変更と問題となる仕様変更とは違うのでしょう。小さな違いで大きな修正というのはありますが、別料金請求するにはＳＥさんも気の毒な。仕様書が理解できてないのよで済んでしまうのでした。（でも、もう少し分かりやすく書いて欲しい。）ありがとうございました。

回答No.4

imogasi

当事者典型：発注者（素人）－ＳＥ（能力バラバラ）－プログラマ（与えられた仕事範囲で、狭い）
（１）仕様変更が、発注者がコンピュタ（プログラム）面に素人であるため、大事な条件を言わないとか、書いてないとか。素人が考える難しさ・面倒さとプログラマのそれとは、往々にして乖離があります。
（２）仕様書がその点では、大まかで書いてなかった。
（１）は折衝するSEの力不足と言えると思います。
（２）もSEの力不足ですが、プログラム的見地から影響しそうなところは早い段階で確認しておくべきで、責任の
一端はプログラマにもあると思います。
また業界や業務の常識からして、当然そうなるといわれる事項もあり、それは業務の常識を時間をかけ、センスを磨かなければしようがないでしょう。意外に人間行動心理に
沿ってない画面設計などやコンなの常識でしょうと言いたい点が、利用者側で、経験したことがありました。社会へ出て１－２年の人がプログラムを組むことも多いようで、大変でしょうが。
私が気遣うのは
（１）データ量的な問題
（２）ランダムアクセスの検索・即時照会（オンラインアクセス）が必要な問題
（３）項目が今のファイルに無い問題（こんな項目は
要求されないか先回り考慮も必要）別のファイルから
取ってこないといけない項目が無いか。
（４）通信や通常以外の入出力機器を使うと言い出した時
は気をつけないと、いけないと思います。たとえばFAXに出力したいなど。不慣れな人が多いでしょうから。
たった１項目の追加で大変になるときがあります。これらは昔はディスク容量も少なく高価で、データベースソフトもそんなに自由に使えなかった時代のことですが、今は大分状況は改善されていますが、やはり大事になるのでは。

お礼

プログラマ的見解で見ますと、（１）のデータの量はプログラミングには関係なく思えます。ファイルの読み方が妥当か気をつけないといけないのでしょうか。（２）のランダムアクセスの検索は、データがなかった場合を細かく考えないといけないような…。即時照会はコーディングしている場所が悪いと修正が入った記憶があります。即時照会に関しては、修正が入っても影響はあまりなかったです。（３）の項目が今のファイルにない、別のファイルから取ってこないとというのは、ペンディング状態になって、仕事が進まず、もやもやしたままになり、他にも重要な箇所があるのに見つからないままというような結果に。（４）の入出力機器の変更は経験ありません。サブルーチンが変わるくらいで、プログラマには影響ないのではないでしょうか。ありがとうございました。

回答No.3

yama_x

>これから逃れる方法はあるでしょうか？

相手先の業務に精通することです。
そのソフトウェアを用いて、どのような処理を何のために行うのが
目的かを理解できれば、仕様書をつめる段階で、先方との認識のズレを
解消源にすることが出来ます。

お礼

業務の説明もしてもらい、分かったと思っても、仕事している時は分からないのです。ありがとうございました。

回答No.2

shikakuhonpo

ソフトウェア開発をしている以上、そういうことはある程度、止むを得ないと割り切るしかありません。

> これから逃れる方法はあるでしょうか？

仕様書をがちがちに作成することです。
というのが建前ですが、まず無理なことなので「ある程度、止むを得ない」となるのです。

あとは経験を積むことでしょう。この客は、このシステムは、この言語はこういうところで仕様上の問題につながりやすいと経験を積めば、効率も上がります。

本当はその経験をマニュアル化、データベース化するなどし、関係者で情報共有化を図るのが理想ですが、あまり実現されている例を見ません。喉元過ぎれば熱さ忘れると言いましょうか。自分の残業時間を増やしてまで、後人にノウハウを残しておこうという親切な開発者は非常に稀です。

> そこからのスケジュール管理はどのようにするのでしょうか

残業や休日出勤でこなすのが一般的です。

あるいは優先度の低い他の作業を後回しにする工程を引き直します。

そういうことにならないよう、スケジュールに多少余裕を持たせておく（工程に表わすのではなく、各開発者が心の中でそろばんを弾いておくという意味で）工夫も必要です。

お礼

そろばんを弾く段階で残業が見える…。ありがとうございました。