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

問題解決とは

まず、「問題」とは、理想と現実のギャップのことです（※検定教科書にそう書いてある）。

そして、問題解決のための「課題」とは、そのギャップを埋めるために具体的にしなければいけない事です。

まず、問題や課題を正しく認識するために、なるべく数値的に認識することで、検証可能な形で（※ 実教出版の見解）課題を表現する必要があります。

たとえば、部活をつくりたいのにメンバー不足な場合、目標は、けっして「部員を増やしたい」という表現はなく、もっと数値的に「最低でも部員が10人になるまでは部品を確保したい。5対5で対戦の練習ができるから」のように具体的に課題を数値で設定する必要があります（※日本文教出版 I）。また、理由も併記すると、応用が利きます。

さらに、文章で課題や情報収集のインタビュー結果などを表現する場合でも、なるべく5W1Hが分かるように記録するべきです（※ 開隆堂の見解）。解決案を提示する場合も、なるべく分かりやすい表現にしましょう（※数研出版）。これが出来てない場合、解決案として、そもそも不十分な可能性があります；。

※ 検定教科書では言及されていませんが、問題解決のために情報収集をする場合、時間の制限がありますので、とりあえずの仮説が見つかったら、さっさと検証しましょう。

（※ 範囲外）SMARTゴール

上記のような、具体的とか、測定可能とかの要求事項をまとめて、下記の「SMARTゴール」があります。 Specific（具体的） Measurable（測定可能） Achievable（実現可能） Relevant（最終目標への関連性が高い） Time-bound （期限が定められている） の頭文字の略です。 PDCA法などでは、SMARTゴールを意識しましょう。

さて、理想や目標がいくつもある場合はどうすればいいでしょうか。

現実には、時間や金銭などの制限があるので、すべての理想や目標が達成できるとは限りません。

理想や目標が複数ある場合や、チーム作業などで今のままでは意見がまとまらない場合には、自分またはチームの理想・目標に優先順位をつけるのが効果的です（※ 第一学習社 P.5、※数研出版 P.18）。

部活でも趣味でやってる練習なら、好きな時間配分で練習すればよいですが、しかし、もし部全体として「試合に勝ちたい」とかの目標があるなら、部の勝利のために効果的な練習に時間を優先的に配分する必要があります（※ 数研出版）。例は運動部でもなくても良く、別に体育祭でも何でも良いです。

課題や目標が複数ある場合、トレードオフの関係にある場合もあるので、そのことを認識する必要もあります（※ 実教出版、数研出版）。少なくとも、学校での部活の課題の場合、部費と言った費用の限界、練習場と言った場所の限界があるので、決して無制限に何でも叶う（かなう）なんて、ありえません（※数研出版の見解）。

※ 大人でも、これが出来ないダメな大人も多い。そういう大人は反面教師にするように。

PDCAサイクル

練習量の多さに満足してはいけません。

スポーツなら、本番前に、本番を模した予行練習とかをしてみて（※ 開隆堂）、自分たちの練習法が果たして本当に正しいのかを検証しなければいけません（※数研出版）。

実際の戦績などを見て、もし練習しても成果が出て無さそうなら、練習法を直さないといけません（※数研出版）。これがPDCA法の考え方です。

なにかの理論通りに練習してみれ成果がいつまでも出ない場合、その理論は間違ってるのです。

そして、本番が来たとします。本番が終わったあとも、本番での自分たちの結果を記録し、来年以降に後輩などが役立てられるように備えます。または、自分たちが来年以降に役立てても構いません。　（いわゆる「アーカイブ」化。普段は使わないが後年に使うかもしれない情報を記録して整理して残して資料化したものをアーカイブと言います。）

※ 文脈は違うが教員研修資料で「アーカイブ」と言う用語が使われてるので、ついでに「アーカイブ」という言葉も覚えよう。国語の外来語の勉強。なおアーカイブの語源はラテン語。

※ 『情報』の教科としては「アーカイブ」という単語は範囲外だろう。

また、本番の結果もPDCAサイクルの一部にして、練習方法などを検証してみたりもします（※数研出版）。

スポーツを例にして説明しましたが（なお日本文教出版の例）、工場の品質管理や生産管理などにPDCAサイクルの手法は応用されています（実教出版）。

（※ 範囲外）暗黙の前提ですが、PDCAサイクルはなるべく短期間で回す必要があります。つまり、世の中には反面教師として、Plan→Do→Do→DO→Do→・・・ みたいにやたらとDoが長かったりして何か月もかかったり、あるいはPlanが長かったりして何か月もかかり、一向に検証 Check や修正後の再行動 Action につながらない人がいて、これではPDCAが形骸化（けいがいか）しています。

計画は3W1Hで

PDCA法などでの、期限などを含む計画の立案（Plan）では、「誰が、いつまでに、何をどうするのか」という3W1Hに落とし込む必要があります。上述のSMARTゴールも意識しつつ、3W1Hにして「誰が、いつまでに、なにをどうするのか」を明確に言語化します。関係者が複数人いる場合、「誰が」には、責任者・担当者といった代表人物を書きます。 その3W1Hを書く際も、箇条書きで 担当者： 期限： 何を／どうする： のように書くと良いでしょう。 実際に文章を描く際には、場所（Where）などを「何を／どうする」欄に書くこともあるかと思いますが、慣習的に「3W1H」と言われています。ほか、Why（なぜ）は、計画の立案では不要です。

ネットのビジネス論を真に受けてはいけない

ネットには、「PDCAサイクルはアイデア出しには向かない。品質改善に向く」という言説もありますが、いろいろと間違っています。 証拠として、日本文教出版の『情報I』には、PDCAサイクルの例の実話風の物語として、「解決策の立案」で、バスケ部員たちがアイデア出しで、アンケートを取った結果、 高校生の発言「バスケットボールの経験者が多い事が分かった」「なぜ高校でバスケットボールをやらないかは、練習がきびしそうだからという答えが多かった」という結果をもとにアイデア「体験入部を開いて部の楽しさを知ってもらおう」 と高校生キャラがアイデアを出す挿し絵（さしえ）マンガがあります。 また、工場などの品質改善の仕事は、よほどの低品質の工場を指導するのでないかぎり、品質管理部門では思考なしのパターン反復ではできません。 なぜなら品質管理部門の仕事とは、そもそも作業員が作業手順書どおりに作業しているはずなのに品質が下がったりして困っているのを解決するために不具合の原因を分析したりする仕事だからです。 決して、単に不良品の発生率の統計を取るだけの仕事ではありません。仕事には、不良品の統計を取る事も含まれていますが。 また、作業手順書どおりのパターン反復が要求されているなら、そもそもPlanは不要です。なぜならPlanを考えるのは末端の作業員ではなく、設計部門だからです。 このように、ネットの言説がいろいろと間違っています。 ネットの言説はいろいろと低品質なので、ネットではなく検定教科書や参考書をきちんと確認しましょう。 おそらく、就職先のブラック企業か何かの不満を、PDCAサイクルに欠点があるのだと混同しているのでしょう。そのブラック企業で人生で初めてPDCAサイクルを習った人も多いのでしょう。

（※範囲外）問題解決のための調査の時間制限

