No.1ベストアンサー
- 回答日時:
それは、SEがへぼだからです。
たまに、あるという事なら100%ミスしない人間はいませんからしょうがないでしょう。でも度々あるのなら、SEがへぼです。
つまり、簡単な仕様書からそのまま作るから最終段階でミスが発生するんです。
最初は簡単でも、途中でPGからの報告なり、疑問点が出てくるはずなんです。お客様に確認を取らないで、想像で「こうだろう」ですると、そうなっちゃいます。
INPUTとOUTPUTを押さえれば、途中の機能は必然的に決まります。また複数の人間で開発するのなら絶対に紙ベースでする事です。
つまりどういった入力(データ)があって、最終的に帳票なり、データ加工するのか。を100%はムリでも、限りなく確認する事です。そうすれば、作成側とお客様側の認識にズレも分かってきますよ。
また、機能一覧表を作って、これもお客様と確認を行う事が重要です。
上記ができて初めてスケジュールも正確なものがかけると思いますよ。
エラーメッセージで考えますと、一つのエラーメッセージが、プログラムでは、いろいろなパターンで発生しますよね。仕様書を書く方は「書いてあるじゃありませんか。」と強く出られますが、こちらはそこまで分からず、責めを負うことになります。これを逃れる方法は無いものでしょうか?ありがとうございました。
No.8
- 回答日時:
顧客や仕様責任者へのフィードバックを、公式・非公式を問わず、常時、行っていくしかないと思います。
お話を聞く限りでは、詳細な仕様が書かれた文書が下りてくることを期待できないようですので。もちろん、コーディングに入る前に全ての仕様が明確な文書が有ることが理想だとは思いますが。
まずは、仕様で曖昧な点が見えてきたら、すべて担当のSEさんに確認するのが良いでしょう。SEさんに聞くまでも無いと思えるような詳細な点についても「これこれについて、この程度のことはこちらで判断しても良いですか?」という様な確認はしておいた方が良いでしょう。
うるさがられるかも知れませんが、PGからの仕様についての質問に答えるのもSEの仕事ですから。遠慮せずにどんどん聞いた方が最終的にはお互いのためになると思います。ただし、相手の仕事が一段落したときを狙う、質問はある程度まとめる、など、聞き方は工夫したほうが良いでしょう。直接言うよりも、e-mailの方が、時間のある時に回答して貰えるので良いかもしれません。
また、各工程で、目に見える成果物・出力がある場合は、こまめに担当のSEさんに確認してもらうことも必要だと思います。
・コーディングが終わった時点で、画面、メッセージ、出力ファイルなどが出せれば、それを確認してもらう。
・単体試験の試験項目表を作っている場合は、それが出来た時点で確認してもらう。
など、他にもいろいろ有ると思います。
大きな障害がある場合は、これらのものにざっと目を通すだけでも、障害が見つかることが良くありますので、出来るだけ担当のSEさんをつかまえて確認してもらうと良いです。
最近注目されているアジャイルと呼ばれる種類の開発プロセスでも、顧客へのフィードバックは、とても重要視されています。
参考URL:http://www.atmarkit.co.jp/fjava/devs/process01/p …
指定されたホームページをざっと流し読みして、理解していません。何度も読み、場数を踏み、また読み、そうしたら理解できるのでしょうか。ドキュメントの修正が問題ならば、新規の時は添付資料にして、開発が完了したら捨ててしまえば良いと思うのですが。詳細設計はプログラムの中に盛り込むのなら、いらなくなるものだと思うのですが。全くないよりは、出来上がるまではドキュメントとしてあってもいいのではないでしょうか。説明するのにも、ドキュメントがあったほうが、忘れることなく良いと思うのですが…。ありがとうございました。
No.7
- 回答日時:
根本的には、仕様書を書いた人の責任ですね。
ただ、プログラマが業務を理解してくれば、矛盾点や
仕様漏れ見えてくるということが往々にしてあります。
疑問点を感じたら設計者に確認すればいいのですから。
なので、逃れるポイントというと、ただ漠然と仕様書に
沿ってコーディングしていくのではなく、業務を
理解しようという意識の元で作業を進めていけば、
多少はなんとかなるのではということになります。
ただ、どうしても仕様漏れ、間違いというのは設計者も
人間なので発生します。ユーザとの認識違いなんてのも
ありますし。
スケジュール管理という点では、あらかじめバッファを取っておくということでしょうかね、やっぱり。
使い切ったらアウトですが。
コーディングしている段階では理解できているつもりなのです。結局ケース漏れです。バグが発生してから、業務が分かるということがありました。あまり良く分かるので、もしかしたら、仕様書を書いた人もこの頃作るものがわかったのではと思うこともあります。意思の疎通ができていなかったのでしょうが。最初の段階でこれで良いと思い込んでしまったのでしょうか。ありがとうございました。
No.6
- 回答日時:
なるほど、PGとしてのご質問でしたか。
>仕様書を書く方は「書いてあるじゃありませんか。」と強く出られますが、こちらはそこまで分からず、責めを負うことになります。
という事ですが、
>エラーメッセージで考えますと、一つのエラーメッセージが、プログラムでは、いろいろなパターンで発生しますよね。
当たり前の話です。パターン表はお作りになりましたか?つまり仕様書の分析不足かもしれませんね。
100%の仕様書は存在しませんし、時間などで結構いいかげんだったりします。そこで仕様の不具合や不明点を把握する事が大事になります。初期段階でこの作業をおやりになると、後でSEより「書いてあるでしょう」というのは言われなくなります。SEだって100%分かって書いている訳ではないからですね。矛盾点を探しだして突きつけるのもPGの仕事ですよ。
そういった訓練を積んでSEになっていくのですから。
仕事は前詰めにしましょうと言われると、パターン表を作る余裕はなくなり、先にコーディングをはじめとにかく進捗が進んでいるように発表しています。そして問題になります。ということは、最初に厳しく言われても、とにかく我慢しないといけないのですね。ありがとうございました。
No.5
- 回答日時:
業務の請負は当然契約ですので作業範囲は明確にしておく必要があります。
機能仕様書作成段階で確認(テスト)項目が具体的で明確にしてありましたでしょうか。何々が出来るという程度でも構いませんが、具体的であればある程、問題が起きません。(5W1Hがあるか意識して下さい)プログラムの仕事は作成後、仕様書の実施テストが終了した段階で終了で、後はメンテナンスです。また機能仕様書には会社間、部門間、担当者間の確認印をおしてありますでしょうか。打ち合わせの議事録は残して参加者の確認印は取ってありますか。もしそこまで全員の一致で仕事を進めたのであれば、仕様変更となった時点で営業を含めて別料金請求でしょう。別途請求であれば機能漏れなど無いよう初めから真剣に仕様書が作成されるはずです。仕事は無料奉仕ではありません。各人の立場と責任範囲を明確にし、その業務に対してお金が動いていることを意識して働いて下さい。もしこの責任範囲が最初から明確でないと感じられるなら各担当者の責任範囲を決める所から文書で決める所からが仕事の開始です。頑張って下さい。テスト項目の洗い出しのために時間をとらされた記憶もありますが、プログラムを渡されて、テスト項目の洗い出しもこちらでやってくださいと言うのが、いつものパターンです。確認印が重要だと聞いてはいますが、そのようなことを考えている余裕がありませんでした。私の考える仕様変更と問題となる仕様変更とは違うのでしょう。小さな違いで大きな修正というのはありますが、別料金請求するにはSEさんも気の毒な。仕様書が理解できてないのよで済んでしまうのでした。(でも、もう少し分かりやすく書いて欲しい。)ありがとうございました。
No.4
- 回答日時:
当事者典型:発注者(素人)-SE(能力バラバラ)-プログラマ(与えられた仕事範囲で、狭い)
(1)仕様変更が、発注者がコンピュタ(プログラム)面に素人であるため、大事な条件を言わないとか、書いてないとか。素人が考える難しさ・面倒さとプログラマのそれとは、往々にして乖離があります。
(2)仕様書がその点では、大まかで書いてなかった。
(1)は折衝するSEの力不足と言えると思います。
(2)もSEの力不足ですが、プログラム的見地から影響しそうなところは早い段階で確認しておくべきで、責任の
一端はプログラマにもあると思います。
また業界や業務の常識からして、当然そうなるといわれる事項もあり、それは業務の常識を時間をかけ、センスを磨かなければしようがないでしょう。意外に人間行動心理に
沿ってない画面設計などやコンなの常識でしょうと言いたい点が、利用者側で、経験したことがありました。社会へ出て1-2年の人がプログラムを組むことも多いようで、大変でしょうが。
私が気遣うのは
(1)データ量的な問題
(2)ランダムアクセスの検索・即時照会(オンラインアクセス)が必要な問題
(3)項目が今のファイルに無い問題(こんな項目は
要求されないか先回り考慮も必要)別のファイルから
取ってこないといけない項目が無いか。
(4)通信や通常以外の入出力機器を使うと言い出した時
は気をつけないと、いけないと思います。たとえばFAXに出力したいなど。不慣れな人が多いでしょうから。
たった1項目の追加で大変になるときがあります。これらは昔はディスク容量も少なく高価で、データベースソフトもそんなに自由に使えなかった時代のことですが、今は大分状況は改善されていますが、やはり大事になるのでは。
プログラマ的見解で見ますと、(1)のデータの量はプログラミングには関係なく思えます。ファイルの読み方が妥当か気をつけないといけないのでしょうか。(2)のランダムアクセスの検索は、データがなかった場合を細かく考えないといけないような…。即時照会はコーディングしている場所が悪いと修正が入った記憶があります。即時照会に関しては、修正が入っても影響はあまりなかったです。(3)の項目が今のファイルにない、別のファイルから取ってこないとというのは、ペンディング状態になって、仕事が進まず、もやもやしたままになり、他にも重要な箇所があるのに見つからないままというような結果に。(4)の入出力機器の変更は経験ありません。サブルーチンが変わるくらいで、プログラマには影響ないのではないでしょうか。ありがとうございました。
No.2
- 回答日時:
ソフトウェア開発をしている以上、そういうことはある程度、止むを得ないと割り切るしかありません。
> これから逃れる方法はあるでしょうか?
仕様書をがちがちに作成することです。
というのが建前ですが、まず無理なことなので「ある程度、止むを得ない」となるのです。
あとは経験を積むことでしょう。この客は、このシステムは、この言語はこういうところで仕様上の問題につながりやすいと経験を積めば、効率も上がります。
本当はその経験をマニュアル化、データベース化するなどし、関係者で情報共有化を図るのが理想ですが、あまり実現されている例を見ません。喉元過ぎれば熱さ忘れると言いましょうか。自分の残業時間を増やしてまで、後人にノウハウを残しておこうという親切な開発者は非常に稀です。
> そこからのスケジュール管理はどのようにするのでしょうか
残業や休日出勤でこなすのが一般的です。
あるいは優先度の低い他の作業を後回しにする工程を引き直します。
そういうことにならないよう、スケジュールに多少余裕を持たせておく(工程に表わすのではなく、各開発者が心の中でそろばんを弾いておくという意味で)工夫も必要です。
お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!
似たような質問が見つかりました
- その他(データベース) Excel VBA 転記について 1 2022/04/20 16:55
- WordPress(ワードプレス) 「あるサイトのリンクを踏まないと、次のサイトを見れない仕組み」を作りたい 2 2022/07/20 02:43
- システム 古いWEBシステム。もう追加プログラムは作れない? それともできる? 6 2022/06/08 13:41
- 会社経営 中間管理職の仕事 2 2022/05/26 01:20
- その他(プログラミング・Web制作) Windows上のプログラム。「予め決められた時刻に自分で起動して処理して自分で終了する」って可能? 3 2023/01/04 14:29
- その他(スマートフォン・携帯電話・VR) 全部入りでも夜間の動画性能がいいスマホありますか? 5 2022/04/04 16:33
- PDF ワードで作った文書のPDF化 5 2023/04/10 16:56
- デスクトップパソコン 「自動修復でPCを修復できませんでした」と表示されPCが起動しないのですが対処法はありますか? 5 2022/05/13 09:16
- 固定電話・IP電話・FAX 業務用ファックスについて 5 2022/09/28 19:08
- 電気・ガス・水道業 PLC プログラム 1 2023/02/03 22:29
関連するカテゴリからQ&Aを探す
おすすめ情報
デイリーランキングこのカテゴリの人気デイリーQ&Aランキング
-
texに関する初歩的な質問
-
P2P地震速報のEEW APIの仕様書...
-
文字をなぞるとポップアップが...
-
Zと2とか紛らわしいのがあるか...
-
納品 vs ご納品 どちらが正し...
-
PostgreSQL+DataGridView
-
オーバレイ方式と仮想記憶シス...
-
グーグルの障害者訓練プログラ...
-
購入手続き後の値上げ
-
営業職をやってます。先月発注...
-
個人でデザインやイラストを書...
-
契約期間内における値上げ等に...
-
敬語チェックお願いします!
-
翻訳お願いします。英→日
-
どうすれば過剰発注抑えられま...
-
印刷会社がミスプリント。その...
-
納入日と納品日について
-
ヴィジュアルベーシックについて
-
1次元バーコードを読み取りたい
-
発注書について とある株式会社...
マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング
-
P2P地震速報のEEW APIの仕様書...
-
texに関する初歩的な質問
-
C#単体テストで同クラス内の呼...
-
テスト仕様書作成って初心者(...
-
EXCEL_VBAでOracleにADO接続し...
-
C#の単体テストでローカル変数...
-
ホームページ・ビルダーで「e...
-
VBからBeckyを使用したメール送...
-
HWNDへの変換
-
Visial C++におけるプログラミング
-
JUnit結果出力をファイルに書き...
-
Verilogの参考書のお勧めを教え...
-
UNIX:テキストファイルのNULL...
-
仕様書に書かれていないこと
-
VB6 コードでメニュー作成
-
テスト仕様書の著作権について
-
Excel-VBA コンテンツの作成日時
-
文字をなぞるとポップアップが...
-
単体テストについて
-
ハノイ塔の非再帰について
おすすめ情報