HOME


流通工房について

各フェーズ定義


トピックについて

Link


サイトマップ

書籍・プロフィール

サイト内検索

-------------------------









流通業・流通システムにおけるシステム設計の実務ノウハウが満載−流通工房

実装OnePoint!
【画面起動ログ
<吉田君>
 メニューの要件の整理が終了しました。
 主なものとしては商品部や経理、店舗などでそれぞれ使う機能が異なること、そして一部
 店長のみが承認の機能を使うことができるなど役職での制限もあるということなのでログイン
 IDから部署、役職を判断し表示するメニューを変えることにしました。

<早瀬>
 メニューから起動した画面のログも取るようになっている?

<吉田君>
 画面のログですか?考えていなかったのですが


【ポイント】
トピックとしてはフェーズとしては要件定義〜基本設計フェーズ、視点としてはシステム運用
の観点からの内容となります。

ログインの権限制御からメニュー表示までの一連の機能については基本的には要件として
は大きく違いはないので、既に共通機能として各開発会社や企業で用意していることも
多いと思います。

そこで、このトピックはそういった共通機能がない場合、今回のシステムで独自でメニュー
機能を設計する際のポイントになります。

細かい制御パターンについてはそれぞれの顧客により異なるので確認が必要ですが、今までの
システム構築経験から大体部署そして役職で表示、選択できるメニューの制御ができれば要件
としては満たされます。

そして、おそらくここまでは顧客からの要件から設計ができるかと思いますが、もうひとつ
システム運用の観点から重要なのが画面の起動ログです。

これは、メニューから画面を起動した際のログインIDや起動日時をDBのテーブルなどに保存
する機能です。
この情報はシステムがリリースされてシステムを運用していく上で非常に重要な情報と
なります。

大きくは以下の2点です。

1.画面の曜日別、時間帯のピークタイミングの把握
  システム上は負荷が高まれば当然、レスポンスは悪化します。
  また、一方でシステムメンテナンス上どうしても日中にデータの復旧をしたり、また
  業務要件でオンラインバッチを実行することがあるかとおもいます。

  その時に、システムにおいて負荷が一番高い曜日、時間帯を抑えておくことで、その
  タイミングでのデータパッチやオンラインバッチの処理を控えることができます。
  今までの経験でも、システム上の負荷が高いときにオンラインバッチなどを実行する
  と画面のレスポンスが著しく劣化し、オンラインバッチ自体も状況によっては通常の
  倍以上時間がかかったことがあります。

  当然、「画面が一番使われている=システム負荷」の関係式が必ず成り立つわけでも
  ないので、同時にシステム負荷についても監視、把握する必要はありますが、どの時間帯
  に一番使われるかを抑えることは有益な情報となります。

  また、これらの統計情報は、システムリリース後、顧客における店舗や取り扱いデータ
  などが増えた場合のシステム拡張の際の情報にも役立つでしょう。

2.使用機能、未使用機能の把握
  設計時に必須の機能、そして中には必要性がいまひとつわからないが既存システムに
  あるからといったいまひとつ必要性のわからない機能などが出てくることがあるかと
  思います。

  これらはシステムリリース後、実際の画面の使用頻度を見ることで把握できるように
  なります。私のシステム構築の経験上も、情報システムでは必要と認識していた機能が
  実はあまり使われていなかったり、そんなに重要と思われていなかった機能が非常によく
  使われていたといったことが判明したこともあります。

  つまり、どの機能がよく使われているか、使われていない機能はどれかといったことを
  把握することで、リリース後のシステム拡張や、いずれまた来るかもしれない基幹系
  システム再構築の際に実装する機能の判断やより充実させる機能などの判断に役立ち
  ます。

  そして、これも私の経験からですが、あまり使われないイレギュラー機能ほど、それを
  使う現業部門の人が「絶対必要」と主張したりするケースもあります。
  当然、使用頻度が少なくても重要な機能は実装する必要がありますが、あとはそれを
  きちんとしたシステム機能として実装しなければならないのか、あるいはデータを
  DBから取得できるのであればアクセスやエクセルなどで加工するだけでもよいのかと
  いった判断をするための基本情報ともなります。

  顧客においては年間でシステム運用、改修にかけられる予算は限られています。
  一方、基幹系システムに機能としての実装を行う場合は、開発工数、そしてテスト
  がそれなりにかかり、また外部の協力会社に委託する場合はコストも発生します。
  実装の有無、そして必要な場合でもその必要度を判断することは非常に重要です。

  ●もうひとつ重要なポイント=「使われていない機能」
  なお、ここでもうひとつ重要なポイントがあるのですが、
  
  「使われていない機能」=「不要な機能」
  
  と決めつけないことです。
  当然、「不要な機能」もありますが、実は

  「現場の要件にうまくあっていなくて使いづらいから使っていない」

  といったケースもあるからです。

  この「流通工房」のトピックの中でも

  ・「業務の視点での設計」
  ・「実際に使う場をイメージしての設計」
 
  の重要性は伝えてきていますが、どんなに留意していても100%ということはありません。
  ちょっとした画面オペレーション、検索条件、表示データ内容で現場としては「使えない」
  機能となるケースも出てきます。

  そして、そういったことをエスカレートできたり、吸収するような「仕組み」が顧客
  企業にあればよいですが、それがない場合はこういったものは埋もれてしまいます。
  しかし、現場の業務上は必要なのでイレギュラーな業務オペレーションが発生したり
  する原因ともなります。

いつどれくらい起動されたかといった単純な統計情報ですが、上記のとおり非常に有益かつ
重要な情報となります。ぜひ、機能設計の上で考慮するようにしてください。

質問 このトピックの情報は役立ちましたか?
役に立った
目的の情報と異なったが、参考になった
役に立たなかった

コメント




結果