情報大工のひとりごと

機能と使い勝手の実装は不可分

「利用者の立場を考えたペルソナ／シナリオ法による開発とは」がやはり話題になっていますね。全体的に良い指摘が続く中で、もっとも注目すべき点は以下の部分ではないでしょうか。

ペルソナ／シナリオ法による開発は「シナリオファースト」と呼ぶことができます。最初にペルソナとシナリオを使って仕様をかなり細かいところまで固めて、それを基にしてソフトウェアの仕様を作っていくのです。仕様についてはイテレーションを行うことよりも最初に多くの部分を固めてしまうことを重視するため、ある意味ではウォーターフォールに近い形になります。

@IT | 利用者の立場を考えたペルソナ／シナリオ法による開発とは

世の中の流れに逆らっているのかもしれませんが、まったく同感です。設計段階でもっと使い勝手を詰めるべきでしょう。

システムの設計はどうしても機能ベースや画面ベースで進みがちなので、設計プロセスにユーザーの視点を導入するという意味で、シナリオによる検証は価値があります。それだけでなく、実際の機能とシナリオで要求される機能をマッピングしてみて、機能の漏れがないかどうかを検証できるという面でもシナリオによる検証は必須と言えるでしょう。ただ、業務システムに関しては、厳密なペルソナを設定する必要はないような気がします。「いつ・誰が・（具体的に）どのような業務を行うか」のコンテクストを明確に設定することで、シナリオだけで基本的な使い勝手は検証できるはずです。

それよりも、業務システムに関しては別の問題があります。つまりシナリオによる検証を行うかどうかもさることながら、納期やコストの制約からシナリオ検証の成果を十分に活かすことができない（検証結果を反映すると納期／コストを超過するので、現状で見切り発車する）という、根本的かつ慢性的な問題です。ここをクリアしないと、いくら検証プロセスを導入したところで「システムが使われないのは設計が悪い」（使い勝手的に実業務に負荷となってしまう＝まともに運用できない）から抜けられません。

これは機能の実装と使い勝手（の向上）の実装を分けて考えているために発生する問題ではないでしょうか。そうすると、「機能の実装には使い勝手の実装も含まれる」つまり「機能と使い勝手の実装は不可分である」ことが、発注者／開発者の共通認識として徹底されない限り、設計の品質は永遠に向上しないということになります。だからこそ、前述の記事中で触れられている通り、設計段階での使い勝手の検討が重要になってくるのです。

業務システムの設計工程に関する書籍をいくつか読んでみても、設計段階における使い勝手の作り込み／検証に関しては、ほとんど触れられていないのが実情です。まずはこの辺りから変えていく必要があると思うのですが、いかがでしょうか。