エンジニア

詳細設計書が書けない?仕様書が書けなくても最低限やるべきこと!

2020年5月25日

詳細設計が書けない

 

基本設計を終えて、次は詳細設計。
だけど詳細設計書ってうまく書けないんだよな。。
プログラムもあまり経験してこなかったし。
いったい何を書けばいいのか。。

 

こんにちは、古賀です!

 

本記事では、

はてな

  • 詳細設計書を書く上で、最低限抑えておくことは?
  • 詳細設計で最も大事なこととは?

についてお話します。

 

詳細設計が書けない理由は、人それぞれあると思います。

「プログラム経験が少ない!」

「時間がなくて、隅々まで書けない!」

 

本記事が、その「書けない理由」に対して、少しでも手助けになればと思います。

 

安心してください。

詳細設計はわたしの得意分野です!

わたしの経験を参考にして、プログラマーから感謝される詳細設計書を作成しましょう!

 

自己紹介が遅れましたが、

わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして

約10年間働いておりました。

プロフィールの詳細はこちらです。

 

先に詳細設計を作成する上で、最も大事なことを伝えておきます。

それは、

ポイント

「気持ちを伝えること!」

です!

 

「気持ちを伝えること」が、詳細設計の基本です!

これを忘れないようにしましょう!

詳細設計とは?何のため?目的を忘れないように!

V字モデル-詳細設計

詳細設計は、以下の目的のために作成します。

  • プログラマーが詳細設計を見ながら、プログラムを作成するため
  • 詳細設計を見ながら、単体テストを行うため
  • 運用保守時に詳細設計を見ながら、調査を行うため

この3つを抑えておきましょう。

 

お客さんに提出する企業もあるかと思いますが、

「提出しない」前提で話を進めます。

そうすると、完全に「開発企業内の資料」になりますね。

 

詳細設計書は、

ポイント

「自分たちを守る資料」

になります。

詳細設計が書けなくても最低限抑えておくべきこと

設計書

詳細設計がうまく書けなくても、最低限できることはやりましょう。

  • テーブル設計書
  • 転送表、更新表
  • 画面レイアウト、帳票レイアウト
  • エラーチェック

くらいですかね。

1つ1つ見ていきましょう。

テーブル設計書

テーブル設計書は、一番最初に作ってしまいたい設計書です。

できれば、

「少しずつ作るのではなく、全体を見通して一気に作る」

ことを意識しましょう。

 

プログラム内だけで使用する「ワークテーブル」等は、プログラマーに任しても良いです。

システムエンジニア目線で必要な部分だけでも作成していきましょう!

転送表・更新表

転送表と更新表は以下を抑えましょう。

アウトプット処理は「データ取得元」

インプット処理は「データ更新先」

上記は基本設計工程で、お客さんと大体の内容を決めているはずです。

 

「ここのインプット項目が、ここに反映されます。」

 

みたいなことをしていると思いますので、

基本設計の内容をベースに「転送表」、「更新表」を完成させましょう!

 

「どうやって更新するか?」

「どうやって取得するか?」

が書けない場合は一旦置いておきましょう!

画面レイアウト、帳票レイアウト

「画面レイアウト」や「帳票レイアウト」は、基本設計で間違いなく決めているはずです。

詳細設計は桁数等に注意して、コピペで完成です!

エラーチェック

「エラーチェック」も基本設計で決めている部分が多くあると思います。

これもコピペでOKです!

 

その他に、

「システム上で必要なエラーチェック」

があると思いますが、一旦分かる範囲だけで大丈夫です。

詳細設計で一番大事なこと!それが「気持ち」!

ありがとう

冒頭でお伝えした通り、詳細設計で一番大事なことは「気持ち」です!

 

詳細設計が書けない方の大半の悩みが、

はてな

「どうやってこの処理を実装するか?」

の部分かなと思います。

時間もかかりますしね。

 

「どうやって?」の部分を、システム設計書っぽく書かなくてもいいです。

「気持ち」を伝えるために、必要なことは、

ポイント

  • 「何故その処理が必要なのか?」を伝える
  • 処理結果が分かる資料を用意する

この2つです。

「何故その処理が必要なのか?」を伝える「メリット」

プログラマーに対して、

「こうやって作ってください!」

とだけ伝えると、プログラマーはその通りに作るしかありません。

(その通りに作ってくれるかは置いといて。。)

 

しかし、システムエンジニア側の意図や背景を伝えておくことで、

「プログラマー側が一緒に考えてくれる」

ようになります。

 

1人よりも2人。2人よりも3人です。

複数人の力を借りて、詳細設計を完成させましょう!

難しい処理の部分は、プログラマーにお願いしてもいいんです!

 

「意図」や「理由」、そのあたりの「想い」は必ず設計書に残しておきましょう!

 

「想い」は運用保守時にも、手助けになります。

「なんでこんなふうになっているのか。。」

と困った時に、意図が記載してあれば、どのように解決していけばいいかの道しるべになります。

 

そのために、

ポイント

「意図」や「理由」をプログラマーと共有する

ことを意識しましょう。

 

意図の記載は、処理ロジックよりも大事です。

