例えば、1つのアウトプットを取っても「目的」を理解する事が重要です。目的を理解する事によって、例えば、代替機能のご提案や機能の重複、無駄を防ぐ事が出来ます。それから、予算都合との兼ね合い等で要望の優先度を判定する材料にもなりますね。

そこれまでの経験から言うと、ユーザーとは手段を訴えてくるケースが多いものです。つまり「システムや機能を作りたい」という意見が先行し、例えば「業務の効率化」といった、プロジェクト本来の目的が不明瞭になるといった場合があります。これは、「何故そうしたいのか？何故それが必要なのか？」といった （目的に繋がる） 背景は無くても、「どういう手順でやりたい」と言う事を伝える事で、目的までを理解して貰えるという錯覚 （感覚） があるからでしょう。 K/Fそうですね。システムに慣れているお客様だと、システムのイメージを提示して頂けるケースもありますが、その手段が最適とは限りません。本来の課題を確認すると、他の手段が望ましい事もあります。

そうですね。システムに慣れているお客様だと、システムのイメージを提示して頂けるケースもありますが、その手段が最適とは限りません。本来の課題を確認すると、他の手段が望ましい事もあります。

「目的を重視した最適化を提案する事」が、正に我々の役割ですね。

先にも述べましたが、暗黙値や期待値を見出すには、システム化の範囲を先行して決めてしまわない事です。意外な箇所 にシステム化のターゲットが潜んでいる場合もあります。 今回のプロジェクトでは対応しないとしても、お客様の業務を深く知る事で、次期のシステム構築をご提案出来る可能性 も含んでいます。私は部下に対して、「ユーザー業務に精通する事が重要だ」口うるさく言うのですが、そのような意味 もあるんですよ。