文・石川　涼（日立総合計画研究所社会システム・イノベーショングループ研究員） SWOT分析とは、1960年代に考案された、組織のビジョンや戦略を企画立案する際に利用する現状を分析する手法の一つです。SWOTは、Strength（強み）、Weakness（弱み）、Opportunity（機会）、Threat（脅威）の頭文字を取ったものです。 さまざまな要素をS（強み）・W（弱み）・O（機会）・T（脅威）の四つに分類し、マトリクス表にまとめることにより、問題点が整理されます。その結果、解決策を見つけやすくなるという特徴があります。マトリクスに整理する過程で、関係者が意見を出し合いながら、問題意識を共有化できる点もメリットの一つです。 SWOT分析には、二つの段階があります。第一段階では、事業や組織におけるS・W・O・Tそれぞれの要素を抽出します。まずS（強み）とW（弱み）には、企業や組織の持つ

画面設計書について，前回に引き続き，それを書くツールや手法について考えてみましょう。 画面設計書の基本 まずは，画面設計書の中にあるべき情報から見てみましょう。これらすべてがそろっていなければならない，というわけではありませんが，望ましいのではないかと私自身は考えています。 header ページIDやタイトルなど，一目でそのページがどの画面仕様を記述しているかがわかるような「ヘッダー」部分。細かく書くならば，文字コードや対象ブラウザまで記述する場合もある。また，プロジェクトの名前（プロジェクト・コード）や版番号なども記し，似たようなドキュメントの中からも引き出せるようにしておく。 footer 制作サイドのコピーライトやページ番号などを記す。最終的には，クライアントのコピーライトに置き直して，最終納品とする場合もある。 Page Layout 画面内に配置する「ユーザー・インタフェース（U

前回まで「画面設計書」について書いてきました。今回は，画面設計書も含めた「ドキュメント」を，どのようにとらえるべきかというテーマを取り上げたいと思います。 今回お伝えしたいのは，ドキュメント作成のプロセスを定めることは，実はかなり大きな決断だということです。ドキュメントは作成に手間のかかるもので，どうしてもコーディングに比べれば後追いの形になります。しかし，記録や技術資産という意味で価値あるものであることには間違いがありません。だからこそ，慎重に取り組むべき事柄なのです。なお，以降でいくつか私流の考え方を列挙しますが，どれが本当に良いかは，もちろん皆さん自身の考え方や環境によります。 ドキュメント記述の責任と分担が明確になりつつある ドキュメントを記述するツールにはどういったものを選べばいいのでしょうか。小さな組織であったり，短期間の開発であったりするなら，今まで自分が慣れ親しんできたツー

Webサイトを構築する場合，通常は「設計書」を作成します。サイト全体の設計書であったり，ページ単体の設計書であったりするわけですが，今回は後者である「画面設計書」について考えてみましょう。 画面設計書を読むのは誰か Webサイトの構築では，対象ユーザーをできる限り具体的に決めてから開発を進めていきます。同様に，画面設計書にも「対象読者」を見定める必要があります。結論から言えば，かなり属性の異なる二種類の読者が存在します。 まず，発注者である「クライアント」です。クライアントは，技術的な難易度ではなく，自分たちのビジネス要件を満たすものが作られるかどうかを確認するために画面設計書を読みます。開発（プロジェクト）のゴールや，プロジェクトのメリット/デメリット，リリース後の顧客満足の予想などを，その設計書から読み取ろうとします。したがって，できる限り具体的なイメージが伝わるものが要求されます。

対象とするユーザーの“慣れや知識”によって，画面の構成を変えたほうが伝わりやすいとするならば，画面上の「ユーザー・インタフェース（UI）部品」の色や形状も，ユーザーに応じて変えるべきでしょう。今回は，代表的なUI部品でありながら，なかなか作り手の思うように押してくれない「ボタン」について考えます。 わかりやすいボタンの形状はユーザーによって違う まず，前回とほぼ同じ絵を用います。Webシステムの操作方法への「熟知度（PCリテラシ）」を縦軸，「提供したいサービスに対する知識」を横軸とします。そして，それぞれの「軸」に対して，受け入れやすいと思われる「ボタン」の形状を例記しました。 上図の【A】や【B】のタイプに当てはまるPCリテラシの高いユーザーは，ボタンの“ラベル”に「submit」と書かれていようが「GO」と書かれていようが，ボタンを認識することはさほど苦ではありません。 しかし，PCに

Webアプリケーションを開発する際に，対象ユーザーを考慮することの大切さについて見てきました。今回は，ユーザー・インタフェース（UI）設計にも，マーケティング感覚が必要なことを考えてみましょう。 UIの問題点を改善していく手順 例によって航空券の予約をサンプルに使います。下記の画面をご覧ください。このWebアプリケーションには，様々なオプションを付け加えることができます。しかし，必要最小限の情報は，「搭乗日」と「出発地」と「到着地」の三項目だけです。このUIに，どこか問題はないでしょうか。 (1)　日付部分への改良 まず注目してほしいのは，搭乗日という日付情報をユーザーにすべて入力させている点です。日付情報をユーザーにまかせ切ってしまうと，表記が統一されず，結局のところシステムでそれを補う処理が発生してしまいます（たとえ「2006/08/02」などと「例」を明記しても，半角文字と倍角文字と