見出し画像

システム設計とは?現役ITエンジニアが思うところ

はじめに

・前提として

ここで述べるシステム設計は、基本設計、詳細設計といった細かい括りではありません。
開発に向けて行われる設計全般、要件定義から詳細設計あたりを想定して、自分の思うところを語ってみたいと思います。

また、私はこれまで顧客ありきの受託システム構築の経験のみなので、不特定多数向けにサービスを展開しているシステムについては除外します。

「システム設計とは?」その意味するところを改めて考えてみました。

・システム設計を改めて考えるに至った理由

最近、自分が働いている現場であった障害報告で、設計書通りにコーディングした結果、不具合が発生したという内容がありました。

現行システムへ機能追加を行う対応があったため、該当の設計書に追加機能の仕様が追加されましたが、既存の機能との繋がりが見えない追加のされ方になっていました。
恐らく追加機能の仕様を、文字通り設計書に追加しただけの対応になってしまったのだと考えられます。

これを聞いて思ったのは、設計を行った当人は設計をする目的を考えていないのではないか?ということです。
設計書を作ること、または修正することが目的になっているのではないか?とも考えられます。

設計はエンジニアに求められる重要なスキルの一つです。
この障害報告をきっかけに、設計は何をするのか、なぜ設計書を作るのかについて改めて考えてみようと思いました。

設計とは何をするのか

・どのようなシステムを作るのかを決める

受託開発の場合、顧客からの依頼を受けてシステム開発が始まります。

多くの顧客は作りたいシステムについて曖昧で、ふわっとしたイメージでいるため、コミュニケーションを重ねて明確にしていくことが必要です。

前提として、顧客が何を目的としてシステムを必要としているのか、把握しておく必要があります。
目的を理解するためには、顧客のビジネスについても知っておく必要があります。

どのようなシステムを作るのか曖昧な状態で進めてしまうと、開発を進めていく段階で「あーでもない、こーでもない、あれもこれも必要」といった感じで要件が膨らみ、当初の予定が破綻ということになりかねません。

(私も過去にやらかしました…。)

・システムを実現するための手順を明確にする

作りたいシステムが決まったら、システムを実現するために必要な機能や性能を決めます。
必要な機能や性能が洗い出されたら、それらを満たすための仕様を決めます。

仕様が決まったら、仕様を実現するためにシステムをどうやって作っていくのかを考えます。
その際には、開発工程以降、リリース後の運用保守のことも考えられた内容にしておくべきです。

過去の経験上、運用保守までしっかり考えられているシステムは少ないと感じています。
不具合を検知する監視メッセージが不十分だったり、なぜ組み込まれたかわからない謎処理に振り回されたり等がありました。

設計書を作る理由

・システムのイメージを共有するため

まずは顧客との、システム完成イメージを共有するために設計書が必要です。

どのようなシステムを作るのか決めた後、システムを実現していく手順を決めていきますが、顧客が求める内容であるかどうか確認を行う必要があります。
顧客が意図していないシステムを作り上げてしまっては、元も子もありません。
つまり、顧客がシステム完成イメージを想像できる内容である必要があります。

次に後工程の担当者への引継ぎ資料、指示書として設計書が必要です。

システム開発の多くは、最初から最後まで同じ人が担当することはありません。
上流工程、下流工程、もしくは工程毎に担当者が変わることがあります。
つまり、実現したいシステム仕様、機能詳細、実装内容等を第三者に伝える内容である必要があります。

・運用保守の負担軽減のため

問い合わせや障害等、スピード感が求められる場面で設計書はとても有効な手段となります。
また、システム改修の要望が出た場合に、どこにどのような改修をすれば良いのか判断しやすくなります。

設計書がないと、都度ソースを解析する必要があり、スピード感を損なっています。
また、設計書に不備があると正しい情報がわからなくなり、結局はソースを解析しなければならないという事態になります。

とはいえ、私が過去に経験してきた中で設計書が不備なく揃っていると思えた現場は皆無でした。
結局はソースを解析し、不備がある内容については設計書を改善していき、充実させていくことを繰り返しています。

特に誤った情報が設計書に記載されているのは厄介です…。

さいごに

エンジニアが開発現場、もしくは保守の現場で「設計してください」と依頼されたら、設計書の作成、修正を行うでしょう。

システム設計をしたその結果を第三者に伝えるために、設計書を作ります。
「設計書を作ること=設計をする」ではありません。

その設計書、何のために書いていますか?誰に向けて、何を伝えようとして書いていますか?
設計書を見たら、システムがどのようなものかわかりますか?システムを実現するための手段は適切ですか?

これは自分自身への教訓でもあります。
現在、保守の現場に入っており、度々システム改修を行っているため、設計書の修正を行う機会があります。

設計書を作ること、修正することがゴールにならないように、目的を忘れないように、noteに残しておきます。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
ありがとうございます(^^)
3
SES企業所属のITエンジニアです。 学びになったことのアウトプットをする場に出来ればと思います。 Twitterやっています。https://twitter.com/AoiLaurent
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。