高等学校情報/情報I/情報デザインとプロトタイプ開発

まず、「問題」とは、理想と現実のギャップのことです(※検定教科書にそう書いてある)。
そして、問題解決のための「課題」とは、そのギャップを埋めるために具体的にしなければいけない事です。
まず、問題や課題を正しく認識するために、なるべく数値的に認識することで、検証可能な形で(※ 実教出版の見解)課題を表現する必要があります。
たとえば、部活をつくりたいのにメンバー不足な場合、目標は、けっして「部員を増やしたい」という表現はなく、もっと数値的に「最低でも部員が10人になるまでは部品を確保したい。5対5で対戦の練習ができるから」のように具体的に課題を数値で設定する必要があります(※日本文教出版 I)。また、理由も併記すると、応用が利きます。
さらに、文章で課題や情報収集のインタビュー結果などを表現する場合でも、なるべく5W1Hが分かるように記録するべきです(※ 開隆堂の見解)。解決案を提示する場合も、なるべく分かりやすい表現にしましょう(※数研出版)。これが出来てない場合、解決案として、そもそも不十分な可能性があります;。
さて、理想や目標がいくつもある場合はどうすればいいでしょうか。
現実には、時間や金銭などの制限があるので、すべての理想や目標が達成できるとは限りません。
理想や目標が複数ある場合や、チーム作業などで今のままでは意見がまとまらない場合には、自分またはチームの理想・目標に優先順位をつけるのが効果的です(※ 第一学習社 P.5、※数研出版 P.18)。
部活でも趣味でやってる練習なら、好きな時間配分で練習すればよいですが、しかし、もし部全体として「試合に勝ちたい」とかの目標があるなら、部の勝利のために効果的な練習に時間を優先的に配分する必要があります(※ 数研出版)。例は運動部でもなくても良く、別に体育祭でも何でも良いです。
課題や目標が複数ある場合、トレードオフの関係にある場合もあるので、そのことを認識する必要もあります(※ 実教出版、数研出版)。少なくとも、学校での部活の課題の場合、部費と言った費用の限界、練習場と言った場所の限界があるので、決して無制限に何でも叶う(かなう)なんて、ありえません(※数研出版の見解)。
練習量の多さに満足してはいけません。
スポーツなら、本番前に、本番を模した予行練習とかをしてみて(※ 開隆堂)、自分たちの練習法が果たして本当に正しいのかを検証しなければいけません(※数研出版)。
実際の戦績などを見て、もし練習しても成果が出て無さそうなら、練習法を直さないといけません(※数研出版)。これがPDCA法の考え方です。
なにかの理論通りに練習してみれ成果がいつまでも出ない場合、その理論は間違ってるのです。
そして、本番が来たとします。本番が終わったあとも、本番での自分たちの結果を記録し、来年以降に後輩などが役立てられるように備えます。または、自分たちが来年以降に役立てても構いません。 (いわゆる「アーカイブ」化。普段は使わないが後年に使うかもしれない情報を記録して整理して残して資料化したものをアーカイブと言います。)
また、本番の結果もPDCAサイクルの一部にして、練習方法などを検証してみたりもします(※数研出版)。
スポーツを例にして説明しましたが(なお日本文教出版の例)、工場の品質管理や生産管理などにPDCAサイクルの手法は応用されています(実教出版)。
(※ 範囲外)暗黙の前提ですが、PDCAサイクルはなるべく短期間で回す必要があります。つまり、世の中には反面教師として、Plan→Do→Do→DO→Do→・・・ みたいにやたらとDoが長かったりして何か月もかかったり、あるいはPlanが長かったりして何か月もかかり、一向に検証 Check や修正後の再行動 Action につながらない人がいて、これではPDCAが形骸化(けいがいか)しています。
デザイン(design)とアートは違います。デザインは自己表現ではありません。東京書籍かどこかのサイトにある情報科目のパンフレットでは、アートとデザインは別物だと、イメージ画像で説明しています。
なんだかピカソ的な良く分からない絵や像をつくるのがアートで、そうではなくて図解などで文字を読まずに(もしくは少ない文字で)絵だけで分かりやすく説明するのがデザインです。
デザインのうち、情報デザイン(information design)と言われる分野があります。
アートと情報デザインの違いとして、上記の違いのほかにも、アートは多様な解釈を許しますが、情報デザインでは解釈を、正しい解釈だけで一通りに人々に受け取ってもらえるようにしなければなりません(※第一学習社)。たとえば、もし外国人など文化の異なる人が道路標識や非常口マークやトイレのマークなどを見たら(こういった標識も「情報デザイン」の例です)、その意味を一通りに理解できないと、事故の原因になってしまうので、情報デザインでは一通りの解釈でないといけないのです。
余談ですが、色は国によって解釈が違うので、ピクトグラムに色を使うときは注意が必要です(※第一学習社)。たとえば太陽の色は、日本では赤で表す人が多いかもしれませんが、外国では白や黄色で表す人が多い国もあります(※第一学習社)。普及しているピクトグラムを見れば、色を見ずとも形状だけでも意味が推測できるようになっているデザインが多いでしょう。
なお、情報科目だけでなく、美術2でも似たようなデザインとアートの違いについて習います
じっさい、美術の教科書会社のサイトにある動画でも、そう言っています。
デザインは問題解決のために、観客に分かりやすく、観客が楽しめるように絵を交えて説明する絵画作品のことです。
なお、デザインする仕事の人のことを「デザイナー」と言います。
ともかく、デザイナーは作品で情報が分かりやすく伝わらないと意味ないので、なので普通の人の気持ちもある程度は分からないといけません。
なので、情報デザインの授業でたとえば「学校の紹介をするwebサイトを作ろう」みたいな事になった時は、きちんと分かりやすいwebサイトを作ってください。
なお、別単元の「プロトタイプ開発」なども参考にするとよいでしょう。
教科書会社によっては「プロトタイプ」と言う呼び方ではなく「試作」と読んでいる会社もあります。まあ、内容は同じで、要するに試作してから、細部をつめていきます。

