Manabuオブジェクト指向UIとタスク指向UIの主な違いはそのシンタックスにありますが、通常は、ひとつのシステムやアプリケーションの中に両方のシンタックスが混在していたり、あるいは目的と手段の関係のように、いま選ぼうとしているのがオブジェクトなのかタスクなのかは作業段階のどこから見るかで相対的に決まる場合が多くあります。デスクトップにあるブラウザのアイコンをクリックするという行為は、ブラウザというアプリケーションオブジェクトの選択であるとも言えますし、そこから開始するウェブの閲覧というタスクの選択であるとも言えます。そもそもパソコンという道具は、ひとつのシステムでいろいろな仕事をするためのものですから、その上で作業の合目的性を高めるためには、何かのタスクに特化したフレームワークやアプリケーションの存在が必須になってきます。何にでも使える道具というのは結局何にも役立たないわけですから。考えると、オブジェクト指向UIとかタスク指向UIというのは、方式として機械的に設計できるようなものではなく、もっと感覚的なというか、思想的なものなのだと思います。ある機能をどちらのシンタックスで実現するかは、自由に選択できるわけではなく、そのシステムの基本的なコンセプトから必然的に決まってくるものです。どちらが優れているということはないのですが、コンセプトが曖昧だったりインタラクションの一貫性が意識されていなかったりすると、両者がコンフリクトを起こして、不合理でちぐはぐな操作性になってしまうのです。コンセプトというのは、そのシステムが提供するサービスの世界観や、道具としての操作性を決定するイディオムのことです。「自動車」や「電車」はイディオムの例です。移動手段としてどちらの乗り物も存在意義があるように、ユーザーインターフェースのイディオムにもこうでなければいけないというものはありません。いうのは基本的に「自動車」的なイディオムのアプリケーションにマッチした表現なのです。ここでひとつ気づいたことがあります。受け入れ、「自動車」式イディオムの分かりやすさや生産性を認識したかのように思われますが、実際には、そうでもないようなのです。いうのも、いろいろなクライアントを相手にオブジェクト指向UIを意識したデザインを提案していると、タスクの内容にかかわらず、担当者によって気に入ってもらえる場合と、どうしても納得してもらえない場合があるのです。業務要件やフィージビリティとは関係ないレベルで、何か生理的に受け付けない人というのがいるようなのです。割合で言えばむしろそういう人の方が多いぐらいで、六割ぐらいの人が、実は「自動車」式のイディオムが嫌いみたいなのです。ユーザーインターフェースというもの全般に対する価値観が違うようです。自動者式を気に入る人達は、ユーザーインターフェースを「料理の道具」のように見ているのに対し、そうでない人達は「料理のレシピ」のように見ているのです。料理のレシピというのは、つまり目的達成までの手続を示すもので、イディオムで言えば「電車」式に必要なものです。使いながらも電車式のイディオムを求めているようなのです。彼等は、複雑で操作方法が分かりにくい画面を改善するために、「説明書きを加えればよい」とか、「エラーメッセージにヘルプ的な指示を出せばいい」といったことを言います。画面をもっとシンプルにしようとする方向には消極的です。UI要素をもっと記号的かつ合理的にして、重複するアクションや対象オブジェクトの表現を一元化することにあまり価値を見出しません。料理道具の無駄を減らして取り回しを良くするよりも、レシピをもっと詳しくすることの方が有益であると考えるのです。ダウンロードするにはこちらをクリックしてください」という指示文のリンクを置こうとするのです。不可逆的なコントロールを何とも思わず、あらゆる操作に確認ダイアログを出したがり、そしてサブミットが成功したことを告げるだけの完了画面に固執するのです。UIに対する価値観が根本的に違うのですから、これを無理に説得するのはほとんど不可能です。pm暗に概念クラス図を導くような構えで業務分析のようなことを行うと、インタビュー相手に戸惑われてしまいがちですが、シーケンス図のたたき台をいったん提示すると、自分から進んでスラスラ書き直してくれたりすることが多いです。このへんにも、自動車vs電車をめぐる生理に深く根ざす問題があるんでしょうね。その場合のシーケンス図に現れるレーンは、たいていアクターであって、クラスではないんですよね。業務というものを、クラス同士の静的な関係性ではなく、シーケンシャルなワークフローとして認識していることが多いようですね。WordPress.。