現実では、問題解決の方法を提案するために調査や分析をするさい、締め切りや期限といった時間の制限がある場合も多い。 たとえば、もし高校の部活での他校との試合の勝率を増やすための問題解決なら、その解決案は高校の部活在籍中の3年の夏までに実行できなければ意味が無い。 常識的に考えれば、高校の部活のためのデータ分析をする場合なら、数日中に解決策を提案しなければならないでしょう。 なので、高校入学後に3年以上の時間をかけて数学を勉強してから解決案を出しても、その前にすでに高校を卒業してしまっており、その案には何の意味も無い。同様、インタビューなどの情報収集に3年以上をかけたり、データ分析などを3年以上かけても、意味が無い。 このように、実用のデータ分析では、精度を犠牲にしてでも期限に間に合わせる必要がある場合も多いのです。 もちろん、最初の解決策は精度が低いので、期限後にあとから修正して、より良い解決策に変えるという追加作業が必要になります。ですが、まずは期限内に間に合わせて、とりあえずの解決策を提示する必要があります。 ほか、データサイエンスとは別ですが、一般的に何か目標を立てる際には、スケジュール的に遠すぎない中間目標を立てるのが常識です。受験で志望校に合格するのが目標なら、たとえばまずは期末テストの成績をよくする途中の目標を立てる必要があり、さらにそのために来週までに〇〇をする的な目標が必要にある、といった類です データ分析にかぎらず、テクノロジーの応用の世界でも、時間に限りがありますので、その時間の範囲内で成果を出せるようにする必要があるので、そういう注意事項があります。「オーバーエンジニアリング」（over engineering）といい、過度な技術適用による非効率化のことを言います。 たとえば、ソフトウェアの設計の場合、あらゆるバグを想定して個別に対応したコードを書こうようとしてしまうと、コードが長大になってしまい、保守性がいちじるしく低下してしまいます。 システムのあらゆる部分にバックアップを持つのも、時間的にも費用的にも不可能であり、オーバーエンジニアリングです。 シンプルに計画を立てて、少し念入りに検証すれば充分なものを、いちいち複雑な大学レベルの個別事例の数式を用いて、長い時間を掛けて分析するのは、本末転倒であり、まさにオーバーエンジニアリングです。

情報デザインとプロトタイプ開発

※ 情報デザインは情報Iの内容です。プロトタイプは情報IIの内容ですが、wikiの都合上、こちらのページでも紹介します。なお、日本文教出版が『情報I』で「試作」の用語でプロトタイプを説明。

※ 教員研修用飼料では、情報デザインとプロトタイプ開発を同じPDFで説明している著者非公開（当時） 『高等学校情報科「情報Ⅰ」教員研修用教材（本編） 第2章　コミュニケーションと情報デザイン』

※ 「総合的な探究の時間」との関係もある。

※　日本文教出版『情報I』はブレーンストーミングと関連づけて説明しているが、他社教科書では関連づけてない。

情報デザイン

デザインとアートの違い

デザイン（design）とアートは違います。デザインは自己表現ではありません。東京書籍かどこかのサイトにある情報科目のパンフレットでは、アートとデザインは別物だと、イメージ画像で説明しています。

なんだかピカソ的な良く分からない絵や像をつくるのがアートで、そうではなくて図解などで文字を読まずに（もしくは少ない文字で）絵だけで分かりやすく説明するのがデザインです。

デザインのうち、情報デザイン（information design）と言われる分野があります。

アートと情報デザインの違いとして、上記の違いのほかにも、アートは多様な解釈を許しますが、情報デザインでは解釈を、正しい解釈だけで一通りに人々に受け取ってもらえるようにしなければなりません（※第一学習社）。たとえば、もし外国人など文化の異なる人が道路標識や非常口マークやトイレのマークなどを見たら（こういった標識も「情報デザイン」の例です）、その意味を一通りに理解できないと、事故の原因になってしまうので、情報デザインでは一通りの解釈でないといけないのです。

余談ですが、色は国によって解釈が違うので、ピクトグラムに色を使うときは注意が必要です（※第一学習社）。たとえば太陽の色は、日本では赤で表す人が多いかもしれませんが、外国では白や黄色で表す人が多い国もあります（※第一学習社）。普及しているピクトグラムを見れば、色を見ずとも形状だけでも意味が推測できるようになっているデザインが多いでしょう。

なお、情報科目だけでなく、美術2でも似たようなデザインとアートの違いについて習います

じっさい、美術の教科書会社のサイトにある動画でも、そう言っています。

デザインは問題解決のために、観客に分かりやすく、観客が楽しめるように絵を交えて説明する絵画作品のことです。

なお、デザインする仕事の人のことを「デザイナー」と言います。

ともかく、デザイナーは作品で情報が分かりやすく伝わらないと意味ないので、なので普通の人の気持ちもある程度は分からないといけません。

なので、情報デザインの授業でたとえば「学校の紹介をするwebサイトを作ろう」みたいな事になった時は、きちんと分かりやすいwebサイトを作ってください。

なお、別単元の「プロトタイプ開発」なども参考にするとよいでしょう。

教科書会社によっては「プロトタイプ」と言う呼び方ではなく「試作」と読んでいる会社もあります。まあ、内容は同じで、要するに試作してから、細部をつめていきます。

パンフレットやwebサイトなどの情報伝達メディアを作る場合、対象者（ターゲット）に分かりやすい表現をする必要があります（※ 日本文教出版I・P96、開隆堂）。

特に幼児や小学生などの子供向けの場合、それらの年齢層にも分かりやすい表現が必要です（※ 開隆堂）。

※ いっぽう、大人でも、対象者を無視して、難解な自己満足の表現をするダメな大人もいます（難しい表現のできる自分を「国語力が高い」みたいに思ってる）。そういう、高校生未満の頭のダメな大人は、決して見習わないようにしましょう。

日本文教出版『情報 I』いわく、「わかりやすさ」「見やすさ」「読みやすさ」が、情報伝達メディアを作る際のポイントです。

プロトタイプ開発

基本

デザイン（『設計』という意味）の分野では、けっして、なんでもかんでも議論で決定するべきではありません。

アイデアの良さを確認する場合は、実際に試作品をつくって、アイデアがうまく行きそうかどうかを、実験的に手を動かして確認してみることも必要です。

たとえば、あるウェブサイト用のイラストを描く場合を例をあげると、まずラフ画（簡略化した線画などからなる、おおざっぱな絵）を書いて、協力者や依頼者などにラフ画を見せて意見を出してもらって、構図に問題が無いかなど、いろいろと確かめます。

あるいは、大まかな線画に加えて色も大まかに塗るくらいなら、いいかもしれません。

そしてウェブサイト用イラストの場合なら、まずラフ画ができたら、そのラフ画をさっさとスキャナーなどでデジタルデータにして、先にHTMLファイルなどで製作中サイトに表示してみて、いろいろと確かめてます。

たとえば、ラフ画が色付きなら、「その画像の色は、はたして本当にこのサイトで表示しても大丈夫か？ 文字の色と紛らわしくないか？ サイトの背景の色と紛らわしくないか？」とか様々な問題点の有無を確認します。

（たとえばNHk教育『社会と情報』でも、文字色と背景色とは明度の差をつけりようにと言っています。）

なお、赤と緑は、判別しにくい人がいます。なので、文字と背景での色の組み合わせにおいて、赤と緑の組み合わせは、できるだけ避ける必要があります。やむを得ず、赤と緑の組み合わせを使うときは、明度に差をつけるとか、あるいは、背景に網掛け（あみかけ）をするなどの工夫が必要です。

あるいは、サイトの説明文などを組み合わせた状態を実際に閲覧してみて問題点が無いかなども、確認してみます。

（いくら、紙に書かれた単品のイラストだけを見ても、サイト上で説明文と組み合せた時の問題点は、実際にコンピュータ上で組み合せてみないと、気づくのが難しいのです。 なので、実際に試作してみましょう。）

「ペーパープロトタイピング」という市場のスケッチだけでアイデア出しをする手法もありますが（※たとえば検定教科書の東京書籍『情報II』でも紹介されています。日本文教出版でも用語なしで紹介）、しかし「ペーパープロトタイプ」という用語は採用しなくていいです。そもそも、ペーパープロトタイピングは、日本語でいう「試作」ではなく、経産省が言うにはアイデア出しの手法です。

経産省および独立行政法人　情報処理推進機構（IPA）の見解では、ペーパープロトタイピングは、アイデア出し手法のブレーンストーミング法やKJ法などと同列の手法であると、経産省らの資料『デジタルスキル標準』ver.1.1 の表に書かれています。

なお、文科省の教員研修要資料にあるペーパープロトタイピングの使い方は、まとまったアイデアをさっさとスキャニングして、それを実際にパソコン画面などで見ることで、配置などを検討しています。そういう使い方です。

ただまあ、現代ならタッチペンのあるデバイスとツールで画像を書いて、それをパソコンに取り込むほうが早いと思います。スキャナーに並ばなくて済むし。

