ユーザーインターフェースの重要性

最近、ＩＣＴ系雑誌などで、システム開発時におけるユーザーインターフェースの重要性についての記事を頻繁に見かけるようになりました。

私は、ユーザーインターフェースについては、想定外のデーター入力が発生する場合などの他は、ある程度はユーザー側の我慢も必要であるという考え方を持っています。
よって、例えばシステム構築プロジェクトのキックオフミーティングにおいて、その考え方をお伝えするケースもありました。


しかし最近、スクラッチ開発の小規模システムにおいて、ユーザーインターフェースが何となくスッキリしないシステムの機能追加やリメイクに関係することになりました。

その時に幾つか、あらためて痛感したことがありました。


まず顧客との応対中に情報検索や伝票入力を行うような利用シーンのあるシステムにおいては、やはりユーザーインターフェース次第で、リアルタイムにシステムが活用されないケースが発生し得る、ということです。

このことにより、例えば顧客満足度や顧客応対可能件数の向上などの戦略的効果が半減してしまうなど、かなりの影響を与えます。

このようなケースの場合、まず徹底してリアルタイムの活用を実施するように教育を行うべきですが、最終的には画面構成を見直す必要性が生じるものと思われます。
また例えば、そもそもの設計思想として応対途中で運用することが十分にイメージされないまま開発されているなどの場合には、一部の画面については新たに作り直すことも検討すべきかもしれません。


次に情報系システムについては、分りづらい、操作しづらい画面構成の場合には、使われない可能性が非常に高い、ということです。

情報系システムの構築目的としては、例えばマーチャンダイジングの見直しや顧客ロイヤリティ向上などに必要な情報を瞬時に活用できるようにするなど、
戦略的意図が必ず含まれているものと考えられます。
情報系システムが利用されないということは、その戦略的意図の未達成に直結します。

これについても、ユーザー教育で解消する場合もありますが、やはり、設計段階で十分にユーザー視点でも検討されることが重要だと思います。


以上のように、
単なる伝票処理の効率化や重複入力の排除など、一昔前におけるシステム化の目的ではなく、
システム活用によるより戦略的な効果を得ようとするケースにおいては、特にユーザーインターフェースを重視する必要があると、私はあらためて感じているところです。


＜関連記事＞
「超上流工程からシステム運用テストまでにおける考慮事項」

システム化の目的を伝える（その2）

以前「システム化の目的を伝える」という記事におきまして、
システム化の目的を繰り返し伝えることの重要性などについて記載しました。

それに関連して「システム化の目的を理解し浸透させる中心メンバー」の重要性について、、最近、再認識しました。
今回はその件について、少し記載したいと思います。


よくよく振り返ってみますと、幾度も同じような体験をしているのですが、

最近、あるシステム化について、ユーザー部門向けに概要を実施した時、（予想どおりに）批判的と思われる意見が出されました。
批判的な意見が一つ出ますと、そのような空気が流れ、誤解に基づく意見やあまり関係のない意見まで飛び出すようになります。

ちなみに私は、このようなことは良く発生し得る状態であると、あらかじめ覚悟していますし、そのような意見を無理に出ないように進行することも好ましくないと思っています。
（いずれは通らなければならない過程なのですから）

そのような批判的と思われる意見の直後に反論？すると、逆に紛糾するような事態も起こります。
よって、冷静になって、先ずは相手の意見の真意を理解すること、そのような態度をとり続けることが大切であると、私は考えています。

そして、そのように議論が進んでいきますと、
そのシステム化検討に参画した中心メンバーから、いろいろと背景や目的について（うまく噛み砕かれた）再説明がなされ、
更に議論が進みますと、最終的には「まあ分かった。協力しよう。」ということで合意形成がなされていきます。


「それは当然のこと」と思われる方もいると思います。
「そのようにうまくはいかない」と思われる方もいるかもしれません。
「そもそも、ユーザ部門から事前に批判的意見が出るような状態は問題である」という風にとらえる方もいるかもしれません。

いろいろな経験や思いがあるかもしれませんが、
私はシステム化の検討に参画したメンバーが、共通認識をもって、システム化の目的や必要性、現状の問題意識などを語れる状態にしておくことが、大変に重要であると思っています。
そして、そのメンバーが責任感を発揮し、現場への浸透を図ることが、システム化の成功要因の一つであると思うのです。


プロジェクトリーダーまたはアドバイザーの立場である私が「伝えたい」と思うことを、
その検討メンバーが、責任感ある顔で、一生懸命に、自分の言葉で、ユーザー部門に向けて語っている姿を見ますと、
とても頼もしく、また、嬉しい気分になります。


