Wikibooks jawikibooks https://ja.wikibooks.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 MediaWiki 1.39.0-wmf.22 first-letter メディア 特別 トーク 利用者 利用者・トーク Wikibooks Wikibooks・トーク ファイル ファイル・トーク MediaWiki MediaWiki・トーク テンプレート テンプレート・トーク ヘルプ ヘルプ・トーク カテゴリ カテゴリ・トーク Transwiki Transwiki‐ノート TimedText TimedText talk モジュール モジュール・トーク Gadget Gadget talk Gadget definition Gadget definition talk 0 554 206046 205384 2022-07-31T12:02:38Z 126.158.229.60 wikitext text/x-wiki 206047 206046 2022-07-31T12:02:50Z 126.158.229.60 wikitext text/x-wiki 206048 206047 2022-07-31T12:05:09Z 126.158.229.60 wikitext text/x-wiki 206049 206048 2022-07-31T12:13:59Z Syunsyunminmin 67230 Reverted 3 edits by [[Special:Contributions/126.158.229.60|126.158.229.60]] ([[User talk:126.158.229.60|talk]]) (Using [[:m:User:Xiplus/TwinkleGlobal|TwinkleGlobal]]) wikitext text/x-wiki {{Pathnav|メインページ|frame=1}}{{蔵書一覧}} ここは普通教育に関する教科書・資料を収めておく書庫です。以下の書籍が収録されています。なお、ウィキブックスの読み方などについては[[小学校・中学校・高等学校の学習/ウィキブックスについて|こちら]]をご覧ください。 == 教科書 == * [[小学校の学習|{{ruby|小学校|しょうがっこう}}の{{ruby|教科書|きょうかしょ}}]] * [[中学校の学習|中学校の教科書]] * [[高等学校の学習|高等学校の教科書]] (※令和元年度以降の学習指導要領へ対応するための改訂が遅れています。[[高等学校の学習/旧課程|旧課程版]]も参考にしてください) === 重要事項 === 現在(2022年)、小学校・中学校・高等学校では新学習指導要領が施行されています。各教科を執筆・編集の際には、学習指導要領や各教科書会社の移行措置資料などもあらかじめ確認されますようお願いいたします(特に英語・数学(算数)・理科・共通教科情報科は学年を移行する内容や新規追加される内容が多い教科となっています)。 == 学習・生活ガイド == * [[学習方法]](小中高の全般および各科目ごと) * [[生活ガイド]] === 小学校 === * [[小学校ガイド]] * [[学習方法/小学校全般|{{ruby|学習方法|がくしゅうほうほう}}/小学校{{ruby|全般|ぜんぱん}}]] {{ruby|各教科|かくきょうか}}の{{ruby|学習法|がくしゅうほう}}は『{{ruby|学習方法|がくしゅうほうほう}}』にあります。 === 中高総合 === * [[学習方法/中学高校の学習全般]] * [[中学高校の生活ガイド全般]] === 中学校 === * [[中学生活ガイド]] * [[学習方法/中学校全般]] 各教科の学習法は『学習方法』にあります。 === 高等学校 === * [[高校生活ガイド]] * [[学習方法/普通科高校全般]] * [[学習方法/高校5教科全般]] * [[学習方法/大学受験5教科全般]] 各教科の学習法は『学習方法』にあります。 == 受験ガイド・参考書 == * [[受験ガイド]] === 中学受験 === * [[中学受験ガイド]] * [[中学受験参考書]] === 高校受験 === * [[高校受験ガイド]] * [[高校受験参考書]] === 大学受験 === * [[日本の大学受験ガイド]] * [[外国の大学受験ガイド]] * [[大学受験参考書]] == 中高一貫校の教科書・生活ガイド == * [[中高一貫校の学習|中高一貫校の教科書]] * [[中高一貫校生活ガイド]] == 検定 == * 学校で必要で基準がはっきりしてる物を扱う［算・漢・英（中学から）：検］ * 一般的にイー・タイピングやP〈パソコン〉検はコンピューター需要が関わる * 団体応募があるが雇用に含むか疑問視する点がある == 資料 == ;演習 * [[小・中・高等学校演習]] ;学校制度の紹介 * [[生活と進路]] ;他の教科書 * [[大学の学習|大学の教科書]] * [[特別支援学校の学習]] ;就職活動ガイド * [[就職活動ガイド]] ;編集に参加したい人へ * [[小学校・中学校・高等学校の学習/ウィキブックスで教科書を執筆する人へ|ウィキブックスで教科書を執筆する人へ]] * [[検定教科書|検定教科書の閲覧・購入]] * [[Wikibooks:児童・生徒の方々へ]] [[Category:普通教育|しようかつこうちゆうかつこうこうとうかつこうのかくしゆう]] [[Category:書庫|しようかつこうちゆうかつこうこうとうかつこうのかくしゆう]] cppjzyv1w5vke0ta20o439daabfbveq 206050 206049 2022-07-31T12:15:48Z 126.253.159.149 wikitext text/x-wiki 206055 206050 2022-07-31T12:55:41Z 椎楽 32225 [[Special:Contributions/126.253.159.149|126.253.159.149]] ([[User talk:126.253.159.149|トーク]]) による版 206050 を取り消し。荒らし wikitext text/x-wiki {{Pathnav|メインページ|frame=1}}{{蔵書一覧}} ここは普通教育に関する教科書・資料を収めておく書庫です。以下の書籍が収録されています。なお、ウィキブックスの読み方などについては[[小学校・中学校・高等学校の学習/ウィキブックスについて|こちら]]をご覧ください。 == 教科書 == * [[小学校の学習|{{ruby|小学校|しょうがっこう}}の{{ruby|教科書|きょうかしょ}}]] * [[中学校の学習|中学校の教科書]] * [[高等学校の学習|高等学校の教科書]] (※令和元年度以降の学習指導要領へ対応するための改訂が遅れています。[[高等学校の学習/旧課程|旧課程版]]も参考にしてください) === 重要事項 === 現在(2022年)、小学校・中学校・高等学校では新学習指導要領が施行されています。各教科を執筆・編集の際には、学習指導要領や各教科書会社の移行措置資料などもあらかじめ確認されますようお願いいたします(特に英語・数学(算数)・理科・共通教科情報科は学年を移行する内容や新規追加される内容が多い教科となっています)。 == 学習・生活ガイド == * [[学習方法]](小中高の全般および各科目ごと) * [[生活ガイド]] === 小学校 === * [[小学校ガイド]] * [[学習方法/小学校全般|{{ruby|学習方法|がくしゅうほうほう}}/小学校{{ruby|全般|ぜんぱん}}]] {{ruby|各教科|かくきょうか}}の{{ruby|学習法|がくしゅうほう}}は『{{ruby|学習方法|がくしゅうほうほう}}』にあります。 === 中高総合 === * [[学習方法/中学高校の学習全般]] * [[中学高校の生活ガイド全般]] === 中学校 === * [[中学生活ガイド]] * [[学習方法/中学校全般]] 各教科の学習法は『学習方法』にあります。 === 高等学校 === * [[高校生活ガイド]] * [[学習方法/普通科高校全般]] * [[学習方法/高校5教科全般]] * [[学習方法/大学受験5教科全般]] 各教科の学習法は『学習方法』にあります。 == 受験ガイド・参考書 == * [[受験ガイド]] === 中学受験 === * [[中学受験ガイド]] * [[中学受験参考書]] === 高校受験 === * [[高校受験ガイド]] * [[高校受験参考書]] === 大学受験 === * [[日本の大学受験ガイド]] * [[外国の大学受験ガイド]] * [[大学受験参考書]] == 中高一貫校の教科書・生活ガイド == * [[中高一貫校の学習|中高一貫校の教科書]] * [[中高一貫校生活ガイド]] == 検定 == * 学校で必要で基準がはっきりしてる物を扱う［算・漢・英（中学から）：検］ * 一般的にイー・タイピングやP〈パソコン〉検はコンピューター需要が関わる * 団体応募があるが雇用に含むか疑問視する点がある == 資料 == ;演習 * [[小・中・高等学校演習]] ;学校制度の紹介 * [[生活と進路]] ;他の教科書 * [[大学の学習|大学の教科書]] * [[特別支援学校の学習]] ;就職活動ガイド * [[就職活動ガイド]] ;編集に参加したい人へ * [[小学校・中学校・高等学校の学習/ウィキブックスで教科書を執筆する人へ|ウィキブックスで教科書を執筆する人へ]] * [[検定教科書|検定教科書の閲覧・購入]] * [[Wikibooks:児童・生徒の方々へ]] [[Category:普通教育|しようかつこうちゆうかつこうこうとうかつこうのかくしゆう]] [[Category:書庫|しようかつこうちゆうかつこうこうとうかつこうのかくしゆう]] cppjzyv1w5vke0ta20o439daabfbveq 0 3121 206115 205141 2022-08-01T08:06:19Z 106.154.143.149 /* 英語（文理共通） */ wikitext text/x-wiki {{Wikipedia|名古屋大学}} * [[日本の大学受験ガイド]] > [[名古屋大対策]] 本項は、[[w:名古屋大学|名古屋大学]]の「一般入学試験」対策に関する事項である。 名古屋大学（名大）は、最後に設立された帝国大学である。大学入試標準レベル～やや難レベルの問題が中心の入試内容になっているので、受験生の勉強量の差が如実に現れる入試であると言える。標準レベルとは言うものの、誤魔化しや付け焼刃の勉強法では全く通用しない。解法パターンの丸暗記や小手先のテクニック等に頼った勉強ではなく、基本原理を押さえて理解することに重点を置いた対策が必要である。 大学入学共通テストの配点が工学部以外では圧縮されずに加算される(工学部は600点に圧縮。それでも高めだが…)ので、共通テストでも高い点数が求められる。 倍率は、年度によって変動もあるが、例年文系学部が2倍前後、理系学部が2～3倍程度である。近年倍率が上昇しており、特に文系で如実である。 == 英語（文理共通） == 外国語は、英語のみ（他の言語は全て選択不可）。 問題の出題数は４題で、2010年以降は、読解問題2題、会話文1題、英作文1題となっており、試験時間は105分である。 記述問題が中心で、その多くは字数制限が設けられている。 解答に時間のかかる設問が少なく、なかには標準的な問題も散見されるが、英語の読解力、表現力をはかる易問が多い。また標準的な自由英作文も出題されている。 第一問、第二問は論説文が中心で、文化・社会・教育・科学などの多岐にわたるテーマから出題される。前年発行の雑誌を出典とするなど、最新の話題を取り上げる傾向にあるようだ。 読解のレベルとしては、標準からやや難といったところである。 第三問は、問題が英文のみの会話文の問題が出題される。記号問題が多いが、英文で自分の意見や考えを述べる自由英作文が出された。 第四問は和文英訳で標準的な難度の出題である。やや訳すのが難しい日本語は、自分で簡単な日本語に置き換えて英文に訳すのが鉄則である。 対策としては、学校の授業、自習などを通して高い語彙力、読解力の養成をし、基本的な英文のパターンを頭に入れたうえで本番が近付いてくると、名古屋大学の過去問にも目を通すと良い。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。過去問と併せて名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりはこれまでやった過去問で読解をする上で必要となる単語や文法そして構文の整理に使った方が賢明である。毎年多かれ少なかれ傾向が変わるのが逆に名古屋大学の特徴ともいえるので、二次本番では解答開始時に昨年と比べて傾向がどう変わったのかを確認し、時間配分を考えつつ、解答作成に取り掛かるのを意識しておくとよい。 == 数学 == 本学は大学入試の数学では珍しく、文理共通で試験問題に付録として「数学公式集」が与えられる（持ち帰り可）。出題者の意図は不明確だが、解答作成において使用しても何ら支障は無い。ただこれが解答作成の上で役に立った事例は極めて稀だそうである。解答形式は、文理そして全題共通して計算の過程と解答を記入しなければならない論述式である。問題形式は同じく文理共通で、解答の際に配布されるB4の表紙付右開き冊子の中に試験問題・数学公式・答案紙（文科系3枚、理科系4枚）が入っている。このうち、提出は答案紙のみである。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。もう少し欲しいならば、直近の5年分（教学社の赤本が対応）でも良い(他科目そして共通テストとの折り合いを考えれば、分量としてはこれが限界かもしれない)。前記の過去問と、名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりは公式を再確認やこれまでに扱った問題の答案作成の精度向上に使った方が賢明である。 === 文系 === 大問は3題で、難易度は易〜標準レベルであったが、それは過去の話で、2018年以降はかなり厳しい出題が続いており、標準より難しい～かなり難しい問題が並ぶ。また、2020年はなんと確率が出題されず、問題自体も過去最難レベルの問題であった。文系数学ではトップクラスの難しさであるため、点を取るにはかなりの実力が要求される。積分、ベクトル、図形と方程式、確率が頻出であり、特に高次関数の微積分、場合の数と確率漸化式の融合が多い。過去問を中心に傾向を把握し、対策することが有効と言える。 === 理系 === 試験時間は150分である。大問数は、例年4題である。難易度については2014年以降、かなりハイレベルな出題が続いており、問題全体は1990年代から2007年まで（解答時間が120分）に比べると難化しつつある。特に2011年度は過去10年で最難といえるほどに難化したが、2012年度以降も数学の難化傾向にあり、さらに2018年以降は完答出来るものが無いに等しいほどに凄まじい難度となっており、今後もこのレベルが名古屋大学として標準になると思われる。このようなことから、もはや1998年のような非常に易しい問題が4題で構成された時代（数学が非常に得意であれば、4題全完も可能であった）は終焉を迎えたと言っても過言ではない。2020年現在で、ここ10年の傾向としては1～2題は標準～やや難(名古屋大受験生を基準)、1～2題は難(完答できなくても合否にはほとんど影響はない)である。前記の2題を見極めて、難レベルの1～2題を後回しにできるかがカギとなる。 具体的な出題内容は、「微積分」「確率」は必ず1題ずつ出るといっても良いくらい頻出項目であり、「数列」「帰納法」も頻出である。また、「ベクトル」や「複素数」も良く出題されるが、すべての分野において基本レベルでは不十分で、特に微積、確率、数列、整数は相当の実力がなければ完答あるいは差をつけるのは難しい。どの分野の問題も4問150分であるからか非常に良く練られており、かなり重く難しい。予備校のテキストなどを1冊何度もやり込むことが対策となる。過去問も時間の許す限りできるだけ多くの年度の問題を解いておいてほしい。旧課程(2006年~2014年)のときは「整数問題」「行列」「微積分」「平面・空間幾何」「確率」が割合的に大半を占める。「数列」はこれらの分野に必ず融合させて出題される傾向が強い。2011年度入試第2問は「行列」「確率」「数列(確率漸化式)」の3分野を融合させた問題であった。 また、誘導が丁寧な問題が殆どであり、小問の考え方、計算過程や答えが最後の小問のヒントになっている場合が少なくない。ただし小問がヒントとしてあまり役に立たない問題(2002年度大問2など)も出題されているので注意すること。また、出題頻度は少ないが小問なしの問題も出題されている。これらの問題は教育的配慮からか難易度は標準的な問題が多いが、一部難問も存在する。 出題方式は、4題構成でうち大問4は2問から1問を選ぶ選択形式（4a,4b）で計4題を解答する形式であったが、2010年以降は選択問題(一時、1999年は選択形式が無かった)はなくなり、選択問題のない4題必須解答形式となっている。2020年までこの傾向が続いており、この形が続く可能性はある。とはいうものの、ある年突然に前述の選択形式が復活する可能性も否めない。この選択形式が出題された場合は、受験生の得意な問題を解答しても構わないが、試験中にどちらを解答するかを迷うのは良くない。この選択問題の難易度を見極められる選球眼を普段から鍛えておくことが重要で、そのためには好き嫌いや得手不得手な分野を作るのではなく、バランスよく対策しておくことが重要である。 試験時間150分に対して大問数4題と時間的な余裕が与えられている。問題の難易度は別として単純計算すると、1題あたりに与えられる平均時間は37.5分だが、これは全国の大学を見ても多い(参考に解答時間を比較的多く与えられている東京工業大学は、試験時間180分で36分/題)。解答時間は十分与えられているだけに、完成度の高い答案が求められるようになった、と言っても過言ではない。但し、それなりに難度も上がり、完答はむしろ難しくなった。対策としては、必ず出題される標準的な問題を確実に獲得した上で、難問に対しても要を得た解法やアプローチを示して部分点を1点でも多く狙うことが合格最大のポイントである。解答の過程も書くことが求められる、即ち解法や着眼点も評点の対象となるので、このような論述式の利点を活用することが大切である。また、前記のようにより完成度の高い答案が求められるだけに確実にわかる知識の範囲で答案作成すること、そして自身で作成した答案の過程はきちんと論理性があるかどうか（自身で読んで理解できないものは、他者が読むとさらに理解できない）、等と答案を作成した後に客観的に見直すことが重要となる。得点は標準レベルは満点確保、やや難で満点にできるだけ近い部分点を稼ぐ、難レベルも少ないながらも部分点を獲得する(数学と言う科目の性質上、至難の業ではあるが…。)が理想である。以上のことから、日本で最も難しい数学の問題を出す大学である。 == 国語 == 文系・理系の区別なく共通の問題が出題される。2022年度現在、文系では文・教育・経済学部で、理系では理・医・農学部(現代文のみ／150点満点)で課されている。試験時間は理系（現代文のみ）では45分、文系では105分であるから現代文に45分、古・漢文に60分かけるのが標準的なのであろう。全体的に難易度は高めである。それぞれの分野が重厚さを持っているので本文を速読し、深く理解する力をつけることが重要となってくる。ちなみに2008年度は理学部・医学部医学科での国語導入のせいか特殊な出題があった。</br> '''現代文'''：例年、長い文章をテーマにしており、漢字の読み・書きなどから字数制限つきの説明問題など毎年6問程度での構成となっている。「抜き出せ」という問題は毎年出題されており、これと漢字に関する問題は説明問題の難易度を考えれば絶対に落とせない問題である。さて、その説明問題であるが毎年3～4問ほどあり、字数も60～100字程度の字数制限がつく。解答欄には与えられた字数＋10文字分のマス目が載せられている。難易度は高めであり日ごろからこのような形式の問題に慣れていなければ全問解答はまず不可能だろう。扱っている題材には抽象的な内容を含むものが多く、素材の文章自体が難易度を上げているためより難しめに感じるかもしれない。国語に充てる時間が短い理系には特に厳しい。2008年度は本文中の空欄に当てはまるように本文中の漢字2文字を抜き出させる本学としては特殊な問題が出題された。 '''古文'''：文章自体は少し長め。問題数は3つである。1問目は傍線部の口語訳で2、3問目は所定の解答欄に現代文で説明を書く問題である。本学の古典では、選択肢を選ぶ問題がないのが一般的であるため私立大学の古典に対する対策よりも論述性を重視した対策が必要になる。現代文と同様、簡潔に説明できる能力を平素の学習で養うことが望ましい。知識問題は出題されないが、それそのものが不要というわけではなく読解の助けになることもあるので平素の学習からさまざまな古文に触れていくことが大切。現代文と同様に難易度は高い。2008年度は例外的に選択肢を選ぶ問題と、本文とは別に与えられた文章の空欄補充問題があった。 '''漢文'''：共通テストよりも長めくらいの本文に対し6問程度が与えられる。1問目は読みを仮名で書く問題でありその他は全て説明問題となっている。特徴的なのは最後の150字説明問題であり、現・古・漢の中で最も重厚な問題であるといえる。古文同様、古典的知識は読解の助けになりうる。こちらも文章そのものの読みにくさから難易度は高い。2008年度は7問出題された。 == 小論文（法学部） == 法学部では国語の代わりに小論文が課される。大学入試小論文としては難易度はやや高い方である。試験時間は90分、解答字数は全問あわせて1000字程度である。課題文は、法学や政治学など社会科学系のテーマを取り上げた、比較的長めではあるが読みやすい文章が出題される。設問は、課題文の内容理解を問う問題（200字程度、1～2題）と、意見論述（600字～800字程度、1題）の形式で定着している。社会科学系志望者として最低限必要な法学・政治学関連の予備知識を、講座の演習などを通じて押さえおかなければならない。さらに、新聞やニュースなどを通して、現代社会のトピックに関する知識を養っておくとよい。 意見論述問題では、筆者の主張に対して自己の賛成・反対意見を論じる出題だけでなく、筆者の議論を踏まえて考察する問題など、幅広い出題が想定される。本文を丁寧に読解して端的に課題文の主張・論拠をまとめるとともに、自己の論拠を明確にして説得力のある主張を述べることを心がけたい。また、600～800字という論述字数は、日頃から演習を積んでおかないとまとめるのに苦労する。過去問演習を通してなるべく多くの年度の問題にあたり、学校や予備校の先生に添削してもらおう。また、名大法学部以外で似たような傾向の小論文として、[[慶應義塾大対策|慶應義塾大学法学部]]の論述力という科目がある。課題文は抽象的な用語が目立つ非常に難しいものであるが、社会科学的な予備知識に基づいて意見を論述するという意味で、設問の傾向は非常に似ているので、もし時間に余裕があるようであればぜひ挑戦してほしい。 以下も参考にしてほしい。 *[[大学受験小論文の勉強法]] == 理科 == 試験時間は、二科目でまとめて150分（情報学部自然情報学科では一科目で75分）である（二科目受験の場合は一科目ごとの時間配分は厳密に設けられておらず、一科目終了後の答案回収は行わない）。学部によっては、必須科目もあるので本学発行の受験案内等で事前に確認しておくことが好ましい。 === 物理（物理基礎/物理）=== 大問数は3題で構成される。1題は力学であり単振動や等加速運動など力学全般から幅広く出題される。ドップラー効果など波動との融合問題もある。また、惑星探査衛星など受験生にはあまり馴染みのない内容を取り上げる、思考力を要する問題が目立ってきている。電磁気も力学同様電磁気全般から幅広く出題される。また、難易度が不安定なのが名大物理の特徴であり、簡単な時は合格平均が6割を越えることもあるが、難化すると凄まじい難易度になり、合格者平均が3割を割りかねない程になる。 計算量は簡単な年はやや多いぐらいであるが、難しい年は完答不可能なレベルになるので、計算ミスに気を付けつつ、確実に取れる所を進めていこう。合格点としては近年なら医学部医学科は7割、その他学部は5割程度で十分だろう。(ただし難易度による) 2017年度までは、大問1は力学、大問2は電磁気、大問3は波動・熱力学で構成されていたが、2018年度では熱力学→電磁気→力学、2019年度では力学→熱力学→電磁気の順で出題された。この変更に対する意図は不明である。 力学は見慣れない設定での出題が多く、難易度も高いが、基本に忠実にこなしていけば、得点源となるだろう。 電磁気はコンデンサーや直流回路に関する問題が頻出である。こちらも誘導が丁寧なので落ち着いて解けば満点解答も可能だが、入試問題としてはやや難のレベルで出題されるので油断は禁物である。 波動・熱力学はどちらか一方の分野のみでの出題、両方を融合した出題が見受けられる。2010年度の大問3はこれらの分野を融合した問題であった(実際のところは熱力学の問題は1問のみで実質的に波動の問題。2014年の問題にはレンズの理解を深く問う問題が出題された。 かつては、（名大に合格する受験生のレベルならば）得点は満点からどれだけマイナスかで計算する、と言ったような難易度であったが、2013年頃から難易度は大幅に上昇している。例として2014年は凄まじく難化し、合格点が3割くらいまで落ちた。更に2020年は過去の名大どころか入試でも類を見ない程に難しく、ある情報では合格点が2割ちょっとであったらしい。今後もこの難度が名大物理として標準となる、と思われる。理系数学と同様、前記のような「満点からどれだけマイナスかで計算する」時代は終焉を迎えたと言っても過言ではない。また、2007年までは理科二科目(試験時間は計120分)受験必須の学部は大問2題(大問1は力学、大問2は電磁気の出題が基本)であり平均で30分/題だったが、2008年度からは上記のように基本は大問3題が出題されたことで平均で25分/題となり、1題の平均解答時間が短くなったことも難化の原因と言える。対策としては、典型的な問題を確実に解けるようにするだけでなく、教科書などを読み、公式などの原理を理解したうえで、過去問に取り組むのが望ましい。 但し、過去問を解き始める時は、時間内に終わらないので、はじめは90分を、目安に、その後、約70分で解くことが望ましい。 答案形式は、解答のみ記入する欄と計算の過程と解答の両方を記入する欄（一部では、論述をするための枠もあり）で構成される。解答のみ記入する部分は計算の過程が合っていても記載が間違っていれば、失点になる可能性になるが高いので、計算あるいは記載の間違いには特に気を付けることが必要である。また、前述のように難易度が不安定なので、物理で差をつけようとするのはあまり得策ではない。(勿論人によるが…。)なので、普通の年の難易度なら合格点を取れるレベルなら、他の教科を安定させた方が良いかもしれない。 以上から、易しい年なら高得点が狙えるが、難化した年は全入試でも最難レベルの問題を出す大学である。 === 化学（化学基礎/化学）=== 共通テストの選択肢を隠して記述として問題を解けば名大化学の対策にも通じるといえる。理論・無機・有機・高分子とすべての分野の基本事項はできるようにしておきたい。その上で私たちの日常生活にどのように活用されているかなどを考えると良いだろう。 近年は、理論・無機で大問3つ、有機で大問1つずつの合計5問で構成されている。 理論は気圧計算が頻出であり、近年は結晶構造や熱化学などもよく出題されている。基本的事項のみで解ける問題は多いがやや難度の高い問題も出題されている。とは言ってもマニアックな知識が必要とされる問題は出題されないので標準レベルの重要事項をどれだけモノにできるかが大切であろう。計算は簡単なものから計算力を要するものまであるため、日ごろからモル計算や気圧計算などに親しんでおくことも大切。 無機は基本事項をどれだけ押さえられたかが肝である。細かな部分も多少は覚えておくことが望ましい。 有機（化学）は構造決定が頻出であり、それのみで大問が構成されていた年度もある。基本的知識の組み合わせのみで解ける問題が多いが普段から構造決定に慣れておかなければ手間取ってしまうこともあるので日々の練習で的確かつ素早く構造決定できるようにしておきたい。それ以外の基本も押さえておくこと。油脂もよく出題されている。高分子を絡めた出題があるので注意。さらに糖類・アミノ酸(タンパク質)・高分子化合物をテーマにして出題してくるが生物選択者が多少有利な小問があったりする。それでも基本的な事柄を問うていることがほとんどであるからこの大問で点数を落とすことは避けたい。 == 模試 == 本大対応模試として、[[w:河合塾|河合塾]]の名大入試オープン（年に2回開催されるが、第2回の成績を重視されたい）、[[w:代々木ゼミナール|SAPIX YOZEMI GROUP]]の名大入試プレ<ref>理科では「地学基礎・地学」、地理歴史では「地理B」の試験は実施しない。</ref>（2020年度は、9月に実施）、[[w:駿台予備校|駿台]]の名大入試実戦模試<ref>答案は2021年実施分よりWeb返却（駿台のマイページにPDF形式で掲載。掲載期間は、Web公開開始日から3ヶ月間。）のみとなり、紙の答案による返却は廃止となった。</ref>、[[w:東進予備校|東進]]の本番レベル模試（2020年度は、年に3回開催）がある（判定は、いずれも前期日程のみ）。各予備校は、大学の傾向を徹底的にチェックして大学別の予想問題を作成しているので、受験すれば、本番の入試に向けて大きな指針となり、本番の雰囲気に慣れることにもなる。また過去問だけでも物足りなさを感じるのであれば、河合出版からの過去の名大入試オープンを5回分収録した問題集「入試攻略問題集　名古屋大学」（英語・数学）が市販されているため、時間があれば取り組んでみるのもよい。 年によっては、名古屋大学（東山キャンパス）内に受験会場が設置されることがある。本学を志願する受験生にとっては、受験会場の雰囲気に慣れることや受験会場の下見も兼ねることにもなることで、良い機会となる。 加えて、主に高1・2生が対象になるが、2021年度は東進で「名大入試同日体験受験」(2月25日・26日)という模試が開催される。これは同年の前期日程入試本番に出題された問題を同日に同解答時間・同スケジュール(但し、試験開始と終了時刻は異なる)で解くというものである。試験開始と終了の時刻は違えど、前期日程入試と同じスケジュールで試験を受けることができる（医学部医学科の面接試験は実施せず）。模擬試験とは違った本番ならではの感覚を味わうまたとない機会と言えるので、本学を希望するならば受験しておくと良いかもしれない。 == 二段階選抜 == 後期日程（医学部医学科のみ）で定員5名に対して志願倍率が12倍（志願者数60名）を超えた場合、実施される。選考方法は大学入学共通テスト成績に基づき、高得点順に上位60名を合格者する。<br> 令和4年度以降は医学部医学科の前期日程・後期日程の受験者に対して、それぞれ大学入学共通テストの成績が 900 点満点中 700 点以上の者が、第1段階の合格者となる。 == 面接試験 == '''医学部医学科のみ'''実施される。実施内容は、以下である。*2020年度実施分よりインターネット出願が導入され、紙媒体の募集要項の配布はなくなったので、志願理由書は名古屋大学の公式ホームページよりダウンロード(PDF文書)してプリントアウトして記入する必要がある。2020年度以降の受験者は、インターネット環境を整えておくことはおろか、プリンターを用意することが好ましい。 '''前期日程'''</br> 筆記試験（2/25・26）終了後の翌27日、本大学受験者全員に対して課される。前期日程試験は、筆記試験(2日間がけ)+面接試験(1日完結)の3日間である。注意点として、筆記試験と面接試験は実施されるキャンパスが異なることである。筆記試験は東山キャンパス（名古屋大学本部）で、面接試験は鶴舞キャンパス(名大病院・医学部医学科専用キャンパス)で実施されるので、試験会場をくれぐれも間違えないように注意すること。 '''後期日程'''</br> 3/12の1日間で実施。後期日程試験は、この面接試験のみである（筆記試験は実施せず）。面接試験は鶴舞キャンパスで実施される。 == 高得点者選抜 == この大学の特徴として、国立大学でありながら私立によく見られる「高得点者選抜」がある。これは大学入学共通テストの成績のみ、あるいは個別学力検査の成績のみで評価されるものだが、どちらの方法であっても高い得点力が要求される。確約は出来ないが、大学入学共通テストは9割あるいは9割5分あればほぼ安全圏、そして個別学力検査は最低でも7割5分～8割程度（但し、2020年度時点での直近10年の試験問題の難度からすると、これもかなり至難の業）あれば可能圏内と思われる。令和3年度は工学部（大学入学共通テストの成績のみで選抜／個別学力検査の成績のみで選抜，いずれも各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）と、農学部（個別学力検査の成績のみでの選抜，各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）で実施されている。 == その他 == 工学部は学科ごとに入試で選考され、本人の希望と1年次の成績で2年進級時にコース分けされる。たとえば、機械・航空宇宙工学科は2年次から「機械システム工学・電子機械工学・航空宇宙工学」とコースが3つに分かれるが、中でも航空宇宙工学コースは人気があり例年定員以上の希望がある。 理学部は一括で選考され、2年進級時に学科配属となる。物理学科・化学科・生命理学科は例年人気が有り、定員オーバーとなることもある。この場合、一年時の取得単位状況による選考となる。 =脚注= <references/> == 関連リンク == *[http://www.nagoya-u.ac.jp/ 名古屋大学]：公式サイト [[Category:大学入試|なこやたいたいさく]] 9qxbco4aq7ejrtm69wmmwbzx0oebqjr 206116 206115 2022-08-01T08:11:57Z 106.154.143.149 /* 理系 */ wikitext text/x-wiki {{Wikipedia|名古屋大学}} * [[日本の大学受験ガイド]] > [[名古屋大対策]] 本項は、[[w:名古屋大学|名古屋大学]]の「一般入学試験」対策に関する事項である。 名古屋大学（名大）は、最後に設立された帝国大学である。大学入試標準レベル～やや難レベルの問題が中心の入試内容になっているので、受験生の勉強量の差が如実に現れる入試であると言える。標準レベルとは言うものの、誤魔化しや付け焼刃の勉強法では全く通用しない。解法パターンの丸暗記や小手先のテクニック等に頼った勉強ではなく、基本原理を押さえて理解することに重点を置いた対策が必要である。 大学入学共通テストの配点が工学部以外では圧縮されずに加算される(工学部は600点に圧縮。それでも高めだが…)ので、共通テストでも高い点数が求められる。 倍率は、年度によって変動もあるが、例年文系学部が2倍前後、理系学部が2～3倍程度である。近年倍率が上昇しており、特に文系で如実である。 == 英語（文理共通） == 外国語は、英語のみ（他の言語は全て選択不可）。 問題の出題数は４題で、2010年以降は、読解問題2題、会話文1題、英作文1題となっており、試験時間は105分である。 記述問題が中心で、その多くは字数制限が設けられている。 解答に時間のかかる設問が少なく、なかには標準的な問題も散見されるが、英語の読解力、表現力をはかる易問が多い。また標準的な自由英作文も出題されている。 第一問、第二問は論説文が中心で、文化・社会・教育・科学などの多岐にわたるテーマから出題される。前年発行の雑誌を出典とするなど、最新の話題を取り上げる傾向にあるようだ。 読解のレベルとしては、標準からやや難といったところである。 第三問は、問題が英文のみの会話文の問題が出題される。記号問題が多いが、英文で自分の意見や考えを述べる自由英作文が出された。 第四問は和文英訳で標準的な難度の出題である。やや訳すのが難しい日本語は、自分で簡単な日本語に置き換えて英文に訳すのが鉄則である。 対策としては、学校の授業、自習などを通して高い語彙力、読解力の養成をし、基本的な英文のパターンを頭に入れたうえで本番が近付いてくると、名古屋大学の過去問にも目を通すと良い。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。過去問と併せて名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりはこれまでやった過去問で読解をする上で必要となる単語や文法そして構文の整理に使った方が賢明である。毎年多かれ少なかれ傾向が変わるのが逆に名古屋大学の特徴ともいえるので、二次本番では解答開始時に昨年と比べて傾向がどう変わったのかを確認し、時間配分を考えつつ、解答作成に取り掛かるのを意識しておくとよい。 == 数学 == 本学は大学入試の数学では珍しく、文理共通で試験問題に付録として「数学公式集」が与えられる（持ち帰り可）。出題者の意図は不明確だが、解答作成において使用しても何ら支障は無い。ただこれが解答作成の上で役に立った事例は極めて稀だそうである。解答形式は、文理そして全題共通して計算の過程と解答を記入しなければならない論述式である。問題形式は同じく文理共通で、解答の際に配布されるB4の表紙付右開き冊子の中に試験問題・数学公式・答案紙（文科系3枚、理科系4枚）が入っている。このうち、提出は答案紙のみである。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。もう少し欲しいならば、直近の5年分（教学社の赤本が対応）でも良い(他科目そして共通テストとの折り合いを考えれば、分量としてはこれが限界かもしれない)。前記の過去問と、名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりは公式を再確認やこれまでに扱った問題の答案作成の精度向上に使った方が賢明である。 === 文系 === 大問は3題で、難易度は易〜標準レベルであったが、それは過去の話で、2018年以降はかなり厳しい出題が続いており、標準より難しい～かなり難しい問題が並ぶ。また、2020年はなんと確率が出題されず、問題自体も過去最難レベルの問題であった。文系数学ではトップクラスの難しさであるため、点を取るにはかなりの実力が要求される。積分、ベクトル、図形と方程式、確率が頻出であり、特に高次関数の微積分、場合の数と確率漸化式の融合が多い。過去問を中心に傾向を把握し、対策することが有効と言える。 === 理系 === 試験時間は150分である。大問数は、例年4題である。難易度については2014年以降、かなりハイレベルな出題が続いており、問題全体は1990年代から2007年まで（解答時間が120分）に比べると難化しつつある。特に2011年度は過去10年で最難といえるほどに難化したが、2012年度以降も数学の難化傾向にあり、さらに2018年以降は完答出来るものが無いに等しいほどに凄まじい難度となっており、今後もこのレベルが名古屋大学として標準になると思われる。このようなことから、もはや1998年のような非常に易しい問題が4題で構成された時代（数学が非常に得意であれば、4題全完も可能であった）は終焉を迎えたと言っても過言ではない。2020年現在で、ここ10年の傾向としては1～2題は標準～やや難(名古屋大受験生を基準)、1～2題は難(完答できなくても合否にはほとんど影響はない)である。また、数年に1度の程度であるが、超難（言うまでもなく捨てても、合否にはほとんど影響はない）が1題出題されることも有る。前記の2題を見極めて、難レベルの1～2題（超難レベルの1題を含む）を後回しにできるかがカギとなる。 具体的な出題内容は、「微積分」「確率」は必ず1題ずつ出るといっても良いくらい頻出項目であり、「数列」「帰納法」も頻出である。また、「ベクトル」や「複素数」も良く出題されるが、すべての分野において基本レベルでは不十分で、特に微積、確率、数列、整数は相当の実力がなければ完答あるいは差をつけるのは難しい。どの分野の問題も4問150分であるからか非常に良く練られており、かなり重く難しい。予備校のテキストなどを1冊何度もやり込むことが対策となる。過去問も時間の許す限りできるだけ多くの年度の問題を解いておいてほしい。旧課程(2006年~2014年)のときは「整数問題」「行列」「微積分」「平面・空間幾何」「確率」が割合的に大半を占める。「数列」はこれらの分野に必ず融合させて出題される傾向が強い。2011年度入試第2問は「行列」「確率」「数列(確率漸化式)」の3分野を融合させた問題であった。 また、誘導が丁寧な問題が殆どであり、小問の考え方、計算過程や答えが最後の小問のヒントになっている場合が少なくない。ただし小問がヒントとしてあまり役に立たない問題(2002年度大問2など)も出題されているので注意すること。また、出題頻度は少ないが小問なしの問題も出題されている。これらの問題は教育的配慮からか難易度は標準的な問題が多いが、一部難問も存在する。 出題方式は、4題構成でうち大問4は2問から1問を選ぶ選択形式（4a,4b）で計4題を解答する形式であったが、2010年以降は選択問題(一時、1999年は選択形式が無かった)はなくなり、選択問題のない4題必須解答形式となっている。2020年までこの傾向が続いており、この形が続く可能性はある。とはいうものの、ある年突然に前述の選択形式が復活する可能性も否めない。この選択形式が出題された場合は、受験生の得意な問題を解答しても構わないが、試験中にどちらを解答するかを迷うのは良くない。この選択問題の難易度を見極められる選球眼を普段から鍛えておくことが重要で、そのためには好き嫌いや得手不得手な分野を作るのではなく、バランスよく対策しておくことが重要である。 試験時間150分に対して大問数4題と時間的な余裕が与えられている。問題の難易度は別として単純計算すると、1題あたりに与えられる平均時間は37.5分だが、これは全国の大学を見ても多い(参考に解答時間を比較的多く与えられている東京工業大学は、試験時間180分で36分/題)。解答時間は十分与えられているだけに、完成度の高い答案が求められるようになった、と言っても過言ではない。但し、それなりに難度も上がり、完答はむしろ難しくなった。対策としては、必ず出題される標準的な問題を確実に獲得した上で、難問に対しても要を得た解法やアプローチを示して部分点を1点でも多く狙うことが合格最大のポイントである。解答の過程も書くことが求められる、即ち解法や着眼点も評点の対象となるので、このような論述式の利点を活用することが大切である。また、前記のようにより完成度の高い答案が求められるだけに確実にわかる知識の範囲で答案作成すること、そして自身で作成した答案の過程はきちんと論理性があるかどうか（自身で読んで理解できないものは、他者が読むとさらに理解できない）、等と答案を作成した後に客観的に見直すことが重要となる。得点は標準レベルは満点確保、やや難で満点にできるだけ近い部分点を稼ぐ、難レベルも少ないながらも部分点を獲得する(数学と言う科目の性質上、至難の業ではあるが…。)が理想である。以上のことから、日本で最も難しい数学の問題を出す大学である。 == 国語 == 文系・理系の区別なく共通の問題が出題される。2022年度現在、文系では文・教育・経済学部で、理系では理・医・農学部(現代文のみ／150点満点)で課されている。試験時間は理系（現代文のみ）では45分、文系では105分であるから現代文に45分、古・漢文に60分かけるのが標準的なのであろう。全体的に難易度は高めである。それぞれの分野が重厚さを持っているので本文を速読し、深く理解する力をつけることが重要となってくる。ちなみに2008年度は理学部・医学部医学科での国語導入のせいか特殊な出題があった。</br> '''現代文'''：例年、長い文章をテーマにしており、漢字の読み・書きなどから字数制限つきの説明問題など毎年6問程度での構成となっている。「抜き出せ」という問題は毎年出題されており、これと漢字に関する問題は説明問題の難易度を考えれば絶対に落とせない問題である。さて、その説明問題であるが毎年3～4問ほどあり、字数も60～100字程度の字数制限がつく。解答欄には与えられた字数＋10文字分のマス目が載せられている。難易度は高めであり日ごろからこのような形式の問題に慣れていなければ全問解答はまず不可能だろう。扱っている題材には抽象的な内容を含むものが多く、素材の文章自体が難易度を上げているためより難しめに感じるかもしれない。国語に充てる時間が短い理系には特に厳しい。2008年度は本文中の空欄に当てはまるように本文中の漢字2文字を抜き出させる本学としては特殊な問題が出題された。 '''古文'''：文章自体は少し長め。問題数は3つである。1問目は傍線部の口語訳で2、3問目は所定の解答欄に現代文で説明を書く問題である。本学の古典では、選択肢を選ぶ問題がないのが一般的であるため私立大学の古典に対する対策よりも論述性を重視した対策が必要になる。現代文と同様、簡潔に説明できる能力を平素の学習で養うことが望ましい。知識問題は出題されないが、それそのものが不要というわけではなく読解の助けになることもあるので平素の学習からさまざまな古文に触れていくことが大切。現代文と同様に難易度は高い。2008年度は例外的に選択肢を選ぶ問題と、本文とは別に与えられた文章の空欄補充問題があった。 '''漢文'''：共通テストよりも長めくらいの本文に対し6問程度が与えられる。1問目は読みを仮名で書く問題でありその他は全て説明問題となっている。特徴的なのは最後の150字説明問題であり、現・古・漢の中で最も重厚な問題であるといえる。古文同様、古典的知識は読解の助けになりうる。こちらも文章そのものの読みにくさから難易度は高い。2008年度は7問出題された。 == 小論文（法学部） == 法学部では国語の代わりに小論文が課される。大学入試小論文としては難易度はやや高い方である。試験時間は90分、解答字数は全問あわせて1000字程度である。課題文は、法学や政治学など社会科学系のテーマを取り上げた、比較的長めではあるが読みやすい文章が出題される。設問は、課題文の内容理解を問う問題（200字程度、1～2題）と、意見論述（600字～800字程度、1題）の形式で定着している。社会科学系志望者として最低限必要な法学・政治学関連の予備知識を、講座の演習などを通じて押さえおかなければならない。さらに、新聞やニュースなどを通して、現代社会のトピックに関する知識を養っておくとよい。 意見論述問題では、筆者の主張に対して自己の賛成・反対意見を論じる出題だけでなく、筆者の議論を踏まえて考察する問題など、幅広い出題が想定される。本文を丁寧に読解して端的に課題文の主張・論拠をまとめるとともに、自己の論拠を明確にして説得力のある主張を述べることを心がけたい。また、600～800字という論述字数は、日頃から演習を積んでおかないとまとめるのに苦労する。過去問演習を通してなるべく多くの年度の問題にあたり、学校や予備校の先生に添削してもらおう。また、名大法学部以外で似たような傾向の小論文として、[[慶應義塾大対策|慶應義塾大学法学部]]の論述力という科目がある。課題文は抽象的な用語が目立つ非常に難しいものであるが、社会科学的な予備知識に基づいて意見を論述するという意味で、設問の傾向は非常に似ているので、もし時間に余裕があるようであればぜひ挑戦してほしい。 以下も参考にしてほしい。 *[[大学受験小論文の勉強法]] == 理科 == 試験時間は、二科目でまとめて150分（情報学部自然情報学科では一科目で75分）である（二科目受験の場合は一科目ごとの時間配分は厳密に設けられておらず、一科目終了後の答案回収は行わない）。学部によっては、必須科目もあるので本学発行の受験案内等で事前に確認しておくことが好ましい。 === 物理（物理基礎/物理）=== 大問数は3題で構成される。1題は力学であり単振動や等加速運動など力学全般から幅広く出題される。ドップラー効果など波動との融合問題もある。また、惑星探査衛星など受験生にはあまり馴染みのない内容を取り上げる、思考力を要する問題が目立ってきている。電磁気も力学同様電磁気全般から幅広く出題される。また、難易度が不安定なのが名大物理の特徴であり、簡単な時は合格平均が6割を越えることもあるが、難化すると凄まじい難易度になり、合格者平均が3割を割りかねない程になる。 計算量は簡単な年はやや多いぐらいであるが、難しい年は完答不可能なレベルになるので、計算ミスに気を付けつつ、確実に取れる所を進めていこう。合格点としては近年なら医学部医学科は7割、その他学部は5割程度で十分だろう。(ただし難易度による) 2017年度までは、大問1は力学、大問2は電磁気、大問3は波動・熱力学で構成されていたが、2018年度では熱力学→電磁気→力学、2019年度では力学→熱力学→電磁気の順で出題された。この変更に対する意図は不明である。 力学は見慣れない設定での出題が多く、難易度も高いが、基本に忠実にこなしていけば、得点源となるだろう。 電磁気はコンデンサーや直流回路に関する問題が頻出である。こちらも誘導が丁寧なので落ち着いて解けば満点解答も可能だが、入試問題としてはやや難のレベルで出題されるので油断は禁物である。 波動・熱力学はどちらか一方の分野のみでの出題、両方を融合した出題が見受けられる。2010年度の大問3はこれらの分野を融合した問題であった(実際のところは熱力学の問題は1問のみで実質的に波動の問題。2014年の問題にはレンズの理解を深く問う問題が出題された。 かつては、（名大に合格する受験生のレベルならば）得点は満点からどれだけマイナスかで計算する、と言ったような難易度であったが、2013年頃から難易度は大幅に上昇している。例として2014年は凄まじく難化し、合格点が3割くらいまで落ちた。更に2020年は過去の名大どころか入試でも類を見ない程に難しく、ある情報では合格点が2割ちょっとであったらしい。今後もこの難度が名大物理として標準となる、と思われる。理系数学と同様、前記のような「満点からどれだけマイナスかで計算する」時代は終焉を迎えたと言っても過言ではない。また、2007年までは理科二科目(試験時間は計120分)受験必須の学部は大問2題(大問1は力学、大問2は電磁気の出題が基本)であり平均で30分/題だったが、2008年度からは上記のように基本は大問3題が出題されたことで平均で25分/題となり、1題の平均解答時間が短くなったことも難化の原因と言える。対策としては、典型的な問題を確実に解けるようにするだけでなく、教科書などを読み、公式などの原理を理解したうえで、過去問に取り組むのが望ましい。 但し、過去問を解き始める時は、時間内に終わらないので、はじめは90分を、目安に、その後、約70分で解くことが望ましい。 答案形式は、解答のみ記入する欄と計算の過程と解答の両方を記入する欄（一部では、論述をするための枠もあり）で構成される。解答のみ記入する部分は計算の過程が合っていても記載が間違っていれば、失点になる可能性になるが高いので、計算あるいは記載の間違いには特に気を付けることが必要である。また、前述のように難易度が不安定なので、物理で差をつけようとするのはあまり得策ではない。(勿論人によるが…。)なので、普通の年の難易度なら合格点を取れるレベルなら、他の教科を安定させた方が良いかもしれない。 以上から、易しい年なら高得点が狙えるが、難化した年は全入試でも最難レベルの問題を出す大学である。 === 化学（化学基礎/化学）=== 共通テストの選択肢を隠して記述として問題を解けば名大化学の対策にも通じるといえる。理論・無機・有機・高分子とすべての分野の基本事項はできるようにしておきたい。その上で私たちの日常生活にどのように活用されているかなどを考えると良いだろう。 近年は、理論・無機で大問3つ、有機で大問1つずつの合計5問で構成されている。 理論は気圧計算が頻出であり、近年は結晶構造や熱化学などもよく出題されている。基本的事項のみで解ける問題は多いがやや難度の高い問題も出題されている。とは言ってもマニアックな知識が必要とされる問題は出題されないので標準レベルの重要事項をどれだけモノにできるかが大切であろう。計算は簡単なものから計算力を要するものまであるため、日ごろからモル計算や気圧計算などに親しんでおくことも大切。 無機は基本事項をどれだけ押さえられたかが肝である。細かな部分も多少は覚えておくことが望ましい。 有機（化学）は構造決定が頻出であり、それのみで大問が構成されていた年度もある。基本的知識の組み合わせのみで解ける問題が多いが普段から構造決定に慣れておかなければ手間取ってしまうこともあるので日々の練習で的確かつ素早く構造決定できるようにしておきたい。それ以外の基本も押さえておくこと。油脂もよく出題されている。高分子を絡めた出題があるので注意。さらに糖類・アミノ酸(タンパク質)・高分子化合物をテーマにして出題してくるが生物選択者が多少有利な小問があったりする。それでも基本的な事柄を問うていることがほとんどであるからこの大問で点数を落とすことは避けたい。 == 模試 == 本大対応模試として、[[w:河合塾|河合塾]]の名大入試オープン（年に2回開催されるが、第2回の成績を重視されたい）、[[w:代々木ゼミナール|SAPIX YOZEMI GROUP]]の名大入試プレ<ref>理科では「地学基礎・地学」、地理歴史では「地理B」の試験は実施しない。</ref>（2020年度は、9月に実施）、[[w:駿台予備校|駿台]]の名大入試実戦模試<ref>答案は2021年実施分よりWeb返却（駿台のマイページにPDF形式で掲載。掲載期間は、Web公開開始日から3ヶ月間。）のみとなり、紙の答案による返却は廃止となった。</ref>、[[w:東進予備校|東進]]の本番レベル模試（2020年度は、年に3回開催）がある（判定は、いずれも前期日程のみ）。各予備校は、大学の傾向を徹底的にチェックして大学別の予想問題を作成しているので、受験すれば、本番の入試に向けて大きな指針となり、本番の雰囲気に慣れることにもなる。また過去問だけでも物足りなさを感じるのであれば、河合出版からの過去の名大入試オープンを5回分収録した問題集「入試攻略問題集　名古屋大学」（英語・数学）が市販されているため、時間があれば取り組んでみるのもよい。 年によっては、名古屋大学（東山キャンパス）内に受験会場が設置されることがある。本学を志願する受験生にとっては、受験会場の雰囲気に慣れることや受験会場の下見も兼ねることにもなることで、良い機会となる。 加えて、主に高1・2生が対象になるが、2021年度は東進で「名大入試同日体験受験」(2月25日・26日)という模試が開催される。これは同年の前期日程入試本番に出題された問題を同日に同解答時間・同スケジュール(但し、試験開始と終了時刻は異なる)で解くというものである。試験開始と終了の時刻は違えど、前期日程入試と同じスケジュールで試験を受けることができる（医学部医学科の面接試験は実施せず）。模擬試験とは違った本番ならではの感覚を味わうまたとない機会と言えるので、本学を希望するならば受験しておくと良いかもしれない。 == 二段階選抜 == 後期日程（医学部医学科のみ）で定員5名に対して志願倍率が12倍（志願者数60名）を超えた場合、実施される。選考方法は大学入学共通テスト成績に基づき、高得点順に上位60名を合格者する。<br> 令和4年度以降は医学部医学科の前期日程・後期日程の受験者に対して、それぞれ大学入学共通テストの成績が 900 点満点中 700 点以上の者が、第1段階の合格者となる。 == 面接試験 == '''医学部医学科のみ'''実施される。実施内容は、以下である。*2020年度実施分よりインターネット出願が導入され、紙媒体の募集要項の配布はなくなったので、志願理由書は名古屋大学の公式ホームページよりダウンロード(PDF文書)してプリントアウトして記入する必要がある。2020年度以降の受験者は、インターネット環境を整えておくことはおろか、プリンターを用意することが好ましい。 '''前期日程'''</br> 筆記試験（2/25・26）終了後の翌27日、本大学受験者全員に対して課される。前期日程試験は、筆記試験(2日間がけ)+面接試験(1日完結)の3日間である。注意点として、筆記試験と面接試験は実施されるキャンパスが異なることである。筆記試験は東山キャンパス（名古屋大学本部）で、面接試験は鶴舞キャンパス(名大病院・医学部医学科専用キャンパス)で実施されるので、試験会場をくれぐれも間違えないように注意すること。 '''後期日程'''</br> 3/12の1日間で実施。後期日程試験は、この面接試験のみである（筆記試験は実施せず）。面接試験は鶴舞キャンパスで実施される。 == 高得点者選抜 == この大学の特徴として、国立大学でありながら私立によく見られる「高得点者選抜」がある。これは大学入学共通テストの成績のみ、あるいは個別学力検査の成績のみで評価されるものだが、どちらの方法であっても高い得点力が要求される。確約は出来ないが、大学入学共通テストは9割あるいは9割5分あればほぼ安全圏、そして個別学力検査は最低でも7割5分～8割程度（但し、2020年度時点での直近10年の試験問題の難度からすると、これもかなり至難の業）あれば可能圏内と思われる。令和3年度は工学部（大学入学共通テストの成績のみで選抜／個別学力検査の成績のみで選抜，いずれも各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）と、農学部（個別学力検査の成績のみでの選抜，各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）で実施されている。 == その他 == 工学部は学科ごとに入試で選考され、本人の希望と1年次の成績で2年進級時にコース分けされる。たとえば、機械・航空宇宙工学科は2年次から「機械システム工学・電子機械工学・航空宇宙工学」とコースが3つに分かれるが、中でも航空宇宙工学コースは人気があり例年定員以上の希望がある。 理学部は一括で選考され、2年進級時に学科配属となる。物理学科・化学科・生命理学科は例年人気が有り、定員オーバーとなることもある。この場合、一年時の取得単位状況による選考となる。 =脚注= <references/> == 関連リンク == *[http://www.nagoya-u.ac.jp/ 名古屋大学]：公式サイト [[Category:大学入試|なこやたいたいさく]] f1ccis4812pxquz3zyphonzdq69a3as 206117 206116 2022-08-01T08:14:51Z 106.154.143.149 /* 理系 */ wikitext text/x-wiki {{Wikipedia|名古屋大学}} * [[日本の大学受験ガイド]] > [[名古屋大対策]] 本項は、[[w:名古屋大学|名古屋大学]]の「一般入学試験」対策に関する事項である。 名古屋大学（名大）は、最後に設立された帝国大学である。大学入試標準レベル～やや難レベルの問題が中心の入試内容になっているので、受験生の勉強量の差が如実に現れる入試であると言える。標準レベルとは言うものの、誤魔化しや付け焼刃の勉強法では全く通用しない。解法パターンの丸暗記や小手先のテクニック等に頼った勉強ではなく、基本原理を押さえて理解することに重点を置いた対策が必要である。 大学入学共通テストの配点が工学部以外では圧縮されずに加算される(工学部は600点に圧縮。それでも高めだが…)ので、共通テストでも高い点数が求められる。 倍率は、年度によって変動もあるが、例年文系学部が2倍前後、理系学部が2～3倍程度である。近年倍率が上昇しており、特に文系で如実である。 == 英語（文理共通） == 外国語は、英語のみ（他の言語は全て選択不可）。 問題の出題数は４題で、2010年以降は、読解問題2題、会話文1題、英作文1題となっており、試験時間は105分である。 記述問題が中心で、その多くは字数制限が設けられている。 解答に時間のかかる設問が少なく、なかには標準的な問題も散見されるが、英語の読解力、表現力をはかる易問が多い。また標準的な自由英作文も出題されている。 第一問、第二問は論説文が中心で、文化・社会・教育・科学などの多岐にわたるテーマから出題される。前年発行の雑誌を出典とするなど、最新の話題を取り上げる傾向にあるようだ。 読解のレベルとしては、標準からやや難といったところである。 第三問は、問題が英文のみの会話文の問題が出題される。記号問題が多いが、英文で自分の意見や考えを述べる自由英作文が出された。 第四問は和文英訳で標準的な難度の出題である。やや訳すのが難しい日本語は、自分で簡単な日本語に置き換えて英文に訳すのが鉄則である。 対策としては、学校の授業、自習などを通して高い語彙力、読解力の養成をし、基本的な英文のパターンを頭に入れたうえで本番が近付いてくると、名古屋大学の過去問にも目を通すと良い。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。過去問と併せて名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりはこれまでやった過去問で読解をする上で必要となる単語や文法そして構文の整理に使った方が賢明である。毎年多かれ少なかれ傾向が変わるのが逆に名古屋大学の特徴ともいえるので、二次本番では解答開始時に昨年と比べて傾向がどう変わったのかを確認し、時間配分を考えつつ、解答作成に取り掛かるのを意識しておくとよい。 == 数学 == 本学は大学入試の数学では珍しく、文理共通で試験問題に付録として「数学公式集」が与えられる（持ち帰り可）。出題者の意図は不明確だが、解答作成において使用しても何ら支障は無い。ただこれが解答作成の上で役に立った事例は極めて稀だそうである。解答形式は、文理そして全題共通して計算の過程と解答を記入しなければならない論述式である。問題形式は同じく文理共通で、解答の際に配布されるB4の表紙付右開き冊子の中に試験問題・数学公式・答案紙（文科系3枚、理科系4枚）が入っている。このうち、提出は答案紙のみである。過去問は最低でも直近の3年分（駿台の青本が対応）はやっておいた方が好ましい。もう少し欲しいならば、直近の5年分（教学社の赤本が対応）でも良い(他科目そして共通テストとの折り合いを考えれば、分量としてはこれが限界かもしれない)。前記の過去問と、名大対応模試さらには公開模試の問題を併せてやるとなお良い。基本はこの分量で十分である。あまり無いと思うが、これらを完璧にやり終えてそれでも足りなければ、足していく形で良い。ただ、本番まで時間が残り少ないのであれば、足していくよりは公式を再確認やこれまでに扱った問題の答案作成の精度向上に使った方が賢明である。 === 文系 === 大問は3題で、難易度は易〜標準レベルであったが、それは過去の話で、2018年以降はかなり厳しい出題が続いており、標準より難しい～かなり難しい問題が並ぶ。また、2020年はなんと確率が出題されず、問題自体も過去最難レベルの問題であった。文系数学ではトップクラスの難しさであるため、点を取るにはかなりの実力が要求される。積分、ベクトル、図形と方程式、確率が頻出であり、特に高次関数の微積分、場合の数と確率漸化式の融合が多い。過去問を中心に傾向を把握し、対策することが有効と言える。 === 理系 === 試験時間は150分である。大問数は、例年4題である。難易度については2014年以降、かなりハイレベルな出題が続いており、問題全体は1990年代から2007年まで（解答時間が120分）に比べると難化しつつある。特に2011年度は過去10年で最難といえるほどに難化したが、2012年度以降も数学の難化傾向にあり、さらに2018年以降は完答出来るものが無いに等しいほどに凄まじい難度となっており、今後もこのレベルが名古屋大学として標準になると思われる。このようなことから、もはや1998年のような非常に易しい問題が4題で構成された時代（数学が非常に得意であれば、4題全完も可能であった）は終焉を迎えたと言っても過言ではない。2020年現在で、ここ10年の傾向としては1～2題は標準～やや難(名古屋大受験生を基準)、1～2題は難(完答できなくても合否にはほとんど影響はない)である。また、数年に1度の程度であるが、超難（言うまでもなく捨てても、合否にはほとんど影響はない）が1題出題されることも有る。前記の2題を見極めて、難レベルの1～2題（超難レベルの1題を含む）を後回しにできるかがカギとなる。 具体的な出題内容は、「微積分」「確率」は必ず1題ずつ出るといっても良いくらい頻出項目であり、「数列」「帰納法」も頻出である。また、「ベクトル」や「複素数」も良く出題されるが、すべての分野において基本レベルでは不十分で、特に微積、確率、数列、整数は相当の実力がなければ完答あるいは差をつけるのは難しい。どの分野の問題も4問150分であるからか非常に良く練られており、かなり重く難しい。予備校のテキストなどを1冊何度もやり込むことが対策となる。過去問も時間の許す限りできるだけ多くの年度の問題を解いておいてほしい。旧課程(2006年~2014年)のときは「整数問題」「行列」「微積分」「平面・空間幾何」「確率」が割合的に大半を占める。「数列」はこれらの分野に必ず融合させて出題される傾向が強い。2011年度入試第2問は「行列」「確率」「数列(確率漸化式)」の3分野を融合させた問題であった。 また、誘導が丁寧な問題が殆どであり、小問の考え方、計算過程や答えが最後の小問のヒントになっている場合が少なくない。ただし小問がヒントとしてあまり役に立たない問題(2002年度大問2など)も出題されているので注意すること。また、出題頻度は少ないが小問なしの問題も出題されている。これらの問題は教育的配慮からか難易度は標準的な問題が多いが、一部難問も存在する。 出題方式は、4題構成でうち大問4は2問から1問を選ぶ選択形式（4a,4b）で計4題を解答する形式であったが、2010年以降は選択問題(一時、1999年は選択形式が無かった)はなくなり、選択問題のない4題必須解答形式となっている。2020年までこの傾向が続いており、この形が続く可能性はある。とはいうものの、ある年突然に前述の選択形式が復活する可能性も否めない。この選択形式が出題された場合は、受験生の得意な問題を解答しても構わないが、試験中にどちらを解答するかを迷うのは良くない。この選択問題の難易度を見極められる選球眼を普段から鍛えておくことが重要で、そのためには好き嫌いや得手不得手な分野を作るのではなく、バランスよく対策しておくことが重要である。 試験時間150分に対して大問数4題と時間的な余裕が与えられている。問題の難易度は別として単純計算すると、1題あたりに与えられる平均時間は37.5分だが、これは全国の大学を見ても多い(参考に解答時間を比較的多く与えられている東京工業大学は、試験時間180分で36分/題)。解答時間は十分与えられているだけに、完成度の高い答案が求められるようになった、と言っても過言ではない。但し、それなりに難度も上がり、完答はむしろ難しくなった。対策としては、必ず出題される標準的な問題を確実に獲得した上で、難問に対しても要を得た解法やアプローチを示して部分点を1点でも多く狙うことが合格最大のポイントである。解答の過程も書くことが求められる、即ち解法や着眼点も評点の対象となるので、このような論述式の利点を活用することが大切である。また、前記のようにより完成度の高い答案が求められるだけに確実にわかる知識の範囲で答案作成すること、そして自身で作成した答案の過程はきちんと論理性があるかどうか（自身で読んで理解できないものは、他者が読むとさらに理解できない）、等と答案を作成した後に客観的に見直すことが重要となる。得点は標準レベルは満点確保、やや難で満点にできるだけ近い部分点を稼ぐ、難～超難レベルも少ないながらも部分点を獲得する(数学と言う科目の性質上、至難の業ではあるが…。)が理想である。以上のことから、日本で最も難しい数学の問題を出す大学である。 == 国語 == 文系・理系の区別なく共通の問題が出題される。2022年度現在、文系では文・教育・経済学部で、理系では理・医・農学部(現代文のみ／150点満点)で課されている。試験時間は理系（現代文のみ）では45分、文系では105分であるから現代文に45分、古・漢文に60分かけるのが標準的なのであろう。全体的に難易度は高めである。それぞれの分野が重厚さを持っているので本文を速読し、深く理解する力をつけることが重要となってくる。ちなみに2008年度は理学部・医学部医学科での国語導入のせいか特殊な出題があった。</br> '''現代文'''：例年、長い文章をテーマにしており、漢字の読み・書きなどから字数制限つきの説明問題など毎年6問程度での構成となっている。「抜き出せ」という問題は毎年出題されており、これと漢字に関する問題は説明問題の難易度を考えれば絶対に落とせない問題である。さて、その説明問題であるが毎年3～4問ほどあり、字数も60～100字程度の字数制限がつく。解答欄には与えられた字数＋10文字分のマス目が載せられている。難易度は高めであり日ごろからこのような形式の問題に慣れていなければ全問解答はまず不可能だろう。扱っている題材には抽象的な内容を含むものが多く、素材の文章自体が難易度を上げているためより難しめに感じるかもしれない。国語に充てる時間が短い理系には特に厳しい。2008年度は本文中の空欄に当てはまるように本文中の漢字2文字を抜き出させる本学としては特殊な問題が出題された。 '''古文'''：文章自体は少し長め。問題数は3つである。1問目は傍線部の口語訳で2、3問目は所定の解答欄に現代文で説明を書く問題である。本学の古典では、選択肢を選ぶ問題がないのが一般的であるため私立大学の古典に対する対策よりも論述性を重視した対策が必要になる。現代文と同様、簡潔に説明できる能力を平素の学習で養うことが望ましい。知識問題は出題されないが、それそのものが不要というわけではなく読解の助けになることもあるので平素の学習からさまざまな古文に触れていくことが大切。現代文と同様に難易度は高い。2008年度は例外的に選択肢を選ぶ問題と、本文とは別に与えられた文章の空欄補充問題があった。 '''漢文'''：共通テストよりも長めくらいの本文に対し6問程度が与えられる。1問目は読みを仮名で書く問題でありその他は全て説明問題となっている。特徴的なのは最後の150字説明問題であり、現・古・漢の中で最も重厚な問題であるといえる。古文同様、古典的知識は読解の助けになりうる。こちらも文章そのものの読みにくさから難易度は高い。2008年度は7問出題された。 == 小論文（法学部） == 法学部では国語の代わりに小論文が課される。大学入試小論文としては難易度はやや高い方である。試験時間は90分、解答字数は全問あわせて1000字程度である。課題文は、法学や政治学など社会科学系のテーマを取り上げた、比較的長めではあるが読みやすい文章が出題される。設問は、課題文の内容理解を問う問題（200字程度、1～2題）と、意見論述（600字～800字程度、1題）の形式で定着している。社会科学系志望者として最低限必要な法学・政治学関連の予備知識を、講座の演習などを通じて押さえおかなければならない。さらに、新聞やニュースなどを通して、現代社会のトピックに関する知識を養っておくとよい。 意見論述問題では、筆者の主張に対して自己の賛成・反対意見を論じる出題だけでなく、筆者の議論を踏まえて考察する問題など、幅広い出題が想定される。本文を丁寧に読解して端的に課題文の主張・論拠をまとめるとともに、自己の論拠を明確にして説得力のある主張を述べることを心がけたい。また、600～800字という論述字数は、日頃から演習を積んでおかないとまとめるのに苦労する。過去問演習を通してなるべく多くの年度の問題にあたり、学校や予備校の先生に添削してもらおう。また、名大法学部以外で似たような傾向の小論文として、[[慶應義塾大対策|慶應義塾大学法学部]]の論述力という科目がある。課題文は抽象的な用語が目立つ非常に難しいものであるが、社会科学的な予備知識に基づいて意見を論述するという意味で、設問の傾向は非常に似ているので、もし時間に余裕があるようであればぜひ挑戦してほしい。 以下も参考にしてほしい。 *[[大学受験小論文の勉強法]] == 理科 == 試験時間は、二科目でまとめて150分（情報学部自然情報学科では一科目で75分）である（二科目受験の場合は一科目ごとの時間配分は厳密に設けられておらず、一科目終了後の答案回収は行わない）。学部によっては、必須科目もあるので本学発行の受験案内等で事前に確認しておくことが好ましい。 === 物理（物理基礎/物理）=== 大問数は3題で構成される。1題は力学であり単振動や等加速運動など力学全般から幅広く出題される。ドップラー効果など波動との融合問題もある。また、惑星探査衛星など受験生にはあまり馴染みのない内容を取り上げる、思考力を要する問題が目立ってきている。電磁気も力学同様電磁気全般から幅広く出題される。また、難易度が不安定なのが名大物理の特徴であり、簡単な時は合格平均が6割を越えることもあるが、難化すると凄まじい難易度になり、合格者平均が3割を割りかねない程になる。 計算量は簡単な年はやや多いぐらいであるが、難しい年は完答不可能なレベルになるので、計算ミスに気を付けつつ、確実に取れる所を進めていこう。合格点としては近年なら医学部医学科は7割、その他学部は5割程度で十分だろう。(ただし難易度による) 2017年度までは、大問1は力学、大問2は電磁気、大問3は波動・熱力学で構成されていたが、2018年度では熱力学→電磁気→力学、2019年度では力学→熱力学→電磁気の順で出題された。この変更に対する意図は不明である。 力学は見慣れない設定での出題が多く、難易度も高いが、基本に忠実にこなしていけば、得点源となるだろう。 電磁気はコンデンサーや直流回路に関する問題が頻出である。こちらも誘導が丁寧なので落ち着いて解けば満点解答も可能だが、入試問題としてはやや難のレベルで出題されるので油断は禁物である。 波動・熱力学はどちらか一方の分野のみでの出題、両方を融合した出題が見受けられる。2010年度の大問3はこれらの分野を融合した問題であった(実際のところは熱力学の問題は1問のみで実質的に波動の問題。2014年の問題にはレンズの理解を深く問う問題が出題された。 かつては、（名大に合格する受験生のレベルならば）得点は満点からどれだけマイナスかで計算する、と言ったような難易度であったが、2013年頃から難易度は大幅に上昇している。例として2014年は凄まじく難化し、合格点が3割くらいまで落ちた。更に2020年は過去の名大どころか入試でも類を見ない程に難しく、ある情報では合格点が2割ちょっとであったらしい。今後もこの難度が名大物理として標準となる、と思われる。理系数学と同様、前記のような「満点からどれだけマイナスかで計算する」時代は終焉を迎えたと言っても過言ではない。また、2007年までは理科二科目(試験時間は計120分)受験必須の学部は大問2題(大問1は力学、大問2は電磁気の出題が基本)であり平均で30分/題だったが、2008年度からは上記のように基本は大問3題が出題されたことで平均で25分/題となり、1題の平均解答時間が短くなったことも難化の原因と言える。対策としては、典型的な問題を確実に解けるようにするだけでなく、教科書などを読み、公式などの原理を理解したうえで、過去問に取り組むのが望ましい。 但し、過去問を解き始める時は、時間内に終わらないので、はじめは90分を、目安に、その後、約70分で解くことが望ましい。 答案形式は、解答のみ記入する欄と計算の過程と解答の両方を記入する欄（一部では、論述をするための枠もあり）で構成される。解答のみ記入する部分は計算の過程が合っていても記載が間違っていれば、失点になる可能性になるが高いので、計算あるいは記載の間違いには特に気を付けることが必要である。また、前述のように難易度が不安定なので、物理で差をつけようとするのはあまり得策ではない。(勿論人によるが…。)なので、普通の年の難易度なら合格点を取れるレベルなら、他の教科を安定させた方が良いかもしれない。 以上から、易しい年なら高得点が狙えるが、難化した年は全入試でも最難レベルの問題を出す大学である。 === 化学（化学基礎/化学）=== 共通テストの選択肢を隠して記述として問題を解けば名大化学の対策にも通じるといえる。理論・無機・有機・高分子とすべての分野の基本事項はできるようにしておきたい。その上で私たちの日常生活にどのように活用されているかなどを考えると良いだろう。 近年は、理論・無機で大問3つ、有機で大問1つずつの合計5問で構成されている。 理論は気圧計算が頻出であり、近年は結晶構造や熱化学などもよく出題されている。基本的事項のみで解ける問題は多いがやや難度の高い問題も出題されている。とは言ってもマニアックな知識が必要とされる問題は出題されないので標準レベルの重要事項をどれだけモノにできるかが大切であろう。計算は簡単なものから計算力を要するものまであるため、日ごろからモル計算や気圧計算などに親しんでおくことも大切。 無機は基本事項をどれだけ押さえられたかが肝である。細かな部分も多少は覚えておくことが望ましい。 有機（化学）は構造決定が頻出であり、それのみで大問が構成されていた年度もある。基本的知識の組み合わせのみで解ける問題が多いが普段から構造決定に慣れておかなければ手間取ってしまうこともあるので日々の練習で的確かつ素早く構造決定できるようにしておきたい。それ以外の基本も押さえておくこと。油脂もよく出題されている。高分子を絡めた出題があるので注意。さらに糖類・アミノ酸(タンパク質)・高分子化合物をテーマにして出題してくるが生物選択者が多少有利な小問があったりする。それでも基本的な事柄を問うていることがほとんどであるからこの大問で点数を落とすことは避けたい。 == 模試 == 本大対応模試として、[[w:河合塾|河合塾]]の名大入試オープン（年に2回開催されるが、第2回の成績を重視されたい）、[[w:代々木ゼミナール|SAPIX YOZEMI GROUP]]の名大入試プレ<ref>理科では「地学基礎・地学」、地理歴史では「地理B」の試験は実施しない。</ref>（2020年度は、9月に実施）、[[w:駿台予備校|駿台]]の名大入試実戦模試<ref>答案は2021年実施分よりWeb返却（駿台のマイページにPDF形式で掲載。掲載期間は、Web公開開始日から3ヶ月間。）のみとなり、紙の答案による返却は廃止となった。</ref>、[[w:東進予備校|東進]]の本番レベル模試（2020年度は、年に3回開催）がある（判定は、いずれも前期日程のみ）。各予備校は、大学の傾向を徹底的にチェックして大学別の予想問題を作成しているので、受験すれば、本番の入試に向けて大きな指針となり、本番の雰囲気に慣れることにもなる。また過去問だけでも物足りなさを感じるのであれば、河合出版からの過去の名大入試オープンを5回分収録した問題集「入試攻略問題集　名古屋大学」（英語・数学）が市販されているため、時間があれば取り組んでみるのもよい。 年によっては、名古屋大学（東山キャンパス）内に受験会場が設置されることがある。本学を志願する受験生にとっては、受験会場の雰囲気に慣れることや受験会場の下見も兼ねることにもなることで、良い機会となる。 加えて、主に高1・2生が対象になるが、2021年度は東進で「名大入試同日体験受験」(2月25日・26日)という模試が開催される。これは同年の前期日程入試本番に出題された問題を同日に同解答時間・同スケジュール(但し、試験開始と終了時刻は異なる)で解くというものである。試験開始と終了の時刻は違えど、前期日程入試と同じスケジュールで試験を受けることができる（医学部医学科の面接試験は実施せず）。模擬試験とは違った本番ならではの感覚を味わうまたとない機会と言えるので、本学を希望するならば受験しておくと良いかもしれない。 == 二段階選抜 == 後期日程（医学部医学科のみ）で定員5名に対して志願倍率が12倍（志願者数60名）を超えた場合、実施される。選考方法は大学入学共通テスト成績に基づき、高得点順に上位60名を合格者する。<br> 令和4年度以降は医学部医学科の前期日程・後期日程の受験者に対して、それぞれ大学入学共通テストの成績が 900 点満点中 700 点以上の者が、第1段階の合格者となる。 == 面接試験 == '''医学部医学科のみ'''実施される。実施内容は、以下である。*2020年度実施分よりインターネット出願が導入され、紙媒体の募集要項の配布はなくなったので、志願理由書は名古屋大学の公式ホームページよりダウンロード(PDF文書)してプリントアウトして記入する必要がある。2020年度以降の受験者は、インターネット環境を整えておくことはおろか、プリンターを用意することが好ましい。 '''前期日程'''</br> 筆記試験（2/25・26）終了後の翌27日、本大学受験者全員に対して課される。前期日程試験は、筆記試験(2日間がけ)+面接試験(1日完結)の3日間である。注意点として、筆記試験と面接試験は実施されるキャンパスが異なることである。筆記試験は東山キャンパス（名古屋大学本部）で、面接試験は鶴舞キャンパス(名大病院・医学部医学科専用キャンパス)で実施されるので、試験会場をくれぐれも間違えないように注意すること。 '''後期日程'''</br> 3/12の1日間で実施。後期日程試験は、この面接試験のみである（筆記試験は実施せず）。面接試験は鶴舞キャンパスで実施される。 == 高得点者選抜 == この大学の特徴として、国立大学でありながら私立によく見られる「高得点者選抜」がある。これは大学入学共通テストの成績のみ、あるいは個別学力検査の成績のみで評価されるものだが、どちらの方法であっても高い得点力が要求される。確約は出来ないが、大学入学共通テストは9割あるいは9割5分あればほぼ安全圏、そして個別学力検査は最低でも7割5分～8割程度（但し、2020年度時点での直近10年の試験問題の難度からすると、これもかなり至難の業）あれば可能圏内と思われる。令和3年度は工学部（大学入学共通テストの成績のみで選抜／個別学力検査の成績のみで選抜，いずれも各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）と、農学部（個別学力検査の成績のみでの選抜，各学科の前期日程募集人員の10％を限度そして第一志望の学科に限る）で実施されている。 == その他 == 工学部は学科ごとに入試で選考され、本人の希望と1年次の成績で2年進級時にコース分けされる。たとえば、機械・航空宇宙工学科は2年次から「機械システム工学・電子機械工学・航空宇宙工学」とコースが3つに分かれるが、中でも航空宇宙工学コースは人気があり例年定員以上の希望がある。 理学部は一括で選考され、2年進級時に学科配属となる。物理学科・化学科・生命理学科は例年人気が有り、定員オーバーとなることもある。この場合、一年時の取得単位状況による選考となる。 =脚注= <references/> == 関連リンク == *[http://www.nagoya-u.ac.jp/ 名古屋大学]：公式サイト [[Category:大学入試|なこやたいたいさく]] 9d7g9568l0mefh03i8x7hm7m3ymcq0n 0 5792 206067 203265 2022-08-01T00:19:25Z Ef3 694 文体 wikitext text/x-wiki {{Wikipedia|Java}} [[情報技術]] > [[Java]] > Javaクイックツアー Javaは、"'''Write once, run anywhere'''" ('''WORA'''、「一度（プログラムを）書けば、どこでも実行できる」)を謳い文句に登場しました。Javaで書かれたプログラムは、従来のプログラムとは違い、一度書けば、どんな[[w:オペレーティングシステム|OS(オペレーティングシステム)]]や[[w:CPU|CPU]]の上でも動かすことができる「[[w:クロスプラットフォーム|プラットフォーム非依存]]」という特徴を持っています。まずは、そのJavaの特徴について説明します。 == Javaの特徴 == Javaはその優れた「プラットフォーム非依存性」によって、[[w:Microsoft Windows|Windows]]、[[w:Macintosh|Macintosh]]、[[w:UNIX|Unix]]、[[w:Linux|Linux]]、どのプラットホームでも、[[w:コンパイラ|コンパイル]]することなくプログラムを動作させることができます。また、従来のC言語やC++言語でしばしば見られた、10年前に購入したソフトウェアが動作しないといった問題も解決しています。これらの特徴に加え、Javaは[[w:ネットワーク|ネットワーク]]との親和性にも優れています。Javaは最初からネットワークを意識した言語なのです。Javaという技術は、もともと[[w:家電製品|家電製品]]を制御するために作られたものです。そのためには、ネットワークとの親和性が高く、どの家電製品でも同じようにJavaのプログラムが動作する「プラットフォーム非依存型」であることが必要でした。そのため、Javaはパーソナル コンピューやだけでなく、サーバーや携帯端末でも動作するようになりました。 == C/C++言語との違い == {{Wikipedia|JavaとC++の比較}} Javaはネットワークとの親和性が強いことから、[[w:Javaコンパイラ|Javaコンパイラ]]には厳しい[[w:セキュリティ|セキュリティ]]チェックがかかっており、そう簡単には危険なプログラムを作ることができないようになっています。 Javaにある多くの機能が、C/C++からの影響を受けています。そのため、Javaは文法がC/C++に非常に似ています。しかし、それと同時に、C/C++では危険とされる様々なものを除去し、欠点を改良してJavaが開発されました。 === ポインタ === {{Wikipedia|ポインタ (プログラミング)|ポインタ}} Javaには[[C言語|C言語]]や[[CPlusPlus|C++]]にある[[w:ポインタ|ポインタ]]と類似する機能はあるものの、C言語やC++のように、ポインタを使ってメモリ上の特定の番地にアクセスしてシステムを破壊するという危険なことが起きないようになっています。よく「Javaにはポインタがない」と誤解されることがありますが、実際にはあります。しかし、C言語やC++言語のように、危険な「ポインタ演算」を行うことはできなくなりました。これにより、Javaでは、C言語やC++言語よりもより安全にプログラミングをすることが可能になりました。Javaを開発した[[w:サン・マイクロシステムズ|Sun Microsystems]]は、「Javaにはポインタがない」を宣伝文句にしていることがありましたが、これは誤解を招く表現であり、実際には、むしろJavaはポインタだらけです。しかし、C言語やC++言語のような頭を悩ます危険な問題はおきにくくなっています。つまり、「Javaにはポインタはあるけれども'''ポインタ演算'''はない」という表現が正確です。 === 配列 === {{Wikipedia|配列}} C言語やC++言語ではJava同様[[w:配列|配列]]というものがあります。C言語やC++言語ではこの配列を使って危険なことができてしまいました。JavaもC言語やC++言語も配列を宣言するとき、長さを指定します。しかしC言語やC++言語では、長さを指定しても、その配列の長さを超える領域にアクセスすることも可能でした。Javaでは、配列の領域外にアクセスすると[[w:例外処理|例外処理]]機構が働いて、事前にどこで問題が起きたのかを知らせてくれます。しかし、C言語やC++言語では知らせてくれません。そのためにどこでプログラムに問題がおきたのかを通知することができないという問題がありました。そのために、C言語やC++言語では、システムを破壊に追いやる[[w:バッファオーバーラン|バッファオーバーフロー]](buffer overflow)という深刻な問題をもたらしました。C言語やC++言語では、メモリ空間全体を非常に長い巨大な配列として見なしているのです。その巨大な配列をポインタと見なして[[w:メモリリーク|メモリリーク]]を引き起こすことも可能になる危険なメモリアクセスを可能にしています。Javaではこのようなことはなく、配列の添え字には負の値を使うことができず、宣言したサイズ内でしかアクセスできないようになっています。つまり、Javaは不用意に外部のリソースにアクセスできないようになっているのです。 === オート ガベージコレクション === {{Wikipedia|ガベージコレクション}} Javaはさらに、メモリ管理も容易になりました。オート[[w:ガベージコレクション|ガベージコレクション]]によって、オブジェクト生成時に確保したメモリ領域は、そのオブジェクトが不必要になったとき、自動的に開放してくれるという優れた特徴があります。C言語やC++言語ではmalloc()やnewで確保したメモリはfree()やdelete()で明示的に解放しなければなりませんでした。これは、いつどこで、メモリを解放すべきかを、自分で決めなければならないという負担がありました。そのためにC言語やC++ではこのメモリ解放を怠ることで、システムを破壊する[[w:メモリリーク|メモリリーク]]という惨事を引き起こす危険もありました。Javaでは、この[[w:ガベージコレクション|ガベージコレクション]]が自動的に破棄されたメモリ領域を、その名の通り、ゴミ収集車のように自動的に回収してくれます。そのために、メモリをいつ解放するかを意識せず、効率よくプログラミングすることができます。これは、自動車にたとえると、[[w:マニュアルトランスミッション|マニュアル車]]が[[w:オートマチックトランスミッション|オートマ車]]に変わってしまうほど効率的な進化を遂げているということです。 == 廃止された技術 == かつて、webブラウザなどと連動してJavaを使える「Javaアプレット」という技術がありましたが、現在<ref>Java11時点</ref>では廃止されています。 Java 9 の時点で既にJavaアプレットは非推奨になっています。 webブラウザの動的な制御のプログラミングは、現在および今後は HTML5 と JavaScript で行う必要があります。 {{Stub}} 8wpuql5o6oakh63l8am6rlhfvb75xel 0 6151 206051 206042 2022-07-31T12:18:25Z Linguae 449 /* 14節 */ wikitext text/x-wiki [[Category:ガリア戦記|3]] [[ガリア戦記]]＞&nbsp;'''第3巻'''&nbsp;＞[[ガリア戦記 第3巻/注解|注解]] <div style="text-align:center"> <span style="font-size:20px; font-weight:bold; font-variant-caps: petite-caps; color:white; background: rgb(47,94,255);background: linear-gradient(180deg, rgba(47,94,255,1) 0%, rgba(24,56,255,1) 50%, rgba(0,8,255,1) 100%);">&nbsp;C&nbsp;IVLII&nbsp;CAESARIS&nbsp;COMMENTARIORVM&nbsp;BELLI&nbsp;GALLICI&nbsp;</span> <span style="font-size:40px; font-weight:bold; color:white; background: rgb(47,94,255);background: linear-gradient(180deg, rgba(47,94,255,1) 0%, rgba(24,56,255,1) 50%, rgba(0,8,255,1) 100%);">&nbsp;LIBER TERTIVS&nbsp;</span> </div> [[画像:Gaule -56.png|thumb|right|150px|ガリア戦記 第3巻の情勢図（BC56年）。<br>黄色の領域がローマ領。桃色が同盟部族領。]] {| id="toc" style="align:left;clear:all;" align="left" cellpadding="5" ! style="background:#ccccff; text-align:left;" colspan="2" | ガリア戦記 第3巻 目次 |- | style="text-align:right; font-size: 0.86em;"| '''[[#アルプス・オクトードゥールスの戦い|アルプス・オクトードゥールスの戦い]]''':<br /> '''[[#大西洋岸ウェネティー族の造反|大西洋岸ウェネティー族の造反]]''':<br /> <br /> '''[[#大西洋岸ウネッリ族の造反|大西洋岸ウネッリ族の造反]]''':<br /> '''[[#クラッススのアクィタニア遠征|クラッススのアクィタニア遠征]]''':<br /> <br /> '''[[#モリニ族・メナピイ族への遠征|モリニ族・メナピイ族への遠征]]''':<br /> | style="text-align:left; font-size: 0.86em;"| [[#1節|01節]] | [[#2節|02節]] | [[#3節|03節]] | [[#4節|04節]] | [[#5節|05節]] | [[#6節|06節]] <br /> [[#7節|07節]] | [[#8節|08節]] | [[#9節|09節]] | [[#10節|10節]] <br /> [[#11節|11節]] | [[#12節|12節]] | [[#13節|13節]] | [[#14節|14節]] | [[#15節|15節]] | [[#16節|16節]] <br /> [[#17節|17節]] | [[#18節|18節]] | [[#19節|19節]] <br /> [[#20節|20節]] <br /> [[#21節|21節]] | [[#22節|22節]] | [[#23節|23節]] | [[#24節|24節]] | [[#25節|25節]] | [[#26節|26節]] | [[#27節|27節]] <br /> [[#28節|28節]] | [[#29節|29節]] |} <br style="clear:both;" /> __notoc__ ==<span style="color:#009900;">はじめに</span>== :<div style="color:#009900;width:85%;">前巻（[[ガリア戦記 第2巻|ガリア戦記 第2巻]]）の終わりで述べられたように、カエサルによってガッリアはほぼ平定されたと思われて、首都ローマで感謝祭が催されたほどであった。このため、本巻（第3巻）ではカエサル自身の遠征として記す内容はとても少ない。<br><br>本巻の[[#1節]]～[[#6節]]で言及される[[#アルプス・オクトードゥールスの戦い]]は、[[w:紀元前57年|BC57年]]秋頃に起こったと考えられるので、本来なら第2巻に含められるべきであるが、そうなると第3巻が20節ほどの非常に短い巻になってしまうので、第3巻の冒頭に置いたとも考えられる。<br><br>本巻（第3巻）の年（[[w:紀元前56年|BC56年]]）の春には、ガッリア遠征の遂行上きわめて重要な'''ルカ会談'''があったので、以下に補足する。</div> <div style="background-color:#eee;width:75%;"> ===コラム「ルカ会談」=== :::<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Luca Conference|Luca Conference]]''</span>（英語記事）などを参照。 :<span style="color:#009900;">伝記作家[[ガリア戦記/注解編#プルータルコス『対比列伝』|プルータルコス]]によれば<ref>[[ガリア戦記/注解編#プルータルコス『対比列伝』|プルータルコス『対比列伝』]]の「カエサル」20,21</ref>、カエサルはベルガエ人との戦いを成し遂げると、前年に続いて'''パドゥス川'''〔[[w:la:Padus|Padus]] [[w:ポー川|ポー川]]〕流域で越冬しながら、ローマ政界への政治工作を続けた。例えば、カエサルを後援者とする選挙の立候補者たちが有権者を買収するための金銭をばらまいていた。ガッリア人捕虜を奴隷商人に売り払って得た莫大な金銭で。その結果、カエサルの金銭で当選した者たちの尽力で、属州総督カエサルへの新たな資金の支給が可決されるという具合であった。<br><br>そのうち、多くの名門貴族たちがカエサルに面会するために[[w:ルッカ|ルカ]]（[[w:la:Luca|Luca]]）の街へやって来た。<br>こうした中、[[w:紀元前56年|BC56年]]の4月に、カエサルと非公式の盟約（[[w:三頭政治#第一回三頭政治|三頭政治]]）を結んでいた[[w:マルクス・リキニウス・クラッスス|クラッスス]]と[[w:グナエウス・ポンペイウス|ポンペイウス]]もルカを訪れて、三者による会談が行われた。<br><br>首都ローマでは、三頭政治を後ろ盾とする[[w:ポプラレス|平民派]]の[[w:プブリウス・クロディウス・プルケル|クロディウス]]（<span style="font-family:Times New Roman;">[[w:la:Publius Clodius Pulcher|Publius Clodius Pulcher]]</span>）が民衆に暴動をけしかけ、[[w:オプティマテス|門閥派]]のミロ（<span style="font-family:Times New Roman;">[[w:la:Titus Annius Milo|Titus Annius Milo]]</span>）と激しく抗争するなど、騒然としていた。このクロディウスの暴力的な手法は、クラッススとポンペイウスの関係を傷つけた。また、カエサルのガッリアでの輝かしい勝利に、二人とも不満を感じていた。このように三頭政治は綻び出していたのだ。<br><br>三人は三頭政治を延長することで合意した。カエサルは、クラッススとポンペイウスが翌年（[[w:紀元前55年|BC55年]]）の執政官に立候補すること、3属州の総督であるカエサルの任期がさらに5年間延長されること、などを求めた。<br><br>会談の結果、任期が大幅に延長されたカエサルの野望は、ガッリアに止まらず、[[w:ゲルマニア|ゲルマーニア]]や[[w:ブリタンニア|ブリタンニア]]の征服へと向かっていく。一方、再び執政官になった二人は、[[w:パルティア|パルティア]]を攻略するためにクラッススがシリア総督になることを決めるが、これはクラッススの命運とともに三頭政治の瓦解、カエサルとポンペイウスの関係悪化を招来することになる。 </span> <div style="text-align:center"> {| |- |[[画像:First Triumvirate of Caesar, Crassius and Pompey.jpg|thumb|right|500px|後に[[w:三頭政治#第一回三頭政治|三頭政治]]（<span style="font-family:Times New Roman;">[[w:la:Triumviratus|Triumviratus]]</span>）と呼ばれることになる非公式な盟約を結んでいた、左から[[w:ガイウス・ユリウス・カエサル|カエサル]]、[[w:マルクス・リキニウス・クラッスス|クラッスス]]、[[w:グナエウス・ポンペイウス|ポンペイウス]]。<br>3人は、第3巻の戦いが始まる前に、ルカ会談で三頭政治の延長を決めた。]] |} </div> </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ==アルプス・オクトードゥールスの戦い== :<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Battle of Octodurus|Battle of Octodurus]]''</span>（英語記事）<span style="font-family:Times New Roman;font-size:13pt;">''[[w:fr:Bataille d'Octodure|Bataille d'Octodure]]''</span>（仏語記事）などを参照。 ===1節=== [[画像:Historische Karte CH Rome 1.png|thumb|right|300px|現在の[[w:スイス|スイス]]の帝制ローマ時代の地図。左下の三日月形の[[w:レマン湖|レマン湖]]の下方に、<span style="font-family:Times New Roman;">ALLOBROGES, NANTUATES, VERAGRI, SEDUNI</span> の部族名が見える。]] [[画像:Afdaling vd San Bernardino - panoramio.jpg|thumb|right|300px|現在の[[w:グラン・サン・ベルナール峠|グラン・サン・ベルナール峠]]。ラテン語では <span style="font-family:Times New Roman;">[[w:la:Porta Magni Sancti Bernardi|Porta Magni Sancti Bernardi]] という。<br>スイスを縦断する[[w:欧州自動車道路|欧州自動車道路]] [[w:en:European route E27|E27]] が[[w:レマン湖|レマン湖]]からこの峠を通ってイタリアの[[w:アオスタ|アオスタ]]へ至る。</span>]] *<span style="background-color:#ffd;">[[/注解/1節]]　{{進捗|00%|2022-04-23}}</span> '''ガルバとローマ第12軍団が、ロダヌス川渓谷のオクトードゥールスにて冬営する''' <br> ;　　　カエサルが、ガルバと軍団・騎兵をアルプス地方へ派兵 *Cum in Italiam proficisceretur Caesar, **カエサルは、イタリア〔[[w:ガリア・キサルピナ|ガッリア・キサルピーナ]]〕に出発していたときに、 *[[wikt:en:Servium|Servium]] Galbam cum [[w:en:Legio XII Fulminata|legione duodecima(XII.)]] et parte equitatus **[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|セルウィウス・ガルバ]]を第12軍団および騎兵隊の一部とともに、 *in [[wikt:fr:Nantuates#Latin|Nantuates]], [[wikt:en:Veragri#Latin|Veragros]] Sedunosque misit, **ナントゥアーテース族・ウェラーグリー族・セドゥーニー族（の領土）に派遣した。 *qui a finibus [[wikt:en:Allobroges#Latin|Allobrogum]] et lacu [[wikt:fr:Lemannus|Lemanno]] et flumine [[wikt:en:Rhodanus#Latin|Rhodano]] ad summas [[wikt:en:Alpes#Latin|Alpes]] pertinent. **彼らはアッロブロゲース族の領土、レマンヌス湖〔[[w:レマン湖|レマン湖]]〕およびロダヌス川〔[[w:ローヌ川|ローヌ川]]〕から[[w:アルプス山脈|アルプス]]の頂きに及んでいる。 *Causa mittendi fuit, **派遣の理由は（以下のこと）であった： *quod iter per Alpes, **アルプスを通る道は、 *quo magno cum periculo magnisque cum [[wikt:en:portorium|portoriis]] mercatores ire consuerant, **大きな危険と多額の関税を伴って商人たちが旅することが常であったので、 *patefieri volebat. **（カエサルは道が）開かれることを望んでいたのだ。 **:<span style="color:#009900;">（訳注：現在の[[w:グラン・サン・ベルナール峠|グラン・サン・ベルナール峠]]を通ってスイスとイタリアを結ぶ道のことで、<br>　　　　帝制初期に[[w:アウグストゥス|アウグストゥス]]によって街道が敷設された。<br>　　　　かつて[[w:ハンニバル|ハンニバル]]が越えたのは諸説あるが、この道であった可能性もある。<br>　　　　ローマ人がこの地に移入・育成した軍用犬は現在の[[w:セント・バーナード|セント・バーナード犬]]。）</span> *Huic permisit, si opus esse arbitraretur, uti in his locis legionem hiemandi causa conlocaret. **彼〔ガルバ〕に、もし必要と思われるならば、この地に軍団を[[w:冬営|冬営]]するために宿営させることを許可した。 [[画像:Servius Sulpicius Galba.jpg|thumb|right|300px|[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|セルウィウス・スルピキウス・ガルバ]]の横顔が刻まれた貨幣。ガルバは[[w:紀元前54年|BC54年]]（[[ガリア戦記 第5巻|ガリア戦記 第5巻]]の年）に[[w:プラエトル|法務官]]に任官。内戦期もカエサルに従うが、暗殺計画に参画する。<br>[[w:ネロ|ネロ帝]]とともにユリウス家の王朝が途絶えると、ガルバの曽孫が[[w:ローマ内戦_(68年-70年)#四皇帝|四皇帝]]の一人目の[[w:ガルバ|ガルバ帝]]となった。このため[[w:ガイウス・スエトニウス・トランクィッルス|スエートーニウス]]『ローマ皇帝伝』の「ガルバ伝」にガルバへの言及がある<ref>[[s:la:De_vita_Caesarum_libri_VIII/Vita_Galbae#III.]]</ref>。]] <br> ;　　　ガルバが、諸部族を攻略して、軍団の冬営を決める *Galba, secundis aliquot proeliis factis **ガルバは、いくつかの優勢な戦いをして、 *castellisque compluribus eorum expugnatis, **彼ら〔ガッリア諸部族〕の多くの砦が攻略されると、 *missis ad eum undique legatis **彼〔ガルバ〕のもとへ四方八方から（諸部族の）使節たちが遣わされ、 *obsidibusque datis et pace facta, **人質が供出されて、講和がなされたので、 *constituit **（ガルバは、以下のことを）決めた。 *cohortes duas in Nantuatibus conlocare **2個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>をナントゥアーテース族（の領土）に宿営させること、 *et ipse cum reliquis eius legionis cohortibus **（ガルバ）自身はその軍団の残りの<ruby><rb>歩兵大隊</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>とともに、 *in vico Veragrorum, qui appellatur [[wikt:en:Octodurus|Octodurus]], hiemare; **オクトードゥールスと呼ばれているウェラーグリー族の村に冬営することを。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：オクトードゥールス（[[wikt:en:Octodurus|Octodurus]]）は現在の[[w:マルティニー|マルティニー市]]。）</span> <br> ;　　　ウェラーグリー族のオクトードゥールス村 *qui vicus positus in valle, non magna adiecta planitie, **その村は、さほど大きくない平地に付随した渓谷の中に位置し、 *altissimis montibus undique continetur. **とても高い山々で四方八方を囲まれている。 *Cum hic in duas partes flumine divideretur, **これ〔村〕は川によって二つの部分に分け隔てられているので、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：現在の[[w:マルティニー|マルティニー]]の街中を、[[w:ローヌ川|ローヌ川]]の支流であるドランス川（''[[w:en:Drance|Drance]]）が貫流している。）</span> *alteram partem eius vici Gallis [ad hiemandum] concessit, **その村の一方の部分をガッリア人に [越冬するために] 譲った。 *alteram vacuam ab his relictam cohortibus attribuit. **もう一方の彼ら〔ガッリア人〕により空にされた方を、残りの<ruby><rb>歩兵大隊</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>に割り当てた。 *Eum locum vallo fossaque munivit. **その地を堡塁と塹壕で守りを固めた。 <div style="text-align:center"> {| |- |[[画像:Martigny_1600.jpg|thumb|right|600px|かつてウェラーグリー族のオクトードゥールス村（[[w:la:Octodurus|Octodurus]]）があった所は、現在では[[w:スイス|スイス]]の[[w:マルティニー|マルティニー]]（[[w:en:Martigny|Martigny]]）市となっている。[[w:ローヌ川|ローヌ川]]が屈曲して流れる[[w:谷|渓谷]]地帯にある。]] |} </div> <div style="background-color:#eee;width:77%;"> ===コラム「ガルバの派遣とカティリーナ事件」=== :::関連記事：<span style="font-family:Times New Roman;font-size:13pt;">[[w:la:Catilinae coniuratio|Catilinae coniuratio]], ''[[w:en:Second Catilinarian conspiracy|Second Catilinarian conspiracy]]''</span> :<span style="color:#009900;">　[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|セルウィウス・スルピキウス・'''ガルバ''']]にアルプス派兵を指揮させた理由について、カエサルは記していない。<br><br>　[[w:紀元前63年|BC63年]]～[[w:紀元前62年|BC62年]]に、ローマの高官だった[[w:ルキウス・セルギウス・カティリナ|ルーキウス・セルギウス・'''カティリーナ''']]（[[w:la:Lucius Sergius Catilina|Lucius Sergius Catilina]]）がクーデタを企てるという大事件があった。'''[[w:マルクス・トゥッリウス・キケロ|キケロー]]'''が『[[w:カティリナ弾劾演説|カティリナ弾劾演説]]』で糾弾し、カエサルが事件の黒幕ではないかと取り沙汰された(スエートニウス<ref>[[s:la:De_vita_Caesarum_libri_VIII/Vita_divi_Iuli#XIV.]]， [[s:la:De_vita_Caesarum_libri_VIII/Vita_divi_Iuli#XVII.|#XVII.]] を参照。</ref>)。<br>　BC63年の[[w:プラエトル|法務官]][[w:ガイウス・ポンプティヌス|ガーイウス・'''ポンプティーヌス''']]がキケローを助けて事件を捜査し、アッロブロゲース族からカティリーナへ宛てた手紙を調べた。BC62年にポンプティーヌスは前法務官としてガッリア総督となり、事件に関与していたアッロブロゲース族を平定した。このとき、[[w:トリブヌス|副官]]としてポンプティーヌスを助けてアッロブロゲース族を攻めたのが'''ガルバ'''であった。総督がカエサルに替わっても、ガルバは副官として留任し、アッロブロゲース族の近隣部族の鎮定に努めていたわけである。<br>　ポンプティーヌスは、一部の元老院議員の反対で、戦勝将軍の権利である[[w:凱旋式|凱旋式]]ができなかった。これを不満に思っていたガルバは、[[w:紀元前54年|BC54年]]に法務官になると尽力して、その年にポンプティーヌスの凱旋式を行なうことに成功した。 <div style="text-align:center"> {| |- |[[画像:Joseph-Marie Vien - The Oath of Catiline.jpg|thumb|right|320px|'''カティリーナの誓い'''（''Le Serment de Catiline''）<br>[[w:ジョゼフ＝マリー・ヴィアン|ジョゼフ＝マリー・ヴィアン]]画(1809年)。<hr>カティリーナと共謀者たちは、人間の血を混ぜたワインを飲んで誓いを立てる儀式を行なったと伝えられている。]] |[[画像:The Discovery of the Body of Catiline.jpg|thumb|right|320px|'''カティリーナの遺骸の発見'''<br>（''Il ritrovamento del corpo di Catilina''）<br>''[[w:en:Alcide Segoni|Alcide Segoni]]'' 画(1871年)<hr>アッロブロゲース族のいるガッリアへ向かおうとしていたカティリーナは、[[w:ピストイア|ピストリア]]（[[w:la:Pistorium|Pistoria]]）の戦い（''[[w:en:Battle of Pistoia|Battle of Pistoia]]''）で戦死した。]] |} </div> </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===2節=== *<span style="background-color:#ffd;">[[/注解/2節]]　{{進捗|00%|2022-05-05}}</span> '''ガッリア人が再び挙兵して周囲の高峰を押さえ、第12軍団の冬営地を包囲''' *Cum dies hibernorum complures transissent frumentumque eo comportari iussisset, **冬営の多くの日々が過ぎ去って、穀物がそこに運び集められることを（[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|ガルバ]]が）命じていたときに、 *subito per exploratores certior factus est **突然に（以下のことが）[[w:偵察|偵察隊]]により報告された。 *ex ea parte vici, quam Gallis concesserat, omnes noctu discessisse **ガッリア人たちに譲っていた村の一部から、皆が夜に立ち退いており、 *montesque, qui [[wikt:en:impendeo#Latin|impenderent]], a maxima multitudine Sedunorum et [[wikt:en:Veragri|Veragrorum]] teneri. **そそり立つ山々がセドゥーニー族とウェラーグリー族のかなりの大勢により占拠されたのだ。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：ウェラーグリー族は既述のようにオクトードゥールス村 [[w:la:Octodurus|Octodurus]]〔現在の[[w:マルティニー|マルティニー市]]〕を、<br>セドゥーニー族 [[w:la:Seduni|Seduni]] はより上流のセドゥヌム [[w:la:Sedunum|Sedunum]]〔現在の[[w:シオン (スイス)|シオン市]]〕を首邑としていた。）</span> *Id aliquot de causis acciderat, **いくつかの理由から、起こっていたことには、 *ut subito Galli belli renovandi legionisque opprimendae consilium caperent: **突如としてガッリア人が、戦争を再開して（ローマ人の）軍団を急襲する作戦計画を立てたのだ。 <br> ;　　　　第1の理由：ガルバの第12軍団は、兵が割かれていて寡勢である *primum, quod legionem neque eam plenissimam detractis cohortibus duabus **というのも、第一に、総員がそろっていない軍団を&nbsp;──2個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>が引き抜かれていて、 **:<span style="color:#009900;">（訳注：前節で既述のように、2個歩兵大隊をナントゥアーテース族のところに宿営させていたが、これはレマンヌス湖〔[[w:レマン湖|レマン湖]]〕に近いより下流の地域で、離れていたようだ。）</span> *et compluribus singillatim, qui commeatus petendi causa missi erant, absentibus, **多くの者たちが一人ずつ、糧食を求めるために派遣されていて不在である、── *propter paucitatem despiciebant; **（その第12軍団を）少数であるゆえに、見下していたからだ。 <br> ;　　　　第2の理由：渓谷にいるローマ人は、山から攻め降りて来るガッリア人の飛道具を受け止められまい *tum etiam, quod propter iniquitatem loci, **それからさらに（ローマ勢が冬営している渓谷の）地の利の無さゆえ、 *cum ipsi ex montibus in vallem decurrerent et tela conicerent, **（ガッリア勢）自身が山々から谷間に駆け下りて飛道具を投じたときに、 *ne primum quidem impetum suum posse sustineri existimabant. **自分たちの最初の襲撃を（ローマ勢が）持ちこたえることができない、と判断していたので。 <br> ;　　　　第3の理由：人質を取られて、属州に併合される前にローマ人を討て *Accedebat, quod suos ab se liberos abstractos obsidum nomine dolebant, **加えて、人質の名目で自分たちから引き離されている自分の子供たちのことを嘆き悲しんでいたので、 *et Romanos non solum itinerum causa, sed etiam perpetuae possessionis **かつ、ローマ人たちは道（の開通）のためだけでなく、永続的な領有のためにさえも *culmina Alpium occupare <u>conari</u> **アルプスの頂上を占領すること、 *et ea loca finitimae provinciae adiungere **および（ローマの）属州に隣接する当地を併合することを<u>企てている</u>、 *sibi persuasum habebant. **と（ガッリア人たちは）確信していたのである。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===3節=== *<span style="background-color:#ffd;">[[/注解/3節]]　{{進捗|00%|2022-05-12}}</span> '''ガルバが軍議を召集し、策を募る''' *His nuntiis acceptis Galba, **ガルバは、これらの報告を受け取ると、 *<u>cum</u> neque opus hibernorum munitionesque plene essent perfectae **冬営の普請や防塁構築も十分に完成していなかったし、 *neque de frumento reliquoque commeatu satis esset provisum, **穀物や他の糧秣も十分に調達されていなかった<u>ので</u>、 *quod deditione facta obsidibusque acceptis **── というのも、降伏がなされて、人質が受け取られ、 *nihil de bello timendum existimaverat, **戦争について恐れるべきことは何もない、と判断していたためであるが、── *consilio celeriter convocato sententias exquirere coepit. **軍議を速やかに召集して、意見を求め始めた。 <br> ;軍議 *Quo in consilio, **その軍議において、 *<u>cum</u> tantum repentini periculi praeter opinionem accidisset **これほどの不意の危険が、予想に反して起こっていたので、 *ac iam omnia fere superiora loca multitudine armatorum completa conspicerentur **かつ、すでにほぼすべてのより高い場所が、武装した大勢の者たちで満たされていることが、見られていたので、 *neque subsidio veniri **救援のために（援軍が）来られることもなかったし、 *neque commeatus supportari interclusis itineribus possent, **糧秣が運び込まれることも、道が遮断されているので、できなかった<u>ので</u>、 *prope iam desperata salute non nullae eius modi sententiae dicebantur, **すでにほぼ身の安全に絶望していた幾人かの者たちの'''以下のような'''意見が述べられていた。 *ut impedimentis relictis eruptione facta **輜重を残して、出撃して、 *isdem itineribus quibus eo pervenissent ad salutem contenderent. **そこへやって来たのと同じ道によって、安全なところへ急ぐように、と。 **:<span style="color:#009900;">（訳注：レマンヌス〔[[w:レマン湖|レマン湖]]〕湖畔を通ってアッロブロゲース族領へ撤収することであろう。）</span> *Maiori tamen parti placuit, **しかしながら、大部分の者が賛成したのは、 *hoc reservato ad extremum consilio **この考え（計画）を最後まで保持しておいて、 *interim rei eventum experiri et castra defendere. **その間に、事の結果を吟味して、陣営を守備すること、であった。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===4節=== *<span style="background-color:#ffd;">[[/注解/4節]]　{{進捗|00%|2022-05-16}}</span> '''ガッリア勢がガルバの陣営を急襲し、寡兵のローマ勢は劣勢に陥る''' *Brevi spatio interiecto, **（敵の来襲まで）短い間が介在しただけだったので、 *vix ut iis rebus quas constituissent conlocandis atque administrandis tempus daretur, **決めておいた物事を配置したり遂行するための時間が、ほとんど与えられないほどであった。 *hostes ex omnibus partibus signo dato decurrere, **敵方〔ガッリア勢〕があらゆる方向から、号令が出されて、駆け下りて来て、 *lapides [[wikt:en:gaesum|gaesa]]que in vallum conicere. **石や投槍を堡塁の中に投げ込んだ。 *Nostri primo integris viribus fortiter propugnare **我が方〔ローマ勢〕は、当初、体力が損なわれていないうちは勇敢に応戦して、 *neque ullum frustra telum ex loco superiore mittere, **高所から、いかなる飛道具も無駄に投げることはなかった。 *et quaecumque<!--ut quaeque--> pars castrorum nudata defensoribus premi videbatur, **陣営のどの部分であれ、防戦者たちがはがされて押され気味であることと思われれば、 *eo occurrere et auxilium ferre, **（ローマ勢が）そこへ駆け付けて、支援した。 <br> ;　　兵の多寡が、ローマ勢を追い込む *sed hoc superari **しかし、以下のことにより（ローマ勢は）打ち破られた。 *quod diuturnitate pugnae hostes defessi proelio excedebant, **──戦いが長引いたことにより、疲れ切った敵たちは戦闘から離脱して、 *alii integris viribus succedebant; **体力が損なわれていない他の者たちが交代していたのだ。── *quarum rerum a nostris propter paucitatem fieri nihil poterat, **我が方〔ローマ勢〕は少数であるゆえに、このような事〔兵の交代〕は何らなされ得なかった。 *ac non modo defesso ex pugna excedendi, **疲弊した者にとっての戦いから離脱することの（機会）のみならず、 *sed ne saucio quidem eius loci ubi constiterat relinquendi ac sui recipiendi facultas dabatur. **負傷した者にとってさえも、その持ち場を放棄することや（体力を）回復することの機会も与えられなかったのだ。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===5節=== *<span style="background-color:#ffd;">[[/注解/5節]]　{{進捗|00%|2022-05-29}}</span> '''最後の土壇場で説得されたガルバが、疲労回復後の突撃に命運を賭ける''' *<u>Cum</u> iam amplius horis sex continenter pugnaretur, **すでに6時間より多く引き続いて戦われており、 **:<span style="color:#009900;">（訳注：[[古代ローマの不定時法]]では、冬の日中の半日ほどである）</span> *ac non solum vires sed etiam tela nostros deficerent, **活力だけでなく飛道具さえも我が方〔ローマ勢〕には不足していたし、 *atque hostes acrius instarent **敵方〔ガッリア勢〕はより激しく攻め立てていて、 *languidioribusque nostris **我が方〔ローマ勢〕が弱り切っており、 *vallum scindere et fossas complere coepissent, **（ガッリア勢は）防柵を破却したり、塹壕を埋め立てたりし始めていたし、 *resque esset iam ad extremum perducta casum, **戦況はすでに最後の土壇場に陥っていた<u>ので</u>、 <br> ;　　二人の軍団首脳バクルスとウォルセーヌスが、ガルバに敵中突破を説く *[[wikt:en:P.|P.]] Sextius Baculus, primi pili centurio, **<ruby><rb>[[w:プリムス・ピルス|首位百人隊長]]</rb><rp>（</rp><rt>プリームス・ピールス</rt><rp>）</rp></ruby>プーブリウス・セクスティウス・バクルス **:<span style="color:#009900;">（訳注：[[w:la:Publius Sextius Baculus|Publius Sextius Baculus]] などの記事を参照。）</span> *quem Nervico proelio compluribus confectum vulneribus diximus, **──その者が[[w:ネルウィイ族|ネルウィイー族]]との戦いで多くの負傷で消耗したと前述した── **:<span style="color:#009900;">（訳注：[[ガリア戦記 第2巻#25節|第2巻25節]]を参照。なお、[[ガリア戦記 第6巻#38節|第6巻38節]] でも言及される。）</span> *et item [[wikt:en:C.#Latin|C.]] Volusenus, tribunus militum, vir et consilii magni et virtutis, **および、[[w:トリブヌス・ミリトゥム|軍団次官]]ガーイウス・ウォルセーヌス ──卓越した判断力と武勇を持つ男──（の2人）は、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:en:Gaius Volusenus|Gaius Volusenus]]'' などの記事を参照せよ。）</span> *ad Galbam accurrunt **ガルバのもとへ急いで来て、 *atque unam esse spem salutis docent, si eruptione facta extremum auxilium experirentur. **身の安全のただ一つの希望は、出撃をして最後の救済策を試みるかどうかだ、と説く。 *Itaque convocatis centurionibus **こうして、<ruby><rb>[[w:ケントゥリオ|百人隊長]]</rb><rp>（</rp><rt>ケントゥリオー</rt><rp>）</rp></ruby>たちが召集されて、 *celeriter milites certiores facit, **（ガルバが以下のことを）速やかに兵士たちに通達する。 *paulisper intermitterent proelium **しばらく戦いを中断して *ac tantummodo tela missa exciperent seque ex labore reficerent, **ただ投げられた飛道具を遮るだけとし、疲労から（体力を）回復するようにと、 *post dato signo ex castris erumperent, **与えられた号令の後に陣営から出撃するように、 *atque omnem spem salutis in virtute ponerent. **身の安全のすべての希望を武勇に賭けるように、と。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===6節=== *<span style="background-color:#ffd;">[[/注解/6節]]　{{進捗|00%|2022-06-05}}</span> '''第12軍団がガッリア勢を破るが、ガルバはオクトードゥールスでの冬営を断念する''' *Quod iussi sunt faciunt, **（ローマ兵たちは）命じられたことをなして、 *ac subito omnibus portis eruptione facta **突然に（陣営の）すべての門から出撃がなされ、 *neque cognoscendi quid fieret **何が生じたのかを知ることの（機会）も *neque sui colligendi hostibus facultatem relinquunt. **（自軍の兵力を）集中することの機会も、敵方に残さない。 *Ita commutata fortuna **こうして武運が変転して、 *eos qui in spem potiundorum castrorum venerant undique circumventos intercipiunt, **（ローマ人の）陣営を占領することを期待してやって来ていた者たちを、至る所で包囲して<ruby><rb>屠</rb><rp>（</rp><rt>ほふ</rt><rp>）</rp></ruby>る。 *et ex hominum milibus amplius XXX{triginta}, **3万より多い人間が *quem numerum barbarorum ad castra venisse constabat, **それだけの数の蛮族が（ローマ）陣営のところへ来ていたのは、確実であったが、 *plus tertia parte interfecta **3分の1より多く（の者）が<ruby><rb>殺戮</rb><rp>（</rp><rt>さつりく</rt><rp>）</rp></ruby>されて、 *reliquos perterritos in fugam coiciunt **（ローマ勢は）残りの者たちを怖気づかせて敗走に追いやり、 *ac ne in locis quidem superioribus consistere patiuntur. **（ガッリア勢は）より高い場所にさえ留まることさえ許されない。 *Sic omnibus hostium copiis fusis armisque exutis **そのように敵方の全軍勢が撃破されて、武器が放棄されて、 *se intra munitiones suas recipiunt. **（ローマ勢は）自分たちの防塁の内側に撤収する。 <br> ;　　ガルバがオクトードゥールスでの冬営を断念して、同盟部族領に撤退する *Quo proelio facto, **この戦いが果たされると、 *quod saepius fortunam temptare Galba nolebat **──ガルバは、よりたびたび武運を試すことを欲していなかったし、 *atque alio se in hiberna consilio venisse meminerat, **冬営に他の計画のために来ていたことを思い出していたが、 *aliis occurrisse rebus videbat, **別の事態に遭遇したのを見ていたので、── *maxime frumenti commeatusque inopia permotus **とりわけ穀物や糧秣の欠乏に揺り動かされて、 *postero die omnibus eius vici aedificiis incensis **翌日にその村のすべての建物が焼き討ちされて、 *in provinciam reverti contendit, **（ガルバは）属州〔[[w:ガリア・キサルピナ|ガッリア・キサルピーナ]]〕に引き返すことを急ぐ。 *ac nullo hoste prohibente aut iter demorante **いかなる敵によって妨げられることも、あるいは行軍が遅滞させられることもなく、 *incolumem legionem in Nantuates, **軍団を無傷なままでナントゥアーテース族（の領土）に（連れて行き）、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：ナントゥアーテース族 ''[[w:en:Nantuates|Nantuates]]'' は、レマンヌス湖〔[[w:レマン湖|レマン湖]]〕の南東を領有していた部族。<br>　　　　[[#1節]]で、軍団のうち2個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>を宿営させたことが述べられた。）</span> *inde in Allobroges perduxit ibique hiemavit. **そこから、アッロブロゲース族（の領土）に連れて行き、そこで冬営した。 <div style="text-align:center"> {| |- |[[画像:Amphitheaterforumclaudiival1.jpg|thumb|right|500px|オクトードゥールス（<span style="font-family:Times New Roman;">[[w:la:Octodurus|Octodurus]]</span>）、すなわち現在の[[w:マルティニー|マルティニー市]]に遺る帝制ローマ時代の円形競技場。オクトードゥールスは、<span style="font-family:Times New Roman;">Forum Claudii Vallensium</span> と改称され、[[w: クラウディウス|クラウディウス帝]]によって円形競技場が建てられた。<br>（<span style="font-family:Times New Roman;">''[[w:fr:Amphithéâtre de Martigny|Amphithéâtre de Martigny]]''</span> 等の記事を参照。）]] |} </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ==大西洋岸ウェネティー族の造反== :::<span style="background-color:#ffd;">関連記事：[[w:モルビアン湾の海戦|モルビアン湾の海戦]]、''[[w:fr:Guerre des Vénètes|fr:Guerre des Vénètes]]'' 等を参照せよ。</span> ===7節=== *<span style="background-color:#ffd;">[[/注解/7節]]　{{進捗|00%|2022-06-12}}</span> '''新たな戦争の勃発''' *His rebus gestis **これらの戦役が遂げられて、 *cum omnibus de causis Caesar pacatam Galliam existimaret, **カエサルが、あらゆる状況についてガッリアは平定された、と判断していたときに、 *superatis Belgis, **（すなわち）[[w:ベルガエ|ベルガエ人]]は征服され、 **:<span style="color:#009900;">（訳注：第2巻で述べられたこと）</span> *expulsis Germanis, **[[w:ゲルマニア|ゲルマーニア]]人は駆逐され、 **:<span style="color:#009900;">（訳注：第1巻で述べられた[[w:アリオウィストゥス|アリオウィストゥス]]との戦役のこと）</span> *victis in [[wikt:en:Alpibus|Alpibus]] Sedunis, **アルペース〔[[w:アルプス山脈|アルプス]]〕においてセドゥーニー族は打ち負かされて、 **:<span style="color:#009900;">（訳注：[[#1節]]～[[#6節]]で述べられたこと）</span> *atque ita inita hieme in [[wikt:en:Illyricum#Latin|Illyricum]] profectus esset, **こうして冬の初めに（カエサルが）[[w:イリュリクム|イッリュリクム]]に出発していたときに、 *quod eas quoque nationes adire et regiones cognoscere volebat, **──というのは、これら各部族を訪れて諸地方を知ることを欲していたからであるが、── **:<span style="color:#009900;">（訳注：属州総督の職務として、巡回裁判を行う必要があったためであろう）</span> *subitum bellum in Gallia coortum est. **突然の戦争がガッリアで勃発したのである。 <br> ;　　　戦争の背景 *Eius belli haec fuit causa: **その戦争の原因は、以下の通りであった。 *[[wikt:en:P.|P.]] Crassus adulescens cum legione septima(VII.) **[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス青年]]は、第7軍団とともに **:<span style="color:#009900;">（訳注：三頭政治家[[w:マルクス・リキニウス・クラッスス|M. クラッスス]]の息子で、第1巻[[s:la:Commentarii_de_bello_Gallico/Liber_I#52|52節]]では騎兵隊の指揮官だった。<br>　　　　[[ガリア戦記_第2巻#34節|第2巻34節]]では、1個軍団とともに大西洋沿岸地方に派遣されたと述べられた。）</span> *proximus mare Oceanum in Andibus hiemarat. **<ruby><rb>大洋〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>に最も近いアンデース族（の領土）で冬営していた。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：アンデース族 Andes は、'''アンデカーウィー族''' [[w:la:Andecavi|Andecavi]], ''[[wikt:en:Andecavi|Andecavi]]'' と呼ばれることが多い。<br>　　　　実際には大西洋岸から内陸側に寄っていたと考えられている。）</span> *Is, quod in his locis inopia frumenti erat, **彼〔クラッスス〕は、これらの場所においては穀物の欠乏があったので、 *praefectos tribunosque militum complures in finitimas civitates **（[[w:アウクシリア|支援軍]]の）<ruby><rb>[[w:プラエフェクトゥス|指揮官]]</rb><rp>（</rp><rt>プラエフェクトゥス</rt><rp>）</rp></ruby>たちや[[w:トリブヌス・ミリトゥム|軍団次官]]たちのかなりの数を、近隣諸部族のところへ *frumenti (commeatusque petendi) causa dimisit; **穀物や糧食を求めるために送り出した。 *quo in numero est [[wikt:en:T.#Latin|T.]] Terrasidius missus in Esuvios<!--/ Unellos Essuviosque-->, **その人員のうち、ティトゥス・テッラシディウスは、エスウィイー族<!--ウネッリー族やエスウィイ族-->のところに遣わされ、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：テッラシディウスは騎士階級の将校。''[[w:en:Terrasidius|Terrasidius]]'' 参照。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：エスウィイー族 ''[[w:en:Esuvii|Esuvii]]'' は、現在の[[w:オルヌ川|オルヌ川]]盆地の[[w:オルヌ県|オルヌ県]][[w:セー (オルヌ県)|セー]]～[[w:fr:Exmes|エム]]の辺りにいたらしい。）</span> *[[wikt:en:M.#Latin|M.]] [[wikt:en:Trebius#Latin|Trebius]] Gallus in Coriosolităs, **マールクス・トレビウス・ガッルスは、コリオソリテース族のところに（遣わされ）、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:it:Marco Trebio Gallo|it:Marco Trebio Gallo]]'' 等参照）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：コリオソリテース族 ''[[w:en:Coriosolites|Coriosolites]]'' は、クーリオソリーテース ''[[wikt:en:Curiosolites|Curiosolites]]'' などとも呼ばれ、<br>　　　　現在の[[w:コート＝ダルモール県|コート＝ダルモール県]]コルスール([[w:en:Corseul|Corseul]])の辺りにいたらしい。）</span> *[[wikt:en:Q.|Q.]] [[wikt:en:Velanius#Latin|Velanius]] cum T. Sillio in Venetos. **クゥイーントゥス・ウェラーニウスはティトゥス・シーッリウスとともに、[[w:ウェネティ族 (ガリア)|ウェネティー族]]のところに（遣わされた）。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:it:Quinto Velanio|it:Quinto Velanio]], [[w:it:Tito Silio|it:Tito Silio]]'' 等参照。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:ウェネティ族 (ガリア)|ウェネティー族]] ''[[w:en:Veneti (Gaul)|Veneti (Gaul)]]'' は、[[w:アルモリカ|アルモリカ]]南西部、現在の[[w:モルビアン県|モルビアン県]]辺りにいた。）</span> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===8節=== *<span style="background-color:#ffd;">[[/注解/8節]]　{{進捗|00%|2022-06-13}}</span> '''ウェネティー族らの動き''' <br> ;　　　沿海地方を主導するウェネティー族 *Huius est civitatis longe amplissima auctoritas omnis orae maritimae regionum earum, **この部族〔ウェネティー族〕の<ruby><rb>影響力</rb><rp>（</rp><rt>アウクトーリタース</rt><rp>）</rp></ruby>は、海岸のその全地方の中でずば抜けて大きい。 *quod et naves habent Veneti plurimas, **── というのは、[[w:ウェネティ族 (ガリア)|ウェネティー族]]は、最も多くの船舶を持っており、 *quibus in Britanniam navigare consuerunt, **それら〔船団〕によって[[w:ブリタンニア|ブリタンニア]]に航海するのが常であり、 *et scientia atque usu rerum nauticarum ceteros antecedunt **かつ[[w:海事|海事]]の知識と経験において他の者たち〔諸部族〕をしのいでおり、 *et in magno impetu maris atque aperto &lt;Oceano&gt; **かつ海のたいへんな荒々しさと開けた&lt;<ruby><rb>大洋〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>&gt;において、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：&lt;Oceano&gt; は写本になく、挿入提案された修正読み）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:大陸棚|大陸棚]]が広がる[[w:ビスケー湾|ビスケー湾]]は、世界最大12mの大きな[[w:潮汐|干満差]]と、<br>　　　　北西風による激しい嵐で知られる<ref>[https://kotobank.jp/word/%E3%83%93%E3%82%B9%E3%82%B1%E3%83%BC%E6%B9%BE-119819 ビスケー湾とは - コトバンク]</ref>。）</span> *paucis portibus interiectis, **わずかの港が介在していて、 *quos tenent ipsi, **彼ら自身〔ウェネティー族〕がそれら〔港湾〕を制していて、 *omnes fere qui eo mari uti consuerunt, habent vectigales. **その海を利用するのが常であった者たち〔部族〕ほぼすべてを、貢税者としていたのだ。── <br> ;　　　ウェネティー族が、クラッススの使節たちを抑留する *Ab his fit initium retinendi Sillii atque Velanii, **彼ら〔ウェネティー族〕によって、シーッリウスとウェラーニウスを拘束することが皮切りとなる。 **:<span style="color:#009900;">（訳注：2人は、前節([[#7節]])でウェネティー族への派遣が述べられた使節）</span> *<u>et si quos intercipere potuerunt</u> **何らかの者たちを捕えることができたのではないか、と。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：下線部は、&beta;系写本だけの記述で、&alpha;系写本にはない。）</span> *quod per eos suos se obsides, quos Crasso dedissent, recuperaturos existimabant. **というのは、彼らを介して、[[w:プブリウス・リキニウス・クラッスス|クラッスス]]に差し出されていた己の人質たちを取り戻すことができると考えていたのである。 <br> *Horum auctoritate finitimi adducti, **彼ら〔ウェネティー族〕の影響力によって、近隣の者たち〔諸部族〕が動かされて、 *ut sunt Gallorum subita et repentina consilia, **──ガッリア人の判断力というものは、思いがけなく性急なものであるが、── *eadem de causa Trebium Terrasidiumque retinent **同じ理由によりトレビウスとテッラシディウスを拘束する。 **:<span style="color:#009900;">（訳注：トレビウスは、前節でコリオソリテース族に派遣された。<br>　　　　テッラシディウスは、前節でエスウィイー族に派遣された。）</span> *et celeriter missis legatis **そして速やかに使節が遣わされて、 *per suos principes inter se coniurant **自分らの領袖たちを通して互いに誓約する。 *nihil nisi communi consilio acturos eundemque omnes fortunae exitum esse laturos, **合同の軍議なしには何も実施しないであろうし、皆が命運の同じ結果に耐えるであろう、と。 *reliquasque civitates sollicitant, **残りの諸部族を扇動する。 *ut in ea libertate quam a maioribus acceperint, permanere quam Romanorum servitutem perferre malint. **ローマ人への隷属を辛抱することより、むしろ先祖から引き継いでいた自由に留まることを欲すべし、と。 <br> *Omni ora maritima celeriter ad suam sententiam perducta **すべての海岸（の諸部族）が速やかに自分たち〔ウェネティー族〕の見解に引き込まれると、 *communem legationem ad [[wikt:en:Publium|Publium]] Crassum mittunt, **共同の使節を[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス]]のもとへ遣わす。 *si velit suos recuperare, obsides sibi remittat. **もし味方の者たち〔ローマ人〕を取り戻すことを望むならば、自分たち〔諸部族〕の人質たちを返すように、と。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===9節=== *<span style="background-color:#ffd;">[[/注解/9節]]　{{進捗|00%|2022-06-19}}</span> {{Wikipedia|la:Liger| Liger }} '''カエサル到着、ウェネティー族らの作戦と開戦準備''' ;　　　カエサルが、海戦の準備を手配してから、沿岸地域に急ぐ *Quibus de rebus Caesar a Crasso certior factus, **以上の事について、カエサルは[[w:プブリウス・リキニウス・クラッスス|クラッスス]]により報知されると、 *quod ipse aberat longius, **（カエサル）自身は非常に遠くに離れていたので、 **:<span style="color:#009900;">（訳注：[[#コラム「ルカ会談」|#ルカ会談]]などローマへの政界工作のために属州にいたと考えられている。）</span> *naves interim longas aedificari in flumine [[wikt:la:Liger#Latine|Ligeri]], quod influit in Oceanum, **その間に<u>軍船</u>が<ruby><rb>大洋〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>に流れ込むリゲル川〔[[w:ロワール川|ロワール川]]〕にて建造されること、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：艦隊 [[w:la:Classis Romana|classis]] の主力として戦う[[w:ガレー船|ガレー船]]は「長船」[[w:la:Navis longa|navis longa]] と呼ばれていた。<br>　　　　これに対して、軍需物資を運搬する輸送船は [[w:la:Navis actuaria|navis actuaria]] と呼ばれていた。）</span> *remiges ex provincia institui, **<ruby><rb>漕ぎ手</rb><rp>（</rp><rt>レーメクス</rt><rp>）</rp></ruby>が属州〔[[w:ガリア・トランサルピナ|ガッリア・トランサルピーナ]]〕から採用されること、 *nautas gubernatoresque comparari iubet. **<ruby><rb>[[w:船員|水夫]]</rb><rp>（</rp><rt>ナウタ</rt><rp>）</rp></ruby>や<ruby><rb>操舵手</rb><rp>（</rp><rt>グベルナートル</rt><rp>）</rp></ruby>が徴募されること、を命じる。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：船尾の「<ruby><rb>[[w:舵|舵]]</rb><rp>（</rp><rt>かじ</rt><rp>）</rp></ruby>」が発明されたのは[[w:漢|漢代]]の中国であって、古代西洋の船に<ruby><rb>舵</rb><rp>（</rp><rt>かじ</rt><rp>）</rp></ruby>はない。<br>　　　　船の操舵手は「<ruby><rb>舵櫂</rb><rp>（</rp><rt>かじかい</rt><rp>）</rp></ruby>」(''[[w:en:Steering oar|steering oar]]'') という[[w:櫂|櫂]]の一種を用いて操船したらしい。）</span> <br> *His rebus celeriter administratis ipse, **これらの事柄が速やかに処理されると、（カエサル）自身は *cum primum per anni tempus potuit, ad exercitum contendit. **年のできるだけ早い時季に、軍隊のもとへ急いだ。 <br> ;　　　ウェネティー族らが、使節団拘留の重大さを勘案して、海戦の準備を進める *Veneti reliquaeque item civitates cognito Caesaris adventu **[[w:ウェネティ族 (ガリア)|ウェネティー族]]と残りの部族もまた、カエサルの到着を知り、 *<span style="color:#009900;">&lt;</span>et de recipiendis obsidibus spem se fefellise<span style="color:#009900;">&gt;</span> certiores facti, **<span style="color:#009900;">&lt;</span>かつ人質を取り戻すという希望に惑わされたことを<span style="color:#009900;">&gt;</span> 知らされて、 *simul quod quantum in se facinus admisissent intellegebant, **同時に、どれほど大それた行為を自分たちが侵していたかを判断していたので、 *<span style="color:#009900;">[</span>legatos, quod nomen ad omnes nationes sanctum inviolatumque semper fuisset, **──（すなわち）あらゆる種族のもとでその名が神聖かつ不可侵の、使節たちが *retentos ab se et in vincula coniectos,<span style="color:#009900;">]</span> **自分たちによって拘束され、鎖につながれていたわけだが、── *pro magnitudine periculi bellum parare **危機の重大さに見合う戦争を準備すること、 *et maxime ea quae ad usum navium pertinent providere instituunt, **とりわけ船団を運用するために役立つところのものを調達すること、を着手する。 *hoc maiore spe quod multum natura loci confidebant. **地勢を大いに信じていた点に大きな期待をして。 <br> *Pedestria esse itinera concisa aestuariis, **（ローマ勢の）歩兵の行軍路は入江で遮断されるし、 *navigationem impeditam propter inscientiam locorum paucitatemque portuum sciebant, **土地の不案内と港の少なさのゆえに航行が妨げられることを（ウェネティー族らは）知っていた。 *neque nostros exercitus propter inopiam frumenti diutius apud se morari posse confidebant; **穀物の欠乏のゆえに、我が軍〔ローマ軍〕がより長く彼らのもとに留まることができないと（ウェネティー族らは）信じ切っていた。 <br> *ac iam ut omnia contra opinionem acciderent, **やがて、すべてのことが予想に反して生じたとしても、 *tamen se plurimum navibus posse, quam Romanos neque ullam facultatem habere navium, **けれども自分たち〔ウェネティー族ら〕は艦船において、艦船の備えを何ら持たないローマ人よりも大いに優勢であり、 *neque eorum locorum, ubi bellum gesturi essent, vada, portus, insulas novisse; **戦争を遂行しようとしているところの浅瀬・港・島に（ローマ人は）不案内であった（と信じ切っていた）。 <br> *ac longe aliam esse navigationem in concluso mari atque in vastissimo atque apertissimo Oceano perspiciebant. **閉ざされた海〔[[w:地中海|地中海]]〕と非常に広大で開けた大洋における航行はまったく別物であると見通していた。 <br> *His initis consiliis **この作戦計画が決められると、 *oppida muniunt, **<ruby><rb>[[w:オッピドゥム|城塞都市]]</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の防備を固め、 *frumenta ex agris in oppida comportant, **穀物を耕地から<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>に運び込み、 *naves in [[wikt:en:Venetia#Latin|Venetiam]], ubi Caesarem primum (esse) bellum gesturum constabat, quam plurimas possunt, cogunt. **カエサルが最初の戦争を遂行するであろうことが明白であったところの[[w:ウェネティ族 (ガリア)|ウェネティー族]]領に、ありったけの艦船を集める。 <br> *Socios sibi ad id bellum **この戦争のために（ウェネティー族は）自分たちのもとへ同盟者として *[[wikt:en:Osismi#Latin|Osismos]], [[wikt:en:Lexovii#Latin|Lexovios]], [[wikt:en:Namnetes#Latin|Namnetes]], Ambiliatos, [[wikt:en:Morini#Latin|Morinos]], [[w:en:Diablintes|Diablintes]], [[wikt:en:Menapii#Latin|Menapios]] adsciscunt; **<span style="font-size:10pt;">オスィスミー族・レクソウィイー族・ナムネーテース族・アンビリアーティー族・モリニー族・ディアブリンテース族・メナピイー族</span>&nbsp;を引き入れる。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：アンビリアーティー族 ➡ [[w:ガイウス・プリニウス・セクンドゥス|プリニウス]]は「アンビラトリー族」 [[wikt:en:Ambilatri#Latin|Ambilatri]] と記す。<br>　　　　ディアブリンテース族 ➡ プリニウスは「ディアブリンティー族」 [[wikt:en:Diablinti#Latin|Diablinti]] と記す。<br>　　　　　　　　　　　　　　　　この部族は、アウレルキー族 ''[[w:en:Aulerci|Aulerci]]'' の支族。）</span> *auxilia ex Britannia, quae contra eas regiones posita est, arcessunt. **援軍を、この地域の向かい側に位置する[[w:ブリタンニア|ブリタンニア]]から呼び寄せた。 **:<span style="color:#009900;">（訳注：援軍を出したという口実のもと、翌年カエサルがブリタンニアに侵攻することになる。）</span> <div style="text-align:center"> {| |- |[[画像:Map of Aremorican tribes (Latin).svg|thumb|right|600px|[[w:アルモリカ|アルモリカ]]（<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Armorica|Armorica]]''</span> ）の部族分布図。 ]] |} </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===10節=== *<span style="background-color:#ffd;">[[/注解/10節]]　{{進捗|00%|2022-07-02}}</span> '''カエサルの開戦への大義名分''' *Erant hae difficultates belli gerendi, quas supra ostendimus, **上で指摘したような、戦争を遂行することの困難さがあった。 *sed tamen multa Caesarem ad id bellum incitabant: **にもかかわらず、多くのことがカエサルをその戦争へと駆り立てていたのだ。 *iniuria retentorum equitum Romanorum, **①ローマ人の[[w:エクィテス|騎士]]〔騎士階級の者〕たちが拘束されることの無法さ、 *rebellio facta post deditionem, **②降伏の後でなされた造反、 *defectio datis obsidibus, **③人質を供出しての謀反、 *tot civitatum coniuratio, **④これほど多くの部族の共謀、 *in primis ne hac parte neglecta reliquae nationes sibi idem licere arbitrarentur. **⑤何よりも第一に、この地方をなおざりにして、残りの種族が自分たちも同じことを許容されると思い込まないように。 *Itaque cum intellegeret **そこで、（カエサルは以下のように）認識していたので、 *omnes fere Gallos novis rebus studere et ad bellum mobiliter celeriterque excitari, **①ほぼすべてのガリア人が政変を熱望して、戦争へ簡単に速やかに奮い立たせられていること、 *omnes autem homines natura libertati studere incitari et condicionem servitutis odisse, **②他方ですべての人間は本来的に自由を熱望することに扇動され、隷属の状態を嫌っていること、 *prius quam plures civitates conspirarent, **多くの部族が共謀するより前に、 *partiendum sibi ac latius distribuendum exercitum putavit. **（カエサルは）自分にとって軍隊が分けられるべき、より広範に割り振られるべきであると考えた。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===11節=== *<span style="background-color:#ffd;">[[/注解/11節]]　{{進捗|00%|2022-07-03}}</span> '''ラビエーヌス、クラッスス、サビーヌス、ブルートゥスを前線へ派兵する''' <br><br> ;　　　副官ラビエーヌスをトレウェリー族のもとへ遣わす *Itaque [[wikt:en:Titum|T.]] [[wikt:en:Labienus#Latin|Labienum]] legatum in [[wikt:en:Treveri#Latin|Treveros]], qui proximi flumini Rheno sunt, cum equitatu mittit. **こうして、<ruby><rb>[[w:レガトゥス|副官]]</rb><rp>（</rp><rt>レガトゥス</rt><rp>）</rp></ruby>[[w:ティトゥス・ラビエヌス|ティトゥス・ラビエーヌス]]をレーヌス川〔[[w:ライン川|ライン川]]〕に最も近いトレーウェリー族に、騎兵隊とともに派遣する。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:la:Titus Labienus|Titus Labienus]] は、『ガリア戦記』におけるカエサルの片腕。<br>　　　　''[[w:en:Treveri|Treveri]]'' はローマの同盟部族だが、[[ガリア戦記_第5巻|第5巻]]・[[ガリア戦記_第6巻|第6巻]]で挙兵する。）</span> *Huic mandat, **彼に（以下のように）命じる。 *[[wikt:en:Remi#Latin|Remos]] reliquosque [[wikt:en:Belgas|Belgas]] adeat atque in officio contineat **①レーミー族やほかの[[w:ベルガエ|ベルガエ人]]を訪れて、<ruby><rb>忠実さ</rb><rp>（</rp><rt>オッフィキウム</rt><rp>）</rp></ruby>に留めるように、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:en:Remi|Remi]]'' は、ローマの同盟部族で、[[ガリア戦記_第2巻#3節|第2巻3節]]以降で言及された。）</span> *[[wikt:en:Germanos|Germanos]]que, qui auxilio a Gallis arcessiti dicebantur, **②ガッリア人により援兵として呼び寄せられたといわれていた[[w:ゲルマニア|ゲルマーニア]]人が **:<span style="color:#009900;">（訳注：第1巻で言及された[[w:アリオウィストゥス|アリオウィストゥス]]の軍勢のこと。）</span> *si per vim navibus flumen transire conentur, prohibeat. **（彼らが）もし力ずくで船で川を渡ることを試みるならば、防ぐように、と。 <br> ;　　　クラッスス青年をアクィーターニアに派遣する *[[wikt:en:Publium|P.]] [[wikt:en:Crassus#Latin|Crassum]] cum cohortibus legionariis XII(duodecim) et magno numero equitatus in Aquitaniam proficisci iubet, **[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス]]には、軍団の12個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>と多数の騎兵隊とともに、[[w:アクィタニア|アクィーターニア]]に出発することを命じる。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:la:Publius Licinius Crassus|Publius Licinius Crassus]]、[[#7節]]から既述。）</span> *ne ex his nationibus auxilia in Galliam mittantur ac tantae nationes coniungantur. **これらの種族から援兵がガッリアに派遣され、これほど多くの諸部族が結託することがないように。 <br> ;　　　副官サビーヌスを3個軍団とともに[[w:アルモリカ|アルモリカ]]北部へ派兵する *[[wikt:en:Quintum#Latin|Q.]] [[wikt:en:Titurius#Latin|Titurium]] Sabinum legatum cum legionibus tribus **副官[[w:クィントゥス・ティトゥリウス・サビヌス|クィーントゥス・ティトゥリウス・サビーヌス]]を3個軍団とともに **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:en:Quintus Titurius Sabinus|Quintus Titurius Sabinus]]'' は[[ガリア戦記_第2巻#5節|第2巻5節]]から言及されている『ガリア戦記』前半で活躍する副官。）</span> *in [[wikt:en:Unelli#Latin|Unellos]](Venellos), Coriosolităs [[wikt:en:Lexovii#Latin|Lexovios]]que mittit, qui eam manum distinendam curet. **ウネッリー族・コリオソリテース族・レクソウィイー族に派遣して、彼らの手勢を分散させるべく配慮するように。 <br> ;　　　ブルートゥス青年をウェネティー族領へ派兵する *[[wikt:en:Decimus#Latin|D.]] [[wikt:en:Brutum|Brutum]] adulescentem classi Gallicisque navibus, **[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|デキムス・ブルートゥス青年]]に、（ローマの）艦隊とガッリア人の船団を、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:la:Decimus Iunius Brutus Albinus|Decimus Iunius Brutus Albinus]] は、カエサルの副官として活躍するが、後に暗殺に加わる。）</span> *quas ex [[wikt:en:Pictones#Latin|Pictonibus]] et [[wikt:en:Santoni#Latin|Santonis]] reliquisque pacatis regionibus convenire iusserat, **──これら（船団）はピクトネース族・サントニー族やほかの平定された地方から集まるように命じていたものであるが、── *praeficit et, cum primum possit, in [[wikt:en:Veneti#Latin|Venetos]] proficisci iubet. **（ブルートゥスに船団を）指揮させて、できるだけ早く[[w:ウェネティ族 (ガリア)|ウェネティー族]]（の領土）に出発することを命じる。 <br> *Ipse eo pedestribus copiis contendit. **（カエサル）自身は、そこへ歩兵の軍勢とともに急ぐ。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===12節=== *<span style="background-color:#ffd;">[[/注解/12節]]　{{進捗|00%|2022-07-09}}</span> '''ウェネティー族の城塞都市の地勢、海洋民の機動性''' <div style="text-align:center"> {| |- |[[画像:Bretagne Finistere PointeduRaz15119.jpg|thumb|right|350px|ウェネティー族の[[w:オッピドゥム|城塞都市]]があった[[w:ブルターニュ半島|ブルターニュ半島]]の突き出た地形]] |} </div> *Erant [[wikt:en:eiusmodi|eiusmodi]] fere situs oppidorum, **（[[w:ウェネティ族 (ガリア)|ウェネティー族]]の）<ruby><rb>[[w:オッピドゥム|城塞都市]]</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の地勢はほぼ以下のようであった。 *ut posita in extremis [[wikt:en:lingula#Latin|lingulis]] [[wikt:en:promunturium#Latin|promunturiis]]que **<ruby><rb>[[w:砂嘴|砂嘴]]</rb><rp>（</rp><rt>リングラ</rt><rp>）</rp></ruby>や[[w:岬|岬]]の先端部に位置しているので、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:lingula#Latin|lingula]] ⇒ [[w:la:Lingua terrae|lingua terrae]] (舌状地) ≒ <ruby><rb>[[w:砂嘴|砂嘴]]</rb><rp>（</rp><rt>さし</rt><rp>）</rp></ruby>(くちばし状の砂地)。）</span> *neque pedibus aditum haberent, cum ex alto se [[wikt:en:aestus#Latin|aestus]] incitavisset, **沖合から<ruby><rb>[[w:潮汐|潮　汐]]</rb><rp>（</rp><rt>アエトゥス</rt><rp>）</rp></ruby>が押し寄せて来たとき<span style="color:#009900;">〔満潮〕</span>に、徒歩での<ruby><rb>接近路</rb><rp>（</rp><rt>アプローチ</rt><rp>）</rp></ruby>を持っていなかった。 *quod bis accidit semper horarum XII(duodenarum) spatio, **というのは<span style="color:#009900;">（満潮が毎日）</span>2度、常に12時間の間隔で起こるためである。 <div style="text-align:center"> {| |- |[[画像:Astronomical tide IJmuiden 21 January 2012.png|thumb|right|600px|ある日（24時間）の'''[[w:潮位|潮位]]'''予測グラフの例（2012年、オランダ北海沿岸のエイマイデン）。<br>満潮や干潮は、約12時間の周期で繰り返されることが多いため、たいてい1日2回ずつ生じる。]] |} </div> *neque navibus, **船で（のアプローチ）もなく、 *quod rursus minuente aestu naves in vadis adflictarentur. **というのは、潮が再び減ると<span style="color:#009900;">〔干潮〕</span>、船団が[[w:浅瀬|浅瀬]]で損傷してしまうためである。 *Ita utraque re oppidorum oppugnatio impediebatur; **このように<span style="color:#009900;">（陸路・海路）</span>どちらの状況においても、<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の攻略は妨げられていた。 <br><br> *ac si quando magnitudine operis forte superati, **あるとき、期せずして<span style="color:#009900;">（ウェネティー族がローマ人の）</span><ruby><rb>構造物</rb><rp>（</rp><rt>オプス</rt><rp>）</rp></ruby>の大きさに圧倒されて、 *extruso mari aggere ac molibus **<span style="color:#009900;">（ローマ人が建造した）</span><ruby><rb>土手</rb><rp>（</rp><rt>アッゲル</rt><rp>）</rp></ruby>や<ruby><rb>[[w:防波堤|防波堤]]</rb><rp>（</rp><rt>モーレース</rt><rp>）</rp></ruby>により海水が押し出され、 *atque his oppidi moenibus adaequatis, **これら<span style="color:#009900;">〔堡塁〕</span>が<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の城壁と<span style="color:#009900;">（高さにおいて）</span>等しくされ、 *suis fortunis desperare coeperant, **<span style="color:#009900;">（ウェネティー族らが）</span>自分たちの命運に絶望し始めていたとしても、 *magno numero navium adpulso, **船の多数を接岸して、 *cuius rei summam facultatem habebant, **それら〔船〕の供給に最大の備えを持っていたので、 *omnia sua deportabant seque in proxima oppida recipiebant; **自分たちの<ruby><rb>一切合財</rb><rp>（</rp><rt>オムニア</rt><rp>）</rp></ruby>を運び去って、最も近い<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>に撤収していた。 *ibi se rursus isdem opportunitatibus loci defendebant. **そこにおいて再び同じような地の利によって防戦していたのだ。 <br><br> *Haec [[wikt:en:eo#Latin|eo]] facilius magnam partem aestatis faciebant, **以上のことが、夏の大部分を<span style="color:#009900;">（ウェネティー族にとって）</span>より容易にしていた。 *quod nostrae naves [[wikt:en:tempestas#Latin|tempestatibus]] detinebantur, **なぜなら、我が方〔ローマ人〕の船団は嵐により<span style="color:#009900;">（航行を）</span>阻まれており、 *summaque erat **<span style="color:#009900;">（航行することの困難さが）</span>非常に大きかった。 *vasto atque aperto mari, **海は広大で開けており、 *magnis aestibus, **<ruby><rb>潮流</rb><rp>（</rp><rt>アエトゥス</rt><rp>）</rp></ruby>が激しく、 *raris ac prope nullis portibus **港は<ruby><rb>疎</rb><rp>（</rp><rt>まば</rt><rp>）</rp></ruby>らでほとんどないので、 *difficultas navigandi. **航行することの困難さが<span style="color:#009900;">（非常に大きかった）</span>。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===13節=== *<span style="background-color:#ffd;">[[/注解/13節]]　{{進捗|00%|2022-07-10}}</span> '''ウェネティー族の帆船の特徴''' <div style="background-color:#ededed; width:90%; text-align:center"> {| |- | colspan="2" |ウェネティー族の船の再現画（左下に兵士の大きさが示されている） | rowspan="2" style="background-color:#fff;" |&nbsp; | rowspan="2" style="vertical-align:bottom;" |[[画像:Navis longa ja.JPG|thumb|right|350px|古代ローマの軍船（[[w:ガレー船|ガレー船]]）の構成]] |- | style="vertical-align:bottom;" |[[画像:Navire venete.svg|thumb|right|200px|一つの帆をもつ帆船の例]] | style="vertical-align:bottom;" |[[画像:Navire venete 2.svg|thumb|right|200px|二つの帆をもつ帆船の例]] |} </div> *Namque ipsorum naves ad hunc modum factae armataeque erant: **これに対して彼ら<span style="color:#009900;">〔[[w:ウェネティ族 (ガリア)|ウェネティー族]]〕</span>自身の[[w:帆船|船]]は、以下のやり方で建造され、<ruby><rb>[[w:艤装|艤装]]</rb><rp>（</rp><rt>ぎそう</rt><rp>）</rp></ruby>されていた。 ;　竜骨 *[[wikt:en:carina#Latin|carinae]] [[wikt:en:aliquanto|aliquanto]] planiores quam nostrarum navium, **<ruby><rb>[[w:竜骨 (船)|竜　骨]]</rb><rp>（</rp><rt>カリーナ</rt><rp>）</rp></ruby>は、我が方<span style="color:#009900;">〔ローマ人〕</span>の船のものよりも、いくらか平らで、 **:<span style="color:#009900;">（訳注：[[w:竜骨 (船)|竜骨]]は、船底に突き出た背骨部分で、[[w:帆船|帆船]]が風で横滑りしないように造られていた。）</span> *quo facilius vada ac decessum aestus excipere possent; **それによって、より容易に[[w:浅瀬|浅瀬]]&nbsp;や&nbsp;[[w:潮汐|潮]]が退くこと<span style="color:#009900;">〔干潮〕</span>を持ち応えることができた。 ;　船首と船尾 *[[wikt:en:prora#Latin|prorae]] admodum erectae atque item [[wikt:en:puppis|puppes]], **<ruby><rb>[[w:船首|船　首]]</rb><rp>（</rp><rt>プローラ</rt><rp>）</rp></ruby>はまったく直立しており、<ruby><rb>[[w:船尾|船　尾]]</rb><rp>（</rp><rt>プッピス</rt><rp>）</rp></ruby>も同様で、 *ad magnitudinem fluctuum tempestatumque adcommodatae; **<ruby><rb>[[w:波#波浪（風浪とうねり）|波　浪]]</rb><rp>（</rp><rt>フルークトゥス</rt><rp>）</rp></ruby> や <ruby><rb>[[w:嵐|暴風雨]]</rb><rp>（</rp><rt>テンペスタース</rt><rp>）</rp></ruby> の激しさに適応していた。 ;　船体の材質 *naves totae factae ex [[wikt:en:robur#Latin|robore]] ad quamvis vim et contumeliam perferendam; **船は、どんな力や衝撃にも耐えるために、全体として[[w:オーク|オーク材]]で造られていた。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:la:robur|robur]] は ''[[wikt:en:oak#English|oak]]'' と英訳され、[[w:樫#Japanese|樫]]と訳されることが多いが、<br>　　　　「<ruby><rb>[[w:カシ|樫]]</rb><rp>（</rp><rt>カシ</rt><rp>）</rp></ruby>」は常緑樹であり、西洋では落葉樹である「<ruby><rb>[[w:ナラ|楢]]</rb><rp>（</rp><rt>ナラ</rt><rp>）</rp></ruby>」が多い。<br>　　　　　学名 [[w:la:Quercus robur|Quercus robur]] は「[[w:ヨーロッパナラ|ヨーロッパナラ]]」と訳される。）</span> ;　横梁 *[[wikt:en:transtrum#Latin|transtra]] ex pedalibus in altitudinem [[wikt:en:trabs#Latin|trabibus]], confixa [[wikt:en:clavus#Latin|clavis]] [[wikt:en:ferreus#Latin|ferreis]] digiti [[wikt:en:pollex#Latin|pollicis]] crassitudine; **<ruby><rb>横梁(横木)</rb><rp>（</rp><rt>トラーンストルム</rt><rp>）</rp></ruby>は、1ペースの幅の<ruby><rb>材木</rb><rp>（</rp><rt>トラプス</rt><rp>）</rp></ruby>からなり、親指の太さほどの鉄製の[[w:釘|釘]]で固定されていた。 **:<span style="font-family:Times New Roman;color:#009900;">（訳注：1[[ガイウス・ユリウス・カエサルの著作/通貨・計量単位#ペース|ペース]]は約29.6cm。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:transtrum#Latin|transtra]] は、<ruby><rb>[[w:マスト|帆柱]]</rb><rp>（</rp><rt>マスト</rt><rp>）</rp></ruby>（[[wikt:en:malus#Etymology_3_2|malus]]）を船に固定するための<ruby><rb>横梁(横木)</rb><rp>（</rp><rt>クロスビーム</rt><rp>）</rp></ruby>とも考えられる。）</span> ;　錨(いかり)の索具 *[[wikt:en:ancora#Latin|ancorae]] pro [[wikt:en:funis#Latin|funibus]] ferreis catenis revinctae; **<ruby><rb>[[w:錨|錨]]</rb><rp>（</rp><rt>アンコラ</rt><rp>）</rp></ruby>は、<ruby><rb>[[w:ロープ|縄　索]]</rb><rp>（</rp><rt>フーニス</rt><rp>）</rp></ruby>の代わりに鉄製の[[w:鎖|鎖]]でつながれていた。 <div style="background-color:#eee; width:600px; text-align:center"> {| |- | style="vertical-align:bottom;" |[[画像:Nemi 060 museo delle Navi.jpg|thumb|right|180px|[[w:la:Ancora|ancora]] ([[w:錨|錨]])(古代ローマ)]] | style="vertical-align:bottom;" |[[画像:Cordage en chanvre.jpg|thumb|right|150px|[[w:la:Funis|funis]] (綱の[[w:ロープ|ロープ]])]] | style="vertical-align:bottom;" |[[画像:Old chain.jpg|thumb|right|150px|[[w:la:Catena|catena]] ([[w:鎖|鎖]])]] |} </div> <br> ;　帆の材質 *[[wikt:en:pellis#Latin|pelles]] pro [[wikt:en:velum#Latin|velis]] [[wikt:en:aluta#Latin|alutae]]que tenuiter confectae, **<ruby><rb>[[w:帆布|帆　布]]</rb><rp>（</rp><rt>ウェールム</rt><rp>）</rp></ruby>の代わりに<ruby><rb>[[w:毛皮|毛皮]]</rb><rp>（</rp><rt>ペッリス</rt><rp>）</rp></ruby>や、薄く作製された<ruby><rb>なめし皮</rb><rp>（</rp><rt>アルータ</rt><rp>）</rp></ruby>が（用いられた）。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:pellis#Latin|pellis]] は<ruby><rb>鞣</rb><rp>（</rp><rt>なめ</rt><rp>）</rp></ruby>していない生皮、[[wikt:en:aluta#Latin|aluta]] は<ruby><rb>鞣</rb><rp>（</rp><rt>なめ</rt><rp>）</rp></ruby>した[[w:皮革|皮革]] [[wikt:en:corium#Latin|corium]] のこと。）</span> <div style="background-color:#eee; width:600px; text-align:center"> {| |- | style="vertical-align:bottom;" |[[画像:Linen canvas.jpg|thumb|right|150px|<ruby><rb>[[w:リネン|亜麻布]]</rb><rp>（</rp><rt>リネン</rt><rp>）</rp></ruby>の[[w:帆布|帆布]] ]] | style="vertical-align:bottom;" |[[画像:Kissen aus indischem Antilopenfell 2013.jpg|thumb|right|100px|[[w:la:Pellis|pellis]] ([[w:毛皮|毛皮]])]] | style="vertical-align:bottom;" |[[画像:Natural Bridge State Park (30337351644).jpg|thumb|right|200px|aluta ([[w:en:Tanning (leather)|なめし皮]])]] |} </div> *[hae] sive propter inopiam [[wikt:en:linum#Latin|lini]] atque eius usus inscientiam, **[これは] あるいは、<ruby><rb>[[w:アマ (植物)|亜麻]]</rb><rp>（</rp><rt>リーヌム</rt><rp>）</rp></ruby>の不足ゆえや、その利用に無知であるゆえか、 **:<span style="color:#009900;">（訳注：ローマ人には、[[w:リネン|亜麻布 (リネン)]]で帆を作る慣習があった。）</span> *sive eo, quod est magis [[wikt:en:verisimilis#Latin|veri simile]], **あるいは、この方がより真実に近いのだろうが、 *quod tantas tempestates Oceani tantosque impetus ventorum sustineri **<ruby><rb>[[w:オーケアノス|大洋]]〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>のあれほどの嵐や、風のあれほどの激しさに持ち応えること、 *ac tanta onera navium regi **船のあれほどの重さを制御することは、 *[[wikt:en:velum#Latin|velis]] non satis commode posse arbitrabantur. **<ruby><rb>帆　布</rb><rp>（</rp><rt>ウェールム</rt><rp>）</rp></ruby>にとって十分に具合良くできないと、<span style="color:#009900;">（ウェネティー族は）</span>考えていたためであろう。 <br><br> ;　　ウェネティー船団とローマ艦隊の優劣 *Cum his navibus nostrae classi eiusmodi congressus erat, **彼ら<span style="color:#009900;">〔ウェネティー族〕</span>の船団と、我が方<span style="color:#009900;">〔ローマ軍〕</span>の艦隊は、以下のように交戦していた。 *ut una celeritate et pulsu remorum praestaret, **迅速さと<ruby><rb>[[w:櫂|櫂]](かい)</rb><rp>（</rp><rt>レームス</rt><rp>）</rp></ruby>を<ruby><rb>漕</rb><rp>（</rp><rt>こ</rt><rp>）</rp></ruby>ぐのだけは<span style="color:#009900;">（ローマ艦隊が）</span>よりまさっていたのだが、 *reliqua pro loci natura, pro vi tempestatum **そのほかのことは、地勢や嵐の勢いを考慮すると、 *illis essent aptiora et adcommodatiora. **彼ら<span style="color:#009900;">〔ウェネティー族〕</span>にとってより適しており、より好都合であった。 *Neque enim his nostrae rostro nocere poterant **なぜなら、我が方<span style="color:#009900;">〔ローマ艦隊〕</span>の<ruby><rb>[[w:衝角|衝　　角]]</rb><rp>（</rp><rt>ローストルム</rt><rp>）</rp></ruby>によって彼ら<span style="color:#009900;">（の船）</span>に対して損壊することができず、 *── tanta in iis erat firmitudo ──, **──それら<span style="color:#009900;">〔ウェネティー族の船〕</span>においては<span style="color:#009900;">（船体の）</span>それほどの頑丈さがあったのだが── *neque propter altitudinem facile telum adigebatur, **<span style="color:#009900;">（ウェネティー族の船体の）</span>高さのゆえに、飛道具がたやすく投げ込まれなかったし、 *et eadem de causa minus commode <u>[[wikt:en:copula#Latin|copulis]]</u> continebantur. **同じ理由から、あまり都合よく <ruby><rb><u>[[w:鉤縄|鉤縄]]</u></rb><rp>（</rp><rt>かぎなわ</rt><rp>）</rp></ruby> で<span style="color:#009900;">（敵船が）</span>つなぎ止められなかった。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：下線部は、古い写本では [[wikt:en:scopulus#Latin|scopulis]]「岩礁」だが、<br>　　　　後代の写本で修正され「[[w:鉤縄|鉤縄]]」と解釈されている。下図参照。）</span> <div style="background-color:#eee; width:350px; text-align:center"> {| |- | style="vertical-align:bottom;" |[[画像:Grappling hook 2 (PSF).png|thumb|right|410px|[[w:海戦|海戦]]において敵船に[[w:移乗攻撃|接舷]]するために用いられていた、多数の<ruby><rb>[[w:鉤|鉤]]</rb><rp>（</rp><rt>かぎ</rt><rp>）</rp></ruby>を備えた<ruby><rb>[[w:銛|銛]]</rb><rp>（</rp><rt>もり</rt><rp>）</rp></ruby>の一種（<small>英語 [[wikt:en:grappling hook|grappling hook]]</small>）。<hr>[[内乱記_第1巻#57節|『内乱記』第1巻57節]]、[[内乱記_第2巻#6節|第2巻6節]]においても、[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|D.ブルートゥス]]による'''[[内乱記/マッシリアについて|マッシリア攻囲]]'''の海戦の場面で、同様の鉤について言及される。]] |} </div> *Accedebat ut, **さらに加えて、 *cum <span style="color:#009900;">[</span>saevire ventus coepisset et<span style="color:#009900;">]</span> se vento dedissent, **<span style="color:#009900;">[</span>風が荒々しく吹き始めて<span style="color:#009900;">]</span> 風に身を委ねて<span style="color:#009900;">（航行して）</span>いたときに、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：&beta;系写本では [　　] 部分を欠く。）</span> *et tempestatem ferrent facilius **<span style="color:#009900;">（ウェネティー族の船団は）</span>嵐により容易に耐えていたし、 *et in vadis consisterent tutius **浅瀬により安全に停留して、 *et ab aestu relictae **潮に取り残されても、 *nihil saxa et [[wikt:en:cautes#Latin|cautes]] timerent; **岩石やごつごつした石を何ら恐れることがなかった。 *quarum rerum omnium nostris navibus casus erant extimescendi. **それらのすべての事が、我が<span style="color:#009900;">〔ローマ人の〕</span>船団にとっては、恐怖すべき危険であったのだ。 **:<span style="color:#009900;">（訳注：ウェネティー族の船は[[w:竜骨 (船)|竜骨]]がローマ人の船より平たいため、<br>　　　　浅瀬や引き潮を容易に持ち応えられた。本節の冒頭を参照。）</span> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===14節=== *<span style="background-color:#ffd;">[[/注解/14節]]　{{進捗|00%|2022-07-17}}</span> '''カエサル待望のブルートゥスの艦隊が来航し、ウェネティー族との海戦が始まる''' *Compluribus expugnatis oppidis **いくつもの<span style="color:#009900;">（ウェネティー族の）</span><ruby><rb>[[w:オッピドゥム|城塞都市]]</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>が攻略されると、 *Caesar <u>ubi intellexit</u> frustra tantum laborem sumi **カエサルは、これほどの労苦が徒労になること（を知り）、 *neque hostium fugam captis oppidis reprimi **（すなわち）<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>が占領されても、敵の逃亡が妨げられないし、 *neque iis noceri posse, **彼ら<span style="color:#009900;">〔ウェネティー族〕</span>に損害が与えられることも不可能である<u>と知るや否や</u>、 *statuit exspectandam classem. **[[w:ローマ海軍|艦隊]]<span style="color:#009900;">（の到着）</span>を待つことを決意した。 **:<span style="color:#009900;">（訳注：ローマの軍船がリゲル川〔[[w:ロワール川|ロワール川]]〕で建造されていることが[[#9節|9節]]で述べられた。）</span> <br> ;　　ローマ艦隊が来航すると、約220隻のウェネティー船団が迎え撃とうとする *Quae ubi convenit ac primum ab hostibus visa est, **これら<span style="color:#009900;">〔ローマ艦隊〕</span>が集結して敵方により目撃されるや否や、 *circiter CCXX(ducentae viginti) naves eorum paratissimae **約220隻の彼ら<span style="color:#009900;">〔ウェネティー族〕</span>の船団が準備を整え、 *atque omni genere armorum ornatissimae **あらゆる種類の武器が完備された状態で *ex portu profectae nostris adversae constiterunt; **港から出航して、我が方<span style="color:#009900;">〔ローマ艦隊〕</span>と向かい合って布陣した。 <div style="text-align:center"> {| |- |[[画像:Bataille Morbihan -56.png|thumb|right|600px|[[w:紀元前56年|BC56年]]に現在の[[w:モルビアン県|モルビアン県]]沿いの[[w:キブロン湾|キブロン湾]]で戦われたと考えられている、[[w:ウェネティ族 (ガリア)|ウェネティー族]]と[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|D. ブルートゥス]]率いる艦隊との海戦、いわゆる「[[w:モルビアン湾の海戦|モルビアン湾の海戦]]」の海戦図。<hr>上図の説では、<span style="color:green;">ウェネティー族の帆船(緑色/約220隻)</span>と<span style="color:red;">ブルートゥス率いるローマのガレー船(赤色/約100隻)</span>が[[w:キブロン湾|キブロン湾]]で対峙し、<span style="color:red;">カエサルと1個軍団(赤色)</span>が沿岸を占領している。]] |} </div> *neque satis [[wikt:en:Brutus#Latin|Bruto]], qui classi praeerat, **艦隊を指揮していた[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|ブルートゥス]]には十分（明らか）ではなかった。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：デキムス・ブルートゥス [[w:la:Decimus Iunius Brutus Albinus|Decimus Brutus]] に艦隊を指揮させることが[[#11節|11節]]で述べられた。）</span> *vel tribunis militum centurionibusque, quibus singulae naves erant attributae, **あるいは、個々の船が割り当てられていた <ruby><rb>[[w:トリブヌス・ミリトゥム|兵士長官]]</rb><rp>（</rp><rt>トリブヌス・ミリトゥム</rt><rp>）</rp></ruby> や <ruby><rb>[[w:ケントゥリオ|百人隊長]]</rb><rp>（</rp><rt>ケントゥリオー</rt><rp>）</rp></ruby> にとってさえも、 *constabat quid agerent aut quam rationem pugnae insisterent. **何をすべきなのか、どのような戦法を採るべきなのか、明らかではなかった。 *[[wikt:en:rostrum#Latin|Rostro]] enim noceri non posse cognoverant; **なぜなら、<ruby><rb>[[w:衝角|衝　角]]</rb><rp>（</rp><rt>ローストルム</rt><rp>）</rp></ruby>にとって<span style="color:#009900;">（敵船に）</span>損害を与えることができないことを知っていたからだ。 **:<span style="color:#009900;">（訳注：[[#13節|前節]]で、ウェネティー族の船体が頑丈であるため、と述べられた。）</span> *turribus autem excitatis tamen has altitudo [[wikt:en:puppis#Latin|puppium]] ex barbaris navibus superabat, **他方で、[[w:櫓|櫓]]が築かれたにもかかわらず、蛮族の船の <ruby><rb>[[w:船尾|船尾]]</rb><rp>（</rp><rt>プッピス</rt><rp>）</rp></ruby> の高さがそれら（の高さ）を上回っていた。 **:<span style="color:#009900;">（訳注：ローマの軍船の甲板上には、投槍などの飛道具を投げるために櫓が設けられていた。）</span> *ut neque ex inferiore loco satis commode [[wikt:en:telum#Latin|tela]] adigi possent **その結果、より低い場所から十分に具合良く<span style="color:#009900;">（敵船に）</span><ruby><rb>[[w:飛び道具|飛道具]]</rb><rp>（</rp><rt>テールム</rt><rp>）</rp></ruby>が投げ込まれることは不可能で、 *et missa a Gallis gravius acciderent. **ガッリア人により放られたものがより激しく降ってきていた。 <br> ;　　ローマ艦隊の切り札 *Una erat magno usui res praeparata a nostris, **ただ一つの大いに役立つ物が、我が方<span style="color:#009900;">〔ローマ艦隊〕</span>によって準備されていた。 *[[wikt:en:falx#Latin|falces]] praeacutae insertae adfixaeque [[wikt:en:longurius#Latin|longuriis]], **<span style="color:#009900;">（それは）</span>先の尖った[[w:鎌|鎌]]が <ruby><rb>長い竿</rb><rp>（</rp><rt>ロングリウス</rt><rp>）</rp></ruby> に挿入されて固定されたもので、 *non absimili forma muralium falcium. **<ruby><rb><span style="color:#009900;">(攻城用の)</span>破城の鎌</rb><rp>（</rp><rt>ファルクス・ムーラーリス</rt><rp>）</rp></ruby> に形が似ていなくもない。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：「破城の鎌」'''[[古代ローマの攻城兵器#falx_muralis_(siege_hook)|falx muralis]]''' に似たもので、'''[[ガイウス・ユリウス・カエサルの著作/古代ローマの攻城兵器#falx_navalis|falx navalis]]''' とも呼ばれている。）</span> <div style="text-align:center"> {| |- |[[画像:Caesar's Gallic war; (Allen and Greenough's ed.) (1898) (14778300381)(cropped).jpg|thumb|right|300px|破城鎌の復元画の例]] |[[画像:Ulysse bateau.jpg|thumb|right|320px|帆柱・帆桁や帆・綱具などが描かれたローマ時代の[[w:モザイク|モザイク画]]<ref>[[w:en:Roman mosaic]]</ref>《[[w:オデュッセウス|オデュッセウス]]と[[w:セイレーン|セイレーン]]》<br>（[[w:チュニス|チュニス]]の[[w:バルド国立博物館|バルド国立博物館]]）]] |} </div> *His cum [[wikt:en:funis#Latin|funes]] qui [[wikt:en:antemna#Latin|antemnas]] ad [[wikt:en:malus#Etymology_3_2|malos]] destinabant, comprehensi adductique erant, **これにより、<ruby><rb>帆　桁</rb><rp>（</rp><rt>アンテムナ</rt><rp>）</rp></ruby> を <ruby><rb>[[w:マスト|帆　柱]]</rb><rp>（</rp><rt>マールス</rt><rp>）</rp></ruby> に結びつけていた <ruby><rb>綱具</rb><rp>（</rp><rt>フーニス</rt><rp>）</rp></ruby> にひっかけて引っ張るたびに、 *navigio remis incitato praerumpebantur. **[[w:櫂|櫂]]によってすばやく航行すると、（帆綱は）引きちぎられた。 *Quibus abscisis antemnae necessario concidebant, **これら<span style="color:#009900;">〔帆綱〕</span>が切れると、<ruby><rb>帆　桁</rb><rp>（</rp><rt>アンテムナ</rt><rp>）</rp></ruby> は必然的に倒れて、 *ut, cum omnis Gallicis navibus spes in velis armamentisque consisteret, **その結果、ガリア人のすべての船にとって、期待は帆と[[w:索具|索具]]に基づいていたので、 *his ereptis omnis usus navium uno tempore eriperetur. **これをちぎり取られて、船の運用（能力）も奪い取られた。 *Reliquum erat certamen positum in virtute, qua nostri milites facile superabant, **残りの争闘は武勇いかんにかかっており、我が方<span style="color:#009900;">〔ローマ勢〕</span>の兵士がはるかに上回った。 <br> ;　　沿岸はカエサルとローマ軍によって占領されていた *atque eo magis quod in conspectu Caesaris atque omnis exercitus res gerebatur, **カエサルと全軍の眺望の中で、それだけ大きく、事（戦闘）が遂行されたので、 *ut nullum paulo fortius factum latere posset; **どんな力強い動作も知られずにいることができないほどであった。 *omnes enim colles ac loca superiora, unde erat propinquus despectus in mare, ab exercitu tenebantur. **なぜなら、そこから間近に海を見下ろすすべての丘とより高い場所は、<span style="color:#009900;">（ローマ人の）</span>軍隊によって占領されていたのである。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===15節=== '''海戦が終わる''' *Deiectis, ut diximus, antemnis, **上述したように帆桁がぶっ倒れて、 *cum singulas binae ac ternae naves circumsteterant, **（ウェネティー族の船）1艘ずつを（ローマの）2艘ずつや3艘ずつの船が攻囲して、 *milites summa vi transcendere in hostium naves contendebant. **（ローマの）兵士たちは最高の力で敵の船に乗り移ることに努めた。 *Quod postquam barbari fieri animadverterunt, **そのことが行なわれていると蛮族が気づいた後で、 *expugnatis compluribus navibus, **いくつもの（ウェネティー族の）船が攻略されて、 *cum ei rei nullum reperiretur auxilium, **この事態に対して何ら助けを見出せなかったので、 *fuga salutem petere contenderunt. **逃亡に身の安全を求めることに努めた。 *Ac iam conversis in eam partem navibus quo ventus ferebat, **ちょうど風が運んでいた方角へ船の向きを変えたが、 *tanta subito malacia ac tranquillitas exstitit, **突然に大きく[[w:凪|凪]]や静けさが生じて、 *ut se ex loco movere non possent. **（ウェネティー族が）その場所から動くことができないほどであった。 *Quae quidem res ad negotium conficiendum maximae fuit oportunitati: **このような事態はまさに仕事（軍務）を遂行するのに最大の機会であった。 *nam singulas nostri consectati expugnaverunt, **というのも（敵船）1つずつを我が方が追跡して攻略して、 *ut perpaucae ex omni numero noctis interventu ad terram pervenirent, **その結果、総勢のうちから非常にわずかな数の者たちが、夜のとばりに包まれて、陸地に達したのだ。 *cum ab hora fere IIII{quarta}. usque ad solis occasum pugnaretur. **なぜなら（海戦が）ほぼ第四時から日が没するまで絶えず戦われたからだ。 **:（訳注：第四時は、古代ローマの不定時法で、午前9時～10時頃と思われる。） ===16節=== '''ウェネティー族の行末''' *Quo proelio bellum Venetorum totiusque orae maritimae confectum est. **以上の戦闘で、[[w:ウェネティ族 (ガリア)|ウェネティー族]]およびすべての沿岸住民との戦争が完遂された。 *Nam cum omnis iuventus, omnes etiam gravioris aetatis, **なぜなら、すべての青年とすべての年嵩の者さえも、 *in quibus aliquid consilii aut dignitatis fuit eo convenerant, **何らかの見識や品位のあった者たちは、そこ（戦場）へ集まっていたからだ。 *tum navium quod ubique fuerat in unum locum coegerant; **そのとき、至る所にあった船が一つの場所に集められていたのだ。 *quibus amissis reliqui neque quo se reciperent neque quemadmodum oppida defenderent habebant. **以上のものを喪失して、残存者たちは、どこへ退くかも、どんな方法で城市を防衛するかもわからなかった。 *Itaque se suaque omnia Caesari dediderunt. **こうして、彼らとそのすべてのものをカエサルに委ねた（降伏した）。 *In quos eo gravius Caesar vindicandum statuit **これらのものを、カエサルはより厳重に処罰すると決定した。 *quo diligentius in reliquum tempus a barbaris ius legatorum conservaretur. **将来、蛮族により（ローマの）使節の権利をいっそう保たせるように。 *Itaque omni senatu necato reliquos sub corona vendidit. **こうして、すべての長老を殺害して、残りの者たちを奴隷として売却した。 **（訳注：sub corona vendere；葉冠のもとに売る＝奴隷として売る） ==大西洋岸ウネッリ族の造反== ===17節=== [[画像:Campagne Unelles -56.png|thumb|right|200px|ウネッリ族・レクソウィイ族への遠征経路。]] '''ウネッリ族の反乱とサビヌスの作戦''' *Dum haec in Venetis geruntur, **以上のことが[[w:ウェネティ族 (ガリア)|ウェネティー族]]（の領国）で行なわれていた間に、 *Q. Titurius Sabinus cum iis copiis, quas a Caesare acceperat **[[w:クィントゥス・ティトゥリウス・サビヌス|クィントゥス・ティトゥリウス・サビヌス]]は、カエサルから受け取った軍勢とともに *in fines Unellorum{Venellorum} pervenit. **[[w:ウネッリ族|ウネッリ族]]の領土に到着した。 *His praeerat Viridovix ac summam imperii tenebat earum omnium civitatum, quae defecerant, **彼ら（ウネッリ族）を指揮していたのは[[w:ウィリドウィクス|ウィリドウィクス]]で、背反した全部族の最高指揮権を保持していた。 *ex quibus exercitum [magnasque copias] coegerat; **（彼は）これら（の部族）から大軍勢を徴集した。 *atque his paucis diebus Aulerci Eburovices Lexoviique, **それから数日内に、[[w:アウレルキ族|アウレルキ族]]、[[w:エブロウィケス族|エブロウィケス族]]と[[w:レクソウィー族|レクソウィイ族]]は、 *senatu suo interfecto, quod auctores belli esse nolebant, **自分たちの長老たちを、戦争の首謀者になることを欲しなかったという理由で殺害し、 *portas clauserunt seseque cum Viridovice coniunxerunt; **（城市の）門を閉じて、彼らはウィリドウィクスと結託した。 *magnaque praeterea multitudo undique ex Gallia perditorum hominum latronumque convenerat, **そのうえにガリアの至る所から大勢の無頼漢や略奪者が集まっていた。 *quos spes praedandi studiumque bellandi ab agri cultura et cotidiano labore revocabat. **これらの者たちを、略奪への期待と戦争への熱望が、農耕や毎日の仕事から呼び戻したのだ。 *Sabinus idoneo omnibus rebus loco castris se tenebat, **サビヌスはすべての事柄において適切な場所で、陣営を保持した。 *cum Viridovix contra eum duorum milium spatio consedisset **ウィリドウィクスは彼に対抗して2[[w:ローママイル|ローママイル]]（約3km）の間隔で陣取って、 *cotidieque productis copiis pugnandi potestatem faceret, **毎日、軍勢を連れ出して戦闘の機会を作った。 *ut iam non solum hostibus in contemptionem Sabinus veniret, **その結果ついに、敵からサビヌスが軽蔑されるに至ったのみならず、 *sed etiam nostrorum militum vocibus nonnihil carperetur; **我が方（ローマ）の兵士からも若干の者が声に出して嘲弄するに至った。 *tantamque opinionem timoris praebuit, **これほどの恐れの評判を呈したので、 *ut iam ad vallum castrorum hostes accedere auderent. **ついに陣営の堡塁のところにまで敵が敢えて近づいて来るほどであった。 *Id ea de causa faciebat **（サビヌスは）以上のことを以下の理由でしたのである。 *quod cum tanta multitudine hostium, **というのも、このような大がかりな敵とともに、 *praesertim eo absente qui summam imperii teneret, **とりわけ、（ローマ側の）最高指揮権を保持する者（=カエサル）がおらずに、 *nisi aequo loco aut opportunitate aliqua data **有利な場所か何らかの機会が与えられなければ、 *legato dimicandum non existimabat. **総督副官（[[w:レガトゥス|レガトゥス]]）にとって戦うべきとは考えなかったのである。 ===18節=== '''サビヌスの計略''' *Hac confirmata opinione timoris **このような恐れの評判が強められて、 *idoneum quendam hominem et callidum delegit Gallum, **（サビヌスは）適切で明敏なガリア人のある男を選び出した。 *ex iis quos auxilii causa secum habebat. **支援軍（[[w:アウクシリア|アウクシリア]]）のために保持していた者たちの内から。 *Huic magnis praemiis pollicitationibusque persuadet uti ad hostes transeat, **この者を、多大なほうびを約束して、敵側に渡るように説得して、 *et quid fieri velit edocet. **（サビヌスが）なされんと欲することを説き教えた。 *Qui ubi pro perfuga ad eos venit, timorem Romanorum proponit, **その者は、逃亡兵として彼ら（ウネッリ族）のところへ来るや否や、ローマ人の恐れを申し述べた。 *quibus angustiis ipse Caesar a Venetis prematur docet, **いかなる困窮で、カエサル自身が[[w:ウェネティ族 (ガリア)|ウェネティー族]]により苦戦させられているかを教えた。 *neque longius abesse, quin proxima nocte **遠からず、明晩には *Sabinus clam ex castris exercitum educat **サビヌスはひそかに陣営から軍隊を導き出して、 *et ad Caesarem auxilii ferendi causa proficiscatur. **カエサルのところへ支援をもたらすために出発するであろう（とその男は教えた）。 *Quod ubi auditum est, conclamant **このことが聞かれるや否や、（ウネッリ族の者たちは）叫び声を上げて、 *omnes occasionem negotii bene gerendi amittendam non esse: ad castra iri oportere. **うまく仕事をするすべての機会を失うべきではない、（ローマの）陣営へ行かねばならぬ（と叫んだ）。 *Multae res ad hoc consilium Gallos hortabantur: **多くの事柄が、この計画へとガリア人を励ました。 **（それらの事柄とは、以下のことである。） *superiorum dierum Sabini cunctatio, **最近の日々のサビヌスのためらい、 *perfugae confirmatio, **脱走兵の確証、 *inopia cibariorum, cui rei parum diligenter ab iis erat provisum, **彼ら（ガリア人）によって充分に入念に調達されなかった糧食の欠乏、 *spes Venetici belli, **[[w:ウェネティ族 (ガリア)|ウェネティー族]]の戦争への希望、 *et quod fere libenter homines id quod volunt credunt. **というのも、たいてい人間は（自分が）欲することを喜んで信ずるからである。 *His rebus adducti non prius Viridovicem reliquosque duces ex concilio dimittunt, **これらの事態に引かれて、（ウネッリ族は）ウィリドウィクスや他の指導者を会議から解散させなかった。 *quam ab his sit concessum arma uti capiant et ad castra contendant. **彼らによって、武器を取って（ローマ）陣営へ急行するように容認されるまでは。 *Qua re concessa laeti, ut explorata victoria, **この事が容認されて、勝利が得られたかのように喜んで、 *sarmentis virgultisque collectis, quibus fossas Romanorum compleant, ad castra pergunt. **柴や薮を集めて、これでもってローマ人の堀を埋めるべく、（ローマの）陣営のところへ出発した。 ===19節=== '''ウネッリ族らとの決戦''' *Locus erat castrorum editus et paulatim ab imo acclivis circiter passus mille. **ローマ陣営の位置は高く、最も下（麓）から緩やかな上り坂で約1000[[w:パッスス|パッスス]]（約1.5km）のところにあった。 *Huc magno cursu contenderunt, ここへ、大いに駆けて急いで、 *ut quam minimum spatii ad se colligendos armandosque Romanis daretur, **ローマ人にとって集結して武装するための時間ができるだけ与えられないようにして、 *exanimatique pervenerunt. **息を切らして到着した。 *Sabinus suos hortatus cupientibus signum dat. **サビヌスは、自分の部下たちを励まして、はやる者たちに合図を与える。 *Impeditis hostibus propter ea quae ferebant onera, **敵は、彼らが担いでいた重荷のために妨げられていて、 *subito duabus portis eruptionem fieri iubet. **（サビヌスは）突然に（左右の）二つの門から出撃することを命じた。 *Factum est **（ut以下のことが）なされた。 *opportunitate loci, hostium inscientia ac defatigatione, **場所の有利さ、敵の（武具や戦術の）不案内と疲労や、 *virtute militum et superiorum pugnarum exercitatione, **兵士の武勇とかつての戦闘の熟練によって *ut ne primum quidem nostrorum impetum ferrent ac statim terga verterent. **我が方（ローマ）の最初の襲撃さえ持ちこたえることなく、（敵は）すぐに背を向けた。 *Quos impeditos integris viribus milites nostri consecuti **これらの妨げられている者たちを、健全な力で我が方の兵士たちが追跡して、 *magnum numerum eorum occiderunt; **彼らの大多数を殺戮した。 *reliquos equites consectati paucos, qui ex fuga evaserant, reliquerunt. **残りの者たちは、（ローマの）騎兵が追跡したが、逃亡によって逃れたので、見逃した。 *Sic uno tempore et de navali pugna Sabinus et de Sabini victoria Caesar est certior factus, **このようにして一度に、海戦についてサビヌスが、サビヌスの勝利についてカエサルが、報告を受けて、 *civitatesque omnes se statim Titurio dediderunt. **（敵の）全部族がすぐにティトゥリウス（・サビヌス）に降伏した。 *Nam ut ad bella suscipienda Gallorum alacer ac promptus est animus, **こうなったのは、ガリア人は戦争を実行することについては性急で、心は敏捷であるが、 *sic mollis ac minime resistens ad calamitates ferendas mens eorum est. **と同様に柔弱で、災難に耐えるには彼らの心はあまり抵抗しないためである。 ==クラッススのアクィタニア遠征== ===20節=== [[画像:Campagne Aquitains -56.png|thumb|right|200px|クラッススのアウィタニア遠征の経路。]] '''クラッススのアクィタニア遠征、ソティアテス族''' *Eodem fere tempore P. Crassus, cum in Aquitaniam pervenisset, **ほぼ同じ時期に[[w:プブリウス・リキニウス・クラッスス|プブリウス・クラッスス]]が[[w:アクィタニア|アクィタニア]]に達したときに、 *quae pars, ut ante dictum est, et regionum latitudine et multitudine hominum **この方面は、前述のように、領域の広さと人間の多さで *ex tertia parte Galliae est aestimanda, **[[w:ガリア|ガリア]]の第三の部分であると考えられるべきであるが、 *cum intellegeret in illis locis sibi bellum gerendum, **（クラッススは）かの場所で自らにとって戦争がなされるべきであると考えたので、 *ubi paucis ante annis L. Valerius Praeconinus legatus exercitu pulso interfectus esset **そこでほんの数年前に[[w:ルキウス・ウァレリウス・プラエコニヌス|ルキウス・ウァレリウス・プラエコニヌス]]総督副官（[[w:レガトゥス|レガトゥス]]）が軍隊を撃退されて殺害されており、 *atque unde L. Manlius proconsul impedimentis amissis profugisset, **かつここから[[w:ルキウス・マンリウス・トルクァトゥス|ルキウス・マンリウス]]執政官代理（[[w:プロコンスル|プロコンスル]]）が輜重を失って敗走しており、 *non mediocrem sibi diligentiam adhibendam intellegebat. **己にとって尋常ならざる注意深さが適用されるべきだと考えたのだ。 *Itaque re frumentaria provisa, auxiliis equitatuque comparato, **こうして糧食が調達され、支援軍（[[w:アウクシリア|アウクシリア]]）や[[w:騎兵|騎兵隊]]が整備され、 *multis praeterea viris fortibus Tolosa et Carcasone et Narbone, **そのうえ多くの屈強な男たちが、[[w:トロサ|トロサ]]や[[w:カルカソ|カルカソ]]や[[w:ナルボ|ナルボ]]から *－ quae sunt civitates Galliae provinciae finitimae, ex his regionibus－ **＜それらは、この地域に隣接する（ローマの）ガリア属州（[[w:ガリア・ナルボネンシス|ガリア・トランサルピナ]]）の都市であるが、＞ *nominatim evocatis, in Sotiatium fines exercitum introduxit. **名指しで徴集されて、（クラッススは）[[w:ソティアテス族|ソティアテス族]]の領土に軍隊を導き入れた。 *Cuius adventu cognito Sotiates magnis copiis coactis, **彼（クラッスス）の到着を知ると、ソティアテス族は大軍勢を集めて、 *equitatuque, quo plurimum valebant, in itinere agmen nostrum adorti **それにより彼らが大いに力があったところの騎兵隊で、行軍中の我が（ローマの）隊列を襲って、 *primum equestre proelium commiserunt, **はじめに騎兵戦を戦った。 *deinde equitatu suo pulso atque insequentibus nostris **それから、その（敵の）騎兵隊が撃退され、我が方が追跡したが、 *subito pedestres copias, quas in convalle in insidiis conlocaverant, ostenderunt. **突然に歩兵の軍勢　＜[[w:峡谷|峡谷]]の中で[[w:伏兵|伏兵]]として配置していた者たち＞　が現われた。 *Iis nostros disiectos adorti proelium renovarunt. **これらによって追い散らされた我が方（ローマ軍）に襲いかかり、戦いを再び始めた。 ===21節=== '''ソティアテス族の敗勢''' *Pugnatum est diu atque acriter, **長く激しく戦われた。 *cum Sotiates superioribus victoriis freti **というのもソティアテス族は、かつての（ローマ軍に対する）勝利を信頼しており、 *in sua virtute totius Aquitaniae salutem positam putarent, **自分たちの武勇の中に全アクィタニアの安全が立脚していると、みなしていたからだ。 *nostri autem, **我が方（ローマ軍）はそれに対して *quid sine imperatore et sine reliquis legionibus adulescentulo duce efficere possent, **最高司令官（[[w:インペラトル|インペラトル]]）なし、他の[[w:ローマ軍団|軍団]]もなしに、この若造（クラッスス）が指揮官として何をなしうるかが *perspici cuperent; **注視（吟味）されることを欲していたのだ。 *tandem confecti vulneribus hostes terga verterunt. **ついに傷を負って、敵は背を向けた。 *Quorum magno numero interfecto **これらの者の大多数を殺戮し、 *Crassus ex itinere oppidum Sotiatium oppugnare coepit. **クラッススは行軍からただちにソティアテス族の[[w:オッピドゥム|城市]]を攻撃し始めた。 *Quibus fortiter resistentibus vineas turresque egit. **これらの者たちが勇敢に抵抗したので、（ローマ勢は）工作小屋（[[w:ウィネア|ウィネア]]）や[[w:櫓|櫓]]を（城の方に）導いた。 *Illi alias eruptione temptata, alias cuniculis ad aggerem vineasque actis **彼ら（アクィタニア人）は、あるときは突撃を試みて、あるときは[[w:坑道|坑道]]を[[w:土塁|土塁]]や工作小屋のところへ導いた。 *－ cuius rei sunt longe peritissimi Aquitani, **＜こういった事柄（坑道の技術）に、アクィタニア人は長らく非常に熟練している。 *propterea quod multis locis apud eos aerariae secturaeque sunt －, **これは、彼らのもとの多くの場所に[[w:銅山|銅山]]や[[w:採石所|採石所]]があることのためである。＞ *ubi diligentia nostrorum nihil his rebus profici posse intellexerunt, **我が方の注意深さによってこのような事柄によっても何ら得られぬと考えるや否や、 *legatos ad Crassum mittunt, seque in deditionem ut recipiat petunt. **（ソティアテス族は）使節をクラッススのところへ送って、自分たちを降伏へと受け入れるように求める。 *Qua re impetrata arma tradere iussi faciunt. **この事が達せられ、武器の引渡しが命じられ、実行された。 ===22節=== '''アディアトゥアヌスと従僕たちの突撃''' *Atque in ea re omnium nostrorum intentis animis **この事柄に我が方（ローマ勢）の皆が心から没頭しており、 *alia ex parte oppidi Adiatuanus, qui summam imperii tenebat, **城市の他の方面から、最高指揮権を保持していた[[w:アディアトゥアヌス|アディアトゥアヌス]]が *cum DC{sescentis} devotis, quos illi{Galli} soldurios appellant, **ガリア人がソルドゥリイ（従僕）と呼んでいる600名の忠実な者とともに（突撃を試みた）。 '''アディアトゥアヌスの従僕たち''' *－ quorum haec est condicio, **＜　これらの者たちの状況は以下の通りであった。 *uti omnibus in vita commodis una cum iis fruantur quorum se amicitiae dediderint, **人生におけるあらゆる恩恵を、忠心に身を捧げる者たちと一緒に享受する。 *si quid his per vim accidat, aut eundem casum una ferant aut sibi mortem consciscant; **もし彼らに何か暴力沙汰が起こったら、同じ運命に一緒に耐えるか、自らに死を引き受ける（自殺する）。 *neque adhuc hominum memoria repertus est quisquam qui, **これまで、次のような人の記憶は見出されていない。 *eo interfecto, cuius se amicitiae devovisset, mortem recusaret － **忠心に身を捧げる者が殺されても死を拒む（ような者）　＞ *cum his Adiatuanus eruptionem facere conatus **これらの者（従僕）とともにアディアトゥアヌスは突撃することを試みた。 '''アディアトゥアヌスの敗退''' *clamore ab ea parte munitionis sublato **堡塁のその方面から叫び声が上げられて、 *cum ad arma milites concurrissent vehementerque ibi pugnatum esset, **武器のところへ（ローマの）兵士たちが急ぎ集まった後に、そこで激しく戦われた。 *repulsus in oppidum **（アディアトゥアヌスたちは）城市の中に撃退され、 *tamen uti eadem deditionis condicione uteretur a Crasso impetravit. **しかし（前と）同じ降伏条件を用いるように、クラッススを説得した。 ===23節=== '''ウォカテス族・タルサテス族対クラッスス''' *Armis obsidibusque acceptis, Crassus in fines Vocatium et Tarusatium profectus est. **武器と人質を受け取って、クラッススは[[w:ウォカテス族|ウォカテス族]]と[[w:タルサテス族|タルサテス族]]の領土に出発した。 *Tum vero barbari commoti, **そのとき確かに蛮族たちは動揺させられて、 *quod oppidum et natura loci et manu munitum **というのも、地勢と部隊で防備された（ソティアテス族の）城市が *paucis diebus quibus eo ventum erat, expugnatum cognoverant, **（ローマ人が）そこへ来てからわずかな日数で攻め落とされたことを知っていたためであるが、 *legatos quoque versus dimittere, **使節たちをあらゆる方面に向けて送り出し、 *coniurare, obsides inter se dare, copias parare coeperunt. **共謀して、互いに人質を与え合って、軍勢を準備し始めた。 *Mittuntur etiam ad eas civitates legati quae sunt citerioris Hispaniae finitimae Aquitaniae: **アクィタニアに隣接する[[w:上ヒスパニア|上ヒスパニア]]（[[w:en:Hispania Citerior|Hispania Citerior]]）にいる部族たちにさえ、使節が派遣された。 [[画像:Hispania_1a_division_provincial.PNG|thumb|250px|right|BC197年頃のヒスパニア。オレンジ色の地域が当時の上ヒスパニア]] [[画像:Ethnographic Iberia 200 BCE.PNG|thumb|right|250px|BC200年頃のイベリア半島の民族分布。朱色の部分に[[w:アクィタニア人|アクィタニア人]]の諸部族が居住していた。]] *inde auxilia ducesque arcessuntur. **そこから援兵と指揮官が呼び寄せられた。 *Quorum adventu **これらの者が到着して、 *magna cum auctoritate et magna [cum] hominum multitudine **大きな権威と大勢の人間とともに、 *bellum gerere conantur. **戦争遂行を企てた。 *Duces vero ii deliguntur **指揮官には確かに（以下の者たちが）選ばれた。 *qui una cum Q. Sertorio omnes annos fuerant **皆が多年の間、[[w:クィントゥス・セルトリウス|クィントゥス・セルトリウス]]（[[w:la:Quintus Sertorius|Quintus Sertorius]]）と一緒にいて、 *summamque scientiam rei militaris habere existimabantur. **軍事の最高の知識を有すると考えられていた（者たちである）。 **（訳注：セルトリウスは、[[w:ルキウス・コルネリウス・スッラ|スッラ]]の独裁に抵抗したローマ人の武将である。[[w:ヒスパニア|ヒスパニア]]の住民にローマ軍の戦術を教えて共和政ローマに対して反乱を起こしたが、[[w:グナエウス・ポンペイウス|ポンペイウス]]によって鎮圧された。） *Hi consuetudine populi Romani loca capere, **これらの者たちは、ローマ人民の習慣によって、場所を占領し、 *castra munire, **[[w:カストラ|陣営]]を防壁で守り、 *commeatibus nostros intercludere instituunt. **我が方（ローマ勢）の物資をさえぎることに決めたのだ。 *Quod ubi Crassus animadvertit, **クラッススは（以下の諸事情に）気づくや否や、（すなわち） *suas copias propter exiguitatem non facile diduci, **己の軍勢が寡兵であるために、展開するのが容易でないこと、 *hostem et vagari et vias obsidere et castris satis praesidii relinquere, **敵はうろつき回って道を遮断して、陣営に十分な守備兵を残していること、 *ob eam causam minus commode frumentum commeatumque sibi supportari, **その理由のために糧食や軍需品を都合良く自陣に持ち運べていないこと、 *in dies hostium numerum augeri, **日々に敵の数が増していること、（これらの諸事情に気づいたので） *non cunctandum existimavit quin pugna decertaret. **（クラッススは）戦闘で雌雄を決することをためらうべきではないと考えたのだ。 *Hac re ad consilium delata, ubi omnes idem sentire intellexit, **この事が会議に報告されて、皆が同じく考えていることを知るや否や、 *posterum diem pugnae constituit. **戦闘を翌日に決めた。 ===24節=== '''両軍の開戦準備''' *Prima luce productis omnibus copiis, **（クラッススは）夜明けに全軍勢を連れ出して、 *duplici acie instituta, **二重の戦列を整列し、 *auxiliis in mediam aciem coniectis, **支援軍（[[w:アウクシリア|アウクシリア]]）を戦列の中央部に集結し、 *quid hostes consilii caperent exspectabat. **敵がいかなる計略をとるのかを待った。 *Illi, **彼ら（アクィタニア人）は、 *etsi propter multitudinem et veterem belli gloriam paucitatemque nostrorum se tuto dimicaturos existimabant, **（自らの）多勢、昔の戦争の名誉、我が方（ローマ勢）の寡勢のために、安全に闘えると考えたにも拘らず、 *tamen tutius esse arbitrabantur obsessis viis commeatu intercluso sine ullo vulnere victoria potiri, **それでもより安全と思われるのは、道を包囲して[[w:兵站|兵站]]を遮断し、何ら傷なしに勝利をものにすることであり、 *et si propter inopiam rei frumentariae Romani se recipere coepissent, **もし糧食の欠乏のためにローマ人が退却し始めたならば、 *impeditos in agmine et sub sarcinis infirmiores **（ローマ人が）隊列において[[w:背嚢|背嚢]]を背負って妨げられて臆病になっているところを、 *aequo animo adoriri cogitabant. **平常心をもって襲いかかれると考えたのだ。 *Hoc consilio probato ab ducibus, productis Romanorum copiis, sese castris tenebant. **この計略が指揮官により承認されて、ローマ人の軍勢が進撃しても、彼らは陣営に留まった。 *Hac re perspecta Crassus, **この事を見通してクラッススは、 *cum sua cunctatione atque opinione timidiores hostes **（敵）自身のためらいや、評判より臆病な敵が *nostros milites alacriores ad pugnandum effecissent **我が方（ローマ）の兵士たちを戦うことにおいてやる気にさせたので、 *atque omnium voces audirentur exspectari diutius non oportere quin ad castra iretur, **かつ（敵の）陣営へ向かうことをこれ以上待つべきではないという皆の声が聞かれたので、 *cohortatus suos omnibus cupientibus ad hostium castra contendit. **部下を励まして、（戦いを）欲する皆で、敵の陣営へ急行した。 ===25節=== '''クラッスス、敵陣へ攻めかかる''' *Ibi cum alii fossas complerent, alii multis telis coniectis **そこで、ある者は堀を埋め、ある者は多くの飛道具を投げて、 *defensores vallo munitionibusque depellerent, **守備兵たちを[[w:防柵|防柵]]や[[w:防壁|防壁]]から駆逐した。 *auxiliaresque, quibus ad pugnam non multum Crassus confidebat, **[[w:アウクシリア|支援軍]]の者たちといえば、クラッススは彼らの戦いを大して信頼していなかったが、 *lapidibus telisque subministrandis et ad aggerem caespitibus comportandis **石や飛道具を供給したり、[[w:土塁|土塁]]のために[[w:芝|芝草]]を運んだり、 *speciem atque opinionem pugnantium praeberent, **戦っている様子や印象を示した。 *cum item ab hostibus constanter ac non timide pugnaretur **敵もまたしっかりと臆せずに戦って、 *telaque ex loco superiore missa non frustra acciderent, **より高い所から放られた飛道具は無駄なく落ちてきたので、 *equites circumitis hostium castris Crasso renuntiaverunt **[[w:騎兵|騎兵]]は、敵の陣営を巡察してクラッススに報告した。 *non eadem esse diligentia ab decumana porta castra munita **（敵の）陣営の後門（porta decumana）は（他の部分と）同じほどの入念さで防備されておらず、 *facilemque aditum habere. **容易に接近できると。 ===26節=== '''クラッスス、総攻撃をかける''' *Crassus equitum praefectos cohortatus, **クラッススは[[w:騎兵|騎兵]]の指揮官たちに促した。 *ut magnis praemiis pollicitationibusque suos excitarent, quid fieri velit ostendit. **大きな恩賞の約束で部下たちを駆り立てて、何がなされることを欲しているかを示すようにと。 *Illi, ut erat imperatum, **この者らは命じられたように、 *eductis iis cohortibus quae praesidio castris relictae intritae ab labore erant, **守備兵として陣営に残されていて、働きによって疲弊していなかった歩兵大隊（[[w:コホルス|コホルス]]）を連れ出して、 *et longiore itinere circumductis, ne ex hostium castris conspici possent, **敵の陣営から視認できないように、遠回りの道程をめぐらせて、 *omnium oculis mentibusque ad pugnam intentis **（彼我の）皆の目と意識が戦闘に没頭している間に *celeriter ad eas quas diximus munitiones pervenerunt atque his prorutis **速やかに前述した（後門の）防壁に至って、それを崩壊させて、 *prius in hostium castris constiterunt, **敵の陣営に拠点を築いた。 *quam plane ab his videri aut quid rei gereretur cognosci posset. **彼ら（敵）によりまったく見られ、あるいはいかなる事が遂行されているかを知られるよりも早くのことだった。 *Tum vero clamore ab ea parte audito **そのときまさにこの方面から雄叫びが聞こえて、 *nostri redintegratis viribus, **我が方（ローマ勢）は活力を回復し、 *quod plerumque in spe victoriae accidere consuevit, **勝利の希望の中にたいてい起こるのが常であったように *acrius impugnare coeperunt. **より激烈に攻め立て始めたのであった。 *Hostes undique circumventi desperatis omnibus rebus **敵は至る所から攻囲されて、すべての事態に絶望し、 *se per munitiones deicere et fuga salutem petere intenderunt. **壁を越えて飛び降りて、逃亡によって身の安全を求めることに懸命になった。 *Quos equitatus apertissimis campis consectatus **この者たちを（ローマの）騎兵隊が非常に開けた平原で追撃し、 *ex milium L{quinquaginta} numero, quae ex Aquitania Cantabrisque convenisse constabat, **[[w:アクィタニア|アクィタニア]]と[[w:カンタブリ族|カンタブリ族]]（[[w:en:Cantabri|Cantabri]]）から集まっていた（敵の総勢の）数は5万名が確認されたが、 *vix quarta parte relicta, **やっとその四分の一が生き残り、 *multa nocte se in castra recepit. **夜も更けて（ローマ勢は）陣営に退却した。 ===27節=== '''アクィタニア諸部族の降伏''' *Hac audita pugna **この戦闘（の勝敗）を聞いて、 *maxima pars Aquitaniae sese Crasso dedidit obsidesque ultro misit; **[[w:アクィタニア人|アクィタニア人]]の大部分がクラッススに降伏して、すすんで[[w:人質|人質]]を送った。 *quo in numero fuerunt **その数の中には以下の部族がいた。 *Tarbelli, Bigerriones, Ptianii, Vocates, Tarusates, Elusates, **[[w:タルベッリ族|タルベッリ族]]、[[w:ビゲッリオネス族|ビゲッリオネス族]]、[[w:プティアニー族|プティアニイ族]]、[[w:ウォカテス族|ウォカテス族]]、[[w:タルサテス族|タルサテス族]]、[[w:エルサテス族|エルサテス族]]、 *Gates, Ausci, Garunni, Sibulates, Cocosates: **[[w:ガテス族|ガテス族]]、[[w:アウスキ族|アウスキ族]]、[[w:ガルンニ族|ガルンニ族]]、[[w:シブラテス族|シブラテス族]]、[[w:ココサテス族|ココサテス族]]、である。 *paucae ultimae nationes **わずかな遠方の部族たちは、 *anni tempore confisae, quod hiems suberat, **時季を頼りにして、というのも冬が近づいていたためであるが、 *id facere neglexerunt. **そのこと（降伏と人質）をなおざりにした。 ==モリニ族・メナピイ族への遠征== ===28節=== '''カエサル、モリニ族・メナピイ族へ遠征''' *Eodem fere tempore Caesar, **（前節までに述べたクラッススのアクィタニア遠征と）ほぼ同じ時期にカエサルは、 *etsi prope exacta iam aestas erat, **すでに夏はほとんど過ぎ去っていたのであるが、 *tamen quod omni Gallia pacata **全ガリアが平定されていたにもかかわらず、 *Morini Menapiique supererant, **[[w:モリニ族|モリニ族]]と[[w:メナピー族|メナピイ族]]は生き残って *qui in armis essent, neque ad eum umquam legatos de pace misissent, **武装した状態で、彼（カエサル）のところへ決して和平の使節を派遣しようとしなかったので、 *arbitratus id bellum celeriter confici posse, eo exercitum duxit; **この戦争は速やかに完遂されると思って、そこへ軍隊を率いて行った。 *qui longe alia ratione ac reliqui Galli bellum gerere instituerunt. **これら（の部族）は、他のガリア人とはまったく別の方法で戦争遂行することを決めた。 *Nam **なぜなら *quod intellegebant maximas nationes, quae proelio contendissent, pulsas superatasque esse, **というのも、戦闘を戦った非常に多くの部族が撃退され、征服されていることを（彼らは）知っており、 *continentesque silvas ac paludes habebant, **かつ、絶え間ない[[w:森林|森]]と[[w:沼地|沼地]]を（彼らは）持っていたので *eo se suaque omnia contulerunt. **そこへ自分たちとそのすべての物を運び集めたのだ。 *Ad quarum initium silvarum cum Caesar pervenisset castraque munire instituisset **かかる森の入口のところへカエサルが到着して陣営の防備にとりかかったときに、 *neque hostis interim visus esset, **敵はその間に現れることはなく、 *dispersis in opere nostris **工事において分散されている我が方（ローマ勢）を *subito ex omnibus partibus silvae evolaverunt et in nostros impetum fecerunt. **突然に（敵が）森のあらゆる方面から飛び出してきて、我が方に襲撃をしかけたのだ。 *Nostri celeriter arma ceperunt **我が方は速やかに武器を取って *eosque in silvas reppulerunt et compluribus interfectis **彼らを森の中に押し戻して、かなり（の敵）を殺傷して *longius impeditioribus locis secuti **非常に通りにくい場所を追跡したが、 *paucos ex suis deperdiderunt. **我が方の部下で損傷を負ったのは少数であった。 ===29節=== '''カエサル、むなしく撤兵する''' *Reliquis deinceps diebus Caesar silvas caedere instituit, **続いて（冬が近づくまでの）残りの何日かで、カエサルは森を[[w:伐採|伐採]]することに決めた。 *et ne quis inermibus imprudentibusque militibus ab latere impetus fieri posset, **（これは）非武装で不注意な兵士たちが側面からいかなる襲撃もなされないように（ということであり）、 *omnem eam materiam quae erat caesa conversam ad hostem conlocabat **伐採されたすべての[[w:木材|材木]]を敵の方へ向きを変えて配置して、 *et pro vallo ad utrumque latus exstruebat. **[[w:防柵|防柵]]の代わりに両方の側面に築いた。 *Incredibili celeritate magno spatio paucis diebus confecto, **信じがたいほどの迅速さで大きな空間がわずかな日数で完遂されて、 *cum iam pecus atque extrema impedimenta a nostris tenerentur, **すでに[[w:家畜|家畜]]や[[w:輜重|輜重]]の最も端が我が方（ローマ軍）により捕捉された。 *ipsi densiores silvas peterent, **（敵）自身は密生した森を行くし、 *eiusmodi sunt tempestates consecutae, uti opus necessario intermitteretur **[[w:嵐|嵐]]が続いたので、工事はやむを得ずに中断された。 *et continuatione imbrium diutius sub pellibus milites contineri non possent. **雨が続いて、これ以上は皮（[[w:天幕|天幕]]）の下に兵士たちを留めることはできなかった。 *Itaque vastatis omnibus eorum agris, vicis aedificiisque incensis, **こうして、彼らのすべての畑を荒らして、村々や建物に火をつけて、 *Caesar exercitum reduxit **カエサルは軍隊を連れ戻して、 *et in Aulercis Lexoviisque, reliquis item civitatibus quae proxime bellum fecerant, **[[w:アウレルキ族|アウレルキ族]]と[[w:レクソウィー族|レクソウィイ族]]や、他の同様に最近に戦争をしていた部族たちのところに *in hibernis conlocavit. **[[w:冬営|冬営]]を設置した。 ---- *<span style="background-color:#99ff99;">「ガリア戦記 第3巻」了。「[[ガリア戦記 第4巻]]」へ続く。</span> ==脚注== <references /> [[Category:ガリア戦記 第3巻|*]] 1lunjcpby5bb3v931qngxwp4u1yj5qe 206058 206051 2022-07-31T14:21:04Z Linguae 449 /* 14節 */ 修正 wikitext text/x-wiki [[Category:ガリア戦記|3]] [[ガリア戦記]]＞&nbsp;'''第3巻'''&nbsp;＞[[ガリア戦記 第3巻/注解|注解]] <div style="text-align:center"> <span style="font-size:20px; font-weight:bold; font-variant-caps: petite-caps; color:white; background: rgb(47,94,255);background: linear-gradient(180deg, rgba(47,94,255,1) 0%, rgba(24,56,255,1) 50%, rgba(0,8,255,1) 100%);">&nbsp;C&nbsp;IVLII&nbsp;CAESARIS&nbsp;COMMENTARIORVM&nbsp;BELLI&nbsp;GALLICI&nbsp;</span> <span style="font-size:40px; font-weight:bold; color:white; background: rgb(47,94,255);background: linear-gradient(180deg, rgba(47,94,255,1) 0%, rgba(24,56,255,1) 50%, rgba(0,8,255,1) 100%);">&nbsp;LIBER TERTIVS&nbsp;</span> </div> [[画像:Gaule -56.png|thumb|right|150px|ガリア戦記 第3巻の情勢図（BC56年）。<br>黄色の領域がローマ領。桃色が同盟部族領。]] {| id="toc" style="align:left;clear:all;" align="left" cellpadding="5" ! style="background:#ccccff; text-align:left;" colspan="2" | ガリア戦記 第3巻 目次 |- | style="text-align:right; font-size: 0.86em;"| '''[[#アルプス・オクトードゥールスの戦い|アルプス・オクトードゥールスの戦い]]''':<br /> '''[[#大西洋岸ウェネティー族の造反|大西洋岸ウェネティー族の造反]]''':<br /> <br /> '''[[#大西洋岸ウネッリ族の造反|大西洋岸ウネッリ族の造反]]''':<br /> '''[[#クラッススのアクィタニア遠征|クラッススのアクィタニア遠征]]''':<br /> <br /> '''[[#モリニ族・メナピイ族への遠征|モリニ族・メナピイ族への遠征]]''':<br /> | style="text-align:left; font-size: 0.86em;"| [[#1節|01節]] | [[#2節|02節]] | [[#3節|03節]] | [[#4節|04節]] | [[#5節|05節]] | [[#6節|06節]] <br /> [[#7節|07節]] | [[#8節|08節]] | [[#9節|09節]] | [[#10節|10節]] <br /> [[#11節|11節]] | [[#12節|12節]] | [[#13節|13節]] | [[#14節|14節]] | [[#15節|15節]] | [[#16節|16節]] <br /> [[#17節|17節]] | [[#18節|18節]] | [[#19節|19節]] <br /> [[#20節|20節]] <br /> [[#21節|21節]] | [[#22節|22節]] | [[#23節|23節]] | [[#24節|24節]] | [[#25節|25節]] | [[#26節|26節]] | [[#27節|27節]] <br /> [[#28節|28節]] | [[#29節|29節]] |} <br style="clear:both;" /> __notoc__ ==<span style="color:#009900;">はじめに</span>== :<div style="color:#009900;width:85%;">前巻（[[ガリア戦記 第2巻|ガリア戦記 第2巻]]）の終わりで述べられたように、カエサルによってガッリアはほぼ平定されたと思われて、首都ローマで感謝祭が催されたほどであった。このため、本巻（第3巻）ではカエサル自身の遠征として記す内容はとても少ない。<br><br>本巻の[[#1節]]～[[#6節]]で言及される[[#アルプス・オクトードゥールスの戦い]]は、[[w:紀元前57年|BC57年]]秋頃に起こったと考えられるので、本来なら第2巻に含められるべきであるが、そうなると第3巻が20節ほどの非常に短い巻になってしまうので、第3巻の冒頭に置いたとも考えられる。<br><br>本巻（第3巻）の年（[[w:紀元前56年|BC56年]]）の春には、ガッリア遠征の遂行上きわめて重要な'''ルカ会談'''があったので、以下に補足する。</div> <div style="background-color:#eee;width:75%;"> ===コラム「ルカ会談」=== :::<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Luca Conference|Luca Conference]]''</span>（英語記事）などを参照。 :<span style="color:#009900;">伝記作家[[ガリア戦記/注解編#プルータルコス『対比列伝』|プルータルコス]]によれば<ref>[[ガリア戦記/注解編#プルータルコス『対比列伝』|プルータルコス『対比列伝』]]の「カエサル」20,21</ref>、カエサルはベルガエ人との戦いを成し遂げると、前年に続いて'''パドゥス川'''〔[[w:la:Padus|Padus]] [[w:ポー川|ポー川]]〕流域で越冬しながら、ローマ政界への政治工作を続けた。例えば、カエサルを後援者とする選挙の立候補者たちが有権者を買収するための金銭をばらまいていた。ガッリア人捕虜を奴隷商人に売り払って得た莫大な金銭で。その結果、カエサルの金銭で当選した者たちの尽力で、属州総督カエサルへの新たな資金の支給が可決されるという具合であった。<br><br>そのうち、多くの名門貴族たちがカエサルに面会するために[[w:ルッカ|ルカ]]（[[w:la:Luca|Luca]]）の街へやって来た。<br>こうした中、[[w:紀元前56年|BC56年]]の4月に、カエサルと非公式の盟約（[[w:三頭政治#第一回三頭政治|三頭政治]]）を結んでいた[[w:マルクス・リキニウス・クラッスス|クラッスス]]と[[w:グナエウス・ポンペイウス|ポンペイウス]]もルカを訪れて、三者による会談が行われた。<br><br>首都ローマでは、三頭政治を後ろ盾とする[[w:ポプラレス|平民派]]の[[w:プブリウス・クロディウス・プルケル|クロディウス]]（<span style="font-family:Times New Roman;">[[w:la:Publius Clodius Pulcher|Publius Clodius Pulcher]]</span>）が民衆に暴動をけしかけ、[[w:オプティマテス|門閥派]]のミロ（<span style="font-family:Times New Roman;">[[w:la:Titus Annius Milo|Titus Annius Milo]]</span>）と激しく抗争するなど、騒然としていた。このクロディウスの暴力的な手法は、クラッススとポンペイウスの関係を傷つけた。また、カエサルのガッリアでの輝かしい勝利に、二人とも不満を感じていた。このように三頭政治は綻び出していたのだ。<br><br>三人は三頭政治を延長することで合意した。カエサルは、クラッススとポンペイウスが翌年（[[w:紀元前55年|BC55年]]）の執政官に立候補すること、3属州の総督であるカエサルの任期がさらに5年間延長されること、などを求めた。<br><br>会談の結果、任期が大幅に延長されたカエサルの野望は、ガッリアに止まらず、[[w:ゲルマニア|ゲルマーニア]]や[[w:ブリタンニア|ブリタンニア]]の征服へと向かっていく。一方、再び執政官になった二人は、[[w:パルティア|パルティア]]を攻略するためにクラッススがシリア総督になることを決めるが、これはクラッススの命運とともに三頭政治の瓦解、カエサルとポンペイウスの関係悪化を招来することになる。 </span> <div style="text-align:center"> {| |- |[[画像:First Triumvirate of Caesar, Crassius and Pompey.jpg|thumb|right|500px|後に[[w:三頭政治#第一回三頭政治|三頭政治]]（<span style="font-family:Times New Roman;">[[w:la:Triumviratus|Triumviratus]]</span>）と呼ばれることになる非公式な盟約を結んでいた、左から[[w:ガイウス・ユリウス・カエサル|カエサル]]、[[w:マルクス・リキニウス・クラッスス|クラッスス]]、[[w:グナエウス・ポンペイウス|ポンペイウス]]。<br>3人は、第3巻の戦いが始まる前に、ルカ会談で三頭政治の延長を決めた。]] |} </div> </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ==アルプス・オクトードゥールスの戦い== :<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Battle of Octodurus|Battle of Octodurus]]''</span>（英語記事）<span style="font-family:Times New Roman;font-size:13pt;">''[[w:fr:Bataille d'Octodure|Bataille d'Octodure]]''</span>（仏語記事）などを参照。 ===1節=== [[画像:Historische Karte CH Rome 1.png|thumb|right|300px|現在の[[w:スイス|スイス]]の帝制ローマ時代の地図。左下の三日月形の[[w:レマン湖|レマン湖]]の下方に、<span style="font-family:Times New Roman;">ALLOBROGES, NANTUATES, VERAGRI, SEDUNI</span> の部族名が見える。]] [[画像:Afdaling vd San Bernardino - panoramio.jpg|thumb|right|300px|現在の[[w:グラン・サン・ベルナール峠|グラン・サン・ベルナール峠]]。ラテン語では <span style="font-family:Times New Roman;">[[w:la:Porta Magni Sancti Bernardi|Porta Magni Sancti Bernardi]] という。<br>スイスを縦断する[[w:欧州自動車道路|欧州自動車道路]] [[w:en:European route E27|E27]] が[[w:レマン湖|レマン湖]]からこの峠を通ってイタリアの[[w:アオスタ|アオスタ]]へ至る。</span>]] *<span style="background-color:#ffd;">[[/注解/1節]]　{{進捗|00%|2022-04-23}}</span> '''ガルバとローマ第12軍団が、ロダヌス川渓谷のオクトードゥールスにて冬営する''' <br> ;　　　カエサルが、ガルバと軍団・騎兵をアルプス地方へ派兵 *Cum in Italiam proficisceretur Caesar, **カエサルは、イタリア〔[[w:ガリア・キサルピナ|ガッリア・キサルピーナ]]〕に出発していたときに、 *[[wikt:en:Servium|Servium]] Galbam cum [[w:en:Legio XII Fulminata|legione duodecima(XII.)]] et parte equitatus **[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|セルウィウス・ガルバ]]を第12軍団および騎兵隊の一部とともに、 *in [[wikt:fr:Nantuates#Latin|Nantuates]], [[wikt:en:Veragri#Latin|Veragros]] Sedunosque misit, **ナントゥアーテース族・ウェラーグリー族・セドゥーニー族（の領土）に派遣した。 *qui a finibus [[wikt:en:Allobroges#Latin|Allobrogum]] et lacu [[wikt:fr:Lemannus|Lemanno]] et flumine [[wikt:en:Rhodanus#Latin|Rhodano]] ad summas [[wikt:en:Alpes#Latin|Alpes]] pertinent. **彼らはアッロブロゲース族の領土、レマンヌス湖〔[[w:レマン湖|レマン湖]]〕およびロダヌス川〔[[w:ローヌ川|ローヌ川]]〕から[[w:アルプス山脈|アルプス]]の頂きに及んでいる。 *Causa mittendi fuit, **派遣の理由は（以下のこと）であった： *quod iter per Alpes, **アルプスを通る道は、 *quo magno cum periculo magnisque cum [[wikt:en:portorium|portoriis]] mercatores ire consuerant, **大きな危険と多額の関税を伴って商人たちが旅することが常であったので、 *patefieri volebat. **（カエサルは道が）開かれることを望んでいたのだ。 **:<span style="color:#009900;">（訳注：現在の[[w:グラン・サン・ベルナール峠|グラン・サン・ベルナール峠]]を通ってスイスとイタリアを結ぶ道のことで、<br>　　　　帝制初期に[[w:アウグストゥス|アウグストゥス]]によって街道が敷設された。<br>　　　　かつて[[w:ハンニバル|ハンニバル]]が越えたのは諸説あるが、この道であった可能性もある。<br>　　　　ローマ人がこの地に移入・育成した軍用犬は現在の[[w:セント・バーナード|セント・バーナード犬]]。）</span> *Huic permisit, si opus esse arbitraretur, uti in his locis legionem hiemandi causa conlocaret. **彼〔ガルバ〕に、もし必要と思われるならば、この地に軍団を[[w:冬営|冬営]]するために宿営させることを許可した。 [[画像:Servius Sulpicius Galba.jpg|thumb|right|300px|[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|セルウィウス・スルピキウス・ガルバ]]の横顔が刻まれた貨幣。ガルバは[[w:紀元前54年|BC54年]]（[[ガリア戦記 第5巻|ガリア戦記 第5巻]]の年）に[[w:プラエトル|法務官]]に任官。内戦期もカエサルに従うが、暗殺計画に参画する。<br>[[w:ネロ|ネロ帝]]とともにユリウス家の王朝が途絶えると、ガルバの曽孫が[[w:ローマ内戦_(68年-70年)#四皇帝|四皇帝]]の一人目の[[w:ガルバ|ガルバ帝]]となった。このため[[w:ガイウス・スエトニウス・トランクィッルス|スエートーニウス]]『ローマ皇帝伝』の「ガルバ伝」にガルバへの言及がある<ref>[[s:la:De_vita_Caesarum_libri_VIII/Vita_Galbae#III.]]</ref>。]] <br> ;　　　ガルバが、諸部族を攻略して、軍団の冬営を決める *Galba, secundis aliquot proeliis factis **ガルバは、いくつかの優勢な戦いをして、 *castellisque compluribus eorum expugnatis, **彼ら〔ガッリア諸部族〕の多くの砦が攻略されると、 *missis ad eum undique legatis **彼〔ガルバ〕のもとへ四方八方から（諸部族の）使節たちが遣わされ、 *obsidibusque datis et pace facta, **人質が供出されて、講和がなされたので、 *constituit **（ガルバは、以下のことを）決めた。 *cohortes duas in Nantuatibus conlocare **2個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>をナントゥアーテース族（の領土）に宿営させること、 *et ipse cum reliquis eius legionis cohortibus **（ガルバ）自身はその軍団の残りの<ruby><rb>歩兵大隊</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>とともに、 *in vico Veragrorum, qui appellatur [[wikt:en:Octodurus|Octodurus]], hiemare; **オクトードゥールスと呼ばれているウェラーグリー族の村に冬営することを。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：オクトードゥールス（[[wikt:en:Octodurus|Octodurus]]）は現在の[[w:マルティニー|マルティニー市]]。）</span> <br> ;　　　ウェラーグリー族のオクトードゥールス村 *qui vicus positus in valle, non magna adiecta planitie, **その村は、さほど大きくない平地に付随した渓谷の中に位置し、 *altissimis montibus undique continetur. **とても高い山々で四方八方を囲まれている。 *Cum hic in duas partes flumine divideretur, **これ〔村〕は川によって二つの部分に分け隔てられているので、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：現在の[[w:マルティニー|マルティニー]]の街中を、[[w:ローヌ川|ローヌ川]]の支流であるドランス川（''[[w:en:Drance|Drance]]）が貫流している。）</span> *alteram partem eius vici Gallis [ad hiemandum] concessit, **その村の一方の部分をガッリア人に [越冬するために] 譲った。 *alteram vacuam ab his relictam cohortibus attribuit. **もう一方の彼ら〔ガッリア人〕により空にされた方を、残りの<ruby><rb>歩兵大隊</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>に割り当てた。 *Eum locum vallo fossaque munivit. **その地を堡塁と塹壕で守りを固めた。 <div style="text-align:center"> {| |- |[[画像:Martigny_1600.jpg|thumb|right|600px|かつてウェラーグリー族のオクトードゥールス村（[[w:la:Octodurus|Octodurus]]）があった所は、現在では[[w:スイス|スイス]]の[[w:マルティニー|マルティニー]]（[[w:en:Martigny|Martigny]]）市となっている。[[w:ローヌ川|ローヌ川]]が屈曲して流れる[[w:谷|渓谷]]地帯にある。]] |} </div> <div style="background-color:#eee;width:77%;"> ===コラム「ガルバの派遣とカティリーナ事件」=== :::関連記事：<span style="font-family:Times New Roman;font-size:13pt;">[[w:la:Catilinae coniuratio|Catilinae coniuratio]], ''[[w:en:Second Catilinarian conspiracy|Second Catilinarian conspiracy]]''</span> :<span style="color:#009900;">　[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|セルウィウス・スルピキウス・'''ガルバ''']]にアルプス派兵を指揮させた理由について、カエサルは記していない。<br><br>　[[w:紀元前63年|BC63年]]～[[w:紀元前62年|BC62年]]に、ローマの高官だった[[w:ルキウス・セルギウス・カティリナ|ルーキウス・セルギウス・'''カティリーナ''']]（[[w:la:Lucius Sergius Catilina|Lucius Sergius Catilina]]）がクーデタを企てるという大事件があった。'''[[w:マルクス・トゥッリウス・キケロ|キケロー]]'''が『[[w:カティリナ弾劾演説|カティリナ弾劾演説]]』で糾弾し、カエサルが事件の黒幕ではないかと取り沙汰された(スエートニウス<ref>[[s:la:De_vita_Caesarum_libri_VIII/Vita_divi_Iuli#XIV.]]， [[s:la:De_vita_Caesarum_libri_VIII/Vita_divi_Iuli#XVII.|#XVII.]] を参照。</ref>)。<br>　BC63年の[[w:プラエトル|法務官]][[w:ガイウス・ポンプティヌス|ガーイウス・'''ポンプティーヌス''']]がキケローを助けて事件を捜査し、アッロブロゲース族からカティリーナへ宛てた手紙を調べた。BC62年にポンプティーヌスは前法務官としてガッリア総督となり、事件に関与していたアッロブロゲース族を平定した。このとき、[[w:トリブヌス|副官]]としてポンプティーヌスを助けてアッロブロゲース族を攻めたのが'''ガルバ'''であった。総督がカエサルに替わっても、ガルバは副官として留任し、アッロブロゲース族の近隣部族の鎮定に努めていたわけである。<br>　ポンプティーヌスは、一部の元老院議員の反対で、戦勝将軍の権利である[[w:凱旋式|凱旋式]]ができなかった。これを不満に思っていたガルバは、[[w:紀元前54年|BC54年]]に法務官になると尽力して、その年にポンプティーヌスの凱旋式を行なうことに成功した。 <div style="text-align:center"> {| |- |[[画像:Joseph-Marie Vien - The Oath of Catiline.jpg|thumb|right|320px|'''カティリーナの誓い'''（''Le Serment de Catiline''）<br>[[w:ジョゼフ＝マリー・ヴィアン|ジョゼフ＝マリー・ヴィアン]]画(1809年)。<hr>カティリーナと共謀者たちは、人間の血を混ぜたワインを飲んで誓いを立てる儀式を行なったと伝えられている。]] |[[画像:The Discovery of the Body of Catiline.jpg|thumb|right|320px|'''カティリーナの遺骸の発見'''<br>（''Il ritrovamento del corpo di Catilina''）<br>''[[w:en:Alcide Segoni|Alcide Segoni]]'' 画(1871年)<hr>アッロブロゲース族のいるガッリアへ向かおうとしていたカティリーナは、[[w:ピストイア|ピストリア]]（[[w:la:Pistorium|Pistoria]]）の戦い（''[[w:en:Battle of Pistoia|Battle of Pistoia]]''）で戦死した。]] |} </div> </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===2節=== *<span style="background-color:#ffd;">[[/注解/2節]]　{{進捗|00%|2022-05-05}}</span> '''ガッリア人が再び挙兵して周囲の高峰を押さえ、第12軍団の冬営地を包囲''' *Cum dies hibernorum complures transissent frumentumque eo comportari iussisset, **冬営の多くの日々が過ぎ去って、穀物がそこに運び集められることを（[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|ガルバ]]が）命じていたときに、 *subito per exploratores certior factus est **突然に（以下のことが）[[w:偵察|偵察隊]]により報告された。 *ex ea parte vici, quam Gallis concesserat, omnes noctu discessisse **ガッリア人たちに譲っていた村の一部から、皆が夜に立ち退いており、 *montesque, qui [[wikt:en:impendeo#Latin|impenderent]], a maxima multitudine Sedunorum et [[wikt:en:Veragri|Veragrorum]] teneri. **そそり立つ山々がセドゥーニー族とウェラーグリー族のかなりの大勢により占拠されたのだ。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：ウェラーグリー族は既述のようにオクトードゥールス村 [[w:la:Octodurus|Octodurus]]〔現在の[[w:マルティニー|マルティニー市]]〕を、<br>セドゥーニー族 [[w:la:Seduni|Seduni]] はより上流のセドゥヌム [[w:la:Sedunum|Sedunum]]〔現在の[[w:シオン (スイス)|シオン市]]〕を首邑としていた。）</span> *Id aliquot de causis acciderat, **いくつかの理由から、起こっていたことには、 *ut subito Galli belli renovandi legionisque opprimendae consilium caperent: **突如としてガッリア人が、戦争を再開して（ローマ人の）軍団を急襲する作戦計画を立てたのだ。 <br> ;　　　　第1の理由：ガルバの第12軍団は、兵が割かれていて寡勢である *primum, quod legionem neque eam plenissimam detractis cohortibus duabus **というのも、第一に、総員がそろっていない軍団を&nbsp;──2個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>が引き抜かれていて、 **:<span style="color:#009900;">（訳注：前節で既述のように、2個歩兵大隊をナントゥアーテース族のところに宿営させていたが、これはレマンヌス湖〔[[w:レマン湖|レマン湖]]〕に近いより下流の地域で、離れていたようだ。）</span> *et compluribus singillatim, qui commeatus petendi causa missi erant, absentibus, **多くの者たちが一人ずつ、糧食を求めるために派遣されていて不在である、── *propter paucitatem despiciebant; **（その第12軍団を）少数であるゆえに、見下していたからだ。 <br> ;　　　　第2の理由：渓谷にいるローマ人は、山から攻め降りて来るガッリア人の飛道具を受け止められまい *tum etiam, quod propter iniquitatem loci, **それからさらに（ローマ勢が冬営している渓谷の）地の利の無さゆえ、 *cum ipsi ex montibus in vallem decurrerent et tela conicerent, **（ガッリア勢）自身が山々から谷間に駆け下りて飛道具を投じたときに、 *ne primum quidem impetum suum posse sustineri existimabant. **自分たちの最初の襲撃を（ローマ勢が）持ちこたえることができない、と判断していたので。 <br> ;　　　　第3の理由：人質を取られて、属州に併合される前にローマ人を討て *Accedebat, quod suos ab se liberos abstractos obsidum nomine dolebant, **加えて、人質の名目で自分たちから引き離されている自分の子供たちのことを嘆き悲しんでいたので、 *et Romanos non solum itinerum causa, sed etiam perpetuae possessionis **かつ、ローマ人たちは道（の開通）のためだけでなく、永続的な領有のためにさえも *culmina Alpium occupare <u>conari</u> **アルプスの頂上を占領すること、 *et ea loca finitimae provinciae adiungere **および（ローマの）属州に隣接する当地を併合することを<u>企てている</u>、 *sibi persuasum habebant. **と（ガッリア人たちは）確信していたのである。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===3節=== *<span style="background-color:#ffd;">[[/注解/3節]]　{{進捗|00%|2022-05-12}}</span> '''ガルバが軍議を召集し、策を募る''' *His nuntiis acceptis Galba, **ガルバは、これらの報告を受け取ると、 *<u>cum</u> neque opus hibernorum munitionesque plene essent perfectae **冬営の普請や防塁構築も十分に完成していなかったし、 *neque de frumento reliquoque commeatu satis esset provisum, **穀物や他の糧秣も十分に調達されていなかった<u>ので</u>、 *quod deditione facta obsidibusque acceptis **── というのも、降伏がなされて、人質が受け取られ、 *nihil de bello timendum existimaverat, **戦争について恐れるべきことは何もない、と判断していたためであるが、── *consilio celeriter convocato sententias exquirere coepit. **軍議を速やかに召集して、意見を求め始めた。 <br> ;軍議 *Quo in consilio, **その軍議において、 *<u>cum</u> tantum repentini periculi praeter opinionem accidisset **これほどの不意の危険が、予想に反して起こっていたので、 *ac iam omnia fere superiora loca multitudine armatorum completa conspicerentur **かつ、すでにほぼすべてのより高い場所が、武装した大勢の者たちで満たされていることが、見られていたので、 *neque subsidio veniri **救援のために（援軍が）来られることもなかったし、 *neque commeatus supportari interclusis itineribus possent, **糧秣が運び込まれることも、道が遮断されているので、できなかった<u>ので</u>、 *prope iam desperata salute non nullae eius modi sententiae dicebantur, **すでにほぼ身の安全に絶望していた幾人かの者たちの'''以下のような'''意見が述べられていた。 *ut impedimentis relictis eruptione facta **輜重を残して、出撃して、 *isdem itineribus quibus eo pervenissent ad salutem contenderent. **そこへやって来たのと同じ道によって、安全なところへ急ぐように、と。 **:<span style="color:#009900;">（訳注：レマンヌス〔[[w:レマン湖|レマン湖]]〕湖畔を通ってアッロブロゲース族領へ撤収することであろう。）</span> *Maiori tamen parti placuit, **しかしながら、大部分の者が賛成したのは、 *hoc reservato ad extremum consilio **この考え（計画）を最後まで保持しておいて、 *interim rei eventum experiri et castra defendere. **その間に、事の結果を吟味して、陣営を守備すること、であった。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===4節=== *<span style="background-color:#ffd;">[[/注解/4節]]　{{進捗|00%|2022-05-16}}</span> '''ガッリア勢がガルバの陣営を急襲し、寡兵のローマ勢は劣勢に陥る''' *Brevi spatio interiecto, **（敵の来襲まで）短い間が介在しただけだったので、 *vix ut iis rebus quas constituissent conlocandis atque administrandis tempus daretur, **決めておいた物事を配置したり遂行するための時間が、ほとんど与えられないほどであった。 *hostes ex omnibus partibus signo dato decurrere, **敵方〔ガッリア勢〕があらゆる方向から、号令が出されて、駆け下りて来て、 *lapides [[wikt:en:gaesum|gaesa]]que in vallum conicere. **石や投槍を堡塁の中に投げ込んだ。 *Nostri primo integris viribus fortiter propugnare **我が方〔ローマ勢〕は、当初、体力が損なわれていないうちは勇敢に応戦して、 *neque ullum frustra telum ex loco superiore mittere, **高所から、いかなる飛道具も無駄に投げることはなかった。 *et quaecumque<!--ut quaeque--> pars castrorum nudata defensoribus premi videbatur, **陣営のどの部分であれ、防戦者たちがはがされて押され気味であることと思われれば、 *eo occurrere et auxilium ferre, **（ローマ勢が）そこへ駆け付けて、支援した。 <br> ;　　兵の多寡が、ローマ勢を追い込む *sed hoc superari **しかし、以下のことにより（ローマ勢は）打ち破られた。 *quod diuturnitate pugnae hostes defessi proelio excedebant, **──戦いが長引いたことにより、疲れ切った敵たちは戦闘から離脱して、 *alii integris viribus succedebant; **体力が損なわれていない他の者たちが交代していたのだ。── *quarum rerum a nostris propter paucitatem fieri nihil poterat, **我が方〔ローマ勢〕は少数であるゆえに、このような事〔兵の交代〕は何らなされ得なかった。 *ac non modo defesso ex pugna excedendi, **疲弊した者にとっての戦いから離脱することの（機会）のみならず、 *sed ne saucio quidem eius loci ubi constiterat relinquendi ac sui recipiendi facultas dabatur. **負傷した者にとってさえも、その持ち場を放棄することや（体力を）回復することの機会も与えられなかったのだ。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===5節=== *<span style="background-color:#ffd;">[[/注解/5節]]　{{進捗|00%|2022-05-29}}</span> '''最後の土壇場で説得されたガルバが、疲労回復後の突撃に命運を賭ける''' *<u>Cum</u> iam amplius horis sex continenter pugnaretur, **すでに6時間より多く引き続いて戦われており、 **:<span style="color:#009900;">（訳注：[[古代ローマの不定時法]]では、冬の日中の半日ほどである）</span> *ac non solum vires sed etiam tela nostros deficerent, **活力だけでなく飛道具さえも我が方〔ローマ勢〕には不足していたし、 *atque hostes acrius instarent **敵方〔ガッリア勢〕はより激しく攻め立てていて、 *languidioribusque nostris **我が方〔ローマ勢〕が弱り切っており、 *vallum scindere et fossas complere coepissent, **（ガッリア勢は）防柵を破却したり、塹壕を埋め立てたりし始めていたし、 *resque esset iam ad extremum perducta casum, **戦況はすでに最後の土壇場に陥っていた<u>ので</u>、 <br> ;　　二人の軍団首脳バクルスとウォルセーヌスが、ガルバに敵中突破を説く *[[wikt:en:P.|P.]] Sextius Baculus, primi pili centurio, **<ruby><rb>[[w:プリムス・ピルス|首位百人隊長]]</rb><rp>（</rp><rt>プリームス・ピールス</rt><rp>）</rp></ruby>プーブリウス・セクスティウス・バクルス **:<span style="color:#009900;">（訳注：[[w:la:Publius Sextius Baculus|Publius Sextius Baculus]] などの記事を参照。）</span> *quem Nervico proelio compluribus confectum vulneribus diximus, **──その者が[[w:ネルウィイ族|ネルウィイー族]]との戦いで多くの負傷で消耗したと前述した── **:<span style="color:#009900;">（訳注：[[ガリア戦記 第2巻#25節|第2巻25節]]を参照。なお、[[ガリア戦記 第6巻#38節|第6巻38節]] でも言及される。）</span> *et item [[wikt:en:C.#Latin|C.]] Volusenus, tribunus militum, vir et consilii magni et virtutis, **および、[[w:トリブヌス・ミリトゥム|軍団次官]]ガーイウス・ウォルセーヌス ──卓越した判断力と武勇を持つ男──（の2人）は、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:en:Gaius Volusenus|Gaius Volusenus]]'' などの記事を参照せよ。）</span> *ad Galbam accurrunt **ガルバのもとへ急いで来て、 *atque unam esse spem salutis docent, si eruptione facta extremum auxilium experirentur. **身の安全のただ一つの希望は、出撃をして最後の救済策を試みるかどうかだ、と説く。 *Itaque convocatis centurionibus **こうして、<ruby><rb>[[w:ケントゥリオ|百人隊長]]</rb><rp>（</rp><rt>ケントゥリオー</rt><rp>）</rp></ruby>たちが召集されて、 *celeriter milites certiores facit, **（ガルバが以下のことを）速やかに兵士たちに通達する。 *paulisper intermitterent proelium **しばらく戦いを中断して *ac tantummodo tela missa exciperent seque ex labore reficerent, **ただ投げられた飛道具を遮るだけとし、疲労から（体力を）回復するようにと、 *post dato signo ex castris erumperent, **与えられた号令の後に陣営から出撃するように、 *atque omnem spem salutis in virtute ponerent. **身の安全のすべての希望を武勇に賭けるように、と。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===6節=== *<span style="background-color:#ffd;">[[/注解/6節]]　{{進捗|00%|2022-06-05}}</span> '''第12軍団がガッリア勢を破るが、ガルバはオクトードゥールスでの冬営を断念する''' *Quod iussi sunt faciunt, **（ローマ兵たちは）命じられたことをなして、 *ac subito omnibus portis eruptione facta **突然に（陣営の）すべての門から出撃がなされ、 *neque cognoscendi quid fieret **何が生じたのかを知ることの（機会）も *neque sui colligendi hostibus facultatem relinquunt. **（自軍の兵力を）集中することの機会も、敵方に残さない。 *Ita commutata fortuna **こうして武運が変転して、 *eos qui in spem potiundorum castrorum venerant undique circumventos intercipiunt, **（ローマ人の）陣営を占領することを期待してやって来ていた者たちを、至る所で包囲して<ruby><rb>屠</rb><rp>（</rp><rt>ほふ</rt><rp>）</rp></ruby>る。 *et ex hominum milibus amplius XXX{triginta}, **3万より多い人間が *quem numerum barbarorum ad castra venisse constabat, **それだけの数の蛮族が（ローマ）陣営のところへ来ていたのは、確実であったが、 *plus tertia parte interfecta **3分の1より多く（の者）が<ruby><rb>殺戮</rb><rp>（</rp><rt>さつりく</rt><rp>）</rp></ruby>されて、 *reliquos perterritos in fugam coiciunt **（ローマ勢は）残りの者たちを怖気づかせて敗走に追いやり、 *ac ne in locis quidem superioribus consistere patiuntur. **（ガッリア勢は）より高い場所にさえ留まることさえ許されない。 *Sic omnibus hostium copiis fusis armisque exutis **そのように敵方の全軍勢が撃破されて、武器が放棄されて、 *se intra munitiones suas recipiunt. **（ローマ勢は）自分たちの防塁の内側に撤収する。 <br> ;　　ガルバがオクトードゥールスでの冬営を断念して、同盟部族領に撤退する *Quo proelio facto, **この戦いが果たされると、 *quod saepius fortunam temptare Galba nolebat **──ガルバは、よりたびたび武運を試すことを欲していなかったし、 *atque alio se in hiberna consilio venisse meminerat, **冬営に他の計画のために来ていたことを思い出していたが、 *aliis occurrisse rebus videbat, **別の事態に遭遇したのを見ていたので、── *maxime frumenti commeatusque inopia permotus **とりわけ穀物や糧秣の欠乏に揺り動かされて、 *postero die omnibus eius vici aedificiis incensis **翌日にその村のすべての建物が焼き討ちされて、 *in provinciam reverti contendit, **（ガルバは）属州〔[[w:ガリア・キサルピナ|ガッリア・キサルピーナ]]〕に引き返すことを急ぐ。 *ac nullo hoste prohibente aut iter demorante **いかなる敵によって妨げられることも、あるいは行軍が遅滞させられることもなく、 *incolumem legionem in Nantuates, **軍団を無傷なままでナントゥアーテース族（の領土）に（連れて行き）、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：ナントゥアーテース族 ''[[w:en:Nantuates|Nantuates]]'' は、レマンヌス湖〔[[w:レマン湖|レマン湖]]〕の南東を領有していた部族。<br>　　　　[[#1節]]で、軍団のうち2個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>を宿営させたことが述べられた。）</span> *inde in Allobroges perduxit ibique hiemavit. **そこから、アッロブロゲース族（の領土）に連れて行き、そこで冬営した。 <div style="text-align:center"> {| |- |[[画像:Amphitheaterforumclaudiival1.jpg|thumb|right|500px|オクトードゥールス（<span style="font-family:Times New Roman;">[[w:la:Octodurus|Octodurus]]</span>）、すなわち現在の[[w:マルティニー|マルティニー市]]に遺る帝制ローマ時代の円形競技場。オクトードゥールスは、<span style="font-family:Times New Roman;">Forum Claudii Vallensium</span> と改称され、[[w: クラウディウス|クラウディウス帝]]によって円形競技場が建てられた。<br>（<span style="font-family:Times New Roman;">''[[w:fr:Amphithéâtre de Martigny|Amphithéâtre de Martigny]]''</span> 等の記事を参照。）]] |} </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ==大西洋岸ウェネティー族の造反== :::<span style="background-color:#ffd;">関連記事：[[w:モルビアン湾の海戦|モルビアン湾の海戦]]、''[[w:fr:Guerre des Vénètes|fr:Guerre des Vénètes]]'' 等を参照せよ。</span> ===7節=== *<span style="background-color:#ffd;">[[/注解/7節]]　{{進捗|00%|2022-06-12}}</span> '''新たな戦争の勃発''' *His rebus gestis **これらの戦役が遂げられて、 *cum omnibus de causis Caesar pacatam Galliam existimaret, **カエサルが、あらゆる状況についてガッリアは平定された、と判断していたときに、 *superatis Belgis, **（すなわち）[[w:ベルガエ|ベルガエ人]]は征服され、 **:<span style="color:#009900;">（訳注：第2巻で述べられたこと）</span> *expulsis Germanis, **[[w:ゲルマニア|ゲルマーニア]]人は駆逐され、 **:<span style="color:#009900;">（訳注：第1巻で述べられた[[w:アリオウィストゥス|アリオウィストゥス]]との戦役のこと）</span> *victis in [[wikt:en:Alpibus|Alpibus]] Sedunis, **アルペース〔[[w:アルプス山脈|アルプス]]〕においてセドゥーニー族は打ち負かされて、 **:<span style="color:#009900;">（訳注：[[#1節]]～[[#6節]]で述べられたこと）</span> *atque ita inita hieme in [[wikt:en:Illyricum#Latin|Illyricum]] profectus esset, **こうして冬の初めに（カエサルが）[[w:イリュリクム|イッリュリクム]]に出発していたときに、 *quod eas quoque nationes adire et regiones cognoscere volebat, **──というのは、これら各部族を訪れて諸地方を知ることを欲していたからであるが、── **:<span style="color:#009900;">（訳注：属州総督の職務として、巡回裁判を行う必要があったためであろう）</span> *subitum bellum in Gallia coortum est. **突然の戦争がガッリアで勃発したのである。 <br> ;　　　戦争の背景 *Eius belli haec fuit causa: **その戦争の原因は、以下の通りであった。 *[[wikt:en:P.|P.]] Crassus adulescens cum legione septima(VII.) **[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス青年]]は、第7軍団とともに **:<span style="color:#009900;">（訳注：三頭政治家[[w:マルクス・リキニウス・クラッスス|M. クラッスス]]の息子で、第1巻[[s:la:Commentarii_de_bello_Gallico/Liber_I#52|52節]]では騎兵隊の指揮官だった。<br>　　　　[[ガリア戦記_第2巻#34節|第2巻34節]]では、1個軍団とともに大西洋沿岸地方に派遣されたと述べられた。）</span> *proximus mare Oceanum in Andibus hiemarat. **<ruby><rb>大洋〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>に最も近いアンデース族（の領土）で冬営していた。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：アンデース族 Andes は、'''アンデカーウィー族''' [[w:la:Andecavi|Andecavi]], ''[[wikt:en:Andecavi|Andecavi]]'' と呼ばれることが多い。<br>　　　　実際には大西洋岸から内陸側に寄っていたと考えられている。）</span> *Is, quod in his locis inopia frumenti erat, **彼〔クラッスス〕は、これらの場所においては穀物の欠乏があったので、 *praefectos tribunosque militum complures in finitimas civitates **（[[w:アウクシリア|支援軍]]の）<ruby><rb>[[w:プラエフェクトゥス|指揮官]]</rb><rp>（</rp><rt>プラエフェクトゥス</rt><rp>）</rp></ruby>たちや[[w:トリブヌス・ミリトゥム|軍団次官]]たちのかなりの数を、近隣諸部族のところへ *frumenti (commeatusque petendi) causa dimisit; **穀物や糧食を求めるために送り出した。 *quo in numero est [[wikt:en:T.#Latin|T.]] Terrasidius missus in Esuvios<!--/ Unellos Essuviosque-->, **その人員のうち、ティトゥス・テッラシディウスは、エスウィイー族<!--ウネッリー族やエスウィイ族-->のところに遣わされ、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：テッラシディウスは騎士階級の将校。''[[w:en:Terrasidius|Terrasidius]]'' 参照。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：エスウィイー族 ''[[w:en:Esuvii|Esuvii]]'' は、現在の[[w:オルヌ川|オルヌ川]]盆地の[[w:オルヌ県|オルヌ県]][[w:セー (オルヌ県)|セー]]～[[w:fr:Exmes|エム]]の辺りにいたらしい。）</span> *[[wikt:en:M.#Latin|M.]] [[wikt:en:Trebius#Latin|Trebius]] Gallus in Coriosolităs, **マールクス・トレビウス・ガッルスは、コリオソリテース族のところに（遣わされ）、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:it:Marco Trebio Gallo|it:Marco Trebio Gallo]]'' 等参照）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：コリオソリテース族 ''[[w:en:Coriosolites|Coriosolites]]'' は、クーリオソリーテース ''[[wikt:en:Curiosolites|Curiosolites]]'' などとも呼ばれ、<br>　　　　現在の[[w:コート＝ダルモール県|コート＝ダルモール県]]コルスール([[w:en:Corseul|Corseul]])の辺りにいたらしい。）</span> *[[wikt:en:Q.|Q.]] [[wikt:en:Velanius#Latin|Velanius]] cum T. Sillio in Venetos. **クゥイーントゥス・ウェラーニウスはティトゥス・シーッリウスとともに、[[w:ウェネティ族 (ガリア)|ウェネティー族]]のところに（遣わされた）。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:it:Quinto Velanio|it:Quinto Velanio]], [[w:it:Tito Silio|it:Tito Silio]]'' 等参照。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:ウェネティ族 (ガリア)|ウェネティー族]] ''[[w:en:Veneti (Gaul)|Veneti (Gaul)]]'' は、[[w:アルモリカ|アルモリカ]]南西部、現在の[[w:モルビアン県|モルビアン県]]辺りにいた。）</span> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===8節=== *<span style="background-color:#ffd;">[[/注解/8節]]　{{進捗|00%|2022-06-13}}</span> '''ウェネティー族らの動き''' <br> ;　　　沿海地方を主導するウェネティー族 *Huius est civitatis longe amplissima auctoritas omnis orae maritimae regionum earum, **この部族〔ウェネティー族〕の<ruby><rb>影響力</rb><rp>（</rp><rt>アウクトーリタース</rt><rp>）</rp></ruby>は、海岸のその全地方の中でずば抜けて大きい。 *quod et naves habent Veneti plurimas, **── というのは、[[w:ウェネティ族 (ガリア)|ウェネティー族]]は、最も多くの船舶を持っており、 *quibus in Britanniam navigare consuerunt, **それら〔船団〕によって[[w:ブリタンニア|ブリタンニア]]に航海するのが常であり、 *et scientia atque usu rerum nauticarum ceteros antecedunt **かつ[[w:海事|海事]]の知識と経験において他の者たち〔諸部族〕をしのいでおり、 *et in magno impetu maris atque aperto &lt;Oceano&gt; **かつ海のたいへんな荒々しさと開けた&lt;<ruby><rb>大洋〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>&gt;において、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：&lt;Oceano&gt; は写本になく、挿入提案された修正読み）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:大陸棚|大陸棚]]が広がる[[w:ビスケー湾|ビスケー湾]]は、世界最大12mの大きな[[w:潮汐|干満差]]と、<br>　　　　北西風による激しい嵐で知られる<ref>[https://kotobank.jp/word/%E3%83%93%E3%82%B9%E3%82%B1%E3%83%BC%E6%B9%BE-119819 ビスケー湾とは - コトバンク]</ref>。）</span> *paucis portibus interiectis, **わずかの港が介在していて、 *quos tenent ipsi, **彼ら自身〔ウェネティー族〕がそれら〔港湾〕を制していて、 *omnes fere qui eo mari uti consuerunt, habent vectigales. **その海を利用するのが常であった者たち〔部族〕ほぼすべてを、貢税者としていたのだ。── <br> ;　　　ウェネティー族が、クラッススの使節たちを抑留する *Ab his fit initium retinendi Sillii atque Velanii, **彼ら〔ウェネティー族〕によって、シーッリウスとウェラーニウスを拘束することが皮切りとなる。 **:<span style="color:#009900;">（訳注：2人は、前節([[#7節]])でウェネティー族への派遣が述べられた使節）</span> *<u>et si quos intercipere potuerunt</u> **何らかの者たちを捕えることができたのではないか、と。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：下線部は、&beta;系写本だけの記述で、&alpha;系写本にはない。）</span> *quod per eos suos se obsides, quos Crasso dedissent, recuperaturos existimabant. **というのは、彼らを介して、[[w:プブリウス・リキニウス・クラッスス|クラッスス]]に差し出されていた己の人質たちを取り戻すことができると考えていたのである。 <br> *Horum auctoritate finitimi adducti, **彼ら〔ウェネティー族〕の影響力によって、近隣の者たち〔諸部族〕が動かされて、 *ut sunt Gallorum subita et repentina consilia, **──ガッリア人の判断力というものは、思いがけなく性急なものであるが、── *eadem de causa Trebium Terrasidiumque retinent **同じ理由によりトレビウスとテッラシディウスを拘束する。 **:<span style="color:#009900;">（訳注：トレビウスは、前節でコリオソリテース族に派遣された。<br>　　　　テッラシディウスは、前節でエスウィイー族に派遣された。）</span> *et celeriter missis legatis **そして速やかに使節が遣わされて、 *per suos principes inter se coniurant **自分らの領袖たちを通して互いに誓約する。 *nihil nisi communi consilio acturos eundemque omnes fortunae exitum esse laturos, **合同の軍議なしには何も実施しないであろうし、皆が命運の同じ結果に耐えるであろう、と。 *reliquasque civitates sollicitant, **残りの諸部族を扇動する。 *ut in ea libertate quam a maioribus acceperint, permanere quam Romanorum servitutem perferre malint. **ローマ人への隷属を辛抱することより、むしろ先祖から引き継いでいた自由に留まることを欲すべし、と。 <br> *Omni ora maritima celeriter ad suam sententiam perducta **すべての海岸（の諸部族）が速やかに自分たち〔ウェネティー族〕の見解に引き込まれると、 *communem legationem ad [[wikt:en:Publium|Publium]] Crassum mittunt, **共同の使節を[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス]]のもとへ遣わす。 *si velit suos recuperare, obsides sibi remittat. **もし味方の者たち〔ローマ人〕を取り戻すことを望むならば、自分たち〔諸部族〕の人質たちを返すように、と。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===9節=== *<span style="background-color:#ffd;">[[/注解/9節]]　{{進捗|00%|2022-06-19}}</span> {{Wikipedia|la:Liger| Liger }} '''カエサル到着、ウェネティー族らの作戦と開戦準備''' ;　　　カエサルが、海戦の準備を手配してから、沿岸地域に急ぐ *Quibus de rebus Caesar a Crasso certior factus, **以上の事について、カエサルは[[w:プブリウス・リキニウス・クラッスス|クラッスス]]により報知されると、 *quod ipse aberat longius, **（カエサル）自身は非常に遠くに離れていたので、 **:<span style="color:#009900;">（訳注：[[#コラム「ルカ会談」|#ルカ会談]]などローマへの政界工作のために属州にいたと考えられている。）</span> *naves interim longas aedificari in flumine [[wikt:la:Liger#Latine|Ligeri]], quod influit in Oceanum, **その間に<u>軍船</u>が<ruby><rb>大洋〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>に流れ込むリゲル川〔[[w:ロワール川|ロワール川]]〕にて建造されること、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：艦隊 [[w:la:Classis Romana|classis]] の主力として戦う[[w:ガレー船|ガレー船]]は「長船」[[w:la:Navis longa|navis longa]] と呼ばれていた。<br>　　　　これに対して、軍需物資を運搬する輸送船は [[w:la:Navis actuaria|navis actuaria]] と呼ばれていた。）</span> *remiges ex provincia institui, **<ruby><rb>漕ぎ手</rb><rp>（</rp><rt>レーメクス</rt><rp>）</rp></ruby>が属州〔[[w:ガリア・トランサルピナ|ガッリア・トランサルピーナ]]〕から採用されること、 *nautas gubernatoresque comparari iubet. **<ruby><rb>[[w:船員|水夫]]</rb><rp>（</rp><rt>ナウタ</rt><rp>）</rp></ruby>や<ruby><rb>操舵手</rb><rp>（</rp><rt>グベルナートル</rt><rp>）</rp></ruby>が徴募されること、を命じる。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：船尾の「<ruby><rb>[[w:舵|舵]]</rb><rp>（</rp><rt>かじ</rt><rp>）</rp></ruby>」が発明されたのは[[w:漢|漢代]]の中国であって、古代西洋の船に<ruby><rb>舵</rb><rp>（</rp><rt>かじ</rt><rp>）</rp></ruby>はない。<br>　　　　船の操舵手は「<ruby><rb>舵櫂</rb><rp>（</rp><rt>かじかい</rt><rp>）</rp></ruby>」(''[[w:en:Steering oar|steering oar]]'') という[[w:櫂|櫂]]の一種を用いて操船したらしい。）</span> <br> *His rebus celeriter administratis ipse, **これらの事柄が速やかに処理されると、（カエサル）自身は *cum primum per anni tempus potuit, ad exercitum contendit. **年のできるだけ早い時季に、軍隊のもとへ急いだ。 <br> ;　　　ウェネティー族らが、使節団拘留の重大さを勘案して、海戦の準備を進める *Veneti reliquaeque item civitates cognito Caesaris adventu **[[w:ウェネティ族 (ガリア)|ウェネティー族]]と残りの部族もまた、カエサルの到着を知り、 *<span style="color:#009900;">&lt;</span>et de recipiendis obsidibus spem se fefellise<span style="color:#009900;">&gt;</span> certiores facti, **<span style="color:#009900;">&lt;</span>かつ人質を取り戻すという希望に惑わされたことを<span style="color:#009900;">&gt;</span> 知らされて、 *simul quod quantum in se facinus admisissent intellegebant, **同時に、どれほど大それた行為を自分たちが侵していたかを判断していたので、 *<span style="color:#009900;">[</span>legatos, quod nomen ad omnes nationes sanctum inviolatumque semper fuisset, **──（すなわち）あらゆる種族のもとでその名が神聖かつ不可侵の、使節たちが *retentos ab se et in vincula coniectos,<span style="color:#009900;">]</span> **自分たちによって拘束され、鎖につながれていたわけだが、── *pro magnitudine periculi bellum parare **危機の重大さに見合う戦争を準備すること、 *et maxime ea quae ad usum navium pertinent providere instituunt, **とりわけ船団を運用するために役立つところのものを調達すること、を着手する。 *hoc maiore spe quod multum natura loci confidebant. **地勢を大いに信じていた点に大きな期待をして。 <br> *Pedestria esse itinera concisa aestuariis, **（ローマ勢の）歩兵の行軍路は入江で遮断されるし、 *navigationem impeditam propter inscientiam locorum paucitatemque portuum sciebant, **土地の不案内と港の少なさのゆえに航行が妨げられることを（ウェネティー族らは）知っていた。 *neque nostros exercitus propter inopiam frumenti diutius apud se morari posse confidebant; **穀物の欠乏のゆえに、我が軍〔ローマ軍〕がより長く彼らのもとに留まることができないと（ウェネティー族らは）信じ切っていた。 <br> *ac iam ut omnia contra opinionem acciderent, **やがて、すべてのことが予想に反して生じたとしても、 *tamen se plurimum navibus posse, quam Romanos neque ullam facultatem habere navium, **けれども自分たち〔ウェネティー族ら〕は艦船において、艦船の備えを何ら持たないローマ人よりも大いに優勢であり、 *neque eorum locorum, ubi bellum gesturi essent, vada, portus, insulas novisse; **戦争を遂行しようとしているところの浅瀬・港・島に（ローマ人は）不案内であった（と信じ切っていた）。 <br> *ac longe aliam esse navigationem in concluso mari atque in vastissimo atque apertissimo Oceano perspiciebant. **閉ざされた海〔[[w:地中海|地中海]]〕と非常に広大で開けた大洋における航行はまったく別物であると見通していた。 <br> *His initis consiliis **この作戦計画が決められると、 *oppida muniunt, **<ruby><rb>[[w:オッピドゥム|城塞都市]]</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の防備を固め、 *frumenta ex agris in oppida comportant, **穀物を耕地から<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>に運び込み、 *naves in [[wikt:en:Venetia#Latin|Venetiam]], ubi Caesarem primum (esse) bellum gesturum constabat, quam plurimas possunt, cogunt. **カエサルが最初の戦争を遂行するであろうことが明白であったところの[[w:ウェネティ族 (ガリア)|ウェネティー族]]領に、ありったけの艦船を集める。 <br> *Socios sibi ad id bellum **この戦争のために（ウェネティー族は）自分たちのもとへ同盟者として *[[wikt:en:Osismi#Latin|Osismos]], [[wikt:en:Lexovii#Latin|Lexovios]], [[wikt:en:Namnetes#Latin|Namnetes]], Ambiliatos, [[wikt:en:Morini#Latin|Morinos]], [[w:en:Diablintes|Diablintes]], [[wikt:en:Menapii#Latin|Menapios]] adsciscunt; **<span style="font-size:10pt;">オスィスミー族・レクソウィイー族・ナムネーテース族・アンビリアーティー族・モリニー族・ディアブリンテース族・メナピイー族</span>&nbsp;を引き入れる。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：アンビリアーティー族 ➡ [[w:ガイウス・プリニウス・セクンドゥス|プリニウス]]は「アンビラトリー族」 [[wikt:en:Ambilatri#Latin|Ambilatri]] と記す。<br>　　　　ディアブリンテース族 ➡ プリニウスは「ディアブリンティー族」 [[wikt:en:Diablinti#Latin|Diablinti]] と記す。<br>　　　　　　　　　　　　　　　　この部族は、アウレルキー族 ''[[w:en:Aulerci|Aulerci]]'' の支族。）</span> *auxilia ex Britannia, quae contra eas regiones posita est, arcessunt. **援軍を、この地域の向かい側に位置する[[w:ブリタンニア|ブリタンニア]]から呼び寄せた。 **:<span style="color:#009900;">（訳注：援軍を出したという口実のもと、翌年カエサルがブリタンニアに侵攻することになる。）</span> <div style="text-align:center"> {| |- |[[画像:Map of Aremorican tribes (Latin).svg|thumb|right|600px|[[w:アルモリカ|アルモリカ]]（<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Armorica|Armorica]]''</span> ）の部族分布図。 ]] |} </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===10節=== *<span style="background-color:#ffd;">[[/注解/10節]]　{{進捗|00%|2022-07-02}}</span> '''カエサルの開戦への大義名分''' *Erant hae difficultates belli gerendi, quas supra ostendimus, **上で指摘したような、戦争を遂行することの困難さがあった。 *sed tamen multa Caesarem ad id bellum incitabant: **にもかかわらず、多くのことがカエサルをその戦争へと駆り立てていたのだ。 *iniuria retentorum equitum Romanorum, **①ローマ人の[[w:エクィテス|騎士]]〔騎士階級の者〕たちが拘束されることの無法さ、 *rebellio facta post deditionem, **②降伏の後でなされた造反、 *defectio datis obsidibus, **③人質を供出しての謀反、 *tot civitatum coniuratio, **④これほど多くの部族の共謀、 *in primis ne hac parte neglecta reliquae nationes sibi idem licere arbitrarentur. **⑤何よりも第一に、この地方をなおざりにして、残りの種族が自分たちも同じことを許容されると思い込まないように。 *Itaque cum intellegeret **そこで、（カエサルは以下のように）認識していたので、 *omnes fere Gallos novis rebus studere et ad bellum mobiliter celeriterque excitari, **①ほぼすべてのガリア人が政変を熱望して、戦争へ簡単に速やかに奮い立たせられていること、 *omnes autem homines natura libertati studere incitari et condicionem servitutis odisse, **②他方ですべての人間は本来的に自由を熱望することに扇動され、隷属の状態を嫌っていること、 *prius quam plures civitates conspirarent, **多くの部族が共謀するより前に、 *partiendum sibi ac latius distribuendum exercitum putavit. **（カエサルは）自分にとって軍隊が分けられるべき、より広範に割り振られるべきであると考えた。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===11節=== *<span style="background-color:#ffd;">[[/注解/11節]]　{{進捗|00%|2022-07-03}}</span> '''ラビエーヌス、クラッスス、サビーヌス、ブルートゥスを前線へ派兵する''' <br><br> ;　　　副官ラビエーヌスをトレウェリー族のもとへ遣わす *Itaque [[wikt:en:Titum|T.]] [[wikt:en:Labienus#Latin|Labienum]] legatum in [[wikt:en:Treveri#Latin|Treveros]], qui proximi flumini Rheno sunt, cum equitatu mittit. **こうして、<ruby><rb>[[w:レガトゥス|副官]]</rb><rp>（</rp><rt>レガトゥス</rt><rp>）</rp></ruby>[[w:ティトゥス・ラビエヌス|ティトゥス・ラビエーヌス]]をレーヌス川〔[[w:ライン川|ライン川]]〕に最も近いトレーウェリー族に、騎兵隊とともに派遣する。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:la:Titus Labienus|Titus Labienus]] は、『ガリア戦記』におけるカエサルの片腕。<br>　　　　''[[w:en:Treveri|Treveri]]'' はローマの同盟部族だが、[[ガリア戦記_第5巻|第5巻]]・[[ガリア戦記_第6巻|第6巻]]で挙兵する。）</span> *Huic mandat, **彼に（以下のように）命じる。 *[[wikt:en:Remi#Latin|Remos]] reliquosque [[wikt:en:Belgas|Belgas]] adeat atque in officio contineat **①レーミー族やほかの[[w:ベルガエ|ベルガエ人]]を訪れて、<ruby><rb>忠実さ</rb><rp>（</rp><rt>オッフィキウム</rt><rp>）</rp></ruby>に留めるように、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:en:Remi|Remi]]'' は、ローマの同盟部族で、[[ガリア戦記_第2巻#3節|第2巻3節]]以降で言及された。）</span> *[[wikt:en:Germanos|Germanos]]que, qui auxilio a Gallis arcessiti dicebantur, **②ガッリア人により援兵として呼び寄せられたといわれていた[[w:ゲルマニア|ゲルマーニア]]人が **:<span style="color:#009900;">（訳注：第1巻で言及された[[w:アリオウィストゥス|アリオウィストゥス]]の軍勢のこと。）</span> *si per vim navibus flumen transire conentur, prohibeat. **（彼らが）もし力ずくで船で川を渡ることを試みるならば、防ぐように、と。 <br> ;　　　クラッスス青年をアクィーターニアに派遣する *[[wikt:en:Publium|P.]] [[wikt:en:Crassus#Latin|Crassum]] cum cohortibus legionariis XII(duodecim) et magno numero equitatus in Aquitaniam proficisci iubet, **[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス]]には、軍団の12個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>と多数の騎兵隊とともに、[[w:アクィタニア|アクィーターニア]]に出発することを命じる。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:la:Publius Licinius Crassus|Publius Licinius Crassus]]、[[#7節]]から既述。）</span> *ne ex his nationibus auxilia in Galliam mittantur ac tantae nationes coniungantur. **これらの種族から援兵がガッリアに派遣され、これほど多くの諸部族が結託することがないように。 <br> ;　　　副官サビーヌスを3個軍団とともに[[w:アルモリカ|アルモリカ]]北部へ派兵する *[[wikt:en:Quintum#Latin|Q.]] [[wikt:en:Titurius#Latin|Titurium]] Sabinum legatum cum legionibus tribus **副官[[w:クィントゥス・ティトゥリウス・サビヌス|クィーントゥス・ティトゥリウス・サビーヌス]]を3個軍団とともに **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:en:Quintus Titurius Sabinus|Quintus Titurius Sabinus]]'' は[[ガリア戦記_第2巻#5節|第2巻5節]]から言及されている『ガリア戦記』前半で活躍する副官。）</span> *in [[wikt:en:Unelli#Latin|Unellos]](Venellos), Coriosolităs [[wikt:en:Lexovii#Latin|Lexovios]]que mittit, qui eam manum distinendam curet. **ウネッリー族・コリオソリテース族・レクソウィイー族に派遣して、彼らの手勢を分散させるべく配慮するように。 <br> ;　　　ブルートゥス青年をウェネティー族領へ派兵する *[[wikt:en:Decimus#Latin|D.]] [[wikt:en:Brutum|Brutum]] adulescentem classi Gallicisque navibus, **[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|デキムス・ブルートゥス青年]]に、（ローマの）艦隊とガッリア人の船団を、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:la:Decimus Iunius Brutus Albinus|Decimus Iunius Brutus Albinus]] は、カエサルの副官として活躍するが、後に暗殺に加わる。）</span> *quas ex [[wikt:en:Pictones#Latin|Pictonibus]] et [[wikt:en:Santoni#Latin|Santonis]] reliquisque pacatis regionibus convenire iusserat, **──これら（船団）はピクトネース族・サントニー族やほかの平定された地方から集まるように命じていたものであるが、── *praeficit et, cum primum possit, in [[wikt:en:Veneti#Latin|Venetos]] proficisci iubet. **（ブルートゥスに船団を）指揮させて、できるだけ早く[[w:ウェネティ族 (ガリア)|ウェネティー族]]（の領土）に出発することを命じる。 <br> *Ipse eo pedestribus copiis contendit. **（カエサル）自身は、そこへ歩兵の軍勢とともに急ぐ。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===12節=== *<span style="background-color:#ffd;">[[/注解/12節]]　{{進捗|00%|2022-07-09}}</span> '''ウェネティー族の城塞都市の地勢、海洋民の機動性''' <div style="text-align:center"> {| |- |[[画像:Bretagne Finistere PointeduRaz15119.jpg|thumb|right|350px|ウェネティー族の[[w:オッピドゥム|城塞都市]]があった[[w:ブルターニュ半島|ブルターニュ半島]]の突き出た地形]] |} </div> *Erant [[wikt:en:eiusmodi|eiusmodi]] fere situs oppidorum, **（[[w:ウェネティ族 (ガリア)|ウェネティー族]]の）<ruby><rb>[[w:オッピドゥム|城塞都市]]</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の地勢はほぼ以下のようであった。 *ut posita in extremis [[wikt:en:lingula#Latin|lingulis]] [[wikt:en:promunturium#Latin|promunturiis]]que **<ruby><rb>[[w:砂嘴|砂嘴]]</rb><rp>（</rp><rt>リングラ</rt><rp>）</rp></ruby>や[[w:岬|岬]]の先端部に位置しているので、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:lingula#Latin|lingula]] ⇒ [[w:la:Lingua terrae|lingua terrae]] (舌状地) ≒ <ruby><rb>[[w:砂嘴|砂嘴]]</rb><rp>（</rp><rt>さし</rt><rp>）</rp></ruby>(くちばし状の砂地)。）</span> *neque pedibus aditum haberent, cum ex alto se [[wikt:en:aestus#Latin|aestus]] incitavisset, **沖合から<ruby><rb>[[w:潮汐|潮　汐]]</rb><rp>（</rp><rt>アエトゥス</rt><rp>）</rp></ruby>が押し寄せて来たとき<span style="color:#009900;">〔満潮〕</span>に、徒歩での<ruby><rb>接近路</rb><rp>（</rp><rt>アプローチ</rt><rp>）</rp></ruby>を持っていなかった。 *quod bis accidit semper horarum XII(duodenarum) spatio, **というのは<span style="color:#009900;">（満潮が毎日）</span>2度、常に12時間の間隔で起こるためである。 <div style="text-align:center"> {| |- |[[画像:Astronomical tide IJmuiden 21 January 2012.png|thumb|right|600px|ある日（24時間）の'''[[w:潮位|潮位]]'''予測グラフの例（2012年、オランダ北海沿岸のエイマイデン）。<br>満潮や干潮は、約12時間の周期で繰り返されることが多いため、たいてい1日2回ずつ生じる。]] |} </div> *neque navibus, **船で（のアプローチ）もなく、 *quod rursus minuente aestu naves in vadis adflictarentur. **というのは、潮が再び減ると<span style="color:#009900;">〔干潮〕</span>、船団が[[w:浅瀬|浅瀬]]で損傷してしまうためである。 *Ita utraque re oppidorum oppugnatio impediebatur; **このように<span style="color:#009900;">（陸路・海路）</span>どちらの状況においても、<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の攻略は妨げられていた。 <br><br> *ac si quando magnitudine operis forte superati, **あるとき、期せずして<span style="color:#009900;">（ウェネティー族がローマ人の）</span><ruby><rb>構造物</rb><rp>（</rp><rt>オプス</rt><rp>）</rp></ruby>の大きさに圧倒されて、 *extruso mari aggere ac molibus **<span style="color:#009900;">（ローマ人が建造した）</span><ruby><rb>土手</rb><rp>（</rp><rt>アッゲル</rt><rp>）</rp></ruby>や<ruby><rb>[[w:防波堤|防波堤]]</rb><rp>（</rp><rt>モーレース</rt><rp>）</rp></ruby>により海水が押し出され、 *atque his oppidi moenibus adaequatis, **これら<span style="color:#009900;">〔堡塁〕</span>が<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の城壁と<span style="color:#009900;">（高さにおいて）</span>等しくされ、 *suis fortunis desperare coeperant, **<span style="color:#009900;">（ウェネティー族らが）</span>自分たちの命運に絶望し始めていたとしても、 *magno numero navium adpulso, **船の多数を接岸して、 *cuius rei summam facultatem habebant, **それら〔船〕の供給に最大の備えを持っていたので、 *omnia sua deportabant seque in proxima oppida recipiebant; **自分たちの<ruby><rb>一切合財</rb><rp>（</rp><rt>オムニア</rt><rp>）</rp></ruby>を運び去って、最も近い<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>に撤収していた。 *ibi se rursus isdem opportunitatibus loci defendebant. **そこにおいて再び同じような地の利によって防戦していたのだ。 <br><br> *Haec [[wikt:en:eo#Latin|eo]] facilius magnam partem aestatis faciebant, **以上のことが、夏の大部分を<span style="color:#009900;">（ウェネティー族にとって）</span>より容易にしていた。 *quod nostrae naves [[wikt:en:tempestas#Latin|tempestatibus]] detinebantur, **なぜなら、我が方〔ローマ人〕の船団は嵐により<span style="color:#009900;">（航行を）</span>阻まれており、 *summaque erat **<span style="color:#009900;">（航行することの困難さが）</span>非常に大きかった。 *vasto atque aperto mari, **海は広大で開けており、 *magnis aestibus, **<ruby><rb>潮流</rb><rp>（</rp><rt>アエトゥス</rt><rp>）</rp></ruby>が激しく、 *raris ac prope nullis portibus **港は<ruby><rb>疎</rb><rp>（</rp><rt>まば</rt><rp>）</rp></ruby>らでほとんどないので、 *difficultas navigandi. **航行することの困難さが<span style="color:#009900;">（非常に大きかった）</span>。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===13節=== *<span style="background-color:#ffd;">[[/注解/13節]]　{{進捗|00%|2022-07-10}}</span> '''ウェネティー族の帆船の特徴''' <div style="background-color:#ededed; width:90%; text-align:center"> {| |- | colspan="2" |ウェネティー族の船の再現画（左下に兵士の大きさが示されている） | rowspan="2" style="background-color:#fff;" |&nbsp; | rowspan="2" style="vertical-align:bottom;" |[[画像:Navis longa ja.JPG|thumb|right|350px|古代ローマの軍船（[[w:ガレー船|ガレー船]]）の構成]] |- | style="vertical-align:bottom;" |[[画像:Navire venete.svg|thumb|right|200px|一つの帆をもつ帆船の例]] | style="vertical-align:bottom;" |[[画像:Navire venete 2.svg|thumb|right|200px|二つの帆をもつ帆船の例]] |} </div> *Namque ipsorum naves ad hunc modum factae armataeque erant: **これに対して彼ら<span style="color:#009900;">〔[[w:ウェネティ族 (ガリア)|ウェネティー族]]〕</span>自身の[[w:帆船|船]]は、以下のやり方で建造され、<ruby><rb>[[w:艤装|艤装]]</rb><rp>（</rp><rt>ぎそう</rt><rp>）</rp></ruby>されていた。 ;　竜骨 *[[wikt:en:carina#Latin|carinae]] [[wikt:en:aliquanto|aliquanto]] planiores quam nostrarum navium, **<ruby><rb>[[w:竜骨 (船)|竜　骨]]</rb><rp>（</rp><rt>カリーナ</rt><rp>）</rp></ruby>は、我が方<span style="color:#009900;">〔ローマ人〕</span>の船のものよりも、いくらか平らで、 **:<span style="color:#009900;">（訳注：[[w:竜骨 (船)|竜骨]]は、船底に突き出た背骨部分で、[[w:帆船|帆船]]が風で横滑りしないように造られていた。）</span> *quo facilius vada ac decessum aestus excipere possent; **それによって、より容易に[[w:浅瀬|浅瀬]]&nbsp;や&nbsp;[[w:潮汐|潮]]が退くこと<span style="color:#009900;">〔干潮〕</span>を持ち応えることができた。 ;　船首と船尾 *[[wikt:en:prora#Latin|prorae]] admodum erectae atque item [[wikt:en:puppis|puppes]], **<ruby><rb>[[w:船首|船　首]]</rb><rp>（</rp><rt>プローラ</rt><rp>）</rp></ruby>はまったく直立しており、<ruby><rb>[[w:船尾|船　尾]]</rb><rp>（</rp><rt>プッピス</rt><rp>）</rp></ruby>も同様で、 *ad magnitudinem fluctuum tempestatumque adcommodatae; **<ruby><rb>[[w:波#波浪（風浪とうねり）|波　浪]]</rb><rp>（</rp><rt>フルークトゥス</rt><rp>）</rp></ruby> や <ruby><rb>[[w:嵐|暴風雨]]</rb><rp>（</rp><rt>テンペスタース</rt><rp>）</rp></ruby> の激しさに適応していた。 ;　船体の材質 *naves totae factae ex [[wikt:en:robur#Latin|robore]] ad quamvis vim et contumeliam perferendam; **船は、どんな力や衝撃にも耐えるために、全体として[[w:オーク|オーク材]]で造られていた。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:la:robur|robur]] は ''[[wikt:en:oak#English|oak]]'' と英訳され、[[w:樫#Japanese|樫]]と訳されることが多いが、<br>　　　　「<ruby><rb>[[w:カシ|樫]]</rb><rp>（</rp><rt>カシ</rt><rp>）</rp></ruby>」は常緑樹であり、西洋では落葉樹である「<ruby><rb>[[w:ナラ|楢]]</rb><rp>（</rp><rt>ナラ</rt><rp>）</rp></ruby>」が多い。<br>　　　　　学名 [[w:la:Quercus robur|Quercus robur]] は「[[w:ヨーロッパナラ|ヨーロッパナラ]]」と訳される。）</span> ;　横梁 *[[wikt:en:transtrum#Latin|transtra]] ex pedalibus in altitudinem [[wikt:en:trabs#Latin|trabibus]], confixa [[wikt:en:clavus#Latin|clavis]] [[wikt:en:ferreus#Latin|ferreis]] digiti [[wikt:en:pollex#Latin|pollicis]] crassitudine; **<ruby><rb>横梁(横木)</rb><rp>（</rp><rt>トラーンストルム</rt><rp>）</rp></ruby>は、1ペースの幅の<ruby><rb>材木</rb><rp>（</rp><rt>トラプス</rt><rp>）</rp></ruby>からなり、親指の太さほどの鉄製の[[w:釘|釘]]で固定されていた。 **:<span style="font-family:Times New Roman;color:#009900;">（訳注：1[[ガイウス・ユリウス・カエサルの著作/通貨・計量単位#ペース|ペース]]は約29.6cm。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:transtrum#Latin|transtra]] は、<ruby><rb>[[w:マスト|帆柱]]</rb><rp>（</rp><rt>マスト</rt><rp>）</rp></ruby>（[[wikt:en:malus#Etymology_3_2|malus]]）を船に固定するための<ruby><rb>横梁(横木)</rb><rp>（</rp><rt>クロスビーム</rt><rp>）</rp></ruby>とも考えられる。）</span> ;　錨(いかり)の索具 *[[wikt:en:ancora#Latin|ancorae]] pro [[wikt:en:funis#Latin|funibus]] ferreis catenis revinctae; **<ruby><rb>[[w:錨|錨]]</rb><rp>（</rp><rt>アンコラ</rt><rp>）</rp></ruby>は、<ruby><rb>[[w:ロープ|縄　索]]</rb><rp>（</rp><rt>フーニス</rt><rp>）</rp></ruby>の代わりに鉄製の[[w:鎖|鎖]]でつながれていた。 <div style="background-color:#eee; width:600px; text-align:center"> {| |- | style="vertical-align:bottom;" |[[画像:Nemi 060 museo delle Navi.jpg|thumb|right|180px|[[w:la:Ancora|ancora]] ([[w:錨|錨]])(古代ローマ)]] | style="vertical-align:bottom;" |[[画像:Cordage en chanvre.jpg|thumb|right|150px|[[w:la:Funis|funis]] (綱の[[w:ロープ|ロープ]])]] | style="vertical-align:bottom;" |[[画像:Old chain.jpg|thumb|right|150px|[[w:la:Catena|catena]] ([[w:鎖|鎖]])]] |} </div> <br> ;　帆の材質 *[[wikt:en:pellis#Latin|pelles]] pro [[wikt:en:velum#Latin|velis]] [[wikt:en:aluta#Latin|alutae]]que tenuiter confectae, **<ruby><rb>[[w:帆布|帆　布]]</rb><rp>（</rp><rt>ウェールム</rt><rp>）</rp></ruby>の代わりに<ruby><rb>[[w:毛皮|毛皮]]</rb><rp>（</rp><rt>ペッリス</rt><rp>）</rp></ruby>や、薄く作製された<ruby><rb>なめし皮</rb><rp>（</rp><rt>アルータ</rt><rp>）</rp></ruby>が（用いられた）。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:pellis#Latin|pellis]] は<ruby><rb>鞣</rb><rp>（</rp><rt>なめ</rt><rp>）</rp></ruby>していない生皮、[[wikt:en:aluta#Latin|aluta]] は<ruby><rb>鞣</rb><rp>（</rp><rt>なめ</rt><rp>）</rp></ruby>した[[w:皮革|皮革]] [[wikt:en:corium#Latin|corium]] のこと。）</span> <div style="background-color:#eee; width:600px; text-align:center"> {| |- | style="vertical-align:bottom;" |[[画像:Linen canvas.jpg|thumb|right|150px|<ruby><rb>[[w:リネン|亜麻布]]</rb><rp>（</rp><rt>リネン</rt><rp>）</rp></ruby>の[[w:帆布|帆布]] ]] | style="vertical-align:bottom;" |[[画像:Kissen aus indischem Antilopenfell 2013.jpg|thumb|right|100px|[[w:la:Pellis|pellis]] ([[w:毛皮|毛皮]])]] | style="vertical-align:bottom;" |[[画像:Natural Bridge State Park (30337351644).jpg|thumb|right|200px|aluta ([[w:en:Tanning (leather)|なめし皮]])]] |} </div> *[hae] sive propter inopiam [[wikt:en:linum#Latin|lini]] atque eius usus inscientiam, **[これは] あるいは、<ruby><rb>[[w:アマ (植物)|亜麻]]</rb><rp>（</rp><rt>リーヌム</rt><rp>）</rp></ruby>の不足ゆえや、その利用に無知であるゆえか、 **:<span style="color:#009900;">（訳注：ローマ人には、[[w:リネン|亜麻布 (リネン)]]で帆を作る慣習があった。）</span> *sive eo, quod est magis [[wikt:en:verisimilis#Latin|veri simile]], **あるいは、この方がより真実に近いのだろうが、 *quod tantas tempestates Oceani tantosque impetus ventorum sustineri **<ruby><rb>[[w:オーケアノス|大洋]]〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>のあれほどの嵐や、風のあれほどの激しさに持ち応えること、 *ac tanta onera navium regi **船のあれほどの重さを制御することは、 *[[wikt:en:velum#Latin|velis]] non satis commode posse arbitrabantur. **<ruby><rb>帆　布</rb><rp>（</rp><rt>ウェールム</rt><rp>）</rp></ruby>にとって十分に具合良くできないと、<span style="color:#009900;">（ウェネティー族は）</span>考えていたためであろう。 <br><br> ;　　ウェネティー船団とローマ艦隊の優劣 *Cum his navibus nostrae classi eiusmodi congressus erat, **彼ら<span style="color:#009900;">〔ウェネティー族〕</span>の船団と、我が方<span style="color:#009900;">〔ローマ軍〕</span>の艦隊は、以下のように交戦していた。 *ut una celeritate et pulsu remorum praestaret, **迅速さと<ruby><rb>[[w:櫂|櫂]](かい)</rb><rp>（</rp><rt>レームス</rt><rp>）</rp></ruby>を<ruby><rb>漕</rb><rp>（</rp><rt>こ</rt><rp>）</rp></ruby>ぐのだけは<span style="color:#009900;">（ローマ艦隊が）</span>よりまさっていたのだが、 *reliqua pro loci natura, pro vi tempestatum **そのほかのことは、地勢や嵐の勢いを考慮すると、 *illis essent aptiora et adcommodatiora. **彼ら<span style="color:#009900;">〔ウェネティー族〕</span>にとってより適しており、より好都合であった。 *Neque enim his nostrae rostro nocere poterant **なぜなら、我が方<span style="color:#009900;">〔ローマ艦隊〕</span>の<ruby><rb>[[w:衝角|衝　　角]]</rb><rp>（</rp><rt>ローストルム</rt><rp>）</rp></ruby>によって彼ら<span style="color:#009900;">（の船）</span>に対して損壊することができず、 *── tanta in iis erat firmitudo ──, **──それら<span style="color:#009900;">〔ウェネティー族の船〕</span>においては<span style="color:#009900;">（船体の）</span>それほどの頑丈さがあったのだが── *neque propter altitudinem facile telum adigebatur, **<span style="color:#009900;">（ウェネティー族の船体の）</span>高さのゆえに、飛道具がたやすく投げ込まれなかったし、 *et eadem de causa minus commode <u>[[wikt:en:copula#Latin|copulis]]</u> continebantur. **同じ理由から、あまり都合よく <ruby><rb><u>[[w:鉤縄|鉤縄]]</u></rb><rp>（</rp><rt>かぎなわ</rt><rp>）</rp></ruby> で<span style="color:#009900;">（敵船が）</span>つなぎ止められなかった。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：下線部は、古い写本では [[wikt:en:scopulus#Latin|scopulis]]「岩礁」だが、<br>　　　　後代の写本で修正され「[[w:鉤縄|鉤縄]]」と解釈されている。下図参照。）</span> <div style="background-color:#eee; width:350px; text-align:center"> {| |- | style="vertical-align:bottom;" |[[画像:Grappling hook 2 (PSF).png|thumb|right|410px|[[w:海戦|海戦]]において敵船に[[w:移乗攻撃|接舷]]するために用いられていた、多数の<ruby><rb>[[w:鉤|鉤]]</rb><rp>（</rp><rt>かぎ</rt><rp>）</rp></ruby>を備えた<ruby><rb>[[w:銛|銛]]</rb><rp>（</rp><rt>もり</rt><rp>）</rp></ruby>の一種（<small>英語 [[wikt:en:grappling hook|grappling hook]]</small>）。<hr>[[内乱記_第1巻#57節|『内乱記』第1巻57節]]、[[内乱記_第2巻#6節|第2巻6節]]においても、[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|D.ブルートゥス]]による'''[[内乱記/マッシリアについて|マッシリア攻囲]]'''の海戦の場面で、同様の鉤について言及される。]] |} </div> *Accedebat ut, **さらに加えて、 *cum <span style="color:#009900;">[</span>saevire ventus coepisset et<span style="color:#009900;">]</span> se vento dedissent, **<span style="color:#009900;">[</span>風が荒々しく吹き始めて<span style="color:#009900;">]</span> 風に身を委ねて<span style="color:#009900;">（航行して）</span>いたときに、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：&beta;系写本では [　　] 部分を欠く。）</span> *et tempestatem ferrent facilius **<span style="color:#009900;">（ウェネティー族の船団は）</span>嵐により容易に耐えていたし、 *et in vadis consisterent tutius **浅瀬により安全に停留して、 *et ab aestu relictae **潮に取り残されても、 *nihil saxa et [[wikt:en:cautes#Latin|cautes]] timerent; **岩石やごつごつした石を何ら恐れることがなかった。 *quarum rerum omnium nostris navibus casus erant extimescendi. **それらのすべての事が、我が<span style="color:#009900;">〔ローマ人の〕</span>船団にとっては、恐怖すべき危険であったのだ。 **:<span style="color:#009900;">（訳注：ウェネティー族の船は[[w:竜骨 (船)|竜骨]]がローマ人の船より平たいため、<br>　　　　浅瀬や引き潮を容易に持ち応えられた。本節の冒頭を参照。）</span> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===14節=== *<span style="background-color:#ffd;">[[/注解/14節]]　{{進捗|00%|2022-07-17}}</span> '''カエサル待望のブルートゥスの艦隊が来航し、ウェネティー族との海戦が始まる''' *Compluribus expugnatis oppidis **いくつもの<span style="color:#009900;">（ウェネティー族の）</span><ruby><rb>[[w:オッピドゥム|城塞都市]]</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>が攻略されると、 *Caesar <u>ubi intellexit</u> frustra tantum laborem sumi **カエサルは、これほどの労苦が徒労になること（を知り）、 *neque hostium fugam captis oppidis reprimi **（すなわち）<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>が占領されても、敵の逃亡が妨げられないし、 *neque iis noceri posse, **彼ら<span style="color:#009900;">〔ウェネティー族〕</span>に損害が与えられることも不可能である<u>と知るや否や</u>、 *statuit exspectandam classem. **[[w:ローマ海軍|艦隊]]<span style="color:#009900;">（の到着）</span>を待つことを決意した。 **:<span style="color:#009900;">（訳注：ローマの軍船がリゲル川〔[[w:ロワール川|ロワール川]]〕で建造されていることが[[#9節|9節]]で述べられた。）</span> <br> ;　　ローマ艦隊が来航すると、約220隻のウェネティー船団が迎え撃とうとする *Quae ubi convenit ac primum ab hostibus visa est, **これら<span style="color:#009900;">〔ローマ艦隊〕</span>が集結して敵方により目撃されるや否や、 *circiter CCXX(ducentae viginti) naves eorum paratissimae **約220隻の彼ら<span style="color:#009900;">〔ウェネティー族〕</span>の船団が準備を整え、 *atque omni genere armorum ornatissimae **あらゆる種類の武器が完備された状態で *ex portu profectae nostris adversae constiterunt; **港から出航して、我が方<span style="color:#009900;">〔ローマ艦隊〕</span>と向かい合って布陣した。 <div style="text-align:center"> {| |- |[[画像:Bataille Morbihan -56.png|thumb|right|600px|[[w:紀元前56年|BC56年]]に現在の[[w:モルビアン県|モルビアン県]]沿いの[[w:キブロン湾|キブロン湾]]で戦われたと考えられている、[[w:ウェネティ族 (ガリア)|ウェネティー族]]と[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|D. ブルートゥス]]率いる艦隊との海戦、いわゆる「[[w:モルビアン湾の海戦|モルビアン湾の海戦]]」の海戦図。<hr>上図の説では、<span style="color:green;">ウェネティー族の帆船(緑色/約220隻)</span>と<span style="color:red;">ブルートゥス率いるローマのガレー船(赤色/約100隻)</span>が[[w:キブロン湾|キブロン湾]]で対峙し、<span style="color:red;">カエサルと1個軍団(赤色)</span>が沿岸を占領している。]] |} </div> *neque satis [[wikt:en:Brutus#Latin|Bruto]], qui classi praeerat, **艦隊を指揮していた[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|ブルートゥス]]には十分（明らか）ではなかった。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：デキムス・ブルートゥス [[w:la:Decimus Iunius Brutus Albinus|Decimus Brutus]] に艦隊を指揮させることが[[#11節|11節]]で述べられた。）</span> *vel tribunis militum centurionibusque, quibus singulae naves erant attributae, **あるいは、個々の船が割り当てられていた <ruby><rb>[[w:トリブヌス・ミリトゥム|兵士長官]]</rb><rp>（</rp><rt>トリブヌス・ミリトゥム</rt><rp>）</rp></ruby> や <ruby><rb>[[w:ケントゥリオ|百人隊長]]</rb><rp>（</rp><rt>ケントゥリオー</rt><rp>）</rp></ruby> にとってさえも、 *constabat quid agerent aut quam rationem pugnae insisterent. **何をすべきなのか、どのような戦法を採るべきなのか、明らかではなかった。 *[[wikt:en:rostrum#Latin|Rostro]] enim noceri non posse cognoverant; **なぜなら、<ruby><rb>[[w:衝角|衝　角]]</rb><rp>（</rp><rt>ローストルム</rt><rp>）</rp></ruby>にとって<span style="color:#009900;">（敵船に）</span>損害を与えることができないことを知っていたからだ。 **:<span style="color:#009900;">（訳注：[[#13節|前節]]で、ウェネティー族の船体が頑丈であるため、と述べられた。）</span> *turribus autem excitatis tamen has altitudo [[wikt:en:puppis#Latin|puppium]] ex barbaris navibus superabat, **他方で、[[w:櫓|櫓]]が築かれたにもかかわらず、蛮族の船の <ruby><rb>[[w:船尾|船尾]]</rb><rp>（</rp><rt>プッピス</rt><rp>）</rp></ruby> の高さがそれら（の高さ）を上回っていた。 **:<span style="color:#009900;">（訳注：ローマの軍船の甲板上には、投槍などの飛道具を投げるために櫓が設けられていた。）</span> *ut neque ex inferiore loco satis commode [[wikt:en:telum#Latin|tela]] adigi possent **その結果、より低い場所から十分に具合良く<span style="color:#009900;">（敵船に）</span><ruby><rb>[[w:飛び道具|飛道具]]</rb><rp>（</rp><rt>テールム</rt><rp>）</rp></ruby>が投げ込まれることは不可能で、 *et missa a Gallis gravius acciderent. **ガッリア人により放られたものがより激しく降ってきていた。 <br> ;　　ローマ艦隊の切り札 *Una erat magno usui res praeparata a nostris, **ただ一つの大いに役立つ物が、我が方<span style="color:#009900;">〔ローマ艦隊〕</span>によって準備されていた。 *[[wikt:en:falx#Latin|falces]] praeacutae insertae adfixaeque [[wikt:en:longurius#Latin|longuriis]], **<span style="color:#009900;">（それは）</span>先の尖った[[w:鎌|鎌]]が <ruby><rb>長い竿</rb><rp>（</rp><rt>ロングリウス</rt><rp>）</rp></ruby> に挿入されて固定されたもので、 *non absimili forma muralium falcium. **<ruby><rb><span style="color:#009900;">(攻城用の)</span>破城の鎌</rb><rp>（</rp><rt>ファルクス・ムーラーリス</rt><rp>）</rp></ruby> に形が似ていなくもない。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：「破城の鎌」'''[[古代ローマの攻城兵器#falx_muralis_(siege_hook)|falx muralis]]''' に似たもので、'''[[ガイウス・ユリウス・カエサルの著作/古代ローマの攻城兵器#falx_navalis|falx navalis]]''' とも呼ばれている。）</span> <div style="text-align:center"> {| |- |[[画像:Caesar's Gallic war; (Allen and Greenough's ed.) (1898) (14778300381)(cropped).jpg|thumb|right|300px|破城鎌の復元画の例]] |[[画像:Ulysse bateau.jpg|thumb|right|320px|帆柱・帆桁や帆・綱具などが描かれたローマ時代の[[w:モザイク|モザイク画]]<ref>[[w:en:Roman mosaic]]</ref>《[[w:オデュッセウス|オデュッセウス]]と[[w:セイレーン|セイレーン]]》<br>（[[w:チュニス|チュニス]]の[[w:バルド国立博物館|バルド国立博物館]]）]] |} </div> *His cum [[wikt:en:funis#Latin|funes]] qui [[wikt:en:antemna#Latin|antemnas]] ad [[wikt:en:malus#Etymology_3_2|malos]] destinabant, comprehensi adductique erant, **これによって、<ruby><rb>帆　桁</rb><rp>（</rp><rt>アンテムナ</rt><rp>）</rp></ruby> を <ruby><rb>[[w:マスト|帆　柱]]</rb><rp>（</rp><rt>マールス</rt><rp>）</rp></ruby> に縛り付けていた <ruby><rb>綱具</rb><rp>（</rp><rt>フーニス</rt><rp>）</rp></ruby> が補足されて引っ張られた状態で、 *navigio remis incitato praerumpebantur. **<ruby><rb>艦艇</rb><rp>（</rp><rt>ナーウィギウム</rt><rp>）</rp></ruby>が[[w:櫂|櫂]]によってすばやく推進されると、<span style="color:#009900;">（綱具が）</span>引き裂かれていた。 *Quibus abscisis antemnae necessario concidebant, **それら<span style="color:#009900;">〔綱具〕</span>が切断されると、<ruby><rb>帆　桁</rb><rp>（</rp><rt>アンテムナ</rt><rp>）</rp></ruby> は必然的に倒れてしまっていた。 *ut, cum omnis Gallicis navibus spes in velis armamentisque consisteret, **その結果、ガッリア人の船団にとって、すべての期待は帆と索具に依拠していたので、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:armamentum#Latin|armamentum]] (英 ''[[wikt:en:rigging#English|rigging]]'')⇒「索具」：[[w:帆|帆]]と[[w:マスト|帆柱]]を支える綱や器具など。）</span> *his ereptis omnis usus navium uno tempore eriperetur. **これらが引き裂かれると、船のすべての運用能力も<ruby><rb>一時</rb><rp>（</rp><rt>いちどき</rt><rp>）</rp></ruby>に奪い取られていた。 *Reliquum erat certamen positum in virtute, **残りの争闘は、武勇いかんに<ruby><rb>懸</rb><rp>（</rp><rt>か</rt><rp>）</rp></ruby>かっており、 *qua nostri milites facile superabant, **その点では我が方<span style="color:#009900;">〔ローマ勢〕</span>の兵士たちが容易に上回っていた。 <br> ;　　沿岸はカエサルとローマ軍によって占領されていた *atque eo magis quod in conspectu Caesaris atque omnis exercitus res gerebatur, **カエサルと全軍の眺望の中で、それだけ大きく、事（戦闘）が遂行されたので、 *ut nullum paulo fortius factum latere posset; **どんな力強い動作も知られずにいることができないほどであった。 *omnes enim colles ac loca superiora, unde erat propinquus despectus in mare, ab exercitu tenebantur. **なぜなら、そこから間近に海を見下ろすすべての丘とより高い場所は、<span style="color:#009900;">（ローマ人の）</span>軍隊によって占領されていたのである。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===15節=== '''海戦が終わる''' *Deiectis, ut diximus, antemnis, **上述したように帆桁がぶっ倒れて、 *cum singulas binae ac ternae naves circumsteterant, **（ウェネティー族の船）1艘ずつを（ローマの）2艘ずつや3艘ずつの船が攻囲して、 *milites summa vi transcendere in hostium naves contendebant. **（ローマの）兵士たちは最高の力で敵の船に乗り移ることに努めた。 *Quod postquam barbari fieri animadverterunt, **そのことが行なわれていると蛮族が気づいた後で、 *expugnatis compluribus navibus, **いくつもの（ウェネティー族の）船が攻略されて、 *cum ei rei nullum reperiretur auxilium, **この事態に対して何ら助けを見出せなかったので、 *fuga salutem petere contenderunt. **逃亡に身の安全を求めることに努めた。 *Ac iam conversis in eam partem navibus quo ventus ferebat, **ちょうど風が運んでいた方角へ船の向きを変えたが、 *tanta subito malacia ac tranquillitas exstitit, **突然に大きく[[w:凪|凪]]や静けさが生じて、 *ut se ex loco movere non possent. **（ウェネティー族が）その場所から動くことができないほどであった。 *Quae quidem res ad negotium conficiendum maximae fuit oportunitati: **このような事態はまさに仕事（軍務）を遂行するのに最大の機会であった。 *nam singulas nostri consectati expugnaverunt, **というのも（敵船）1つずつを我が方が追跡して攻略して、 *ut perpaucae ex omni numero noctis interventu ad terram pervenirent, **その結果、総勢のうちから非常にわずかな数の者たちが、夜のとばりに包まれて、陸地に達したのだ。 *cum ab hora fere IIII{quarta}. usque ad solis occasum pugnaretur. **なぜなら（海戦が）ほぼ第四時から日が没するまで絶えず戦われたからだ。 **:（訳注：第四時は、古代ローマの不定時法で、午前9時～10時頃と思われる。） ===16節=== '''ウェネティー族の行末''' *Quo proelio bellum Venetorum totiusque orae maritimae confectum est. **以上の戦闘で、[[w:ウェネティ族 (ガリア)|ウェネティー族]]およびすべての沿岸住民との戦争が完遂された。 *Nam cum omnis iuventus, omnes etiam gravioris aetatis, **なぜなら、すべての青年とすべての年嵩の者さえも、 *in quibus aliquid consilii aut dignitatis fuit eo convenerant, **何らかの見識や品位のあった者たちは、そこ（戦場）へ集まっていたからだ。 *tum navium quod ubique fuerat in unum locum coegerant; **そのとき、至る所にあった船が一つの場所に集められていたのだ。 *quibus amissis reliqui neque quo se reciperent neque quemadmodum oppida defenderent habebant. **以上のものを喪失して、残存者たちは、どこへ退くかも、どんな方法で城市を防衛するかもわからなかった。 *Itaque se suaque omnia Caesari dediderunt. **こうして、彼らとそのすべてのものをカエサルに委ねた（降伏した）。 *In quos eo gravius Caesar vindicandum statuit **これらのものを、カエサルはより厳重に処罰すると決定した。 *quo diligentius in reliquum tempus a barbaris ius legatorum conservaretur. **将来、蛮族により（ローマの）使節の権利をいっそう保たせるように。 *Itaque omni senatu necato reliquos sub corona vendidit. **こうして、すべての長老を殺害して、残りの者たちを奴隷として売却した。 **（訳注：sub corona vendere；葉冠のもとに売る＝奴隷として売る） ==大西洋岸ウネッリ族の造反== ===17節=== [[画像:Campagne Unelles -56.png|thumb|right|200px|ウネッリ族・レクソウィイ族への遠征経路。]] '''ウネッリ族の反乱とサビヌスの作戦''' *Dum haec in Venetis geruntur, **以上のことが[[w:ウェネティ族 (ガリア)|ウェネティー族]]（の領国）で行なわれていた間に、 *Q. Titurius Sabinus cum iis copiis, quas a Caesare acceperat **[[w:クィントゥス・ティトゥリウス・サビヌス|クィントゥス・ティトゥリウス・サビヌス]]は、カエサルから受け取った軍勢とともに *in fines Unellorum{Venellorum} pervenit. **[[w:ウネッリ族|ウネッリ族]]の領土に到着した。 *His praeerat Viridovix ac summam imperii tenebat earum omnium civitatum, quae defecerant, **彼ら（ウネッリ族）を指揮していたのは[[w:ウィリドウィクス|ウィリドウィクス]]で、背反した全部族の最高指揮権を保持していた。 *ex quibus exercitum [magnasque copias] coegerat; **（彼は）これら（の部族）から大軍勢を徴集した。 *atque his paucis diebus Aulerci Eburovices Lexoviique, **それから数日内に、[[w:アウレルキ族|アウレルキ族]]、[[w:エブロウィケス族|エブロウィケス族]]と[[w:レクソウィー族|レクソウィイ族]]は、 *senatu suo interfecto, quod auctores belli esse nolebant, **自分たちの長老たちを、戦争の首謀者になることを欲しなかったという理由で殺害し、 *portas clauserunt seseque cum Viridovice coniunxerunt; **（城市の）門を閉じて、彼らはウィリドウィクスと結託した。 *magnaque praeterea multitudo undique ex Gallia perditorum hominum latronumque convenerat, **そのうえにガリアの至る所から大勢の無頼漢や略奪者が集まっていた。 *quos spes praedandi studiumque bellandi ab agri cultura et cotidiano labore revocabat. **これらの者たちを、略奪への期待と戦争への熱望が、農耕や毎日の仕事から呼び戻したのだ。 *Sabinus idoneo omnibus rebus loco castris se tenebat, **サビヌスはすべての事柄において適切な場所で、陣営を保持した。 *cum Viridovix contra eum duorum milium spatio consedisset **ウィリドウィクスは彼に対抗して2[[w:ローママイル|ローママイル]]（約3km）の間隔で陣取って、 *cotidieque productis copiis pugnandi potestatem faceret, **毎日、軍勢を連れ出して戦闘の機会を作った。 *ut iam non solum hostibus in contemptionem Sabinus veniret, **その結果ついに、敵からサビヌスが軽蔑されるに至ったのみならず、 *sed etiam nostrorum militum vocibus nonnihil carperetur; **我が方（ローマ）の兵士からも若干の者が声に出して嘲弄するに至った。 *tantamque opinionem timoris praebuit, **これほどの恐れの評判を呈したので、 *ut iam ad vallum castrorum hostes accedere auderent. **ついに陣営の堡塁のところにまで敵が敢えて近づいて来るほどであった。 *Id ea de causa faciebat **（サビヌスは）以上のことを以下の理由でしたのである。 *quod cum tanta multitudine hostium, **というのも、このような大がかりな敵とともに、 *praesertim eo absente qui summam imperii teneret, **とりわけ、（ローマ側の）最高指揮権を保持する者（=カエサル）がおらずに、 *nisi aequo loco aut opportunitate aliqua data **有利な場所か何らかの機会が与えられなければ、 *legato dimicandum non existimabat. **総督副官（[[w:レガトゥス|レガトゥス]]）にとって戦うべきとは考えなかったのである。 ===18節=== '''サビヌスの計略''' *Hac confirmata opinione timoris **このような恐れの評判が強められて、 *idoneum quendam hominem et callidum delegit Gallum, **（サビヌスは）適切で明敏なガリア人のある男を選び出した。 *ex iis quos auxilii causa secum habebat. **支援軍（[[w:アウクシリア|アウクシリア]]）のために保持していた者たちの内から。 *Huic magnis praemiis pollicitationibusque persuadet uti ad hostes transeat, **この者を、多大なほうびを約束して、敵側に渡るように説得して、 *et quid fieri velit edocet. **（サビヌスが）なされんと欲することを説き教えた。 *Qui ubi pro perfuga ad eos venit, timorem Romanorum proponit, **その者は、逃亡兵として彼ら（ウネッリ族）のところへ来るや否や、ローマ人の恐れを申し述べた。 *quibus angustiis ipse Caesar a Venetis prematur docet, **いかなる困窮で、カエサル自身が[[w:ウェネティ族 (ガリア)|ウェネティー族]]により苦戦させられているかを教えた。 *neque longius abesse, quin proxima nocte **遠からず、明晩には *Sabinus clam ex castris exercitum educat **サビヌスはひそかに陣営から軍隊を導き出して、 *et ad Caesarem auxilii ferendi causa proficiscatur. **カエサルのところへ支援をもたらすために出発するであろう（とその男は教えた）。 *Quod ubi auditum est, conclamant **このことが聞かれるや否や、（ウネッリ族の者たちは）叫び声を上げて、 *omnes occasionem negotii bene gerendi amittendam non esse: ad castra iri oportere. **うまく仕事をするすべての機会を失うべきではない、（ローマの）陣営へ行かねばならぬ（と叫んだ）。 *Multae res ad hoc consilium Gallos hortabantur: **多くの事柄が、この計画へとガリア人を励ました。 **（それらの事柄とは、以下のことである。） *superiorum dierum Sabini cunctatio, **最近の日々のサビヌスのためらい、 *perfugae confirmatio, **脱走兵の確証、 *inopia cibariorum, cui rei parum diligenter ab iis erat provisum, **彼ら（ガリア人）によって充分に入念に調達されなかった糧食の欠乏、 *spes Venetici belli, **[[w:ウェネティ族 (ガリア)|ウェネティー族]]の戦争への希望、 *et quod fere libenter homines id quod volunt credunt. **というのも、たいてい人間は（自分が）欲することを喜んで信ずるからである。 *His rebus adducti non prius Viridovicem reliquosque duces ex concilio dimittunt, **これらの事態に引かれて、（ウネッリ族は）ウィリドウィクスや他の指導者を会議から解散させなかった。 *quam ab his sit concessum arma uti capiant et ad castra contendant. **彼らによって、武器を取って（ローマ）陣営へ急行するように容認されるまでは。 *Qua re concessa laeti, ut explorata victoria, **この事が容認されて、勝利が得られたかのように喜んで、 *sarmentis virgultisque collectis, quibus fossas Romanorum compleant, ad castra pergunt. **柴や薮を集めて、これでもってローマ人の堀を埋めるべく、（ローマの）陣営のところへ出発した。 ===19節=== '''ウネッリ族らとの決戦''' *Locus erat castrorum editus et paulatim ab imo acclivis circiter passus mille. **ローマ陣営の位置は高く、最も下（麓）から緩やかな上り坂で約1000[[w:パッスス|パッスス]]（約1.5km）のところにあった。 *Huc magno cursu contenderunt, ここへ、大いに駆けて急いで、 *ut quam minimum spatii ad se colligendos armandosque Romanis daretur, **ローマ人にとって集結して武装するための時間ができるだけ与えられないようにして、 *exanimatique pervenerunt. **息を切らして到着した。 *Sabinus suos hortatus cupientibus signum dat. **サビヌスは、自分の部下たちを励まして、はやる者たちに合図を与える。 *Impeditis hostibus propter ea quae ferebant onera, **敵は、彼らが担いでいた重荷のために妨げられていて、 *subito duabus portis eruptionem fieri iubet. **（サビヌスは）突然に（左右の）二つの門から出撃することを命じた。 *Factum est **（ut以下のことが）なされた。 *opportunitate loci, hostium inscientia ac defatigatione, **場所の有利さ、敵の（武具や戦術の）不案内と疲労や、 *virtute militum et superiorum pugnarum exercitatione, **兵士の武勇とかつての戦闘の熟練によって *ut ne primum quidem nostrorum impetum ferrent ac statim terga verterent. **我が方（ローマ）の最初の襲撃さえ持ちこたえることなく、（敵は）すぐに背を向けた。 *Quos impeditos integris viribus milites nostri consecuti **これらの妨げられている者たちを、健全な力で我が方の兵士たちが追跡して、 *magnum numerum eorum occiderunt; **彼らの大多数を殺戮した。 *reliquos equites consectati paucos, qui ex fuga evaserant, reliquerunt. **残りの者たちは、（ローマの）騎兵が追跡したが、逃亡によって逃れたので、見逃した。 *Sic uno tempore et de navali pugna Sabinus et de Sabini victoria Caesar est certior factus, **このようにして一度に、海戦についてサビヌスが、サビヌスの勝利についてカエサルが、報告を受けて、 *civitatesque omnes se statim Titurio dediderunt. **（敵の）全部族がすぐにティトゥリウス（・サビヌス）に降伏した。 *Nam ut ad bella suscipienda Gallorum alacer ac promptus est animus, **こうなったのは、ガリア人は戦争を実行することについては性急で、心は敏捷であるが、 *sic mollis ac minime resistens ad calamitates ferendas mens eorum est. **と同様に柔弱で、災難に耐えるには彼らの心はあまり抵抗しないためである。 ==クラッススのアクィタニア遠征== ===20節=== [[画像:Campagne Aquitains -56.png|thumb|right|200px|クラッススのアウィタニア遠征の経路。]] '''クラッススのアクィタニア遠征、ソティアテス族''' *Eodem fere tempore P. Crassus, cum in Aquitaniam pervenisset, **ほぼ同じ時期に[[w:プブリウス・リキニウス・クラッスス|プブリウス・クラッスス]]が[[w:アクィタニア|アクィタニア]]に達したときに、 *quae pars, ut ante dictum est, et regionum latitudine et multitudine hominum **この方面は、前述のように、領域の広さと人間の多さで *ex tertia parte Galliae est aestimanda, **[[w:ガリア|ガリア]]の第三の部分であると考えられるべきであるが、 *cum intellegeret in illis locis sibi bellum gerendum, **（クラッススは）かの場所で自らにとって戦争がなされるべきであると考えたので、 *ubi paucis ante annis L. Valerius Praeconinus legatus exercitu pulso interfectus esset **そこでほんの数年前に[[w:ルキウス・ウァレリウス・プラエコニヌス|ルキウス・ウァレリウス・プラエコニヌス]]総督副官（[[w:レガトゥス|レガトゥス]]）が軍隊を撃退されて殺害されており、 *atque unde L. Manlius proconsul impedimentis amissis profugisset, **かつここから[[w:ルキウス・マンリウス・トルクァトゥス|ルキウス・マンリウス]]執政官代理（[[w:プロコンスル|プロコンスル]]）が輜重を失って敗走しており、 *non mediocrem sibi diligentiam adhibendam intellegebat. **己にとって尋常ならざる注意深さが適用されるべきだと考えたのだ。 *Itaque re frumentaria provisa, auxiliis equitatuque comparato, **こうして糧食が調達され、支援軍（[[w:アウクシリア|アウクシリア]]）や[[w:騎兵|騎兵隊]]が整備され、 *multis praeterea viris fortibus Tolosa et Carcasone et Narbone, **そのうえ多くの屈強な男たちが、[[w:トロサ|トロサ]]や[[w:カルカソ|カルカソ]]や[[w:ナルボ|ナルボ]]から *－ quae sunt civitates Galliae provinciae finitimae, ex his regionibus－ **＜それらは、この地域に隣接する（ローマの）ガリア属州（[[w:ガリア・ナルボネンシス|ガリア・トランサルピナ]]）の都市であるが、＞ *nominatim evocatis, in Sotiatium fines exercitum introduxit. **名指しで徴集されて、（クラッススは）[[w:ソティアテス族|ソティアテス族]]の領土に軍隊を導き入れた。 *Cuius adventu cognito Sotiates magnis copiis coactis, **彼（クラッスス）の到着を知ると、ソティアテス族は大軍勢を集めて、 *equitatuque, quo plurimum valebant, in itinere agmen nostrum adorti **それにより彼らが大いに力があったところの騎兵隊で、行軍中の我が（ローマの）隊列を襲って、 *primum equestre proelium commiserunt, **はじめに騎兵戦を戦った。 *deinde equitatu suo pulso atque insequentibus nostris **それから、その（敵の）騎兵隊が撃退され、我が方が追跡したが、 *subito pedestres copias, quas in convalle in insidiis conlocaverant, ostenderunt. **突然に歩兵の軍勢　＜[[w:峡谷|峡谷]]の中で[[w:伏兵|伏兵]]として配置していた者たち＞　が現われた。 *Iis nostros disiectos adorti proelium renovarunt. **これらによって追い散らされた我が方（ローマ軍）に襲いかかり、戦いを再び始めた。 ===21節=== '''ソティアテス族の敗勢''' *Pugnatum est diu atque acriter, **長く激しく戦われた。 *cum Sotiates superioribus victoriis freti **というのもソティアテス族は、かつての（ローマ軍に対する）勝利を信頼しており、 *in sua virtute totius Aquitaniae salutem positam putarent, **自分たちの武勇の中に全アクィタニアの安全が立脚していると、みなしていたからだ。 *nostri autem, **我が方（ローマ軍）はそれに対して *quid sine imperatore et sine reliquis legionibus adulescentulo duce efficere possent, **最高司令官（[[w:インペラトル|インペラトル]]）なし、他の[[w:ローマ軍団|軍団]]もなしに、この若造（クラッスス）が指揮官として何をなしうるかが *perspici cuperent; **注視（吟味）されることを欲していたのだ。 *tandem confecti vulneribus hostes terga verterunt. **ついに傷を負って、敵は背を向けた。 *Quorum magno numero interfecto **これらの者の大多数を殺戮し、 *Crassus ex itinere oppidum Sotiatium oppugnare coepit. **クラッススは行軍からただちにソティアテス族の[[w:オッピドゥム|城市]]を攻撃し始めた。 *Quibus fortiter resistentibus vineas turresque egit. **これらの者たちが勇敢に抵抗したので、（ローマ勢は）工作小屋（[[w:ウィネア|ウィネア]]）や[[w:櫓|櫓]]を（城の方に）導いた。 *Illi alias eruptione temptata, alias cuniculis ad aggerem vineasque actis **彼ら（アクィタニア人）は、あるときは突撃を試みて、あるときは[[w:坑道|坑道]]を[[w:土塁|土塁]]や工作小屋のところへ導いた。 *－ cuius rei sunt longe peritissimi Aquitani, **＜こういった事柄（坑道の技術）に、アクィタニア人は長らく非常に熟練している。 *propterea quod multis locis apud eos aerariae secturaeque sunt －, **これは、彼らのもとの多くの場所に[[w:銅山|銅山]]や[[w:採石所|採石所]]があることのためである。＞ *ubi diligentia nostrorum nihil his rebus profici posse intellexerunt, **我が方の注意深さによってこのような事柄によっても何ら得られぬと考えるや否や、 *legatos ad Crassum mittunt, seque in deditionem ut recipiat petunt. **（ソティアテス族は）使節をクラッススのところへ送って、自分たちを降伏へと受け入れるように求める。 *Qua re impetrata arma tradere iussi faciunt. **この事が達せられ、武器の引渡しが命じられ、実行された。 ===22節=== '''アディアトゥアヌスと従僕たちの突撃''' *Atque in ea re omnium nostrorum intentis animis **この事柄に我が方（ローマ勢）の皆が心から没頭しており、 *alia ex parte oppidi Adiatuanus, qui summam imperii tenebat, **城市の他の方面から、最高指揮権を保持していた[[w:アディアトゥアヌス|アディアトゥアヌス]]が *cum DC{sescentis} devotis, quos illi{Galli} soldurios appellant, **ガリア人がソルドゥリイ（従僕）と呼んでいる600名の忠実な者とともに（突撃を試みた）。 '''アディアトゥアヌスの従僕たち''' *－ quorum haec est condicio, **＜　これらの者たちの状況は以下の通りであった。 *uti omnibus in vita commodis una cum iis fruantur quorum se amicitiae dediderint, **人生におけるあらゆる恩恵を、忠心に身を捧げる者たちと一緒に享受する。 *si quid his per vim accidat, aut eundem casum una ferant aut sibi mortem consciscant; **もし彼らに何か暴力沙汰が起こったら、同じ運命に一緒に耐えるか、自らに死を引き受ける（自殺する）。 *neque adhuc hominum memoria repertus est quisquam qui, **これまで、次のような人の記憶は見出されていない。 *eo interfecto, cuius se amicitiae devovisset, mortem recusaret － **忠心に身を捧げる者が殺されても死を拒む（ような者）　＞ *cum his Adiatuanus eruptionem facere conatus **これらの者（従僕）とともにアディアトゥアヌスは突撃することを試みた。 '''アディアトゥアヌスの敗退''' *clamore ab ea parte munitionis sublato **堡塁のその方面から叫び声が上げられて、 *cum ad arma milites concurrissent vehementerque ibi pugnatum esset, **武器のところへ（ローマの）兵士たちが急ぎ集まった後に、そこで激しく戦われた。 *repulsus in oppidum **（アディアトゥアヌスたちは）城市の中に撃退され、 *tamen uti eadem deditionis condicione uteretur a Crasso impetravit. **しかし（前と）同じ降伏条件を用いるように、クラッススを説得した。 ===23節=== '''ウォカテス族・タルサテス族対クラッスス''' *Armis obsidibusque acceptis, Crassus in fines Vocatium et Tarusatium profectus est. **武器と人質を受け取って、クラッススは[[w:ウォカテス族|ウォカテス族]]と[[w:タルサテス族|タルサテス族]]の領土に出発した。 *Tum vero barbari commoti, **そのとき確かに蛮族たちは動揺させられて、 *quod oppidum et natura loci et manu munitum **というのも、地勢と部隊で防備された（ソティアテス族の）城市が *paucis diebus quibus eo ventum erat, expugnatum cognoverant, **（ローマ人が）そこへ来てからわずかな日数で攻め落とされたことを知っていたためであるが、 *legatos quoque versus dimittere, **使節たちをあらゆる方面に向けて送り出し、 *coniurare, obsides inter se dare, copias parare coeperunt. **共謀して、互いに人質を与え合って、軍勢を準備し始めた。 *Mittuntur etiam ad eas civitates legati quae sunt citerioris Hispaniae finitimae Aquitaniae: **アクィタニアに隣接する[[w:上ヒスパニア|上ヒスパニア]]（[[w:en:Hispania Citerior|Hispania Citerior]]）にいる部族たちにさえ、使節が派遣された。 [[画像:Hispania_1a_division_provincial.PNG|thumb|250px|right|BC197年頃のヒスパニア。オレンジ色の地域が当時の上ヒスパニア]] [[画像:Ethnographic Iberia 200 BCE.PNG|thumb|right|250px|BC200年頃のイベリア半島の民族分布。朱色の部分に[[w:アクィタニア人|アクィタニア人]]の諸部族が居住していた。]] *inde auxilia ducesque arcessuntur. **そこから援兵と指揮官が呼び寄せられた。 *Quorum adventu **これらの者が到着して、 *magna cum auctoritate et magna [cum] hominum multitudine **大きな権威と大勢の人間とともに、 *bellum gerere conantur. **戦争遂行を企てた。 *Duces vero ii deliguntur **指揮官には確かに（以下の者たちが）選ばれた。 *qui una cum Q. Sertorio omnes annos fuerant **皆が多年の間、[[w:クィントゥス・セルトリウス|クィントゥス・セルトリウス]]（[[w:la:Quintus Sertorius|Quintus Sertorius]]）と一緒にいて、 *summamque scientiam rei militaris habere existimabantur. **軍事の最高の知識を有すると考えられていた（者たちである）。 **（訳注：セルトリウスは、[[w:ルキウス・コルネリウス・スッラ|スッラ]]の独裁に抵抗したローマ人の武将である。[[w:ヒスパニア|ヒスパニア]]の住民にローマ軍の戦術を教えて共和政ローマに対して反乱を起こしたが、[[w:グナエウス・ポンペイウス|ポンペイウス]]によって鎮圧された。） *Hi consuetudine populi Romani loca capere, **これらの者たちは、ローマ人民の習慣によって、場所を占領し、 *castra munire, **[[w:カストラ|陣営]]を防壁で守り、 *commeatibus nostros intercludere instituunt. **我が方（ローマ勢）の物資をさえぎることに決めたのだ。 *Quod ubi Crassus animadvertit, **クラッススは（以下の諸事情に）気づくや否や、（すなわち） *suas copias propter exiguitatem non facile diduci, **己の軍勢が寡兵であるために、展開するのが容易でないこと、 *hostem et vagari et vias obsidere et castris satis praesidii relinquere, **敵はうろつき回って道を遮断して、陣営に十分な守備兵を残していること、 *ob eam causam minus commode frumentum commeatumque sibi supportari, **その理由のために糧食や軍需品を都合良く自陣に持ち運べていないこと、 *in dies hostium numerum augeri, **日々に敵の数が増していること、（これらの諸事情に気づいたので） *non cunctandum existimavit quin pugna decertaret. **（クラッススは）戦闘で雌雄を決することをためらうべきではないと考えたのだ。 *Hac re ad consilium delata, ubi omnes idem sentire intellexit, **この事が会議に報告されて、皆が同じく考えていることを知るや否や、 *posterum diem pugnae constituit. **戦闘を翌日に決めた。 ===24節=== '''両軍の開戦準備''' *Prima luce productis omnibus copiis, **（クラッススは）夜明けに全軍勢を連れ出して、 *duplici acie instituta, **二重の戦列を整列し、 *auxiliis in mediam aciem coniectis, **支援軍（[[w:アウクシリア|アウクシリア]]）を戦列の中央部に集結し、 *quid hostes consilii caperent exspectabat. **敵がいかなる計略をとるのかを待った。 *Illi, **彼ら（アクィタニア人）は、 *etsi propter multitudinem et veterem belli gloriam paucitatemque nostrorum se tuto dimicaturos existimabant, **（自らの）多勢、昔の戦争の名誉、我が方（ローマ勢）の寡勢のために、安全に闘えると考えたにも拘らず、 *tamen tutius esse arbitrabantur obsessis viis commeatu intercluso sine ullo vulnere victoria potiri, **それでもより安全と思われるのは、道を包囲して[[w:兵站|兵站]]を遮断し、何ら傷なしに勝利をものにすることであり、 *et si propter inopiam rei frumentariae Romani se recipere coepissent, **もし糧食の欠乏のためにローマ人が退却し始めたならば、 *impeditos in agmine et sub sarcinis infirmiores **（ローマ人が）隊列において[[w:背嚢|背嚢]]を背負って妨げられて臆病になっているところを、 *aequo animo adoriri cogitabant. **平常心をもって襲いかかれると考えたのだ。 *Hoc consilio probato ab ducibus, productis Romanorum copiis, sese castris tenebant. **この計略が指揮官により承認されて、ローマ人の軍勢が進撃しても、彼らは陣営に留まった。 *Hac re perspecta Crassus, **この事を見通してクラッススは、 *cum sua cunctatione atque opinione timidiores hostes **（敵）自身のためらいや、評判より臆病な敵が *nostros milites alacriores ad pugnandum effecissent **我が方（ローマ）の兵士たちを戦うことにおいてやる気にさせたので、 *atque omnium voces audirentur exspectari diutius non oportere quin ad castra iretur, **かつ（敵の）陣営へ向かうことをこれ以上待つべきではないという皆の声が聞かれたので、 *cohortatus suos omnibus cupientibus ad hostium castra contendit. **部下を励まして、（戦いを）欲する皆で、敵の陣営へ急行した。 ===25節=== '''クラッスス、敵陣へ攻めかかる''' *Ibi cum alii fossas complerent, alii multis telis coniectis **そこで、ある者は堀を埋め、ある者は多くの飛道具を投げて、 *defensores vallo munitionibusque depellerent, **守備兵たちを[[w:防柵|防柵]]や[[w:防壁|防壁]]から駆逐した。 *auxiliaresque, quibus ad pugnam non multum Crassus confidebat, **[[w:アウクシリア|支援軍]]の者たちといえば、クラッススは彼らの戦いを大して信頼していなかったが、 *lapidibus telisque subministrandis et ad aggerem caespitibus comportandis **石や飛道具を供給したり、[[w:土塁|土塁]]のために[[w:芝|芝草]]を運んだり、 *speciem atque opinionem pugnantium praeberent, **戦っている様子や印象を示した。 *cum item ab hostibus constanter ac non timide pugnaretur **敵もまたしっかりと臆せずに戦って、 *telaque ex loco superiore missa non frustra acciderent, **より高い所から放られた飛道具は無駄なく落ちてきたので、 *equites circumitis hostium castris Crasso renuntiaverunt **[[w:騎兵|騎兵]]は、敵の陣営を巡察してクラッススに報告した。 *non eadem esse diligentia ab decumana porta castra munita **（敵の）陣営の後門（porta decumana）は（他の部分と）同じほどの入念さで防備されておらず、 *facilemque aditum habere. **容易に接近できると。 ===26節=== '''クラッスス、総攻撃をかける''' *Crassus equitum praefectos cohortatus, **クラッススは[[w:騎兵|騎兵]]の指揮官たちに促した。 *ut magnis praemiis pollicitationibusque suos excitarent, quid fieri velit ostendit. **大きな恩賞の約束で部下たちを駆り立てて、何がなされることを欲しているかを示すようにと。 *Illi, ut erat imperatum, **この者らは命じられたように、 *eductis iis cohortibus quae praesidio castris relictae intritae ab labore erant, **守備兵として陣営に残されていて、働きによって疲弊していなかった歩兵大隊（[[w:コホルス|コホルス]]）を連れ出して、 *et longiore itinere circumductis, ne ex hostium castris conspici possent, **敵の陣営から視認できないように、遠回りの道程をめぐらせて、 *omnium oculis mentibusque ad pugnam intentis **（彼我の）皆の目と意識が戦闘に没頭している間に *celeriter ad eas quas diximus munitiones pervenerunt atque his prorutis **速やかに前述した（後門の）防壁に至って、それを崩壊させて、 *prius in hostium castris constiterunt, **敵の陣営に拠点を築いた。 *quam plane ab his videri aut quid rei gereretur cognosci posset. **彼ら（敵）によりまったく見られ、あるいはいかなる事が遂行されているかを知られるよりも早くのことだった。 *Tum vero clamore ab ea parte audito **そのときまさにこの方面から雄叫びが聞こえて、 *nostri redintegratis viribus, **我が方（ローマ勢）は活力を回復し、 *quod plerumque in spe victoriae accidere consuevit, **勝利の希望の中にたいてい起こるのが常であったように *acrius impugnare coeperunt. **より激烈に攻め立て始めたのであった。 *Hostes undique circumventi desperatis omnibus rebus **敵は至る所から攻囲されて、すべての事態に絶望し、 *se per munitiones deicere et fuga salutem petere intenderunt. **壁を越えて飛び降りて、逃亡によって身の安全を求めることに懸命になった。 *Quos equitatus apertissimis campis consectatus **この者たちを（ローマの）騎兵隊が非常に開けた平原で追撃し、 *ex milium L{quinquaginta} numero, quae ex Aquitania Cantabrisque convenisse constabat, **[[w:アクィタニア|アクィタニア]]と[[w:カンタブリ族|カンタブリ族]]（[[w:en:Cantabri|Cantabri]]）から集まっていた（敵の総勢の）数は5万名が確認されたが、 *vix quarta parte relicta, **やっとその四分の一が生き残り、 *multa nocte se in castra recepit. **夜も更けて（ローマ勢は）陣営に退却した。 ===27節=== '''アクィタニア諸部族の降伏''' *Hac audita pugna **この戦闘（の勝敗）を聞いて、 *maxima pars Aquitaniae sese Crasso dedidit obsidesque ultro misit; **[[w:アクィタニア人|アクィタニア人]]の大部分がクラッススに降伏して、すすんで[[w:人質|人質]]を送った。 *quo in numero fuerunt **その数の中には以下の部族がいた。 *Tarbelli, Bigerriones, Ptianii, Vocates, Tarusates, Elusates, **[[w:タルベッリ族|タルベッリ族]]、[[w:ビゲッリオネス族|ビゲッリオネス族]]、[[w:プティアニー族|プティアニイ族]]、[[w:ウォカテス族|ウォカテス族]]、[[w:タルサテス族|タルサテス族]]、[[w:エルサテス族|エルサテス族]]、 *Gates, Ausci, Garunni, Sibulates, Cocosates: **[[w:ガテス族|ガテス族]]、[[w:アウスキ族|アウスキ族]]、[[w:ガルンニ族|ガルンニ族]]、[[w:シブラテス族|シブラテス族]]、[[w:ココサテス族|ココサテス族]]、である。 *paucae ultimae nationes **わずかな遠方の部族たちは、 *anni tempore confisae, quod hiems suberat, **時季を頼りにして、というのも冬が近づいていたためであるが、 *id facere neglexerunt. **そのこと（降伏と人質）をなおざりにした。 ==モリニ族・メナピイ族への遠征== ===28節=== '''カエサル、モリニ族・メナピイ族へ遠征''' *Eodem fere tempore Caesar, **（前節までに述べたクラッススのアクィタニア遠征と）ほぼ同じ時期にカエサルは、 *etsi prope exacta iam aestas erat, **すでに夏はほとんど過ぎ去っていたのであるが、 *tamen quod omni Gallia pacata **全ガリアが平定されていたにもかかわらず、 *Morini Menapiique supererant, **[[w:モリニ族|モリニ族]]と[[w:メナピー族|メナピイ族]]は生き残って *qui in armis essent, neque ad eum umquam legatos de pace misissent, **武装した状態で、彼（カエサル）のところへ決して和平の使節を派遣しようとしなかったので、 *arbitratus id bellum celeriter confici posse, eo exercitum duxit; **この戦争は速やかに完遂されると思って、そこへ軍隊を率いて行った。 *qui longe alia ratione ac reliqui Galli bellum gerere instituerunt. **これら（の部族）は、他のガリア人とはまったく別の方法で戦争遂行することを決めた。 *Nam **なぜなら *quod intellegebant maximas nationes, quae proelio contendissent, pulsas superatasque esse, **というのも、戦闘を戦った非常に多くの部族が撃退され、征服されていることを（彼らは）知っており、 *continentesque silvas ac paludes habebant, **かつ、絶え間ない[[w:森林|森]]と[[w:沼地|沼地]]を（彼らは）持っていたので *eo se suaque omnia contulerunt. **そこへ自分たちとそのすべての物を運び集めたのだ。 *Ad quarum initium silvarum cum Caesar pervenisset castraque munire instituisset **かかる森の入口のところへカエサルが到着して陣営の防備にとりかかったときに、 *neque hostis interim visus esset, **敵はその間に現れることはなく、 *dispersis in opere nostris **工事において分散されている我が方（ローマ勢）を *subito ex omnibus partibus silvae evolaverunt et in nostros impetum fecerunt. **突然に（敵が）森のあらゆる方面から飛び出してきて、我が方に襲撃をしかけたのだ。 *Nostri celeriter arma ceperunt **我が方は速やかに武器を取って *eosque in silvas reppulerunt et compluribus interfectis **彼らを森の中に押し戻して、かなり（の敵）を殺傷して *longius impeditioribus locis secuti **非常に通りにくい場所を追跡したが、 *paucos ex suis deperdiderunt. **我が方の部下で損傷を負ったのは少数であった。 ===29節=== '''カエサル、むなしく撤兵する''' *Reliquis deinceps diebus Caesar silvas caedere instituit, **続いて（冬が近づくまでの）残りの何日かで、カエサルは森を[[w:伐採|伐採]]することに決めた。 *et ne quis inermibus imprudentibusque militibus ab latere impetus fieri posset, **（これは）非武装で不注意な兵士たちが側面からいかなる襲撃もなされないように（ということであり）、 *omnem eam materiam quae erat caesa conversam ad hostem conlocabat **伐採されたすべての[[w:木材|材木]]を敵の方へ向きを変えて配置して、 *et pro vallo ad utrumque latus exstruebat. **[[w:防柵|防柵]]の代わりに両方の側面に築いた。 *Incredibili celeritate magno spatio paucis diebus confecto, **信じがたいほどの迅速さで大きな空間がわずかな日数で完遂されて、 *cum iam pecus atque extrema impedimenta a nostris tenerentur, **すでに[[w:家畜|家畜]]や[[w:輜重|輜重]]の最も端が我が方（ローマ軍）により捕捉された。 *ipsi densiores silvas peterent, **（敵）自身は密生した森を行くし、 *eiusmodi sunt tempestates consecutae, uti opus necessario intermitteretur **[[w:嵐|嵐]]が続いたので、工事はやむを得ずに中断された。 *et continuatione imbrium diutius sub pellibus milites contineri non possent. **雨が続いて、これ以上は皮（[[w:天幕|天幕]]）の下に兵士たちを留めることはできなかった。 *Itaque vastatis omnibus eorum agris, vicis aedificiisque incensis, **こうして、彼らのすべての畑を荒らして、村々や建物に火をつけて、 *Caesar exercitum reduxit **カエサルは軍隊を連れ戻して、 *et in Aulercis Lexoviisque, reliquis item civitatibus quae proxime bellum fecerant, **[[w:アウレルキ族|アウレルキ族]]と[[w:レクソウィー族|レクソウィイ族]]や、他の同様に最近に戦争をしていた部族たちのところに *in hibernis conlocavit. **[[w:冬営|冬営]]を設置した。 ---- *<span style="background-color:#99ff99;">「ガリア戦記 第3巻」了。「[[ガリア戦記 第4巻]]」へ続く。</span> ==脚注== <references /> [[Category:ガリア戦記 第3巻|*]] 35rkla8kxwvmh8mj9gpzf2m0m4oi7g3 206062 206058 2022-07-31T15:30:14Z Linguae 449 /* 14節 */ 修正 wikitext text/x-wiki [[Category:ガリア戦記|3]] [[ガリア戦記]]＞&nbsp;'''第3巻'''&nbsp;＞[[ガリア戦記 第3巻/注解|注解]] <div style="text-align:center"> <span style="font-size:20px; font-weight:bold; font-variant-caps: petite-caps; color:white; background: rgb(47,94,255);background: linear-gradient(180deg, rgba(47,94,255,1) 0%, rgba(24,56,255,1) 50%, rgba(0,8,255,1) 100%);">&nbsp;C&nbsp;IVLII&nbsp;CAESARIS&nbsp;COMMENTARIORVM&nbsp;BELLI&nbsp;GALLICI&nbsp;</span> <span style="font-size:40px; font-weight:bold; color:white; background: rgb(47,94,255);background: linear-gradient(180deg, rgba(47,94,255,1) 0%, rgba(24,56,255,1) 50%, rgba(0,8,255,1) 100%);">&nbsp;LIBER TERTIVS&nbsp;</span> </div> [[画像:Gaule -56.png|thumb|right|150px|ガリア戦記 第3巻の情勢図（BC56年）。<br>黄色の領域がローマ領。桃色が同盟部族領。]] {| id="toc" style="align:left;clear:all;" align="left" cellpadding="5" ! style="background:#ccccff; text-align:left;" colspan="2" | ガリア戦記 第3巻 目次 |- | style="text-align:right; font-size: 0.86em;"| '''[[#アルプス・オクトードゥールスの戦い|アルプス・オクトードゥールスの戦い]]''':<br /> '''[[#大西洋岸ウェネティー族の造反|大西洋岸ウェネティー族の造反]]''':<br /> <br /> '''[[#大西洋岸ウネッリ族の造反|大西洋岸ウネッリ族の造反]]''':<br /> '''[[#クラッススのアクィタニア遠征|クラッススのアクィタニア遠征]]''':<br /> <br /> '''[[#モリニ族・メナピイ族への遠征|モリニ族・メナピイ族への遠征]]''':<br /> | style="text-align:left; font-size: 0.86em;"| [[#1節|01節]] | [[#2節|02節]] | [[#3節|03節]] | [[#4節|04節]] | [[#5節|05節]] | [[#6節|06節]] <br /> [[#7節|07節]] | [[#8節|08節]] | [[#9節|09節]] | [[#10節|10節]] <br /> [[#11節|11節]] | [[#12節|12節]] | [[#13節|13節]] | [[#14節|14節]] | [[#15節|15節]] | [[#16節|16節]] <br /> [[#17節|17節]] | [[#18節|18節]] | [[#19節|19節]] <br /> [[#20節|20節]] <br /> [[#21節|21節]] | [[#22節|22節]] | [[#23節|23節]] | [[#24節|24節]] | [[#25節|25節]] | [[#26節|26節]] | [[#27節|27節]] <br /> [[#28節|28節]] | [[#29節|29節]] |} <br style="clear:both;" /> __notoc__ ==<span style="color:#009900;">はじめに</span>== :<div style="color:#009900;width:85%;">前巻（[[ガリア戦記 第2巻|ガリア戦記 第2巻]]）の終わりで述べられたように、カエサルによってガッリアはほぼ平定されたと思われて、首都ローマで感謝祭が催されたほどであった。このため、本巻（第3巻）ではカエサル自身の遠征として記す内容はとても少ない。<br><br>本巻の[[#1節]]～[[#6節]]で言及される[[#アルプス・オクトードゥールスの戦い]]は、[[w:紀元前57年|BC57年]]秋頃に起こったと考えられるので、本来なら第2巻に含められるべきであるが、そうなると第3巻が20節ほどの非常に短い巻になってしまうので、第3巻の冒頭に置いたとも考えられる。<br><br>本巻（第3巻）の年（[[w:紀元前56年|BC56年]]）の春には、ガッリア遠征の遂行上きわめて重要な'''ルカ会談'''があったので、以下に補足する。</div> <div style="background-color:#eee;width:75%;"> ===コラム「ルカ会談」=== :::<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Luca Conference|Luca Conference]]''</span>（英語記事）などを参照。 :<span style="color:#009900;">伝記作家[[ガリア戦記/注解編#プルータルコス『対比列伝』|プルータルコス]]によれば<ref>[[ガリア戦記/注解編#プルータルコス『対比列伝』|プルータルコス『対比列伝』]]の「カエサル」20,21</ref>、カエサルはベルガエ人との戦いを成し遂げると、前年に続いて'''パドゥス川'''〔[[w:la:Padus|Padus]] [[w:ポー川|ポー川]]〕流域で越冬しながら、ローマ政界への政治工作を続けた。例えば、カエサルを後援者とする選挙の立候補者たちが有権者を買収するための金銭をばらまいていた。ガッリア人捕虜を奴隷商人に売り払って得た莫大な金銭で。その結果、カエサルの金銭で当選した者たちの尽力で、属州総督カエサルへの新たな資金の支給が可決されるという具合であった。<br><br>そのうち、多くの名門貴族たちがカエサルに面会するために[[w:ルッカ|ルカ]]（[[w:la:Luca|Luca]]）の街へやって来た。<br>こうした中、[[w:紀元前56年|BC56年]]の4月に、カエサルと非公式の盟約（[[w:三頭政治#第一回三頭政治|三頭政治]]）を結んでいた[[w:マルクス・リキニウス・クラッスス|クラッスス]]と[[w:グナエウス・ポンペイウス|ポンペイウス]]もルカを訪れて、三者による会談が行われた。<br><br>首都ローマでは、三頭政治を後ろ盾とする[[w:ポプラレス|平民派]]の[[w:プブリウス・クロディウス・プルケル|クロディウス]]（<span style="font-family:Times New Roman;">[[w:la:Publius Clodius Pulcher|Publius Clodius Pulcher]]</span>）が民衆に暴動をけしかけ、[[w:オプティマテス|門閥派]]のミロ（<span style="font-family:Times New Roman;">[[w:la:Titus Annius Milo|Titus Annius Milo]]</span>）と激しく抗争するなど、騒然としていた。このクロディウスの暴力的な手法は、クラッススとポンペイウスの関係を傷つけた。また、カエサルのガッリアでの輝かしい勝利に、二人とも不満を感じていた。このように三頭政治は綻び出していたのだ。<br><br>三人は三頭政治を延長することで合意した。カエサルは、クラッススとポンペイウスが翌年（[[w:紀元前55年|BC55年]]）の執政官に立候補すること、3属州の総督であるカエサルの任期がさらに5年間延長されること、などを求めた。<br><br>会談の結果、任期が大幅に延長されたカエサルの野望は、ガッリアに止まらず、[[w:ゲルマニア|ゲルマーニア]]や[[w:ブリタンニア|ブリタンニア]]の征服へと向かっていく。一方、再び執政官になった二人は、[[w:パルティア|パルティア]]を攻略するためにクラッススがシリア総督になることを決めるが、これはクラッススの命運とともに三頭政治の瓦解、カエサルとポンペイウスの関係悪化を招来することになる。 </span> <div style="text-align:center"> {| |- |[[画像:First Triumvirate of Caesar, Crassius and Pompey.jpg|thumb|right|500px|後に[[w:三頭政治#第一回三頭政治|三頭政治]]（<span style="font-family:Times New Roman;">[[w:la:Triumviratus|Triumviratus]]</span>）と呼ばれることになる非公式な盟約を結んでいた、左から[[w:ガイウス・ユリウス・カエサル|カエサル]]、[[w:マルクス・リキニウス・クラッスス|クラッスス]]、[[w:グナエウス・ポンペイウス|ポンペイウス]]。<br>3人は、第3巻の戦いが始まる前に、ルカ会談で三頭政治の延長を決めた。]] |} </div> </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ==アルプス・オクトードゥールスの戦い== :<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Battle of Octodurus|Battle of Octodurus]]''</span>（英語記事）<span style="font-family:Times New Roman;font-size:13pt;">''[[w:fr:Bataille d'Octodure|Bataille d'Octodure]]''</span>（仏語記事）などを参照。 ===1節=== [[画像:Historische Karte CH Rome 1.png|thumb|right|300px|現在の[[w:スイス|スイス]]の帝制ローマ時代の地図。左下の三日月形の[[w:レマン湖|レマン湖]]の下方に、<span style="font-family:Times New Roman;">ALLOBROGES, NANTUATES, VERAGRI, SEDUNI</span> の部族名が見える。]] [[画像:Afdaling vd San Bernardino - panoramio.jpg|thumb|right|300px|現在の[[w:グラン・サン・ベルナール峠|グラン・サン・ベルナール峠]]。ラテン語では <span style="font-family:Times New Roman;">[[w:la:Porta Magni Sancti Bernardi|Porta Magni Sancti Bernardi]] という。<br>スイスを縦断する[[w:欧州自動車道路|欧州自動車道路]] [[w:en:European route E27|E27]] が[[w:レマン湖|レマン湖]]からこの峠を通ってイタリアの[[w:アオスタ|アオスタ]]へ至る。</span>]] *<span style="background-color:#ffd;">[[/注解/1節]]　{{進捗|00%|2022-04-23}}</span> '''ガルバとローマ第12軍団が、ロダヌス川渓谷のオクトードゥールスにて冬営する''' <br> ;　　　カエサルが、ガルバと軍団・騎兵をアルプス地方へ派兵 *Cum in Italiam proficisceretur Caesar, **カエサルは、イタリア〔[[w:ガリア・キサルピナ|ガッリア・キサルピーナ]]〕に出発していたときに、 *[[wikt:en:Servium|Servium]] Galbam cum [[w:en:Legio XII Fulminata|legione duodecima(XII.)]] et parte equitatus **[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|セルウィウス・ガルバ]]を第12軍団および騎兵隊の一部とともに、 *in [[wikt:fr:Nantuates#Latin|Nantuates]], [[wikt:en:Veragri#Latin|Veragros]] Sedunosque misit, **ナントゥアーテース族・ウェラーグリー族・セドゥーニー族（の領土）に派遣した。 *qui a finibus [[wikt:en:Allobroges#Latin|Allobrogum]] et lacu [[wikt:fr:Lemannus|Lemanno]] et flumine [[wikt:en:Rhodanus#Latin|Rhodano]] ad summas [[wikt:en:Alpes#Latin|Alpes]] pertinent. **彼らはアッロブロゲース族の領土、レマンヌス湖〔[[w:レマン湖|レマン湖]]〕およびロダヌス川〔[[w:ローヌ川|ローヌ川]]〕から[[w:アルプス山脈|アルプス]]の頂きに及んでいる。 *Causa mittendi fuit, **派遣の理由は（以下のこと）であった： *quod iter per Alpes, **アルプスを通る道は、 *quo magno cum periculo magnisque cum [[wikt:en:portorium|portoriis]] mercatores ire consuerant, **大きな危険と多額の関税を伴って商人たちが旅することが常であったので、 *patefieri volebat. **（カエサルは道が）開かれることを望んでいたのだ。 **:<span style="color:#009900;">（訳注：現在の[[w:グラン・サン・ベルナール峠|グラン・サン・ベルナール峠]]を通ってスイスとイタリアを結ぶ道のことで、<br>　　　　帝制初期に[[w:アウグストゥス|アウグストゥス]]によって街道が敷設された。<br>　　　　かつて[[w:ハンニバル|ハンニバル]]が越えたのは諸説あるが、この道であった可能性もある。<br>　　　　ローマ人がこの地に移入・育成した軍用犬は現在の[[w:セント・バーナード|セント・バーナード犬]]。）</span> *Huic permisit, si opus esse arbitraretur, uti in his locis legionem hiemandi causa conlocaret. **彼〔ガルバ〕に、もし必要と思われるならば、この地に軍団を[[w:冬営|冬営]]するために宿営させることを許可した。 [[画像:Servius Sulpicius Galba.jpg|thumb|right|300px|[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|セルウィウス・スルピキウス・ガルバ]]の横顔が刻まれた貨幣。ガルバは[[w:紀元前54年|BC54年]]（[[ガリア戦記 第5巻|ガリア戦記 第5巻]]の年）に[[w:プラエトル|法務官]]に任官。内戦期もカエサルに従うが、暗殺計画に参画する。<br>[[w:ネロ|ネロ帝]]とともにユリウス家の王朝が途絶えると、ガルバの曽孫が[[w:ローマ内戦_(68年-70年)#四皇帝|四皇帝]]の一人目の[[w:ガルバ|ガルバ帝]]となった。このため[[w:ガイウス・スエトニウス・トランクィッルス|スエートーニウス]]『ローマ皇帝伝』の「ガルバ伝」にガルバへの言及がある<ref>[[s:la:De_vita_Caesarum_libri_VIII/Vita_Galbae#III.]]</ref>。]] <br> ;　　　ガルバが、諸部族を攻略して、軍団の冬営を決める *Galba, secundis aliquot proeliis factis **ガルバは、いくつかの優勢な戦いをして、 *castellisque compluribus eorum expugnatis, **彼ら〔ガッリア諸部族〕の多くの砦が攻略されると、 *missis ad eum undique legatis **彼〔ガルバ〕のもとへ四方八方から（諸部族の）使節たちが遣わされ、 *obsidibusque datis et pace facta, **人質が供出されて、講和がなされたので、 *constituit **（ガルバは、以下のことを）決めた。 *cohortes duas in Nantuatibus conlocare **2個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>をナントゥアーテース族（の領土）に宿営させること、 *et ipse cum reliquis eius legionis cohortibus **（ガルバ）自身はその軍団の残りの<ruby><rb>歩兵大隊</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>とともに、 *in vico Veragrorum, qui appellatur [[wikt:en:Octodurus|Octodurus]], hiemare; **オクトードゥールスと呼ばれているウェラーグリー族の村に冬営することを。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：オクトードゥールス（[[wikt:en:Octodurus|Octodurus]]）は現在の[[w:マルティニー|マルティニー市]]。）</span> <br> ;　　　ウェラーグリー族のオクトードゥールス村 *qui vicus positus in valle, non magna adiecta planitie, **その村は、さほど大きくない平地に付随した渓谷の中に位置し、 *altissimis montibus undique continetur. **とても高い山々で四方八方を囲まれている。 *Cum hic in duas partes flumine divideretur, **これ〔村〕は川によって二つの部分に分け隔てられているので、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：現在の[[w:マルティニー|マルティニー]]の街中を、[[w:ローヌ川|ローヌ川]]の支流であるドランス川（''[[w:en:Drance|Drance]]）が貫流している。）</span> *alteram partem eius vici Gallis [ad hiemandum] concessit, **その村の一方の部分をガッリア人に [越冬するために] 譲った。 *alteram vacuam ab his relictam cohortibus attribuit. **もう一方の彼ら〔ガッリア人〕により空にされた方を、残りの<ruby><rb>歩兵大隊</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>に割り当てた。 *Eum locum vallo fossaque munivit. **その地を堡塁と塹壕で守りを固めた。 <div style="text-align:center"> {| |- |[[画像:Martigny_1600.jpg|thumb|right|600px|かつてウェラーグリー族のオクトードゥールス村（[[w:la:Octodurus|Octodurus]]）があった所は、現在では[[w:スイス|スイス]]の[[w:マルティニー|マルティニー]]（[[w:en:Martigny|Martigny]]）市となっている。[[w:ローヌ川|ローヌ川]]が屈曲して流れる[[w:谷|渓谷]]地帯にある。]] |} </div> <div style="background-color:#eee;width:77%;"> ===コラム「ガルバの派遣とカティリーナ事件」=== :::関連記事：<span style="font-family:Times New Roman;font-size:13pt;">[[w:la:Catilinae coniuratio|Catilinae coniuratio]], ''[[w:en:Second Catilinarian conspiracy|Second Catilinarian conspiracy]]''</span> :<span style="color:#009900;">　[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|セルウィウス・スルピキウス・'''ガルバ''']]にアルプス派兵を指揮させた理由について、カエサルは記していない。<br><br>　[[w:紀元前63年|BC63年]]～[[w:紀元前62年|BC62年]]に、ローマの高官だった[[w:ルキウス・セルギウス・カティリナ|ルーキウス・セルギウス・'''カティリーナ''']]（[[w:la:Lucius Sergius Catilina|Lucius Sergius Catilina]]）がクーデタを企てるという大事件があった。'''[[w:マルクス・トゥッリウス・キケロ|キケロー]]'''が『[[w:カティリナ弾劾演説|カティリナ弾劾演説]]』で糾弾し、カエサルが事件の黒幕ではないかと取り沙汰された(スエートニウス<ref>[[s:la:De_vita_Caesarum_libri_VIII/Vita_divi_Iuli#XIV.]]， [[s:la:De_vita_Caesarum_libri_VIII/Vita_divi_Iuli#XVII.|#XVII.]] を参照。</ref>)。<br>　BC63年の[[w:プラエトル|法務官]][[w:ガイウス・ポンプティヌス|ガーイウス・'''ポンプティーヌス''']]がキケローを助けて事件を捜査し、アッロブロゲース族からカティリーナへ宛てた手紙を調べた。BC62年にポンプティーヌスは前法務官としてガッリア総督となり、事件に関与していたアッロブロゲース族を平定した。このとき、[[w:トリブヌス|副官]]としてポンプティーヌスを助けてアッロブロゲース族を攻めたのが'''ガルバ'''であった。総督がカエサルに替わっても、ガルバは副官として留任し、アッロブロゲース族の近隣部族の鎮定に努めていたわけである。<br>　ポンプティーヌスは、一部の元老院議員の反対で、戦勝将軍の権利である[[w:凱旋式|凱旋式]]ができなかった。これを不満に思っていたガルバは、[[w:紀元前54年|BC54年]]に法務官になると尽力して、その年にポンプティーヌスの凱旋式を行なうことに成功した。 <div style="text-align:center"> {| |- |[[画像:Joseph-Marie Vien - The Oath of Catiline.jpg|thumb|right|320px|'''カティリーナの誓い'''（''Le Serment de Catiline''）<br>[[w:ジョゼフ＝マリー・ヴィアン|ジョゼフ＝マリー・ヴィアン]]画(1809年)。<hr>カティリーナと共謀者たちは、人間の血を混ぜたワインを飲んで誓いを立てる儀式を行なったと伝えられている。]] |[[画像:The Discovery of the Body of Catiline.jpg|thumb|right|320px|'''カティリーナの遺骸の発見'''<br>（''Il ritrovamento del corpo di Catilina''）<br>''[[w:en:Alcide Segoni|Alcide Segoni]]'' 画(1871年)<hr>アッロブロゲース族のいるガッリアへ向かおうとしていたカティリーナは、[[w:ピストイア|ピストリア]]（[[w:la:Pistorium|Pistoria]]）の戦い（''[[w:en:Battle of Pistoia|Battle of Pistoia]]''）で戦死した。]] |} </div> </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===2節=== *<span style="background-color:#ffd;">[[/注解/2節]]　{{進捗|00%|2022-05-05}}</span> '''ガッリア人が再び挙兵して周囲の高峰を押さえ、第12軍団の冬営地を包囲''' *Cum dies hibernorum complures transissent frumentumque eo comportari iussisset, **冬営の多くの日々が過ぎ去って、穀物がそこに運び集められることを（[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|ガルバ]]が）命じていたときに、 *subito per exploratores certior factus est **突然に（以下のことが）[[w:偵察|偵察隊]]により報告された。 *ex ea parte vici, quam Gallis concesserat, omnes noctu discessisse **ガッリア人たちに譲っていた村の一部から、皆が夜に立ち退いており、 *montesque, qui [[wikt:en:impendeo#Latin|impenderent]], a maxima multitudine Sedunorum et [[wikt:en:Veragri|Veragrorum]] teneri. **そそり立つ山々がセドゥーニー族とウェラーグリー族のかなりの大勢により占拠されたのだ。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：ウェラーグリー族は既述のようにオクトードゥールス村 [[w:la:Octodurus|Octodurus]]〔現在の[[w:マルティニー|マルティニー市]]〕を、<br>セドゥーニー族 [[w:la:Seduni|Seduni]] はより上流のセドゥヌム [[w:la:Sedunum|Sedunum]]〔現在の[[w:シオン (スイス)|シオン市]]〕を首邑としていた。）</span> *Id aliquot de causis acciderat, **いくつかの理由から、起こっていたことには、 *ut subito Galli belli renovandi legionisque opprimendae consilium caperent: **突如としてガッリア人が、戦争を再開して（ローマ人の）軍団を急襲する作戦計画を立てたのだ。 <br> ;　　　　第1の理由：ガルバの第12軍団は、兵が割かれていて寡勢である *primum, quod legionem neque eam plenissimam detractis cohortibus duabus **というのも、第一に、総員がそろっていない軍団を&nbsp;──2個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>が引き抜かれていて、 **:<span style="color:#009900;">（訳注：前節で既述のように、2個歩兵大隊をナントゥアーテース族のところに宿営させていたが、これはレマンヌス湖〔[[w:レマン湖|レマン湖]]〕に近いより下流の地域で、離れていたようだ。）</span> *et compluribus singillatim, qui commeatus petendi causa missi erant, absentibus, **多くの者たちが一人ずつ、糧食を求めるために派遣されていて不在である、── *propter paucitatem despiciebant; **（その第12軍団を）少数であるゆえに、見下していたからだ。 <br> ;　　　　第2の理由：渓谷にいるローマ人は、山から攻め降りて来るガッリア人の飛道具を受け止められまい *tum etiam, quod propter iniquitatem loci, **それからさらに（ローマ勢が冬営している渓谷の）地の利の無さゆえ、 *cum ipsi ex montibus in vallem decurrerent et tela conicerent, **（ガッリア勢）自身が山々から谷間に駆け下りて飛道具を投じたときに、 *ne primum quidem impetum suum posse sustineri existimabant. **自分たちの最初の襲撃を（ローマ勢が）持ちこたえることができない、と判断していたので。 <br> ;　　　　第3の理由：人質を取られて、属州に併合される前にローマ人を討て *Accedebat, quod suos ab se liberos abstractos obsidum nomine dolebant, **加えて、人質の名目で自分たちから引き離されている自分の子供たちのことを嘆き悲しんでいたので、 *et Romanos non solum itinerum causa, sed etiam perpetuae possessionis **かつ、ローマ人たちは道（の開通）のためだけでなく、永続的な領有のためにさえも *culmina Alpium occupare <u>conari</u> **アルプスの頂上を占領すること、 *et ea loca finitimae provinciae adiungere **および（ローマの）属州に隣接する当地を併合することを<u>企てている</u>、 *sibi persuasum habebant. **と（ガッリア人たちは）確信していたのである。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===3節=== *<span style="background-color:#ffd;">[[/注解/3節]]　{{進捗|00%|2022-05-12}}</span> '''ガルバが軍議を召集し、策を募る''' *His nuntiis acceptis Galba, **ガルバは、これらの報告を受け取ると、 *<u>cum</u> neque opus hibernorum munitionesque plene essent perfectae **冬営の普請や防塁構築も十分に完成していなかったし、 *neque de frumento reliquoque commeatu satis esset provisum, **穀物や他の糧秣も十分に調達されていなかった<u>ので</u>、 *quod deditione facta obsidibusque acceptis **── というのも、降伏がなされて、人質が受け取られ、 *nihil de bello timendum existimaverat, **戦争について恐れるべきことは何もない、と判断していたためであるが、── *consilio celeriter convocato sententias exquirere coepit. **軍議を速やかに召集して、意見を求め始めた。 <br> ;軍議 *Quo in consilio, **その軍議において、 *<u>cum</u> tantum repentini periculi praeter opinionem accidisset **これほどの不意の危険が、予想に反して起こっていたので、 *ac iam omnia fere superiora loca multitudine armatorum completa conspicerentur **かつ、すでにほぼすべてのより高い場所が、武装した大勢の者たちで満たされていることが、見られていたので、 *neque subsidio veniri **救援のために（援軍が）来られることもなかったし、 *neque commeatus supportari interclusis itineribus possent, **糧秣が運び込まれることも、道が遮断されているので、できなかった<u>ので</u>、 *prope iam desperata salute non nullae eius modi sententiae dicebantur, **すでにほぼ身の安全に絶望していた幾人かの者たちの'''以下のような'''意見が述べられていた。 *ut impedimentis relictis eruptione facta **輜重を残して、出撃して、 *isdem itineribus quibus eo pervenissent ad salutem contenderent. **そこへやって来たのと同じ道によって、安全なところへ急ぐように、と。 **:<span style="color:#009900;">（訳注：レマンヌス〔[[w:レマン湖|レマン湖]]〕湖畔を通ってアッロブロゲース族領へ撤収することであろう。）</span> *Maiori tamen parti placuit, **しかしながら、大部分の者が賛成したのは、 *hoc reservato ad extremum consilio **この考え（計画）を最後まで保持しておいて、 *interim rei eventum experiri et castra defendere. **その間に、事の結果を吟味して、陣営を守備すること、であった。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===4節=== *<span style="background-color:#ffd;">[[/注解/4節]]　{{進捗|00%|2022-05-16}}</span> '''ガッリア勢がガルバの陣営を急襲し、寡兵のローマ勢は劣勢に陥る''' *Brevi spatio interiecto, **（敵の来襲まで）短い間が介在しただけだったので、 *vix ut iis rebus quas constituissent conlocandis atque administrandis tempus daretur, **決めておいた物事を配置したり遂行するための時間が、ほとんど与えられないほどであった。 *hostes ex omnibus partibus signo dato decurrere, **敵方〔ガッリア勢〕があらゆる方向から、号令が出されて、駆け下りて来て、 *lapides [[wikt:en:gaesum|gaesa]]que in vallum conicere. **石や投槍を堡塁の中に投げ込んだ。 *Nostri primo integris viribus fortiter propugnare **我が方〔ローマ勢〕は、当初、体力が損なわれていないうちは勇敢に応戦して、 *neque ullum frustra telum ex loco superiore mittere, **高所から、いかなる飛道具も無駄に投げることはなかった。 *et quaecumque<!--ut quaeque--> pars castrorum nudata defensoribus premi videbatur, **陣営のどの部分であれ、防戦者たちがはがされて押され気味であることと思われれば、 *eo occurrere et auxilium ferre, **（ローマ勢が）そこへ駆け付けて、支援した。 <br> ;　　兵の多寡が、ローマ勢を追い込む *sed hoc superari **しかし、以下のことにより（ローマ勢は）打ち破られた。 *quod diuturnitate pugnae hostes defessi proelio excedebant, **──戦いが長引いたことにより、疲れ切った敵たちは戦闘から離脱して、 *alii integris viribus succedebant; **体力が損なわれていない他の者たちが交代していたのだ。── *quarum rerum a nostris propter paucitatem fieri nihil poterat, **我が方〔ローマ勢〕は少数であるゆえに、このような事〔兵の交代〕は何らなされ得なかった。 *ac non modo defesso ex pugna excedendi, **疲弊した者にとっての戦いから離脱することの（機会）のみならず、 *sed ne saucio quidem eius loci ubi constiterat relinquendi ac sui recipiendi facultas dabatur. **負傷した者にとってさえも、その持ち場を放棄することや（体力を）回復することの機会も与えられなかったのだ。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===5節=== *<span style="background-color:#ffd;">[[/注解/5節]]　{{進捗|00%|2022-05-29}}</span> '''最後の土壇場で説得されたガルバが、疲労回復後の突撃に命運を賭ける''' *<u>Cum</u> iam amplius horis sex continenter pugnaretur, **すでに6時間より多く引き続いて戦われており、 **:<span style="color:#009900;">（訳注：[[古代ローマの不定時法]]では、冬の日中の半日ほどである）</span> *ac non solum vires sed etiam tela nostros deficerent, **活力だけでなく飛道具さえも我が方〔ローマ勢〕には不足していたし、 *atque hostes acrius instarent **敵方〔ガッリア勢〕はより激しく攻め立てていて、 *languidioribusque nostris **我が方〔ローマ勢〕が弱り切っており、 *vallum scindere et fossas complere coepissent, **（ガッリア勢は）防柵を破却したり、塹壕を埋め立てたりし始めていたし、 *resque esset iam ad extremum perducta casum, **戦況はすでに最後の土壇場に陥っていた<u>ので</u>、 <br> ;　　二人の軍団首脳バクルスとウォルセーヌスが、ガルバに敵中突破を説く *[[wikt:en:P.|P.]] Sextius Baculus, primi pili centurio, **<ruby><rb>[[w:プリムス・ピルス|首位百人隊長]]</rb><rp>（</rp><rt>プリームス・ピールス</rt><rp>）</rp></ruby>プーブリウス・セクスティウス・バクルス **:<span style="color:#009900;">（訳注：[[w:la:Publius Sextius Baculus|Publius Sextius Baculus]] などの記事を参照。）</span> *quem Nervico proelio compluribus confectum vulneribus diximus, **──その者が[[w:ネルウィイ族|ネルウィイー族]]との戦いで多くの負傷で消耗したと前述した── **:<span style="color:#009900;">（訳注：[[ガリア戦記 第2巻#25節|第2巻25節]]を参照。なお、[[ガリア戦記 第6巻#38節|第6巻38節]] でも言及される。）</span> *et item [[wikt:en:C.#Latin|C.]] Volusenus, tribunus militum, vir et consilii magni et virtutis, **および、[[w:トリブヌス・ミリトゥム|軍団次官]]ガーイウス・ウォルセーヌス ──卓越した判断力と武勇を持つ男──（の2人）は、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:en:Gaius Volusenus|Gaius Volusenus]]'' などの記事を参照せよ。）</span> *ad Galbam accurrunt **ガルバのもとへ急いで来て、 *atque unam esse spem salutis docent, si eruptione facta extremum auxilium experirentur. **身の安全のただ一つの希望は、出撃をして最後の救済策を試みるかどうかだ、と説く。 *Itaque convocatis centurionibus **こうして、<ruby><rb>[[w:ケントゥリオ|百人隊長]]</rb><rp>（</rp><rt>ケントゥリオー</rt><rp>）</rp></ruby>たちが召集されて、 *celeriter milites certiores facit, **（ガルバが以下のことを）速やかに兵士たちに通達する。 *paulisper intermitterent proelium **しばらく戦いを中断して *ac tantummodo tela missa exciperent seque ex labore reficerent, **ただ投げられた飛道具を遮るだけとし、疲労から（体力を）回復するようにと、 *post dato signo ex castris erumperent, **与えられた号令の後に陣営から出撃するように、 *atque omnem spem salutis in virtute ponerent. **身の安全のすべての希望を武勇に賭けるように、と。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===6節=== *<span style="background-color:#ffd;">[[/注解/6節]]　{{進捗|00%|2022-06-05}}</span> '''第12軍団がガッリア勢を破るが、ガルバはオクトードゥールスでの冬営を断念する''' *Quod iussi sunt faciunt, **（ローマ兵たちは）命じられたことをなして、 *ac subito omnibus portis eruptione facta **突然に（陣営の）すべての門から出撃がなされ、 *neque cognoscendi quid fieret **何が生じたのかを知ることの（機会）も *neque sui colligendi hostibus facultatem relinquunt. **（自軍の兵力を）集中することの機会も、敵方に残さない。 *Ita commutata fortuna **こうして武運が変転して、 *eos qui in spem potiundorum castrorum venerant undique circumventos intercipiunt, **（ローマ人の）陣営を占領することを期待してやって来ていた者たちを、至る所で包囲して<ruby><rb>屠</rb><rp>（</rp><rt>ほふ</rt><rp>）</rp></ruby>る。 *et ex hominum milibus amplius XXX{triginta}, **3万より多い人間が *quem numerum barbarorum ad castra venisse constabat, **それだけの数の蛮族が（ローマ）陣営のところへ来ていたのは、確実であったが、 *plus tertia parte interfecta **3分の1より多く（の者）が<ruby><rb>殺戮</rb><rp>（</rp><rt>さつりく</rt><rp>）</rp></ruby>されて、 *reliquos perterritos in fugam coiciunt **（ローマ勢は）残りの者たちを怖気づかせて敗走に追いやり、 *ac ne in locis quidem superioribus consistere patiuntur. **（ガッリア勢は）より高い場所にさえ留まることさえ許されない。 *Sic omnibus hostium copiis fusis armisque exutis **そのように敵方の全軍勢が撃破されて、武器が放棄されて、 *se intra munitiones suas recipiunt. **（ローマ勢は）自分たちの防塁の内側に撤収する。 <br> ;　　ガルバがオクトードゥールスでの冬営を断念して、同盟部族領に撤退する *Quo proelio facto, **この戦いが果たされると、 *quod saepius fortunam temptare Galba nolebat **──ガルバは、よりたびたび武運を試すことを欲していなかったし、 *atque alio se in hiberna consilio venisse meminerat, **冬営に他の計画のために来ていたことを思い出していたが、 *aliis occurrisse rebus videbat, **別の事態に遭遇したのを見ていたので、── *maxime frumenti commeatusque inopia permotus **とりわけ穀物や糧秣の欠乏に揺り動かされて、 *postero die omnibus eius vici aedificiis incensis **翌日にその村のすべての建物が焼き討ちされて、 *in provinciam reverti contendit, **（ガルバは）属州〔[[w:ガリア・キサルピナ|ガッリア・キサルピーナ]]〕に引き返すことを急ぐ。 *ac nullo hoste prohibente aut iter demorante **いかなる敵によって妨げられることも、あるいは行軍が遅滞させられることもなく、 *incolumem legionem in Nantuates, **軍団を無傷なままでナントゥアーテース族（の領土）に（連れて行き）、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：ナントゥアーテース族 ''[[w:en:Nantuates|Nantuates]]'' は、レマンヌス湖〔[[w:レマン湖|レマン湖]]〕の南東を領有していた部族。<br>　　　　[[#1節]]で、軍団のうち2個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>を宿営させたことが述べられた。）</span> *inde in Allobroges perduxit ibique hiemavit. **そこから、アッロブロゲース族（の領土）に連れて行き、そこで冬営した。 <div style="text-align:center"> {| |- |[[画像:Amphitheaterforumclaudiival1.jpg|thumb|right|500px|オクトードゥールス（<span style="font-family:Times New Roman;">[[w:la:Octodurus|Octodurus]]</span>）、すなわち現在の[[w:マルティニー|マルティニー市]]に遺る帝制ローマ時代の円形競技場。オクトードゥールスは、<span style="font-family:Times New Roman;">Forum Claudii Vallensium</span> と改称され、[[w: クラウディウス|クラウディウス帝]]によって円形競技場が建てられた。<br>（<span style="font-family:Times New Roman;">''[[w:fr:Amphithéâtre de Martigny|Amphithéâtre de Martigny]]''</span> 等の記事を参照。）]] |} </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ==大西洋岸ウェネティー族の造反== :::<span style="background-color:#ffd;">関連記事：[[w:モルビアン湾の海戦|モルビアン湾の海戦]]、''[[w:fr:Guerre des Vénètes|fr:Guerre des Vénètes]]'' 等を参照せよ。</span> ===7節=== *<span style="background-color:#ffd;">[[/注解/7節]]　{{進捗|00%|2022-06-12}}</span> '''新たな戦争の勃発''' *His rebus gestis **これらの戦役が遂げられて、 *cum omnibus de causis Caesar pacatam Galliam existimaret, **カエサルが、あらゆる状況についてガッリアは平定された、と判断していたときに、 *superatis Belgis, **（すなわち）[[w:ベルガエ|ベルガエ人]]は征服され、 **:<span style="color:#009900;">（訳注：第2巻で述べられたこと）</span> *expulsis Germanis, **[[w:ゲルマニア|ゲルマーニア]]人は駆逐され、 **:<span style="color:#009900;">（訳注：第1巻で述べられた[[w:アリオウィストゥス|アリオウィストゥス]]との戦役のこと）</span> *victis in [[wikt:en:Alpibus|Alpibus]] Sedunis, **アルペース〔[[w:アルプス山脈|アルプス]]〕においてセドゥーニー族は打ち負かされて、 **:<span style="color:#009900;">（訳注：[[#1節]]～[[#6節]]で述べられたこと）</span> *atque ita inita hieme in [[wikt:en:Illyricum#Latin|Illyricum]] profectus esset, **こうして冬の初めに（カエサルが）[[w:イリュリクム|イッリュリクム]]に出発していたときに、 *quod eas quoque nationes adire et regiones cognoscere volebat, **──というのは、これら各部族を訪れて諸地方を知ることを欲していたからであるが、── **:<span style="color:#009900;">（訳注：属州総督の職務として、巡回裁判を行う必要があったためであろう）</span> *subitum bellum in Gallia coortum est. **突然の戦争がガッリアで勃発したのである。 <br> ;　　　戦争の背景 *Eius belli haec fuit causa: **その戦争の原因は、以下の通りであった。 *[[wikt:en:P.|P.]] Crassus adulescens cum legione septima(VII.) **[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス青年]]は、第7軍団とともに **:<span style="color:#009900;">（訳注：三頭政治家[[w:マルクス・リキニウス・クラッスス|M. クラッスス]]の息子で、第1巻[[s:la:Commentarii_de_bello_Gallico/Liber_I#52|52節]]では騎兵隊の指揮官だった。<br>　　　　[[ガリア戦記_第2巻#34節|第2巻34節]]では、1個軍団とともに大西洋沿岸地方に派遣されたと述べられた。）</span> *proximus mare Oceanum in Andibus hiemarat. **<ruby><rb>大洋〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>に最も近いアンデース族（の領土）で冬営していた。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：アンデース族 Andes は、'''アンデカーウィー族''' [[w:la:Andecavi|Andecavi]], ''[[wikt:en:Andecavi|Andecavi]]'' と呼ばれることが多い。<br>　　　　実際には大西洋岸から内陸側に寄っていたと考えられている。）</span> *Is, quod in his locis inopia frumenti erat, **彼〔クラッスス〕は、これらの場所においては穀物の欠乏があったので、 *praefectos tribunosque militum complures in finitimas civitates **（[[w:アウクシリア|支援軍]]の）<ruby><rb>[[w:プラエフェクトゥス|指揮官]]</rb><rp>（</rp><rt>プラエフェクトゥス</rt><rp>）</rp></ruby>たちや[[w:トリブヌス・ミリトゥム|軍団次官]]たちのかなりの数を、近隣諸部族のところへ *frumenti (commeatusque petendi) causa dimisit; **穀物や糧食を求めるために送り出した。 *quo in numero est [[wikt:en:T.#Latin|T.]] Terrasidius missus in Esuvios<!--/ Unellos Essuviosque-->, **その人員のうち、ティトゥス・テッラシディウスは、エスウィイー族<!--ウネッリー族やエスウィイ族-->のところに遣わされ、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：テッラシディウスは騎士階級の将校。''[[w:en:Terrasidius|Terrasidius]]'' 参照。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：エスウィイー族 ''[[w:en:Esuvii|Esuvii]]'' は、現在の[[w:オルヌ川|オルヌ川]]盆地の[[w:オルヌ県|オルヌ県]][[w:セー (オルヌ県)|セー]]～[[w:fr:Exmes|エム]]の辺りにいたらしい。）</span> *[[wikt:en:M.#Latin|M.]] [[wikt:en:Trebius#Latin|Trebius]] Gallus in Coriosolităs, **マールクス・トレビウス・ガッルスは、コリオソリテース族のところに（遣わされ）、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:it:Marco Trebio Gallo|it:Marco Trebio Gallo]]'' 等参照）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：コリオソリテース族 ''[[w:en:Coriosolites|Coriosolites]]'' は、クーリオソリーテース ''[[wikt:en:Curiosolites|Curiosolites]]'' などとも呼ばれ、<br>　　　　現在の[[w:コート＝ダルモール県|コート＝ダルモール県]]コルスール([[w:en:Corseul|Corseul]])の辺りにいたらしい。）</span> *[[wikt:en:Q.|Q.]] [[wikt:en:Velanius#Latin|Velanius]] cum T. Sillio in Venetos. **クゥイーントゥス・ウェラーニウスはティトゥス・シーッリウスとともに、[[w:ウェネティ族 (ガリア)|ウェネティー族]]のところに（遣わされた）。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:it:Quinto Velanio|it:Quinto Velanio]], [[w:it:Tito Silio|it:Tito Silio]]'' 等参照。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:ウェネティ族 (ガリア)|ウェネティー族]] ''[[w:en:Veneti (Gaul)|Veneti (Gaul)]]'' は、[[w:アルモリカ|アルモリカ]]南西部、現在の[[w:モルビアン県|モルビアン県]]辺りにいた。）</span> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===8節=== *<span style="background-color:#ffd;">[[/注解/8節]]　{{進捗|00%|2022-06-13}}</span> '''ウェネティー族らの動き''' <br> ;　　　沿海地方を主導するウェネティー族 *Huius est civitatis longe amplissima auctoritas omnis orae maritimae regionum earum, **この部族〔ウェネティー族〕の<ruby><rb>影響力</rb><rp>（</rp><rt>アウクトーリタース</rt><rp>）</rp></ruby>は、海岸のその全地方の中でずば抜けて大きい。 *quod et naves habent Veneti plurimas, **── というのは、[[w:ウェネティ族 (ガリア)|ウェネティー族]]は、最も多くの船舶を持っており、 *quibus in Britanniam navigare consuerunt, **それら〔船団〕によって[[w:ブリタンニア|ブリタンニア]]に航海するのが常であり、 *et scientia atque usu rerum nauticarum ceteros antecedunt **かつ[[w:海事|海事]]の知識と経験において他の者たち〔諸部族〕をしのいでおり、 *et in magno impetu maris atque aperto &lt;Oceano&gt; **かつ海のたいへんな荒々しさと開けた&lt;<ruby><rb>大洋〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>&gt;において、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：&lt;Oceano&gt; は写本になく、挿入提案された修正読み）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:大陸棚|大陸棚]]が広がる[[w:ビスケー湾|ビスケー湾]]は、世界最大12mの大きな[[w:潮汐|干満差]]と、<br>　　　　北西風による激しい嵐で知られる<ref>[https://kotobank.jp/word/%E3%83%93%E3%82%B9%E3%82%B1%E3%83%BC%E6%B9%BE-119819 ビスケー湾とは - コトバンク]</ref>。）</span> *paucis portibus interiectis, **わずかの港が介在していて、 *quos tenent ipsi, **彼ら自身〔ウェネティー族〕がそれら〔港湾〕を制していて、 *omnes fere qui eo mari uti consuerunt, habent vectigales. **その海を利用するのが常であった者たち〔部族〕ほぼすべてを、貢税者としていたのだ。── <br> ;　　　ウェネティー族が、クラッススの使節たちを抑留する *Ab his fit initium retinendi Sillii atque Velanii, **彼ら〔ウェネティー族〕によって、シーッリウスとウェラーニウスを拘束することが皮切りとなる。 **:<span style="color:#009900;">（訳注：2人は、前節([[#7節]])でウェネティー族への派遣が述べられた使節）</span> *<u>et si quos intercipere potuerunt</u> **何らかの者たちを捕えることができたのではないか、と。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：下線部は、&beta;系写本だけの記述で、&alpha;系写本にはない。）</span> *quod per eos suos se obsides, quos Crasso dedissent, recuperaturos existimabant. **というのは、彼らを介して、[[w:プブリウス・リキニウス・クラッスス|クラッスス]]に差し出されていた己の人質たちを取り戻すことができると考えていたのである。 <br> *Horum auctoritate finitimi adducti, **彼ら〔ウェネティー族〕の影響力によって、近隣の者たち〔諸部族〕が動かされて、 *ut sunt Gallorum subita et repentina consilia, **──ガッリア人の判断力というものは、思いがけなく性急なものであるが、── *eadem de causa Trebium Terrasidiumque retinent **同じ理由によりトレビウスとテッラシディウスを拘束する。 **:<span style="color:#009900;">（訳注：トレビウスは、前節でコリオソリテース族に派遣された。<br>　　　　テッラシディウスは、前節でエスウィイー族に派遣された。）</span> *et celeriter missis legatis **そして速やかに使節が遣わされて、 *per suos principes inter se coniurant **自分らの領袖たちを通して互いに誓約する。 *nihil nisi communi consilio acturos eundemque omnes fortunae exitum esse laturos, **合同の軍議なしには何も実施しないであろうし、皆が命運の同じ結果に耐えるであろう、と。 *reliquasque civitates sollicitant, **残りの諸部族を扇動する。 *ut in ea libertate quam a maioribus acceperint, permanere quam Romanorum servitutem perferre malint. **ローマ人への隷属を辛抱することより、むしろ先祖から引き継いでいた自由に留まることを欲すべし、と。 <br> *Omni ora maritima celeriter ad suam sententiam perducta **すべての海岸（の諸部族）が速やかに自分たち〔ウェネティー族〕の見解に引き込まれると、 *communem legationem ad [[wikt:en:Publium|Publium]] Crassum mittunt, **共同の使節を[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス]]のもとへ遣わす。 *si velit suos recuperare, obsides sibi remittat. **もし味方の者たち〔ローマ人〕を取り戻すことを望むならば、自分たち〔諸部族〕の人質たちを返すように、と。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===9節=== *<span style="background-color:#ffd;">[[/注解/9節]]　{{進捗|00%|2022-06-19}}</span> {{Wikipedia|la:Liger| Liger }} '''カエサル到着、ウェネティー族らの作戦と開戦準備''' ;　　　カエサルが、海戦の準備を手配してから、沿岸地域に急ぐ *Quibus de rebus Caesar a Crasso certior factus, **以上の事について、カエサルは[[w:プブリウス・リキニウス・クラッスス|クラッスス]]により報知されると、 *quod ipse aberat longius, **（カエサル）自身は非常に遠くに離れていたので、 **:<span style="color:#009900;">（訳注：[[#コラム「ルカ会談」|#ルカ会談]]などローマへの政界工作のために属州にいたと考えられている。）</span> *naves interim longas aedificari in flumine [[wikt:la:Liger#Latine|Ligeri]], quod influit in Oceanum, **その間に<u>軍船</u>が<ruby><rb>大洋〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>に流れ込むリゲル川〔[[w:ロワール川|ロワール川]]〕にて建造されること、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：艦隊 [[w:la:Classis Romana|classis]] の主力として戦う[[w:ガレー船|ガレー船]]は「長船」[[w:la:Navis longa|navis longa]] と呼ばれていた。<br>　　　　これに対して、軍需物資を運搬する輸送船は [[w:la:Navis actuaria|navis actuaria]] と呼ばれていた。）</span> *remiges ex provincia institui, **<ruby><rb>漕ぎ手</rb><rp>（</rp><rt>レーメクス</rt><rp>）</rp></ruby>が属州〔[[w:ガリア・トランサルピナ|ガッリア・トランサルピーナ]]〕から採用されること、 *nautas gubernatoresque comparari iubet. **<ruby><rb>[[w:船員|水夫]]</rb><rp>（</rp><rt>ナウタ</rt><rp>）</rp></ruby>や<ruby><rb>操舵手</rb><rp>（</rp><rt>グベルナートル</rt><rp>）</rp></ruby>が徴募されること、を命じる。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：船尾の「<ruby><rb>[[w:舵|舵]]</rb><rp>（</rp><rt>かじ</rt><rp>）</rp></ruby>」が発明されたのは[[w:漢|漢代]]の中国であって、古代西洋の船に<ruby><rb>舵</rb><rp>（</rp><rt>かじ</rt><rp>）</rp></ruby>はない。<br>　　　　船の操舵手は「<ruby><rb>舵櫂</rb><rp>（</rp><rt>かじかい</rt><rp>）</rp></ruby>」(''[[w:en:Steering oar|steering oar]]'') という[[w:櫂|櫂]]の一種を用いて操船したらしい。）</span> <br> *His rebus celeriter administratis ipse, **これらの事柄が速やかに処理されると、（カエサル）自身は *cum primum per anni tempus potuit, ad exercitum contendit. **年のできるだけ早い時季に、軍隊のもとへ急いだ。 <br> ;　　　ウェネティー族らが、使節団拘留の重大さを勘案して、海戦の準備を進める *Veneti reliquaeque item civitates cognito Caesaris adventu **[[w:ウェネティ族 (ガリア)|ウェネティー族]]と残りの部族もまた、カエサルの到着を知り、 *<span style="color:#009900;">&lt;</span>et de recipiendis obsidibus spem se fefellise<span style="color:#009900;">&gt;</span> certiores facti, **<span style="color:#009900;">&lt;</span>かつ人質を取り戻すという希望に惑わされたことを<span style="color:#009900;">&gt;</span> 知らされて、 *simul quod quantum in se facinus admisissent intellegebant, **同時に、どれほど大それた行為を自分たちが侵していたかを判断していたので、 *<span style="color:#009900;">[</span>legatos, quod nomen ad omnes nationes sanctum inviolatumque semper fuisset, **──（すなわち）あらゆる種族のもとでその名が神聖かつ不可侵の、使節たちが *retentos ab se et in vincula coniectos,<span style="color:#009900;">]</span> **自分たちによって拘束され、鎖につながれていたわけだが、── *pro magnitudine periculi bellum parare **危機の重大さに見合う戦争を準備すること、 *et maxime ea quae ad usum navium pertinent providere instituunt, **とりわけ船団を運用するために役立つところのものを調達すること、を着手する。 *hoc maiore spe quod multum natura loci confidebant. **地勢を大いに信じていた点に大きな期待をして。 <br> *Pedestria esse itinera concisa aestuariis, **（ローマ勢の）歩兵の行軍路は入江で遮断されるし、 *navigationem impeditam propter inscientiam locorum paucitatemque portuum sciebant, **土地の不案内と港の少なさのゆえに航行が妨げられることを（ウェネティー族らは）知っていた。 *neque nostros exercitus propter inopiam frumenti diutius apud se morari posse confidebant; **穀物の欠乏のゆえに、我が軍〔ローマ軍〕がより長く彼らのもとに留まることができないと（ウェネティー族らは）信じ切っていた。 <br> *ac iam ut omnia contra opinionem acciderent, **やがて、すべてのことが予想に反して生じたとしても、 *tamen se plurimum navibus posse, quam Romanos neque ullam facultatem habere navium, **けれども自分たち〔ウェネティー族ら〕は艦船において、艦船の備えを何ら持たないローマ人よりも大いに優勢であり、 *neque eorum locorum, ubi bellum gesturi essent, vada, portus, insulas novisse; **戦争を遂行しようとしているところの浅瀬・港・島に（ローマ人は）不案内であった（と信じ切っていた）。 <br> *ac longe aliam esse navigationem in concluso mari atque in vastissimo atque apertissimo Oceano perspiciebant. **閉ざされた海〔[[w:地中海|地中海]]〕と非常に広大で開けた大洋における航行はまったく別物であると見通していた。 <br> *His initis consiliis **この作戦計画が決められると、 *oppida muniunt, **<ruby><rb>[[w:オッピドゥム|城塞都市]]</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の防備を固め、 *frumenta ex agris in oppida comportant, **穀物を耕地から<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>に運び込み、 *naves in [[wikt:en:Venetia#Latin|Venetiam]], ubi Caesarem primum (esse) bellum gesturum constabat, quam plurimas possunt, cogunt. **カエサルが最初の戦争を遂行するであろうことが明白であったところの[[w:ウェネティ族 (ガリア)|ウェネティー族]]領に、ありったけの艦船を集める。 <br> *Socios sibi ad id bellum **この戦争のために（ウェネティー族は）自分たちのもとへ同盟者として *[[wikt:en:Osismi#Latin|Osismos]], [[wikt:en:Lexovii#Latin|Lexovios]], [[wikt:en:Namnetes#Latin|Namnetes]], Ambiliatos, [[wikt:en:Morini#Latin|Morinos]], [[w:en:Diablintes|Diablintes]], [[wikt:en:Menapii#Latin|Menapios]] adsciscunt; **<span style="font-size:10pt;">オスィスミー族・レクソウィイー族・ナムネーテース族・アンビリアーティー族・モリニー族・ディアブリンテース族・メナピイー族</span>&nbsp;を引き入れる。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：アンビリアーティー族 ➡ [[w:ガイウス・プリニウス・セクンドゥス|プリニウス]]は「アンビラトリー族」 [[wikt:en:Ambilatri#Latin|Ambilatri]] と記す。<br>　　　　ディアブリンテース族 ➡ プリニウスは「ディアブリンティー族」 [[wikt:en:Diablinti#Latin|Diablinti]] と記す。<br>　　　　　　　　　　　　　　　　この部族は、アウレルキー族 ''[[w:en:Aulerci|Aulerci]]'' の支族。）</span> *auxilia ex Britannia, quae contra eas regiones posita est, arcessunt. **援軍を、この地域の向かい側に位置する[[w:ブリタンニア|ブリタンニア]]から呼び寄せた。 **:<span style="color:#009900;">（訳注：援軍を出したという口実のもと、翌年カエサルがブリタンニアに侵攻することになる。）</span> <div style="text-align:center"> {| |- |[[画像:Map of Aremorican tribes (Latin).svg|thumb|right|600px|[[w:アルモリカ|アルモリカ]]（<span style="font-family:Times New Roman;font-size:13pt;">''[[w:en:Armorica|Armorica]]''</span> ）の部族分布図。 ]] |} </div> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===10節=== *<span style="background-color:#ffd;">[[/注解/10節]]　{{進捗|00%|2022-07-02}}</span> '''カエサルの開戦への大義名分''' *Erant hae difficultates belli gerendi, quas supra ostendimus, **上で指摘したような、戦争を遂行することの困難さがあった。 *sed tamen multa Caesarem ad id bellum incitabant: **にもかかわらず、多くのことがカエサルをその戦争へと駆り立てていたのだ。 *iniuria retentorum equitum Romanorum, **①ローマ人の[[w:エクィテス|騎士]]〔騎士階級の者〕たちが拘束されることの無法さ、 *rebellio facta post deditionem, **②降伏の後でなされた造反、 *defectio datis obsidibus, **③人質を供出しての謀反、 *tot civitatum coniuratio, **④これほど多くの部族の共謀、 *in primis ne hac parte neglecta reliquae nationes sibi idem licere arbitrarentur. **⑤何よりも第一に、この地方をなおざりにして、残りの種族が自分たちも同じことを許容されると思い込まないように。 *Itaque cum intellegeret **そこで、（カエサルは以下のように）認識していたので、 *omnes fere Gallos novis rebus studere et ad bellum mobiliter celeriterque excitari, **①ほぼすべてのガリア人が政変を熱望して、戦争へ簡単に速やかに奮い立たせられていること、 *omnes autem homines natura libertati studere incitari et condicionem servitutis odisse, **②他方ですべての人間は本来的に自由を熱望することに扇動され、隷属の状態を嫌っていること、 *prius quam plures civitates conspirarent, **多くの部族が共謀するより前に、 *partiendum sibi ac latius distribuendum exercitum putavit. **（カエサルは）自分にとって軍隊が分けられるべき、より広範に割り振られるべきであると考えた。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===11節=== *<span style="background-color:#ffd;">[[/注解/11節]]　{{進捗|00%|2022-07-03}}</span> '''ラビエーヌス、クラッスス、サビーヌス、ブルートゥスを前線へ派兵する''' <br><br> ;　　　副官ラビエーヌスをトレウェリー族のもとへ遣わす *Itaque [[wikt:en:Titum|T.]] [[wikt:en:Labienus#Latin|Labienum]] legatum in [[wikt:en:Treveri#Latin|Treveros]], qui proximi flumini Rheno sunt, cum equitatu mittit. **こうして、<ruby><rb>[[w:レガトゥス|副官]]</rb><rp>（</rp><rt>レガトゥス</rt><rp>）</rp></ruby>[[w:ティトゥス・ラビエヌス|ティトゥス・ラビエーヌス]]をレーヌス川〔[[w:ライン川|ライン川]]〕に最も近いトレーウェリー族に、騎兵隊とともに派遣する。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:la:Titus Labienus|Titus Labienus]] は、『ガリア戦記』におけるカエサルの片腕。<br>　　　　''[[w:en:Treveri|Treveri]]'' はローマの同盟部族だが、[[ガリア戦記_第5巻|第5巻]]・[[ガリア戦記_第6巻|第6巻]]で挙兵する。）</span> *Huic mandat, **彼に（以下のように）命じる。 *[[wikt:en:Remi#Latin|Remos]] reliquosque [[wikt:en:Belgas|Belgas]] adeat atque in officio contineat **①レーミー族やほかの[[w:ベルガエ|ベルガエ人]]を訪れて、<ruby><rb>忠実さ</rb><rp>（</rp><rt>オッフィキウム</rt><rp>）</rp></ruby>に留めるように、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:en:Remi|Remi]]'' は、ローマの同盟部族で、[[ガリア戦記_第2巻#3節|第2巻3節]]以降で言及された。）</span> *[[wikt:en:Germanos|Germanos]]que, qui auxilio a Gallis arcessiti dicebantur, **②ガッリア人により援兵として呼び寄せられたといわれていた[[w:ゲルマニア|ゲルマーニア]]人が **:<span style="color:#009900;">（訳注：第1巻で言及された[[w:アリオウィストゥス|アリオウィストゥス]]の軍勢のこと。）</span> *si per vim navibus flumen transire conentur, prohibeat. **（彼らが）もし力ずくで船で川を渡ることを試みるならば、防ぐように、と。 <br> ;　　　クラッスス青年をアクィーターニアに派遣する *[[wikt:en:Publium|P.]] [[wikt:en:Crassus#Latin|Crassum]] cum cohortibus legionariis XII(duodecim) et magno numero equitatus in Aquitaniam proficisci iubet, **[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス]]には、軍団の12個<ruby><rb>[[w:コホルス|歩兵大隊]]</rb><rp>（</rp><rt>コホルス</rt><rp>）</rp></ruby>と多数の騎兵隊とともに、[[w:アクィタニア|アクィーターニア]]に出発することを命じる。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:la:Publius Licinius Crassus|Publius Licinius Crassus]]、[[#7節]]から既述。）</span> *ne ex his nationibus auxilia in Galliam mittantur ac tantae nationes coniungantur. **これらの種族から援兵がガッリアに派遣され、これほど多くの諸部族が結託することがないように。 <br> ;　　　副官サビーヌスを3個軍団とともに[[w:アルモリカ|アルモリカ]]北部へ派兵する *[[wikt:en:Quintum#Latin|Q.]] [[wikt:en:Titurius#Latin|Titurium]] Sabinum legatum cum legionibus tribus **副官[[w:クィントゥス・ティトゥリウス・サビヌス|クィーントゥス・ティトゥリウス・サビーヌス]]を3個軍団とともに **:<span style="color:#009900;font-family:Times New Roman;">（訳注：''[[w:en:Quintus Titurius Sabinus|Quintus Titurius Sabinus]]'' は[[ガリア戦記_第2巻#5節|第2巻5節]]から言及されている『ガリア戦記』前半で活躍する副官。）</span> *in [[wikt:en:Unelli#Latin|Unellos]](Venellos), Coriosolităs [[wikt:en:Lexovii#Latin|Lexovios]]que mittit, qui eam manum distinendam curet. **ウネッリー族・コリオソリテース族・レクソウィイー族に派遣して、彼らの手勢を分散させるべく配慮するように。 <br> ;　　　ブルートゥス青年をウェネティー族領へ派兵する *[[wikt:en:Decimus#Latin|D.]] [[wikt:en:Brutum|Brutum]] adulescentem classi Gallicisque navibus, **[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|デキムス・ブルートゥス青年]]に、（ローマの）艦隊とガッリア人の船団を、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[w:la:Decimus Iunius Brutus Albinus|Decimus Iunius Brutus Albinus]] は、カエサルの副官として活躍するが、後に暗殺に加わる。）</span> *quas ex [[wikt:en:Pictones#Latin|Pictonibus]] et [[wikt:en:Santoni#Latin|Santonis]] reliquisque pacatis regionibus convenire iusserat, **──これら（船団）はピクトネース族・サントニー族やほかの平定された地方から集まるように命じていたものであるが、── *praeficit et, cum primum possit, in [[wikt:en:Veneti#Latin|Venetos]] proficisci iubet. **（ブルートゥスに船団を）指揮させて、できるだけ早く[[w:ウェネティ族 (ガリア)|ウェネティー族]]（の領土）に出発することを命じる。 <br> *Ipse eo pedestribus copiis contendit. **（カエサル）自身は、そこへ歩兵の軍勢とともに急ぐ。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===12節=== *<span style="background-color:#ffd;">[[/注解/12節]]　{{進捗|00%|2022-07-09}}</span> '''ウェネティー族の城塞都市の地勢、海洋民の機動性''' <div style="text-align:center"> {| |- |[[画像:Bretagne Finistere PointeduRaz15119.jpg|thumb|right|350px|ウェネティー族の[[w:オッピドゥム|城塞都市]]があった[[w:ブルターニュ半島|ブルターニュ半島]]の突き出た地形]] |} </div> *Erant [[wikt:en:eiusmodi|eiusmodi]] fere situs oppidorum, **（[[w:ウェネティ族 (ガリア)|ウェネティー族]]の）<ruby><rb>[[w:オッピドゥム|城塞都市]]</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の地勢はほぼ以下のようであった。 *ut posita in extremis [[wikt:en:lingula#Latin|lingulis]] [[wikt:en:promunturium#Latin|promunturiis]]que **<ruby><rb>[[w:砂嘴|砂嘴]]</rb><rp>（</rp><rt>リングラ</rt><rp>）</rp></ruby>や[[w:岬|岬]]の先端部に位置しているので、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:lingula#Latin|lingula]] ⇒ [[w:la:Lingua terrae|lingua terrae]] (舌状地) ≒ <ruby><rb>[[w:砂嘴|砂嘴]]</rb><rp>（</rp><rt>さし</rt><rp>）</rp></ruby>(くちばし状の砂地)。）</span> *neque pedibus aditum haberent, cum ex alto se [[wikt:en:aestus#Latin|aestus]] incitavisset, **沖合から<ruby><rb>[[w:潮汐|潮　汐]]</rb><rp>（</rp><rt>アエトゥス</rt><rp>）</rp></ruby>が押し寄せて来たとき<span style="color:#009900;">〔満潮〕</span>に、徒歩での<ruby><rb>接近路</rb><rp>（</rp><rt>アプローチ</rt><rp>）</rp></ruby>を持っていなかった。 *quod bis accidit semper horarum XII(duodenarum) spatio, **というのは<span style="color:#009900;">（満潮が毎日）</span>2度、常に12時間の間隔で起こるためである。 <div style="text-align:center"> {| |- |[[画像:Astronomical tide IJmuiden 21 January 2012.png|thumb|right|600px|ある日（24時間）の'''[[w:潮位|潮位]]'''予測グラフの例（2012年、オランダ北海沿岸のエイマイデン）。<br>満潮や干潮は、約12時間の周期で繰り返されることが多いため、たいてい1日2回ずつ生じる。]] |} </div> *neque navibus, **船で（のアプローチ）もなく、 *quod rursus minuente aestu naves in vadis adflictarentur. **というのは、潮が再び減ると<span style="color:#009900;">〔干潮〕</span>、船団が[[w:浅瀬|浅瀬]]で損傷してしまうためである。 *Ita utraque re oppidorum oppugnatio impediebatur; **このように<span style="color:#009900;">（陸路・海路）</span>どちらの状況においても、<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の攻略は妨げられていた。 <br><br> *ac si quando magnitudine operis forte superati, **あるとき、期せずして<span style="color:#009900;">（ウェネティー族がローマ人の）</span><ruby><rb>構造物</rb><rp>（</rp><rt>オプス</rt><rp>）</rp></ruby>の大きさに圧倒されて、 *extruso mari aggere ac molibus **<span style="color:#009900;">（ローマ人が建造した）</span><ruby><rb>土手</rb><rp>（</rp><rt>アッゲル</rt><rp>）</rp></ruby>や<ruby><rb>[[w:防波堤|防波堤]]</rb><rp>（</rp><rt>モーレース</rt><rp>）</rp></ruby>により海水が押し出され、 *atque his oppidi moenibus adaequatis, **これら<span style="color:#009900;">〔堡塁〕</span>が<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>の城壁と<span style="color:#009900;">（高さにおいて）</span>等しくされ、 *suis fortunis desperare coeperant, **<span style="color:#009900;">（ウェネティー族らが）</span>自分たちの命運に絶望し始めていたとしても、 *magno numero navium adpulso, **船の多数を接岸して、 *cuius rei summam facultatem habebant, **それら〔船〕の供給に最大の備えを持っていたので、 *omnia sua deportabant seque in proxima oppida recipiebant; **自分たちの<ruby><rb>一切合財</rb><rp>（</rp><rt>オムニア</rt><rp>）</rp></ruby>を運び去って、最も近い<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>に撤収していた。 *ibi se rursus isdem opportunitatibus loci defendebant. **そこにおいて再び同じような地の利によって防戦していたのだ。 <br><br> *Haec [[wikt:en:eo#Latin|eo]] facilius magnam partem aestatis faciebant, **以上のことが、夏の大部分を<span style="color:#009900;">（ウェネティー族にとって）</span>より容易にしていた。 *quod nostrae naves [[wikt:en:tempestas#Latin|tempestatibus]] detinebantur, **なぜなら、我が方〔ローマ人〕の船団は嵐により<span style="color:#009900;">（航行を）</span>阻まれており、 *summaque erat **<span style="color:#009900;">（航行することの困難さが）</span>非常に大きかった。 *vasto atque aperto mari, **海は広大で開けており、 *magnis aestibus, **<ruby><rb>潮流</rb><rp>（</rp><rt>アエトゥス</rt><rp>）</rp></ruby>が激しく、 *raris ac prope nullis portibus **港は<ruby><rb>疎</rb><rp>（</rp><rt>まば</rt><rp>）</rp></ruby>らでほとんどないので、 *difficultas navigandi. **航行することの困難さが<span style="color:#009900;">（非常に大きかった）</span>。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===13節=== *<span style="background-color:#ffd;">[[/注解/13節]]　{{進捗|00%|2022-07-10}}</span> '''ウェネティー族の帆船の特徴''' <div style="background-color:#ededed; width:90%; text-align:center"> {| |- | colspan="2" |ウェネティー族の船の再現画（左下に兵士の大きさが示されている） | rowspan="2" style="background-color:#fff;" |&nbsp; | rowspan="2" style="vertical-align:bottom;" |[[画像:Navis longa ja.JPG|thumb|right|350px|古代ローマの軍船（[[w:ガレー船|ガレー船]]）の構成]] |- | style="vertical-align:bottom;" |[[画像:Navire venete.svg|thumb|right|200px|一つの帆をもつ帆船の例]] | style="vertical-align:bottom;" |[[画像:Navire venete 2.svg|thumb|right|200px|二つの帆をもつ帆船の例]] |} </div> *Namque ipsorum naves ad hunc modum factae armataeque erant: **これに対して彼ら<span style="color:#009900;">〔[[w:ウェネティ族 (ガリア)|ウェネティー族]]〕</span>自身の[[w:帆船|船]]は、以下のやり方で建造され、<ruby><rb>[[w:艤装|艤装]]</rb><rp>（</rp><rt>ぎそう</rt><rp>）</rp></ruby>されていた。 ;　竜骨 *[[wikt:en:carina#Latin|carinae]] [[wikt:en:aliquanto|aliquanto]] planiores quam nostrarum navium, **<ruby><rb>[[w:竜骨 (船)|竜　骨]]</rb><rp>（</rp><rt>カリーナ</rt><rp>）</rp></ruby>は、我が方<span style="color:#009900;">〔ローマ人〕</span>の船のものよりも、いくらか平らで、 **:<span style="color:#009900;">（訳注：[[w:竜骨 (船)|竜骨]]は、船底に突き出た背骨部分で、[[w:帆船|帆船]]が風で横滑りしないように造られていた。）</span> *quo facilius vada ac decessum aestus excipere possent; **それによって、より容易に[[w:浅瀬|浅瀬]]&nbsp;や&nbsp;[[w:潮汐|潮]]が退くこと<span style="color:#009900;">〔干潮〕</span>を持ち応えることができた。 ;　船首と船尾 *[[wikt:en:prora#Latin|prorae]] admodum erectae atque item [[wikt:en:puppis|puppes]], **<ruby><rb>[[w:船首|船　首]]</rb><rp>（</rp><rt>プローラ</rt><rp>）</rp></ruby>はまったく直立しており、<ruby><rb>[[w:船尾|船　尾]]</rb><rp>（</rp><rt>プッピス</rt><rp>）</rp></ruby>も同様で、 *ad magnitudinem fluctuum tempestatumque adcommodatae; **<ruby><rb>[[w:波#波浪（風浪とうねり）|波　浪]]</rb><rp>（</rp><rt>フルークトゥス</rt><rp>）</rp></ruby> や <ruby><rb>[[w:嵐|暴風雨]]</rb><rp>（</rp><rt>テンペスタース</rt><rp>）</rp></ruby> の激しさに適応していた。 ;　船体の材質 *naves totae factae ex [[wikt:en:robur#Latin|robore]] ad quamvis vim et contumeliam perferendam; **船は、どんな力や衝撃にも耐えるために、全体として[[w:オーク|オーク材]]で造られていた。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:la:robur|robur]] は ''[[wikt:en:oak#English|oak]]'' と英訳され、[[w:樫#Japanese|樫]]と訳されることが多いが、<br>　　　　「<ruby><rb>[[w:カシ|樫]]</rb><rp>（</rp><rt>カシ</rt><rp>）</rp></ruby>」は常緑樹であり、西洋では落葉樹である「<ruby><rb>[[w:ナラ|楢]]</rb><rp>（</rp><rt>ナラ</rt><rp>）</rp></ruby>」が多い。<br>　　　　　学名 [[w:la:Quercus robur|Quercus robur]] は「[[w:ヨーロッパナラ|ヨーロッパナラ]]」と訳される。）</span> ;　横梁 *[[wikt:en:transtrum#Latin|transtra]] ex pedalibus in altitudinem [[wikt:en:trabs#Latin|trabibus]], confixa [[wikt:en:clavus#Latin|clavis]] [[wikt:en:ferreus#Latin|ferreis]] digiti [[wikt:en:pollex#Latin|pollicis]] crassitudine; **<ruby><rb>横梁(横木)</rb><rp>（</rp><rt>トラーンストルム</rt><rp>）</rp></ruby>は、1ペースの幅の<ruby><rb>材木</rb><rp>（</rp><rt>トラプス</rt><rp>）</rp></ruby>からなり、親指の太さほどの鉄製の[[w:釘|釘]]で固定されていた。 **:<span style="font-family:Times New Roman;color:#009900;">（訳注：1[[ガイウス・ユリウス・カエサルの著作/通貨・計量単位#ペース|ペース]]は約29.6cm。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:transtrum#Latin|transtra]] は、<ruby><rb>[[w:マスト|帆柱]]</rb><rp>（</rp><rt>マスト</rt><rp>）</rp></ruby>（[[wikt:en:malus#Etymology_3_2|malus]]）を船に固定するための<ruby><rb>横梁(横木)</rb><rp>（</rp><rt>クロスビーム</rt><rp>）</rp></ruby>とも考えられる。）</span> ;　錨(いかり)の索具 *[[wikt:en:ancora#Latin|ancorae]] pro [[wikt:en:funis#Latin|funibus]] ferreis catenis revinctae; **<ruby><rb>[[w:錨|錨]]</rb><rp>（</rp><rt>アンコラ</rt><rp>）</rp></ruby>は、<ruby><rb>[[w:ロープ|縄　索]]</rb><rp>（</rp><rt>フーニス</rt><rp>）</rp></ruby>の代わりに鉄製の[[w:鎖|鎖]]でつながれていた。 <div style="background-color:#eee; width:600px; text-align:center"> {| |- | style="vertical-align:bottom;" |[[画像:Nemi 060 museo delle Navi.jpg|thumb|right|180px|[[w:la:Ancora|ancora]] ([[w:錨|錨]])(古代ローマ)]] | style="vertical-align:bottom;" |[[画像:Cordage en chanvre.jpg|thumb|right|150px|[[w:la:Funis|funis]] (綱の[[w:ロープ|ロープ]])]] | style="vertical-align:bottom;" |[[画像:Old chain.jpg|thumb|right|150px|[[w:la:Catena|catena]] ([[w:鎖|鎖]])]] |} </div> <br> ;　帆の材質 *[[wikt:en:pellis#Latin|pelles]] pro [[wikt:en:velum#Latin|velis]] [[wikt:en:aluta#Latin|alutae]]que tenuiter confectae, **<ruby><rb>[[w:帆布|帆　布]]</rb><rp>（</rp><rt>ウェールム</rt><rp>）</rp></ruby>の代わりに<ruby><rb>[[w:毛皮|毛皮]]</rb><rp>（</rp><rt>ペッリス</rt><rp>）</rp></ruby>や、薄く作製された<ruby><rb>なめし皮</rb><rp>（</rp><rt>アルータ</rt><rp>）</rp></ruby>が（用いられた）。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:pellis#Latin|pellis]] は<ruby><rb>鞣</rb><rp>（</rp><rt>なめ</rt><rp>）</rp></ruby>していない生皮、[[wikt:en:aluta#Latin|aluta]] は<ruby><rb>鞣</rb><rp>（</rp><rt>なめ</rt><rp>）</rp></ruby>した[[w:皮革|皮革]] [[wikt:en:corium#Latin|corium]] のこと。）</span> <div style="background-color:#eee; width:600px; text-align:center"> {| |- | style="vertical-align:bottom;" |[[画像:Linen canvas.jpg|thumb|right|150px|<ruby><rb>[[w:リネン|亜麻布]]</rb><rp>（</rp><rt>リネン</rt><rp>）</rp></ruby>の[[w:帆布|帆布]] ]] | style="vertical-align:bottom;" |[[画像:Kissen aus indischem Antilopenfell 2013.jpg|thumb|right|100px|[[w:la:Pellis|pellis]] ([[w:毛皮|毛皮]])]] | style="vertical-align:bottom;" |[[画像:Natural Bridge State Park (30337351644).jpg|thumb|right|200px|aluta ([[w:en:Tanning (leather)|なめし皮]])]] |} </div> *[hae] sive propter inopiam [[wikt:en:linum#Latin|lini]] atque eius usus inscientiam, **[これは] あるいは、<ruby><rb>[[w:アマ (植物)|亜麻]]</rb><rp>（</rp><rt>リーヌム</rt><rp>）</rp></ruby>の不足ゆえや、その利用に無知であるゆえか、 **:<span style="color:#009900;">（訳注：ローマ人には、[[w:リネン|亜麻布 (リネン)]]で帆を作る慣習があった。）</span> *sive eo, quod est magis [[wikt:en:verisimilis#Latin|veri simile]], **あるいは、この方がより真実に近いのだろうが、 *quod tantas tempestates Oceani tantosque impetus ventorum sustineri **<ruby><rb>[[w:オーケアノス|大洋]]〔[[w:大西洋|大西洋]]〕</rb><rp>（</rp><rt>オーケアヌス</rt><rp>）</rp></ruby>のあれほどの嵐や、風のあれほどの激しさに持ち応えること、 *ac tanta onera navium regi **船のあれほどの重さを制御することは、 *[[wikt:en:velum#Latin|velis]] non satis commode posse arbitrabantur. **<ruby><rb>帆　布</rb><rp>（</rp><rt>ウェールム</rt><rp>）</rp></ruby>にとって十分に具合良くできないと、<span style="color:#009900;">（ウェネティー族は）</span>考えていたためであろう。 <br><br> ;　　ウェネティー船団とローマ艦隊の優劣 *Cum his navibus nostrae classi eiusmodi congressus erat, **彼ら<span style="color:#009900;">〔ウェネティー族〕</span>の船団と、我が方<span style="color:#009900;">〔ローマ軍〕</span>の艦隊は、以下のように交戦していた。 *ut una celeritate et pulsu remorum praestaret, **迅速さと<ruby><rb>[[w:櫂|櫂]](かい)</rb><rp>（</rp><rt>レームス</rt><rp>）</rp></ruby>を<ruby><rb>漕</rb><rp>（</rp><rt>こ</rt><rp>）</rp></ruby>ぐのだけは<span style="color:#009900;">（ローマ艦隊が）</span>よりまさっていたのだが、 *reliqua pro loci natura, pro vi tempestatum **そのほかのことは、地勢や嵐の勢いを考慮すると、 *illis essent aptiora et adcommodatiora. **彼ら<span style="color:#009900;">〔ウェネティー族〕</span>にとってより適しており、より好都合であった。 *Neque enim his nostrae rostro nocere poterant **なぜなら、我が方<span style="color:#009900;">〔ローマ艦隊〕</span>の<ruby><rb>[[w:衝角|衝　　角]]</rb><rp>（</rp><rt>ローストルム</rt><rp>）</rp></ruby>によって彼ら<span style="color:#009900;">（の船）</span>に対して損壊することができず、 *── tanta in iis erat firmitudo ──, **──それら<span style="color:#009900;">〔ウェネティー族の船〕</span>においては<span style="color:#009900;">（船体の）</span>それほどの頑丈さがあったのだが── *neque propter altitudinem facile telum adigebatur, **<span style="color:#009900;">（ウェネティー族の船体の）</span>高さのゆえに、飛道具がたやすく投げ込まれなかったし、 *et eadem de causa minus commode <u>[[wikt:en:copula#Latin|copulis]]</u> continebantur. **同じ理由から、あまり都合よく <ruby><rb><u>[[w:鉤縄|鉤縄]]</u></rb><rp>（</rp><rt>かぎなわ</rt><rp>）</rp></ruby> で<span style="color:#009900;">（敵船が）</span>つなぎ止められなかった。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：下線部は、古い写本では [[wikt:en:scopulus#Latin|scopulis]]「岩礁」だが、<br>　　　　後代の写本で修正され「[[w:鉤縄|鉤縄]]」と解釈されている。下図参照。）</span> <div style="background-color:#eee; width:350px; text-align:center"> {| |- | style="vertical-align:bottom;" |[[画像:Grappling hook 2 (PSF).png|thumb|right|410px|[[w:海戦|海戦]]において敵船に[[w:移乗攻撃|接舷]]するために用いられていた、多数の<ruby><rb>[[w:鉤|鉤]]</rb><rp>（</rp><rt>かぎ</rt><rp>）</rp></ruby>を備えた<ruby><rb>[[w:銛|銛]]</rb><rp>（</rp><rt>もり</rt><rp>）</rp></ruby>の一種（<small>英語 [[wikt:en:grappling hook|grappling hook]]</small>）。<hr>[[内乱記_第1巻#57節|『内乱記』第1巻57節]]、[[内乱記_第2巻#6節|第2巻6節]]においても、[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|D.ブルートゥス]]による'''[[内乱記/マッシリアについて|マッシリア攻囲]]'''の海戦の場面で、同様の鉤について言及される。]] |} </div> *Accedebat ut, **さらに加えて、 *cum <span style="color:#009900;">[</span>saevire ventus coepisset et<span style="color:#009900;">]</span> se vento dedissent, **<span style="color:#009900;">[</span>風が荒々しく吹き始めて<span style="color:#009900;">]</span> 風に身を委ねて<span style="color:#009900;">（航行して）</span>いたときに、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：&beta;系写本では [　　] 部分を欠く。）</span> *et tempestatem ferrent facilius **<span style="color:#009900;">（ウェネティー族の船団は）</span>嵐により容易に耐えていたし、 *et in vadis consisterent tutius **浅瀬により安全に停留して、 *et ab aestu relictae **潮に取り残されても、 *nihil saxa et [[wikt:en:cautes#Latin|cautes]] timerent; **岩石やごつごつした石を何ら恐れることがなかった。 *quarum rerum omnium nostris navibus casus erant extimescendi. **それらのすべての事が、我が<span style="color:#009900;">〔ローマ人の〕</span>船団にとっては、恐怖すべき危険であったのだ。 **:<span style="color:#009900;">（訳注：ウェネティー族の船は[[w:竜骨 (船)|竜骨]]がローマ人の船より平たいため、<br>　　　　浅瀬や引き潮を容易に持ち応えられた。本節の冒頭を参照。）</span> <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===14節=== *<span style="background-color:#ffd;">[[/注解/14節]]　{{進捗|00%|2022-07-17}}</span> '''カエサル待望のブルートゥスの艦隊が来航し、ウェネティー族との海戦が始まる''' *Compluribus expugnatis oppidis **いくつもの<span style="color:#009900;">（ウェネティー族の）</span><ruby><rb>[[w:オッピドゥム|城塞都市]]</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>が攻略されると、 *Caesar <u>ubi intellexit</u> frustra tantum laborem sumi **カエサルは、これほどの労苦が徒労になること（を知り）、 *neque hostium fugam captis oppidis reprimi **（すなわち）<ruby><rb>城塞都市</rb><rp>（</rp><rt>オッピドゥム</rt><rp>）</rp></ruby>が占領されても、敵の逃亡が妨げられないし、 *neque iis noceri posse, **彼ら<span style="color:#009900;">〔ウェネティー族〕</span>に損害が与えられることも不可能である<u>と知るや否や</u>、 *statuit exspectandam classem. **[[w:ローマ海軍|艦隊]]<span style="color:#009900;">（の到着）</span>を待つことを決意した。 **:<span style="color:#009900;">（訳注：ローマの軍船がリゲル川〔[[w:ロワール川|ロワール川]]〕で建造されていることが[[#9節|9節]]で述べられた。）</span> <br> ;　　ローマ艦隊が来航すると、約220隻のウェネティー船団が迎え撃とうとする *Quae ubi convenit ac primum ab hostibus visa est, **これら<span style="color:#009900;">〔ローマ艦隊〕</span>が集結して敵方により目撃されるや否や、 *circiter CCXX(ducentae viginti) naves eorum paratissimae **約220隻の彼ら<span style="color:#009900;">〔ウェネティー族〕</span>の船団が準備を整え、 *atque omni genere armorum ornatissimae **あらゆる種類の武器が完備された状態で *ex portu profectae nostris adversae constiterunt; **港から出航して、我が方<span style="color:#009900;">〔ローマ艦隊〕</span>と向かい合って布陣した。 <div style="text-align:center"> {| |- |[[画像:Bataille Morbihan -56.png|thumb|right|600px|[[w:紀元前56年|BC56年]]に現在の[[w:モルビアン県|モルビアン県]]沿いの[[w:キブロン湾|キブロン湾]]で戦われたと考えられている、[[w:ウェネティ族 (ガリア)|ウェネティー族]]と[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|D. ブルートゥス]]率いる艦隊との海戦、いわゆる「[[w:モルビアン湾の海戦|モルビアン湾の海戦]]」の海戦図。<hr>上図の説では、<span style="color:green;">ウェネティー族の帆船(緑色/約220隻)</span>と<span style="color:red;">ブルートゥス率いるローマのガレー船(赤色/約100隻)</span>が[[w:キブロン湾|キブロン湾]]で対峙し、<span style="color:red;">カエサルと1個軍団(赤色)</span>が沿岸を占領している。]] |} </div> *neque satis [[wikt:en:Brutus#Latin|Bruto]], qui classi praeerat, **艦隊を指揮していた[[w:デキムス・ユニウス・ブルトゥス・アルビヌス|ブルートゥス]]には十分（明らか）ではなかった。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：デキムス・ブルートゥス [[w:la:Decimus Iunius Brutus Albinus|Decimus Brutus]] に艦隊を指揮させることが[[#11節|11節]]で述べられた。）</span> *vel tribunis militum centurionibusque, quibus singulae naves erant attributae, **あるいは、個々の船が割り当てられていた <ruby><rb>[[w:トリブヌス・ミリトゥム|兵士長官]]</rb><rp>（</rp><rt>トリブヌス・ミリトゥム</rt><rp>）</rp></ruby> や <ruby><rb>[[w:ケントゥリオ|百人隊長]]</rb><rp>（</rp><rt>ケントゥリオー</rt><rp>）</rp></ruby> にとってさえも、 *constabat quid agerent aut quam rationem pugnae insisterent. **何をすべきなのか、どのような戦法を採るべきなのか、明らかではなかった。 *[[wikt:en:rostrum#Latin|Rostro]] enim noceri non posse cognoverant; **なぜなら、<ruby><rb>[[w:衝角|衝　角]]</rb><rp>（</rp><rt>ローストルム</rt><rp>）</rp></ruby>にとって<span style="color:#009900;">（敵船に）</span>損害を与えることができないことを知っていたからだ。 **:<span style="color:#009900;">（訳注：[[#13節|前節]]で、ウェネティー族の船体が頑丈であるため、と述べられた。）</span> *turribus autem excitatis tamen has altitudo [[wikt:en:puppis#Latin|puppium]] ex barbaris navibus superabat, **他方で、[[w:櫓|櫓]]が築かれたにもかかわらず、蛮族の船の <ruby><rb>[[w:船尾|船尾]]</rb><rp>（</rp><rt>プッピス</rt><rp>）</rp></ruby> の高さがそれら（の高さ）を上回っていた。 **:<span style="color:#009900;">（訳注：ローマの軍船の甲板上には、投槍などの飛道具を投げるために櫓が設けられていた。）</span> *ut neque ex inferiore loco satis commode [[wikt:en:telum#Latin|tela]] adigi possent **その結果、より低い場所から十分に具合良く<span style="color:#009900;">（敵船に）</span><ruby><rb>[[w:飛び道具|飛道具]]</rb><rp>（</rp><rt>テールム</rt><rp>）</rp></ruby>が投げ込まれることは不可能で、 *et missa a Gallis gravius acciderent. **ガッリア人により放られたものがより激しく降ってきていた。 <br> ;　　ローマ艦隊の切り札 *Una erat magno usui res praeparata a nostris, **ただ一つの大いに役立つ物が、我が方<span style="color:#009900;">〔ローマ艦隊〕</span>によって準備されていた。 *[[wikt:en:falx#Latin|falces]] praeacutae insertae adfixaeque [[wikt:en:longurius#Latin|longuriis]], **<span style="color:#009900;">（それは）</span>先の尖った[[w:鎌|鎌]]が <ruby><rb>長い竿</rb><rp>（</rp><rt>ロングリウス</rt><rp>）</rp></ruby> に挿入されて固定されたもので、 *non absimili forma muralium falcium. **<ruby><rb><span style="color:#009900;">(攻城用の)</span>破城の鎌</rb><rp>（</rp><rt>ファルクス・ムーラーリス</rt><rp>）</rp></ruby> に形が似ていなくもない。 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：「破城の鎌」'''[[古代ローマの攻城兵器#falx_muralis_(siege_hook)|falx muralis]]''' に似たもので、'''[[ガイウス・ユリウス・カエサルの著作/古代ローマの攻城兵器#falx_navalis|falx navalis]]''' とも呼ばれている。）</span> <div style="text-align:center"> {| |- |[[画像:Caesar's Gallic war; (Allen and Greenough's ed.) (1898) (14778300381)(cropped).jpg|thumb|right|300px|破城鎌の復元画の例]] |[[画像:Ulysse bateau.jpg|thumb|right|320px|帆柱・帆桁や帆・綱具などが描かれたローマ時代の[[w:モザイク|モザイク画]]<ref>[[w:en:Roman mosaic]]</ref>《[[w:オデュッセウス|オデュッセウス]]と[[w:セイレーン|セイレーン]]》<br>（[[w:チュニス|チュニス]]の[[w:バルド国立博物館|バルド国立博物館]]）]] |} </div> *His cum [[wikt:en:funis#Latin|funes]] qui [[wikt:en:antemna#Latin|antemnas]] ad [[wikt:en:malus#Etymology_3_2|malos]] destinabant, comprehensi adductique erant, **これによって、<ruby><rb>帆　桁</rb><rp>（</rp><rt>アンテムナ</rt><rp>）</rp></ruby> を <ruby><rb>[[w:マスト|帆　柱]]</rb><rp>（</rp><rt>マールス</rt><rp>）</rp></ruby> に縛り付けていた <ruby><rb>綱具</rb><rp>（</rp><rt>フーニス</rt><rp>）</rp></ruby> が補足されて引っ張られた状態で、 *navigio remis incitato praerumpebantur. **<ruby><rb>艦艇</rb><rp>（</rp><rt>ナーウィギウム</rt><rp>）</rp></ruby>が[[w:櫂|櫂]]によってすばやく推進されると、<span style="color:#009900;">（綱具が）</span>引き裂かれていた。 *Quibus abscisis antemnae necessario concidebant, **それら<span style="color:#009900;">〔綱具〕</span>が切断されると、<ruby><rb>帆　桁</rb><rp>（</rp><rt>アンテムナ</rt><rp>）</rp></ruby> は必然的に倒れてしまっていた。 *ut, cum omnis Gallicis navibus spes in velis armamentisque consisteret, **その結果、ガッリア人の船団にとって、すべての期待は帆と索具に依拠していたので、 **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:armamentum#Latin|armamentum]] (英 ''[[wikt:en:rigging#English|rigging]]'')⇒「索具」：[[w:帆|帆]]と[[w:マスト|帆柱]]を支える綱や器具など。）</span> *his ereptis omnis usus navium uno tempore eriperetur. **これらが引き裂かれると、船のすべての運用能力も<ruby><rb>一時</rb><rp>（</rp><rt>いちどき</rt><rp>）</rp></ruby>に奪い取られていた。 *Reliquum erat certamen positum in virtute, **残りの争闘は、武勇いかんに<ruby><rb>懸</rb><rp>（</rp><rt>か</rt><rp>）</rp></ruby>かっており、 *qua nostri milites facile superabant, **その点では我が方<span style="color:#009900;">〔ローマ勢〕</span>の兵士たちが容易に上回っていた。 <br> ;　　沿岸はカエサルとローマ軍によって占領されていた *atque eo magis quod in conspectu Caesaris atque omnis exercitus res gerebatur, **海戦がカエサルと全陸軍の眼前において遂行されていたので、それだけますます **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:classis#Latin|classis]] が艦隊（海軍）を指すのに対して、[[wikt:en:exercitus#Noun|exercitus]] は重装歩兵を主体とする陸軍部隊を指す。）</span> **:<span style="color:#009900;font-family:Times New Roman;">（訳注：[[wikt:en:eo#Etymology_3_2|eo]] [[wikt:en:magis#Latin|magis]] [[wikt:en:quod#Latin|quod]] ～ 「～だけ、ますます」）</span> *ut nullum paulo fortius factum latere posset; **（普通より）より少し勇敢ならどんな行動も知らずにはおかないほどであった。 *omnes enim colles ac loca superiora, unde erat propinquus despectus in mare, ab exercitu tenebantur. **なぜなら、そこから海への眺望が近いところのすべての丘や高地は、<span style="color:#009900;">（ローマ人の）</span>軍隊によって占領されていたのである。 <!-- **:<span style="color:#009900;">（訳注： **:<span style="color:#009900;font-family:Times New Roman;">（訳注： --> ===15節=== '''海戦が終わる''' *Deiectis, ut diximus, antemnis, **上述したように帆桁がぶっ倒れて、 *cum singulas binae ac ternae naves circumsteterant, **（ウェネティー族の船）1艘ずつを（ローマの）2艘ずつや3艘ずつの船が攻囲して、 *milites summa vi transcendere in hostium naves contendebant. **（ローマの）兵士たちは最高の力で敵の船に乗り移ることに努めた。 *Quod postquam barbari fieri animadverterunt, **そのことが行なわれていると蛮族が気づいた後で、 *expugnatis compluribus navibus, **いくつもの（ウェネティー族の）船が攻略されて、 *cum ei rei nullum reperiretur auxilium, **この事態に対して何ら助けを見出せなかったので、 *fuga salutem petere contenderunt. **逃亡に身の安全を求めることに努めた。 *Ac iam conversis in eam partem navibus quo ventus ferebat, **ちょうど風が運んでいた方角へ船の向きを変えたが、 *tanta subito malacia ac tranquillitas exstitit, **突然に大きく[[w:凪|凪]]や静けさが生じて、 *ut se ex loco movere non possent. **（ウェネティー族が）その場所から動くことができないほどであった。 *Quae quidem res ad negotium conficiendum maximae fuit oportunitati: **このような事態はまさに仕事（軍務）を遂行するのに最大の機会であった。 *nam singulas nostri consectati expugnaverunt, **というのも（敵船）1つずつを我が方が追跡して攻略して、 *ut perpaucae ex omni numero noctis interventu ad terram pervenirent, **その結果、総勢のうちから非常にわずかな数の者たちが、夜のとばりに包まれて、陸地に達したのだ。 *cum ab hora fere IIII{quarta}. usque ad solis occasum pugnaretur. **なぜなら（海戦が）ほぼ第四時から日が没するまで絶えず戦われたからだ。 **:（訳注：第四時は、古代ローマの不定時法で、午前9時～10時頃と思われる。） ===16節=== '''ウェネティー族の行末''' *Quo proelio bellum Venetorum totiusque orae maritimae confectum est. **以上の戦闘で、[[w:ウェネティ族 (ガリア)|ウェネティー族]]およびすべての沿岸住民との戦争が完遂された。 *Nam cum omnis iuventus, omnes etiam gravioris aetatis, **なぜなら、すべての青年とすべての年嵩の者さえも、 *in quibus aliquid consilii aut dignitatis fuit eo convenerant, **何らかの見識や品位のあった者たちは、そこ（戦場）へ集まっていたからだ。 *tum navium quod ubique fuerat in unum locum coegerant; **そのとき、至る所にあった船が一つの場所に集められていたのだ。 *quibus amissis reliqui neque quo se reciperent neque quemadmodum oppida defenderent habebant. **以上のものを喪失して、残存者たちは、どこへ退くかも、どんな方法で城市を防衛するかもわからなかった。 *Itaque se suaque omnia Caesari dediderunt. **こうして、彼らとそのすべてのものをカエサルに委ねた（降伏した）。 *In quos eo gravius Caesar vindicandum statuit **これらのものを、カエサルはより厳重に処罰すると決定した。 *quo diligentius in reliquum tempus a barbaris ius legatorum conservaretur. **将来、蛮族により（ローマの）使節の権利をいっそう保たせるように。 *Itaque omni senatu necato reliquos sub corona vendidit. **こうして、すべての長老を殺害して、残りの者たちを奴隷として売却した。 **（訳注：sub corona vendere；葉冠のもとに売る＝奴隷として売る） ==大西洋岸ウネッリ族の造反== ===17節=== [[画像:Campagne Unelles -56.png|thumb|right|200px|ウネッリ族・レクソウィイ族への遠征経路。]] '''ウネッリ族の反乱とサビヌスの作戦''' *Dum haec in Venetis geruntur, **以上のことが[[w:ウェネティ族 (ガリア)|ウェネティー族]]（の領国）で行なわれていた間に、 *Q. Titurius Sabinus cum iis copiis, quas a Caesare acceperat **[[w:クィントゥス・ティトゥリウス・サビヌス|クィントゥス・ティトゥリウス・サビヌス]]は、カエサルから受け取った軍勢とともに *in fines Unellorum{Venellorum} pervenit. **[[w:ウネッリ族|ウネッリ族]]の領土に到着した。 *His praeerat Viridovix ac summam imperii tenebat earum omnium civitatum, quae defecerant, **彼ら（ウネッリ族）を指揮していたのは[[w:ウィリドウィクス|ウィリドウィクス]]で、背反した全部族の最高指揮権を保持していた。 *ex quibus exercitum [magnasque copias] coegerat; **（彼は）これら（の部族）から大軍勢を徴集した。 *atque his paucis diebus Aulerci Eburovices Lexoviique, **それから数日内に、[[w:アウレルキ族|アウレルキ族]]、[[w:エブロウィケス族|エブロウィケス族]]と[[w:レクソウィー族|レクソウィイ族]]は、 *senatu suo interfecto, quod auctores belli esse nolebant, **自分たちの長老たちを、戦争の首謀者になることを欲しなかったという理由で殺害し、 *portas clauserunt seseque cum Viridovice coniunxerunt; **（城市の）門を閉じて、彼らはウィリドウィクスと結託した。 *magnaque praeterea multitudo undique ex Gallia perditorum hominum latronumque convenerat, **そのうえにガリアの至る所から大勢の無頼漢や略奪者が集まっていた。 *quos spes praedandi studiumque bellandi ab agri cultura et cotidiano labore revocabat. **これらの者たちを、略奪への期待と戦争への熱望が、農耕や毎日の仕事から呼び戻したのだ。 *Sabinus idoneo omnibus rebus loco castris se tenebat, **サビヌスはすべての事柄において適切な場所で、陣営を保持した。 *cum Viridovix contra eum duorum milium spatio consedisset **ウィリドウィクスは彼に対抗して2[[w:ローママイル|ローママイル]]（約3km）の間隔で陣取って、 *cotidieque productis copiis pugnandi potestatem faceret, **毎日、軍勢を連れ出して戦闘の機会を作った。 *ut iam non solum hostibus in contemptionem Sabinus veniret, **その結果ついに、敵からサビヌスが軽蔑されるに至ったのみならず、 *sed etiam nostrorum militum vocibus nonnihil carperetur; **我が方（ローマ）の兵士からも若干の者が声に出して嘲弄するに至った。 *tantamque opinionem timoris praebuit, **これほどの恐れの評判を呈したので、 *ut iam ad vallum castrorum hostes accedere auderent. **ついに陣営の堡塁のところにまで敵が敢えて近づいて来るほどであった。 *Id ea de causa faciebat **（サビヌスは）以上のことを以下の理由でしたのである。 *quod cum tanta multitudine hostium, **というのも、このような大がかりな敵とともに、 *praesertim eo absente qui summam imperii teneret, **とりわけ、（ローマ側の）最高指揮権を保持する者（=カエサル）がおらずに、 *nisi aequo loco aut opportunitate aliqua data **有利な場所か何らかの機会が与えられなければ、 *legato dimicandum non existimabat. **総督副官（[[w:レガトゥス|レガトゥス]]）にとって戦うべきとは考えなかったのである。 ===18節=== '''サビヌスの計略''' *Hac confirmata opinione timoris **このような恐れの評判が強められて、 *idoneum quendam hominem et callidum delegit Gallum, **（サビヌスは）適切で明敏なガリア人のある男を選び出した。 *ex iis quos auxilii causa secum habebat. **支援軍（[[w:アウクシリア|アウクシリア]]）のために保持していた者たちの内から。 *Huic magnis praemiis pollicitationibusque persuadet uti ad hostes transeat, **この者を、多大なほうびを約束して、敵側に渡るように説得して、 *et quid fieri velit edocet. **（サビヌスが）なされんと欲することを説き教えた。 *Qui ubi pro perfuga ad eos venit, timorem Romanorum proponit, **その者は、逃亡兵として彼ら（ウネッリ族）のところへ来るや否や、ローマ人の恐れを申し述べた。 *quibus angustiis ipse Caesar a Venetis prematur docet, **いかなる困窮で、カエサル自身が[[w:ウェネティ族 (ガリア)|ウェネティー族]]により苦戦させられているかを教えた。 *neque longius abesse, quin proxima nocte **遠からず、明晩には *Sabinus clam ex castris exercitum educat **サビヌスはひそかに陣営から軍隊を導き出して、 *et ad Caesarem auxilii ferendi causa proficiscatur. **カエサルのところへ支援をもたらすために出発するであろう（とその男は教えた）。 *Quod ubi auditum est, conclamant **このことが聞かれるや否や、（ウネッリ族の者たちは）叫び声を上げて、 *omnes occasionem negotii bene gerendi amittendam non esse: ad castra iri oportere. **うまく仕事をするすべての機会を失うべきではない、（ローマの）陣営へ行かねばならぬ（と叫んだ）。 *Multae res ad hoc consilium Gallos hortabantur: **多くの事柄が、この計画へとガリア人を励ました。 **（それらの事柄とは、以下のことである。） *superiorum dierum Sabini cunctatio, **最近の日々のサビヌスのためらい、 *perfugae confirmatio, **脱走兵の確証、 *inopia cibariorum, cui rei parum diligenter ab iis erat provisum, **彼ら（ガリア人）によって充分に入念に調達されなかった糧食の欠乏、 *spes Venetici belli, **[[w:ウェネティ族 (ガリア)|ウェネティー族]]の戦争への希望、 *et quod fere libenter homines id quod volunt credunt. **というのも、たいてい人間は（自分が）欲することを喜んで信ずるからである。 *His rebus adducti non prius Viridovicem reliquosque duces ex concilio dimittunt, **これらの事態に引かれて、（ウネッリ族は）ウィリドウィクスや他の指導者を会議から解散させなかった。 *quam ab his sit concessum arma uti capiant et ad castra contendant. **彼らによって、武器を取って（ローマ）陣営へ急行するように容認されるまでは。 *Qua re concessa laeti, ut explorata victoria, **この事が容認されて、勝利が得られたかのように喜んで、 *sarmentis virgultisque collectis, quibus fossas Romanorum compleant, ad castra pergunt. **柴や薮を集めて、これでもってローマ人の堀を埋めるべく、（ローマの）陣営のところへ出発した。 ===19節=== '''ウネッリ族らとの決戦''' *Locus erat castrorum editus et paulatim ab imo acclivis circiter passus mille. **ローマ陣営の位置は高く、最も下（麓）から緩やかな上り坂で約1000[[w:パッスス|パッスス]]（約1.5km）のところにあった。 *Huc magno cursu contenderunt, ここへ、大いに駆けて急いで、 *ut quam minimum spatii ad se colligendos armandosque Romanis daretur, **ローマ人にとって集結して武装するための時間ができるだけ与えられないようにして、 *exanimatique pervenerunt. **息を切らして到着した。 *Sabinus suos hortatus cupientibus signum dat. **サビヌスは、自分の部下たちを励まして、はやる者たちに合図を与える。 *Impeditis hostibus propter ea quae ferebant onera, **敵は、彼らが担いでいた重荷のために妨げられていて、 *subito duabus portis eruptionem fieri iubet. **（サビヌスは）突然に（左右の）二つの門から出撃することを命じた。 *Factum est **（ut以下のことが）なされた。 *opportunitate loci, hostium inscientia ac defatigatione, **場所の有利さ、敵の（武具や戦術の）不案内と疲労や、 *virtute militum et superiorum pugnarum exercitatione, **兵士の武勇とかつての戦闘の熟練によって *ut ne primum quidem nostrorum impetum ferrent ac statim terga verterent. **我が方（ローマ）の最初の襲撃さえ持ちこたえることなく、（敵は）すぐに背を向けた。 *Quos impeditos integris viribus milites nostri consecuti **これらの妨げられている者たちを、健全な力で我が方の兵士たちが追跡して、 *magnum numerum eorum occiderunt; **彼らの大多数を殺戮した。 *reliquos equites consectati paucos, qui ex fuga evaserant, reliquerunt. **残りの者たちは、（ローマの）騎兵が追跡したが、逃亡によって逃れたので、見逃した。 *Sic uno tempore et de navali pugna Sabinus et de Sabini victoria Caesar est certior factus, **このようにして一度に、海戦についてサビヌスが、サビヌスの勝利についてカエサルが、報告を受けて、 *civitatesque omnes se statim Titurio dediderunt. **（敵の）全部族がすぐにティトゥリウス（・サビヌス）に降伏した。 *Nam ut ad bella suscipienda Gallorum alacer ac promptus est animus, **こうなったのは、ガリア人は戦争を実行することについては性急で、心は敏捷であるが、 *sic mollis ac minime resistens ad calamitates ferendas mens eorum est. **と同様に柔弱で、災難に耐えるには彼らの心はあまり抵抗しないためである。 ==クラッススのアクィタニア遠征== ===20節=== [[画像:Campagne Aquitains -56.png|thumb|right|200px|クラッススのアウィタニア遠征の経路。]] '''クラッススのアクィタニア遠征、ソティアテス族''' *Eodem fere tempore P. Crassus, cum in Aquitaniam pervenisset, **ほぼ同じ時期に[[w:プブリウス・リキニウス・クラッスス|プブリウス・クラッスス]]が[[w:アクィタニア|アクィタニア]]に達したときに、 *quae pars, ut ante dictum est, et regionum latitudine et multitudine hominum **この方面は、前述のように、領域の広さと人間の多さで *ex tertia parte Galliae est aestimanda, **[[w:ガリア|ガリア]]の第三の部分であると考えられるべきであるが、 *cum intellegeret in illis locis sibi bellum gerendum, **（クラッススは）かの場所で自らにとって戦争がなされるべきであると考えたので、 *ubi paucis ante annis L. Valerius Praeconinus legatus exercitu pulso interfectus esset **そこでほんの数年前に[[w:ルキウス・ウァレリウス・プラエコニヌス|ルキウス・ウァレリウス・プラエコニヌス]]総督副官（[[w:レガトゥス|レガトゥス]]）が軍隊を撃退されて殺害されており、 *atque unde L. Manlius proconsul impedimentis amissis profugisset, **かつここから[[w:ルキウス・マンリウス・トルクァトゥス|ルキウス・マンリウス]]執政官代理（[[w:プロコンスル|プロコンスル]]）が輜重を失って敗走しており、 *non mediocrem sibi diligentiam adhibendam intellegebat. **己にとって尋常ならざる注意深さが適用されるべきだと考えたのだ。 *Itaque re frumentaria provisa, auxiliis equitatuque comparato, **こうして糧食が調達され、支援軍（[[w:アウクシリア|アウクシリア]]）や[[w:騎兵|騎兵隊]]が整備され、 *multis praeterea viris fortibus Tolosa et Carcasone et Narbone, **そのうえ多くの屈強な男たちが、[[w:トロサ|トロサ]]や[[w:カルカソ|カルカソ]]や[[w:ナルボ|ナルボ]]から *－ quae sunt civitates Galliae provinciae finitimae, ex his regionibus－ **＜それらは、この地域に隣接する（ローマの）ガリア属州（[[w:ガリア・ナルボネンシス|ガリア・トランサルピナ]]）の都市であるが、＞ *nominatim evocatis, in Sotiatium fines exercitum introduxit. **名指しで徴集されて、（クラッススは）[[w:ソティアテス族|ソティアテス族]]の領土に軍隊を導き入れた。 *Cuius adventu cognito Sotiates magnis copiis coactis, **彼（クラッスス）の到着を知ると、ソティアテス族は大軍勢を集めて、 *equitatuque, quo plurimum valebant, in itinere agmen nostrum adorti **それにより彼らが大いに力があったところの騎兵隊で、行軍中の我が（ローマの）隊列を襲って、 *primum equestre proelium commiserunt, **はじめに騎兵戦を戦った。 *deinde equitatu suo pulso atque insequentibus nostris **それから、その（敵の）騎兵隊が撃退され、我が方が追跡したが、 *subito pedestres copias, quas in convalle in insidiis conlocaverant, ostenderunt. **突然に歩兵の軍勢　＜[[w:峡谷|峡谷]]の中で[[w:伏兵|伏兵]]として配置していた者たち＞　が現われた。 *Iis nostros disiectos adorti proelium renovarunt. **これらによって追い散らされた我が方（ローマ軍）に襲いかかり、戦いを再び始めた。 ===21節=== '''ソティアテス族の敗勢''' *Pugnatum est diu atque acriter, **長く激しく戦われた。 *cum Sotiates superioribus victoriis freti **というのもソティアテス族は、かつての（ローマ軍に対する）勝利を信頼しており、 *in sua virtute totius Aquitaniae salutem positam putarent, **自分たちの武勇の中に全アクィタニアの安全が立脚していると、みなしていたからだ。 *nostri autem, **我が方（ローマ軍）はそれに対して *quid sine imperatore et sine reliquis legionibus adulescentulo duce efficere possent, **最高司令官（[[w:インペラトル|インペラトル]]）なし、他の[[w:ローマ軍団|軍団]]もなしに、この若造（クラッスス）が指揮官として何をなしうるかが *perspici cuperent; **注視（吟味）されることを欲していたのだ。 *tandem confecti vulneribus hostes terga verterunt. **ついに傷を負って、敵は背を向けた。 *Quorum magno numero interfecto **これらの者の大多数を殺戮し、 *Crassus ex itinere oppidum Sotiatium oppugnare coepit. **クラッススは行軍からただちにソティアテス族の[[w:オッピドゥム|城市]]を攻撃し始めた。 *Quibus fortiter resistentibus vineas turresque egit. **これらの者たちが勇敢に抵抗したので、（ローマ勢は）工作小屋（[[w:ウィネア|ウィネア]]）や[[w:櫓|櫓]]を（城の方に）導いた。 *Illi alias eruptione temptata, alias cuniculis ad aggerem vineasque actis **彼ら（アクィタニア人）は、あるときは突撃を試みて、あるときは[[w:坑道|坑道]]を[[w:土塁|土塁]]や工作小屋のところへ導いた。 *－ cuius rei sunt longe peritissimi Aquitani, **＜こういった事柄（坑道の技術）に、アクィタニア人は長らく非常に熟練している。 *propterea quod multis locis apud eos aerariae secturaeque sunt －, **これは、彼らのもとの多くの場所に[[w:銅山|銅山]]や[[w:採石所|採石所]]があることのためである。＞ *ubi diligentia nostrorum nihil his rebus profici posse intellexerunt, **我が方の注意深さによってこのような事柄によっても何ら得られぬと考えるや否や、 *legatos ad Crassum mittunt, seque in deditionem ut recipiat petunt. **（ソティアテス族は）使節をクラッススのところへ送って、自分たちを降伏へと受け入れるように求める。 *Qua re impetrata arma tradere iussi faciunt. **この事が達せられ、武器の引渡しが命じられ、実行された。 ===22節=== '''アディアトゥアヌスと従僕たちの突撃''' *Atque in ea re omnium nostrorum intentis animis **この事柄に我が方（ローマ勢）の皆が心から没頭しており、 *alia ex parte oppidi Adiatuanus, qui summam imperii tenebat, **城市の他の方面から、最高指揮権を保持していた[[w:アディアトゥアヌス|アディアトゥアヌス]]が *cum DC{sescentis} devotis, quos illi{Galli} soldurios appellant, **ガリア人がソルドゥリイ（従僕）と呼んでいる600名の忠実な者とともに（突撃を試みた）。 '''アディアトゥアヌスの従僕たち''' *－ quorum haec est condicio, **＜　これらの者たちの状況は以下の通りであった。 *uti omnibus in vita commodis una cum iis fruantur quorum se amicitiae dediderint, **人生におけるあらゆる恩恵を、忠心に身を捧げる者たちと一緒に享受する。 *si quid his per vim accidat, aut eundem casum una ferant aut sibi mortem consciscant; **もし彼らに何か暴力沙汰が起こったら、同じ運命に一緒に耐えるか、自らに死を引き受ける（自殺する）。 *neque adhuc hominum memoria repertus est quisquam qui, **これまで、次のような人の記憶は見出されていない。 *eo interfecto, cuius se amicitiae devovisset, mortem recusaret － **忠心に身を捧げる者が殺されても死を拒む（ような者）　＞ *cum his Adiatuanus eruptionem facere conatus **これらの者（従僕）とともにアディアトゥアヌスは突撃することを試みた。 '''アディアトゥアヌスの敗退''' *clamore ab ea parte munitionis sublato **堡塁のその方面から叫び声が上げられて、 *cum ad arma milites concurrissent vehementerque ibi pugnatum esset, **武器のところへ（ローマの）兵士たちが急ぎ集まった後に、そこで激しく戦われた。 *repulsus in oppidum **（アディアトゥアヌスたちは）城市の中に撃退され、 *tamen uti eadem deditionis condicione uteretur a Crasso impetravit. **しかし（前と）同じ降伏条件を用いるように、クラッススを説得した。 ===23節=== '''ウォカテス族・タルサテス族対クラッスス''' *Armis obsidibusque acceptis, Crassus in fines Vocatium et Tarusatium profectus est. **武器と人質を受け取って、クラッススは[[w:ウォカテス族|ウォカテス族]]と[[w:タルサテス族|タルサテス族]]の領土に出発した。 *Tum vero barbari commoti, **そのとき確かに蛮族たちは動揺させられて、 *quod oppidum et natura loci et manu munitum **というのも、地勢と部隊で防備された（ソティアテス族の）城市が *paucis diebus quibus eo ventum erat, expugnatum cognoverant, **（ローマ人が）そこへ来てからわずかな日数で攻め落とされたことを知っていたためであるが、 *legatos quoque versus dimittere, **使節たちをあらゆる方面に向けて送り出し、 *coniurare, obsides inter se dare, copias parare coeperunt. **共謀して、互いに人質を与え合って、軍勢を準備し始めた。 *Mittuntur etiam ad eas civitates legati quae sunt citerioris Hispaniae finitimae Aquitaniae: **アクィタニアに隣接する[[w:上ヒスパニア|上ヒスパニア]]（[[w:en:Hispania Citerior|Hispania Citerior]]）にいる部族たちにさえ、使節が派遣された。 [[画像:Hispania_1a_division_provincial.PNG|thumb|250px|right|BC197年頃のヒスパニア。オレンジ色の地域が当時の上ヒスパニア]] [[画像:Ethnographic Iberia 200 BCE.PNG|thumb|right|250px|BC200年頃のイベリア半島の民族分布。朱色の部分に[[w:アクィタニア人|アクィタニア人]]の諸部族が居住していた。]] *inde auxilia ducesque arcessuntur. **そこから援兵と指揮官が呼び寄せられた。 *Quorum adventu **これらの者が到着して、 *magna cum auctoritate et magna [cum] hominum multitudine **大きな権威と大勢の人間とともに、 *bellum gerere conantur. **戦争遂行を企てた。 *Duces vero ii deliguntur **指揮官には確かに（以下の者たちが）選ばれた。 *qui una cum Q. Sertorio omnes annos fuerant **皆が多年の間、[[w:クィントゥス・セルトリウス|クィントゥス・セルトリウス]]（[[w:la:Quintus Sertorius|Quintus Sertorius]]）と一緒にいて、 *summamque scientiam rei militaris habere existimabantur. **軍事の最高の知識を有すると考えられていた（者たちである）。 **（訳注：セルトリウスは、[[w:ルキウス・コルネリウス・スッラ|スッラ]]の独裁に抵抗したローマ人の武将である。[[w:ヒスパニア|ヒスパニア]]の住民にローマ軍の戦術を教えて共和政ローマに対して反乱を起こしたが、[[w:グナエウス・ポンペイウス|ポンペイウス]]によって鎮圧された。） *Hi consuetudine populi Romani loca capere, **これらの者たちは、ローマ人民の習慣によって、場所を占領し、 *castra munire, **[[w:カストラ|陣営]]を防壁で守り、 *commeatibus nostros intercludere instituunt. **我が方（ローマ勢）の物資をさえぎることに決めたのだ。 *Quod ubi Crassus animadvertit, **クラッススは（以下の諸事情に）気づくや否や、（すなわち） *suas copias propter exiguitatem non facile diduci, **己の軍勢が寡兵であるために、展開するのが容易でないこと、 *hostem et vagari et vias obsidere et castris satis praesidii relinquere, **敵はうろつき回って道を遮断して、陣営に十分な守備兵を残していること、 *ob eam causam minus commode frumentum commeatumque sibi supportari, **その理由のために糧食や軍需品を都合良く自陣に持ち運べていないこと、 *in dies hostium numerum augeri, **日々に敵の数が増していること、（これらの諸事情に気づいたので） *non cunctandum existimavit quin pugna decertaret. **（クラッススは）戦闘で雌雄を決することをためらうべきではないと考えたのだ。 *Hac re ad consilium delata, ubi omnes idem sentire intellexit, **この事が会議に報告されて、皆が同じく考えていることを知るや否や、 *posterum diem pugnae constituit. **戦闘を翌日に決めた。 ===24節=== '''両軍の開戦準備''' *Prima luce productis omnibus copiis, **（クラッススは）夜明けに全軍勢を連れ出して、 *duplici acie instituta, **二重の戦列を整列し、 *auxiliis in mediam aciem coniectis, **支援軍（[[w:アウクシリア|アウクシリア]]）を戦列の中央部に集結し、 *quid hostes consilii caperent exspectabat. **敵がいかなる計略をとるのかを待った。 *Illi, **彼ら（アクィタニア人）は、 *etsi propter multitudinem et veterem belli gloriam paucitatemque nostrorum se tuto dimicaturos existimabant, **（自らの）多勢、昔の戦争の名誉、我が方（ローマ勢）の寡勢のために、安全に闘えると考えたにも拘らず、 *tamen tutius esse arbitrabantur obsessis viis commeatu intercluso sine ullo vulnere victoria potiri, **それでもより安全と思われるのは、道を包囲して[[w:兵站|兵站]]を遮断し、何ら傷なしに勝利をものにすることであり、 *et si propter inopiam rei frumentariae Romani se recipere coepissent, **もし糧食の欠乏のためにローマ人が退却し始めたならば、 *impeditos in agmine et sub sarcinis infirmiores **（ローマ人が）隊列において[[w:背嚢|背嚢]]を背負って妨げられて臆病になっているところを、 *aequo animo adoriri cogitabant. **平常心をもって襲いかかれると考えたのだ。 *Hoc consilio probato ab ducibus, productis Romanorum copiis, sese castris tenebant. **この計略が指揮官により承認されて、ローマ人の軍勢が進撃しても、彼らは陣営に留まった。 *Hac re perspecta Crassus, **この事を見通してクラッススは、 *cum sua cunctatione atque opinione timidiores hostes **（敵）自身のためらいや、評判より臆病な敵が *nostros milites alacriores ad pugnandum effecissent **我が方（ローマ）の兵士たちを戦うことにおいてやる気にさせたので、 *atque omnium voces audirentur exspectari diutius non oportere quin ad castra iretur, **かつ（敵の）陣営へ向かうことをこれ以上待つべきではないという皆の声が聞かれたので、 *cohortatus suos omnibus cupientibus ad hostium castra contendit. **部下を励まして、（戦いを）欲する皆で、敵の陣営へ急行した。 ===25節=== '''クラッスス、敵陣へ攻めかかる''' *Ibi cum alii fossas complerent, alii multis telis coniectis **そこで、ある者は堀を埋め、ある者は多くの飛道具を投げて、 *defensores vallo munitionibusque depellerent, **守備兵たちを[[w:防柵|防柵]]や[[w:防壁|防壁]]から駆逐した。 *auxiliaresque, quibus ad pugnam non multum Crassus confidebat, **[[w:アウクシリア|支援軍]]の者たちといえば、クラッススは彼らの戦いを大して信頼していなかったが、 *lapidibus telisque subministrandis et ad aggerem caespitibus comportandis **石や飛道具を供給したり、[[w:土塁|土塁]]のために[[w:芝|芝草]]を運んだり、 *speciem atque opinionem pugnantium praeberent, **戦っている様子や印象を示した。 *cum item ab hostibus constanter ac non timide pugnaretur **敵もまたしっかりと臆せずに戦って、 *telaque ex loco superiore missa non frustra acciderent, **より高い所から放られた飛道具は無駄なく落ちてきたので、 *equites circumitis hostium castris Crasso renuntiaverunt **[[w:騎兵|騎兵]]は、敵の陣営を巡察してクラッススに報告した。 *non eadem esse diligentia ab decumana porta castra munita **（敵の）陣営の後門（porta decumana）は（他の部分と）同じほどの入念さで防備されておらず、 *facilemque aditum habere. **容易に接近できると。 ===26節=== '''クラッスス、総攻撃をかける''' *Crassus equitum praefectos cohortatus, **クラッススは[[w:騎兵|騎兵]]の指揮官たちに促した。 *ut magnis praemiis pollicitationibusque suos excitarent, quid fieri velit ostendit. **大きな恩賞の約束で部下たちを駆り立てて、何がなされることを欲しているかを示すようにと。 *Illi, ut erat imperatum, **この者らは命じられたように、 *eductis iis cohortibus quae praesidio castris relictae intritae ab labore erant, **守備兵として陣営に残されていて、働きによって疲弊していなかった歩兵大隊（[[w:コホルス|コホルス]]）を連れ出して、 *et longiore itinere circumductis, ne ex hostium castris conspici possent, **敵の陣営から視認できないように、遠回りの道程をめぐらせて、 *omnium oculis mentibusque ad pugnam intentis **（彼我の）皆の目と意識が戦闘に没頭している間に *celeriter ad eas quas diximus munitiones pervenerunt atque his prorutis **速やかに前述した（後門の）防壁に至って、それを崩壊させて、 *prius in hostium castris constiterunt, **敵の陣営に拠点を築いた。 *quam plane ab his videri aut quid rei gereretur cognosci posset. **彼ら（敵）によりまったく見られ、あるいはいかなる事が遂行されているかを知られるよりも早くのことだった。 *Tum vero clamore ab ea parte audito **そのときまさにこの方面から雄叫びが聞こえて、 *nostri redintegratis viribus, **我が方（ローマ勢）は活力を回復し、 *quod plerumque in spe victoriae accidere consuevit, **勝利の希望の中にたいてい起こるのが常であったように *acrius impugnare coeperunt. **より激烈に攻め立て始めたのであった。 *Hostes undique circumventi desperatis omnibus rebus **敵は至る所から攻囲されて、すべての事態に絶望し、 *se per munitiones deicere et fuga salutem petere intenderunt. **壁を越えて飛び降りて、逃亡によって身の安全を求めることに懸命になった。 *Quos equitatus apertissimis campis consectatus **この者たちを（ローマの）騎兵隊が非常に開けた平原で追撃し、 *ex milium L{quinquaginta} numero, quae ex Aquitania Cantabrisque convenisse constabat, **[[w:アクィタニア|アクィタニア]]と[[w:カンタブリ族|カンタブリ族]]（[[w:en:Cantabri|Cantabri]]）から集まっていた（敵の総勢の）数は5万名が確認されたが、 *vix quarta parte relicta, **やっとその四分の一が生き残り、 *multa nocte se in castra recepit. **夜も更けて（ローマ勢は）陣営に退却した。 ===27節=== '''アクィタニア諸部族の降伏''' *Hac audita pugna **この戦闘（の勝敗）を聞いて、 *maxima pars Aquitaniae sese Crasso dedidit obsidesque ultro misit; **[[w:アクィタニア人|アクィタニア人]]の大部分がクラッススに降伏して、すすんで[[w:人質|人質]]を送った。 *quo in numero fuerunt **その数の中には以下の部族がいた。 *Tarbelli, Bigerriones, Ptianii, Vocates, Tarusates, Elusates, **[[w:タルベッリ族|タルベッリ族]]、[[w:ビゲッリオネス族|ビゲッリオネス族]]、[[w:プティアニー族|プティアニイ族]]、[[w:ウォカテス族|ウォカテス族]]、[[w:タルサテス族|タルサテス族]]、[[w:エルサテス族|エルサテス族]]、 *Gates, Ausci, Garunni, Sibulates, Cocosates: **[[w:ガテス族|ガテス族]]、[[w:アウスキ族|アウスキ族]]、[[w:ガルンニ族|ガルンニ族]]、[[w:シブラテス族|シブラテス族]]、[[w:ココサテス族|ココサテス族]]、である。 *paucae ultimae nationes **わずかな遠方の部族たちは、 *anni tempore confisae, quod hiems suberat, **時季を頼りにして、というのも冬が近づいていたためであるが、 *id facere neglexerunt. **そのこと（降伏と人質）をなおざりにした。 ==モリニ族・メナピイ族への遠征== ===28節=== '''カエサル、モリニ族・メナピイ族へ遠征''' *Eodem fere tempore Caesar, **（前節までに述べたクラッススのアクィタニア遠征と）ほぼ同じ時期にカエサルは、 *etsi prope exacta iam aestas erat, **すでに夏はほとんど過ぎ去っていたのであるが、 *tamen quod omni Gallia pacata **全ガリアが平定されていたにもかかわらず、 *Morini Menapiique supererant, **[[w:モリニ族|モリニ族]]と[[w:メナピー族|メナピイ族]]は生き残って *qui in armis essent, neque ad eum umquam legatos de pace misissent, **武装した状態で、彼（カエサル）のところへ決して和平の使節を派遣しようとしなかったので、 *arbitratus id bellum celeriter confici posse, eo exercitum duxit; **この戦争は速やかに完遂されると思って、そこへ軍隊を率いて行った。 *qui longe alia ratione ac reliqui Galli bellum gerere instituerunt. **これら（の部族）は、他のガリア人とはまったく別の方法で戦争遂行することを決めた。 *Nam **なぜなら *quod intellegebant maximas nationes, quae proelio contendissent, pulsas superatasque esse, **というのも、戦闘を戦った非常に多くの部族が撃退され、征服されていることを（彼らは）知っており、 *continentesque silvas ac paludes habebant, **かつ、絶え間ない[[w:森林|森]]と[[w:沼地|沼地]]を（彼らは）持っていたので *eo se suaque omnia contulerunt. **そこへ自分たちとそのすべての物を運び集めたのだ。 *Ad quarum initium silvarum cum Caesar pervenisset castraque munire instituisset **かかる森の入口のところへカエサルが到着して陣営の防備にとりかかったときに、 *neque hostis interim visus esset, **敵はその間に現れることはなく、 *dispersis in opere nostris **工事において分散されている我が方（ローマ勢）を *subito ex omnibus partibus silvae evolaverunt et in nostros impetum fecerunt. **突然に（敵が）森のあらゆる方面から飛び出してきて、我が方に襲撃をしかけたのだ。 *Nostri celeriter arma ceperunt **我が方は速やかに武器を取って *eosque in silvas reppulerunt et compluribus interfectis **彼らを森の中に押し戻して、かなり（の敵）を殺傷して *longius impeditioribus locis secuti **非常に通りにくい場所を追跡したが、 *paucos ex suis deperdiderunt. **我が方の部下で損傷を負ったのは少数であった。 ===29節=== '''カエサル、むなしく撤兵する''' *Reliquis deinceps diebus Caesar silvas caedere instituit, **続いて（冬が近づくまでの）残りの何日かで、カエサルは森を[[w:伐採|伐採]]することに決めた。 *et ne quis inermibus imprudentibusque militibus ab latere impetus fieri posset, **（これは）非武装で不注意な兵士たちが側面からいかなる襲撃もなされないように（ということであり）、 *omnem eam materiam quae erat caesa conversam ad hostem conlocabat **伐採されたすべての[[w:木材|材木]]を敵の方へ向きを変えて配置して、 *et pro vallo ad utrumque latus exstruebat. **[[w:防柵|防柵]]の代わりに両方の側面に築いた。 *Incredibili celeritate magno spatio paucis diebus confecto, **信じがたいほどの迅速さで大きな空間がわずかな日数で完遂されて、 *cum iam pecus atque extrema impedimenta a nostris tenerentur, **すでに[[w:家畜|家畜]]や[[w:輜重|輜重]]の最も端が我が方（ローマ軍）により捕捉された。 *ipsi densiores silvas peterent, **（敵）自身は密生した森を行くし、 *eiusmodi sunt tempestates consecutae, uti opus necessario intermitteretur **[[w:嵐|嵐]]が続いたので、工事はやむを得ずに中断された。 *et continuatione imbrium diutius sub pellibus milites contineri non possent. **雨が続いて、これ以上は皮（[[w:天幕|天幕]]）の下に兵士たちを留めることはできなかった。 *Itaque vastatis omnibus eorum agris, vicis aedificiisque incensis, **こうして、彼らのすべての畑を荒らして、村々や建物に火をつけて、 *Caesar exercitum reduxit **カエサルは軍隊を連れ戻して、 *et in Aulercis Lexoviisque, reliquis item civitatibus quae proxime bellum fecerant, **[[w:アウレルキ族|アウレルキ族]]と[[w:レクソウィー族|レクソウィイ族]]や、他の同様に最近に戦争をしていた部族たちのところに *in hibernis conlocavit. **[[w:冬営|冬営]]を設置した。 ---- *<span style="background-color:#99ff99;">「ガリア戦記 第3巻」了。「[[ガリア戦記 第4巻]]」へ続く。</span> ==脚注== <references /> [[Category:ガリア戦記 第3巻|*]] 3709rgidaiomtkxgg2mr4hcud3ms18k 0 6837 206052 204718 2022-07-31T12:22:52Z Linguae 449 /* 第3巻 */ 14節 wikitext text/x-wiki [[Category:ガリア戦記|もくし]] ガリア戦記の章・節の概略を記した目次 {| id="toc" style="align:left;clear:all;" align="left" cellpadding="5" ! style="background:#ccccff; text-align:left;" | ガリア戦記 内容目次 |- | style="text-align:left; font-size: 0.86em;"| [[#第1巻|第1巻]] | [[#第2巻|第2巻]] | [[#第3巻|第3巻]] | [[#第4巻|第4巻]] | [[#第5巻|第5巻]] | [[#第6巻|第6巻]] | [[#第7巻|第7巻]] | [[#第8巻|第8巻]] |} <br style="clear:both;" /> __notoc__ == [[ガリア戦記 第1巻|第1巻]] == *<span style="background-color:#ddd;">[[ガリア戦記 第1巻]]　；　[[ガリア戦記 第1巻/注解]]</span> '''[[w:ヘルウェティイ族|ヘルウェティイ族]]との戦役、[[w:アリオウィストゥス|アリオウィストゥス]]率いる[[w:ゲルマニア|ゲルマニア]]人との戦役。''' == 第2巻 == *<span style="background-color:#ddd;">[[ガリア戦記 第2巻]]　；　[[ガリア戦記 第2巻/注解]]</span> ;[[w:ベルガエ人|ベルガエ人]]との戦役、大西洋岸の征服 *ベルガエ人同盟との戦役 **[[ガリア戦記 第2巻#1節|01節]]　　ベルガエ諸部族のローマに対抗する共謀とその理由<!--（[[w:ティトゥス・ラビエヌス|ラビエヌス]]の報告）--> **[[ガリア戦記 第2巻#2節|02節]]　　カエサルが新たに2個軍団を徴募させ、初夏にベルガエへ向かう **[[ガリア戦記 第2巻#3節|03節]]　　レーミー族使節が、カエサルに帰順を表明し、支援を約束する **[[ガリア戦記 第2巻#4節|04節]]　　レーミー族使節が、ベルガエ人の出自や兵力について教える **[[ガリア戦記 第2巻#5節|05節]]　　カエサルがハエドゥイー族のディーウィキアークスにベッロウァキー族領の劫掠を命じ、<br>　　　　　さらに[[w:エーヌ川|アクソナ川]]のたもとに背水の陣を敷く **[[ガリア戦記 第2巻#6節|06節]]　　レーミー族の城塞都市ビブラクスを、進軍して来たベルガエ勢が攻囲し始める **[[ガリア戦記 第2巻#7節|07節]]　　カエサルがビブラクスの救援に分遣隊を派兵するが、<br>　　　　　ベルガエ勢はカエサルの前に野営する **[[ガリア戦記 第2巻#8節|08節]]　　カエサルが騎兵戦の小競り合いでベルガエ勢の強さを探り、陣営の防備を固めて主力を布陣させる **[[ガリア戦記 第2巻#9節|09節]]　　ベルガエ勢の別動隊が、ローマ軍の背後の糧道を断とうとして[[w:エーヌ川|アクソナ]]渡河をめざす **[[ガリア戦記 第2巻#10節|10節]]　　[[w:アクソナ川の戦い|アクソナ川の戦い]]：ローマ軍の同盟部隊に別動隊を破られ、ベルガエ勢が本土決戦を期す **[[ガリア戦記 第2巻#11節|11節]]　　ベルガエ勢の撤退戦：夜通し退却するが、朝から追撃を始めたローマ軍に大勢が打ち取られる **[[ガリア戦記 第2巻#12節|12節]]　　カエサルがスエッスィオーネース族の城塞都市ノウィオドゥーヌムを攻め、和議を請われる **[[ガリア戦記 第2巻#13節|13節]]　　スエッスィオーネース族の降伏を受け入れる。続いてベッロウァキー族も和議を請い始める **[[ガリア戦記 第2巻#14節|14節]]　　ハエドゥイー族のディーウィキアークスが、ベッロウァキー族を弁護 {{Wikipedia|サビス川の戦い|サビス川の戦い}} *ネルウィイー族らとの戦役（サビス川の戦い） **[[ガリア戦記 第2巻#15節|15節]]　　ベッロウァキー族、アンビアーニー族の降伏。[[w:ネルウィイ族|ネルウィイー族]]情報 **[[ガリア戦記 第2巻#16節|16節]]　　ネルウィイー族らがサビス川岸でカエサルの軍隊を待ち伏せる **[[ガリア戦記 第2巻#17節|17節]]　　ネルウィイー族が、諜者を通じてローマ軍の内情を調べ、作戦を練る **[[ガリア戦記 第2巻#18節|18節]]　　サビス川を挟んで対峙する両軍の陣営の地形 **[[ガリア戦記 第2巻#19節|19節]]　　ネルウィイー族らベルガエ勢が、森から出て、全軍を挙げてローマ軍へ殺到（[[w:サビス川の戦い|サビス川の戦い]]） **[[ガリア戦記 第2巻#20節|20節]]　　急襲されたローマ軍は危機的な状況に陥るが、鍛錬された将兵が規律を示す **[[ガリア戦記 第2巻#21節|21節]]　　カエサルが第10軍団を鼓舞。切迫した状況で兵士たちが軍旗のもとに集まる **[[ガリア戦記 第2巻#22節|22節]]　　ローマ勢が、不利な戦況において臨機応変に対処することを強いられる **[[ガリア戦記 第2巻#23節|23節]]　　ローマ勢が左翼・中央で優勢になるが、ボドゥオーグナートゥス麾下ネルウィイー族がローマ陣営を目指して猛攻をかける **[[ガリア戦記 第2巻#24節|24節]]　　ネルウィイー勢の突入によってローマ方の陣営が大混乱に陥り、騎兵・軽装兵・軍属奴隷たちが四散する **[[ガリア戦記 第2巻#25節|25節]]　　苦戦する右翼の第12軍団の将兵が、カエサルの激励に応えて敵勢の猛攻に耐える **[[ガリア戦記 第2巻#26節|26節]]　　ローマ勢右翼の第7軍団が頑強に敵に抵抗し、3個軍団が増援に向かう **[[ガリア戦記 第2巻#27節|27節]]　　戦場の潮目が変わって、ローマ勢の士気が高揚するが、ネルウィイー勢も奮戦する **[[ガリア戦記 第2巻#28節|28節]]　　ネルウィイー族の降伏 *アトゥアトゥキー族との戦役 **[[ガリア戦記 第2巻#29節|29節]]　　アトゥアトゥキー族の籠城；その出自とキンブリー・テウトニー戦争の顛末 **[[ガリア戦記 第2巻#30節|30節]]　　ローマ軍に城塞都市を包囲されたアトゥアトゥキー族が、大声で野次を飛ばす **[[ガリア戦記 第2巻#31節|31節]]　　アトゥアトゥキー族の講和条件 **[[ガリア戦記 第2巻#32節|32節]]　　アトゥアトゥキー族がカエサルの通告を受け入れて、城門を開く **[[ガリア戦記 第2巻#33節|33節]]　　アトゥアトゥキー族の夜襲と結末 *ガリア平定とカエサルの凱旋 **[[ガリア戦記 第2巻#34節|34節]]　　[[w:プブリウス・リキニウス・クラッスス|プーブリウス・クラッスス]]が大西洋岸諸部族（[[w:アルモリカ|アルモリカエ]]）を帰服させる **[[ガリア戦記 第2巻#35節|35節]]　　カエサルの属州帰還と軍団の冬営；前例のない感謝祭 == [[ガリア戦記 第3巻|第3巻]] == *<span style="background-color:#ddd;">[[ガリア戦記 第3巻]]　；　[[ガリア戦記 第3巻/注解]]</span> '''[[w:アルプス山脈|アルプス]]での戦い、大西洋岸およびアクィーターニアの平定''' *アルプス・オクトードゥールスの戦い **[[ガリア戦記 第3巻#1節|01節]]　　[[w:セルウィウス・スルピキウス・ガルバ (紀元前54年法務官)|ガルバ]]とローマ第12軍団が、ロダヌス川渓谷のオクトードゥールスにて冬営する **[[ガリア戦記 第3巻#2節|02節]]　　ガッリア人が再び挙兵して周囲の高峰を押さえ、第12軍団の冬営地を包囲 **[[ガリア戦記 第3巻#3節|03節]]　　ガルバが軍議を召集し、策を募る **[[ガリア戦記 第3巻#4節|04節]]　　ガッリア勢がガルバの陣営を急襲し、寡兵のローマ勢は劣勢に陥る **[[ガリア戦記 第3巻#5節|05節]]　　最後の土壇場で説得されたガルバが、疲労回復後の突撃に命運を賭ける **[[ガリア戦記 第3巻#6節|06節]]　　第12軍団がガッリア勢を破るが、ガルバはオクトードゥールスでの冬営を断念する *大西洋岸[[w:ウェネティ族 (ガリア)|ウェネティー族]]の造反 **[[ガリア戦記 第3巻#7節|07節]]　　新たな戦争の勃発 **[[ガリア戦記 第3巻#8節|08節]]　　ウェネティー族らの動き **[[ガリア戦記 第3巻#9節|09節]]　　カエサル到着、ウェネティー族らの作戦と開戦準備 **[[ガリア戦記 第3巻#10節|10節]]　　カエサルの開戦への大義名分 **[[ガリア戦記 第3巻#11節|11節]]　　ラビエーヌス、クラッスス、サビーヌス、ブルートゥスを前線へ派兵する **[[ガリア戦記 第3巻#12節|12節]]　　ウェネティー族の城塞都市の地勢、海洋民の機動性 **[[ガリア戦記 第3巻#13節|13節]]　　ウェネティー族の帆船の特徴 **[[ガリア戦記 第3巻#14節|14節]]　　カエサル待望のブルートゥスの艦隊が来航し、ウェネティー族との海戦が始まる **[[ガリア戦記 第3巻#15節|15節]]　　海戦が終わる **[[ガリア戦記 第3巻#16節|16節]]　　ウェネティー族の行末 *大西洋岸ウネッリ族の造反 **[[ガリア戦記 第3巻#17節|17節]]　　ウネッリ族の反乱と[[w:クィントゥス・ティトゥリウス・サビヌス|サビーヌス]]の作戦 **[[ガリア戦記 第3巻#18節|18節]]　　サビーヌスの計略 **[[ガリア戦記 第3巻#19節|19節]]　　ウネッリ族らとの決戦 *[[w:プブリウス・リキニウス・クラッスス|クラッスス]]の[[w:ガリア・アクィタニア|アクィーターニア]]遠征 **[[ガリア戦記 第3巻#20節|20節]]　　クラッススのアクィーターニア遠征、ソティアテス族 **[[ガリア戦記 第3巻#21節|21節]]　　ソティアテス族の敗勢 **[[ガリア戦記 第3巻#22節|22節]]　　アディアトゥアヌスと従僕たちの突撃 **[[ガリア戦記 第3巻#23節|23節]]　　ウォカテス族・タルサテス族対クラッスス **[[ガリア戦記 第3巻#24節|24節]]　　両軍の開戦準備 **[[ガリア戦記 第3巻#25節|25節]]　　クラッスス、敵陣へ攻めかかる **[[ガリア戦記 第3巻#26節|26節]]　　クラッスス、総攻撃をかける **[[ガリア戦記 第3巻#27節|27節]]　　アクィーターニア諸部族の降伏 *モリニー族・メナピイー族への遠征 **[[ガリア戦記 第3巻#28節|28節]]　　カエサル、モリニ族・メナピイー族へ遠征 **[[ガリア戦記 第3巻#29節|29節]]　　カエサル、むなしく撤兵する == [[ガリア戦記 第4巻|第4巻]] == '''ゲルマニア人との戦役、ゲルマニアおよびブリタンニアへの遠征''' *[[w:ゲルマニア|ゲルマニア]]人との戦役 **[[ガリア戦記 第4巻#1節|01節]]　　[[w:ゲルマニア|ゲルマニア]]情勢、[[w:スエビ族|スエビ族]]について(1) **[[ガリア戦記 第4巻#2節|02節]]　　スエビ族について(2) **[[ガリア戦記 第4巻#3節|03節]]　　スエビ族(3)、[[w:ウビー族|ウビイ族]]について **[[ガリア戦記 第4巻#4節|04節]]　　ゲルマニア人が[[w:メナピー族|メナピイ族]]を襲撃 **[[ガリア戦記 第4巻#5節|05節]]　　カエサルのガリア人観 **[[ガリア戦記 第4巻#6節|06節]]　　ガリア人とカエサルの動き **[[ガリア戦記 第4巻#7節|07節]]　　ゲルマニア人の使節 **[[ガリア戦記 第4巻#8節|08節]]　　カエサルの返答 **[[ガリア戦記 第4巻#9節|09節]]　　カエサルの判断 **[[ガリア戦記 第4巻#10節|10節]]　　モサ川・レヌス川流域の地理 **[[ガリア戦記 第4巻#11節|11節]]　　ゲルマニア人とカエサルの駆け引き **[[ガリア戦記 第4巻#12節|12節]]　　ゲルマニア騎兵の奇襲、ピソの討死 **[[ガリア戦記 第4巻#13節|13節]]　　カエサルの反省と決断 **[[ガリア戦記 第4巻#14節|14節]]　　ローマ軍の急襲 **[[ガリア戦記 第4巻#15節|15節]]　　対ゲルマニア人戦役の帰趨 [[画像:Il_ponte_di_Cesare_sul_Reno.jpg |right|thumb|280 px|レヌス川に架けた橋を渡るローマ軍の想像画。]] [[画像:The_Standard-Bearer_of_the_Tenth_Legion.jpg|thumb|250px|right|ローマ軍の上陸を鼓舞する鷲の徽章の旗手（想像画）]] *第1次[[w:ゲルマニア|ゲルマニア]]遠征 **[[ガリア戦記 第4巻#16節|16節]]　　レヌス渡河の理由、スガンブリ族、ウビイ族 **[[ガリア戦記 第4巻#17節|17節]]　　レヌス川の架橋工事 **[[ガリア戦記 第4巻#18節|18節]]　　レヌス渡河、スガンブリ族の退却 **[[ガリア戦記 第4巻#19節|19節]]　　カエサル、ゲルマニアから撤退する *第1次[[w:ブリタンニア|ブリタンニア]]遠征 **[[ガリア戦記 第4巻#20節|20節]]　　ブリタンニア遠征の理由と無知識 **[[ガリア戦記 第4巻#21節|21節]]　　ブリタンニア遠征の準備、ウォルセヌスとコンミウスの先遣 **[[ガリア戦記 第4巻#22節|22節]]　　モリニ族の帰服、船団の手配 **[[ガリア戦記 第4巻#23節|23節]]　　ブリタンニアへ渡海 **[[ガリア戦記 第4巻#24節|24節]]　　[[w:ブリトン|ブリタンニア人]]が上陸を阻む **[[ガリア戦記 第4巻#25節|25節]]　　軍船と鷲の徽章の旗手 **[[ガリア戦記 第4巻#26節|26節]]　　ローマ勢、苦戦からの強襲上陸 **[[ガリア戦記 第4巻#27節|27節]]　　ブリタンニア人の帰服 **[[ガリア戦記 第4巻#28節|28節]]　　嵐に遭う船団 **[[ガリア戦記 第4巻#29節|29節]]　　ローマ船団の大破 **[[ガリア戦記 第4巻#30節|30節]]　　ブリタンニア人の心変わり **[[ガリア戦記 第4巻#31節|31節]]　　カエサルの応急措置 **[[ガリア戦記 第4巻#32節|32節]]　　包囲されたローマ軍団 **[[ガリア戦記 第4巻#33節|33節]]　　ブリタンニア人の戦術 **[[ガリア戦記 第4巻#34節|34節]]　　カエサルの来援と撤収、ブリタンニア勢の集結 **[[ガリア戦記 第4巻#35節|35節]]　　ブリタンニア勢を撃退 **[[ガリア戦記 第4巻#36節|36節]]　　講和と大陸への帰着 *[[w:モリニ族|モリニ族]]・[[w:メナピー族|メナピイ族]]への第2次遠征 **[[ガリア戦記 第4巻#37節|37節]]　　モリニ族の裏切りと敗北 **[[ガリア戦記 第4巻#38節|38節]]　　モリニ族の降伏、メナピイ族への遠征 == [[ガリア戦記 第5巻|第5巻]] == '''第2次ブリタンニア遠征、ベルガエ人やトレウェリ族の蜂起''' *[[w:ブリタンニア|ブリタンニア]]再遠征の準備 **[[ガリア戦記 第5巻#1節|01節]]　　造船計画、[[w:ピルスタエ族|ピルスタエ族]]の問題 **[[ガリア戦記 第5巻#2節|02節]]　　造船の進捗状況、トレウェリ族の問題 **[[ガリア戦記 第5巻#3節|03節]]　　トレウェリ族の動向、インドゥティオマルス]]と[[w:キンゲトリクス|キンゲトリクス **[[ガリア戦記 第5巻#4節|04節]]　　カエサルとインドゥティオマルス **[[ガリア戦記 第5巻#5節|05節]]　　イティウス港、ガリア領袖たちの召集 **[[ガリア戦記 第5巻#6節|06節]]　　[[w:ハエドゥイ族|ハエドゥイ族]]のドゥムノリクス **[[ガリア戦記 第5巻#7節|07節]]　　ドゥムノリクスの最期 [[画像:Devil's_Dyke_Hertfordshire_sign.jpg|thumb|right|300px|カエサルがカッスィウェッラウヌスを破ったと推定される遺跡の記念碑]] *　第2次ブリタンニア遠征 **[[ガリア戦記 第5巻#8節|08節]]　　ブリタンニアへ再び渡海 **[[ガリア戦記 第5巻#9節|09節]]　　ブリタンニア再上陸、敵の砦を夜襲 **[[ガリア戦記 第5巻#10節|10節]]　　再び嵐が船団を破損 **[[ガリア戦記 第5巻#11節|11節]]　　船団と陣営の防備、[[w:カッシウェラウヌス|カッスィウェッラウヌス]]登場 **[[ガリア戦記 第5巻#12節|12節]]　　ブリタンニアの地理(1)－部族と風土 **[[ガリア戦記 第5巻#13節|13節]]　　ブリタンニアの地理(2)－島々と地形 **[[ガリア戦記 第5巻#14節|14節]]　　ブリタンニアの地理(3)－生活習慣 **[[ガリア戦記 第5巻#15節|15節]]　　ブリタンニア勢がローマ陣営を襲撃 **[[ガリア戦記 第5巻#16節|16節]]　　ブリタンニア勢との戦術の優劣を分析 **[[ガリア戦記 第5巻#17節|17節]]　　[[w:ガイウス・トレボニウス|トレボニウス]]が敵の奇襲を撃退 **[[ガリア戦記 第5巻#18節|18節]]　　[[w:テムズ川|タメスィス川]]を渡河 **[[ガリア戦記 第5巻#19節|19節]]　　カッスィウェッラウヌスの戦車隊とローマ騎兵の交戦 **[[ガリア戦記 第5巻#20節|20節]]　　[[w:トリノヴァンテス族|トリノウァンテス族]]とマンドゥブラキウス **[[ガリア戦記 第5巻#21節|21節]]　　諸部族の投降、城市の陥落 **[[ガリア戦記 第5巻#22節|22節]]　　カンティウム勢による急襲、カッスィウェッラウヌスの降伏 **[[ガリア戦記 第5巻#23節|23節]]　　カエサルとローマ軍が大陸へ帰着する [[画像:Ambiorix.jpg|thumb|right|300px|アンビオリクスの銅像。[[w:ベルギー|ベルギー]]の[[w:トンゲレン|トンゲレン]]（Tongeren）市街に建つ。ローマ軍の侵略と闘って撃破した郷土の英雄として、同市が彫刻家ジュール・ベルタン（Jules Bertin）に依頼し1866年に建立した。]] *[[w:アンビオリクス|アンビオリクス]]と[[w:エブロネス族|エブロネス族]]の蜂起 **[[ガリア戦記 第5巻#24節|24節]]　　ローマ軍団8個半がガリア北部で冬営する **[[ガリア戦記 第5巻#25節|25節]]　　カルヌテス族の王タスゲティウスが殺される **[[ガリア戦記 第5巻#26節|26節]]　　[[w:クィントゥス・ティトゥリウス・サビヌス|サビヌス]]とコッタの冬営にエブロネス族が襲来 **[[ガリア戦記 第5巻#27節|27節]]　　アンビオリクスの弁明と通告 **[[ガリア戦記 第5巻#28節|28節]]　　ローマ陣営の大論争 **[[ガリア戦記 第5巻#29節|29節]]　　サビヌスの反論 **[[ガリア戦記 第5巻#30節|30節]]　　サビヌスのさらなる説得 **[[ガリア戦記 第5巻#31節|31節]]　　論争決し、ローマ勢が陣営を発つ **[[ガリア戦記 第5巻#32節|32節]]　　エブロネス族の待ち伏せ **[[ガリア戦記 第5巻#33節|33節]]　　戦慄するローマ勢 **[[ガリア戦記 第5巻#34節|34節]]　　エブロネス族の作戦 **[[ガリア戦記 第5巻#35節|35節]]　　苦戦に陥るローマ勢 **[[ガリア戦記 第5巻#36節|36節]]　　サビヌスの命乞い **[[ガリア戦記 第5巻#37節|37節]]　　サビヌスとコッタの最期、ローマ軍団の壊滅 *[[w:ネルウィイ族|ネルウィイー族]]ら[[w:ベルガエ人|ベルガエ人]]同盟の蜂起 **[[ガリア戦記 第5巻#38節|38節]]　　アンビオリクスがアドゥアトゥキ族とネルウィイー族を説得 **[[ガリア戦記 第5巻#39節|39節]]　　ネルウィイー族が[[w:クィントゥス・トゥッリウス・キケロ|キケロ]]の陣営に襲来 **[[ガリア戦記 第5巻#40節|40節]]　　キケロの陣営が攻囲される **[[ガリア戦記 第5巻#41節|41節]]　　キケロがネルウィイー族の詭弁をはねつける **[[ガリア戦記 第5巻#42節|42節]]　　ネルウィイー族がローマ人の包囲網と攻城術をまねる **[[ガリア戦記 第5巻#43節|43節]]　　ローマ勢が果敢に防戦 **[[ガリア戦記 第5巻#44節|44節]]　　百人隊長プッロとウォレヌスの奮戦 **[[ガリア戦記 第5巻#45節|45節]]　　ガリア人伝令がカエサルにキケロと軍団の危機を伝える **[[ガリア戦記 第5巻#46節|46節]]　　カエサルが副官たちに伝令を派遣する **[[ガリア戦記 第5巻#47節|47節]]　　カエサルと副官たちの動き **[[ガリア戦記 第5巻#48節|48節]]　　カエサルがキケロに返信 **[[ガリア戦記 第5巻#49節|49節]]　　ガリア勢がキケロの包囲を解いて、カエサルと対峙する **[[ガリア戦記 第5巻#50節|50節]]　　カエサルが詭計により敵勢をおびき寄せる **[[ガリア戦記 第5巻#51節|51節]]　　カエサルがネルウィイ族らを撃退 **[[ガリア戦記 第5巻#52節|52節]]　　カエサルがキケロの軍団と合流 *インドゥティオマルスとトレウェリ族の蜂起 **[[ガリア戦記 第5巻#53節|53節]]　　サビヌス敗死とカエサル勝利の影響 **[[ガリア戦記 第5巻#54節|54節]]　　セノネース族の背反、ガリアの不穏 **[[ガリア戦記 第5巻#55節|55節]]　　トレウェリ族のインドゥティオマルスが兵を集める **[[ガリア戦記 第5巻#56節|56節]]　　インドゥティオマルスの挙兵 **[[ガリア戦記 第5巻#57節|57節]]　　インドゥティオマルスが[[w:ティトゥス・ラビエヌス|ラビエーヌス]]の陣営に殺到 **[[ガリア戦記 第5巻#58節|58節]]　　インドゥティオマルスの最期 == [[ガリア戦記 第6巻|第6巻]] == '''ガリア北部の平定。ガリアとゲルマニアの風習。エブロネス族の追討''' *ガリア北部の平定 **[[ガリア戦記 第6巻#1節|01節]]　　カエサルが[[w:グナエウス・ポンペイウス|ポンペイウス]]の助けにより新兵を徴募する **[[ガリア戦記 第6巻#2節|02節]]　　ガリア北部の不穏な情勢 **[[ガリア戦記 第6巻#3節|03節]]　　[[w:ネルウィイ族|ネルウィイ族]]を降し、ガリアの領袖たちを召集する **[[ガリア戦記 第6巻#4節|04節]]　　アッコの造反、[[w:セノネス族|セノネス族]]と[[w:カルヌテス族|カルヌテス族]]を降す **[[ガリア戦記 第6巻#5節|05節]]　　アンビオリクスへの策を練り、[[w:メナピイ族|メナピイ族]]へ向かう **[[ガリア戦記 第6巻#6節|06節]]　　メナピイ族を降す **[[ガリア戦記 第6巻#7節|07節]]　　[[w:トレウェリ族|トレウェリ族]]の開戦準備、[[w:ティトゥス・ラビエヌス|ラビエヌス]]の計略 **[[ガリア戦記 第6巻#8節|08節]]　　ラビエヌスがトレウェリ族を降す *第二次ゲルマニア遠征 **[[ガリア戦記 第6巻#9節|09節]]　　再びレヌスを渡河、ウビイ族を調べる **[[ガリア戦記 第6巻#10節|10節]]　　ウビイ族を通じてスエビ族の動静を探る **[[ガリア戦記 第6巻#訳注：スエビ族とカッティ族・ケルスキ族・ウビイ族について|訳注：スエビ族とカッティ族・ケルスキ族・ウビイ族について]] *[[w:ガリア人|ガリア人]]の社会と風習について **[[ガリア戦記 第6巻#訳注：ガリア・ゲルマニアの地誌・民族誌について|訳注：ガリア・ゲルマニアの地誌・民族誌について]] **[[ガリア戦記 第6巻#11節|11節]]　　ガリア人の派閥性 **[[ガリア戦記 第6巻#12節|12節]]　　[[w:ハエドゥイ族|ハエドゥイ族]]、[[w:セクァニ族|セクァニ族]]、[[w:レミ族|レミ族]]の覇権争い **[[ガリア戦記 第6巻#13節|13節]]　　ガリア人の社会階級、平民および[[w:ドルイド|ドルイド]]について(1) **[[ガリア戦記 第6巻#14節|14節]]　　ドルイドについて(2) **[[ガリア戦記 第6巻#15節|15節]]　　ガリア人の騎士階級について **[[ガリア戦記 第6巻#16節|16節]]　　ガリア人の信仰と生け贄、[[w:ウィッカーマン|ウィッカーマン]] **[[ガリア戦記 第6巻#17節|17節]]　　ガリアの神々（ローマ風解釈） **[[ガリア戦記 第6巻#18節|18節]]　　ガリア人の時間や子供についての観念 **[[ガリア戦記 第6巻#19節|19節]]　　ガリア人の婚姻と財産・葬儀の制度 **[[ガリア戦記 第6巻#20節|20節]]　　ガリア部族国家の情報統制 *[[w:ゲルマニア|ゲルマニア]]の風習と自然について **[[ガリア戦記 第6巻#21節|21節]]　　ゲルマニア人の信仰と性 **[[ガリア戦記 第6巻#22節|22節]]　　ゲルマニア人の土地制度 **[[ガリア戦記 第6巻#23節|23節]]　　ゲルマニア諸部族のあり方 **[[ガリア戦記 第6巻#24節|24節]]　　ゲルマニア人とガリア人 **[[ガリア戦記 第6巻#25節|25節]]　　ヘルキュニアの森林地帯 **[[ガリア戦記 第6巻#26節|26節]]　　ヘルキュニアの野獣① **[[ガリア戦記 第6巻#27節|27節]]　　ヘルキュニアの野獣② **[[ガリア戦記 第6巻#28節|28節]]　　ヘルキュニアの野獣③ *対エブロネス族追討戦(1) **[[ガリア戦記 第6巻#29節|29節]]　　ゲルマニアから撤兵、対アンビオリクス戦へ出発 **[[ガリア戦記 第6巻#30節|30節]]　　アンビオリクスがバスィリスのローマ騎兵から逃れる **[[ガリア戦記 第6巻#31節|31節]]　　エブロネス族の退避、カトゥウォルクスの最期 **[[ガリア戦記 第6巻#32節|32節]]　　ゲルマニア部族の弁明、アドゥアトゥカに輜重を集める **[[ガリア戦記 第6巻#33節|33節]]　　軍勢をカエサル、ラビエヌス、トレボニウスの三隊に分散 **[[ガリア戦記 第6巻#34節|34節]]　　夷を以って夷を制す対エブロネス族包囲網 *スガンブリ族のアドゥアトゥカ攻略戦 **[[ガリア戦記 第6巻#35節|35節]]　　スガンブリ族が略奪に駆り立てられてアドゥアトゥカへ向かう **[[ガリア戦記 第6巻#36節|36節]]　　アドゥアトゥカのキケロが糧秣徴発に派兵する **[[ガリア戦記 第6巻#37節|37節]]　　スガンブリ族がキケロの陣営に襲来 **[[ガリア戦記 第6巻#38節|38節]]　　バクルスと百人隊長たちが防戦する **[[ガリア戦記 第6巻#39節|39節]]　　スガンブリ族が糧秣徴発部隊をも襲う **[[ガリア戦記 第6巻#40節|40節]]　　敵中突破して陣営へ戻る糧秣徴発部隊の明暗 **[[ガリア戦記 第6巻#41節|41節]]　　スガンブリ族の撤退、カエサルの帰還 **[[ガリア戦記 第6巻#42節|42節]]　　カエサルがスガンブリ族の襲来と撤退を運命に帰する *対エブロネス族追討戦(2) **[[ガリア戦記 第6巻#43節|43節]]　　アンビオリクスが辛うじて追討を逃れる **[[ガリア戦記 第6巻#44節|44節]]　　カエサルが撤退し、造反者アッコを処刑する == [[ガリア戦記 第7巻|第7巻]] == [[画像:Vercingétorix_par_Millet.jpg|thumb|right|300px|[[w:ウェルキンゲトリクス|ウェルキンゲトリクス]]の立像]] [[画像:Avaricum_westpoint_july_2006.jpg|thumb|right|450px|[[w:アウァリクム包囲戦|アウァリクム攻略戦]]の[[w:ジオラマ|ジオラマ]]（[[w:陸軍士官学校 (アメリカ合衆国)|米国陸軍士官学校]]博物館）。]] [[画像:Dorf_La_Roche_Blanche.JPG|thumb|right|450px|[[w:ゲルゴウィアの戦い|ゲルゴウィア攻略戦]]（[[w:la:Obsidio Gergoviensis|Obsidio Gergoviensis]]）の舞台となった現在のジェルゴヴィ高地（[[w:fr:Plateau_de_Gergovie|Plateau de Gergovie]]）の遠景。画像中央がローマ軍が小さい方の陣営を設置していたと推定されているラ・ロシュ＝ブランシュ（[[w:fr:La_Roche-Blanche_(Puy-de-Dôme)|La Roche Blanche]]）の丘陵で、山頂からこの丘陵の辺りが激戦地だったと思われる。]] '''ウェルキンゲトリクス率いるガリア同盟軍との戦役''' *[[w:ウェルキンゲトリクス|ウェルキンゲトリクス]]とガリア同盟軍の蜂起 **[[ガリア戦記 第7巻#1節|01節]]　　首都ローマの政情不安、ガリア人領袖たちの謀計 **[[ガリア戦記 第7巻#2節|02節]]　　カルヌテス族が開戦動議 **[[ガリア戦記 第7巻#3節|03節]]　　カルヌテス族がケナブム進駐 **[[ガリア戦記 第7巻#4節|04節]]　　アルウェルニ族のウェルキンゲトリクスが挙兵、ガリア諸部族同盟軍を指揮する **[[ガリア戦記 第7巻#5節|05節]]　　ビトゥリゲス族がガリア同盟軍に寝返る **[[ガリア戦記 第7巻#6節|06節]]　　諸軍団と分断されて苦慮するカエサル **[[ガリア戦記 第7巻#7節|07節]]　　[[w:ナルボンヌ|ナルボ]]をめぐる属州内外の攻防の駆け引き **[[ガリア戦記 第7巻#8節|08節]]　　カエサルがケウェンナ山地を越えてアルウェルニ族の領内へ突入 **[[ガリア戦記 第7巻#9節|09節]]　　カエサルが諸軍団と合流、同盟軍はボイイ族攻略をめざす **[[ガリア戦記 第7巻#10節|10節]]　　カエサルがアゲディンクムを発って、ボイイ族支援に向かう **[[ガリア戦記 第7巻#11節|11節]]　　セノネス族のウェッラウノドゥヌムを降し、カルヌテス族のケナブムを攻略 **[[ガリア戦記 第7巻#12節|12節]]　　ビトゥリゲス族のノウィオドゥヌムを降すが、敵の騎兵が来援 **[[ガリア戦記 第7巻#13節|13節]]　　同盟軍の騎兵を撃退、城市を再び降して、アウァリクム攻めに向かう *[[w:アウァリクム包囲戦|アウァリクム攻略戦]] **[[ガリア戦記 第7巻#14節|14節]]　　ウェルキンゲトリクスが[[w:兵站|兵站]]妨害と[[w:焦土作戦|焦土戦術]]を決断 **[[ガリア戦記 第7巻#15節|15節]]　　焦土戦術開始、しかしアウァリクムの防衛を決定 **[[ガリア戦記 第7巻#16節|16節]]　　アウァリクムをめぐる両軍の駆け引き **[[ガリア戦記 第7巻#17節|17節]]　　攻囲に取りかかるローマ軍の[[w:糧秣|糧秣]]欠乏 **[[ガリア戦記 第7巻#18節|18節]]　　カエサルがウェルキンゲトリクス不在の敵陣へ迫る **[[ガリア戦記 第7巻#19節|19節]]　　丘の上のガリア勢と沼沢を挟んで対峙する **[[ガリア戦記 第7巻#20節|20節]]　　ウェルキンゲトリクスが味方に弁明し、捕虜に問い質す **[[ガリア戦記 第7巻#21節|21節]]　　ウェルキンゲトリクスの誠心とアウァリクムの重要性を確認 **[[ガリア戦記 第7巻#22節|22節]]　　アウァリクムの籠城ガリア勢が[[w:坑道戦|坑道戦]]で攻防に努める **[[ガリア戦記 第7巻#23節|23節]]　　ガリア式城壁の構造 **[[ガリア戦記 第7巻#24節|24節]]　　ローマ勢が徹夜の土塁工事、籠城ガリア勢の攻勢 **[[ガリア戦記 第7巻#25節|25節]]　　籠城ガリア勢が必死の防戦 **[[ガリア戦記 第7巻#26節|26節]]　　アウァリクム脱出の企て、女たちの絶叫 **[[ガリア戦記 第7巻#27節|27節]]　　ローマ軍が大雨の中で城壁を占拠 **[[ガリア戦記 第7巻#28節|28節]]　　ローマ軍がアウァリクムの市民4万人を大虐殺 **[[ガリア戦記 第7巻#29節|29節]]　　ウェルキンゲトリクスが演説で味方を鼓舞する **[[ガリア戦記 第7巻#30節|30節]]　　ガリア勢がウェルキンゲトリクスに心服し、希望を抱く **[[ガリア戦記 第7巻#31節|31節]]　　ウェルキンゲトリクスがほかの諸部族を勧誘し、兵力を補充する *[[w:ゲルゴウィアの戦い|ゲルゴウィア攻略戦]]、[[w:ハエドゥイ族|ハエドゥイ族]]の離反 **[[ガリア戦記 第7巻#32節|32節]]　　ハエドゥイ族内紛の危機 **[[ガリア戦記 第7巻#33節|33節]]　　カエサルがハエドゥイ族の権力をコンウィクトリタウィスに与える **[[ガリア戦記 第7巻#34節|34節]]　　ハエドゥイ族を動員し、ローマ軍をカエサルとラビエヌスの二隊に分散 **[[ガリア戦記 第7巻#35節|35節]]　　カエサルが陽動によってエラウェル川に架橋、渡河する **[[ガリア戦記 第7巻#36節|36節]]　　両軍がゲルゴウィアの要衝に陣営を築く **[[ガリア戦記 第7巻#37節|37節]]　　ハエドゥイ族のコンウィクトリタウィスがガリア同盟軍に内応する **[[ガリア戦記 第7巻#38節|38節]]　　リタウィックスの鼓舞でハエドゥイ族の歩兵1万が挙兵する **[[ガリア戦記 第7巻#39節|39節]]　　エポレドリクスがハエドゥイ勢1万の寝返りをカエサルに知らせる **[[ガリア戦記 第7巻#40節|40節]]　　カエサルが4個軍団を率いてハエドゥイ勢1万を制止し、リタウィックスは逃亡 **[[ガリア戦記 第7巻#41節|41節]]　　副官ファビウスの報告：ゲルゴウィアの敵勢がローマ陣営に襲来 **[[ガリア戦記 第7巻#42節|42節]]　　ハエドゥイ族の者たちが反ローマ暴動を引き起こす **[[ガリア戦記 第7巻#43節|43節]]　　ハエドゥイ族当局がカエサルに屈服。ガリア大動乱の予感 **[[ガリア戦記 第7巻#44節|44節]]　　ゲルゴウィアの急所の尾根 **[[ガリア戦記 第7巻#45節|45節]]　　ローマ勢の陽動部隊が敵を引き付け、本隊が敵の本陣を目指す **[[ガリア戦記 第7巻#46節|46節]]　　ローマ軍の本隊が防壁を越えて、敵陣の一部を占拠 **[[ガリア戦記 第7巻#47節|47節]]　　血気にはやるローマ兵たちの猪突猛進、ガリア女たちの命乞い **[[ガリア戦記 第7巻#48節|48節]]　　ガリア勢が城市に引き返して、防戦に努める **[[ガリア戦記 第7巻#49節|49節]]　　カエサルが劣勢の自軍に副官セクスティウスを増援する **[[ガリア戦記 第7巻#50節|50節]]　　激戦の末、敗勢に陥るローマ軍 **[[ガリア戦記 第7巻#51節|51節]]　　カエサルが一敗地に塗れる **[[ガリア戦記 第7巻#52節|52節]]　　敗軍の将カエサルが兵士たちを責める **[[ガリア戦記 第7巻#53節|53節]]　　カエサルとローマ軍がゲルゴウィアから撤退 **[[ガリア戦記 第7巻#54節|54節]]　　ハエドゥイ族のエポレドリクスとウィリドマルスらがカエサルのもとから立ち去る **[[ガリア戦記 第7巻#55節|55節]]　　エポレドリクスとウィリドマルスらがローマの拠点ノウィオドゥヌムで寝返る **[[ガリア戦記 第7巻#56節|56節]]　　カエサルが属州へは戻らず、増水した[[w:ロワール川|リゲル川]]の渡河を敢行 *[[w:ティトゥス・ラビエヌス|ラビエヌス]]の[[w:ルテティア|ルテティア]]遠征 **[[ガリア戦記 第7巻#57節|57節]]　　副官ラビエヌスがルテティア制圧に向かう **[[ガリア戦記 第7巻#58節|58節]]　　ラビエヌスがメトロセドゥムを陥落させ、ルテティアのガリア勢と対峙 **[[ガリア戦記 第7巻#59節|59節]]　　ガリア諸部族が迫り、ラビエヌスが作戦変更を決断 **[[ガリア戦記 第7巻#60節|60節]]　　ラビエヌスが陽動戦術に努める **[[ガリア戦記 第7巻#61節|61節]]　　ラビエヌスの陽動により、敵将カムロゲヌスが兵力を分散 **[[ガリア戦記 第7巻#62節|62節]]　　ラビエヌスがカムロゲヌス麾下のガリア勢を各個撃破して、カエサルと合流 *ガリア戦乱の拡大 **[[ガリア戦記 第7巻#63節|63節]]　　ハエドゥイ族がウェルキンゲトリクスに主導権争いを挑む **[[ガリア戦記 第7巻#64節|64節]]　　ウェルキンゲトリクスがガリア諸部族の誘降・服従を謀る **[[ガリア戦記 第7巻#65節|65節]]　　カエサルと同盟諸部族の防戦。ゲルマニア騎兵を呼び寄せる **[[ガリア戦記 第7巻#66節|66節]]　　属州へと南下するカエサル、迎え撃とうとするウェルキンゲトリクス **[[ガリア戦記 第7巻#67節|67節]]　　カエサル麾下のゲルマニア騎兵がウェルキンゲトリクスを一蹴 *[[w:アレシアの戦い|アレスィア攻囲戦]] **[[ガリア戦記 第7巻#68節|68節]]　　ウェルキンゲトリクスがアレスィア入城、カエサルは攻囲を決断 **[[ガリア戦記 第7巻#69節|69節]]　　アレスィアの地勢、ローマ軍の攻囲線 **[[ガリア戦記 第7巻#70節|70節]]　　カエサル麾下のゲルマニア騎兵が、再びガリア騎兵を虐殺 **[[ガリア戦記 第7巻#71節|71節]]　　ウェルキンゲトリクスが援兵召集のため騎兵を放ち、籠城策を定める **[[ガリア戦記 第7巻#72節|72節]]　　カエサルが、より大掛かりな攻囲陣地を構築する **[[ガリア戦記 第7巻#73節|73節]]　　カエサルは、攻囲陣地をさらに障害物で補強する **[[ガリア戦記 第7巻#74節|74節]]　　ガリア人の来援に備えて、外周にも同様の塁壁を張り巡らす **[[ガリア戦記 第7巻#75節|75節]]　　ガリア同盟が各部族に動員を要請する **[[ガリア戦記 第7巻#76節|76節]]　　コンミウスもガリア同盟軍に内応、約25万の大軍が集結 **[[ガリア戦記 第7巻#77節|77節]]　　飢餓状態のアレスィアで、クリトグナトゥスが極論を唱える **[[ガリア戦記 第7巻#78節|78節]]　　マンドゥビイ族の投降をカエサルが拒む **[[ガリア戦記 第7巻#79節|79節]]　　ガリア同盟軍の来援、アレスィアの歓呼 **[[ガリア戦記 第7巻#80節|80節]]　　ゲルマニア騎兵らローマ勢が来援ガリア騎兵をも打ち破る **[[ガリア戦記 第7巻#81節|81節]]　　ガリア来援軍と籠城軍がローマ陣地に夜襲をしかける **[[ガリア戦記 第7巻#82節|82節]]　　アレスィア内外のガリア勢が障害物に阻まれて退く **[[ガリア戦記 第7巻#83節|83節]]　　ウェルカッスィウェッラウヌスが兵6万を率いて急所の丘へ向かう **[[ガリア戦記 第7巻#84節|84節]]　　ウェルキンゲトリクスらアレスィア籠城軍も善戦する **[[ガリア戦記 第7巻#85節|85節]]　　ウェルカッスィウェッラウヌスが急所の丘を攻める **[[ガリア戦記 第7巻#86節|86節]]　　危急存亡の秋、両軍の苦闘 **[[ガリア戦記 第7巻#87節|87節]]　　カエサルの救援、ラビエヌスの作戦 **[[ガリア戦記 第7巻#88節|88節]]　　雌雄決し、ガリア来援軍が敗走 *ガリア同盟軍主力の降伏 **[[ガリア戦記 第7巻#89節|89節]]　　ウェルキンゲトリクスとアレスィア籠城軍の降伏 **[[ガリア戦記 第7巻#90節|90節]]　　ハエドゥイ族とアルウェルニ族の降伏、諸軍団の冬営 == [[ガリア戦記 第8巻|第8巻]] == hgmroyde6gadh3ebydbpopnm9jebk0w 0 19044 206074 178602 2022-08-01T02:25:57Z 27.133.159.229 /* 州の分類 */ wikitext text/x-wiki [[ファイル:Indianocean.png|left|thumb|200px|インド洋]] [[ファイル:Atlantic Ocean-ja.png|thumb|大西洋]] [[ファイル:Pacific Ocean.png|right|thumb|200px|太平洋の位置。日本は、この図の左上のほうにある。三角印で示された点は、太平洋の最深点であるチャレンジャー海淵。]] 世界には、陸地には6つの <span style="font-size: large;">大陸</span>（たいりく、英：continent コンティネント） と、海洋には3つの <span style="font-size: large;">大洋</span>（たいよう、英：ocean オーシャン） がある。 <span style="font-size: large;">六大陸</span>（ろくたいりく）や<span style="font-size: large;">三大洋</span>（さんたいよう）などと呼ばれることもある。 地球全体の陸地よりも、地球全体の海洋のほうが広い。 陸地と海洋の面積の比は、おおよそ : 陸地の面積：海洋の面積＝3：7 である。 つまり、海のほうが陸地よりも2倍以上広い。 == ３つの大洋 == 3つの大洋とは <span style="font-size: large;">太平洋</span>（たいへいよう、英：Pacific Ocean）、<span style="font-size: large;">大西洋</span>（たいせいよう、英：Atlantic Ocean）、<span style="font-size: large;">インド洋</span>（英：Indian Ocean） である。このうち、日本が接しているのは太平洋のみである。 「太平洋」の「太」は「ふとい」の字だが、「大西洋」の「大」は「おおきい」の字なので、間違えないように。 世界地理の話題では、日本海など3つの大洋以外の海は、大洋のどれかに属した海として扱う。 大西洋とは、ヨーロッパ（英：Europe）の西側にあり、ヨーロッパとアメリカ（英：America）との間にある大きな海です。 インド洋とは、インド半島（英：Indian subcontinent）の周囲とインドの南にあり、アフリカの東海岸とオーストラリアの西海岸で囲まれた、アフリカ(Africa)・インド(India)・オーストラリア(Australia)との間の海です。 {{clear}} == 六大陸 == 6つの大陸とは、<span style="font-size: large;">ユーラシア大陸</span>(英: Eurasia ユーレイシア)、<span style="font-size: large;">アフリカ大陸</span>(Africa アフリカ)、<span style="font-size: large;">北アメリカ大陸</span>(North America ノース・アメリカ)、<span style="font-size: large;">南アメリカ大陸</span>(South America サウス・アメリカ)、<span style="font-size: large;">オーストラリア大陸</span>(Australia オーストレイリア)、<span style="font-size: large;">南極大陸</span>(Antarctica アンタークティカ)の6つである。 ユーラシア大陸とは、ロシアや中華人民共和国やヨーロッパ諸国やインドなどがある大陸である。もっとも広い大陸はユーラシア大陸である。 {{clear}} <gallery widths=300px heights=300px> File:Two-point-equidistant-asia.jpg|ユーラシア大陸 File:Africa satellite orthographic.jpg|アフリカ大陸 File:North America satellite orthographic.jpg|北アメリカ大陸 File:South America satellite orthographic.jpg|南アメリカ大陸 File:Australia satellite plane.jpg|オーストラリア File:Antarctica 6400px from Blue Marble.jpg|南極大陸 </gallery> == 州の分類 == [[File:Europe (orthographic projection).svg|thumb|left|200px|ヨーロッパ州。]] [[File:Asia (orthographic projection).svg|thumb|200px|アジア州。]] [[Image:Location-Asia-UNsubregions.png|thumb|225px|アジア州の地域の分類<br> <div style="background:#0000E0; border:1px solid #000000; float: left;">　</div>　シベリア<br><br> <div style="background:#E000E0; border:1px solid #000000; float: left;">　</div>　中央アジア<br><br> <div style="background:#00E000; border:1px solid #000000; float: left;">　</div>　西アジア<br><br> <div style="background:#E00000; border:1px solid #000000; float: left;">　</div>　南アジア<br><br> <div style="background:#FFFF20; border:1px solid #000000; float: left;">　</div>　東アジア<br><br> <div style="background:#FFC000; border:1px solid #000000; float: left;">　</div>　東南アジア]] いくつかの大陸は、さらに<span style="font-size: large;">州</span>（しゅう）に分けられる。 その結果、世界は大まかに6つの州に分けられる。 <span style="font-size: large;">アジア州</span>（アジアしゅう、Asia エイジャ）、<span style="font-size: large;">ヨーロッパ州</span>（ヨーロッパしゅう、Europe ユーロプ）、<span style="font-size: large;">アフリカ州</span>、<span style="font-size: large;">北アメリカ州</span>、<span style="font-size: large;">南アメリカ州</span>、<span style="font-size: large;">オセアニア州</span>(Oceania オウシェアニア)の６つの州である。 ユーラシア大陸は、ウラル山脈（英: Ural Mountains）を境（さかい）にして、 <span style="font-size: large;">ヨーロッパ州</span>（ヨーロッパしゅう） と <span style="font-size: large;">アジア州</span>（アジアしゅう） とに分かれています。 ロシア（英：Russia）というユーラシア大陸の北にある大きな国は、ヨーロッパ州とアジア州に、またがっています。なお、ロシアは、かつてソビエト連邦（英：Soviet Union ソビエト・ユニオン）を冷戦のときに構成していた国である。 <span style="font-size: large;">オセアニア州</span>とは、オーストラリア大陸と、その周辺の諸島の地域です。 いくつかの州は、さらに細かく分かれます。 アジア州では、東アジア（英：East Asia イースト・エイジャ）や東南アジア（英：Southeast Asia）、シベリア（英：Siberia サイビーリア）、中央アジア（英：Central Asia セントラル・エイジャ）、南アジア（英：South Asia サウス・エイジャ）、西アジア（英：Western Asia）などに分かれます。 私たちの国の日本（英：Japan ジャパン）は、東アジアにあります。 [[ファイル:Oceania (orthographic projection).svg|200px|center|thumb|オセアニア州]] [[Category:中学校地理|みつつのたいようとむつつのたいりく]] 6h0f5fqp420l1eh1bf0qy01u876sc8s 206075 206074 2022-08-01T02:26:18Z 27.133.159.229 wikitext text/x-wiki [[ファイル:Indianocean.png|left|thumb|200px|インド洋]] [[ファイル:Atlantic Ocean-ja.png|thumb|大西洋]] [[ファイル:Pacific Ocean.png|right|thumb|200px|太平洋の位置。日本は、この図の左上のほうにある。三角印で示された点は、太平洋の最深点であるチャレンジャー海淵。]] 世界には、陸地には6つの <span style="font-size: large;">大陸</span>（たいりく、英：continent コンティネント） と、海洋には3つの <span style="font-size: large;">大洋</span>（たいよう、英：ocean オーシャン） がある。 <span style="font-size: large;">六大陸</span>（ろくたいりく）や<span style="font-size: large;">三大洋</span>（さんたいよう）などと呼ばれることもある。 地球全体の陸地よりも、地球全体の海洋のほうが広い。 陸地と海洋の面積の比は、おおよそ : 陸地の面積：海洋の面積＝3：7 である。 つまり、海のほうが陸地よりも2倍以上広い。 == ３つの大洋 == 3つの大洋とは <span style="font-size: large;">太平洋</span>（たいへいよう、英：Pacific Ocean）、<span style="font-size: large;">大西洋</span>（たいせいよう、英：Atlantic Ocean）、<span style="font-size: large;">インド洋</span>（英：Indian Ocean） である。このうち、日本が接しているのは太平洋のみである。 「太平洋」の「太」は「ふとい」の字だが、「大西洋」の「大」は「おおきい」の字なので、間違えないように。 世界地理の話題では、日本海など3つの大洋以外の海は、大洋のどれかに属した海として扱う。 大西洋とは、ヨーロッパ（英：Europe）の西側にあり、ヨーロッパとアメリカ（英：America）との間にある大きな海です。 インド洋とは、インド半島（英：Indian subcontinent）の周囲とインドの南にあり、アフリカの東海岸とオーストラリアの西海岸で囲まれた、アフリカ(Africa)・インド(India)・オーストラリア(Australia)との間の海です。 {{clear}} == 六大陸 == 6つの大陸とは、<span style="font-size: large;">ユーラシア大陸</span>(英: Eurasia ユーレイシア)、<span style="font-size: large;">アフリカ大陸</span>(Africa アフリカ)、<span style="font-size: large;">北アメリカ大陸</span>(North America ノース・アメリカ)、<span style="font-size: large;">南アメリカ大陸</span>(South America サウス・アメリカ)、<span style="font-size: large;">オーストラリア大陸</span>(Australia オーストレイリア)、<span style="font-size: large;">南極大陸</span>(Antarctica アンタークティカ)の6つである。 ユーラシア大陸とは、ロシアや中華人民共和国やヨーロッパ諸国やインドなどがある大陸である。もっとも広い大陸はユーラシア大陸である。 {{clear}} <gallery widths=300px heights=300px> File:Two-point-equidistant-asia.jpg|ユーラシア大陸 File:Africa satellite orthographic.jpg|アフリカ大陸 File:North America satellite orthographic.jpg|北アメリカ大陸 File:South America satellite orthographic.jpg|南アメリカ大陸 File:Australia satellite plane.jpg|オーストラリア大陸 File:Antarctica 6400px from Blue Marble.jpg|南極大陸 </gallery> == 州の分類 == [[File:Europe (orthographic projection).svg|thumb|left|200px|ヨーロッパ州。]] [[File:Asia (orthographic projection).svg|thumb|200px|アジア州。]] [[Image:Location-Asia-UNsubregions.png|thumb|225px|アジア州の地域の分類<br> <div style="background:#0000E0; border:1px solid #000000; float: left;">　</div>　シベリア<br><br> <div style="background:#E000E0; border:1px solid #000000; float: left;">　</div>　中央アジア<br><br> <div style="background:#00E000; border:1px solid #000000; float: left;">　</div>　西アジア<br><br> <div style="background:#E00000; border:1px solid #000000; float: left;">　</div>　南アジア<br><br> <div style="background:#FFFF20; border:1px solid #000000; float: left;">　</div>　東アジア<br><br> <div style="background:#FFC000; border:1px solid #000000; float: left;">　</div>　東南アジア]] いくつかの大陸は、さらに<span style="font-size: large;">州</span>（しゅう）に分けられる。 その結果、世界は大まかに6つの州に分けられる。 <span style="font-size: large;">アジア州</span>（アジアしゅう、Asia エイジャ）、<span style="font-size: large;">ヨーロッパ州</span>（ヨーロッパしゅう、Europe ユーロプ）、<span style="font-size: large;">アフリカ州</span>、<span style="font-size: large;">北アメリカ州</span>、<span style="font-size: large;">南アメリカ州</span>、<span style="font-size: large;">オセアニア州</span>(Oceania オウシェアニア)の６つの州である。 ユーラシア大陸は、ウラル山脈（英: Ural Mountains）を境（さかい）にして、 <span style="font-size: large;">ヨーロッパ州</span>（ヨーロッパしゅう） と <span style="font-size: large;">アジア州</span>（アジアしゅう） とに分かれています。 ロシア（英：Russia）というユーラシア大陸の北にある大きな国は、ヨーロッパ州とアジア州に、またがっています。なお、ロシアは、かつてソビエト連邦（英：Soviet Union ソビエト・ユニオン）を冷戦のときに構成していた国である。 <span style="font-size: large;">オセアニア州</span>とは、オーストラリア大陸と、その周辺の諸島の地域です。 いくつかの州は、さらに細かく分かれます。 アジア州では、東アジア（英：East Asia イースト・エイジャ）や東南アジア（英：Southeast Asia）、シベリア（英：Siberia サイビーリア）、中央アジア（英：Central Asia セントラル・エイジャ）、南アジア（英：South Asia サウス・エイジャ）、西アジア（英：Western Asia）などに分かれます。 私たちの国の日本（英：Japan ジャパン）は、東アジアにあります。 [[ファイル:Oceania (orthographic projection).svg|200px|center|thumb|オセアニア州]] [[Category:中学校地理|みつつのたいようとむつつのたいりく]] eghve5m20ge6dgwvg6d1hq9iaq402vc 0 19396 206108 205721 2022-08-01T07:14:59Z はいかぐら 45848 wikitext text/x-wiki == ロシアの南下政策と日英同盟 == 1899年（明治32年）の義和団の事件のあとも、ロシアは兵力をひかず、ロシア軍は満州にいつづけた。そして、朝鮮半島や清に勢力をひろげようとする南下政策（なんか せいさく）をロシアは目指した。 ロシアは、冬でも凍らない港が、軍事上の理由で必要だった。このような冬でも凍らない港のことを、不凍港（ふとうこう）と言う。なので、ロシアは、領土を南方に拡大したかった。 いっぽう、中国大陸に利権を持つイギリスにとっては、ロシアの南下政策が不都合だった。さらに当時のロシアは、ロシア国内で東西に長いシベリア鉄道（シベリアてつどう）を建設していた。もしシベリア鉄道が完成すると、軍隊の兵士や軍事物資も、すばやく送れるようになるので、イギリスにとっては、ロシアはとても危険な国だった。 そこでイギリスは、ロシアの南下政策に対抗するため、日本とイギリスとのあいだでの同盟を1902年に結んだ。この日本とイギリスの同盟を、<big>'''日英同盟'''</big>（にちえい どうめい、英語: Anglo-Japanese Alliance　アングロ-ジャパニーズ・アライアンス）と言う。 *日英同盟にいたるまでの経緯 遼東半島（リャオトンはんとう、りょうとうはんとう）にあった旅順（りょじゅん、リュイシュン）では、ロシアが軍艦の基地を増設していた。 '''義和団事件'''の鎮圧の名目で、ロシアは満洲を占領した。義和団の乱の収束後も、ロシアは満州から撤兵しなかった（※ 「義和団事件」については、[[中学校社会 歴史/日清戦争から日露戦争までのあいだ]] ）。 日本・イギリス・アメリカの３カ国がロシアに抗議（こうぎ）して、ロシアは兵を引くことを約束した。だが、じっさいにはロシアは兵をひかずに居続けた。それどころか、ロシアは占領軍の増強をした。 ロシアの強硬な方針に、イギリスは危機感を感じた。そしてイギリスは、日本と同盟をした。これが日英同盟である。 ロシアの勢力の拡大を恐れ、日本の政府は戦争を警戒していった。いっぽうのロシアの政府も、大国であるロシアとすれば小国にすぎない日本を恐れる必要はなく、なので日本との戦争もかまわないという強硬な姿勢をロシアは強めていった。 == 日露戦争 == 日本はロシアとの戦争をふせぐため、外交で解決しようとした。日本の案では、ロシアが満州を支配することを認めるかわりに、日本が朝鮮を支配することを認めさせるという案をロシアに提出した。（※ 教育出版および清水書院の検定教科書に、このことの記述あり。） しかし、ロシアがこの案を拒否し、交渉はまとまらず決裂し、1904年に、ついに日本はロシアとの戦争の開戦にふみきった。 ロシアの満州領有に反対するイギリスとアメリカは、日本の戦費の調達に協力し、日本を経済的に支援した。（※ 中学の範囲。東京書籍の教科書に記述あり。） このころ、日本銀行副総裁（ふくそうさい）の'''高橋是清'''（たかはし これきよ）が、外債（「がいさい」、外国からの借金のこと）の調達のため、イギリスやアメリカを訪問して、イギリスやアメリカの銀行家や資本家からの信用を得て、日本公債を発行し、戦費調達に成功した。 このように、日本は日露戦争のために多額の借金をした。 日露戦争の戦場になった場所は、朝鮮半島の周辺の海域と、満州の陸上および海域であった。 陸地での戦場では、旅順（りょじゅん、リュイシュン）や奉天（ほうてん、フォンティエン）での戦いで、日本は苦戦のすえ、ロシアに勝った。旅順の攻略では乃木希典（のぎ まれすけ）が日本軍をひきいた。奉天の戦いでは大山巌（おおやま いわお）が日本軍をひきいた。 [[ファイル:Tsushima battle map-ja.svg|thumb|300px|right|ロシア艦隊は対馬近海で連合艦隊と遭遇し、日本海南西部で撃破された。]] 日本海海戦では、海軍中将（ちゅうじょう）の'''東郷平八郎'''（とうごう へいはちろう）ひきいる連合艦隊が、ロシアの'''バルチック艦隊'''を全滅させた。 勝敗の結果だけを見ると日本の大勝のように見えるが、日本は大きく戦力を消耗しており、また、軍事費を使いきっていた。日本は、戦争の続行がむずかしかった。 いっぽうのロシアでも政府に反対する革命の動きがおきはじめ、ロシア政府は戦争をつづけることが、難しくなった。 そこで日本は状況が日本に有利なうちに講和をしようと考え、アメリカにロシアとの講和の仲立ちをしてもらって、講和条約である <big>'''ポーツマス条約'''</big> (英語: Portsmouth Treaty) が結ばれ、日露戦争は終結した。 === 講和 === [[ファイル:Jutaro Komura.jpg|thumb|200px|小村寿太郎（こむら じゅたろう）]] アメリカ大統領の<big>セオドア＝ローズベルト</big>(Roosevelt)が講和の仲立ちになり、日本の代表は外相（がいしょう、意味：外交の大臣のこと）の<big>'''小村寿太郎'''</big>（こむら じゅたろう）であった。ロシアの代表は<big>ヴィッテ</big>(Витте)である。 :条約の結果、日本は朝鮮での優越権を認められた。 :日本は、南満州の長春（ちょうしゅん、チャンチュン）以南の鉄道の利権を得た。 :日本は、ロシアから樺太の北緯50度以南（ほぼ南半分）の領土を、日本へゆずらせた。 :日本は、ロシアから、'''旅順'''および'''大連'''（だいれん）をふくむ遼東（リャオトン）半島の南端部の'''租借権'''（そしゃくけん）を、日本へ譲らせた。 :日本は漁業権を獲得した。沿海州およびカムチャッカ半島の沿岸での漁業権を日本が獲得。 日本は講和を急いだため、賠償金（ばいしょうきん）をとらなかった。このことが国民の反発を呼び、東京の日比谷（ひびや）では焼き討ち事件が起きた。新聞社や警察の交番などが焼き討ちされた。（日比谷焼き討ち事件）　国民からすれば、戦争で多くの負担をしたにもかかわらず、賠償金をとれないことを不満に感じたのであった。 :（※ 高校の範囲:）このとき日本が獲得した大連が、のちの日本の満州経営での拠点になる。後述の満鉄株式会社の本社も大連にあった。（第一学習社『日本史A』の見解） === 戦後 === 満州には、満州経営のため、政府により半官半民の企業の'''南満州鉄道株式会社'''（みなみまんしゅう てつどう かぶしきがいしゃ） （ 略称： '''満鉄'''（まんてつ） ）が設立された。　 また、満鉄の鉄道の警備などのため、満州に日本軍が置かれた。 なお、この満州鉄道を警備している日本軍は、のちの1919年に「関東軍」（かんとうぐん）と言い改められる。中国の山海関（さんかいかん）より東の位置を「関東」といい、その地域を守備していたので、関東軍（かんとうぐん）と言い改められる。 この戦争の交渉の結果、日本は満州に権益を得ることになった。のちの第二次世界対戦のときに日本軍が満州に滞在している理由は、おおまかな理由は、元をただせば、この日露戦争で得た権益を防衛するために派兵されたからである。 さて、1907年には <big>日露協約</big>（にちろ きょうやく） で、日本とロシアとの、満州での勢力範囲が決められた。 この満州への日本による権益獲得では、アメリカが日露戦争では資金面などで日本に協力したにも関わらず、ほぼ日本が満州の権益を独占することになり、アメリカは満州に権益を獲得できなかった。アメリカなどは、満州の事業の門戸開放を日本に要求したが、日本は要求を拒んだ。こうしてアメリカの日本への不満が高まり、のちにアメリカと日本とが対立していく原因の一つとなったと考えられる。 === 戦前の世論 === ==== 非戦論 ==== 日露戦争の前、開戦を、多くの国民が支持した。だが、開戦に反対する意見もあった。 非戦論（ひせんろん）をとなえた人をあげれば、キリスト教徒の'''内村鑑三'''（うちむら かんぞう）や、社会主義者の幸徳秋水（こうとく しゅうすい）が有名である。 [[ファイル:Akiko Yosano younger.jpg|thumb|200px|与謝野晶子（よさの あきこ）]] また、歌人の<big>'''与謝野晶子'''</big>（よさの あきこ）は、戦場にいる弟を思いやる詩を書き、「君（きみ） 死（し）にたまふ（たもう）こと なかれ」という詩を書いた。 <div style="border:1px solid #000000;"> 　'''君死にたまふことなかれ'''（抜粋） : あゝ をとうとよ 君を泣く : 君 死にたもふこと なかれ : 末（すえ）に 生まれし 君なれば : 親の なさけは まさりしも : 親は 刃(やいば)を にぎらせて : 人を 殺せと をしえしや : 人を 殺して 死ねよとて : 二十四までを そだてしや ::雑誌『明星』（みょうじょう）、明治37年(1904年)9月号『恋衣』（晶子第四歌集）所収。 </div> 与謝野晶子の詩は、当時の日本国民の多くから、反戦の気持ちを遠回しにうたった詩として、うけとめられた。 なお、現代では、与謝野晶子を反戦詩人としてあつかう説をとなえる学者や評論家がいるが、のちの第一次世界大戦や第二次世界大戦のころには、日本および戦争を支持する詩も書いていることもあり、はたして与謝野晶子が日露戦争に反戦であったかどうかについては、はっきりとした証拠がない。 * 内村鑑三の戦争廃止論 <div style="border:1px solid #000000;"> ::内村鑑三の戦争廃止論 :余（よ）は日露非開戦論者であるばかりでない、戦争絶対的廃止論者である。・・・（中略）・・・戦争の利益は強盗の利益である。・・・・・・近くはその実例を日清戦争において見ることができる。二億の富と一万の生命を消費して日本国がこの戦争より得し（えし）ものは何であるか。・・・その目的たりし朝鮮の独立は・・・弱められ、支那（「しな」＝中国のこと）分割の端緒（たんしょ）は開かれ、日本国民の分担は非常に増加され、・・・東洋全体を危殆（きたい）の地位にまで持ちきったではないか。 ::（『万朝報』（よろずちょうほう）1903年6月30日、抜粋。） </div> 現代語訳 私は日露戦争の非開戦論者であるばかりでなく、戦争の絶対廃止論者である。・・・（中略）・・・戦争の利益は強盗の利益である。・・・・・・近くはその実例を日清戦争において見ることができる。二億の富と一万の生命を消費して日本国がこの戦争より得たものは何であるか。・・・その目的だった朝鮮の独立は弱められ、中国の分割が始まり、日本国民の負担はとても増加し、・・・東洋全体が危険におちいったではないか。 （以上、現代語訳） 内村鑑三のこの反戦論は、当時の世論である主戦論に対抗したものである。 ==== 七博士の主戦論 ==== 当時の主戦論の例としては、東京帝国大学の七人の大学教授の主戦論が有名である。 この七博士の主戦論の口語訳を紹介しよう。（※ 原文は口調が難しいので、省略。） *口語訳（要約） <div style="border:1px solid #000000;"> ::七博士の主戦論 :ロシアは朝鮮に問題を起こそうとしている。そうする理由は、満州はすでにロシアの勢力範囲にあると（ロシアが）見なしているからだ。 :したがって極東のこの問題を保全するのは、満州を保全することにかかっており、これ（＝戦争のこと）を決断しなければならない。 ::（『東京朝日新聞』1963年6月24日、抜粋および要約） </div> == 条約改正 == *日清戦争の前後 [[ファイル:Mutsu Munemitsu.jpg|thumb|150px|陸奥宗光（むつ むねみつ）]] 日清戦争の直前の1894年に、イギリスとのあいだで、外務大臣の陸奥宗光（むつ むねみつ）の交渉により、治外法権をなくすことに成功。この治外法権の廃止（はいし）は、日本がイギリスと結んだ、 日英通商航海条約（にちえい つうしょう こうかい じょうやく） による。 （1870年代から条約改正のための交渉はしていたが、そのころは、欧米は理由をつけて、受け入れなかった。） 日清戦争で日本が勝利すると、ロシア・フランスなども治外法権をなくすことに同意したが、日本の関税（かんぜい）自主権（じしゅけん）は、みとめなかった。 *日露戦争の後 [[ファイル:Jutaro Komura.jpg|thumb|150px|小村寿太郎（こむら じゅたろう）]] 日露戦争で日本が勝利したことにより日本の国際的な地位が高まると、各国は、関税自主権の改正にも応じるようになり、外務大臣の小村寿太郎（こむら じゅたろう）の各国との交渉により、1911年に日本の関税自主権は回復した。 {{clear}} == 日本の勝利がアジアへ希望をもたらす == この日露戦争での日本の勝利は、黄色人者（日本）が白人の国（ロシア）に勝利した戦争であるので、アジアやアフリカの欧米の植民地にされた地域の人々を勇気づけた。だが、その後の日本は、欧米と同じように植民地支配的な政策を朝鮮などで行っていったことにより、アジア・アフリカの欧米への不満と同様に日本も失望されていくことになる。とはいえ、日露戦争の終戦直後の時点では、アジア・アフリカの植民地支配をされていた民衆は、日本の勝利に喜ぶ者が多かった。 ::のちのインドの独立運動家ネルーは、獄中で書いた著書『父が子に語る世界史』の中で、ネルーの少年時代のころの日露戦争における大日本帝国の勝利が、アジア諸国に独立への希望を与えたことを書いており、ネルー少年自身も感激した。 ::しかし、その後、大日本帝国が欧米列強と同じく、近隣諸国を植民地支配下に置いたことを著書で記述している。日本による侵略の悲惨を最初に味わわされたのは朝鮮であったというふうに記述している。 とはいえ、先ほども述べたように、日露戦争の終戦直後の時点では、日本の勝利に希望をいだくアジアの民衆が多かったのである。 なので、日露戦争のあと、アジアでは独立を目指す政治運動がさかんになる。もっとも、アジア植民地のヨーロッパ諸国からの独立の時期そのものは、ほとんどは第二次世界大戦後の時代になる。 == ※ 範囲外: イギリスは「光栄ある孤立」だったのか？ == 日英同盟までの、ギリスは中立路線・非同盟政策をつらぬいていて、『光栄ある孤立』（：Splendid Isolation）と自賛していた。そして日英同盟の成立により、イギリスの『孤立』は終了した。 しばしば現代日本の歴史評論などで、このことが日英同盟の重要性を説明するのに使われる。あたかも、日本が、イギリスの伝統的な中立政策を終了させるほどの大国かのように、評論される場合がある。 しかし、じつはイギリスが『光栄ある孤立』と初めて言ったのは1896年で、日英同盟が1902成立なので、たったの6年間であり、実は意図的な『孤立』期間はあまり長くないのが真相である。 真相は、イギリスと対立していたドイツによって、イギリスが外交的に孤立する状況に追い詰められてた背景がある。 アフリカ大陸の植民地利権をめぐり、ドイツとイギリスは対立していた。 このころイギリスは、オランダ系のアフリカ植民地国家と戦争をしていた（ボーア戦争など）。そして、ドイツはオランダを支援していたのであった。また、ドイツ自体も、周辺国とさまざまな同盟を結んでいた（いわゆる『ビスマルク政策』。詳しくは高校で習う）。 そのため、イギリスは外交的な孤立に追い込まれた。 そのボーア戦争のさい、イギリス領カナダがイギリスを支持表明する目的で『光栄ある孤立』（：Splendid Isolation）と評したのが、この言葉の由来である。 どうやらイギリスは、あまり意識して非同盟政策をしていたようではないようだ。 [[Category:中学校歴史|にちろせんそう]] 6a8px7h74nvvxemdcbqijxv8426ijkn 0 19398 206104 124068 2022-08-01T07:06:01Z はいかぐら 45848 wikitext text/x-wiki == 韓国 == *[[中学校社会 歴史/韓国併合]] を参照。 == 台湾 == == 満州 == 日露戦争の勝利によって、日本がポーツマス条約で得た利権をもとに、日本は'''南満州鉄道株式会社'''（みなみまんしゅうてつどう かぶしきかいしゃ）を設立した。南満州鉄道株式会社は「'''満鉄'''」（まんてつ）と略される。 満州には、満州経営のため、政府により半官半民の企業の南満州鉄道株式会社（みなみまんしゅうてつどう かぶしきがいしゃ） （ 略称： 満鉄（まんてつ） ）が設立された。 また、満鉄の鉄道の警備などのため、満州に日本軍が置かれた。 なお、この満州鉄道を警備している日本軍は、のちの1919年に「関東軍」（かんとうぐん）と言い改められる。中国の山海関（さんかいかん）より東の位置を「関東」といい、その地域を守備していたので、関東軍（かんとうぐん）と言い改められる。 この戦争の交渉の結果、日本は満州に権益を得ることになった。のちの第二次世界対戦のときに日本軍が満州に滞在している理由は、おおまかな理由は、元をただせば、この日露戦争で得た権益を防衛するために派兵されたからである。 さて、1907年には 日露協約（にちろ きょうやく） で、日本とロシアとの、満州での勢力範囲が決められた。 この満州への日本による権益獲得では、アメリカが日露戦争では資金面などで日本に協力したにも関わらず、ほぼ日本が満州の権益を独占することになり、アメリカは満州に権益を獲得できなかった。アメリカなどは、満州の事業の門戸開放を日本に要求したが、日本は要求を拒んだ。こうしてアメリカの日本への不満が高まり、のちにアメリカと日本とが対立していく原因の一つともなったと考えられる。 [[Category:中学校歴史|にほんとうちかのしよくみんち]] rz5fnfzm5vglnmtbwgq8a074pi0ajxa 0 21972 206061 203449 2022-07-31T14:57:48Z アリウム 68375 wikitext text/x-wiki {{Pathnav|Main Page|小学校・中学校・高等学校の学習|中学校の学習|中学校英語}} [[{{PAGENAME}}]]では、2学年の英語で習得すべき単語について教授します。[[中学校英語/1年]] および [[中学校英語/2年/文法]]も必要に合わせて一緒にお読みください。本ページでは熟語・連語も含みます。 {{発音}} ; 複数形の表記について :山 mountain（s） マウンテン のように、カッコ内に、複数形の表記を書く。 たとえば、「山」の英語の場合、mountains が、複数形のときの表記。 == 単語一覧 == {{節stub}} この章では、1年もしくは2年で学習する単語 (熟語・連語も含む) を紹介します。日本語訳の前にある漢字は、「冠」が冠詞、「動」が動詞、「名」が名詞、「形」が形容詞です。後に「(1)」とあるものは1年生で、「(2)」は2年生で学習する単語です。 === A === {{Wordヘッダ}} {{Word|2=冠|3=1つ(の)(なお、通常訳さない)|1=a|4=ə|5=(1)}} {{Word|2=副・前|3=(副詞)およそ・約・(前置詞)について|1=about|4=əbáut|5=(1)}} {{Word|2=前|3=の上(宙に浮いている物に使う)|1=above|4=(カタカナ)ア'''バ'''ヴ・(発音記号)əbʌ́v|5=(2)}} {{Word|abroad|前置詞|外国 で・に・へ|əbrɔ́ːd}} {{Word|across|前置詞|横断して・横切って|əkrɔ́ːs}} {{Word|actually|副詞|実 に・は|ǽktʃuəli}} {{Word|against|前置詞|〜に対して|əˈɡenst}} |} == まぎらわしい単語 == :働く（はたらく） work ワーク :歩く walk ウォーク == 地形 == :山 mountain（s） マウンテン :川 river リバー :海 sea シー : : : == 熟語 == * 写真をとる take a picture (テイク ア ピクチャー)、 複数形なら take pictures 写真をあらわす名詞には、picture のほかにも photo や photograph がある。 だが、take a photo とは、あまり言わない。もっとも、「take a photo」などでも、間違いではない。 例文 :I took pictures in London. ロンドンで写真を取ってきました。 :I took those pictures in Hawaii. ハワイでこれらの写真を取ってきました。 *（注意深く）見る look at 〜 （ルック アット） 例文 :Look at this picture. （この写真を見て。） == 形容詞 == === 対でおぼえる形容詞 === * おぼえるべき :大きい large（ラージ） ⇔ 小さい small （スモール） :重い heavy （ヘビー） ⇔ 軽い light （ライト） ※ 光（ひかり） light と、軽いは、つづりが同じ。なお、「右」のつづりは right である。 :速い fast （ファースト） ⇔ 遅い slow （スロウ） （※ 参考） 時刻が「早い」は early である。fast は速度や動きが「速い」ようす。 === 性格をあらわす形容詞 === :親切である、親切な kind (カインド) 例文 :He is kind. 彼は親切です。 :恥ずがりやの shy （シャイ） :Bob is shy. ボブは恥ずかしがり屋です。 :正直な、正直である honest （ホネスト） :Bob is honest. ボブは正直者です。 :神経質な nervous （ナーバス） === 感情をあらわす形容詞 === :興奮した excited (エキサイテド) :glad (うれしい) 例文 :I'm glad to meet you. （アイムグラッド トゥ ミートゥユー）あなたに出会えて、うれしいです。 :おどろいた surprised （サプライズド） * 感情を引き起こすもの いっぽう、感情を引き起すもの（出来事や書籍や映像など）については、 :This movie is exciting. （この映画、とっても面白いよ。） とか、 :This is surprising. （これは、びっくりすることだ） とかのように、〜ing の形になります。 形式的には、surprisedは過去形-edと同じ形だ、surprising は進行形と同じ形ですが、しかし、surprised も surprising も形容詞として扱うのが普通です。 excited や exciting など、ほかの感情を表す語でも同様に、形容詞としてあつかうのが一般的。 == 未分類 == :学ぶ learn （ラーン） :言語 language （ランゲージ） :単語 word （ワード） :文化 culture (カルチャー) : :質問 question （クエスチョン） 例文 Do you have a question ? 何か質問がありますか？ :〜は、おもしろがらせる: 〜 be interesting :〜は興味深い: be interesuted in 〜 例文 :This book is very interesting. interesting の主語になるのは、他人をおもしろがらせる物や出来事など。 interestedの主語になるのは、「私」や「あなた」など、おもしろさを受け取った人。 :It sounds interesting. （イット サウンズ インタレスティング） それは、おもしろそうだ。 :That sounds interesting. （ザット サウンズ インタレスティング） それは、おもしろそうだ。 ※ 「That sounds interesting」を「あれは、おもしろそうだ。」（×）とは訳さない。「That sounds interesting.」は慣用表現になっており、「それは、おもしろそうだね」などと訳す。 なお、 sound （サウンド）には、名詞と動詞があり、直訳すると、それぞれ :名詞「sound」は音、音声の意味、 :動詞「sound」は「聞こえる」の意味、 である。 「That sounds interesting.」で「それは、おもしろそうだ。」というような意味の慣用表現に、なっている。 なので、入試や定期テストなどの和訳では、けっして、「それはおもしろと、聞こえる」（×）などと直訳してはいけない。 （※ 範囲外: ）中学の授業や高校入試では誤魔化されているが、interesting は本来、知的な関心を呼ぶという意味での「おもしろい」に使う。だから、たとえばテニスをプレイしてみて「面白かった」とか言う場合、interesting ではなく形容詞 fun （ファン）を使う。 It's fun to play tennis. 「テニスをプレイするのは面白い」 :〜は刺激的: 〜 be exciting :〜は興奮した: 〜 be excited :テレビ番組 TV program :違う different :be different from 〜 「〜とは違う」の意味。 （※ 範囲外: ）実は to や than でも良い。つまり、be different to ～　なども可。from が一般的だが、英国口語でto 、米国で than も使われる（ジーニアス英和およびセンチュリー英和で確認）。作問をする教員は注意のこと。 :グループ group 例文 :I was very excited. わたしは、とっても興奮した。 :That's sounds exciting. それは刺激的だね。 == 前置詞 == :〜にそって along ::along the river 川にそって、川ぞいに :before ビフォア :after アフター 例文 :I go to school after breakfast. 朝食のあと、（わたしは）学校に行きます。 :during デュアリング == 天気 == :天気 weather ウェザー 例文 :It was sunny yesterday. 昨日は晴れでした。 :It is sunny. （今の）天気は晴れです。 :It is sunny now. 今の天気は晴れです。 :It was cloudy yesterday. 昨日はくもりでした。 :It was rainy yesterday. 昨日は雨でした。 :It was snowy yesterday. 昨日は雪です。 * 単語 :晴れ sunny サニー :太陽 sun サン :くもり cloudy クラウディ :雲 cloud クラウド :雨の振ってる日 rainy レイニイ :雨が降る rain レイン :風がビュービュー吹いてる天気 windy ウィンディ :風 wind ウィンド :雪の日の天気 snowy スノウイ :雪 snow スノウ :暑い hot :あったかい warm （ウォーム） :すずしい cool :さむい、つめたい cold （コウルド） ※ 発音注意「オウ」の部分 : （※ 範囲外? ）雨ガッパは raincoat である。雪ダルマは snowman である。 == 星 == :太陽 the Sun ザ・サン :地球 the Earth ジ・アース （※ 発音注意。「ジ」の部分、母音の前なので。） 関連表現 ::地震 earthquake アースクエイク ::地球温暖化 global warming グローバル・ウォーミング globe は球体という意味だが、地球を表す場合もある。なお、手袋 glove （グラブ）と、まちがえないように。 :月 the Moon ザ・ムーン == 地球環境問題など == == 家族 == :いとこ cousin :おじ uncle :おば aunt :娘 daughter :息子 son :孫（男の場合） grandson :パパ dad :ママ mom : == 職業 == === 語形による分類 === * 職業名が 「動詞の原形 ＋ er」 のタイプ :文筆家、作家 writer （ライター） :教師、先生 teacher （ティーチャー） :歌手 singer （シンガー） :運転手 driver （ドライバー） :ダンサー dancer * 職業名が ｰor のタイプ :医者 doctor （ドクター） :俳優 actor （アクター） ::参考: 女性の俳優を actress （アクトレス）ともいう。ただし最近では、男女ともに actor という場合も多い（※　三省堂クラウンの小学5～6年生むけの英語教科書の見本に、そう書いてある）。 * 職業名が ｰist のタイプ :ピアニスト pianist :科学者 scientist （サイエンティスト） :花屋 florist （※ やや中学の範囲外:） pianist は、職業以外にも、単にピアノがうまい人を a good pianist のように言う場合もある。 singer も同様で、歌がうまい人を a good singer と言う場合もある。 詳しくは高校の英文法で、名詞構文（めいし こうぶん）という単元で習う。 He is a good singer. 「彼は歌をうたうのが上手だ。」 は、 He sings well. のように言い換えできる。 singer にかぎらず、音楽やスポーツのplayerでも同様に well で言い換えできる。 === 産業・職種別による分類 === :警察官 police officer （ポリス オフィサー） :消防士 firefighter （ファイア ファイター） :看護婦 nurse （ナース） :医者 doctor （ドクター） :歯医者 dentist （デンティスト） :音楽家 musician （ミュジシャン） :歌手 singer （シンガー） :ダンサー dancer :画家 illustrator （イラストレイター） :事務職、OL、会社員など office worker :弁護士 lawyer （ロウヤー） :公務員 civil servant （シビル・サーバント） :農家 farmer （ファーマー） :大工 carpenter （カーペンター） :技術者 engineer （エンジニーア） ※発音注意 :パイロット pilot :フライト・アテンダント（スチュワーデス） flight attendant :料理人、調理師、コック cook（クック） :俳優 actor （アクター） :女性の俳優 actress （アクトレス） == 売り買い == :おかね money マニー :お客 customer カスタマー :買う buy バイ :値段が高い expensive エクスペンシブ ※形容詞 :スーパーマーケット supermarket :ドラッグストア（薬局） drugstore :本屋 bookstore ブックストア == 工業、テクノロジー == :工場 factory ファクトリー :技術者 engineer エンジニーア :コンピューター computer :クリーン・エネルギー clean energy ※発音: 「クリーンエナジー」 「エネルギー」という読みは、ドイツ語に由来する読み。 英語では、「エナジー」と読む。 :ジェット・エンジン jet engine == 福祉 == :ボランティア volunteer ボランティーア :盲目（もうもく）の、目の見えない人 blind ブラインド :ユニバーサル・デザイン universal design == 戦争と平和 == :戦争 war （ウォー） :平和 peace （ピース） == プロレス == :プロレス professional wrestling プロフェッショナル・レスリング :レスラー wrestler :レスリングをする wrestle レッスル == 観光名所 == === 日本の観光名所 === :鹿苑寺（ろくおんじ）金閣 Rokuonji Temple あるいは単に Kinkakuji :寺 temple テンプル :神社 shrine シュライン :大阪城 Osaka Castle オーサカ・キャッスル :城 castle : === 外国の観光名所 === :世界遺産 ワールド・ヘリテージ 参考 :万里の長城（中国にある） Great Wall グレート・ウォール : == 未分類 == :村 village ビレッジ :村人 villager(s) ビレッジゃ : :一人の子供 child チャイルド :子供達(複数形) children チルドレン :大人 adult(s) アダルト :インド人 Indian インディアン == 他教科で使う用語 == === 算数 === :グラフ graph(s) グラフ :表（ひょう） table(s) テイブル :パーセント percent === 地理 === :アフリカ Africa '''ア'''ーフリカ ※ 「アフリカ」の「ア」の部分にアクセントがあるため、「アー」と伸ばしてるように聞こえる。発音記号では「アフリカ」と伸ばしてないが、このようなアクセントの事情を考え、本書では「アーフリカ」と表記した。 :アジア Asia '''エイジャ''' ※発音注意 :ヨーロッパ Europe '''ユーロプ''' ※発音注意 : : : : [[カテゴリ:中学校英語|にねんたんこ]] [[カテゴリ:英語教育|ちゆうにたんこ]] t8berwxuohvctxvn5631xzdwpqf3dx7 206064 206061 2022-07-31T23:50:43Z アリウム 68375 /* A */ wikitext text/x-wiki {{Pathnav|Main Page|小学校・中学校・高等学校の学習|中学校の学習|中学校英語}} [[{{PAGENAME}}]]では、2学年の英語で習得すべき単語について教授します。[[中学校英語/1年]] および [[中学校英語/2年/文法]]も必要に合わせて一緒にお読みください。本ページでは熟語・連語も含みます。 {{発音}} ; 複数形の表記について :山 mountain（s） マウンテン のように、カッコ内に、複数形の表記を書く。 たとえば、「山」の英語の場合、mountains が、複数形のときの表記。 == 単語一覧 == {{節stub}} この章では、1年もしくは2年で学習する単語 (熟語・連語も含む) を紹介します。日本語訳の前にある漢字は、「冠」が冠詞、「動」が動詞、「名」が名詞、「形」が形容詞です。後に「(1)」とあるものは1年生で、「(2)」は2年生で学習する単語です。 === A === {{Wordヘッダ}} {{Word|2=冠|3=1つ(の)(なお、通常訳さない)|1=a|4=ə|5=(1)}} {{Word|2=副・前|3=(副詞)およそ・約・(前置詞)について|1=about|4=əbáut|5=(1)}} {{Word|2=前|3=の上(宙に浮いている物に使う)|1=above|4=(カタカナ)ア'''バ'''ヴ・(発音記号)əbʌ́v|5=(2)}} {{Word|abroad|前置詞|外国 で・に・へ|əbrɔ́ːd}} {{Word|across|前置詞|横断して・横切って|əkrɔ́ːs}} {{Word|actually|副詞|実 に・は|ǽktʃuəli}} {{Word|adult|名|大人|əˈdəlt}} {{Word|against|前置詞|〜に対して|əˈɡenst}} {{Word|ago|副詞|〜前に|əˈɡō}} {{Word|air conditioner|名|エアコン|érkəndìʃənɚ}} |} == まぎらわしい単語 == :働く（はたらく） work ワーク :歩く walk ウォーク == 地形 == :山 mountain（s） マウンテン :川 river リバー :海 sea シー : : : == 熟語 == * 写真をとる take a picture (テイク ア ピクチャー)、 複数形なら take pictures 写真をあらわす名詞には、picture のほかにも photo や photograph がある。 だが、take a photo とは、あまり言わない。もっとも、「take a photo」などでも、間違いではない。 例文 :I took pictures in London. ロンドンで写真を取ってきました。 :I took those pictures in Hawaii. ハワイでこれらの写真を取ってきました。 *（注意深く）見る look at 〜 （ルック アット） 例文 :Look at this picture. （この写真を見て。） == 形容詞 == === 対でおぼえる形容詞 === * おぼえるべき :大きい large（ラージ） ⇔ 小さい small （スモール） :重い heavy （ヘビー） ⇔ 軽い light （ライト） ※ 光（ひかり） light と、軽いは、つづりが同じ。なお、「右」のつづりは right である。 :速い fast （ファースト） ⇔ 遅い slow （スロウ） （※ 参考） 時刻が「早い」は early である。fast は速度や動きが「速い」ようす。 === 性格をあらわす形容詞 === :親切である、親切な kind (カインド) 例文 :He is kind. 彼は親切です。 :恥ずがりやの shy （シャイ） :Bob is shy. ボブは恥ずかしがり屋です。 :正直な、正直である honest （ホネスト） :Bob is honest. ボブは正直者です。 :神経質な nervous （ナーバス） === 感情をあらわす形容詞 === :興奮した excited (エキサイテド) :glad (うれしい) 例文 :I'm glad to meet you. （アイムグラッド トゥ ミートゥユー）あなたに出会えて、うれしいです。 :おどろいた surprised （サプライズド） * 感情を引き起こすもの いっぽう、感情を引き起すもの（出来事や書籍や映像など）については、 :This movie is exciting. （この映画、とっても面白いよ。） とか、 :This is surprising. （これは、びっくりすることだ） とかのように、〜ing の形になります。 形式的には、surprisedは過去形-edと同じ形だ、surprising は進行形と同じ形ですが、しかし、surprised も surprising も形容詞として扱うのが普通です。 excited や exciting など、ほかの感情を表す語でも同様に、形容詞としてあつかうのが一般的。 == 未分類 == :学ぶ learn （ラーン） :言語 language （ランゲージ） :単語 word （ワード） :文化 culture (カルチャー) : :質問 question （クエスチョン） 例文 Do you have a question ? 何か質問がありますか？ :〜は、おもしろがらせる: 〜 be interesting :〜は興味深い: be interesuted in 〜 例文 :This book is very interesting. interesting の主語になるのは、他人をおもしろがらせる物や出来事など。 interestedの主語になるのは、「私」や「あなた」など、おもしろさを受け取った人。 :It sounds interesting. （イット サウンズ インタレスティング） それは、おもしろそうだ。 :That sounds interesting. （ザット サウンズ インタレスティング） それは、おもしろそうだ。 ※ 「That sounds interesting」を「あれは、おもしろそうだ。」（×）とは訳さない。「That sounds interesting.」は慣用表現になっており、「それは、おもしろそうだね」などと訳す。 なお、 sound （サウンド）には、名詞と動詞があり、直訳すると、それぞれ :名詞「sound」は音、音声の意味、 :動詞「sound」は「聞こえる」の意味、 である。 「That sounds interesting.」で「それは、おもしろそうだ。」というような意味の慣用表現に、なっている。 なので、入試や定期テストなどの和訳では、けっして、「それはおもしろと、聞こえる」（×）などと直訳してはいけない。 （※ 範囲外: ）中学の授業や高校入試では誤魔化されているが、interesting は本来、知的な関心を呼ぶという意味での「おもしろい」に使う。だから、たとえばテニスをプレイしてみて「面白かった」とか言う場合、interesting ではなく形容詞 fun （ファン）を使う。 It's fun to play tennis. 「テニスをプレイするのは面白い」 :〜は刺激的: 〜 be exciting :〜は興奮した: 〜 be excited :テレビ番組 TV program :違う different :be different from 〜 「〜とは違う」の意味。 （※ 範囲外: ）実は to や than でも良い。つまり、be different to ～　なども可。from が一般的だが、英国口語でto 、米国で than も使われる（ジーニアス英和およびセンチュリー英和で確認）。作問をする教員は注意のこと。 :グループ group 例文 :I was very excited. わたしは、とっても興奮した。 :That's sounds exciting. それは刺激的だね。 == 前置詞 == :〜にそって along ::along the river 川にそって、川ぞいに :before ビフォア :after アフター 例文 :I go to school after breakfast. 朝食のあと、（わたしは）学校に行きます。 :during デュアリング == 天気 == :天気 weather ウェザー 例文 :It was sunny yesterday. 昨日は晴れでした。 :It is sunny. （今の）天気は晴れです。 :It is sunny now. 今の天気は晴れです。 :It was cloudy yesterday. 昨日はくもりでした。 :It was rainy yesterday. 昨日は雨でした。 :It was snowy yesterday. 昨日は雪です。 * 単語 :晴れ sunny サニー :太陽 sun サン :くもり cloudy クラウディ :雲 cloud クラウド :雨の振ってる日 rainy レイニイ :雨が降る rain レイン :風がビュービュー吹いてる天気 windy ウィンディ :風 wind ウィンド :雪の日の天気 snowy スノウイ :雪 snow スノウ :暑い hot :あったかい warm （ウォーム） :すずしい cool :さむい、つめたい cold （コウルド） ※ 発音注意「オウ」の部分 : （※ 範囲外? ）雨ガッパは raincoat である。雪ダルマは snowman である。 == 星 == :太陽 the Sun ザ・サン :地球 the Earth ジ・アース （※ 発音注意。「ジ」の部分、母音の前なので。） 関連表現 ::地震 earthquake アースクエイク ::地球温暖化 global warming グローバル・ウォーミング globe は球体という意味だが、地球を表す場合もある。なお、手袋 glove （グラブ）と、まちがえないように。 :月 the Moon ザ・ムーン == 地球環境問題など == == 家族 == :いとこ cousin :おじ uncle :おば aunt :娘 daughter :息子 son :孫（男の場合） grandson :パパ dad :ママ mom : == 職業 == === 語形による分類 === * 職業名が 「動詞の原形 ＋ er」 のタイプ :文筆家、作家 writer （ライター） :教師、先生 teacher （ティーチャー） :歌手 singer （シンガー） :運転手 driver （ドライバー） :ダンサー dancer * 職業名が ｰor のタイプ :医者 doctor （ドクター） :俳優 actor （アクター） ::参考: 女性の俳優を actress （アクトレス）ともいう。ただし最近では、男女ともに actor という場合も多い（※　三省堂クラウンの小学5～6年生むけの英語教科書の見本に、そう書いてある）。 * 職業名が ｰist のタイプ :ピアニスト pianist :科学者 scientist （サイエンティスト） :花屋 florist （※ やや中学の範囲外:） pianist は、職業以外にも、単にピアノがうまい人を a good pianist のように言う場合もある。 singer も同様で、歌がうまい人を a good singer と言う場合もある。 詳しくは高校の英文法で、名詞構文（めいし こうぶん）という単元で習う。 He is a good singer. 「彼は歌をうたうのが上手だ。」 は、 He sings well. のように言い換えできる。 singer にかぎらず、音楽やスポーツのplayerでも同様に well で言い換えできる。 === 産業・職種別による分類 === :警察官 police officer （ポリス オフィサー） :消防士 firefighter （ファイア ファイター） :看護婦 nurse （ナース） :医者 doctor （ドクター） :歯医者 dentist （デンティスト） :音楽家 musician （ミュジシャン） :歌手 singer （シンガー） :ダンサー dancer :画家 illustrator （イラストレイター） :事務職、OL、会社員など office worker :弁護士 lawyer （ロウヤー） :公務員 civil servant （シビル・サーバント） :農家 farmer （ファーマー） :大工 carpenter （カーペンター） :技術者 engineer （エンジニーア） ※発音注意 :パイロット pilot :フライト・アテンダント（スチュワーデス） flight attendant :料理人、調理師、コック cook（クック） :俳優 actor （アクター） :女性の俳優 actress （アクトレス） == 売り買い == :おかね money マニー :お客 customer カスタマー :買う buy バイ :値段が高い expensive エクスペンシブ ※形容詞 :スーパーマーケット supermarket :ドラッグストア（薬局） drugstore :本屋 bookstore ブックストア == 工業、テクノロジー == :工場 factory ファクトリー :技術者 engineer エンジニーア :コンピューター computer :クリーン・エネルギー clean energy ※発音: 「クリーンエナジー」 「エネルギー」という読みは、ドイツ語に由来する読み。 英語では、「エナジー」と読む。 :ジェット・エンジン jet engine == 福祉 == :ボランティア volunteer ボランティーア :盲目（もうもく）の、目の見えない人 blind ブラインド :ユニバーサル・デザイン universal design == 戦争と平和 == :戦争 war （ウォー） :平和 peace （ピース） == プロレス == :プロレス professional wrestling プロフェッショナル・レスリング :レスラー wrestler :レスリングをする wrestle レッスル == 観光名所 == === 日本の観光名所 === :鹿苑寺（ろくおんじ）金閣 Rokuonji Temple あるいは単に Kinkakuji :寺 temple テンプル :神社 shrine シュライン :大阪城 Osaka Castle オーサカ・キャッスル :城 castle : === 外国の観光名所 === :世界遺産 ワールド・ヘリテージ 参考 :万里の長城（中国にある） Great Wall グレート・ウォール : == 未分類 == :村 village ビレッジ :村人 villager(s) ビレッジゃ : :一人の子供 child チャイルド :子供達(複数形) children チルドレン :大人 adult(s) アダルト :インド人 Indian インディアン == 他教科で使う用語 == === 算数 === :グラフ graph(s) グラフ :表（ひょう） table(s) テイブル :パーセント percent === 地理 === :アフリカ Africa '''ア'''ーフリカ ※ 「アフリカ」の「ア」の部分にアクセントがあるため、「アー」と伸ばしてるように聞こえる。発音記号では「アフリカ」と伸ばしてないが、このようなアクセントの事情を考え、本書では「アーフリカ」と表記した。 :アジア Asia '''エイジャ''' ※発音注意 :ヨーロッパ Europe '''ユーロプ''' ※発音注意 : : : : [[カテゴリ:中学校英語|にねんたんこ]] [[カテゴリ:英語教育|ちゆうにたんこ]] ge9rlrb3beirfykwxhes0ja438clja9 206066 206064 2022-08-01T00:14:09Z アリウム 68375 wikitext text/x-wiki {{Pathnav|Main Page|小学校・中学校・高等学校の学習|中学校の学習|中学校英語}} [[{{PAGENAME}}]]では、2学年の英語で習得すべき単語について教授します。[[中学校英語/1年]] および [[中学校英語/2年/文法]]も必要に合わせて一緒にお読みください。本ページでは熟語・連語も含みます。 {{発音}} ; 複数形の表記について :山 mountain（s） マウンテン のように、カッコ内に、複数形の表記を書く。 たとえば、「山」の英語の場合、mountains が、複数形のときの表記。 == 単語一覧 == {{節stub}} この章では、1年もしくは2年で学習する単語 (熟語・連語も含む) を紹介します。日本語訳の前にある漢字は、「冠」が冠詞、「動」が動詞、「名」が名詞、「形」が形容詞です。後に「(1)」とあるものは1年生で、「(2)」は2年生で学習する単語です。 === A === {{Wordヘッダ}} {{Word|2=冠|3=1つ(の)(なお、通常訳さない)|1=a|4=ə|5=(1)}} {{Word|2=副・前|3=(副詞)およそ・約・(前置詞)について|1=about|4=əbáut|5=(1)}} {{Word|2=前|3=の上(宙に浮いている物に使う)|1=above|4=(カタカナ)ア'''バ'''ヴ・(発音記号)əbʌ́v|5=(2)}} {{Word|abroad|前置詞|外国 で・に・へ|əbrɔ́ːd}} {{Word|across|前置詞|横断して・横切って|əkrɔ́ːs}} {{Word|actually|副詞|実 に・は|ǽktʃuəli}} {{Word|adult|名|大人|əˈdəlt}} {{Word|against|前置詞|〜に対して|əˈɡenst}} {{Word|ago|副詞|〜前に|əˈɡō}} {{Word|air conditioner|名|エアコン|érkəndìʃənɚ}} {{Word|airline|名|航空会社|éɚlɑìn}} {{Word|alarm|名|警報装置、警報器|əlɑ'ːrm}} {{Word|alive|形|生きている|əláiv}} {{Word|always|副詞|いつも|ɔ'ːlweiz}} {{Word|amazing|形|驚くべき、びっくりするような|əméiziŋ}} {{Word|among|前置詞|〜の間に(で)|əmʌ'ŋ}} {{Word|ancient|形|古代の|éinʃənt}} {{Word|angel|名|天使|éindʒəl}} {{Word|angry|形|怒っている|ǽŋgri}} {{Word|announcement|名|アナウンス|ǽŋgri}} |} == まぎらわしい単語 == :働く（はたらく） work ワーク :歩く walk ウォーク == 地形 == :山 mountain（s） マウンテン :川 river リバー :海 sea シー : : : == 熟語 == * 写真をとる take a picture (テイク ア ピクチャー)、 複数形なら take pictures 写真をあらわす名詞には、picture のほかにも photo や photograph がある。 だが、take a photo とは、あまり言わない。もっとも、「take a photo」などでも、間違いではない。 例文 :I took pictures in London. ロンドンで写真を取ってきました。 :I took those pictures in Hawaii. ハワイでこれらの写真を取ってきました。 *（注意深く）見る look at 〜 （ルック アット） 例文 :Look at this picture. （この写真を見て。） == 形容詞 == === 対でおぼえる形容詞 === * おぼえるべき :大きい large（ラージ） ⇔ 小さい small （スモール） :重い heavy （ヘビー） ⇔ 軽い light （ライト） ※ 光（ひかり） light と、軽いは、つづりが同じ。なお、「右」のつづりは right である。 :速い fast （ファースト） ⇔ 遅い slow （スロウ） （※ 参考） 時刻が「早い」は early である。fast は速度や動きが「速い」ようす。 === 性格をあらわす形容詞 === :親切である、親切な kind (カインド) 例文 :He is kind. 彼は親切です。 :恥ずがりやの shy （シャイ） :Bob is shy. ボブは恥ずかしがり屋です。 :正直な、正直である honest （ホネスト） :Bob is honest. ボブは正直者です。 :神経質な nervous （ナーバス） === 感情をあらわす形容詞 === :興奮した excited (エキサイテド) :glad (うれしい) 例文 :I'm glad to meet you. （アイムグラッド トゥ ミートゥユー）あなたに出会えて、うれしいです。 :おどろいた surprised （サプライズド） * 感情を引き起こすもの いっぽう、感情を引き起すもの（出来事や書籍や映像など）については、 :This movie is exciting. （この映画、とっても面白いよ。） とか、 :This is surprising. （これは、びっくりすることだ） とかのように、〜ing の形になります。 形式的には、surprisedは過去形-edと同じ形だ、surprising は進行形と同じ形ですが、しかし、surprised も surprising も形容詞として扱うのが普通です。 excited や exciting など、ほかの感情を表す語でも同様に、形容詞としてあつかうのが一般的。 == 未分類 == :学ぶ learn （ラーン） :言語 language （ランゲージ） :単語 word （ワード） :文化 culture (カルチャー) : :質問 question （クエスチョン） 例文 Do you have a question ? 何か質問がありますか？ :〜は、おもしろがらせる: 〜 be interesting :〜は興味深い: be interesuted in 〜 例文 :This book is very interesting. interesting の主語になるのは、他人をおもしろがらせる物や出来事など。 interestedの主語になるのは、「私」や「あなた」など、おもしろさを受け取った人。 :It sounds interesting. （イット サウンズ インタレスティング） それは、おもしろそうだ。 :That sounds interesting. （ザット サウンズ インタレスティング） それは、おもしろそうだ。 ※ 「That sounds interesting」を「あれは、おもしろそうだ。」（×）とは訳さない。「That sounds interesting.」は慣用表現になっており、「それは、おもしろそうだね」などと訳す。 なお、 sound （サウンド）には、名詞と動詞があり、直訳すると、それぞれ :名詞「sound」は音、音声の意味、 :動詞「sound」は「聞こえる」の意味、 である。 「That sounds interesting.」で「それは、おもしろそうだ。」というような意味の慣用表現に、なっている。 なので、入試や定期テストなどの和訳では、けっして、「それはおもしろと、聞こえる」（×）などと直訳してはいけない。 （※ 範囲外: ）中学の授業や高校入試では誤魔化されているが、interesting は本来、知的な関心を呼ぶという意味での「おもしろい」に使う。だから、たとえばテニスをプレイしてみて「面白かった」とか言う場合、interesting ではなく形容詞 fun （ファン）を使う。 It's fun to play tennis. 「テニスをプレイするのは面白い」 :〜は刺激的: 〜 be exciting :〜は興奮した: 〜 be excited :テレビ番組 TV program :違う different :be different from 〜 「〜とは違う」の意味。 （※ 範囲外: ）実は to や than でも良い。つまり、be different to ～　なども可。from が一般的だが、英国口語でto 、米国で than も使われる（ジーニアス英和およびセンチュリー英和で確認）。作問をする教員は注意のこと。 :グループ group 例文 :I was very excited. わたしは、とっても興奮した。 :That's sounds exciting. それは刺激的だね。 == 前置詞 == :〜にそって along ::along the river 川にそって、川ぞいに :before ビフォア :after アフター 例文 :I go to school after breakfast. 朝食のあと、（わたしは）学校に行きます。 :during デュアリング == 天気 == :天気 weather ウェザー 例文 :It was sunny yesterday. 昨日は晴れでした。 :It is sunny. （今の）天気は晴れです。 :It is sunny now. 今の天気は晴れです。 :It was cloudy yesterday. 昨日はくもりでした。 :It was rainy yesterday. 昨日は雨でした。 :It was snowy yesterday. 昨日は雪です。 * 単語 :晴れ sunny サニー :太陽 sun サン :くもり cloudy クラウディ :雲 cloud クラウド :雨の振ってる日 rainy レイニイ :雨が降る rain レイン :風がビュービュー吹いてる天気 windy ウィンディ :風 wind ウィンド :雪の日の天気 snowy スノウイ :雪 snow スノウ :暑い hot :あったかい warm （ウォーム） :すずしい cool :さむい、つめたい cold （コウルド） ※ 発音注意「オウ」の部分 : （※ 範囲外? ）雨ガッパは raincoat である。雪ダルマは snowman である。 == 星 == :太陽 the Sun ザ・サン :地球 the Earth ジ・アース （※ 発音注意。「ジ」の部分、母音の前なので。） 関連表現 ::地震 earthquake アースクエイク ::地球温暖化 global warming グローバル・ウォーミング globe は球体という意味だが、地球を表す場合もある。なお、手袋 glove （グラブ）と、まちがえないように。 :月 the Moon ザ・ムーン == 地球環境問題など == == 家族 == :いとこ cousin :おじ uncle :おば aunt :娘 daughter :息子 son :孫（男の場合） grandson :パパ dad :ママ mom : == 職業 == === 語形による分類 === * 職業名が 「動詞の原形 ＋ er」 のタイプ :文筆家、作家 writer （ライター） :教師、先生 teacher （ティーチャー） :歌手 singer （シンガー） :運転手 driver （ドライバー） :ダンサー dancer * 職業名が ｰor のタイプ :医者 doctor （ドクター） :俳優 actor （アクター） ::参考: 女性の俳優を actress （アクトレス）ともいう。ただし最近では、男女ともに actor という場合も多い（※　三省堂クラウンの小学5～6年生むけの英語教科書の見本に、そう書いてある）。 * 職業名が ｰist のタイプ :ピアニスト pianist :科学者 scientist （サイエンティスト） :花屋 florist （※ やや中学の範囲外:） pianist は、職業以外にも、単にピアノがうまい人を a good pianist のように言う場合もある。 singer も同様で、歌がうまい人を a good singer と言う場合もある。 詳しくは高校の英文法で、名詞構文（めいし こうぶん）という単元で習う。 He is a good singer. 「彼は歌をうたうのが上手だ。」 は、 He sings well. のように言い換えできる。 singer にかぎらず、音楽やスポーツのplayerでも同様に well で言い換えできる。 === 産業・職種別による分類 === :警察官 police officer （ポリス オフィサー） :消防士 firefighter （ファイア ファイター） :看護婦 nurse （ナース） :医者 doctor （ドクター） :歯医者 dentist （デンティスト） :音楽家 musician （ミュジシャン） :歌手 singer （シンガー） :ダンサー dancer :画家 illustrator （イラストレイター） :事務職、OL、会社員など office worker :弁護士 lawyer （ロウヤー） :公務員 civil servant （シビル・サーバント） :農家 farmer （ファーマー） :大工 carpenter （カーペンター） :技術者 engineer （エンジニーア） ※発音注意 :パイロット pilot :フライト・アテンダント（スチュワーデス） flight attendant :料理人、調理師、コック cook（クック） :俳優 actor （アクター） :女性の俳優 actress （アクトレス） == 売り買い == :おかね money マニー :お客 customer カスタマー :買う buy バイ :値段が高い expensive エクスペンシブ ※形容詞 :スーパーマーケット supermarket :ドラッグストア（薬局） drugstore :本屋 bookstore ブックストア == 工業、テクノロジー == :工場 factory ファクトリー :技術者 engineer エンジニーア :コンピューター computer :クリーン・エネルギー clean energy ※発音: 「クリーンエナジー」 「エネルギー」という読みは、ドイツ語に由来する読み。 英語では、「エナジー」と読む。 :ジェット・エンジン jet engine == 福祉 == :ボランティア volunteer ボランティーア :盲目（もうもく）の、目の見えない人 blind ブラインド :ユニバーサル・デザイン universal design == 戦争と平和 == :戦争 war （ウォー） :平和 peace （ピース） == プロレス == :プロレス professional wrestling プロフェッショナル・レスリング :レスラー wrestler :レスリングをする wrestle レッスル == 観光名所 == === 日本の観光名所 === :鹿苑寺（ろくおんじ）金閣 Rokuonji Temple あるいは単に Kinkakuji :寺 temple テンプル :神社 shrine シュライン :大阪城 Osaka Castle オーサカ・キャッスル :城 castle : === 外国の観光名所 === :世界遺産 ワールド・ヘリテージ 参考 :万里の長城（中国にある） Great Wall グレート・ウォール : == 未分類 == :村 village ビレッジ :村人 villager(s) ビレッジゃ : :一人の子供 child チャイルド :子供達(複数形) children チルドレン :大人 adult(s) アダルト :インド人 Indian インディアン == 他教科で使う用語 == === 算数 === :グラフ graph(s) グラフ :表（ひょう） table(s) テイブル :パーセント percent === 地理 === :アフリカ Africa '''ア'''ーフリカ ※ 「アフリカ」の「ア」の部分にアクセントがあるため、「アー」と伸ばしてるように聞こえる。発音記号では「アフリカ」と伸ばしてないが、このようなアクセントの事情を考え、本書では「アーフリカ」と表記した。 :アジア Asia '''エイジャ''' ※発音注意 :ヨーロッパ Europe '''ユーロプ''' ※発音注意 : : : : [[カテゴリ:中学校英語|にねんたんこ]] [[カテゴリ:英語教育|ちゆうにたんこ]] ib0yejmi42zpva37myhsdefivyz5ct8 0 25403 206056 136287 2022-07-31T13:16:12Z 椎楽 32225 wikitext text/x-wiki {{Nav}} == 高校「倫理」から哲学・倫理学へ == 普通の検定教科書では参考文献は省かれている。本来、参考文献のない書籍というものはあまり信用のおけるものではない。推測するほかないのだが、簡潔であることを旨とする検定教科書では膨大になることが予想される参考文献はカットされているのだろう。また、教科書の内容は通説であり、ほぼ論争的なものではないというのも理由として挙げられよう。その分、資料集などで参考文献に当たるものを紹介することで補っているといえる。 ここであえて「倫理」教科書の参考文献を挙げる理由は以下のとおりである。 #信頼性の向上。どうしてもオンライン上の文献、とくにウィキ形式のものはだれでも編集できるという特徴から信頼性に疑問を持たれがちである。信頼性はどのような文献を元にしているかというのも大きい。そのため、ここでは参考文献を挙げることにする。 #これを読んでいる高校生ないし高校「倫理」にちょっとでも関心を持った大学生・社会人が「倫理」から、さらにもう一歩進めて哲学や倫理学を学ぼうとする際の手がかりとして。 なお、一部の文献にはコメントもつけている。学習者の参考になれば幸いである。 == 全般 == === 検定高校教科書・参考書 === * 『高等学校改訂版　倫理』、第一学習社、1993年(1991年検定) * 小寺聡編『もういちど読む　山川　倫理』、山川出版社、2011年 * 濱井修監修・小寺聡編『第2版　倫理用語集』、山川出版社、2019年 * 『新訂第2版　倫理資料集　ソフィエ～智を学び夢を育む～』、清水書院、2016年 === 辞典・用語集 === * 栗田賢三・古在由重編『岩波　哲学小事典』、岩波書店、1979年 :価格・サイズ共に手ごろであり、ちょっとした調べ物にはよい。ただ古すぎる。『'''岩波哲学・思想事典'''』(廣松渉編、1998年)は一般向けにはボリュームがありすぎるのが難点。15000円というのは大学院生でないと手も出にくいだろう。価格とボリュームのバランスがよく、現代思想を追っているものとしては『'''新版 哲学・論理用語辞典'''』(思想の科学研究会編、三一書房、2012年)などが妥当か。 * 尾関周二他編『環境思想キーワード』、青木書店、2005年 :環境思想や環境倫理学に特化した(珍しい)用語集だが、通り一遍の哲学者たちの思想はおさえられているので、高校「倫理」から哲学・倫理学への入門用用語集としてもお手頃。入手はやや難しい。 === 哲学史 === * ヨースタイン・ゴルテル著『ソフィーの世界　哲学者からの不思議な手紙』(須田朗監修/池田香代子訳)、NHK出版、1995年 :ミステリー要素を含むファンタジーの形式をとる哲学史入門書。ボリュームはあるが、小説感覚で読める。範囲も高校「倫理」と重なる。 * 久保陽一・河合淳編著『原典による哲学の歴史』、公論社、2002年 :大学の教科書。原典の重要な箇所をピックアップしている。少々古く、また社会思想がやや弱いという欠点もあるが、『'''哲学　原典資料集'''』(山本巍他編著、東京大学出版、1993年)もおススメ。 * 内田勝利他編著『哲学の歴史』12巻-別巻、中央公論新社、2007-2008年 :どちらかというと教師向け。まずは気になったところだけを読むことから始めるといい。 * 竹田青嗣・西研編著『初めての哲学史　強く深く考えるために』、有斐閣アルマ、1998年 :大学の教養科目用テキスト。良くも悪くも編著者である竹田・西両氏の個性が強い解説となっている。 == 青年期の課題と人間としての在り方生き方 == == 人間としての自覚 == === ギリシャ哲学 === *ディオゲネス・ラエルティオス著『ギリシア哲学者列伝』(加来彰俊訳)、岩波文庫（上中下）、1984年・1989年・1994年 ==== ソクラテス以前の哲学者 ==== ==== ソクラテス、プラトン ==== *プラトン著『ソクラテスの弁明』(納富信留訳)、光文社古典新訳文庫、2012年 ==== アリストテレス ==== *『形而上学』(井隆訳)、岩波文庫、1959年 ==== ヘレニズムの思想 ==== == 国際社会に生きる日本人としての自覚 == == 現代に生きる人間の倫理と思想 == == 現代と倫理 == [[Category:高等学校教育|りんりさんこうふんけん]] [[Category:社会科教育|りんりさんこうふんけん]] [[Category:高等学校倫理|*]] [[Category:哲学|てつかくさんこうふんけんにゆうもんしゆう]] [[Category:倫理学|りんりかくさんこうふんけんにゆうもんしゆう]] 798id4kzqy3i6p50cn0y1sy42dooas4 206057 206056 2022-07-31T13:19:26Z 椎楽 32225 /* 人間としての自覚 */ wikitext text/x-wiki {{Nav}} == 高校「倫理」から哲学・倫理学へ == 普通の検定教科書では参考文献は省かれている。本来、参考文献のない書籍というものはあまり信用のおけるものではない。推測するほかないのだが、簡潔であることを旨とする検定教科書では膨大になることが予想される参考文献はカットされているのだろう。また、教科書の内容は通説であり、ほぼ論争的なものではないというのも理由として挙げられよう。その分、資料集などで参考文献に当たるものを紹介することで補っているといえる。 ここであえて「倫理」教科書の参考文献を挙げる理由は以下のとおりである。 #信頼性の向上。どうしてもオンライン上の文献、とくにウィキ形式のものはだれでも編集できるという特徴から信頼性に疑問を持たれがちである。信頼性はどのような文献を元にしているかというのも大きい。そのため、ここでは参考文献を挙げることにする。 #これを読んでいる高校生ないし高校「倫理」にちょっとでも関心を持った大学生・社会人が「倫理」から、さらにもう一歩進めて哲学や倫理学を学ぼうとする際の手がかりとして。 なお、一部の文献にはコメントもつけている。学習者の参考になれば幸いである。 == 全般 == === 検定高校教科書・参考書 === * 『高等学校改訂版　倫理』、第一学習社、1993年(1991年検定) * 小寺聡編『もういちど読む　山川　倫理』、山川出版社、2011年 * 濱井修監修・小寺聡編『第2版　倫理用語集』、山川出版社、2019年 * 『新訂第2版　倫理資料集　ソフィエ～智を学び夢を育む～』、清水書院、2016年 === 辞典・用語集 === * 栗田賢三・古在由重編『岩波　哲学小事典』、岩波書店、1979年 :価格・サイズ共に手ごろであり、ちょっとした調べ物にはよい。ただ古すぎる。『'''岩波哲学・思想事典'''』(廣松渉編、1998年)は一般向けにはボリュームがありすぎるのが難点。15000円というのは大学院生でないと手も出にくいだろう。価格とボリュームのバランスがよく、現代思想を追っているものとしては『'''新版 哲学・論理用語辞典'''』(思想の科学研究会編、三一書房、2012年)などが妥当か。 * 尾関周二他編『環境思想キーワード』、青木書店、2005年 :環境思想や環境倫理学に特化した(珍しい)用語集だが、通り一遍の哲学者たちの思想はおさえられているので、高校「倫理」から哲学・倫理学への入門用用語集としてもお手頃。入手はやや難しい。 === 哲学史 === * ヨースタイン・ゴルテル著『ソフィーの世界　哲学者からの不思議な手紙』(須田朗監修/池田香代子訳)、NHK出版、1995年 :ミステリー要素を含むファンタジーの形式をとる哲学史入門書。ボリュームはあるが、小説感覚で読める。範囲も高校「倫理」と重なる。 * 久保陽一・河合淳編著『原典による哲学の歴史』、公論社、2002年 :大学の教科書。原典の重要な箇所をピックアップしている。少々古く、また社会思想がやや弱いという欠点もあるが、『'''哲学　原典資料集'''』(山本巍他編著、東京大学出版、1993年)もおススメ。 * 内田勝利他編著『哲学の歴史』12巻-別巻、中央公論新社、2007-2008年 :どちらかというと教師向け。まずは気になったところだけを読むことから始めるといい。 * 竹田青嗣・西研編著『初めての哲学史　強く深く考えるために』、有斐閣アルマ、1998年 :大学の教養科目用テキスト。良くも悪くも編著者である竹田・西両氏の個性が強い解説となっている。 == 青年期の課題と人間としての在り方生き方 == == 人間としての自覚 == === 古代ギリシャ哲学 === *ディオゲネス・ラエルティオス著『ギリシア哲学者列伝』(加来彰俊訳)、岩波文庫（上中下）、1984年・1989年・1994年 ==== ソクラテス以前の哲学者 ==== ==== ソクラテス、プラトン ==== *プラトン著『ソクラテスの弁明』(納富信留訳)、光文社古典新訳文庫、2012年 ==== アリストテレス ==== *『形而上学』(井隆訳)、岩波文庫、1959年 ==== ヘレニズムの思想 ==== === 諸子百家の思想 === ==== 儒家 ==== ==== 道家 ==== ==== 諸子 ==== === 三大宗教のはじまり === ==== 仏教 ==== ==== キリスト教 ==== == 国際社会に生きる日本人としての自覚 == == 現代に生きる人間の倫理と思想 == == 現代と倫理 == [[Category:高等学校教育|りんりさんこうふんけん]] [[Category:社会科教育|りんりさんこうふんけん]] [[Category:高等学校倫理|*]] [[Category:哲学|てつかくさんこうふんけんにゆうもんしゆう]] [[Category:倫理学|りんりかくさんこうふんけんにゆうもんしゆう]] slvu5e05outra71d92ufwy4bhjqgun8 0 26517 206059 148388 2022-07-31T14:33:10Z CommonsDelinker 786 「Artist's_impression_dwarf_planet_Eris_(1).jpg」 を 「Artist's_impression_dwarf_planet_Eris.jpg」 に差し替え（[[commons:User:CommonsDelinker|CommonsDelinker]]による。理由：[[:c:COM:Duplicate|Duplicate]]: Exact or scaled-down duplicate: [[:c::File:Artist's impression dwarf wikitext text/x-wiki {{Pathnav|Main Page|自然科学|天文学|太陽系}} {{Wikipedia}} '''準惑星'''は惑星のような球形だがその軌道付近に他の天体が排除されていない天体である。惑星は定義上、その軌道上に同サイズのものが存在しない天体であるので、2006年より冥王星は惑星から除外された。 2019年11月現在、5個が惑星として定義されている。 == ケレス == [[ファイル:Color global view of Ceres - Oxo and Haulani craters.png|thumb|right|220px|探査機ドーンの撮影したケレス。]] '''ケレス'''は火星と木星の間にある唯一の準惑星である。準惑星・小惑星で初めて発見された天体でもある。 半径は470km。質量は9.4&times;10²⁰kg。 表面積は2.8&times;10⁶km²であり、日本の面積の約7倍に相当する。 2007年にはNASAが探査機ドーンを打ち上げ、燃料枯渇により2018年に運用を終了した。現在はケレス周辺を衛星として回っている。 == 冥王星 == [[ファイル:Pluto by LORRI and Ralph, 13 July 2015.jpg|thumb|right|220px|ニュー・ホライズンズによる冥王星の写真。]] '''冥王星'''はかつては太陽系の第9惑星だと考えられていた準惑星である。 半径は1200km。質量は1.3&times;10²²kgである。 衛星を5つ持つが、そのうちとりわけ'''カロン'''が大きい。カロンは半径が冥王星の半分以上あるので二重小惑星と捉えることもできる。 冥王星の探査は2006年、ニュー・ホライズンズの打ち上げで9年後の2015年に冥王星に接近した。 == ハウメア == [[ファイル:2003EL61art.jpg|thumb|right|220px|ハウメアとその衛星の想像図。]] '''ハウメア'''は準惑星の1つである。発見は2003年と比較的に最近である。 正確な球のような形ではなく楕円体なので半径は決められないが長径は約1960km。質量は4.0&times;10²¹kg。 衛星を2つ持ち、更に環をも持つ準惑星である。 == マケマケ == [[ファイル:2005FY9art.jpg|thumb|right|220px|マケマケの想像図]] '''マケマケ'''は準惑星の1つである。こちらも2005年発見と比較的に最近である。 半径は750km。質量は4.0&times;10²¹kg以下と見積もられている。 == エリス == [[ファイル:Artist's impression dwarf planet Eris.jpg|thumb|right|220px|エリスの想像図。]] '''エリス'''は準惑星の1つである。 半径は約1160km。質量は1.7&times;10²²kg。 {{デフォルトソート:しゆんわくせい}} [[Category:太陽系]] dwm2he8bgeea13rntulxsjghggtsr9h 0 26659 206070 205969 2022-08-01T01:46:57Z Ef3 694 /*演算子オーバーロード */ Kotlinでは、演算子はメソッド形式の別名を持ちます。 例えば、<code>a + b</code> は <code>a.plus(b)</code> とも書けます。 この plus メソッドを再定義すると、演算子オーバーロードができます<ref>[https://kotlinlang.org/docs/operator-overloading.html Operator overloading]</ref>。 wikitext text/x-wiki {{Wikipedia}} {{Pathnav|メインページ|工学|情報技術|プログラミング}} ---- Kotlin（コトリン）は、クロスプラットフォームで、静的型付けな、[[W:型推論|型推論]]を用いることが出来る[[W:汎用プログラミング言語|汎用プログラミング言語]]です。 Kotlinは、関数型プログラミング・クラス指向のオブジェクト指向型プログラミング・シェネリックプログラミングなど、複数のプログラミングパラダイムをサポートする[[W:マルチパラダイム言語|マルチパラダイム言語]]です。 Kotlinは、Javaと完全に相互運用できるように設計されており、JVM版のKotlinの標準ライブラリはJavaクラスライブラリを利用しているが、型推論によってより簡潔な構文にすることが可能です。 Kotlinは、主にJVMをターゲットとしているが、JavaScript（Reactを用いたフロントエンドのWebアプリケーションなど）やLLVMによるネイティブコード（Androidアプリとビジネスロジックを共有するiOSネイティブアプリなど）にもコンパイルできます。 言語開発のコストは、[[w:JetBrains|JetBrains]]が負担し、Kotlin FoundationがKotlin™商標を守っています。 == 目次 == * [[Kotlin/インストール方法]] ※ 長いので実行方法とは別の単元にします * [[Kotlin/実行方法]] * [[Kotlin/関数]] * Kotlin/ == 未分類の下書き == ※ 完成次第、サブページに移動してください。 ;予備知識 現状の版では、読者に予備知識として、ある程度のC言語やJavaScriptの知識を想定しています。もし読者がこれら予備知識の言語にそこまで詳しくなければ、先に『[[C言語]]』および『[[JavaScript]]』をお読みください。 なお、Javaの知識はあるにこしたことないですが、必ずしも必要ではありません。 Javaなどにある「クラス」を Kotlin でもサポートしており、Javaと同様にKotlin でも class 宣言でクラスを作成できます。しかし、読者がまったくクラスについて知らなくても、Kotlin による開発を比較的に簡単に始めることが可能です。 === 文法の概要 === ==== hello world ==== Kotlinの文法は、Javaと大きく異なります。 以下に示すのはKotlinでの[[w:ハローワールド]]のコードです。 ;[https://pl.kotl.in/BIeRKX0rd Hello.kt]:<syntaxhighlight lang="Kotlin"> fun main(args: Array<String>) { println("Hello, World!") } </syntaxhighlight> このケースについてはさらに短くでき、<ref group="注">Kotlin 1.3以降: クラスの中にないmain関数はargs変数を宣言しなくても良い。</ref><ref name="13later">https://kotlinlang.org/docs/reference/whatsnew13.html</ref> ;[https://pl.kotl.in/3ztubYDuP ShortHello.kt]:<syntaxhighlight lang="Kotlin"> fun main() { println("Hello, World!") } </syntaxhighlight> と書いてもよい。 {{code|fun}}というのは、関数を定義するキーワードです。JavaScriptで言う{{code|function}}です。 printlnというのは、コマンド画面などに、文字表示をする組み込み関数のことです。<ref name="api:println">https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.io/println.html</ref> printlnは、文末に改行が自動で入ます。<ref name="api:println" /> JavaやC言語などと違い、文末にセミコロン ({{code|;}}) は必要ありません。 ==== その他の例 ==== まずはコード例を見てみましょう。 ;[https://pl.kotl.in/rXFKwaSIB コード例]:<syntaxhighlight lang="Kotlin"> fun main() { var mes : String // (1) mes = "テストです" println(mes) var num : Int // (2) num = 5 println(num * 3) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> テストです 15 </syntaxhighlight> ;解説 変数を宣言するときは、 var 変数名 : 型名 という書式で宣言します。 なお、Kotlin の型名はJava同様、大文字のキャメルケースであるのが通例です。 上記のコードの (1) では、mesという{{code|kotlin.String}}型の変数を、 (2) では、numという{{code|kotlin.Int}}型の変数を宣言しています。 {{code|val}}を用いることもできるが、{{code|val}}で宣言された場合は再度代入することができません。 :var は variable （変数）の略。 :val は value （値）の略。 === 文字表示と標準入出力の概要 === ==== 文字の連結 ==== println関数などで2個以上の文字列を連結したい場合は、<code>+</code>演算子でつなぎあわせます。 ;[https://pl.kotl.in/Qp2SYtHn3 コード例]:<syntaxhighlight lang="Kotlin"> fun main() { var mes : String mes = "テストです" println(mes) var num : Int num = 5 println(num * 3) println(mes + num) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> テストです 15 テストです5 </syntaxhighlight> ※ 変数 num 自体の中身は15ではなく5。 式が要求されている箇所で、{{code|kotlin.String}}'''でない'''型の変数に{{code|kotlin.String}}型の変数を、あるいは{{code|kotlin.String}}型の変数に{{code|kotlin.String}}'''でない'''型の変数を足すと、自動的に{{code|kotlin.String}}型でない変数をレシーバーとして{{code|toString()}}が暗黙的に呼ばれ<ref name="api:any_q_toString">https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/to-string.html</ref>、{{code|kotlin.String}}型同士の演算となります。 ==== 二重引用符と一重引用符 ==== println("出したい文字") などの文字列をくくる引用符は、kotlinでは二重引用符（ダブル クォーテーション、{{code|"}}）のみが使用できます。 Javaと同じく、{{code|"a"}}は{{code|a}}という中身の{{code|kotlin.String}}型のインスタンスとして認識されるが、{{code|'a'}}は{{code|a}}という中身の{{code|kotlin.Char}}型のインスタンスとして認識されます。 ==== テンプレートリテラル ==== kotlinではプラス記号{{code|+}}で文字列を連結しなくても、下記のように文字列中に別の式を埋め込む事が出来ます。 ;[https://pl.kotl.in/5SN2x2awF コード例]:<syntaxhighlight lang="Kotlin"> fun main() { var num : Int num = 5 println("数字は $num だ") // (1) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 数字は 5 だ </syntaxhighlight> ;解説 Kotlinではドル記号{{code|$}}をつけて変数名を文字列の中に直接書くことができ、[[w:文字列補間|文字列テンプレート]]( ''string template'' ) と呼びます。 [[JavaScript]]では同様の機能を「[[JavaScript/文字列#テンプレート・リテラルのプレースホルダー|テンプレート・リテラルのプレースホルダー]]」と呼ばれます。 なお、(1) は回りくどく書くと以下のような意味になります。 :<syntaxhighlight lang="kotlin"> println("数字は" + num + "だ") // あるいは println("数字は" + num.toString() + "だ") </syntaxhighlight> ==== ドル記号 $ をエスケープする ==== {{code|$}}そのものを文字表示したい場合は、{{code|\$num}}のように、バックスラッシュ「\」をドル記号の前につけると、直後の文字を単なる文字として認識します（他の多くの言語のように <code>$$</code> ではありません）。 これをエスケープ・シーケンスと言います。C言語など多くの言語に、類似の仕組みがあります。（なお、Windows日本語版の場合、バージョンによってはバックスラッシュが円通貨マークで表示される場合もあります。） ;[https://pl.kotl.in/_T5nEJaKL コード例]:<syntaxhighlight lang="Kotlin"> fun main() { var num : Int num = 5 println("\$num は $num だ") } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> $num は 5 だ </syntaxhighlight> ==== 標準入力 ==== コンソール、ターミナル、DOSプロンプトなどから入ってくるデータをstdin、または[[w:標準入力]]と呼ぶ。 ヒューマンフレンドリに言うならば、それらのウィンドウに入力した文字列やパイプで流した文字列を標準入力と呼ぶ。 Kotlin で同じことを行うためには、<code>readLine()</code> 関数を使う。 ;[https://pl.kotl.in/89uE4042d コード例]:<syntaxhighlight lang="Kotlin"> fun main() { println("文字を入力してください") var input = readLine() println(input + "とあなたは入力しました") } </syntaxhighlight> ;実行結果の例 :※ 入力内容によって結果が異なります。下記は hhh と入力した例。 :<syntaxhighlight lang=console> 文字を入力してください hhh hhhとあなたは入力しました </syntaxhighlight> なお、Javaでは、以下のようにボイラープレートコード( boilerplate code )を都度書く必要があった: ;Java の場合:<syntaxhighlight lang="java"> import java.util.Scanner; /// Scanner scanner = new Scanner(System.in); String line = scanner.nextLine(); </syntaxhighlight> これは{{code|Scanner}}コンストラクターにJavaの「標準」入力ストリーム{{code|System.in}}を渡し、ScanneのnextLine()メソッドの戻値を変数{{code|line}}に格納する。 == 条件分岐 == ==== if ==== if式は、条件式に基づき分岐し、分岐先の式を評価します。 if式の値は、分岐先の式の値です。 if式の値を右辺値化した場合、else節は必須です。 ;構文:<syntaxhighlight lang=ebnf> if-expr := if '(' 条件式 ')' 式1 [ else 式2 ] </syntaxhighlight> :;[https://paiza.io/projects/kzILsP_EQrnNj2_LsH8wHQ?language=kotlin 条件式に整数を使うと]:<syntaxhighlight lang=Scala line> fun main(args: Array<String>) { val i = 0 if (i) println("zero") } </syntaxhighlight> :;コンパイルエラー:<syntaxhighlight lang=text> Main.kt:4:9: error: type mismatch: inferred type is Int but Boolean was expected if (i) ^ </syntaxhighlight> :: Kotlinでは、if式に限らず、条件式は、Boolean 型でなければいけません。 ;[https://paiza.io/projects/L8U8HupJcIqHpOf6igxDDA?language=kotlin if式の例]:<syntaxhighlight lang=Scala line> fun main(args: Array<String>) { val i = 0 if (i == 0) println("zero") else println("non zero") println( if (i == 0) "Zero" else "Non zero" ) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> zero Zero </syntaxhighlight> === when === when式を使って条件分岐をすることができます。 when 式は、when に与えられた式に最初にマッチするパターンに結ぶ付いた値を返すパターンマッチングです。 式が省略されると、パターンの条件が最初に真になるパターンに結びついた値を返します。 ;when式の例:<syntaxhighlight lang="Kotlin"> fun main() { val mes = "a" when (mes) { "a" -> { print("定数で初期化しているので、") println("mesはa") } "b" -> println("mesはb") "c", "d", "e" -> println("mesはcかdかe") else -> println("mesはそれ以外") } // when 式の値を使った等価なコード println(when (mes) { "a" -> { print("定数で初期化しているので、") "mesはa" } "b" -> "mesはb" "c", "d", "e" -> "mesはcかdかe" else -> "mesはそれ以外" }) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 定数で初期化しているので、mesはa 定数で初期化しているので、mesはa </syntaxhighlight> : when式は、いくつかの論理条件に応じて、複数の異なる制御構造体（ケース）のうちの1つを評価することができるという点で、条件式と類似しています<ref>[https://kotlinlang.org/spec/expressions.html#when-expressions Kotlin language specification Chapter 8 Expressions 8.6 When expressions]</ref>。 : 重要な違いは、when式は複数の異なる条件とそれに対応する制御構造体(control structure bodies; CSB)を含むことができることです。 : when式には、境界値付きと境界値なしの2種類の形式があります。 : 境界値(bound value；whenキーワードの後の括弧で囲まれた式)なしのwhen式は、whenエントリからの条件に基づいて異なるCSBのうちの1つを評価します。 : 各 when エントリは、boolean 条件（または特殊な else 条件）とそれに対応する CSB から構成されます。 : when項目は出現順にチェックされ評価され、条件が真と評価された場合、対応するCSBが評価され、when式の値はCSBの値と同じになり、残りのすべての条件と式は評価されません。 ::whenパターン式のパターンの後ろに break は不要です（フォールスルーしませんし、することはできません）。 ::もし break を書くと、when式の外のループ式からの脱出になります（フォールスルーしてしまう言語には、できなかったこと）。 区切子 <code>-></code> を使った構文の左辺の条件には、以下のようなバリエーションがあります。 ;when式の条件の構文:<syntaxhighlight lang="Kotlin"> 値 値1, 値2... , 値n in 範囲式 !in 範囲式 is 型 !is 型 else </syntaxhighlight> : 値は、定数である必要はなくメソッドでも構いません。 : 式は、単式i外にブロック式<code>{...}</code>でも構いません。 [TODO:境界値を省略した例、when文でループを脱出する例、enumな式が境界値に与えられた例] == 繰り返し処理 == Kotlinは、while と for の2つの繰り返し構文があります。 ==== while式 ==== while式は、条件式が true の間、式を評価しつづけます。 while式の値は、評価した式の値です。 ;構文:<syntaxhighlight lang=ebnf> while-expr := while '(' 条件式 ')' 式 </syntaxhighlight> : 条件式は、Boolean 型でなければいけません。 ;[https://paiza.io/projects/lpmktjJ6kNtJLcY8Mwxwrw?language=kotlin while式の例]:<syntaxhighlight lang=Scala highlight="4-7" line> fun main(args: Array<String>) { var i = 0 while (i < 5) { println(i) i += 1 } println("last = $i") } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 0 1 2 3 4 last = 5 </syntaxhighlight> === for式とコレクション === Kotlinのfor式は[[w:foreach文]]タイプのループ構文で、C言語の for(;;) とは異なる構文です。 ;構文:<syntaxhighlight lang=text> for (ループ変数 in コレクション) 式 </syntaxhighlight> ;[https://paiza.io/projects/zw6faeOmsjuZVF3D3WY_-g?language=kotlin 範囲コレクションとforを組合せた例]:<syntaxhighlight lang="kotlin" highlight=2> fun main(args: Array<String>) { for (i in 1..5) println(i) println((1..5).javaClass.kotlin) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 1 2 3 4 5 class kotlin.ranges.IntRange </syntaxhighlight> :<var>i</var>の様なループ変数は、forがスコープになります。 :ここでは、型指定を省略しているので、型推論されコレクションの要素型になります。省略せず、 ::<syntaxhighlight lang="kotlin" hightlight=2> for (i : Int in 1..5) println(i) </syntaxhighlight> :とすることもできます（ただし、異種コレクションだと要素型はUnion型になり宣言が複雑になるので、コードレビューの時に意図を明確にするなどの想起がない限り、型推論に任せるのが常です）。 :ループ変数は、varやvalを前置することができません。 :ループ変数には、代入できません。 ==== for と等価な while　==== ;for と等価な while:<syntaxhighlight lang="kotlin"> for (ループ変数 in コレクション) { println(ループ変数) } // は、以下と等価 val イテレーター = コレクション.iterator() while (イテレーター.hasNext()) { val ループ変数 = イテレーター.next() println(ループ変数) } </syntaxhighlight> :このことから、コレクションは .iterator(), .hasNext(), .next() の3つのメソッドを持つクラスと規定できます（この様なメソッド集合をプロトコルといい、この場合は for プロトコルといいます）。 ==== コレクション ==== <code>println((1..5).javaClass.kotlin)</code>の結果が示す通り、範囲リテラル<code>1..5</code>は<code>class kotlin.ranges.IntRange</code>です。 コレクションは、Ranges以外にも、Sequences・Ranges・Lists・Arrays・Sets・Mapsなどがあります。これは網羅していませんし、上記の forプロトコルに従ったクラスを作れば、ユーザー定義のコレクションも作成できます。 ;[https://paiza.io/projects/zw6faeOmsjuZVF3D3WY_-g?language=kotlin 様々なコレクション]:<syntaxhighlight lang="Kotlin"> fun main(args: Array<String>) { val collections = arrayOf( 1..5, 1..8 step 2, 5 downTo 1, 8 downTo 1 step 2, 'A'..'Z', listOf(2,3,5), setOf(7,11,13)) println("$collections(${collections.javaClass.kotlin})") for (collection in collections) { print(collection) print(": ") for (x in collection) { print(x) print(" ") } print(": ") println(collection.javaClass.kotlin) } } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> class kotlin.Array 1..5: 1 2 3 4 5 : class kotlin.ranges.IntRange 1..7 step 2: 1 3 5 7 : class kotlin.ranges.IntProgression 5 downTo 1 step 1: 5 4 3 2 1 : class kotlin.ranges.IntProgression 8 downTo 2 step 2: 8 6 4 2 : class kotlin.ranges.IntProgression A..Z: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z : class kotlin.ranges.CharRange [2, 3, 5]: 2 3 5 : class java.util.Arrays$ArrayList [7, 11, 13]: 7 11 13 : class java.util.LinkedHashSet </syntaxhighlight> : 二重のforループで、外周はコレクションのコレクションで、内周は個々のコレクションの要素をイテレーションしています。 === repeat関数 === Kotlinにはrepeat関数があり、定数回の繰返しが必要な時に便利です<ref>[https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/repeat.html repeat - Kotlin Programming Language]</ref>。 ;[https://paiza.io/projects/LHnnORcAjUhvb_qW9ysIvw?language=kotlin repeat関数]:<syntaxhighlight lang="kotlin"> fun main() { repeat(5) { println("it = $it") } repeat(3) { i -> repeat(4) { j -> println("(i, j) = ($i, $j)") } } } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> it = 0 it = 1 it = 2 it = 3 it = 4 (i, j) = (0, 0) (i, j) = (0, 1) (i, j) = (0, 2) (i, j) = (0, 3) (i, j) = (1, 0) (i, j) = (1, 1) (i, j) = (1, 2) (i, j) = (1, 3) (i, j) = (2, 0) (i, j) = (2, 1) (i, j) = (2, 2) (i, j) = (2, 3) </syntaxhighlight> :<var>it</var>は、暗黙のループ変数です。 :多重ループでは、ループ変数の名前が固定では都合が悪いので、ブロックの先頭で<code>識別子名 -></code> とすることで明示的に名前をつけることができます。 === ブロックを受取る関数 === repeat関数もそうですが、Kotlinにはブロックを受取る関数（やメソッド）があります。 ;[https://paiza.io/projects/AZT2juUGcUnyjqgDx4G85g?language=kotlin ブロックを受取る関数]:<syntaxhighlight lang="kotlin"> fun main(args: Array<String>) { val ary = Array(5) { 2 * it + 1 } ary.forEach{ println(it) } println(ary.map{ it.toString() }.joinToString(" ")) println(ary.reduce{ sum, el -> sum + el }) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 1 3 5 7 9 1 3 5 7 9 25 </syntaxhighlight> :ブロックで配列の初期化を行う場合、<var>it</var>は順位になります。 :コレクションのforEachメソッドもブロックを取ります。 :コレクションのreduceメソッドもブロックを取りますが、累算値と要素の2つを取るので、名付けが必要です。 このように、ブロックを取るメソッドを使うとコレクションに関する操作を簡素に書けます。 === 識別子の重複とシャドーイング === Kotlinでは、内側のスコープの識別子と外側のスコープの識別子が重複した場合、内側のスコープの識別子が参照されます。 ;[https://paiza.io/projects/etUJhoaySpr4RcwO9VwO-g?language=kotlin コード例]:<syntaxhighlight lang="Kotlin" line highlight="2,4"> fun main() { var i = 10 for (i in 1..3) println("for内: i = $i") println("for外: i = $i") } </syntaxhighlight> ;コンパイラーのエラー出力:<syntaxhighlight lang=text> Main.kt:4:10: warning: name shadowed: i for (i in 1..3) ^ </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> for内: i = 1 for内: i = 2 for内: i = 3 for外: i = 10 </syntaxhighlight> : ループ変数 <var>i</var> と、2行目で宣言された変数 <var>i</var> の名前が衝突しいています。 : この様に名前が衝突した場合、スコープの内側のオブジェクトが参照されます。 :: 名前が衝突し、内側和のスコープの識別子に外側のスコープの識別子が隠される事を'''シャドーイング'''と呼び、コンパイラーは発見すると<code>warning: name shadowed: 識別子</code>と（エラーでなく）警告します。 多くのシャドーイングは無害ですが… ;ありがちな間違え:<syntaxhighlight lang="Kotlin" line highlight="2,3"> fun main() { for (i in 1..3) for (i in 1..4) println("(i, i) = ($i, $i)") } </syntaxhighlight> ;コンパイラーのエラー出力:<syntaxhighlight lang=text> Main.kt:3:14: warning: name shadowed: i for (i in 1..4) ^ </syntaxhighlight> ;修正例:<syntaxhighlight lang="Kotlin" line highlight="3,4"> fun main() { for (i in 1..3) for (j in 1..4) println("(i, j) = ($i, $j)") } </syntaxhighlight> : 行列式を扱っていると、よくやらかします。 == クラス == Kotlinは、関数型プログラミング言語であると同時に、オブジェクト指向プログラミング言語です。 より厳密に言うと、（プロトタイプベースではなく）クラスベースのオブジェクト指向プログラミング言語です。 クラス(''class'')は、オブジェクトを作る雛形で、クラスからコンストラクタを使ってオブジェクトを作ることをインスタンス化、出来たオブジェクトの事をインスタンスと呼びます。 === クラス定義とインスタンス化とメソッド === ;[https://paiza.io/projects/41inK-Tl-w-FIjRvurIs3Q?language=Kotlin コード例]:<syntaxhighlight lang=Kotlin highlight="2-7,9,13" line> fun main(args: Array<String>) { class Hello(val s: String = "world") { override fun toString(): String { return "Hello $s!" } fun print(): Unit { println(s) } } val hello1 = Hello() println(hello1) hello1.print() val hello2 = Hello("my friend") println(hello2); print( """ Hello::class.java === ${Hello::class.java} hello1 === ${hello1} hello2.s = ${hello2.s} """ ) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Hello world! world Hello my friend! Hello::class.java === class MainKt$main$Hello hello1 === Hello world! hello2.s = my friend </syntaxhighlight> : [[Ruby#クラス]]の例を、Kotlin に移植しました。 : 冒頭4行がクラス定義です。 : クラス定義に、他のオブジェクト指向言語ならコンストラクタに渡すような引数が渡されています。 : メンバーを公開するケースなら、この様に宣言的な引数リストを使うとメンバー定義と暗黙の初期値を与えられます。 : toString は、オブジェクトを文字列化するメソッドで、Objectの同名のメソッドをオーバーライドしています。 : print は、このクラスに独自なメソッドで、println() の値 == () == Unit を戻値型としています。 === 演算子オーバーロード === Kotlinでは、演算子はメソッド形式の別名を持ちます。 例えば、<code>a + b</code> は <code>a.plus(b)</code> とも書けます。 この plus メソッドを再定義すると、演算子オーバーロードができます<ref>[https://kotlinlang.org/docs/operator-overloading.html Operator overloading]</ref>。 ;[https://paiza.io/projects/5q0qoELhXCuLq6YJfr05bw?language=kotlin コード例]:<syntaxhighlight lang=Kotlin highlight="7-9,13-16" line> fun main(args: Array<String>) { class Point(val x : Int = 0, val y : Int = 0) { override fun toString(): String { return "Point(x=$x, y=$y)" } } operator fun Point.plus(other: Point): Point { return Point(x + other.x, y + other.y) } val p1 = Point(15, 25) val p2 = Point(20, 30) println(p1 + p2) println(p1.plus(p2)) println(12 + 5) println(12.plus(5)) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Point(x=35, y=55) Point(x=35, y=55) 17 17 </syntaxhighlight> 演算子は、もちろん加算だけではありません。 :{| class="wikitable" style="float:left" |+ 単項演算子 ! 式 ! メソッド形式 |- |<code>+a</code> |<code>a.unaryPlus()</code> |- |<code>-a</code> |<code>a.unaryMinus()</code> |- |<code>!a</code> |<code>a.not()</code> |- |<code>a++</code> |<code>a.inc()</code> |- |<code>a--</code> |<code>a.dec()</code> |} :{| class="wikitable" style="float:left" |+ 算術演算 ! 式 ! メソッド形式 |- |<code>a + b</code> |<code>a.plus(b)</code> |- |<code>a - b</code> |<code>a.minus(b)</code> |- |<code>a * b</code> |<code>a.times(b)</code> |- |<code>a / b</code> |<code>a.div(b)</code> |- |<code>a % b</code> |<code>a.rem(b)</code> |- |<code>a..b</code> |<code>a.rangeTo(b)</code> |} :{| class="wikitable" style="float:left" |+ 包含 ! 式 ! メソッド形式 |- |<code>a in b</code> |<code>b.contains(a)</code> |- |<code>a !in b</code> |<code>!b.contains(a)</code> |} :{| class="wikitable" style="float:left" |+ インデックスによる要素参照 ! 式 ! メソッド形式 |- |<code>a[i]</code> |<code>a.get(i)</code> |- |<code>a[i, j]</code> |<code>a.get(i, j)</code> |- |<code>a[i_1, ..., i_n]</code> |<code>a.get(i_1, ..., i_n)</code> |- |<code>a[i] = b</code> |<code>a.set(i, b)</code> |- |<code>a[i, j] = b</code> |<code>a.set(i, j, b)</code> |- |<code>a[i_1, ..., i_n] = b</code> |<code>a.set(i_1, ..., i_n, b)</code> |} :{| class="wikitable" style="float:left" |+ 関数的な呼出し ! 式 ! メソッド形式 |- |<code>a()</code> |<code>a.invoke()</code> |- |<code>a(i)</code> |<code>a.invoke(i)</code> |- |<code>a(i, j)</code> |<code>a.invoke(i, j)</code> |- |<code>a(i_1, ..., i_n)</code> |<code>a.invoke(i_1, ..., i_n)</code> |} :{| class="wikitable" style="float:left" |+ 代入演算 ! 式 ! メソッド形式 |- |<code>a += b</code> |<code>a.plusAssign(b)</code> |- |<code>a -= b</code> |<code>a.minusAssign(b)</code> |- |<code>a *= b</code> |<code>a.timesAssign(b)</code> |- |<code>a /= b</code> |<code>a.divAssign(b)</code> |- |<code>a %= b</code> |<code>a.remAssign(b)</code> |} :{| class="wikitable" style="float:left" |+ 一致・不一致 ! 式 ! メソッド形式 |- |<code>a == b</code> |<code>a?.equals(b) ?: (b === null)</code> |- |<code>a != b</code> |<code>!(a?.equals(b) ?: (b === null))</code> |} :{| class="wikitable" style="float:left" |+ 比較演算 ! 式 ! メソッド形式 |- |<code>a > b</code> |<code>a.compareTo(b) > 0</code> |- |<code>a < b</code> |<code>a.compareTo(b) < 0</code> |- |<code>a >= b</code> |<code>a.compareTo(b) >= 0</code> |- |<code>a <= b</code> |<code>a.compareTo(b) <= 0</code> |} <br style="clear:both"> == 注釈 == <references group="注" /> == 出典 == <references /> == 外部リンク == * [https://kotlinlang.org/ Kotlin Programming Language] - 公式サイト * [https://play.kotlinlang.org/ Kotlin Playground: Edit, Run, Share Kotlin Code Online] [[Category:Kotlin|*]] [[Category:プログラミング言語]] {{NDC|007.64}} 14x73j53f6b21t4bn1mg0omvlurw21w 0 27004 206063 206038 2022-07-31T20:17:58Z Honooo 14373 /* 本ページの目的 */ wikitext text/x-wiki {{substub}} 現在の版の著者達は、ゲーム戦闘の調整の経験はないので、現状では本ページの内容は調べ物としては役立ちません。経験があり、かつ人間性も良好な人の協力をお待ちしています。 ==本ページの目的== 本科目『ゲームプログラミング』は、科目名に「プログラミング」とあるとおり、ゲームクリエイターのための教材ではなくプログラマーのための教材です。 従って、話題がプログラミング的な技術的な話題に片寄っています。一般のゲームクリエイターを目指す人には、本書のバランス調整の記述は到底、役立ちません。 プログラマーが、とりあえず何か趣味でゲームを作る際、バランス調整についての調べ物の手間を少なくするためだけの目的の教科書です。 ……と、前編集者Suj. は書いたんだけど、その割にはこの人物の私欲を満たすためだけの駄文が結構くどくど書かれてる気がするんだけど… 気のせいか？まあまだちゃんと読んでないしね、熱でもあるのカナ? コロナか^^? == バランス調整 == バランス調整とは、そのゲームの易しさ・難しさを決めるために、具体的に敵の強さなどを決めたり、あるいは主人公の強さを決めたり、あるいはそれらの要因の調査のためのテストプレイなどである。 なお、難易度の調整に限らず、バグ修正ではないが操作性の改善のために仕様および実装を更新するなど、そのゲームをさらに面白くするために様々な改善をすることをまとめて、ゲーム業界用語では「チューニング」という。「バランス調整」は、「チューニング」の項目のうちの一つである。 英語では、難易度の調整のことを「レベルデザイン」と言う。しかし英語の「レベルデザイン」のレベルとは、けっして日本のRPG的な経験値稼ぎによる「レベル上げ」などのレベルのことではなく、欧米で過去に流行した3Dゲームにおいてそのマップエディタではマップの高低差（※wiki注: これが英語の「レベル」の意味）を調整していたのだが、そのマップエディタのことを欧米では「レベルエディタ」と英語では言っていたのが経緯である。それらの3Dゲームでは、マップのデザインによって難易度が大きく変わるので、しだいにレベルデザインが難易度デザインのような意味になっていった、と考えられている<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.57</ref>。 書籍『ゲームプランとデザインの教科書』では、図中だが「難易度デザイン」という表現を用いている<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.58</ref>。 また、レベルデザインにはマップの処理もあるので、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、3Dゲームにおける「レベルデザイン」担当者には、MAYAなどの3Dグラフィックツールの技能が要求されることもあるとのことです<ref>吉冨賢介『ゲームプランナー入門』、P234</ref>。 === 「詰み」防止の確認 === 商業ゲームでは、クリア不能な状況にてプレイヤーがセーブしてしまい、ゲームを最初からプレイしなおす状況にプレイヤーが追い込まれること（いわゆる「詰み」（つみ） ）を絶対に防がなければなりません。 文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、このためバランス調整でも、プレイヤーがそういう「詰み」に追い込まれないようにする必要があります<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P78</ref>。 まず前提として、平均的なプレイヤーなら普通にクリアできる調整をしておく必要があります。 その上で、詰みを防止するためには、ゲームがとてもうまいプレイヤーでよいので、最低でも1人が、そのゲーム中で想定できる理論的に最もクリア困難な状況からですらも挽回してクリアできるという、クリア実績が必要です。 時間の制約などもあるからか、文献によれば、非常に上手い人が一度でもクリアしたという実績があれば良いという調整になるようです<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P78</ref>。 もちろん、前提として平均的なプレイヤーの多くが平均的な練習でクリアできるようになっているという環境の上です。 === プレイヤーの面倒くさがること === 『ゲームプランとデザインの教科書』によると、ゲーム中で一般的なプレイヤーの面倒くさがることとして、 覚えること、計算すること、配ることを面倒だと感じると言われています<ref>『ゲームプランとデザインの教科書』,P342</ref>。 === 消費者の趣向の変化 === 家庭用ゲーム黎明期の1980年ごろと比べて西暦2000年以降では、消費者に好まれるゲームの難易度バランスが違っています。 ;用語「難しい」の変化 ファミコン時代の昔と21世紀の今とで、ゲーム消費者の感じる「難しい」という言葉そのものの程度や意味が、昔と今で、やや違います。 文献『ゲームプランナーの新しい教科書』によると、たとえば携帯ゲームにおいて、平均的なゲームプレイヤーがクリアまでに5回ゲームオーバーになるように調整されたゲームは、21世紀の現代では「難しい」に分類される場合もあります<ref>『ゲームプランナーの新しい教科書』、P210</ref>。 一方、同文献によると「やさしい」とは、「平均プレイヤーならゲームオーバーにならない」という程度の意味です。 「難しいゲームの○○が人気！」などのニュースを目にしても、もしかしたら、そのジャンルのターゲット層の考える「難しい」の意味が、ファミコン的な昔の意味とは違うかもしれません。気をつけましょう。 その他、文献の情報ではないですがテレビ番組ですが（番組名は忘れた）、2011～2013年頃のテレビ番組で、ゲーム業界を取材した番組があったのですが（番組名は忘れました。たしか夜中の番組でした。）、 ゲーム会社だかゲーム業界の人がインタビューで :「 昔の子供は、難しいゲームをプレイしたとき、「このゲームは難しい」と答えていたが、今の子供は「このゲームはつまらない」 と答える」という話をしています。当時、アニメ業界やゲーム業界などを取材した番組がいくつかあったのです。 === どの程度の難易度を狙うべきか === 『ナナのリテラシー』というビジネスノウハウ系の漫画があるのですが、これの2巻がゲーム会社勤務回です。また、著者の漫画家もゲーム雑誌で漫画を掲載していた経験もあります。 さて、その漫画『ナナのリテラシー』によると、「誰もが飛び越せる絶妙な難易度の壁をクリアさせる」のがコツだと、作中のゲーム会社の老人経営者は言います。あくまで創作中の人物であり、また、作品の主張ではないですが。 この漫画の取材の程度として、 「PS」（プレステ）のロードは、「1回のロードで2WMが限界なんで　どんなマップも2メガに入れなくちゃいけない　会話も音楽も全部ね」 という情報を入手できている程度には取材のされている作品です。 高難易度（むずかしめ）ゲームや低難易度（やさしめ）ゲームを作るにしても、まず基準がこうであることを知っておきましょう。 ただし、すべての人に丁度いいバランスに調整することは、非常に難しいです。なので書籍『ゲームプランとデザインの教科書』では、ターゲット層をある程度はしぼりこむ必要があると述べています<ref>『ゲームプランとデザインの教科書』、P.97 </ref>。 ほかの書籍でも、塩川洋介『ゲームデザイン プロフェッショナル』では、やや文脈が違いますが、「遊んだプレイヤー全員が満足するものを、目指さない」と記述があります<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、2020年10月3日 第1刷発行、P.173</ref>。（ただし、これはターゲット層の限定のほかにも、テストプレイヤーの意見に振り回されないように、という意味もあるので、文脈が少し違う。） ターゲット層の設定で重要なことは、少なくとも、実在する最低1人の人間を、想定することです。「20代社会人男性が」とかではなく、自分の知人・友人・家族とか、そこまで具体的なレベルで想定するべきだと、塩川氏の著書では述べられています<ref>『ゲームデザイン プロフェッショナル』、P205</ref>。 {{コラム|カラケオ音楽の難易度も似ている| なお、ゲームではなく音楽文化ですが、80年代～90年代にカラオケが流行しましたが、実は当時の歌謡曲も似たようなカラオケでの難易度を意識して作曲されています。練習しないと歌うのが難しいが、素人でも練習すれば上手く歌える歌になるように、メロディが作曲されています。 たしか90年代後半、岡田斗司夫などが、こういったことを評論していました。 よく、音楽評論などでは、作曲家の小室哲也の曲が典型的にそうだと言われています。 なお例外もあります。 カラオケブームにより、90年代前半には、アニメソングでも子供が気軽に歌える歌が減ってしまったので、1995年のアニメ『新世紀エヴァンゲリオン』の主題歌の作曲では、監督やスポンサーのレコードー会社プロデューサーは、子供でも歌いやすいように作曲してくださいと作曲家に依頼しています。90年代後半の何かの書籍のインタビューで、スポンサーのレコード会社のキングレコードのプロデューサー（当時）大月俊倫がそう答えていました。 }} {{コラム|作者ではなく購入客たちによって是非が決まる| 商業作品であるなら、最終的には売上によって作品の是非が決まるわけですので、ゲーム産業なら間接的には購入プレイヤー/課金プレーヤーが作品の是非を決めることになります。 決して作家が是非を決められることではないのです。 文脈は違いますが、文献『ゲームデザイン プロフェッショナル』でも、「味の善し悪しはプレイヤーが決める」と記述があります<ref>『ゲームデザイン プロフェッショナル』、P.167</ref>。（ただしその参考文献では、ターゲット層を決めるべきだという文脈で味の善し悪しをプレイヤーが決めるという話をしていますので、本wiki本ページのニュアンスとは違います。） ゲームに限らずアニメ産業でも同じであり、作者や監督でも決められないことが多くあります。 ジブリアニメの『となりのトトロ』は、子供たちにアニメばかり見ずに外で遊ぶように啓蒙するようなストーリーを作者・監督の宮崎駿は目指したと言われています。 しかし実際には、視聴者からファンレターで、子持ちの母親からのファンレターで、「うちの子は、よく宮崎先生のアニメを見ています。面白いアニメを作ってくださり有難うございます」みたいな感謝のメッセージが来たりと、つまり、肝心の「アニメばかり見ないで外で遊べ」というメッセージが伝わりませんでした。 ガンダムやエヴァンゲリオンでも似たような逸話がアニメ評論ではありますが、説明を省略します。 }} === チュートリアルの分離などの検討 === 文献『ゲームプランとデザインの教科書』では、チュートリアルは別モードにすると良い場合もあると薦めています<ref>『ゲームプランとデザインの教科書』、P401</ref>。 伝統的な難易度デザインの書籍では、「段階的に難易度をステップアップ」のような設計論が語られている書籍もありますが、しかしそれだと長編ゲームなどでは中後半のゲーム性の本筋に入る前に長々と本筋でない部分をプレイさせられてしまいかねません。そこで、チュートリアルを別モードに分けることで、あまりにも中盤の難易度から掛け離れた部分を、ゲームの本編からは切り離すことができる場合もあるとの事です。 商業ゲームの実例としては『不思議のダンジョン２　風来のシレン』というゲームが、このようなチュートリアル分離の手法を活用しているとのことです。 === 教育的視点でのバランス調整 === ==== バランスを通じた教育 ==== バランス調整を成功させるための対策はいくつかあります。一つ例を挙げると、プレイヤーに習得してもらうプレイ技法をある程度想定しておくことです。 プレイヤーがそういうプレイ技法を習得し、実践できるようになったら、敵キャラを簡単に倒せるようにするのが良いでしょう。 文献『ゲームプランナー集中講座』（吉沢秀雄 著）でも、ニュアンスはやや違いますが「教育的難易度」という用語を使っています<ref>吉沢秀雄『ゲームプランナー入門講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、225ページ</ref>。 :※ ただし、この文献でいう「教育的難易度」とは、ある敵を攻略するのにプレイヤーがなんらかの操作を要求する敵は、まず1個だけのその敵の撃破用の操作技能だけをプレイヤーが修得できれば攻略できるようにしろという意味です。なので、本wikiでいう「教育的視点」とはニュアンスが若干（じゃっかん）、違います。 教育と言葉を使いましたが、プレイヤー視点では「学習」です。文脈は違いますが参考文献『ゲームプランとデザインの教科書』では、「学習」という言葉を用いています<ref>『ゲームプランとデザインの教科書』、P.61 </ref>。 ただし、このように教育的な視点が有効な場面は、あくまでバランス調整だけでしょう。企画などのアイデア出しは、教育的視点ではなく、もっと大衆娯楽エンタメ視点で行うのが定石です。（なお一般的に、ゲーム業界にかぎらず企画手法の定石として、面白い事どうしの組み合わせ、というのがあります。） また、少なくない多くのプレイヤーたちが、ゲームを通じて自身の思考力が磨かれて成長したかのような感覚を味わうのが好きだという統計・アンケート結果があります<ref>[https://www.teu.ac.jp/ap_page/koukai/2019_03_3endo.pdf [[w:遠藤雅伸]] 『ゲーム道に通じるユーザーの振る舞いとゲームデザインへの応用』66ページ、3.3.3. 面白さに関する考察 ]</ref>。 なお、コンピュータ的なゲーム産業と、教育との関係性にすでに気付いて注目しているゲーム作家もいます。ナムコ出身の岸本好弘がそうです。また、学問的にも、ゲーム設計技術の教育への応用として『ゲーミフィケーション』などと言う概念が提唱されています。 ゲームフィケーションに関する説明は長くなるのでコラム化します。 {{コラム|ゲーミフィケーションに関すること| 野球ゲームの『ファミスタ』シリーズで有名なナムコ出身の岸本好弘などが、ゲーミフィケーションをゲーム作家の立場から推奨している。<ref>[https://news.denfaminicogamer.jp/kikakuthetower/190731a ファミスタの父が「日本ゲーミフィケーション協会」発足──ゲームの力で世の中はもっと面白くなる 2019年7月31日 14:41 公開]</ref> 2019年に岸本がゲーミフィケーション学会を設立したが、なにもこの時点で概念が産まれたわけではなく、既に2013年あたりの時代には、たとえばテレビの夜中の経済ニュース番組などで、ゲーミフィケーションを企業の新人研修に応用する事例などが報道されていた亊もある（ただし、これに岸本氏が関わっているかは知らない）。 岸本が言うには「ゲームの本質っていうのは、人間が頭で想像することの素晴らしさ」である<ref>[https://www.fantasy.co.jp/edutainment/article/interview16 『“遊び”と“学び”はまったく同じ！？ ゲームと教育の専門家二人が語るゲーミフィケーション教育（前編）』 2021.07.08 UP] </ref>。 岸本が言うには、今から40年前（※1980頃 ？）を振り返り、すでにゲームセンター用のアーケードゲーム業界では、 :「そのころアーケードゲームのデザインで言われていたのは、初めてそのゲームに挑戦したプレイヤーでも3分間程度は遊べるようにすること。「もう一度チャレンジしたら、先に進めそうだ！」と、プレイヤーの気持ちが動くように制作すること」 :「これって、現在IT業界で言われるUX、ユーザーエクスペリエンスですよね。ゲーム業界では理論化、言語化していなかったけれど、40年前から現代に通じることをやっていたんだなと思いました。」 と言われている<ref>[https://www.fantasy.co.jp/edutainment/article/interview16 『“遊び”と“学び”はまったく同じ！？ ゲームと教育の専門家二人が語るゲーミフィケーション教育（前編）』 藤本 徹氏・岸本 好弘氏, 2021.07.08 UP] </ref>。 岸本「ゲームって全部「そそのかし」なんです。ゲームをプレイしていて、Ａの洞窟に行きなさいとか、Ｂの洞窟には行くなとは言われないですよね。プレイヤーが2つの洞窟をぱっと見たときに「こっちの洞窟に宝があるかも！」って見えるように作っているんです。これを「そそのかし」って言うんです。間違っても、ストレートに「Ａの洞窟に宝物があるなどという看板を立ててはいけません（笑）。」 （抜粋）「先生は答えを教えるのではなく、生徒が自分で「わかった！」、「僕が一人で気が付いた！」と思わせることが大切。」 「ゲームをデザインするのも授業をデザインするのも同じです。楽しいと思うことやワクワクすることは脳の働きを最大限にする。だから、つらいことを我慢するのはよくない。脳が楽しいと感じることがとても大切なんです。」<ref>[https://www.fantasy.co.jp/edutainment/article/interview17 『“遊び”と“学び”はまったく同じ！？ ゲームと教育の専門家二人が語るゲーミフィケーション教育（後編）』藤本 徹氏・岸本 好弘氏, 2021.07.15 UP] </ref> 必ずしも現代のゲームが上述のように教育的配慮にもとづいて設計してもヒットするかは不明である。21世紀の現代と20世紀のファミコン黎明期とでは消費者ニーズも違っているから、もしかしたら今後は教育的配慮ある作品が全く売れないのかもしれない。 だが、とりあえず1980年代前後のゲーム文化の根底には、このような教育的な発想が色濃く存在していたのもまた事実であろう。 }} {{コラム|オタキング岡田はこういった| また、ゲーム業界人だけでなくアニメ業界人からも、1998年までの時点で似たようなことが指摘されています。 既に1990年代後半の時点で、アニメ評論家の岡田斗司夫により著書などで、市販のゲームソフトの多くは達成感を味合わせるものだと指摘されている。 たしか岡田の著書『世紀の大怪獣!!オカダ―岡田斗司夫のお蔵出し 』に、そういった話題が書かれており、マリオカートが例に出されている。 岡田に言わせれば、ゲーム文化以前の人生の趣味の多くは、必ずしも努力の量と、上達とが比例しない。たとえばスポーツとか、絵画とか、何でもいいが、たしかに練習を多くしても必ずしも上達に結びつくとは限らない。 しかしファミコン以降のコンピュータ式のゲームはそうではなく、ほぼ必ずといっていいくらい、少なくとも初心者レベルの範囲でなら、プレイして練習すれば上達するように設計されていると、彼の著書では述べられている。 岡田が言うには、人生はゲームみたいに甘くないし、もしかしたらゲームは現実逃避で不健全かもしれないけど、でも大人だって親だって達成感をもっと感じたいんだぜ・・・だから今日も娘といっしょにマリオカートをプレイしている、というような感じのことを著書で述べていた。 }} {{コラム|岡田斗司夫はゲーム会社社長でもあった| なお、岡田らの創業したアニメ会社の「ガイナックス」は、現在では『新世紀エヴァンゲリオン』をつくったアニメ会社として語り継がれていますが、実はゲームソフトも開発していました。 多くは美少女ゲームだったりしたのですが、その中に、1991年に開発した『プリンセスメーカー』という当時としては斬新な育成シミュレーションゲームがありました。（少女を育成するゲームとしては、おそらくプリンセスメーカーが世界初。なお、競馬の競走馬を育成するゲーム（ダービースタリオン）1991年12月発売よりもプリンセスメーカー（1991年5月24日）のほうが発売が早い。） 文献『ゲームプランナーの新しい教科書』でも、美少女や少年などのキャラクターを1人または少人数のキャラクターを育成するジャンルを確立したゲーム作品が、このプリンセスメーカーであると述べられています<ref>STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版 第2刷 発行、P182</ref>。 さて、1998年ごろにゲーム評論家の阿部広樹（あべひろき）が言うには、 98年当時はコナミ社『ときめきメモリアル』という、美少女と恋愛するための男主人公を育成する育成ゲームがほぼ社会現象のような流行だったのですが（たとえばジャンプ漫画の　こち亀（略称。長いので）　にも、 明らかに『ときめきモリアル』（略称：「ときメモ」）のようなゲームを話題にした作品が、 社会現象作品として登場しています）。 阿部が言うには、ときメモのような育成ＳＬＧは、ゲーム業界での系譜としては、まずプリンセスメーカーが娘の育成ゲームとして登場し、 おそらくは、それを参考にしてPCゲーム会社「エルフ」が美少女アダルトゲーム「同級生」（ゲーム中に男主人公の育成がある）を開発し、 さらにそれを参考にしてコナミ社がときメモを開発したという流れになる、と阿部は著書などで述べています。 あくまで阿部氏が著書でそう思っている旨を述べていただけなので、 もしかしたらエルフ社やコナミ社の当時の関係者からすれば元ネタが違う点もあるのかもしれませんが、 少なくとも他社やマニア消費者からはそう思われている（プリメ→同級生→ときメモ　という流れを思われている）というワケです。 さて、ときメモの話をしたいのではなく、岡田の話をしたいのです。 岡田は当時はゲーム社長だったので、常識的に考えて、プリンセスメーカーの開発に関する情報は、ある程度は耳に入っていると思われます。（ただし、岡田本人はゲームファンではなく、アニメファンかどうかも怪しく、どちらかというとSFファンでした。） いくら岡田がゲームに詳しくないといっても、信頼できる部下にゲーム開発指揮を任せているとしても、岡田が社長である以上、最低限の開発工程の概要や全体像に関する情報が岡田の耳には入っているハズです。 そういう経験のある岡田が「ゲームはプレイ時間に応じて、上達するように設計されている」と具体的に言うわけですから、岡田のマリオカート評論当時の意見を、過去のゲーム業界人の意見としても、それなりに意見を参考に聞き入れるべきでしょう。 だから「岡田はアニメ評論家じゃねえか」とか言って意見を無視するのは、不見識です。 また、プリメ→同級生→ときメモ　という流れから分かるように、一般にゲーム会社は他社の人気コンテンツを真似ています。 攻略本やゲーム雑誌などには一切書かれていませんが、大人の事情で書かれていないだけですので、大人の事情を真に受けないようにしましょう。当然、ときメモ以降の他社の育成ゲームや美少女ゲームも、社会現象になった「ときメモ」を真似しています。誤解のないように再度書きますが、上記で紹介したゲーム郡のうち、岡田経営のガイナックスのゲームは『プリンセスメーカー』だけです。ほかのゲームは他社コンテンツですので、誤解なきよう。 }} {{コラム|プリメとデスペナ| プリンセスメーカーには育成システムのほかにも比較的に画期的なところがあって、それは戦闘での全滅時の損失の軽さです。プリメのしリーズでは、戦闘で全滅しても、拠点に戻されることと、育成パートでのターンが1ターン経過するだけです（1ヶ月が1ターンに相当する）。この指摘は別にwikiのオリジナルではなく、1990年代の後半に雑誌『ゲーム批評』で指摘されていたことである。 1年に12ターンしか行動できないので、シミュレーションゲームの視点で考えると損失は大きいかもしれませんが、RPGの視点だけで見ると損失は軽い、というわけです。 日本の現代的なゲーム評論では、全滅時の損失のことを和製英語でデス ペナルティといいます。英語では dead damage というらしいです（DDと略すようです）。英語ではデスペナルティ death penalty とは「死刑」の意味です。 つまりプリンセスメーカーは、デスペネルティが軽くても面白いRPGを作れることを実証したかもしれない可能性があります。 ;デスルーラ なお、全滅しても拠点に戻るだけのシステムだと、拠点に戻りたい場合にわざと全滅する方法を使えますが、これを和製英語で「デスルーラ」といいます。ルーラとはドラクエの移動魔法のルーラのことです。 さて、全滅したときに拠点に戻るゲームでは、標準的な方法では、決してイベントなどで拠点に戻らないようにするのは不可能です。 なぜなら、たとえば拠点の町に戻る橋を通せんぼしているボス敵がいたとして、ボス敵が「この橋を通りたければ、私を倒すが良い」とか言われてボス戦になったとしても、そのボス戦闘で全滅するとパーティは拠点の町に戻るので、そもそも通せんぼイベントの意味がありません。 ただし、もしイベント用の特殊なプログラムとして、全滅時には他の町に戻るなどの戦闘の処理を組めば可能ですが。 }} {{コラム|デスペナ関連の話題| <!-- この話題は、後述の商学書『メイド・イン・ジャパンは負けるのか』の話題と関連するので、残す必要がある。 --> ;帰り道の通せんぼイベントと詰みのリスク そもそも、拠点への通せんぼ系のイベント自体、クリア保証の観点からは難しい点もあります。サガのようにどこでもセーブできるゲームの場合は、帰り道の通せんぼイベントを上手に設計しないと、クリア不能につながるおそれがあります（いわゆる「詰み」（つみ））。 だから実際、ファミコン～スーファミ時代のドラクエやファイナルファンタジーやGB版サガやロマサガなどでは、このような帰り道の通せんぼイベントを見かけないか、あったとしてもスグには思い出せません。 どこでもセーブできるロマサガ1の氷結城の帰り道で通せんぼするボス敵がいますが、しかし会話選択肢などによりボス戦を回避可能ですので、詰みにはなりません。 なお、古い時代のサガ系やロマサガなどでは、基本的に、ダンジョン奥まで探検したあとの帰り道には、帰り道の短縮のためにダンジョン最深部に出口への一方通行をマップ側で用意済みというダンジョン設計もよく見られました。このダンジョン設計は、テンポ感向上の基本手法である「プレイヤーが既に理解していることを再度要求しないこと」にもつながりますので、一石二鳥です。 ただし、一方通行出口がないダンジョンがあれば、「帰り道でボス戦があるんだな」とプレイヤーに予感させてしまい、プレイヤーへのネタバレになります。だから、ドラクエがそのような一方通行出口をまず用意しないのも一理あります。 このように、ゲームのルールの設計により、実装可能なイベントやマップなどがある程度は限定されてしまいます。 }} さて上記のデスペナルティのコラムで説明したように、ゲームのシリーズ作品は、そのシリーズを通してルールがおおむね一緒です。 このことと、「ゲームのルールによって搭載されるイベントがある程度は決まる」という事を合わせて考えると、どうなるでしょうか。 そう、シリーズ作品によって、搭載されるイベントの傾向が決まってしまうのです。 問題は、これがマンネリ化につながるおそれがあること、少なくともビジネス書ではそう見られていることです。 これは別にwikiのオリジナル意見ではなく、文脈は違いますが、商学書『メイド・イン・ジャパンは負けるのか』という2010年ごろの書籍で、 シリーズ化とマンネリ化との相互関係が語られています。 さらにその書籍によれば、基本的に家庭用ゲーム機の作品群の多くはゲーム性の根幹が90年代あたりから以降の作品は変わっておらず、変わったのはグラフィックが細かくなっただけ、というふうに見られています。 ただし、書籍は2010年ごろの出版物なので、もしかしたらスマホゲームやソシャゲの流行している2020年代の現代なら、分析結果は違うのかもしれません。 もっともゲーム会社からすれば反論もあるかもしれませんし、たとえば、 「でも消費者が、新シリーズや新ジャンルを出してもロクに買わねえじゃねえか・・・」とか 「グラフィックよりゲーム性とか口先では消費者は言うけど、でもそういうグラ軽視のゲームを消費者は買ってくれないんだよね」とか 「素人はみなそう言うんだよね。でも自分じゃ作ってくんないし少しでも試作品の手本すら見せてくんない」とか思うかもしれませんが、 とりあえず、世間にはそういう意見があります。 けっしてゲームオタクだけがそういうマンネリ化の意見を言ってるのではなく、外部の商学あたりからもそう見られています。ただし書籍の商学者の分析が正しいかどうかは知りませんが。 1980年代のような家庭用ゲーム黎明期や1995年頃のソフト容量が飛躍的に伸びたプレステ1時代ならともかく、そうそう新しくて画期的かつリアリティと説得力ありそうなルールなんて、思いつくものではありません。難しい問題です。また、マンガ産業やアニメ産業は黎明期をとっくに過ぎてしまいましたが、それでもマンガもアニメも産業は続いています。2010年台のゲーム産業だって、もしかしたらスマホゲーム黎明期、ソシャゲ黎明期なのかもしれません。2010年以降の現代のゲーム産業については、当wikiは中立性の立場上、これ以上は解説しません。 {{コラム|岡田斗司夫のアノマリー理論| 古典的な理論を言うと、アニメ評論家の岡田斗司夫が「アノマリー」（「片寄り」という意味の用語）で言ってる例ですが（『東大オタク学講座』にある理論）、ゲームのバランス調整にはそもそも、岡田の理屈によると普遍性はなく、どうしても作者の世界観が反映されます。 たとえば、『シムシティ』というアメリカ人の作った都市運営シミュレーションのゲームでは、原発が効果的な投資であるのですが、そして火力発電所よりも原子力発電所が効果的なのですが、岡田はこれを作者のアメリカ的な都市政策観の反映だとしています。 そのほか、岡田は、ドラクエシリーズに対して、「なぜ作者の堀井さんは、作中で父親と子の関係に、どの作品でも、こだわりたがるんだろう？　なにかあったんじゃねえの？」的なゲスい勘繰りもしています。 作家の「個性」というのは、一般人から見れば「異常性」でもあるわけです（ただし、法律を守る程度の最低限の一般性は作家だろうが必要ですが）。個性というのは長所ではなく、欠点の裏返しでもあるわけであり、その欠点すら大人はうまく自分で活用しなければならないのでしょう。 }} ==== 本文 ==== もちろん作品によっては例外もあるでしょうが、しかし上述で紹介したような様々な視点の異なる複数のゲームクリエイターなどゲーム業界人が、「教育」や「成長」などあたかも学習的な用語を使っている事は、念頭に置くと良いかと思います。 ゲームにおける教育的な要素はもちろん擬似的なものです（ゲームに限らず一般のアニメや漫画も同様です。もし本格的に世間一般で通用する意味での「学習」をしたいなら高校～大学レベルの国語・数学・英語・理科・社会科などの参考書などを読もう）。 さて調整の話題に戻ります。 たとえば、アクションゲームの調整なら、 もし敵が飛び道具を使ってくるなら、まずプレイヤーは物陰に隠れて移動して近づくとか、あるいはプレイヤーも飛び道具で応戦するとか、そういうプレイ技法が必要でしょう。 文献『ゲームプランナー集中講座』（吉沢秀雄 著）でも、飛び道具を使ってくる敵には、ゲーム序盤では、まず物陰にかくれて敵の攻撃を避けるなどのプレイ技法をプレイヤーに習得できればよいというくらいまで、（序盤の）難易度を簡単にすべきだと、その文献『ゲームプランナー集中講座』では主張されています<ref>吉沢秀雄『ゲームプランナー入門講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、226ページ</ref>。 まず、序盤の飛び道具つかいの敵なら、プレイヤーが上述のような物陰に隠れる技法を実践できていたら、その敵を簡単に倒せるように難易度を調整します。 このため、序盤ではけっして、敵の攻撃をさけるための物陰の部分には、ゲーム作者はワナなどを仕掛けないでおき、物影には敵も配置しないようにするくらいで、良いのです<ref>吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、226ページ</ref>。 たとえば、飛び道具を使ってくる敵は、そいつに攻撃を当てるまでは難しいが、しかし敵の防御力を低くしておいて、もし敵が（プレイヤーからの）攻撃を受けたら、敵はすぐに倒されてしまう・・・のような強さの敵としてパラメータ調整しておくのが良いでしょう。 つまり、プレイヤーに教えたいスキルとして、そのアクションゲームを通して、飛び道具を使ってくる敵の対処法を教えるのです。 ゲーム後半で難易度を上げる場合は、けっして敵を単にやたらと頑丈にするのではなくて、 敵の強さはそこそこでいいので、 たとえば ステージのギミックや敵の行動などを今までの敵と複合化させたりする等の設計により、過去にプレイヤーの習得したプレイ技法の組み合わせの練習・習得をプレイヤーに要求したりとかして、プレイヤーに今まで習得した単一のプレイ技法の複合の習得を要求するようにすると、プレイヤーも成長できますし、あきづらくなるし、いいことづくめです<ref>吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、228ページ</ref>。 （ただし、あまりにも膨大なプレイ技法どうしを組み合わせるような過大な技法をプレイヤーに要求しないように、（作者がプレイヤーに）要求する技法の数にも限度は必要でしょう。） なお、余談だが、「難易度」の「高い」「低い」の意味は、 :「むずかしい」＝「難易度が高い」 :「やさしい」＝「難易度が低い」 である。 ゲームを難しくする目的は、プレイヤーに創意工夫を呼び起こすためです。創意工夫を呼び起こさない難しさは不要かもしれません。 書籍『ゲームプランナー入門』によれば、ボス戦などの難しいエリアの目的は、プレイヤーが自らのプレイスキルの程度を試したり、あるいはRPGなどならキャラクターユニットの成長を試すためのものです<ref>吉冨賢介『ゲームプランナー入門』、P60</ref>。また、「歯ごたえ」などの表現の意味も、こういった意味であると書籍では述べています。 ;制限の必要性 制限の必要性とは、たとえば、ゲーム中での主人公が丈夫で死にづらいのは構いませんが、しかしどんなに敵の攻撃を食らっても死なずに倒れずに不死身なのは駄目です。 また、主人公の所持金が多いのは構いませんが、しかし所持金が無限大なのは駄目なのです。 また、敵の動きが少し単純なのは構いませんが、しかし、プレイヤーが油断しすぎているのにプレイヤーが負けないのは駄目です（たとえばアクションゲームで一時停止ボタン（ポーズボタン）を押さずにトイレに行ってウンコを数分してきても、ウンコから戻ってきてもキャラが負けてないのは明らかに駄目）。 このような駄目な例のゲームのままでは、プレイヤーが創意工夫をしなくなってしまいます。 このため、そのゲームでのゲームオーバー条件を、作者は早めに決めておきます。ゲームオーバーが用意されていないと、スリルが出ないのです<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.254</ref>。 あまり気が乗らないでしょうが、しかし、ゲームにはゲームオーバーや敗北の条件が必要ですし、プレイヤーには敗北を回避するように努力してもらわなければなりません。 ;解法を1つに限らない 書籍『ゲームプランナー入門』（吉冨賢介 著）によると、たとえばスーパーマリオ1のステージ1-1の最初の敵のクリボーの対処でも、クリボーを踏んでやっつけるか、それともジャンプして飛び越えて次に進んでしまうか、マリオがブロックの上に乗ってクリボーが通り過ぎるのをやりすごすか、などなど幾つもの選択肢があると、例を挙げています<ref>吉冨賢介『ゲームプランナー入門』、P55</ref>。けっして、「たった一つの正解」ではないと述べています<ref>吉冨賢介『ゲームプランナー入門』、P55</ref>。 このように解法を複数用意することで、プレイヤーに創意工夫を呼び起こしやすくなります。 ==== 他メディアとの違い ==== ===== マンガ・アニメのバランス調整との違い ===== マンガやアニメのバランス調整というか、物語での敵の強さの見せ方と、ゲームでの敵の強さのありかたは、少し差異があります。 マンガ・アニメだと、たいてい強敵は、主人公がなんとか苦戦しながら倒せるギリギリの強さになっています。たしか1982年『鳥山明のヘタッピマンガ研究所』（1982年『鳥山明のヘタッピマンガ研究所』）の時点で、すでに、マンガやアニメや特撮（ウルトラマン）などの敵の強さは、そういうふうに設計されていることが説明されています。 しかしゲームでは普通、このようなギリギリの強敵にしてないほうが安全です。 マンガやアニメの強敵よりも、やや弱めにしておく必要があります。そうしないと、プレイヤーに創意工夫が生まれません。 具体例を考えるなら、分かりやすい例が、先ほど漫画家の鳥山明さんを例にあげましたが、その鳥山さんのドラゴンボールの原作マンガとゲーム版でのボス敵の強さの違いです。ゲーム版『激神フリーザ』だと、たとえばクリリンでもちょっと鍛えて頑張ればザーボン（ナメック星編の中ボス敵）を倒せるようになっています（原作マンガだとクリリンはザーボンを倒せない）。別に鳥山さんの作品だけでなく、ほかの多くの作家のマンガやアニメのゲーム版も、大体、同様に、原作マンガや原作アニメでは倒せなかったボス強敵がゲーム版では頑張れば倒せるようになっています。 理論的に考察するなら、マンガやアニメでは、一回の戦闘での強敵の倒しかたが一通りしかなく、いちばん読者に魅力的に見える奇想天外・破天荒な倒しかたで、敵を倒します。なのでマンガやアニメでは、ギリギリ倒せる強さのほうが良いのしょう。 しかしゲームの強敵では、多くのプレイヤーの、それぞれ異なる色々なアイデアに対応した倒し方を何通りも準備する必要があるので、ゲームでの強敵の強さは、ギリギリ倒せる状態よりも少し弱めにする必要があります。 ==== 「廃人」 ==== ゲーム用語で「廃人」（はいじん）という表現があります。「廃人」とは、たとえば通信機能のあるネトゲRPGなどで、普通の社会人だとレベル上げが引きこもりプレイヤー追いつかずに（社会人が）クリアできないようなゲームにおいて、高レベルプレイヤーである引きこもりプレイヤーや無職プレイヤーなどを揶揄する意味です。 2010年以降の近年は課金ゲームなどにも「廃人」という言葉が使われます。一般の市販ゲームは高くても1万円程度ですが、それと比較して多額すぎる数十万円や数百万円の金額をゲームに課金するプレイヤーのことです。 書籍『ゲームプランとデザインの教科書』でも、この問題をサラっとですが、きちんと紹介しています。書籍中では「廃課金ユーザー」という表現を使っています<ref>『ゲームプランとデザインの教科書』、P66</ref>。書籍『ゲームデザインとぼくらの教科書』でも、廃課金ユーザーが社会問題化したことに触れられています<ref>『ゲームプランとデザインの教科書』、P66</ref>。 アニメーターだってゲームをする暇があるなら絵を描いていたからアニメーターとして通用しているわけです。アニメーターの就職前の第一趣味はゲーマーではないでしょう（イラスト制作やアニメ制作のはずです）。 === ゲーム作家の体感の難易度はズレやすい === プログラミングというよりゲームデザインの話題かもしれないが、そのゲームの簡単さ・難しさといった難易のバランス調整も、コツがいろいろとある。 ==== 具体的な方法 ==== 結論から言うと、多くのゲームデザインの文献で、やや簡単めに調整されたバランスでゲームを作るのが安全であると主張されている。 たとえば書籍『ゲームプランナーの新しい教科書』（STUDIO SHIN 著、翔泳社）でも、作者がやや簡単だと思うくらいに作ると良くなる場合が多いという経験則が語られている<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版第2刷発行、54ページ</ref>。 また、書籍『ゲームプランナー集中講座』（吉沢秀雄、SBクリエイティブ）でも同様に、調整で迷って、プレイヤーにとっては易しいほうの案Aと難しいほうの案Bとがあったら、ゲーム本編には、やさしいほうの案Aを採用するのが良い、と主張しています<ref>吉沢秀雄『ゲームプランナー入門講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、235ページ</ref>。 難しいほうの案Bは、クリアに不要なサブ・ステージとか、そういうステージに流用すればいいのです<ref>吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、P207および235ページ</ref>。 ちなみに、文献『ゲームプランナーの新しい教科書』によれば、RPGにおいて、クリアに不要なイベントのことを「任意イベント」と言います。一方、クリアに絶対な必要なイベントのことは「強制イベント」といいます<ref>STUDIO SHIN著『ゲームプランナーの新しい教科書』、P198</ref>。 つまり、サブ・ステージや任意イベントの難易度については、本編の強制イベントの難易度よりも少し難しくしても構わないのです。文献『ゲームプランナー集中講座』によれば、むしろ、多様なプレイヤーに対応するためにサブ・ステージや任意イベントの難易度の設計は、本編強制イベントとは難易度を変えるほうが望ましいというか、そういう設計テクニックとしてサブ・ステージや任意イベントが用意されているような側面もあるようです<ref>吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、P208</ref>。 書籍『ゲームプランナー入門』（吉冨賢介 著）でも、基本的に作り手は「簡単」だと思っていても、初めてプレイするプレイヤーには難しいという現象がよくあることを述べています<ref>吉冨賢介『ゲームプランナー入門』、P56</ref>。 ==== 例外 ==== 例外的なプレイヤーもいます。プレイヤーの中には、たとえばRPGなら、レベル上げそのものが好きな人もいます。 また、たとえばゲーマーでない一般人でも、たとえば電卓で「+1」を押しまくって計算結果をカウントアップしていく暇つぶしをしたことある人も多いでしょう。 ですが、レベル上げが好きなRPGゲーマーでも、彼らがプレイしたがるゲームの多くは、なぜか、レベル上げがそれほど好きでない種類のゲーマーも楽しめるゲームばかりです。 ドラクエ、ファイナルファンタジー、女神転生、テイルズ、・・・などなどのシリーズは、どれも商業の人気ゲームは、レベル上げがそれほど好きでなくても、ストーリーや戦術性などでも楽しめるようになっています。 本当にレベル上げだけが好きなら、ストーリー一切無しのレベル上げだけのゲームをプレイすれば充分ですし、フリーゲームなどでそれに近いゲームはあります。しかし、商業の世界では、そういうストーリー無し、あるいは戦術性が無しのゲームの話を聞きません。 これはどういうことでしょうか。 ゲームでなくマンガ業界の例で考えて見ましょう。 たとえば、少年ジャンプの読者には、メインの読者層は若い男の子ですが、 しかし実際には成人男性の読者もいますし、それどころか女性読者もいます。 しかし少年ジャンプは、あくまでも、メインの読者層が男の子であることを貫く編集姿勢であることが、 ジャンプ漫画の裏側を描いたマンガ『バクマン』では描かれています。 バクマンによると、たとえ少女の読者がいても、その少女は、 「男の子が読んでるマンガを自分も読んでみたい」と思うような女の子なので、 だからジャンプの取るべき編集姿勢としては、あくまで男の子向けを貫かないといけない、 といった内容が説かれています。 ゲームも同様でしょう。 ==== 背景事情 ==== 一般的にゲーム作家の側は、自作のゲームをプレイしたときの体感の難易度（なんいど）が、（他のプレイヤーよりも）自作ゲームを「やさしめ」に感じてしまいまちである。 つまり、本当は難しいゲームなのに、作家自身は「やさしい」と錯覚しやすい傾向がある。なお、この現象を俗に（ぞくに）「作者バイアス」と日本では言う。 ;歴史 まず、1990年代のゲーム雑誌『ゲーム批評』にもある歴史的事実として、下記のような事例がすでに1990年代から知られています。 すでに1990年代の時点でゲーム評論雑誌『ゲーム批評』において、新人のゲームプランナーは企画提案の際に既存ゲームを難しくアレンジした提案をしがちだという報告がありました。 雑誌『ゲーム批評』によると、たしか、たとえばもし自社がスーパーマリオのようなゲームを作ろうとしている場合、新人はよく、「マリオのこの部分が簡単すぎるから、わが社はここを難しくしましょう」という提案をしがちだということです。 たとえば、スーパーファミコン版マリオ（スーパーマリオワールド）では、地上ステージでは多くのステージで、マリオに空を飛ばせれば、敵に遭遇せずにステージのゴールまで行けるように設計されています。 それを新人は「飛んでしまうと簡単なので、つまらない」と考えがちらしく、なので「空中に敵キャラを多く配置しましょう」という感じの案を提出しがちだということです。 たとえば 「空中に狼（オオカミ）を配置するのはどうでしょう？　アメリカの昔のSFドラマに『超音速攻撃ヘリ　エアーウルフ』という作品もありますので、パロディにもなって大人にもウケます」みたいな提案を出したりしがち、らしいです。（このほか、ゴルフゲームでウルフを空飛ばせる駄洒落（ゴルフでウルフ）アイデアなどの披露もあるとかゲーム批評では書かれていた気がするが（というか元々ゴルフゲームの提案で、上司役からのダメだしの根拠にマリオを例にする批評記事だったかもしれないが、本wiki本ページの文脈にあまり関係ないので、ゴルフの話は割愛させてもらう。） ですが、マリオの地上ステージの空中に敵が少ないのは、ゲームが苦手なプレイヤーのための救済措置だったり、あるいは既に途中まで攻略したけどミスでステージ冒頭に戻されたあとの再チャレンジなどで興味ない体験済みステージ前半を無視するための工夫だったりするので、よって空中の安全性は必要な要素でしょう。 しかし、エアーウルフ的な提案では、そういう分析が抜け落ちています。 ともかく、このように、バランス調整では「予備知識が無いと、多くのゲーム製作者は、ゲームを難しく設計しがち」だというゲーム業界の経験則がもう1990年代からあります。私たちは、歴史にも学びましょう。 :※ ある編集者Aがなんとなく印象でゲームデザイン本などに「ゲーム作家はあまりネットの批評を参考にしない。ゲームを作った事のない人の批評なので、トンチンカンな批評も多いからだ」といったような情報があったような気がしたのですが、 :しかしあらためて書籍を確認してみると、少なくとも『ゲーム作りの発想法と企画書の作り方』や『ゲームプランとデザインの教科書』や『レベルデザイン指南書』では、そのような記述は確認されませんでした。 :下記のコラムは、その情報も背景にしています。 :どうやら、もしそういう記述の文献があっても、必ずしも商業ゲーム業界の多数意見とは限らないようです。 :あるいはその情報は、もしかしたら書籍による情報ではなく、ゲーム雑誌などのwebサイトの意見だったかもしれません（※ 読者に出典などをご存知の方がいたら、情報提供の編集をしていただけると、さいわいです）。よくゲーム雑誌の会社がwebサイトなどに商業ゲーム作家へのインタビュー文など掲載しています。 :一応、『ゲームデザイン プロフェッショナル』では、書籍後半のセクションの題名で大きく「一次情報以外、個性には役立たない」と銘打って、 :「インターネットやSNS」などについて、「そうした情報は知識として役に立つことはありますが、ゲームデザイナーが個性を発揮するうえではあまり役に立ちません」と説明している<ref>『ゲームデザイン プロフェショナル』、P314</ref>。 {{コラム|マリオメーカーのクリアチェック、ほか| マリオついでに話すと、『マリオメーカー』という任天堂のつくった、マリオのゲームの素材を使って、 マリオメーカー購入者でも自分でマリオ風アクションゲームを作れるというゲームがあります。 このマリオメーカーというゲームでは、自作したゲームを任天堂のwebサイトに投稿・公開する際、クリアしてからでないと、投稿・保存できない仕組みになっています。 実は、マリオメーカーが発売される前、インターネット上には「改造マリオ」といって、マリオのROMを違法改造して、自作ステージをつくって無料公開などをする人たちがいました。 改造マリオはそもそも著作権侵害であり違法なのですが、その他にも問題点として、作成されたステージがやたらと難しすぎてクリア困難なステージばかりで溢れていた、という問題もありました。 しかしインターネット上では、そのようなクリア困難なゲームが、ネットのマニア達にはウケており、動画サイトなどではそのような超絶な高難度ステージが話題だったのです。 社会科学の格言で、「犬が人をかんでもニュースにならないが、人が犬をかむとニュースになる」という有名な格言があります。つまり、実際には統計的には少ない事例のほうがニュースとして話題になりやすいという、社会の法則があります。 また、アンケート調査などの心理学的ノウハウとして、「あなたは○○を買いますか？」と「あなたは○○を好きですか？」と聞いたときでは、 アンケート結果の傾向がかなり異なり、多くの人が、「○○を好きですか？」と質問されても決して実際に好きなものを答えるのではなく、 世間から賞賛されそうな趣味趣向の場合にだけ回答で「はい、好きです」と答えるようであるという、分析結果があります。 まさに改造マリオと本来の合法マリオの関係がそれです。 マリオメーカーでクリアチェックが必須なのは、せめて作者自身がクリアできるゲームをつくれ、常識的なプレイ時間で上達してクリアできるゲームをつくれ、というような任天堂の思いが伝わってきます。 おそらく任天堂の社内でも開発ゲームでは、各ステージのクリアチェックなどが行われているのでしょう。 }} {{コラム|ネット民の感性は信用できるか?| インターネット上には無料コンテンツがあふれておりますが、そのような無料コンテンツを楽しむ人たちのセンスは、一般の消費者のセンスとは異なりますし、もし仮に有料だとしても自分がカネを払うつもりもないものを平気で「面白い」と言える人たちも多く居ます。 それでも実際にプレイをした上での感想を言うならまだしも、しかしプレイヤーの人数よりも世界には無料動画の視聴だけをして感想を言うだけの人たちのほうが多いのです。 しかしそれすらも動画サイトでゲーム画面を長時間見ているので、まだしもマシなほうで、もっと酷いのになると、匿名掲示板で誰が言ったかも分からない批評や評論を真に受けて、あたかも実際にプレイしたかのように表面を装う人たちすらも多くいます。 マンガ業界も同じ問題に気づいてるようです。マンガ『ラーメン発見伝』（小学館ビッグコミックスペリオール ）では、作中のライバル役のラーメン屋経営者（いわゆる「ラーメンハゲ」）が、ネットの情報をもとにラーメンの実際の食べたときの味を無視してラーメン評論をする自称ラーメンマニアに陰口で悪態をついています。これにリアリティを感じるマンガ出版社があるわけですから、つまりマンガ出版社の目からも、世間一般の人って多くがそういうネットの風評に左右される人達だよねと見られているわけです。 本wikiもネットの情報の一部なので、鵜呑みにしないでください。お金は掛かりますが、参考文献などとして記載されているゲーム関連に役立ちそうな書籍を、読者は実際に何冊か買って、書籍の実物を読むなどしてください。あるいは実際にゲーム制作やプログラミングをするなどして、確かめてください、 文献『ゲームデザイン プロフェッショナル』では、著者の塩川氏が言うには、口コミやレビュー、プレイ動画によって「知った気になる」ことを有害であると戒めています<ref>『ゲームデザイン プロフェッショナル』、P.282</ref>。 だからゲーム作品を調査するなら、実際にクリアするまでプレイするか、あるいは十分なプレイ時間を投じてプレイしてみなければ、ゲームデザイナーにはあまり役立たないと、塩川氏は忠告しています。 たとえ短時間のプレイでは楽しく感じても、長時間のプレイや繰り返しの演出をされた場合には楽しくないような場合もあるので、だから長時間のプレイをして確認してみる必要があるとのことです。（以上、『ゲームデザイン プロフェッショナル』を参考にした。著作権の事情のため、言い回しや文体は多少は変えてある。） ただ、これは一見するとゲーム作家には、「偏見なく自作を最後までプレイをしてもらえそう」とか思えそうですが、しかしプロの作家は暇人ではないので、同人ゲームまで含めて何でもかんでもプレイすることはできません。 塩川氏は、著作の別のページでは。若者に進めるゲームプレイとして、とりあえずゲーム業界志望なら、まずは人気作や、過去の人気作、自分が作っているゲームのジャンルに近いものを選ぶのが良いと言ってます<ref>『ゲームデザイン プロフェッショナル』、P280</ref>。 これは裏を返すと、もし人気作や商業的な成功作でなければ、そもそもプレイすらしてもらえない、ということを意味します。塩川氏本人はそう言ってなくても、現実世界の時間は有限であるので、作品1つあたりのプレイ時間を延ばすことはつまり、1多くのプレイしてもらえない作品が生まれます。 つまり、塩川氏のプレイスタイルは、前提として、あるゲームについてプレイを開始するまでの条件が、めちゃくちゃ厳しいわけです。 イラスト業界でも類似の指南の事例があり、「アニメ私塾」といわれる有名イラストレーターは、YouTube動画などでプロのアニメ作品の模写の練習を進めていますが、しかし、おおむね発言内容「アニメ線画の模写ですら時間が何十分も掛かるので、練習に入る前にまず、その構図やデザインなどが自分にとって模写をする価値があるものかどうかを判定して、もし価値あると判定できた場合だけを模写しろ」と、判定にけっこう頭を使いなさい、と指南しています。 しかも「アニメ私塾」氏は、1枚の模写をどの程度まで模写すればいいかという質問に対しては「（模写先の手本に）似るまで模写しろ」とまで言っています。まるで、その1枚の手本を、模写のゲームクリアをするまで模写し続けるわけです。 さて、色々とゲームファンの問題点をいくつか前の段落で言いましたが、それでもゲームはアニメや漫画と比べるとまだしもマシであり、なぜならゲームではプレイヤーと、プレイしてない人たちの区別がしやすいからです。 これがアニメや漫画になると、もはや違法サイトで違法配布されたマンガを読んでるだけの人なのか、 実際に購入してプレイした人なのかの区別が困難になります。 実際、中国や韓国などでは、違法の無料配布されてしまったマンガがネットに溢れてしまった時期があり、 そのような事情もあり金融業界などはマンガ産業への投資を渋り、代わりに課金をしやすいオンラインゲームに投資をしたという経緯があります。 }} 文献『ゲームプランとデザインの教科書』によると、アナログゲーム（カードゲームやボードゲームなど）の設計の例ですが、ネット上の意見ではなく実際の目の前のテストプレイヤーの意見であっても、気を使ったりして本音を言わないことも多いので、意見や感想よりも実際のプレイを観察して、「プレイヤーがルールを勘違いしてないか？」など色々と観察するのが良いといわれています<ref>『ゲームプランとデザインの教科書』、P338</ref>。 {{コラム|イナズマイレブンの人気投票呼びかけ事件| イナズマイレブンという、男子小中学生くらいの子供をターゲットにした、サッカーのゲームおよびそのアニメ化作品があります。実際、ゲームなどでも平仮名を多用しているし、アニメなどでも振り仮名が多いですので、常識的に小学生くらいの子供がターゲットでしょう。 さて、このイナヅマイレブンの公式サイトが、ネット上での登場キャラクターの人気投票を行いました。 作品中で、「五条」（ごじょう）というマイナーな中学生キャラで、おっさんぽい顔のメガネで目が隠れて何を考えて分からない不気味な雰囲気の悪役っぽいキャラがいるのですが、ある有名な匿名掲示板のスレッドで、このキャラクターへの組織票の投票を呼びかけました。 その掲示板は、どう考えても子供が見ないような掲示板なのですが、しかし投票の結果、五条が一位になりました。 もし「ターゲット層の小学生の子供達が実は五条が一番好きだった」という理由ならそれでも構わないのですが、しかし投票の前後で「五条が子供に一番人気」という現象は特に観測されませんでした。「五条も子供に人気」という現象はあるかもしれません。ですが、「五条が子供に人気」という現象は結局は起きていないでしょう。 ネットの投票では、このような不合理な亊がたびたび起きます。 まず、年齢制限などをすることが不可能な場合が多いです。 また、本来なら「一人一票」などとしたくても、技術的な理由で不可能な場合もあります。 例えば、一人一票のために例えばツイッターなど外部サイトのアカウントを要求しようにも、しかし子供だとネット上のアカウント持つこと自体が不可能な場合もあります。たとえばツイッターの場合、年齢制限として13歳以下は利用不可能ですので、結果的に、小学生むけのアニメの人気投票をツイッターからの投票を呼びかけようとしても、技術的に不可能です。 アイドルグループのAKBなどでは、発売するCDに投票券などをつけることで、本当にカネを出して商品を購入したターゲット層だけが投票できるように工夫する場合もあります。ただし、AKB方式はこれで別の問題があり、一人の熱心なマニアが何票も投票したくて一人で何枚も同じ曲のCDを買うなどする、一般人とはかけ離れた購入行動をする事例があります。 また、アカウントなどを要求しない投票の場合、一日ごとに追加投票できてしまう場合があります。だから暇な人ほど、多くの投票をしてしまいます。 ;「美人投票」 経済学で、「ケインズの美人投票」という理論があります。これは、金融における株の購入行動では、人々は自分が良いと思っている株を買うのではなく、世間が「この株は上がるだろう」と思っているだろうと予想した株を買うというものです。 ですが、この五条の投票の場合はもはや美人投票ですらありません。ネットのある集団が、自分たちのコミュニティをアピールするために、意図的に、子供からは美男子・美形・好印象だと思われないであろうと予想したキャラに投票しているわけです。まるで逆美人投票です。 ;ノイジー・マイノリティ 世の中には、「口数は多い割には、人数は少ない」という集団があるのです。そのような集団を称して ノイジー・マイノリティ と言い、「うるさい少数派」という意味です。 しかし、うるさいだけの人に限って、企業などからは嫌われるので仕事がなかったりして、ネット上では口数が多いのです。 よく仕事や学生でも学校や家の軽作業などで、「口ばっかり動かしてないで、手を動かせ」などと年上から注意される事があると思いますが、まるでその逆の集団です。手を動かさない人は、口数でしかアピールできないのです。投票とは、そういう人にすら投票権を与えるという意味でもあります。 アニメやマンガなどの投票に関わらず、現実の政治の国会議員などへの投票でも、ある政治家へのネット掲示板などでの賛同は多いが、しかし実際に選挙をしてみると支持票がそれほど多くないという事例もよくあります。 また、暴力団などでは「総会屋」と言って、企業の株を少数でいいので購入し、株主総会での意見をよそおって、難癖をつけるぞとおどすことで、金品を要求するという手口も平成初期までは、よくありました（現在は規制されており、総会屋しづらくなっています）。一株など少数の株でも発言できてしまうので、こういう悪事が出来てしまったのです。 }} 文献『レベルデザイン徹底指南書』では、現実世界で自分が新しいスキルを1つ覚えたら、古いスキル1つはどれか封印する必要があることを説いています。たとえば会社で自らの希望によってグラフィッカーからプランナーに役職が変わったら、グラフィッカー時代のスキルは封印する必要があります<ref>大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81</ref>。（参考文献では「デザイナー」と言ってますが、デザイナーは多義語でありイラストレーターの他にも開発リーダーなどの事を言う場合もあるので、本セクションでは「グラフィッカー」に言い換えた。）プランナーがグラフィッカーの仕事まで掛け持ちしたら、過労死してしまいます。 現実世界の仕事では時間が限られているので、そういうスキル封印が必要なのです。 {{コラム|一人で何でもできるか?| 「と学会」の人が2010年ごろにニコニコ生放送の番組に出演したときに言ってたのですが、どこかのマンガ出版社に対して、「と学会」のその人はマンガ原作者にネタ提供したことあるとの事です。 大衆は、漫画家を一人で何でもできる万能の人だと錯覚したいので、そういう大衆を喜ばせるために、アドバイザーが隠れて、漫画家の知らないネタでしかも読者にウケそうなネタのアイデアを提供をするのです。マンガ作品のクレジットには書かれませんが、そういうビジネスがあります。 もっとも、業界によってはアドバイザーがクレジットに記載される場合もあります。たとえばテレビドラマやアニメなどだと、「考証」や「監修」などで、関連するジャンルの専門家がアドバイスすることもあります。たとえばNHKの歴史大河ドラマなら、東大あたりの大学教授で歴史学教授といったプロの歴史学者が、監修についている場合もあります。 アニメではそこまで行かなくても、ミリタリー物のアニメなどで、実際に銃器を仕事であつかった経験のある人が監修をついていたり、軍事雑誌の記者などが監修についたりとか、そういうこともあります。 }} {{コラム|可処分時間| 21世紀のビジネス用語で「可処分時間」という概念があります。 もともと「可処分所得」という経理などの用語があり、 「可処分所得」とは労働者が給料のうち、税金や社会保険料など支払いが義務付けられているものを差し引いた、 残りの（法的には）自由に使えるぶんの金額です。 実際には、水道光熱費といった公共料金など自由といえるかどうか分かりませんが、この議論では本質的ではないので深入りしないでおきます。 さて、可処分時間とは、可処分所得になぞらえて、可処分時間とは、おおむね、「1日のうちの自分の起きている時間のうち、労働時間などを差し引いた、残りの自由に使える時間」という意味です。 可処分所得に限りがあるように、可処分時間にも限りがあります。だから、商売の競争とは、消費者の可処分所得の奪い合いであると同時に、消費者の可処分時間の奪い合いでもあるのです。 1つの他人の作品に投じる可処分時間を増やしたら、当然ですが、他の作品への可処分時間の投入量が減ります。 こういう厳然たる事実があります。「可処分時間」という用語までクリエイターが覚える必要はないでしょうが、しかし消費者の時間に限りがあるという事実からは決して逃げることができないのです。しかもよく評論で「エンタメ界隈は、可処分時間の奪い合いの産業である」とも言われます。 クリエイターだって時間に限りがあります。たとえば、休日にもし自主制作の作品をつくっていたら、当然ですが、他人の作品を鑑賞する時間は減ります。 }} === クリア保証と戦術性のジレンマ === ==== クリア保証 ==== ドラクエのレベル成長のシステムは画期的であり、どう画期的かを一言でいうと「クリア保証」である<ref>[https://news.denfaminicogamer.jp/column05/170905b　『「レベルを上げて物理で殴る」の素晴らしさをゲームデザイナー視点で語ろう。ドラクエで学ぶ「RPGメカニクス」の3大メリット【ゲームの話を言語化したい：第四回】』2017年9月5日 16:30 ] 2020年12月21日に閲覧して確認.</ref>。どういう事かというと、参考文献のリンク先の記事にも書いてあるが、ファミコン以前の1980年代のアーケードゲームではプレイヤーが上手い操作を学習しないとクリアできなかったが、しかしファミコン以降の家庭用RPGでは、プレイヤーの興味ないことは学習しないでも、代わりにレベル上げなどに多少の時間を掛ければゲームクリアできるようになったのである。 たとえば、プレイヤーが攻略法のわからないダンジョンでも、最悪の場合でも経験値かせぎに多少の時間を掛ければ、そのダンジョンのボスを倒せるなどして、かならず最後にはゲームクリアが出来る、というような事でもある。 その他の例では、たとえばゲーム終盤になってから未探検だった序盤の一部ダンジョンを冒険する際、プレイヤーには既にもっと難しいダンジョンを冒険してるのでその未探検ダンジョンから学習できることは少ないが、プレイヤーキャラのレベルが高いために未探検の序盤ダンジョンの敵はプレイヤーにはすでに弱くなっているので、その残っていた未探検ダンジョンにあまり苦労せずに時間を掛けなくてもダンジョンクリアできるように、難易度が上手い感じに自動調節<ref>[https://news.denfaminicogamer.jp/column05/170905b　『「レベルを上げて物理で殴る」の素晴らしさをゲームデザイナー視点で語ろう。ドラクエで学ぶ「RPGメカニクス」の3大メリット【ゲームの話を言語化したい：第四回】』2017年9月5日 16:30 ] 2020年12月21日に閲覧して確認.</ref>されるなど、RPGのレベルシステムおよび類似システムにはそういった側面もある。 要するに、 :* クリア保証、 :* 難易度の自動調整機能、 の2つが、ドラクエ的なレベルシステムの面白さの本質的・醍醐味であるとのことである。 リンク先の人の意見ではないが、このクリア保証のないデザインのRPGは（RPGでも古いゲームやフリーゲームなどで時々みかける）、表面的にはドラクエ的なインターフェースやステータス画面であっても、中身は似て非なるものであろう。 ファミコン時代の古いゲームなどのバランス調整の失敗（作者にとっては意図的かもしれないが）でよくある失敗として、レベルの上昇の上限を低いところに設定しすぎて、クリア困難になる事例があった（ドラクエ2がそれに近い）。なので、現代への教訓としては、そもそもレベル制限は十分にとるのが安全であろう。 RPGに限らず一般に、ゲームの後半に行くに従って、次ステージ攻略などのための事前準備の増加や、試行錯誤の時間の増加に時間のかかるようになっていく事が多い。そして、ステージクリアに必要な時間の増加が、ゲームを苦手とするプレイヤーに、そのゲームのクリアを諦めさせて挫折感を味あわせてしまう原因になる場合が、少なからずある<ref>[http://endohlab.org/paper/whydoplayersdrop.pdf 遠藤雅伸『ひとはなぜゲームを途中でやめるのか？－ゲームデザイン由来の理由－』6.まとめ] 2020年12月21日に閲覧して確認. </ref>。 === 自由度 === 文献『ゲームクリエイターの仕事』（翔泳社）によると、一本道のゲームではなく攻略ルートが複数あって自由度があるゲームの場合、それら複数のルートも考慮する必要があります。ゲームの自由度が多くなれば、その「場合の数」に応じて、調整の際に考慮する事項も増えます<ref>『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖！』、P78</ref>。 === 勉強の方法論 === ※ バランス調整に限った話題ではないが、他に適した単元が見つからないし、メインページに書くほどでもないので、間借り（まがり）的にバランス調整のページで書くことにする。 ==== 共通言語 ==== ゲーム業界人たちは商売人なので、いろんなゲームをプレイするように推奨します。しかし現実には、それは費用的にも時間的にも不可能です。 商業ゲーム会社でゲームデザイナーになりたいのなら、人気作のゲーム知識は必要です。手本とするためという理由の他にも、スタッフなどに開発コンセプトなどを説明するためにも過去作のゲーム知識が必要になります」（いわゆる「共通言語」）<ref>『ゲームデザイン プロフェッショナル』、P278</ref>。 とりあえずゲーム業界志望なら、まずは人気作や、過去の人気作、自分が作っているゲームのジャンルに近いものを選ぶのが良いといわれています<ref>『ゲームデザイン プロフェッショナル』、P280</ref>。 ==== 前後比較 ==== ゲーム制作において、人気作や人気シリーズを、手本の中心にすえる必要があるが、しかし、けっして人気ゲームだけをマネしようとしてはいけない。名作が名作である意義を確認するためには、同時代の他社の作品や、それ以前の過去の作家の作品に、どういう欠点があったを把握する必要がある。そうした前後関係の比較により、理解が深まる<ref>[https://news.denfaminicogamer.jp/interview/200615a/3 吉田寛・松永伸司『“ゲームらしさ”をもっと深く語りたい！そんなあなたのためのゲームスタディーズ入門』、電ファミニコゲーマー、2020年6月15日 12:02 ] 2020年11月27日に閲覧して確認.</ref>。 なお、同様のノウハウはアニメ研究の業界でも1990年代から語られており、たとえばアニメ評論家の岡田斗司夫や氷川竜介などが、絶版になってしまったが岡田らの共著『国際おたく大学―1998年 最前線からの研究報告』などの書籍の中で例を述べており<!-- 手元にその本が無いので、もしかしたら別の著作かもしれないが、岡田らの共著のどれかではある。 -->、たとえばアニメのガンダム初代がリアリティゆえに名作であることを評論したいならば、それ以前の時代のロボットアニメが如何にリアリティが欠けていたかを実際にビデオなどで視聴するなりして確認しなければならないと岡田・氷川らは述べていた。 ともかく、ゲームでも、名作ばかりプレイしていてもダメであり、つまり知名度だけでプレイするゲームを選んでいては、他のクリエイターに利用されて養分になるだけであろう。 岡田斗司夫と「と学会」の著作した『 岡田の国際おたく大学―1998年 最前線からの研究報告』では、書籍中で、ゲーム作家を経験した演劇作家の鴻上尚史（こうがみ しょうじ）の失敗例を東大生が取材したレポートを紹介しているのですが、岡田がそのレポートを評して言うには、おおむね「成功例から学ぶたがる人は多いが、しかし成功例だけから学ぶのは素人。プロは失敗例にこそ学ぶ。」というような感じのことを言っています。 工学の世界では、『失敗学』という概念が畑村洋太郎によって提唱されており、2002年の畑村の論文<ref>[https://www.jstage.jst.go.jp/article/jjlp1960/43/2/43_2_182/_pdf 『失敗学のすすめ』]</ref>や、2000年には畑村の著作『失敗学のすすめ』が出版されています。 （wikipedia日本語版には「2005年」に出版とあるが、間違いである。2002年の論文で、2000年の畑村の著作が参考文献とされている<ref>[https://www.jstage.jst.go.jp/article/jjlp1960/43/2/43_2_182/_pdf 『失敗学のすすめ』]</ref>。） 実は、2000年よりも前に、ゲーム産業限定ですが岡田が「失敗にこそ学ぶべき」といった内容のことを提唱しています。なお、畑村の論文の末尾の参考文献欄には、『 1) 畑村 洋太郎 編 著:続・続 実際の設計― 失敗に学ぶ .日刊工業新聞社,1996.』とあります。 {{コラム|失敗とスポーツの例え話| ビジネス書で昔からよく言われるのですが、新しいことへのチャレンジには失敗はつきものです。 でも、新しいことにチャレンジして経験を蓄えることが、今後の成功につながるのです。もし失敗をおそれて新しいことにチャレンジしなくなったら、もはや次の成功にはつながりません。 失敗しないけれど成功もしないで市場から淘汰されることになるよりも、失敗してもいいのでそれ以上の大成功をおさめて市場で行き続けることができればいいのです。 よくビジネス評論ではスポーツに喩えられるのですが、スポーツのサッカーや野球などの試合にたとえれば、3点を奪われても、こちらが5点を得て結果的に勝てればいいのです。 逆に、1点しか奪われなくても、こちらの得点が0点なら、試合には負けます。 だから、「試合での負け」に相当するような致命的な失敗さえ、回避できればいいのです 「たとえ失敗しても、試合に負けなければいい」のです。「失点しても、試合に負けなければいい」のです。 塩川氏も、失点しても試合に勝てれば良いという内容のことを書籍で発言しています<ref>『ゲームデザイン プロフェッショナル』、P.334</ref>。 さて塩川氏の著作では、失点でない単なる「ミス」を「不具合の発生」、「失点」をユーザーの不利益、「負け」を「売り上げの低下やユーザーの離脱」（長いので抜粋）などと定義しています。 塩川氏の意図は分かりませんが、少なくとも新しいことにチャレンジすれば、未知の失敗は起きますので、ITソフト業界なら、それによる不具合の発生が起きます。 その不具合の結果、ユーザーに不利益が一時的に生じることはあります。しかし、そういう一時的な不利益は、新分野の開拓では避けられません。 ユーザーで実験する前の、最低限の手元や仲間内での実験は必要でしょうが、しかし未然の実験で今後のすべてのミスを防止することは不可能です。 }} === 異業種の立場を想像しよう === ゲームにかぎらず、文芸でもイラスト趣味でも、、狭いコミュニティ内の内輪ウケばかりに特化していって衰退していっている文化は多い。そうならないように気をつけよう。 内輪受けのマニア化による初心者忌避による衰退をうまく表現できている言い回しとして、プロレス業界の格言ですが「マニアが業界を潰す」という格言があります。なお、この発言は2012年に新日本プロレスリングを買収したゲーム会社のブシロードが買収時に述べた発言「すべてのジャンルはマニアが潰す」が元になっているので、まさにゲーム業界の反省にもとづく考察でもあります<ref> [https://newspicks.com/news/4135958/body/ 『【最終話・木谷高明】すべてのジャンルはマニアが潰す』 2019/10/5 ] 2021年11月7日に確認</ref>。（ブシロードの文脈とは違うかもしれませんが（出展の外部リンク先が有料なので読んでいないので）、本wikiでもおそらく後述していますが、ゲーム業界では1990～2000年の一時期、ジャンルによってはゲームが高難易度化した作品が多くなって、そのため新規参入者が苦手と感じてプレイヤーが減って衰退縮小していったジャンルが幾つかありました。） なので、ゲーム製作のこういった予備知識のないファンコミュニティの意見ばかりを鵜呑みにして聞いていると、初心者を遠ざけた高難易度ゲームと化してしまうおそれもあります。 特にゲームセンターにある対戦格闘ゲームでは、「初心者狩り」といって、初心者が筐体で練習したくても、熟練プレイヤーが参入して初心者を負かして初心者がゲームプレイヤーになるので、初心者は練習できない。・・・その結果、気がついたらそのゲームの新規参入層が減っていった・・・という事例がありました。 ゲームにかぎらず、スポーツなどの競技の人気でも、似たような現象が見られます。競技というジャンル自体が技巧などを競うものなので仕方ない面もありますが、なんとかして初心者を遠ざけない工夫はゲーム屋には必要でしょう。 ともかく、上述のような色々な理由で、作家側は、体感の難易度が、本当は難しめのゲームなのに「やさしめ」に感じがちである。 実際、日本のゲーム史でも、1990年代の前半ごろは、ゲームの難易度が「むずかしめ」に調整されがちであった。しかし、その結果、世間では「最近のゲームは難しい」と感じる人が増え、日本のゲーム人気は一時期、衰退し、アニメ産業などに人気を取られる事態になった。 {{コラム|作者は答えを知ってしまっている| バランス調整とは少し違いますが、作者はネタバレを知ってるので、シナリオに感動できないわけです。 これは、ハドソン（ゲーム会社名）の『新桃太郎伝説』（スーファミ版）の攻略本『新桃太郎伝説　究極本』（KKベストセラーズ 刊）で、作者の　さくま　あきら　が、読者インタビューに答える形でそう言っています。 ゲーム雑誌での読者からの「ゲーム中、もっとも印象に残ったシーンはどこですか？」という旨の質問に対し、さくま氏は「作者はシナリオの答えを知ってるので、もっとも印象に残るとかそういうのはありません」的な内容の返答をしています。 }} ;ティッシュテスター さて、作者バイアスでバランスが分からなくなるのは作者だけではなく、テストプレイヤーやデバッガーも、そのゲームに慣れてゆくと、次第に感覚が一般プレイヤーとズレていき、テストプレイヤー達もゲームの適切なバランス側が分からなくなっていく。 このことを比喩した表現として、「ティッシュ テスター」（tissue tester）という用語がある。使い捨てティッシュが1枚あたり1度しか使えないように、そのゲームに予備知識の無いテスターも、一度しか使えないのである。「フレッシュミート」（新鮮な肉、fresh meat）とも言います。 かといって、テストプレイヤーの人数にも限りがあるので、ゲーム作者は、たとえ自作ゲームのバランス調整が不完全でも、最低限の調整をしたら、もう「えいやっ」と（フリーゲームや同人ゲームなら）ゲームのver1.00および以降バージョンを出さざるを得ない。 単にバグを探すだけのデバッグ用テストならティッシュテスターでなくても可能ですが、しかしバランス調整ではティッシュテスターがいたほうが効率的です。 === 要素の相互関係 === ==== 概要 ==== 文献『ゲームデザイン プロフェッショナル』によると、調整は、関連あるものを、まとめて同時期に、ただし1個ずつ調整していきます<ref>『ゲームデザイン プロフェッショナル』、P.182</ref>。 このため、まだ関連ある要素を実装しきっていない段階では、調整しません。だから開発の最初から調整することは、まず無いでしょう。 しかし、場合によっては、要素の実装をそろうの待つと調整開始の時期が遅くなりすぎてしまい、計画に支障が出る場合があります。そういう場合、ある程度のまとまりのある実装ができた段階で、調整をするようです。 具体的な調整の判断基準については、参考文献『ゲームデザイン プロフェッショナル』を買ってお読みください。 もし読者が練習として、てっとり早くレベルデザイン・バランス調整の経験を積みたい場合、角川書店（現: KADOKAWA）の『RPGツクール』という制作ツールで実際にゲームを作ってみるのが良いでしょう。文献『レベルデザイン徹底指南書』（大久保磨 著）でも、RPGツクールによる練習・勉強を進めています<ref>大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81</ref>。 ==== マップと敵の相互関係 ==== ゲームバランスを決めるのは、敵の強さだけでなく、マップの構成、さらにRPGのダンジョンなら宝箱の中にあるアイテムや装備品の強さ、などなどのさまざまな要素が加わります。 宝箱もマップの構成要素ですから、広い意味では宝箱もマップだとすると、つまり敵そのもののの強さだけでなく、マップもバランス調整に大きく影響します。だから、もし仮に時間が無限にあるのなら、理想的には、ダンジョンなど各ステージののマップが実装されてからバランス調整を行うのが理想でしょう。 しかし、実際には、マップの実装は、なかなか時間の掛かることです。特に、マップを考えることは、そのステージの世界観などを考えることでもあるので、そういった理系的ではない文系的なことも考えなければなりません。 マップに敵を組み込む方式で調整する場合だとマップの実装を待っている間にはバランス調整が出来ないのも、なかなか難しい問題です。 だからマップと敵の調整の順序は、おそらく人や会社によって色々な方式があると思います。たとえば、 :マップを作ってからそのマップに敵を組み込んでみてプレイしてみて、敵の強さを決めるのか、 :それとも敵の強さを決めてから、マップを決めるのか、 :あるいはマップと敵を別々に決めてから、最後に組み合わせて微調整するのか、 などなどです。 ご自身の作品にあった方式をお選びください。 ===== 始めよければ全てよし ===== さて、ゲームが長編になる場合、まずはプロトタイプ的に、序盤をやや多めに通しプレイをして、とりあえず序盤のバランスがゲームとして面白くなるように調整すると良いでしょう。 書籍『ゲームプランナー集中講座』でも、ゲームの初めと終わりの印象がよければ、途中のバランスが少しくらい悪くても楽しんでもらえると述べています<ref>『ゲームプランナー集中講座』、P236</ref>。 :※ なお、アニメ産業でも、実はテレビアニメは、第1話と最終話だけ、他のエピソードよりも予算が多めに作られるのが普通です（特に公言はされてないが、多くの作品で明らかにクオリティが違う場合が多い）。 とはいえ、ゲーム制作当初は、そもそも終盤のストーリーがまだ未完成だったりするので、意図せずとも、こういったプロトタイプ的に序盤をやや多めに調整する方法が自然に行われる事になるでしょう。 商業作品でも、たとえば攻略本やファンブックなどに書いてあるゲーム開発裏話などを見ると、RPGでは、（プレイヤーからは数値の見えない）敵の強さのほうを動かすことで、バランスを調整するという事例などもよく紹介されています。よくある話が、最終ボスなどの能力値です。原理的には、敵側の能力値ではなく、味方の能力値で調整したり、あるいは装備品で調整したりしてもイイはずですが、しかしよく開発裏話に出てくるのは、なぜか敵側の能力値の話題ばかりです。 たとえば、スーファミRPG『新 桃太郎伝説』では、最終ボスのパラメータのほうを調整していることが、KKベストセラーズ（出版社名）から出た攻略本『新桃太郎伝説究極本』に書かれています。（調整前はボスはもっとHPが多かった。） :※ただし、あくまでRPG限定の話題。アクションゲームなどでは、違うかもしれない。 また、こういった調整順序の前提として、調整はゲーム序盤から順番に、ゲーム後半に向かって調整していくしかありません。 そのため、古いゲームなどでは、よくゲーム後半で、調整不足のために、極端に難しかったり、あるいは逆にあっけなく簡単すぎる後半だったりなどの話題も、よく聞きます。ドラクエ2の後半ダンジョンであるロンダルキア洞窟とその次ステージが典型です。 さて、プレイヤーに目立つ部分（たとえば味方キャラの能力値や装備品の性能など）を基準にして調整するといって、けっして全く数値をイジラないというワケではないのです。あくまで、（調整による変動幅の大きい敵能力値と比べたら、）「比較的には、味方キャラ関連の数値は、調整による数値の変動の幅が小さめ。敵の能力値は、調整による変動の幅が大きい。」という事にすぎません。 {{コラム|ノイマン「ゲーム理論」で説明できないのがテレビゲーム| 日本の人類学者の中沢新一は、ノイマンのゲーム理論で説明できないのが昨今のコンピュータゲームの特徴だと言っています。その発言の出典は忘れたのですが、人類学者で有名な中沢新一は近年、ゲーム産業に関心を持ち、たとえばナムコ出身の遠藤雅信などとも対談しています<ref>https://news.denfaminicogamer.jp/kikakuthetower/nakagawa-endo_bb/2 『ゼビウスからポケモンGOまで… 国内ゲーム史を遠藤雅伸氏と『現代ゲーム全史』著者が振り返る。中沢新一氏も壇上に登場！【イベントレポ】』 2017年4月12日 12:30 公開 ] 2022年1月18日に確認. </ref>。（なお、リンク先イベント記事の司会役の「中川」氏とゲストの「中沢」氏は別人なので、混同しないように） ゲーム理論の用途としては、現代日本の学問では、政治的局面での外交戦略などを語る際によく政治学書で用いられたりします。ただし、そのゲーム理論でも、中沢新一によると、それでコンピュータゲームを語るのは不足だという事です。 中沢は特に言及していないですが、数学的にモデル化するなら、政策応用なら「国際情勢」など外交的な制約によって出力にとりうる値1個あたりの幅や個数が2～3個に限定されたりのような、値の個数が十分に小さくて有限の整数個の場合でないと、なかなかゲーム理論の応用は効果を発揮しません。 （20世紀の天才数学者 フォン・ノイマンの）『ゲーム理論』のような出力値に選べる個数が極端に少ない理論は、コンピュータゲームの調整では不足でしょう。本ページでも、ノイマンのゲーム理論については、版にもよりますが、このコラム以外では特に言及していないだろうと思います（2022年1月までの時点では、ノイマンのゲーム理論には言及していない）。 さて中沢の意見ではないですが、そもそもゲーム理論についてノイマンについての出典として、たしか数学者の森毅（もり つよし）のエッセイ本だったと思いますが、ゲーム理論はもともとノイマンが第二次大戦中の亡命中か何かにトランプのポーカーを参考に考えついたらしいです。 ネット上のゲーム評論では、経済由来の表現でよく使われる表現は、ゲーム理論ではなく「インフレ」「デフレ」などといった表現です。 経済学を知らなくてもゲームは製作できるでしょうが、どうしても経済学を参考にするなら、ゲーム理論よりも物価政策のほうを勉強したほうが良いかもしれません。 一応、書籍『ゲーム作りの発想法と企画書の作り方』ではゲーム理論も紹介されていますが、しかし具体的にどうゲーム作りにゲーム理論を応用するかは書かれていません<ref>『ゲーム作りの発想法と企画書の作り方』、P64</ref>。 }} === 各論（デザイン的なこと） === どの程度、レベル上昇でキャラクターを強くすればいいかについては、ハドソン社あたりでの有名な慣習があり、新しく訪れたダンジョンなどでは「レベルが3上がると、敵を1撃で倒せるようにすべし」という有名な基準があります<ref>『ゲームプランとデザインの教科書』、P.94、 ※ 著者のひとりの「平川らいあん」氏はハドソン出身</ref>。他社ゲームでは別かもしれませんが、だいたいスーファミ時代の桃太郎伝説シリーズはこんな感じに調整されているはずです。 == RPGのダメージ計算式 == === 特化型が有利になりやすい === 文献『ゲームプランとデザインの教科書』によると、ファミコン時代のゲームに限らず、21世紀の現代的なゲームでも、「なんでも平均的にできる」キャラクターよりも「○○だけなら自分が一番強い」といった感じの特化型のキャラクターが戦闘では強くなりやすい傾向があります<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.227</ref>。対して、バランス型は「器用貧乏」になりやすいのが現状です<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.227</ref>。 なお文献『ゲーム作りの発想法と企画書の作り方』によると、ダメージ計算式を考えるのは（プログラマーの仕事ではなく）ゲームデザイナーの仕事です<ref>『ゲーム作りの発想法と企画書の作り方』、P145</ref>。 では、特化型が有利になりやすい原理を、これから説明していきます。 たとえば、キャラクターに能力をプレイヤーが自由に選んで振り分け配分できるシステムのゲームがあったとしましょう。（商業ゲームでも、いくつかの作品で、似たようなシステムのRPGがあります。） 説明の単純化のため、合計値が必ず100だとしましょう。 つまり、たとえば下記のようになります。 ;作成キャラの能力例 :（※ 合計100） ちから: 10 たいりょく: 30 しゅびりょく: 10 すばやさ: 40 きようさ: 10 さて、別の作成キャラ例を考えます。 ;平均型キャラA ちから: 20 たいりょく:20 しゅびりょく: 20 すばやさ: 20 きようさ: 20 :（※ 合計100） のように、能力値を平均にふりわけたキャラクターと 合計値は同じですが、特定のパラメータに特化して能力値を振り分けした ;特化型キャラB ちから: 40 たいりょく:20 しゅびりょく: 30 すばやさ: 5 きようさ: 5 :（※ 合計100） のようなキャラクターを、 コンピュータ上でRPGの戦闘システムのアルゴリズム上で対戦させた場合、 ほとんどの20世紀のRPGのアルゴリズムでは、特化型のキャラBのほうが勝ち、つまり特化型のほうが強くなってしまいます。 さらに言うと、たいてい「攻撃力」のような、敵にダメージを与える意味のパラメーターに振り割ったほうが、キャラクターが強くなるゲームのほうが多いです。（ファミコン時代から、ウィザードリィ1の攻略本でそういわれていました。敵モンスター『ワイバーン』あたりの攻略法として「攻撃は最大の防御」という格言を出しています。表紙の黒かった攻略本なので、たぶんゲームアーツの本。『ウィザードリィ攻略の手引き』(MIA BOOKS)かと思われます。） なぜこうなるかと言うと、なぜなら、もし攻撃力が上がると、敵を倒すのに要するターン数も減少するので、結果的に敵を倒すまでに自キャラの受けるダメージ量も減るからです。（なお、現実の軍事学でも、似たような事が言われており、戦術論ですが、クラウゼヴィッツ（近代ドイツの軍事学者の一人）は防御重視の作戦よりも攻撃重視の作戦のほうが有利だと述べています。防御だけで攻撃しなければ、現実でもゲ－ムでも戦闘では絶対に勝てません。） 裏を返せば、平均型能力のキャラは、多くのゲームシステムでは弱くなりがちです。 パラメータの振り分けは自由ではないですが、ドラクエ2（ファミコン版）でいう、サマルトリア王子が弱くなる現象です。ファイナルファンタジー3・5の赤魔導師も、似たような弱点を抱えています。 理由はいろいろとありますが、バランス側の弱くなりやすい理由のひとつとして、参考文献などは特には無いですが、 :・ウィザードリィやドラクエなどの古いRPGのアルゴリズムが、特化型に有利になっているという歴史的な経緯。 :・命中率などの確率に関わるパラメータ（「器用さ」）のある場合、パラメータ割り振り前から既にある程度の底上げ補正がされている場合が多いので、わざわざ命中率を上げると割り損になる。 :・「すばやさ」（素早さ）が攻撃の順番にしか影響しない場合、素早さが低くても1ターンに1度は攻撃できるので、素早さを上げると損。 などの理由があるでしょうか。 命中率に関しては、多くのRPGで、攻撃が外れるのは、プレイヤーに不満感を与えるので、たいていのゲームでは、ゲーム序盤のレベル1のキャラであっても、数値上での「命中率」や「器用さ」などの表向きの命中率が低くても、たとえば「命中率 40」と表示されていても、実際のゲーム内部での命中率はたとえば＋20%されてて本当の命中率が60%だったりするような場合もあります。 このような底上げ命中率のあるシステムだと、20%底上げされる場合、命中率を80%以上に育てるのは損です。なぜなら100%以上には上がりようが無いからです。 命中率が101%以上の場合に特殊な追加スキルなどを獲得できるなら別ですが（たとえば、クリティカルヒットの確率がけっこう増えるとか）、たいていの古いゲームでは、そこまでの手入れをしていません。おそらく調整に時間が掛かるからでしょう。 === ダメージ計算式 === さて、RPGの戦闘におけるダメージの計算式（「ダメージ計算式」といいます）に、アルテリオス計算式というのがあります。これは、昔のゲーム『アルテリオス』で採用された計算式なのですが、 攻撃側の攻撃力 － 守備側の守備力 ＝ 守備側のダメージ という計算式です。 ドラクエやファイナルファンタジーのシリーズの計算式はもっと複雑なのですが、どのRPGでもダメージ計算式の基本的な設計思想・方針はアルテリオス計算式と同じです。 アルテリオス以外のダメージ計算式でも、たとえば :1.3×攻撃側の攻撃力 － 0.75 × 守備側の守備力 ＝ 守備側のダメージ というような感じの計算式である作品も多いです。 せいぜい、変数の前に定数係数が掛かっている程度です。 なぜ、どの会社のRPGでも、この程度の中学校レベルの単純な計算式なのかというと、バランス調整が簡単だからです。 バランス調整するのは人間なので、もし、ダメージ計算式があまりに複雑な方程式であると（たとえば量子物理のシュレーディンガー方程式みたいなのだったりすると）、そもそもバランス調整担当の社員が理解できません。 そして、このアルテリオス式を見ると分かるのですが、 :攻撃側の攻撃力 － 守備側の守備力 ＝ 守備側のダメージ もし自軍の攻撃力が0の場合、敵にダメージを与えられないので（ダメージが0）、絶対に負けてしまいます。つまり、攻撃力が敵の守備力を下回る場合も、絶対に負けるのです。 一方、「すばやさ」パラメータが戦闘の先攻/後攻の順番にしか影響しない場合、素早さが0であっても、勝つことは可能です。 また、守備力が0であっても、勝つことは可能です。 このように、パラメータの種類ごとに、そのゲームにおいて重視・軽視の差があり、不公平になっている事が多いのです。 また、バランス型の能力値のキャラクターの場合、せっかく「ちから」を上げて攻撃力を上げても、守備側の守備力を下回っていると、ダメージ0になってしまい、絶対に負けます。 つまり、 自分の攻撃力 ＞ 敵の守備力 でないと、アルテリオス式では必ず負けるのです。 一方、 :1.3×攻撃側の攻撃力 － 0.75 × 守備側の守備力 ＝ 守備側のダメージ のように係数を掛けた計算式の場合、 守備力を1ポイント増やしても、その効果は25%減少されます。（たとえばレベルアップの際に上昇パラメータを一種類選べるシステムの場合、守備力を選ぶと損になる場合が多い。） いっぽう、攻撃力を1ポイント増やすと、効果は30%増しです。 このように、計算式によって、有利/不利なパラメータという格差が生じます。 === DPS （Damage Per Second） の概念 === :※ 出典は無いが、あまりに有名な概念なので、さすがに消さない。 最近のRPGゲームには攻撃コマンド選択時に「二段斬り」などのスキル選択ができます。 スキルを設計するとき、昔の初心者のやりがちなミスとして、最近は減ってきましたが、スキルの結果の見かけの数値にゴマかされて、実はスキルが強くなってない特技を設計してしまうミスが時々ありました。 たとえば典型的なのは特技『ためる』です。これは、次回ターン時のダメージを数倍に倍増し、次回ターンの1回だけ、ダメージを倍増させる特技です。 この『ためる』は必ず、次回ターン時のダメージが2倍を超えないと（たとえば2.5倍にならないと）、無意味です。 なぜなら、『ためる』コマンドを選択したターンは、攻撃をしてないからです。 つまり、スキルを使わずに普通に2ターン通常攻撃した場合、ダメージ量は単純計算で :1+1=2 より、2ターンぶんのダメージです。 いっぽう、『ためる』コマンドを使えば、それがもし2倍しかダメージが倍増しない場合、 :0+2＝2 で、結果は同じ通常攻撃2発ぶんのダメージのままです。 計算すれば子供でも分かる理屈ですが、しかしファミコン時代には市販の商業ゲームですら、こういうミスがありました。たとえばファイナルファンタジー3の職業『空手家』のスキル『ためる』です。 このようなミスを犯さないために必要な概念としては、'''DPS''' （'''D'''amage '''P'''er '''S'''econd） の概念が便利でしょう。DPS とは1秒あたりのダメージ量、という意味です。 もともと欧米のアクションゲームについての理論研究に由来する用語なので、単位が 秒 （second）になっていますが、RPGに応用する場合には単位をターンに変えるなどして工夫しましょう。 このDPSの概念を使って、上述の『ためる』コマンドの設計ミスを説明すれば、つまり、1ターンあたりのダメージ量（DPS）が上昇していないのが問題点です。 では、私たちが改善策を考えましょう。数学的に考えれば中学レベルで充分で、 : 0 + x ＞ 2 を満たす変数xを設計するだけの問題です。 なので、たとえば、『ためる』後の攻撃ダメージ量を「2.5倍」とか「3倍」とかの数値に設計すればいいのです。 では、次に応用問題を考えましょう。 「『ためる』を2回続けると、さらにダメージ量がアップ」などのシステムを導入するときも、必ずDPSが増えるようにしましょう。 たとえば、この場合、ダメージを与えるのに最低3ターンが必要なので、不等式を考えれば、 変数xについての :0 ＋ 0 ＋ x ＞ 3 を満たさないといけません。 つまり、『ためる』2回後のダメージ量は、最低でも「3.5倍」のように3を超える数値、あるいは整数に限定すれば、たとえば「4倍」とか「5倍」とかになっている必要があります。 == KPI == Key Performance Indicator という経営的な指標があり、『レベルデザイン徹底指南書』P140 および 『ゲームプランとデザインの教科書』P70 によると、共通しているのは後述の内容です。なお、『ゲームプランとデザインの教科書』P67 によると、オンラインゲームの運営などで使われる用語ですが、別にゲーム業界限定の用語ではありません。 ;DAU（Daily Active User） :デイリー・アクティブ・ユーザー DAUとは、その日に遊んでくれたユーザーの人数です。 ;MAU（Mathly Active User） :マンスリー・アクティブ・ユーザー MAUとは、その月に遊んでくれたユーザーの人数です。 ;WAU（Weekly Active User） :ウィークリー・アクティブ・ユーザー WAUとは、その週に遊んでくれたユーザーの人数です。 ;PU（Paying User） :ペイング・ユーザー 課金ユーザーの人数のことです。その日を課金ユーザー人数をDPU、その月の課金ユーザー人数をMPUと言います<ref>『レベルデザイン徹底指南書』、P140</ref>。 ;課金率 たとえば、ある月のユーザ数のうちの課金ユーザーの割合など、 一定期間中の課金ユーザーの割合を言ったりしますす<ref>『レベルデザイン徹底指南書』、P140</ref>。 あるいは、全ユーザーのうちの課金ユーザーのことだったりしますす<ref>『ゲームプランとデザインの教科書』、P70</ref>。（書籍によって、内容が微妙に違う） ;継続率 前月と比べて今月はどんだけユーザーが残っているかとか、あるいは前週と比べて今週はどんだけユーザーが残っているかのことを、 継続率といいます。 （以上） このほかにも、色々な指標があります。 == 参考文献・脚注など == tigy1p46ed11fhhisbi0mwm4lt3mhvu 206118 206063 2022-08-01T11:16:34Z Honooo 14373 /* バランス調整 */ 前文のみ修正。1/14。 wikitext text/x-wiki {{substub}} 現在の版の著者達は、ゲーム戦闘の調整の経験はないので、現状では本ページの内容は調べ物としては役立ちません。経験があり、かつ人間性も良好な人の協力をお待ちしています。 ==本ページの目的== 本科目『ゲームプログラミング』は、科目名に「プログラミング」とあるとおり、ゲームクリエイターのための教材ではなくプログラマーのための教材です。 従って、話題がプログラミング的な技術的な話題に片寄っています。一般のゲームクリエイターを目指す人には、本書のバランス調整の記述は到底、役立ちません。 プログラマーが、とりあえず何か趣味でゲームを作る際、バランス調整についての調べ物の手間を少なくするためだけの目的の教科書です。 ……と、前編集者Suj. は書いたんだけど、その割にはこの人物の私欲を満たすためだけの駄文が結構くどくど書かれてる気がするんだけど… 気のせいか？まあまだちゃんと読んでないしね、熱でもあるのカナ? コロナか^^? ==バランス調整== ゲームには難易度というものがあるが、そのゲームの面白さのため、あるいは商品としての購買力アップのため、調整し、最適値を見出す必要があるだろう。敵の強さや主人公の強さ、それらを調整し、最適値を見出すための調査、テストプレイなどが必要だ。 より普遍的に、バグ修正、操作性の改善、仕様実装の更新、そして今書いたバランス調整、ゲームを面白く、評価を高めるための様々な改善を、一般にチューニングと呼んでいる。 英語では、難易度の調整のことを「レベルデザイン」と言う。このレベルとは、高低差の意味で、欧米での昔の3Dゲームにおける、マップの高低差を意図しているらしい。このレベルを調整するツールをレベルエディタというが、このマップの高低差の調整で難易度が変わるので、しだいにレベルデザインが難易度の調整の意味になっていったという<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.57</ref>。 難易度デザイン、という言葉も使われている<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.58</ref>。 そして、難易度の調整にはマップの処理もあるので、3Dゲームのレベルデザイン担当者は、MAYAなどの3Dグラフィックツールの技能を持っているスタッフが多いという<ref>吉冨賢介『ゲームプランナー入門』、P234</ref>。 === 「詰み」防止の確認 === 商業ゲームでは、クリア不能な状況にてプレイヤーがセーブしてしまい、ゲームを最初からプレイしなおす状況にプレイヤーが追い込まれること（いわゆる「詰み」（つみ） ）を絶対に防がなければなりません。 文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、このためバランス調整でも、プレイヤーがそういう「詰み」に追い込まれないようにする必要があります<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P78</ref>。 まず前提として、平均的なプレイヤーなら普通にクリアできる調整をしておく必要があります。 その上で、詰みを防止するためには、ゲームがとてもうまいプレイヤーでよいので、最低でも1人が、そのゲーム中で想定できる理論的に最もクリア困難な状況からですらも挽回してクリアできるという、クリア実績が必要です。 時間の制約などもあるからか、文献によれば、非常に上手い人が一度でもクリアしたという実績があれば良いという調整になるようです<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P78</ref>。 もちろん、前提として平均的なプレイヤーの多くが平均的な練習でクリアできるようになっているという環境の上です。 === プレイヤーの面倒くさがること === 『ゲームプランとデザインの教科書』によると、ゲーム中で一般的なプレイヤーの面倒くさがることとして、 覚えること、計算すること、配ることを面倒だと感じると言われています<ref>『ゲームプランとデザインの教科書』,P342</ref>。 === 消費者の趣向の変化 === 家庭用ゲーム黎明期の1980年ごろと比べて西暦2000年以降では、消費者に好まれるゲームの難易度バランスが違っています。 ;用語「難しい」の変化 ファミコン時代の昔と21世紀の今とで、ゲーム消費者の感じる「難しい」という言葉そのものの程度や意味が、昔と今で、やや違います。 文献『ゲームプランナーの新しい教科書』によると、たとえば携帯ゲームにおいて、平均的なゲームプレイヤーがクリアまでに5回ゲームオーバーになるように調整されたゲームは、21世紀の現代では「難しい」に分類される場合もあります<ref>『ゲームプランナーの新しい教科書』、P210</ref>。 一方、同文献によると「やさしい」とは、「平均プレイヤーならゲームオーバーにならない」という程度の意味です。 「難しいゲームの○○が人気！」などのニュースを目にしても、もしかしたら、そのジャンルのターゲット層の考える「難しい」の意味が、ファミコン的な昔の意味とは違うかもしれません。気をつけましょう。 その他、文献の情報ではないですがテレビ番組ですが（番組名は忘れた）、2011～2013年頃のテレビ番組で、ゲーム業界を取材した番組があったのですが（番組名は忘れました。たしか夜中の番組でした。）、 ゲーム会社だかゲーム業界の人がインタビューで :「 昔の子供は、難しいゲームをプレイしたとき、「このゲームは難しい」と答えていたが、今の子供は「このゲームはつまらない」 と答える」という話をしています。当時、アニメ業界やゲーム業界などを取材した番組がいくつかあったのです。 === どの程度の難易度を狙うべきか === 『ナナのリテラシー』というビジネスノウハウ系の漫画があるのですが、これの2巻がゲーム会社勤務回です。また、著者の漫画家もゲーム雑誌で漫画を掲載していた経験もあります。 さて、その漫画『ナナのリテラシー』によると、「誰もが飛び越せる絶妙な難易度の壁をクリアさせる」のがコツだと、作中のゲーム会社の老人経営者は言います。あくまで創作中の人物であり、また、作品の主張ではないですが。 この漫画の取材の程度として、 「PS」（プレステ）のロードは、「1回のロードで2WMが限界なんで　どんなマップも2メガに入れなくちゃいけない　会話も音楽も全部ね」 という情報を入手できている程度には取材のされている作品です。 高難易度（むずかしめ）ゲームや低難易度（やさしめ）ゲームを作るにしても、まず基準がこうであることを知っておきましょう。 ただし、すべての人に丁度いいバランスに調整することは、非常に難しいです。なので書籍『ゲームプランとデザインの教科書』では、ターゲット層をある程度はしぼりこむ必要があると述べています<ref>『ゲームプランとデザインの教科書』、P.97 </ref>。 ほかの書籍でも、塩川洋介『ゲームデザイン プロフェッショナル』では、やや文脈が違いますが、「遊んだプレイヤー全員が満足するものを、目指さない」と記述があります<ref>塩川洋介『ゲームデザイン プロフェッショナル』、技術評論社、2020年10月3日 第1刷発行、P.173</ref>。（ただし、これはターゲット層の限定のほかにも、テストプレイヤーの意見に振り回されないように、という意味もあるので、文脈が少し違う。） ターゲット層の設定で重要なことは、少なくとも、実在する最低1人の人間を、想定することです。「20代社会人男性が」とかではなく、自分の知人・友人・家族とか、そこまで具体的なレベルで想定するべきだと、塩川氏の著書では述べられています<ref>『ゲームデザイン プロフェッショナル』、P205</ref>。 {{コラム|カラケオ音楽の難易度も似ている| なお、ゲームではなく音楽文化ですが、80年代～90年代にカラオケが流行しましたが、実は当時の歌謡曲も似たようなカラオケでの難易度を意識して作曲されています。練習しないと歌うのが難しいが、素人でも練習すれば上手く歌える歌になるように、メロディが作曲されています。 たしか90年代後半、岡田斗司夫などが、こういったことを評論していました。 よく、音楽評論などでは、作曲家の小室哲也の曲が典型的にそうだと言われています。 なお例外もあります。 カラオケブームにより、90年代前半には、アニメソングでも子供が気軽に歌える歌が減ってしまったので、1995年のアニメ『新世紀エヴァンゲリオン』の主題歌の作曲では、監督やスポンサーのレコードー会社プロデューサーは、子供でも歌いやすいように作曲してくださいと作曲家に依頼しています。90年代後半の何かの書籍のインタビューで、スポンサーのレコード会社のキングレコードのプロデューサー（当時）大月俊倫がそう答えていました。 }} {{コラム|作者ではなく購入客たちによって是非が決まる| 商業作品であるなら、最終的には売上によって作品の是非が決まるわけですので、ゲーム産業なら間接的には購入プレイヤー/課金プレーヤーが作品の是非を決めることになります。 決して作家が是非を決められることではないのです。 文脈は違いますが、文献『ゲームデザイン プロフェッショナル』でも、「味の善し悪しはプレイヤーが決める」と記述があります<ref>『ゲームデザイン プロフェッショナル』、P.167</ref>。（ただしその参考文献では、ターゲット層を決めるべきだという文脈で味の善し悪しをプレイヤーが決めるという話をしていますので、本wiki本ページのニュアンスとは違います。） ゲームに限らずアニメ産業でも同じであり、作者や監督でも決められないことが多くあります。 ジブリアニメの『となりのトトロ』は、子供たちにアニメばかり見ずに外で遊ぶように啓蒙するようなストーリーを作者・監督の宮崎駿は目指したと言われています。 しかし実際には、視聴者からファンレターで、子持ちの母親からのファンレターで、「うちの子は、よく宮崎先生のアニメを見ています。面白いアニメを作ってくださり有難うございます」みたいな感謝のメッセージが来たりと、つまり、肝心の「アニメばかり見ないで外で遊べ」というメッセージが伝わりませんでした。 ガンダムやエヴァンゲリオンでも似たような逸話がアニメ評論ではありますが、説明を省略します。 }} === チュートリアルの分離などの検討 === 文献『ゲームプランとデザインの教科書』では、チュートリアルは別モードにすると良い場合もあると薦めています<ref>『ゲームプランとデザインの教科書』、P401</ref>。 伝統的な難易度デザインの書籍では、「段階的に難易度をステップアップ」のような設計論が語られている書籍もありますが、しかしそれだと長編ゲームなどでは中後半のゲーム性の本筋に入る前に長々と本筋でない部分をプレイさせられてしまいかねません。そこで、チュートリアルを別モードに分けることで、あまりにも中盤の難易度から掛け離れた部分を、ゲームの本編からは切り離すことができる場合もあるとの事です。 商業ゲームの実例としては『不思議のダンジョン２　風来のシレン』というゲームが、このようなチュートリアル分離の手法を活用しているとのことです。 === 教育的視点でのバランス調整 === ==== バランスを通じた教育 ==== バランス調整を成功させるための対策はいくつかあります。一つ例を挙げると、プレイヤーに習得してもらうプレイ技法をある程度想定しておくことです。 プレイヤーがそういうプレイ技法を習得し、実践できるようになったら、敵キャラを簡単に倒せるようにするのが良いでしょう。 文献『ゲームプランナー集中講座』（吉沢秀雄 著）でも、ニュアンスはやや違いますが「教育的難易度」という用語を使っています<ref>吉沢秀雄『ゲームプランナー入門講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、225ページ</ref>。 :※ ただし、この文献でいう「教育的難易度」とは、ある敵を攻略するのにプレイヤーがなんらかの操作を要求する敵は、まず1個だけのその敵の撃破用の操作技能だけをプレイヤーが修得できれば攻略できるようにしろという意味です。なので、本wikiでいう「教育的視点」とはニュアンスが若干（じゃっかん）、違います。 教育と言葉を使いましたが、プレイヤー視点では「学習」です。文脈は違いますが参考文献『ゲームプランとデザインの教科書』では、「学習」という言葉を用いています<ref>『ゲームプランとデザインの教科書』、P.61 </ref>。 ただし、このように教育的な視点が有効な場面は、あくまでバランス調整だけでしょう。企画などのアイデア出しは、教育的視点ではなく、もっと大衆娯楽エンタメ視点で行うのが定石です。（なお一般的に、ゲーム業界にかぎらず企画手法の定石として、面白い事どうしの組み合わせ、というのがあります。） また、少なくない多くのプレイヤーたちが、ゲームを通じて自身の思考力が磨かれて成長したかのような感覚を味わうのが好きだという統計・アンケート結果があります<ref>[https://www.teu.ac.jp/ap_page/koukai/2019_03_3endo.pdf [[w:遠藤雅伸]] 『ゲーム道に通じるユーザーの振る舞いとゲームデザインへの応用』66ページ、3.3.3. 面白さに関する考察 ]</ref>。 なお、コンピュータ的なゲーム産業と、教育との関係性にすでに気付いて注目しているゲーム作家もいます。ナムコ出身の岸本好弘がそうです。また、学問的にも、ゲーム設計技術の教育への応用として『ゲーミフィケーション』などと言う概念が提唱されています。 ゲームフィケーションに関する説明は長くなるのでコラム化します。 {{コラム|ゲーミフィケーションに関すること| 野球ゲームの『ファミスタ』シリーズで有名なナムコ出身の岸本好弘などが、ゲーミフィケーションをゲーム作家の立場から推奨している。<ref>[https://news.denfaminicogamer.jp/kikakuthetower/190731a ファミスタの父が「日本ゲーミフィケーション協会」発足──ゲームの力で世の中はもっと面白くなる 2019年7月31日 14:41 公開]</ref> 2019年に岸本がゲーミフィケーション学会を設立したが、なにもこの時点で概念が産まれたわけではなく、既に2013年あたりの時代には、たとえばテレビの夜中の経済ニュース番組などで、ゲーミフィケーションを企業の新人研修に応用する事例などが報道されていた亊もある（ただし、これに岸本氏が関わっているかは知らない）。 岸本が言うには「ゲームの本質っていうのは、人間が頭で想像することの素晴らしさ」である<ref>[https://www.fantasy.co.jp/edutainment/article/interview16 『“遊び”と“学び”はまったく同じ！？ ゲームと教育の専門家二人が語るゲーミフィケーション教育（前編）』 2021.07.08 UP] </ref>。 岸本が言うには、今から40年前（※1980頃 ？）を振り返り、すでにゲームセンター用のアーケードゲーム業界では、 :「そのころアーケードゲームのデザインで言われていたのは、初めてそのゲームに挑戦したプレイヤーでも3分間程度は遊べるようにすること。「もう一度チャレンジしたら、先に進めそうだ！」と、プレイヤーの気持ちが動くように制作すること」 :「これって、現在IT業界で言われるUX、ユーザーエクスペリエンスですよね。ゲーム業界では理論化、言語化していなかったけれど、40年前から現代に通じることをやっていたんだなと思いました。」 と言われている<ref>[https://www.fantasy.co.jp/edutainment/article/interview16 『“遊び”と“学び”はまったく同じ！？ ゲームと教育の専門家二人が語るゲーミフィケーション教育（前編）』 藤本 徹氏・岸本 好弘氏, 2021.07.08 UP] </ref>。 岸本「ゲームって全部「そそのかし」なんです。ゲームをプレイしていて、Ａの洞窟に行きなさいとか、Ｂの洞窟には行くなとは言われないですよね。プレイヤーが2つの洞窟をぱっと見たときに「こっちの洞窟に宝があるかも！」って見えるように作っているんです。これを「そそのかし」って言うんです。間違っても、ストレートに「Ａの洞窟に宝物があるなどという看板を立ててはいけません（笑）。」 （抜粋）「先生は答えを教えるのではなく、生徒が自分で「わかった！」、「僕が一人で気が付いた！」と思わせることが大切。」 「ゲームをデザインするのも授業をデザインするのも同じです。楽しいと思うことやワクワクすることは脳の働きを最大限にする。だから、つらいことを我慢するのはよくない。脳が楽しいと感じることがとても大切なんです。」<ref>[https://www.fantasy.co.jp/edutainment/article/interview17 『“遊び”と“学び”はまったく同じ！？ ゲームと教育の専門家二人が語るゲーミフィケーション教育（後編）』藤本 徹氏・岸本 好弘氏, 2021.07.15 UP] </ref> 必ずしも現代のゲームが上述のように教育的配慮にもとづいて設計してもヒットするかは不明である。21世紀の現代と20世紀のファミコン黎明期とでは消費者ニーズも違っているから、もしかしたら今後は教育的配慮ある作品が全く売れないのかもしれない。 だが、とりあえず1980年代前後のゲーム文化の根底には、このような教育的な発想が色濃く存在していたのもまた事実であろう。 }} {{コラム|オタキング岡田はこういった| また、ゲーム業界人だけでなくアニメ業界人からも、1998年までの時点で似たようなことが指摘されています。 既に1990年代後半の時点で、アニメ評論家の岡田斗司夫により著書などで、市販のゲームソフトの多くは達成感を味合わせるものだと指摘されている。 たしか岡田の著書『世紀の大怪獣!!オカダ―岡田斗司夫のお蔵出し 』に、そういった話題が書かれており、マリオカートが例に出されている。 岡田に言わせれば、ゲーム文化以前の人生の趣味の多くは、必ずしも努力の量と、上達とが比例しない。たとえばスポーツとか、絵画とか、何でもいいが、たしかに練習を多くしても必ずしも上達に結びつくとは限らない。 しかしファミコン以降のコンピュータ式のゲームはそうではなく、ほぼ必ずといっていいくらい、少なくとも初心者レベルの範囲でなら、プレイして練習すれば上達するように設計されていると、彼の著書では述べられている。 岡田が言うには、人生はゲームみたいに甘くないし、もしかしたらゲームは現実逃避で不健全かもしれないけど、でも大人だって親だって達成感をもっと感じたいんだぜ・・・だから今日も娘といっしょにマリオカートをプレイしている、というような感じのことを著書で述べていた。 }} {{コラム|岡田斗司夫はゲーム会社社長でもあった| なお、岡田らの創業したアニメ会社の「ガイナックス」は、現在では『新世紀エヴァンゲリオン』をつくったアニメ会社として語り継がれていますが、実はゲームソフトも開発していました。 多くは美少女ゲームだったりしたのですが、その中に、1991年に開発した『プリンセスメーカー』という当時としては斬新な育成シミュレーションゲームがありました。（少女を育成するゲームとしては、おそらくプリンセスメーカーが世界初。なお、競馬の競走馬を育成するゲーム（ダービースタリオン）1991年12月発売よりもプリンセスメーカー（1991年5月24日）のほうが発売が早い。） 文献『ゲームプランナーの新しい教科書』でも、美少女や少年などのキャラクターを1人または少人数のキャラクターを育成するジャンルを確立したゲーム作品が、このプリンセスメーカーであると述べられています<ref>STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版 第2刷 発行、P182</ref>。 さて、1998年ごろにゲーム評論家の阿部広樹（あべひろき）が言うには、 98年当時はコナミ社『ときめきメモリアル』という、美少女と恋愛するための男主人公を育成する育成ゲームがほぼ社会現象のような流行だったのですが（たとえばジャンプ漫画の　こち亀（略称。長いので）　にも、 明らかに『ときめきモリアル』（略称：「ときメモ」）のようなゲームを話題にした作品が、 社会現象作品として登場しています）。 阿部が言うには、ときメモのような育成ＳＬＧは、ゲーム業界での系譜としては、まずプリンセスメーカーが娘の育成ゲームとして登場し、 おそらくは、それを参考にしてPCゲーム会社「エルフ」が美少女アダルトゲーム「同級生」（ゲーム中に男主人公の育成がある）を開発し、 さらにそれを参考にしてコナミ社がときメモを開発したという流れになる、と阿部は著書などで述べています。 あくまで阿部氏が著書でそう思っている旨を述べていただけなので、 もしかしたらエルフ社やコナミ社の当時の関係者からすれば元ネタが違う点もあるのかもしれませんが、 少なくとも他社やマニア消費者からはそう思われている（プリメ→同級生→ときメモ　という流れを思われている）というワケです。 さて、ときメモの話をしたいのではなく、岡田の話をしたいのです。 岡田は当時はゲーム社長だったので、常識的に考えて、プリンセスメーカーの開発に関する情報は、ある程度は耳に入っていると思われます。（ただし、岡田本人はゲームファンではなく、アニメファンかどうかも怪しく、どちらかというとSFファンでした。） いくら岡田がゲームに詳しくないといっても、信頼できる部下にゲーム開発指揮を任せているとしても、岡田が社長である以上、最低限の開発工程の概要や全体像に関する情報が岡田の耳には入っているハズです。 そういう経験のある岡田が「ゲームはプレイ時間に応じて、上達するように設計されている」と具体的に言うわけですから、岡田のマリオカート評論当時の意見を、過去のゲーム業界人の意見としても、それなりに意見を参考に聞き入れるべきでしょう。 だから「岡田はアニメ評論家じゃねえか」とか言って意見を無視するのは、不見識です。 また、プリメ→同級生→ときメモ　という流れから分かるように、一般にゲーム会社は他社の人気コンテンツを真似ています。 攻略本やゲーム雑誌などには一切書かれていませんが、大人の事情で書かれていないだけですので、大人の事情を真に受けないようにしましょう。当然、ときメモ以降の他社の育成ゲームや美少女ゲームも、社会現象になった「ときメモ」を真似しています。誤解のないように再度書きますが、上記で紹介したゲーム郡のうち、岡田経営のガイナックスのゲームは『プリンセスメーカー』だけです。ほかのゲームは他社コンテンツですので、誤解なきよう。 }} {{コラム|プリメとデスペナ| プリンセスメーカーには育成システムのほかにも比較的に画期的なところがあって、それは戦闘での全滅時の損失の軽さです。プリメのしリーズでは、戦闘で全滅しても、拠点に戻されることと、育成パートでのターンが1ターン経過するだけです（1ヶ月が1ターンに相当する）。この指摘は別にwikiのオリジナルではなく、1990年代の後半に雑誌『ゲーム批評』で指摘されていたことである。 1年に12ターンしか行動できないので、シミュレーションゲームの視点で考えると損失は大きいかもしれませんが、RPGの視点だけで見ると損失は軽い、というわけです。 日本の現代的なゲーム評論では、全滅時の損失のことを和製英語でデス ペナルティといいます。英語では dead damage というらしいです（DDと略すようです）。英語ではデスペナルティ death penalty とは「死刑」の意味です。 つまりプリンセスメーカーは、デスペネルティが軽くても面白いRPGを作れることを実証したかもしれない可能性があります。 ;デスルーラ なお、全滅しても拠点に戻るだけのシステムだと、拠点に戻りたい場合にわざと全滅する方法を使えますが、これを和製英語で「デスルーラ」といいます。ルーラとはドラクエの移動魔法のルーラのことです。 さて、全滅したときに拠点に戻るゲームでは、標準的な方法では、決してイベントなどで拠点に戻らないようにするのは不可能です。 なぜなら、たとえば拠点の町に戻る橋を通せんぼしているボス敵がいたとして、ボス敵が「この橋を通りたければ、私を倒すが良い」とか言われてボス戦になったとしても、そのボス戦闘で全滅するとパーティは拠点の町に戻るので、そもそも通せんぼイベントの意味がありません。 ただし、もしイベント用の特殊なプログラムとして、全滅時には他の町に戻るなどの戦闘の処理を組めば可能ですが。 }} {{コラム|デスペナ関連の話題| <!-- この話題は、後述の商学書『メイド・イン・ジャパンは負けるのか』の話題と関連するので、残す必要がある。 --> ;帰り道の通せんぼイベントと詰みのリスク そもそも、拠点への通せんぼ系のイベント自体、クリア保証の観点からは難しい点もあります。サガのようにどこでもセーブできるゲームの場合は、帰り道の通せんぼイベントを上手に設計しないと、クリア不能につながるおそれがあります（いわゆる「詰み」（つみ））。 だから実際、ファミコン～スーファミ時代のドラクエやファイナルファンタジーやGB版サガやロマサガなどでは、このような帰り道の通せんぼイベントを見かけないか、あったとしてもスグには思い出せません。 どこでもセーブできるロマサガ1の氷結城の帰り道で通せんぼするボス敵がいますが、しかし会話選択肢などによりボス戦を回避可能ですので、詰みにはなりません。 なお、古い時代のサガ系やロマサガなどでは、基本的に、ダンジョン奥まで探検したあとの帰り道には、帰り道の短縮のためにダンジョン最深部に出口への一方通行をマップ側で用意済みというダンジョン設計もよく見られました。このダンジョン設計は、テンポ感向上の基本手法である「プレイヤーが既に理解していることを再度要求しないこと」にもつながりますので、一石二鳥です。 ただし、一方通行出口がないダンジョンがあれば、「帰り道でボス戦があるんだな」とプレイヤーに予感させてしまい、プレイヤーへのネタバレになります。だから、ドラクエがそのような一方通行出口をまず用意しないのも一理あります。 このように、ゲームのルールの設計により、実装可能なイベントやマップなどがある程度は限定されてしまいます。 }} さて上記のデスペナルティのコラムで説明したように、ゲームのシリーズ作品は、そのシリーズを通してルールがおおむね一緒です。 このことと、「ゲームのルールによって搭載されるイベントがある程度は決まる」という事を合わせて考えると、どうなるでしょうか。 そう、シリーズ作品によって、搭載されるイベントの傾向が決まってしまうのです。 問題は、これがマンネリ化につながるおそれがあること、少なくともビジネス書ではそう見られていることです。 これは別にwikiのオリジナル意見ではなく、文脈は違いますが、商学書『メイド・イン・ジャパンは負けるのか』という2010年ごろの書籍で、 シリーズ化とマンネリ化との相互関係が語られています。 さらにその書籍によれば、基本的に家庭用ゲーム機の作品群の多くはゲーム性の根幹が90年代あたりから以降の作品は変わっておらず、変わったのはグラフィックが細かくなっただけ、というふうに見られています。 ただし、書籍は2010年ごろの出版物なので、もしかしたらスマホゲームやソシャゲの流行している2020年代の現代なら、分析結果は違うのかもしれません。 もっともゲーム会社からすれば反論もあるかもしれませんし、たとえば、 「でも消費者が、新シリーズや新ジャンルを出してもロクに買わねえじゃねえか・・・」とか 「グラフィックよりゲーム性とか口先では消費者は言うけど、でもそういうグラ軽視のゲームを消費者は買ってくれないんだよね」とか 「素人はみなそう言うんだよね。でも自分じゃ作ってくんないし少しでも試作品の手本すら見せてくんない」とか思うかもしれませんが、 とりあえず、世間にはそういう意見があります。 けっしてゲームオタクだけがそういうマンネリ化の意見を言ってるのではなく、外部の商学あたりからもそう見られています。ただし書籍の商学者の分析が正しいかどうかは知りませんが。 1980年代のような家庭用ゲーム黎明期や1995年頃のソフト容量が飛躍的に伸びたプレステ1時代ならともかく、そうそう新しくて画期的かつリアリティと説得力ありそうなルールなんて、思いつくものではありません。難しい問題です。また、マンガ産業やアニメ産業は黎明期をとっくに過ぎてしまいましたが、それでもマンガもアニメも産業は続いています。2010年台のゲーム産業だって、もしかしたらスマホゲーム黎明期、ソシャゲ黎明期なのかもしれません。2010年以降の現代のゲーム産業については、当wikiは中立性の立場上、これ以上は解説しません。 {{コラム|岡田斗司夫のアノマリー理論| 古典的な理論を言うと、アニメ評論家の岡田斗司夫が「アノマリー」（「片寄り」という意味の用語）で言ってる例ですが（『東大オタク学講座』にある理論）、ゲームのバランス調整にはそもそも、岡田の理屈によると普遍性はなく、どうしても作者の世界観が反映されます。 たとえば、『シムシティ』というアメリカ人の作った都市運営シミュレーションのゲームでは、原発が効果的な投資であるのですが、そして火力発電所よりも原子力発電所が効果的なのですが、岡田はこれを作者のアメリカ的な都市政策観の反映だとしています。 そのほか、岡田は、ドラクエシリーズに対して、「なぜ作者の堀井さんは、作中で父親と子の関係に、どの作品でも、こだわりたがるんだろう？　なにかあったんじゃねえの？」的なゲスい勘繰りもしています。 作家の「個性」というのは、一般人から見れば「異常性」でもあるわけです（ただし、法律を守る程度の最低限の一般性は作家だろうが必要ですが）。個性というのは長所ではなく、欠点の裏返しでもあるわけであり、その欠点すら大人はうまく自分で活用しなければならないのでしょう。 }} ==== 本文 ==== もちろん作品によっては例外もあるでしょうが、しかし上述で紹介したような様々な視点の異なる複数のゲームクリエイターなどゲーム業界人が、「教育」や「成長」などあたかも学習的な用語を使っている事は、念頭に置くと良いかと思います。 ゲームにおける教育的な要素はもちろん擬似的なものです（ゲームに限らず一般のアニメや漫画も同様です。もし本格的に世間一般で通用する意味での「学習」をしたいなら高校～大学レベルの国語・数学・英語・理科・社会科などの参考書などを読もう）。 さて調整の話題に戻ります。 たとえば、アクションゲームの調整なら、 もし敵が飛び道具を使ってくるなら、まずプレイヤーは物陰に隠れて移動して近づくとか、あるいはプレイヤーも飛び道具で応戦するとか、そういうプレイ技法が必要でしょう。 文献『ゲームプランナー集中講座』（吉沢秀雄 著）でも、飛び道具を使ってくる敵には、ゲーム序盤では、まず物陰にかくれて敵の攻撃を避けるなどのプレイ技法をプレイヤーに習得できればよいというくらいまで、（序盤の）難易度を簡単にすべきだと、その文献『ゲームプランナー集中講座』では主張されています<ref>吉沢秀雄『ゲームプランナー入門講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、226ページ</ref>。 まず、序盤の飛び道具つかいの敵なら、プレイヤーが上述のような物陰に隠れる技法を実践できていたら、その敵を簡単に倒せるように難易度を調整します。 このため、序盤ではけっして、敵の攻撃をさけるための物陰の部分には、ゲーム作者はワナなどを仕掛けないでおき、物影には敵も配置しないようにするくらいで、良いのです<ref>吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、226ページ</ref>。 たとえば、飛び道具を使ってくる敵は、そいつに攻撃を当てるまでは難しいが、しかし敵の防御力を低くしておいて、もし敵が（プレイヤーからの）攻撃を受けたら、敵はすぐに倒されてしまう・・・のような強さの敵としてパラメータ調整しておくのが良いでしょう。 つまり、プレイヤーに教えたいスキルとして、そのアクションゲームを通して、飛び道具を使ってくる敵の対処法を教えるのです。 ゲーム後半で難易度を上げる場合は、けっして敵を単にやたらと頑丈にするのではなくて、 敵の強さはそこそこでいいので、 たとえば ステージのギミックや敵の行動などを今までの敵と複合化させたりする等の設計により、過去にプレイヤーの習得したプレイ技法の組み合わせの練習・習得をプレイヤーに要求したりとかして、プレイヤーに今まで習得した単一のプレイ技法の複合の習得を要求するようにすると、プレイヤーも成長できますし、あきづらくなるし、いいことづくめです<ref>吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、228ページ</ref>。 （ただし、あまりにも膨大なプレイ技法どうしを組み合わせるような過大な技法をプレイヤーに要求しないように、（作者がプレイヤーに）要求する技法の数にも限度は必要でしょう。） なお、余談だが、「難易度」の「高い」「低い」の意味は、 :「むずかしい」＝「難易度が高い」 :「やさしい」＝「難易度が低い」 である。 ゲームを難しくする目的は、プレイヤーに創意工夫を呼び起こすためです。創意工夫を呼び起こさない難しさは不要かもしれません。 書籍『ゲームプランナー入門』によれば、ボス戦などの難しいエリアの目的は、プレイヤーが自らのプレイスキルの程度を試したり、あるいはRPGなどならキャラクターユニットの成長を試すためのものです<ref>吉冨賢介『ゲームプランナー入門』、P60</ref>。また、「歯ごたえ」などの表現の意味も、こういった意味であると書籍では述べています。 ;制限の必要性 制限の必要性とは、たとえば、ゲーム中での主人公が丈夫で死にづらいのは構いませんが、しかしどんなに敵の攻撃を食らっても死なずに倒れずに不死身なのは駄目です。 また、主人公の所持金が多いのは構いませんが、しかし所持金が無限大なのは駄目なのです。 また、敵の動きが少し単純なのは構いませんが、しかし、プレイヤーが油断しすぎているのにプレイヤーが負けないのは駄目です（たとえばアクションゲームで一時停止ボタン（ポーズボタン）を押さずにトイレに行ってウンコを数分してきても、ウンコから戻ってきてもキャラが負けてないのは明らかに駄目）。 このような駄目な例のゲームのままでは、プレイヤーが創意工夫をしなくなってしまいます。 このため、そのゲームでのゲームオーバー条件を、作者は早めに決めておきます。ゲームオーバーが用意されていないと、スリルが出ないのです<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.254</ref>。 あまり気が乗らないでしょうが、しかし、ゲームにはゲームオーバーや敗北の条件が必要ですし、プレイヤーには敗北を回避するように努力してもらわなければなりません。 ;解法を1つに限らない 書籍『ゲームプランナー入門』（吉冨賢介 著）によると、たとえばスーパーマリオ1のステージ1-1の最初の敵のクリボーの対処でも、クリボーを踏んでやっつけるか、それともジャンプして飛び越えて次に進んでしまうか、マリオがブロックの上に乗ってクリボーが通り過ぎるのをやりすごすか、などなど幾つもの選択肢があると、例を挙げています<ref>吉冨賢介『ゲームプランナー入門』、P55</ref>。けっして、「たった一つの正解」ではないと述べています<ref>吉冨賢介『ゲームプランナー入門』、P55</ref>。 このように解法を複数用意することで、プレイヤーに創意工夫を呼び起こしやすくなります。 ==== 他メディアとの違い ==== ===== マンガ・アニメのバランス調整との違い ===== マンガやアニメのバランス調整というか、物語での敵の強さの見せ方と、ゲームでの敵の強さのありかたは、少し差異があります。 マンガ・アニメだと、たいてい強敵は、主人公がなんとか苦戦しながら倒せるギリギリの強さになっています。たしか1982年『鳥山明のヘタッピマンガ研究所』（1982年『鳥山明のヘタッピマンガ研究所』）の時点で、すでに、マンガやアニメや特撮（ウルトラマン）などの敵の強さは、そういうふうに設計されていることが説明されています。 しかしゲームでは普通、このようなギリギリの強敵にしてないほうが安全です。 マンガやアニメの強敵よりも、やや弱めにしておく必要があります。そうしないと、プレイヤーに創意工夫が生まれません。 具体例を考えるなら、分かりやすい例が、先ほど漫画家の鳥山明さんを例にあげましたが、その鳥山さんのドラゴンボールの原作マンガとゲーム版でのボス敵の強さの違いです。ゲーム版『激神フリーザ』だと、たとえばクリリンでもちょっと鍛えて頑張ればザーボン（ナメック星編の中ボス敵）を倒せるようになっています（原作マンガだとクリリンはザーボンを倒せない）。別に鳥山さんの作品だけでなく、ほかの多くの作家のマンガやアニメのゲーム版も、大体、同様に、原作マンガや原作アニメでは倒せなかったボス強敵がゲーム版では頑張れば倒せるようになっています。 理論的に考察するなら、マンガやアニメでは、一回の戦闘での強敵の倒しかたが一通りしかなく、いちばん読者に魅力的に見える奇想天外・破天荒な倒しかたで、敵を倒します。なのでマンガやアニメでは、ギリギリ倒せる強さのほうが良いのしょう。 しかしゲームの強敵では、多くのプレイヤーの、それぞれ異なる色々なアイデアに対応した倒し方を何通りも準備する必要があるので、ゲームでの強敵の強さは、ギリギリ倒せる状態よりも少し弱めにする必要があります。 ==== 「廃人」 ==== ゲーム用語で「廃人」（はいじん）という表現があります。「廃人」とは、たとえば通信機能のあるネトゲRPGなどで、普通の社会人だとレベル上げが引きこもりプレイヤー追いつかずに（社会人が）クリアできないようなゲームにおいて、高レベルプレイヤーである引きこもりプレイヤーや無職プレイヤーなどを揶揄する意味です。 2010年以降の近年は課金ゲームなどにも「廃人」という言葉が使われます。一般の市販ゲームは高くても1万円程度ですが、それと比較して多額すぎる数十万円や数百万円の金額をゲームに課金するプレイヤーのことです。 書籍『ゲームプランとデザインの教科書』でも、この問題をサラっとですが、きちんと紹介しています。書籍中では「廃課金ユーザー」という表現を使っています<ref>『ゲームプランとデザインの教科書』、P66</ref>。書籍『ゲームデザインとぼくらの教科書』でも、廃課金ユーザーが社会問題化したことに触れられています<ref>『ゲームプランとデザインの教科書』、P66</ref>。 アニメーターだってゲームをする暇があるなら絵を描いていたからアニメーターとして通用しているわけです。アニメーターの就職前の第一趣味はゲーマーではないでしょう（イラスト制作やアニメ制作のはずです）。 === ゲーム作家の体感の難易度はズレやすい === プログラミングというよりゲームデザインの話題かもしれないが、そのゲームの簡単さ・難しさといった難易のバランス調整も、コツがいろいろとある。 ==== 具体的な方法 ==== 結論から言うと、多くのゲームデザインの文献で、やや簡単めに調整されたバランスでゲームを作るのが安全であると主張されている。 たとえば書籍『ゲームプランナーの新しい教科書』（STUDIO SHIN 著、翔泳社）でも、作者がやや簡単だと思うくらいに作ると良くなる場合が多いという経験則が語られている<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版第2刷発行、54ページ</ref>。 また、書籍『ゲームプランナー集中講座』（吉沢秀雄、SBクリエイティブ）でも同様に、調整で迷って、プレイヤーにとっては易しいほうの案Aと難しいほうの案Bとがあったら、ゲーム本編には、やさしいほうの案Aを採用するのが良い、と主張しています<ref>吉沢秀雄『ゲームプランナー入門講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、235ページ</ref>。 難しいほうの案Bは、クリアに不要なサブ・ステージとか、そういうステージに流用すればいいのです<ref>吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、P207および235ページ</ref>。 ちなみに、文献『ゲームプランナーの新しい教科書』によれば、RPGにおいて、クリアに不要なイベントのことを「任意イベント」と言います。一方、クリアに絶対な必要なイベントのことは「強制イベント」といいます<ref>STUDIO SHIN著『ゲームプランナーの新しい教科書』、P198</ref>。 つまり、サブ・ステージや任意イベントの難易度については、本編の強制イベントの難易度よりも少し難しくしても構わないのです。文献『ゲームプランナー集中講座』によれば、むしろ、多様なプレイヤーに対応するためにサブ・ステージや任意イベントの難易度の設計は、本編強制イベントとは難易度を変えるほうが望ましいというか、そういう設計テクニックとしてサブ・ステージや任意イベントが用意されているような側面もあるようです<ref>吉沢秀雄『ゲームプランナー集中講座』SBクリエイティブ、2015年12月29日 初版　第1刷発行、P208</ref>。 書籍『ゲームプランナー入門』（吉冨賢介 著）でも、基本的に作り手は「簡単」だと思っていても、初めてプレイするプレイヤーには難しいという現象がよくあることを述べています<ref>吉冨賢介『ゲームプランナー入門』、P56</ref>。 ==== 例外 ==== 例外的なプレイヤーもいます。プレイヤーの中には、たとえばRPGなら、レベル上げそのものが好きな人もいます。 また、たとえばゲーマーでない一般人でも、たとえば電卓で「+1」を押しまくって計算結果をカウントアップしていく暇つぶしをしたことある人も多いでしょう。 ですが、レベル上げが好きなRPGゲーマーでも、彼らがプレイしたがるゲームの多くは、なぜか、レベル上げがそれほど好きでない種類のゲーマーも楽しめるゲームばかりです。 ドラクエ、ファイナルファンタジー、女神転生、テイルズ、・・・などなどのシリーズは、どれも商業の人気ゲームは、レベル上げがそれほど好きでなくても、ストーリーや戦術性などでも楽しめるようになっています。 本当にレベル上げだけが好きなら、ストーリー一切無しのレベル上げだけのゲームをプレイすれば充分ですし、フリーゲームなどでそれに近いゲームはあります。しかし、商業の世界では、そういうストーリー無し、あるいは戦術性が無しのゲームの話を聞きません。 これはどういうことでしょうか。 ゲームでなくマンガ業界の例で考えて見ましょう。 たとえば、少年ジャンプの読者には、メインの読者層は若い男の子ですが、 しかし実際には成人男性の読者もいますし、それどころか女性読者もいます。 しかし少年ジャンプは、あくまでも、メインの読者層が男の子であることを貫く編集姿勢であることが、 ジャンプ漫画の裏側を描いたマンガ『バクマン』では描かれています。 バクマンによると、たとえ少女の読者がいても、その少女は、 「男の子が読んでるマンガを自分も読んでみたい」と思うような女の子なので、 だからジャンプの取るべき編集姿勢としては、あくまで男の子向けを貫かないといけない、 といった内容が説かれています。 ゲームも同様でしょう。 ==== 背景事情 ==== 一般的にゲーム作家の側は、自作のゲームをプレイしたときの体感の難易度（なんいど）が、（他のプレイヤーよりも）自作ゲームを「やさしめ」に感じてしまいまちである。 つまり、本当は難しいゲームなのに、作家自身は「やさしい」と錯覚しやすい傾向がある。なお、この現象を俗に（ぞくに）「作者バイアス」と日本では言う。 ;歴史 まず、1990年代のゲーム雑誌『ゲーム批評』にもある歴史的事実として、下記のような事例がすでに1990年代から知られています。 すでに1990年代の時点でゲーム評論雑誌『ゲーム批評』において、新人のゲームプランナーは企画提案の際に既存ゲームを難しくアレンジした提案をしがちだという報告がありました。 雑誌『ゲーム批評』によると、たしか、たとえばもし自社がスーパーマリオのようなゲームを作ろうとしている場合、新人はよく、「マリオのこの部分が簡単すぎるから、わが社はここを難しくしましょう」という提案をしがちだということです。 たとえば、スーパーファミコン版マリオ（スーパーマリオワールド）では、地上ステージでは多くのステージで、マリオに空を飛ばせれば、敵に遭遇せずにステージのゴールまで行けるように設計されています。 それを新人は「飛んでしまうと簡単なので、つまらない」と考えがちらしく、なので「空中に敵キャラを多く配置しましょう」という感じの案を提出しがちだということです。 たとえば 「空中に狼（オオカミ）を配置するのはどうでしょう？　アメリカの昔のSFドラマに『超音速攻撃ヘリ　エアーウルフ』という作品もありますので、パロディにもなって大人にもウケます」みたいな提案を出したりしがち、らしいです。（このほか、ゴルフゲームでウルフを空飛ばせる駄洒落（ゴルフでウルフ）アイデアなどの披露もあるとかゲーム批評では書かれていた気がするが（というか元々ゴルフゲームの提案で、上司役からのダメだしの根拠にマリオを例にする批評記事だったかもしれないが、本wiki本ページの文脈にあまり関係ないので、ゴルフの話は割愛させてもらう。） ですが、マリオの地上ステージの空中に敵が少ないのは、ゲームが苦手なプレイヤーのための救済措置だったり、あるいは既に途中まで攻略したけどミスでステージ冒頭に戻されたあとの再チャレンジなどで興味ない体験済みステージ前半を無視するための工夫だったりするので、よって空中の安全性は必要な要素でしょう。 しかし、エアーウルフ的な提案では、そういう分析が抜け落ちています。 ともかく、このように、バランス調整では「予備知識が無いと、多くのゲーム製作者は、ゲームを難しく設計しがち」だというゲーム業界の経験則がもう1990年代からあります。私たちは、歴史にも学びましょう。 :※ ある編集者Aがなんとなく印象でゲームデザイン本などに「ゲーム作家はあまりネットの批評を参考にしない。ゲームを作った事のない人の批評なので、トンチンカンな批評も多いからだ」といったような情報があったような気がしたのですが、 :しかしあらためて書籍を確認してみると、少なくとも『ゲーム作りの発想法と企画書の作り方』や『ゲームプランとデザインの教科書』や『レベルデザイン指南書』では、そのような記述は確認されませんでした。 :下記のコラムは、その情報も背景にしています。 :どうやら、もしそういう記述の文献があっても、必ずしも商業ゲーム業界の多数意見とは限らないようです。 :あるいはその情報は、もしかしたら書籍による情報ではなく、ゲーム雑誌などのwebサイトの意見だったかもしれません（※ 読者に出典などをご存知の方がいたら、情報提供の編集をしていただけると、さいわいです）。よくゲーム雑誌の会社がwebサイトなどに商業ゲーム作家へのインタビュー文など掲載しています。 :一応、『ゲームデザイン プロフェッショナル』では、書籍後半のセクションの題名で大きく「一次情報以外、個性には役立たない」と銘打って、 :「インターネットやSNS」などについて、「そうした情報は知識として役に立つことはありますが、ゲームデザイナーが個性を発揮するうえではあまり役に立ちません」と説明している<ref>『ゲームデザイン プロフェショナル』、P314</ref>。 {{コラム|マリオメーカーのクリアチェック、ほか| マリオついでに話すと、『マリオメーカー』という任天堂のつくった、マリオのゲームの素材を使って、 マリオメーカー購入者でも自分でマリオ風アクションゲームを作れるというゲームがあります。 このマリオメーカーというゲームでは、自作したゲームを任天堂のwebサイトに投稿・公開する際、クリアしてからでないと、投稿・保存できない仕組みになっています。 実は、マリオメーカーが発売される前、インターネット上には「改造マリオ」といって、マリオのROMを違法改造して、自作ステージをつくって無料公開などをする人たちがいました。 改造マリオはそもそも著作権侵害であり違法なのですが、その他にも問題点として、作成されたステージがやたらと難しすぎてクリア困難なステージばかりで溢れていた、という問題もありました。 しかしインターネット上では、そのようなクリア困難なゲームが、ネットのマニア達にはウケており、動画サイトなどではそのような超絶な高難度ステージが話題だったのです。 社会科学の格言で、「犬が人をかんでもニュースにならないが、人が犬をかむとニュースになる」という有名な格言があります。つまり、実際には統計的には少ない事例のほうがニュースとして話題になりやすいという、社会の法則があります。 また、アンケート調査などの心理学的ノウハウとして、「あなたは○○を買いますか？」と「あなたは○○を好きですか？」と聞いたときでは、 アンケート結果の傾向がかなり異なり、多くの人が、「○○を好きですか？」と質問されても決して実際に好きなものを答えるのではなく、 世間から賞賛されそうな趣味趣向の場合にだけ回答で「はい、好きです」と答えるようであるという、分析結果があります。 まさに改造マリオと本来の合法マリオの関係がそれです。 マリオメーカーでクリアチェックが必須なのは、せめて作者自身がクリアできるゲームをつくれ、常識的なプレイ時間で上達してクリアできるゲームをつくれ、というような任天堂の思いが伝わってきます。 おそらく任天堂の社内でも開発ゲームでは、各ステージのクリアチェックなどが行われているのでしょう。 }} {{コラム|ネット民の感性は信用できるか?| インターネット上には無料コンテンツがあふれておりますが、そのような無料コンテンツを楽しむ人たちのセンスは、一般の消費者のセンスとは異なりますし、もし仮に有料だとしても自分がカネを払うつもりもないものを平気で「面白い」と言える人たちも多く居ます。 それでも実際にプレイをした上での感想を言うならまだしも、しかしプレイヤーの人数よりも世界には無料動画の視聴だけをして感想を言うだけの人たちのほうが多いのです。 しかしそれすらも動画サイトでゲーム画面を長時間見ているので、まだしもマシなほうで、もっと酷いのになると、匿名掲示板で誰が言ったかも分からない批評や評論を真に受けて、あたかも実際にプレイしたかのように表面を装う人たちすらも多くいます。 マンガ業界も同じ問題に気づいてるようです。マンガ『ラーメン発見伝』（小学館ビッグコミックスペリオール ）では、作中のライバル役のラーメン屋経営者（いわゆる「ラーメンハゲ」）が、ネットの情報をもとにラーメンの実際の食べたときの味を無視してラーメン評論をする自称ラーメンマニアに陰口で悪態をついています。これにリアリティを感じるマンガ出版社があるわけですから、つまりマンガ出版社の目からも、世間一般の人って多くがそういうネットの風評に左右される人達だよねと見られているわけです。 本wikiもネットの情報の一部なので、鵜呑みにしないでください。お金は掛かりますが、参考文献などとして記載されているゲーム関連に役立ちそうな書籍を、読者は実際に何冊か買って、書籍の実物を読むなどしてください。あるいは実際にゲーム制作やプログラミングをするなどして、確かめてください、 文献『ゲームデザイン プロフェッショナル』では、著者の塩川氏が言うには、口コミやレビュー、プレイ動画によって「知った気になる」ことを有害であると戒めています<ref>『ゲームデザイン プロフェッショナル』、P.282</ref>。 だからゲーム作品を調査するなら、実際にクリアするまでプレイするか、あるいは十分なプレイ時間を投じてプレイしてみなければ、ゲームデザイナーにはあまり役立たないと、塩川氏は忠告しています。 たとえ短時間のプレイでは楽しく感じても、長時間のプレイや繰り返しの演出をされた場合には楽しくないような場合もあるので、だから長時間のプレイをして確認してみる必要があるとのことです。（以上、『ゲームデザイン プロフェッショナル』を参考にした。著作権の事情のため、言い回しや文体は多少は変えてある。） ただ、これは一見するとゲーム作家には、「偏見なく自作を最後までプレイをしてもらえそう」とか思えそうですが、しかしプロの作家は暇人ではないので、同人ゲームまで含めて何でもかんでもプレイすることはできません。 塩川氏は、著作の別のページでは。若者に進めるゲームプレイとして、とりあえずゲーム業界志望なら、まずは人気作や、過去の人気作、自分が作っているゲームのジャンルに近いものを選ぶのが良いと言ってます<ref>『ゲームデザイン プロフェッショナル』、P280</ref>。 これは裏を返すと、もし人気作や商業的な成功作でなければ、そもそもプレイすらしてもらえない、ということを意味します。塩川氏本人はそう言ってなくても、現実世界の時間は有限であるので、作品1つあたりのプレイ時間を延ばすことはつまり、1多くのプレイしてもらえない作品が生まれます。 つまり、塩川氏のプレイスタイルは、前提として、あるゲームについてプレイを開始するまでの条件が、めちゃくちゃ厳しいわけです。 イラスト業界でも類似の指南の事例があり、「アニメ私塾」といわれる有名イラストレーターは、YouTube動画などでプロのアニメ作品の模写の練習を進めていますが、しかし、おおむね発言内容「アニメ線画の模写ですら時間が何十分も掛かるので、練習に入る前にまず、その構図やデザインなどが自分にとって模写をする価値があるものかどうかを判定して、もし価値あると判定できた場合だけを模写しろ」と、判定にけっこう頭を使いなさい、と指南しています。 しかも「アニメ私塾」氏は、1枚の模写をどの程度まで模写すればいいかという質問に対しては「（模写先の手本に）似るまで模写しろ」とまで言っています。まるで、その1枚の手本を、模写のゲームクリアをするまで模写し続けるわけです。 さて、色々とゲームファンの問題点をいくつか前の段落で言いましたが、それでもゲームはアニメや漫画と比べるとまだしもマシであり、なぜならゲームではプレイヤーと、プレイしてない人たちの区別がしやすいからです。 これがアニメや漫画になると、もはや違法サイトで違法配布されたマンガを読んでるだけの人なのか、 実際に購入してプレイした人なのかの区別が困難になります。 実際、中国や韓国などでは、違法の無料配布されてしまったマンガがネットに溢れてしまった時期があり、 そのような事情もあり金融業界などはマンガ産業への投資を渋り、代わりに課金をしやすいオンラインゲームに投資をしたという経緯があります。 }} 文献『ゲームプランとデザインの教科書』によると、アナログゲーム（カードゲームやボードゲームなど）の設計の例ですが、ネット上の意見ではなく実際の目の前のテストプレイヤーの意見であっても、気を使ったりして本音を言わないことも多いので、意見や感想よりも実際のプレイを観察して、「プレイヤーがルールを勘違いしてないか？」など色々と観察するのが良いといわれています<ref>『ゲームプランとデザインの教科書』、P338</ref>。 {{コラム|イナズマイレブンの人気投票呼びかけ事件| イナズマイレブンという、男子小中学生くらいの子供をターゲットにした、サッカーのゲームおよびそのアニメ化作品があります。実際、ゲームなどでも平仮名を多用しているし、アニメなどでも振り仮名が多いですので、常識的に小学生くらいの子供がターゲットでしょう。 さて、このイナヅマイレブンの公式サイトが、ネット上での登場キャラクターの人気投票を行いました。 作品中で、「五条」（ごじょう）というマイナーな中学生キャラで、おっさんぽい顔のメガネで目が隠れて何を考えて分からない不気味な雰囲気の悪役っぽいキャラがいるのですが、ある有名な匿名掲示板のスレッドで、このキャラクターへの組織票の投票を呼びかけました。 その掲示板は、どう考えても子供が見ないような掲示板なのですが、しかし投票の結果、五条が一位になりました。 もし「ターゲット層の小学生の子供達が実は五条が一番好きだった」という理由ならそれでも構わないのですが、しかし投票の前後で「五条が子供に一番人気」という現象は特に観測されませんでした。「五条も子供に人気」という現象はあるかもしれません。ですが、「五条が子供に人気」という現象は結局は起きていないでしょう。 ネットの投票では、このような不合理な亊がたびたび起きます。 まず、年齢制限などをすることが不可能な場合が多いです。 また、本来なら「一人一票」などとしたくても、技術的な理由で不可能な場合もあります。 例えば、一人一票のために例えばツイッターなど外部サイトのアカウントを要求しようにも、しかし子供だとネット上のアカウント持つこと自体が不可能な場合もあります。たとえばツイッターの場合、年齢制限として13歳以下は利用不可能ですので、結果的に、小学生むけのアニメの人気投票をツイッターからの投票を呼びかけようとしても、技術的に不可能です。 アイドルグループのAKBなどでは、発売するCDに投票券などをつけることで、本当にカネを出して商品を購入したターゲット層だけが投票できるように工夫する場合もあります。ただし、AKB方式はこれで別の問題があり、一人の熱心なマニアが何票も投票したくて一人で何枚も同じ曲のCDを買うなどする、一般人とはかけ離れた購入行動をする事例があります。 また、アカウントなどを要求しない投票の場合、一日ごとに追加投票できてしまう場合があります。だから暇な人ほど、多くの投票をしてしまいます。 ;「美人投票」 経済学で、「ケインズの美人投票」という理論があります。これは、金融における株の購入行動では、人々は自分が良いと思っている株を買うのではなく、世間が「この株は上がるだろう」と思っているだろうと予想した株を買うというものです。 ですが、この五条の投票の場合はもはや美人投票ですらありません。ネットのある集団が、自分たちのコミュニティをアピールするために、意図的に、子供からは美男子・美形・好印象だと思われないであろうと予想したキャラに投票しているわけです。まるで逆美人投票です。 ;ノイジー・マイノリティ 世の中には、「口数は多い割には、人数は少ない」という集団があるのです。そのような集団を称して ノイジー・マイノリティ と言い、「うるさい少数派」という意味です。 しかし、うるさいだけの人に限って、企業などからは嫌われるので仕事がなかったりして、ネット上では口数が多いのです。 よく仕事や学生でも学校や家の軽作業などで、「口ばっかり動かしてないで、手を動かせ」などと年上から注意される事があると思いますが、まるでその逆の集団です。手を動かさない人は、口数でしかアピールできないのです。投票とは、そういう人にすら投票権を与えるという意味でもあります。 アニメやマンガなどの投票に関わらず、現実の政治の国会議員などへの投票でも、ある政治家へのネット掲示板などでの賛同は多いが、しかし実際に選挙をしてみると支持票がそれほど多くないという事例もよくあります。 また、暴力団などでは「総会屋」と言って、企業の株を少数でいいので購入し、株主総会での意見をよそおって、難癖をつけるぞとおどすことで、金品を要求するという手口も平成初期までは、よくありました（現在は規制されており、総会屋しづらくなっています）。一株など少数の株でも発言できてしまうので、こういう悪事が出来てしまったのです。 }} 文献『レベルデザイン徹底指南書』では、現実世界で自分が新しいスキルを1つ覚えたら、古いスキル1つはどれか封印する必要があることを説いています。たとえば会社で自らの希望によってグラフィッカーからプランナーに役職が変わったら、グラフィッカー時代のスキルは封印する必要があります<ref>大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81</ref>。（参考文献では「デザイナー」と言ってますが、デザイナーは多義語でありイラストレーターの他にも開発リーダーなどの事を言う場合もあるので、本セクションでは「グラフィッカー」に言い換えた。）プランナーがグラフィッカーの仕事まで掛け持ちしたら、過労死してしまいます。 現実世界の仕事では時間が限られているので、そういうスキル封印が必要なのです。 {{コラム|一人で何でもできるか?| 「と学会」の人が2010年ごろにニコニコ生放送の番組に出演したときに言ってたのですが、どこかのマンガ出版社に対して、「と学会」のその人はマンガ原作者にネタ提供したことあるとの事です。 大衆は、漫画家を一人で何でもできる万能の人だと錯覚したいので、そういう大衆を喜ばせるために、アドバイザーが隠れて、漫画家の知らないネタでしかも読者にウケそうなネタのアイデアを提供をするのです。マンガ作品のクレジットには書かれませんが、そういうビジネスがあります。 もっとも、業界によってはアドバイザーがクレジットに記載される場合もあります。たとえばテレビドラマやアニメなどだと、「考証」や「監修」などで、関連するジャンルの専門家がアドバイスすることもあります。たとえばNHKの歴史大河ドラマなら、東大あたりの大学教授で歴史学教授といったプロの歴史学者が、監修についている場合もあります。 アニメではそこまで行かなくても、ミリタリー物のアニメなどで、実際に銃器を仕事であつかった経験のある人が監修をついていたり、軍事雑誌の記者などが監修についたりとか、そういうこともあります。 }} {{コラム|可処分時間| 21世紀のビジネス用語で「可処分時間」という概念があります。 もともと「可処分所得」という経理などの用語があり、 「可処分所得」とは労働者が給料のうち、税金や社会保険料など支払いが義務付けられているものを差し引いた、 残りの（法的には）自由に使えるぶんの金額です。 実際には、水道光熱費といった公共料金など自由といえるかどうか分かりませんが、この議論では本質的ではないので深入りしないでおきます。 さて、可処分時間とは、可処分所得になぞらえて、可処分時間とは、おおむね、「1日のうちの自分の起きている時間のうち、労働時間などを差し引いた、残りの自由に使える時間」という意味です。 可処分所得に限りがあるように、可処分時間にも限りがあります。だから、商売の競争とは、消費者の可処分所得の奪い合いであると同時に、消費者の可処分時間の奪い合いでもあるのです。 1つの他人の作品に投じる可処分時間を増やしたら、当然ですが、他の作品への可処分時間の投入量が減ります。 こういう厳然たる事実があります。「可処分時間」という用語までクリエイターが覚える必要はないでしょうが、しかし消費者の時間に限りがあるという事実からは決して逃げることができないのです。しかもよく評論で「エンタメ界隈は、可処分時間の奪い合いの産業である」とも言われます。 クリエイターだって時間に限りがあります。たとえば、休日にもし自主制作の作品をつくっていたら、当然ですが、他人の作品を鑑賞する時間は減ります。 }} === クリア保証と戦術性のジレンマ === ==== クリア保証 ==== ドラクエのレベル成長のシステムは画期的であり、どう画期的かを一言でいうと「クリア保証」である<ref>[https://news.denfaminicogamer.jp/column05/170905b　『「レベルを上げて物理で殴る」の素晴らしさをゲームデザイナー視点で語ろう。ドラクエで学ぶ「RPGメカニクス」の3大メリット【ゲームの話を言語化したい：第四回】』2017年9月5日 16:30 ] 2020年12月21日に閲覧して確認.</ref>。どういう事かというと、参考文献のリンク先の記事にも書いてあるが、ファミコン以前の1980年代のアーケードゲームではプレイヤーが上手い操作を学習しないとクリアできなかったが、しかしファミコン以降の家庭用RPGでは、プレイヤーの興味ないことは学習しないでも、代わりにレベル上げなどに多少の時間を掛ければゲームクリアできるようになったのである。 たとえば、プレイヤーが攻略法のわからないダンジョンでも、最悪の場合でも経験値かせぎに多少の時間を掛ければ、そのダンジョンのボスを倒せるなどして、かならず最後にはゲームクリアが出来る、というような事でもある。 その他の例では、たとえばゲーム終盤になってから未探検だった序盤の一部ダンジョンを冒険する際、プレイヤーには既にもっと難しいダンジョンを冒険してるのでその未探検ダンジョンから学習できることは少ないが、プレイヤーキャラのレベルが高いために未探検の序盤ダンジョンの敵はプレイヤーにはすでに弱くなっているので、その残っていた未探検ダンジョンにあまり苦労せずに時間を掛けなくてもダンジョンクリアできるように、難易度が上手い感じに自動調節<ref>[https://news.denfaminicogamer.jp/column05/170905b　『「レベルを上げて物理で殴る」の素晴らしさをゲームデザイナー視点で語ろう。ドラクエで学ぶ「RPGメカニクス」の3大メリット【ゲームの話を言語化したい：第四回】』2017年9月5日 16:30 ] 2020年12月21日に閲覧して確認.</ref>されるなど、RPGのレベルシステムおよび類似システムにはそういった側面もある。 要するに、 :* クリア保証、 :* 難易度の自動調整機能、 の2つが、ドラクエ的なレベルシステムの面白さの本質的・醍醐味であるとのことである。 リンク先の人の意見ではないが、このクリア保証のないデザインのRPGは（RPGでも古いゲームやフリーゲームなどで時々みかける）、表面的にはドラクエ的なインターフェースやステータス画面であっても、中身は似て非なるものであろう。 ファミコン時代の古いゲームなどのバランス調整の失敗（作者にとっては意図的かもしれないが）でよくある失敗として、レベルの上昇の上限を低いところに設定しすぎて、クリア困難になる事例があった（ドラクエ2がそれに近い）。なので、現代への教訓としては、そもそもレベル制限は十分にとるのが安全であろう。 RPGに限らず一般に、ゲームの後半に行くに従って、次ステージ攻略などのための事前準備の増加や、試行錯誤の時間の増加に時間のかかるようになっていく事が多い。そして、ステージクリアに必要な時間の増加が、ゲームを苦手とするプレイヤーに、そのゲームのクリアを諦めさせて挫折感を味あわせてしまう原因になる場合が、少なからずある<ref>[http://endohlab.org/paper/whydoplayersdrop.pdf 遠藤雅伸『ひとはなぜゲームを途中でやめるのか？－ゲームデザイン由来の理由－』6.まとめ] 2020年12月21日に閲覧して確認. </ref>。 === 自由度 === 文献『ゲームクリエイターの仕事』（翔泳社）によると、一本道のゲームではなく攻略ルートが複数あって自由度があるゲームの場合、それら複数のルートも考慮する必要があります。ゲームの自由度が多くなれば、その「場合の数」に応じて、調整の際に考慮する事項も増えます<ref>『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖！』、P78</ref>。 === 勉強の方法論 === ※ バランス調整に限った話題ではないが、他に適した単元が見つからないし、メインページに書くほどでもないので、間借り（まがり）的にバランス調整のページで書くことにする。 ==== 共通言語 ==== ゲーム業界人たちは商売人なので、いろんなゲームをプレイするように推奨します。しかし現実には、それは費用的にも時間的にも不可能です。 商業ゲーム会社でゲームデザイナーになりたいのなら、人気作のゲーム知識は必要です。手本とするためという理由の他にも、スタッフなどに開発コンセプトなどを説明するためにも過去作のゲーム知識が必要になります」（いわゆる「共通言語」）<ref>『ゲームデザイン プロフェッショナル』、P278</ref>。 とりあえずゲーム業界志望なら、まずは人気作や、過去の人気作、自分が作っているゲームのジャンルに近いものを選ぶのが良いといわれています<ref>『ゲームデザイン プロフェッショナル』、P280</ref>。 ==== 前後比較 ==== ゲーム制作において、人気作や人気シリーズを、手本の中心にすえる必要があるが、しかし、けっして人気ゲームだけをマネしようとしてはいけない。名作が名作である意義を確認するためには、同時代の他社の作品や、それ以前の過去の作家の作品に、どういう欠点があったを把握する必要がある。そうした前後関係の比較により、理解が深まる<ref>[https://news.denfaminicogamer.jp/interview/200615a/3 吉田寛・松永伸司『“ゲームらしさ”をもっと深く語りたい！そんなあなたのためのゲームスタディーズ入門』、電ファミニコゲーマー、2020年6月15日 12:02 ] 2020年11月27日に閲覧して確認.</ref>。 なお、同様のノウハウはアニメ研究の業界でも1990年代から語られており、たとえばアニメ評論家の岡田斗司夫や氷川竜介などが、絶版になってしまったが岡田らの共著『国際おたく大学―1998年 最前線からの研究報告』などの書籍の中で例を述べており<!-- 手元にその本が無いので、もしかしたら別の著作かもしれないが、岡田らの共著のどれかではある。 -->、たとえばアニメのガンダム初代がリアリティゆえに名作であることを評論したいならば、それ以前の時代のロボットアニメが如何にリアリティが欠けていたかを実際にビデオなどで視聴するなりして確認しなければならないと岡田・氷川らは述べていた。 ともかく、ゲームでも、名作ばかりプレイしていてもダメであり、つまり知名度だけでプレイするゲームを選んでいては、他のクリエイターに利用されて養分になるだけであろう。 岡田斗司夫と「と学会」の著作した『 岡田の国際おたく大学―1998年 最前線からの研究報告』では、書籍中で、ゲーム作家を経験した演劇作家の鴻上尚史（こうがみ しょうじ）の失敗例を東大生が取材したレポートを紹介しているのですが、岡田がそのレポートを評して言うには、おおむね「成功例から学ぶたがる人は多いが、しかし成功例だけから学ぶのは素人。プロは失敗例にこそ学ぶ。」というような感じのことを言っています。 工学の世界では、『失敗学』という概念が畑村洋太郎によって提唱されており、2002年の畑村の論文<ref>[https://www.jstage.jst.go.jp/article/jjlp1960/43/2/43_2_182/_pdf 『失敗学のすすめ』]</ref>や、2000年には畑村の著作『失敗学のすすめ』が出版されています。 （wikipedia日本語版には「2005年」に出版とあるが、間違いである。2002年の論文で、2000年の畑村の著作が参考文献とされている<ref>[https://www.jstage.jst.go.jp/article/jjlp1960/43/2/43_2_182/_pdf 『失敗学のすすめ』]</ref>。） 実は、2000年よりも前に、ゲーム産業限定ですが岡田が「失敗にこそ学ぶべき」といった内容のことを提唱しています。なお、畑村の論文の末尾の参考文献欄には、『 1) 畑村 洋太郎 編 著:続・続 実際の設計― 失敗に学ぶ .日刊工業新聞社,1996.』とあります。 {{コラム|失敗とスポーツの例え話| ビジネス書で昔からよく言われるのですが、新しいことへのチャレンジには失敗はつきものです。 でも、新しいことにチャレンジして経験を蓄えることが、今後の成功につながるのです。もし失敗をおそれて新しいことにチャレンジしなくなったら、もはや次の成功にはつながりません。 失敗しないけれど成功もしないで市場から淘汰されることになるよりも、失敗してもいいのでそれ以上の大成功をおさめて市場で行き続けることができればいいのです。 よくビジネス評論ではスポーツに喩えられるのですが、スポーツのサッカーや野球などの試合にたとえれば、3点を奪われても、こちらが5点を得て結果的に勝てればいいのです。 逆に、1点しか奪われなくても、こちらの得点が0点なら、試合には負けます。 だから、「試合での負け」に相当するような致命的な失敗さえ、回避できればいいのです 「たとえ失敗しても、試合に負けなければいい」のです。「失点しても、試合に負けなければいい」のです。 塩川氏も、失点しても試合に勝てれば良いという内容のことを書籍で発言しています<ref>『ゲームデザイン プロフェッショナル』、P.334</ref>。 さて塩川氏の著作では、失点でない単なる「ミス」を「不具合の発生」、「失点」をユーザーの不利益、「負け」を「売り上げの低下やユーザーの離脱」（長いので抜粋）などと定義しています。 塩川氏の意図は分かりませんが、少なくとも新しいことにチャレンジすれば、未知の失敗は起きますので、ITソフト業界なら、それによる不具合の発生が起きます。 その不具合の結果、ユーザーに不利益が一時的に生じることはあります。しかし、そういう一時的な不利益は、新分野の開拓では避けられません。 ユーザーで実験する前の、最低限の手元や仲間内での実験は必要でしょうが、しかし未然の実験で今後のすべてのミスを防止することは不可能です。 }} === 異業種の立場を想像しよう === ゲームにかぎらず、文芸でもイラスト趣味でも、、狭いコミュニティ内の内輪ウケばかりに特化していって衰退していっている文化は多い。そうならないように気をつけよう。 内輪受けのマニア化による初心者忌避による衰退をうまく表現できている言い回しとして、プロレス業界の格言ですが「マニアが業界を潰す」という格言があります。なお、この発言は2012年に新日本プロレスリングを買収したゲーム会社のブシロードが買収時に述べた発言「すべてのジャンルはマニアが潰す」が元になっているので、まさにゲーム業界の反省にもとづく考察でもあります<ref> [https://newspicks.com/news/4135958/body/ 『【最終話・木谷高明】すべてのジャンルはマニアが潰す』 2019/10/5 ] 2021年11月7日に確認</ref>。（ブシロードの文脈とは違うかもしれませんが（出展の外部リンク先が有料なので読んでいないので）、本wikiでもおそらく後述していますが、ゲーム業界では1990～2000年の一時期、ジャンルによってはゲームが高難易度化した作品が多くなって、そのため新規参入者が苦手と感じてプレイヤーが減って衰退縮小していったジャンルが幾つかありました。） なので、ゲーム製作のこういった予備知識のないファンコミュニティの意見ばかりを鵜呑みにして聞いていると、初心者を遠ざけた高難易度ゲームと化してしまうおそれもあります。 特にゲームセンターにある対戦格闘ゲームでは、「初心者狩り」といって、初心者が筐体で練習したくても、熟練プレイヤーが参入して初心者を負かして初心者がゲームプレイヤーになるので、初心者は練習できない。・・・その結果、気がついたらそのゲームの新規参入層が減っていった・・・という事例がありました。 ゲームにかぎらず、スポーツなどの競技の人気でも、似たような現象が見られます。競技というジャンル自体が技巧などを競うものなので仕方ない面もありますが、なんとかして初心者を遠ざけない工夫はゲーム屋には必要でしょう。 ともかく、上述のような色々な理由で、作家側は、体感の難易度が、本当は難しめのゲームなのに「やさしめ」に感じがちである。 実際、日本のゲーム史でも、1990年代の前半ごろは、ゲームの難易度が「むずかしめ」に調整されがちであった。しかし、その結果、世間では「最近のゲームは難しい」と感じる人が増え、日本のゲーム人気は一時期、衰退し、アニメ産業などに人気を取られる事態になった。 {{コラム|作者は答えを知ってしまっている| バランス調整とは少し違いますが、作者はネタバレを知ってるので、シナリオに感動できないわけです。 これは、ハドソン（ゲーム会社名）の『新桃太郎伝説』（スーファミ版）の攻略本『新桃太郎伝説　究極本』（KKベストセラーズ 刊）で、作者の　さくま　あきら　が、読者インタビューに答える形でそう言っています。 ゲーム雑誌での読者からの「ゲーム中、もっとも印象に残ったシーンはどこですか？」という旨の質問に対し、さくま氏は「作者はシナリオの答えを知ってるので、もっとも印象に残るとかそういうのはありません」的な内容の返答をしています。 }} ;ティッシュテスター さて、作者バイアスでバランスが分からなくなるのは作者だけではなく、テストプレイヤーやデバッガーも、そのゲームに慣れてゆくと、次第に感覚が一般プレイヤーとズレていき、テストプレイヤー達もゲームの適切なバランス側が分からなくなっていく。 このことを比喩した表現として、「ティッシュ テスター」（tissue tester）という用語がある。使い捨てティッシュが1枚あたり1度しか使えないように、そのゲームに予備知識の無いテスターも、一度しか使えないのである。「フレッシュミート」（新鮮な肉、fresh meat）とも言います。 かといって、テストプレイヤーの人数にも限りがあるので、ゲーム作者は、たとえ自作ゲームのバランス調整が不完全でも、最低限の調整をしたら、もう「えいやっ」と（フリーゲームや同人ゲームなら）ゲームのver1.00および以降バージョンを出さざるを得ない。 単にバグを探すだけのデバッグ用テストならティッシュテスターでなくても可能ですが、しかしバランス調整ではティッシュテスターがいたほうが効率的です。 === 要素の相互関係 === ==== 概要 ==== 文献『ゲームデザイン プロフェッショナル』によると、調整は、関連あるものを、まとめて同時期に、ただし1個ずつ調整していきます<ref>『ゲームデザイン プロフェッショナル』、P.182</ref>。 このため、まだ関連ある要素を実装しきっていない段階では、調整しません。だから開発の最初から調整することは、まず無いでしょう。 しかし、場合によっては、要素の実装をそろうの待つと調整開始の時期が遅くなりすぎてしまい、計画に支障が出る場合があります。そういう場合、ある程度のまとまりのある実装ができた段階で、調整をするようです。 具体的な調整の判断基準については、参考文献『ゲームデザイン プロフェッショナル』を買ってお読みください。 もし読者が練習として、てっとり早くレベルデザイン・バランス調整の経験を積みたい場合、角川書店（現: KADOKAWA）の『RPGツクール』という制作ツールで実際にゲームを作ってみるのが良いでしょう。文献『レベルデザイン徹底指南書』（大久保磨 著）でも、RPGツクールによる練習・勉強を進めています<ref>大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81</ref>。 ==== マップと敵の相互関係 ==== ゲームバランスを決めるのは、敵の強さだけでなく、マップの構成、さらにRPGのダンジョンなら宝箱の中にあるアイテムや装備品の強さ、などなどのさまざまな要素が加わります。 宝箱もマップの構成要素ですから、広い意味では宝箱もマップだとすると、つまり敵そのもののの強さだけでなく、マップもバランス調整に大きく影響します。だから、もし仮に時間が無限にあるのなら、理想的には、ダンジョンなど各ステージののマップが実装されてからバランス調整を行うのが理想でしょう。 しかし、実際には、マップの実装は、なかなか時間の掛かることです。特に、マップを考えることは、そのステージの世界観などを考えることでもあるので、そういった理系的ではない文系的なことも考えなければなりません。 マップに敵を組み込む方式で調整する場合だとマップの実装を待っている間にはバランス調整が出来ないのも、なかなか難しい問題です。 だからマップと敵の調整の順序は、おそらく人や会社によって色々な方式があると思います。たとえば、 :マップを作ってからそのマップに敵を組み込んでみてプレイしてみて、敵の強さを決めるのか、 :それとも敵の強さを決めてから、マップを決めるのか、 :あるいはマップと敵を別々に決めてから、最後に組み合わせて微調整するのか、 などなどです。 ご自身の作品にあった方式をお選びください。 ===== 始めよければ全てよし ===== さて、ゲームが長編になる場合、まずはプロトタイプ的に、序盤をやや多めに通しプレイをして、とりあえず序盤のバランスがゲームとして面白くなるように調整すると良いでしょう。 書籍『ゲームプランナー集中講座』でも、ゲームの初めと終わりの印象がよければ、途中のバランスが少しくらい悪くても楽しんでもらえると述べています<ref>『ゲームプランナー集中講座』、P236</ref>。 :※ なお、アニメ産業でも、実はテレビアニメは、第1話と最終話だけ、他のエピソードよりも予算が多めに作られるのが普通です（特に公言はされてないが、多くの作品で明らかにクオリティが違う場合が多い）。 とはいえ、ゲーム制作当初は、そもそも終盤のストーリーがまだ未完成だったりするので、意図せずとも、こういったプロトタイプ的に序盤をやや多めに調整する方法が自然に行われる事になるでしょう。 商業作品でも、たとえば攻略本やファンブックなどに書いてあるゲーム開発裏話などを見ると、RPGでは、（プレイヤーからは数値の見えない）敵の強さのほうを動かすことで、バランスを調整するという事例などもよく紹介されています。よくある話が、最終ボスなどの能力値です。原理的には、敵側の能力値ではなく、味方の能力値で調整したり、あるいは装備品で調整したりしてもイイはずですが、しかしよく開発裏話に出てくるのは、なぜか敵側の能力値の話題ばかりです。 たとえば、スーファミRPG『新 桃太郎伝説』では、最終ボスのパラメータのほうを調整していることが、KKベストセラーズ（出版社名）から出た攻略本『新桃太郎伝説究極本』に書かれています。（調整前はボスはもっとHPが多かった。） :※ただし、あくまでRPG限定の話題。アクションゲームなどでは、違うかもしれない。 また、こういった調整順序の前提として、調整はゲーム序盤から順番に、ゲーム後半に向かって調整していくしかありません。 そのため、古いゲームなどでは、よくゲーム後半で、調整不足のために、極端に難しかったり、あるいは逆にあっけなく簡単すぎる後半だったりなどの話題も、よく聞きます。ドラクエ2の後半ダンジョンであるロンダルキア洞窟とその次ステージが典型です。 さて、プレイヤーに目立つ部分（たとえば味方キャラの能力値や装備品の性能など）を基準にして調整するといって、けっして全く数値をイジラないというワケではないのです。あくまで、（調整による変動幅の大きい敵能力値と比べたら、）「比較的には、味方キャラ関連の数値は、調整による数値の変動の幅が小さめ。敵の能力値は、調整による変動の幅が大きい。」という事にすぎません。 {{コラム|ノイマン「ゲーム理論」で説明できないのがテレビゲーム| 日本の人類学者の中沢新一は、ノイマンのゲーム理論で説明できないのが昨今のコンピュータゲームの特徴だと言っています。その発言の出典は忘れたのですが、人類学者で有名な中沢新一は近年、ゲーム産業に関心を持ち、たとえばナムコ出身の遠藤雅信などとも対談しています<ref>https://news.denfaminicogamer.jp/kikakuthetower/nakagawa-endo_bb/2 『ゼビウスからポケモンGOまで… 国内ゲーム史を遠藤雅伸氏と『現代ゲーム全史』著者が振り返る。中沢新一氏も壇上に登場！【イベントレポ】』 2017年4月12日 12:30 公開 ] 2022年1月18日に確認. </ref>。（なお、リンク先イベント記事の司会役の「中川」氏とゲストの「中沢」氏は別人なので、混同しないように） ゲーム理論の用途としては、現代日本の学問では、政治的局面での外交戦略などを語る際によく政治学書で用いられたりします。ただし、そのゲーム理論でも、中沢新一によると、それでコンピュータゲームを語るのは不足だという事です。 中沢は特に言及していないですが、数学的にモデル化するなら、政策応用なら「国際情勢」など外交的な制約によって出力にとりうる値1個あたりの幅や個数が2～3個に限定されたりのような、値の個数が十分に小さくて有限の整数個の場合でないと、なかなかゲーム理論の応用は効果を発揮しません。 （20世紀の天才数学者 フォン・ノイマンの）『ゲーム理論』のような出力値に選べる個数が極端に少ない理論は、コンピュータゲームの調整では不足でしょう。本ページでも、ノイマンのゲーム理論については、版にもよりますが、このコラム以外では特に言及していないだろうと思います（2022年1月までの時点では、ノイマンのゲーム理論には言及していない）。 さて中沢の意見ではないですが、そもそもゲーム理論についてノイマンについての出典として、たしか数学者の森毅（もり つよし）のエッセイ本だったと思いますが、ゲーム理論はもともとノイマンが第二次大戦中の亡命中か何かにトランプのポーカーを参考に考えついたらしいです。 ネット上のゲーム評論では、経済由来の表現でよく使われる表現は、ゲーム理論ではなく「インフレ」「デフレ」などといった表現です。 経済学を知らなくてもゲームは製作できるでしょうが、どうしても経済学を参考にするなら、ゲーム理論よりも物価政策のほうを勉強したほうが良いかもしれません。 一応、書籍『ゲーム作りの発想法と企画書の作り方』ではゲーム理論も紹介されていますが、しかし具体的にどうゲーム作りにゲーム理論を応用するかは書かれていません<ref>『ゲーム作りの発想法と企画書の作り方』、P64</ref>。 }} === 各論（デザイン的なこと） === どの程度、レベル上昇でキャラクターを強くすればいいかについては、ハドソン社あたりでの有名な慣習があり、新しく訪れたダンジョンなどでは「レベルが3上がると、敵を1撃で倒せるようにすべし」という有名な基準があります<ref>『ゲームプランとデザインの教科書』、P.94、 ※ 著者のひとりの「平川らいあん」氏はハドソン出身</ref>。他社ゲームでは別かもしれませんが、だいたいスーファミ時代の桃太郎伝説シリーズはこんな感じに調整されているはずです。 == RPGのダメージ計算式 == === 特化型が有利になりやすい === 文献『ゲームプランとデザインの教科書』によると、ファミコン時代のゲームに限らず、21世紀の現代的なゲームでも、「なんでも平均的にできる」キャラクターよりも「○○だけなら自分が一番強い」といった感じの特化型のキャラクターが戦闘では強くなりやすい傾向があります<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.227</ref>。対して、バランス型は「器用貧乏」になりやすいのが現状です<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.227</ref>。 なお文献『ゲーム作りの発想法と企画書の作り方』によると、ダメージ計算式を考えるのは（プログラマーの仕事ではなく）ゲームデザイナーの仕事です<ref>『ゲーム作りの発想法と企画書の作り方』、P145</ref>。 では、特化型が有利になりやすい原理を、これから説明していきます。 たとえば、キャラクターに能力をプレイヤーが自由に選んで振り分け配分できるシステムのゲームがあったとしましょう。（商業ゲームでも、いくつかの作品で、似たようなシステムのRPGがあります。） 説明の単純化のため、合計値が必ず100だとしましょう。 つまり、たとえば下記のようになります。 ;作成キャラの能力例 :（※ 合計100） ちから: 10 たいりょく: 30 しゅびりょく: 10 すばやさ: 40 きようさ: 10 さて、別の作成キャラ例を考えます。 ;平均型キャラA ちから: 20 たいりょく:20 しゅびりょく: 20 すばやさ: 20 きようさ: 20 :（※ 合計100） のように、能力値を平均にふりわけたキャラクターと 合計値は同じですが、特定のパラメータに特化して能力値を振り分けした ;特化型キャラB ちから: 40 たいりょく:20 しゅびりょく: 30 すばやさ: 5 きようさ: 5 :（※ 合計100） のようなキャラクターを、 コンピュータ上でRPGの戦闘システムのアルゴリズム上で対戦させた場合、 ほとんどの20世紀のRPGのアルゴリズムでは、特化型のキャラBのほうが勝ち、つまり特化型のほうが強くなってしまいます。 さらに言うと、たいてい「攻撃力」のような、敵にダメージを与える意味のパラメーターに振り割ったほうが、キャラクターが強くなるゲームのほうが多いです。（ファミコン時代から、ウィザードリィ1の攻略本でそういわれていました。敵モンスター『ワイバーン』あたりの攻略法として「攻撃は最大の防御」という格言を出しています。表紙の黒かった攻略本なので、たぶんゲームアーツの本。『ウィザードリィ攻略の手引き』(MIA BOOKS)かと思われます。） なぜこうなるかと言うと、なぜなら、もし攻撃力が上がると、敵を倒すのに要するターン数も減少するので、結果的に敵を倒すまでに自キャラの受けるダメージ量も減るからです。（なお、現実の軍事学でも、似たような事が言われており、戦術論ですが、クラウゼヴィッツ（近代ドイツの軍事学者の一人）は防御重視の作戦よりも攻撃重視の作戦のほうが有利だと述べています。防御だけで攻撃しなければ、現実でもゲ－ムでも戦闘では絶対に勝てません。） 裏を返せば、平均型能力のキャラは、多くのゲームシステムでは弱くなりがちです。 パラメータの振り分けは自由ではないですが、ドラクエ2（ファミコン版）でいう、サマルトリア王子が弱くなる現象です。ファイナルファンタジー3・5の赤魔導師も、似たような弱点を抱えています。 理由はいろいろとありますが、バランス側の弱くなりやすい理由のひとつとして、参考文献などは特には無いですが、 :・ウィザードリィやドラクエなどの古いRPGのアルゴリズムが、特化型に有利になっているという歴史的な経緯。 :・命中率などの確率に関わるパラメータ（「器用さ」）のある場合、パラメータ割り振り前から既にある程度の底上げ補正がされている場合が多いので、わざわざ命中率を上げると割り損になる。 :・「すばやさ」（素早さ）が攻撃の順番にしか影響しない場合、素早さが低くても1ターンに1度は攻撃できるので、素早さを上げると損。 などの理由があるでしょうか。 命中率に関しては、多くのRPGで、攻撃が外れるのは、プレイヤーに不満感を与えるので、たいていのゲームでは、ゲーム序盤のレベル1のキャラであっても、数値上での「命中率」や「器用さ」などの表向きの命中率が低くても、たとえば「命中率 40」と表示されていても、実際のゲーム内部での命中率はたとえば＋20%されてて本当の命中率が60%だったりするような場合もあります。 このような底上げ命中率のあるシステムだと、20%底上げされる場合、命中率を80%以上に育てるのは損です。なぜなら100%以上には上がりようが無いからです。 命中率が101%以上の場合に特殊な追加スキルなどを獲得できるなら別ですが（たとえば、クリティカルヒットの確率がけっこう増えるとか）、たいていの古いゲームでは、そこまでの手入れをしていません。おそらく調整に時間が掛かるからでしょう。 === ダメージ計算式 === さて、RPGの戦闘におけるダメージの計算式（「ダメージ計算式」といいます）に、アルテリオス計算式というのがあります。これは、昔のゲーム『アルテリオス』で採用された計算式なのですが、 攻撃側の攻撃力 － 守備側の守備力 ＝ 守備側のダメージ という計算式です。 ドラクエやファイナルファンタジーのシリーズの計算式はもっと複雑なのですが、どのRPGでもダメージ計算式の基本的な設計思想・方針はアルテリオス計算式と同じです。 アルテリオス以外のダメージ計算式でも、たとえば :1.3×攻撃側の攻撃力 － 0.75 × 守備側の守備力 ＝ 守備側のダメージ というような感じの計算式である作品も多いです。 せいぜい、変数の前に定数係数が掛かっている程度です。 なぜ、どの会社のRPGでも、この程度の中学校レベルの単純な計算式なのかというと、バランス調整が簡単だからです。 バランス調整するのは人間なので、もし、ダメージ計算式があまりに複雑な方程式であると（たとえば量子物理のシュレーディンガー方程式みたいなのだったりすると）、そもそもバランス調整担当の社員が理解できません。 そして、このアルテリオス式を見ると分かるのですが、 :攻撃側の攻撃力 － 守備側の守備力 ＝ 守備側のダメージ もし自軍の攻撃力が0の場合、敵にダメージを与えられないので（ダメージが0）、絶対に負けてしまいます。つまり、攻撃力が敵の守備力を下回る場合も、絶対に負けるのです。 一方、「すばやさ」パラメータが戦闘の先攻/後攻の順番にしか影響しない場合、素早さが0であっても、勝つことは可能です。 また、守備力が0であっても、勝つことは可能です。 このように、パラメータの種類ごとに、そのゲームにおいて重視・軽視の差があり、不公平になっている事が多いのです。 また、バランス型の能力値のキャラクターの場合、せっかく「ちから」を上げて攻撃力を上げても、守備側の守備力を下回っていると、ダメージ0になってしまい、絶対に負けます。 つまり、 自分の攻撃力 ＞ 敵の守備力 でないと、アルテリオス式では必ず負けるのです。 一方、 :1.3×攻撃側の攻撃力 － 0.75 × 守備側の守備力 ＝ 守備側のダメージ のように係数を掛けた計算式の場合、 守備力を1ポイント増やしても、その効果は25%減少されます。（たとえばレベルアップの際に上昇パラメータを一種類選べるシステムの場合、守備力を選ぶと損になる場合が多い。） いっぽう、攻撃力を1ポイント増やすと、効果は30%増しです。 このように、計算式によって、有利/不利なパラメータという格差が生じます。 === DPS （Damage Per Second） の概念 === :※ 出典は無いが、あまりに有名な概念なので、さすがに消さない。 最近のRPGゲームには攻撃コマンド選択時に「二段斬り」などのスキル選択ができます。 スキルを設計するとき、昔の初心者のやりがちなミスとして、最近は減ってきましたが、スキルの結果の見かけの数値にゴマかされて、実はスキルが強くなってない特技を設計してしまうミスが時々ありました。 たとえば典型的なのは特技『ためる』です。これは、次回ターン時のダメージを数倍に倍増し、次回ターンの1回だけ、ダメージを倍増させる特技です。 この『ためる』は必ず、次回ターン時のダメージが2倍を超えないと（たとえば2.5倍にならないと）、無意味です。 なぜなら、『ためる』コマンドを選択したターンは、攻撃をしてないからです。 つまり、スキルを使わずに普通に2ターン通常攻撃した場合、ダメージ量は単純計算で :1+1=2 より、2ターンぶんのダメージです。 いっぽう、『ためる』コマンドを使えば、それがもし2倍しかダメージが倍増しない場合、 :0+2＝2 で、結果は同じ通常攻撃2発ぶんのダメージのままです。 計算すれば子供でも分かる理屈ですが、しかしファミコン時代には市販の商業ゲームですら、こういうミスがありました。たとえばファイナルファンタジー3の職業『空手家』のスキル『ためる』です。 このようなミスを犯さないために必要な概念としては、'''DPS''' （'''D'''amage '''P'''er '''S'''econd） の概念が便利でしょう。DPS とは1秒あたりのダメージ量、という意味です。 もともと欧米のアクションゲームについての理論研究に由来する用語なので、単位が 秒 （second）になっていますが、RPGに応用する場合には単位をターンに変えるなどして工夫しましょう。 このDPSの概念を使って、上述の『ためる』コマンドの設計ミスを説明すれば、つまり、1ターンあたりのダメージ量（DPS）が上昇していないのが問題点です。 では、私たちが改善策を考えましょう。数学的に考えれば中学レベルで充分で、 : 0 + x ＞ 2 を満たす変数xを設計するだけの問題です。 なので、たとえば、『ためる』後の攻撃ダメージ量を「2.5倍」とか「3倍」とかの数値に設計すればいいのです。 では、次に応用問題を考えましょう。 「『ためる』を2回続けると、さらにダメージ量がアップ」などのシステムを導入するときも、必ずDPSが増えるようにしましょう。 たとえば、この場合、ダメージを与えるのに最低3ターンが必要なので、不等式を考えれば、 変数xについての :0 ＋ 0 ＋ x ＞ 3 を満たさないといけません。 つまり、『ためる』2回後のダメージ量は、最低でも「3.5倍」のように3を超える数値、あるいは整数に限定すれば、たとえば「4倍」とか「5倍」とかになっている必要があります。 == KPI == Key Performance Indicator という経営的な指標があり、『レベルデザイン徹底指南書』P140 および 『ゲームプランとデザインの教科書』P70 によると、共通しているのは後述の内容です。なお、『ゲームプランとデザインの教科書』P67 によると、オンラインゲームの運営などで使われる用語ですが、別にゲーム業界限定の用語ではありません。 ;DAU（Daily Active User） :デイリー・アクティブ・ユーザー DAUとは、その日に遊んでくれたユーザーの人数です。 ;MAU（Mathly Active User） :マンスリー・アクティブ・ユーザー MAUとは、その月に遊んでくれたユーザーの人数です。 ;WAU（Weekly Active User） :ウィークリー・アクティブ・ユーザー WAUとは、その週に遊んでくれたユーザーの人数です。 ;PU（Paying User） :ペイング・ユーザー 課金ユーザーの人数のことです。その日を課金ユーザー人数をDPU、その月の課金ユーザー人数をMPUと言います<ref>『レベルデザイン徹底指南書』、P140</ref>。 ;課金率 たとえば、ある月のユーザ数のうちの課金ユーザーの割合など、 一定期間中の課金ユーザーの割合を言ったりしますす<ref>『レベルデザイン徹底指南書』、P140</ref>。 あるいは、全ユーザーのうちの課金ユーザーのことだったりしますす<ref>『ゲームプランとデザインの教科書』、P70</ref>。（書籍によって、内容が微妙に違う） ;継続率 前月と比べて今月はどんだけユーザーが残っているかとか、あるいは前週と比べて今週はどんだけユーザーが残っているかのことを、 継続率といいます。 （以上） このほかにも、色々な指標があります。 == 参考文献・脚注など == fvllhs37iszzfftid1lfamhc8u55ntk 0 27227 206119 206037 2022-08-01T11:20:03Z Honooo 14373 /* 「仕様書」、「企画書」 */ wikitext text/x-wiki {{substub}}このページの主要執筆者は、ゲーム業界経験者ではないので（2022/1時点）、ここの記述は調べ物としては役立ちません。 2022/1時点でゲームプログラミングと直接の関係ない話題が長い、という問題があるので、より簡潔、かつ分かり易い記事への編集にご協力いただけたら幸いです。もっとも現編集者Hは、解ってるならそれを書いた奴が書き直せ、そもそも余計なことは最初から書くな、…とは思いますが…。 このページは、教科書としてゲームプログラミングの方針を説明する際に、どうしても書類についての説明が必要だから記述されています。現状では、一般IT業界や製造業などの設計図を参考に説明がなされています。 == 本書の目的 == 本書は、ゲームデザイナーのための教科書ではありません。 メインページ、「[[ゲームプログラミング]]」の題名どおり、プログラマーのための教科書です。プログラマーがゲーム制作に興味をもって実際に作り始める際に、調べ物の手間を減らすために書かれた参考書籍です。 ゲームデザインに関する解説を望む方は、別途、他の参考資料に当たってみてください。 ==「仕様書」== ここでいう「仕様書」とは、ゲームの設計図のことです<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.126</ref>。しかも職業的に集団でゲームを作るときの書類です。 ではまず、「設計図」とは何か、について、考えていきましょう。これは普通科高校では学習しない事項です。 ゲーム業界では、「仕様書」を含む書類群の「発注書」には、決められたルールや書式はありません。だから作るゲーム内容や製作チームごとに、適切な発注書のありかたを毎回考える事になります<ref>『ゲームデザイン プロフェッショナル』、P.145</ref>。 職業的なゲーム開発では、一般に :発注 → 実装 → 調整 というプロセスを経て<ref>『ゲームデザイン プロフェッショナル』、P.61</ref>、最終的にとりあえずの完成になります。 ゲーム産業での「仕様書」は、発注の段階での書類です。 ==集団ゲーム制作での解説文== 発売禁止になってしまった書籍（おそらく。しかし何故？）『国際おたく大学―1998年 最前線からの研究報告』（岡田斗司夫ほか、光文社）に書いてあった事例なのですが、G.O.D.と言うイマジニア社のRPGゲームに対する大学生（岡田は当時、大学講師だった）の取材があって、そのGODの開発に参加した劇作家の鴻上尚史（こうかみ しょうじ）氏と、エニックスの堀井雄二（ほりい ゆうじ）氏とが、対談した経緯が、紹介されていました。 劇作家の鴻上は、ゲームに演劇のリアリティを入れようとして、スタッフに「間（ま）を意識したシナリオを書いてほしい」と要求したが、うまく行かずに難航したと体験談を述べています。 対談相手の堀井は、鴻上のその体験談に対し「『（※ここで3秒休止）』とか書くと良いですよ」と、指示書で具体的に書くと良い、とアドバイスした、と、岡田の書籍にある大学生のレポートにあります。 おそらくドラゴンクエストのゲーム開発でも、このように具体的な指定を必要に応じて出していた・いるものと思われます。 21世紀現代の、商業ゲームの現場でも同様であり、書籍『ゲームデザイン プロフェッショナル』にもありますが（※かぎカッコ内が引用）、「もっとかっこよく調整してほしい」という問題であれば、たとえば「もっと目立たせたいので、アニメーションのシルエットを全体的に今より少しだけ大きくしてほしい」<ref>『ゲームデザイン プロフェッショナル』、P296</ref>という具体的な指定が妥当でしょう。 == 集団作業に必要な書類 == ===設計図=== IT業界やゲーム業界では、集団作業で制作開始をしようとする際、まず、いきなり設計図を作るのではなく、まず先に試作品（しさくひん、英語で「プロトタイプ」proto-type）のプログラムを作り、企画で考えた各種システムなどのアイデアが有効かどうかを検証します。 そのプロトタイプで、企画のアイデアが本当に有効であるかを確認してから、もし有効だったら、本格的な制作を開始します。 もしかしたら会社によっては、企画会議（もしくは企画の打ち合わせ）よりも先にプロトタイプを作るかもしれません。 さて、会社へのプロトタイプ提出で、制作続行・制作本格化の賛同が会社から得られたとしましょう。 IT業界でも製造業でも、どこの業界でも集団作業で、制作の合意を作るさい、必要な書類は、おおむね、 :作業者用の具体的な「完成予想図」 です。 しかしゲーム業界の場合、いきなり完成予想図に相当する「仕様書」は書けないので、書籍『ゲームデザインプロフェッショナル』によるとまずゲーム中の大まかな実装予定事項を記述した『企画概要書』という書類を作成することもあると言われています<ref>『ゲームデザインプロフェッショナル』、P139</ref>。ただしこの「企画概要書」は、名前に「企画」とはついているものの、どちらかというと仕様書の方針を大まかに打ち合わせするための書類に近いので、いわゆる「企画書」とは異なります。 なお、一般のIT企業でよく書かれる「要求事項書」は、ゲーム書籍では紹介されていないので、おそらくゲーム業界では書かないのが普通だと思われます。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） ===ゲーム業界での技術職=== 言葉というのは同じ国の国語でも、その業種や職場、社会集団で、微妙に違った使われ方をすることも多く、技術職、という言葉もゲーム業界での特別な使い方があるようですね。 この業界では、グラフィックデザイナ－やサウンドクリエイターやプログラマーが「技術職」<ref>『ゲームプランとデザインの教科書』、P125</ref>。技術職 = ￢(not)企画職、という事で、プロデュ－サーやプランナーやディレクターなどの「企画職」でない製作スタッフが技術職です。 ただ現編集者はプロデューサーとディレクターは対立する職種だというイメージはありますね。プロデューサーは企画職だろうけど、ディレクターは、"実"制作職ではないかな？ ===企画書=== *PREP法 基本的にビジネス上の書類は、結論を一番先に書く構成法が望ましいですね。もちろん商業ゲーム制作の現場でもそうでしょう。文献『ゲームプランナー入門』では、具体例として、PREP法を紹介しています。 PREP法とは、 :Point（結論）→Reason（理由）→Example（具体例）→Point（結論）。 ほかにもホールパート法やSDS法などがありますが、どれも冒頭で結論を示した後詳細を伝える方法で、ビジネス文書はやはり、その形式が常道でしょう<ref>『ゲームプランナー入門』、P141</ref>。 しかしこの社会、ビジネスが重要なのは事実だが結局、他者の行為や仕事をただ自分の欲望と利益に使い、他者の存在や詳細に興味のない人間は、とにかく結論だけを先に聞きたがるし、それ以外の事には事実上何の興味も持っていないでしょう。 *ゲームのルール 常識的な判断としては、ゲームにはルールがあるものですよね。ルールのないゲームというのは、ふつうあまり考えつかないし、イメージできない。 ですからゲーム企画書としては、ルールの説明が必要になる。キャラクター設定や世界観の解説があったとして、ルール説明がない企画書はふつう受け入れられない<ref>『ゲームプランとデザインの教科書』、P83</ref>。 ただ今ではゲームジャンルの固定化が進んでいるので、ルールはくどくど説明する必要はない、という場合はある。 企画書を誰が書くかという問題もある。業界の内部の重要人物か、全く外部の業界経験の無い人物か。 どちらににろ常識判断としては、ある程度のゲームルールの解説は必要だろう。 *プレイ人数 企画書には、ゲームのプレイ人数の記述も必要<ref>『ゲームプランナー入門』、P159</ref>。 ほんとの昔は、一人か二人でプレイするのがコンピューターゲームだったのですが、もはや時代は変わりましたね。インターネットを駆使して多人数プレイ、ソーシャルゲームなんてものも出てきました。 <!--(:※ ここから先、セクション末尾まで文章の編集者が異なります。編集者Hによる文章です。なお出典のある部分は編集者Hではなく別の編集者Sによるものです。)←すじ肉先輩さー、この記述は無いわ^^;;。だってこれって、みなさーん、以下の馬鹿文はHが書いたんだからね、俺、Sujの文じゃあないよ、馬鹿なのはHであって、俺じゃあないから。Sujはちゃんと出典は全部書いてんだよ^^、って言ってるのと同じだよね^^;;;;;--> さて、企画書に関しては、よくない企画の典型例というのはあるようですね。特に特定人物のネームバリューに依存した企画は良くないし、批判の対象になることも多いようです。ゲームとしては、イラストレーターや声優に超大物を起用することを強調した企画書ですね。 出典として『テリー伊藤のお笑い大蔵省極秘情報』あたり、確実に特定はできませんが、木村拓也のタレント性に頼った企画は、著者のテリー伊藤によってよくない企画の例として指摘されていたようです。 もっともテリー伊藤という人物自身が、ビートたけしの面白さ、彼を起用したことの良さによって世に出て知られるようになった人物なので、そんな事言っていいのかね、などと現編集者は少し思いますが…。 また今回の本題、ゲーム業界でもそういう良くない企画書が提出されることは多いようです。元ゲーム業界人でゲーム評論家の あべひろき が、90年代の著書で、過去にゲーム関連会社に勤務してたときの体験談を書いています。企画書の精査をしているときに、「人気声優の○○さん起用！」と書かれていたものがあったが、あべ氏がその声優の所属する声優事務所に確認の電話をとると、なんの商談も声優とも事務所ともされていなかったという事です。 もっとも企画書とは企画に過ぎないのではないだろうか？これらの他人のネームバリューに頼った企画が良くないのは事実だが、企画が通って実現する見込みが決定する以前は、むしろ声優本人や事務所にアクセスすることはないのが普通だろう。 もちろん企画者がその事務者や声優と懇意にしてる場合は、あらかじめ話をする可能性はあるが、しかし企画段階ではそもそも現実のビジネスになる可能性はそれほど高くない。声優や事務所にとってもその段階でもっともらしく話をされても、むしろ困惑するだけではないだろうか？ ただこういう他人任せの企画は、「プロデューサー的企画」と呼ばれるようです<ref>吉冨賢介『ゲームプランナー入門』、P71</ref>。クリエイティブな企画とは言えないわけですが、しかし商業的な娯楽作品には、クリエイターだけではなく、プロデューサーも絶対必要でしょう。 一般に企画でも他の仕事でも、他者の力や権威、その後の作業などに頼り切った態度は、どんな場所でも嫌われて批判されますし、それは職業の場だけではないでしょう。 また、ゲームの企画に関してもう一つの話題として、アメリカでも売ることに成功したドンキーコングの、ディレクターの宮本茂（任天堂）は、「人間の生理的なところを体感できるゲームを作れば、それがユニバーサル」、だと、語っていたようです<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P89</ref>。 ===「仕様書」、「企画書」=== 商業的なゲーム制作では、一般に、 発注 → 実装 → 調整 の過程を辿ります。 そして発注段階で重要な書類は、「企画書」と「仕様書」の二つです。まず『企画書』で作るゲームのコンセプトを固めてから、あとで『仕様書』で、より詳細に内容をを決める、という順序をとります<ref>『ゲームプランとデザインの教科書』、P43およびP45</ref>。 企画書<ref name="gcs72">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、72ページ</ref>は社内だけでなく協力会社にも見せる資料であり、開発者・協力者に対して手短かに、そのゲームの全体的なコンセプトを伝えるためのものです。 仕様書は、ゲーム制作では「設計図」であり、「完成予想図」であるといっていいでしょう。企画書よりより詳細にゲームの内容を決め、指定しています。 さて、話を進める前に、商業的に集団でゲームを作る場合の他の書類や必要事項の名称について、ここで簡単に書いておきます。 まず「発注書」とは，発注時に作られる、必要な書類群のことでしょう。「企画書」と「仕様書」も含みます。 「指示書」はむしろ、実装や調整段階でなされる、具体的なゲーム演出上の指定でしょうね。 試作品（しさくひん、英語で「プロトタイプ」proto-type）や企画会議（もしくは企画の打ち合わせ）なんて言葉も出てきますが、こういうのはあえてクドクド説明しなくても、直感的にイメージわきますよね。 『企画概要書』とは企画書とは異なるもので、仕様書に準ずる書類で、仕様書の方針を大まかに打ち合わせするためゲーム中の大まかな実装予定事項を記述している書類です。 『原案書』<ref name="gcs72" />は社内だけで企画がペイするかどうかの検討を決算書などを参考に分析・会議するための書類です。 こういう書類や用語に関する言葉の使い方は、商業的集団的なゲーム制作の場として妥当と思われるものをまとめてみましたが、もちろん職場によって、会社によって使い方や意味が微妙に変わってくる場合はあるでしょう。 さらにゲーム以外の一般IT業界や製造業でもそれぞれの慣習があり、今回の説明が成り立たない、そしてそこはより一般的な職場ですから、それぞれより一般的な言葉の使い方があると思います。 さて、コンセプトの具体例として、書籍『ゲームプランとデザインの教科書』によると、たとえば『ポケットモンスター』のメインのコンセプトは、「通信ケーブルを伝わって、ポケモンが入ったカプセルが移動して交換する」、が始まりだそうです<ref>『ゲームプランとデザインの教科書』、P109</ref>。 また、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、『メタルギア』シリーズのコンセプトは、「敵に見つからないように進む」、とのことですね<ref>吉冨賢介『ゲームプランナー入門』、P108</ref>。 イラストや音楽の発注は、一般的には企画が決まった後でしょう。 そもそもイラストレーションや音楽を対価を払って提供してもらったとして、それを実作品に使用しないのは、作者にとっては不本意なことだと思います。 アニメーターの故大塚康生氏は、アニメーション演出家が安易にアニメーターに大量の絵を描かせ、そこからいいもの、利用できるものだけ取捨選択する方法を批判していましたし、一般的に手仕事には作者の思い入れがありますから、安易な大量生産品と同じ取り扱いはできないと思います。 もっとも一方で、あるアメリカの日本人アニメーターが、同僚の日本人アニメーターが、自分の描いたものを日本の家族や友人たちが見ることができないことを不満に思っていた、という事を批判的に語っていたのを、現編集者は聞いたことがあります。 しかしゲームの場合、例外的にイラストや音楽が先行する場合はありますね。 RPG『クロノトリガー』は、企画の当初からイラストレーターをつとめた漫画家・鳥山明のイラストがあって、それをもとに作品を作ったと、鳥山のマンガの編集者であった元・少年ジャンプ編集の鳥嶋和彦は述べています。<ref name="tskdq">[https://news.denfaminicogamer.jp/projectbook/torishima/2]</ref>決めシーンなどのキービジュアルを先に決め、それに合うように設定を練りこんでいくという方式で、クロノは作られたようです。 企画書の制作ツールとしては、清書としては、オフィスソフトの「PowerPoint」と、アドビの「Illustrator」、または、アドビのソフトウェアは高価なので代わりにフリーソフトの「Inkscape」および「GIMP」がよく使われます<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日第1版第1刷、P.281</ref>。なお、Illustrator および Inkscape は、ベクトル画像を描画するソフトウェアです。 ただし、下書きなどでは、タッチペンと何らかの画像ソフト、またはタッチペン用メモソフトで下書きすることもあります。 業界で、ゲームプランナーと呼ばれる職種は、仕様書作成や進捗管理、テスト&デバッグ、スタッフとのコミュニケーション、などが仕事ですね<ref>『ゲームプランとデザインの教科書』、P.9</ref>。 また、ゲーム制作に関して、だれもが様々なアイディアを持っていると思いますが、メモを取って、もし忘れてもメモで思い出せるようにするといいですね<ref>『ゲームプランとデザインの教科書』、P.20</ref>。 アマチュアの企画なら、実際にプロトタイプ（プレイできる試作品のこと）を作って実作品で企画、仕様を説明してしまったほうが早いかもしれません。 参考文献『ゲームプランとデザインの教科書』でも、（試作品を）「ゲームプランナーを志す中で企画書や仕様書を書きながら、ぜひ自分でも作ってみましょう。プログラムや3Dモデルを簡単なものでいいので作ってゲームに仕上げてみましょう。」と述べています<ref>『ゲームプランとデザインの教科書』、P.3</ref>。 上記の本の図表によると、企画書では、「競合情報」、「世界観」、「ストーリー」なども記述して欲しいようです<ref>『ゲームプランとデザインの教科書』、P.43 </ref>。世界観とストーリーが分けられているのです。 物語とその舞台ですね。我々自身もこの世界で自分という役を演じている役者ですよね^^ {{コラム|ゲームの企画書とアニメーションの企画書| 商業アニメーションの世界では、企画の段階でストーリーの概要が決まっているようです。ただこれは、アニメーション作品の企画として、当然に必要とされる要素であるから記述されているわけで、実制作の過程で、実際のスタッフの意向により大幅に変更されることもあります。また、これらの企画では、キャラクター設定やキャラクターイラストのデザインも当然必要であり、かなり明確な形で提出されています。 たとえば、アニメ業界の企画書ですが、1990年代のアニメ『新世紀エヴァンゲリオン』の企画書の掲載されている『新世紀エヴァンゲリオン (ニュータイプ100%コレクション) 』（1997年2月28日初版発行、85～88ページ）を読むと、『企書画』の段階でもう、キャラクターイラストが主役だけでなくその友人や周囲の大人なども含めて、ほとんどのキャラクターでイラスト紹介されており、さらに全部の話数ぶんの粗筋と見せ場・意図を2～3行ていどで説明しています（ただし第1話と最終3話（24～26話）のみ説明が5行以上くらいと長い）。 因みに現編集者は実際にアニメーション業界で企画書を書いたことがありますが、その時に上司、制作会社の重役に指摘されたのは、1クール（3か月）か2クール分の実際のストーリーの具体内容を書いてほしい、との事でした。 一方ゲーム業界では、そういうキャラクター設定やストーリーは、企画段階では決まっていなくて、もし書かれていても邪魔だと感じられるようです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、149ページ</ref>。 業界の企画書で、強調してほしい内容とは、ゲームシステムと、そうシステムを設計した根拠のようです。なぜなら、ゲームの企画書でいう「コンセプトが重要」、と言う際の「コンセプト」の意味とは、ゲームシステムやゲームルールを設計した根拠のことだからです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、108ページあたり</ref>。 とはいえ、ゲーム業界の企画書でも、ゲームの世界観が「中世西洋ファンタジー風」なのか、「現代日本」か、「近未来SF風」なのか、などの設定はある様です。ネット上で公開されている商業ゲ－ム企画書からその様子が分かりますが、しかし、最初の企画書の段階で決まってる世界観はその程度まで、です。 背景としては、ビジネスモデルが根本的にアニメーション業界とゲーム業界とでは違う、という事情があるのでしょう。 }} {{コラム|キャラクター重視の物語論| アニメ―ション業界のビジネスモデルは、キャラクタービジネスだと言われています。1990年代の徳間書店のアニメーションに関する書籍（アニメージュ10周年記念）で、徳間の編集者が1980年代のアニメ業界を振り返ると、これはキャラクタービジネスだろうと、たとえば銀河鉄道999のアニメ―ションの人気も、メーテルなどのキャラクターの人気なのだという分析があり、アニメージュ創刊当時の『銀河鉄道999』特集では、ストーリー解説ではなく、キャラクターに焦点を当てた記事を組んだと、述懐（じゅっかい）しています。 また、漫画産業もキャラクター重視のようです。主人公に共感させるための様々な演出が凝らされている。そして主人公が身近に感じられることが重要だと指摘されています<ref name="tskdq" />。 これは日本人が物語軽視というよりは、海外でも同様であり、むしろ物語とはキャラクターを描くという要素が非常に大きいという事でしょう。多くのミステリの中でも「シャーロック・ホームズ」や「007」の人気が非常に高いのも、キャラクター性と結びついた作品だからでしょうね<ref name="tskdq" />。 1982年頃『鳥山明のヘタッピマンガ研究所』では、おおむね「マンガとは人間を描くことだ」という主張がなされています。 現編集者の記憶では、漫画がキャラクターだという主張を強くしたのは、漫画原作者であり、劇画村塾の開設者である、故[[w:小池一夫|小池一夫]]氏でしょう。上述の書籍の共著者、さくまあきら氏も、劇画村塾出身ですから、さもありなんということですね。 アニメ評論家の岡田斗司夫氏は、対談集『マジメな話』で、「古代ギリシア人や古代ローマ人はとても論理的で学問も発達していたが、一方でギリシア神話やギリシア悲劇が普及していた、人間には物語が必要なのだろう、自分達の社会の仕組みを、物語になぞらえて理解する、物語が学問や科学に匹敵する」といったことを述べていました。 ギリシア神話では実に人間的な神々の物語が語られていきます。 また、政治学者小室直樹氏は、別の書籍、おそらく、『日本人のための宗教原論』あたりで、「幼少期の子供にとっての、父親の力強さと畏怖のイメージ」こそが神のイメージだろうと述べています。ギリシア神話の最高神ゼウスは、明らかに父性を示していますよね。 これはユダヤ教やキリスト教の神のイメージだと考えてもいいと思います。この辺[[w:父なる神]]あたりに面白い記述がありますし、一方でイスラム教は神に父性を見出さない、などの興味深い分析も書かれています。 また、RPGゲーム『真・女神転生』では、裏設定ですが、作中の「悪魔」とは、力の象徴であり、それは父親を暗喩しているというコンセプトがあります（たしか公式ファンブック『CLUB邪教の館』あたりに記載がある）。だからこのゲームの主人公は、父親がいない母子家庭の子供だという事になっています。 }} {{コラム|ゲームにおけるキャラクター| ゲームの世界は、ソーシャルゲームや美少女ゲーム等はありますが、一般的にはキャラクター重視のメディアではないようです。シューティングゲーム『ゼビウス』のキャラクター性とか、『平安京エイリアン』のキャラクター性など、想像力を最大限に駆使すれば見出せないことはないですが、常識的にはキャラクターの魅力は提供されてはいないでしょう。 ゲーム学という概念を推進している人達は、ナラティブ（「叙述」という意味）といって、スーパーマリオなどのように作中にストーリー説明文が無いゲームのことを説明しているようです。 今現在では、可愛いキャラクターや恰好いいキャラクターを作品に取り込めるのなら、それを除外する必要はないでしょう。しかし現実の人気ゲームでは、キャラクター性があいまい、あるいはほとんど見出せないゲームも多いですよね。 ゲームのキャラクターは、開発途上で変更される可能性もある。海外展開しているゲームは、相手国の風習、社会状況に合わせて、キャラクター設定を変える場合もある。 今現在は、ソーシャルゲームでもキャラクターゲームは人気ですが、昔はそうではありませんでした。1990年代は、多くのゲームファンの間では、「キャラクターゲームはつまらない」と言われていました。 2002年にシリーズ発売開始されたRPG『ドットハック』シリーズの企画コンセプトは、面白いキャラクターゲームを実現することであり、2003年当時の社長（松山洋）がラジオ番組『ドットハックレイディオ』に出演した時に、「キャラクターゲームがつまらない」という一般的に言われている常識を打破したい、それがコンセプトだ、と述べていました。 しかし実際には1990年時点で魅力的なキャラクターゲームもありましたし、大ヒットすることは無くても、一部の大きな人気は得られていたようです。 }} {{コラム|企画が実制作に移ること| 1990年代後半に書籍を出し始めた、元ゲーム業界人・阿部広樹氏は、ゲーム会社から請け負って、そこで頓挫した、或いは難航した企画を練り直しする仕事をしていたようです。彼の著作ではその経験、経緯が語られています。 扱った一つの企画が、ガンダム風の巨大ロボット操作ゲームで、企画として完成度の高いものでした。 主要機体の巨大ロボットのグラフィック設定画は線画が完成していて、機体パイロットである主人公の顔グラフィック線画もある、ロボットの設定サイズ（「全長○○メートル」、「主要武器：○○」など）なども含む、仕様書がすでに用意されていました。 機体の名前には「メタトロン」や（たしか）「サンダルフォン」と、ネットの普及していなかった当時では調べるのにも手間のかかるユダヤ教の大天使の名前がつけられていました。 阿部氏も、このゲームは実現するだろうと、期待を込めて企画を進めていたようです。 しかし現実にはこのロボットゲーム企画は対象のゲーム会社では採用されず、実際に制作されることはありませんでした。このようにゲームの企画は、企画だけで終了してしまうものが沢山あります。 一般的に商業ゲームの製作は、本当にペイするかどうか、経営者や出資者の審査、判断の上、実制作に取り掛かるでしょう。 企画を作る方も仕事として取り組んでいるのですから、「没になるかもしれない」といって手抜きするはずもなく、内容的にも、前設定の完成度としても、どれも相当の力と手間暇をかけて企画を練りこんでゆくでしょう。 しかし結果は結果としてありますよね。採用される保証はないしされないほうが実際多い。その判断が正しかったかどうかはまた別の話ですがね。 }} {{コラム|他業種、一般的な意味での『企画書』| 企画書にもいろいろな段階があります。 #本当に企画の初期段階の、内部関係者しか見ない、思いつきを書きなぐったような企画提案の書類（厚さはせいぜい2～3ページくらいまで？） #企画が熟成してスポンサーや外部に見せられるようになった段階、もしくはその直前くらいの企画書（10ページを超える程度） #パワーポイントなどを使ってプロジェクタ－で見せるプレゼン資料の「企画書」 多くの業界の企画書で学生や外部の人間が見るのは 2.か 3.でしょう。 1990年代後半のゲーム評論家の阿部広樹の他者との共著による書籍によると、彼はゲーム業界で企画に関するトラブルを解決する仕事をしていたようですが、ある案件で、「当時の人気アニメ声優を起用！」など書かれた企画書をトラブル解決のために扱いましたが、彼らが調査した時には相手先のアニメ声優および声優事務所には全く話が行っておらず、対応にも難航したようです。ただ、本Wikiの別の場所でも指摘しましたが、企画時点では、その手の手続きを踏む必要はないでしょう。企画は企画にすぎませんし、実現の見通しが大きくはないその時点で話を持ってこられても、声優も事務所も、対応しようがないと思う。ただ、前編集者の記述では、許可をとれそうな見込みもないと書いてあるから、よほどのビッグネーム声優、要するにその声優の知名度だけをあてにしている企画ですから、悪い企画の例として非難されても仕方ないのかもしれません。しかし現編集者がさらに邪推、想像するに、彼らに企画トラブルの解決を依頼したゲーム会社は、自分たちは零細で知名度もパワーもないので、とてもその有名声優にはアクセスできない、ですからトラブル解決を稼業にしている業者なら、上手にその声優にアクセスしてくれるのでは？という期待があったのではないでしょうか？だとしたら、この事案に対する阿部氏らの態度、そして後になってわざわざ自らの著書でその出来事、関係者を愚弄して、それで自分たちが正しいかのように言うこの人物の姿勢は、職業人、仕事人として問題があるのではないでしょうか？ さて、ある程度企画が本格化してくると、スポンサーに提示するプレゼン用の資料とは別に、詳細な設定や企画意図を説明する、「詳述企画書（ここでの仮の名称）」も作られていきます。この書類は今後の作業のためのひな型の意味もあり、具体的にどんなキャラクターが出てくるか、イラストなども描かれます。 因みに、「ゲーム　企画書」でグーグル検索してみると、企画書としては 1.~3. そして今書いた「詳述企画書」が混然と表示され、書類として種類や趣旨は明確化されていないようです。企業が求職者を採用するために、企画書を求める場合は、プレゼン資料が最適のようですね。採用担当者にとって一番読みやすい資料だからでしょう。 企画書として、説得力のある内容なら、採用され実制作に移る可能性も高くなるのでしょうね。そのために指摘される事として、冒頭部分で、この企画と既存の作品の違い、今までの状況からの改善点、そして実際の改良の実現の見通しと方針を示すといい様です。これは「企画意図」や「コンセプト」と呼ばれますね。 「改善点→（競合他社の）現状説明→改善案の詳細」を、詳細企画書で段階的に説明するといいですね。新聞記事の書き方で、起承転結ならぬ「結・起・承」（けつきしょう）というのがあるので、それを参考にするのもいいでしょう。 また、売り込み先の消費者として想定しているターゲット層の指定も必要です。年齢はいくつくらいなのか、性別は男性か女性か、などですね。 企画の詳細を作りこんである場合や、すでにゲームソフトを実装してある場合のシステムの説明では、単にフローチャートを図示するだけでなく、そのシステムでプレイヤーは何ができるのか、簡単な遊び方の概要説明、等を加えるといいですね。 }} {{コラム|日産自動車の社内講習でのアニメーション業界人の講演| どこの企業でも社員向けの講習会はそれなりにあるでしょうが、日産自動車では過去、アニメーション制作会社の幹部を招いて、営業マンや企画職の社員のために講演してもらったことがあるようです。 テレビアニメーション『輪廻のラグランジェ』が2012年に放映されていた前後、日産が取材協力として制作に参加していたので、CG雑誌で、日産の講演会の様子が紹介されていました。 アニメーション業界では、実在しない物体や機械のイメージを、メカニック設定などで詳細にイメージを作り、絵コンテマンや、原画・動画のスタッフ間でその具体設計を共有するので、自動車製造業界でも参考になる要素があると考えられたようです。 日産の担当者は、制作会社の幹部の講演会に手ごたえを感じたので、もっと話を聞かせてほしいと要望すると、『輪廻のラグランジェ』の製作会社を紹介してくれたので、その会社にも講演をお願いし、さらに制作会社側の取材協力にも積極的に応じて、異業種同士のコラボレーションが形成されていったようです。 }} さて、ゲームの『仕様書』はそのゲームの設計図なので、起こりうる全てのパターンを網羅して設計を指定する必要があります…と言いたいところですが、そもそも本当にすべての操作に対する反応をもれなく記述できるのか? しかしできる出来ないにかかわらず、創作物が世に出れば、それはコンピューターアプリケーションとして、ユーザーに自由に操作される。その時仕様と創作物が、合理的に網羅的に作られていれば、プレーヤーはストレスなく、ゲームを楽しむ事が出来るでしょう。 ;検品、検収 さて、一般に技術系の業界では、図面などの設計図は、検品のさいのチェックリストを兼ねています。（ただし、ゲーム業界での「仕様書」が検品チェックリストを兼ねているかどうかは、2022/01時点、著者側の調査不足で不明。） しかし検品自体はゲーム業界でも行っている。協力会社から納品されたプログラムも、仕様を満たしているかチェックするだろう。 そしてチェックを通ったら、合格した製品として正式に受け取る。 納品物を合格として認めて受け取ることを「検収」（けんしゅう）という。（ゲーム業界でも）<ref name="creator_work:77">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、77ページ</ref>。ゲームの仕様書は、この検収を考慮に入れて書くのがいいだろう。 つまり逆に納品物が合格していないと判断されると、受け入れない、検収しない、納品者に作り直しを要求することになるだろう<ref>蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、76ページ</ref>。 商業ゲーム界では、営業マンが見積もりをするときの根拠は、仕様書、という事になる<ref name="creator_work:77" />。 外注テストに関しては、仕様書では不十分で、テスト用の別資料を用意する<ref>『ゲームプランとデザインの教科書』,P9</ref>。 バグチェックを外注しない場合は、「仕様書」を根拠にする場合が多いという<ref>吉冨賢介『ゲームプランナー入門』、P20およびP199</ref>。 つまりやはり、製品の仕様の基盤は仕様書、正しい仕様は、仕様書に書かれている事だという事になる。 開発後半のデバッグ段階などのバグチェックの段階に入る前に、仕様書を最新のゲームの状態とそろえる<ref>吉冨賢介『ゲームプランナー入門』、P238</ref>。つまりこれは、ゲームの仕様が制作過程で変わっていったら、逆に仕様書を書き換えて、実際の仕様に合わせるという事だ。 == そもそも知能労働の現場での作成工程は == === まず完成予想図を示す === 仕様書はゲームの設計図です。仕様書のとおりにプログラマーやグラフィッカーは作業をすすめます。ただしゲームの場合、いきなりは完成図を決めるのが困難な場合があります。その場合、段階的に、決められることを先に大まかに決めていくようです。実際、文献『ゲームデザイン プロフェショナル』によるとゲーム業界でも会社によっては、大まかな「企画概要書」と、より詳細な「仕様書」により、段階的に仕様を決めていったりするようです<ref>『ゲームデザイン プロフェッショナル』、P.141</ref>。 なお、書籍『ゲームデザイン プロフェッショナル』によると、ゲーム業界でも、（設計図ではなく指示・発注ですが）あいまいな指示や発注は事故のもとだと、認識されており、たとえば「とにかく、かっこいい感じでお願いします」といった指示は事故のもとだと認識されています<ref>『ゲームデザイン プロフェッショナル』、P.60</ref>。 もちろん後述のゲーム業界での「裁量」のように例外もあります（なお国語的には「原則」「の対義語は「例外」）。しかし、あくまで技術系の仕事での「設計図」というものの原則は、極力、あいまいさがない事が必要なのです。 例外的にゲームの場合、ある程度は発注では、発注相手の裁量にゆだねたほうが良い場合もあります<ref>『ゲームデザイン プロフェッショナル』、P.134</ref>。しかしその場合も、具体的にどういう実装予定のもので、どこに裁量を与えるのかを具体的に依頼する必要があります。これについてはwikiでは短い文章では引用できず、長い文章を引用すると著作権的に問題あるので、裁量の発注について詳しく知りたい人は書籍『ゲームデザイン プロフェッショナル』を買って読んでください。 === 各機能の完成予想図の決定稿 === ゲームソフトにかぎらず、なにかのソフトウェアの完成予想図を描くとき、それぞれの画面を基準にして書くと、相手に伝わりやすいようです。 おそらく、人の目で画面は見えるので、集団内で確認を取りやすいのでしょう。 たとえば、 <pre> △△モードの××画面 Aボタン: ダッシュ（走る）。押すとキャラが十字キーの選択方向にダッシュするようにプログラムする Bボタン: ジャンプ。押すとキャラが上方向にジャンプするようにプログラムする </pre> のような、それぞれの画面・モードでの機能の満たすべき情報の一覧の書類を作業者に伝えると、良いかもしれません。 IT用語では、このように、ソフトウェアをユーザー視点でも見たときに製品がどういう条件を満たしているべきかを指定した仕様のことを（IT用語では）「外部仕様」と言います。 なので、ソフトウェア設計者は、すべてのモードについて、こういった（画面仕様などの外部仕様を中心とした）一覧を用意する必要があります。 これが、プログラマーにとっての完成予想図になります。 なお、（外部仕様でなく）「内部仕様」とは、ソースコードがどうなってるか、という仕様です。 ゲーム業界では原則的に、内部仕様については、書かないようです。 ただし、実際は程度問題であり、設計しようとしている項目がプロトタイプのどのファイルや変数に相当するかがゲーム『仕様書』に書かれるのが通例だと、ネットでは言われています。 さて、外部仕様について、「画面仕様」のほかにも「外部仕様」があります。ゲームの場合、アクションゲームのモンスターの動き方のパターンも「外部仕様」であり、あるいはRPGのダメージ計算式も「外部仕様」であり、なぜ外部仕様かというとプレイヤーから見たら確認できるので（つまり外部仕様であるので）、ゲーム仕様書では、それらの仕様（敵の動き方、ダメージ計算式など）も指定することになるでしょうか。 ゲームの仕様書はけっこうな割合が画面仕様が中心的になりますが、しかし画面仕様の他の外部仕様もゲームの仕様書では指定する必要があるので、そこは気をつけてください。 == ※ 例 == 完成予想図どうしでは、説明はあまり重複しないようにする必要があります。 なぜなら、もし重複させて他の書類の参照をすると、もしその参照された側の予想図Aで設計内容の変更が起きたときに、参照する側の予想図Bにも設計変更が必要になってしまいます<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、228ページ、</ref>。 なので、完成予想図では、説明のための重複は不要です。これは、製造業の製図でも同様です。製造業でも、ひとつの末端部品の図面では、他の図面は参照しないようにします。 さてゲーム業界の話題に戻りますが、学生にはこのような完成予想図の考えかたは、ちょっと分かりづらいと思いますので、たとえばウディタのサンプルゲームを具体例をあげて、説明します。 仮に、このウディタのサンプルゲームを、新たに仕様書として書き起こすとしましょう（仮にですよ。すでにソフトはあるので実用的には、もうサンプルゲームに仕様書は不要です）。 たとえば、ウディタのサンプルゲームは、メニュー画面で、上から順に :相談 :アイテム :特殊技能 :装備 :システム :セーブ というふうに6つのコマンドがあります。 上から4つめに「装備」というのがあって、それにカーソルを合わせた状態で決定ボタンを押すとキャラクター選択に移り、十字キーで目的のキャラクターを選択して決定ボタンを押すと、装備画面に移ります。 さて、もしこれを仕様書にする場合、たとえば装備キャラクター選択の仕様での説明の文章では、あえて、 【'''装備キャラクター選択画面'''】 '''遷移直後の変化''' メニュー欄に「装備」コマンド位置に決定後カーソル画像「○○○.bmp」を表示。 キャラクター選択欄のカーソルの点滅が開始。キャラクター選択用の点滅用カーソルの画像は「△△△.bmp」。 '''ボタン押の反応''' キャラ選択欄で十字キーの方向にいる隣または次のキャラクターを選択でき、そのキャラの選択欄にて点滅カーソルが点滅表示される。 決定キーを押すと、選択中キャラクターの『装備部位の選択画面』に移る。 キャンセルキーを押すと『メニュー画面』に移る。 '''画像リソース''' ○○○.bmp :メニュー欄用の決定中カーソル画像 △△△.bmp :キャラクター選択欄用の点滅用カーソル画像 という感じの、その画面とやりとりする相手先の画面の名前と、あとはその画面の読み込むファイル等しか、他の画面や他ファイルについては書かないほうが良い、というワケです。 :※ 実際はもっと多くの変化がウディタのサンプルゲームであるだろうが、説明のため単純化している。 :※ 上記の仕様書の書式の参考文献として、吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、221ページ、の例『各画面の仕様書の例』の書式を参考にした。 ついつい学生さんとかだと、 『装備部位の選択画面』に移ったあとの説明も続けて書いてしまいがちです。しかし、そういうのは別途、たとえば『装備フロー仕様書』みたいな仕様書を作成せよ、と考えるのが良いでしょうか。 なぜ別途に分かるべきかというと、もし仕様変更で、『装備』コマンドの位置が（サンプルゲームでは上から4番目だが）上から6個目に変わったりしたら、「メニューの装備コマンドは上から4番目にある」と書いた書類は全部作り直しになってしまいます。 そういう修正時の書類の作り直しの手間を省くため、あえて書類をモジュール化するのです。当然、そのままでは全体像は把握しづらくなりますが、しかし全体像の把握については、さらに別の全体像把握のための専用フローチャートなどを書類に設けるなどして補うことによって、修正の手間がなるべく波及しないようにします。 さて、「装備フロー仕様書」みたいなのを作るときは、たとえば '''装備フロー仕様''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 のようになるでしょうか。 ::なお、フローチャートの作図をしたい場合は、オフィスソフトのパワーポイントの図形描画の機能で作図が可能です。 ::またなお、フローチャートの描き方はJISで決まってるので、ソレを参考に。というか中学校の技術家庭科でも習う。 また、ウディタのサンプルゲームの装備部位の選択画面では、 :右手 :左手 :身体 :装飾1 :装飾2 と5つの項目があります。 もし仮に仕様変更で、部位の名称が変更され、 :武器 :盾 :頭 :身体 :腕 :装飾 とかに名称の仕様が変更したりすると、「装備部位の選択画面の「右手」選択にカーソルの合わさった状態で移る」とか書いた書類は、すべて作り直しです。 なので、『メニュー画面』とか『キャラクター選択画面』とかでは、そういう他画面である装備部位選択画面についての個別具体的な項目の名称（「右手」とか「左手」とか）や移り方の詳細は書かないで、キャラクター選択画面の仕様では単に「選択中キャラクターの『装備部位の選択画面』に移る。」と遷移先の画面名だけを書くべきか、あるいは「画面の変更時は原則、その画面のいちばん上のメニュー項目にカーソルの合わさった状態で画面が移る」とか、どこかの仕様書に書いておいて、あとはその説明を今回も引用するかすればいいだけです。 また、装備コマンドのフローを書くときは、 あまり、 :マップ画面 → キャンセルボタン → メニュー画面 → 「装備」を選択で決定ボタン → キャラクター選択 → 決定ボタン → 装備品選択画面 と設計図の段階では、続けて書くべきではないでしょう。 こういうのは、意味のある内容ごとにいくつかにフローを分解し '''メニュー選択フロー''' 【 マップ画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 メニュー画面 】 というメニュー画面を選択するためのフロー仕様書と、 もうひとつのフロー図面は、 '''装備関係フロー''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 という装備関係のフローとに2分割するのが良いでしょうか。 このように、意味的にまとまりのある単位ごとに階層をフロー分割するのが良いでしょう。 かといって、階層を5分割とか10分割とかすると、まるでゼネコン多重下請けみたいになって、かえって見通しが悪くなりますので、なるべく2分割までにするのが良いと思います。（せいぜい3分割まで） さて、フロー同士の関係の記述では、別途、 【メニュー画面仕様】 '''表示項目リスト''' 決定ボタンで下記の項目を選択できる。 ・相談　　　　　　:決定すればメニュー相談フローに移行 ・アイテム　　　　:決定すればメニューアイテムフローに移行 ・特殊技能　　　　:決定すればメニュー特殊技能フローに移行 ・装備　　　 　:決定すればメニュー装備フローに移行 ・システム　　　　:決定すればメニューシステムフローに移行 ・セーブ　　　 　:決定すればメニューセーブフローに移行 '''非表示項目''' ・キャンセルボタンでマップ画面に戻る とでも書いておけば済むでしょうか。 なお、各画面での遷移先の画面の説明と、フロー図での遷移先の画面との説明が重複していますが、これは実務でも構いません。 参考文献の 吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』の209ページ「状態遷移フローの例」と211ページ「各画面の仕様書の例」とでも、遷移先の画面の説明はそれぞれ重複しています。 ;一枚の図面の中では内容重複はオッケー なお、一枚の仕様書の中では、内容の重複はオッケーです。 たとえば、機能の似たモノを2個つくるとき、 2個目の説明では、「○○については△△と同じ」のように、「～～～と同じ」というふうに説明できるから、です<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ、</ref>。 なぜなら、この場合なら、他の図面を参照する必要が無いので、一枚のその図面の中で完結するからです。 しかし、この場合でも、なるべく二回目以降の説明では「○○については△△と同じ」のように、「～～～と同じ」というふうに説明すべきです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ、</ref>。 あまり、具体的な仕様の文は、二度目からは掲載しないほうが良いのです。 なぜなら、もし参照先である一度目の説明の仕様に設計変更があると、もし具体的な仕様の文を2度目以降にも掲載した場合には、修正のさいに二度目・三度目の説明も修正することになってしまいます。 で、よくミスとして、二個目以降の修正をし忘れるミスがあります。 ;その他 暗黙の前提ですが、画面名やファイル名などの名前を決める際には、具体的な名前をつけましょう<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、213ページ、</ref>。 たとえば、上述のウディタのサンプルゲームの画面をもしアナタが命名するなら :「マップ画面」、「メニュー画面」、「装備キャラクター選択画面」、「装備部位選択画面」などのように、です。 当然のことのように思えますが、しかし、おそらく新人にこういう図面を書かせる仕事を依頼すると、新人によっては、「画面1」、「画面2」、「画面3」、…のような具体的でない名前をつける場合があります。 あるいは、「メイン画面」、「メニュー画面」、「サブメニュー画面1」、「サブメニュー画面2」、…というパターンも考えられます。 しかし、そのような抽象的な命名は他人に伝わりにくいためやめましょう。 ===== 要求事項書はゲーム業界では書かない場合もある ===== IT業界でいう「要求事項」とは、顧客などから、完成品の満たすべき要件を聞き取ったりしたりして、完成品の満たすべき要件をまとめた書類のことです。 しかしゲーム業界では、ゲームプランニングの書籍を読んでも要求事項書は紹介されてない状態です。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） 個人製作のゲームでは、要求事項書は、まず不要です（自分で作ればいいので）。 個人製作では要求事項は不要ですが、比較のために下記に概要を記載しておきます。 まず、要求事項書は、発注者と受注者の両方の打ち合わせによって書きます。 なおゲーム業界でも、（要求事項書ではなく）発注書ですので立場は逆の種類ですが、その発注の成果物が作中でどういう目的で使われるのかなどの意図・用途を伝えるのが良い<ref>『ゲームデザイン プロフェッショナル』、P296</ref>とされています。 ==== データ暫定値 ==== ゲーム中の、たとえばRPG武器の「攻撃力」などのデータの数値は、あらかじめ作者が、すべての項目の想定値を具体値で設計図に記述します <ref>[https://www.youtube.com/watch?v=KVdtNiB_lIQ 【ゲーム企画】 ゲーム仕様書の書き方 - YouTube] ゲームのしくみチャンネル、2015/12/11、 2020年3月14日に閲覧</ref>。 CSVファイルなどでエクセルなどで記述しておきます。 【剣データ暫定値】 銅の剣: 攻撃力 7 鉄の剣: 攻撃力 18 ハガネの剣: 攻撃力 37 ミスリルの剣: 攻撃力 70 ほのおの剣: 攻撃力 57 （※ 剣ではランク5は欠番とする） デスブリンガー: 攻撃力 150 備前長船: 攻撃力 250 聖剣エクスカリバー: 攻撃力 450 魔剣レーヴァテイン: 攻撃力 450 みたいに、暫定値でいいので、とりあえずの具体的指示も必要です。 ただし、これはあくまで暫定的な値でありますので、今後の調整で変更する可能性があります。 ==== データ仕様書 ==== データ仕様書とは、たとえばRPGなら :攻撃力: 敵の守備力との計算によってダメージを算出する のようなパラメータ計算式の定義を行った仕様書のことです<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、92ページ</ref>。 そして、この「データ仕様書」は、デバッグのための資料になります。デバッガーが、この資料と実際の動作を照合することで、仕様どおりにプログラムが動いているかを確認します<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、92ページ</ref>。 どうもアイテム（「やくそう」とか「毒消し」などのアイテム）価格などの「100」（100ゴールド）とか「200」（200ゴールド）とかの具体値のあるデータ表のことをSTUDIO SHIN 氏は「仕様書」と言っている<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、261ページ</ref>。本当は「100」になるべき数値が「200」になっている場合、「仕様書」で簡単に確認できるとSTUDIO SHIN 氏は言っている。） 一般に、RPGの仕様書は、すごく分厚くなるといわれています。（アニメ評論家の岡田斗司夫が1990年代のむかし、彼の言うには、彼の伝聞によると、ある有名RPGの仕様書は、その書類の量の表現として（ページ数ではなく）キログラム単位で表現されるくらいだと言われています。岡田さんは彼の著書『オタク学講座』などの書籍で、そういった伝聞を述べています。有名作の仕様書だと、ちょっとした電話帳みたいに分厚くて重い書類が、場合によっては何冊かあるらしいです。おそらく、データ台帳に、攻撃力などのデータだけでなく、さらに設計の背景となる要求事項などもマトメて書いた上での重量でしょう。） ;攻略本と『仕様書』 ゲームの攻略本にある、アイテムの効果値や、敵の能力値などといった数値の一覧などは、おそらく、そのゲームのデータ台帳から、転記されていると思われます。 よく、「仕様書をもとに攻略本が作られる」と言いますが、しかし攻略本の制作に必要なのは、プログラム部分の設計図などではなく、実際に入力された各データを記載したデータ台帳のハズです。 ただし、実際には市販の攻略本には、記載ミスなどもあります。 また、制作側が情報を隠していたりして、攻略本に記載された情報と、実際のゲームプログラム内の数値とが違っている場合もあります。 == 他部署との連絡の仕事をするのは誰なのか == ゲーム業界では、プランナーと言われる役職の人が、連絡網の中心になって、いろいろな部署のあいだの情報伝達をします。 <div style="font-size:120%;"> <pre> ディレクター　━━━　プランナー　━━━━┳━　プログラマ 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　グラフィッカー 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　デバッガー </pre> </div> のような感じです。（ディレクターの上に、さらにプロデューサー、プロデューサーの上には社長などがいるが、省略する。） このプランナーは、ゲーム業界の場合、中間管理職のような権限もあって、各部署（プログラマ部署やグラフィッカー部署など）とディレクター（監督みたいな役職）のあいだのやりとりもします。 :※ 一般の企業での連絡網の場合については、企業ごとの差異が大きいので、説明を省略する。 「プランナー」というと、てっきりプラン「計画」を練る仕事化のように思いがちですが、しかし、どっちかというと、計画を練るというより、たとえばテレビ業界でいう「AD」アシスタントディレクターのようなイメージのほうが近いかもしれません。 実際、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、プランナ－にはTV業界でいう「AD」のような側面があると述べています<ref>吉冨賢介『ゲームプランナー入門』、P236</ref>。 == イラスト・音楽などの外注や打ち合わせ == イラスト・音楽に限った話ではないですが、文献『ゲームデザイン プロフェッショナル』によると、発注フォーマットに業界共通のルールは存在しないので、だから開発する作品に適したフォーマットを考える必要があります<ref>『ゲームデザイン プロフェッショナル』、P.146</ref>。 また、発注の際には、発注の目的まで、発注相手には説明できることが望ましいとのことです。 何らかの発注をする際、事前にチェック項目リストを作る必要があります<ref>『ゲームデザイン プロフェッショナル』、P.159</ref>。 === 外注する場合 === 自分にイラストや音楽をつくる能力が無い場合で、イラスト素材や音楽素材の調達をしたい際、イラストレーターなどの専門家に外注することになります。 打ち合わせをする際、たとえばイラストなら、発注元の画力にもよりますが、 :構図、 :希望のポーズ、 :塗り方、 :テイスト、 などの指示が必要です<ref>『ゲームプランとデザインの教科書』、P.128</ref>。 あと、絵を書かない人が勘違いしがちなことですが、「イラストレーター」を名乗っている人は、あくまでイラストだけが専門的であるので、一般に、イラストレーターは漫画を書けません<ref>『ゲームプランとデザインの教科書』、P.128</ref>。アニメも作れません。 イラストも漫画も両方とも作れる人のほうが、希少ケースなのです<ref>『ゲームプランとデザインの教科書』、P.128</ref>。（たとえばアニメ業界のジブリの宮崎監督のような、イラストもアニメも漫画もかけるような人は、かなり例外的なケースです。） なので、イラスト、漫画、アニメ、などは、それぞれの専門家ごとに分けて注文なり依頼なりをすべきです<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 ゲーム作家によっては、キャラクターイラストの発注をするときはモデルとなるアイドルや俳優などの情報を添えて発注するゲーム作家もいます<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 :ラフ画などを用意してどんなシーンでどんなキャラのどんな構図を書いてほしいか等の大体の要望を具体的に伝える、 というのも重要ですが、もうひとつ必要になるかもしれない事として、 :なぜ、その構図が作中でどういう目的で使われるのかなどの意図・用途を伝える<ref>『ゲームデザイン プロフェッショナル』、P296</ref>、 という事が重要です。 『ゲームデザイン プロフェッショナル』によると、発注の意図・用途を伝える際も、長いと意図説明が書類の場合は書類を読んでもらえないし、口頭でも相手の頭に入らないので、だから発注者は要点を短く的確な言葉であらわさなければあらないということです<ref>『ゲームデザイン プロフェッショナル』、P295</ref>。 個々から先は別に文献の内容ではないですが、そもそもなぜ用途を伝えるのが必要かというと、相手のほうがその分野ではプロだからですし、発注元は往々にしてイラストは素人だからです。 発注元が素人の場合、プロのイラストレーターに用途を伝えると、たとえば、当初に発注元の考えていた構図などが実は不適切である、という情報が返ってくる可能性もあります。 このようなフィードバックのある場合、発注元がデザインを再検討する必要になる可能性もあります。 そもそも発注元は、あまりイラストや音楽などの分野を知らないので、だからこそ事前の打ち合わせによる、デザイン意図の確認が必要なわけです。 つまり、たとえるなら「作業指示」と考えるよりも、どこかの営業マンとの事前の打ち合わせのようなものだと考えるのがイメージ的には適切かもしれません。 たとえば住宅をリフォームする場合なども、事前に何度もリフォーム会社の営業マンとの商談をして、イメージを共有するのが普通です。イメージ的には、これに近いのかもしれません。イメージ的には、イラストレーターとか作曲家などアーティストに対する外注・発注も、こんな感じでしょう。 ;その他 書籍『ゲーム作りの発想法と企画書の作り方』によると、アダルトゲームではシナリオも外注の場合が多くあるとのことです<ref>畑大典 著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P129</ref>。 ;発注されるイラストレーター側からの視点 これはイラスト－レーター側からの視点では、発注者の要求事項に従った絵を描かなければならないわけです。 だからもし、提出しようとする絵が、まったく要求事項に従えてなければ、ダメな絵となり、発注者は納品受け取りを拒否するので、絵はリテイク（書き直し）になります。 たとえば、アニメイラスト系絵描き向けの教本『クリエイターのためのおんなのこデータベース2008 -ファッション編-』によると、 もしイラスト発注の要求事項が「セーラー服の少女を描いてください」なのに、 もしイラストレーターがブレザー服の少女を描いて提出してきたら、 どんなに可愛く上手にブレザー少女が描けてようが、リテイクです<ref>『クリエイターのためのおんなのこデータベース2008 -ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日 初版発行、P.208</ref>。 イラストレーター向けの教本などでもきちんと教育されているように、まともなイラストレーターは、こういう社会のルールがきちんと分かっています。 裏を返せば、こういう社会ルールが分かってない絵描きは、自称「イラストレーター」です。 イラストレーターにとっては当然の、社会のルールだと思いますよね。しかし世間には、イラストレーター業界に興味ない人は、この当然の社会ルールが分からない人が、少なくとも2005年より前の昔は世間に多くいました（下記コラムで説明する）。 {{コラム|絵の仕事は自由業ではない| 根本的な問題として、さすがに最近は無くなってきたと思いますが、ほんの2005～08年ぐらいまで、 世間には絵の仕事を、「自由に絵が描ける」と勘違いしている人がいました。また、「漫画や絵の仕事は、競争を気にしなくていい」という類の、良く分からない勘違いもありました。 どうやら、勘違いの原因は、小学校の図工のお絵かきや、中学校・高校の美術の授業が、そういうなるべく自由なテーマで絵を描かせるので、どうもイラスト関係の仕事までそうかと勘違いをする人が、ほんの2008年くらいまで昔は少なからず居たのです。 さんざんマンガ評論やアニメ評論などで「漫画の打ち切り」だとか「アニメの放映打ち切り」とか言われても、あるいは評論誌など読まなくても友人どうしの雑談でそういう話をしても、しかしその「打ち切り」情報が脳内にある勘違い「小学校の図工のような自由な仕事 <nowiki>=</nowiki> プロ絵描き」という勘違いの修正に結びつかないようです。 だから漫画家の江川達也は苦言として、雑誌コラム（おそらく『SPA』）で2001～2005年ごろの意見ですが、当時のゆとり教育の賛成論者がなんだか漫画業界について「漫画家は、競争が無くて自由に漫画を描ける仕事」だと勘違いしているような言説が散見されたことに対し、江川は苦言でおおむね「漫画家はとても競争の厳しい世界だ。ふざけたことを言うな」といったような感じの批判を雑誌コラムで述べていました。 漫画家はプロデビューするまでだって競争がありますし、デビューしてからも不人気だったら打ち切りですし、競争はとても厳しいです。 漫画に限らず、どうも世間にはイラストレーターや漫画家を、なぜか競争のない業界だと勘違いしている人が好くなからずいます。昭和の時代は、漫画家を終身雇用だと勘違いしている人もいました。 昭和時代にデビューした漫画家の小林よしのりは、自身が漫画家プロデビューするまでは、勘違いで、「マンガ出版社は、漫画家が死ぬまで面倒を見てくれる、まるで公務員のような終身雇用の業界が漫画業界」だと思っていたと、著書『ゴーマニズム宣言』で自身の勘違いを白状しています。 それでも昭和の時代なら、まだ漫画業界がよく知られていなかったので、世間一般の終身雇用の常識に照らし合わせて勘違いしてしまうのも、無理ありません。ですが、平成が10年以上も過ぎた2001年以降にこの手の勘違いをしている人もおり、もう手の施しようのない人です。 }} === 絵の「クオリティ」とは === 何かのゲームデザイン本によると、「クオリティ」とは、イラスト発注などの言葉のようです。 その書籍では「クオリティ」の意味は説明していないのですが、ゲーム業界で言うクオリティと一般の英語のqualityは少々、意味が異なります。 ゲーム業界には、イラストや音楽などに対して「クオリティ」という言葉があります。英語ではqualityは「品質」という意味ですが、しかし日本のゲーム業界でいう「クオリティ」にもその意味はあるもののニュアンスはやや違います。 たとえばイラストの例なら、どんなに「ポーズと構図はこうしてください」とか「メインカラーはこうしてください」とかの発注要件を守ってイラストレーターが絵を描いて提出しても、しかしその絵の画風がターゲット層の消費者たちの好みの画風でなければ、ゲームが売れずにゲーム会社は商売になりません。 少なくとも2010年以降、ゲームファンの絵柄の好みは、素人では描けないような細密かつCG特有のグラデーションなどを活用した絵柄が消費者層の好みです。そういう求められた画風である細かい絵である素材を出せる能力のことも「絵のうまさ」と捉えて、ゲーム業界では「クオリティ」と呼んでいるようです。 逆に言うと、たとえばマンガ家の手塚治虫『鉄腕アトム』の原作のような簡素な絵でどんなに上手い絵をゲーム発注者に提出しても、おそらく「クオリティが高い」とは言われないでしょう。 絵の場合、昨今の消費者の好みが、細かく線を描きこまれたりグラデーションなどCG機能を多く使ったアニメ風イラストまたは細かいリアルCG風イラストといった絵柄なので、そういう絵がゲーム業界では「クオリティが高い」のように言われたりもします。 ;業界によって要求される画風が異なる ゲーム業界の絵を描く能力は、マンガ業界やアニメ業界で求められる能力とは異なります。 マンガ業界の場合、まず白黒印刷で表現できる絵柄でないといけませんし、印刷の解像度の問題もあるので、カラー表現は求められない場合も多いし、またグラデーションも利用が困難です。だからマンガ業界ではグラデーションではなく、スクリーントーンを使います。そもそも製作ソフトウェアからして、イラスト製作用ソフトではなく専用のマンガ製作用ソフト（『コミックスタジオ』など）を使ってマンガが描かれています。週刊マンガと月刊マンガでも、絵柄の傾向が違っています。試しに線画部分だけでいいので漫画を模写などをしてみれば分かると思いますが、週刊漫画の絵柄は比較的に短時間で模写できるような線の少ない絵柄になっている場合が多いえす。 アニメ業界の場合、動画マンが動画を何枚も描かないといけないので、原画ではなるべく1枚あたりの線を減らす必要があります。1枚イラストでは「撮影」と言ってCG処理などで光の表現などのためにフィルタ加工などもしますが、しかしゲーム業界と比較するとアニメ業界の手書きアニメ用イラストのCG処理は簡素な処理です。 ゲーム業界とアニメ業界では、人気の絵柄におけるCG加工の傾向が逆のことも多く、だからアニメ業界のような多くの人が真似して描けるようにデザインされた絵柄は、ゲーム消費者にはウケていません。 世間では美少女キャラの瞳が大きいだけで「アニメ絵」とか言いますが、しかし実際には瞳の大きい美少女キャラでも、アニメ業界とゲーム業界とマンガ業界とでは、求められているデザインがまったく違うのです。 アニメ業界とゲーム業界とで「原画」や「仕上げ」など共通の用語が使われる場合もありますが、内実、意味は違っています。 もっとも、近年ではアニメ業界もゲーム業界やライトノベル業界（雑誌媒体なら月刊誌である場合が多い）などの影響を受けて、細かい絵が増えてきました。アニメの原作がゲームやライトノベル作品である場合も多いので、そういう作品は当然、細かい絵が求められるわけです。 なお、アニメ業界の場合、細かい絵を描くことはクオリティとは呼ばずに「カロリー」と呼ぶことが多いです。どうやら栄養の「カロリー」由来の表現らしく、作画に求められる手間や負担というような感じらしいです。「作画カロリー」などといった表現もアニメ業界にあります。 細かい絵や、細かい動き、やたらと凝った動きや構図などを描く際、「この絵はカロリーが高い」のように表現するようです。 「クオリティ」という言葉を聴いているとあたかも「業界を越えて共通の絵のうまさがある」とでも錯覚するかもしれませんが、しかし上述のように要求される絵柄や画力は、業界ごとに違います。 ;週間マンガ・アニメの後日修正 なお、実は週間漫画は、雑誌掲載時の絵柄と、単行本掲載時とで、絵柄が微妙に違う場合があります。雑誌掲載時だと、週間ペースの掲載に追いつかせるために、省略できそうな背景などの書き込みを減らしている場合もあります。なので、実はそういう省略された部分を、単行本化に向けて後で、アシスタントや、専門の会社などが、細部を仕上げているわけです。 単行本の話ではないのですが、2012年ぐらいにBSあたりで放映されたマンガ業界特集番組では、実はマンガのアシスタント専門の会社が存在することを紹介しています。細かな統計は忘れましたが、その番組によると、現代（ただし放映当時の2012年頃）の漫画家の多くは、実は連載作家ではなくアシスタントとのことです。今のマンガ産業は、実は分業制なのです（なおアニメ産業は昭和後期～平成初期からとっくに分業制）。 アニメも、実はテレビ放映時とブルーレイ・DVDなどの円盤メディアとで、絵柄が少しだけ微妙に違う場合などがあります。放映後に細部を直すのです。 === マンガ・アニメ業界での「芸術」･「自由」の裏の意味 === 文献『ゲームプランナー集中講座』によれば、ゲーム作りに必要な資質としては、作家性<ref>『ゲームプランナー集中講座』、P246</ref>のほかにも「人を楽しませたいと思う気持ち」<ref>『ゲームプランナー集中講座』、P246</ref>が必要です。 また、同文献によれば、ゲーム会社では自己表現は求められていません<ref>『ゲームプランナー集中講座』、P246</ref>。もし本当に自己表現をした人は、ゲーム会社ではなく１人で芸術家を志望するべきだと文献『ゲームプランナー集中講座』では述べています<ref>『ゲームプランナー集中講座』、P246</ref>。 作家性は必要ですが<ref>『ゲームプランナー集中講座』、P246</ref>、しかし自己表現は求められていないという、バランス感覚が問われます。 ゲーム業界への就職では自分の作品があるとアピールポイントになり多くのゲームプランナー入門書でもプロトタイプなどの作品づくりを推奨していますが、しかし自己表現は求められていないことに注意する必要があります。 さて、ゲーム会社だけでなくイラスト業界やマンガ業界も、似たような見解です。 『クリエイターのためのおんなのこデータベース2008 -ファッション編-』によると依頼内容を無視して自由に絵を描こうとする人は、けっして「プロ」ではなく、それは「芸術家」だとのことです<ref>『クリエイターのためのおんなのこデータベース2008 -ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日 初版発行、P.198</ref>。 ==== 「芸術」 ==== 「芸術」といえば、漫画『サルでも描けるまんが教室』では、漫画家志望者が芸術かぶれになることを、とても戒めています。 {{コラム|サル漫の芸術かぶれ回| サル漫の芸術かぶれ回では、作中の漫画家コンビのシナリオ担当の竹熊と作画担当の相原が、漫画の執筆中に、 芸術かぶれを煩った作画担当キャラの相原コージが、まず、おおむね「俺たちはこんなくだらない漫画を描いてていいのだろうか」みたいなことをつぶやきます。 それに対して竹熊が心配したか「どうした相原？」とたずねると、 相原の細かなセイルフは忘れましたが、相原は「俺たちはもっと本質的な作品を作るべきではないか？」とか 「資本主義などという下らない次元にとらわれてはいけないのではないか」とか、 「俺たちは国や大企業におどらされていてはいけない」とか、 なんかそんな感じのことを言います。 すると、竹熊はまず相原をぶん殴ったあと、 竹熊は「お前は芸術をぜんぜん分かっちゃいない！」と説教し、 相原が「そんなことない」というと、 竹熊が「じゃあ、お前のいう芸術とは何かと言ってみろ？」と問い詰めると、 相原が「それは、人間の内面の真実ってゆうか」とつぶやくと 竹熊はめっちゃあきれたような見下したような表情で、「にんげんのぉー、ないめんのしんじつぅ～」みたいにつぶやき返します。 そしてそのあと、竹熊はおおむね、 「お前は権威にとらわれてはいけないとはいうが、じゃあお前のその意見は、どこかの芸術大学の教授の権威にすがっているだけではないか！？」とか :「お前こそ、政府や商業メデイアによる宣伝のつくった権威にとらわれているだけじゃないか」とか、 :「お前は芸術教授の権威にあやかって自分も地位と名誉が欲しいだけだし、結局、お前はカネが欲しいだけなのだ。」 なんかそんな感じのツッコミをします。 このあとも竹熊のツッコミは続きますが、続きを知りたい方はサル漫を購入してください（ネタバレになるので続きは省略）。 ともかく、マンガ業界やアニメ業界でいう『芸術』には、こういう隠れた意味があります。 アニメ『新世紀エヴァンゲリオン』の総監督の人はサル漫の大ファンですし、総監督は竹熊とも対談したことあるので、つまりアニメ業界でも自称「芸術家」はまあ似たような扱いです。 }} ==== 「私小説」 ==== {{コラム|売り上げと文化は違う| 文学史でいう「私小説」と、マンガ・アニメ業界でいう「私小説」とは、意味が異なります。 現代でもアニメ評論などでは、「私小説」というのを否定的な意味で、「頭でっかちのインテリが書いた、世の中に文句を言ってるだけのことを、さも深い洞察かのように装うとしてるだけの、売れない小説」のような意味で使っていたり、あるいは「世間知らずの漫画家やアニメ監督の書いた、世の中に文句を言ってるだけの（以下略）マンガやアニメ作品の脚本みたいなもの」のような意味で使われることもあります。 たとえば1998年の岡田斗司夫の対談集『マジメな話』でも、当時のエヴァンゲリオンの映画版を「私小説」だと対談相手の推理小説家・今野敏（こんの びん）が批判していたりしました。「クリエイターよ、メッセージはあるか」というタイトルの対談です。 なお、名前の漢字が似ているアニメーター・今敏（こん さとし）とは全くの別人ですので、混同しないように。そもそも今敏はエヴァンゲリオンの制作スタッフの一員です。アニメーター・今敏は、全く、岡田とは対談'''していない'''です。 さて、文学史でも、売上と、後世に語られる作品が異なることはあり、たとえば大正文学の売上のベストセラーは、 :倉田百三『出家とその弟子』、 :島田清次郎『地上』、 :賀川豊彦『死線を越えて』、 が大正時代の三大ベストセラーですが、しかし今や彼らは文学史の教科書には、滅多にのりません。せいぜい高校日本史の教科書で、倉田が少し紹介されているくらいです。 現代の教科書でよく大正時代の小説家として紹介される芥川龍之介は、じつは当時は倉田・島田らほどには売れてない作家です。また、「私小説」といわれるジャンルは実は売れていません。（もっとも、芥川が私小説を書き出したのは晩年のこと。このコラムでは、芥川の伝記については立ち入らない。） 食い違いの原因は、芥川が小説連載していた大阪毎日新聞による芥川をブランド化するイメージ戦略の成功や、あるいは第二次大戦後になって教育界隈の左翼運動家たちが文学史を左翼イデオロギーに都合よく書き替えたことなどが考えられますが、しかし新聞社や左翼ごときに書き換えられるぐらいに戦前の文学史が研究不足であったことが、そもそもの根本原因でしょうか。 ともかく、「私小説」というジャンルは、そもそも大正時代の当時は、大して売れていません。 }} === ローポリ関連の作画 === 単元『[[ゲームプログラミング/3Dグラフィック#ローポリ制作手法的なこと]]』で説明した。 == レポートは結論だけを読んでも分かるように書く == レポートなどは、ゲーム業界なら、途中を読み飛ばしても、内容がおおまかに分かるように書かなければなりません。 別に冒頭で結論を述べる必要はありませんが（会社による）、しかし、仮に書類のページの順序どおりに上司が読まなくても、 レポート全体の内容を把握できるように書かなければならないでしょう。 == 中卒でも分かるように書類を書く == ゲームに限らないのですが、企業でレポートなど種類を新人などに書かせると、時々、教科書などを丸写しするような人がいます。しかし、そういう丸写しは、多くの企業で、一般的な企業では不要です。コードの解説というより、企業で何かの解説レポートを書く際の基本ですが。 書籍『ゲームデザイン プロフェッショナル』によると、ゲーム開発で必要なチーム内での言葉選びについては、「中学生の知識でも理解できる言葉を使うこと」とあります。そのほか、言いやすいフレーズを使うことも必要です<ref>『ゲームデザイン プロフェッショナル』、P101</ref>。 ぶっちゃけ、このwikiのこの科目の教科書のようなのは、中学生レベルの知識で読解できないので、ダメでしょう。読者は、このwikiを反面教師にしてください。 書籍『ゲームデザイン プロフェッショナル』は特に述べてはいませんが、企業というのは、従業員の過去の学歴や経歴がバラバラなのです。普通科高校を卒業して就職する人もいれば、業界に近い専門学校に入った人もいますし、商業高校や工業高校などに進学していた人もいますし、大卒や院卒もいます。 日本では高校進学率が100%ですが、しかし高校は選択科目などが多いので、共通知識はどの選択科目を選んだかで差異が多いので、なかなか高校を基準に合わせるのは難しい業種も多いのです（ただし、製造業なら工業高校卒のように、一部の業界では学校の種類を絞って基準にすることがある）。 なので、一般の多くの企業では、従業員がどういった学歴でも情報伝達が上手く行くように、中学レベルでも分かるような物言いが、企業では原則必要になります。大卒社員であっても、そういうふうに言い回しを直すトレーニングをしたりします。 == 脚注・参考文献 == 80uxs8n3bh2fwczxmn7jsewtxepulp1 206120 206119 2022-08-01T11:22:08Z Honooo 14373 /*作成工程*/ 節タイトルのみ変更 wikitext text/x-wiki {{substub}}このページの主要執筆者は、ゲーム業界経験者ではないので（2022/1時点）、ここの記述は調べ物としては役立ちません。 2022/1時点でゲームプログラミングと直接の関係ない話題が長い、という問題があるので、より簡潔、かつ分かり易い記事への編集にご協力いただけたら幸いです。もっとも現編集者Hは、解ってるならそれを書いた奴が書き直せ、そもそも余計なことは最初から書くな、…とは思いますが…。 このページは、教科書としてゲームプログラミングの方針を説明する際に、どうしても書類についての説明が必要だから記述されています。現状では、一般IT業界や製造業などの設計図を参考に説明がなされています。 == 本書の目的 == 本書は、ゲームデザイナーのための教科書ではありません。 メインページ、「[[ゲームプログラミング]]」の題名どおり、プログラマーのための教科書です。プログラマーがゲーム制作に興味をもって実際に作り始める際に、調べ物の手間を減らすために書かれた参考書籍です。 ゲームデザインに関する解説を望む方は、別途、他の参考資料に当たってみてください。 ==「仕様書」== ここでいう「仕様書」とは、ゲームの設計図のことです<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.126</ref>。しかも職業的に集団でゲームを作るときの書類です。 ではまず、「設計図」とは何か、について、考えていきましょう。これは普通科高校では学習しない事項です。 ゲーム業界では、「仕様書」を含む書類群の「発注書」には、決められたルールや書式はありません。だから作るゲーム内容や製作チームごとに、適切な発注書のありかたを毎回考える事になります<ref>『ゲームデザイン プロフェッショナル』、P.145</ref>。 職業的なゲーム開発では、一般に :発注 → 実装 → 調整 というプロセスを経て<ref>『ゲームデザイン プロフェッショナル』、P.61</ref>、最終的にとりあえずの完成になります。 ゲーム産業での「仕様書」は、発注の段階での書類です。 ==集団ゲーム制作での解説文== 発売禁止になってしまった書籍（おそらく。しかし何故？）『国際おたく大学―1998年 最前線からの研究報告』（岡田斗司夫ほか、光文社）に書いてあった事例なのですが、G.O.D.と言うイマジニア社のRPGゲームに対する大学生（岡田は当時、大学講師だった）の取材があって、そのGODの開発に参加した劇作家の鴻上尚史（こうかみ しょうじ）氏と、エニックスの堀井雄二（ほりい ゆうじ）氏とが、対談した経緯が、紹介されていました。 劇作家の鴻上は、ゲームに演劇のリアリティを入れようとして、スタッフに「間（ま）を意識したシナリオを書いてほしい」と要求したが、うまく行かずに難航したと体験談を述べています。 対談相手の堀井は、鴻上のその体験談に対し「『（※ここで3秒休止）』とか書くと良いですよ」と、指示書で具体的に書くと良い、とアドバイスした、と、岡田の書籍にある大学生のレポートにあります。 おそらくドラゴンクエストのゲーム開発でも、このように具体的な指定を必要に応じて出していた・いるものと思われます。 21世紀現代の、商業ゲームの現場でも同様であり、書籍『ゲームデザイン プロフェッショナル』にもありますが（※かぎカッコ内が引用）、「もっとかっこよく調整してほしい」という問題であれば、たとえば「もっと目立たせたいので、アニメーションのシルエットを全体的に今より少しだけ大きくしてほしい」<ref>『ゲームデザイン プロフェッショナル』、P296</ref>という具体的な指定が妥当でしょう。 == 集団作業に必要な書類 == ===設計図=== IT業界やゲーム業界では、集団作業で制作開始をしようとする際、まず、いきなり設計図を作るのではなく、まず先に試作品（しさくひん、英語で「プロトタイプ」proto-type）のプログラムを作り、企画で考えた各種システムなどのアイデアが有効かどうかを検証します。 そのプロトタイプで、企画のアイデアが本当に有効であるかを確認してから、もし有効だったら、本格的な制作を開始します。 もしかしたら会社によっては、企画会議（もしくは企画の打ち合わせ）よりも先にプロトタイプを作るかもしれません。 さて、会社へのプロトタイプ提出で、制作続行・制作本格化の賛同が会社から得られたとしましょう。 IT業界でも製造業でも、どこの業界でも集団作業で、制作の合意を作るさい、必要な書類は、おおむね、 :作業者用の具体的な「完成予想図」 です。 しかしゲーム業界の場合、いきなり完成予想図に相当する「仕様書」は書けないので、書籍『ゲームデザインプロフェッショナル』によるとまずゲーム中の大まかな実装予定事項を記述した『企画概要書』という書類を作成することもあると言われています<ref>『ゲームデザインプロフェッショナル』、P139</ref>。ただしこの「企画概要書」は、名前に「企画」とはついているものの、どちらかというと仕様書の方針を大まかに打ち合わせするための書類に近いので、いわゆる「企画書」とは異なります。 なお、一般のIT企業でよく書かれる「要求事項書」は、ゲーム書籍では紹介されていないので、おそらくゲーム業界では書かないのが普通だと思われます。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） ===ゲーム業界での技術職=== 言葉というのは同じ国の国語でも、その業種や職場、社会集団で、微妙に違った使われ方をすることも多く、技術職、という言葉もゲーム業界での特別な使い方があるようですね。 この業界では、グラフィックデザイナ－やサウンドクリエイターやプログラマーが「技術職」<ref>『ゲームプランとデザインの教科書』、P125</ref>。技術職 = ￢(not)企画職、という事で、プロデュ－サーやプランナーやディレクターなどの「企画職」でない製作スタッフが技術職です。 ただ現編集者はプロデューサーとディレクターは対立する職種だというイメージはありますね。プロデューサーは企画職だろうけど、ディレクターは、"実"制作職ではないかな？ ===企画書=== *PREP法 基本的にビジネス上の書類は、結論を一番先に書く構成法が望ましいですね。もちろん商業ゲーム制作の現場でもそうでしょう。文献『ゲームプランナー入門』では、具体例として、PREP法を紹介しています。 PREP法とは、 :Point（結論）→Reason（理由）→Example（具体例）→Point（結論）。 ほかにもホールパート法やSDS法などがありますが、どれも冒頭で結論を示した後詳細を伝える方法で、ビジネス文書はやはり、その形式が常道でしょう<ref>『ゲームプランナー入門』、P141</ref>。 しかしこの社会、ビジネスが重要なのは事実だが結局、他者の行為や仕事をただ自分の欲望と利益に使い、他者の存在や詳細に興味のない人間は、とにかく結論だけを先に聞きたがるし、それ以外の事には事実上何の興味も持っていないでしょう。 *ゲームのルール 常識的な判断としては、ゲームにはルールがあるものですよね。ルールのないゲームというのは、ふつうあまり考えつかないし、イメージできない。 ですからゲーム企画書としては、ルールの説明が必要になる。キャラクター設定や世界観の解説があったとして、ルール説明がない企画書はふつう受け入れられない<ref>『ゲームプランとデザインの教科書』、P83</ref>。 ただ今ではゲームジャンルの固定化が進んでいるので、ルールはくどくど説明する必要はない、という場合はある。 企画書を誰が書くかという問題もある。業界の内部の重要人物か、全く外部の業界経験の無い人物か。 どちらににろ常識判断としては、ある程度のゲームルールの解説は必要だろう。 *プレイ人数 企画書には、ゲームのプレイ人数の記述も必要<ref>『ゲームプランナー入門』、P159</ref>。 ほんとの昔は、一人か二人でプレイするのがコンピューターゲームだったのですが、もはや時代は変わりましたね。インターネットを駆使して多人数プレイ、ソーシャルゲームなんてものも出てきました。 <!--(:※ ここから先、セクション末尾まで文章の編集者が異なります。編集者Hによる文章です。なお出典のある部分は編集者Hではなく別の編集者Sによるものです。)←すじ肉先輩さー、この記述は無いわ^^;;。だってこれって、みなさーん、以下の馬鹿文はHが書いたんだからね、俺、Sujの文じゃあないよ、馬鹿なのはHであって、俺じゃあないから。Sujはちゃんと出典は全部書いてんだよ^^、って言ってるのと同じだよね^^;;;;;--> さて、企画書に関しては、よくない企画の典型例というのはあるようですね。特に特定人物のネームバリューに依存した企画は良くないし、批判の対象になることも多いようです。ゲームとしては、イラストレーターや声優に超大物を起用することを強調した企画書ですね。 出典として『テリー伊藤のお笑い大蔵省極秘情報』あたり、確実に特定はできませんが、木村拓也のタレント性に頼った企画は、著者のテリー伊藤によってよくない企画の例として指摘されていたようです。 もっともテリー伊藤という人物自身が、ビートたけしの面白さ、彼を起用したことの良さによって世に出て知られるようになった人物なので、そんな事言っていいのかね、などと現編集者は少し思いますが…。 また今回の本題、ゲーム業界でもそういう良くない企画書が提出されることは多いようです。元ゲーム業界人でゲーム評論家の あべひろき が、90年代の著書で、過去にゲーム関連会社に勤務してたときの体験談を書いています。企画書の精査をしているときに、「人気声優の○○さん起用！」と書かれていたものがあったが、あべ氏がその声優の所属する声優事務所に確認の電話をとると、なんの商談も声優とも事務所ともされていなかったという事です。 もっとも企画書とは企画に過ぎないのではないだろうか？これらの他人のネームバリューに頼った企画が良くないのは事実だが、企画が通って実現する見込みが決定する以前は、むしろ声優本人や事務所にアクセスすることはないのが普通だろう。 もちろん企画者がその事務者や声優と懇意にしてる場合は、あらかじめ話をする可能性はあるが、しかし企画段階ではそもそも現実のビジネスになる可能性はそれほど高くない。声優や事務所にとってもその段階でもっともらしく話をされても、むしろ困惑するだけではないだろうか？ ただこういう他人任せの企画は、「プロデューサー的企画」と呼ばれるようです<ref>吉冨賢介『ゲームプランナー入門』、P71</ref>。クリエイティブな企画とは言えないわけですが、しかし商業的な娯楽作品には、クリエイターだけではなく、プロデューサーも絶対必要でしょう。 一般に企画でも他の仕事でも、他者の力や権威、その後の作業などに頼り切った態度は、どんな場所でも嫌われて批判されますし、それは職業の場だけではないでしょう。 また、ゲームの企画に関してもう一つの話題として、アメリカでも売ることに成功したドンキーコングの、ディレクターの宮本茂（任天堂）は、「人間の生理的なところを体感できるゲームを作れば、それがユニバーサル」、だと、語っていたようです<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P89</ref>。 ===「仕様書」、「企画書」=== 商業的なゲーム制作では、一般に、 発注 → 実装 → 調整 の過程を辿ります。 そして発注段階で重要な書類は、「企画書」と「仕様書」の二つです。まず『企画書』で作るゲームのコンセプトを固めてから、あとで『仕様書』で、より詳細に内容をを決める、という順序をとります<ref>『ゲームプランとデザインの教科書』、P43およびP45</ref>。 企画書<ref name="gcs72">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、72ページ</ref>は社内だけでなく協力会社にも見せる資料であり、開発者・協力者に対して手短かに、そのゲームの全体的なコンセプトを伝えるためのものです。 仕様書は、ゲーム制作では「設計図」であり、「完成予想図」であるといっていいでしょう。企画書よりより詳細にゲームの内容を決め、指定しています。 さて、話を進める前に、商業的に集団でゲームを作る場合の他の書類や必要事項の名称について、ここで簡単に書いておきます。 まず「発注書」とは，発注時に作られる、必要な書類群のことでしょう。「企画書」と「仕様書」も含みます。 「指示書」はむしろ、実装や調整段階でなされる、具体的なゲーム演出上の指定でしょうね。 試作品（しさくひん、英語で「プロトタイプ」proto-type）や企画会議（もしくは企画の打ち合わせ）なんて言葉も出てきますが、こういうのはあえてクドクド説明しなくても、直感的にイメージわきますよね。 『企画概要書』とは企画書とは異なるもので、仕様書に準ずる書類で、仕様書の方針を大まかに打ち合わせするためゲーム中の大まかな実装予定事項を記述している書類です。 『原案書』<ref name="gcs72" />は社内だけで企画がペイするかどうかの検討を決算書などを参考に分析・会議するための書類です。 こういう書類や用語に関する言葉の使い方は、商業的集団的なゲーム制作の場として妥当と思われるものをまとめてみましたが、もちろん職場によって、会社によって使い方や意味が微妙に変わってくる場合はあるでしょう。 さらにゲーム以外の一般IT業界や製造業でもそれぞれの慣習があり、今回の説明が成り立たない、そしてそこはより一般的な職場ですから、それぞれより一般的な言葉の使い方があると思います。 さて、コンセプトの具体例として、書籍『ゲームプランとデザインの教科書』によると、たとえば『ポケットモンスター』のメインのコンセプトは、「通信ケーブルを伝わって、ポケモンが入ったカプセルが移動して交換する」、が始まりだそうです<ref>『ゲームプランとデザインの教科書』、P109</ref>。 また、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、『メタルギア』シリーズのコンセプトは、「敵に見つからないように進む」、とのことですね<ref>吉冨賢介『ゲームプランナー入門』、P108</ref>。 イラストや音楽の発注は、一般的には企画が決まった後でしょう。 そもそもイラストレーションや音楽を対価を払って提供してもらったとして、それを実作品に使用しないのは、作者にとっては不本意なことだと思います。 アニメーターの故大塚康生氏は、アニメーション演出家が安易にアニメーターに大量の絵を描かせ、そこからいいもの、利用できるものだけ取捨選択する方法を批判していましたし、一般的に手仕事には作者の思い入れがありますから、安易な大量生産品と同じ取り扱いはできないと思います。 もっとも一方で、あるアメリカの日本人アニメーターが、同僚の日本人アニメーターが、自分の描いたものを日本の家族や友人たちが見ることができないことを不満に思っていた、という事を批判的に語っていたのを、現編集者は聞いたことがあります。 しかしゲームの場合、例外的にイラストや音楽が先行する場合はありますね。 RPG『クロノトリガー』は、企画の当初からイラストレーターをつとめた漫画家・鳥山明のイラストがあって、それをもとに作品を作ったと、鳥山のマンガの編集者であった元・少年ジャンプ編集の鳥嶋和彦は述べています。<ref name="tskdq">[https://news.denfaminicogamer.jp/projectbook/torishima/2]</ref>決めシーンなどのキービジュアルを先に決め、それに合うように設定を練りこんでいくという方式で、クロノは作られたようです。 企画書の制作ツールとしては、清書としては、オフィスソフトの「PowerPoint」と、アドビの「Illustrator」、または、アドビのソフトウェアは高価なので代わりにフリーソフトの「Inkscape」および「GIMP」がよく使われます<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日第1版第1刷、P.281</ref>。なお、Illustrator および Inkscape は、ベクトル画像を描画するソフトウェアです。 ただし、下書きなどでは、タッチペンと何らかの画像ソフト、またはタッチペン用メモソフトで下書きすることもあります。 業界で、ゲームプランナーと呼ばれる職種は、仕様書作成や進捗管理、テスト&デバッグ、スタッフとのコミュニケーション、などが仕事ですね<ref>『ゲームプランとデザインの教科書』、P.9</ref>。 また、ゲーム制作に関して、だれもが様々なアイディアを持っていると思いますが、メモを取って、もし忘れてもメモで思い出せるようにするといいですね<ref>『ゲームプランとデザインの教科書』、P.20</ref>。 アマチュアの企画なら、実際にプロトタイプ（プレイできる試作品のこと）を作って実作品で企画、仕様を説明してしまったほうが早いかもしれません。 参考文献『ゲームプランとデザインの教科書』でも、（試作品を）「ゲームプランナーを志す中で企画書や仕様書を書きながら、ぜひ自分でも作ってみましょう。プログラムや3Dモデルを簡単なものでいいので作ってゲームに仕上げてみましょう。」と述べています<ref>『ゲームプランとデザインの教科書』、P.3</ref>。 上記の本の図表によると、企画書では、「競合情報」、「世界観」、「ストーリー」なども記述して欲しいようです<ref>『ゲームプランとデザインの教科書』、P.43 </ref>。世界観とストーリーが分けられているのです。 物語とその舞台ですね。我々自身もこの世界で自分という役を演じている役者ですよね^^ {{コラム|ゲームの企画書とアニメーションの企画書| 商業アニメーションの世界では、企画の段階でストーリーの概要が決まっているようです。ただこれは、アニメーション作品の企画として、当然に必要とされる要素であるから記述されているわけで、実制作の過程で、実際のスタッフの意向により大幅に変更されることもあります。また、これらの企画では、キャラクター設定やキャラクターイラストのデザインも当然必要であり、かなり明確な形で提出されています。 たとえば、アニメ業界の企画書ですが、1990年代のアニメ『新世紀エヴァンゲリオン』の企画書の掲載されている『新世紀エヴァンゲリオン (ニュータイプ100%コレクション) 』（1997年2月28日初版発行、85～88ページ）を読むと、『企書画』の段階でもう、キャラクターイラストが主役だけでなくその友人や周囲の大人なども含めて、ほとんどのキャラクターでイラスト紹介されており、さらに全部の話数ぶんの粗筋と見せ場・意図を2～3行ていどで説明しています（ただし第1話と最終3話（24～26話）のみ説明が5行以上くらいと長い）。 因みに現編集者は実際にアニメーション業界で企画書を書いたことがありますが、その時に上司、制作会社の重役に指摘されたのは、1クール（3か月）か2クール分の実際のストーリーの具体内容を書いてほしい、との事でした。 一方ゲーム業界では、そういうキャラクター設定やストーリーは、企画段階では決まっていなくて、もし書かれていても邪魔だと感じられるようです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、149ページ</ref>。 業界の企画書で、強調してほしい内容とは、ゲームシステムと、そうシステムを設計した根拠のようです。なぜなら、ゲームの企画書でいう「コンセプトが重要」、と言う際の「コンセプト」の意味とは、ゲームシステムやゲームルールを設計した根拠のことだからです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、108ページあたり</ref>。 とはいえ、ゲーム業界の企画書でも、ゲームの世界観が「中世西洋ファンタジー風」なのか、「現代日本」か、「近未来SF風」なのか、などの設定はある様です。ネット上で公開されている商業ゲ－ム企画書からその様子が分かりますが、しかし、最初の企画書の段階で決まってる世界観はその程度まで、です。 背景としては、ビジネスモデルが根本的にアニメーション業界とゲーム業界とでは違う、という事情があるのでしょう。 }} {{コラム|キャラクター重視の物語論| アニメ―ション業界のビジネスモデルは、キャラクタービジネスだと言われています。1990年代の徳間書店のアニメーションに関する書籍（アニメージュ10周年記念）で、徳間の編集者が1980年代のアニメ業界を振り返ると、これはキャラクタービジネスだろうと、たとえば銀河鉄道999のアニメ―ションの人気も、メーテルなどのキャラクターの人気なのだという分析があり、アニメージュ創刊当時の『銀河鉄道999』特集では、ストーリー解説ではなく、キャラクターに焦点を当てた記事を組んだと、述懐（じゅっかい）しています。 また、漫画産業もキャラクター重視のようです。主人公に共感させるための様々な演出が凝らされている。そして主人公が身近に感じられることが重要だと指摘されています<ref name="tskdq" />。 これは日本人が物語軽視というよりは、海外でも同様であり、むしろ物語とはキャラクターを描くという要素が非常に大きいという事でしょう。多くのミステリの中でも「シャーロック・ホームズ」や「007」の人気が非常に高いのも、キャラクター性と結びついた作品だからでしょうね<ref name="tskdq" />。 1982年頃『鳥山明のヘタッピマンガ研究所』では、おおむね「マンガとは人間を描くことだ」という主張がなされています。 現編集者の記憶では、漫画がキャラクターだという主張を強くしたのは、漫画原作者であり、劇画村塾の開設者である、故[[w:小池一夫|小池一夫]]氏でしょう。上述の書籍の共著者、さくまあきら氏も、劇画村塾出身ですから、さもありなんということですね。 アニメ評論家の岡田斗司夫氏は、対談集『マジメな話』で、「古代ギリシア人や古代ローマ人はとても論理的で学問も発達していたが、一方でギリシア神話やギリシア悲劇が普及していた、人間には物語が必要なのだろう、自分達の社会の仕組みを、物語になぞらえて理解する、物語が学問や科学に匹敵する」といったことを述べていました。 ギリシア神話では実に人間的な神々の物語が語られていきます。 また、政治学者小室直樹氏は、別の書籍、おそらく、『日本人のための宗教原論』あたりで、「幼少期の子供にとっての、父親の力強さと畏怖のイメージ」こそが神のイメージだろうと述べています。ギリシア神話の最高神ゼウスは、明らかに父性を示していますよね。 これはユダヤ教やキリスト教の神のイメージだと考えてもいいと思います。この辺[[w:父なる神]]あたりに面白い記述がありますし、一方でイスラム教は神に父性を見出さない、などの興味深い分析も書かれています。 また、RPGゲーム『真・女神転生』では、裏設定ですが、作中の「悪魔」とは、力の象徴であり、それは父親を暗喩しているというコンセプトがあります（たしか公式ファンブック『CLUB邪教の館』あたりに記載がある）。だからこのゲームの主人公は、父親がいない母子家庭の子供だという事になっています。 }} {{コラム|ゲームにおけるキャラクター| ゲームの世界は、ソーシャルゲームや美少女ゲーム等はありますが、一般的にはキャラクター重視のメディアではないようです。シューティングゲーム『ゼビウス』のキャラクター性とか、『平安京エイリアン』のキャラクター性など、想像力を最大限に駆使すれば見出せないことはないですが、常識的にはキャラクターの魅力は提供されてはいないでしょう。 ゲーム学という概念を推進している人達は、ナラティブ（「叙述」という意味）といって、スーパーマリオなどのように作中にストーリー説明文が無いゲームのことを説明しているようです。 今現在では、可愛いキャラクターや恰好いいキャラクターを作品に取り込めるのなら、それを除外する必要はないでしょう。しかし現実の人気ゲームでは、キャラクター性があいまい、あるいはほとんど見出せないゲームも多いですよね。 ゲームのキャラクターは、開発途上で変更される可能性もある。海外展開しているゲームは、相手国の風習、社会状況に合わせて、キャラクター設定を変える場合もある。 今現在は、ソーシャルゲームでもキャラクターゲームは人気ですが、昔はそうではありませんでした。1990年代は、多くのゲームファンの間では、「キャラクターゲームはつまらない」と言われていました。 2002年にシリーズ発売開始されたRPG『ドットハック』シリーズの企画コンセプトは、面白いキャラクターゲームを実現することであり、2003年当時の社長（松山洋）がラジオ番組『ドットハックレイディオ』に出演した時に、「キャラクターゲームがつまらない」という一般的に言われている常識を打破したい、それがコンセプトだ、と述べていました。 しかし実際には1990年時点で魅力的なキャラクターゲームもありましたし、大ヒットすることは無くても、一部の大きな人気は得られていたようです。 }} {{コラム|企画が実制作に移ること| 1990年代後半に書籍を出し始めた、元ゲーム業界人・阿部広樹氏は、ゲーム会社から請け負って、そこで頓挫した、或いは難航した企画を練り直しする仕事をしていたようです。彼の著作ではその経験、経緯が語られています。 扱った一つの企画が、ガンダム風の巨大ロボット操作ゲームで、企画として完成度の高いものでした。 主要機体の巨大ロボットのグラフィック設定画は線画が完成していて、機体パイロットである主人公の顔グラフィック線画もある、ロボットの設定サイズ（「全長○○メートル」、「主要武器：○○」など）なども含む、仕様書がすでに用意されていました。 機体の名前には「メタトロン」や（たしか）「サンダルフォン」と、ネットの普及していなかった当時では調べるのにも手間のかかるユダヤ教の大天使の名前がつけられていました。 阿部氏も、このゲームは実現するだろうと、期待を込めて企画を進めていたようです。 しかし現実にはこのロボットゲーム企画は対象のゲーム会社では採用されず、実際に制作されることはありませんでした。このようにゲームの企画は、企画だけで終了してしまうものが沢山あります。 一般的に商業ゲームの製作は、本当にペイするかどうか、経営者や出資者の審査、判断の上、実制作に取り掛かるでしょう。 企画を作る方も仕事として取り組んでいるのですから、「没になるかもしれない」といって手抜きするはずもなく、内容的にも、前設定の完成度としても、どれも相当の力と手間暇をかけて企画を練りこんでゆくでしょう。 しかし結果は結果としてありますよね。採用される保証はないしされないほうが実際多い。その判断が正しかったかどうかはまた別の話ですがね。 }} {{コラム|他業種、一般的な意味での『企画書』| 企画書にもいろいろな段階があります。 #本当に企画の初期段階の、内部関係者しか見ない、思いつきを書きなぐったような企画提案の書類（厚さはせいぜい2～3ページくらいまで？） #企画が熟成してスポンサーや外部に見せられるようになった段階、もしくはその直前くらいの企画書（10ページを超える程度） #パワーポイントなどを使ってプロジェクタ－で見せるプレゼン資料の「企画書」 多くの業界の企画書で学生や外部の人間が見るのは 2.か 3.でしょう。 1990年代後半のゲーム評論家の阿部広樹の他者との共著による書籍によると、彼はゲーム業界で企画に関するトラブルを解決する仕事をしていたようですが、ある案件で、「当時の人気アニメ声優を起用！」など書かれた企画書をトラブル解決のために扱いましたが、彼らが調査した時には相手先のアニメ声優および声優事務所には全く話が行っておらず、対応にも難航したようです。ただ、本Wikiの別の場所でも指摘しましたが、企画時点では、その手の手続きを踏む必要はないでしょう。企画は企画にすぎませんし、実現の見通しが大きくはないその時点で話を持ってこられても、声優も事務所も、対応しようがないと思う。ただ、前編集者の記述では、許可をとれそうな見込みもないと書いてあるから、よほどのビッグネーム声優、要するにその声優の知名度だけをあてにしている企画ですから、悪い企画の例として非難されても仕方ないのかもしれません。しかし現編集者がさらに邪推、想像するに、彼らに企画トラブルの解決を依頼したゲーム会社は、自分たちは零細で知名度もパワーもないので、とてもその有名声優にはアクセスできない、ですからトラブル解決を稼業にしている業者なら、上手にその声優にアクセスしてくれるのでは？という期待があったのではないでしょうか？だとしたら、この事案に対する阿部氏らの態度、そして後になってわざわざ自らの著書でその出来事、関係者を愚弄して、それで自分たちが正しいかのように言うこの人物の姿勢は、職業人、仕事人として問題があるのではないでしょうか？ さて、ある程度企画が本格化してくると、スポンサーに提示するプレゼン用の資料とは別に、詳細な設定や企画意図を説明する、「詳述企画書（ここでの仮の名称）」も作られていきます。この書類は今後の作業のためのひな型の意味もあり、具体的にどんなキャラクターが出てくるか、イラストなども描かれます。 因みに、「ゲーム　企画書」でグーグル検索してみると、企画書としては 1.~3. そして今書いた「詳述企画書」が混然と表示され、書類として種類や趣旨は明確化されていないようです。企業が求職者を採用するために、企画書を求める場合は、プレゼン資料が最適のようですね。採用担当者にとって一番読みやすい資料だからでしょう。 企画書として、説得力のある内容なら、採用され実制作に移る可能性も高くなるのでしょうね。そのために指摘される事として、冒頭部分で、この企画と既存の作品の違い、今までの状況からの改善点、そして実際の改良の実現の見通しと方針を示すといい様です。これは「企画意図」や「コンセプト」と呼ばれますね。 「改善点→（競合他社の）現状説明→改善案の詳細」を、詳細企画書で段階的に説明するといいですね。新聞記事の書き方で、起承転結ならぬ「結・起・承」（けつきしょう）というのがあるので、それを参考にするのもいいでしょう。 また、売り込み先の消費者として想定しているターゲット層の指定も必要です。年齢はいくつくらいなのか、性別は男性か女性か、などですね。 企画の詳細を作りこんである場合や、すでにゲームソフトを実装してある場合のシステムの説明では、単にフローチャートを図示するだけでなく、そのシステムでプレイヤーは何ができるのか、簡単な遊び方の概要説明、等を加えるといいですね。 }} {{コラム|日産自動車の社内講習でのアニメーション業界人の講演| どこの企業でも社員向けの講習会はそれなりにあるでしょうが、日産自動車では過去、アニメーション制作会社の幹部を招いて、営業マンや企画職の社員のために講演してもらったことがあるようです。 テレビアニメーション『輪廻のラグランジェ』が2012年に放映されていた前後、日産が取材協力として制作に参加していたので、CG雑誌で、日産の講演会の様子が紹介されていました。 アニメーション業界では、実在しない物体や機械のイメージを、メカニック設定などで詳細にイメージを作り、絵コンテマンや、原画・動画のスタッフ間でその具体設計を共有するので、自動車製造業界でも参考になる要素があると考えられたようです。 日産の担当者は、制作会社の幹部の講演会に手ごたえを感じたので、もっと話を聞かせてほしいと要望すると、『輪廻のラグランジェ』の製作会社を紹介してくれたので、その会社にも講演をお願いし、さらに制作会社側の取材協力にも積極的に応じて、異業種同士のコラボレーションが形成されていったようです。 }} さて、ゲームの『仕様書』はそのゲームの設計図なので、起こりうる全てのパターンを網羅して設計を指定する必要があります…と言いたいところですが、そもそも本当にすべての操作に対する反応をもれなく記述できるのか? しかしできる出来ないにかかわらず、創作物が世に出れば、それはコンピューターアプリケーションとして、ユーザーに自由に操作される。その時仕様と創作物が、合理的に網羅的に作られていれば、プレーヤーはストレスなく、ゲームを楽しむ事が出来るでしょう。 ;検品、検収 さて、一般に技術系の業界では、図面などの設計図は、検品のさいのチェックリストを兼ねています。（ただし、ゲーム業界での「仕様書」が検品チェックリストを兼ねているかどうかは、2022/01時点、著者側の調査不足で不明。） しかし検品自体はゲーム業界でも行っている。協力会社から納品されたプログラムも、仕様を満たしているかチェックするだろう。 そしてチェックを通ったら、合格した製品として正式に受け取る。 納品物を合格として認めて受け取ることを「検収」（けんしゅう）という。（ゲーム業界でも）<ref name="creator_work:77">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、77ページ</ref>。ゲームの仕様書は、この検収を考慮に入れて書くのがいいだろう。 つまり逆に納品物が合格していないと判断されると、受け入れない、検収しない、納品者に作り直しを要求することになるだろう<ref>蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、76ページ</ref>。 商業ゲーム界では、営業マンが見積もりをするときの根拠は、仕様書、という事になる<ref name="creator_work:77" />。 外注テストに関しては、仕様書では不十分で、テスト用の別資料を用意する<ref>『ゲームプランとデザインの教科書』,P9</ref>。 バグチェックを外注しない場合は、「仕様書」を根拠にする場合が多いという<ref>吉冨賢介『ゲームプランナー入門』、P20およびP199</ref>。 つまりやはり、製品の仕様の基盤は仕様書、正しい仕様は、仕様書に書かれている事だという事になる。 開発後半のデバッグ段階などのバグチェックの段階に入る前に、仕様書を最新のゲームの状態とそろえる<ref>吉冨賢介『ゲームプランナー入門』、P238</ref>。つまりこれは、ゲームの仕様が制作過程で変わっていったら、逆に仕様書を書き換えて、実際の仕様に合わせるという事だ。 ==作成工程== === まず完成予想図を示す === 仕様書はゲームの設計図です。仕様書のとおりにプログラマーやグラフィッカーは作業をすすめます。ただしゲームの場合、いきなりは完成図を決めるのが困難な場合があります。その場合、段階的に、決められることを先に大まかに決めていくようです。実際、文献『ゲームデザイン プロフェショナル』によるとゲーム業界でも会社によっては、大まかな「企画概要書」と、より詳細な「仕様書」により、段階的に仕様を決めていったりするようです<ref>『ゲームデザイン プロフェッショナル』、P.141</ref>。 なお、書籍『ゲームデザイン プロフェッショナル』によると、ゲーム業界でも、（設計図ではなく指示・発注ですが）あいまいな指示や発注は事故のもとだと、認識されており、たとえば「とにかく、かっこいい感じでお願いします」といった指示は事故のもとだと認識されています<ref>『ゲームデザイン プロフェッショナル』、P.60</ref>。 もちろん後述のゲーム業界での「裁量」のように例外もあります（なお国語的には「原則」「の対義語は「例外」）。しかし、あくまで技術系の仕事での「設計図」というものの原則は、極力、あいまいさがない事が必要なのです。 例外的にゲームの場合、ある程度は発注では、発注相手の裁量にゆだねたほうが良い場合もあります<ref>『ゲームデザイン プロフェッショナル』、P.134</ref>。しかしその場合も、具体的にどういう実装予定のもので、どこに裁量を与えるのかを具体的に依頼する必要があります。これについてはwikiでは短い文章では引用できず、長い文章を引用すると著作権的に問題あるので、裁量の発注について詳しく知りたい人は書籍『ゲームデザイン プロフェッショナル』を買って読んでください。 === 各機能の完成予想図の決定稿 === ゲームソフトにかぎらず、なにかのソフトウェアの完成予想図を描くとき、それぞれの画面を基準にして書くと、相手に伝わりやすいようです。 おそらく、人の目で画面は見えるので、集団内で確認を取りやすいのでしょう。 たとえば、 <pre> △△モードの××画面 Aボタン: ダッシュ（走る）。押すとキャラが十字キーの選択方向にダッシュするようにプログラムする Bボタン: ジャンプ。押すとキャラが上方向にジャンプするようにプログラムする </pre> のような、それぞれの画面・モードでの機能の満たすべき情報の一覧の書類を作業者に伝えると、良いかもしれません。 IT用語では、このように、ソフトウェアをユーザー視点でも見たときに製品がどういう条件を満たしているべきかを指定した仕様のことを（IT用語では）「外部仕様」と言います。 なので、ソフトウェア設計者は、すべてのモードについて、こういった（画面仕様などの外部仕様を中心とした）一覧を用意する必要があります。 これが、プログラマーにとっての完成予想図になります。 なお、（外部仕様でなく）「内部仕様」とは、ソースコードがどうなってるか、という仕様です。 ゲーム業界では原則的に、内部仕様については、書かないようです。 ただし、実際は程度問題であり、設計しようとしている項目がプロトタイプのどのファイルや変数に相当するかがゲーム『仕様書』に書かれるのが通例だと、ネットでは言われています。 さて、外部仕様について、「画面仕様」のほかにも「外部仕様」があります。ゲームの場合、アクションゲームのモンスターの動き方のパターンも「外部仕様」であり、あるいはRPGのダメージ計算式も「外部仕様」であり、なぜ外部仕様かというとプレイヤーから見たら確認できるので（つまり外部仕様であるので）、ゲーム仕様書では、それらの仕様（敵の動き方、ダメージ計算式など）も指定することになるでしょうか。 ゲームの仕様書はけっこうな割合が画面仕様が中心的になりますが、しかし画面仕様の他の外部仕様もゲームの仕様書では指定する必要があるので、そこは気をつけてください。 == ※ 例 == 完成予想図どうしでは、説明はあまり重複しないようにする必要があります。 なぜなら、もし重複させて他の書類の参照をすると、もしその参照された側の予想図Aで設計内容の変更が起きたときに、参照する側の予想図Bにも設計変更が必要になってしまいます<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、228ページ、</ref>。 なので、完成予想図では、説明のための重複は不要です。これは、製造業の製図でも同様です。製造業でも、ひとつの末端部品の図面では、他の図面は参照しないようにします。 さてゲーム業界の話題に戻りますが、学生にはこのような完成予想図の考えかたは、ちょっと分かりづらいと思いますので、たとえばウディタのサンプルゲームを具体例をあげて、説明します。 仮に、このウディタのサンプルゲームを、新たに仕様書として書き起こすとしましょう（仮にですよ。すでにソフトはあるので実用的には、もうサンプルゲームに仕様書は不要です）。 たとえば、ウディタのサンプルゲームは、メニュー画面で、上から順に :相談 :アイテム :特殊技能 :装備 :システム :セーブ というふうに6つのコマンドがあります。 上から4つめに「装備」というのがあって、それにカーソルを合わせた状態で決定ボタンを押すとキャラクター選択に移り、十字キーで目的のキャラクターを選択して決定ボタンを押すと、装備画面に移ります。 さて、もしこれを仕様書にする場合、たとえば装備キャラクター選択の仕様での説明の文章では、あえて、 【'''装備キャラクター選択画面'''】 '''遷移直後の変化''' メニュー欄に「装備」コマンド位置に決定後カーソル画像「○○○.bmp」を表示。 キャラクター選択欄のカーソルの点滅が開始。キャラクター選択用の点滅用カーソルの画像は「△△△.bmp」。 '''ボタン押の反応''' キャラ選択欄で十字キーの方向にいる隣または次のキャラクターを選択でき、そのキャラの選択欄にて点滅カーソルが点滅表示される。 決定キーを押すと、選択中キャラクターの『装備部位の選択画面』に移る。 キャンセルキーを押すと『メニュー画面』に移る。 '''画像リソース''' ○○○.bmp :メニュー欄用の決定中カーソル画像 △△△.bmp :キャラクター選択欄用の点滅用カーソル画像 という感じの、その画面とやりとりする相手先の画面の名前と、あとはその画面の読み込むファイル等しか、他の画面や他ファイルについては書かないほうが良い、というワケです。 :※ 実際はもっと多くの変化がウディタのサンプルゲームであるだろうが、説明のため単純化している。 :※ 上記の仕様書の書式の参考文献として、吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、221ページ、の例『各画面の仕様書の例』の書式を参考にした。 ついつい学生さんとかだと、 『装備部位の選択画面』に移ったあとの説明も続けて書いてしまいがちです。しかし、そういうのは別途、たとえば『装備フロー仕様書』みたいな仕様書を作成せよ、と考えるのが良いでしょうか。 なぜ別途に分かるべきかというと、もし仕様変更で、『装備』コマンドの位置が（サンプルゲームでは上から4番目だが）上から6個目に変わったりしたら、「メニューの装備コマンドは上から4番目にある」と書いた書類は全部作り直しになってしまいます。 そういう修正時の書類の作り直しの手間を省くため、あえて書類をモジュール化するのです。当然、そのままでは全体像は把握しづらくなりますが、しかし全体像の把握については、さらに別の全体像把握のための専用フローチャートなどを書類に設けるなどして補うことによって、修正の手間がなるべく波及しないようにします。 さて、「装備フロー仕様書」みたいなのを作るときは、たとえば '''装備フロー仕様''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 のようになるでしょうか。 ::なお、フローチャートの作図をしたい場合は、オフィスソフトのパワーポイントの図形描画の機能で作図が可能です。 ::またなお、フローチャートの描き方はJISで決まってるので、ソレを参考に。というか中学校の技術家庭科でも習う。 また、ウディタのサンプルゲームの装備部位の選択画面では、 :右手 :左手 :身体 :装飾1 :装飾2 と5つの項目があります。 もし仮に仕様変更で、部位の名称が変更され、 :武器 :盾 :頭 :身体 :腕 :装飾 とかに名称の仕様が変更したりすると、「装備部位の選択画面の「右手」選択にカーソルの合わさった状態で移る」とか書いた書類は、すべて作り直しです。 なので、『メニュー画面』とか『キャラクター選択画面』とかでは、そういう他画面である装備部位選択画面についての個別具体的な項目の名称（「右手」とか「左手」とか）や移り方の詳細は書かないで、キャラクター選択画面の仕様では単に「選択中キャラクターの『装備部位の選択画面』に移る。」と遷移先の画面名だけを書くべきか、あるいは「画面の変更時は原則、その画面のいちばん上のメニュー項目にカーソルの合わさった状態で画面が移る」とか、どこかの仕様書に書いておいて、あとはその説明を今回も引用するかすればいいだけです。 また、装備コマンドのフローを書くときは、 あまり、 :マップ画面 → キャンセルボタン → メニュー画面 → 「装備」を選択で決定ボタン → キャラクター選択 → 決定ボタン → 装備品選択画面 と設計図の段階では、続けて書くべきではないでしょう。 こういうのは、意味のある内容ごとにいくつかにフローを分解し '''メニュー選択フロー''' 【 マップ画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 メニュー画面 】 というメニュー画面を選択するためのフロー仕様書と、 もうひとつのフロー図面は、 '''装備関係フロー''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 という装備関係のフローとに2分割するのが良いでしょうか。 このように、意味的にまとまりのある単位ごとに階層をフロー分割するのが良いでしょう。 かといって、階層を5分割とか10分割とかすると、まるでゼネコン多重下請けみたいになって、かえって見通しが悪くなりますので、なるべく2分割までにするのが良いと思います。（せいぜい3分割まで） さて、フロー同士の関係の記述では、別途、 【メニュー画面仕様】 '''表示項目リスト''' 決定ボタンで下記の項目を選択できる。 ・相談　　　　　　:決定すればメニュー相談フローに移行 ・アイテム　　　　:決定すればメニューアイテムフローに移行 ・特殊技能　　　　:決定すればメニュー特殊技能フローに移行 ・装備　　　 　:決定すればメニュー装備フローに移行 ・システム　　　　:決定すればメニューシステムフローに移行 ・セーブ　　　 　:決定すればメニューセーブフローに移行 '''非表示項目''' ・キャンセルボタンでマップ画面に戻る とでも書いておけば済むでしょうか。 なお、各画面での遷移先の画面の説明と、フロー図での遷移先の画面との説明が重複していますが、これは実務でも構いません。 参考文献の 吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』の209ページ「状態遷移フローの例」と211ページ「各画面の仕様書の例」とでも、遷移先の画面の説明はそれぞれ重複しています。 ;一枚の図面の中では内容重複はオッケー なお、一枚の仕様書の中では、内容の重複はオッケーです。 たとえば、機能の似たモノを2個つくるとき、 2個目の説明では、「○○については△△と同じ」のように、「～～～と同じ」というふうに説明できるから、です<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ、</ref>。 なぜなら、この場合なら、他の図面を参照する必要が無いので、一枚のその図面の中で完結するからです。 しかし、この場合でも、なるべく二回目以降の説明では「○○については△△と同じ」のように、「～～～と同じ」というふうに説明すべきです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ、</ref>。 あまり、具体的な仕様の文は、二度目からは掲載しないほうが良いのです。 なぜなら、もし参照先である一度目の説明の仕様に設計変更があると、もし具体的な仕様の文を2度目以降にも掲載した場合には、修正のさいに二度目・三度目の説明も修正することになってしまいます。 で、よくミスとして、二個目以降の修正をし忘れるミスがあります。 ;その他 暗黙の前提ですが、画面名やファイル名などの名前を決める際には、具体的な名前をつけましょう<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、213ページ、</ref>。 たとえば、上述のウディタのサンプルゲームの画面をもしアナタが命名するなら :「マップ画面」、「メニュー画面」、「装備キャラクター選択画面」、「装備部位選択画面」などのように、です。 当然のことのように思えますが、しかし、おそらく新人にこういう図面を書かせる仕事を依頼すると、新人によっては、「画面1」、「画面2」、「画面3」、…のような具体的でない名前をつける場合があります。 あるいは、「メイン画面」、「メニュー画面」、「サブメニュー画面1」、「サブメニュー画面2」、…というパターンも考えられます。 しかし、そのような抽象的な命名は他人に伝わりにくいためやめましょう。 ===== 要求事項書はゲーム業界では書かない場合もある ===== IT業界でいう「要求事項」とは、顧客などから、完成品の満たすべき要件を聞き取ったりしたりして、完成品の満たすべき要件をまとめた書類のことです。 しかしゲーム業界では、ゲームプランニングの書籍を読んでも要求事項書は紹介されてない状態です。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） 個人製作のゲームでは、要求事項書は、まず不要です（自分で作ればいいので）。 個人製作では要求事項は不要ですが、比較のために下記に概要を記載しておきます。 まず、要求事項書は、発注者と受注者の両方の打ち合わせによって書きます。 なおゲーム業界でも、（要求事項書ではなく）発注書ですので立場は逆の種類ですが、その発注の成果物が作中でどういう目的で使われるのかなどの意図・用途を伝えるのが良い<ref>『ゲームデザイン プロフェッショナル』、P296</ref>とされています。 ==== データ暫定値 ==== ゲーム中の、たとえばRPG武器の「攻撃力」などのデータの数値は、あらかじめ作者が、すべての項目の想定値を具体値で設計図に記述します <ref>[https://www.youtube.com/watch?v=KVdtNiB_lIQ 【ゲーム企画】 ゲーム仕様書の書き方 - YouTube] ゲームのしくみチャンネル、2015/12/11、 2020年3月14日に閲覧</ref>。 CSVファイルなどでエクセルなどで記述しておきます。 【剣データ暫定値】 銅の剣: 攻撃力 7 鉄の剣: 攻撃力 18 ハガネの剣: 攻撃力 37 ミスリルの剣: 攻撃力 70 ほのおの剣: 攻撃力 57 （※ 剣ではランク5は欠番とする） デスブリンガー: 攻撃力 150 備前長船: 攻撃力 250 聖剣エクスカリバー: 攻撃力 450 魔剣レーヴァテイン: 攻撃力 450 みたいに、暫定値でいいので、とりあえずの具体的指示も必要です。 ただし、これはあくまで暫定的な値でありますので、今後の調整で変更する可能性があります。 ==== データ仕様書 ==== データ仕様書とは、たとえばRPGなら :攻撃力: 敵の守備力との計算によってダメージを算出する のようなパラメータ計算式の定義を行った仕様書のことです<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、92ページ</ref>。 そして、この「データ仕様書」は、デバッグのための資料になります。デバッガーが、この資料と実際の動作を照合することで、仕様どおりにプログラムが動いているかを確認します<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、92ページ</ref>。 どうもアイテム（「やくそう」とか「毒消し」などのアイテム）価格などの「100」（100ゴールド）とか「200」（200ゴールド）とかの具体値のあるデータ表のことをSTUDIO SHIN 氏は「仕様書」と言っている<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、261ページ</ref>。本当は「100」になるべき数値が「200」になっている場合、「仕様書」で簡単に確認できるとSTUDIO SHIN 氏は言っている。） 一般に、RPGの仕様書は、すごく分厚くなるといわれています。（アニメ評論家の岡田斗司夫が1990年代のむかし、彼の言うには、彼の伝聞によると、ある有名RPGの仕様書は、その書類の量の表現として（ページ数ではなく）キログラム単位で表現されるくらいだと言われています。岡田さんは彼の著書『オタク学講座』などの書籍で、そういった伝聞を述べています。有名作の仕様書だと、ちょっとした電話帳みたいに分厚くて重い書類が、場合によっては何冊かあるらしいです。おそらく、データ台帳に、攻撃力などのデータだけでなく、さらに設計の背景となる要求事項などもマトメて書いた上での重量でしょう。） ;攻略本と『仕様書』 ゲームの攻略本にある、アイテムの効果値や、敵の能力値などといった数値の一覧などは、おそらく、そのゲームのデータ台帳から、転記されていると思われます。 よく、「仕様書をもとに攻略本が作られる」と言いますが、しかし攻略本の制作に必要なのは、プログラム部分の設計図などではなく、実際に入力された各データを記載したデータ台帳のハズです。 ただし、実際には市販の攻略本には、記載ミスなどもあります。 また、制作側が情報を隠していたりして、攻略本に記載された情報と、実際のゲームプログラム内の数値とが違っている場合もあります。 == 他部署との連絡の仕事をするのは誰なのか == ゲーム業界では、プランナーと言われる役職の人が、連絡網の中心になって、いろいろな部署のあいだの情報伝達をします。 <div style="font-size:120%;"> <pre> ディレクター　━━━　プランナー　━━━━┳━　プログラマ 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　グラフィッカー 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　デバッガー </pre> </div> のような感じです。（ディレクターの上に、さらにプロデューサー、プロデューサーの上には社長などがいるが、省略する。） このプランナーは、ゲーム業界の場合、中間管理職のような権限もあって、各部署（プログラマ部署やグラフィッカー部署など）とディレクター（監督みたいな役職）のあいだのやりとりもします。 :※ 一般の企業での連絡網の場合については、企業ごとの差異が大きいので、説明を省略する。 「プランナー」というと、てっきりプラン「計画」を練る仕事化のように思いがちですが、しかし、どっちかというと、計画を練るというより、たとえばテレビ業界でいう「AD」アシスタントディレクターのようなイメージのほうが近いかもしれません。 実際、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、プランナ－にはTV業界でいう「AD」のような側面があると述べています<ref>吉冨賢介『ゲームプランナー入門』、P236</ref>。 == イラスト・音楽などの外注や打ち合わせ == イラスト・音楽に限った話ではないですが、文献『ゲームデザイン プロフェッショナル』によると、発注フォーマットに業界共通のルールは存在しないので、だから開発する作品に適したフォーマットを考える必要があります<ref>『ゲームデザイン プロフェッショナル』、P.146</ref>。 また、発注の際には、発注の目的まで、発注相手には説明できることが望ましいとのことです。 何らかの発注をする際、事前にチェック項目リストを作る必要があります<ref>『ゲームデザイン プロフェッショナル』、P.159</ref>。 === 外注する場合 === 自分にイラストや音楽をつくる能力が無い場合で、イラスト素材や音楽素材の調達をしたい際、イラストレーターなどの専門家に外注することになります。 打ち合わせをする際、たとえばイラストなら、発注元の画力にもよりますが、 :構図、 :希望のポーズ、 :塗り方、 :テイスト、 などの指示が必要です<ref>『ゲームプランとデザインの教科書』、P.128</ref>。 あと、絵を書かない人が勘違いしがちなことですが、「イラストレーター」を名乗っている人は、あくまでイラストだけが専門的であるので、一般に、イラストレーターは漫画を書けません<ref>『ゲームプランとデザインの教科書』、P.128</ref>。アニメも作れません。 イラストも漫画も両方とも作れる人のほうが、希少ケースなのです<ref>『ゲームプランとデザインの教科書』、P.128</ref>。（たとえばアニメ業界のジブリの宮崎監督のような、イラストもアニメも漫画もかけるような人は、かなり例外的なケースです。） なので、イラスト、漫画、アニメ、などは、それぞれの専門家ごとに分けて注文なり依頼なりをすべきです<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 ゲーム作家によっては、キャラクターイラストの発注をするときはモデルとなるアイドルや俳優などの情報を添えて発注するゲーム作家もいます<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 :ラフ画などを用意してどんなシーンでどんなキャラのどんな構図を書いてほしいか等の大体の要望を具体的に伝える、 というのも重要ですが、もうひとつ必要になるかもしれない事として、 :なぜ、その構図が作中でどういう目的で使われるのかなどの意図・用途を伝える<ref>『ゲームデザイン プロフェッショナル』、P296</ref>、 という事が重要です。 『ゲームデザイン プロフェッショナル』によると、発注の意図・用途を伝える際も、長いと意図説明が書類の場合は書類を読んでもらえないし、口頭でも相手の頭に入らないので、だから発注者は要点を短く的確な言葉であらわさなければあらないということです<ref>『ゲームデザイン プロフェッショナル』、P295</ref>。 個々から先は別に文献の内容ではないですが、そもそもなぜ用途を伝えるのが必要かというと、相手のほうがその分野ではプロだからですし、発注元は往々にしてイラストは素人だからです。 発注元が素人の場合、プロのイラストレーターに用途を伝えると、たとえば、当初に発注元の考えていた構図などが実は不適切である、という情報が返ってくる可能性もあります。 このようなフィードバックのある場合、発注元がデザインを再検討する必要になる可能性もあります。 そもそも発注元は、あまりイラストや音楽などの分野を知らないので、だからこそ事前の打ち合わせによる、デザイン意図の確認が必要なわけです。 つまり、たとえるなら「作業指示」と考えるよりも、どこかの営業マンとの事前の打ち合わせのようなものだと考えるのがイメージ的には適切かもしれません。 たとえば住宅をリフォームする場合なども、事前に何度もリフォーム会社の営業マンとの商談をして、イメージを共有するのが普通です。イメージ的には、これに近いのかもしれません。イメージ的には、イラストレーターとか作曲家などアーティストに対する外注・発注も、こんな感じでしょう。 ;その他 書籍『ゲーム作りの発想法と企画書の作り方』によると、アダルトゲームではシナリオも外注の場合が多くあるとのことです<ref>畑大典 著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P129</ref>。 ;発注されるイラストレーター側からの視点 これはイラスト－レーター側からの視点では、発注者の要求事項に従った絵を描かなければならないわけです。 だからもし、提出しようとする絵が、まったく要求事項に従えてなければ、ダメな絵となり、発注者は納品受け取りを拒否するので、絵はリテイク（書き直し）になります。 たとえば、アニメイラスト系絵描き向けの教本『クリエイターのためのおんなのこデータベース2008 -ファッション編-』によると、 もしイラスト発注の要求事項が「セーラー服の少女を描いてください」なのに、 もしイラストレーターがブレザー服の少女を描いて提出してきたら、 どんなに可愛く上手にブレザー少女が描けてようが、リテイクです<ref>『クリエイターのためのおんなのこデータベース2008 -ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日 初版発行、P.208</ref>。 イラストレーター向けの教本などでもきちんと教育されているように、まともなイラストレーターは、こういう社会のルールがきちんと分かっています。 裏を返せば、こういう社会ルールが分かってない絵描きは、自称「イラストレーター」です。 イラストレーターにとっては当然の、社会のルールだと思いますよね。しかし世間には、イラストレーター業界に興味ない人は、この当然の社会ルールが分からない人が、少なくとも2005年より前の昔は世間に多くいました（下記コラムで説明する）。 {{コラム|絵の仕事は自由業ではない| 根本的な問題として、さすがに最近は無くなってきたと思いますが、ほんの2005～08年ぐらいまで、 世間には絵の仕事を、「自由に絵が描ける」と勘違いしている人がいました。また、「漫画や絵の仕事は、競争を気にしなくていい」という類の、良く分からない勘違いもありました。 どうやら、勘違いの原因は、小学校の図工のお絵かきや、中学校・高校の美術の授業が、そういうなるべく自由なテーマで絵を描かせるので、どうもイラスト関係の仕事までそうかと勘違いをする人が、ほんの2008年くらいまで昔は少なからず居たのです。 さんざんマンガ評論やアニメ評論などで「漫画の打ち切り」だとか「アニメの放映打ち切り」とか言われても、あるいは評論誌など読まなくても友人どうしの雑談でそういう話をしても、しかしその「打ち切り」情報が脳内にある勘違い「小学校の図工のような自由な仕事 <nowiki>=</nowiki> プロ絵描き」という勘違いの修正に結びつかないようです。 だから漫画家の江川達也は苦言として、雑誌コラム（おそらく『SPA』）で2001～2005年ごろの意見ですが、当時のゆとり教育の賛成論者がなんだか漫画業界について「漫画家は、競争が無くて自由に漫画を描ける仕事」だと勘違いしているような言説が散見されたことに対し、江川は苦言でおおむね「漫画家はとても競争の厳しい世界だ。ふざけたことを言うな」といったような感じの批判を雑誌コラムで述べていました。 漫画家はプロデビューするまでだって競争がありますし、デビューしてからも不人気だったら打ち切りですし、競争はとても厳しいです。 漫画に限らず、どうも世間にはイラストレーターや漫画家を、なぜか競争のない業界だと勘違いしている人が好くなからずいます。昭和の時代は、漫画家を終身雇用だと勘違いしている人もいました。 昭和時代にデビューした漫画家の小林よしのりは、自身が漫画家プロデビューするまでは、勘違いで、「マンガ出版社は、漫画家が死ぬまで面倒を見てくれる、まるで公務員のような終身雇用の業界が漫画業界」だと思っていたと、著書『ゴーマニズム宣言』で自身の勘違いを白状しています。 それでも昭和の時代なら、まだ漫画業界がよく知られていなかったので、世間一般の終身雇用の常識に照らし合わせて勘違いしてしまうのも、無理ありません。ですが、平成が10年以上も過ぎた2001年以降にこの手の勘違いをしている人もおり、もう手の施しようのない人です。 }} === 絵の「クオリティ」とは === 何かのゲームデザイン本によると、「クオリティ」とは、イラスト発注などの言葉のようです。 その書籍では「クオリティ」の意味は説明していないのですが、ゲーム業界で言うクオリティと一般の英語のqualityは少々、意味が異なります。 ゲーム業界には、イラストや音楽などに対して「クオリティ」という言葉があります。英語ではqualityは「品質」という意味ですが、しかし日本のゲーム業界でいう「クオリティ」にもその意味はあるもののニュアンスはやや違います。 たとえばイラストの例なら、どんなに「ポーズと構図はこうしてください」とか「メインカラーはこうしてください」とかの発注要件を守ってイラストレーターが絵を描いて提出しても、しかしその絵の画風がターゲット層の消費者たちの好みの画風でなければ、ゲームが売れずにゲーム会社は商売になりません。 少なくとも2010年以降、ゲームファンの絵柄の好みは、素人では描けないような細密かつCG特有のグラデーションなどを活用した絵柄が消費者層の好みです。そういう求められた画風である細かい絵である素材を出せる能力のことも「絵のうまさ」と捉えて、ゲーム業界では「クオリティ」と呼んでいるようです。 逆に言うと、たとえばマンガ家の手塚治虫『鉄腕アトム』の原作のような簡素な絵でどんなに上手い絵をゲーム発注者に提出しても、おそらく「クオリティが高い」とは言われないでしょう。 絵の場合、昨今の消費者の好みが、細かく線を描きこまれたりグラデーションなどCG機能を多く使ったアニメ風イラストまたは細かいリアルCG風イラストといった絵柄なので、そういう絵がゲーム業界では「クオリティが高い」のように言われたりもします。 ;業界によって要求される画風が異なる ゲーム業界の絵を描く能力は、マンガ業界やアニメ業界で求められる能力とは異なります。 マンガ業界の場合、まず白黒印刷で表現できる絵柄でないといけませんし、印刷の解像度の問題もあるので、カラー表現は求められない場合も多いし、またグラデーションも利用が困難です。だからマンガ業界ではグラデーションではなく、スクリーントーンを使います。そもそも製作ソフトウェアからして、イラスト製作用ソフトではなく専用のマンガ製作用ソフト（『コミックスタジオ』など）を使ってマンガが描かれています。週刊マンガと月刊マンガでも、絵柄の傾向が違っています。試しに線画部分だけでいいので漫画を模写などをしてみれば分かると思いますが、週刊漫画の絵柄は比較的に短時間で模写できるような線の少ない絵柄になっている場合が多いえす。 アニメ業界の場合、動画マンが動画を何枚も描かないといけないので、原画ではなるべく1枚あたりの線を減らす必要があります。1枚イラストでは「撮影」と言ってCG処理などで光の表現などのためにフィルタ加工などもしますが、しかしゲーム業界と比較するとアニメ業界の手書きアニメ用イラストのCG処理は簡素な処理です。 ゲーム業界とアニメ業界では、人気の絵柄におけるCG加工の傾向が逆のことも多く、だからアニメ業界のような多くの人が真似して描けるようにデザインされた絵柄は、ゲーム消費者にはウケていません。 世間では美少女キャラの瞳が大きいだけで「アニメ絵」とか言いますが、しかし実際には瞳の大きい美少女キャラでも、アニメ業界とゲーム業界とマンガ業界とでは、求められているデザインがまったく違うのです。 アニメ業界とゲーム業界とで「原画」や「仕上げ」など共通の用語が使われる場合もありますが、内実、意味は違っています。 もっとも、近年ではアニメ業界もゲーム業界やライトノベル業界（雑誌媒体なら月刊誌である場合が多い）などの影響を受けて、細かい絵が増えてきました。アニメの原作がゲームやライトノベル作品である場合も多いので、そういう作品は当然、細かい絵が求められるわけです。 なお、アニメ業界の場合、細かい絵を描くことはクオリティとは呼ばずに「カロリー」と呼ぶことが多いです。どうやら栄養の「カロリー」由来の表現らしく、作画に求められる手間や負担というような感じらしいです。「作画カロリー」などといった表現もアニメ業界にあります。 細かい絵や、細かい動き、やたらと凝った動きや構図などを描く際、「この絵はカロリーが高い」のように表現するようです。 「クオリティ」という言葉を聴いているとあたかも「業界を越えて共通の絵のうまさがある」とでも錯覚するかもしれませんが、しかし上述のように要求される絵柄や画力は、業界ごとに違います。 ;週間マンガ・アニメの後日修正 なお、実は週間漫画は、雑誌掲載時の絵柄と、単行本掲載時とで、絵柄が微妙に違う場合があります。雑誌掲載時だと、週間ペースの掲載に追いつかせるために、省略できそうな背景などの書き込みを減らしている場合もあります。なので、実はそういう省略された部分を、単行本化に向けて後で、アシスタントや、専門の会社などが、細部を仕上げているわけです。 単行本の話ではないのですが、2012年ぐらいにBSあたりで放映されたマンガ業界特集番組では、実はマンガのアシスタント専門の会社が存在することを紹介しています。細かな統計は忘れましたが、その番組によると、現代（ただし放映当時の2012年頃）の漫画家の多くは、実は連載作家ではなくアシスタントとのことです。今のマンガ産業は、実は分業制なのです（なおアニメ産業は昭和後期～平成初期からとっくに分業制）。 アニメも、実はテレビ放映時とブルーレイ・DVDなどの円盤メディアとで、絵柄が少しだけ微妙に違う場合などがあります。放映後に細部を直すのです。 === マンガ・アニメ業界での「芸術」･「自由」の裏の意味 === 文献『ゲームプランナー集中講座』によれば、ゲーム作りに必要な資質としては、作家性<ref>『ゲームプランナー集中講座』、P246</ref>のほかにも「人を楽しませたいと思う気持ち」<ref>『ゲームプランナー集中講座』、P246</ref>が必要です。 また、同文献によれば、ゲーム会社では自己表現は求められていません<ref>『ゲームプランナー集中講座』、P246</ref>。もし本当に自己表現をした人は、ゲーム会社ではなく１人で芸術家を志望するべきだと文献『ゲームプランナー集中講座』では述べています<ref>『ゲームプランナー集中講座』、P246</ref>。 作家性は必要ですが<ref>『ゲームプランナー集中講座』、P246</ref>、しかし自己表現は求められていないという、バランス感覚が問われます。 ゲーム業界への就職では自分の作品があるとアピールポイントになり多くのゲームプランナー入門書でもプロトタイプなどの作品づくりを推奨していますが、しかし自己表現は求められていないことに注意する必要があります。 さて、ゲーム会社だけでなくイラスト業界やマンガ業界も、似たような見解です。 『クリエイターのためのおんなのこデータベース2008 -ファッション編-』によると依頼内容を無視して自由に絵を描こうとする人は、けっして「プロ」ではなく、それは「芸術家」だとのことです<ref>『クリエイターのためのおんなのこデータベース2008 -ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日 初版発行、P.198</ref>。 ==== 「芸術」 ==== 「芸術」といえば、漫画『サルでも描けるまんが教室』では、漫画家志望者が芸術かぶれになることを、とても戒めています。 {{コラム|サル漫の芸術かぶれ回| サル漫の芸術かぶれ回では、作中の漫画家コンビのシナリオ担当の竹熊と作画担当の相原が、漫画の執筆中に、 芸術かぶれを煩った作画担当キャラの相原コージが、まず、おおむね「俺たちはこんなくだらない漫画を描いてていいのだろうか」みたいなことをつぶやきます。 それに対して竹熊が心配したか「どうした相原？」とたずねると、 相原の細かなセイルフは忘れましたが、相原は「俺たちはもっと本質的な作品を作るべきではないか？」とか 「資本主義などという下らない次元にとらわれてはいけないのではないか」とか、 「俺たちは国や大企業におどらされていてはいけない」とか、 なんかそんな感じのことを言います。 すると、竹熊はまず相原をぶん殴ったあと、 竹熊は「お前は芸術をぜんぜん分かっちゃいない！」と説教し、 相原が「そんなことない」というと、 竹熊が「じゃあ、お前のいう芸術とは何かと言ってみろ？」と問い詰めると、 相原が「それは、人間の内面の真実ってゆうか」とつぶやくと 竹熊はめっちゃあきれたような見下したような表情で、「にんげんのぉー、ないめんのしんじつぅ～」みたいにつぶやき返します。 そしてそのあと、竹熊はおおむね、 「お前は権威にとらわれてはいけないとはいうが、じゃあお前のその意見は、どこかの芸術大学の教授の権威にすがっているだけではないか！？」とか :「お前こそ、政府や商業メデイアによる宣伝のつくった権威にとらわれているだけじゃないか」とか、 :「お前は芸術教授の権威にあやかって自分も地位と名誉が欲しいだけだし、結局、お前はカネが欲しいだけなのだ。」 なんかそんな感じのツッコミをします。 このあとも竹熊のツッコミは続きますが、続きを知りたい方はサル漫を購入してください（ネタバレになるので続きは省略）。 ともかく、マンガ業界やアニメ業界でいう『芸術』には、こういう隠れた意味があります。 アニメ『新世紀エヴァンゲリオン』の総監督の人はサル漫の大ファンですし、総監督は竹熊とも対談したことあるので、つまりアニメ業界でも自称「芸術家」はまあ似たような扱いです。 }} ==== 「私小説」 ==== {{コラム|売り上げと文化は違う| 文学史でいう「私小説」と、マンガ・アニメ業界でいう「私小説」とは、意味が異なります。 現代でもアニメ評論などでは、「私小説」というのを否定的な意味で、「頭でっかちのインテリが書いた、世の中に文句を言ってるだけのことを、さも深い洞察かのように装うとしてるだけの、売れない小説」のような意味で使っていたり、あるいは「世間知らずの漫画家やアニメ監督の書いた、世の中に文句を言ってるだけの（以下略）マンガやアニメ作品の脚本みたいなもの」のような意味で使われることもあります。 たとえば1998年の岡田斗司夫の対談集『マジメな話』でも、当時のエヴァンゲリオンの映画版を「私小説」だと対談相手の推理小説家・今野敏（こんの びん）が批判していたりしました。「クリエイターよ、メッセージはあるか」というタイトルの対談です。 なお、名前の漢字が似ているアニメーター・今敏（こん さとし）とは全くの別人ですので、混同しないように。そもそも今敏はエヴァンゲリオンの制作スタッフの一員です。アニメーター・今敏は、全く、岡田とは対談'''していない'''です。 さて、文学史でも、売上と、後世に語られる作品が異なることはあり、たとえば大正文学の売上のベストセラーは、 :倉田百三『出家とその弟子』、 :島田清次郎『地上』、 :賀川豊彦『死線を越えて』、 が大正時代の三大ベストセラーですが、しかし今や彼らは文学史の教科書には、滅多にのりません。せいぜい高校日本史の教科書で、倉田が少し紹介されているくらいです。 現代の教科書でよく大正時代の小説家として紹介される芥川龍之介は、じつは当時は倉田・島田らほどには売れてない作家です。また、「私小説」といわれるジャンルは実は売れていません。（もっとも、芥川が私小説を書き出したのは晩年のこと。このコラムでは、芥川の伝記については立ち入らない。） 食い違いの原因は、芥川が小説連載していた大阪毎日新聞による芥川をブランド化するイメージ戦略の成功や、あるいは第二次大戦後になって教育界隈の左翼運動家たちが文学史を左翼イデオロギーに都合よく書き替えたことなどが考えられますが、しかし新聞社や左翼ごときに書き換えられるぐらいに戦前の文学史が研究不足であったことが、そもそもの根本原因でしょうか。 ともかく、「私小説」というジャンルは、そもそも大正時代の当時は、大して売れていません。 }} === ローポリ関連の作画 === 単元『[[ゲームプログラミング/3Dグラフィック#ローポリ制作手法的なこと]]』で説明した。 == レポートは結論だけを読んでも分かるように書く == レポートなどは、ゲーム業界なら、途中を読み飛ばしても、内容がおおまかに分かるように書かなければなりません。 別に冒頭で結論を述べる必要はありませんが（会社による）、しかし、仮に書類のページの順序どおりに上司が読まなくても、 レポート全体の内容を把握できるように書かなければならないでしょう。 == 中卒でも分かるように書類を書く == ゲームに限らないのですが、企業でレポートなど種類を新人などに書かせると、時々、教科書などを丸写しするような人がいます。しかし、そういう丸写しは、多くの企業で、一般的な企業では不要です。コードの解説というより、企業で何かの解説レポートを書く際の基本ですが。 書籍『ゲームデザイン プロフェッショナル』によると、ゲーム開発で必要なチーム内での言葉選びについては、「中学生の知識でも理解できる言葉を使うこと」とあります。そのほか、言いやすいフレーズを使うことも必要です<ref>『ゲームデザイン プロフェッショナル』、P101</ref>。 ぶっちゃけ、このwikiのこの科目の教科書のようなのは、中学生レベルの知識で読解できないので、ダメでしょう。読者は、このwikiを反面教師にしてください。 書籍『ゲームデザイン プロフェッショナル』は特に述べてはいませんが、企業というのは、従業員の過去の学歴や経歴がバラバラなのです。普通科高校を卒業して就職する人もいれば、業界に近い専門学校に入った人もいますし、商業高校や工業高校などに進学していた人もいますし、大卒や院卒もいます。 日本では高校進学率が100%ですが、しかし高校は選択科目などが多いので、共通知識はどの選択科目を選んだかで差異が多いので、なかなか高校を基準に合わせるのは難しい業種も多いのです（ただし、製造業なら工業高校卒のように、一部の業界では学校の種類を絞って基準にすることがある）。 なので、一般の多くの企業では、従業員がどういった学歴でも情報伝達が上手く行くように、中学レベルでも分かるような物言いが、企業では原則必要になります。大卒社員であっても、そういうふうに言い回しを直すトレーニングをしたりします。 == 脚注・参考文献 == 6syj7m3vssavszuelteozwv862kmdi8 206121 206120 2022-08-01T11:25:36Z Honooo 14373 /*完成予想図*/ wikitext text/x-wiki {{substub}}このページの主要執筆者は、ゲーム業界経験者ではないので（2022/1時点）、ここの記述は調べ物としては役立ちません。 2022/1時点でゲームプログラミングと直接の関係ない話題が長い、という問題があるので、より簡潔、かつ分かり易い記事への編集にご協力いただけたら幸いです。もっとも現編集者Hは、解ってるならそれを書いた奴が書き直せ、そもそも余計なことは最初から書くな、…とは思いますが…。 このページは、教科書としてゲームプログラミングの方針を説明する際に、どうしても書類についての説明が必要だから記述されています。現状では、一般IT業界や製造業などの設計図を参考に説明がなされています。 == 本書の目的 == 本書は、ゲームデザイナーのための教科書ではありません。 メインページ、「[[ゲームプログラミング]]」の題名どおり、プログラマーのための教科書です。プログラマーがゲーム制作に興味をもって実際に作り始める際に、調べ物の手間を減らすために書かれた参考書籍です。 ゲームデザインに関する解説を望む方は、別途、他の参考資料に当たってみてください。 ==「仕様書」== ここでいう「仕様書」とは、ゲームの設計図のことです<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.126</ref>。しかも職業的に集団でゲームを作るときの書類です。 ではまず、「設計図」とは何か、について、考えていきましょう。これは普通科高校では学習しない事項です。 ゲーム業界では、「仕様書」を含む書類群の「発注書」には、決められたルールや書式はありません。だから作るゲーム内容や製作チームごとに、適切な発注書のありかたを毎回考える事になります<ref>『ゲームデザイン プロフェッショナル』、P.145</ref>。 職業的なゲーム開発では、一般に :発注 → 実装 → 調整 というプロセスを経て<ref>『ゲームデザイン プロフェッショナル』、P.61</ref>、最終的にとりあえずの完成になります。 ゲーム産業での「仕様書」は、発注の段階での書類です。 ==集団ゲーム制作での解説文== 発売禁止になってしまった書籍（おそらく。しかし何故？）『国際おたく大学―1998年 最前線からの研究報告』（岡田斗司夫ほか、光文社）に書いてあった事例なのですが、G.O.D.と言うイマジニア社のRPGゲームに対する大学生（岡田は当時、大学講師だった）の取材があって、そのGODの開発に参加した劇作家の鴻上尚史（こうかみ しょうじ）氏と、エニックスの堀井雄二（ほりい ゆうじ）氏とが、対談した経緯が、紹介されていました。 劇作家の鴻上は、ゲームに演劇のリアリティを入れようとして、スタッフに「間（ま）を意識したシナリオを書いてほしい」と要求したが、うまく行かずに難航したと体験談を述べています。 対談相手の堀井は、鴻上のその体験談に対し「『（※ここで3秒休止）』とか書くと良いですよ」と、指示書で具体的に書くと良い、とアドバイスした、と、岡田の書籍にある大学生のレポートにあります。 おそらくドラゴンクエストのゲーム開発でも、このように具体的な指定を必要に応じて出していた・いるものと思われます。 21世紀現代の、商業ゲームの現場でも同様であり、書籍『ゲームデザイン プロフェッショナル』にもありますが（※かぎカッコ内が引用）、「もっとかっこよく調整してほしい」という問題であれば、たとえば「もっと目立たせたいので、アニメーションのシルエットを全体的に今より少しだけ大きくしてほしい」<ref>『ゲームデザイン プロフェッショナル』、P296</ref>という具体的な指定が妥当でしょう。 == 集団作業に必要な書類 == ===設計図=== IT業界やゲーム業界では、集団作業で制作開始をしようとする際、まず、いきなり設計図を作るのではなく、まず先に試作品（しさくひん、英語で「プロトタイプ」proto-type）のプログラムを作り、企画で考えた各種システムなどのアイデアが有効かどうかを検証します。 そのプロトタイプで、企画のアイデアが本当に有効であるかを確認してから、もし有効だったら、本格的な制作を開始します。 もしかしたら会社によっては、企画会議（もしくは企画の打ち合わせ）よりも先にプロトタイプを作るかもしれません。 さて、会社へのプロトタイプ提出で、制作続行・制作本格化の賛同が会社から得られたとしましょう。 IT業界でも製造業でも、どこの業界でも集団作業で、制作の合意を作るさい、必要な書類は、おおむね、 :作業者用の具体的な「完成予想図」 です。 しかしゲーム業界の場合、いきなり完成予想図に相当する「仕様書」は書けないので、書籍『ゲームデザインプロフェッショナル』によるとまずゲーム中の大まかな実装予定事項を記述した『企画概要書』という書類を作成することもあると言われています<ref>『ゲームデザインプロフェッショナル』、P139</ref>。ただしこの「企画概要書」は、名前に「企画」とはついているものの、どちらかというと仕様書の方針を大まかに打ち合わせするための書類に近いので、いわゆる「企画書」とは異なります。 なお、一般のIT企業でよく書かれる「要求事項書」は、ゲーム書籍では紹介されていないので、おそらくゲーム業界では書かないのが普通だと思われます。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） ===ゲーム業界での技術職=== 言葉というのは同じ国の国語でも、その業種や職場、社会集団で、微妙に違った使われ方をすることも多く、技術職、という言葉もゲーム業界での特別な使い方があるようですね。 この業界では、グラフィックデザイナ－やサウンドクリエイターやプログラマーが「技術職」<ref>『ゲームプランとデザインの教科書』、P125</ref>。技術職 = ￢(not)企画職、という事で、プロデュ－サーやプランナーやディレクターなどの「企画職」でない製作スタッフが技術職です。 ただ現編集者はプロデューサーとディレクターは対立する職種だというイメージはありますね。プロデューサーは企画職だろうけど、ディレクターは、"実"制作職ではないかな？ ===企画書=== *PREP法 基本的にビジネス上の書類は、結論を一番先に書く構成法が望ましいですね。もちろん商業ゲーム制作の現場でもそうでしょう。文献『ゲームプランナー入門』では、具体例として、PREP法を紹介しています。 PREP法とは、 :Point（結論）→Reason（理由）→Example（具体例）→Point（結論）。 ほかにもホールパート法やSDS法などがありますが、どれも冒頭で結論を示した後詳細を伝える方法で、ビジネス文書はやはり、その形式が常道でしょう<ref>『ゲームプランナー入門』、P141</ref>。 しかしこの社会、ビジネスが重要なのは事実だが結局、他者の行為や仕事をただ自分の欲望と利益に使い、他者の存在や詳細に興味のない人間は、とにかく結論だけを先に聞きたがるし、それ以外の事には事実上何の興味も持っていないでしょう。 *ゲームのルール 常識的な判断としては、ゲームにはルールがあるものですよね。ルールのないゲームというのは、ふつうあまり考えつかないし、イメージできない。 ですからゲーム企画書としては、ルールの説明が必要になる。キャラクター設定や世界観の解説があったとして、ルール説明がない企画書はふつう受け入れられない<ref>『ゲームプランとデザインの教科書』、P83</ref>。 ただ今ではゲームジャンルの固定化が進んでいるので、ルールはくどくど説明する必要はない、という場合はある。 企画書を誰が書くかという問題もある。業界の内部の重要人物か、全く外部の業界経験の無い人物か。 どちらににろ常識判断としては、ある程度のゲームルールの解説は必要だろう。 *プレイ人数 企画書には、ゲームのプレイ人数の記述も必要<ref>『ゲームプランナー入門』、P159</ref>。 ほんとの昔は、一人か二人でプレイするのがコンピューターゲームだったのですが、もはや時代は変わりましたね。インターネットを駆使して多人数プレイ、ソーシャルゲームなんてものも出てきました。 <!--(:※ ここから先、セクション末尾まで文章の編集者が異なります。編集者Hによる文章です。なお出典のある部分は編集者Hではなく別の編集者Sによるものです。)←すじ肉先輩さー、この記述は無いわ^^;;。だってこれって、みなさーん、以下の馬鹿文はHが書いたんだからね、俺、Sujの文じゃあないよ、馬鹿なのはHであって、俺じゃあないから。Sujはちゃんと出典は全部書いてんだよ^^、って言ってるのと同じだよね^^;;;;;--> さて、企画書に関しては、よくない企画の典型例というのはあるようですね。特に特定人物のネームバリューに依存した企画は良くないし、批判の対象になることも多いようです。ゲームとしては、イラストレーターや声優に超大物を起用することを強調した企画書ですね。 出典として『テリー伊藤のお笑い大蔵省極秘情報』あたり、確実に特定はできませんが、木村拓也のタレント性に頼った企画は、著者のテリー伊藤によってよくない企画の例として指摘されていたようです。 もっともテリー伊藤という人物自身が、ビートたけしの面白さ、彼を起用したことの良さによって世に出て知られるようになった人物なので、そんな事言っていいのかね、などと現編集者は少し思いますが…。 また今回の本題、ゲーム業界でもそういう良くない企画書が提出されることは多いようです。元ゲーム業界人でゲーム評論家の あべひろき が、90年代の著書で、過去にゲーム関連会社に勤務してたときの体験談を書いています。企画書の精査をしているときに、「人気声優の○○さん起用！」と書かれていたものがあったが、あべ氏がその声優の所属する声優事務所に確認の電話をとると、なんの商談も声優とも事務所ともされていなかったという事です。 もっとも企画書とは企画に過ぎないのではないだろうか？これらの他人のネームバリューに頼った企画が良くないのは事実だが、企画が通って実現する見込みが決定する以前は、むしろ声優本人や事務所にアクセスすることはないのが普通だろう。 もちろん企画者がその事務者や声優と懇意にしてる場合は、あらかじめ話をする可能性はあるが、しかし企画段階ではそもそも現実のビジネスになる可能性はそれほど高くない。声優や事務所にとってもその段階でもっともらしく話をされても、むしろ困惑するだけではないだろうか？ ただこういう他人任せの企画は、「プロデューサー的企画」と呼ばれるようです<ref>吉冨賢介『ゲームプランナー入門』、P71</ref>。クリエイティブな企画とは言えないわけですが、しかし商業的な娯楽作品には、クリエイターだけではなく、プロデューサーも絶対必要でしょう。 一般に企画でも他の仕事でも、他者の力や権威、その後の作業などに頼り切った態度は、どんな場所でも嫌われて批判されますし、それは職業の場だけではないでしょう。 また、ゲームの企画に関してもう一つの話題として、アメリカでも売ることに成功したドンキーコングの、ディレクターの宮本茂（任天堂）は、「人間の生理的なところを体感できるゲームを作れば、それがユニバーサル」、だと、語っていたようです<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P89</ref>。 ===「仕様書」、「企画書」=== 商業的なゲーム制作では、一般に、 発注 → 実装 → 調整 の過程を辿ります。 そして発注段階で重要な書類は、「企画書」と「仕様書」の二つです。まず『企画書』で作るゲームのコンセプトを固めてから、あとで『仕様書』で、より詳細に内容をを決める、という順序をとります<ref>『ゲームプランとデザインの教科書』、P43およびP45</ref>。 企画書<ref name="gcs72">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、72ページ</ref>は社内だけでなく協力会社にも見せる資料であり、開発者・協力者に対して手短かに、そのゲームの全体的なコンセプトを伝えるためのものです。 仕様書は、ゲーム制作では「設計図」であり、「完成予想図」であるといっていいでしょう。企画書よりより詳細にゲームの内容を決め、指定しています。 さて、話を進める前に、商業的に集団でゲームを作る場合の他の書類や必要事項の名称について、ここで簡単に書いておきます。 まず「発注書」とは，発注時に作られる、必要な書類群のことでしょう。「企画書」と「仕様書」も含みます。 「指示書」はむしろ、実装や調整段階でなされる、具体的なゲーム演出上の指定でしょうね。 試作品（しさくひん、英語で「プロトタイプ」proto-type）や企画会議（もしくは企画の打ち合わせ）なんて言葉も出てきますが、こういうのはあえてクドクド説明しなくても、直感的にイメージわきますよね。 『企画概要書』とは企画書とは異なるもので、仕様書に準ずる書類で、仕様書の方針を大まかに打ち合わせするためゲーム中の大まかな実装予定事項を記述している書類です。 『原案書』<ref name="gcs72" />は社内だけで企画がペイするかどうかの検討を決算書などを参考に分析・会議するための書類です。 こういう書類や用語に関する言葉の使い方は、商業的集団的なゲーム制作の場として妥当と思われるものをまとめてみましたが、もちろん職場によって、会社によって使い方や意味が微妙に変わってくる場合はあるでしょう。 さらにゲーム以外の一般IT業界や製造業でもそれぞれの慣習があり、今回の説明が成り立たない、そしてそこはより一般的な職場ですから、それぞれより一般的な言葉の使い方があると思います。 さて、コンセプトの具体例として、書籍『ゲームプランとデザインの教科書』によると、たとえば『ポケットモンスター』のメインのコンセプトは、「通信ケーブルを伝わって、ポケモンが入ったカプセルが移動して交換する」、が始まりだそうです<ref>『ゲームプランとデザインの教科書』、P109</ref>。 また、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、『メタルギア』シリーズのコンセプトは、「敵に見つからないように進む」、とのことですね<ref>吉冨賢介『ゲームプランナー入門』、P108</ref>。 イラストや音楽の発注は、一般的には企画が決まった後でしょう。 そもそもイラストレーションや音楽を対価を払って提供してもらったとして、それを実作品に使用しないのは、作者にとっては不本意なことだと思います。 アニメーターの故大塚康生氏は、アニメーション演出家が安易にアニメーターに大量の絵を描かせ、そこからいいもの、利用できるものだけ取捨選択する方法を批判していましたし、一般的に手仕事には作者の思い入れがありますから、安易な大量生産品と同じ取り扱いはできないと思います。 もっとも一方で、あるアメリカの日本人アニメーターが、同僚の日本人アニメーターが、自分の描いたものを日本の家族や友人たちが見ることができないことを不満に思っていた、という事を批判的に語っていたのを、現編集者は聞いたことがあります。 しかしゲームの場合、例外的にイラストや音楽が先行する場合はありますね。 RPG『クロノトリガー』は、企画の当初からイラストレーターをつとめた漫画家・鳥山明のイラストがあって、それをもとに作品を作ったと、鳥山のマンガの編集者であった元・少年ジャンプ編集の鳥嶋和彦は述べています。<ref name="tskdq">[https://news.denfaminicogamer.jp/projectbook/torishima/2]</ref>決めシーンなどのキービジュアルを先に決め、それに合うように設定を練りこんでいくという方式で、クロノは作られたようです。 企画書の制作ツールとしては、清書としては、オフィスソフトの「PowerPoint」と、アドビの「Illustrator」、または、アドビのソフトウェアは高価なので代わりにフリーソフトの「Inkscape」および「GIMP」がよく使われます<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日第1版第1刷、P.281</ref>。なお、Illustrator および Inkscape は、ベクトル画像を描画するソフトウェアです。 ただし、下書きなどでは、タッチペンと何らかの画像ソフト、またはタッチペン用メモソフトで下書きすることもあります。 業界で、ゲームプランナーと呼ばれる職種は、仕様書作成や進捗管理、テスト&デバッグ、スタッフとのコミュニケーション、などが仕事ですね<ref>『ゲームプランとデザインの教科書』、P.9</ref>。 また、ゲーム制作に関して、だれもが様々なアイディアを持っていると思いますが、メモを取って、もし忘れてもメモで思い出せるようにするといいですね<ref>『ゲームプランとデザインの教科書』、P.20</ref>。 アマチュアの企画なら、実際にプロトタイプ（プレイできる試作品のこと）を作って実作品で企画、仕様を説明してしまったほうが早いかもしれません。 参考文献『ゲームプランとデザインの教科書』でも、（試作品を）「ゲームプランナーを志す中で企画書や仕様書を書きながら、ぜひ自分でも作ってみましょう。プログラムや3Dモデルを簡単なものでいいので作ってゲームに仕上げてみましょう。」と述べています<ref>『ゲームプランとデザインの教科書』、P.3</ref>。 上記の本の図表によると、企画書では、「競合情報」、「世界観」、「ストーリー」なども記述して欲しいようです<ref>『ゲームプランとデザインの教科書』、P.43 </ref>。世界観とストーリーが分けられているのです。 物語とその舞台ですね。我々自身もこの世界で自分という役を演じている役者ですよね^^ {{コラム|ゲームの企画書とアニメーションの企画書| 商業アニメーションの世界では、企画の段階でストーリーの概要が決まっているようです。ただこれは、アニメーション作品の企画として、当然に必要とされる要素であるから記述されているわけで、実制作の過程で、実際のスタッフの意向により大幅に変更されることもあります。また、これらの企画では、キャラクター設定やキャラクターイラストのデザインも当然必要であり、かなり明確な形で提出されています。 たとえば、アニメ業界の企画書ですが、1990年代のアニメ『新世紀エヴァンゲリオン』の企画書の掲載されている『新世紀エヴァンゲリオン (ニュータイプ100%コレクション) 』（1997年2月28日初版発行、85～88ページ）を読むと、『企書画』の段階でもう、キャラクターイラストが主役だけでなくその友人や周囲の大人なども含めて、ほとんどのキャラクターでイラスト紹介されており、さらに全部の話数ぶんの粗筋と見せ場・意図を2～3行ていどで説明しています（ただし第1話と最終3話（24～26話）のみ説明が5行以上くらいと長い）。 因みに現編集者は実際にアニメーション業界で企画書を書いたことがありますが、その時に上司、制作会社の重役に指摘されたのは、1クール（3か月）か2クール分の実際のストーリーの具体内容を書いてほしい、との事でした。 一方ゲーム業界では、そういうキャラクター設定やストーリーは、企画段階では決まっていなくて、もし書かれていても邪魔だと感じられるようです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、149ページ</ref>。 業界の企画書で、強調してほしい内容とは、ゲームシステムと、そうシステムを設計した根拠のようです。なぜなら、ゲームの企画書でいう「コンセプトが重要」、と言う際の「コンセプト」の意味とは、ゲームシステムやゲームルールを設計した根拠のことだからです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、108ページあたり</ref>。 とはいえ、ゲーム業界の企画書でも、ゲームの世界観が「中世西洋ファンタジー風」なのか、「現代日本」か、「近未来SF風」なのか、などの設定はある様です。ネット上で公開されている商業ゲ－ム企画書からその様子が分かりますが、しかし、最初の企画書の段階で決まってる世界観はその程度まで、です。 背景としては、ビジネスモデルが根本的にアニメーション業界とゲーム業界とでは違う、という事情があるのでしょう。 }} {{コラム|キャラクター重視の物語論| アニメ―ション業界のビジネスモデルは、キャラクタービジネスだと言われています。1990年代の徳間書店のアニメーションに関する書籍（アニメージュ10周年記念）で、徳間の編集者が1980年代のアニメ業界を振り返ると、これはキャラクタービジネスだろうと、たとえば銀河鉄道999のアニメ―ションの人気も、メーテルなどのキャラクターの人気なのだという分析があり、アニメージュ創刊当時の『銀河鉄道999』特集では、ストーリー解説ではなく、キャラクターに焦点を当てた記事を組んだと、述懐（じゅっかい）しています。 また、漫画産業もキャラクター重視のようです。主人公に共感させるための様々な演出が凝らされている。そして主人公が身近に感じられることが重要だと指摘されています<ref name="tskdq" />。 これは日本人が物語軽視というよりは、海外でも同様であり、むしろ物語とはキャラクターを描くという要素が非常に大きいという事でしょう。多くのミステリの中でも「シャーロック・ホームズ」や「007」の人気が非常に高いのも、キャラクター性と結びついた作品だからでしょうね<ref name="tskdq" />。 1982年頃『鳥山明のヘタッピマンガ研究所』では、おおむね「マンガとは人間を描くことだ」という主張がなされています。 現編集者の記憶では、漫画がキャラクターだという主張を強くしたのは、漫画原作者であり、劇画村塾の開設者である、故[[w:小池一夫|小池一夫]]氏でしょう。上述の書籍の共著者、さくまあきら氏も、劇画村塾出身ですから、さもありなんということですね。 アニメ評論家の岡田斗司夫氏は、対談集『マジメな話』で、「古代ギリシア人や古代ローマ人はとても論理的で学問も発達していたが、一方でギリシア神話やギリシア悲劇が普及していた、人間には物語が必要なのだろう、自分達の社会の仕組みを、物語になぞらえて理解する、物語が学問や科学に匹敵する」といったことを述べていました。 ギリシア神話では実に人間的な神々の物語が語られていきます。 また、政治学者小室直樹氏は、別の書籍、おそらく、『日本人のための宗教原論』あたりで、「幼少期の子供にとっての、父親の力強さと畏怖のイメージ」こそが神のイメージだろうと述べています。ギリシア神話の最高神ゼウスは、明らかに父性を示していますよね。 これはユダヤ教やキリスト教の神のイメージだと考えてもいいと思います。この辺[[w:父なる神]]あたりに面白い記述がありますし、一方でイスラム教は神に父性を見出さない、などの興味深い分析も書かれています。 また、RPGゲーム『真・女神転生』では、裏設定ですが、作中の「悪魔」とは、力の象徴であり、それは父親を暗喩しているというコンセプトがあります（たしか公式ファンブック『CLUB邪教の館』あたりに記載がある）。だからこのゲームの主人公は、父親がいない母子家庭の子供だという事になっています。 }} {{コラム|ゲームにおけるキャラクター| ゲームの世界は、ソーシャルゲームや美少女ゲーム等はありますが、一般的にはキャラクター重視のメディアではないようです。シューティングゲーム『ゼビウス』のキャラクター性とか、『平安京エイリアン』のキャラクター性など、想像力を最大限に駆使すれば見出せないことはないですが、常識的にはキャラクターの魅力は提供されてはいないでしょう。 ゲーム学という概念を推進している人達は、ナラティブ（「叙述」という意味）といって、スーパーマリオなどのように作中にストーリー説明文が無いゲームのことを説明しているようです。 今現在では、可愛いキャラクターや恰好いいキャラクターを作品に取り込めるのなら、それを除外する必要はないでしょう。しかし現実の人気ゲームでは、キャラクター性があいまい、あるいはほとんど見出せないゲームも多いですよね。 ゲームのキャラクターは、開発途上で変更される可能性もある。海外展開しているゲームは、相手国の風習、社会状況に合わせて、キャラクター設定を変える場合もある。 今現在は、ソーシャルゲームでもキャラクターゲームは人気ですが、昔はそうではありませんでした。1990年代は、多くのゲームファンの間では、「キャラクターゲームはつまらない」と言われていました。 2002年にシリーズ発売開始されたRPG『ドットハック』シリーズの企画コンセプトは、面白いキャラクターゲームを実現することであり、2003年当時の社長（松山洋）がラジオ番組『ドットハックレイディオ』に出演した時に、「キャラクターゲームがつまらない」という一般的に言われている常識を打破したい、それがコンセプトだ、と述べていました。 しかし実際には1990年時点で魅力的なキャラクターゲームもありましたし、大ヒットすることは無くても、一部の大きな人気は得られていたようです。 }} {{コラム|企画が実制作に移ること| 1990年代後半に書籍を出し始めた、元ゲーム業界人・阿部広樹氏は、ゲーム会社から請け負って、そこで頓挫した、或いは難航した企画を練り直しする仕事をしていたようです。彼の著作ではその経験、経緯が語られています。 扱った一つの企画が、ガンダム風の巨大ロボット操作ゲームで、企画として完成度の高いものでした。 主要機体の巨大ロボットのグラフィック設定画は線画が完成していて、機体パイロットである主人公の顔グラフィック線画もある、ロボットの設定サイズ（「全長○○メートル」、「主要武器：○○」など）なども含む、仕様書がすでに用意されていました。 機体の名前には「メタトロン」や（たしか）「サンダルフォン」と、ネットの普及していなかった当時では調べるのにも手間のかかるユダヤ教の大天使の名前がつけられていました。 阿部氏も、このゲームは実現するだろうと、期待を込めて企画を進めていたようです。 しかし現実にはこのロボットゲーム企画は対象のゲーム会社では採用されず、実際に制作されることはありませんでした。このようにゲームの企画は、企画だけで終了してしまうものが沢山あります。 一般的に商業ゲームの製作は、本当にペイするかどうか、経営者や出資者の審査、判断の上、実制作に取り掛かるでしょう。 企画を作る方も仕事として取り組んでいるのですから、「没になるかもしれない」といって手抜きするはずもなく、内容的にも、前設定の完成度としても、どれも相当の力と手間暇をかけて企画を練りこんでゆくでしょう。 しかし結果は結果としてありますよね。採用される保証はないしされないほうが実際多い。その判断が正しかったかどうかはまた別の話ですがね。 }} {{コラム|他業種、一般的な意味での『企画書』| 企画書にもいろいろな段階があります。 #本当に企画の初期段階の、内部関係者しか見ない、思いつきを書きなぐったような企画提案の書類（厚さはせいぜい2～3ページくらいまで？） #企画が熟成してスポンサーや外部に見せられるようになった段階、もしくはその直前くらいの企画書（10ページを超える程度） #パワーポイントなどを使ってプロジェクタ－で見せるプレゼン資料の「企画書」 多くの業界の企画書で学生や外部の人間が見るのは 2.か 3.でしょう。 1990年代後半のゲーム評論家の阿部広樹の他者との共著による書籍によると、彼はゲーム業界で企画に関するトラブルを解決する仕事をしていたようですが、ある案件で、「当時の人気アニメ声優を起用！」など書かれた企画書をトラブル解決のために扱いましたが、彼らが調査した時には相手先のアニメ声優および声優事務所には全く話が行っておらず、対応にも難航したようです。ただ、本Wikiの別の場所でも指摘しましたが、企画時点では、その手の手続きを踏む必要はないでしょう。企画は企画にすぎませんし、実現の見通しが大きくはないその時点で話を持ってこられても、声優も事務所も、対応しようがないと思う。ただ、前編集者の記述では、許可をとれそうな見込みもないと書いてあるから、よほどのビッグネーム声優、要するにその声優の知名度だけをあてにしている企画ですから、悪い企画の例として非難されても仕方ないのかもしれません。しかし現編集者がさらに邪推、想像するに、彼らに企画トラブルの解決を依頼したゲーム会社は、自分たちは零細で知名度もパワーもないので、とてもその有名声優にはアクセスできない、ですからトラブル解決を稼業にしている業者なら、上手にその声優にアクセスしてくれるのでは？という期待があったのではないでしょうか？だとしたら、この事案に対する阿部氏らの態度、そして後になってわざわざ自らの著書でその出来事、関係者を愚弄して、それで自分たちが正しいかのように言うこの人物の姿勢は、職業人、仕事人として問題があるのではないでしょうか？ さて、ある程度企画が本格化してくると、スポンサーに提示するプレゼン用の資料とは別に、詳細な設定や企画意図を説明する、「詳述企画書（ここでの仮の名称）」も作られていきます。この書類は今後の作業のためのひな型の意味もあり、具体的にどんなキャラクターが出てくるか、イラストなども描かれます。 因みに、「ゲーム　企画書」でグーグル検索してみると、企画書としては 1.~3. そして今書いた「詳述企画書」が混然と表示され、書類として種類や趣旨は明確化されていないようです。企業が求職者を採用するために、企画書を求める場合は、プレゼン資料が最適のようですね。採用担当者にとって一番読みやすい資料だからでしょう。 企画書として、説得力のある内容なら、採用され実制作に移る可能性も高くなるのでしょうね。そのために指摘される事として、冒頭部分で、この企画と既存の作品の違い、今までの状況からの改善点、そして実際の改良の実現の見通しと方針を示すといい様です。これは「企画意図」や「コンセプト」と呼ばれますね。 「改善点→（競合他社の）現状説明→改善案の詳細」を、詳細企画書で段階的に説明するといいですね。新聞記事の書き方で、起承転結ならぬ「結・起・承」（けつきしょう）というのがあるので、それを参考にするのもいいでしょう。 また、売り込み先の消費者として想定しているターゲット層の指定も必要です。年齢はいくつくらいなのか、性別は男性か女性か、などですね。 企画の詳細を作りこんである場合や、すでにゲームソフトを実装してある場合のシステムの説明では、単にフローチャートを図示するだけでなく、そのシステムでプレイヤーは何ができるのか、簡単な遊び方の概要説明、等を加えるといいですね。 }} {{コラム|日産自動車の社内講習でのアニメーション業界人の講演| どこの企業でも社員向けの講習会はそれなりにあるでしょうが、日産自動車では過去、アニメーション制作会社の幹部を招いて、営業マンや企画職の社員のために講演してもらったことがあるようです。 テレビアニメーション『輪廻のラグランジェ』が2012年に放映されていた前後、日産が取材協力として制作に参加していたので、CG雑誌で、日産の講演会の様子が紹介されていました。 アニメーション業界では、実在しない物体や機械のイメージを、メカニック設定などで詳細にイメージを作り、絵コンテマンや、原画・動画のスタッフ間でその具体設計を共有するので、自動車製造業界でも参考になる要素があると考えられたようです。 日産の担当者は、制作会社の幹部の講演会に手ごたえを感じたので、もっと話を聞かせてほしいと要望すると、『輪廻のラグランジェ』の製作会社を紹介してくれたので、その会社にも講演をお願いし、さらに制作会社側の取材協力にも積極的に応じて、異業種同士のコラボレーションが形成されていったようです。 }} さて、ゲームの『仕様書』はそのゲームの設計図なので、起こりうる全てのパターンを網羅して設計を指定する必要があります…と言いたいところですが、そもそも本当にすべての操作に対する反応をもれなく記述できるのか? しかしできる出来ないにかかわらず、創作物が世に出れば、それはコンピューターアプリケーションとして、ユーザーに自由に操作される。その時仕様と創作物が、合理的に網羅的に作られていれば、プレーヤーはストレスなく、ゲームを楽しむ事が出来るでしょう。 ;検品、検収 さて、一般に技術系の業界では、図面などの設計図は、検品のさいのチェックリストを兼ねています。（ただし、ゲーム業界での「仕様書」が検品チェックリストを兼ねているかどうかは、2022/01時点、著者側の調査不足で不明。） しかし検品自体はゲーム業界でも行っている。協力会社から納品されたプログラムも、仕様を満たしているかチェックするだろう。 そしてチェックを通ったら、合格した製品として正式に受け取る。 納品物を合格として認めて受け取ることを「検収」（けんしゅう）という。（ゲーム業界でも）<ref name="creator_work:77">蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、77ページ</ref>。ゲームの仕様書は、この検収を考慮に入れて書くのがいいだろう。 つまり逆に納品物が合格していないと判断されると、受け入れない、検収しない、納品者に作り直しを要求することになるだろう<ref>蛭田健司『ゲームクリエイターの仕事』、翔泳社、2016年4月1日初版第1刷発行、76ページ</ref>。 商業ゲーム界では、営業マンが見積もりをするときの根拠は、仕様書、という事になる<ref name="creator_work:77" />。 外注テストに関しては、仕様書では不十分で、テスト用の別資料を用意する<ref>『ゲームプランとデザインの教科書』,P9</ref>。 バグチェックを外注しない場合は、「仕様書」を根拠にする場合が多いという<ref>吉冨賢介『ゲームプランナー入門』、P20およびP199</ref>。 つまりやはり、製品の仕様の基盤は仕様書、正しい仕様は、仕様書に書かれている事だという事になる。 開発後半のデバッグ段階などのバグチェックの段階に入る前に、仕様書を最新のゲームの状態とそろえる<ref>吉冨賢介『ゲームプランナー入門』、P238</ref>。つまりこれは、ゲームの仕様が制作過程で変わっていったら、逆に仕様書を書き換えて、実際の仕様に合わせるという事だ。 ==作成工程== ===完成予想図=== 仕様書はゲームの設計図。この書類を基盤にプログラマー、グラフィッカー、製作スタッフたちは作業を進める。しかし、ゲームの場合は、いきなり完成図を明確に決定するのは困難な場合が多い。そうなると方便的に大まかな設計、決定を作っていくという事になるだろう。事実、現実の業界では、大まかな「企画概要書」から詳細な「仕様書」へと、段階的に仕様が決まっていく<ref>『ゲームデザイン プロフェッショナル』、P.141</ref>。 一般的な製造業でもゲーム業界でも、あいまいな指定は事故のもとだと考えている。「とにかく、かっこいい感じでお願いします」なんて言いたくなることもあるけど、危険らしい<ref>『ゲームデザイン プロフェッショナル』、P.60</ref>。相手の「かっこいい」のイメージが、有り得ないものだったりする場合、あるよね^^;;;。 しかし場合によっては例外もあるようだ。裁量とか、阿吽の呼吸といったものも、人間関係ではある。しかし技術を語る場合、設計とは極力あいまいさは排除するものだろう。 ゲームでは、他者に発注するときは、ある程度相手の裁量にゆだねた方が良い場合もある<ref>『ゲームデザイン プロフェッショナル』、P.134</ref>。しかしその場合も、具体的にどういう実装予定のもので、どこに裁量を与えるのか明確にする必要があるという。裁量の発注については、『ゲームデザイン プロフェッショナル』本書を読めと、前編集者は書く。 とにかくこの編集者によると、Wikibooks をはじめ、Web上のWiki には何の価値もないと言う。世の中唯一価値のある文献は市販されている書籍で、Wikiの利用意味はその価値のある素晴らしい書籍を、出典としての記述を参考に、知ることだと言う。 それなら、Wiki書くのなんて辞めて、本屋でも始めたら? === 各機能の完成予想図の決定稿 === ゲームソフトにかぎらず、なにかのソフトウェアの完成予想図を描くとき、それぞれの画面を基準にして書くと、相手に伝わりやすいようです。 おそらく、人の目で画面は見えるので、集団内で確認を取りやすいのでしょう。 たとえば、 <pre> △△モードの××画面 Aボタン: ダッシュ（走る）。押すとキャラが十字キーの選択方向にダッシュするようにプログラムする Bボタン: ジャンプ。押すとキャラが上方向にジャンプするようにプログラムする </pre> のような、それぞれの画面・モードでの機能の満たすべき情報の一覧の書類を作業者に伝えると、良いかもしれません。 IT用語では、このように、ソフトウェアをユーザー視点でも見たときに製品がどういう条件を満たしているべきかを指定した仕様のことを（IT用語では）「外部仕様」と言います。 なので、ソフトウェア設計者は、すべてのモードについて、こういった（画面仕様などの外部仕様を中心とした）一覧を用意する必要があります。 これが、プログラマーにとっての完成予想図になります。 なお、（外部仕様でなく）「内部仕様」とは、ソースコードがどうなってるか、という仕様です。 ゲーム業界では原則的に、内部仕様については、書かないようです。 ただし、実際は程度問題であり、設計しようとしている項目がプロトタイプのどのファイルや変数に相当するかがゲーム『仕様書』に書かれるのが通例だと、ネットでは言われています。 さて、外部仕様について、「画面仕様」のほかにも「外部仕様」があります。ゲームの場合、アクションゲームのモンスターの動き方のパターンも「外部仕様」であり、あるいはRPGのダメージ計算式も「外部仕様」であり、なぜ外部仕様かというとプレイヤーから見たら確認できるので（つまり外部仕様であるので）、ゲーム仕様書では、それらの仕様（敵の動き方、ダメージ計算式など）も指定することになるでしょうか。 ゲームの仕様書はけっこうな割合が画面仕様が中心的になりますが、しかし画面仕様の他の外部仕様もゲームの仕様書では指定する必要があるので、そこは気をつけてください。 == ※ 例 == 完成予想図どうしでは、説明はあまり重複しないようにする必要があります。 なぜなら、もし重複させて他の書類の参照をすると、もしその参照された側の予想図Aで設計内容の変更が起きたときに、参照する側の予想図Bにも設計変更が必要になってしまいます<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、228ページ、</ref>。 なので、完成予想図では、説明のための重複は不要です。これは、製造業の製図でも同様です。製造業でも、ひとつの末端部品の図面では、他の図面は参照しないようにします。 さてゲーム業界の話題に戻りますが、学生にはこのような完成予想図の考えかたは、ちょっと分かりづらいと思いますので、たとえばウディタのサンプルゲームを具体例をあげて、説明します。 仮に、このウディタのサンプルゲームを、新たに仕様書として書き起こすとしましょう（仮にですよ。すでにソフトはあるので実用的には、もうサンプルゲームに仕様書は不要です）。 たとえば、ウディタのサンプルゲームは、メニュー画面で、上から順に :相談 :アイテム :特殊技能 :装備 :システム :セーブ というふうに6つのコマンドがあります。 上から4つめに「装備」というのがあって、それにカーソルを合わせた状態で決定ボタンを押すとキャラクター選択に移り、十字キーで目的のキャラクターを選択して決定ボタンを押すと、装備画面に移ります。 さて、もしこれを仕様書にする場合、たとえば装備キャラクター選択の仕様での説明の文章では、あえて、 【'''装備キャラクター選択画面'''】 '''遷移直後の変化''' メニュー欄に「装備」コマンド位置に決定後カーソル画像「○○○.bmp」を表示。 キャラクター選択欄のカーソルの点滅が開始。キャラクター選択用の点滅用カーソルの画像は「△△△.bmp」。 '''ボタン押の反応''' キャラ選択欄で十字キーの方向にいる隣または次のキャラクターを選択でき、そのキャラの選択欄にて点滅カーソルが点滅表示される。 決定キーを押すと、選択中キャラクターの『装備部位の選択画面』に移る。 キャンセルキーを押すと『メニュー画面』に移る。 '''画像リソース''' ○○○.bmp :メニュー欄用の決定中カーソル画像 △△△.bmp :キャラクター選択欄用の点滅用カーソル画像 という感じの、その画面とやりとりする相手先の画面の名前と、あとはその画面の読み込むファイル等しか、他の画面や他ファイルについては書かないほうが良い、というワケです。 :※ 実際はもっと多くの変化がウディタのサンプルゲームであるだろうが、説明のため単純化している。 :※ 上記の仕様書の書式の参考文献として、吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、221ページ、の例『各画面の仕様書の例』の書式を参考にした。 ついつい学生さんとかだと、 『装備部位の選択画面』に移ったあとの説明も続けて書いてしまいがちです。しかし、そういうのは別途、たとえば『装備フロー仕様書』みたいな仕様書を作成せよ、と考えるのが良いでしょうか。 なぜ別途に分かるべきかというと、もし仕様変更で、『装備』コマンドの位置が（サンプルゲームでは上から4番目だが）上から6個目に変わったりしたら、「メニューの装備コマンドは上から4番目にある」と書いた書類は全部作り直しになってしまいます。 そういう修正時の書類の作り直しの手間を省くため、あえて書類をモジュール化するのです。当然、そのままでは全体像は把握しづらくなりますが、しかし全体像の把握については、さらに別の全体像把握のための専用フローチャートなどを書類に設けるなどして補うことによって、修正の手間がなるべく波及しないようにします。 さて、「装備フロー仕様書」みたいなのを作るときは、たとえば '''装備フロー仕様''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 のようになるでしょうか。 ::なお、フローチャートの作図をしたい場合は、オフィスソフトのパワーポイントの図形描画の機能で作図が可能です。 ::またなお、フローチャートの描き方はJISで決まってるので、ソレを参考に。というか中学校の技術家庭科でも習う。 また、ウディタのサンプルゲームの装備部位の選択画面では、 :右手 :左手 :身体 :装飾1 :装飾2 と5つの項目があります。 もし仮に仕様変更で、部位の名称が変更され、 :武器 :盾 :頭 :身体 :腕 :装飾 とかに名称の仕様が変更したりすると、「装備部位の選択画面の「右手」選択にカーソルの合わさった状態で移る」とか書いた書類は、すべて作り直しです。 なので、『メニュー画面』とか『キャラクター選択画面』とかでは、そういう他画面である装備部位選択画面についての個別具体的な項目の名称（「右手」とか「左手」とか）や移り方の詳細は書かないで、キャラクター選択画面の仕様では単に「選択中キャラクターの『装備部位の選択画面』に移る。」と遷移先の画面名だけを書くべきか、あるいは「画面の変更時は原則、その画面のいちばん上のメニュー項目にカーソルの合わさった状態で画面が移る」とか、どこかの仕様書に書いておいて、あとはその説明を今回も引用するかすればいいだけです。 また、装備コマンドのフローを書くときは、 あまり、 :マップ画面 → キャンセルボタン → メニュー画面 → 「装備」を選択で決定ボタン → キャラクター選択 → 決定ボタン → 装備品選択画面 と設計図の段階では、続けて書くべきではないでしょう。 こういうのは、意味のある内容ごとにいくつかにフローを分解し '''メニュー選択フロー''' 【 マップ画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 メニュー画面 】 というメニュー画面を選択するためのフロー仕様書と、 もうひとつのフロー図面は、 '''装備関係フロー''' 【 メニュー画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 キャラクター選択画面 】 決定ボタン ↓ ↑ キャンセルボタン 【 装備品 選択画面 】 という装備関係のフローとに2分割するのが良いでしょうか。 このように、意味的にまとまりのある単位ごとに階層をフロー分割するのが良いでしょう。 かといって、階層を5分割とか10分割とかすると、まるでゼネコン多重下請けみたいになって、かえって見通しが悪くなりますので、なるべく2分割までにするのが良いと思います。（せいぜい3分割まで） さて、フロー同士の関係の記述では、別途、 【メニュー画面仕様】 '''表示項目リスト''' 決定ボタンで下記の項目を選択できる。 ・相談　　　　　　:決定すればメニュー相談フローに移行 ・アイテム　　　　:決定すればメニューアイテムフローに移行 ・特殊技能　　　　:決定すればメニュー特殊技能フローに移行 ・装備　　　 　:決定すればメニュー装備フローに移行 ・システム　　　　:決定すればメニューシステムフローに移行 ・セーブ　　　 　:決定すればメニューセーブフローに移行 '''非表示項目''' ・キャンセルボタンでマップ画面に戻る とでも書いておけば済むでしょうか。 なお、各画面での遷移先の画面の説明と、フロー図での遷移先の画面との説明が重複していますが、これは実務でも構いません。 参考文献の 吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』の209ページ「状態遷移フローの例」と211ページ「各画面の仕様書の例」とでも、遷移先の画面の説明はそれぞれ重複しています。 ;一枚の図面の中では内容重複はオッケー なお、一枚の仕様書の中では、内容の重複はオッケーです。 たとえば、機能の似たモノを2個つくるとき、 2個目の説明では、「○○については△△と同じ」のように、「～～～と同じ」というふうに説明できるから、です<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ、</ref>。 なぜなら、この場合なら、他の図面を参照する必要が無いので、一枚のその図面の中で完結するからです。 しかし、この場合でも、なるべく二回目以降の説明では「○○については△△と同じ」のように、「～～～と同じ」というふうに説明すべきです<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、229ページ、</ref>。 あまり、具体的な仕様の文は、二度目からは掲載しないほうが良いのです。 なぜなら、もし参照先である一度目の説明の仕様に設計変更があると、もし具体的な仕様の文を2度目以降にも掲載した場合には、修正のさいに二度目・三度目の説明も修正することになってしまいます。 で、よくミスとして、二個目以降の修正をし忘れるミスがあります。 ;その他 暗黙の前提ですが、画面名やファイル名などの名前を決める際には、具体的な名前をつけましょう<ref>吉富賢介『ゲームプランナー入門 アイデア・企画書・仕様書の技術から就職まで』、技術評論社、2019年5月2日、213ページ、</ref>。 たとえば、上述のウディタのサンプルゲームの画面をもしアナタが命名するなら :「マップ画面」、「メニュー画面」、「装備キャラクター選択画面」、「装備部位選択画面」などのように、です。 当然のことのように思えますが、しかし、おそらく新人にこういう図面を書かせる仕事を依頼すると、新人によっては、「画面1」、「画面2」、「画面3」、…のような具体的でない名前をつける場合があります。 あるいは、「メイン画面」、「メニュー画面」、「サブメニュー画面1」、「サブメニュー画面2」、…というパターンも考えられます。 しかし、そのような抽象的な命名は他人に伝わりにくいためやめましょう。 ===== 要求事項書はゲーム業界では書かない場合もある ===== IT業界でいう「要求事項」とは、顧客などから、完成品の満たすべき要件を聞き取ったりしたりして、完成品の満たすべき要件をまとめた書類のことです。 しかしゲーム業界では、ゲームプランニングの書籍を読んでも要求事項書は紹介されてない状態です。（たとえば『ゲームプランナー入門』（吉冨賢介、技術評論社）や『ゲームプランナーの新しい教科書』（STUDIO SHIN著、 翔泳社）などを読んでも、『企画書』と『仕様書』は触れられていても、要求事項書については全く触れられてない。） 個人製作のゲームでは、要求事項書は、まず不要です（自分で作ればいいので）。 個人製作では要求事項は不要ですが、比較のために下記に概要を記載しておきます。 まず、要求事項書は、発注者と受注者の両方の打ち合わせによって書きます。 なおゲーム業界でも、（要求事項書ではなく）発注書ですので立場は逆の種類ですが、その発注の成果物が作中でどういう目的で使われるのかなどの意図・用途を伝えるのが良い<ref>『ゲームデザイン プロフェッショナル』、P296</ref>とされています。 ==== データ暫定値 ==== ゲーム中の、たとえばRPG武器の「攻撃力」などのデータの数値は、あらかじめ作者が、すべての項目の想定値を具体値で設計図に記述します <ref>[https://www.youtube.com/watch?v=KVdtNiB_lIQ 【ゲーム企画】 ゲーム仕様書の書き方 - YouTube] ゲームのしくみチャンネル、2015/12/11、 2020年3月14日に閲覧</ref>。 CSVファイルなどでエクセルなどで記述しておきます。 【剣データ暫定値】 銅の剣: 攻撃力 7 鉄の剣: 攻撃力 18 ハガネの剣: 攻撃力 37 ミスリルの剣: 攻撃力 70 ほのおの剣: 攻撃力 57 （※ 剣ではランク5は欠番とする） デスブリンガー: 攻撃力 150 備前長船: 攻撃力 250 聖剣エクスカリバー: 攻撃力 450 魔剣レーヴァテイン: 攻撃力 450 みたいに、暫定値でいいので、とりあえずの具体的指示も必要です。 ただし、これはあくまで暫定的な値でありますので、今後の調整で変更する可能性があります。 ==== データ仕様書 ==== データ仕様書とは、たとえばRPGなら :攻撃力: 敵の守備力との計算によってダメージを算出する のようなパラメータ計算式の定義を行った仕様書のことです<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、92ページ</ref>。 そして、この「データ仕様書」は、デバッグのための資料になります。デバッガーが、この資料と実際の動作を照合することで、仕様どおりにプログラムが動いているかを確認します<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、92ページ</ref>。 どうもアイテム（「やくそう」とか「毒消し」などのアイテム）価格などの「100」（100ゴールド）とか「200」（200ゴールド）とかの具体値のあるデータ表のことをSTUDIO SHIN 氏は「仕様書」と言っている<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、261ページ</ref>。本当は「100」になるべき数値が「200」になっている場合、「仕様書」で簡単に確認できるとSTUDIO SHIN 氏は言っている。） 一般に、RPGの仕様書は、すごく分厚くなるといわれています。（アニメ評論家の岡田斗司夫が1990年代のむかし、彼の言うには、彼の伝聞によると、ある有名RPGの仕様書は、その書類の量の表現として（ページ数ではなく）キログラム単位で表現されるくらいだと言われています。岡田さんは彼の著書『オタク学講座』などの書籍で、そういった伝聞を述べています。有名作の仕様書だと、ちょっとした電話帳みたいに分厚くて重い書類が、場合によっては何冊かあるらしいです。おそらく、データ台帳に、攻撃力などのデータだけでなく、さらに設計の背景となる要求事項などもマトメて書いた上での重量でしょう。） ;攻略本と『仕様書』 ゲームの攻略本にある、アイテムの効果値や、敵の能力値などといった数値の一覧などは、おそらく、そのゲームのデータ台帳から、転記されていると思われます。 よく、「仕様書をもとに攻略本が作られる」と言いますが、しかし攻略本の制作に必要なのは、プログラム部分の設計図などではなく、実際に入力された各データを記載したデータ台帳のハズです。 ただし、実際には市販の攻略本には、記載ミスなどもあります。 また、制作側が情報を隠していたりして、攻略本に記載された情報と、実際のゲームプログラム内の数値とが違っている場合もあります。 == 他部署との連絡の仕事をするのは誰なのか == ゲーム業界では、プランナーと言われる役職の人が、連絡網の中心になって、いろいろな部署のあいだの情報伝達をします。 <div style="font-size:120%;"> <pre> ディレクター　━━━　プランナー　━━━━┳━　プログラマ 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　グラフィッカー 　　　　　　　　　　　　　　　　　　　　　┃ 　　　　　　　　　　　　　　　　　　　　　┣━　デバッガー </pre> </div> のような感じです。（ディレクターの上に、さらにプロデューサー、プロデューサーの上には社長などがいるが、省略する。） このプランナーは、ゲーム業界の場合、中間管理職のような権限もあって、各部署（プログラマ部署やグラフィッカー部署など）とディレクター（監督みたいな役職）のあいだのやりとりもします。 :※ 一般の企業での連絡網の場合については、企業ごとの差異が大きいので、説明を省略する。 「プランナー」というと、てっきりプラン「計画」を練る仕事化のように思いがちですが、しかし、どっちかというと、計画を練るというより、たとえばテレビ業界でいう「AD」アシスタントディレクターのようなイメージのほうが近いかもしれません。 実際、書籍『ゲームプランナー入門』（吉冨賢介 著）によると、プランナ－にはTV業界でいう「AD」のような側面があると述べています<ref>吉冨賢介『ゲームプランナー入門』、P236</ref>。 == イラスト・音楽などの外注や打ち合わせ == イラスト・音楽に限った話ではないですが、文献『ゲームデザイン プロフェッショナル』によると、発注フォーマットに業界共通のルールは存在しないので、だから開発する作品に適したフォーマットを考える必要があります<ref>『ゲームデザイン プロフェッショナル』、P.146</ref>。 また、発注の際には、発注の目的まで、発注相手には説明できることが望ましいとのことです。 何らかの発注をする際、事前にチェック項目リストを作る必要があります<ref>『ゲームデザイン プロフェッショナル』、P.159</ref>。 === 外注する場合 === 自分にイラストや音楽をつくる能力が無い場合で、イラスト素材や音楽素材の調達をしたい際、イラストレーターなどの専門家に外注することになります。 打ち合わせをする際、たとえばイラストなら、発注元の画力にもよりますが、 :構図、 :希望のポーズ、 :塗り方、 :テイスト、 などの指示が必要です<ref>『ゲームプランとデザインの教科書』、P.128</ref>。 あと、絵を書かない人が勘違いしがちなことですが、「イラストレーター」を名乗っている人は、あくまでイラストだけが専門的であるので、一般に、イラストレーターは漫画を書けません<ref>『ゲームプランとデザインの教科書』、P.128</ref>。アニメも作れません。 イラストも漫画も両方とも作れる人のほうが、希少ケースなのです<ref>『ゲームプランとデザインの教科書』、P.128</ref>。（たとえばアニメ業界のジブリの宮崎監督のような、イラストもアニメも漫画もかけるような人は、かなり例外的なケースです。） なので、イラスト、漫画、アニメ、などは、それぞれの専門家ごとに分けて注文なり依頼なりをすべきです<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 ゲーム作家によっては、キャラクターイラストの発注をするときはモデルとなるアイドルや俳優などの情報を添えて発注するゲーム作家もいます<ref>畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P168</ref>。 :ラフ画などを用意してどんなシーンでどんなキャラのどんな構図を書いてほしいか等の大体の要望を具体的に伝える、 というのも重要ですが、もうひとつ必要になるかもしれない事として、 :なぜ、その構図が作中でどういう目的で使われるのかなどの意図・用途を伝える<ref>『ゲームデザイン プロフェッショナル』、P296</ref>、 という事が重要です。 『ゲームデザイン プロフェッショナル』によると、発注の意図・用途を伝える際も、長いと意図説明が書類の場合は書類を読んでもらえないし、口頭でも相手の頭に入らないので、だから発注者は要点を短く的確な言葉であらわさなければあらないということです<ref>『ゲームデザイン プロフェッショナル』、P295</ref>。 個々から先は別に文献の内容ではないですが、そもそもなぜ用途を伝えるのが必要かというと、相手のほうがその分野ではプロだからですし、発注元は往々にしてイラストは素人だからです。 発注元が素人の場合、プロのイラストレーターに用途を伝えると、たとえば、当初に発注元の考えていた構図などが実は不適切である、という情報が返ってくる可能性もあります。 このようなフィードバックのある場合、発注元がデザインを再検討する必要になる可能性もあります。 そもそも発注元は、あまりイラストや音楽などの分野を知らないので、だからこそ事前の打ち合わせによる、デザイン意図の確認が必要なわけです。 つまり、たとえるなら「作業指示」と考えるよりも、どこかの営業マンとの事前の打ち合わせのようなものだと考えるのがイメージ的には適切かもしれません。 たとえば住宅をリフォームする場合なども、事前に何度もリフォーム会社の営業マンとの商談をして、イメージを共有するのが普通です。イメージ的には、これに近いのかもしれません。イメージ的には、イラストレーターとか作曲家などアーティストに対する外注・発注も、こんな感じでしょう。 ;その他 書籍『ゲーム作りの発想法と企画書の作り方』によると、アダルトゲームではシナリオも外注の場合が多くあるとのことです<ref>畑大典 著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P129</ref>。 ;発注されるイラストレーター側からの視点 これはイラスト－レーター側からの視点では、発注者の要求事項に従った絵を描かなければならないわけです。 だからもし、提出しようとする絵が、まったく要求事項に従えてなければ、ダメな絵となり、発注者は納品受け取りを拒否するので、絵はリテイク（書き直し）になります。 たとえば、アニメイラスト系絵描き向けの教本『クリエイターのためのおんなのこデータベース2008 -ファッション編-』によると、 もしイラスト発注の要求事項が「セーラー服の少女を描いてください」なのに、 もしイラストレーターがブレザー服の少女を描いて提出してきたら、 どんなに可愛く上手にブレザー少女が描けてようが、リテイクです<ref>『クリエイターのためのおんなのこデータベース2008 -ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日 初版発行、P.208</ref>。 イラストレーター向けの教本などでもきちんと教育されているように、まともなイラストレーターは、こういう社会のルールがきちんと分かっています。 裏を返せば、こういう社会ルールが分かってない絵描きは、自称「イラストレーター」です。 イラストレーターにとっては当然の、社会のルールだと思いますよね。しかし世間には、イラストレーター業界に興味ない人は、この当然の社会ルールが分からない人が、少なくとも2005年より前の昔は世間に多くいました（下記コラムで説明する）。 {{コラム|絵の仕事は自由業ではない| 根本的な問題として、さすがに最近は無くなってきたと思いますが、ほんの2005～08年ぐらいまで、 世間には絵の仕事を、「自由に絵が描ける」と勘違いしている人がいました。また、「漫画や絵の仕事は、競争を気にしなくていい」という類の、良く分からない勘違いもありました。 どうやら、勘違いの原因は、小学校の図工のお絵かきや、中学校・高校の美術の授業が、そういうなるべく自由なテーマで絵を描かせるので、どうもイラスト関係の仕事までそうかと勘違いをする人が、ほんの2008年くらいまで昔は少なからず居たのです。 さんざんマンガ評論やアニメ評論などで「漫画の打ち切り」だとか「アニメの放映打ち切り」とか言われても、あるいは評論誌など読まなくても友人どうしの雑談でそういう話をしても、しかしその「打ち切り」情報が脳内にある勘違い「小学校の図工のような自由な仕事 <nowiki>=</nowiki> プロ絵描き」という勘違いの修正に結びつかないようです。 だから漫画家の江川達也は苦言として、雑誌コラム（おそらく『SPA』）で2001～2005年ごろの意見ですが、当時のゆとり教育の賛成論者がなんだか漫画業界について「漫画家は、競争が無くて自由に漫画を描ける仕事」だと勘違いしているような言説が散見されたことに対し、江川は苦言でおおむね「漫画家はとても競争の厳しい世界だ。ふざけたことを言うな」といったような感じの批判を雑誌コラムで述べていました。 漫画家はプロデビューするまでだって競争がありますし、デビューしてからも不人気だったら打ち切りですし、競争はとても厳しいです。 漫画に限らず、どうも世間にはイラストレーターや漫画家を、なぜか競争のない業界だと勘違いしている人が好くなからずいます。昭和の時代は、漫画家を終身雇用だと勘違いしている人もいました。 昭和時代にデビューした漫画家の小林よしのりは、自身が漫画家プロデビューするまでは、勘違いで、「マンガ出版社は、漫画家が死ぬまで面倒を見てくれる、まるで公務員のような終身雇用の業界が漫画業界」だと思っていたと、著書『ゴーマニズム宣言』で自身の勘違いを白状しています。 それでも昭和の時代なら、まだ漫画業界がよく知られていなかったので、世間一般の終身雇用の常識に照らし合わせて勘違いしてしまうのも、無理ありません。ですが、平成が10年以上も過ぎた2001年以降にこの手の勘違いをしている人もおり、もう手の施しようのない人です。 }} === 絵の「クオリティ」とは === 何かのゲームデザイン本によると、「クオリティ」とは、イラスト発注などの言葉のようです。 その書籍では「クオリティ」の意味は説明していないのですが、ゲーム業界で言うクオリティと一般の英語のqualityは少々、意味が異なります。 ゲーム業界には、イラストや音楽などに対して「クオリティ」という言葉があります。英語ではqualityは「品質」という意味ですが、しかし日本のゲーム業界でいう「クオリティ」にもその意味はあるもののニュアンスはやや違います。 たとえばイラストの例なら、どんなに「ポーズと構図はこうしてください」とか「メインカラーはこうしてください」とかの発注要件を守ってイラストレーターが絵を描いて提出しても、しかしその絵の画風がターゲット層の消費者たちの好みの画風でなければ、ゲームが売れずにゲーム会社は商売になりません。 少なくとも2010年以降、ゲームファンの絵柄の好みは、素人では描けないような細密かつCG特有のグラデーションなどを活用した絵柄が消費者層の好みです。そういう求められた画風である細かい絵である素材を出せる能力のことも「絵のうまさ」と捉えて、ゲーム業界では「クオリティ」と呼んでいるようです。 逆に言うと、たとえばマンガ家の手塚治虫『鉄腕アトム』の原作のような簡素な絵でどんなに上手い絵をゲーム発注者に提出しても、おそらく「クオリティが高い」とは言われないでしょう。 絵の場合、昨今の消費者の好みが、細かく線を描きこまれたりグラデーションなどCG機能を多く使ったアニメ風イラストまたは細かいリアルCG風イラストといった絵柄なので、そういう絵がゲーム業界では「クオリティが高い」のように言われたりもします。 ;業界によって要求される画風が異なる ゲーム業界の絵を描く能力は、マンガ業界やアニメ業界で求められる能力とは異なります。 マンガ業界の場合、まず白黒印刷で表現できる絵柄でないといけませんし、印刷の解像度の問題もあるので、カラー表現は求められない場合も多いし、またグラデーションも利用が困難です。だからマンガ業界ではグラデーションではなく、スクリーントーンを使います。そもそも製作ソフトウェアからして、イラスト製作用ソフトではなく専用のマンガ製作用ソフト（『コミックスタジオ』など）を使ってマンガが描かれています。週刊マンガと月刊マンガでも、絵柄の傾向が違っています。試しに線画部分だけでいいので漫画を模写などをしてみれば分かると思いますが、週刊漫画の絵柄は比較的に短時間で模写できるような線の少ない絵柄になっている場合が多いえす。 アニメ業界の場合、動画マンが動画を何枚も描かないといけないので、原画ではなるべく1枚あたりの線を減らす必要があります。1枚イラストでは「撮影」と言ってCG処理などで光の表現などのためにフィルタ加工などもしますが、しかしゲーム業界と比較するとアニメ業界の手書きアニメ用イラストのCG処理は簡素な処理です。 ゲーム業界とアニメ業界では、人気の絵柄におけるCG加工の傾向が逆のことも多く、だからアニメ業界のような多くの人が真似して描けるようにデザインされた絵柄は、ゲーム消費者にはウケていません。 世間では美少女キャラの瞳が大きいだけで「アニメ絵」とか言いますが、しかし実際には瞳の大きい美少女キャラでも、アニメ業界とゲーム業界とマンガ業界とでは、求められているデザインがまったく違うのです。 アニメ業界とゲーム業界とで「原画」や「仕上げ」など共通の用語が使われる場合もありますが、内実、意味は違っています。 もっとも、近年ではアニメ業界もゲーム業界やライトノベル業界（雑誌媒体なら月刊誌である場合が多い）などの影響を受けて、細かい絵が増えてきました。アニメの原作がゲームやライトノベル作品である場合も多いので、そういう作品は当然、細かい絵が求められるわけです。 なお、アニメ業界の場合、細かい絵を描くことはクオリティとは呼ばずに「カロリー」と呼ぶことが多いです。どうやら栄養の「カロリー」由来の表現らしく、作画に求められる手間や負担というような感じらしいです。「作画カロリー」などといった表現もアニメ業界にあります。 細かい絵や、細かい動き、やたらと凝った動きや構図などを描く際、「この絵はカロリーが高い」のように表現するようです。 「クオリティ」という言葉を聴いているとあたかも「業界を越えて共通の絵のうまさがある」とでも錯覚するかもしれませんが、しかし上述のように要求される絵柄や画力は、業界ごとに違います。 ;週間マンガ・アニメの後日修正 なお、実は週間漫画は、雑誌掲載時の絵柄と、単行本掲載時とで、絵柄が微妙に違う場合があります。雑誌掲載時だと、週間ペースの掲載に追いつかせるために、省略できそうな背景などの書き込みを減らしている場合もあります。なので、実はそういう省略された部分を、単行本化に向けて後で、アシスタントや、専門の会社などが、細部を仕上げているわけです。 単行本の話ではないのですが、2012年ぐらいにBSあたりで放映されたマンガ業界特集番組では、実はマンガのアシスタント専門の会社が存在することを紹介しています。細かな統計は忘れましたが、その番組によると、現代（ただし放映当時の2012年頃）の漫画家の多くは、実は連載作家ではなくアシスタントとのことです。今のマンガ産業は、実は分業制なのです（なおアニメ産業は昭和後期～平成初期からとっくに分業制）。 アニメも、実はテレビ放映時とブルーレイ・DVDなどの円盤メディアとで、絵柄が少しだけ微妙に違う場合などがあります。放映後に細部を直すのです。 === マンガ・アニメ業界での「芸術」･「自由」の裏の意味 === 文献『ゲームプランナー集中講座』によれば、ゲーム作りに必要な資質としては、作家性<ref>『ゲームプランナー集中講座』、P246</ref>のほかにも「人を楽しませたいと思う気持ち」<ref>『ゲームプランナー集中講座』、P246</ref>が必要です。 また、同文献によれば、ゲーム会社では自己表現は求められていません<ref>『ゲームプランナー集中講座』、P246</ref>。もし本当に自己表現をした人は、ゲーム会社ではなく１人で芸術家を志望するべきだと文献『ゲームプランナー集中講座』では述べています<ref>『ゲームプランナー集中講座』、P246</ref>。 作家性は必要ですが<ref>『ゲームプランナー集中講座』、P246</ref>、しかし自己表現は求められていないという、バランス感覚が問われます。 ゲーム業界への就職では自分の作品があるとアピールポイントになり多くのゲームプランナー入門書でもプロトタイプなどの作品づくりを推奨していますが、しかし自己表現は求められていないことに注意する必要があります。 さて、ゲーム会社だけでなくイラスト業界やマンガ業界も、似たような見解です。 『クリエイターのためのおんなのこデータベース2008 -ファッション編-』によると依頼内容を無視して自由に絵を描こうとする人は、けっして「プロ」ではなく、それは「芸術家」だとのことです<ref>『クリエイターのためのおんなのこデータベース2008 -ファッション編-』、編著 おんなのこデータベース制作委員会、ジャイブ株式会社（出版社名）、2008年7月5日 初版発行、P.198</ref>。 ==== 「芸術」 ==== 「芸術」といえば、漫画『サルでも描けるまんが教室』では、漫画家志望者が芸術かぶれになることを、とても戒めています。 {{コラム|サル漫の芸術かぶれ回| サル漫の芸術かぶれ回では、作中の漫画家コンビのシナリオ担当の竹熊と作画担当の相原が、漫画の執筆中に、 芸術かぶれを煩った作画担当キャラの相原コージが、まず、おおむね「俺たちはこんなくだらない漫画を描いてていいのだろうか」みたいなことをつぶやきます。 それに対して竹熊が心配したか「どうした相原？」とたずねると、 相原の細かなセイルフは忘れましたが、相原は「俺たちはもっと本質的な作品を作るべきではないか？」とか 「資本主義などという下らない次元にとらわれてはいけないのではないか」とか、 「俺たちは国や大企業におどらされていてはいけない」とか、 なんかそんな感じのことを言います。 すると、竹熊はまず相原をぶん殴ったあと、 竹熊は「お前は芸術をぜんぜん分かっちゃいない！」と説教し、 相原が「そんなことない」というと、 竹熊が「じゃあ、お前のいう芸術とは何かと言ってみろ？」と問い詰めると、 相原が「それは、人間の内面の真実ってゆうか」とつぶやくと 竹熊はめっちゃあきれたような見下したような表情で、「にんげんのぉー、ないめんのしんじつぅ～」みたいにつぶやき返します。 そしてそのあと、竹熊はおおむね、 「お前は権威にとらわれてはいけないとはいうが、じゃあお前のその意見は、どこかの芸術大学の教授の権威にすがっているだけではないか！？」とか :「お前こそ、政府や商業メデイアによる宣伝のつくった権威にとらわれているだけじゃないか」とか、 :「お前は芸術教授の権威にあやかって自分も地位と名誉が欲しいだけだし、結局、お前はカネが欲しいだけなのだ。」 なんかそんな感じのツッコミをします。 このあとも竹熊のツッコミは続きますが、続きを知りたい方はサル漫を購入してください（ネタバレになるので続きは省略）。 ともかく、マンガ業界やアニメ業界でいう『芸術』には、こういう隠れた意味があります。 アニメ『新世紀エヴァンゲリオン』の総監督の人はサル漫の大ファンですし、総監督は竹熊とも対談したことあるので、つまりアニメ業界でも自称「芸術家」はまあ似たような扱いです。 }} ==== 「私小説」 ==== {{コラム|売り上げと文化は違う| 文学史でいう「私小説」と、マンガ・アニメ業界でいう「私小説」とは、意味が異なります。 現代でもアニメ評論などでは、「私小説」というのを否定的な意味で、「頭でっかちのインテリが書いた、世の中に文句を言ってるだけのことを、さも深い洞察かのように装うとしてるだけの、売れない小説」のような意味で使っていたり、あるいは「世間知らずの漫画家やアニメ監督の書いた、世の中に文句を言ってるだけの（以下略）マンガやアニメ作品の脚本みたいなもの」のような意味で使われることもあります。 たとえば1998年の岡田斗司夫の対談集『マジメな話』でも、当時のエヴァンゲリオンの映画版を「私小説」だと対談相手の推理小説家・今野敏（こんの びん）が批判していたりしました。「クリエイターよ、メッセージはあるか」というタイトルの対談です。 なお、名前の漢字が似ているアニメーター・今敏（こん さとし）とは全くの別人ですので、混同しないように。そもそも今敏はエヴァンゲリオンの制作スタッフの一員です。アニメーター・今敏は、全く、岡田とは対談'''していない'''です。 さて、文学史でも、売上と、後世に語られる作品が異なることはあり、たとえば大正文学の売上のベストセラーは、 :倉田百三『出家とその弟子』、 :島田清次郎『地上』、 :賀川豊彦『死線を越えて』、 が大正時代の三大ベストセラーですが、しかし今や彼らは文学史の教科書には、滅多にのりません。せいぜい高校日本史の教科書で、倉田が少し紹介されているくらいです。 現代の教科書でよく大正時代の小説家として紹介される芥川龍之介は、じつは当時は倉田・島田らほどには売れてない作家です。また、「私小説」といわれるジャンルは実は売れていません。（もっとも、芥川が私小説を書き出したのは晩年のこと。このコラムでは、芥川の伝記については立ち入らない。） 食い違いの原因は、芥川が小説連載していた大阪毎日新聞による芥川をブランド化するイメージ戦略の成功や、あるいは第二次大戦後になって教育界隈の左翼運動家たちが文学史を左翼イデオロギーに都合よく書き替えたことなどが考えられますが、しかし新聞社や左翼ごときに書き換えられるぐらいに戦前の文学史が研究不足であったことが、そもそもの根本原因でしょうか。 ともかく、「私小説」というジャンルは、そもそも大正時代の当時は、大して売れていません。 }} === ローポリ関連の作画 === 単元『[[ゲームプログラミング/3Dグラフィック#ローポリ制作手法的なこと]]』で説明した。 == レポートは結論だけを読んでも分かるように書く == レポートなどは、ゲーム業界なら、途中を読み飛ばしても、内容がおおまかに分かるように書かなければなりません。 別に冒頭で結論を述べる必要はありませんが（会社による）、しかし、仮に書類のページの順序どおりに上司が読まなくても、 レポート全体の内容を把握できるように書かなければならないでしょう。 == 中卒でも分かるように書類を書く == ゲームに限らないのですが、企業でレポートなど種類を新人などに書かせると、時々、教科書などを丸写しするような人がいます。しかし、そういう丸写しは、多くの企業で、一般的な企業では不要です。コードの解説というより、企業で何かの解説レポートを書く際の基本ですが。 書籍『ゲームデザイン プロフェッショナル』によると、ゲーム開発で必要なチーム内での言葉選びについては、「中学生の知識でも理解できる言葉を使うこと」とあります。そのほか、言いやすいフレーズを使うことも必要です<ref>『ゲームデザイン プロフェッショナル』、P101</ref>。 ぶっちゃけ、このwikiのこの科目の教科書のようなのは、中学生レベルの知識で読解できないので、ダメでしょう。読者は、このwikiを反面教師にしてください。 書籍『ゲームデザイン プロフェッショナル』は特に述べてはいませんが、企業というのは、従業員の過去の学歴や経歴がバラバラなのです。普通科高校を卒業して就職する人もいれば、業界に近い専門学校に入った人もいますし、商業高校や工業高校などに進学していた人もいますし、大卒や院卒もいます。 日本では高校進学率が100%ですが、しかし高校は選択科目などが多いので、共通知識はどの選択科目を選んだかで差異が多いので、なかなか高校を基準に合わせるのは難しい業種も多いのです（ただし、製造業なら工業高校卒のように、一部の業界では学校の種類を絞って基準にすることがある）。 なので、一般の多くの企業では、従業員がどういった学歴でも情報伝達が上手く行くように、中学レベルでも分かるような物言いが、企業では原則必要になります。大卒社員であっても、そういうふうに言い回しを直すトレーニングをしたりします。 == 脚注・参考文献 == 2azc6jz2glf6swhx3upfzgx5qvp9zux 0 28401 206060 205417 2022-07-31T14:36:44Z Linguae 449 /* そのほかの属格 -ūs型の名詞 */ cōnspectus wikitext text/x-wiki == 名詞の第四変化 == '''第四変化''' （羅 [[wikt:la:Auxilium:Declinatio Latina#Quarta Declinatio|Quarta Declinatio]] ； 英 ''[[wikt:en:Appendix:Latin fourth declension|Fourth declension]]'' ； 仏 ''[[wikt:fr:Annexe:Quatrième déclinaison en latin|Quatrième déclinaison]]'' ） は、名詞の数が多くはなく、第一変化～第三変化に比べると重要な変化ではないが、不規則な例外も少ない。 おもに、男性・女性名詞の 「 -ūs 型 」と、中性名詞の 「 -ū 型 」 からなる。 {| border="1" class="wikitable" |+ '''第四変化''' |- align="center" | colspan="2" | ! colspan="3" | -ūs 型 | rowspan="13" | ! colspan="3" | -ū 型 |- style="text-align:center;" | colspan="2" style="text-align:right;"| (名詞の性) | colspan="3" style="background-color:#fdf;"| 男・女 | colspan="3" style="background-color:#dfd;"| 中性 |- style="text-align:center;" | colspan="2" style="text-align:right;"| (単語例) ! style="background-color:#fdf;" |語尾 | colspan="2"| manus, -ūs 「手」 ! style="background-color:#dfd;" | 語尾 | colspan="2" | cornū, -ū 「角(つの)」 | rowspan="11" | ! colspan="3" |語尾比較 |- ! rowspan="5"| 単数 ! 主格 | style="background-color:#fdf;"| -'''us''' | man'''us''' | 一つの手'''が''' | style="background-color:#dfd;"| -'''ū''' | corn'''ū''' |一つの角'''が''' ! 主格 | style="background-color:#fdf;"| -'''us''' | style="background-color:#dfd;"| -'''ū''' |- ! 属格 | style="background-color:#fdf;"| -'''ūs''' | man'''ūs''' | 一つの手'''の''' | style="background-color:#dfd;"| -'''ūs''' | corn'''ūs''' |一つの角'''の''' ! 属格 | colspan="2" style="text-align:center;" | -'''ūs''' |- | style="text-align:center;" | 対格 | style="background-color:#fdf;"| -'''um''' | man'''um''' | 一つの手'''を''' | style="background-color:#dfd;"| -'''ū''' | corn'''ū''' |一つの角'''を''' | style="text-align:center;" | 対格 | style="background-color:#fdf;"| -'''um''' | style="background-color:#dfd;"| -'''ū''' |- | style="text-align:center;" | 与格 | style="background-color:#fdf;"| -'''uī''' | man'''uī''' | 一つの手'''に''' | style="background-color:#dfd;"| -'''ū''' | corn'''ū''' |一つの角'''に''' | style="text-align:center;" | 与格 | style="background-color:#fdf;"| -'''uī''' | style="background-color:#dfd;"| -'''ū''' |- | style="text-align:center;" | 奪格 | style="background-color:#fdf;"| -'''ū''' | man'''ū''' | 一つの手'''で''' | style="background-color:#dfd;"| -'''ū''' | corn'''ū''' |一つの角'''で''' | style="text-align:center;" | 奪格 | colspan="2" style="text-align:center;" | -'''ū''' |- ! rowspan="5"| 複数 | style="text-align:center;" | 主格 | style="background-color:#fcf;"| -'''ūs''' | man'''ūs''' | 複数の手'''が''' | style="background-color:#cfc;"| -'''ua''' | corn'''ua''' |複数の角'''が''' | style="text-align:center;" | 主格 | style="background-color:#fcf;"| -'''ūs''' | style="background-color:#cfc;"| -'''ua''' |- ! 属格 | style="background-color:#fcf;"| -'''uum''' | man'''uum''' | 複数の手'''の''' | style="background-color:#cfc;"| -'''uum''' | corn'''uum''' |複数の角'''の''' ! 属格 | colspan="2" style="text-align:center;" | -'''uum''' |- | style="text-align:center;" | 対格 | style="background-color:#fcf;"| -'''ūs''' | man'''ūs''' | 複数の手'''を''' | style="background-color:#cfc;"| -'''ua''' | corn'''ua''' |複数の角'''を''' | style="text-align:center;" | 対格 | style="background-color:#fcf;"| -'''ūs''' | style="background-color:#cfc;"| -'''ua''' |- | style="text-align:center;" | 与格 | style="background-color:#fcf;"| -'''ibus''' | man'''ibus''' | 複数の手'''に''' | style="background-color:#cfc;"| -'''ibus''' | corn'''ibus''' |複数の角'''に''' | style="text-align:center;" | 与格 | colspan="2" style="text-align:center;" | -'''ibus''' |- | style="text-align:center;" | 奪格 | style="background-color:#fcf;"| -'''ibus''' | man'''ibus''' | 複数の手'''で''' | style="background-color:#cfc;"| -'''ibus''' | corn'''ibus''' |複数の角'''で''' | style="text-align:center;" | 奪格 | colspan="2" style="text-align:center;" | -'''ibus''' |} == -ūs型 == ===おもな-ūs型=== *<span style="font-family:Times New Roman;font-size:25pt;"><span style="background-color:#ccf;">[[/exercitus]]</span>　　　　{{進捗|00%|2020-07-06}} </span> *<span style="font-family:Times New Roman;font-size:25pt;"><span style="background-color:#ccf;">[[/senatus]]</span>　　　　{{進捗|00%|2020-07-26}} </span> ====そのほかの属格 -ūs型の名詞==== ;　　男性名詞 *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:aditus#Latin|aditus, aditūs]]</span>　「出入口、アプローチ」など・・・[[ガリア戦記 第3巻/注解/12節|第3巻12節1項]]、など *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:aestus#Latin|aestus, aestūs]]</span>　「潮」など・・・[[ガリア戦記 第3巻/注解/12節|第3巻12節1項]]、など *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:commeatus#Latin|commeātus, -ūs]]</span>　「糧秣、糧食」「輸送」など・・・[[ガリア戦記 第3巻/注解/2節|第3巻2節3項]]、ほか *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:conspectus#Noun_2|cōnspectus, cōnspectūs]]</span>　「眺望」「眼前」など・・・[[ガリア戦記 第3巻/注解/14節|第3巻14節]]、など *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:equitatus#Latin|equitātus, equitātūs]]</span>　「騎兵隊」　多数 *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:exitus#Latin|exitus, exitūs]]</span>　「結果」など・・・[[ガリア戦記 第3巻/注解/8節|第3巻8節3項]]、など *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:impetus#Latin|impetus, impetūs]]</span>　「突進、攻撃」「激しい動き、勢い」など・・・[[ガリア戦記 第3巻/注解/8節|第3巻8節1項]]、など *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:lacus#Latin|lacus, lacūs]]</span>　「湖」　（ガリア戦記では、まれな単語） ・・・ [[ガリア戦記 第1巻/注解/2節#3項|1巻2節3項]]、[[ガリア戦記 第1巻/注解/8節#1項|1巻8節1項]]、第3巻など *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:portus#Latin|portus, portūs]]</span>　「港」・・・[[ガリア戦記 第3巻/注解/8節|第3巻8節2項]]、など *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:pulsus#Latin|pulsus, pulsūs]]</span>　「打つこと」「（櫂で）こぐこと」など・・・[[ガリア戦記 第3巻/注解/13節|第3巻13節]]、など *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:situs#Etymology_2_2|situs, sitūs]]</span>　「位置」「状況」など・・・[[ガリア戦記 第3巻/注解/12節|第3巻12節1項]]、など *<span style="font-family:Times New Roman;font-size:15pt;background-color:#eef;">[[wikt:en:usus#Latin|ūsus, ūsūs]]</span>　「経験」など・・・[[ガリア戦記 第3巻/注解/8節|第3巻8節1項]]、など <br> ;　　女性名詞 *<span style="font-family:Times New Roman;font-size:15pt;background-color:#fee;">[[wikt:en:manus#Latin|manus, manūs]] <span style="font-size:9pt;">(女性名詞)</span></span>　「手、部隊」　多数 ===passus=== <span style="background-color:#ccf;font-family:Times New Roman;font-size:20pt;">[[wikt:en:passus#Etymology_2|passus, passūs]]</span>　　は、<span style="font-family:Times New Roman;font-size:15pt;">-ūs</span>型の男性名詞で、歩幅に基づく長さの単位「[[w:パッスス|パッスス]]」（約1.48メートル）を表わす。[[w:ペース (長さ)|ペース (歩尺)]] の5倍。『ガリア戦記』では、1000パッススを表わす <span style="background-color:#cfc;font-family:Times New Roman;font-size:15pt;">mīlle passuum</span> として用いられることが多い。 <span style="background-color:#cfc;font-family:Times New Roman;font-size:15pt;">[[ガリア戦記/用例集/数詞/mille#mīlle passuum|mīlle passuum]]</span> を参照。 {| class=wikitable |+ style="background-color:#ccf; color:red;" |<span style="font-family:Times New Roman; font-size:20pt;">[[wikt:en:passus#Etymology_2|passus, -ūs]]</span> (男性名詞) !格 !! 単　数 !! 複　数 |- style="font-family:Times New Roman; text-align:center;" ! style="text-align:center; background-color:#dedede;" |主格 | style="font-size:20pt; background-color:#ccf;" | pass<span style="color:#f55;">'''us'''</span> | style="font-size:20pt;" | pass<span style="color:#f55;">'''ūs'''</span> |- style="font-family:Times New Roman; text-align:center;" ! style="text-align:center; background-color:#dedede;" |属格 | style="font-size:20pt;" | pass<span style="color:#f55;">'''ūs'''</span> | style="font-size:20pt;" | pass<span style="color:#f55;">'''uum'''</span> |- style="font-family:Times New Roman; text-align:center;" ! style="text-align:center;" |対格 | style="font-size:20pt;" | pass<span style="color:#f55;">'''um'''</span> | style="font-size:20pt;" | pass<span style="color:#f55;">'''ūs'''</span> |- style="font-family:Times New Roman; text-align:center;" ! style="text-align:center;" |与格 | style="font-size:20pt;" | pass<span style="color:#f55;">'''uī'''</span> | style="font-size:20pt;" | pass<span style="color:#f55;">'''ibus'''</span> |- style="font-family:Times New Roman; text-align:center;" ! style="text-align:center;" |奪格 | style="font-size:20pt;" | pass<span style="color:#f55;">'''ū'''</span> <!--,<br>mont<span style="color:#f55;">'''ī'''</span> --> | style="font-size:20pt;" | pass<span style="color:#f55;">'''ibus'''</span> |} == -ū 型 == ===おもな-ū型=== ====そのほかの-ū 型の名詞==== <br><span style="background-color:yellow;">（編集中）</span> == == == 脚注 == <references /> == 参考文献 == == 関連項目 == *<span style="background-color:#ffffcc;">[[古典ラテン語/名詞の変化/第四変化]]　　　　{{進捗|00%|2022-05-07}} </span> == 関連記事 == === 英語版 === *英語版ウィクショナリー **[[wikt:en:Appendix:Latin fourth declension]] （第四変化） **[[wikt:en:Category:Latin fourth declension nouns]] （第四変化名詞のカテゴリ） === 仏語版 === *仏語版ウィクショナリー **[[wikt:fr:Annexe:Quatrième déclinaison en latin]] （第四変化） === ラテン語版 === *ラテン語版ウィクショナリー **[[wikt:la:Categoria:Nomina Latina declinationis 4]] （第四変化のカテゴリ） == 外部リンク == <!-- {| border="1" class="wikitable" |+ '''名詞のおもな語尾変化''' |- align="center" | colspan="2" | ! 第1変化 ! colspan="2" | 第2変化 ! colspan="2" | 第3変化 ! colspan="2" | 第4変化 ! 第5変化 |- style="text-align:center;" | colspan="2" style="text-align:right;"| (名詞の性) | style="background-color:#fdd;"| 女性 | style="background-color:#ddf;"| 男性 | style="background-color:#dfd;"| 中性 | style="background-color:#fcf;"| 男･女 | style="background-color:#dfd;"| 中性 | style="background-color:#ddf;"| 男性 | style="background-color:#dfd;"| 中性 | style="background-color:#fdd;"| 女性 |- style="text-align:center;" | colspan="2" style="text-align:right;"| (単語例) | style="background-color:#fdd;"| amīca<br>(女友達) | style="background-color:#ddf;"| amīcus<br>(男友達) | style="background-color:#dfd;"| verbum<br>(言葉) | style="background-color:#fcf;"| homō<br>(人間) | style="background-color:#dfd;"| corpus<br>(身体) | style="background-color:#ddf;"| ūsus<br>(経験) | style="background-color:#dfd;"| cornū<br>(つの) | style="background-color:#fdd;"| rēs<br>(物事) |- ! rowspan="5"| 単数 ! 主格 | style="background-color:#fdd;"| -'''a''' | style="background-color:#ddf;"| -'''us''' | style="background-color:#dfd;"| -'''um''' | style="background-color:#fcf;"| -''(?)'' | style="background-color:#dfd;"| -''(?)'' | style="background-color:#ddf;"| -'''us''' | style="background-color:#dfd;"| -'''ū''' | style="background-color:#fdd;"| -'''ēs''' |- ! 属格 | style="background-color:#fdd;"| -'''ae''' | style="background-color:#ddf;"| -'''ī''' | style="background-color:#dfd;"| -'''ī''' | style="background-color:#fcf;"| -'''is''' | style="background-color:#dfd;"| -'''is''' | style="background-color:#ddf;"| -'''ūs''' | style="background-color:#dfd;"| -'''ūs''' | style="background-color:#fdd;"| -'''eī''' |- | style="text-align:center;" | 対格 | style="background-color:#fdd;"| -'''am''' | style="background-color:#ddf;"| -'''um''' | style="background-color:#dfd;"| -'''um''' | style="background-color:#fcf;"| -'''em''' | style="background-color:#dfd;"| -''(?)'' | style="background-color:#ddf;"| -'''um''' | style="background-color:#dfd;"| -'''ū''' | style="background-color:#fdd;"| -'''em''' |- | style="text-align:center;" | 与格 | style="background-color:#fdd;"| -'''ae''' | style="background-color:#ddf;"| -'''ō''' | style="background-color:#dfd;"| -'''ō''' | style="background-color:#fcf;"| -'''ī''' | style="background-color:#dfd;"| -'''ī''' | style="background-color:#ddf;"| -'''uī''' | style="background-color:#dfd;"| -'''ū''' | style="background-color:#fdd;"| -'''eī''' |- | style="text-align:center;" | 奪格 | style="background-color:#fdd;"| -'''ā''' | style="background-color:#ddf;"| -'''ō''' | style="background-color:#dfd;"| -'''ō''' | style="background-color:#fcf;"| -'''e''' | style="background-color:#dfd;"| -''(?)'' | style="background-color:#ddf;"| -'''ū''' | style="background-color:#dfd;"| -'''ū''' | style="background-color:#fdd;"| -'''ē''' |- ! rowspan="5"| 複数 | style="text-align:center;" | 主格 | style="background-color:#fcc;"| -'''ae''' | style="background-color:#ccf;"| -'''ī''' | style="background-color:#cfc;"| -'''a''' | style="background-color:#fbf;"| -'''ēs''' | style="background-color:#cfc;"| -'''(i) a''' | style="background-color:#ccf;"| -'''ūs''' | style="background-color:#cfc;"| -'''ua''' | style="background-color:#fcc;"| -'''ēs''' |- ! 属格 | style="background-color:#fcc;"| -'''ārum''' | style="background-color:#ccf;"| -'''ōrum''' | style="background-color:#cfc;"| -'''ōrum''' | style="background-color:#fbf;"| -'''(i) um''' | style="background-color:#cfc;"| -'''(i) um''' | style="background-color:#ccf;"| -'''uum''' | style="background-color:#cfc;"| -'''uum''' | style="background-color:#fcc;"| -'''ērum''' |- | style="text-align:center;" | 対格 | style="background-color:#fcc;"| -'''ās''' | style="background-color:#ccf;"| -'''ōs''' | style="background-color:#cfc;"| -'''a''' | style="background-color:#fbf;"| -'''ēs''' | style="background-color:#cfc;"| -'''(i) a''' | style="background-color:#ccf;"| -'''ūs''' | style="background-color:#cfc;"| -'''ua''' | style="background-color:#fcc;"| -'''ēs''' |- | style="text-align:center;" | 与格 | style="background-color:#fcc;"| -'''īs''' | style="background-color:#ccf;"| -'''īs''' | style="background-color:#cfc;"| -'''īs''' | style="background-color:#fbf;"| -'''ibus''' | style="background-color:#cfc;"| -'''ibus''' | style="background-color:#ccf;"| -'''ibus''' | style="background-color:#cfc;"| -'''ibus''' | style="background-color:#fcc;"| -'''ēbus''' |- | style="text-align:center;" | 奪格 | style="background-color:#fcc;"| -'''īs''' | style="background-color:#ccf;"| -'''īs''' | style="background-color:#cfc;"| -'''īs''' | style="background-color:#fbf;"| -'''ibus''' | style="background-color:#cfc;"| -'''ibus''' | style="background-color:#ccf;"| -'''ibus''' | style="background-color:#cfc;"| -'''ibus''' | style="background-color:#fcc;"| -'''ēbus''' |} --> [[Category:ガリア戦記 用例集|名詞]] t9ou3ebw3hp4hy2qx0fe0b805qncg9j 0 28640 206065 206001 2022-07-31T23:59:06Z Ef3 694 語尾の統一 wikitext text/x-wiki == 注釈 == Kotlinは、コンパイルのターゲットごとに大別すると * [[w:LLVM]] 向けのKotlin/Native * [[JavaScript]]向けであるKotlin/JS * [[w:LLVM]] 向けのKotlin/Native があります。 それぞれ、開発に必要になるものが異なります。 == Kotlin/JVM 環境のインストール方法 == === Windowsの場合 === ==== Javaのインストール ==== まず、2020年現在のJava開発元のオラクルのwebサイトから、Javaのインストーラーをダウンロードして、これをダブルクリック起動などしてインストールします。 ==== kotlinの入手 ==== GitHubにkotlinの公式リポジトリがあります。 https://github.com/JetBrains/kotlin/ このリポジトリから、[https://github.com/JetBrains/kotlin/releases リリース情報]を開き、'''Assets''' をページ内検索しその章にある kotlin-compiler-1.7.10 をダウンロードします。 1.7.0 の部分は、リリースの度に更新されていくので、適宜、読み替えて欲しい。 ==== kotlin のインストール ==== GitHubからダウンロードしたkotlinコンパイラのZIPを展開すると、「kotlinc」というホルダー以下に展開されます（語尾に「c」がついています）。 目標として、このkotlincの場所に環境変数パスをこれから通せばいいです。 なので、kotlincの保管場所は、単にインストールするだけなら どこでもいいのですが、Cドライブ直下またはCドライブの「Program Files」などにkotlincを移動したほうが、他のプログラマーとノウハウ共有しやすく管理しやすいでしょう。 なので、たとえば今回は、Cドライブ直下にkotlincを移動したとしましょう。 Windowsの環境変数には、システム環境変数とユーザ環境変数があるのですが、kotlinのインストールではシステム環境変数を設定します。システム環境変数は他のユーザと共有されます。 システム環境変数を設定するには、デスクトップで「システムのプロパティ」を検索し、システムのプロパティを開き、［詳細設定］タブの右下にある［環境変数］ボタンをクリックして、［環境変数］画面を開き、システム環境変数の設定をします。 環境変数PATHの末尾に「;C:\kotlinc\bin」を追加します。なお、セミコロン;とコロン:の使い分けには中注意。 Cの直前にある「;」はセミコロンであり、意味はほかのアプリのパスとの区切り記号です。 Cの直後にある「:」はドライブレターを示すコロンです。 環境変数パスの設定が正しく出来たら、インストールに成功しているはずなので、下記のように、バージョン確認コマンドなどで確認します。 コマンド入力は、Windowsアクセサリの『コマンド プロンプト』『Windows Terminal』あるいは『Power shell』から行えます。 バージョン確認コマンドは、 kotlin -version であるので、単にこのコマンドを入力すればいいです。 成功すれば Kotlin version 1.7.10-release-333 (JRE 1.8.0_331-b09) のように kotlin 自身と JRE のバージョンが表示されます。 === Linuxの場合 === 2020年の現状では、Linux で kotlinのインストールのために、まず先にsdkmanをインストールします。 sdkmanはkotlinに限らず、パッケージの複数バージョンの並行管理などを行うことができます。 ==== sdkmanのインストール ==== Linuxの場合、コマンド :<nowiki> curl -s "https://get.sdkman.io" | bash</nowiki> でsdkmanのインストールが行われます。 アスキーアートが表示され、 <!-- Now attempting の前の長い空白は、実機の仕様です。 --> <pre> Now attempting installation... Looking for a previous installation of SDKMAN... Looking for unzip... Looking for zip... </pre> （※ 後略） と処理が進み 最後に All done! あるいは Enjoy!!! とか書いてあれば、sdkmanのインストール自体は完了。ただし、まだパス設定などが、されていません。 そのあと、sdkman のパス設定などのために、コマンド source "$HOME/.sdkman/bin/sdkman-init.sh" を入力。 このあと、インストールが成功したかどうかの確認のため sdk version もし sdkman のインストールに成功してれば、 <pre> ==== BROADCAST ================================================================= * 2020-06-17: Asciidoctorj 2.3.1 released on SDKMAN! #asciidoctorj * 2020-06-16: Micronaut 2.0.0.RC1 released on SDKMAN! #micronautfw * 2020-06-14: Jbang 0.31.0 released on SDKMAN! See https://github.com/jbangdev/jbang/releases/tag/v0.31.0 #jbang ================================================================================ SDKMAN 5.8.3+506 </pre> のようなう表示が行われます。 しかし、まだsdkmanがインストールされただけです。 ==== sdkmanのインストール後 ==== sdkmanのインストールに成功したら、これから kotlin をインストールするため、さらにコマンド sdk install kotlin でkotlinをインストールします。 成功すれば、下記のように表示されます。 <pre> Downloading: kotlin 1.3.72 In progress... ######################################################################### 100.0%######################################################################### 100.0% Installing: kotlin 1.3.72 Done installing! Setting kotlin 1.3.72 as default. </pre> これで kotlin のインストールが成功しているハズ。 最終確認として、バージョン確認をしてみましょう。 コマンド kotlinc -version を実行すれば、 info: kotlinc-jvm 1.5.31 (JRE 17.0.1+12) のように表示されるでしょう。 === BSD系Unixの場合 === NetBSDやFreeBSDなどのBSD系Unixの場合、Ports Collectionに、lang/kotlin としてエントリーがあるので ;ソースからビルド:<syntaxhighlight lang="console"> % sudo make -C /usr/ports/lang/kotlin all install clean </syntaxhighlight> あるいは ;パッケージからインストール:<syntaxhighlight lang="console"> % sudo pkg install lang/kotすれば Kotlin version 1.7.10-release-333 (JRE 1.8.0_331-lin </syntaxhighlight> の2通りのインストール方法があります。 ソースからビルドと言っも、lang/kotlin の場合は2022年6月現在、GitHubからリリースバージョンのコンパイラーのZIPを fetch して展開するだけなので、ビルドオプションを変えてホスト環境に最適化などはしなしので、パッケージ版との差異はありません。 なお、どちらの方法も、jdk などのパッケージに不足があれば、依存関係により、ビルドあるいは fetch & install されます。 インストールが終わったら、インストールされたKotlinのバージョンを確認します。 ;バージョン確認:<syntaxhighlight lang="console"> % kotlinc -version info: kotlinc-jvm 1.7.10 (JRE 1.8.0_332-b09) </syntaxhighlight> もし :<syntaxhighlight lang="console"> % kotlinc -version kotlinc: Command not found. </syntaxhighlight> の様に、失敗するようでしたらインストール失敗も考えられますが、/usr/local/bin にPATHが通っているか確認してください。 61xk7olbbnceakc85v6uot2l5n7ro9y 206068 206065 2022-08-01T00:41:24Z Ef3 694 /* BSD系Unixの場合 */ Fix markup wikitext text/x-wiki == 注釈 == Kotlinは、コンパイルのターゲットごとに大別すると * [[w:LLVM]] 向けのKotlin/Native * [[JavaScript]]向けであるKotlin/JS * [[w:LLVM]] 向けのKotlin/Native があります。 それぞれ、開発に必要になるものが異なります。 == Kotlin/JVM 環境のインストール方法 == === Windowsの場合 === ==== Javaのインストール ==== まず、2020年現在のJava開発元のオラクルのwebサイトから、Javaのインストーラーをダウンロードして、これをダブルクリック起動などしてインストールします。 ==== kotlinの入手 ==== GitHubにkotlinの公式リポジトリがあります。 https://github.com/JetBrains/kotlin/ このリポジトリから、[https://github.com/JetBrains/kotlin/releases リリース情報]を開き、'''Assets''' をページ内検索しその章にある kotlin-compiler-1.7.10 をダウンロードします。 1.7.0 の部分は、リリースの度に更新されていくので、適宜、読み替えて欲しい。 ==== kotlin のインストール ==== GitHubからダウンロードしたkotlinコンパイラのZIPを展開すると、「kotlinc」というホルダー以下に展開されます（語尾に「c」がついています）。 目標として、このkotlincの場所に環境変数パスをこれから通せばいいです。 なので、kotlincの保管場所は、単にインストールするだけなら どこでもいいのですが、Cドライブ直下またはCドライブの「Program Files」などにkotlincを移動したほうが、他のプログラマーとノウハウ共有しやすく管理しやすいでしょう。 なので、たとえば今回は、Cドライブ直下にkotlincを移動したとしましょう。 Windowsの環境変数には、システム環境変数とユーザ環境変数があるのですが、kotlinのインストールではシステム環境変数を設定します。システム環境変数は他のユーザと共有されます。 システム環境変数を設定するには、デスクトップで「システムのプロパティ」を検索し、システムのプロパティを開き、［詳細設定］タブの右下にある［環境変数］ボタンをクリックして、［環境変数］画面を開き、システム環境変数の設定をします。 環境変数PATHの末尾に「;C:\kotlinc\bin」を追加します。なお、セミコロン;とコロン:の使い分けには中注意。 Cの直前にある「;」はセミコロンであり、意味はほかのアプリのパスとの区切り記号です。 Cの直後にある「:」はドライブレターを示すコロンです。 環境変数パスの設定が正しく出来たら、インストールに成功しているはずなので、下記のように、バージョン確認コマンドなどで確認します。 コマンド入力は、Windowsアクセサリの『コマンド プロンプト』『Windows Terminal』あるいは『Power shell』から行えます。 バージョン確認コマンドは、 kotlin -version であるので、単にこのコマンドを入力すればいいです。 成功すれば Kotlin version 1.7.10-release-333 (JRE 1.8.0_331-b09) のように kotlin 自身と JRE のバージョンが表示されます。 === Linuxの場合 === 2020年の現状では、Linux で kotlinのインストールのために、まず先にsdkmanをインストールします。 sdkmanはkotlinに限らず、パッケージの複数バージョンの並行管理などを行うことができます。 ==== sdkmanのインストール ==== Linuxの場合、コマンド :<nowiki> curl -s "https://get.sdkman.io" | bash</nowiki> でsdkmanのインストールが行われます。 アスキーアートが表示され、 <!-- Now attempting の前の長い空白は、実機の仕様です。 --> <pre> Now attempting installation... Looking for a previous installation of SDKMAN... Looking for unzip... Looking for zip... </pre> （※ 後略） と処理が進み 最後に All done! あるいは Enjoy!!! とか書いてあれば、sdkmanのインストール自体は完了。ただし、まだパス設定などが、されていません。 そのあと、sdkman のパス設定などのために、コマンド source "$HOME/.sdkman/bin/sdkman-init.sh" を入力。 このあと、インストールが成功したかどうかの確認のため sdk version もし sdkman のインストールに成功してれば、 <pre> ==== BROADCAST ================================================================= * 2020-06-17: Asciidoctorj 2.3.1 released on SDKMAN! #asciidoctorj * 2020-06-16: Micronaut 2.0.0.RC1 released on SDKMAN! #micronautfw * 2020-06-14: Jbang 0.31.0 released on SDKMAN! See https://github.com/jbangdev/jbang/releases/tag/v0.31.0 #jbang ================================================================================ SDKMAN 5.8.3+506 </pre> のようなう表示が行われます。 しかし、まだsdkmanがインストールされただけです。 ==== sdkmanのインストール後 ==== sdkmanのインストールに成功したら、これから kotlin をインストールするため、さらにコマンド sdk install kotlin でkotlinをインストールします。 成功すれば、下記のように表示されます。 <pre> Downloading: kotlin 1.3.72 In progress... ######################################################################### 100.0%######################################################################### 100.0% Installing: kotlin 1.3.72 Done installing! Setting kotlin 1.3.72 as default. </pre> これで kotlin のインストールが成功しているハズ。 最終確認として、バージョン確認をしてみましょう。 コマンド kotlinc -version を実行すれば、 info: kotlinc-jvm 1.5.31 (JRE 17.0.1+12) のように表示されるでしょう。 === BSD系Unixの場合 === NetBSDやFreeBSDなどのBSD系Unixの場合、Package sourceやPorts Collectionに、lang/kotlin としてエントリーがあるので ;ソースからビルド:<syntaxhighlight lang="console"> # make -C /usr/ports/lang/kotlin all install clean ===> License APACHE20 accepted by the user ===> kotlin-1.7.10 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by kotlin-1.7.10 for building ===> Extracting for kotlin-1.7.10 => SHA256 Checksum OK for kotlin-compiler-1.7.10.zip. /bin/rm -f /usr/ports/lang/kotlin/work/kotlinc/bin/*.bat ===> Patching for kotlin-1.7.10 ===> Configuring for kotlin-1.7.10 ===> Staging for kotlin-1.7.10 ===> kotlin-1.7.10 depends on executable: bash - found ===> kotlin-1.7.10 depends on file: /usr/local/openjdk8/bin/java - found ===> Generating temporary packing list /bin/mkdir -p /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin/lib /bin/mkdir -p /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin/bin cd /usr/ports/lang/kotlin/work/kotlinc/bin && /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) && /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 555 "$@"'\'' . {} + \)' COPYTREE_BIN . /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin/bin cd /usr/ports/lang/kotlin/work/kotlinc/lib && /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) && /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE . /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin/lib /bin/ln -sf /usr/local/share/kotlin/bin/kapt /usr/ports/lang/kotlin/work/stage/usr/local/bin/kapt /bin/ln -sf /usr/local/share/kotlin/bin/kotlin /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlin /bin/ln -sf /usr/local/share/kotlin/bin/kotlin-dce-js /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlin-dce-js /bin/ln -sf /usr/local/share/kotlin/bin/kotlinc /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlinc /bin/ln -sf /usr/local/share/kotlin/bin/kotlinc-js /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlinc-js /bin/ln -sf /usr/local/share/kotlin/bin/kotlinc-jvm /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlinc-jvm install -C -m 0644 /usr/ports/lang/kotlin/work/kotlinc/build.txt /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin ====> Compressing man pages (compress-man) ===> Installing for kotlin-1.7.10 ===> Checking if kotlin is already installed ===> Registering installation for kotlin-1.7.10 Installing kotlin-1.7.10... ===> Cleaning for kotlin-1.7.10 </syntaxhighlight> あるいは ;パッケージからインストール:<syntaxhighlight lang="console"> # pkg install lang/kotlin Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 2 package(s) will be affected (of 0 checked): New packages to be INSTALLED: kotlin: 1.7.10 Installed packages to be DOWNGRADED: highway: 1.0.0 -> 0.17.0 Number of packages to be installed: 1 Number of packages to be downgraded: 1 The process will require 77 MiB more space. 354 KiB to be downloaded. Proceed with this action? [y/N]: y [1/1] Fetching highway-0.17.0.pkg: 100% 354 KiB 362.7kB/s 00:01 Checking integrity... done (0 conflicting) [1/2] Installing kotlin-1.7.10... [1/2] Extracting kotlin-1.7.10: 100% [2/2] Downgrading highway from 1.0.0 to 0.17.0... [2/2] Extracting highway-0.17.0: 100% </syntaxhighlight> :の2通りのインストール方法があります。 ソースからビルドと言っも、lang/kotlin の場合は2022年6月現在、GitHubからリリースバージョンのコンパイラーのZIPを fetch して展開するだけなので、ビルドオプションを変えてホスト環境に最適化などはしなしので、パッケージ版との差異はありません。 なお、どちらの方法も、jdk などのパッケージに不足があれば、依存関係により、ビルドあるいは fetch & install されます。 インストールが終わったら、インストールされたKotlinのバージョンを確認します。 ;バージョン確認:<syntaxhighlight lang="console"> % kotlinc -version info: kotlinc-jvm 1.7.10 (JRE 1.8.0_332-b09) </syntaxhighlight> もし :<syntaxhighlight lang="console"> % kotlinc -version kotlinc: Command not found. </syntaxhighlight> の様に、失敗するようでしたらインストール失敗も考えられますが、/usr/local/bin にPATHが通っているか確認してください。 dnamgy2jexwp0abtohhkh1zj9vfe14n 206069 206068 2022-08-01T00:43:08Z Ef3 694 /* 注釈 */ * [[w:Java仮想マシン]]向けのKotlin/JVM wikitext text/x-wiki == 注釈 == Kotlinは、コンパイルのターゲットごとに大別すると * [[w:Java仮想マシン]]向けのKotlin/JVM * [[JavaScript]]向けのKotlin/JS * [[w:LLVM]] 向けのKotlin/Native があります。 それぞれ、開発に必要になるものが異なります。 == Kotlin/JVM 環境のインストール方法 == === Windowsの場合 === ==== Javaのインストール ==== まず、2020年現在のJava開発元のオラクルのwebサイトから、Javaのインストーラーをダウンロードして、これをダブルクリック起動などしてインストールします。 ==== kotlinの入手 ==== GitHubにkotlinの公式リポジトリがあります。 https://github.com/JetBrains/kotlin/ このリポジトリから、[https://github.com/JetBrains/kotlin/releases リリース情報]を開き、'''Assets''' をページ内検索しその章にある kotlin-compiler-1.7.10 をダウンロードします。 1.7.0 の部分は、リリースの度に更新されていくので、適宜、読み替えて欲しい。 ==== kotlin のインストール ==== GitHubからダウンロードしたkotlinコンパイラのZIPを展開すると、「kotlinc」というホルダー以下に展開されます（語尾に「c」がついています）。 目標として、このkotlincの場所に環境変数パスをこれから通せばいいです。 なので、kotlincの保管場所は、単にインストールするだけなら どこでもいいのですが、Cドライブ直下またはCドライブの「Program Files」などにkotlincを移動したほうが、他のプログラマーとノウハウ共有しやすく管理しやすいでしょう。 なので、たとえば今回は、Cドライブ直下にkotlincを移動したとしましょう。 Windowsの環境変数には、システム環境変数とユーザ環境変数があるのですが、kotlinのインストールではシステム環境変数を設定します。システム環境変数は他のユーザと共有されます。 システム環境変数を設定するには、デスクトップで「システムのプロパティ」を検索し、システムのプロパティを開き、［詳細設定］タブの右下にある［環境変数］ボタンをクリックして、［環境変数］画面を開き、システム環境変数の設定をします。 環境変数PATHの末尾に「;C:\kotlinc\bin」を追加します。なお、セミコロン;とコロン:の使い分けには中注意。 Cの直前にある「;」はセミコロンであり、意味はほかのアプリのパスとの区切り記号です。 Cの直後にある「:」はドライブレターを示すコロンです。 環境変数パスの設定が正しく出来たら、インストールに成功しているはずなので、下記のように、バージョン確認コマンドなどで確認します。 コマンド入力は、Windowsアクセサリの『コマンド プロンプト』『Windows Terminal』あるいは『Power shell』から行えます。 バージョン確認コマンドは、 kotlin -version であるので、単にこのコマンドを入力すればいいです。 成功すれば Kotlin version 1.7.10-release-333 (JRE 1.8.0_331-b09) のように kotlin 自身と JRE のバージョンが表示されます。 === Linuxの場合 === 2020年の現状では、Linux で kotlinのインストールのために、まず先にsdkmanをインストールします。 sdkmanはkotlinに限らず、パッケージの複数バージョンの並行管理などを行うことができます。 ==== sdkmanのインストール ==== Linuxの場合、コマンド :<nowiki> curl -s "https://get.sdkman.io" | bash</nowiki> でsdkmanのインストールが行われます。 アスキーアートが表示され、 <!-- Now attempting の前の長い空白は、実機の仕様です。 --> <pre> Now attempting installation... Looking for a previous installation of SDKMAN... Looking for unzip... Looking for zip... </pre> （※ 後略） と処理が進み 最後に All done! あるいは Enjoy!!! とか書いてあれば、sdkmanのインストール自体は完了。ただし、まだパス設定などが、されていません。 そのあと、sdkman のパス設定などのために、コマンド source "$HOME/.sdkman/bin/sdkman-init.sh" を入力。 このあと、インストールが成功したかどうかの確認のため sdk version もし sdkman のインストールに成功してれば、 <pre> ==== BROADCAST ================================================================= * 2020-06-17: Asciidoctorj 2.3.1 released on SDKMAN! #asciidoctorj * 2020-06-16: Micronaut 2.0.0.RC1 released on SDKMAN! #micronautfw * 2020-06-14: Jbang 0.31.0 released on SDKMAN! See https://github.com/jbangdev/jbang/releases/tag/v0.31.0 #jbang ================================================================================ SDKMAN 5.8.3+506 </pre> のようなう表示が行われます。 しかし、まだsdkmanがインストールされただけです。 ==== sdkmanのインストール後 ==== sdkmanのインストールに成功したら、これから kotlin をインストールするため、さらにコマンド sdk install kotlin でkotlinをインストールします。 成功すれば、下記のように表示されます。 <pre> Downloading: kotlin 1.3.72 In progress... ######################################################################### 100.0%######################################################################### 100.0% Installing: kotlin 1.3.72 Done installing! Setting kotlin 1.3.72 as default. </pre> これで kotlin のインストールが成功しているハズ。 最終確認として、バージョン確認をしてみましょう。 コマンド kotlinc -version を実行すれば、 info: kotlinc-jvm 1.5.31 (JRE 17.0.1+12) のように表示されるでしょう。 === BSD系Unixの場合 === NetBSDやFreeBSDなどのBSD系Unixの場合、Package sourceやPorts Collectionに、lang/kotlin としてエントリーがあるので ;ソースからビルド:<syntaxhighlight lang="console"> # make -C /usr/ports/lang/kotlin all install clean ===> License APACHE20 accepted by the user ===> kotlin-1.7.10 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by kotlin-1.7.10 for building ===> Extracting for kotlin-1.7.10 => SHA256 Checksum OK for kotlin-compiler-1.7.10.zip. /bin/rm -f /usr/ports/lang/kotlin/work/kotlinc/bin/*.bat ===> Patching for kotlin-1.7.10 ===> Configuring for kotlin-1.7.10 ===> Staging for kotlin-1.7.10 ===> kotlin-1.7.10 depends on executable: bash - found ===> kotlin-1.7.10 depends on file: /usr/local/openjdk8/bin/java - found ===> Generating temporary packing list /bin/mkdir -p /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin/lib /bin/mkdir -p /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin/bin cd /usr/ports/lang/kotlin/work/kotlinc/bin && /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) && /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 555 "$@"'\'' . {} + \)' COPYTREE_BIN . /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin/bin cd /usr/ports/lang/kotlin/work/kotlinc/lib && /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) && /usr/bin/find -Ed $1 $3 \( -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} + -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE . /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin/lib /bin/ln -sf /usr/local/share/kotlin/bin/kapt /usr/ports/lang/kotlin/work/stage/usr/local/bin/kapt /bin/ln -sf /usr/local/share/kotlin/bin/kotlin /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlin /bin/ln -sf /usr/local/share/kotlin/bin/kotlin-dce-js /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlin-dce-js /bin/ln -sf /usr/local/share/kotlin/bin/kotlinc /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlinc /bin/ln -sf /usr/local/share/kotlin/bin/kotlinc-js /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlinc-js /bin/ln -sf /usr/local/share/kotlin/bin/kotlinc-jvm /usr/ports/lang/kotlin/work/stage/usr/local/bin/kotlinc-jvm install -C -m 0644 /usr/ports/lang/kotlin/work/kotlinc/build.txt /usr/ports/lang/kotlin/work/stage/usr/local/share/kotlin ====> Compressing man pages (compress-man) ===> Installing for kotlin-1.7.10 ===> Checking if kotlin is already installed ===> Registering installation for kotlin-1.7.10 Installing kotlin-1.7.10... ===> Cleaning for kotlin-1.7.10 </syntaxhighlight> あるいは ;パッケージからインストール:<syntaxhighlight lang="console"> # pkg install lang/kotlin Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 2 package(s) will be affected (of 0 checked): New packages to be INSTALLED: kotlin: 1.7.10 Installed packages to be DOWNGRADED: highway: 1.0.0 -> 0.17.0 Number of packages to be installed: 1 Number of packages to be downgraded: 1 The process will require 77 MiB more space. 354 KiB to be downloaded. Proceed with this action? [y/N]: y [1/1] Fetching highway-0.17.0.pkg: 100% 354 KiB 362.7kB/s 00:01 Checking integrity... done (0 conflicting) [1/2] Installing kotlin-1.7.10... [1/2] Extracting kotlin-1.7.10: 100% [2/2] Downgrading highway from 1.0.0 to 0.17.0... [2/2] Extracting highway-0.17.0: 100% </syntaxhighlight> :の2通りのインストール方法があります。 ソースからビルドと言っも、lang/kotlin の場合は2022年6月現在、GitHubからリリースバージョンのコンパイラーのZIPを fetch して展開するだけなので、ビルドオプションを変えてホスト環境に最適化などはしなしので、パッケージ版との差異はありません。 なお、どちらの方法も、jdk などのパッケージに不足があれば、依存関係により、ビルドあるいは fetch & install されます。 インストールが終わったら、インストールされたKotlinのバージョンを確認します。 ;バージョン確認:<syntaxhighlight lang="console"> % kotlinc -version info: kotlinc-jvm 1.7.10 (JRE 1.8.0_332-b09) </syntaxhighlight> もし :<syntaxhighlight lang="console"> % kotlinc -version kotlinc: Command not found. </syntaxhighlight> の様に、失敗するようでしたらインストール失敗も考えられますが、/usr/local/bin にPATHが通っているか確認してください。 dtkwvi2sxyy5nz7omo1gwl4w2sxjibv 0 28986 206071 185707 2022-08-01T01:50:15Z Ef3 694 /* グローバル変数 */ main() 関数のブロックの外を、仮に「グローバル領域」とします。 グローバル領域で、変数（グローバル変数）を宣言する事が出来ます。 グローバル変数は、main関数の関数で自由に参照でき、宣言などせずに前方参照ができます。 wikitext text/x-wiki == 関数 == === グローバル変数 === main() 関数のブロックの外を、仮に「グローバル領域」とします。 グローバル領域で、変数（グローバル変数）を宣言する事が出来ます。 グローバル変数は、main関数の関数で自由に参照でき、宣言などせずに前方参照ができます。 ;[https://paiza.io/projects/qn0dVRekXX-uJ_PHvt2O_A?language=kotlin コード例]:<syntaxhighlight lang="Kotlin"> var i : Int = 20 fun main() { println(i) println(j) // グローバル変数は前方参照が許されます。 } var j : Int = 42 </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> 20 42 </syntaxhighlight> === ユーザ定義関数 === 関数(function)とは、処理をまとめたものである。プログラマーが関数を自作する事もでき、そのような関数を「ユーザ定義関数」と言う。 いっぽう、「println」のように、元から用意されている関数のことを「組み込み関数」（ビルトイン関数）と言ったり「標準関数」と言ったり、色々な言い方がある。 さて、ユーザ定義関数の書式は、 <syntaxhighlight lang="Kotlin"> fun 関数名(引数名: 引数の型) : 戻り値の型 { return 戻り値 } </syntaxhighlight> である。 Kotlinにおけるユーザ定義関数の例を示す。下記の「test」がユーザ定義関数である。 ;コード例 <syntaxhighlight lang="Kotlin"> fun test(i: Int) : Int { return i + 5 } fun main() { var i : Int i =10 println(test(i)) } </syntaxhighlight> ;実行結果 <pre> 15 </pre> ユーザ定義関数の中で変数を使う場合は、グローバル変数でない限りは、必ずそのユーザ定義関数で再宣言する必要があります（しないとコンパイル時にエラー）。 Kotlinのユーザ定義変数内では、グローバル変数を使える。グローバル変数を宣言すると、その変数をどのユーザ定義関数からでも、書き換えしやすくなります。一方で、バグによる意図しない書き換えを防ぎたい場合には、あえてグローバル変数を用いない方法も可能です。 下記コードに、グローバル変数を用いる例を示します。 ;コード例 <syntaxhighlight lang="Kotlin"> var i : Int = 30 fun add() { i = i + 5 } fun main() { add() println(i) } </syntaxhighlight> ;実行結果 <pre> 35 </pre> なお、関数の引数は、必要が無ければ省略できる。戻り値の型も、そもそも戻り値が無い場合には型を省略できる。 戻り値の無い場合にそのことを明示したい場合、<code>Unit</code> という型名を使う。（Unit は、Java でいう void に相当。） 引数の無い関数の例として、たとえば下記のような文字表示をするだけの関数がある。 ;コード例 <syntaxhighlight lang="Kotlin"> fun aisatu() { println("こんにちは") } fun main() :Unit { aisatu() } </syntaxhighlight> ;実行結果 <pre> こんにちは </pre> ユーザ定義関数をmain関数よりも後ろに書いても、kotlinは読み取ってくれます。 ;コード例 <syntaxhighlight lang="Kotlin"> fun gummo() { println("おはよう") } fun main() :Unit { gummo() } </syntaxhighlight> ;実行結果 <pre> おはよう </pre> === 引数は読取専用 === kotlinの関数の引数で宣言された変数は、基本的に読取専用です。そのため、下記のようにグローバル書き換えをしようとしても、エラーになり不可能です。 ;エラーになるコード例 <syntaxhighlight lang="Kotlin"> var i : Int = 30 // グローバル変数として宣言 fun test(i: Int) : Int { i = i + 5 // ここでエラー println("いまユーザ関数の中") println(i) return 1 } fun main() { var i : Int i =10 test(i) println("いまmain関数") println(i) } </syntaxhighlight> たとえ同名の変数をグローバル変数で宣言していようが、引数で宣言された数の書き換えは不可能です。 もし、グローバル変数をユーザ定義関数で書き替えたい場合には、下記コードのように呼び出し時に、その引数名は与えないで、呼び出しします。 ;コード例 <syntaxhighlight lang="Kotlin"> var i : Int = 30 // 引数が無い事に注目 fun test() : Int { i = i + 5 println("いまユーザ関数の中") println(i) return 1 } fun main() { var i : Int i =10 test() // グローバル変数をいじるので、呼び出し側の引数を消す println("いまmain関数") println(i) } </syntaxhighlight> ;実行結果 <pre> いまユーザ関数の中 35 いまmain関数 10 </pre> なお、ユーザ定義関数側でグローバル変数をいじっているので、ユーザ定義関数で参照される「i」は、main関数の「10」ではなく、グローバル変数の「30」および計算結果(+5)の「35」です。 また、main関数側でも別途iを宣言してあるので、main関数に戻った時にはiは「10」に戻ります。（詳しくは後述の「ローカル変数」の節で説明します。） === ローカル変数 === ある関数の中で、呼び出し元やグーバル変数ですでに使用した変数と同じ変数名の変数をvar宣言する事ができますが、既存の変数とは別の、宣言場所のその関数内限定での変数として扱われ、このような仕組みを「ローカル変数」といいます。 ;コード例 <syntaxhighlight lang="Kotlin"> fun test() : Int { var i : Int = 40 i = i + 5 println("いまユーザ関数の中") println(i) return 1 } fun main() { var i : Int i =10 test() println("いまmain関数") println(i) } </syntaxhighlight> ;実行結果 <pre> いまユーザ関数の中 45 いまmain関数 10 </pre> ユーザ定義関数の中の「i」は、main関数の「i」とは別物です。 なので、ユーザ定義関数側でiが40になったり45になったりしても、ユーザ定義関数の実行が終わりmain関数に戻った際には、iの値は10に戻ってしまいます（main関数内でのユーザ定義関数の呼び出し直前のiの値が「10」なので、直前の値に戻る）。 giatvuhzoifprvkiupn1g75ttjlkdp5 206072 206071 2022-08-01T02:08:55Z Ef3 694 /* 関数定義 */ Kotlinの関数はfunキーワードで宣言されます。 wikitext text/x-wiki == 関数 == === グローバル変数 === main() 関数のブロックの外を、仮に「グローバル領域」とします。 グローバル領域で、変数（グローバル変数）を宣言する事が出来ます。 グローバル変数は、main関数の関数で自由に参照でき、宣言などせずに前方参照ができます。 ;[https://paiza.io/projects/qn0dVRekXX-uJ_PHvt2O_A?language=kotlin コード例]:<syntaxhighlight lang="Kotlin"> var i : Int = 20 fun main() { println(i) println(j) // グローバル変数は前方参照が許されます。 } var j : Int = 42 </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> 20 42 </syntaxhighlight> === 関数定義 === Kotlinの関数はfunキーワードで宣言されます。 ;関数定義と呼出しの例:<syntaxhighlight lang="Kotlin" highlight="1-3,8"> fun power(n : Int) : Int { return n * n } fun main(args: Array<String>) { var i : Int = 10 println(power(i)) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 100 </syntaxhighlight> : 整数の仮引数を１つとり、整数の値を返す関数 power() を定義しています。 : main() の中で <code>power(i)</code> と実引数を変数 <var>i</var> として呼出しています。 ;関数定義の構文:<syntaxhighlight lang="Kotlin"> fun 関数名(仮引数リスト) : 戻値型 { 式・・・・ return 戻値式 } </syntaxhighlight> ;関数呼出しの構文:<syntaxhighlight lang="Kotlin"> 関数名(実引数リスト) </syntaxhighlight> === 引数は読取専用 === kotlinの関数の引数で宣言された変数は、基本的に読取専用です。そのため、下記のようにグローバル書き換えをしようとしても、エラーになり不可能です。 ;エラーになるコード例 <syntaxhighlight lang="Kotlin"> var i : Int = 30 // グローバル変数として宣言 fun test(i: Int) : Int { i = i + 5 // ここでエラー println("いまユーザ関数の中") println(i) return 1 } fun main() { var i : Int i =10 test(i) println("いまmain関数") println(i) } </syntaxhighlight> たとえ同名の変数をグローバル変数で宣言していようが、引数で宣言された数の書き換えは不可能です。 もし、グローバル変数をユーザ定義関数で書き替えたい場合には、下記コードのように呼び出し時に、その引数名は与えないで、呼び出しします。 ;コード例 <syntaxhighlight lang="Kotlin"> var i : Int = 30 // 引数が無い事に注目 fun test() : Int { i = i + 5 println("いまユーザ関数の中") println(i) return 1 } fun main() { var i : Int i =10 test() // グローバル変数をいじるので、呼び出し側の引数を消す println("いまmain関数") println(i) } </syntaxhighlight> ;実行結果 <pre> いまユーザ関数の中 35 いまmain関数 10 </pre> なお、ユーザ定義関数側でグローバル変数をいじっているので、ユーザ定義関数で参照される「i」は、main関数の「10」ではなく、グローバル変数の「30」および計算結果(+5)の「35」です。 また、main関数側でも別途iを宣言してあるので、main関数に戻った時にはiは「10」に戻ります。（詳しくは後述の「ローカル変数」の節で説明します。） === ローカル変数 === ある関数の中で、呼び出し元やグーバル変数ですでに使用した変数と同じ変数名の変数をvar宣言する事ができますが、既存の変数とは別の、宣言場所のその関数内限定での変数として扱われ、このような仕組みを「ローカル変数」といいます。 ;コード例 <syntaxhighlight lang="Kotlin"> fun test() : Int { var i : Int = 40 i = i + 5 println("いまユーザ関数の中") println(i) return 1 } fun main() { var i : Int i =10 test() println("いまmain関数") println(i) } </syntaxhighlight> ;実行結果 <pre> いまユーザ関数の中 45 いまmain関数 10 </pre> ユーザ定義関数の中の「i」は、main関数の「i」とは別物です。 なので、ユーザ定義関数側でiが40になったり45になったりしても、ユーザ定義関数の実行が終わりmain関数に戻った際には、iの値は10に戻ってしまいます（main関数内でのユーザ定義関数の呼び出し直前のiの値が「10」なので、直前の値に戻る）。 qmde2nnex5dt3870dkjb20l6j40r5dw 206073 206072 2022-08-01T02:17:14Z Ef3 694 /* 引数はイミュータブル */ kotlinの関数の引数で宣言された変数は、val 宣言された変数と同じくイミュータブルです。そのため、下記のように代入しようとしても、エラーとなりコンパイルできません。 wikitext text/x-wiki == 関数 == === グローバル変数 === main() 関数のブロックの外を、仮に「グローバル領域」とします。 グローバル領域で、変数（グローバル変数）を宣言する事が出来ます。 グローバル変数は、main関数の関数で自由に参照でき、宣言などせずに前方参照ができます。 ;[https://paiza.io/projects/qn0dVRekXX-uJ_PHvt2O_A?language=kotlin コード例]:<syntaxhighlight lang="Kotlin"> var i : Int = 20 fun main() { println(i) println(j) // グローバル変数は前方参照が許されます。 } var j : Int = 42 </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> 20 42 </syntaxhighlight> === 関数定義 === Kotlinの関数はfunキーワードで宣言されます。 ;関数定義と呼出しの例:<syntaxhighlight lang="Kotlin" highlight="1-3,8"> fun power(n : Int) : Int { return n * n } fun main(args: Array<String>) { var i : Int = 10 println(power(i)) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 100 </syntaxhighlight> : 整数の仮引数を１つとり、整数の値を返す関数 power() を定義しています。 : main() の中で <code>power(i)</code> と実引数を変数 <var>i</var> として呼出しています。 ;関数定義の構文:<syntaxhighlight lang="Kotlin"> fun 関数名(仮引数リスト) : 戻値型 { 式・・・・ return 戻値式 } </syntaxhighlight> ;関数呼出しの構文:<syntaxhighlight lang="Kotlin"> 関数名(実引数リスト) </syntaxhighlight> === 引数はイミュータブル === kotlinの関数の引数で宣言された変数は、val 宣言された変数と同じくイミュータブルです。そのため、下記のように代入しようとしても、エラーとなりコンパイルできません。 ;[https://paiza.io/projects/Bd9OMV9CzHIHOOpYM588ow?language=kotlin 関数の引数に代入する例]（コンパイルエラーになります）:<syntaxhighlight lang="Kotlin" highlight=2> fun paramAssin(i: Int) : Int { i = 0 println(i) return 1 } fun main() { var i : Int = 10 i = paramAssin(i) println(i) } </syntaxhighlight> ;コンパイルエラー:<syntaxhighlight lang=text> Main.kt:2:5: error: val cannot be reassigned i = 0 ^ </syntaxhighlight> === ローカル変数 === ある関数の中で、呼び出し元やグーバル変数ですでに使用した変数と同じ変数名の変数をvar宣言する事ができますが、既存の変数とは別の、宣言場所のその関数内限定での変数として扱われ、このような仕組みを「ローカル変数」といいます。 ;コード例 <syntaxhighlight lang="Kotlin"> fun test() : Int { var i : Int = 40 i = i + 5 println("いまユーザ関数の中") println(i) return 1 } fun main() { var i : Int i =10 test() println("いまmain関数") println(i) } </syntaxhighlight> ;実行結果 <pre> いまユーザ関数の中 45 いまmain関数 10 </pre> ユーザ定義関数の中の「i」は、main関数の「i」とは別物です。 なので、ユーザ定義関数側でiが40になったり45になったりしても、ユーザ定義関数の実行が終わりmain関数に戻った際には、iの値は10に戻ってしまいます（main関数内でのユーザ定義関数の呼び出し直前のiの値が「10」なので、直前の値に戻る）。 ioi46agzz0sxgp9vmydmddu4mj7jfaj 206076 206073 2022-08-01T02:28:52Z Ef3 694 /* ローカル変数 */ ある関数の中で、変数（ローカル変数）を宣言することができます。 ローカル変数は、関数をぬけると参照することができなくなります。これを「ローカル変数のスコープは宣言された関数」といいます。 wikitext text/x-wiki == 関数 == === グローバル変数 === main() 関数のブロックの外を、仮に「グローバル領域」とします。 グローバル領域で、変数（グローバル変数）を宣言する事が出来ます。 グローバル変数は、main関数の関数で自由に参照でき、宣言などせずに前方参照ができます。 ;[https://paiza.io/projects/qn0dVRekXX-uJ_PHvt2O_A?language=kotlin コード例]:<syntaxhighlight lang="Kotlin"> var i : Int = 20 fun main() { println(i) println(j) // グローバル変数は前方参照が許されます。 } var j : Int = 42 </syntaxhighlight> ;実行結果:<syntaxhighlight lang="text"> 20 42 </syntaxhighlight> === 関数定義 === Kotlinの関数はfunキーワードで宣言されます。 ;関数定義と呼出しの例:<syntaxhighlight lang="Kotlin" highlight="1-3,8"> fun power(n : Int) : Int { return n * n } fun main(args: Array<String>) { var i : Int = 10 println(power(i)) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 100 </syntaxhighlight> : 整数の仮引数を１つとり、整数の値を返す関数 power() を定義しています。 : main() の中で <code>power(i)</code> と実引数を変数 <var>i</var> として呼出しています。 ;関数定義の構文:<syntaxhighlight lang="Kotlin"> fun 関数名(仮引数リスト) : 戻値型 { 式・・・・ return 戻値式 } </syntaxhighlight> ;関数呼出しの構文:<syntaxhighlight lang="Kotlin"> 関数名(実引数リスト) </syntaxhighlight> === 引数はイミュータブル === kotlinの関数の引数で宣言された変数は、val 宣言された変数と同じくイミュータブルです。そのため、下記のように代入しようとしても、エラーとなりコンパイルできません。 ;[https://paiza.io/projects/Bd9OMV9CzHIHOOpYM588ow?language=kotlin 関数の引数に代入する例]（コンパイルエラーになります）:<syntaxhighlight lang="Kotlin" highlight=2> fun paramAssin(i: Int) : Int { i = 0 println(i) return 1 } fun main() { var i : Int = 10 i = paramAssin(i) println(i) } </syntaxhighlight> ;コンパイルエラー:<syntaxhighlight lang=text> Main.kt:2:5: error: val cannot be reassigned i = 0 ^ </syntaxhighlight> === ローカル変数 === ある関数の中で、変数（ローカル変数）を宣言することができます。 ローカル変数は、関数をぬけると参照することができなくなります。これを「ローカル変数のスコープは宣言された関数」といいます。 ;ローカル変数の例:<syntaxhighlight lang="Kotlin"> fun sample() { var i : Int = 40 i = i + 5 println(i) } fun main() { var i : Int = 10 sample() println(i) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 45 10 </syntaxhighlight> この様に、sample()関数の中の <var>i</var> は、main関数の <var>i</var> とは、名前が同じだけの別のインスタンスです。 e46xmtapovd9zy5jjx0z6ff7rh8ih6d 0 32690 206102 186360 2022-08-01T07:03:34Z はいかぐら 45848 wikitext text/x-wiki == バイオデジタル論とは == バイオデジタル論 (ばいおでじたるろん 英:Biodigital Theory) とはスペキュレイティブ・リアリズムとニューロ・キャピタリズムの理論を思想的基盤に様々に細分化された非物質的本性としてのモナドの生成と相互主観性論の内在性を考察するデジタル以降の社会における概念である。 ==バイオデジタルの定義== ポストデジタルの解釈を起点としクリティカル・ポストヒューマニズム、トランスヒューマン、非平衡科学の自己組織化 (Self-organization) に基づくアクターネットワーク論 (ANT) の概念をも視野にいれたマルチレイヤーの理論として展開される。バイオデジタルはデジタル以降の様々な内観的 (Introspektion) な現象学の概念、バイオ・コンピュテーション、インタラクティブ・ネットワーク、生命体の形成過程における複雑系、生成の偶発性をデジタルメディアにとりいれた根源的再考に準拠している。  ==バイオデジタル論の解釈== テネシー州立大学教授のサラ・ヘイズ (Sarah Hayes) とプリマス大学トランスアート・インスティチュートのディレクターの松本良多 (Ryota Matsumoto) がアンソロポセン (Anthropocene) の階層的体系におけるデジタル以降のディスクールとしての思想としてディファインした。松本良多 (Ryota Matsumoto) はバイオテクノロジー、トランスヒューマン、分子生物学、生命体のみならず総合的なアクタントの有機合成の過程との類似性を視野に生命と流動性とその潜在的対象からバイオデジタルを生命の受動的自我のメタ科学として解釈している。 ==外部リンク== * [https://www.tandfonline.com/doi/full/10.1080/00131857.2020.1867108/a/ バイオデジタル論とコンフィギャレーション] * [https://roadrunner.lasierra.edu/interview-with-ryota-matsumoto-artist/a/ 松本良多教授との対話、ルイジアナ大学ジャーナル] * [https://dic.nicovideo.jp/a/ポストデジタル・アート　バイオデジタル・アート以降] {{デフォルトソート:b}} [[カテゴリ:人文科学]] [[カテゴリ:書庫]] 3n87ia4492mj8a234eck2kh2olf28gp 0 35265 206053 2022-07-31T12:26:40Z 椎楽 32225 初めの一歩 wikitext text/x-wiki == ソクラテスの生涯 == 紀元前469年ごろ生～紀元前399年没。古代ギリシャのポリスの一つであるアテネで生まれた。父は石工で母は助産師であったと伝えられる。ソクラテスの生きた時代はアテネの黄金期と没落の時代であり、彼も[[w:ペロポネソス戦争]]にも従軍した。アテネがペロポネソス戦争に敗北したことをきっかけとして[[w:衆愚政治]]におちいる中、ポリスの市民に正しい生き方を説いた。そのため、ソクラテスは倫理学の創始者とされる。 しかし、ソクラテスの活動は少なくない人々の反感を買う。しかも、民主政治をめぐる対立に巻き込まれ、ソクラテスは「国家の神々を認めず、青年を堕落させた」と告発されて公開裁判にかけられた。そこで妥協しなかったソクラテスには死刑判決が出された。弟子たちや友人が逃亡を勧めるが、それを拒否して毒杯による死刑を受け入れた。 彼は生涯著作を書くことはなかった。彼の言行は弟子である[[w:クセノポン]]や[[高等学校倫理/プラトン|プラトン]]によって伝えられた。 == 無知の知 == === 問答法 === == 善く生きること == === 魂の配慮 === === 知ることと生きること === [[カテゴリ:社会科教育|そくらてす]] [[カテゴリ:高等学校倫理|そくらてす]] ovaxajy9mvli4ztmnaofj4hytfi618u 206054 206053 2022-07-31T12:54:02Z 椎楽 32225 wikitext text/x-wiki {{Nav}} == ソクラテスの生涯 == 紀元前469年ごろ生～紀元前399年没。古代ギリシャのポリスの一つであるアテネで生まれた。父は石工で母は助産師であったと伝えられる。ソクラテスの生きた時代はアテネの黄金期と没落の時代であり、彼も[[w:ペロポネソス戦争]]にも従軍した。アテネがペロポネソス戦争に敗北したことをきっかけとして[[w:衆愚政治]]におちいる中、ポリスの市民に正しい生き方を説いた。そのため、ソクラテスは倫理学の創始者とされる。 しかし、ソクラテスの活動は少なくない人々の反感を買う。しかも、民主政治をめぐる対立に巻き込まれ、ソクラテスは「国家の神々を認めず、青年を堕落させた」と告発されて公開裁判にかけられた。そこで妥協しなかったソクラテスには死刑判決が出された。弟子たちや友人が逃亡を勧めるが、それを拒否して毒杯による死刑を受け入れた。 彼は生涯著作を書くことはなかった。彼の言行は弟子である[[w:クセノポン]]や[[高等学校倫理/プラトン|プラトン]]によって伝えられた。特にプラトンの『饗宴』『ソクラテスの弁明』『クリトン』『パイドン』にて、ソクラテスの思想がよく伝えられている。 == 無知の知 == === デルフォイ神殿の神託 === ソクラテスの友人が[[w:デルフォイ]]のアポロン神殿に出向き、「ソクラテスよりも知恵のあるものはいるか」と問うた。それに対しての神託は「ソクラテスよりも賢い者はいない」というものだった。これに、ソクラテスは驚いた。なぜなら、彼は自分がそれほど知恵のある人物だとは思っていなかったからだった。 彼は神託の真意を求めて、賢者・知者と言われる各地の政治家や思想家たちを訪ねた。そして、人間にとって大切なことなどについて問うた。だが、彼を満足させるような答えを述べられたものは一人もいなかった。 そこでソクラテスが気づいたのは、人間が生きるのに必要な「善」や「美」などについてだれも知らないということであった。むしろ、世の中で賢者とか知者と呼ばれる人は知らないことに気付かず、知っていると思い込んでいるにすぎない。しかし、ソクラテスは'''自分が何も知らないということを知っている'''ことに気付いたのだった。 === 問答法 === == 善く生きること == === 魂の配慮 === === 知ることと生きること === [[カテゴリ:社会科教育|そくらてす]] [[カテゴリ:高等学校倫理|そくらてす]] 3tzl0em3q91891vszu0mtsftsihyuxn 0 35266 206077 2022-08-01T04:04:15Z Ef3 694 import from: https://en.wikibooks.org/w/index.php?title=Introduction_to_Software_Engineering&oldid=3457910 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | __TOC__ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} 5wkk24dybeyil3jhzbrejk5pxk5ol59 206078 206077 2022-08-01T04:24:31Z Ef3 694 /*section=0*/和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | __TOC__ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} iyj3sstputzhquufha32nmqptcfla16 206079 206078 2022-08-01T04:27:01Z Ef3 694 __TOC__ wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} t7e4x13nnrf4nj0bjc28ct26i6zdrk2 206080 206079 2022-08-01T04:31:38Z Ef3 694 /* ソフトウェア工学 */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} rkzxfwn213iwew2bi5ntn0kzmsyqwwj 206081 206080 2022-08-01T04:34:43Z Ef3 694 /* UML */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} iswufw2ec3mol6zmdh2v7g1f7us4fch 206082 206081 2022-08-01T04:41:48Z Ef3 694 /* プロセスと手法 */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} pvuwvxmsgtq3vk6d4uhrqb8pgalmh0p 206083 206082 2022-08-01T04:45:44Z Ef3 694 /* 計画 */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} k30kv30kt3ino1c3z1nufufeq7jih4h 206084 206083 2022-08-01T04:49:36Z Ef3 694 /* プロジェクト管理 */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロジェクト管理 === * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} o9cp5tlkxhxia3g8349x17w6glvs32b 206085 206084 2022-08-01T04:54:08Z Ef3 694 /* アーキテクチャーとデザイン */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロジェクト管理 === * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ---- === アーキテクチャーとデザイン === * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} refe8r968hhrpzgow9lvzgrzbipx3i1 206086 206085 2022-08-01T05:01:51Z Ef3 694 /* 実装 */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロジェクト管理 === * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ---- === アーキテクチャーとデザイン === * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 実装 === * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} dihgvhsdu9kjhitmnnz714xnrajvr81 206087 206086 2022-08-01T05:09:36Z Ef3 694 /* テスト */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロジェクト管理 === * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ---- === アーキテクチャーとデザイン === * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 実装 === * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === テスト === * [[/テスト]] * [[/テスト/ユニットテスト]] * [[/テスト/プロファイリング]] * [[/テスト/テスト駆動開発]] * [[/テスト/リファクタリング]] * [[/ツール/テストツール]] * [[/ツール/コード網羅率]] * [[/ツール/プロファイリング]] * [[/テスト/Labs]] === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} 5a1jccb9y6kit8fx9oy8mnwd3i3mxqh 206088 206087 2022-08-01T05:32:50Z Ef3 694 /* ソフトウェア品質 */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロジェクト管理 === * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ---- === アーキテクチャーとデザイン === * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 実装 === * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === テスト === * [[/テスト]] * [[/テスト/ユニットテスト]] * [[/テスト/プロファイリング]] * [[/テスト/テスト駆動開発]] * [[/テスト/リファクタリング]] * [[/ツール/テストツール]] * [[/ツール/コード網羅率]] * [[/ツール/プロファイリング]] * [[/テスト/Labs]] === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === ソフトウェア品質 === * [[/品質]] * [[/品質/静的解析]] * [[/品質/指標]] * [[/品質/ソフトウェア・パッケージの指標]] * [[/品質/可視化]] * [[/品質/コードレビュー]] * [[/品質/コード審査]] * [[/ツール/静的コード解析]] * [[/品質/Labs]] === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} 4t6aejl5ee3m9612xads6sfbdbwpi05 206089 206088 2022-08-01T05:36:48Z Ef3 694 /*開発と保守 */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロジェクト管理 === * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ---- === アーキテクチャーとデザイン === * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 実装 === * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === テスト === * [[/テスト]] * [[/テスト/ユニットテスト]] * [[/テスト/プロファイリング]] * [[/テスト/テスト駆動開発]] * [[/テスト/リファクタリング]] * [[/ツール/テストツール]] * [[/ツール/コード網羅率]] * [[/ツール/プロファイリング]] * [[/テスト/Labs]] === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === ソフトウェア品質 === * [[/品質]] * [[/品質/静的解析]] * [[/品質/指標]] * [[/品質/ソフトウェア・パッケージの指標]] * [[/品質/可視化]] * [[/品質/コードレビュー]] * [[/品質/コード審査]] * [[/ツール/静的コード解析]] * [[/品質/Labs]] === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 開発と保守 === * [[/開発]] * [[/開発/保守]] * [[/開発/展開]] * [[/ツール/ビルドツール]] * [[/ツール/継続的インテグレーション]] * [[/ツール/バグトラッキングシステム]] * [[/開発/Labs]] === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} c2g6kv7sn9m579773skkoeessh09ro1 206090 206089 2022-08-01T05:40:24Z Ef3 694 /* リエンジニアリング */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロジェクト管理 === * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ---- === アーキテクチャーとデザイン === * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 実装 === * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === テスト === * [[/テスト]] * [[/テスト/ユニットテスト]] * [[/テスト/プロファイリング]] * [[/テスト/テスト駆動開発]] * [[/テスト/リファクタリング]] * [[/ツール/テストツール]] * [[/ツール/コード網羅率]] * [[/ツール/プロファイリング]] * [[/テスト/Labs]] === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === ソフトウェア品質 === * [[/品質]] * [[/品質/静的解析]] * [[/品質/指標]] * [[/品質/ソフトウェア・パッケージの指標]] * [[/品質/可視化]] * [[/品質/コードレビュー]] * [[/品質/コード審査]] * [[/ツール/静的コード解析]] * [[/品質/Labs]] === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 開発と保守 === * [[/開発]] * [[/開発/保守]] * [[/開発/展開]] * [[/ツール/ビルドツール]] * [[/ツール/継続的インテグレーション]] * [[/ツール/バグトラッキングシステム]] * [[/開発/Labs]] === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === リエンジニアリング === * [[/リエンジニアリング]] * [[/リエンジニアリング/リバースエンジニアリング]] * [[/リエンジニアリング/ラウンドトリップエンジニアリング]] * [[/ツール/デコンパイラー]] * [[/ツール/難読化]] * [[/リエンジニアリング/Labs]] === Other === * [[/Other|Introduction]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} r5ibqfdk1321nacwtd0sarsutpuhktt 206091 206090 2022-08-01T05:41:13Z Ef3 694 /* その他 */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロジェクト管理 === * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ---- === アーキテクチャーとデザイン === * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 実装 === * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === テスト === * [[/テスト]] * [[/テスト/ユニットテスト]] * [[/テスト/プロファイリング]] * [[/テスト/テスト駆動開発]] * [[/テスト/リファクタリング]] * [[/ツール/テストツール]] * [[/ツール/コード網羅率]] * [[/ツール/プロファイリング]] * [[/テスト/Labs]] === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === ソフトウェア品質 === * [[/品質]] * [[/品質/静的解析]] * [[/品質/指標]] * [[/品質/ソフトウェア・パッケージの指標]] * [[/品質/可視化]] * [[/品質/コードレビュー]] * [[/品質/コード審査]] * [[/ツール/静的コード解析]] * [[/品質/Labs]] === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 開発と保守 === * [[/開発]] * [[/開発/保守]] * [[/開発/展開]] * [[/ツール/ビルドツール]] * [[/ツール/継続的インテグレーション]] * [[/ツール/バグトラッキングシステム]] * [[/開発/Labs]] === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === リエンジニアリング === * [[/リエンジニアリング]] * [[/リエンジニアリング/リバースエンジニアリング]] * [[/リエンジニアリング/ラウンドトリップエンジニアリング]] * [[/ツール/デコンパイラー]] * [[/ツール/難読化]] * [[/リエンジニアリング/Labs]] === Other === * [[/Other|Introduction]] ---- === その他 === * [[その他]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} 22fhvg9564ud84iurkje8ck9vh2v7z6 206092 206091 2022-08-01T05:44:14Z Ef3 694 /* 附録 */ 和訳 wikitext text/x-wiki {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人が長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ---- === ソフトウェア工学 === * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ---- * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Examples|Labs]] === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロセスと手法 === * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 計画 === * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === プロジェクト管理 === * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ---- === アーキテクチャーとデザイン === * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 実装 === * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === テスト === * [[/テスト]] * [[/テスト/ユニットテスト]] * [[/テスト/プロファイリング]] * [[/テスト/テスト駆動開発]] * [[/テスト/リファクタリング]] * [[/ツール/テストツール]] * [[/ツール/コード網羅率]] * [[/ツール/プロファイリング]] * [[/テスト/Labs]] === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === ソフトウェア品質 === * [[/品質]] * [[/品質/静的解析]] * [[/品質/指標]] * [[/品質/ソフトウェア・パッケージの指標]] * [[/品質/可視化]] * [[/品質/コードレビュー]] * [[/品質/コード審査]] * [[/ツール/静的コード解析]] * [[/品質/Labs]] === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === 開発と保守 === * [[/開発]] * [[/開発/保守]] * [[/開発/展開]] * [[/ツール/ビルドツール]] * [[/ツール/継続的インテグレーション]] * [[/ツール/バグトラッキングシステム]] * [[/開発/Labs]] === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ---- === リエンジニアリング === * [[/リエンジニアリング]] * [[/リエンジニアリング/リバースエンジニアリング]] * [[/リエンジニアリング/ラウンドトリップエンジニアリング]] * [[/ツール/デコンパイラー]] * [[/ツール/難読化]] * [[/リエンジニアリング/Labs]] === Other === * [[/Other|Introduction]] ---- === その他 === * [[その他]] === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} ---- === 附録 === * [[/用語集]] * [[/資料]] * [[/著者]] * [[/ライセンス]] s37pr382ujpbpvvlyo5gb37tlp1f5vv 206093 206092 2022-08-01T05:51:45Z Ef3 694 原文をコメント化；リンク先を翻訳してタイトルが妥当か確認してから立頁する予定（ページ移動は煩雑になりがちなので） wikitext text/x-wiki <!-- {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- --> <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人を長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === ソフトウェア工学 === <!-- === Software Engineering === * [[/Introduction/]] {{stage short|75%|Mar 02 2011}} * [[/History/]] {{stage short|75%|Mar 02, 2011}} * [[/Software Engineer/]] {{stage short|75%|Mar 02, 2011}} ----> * [[/概論]] * [[/歴史]] * [[/ソフトウェアエンジニア]] === UML === <!-- * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ----> * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Labs]] === プロセスと手法 === <!--- === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === 計画 === <!--- === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === プロジェクト管理 === <!--- === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === アーキテクチャーとデザイン === <!-- === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ----> * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === 実装 === <!-- === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === テスト === <!-- === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/テスト]] * [[/テスト/ユニットテスト]] * [[/テスト/プロファイリング]] * [[/テスト/テスト駆動開発]] * [[/テスト/リファクタリング]] * [[/ツール/テストツール]] * [[/ツール/コード網羅率]] * [[/ツール/プロファイリング]] * [[/テスト/Labs]] === ソフトウェア品質 === <!-- === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/品質]] * [[/品質/静的解析]] * [[/品質/指標]] * [[/品質/ソフトウェア・パッケージの指標]] * [[/品質/可視化]] * [[/品質/コードレビュー]] * [[/品質/コード審査]] * [[/ツール/静的コード解析]] * [[/品質/Labs]] === 開発と保守 === <!-- === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/開発]] * [[/開発/保守]] * [[/開発/展開]] * [[/ツール/ビルドツール]] * [[/ツール/継続的インテグレーション]] * [[/ツール/バグトラッキングシステム]] * [[/開発/Labs]] === リエンジニアリング === <!--- === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/リエンジニアリング]] * [[/リエンジニアリング/リバースエンジニアリング]] * [[/リエンジニアリング/ラウンドトリップエンジニアリング]] * [[/ツール/デコンパイラー]] * [[/ツール/難読化]] * [[/リエンジニアリング/Labs]] === その他 === * [[その他]] === 附録 === <!-- === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} ----> * [[/用語集]] * [[/資料]] * [[/著者]] * [[/ライセンス]] 3bvc6s3zhlhs9uar5717eod4vb73tt4 206094 206093 2022-08-01T06:02:12Z Ef3 694 /* ソフトウェア工学 */ s/概論/緒論/ wikitext text/x-wiki <!-- {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- --> <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人を長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明します。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === ソフトウェア工学 === * [[/緒論]]<!-- Introduction --> * [[/歴史]]<!-- History --> * [[/ソフトウェアエンジニア]]<!-- Software Engineer --> === UML === <!-- * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ----> * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Labs]] === プロセスと手法 === <!--- === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === 計画 === <!--- === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === プロジェクト管理 === <!--- === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === アーキテクチャーとデザイン === <!-- === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ----> * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === 実装 === <!-- === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === テスト === <!-- === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/テスト]] * [[/テスト/ユニットテスト]] * [[/テスト/プロファイリング]] * [[/テスト/テスト駆動開発]] * [[/テスト/リファクタリング]] * [[/ツール/テストツール]] * [[/ツール/コード網羅率]] * [[/ツール/プロファイリング]] * [[/テスト/Labs]] === ソフトウェア品質 === <!-- === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/品質]] * [[/品質/静的解析]] * [[/品質/指標]] * [[/品質/ソフトウェア・パッケージの指標]] * [[/品質/可視化]] * [[/品質/コードレビュー]] * [[/品質/コード審査]] * [[/ツール/静的コード解析]] * [[/品質/Labs]] === 開発と保守 === <!-- === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/開発]] * [[/開発/保守]] * [[/開発/展開]] * [[/ツール/ビルドツール]] * [[/ツール/継続的インテグレーション]] * [[/ツール/バグトラッキングシステム]] * [[/開発/Labs]] === リエンジニアリング === <!--- === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/リエンジニアリング]] * [[/リエンジニアリング/リバースエンジニアリング]] * [[/リエンジニアリング/ラウンドトリップエンジニアリング]] * [[/ツール/デコンパイラー]] * [[/ツール/難読化]] * [[/リエンジニアリング/Labs]] === その他 === * [[その他]] === 附録 === <!-- === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} ----> * [[/用語集]] * [[/資料]] * [[/著者]] * [[/ライセンス]] 2tvx61kl100cno02uge0003tynosxkg 206098 206094 2022-08-01T06:38:28Z Ef3 694 常体に統一 wikitext text/x-wiki <!-- {| width=100% |- | valign=top width=30% | _　_TOC_　_ | valign=top | '''Status: This book is still under construction.''' This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. [[w:Software engineering|Software Engineering]] is about teams and it is about quality. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication on a team and with internal and external stakeholders. Teams do not consist only of developers, but also of quality assurance testers, systems architects, system/platform engineers, customers, project managers and other stakeholders. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics and improve the quality in those areas. The code should follow certain standards to make it easier for a team to work together. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software and other maintenance can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, the book covers project management skills. Software projects can be so large that we have to do careful planning. We walk through the factors that cause a project to fail and the success factors. Last but not least, a good software engineer, like any engineer, needs tools, and in this book we cover good tools for everyday use on large, and small, projects. We invite you to join us on the journey through the mazes of software engineering! |} {{PDF version|Introduction_to_Software_Engineering|2489 KB|Introduction to Software Engineering}} {{Print version|/Print version}} {{Reading level|Intermediate}} {{Book Search}} * [[/Preface/]] {{stage short|75%|Mar 02 2011}} ---- --> <div style="width: fit-content;float:left; margin: 1rem">__TOC__</div> '''状態：本書はまだ作成中です。''' 本書は、ソフトウェア工学の入門書であり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''software engineering'' )は、チームに関するものであり、品質に関するものである。 解決すべき問題は非常に複雑であったり、大規模であったりするため、一人の開発者ではもう解決できない。 また、ソフトウェア工学は、チーム内や社内外の関係者とのコミュニケーションについても重要である。 チームは開発者だけでなく、品質保証テスター、システム設計者、システム／プラットフォームエンジニア、顧客、プロジェクトマネージャー、その他の利害関係者( ''stakeholders'' )で構成されている。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、ユニットテストを書くことも必要である。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見し、その部分の品質を向上させることができなければならない。 コードは、チームが一緒に作業しやすいように、一定の標準に従っている必要がある。 大規模なプロジェクトでは、ソフトウェアのメンテナンスなど、多くの人を長い間、忙しく働かせることになる。 プロジェクトの成否を左右する要素は非常に多いため、本書ではプロジェクトマネジメントのスキルについて取り上げている。 ソフトウェアプロジェクトは非常に大規模なものになるため、綿密な計画を立てなければならない。 プロジェクトが失敗する要因と成功する要因について説明する。 最後に、優れたソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とする。 本書では、大規模なプロジェクトから小規模なプロジェクトまで、日常的に使用する優れたツールについて取り上げている。 本書では、大小さまざまなプロジェクトで日常的に使用できる優れたツールを紹介している。 皆さんも、ソフトウェア工学の迷宮への旅にでよう！ <br style="clear:both"> === ソフトウェア工学 === * [[/緒論]]<!-- Introduction --> * [[/歴史]]<!-- History --> * [[/ソフトウェアエンジニア]]<!-- Software Engineer --> === UML === <!-- * [[/UML/Introduction|Introduction]] {{stage short|75%|Mar 3, 2011}} * [[/UML|Models and Diagrams]] {{stage short|75%|Mar 3, 2011}} * [[/Tools/Modelling and Case Tools|Tools: Modelling and Case]] {{stage short|25%|Feb 27, 2011}} * [[/UML/Examples|Labs]] {{stage short|75%|Mar 4, 2011}} ----> * [[/UML/イントロダクション|イントロダクション]] * [[/UML|モデルとダイアグラム]] * [[/ツール/モデリングとケースツール|ツール: モデリングとケース]] * [[/UML/Labs]] === プロセスと手法 === <!--- === Process & Methodology === * [[/Process|Introduction]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Methodology|Methodology]] {{stage short|50%|Feb 18, 2011}} * [[/Process/V-Model|V-Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Agile Model|Agile Model]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Standards|Standards]] {{stage short|50%|Feb 18, 2011}} * [[/Process/Life Cycle|Life Cycle]] {{stage short|25%|Feb 18, 2011}} * [[/Process/Rapid Application Development|Rapid Application Development]] {{stage short|25%|Feb 26, 2011}} * [[/Process/Extreme Programming|Extreme Programming]] {{stage short|25%|Feb 26, 2011}} * [[/Process/PSP|Personal Software Process]] {{stage short|25%|26 June 2014}} * [[/Tools/Process Tools|Tools: Process]] {{stage short|0%|Mar 8, 2011}} * [[/Process/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/プロセス]] * [[/プロセス/手法]] * [[/プロセス/Vモデル]] * [[/プロセス/アジャイルモデル]] * [[/プロセス/標準]] * [[/プロセス/ライフサイクル]] * [[/プロセス/ラピッドアプリケーション開発]] * [[/プロセス/エクストリーム・プログラミング]] * [[/プロセス/パーソナルソフトウェアプロセス]] * [[/ツール/プロセスツール]] * [[/プロセス/Labs]] === 計画 === <!--- === Planning === * [[/Planning/Requirements|Requirements]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Requirements Management|Requirements Management]] {{stage short|25%|Feb 27, 2011}} * [[/Planning/Specification|Specification]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Planning Tools|Tools: Planning]] {{stage short|0%|Mar 8, 2011}} * [[/Planning/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/計画/要求要件]] * [[/計画/要求管理]] * [[/計画/仕様書]] * [[/ツール/計画ツール]] * [[/計画/Labs]] === プロジェクト管理 === <!--- === Project Management === * [[/Project Management|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Software Estimation|Software Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Cost Estimation|Cost Estimation]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Development Speed|Development Speed]] * [[/Tools/Project Management|Tools: Project Management]] {{stage short|25%|Feb 27, 2011}} * [[/Project Management/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/プロジェクト管理]] * [[/プロジェクト管理/ソフトウェア見積]] * [[/プロジェクト管理/コスト見積]] * [[/プロジェクト管理/開発速度]] * [[/ツール/プロジェクト管理]] * [[/プロジェクト管理/Labs]] === アーキテクチャーとデザイン === <!-- === Architecture & Design === * [[/Architecture|Introduction]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design|Design]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Design Patterns|Design Patterns]] {{stage short|75%|Mar 8, 2011}} * [[/Architecture/Anti-Patterns|Anti-Patterns]] {{stage short|75%|Mar 9, 2011}} * [[/Tools/Architecture Tools|Tools: Architecture]] {{stage short|0%|Mar 8, 2011}} * [[/Architecture/Labs|Labs]] {{stage short|25%|Mar 8, 2011}} ----> * [[/アーキテクチャー]] * [[/アーキテクチャー/デザイン]] * [[/アーキテクチャー/デザイン・パターン]] * [[/アーキテクチャー/アンチ・パターン]] * [[/ツール/アーキテクチャー・ツール]] * [[/アーキテクチャー/Labs]] === 実装 === <!-- === Implementation === * [[/Implementation|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Code Convention|Code Convention]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Good Coding|Good Coding]] * [[/Implementation/Documentation|Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Compiler|Tools: Compiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Debugger|Tools: Debugger]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/IDE|Tools: IDE]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/GUI Builder|Tools: GUI Builder]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Source Control|Tools: Source Control]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Software Documentation|Tools: Software Documentation]] {{stage short|25%|Feb 27, 2011}} * [[/Implementation/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/実装]] * [[/実装/コーディング規約]] * [[/実装/ドキュメンテーション]] * [[/実装/良質なコーディング]] * [[/ツール/コンパイラー]] * [[/ツール/デバッガー]] * [[/ツール/IDE]] * [[/ツール/GUIビルダー]] * [[/ツール/ソースコントロール]] * [[/ツール/ソフトウェアドキュメンテーション]] * [[/実装/Labs]] === テスト === <!-- === Testing === * [[/Testing|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Unit Tests|Unit Tests]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Profiling|Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Test-driven Development|Test-driven Development]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Refactoring|Refactoring]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Testing Tools|Tools: Testing]] {{stage short|0%|Mar 8, 2011}} * [[/Tools/Code Coverage|Tools: Code Coverage]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Profiling|Tools: Profiling]] {{stage short|25%|Feb 27, 2011}} * [[/Testing/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/テスト]] * [[/テスト/ユニットテスト]] * [[/テスト/プロファイリング]] * [[/テスト/テスト駆動開発]] * [[/テスト/リファクタリング]] * [[/ツール/テストツール]] * [[/ツール/コード網羅率]] * [[/ツール/プロファイリング]] * [[/テスト/Labs]] === ソフトウェア品質 === <!-- === Software Quality === * [[/Quality|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Static Analysis|Static Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics|Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Metrics2|Software Package Metrics]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Visualization|Visualization]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Review|Code Review]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Code Inspection|Code Inspection]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Static Code Analysis|Tools: Static Code Analysis]] {{stage short|25%|Feb 27, 2011}} * [[/Quality/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/品質]] * [[/品質/静的解析]] * [[/品質/指標]] * [[/品質/ソフトウェア・パッケージの指標]] * [[/品質/可視化]] * [[/品質/コードレビュー]] * [[/品質/コード審査]] * [[/ツール/静的コード解析]] * [[/品質/Labs]] === 開発と保守 === <!-- === Deployment & Maintenance === * [[/Deployment|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Maintenance|Maintenance]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Evolution|Evolution]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Build Tools|Tools: Build Tools]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Continuous Integration|Tools: Continuous Integration]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Bug tracking system|Tools: Bug Tracking]] {{stage short|25%|Feb 27, 2011}} * [[/Deployment/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/開発]] * [[/開発/保守]] * [[/開発/展開]] * [[/ツール/ビルドツール]] * [[/ツール/継続的インテグレーション]] * [[/ツール/バグトラッキングシステム]] * [[/開発/Labs]] === リエンジニアリング === <!--- === Re-engineering === * [[/Reengineering|Introduction]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Reverse Engineering|Reverse Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Round-trip Engineering|Round-trip Engineering]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Decompiler|Tools: Decompiler]] {{stage short|25%|Feb 27, 2011}} * [[/Tools/Obfuscation|Tools: Obfuscation]] {{stage short|25%|Feb 27, 2011}} * [[/Reengineering/Labs|Labs]] {{stage short|0%|Mar 8, 2011}} ----> * [[/リエンジニアリング]] * [[/リエンジニアリング/リバースエンジニアリング]] * [[/リエンジニアリング/ラウンドトリップエンジニアリング]] * [[/ツール/デコンパイラー]] * [[/ツール/難読化]] * [[/リエンジニアリング/Labs]] === その他 === * [[その他]] === 附録 === <!-- === Appendices === * [[/Glossary/]] * [[/Resources/]] * [[/Authors/]] * [[Wikibooks:Copyrights|Licensing]] {{Shelves|Software engineering}} {{alphabetical|I}} {{status|0%}} ----> * [[/用語集]] * [[/資料]] * [[/著者]] * [[/ライセンス]] 18zip8ak67tpiplcm3p47n6izy2e35k 0 35267 206095 2022-08-01T06:03:43Z Ef3 694 import from: https://en.wikibooks.org/w/index.php?title=Introduction_to_Software_Engineering/Introduction&oldid=3649282 wikitext text/x-wiki __NOTOC__ == Introduction == This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. Software engineering is about teams. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication. Teams do not consist only of developers, but also of testers, architects, system engineers, customer, project managers, etc. Software projects can be so large that we have to do careful planning. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics. They tell us if our code follows certain standards. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, we also need to learn a little about project management and its pitfalls, but especially what makes projects successful. And last but not least, a good software engineer, like any engineer, needs tools, and you need to know about them. ==== Developers Work in Teams ==== In your beginning semesters you were coding as individuals. The problems you were solving were small enough so one person could master them. In the real world this is different:- the problem sizes and time constraints are such that only teams can solve those problems. For teams to work effectively they need a language to communicate (UML). Also teams do not consist only of developers, but also of testers, architects, system engineers and most importantly the customer. So we need to learn about what makes good teams, how to communicate with the customer, and how to document not only the source code, but everything related to the software project. ==== New Language ==== In previous courses we learned languages, such as Java or C++, and how to turn ideas into code. But these ideas are independent of the language. With Unified Modeling Language (UML) we will see a way to describe code independently of language, and more importantly, we learn to think in a level of abstraction which is higher by one level. UML can be an invaluable communication and documentation tool. We will learn to see the big picture: patterns. This gives us yet one higher level of abstraction. Again this increases our vocabulary to communicate more effectively with our peers. Also, it is a fantastic way to learn from our seniors. This is essential for designing large software systems. ==== Measurement ==== Also just being able to write software, doesn’t mean that the software is any good. Hence, we will discover what makes good software, and how to measure software quality. On one hand we should be able to analyse existing source code through static analysis and measuring metrics, but also how do we guarantee that our code meets certain quality standards? Testing is also important in this context, it guarantees high quality products. ==== New Tools ==== Up to now, you may have come to know about an IDE, a compiler and a debugger. But there are many more tools at the disposal of a software engineer. There are tools that allow us to work in teams, to document our software, to assist and monitor the whole development effort. There are tools for software architects, tools for testing and profiling, automation and re-engineering. {{BookCat}} t5fhfhhkiur3zio0udru9kke9cun08c 206096 206095 2022-08-01T06:19:52Z Ef3 694 /* 緒論 */ 和訳 wikitext text/x-wiki __NOTOC__ == Introduction == This book is an introduction to the art of software engineering. It is intended as a textbook for an undergraduate level course. Software engineering is about teams. The problems to solve are so complex or large, that a single developer cannot solve them anymore. Software engineering is also about communication. Teams do not consist only of developers, but also of testers, architects, system engineers, customer, project managers, etc. Software projects can be so large that we have to do careful planning. Implementation is no longer just writing code, but it is also following guidelines, writing documentation and also writing unit tests. But unit tests alone are not enough. The different pieces have to fit together. And we have to be able to spot problematic areas using metrics. They tell us if our code follows certain standards. Once we are finished coding, that does not mean that we are finished with the project: for large projects maintaining software can keep many people busy for a long time. Since there are so many factors influencing the success or failure of a project, we also need to learn a little about project management and its pitfalls, but especially what makes projects successful. And last but not least, a good software engineer, like any engineer, needs tools, and you need to know about them. ---- == 緒論 == 本書は、ソフトウェア工学の入門書でり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''[[W:en:Software engineering|software engineering]]'' )ははチームで行うものである。 解決すべき問題があまりにも複雑であったり、大規模であったりするため、一人の開発者ではもう解決できないのである。 また、ソフトウェア工学はコミュニケーションも重要である。チームは開発者だけでなく、テスター、アーキテクト、システムエンジニア、顧客、プロジェクトマネージャーなど、さまざまなメンバーで構成されている。ソフトウェアプロジェクトは非常に大規模になるため、綿密な計画を立てなければならない。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、さらにユニットテストも書かなければならない。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組み合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見できなければならない。測定基準は、私たちのコードが特定の標準に従っているかどうかを教えてくれる。 大規模なプロジェクトでは、ソフトウェアのメンテナンスに多くの人が長い間忙殺されることがある。 プロジェクトの成否を左右する要素は非常に多いので、プロジェクトマネジメントとその落とし穴、特にプロジェクトを成功に導く要素について少し学ぶ必要がある。 そして最後になるが、優秀なソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とし、そのツールについて知る必要がある。 ==== Developers Work in Teams ==== In your beginning semesters you were coding as individuals. The problems you were solving were small enough so one person could master them. In the real world this is different:- the problem sizes and time constraints are such that only teams can solve those problems. For teams to work effectively they need a language to communicate (UML). Also teams do not consist only of developers, but also of testers, architects, system engineers and most importantly the customer. So we need to learn about what makes good teams, how to communicate with the customer, and how to document not only the source code, but everything related to the software project. ---- === 開発者はチームで仕事をする === 最初のころ、皆さんは個人でコーディングしていた。 解決する問題は小さいので、一人で解決することができる。 現実の世界では、問題の大きさや時間の制約から、チームでなければ解決できないような問題がある。 チームが効果的に機能するためには、コミュニケーションするための言語（UML）が必要である。また、チームは開発者だけでなく、テスター、アーキテクト、システムエンジニア、そして最も重要な顧客からも構成されている。そこで、良いチームとは何か、顧客とのコミュニケーションの取り方、ソースコードだけでなく、ソフトウェアプロジェクトに関わる全てのことを文書化する方法などを学ぶ必要がある。 ==== New Language ==== In previous courses we learned languages, such as Java or C++, and how to turn ideas into code. But these ideas are independent of the language. With Unified Modeling Language (UML) we will see a way to describe code independently of language, and more importantly, we learn to think in a level of abstraction which is higher by one level. UML can be an invaluable communication and documentation tool. We will learn to see the big picture: patterns. This gives us yet one higher level of abstraction. Again this increases our vocabulary to communicate more effectively with our peers. Also, it is a fantastic way to learn from our seniors. This is essential for designing large software systems. ---- === 新しい言語 === これまでの講座では、JavaやC++などの言語と、アイデアをコードにする方法を学んだ。しかし、これらのアイデアは言語から独立している。 統一モデリング言語（ ''Unified Modeling Language'' ; UML）を使えば、言語から独立してコードを記述する方法を見ることができるし、さらに重要なことに、1レベル上の抽象化レベルで考えることを学ぶことができる。 UMLは、コミュニケーションとドキュメンテーションのツールとして非常に有効である。 私たちは、パターンという全体像を見ることを学ぶ。これにより、さらに一段高い抽象度を得ることができる。 ここでもまた、仲間とのコミュニケーションをより効果的にするための語彙が増える。また、先輩から学ぶことも素晴らしい方法である。 これは、大規模なソフトウェアシステムを設計する際に必要不可欠なことである。 ==== Measurement ==== Also just being able to write software, doesn’t mean that the software is any good. Hence, we will discover what makes good software, and how to measure software quality. On one hand we should be able to analyse existing source code through static analysis and measuring metrics, but also how do we guarantee that our code meets certain quality standards? Testing is also important in this context, it guarantees high quality products. ---- === 測定 === また、ソフトウェアを書くことができるだけでは、そのソフトウェアが良いものであるとは限らない。そこで、何が良いソフトウェアなのか、そして、どのようにソフトウェアの品質を測定するのかを明らかにする。静的解析( ''static analysis'' )や測定基準( ''measuring metrics'' )によって既存のソースコードを分析できるようになる一方で、コードが一定の品質基準を満たしていることをどのように保証すればよいのであろうか？この文脈では、テストも重要であり、高品質の製品を保証するものである。 ==== New Tools ==== Up to now, you may have come to know about an IDE, a compiler and a debugger. But there are many more tools at the disposal of a software engineer. There are tools that allow us to work in teams, to document our software, to assist and monitor the whole development effort. There are tools for software architects, tools for testing and profiling, automation and re-engineering. {{BookCat}} ---- === 新しいツール === これまで、IDE、コンパイラー、デバッガーについて知っていただけたかと思う。しかし、ソフトウェア・エンジニアが自由に使えるツールはもっとたくさんある。 チームで作業するためのツール、ソフトウェアを文書化するためのツール、開発作業全体を支援・監視するためのツールなどがある。 ソフトウェアアーキテクトのためのツール、テストやプロファイリングのためのツール、自動化やリエンジニアリングのためのツールもある。 0voszrgwcm0nsq6xkcfzbmqrbw83sk1 206097 206096 2022-08-01T06:36:10Z Ef3 694 原文抹消；セクションに原題を併記 wikitext text/x-wiki {{Nav}} __NOTOC__ == 緒論 -- Introduction == 本書は、ソフトウェア工学の入門書であり、学部レベルのコースの教科書として意図されている。 [[w:ソフトウェア工学|ソフトウェア工学]]( ''[[W:en:Software engineering|software engineering]]'' )はチームで行うものである。 解決すべき問題があまりにも複雑であったり、大規模であったりするため、一人の開発者ではもう解決できないのである。 また、ソフトウェア工学はコミュニケーションも重要である。チームは開発者だけでなく、テスター、アーキテクト、システムエンジニア、顧客、プロジェクトマネージャーなど、さまざまなメンバーで構成されている。ソフトウェアプロジェクトは非常に大規模になるため、綿密な計画を立てなければならない。 実装は、もはやコードを書くだけでなく、ガイドラインに従い、ドキュメントを書き、さらにユニットテストも書かなければならない。 しかし、ユニットテストだけでは十分ではない。さまざまなピースが組合わされなければならないのである。 そして、測定基準を使って問題のある部分を発見できなければならない。測定基準は、私たちのコードが特定の標準に従っているかどうかを教えてくれる。 大規模なプロジェクトでは、ソフトウェアの保守に多くの人が長い間忙殺されることがある。 プロジェクトの成否を左右する要素は非常に多いので、プロジェクト管理とその落とし穴、特にプロジェクトを成功に導く要素について少し学ぶ必要がある。 そして最後になるが、優秀なソフトウェアエンジニアは、他のエンジニアと同様に、ツールを必要とし、そのツールについて知る必要がある。 === 開発者はチームで仕事をする -- Developers Work in Teams === 最初のころ、皆さんは個人でコーディングしていた。 解決すべき問題は小さかったので一人で解決することができた。 現実の世界では、問題の大きさや時間の制約から、チームでなければ解決できないような問題がある。 チームが効果的に機能するためには、コミュニケーションするための言語（UML）が必要である。 また、チームは開発者だけでなく、テスター、アーキテクト、システムエンジニア、そして最も重要な顧客からも構成されている。 そこで、良いチームとは何か、顧客とのコミュニケーションの取り方、ソースコードだけでなく、ソフトウェアプロジェクトに関わる全てのことを文書化する方法などを学ぶ必要がある。 === 新しい言語 -- New Language === これまでの講座では、JavaやC++などの言語と、アイデアをコードにする方法を学んだ。しかし、これらのアイデアは言語から独立している。 統一モデリング言語（ ''Unified Modeling Language'' ; UML）を使えば、言語から独立してコードを記述する方法を見ることができるし、さらに重要なことに、1レベル上の抽象化レベルで考えることを学ぶことができる。 UMLは、コミュニケーションとドキュメンテーションのツールとして非常に有効である。 私たちは、パターンという全体像を見ることを学ぶ。これにより、さらに一段高い抽象度を得ることができる。 ここでもまた、仲間とのコミュニケーションをより効果的にするための語彙が増える。また、先輩から学ぶことも素晴らしい方法である。 これは、大規模なソフトウェアシステムを設計する際に必要不可欠なことである。 === 測定 -- Measurement === また、ソフトウェアを書くことができるだけでは、そのソフトウェアが良いものであるとは限らない。そこで、何が良いソフトウェアなのか、そして、どのようにソフトウェアの品質を測定するのかを明らかにする。静的解析( ''static analysis'' )や測定基準( ''measuring metrics'' )によって既存のソースコードを分析できるようになる一方で、コードが一定の品質基準を満たしていることをどのように保証すればよいのであろうか？この文脈では、テストも重要であり、高品質の製品を保証するものである。 === 新しいツール -- New Tools === これまで、IDE、コンパイラー、デバッガーについて知っていただけたかと思う。しかし、ソフトウェア・エンジニアが自由に使えるツールはもっとたくさんある。 チームで作業するためのツール、ソフトウェアを文書化するためのツール、開発作業全体を支援・監視するためのツールなどがある。 ソフトウェアアーキテクトのためのツール、テストやプロファイリングのためのツール、自動化やリエンジニアリングのためのツールもある。 {{Nav}} q0r9w5cak8mfk26wfeqd0vdlp23exbg 0 35268 206099 2022-08-01T06:42:07Z Ef3 694 import from: https://en.wikibooks.org/w/index.php?title=Introduction_to_Software_Engineering/History&oldid=2842385 wikitext text/x-wiki __NOTOC__ == History == When the first modern digital computers appeared in the early 1940s,<ref>{{Cite book|last=Leondes|title= intelligent systems: technology and applications|year=2002| publisher=CRC Press| isbn =9780849311215 | quote = }}</ref> the instructions to make them operate were wired into the machine. At this time, people working with computers were engineers, mostly electrical engineers. This hardware centric design was not flexible and was quickly replaced with the "stored program architecture" or von Neumann architecture. Thus the first division between "hardware" and "software" began with abstraction being used to deal with the complexity of computing. Programming languages started to appear in the 1950s and this was also another major step in abstraction. Major languages such as Fortran, ALGOL, and COBOL were released in the late 1950s to deal with scientific, algorithmic, and business problems respectively. E.W. Dijkstra wrote his seminal paper, "Go To Statement Considered Harmful",<ref>{{Cite journal | last = Dijkstra | first = E. W. | authorlink = Edsger_Dijkstra | title = Go To Statement Considered Harmful | journal = [[Wikipedia:Communications of the ACM]] | volume = 11 | issue = 3 | pages = 147–148 | month = March | year = 1968 | url = http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF | accessdate = 2009-08-10 | doi = 10.1145/362929.362947}} </ref> in 1968 and David Parnas introduced the key concept of modularity and information hiding in 1972<ref> {{Cite journal | last = Parnas | first = David | authorlink = David Parnas | journal = [[Wikipedia:Communications of the ACM]] | volume = 15 | issue = 12 | pages = 1053–1058 | url = http://www.acm.org/classics/may96/ | title = On the Criteria To Be Used in Decomposing Systems into Modules | month = December | year = 1972 | accessdate = 2008-12-26 | doi = 10.1145/361598.361623 }}</ref> to help programmers deal with the ever increasing complexity of software systems. A software system for managing the hardware called an operating system was also introduced, most notably by Unix in 1969. In 1967, the Simula language introduced the object-oriented programming paradigm. These advances in software were met with more advances in computer hardware. In the mid 1970s, the microcomputer was introduced, making it economical for hobbyists to obtain a computer and write software for it. This in turn led to the now famous Personal Computer (PC) and Microsoft Windows. The Software Development Life Cycle or SDLC was also starting to appear as a consensus for centralized construction of software in the mid 1980s. The late 1970s and early 1980s saw the introduction of several new Simula-inspired object-oriented programming languages, including Smalltalk, Objective-C, and C++. Open-source software started to appear in the early 90s in the form of Linux and other software introducing the "bazaar" or decentralized style of constructing software.<ref>Raymond, Eric S. [http://www.catb.org/esr/writings/cathedral-bazaar/ ''The Cathedral and the Bazaar'']. ed 3.0. 2000.</ref> Then the World Wide Web and the popularization of the Internet hit in the mid 90s, changing the engineering of software once again. Distributed systems gained sway as a way to design systems, and the Java programming language was introduced with its virtual machine as another step in abstraction. Programmers collaborated and wrote the Agile Manifesto, which favored more lightweight processes to create cheaper and more timely software. The current definition of ''software engineering'' is still being debated by practitioners today as they struggle to come up with ways to produce software that is "cheaper, better, faster". Cost reduction has been a primary focus of the IT industry since the 1990s. Total cost of ownership represents the costs of more than just acquisition. It includes things like productivity impediments, upkeep efforts, and resources needed to support infrastructure. === References === {{Reflist}} === Further Reading === [http://en.wikipedia.org/wiki/History_of_software_engineering History of software engineering] {{BookCat}} st5gyz7v8z9gqikenfrjs446hsl35jd 206100 206099 2022-08-01T06:58:05Z Ef3 694 和訳 wikitext text/x-wiki __NOTOC__ == History == When the first modern digital computers appeared in the early 1940s,<ref>{{Cite book|last=Leondes|title= intelligent systems: technology and applications|year=2002| publisher=CRC Press| isbn =9780849311215 | quote = }}</ref> the instructions to make them operate were wired into the machine. At this time, people working with computers were engineers, mostly electrical engineers. This hardware centric design was not flexible and was quickly replaced with the "stored program architecture" or von Neumann architecture. Thus the first division between "hardware" and "software" began with abstraction being used to deal with the complexity of computing. Programming languages started to appear in the 1950s and this was also another major step in abstraction. Major languages such as Fortran, ALGOL, and COBOL were released in the late 1950s to deal with scientific, algorithmic, and business problems respectively. E.W. Dijkstra wrote his seminal paper, "Go To Statement Considered Harmful",<ref>{{Cite journal | last = Dijkstra | first = E. W. | authorlink = Edsger_Dijkstra | title = Go To Statement Considered Harmful | journal = [[Wikipedia:Communications of the ACM]] | volume = 11 | issue = 3 | pages = 147–148 | month = March | year = 1968 | url = http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF | accessdate = 2009-08-10 | doi = 10.1145/362929.362947}} </ref> in 1968 and David Parnas introduced the key concept of modularity and information hiding in 1972<ref> {{Cite journal | last = Parnas | first = David | authorlink = David Parnas | journal = [[Wikipedia:Communications of the ACM]] | volume = 15 | issue = 12 | pages = 1053–1058 | url = http://www.acm.org/classics/may96/ | title = On the Criteria To Be Used in Decomposing Systems into Modules | month = December | year = 1972 | accessdate = 2008-12-26 | doi = 10.1145/361598.361623 }}</ref> to help programmers deal with the ever increasing complexity of software systems. A software system for managing the hardware called an operating system was also introduced, most notably by Unix in 1969. In 1967, the Simula language introduced the object-oriented programming paradigm. These advances in software were met with more advances in computer hardware. In the mid 1970s, the microcomputer was introduced, making it economical for hobbyists to obtain a computer and write software for it. This in turn led to the now famous Personal Computer (PC) and Microsoft Windows. The Software Development Life Cycle or SDLC was also starting to appear as a consensus for centralized construction of software in the mid 1980s. The late 1970s and early 1980s saw the introduction of several new Simula-inspired object-oriented programming languages, including Smalltalk, Objective-C, and C++. Open-source software started to appear in the early 90s in the form of Linux and other software introducing the "bazaar" or decentralized style of constructing software.<ref>Raymond, Eric S. [http://www.catb.org/esr/writings/cathedral-bazaar/ ''The Cathedral and the Bazaar'']. ed 3.0. 2000.</ref> Then the World Wide Web and the popularization of the Internet hit in the mid 90s, changing the engineering of software once again. Distributed systems gained sway as a way to design systems, and the Java programming language was introduced with its virtual machine as another step in abstraction. Programmers collaborated and wrote the Agile Manifesto, which favored more lightweight processes to create cheaper and more timely software. The current definition of ''software engineering'' is still being debated by practitioners today as they struggle to come up with ways to produce software that is "cheaper, better, faster". Cost reduction has been a primary focus of the IT industry since the 1990s. Total cost of ownership represents the costs of more than just acquisition. It includes things like productivity impediments, upkeep efforts, and resources needed to support infrastructure. === References === {{Reflist}} === Further Reading === [http://en.wikipedia.org/wiki/History_of_software_engineering History of software engineering] {{BookCat}} ---- == 歴史 == 1940年代初頭に近代的なデジタル・コンピューターが初めて登場したとき、<ref>{{Cite book|last=Leondes|title= intelligent systems: technology and applications ISBN:9780849311215 |year=2002| publisher=CRC Press| quote = }}</ref> それを作動させる命令は機械に配線されていた。 この頃、コンピューターを扱うのは技術者であり、その多くは電気技術者であった。 このハードウェア中心の設計は柔軟性に欠け、すぐに「ストアドプログラムアーキテクチャー」またはフォンノイマンアーキテクチャーに取って代わられた。 こうして、「ハードウェア」と「ソフトウェア」の最初の区分けが始まり、コンピューティングの複雑さに対処するために抽象化が行われるようになったのです。 1950年代にはプログラミング言語が登場し始め、これもまた抽象化の大きな一歩となった。 [[Fortran|FORTRAN]]、[[ALGOL]]、[[COBOL]]といった主要な言語が1950年代後半にリリースされ、それぞれ科学的、アルゴリズム的、ビジネス的な問題に対処するために使用されるようになった。 E.W.ダイクストラは、その代表的な論文”Go To Statement Considered Harmful”（『Go to文は有害と思われる』本邦未出版）<ref>{{Cite journal | last = Dijkstra | first = E. W. | authorlink = Edsger_Dijkstra | title = Go To Statement Considered Harmful | journal = [[Wikipedia:Communications of the ACM]] | volume = 11 | issue = 3 | pages = 147–148 | month = March | year = 1968 | url = http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF | accessdate = 2009-08-10 | doi = 10.1145/362929.362947}} </ref> は1968年に、David Parnasは1972年に、モジュール性と情報隠蔽の重要な概念を導入した<ref> {{Cite journal | last = Parnas | first = David | authorlink = David Parnas | journal = [[Wikipedia:Communications of the ACM]] | volume = 15 | issue = 12 | pages = 1053–1058 | url = http://www.acm.org/classics/may96/ | title = On the Criteria To Be Used in Decomposing Systems into Modules | month = December | year = 1972 | accessdate = 2008-12-26 | doi = 10.1145/361598.361623 }}</ref>。複雑化し続けるソフトウェアシステムにプログラマーが対応できるようにするためのものである。 オペレーティングシステムと呼ばれるハードウェアを管理するソフトウェアシステムも導入され、特に1969年のUnixが有名である。1967年には、Simula言語がオブジェクト指向のプログラミングパラダイムを導入した。 このようなソフトウェアの進歩に呼応して、コンピューターのハードウェアもさらに進歩した。 1970年代半ばには、マイクロコンピューターが登場し、趣味でコンピューターを入手し、そのためのソフトウェアを書くことが経済的にできるようになった。 これが、現在では有名なパーソナルコンピューター（PC）やマイクロソフト社のWindowsにつながったのである。 また、1980年代半ばには、ソフトウェアを一元的に構築するためのコンセンサスとして、ソフトウェア開発ライフサイクル（The Software Development Life Cycle; SDLC）が登場し始めた。1970年代後半から1980年代前半にかけては、Smalltalk、Objective-C、C++など、シミュラに影響を受けた新しいオブジェクト指向のプログラミング言語がいくつか登場した。 90年代初頭にはLinuxなどの形でオープンソースソフトウェアが登場し始め、「バザール」という分散型のソフトウェア構築スタイルが紹介された。<ref>Raymond, Eric S. [http://www.catb.org/esr/writings/cathedral-bazaar/ ''The Cathedral and the Bazaar''].ed 3.0. 2000.</ref> その後、90年代半ばにWorld Wide Webとインターネットの普及が始まり、ソフトウェアのエンジニアリングが再び変化した。分散システムはシステムを設計する方法として有力となり、プログラミング言語Javaは抽象化の新たなステップとして仮想マシンとともに導入された。プログラマーは協力してアジャイル宣言を書き、より軽量なプロセスでより安く、よりタイムリーなソフトウェアを作ることを支持した。 現在の''ソフトウェア工学''の定義は、「より安く、より良く、より速く」ソフトウェアを作る方法を考え出すのに苦労しているため、今日でも実務家の間で議論されている。1990年代以降、IT業界ではコスト削減に主眼が置かれるようになった。総所有コスト（Total Cost of Ownership; TCO）とは、単なる取得コストだけでなく、生産性を阻害するようなコストも含まれる。総所有コストには、生産性の阻害、維持管理努力、インフラストラクチャーをサポートするために必要なリソースなどが含まれる。 === 脚註 == <references /> == 参考文献 == * [https://en.wikipedia.org/wiki/History_of_software_engineering ソフトウェア工学の歴史]（英） ir2i6t7aqqjqpza9nl7zal6fb74tq0m 206101 206100 2022-08-01T07:01:41Z Ef3 694 原文抹消 wikitext text/x-wiki {{Nav}} __NOTOC__ == 歴史 == 1940年代初頭に近代的なデジタル・コンピューターが初めて登場したとき、それを作動させる命令は機械に配線されていた<ref>{{Cite book|last=Leondes|title= intelligent systems: technology and applications ISBN:9780849311215 |year=2002| publisher=CRC Press| quote = }}</ref>。この頃、コンピューターを扱うのは技術者であり、その多くは電気技術者であった。 このハードウェア中心の設計は柔軟性に欠け、すぐに「ストアドプログラムアーキテクチャー」またはフォンノイマンアーキテクチャーに取って代わられた。 こうして、「ハードウェア」と「ソフトウェア」の最初の区分けが始まり、コンピューティングの複雑さに対処するために抽象化が行われるようになったのです。 1950年代にはプログラミング言語が登場し始め、これもまた抽象化の大きな一歩となった。 [[Fortran|FORTRAN]]、[[ALGOL]]、[[COBOL]]といった主要な言語が1950年代後半にリリースされ、それぞれ科学的、アルゴリズム的、ビジネス的な問題に対処するために使用されるようになった。 E.W.ダイクストラは、その代表的な論文”Go To Statement Considered Harmful”（『Go to文は有害と思われる』本邦未出版）<ref>{{Cite journal | last = Dijkstra | first = E. W. | authorlink = Edsger_Dijkstra | title = Go To Statement Considered Harmful | journal = [[Wikipedia:Communications of the ACM]] | volume = 11 | issue = 3 | pages = 147–148 | month = March | year = 1968 | url = http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF | accessdate = 2009-08-10 | doi = 10.1145/362929.362947}} </ref> は1968年に、David Parnasは1972年に、モジュール性と情報隠蔽の重要な概念を導入した<ref> {{Cite journal | last = Parnas | first = David | authorlink = David Parnas | journal = [[Wikipedia:Communications of the ACM]] | volume = 15 | issue = 12 | pages = 1053–1058 | url = http://www.acm.org/classics/may96/ | title = On the Criteria To Be Used in Decomposing Systems into Modules | month = December | year = 1972 | accessdate = 2008-12-26 | doi = 10.1145/361598.361623 }}</ref>。複雑化し続けるソフトウェアシステムにプログラマーが対応できるようにするためのものである。 オペレーティングシステムと呼ばれるハードウェアを管理するソフトウェアシステムも導入され、特に1969年のUnixが有名である。1967年には、Simula言語がオブジェクト指向のプログラミングパラダイムを導入した。 このようなソフトウェアの進歩に呼応して、コンピューターのハードウェアもさらに進歩した。 1970年代半ばには、マイクロコンピューターが登場し、趣味でコンピューターを入手し、そのためのソフトウェアを書くことが経済的にできるようになった。 これが、現在では有名なパーソナルコンピューター（PC）やマイクロソフト社のWindowsにつながったのである。 また、1980年代半ばには、ソフトウェアを一元的に構築するためのコンセンサスとして、ソフトウェア開発ライフサイクル（The Software Development Life Cycle; SDLC）が登場し始めた。1970年代後半から1980年代前半にかけては、Smalltalk、Objective-C、C++など、シミュラに影響を受けた新しいオブジェクト指向のプログラミング言語がいくつか登場した。 90年代初頭にはLinuxなどの形でオープンソースソフトウェアが登場し始め、「バザール」という分散型のソフトウェア構築スタイルが紹介された。<ref>Raymond, Eric S. [http://www.catb.org/esr/writings/cathedral-bazaar/ ''The Cathedral and the Bazaar''].ed 3.0. 2000.</ref> その後、90年代半ばにWorld Wide Webとインターネットの普及が始まり、ソフトウェアのエンジニアリングが再び変化した。分散システムはシステムを設計する方法として有力となり、プログラミング言語Javaは抽象化の新たなステップとして仮想マシンとともに導入された。プログラマーは協力してアジャイル宣言を書き、より軽量なプロセスでより安く、よりタイムリーなソフトウェアを作ることを支持した。 現在の''ソフトウェア工学''の定義は、「より安く、より良く、より速く」ソフトウェアを作る方法を考え出すのに苦労しているため、今日でも実務家の間で議論されている。1990年代以降、IT業界ではコスト削減に主眼が置かれるようになった。総所有コスト（Total Cost of Ownership; TCO）とは、単なる取得コストだけでなく、生産性を阻害するようなコストも含まれる。総所有コストには、生産性の阻害、維持管理努力、インフラストラクチャーをサポートするために必要なリソースなどが含まれる。 === 脚註 === <references /> === 参考文献 === * [https://en.wikipedia.org/wiki/History_of_software_engineering ソフトウェア工学の歴史]（英） {{Nav}} j7atb2wn6atwq70hm7bosc76grdk4hb 206103 206101 2022-08-01T07:04:47Z Ef3 694 /* 歴史 */ ln wikitext text/x-wiki {{Nav}} __NOTOC__ == 歴史 == 1940年代初頭に近代的なデジタル・コンピューターが初めて登場したとき、それを作動させる命令は機械に配線されていた<ref>{{Cite book|last=Leondes|title= intelligent systems: technology and applications ISBN:9780849311215 |year=2002| publisher=CRC Press| quote = }}</ref>。この頃、コンピューターを扱うのは技術者であり、その多くは電気技術者であった。 このハードウェア中心の設計は柔軟性に欠け、すぐに「ストアドプログラムアーキテクチャー」またはフォンノイマンアーキテクチャーに取って代わられた。 こうして、「ハードウェア」と「ソフトウェア」の最初の区分けが始まり、コンピューティングの複雑さに対処するために抽象化が行われるようになったのです。 1950年代にはプログラミング言語が登場し始め、これもまた抽象化の大きな一歩となった。 [[Fortran|FORTRAN]]、[[ALGOL]]、[[COBOL]]といった主要な言語が1950年代後半にリリースされ、それぞれ科学的、アルゴリズム的、ビジネス的な問題に対処するために使用されるようになった。 E.W.ダイクストラは、その代表的な論文”Go To Statement Considered Harmful”（『Go to文は有害と思われる』本邦未出版）<ref>{{Cite journal | last = Dijkstra | first = E. W. | authorlink = Edsger_Dijkstra | title = Go To Statement Considered Harmful | journal = [[Wikipedia:Communications of the ACM]] | volume = 11 | issue = 3 | pages = 147–148 | month = March | year = 1968 | url = http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF | accessdate = 2009-08-10 | doi = 10.1145/362929.362947}} </ref> は1968年に、David Parnasは1972年に、モジュール性と情報隠蔽の重要な概念を導入した<ref> {{Cite journal | last = Parnas | first = David | authorlink = David Parnas | journal = [[Wikipedia:Communications of the ACM]] | volume = 15 | issue = 12 | pages = 1053–1058 | url = http://www.acm.org/classics/may96/ | title = On the Criteria To Be Used in Decomposing Systems into Modules | month = December | year = 1972 | accessdate = 2008-12-26 | doi = 10.1145/361598.361623 }}</ref>。複雑化し続けるソフトウェアシステムにプログラマーが対応できるようにするためのものである。 オペレーティングシステムと呼ばれるハードウェアを管理するソフトウェアシステムも導入され、特に1969年のUnixが有名である。1967年には、Simula言語がオブジェクト指向のプログラミングパラダイムを導入した。 このようなソフトウェアの進歩に呼応して、コンピューターのハードウェアもさらに進歩した。 1970年代半ばには、マイクロコンピューターが登場し、趣味でコンピューターを入手し、そのためのソフトウェアを書くことが経済的にできるようになった。 これが、現在では有名なパーソナルコンピューター（PC）やマイクロソフト社のWindowsにつながったのである。 また、1980年代半ばには、ソフトウェアを一元的に構築するためのコンセンサスとして、ソフトウェア開発ライフサイクル（The Software Development Life Cycle; SDLC）が登場し始めた。1970年代後半から1980年代前半にかけては、[[Smalltalk]]、[[Objective-C]]、[[C++]]など、Simulaに影響を受けた新しいオブジェクト指向のプログラミング言語がいくつか登場した。 90年代初頭にはLinuxなどの形でオープンソースソフトウェアが登場し始め、「バザール」という分散型のソフトウェア構築スタイルが紹介された。<ref>Raymond, Eric S. [http://www.catb.org/esr/writings/cathedral-bazaar/ ''The Cathedral and the Bazaar''].ed 3.0. 2000.</ref> その後、90年代半ばにWorld Wide Webとインターネットの普及が始まり、ソフトウェアのエンジニアリングが再び変化した。分散システムはシステムを設計する方法として有力となり、プログラミング言語Javaは抽象化の新たなステップとして仮想マシンとともに導入された。プログラマーは協力してアジャイル宣言を書き、より軽量なプロセスでより安く、よりタイムリーなソフトウェアを作ることを支持した。 現在の''ソフトウェア工学''の定義は、「より安く、より良く、より速く」ソフトウェアを作る方法を考え出すのに苦労しているため、今日でも実務家の間で議論されている。1990年代以降、IT業界ではコスト削減に主眼が置かれるようになった。総所有コスト（Total Cost of Ownership; TCO）とは、単なる取得コストだけでなく、生産性を阻害するようなコストも含まれる。総所有コストには、生産性の阻害、維持管理努力、インフラストラクチャーをサポートするために必要なリソースなどが含まれる。 === 脚註 === <references /> === 参考文献 === * [https://en.wikipedia.org/wiki/History_of_software_engineering ソフトウェア工学の歴史]（英） {{Nav}} 419df3kos9sfm6wve1cqbvth2oooxkg 10 35269 206105 2022-08-01T07:07:00Z Ef3 694 import from: https://en.wikibooks.org/w/index.php?title=Template:Doi&oldid=1814112 wikitext text/x-wiki <!-- -->{{hide in print<!-- -->|[[w:Digital object identifier|doi]]:[http://dx.doi.org/{{urlencode:{{{1|{{{id}}}}}}}} {{#tag:nowiki|{{{1|{{{id}}}}}}}}]<!-- -->}}<!-- -->{{only in print<!-- -->|doi:{{{1|{{{id}}}}}}<!-- -->}}<!-- --><noinclude> {{documentation}}</noinclude> nucrgnttapafk17sjg1sceyl6s2v17n 10 35270 206106 2022-08-01T07:08:42Z Ef3 694 import from: https://en.wikibooks.org/w/index.php?title=Template:Hide_in_print&oldid=1778094 wikitext text/x-wiki <includeonly>{{{1|}}}</includeonly><noinclude> {{documentation}} [[Category:Exclude in print| ]] </noinclude> tvnms9jz42yzpfjz17tdfa22mm11pav 10 35271 206107 2022-08-01T07:09:54Z Ef3 694 import from: https://en.wikibooks.org/w/index.php?title=Template:Only_in_print&oldid=1778065 wikitext text/x-wiki {{#if:{{hide in print|1}}||{{{1|}}}}}<noinclude> {{documentation}} </noinclude> rm8emca34tsah296fr9jh9dzgyhnfxo 828 35272 206109 2022-08-01T07:17:40Z Ef3 694 import from: https://ja.wikipedia.org/w/index.php?title=%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB:Check_isxn&oldid=78671550 Scribunto text/plain -- This template is a copy of the ISXN validation code from [[Module:Citation/CS1]] -- which allows for validating ISBN, ISMN, and ISSN without invoking a citation template local p = {} --[[--------------------------< IS _ V A L I D _ I S X N >----------------------------------------------------- ISBN-10 and ISSN validator code calculates checksum across all isbn/issn digits including the check digit. ISBN-13 is checked in check_isbn(). If the number is valid the result will be 0. Before calling this function, issbn/issn must be checked for length and stripped of dashes, spaces and other non-isxn characters. ]] local function is_valid_isxn (isxn_str, len) local temp = 0; isxn_str = { isxn_str:byte(1, len) }; -- make a table of byte values '0' → 0x30 .. '9' → 0x39, 'X' → 0x58 len = len+1; -- adjust to be a loop counter for i, v in ipairs( isxn_str ) do -- loop through all of the bytes and calculate the checksum if v == string.byte( "X" ) then -- if checkdigit is X (compares the byte value of 'X' which is 0x58) temp = temp + 10*( len - i ); -- it represents 10 decimal else temp = temp + tonumber( string.char(v) )*(len-i); end end return temp % 11 == 0; -- returns true if calculation result is zero end --[[--------------------------< IS _ V A L I D _ I S X N _ 1 3 >---------------------------------------------- ISBN-13 and ISMN validator code calculates checksum across all 13 isbn/ismn digits including the check digit. If the number is valid, the result will be 0. Before calling this function, isbn-13/ismn must be checked for length and stripped of dashes, spaces and other non-isxn-13 characters. ]] local function is_valid_isxn_13 (isxn_str) local temp=0; isxn_str = { isxn_str:byte(1, 13) }; -- make a table of byte values '0' → 0x30 .. '9' → 0x39 for i, v in ipairs( isxn_str ) do temp = temp + (3 - 2*(i % 2)) * tonumber( string.char(v) ); -- multiply odd index digits by 1, even index digits by 3 and sum; includes check digit end return temp % 10 == 0; -- sum modulo 10 is zero when isbn-13/ismn is correct end --[[--------------------------< C H E C K _ I S B N >------------------------------------------------------------ Determines whether an ISBN string is valid ]] local function check_isbn( isbn_str, error_string ) if nil ~= isbn_str:match("[^%s-0-9X]") then -- fail if isbn_str contains anything but digits, hyphens, or the uppercase X return error_string; end isbn_str = isbn_str:gsub( "-", "" ):gsub( " ", "" ); -- remove hyphens and spaces local len = isbn_str:len(); if len ~= 10 and len ~= 13 then return error_string; end if len == 10 then if isbn_str:match( "^%d*X?$" ) == nil then return error_string; end return is_valid_isxn(isbn_str, 10) and '' or error_string; else local temp = 0; if isbn_str:match( "^97[89]%d*$" ) == nil then -- isbn13 begins with 978 or 979; ismn begins with 979 return error_string; end return is_valid_isxn_13 (isbn_str) and '' or error_string; end end --[[--------------------------< C H E C K _ I S M N >------------------------------------------------------------ Determines whether an ISMN string is valid. Similar to isbn-13, ismn is 13 digits begining 979-0-... and uses the same check digit calculations. See http://www.ismn-international.org/download/Web_ISMN_Users_Manual_2008-6.pdf section 2, pages 9–12. ]] local function check_ismn (id, error_string) local text; local valid_ismn = true; id=id:gsub( "[%s-–]", "" ); -- strip spaces, hyphens, and endashes from the ismn if 13 ~= id:len() or id:match( "^9790%d*$" ) == nil then -- ismn must be 13 digits and begin 9790 valid_ismn = false; else valid_ismn=is_valid_isxn_13 (id); -- validate ismn end return valid_ismn and '' or error_string end --[[--------------------------< I S S N >---------------------------------------------------------------------- Validate and format an issn. This code fixes the case where an editor has included an ISSN in the citation but has separated the two groups of four digits with a space. When that condition occurred, the resulting link looked like this: |issn=0819 4327 gives: [http://www.worldcat.org/issn/0819 4327 0819 4327] -- can't have spaces in an external link This code now prevents that by inserting a hyphen at the issn midpoint. It also validates the issn for length and makes sure that the checkdigit agrees with the calculated value. Incorrect length (8 digits), characters other than 0-9 and X, or checkdigit / calculated value mismatch will all cause a check issn error message. ]] local function check_issn(id, error_string) local issn_copy = id; -- save a copy of unadulterated issn; use this version for display if issn does not validate local text; local valid_issn = true; if not id:match ('^%d*%-?%d*X?$') then return error_string; end id=id:gsub( "[%s-–]", "" ); -- strip spaces, hyphens, and endashes from the issn if 8 ~= id:len() or nil == id:match( "^%d*X?$" ) then -- validate the issn: 8 digits long, containing only 0-9 or X in the last position valid_issn=false; -- wrong length or improper character else valid_issn=is_valid_isxn(id, 8); -- validate issn end return valid_issn and '' or error_string end ------------------------------< E N T R Y P O I N T S >--------------------------------------------------==== function p.check_isbn(frame) return check_isbn(frame.args[1] or frame:getParent().args[1], frame.args['error'] or frame:getParent().args['error'] or 'error') end function p.check_ismn(frame) return check_ismn(frame.args[1] or frame:getParent().args[1], frame.args['error'] or frame:getParent().args['error'] or 'error') end function p.check_issn(frame) return check_issn(frame.args[1] or frame:getParent().args[1], frame.args['error'] or frame:getParent().args['error'] or 'error') end return p oemuk3luf2fulv6vk23w1vax1szefeg 10 35273 206110 2022-08-01T07:18:11Z Ef3 694 import from: https://ja.wikipedia.org/w/index.php?title=Template:ISBN2&oldid=82899822 wikitext text/x-wiki {{#if:{{{1|<noinclude>$</noinclude>}}}|{{Catalog lookup link|{{{1|}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}|{{{5|}}}|{{{6|}}}|{{{7|}}}|{{{8|}}}|{{{9|}}}|article-link={{#ifeq:{{yesno-no|{{{plainlink|}}}}}|yes||ISBN}}|article-name={{#ifeq:{{yesno-no|{{{plainlink|}}}}}|yes||ISBN}}|link-prefix=[特別:文献資料/|item-prefix={{!}}|item-postfix=]|list-leadout={{{leadout|}}}}}{{#if:{{trim|{{{1|}}}}}|{{#ifeq:{{yesno-no|{{{invalid1|}}}}}|yes|{{main other|[[Category:無効なISBNが列挙されたページ]]}}|{{#invoke:check isxn|check_isbn|{{{1|}}}|error={{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: 無効な[[ISBN]]です。}}{{main other|[[Category:ISBNのエラーがあるページ]]}}}}}}{{#if:{{trim|{{{2|}}}}}|{{#ifeq:{{yesno-no|{{{invalid2|}}}}}|yes|{{main other|[[Category:無効なISBNが列挙されたページ]]}}|{{#invoke:check isxn|check_isbn|{{{2|}}}|error={{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: 無効な[[ISBN]]です。}}{{main other|[[Category:ISBNのエラーがあるページ]]}}}}}}{{#if:{{trim|{{{3|}}}}}|{{#ifeq:{{yesno-no|{{{invalid3|}}}}}|yes|{{main other|[[Category:無効なISBNが列挙されたページ]]}}|{{#invoke:check isxn|check_isbn|{{{3|}}}|error={{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: 無効な[[ISBN]]です。}}{{main other|[[Category:ISBNのエラーがあるページ]]}}}}}}{{#if:{{trim|{{{4|}}}}}|{{#ifeq:{{yesno-no|{{{invalid4|}}}}}|yes|{{main other|[[Category:無効なISBNが列挙されたページ]]}}|{{#invoke:check isxn|check_isbn|{{{4|}}}|error={{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: 無効な[[ISBN]]です。}}{{main other|[[Category:ISBNのエラーがあるページ]]}}}}}}{{#if:{{trim|{{{5|}}}}}|{{#ifeq:{{yesno-no|{{{invalid5|}}}}}|yes|{{main other|[[Category:無効なISBNが列挙されたページ]]}}|{{#invoke:check isxn|check_isbn|{{{5|}}}|error={{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: 無効な[[ISBN]]です。}}{{main other|[[Category:ISBNのエラーがあるページ]]}}}}}}{{#if:{{trim|{{{6|}}}}}|{{#ifeq:{{yesno-no|{{{invalid6|}}}}}|yes|{{main other|[[Category:無効なISBNが列挙されたページ]]}}|{{#invoke:check isxn|check_isbn|{{{6|}}}|error={{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: 無効な[[ISBN]]です。}}{{main other|[[Category:ISBNのエラーがあるページ]]}}}}}}{{#if:{{trim|{{{7|}}}}}|{{#ifeq:{{yesno-no|{{{invalid7|}}}}}|yes|{{main other|[[Category:無効なISBNが列挙されたページ]]}}|{{#invoke:check isxn|check_isbn|{{{7|}}}|error={{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: 無効な[[ISBN]]です。}}{{main other|[[Category:ISBNのエラーがあるページ]]}}}}}}{{#if:{{trim|{{{8|}}}}}|{{#ifeq:{{yesno-no|{{{invalid8|}}}}}|yes|{{main other|[[Category:無効なISBNが列挙されたページ]]}}|{{#invoke:check isxn|check_isbn|{{{8|}}}|error={{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: 無効な[[ISBN]]です。}}{{main other|[[Category:ISBNのエラーがあるページ]]}}}}}}{{#if:{{trim|{{{9|}}}}}|{{#ifeq:{{yesno-no|{{{invalid9|}}}}}|yes|{{main other|[[Category:無効なISBNが列挙されたページ]]}}|{{#invoke:check isxn|check_isbn|{{{9|}}}|error={{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: 無効な[[ISBN]]です。}}{{main other|[[Category:ISBNのエラーがあるページ]]}}}}}}}}}}}}}}}}}}}}}}}}|{{error-small|{{tl|ISBN2<!-- ISBN -->}}のパラメータエラー: [[ISBN]]の指定がありません。}}}}<noinclude> {{Documentation}}</noinclude> hj80y7eswgm840rkftexsjizms1zfzq 10 35274 206111 2022-08-01T07:19:31Z Ef3 694 import from: https://ja.wikipedia.org/w/index.php?title=Template:Error-small&oldid=82899821 wikitext text/x-wiki {{Small|{{#invoke:Error|error|{{{message|{{{1}}}}}}|tag=span}}}}<noinclude> {{Documentation}} </noinclude> qy17zdano2vw7seroj6w88ph1p1pe8l 10 35275 206112 2022-08-01T07:21:05Z Ef3 694 import from: https://ja.wikipedia.org/w/index.php?title=Template:Small&oldid=73980085 wikitext text/x-wiki <small>{{{1}}}</small><noinclude> {{Documentation}} </noinclude> sm8br4qxzkrfpuanwn3q3akoohw3sa4 828 35276 206113 2022-08-01T07:22:55Z Ef3 694 import from: https://ja.wikipedia.org/w/index.php?title=%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB:Error&oldid=83330732 Scribunto text/plain -- This module implements {{error}}. local p = {} local function _error(frame, args) local tag = mw.ustring.lower(tostring(args.tag)) -- Work out what html tag we should use. if not (tag == 'p' or tag == 'span' or tag == 'div') then tag = 'strong' end -- Generate the html. local retval = frame:extensionTag{name = 'templatestyles', args = {src = 'Module:Error/styles.css'}} local errortag = mw.html.create(tag) :addClass('error') :wikitext(tostring(args.message or args[1] or error('エラーメッセージが指定されていません', 2))) retval = retval .. tostring(errortag) return retval end function p.error(frame) local args if type(frame.args) == 'table' then -- We're being called via #invoke. The args are passed through to the module -- from the template page, so use the args that were passed into the template. args = frame.args else -- We're being called from another module or from the debug console, so assume -- the args are passed in directly. args = frame end -- if the message parameter is present but blank, change it to nil so that Lua will -- consider it false. if args.message == "" then args.message = nil end return _error(frame, args) end return p 11ga4sna3dvurx95bloujqnizb74lhs 828 35277 206114 2022-08-01T07:24:16Z Ef3 694 import from: https://ja.wikipedia.org/w/index.php?title=%E3%83%A2%E3%82%B8%E3%83%A5%E3%83%BC%E3%83%AB:Error/styles.css&oldid=83330820 sanitized-css text/css .error { font-size: larger; color: #d33; } /* [[Category:テンプレートスタイル]] */ iy6amhmk239qaquca1xp39v5yfhwyj7