ハッキリ言って、（検討ではなく）検証の目的ではペーパープロトタイピングは役立ちません。コンピュータ関係のアイデアの検証をしたいなら、実際にコンピュータの実機で動かすしかありません。

裏を返すと、IT業界でいう「設計」というのは、実際に動くものを作るなどして簡易的な検証をすることも含まれています。なお、経産省の資料では、「設計」のあとにユーザーに使ってもらうなどして（※ 資料の「ユーザビリティ」からwiki側で推測）、本格的な「検証」の工程があります。

「ペーパープロトタイピング」というのは、単に、構想のアイデア出しの打ち合わせのときのスケッチを別の用語で言い換えただけに過ぎません。しょせん「ペーパープロトタイピング」はアイデア出しにすぎず、検証ではありません。

一般にIT企業でも製造業でも、さっさと実機で動くかどうかを確認するのが一般的な意味での「プロトタイプ」であり「試作品」です。少なくとも企業が若者に求めている能力はそれです。

アイデア出しばかりせず、良さそうなアイデアが出たら、（安全に配慮しつつ）さっさと検証してください。

素人どうしの高校生が、実機での制作すらしたことないのに紙上で議論しても、どうせピント外れの議論になって、無駄の無駄です。

webサイトくらいさっさとhtmlで記述して、試作できるでしょう。中学生ですら試作できます。

紙上での議論が必要なジャンルがあるとしたら、もっとカネのかかるものを制作する場合の話です。イスを作るとか、傘立てを作るとか、そういう実物のあるものを作る場合なら、紙上でのスケッチも有効かもしれません。

ですが、webサイトはそういう実物ではありません。さっさとHTMLでwebサイトを書いてください。

PDCA法などの評価手法・修正手法などによる評価(Check)や改善(Act)などは、まず先にプロトタイプで実験してからのハナシですし、まずはプロトタイプを利用者に見てもらうなどの必要があります。

※ PDCA法とは業務改善の手法であり、Plan（計画）→ Do（実行）→ Check（評価）→ Act（改善）の 4段階を繰り返すことによって、業務を改善する手法のこと。

もし仮に、先に絵を細かく書いてから、あとからウェブサイトに取り込む方式の開発をしてしまうと、もし文章との組み合わせでの問題点があったときに、作り直しになってしまい、大幅に時間を無駄にしてしまいます。

なので、まず先に、試作品で、最終的な全体像に近いほうを、試す必要があります。

単にラフ画を描くだけでなく、さらに、なるべく、サイトの全体像を先に試作する必要があります。

このように、なにかを試作する場合には、なるべく、試作でいいので全体像を先につくってみて実際に実験することで、全体像を確認してみます。そして、全体の確認が取れたり、あるいは全体像のミスが修正できたら、あとから細部を作り込んでいきます。

不具合原因の特定の必要性（※ 検定教科書の範囲外。NHK動画で似た話を確認）

さて、問題として、もしうまく動作しない場合などに、不具合の原因をどうやって特定するか、なかなかの問題です。これはwebサイトのプロトタイプに限った話ではなく、ロボットやドローンなどを作る場合も同様に起こりうる問題です。 もし不具合があった場合、色々と試すことで不具合の原因をなるべく特定しましょう。たとえ不具合後、1回だけソースコードを変えてみて別方式をひとつ試してみて実際に正常動作しても、それで検証を終わりにするのは危険です。 なぜ一つの別方式だけでは危険かというと、もしかしたら正常動作した理由は決してソースコードを変えたことではないかもしれず、たとえば時間がたって何らかの条件を満たしたから正常動作しただけかもしれません。あるいは、奇数回数では失敗するが偶数回数では成功するとか、あるいはハッカーが偶然そのとき攻撃を停止していた、などの不具合かもしれません。 この場合だと、本当の原因を解決できてないので、ふたたび時間が経過したりしたら、また不具合が起きる可能性があります。 なので、不具合が起きたら、けっして単に「正常動作したら終わり」ではなく、再発防止のために原因究明をする必要があり、そのためには比較として幾つかの方式を試す必要があります。 （※ 理科の参考書で習う「対照実験」、・・と言おうとしたが、じつは対照実験は検定教科書の『生物基礎』では習ってない。『科学と人間生活』当たりの科目では習う。wikibooksでは高等学校生物/生物I/細胞の構造とはたらきで対照実験に言及（版にもよる）。） 不具合後の原因究明のため、もし不具合のあった後は、とりあえず改修して正常に動作したら、その正常に行ったときのデータやファイルなどは保管しつつ、（時間と費用に余裕があれば）なるべく別の方式も試してみて、不具合の原因が特定できるまで、色々と試していきましょう。

ほかの業界でも試作はある

たとえば、製造業でも、設計の段階では試作します。 教員向けの指導書を読んでたら、ある工業高校でIT化されたリアカーを開発した事例でも、工業高校生がプロトタイプ（試作品）の制作をしています。 別のある水産高校で魚群探知ロボットを作った事例でも、プロトタイプを制作しています。 ある私立の小学校では、木製の椅子を作る際、10分の1のミニチュアを先につくって、強度など確認しています。 いきなり本物の実物大のイスを作ると、木材の消費量が多いし、設計ミスをしたときの損失が多くなってしまって大変です。こういう場合はまずミニチュアを作りましょう。 なお、さすがに子供だけでイスを作るのは無理なので、林業の業者や、学校の先生がところどころ手伝ったりしています。木材の伐採は業者の仕事。子供の仕事は、設計と、組み立て・塗装などです。 実際のミニチュアの椅子だと、ネジやクギなどサイズが合わないので、ミニチュアで成功したからといって、必ずしも実物大で成功するとは限りません。ですが、ミニチュアですら失敗するデザインは、実物大にしたら確実に失敗します。 なので、大きなものを作る場合は、まずはミニチュアで成功するかを確認しましょう。

文科省の動画教材でも言われてるのですが、最近のホームページ作成は難しく、いきなり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部」みたいにしておくのが、本番データへの混入を防げて安全でしょう。 人名なら、「山田 太郎」とか、「東京 花子」みたいなのを仮データにすると良いでしょうか。

なお、この仮データは見本を兼ねます。読者の皆さんも、よく何かの申込書とかを書くとき、「山田 太郎」とかを例にした見本を見るでしょう。ジュール開発をする場合も、まず、そういう見本が無いと、依頼を受けた作業者は分からないのです。

ソフトウェアの「レイアウト」にはテストが必要だろう

結局、「レイアウト」をどこまで具体的に作りこむか、という問題です。業界によって「レイアウト」に要求される具体性の水準は変わります。 イラストレーターやCGデザイナーなど絵描きが「レイアウト」と言ってる制作物を見ると、決して単に配置物を入れる四角の型枠の位置を決めるだけでなく、さらにその配置物のなかみの絵まで、ラフ画で提出しています。というか、イラストの場合、四角の型枠が不要な場合すらあります。 実教出版の検定教科書『情報II』（P.21）だと「レイアウト」で、ワイヤーフレームで四角の型枠の位置を決めるだけまでしか行っていません。そういう業界もあるかもしれないので、決してマチガイとは言えません。 プログラマーや技術者などが作るような何らかのソフトウェアやwebサービスなどの場合、技術的な都合も関わってきますので、テストと一体または併行（へいこう）・並行でなければ「レイアウト」は意味ありません。たとえば、絵のセンスある偉い人が何時間もかけて「レイアウト」を決めても、テストしてなければ意味がなく、たとえば、もしテストしてない場合は、実装段階でテストしたらバグが見つかってしまえばレイアウトから作り直しの羽目になって時間を大幅にロス、なんてことになりかねず、そうなったら目も当てられません。

「ワイヤーフレーム」

