スケジュールの立案について2:プロジェクト計画を立てよう2

前回の記事で、プロジェクト計画立案のステップを3つ定義しましたが、今回はそのステップ1:リリース後イメージの明確化の詳細について記載したいと思います。

ステップ1:リリース後イメージの明確化
ここでは対象とするシステムがリリースされる時、およびリリースされた後のイメージを明確化します。要するに「このシステムはどのように立ち上がって、その後どのように利用/運用されていくのか?」ということです。

1: 目的(ゴール)の明確化
兎にも角にもこれが何より大切です。目的が明確かつ関係者で共有されなければプロジェクトは迷走しメンバーもどんどん疲弊していきます。
逆にいえば目的が明確化されていないプロジェクトは決して始めてはいけません。そのぐらいの意気込みで目的明確化に注力してください。なお目的明確化の詳細については以下の記事をご参照ください。
プロジェクトの目的/ゴールを定義しよう

2: 機能要件の明確化
目的を達成するためにどのような機能を実装するかを明確にします。もちろんこのタイミングで詳細な部分まで明確はできないと思いますが、少なくとも概要レベルでは明確化しておきたいところです。
ここで押えておきたいのは、リリース前後で「誰が」「どういったシーンで」「利益を得るのか?」という点です。ちょっとレベルが詳細すぎますが、記載イメージを以下に示します。(その他ユースケース図なども活用できると思いますよ)

機能名利用シーン現状リリース後
顧客情報検索機能注文伝票入力時顧客台帳で顧客番号を確認し、注文画面に入力する顧客名を入力することで顧客マスタを検索し表示されたリストから該当顧客を選択する

3: 非機能要件1:サービス提供に関する要件の明確化
当システムのユーザー向けサービス提供要件を明確にします。具体的には以下のような内容です。
・サービスが利用できる時間帯(24時間365日とか、営業日の9時から18時までとか・・・、海外ユーザーがいる場合などは特に注意)
・レスポンス(中々コミットしづらい項目ですが、意識はする必要があります)
・システム停止条件(メンテナンスや法定点検などで不定期に停止せざる得ない場合の条件)

4: 非機能要件2:異常事態への対応に関する要件の明確化
当システムに対する異常事態への対応について要件を明確にします。具体的には以下のような内容です。
・ユーザー誤操作への対応(ユーザーが誤ってデータを消した場合など)
・システム障害発生時の対応(データやシステムの二重化要否)
・災害発生時の対応(災対環境の要否)
・セキュリティインシデント発生時の対応(不正侵入やデータ漏洩の疑いがあった場合の対応)

5: システム概要(サーバー構成、ネットワーク構成、ミドルウェア構成など)の想定
機能要件、非機能要件から必要なシステム機器およびその構成について想定します。また、外部システムとの連携が必要な場合もこのタイミングで明確化しておきます。

6: 運用イメージの想定
このシステムがリリースされた後、どのように運用されるかを想定します。具体的には運用に必要となる体制や工数などです。どんなに良いシステムがリリースできたとしても、その後の運用が滞ってはシステムが本来の有効性を発揮できなくなります。想定した運用イメージが受入難いものだとすれば、
・運用を軽減するツールや仕組みを導入する
・運用体制を強化してもらう
・運用インパクトが高く、有効性が低い要件を削る
などの対応を考えます。

7: リリース作業の想定
システムがリリースされるタイミングでの作業について明確化します。リリース作業が上手く行かなければそもそもシステムとしては成り立ちませんし、仮にリリースできたとしても「システムに対する悪い印象」にもつながってしまいます。具体的には以下のような点を確認しつつリリース作業を想定します。
・ユーザーへのサポート内容(マニュアルの整備やユーザーへの教育実施の要否など)
・既存システムへの影響(リリース作業中に他のシステムを停止しなければならない、他システムの設定変更が必要など)
・データ移行方法について(データ移行が必要なケースでは必須、データ移行のための一時的なツールの導入も検討する)
リリース作業がスムースに行かないと想定された場合は、機能要件を見直すことも検討します。

とまぁ、考えなければならないことはいっぱいありますが要は、
・誰がハッピーになるためのシステムなのか?
・そのシステムは想定ユーザーをハッピーにできるのか?
・そのシステムはリリース後適切に運用できるのか?
・そのシステムはスムースにリリースできるのか?
を考慮するっていうことになります。


コメント

タイトルとURLをコピーしました