システム開発工程とは、ソフトウェアやアプリケーションを開発するためのプロセス全体のことを指します。このプロセスは概略して、要件定義、設計、開発、テスト、導入の順序で進められます。まず、要件定義では顧客の要求やニーズをヒアリングし、システムがどのような機能や仕様を満たす必要があるかを明確にします。次に設計では、要件定義に基づいてシステムの構造や機能、データベースの設計などを行います。その後、開発ではプログラミング言語を用いて実際にシステムを作成し、テストでは作成したシステムが要求仕様を満たしているかを検証します。最後に導入では、顧客にシステムを納品し、運用開始に向けた支援を行います。システム開発工程を理解することで、プロジェクトの進捗管理や問題の特定、改善が行いやすくなります。

システム開発工程での専門用語や略語

• RD＝Requirement Definition＝要件定義

要件定義とは、システム開発の最上流に位置する工程であり、ユーザーのシステムに対するニーズを明確にし、それを実現するために必要な機能をまとめて資料化し、ユーザーと合意形成を図る作業のことです。

• BD=Basic Design＝基本設計

基本設計とは、システム全体を機能単位に分割し、それぞれの機能の内容や機能同士のつながりなどを決める作業のことです。

• ED＝External Design＝外部設計

外部設計とは、IT会社によっては基本設計と同じ意味でつかわれることもありますが、ユーザーから見える部分の仕様、例えば画面や帳票などを決定したり、ユーザインターフェイスデザインを設計したりと、ユーザーに向けた仕様を設計することです。また、この段階で下流工程も含めた費用見積もりを試算する場合もあります。

• FD＝Function Design＝機能設計>

機能設計とは、システムの機能ごとに仕様を定義する工程のことで、IT会社によっては外部設計や内部設計の一部として位置づけられます。

• ID＝Internai Design＝内部設計

内部設計とは、詳細設計に近いもので、システム内部の動作や機能、データベースとの接続処理方法など、ユーザーから見えにくい部分の設計をおこなうことです。

• DD＝Detail Design＝詳細設計

詳細設計とは、システム開発工程において、プログラム実装の前に、システムの内部構成を細かく決めることです。

• PD/PS＝Program Design/Program Structure Design＝プログラム設計

プログラム設計とは、機能の実装の直前に各プログラムの動作などを詳細に決めることです。

• PG＝Programing＝プログラミング

プログラミングとは、コンピューターが理解できる言語を用い、実現したい機能を開発することです。

• CD＝Coding＝コーディング

コーディングとは、システムを動かすためのプログラムを書いたり、ユーザーから見える文字や画像をコードで入力したりすることです。

• UT＝Unit Test＝単体テスト

単体テストとは、システムを構成する個々の機能が正しく作動しているか確認することです。

• IT＝Integration Test＝結合テスト

結合テストとは、システムの中で単体では作動するようになった要素をそれぞれ組み合わせたときに、正常に作動するか確認することです。

• PT＝Product Test＝総合テスト

総合テストとは、構築したシステムが全体で必要な機能を全て満たしているか確認することです。

• OT＝Operations Test＝運用テスト

運用テストとは、システム開発におけるテストのうち最後におこなわれるものであり、本番稼働同様に顧客が操作し動作結果を確認するものです。

システム開発
システム開発工程は、ソフトウェアやアプリケーションを開発するために実施される一連のプロセスです。この工程は、要件定義、設計、開発、テスト、導入という一連のステップで構成されています。
最初のステップは要件定義です。この段階では、顧客や利害関係者とのコミュニケーションを重視し、システムがどのような機能や要件を満たす必要があるかを明確にします。要件定義が不十分または曖昧な場合、後の工程で問題が生じることがあります。
次に設計フェーズでは、要件定義で得られた情報をもとに、システムのアーキテクチャや機能、データベース設計などの設計を行います。この段階でシステムの全体像や細部にわたる設計を行うことが重要です。
その後の開発フェーズでは、プログラミング言語を用いて実際にシステムを構築します。設計で定義された仕様に基づいて、コードを記述し、システムの機能を実現していきます。
テストフェーズでは、開発されたシステムが要求された仕様を満たしているかを検証します。機能テストやパフォーマンステストなど、様々なテスト手法を用いてシステムの品質を確認します。
最後に導入フェーズでは、顧客にシステムを納品し、運用開始に向けた支援を行います。顧客がシステムを効果的に活用できるよう、トレーニングやサポートを提供します。
これらの工程を理解し、適切に実施することが、高品質なシステム開発を実現するために重要です。

