要件定義フェーズ
要求の内容を基に、具体的にシステムで実現する機能を明確化するフェーズです。
ベンダーが要求定義書を基に要件定義を行うフェーズで、ベンダーと本格的に仕事が始まります。
システムを初めて導入する場合などは、ベンダー側の業務のやり方に慣れるまでとまどう可能性がありますが、コミュニケーションルールを作ってお互いによく情報交換しましょう。
システムを構築するためには大量の文書を作成します。
見えないプログラムを見える化して合意する。
そのやり方に早く慣れましょう。
ベンダーへの要求説明
要求仕様書を基に、ベンダーに要求の説明をします。
要求仕様書は基本文字で書かれているので、詳しい説明が必要な場合などは、詳細な説明資料を別途作成する必要があります。
ベンダーに要求を正しく理解してもらわないと、この後のシステム開発で誤った設計がされて後戻りの原因となります。
ベンダーが理解するまでしっかりと要求の内容を伝えましょう。
また、説明した内容に対してはベンダーから多くの質問が来るので、それらの質問に丁寧に回答しましょう。
この説明の中で、作った要求がシステムは実現できないなど、想定と違っていることが分かる場合があります。
要求を取り下げるや、要求を変更する必要が出てきますので、速やかな対応が必要になります。
変更に対して、プロジェクト内で合意が必要になるので、その時間を確保しておきましょう。
仕様検証
要求した内容が、本当に実現可能かどうか、効果を技術的な観点から検証します。
できれば、ベンダーに検証するための環境を用意していただき、実際のシステムを使って要求した内容が実現可能なのか、想定した効果は果たしてあるのかを確認します。
実際の環境を使って検証する場合は、検証するためのデータや、検証のためのシナリオの準備が必要です。
ベンダー側の準備期間も必要なので、十分な時間を取って準備しましょう。
「要求した内容が本当にできるのか」が分かる重要な作業です。
ベンダーからの要件説明
ベンダーが作成した機能仕様書を基に、ベンダーから説明を受けます。
要求仕様書によってシステムに要求した内容が、開発されるシステムにどのように実装されるのか、システムがどのような機能を持つのかがわかります。
アドオンをしないシステムであっても、最近のシステムは設定によって機能を作ったり、変更したりできるので、構築する機能の設定項目はシステムの規模によっては何千、何万項目にもなります。
また、機能にはシステムが動作する機能以外に、サーバーの性能や信頼性、拡張性、運用性、セキュリティなど、機能面以外のもの全般を定義する「非機能要件」があります。
こちらの確認は社内のIT部門にお願いしましょう。
ベンダーからの要件説明によって、導入するシステムがどのようなものになるか、具体的に見えてきます。
分からない部分があったらこの段階でベンダーによく確認し、明確にしておきましょう。
要件合意
プロジェクト内で出来上がった機能仕様書の内容を合意します。
これによって、今回開発されるシステムの仕様が最終決定されます。
機能仕様合意の説明の対象は、プロジェクトに参加する全員になります。
プロジェクトに参加するメンバが、会社経営者から他部署、他事業所と広範囲になっている場合は、そのレベルに合わせた説明資料を作成し、説明会を開催することになります。
資料作成、説明会と段取り良くやらないと時間がかかりますので、事前の準備をしっかりと行ってください。
説明会では、システムの導入によってユーザの業務に特に影響がある部分を丁寧に説明して下さい。
システムを導入した段階で「聞いたシステムは、こんなシステムでは無かった」とならないように、ユーザに理解してもらうように分かりやすく説明する必要があります。
この段階で、プロジェクトの半分の９ヶ月が経過します。
全体を俯瞰していただくと分かる通り、プロジェクトの前半は要求、要件を決めるフェーズであり、システムを開発しているわけではありません。 いかに開発前の仕様決定が大事か、分かっていただけるでしょうか。
システム開発見積もり
決定した機能仕様書を基に、この後の設計、プログラミングフェーズの見積もりをします。
この後のシステムを開発するフェーズはほぼベンダーの仕事となります。
要件も決定したので、システムの開発規模が明確になります。
要件定義を行う中で開発する内容が明確になり、要求定義段階の見積もりから変更が入るので、この後にかかる費用を明確にします。
この段階の見積もりで、システム開発のほぼ大方の見積もりが終わり、全体費用の概算が分かります。最終的な費用が当初計画の費用に収まるか、非常に重要な作業になります。
この見積もりでは費用がオーバーすることが多いので、費用を削減するために仕様の見直しが入る場合があります。
仕様を変更するためにはプロジェクト内の合意が必要になるので、時間がかかる場合があるので十分注意してください。
設計/プログラミングフェーズ
ベンダーがシステム開発をするフェーズです。
どうしてもシステム開発を依頼する側からは見えにくい部分が多くなります。
よって、日程がベンダーの開発状況によって左右される可能性が出てきます。
ベンダーにお任せ、にならないように十分注意しましょう。
ベンダーと一緒になってシステムを作る、そのような意識を持って、ベンダーと一緒になって立ち上げて行きましょう。
ベンダーの日程管理
設計/プログラミングのフェーズはほぼベンダーの仕事となるため、プロジェクト側は放置しがちです。
日程が計画通りに進んでいるかはベンダー任せにするのではなく、一緒になって確認しましょう。
多くあるのはベンダーがが下請けを使い、その下請けがまた下請けに仕事を依頼する階層構造になっています。
システム開発の段階では子、孫、ひ孫、その下までの会社関係になる場合があります。
どうしてもベンダーから先の業務が見えにくく、その部分で何らからの不具合などが発生すると、表面化するまでに時間がかかる場合があります。
「気がついてからでは遅い」そう思ってベンダーの日程管理を行ってください。
そのためには細かな日程確認のルールが必要です。
コミュニケーションルールを徹底しましょう。
設計書の確認
プロジェクト側にIT部門がない場合でも設計書の確認を行ってください。
「専門的なことだから分からない」とは言わず、設計書名と設計書に何が書かれているかの簡単な説明だけでも結構なので、ベンダーに説明してもらってください。
ある程度まとまって説明してもらってもけっこうですが、最低でも一週間に一回は設計書の確認を行ってください。
これを行うことによって、少なくてもベンダーの業務量が分かります。
作成している設計書の項目名からだけでもシステムの概要を理解することができます。
何が書いてあるか詳細までは分からなくても、どのようなことを設計しているか概略が分かります。
この設計段階の説明を受けることによって、障害発生時など、障害の状態や原因を説明してもらった際にシステム内部でどのような事が起こっているのか、概要を理解できるようになります。
是非ベンダーに時間を取ってもらって、設計書の説明をしてもらってください。
設計変更対応
設計を進める中で、どうしても設計上の不具合が出てきます。
特に、導入するシステムがベンダーが扱う最新のバージョンだったり、新しい機能を初めて使うなど、ベンダーにとって新規の機能は要注意です。
設計を進めるうちにベンダーがシステムの開発メーカーとのやり取りをしている中で、思わぬ設計の不具合が見つかる場合が多くあります。
これらの不具合は全く無くすことはできません。
不具合が無いシステム開発は有りません。
不具合対応にかかる時間を予め準備し、その際のプロジェクト内で合意を得るための手順も準備してください。
しかし、その不具合の対策が設計変更だけでは対応できず、要件、要求の変更まで至った場合はプロジェクト全体の日程に大きく影響する可能性があります。
そのような重大な事態に陥った場合は、焦らず、プロジェクト全体を俯瞰した上での対応をお願いします。
でも、そのような重大な事態に陥る可能性があるのもこのフェーズです。
ユーザー教育準備
システムを導入する前にはユーザーの教育が必要です。
ユーザー教育の準備期間はそのシステムに登録されるユーザーの数にもよりますが、1,000人規模のユーザーになる場合は、組織をまたいだ教育体制の構築も必要となります。
また、教育の形も、集合教育、実際のシステムを使ったハンズオン教育、e-learningなど色々とあります。
それらの中から効果的な教育を選び、教育のための資料の準備をしなければなりません。
教育の準備で大変なのは、システムの開発と同時進行で教育資料を作るので、実際のシステムのスクリーンショットを撮って資料を作った場合など、システムに変更が入ると、教育資料も同時に直さなければならないことです。
システム開発側と連携を取って進めなければなりません。
また、システムの操作方法などは実際のシステムを動かしながら教育資料を作る必要があり、そのための環境の準備なども必要です。
教育の準備は思ったよりもかかります。 要件定義でシステムの仕様が決まったら、すぐに着手しましょう。
運用/保守準備
稼働後のシステムの運用体制と、保守体制の準備をします。
システムの運用体制としては、ユーザーからの問い合わせ対応、ユーザー教育、ユーザー登録、システム、システムを使った業務の改善活動などが挙げられます。
これらの活動を継続して実施する体制と、これらの業務を行うための手順書の準備が必要です。
保守体制としては、定期的なシステムのメンテナンスや、OSの脆弱性に対する対応、障害発生時の対応などがあります。
社内のIT部門に依頼したり、ベンダーに継続して保守を依頼するなど外部との調整が必要となる場合があります。
システムが稼働してから、運用、保守体制ができておらず、システムに何らかの障害が発生して業務が停止するような状態にならないよう、準備が必要です。
プロジェクトはどうしてもシステム導入までには力を注ぎますが、システム導入後の維持活動は忘れがちです。
導入後にシステムの維持体制が不十分で、右往左往しないように注意しましょう。
テストフェーズ
単体テスト、結合テスト、システムテスト、設置テスト、受入テストなどシステムの規模や開発するベンダーによって、様々なテストがあります。
テストは実際にテストするよりも、その前の準備段階に時間がかかります。
テストしてみたらあのデータが足りない、あの業務も確認しないとだめだ、などとならないように、十分な準備が必要です。
テスト準備
テストは大きく、単体テスト、結合テスト、システムテスト、受入テストがあります。
これらのテストの詳細は別途説明しますが、テストだけでもこれだけの数があると言うことです。
開発されたシステムを導入前にテストして、不具合がない状態に持っていきます。
これはベンダーの仕事ではなく、ユーザー側の仕事だと思って取り組んで下さい。
「システムのテストはベンダーに任せておけばいいや」と思っては絶対にいけません。
ユーザー側が真剣にテストを実施し、導入前に一つでも不具合を見つけ、対策しなければなりません。
テストは不具合が出ないことが良いことではありません。
開発されたシステムには不具合がいくつもあります。
不具合が無いシステムは有りません。
絶対に不具合が入っていると思ってテストをして下さい。
よって、テスト結果が不具合0は失敗テストだと思って下さい。
テストの準備期間にはテストシナリオの作成、テスト環境、テストデータの準備、などがあります。
テスト要員分のテストデータの作成は大変時間がかかります。
新規にシステム内にデータを準備するので、手作業でデータを準備する場合もあります。
大変時間がかかる地道な作業が発生するので、どのようなテストを行い、そのためにはどのようなデータが必要か、よく確認し準備してください。
テスト実施
テストの役割はシステムを開発するベンダーの開発手順によって、違う場合がありますが、単体テストはプログラム開発と同時進行でベンダーが実施します。
結合テストはプログラム開発後にベンダーが実施します。
システムテスト、受入テストはユーザー側のテストになります。
受入テストは実際に業務を行うエンドユーザーに参加してもらって行うので、テストが段取り良く進むように入念な準備が必要です。
テストではテストのやり方に疑問を持って、テストを実施する人が質問をしてくる事が多いので、予め質問を受ける人を用意したり、テストをする人の様子を見て、困っている人には手助けをするなどサポートする人が必要なので、それらの人の準備も必要です。
準備ができておらず、テストが全て時間内に完了しなかった、などにならないように注意しましょう。
障害対応
テストを行うと、絶対に不具合が見つかります。
発生する件数にもよりますが、発生した不具合を影響範囲を特定しながら対応を進めます。
基本はシステム導入時には不具合0です。
どうしてもシステム導入までに対応が間に合わないものに対しては、業務上の影響度合いによって対応時期を判断する必要があります。
不具合があるから即導入延期とならないように注意してください。
導入が延期になるということは、費用がかかります。
プロジェクトの予算が守れなくなる可能性が大きいので、安易に導入延期をしてはいけません。
障害対応は、発生時に即対応ができる体制をベンダーと一緒になって作りましょう。