こんにちは。倉内です。
ITエンジニアの業務といえば、「開発」がまっさきに浮かぶと思いますが、実は開発に至るまでにさまざまな工程があります。
自社開発と受託開発で多少違いはありますが、どちらにしてもいきなりコードを書き始めるということはありません。
開発を始める前に、そのシステムは誰が使うのか、どのような目的を達成すべきなのか、達成するためにはどのような機能が必要か、予算と納期はどのくらいか…といったことを明らかにし整理する必要があります。
プログラミング学習と比べて独学が難しく、実務を通して経験を積む必要がありますが基本的なことは押さえておいてもよいかもしれません。
そこで今回は、システム開発における上流工程（要件定義、設計）についてお伝えしていきます。
システム開発の「上流工程」とは？
「上流工程」という呼び方は、システム開発モデルのひとつである「ウォーターフォールモデル」から来ています。
ウォーターフォールモデルは複数の工程で構成されており、原則として前の工程が完了しないと次の工程に進みません。
ウォーターフォールモデルのイメージ
上から下へ水が流れるように不可逆な時系列順で進めていくため、はじめのほうにある要件定義や基本設計、詳細設計を「上流工程」と呼んでいます。「上流だからよい」「下流だから悪い」といった意味はありません。
「下流工程」である開発とテストがスムーズに手戻りなく進行するためには、「上流工程」でいかにユーザーのニーズを汲み取り、できる限り漏れなく仕様に落とし込めるかにかかっています。
もうひとつよく知られている開発モデル「アジャイル開発」では、チームで要件定義→設計→開発→テスト→リリースといった工程をひとつの単位とした小さいサイクルで繰り返します。
アジャイル開発では、このような小さいサイクルを繰り返すことでリリースまでの期間を短くできますし、開発期間中の仕様変更に強いためリスクを最小化することもできます。
「ウォーターフォールは古くてあまりいいところがない、今はアジャイル開発一択！」という意見も見かけますが、どちらもメリット・デメリットがあり、プロジェクトの規模や制約条件などで異なってくるので一概には言えないかなと思います。
ウォーターフォールは前工程の完了、すなわち「品質の確保がなされている」という前提で次の工程へ進めるため（実際は……難しいですが…）手戻りがない（はず）という利点があります。
ただ、やはり最近はユーザーのニーズの変化が激しいこともあり、サービスの改善を続けながら完成させていくアジャイル開発のほうが適しているケースが多いかもしれませんね。
「上流工程」の概要を押さえよう
要件定義について
要件定義工程では、次のことを実施します。
- ユーザーニーズのヒアリング、もしくはニーズ調査を実施する
- 要求をシステムでどのように実現するか要件に落とし込む
- 機能要件、非機能要件としてまとめる
- システムの全体構成を決める
- 要件定義書としてドキュメントを作成する
受託開発の場合は、要件定義を実施するにあたってユーザーの業務を理解する必要があります。前職のSIerでSEをやっていたころは、業務理解のためにお客さまのオフィスで数日間みっちり教えていただいたこともあります。
リプレイス案件であれば、現行システムを見せてもらうのが一番よいです。
さらっと書きましたが、上記をうまくこなすのは結構大変です。経験を積むことで精度が上がってくる部分でもありますし、絶対的な正解がないのが難しいと言えます。
一般化するのが難しいですが、挙げるとすればこういったスキルが必要かなと思います。
- ユーザーニーズを引き出すためのヒアリング力
- ユーザーの業務を深く理解し的確に提案ができる力
- システムで実現可能かどうか、どんな機能で実現するか具体的にイメージするための技術力
- システム化にあたっての工数やスケジュールを見積もるスキル
- 要件を分かりやすく、正確にドキュメント化するスキル
なお、要件定義については以下の記事でも詳しく解説していますのでごらんください。要件定義工程で気をつけることや具体的なアウトプットなどを記載しています。
設計について
設計には大きく分けると基本設計と詳細設計のふたつあります。
基本設計
基本設計は、要件定義で決めた機能要件と非機能要件（性能、制約条件など）について基本的な仕様を決めるために実施します。
画面（UI、画面遷移、操作性）やデータ（データ出力、帳票出力）などユーザーが見える部分を設計することから「外部設計」とも呼ばれます。
受託開発の場合、基本設計工程でのアウトプットは納品物になる場合が多いので、お客さまにどのドキュメントを納める必要があるのか契約時に確認しておきます。
プロジェクトごとに違いはありますが、一般的なものを以下に示します。（これがすべてというわけではありません）
基本設計の成果物
- システム全体構成図
- 業務フロー図
- 機能一覧表
- 画面レイアウト図
- 画面遷移図
- 帳票レイアウト図
- ER図（実体関連図）
- テーブル定義書
- CRUD図
少し古いですが、IPAが「超上流から攻めるIT化の事例集：システム化の方向性と計画」として、成果物のサンプルを多数提示しています。
こういったドキュメントは会社によって文化があり、フォーマットや記述の仕方もさまざまですが、どういったものなのかというイメージを掴むには十分だと思います。
超上流から攻めるIT化の事例集：システム化の方向性と計画：IPA 独立行政法人 情報処理推進機構
また、ER図はこちらの記事が詳しく解説してくださっているので、参考にしてみてください。
詳細設計
詳細設計では、これまでの工程で定義されたシステムの機能や動作をより詳細にかつ具体的に定義します。目に見える部分ではなく、システムの処理にかかる内容を設計することから「内部設計」とも言われます。
この次の工程が開発なので、この詳細設計でプログラムで実現できるところまで落とし込む必要があるということです。
詳細設計が不十分だとコーディングの際に「どう実装すればいいか分からない」「考慮されていないケースがある」などトラブルの元になります。
また、受託開発の場合、手戻りが発生するとスケジュールの遅延だけでなく、お客さまに承認をいただいている内容を変更しなければならず想像以上に工数がかかります。
これもプロジェクトごとに違いはありますが、一般的な成果物を以下に示します。（これがすべてというわけではありません）
詳細設計の成果物
- アクティビティ図
- シーケンス図
- クラス図
- 処理機能記述書
- インターフェース仕様書
- モジュール構造図
基本設計よりも耳慣れないものが多いかもしれませんね。趣味の開発ではここまでやらないでしょうし、場合によっては業務での開発でもこれらをすべてそろえるわけではありません。
こちらも一部ですが、IPAのサイトにサンプルがありますので、具体的な内容を知りたい方はごらんください。
汎用的教育コンテンツ サンプルダウンロード：IPA 独立行政法人 情報処理推進機構
自社サービスの開発ではあまりこういったことはないかもしれませんが、受託開発では設計者と開発者が異なることがよくあります。できれば詳細設計と開発は同じ人（同じチーム）が実施したほうがよいと思います。
また、今回はインフラ設計（サーバやネットワークの構築や設定手順など）やセキュリティ設計については触れていませんが、業務ではそれらも重要な工程のひとつです。
「上流工程」ができる職種は
エンジニアとひとくくりに書いてきましたが、上流工程を担当する職種もあれば、開発がメインの職種もあります。
上流工程はコーディングとはまた違った難しさや楽しさがあります。ユーザーニーズをシステム化するための重要な工程ですし、自分が構想から携わったものがシステムになるという達成感は格別です。
paiza転職でも企画や提案から始まり、要件定義・設計といった上流工程から携われる職種の求人を多数掲載しています。興味がある方はぜひ覗いてみてください。
ただ、前述のとおりプログラミングスキルがないと上流工程で抜け漏れがあったり、実現不可能な内容を定義したりとあと工程に支障が出ます。
スキルチェックを受けてみて自分のプログラミングスキルがどの程度なのか腕試しをしてみるのもよいでしょう。
まとめ
システム開発の上流工程である要件定義と基本設計、詳細設計の基本事項をお伝えしてきました。
冒頭でも書いたとおり、エンジニアの業務というと開発のイメージが強いですが、そこにいたるまでにはこのような重要な工程があります。
昨今の多様化するユーザーニーズに応えるため、ITエンジニア求人でもサービス企画や要件定義から担当できる人材を求めている企業も増えているなという印象があります。
要件定義や基本設計は、プロジェクトの成否を左右すると言われるほどでやりがいも大きい工程です。この記事では基本事項だけお伝えしましたが、もっと奥が深いので興味を持った方はぜひ調べてみてください。
「paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。
詳しくはこちら
そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。詳しくはこちら
