2019年7月に入社をして、8月に入ってようやく自分の仕事ができました。
顧客向けサービスを大規模に変更することになったので、その変更の要求定義です。
期限は一週間・・・???・・・???
超感覚的な規模感は数億円。それを1週間って・・・
無茶ぶりにも負けず、とりあえず1週間で要求定義書を作ったけど、最終的にユーザー部門との合意までには2週間かかりました。それでもようやく即戦力として認められるようになってきて、居場所ができた感じでほっと一安心。IT子会社とベンダーに要求定義の内容を説明して、見積り依頼をしたら、またやることがなくなって8月後半は読書の日々に逆戻り。
要求定義は自分の得意領域だけれど、今回の要求定義で新鮮だったのは、エンハンスの要求定義なのに現行システムのことを全く知らないこと。今までのエンハンスの要求定義では、現行システムを知っている中でやっていたので、部分部分では意識的にも無意識的にも手段を記載していることも多いのが現状でした。
例えば、
「店舗にある商品の在庫が店舗の中のどこにあるのかを把握したい」
という要求があったとすると、要求定義書には
①在庫管理テーブルのキー項目追加
店頭にあるのか店内倉庫にあるのかを把握するために、在庫管理テーブルのキー項目に場所区分(店頭/店内倉庫)を追加して、店頭の在庫と店内倉庫の在庫を区別できるようにする。
②店内倉庫への入庫
店舗への納品時の検品をした場合、店内倉庫に在庫を計上する。
現行 :○○店ー商品A 100個 +10個
変更後:○○店ー店内倉庫ー商品A 100個 +10個
③店内倉庫からの出庫指示
今までは紙の出庫伝票を起票していたが、在庫管理システムで出庫のエントリーをするように変更する。
④店内倉庫からの出庫時の検品
店内倉庫から出庫する際には、在庫管理システムでエントリーされた出庫指示にもとづき、検品システムで検品を行い、店内倉庫から店頭に在庫を移動する。
○○店ー店内倉庫ー商品A 100個 ー5個
○○店ー店頭ー商品A 10個 +5個
⑤売上が上がったら、店頭在庫から在庫をマイナスする
現行 :○○店ー商品A 100個 ー1個
変更後:○○店ー店頭ー商品A 10個 ー1個
と、こんな感じで具体的な改修方法等を含めて書いてました。
それが今は現行システムを全然知らないので、ある意味、システムに縛られない純粋な要求定義書を作ることができました。一応、プロとして非現実的な要求定義書にはしていないつもりだけれど、現行システムを知らないだけに、どんな見積りが出てくるのか、ドキドキして待っています。
(そもそも現行システム知らないのに、見積りの妥当性なんて評価できるのか???)
そんな感じで、今月は前半は多少忙しかったけど、後半はひまひまだったので、残業時間は12.5時間。
7月 12.0時間
8月 12.5時間
今のところ、社内SE楽伝説は健在です。