まず、「問題」とは、理想と現実のギャップのことです（※検定教科書にそう書いてある）。
そして、問題解決のための「課題」とは、そのギャップを埋めるために具体的にしなければいけない事です。
まず、問題や課題を正しく認識するために、なるべく数値的に認識することで、検証可能な形で（※ 実教出版の見解）課題を表現する必要があります。
たとえば、部活をつくりたいのにメンバー不足な場合、目標は、けっして「部員を増やしたい」という表現はなく、もっと数値的に「最低でも部員が10人になるまでは部品を確保したい。5対5で対戦の練習ができるから」のように具体的に課題を数値で設定する必要があります（※日本文教出版 I）。また、理由も併記すると、応用が利きます。
さらに、文章で課題や情報収集のインタビュー結果などを表現する場合でも、なるべく5W1Hが分かるように記録するべきです（※ 開隆堂の見解）。解決案を提示する場合も、なるべく分かりやすい表現にしましょう（※数研出版）。これが出来てない場合、解決案として、そもそも不十分な可能性があります；。
※ 検定教科書では言及されていませんが、問題解決のために情報収集をする場合、時間の制限がありますので、とりあえずの仮説が見つかったら、さっさと検証しましょう。
{{コラム|（※ 範囲外）SMARTゴール|
上記のような、具体的とか、測定可能とかの要求事項をまとめて、下記の「SMARTゴール」があります。
の頭文字の略です[https://toyokeizai.net/articles/-/311144?page=2  小谷 敦子『仕事時間を減らした人の｢振り返り｣という習慣 週に1回実践すると変わってくる』、東洋経済、2019/10/29 6:00  ]。
PDCA法などでは、SMARTゴールを意識しましょう。
さて、理想や目標がいくつもある場合はどうすればいいでしょうか。
現実には、時間や金銭などの制限があるので、すべての理想や目標が達成できるとは限りません。
理想や目標が複数ある場合や、チーム作業などで今のままでは意見がまとまらない場合には、自分またはチームの理想・目標に優先順位をつけるのが効果的です（※ 第一学習社 P.5、※数研出版 P.18）。
部活でも趣味でやってる練習なら、好きな時間配分で練習すればよいですが、しかし、もし部全体として「試合に勝ちたい」とかの目標があるなら、部の勝利のために効果的な練習に時間を優先的に配分する必要があります（※ 数研出版）。例は運動部でもなくても良く、別に体育祭でも何でも良いです。
課題や目標が複数ある場合、トレードオフの関係にある場合もあるので、そのことを認識する必要もあります（※ 実教出版、数研出版）。少なくとも、学校での部活の課題の場合、部費と言った費用の限界、練習場と言った場所の限界があるので、決して無制限に何でも叶う（かなう）なんて、ありえません（※数研出版の見解）。
※ 大人でも、これが出来ないダメな大人も多い。そういう大人は反面教師にするように。
thumb|300px|PDCAサイクル
練習量の多さに満足してはいけません。
スポーツなら、本番前に、本番を模した予行練習とかをしてみて（※ 開隆堂）、自分たちの練習法が果たして本当に正しいのかを検証しなければいけません（※数研出版）。
実際の戦績などを見て、もし練習しても成果が出て無さそうなら、練習法を直さないといけません（※数研出版）。これがPDCA法の考え方です。
なにかの理論通りに練習してみれ成果がいつまでも出ない場合、その理論は間違ってるのです。
そして、本番が来たとします。本番が終わったあとも、本番での自分たちの結果を記録し、来年以降に後輩などが役立てられるように備えます。または、自分たちが来年以降に役立てても構いません。（いわゆる「アーカイブ」化。普段は使わないが後年に使うかもしれない情報を記録して整理して残して資料化したものをアーカイブと言います。）
※ 文脈は違うが教員研修資料で「アーカイブ」と言う用語が使われてるので[https://www.mext.go.jp/content/20200928-mxt_jogai01-100013300_001.pdf   著者非公開（当時） 『高等学校情報科「情報Ⅰ」教員研修用教材（本編） 第2章コミュニケーションと情報デザイン』 P.84]、ついでに「アーカイブ」という言葉も覚えよう。国語の外来語の勉強。なおアーカイブの語源はラテン語。
※ 『情報』の教科としては「アーカイブ」という単語は範囲外だろう。
また、本番の結果もPDCAサイクルの一部にして、練習方法などを検証してみたりもします（※数研出版）。
スポーツを例にして説明しましたが（なお日本文教出版の例）、工場の品質管理や生産管理などにPDCAサイクルの手法は応用されています（実教出版）。
（※ 範囲外）暗黙の前提ですが、PDCAサイクルはなるべく短期間で回す必要があります浅見和寿 著『Z世代の生徒とつくるはじめての部活動』、明治図書出版、2023年10月初版 第1刷 刊、P.40。つまり、世の中には反面教師として、Plan→Do→Do→DO→Do→・・・ みたいにやたらとDoが長かったりして何か月もかかったり、あるいはPlanが長かったりして何か月もかかり、一向に検証 Check や修正後の再行動 Action につながらない人がいて、これではPDCAが形骸化（けいがいか）しています。
{{コラム|ネットのビジネス論を真に受けてはいけない|
ネットには、「PDCAサイクルはアイデア出しには向かない。品質改善に向く」という言説もありますが、いろいろと間違っています。
証拠として、日本文教出版の『情報I』には、PDCAサイクルの例の実話風の物語として、「解決策の立案」で、バスケ部員たちがアイデア出しで、アンケートを取った結果、
高校生の発言「バスケットボールの経験者が多い事が分かった」「なぜ高校でバスケットボールをやらないかは、練習がきびしそうだからという答えが多かった」という結果をもとにアイデア「体験入部を開いて部の楽しさを知ってもらおう」
と高校生キャラがアイデアを出す挿し絵（さしえ）マンガがあります。
また、工場などの品質改善の仕事は、よほどの低品質の工場を指導するのでないかぎり、品質管理部門では思考なしのパターン反復ではできません。
なぜなら品質管理部門の仕事とは、そもそも作業員が作業手順書どおりに作業しているはずなのに品質が下がったりして困っているのを解決するために不具合の原因を分析したりする仕事だからです。
決して、単に不良品の発生率の統計を取るだけの仕事ではありません。仕事には、不良品の統計を取る事も含まれていますが。
また、作業手順書どおりのパターン反復が要求されているなら、そもそもPlanは不要です。なぜならPlanを考えるのは末端の作業員ではなく、設計部門だからです。
このように、ネットの言説がいろいろと間違っています。
ネットの言説はいろいろと低品質なので、ネットではなく検定教科書や参考書をきちんと確認しましょう。
おそらく、就職先のブラック企業か何かの不満を、PDCAサイクルに欠点があるのだと混同しているのでしょう。そのブラック企業で人生で初めてPDCAサイクルを習った人も多いのでしょう。
{{コラム|（※範囲外）問題解決のための調査の時間制限|
現実では、問題解決の方法を提案するために調査や分析をするさい、締め切りや期限といった時間の制限がある場合も多い松田稔樹ほか12名 著 『問題解決のためのデータサイエンス入門』実教出版、2021年10月25日 初版 第1刷発行、P.6。
たとえば、もし高校の部活での他校との試合の勝率を増やすための問題解決なら、その解決案は高校の部活在籍中の3年の夏までに実行できなければ意味が無い。
常識的に考えれば、高校の部活のためのデータ分析をする場合なら、数日中に解決策を提案しなければならないでしょう。
なので、高校入学後に3年以上の時間をかけて数学を勉強してから解決案を出しても、その前にすでに高校を卒業してしまっており、その案には何の意味も無い。同様、インタビューなどの情報収集に3年以上をかけたり、データ分析などを3年以上かけても、意味が無い。
このように、実用のデータ分析では、精度を犠牲にしてでも期限に間に合わせる必要がある場合も多いのです松田稔樹ほか12名 著 『問題解決のためのデータサイエンス入門』実教出版、2021年10月25日 初版 第1刷発行、P.23。
もちろん、最初の解決策は精度が低いので、期限後にあとから修正して、より良い解決策に変えるという追加作業が必要になります松田稔樹ほか12名 著 『問題解決のためのデータサイエンス入門』実教出版、2021年10月25日 初版 第1刷発行、P.23。ですが、まずは期限内に間に合わせて、とりあえずの解決策を提示する必要があります。
ほか、データサイエンスとは別ですが、一般的に何か目標を立てる際には、スケジュール的に遠すぎない中間目標を立てるのが常識ですみおりん 著『やる気も成績もぐんぐんアップ！中学生のおうち勉強法入門』、2022年2月15日 初版 第1刷 発行、P58。受験で志望校に合格するのが目標なら、たとえばまずは期末テストの成績をよくする途中の目標を立てる必要があり、さらにそのために来週までに〇〇をする的な目標が必要にある、といった類ですみおりん 著『やる気も成績もぐんぐんアップ！中学生のおうち勉強法入門』、2022年2月15日 初版 第1刷 発行、P58
※ 情報デザインは情報Iの内容です。プロトタイプは情報IIの内容ですが、wikiの都合上、こちらのページでも紹介します。なお、日本文教出版が『情報I』で「試作」の用語でプロトタイプを説明。
※ 「総合的な探究の時間」との関係もある。
※日本文教出版『情報I』はブレーンストーミングと関連づけて説明しているが、他社教科書では関連づけてない。
デザイン（design）とアートは違います。デザインは自己表現ではありません。東京書籍かどこかのサイトにある情報科目のパンフレットでは、アートとデザインは別物だと、イメージ画像で説明しています。
なんだかピカソ的な良く分からない絵や像をつくるのがアートで、そうではなくて図解などで文字を読まずに（もしくは少ない文字で）絵だけで分かりやすく説明するのがデザインです。
デザインのうち、情報デザイン（information design）と言われる分野があります。
アートと情報デザインの違いとして、上記の違いのほかにも、アートは多様な解釈を許しますが、情報デザインでは解釈を、正しい解釈だけで一通りに人々に受け取ってもらえるようにしなければなりません（※第一学習社）。たとえば、もし外国人など文化の異なる人が道路標識や非常口マークやトイレのマークなどを見たら（こういった標識も「情報デザイン」の例です）、その意味を一通りに理解できないと、事故の原因になってしまうので、情報デザインでは一通りの解釈でないといけないのです。
余談ですが、色は国によって解釈が違うので、ピクトグラムに色を使うときは注意が必要です（※第一学習社）。たとえば太陽の色は、日本では赤で表す人が多いかもしれませんが、外国では白や黄色で表す人が多い国もあります（※第一学習社）。普及しているピクトグラムを見れば、色を見ずとも形状だけでも意味が推測できるようになっているデザインが多いでしょう。
なお、情報科目だけでなく、美術2でも似たようなデザインとアートの違いについて習います
じっさい、美術の教科書会社のサイトにある動画でも、そう言っています[https://www.mitsumura-tosho.co.jp/kyokasho/k-bijutsu/interview   『インタビュー映像 美術のはなし | 高等学校 美術 | 光村図書出版』 情報をデザインするということ 、語り手：グラフィックデザイナー 中川憲造教科書関連ページ：平成30年度版『美術2』P.32-33「情報を視覚化するデザイン」 ]。
デザインは問題解決のために、観客に分かりやすく、観客が楽しめるように絵を交えて説明する絵画作品のことです[https://www.mitsumura-tosho.co.jp/kyokasho/k-bijutsu/interview   『インタビュー映像 美術のはなし | 高等学校 美術 | 光村図書出版』 情報をデザインするということ 、語り手：グラフィックデザイナー 中川憲造教科書関連ページ：平成30年度版『美術2』P.32-33「情報を視覚化するデザイン」 ]。
なお、デザインする仕事の人のことを「デザイナー」と言います。
ともかく、デザイナーは作品で情報が分かりやすく伝わらないと意味ないので、なので普通の人の気持ちもある程度は分からないといけません[https://www.mitsumura-tosho.co.jp/kyokasho/k-bijutsu/interview   『インタビュー映像 美術のはなし | 高等学校 美術 | 光村図書出版』 情報をデザインするということ 、語り手：グラフィックデザイナー 中川憲造教科書関連ページ：平成30年度版『美術2』P.32-33「情報を視覚化するデザイン」 ]。
なので、情報デザインの授業でたとえば「学校の紹介をするwebサイトを作ろう」みたいな事になった時は、きちんと分かりやすいwebサイトを作ってください。
なお、別単元の「プロトタイプ開発」なども参考にするとよいでしょう。
教科書会社によっては「プロトタイプ」と言う呼び方ではなく「試作」と読んでいる会社もあります。まあ、内容は同じで、要するに試作してから、細部をつめていきます。
パンフレットやwebサイトなどの情報伝達メディアを作る場合、対象者（ターゲット）に分かりやすい表現をする必要があります（※ 日本文教出版I・P96、開隆堂）。
特に幼児や小学生などの子供向けの場合、それらの年齢層にも分かりやすい表現が必要です（※ 開隆堂）。
※ いっぽう、大人でも、対象者を無視して、難解な自己満足の表現をするダメな大人もいます（難しい表現のできる自分を「国語力が高い」みたいに思ってる）。そういう、高校生未満の頭のダメな大人は、決して見習わないようにしましょう。
日本文教出版『情報 I』いわく、「わかりやすさ」「見やすさ」「読みやすさ」が、情報伝達メディアを作る際のポイントです。
デザイン（『設計』という意味）の分野では、けっして、なんでもかんでも議論で決定するべきではありません。
アイデアを確認する場合は、実際に試作品をつくって、アイデアがうまく行きそうかどうかを、実験的に手を動かして確認してみることも必要です [https://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2019/09/24/1416758_004.pdf   『高校情報科_本編_190806.indd - 1416758_004.pdf』  90ページ]  2020年5月18日に閲覧して確認. 。
たとえば、あるウェブサイト用のイラストを描く場合を例をあげると、まずラフ画（簡略化した線画などからなる、おおざっぱな絵）を書いて、協力者や依頼者などにラフ画を見せて意見を出してもらって、構図に問題が無いかなど、いろいろと確かめます。
あるいは、大まかな線画に加えて色も大まかに塗るくらいなら、いいかもしれません。
そしてウェブサイト用イラストの場合なら、まずラフ画ができたら、そのラフ画をさっさとスキャナーなどでデジタルデータにして、先にHTMLファイルなどで製作中サイトに表示してみて、いろいろと確かめてます。
たとえば、ラフ画が色付きなら、「その画像の色は、はたして本当にこのサイトで表示しても大丈夫か？ 文字の色と紛らわしくないか？ サイトの背景の色と紛らわしくないか？」とか様々な問題点の有無を確認します。
あるいは、サイトの説明文などを組み合わせた状態を実際に閲覧してみて問題点が無いかなども、確認してみます。
（いくら、紙に書かれた単品のイラストだけを見ても、サイト上で説明文と組み合せた時の問題点は、実際にコンピュータ上で組み合せてみないと、気づくのが難しいのです。 なので、実際に試作してみましょう。）
「ペーパープロトタイピング」という市場のスケッチだけでアイデア出しをする手法もありますが（※たとえば検定教科書の東京書籍『情報II』でも紹介されています。日本文教出版でも用語なしで紹介）、しかし「ペーパープロトタイプ」という用語は採用しなくていいです。そもそも、ペーパープロトタイピングは、日本語でいう「試作」ではなく、経産省が言うにはアイデア出しの手法です。
経産省および独立行政法人情報処理推進機構（IPA）の見解では、ペーパープロトタイピングは、アイデア出し手法のブレーンストーミング法やKJ法などと同列の手法であると、経産省らの資料『デジタルスキル標準』ver.1.1 の表に書かれています経済産業省・独立行政法人情報処理推進機構 共著『デジタルスキル標準』ver.1.1 ,2023年8月』 ,P.24。
なお、文科省の教員研修要資料にあるペーパープロトタイピングの使い方は、まとまったアイデアをさっさとスキャニングして、それを実際にパソコン画面などで見ることで、配置などを検討しています。そういう使い方です。
ただまあ、現代ならタッチペンのあるデバイスとツールで画像を書いて、それをパソコンに取り込むほうが早いと思います。スキャナーに並ばなくて済むし。
ハッキリ言って、（検討ではなく）検証の目的ではペーパープロトタイピングは役立ちません。コンピュータ関係のアイデアの検証をしたいなら、実際にコンピュータの実機で動かすしかありません。
裏を返すと、IT業界でいう「設計」というのは、実際に動くものを作るなどして簡易的な検証をすることも含まれています。なお、経産省の資料では、「設計」のあとにユーザーに使ってもらうなどして（※ 資料の「ユーザビリティ」からwiki側で推測）、本格的な「検証」の工程があります。
「ペーパープロトタイピング」というのは、単に、構想のアイデア出しの打ち合わせのときのスケッチを別の用語で言い換えただけに過ぎません。しょせん「ペーパープロトタイピング」はアイデア出しにすぎず、検証ではありません。
一般にIT企業でも製造業でも、さっさと実機で動くかどうかを確認するのが一般的な意味での「プロトタイプ」であり「試作品」です。少なくとも企業が若者に求めている能力はそれです。
アイデア出しばかりせず、良さそうなアイデアが出たら、（安全に配慮しつつ）さっさと検証してください。
素人どうしの高校生が、実機での制作すらしたことないのに紙上で議論しても、どうせピント外れの議論になって、無駄の無駄です。
webサイトくらいさっさとhtmlで記述して、試作できるでしょう。中学生ですら試作できます。
紙上での議論が必要なジャンルがあるとしたら、もっとカネのかかるものを制作する場合の話です。イスを作るとか、傘立てを作るとか、そういう実物のあるものを作る場合なら、紙上でのスケッチも有効かもしれません。
ですが、webサイトはそういう実物ではありません。さっさとHTMLでwebサイトを書いてください。
PDCA法などの評価手法・修正手法などによる評価(Check)や改善(Act)などは、まず先にプロトタイプで実験してからのハナシですし、まずはプロトタイプを利用者に見てもらうなどの必要があります[https://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2019/09/24/1416758_004.pdf   『高校情報科_本編_190806.indd - 1416758_004.pdf』  90ページ、ページ下段『（５）評価・検証する』] 。
※ PDCA法とは業務改善の手法であり、Plan（計画）→ Do（実行）→ Check（評価）→ Act（改善）の 4段階を繰り返すことによって、業務を改善する手法のこと。
もし仮に、先に絵を細かく書いてから、あとからウェブサイトに取り込む方式の開発をしてしまうと、もし文章との組み合わせでの問題点があったときに、作り直しになってしまい、大幅に時間を無駄にしてしまいます。
なので、まず先に、試作品で、最終的な全体像に近いほうを、試す必要があります。
単にラフ画を描くだけでなく、さらに、なるべく、サイトの全体像を先に試作する必要があります。
このように、なにかを試作する場合には、なるべく、試作でいいので全体像を先につくってみて実際に実験することで、全体像を確認してみます。そして、全体の確認が取れたり、あるいは全体像のミスが修正できたら、あとから細部を作り込んでいきます。
{{コラム|不具合原因の特定の必要性（※ 検定教科書の範囲外。NHK動画で似た話を確認）|
さて、問題として、もしうまく動作しない場合などに、不具合の原因をどうやって特定するか、なかなかの問題です。これはwebサイトのプロトタイプに限った話ではなく、ロボットやドローンなどを作る場合も同様に起こりうる問題です。
もし不具合があった場合、色々と試すことで不具合の原因をなるべく特定しましょう。たとえ不具合後、1回だけソースコードを変えてみて別方式をひとつ試してみて実際に正常動作しても、それで検証を終わりにするのは危険です。
なぜ一つの別方式だけでは危険かというと、もしかしたら正常動作した理由は決してソースコードを変えたことではないかもしれず、たとえば時間がたって何らかの条件を満たしたから正常動作しただけかもしれません。あるいは、奇数回数では失敗するが偶数回数では成功するとか、あるいはハッカーが偶然そのとき攻撃を停止していた、などの不具合かもしれません。
この場合だと、本当の原因を解決できてないので、ふたたび時間が経過したりしたら、また不具合が起きる可能性があります。
なので、不具合が起きたら、けっして単に「正常動作したら終わり」ではなく、再発防止のために原因究明をする必要があり、そのためには比較として幾つかの方式を試す必要があります。
（※ 理科の参考書で習う「対照実験」、・・と言おうとしたが、じつは対照実験は検定教科書の『生物基礎』では習ってない。『科学と人間生活』当たりの科目では習う。wikibooksでは高等学校生物/生物I/細胞の構造とはたらきで対照実験に言及（版にもよる）。）
不具合後の原因究明のため、もし不具合のあった後は、とりあえず改修して正常に動作したら、その正常に行ったときのデータやファイルなどは保管しつつ、（時間と費用に余裕があれば）なるべく別の方式も試してみて、不具合の原因が特定できるまで、色々と試していきましょう。
{{コラム|ほかの業界でも試作はある|
たとえば、製造業でも、設計の段階では試作します。
教員向けの指導書を読んでたら、ある工業高校でIT化されたリアカーを開発した事例でも、工業高校生がプロトタイプ（試作品）の制作をしています中島幸子『知識ゼロからのSTEAM教育』、幻冬舎、2022年11月25日 第1刷 発行、P12。
別のある水産高校で魚群探知ロボットを作った事例でも、プロトタイプを制作しています中島幸子『知識ゼロからのSTEAM教育』、幻冬舎、2022年11月25日 第1刷 発行、P21。
ある私立の小学校では、木製の椅子を作る際、10分の1のミニチュアを先につくって、強度など確認しています中島幸子『知識ゼロからのSTEAM教育』、幻冬舎、2022年11月25日 第1刷 発行、P21。
いきなり本物の実物大のイスを作ると、木材の消費量が多いし、設計ミスをしたときの損失が多くなってしまって大変です。こういう場合はまずミニチュアを作りましょう。
なお、さすがに子供だけでイスを作るのは無理なので、林業の業者や、学校の先生がところどころ手伝ったりしています。木材の伐採は業者の仕事。子供の仕事は、設計と、組み立て・塗装などです。
実際のミニチュアの椅子だと、ネジやクギなどサイズが合わないので、ミニチュアで成功したからといって、必ずしも実物大で成功するとは限りません。ですが、ミニチュアですら失敗するデザインは、実物大にしたら確実に失敗します。
なので、大きなものを作る場合は、まずはミニチュアで成功するかを確認しましょう。
文科省の動画教材でも言われてるのですが、最近のホームページ作成は難しく、いきなりCSSとかを駆使して作るのは、ふつうの高校生には無理です[https://www.youtube.com/watch?v=-Va7ciTWQ1w  文部科学省/mextchannel『高等学校「情報Ⅰ」オンライン学習会 【第8回】情報をデザインすることの意義、デザインするための一連の進め方』]。
というか、そこまで出来ないから、いま高校生が情報系の科目を勉強しているわけです。
まず、あまりCSSなどのお作法は考えず、とりあえず習った知識だけを駆使して、とりあえずのwebサイトを作りましょう。
ネットでは大人が「CSSを使わないと保守性が悪い！」とか言うかもしれませんが、しかしwebサイトとして動かない欠陥品を保守しても意味が無いです。
保守性がどうこう文句を言う大人は、決して、あなたのwebサイト制作の手伝いなんかしてくれません。そんな口先だけの大人なんかの言う事なんかを真に受けるより、実際にYouTube動画や高校教材などを作ってくれている文科省や大学教授や高校教員の人々を信用しましょう。
動くものを作るのが先、保守性を上げていくのは後回し、です。
実際にプロトタイプを作る場合は、まず箇条書きなどでアイデアを文字に起こしましょう。（※日本文教出版の教科書がそう。）
もし文字起こしをせず、頭の中で考えるだけだと、脳内でアイデアの記憶を維持するだけで脳のエネルギーを使ってしまうので、新アイデアの創造にまで頭が回りません。
『国際大学』という大学院大学とNHKが、プロトタイピングに使えそうな動画を作っています。クラウド関係の啓もう（けいもう）の動画ですが、視聴したところ、プロトタイピングにも使える内容になっています。
[https://full-glocom.jp/resources/lectures/n2 『みんなとクラウドで作業するとき、大切なことって何？』 FuLL, ] 動画中、小学生が学級新聞をつくるためにクラウド活用してプロトタイピングをしています（なお、動画中では『プロトタイプ』の語は出ていません）。今時の学校でのプロトタイピングは、コンテンツを作る場合にはクラウド活用することもあります。
デザイン案について、可能なら、ユーザー層などにwebアンケートを実施します（※第一学習社 P.75）。たとえばデザイン案が複数あって決まらない場合など、アンケートを取ると良いでしょう。
アンケートの際、「よい／わるい／ふつう」といった感想の選択肢のほか、なぜそう思うかの「理由」も必要です（※第一学習社が推奨している）。
検定教科書では「理由」が必要な理由までは説明してないのですが、世間一般には、選択肢を選ぶだけのアンケートだと、手抜きをしてデタラメにつける人がいます。
高校の文化祭webサイトのデザイン案とかだと、時間的な限界もあるでしょうし、アンケート実施まで可能かどうかは分かりません。
ですが、たぶん教科書会社はそういう感じで、高校生や高校教師などにアンケートを取りつつ、検定教科書を作っているのでしょう。
チームで共同作業をする際、それぞれが別のユーザー層を思い浮かべていては、うまく共同作業ができません。
なので、具体的なユーザー層を、チームの皆で考えます。
ユーザー層を考える時、典型的なユーザーを最低でも1人、考えます。
その典型的ユーザーを考える際、名前や職業や年齢や性別、性格、家族構成、趣味や将来の志望、などといった具体的なレベルまで、人物像を決めておきます。
また、それができるようになるために、簡易な取材でいいので、事前にユーザーにインタビュー取材およびユーザー調査などをします（日本文教出版 II）。
このように、典型ユーザーのイメージ像を具体的に共有する開発手法を「ペルソナ法」と言います（東京書籍 I、日本文教出版 II）。
手法の名前「ペルソナ法」はどうでもいいです。具体的なユーザー層を考えましょう。
※ 世の中には、具体的なユーザー層を無視して、巨匠（きょしょう）でもないのに独りよがりな自分にしか価値の分からない作品・製品を作りたがる人もいます。仕事ではなく趣味ならそれでも良いですが、しかし仕事では、そういう独りよがりはやめましょう。高校生でも出来る当然のことすら出来ないオトナは、けっこういます。
このように具体的にユーザー像を決めることで、ユーザー層の理解が深まるし（日本文教出版 II）、また、チームメンバー同士の考え違いなどを防止できる（東京書籍 I）。
東京書籍が言ってる手法ですが、一人のユーザーのペルソナではなく、複数人（数名ていど）のペルソナを設定する方法もあります。
その際、各ユーザーのペルソナの利益が反することがあります。
デザインの改修案が、あるペルソナAには利益があるけど、ペルソナBには改修前のほうが良かった、みたいな場合です。
このようにペルソナ同士の利益が反する場合、どのペルソナを1位にするのか、2位にするのか、事前に序列を決める必要があります（東京書籍 I）。
多数決ではなく、人物の序列で決めるのがポイントです。
東京書籍はそこまで言ってないですが、カネなどを提供しない客以外の人からウケても、意味がありません。たとえば高校教科書の文章の設計なら、高校生でもなければ保護者でもなく高校教師や塾講師でもなければ文科省や教育委員会でもない、世間のオッサン・オバサンとか大学院生とか幼稚園児とかに受けても意味が無いわけです。
一例として、2位以下のユーザーからの要望は、1位のユーザーの利益に反しないかぎり、受け入れる、といった感じです（東京書籍 I）。
業界によっては、別の言い方で「メインユーザー層を決める」とか「コア層を決める」「コア層に従う」とか「メインのターゲット層を決める」みたいな言い方をするかもしれませんが、意味合いは大体、似たような感じです。
東京書籍が言ってるのですが、ペルソナを設定する際に、ユーザー調査ではなく自分のやりたいことから逆算して都合良いペルソナを設定するという、ダメな人が時々います。チーム作業とか他人のお金で仕事をしている場合は、そういうダメな自己表現はしないようにしましょう。
ユーザーを無視して自己表現で自分のアイデアを世に問いたいなら、自分のカネでやりましょう。他人のカネと時間を使うな。
ホームページを作る場合、上記で良いと思います。
400px|thumb|[https://www.mext.go.jp/content/20200928-mxt_jogai01-100013300_001.pdf   【高等学校情報科「情報Ⅰ」教員研修用教材(本編)】第2章 - 20200928-mxt_jogai01-100013300_001.pdf ]より画像を引用。
もし、作りたいものがホームページでない場合、たとえば何かの画像を作りたい場合、そういうのに便利なツールを使いましょう。
文科省の教員用の教材では、ベクター画像の編集ソフトウェアについて、レイヤーの概念を教えています。
Windows『ペイント』には、レイヤーの機能は無いはずです。
ラスタ画像なら、お絵かきソフトなどで無料のソフトでレイヤー機能のあるソフトがあるので、それを使いましょう。もちろん、有料ソフトにもレイヤー機能のある製品が、ふつうにあります、。
thumb|400px|人間中心設計
情報デザインやプロトタイプ開発をする際、話し合いなどで「ユーザビリティ」や「ユーザーエクスペリエンス」などの用語を使うかもしれませんが、これらの用語のいくつかは国際規格の ISO にも規定されています。
とりあえず、検定教科書と同じ意味で使っていれば、特に問題はありません。
ISO規格のうち、「人間中心設計」と言う分野で、定められています。
内容も、ユーザーのニーズを調査しろだとか、それを文書で残して明確化しろとか、ふつうの事が書いてあるだけです。
設計の基本を押さえていれば、問題ありません。
ユーザーニーズを把握して設計のアイデアが決まったら、そのあと試作品を作れとか、試作品を作ったらそれをテストして改善しろだとか（いわゆる「PDCA法」のこと）、そういう普通のことがISOの人間中心設計で定められています。
日本など先進国の技術系の会社では、こういった設計手法は常識ですが、しかし世界にはそういう設計手法が守れない未熟な国があるので、そういう未熟な国との貿易を断る口実がISOです。冗談とかではなく、実際に ISO を守れないと、欧州企業などからは取引停止などの口実にされるかもしれません。
※ 検定教科書ではないのですが、新共通試験（センター試験の新しくなったヤツ）のサンプル問題を見ると、設問文中に「ToDoリスト」というのがあります。
つまり、「こういう風に ToDo リストで仕事しろ」というセンター試験委員たちから高校生への、ありがたい忠告です。
仕事をする際、色々といくつもの事をしないといけません。そのための自分のスケジュールなどの管理方法としてToDoリストがあります。
要点は下記の通り
ToDoリスト作成の理由は、まず、忘れないようにメモ帳などに、やるべき仕事を箇条書きにしてリストアップするのは当然です。後述の作業のため、パソコンでリストアップしましょう。
加えて、重要度順、または締め切りの早い順に並び替えます。なぜ必要かと言うと、メモしないと、いつまでも頭の中で覚え続ける必要があるので、脳味噌を疲れさせてしまい、本来の仕事に集中できません。なので、メモする必要があるのです。
特にIT系の仕事や設計（英語で design デザイン）などの仕事は集中力を使うので、覚え続けるために集中力を使ってしまうと、本来のIT仕事に集中できなくなり、効率がかなり低下します。
また、順序を並び替えないと、いちいち、「どの仕事の重要度が、どのくらい高いか、低いか」を覚え続ける手間が生じてしまうので、やはり本来の仕事に集中できなくなってしまいます。
（新人ではなく）もしかしたら管理職なら、手配先（てはいさき）ごとに作業（タスク）を分類したりとかもあるかもしれませんが、しかしそれは新人の時点では、することではありません。新人が当面のあいだToDoリストでするのは、優先度順の並び替えです。
ともかく、優先度順にToDoリストの各項目を書く必要があるのです。
で、箇条書きにした各仕事にじっさいに取り掛かって、各仕事が終わったら、それぞれ終わった仕事に【完了】 とか 【済み】 とか、同じ行に書いておきます。終わった各仕事は、メモからは消さずに、「完了」とか書いて残しておくのがコツです。
なぜなら、あとから確認作業などのために、仕事を振り返ることがありますので。もし消すと、思い出すのに手間が掛かり時間の無駄ですし、集中力が下がります。それに振り返りもできなくなってしまいます。
なお、別の節で「問題解決」を紹介しますが、ToDoリストの作成も、PDCA法などと並ぶ、問題解決のための有効な手法のひとつです。関連付けて理解しましょう。
「何が解決すべき問題か、分からない」と言うときに、解決すべき問題を見つける方法のひとつが、箇条書きです。
※ 内閣官房からの命令で、文科省が経産省とデジタル人材育成の教育で連携することが命令されている。プロダクト開発などにおいては、経産省は、ゴール設定のスキルを要求している[https://www.ipa.go.jp/jinzai/skill-standard/dss/ps6vr700000083ki-att/000106872.pdf    経済産業省・情報処理推進機構 共著『デジタルスキル標準 ver.1.1』,2023年8月 , P.79]。参考資料の「リーダーシップ」や「ゴール設定」の項目で、ゴール設定のありかたに言及している。
※ 検定教科書の東京書籍『情報II』でも、広告産業の話題だが、ゴール設定の話をしている。ターゲティング広告の話も東京書籍の教科書にはあるが、しかしビジネスでいう「ターゲット」設定とは意味が違う。
（資料では言及していないが、）開発が長引いたりすると、当初の問題意識が何だったのかの記憶が薄れたりして、不明確になりやすい。
または、すでに開発初期から、チームメンバーごとに目標が微妙に食い違ってしまっている場合もある。そうすると、トラブルが起こりやすくなる。
なのでトラブル防止のため、開発の初期に、その製品開発が満たすべき第一目標や優先目標などの目的を明確にチームで共有する必要があるので、そのために言語化してイメージを共有する必要があり、このような優先目標などの言語化を「ゴール設定」などとビジネスでは呼んでいる。
たとえば、遊具をデザインするなら、「幼児～小学生を対象に（ターゲット）、楽しく安全に遊んでもらう（目的）」のようにゴール設定するのです山崎正明『中学校美術 指導スキル大全』、明治図書、2022年5月初版第1刷刊、P51。
ターゲット
なお、この遊具の例のように、ゴール設定の際、メインの使用者層の設定も必要になることがあり、その使用者層のことを「ターゲット層」などとビジネス用語ではよく言います。
デザインでは「使用者（ターゲット）」の設定が必要だと説明しています山崎正明『中学校美術 指導スキル大全』、明治図書、2022年5月初版第1刷刊、P51。
ターゲット層を設定する際も、ペルソナ法などを活用して、そのターゲット層の代表的な人物の性格・職業・趣味・夢などの具体的な人物像が分かるレベルにまでターゲット層を明確に設定しましょう。
一般向けのグラフィック系のデザイン入門書でも「ゴール」と呼んだりもするかもしれません。高校の検定教科書（日本文教出版の情報IIでも、「ゴール」という言い方はしていませんが、「目標」という言葉で、ゴール設定と同じことを紹介しています。）
ターゲット層を設定しつつ、その領域を拡大することも経産省は求めてます[https://www.ipa.go.jp/jinzai/skill-standard/dss/ps6vr700000083ki-att/000106872.pdf 『デジタルスキル標準』P.87]。※「（ターゲットとなる顧客・ユーザー、領域の拡大等）」と言う文言が試料中にある。
書籍『浦和高校論文集』（佐藤優 編著、K＆Kプレス、2019年）を読んでいたら、2010年代の公立高校の高校生が卒論で「ターゲット」という言葉を特に注記なく普通に使っていました。佐藤優 編著『埼玉県立浦和高校論文集』、K＆Kプレス、2019年12月15日 第1刷 発行、P423。コメダ珈琲について、「コメダはモーニングというサービスがある。コーヒーメニューを注文すると、厚切りのトーストとゆ卵がついてくるというサービスだ、朝の時間帯、特に独身のサラリーマンをターゲットにし成功している。」。佐藤優 編著『埼玉県立浦和高校論文集』、K＆Kプレス、2019年12月15日 第1刷 発行、P423という文章です。
2010年代の公立高校生でもターゲット層という概念を知っているんだから、2020年代の高校生だったらもう知ってて当然でしょう。
ターゲットの設定法は、モニタリング（観察）とすでに習ったプロトペルソナ法である程度は対応できるでしょう。
※ 検定教科書の範囲。日本文教出版『情報II』のP.57にアリ。ただし、用語の紹介のみで、その説明はほとんど無い。
さらに「KPI」（ケーピーアイ、Key Performance Indicator）の知識と活用を、経産省『デジタルスキル標準』では求めています[https://www.ipa.go.jp/jinzai/skill-standard/dss/ps6vr700000083ki-att/000106872.pdf 『デジタルスキル標準』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分析は無理でしょう。国語・数学・理科・社会・英語などの学業もありますし。文化祭の出し物の準備のための工作（ノコギリで板を切ったりとか）などに時間を取られて、KPIの分析なんて後回しにせざるを得ないのが実態でしょうか。
ただ、KPIと言う概念は覚えておくと今後のためになって良いでしょう。
企業などでのKPIの測定では、リピーターの人数およびリピート率も測定したりします。
たとえば、（開店の初日でもないのに）もし1回しか商品を購入しない人の割合が多いとすれば、「きっと、購入者の多くが実際に購入したときに、不満があったのだろう」と問題点が存在しそうな可能性の高さを想定できます。
なので、リピート率を何らかの方法で測定します。
高校ではそこまでの測定は難しいかもしれませんが、こういうのがKPI的な分析方法です。
※ なお、Google Analytics というグーグルのサービスで、ホームページの閲覧傾向などの分析ができる。HTMLに埋め込む方式である。情報処理学会の動画でも紹介されている[https://www.youtube.com/watch?v=4ZZtts3T2TQ 情報処理学会『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の話題とダッシュボードの話題がある。
（※ 範囲外）なお、一つの画面上で、アクセスされている頻度が多い箇所ほど色を赤くしたり（または青くしたり）したものを「ヒートマップ」と言います[https://www2.nhk.or.jp/kokokoza/watch/?das_id=D0022200010_00000  NHK高校講座『社会と情報 第10回メディアの発達』]。ヒートマップはアクセス解析ツールの一種。
（※ 範囲外）アクセス記録とクリックなどのその操作記録は、実は不具時の修正のためにサーバー企業が保管しているものであり[https://www2.nhk.or.jp/kokokoza/watch/?das_id=D0022200010_00000  NHK高校講座『社会と情報 第10回メディアの発達』]、それが本来の目的。ユーザビリティの改善にアクセス記録を使うのは、実は派生的・二次的な利用である。
暗黙の前提だが、たとえ利用者側が「送信」ボタンとか「購入」ボタンとかそういうボタンを押さなくても、webサイトにアクセスした時点でサーバー側にはアクセス記録が残ることになる[https://www2.nhk.or.jp/kokokoza/watch/?das_id=D0022200010_00000  NHK高校講座『社会と情報 第10回メディアの発達』]。
thumb|400px|ダッシュボードの例。総務省の統計ダッシュボード。
KPIは、単に数値を表で羅列するのではなく（表にすらしないよりかはマシですが）、できればグラフにしましょう。
KPIを算出する目的は、改善点などの問題発見のためです。なので、グラフ化することで、問題発見をしやすくしなければなりません。
※ Google の Looker Studio で、Google Analytics のでデータをグラフ化できます。
なお、このような複数の別々の項目の最新データをグラフ一覧としてまとめたものを「ダッシュボード」と言います。
さきほどの Looker Studio が、Google Analytics のダッシュボード化のためのwebサービスです。
※ なお、「Google ダッシュボード」とは違います。Google ダッシュボードは、Google アカウント登録者のための画面画面のひとつです。
なお、Google 以外のクラウドサービスでも、たとえば教員の使っている授業用のクラウドソフトなどにも「ダッシュボード」という機能があり、生徒の状況（出席日数とか成績とか）などをグラフ化して、定量的にモニタリングしています。
経済産業省は、デザインとは基本的には問題解決に寄与すべきものでなければならない、というような見解です[https://www.meti.go.jp/shingikai/mono_info_service/service_design/pdf/20200420_03.pdf 経済産業省『我が国におけるサービスデザインの効果的な導⼊及び実践の在り⽅に関する調査研究報告』2020年3月]、、[https://www.meti.go.jp/shingikai/economy/kodo_design/pdf/20190329_02.pdf 経済産業省『⾼度デザイン⼈材育成ガイドライン』2019年3月29日]。
で、内閣官房などの命令で、文部省と経済産業省などはICT教育において連携するようにと、それぞれの官庁は命令されています。
ともかく、IT系やビジネス系の業界で「デザイン」の仕事をうけおう場合、問題解決を優先しましょう。
詳しくは、下記コラム。
{{コラム|（※ 範囲外）デザイナーの仕事は問題「提起」ではなく問題「解決」|
検定教科書では特に言及されていませんが、経営学などでいう「デザイン」では、前提として、「問題解決」のためにデザインを行います。
大学などのネット上のPDF論文やプレゼン資料でも、デザインの理論を扱ったものには、「問題解決」の単語がいくつもあります[https://www.ritsumei.ac.jp/research/rcds/file/2023/5_rcds_2_ando_1.pdf   安藤拓生 著『創造的問題解決としてのデザインに必要な能力に関する理論的整理』、立命館大学、Vol. 2 『デザイン科学研究』 2023 年 3 月、 ] 2023年12月19日に閲覧. [https://www.ritsumei.ac.jp/research/rcds/file/2023/10_rcds_2_iwatani_yaegashi.pdf   岩谷 昌樹 ・八重樫 文 共著『デザイン思考家の条件』立命館大学 、Vol. 2 『デザイン科学研究』 2023 年 3 月、P.136]。
論文 [https://www.ritsumei.ac.jp/research/rcds/file/2023/10_rcds_2_iwatani_yaegashi.pdf   岩谷 昌樹 ・八重樫 文 共著『デザイン思考家の条件』立命館大学 、Vol. 2 『デザイン科学研究』 2023 年 3 月、P.136]
によると、「(2) デザインとは問題解決のことであり，誰でも関わることができる」
とあります。（※上記の「（2）」は原著ではマル2だが、機種依存文字なのでwiki側で変更。）
なので、ともかく、将来的に仕事などで「デザイン」の業務をうけおった場合は、問題提起ばかりしないようにしましょう。
アート作品とかだと、よく、戦争や差別問題（たとえば人種差別や男女差別）など、問題提起があります。（例えばピカソのゲルニカみたいなの。）
しかし、デザインは基本、問題提起ではなく、書き手である自分が問題解決をする仕事です。
客先や観客に問題解決に必要な手間を新たにかけさせるのは、IT業界やビジネス業界では、もはや「デザイン」ではありません。そもそも客は、そういう手間を解決する具体案をつくるのが面倒なので、なので代わりの仕事をデザイナーに頼んでいるわけです。
だからデザイナーは、注文を受けたら、ほぼ自分の作品内で、問題解決をしなければなりません。（ただし、作品を仕上げるために客先などに相談などをするのなら、アリ。）なので、とりあえず、まずは客先からデザイン仕事を依頼されたら、まずは客の解決してもらいたい問題を解決した作品を提出するのを、デザイナーは優先しましょう。
後戻りをしない、させない
もし、客先に問題提起をしてしまうと、客先の工程に、「手戻り」（てもどり）や「後戻り」（あともどり）と言われる、企画などのやり直しの作業が発生してしまいます。例外として、トラブルや事故などに発展しそうな問題でない限り、新たな問題の提案は、客先からの信用を得た次回以降の作品で、企画チームなどに加えてもらえたときに提案しましょう。
特にソフトウェアの場合だと、もし客先に工程の後戻りをさせてしまうと、デバッグなどの作業もやり直しになってしまう可能性があるので、大いにスケジュールおよび費用の負担が増えてしまいかねないのです。なので、工程の後戻りは、基本的には避けなければなりません。
よって、「あまり、後戻りをしない」のがデザインの基本テクニックです。
ソフトウェア開発の場合、仕方なくどうしても後戻りをしないといけない場合でも、なるべくデバッグなどのやり直しの範囲が狭くなるような方法での後戻りを提案しなければならないでしょう。
分業が前提。他部署の負担を増やさない
ほか、暗黙の前提として、デザイン仕事は分業が前提になっています。なので、デザイン仕事では、自分の部下以外の他の作業者の負担を増やしてはいけません。
だから後戻りなどは基本的には禁止だし、その他にも、ほかの部署の作業者の負担を増やすようなことは、避けなければならないのです。
箇条書きメモの必要性（※ 範囲外）
ほかの節でもメモなどの箇条書きの必要性を述べてますが、設計などの仕事などをする際、手元のメモには必要事項などを箇条書きをすると良いでしょう。「何が解決すべき問題か、分からない」と言うときに、解決すべき問題を見つける方法のひとつが、箇条書きです。
もし分業や外注などをする場合でも、箇条書きをしてあることによって、どの作業を分業すればいいか把握しやすくなります。
箇条書きをしたうえでなら、箇条書きでは説明しきれないことがあれば文章にするのも構いませんが、まずすべき事は箇条書きです。
ウォータオフォールとかスパイラルモデルとか。
ただ、高校生の段階では、ウォーターフォールは使わないだろう。
システムへの高度な専門知識がないとウォータオフォールは使いこなせないので。
NHk『情報I』で最終回で言ってたのですが、学校で探究活動や実習などで課題の解決案を出したら、なるべく学外にも公開しましょう。たとえば、地域の課題をIT技術で解決しようとする探究活動をしたなら、その成果の知見を当の地域の人たちに公開しましょうと、そうNHKに出演した大学教員は言ってます[https://www2.nhk.or.jp/kokokoza/watch/?das_id=D0022200040_00000 『第20回データを武器に問題解決!』放送日：2月16日  ]。
しばしば、せっかく新しい発見やアイデアを出しても、それが学校の中だけで完結してしまい、社会に何も還元しないことがあります。また、学校内で情報の流れが閉じていたりすることがあるのも問題です。
自治体でも、地域との交流のため、東京など金のある地域では、自治体の主催によって、地元の学校どうしの探究発表会を開催しています[https://www.youtube.com/watch?v=0gqDyfypKu8  『【高校生】地域の課題と解決策を 「探究」授業の成果発表 東京・八王子市』  2024/02/12  ]。さて、そもそも、公立高校は税金で補助を受けてるのですから、成果はなるべく発表しましょう。
また、自治体や教育委員会などは、こういう、高校どうしの情報共有や連携などの取り組みを支援しなければなりません。NHKの例でも、アンケート調査をする探求学習で、自校だけでなく他校にもアンケートを取っています。自治体はこういう学校間連携ができるように、教育環境整備しなければなりません。生徒や教職員だけの努力では無理です。ほかの公務員などの大人も仕事をしなければならないでしょう。
ニュース
情報デザインを、もしかしたら将来は小学校で教えるかもしれないというニュース。小学校で新教科として情報科を設置する案があり（未決定。あくまで案）、その教育実験が東北の教育大附属の学校で行われている。
後述するKPT的な話のほか、構造化の話もしている。なお、構造化については本wikiでは『高等学校情報/情報の科学/構造化』に解説がある。ほか、対象者を明確にせよ、という話も上記の実験授業にある。ターゲット層の話。情報I・Iiの検定教科書でも、一部の教科書でターゲット層の話をしている。
ほかに紹介されたものを、上記の構造化とまとめて次に列記すると、
なども上記の実験授業にある。
（※ 「比較する」というのが何か、よく分からない。A/Bテストのことだろうか？ それともソフトウェアデザインにおける模写のことか（他人の上手いソフトウェアの挙動と自作の挙動とを見比べる方法。）? ）
上記ニュースでもあるのだが、なにかの告知ポスターらしき作品を作らせて、生徒どうしで成果物のレビュー（品評）を行わせている。
その際、「良かった点」と「改善点」を生徒どうしに述べさせている。評価を受ける際、他人からの評価を受けるのがポイントである。上記ニュースのリンク先でも、実験校の教師がそう指導している。
作り手の自分だけが分かっても、意味が無い。基本、ポスターというのは他人に何かを伝えるために作るので、他人から見て分かりづらいなら、反省点にしなければならない。
「改善点」を言わせるのがポイント。
「分かりづらい」という感想だと、言われた相手（作り手の側）にとっては改善点が何なのかが分からない。なので、生徒どうしで品評する場合は「問題点」ではなく「改善点」として、生徒の「漢字にふり仮名が無いので読みづらかった」という感想をもとに「ふりがなを追加すべき」という改善点になる。
下記のKPT法（ケプトほう）という品質改善手法が、これに近いだろう。（ただし、KPT法では「改善点」ではなく「問題点」を集めるという違いがある。）
プレゼンなど発表をした際、または発表前に仲間内でシミュレーションする際など、発表の良かった点・改善点を信頼できる仲間内で評価しあい、今後の改善につなげると、役立ちます（※ 数研出版の副教材の見解）。
※ 数研出版はここまでしか言ってないのですが、なぜそうすると良いのかwiki側で追加説明します。人によって、良い点ばかり気づく人もいれば、改善点ばかり気づく人もいて、人ごとに片寄りがあります。このため、発表などを評価しあう際、事前に評価シートなどに「良かった点」「改善点」の両方とも記入欄を用意したりすると良いでしょう。
世間には、お世辞ばかり言ってロクに発表内容を聞かずに「全部良かったよ」とか言うクソ野郎とか、その逆に発表者が嫌いとかの理由で全部ケチをつけるクソ野郎とかいるので、そういう人を排除するためにも「良い点」「改善点」の両方をします。というか、たぶん数研出版の編集部で、こういうふうに原稿などの「良かった点」「改善点」とかの相互評価をしているのでしょう。
（※範囲外）KPT法
「KPT法」（ケプトほう）というビジネス手法があります（KPIとは異なる）。Keep、Problem、Tryの略です。
良かった点は、今後も続けて欲しいので Keep （継続する点）、改善点は問題点が由来なのでProblem（問題点）、そして、KeepとProblemをもとに今後に挑戦すること（Try）を決める、という手法です。
ネット上ではKPT法とアンケートを関連づけてる記事は特にないのですが、しかし上述のように、アンケートで「良かった点」・「悪かった点」を最初から記入欄を設けることにより、アンケート収集者はKPTを自然に実践できるでしょう。
アンケートでは、KeepとProblemだけで十分だと思います。上記の数研出版のアンケート例でも、良かった点（Keep）と改善点（Problem）しか自由記述欄が無いし。
なお、Problemのアンケート結果で問題点の報告が集まったら、それをもとに、本質的に解決すべき課題を決める必要があり、この今後の課題のことをイシュー isuue と言います。（なお、GitHubなどの管理サイトを使っていると、issueという項目がある。かなり高度に専門的な話だが、イシュー管理ツールとかチケット管理ツールとかいうサーバーソフトがあって、それで isseu を管理できる。専門的すぎる話なので、読者は分からなければ、このカッコ内は読み飛ばしていい。）
読者がもしToDoリストを知ってれば、このissue解決も、ToDoリスト上の解決すべきタスクに加えます。
そして、チーム開発をしているなら、issueを開発チーム内に報告して、情報を共有します。
Keepのアンケート結果は、今後の仕様とするかどうかを決めます。仕様とすると決まった場合は、それを社内のその製品の開発マニュアルなどのチェックリストに入れて、確実に今後も長所が反映されるようにします。[https://muddydixon.hatenablog.com/entry/2017/01/13/085228 『KPT をチェックリストに昇華させると無駄なく知識が蓄積される - PolyPeaceLight』 ]
なお、アンケート回答者にProblemを書かせる際の注意として、改善策まで書かせないことです。改善策があると、別の工程（Try）が混ざってしまっているので、かえって分離の手間が増えてしまうので、収集側にとっては非効率になってしまうからです。改善策については、収集者の側で Try として考えます。そのため、「悪かった点」「問題点」などのような記入欄の題名にするなど、あえて否定的な表現の題名にすると良いでしょう。
{{コラム|Keepは改善しないほうが良い|
世間の理論家のなかには、KPT法をたとえばトヨタ式カイゼンなどと組み合わせて、ProblemだけでなくKeepも改善しようといった理論を提唱する人もいますが、しかし不要です。
なぜならソフトウェア開発の常識として、「問題なく動いている部分には、基本的には、手を加えない」というのがあるからです。もし「よかれ」と思って手を加えて改修してしまうと、改修にバグが無いかといったテスト（検査）の手間が発生します。なので極力、問題なく動いている部分には手を加えないのが、システム開発の常識です。
ほか、年月が経った時への今後の更新などへの対処は基本、Problem側に分類すべきことです。あるいは、研究などで新機能の実験をしたい場合でも、それは「Keep」ではないです。そもそもKeepとは、当面のあいだ変更すべきでない機能・要求事項だからこそのKeepなのです。
もしKeepの長所をますます強めたい改修をしたい場合でも、その場合はけっしてKeepをイジルのではなく、なるべくProblem側をイジルべきです。
例えですが、もし上手な絵が書けた場合、その絵の魅力をますます協調したい場合は、けっして元絵をイジルのではなく、たとえば、絵を入れる額縁（がくぶち）のほうを高価で豪華なものにすればよいのです。どうせ後で額縁に入れるのだし、だったらその額縁を高価で豪華にすれば、絵の書き直しをせずに（よってテストの手間も無く）、絵の魅力を引き出せるよね、っていうのと同じです。
このように、なるべく、手戻り（てもどり）を避ける、後戻り（あともどり）を避けるというのが、システム開発の実務的なテクニックのひとつです。
つまり、Problem側を修正するさいに手を加えるとき、ついでにKeepを強調するための修正もしてしまえば、手間が省けて一石二鳥です。また、この方法なら、既存のKeepは変えないので、テストの手間が増えません。
thumb|400px|SWOT分析
改善すべき問題点は、放置すると今後の脅威になりうる問題点のみです。単に、苦手を克服することに価値はありません。
たとえば、アナタがもしベトナム語が苦手だとして、これからベトナム語を練習して得意になっても、ベトナムでの仕事に就職できなければ、そしてベトナム文化の研究とかの特技でもなければ、経済的にはアナタのベトナム語の練習の価値は低く、単なる趣味・道楽とみなされやすいのと同じです。
SWOT分析（「スウォットぶんせき」と読む）というのが、脅威に備える分析法であり、強み（Strength）、弱み（Weakness）、機会（Oppotunity）、脅威（Threat）、の分析です。
ただ、日本語の「弱み」という言葉のニュアンスとは、やや違っています。SWOT分析でのWeaknessは「脆弱性」（ぜいじゃくせい）のようなニュアンスです。よく「セキュリティ脆弱性」とか言いますが、その脆弱と同じニュアンスで、放置すると脅威を引き起こす、呼び寄せるものの事です。
たとえばポスター作りの「弱み」なら、「自分はいつも誤字脱字が多い」とか「文化祭ポスターの試作で、校舎をえがいたつもりなのに、どうやら観客には市役所の庁舎に見えてしまっているようだ」とか、そういう今後のトラブルを起こしそうな「脅威」になりうるレベルなのが「弱み」です。単に、「漢字検定2級をまだ取得してない」とかそういうのは、とりあえず放置しても今後の脅威にならないので「弱み」ではないのです。
すでにKPT法で分析している人は、いちいちSWOT分析を書き始める必要はありません。ただ、KPT法を活用する際、SWOT分析を知っていると、より上手にKPT法を活用できるようになります。
さて、私たちの今の目的は、「収集したアンケート結果の、今後のための分析と活用」です。目的、ゴールを、はっきりとさせましょう。この節では、KPT法への活用を想定して、SWOT分析の考え方のうちKPT法への流用に必要な部分だけを説明します。ゴールに寄与しない事は、後回しで良いのです。
ともかく、脅威にならない単なる苦手といった弱点は、改善の必要はありません。むしろ企業社会では、株主や銀行などは、脅威にならない弱点克服は単なる道楽（どうらく）みたいな扱いをします。
ターゲット層にウケない弱点克服をしても、意味がありません。たとえばベトナムで商売してない会社に就職しようとするのにベトナム語をいきなり練習しても、大して価値が無いのと同じです。
経済は「分業」とか比較優位（ひかく ゆうい）とかで動いているのですから、ベトナム語はベトナムの専門家に任せればいいのです。親戚がベトナム人とかでないかぎり、いちいちベトナム語を勉強しても、経済的には利益を得づらいのです。
ベトナム語の例なら、「ベトナム語の就職への活用をあきらめる」と言うのも改善策です。そのジャンルから「撤退する」「他の企業や競争相手に任せる」等も解決策です。実際、SWOT分析でも、「市場撤退」も、脅威への解決策の一つです。
さて、改善をする際、強み（Strength）を損なわないように改善する必要があります。
たとえば、ポスターに掲載する情報を増やすと、情報不足という弱点は解決しますが、そのぶん一つ一つの情報が目立たなくなります。どちらを優先すべきかは、用途によって変わります。」
よって、確保すべき強みに、優先順位をつけましょう。
ポスターを例にあげましたが、ソフトウェアのUIなども同様でしょう。
なお、どんなに強みを強化しても、基本、ぜい弱性は解決しません。たとえば、誤字脱字や誤情報のあるポスターで、どんなに絵を上手に書いても（あるいは写真を上手に撮影しても）、そのポスターの誤字や誤情報は解決しないのと同様です。
たとえば「虫歯の治療」のようなものです。虫歯のある小学生が（ぜい弱性）、その子の小学校の成績が良くて（強み）、どんなに小学校の勉強を頑張っても、何も虫歯は解決しません。歯医者に行くとか、せめて歯磨きを毎日するとかしないと、問題は解決に近づきません。
（※余談の余談）なお、SWOT分析では、「強み」Sと「機会」Oを分離します。機会は、外部環境および未来予想のうち、事業に活用できそうなものです。ここでいう「強み」は、内部環境および過去の実績などです。どこからどこまでが内部なのかは議論の余地がありますが。
まあ、強みと機会の分離は、後回しにしても良い。それよりも、まず優先すべきは、脅威Tへの対応です。
私たちの当初の目的を忘れてはいけません。このページの場合、当初の目的は「収集したアンケート結果から、今後のための改善策を考える」ことが目的です。
SWOT分析とかKPT法とかをあれこれと覚えることは目的ではなく、ゴールに寄与しません。単にこの節では、考え方の例示をしているだけです。
デザインレビュー（design reviews、略称：DR）と言う言葉があり、何かデザイン物を作るとき、いきなり本番にせずに、制作チーム内に設計案を提出して、チーム仲間たちに品評してもらいます。
なお、製作チームの仲間内でないレビューは、デザインレビューではなく、単なるレビューです。
どちらのレビューにせよ、アンケートなどで他人の製作物の問題点を書くとき、改善策につながりやすいように具体的に書くのがコツです。一言「わかりづらかった」とか「いまいち感」とかは論外です。そういうのは問題点ではなく、単なる感想です。仕事でないなら、そういう感想を言うのもいいですが、しかいｓ仕事の場合のレビューなら、「問題点」というには、「解決すべき問題は何なのか」がハッキリしないといけません。仕事でのレビューでは、なるべく解決すべき問題をハッキリさせましょう。
たとえばポスターの問題点なら、「文字が小さすぎる（または「大きすぎる」）」とか「文字が多すぎる」とか「文字の色が背景色と近くて、読みづらい」とか「コントラストがキツくて読みづらい」とか、「子どもに来てほしいイベントなのに、子供が読めない漢字が多い。ふりがなも無い」とか「絵の線と文字の線とが密集していて、文字が読みづらい」とか「絵がイベント内容と違いすぎて、てっきり別のイベントだと誤解してしまった」とか・・・（以下略）、そういうのが問題点です。このように」具体的に問題点を書けば、あとは作り手は、その意見をもとに改善策を考えられます。
改善策については、たとえば1つの問題点について、複数の改善策があるので、それを作り手の側で考えます。たとえば問題点「文字の色が背景色と近くて、読みづらい」なら、解決策は下記の2つ以上あるわけです。
文字または背景の色を変える。
色はそのままで、文字のフチドリ線を追加して、背景と文字を区別できるようにする。
などです。
上記のように改善策は複数個あるので、改善策については Problem には含めず、作り手側に判断を任せます。
しかし、ここまで問題点を具体的に報告できるようになるためには習熟が必要なので、教育的には、初心者はまず改善策を報告するようにしたほうが良いかもしれません（※ じっさい、数研出版の教科書のアンケート例でも「問題点」ではなく「改善策」を記述させている）。
ほか、論外の感想として、ポスターの感想なら「絵がヘタ」とか「文章センスが無い」とか、そういうのも論外の感想です（こういうのは「問題点」「改善策」とは言いません）。なぜなら、解決のための絵の練習に時間が掛かり過ぎるので。暗黙の前提として、提示すべき「問題点」や「解決策」は、短期間かつ低コストで実践が可能な解決策でなければなりません。
ほか、論外のよくある感想で、ターゲット層を無視した感想があります。
たとえば、マンガとかのレビューで、幼児むけのマンガ本やアニメなのに、大人が「もっと、大人の好みにあうように○○にすべきだ」みたいな感想もよくあります。自分の好き嫌いと、社会の要求との区別がついてない、頭のわるい大人です。「自分の好みの作風＝上手い作品」という人は、大人も子供も、けっこう多いです。