要件定義の詳細

要件定義の詳細について以下に解説します。
要件定義はシステム開発プロジェクトの最初のステップであり、成功の鍵となります。この段階では、顧客とのコミュニケーションを重視し、以下のような活動が行われます。
まず、顧客とのヒアリングを通じて、システムがどのような機能を持ち、どのような課題を解決する必要があるかを理解します。次に、要件定義書を作成し、顧客と共有・確認を行います。要件定義書にはユーザーがどのようにシステムを利用するかや、システムが持つべき機能や性能などが明確に示されます。
この段階で顧客とのコミュニケーションを密にし、正確な要件定義を行うことが重要です。なぜなら、要件が不明確であると後の工程で仕様変更が発生しやすくなり、プロジェクトの進行や品質に影響を及ぼすからです。要件定義が完了すると、それを基に設計や開発が進められることになります。




要件定義RDは実際にお客様に出向き打合せ及び現場での業務視察を通じて明確にしていきます。そして基本設計BDにはビジネスモデルも含まれて設計するケースもありますが、上流工程の中でも最重要工程になります。過去の経験からコミュニケーション能力や業務分析力が問われる工程になります。類似の業務経験が豊富な方が良いですが、事例などを踏まえてお客様の要求を引き出すことが重要です。why、なぜ、を繰り返しながら、本当に求めていることは具体的に何なのかを探る必要があります。面談相手は初回フェーズは経営トップも交えた方が良いでしょう。実現する業務に左右されますが、要件分析だけで１か月以上かかったこともあります。

また上図にありますように、大きく分類して設計、製造、テストの３つ、細かくプロセスを分けると１３プロセスになります。案件の規模や状況によりどの工程からスタートするかが変わりますし、パッケージのカスタマイズのような作業ですと、いきなりプログラミングから入るケースもあります。またお客様にも常にせつめいしている事項として、設計と製造とテストの割合については、一般の方で知見の無い方は、お客様の目線で、簡単なプログラムの場合であれば設計やテストの工数を見落としているケースも多いですから理解してもらうためにも設計の重要性とテストの重要性を訴求することが多いです。プログラマーが注意すればバグは出ないだろう、と安易な考え方の方は少なくありません。個人事業主で作業支援をされる方などが最近急激に増えていますが、簡単に自宅の冷蔵庫を買い替えるのとは違って、ある程度の規模の大きなシステム開発では、既存プログラムの分析やプログラム一行一行の確認、そして既存仕様書の分析、または既存仕様書も無いケースなどもありますが、繊細な注意力が無ければ、一つの機能追加によって目に見えない中身の構造がぐちゃぐちゃになってしまうこともあります。




システム開発 要件定義書

システム開発工程 実際の要件定義段階で明確にすること

• お客様のニーズを聞き出す
• お客様のニーズを細分化する
• お客様のニーズを要件定義書として作成する
• 成果物は要件定義書、ビジネス企画書とIT化関連図 等

まずはお客様のニーズをしっかりと漏れなくヒアリングします。ヒアリング相手も対象者は多岐に渡るケースもあります。また、単にどんなニーズを満たしたいかだけでなく、具体的にどのようにニーズを満たしていけば良いのかという話を、業務単位、作業単位、ビジネス単位でひとつひとつしていきます。そして打合せのポイントは顧客のニーズを5W2Hによって文章に表していく事をお勧めします。できれば文書だけでなくイメージ図も工夫して表すことによって共通認識度が深まります。つまり、「なぜそのシステムが必要なのか」「誰が使うのか」「どこで使うのか」「いつ使うのか」「どのような機能を持たせるか」「どのくらいの頻度で使うのか」「社長は何をしたいのか」を明確にしてきます。そうすることで、顧客のニーズを漏れなく汲み取ることができますし、要件定義書として提出することによってお客様も実現に向けてモチベーションが高まりますのでメリットがあります。またお客様へのヒアリング実施は、こちらから積極的に質問をすることが大切です。なぜなら、お客様はITやシステム開発、ソフトウエア開発に関しては知識知見がないことが多いため、何を伝えて良いのかわからないことの方が大半です。こちらからお客様が抱えているであろう悩みを言語化することで、お客様も自分自身の伝えたいことを伝えやすくなります。「お客様の言いたいこと、やりたいことはこういうことだろう」という仮説を会話の中に取り入れながら質問をしていく事によって、ヒアリングの精度が高まります。あくまでもこちらサイドの一方的、専門用語や略語を使わない言葉遣いが求められます。それには豊富な経験と密度の高いコミュニケーションスキルが必要だと言えます。