「ワイヤーフレーム」という用語を聞くと、ついつい、JavaScriptなどで線分を書きたくなるかもしれません。 しかし、最終的にwebサイト中のページでjpeg画像またはpng画像を表示する予定の箇所なら、その箇所にはJavaScriptで何かを描画するよりも、プロトタイプでは別画像で良いので実際にjpeg画像やpng画像など同形式でほぼ同サイズの画像をwebサイトのページ中に表示したほうが、テストも兼ねて安全で効率的でしょう。HTMLではimgタグなどを使えば、画像を表示できるはずです。 「ワイヤーフレーム」と言っても、決して1970年代のSF映画みたいな線画の3D-CGみたいなのは、描画の必要は無いです（当時はああいう線画CGをワイヤーフレームと呼んでいた）。プロトタイプでいう「ワイヤーフレーム」とは、そういう意味ではありません（1970年代くらいの古い文化が由来かもしれないが、しかし現状での意味は違う）。 正直、ワイヤーフレームと言う用語は、割とどうでもよいと思います。実際、日本文教出版や東京書籍の「情報II」教科書ではワイヤーフレームは紹介していないし。 よりにもよって、実教の「情報II」教科書では、手書きでペーパープロトタイピングをしやすいようにと、ワイヤーフレームの説明図では線画の絵を描いています。 しかし、画像を表示する予定の場所には、別の画像で良いので、実際に同じくらいのサイズの画像を表示するコードを書くほうが、テストの面からは大切です。

ほか、「モックアップ」と「ワイヤーフレーム」と「プロトタイプ」の意味の細かな違いは、どうでもよく、なぜなら業界によって意味が微妙に変わるから。

さて日本文教出版の教科書の挿し絵によると、「出し物」をヨコ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）。

業界によっては、別の言い方で「メインユーザー層を決める」とか「コア層を決める」「コア層に従う」とか「メインのターゲット層を決める」みたいな言い方をするかもしれませんが、意味合いは大体、似たような感じです。

東京書籍が言ってるのですが、ペルソナを設定する際に、ユーザー調査ではなく自分のやりたいことから逆算して都合良いペルソナを設定するという、ダメな人が時々います。チーム作業とか他人のお金で仕事をしている場合は、そういうダメな自己表現はしないようにしましょう。

ユーザーを無視して自己表現で自分のアイデアを世に問いたいなら、自分のカネでやりましょう。他人のカネと時間を使うな。

デザインでは適切なツールを使おう

ホームページを作る場合、上記で良いと思います。

【高等学校情報科「情報Ⅰ」教員研修用教材(本編)】第2章 - 20200928-mxt_jogai01-100013300_001.pdf より画像を引用。

もし、作りたいものがホームページでない場合、たとえば何かの画像を作りたい場合、そういうのに便利なツールを使いましょう。

文科省の教員用の教材では、ベクター画像の編集ソフトウェアについて、レイヤーの概念を教えています。

Windows『ペイント』には、レイヤーの機能は無いはずです。

ラスタ画像なら、お絵かきソフトなどで無料のソフトでレイヤー機能のあるソフトがあるので、それを使いましょう。もちろん、有料ソフトにもレイヤー機能のある製品が、ふつうにあります、。

webサイトのコンテンツ制作

検定教科書が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 にも規定されています。

とりあえず、検定教科書と同じ意味で使っていれば、特に問題はありません。

ISO規格のうち、「人間中心設計」と言う分野で、定められています。

内容も、ユーザーのニーズを調査しろだとか、それを文書で残して明確化しろとか、ふつうの事が書いてあるだけです。

設計の基本を押さえていれば、問題ありません。

ユーザーニーズを把握して設計のアイデアが決まったら、そのあと試作品を作れとか、試作品を作ったらそれをテストして改善しろだとか（いわゆる「PDCA法」のこと）、そういう普通のことがISOの人間中心設計で定められています。

日本など先進国の技術系の会社では、こういった設計手法は常識ですが、しかし世界にはそういう設計手法が守れない未熟な国があるので、そういう未熟な国との貿易を断る口実がISOです。冗談とかではなく、実際に ISO を守れないと、欧州企業などからは取引停止などの口実にされるかもしれません。

その他の仕事術

ToDoリスト

※ 検定教科書ではないのですが、新共通試験（センター試験の新しくなったヤツ）のサンプル問題を見ると、設問文中に「ToDoリスト」というのがあります。

つまり、「こういう風に ToDo リストで仕事しろ」というセンター試験委員たちから高校生への、ありがたい忠告です。

仕事をする際、色々といくつもの事をしないといけません。そのための自分のスケジュールなどの管理方法としてToDoリストがあります。

要点は下記の通り

• すべき作業を箇条書きしてリストアップしろ.
• そのリストの各作業（タスク）を優先度順に並び替えろ.
• 上記の並び替えをしやすいようにパソコンでToDoリストを作れ.

ToDoリスト作成の理由は、まず、忘れないようにメモ帳などに、やるべき仕事を箇条書きにしてリストアップするのは当然です。後述の作業のため、パソコンでリストアップしましょう。

加えて、重要度順、または締め切りの早い順に並び替えます。なぜ必要かと言うと、メモしないと、いつまでも頭の中で覚え続ける必要があるので、脳味噌を疲れさせてしまい、本来の仕事に集中できません。なので、メモする必要があるのです。

特にIT系の仕事や設計（英語で design デザイン）などの仕事は集中力を使うので、覚え続けるために集中力を使ってしまうと、本来のIT仕事に集中できなくなり、効率がかなり低下します。

また、順序を並び替えないと、いちいち、「どの仕事の重要度が、どのくらい高いか、低いか」を覚え続ける手間が生じてしまうので、やはり本来の仕事に集中できなくなってしまいます。

（新人ではなく）もしかしたら管理職なら、手配先（てはいさき）ごとに作業（タスク）を分類したりとかもあるかもしれませんが、しかしそれは新人の時点では、することではありません。新人が当面のあいだToDoリストでするのは、優先度順の並び替えです。

ともかく、優先度順にToDoリストの各項目を書く必要があるのです。

で、箇条書きにした各仕事にじっさいに取り掛かって、各仕事が終わったら、それぞれ終わった仕事に【完了】 とか 【済み】 とか、同じ行に書いておきます。終わった各仕事は、メモからは消さずに、「完了」とか書いて残しておくのがコツです。

なぜなら、あとから確認作業などのために、仕事を振り返ることがありますので。もし消すと、思い出すのに手間が掛かり時間の無駄ですし、集中力が下がります。それに振り返りもできなくなってしまいます。

なお、別の節で「問題解決」を紹介しますが、ToDoリストの作成も、PDCA法などと並ぶ、問題解決のための有効な手法のひとつです。関連付けて理解しましょう。

「何が解決すべき問題か、分からない」と言うときに、解決すべき問題を見つける方法のひとつが、箇条書きです。

※ 範囲外? MVP

まず試作では、最小の機能だけを設計する。これをMVP（Minimum Viable Product）と言う。

当wikiでは他の範囲外コラムでオーバーエンジニアリングを避けるべきことを注意喚起しているが、このMVPはオーバーエンジニアリングを避けるための手法の一つである。

文科省の教師むけ動画でも、たとえばチャットアプリを作るならメッセージのサーバーを介しての送受信とその保管だけを優先的に実装する例を出している。リマインダー機能やToDoリストなどの機能を、設計から排除している。なお、文科省の動画では、これを動画では「要件定義」として紹介している。

なお、同動画はPDF化されている。 『情報システムとプログラミング 情報システムを設計しよう』4.。

最終的にリマインダー機能をつけるかどうかはチームの目的によって異なるだろうが、とりあえずソフトウェアの開発当初の段階では不要だろう。（最低限の機能の実装も出来てないのに、あれこれと他の機能を考えても、ことわざでいう『とらぬタヌキの皮算用』みたいなもんでしかない。）

開発コストを下げるため、こういうのが必要。余計な機能をつけると、開発コストが増大しやすいので、あまり余計な機能を増やさないほうが安全。

オーバーエンジニアリングを避ける手法の一つ。

※ 経産省との連携

ゴール設定とターゲット層

※ 内閣官房からの省庁への命令にもどつく提案のひとつです。経産省『デジタルスキル標準』との連携.

