「システム開発」と聞いて具体的にイメージできない方(がほとんどだと思いますが・・・)にはぜひ読んでほしいですので何回かに分けて説明していきたいと思います。
我々は「システムインテグレーション」「システム開発」を主な商いにしているプロですので、何回かに分けてプロ視点でお伝えしていきたいと思います。
「システム開発」という言葉、主に企業活動の中で出てくる用語であり一般の方々には馴染みもないですし、詳しく知らない方が多いのではないでしょうか。
スマートフォンにインストールされているアプリ、オンラインショッピングなど日常生活で使うことが多くなっていますが、開発の裏側までは知り得ないですし、あまり興味ないことと容易に想像できます(笑
ただ、企業の情報システム部の方やIT関連も任されている担当者の方には、「システム開発」のことを少しでも知ってもらえたらと思っています。
いざ、相談・発注・実施となったときにある程度知識をもっておくことで、ベンダー(発注先)の選定だったり、一緒に進めるうえでプラスに働くこと間違いないかと思います。
まずシステム開発の目的ですが、一般的には
ビジネスの目標達成や課題を解決をするため
だと考えています。(これだけではないケースもありますが)
システムを作ることが目的にならないようシステム導入の目的をしっかり定め、関係者の間で共通認識(ゴール)をもったうえで推進すべきかと思います。
システム開発の全工程
さて、前置きが長くなってしまいました。
今回はシステム開発における工程をざっくりとお伝えしようと思います。
詳細は別途ブログを書いていく予定ですのでそちらをご覧いただければと思います。
システム開発を進めるにあたり、主に以下の工程があります。
工程の呼び名はベンダーによって異なったりもします。
・要件定義
・外部設計(基本設計)
・内部設計(詳細設計)
・プログラミング
・単体テスト
・結合テスト
・総合テスト
・受入テスト
・運用・保守
工程には上記の他に
運用設計・移行
などもありますが今回は割愛させていただきます。
要件定義~システムを開発する目的や開発の範囲を明確に定義する
お客様の要求、およびリソース(予算、期間等)を踏まえて以下を決定していきます。
・業務的な要件
・機能的な要件(何を作るか)
・品質特性に関する要件
・外部システムとのデータ連携
リリースや運用までの開発計画も本工程で立案します。
これで概ね何をどこまで開発するのかが決まるので、開発に必要な予算が精度高く算出できます。
少しでもわかりやすくするために「超ざっくり」に、カレーライスを調理するケースで各工程を表現していこうと思います。とか言いつつ、料理のことはよくわからないので「超ざっくり」感じていただければと(汗
まず業務(ビジネス)要求が
売上をUPさせるために、若年層に好まれるカレーライスをつくりたい
だとします。
要件定義ではどんなカレーをつくれば要求を満たせるのかを考えていきます。
いろいろ検討した結果、
激辛で野菜たっぷりのカレーライスとそれに合うサラダをセットで提供する
ことを決めます。
予算も限りがあるので「豚肉ではなく鶏肉を使う」など、お金や時間軸も考えてものごとを決めていきます。
もっと知りたい方はこちらもお読みいただければと思います。
みなさんこんにちは。今回は、プロジェクトの成否がほぼ決まるといっても過言ではない「要件定義」という工程について、3回に分けてお伝えしようと思います。要件定義の前工程に要求定義という工程があったりもしますが、要求を整理して …
外部設計~ユーザーに関係する仕様を定義する
システムの外側の仕様を決めます。
わかりやすいところですと画面レイアウト/表示項目/ボタンなどユーザーに関わるところをどのように(機能を)作るかを決めていきます。
これもお客様と操作性や運用を踏まえて一緒に定義します。
カレーライスで例えると
盛り付け(見た目)、野菜の種類、ライスはコシヒカリを使う、辛さは10倍
などユーザーに大きくかかわるところを決めていきます。
詳しくはこちらをご覧ください。
さて今回は「プロが教える超ざっくりシステム開発」の外部設計編となります 外部設計って? 外部設計は一般的には「基本設計」と呼ぶことも多く、その呼称は多くベンダーによりけりです。この外部設計は、乱暴に一言で言うと「システム …
なお、この工程では「テスト計画」も立案します。
各テスト工程において「どのような環境下でどのような観点のテストをする」などの計画書を作成します。
本記事の趣旨とは少しだけ外れるので、今回は割愛させていただきます。
内部設計~システム内部のユーザーから見えにくいところを設計する
「外部設計」をもとにユーザーから見えない機能やデータの詳細定義など、どう作るかを決めていきます。
開発のルールや標準等、プログラマーが好き勝手作らないように、あるいは作りやすいような仕組みやルールも策定します。
これはお客様に考えていただく必要はなく、我々でいろいろな要素を踏まえて設計していきます。
カレーライスの例では
野菜の切り方、大きさ、火の通し具合、隠し味
など細かなところを考えていきます。
詳しくはこちらをご覧ください。
システム開発工程の内部設計工程でどんなことをしているのか、発注者が協力することはあるか、などを説明しています。
プログラミング~コンピューターへの指示を書く
プログラムを書きます。「実装」とか「製造」とも呼ばれたりしています。
プログラムはシステムが仕様(設計)通りに動くように、コンピューターに出す指示のことです。
プログラムを書くための言語は多くあり(英語とか日本語とかフランス語みたいな)、それら言語によって得手・不得手、特徴などがあります。
プログラマーやベンダーによっても得手・不得手があったりします。
さて、カレーライス・・・
野菜を切る、ご飯を炊く、カレーを煮込む、盛り付ける
ですね。まさに調理そのものです。
単体テスト~1つの機能単位でテストする
プログラミングした機能が単体で仕様通りに動くか検査します
この「単体」というのが分かり辛かったりします。たとえば、「ログイン画面」とかですね。この1画面だけ単体で検査します。
仕様通りに動かない場合はプログラムを修正して、再度検査します
カレー・・・
カレーライスを味見します。辛すぎないか?野菜は固くないか?盛り付けは想定通り?
サラダも味見してみます。うん、うまい!
など、出来上がったカレーライスをチェックします。
想定通りでなければまた作り直します。
ご飯の炊き具合が問題なければ、カレーだけを作り直したりします。
あ、サラダは省いてきましたが同様の工程を経てつくられてきます。
プログラミンと単体テストについて詳しくはこちらもご覧ください。
さて今回は「プロが教える超ざっくりシステム開発」のプログラミングと単体テスト編となります プログラミング工程では、これまでの工程で設計されてきたことを実現するための「プログラム」を作ります(記述します)。「プログラム」と …
結合テスト~機能を組み合わせてテストする
いろんな機能を連携してシステムが仕様通りか検査します。
たとえば、「ログイン画面」でログインが成功したら、メニュー画面が表示される、などですね。
機能単体で検査OKとなっても「他の機能と連動して動かない」なんてことはよくあることです。
こちらも仕様通りに動かない場合はプログラムを修正して、再度検査します。
さて、組み合わせということで(笑
カレーとサラダを一緒に食べてみます。
サラダだけ食べるとおいしいけど、激辛カレーにちょっと合わない
などがあれば、サラダのドレッシングを見直したりするなどして、カレーとサラダが合うように調理しなおします。
結合テストについて詳しくはこちらもご覧ください。
今回は「プロが教える超ざっくりシステム開発」の結合テスト編となります。 結合テストの「結合」って? 「結合」をWikipediaで調べると「2つ以上のものが結び合わさること」とあります。ここでの「もの」とはシステムでいう …
総合テスト~運用を想定してテストをする
誤解を招くことを恐れずに言うと、お客様の本番環境で本番データを使って、お客様の運用を想定した手順でシステムが仕様通りに動作するか検査します。
この検査を合格することで弊社から出荷(納品)となり、お客様の手に渡ります。
非機能テストと呼ばれるテストも実施しますが、少々難しいお話になりますので今回は割愛します。
この「非機能テスト」については、今後ブログで説明していきたいと思います。
ここでもカレーを例にすると・・・
お客様の調理場所と調理器具で、手順書通りにカレーライスとサラダをつくります
火力が弱かったり、室温の問題があり、すこし味が変わるかもしれません。
その場合は調理方法を少し変える必要がありますね。
総合テストについて詳しくはこちらもご覧ください。
さて今回は「プロが教える超ざっくりシステム開発」の総合テスト編となります。 総合テストって何やるの? 総合テストは、すべてのソフトウェア、ハードウェアなどを組み合わせて、要件定義工程で決めたことが利用者が利用する環境で実 …
受入テスト~自身が想定した通りのシステムなのかテストする
お客様自身で想定通りのシステムとなっているか、業務シナリオを通じて検証いただきます。
ここでOKとなれば、我々に検収をあげていただくことになります。
一方、カレーはと言うと
お客様自身にカレーライスとサラダを食していただきます
お客様が想定した味や見た目であれば、合格となります。
このフェーズであまりの味変や、要件定義と異なることは受け入れることはできませんが、多少の調整は行ったりもします。
受入テストについて詳しくはこちらもご覧ください。
さて今回は「プロが教える超ざっくりシステム開発」の受入テスト編となります。このシリーズにおいては、今回で最終回となります。 総合テストの前工程をまだご覧になっていない方はこちらをご覧ください。 受入テストって誰がやるの? …
運用・保守~「終わり」ではなく、ここからが本当の「スタート」
長い期間かけて開発しますが、ここからが本当のスタートですね。
お客様業務はもちろんのこと、システムも放置するのではなく運用・メンテナンスしていく必要があります。
カレーライスの例はちょっと無理があったかもしれませんが(汗)
最後はメニューに載せて、本当のお客様にカレーライスとサラダを提供することになります。
さいごに
システム開発において、主な工程と主な役割は以下のようになります。
◎が主担当で、〇が作業支援等の副担当となります。
工程 | ベンダー | お客様 | お客様タスク |
---|---|---|---|
要件定義 | ◎ | 〇 | ヒアリング対応、資料ご提供、要件定義書のレビュー等 |
外部設計 | ◎ | 〇 | 画面仕様書、帳票仕様書のレビュー等 |
内部設計 | ◎ | ||
プログラミング | ◎ | ||
単体テスト | ◎ | ||
結合テスト | ◎ | 〇 | マスタデータ等、テスト用データの提供等 |
総合テスト | ◎ | 〇 | 必要に応じ、本番環境や実機等のご提供 |
受入テスト | 〇 | ◎ | 想定通りにシステムが動作するか、業務が遂行できるか等の各種確認 |
運用・保守 | ◎ | 〇 |
ずらずらと長くなってしまいましたが、今後はもう少しイメージできるようブログを書いていこうと思います。
ちなみにシステム開発に必要な「工期」は短くても3か月、長くて1年、 大手企業の大規模システムだと数年がかることもあります。
幸せなことに仕事の行列ができていて、エンジニアがアサインできなければもっと時間が必要となります。
企画や発注の際はこの辺も頭に入れておくとよいと思います。
システム開発を成功させるために必要な要素をこちらで解説していますので興味があるようならご覧ください。
今回は、システムインテグレーションやシステム開発を生業にしている我々受注側が実際に実施している「プロジェクト管理」の概要について書いていきます。「受注側」と書いたのは、発注者側でもプロジェクト管理が必要なためです。発注者 …
このサイトは、「株式会社ベーシック」の「新潟事業所」が提供するサービスの一つです。我々は、東京に本社、新潟・関西に拠点を構え、主にお客様(企業)固有の業務システムやサービス基盤をオーダーメイドすることを得意としております …