「システムの開発工程の成果物は？」
「ＳＥとＰＧの役割の違いは？」システム開発の全体的な流れを理解できれば、次工程をイメージできて、理想的なスケジュールで動くことができます。
そして、各工程の成果物と役割、次工程へのつなぎ方のポイントを押さえれば、生産性が上がり、トラブルを未然に防ぐことも可能です。当ページでは、失敗を経験したシステム開発経験者の実体験をもとに各工程での成果物とポイントを解説します。
参考書には載っていない実務での成功・失敗事例をもとに、未経験でもイメージできるようにご説明していきます。さらに、それぞれのSE/PGの役割も記載しておりますので、上流工程でのSE業務についても把握できますよ。
PGからSEへのキャリアステップも目指して、システム開発全体の流れを抑えましょう！あなたの経験をより濃いものにするために予習を行い、実践で力をつけてください。
そのためにこの記事がお役に立てば幸いです。
システム開発の手法を理解しよう
システム開発は、「開発工程」に沿って仕事を進めていきます。
「開発工程」とは、開発を進めるうえでの、いくつかの開発プロセスの集まりを意味しています。
そして、「開発工程」にはいくつかのモデルがあります。
ここでは現在主要となっている２つのモデルを紹介していきます。
ウォーターフォール型とは？
ウオーターフォールモデルは、システム開発における各工程を順番に進めていく開発手法です。
原則として前工程への後戻りはしません。
高いところから水を流すように、工程を上流から下流へ進めていくことから「ウォーターフォールモデル」と呼ばれています。
世の中のほとんどのシステムがこの方法で開発されており、もっとも主流の開発モデルといえます。
このモデルのメリットは対象となるシステムを段階的に詳細化していくため各工程の工数の見積や資源の配分などを行いやすくなります。
よって大規模なシステム開発に向いています。
デメリットはシステム開発の後半にならないとお客様がシステムを確認することができないという点です。
そのため、お客様の要望と異なる部分が発生した場合に、それを修正するために前の工程へ後戻りしなければならず生産性が低くなるという欠点があります。
アジャイル開発とは？
開発のスピードを優先した開発手法です。
前述したウォーターフォールモデルは、設計、開発、テストと順番通りに進めていきますが、アジャイル開発は設計や開発やテストの中身が他手法とも大きく異なる開発手法です。
ポイントとしては、設計に日数をかけず、すぐに開発に取り掛かり、実際に動くプログラムを重要視していきます。
アウトプットされる画面や機能を早い段階でお客様に確認いただくことで、認識のずれや機能の誤りを早期に発見できることがメリットです。
近年、開発ツールの品質が良くなり、よりビジュアルな本番に近いものを早期に開発できるようになってきました。
今後も活用されていくケースは増えていくと想定できます。
システム開発の各工程について詳しく知ろう
要件定義
要件定義とはお客様がシステム化したい内容をヒアリングして、実装すべき機能や満たすべき性能などを明確にしていく工程です。
お客様とシステム開発会社が双方が合意した内容を「要件定義書」にまとめます。
この工程では「何が必要なのか」という要件を定義することを目的とし、それを「どのように設計・実装すべきか」は次の工程で検討します。
また、要件定義の手法は決まったものはなく、システム開発会社やシステムの特性によってさまざまです。
成果物
システム化の目的・全体の方針・機能要件・非機能要件（機能面以外のハード性能や信頼性、拡張性、運用性、セキュリティ面など）をまとめたものです。
これが「要件定義書」となります。
SE・PGの役割
この工程においてPG職の業務はありません。
営業職の方が開発案件を持ってきた場合、営業職＋SE職にてお客様と打ち合わせをすることが多いです。
また、ある程度会議の回数を積むと、SE職のみで業務を進めることもあります。
SE職は上述した成果物を作成するためにお客様の要望を伺い、システムでの実装可能性と合わせて要件定義書にまとめていくことが必要です。
（よく上流工程といわれる部分はここからとなります。経験が必要な部分も多く、PG職の次のSTEPとして要件定義というスキルが求められます。）
次の工程への移り方
本工程でのポイントは、お客様の要望をすべて聞きすぎないことです。
お客様の要望は大小に関わらず出てきます。
そこで、システムでの実現性を加味しつつ、期間や予算、運用面を考慮して最適なものを提案していくことが求められます。
特に、後工程に進むと機能の内容がさらに詳細化していくため、要望が増えていく傾向にあります。
（お客様がシステム開発に長けた方の場合、本工程で要望を出し切ってくれるケースはありますが、稀です。）
基本的には、最新の技術や製品、サービスを使うことになるため、お客様の要望を上回る機能を提供できる部分があります。
その反面、生産性が悪く、期間を必要とするようなものはしっかりとした説明の元、機能をそぎ落としていくことが良いでしょう。
外部設計
外部設計とは、要件定義で決まった内容をもとに画面や帳票などのユーザーインターフェースを設計する工程です。
「基本設計」や「概要設計」と呼ばれることもあります。
この工程では利用者から見てシステムがどのように振る舞うべきか、操作する画面のレイアウトや操作方法、帳票類の書式、データベースの構造などを決めていきます。
また、外部システムとのやり取りをするインターフェイスの内容も設計します。
成果物
「画面設計」、「帳票設計」、「データベース設計」、「外部I/F設計」などがあげられます。
SE・PGの役割
この工程においてPG職の業務はありません。
設計フェーズとなりますので、SE職にてデータ形式や連携方式、ユーザインターフェースの設計を行っていきます。
次の工程への移り方
外部システムへの連携（In/Out）やユーザインターフェースをもとにデータの整合性や連携方式の検討を行います。
データベースの設計も行いますので、データの持ち方と連携方式を十分に検討することが重要です。
外部システムとはデータ形式が異なることがあり得ますので、入口から出口までの検討をしっかり行うことが重要です。
よく制約事項として、連携タイミングやデータ形式に影響が出ることがありますので、全体の流れを見ながら設計をしていきます。
外部の取引先とも調整事項が発生するケースが多いので、合理性や効率化を考えながら進めることが必要です。
内部設計
内部設計では、外部設計の内容をもとに開発するシステムを大まかな機能ごとに分割し、それらをつなぐインタフェースの仕様などを設計します。
内部設計は「システム構造設計」「詳細設計」とも呼ばれます。
なお、要件定義や外部設計とは違い、お客様や外部システム開発担当との仕様調整を行うことはあまりありません。
成果物
「内部仕様書」、「機能設計書」、「ファイル設計」が成果物として作成することが多いです。
外部設計より詳細な内部の連携やファイル設計、データ連携を定義します。
機能ごとに分割し、機能の動きを定義します。
SE・PGの役割
この工程においてPG職の業務はありませんが、PGから次のSTEPとして本工程を行うことは多いです。
開発業務の上位業務にあたるので、経験から対応がしやすいためです。
プログラミングを検討しながら設計をしていきます。
次の工程への移り方
実際の１画面単位の機能をお客様と確認しながら進めていく工程です。
ある程度一般的な機能での設定ができますが、お客様の細かな要望が出てくる場面でもあります。
プログラミング言語の特性を理解しつつ、工数を考えながら、機能要件をまとめていくことが重要です。
開発実施
内部設計をもとにプログラム言語を用いてプログラム(モジュール)の作成を行います。
また、内部設計とプログラミングの間にプログラム設計を書く場合もあります。
プログラミング工程では「コーディング規約」に沿ってプログラムを作成します。
コーディング規約とは、ソースコードを書くにあたって、共通の決まりごとをまとめたドキュメントです。
関数や変数の名前の付け方、コメントの書き方などのお作法が規定されています。
なお、ソースコード(source code)とはプログラミング言語の言語仕様にそって書かれたテキストのことです。
成果物
「プログラム設計書」、「プログラム」が本工程の成果物にあたります。
プログラム設計書は、プログラミング言語を日本語で記述したようなイメージとなります。
SE・PGの役割
本工程がPG職の業務となります。
上流工程で設計された設計書や仕様書をもとにプログラムを作成していきます。
次の工程への移り方
きれいなコードわかりやすいコードを書きたいと考えますが、重要なことは誰が見ても理解がしやすいことです。
見やすさや統一感のある関数の使い方を心がけると、今後の修正も視野にいれるとよいプログラムになります。
経験も必要となりますが、高度なことをやるぐらいなら、見やすさを心がけるとよいプログラムになるでしょう。
その一環として、規約を守ることが見やすさに繋がります。
テスト
大きく４つの工程に分かれており、単体テスト、結合テスト、システムテスト、運用テストがあります。
単体テストではソフトウェアを構成する最小単位である関数やメソッドに対して、設計書で要求された機能を満たしているかどうかを検証します。
単体テストのテスト対象は個別のプログラム（ソースコード）そのものとなります。
ですので、命令文や条件判定を行っている「if-else文」などの各コードが実行されるようにテストケースを考えます。
結合テストは、単体テストで動作が確認されたモジュールを結合させてモジュール間のインターフェイスが合っているか、結合した場合に正しく動作するかを確認するテストです。
システムテストはシステムが全体として要求された機能や性能を満たしているかどうかを検証します。
運用テストは実際の業務の流れに沿って利用してみて問題なく動作するかを検証します。
また、お客様である業務担当者がシステムの操作や運用に慣れるための工程でもあり、本番稼動前の最後のテストとなります。
成果物
「テスト結果」、「性能評価」、「品質評価」が成果物として多いです。
各テスト工程の成果物は必要ですが、規模が大きくなるとそれぞれのバグの就職状況や負荷テストでの性能評価などを求められるケースもあります。
SE・PGの役割
PG職が主の工程となります。
テストを通して設計の問題や調整が必要になることも多く、SE職との連携も発生します。
各テスト工程ともしっかりやりきることが重要です。
次の工程への移り方
テスト計画を立てながら、発生したバグ調査や修正業務との並行業務となります。
このあたりから作業がピークとなってくるケースが多く、計画を遵守しながら、しっかり修正対応を行っていくことが必要です。
成功事例と失敗事例
ここからは、システム開発工程での成功事例と失敗事例をご紹介していきます。
各工程での成功事例と失敗事例
上流工程では、外部システムの仕様を把握して連携をしっかりとイメージすることが成功に繋がります。
失敗したケースというのは、外部システムの仕様を理解せずに自システムの仕様で作りこんでしまい、テスト工程に入ったときに修正が必要となることがありました。
また後半のテスト工程では、正常系、異常系、エラー系の３パターンをテストすることが成功に繋がります。
一般的には、正常、異常のテストパターンというものは実行しますが、エラーケースは省略しがちです。
しかし、エラーケースを省略すると本番でバグが見つかることがありました。
ネットワークが繋がらないなど、あまり発生頻度が少ないだろうテストというものは省略しがちなのですが、本番導入後は何年も利用しますので起こりえます。
本番障害がおこるケースはやはりテスト不足、未実施といったことが多いと感じております。
全体に対していえること
１つ１つの工程で手を抜くことなく、しっかりやりきることが経験上、とても重要です。
少し手をついた工程があると後工程に必ず影響して、苦労することが多いです。
また問題が潜在してしまうことあり、本番導入後に発生するケースもあります。
１分の確認で済んでいたかもしれない問題が本番で障害となってしますと、調査から始まり修正対応、敷いては障害報告書など業務を増やすことになりますので、各工程ともしっかり品質高く、やりきることが全体の工数を削減する意味でも効果的です。
システム開発のキャリア向上にむけて
ここからは、システム開発におけるキャリアを向上させる方法についてご紹介します。
上流工程に挑戦してみよう！
開発工程やテスト工程を行っていると、もっと上流工程で洗い出せた課題だったのではないか、この問題は解決できたのではないか、と気づくことがありますよね。
下流での経験があるからこそ、上流でどうするべきか、段々と見えてくるものが必ずあります。
システムの規模や期間にもよりますが、上流工程にチャレンジするタイミングはわかると思いますので、少し背伸びするぐらいで挑戦してみることが自身のスキルアップ・キャリアアップのために良いでしょう。
思い切って、会社自体を変えてみることも一つの手です。
一気に規模やスピード感が上がることも大きな経験の一つになりますよ。
ISOについて理解する
システム開発で品質を保証するためにISO9001などの国際標準規格を取得している企業は多くあります。
品質管理がしっかりしている・力を入れている企業に仕事を任せたいと思う発注先が多いことも否めません。
ただしその分、発注金額は高くなります。
品質とコストは反比例し、発注元の方針に依存するためです。
ISOの規格を取得するためには、開発会社にて規格を遵守するためのルール化、仕組化、またその後の運用管理（維持管理）も必要です。
その分、発注元は品質という安心感を買えるというわけです。
まとめ
ここまでお読みいただき、ありがとうございました。
この記事を読むことで、基本となる工程の進め方と成果物を確認していただけたでしょう。
経験を積んでいくと、より効率的で自身が管理しやすいやり方が見つかってきます。
また失敗もするでしょう。
システム開発は進めていけばいくほど、奥の深いものです。
優秀なプログラマーであれば、数行でかけるコードも、初心者では数十行になることもあります。
様々なブログでコードが公開されていたりしますので、優秀な方のコードや考え方を学び、プログラミングを究めていくことも一つの道です。
また、部署間や会社間での調整や設計に興味があるようであれば、SE職に向いているかもしれません。
どちらに関しても経験則ですが、しっかり一度全工程を経験してみることが良いです。
一度、ベースの経験が身につくと、新しい言語や環境になったとしても、その経験が生き、効率よく習得ができます。
今後、さらにシステム開発環境の進化は進んでいき、多言語化や環境の改善、より良い開発ツールが出てくると思いますが、しっかりと一度身に付けたものは自分の武器となりますので、臆することなくチャレンジしていってください。
皆様がよりよいITエンジニアになることを心より祈っております。
コメント