またお客様のニーズを聞き出したら、それを持ち帰り内部で細分化します。お客様のニーズを知見知識、更には業界動向など様々な角度から分析して課題や問題点をあぶり出し、それに対しての解決策を内部検討しながら練ることが必要です。また、実現可能な満たせるニーズと実現不可能な満たせないニーズの仕分けもこの段階で行います。小生の持論はできないものは無い！という持論がありますが、費用対効果や技術動向を踏まえて、お客様の要求にこたえない方が良いものを洗い出すこともお客様にとっては喜ばれます。そして様々なニーズの実現には優先順位をつけるべきです。例えば、必須条件、希望条件、納期、という風にカテゴライズします。 そして要件定義書の次章として、それらを文章化、データ化して、お客様やシステム開発プロジェクトチームのスタッフと共有できるようにしましょう。

システム開発工程 要件定義書の作成方法

システム開発するもの、しないもの、業務、システム開発に必要なもの、必要でないもの、実現するものと必要なものに対して、具体的に実現する方法などが固まったら、それを要件定義書に仕上げます。要件定義書は、お客様や社内システム開発プロジェクトチームの技術者やスタッフも確認する為、誰が見ても理解できるようなものにしなければなりません。また、誰が見ても同じように解釈できる内容にする必要がある為、文書力、表現力、言葉遣いなど注意が必要です。質の高い要件定義書を作成するコツは、要点を前半で、細かい情報や補足は後半へ、そして必要な情報は全て記載することを推奨します。理由は要件定義書に書かれていないことは、他の誰にも一切伝わらないし、実現しないと認識されても当然ですから。要件定義書の完成度により、システム開発の成否が決まると言っても過言ではありませんので、しっかりと妥協のないように作成する必要があります。このようなことから要件定義書作成には余裕をもって数か月欲しいところです。

システム開発工程 要件定義書作成に必要なスキル

• お客様のニーズを引き出すコミュニケーションスキル

お客様といっても、打合せするシーンとして参加者も立場の異なる方が参加します。従って相手の立場を尊重しながら誘導していくコミュニケーション能力が必要になります。

• スケジュールとリスク管理のスキル

組織別にヒアリングする場合など、お客様とのアポイント及びヒアリングする順番などスケジュールを立案してお客様との打合せを効率的にしていく必要があります。また各打合せ時には事前に打ち合わせ内容を想定した準備が必要です。相手が話をしていただけるような具体的な資料などもあったほうが良いです。

• 実現可能なシステムの設計を把握するスキル

要件定義の段階では、お客様も期待を含めています。それによりなんでもかんでも実現できるような打合せにならないように発言には注意しましょう。できればその場で何が実現できて、何が実現できないかを判断できればよいのですが、そうでなくても宿題として持ち帰り、次の日には議事録として回答するぐらいのスピード感をもって対応します。なぜなら、要件定義の段階で実現できると判断したことが、開発の段階になって実現できないと判明した場合、システム開発プロジェクトチームの技術者やスタッフが困るからです。そのため、要件定義を担当する人材には、ある程度開発に関する知識を持っている必要があります。

• 要件をドキュメントに落とし込むスキル

前述したように文書力、表現力、もれなく成果物として書き込むことが必要になります。誰が読んでも内容を理解できるような要件定義書を作成できるスキルを身につけることも、プログラムを開発することと同様に一行一行が大切です。

システム開発工程 要件定義書に明記すること

• お客様の業界動向とビジネス企画に関する項目
• 現状の課題と解決策
• システムに関する事項

お客様がどのようなシステムを導入予定なのか説明するためのものです。例えば、システムの概要や、導入の目的、導入後の業務フローを記載します。もちろん課題解決策と連携していなければなりません。

• 機能要件に関する事項

機能要件に関する項目では、システムの実装によって何ができるようになるのかを記載します。具体的には、システムの種類・構造や、処理する内容です。

• 非機能要件に関する事項

非機能要件とは、お客様が求めるニーズのヒアリング後にシステムではなくシステム機能以外で実現できる要件のことです。例えば、組織変更や業務そのものの流れの変更など。それとシステムの性能や効率性、セキュリティや保守・運用サービスなどについても非機能要件として扱うことがあります。ハードウエアや利用ツールに左右されるものについては責任分界点として明確にします。こちらはお客様へのヒアリングの段階で明確にしなければなりません。




要件定義のポイント