※ 内閣官房からの命令で、文科省が経産省とデジタル人材育成の教育で連携することが命令されている。プロダクト開発などにおいては、経産省は、ゴール設定のスキルを要求している。参考資料の「リーダーシップ」や「ゴール設定」の項目で、ゴール設定のありかたに言及している。

※ 検定教科書の東京書籍『情報II』でも、広告産業の話題だが、ゴール設定の話をしている。ターゲティング広告の話も東京書籍の教科書にはあるが、しかしビジネスでいう「ターゲット」設定とは意味が違う。

（資料では言及していないが、）開発が長引いたりすると、当初の問題意識が何だったのかの記憶が薄れたりして、不明確になりやすい。

または、すでに開発初期から、チームメンバーごとに目標が微妙に食い違ってしまっている場合もある。そうすると、トラブルが起こりやすくなる。

なのでトラブル防止のため、開発の初期に、その製品開発が満たすべき第一目標や優先目標などの目的を明確にチームで共有する必要があるので、そのために言語化してイメージを共有する必要があり、このような優先目標などの言語化を「ゴール設定」などとビジネスでは呼んでいる。

たとえば、遊具をデザインするなら、「幼児～小学生を対象に（ターゲット）、楽しく安全に遊んでもらう（目的）」のようにゴール設定するのです。

ターゲット

なお、この遊具の例のように、ゴール設定の際、メインの使用者層の設定も必要になることがあり、その使用者層のことを「ターゲット層」などとビジネス用語ではよく言います。

デザインでは「使用者（ターゲット）」の設定が必要だと説明しています。

ターゲット層を設定する際も、ペルソナ法などを活用して、そのターゲット層の代表的な人物の性格・職業・趣味・夢などの具体的な人物像が分かるレベルにまでターゲット層を明確に設定しましょう。

一般向けのグラフィック系のデザイン入門書でも「ゴール」と呼んだりもするかもしれません。高校の検定教科書（日本文教出版の情報IIでも、「ゴール」という言い方はしていませんが、「目標」という言葉で、ゴール設定と同じことを紹介しています。）

ターゲット層を設定しつつ、その領域を拡大することも経産省は求めてます『デジタルスキル標準』P.87。　※　「（ターゲットとなる顧客・ユーザー、領域の拡大等）」と言う文言が試料中にある。

書籍『浦和高校論文集』（佐藤優 編著、K＆Kプレス、2019年）を読んでいたら、2010年代の公立高校の高校生が卒論で「ターゲット」という言葉を特に注記なく普通に使っていました。。コメダ珈琲について、「コメダはモーニングというサービスがある。コーヒーメニューを注文すると、厚切りのトーストとゆ卵がついてくるというサービスだ、朝の時間帯、特に独身のサラリーマンをターゲットにし成功している。」。という文章です。

2010年代の公立高校生でもターゲット層という概念を知っているんだから、2020年代の高校生だったらもう知ってて当然でしょう。

ターゲットの設定法は、モニタリング（観察）とすでに習ったプロトペルソナ法である程度は対応できるでしょう。

KPI

基本

※ 検定教科書の範囲。日本文教出版『情報II』のP.57にアリ。ただし、用語の紹介のみで、その説明はほとんど無い。

さらに「KPI」（ケーピーアイ、Key Performance Indicator）の知識と活用を、経産省『デジタルスキル標準』では求めています『デジタルスキル標準』P.87。KPIとは、実際にその商品がどれだけユーザーに好まれているかを、現実の自分らの提供中の商品分析から実証的に定量化した統計データです。

たとえば、自社のwebサイトが人気があるかどうかを確認したいなら、決してアンケートなどではなく、実際にそのサイトの1週間や1月など期間あたりの閲覧数のをもとに判断するのが、KPI的な考え方です。閲覧数など統計を記録した上でならアンケートなど実施するのも構いません。（アンケートはKPIとはあまり関係ないので、説明を省略します。）

閲覧数を記録するサービスをさらに細かく分けていけば、どのサービスに人気があって、不人気なサービスは何なのかとかわかっていき、改善点などが判明していきます。PDCAサイクルにおける、チェックの手法の一つと言えるでしょう。文字アンケートだけのチェックだと、文章が得意な人しか回答してくれなかったりして、消費者などの実態を反映しづらいので、なのでKPIによって実際の消費者らの行動を測定します。

経営学などの格言で「人の言ってる事とやってることが違う場合、本音はやってる事のほうだ」という感じの格言があります。KPIもそれと同じで、ユーザー層たちの実際にやってる事を分析します。

ただしKPIだけではユーザー層の細かい感情が分からないので、別途、インタビューなどを中間的にユーザーの一部に行います。ただしそれはKPI分析とは別の作業なので、インタビューについては説明を省略します。

例：　学校の文化祭をKPI分析してみる場合・・・

たとえば文化祭のwebサイトの効果を測定したいなら、個々のページの閲覧者数や予定表PDFなどのダウンロード数だけでなく、さらに入場チケットの予約数とか、実際の文化祭当日の入場者数とか、そういう数値も記録するべきです。

とはいえ、不祥事などによって閲覧者数を増やしても意味がありません。そこで、そのKPIで設定した測定項目の前提として、ゴールも設定する必要があります。

たとえば文化祭サイトのゴールなら、「学校のために足で出向いて文化祭に来てくれるようなファンを増やす」あたりがゴールでしょうか（ゴールは学校によりますので一例です）。

KGIという、ゴールがどのていど達成されてるかを測定する指標の概念もありますが（企業なら「売上」や「利益率」などをKGIに設定する）、これは高校生にはどうしようもないので、説明を省略します。

ただ、ゴールを意識化することは高校生でも可能でしょう。

企業でKPIを設定する場合、単に閲覧者数や訪問者数などだけを記録するのではなく、さらにそのうち購入者数がどれだけいるかや購入率（購入者数をサイト閲覧者で割った数値）なども記録します。

高校の文化祭の場合、商売をしているのではないので購入者数や購入率は記録しようがありませんが、そういう事も覚えておいてください。ビジネスでは、カネを出さない人にウケても意味がないので。

購入率を見るのは、たとえば、閲覧者が1千人だけど900人に売れている商品Aと、閲覧者数が1万人だけど2千人に売れている商品B、売れ行きが良いのはどちらでしょうか？　という問題です。ゴールにも寄りますが、投資効率で見れば、普通は900人に売れている商品のほうが投資効率が良さそうと見るでしょうか。（ただし、経済学には「規模の利益」といった概念もあるので、場合によります。）

高校の文化祭なら、購入者数の代わりに、実際に文化祭で入場した人などの割合も記録することになるでしょうか。これはチケット予約の状況などを測定すれば、ある程度は事前に推測可能でしょう。もちろん、当日の入場者数も記録しましょう。

※ 正直、時間的な限界があるので、高校生にそこまでのKPI分析は無理でしょう。国語・数学・理科・社会・英語などの学業もありますし。文化祭の出し物の準備のための工作（ノコギリで板を切ったりとか）などに時間を取られて、KPIの分析なんて後回しにせざるを得ないのが実態でしょうか。

ただ、KPIと言う概念は覚えておくと今後のためになって良いでしょう。

企業などでのKPIの測定では、リピーターの人数およびリピート率も測定したりします。

たとえば、（開店の初日でもないのに）もし1回しか商品を購入しない人の割合が多いとすれば、「きっと、購入者の多くが実際に購入したときに、不満があったのだろう」と問題点が存在しそうな可能性の高さを想定できます。

なので、リピート率を何らかの方法で測定します。

高校ではそこまでの測定は難しいかもしれませんが、こういうのがKPI的な分析方法です。

※ なお、Google Analytics というグーグルのサービスで、ホームページの閲覧傾向などの分析ができる。HTMLに埋め込む方式である。　情報処理学会の動画でも紹介されている情報処理学会『5. データの分析 (4) アンケートと行動（データの収集と分析）（情報通信ネットワークとデータの活用）』(5分50秒ごろ)。

高校生がそこまでするのは大変だし、実際は無理だろうが、まあこういう方法もある事を知っておくと良い。

※　なお、この情報処理学会の動画でも、KPIに言及しています（6分50秒ごろ）。

