プログラミングなどが学校教育に取り入れられている近年、システムを開発する職業に興味を持つ人が年々増えている印象があります。しかしながら、実際、システム開発がどの様な手順で行われているか、というのは見えづらいようにも感じています。
普段からシステム開発を行っている企業として、改めてシステム開発はどの様な流れで進んでいくのかを考えてみました。システム開発を行うためのステップについて紹介していきます。ここでは広く一般的な開発案件で用いられる「ウォーターフォールモデル」を前提に解説します。
システム開発の6つの流れ
システム開発は大きく分けると6つの流れ(工程)があると考えています。一般的にシステムを開発するには、顧客の業務を理解・分析しながら、それらをシステムに落とし込み、業務改善を行るかを検討することが肝となります。そこからスタートして、構築方法の検討や検証、構築を経たうえで納品という流れとなります。
- 要件定義
- 設計工程
- 検証工程
- 実装工程
- 試験工程
- 納入
上記のような流れをたどってシステムの開発を進めていきます。以下、各工程に対して概要、および考察や注意点などをまとめて記載してみました。システム開発に興味を持っている方々にとって、有益な情報になるのではないかと考えています。
1.要件定義
システム開発を行う上で重要になるのが「要件定義」と呼ばれるものです。要件定義をシンプルに言ってしまうと「何を、どんな風に、どのように、どんな目的で」作るのかを決めて提案書としてまとめていく工程です。システム化をする上で達成するべき目標を記述していくことであり、この時点で定義された内容が顧客に対する「約束される結果」となります。
要件定義は顧客の業務を分析したうえで、どのように業務フローとシステムを組みあわせてれば、顧客の問題を解決できるかを定義します。したがって、技術に長けていることよりも、業務を理解・分析し、システムに落とし込むスキルが必要とされることが一般的です。
コンサルティング会社が仲介する場合もあれば、顧客と直接やり取りを行う場面でもあり、技術的な内容を理解しやすい粒度に落として説明し、相手に理解・納得させるスキルが必要とされます。
要件定義はシステム開発の案件の方向性を決める工程となります。実際、要件定義がうまくいかないままシステムを開発したことにより、顧客が望んでいたものと異なるものが出来上がったことで問題となるケースも見てきました。中には訴訟問題に発展するケースもあります。そのため要件定義での成否が案件の運命を担うといっても過言ではありません。
2.設計工程
前項の要件定義の後、実際にシステムを構築していく前段階として「どのように作っていくか」を決定していきます。設計工程には大きく「外部設計」と「内部設計」の2つが存在しており、外部設計は顧客向け、内部設計はエンジニア向けの資料として作成されます。
外部設計
外部設計は主に、エンジニアではない顧客との、プロジェクトの認識あわせに用いられる設計書であり、開発規模や開発期間を見積もるための根拠を記載し、予算やスケジュールのすり合わせに使用されることが多いです。エンジニアに向けた資料ではないため、どのような粒度で情報を記載するかが重要なポイントです。難しすぎても理解されず、簡単すぎても開発工数や予算の根拠に乏しいものとなってしまうので注意が必要です。
内部設計
内部設計はその名の通り、内部(エンジニア)に向けた設計書です。外部設計書で定義した内容を実装工程に落とし込むために作成することが一般的と言えるでしょう。処理ロジックを箇条書きにして整理したり、クラス図やシーケンス図などを用いて情報を整理していきます。こうした情報を残しておくことがプロジェクト進行に安定性をもたらすのです。
設計工程は要件定義にて設定したゴールに対して目的が達せられるかを、書類を作成しながら検討していく工程となり、設計段階で整合性を確認し、全体的に問題ないかを検証することを目的とします。一般的にシステム開発は想定よりも時間や難易度がぶれてしまうことが一般的です。
しかしながら、設計工程をしっかりと行い、思いつく限りのリスクを潰しておければ、先の工程での作業の増大を防ぐことができるかもしれません。手を動かす前に頭を動かして、しっかりと構想を練ることが重要であり、この工程を抜かりなく行っておくことが、後々の作業に影響を及ぼします。
3.検証工程
検証工程とは、設計工程で作成された資料を検証する作業です。設計した時点で、机上で構築するアプリケーションが論理的に破綻していないか、到達すべき目標に対して漏れが発生していないか等、作成した設計工程での内容を確認する作業に当たります。設計したものが「本当に実装可能であるか」という判断も下します。
この時点でちゃんと検証が出来ていないと、設計上では理想的なように見えていても、実は各所で破綻していたり、構築するのに予算を大幅にオーバーするような内容だった、という事態を招くこともあるのです。システム開発は複雑性が高く、不透明性もあり、先行きを見通すのが非常に困難な仕事です。そのためのリスクを潰すべく、設計したものを厳しく見る目を持つ必要があるということです。
検証工程にて無事に落としどころが見つかったところで、変更点等を設計書に書き残したりしたタイミングで、ようやく設計に関係する工程が完了します。いわゆる「ドキュメンテーション(書類作成)」と言われるやつです。論理的に問題をそれなりに潰したうえで、ようやく実際にシステムを構築していく段階に入っていきます。検証工程まで完了した段階で、「必要情報の整理は完了」ということになります。
4.実装工程
設計から検証を経てドキュメントが完了した後は、システムを本格的に開発(構築)していく段階に入っていきます。設計工程で作成された様々なドキュメントを頼りに、そこに記述された内容物をソースコードに落とし込んで構築していく作業です。
一般的な「システム開発」という部分では、この実装工程を思い浮かべることが多いでしょう。この段階では作成した設計書に沿った処理を記述するだけでなく、第三者にも理解できる記述方式であるかも検討しながら作業を進める必要があります。システムを開発していると「半年前に自分が書いたソースコードも忘れてしまう」ような事態に遭遇します。そのため、出来る限り理解できるように記述し、ヒントとなるコメントも残しておく必要があります。
また、ドキュメントの工程で作りこんでおいても構築する時に考慮が漏れてしまうことがあります。そのような情報の漏れを検出した段階で、実装工程と設計工程を行ったり来たりすることが多くなります。設計工程で作成したドキュメントに対して、実装工程の漏れを反映していきます。お互いに補完しあう関係でもあるのです。
5.試験工程
実装工程で作成したシステムを試験していく工程になります。大きく「単体試験」「結合試験」「受入試験」の3つに分かれることが多いです。
単体試験は作成したモジュールなど、比較的小さなまとまりが正しく機能するかを確認するテストです。単体試験は別名「ユニットテスト」と呼ばれることもあります。結合試験では単体テストを通過した、正常に動くモジュールを組み合わせた機能を結合させてテストしていく工程になります。より実際の作業に近くなるように機能を実行させ、定義された内容に基づいた処理がされているかを検証します。例えば画面入力に対して、結果の出力が正しいか等を行っています。
結合試験では機能横断等をおこなう必要はなく、機能単体など小さいところから始めるのが一般的となります。それより先のよりオペレーションに近い視点で行うテストが「受入試験」になります。受入試験では、実際の現場で想定される運用に沿った内容で、要件定義等で正しく要件が満たされているかを総合的に確認するテストです。納入先となるユーザー様に利用してもらって、運用に似た形式で利用してもらったり、様々な考えられるパターンでテストを行って、運用に耐えうるかを検証していきます。
試験工程における試験の期待値は、設計工程で作成したドキュメントや要件定義で定義した目的になります。
ドキュメントベースで考えた際に、それらが満たされているのか、という点がテスト観点ということです。テストの技法は様々であるため、ここで言及することはしませんが、システム開発におけるテストは小さい個所から始めて徐々に大きな範囲で検証を進めることが重要です。
またテストの行いやすさ、バグが発見されたときにリカバリーするために必要な時間も、試験工程に含んでおかなければなりません。実装工程でのスキル不足により、見通しの悪いソースコードであると、修正範囲が見えづらく「デグレード」等を起こしかねません。
スキルの高いエンジニアとは、実装が速いとか難しい技術を使うといった観点だけでなく、万人が読みやすく、修正のしやすいソースコードを書くことも要素の一つだと考えます。ソフトウェアは完全ではなく、必ずと言っていいほど不具合を生み出します。その状況でも最小の労力で修正することができ、リカバリー速度を速めることが出来るエンジニアも「よいエンジニアの条件」になるはずです。
6.納入
納入工程は一般的に「リリース」と呼ばれることが多く、その名の通り「システムを納入する工程」です。試験工程により最初に作成・合意した要件定義の内容を満たされていると確認されて、システムの開発が完了となり、実際にシステムを納品して、ユーザー環境で稼働させるための工程となります。
システム開発としては、この時点で完了扱いとなり、以降は「保守・運用」と呼ばれるフェーズに移っていきます。保守・運用では納品したシステムがユーザーの下で正しく運用されているか、また不具合などが発生した場合に問題点を改修したり、改善内容があれば対応していくようなフェーズとなります。システム開発は作って終わりであることが少なく、作った後にシステムを軌道に乗せるために時間がかかります。
また保守・運用フェーズになると開発会社が継続して案件を進めていくため、定期的な売上を見込むことが出来ます。そのため、開発会社は開発費用を安めに見積もって入札を得て、保守・運用フェーズで売上を回収するようなケースもあります。本来はシステム開発の費用で黒字、保守・運用でも黒字がうれしいものですが、案件獲得のために多少開発フェーズで無理をすることもあるのです。
システムは情報と信頼で開発する
以上、システムを開発する流れを解説してきました。ところどころ、システム開発を行う上での注意点や各工程での問題点、考慮事項なども記載してきました。何度も出てきますが、システム開発は複雑性が高く、透明性がないので仕事を進めるのが非常に難しい部類の案件になると思います。
その中でスムーズにデリバリーまでたどり着くには、偏にエンジニアだけの技量ではありません。相手に信頼され、相手を信頼し、システム開発を行う上で必要となる情報をしっかりとやり取りし、「ともにシステム開発を開発して業務を効率化するんだ」という共通認識を持つことだと思います。
システム開発は遅延することも良くありますし、ほとんどの場合で期限通りに終わることはありません。顧客と真摯に向き合い、必要な情報は開示し、互いに寄り添いながらカバーしてゴールを目指していくことがとても重要なのです。実際にはそれが難しいため、うまくいかないことの方が多いです。それでもシステムは「情報」と「信頼」によって開発されていると考えてもよいはずです。複雑性が高いからこそ、正確な情報を深く分析し、相互信頼によって案件を進める関係性を構築していきたいものですね。