要件定義のポイントについて前述しましたがもう一度まとめとして詳しく解説します。要件定義を行う際には、以下のポイントに注意することが重要です。
まず第一に、顧客とのコミュニケーションを重視しましょう。要件定義では、顧客のニーズや要求を正確に把握することが不可欠です。それには、ヒアリングやワークショップなど積極的なコミュニケーション手段を活用し、顧客との意思疎通を図ることが大切です。
次に、要件定義書の作成においては、明確で一貫した情報を記述しましょう。要件定義書は後の工程での指針となるため、正確かつ矛盾のない情報が必要です。また、顧客と要件定義書を共有し、確認・修正をすることで、顧客との間での誤解や不足がないかを確認することも肝要です。
さらに、変更管理を適切に行いましょう。プロジェクトが進むにつれて要件が変わることは珍しくありません。しかし、変更が無秩序に行われると品質やスケジュールに影響を及ぼす可能性があります。そのため、要件定義後も適切な手続きと共に変更が行えるようにしておくことが求められます。
最後に、専門家やステークホルダーとの協力を得ましょう。要件定義には多くの関係者が関わるため、専門家や関係部署と協力して行うことで、より正確で包括的な要件定義を目指すことができます。要件定義のポイントを押さえつつ、的確な要件定義を実現しましょう。




システム設計のステップ

システム設計のステップには、概要設計、詳細設計、アーキテクチャ設計の3つの重要なステップがあります。まず、概要設計ではシステム全体の機能やモジュールの関係性を把握し、大まかな設計を行います。次に詳細設計では、概要設計で定義された機能やモジュールを詳細に設計し、具体的な処理の流れやデータ構造を定義します。この段階では、プログラム言語やデータベースの選択も行われます。最後にアーキテクチャ設計では、システム全体のアーキテクチャやデータベースの設計、ネットワーク構成などを決定し、システム全体の設計の完成度を高めます。各ステップは、前のステップで作成された成果物を元に進められ、詳細な設計が進むにつれて、システムの具体的な姿が形成されていきます。システム設計はシステム開発の中で最も重要な段階の一つであり、様々な要素を考慮しながら設計を進めることが求められます。




外部設計と内部設計の違い

外部設計と内部設計の違い外部設計と内部設計は、システム設計の中で重要な役割を果たす2つの概念です。外部設計は、システムのユーザーインターフェースや機能の仕様など、ユーザーから見える部分を設計する段階です。つまり、システムを利用するユーザーが直接触れる部分や操作する部分を設計することが外部設計の主な役割です。一方、内部設計は、外部からは見えないがシステム全体の動作や処理を支える部分を設計する段階です。これには、データの流れや処理の仕組み、モジュール間の関係などが含まれます。外部設計と内部設計は、それぞれプロジェクトの異なる側面を扱うため、設計者はユーザー視点とシステムの内部仕組みの両方を考慮する必要があります。また、外部設計の変更が内部設計に影響を与えることがあるため、設計段階でのコミュニケーションや調整が重要となります。




プログラミング工程

プログラミング工程とは、システム開発工程の中でも、実際にプログラミング言語を使用してシステムの機能を実装する段階を指します。プログラミング工程では、設計段階で作成された仕様や設計書に基づいて、プログラマーが実際のコードを書いていきます。この段階では、プログラミング言語の選定や開発環境の構築が行われ、複数のプログラマーが協力して大規模なシステムを開発する場合には、プログラムの構造やモジュールの設計なども重要なポイントとなります。プログラミング工程においては、プログラマーが設計に基づいて効率的にコーディングを行うことが求められます。また、コーディング規約や品質基準を遵守し、保守性や可読性の高いコードを書くことも重要です。プログラミング工程におけるテストも重要なステップであり、単体テストや結合テスト、システムテストなどを適切に実施し、品質の担保を行います。プログラミング工程では、柔軟性や拡張性を考慮した設計や、効率的なアルゴリズムの選定が求められるため、開発者の経験やスキルが重要な要素となります。




コード品質を保つ方法

コード品質を保つ方法




テストフェーズの攻略

テストフェーズの攻略についてシステム開発工程におけるテストフェーズは、開発したシステムが正しく動作し、要件を満たしているかを確認する重要な段階です。テストフェーズでは、さまざまなテスト手法を駆使してシステムを徹底的に検証し、品質を向上させることが求められます。まずは、ユニットテストと呼ばれるプログラムの個々の部分に対するテストを行い、それぞれの機能が正しく動作しているかを確認します。次に結合テストでは、個々のユニットが連携して正しく機能するかを確認し、システム全体の動作を確認します。さらに、システムテストではユーザーがシステムを操作する状況を模擬し、実際の運用環境に近い状況でテストを行います。最後に受け入れテストでは、顧客が実際にシステムを使用し、要求仕様を満たしているかを確認します。テストフェーズでは、これらのテストを徹底的に実施することで、バグや不具合を早期に発見し、品質の向上につなげることが重要です。




効率的なテスト手法

効率的なテスト手法について、以下のような段落で解説します。
段落1:
効率的なテスト手法の1つには、ユニットテストがあります。ユニットテストはプログラムの個々の機能やメソッドなど、最小単位のコードに対して行われるテストです。開発者自身が書いたテストコードによって、各機能が期待どおりに動作しているかを確認します。ユニットテストは開発初期から継続的に実施することで、バグを早期に発見しやすくなるという利点があります。
段落2:
また、結合テストも効率的なテスト手法の1つです。結合テストでは、個々のユニットが連携して正しく機能するかを確認し、システム全体の動作を検証します。ユニットテストと同様に継続的に結合テストを行うことで、機能間の不整合や互いの依存関係による不具合を早めに発見することができます。
段落3:
さらに、自動化テストも効率的な手法の一つです。自動化テストは、テストケースを自動的に実行することで、繰り返し行うテスト作業を効率化します。特に繰り返し実施することが難しい負荷テストやストレステストなどは自動化が有効です。自動化テストを導入することで、テストの作業量を大幅に削減し、品質向上につなげることができます。




導入と運用のチェックリスト

導入段階では、システムがスムーズに稼働するための準備を整えます。これにはシステムの設置や設定、ユーザー教育などが含まれます。運用段階では、定期的なバックアップとシステムのパフォーマンスモニタリング、セキュリティ対策の実施が欠かせません。このチェックリストを頼りに、導入と運用を着実に進めていきましょう。




運用チューニングのポイント

運用チューニングのポイントは、定期的なパフォーマンスモニタリングとログの分析です。システムの負荷状況やボトルネックを特定し、適切な最適化を行うことが重要です。
また、セキュリティの強化も見逃せません。脆弱性のチェックやパッチ適用など、常に最新のセキュリティ対策を実施しましょう。




まとめ

システム開発の工程とは、ソフトウェアやアプリケーションを開発するためのプロセス全体のことを指します。このプロセスは要件定義、設計、開発、テスト、導入の順序で進行します。要件定義では、顧客の要求やニーズを把握し、システムがどのような機能や仕様を満たす必要があるかを明確にします。設計では、要件定義に基づいてシステムの構造や機能、データベースの設計などを策定します。開発では、プログラミング言語を用いてシステムを実際に作成し、テストでは要求仕様を満たしているかを検証します。最後に導入では、顧客にシステムを納品し、運用開始に向けたサポートを提供します。システム開発工程を理解することで、プロジェクトの進捗や問題の特定、改善が行いやすくなります。工程ごとの適切な管理と連携が、円滑なプロジェクト進行につながります。



いかがでしたでしょうか？
いかがでしたでしょうか？システム開発における工程の専門用語や略語、そして要件定義の進め方、要件定義書の記載内容、要件定義に必要なスキルについてお話しをさせて頂きました。前述したように要件定義はお客様の頭の中にある要望、要求を可視化していくことになりますので難易度は高いです。システム開発を成功させるためにも、しっかりとやらなければなりません。担当者の責任は重大ですが、要件定義書がしっかりしていれば、お客様と開発メンバー全体のバイブルとなり、それだけにシステム開発が成功した時の仕事の達成感は大きいと思います。現実的にお客様に時間を頂き打合せをしていくことになりますので、お客様の責任者からも関係ステークホルダに周知してもらったり、事前に現行業務のドキュメントや伝票なども準備してもらう必要があります。そのような意味では要件定義者は営業と一緒に行動することも良くあります。これはIT会社によって様々な体制があるとおもいますが、要件定義者にはお客様側も心を開く必要があると思いますし、要件定義者はシステムエンジニアとイコールの体制をとっているケースも多くあります。システム開発工程におけるウォーターフォール型モデルとしてのプロセスで、まずは要件定義について今回のコラムとして述べましたが、この工程の通りプロセスが流れていくわけではありませんが、お客様を成功に導くための手法として知見があれば、あとは実践して具体的に誘導していくのみになりますので、学びがあれば幸いです。次回のコラムではアジャイル開発とは、そして費用の算出基準やそのほかのプロセスに関しても時代の流行に合わせて発信できればと考えておりますので、またの機会をお楽しみに。最後まで読んでいただきありがとうございました。
• Go back