- ベストアンサー
わかりやすい仕様書の書き方
現在プログラマをしているのですが、 私の会社は自社ソフトウェアを扱う小さな会社という事もあり、 会社では仕様書を一切書かず、わからないことがあれば各担当した プログラマに聞きにいく、といった感じになっています。 しかし、今回自分が不便を感じた事もあり、自分が作ったものだけでも 文章でまとめて書いておこうと思うのですが、どのように書いていったら良いものなのか書こうとして躓いてしまいました。 あとから見直してわかりやすいような仕様書・・・この場合出来上がったものをまとめるのですが、書き方を教えていただければと思います。 よろしくお願いいたします。
- Caya
- お礼率78% (255/325)
- その他([技術者向] コンピューター)
- 回答数4
- ありがとう数8
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
元ＳＥです。 メインの流れは簡単な図と文章でおこし、それぞれの処理には識別できる記号をつけます。処理はそれぞれ使用をまとめます。 後はそれらをきちんと整理しておけば、後でわかりやすいのではないでしょうか。詳しい処理がわかりませんので、これ以上の説明は難しいですが、もっとも大切なのは「決めたフォーマットを今後も守ること」です。 今後、誰が見ても理解できるようにしておくことが理想ですから、仕様書の作成日・作成者はもちろん、修正を加えた人も修正日・修正内容を残せるようにもしておくべきかと。
その他の回答 (3)
- tkkari
- ベストアンサー率28% (2/7)
現役SEです。 #2様がおっしゃるように、仕様書にも様々なものがあります。ですので、どのような仕様書をお書きになりたいのかを教えていただけると助かります。 少なくとも、 ・誤解のない言葉で表現すること ・注意・制限事項は必ず記述すること ・図によってシステムの流れがわかるようにすること ・定義は必ず残すこと は必要でしょうか。 私は、フォーマットはある程度決めた方が良いかと思います。 「自分だけわかる仕様書」をつくるならフォーマットがあってもなくても良いとは思いますが、もし「誰でもわかる仕様書」を作ろうとするならば、フォーマットは決めておくべきだと思います。 ＞わからないことがあれば各担当した ＞プログラマに聞きにいく、といった感じになっています プログラマは、仕様書をもとにプログラムを行うものであると思っています。ですので、プログラマに仕様を聞きにいく、というのは少々違うと思います。まずは、仕様書をしっかりと固める。それに基づいてプログラマに仕様を引き継ぎ製品をつくる、ということが大切ではないでしょうか。 その仕様をしっかりさせるには「仕様書」をきちんと書くことが必要です。 お客様とトラブルが起きる場合、「仕様に対する理解の相違」があります。 仕様書に起こすことで、互いの認識を確認することができます。ですので、ぜひ自分だけでなく社内に仕様書の文化を根付かせていただければと思います。（偉そうなことを申し上げまして申し訳ありません）
お礼
うちの会社では、営業からほしいといわれた機能を作るのに適していると思われる各システム社員が具体的に考えて作る(SE兼PG？)ような感じで作っています。言葉足らずで誤解を招きました。なにぶん、小さな会社で、請け負うのではなく自社ソフトすので、全てを自分で行うのです。出来上がって機能が足りなければ、営業から言われてつけたし、リリースするのですが、とりあえず、リリース状態のものを 後々のためにまとめておきたいと思っています。 全体の流れと、詳しい説明をわかりやすく書いて行きたいと思います。 ありがとうございました
＃１の人とはちょっと違う意見を。 まず、決まったフォーマットは作らないほうがいいと思います。 変に型にはまってしまい、自分の思った表現に合わないことがあります。 そのため、逆に分かりにくいものが出来上がったりしますので、できるだけ自由に書けるものがいいです。 図は大切です。 言葉では表せないようなことが表現できます。 言葉で説明するのが難しいと思ったら図で描いてみましょう。 フローチャート、UML、ER図、マトリックスなど。 あと、仕様書といってもさまざまです。 基本設計書、詳細設計書、コード設計書などあります。 この場合、コード設計書でしょうか？ それぞれに、設計書の粒度が違いますので分別して下さい。 あと、これは最も重要なことですが、わかり易い言葉で書くということです。 誰が見ても同じような理解ができる言葉で書きます。 例えば、「空の文字列」ということは、例えばnullだったり、スペースが入っててもいいのかなど、読み手によって様々に理解が変わりますので、気をつけて下さい。
お礼
とにかくわかりやすく、というのがキーなのですね。 今書こうとしたら、ソースのコメント(ほぼ全行に書いてあるのですが)をつらつらと並べているようになってしまいました＾＾； 図を取り入れてわかりやすくしたいと思います。 ありがとうございました
補足
そうですね、コード設計になると思います。 基本的な使い方として、このボタンを押したらどうなって・・・というのは単純なものですぐ動かせばわかるのでいいのですが、 ボタンを押したらどの関数が呼び出され、どのようなライブラリが使われていて、又、関数内の詳細な動きをまとめておき、今後変更がある場合、バグが見つかった場合、私が会社をやめたあとに誰でもすぐに変更ができるようにしたいと思っています。
関連するQ&A
- プログラム経験なしでいきなりSEらしきことをしている私ってどうなの？
ソフトウェア開発に携わる20歳代前半の男。 昨年3月に大卒後、翌月から某社に入社した者です。 私の会社はソフトウェア会社ではなく 「メーカーの一部門がソフト屋だ」という少々特殊な会社です。 同期も純粋な営業マンから電気系のエンジニアまで職種は色々。 一般的なソフトウェア会社に入った学生時代の友人の話を聞くと 入社後数ヶ月はCやらJAVAやらのプログラミング研修を みっちりと受けたとよく聞きますが、 自分はこういう会社なので、そういうのはありませんでした。 今の私はまだ顧客先に出向く機会も少ないのですが、 直属の先輩の様子を見ていると、今後は自分も顧客先に出向いて 顧客の悩みを聞き、それをどうソフトウェアで解決していくかを分析する いわゆるSE業をしていくことになりそうです。 今の私はその先輩の補助で、顧客から得た情報を元に、 ソフトウェア仕様書を毎日のようにバンバン作っています。 そして、私の書いた仕様書に基づき、 外注のプログラマに実装してもらっています。 直属の先輩にしろ私自身にしろ 自社の人間がプログラマとして仕事をすることは一切ありません。 学生時代にちょこっとC言語を触っただけの私が ソフトウェアの基本設計書を作り、外注さんに指示を与えててもいいのか？ と悩んでいます。最近、プライベートでJAVA（外注さんの使用言語）の勉強を やっていますが、本当に趣味程度のものですね。 「SE」「プログラマ」といった単語をここで検索すると 「プログラマ経験のないSEなんて有り得ない！」といった 厳しい口調の回答もチラホラ見掛けるのですが、 自分はまさにその手の人間です。 今の会社にいる限り、今後もプログラマ経験は一切ないでしょう。 「プログラマ経験のないSEってのはアリなのか？やっぱりおかしいのか？」 アドバイスをお願いします。
- ベストアンサー
- SE・インフラ・Webエンジニア
- 自分用のアプリ開発の仕様書ってどうしてます？
PHPとMySQLを使ってサイトを運営したり、Excel VBAで私生活を便利にするツールを作ったりしています。 人に提供するものではなく、あくまで自分で使うようで、自分一人で開発しています。 ただ、本職のプログラマーでもなければサンデープログラマーですらなく、必要になったら調べて作るという程度です。 なので、本来プロが作る時みたいに全体を決め作るということができず、作りながらこういう機能が必要だったと思いつき追加するという作り方になっています。 そのせいかソースはグチャグチャで、はっきり言って自分で書いたソースを見直すのが嫌になるほど。 何か機能を追加したくて数カ月後に嫌々見直すときには何のソースだったかすら忘れていたりして苦労しています。 なので自分用のアプリとかでも仕様書が必要なのかなと。 ただ、先程も書きましたが、なんちゃってプログラマーなので、会社にある仕様書なんかを見ても何を言ってるのかわけわからん状態で、そもそも作りながら出ないと思いつけないので、作る前から仕様を決めてということが難しいです。 かといって作るときに仕様書を書くというのも面倒くさいし、作りながらだと仕様書もグチャグチャになりそうだし。 本職の人は、自宅で自分用のアプリやツールなんかを作る場合も仕様書は作るんでしょうか？ それとも本職ともなればソースも綺麗に書けるから自分用のものなら仕様書は不要？ 仕様書を作ってる方は、どんなふうに作ってるか教えていただけないでしょうか？ 人と共有するものではないので仕事で使うようなガチなものでなくても良いのはわかるんですが、それですらいまいちイメージが付かないです。 OSはWindows10、Office365は使ってるのでWordやExcelは使えます。 他に仕様書を作るのに便利なソフトとか、こういう使い方してるとかあれば教えていただけないでしょうか？
- ベストアンサー
- その他(ソフトウェア)
- 「テスト仕様書」の運用について ・どういう手法として知られているか
業務系のソフトウェアを開発・販売・保守している会社にいます。 今回、プログラム開発の過程に「テスト仕様書」というものが導入されることになりました。 通常、プログラマレベルでのプログラムの作成→担当SEもしくはその他の人がそれを検収の上ユーザに納入、という流れを取っています。 （ここにいう「作成」「納入」というのはシステム全体を納入するといったことではなく、例えば数十以上の実行ファイル等でできあがっているシステム全体のうち、実行ファイルを1コ追加する、といった単体レベルの話です。） 「テスト仕様書」の運用方法なのですが、 (1)通常の仕様書と同時に、あるいは少し遅れたタイミングでプログラマに渡す。 (2)稼働中のユーザと同じ動作環境のもとで、ごく限られた条件と、その条件によって出てくる予定の出力結果が提示してある。…帳票などでは範囲を広く指定すれば大量の出力結果が得られるわけですが、例えば「得意先は○○、商品は○○」の場合は「金額は○○円」と出てくる筈、というふうにごく一部だけが示してある。 (3)テスト結果をプログラム作成の終了と同時に、場合によっては途上で担当SEなどに早めに提出する。 …というものです。 趣旨としては、 (1)「テスト仕様書」の添付により、もともとの仕様書の不備を明らかにしやすくなり、かつ、プログラマの仕様の理解における勘違いを早めに正す。 殊に、誤解を招きやすい仕様の箇所に重点を置くと効果を発揮する。 (2)作成されたプログラムの本検収に取り掛かる前に一部でもテスト結果を早めに得ておくことで、検収やそれ以後の作業の迅速化を図る。（おもむろに取り掛かった本検収でプログラムの不備が初めて明らかになるより、ごく一部のテスト結果をちらっと見るだけでそれが間違いであることが分かればすぐに修正を依頼することができる。） (3)一部のテスト結果が正しければ全体も正しいという蓋然性が高まるので、プログラムの品質の向上に繋がる。 …というものです。 趣旨は良く分かりますし、特に「一部だけを早めに摘み食いする」という(2)の着眼点というのは面白いと思います。また、「得られるべき結果」を予測しておくための労力（言い換えれば「テスト仕様書」を作成するための時間)はかかりますが、あるべき出力結果を考えるというのはどのみち後でしなければならないことなので全体としての工数は変わらないという考えもあるようです。 …こういった手法は既に良く知られ、何かの名前が付いているものなのでしょうか。 書店で立ち読みなどをして文献を探したのですが（笑）、該当すると思われるものはありませんでした。 手法としての名前や、何か参考資料の在り処等を教えて頂ければと思います。
- ベストアンサー
- SE・インフラ・Webエンジニア
- 要求仕様に書く内容?
ソフトウェアの要求仕様を作成する仕事をしていますが、ハードウェアによる制限や ソフトウェア側の問題により、特定の条件では仕様を満たせないケースはどういう 風に扱うことが適切なのでしょうか? たとえば ・要求：「ボタンを押したら画面を表示する。」 ・制限： ハードウェアの仕様により、ごく短いボタン押下時間は検出できないことがある。 ・制限： ソフトウェアの作りの問題から、ある過渡的な状態では検出できないことがある。 といった状況があったとします。 こういったケースにおいて、ソフト開発者や検査担当者から 「ごく短いボタン押下は検出しない。」、「遷移中は検出しない」という「仕様」を追加して ほしい、という依頼がきます。(場合によっては、対応が間に合わない部分を「仕様」として 記載してほしい、という要望がくるケースもある。) しかし、これらの制限は「要求仕様」ではないので、私は要求仕様書に記載する内容では ないと思うのですが、ではそれ以外のどこで扱うかというと妙案が浮かばない状態です。 こういった内容は一般的に仕様として記載するものなのでしょうか? またそうでない場合、 どういう形で管理すればよいのか、皆様のご意見をいただけないでしょうか?
- ベストアンサー
- その他（プログラミング・開発）
- ファイル仕様書って何ですか？
たびたびお世話になってます！ また課題でファイル仕様書というものを作ることになったのですが、 ファイル仕様書とはどういったことを書くのでしょうか？ 今回のプログラムでは、線形リストを用いて入出力用のファイルを 用いることになるようですが・・・ （自分で書いてて何の事かさっぱりわかりません） あまり情報がなくてすみませんが、アドバイスいただけると助かります。
- ベストアンサー
- C・C++・C#
- プログラマー職はどういうものか
こんにちは。 自分は、ソフトウェアを作成する会社で働きたいので就職活動をしている者です。 派遣でもいいのでプログラマーとして活躍したいと考えています。 そこで質問なんですが、プログラマーとして働く場合最低どれくらいのスキルが必要 になるんでしょうか？ 言語が複数使えないとだめとかプログラムが組めるならだい たいこのぐらいできなきゃだめという感じで教えていただければ助かります。
- ベストアンサー
- 就職・就活
- 仕様書作成ってどのように書けばいいでしょうか？
私は建築設備&リフォーム屋に勤めています。 私の今までの主な仕事は下水道接続工事の訪問販売でした。 件数は少ないですが、リフォーム（トイレ、キッチン）を担当したことがあります。 入社１年目（来春２年目）なのですが、現在新築の現場管理を任されています。。。 一応建築の専門学校を卒業し、２級建築士の学科は受かりました。 ですが、現場は初めてなので今まで勉強してきた事が浅すぎると感じています。 しかも、先輩社員さんに建築士はいません！！！！ そして恐ろしいことに、当社で新築工事をやるのは初めてです！ 教えてくれる先輩や建築に関して頼りにできる先輩などがいません（＞＜） 地盤改良、基礎工事、詳細図、納まり、、、全てわからないだらけです。。 特に今回プレカットでやるので、私達も、いつも依頼している大工さんも初プレカットで収まりなどよくわかりません。 通常であれば大工さん用の仕様書を作成しなければならないはずなのですが、、上にも書いたように建築に詳しい先輩がいないので、今までのリフォーム工事は仕様書無しで大工さんにやってもらってました。 しかし今回は新築なので仕様書無しは無理です。 大工さんにも仕様書を出してくれと言われています。。。 ネットでも日々新築工事について調べていましたが、、限界です！！ 仕様書はどの図面を見てどのように作成すればいいのでしょうか！？？ 何が必要かアドバイスだけでもいいのでおねがいします！！！！！！
- ベストアンサー
- 新築一戸建て
- 脅迫など法律にふれるものですか
仕事で下請けの人(下請会社所長)からメールでおくられてきたものですが、仕事ほしさゆえにものようなメールを送ってきました。 自分が他社に仕事をさすと冗談まじりで話したのが事の始まりです。 【メール本文】 僕は、今眠れません！冗談で(自分)君が、(下請けライバル会社)に、仕事をさせると本社に言ったら、(自分)君の現場は、一切仕事をするなとのことです。（自社)とは、取引をやめる！引き上げるとのことです(下請会社)の社長と本社の会長が(自社)社長に、話しに、いくそうです！本社に、(自社)の現場及び担当者名！いつも報告しています(泣)マズい！ 義理、人情ない会社社とは、取引は、しない！とのことデス・僕シラナイ～・・・・(自分)君が会社をやめるか、(下請会社)が手をひくか、ですって、冗談から、大変なことに、なりました！では・では・・・ という文章です。 自分が仕事がほしいがゆえに脅しをかけてきたものです。 このようなことが法律に触れる事なのか、専門の方意見をお聞かせ下さい。
- 締切済み
- その他（法律）
- 仕様書が。。。
10年のブランクから抜け出し、会計業務他もろもろの受注会社を作りました。 が、今の自分の守備範囲を遥かに越える仕事が。。。。 恥ずかしい事に、システムの仕様書が書けませんでした。元々の仕事だったはずが。。。。 これが書けないと仕事が進みません。何かヒントになりそうな情報があったら 是非お知らせ下さい。よろしくお願いします。
- 締切済み
- その他（プログラミング・開発）
お礼
大きな流れを書いて、細かい流れを書いていくのですね。 後々の修正の事も考えて書いていくのですね。 回答ありがとうございます。