＜関連記事＞
　システム化の目的を伝える
　超上流工程からシステム運用テストまでにおける考慮事項

システム化の目的を伝える

最近、あるプロジェクトにおいて、一般利用ユーザー向けの操作説明会が実施されました。
それに関連し、あらためて感じた事項について、記載したいと思います。

それは、一般利用ユーザーへ「システム化の目的を伝える」ことについてです。


一般利用ユーザーがシステムの本番利用までに、そのシステムに関する説明を聞く機会はどのような場面でしょうか？

　　①システム化プロジェクトが発足したことと、その計画が組織内へアナウンスされた時
　　②プロジェクトメンバーから検討中の仕様に関する確認や意見を求められた時
　　③システムの仕様が確定したことと、その内容が組織内へアナウンスされた時
　　④仕様変更が必要になったケースにおいて、その理由や内容の説明がされた時
　　⑤操作説明を受ける時
　　⑥新システムへの移行方法の説明を受ける時

概ね上記のような感じでしょうか？

そのうち、一般利用ユーザーが集合型て説明を受けることが特に多いのは、
⑤の操作説明会　ではないか？と私は考えています。

このような集合型でシステム化に関する説明を実施する機会におきましては、
私は必ず「システム化の目的」を十分にご説明いただくようにアドバイス等しています。

これを当然のことと思われる方は多いと思います。
しかし実際には、このようなシステム化の機会に慣れていないために、それが十分になされていない（または全くなされない）ケースが見受けられます。
また「以前に各部門の責任者から説明されているはずだから、その必要はないだろう。。。」
という風な理由から、その説明を省略するケースも見受けられます。

この「システム化の目的」が十分に説明されていない場合、「やらされ感」や「批判的な意見・態度」が表面化し、システム移行時の混乱に拍車をかける要因になる可能性もあります。


以上のようなことから、私は（あまり考え過ぎずに）、
集合型や各部門の定例会議などで新システムの説明をする機会などにおいては、必ず「システム化の目的」を冒頭に説明されることをお勧めしたいと思います。

プロジェクト計画書には、必ず、システム化の目的について記載されているページがあると思います。
それを用いて説明するだけで十分です。

「それは以前も聞いたからいいよ」とか「また同じことを言って・・・」という風な反応があるかもしれません。
しかし、繰り返し説明し過ぎて損することはありません。
その説明回数分だけ、「システム化の目的」や意義が組織内に浸透していくものと思います。


＜関連記事＞
　システム化の目的を伝える（その２）
　超上流工程からシステム運用テストまでにおける考慮事項

プログラムマネジメントの有効性（その2）

以前、「プログラムマネジメントの有効性（その1）」という記事で、「プログラムマネジメント」について少し紹介しました。

最近、このプログラムマネジメントの考え方は、非常に有効であると感じるようになりました。
今回、その考えについて、少し記載したいと思います。


現在、製造業などにおいては、「アジアを内需」として取り組む戦略が功を奏し、継続的に業績が回復している状況です。

しかし、本当の内需である日本国内においてはどうでしょうか？

内需系の小売・サービスは、とても厳しい状況です。
対前年比５％、１０％のダウン、という状況が継続しています。

これは、「アジアを内需」として成功する企業が増えても、特に変化しないように感じます。
理由は、「企業の国際化・現地化」進行の観点をプラスした場合、「日本国内の就業者」の所得にあたえるインパクトはごく一部に限られる、と私は推測しているからです。

その中で、小売・サービスなどの内需系企業はどう対応していけばよいのでしょうか？


おそらく、従来型の市場が自然に大きく成長することは無いと思います。
とすれば、景気循環を期待していても所謂ジリ貧の状態になっていく、という風に予測するべきである、と私は思っています。

その中で、最悪のシナリオを考えた場合、固定費を削減し基礎体力をつける、という考え方に至るかもしれません。
しかしそれは、「給与」や「人員」の削減が対策となる場合が多く、それのみでは、企業の活力減退を促進してしまい、更なるジリ貧に拍車をかける恐れがあります。
よって、現在、「余剰」となっている固定費を削減し辛いという現実がある、と私は思っています。
（ただし体力合戦に勝利することで、競争他社が脱落し、市場シェアを獲得する、という戦略・考え方も有効であると、私は思っています。）

そこで、プログラム・マネジメントの考え方を適用してみたい、と私は思うのです。
（突然、思考が飛躍したような印象を与えるかもしれませんが、ご了承下さい。）