先程の「システム上で必要なエラーチェック」も、

プログラマー側が気付いてくれたりしますよ!

処理結果が分かる資料を用意する

「意図」や「理由」を伝えても、

「それだけじゃ作れねぇ!」

とプログラマーに言われそうですね。。

 

なので、

「処理結果が分かる資料」

を作成しましょう!

 

頭の中に浮かんでいる「処理例」を、「絵」や「図」を使って表現しましょう。

 

「データがこういう状況の場合、処理した後はこうなってほしい!」

ということが分かる資料があれば、

プログラマー側で、

「どうやってこの処理を実装するか?」

のイメージが湧いてきます。

 

処理例、処理結果は汚くてもいいので、資料として残しておきます。

「とにかくプログラマーに気持ちを伝える」

これだけ意識して資料を作成しましょう!

「処理結果が分かる資料」は単体テスト仕様書になる

「処理結果が分かる資料」の作成は、少しめんどくさいかもしれません。

 

ただ、この作業は無駄ではありません。

なぜなら、

ポイント

「処理結果が分かる資料」は単体テスト仕様書になる

からです。

 

後でどうせ単体テストをやります。

単体テストの準備作業です。

単体テストの仕様書作りだと思って、「処理結果が分かる資料」を作成しましょう!

 

できたら詳細設計と同時に、

単体テストの仕様書を完成させておくことをオススメします!

 

単体テスト仕様書を詳細設計と一緒に作ることで、

  • いつの間にか「良い詳細設計書」が出来上がる
  • プログラマーが作りやすく、デバッグしやすい

からです。

 

単体テストでやろうと思っていることを書き出していくと、

次第に詳細設計書もうまく書けるようになっていきます。

 

手間が掛かるかもしれませんが、

「めんどくさいことを先にやる」

という精神です!

 

始めのうちにした苦労は、後で爆発的な時間の余裕を生みます。

常に「一流の考え方」を意識しましょう!

「考え方」に関する記事はこちらです。

エンジニアとして成長するための考え方!一流へ成長する方法とは?

まとめ

ここまでの話をまとめます。

まとめ

<詳細設計で最低限抑えておくべきこと>

・テーブル設計書

・転送表・更新表

・画面レイアウト・帳票レイアウト

・エラーチェック

<詳細設計で一番大事なことは「気持ち」を伝えること>

「意図」や「理由」を伝えることで、

・プログラマーが一緒に考えてくれる

・運用保守時の手助けになる

「処理結果が分かる資料」を用意することで、

・プログラマー側で実装イメージが湧く

・単体テスト仕様書が同時に作れる

 

「気持ち」を伝えることで、当初の詳細設計の目的の3つ、

  • プログラマーが詳細設計を見ながら、プログラムを作成するため
  • 詳細設計を見ながら、単体テストを行うため
  • 運用保守時に詳細設計を見ながら、調査を行うため

が網羅されてますね。

 

気持ちさえ伝われば、詳細設計書は自分ではなく、後から他の人が書いてもいいんです。

その分、得意なことで貢献すればいいです。

 

わたしはシステムの全体的な仕組みや、共通事項を記載した、

気持ちを伝える資料を作成したことがあります。

 

プログラマーが開発作業を行う前に、

その資料を使って「想いの共有」をしました。

 

そのドキュメントは後から参加するプログラマーや、

周りのシステムエンジニアからは絶賛されました。

 

ただ、社内の設計書のチェック機関からは酷評されました。

「そんなの詳細設計じゃない」と。

 

それでもいいんです。

大事なのは、

「お客さんに品質の良いプログラムを届けること」

です。

「お客さんの業績が上がること」

です。

そのために必要なことをやる。それだけです。

 

詳細設計が書けなくてもいいです。

気持ちさえ伝われば!

自分にできることをやりましょう!

 

詳細設計にケチつけてくる人が大半だったら転職もありですよ。。

自分の力を発揮しやすい環境で働きましょう。

 

システムエンジニアの記事へ戻る

SIer業界の記事へ戻る

おすすめ記事

道のり 1

※本記事は、各記事のまとめ記事です。   こんにちは、古賀です!   本記事では、 「プログラミング未経験者がエンジニアとして働き、 年収1000万に到達するまでの道のり」 をご説 ...

成長するエンジニア 2

  エンジニアになったけど、いまいち成長を感じられないなぁ。。 作業スピードも品質も平凡。 この先成長していけるんだろうか。。   こんにちは、古賀です!   エンジニア ...

闘病記 3

※本記事は、各記事のまとめ記事です。   こんにちは、古賀です!   わたしは25歳の時に、悪性リンパ腫になりました。 不安な気持ちになって、たくさん泣きました。 本気で「死ぬかも ...

プログラミングスクール 4

  プログラミングを本格的に勉強して仕事に繋げていきたいけど、 プログラミングスクール多すぎる。。 どういう目線で選べばいいんだ。。   こんにちは、古賀です。   プロ ...

-エンジニア
-, ,

Copyright© Koga Masao's LifeBlog 〜Alive Today〜 , 2020 All Rights Reserved.