パンフレットやwebサイトなどの情報伝達メディアを作る場合、対象者(ターゲット)に分かりやすい表現をする必要があります(※ 日本文教出版I・P96、開隆堂)。
特に幼児や小学生などの子供向けの場合、それらの年齢層にも分かりやすい表現が必要です(※ 開隆堂)。
日本文教出版『情報 I』いわく、「わかりやすさ」「見やすさ」「読みやすさ」が、情報伝達メディアを作る際のポイントです。
デザイン(『設計』という意味)の分野では、けっして、なんでもかんでも議論で決定するべきではありません。
アイデアの良さを確認する場合は、実際に試作品をつくって、アイデアがうまく行きそうかどうかを、実験的に手を動かして確認してみることも必要です。
たとえば、あるウェブサイト用のイラストを描く場合を例をあげると、まずラフ画(簡略化した線画などからなる、おおざっぱな絵)を書いて、協力者や依頼者などにラフ画を見せて意見を出してもらって、構図に問題が無いかなど、いろいろと確かめます。
あるいは、大まかな線画に加えて色も大まかに塗るくらいなら、いいかもしれません。
そしてウェブサイト用イラストの場合なら、まずラフ画ができたら、そのラフ画をさっさとスキャナーなどでデジタルデータにして、先にHTMLファイルなどで製作中サイトに表示してみて、いろいろと確かめてます。
たとえば、ラフ画が色付きなら、「その画像の色は、はたして本当にこのサイトで表示しても大丈夫か? 文字の色と紛らわしくないか? サイトの背景の色と紛らわしくないか?」とか様々な問題点の有無を確認します。
あるいは、サイトの説明文などを組み合わせた状態を実際に閲覧してみて問題点が無いかなども、確認してみます。
(いくら、紙に書かれた単品のイラストだけを見ても、サイト上で説明文と組み合せた時の問題点は、実際にコンピュータ上で組み合せてみないと、気づくのが難しいのです。 なので、実際に試作してみましょう。)
「ペーパープロトタイピング」という市場のスケッチだけでアイデア出しをする手法もありますが(※たとえば検定教科書の東京書籍『情報II』でも紹介されています。日本文教出版でも用語なしで紹介)、しかし「ペーパープロトタイプ」という用語は採用しなくていいです。そもそも、ペーパープロトタイピングは、日本語でいう「試作」ではなく、経産省が言うにはアイデア出しの手法です。
経産省および独立行政法人 情報処理推進機構(IPA)の見解では、ペーパープロトタイピングは、アイデア出し手法のブレーンストーミング法やKJ法などと同列の手法であると、経産省らの資料『デジタルスキル標準』ver.1.1 の表に書かれています。
なお、文科省の教員研修要資料にあるペーパープロトタイピングの使い方は、まとまったアイデアをさっさとスキャニングして、それを実際にパソコン画面などで見ることで、配置などを検討しています。そういう使い方です。
ただまあ、現代ならタッチペンのあるデバイスとツールで画像を書いて、それをパソコンに取り込むほうが早いと思います。スキャナーに並ばなくて済むし。
ハッキリ言って、(検討ではなく)検証の目的ではペーパープロトタイピングは役立ちません。コンピュータ関係のアイデアの検証をしたいなら、実際にコンピュータの実機で動かすしかありません。
裏を返すと、IT業界でいう「設計」というのは、実際に動くものを作るなどして簡易的な検証をすることも含まれています。なお、経産省の資料では、「設計」のあとにユーザーに使ってもらうなどして(※ 資料の「ユーザビリティ」からwiki側で推測)、本格的な「検証」の工程があります。
「ペーパープロトタイピング」というのは、単に、構想のアイデア出しの打ち合わせのときのスケッチを別の用語で言い換えただけに過ぎません。しょせん「ペーパープロトタイピング」はアイデア出しにすぎず、検証ではありません。
一般にIT企業でも製造業でも、さっさと実機で動くかどうかを確認するのが一般的な意味での「プロトタイプ」であり「試作品」です。少なくとも企業が若者に求めている能力はそれです。
アイデア出しばかりせず、良さそうなアイデアが出たら、(安全に配慮しつつ)さっさと検証してください。
素人どうしの高校生が、実機での制作すらしたことないのに紙上で議論しても、どうせピント外れの議論になって、無駄の無駄です。
webサイトくらいさっさとhtmlで記述して、試作できるでしょう。中学生ですら試作できます。
紙上での議論が必要なジャンルがあるとしたら、もっとカネのかかるものを制作する場合の話です。イスを作るとか、傘立てを作るとか、そういう実物のあるものを作る場合なら、紙上でのスケッチも有効かもしれません。
ですが、webサイトはそういう実物ではありません。さっさとHTMLでwebサイトを書いてください。
PDCA法などの評価手法・修正手法などによる評価(Check)や改善(Act)などは、まず先にプロトタイプで実験してからのハナシですし、まずはプロトタイプを利用者に見てもらうなどの必要があります。
もし仮に、先に絵を細かく書いてから、あとからウェブサイトに取り込む方式の開発をしてしまうと、もし文章との組み合わせでの問題点があったときに、作り直しになってしまい、大幅に時間を無駄にしてしまいます。
なので、まず先に、試作品で、最終的な全体像に近いほうを、試す必要があります。
単にラフ画を描くだけでなく、さらに、なるべく、サイトの全体像を先に試作する必要があります。
このように、なにかを試作する場合には、なるべく、試作でいいので全体像を先につくってみて実際に実験することで、全体像を確認してみます。そして、全体の確認が取れたり、あるいは全体像のミスが修正できたら、あとから細部を作り込んでいきます。



文科省の動画教材でも言われてるのですが、最近のホームページ作成は難しく、いきなりCSSとかを駆使して作るのは、ふつうの高校生には無理です。
というか、そこまで出来ないから、いま高校生が情報系の科目を勉強しているわけです。
まず、あまりCSSなどのお作法は考えず、とりあえず習った知識だけを駆使して、とりあえずのwebサイトを作りましょう。
ネットでは大人が「CSSを使わないと保守性が悪い!」とか言うかもしれませんが、しかしwebサイトとして動かない欠陥品を保守しても意味が無いです。
保守性がどうこう文句を言う大人は、決して、あなたのwebサイト制作の手伝いなんかしてくれません。そんな口先だけの大人なんかの言う事なんかを真に受けるより、実際にYouTube動画や高校教材などを作ってくれている文科省や大学教授や高校教員の人々を信用しましょう。
動くものを作るのが先、保守性を上げていくのは後回し、です。

実際にプロトタイプを作る場合は、まず箇条書きなどでアイデアを文字に起こしましょう。(※ 日本文教出版の教科書がそう。)
もし文字起こしをせず、頭の中で考えるだけだと、脳内でアイデアの記憶を維持するだけで脳のエネルギーを使ってしまうので、新アイデアの創造にまで頭が回りません。
『国際大学』という大学院大学とNHKが、プロトタイピングに使えそうな動画を作っています。クラウド関係の啓もう(けいもう)の動画ですが、視聴したところ、プロトタイピングにも使える内容になっています。 『みんなとクラウドで作業するとき、大切なことって何?』 FuLL, 動画中、小学生が学級新聞をつくるためにクラウド活用してプロトタイピングをしています(なお、動画中では『プロトタイプ』の語は出ていません)。今時の学校でのプロトタイピングは、コンテンツを作る場合にはクラウド活用することもあります。

