既存業務をシステム化しよう⑤
この記事では、業務改善の取り組みとして、ITを導入した事例の実体験を複数回に分けて書いています。この取り組みは現在進行形で進んでいる内容です。私自身の取り組みや振り返り、次に活かしたいことなども含めて書いていきます。今回は、進んだ要件定義の後の開発途中の画面確認や、途中で改めて確認が必要になった機能要件、また非機能要件についてです。
関連記事
既存業務をシステム化しよう①
既存業務をシステム化しよう②
既存業務をシステム化しよう③
既存業務をシステム化しよう④
既存業務をシステム化しよう⑤
既存業務をシステム化しよう⑥
既存業務をシステム化しよう⑦
（IT用語）既存業務をシステム化しよう
（システムの改修を考える） 既存業務をシステム化しよう
既存業務をシステム化しよう⑧
開発途中の画面
モックと呼ばれる画面イメージの確認です。画面がどんなイメージで作られているのか、またボタンを押すとどんな画面に遷移していくか、機能ごとに確認していきます。
時間を多く取って進めたのはステータスについてです。ステータス遷移はかっちり決まっていなければいけませんが、遷移の条件が複数あったり、条件が整っていなくても進めるステータスも混在したりと難航しました。
ベンダー企業の方は本当に優秀で、十分でなかったであろう説明から必要な機能を抽出し、また類推して開発を進めてくれていました。
ステータスについては、下の階層に「イベント」というアクションを設けることで、遷移条件を整えていきました。
モック画面確認は、認識のすり合わせやUIの面で重要です。実際に業務を行う現場間を持った担当者とベンダー企業の業務イメージは不一致も多くあります。特にどこで間違いが生じやすいか、そのためにどのような画面である必要があるかのコミュニケーションは納品後のシステム安定稼働に関わるため、早いうちに潰しておく必要があります。
モック画面や機能要件の再確認で、開発していくシステムのブラッシュアップが行われ、時に手戻り、場合によっては追加機能扱いとなり新たな費用が発生する事があります。その時は納期・稼働日についても確認することになります。
開発と同時並行で進んでいくため、こちら側も意思決定スピードを上げる必要がありましたが、ベンダー企業にとっても最も労力のかかる期間だったと思います。
非機能要件
目に見える機能に対して、裏側でどのようにシステムを稼働させるのかを決めるのが非機能要件です。
これはシステムの専任担当者でないと理解が難しい内容です。サーバー構成図の確認やファイルの流れ、レスポンススピード、バックアップ、運用、セキュリティなどについてなどです。
ヒアリングされる内容としては、瞬間で最大どれくらいのアクセスがあるか、サーバーがダウンした際の復旧に要しても良い時間、セキュリティレベル、取り扱うデータ件数、容量などです。
ドメイン、SSLの設定、セキュリティ診断、ウィルスチェックソフトの選定なども非機能要件に含まれるでしょうか。
非機能要件はメイン機能ではないものの、継続してかかる運用保守費用と密接に関わることから、程度を判断するのは発注側の私たちになります。一方で、ではどの程度が適切なのか。これはIPAの基準などを参考に、と言われますが、指標などを見てもよくわからないのが実際のところ、という感触です。結局はベンダー企業の提案を聞き、気になる点を指摘して、改めて提案をもらいその中から選択することになると思います。より経験豊富なPMさんだと自社の求めるレベルと予算に見合ったものを提案してくれるのだと思います。
システム稼働のための準備
開発はいよいよ大詰めで、発注側の私たちも稼働に向けて準備を進めます。
項目としては、
①既存システムの改修
これはデータ連携のためで、必要なデータファイルの吐き出しと取り込み機能です。
②データ連携環境準備
これも①と関わりますが、既存システムを扱う業者と打ち合わせを行い、ファイルをやりとりするためのフォルダの準備やパッチを動かすタイミングなどを決めていきます。
③移行データ等の準備
実際に稼働するシステムは中身のデータは空っぽなのであらかじめ取り込むべきマスタデータや案件データを取り込みます。手作りのAccessデータベースから取り出し、それを取り込める形に加工して渡す作業です。双方に確認が生じたりと手間のかかる作業でした。
④AWS等契約手続き
サーバーの契約やセキュリティ診断の契約です。ベンダー企業に代行をお願いしているので、送られてきた契約書類を確認して提出するだけでした。
次回はいよいよシステム納品です。
検証によるバグ発見や委託先、顧客向けの資料作成など、実はここからが大変ともいえるフェーズ。
= to be continued ⇒
この記事が気に入ったらサポートをしてみませんか？