こういうツールを、アクセス解析ツール（web analytics tool）と言います（※ 日本文教出版 II ・P.38）。

Google Analytics はwebサイトの作り手が解析用のタグをソースコード中に貼り付ける方式であり、このような方式をwebビーコンと言います（※日本文教出版でwebビーコンをweb解析ツールの単元で紹介）。

webビーコン型のほかにも、サーバログ取得型やパケットキャプチャリング型があります（※ 日本文教出版II）。

（※ 編集注）サーバログ取得型などについては、それを解説した高校教材・大学教材などが見つからないので、省略します。たとえば大学教材だが実教出版『データサイエンスリテラシー』に Google Analytics の旧バージョンの Google データポータルの話題とKPIの話題とダッシュボードの話題がある。

（※ 範囲外）なお、一つの画面上で、アクセスされている頻度が多い箇所ほど色を赤くしたり（または青くしたり）したものを「ヒートマップ」と言います。ヒートマップはアクセス解析ツールの一種。

（※ 範囲外）アクセス記録とクリックなどのその操作記録は、実は不具時の修正のためにサーバー企業が保管しているものであり、それが本来の目的。ユーザビリティの改善にアクセス記録を使うのは、実は派生的・二次的な利用である。

暗黙の前提だが、たとえ利用者側が「送信」ボタンとか「購入」ボタンとかそういうボタンを押さなくても、webサイトにアクセスした時点でサーバー側にはアクセス記録が残ることになる。

ダッシュボード

ダッシュボードの例。総務省の統計ダッシュボード。

KPIは、単に数値を表で羅列するのではなく（表にすらしないよりかはマシですが）、できればグラフにしましょう。

KPIを算出する目的は、改善点などの問題発見のためです。なので、グラフ化することで、問題発見をしやすくしなければなりません。

※ Google の Looker Studio で、Google Analytics のでデータをグラフ化できます。

なお、このような複数の別々の項目の最新データをグラフ一覧としてまとめたものを「ダッシュボード」と言います。

さきほどの Looker Studio が、Google Analytics のダッシュボード化のためのwebサービスです。

※ なお、「Google ダッシュボード」とは違います。Google ダッシュボードは、Google アカウント登録者のための画面画面のひとつです。

なお、Google 以外のクラウドサービスでも、たとえば教員の使っている授業用のクラウドソフトなどにも「ダッシュボード」という機能があり、生徒の状況（出席日数とか成績とか）などをグラフ化して、定量的にモニタリングしています。

※コラム：デザインとは問題解決に寄与すべきものである

経済産業省は、デザインとは基本的には問題解決に寄与すべきものでなければならない、というような見解です。

で、内閣官房などの命令で、文部省と経済産業省などはICT教育において連携するようにと、それぞれの官庁は命令されています。

ともかく、IT系やビジネス系の業界で「デザイン」の仕事をうけおう場合、問題解決を優先しましょう。

詳しくは、下記コラム。

（※ 範囲外）デザイナーの仕事は問題「提起」ではなく問題「解決」

検定教科書では特に言及されていませんが、経営学などでいう「デザイン」では、前提として、「問題解決」のためにデザインを行います。 大学などのネット上のPDF論文やプレゼン資料でも、デザインの理論を扱ったものには、「問題解決」の単語がいくつもあります。 論文 岩谷 昌樹 ・八重樫 文 共著『デザイン思考家の条件』立命館大学 、Vol. 2 『デザイン科学研究』 2023 年 3 月、P.136 によると、「(2) デザインとは問題解決のことであり，誰でも関わることができる」 とあります。（※上記の「（2）」は原著ではマル2だが、機種依存文字なのでwiki側で変更。） なので、ともかく、将来的に仕事などで「デザイン」の業務をうけおった場合は、問題提起ばかりしないようにしましょう。 アート作品とかだと、よく、戦争や差別問題（たとえば人種差別や男女差別）など、問題提起があります。（例えばピカソのゲルニカみたいなの。） しかし、デザインは基本、問題提起ではなく、書き手である自分が問題解決をする仕事です。 客先や観客に問題解決に必要な手間を新たにかけさせるのは、IT業界やビジネス業界では、もはや「デザイン」ではありません。そもそも客は、そういう手間を解決する具体案をつくるのが面倒なので、なので代わりの仕事をデザイナーに頼んでいるわけです。 だからデザイナーは、注文を受けたら、ほぼ自分の作品内で、問題解決をしなければなりません。（ただし、作品を仕上げるために客先などに相談などをするのなら、アリ。）なので、とりあえず、まずは客先からデザイン仕事を依頼されたら、まずは客の解決してもらいたい問題を解決した作品を提出するのを、デザイナーは優先しましょう。 後戻りをしない、させない もし、客先に問題提起をしてしまうと、客先の工程に、「手戻り」（てもどり）や「後戻り」（あともどり）と言われる、企画などのやり直しの作業が発生してしまいます。例外として、トラブルや事故などに発展しそうな問題でない限り、新たな問題の提案は、客先からの信用を得た次回以降の作品で、企画チームなどに加えてもらえたときに提案しましょう。 特にソフトウェアの場合だと、もし客先に工程の後戻りをさせてしまうと、デバッグなどの作業もやり直しになってしまう可能性があるので、大いにスケジュールおよび費用の負担が増えてしまいかねないのです。なので、工程の後戻りは、基本的には避けなければなりません。 よって、「あまり、後戻りをしない」のがデザインの基本テクニックです。 ソフトウェア開発の場合、仕方なくどうしても後戻りをしないといけない場合でも、なるべくデバッグなどのやり直しの範囲が狭くなるような方法での後戻りを提案しなければならないでしょう。 分業が前提。　他部署の負担を増やさない ほか、暗黙の前提として、デザイン仕事は分業が前提になっています。なので、デザイン仕事では、自分の部下以外の他の作業者の負担を増やしてはいけません。 だから後戻りなどは基本的には禁止だし、その他にも、ほかの部署の作業者の負担を増やすようなことは、避けなければならないのです。

箇条書きメモの必要性（※ 範囲外）

ほかの節でもメモなどの箇条書きの必要性を述べてますが、設計などの仕事などをする際、手元のメモには必要事項などを箇条書きをすると良いでしょう。「何が解決すべき問題か、分からない」と言うときに、解決すべき問題を見つける方法のひとつが、箇条書きです。

もし分業や外注などをする場合でも、箇条書きをしてあることによって、どの作業を分業すればいいか把握しやすくなります。

箇条書きをしたうえでなら、箇条書きでは説明しきれないことがあれば文章にするのも構いませんが、まずすべき事は箇条書きです。

その他

プロトタイピング以外の開発手法

ウォーターフォール・モデル

ウォーターフォール（waterfall model）とかスパイラルモデル（spiral model）とか、アジャイル開発（agile development）とか。

ただ、高校生の段階では、ウォーターフォールは使わないだろう。

システムへの高度な専門知識がないとウォーターフォールは使いこなせないので。

初心者でプログラミングや運用の知識が無いのに、ウォーターフォールで設計しても、保守性の悪い設計をするのがオチである。

スパイラル（spiral）とは、「渦」（うず）という意味。

スパイラルモデルでは、

要求定義→設計→プログラミング→テスト→要求定義→設計→プログラミング→テスト→（以下略）

と何周も繰り返すので、図にすると渦っぽいので、スパイラルモデルと呼んでいる。

アジャイル開発とは、最初からは厳密な仕様を決めずに、試作を通して、仕様を決めていく方式。

アジャイル agile とは、「機敏」（きびん）とかの意味。

（※ 範囲外）西洋ゲームとかで素早さのことをアジリティー agility と言うが、それと同じ系統の語。たとえばゲーム『w:ウィザードリィ』の素早さは英語で agility である。

アジャイルとスパイラルの違いは、あまり明確ではない。書籍によって、それぞれの開発手法の説明は微妙に違う。

※ 実教出版と日本文教出版がアジャイル開発を紹介。東京書籍はアジャイルを紹介せず、ウォーターフォールとスパイラルモデルだけ紹介。