ちなみに「プログラムマネジメント」とは、
「新版Ｐ２Ｍプロジェクト＆プログラムマネジメント　標準ガイドブック」（企画：日本プロジェクトマネジマント協会／編著：Ｐ２Ｍガイドブック改訂委員会／発行：日本能率協会マネジメントセンター）
におきましては、
「全体使命を実現する複数のプロジェクトが有機的に結合された事業である」と定義されています。


ここで、先ず「全体使命」をどう課題設定するか？が重要だと、私は思います。

例えば「景気動向や企業環境に適合するための筋肉質の体に」という課題設定は、所謂「ダイエット」ですので、「削減」という対策のみが重視される懸念があると、私は思います。
その「削減」という「全体使命」に対して、組織が前向きに一体感を持って取り組むことは、なかなか難しいと思います。

そこで、もう少し上位の概念を念頭に置く必要性が高いと思います。

それは、「顧客価値の向上」だと思います。

ちなみに私は、「顧客価値」を次のように定義しています。
「顧客価値とは、自組織が顧客（注）に対し、製品・商品やサービスを通して提供している、または提供しようとするベネフィットを定義したもの。なお、そのベネフィットの対価から得られるキャッシュにより、自組織は維持・成長できなければならない。」

この「顧客価値の向上」に向けた施策・プロジェクトの一つとして、「固定費」や「無駄」など、何らかの「削減」を目標としてかかげ、
更に、具体的に「顧客価値の向上」に直結するような施策、または、その「施策を検討する」施策を実行する、
そして、それらの関係性を明示する、
という風に取り組む必要性があると、私は思っているところです。

繰り返しになりますが、さまざまな施策・プロジェクトが最上位の「全体使命」の目標達成に全て関係付けられ、
「顧客価値向上プログラム」として、具体的に計画し実行する、
という活動・取り組みの必要性が、特に内需系企業に高まっていると、私は思うのです。

なお、一つのプログラムとして、各施策・プロジェクトの因果関係を分析・整理したり、また整理・統合する際には、バランス・スコアカードの「戦略マップ」の考え方を取り入れることをお勧めします。


「顧客価値の向上」についてあらためて検討してみて、その中で、必要な施策・対策を決定していく、
その中には、厳しいプロジェクトもあるかもしれないが、それらの目標を達成することで、新たな成長シナリオが見えてくる、
それらを認識した上で、組織が一体となって「顧客価値の向上」に向けたプログラムに取り組んでいく
という方向性で、内需系企業は活力と成長を獲得してほしい、と私は祈念し、そのような民間企業ご支援していきたいと思っているところです。


＜関連記事＞
　プログラムマネジメントの有効性（その1）
　〔参考図書〕バランス・スコアカード

　超上流工程からシステム運用テストまでにおける考慮事項

新版 P2Mプロジェクト&プログラムマネジメント標準ガイドブック 日本プロジェクトマネジメント協会 日本能率協会マネジメントセンター このアイテムの詳細を見る

システム切り替えは慎重な対応を（その2）

あるプロジェクトにおいて、新業務への移行時期が近づいてきました。
以前の記事　「システム切り替えは慎重な対応を」　でも記載しましたが、
私は、システムの移行・切り替えは、できるだけ段階的に実施したいと考えています。

今回は、システム構造上、旧システムでの業務と新システムでの業務が混在可能です。
また、データの移行は初回のみの発生です。

よって段階的な移行・切り替えを助言し、ある回数・方法で決定し、計画化されました。


例えば、トランザクション系やサマリー系のデータ移行が発生しない場合、
業務の移行・切り替えの検討・計画化は「その時期が来てから・・・」となるケースが比較的生じやすいような印象を、私は持っています。

そして、その時期が来た時には、「それどころではない！」という状態になり、
結局、移行・切り替えはユーザー部門に何となく委ねる・・・という状況になるケースもあるのではないでしょうか？

ユーザー部門は移行・切り替えの経験が少ないと思います。

ユーザー部門に主体性をもっていただく必要性は十分にわかっているのですが、
ユーザー部門の頼れる支援者として、情報システム担当や構築ベンダーの力を発揮していただきたいと思います。

情報システム担当、構築ベンダーとも、いろいろ過去に苦い経験もしていると思います。
その経験を「見ぬふり」することで生かすのではなく、
しっかりとユーザー部門へ説明し計画化する方向性で生かしてほしいと思います。

少しわかりづらく、飛躍した内容になりましたが、
新システムへの切り替え・移行時に、ユーザー部門と「情報システム部門」「構築ベンダー」との壁を感じる場合があります。


＜関連記事＞
　データ移行は慎重な対応を
　システム切り替えは慎重な対応を

　超上流工程からシステム運用テストまでにおける考慮事項