【IT勉強】　デジタルガバメント推進標準ガイドラインよりサービス・業務企画の章だけを読んで圧縮（2記事目）

　政府がシステム開発の参考として公表した「デジタルガバメント推進標準ガイドライン」について、4章サービス・業務企画を読んだので強く印象に残った点を残しておきます。

　※以前、第3章の予算要求は最優先で読み、そちらも参考になったので時間ある方はどうぞ。このブログでも感想残しました。

　該当プロジェクトの達成すべき将来像を描くための工程であり、下記2つを強く意識すべき。

　①利用者のニーズ把握

　②現状の業務把握

　成し遂げたい事の手段としてシステムを作るのであって、利用者に何を提供するものかそこを考える事が大事。

　利用者の事を知るべきであり、利用者の種類や人数を把握する

　個人か法人か、本人か代理人か、地域・年代・性別・知識差など属性を考慮

具体的にどんな人が利用者か把握するためには、

　・現在のサービス利用時の現地見学・調査

　・ドキュメントやマニュアル

　・ログデータ等の洗い出し

などが手法がある。

　詳細把握は難しいので規模感を掴むことに集中する。既存サービスから類推できればベターだが、難しいときは仮説をおいて類推する。

　・既存サービスからの類推

　　業務データからの類推、現場でのサンプリング調査、一般的な統計からの類推など

　・仮説による類推

　　類似のサービスからの類推、アンケート調査、利用者を仮定し算出など

　上記で類推した利用者の種類や人数からサービスを多く使うであろう典型的なユーザをイメージする。イメージした人がもしサービスを使う時に何があればうれしいのか、ないと操作できないのか、検討を行う。※ペルソナ分析という。

　現場を見て事実を把握すること。

　1日平均や曜日平均から踏み込み、何時のアクセスが多いのか、また何曜日のアクセス数が多いのか把握する。それにより、負荷の平準化を図るために、必要な人やコンピュータリソースを用意して、負担が大きくならないように平準化を行う。

また、ユーザ毎のアクセス数も見て特定の利用者やサービスに大量のアクセスが見受けられる場合は、その部分への個別の対応（専門ページや人員等）を検討する。

　いつ、どのくらいにピークとなっているのか把握し、それをオーバしないようにする。リソースよりも、まずは上で述べた標準化等でピークをなだらかにするように考える事が最初。

　ローカルルールにより、システム導入後に現場で使えないと反発を受ける事がある。それを避けるためにも、そもそも業務手順を標準化しておくべきである。しかし、ローカルルールが誕生する必要があった理由や背景はあるので、全社的に１つのやり方に縛り付けるような一本化に拘る必要はない。

　納得できるだけの効果や理由があるなら、それも標準的なやり方だと関連者が把握した上で、それをシステムとして実現するようにする。

　現場担当者にヒヤリングする際に、協力をもらえない事が多いそうです。なぜなら、何故非効率な事をそもそもやっているのか、発言した事の証跡としてデータ提供してほしいなど宿題をもらう、など、余計な責任追及される事を避けるため身構えてしまう事が大半です。

　プロジェクトの意義をしっかり説明して、担当者にもメリットがでる旨を伝える事は常に意識して実践しないと、本音は引き出せないとの事です。

　※担当者の立場で考えると直属の上司から睨まれたくないので、上司の上司から必要性を説明して理解してもらった上でヒヤリングしてほしいですね。自分が改善側なら担当者と上司にも背景を丁寧に説明するようにすべきですね。