日本文教出版の教科書だと、アジャイル開発でも「要件定義→設計→プログラミング→テスト→運用」の「繰り返し」の工程があるとされる。

このように、あまりアジャイルとスパイラルとの違いがハッキリしない。検定教科書ですら、微妙にアジャイル開発とスパイラルモデルの説明は、それぞれ食い違っている部分がある。

webサイトを見ても、サイトによって、「アジャイル開発のほうがスパイラルモデルよりも品質重視」という主張のサイトもあれば、その逆の「スパイラルモデルのほうがアジャイル開発よりも品質重視」という主張のサイトもあり、日本の技術者たちの間でまだ合意が形成されていないので、高校生は気にしなくていい。

なお、プロトタイプ型の開発は、開発の早い段階でユーザーに実際に試作品（prototype）を使用させて、ユーザー要求を確かめるのがポイントである（実教出版、日本文教出版）。

プロトタイプとアジャイル／スパイラルとの違いもはっきりしない。アジャイルやスパイラルの開発初期の段階で、ユーザーに確認をしてもらったら、それはプロトタイプモデルではないのかとか、疑問はつきない。

ネットのwebサイトだと、細かい違いをあれこれと説明しているサイトもあるが、そんな細かい定義が実務の役に立つか、疑問である。資格試験用の、定義の違いなど覚えても、日本での資格試験でしか役立たない。

そんな言葉の定義のちがいなんかを気にするより、要するに、ユーザーに試作品をつかってもらって確認してもらう事が、実務上は重要である。

「アジャイル開発をしている」などと喧伝しているベンチャー企業などでも、おそらく一部のユーザーにたびたび確認をしてもらっているだろう。

ともかく、このように、開発手法はいくつもある。それぞれ、一長一短である。目的や自分たちの能力に合わせて使い分けるように。

探究学習したら公開しよう

NHk『情報I』で最終回で言ってたのですが、学校で探究活動や実習などで課題の解決案を出したら、なるべく学外にも公開しましょう。たとえば、地域の課題をIT技術で解決しようとする探究活動をしたなら、その成果の知見を当の地域の人たちに公開しましょうと、そうNHKに出演した大学教員は言ってます。

しばしば、せっかく新しい発見やアイデアを出しても、それが学校の中だけで完結してしまい、社会に何も還元しないことがあります。また、学校内で情報の流れが閉じていたりすることがあるのも問題です。

自治体でも、地域との交流のため、東京など金のある地域では、自治体の主催によって、地元の学校どうしの探究発表会を開催しています。さて、そもそも、公立高校は税金で補助を受けてるのですから、成果はなるべく発表しましょう。

また、自治体や教育委員会などは、こういう、高校どうしの情報共有や連携などの取り組みを支援しなければなりません。NHKの例でも、アンケート調査をする探求学習で、自校だけでなく他校にもアンケートを取っています。自治体はこういう学校間連携ができるように、教育環境整備しなければなりません。生徒や教職員だけの努力では無理です。ほかの公務員などの大人も仕事をしなければならないでしょう。

（※範囲外） KPT法とデザインレビュー

KPT法

ニュース

• 狩野さやか 著『「小学校情報科」新設への道筋となるか？〜宮城教育大附属小学校の挑戦』2024年3月12日 06:30

情報デザインを、もしかしたら将来は小学校で教えるかもしれないというニュース。小学校で新教科として情報科を設置する案があり（未決定。あくまで案）、その教育実験が東北の教育大附属の学校で行われている。

後述するKPT的な話のほか、構造化の話もしている。なお、構造化については本wikiでは『高等学校情報/情報の科学/構造化』に解説がある。ほか、対象者を明確にせよ、という話も上記の実験授業にある。ターゲット層の話。情報I・Iiの検定教科書でも、一部の教科書でターゲット層の話をしている。

ほかに紹介されたものを、上記の構造化とまとめて次に列記すると、

色の効果、フォント、キャッチコピー、レイアウト、構造化（※編集の都合で列記）、（グラフなどによる）可視化、対象を明瞭（※おそらくターゲット層の話）、「評価を受ける」（後述のKPT法）、比較する、

なども上記の実験授業にある。

（※ 「比較する」というのが何か、よく分からない。A/Bテストのことだろうか？ それともソフトウェアデザインにおける模写のことか（他人の上手いソフトウェアの挙動と自作の挙動とを見比べる方法。）? ）

上記ニュースでもあるのだが、なにかの告知ポスターらしき作品を作らせて、生徒どうしで成果物のレビュー（品評）を行わせている。

その際、「良かった点」と「改善点」を生徒どうしに述べさせている。評価を受ける際、他人からの評価を受けるのがポイントである。上記ニュースのリンク先でも、実験校の教師がそう指導している。

作り手の自分だけが分かっても、意味が無い。基本、ポスターというのは他人に何かを伝えるために作るので、他人から見て分かりづらいなら、反省点にしなければならない。

「改善点」を言わせるのがポイント。

「分かりづらい」という感想だと、言われた相手（作り手の側）にとっては改善点が何なのかが分からない。なので、生徒どうしで品評する場合は「問題点」ではなく「改善点」として、生徒の「漢字にふり仮名が無いので読みづらかった」という感想をもとに「ふりがなを追加すべき」という改善点になる。

下記のKPT法（ケプトほう）という品質改善手法が、これに近いだろう。（ただし、KPT法では「改善点」ではなく「問題点」を集めるという違いがある。）

• 「良かった点」と「改善点」の収集
  

プレゼンなど発表をした際、または発表前に仲間内でシミュレーションする際など、発表の良かった点・改善点を信頼できる仲間内で評価しあい、今後の改善につなげると、役立ちます（※ 数研出版の副教材の見解）。

※ 数研出版はここまでしか言ってないのですが、なぜそうすると良いのかwiki側で追加説明します。人によって、良い点ばかり気づく人もいれば、改善点ばかり気づく人もいて、人ごとに片寄りがあります。このため、発表などを評価しあう際、事前に評価シートなどに「良かった点」「改善点」の両方とも記入欄を用意したりすると良いでしょう。

世間には、お世辞ばかり言ってロクに発表内容を聞かずに「全部良かったよ」とか言うクソ野郎とか、その逆に発表者が嫌いとかの理由で全部ケチをつけるクソ野郎とかいるので、そういう人を排除するためにも「良い点」「改善点」の両方をします。というか、たぶん数研出版の編集部で、こういうふうに原稿などの「良かった点」「改善点」とかの相互評価をしているのでしょう。

（※範囲外）KPT法

「KPT法」（ケプトほう）というビジネス手法があります（KPIとは異なる）。Keep、Problem、Tryの略です。

良かった点は、今後も続けて欲しいので Keep （継続する点）、改善点は問題点が由来なのでProblem（問題点）、そして、KeepとProblemをもとに今後に挑戦すること（Try）を決める、という手法です。

ネット上ではKPT法とアンケートを関連づけてる記事は特にないのですが、しかし上述のように、アンケートで「良かった点」・「悪かった点」を最初から記入欄を設けることにより、アンケート収集者はKPTを自然に実践できるでしょう。

アンケートでは、KeepとProblemだけで十分だと思います。上記の数研出版のアンケート例でも、良かった点（Keep）と改善点（Problem）しか自由記述欄が無いし。

なお、Problemのアンケート結果で問題点の報告が集まったら、それをもとに、本質的に解決すべき課題を決める必要があり、この今後の課題のことをイシュー issue と言います。（なお、GitHubなどの管理サイトを使っていると、issueという項目がある。かなり高度に専門的な話だが、イシュー管理ツールとかチケット管理ツールとかいうサーバーソフトがあって、それで issue を管理できる。専門的すぎる話なので、読者は分からなければ、このカッコ内は読み飛ばしていい。）

issueは、自分たちの努力で解決できることを書きます。「消費市場が○○なので困ってる」みたいな外部要因に何かをさせる的なことを issue に書かない。issue は、暗黙の前提として「自分達が○○をする」という形にする。

