まずはご相談下さい。御社の実現したい内容・ご予算に応じたシステム提供ができるか否かをご提案させて頂きます。
システム開発の目的は、ビジネス上の課題を解決することです。
企業によってさまざまな課題がありますが、システム開発では主に以下のような課題を解決します。
◎ 新製品の開発、新規事業への参画
◎ 業務効率化によるコストダウン
◎ 顧客満足度の向上による競争力強化
◎ 業務継続性の維持
◎ 外部規制、法制度、コンプライアンスへの対応
◎ 市場の要請、業界団体からの要請への対応
◎ 経営の統廃合への対応
システム開発の手法
一口にシステム開発と言っても、それぞれ現状の課題や、目指すべきゴールが異なりますので、実現するまでの手法もさまざまです。どの手法でも、概ね「要件定義」「設計」「開発」「テスト」をしてから、「リリース」して実際に使ってもらう、という流れをとります。
ただ、コストおよび開発期間の制約や、システムの規模によって開発手法も異なります。さらには、開発を依頼する側の習熟度や経験などによっても、最適な開発手法は違ってきます。
そのため、依頼する側でもシステムの開発手法にはどんなものがあるのか、一通りは理解しておく必要があります。ここで主なシステム開発の手法をご紹介します。ご自身のシステム開発にはどの開発手法をとればよいのか、これを参考にしてください。
代表的な開発手法
◎ ウォーターフォール
◎ アジャイル
◎ スパイラルモデル
◎ プロトタイピング
◎ DevOps
手法①：ウォーターフォール
「ウォーターフォール」（waterfall、滝）は、上流の「要件定義」工程から下流の「テスト」工程まで、滝の上から水が落ちていくかのごとく、順序に従って工程を進めていく開発手法です。
手法②：アジャイル
「アジャイル」（agile）とは、「すばやい」、「機敏な」という意味です。
ウォーターフォールでは、すべての仕様を設計してから開発にとりかかりますが、アジャイルでは最初にすべての仕様を決めず、大体の方向性だけを決めて開発を進めます。
手法③：スパイラルモデル
「スパイラル」とは、「spiral」つまり「螺旋」からきています。アジャイルと同じく、システムを幾つかの単位に分けて開発を進めます。
それぞれの単位で要件定義、設計、開発、テスト、そして評価というサイクルを繰り返すことで、システム全体の完成度を螺旋のように上げていくところから、「スパイラル」と呼ばれます。
手法④：プロトタイピング
「プロトタイピング」（Prototyping）とは、システム開発の早い段階で、プロトタイプ、つまり試作品を作成する開発手法です。
プロトタイプをシステムのユーザーと一緒にレビューしますので、早いうちに認識のズレが解消できます。
また、ユーザーの生の声を聞けることで、よりよいユーザー体験を実現できます。
手法⑤：DevOps
「DevOps」は、「デブオプス」と読みます。開発担当者と運用者が連携して開発をする手法です。
「Dev」は「Development」、つまり開発チームを指し、「Ops」は「Operations」、「運用チーム」を指しています。比較的、最近登場した新しい開発手法です。
システム開発の流れ
どの開発手法をとるにしても、システム開発の大まかな流れは同じです。
システム開発は概ね、次のような7つのステップで進んでいきます。
- 要件定義
- 基本設計
- 機能／詳細設計
- プログラミング（製造）
- 単体/結合テスト
- リリース
- 運用・サポート
システム開発の大体の流れをつかんでおくと、進捗状況の把握や、問題への対処がしやすくなります。
1.要件定義
システム開発の最初のステップであり、最も重要なステップです。
このステップでは、システムがカバーする範囲や、実現方法などを決定し、システムの大まかな仕様を「システム要件」として定義します。
以降のステップはすべて、この「システム要件」を満たすために実行されます。ここでしっかりと要件を定義しておかないと、後に大きなスケジュールの遅れや、コストの増加など、問題が起きる場合があります。
要件定義ではまず、ユーザーにヒアリングを行います。その結果を踏まえ、「システム要件」を定義した「要件定義書」を作成します。
経営陣に対してはビジネス上の課題や今後の展望について、システム管理部門に対しては現状のシステム構成や使用しているツールなどについてヒアリングします。また、業務部門に対して、現状の業務内容や業務フロー、困りごとをヒアリングする場合もあります。
2.基本設計
サービスを提供するサーバーや、利用者が使用するクライアントなど、システムのハードウェアを検討します。
また、システムで使用するネットワークや、ミドルウェアと呼ばれる中間ソフトウェア、プログラミングに使用するプログラミング言語など、ソフトウェアについても検討します。
システムの画面構成など、人の目に触れる部分の設計も行います。
3.機能/詳細設計
基本設計をさらに機能毎に設計を行うステップで、「機能/詳細設計」を行います。
ユーザーが操作する画面の裏で、内部的に実行される処理について、処理のロジックや内部データの構造などを、詳細に定義します。
この機能／詳細設計をもとにしてプログラミングが行われます。
4.プログラミング
詳細設計を元に、実際にプログラムを作っていくステップです。「コーディング」とも言います。
システムの規模にもよりますが、通常は複数のプログラマーが同時にプログラミングを行います。そのため、矛盾が生じないように「バージョン管理システム」を使って、作業中のデータを管理します。
5.単体/結合テスト
設計通りにプログラムが作成されているか、確認するステップです。
どんなに注意して作業していても、人間が行う作業である以上、ミスは発生します。また、設計時には予測できなかった不具合や、複数のプログラム部品を組み合わせてみて、初めて発生する不具合などもあります。
システムをリリースする前に、ミスや不具合を解消して、品質を高めるのが「テスト」ステップの目的です。
また次の表のように、テストにはいくつか種類があります。「対応するステップ」列で定義したことが実現できているかどうかを、「テストの種類」で記述しているテストで確認を行います。
6.リリース
開発とテストが完了して、一定の品質が確保できたら、システムをユーザーに引き渡します（リリース）。
単に引き渡すだけではなく、実際にシステムを使用するユーザーが困らないよう、操作方法についてのトレーニングを行ったり、ドキュメントを整備したりします。
また、引き渡された側は、システムが要求した仕様を満たしていることを確認する（これを「検収」といいます）必要があります。
7.運用・サポート
リリースしたらシステム開発は終了、というわけではなく、運用開始後もサポートを継続します。
実際のデータを使用して運用すると、開発段階では予測できなかった不具合が発生することがあります。また、ユーザーが想定外の操作を行ったためにエラーが発生する場合もあります。
サーバーやクライアントPCなどのハードウェアが故障することや、オペレーティングシステムへの更新プログラム適用が必要になる場合もあります。
このため「運用チーム」を用意しておき、システムのリリース後に発生した問題に対処します。その他「運用チーム」は、安定してシステムが稼働するように監視したり、問題が起きていないか、定期的にヒアリングを行ったりします。
また、ユーザーから挙がってきた追加要望をまとめておき、後日、追加開発を行う場合もあります。
システム開発に必要なコストとメンバー
システム開発にかかるコストについて、仮にソフトウェアの場合は、大部分が人件費です。システム開発の見積では、人件費は「人月」という単位で計算されます。
「人月」とは、1人のスタッフが１か月稼働する場合の工数です。例えば「10人月」ならば、1人が10か月か、10人が1か月稼働するという意味です。
当然この「人月」も、スタッフの役割やスキルによって、単価が異なります。そのためシステム開発のコストを把握するには、どのようなスタッフがプロジェクトに関わるのかを理解しておく必要があります。
システム開発を検討する際の注意点
システム開発を検討する際には、スケジュールやコスト、費用対効果の他にも、いくつか注意しなければならない点があります。
その中でも、リスクマネジメントは特に重要です。
システム開発の期間は長期に渡り、費用も大きくなる場合がありますので、できるだけリスク要因は少なくしておくべきです。
ここでは、次に挙げた注意点について、簡単に説明します。
◎ 要件定義はしっかり詰めておく
◎ メンバーの実績やスキルを確認する
◎ コミュニケーションは密に取る
要件定義はしっかり詰めておく
リスクを極力減らすため、「要件定義」でしっかりと要件を詰めておく必要があります。
開発は、最初の「要件定義」ステップで決めた「システム仕様」に従って進んでいきます。
要件を詰めきれておらず、開発の途中で「システム仕様」に大きな変更が入ると、開発に悪影響を及ぼす可能性があります。スケジュールの遅延、作業コストの増大、品質の低下、パフォーマンスの低下、運用開始後の業務効率低下など、さまざまな問題を引き起こす原因となるのです。例えば、プログラミングの途中で、画面にボタンを1つ追加したとします。
ユーザーから見ればほんの少しと思われる修正かもしれませんが、システムの内部では、データ定義の変更やデータ処理ロジックの変更、エラー処理の追加など、多くの修正をしなければなりません。場合によっては、設計を1からやり直すことにもなりかねません。
ちなみに、要件定義段階での不備は開発側だけでなく依頼側にも責任があります。システムを導入する業務については、開発側がすべてを熟知しているわけではありません。そのため、要件定義書に不備がないかどうか、依頼側も注意深くチェックする必要があります。
