ウォーターフォールの詳細設計(設計)について

皆さんこんにちは。どうも。

今回は、システム開発について、私自身の経験を交えながらお話しします。

まず、システム開発とは何か?ですが、その名の通りシステムを開発してリリースする仕事になります。

で、システム開発手法には、ざっくりとアジャイルとウォーターフォールがありますよね。

アジャイルは機能ごとに設計→開発→テスト→リリースを回していく手法です。なので、機能追加などに柔軟に対応できますが、その都度開発スケジュールなどを見直す必要があります(参照)。

一方で、ウォーターフォールは、予めシステム全体の要件定義→設計→開発→テスト→リリースが決まっています。なので、開発スケジュールや開発コストの見積もりがしやすいですが、機能追加などには柔軟に対応できません(参照)。

なので、それぞれメリット、デメリットがあります。

で、私は今までウォーターフォールの詳細設計(一部基本設計)~テストまでの経験がありますが、実を言うとあまり設計には精通していません。

というよりも、設計に関しては、2社ぐらいの仕事しか経験が無いですし、設計書の書き進め方やフォーマットも会社ごとに結構違うので、何とも言えないですが、本格的なシステム開発会社で設計をしていた時は、実はかなり遅延していました(ここでの設計とは詳細設計のことです)。

理由は様々ですが、主な理由としては、そもそも設計書を書くための情報が完全にそろっておらず、ASISの設計書(基本設計)などを書いている上位会社に問い合わせをしていたり・・まあ、要は一言で言うと情報収集に時間がかかっていたことによります。

なので、設計書を成果物として完成させるには、大前提としてそれを書くための情報がそろっていることがあります。

詳細設計書の目的は、それを見て開発ができるかどうか?です。

なので、詳細設計の段階で、不明点は洗い出さないといけませんし、開発で悩むであろう点をクリアにするための情報を収集して落とし込む必要があるのです(こういう部分に時間がかかります)。

もちろん、(1社であっても)設計の経験値があれば有利ですが、会社が違うと設計書のフォーマットなどもガラッと違うことがあるので、市場で通用する設計スキルを身に着けるのは、色んな会社で設計を経験するのが一番いい気がします。

後は、設計で利用するであろう、フローチャートやクラス図やシーケンス図などの他に、SQLなどに慣れておくのもいいと思います。

チームで開発をする上では、詳細設計以外でもDB設計などをドキュメントとして落とし込む必要があります(テーブル定義の更新やSQLのパフォーマンスを考慮したりも・・)。

その上でも、上記のように(設計で使いそうな)各種チャートの書き方に慣れておくと有利だと思います。

はい。以上、手短ではありましたが、設計に関してでした。

設計に詳しい方や、経験が長い方はアドバイスなりいただけると幸いです。

よろしくお願いいたします。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA