システム開発における工程


システム開発の工程や流れ

システム開発の工程


工程や流れを知ろう

システム開発における工程

以前のコラムでシステム開発とは、についてお話を致しました。簡単に言えば「仕組みを作ること」を指します。 今回のコラムでは実際にシステム開発を実施するときの工程や開発手法についてお話をしたいと思います。まず、システム開発の現場では、当たり前のように専門用語や略語が使われるため、その言葉の意味を理解していないと業務に支障が出ます。 業務を円滑に進めるには、システム開発の工程で用いられる最低限の略語は理解しておく必要があるでしょう。 システム開発の工程で使う専門用語と略語とその意味についてまとめました。

    システム開発

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

  • 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、なぜ、を繰り返しながら、本当に求めていることは具体的に何なのかを探る必要があります。面談相手は初回フェーズは経営トップも交えた方が良いでしょう。実現する業務に左右されますが、要件分析だけで1か月以上かかったこともあります。

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


システム開発 要件定義書

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

  • お客様のニーズを聞き出す

  • お客様のニーズを細分化する

  • お客様のニーズを要件定義書として作成する

  • 成果物は要件定義書、ビジネス企画書とIT化関連図 等

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

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

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

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

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

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

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

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

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

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

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

    • お客様の業界動向とビジネス企画に関する項目

    • 現状の課題と解決策

    • システムに関する事項

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

    • 機能要件に関する事項

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

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

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

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

    中国オフショア開発を利用してdx ソフトウェア開発、ウォーターフォール モデル,アジャイル開発,杭州,ai エンジニア