[ooaa main]  [object pasta2]   [essence] (旧blogはこちら)  [flickr]  [myspace]  [View Eiichi Hayashi's profile on LinkedIn] 

運用を変えるということ

今日の打ち合わせで聞いたことメモです。

・ユーザー企業の情報システム部は、たいがい社内的に立場が弱い場合が多いので情報システム部が調整してつくる仕様は、ユーザー部門の運用に例外が多かったり複雑化して問題や改善の余地があっても、それを変えないような仕様になることがおおい。

・上流工程を請け負う場合は「運用をシンプルにして、システムを最適化しないとコストが上がるとともにシステムを使う恩恵がない」ということを言えるかどうかが大きな境目であるということ。 
最初からその点をミッションとして合意を得られるかどうかは非常に大きいポイントだと思った。

業務、運用の改善を含んだシステム提案ができるかどうか、そこまで踏み込んだことが初期の段階で言えるかどうかがそのシステムの有用性を決定する。 また、それを言えずに例外満載の複雑なシステムになった場合は開発自体の工数爆発のリスクが高くなると思う。

初期に概要レベルで同意を得ることは重要だが、「概要」はレベルを規定したものである必要があると思う。 
そのシステムの目的、UIのレベル感、主要機能の設計方針を含むべきだろう。

レベル感が不明確な場合は、UIのレベルカタログを見せることでユーザさんの要求レベルを明確にするとともに潜在的な要求を掘り起こすことができると思う。 例えば、権限はどこまでコントロールするかとか、画面の制御のレベルはどれくらいかとか。
画面の例を見せることとでレベル感に合意がある状態で見積もりを行うことができると思う。