デザイン案について、可能なら、ユーザー層などにwebアンケートを実施します(※第一学習社 P.75)。たとえばデザイン案が複数あって決まらない場合など、アンケートを取ると良いでしょう。
アンケートの際、「よい/わるい/ふつう」といった感想の選択肢のほか、なぜそう思うかの「理由」も必要です(※第一学習社が推奨している)。
検定教科書では「理由」が必要な理由までは説明してないのですが、世間一般には、選択肢を選ぶだけのアンケートだと、手抜きをしてデタラメにつける人がいます。
高校の文化祭webサイトのデザイン案とかだと、時間的な限界もあるでしょうし、アンケート実施まで可能かどうかは分かりません。
ですが、たぶん教科書会社はそういう感じで、高校生や高校教師などにアンケートを取りつつ、検定教科書を作っているのでしょう。
日本文教出版の情報IIの教科書で、webサイトのモジュール開発する場合は共通部分としてプロトタイプで「ひながた」をつくっておいて、変わる部分だけを個々人に依頼すると良いみたいな事を言ってますが(日本文教出版『情報II』P43)、説明不足、あるいはマチガイです。(なお、ヘッダとかフッタとかを共通部分として使いまわしをする挿し絵あり)
正しくは、まず上述の節での説明のように、全体像を試作するのが先です。
webサイトを作る場合なら、十数分で作ったような低品質なページで良いので、実際にコンピュータ上で、HTMLなどで記述されたwebサイトを作り、とにかくブラウザ上で確認できるところまで作ります。
たとえば日本文教出版の教科書では「出し物詳細その1」「出し物詳細その2」「出し物詳細その3」を、3人に分担させてモジュール制作させています。(おそらく、文化祭か何かの出し物のサイトでしょうか。)
このようなサイトを作りたい場合、もっといい方法は、
まず、仮の「出し物詳細(仮1)」「出し物詳細(仮2)」「出し物詳細(仮3)」「出し物詳細(仮4)」とかをサイト制作者が1人で作っておいて、それをまず画面に組み込んで確認するのが先です。
そして、サイト上で、複数の出し物(仮データ)を表示しても異常が無いかとか、そういうのを実際にサイトの動作を確認するテストをするのが先です。 つまり、本番データ作成よりも前に、まず仮データによる動作テストを行います。(※ 検定教科書(日本文教出版、実教の「情報II」)では、この工程が抜けています。この工程が無いと、本番データでテストすることになるので、運が悪いと最悪、本番データの作り直しになり、時間が大幅に遅れます。
文化祭の出し物のデータなら、たとえばクラス名は高校「991年1組」みたいにありえない数字にしておいたり、部活名なら「カリ1部」とか「カリ2部」みたいにしておくのが、本番データへの混入を防げて安全でしょう。 人名なら、「山田 太郎」とか、「東京 花子」みたいなのを仮データにすると良いでしょうか。
なお、この仮データは見本を兼ねます。読者の皆さんも、よく何かの申込書とかを書くとき、「山田 太郎」とかを例にした見本を見るでしょう。ジュール開発をする場合も、まず、そういう見本が無いと、依頼を受けた作業者は分からないのです。
ほか、「モックアップ」と「ワイヤーフレーム」と「プロトタイプ」の意味の細かな違いは、どうでもよく、なぜなら業界によって意味が微妙に変わるから。
さて日本文教出版の教科書の挿し絵によると、「出し物」をヨコ3列に表示するようなので、だったらテスト時には4個以上の仮データが必要でしょう。ヨコ1行あたりにタテ3列までしか表示しない「出し物」の改行が上手く行くかを確認するためには、4個以上の出し物データが必要だからです。
そして、上述のような試作テストを簡易でいいので終わらせてから、実際の出し物のデータに置き換えるため、それからモジュール開発の依頼を出すべきです。
したがって、モジュール開発する場合は、その前に行ったテスト時の仮データを上書きして本番データに置き換えするような形で、開発していくことになります。
もしサイト中に絵が必要なら、5分や10分で書いた稚拙(ちせつ)な絵でいいので、できれば、とにかく分かりやすい絵をデジタル上で描き、それを組み込みます。
あるいはサイト中にテーブル表などがあるなら、架空のデータで良いので、さっさと数分でデータを試作品として入れます。
まず、ソフトウェア的にバグが無いかを確認するのが先ですので、まず仮データでいいので全体像を作らないといけないのです。
もし、「時間を何時間もかけて、本番データを作成して入力したあとに、バグが発生して、データの作り直し」なんて事になったら、目も当てられません。
だから、まず、最低限の時間で(ただし、チーム仲間が見ても、ソフト動作の確認が分かる程度には、作りこみが必要)、実際に全体像をつくるのが先です。
仮データのファイル名はたとえば「出し物1(仮)」みたいな無難なものにしましょう。
仮データを作る際、もし本番データにまぎれこんでも困らないように、けっして変な名前はつけないようにしましょう。たとえばファイル名に「うんこ」とか「unko」とかつけると、最悪、本番データにまぎれるとトラブルになります。ファイル名「unko」とか付けると、トラブル防止のための確認といった余計な手間を増やしてしまい、チームの負担になります。
仮データのなかの文章も、本番でも使えるようなマジメな文章にしておきましょう。既に例示しましたが、文化祭の出し物の仮データなら、たとえばクラス名は高校「5年1組」とか「991年1組」みたいにありえない数字にしておいたり、部活名なら「カリ1部」とか「カリ2部」みたいにしておくのが安全でしょう。
チームで共同作業をする際、それぞれが別のユーザー層を思い浮かべていては、うまく共同作業ができません。
なので、具体的なユーザー層を、チームの皆で考えます。
ユーザー層を考える時、典型的なユーザーを最低でも1人、考えます。
その典型的ユーザーを考える際、名前や職業や年齢や性別、性格、家族構成、趣味や将来の志望、などといった具体的なレベルまで、人物像を決めておきます。
また、それができるようになるために、簡易な取材でいいので、事前にユーザーにインタビュー取材およびユーザー調査などをします(日本文教出版 II)。
このように、典型ユーザーのイメージ像を具体的に共有する開発手法を「ペルソナ法」と言います(東京書籍 I、日本文教出版 II)。
手法の名前「ペルソナ法」はどうでもいいです。具体的なユーザー層を考えましょう。
このように具体的にユーザー像を決めることで、ユーザー層の理解が深まるし(日本文教出版 II)、また、チームメンバー同士の考え違いなどを防止できる(東京書籍 I)。

東京書籍が言ってる手法ですが、一人のユーザーのペルソナではなく、複数人(数名ていど)のペルソナを設定する方法もあります。
その際、各ユーザーのペルソナの利益が反することがあります。
デザインの改修案が、あるペルソナAには利益があるけど、ペルソナBには改修前のほうが良かった、みたいな場合です。
このようにペルソナ同士の利益が反する場合、どのペルソナを1位にするのか、2位にするのか、事前に序列を決める必要があります(東京書籍 I)。
多数決ではなく、人物の序列で決めるのがポイントです。
東京書籍はそこまで言ってないですが、カネなどを提供しない客以外の人からウケても、意味がありません。たとえば高校教科書の文章の設計なら、高校生でもなければ保護者でもなく高校教師や塾講師でもなければ文科省や教育委員会でもない、世間のオッサン・オバサンとか大学院生とか幼稚園児とかに受けても意味が無いわけです。
一例として、2位以下のユーザーからの要望は、1位のユーザーの利益に反しないかぎり、受け入れる、といった感じです(東京書籍 I)。
業界によっては、別の言い方で「メインユーザー層を決める」とか「コア層を決める」「コア層に従う」とか「メインのターゲット層を決める」みたいな言い方をするかもしれませんが、意味合いは大体、似たような感じです。
東京書籍が言ってるのですが、ペルソナを設定する際に、ユーザー調査ではなく自分のやりたいことから逆算して都合良いペルソナを設定するという、ダメな人が時々います。チーム作業とか他人のお金で仕事をしている場合は、そういうダメな自己表現はしないようにしましょう。
ユーザーを無視して自己表現で自分のアイデアを世に問いたいなら、自分のカネでやりましょう。他人のカネと時間を使うな。
ホームページを作る場合、上記で良いと思います。
もし、作りたいものがホームページでない場合、たとえば何かの画像を作りたい場合、そういうのに便利なツールを使いましょう。
文科省の教員用の教材では、ベクター画像の編集ソフトウェアについて、レイヤーの概念を教えています。
Windows『ペイント』には、レイヤーの機能は無いはずです。
ラスタ画像なら、お絵かきソフトなどで無料のソフトでレイヤー機能のあるソフトがあるので、それを使いましょう。もちろん、有料ソフトにもレイヤー機能のある製品が、ふつうにあります、。
検定教科書がwebサイトのコンテンツ制作を例にプロトタイプを説明してるが、全然、なってない。
JavaScriptとかそういうのは、後回し。特に、業者の作ったwebサイト作成ツールを使っている学校のwebサイトの場合、JavaScriptをいじるのは素人では無理。
なので学生・教職員の出来ることは、まず、普通の日本語の文章だけでいいので、文章または箇条書きなどで、必要事項を説明する。
HTMLファイルをいじる事になるが、この段階では、既存のタグはいじらないで、そのままにしておく。まだ、当面はタグは追加しない。
body タグのブロック内に本文を書くことになると思うが、まずは本文だけで必要事項を説明する。業者のwebページ作成ツールを使っている場合なら、ツールの操作指示にしたがって本文を記述すればいい。
文化祭のwebページなら、開催日とその時間帯といった日時とか、一般公開の有無とか、来校の方法とか(自動車・自転車は不可など)、そういう情報をまず列記。
見た目を整えるのは、後回し。CSSとか、後回し。そもそも業者ツールの場合、CSS編集できない場合すら、ありうる。
さて、出し物の一覧は、どこの高校でも、すでにそういうファイルがpdfなどで別途作成済みなので(印刷用にPDFをどこの高校でも使うので)、その既存のpdfファイルをアップロードし、ダウンロード用のリンクをwebページ内のどこかに配置。pdfアップロードの操作方法については、今時の高校のサイトは、業者がつくったツールの上に、アップロードしたいコンテンツを追加していく方式なので、それぞれのツールごとの操作を確認。
業者にも寄るが、アップロードの原理は単純で、単にファイルサーバーにpdfファイルごとアップロードして、そのサーバーのアドレスのリンクを href タグまたは別のタグなどで記述しているだけである。業者のツール側で、ファイルの種類を判断して、勝手に上手いこと、表示をしてくれる。
だいたい、どこの高校の文化祭サイトでも、
<a href="https://www.学校名.ed.jp/2023-文化祭-スケジュール-1.pdf">ダウンロード</a>
みたいなのがソースファイル中に書かれている。学生側は、ソースコードをイジル必要は無い。学生は、業者のツールに任せて操作すればいい。 むしろ、業者のツールに任せなければいけない。htmlファイルをいじるのは、保証のサポート外になってしまう可能性がある。
JavaSvriptの部分は、いじらない。どうしてもイジるなら、プロの技術者を確保すること。コンテンツの内容と、プログラムの両方を管理できる時間は無い。なので、プログラム専属の人が必要。そんな人手と予算が無いなら、JavaScriptはいじらない。
情報デザインやプロトタイプ開発をする際、話し合いなどで「ユーザビリティ」や「ユーザーエクスペリエンス」などの用語を使うかもしれませんが、これらの用語のいくつかは国際規格の ISO にも規定されています。
とりあえず、検定教科書と同じ意味で使っていれば、特に問題はありません。
ISO規格のうち、「人間中心設計」と言う分野で、定められています。
内容も、ユーザーのニーズを調査しろだとか、それを文書で残して明確化しろとか、ふつうの事が書いてあるだけです。
設計の基本を押さえていれば、問題ありません。
ユーザーニーズを把握して設計のアイデアが決まったら、そのあと試作品を作れとか、試作品を作ったらそれをテストして改善しろだとか(いわゆる「PDCA法」のこと)、そういう普通のことがISOの人間中心設計で定められています。
日本など先進国の技術系の会社では、こういった設計手法は常識ですが、しかし世界にはそういう設計手法が守れない未熟な国があるので、そういう未熟な国との貿易を断る口実がISOです。冗談とかではなく、実際に ISO を守れないと、欧州企業などからは取引停止などの口実にされるかもしれません。
仕事をする際、色々といくつもの事をしないといけません。そのための自分のスケジュールなどの管理方法としてToDoリストがあります。
要点は下記の通り
ToDoリスト作成の理由は、まず、忘れないようにメモ帳などに、やるべき仕事を箇条書きにしてリストアップするのは当然です。後述の作業のため、パソコンでリストアップしましょう。
加えて、重要度順、または締め切りの早い順に並び替えます。なぜ必要かと言うと、メモしないと、いつまでも頭の中で覚え続ける必要があるので、脳味噌を疲れさせてしまい、本来の仕事に集中できません。なので、メモする必要があるのです。
特にIT系の仕事や設計(英語で design デザイン)などの仕事は集中力を使うので、覚え続けるために集中力を使ってしまうと、本来のIT仕事に集中できなくなり、効率がかなり低下します。
また、順序を並び替えないと、いちいち、「どの仕事の重要度が、どのくらい高いか、低いか」を覚え続ける手間が生じてしまうので、やはり本来の仕事に集中できなくなってしまいます。
(新人ではなく)もしかしたら管理職なら、手配先(てはいさき)ごとに作業(タスク)を分類したりとかもあるかもしれませんが、しかしそれは新人の時点では、することではありません。新人が当面のあいだToDoリストでするのは、優先度順の並び替えです。
ともかく、優先度順にToDoリストの各項目を書く必要があるのです。
で、箇条書きにした各仕事にじっさいに取り掛かって、各仕事が終わったら、それぞれ終わった仕事に【完了】 とか 【済み】 とか、同じ行に書いておきます。終わった各仕事は、メモからは消さずに、「完了」とか書いて残しておくのがコツです。
なぜなら、あとから確認作業などのために、仕事を振り返ることがありますので。もし消すと、思い出すのに手間が掛かり時間の無駄ですし、集中力が下がります。それに振り返りもできなくなってしまいます。
なお、別の節で「問題解決」を紹介しますが、ToDoリストの作成も、PDCA法などと並ぶ、問題解決のための有効な手法のひとつです。関連付けて理解しましょう。
「何が解決すべき問題か、分からない」と言うときに、解決すべき問題を見つける方法のひとつが、箇条書きです。
まず試作では、最小の機能だけを設計する。これをMVP(Minimum Viable Product)と言う。
当wikiでは他の範囲外コラムでオーバーエンジニアリングを避けるべきことを注意喚起しているが、このMVPはオーバーエンジニアリングを避けるための手法の一つである。
文科省の教師むけ動画でも、たとえばチャットアプリを作るならメッセージのサーバーを介しての送受信とその保管だけを優先的に実装する例を出している。リマインダー機能やToDoリストなどの機能を、設計から排除している。なお、文科省の動画では、これを動画では「要件定義」として紹介している。
なお、同動画はPDF化されている。 『情報システムとプログラミング 情報システムを設計しよう』4.。
最終的にリマインダー機能をつけるかどうかはチームの目的によって異なるだろうが、とりあえずソフトウェアの開発当初の段階では不要だろう。(最低限の機能の実装も出来てないのに、あれこれと他の機能を考えても、ことわざでいう『とらぬタヌキの皮算用』みたいなもんでしかない。)
開発コストを下げるため、こういうのが必要。余計な機能をつけると、開発コストが増大しやすいので、あまり余計な機能を増やさないほうが安全。
オーバーエンジニアリングを避ける手法の一つ。
(資料では言及していないが、)開発が長引いたりすると、当初の問題意識が何だったのかの記憶が薄れたりして、不明確になりやすい。
または、すでに開発初期から、チームメンバーごとに目標が微妙に食い違ってしまっている場合もある。そうすると、トラブルが起こりやすくなる。
なのでトラブル防止のため、開発の初期に、その製品開発が満たすべき第一目標や優先目標などの目的を明確にチームで共有する必要があるので、そのために言語化してイメージを共有する必要があり、このような優先目標などの言語化を「ゴール設定」などとビジネスでは呼んでいる。
たとえば、遊具をデザインするなら、「幼児~小学生を対象に(ターゲット)、楽しく安全に遊んでもらう(目的)」のようにゴール設定するのです。

なお、この遊具の例のように、ゴール設定の際、メインの使用者層の設定も必要になることがあり、その使用者層のことを「ターゲット層」などとビジネス用語ではよく言います。
デザインでは「使用者(ターゲット)」の設定が必要だと説明しています。
ターゲット層を設定する際も、ペルソナ法などを活用して、そのターゲット層の代表的な人物の性格・職業・趣味・夢などの具体的な人物像が分かるレベルにまでターゲット層を明確に設定しましょう。
一般向けのグラフィック系のデザイン入門書でも「ゴール」と呼んだりもするかもしれません。高校の検定教科書(日本文教出版の情報IIでも、「ゴール」という言い方はしていませんが、「目標」という言葉で、ゴール設定と同じことを紹介しています。)
ターゲット層を設定しつつ、その領域を拡大することも経産省は求めてます『デジタルスキル標準』P.87。 ※ 「(ターゲットとなる顧客・ユーザー、領域の拡大等)」と言う文言が試料中にある。
書籍『浦和高校論文集』(佐藤優 編著、K&Kプレス、2019年)を読んでいたら、2010年代の公立高校の高校生が卒論で「ターゲット」という言葉を特に注記なく普通に使っていました。。コメダ珈琲について、「コメダはモーニングというサービスがある。コーヒーメニューを注文すると、厚切りのトーストとゆ卵がついてくるというサービスだ、朝の時間帯、特に独身のサラリーマンをターゲットにし成功している。」。という文章です。
2010年代の公立高校生でもターゲット層という概念を知っているんだから、2020年代の高校生だったらもう知ってて当然でしょう。
ターゲットの設定法は、モニタリング(観察)とすでに習ったプロトペルソナ法である程度は対応できるでしょう。
さらに「KPI」(ケーピーアイ、Key Performance Indicator)の知識と活用を、経産省『デジタルスキル標準』では求めています『デジタルスキル標準』P.87。KPIとは、実際にその商品がどれだけユーザーに好まれているかを、現実の自分らの提供中の商品分析から実証的に定量化した統計データです。
たとえば、自社のwebサイトが人気があるかどうかを確認したいなら、決してアンケートなどではなく、実際にそのサイトの1週間や1月など期間あたりの閲覧数のをもとに判断するのが、KPI的な考え方です。閲覧数など統計を記録した上でならアンケートなど実施するのも構いません。(アンケートはKPIとはあまり関係ないので、説明を省略します。)
閲覧数を記録するサービスをさらに細かく分けていけば、どのサービスに人気があって、不人気なサービスは何なのかとかわかっていき、改善点などが判明していきます。PDCAサイクルにおける、チェックの手法の一つと言えるでしょう。文字アンケートだけのチェックだと、文章が得意な人しか回答してくれなかったりして、消費者などの実態を反映しづらいので、なのでKPIによって実際の消費者らの行動を測定します。
経営学などの格言で「人の言ってる事とやってることが違う場合、本音はやってる事のほうだ」という感じの格言があります。KPIもそれと同じで、ユーザー層たちの実際にやってる事を分析します。
ただしKPIだけではユーザー層の細かい感情が分からないので、別途、インタビューなどを中間的にユーザーの一部に行います。ただしそれはKPI分析とは別の作業なので、インタビューについては説明を省略します。

たとえば文化祭のwebサイトの効果を測定したいなら、個々のページの閲覧者数や予定表PDFなどのダウンロード数だけでなく、さらに入場チケットの予約数とか、実際の文化祭当日の入場者数とか、そういう数値も記録するべきです。
とはいえ、不祥事などによって閲覧者数を増やしても意味がありません。そこで、そのKPIで設定した測定項目の前提として、ゴールも設定する必要があります。
たとえば文化祭サイトのゴールなら、「学校のために足で出向いて文化祭に来てくれるようなファンを増やす」あたりがゴールでしょうか(ゴールは学校によりますので一例です)。
KGIという、ゴールがどのていど達成されてるかを測定する指標の概念もありますが(企業なら「売上」や「利益率」などをKGIに設定する)、これは高校生にはどうしようもないので、説明を省略します。
ただ、ゴールを意識化することは高校生でも可能でしょう。
企業でKPIを設定する場合、単に閲覧者数や訪問者数などだけを記録するのではなく、さらにそのうち購入者数がどれだけいるかや購入率(購入者数をサイト閲覧者で割った数値)なども記録します。
高校の文化祭の場合、商売をしているのではないので購入者数や購入率は記録しようがありませんが、そういう事も覚えておいてください。ビジネスでは、カネを出さない人にウケても意味がないので。
購入率を見るのは、たとえば、閲覧者が1千人だけど900人に売れている商品Aと、閲覧者数が1万人だけど2千人に売れている商品B、売れ行きが良いのはどちらでしょうか? という問題です。ゴールにも寄りますが、投資効率で見れば、普通は900人に売れている商品のほうが投資効率が良さそうと見るでしょうか。(ただし、経済学には「規模の利益」といった概念もあるので、場合によります。)
高校の文化祭なら、購入者数の代わりに、実際に文化祭で入場した人などの割合も記録することになるでしょうか。これはチケット予約の状況などを測定すれば、ある程度は事前に推測可能でしょう。もちろん、当日の入場者数も記録しましょう。

企業などでのKPIの測定では、リピーターの人数およびリピート率も測定したりします。
たとえば、(開店の初日でもないのに)もし1回しか商品を購入しない人の割合が多いとすれば、「きっと、購入者の多くが実際に購入したときに、不満があったのだろう」と問題点が存在しそうな可能性の高さを想定できます。
なので、リピート率を何らかの方法で測定します。
高校ではそこまでの測定は難しいかもしれませんが、こういうのがKPI的な分析方法です。

こういうツールを、アクセス解析ツール(web analytics tool)と言います(※ 日本文教出版 II ・P.38)。
Google Analytics はwebサイトの作り手が解析用のタグをソースコード中に貼り付ける方式であり、このような方式をwebビーコンと言います(※日本文教出版でwebビーコンをweb解析ツールの単元で紹介)。
webビーコン型のほかにも、サーバログ取得型やパケットキャプチャリング型があります(※ 日本文教出版II)。
暗黙の前提だが、たとえ利用者側が「送信」ボタンとか「購入」ボタンとかそういうボタンを押さなくても、webサイトにアクセスした時点でサーバー側にはアクセス記録が残ることになる。
KPIは、単に数値を表で羅列するのではなく(表にすらしないよりかはマシですが)、できればグラフにしましょう。
KPIを算出する目的は、改善点などの問題発見のためです。なので、グラフ化することで、問題発見をしやすくしなければなりません。
なお、このような複数の別々の項目の最新データをグラフ一覧としてまとめたものを「ダッシュボード」と言います。
なお、Google 以外のクラウドサービスでも、たとえば教員の使っている授業用のクラウドソフトなどにも「ダッシュボード」という機能があり、生徒の状況(出席日数とか成績とか)などをグラフ化して、定量的にモニタリングしています。
経済産業省は、デザインとは基本的には問題解決に寄与すべきものでなければならない、というような見解です。
で、内閣官房などの命令で、文部省と経済産業省などはICT教育において連携するようにと、それぞれの官庁は命令されています。
ともかく、IT系やビジネス系の業界で「デザイン」の仕事をうけおう場合、問題解決を優先しましょう。
詳しくは、下記コラム。
箇条書きメモの必要性(※ 範囲外)
ほかの節でもメモなどの箇条書きの必要性を述べてますが、設計などの仕事などをする際、手元のメモには必要事項などを箇条書きをすると良いでしょう。「何が解決すべき問題か、分からない」と言うときに、解決すべき問題を見つける方法のひとつが、箇条書きです。
もし分業や外注などをする場合でも、箇条書きをしてあることによって、どの作業を分業すればいいか把握しやすくなります。
箇条書きをしたうえでなら、箇条書きでは説明しきれないことがあれば文章にするのも構いませんが、まずすべき事は箇条書きです。

ウォータオフォールとかスパイラルモデルとか。
ただ、高校生の段階では、ウォーターフォールは使わないだろう。
システムへの高度な専門知識がないとウォータオフォールは使いこなせないので。
NHk『情報I』で最終回で言ってたのですが、学校で探究活動や実習などで課題の解決案を出したら、なるべく学外にも公開しましょう。たとえば、地域の課題をIT技術で解決しようとする探究活動をしたなら、その成果の知見を当の地域の人たちに公開しましょうと、そうNHKに出演した大学教員は言ってます。
しばしば、せっかく新しい発見やアイデアを出しても、それが学校の中だけで完結してしまい、社会に何も還元しないことがあります。また、学校内で情報の流れが閉じていたりすることがあるのも問題です。
自治体でも、地域との交流のため、東京など金のある地域では、自治体の主催によって、地元の学校どうしの探究発表会を開催しています。さて、そもそも、公立高校は税金で補助を受けてるのですから、成果はなるべく発表しましょう。
また、自治体や教育委員会などは、こういう、高校どうしの情報共有や連携などの取り組みを支援しなければなりません。NHKの例でも、アンケート調査をする探求学習で、自校だけでなく他校にもアンケートを取っています。自治体はこういう学校間連携ができるように、教育環境整備しなければなりません。生徒や教職員だけの努力では無理です。ほかの公務員などの大人も仕事をしなければならないでしょう。
情報デザインを、もしかしたら将来は小学校で教えるかもしれないというニュース。小学校で新教科として情報科を設置する案があり(未決定。あくまで案)、その教育実験が東北の教育大附属の学校で行われている。
後述するKPT的な話のほか、構造化の話もしている。なお、構造化については本wikiでは『高等学校情報/情報の科学/構造化』に解説がある。ほか、対象者を明確にせよ、という話も上記の実験授業にある。ターゲット層の話。情報I・Iiの検定教科書でも、一部の教科書でターゲット層の話をしている。
ほかに紹介されたものを、上記の構造化とまとめて次に列記すると、
なども上記の実験授業にある。
(※ 「比較する」というのが何か、よく分からない。A/Bテストのことだろうか? それともソフトウェアデザインにおける模写のことか(他人の上手いソフトウェアの挙動と自作の挙動とを見比べる方法。)? )
上記ニュースでもあるのだが、なにかの告知ポスターらしき作品を作らせて、生徒どうしで成果物のレビュー(品評)を行わせている。
その際、「良かった点」と「改善点」を生徒どうしに述べさせている。評価を受ける際、他人からの評価を受けるのがポイントである。上記ニュースのリンク先でも、実験校の教師がそう指導している。
作り手の自分だけが分かっても、意味が無い。基本、ポスターというのは他人に何かを伝えるために作るので、他人から見て分かりづらいなら、反省点にしなければならない。
「改善点」を言わせるのがポイント。
「分かりづらい」という感想だと、言われた相手(作り手の側)にとっては改善点が何なのかが分からない。なので、生徒どうしで品評する場合は「問題点」ではなく「改善点」として、生徒の「漢字にふり仮名が無いので読みづらかった」という感想をもとに「ふりがなを追加すべき」という改善点になる。
下記のKPT法(ケプトほう)という品質改善手法が、これに近いだろう。(ただし、KPT法では「改善点」ではなく「問題点」を集めるという違いがある。)

プレゼンなど発表をした際、または発表前に仲間内でシミュレーションする際など、発表の良かった点・改善点を信頼できる仲間内で評価しあい、今後の改善につなげると、役立ちます(※ 数研出版の副教材の見解)。
※ 数研出版はここまでしか言ってないのですが、なぜそうすると良いのかwiki側で追加説明します。人によって、良い点ばかり気づく人もいれば、改善点ばかり気づく人もいて、人ごとに片寄りがあります。このため、発表などを評価しあう際、事前に評価シートなどに「良かった点」「改善点」の両方とも記入欄を用意したりすると良いでしょう。
世間には、お世辞ばかり言ってロクに発表内容を聞かずに「全部良かったよ」とか言うクソ野郎とか、その逆に発表者が嫌いとかの理由で全部ケチをつけるクソ野郎とかいるので、そういう人を排除するためにも「良い点」「改善点」の両方をします。というか、たぶん数研出版の編集部で、こういうふうに原稿などの「良かった点」「改善点」とかの相互評価をしているのでしょう。
「KPT法」(ケプトほう)というビジネス手法があります(KPIとは異なる)。Keep、Problem、Tryの略です。
良かった点は、今後も続けて欲しいので Keep (継続する点)、改善点は問題点が由来なのでProblem(問題点)、そして、KeepとProblemをもとに今後に挑戦すること(Try)を決める、という手法です。
ネット上ではKPT法とアンケートを関連づけてる記事は特にないのですが、しかし上述のように、アンケートで「良かった点」・「悪かった点」を最初から記入欄を設けることにより、アンケート収集者はKPTを自然に実践できるでしょう。
アンケートでは、KeepとProblemだけで十分だと思います。上記の数研出版のアンケート例でも、良かった点(Keep)と改善点(Problem)しか自由記述欄が無いし。
なお、Problemのアンケート結果で問題点の報告が集まったら、それをもとに、本質的に解決すべき課題を決める必要があり、この今後の課題のことをイシュー issue と言います。(なお、GitHubなどの管理サイトを使っていると、issueという項目がある。かなり高度に専門的な話だが、イシュー管理ツールとかチケット管理ツールとかいうサーバーソフトがあって、それで issue を管理できる。専門的すぎる話なので、読者は分からなければ、このカッコ内は読み飛ばしていい。)
issueを書く際、「なぜ困っているか」Whyという情報は、「何に困っているか」What に変換しましょう。最終的に解決する必要があるのは、目的語となる What だからです。
読者がもしToDoリストを知ってれば、このissue解決も、ToDoリスト上の解決すべきタスクに加えます。
そして、チーム開発をしているなら、issueを開発チーム内に報告して、情報を共有します。
Keepのアンケート結果は、今後の仕様とするかどうかを決めます。仕様とすると決まった場合は、それを社内のその製品の開発マニュアルなどのチェックリストに入れて、確実に今後も長所が反映されるようにします。
なお、アンケート回答者にProblemを書かせる際の注意として、改善策まで書かせないことです。改善策があると、別の工程(Try)が混ざってしまっているので、かえって分離の手間が増えてしまうので、収集側にとっては非効率になってしまうからです。改善策については、収集者の側で Try として考えます。そのため、「悪かった点」「問題点」などのような記入欄の題名にするなど、あえて否定的な表現の題名にすると良いでしょう。
つまり、Problemには、困りごとについて、5W1HでいうHowの形式で、実際に起きた事例をなるべく書きます。
改善すべき問題点は、放置すると今後の脅威になりうる問題点のみです。単に、苦手を克服することに価値はありません。
たとえば、アナタがもしベトナム語が苦手だとして、これからベトナム語を練習して得意になっても、ベトナムでの仕事に就職できなければ、そしてベトナム文化の研究とかの特技でもなければ、経済的にはアナタのベトナム語の練習の価値は低く、単なる趣味・道楽とみなされやすいのと同じです。
SWOT分析(「スウォットぶんせき」と読む)というのが、脅威に備える現状認識法であり、強み(Strength)、弱み(Weakness)、機会(Oppotunity)、脅威(Threat)、の分析です。
SWOT分析は、課題解決の方法ではなく、現状認識の方法です。これらの思考ツールでいう「分析」とは、未処理では複雑・漠然(ばくぜん)で把握しにくい情報を、細かく具体的な情報に分けることです。分析と聞くと、ついつい原因を考えたくなりますが、しかしここでいう「分析」とは、原因を考えることではなく、分けて具体化することです。
SWOT分析など分析ツールそれだけでは問題解決できず、その分析で得られた具体的な情報をもとに別途、問題解決を考えていく必要があります。
さて、日本語の「弱み」という言葉のニュアンスとは、やや違っています。SWOT分析でのWeaknessは「脆弱性」(ぜいじゃくせい)のようなニュアンスです。よく「セキュリティ脆弱性」とか言いますが、その脆弱と同じニュアンスで、放置すると脅威を引き起こす、呼び寄せるものの事です。
たとえばポスター作りの「弱み」なら、「自分はいつも誤字脱字が多い」とか「文化祭ポスターの試作で、校舎をえがいたつもりなのに、どうやら観客には市役所の庁舎に見えてしまっているようだ」とか、そういう今後のトラブルを起こしそうな「脅威」になりうるレベルなのが「弱み」です。単に、「漢字検定2級をまだ取得してない」とかそういうのは、とりあえず放置しても今後の脅威にならないので「弱み」ではないのです。
すでにKPT法で分析している人は、いちいちSWOT分析を書き始める必要はありません。ただ、KPT法を活用する際、SWOT分析を知っていると、より上手にKPT法を活用できるようになります。
さて、私たちの今の目的は、「収集したアンケート結果の、今後のための分析と活用」です。目的、ゴールを、はっきりとさせましょう。この節では、KPT法への活用を想定して、SWOT分析の考え方のうちKPT法への流用に必要な部分だけを説明します。ゴールに寄与しない事は、後回しで良いのです。
ともかく、脅威にならない単なる苦手といった弱点は、改善の必要はありません。むしろ企業社会では、株主や銀行などは、脅威にならない弱点克服は単なる道楽(どうらく)みたいな扱いをします。
ターゲット層にウケない弱点克服をしても、意味がありません。たとえばベトナムで商売してない会社に就職しようとするのにベトナム語をいきなり練習しても、大して価値が無いのと同じです。
経済は「分業」とか比較優位(ひかく ゆうい)とかで動いているのですから、ベトナム語はベトナムの専門家に任せればいいのです。親戚がベトナム人とかでないかぎり、いちいちベトナム語を勉強しても、経済的には利益を得づらいのです。
ベトナム語の例なら、「ベトナム語の就職への活用をあきらめる」と言うのも改善策です。そのジャンルから「撤退する」「他の企業や競争相手に任せる」等も解決策です。実際、SWOT分析でも、「市場撤退」も、脅威への解決策の一つです。
さて、改善をする際、強み(Strength)を損なわないように改善する必要があります。
たとえば、ポスターに掲載する情報を増やすと、情報不足という弱点は解決しますが、そのぶん一つ一つの情報が目立たなくなります。どちらを優先すべきかは、用途によって変わります。」
よって、確保すべき強みに、優先順位をつけましょう。なお東京書籍の教科書では、別単元ですが、プロトペルソナ法の単元で、どのペルソナ(架空のユーザー層)を1位にするのか、2位にするのか、事前に序列を決める必要があると主張しています(東京書籍 I)。
ポスターを例にあげましたが、ソフトウェアのUIなども同様でしょう。
なお、どんなに強みを強化しても、基本、ぜい弱性は解決しません。たとえば、誤字脱字や誤情報のあるポスターで、どんなに絵を上手に書いても(あるいは写真を上手に撮影しても)、そのポスターの誤字や誤情報は解決しないのと同様です。
たとえば「虫歯の治療」のようなものです。虫歯のある小学生が(ぜい弱性)、その子の小学校の成績が良くて(強み)、どんなに小学校の勉強を頑張っても、何も虫歯は解決しません。歯医者に行くとか、せめて歯磨きを毎日するとかしないと、問題は解決に近づきません。
私たちの当初の目的を忘れてはいけません。このページの場合、当初の目的は「収集したアンケート結果から、今後のための改善策を考える」ことが目的です。
SWOT分析とかKPT法とかをあれこれと覚えることは目的ではなく、ゴールに寄与しません。単にこの節では、考え方の例示をしているだけです。
デザインレビュー(design reviews、略称:DR)と言う言葉があり、何かデザイン物を作るとき、いきなり本番にせずに、制作チーム内に設計案を提出して、チーム仲間たちに品評してもらいます。
なお、製作チームの仲間内でないレビューは、デザインレビューではなく、単なるレビューです。
どちらのレビューにせよ、アンケートなどで他人の製作物の問題点を書くとき、改善策につながりやすいように具体的に書くのがコツです。一言「わかりづらかった」とか「いまいち感」とかは論外です。そういうのは問題点ではなく、単なる感想です。仕事でないなら、そういう感想を言うのもいいですが、しかいs仕事の場合のレビューなら、「問題点」というには、「解決すべき問題は何なのか」がハッキリしないといけません。仕事でのレビューでは、なるべく解決すべき問題をハッキリさせましょう。
たとえばポスターの問題点なら、「文字が小さすぎる(または「大きすぎる」)」とか「文字が多すぎる」とか「文字の色が背景色と近くて、読みづらい」とか「コントラストがキツくて読みづらい」とか、「子どもに来てほしいイベントなのに、子供が読めない漢字が多い。ふりがなも無い」とか「絵の線と文字の線とが密集していて、文字が読みづらい」とか「絵がイベント内容と違いすぎて、てっきり別のイベントだと誤解してしまった」とか・・・(以下略)、そういうのが問題点です。このように」具体的に問題点を書けば、あとは作り手は、その意見をもとに改善策を考えられます。
改善策については、たとえば1つの問題点について、複数の改善策があるので、それを作り手の側で考えます。たとえば問題点「文字の色が背景色と近くて、読みづらい」なら、解決策は下記の2つ以上あるわけです。
などです。
なので、「問題」には、解決策を混ぜてはいけません。混ぜてしまうと、ほかの解決策を見落としてしまうからです。
上記のように改善策は複数個あるので、改善策については Problem には含めず、作り手側に判断を任せます。
しかし、ここまで問題点を具体的に報告できるようになるためには習熟が必要なので、教育的には、初心者はまず改善策を報告するようにしたほうが良いかもしれません(※ じっさい、数研出版の教科書のアンケート例でも「問題点」ではなく「改善策」を記述させている)。
ほか、論外の感想として、ポスターの感想なら「絵がヘタ」とか「文章センスが無い」とか、そういうのも論外の感想です(こういうのは「問題点」「改善策」とは言いません)。なぜなら、解決のための絵の練習に時間が掛かり過ぎるので。暗黙の前提として、提示すべき「問題点」や「解決策」は、短期間かつ低コストで実践が可能な解決策でなければなりません。
さて、医療看護系の問題解決ツールで提案されているフレーズで、「す・じ・こ」というのがあり、「(す)すぐに着手できる、(じ)実現可能である、(こ)効果的である」というのがあります。
レビューでもPDCAでも、なるべく「すじこ」な提案をしましょう。
上述の「絵がヘタ」とか「文章センスが無い」は、すぐには着手できないので論外です。
ほか、論外のよくある感想で、ターゲット層を無視した感想があります。
たとえば、マンガとかのレビューで、幼児むけのマンガ本やアニメなのに、大人が「もっと、大人の好みにあうように○○にすべきだ」みたいな感想もよくあります。自分の好き嫌いと、社会の要求との区別がついてない、頭のわるい大人です。「自分の好みの作風 = 上手い作品」という人は、大人も子供も、けっこう多いです。