Column

システムを作ってみようと思い立ったときに、どうやって作れば良いのかわからない方が大半だと思います。
また、どのようにシステムが作られていくのか想像できない方も多いはずです。
どんな工程があって、どんな事が行われているのか理解してから、システム開発を進めたほうがスムーズですし事前に準備を始めることが出来ます。
発注者はシステム開発会社にシステム開発を丸投げするのではなく、システム開発を理解した上で、開発者と協力しながらシステム開発をすすめることがシステム開発を成功させる重要なポイントです。

ここではウォーターフォール型システム開発の工程を簡単に説明します。

システム開発はざっくり４つの工程に分けることができます。

発注者は要求を開発者に伝え、開発者は要求の実現の可否・実現方法を検討し要件定義書を作成する。

要件定義が曖昧だったり、要求・要件を後から変更するとすべての工程に影響を与えるため、スケジュールの遅延や開発費用の増大に繋がる。

要件定義書の要求・要件に沿ってシステムで実現できるように設計書を作成する。

発注者の要求をプログラマーが理解できるように変換する作業と捉えると理解しやすい。

基本設計と詳細設計に分かれる。

設計書に沿ってプログラミングする。

要件定義書・設計書の要求・要件を満たしているか確認する。

この中で一番重要度が高いのは要件定義です。なぜなら要件定義に問題があると、続く工程でその間違いを引き継いでいるからです。
テストで気づくこともできません。

要件定義にはしっかり時間を使いきっちり要件を固める事がプロジェクトの成功に不可欠です。
要件定義の間違い、要件定義漏れは致命的なミスに繋がります。

次に重要な工程がテストです。開発されたシステムが要件と設計に合っているか確認します。

開発者がしっかりテストするのはもちろんのことですが、発注者も積極的にテストに参加するべきです。

専門家に任せたのだから完璧なものが出てくると思っていると、想像していた物と違ったなど問題が発生しがちです。

最後のひと踏ん張りなのでしっかりテストを実施して下さい。

テストと並んで重要な工程がシステム設計です。
内部設計は発注者側にプログラミングの知識がないと難しいのですが、外部設計は知識がなくても理解できるものがあるので目を通して確認しましょう。

最後になりますが開発の工程も重要です。しかし発注者側から出来ることがあまりない工程でもあります。
定期的に進捗を確認し、できればシステムを触らせてもらうなど開発者と相談しましょう。

次に各工程でのポイントを解説します。

解決したい課題を明確にする。課題に対する解決策に合意する。

要望はすべて伝えた上でどの機能を実装してどの機能を実装しないか決定し合意する。

外部設計のうち機能一覧・ページ一覧・画面設計など知識がなくても理解できるものは最低限目を通し認識の齟齬がないか確認する。

できれば発注者が閲覧できる開発環境を用意してもらい機能ごとなどに区切って確認したり、定期的にミーティングを開催し進捗を把握する。

積極的にテストに参加する。要件定義・外部設計どおりに作られているかテストする。

発注者と開発者が関わる工程（要件定義・テスト）の重要度が高く、発注者の積極的な関与が求められます。

開発者は発注者が参加しやすいようにわかりやすく説明するなどのサポートを行うことが必要ですし、発注者の協力が得られていないと感じた時点で参加・協力を仰ぐべきです。

発注者は開発者に丸投げするのではなく、システム開発について理解するように努力するべきですし、積極的にシステムが自分たちの要望通りに動くのか、認識の齟齬がないか確認するべきです。

また、ステークホルダー間のコミュニケーション不足もシステム開発失敗の原因になります。要件定義からテストまで必要十分にコミュニケーションを取ることを心がけましょう。

家を建てるのとシステム開発は似ているかもしれません。あなたが施主だとしたら、頼みっぱなしで完成まで放っておきますか？自分の家がどんな状態か、どこまで進んだのか、設計に沿った作りになっているか確かめに行くのではないでしょうか。それは完成後に間違いに気づいても遅いもしくは余計な手間がかかると感じているからだと思います。

システム開発でも同じです。
発注者も開発者も一丸となり、一つのチームとしてシステムの開発を進める必要があります。

簡単にですが各工程の説明・ポイント・重要度などを解説しました。

このページでは工程を４つにしていますが細かく見るともう少し増えると思いますし、開発手法によって変わると思います。

各工程の詳細を説明することは出来ないので他のページに譲りますが、ぜひ他の工程も掘り下げ理解してシステム開発を成功させて下さい。