事業内容
- DX推進/IoT開発事業
- AI/ROBOTICS開発事業
IT技術の発達に伴い、システムの導入や業務効率化を図る企業も多くなりました。当記事をご覧の方のなかには、現場の業務改善のために、システム開発を検討している方もいるでしょう。
そこで今回は、「システム開発とは、どのようなものなのか」について解説します。システム開発の概要が分からず悩んでいるという方は、参考にしていただけたらと思います。
システム開発とは、企業が抱える課題を解決するための「仕組み」を作ることです。
ウェブサイトを構築したり、プログラムを作成したりすることだけが「システム開発」ではありません。
どの企業にも、「新しい事業に参画したい」「既存の業務を効率化してコストを削減したい」といった、ビジネス上の目標や課題があります。
そうした課題を解決する「仕組み」を、コンピューターシステムを使って実現すること、それが「システム開発」です。
ウェブサイトやプログラムは、ビジネス上の課題を解決する「道具」にすぎません。ビジネスの課題を的確に抽出し、最適な「道具」を最小限のコストで作ること、それが「システム開発」です。
システム開発の目的は、ビジネス上の課題を解決することです。
企業によってさまざまな課題がありますが、システム開発では主に次のような課題を解決します。
◎ 新製品の開発、新規事業への参画
◎ 業務効率化によるコストダウン
◎ 顧客満足度の向上による競争力強化
◎ 業務継続性の維持
◎ 外部規制、法制度、コンプライアンスへの対応
◎ 市場の要請、業界団体からの要請への対応
◎ 経営の統廃合への対応
システム開発を行う前に、ご自身の組織が抱えるビジネス課題は何か、着地点はどこか、また優先すべき課題は何なのかをしっかりと考えたうえで、システムを開発することが重要です。
一口にシステム開発と言っても、それぞれ現状の課題や、目指すべきゴールが異なりますので、実現するまでの手法もさまざまです。どの手法でも、概ね「要件定義」「設計」「開発」「テスト」をしてから、「リリース」して実際に使ってもらう、という流れをとります。
ただ、コストおよび開発期間の制約や、システムの規模によって開発手法も異なります。さらには、開発を依頼する側の習熟度や経験などによっても、最適な開発手法は違ってきます。
そのため、依頼する側でもシステムの開発手法にはどんなものがあるのか、一通りは理解しておく必要があります。ここで主なシステム開発の手法をご紹介します。ご自身のシステム開発にはどの開発手法をとればよいのか、これを参考にしてください。
◎ ウォーターフォール
◎ アジャイル
◎ スパイラルモデル
◎ プロトタイピング
◎ DevOps
以下では、それぞれの開発手法について、簡単にご説明します。
「ウォーターフォール」(waterfall、滝)は、上流の「要件定義」工程から下流の「テスト」工程まで、滝の上から水が落ちていくかのごとく、順序に従って工程を進めていく開発手法です。
以前から採用されていた開発手法で、各工程で進捗管理をしっかり行いながら進んでいくため、スケジュール管理やコスト管理がやりやすく、比較的大規模なシステムでも効率的に開発を進められます。
反面、開発途中での仕様変更には弱いというデメリットがあります。
システムの仕様を上流工程で決定してしまうため、途中の開発工程やテスト工程で、仕様を変更することが難しくなります。
運用部門へのヒアリングや、ビジネス目標の設定をしっかり行えるリソースが自社にある場合に適した開発手法です。
「アジャイル」(agile)とは、「すばやい」、「機敏な」という意味です。
ウォーターフォールでは、すべての仕様を設計してから開発にとりかかりますが、アジャイルでは最初にすべての仕様を決めず、大体の方向性だけを決めて開発を進めます。
またシステム全体を、機能ごとに幾つかの単位に分割して開発します。このため、仕様変更や不具合など、不測の事態にも素早く対応でき、全体への影響も少なく抑えることができます。
また、開発途中で現場のユーザーとコミュニケーションを取りながら進められるので、現場にとって「使える」システムを開発できます。
途中で仕様変更が発生することが想定されるプロジェクトに有効な開発手法です。
ただし、開発途中でシステムの方向性がずれるというリスクがあります。また、全体を幾つかに分割して開発を進めるので、全体の把握やスケジュールの管理が難しいというデメリットがあります。
ウェブサービスやアプリ開発など、ユーザーニーズへの柔軟な対応が求められるプロジェクトに適しています。
「スパイラル」とは、「spiral」つまり「螺旋」からきています。アジャイルと同じく、システムを幾つかの単位に分けて開発を進めます。
それぞれの単位で要件定義、設計、開発、テスト、そして評価というサイクルを繰り返すことで、システム全体の完成度を螺旋のように上げていくところから、「スパイラル」と呼ばれます。
開発途中での仕様変更にも柔軟に対応できるというメリットは、アジャイルと同様です。
ウォーターフォールのように、各工程の計画性を重視して開発を進めていくので、品質重視の、ある程度大規模なプロジェクトに適しています。
「プロトタイピング」(Prototyping)とは、システム開発の早い段階で、プロトタイプ、つまり試作品を作成する開発手法です。
プロトタイプをシステムのユーザーと一緒にレビューしますので、早いうちに認識のズレが解消できます。
また、ユーザーの生の声を聞けることで、よりよいユーザー体験を実現できます。
ただ、プロトタイプを作成するコストと期間が必要になりますので、それがデメリットになる場合もあるでしょう。
新規事業や新製品開発など、ユーザー体験を重視するプロジェクトに向いています。
「DevOps」は、「デブオプス」と読みます。開発担当者と運用者が連携して開発をする手法です。
「Dev」は「Development」、つまり開発チームを指し、「Ops」は「Operations」、「運用チーム」を指しています。比較的、最近登場した新しい開発手法です。
テストを終えたシステムを開発チームがリリースした後、システムの運用、保守など、システムの面倒をみるのが運用チームです。
開発チームと運用チームの役割は違いますが、システムを通じてビジネスの価値を高めるという目標は同じです。
そのため、DevOpsでは、システム開発の段階から開発チームと運用チームが協力し、緊密に連携していきます。これにより、リリースまでの期間短縮やユーザー満足度の向上、品質の向上など、さまざまなメリットが得られます。
どの開発手法をとるにしても、システム開発の大まかな流れは同じです。
システム開発は概ね、次のような7つのステップで進んでいきます。
システム開発の大体の流れをつかんでおくと、進捗状況の把握や、問題への対処がしやすくなります。ここでは、それぞれのステップについて、簡単に説明します。
システム開発の最初のステップであり、最も重要なステップです。
このステップでは、システムがカバーする範囲や、実現方法などを決定し、システムの大まかな仕様を「システム要件」として定義します。
以降のステップはすべて、この「システム要件」を満たすために実行されます。ここでしっかりと要件を定義しておかないと、後に大きなスケジュールの遅れや、コストの増加など、問題が起きる場合があります。
要件定義ではまず、ユーザーにヒアリングを行います。その結果を踏まえ、「システム要件」を定義した「要件定義書」を作成します。
経営陣に対してはビジネス上の課題や今後の展望について、システム管理部門に対しては現状のシステム構成や使用しているツールなどについてヒアリングします。また、業務部門に対して、現状の業務内容や業務フロー、困りごとをヒアリングする場合もあります。
システムの基本的な構成を設計するステップで、「基本設計」とも呼ばれます。
サービスを提供するサーバーや、利用者が使用するクライアントなど、システムのハードウェアを検討します。
また、システムで使用するネットワークや、ミドルウェアと呼ばれる中間ソフトウェア、プログラミングに使用するプログラミング言語など、ソフトウェアについても検討します。
システムの画面構成など、人の目に触れる部分の設計も行います。
外部設計よりもさらに詳細な設計を行うステップで、「詳細設計」とも呼ばれます。
ユーザーが操作する画面の裏で、内部的に実行される処理について、処理のロジックや内部データの構造などを、詳細に定義します。
この内部設計をもとにしてプログラミングが行われます。
内部設計を元に、実際にプログラムを作っていくステップです。「コーディング」とも言います。
システムの規模にもよりますが、通常は複数のプログラマーが同時にプログラミングを行います。そのため、矛盾が生じないように「バージョン管理システム」を使って、作業中のデータを管理します。
設計通りにプログラムが作成されているか、確認するステップです。
どんなに注意して作業していても、人間が行う作業である以上、ミスは発生します。また、設計時には予測できなかった不具合や、複数のプログラム部品を組み合わせてみて、初めて発生する不具合などもあります。
システムをリリースする前に、ミスや不具合を解消して、品質を高めるのが「テスト」ステップの目的です。
また次の表のように、テストにはいくつか種類があります。「対応するステップ」列で定義したことが実現できているかどうかを、「テストの種類」で記述しているテストで確認を行います。
順番 | テストの種類 | 対応するステップ | 着眼点 |
1 | コードレビュー | プログラミング | ルールに従って適切にプログラミングできているかどうか |
2 | 単体テスト | 内部設計(詳細設計) | プログラム部品が単体で上手く動作するかどうか |
3 | 結合テスト | 外部設計(基本設計) | プログラム部品を組み合わせ、全体として問題なく動作するかどうか |
4 | システムテスト | 要件定義 | 全体として、要件定義の要求を満たしているかどうか |
開発とテストが完了して、一定の品質が確保できたら、システムをユーザーに引き渡します(リリース)。
単に引き渡すだけではなく、実際にシステムを使用するユーザーが困らないよう、操作方法についてのトレーニングを行ったり、ドキュメントを整備したりします。
また、引き渡された側は、システムが要求した仕様を満たしていることを確認する(これを「検収」といいます)必要があります。
リリースしたらシステム開発は終了、というわけではなく、運用開始後もサポートを継続します。
実際のデータを使用して運用すると、開発段階では予測できなかった不具合が発生することがあります。また、ユーザーが想定外の操作を行ったためにエラーが発生する場合もあります。
サーバーやクライアントPCなどのハードウェアが故障することや、オペレーティングシステムへの更新プログラム適用が必要になる場合もあります。
このため「運用チーム」を用意しておき、システムのリリース後に発生した問題に対処します。その他「運用チーム」は、安定してシステムが稼働するように監視したり、問題が起きていないか、定期的にヒアリングを行ったりします。
また、ユーザーから挙がってきた追加要望をまとめておき、後日、追加開発を行う場合もあります。
システム開発にかかるコストについて、仮にソフトウェアの場合は、大部分が人件費です。システム開発の見積では、人件費は「人月」という単位で計算されます。
「人月」とは、1人のスタッフが1か月稼働する場合の工数です。例えば「10人月」ならば、1人が10か月か、10人が1か月稼働するという意味です。
当然この「人月」も、スタッフの役割やスキルによって、単価が異なります。そのためシステム開発のコストを把握するには、どのようなスタッフがプロジェクトに関わるのかを理解しておく必要があります。
システム開発には、主に次のようなスタッフが関わってきます。
◎ プロジェクトマネージャー
◎ システムエンジニア
◎ プログラマー
プロジェクト全体を管理するマネジメント職です。
プロジェクトが円滑に進むよう、プロジェクト実行計画の立案、スケジュール管理、リソース管理、コスト管理、ステークホルダー管理などのマネジメント業務を行います。
システム開発の知識だけでなく、マネジメントや問題解決、コミュニケーションスキルなど、多岐にわたって高度なスキルを要求されるため、高いコストが必要です。
システムの要件定義、設計、開発を担当する、技術職です。
ユーザーへのヒアリングや要件定義の作成、システムの詳細な設計など、システム開発の技術的側面において、重要な役割を担います。通常はプログラミングを行いません。
システムの設計に関わるため、技術に対する幅広い知識だけでなく、ビジネスについての知識も求められます。そのため、プログラマーに比べるとコストは高くなります。
システムエンジニアの指示や、詳細設計書にしたがって、実際にコーディングをしていく技術職です。
プログラミング言語やITシステムに、深く習熟していることが求められます。
システム開発を検討する際には、スケジュールやコスト、費用対効果の他にも、いくつか注意しなければならない点があります。
その中でも、リスクマネジメントは特に重要です。
システム開発の期間は長期に渡り、費用も大きくなる場合がありますので、できるだけリスク要因は少なくしておくべきです。
ここでは、次に挙げた注意点について、簡単に説明します。
◎ 要件定義はしっかり詰めておく
◎ メンバーの実績やスキルを確認する
◎ コミュニケーションは密に取る
リスクを極力減らすため、「要件定義」でしっかりと要件を詰めておく必要があります。
開発は、最初の「要件定義」ステップで決めた「システム仕様」に従って進んでいきます。
要件を詰めきれておらず、開発の途中で「システム仕様」に大きな変更が入ると、開発に悪影響を及ぼす可能性があります。スケジュールの遅延、作業コストの増大、品質の低下、パフォーマンスの低下、運用開始後の業務効率低下など、さまざまな問題を引き起こす原因となるのです。
例えば、プログラミングの途中で、画面にボタンを1つ追加したとします。
ユーザーから見ればほんの少しと思われる修正かもしれませんが、システムの内部では、データ定義の変更やデータ処理ロジックの変更、エラー処理の追加など、多くの修正をしなければなりません。場合によっては、設計を1からやり直すことにもなりかねません。
ちなみに、要件定義段階での不備は開発側だけでなく依頼側にも責任があります。システムを導入する業務については、開発側がすべてを熟知しているわけではありません。そのため、要件定義書に不備がないかどうか、依頼側も注意深くチェックする必要があります。
システム開発(ソフトウェアの場合)のコストの大部分を占める人件費を、やみくもに低く抑えようとするのは避けた方がよいでしょう。人件費を抑えると、スキルや経験が十分でないメンバーばかりがアサインされてしまうリスクがあるからです。
システム開発に携わる人材のクオリティは、システム開発の成否に大きく影響します。メンバーの実績やスキルをしっかりと確認したうえで、適切な人材を、適切な価格でアサインしてもらうように注意する必要があります。
「要件定義」ステップが終了し、開発がはじまってからも、開発側と依頼側のコミュニケーションは密に取る必要があるでしょう。
システム開発の進行中には、さまざまな問題が発生します。設計段階では想定できなかった技術上の制約や、市場の変化、法制度の変更など、開発側または依頼側の、どちらにも責任がない問題も起りえます。
お互いの立場や事情を考慮して、建設的かつ合理的な解決策を探るには、コミュニケーションがきちんと取れている必要があるでしょう。
また、コミュニケーションを密にとることで、問題が小さなうちに、迅速に適切な対処ができます。
お互いに相談しやすいような環境を整えることも必要です。例えば、雑談感覚で気軽に話ができるチャットツールや、作業進捗やアクションアイテムを共有できるコラボレーションツールなどを活用するとよいでしょう。
少しの意思決定の遅れが、現場の作業を止め、システム開発に大きく影響します。また、コミュニケーションを密にすれば、「1つの目的に一緒に向かっている」という信頼感を築くことができます。
世の中のIT化が進むにつれて、多くの企業がシステムの開発や導入を行っています。自社の業務効率化を図りたいと考えている場合は、どんなことを実現したいのかを定義し、それを実現するためのアクションを考えるところから始めると良いでしょう。
それにあたり、システム開発が必要な場合は「どのような開発手法があるのか」「どんな手順を踏むのか」といった、システム開発の概要を押さえておくと良いでしょう。また、システム導入を実現するためのコストや必要なメンバーというのも想定しておくことが大切です。
「このシステムを作るには、どんなメンバーが必要で、何日かかるのか」を明確にしたうえで、不足している要素については採用を強化したり、外部に委託したりするなど解決策を考える必要があります。
これまでASTINAは、多くのシステム開発を経験しております。特に弊社の専門領域である、IoT、AI、ロボットなどの先端技術を活用した開発経験が豊富です。「自社の生産性を向上したい」「自社製品に先端技術を組み込みたい」「新たにDX関連の事業をスタートさせたい」といったお客様に選ばれております。ハードウェア、ソフトウェア問わず幅広くご対応しておりますので、お悩みがございましたら、ぜひお気軽にご相談くださいませ。