MENU

NIC BLOG

Voice of the Staff

モノをつくる。byソフトウェアぎょーかい

モノをつくる。byソフトウェアぎょーかい

こんにちは。新型コロナウイルスの感染拡大を受け、在宅勤務中のです。

えーと。新人さん達も配属されてきたので、いろいろと教えたり質問されたり、
在宅でコミュニケーションをとりながら、おしごとを進めているです。

zaitaku_telework_man.png

のおしごとであるソフトウェア業界でもシステムを"つくる"といった事を行います。

お客様のやりたいことを聞いて、プログラムをつかってサービス・システムを提供します。
その中で、設計書をつくるって作業があります。

新人さんへの説明を込めて設計書って何ぞをかるーく書いてみます。

設計書とは
基本設計書:システムを外から見たときにどういう動きをするかを記載された資料
※別名:外部設計・概要設計・システム設計etc

詳細設計書:基本設計で決定した動きを、どのように実現するかを記載された資料
※別名:内部設計・ソフトウェア設計etc

job_kenchikuka.png

大抵はこの2種類の設計書が存在しています。
開発案件によって呼び名がかわる?(なんらかのこだわり??)

なぜ書くの?

question_head_boy.png


1.完成イメージの共有
2.プログラマーへの仕様提示
3.保守・運用の負担軽減

1.完成イメージの共有
お客様の完成イメージとあっているかを確認する。
お客さん側から見て要求事項と相違が無いよねって見てもらいます。
つくり終わってからやっぱりこうして欲しかったは困りますよね。。

2.プログラマーへの仕様提示
プログラマーは、システムエンジニアの書いた詳細設計書を見てプログラミングします。
基本設計書は顧客がイメージしやすいことを念頭に書き、詳細設計書はプログラマーが作業しやすいように配慮して書くことが肝です。

3.保守・運用の負担軽減
システムを開発した人が、必ずしもそのシステムの保守や運用を行うとは限りません。通常は別の人が保守業務を担当しますが、
もし、設計書がなければ、問い合わせ対応や障害調査、障害の修正に対応するためにソースコードを解析して理解するしかありません。

こちらについてもう少し

pierrot_cry.png
しかし、「設計書が古い」「あるけど信頼できない」という言葉をよく耳にします。
障害(バグ)の対応、使いにくいところの改良、機能の向上、プラットフォームの世代進化への対応、
ビジネスの変化への対応などにより、何度も何度も追加開発が行われます。
その全てをきちんと設計書に反映しておけば、設計書が信用できないなどという事態には陥りません!!ここ大事よ。
しかし、こうしたシステム変更においては、まず、プログラムを変更した後から設計書に反映するようなことも多く、
システム導入時のようにきちんと設計レビューをして記載洩れや記載ミスを防止するような慎重さはが薄れます。
また、担当者も都度変わるので、一貫した設計品質を保つのがだんだん難しくなってきます。
さらに、ちょっとでも手抜いたところがあれば、もはや次からは信頼されなくなるのです。

スクリーンショット 2020-10-06 095056.png

変更についても履歴を残し、全て反映させておけば「設計書が古い」なんて言葉はなくなるのです。

今回はこんな感じで、おわります。在宅勤務中のでした。

mokei_puramo_boy.png

小学生の頃作ったミニ4駆の説明書(ガンプラ等も)、幼き子供が説明書見て作って完成出来るってすごいなって。
組み立てパーツは固定のものですが、組み立てイメージが付きやすい絵とか、ハマったらパチンと音がする等いろいろ。
勉強になります!

前の投稿 >

カテゴリ

このブログはNIC社員が定期的な(?)更新を行っています。
各担当者は普段の業務の合間をぬってブログの記事を作成していますので、日付順で表示した場合にはいろいろなカテゴリがごちゃまぜで表示されます。
カテゴリ別の表示をしていただくと、ひとつの流れとして読みやすくなると思います。

月別アーカイブ