Q&A
質問者さんが仕事をしている現場で、周りにドキュメントを書く（書ける）先輩や上司はいないのでしょうか。
今までの現場では設計書らしい設計書を書いたことがなく
以下の３つの書き方が詳しく理解できているわけではありません。
※設計書タグがなかったのでPHPにて失礼いたします。
ネットでいろいろな方の記事を見るのですが、実際になにかの設計書を見たわけではなく
書き方の説明なので、あまりイメージがつきません。どのように勉強すればよいいでしょうか？
いいサイト、オンライン講座、Youtube等など、あなたなりの覚え方を教えていただけたら嬉しいです。
試しに書いてみた場合どこで添削等してもらったらいいでしょうか・・・
・要件定義
・基本設計
・詳細設計
アジャイル開発の現場で、周りも書いたことがないので覚える必要のないの一点張り
現場に資料はなく以前の職場では書いたことある人が多々いるが、その設計書をもっているわけもなく・・・といった感じです
回答3件
0
ベストアンサー
プロジェクトや顧客によります。
決まったフォーマットがあるわけでもなく、大まかに「こういうことを書きましょう」という指標はあれど絶対ではありません。
場合によって挙げられた３つの間に別の設計フェーズも出てくることだってありますし、ウォーターフォールかアジャイルかでも求められる成果物は違ってきます。
試しに書いてみた場合どこで添削等してもらったら
そういうのは、ありません。
プロジェクトによるので。
ただ、考えるべきは、その工程での成果物は次の工程でのインプットとなる資料ですので、「次工程がつつがなく進行できれば正しい」とも言えます。
次工程で不足や不備に気づけば前工程のやりなおしや成果物の修正を行い、整合性をとります。
なるべく「次工程の担当者の感覚や実装に任せないように」配慮することが大事ですね。
まあ、製造工程までおりてくると、どうしてもPGの実装に任せるようなことは出てきますけど、習熟度のあまり高くないメンバーが担当する場合はそれだけ前工程がしっかりしている必要があります。
そこをしっかり先導できるITアーキテクトの存在は不可欠ですね。
投稿2020/03/05 05:58
総合スコア80863
無知な私に、回答ありがとうございました。アジャイル開発しか経験がなく、職場で設計書を求められたことはないのですが、転職の際の質問項目によく出てくる項目でしたので
書けないよりは書こうと思い質問させていただきました。
アジャイルでもきちんと書くところは書くでしょうし、本来は見積もりにも出てくるところです。
現場で求められないならあえて現場で書く必要はないかとは思います。工数の無駄なので。
転職活動ではけっこう「自ら勉強していることはあるか」という質問はあります。
その際に、自身でプロダクトを提出することはあるでしょうし、そのプロダクトはなんとなくでも設計書書くようにしたら良いかと思います。
メモレベルでもあると違います。
「やったことがあるか」よりも「どんなものか知ってるか」が企業が知りたいことです。
あとは現場で覚えるしかないでしょうね。
マニュアルまで整備されているところもあるし、「これまでのを読んで真似して」というところもあるし「自分でやって」というところもあります。
基本設計にちょっと処理書いただけの詳細設計もありますしね。
あくまで客先納品のためだけに書くことだってあります。
基本的には「要求仕様をきちんと満たしたアプリケーション」が最も求められるので、そのアプリケーションが出来上がれば良いのです。
0
結論から言いますと、
今いる現場(もしくは会社)で書き方を知っている上司又は同僚の方にレビューしてもらう以外ないです。
理由は現場によって書き方は全く異なるからです。
テンプレートも会社ごとに異なります。
ネットの書き方はあくまで参考にしかなりません。
情報はバラバラだし、部分的にしか記載していないことが多いからです。
(こういうのは根本がわからないと表面的な書き方しか出来ません。)
勉強するならある程度体系的に情報がまとまった本のほうがいいです。
私の場合[SEの基本]という本で大まかに勉強しました。
曖昧な表現が許される現場もあれば、キッチキチに調べ尽くし、漏れなく記載しないと行けない現場もあります。
前の現場の書き方を次の現場でやったらボロっカスに叱られることもありました。
現実的に言うと実際の書き方は酷評の果に差し戻し覚悟で現場で学べです。
投稿2020/03/05 06:13
総合スコア179
0
どのように勉強すればよいいでしょうか？
実際に考えながら書かないと身につかないので
- 過去に関わって要件を把握しているプロジェクトについて実際に要件定義書/設計書を書いてみる
- 簡単な要件のプロジェクトを仮定して、実際に要件定義書/設計書を書いてみる
体裁、フォーマットや項目については組織によって異なるので、とりあえずは教科書とする情報源のフォーマットに沿って作ってみましょう。
試しに書いてみた場合どこで添削等してもらったらいいでしょうか・・・
ボランティアで添削してくれるような機関は存在しないと思うので（もしかしたらあるかもしれませんが）Mentaあたりで有料で教えている人を見つけて添削を依頼するのが良い気がします。
もしくは、
- 実際に出力された設計書だけを頼りに自分で実装をしてみる(勝手に補完してしまうので結構難易度は高い)
とか
- 2-3人で同様に設計書を作ってみて、設計書を交換して実装してみて設計書に対して相互レビューをする
あたりでしょうか。
投稿2020/03/05 06:03
総合スコア18716
ありがとうございます！
過去やってみたプロジェクトを設計書に起こしてみますね！！！
ありがとうございます！
現場で求められるフォーマットがキャリアプラン的に役に立つかというと「現場の質による」としか言えないので、体系立った形でドキュメントの書き方や要件定義の仕方を勉強するのはとても良いことだと思いますよ。
納品物としてのドキュメントを書こうとすると、顧客の事情というドキュメントの品質とは別の評価軸が働いてしまうので、まずは開発に役立つドキュメントを書いていく（コードを書く前にその範囲の外部仕様書を書いてからコードを書いてみるとか）もいいかもしれませんね。
少し遠回りに思うかもしれませんが、プロジェクトマネジメントの観点からのドキュメンテーションはかなり体系立っているので、そういう方向で調べてみるのもお勧めです。
https://www.ipa.go.jp/ikc/reports/20190912.html
とかも参考になります。
あなたの回答
tips
プレビュー
