開発プロセスとは?
プロセスとは工程のこと、ソフトウェア制作の現場で開発プロセスと言ったら『ソフトウェアの開発に着手してから、設計、コーディング、テストを経て、あるソフトウェアが完成（リリース）するまでの工程』のコトを指しています。
もし、あなたがソフトウェアの製作を他の会社にお願い（発注）した場合、キチンとしたソフトウェア製作会社であるなら、制作するソフトウェアの品質を確保するためにも、ちゃんとした”開発プロセス”を踏んで、クオリティの高いソフトウェアを提供してくれるはずです。
しかし、発注者であるあなたも結果として出来上がるソフトウェアが期待するモノとなるために、発注側として開発プロセスを意識することで、ソフトウェア制作会社とよりWin-Winな結果を得ることが出来ます。
あなたが、自分の家、あるいは自社ビルを注文して建てる場合を想定してみてください。建築会社とは最初のイメージ図だけで、後はお任せ、何でコトはないと思います。ソフトウェアも同じです。いや、ソフトウェアは目に見えないモノですから、建築物件以上に、より途中での確認を行うことが重要です。
また、ソフトウェア製作会社との間で開発プロセスとスケジュールを決めておくことで、自分のビジネスを予定通り開始するための見通しも立てやすくなります。
今日は、ソフトウェア開発における基本的な開発プロセスと、発注側の役割についてお話したいと思います。
基本的な開発プロセス：
ソフトウェアの基本的な開発モデルはウォーターフロー・モデルと呼ばれる開発手法で、図のように上の工程から水が流れるようにプロセスが進むため、このように呼ばれています。
それでは、それぞれのプロセスでどの様な作業が行われるのか？また、発注側として関わる部分はドコか？ に、ついて述べていきます。
要件定義：
そのソフトウェアで実現したいコトについて、明確化します。例：顧客管理のページを発注した場合
・iOS、Android、PCのメジャーなブラウザで動作すること
・顧客の登録フォーム（名前、住所、電話番号など）
・登録した顧客のIDを自動発行する
・顧客情報は個人情報なので暗号化する
・暗号化の強度は、SHA-256、AES-128以上とする
などなど。。。
概要設計：
要件定義で決めた内容を、どの様なアーキテクチャで実現するか設計します。データーベースを使うとか、オープンソースのプロダクトを使うとか、大まかなプログラム要素とデータの流れを決定します。
会社によっては、基本設計と呼んでいる所もあります。
どの様なアーキテクチャとするかで、運営コストや責任が変わってきますので、このフェーズでの設計が完了した時点での設計確認（レビュー）を行うことをオススメします。
詳細設計：
概要設計で決めたアーキテクチャを実際にどんなプログラムにするかを設計します。モジュール、タスク、関数と言った個々のプログラム要素を決めます。
開発の規模にもよりますが、何人かで手分けして進めます。
実装（コーディング）：
詳細設計で決めた内容から実際のプログラムのソースコードを書いていきます。プログラマーがもくもくとパソコンに向かって仕事をするイメージですね。
単体試験：
実装したソフトが詳細設計で決めた動作をしているか確認します。このため、誤動作（バグ）があった場合などは、詳細設計やソースコードを修正して試験をやり直す、という事を繰り返します。
このあたりまでは、個別の担当者が確認します。
私達のような本職の場合、単体試験レベルでのバグの発生・解決状況を確認するだけでそのソフトウェアの品質が大体わかりますので、状況を外部のコンサルに確認してもらうのも方法です。
結合試験：
これまで、内部の個別の部分を確認してきましたが、それぞれをつなげて動作するか確認します。概要設計で決めたアーキテクチャが正常に動作しているかを確認します。
ソフトウェアの品質が低い場合、このフェーズで多くのバグが発生し、開発が遅延します。
総合試験：
最初に決めた要件が満たされているか、実際の利用を想定して試験します。ですので、いわゆるイジワルな試験もこのフェーズで行います。もし、時間があれば発注者の目線で試験に参加することが出来ればソフトウェアの品質が向上します。
発注側として関わる部分として
１：要件定義この要件とは、制作するソフトウェアの骨格となるものです。ですので、ココは発注側がしっかりと意見を言う場です。そして、実現したい機能をしっかり伝えることが必要です。
ただし！
あたりまえですが、盛りすぎると、コストに跳ね返ってきます。
２：概要設計
概要設計の完了により、どのようなソフトウェア構成でシステムを実現するかなど具体化します。このため、実運用でのコストも具体化します。例えば、商用のデーターベースを使った場合、ユーザー数で課金料金が変化しますし、クラウドを使うことで応答性や可用性も変化します。
この段階でレビューを実施することで、 発注側が実際に運用を開始してからどうなるかなど確認する場としても活用できます。また、この時点で具体的な開発工程が見えてきますので、詳細なスケジュールについて合意することも重要です。
３：定例会の開催
定期的に開発進捗を確認する場を設けることをオススメします。よく定例会と言われるものです。２週間に１回くらいは状況確認を行うべきでしょう。もし、当初の予定ではあと2週間で完成の予定が「結合試験に手間取っていて、あと3ヶ月かかります。」と、突然言われても、あまりにも期間が短い場合、ビジネススキームの変更が効かなくなり、お客様に迷惑をかけることにもなりかねません。
その定例会の中でスケジュールに従って、詳細設計や実装、 各試験の状況を確認するアジェンダを設定することで、予定通りなのか、遅延が発生しているのか、問題が発生していないかなど確認できます。
また、実装や試験の途中で画面デザインや動作など確認するようなイベントを設けることで、お互いの齟齬を避けることもできます。
４：納品
最終的な納品の形態を発注時に決めておくことが必要です。[重要]
リリースはコンピューター上で動くプログラム（よくバイナリと呼ばれます）だけですか？ソースコードも含め各種のファイルを納品させる場合はどの様な媒体での納品ですか？ CD-RやDVD-R、あるいはUSBメモリですか？
また、ソースコードのメンテナンスを自分で行おうと考えているならば、最終的なソースコードの説明を行ってもらうべきでしょう。
５：外部のコンサルをポイントでうまく使いましょう。
要件定義の時にビジネスに対して影響のある技術規格を決める、開発が遅れているようだが状況が把握できない、納品形態はどうしたらいいか、概要設計のアーキテクチャが正しいか判断できない、など、わからないコトの明確化や対応など、信頼できる外部の第三者コンサルを活用してください。
最後に：
この、ウォーターフロー・モデルの弱点は、最初に全てを決め、最後にならないと結果がわからない、と言うトコロです。このため、全ての機能をいっぺんに実装するのではなく、最初は最小限の機能だけを実装して仲間内の間で評価し、その結果を少しづつ追加していく手法があり、アジャイル開発と呼ばれています。
次回は、アジャイル開発についてお話したいと思います。
船橋の頭脳
Lightning Brains
コメント
コメントを投稿