issueを書く際、「なぜ困っているか」Whyという情報は、「何に困っているか」What に変換しましょう。最終的に解決する必要があるのは、目的語となる What だからです。

読者がもしToDoリストを知ってれば、このissue解決も、ToDoリスト上の解決すべきタスクに加えます。

そして、チーム開発をしているなら、issueを開発チーム内に報告して、情報を共有します。

Keepのアンケート結果は、今後の仕様とするかどうかを決めます。仕様とすると決まった場合は、それを社内のその製品の開発マニュアルなどのチェックリストに入れて、確実に今後も長所が反映されるようにします。

なお、アンケート回答者にProblemを書かせる際の注意として、改善策まで書かせないことです。改善策があると、別の工程（Try）が混ざってしまっているので、かえって分離の手間が増えてしまうので、収集側にとっては非効率になってしまうからです。改善策については、収集者の側で Try として考えます。そのため、「悪かった点」「問題点」などのような記入欄の題名にするなど、あえて否定的な表現の題名にすると良いでしょう。

つまり、Problemには、困りごとについて、5W1HでいうHowの形式で、実際に起きた事例をなるべく書きます。

※ アンケートを多数、回収したら、さらにそれをテキストマイニングのツールを作って分析、という教育研究もすでに別の学校（大学）などで実施されている。

Keepは改善しないほうが良い

世間の理論家のなかには、KPT法をたとえばトヨタ式カイゼンなどと組み合わせて、ProblemだけでなくKeepも改善しようといった理論を提唱する人もいますが、しかし不要です。 なぜならソフトウェア開発の常識として、「問題なく動いている部分には、基本的には、手を加えない」というのがあるからです。もし「よかれ」と思って手を加えて改修してしまうと、改修にバグが無いかといったテスト（検査）の手間が発生します。なので極力、問題なく動いている部分には手を加えないのが、システム開発の常識です。 ほか、年月が経った時への今後の更新などへの対処は基本、Problem側に分類すべきことです。あるいは、研究などで新機能の実験をしたい場合でも、それは「Keep」ではないです。そもそもKeepとは、当面のあいだ変更すべきでない機能・要求事項だからこそのKeepなのです。 もしKeepの長所をますます強めたい改修をしたい場合でも、その場合はけっしてKeepをイジルのではなく、なるべくProblem側をイジルべきです。 例えですが、もし上手な絵が書けた場合、その絵の魅力をますます協調したい場合は、けっして元絵をイジルのではなく、たとえば、絵を入れる額縁（がくぶち）のほうを高価で豪華なものにすればよいのです。どうせ後で額縁に入れるのだし、だったらその額縁を高価で豪華にすれば、絵の書き直しをせずに（よってテストの手間も無く）、絵の魅力を引き出せるよね、っていうのと同じです。 このように、なるべく、手戻り（てもどり）を避ける、後戻り（あともどり）を避けるというのが、システム開発の実務的なテクニックのひとつです。 つまり、Problem側を修正するさいに手を加えるとき、ついでにKeepを強調するための修正もしてしまえば、手間が省けて一石二鳥です。また、この方法なら、既存のKeepは変えないので、テストの手間が増えません。

すべての弱点は改善する必要は無い

SWOT分析

改善すべき問題点は、放置すると今後の脅威になりうる問題点のみです。単に、苦手を克服することに価値はありません。

たとえば、アナタがもしベトナム語が苦手だとして、これからベトナム語を練習して得意になっても、ベトナムでの仕事に就職できなければ、そしてベトナム文化の研究とかの特技でもなければ、経済的にはアナタのベトナム語の練習の価値は低く、単なる趣味・道楽とみなされやすいのと同じです。

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分析では、「強み」Sと「機会」Oを分離します。機会は、外部環境および未来予想のうち、事業に活用できそうなものです。ここでいう「強み」は、内部環境および過去の実績などです。どこからどこまでが内部なのかは議論の余地がありますが。

まあ、強みと機会の分離は、後回しにしても良い。それよりも、まず優先すべきは、脅威Tへの対応です。

私たちの当初の目的を忘れてはいけません。このページの場合、当初の目的は「収集したアンケート結果から、今後のための改善策を考える」ことが目的です。

SWOT分析とかKPT法とかをあれこれと覚えることは目的ではなく、ゴールに寄与しません。単にこの節では、考え方の例示をしているだけです。

デザインレビュー

デザインレビュー（design reviews、略称：DR）と言う言葉があり、何かデザイン物を作るとき、いきなり本番にせずに、制作チーム内に設計案を提出して、チーム仲間たちに品評してもらいます。「設計レビュー」とか「設計審査」とも言います。

なお、製作チームの仲間内でないレビューは、デザインレビューではなく、単なるレビューです。

デザインレビューをしないと、もしその後の実装で、設計ミスが見つかった場合、最悪の場合、設計そのものが最初からやり直しになってしまいます。なのでデザインレビューが必要なのです。

どちらのレビューにせよ、アンケートなどで他人の製作物の問題点を書くとき、改善策につながりやすいように具体的に書くのがコツです。一言「わかりづらかった」とか「いまいち感」とかは論外です。そういうのは問題点ではなく、単なる感想です。仕事でないなら、そういう感想を言うのもいいですが、しかし仕事の場合のレビューなら、「問題点」というには、「解決すべき問題は何なのか」がハッキリしないといけません。仕事でのレビューでは、なるべく解決すべき問題をハッキリさせましょう。

たとえばポスターの問題点なら、「文字が小さすぎる（または「大きすぎる」）」とか「文字が多すぎる」とか「文字の色が背景色と近くて、読みづらい」とか「コントラストがキツくて読みづらい」とか、「子どもに来てほしいイベントなのに、子供が読めない漢字が多い。ふりがなも無い」とか「絵の線と文字の線とが密集していて、文字が読みづらい」とか「絵がイベント内容と違いすぎて、てっきり別のイベントだと誤解してしまった」とか・・・（以下略）、そういうのが問題点です。このように」具体的に問題点を書けば、あとは作り手は、その意見をもとに改善策を考えられます。

改善策については、たとえば1つの問題点について、複数の改善策があるので、それを作り手の側で考えます。たとえば問題点「文字の色が背景色と近くて、読みづらい」なら、解決策は下記の2つ以上あるわけです。

1. 文字または背景の色を変える。
2. 色はそのままで、文字のフチドリ線を追加して、背景と文字を区別できるようにする。

などです。

なので、「問題」には、解決策を混ぜてはいけません。混ぜてしまうと、ほかの解決策を見落としてしまうからです。

上記のように改善策は複数個あるので、改善策については Problem には含めず、作り手側に判断を任せます。

しかし、ここまで問題点を具体的に報告できるようになるためには習熟が必要なので、教育的には、初心者はまず改善策を報告するようにしたほうが良いかもしれません（※ じっさい、数研出版の教科書のアンケート例でも「問題点」ではなく「改善策」を記述させている）。

ほか、論外の感想として、ポスターの感想なら「絵がヘタ」とか「文章センスが無い」とか、そういうのも論外の感想です（こういうのは「問題点」「改善策」とは言いません）。なぜなら、解決のための絵の練習に時間が掛かり過ぎるので。暗黙の前提として、提示すべき「問題点」や「解決策」は、短期間かつ低コストで実践が可能な解決策でなければなりません。

さて、医療看護系の問題解決ツールで提案されているフレーズで、「す・じ・こ」というのがあり、「（す）すぐに着手できる、（じ）実現可能である、（こ）効果的である」というのがあります。

レビューでもPDCAでも、なるべく「すじこ」な提案をしましょう。

上述の「絵がヘタ」とか「文章センスが無い」は、すぐには着手できないので論外です。

ほか、論外のよくある感想で、ターゲット層を無視した感想があります。

たとえば、マンガとかのレビューで、幼児むけのマンガ本やアニメなのに、大人が「もっと、大人の好みにあうように○○にすべきだ」みたいな感想もよくあります。自分の好き嫌いと、社会の要求との区別がついてない、頭のわるい大人です。「自分の好みの作風　＝　上手い作品」という人は、大人も子供も、けっこう多いです。