「開発・制作プロセス」記事の一覧
「利用者の立場を考えたペルソナ／シナリオ法による開発とは」がやはり話題になっていますね。全体的に良い指摘が続く中で、もっとも注目すべき点は以下の部分ではないでしょうか。
ペルソナ／シナリオ法による開発は「シナリオファースト」と呼ぶことができます。最初にペルソナとシナリオを使って仕様をかなり細かいところまで固めて、それを基にしてソフトウェアの仕様を作っていくのです。仕様についてはイテレーションを行うことよりも最初に多くの部分を固めてしまうことを重視するため、ある意味ではウォーターフォールに近い形になります。
世の中の流れに逆らっているのかもしれませんが、まったく同感です。設計段階でもっと使い勝手を詰めるべきでしょう。
システムの設計はどうしても機能ベースや画面ベースで進みがちなので、設計プロセスにユーザーの視点を導入するという意味で、シナリオによる検証は価値があります。それだけでなく、実際の機能とシナリオで要求される機能をマッピングしてみて、機能の漏れがないかどうかを検証できるという面でもシナリオによる検証は必須と言えるでしょう。ただ、業務システムに関しては、厳密なペルソナを設定する必要はないような気がします。「いつ・誰が・（具体的に）どのような業務を行うか」のコンテクストを明確に設定することで、シナリオだけで基本的な使い勝手は検証できるはずです。
それよりも、業務システムに関しては別の問題があります。つまりシナリオによる検証を行うかどうかもさることながら、納期やコストの制約からシナリオ検証の成果を十分に活かすことができない（検証結果を反映すると納期／コストを超過するので、現状で見切り発車する）という、根本的かつ慢性的な問題です。ここをクリアしないと、いくら検証プロセスを導入したところで「システムが使われないのは設計が悪い」（使い勝手的に実業務に負荷となってしまう＝まともに運用できない）から抜けられません。
これは機能の実装と使い勝手（の向上）の実装を分けて考えているために発生する問題ではないでしょうか。そうすると、「機能の実装には使い勝手の実装も含まれる」つまり「機能と使い勝手の実装は不可分である」ことが、発注者／開発者の共通認識として徹底されない限り、設計の品質は永遠に向上しないということになります。だからこそ、前述の記事中で触れられている通り、設計段階での使い勝手の検討が重要になってくるのです。
業務システムの設計工程に関する書籍をいくつか読んでみても、設計段階における使い勝手の作り込み／検証に関しては、ほとんど触れられていないのが実情です。まずはこの辺りから変えていく必要があると思うのですが、いかがでしょうか。
IT Proの記事「使われないシステムは"ただの箱"」ですが、な〜んかポイントを外しているように思えます。
これまで（各種業務での経験を含めて）見聞きした業務系システムのドキュメントを前提とする限りでは、ドキュメントを含めた教育体制に問題があるというのは、おそらくその通りでしょう。コンスーマー製品のマニュアルを見慣れた目から見ると、品質的に許容レベルに達しているとは到底思えないものがほとんどです。これは仕上がりの出来不出来の問題ではなく（もちろんデザイン処理にもかなり問題がありますが）、文章品質や情報構成の手法などの根本的な問題です。
もう少し具体的に説明すると、この種のドキュメントの文章はエンジニアによる仕様書レベルであることが多く、品質的には書き直しが必要なレベルと言えます。それよりも問題なのは、情報が機能単位で構成されていて、実際の業務単位で構成されていないことです（タスク志向で情報が構成されていない）。一般的な業務には（1つの機能では完結せずに）複数の機能を横断してはじめて完結するものも多いと思います。で、このような場合に情報が個々の機能単位で構成されていると、ドキュメントを読んだだけでは操作の流れの全体像を把握できないのです。
さて、この記事ではドキュメントや教育体制に問題を転嫁するばかりで、システムの設計に問題はなかったのか？という根源的な問題から目をそらしていることが気になります。ドキュメントの重要性を主張してくれるのは嬉しいんですけど（笑）
当該システム現物を見た訳ではないので断定は避けますが、「使われない」システムは実際の業務フローを無視した設計がなされている可能性が非常に高いのではないかと思われます。おそらく、それぞれの機能にすぐにアクセスできるかどうか（ボタンだらけのトップメニューが代表例）は考えても、業務フロー全体を通した使いやすさやわかりやすさを実現することで、業務効率向上を支援するという視点が完全に抜けているのではないでしょうか。そもそも「利用者が本当に知りたい内容を事前に調べ，そのことを重点的に教える」内容は、システム設計段階で対応すべきレベルの話でしょう。
設計主体が企業内部／外部であるに関わらず、UI設計とドキュメント制作に関しては、設計の早期段階から（コンサルじゃなくて）実務専門家を参加させるべきです。従業員にプロトタイプを触ってもらう簡易テストだけでは、使いやすさを確保するにも限界があります。ユーザビリティ検証なしのWebサイト構築があり得ないように、社内業務システムでも専門家によるチェックは必須のはずです。初期導入コストの上昇分は将来的な運用コスト削減を考えれば楽勝でペイできるでしょうし、何よりもシステムを使ってもらえないという莫大な無駄金が発生するよりは、はるかにマシだと思うんですが...。
マニュアル制作の期間短縮とコストダウンを目的として、「仕様書などの内容をそのままマニュアルへ」ということを主張されるエンジニアの方が結構いらっしゃるようです。個別機能ベース（リファレンス系）のマニュアルであれば何とかごまかしはききそうですが、タスクベース（主に操作系）のマニュアルではちょっと無理そうな話です。現状でも日程とコストの両面でマニュアル制作現場にはかなりの負荷がかかっており、少しくらい制作プロセスをいじったところで、作業効率が劇的に向上するとはとても思えません。
このような状況で効率改善のポイントとなりそうなのは、やはり設計部門とマニュアル制作部門間のコミュニケーション・ロスの削減でしょう。つまり設計変更があることを所与条件とした上で、変更対応にかかる作業負荷を（エンドユーザー＝お客様へ負担転嫁することなく）効果的に削減できる、設計部門とマニュアル制作部門間のインターフェースのありかたをどう考えるのか？ということです。で、このインターフェースの大部分は「外部仕様情報のありかた＆運用のしかた」に集約されると思うのです。
ですが、最近の開発プロセスはこのインターフェースの部分を甘く見ているように思えてなりません。外部仕様情報のありかたについてはメーカー内で統一の動きもあるようですが、設計変更に伴う連絡や修正管理といった運用面に関しては、なかなか改善が見られないようです。これはおそらく、外部仕様情報を必要とする部門や、それぞれの部門がどのような情報を必要としているのかを正しく把握していないからでしょう。そのため、必要な情報を必要なタイミングで提供することが難しくなっているのではないかと考えられます。
で、ここをどうやって改善するかなんですが、なかなか難しそうです。まず、
といったあたりを検討することで、現状の問題の所在を明らかにすることが肝要かと思います。その上で、 インターフェースとしての外部仕様情報に必要とされる要件や、運用方法を再考するべきでしょう（でも結局face to faceの時間を増やすとかいうことにされてしまうと、それはちょっと違うんじゃないかなあとか思わないでもないです）。
最後に、外部仕様書については「Joel on Software | やさしい機能仕様」も参考になるかと思います。エンジニアの方には、特におすすめです。
マニュアル制作には仕様書（特に外部仕様書）が必要不可欠なのですが、良いドキュメントが支給されることは少ないのが現実です。主な問題としては、記載量が少なすぎることと、内容がアップデートされていないことの二点にあります。
仕様書の記載量が少なすぎる問題がある場合に共通しているのは、物理的なボタンにせよ画面上の各種コントロールにせよ、オブジェクト単体の機能仕様しか記載されていないことです。リファレンスマニュアルならこれでもなんとかなりますが、ユーザータスク中心のマニュアルを起こすには情報が決定的に不足します。これは実際にユーザーがあるタスクを行う上で、どのような操作の流れの上に特定のオブジェクトを利用するのかが、まったく理解できないからです。他のUIからの連想でカバーできることもありますが、経験に基づいた職人芸的解釈に依存する文書が仕様書というのはいかがなものかと。まあ外部仕様書に記載して欲しい情報内容というのはだいたい決まっていますので、何かの機会にまとめて取り上げたいと思っています。
内容がアップデートされていないという問題に関しては、言うまでもないですよね。このようなケースでは現物優先でと指示されることが多いのですが、現物自体がβ程度の出来だったりすると、もう何が何だかわからない世界に突入です。つまり仕様書も現物もどちらも最終仕様として信用できないわけで、これでは一体何をよりどころにしてマニュアル制作をすれば良いのやら。この場合、担当者間でも意志疎通が取れていないことが多いので、本当に泣きが入ります。
このような問題の背景としては、ソフトウェア開発の（ウォーターフォール型から）反復型への移行という理由がありそうな気がします。どうも「文書（仕様書）重視はウォーターフォール型の文化だから、反復型なら現物重視（文書軽視）でOK」という思い込みまでもが広がっているようで . . . 。でもこれはすごく変な話で、文書が残っていないと実装前の操作性レビューもできないですし、開発プロジェクト全体を通した成功／失敗例の教訓となる、意志決定プロセスの記録も残らないことになってしまいます（反復型の開発に関しては「仕様は逐次変わるものだから、最初から最終仕様を意識しなくてもOK」のように、外野からすると設計段階での熟慮を最初から放棄してるのか？としか思えないとんでもない認識も出てきているようなのですが、これは別の話なのでまたの機会に）。
どうも仕様書（特に外部仕様書）の問題は「マニュアル制作者のためだけに仕様書を支給するのは面倒だから、口頭伝達で良いじゃん」という認識にありそうなのですが、これは大誤解と言わざるを得ません。マニュアル制作者だけではなく、実は営業担当者やサポート担当者など、製品に関わる多くの人たちも仕様書に記載されているべき情報を把握する必要があるのです。機能の特徴や想定利用場面、機能制限などを知らずして、営業／サポートできますか？ ほら、絶対に文書化が必要でしょう？ というか、そもそもしっかり形に残らないような仕様の決めかたなんかしてるから、いつまでたっても製品の操作性が（以下略）。
ソフトウェア開発の領域でプロトタイピングが主流になってくるにつれて、マニュアル制作の現場で困った事態が持ち上がっています。制作者が頻繁なアップデートに付き合わされるため、特定案件から手が離せないという問題です。
マニュアル業界ではページ単価とか文字（苦笑）単価といった制作料金体系を採用しているところが多いのですが、これは大きなチェックを2〜3回＋最終修正のやり取り、という作業フローを想定しているからこそ成立する体系であるといえます。要するに、制作者を特定案件に張り付かせることなく複数の件を受け持ってもらうことで、制作会社として負荷の均一性の確保と全体の売り上げ増を狙うという方法論です。
ですが、マニュアルなりヘルプなりの制作者が、毎週リリースされるビルドという形でプロトタイピングに付き合わされるのであるならば、このような方法論自体が通用しないことになります。作業工数と売り上げの想定の根底が崩れることになりますので、これは由々しき問題です。プロトタイピングで設計が行われる案件に関しては、イラストや基本デザインといった個別単価見積もりが可能な部分と、制作者を専属させるための人月計算で算出する部分に分けて考えるべきなのかもしれません。しかしこれでは大幅なコストアップになるでしょうから、発注側はなかなかこの条件を飲まないでしょう。
この問題については、実際に制作料金が上がるかどうかよりも、設計プロセスの変化による制作プロセスへの影響に発注側の担当者（特にメーカーのマニュアル担当者）がまったく気付いていないというのが一番の問題でしょう。制作システムが写植からDTPに移行したときにも、前時代的なワークフローや意識を引きずったままの担当者が多く見られました（もちろん今も見かけます）。設計プロセスという部分は制作システムと違ってさらに目に見えにくい部分ですから、担当者レベルでの意識改革には、まだまだ時間がかかるのでしょうね。あ〜、頭痛い。
ユーザーの反応を見ながらどんどん作り込んでいくという、プロトタイピング手法がWebサイト構築でもソフトウェア設計でも主流のようですが、ちょっと安易なプロトタイピングが多すぎると思ったことはありませんか？
確かに中途段階での評価を素早く反映して、製品に作り込んでいくことができるというプロトタイピングは、ユーザーにとってより良いものができる可能性が高い設計手法といえます。ですが、それもプロトタイピングのスパイラル（実装→評価→修正〜）に入る前に、やるべきことを適切に行っていればこそという前提が忘れられているように思えます。
そもそもプロトタイピング手法というのはスパイラルをまわすことで品質を作り込んでいく手法ですから、途中の変更をもともと織り込み済みの設計手法です。そうはいっても、中途段階での根本的なロジックの変更には弱いことが見過ごされているように思えるのです。まあ根本的なロジック変更に対応できる手法なんてものは、この世に存在しないでしょうけれども。
それでは、根本的なロジックの変更を引き起こす要因とは何でしょう？ それはWebサイトにおける情報構造デザイン、UI設計における基本操作ポリシーなどのように、目には見えないけれどもユーザーが向き合うシステムの根底を支えている部分の仕様変更なのです（業務システムのデータ構造もこの種の例に入りますが、データ構造の設計には時間をかけていることが多いので、おそらく大丈夫でしょう）。こうした部分を作り直す必要に迫られたときは、たいていは目に見える部分全体が作り直しの対象となります。
ですから、情報構造デザインやらUIポリシー設計といったシステムの根幹部分をもっとよく検証してから、スパイラルに入るべきなのです。ご時世柄か短期決戦プロジェクトが増えているいることもあり、ちゃんと考えずにスパイラルに入ることが多くありませんか？ いや、疑問型ではなく、見聞きした範囲ではこうしたプロジェクトの方が多いのですが（汗）。「今更そんなとこ直せねえよ」ということでWebサイトなりソフトウェアの使い勝手の質があがらず、結局損をするのはユーザーです。もっとも、最終的にはビジネスの失敗ということで、プロジェクト実施部隊が責任を取ることになるのでしょうけれども。
情報大工のひとりごと