  |
はてなキーワード: 指南とは
前回まで、データベースを使ったWebアプリを作成して、SQLの使い方を学びました。
これらの参考書をガッツリ読めば、データベース設計のやり方は分かる。
リレーショナル・データベースは昔からある枯れた（＝安定した）技術なので、鉄板のノウハウが蓄積されている。
先人の知恵に沿って使うなら、データベース設計で悩む余地は少ない。＝攻略は意外と簡単。
経済産業省認定の情報処理技術者試験で「データベース・スペシャリスト」という資格もある。
「データベースエンジニア」という肩書きを名乗れば、ただのプログラマーよりも高給取りになれる。勉強した後、自分の知識を棚卸してみるつもりで資格を取ってみるのもいいだろう。
データベース・スペシャリスト試験の教科書には、浅く広くDBの知識が網羅されているので、１度眺めてみたらいいかも。
データベース設計（database design）は、ソフトウェア開発工程においてデータベースの詳細なデータモデルを作る工程である。
（分類方法にもよるけど）データベース設計は、このようなステップを経る。それでは順番に見ていこう。
実際にシステムを使うことになるユーザーにヒアリング調査して、データベース内に永続化（格納）すべきデータを決定する。
データのCRUD操作（Create 追加、Read 参照、Update 更新、Delete 削除）が、いつ、どこで発生するか？をまとめた表のこと。
「データベース 設計 CRUD表」等のキーワードでGoogle画像検索してみよう。どんな表か分かる。
↑このページの「図2 標準的なCRUD図（例）」みたいな表を作って確認すれば、扱うデータの過不足がなくなる。
だが安心して欲しい！
押さえておくべきポイントはあるので、そこだけ手抜きをしなければ、大失敗は避けられるだろう。
実は、後でテーブルを作るときに、データの更新頻度によって2種類に分類できるんだ。
トランザクションデータの扱いは、気を付けないとデータベースの性能低下に直結する。
どっちのタイプのデータなのか？要件定義の段階から見分ける癖を付けておこう。
試しに、Amazonのような通販サイトなら、どんなデータを扱うことになるのか？想像してみよう。
…仕入先、在庫数、受発注、配送会社、顧客情報、商品カテゴリー、商品スペック、などいろいろあるだろう。
いつどこでCRUDが発生するか？どれがマスターデータで、どれがトランザクションデータだろうか？
（ここまでの説明でURLを8個も貼ってしまったので、続きは次回にしよう。）
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書
anond:20181028152656 増田式プログラマー養成講座 その13 SQLの文法
anond:20181031014212 増田式プログラマー養成講座 その14 Webアプリの試作品を作成
anond:20181101225335 増田式プログラマー養成講座 その15 Webアプリの完成見本
anond:20181101230220 増田式プログラマー養成講座 その16 Webアプリの完成見本（続き）
anond:20181104161900 増田式プログラマー養成講座 その17 Webアプリの骨組み
anond:20181104233013 増田式プログラマー養成講座 その18 SQLでデータの追加と取得
anond:20181110120715 増田式プログラマー養成講座 その19 SQLでデータの更新
anond:20181110182445 増田式プログラマー養成講座 その20 SQLでデータの削除
anond:20181111205255 増田式プログラマー養成講座 その21 データベース設計 (1)要件定義 ←★今ここ★
：
全体の25%、4人に1人、1ゲーム中1人は確実にドクター嫌いな人がいるという快挙
索敵が非常にしやすいだけでなく、固有能力はチェイス補助や遅延にも使える万能キャラ
最近じゃ女子大生やくそばばあの方が強いなんて声もあるけどまだまだ強キラーの一角
秩序 鎮静 磨かれた電極
で、レア度は高ければ高いほどいい。
秩序の偽ステイン、抑制のオーラ可視化、幻覚時間増加、服従の常時疲労、秩序の板幻覚と、チェイスでも索敵でも有用になる。
適当な電極をつけて当てまくれば鯖もプレイヤーも発狂間違い無し。
電撃による狂気の量が上昇。チェイス時に偽の心音とステイン表示。
とにかくドクターは電撃を使う機会が多いが、目的は殆ど狂気の加速だ。
狂気レベルを上昇させて様々な恩恵を得る以上、電撃の強化は必須になる。
板や窓の妨害に電撃を使うにしても、狂気レベルがより早く上昇するなら一石二鳥。
地味に便利なのが偽のステイン表示で、モロコシ畑や暗いマップで鯖を見失いにくくなる。
アンコモン以上になるが、困ったらつけておいて間違いはない。
狂気状態が進行した生存者を数秒間可視化。生存者がドクターの幻影を見る時間が増加する。
狂気状態が進行すると鯖は叫び声をあげてドクターに居場所を知らせてくれる。
通常は爆発音よ叫び声による通知だが、それにオーラが追加されるようになり、索敵がやりやすくなる。
Lv2になると心音だけで狂気の進行は難しいため、幻覚を利用しての索敵がメインになる。
幻覚は鯖の正面に出るため、幻覚の視線で居場所や進行方向の予測が可能になる。
組み合わせを考えることなく単体で強いのでおススメだ。
静電フィールド(心音範囲)の与える狂気の量が上昇。破壊された板の幻覚が見える。
通常、心音は鯖にキラーの位置を知らせるのだが、ドクターの場合は逆にもなる。
また心音範囲にいるだけで狂気が進行し発狂するため、隠密行動がNGになる。
懲罰は電撃を当てなければならないが、秩序は心音範囲に捉えるだけで楽。
板の幻覚で鯖を油断させ、逃走経路を誤らせることもできる。
難点はやはり心音範囲でなければならないこと。必然的に爆音構成になり、戦術の幅が狭まる。
苦悶の根源を利用してもマップ全体を覆うにはほど遠く、試合終盤に発電機が離れていると地獄のシャトルランが始まる。
治療モードの心音範囲が増加、処罰モードの心音範囲が減少。偽の心音が聞こえるようになる。
再三になるが、ドクターは心音範囲が広いことがメリットになる唯一の殺人鬼。
苦悶の根源、不安の元凶、鎮静をセットで使用する爆音ドクター構成はもはやテンプレ。
最も狭いマップであるギデオンを指定した場合は全キラー最強と言われるほど。
ネックになるのは秩序と同様に爆音構成になり、組み合わせも秩序か鎮静重ねになること。
また、処罰モードで心音範囲が狭まるため、チェイスが長引くとせっかくの爆音も無意味になってしまう。
逆手にとっての静音ドクターという構成もあるがネタの域を出ない。
秩序同様、戦術を組み立てて運用しなければいけないアドオンだ。
狂気状態からの復帰時間が2秒増加する。狂気Lv3時、常時疲労状態となる。
使いにくい。ベリーレアしかない上に効果があるのが狂気Lv3のみ。
Lv3にすると狂気復帰+疲労回復で72秒間加速パークを封じることが出来る。
が、完全に封じることは稀で大体は狂気も疲労も回復して何かしら発動している。
玉虫色のキングの効果で発動すると非常にありがたいが、単体で使うほどではない。
①索敵時にばらまく
恐らく上記4パターンになると思う。試合中には②と③のパターンが多いはず。
ドクターとして最も避けたいのは何か。
態々鈍足で渇望も溜まらない治療モードで歩いているのは電撃を当てるため。
ならば多少チャージに時間がかかっても範囲を広げ、当たる確率を上げるべきだというのが自分の考えだ。
高刺激的電極はチャージ時間のデメリットを背負ってでも電撃範囲の拡大のメリットの方が大きい。
固有建築に逃げ込んだ時点で電撃を放てば窓や板を使用させず場所移動を強制させ、遠距離で修理音や破壊音が聞こえれば電撃を放って阻止できる。
反対にカビの生えた電極は電撃範囲がそこまで広くないが、チャージもそこまで遅くない。
さっさと電撃を当てまくって狂気を進行させたり、板や窓のループを狙うときに当てて阻止が出来る。
さらにコモンでレア度が低く、ガンガン使っていけるのもメリットだ。
高刺激電極ほど広範囲じゃないし、カビの生えた電極ほどチャージが早くない。
上述した③と④の時に個人的に使いにくいと感じた。
特殊な運用が必要になるアドオン。ほぼ間違いなく高刺激電極とセットになる。
2×20だと通常のドクターの電撃の使い方だととにかく使いにくい。
しかし高刺激電極を使うと3.5×35の極太長距離レーザーになる。
特に狩りの興奮と呪いのトーテム各種を使ってのトーテム防衛が強い。
通常破壊を阻止するには近くにいって殴るか電撃を当てなければならないが、これならば心音範囲外からでも狙い撃ちに出来る。
但しこの戦法に限らずトーテム防衛ばかり意識して立ち回ると発電機は普通に回ってしまうので注意。
ネタ枠。
電撃範囲が前方8mの位置に外周半径4.2m・内周半径3mのリング状に変化
文字通り壊れてる。
楓製のナイトを使用すると電撃範囲が表示されるのでぜひ見て欲しいが、とても当てられない。
通常画面の真ん中に鯖を捉えて電撃を放つがその使い方だと当たらない。
視界の端に置くか、発電機や板などのオブジェクト周辺を狙って打つしかない。
何より前方8mの位置というのが厄介で、鯖との距離が近いと絶対に当たらない。
今回は、DBで使うプログラム言語「SQL」の文法を見てみよう。
関係データベース（relational database）は関係モデルにもとづいて設計、開発されるデータベースである。
関係データベースを管理するデータベース管理システム (DBMS) を関係データベース管理システム (RDBMS) と呼ぶ。
Oracle Database、Microsoft SQL Server、MySQL、PostgreSQL、DB2、FileMaker、H2 Database などがRDBMSである。
関係モデルはIBMのエドガー・F・コッドによって考案された現在もっとも広く用いられているデータモデルである。
データベースの利用者は、クエリ（問い掛け）をデータベースに与え、データを検索したり、変更することができる。
データは表に似た構造で管理されるが、関係と呼ぶ概念でモデル化される。
関係は組（タプル、表における行に相当する）、属性（アトリビュート、表における列に相当する）、定義域（ドメイン）、候補キー（主キー）、外部キーなどによって構成される。
SQLなどに代表されるデータベース言語（問い合わせ言語）を用いて、関係に対して制限・射影・結合・和・差・交わりなどの関係代数演算（集合演算を含む）ないし関係論理演算を行うことで結果を取り出す。
要するに、
SQL（エスキューエル）は、関係データベース管理システム (RDBMS) において、データの操作や定義を行うためのデータベース言語（問い合わせ言語）、ドメイン固有言語である。
エドガー・F・コッドによって考案された関係データベースの関係モデルにおける演算体系である、関係代数と関係論理（関係計算）にある程度基づいている。
これは、SQLの元となったデータベース言語が、IBMが開発したRDBMSの実験実装であるSystem Rの操作言語「SEQUEL (Structured English Query Language)」であったことが由来である。
「SEQUEL (Structured English Query Language)」を略して「SQL」と呼んだらしい。
英語のクエリーは、質問する、問い合わせる、という意味なんだね。
↑このページをよく読んでくれ。理解できたらSQLの説明は終わりだ！！！
…というと、説明することがなくなるので、ちょっとまとめておこう。
このページの「表1●SQLはDDL，DML，DCLの三つに大別できる。このうちプログラマが最も多く使うのはDMLだ」という図を見てみよう。
という３種類に分けてる。順番に見てみよう。
データベース、テーブル、ビュー、インデックス、ユーザーなどを作成／変更／削除するときに使うSQL。
これでデータベースを使う準備ができる。
データを操作するときに使う。いわゆる「CRUD」のことで、SQLのうち、このDMLを覚えれば、とりあえずRDBは使えるようになる。
CRUD（クラッド）とは、ほとんど全てのコンピュータソフトウェアが持つ永続性の4つの基本機能のイニシャルを並べた用語。
この中で一番活躍するのは、「SELECT」コマンド（命令文）だろう。
SELECTは、いろんな条件を付けてデータを絞り込む／加工することができて、便利なんだ。（Excelなどの表計算ソフトよりも高機能）
RDBは「リレーショナル」（関係）という冠言葉が付いてることからも分かるように、関係がある表と表をくっつけて、データを加工できる。
表と表をくっつける操作のことを「結合」という。
SQLでは「JOIN」というコマンドを使って表と表を結合できる。
↑このページにある丸と丸が重なった図を見てくれ。この図は「ベン図」といって包含関係を示す図だ。図を描いて塗りつぶせば、欲しい部分が分かりやすくなるだろう。
表と表のつなげ方には、何通りかパターンがあるよ。
内部結合は単純だ。外部結合はちょっとややこしい。
外部結合は「LEFT JOIN」の形がよく使われると思うので、まず最初にLEFT JOINの仕組みを理解すれば大丈夫だろう。
（LEFTの仕組みを基準にして、RIGHTやFULLとの相違点を意識すれば、表のつなぎ方を間違えにくい？）
「トランザクション」は、データの更新に失敗したとき、元に戻せる機能だ。（安全装置）
Googleの画像検索で「トランザクション」を検索して、分かりやすそうな図解を探してみよう。
↑このページの「図1 処理失敗による不整合の発生」を見てみよう。
銀行で口座間の送金を考えてみる。Aさんの口座からBさんの口座へ50万円送金したい。
この２つの処理が両方とも成功しないと、送金は失敗だ。（Aさんは送金できてないのに貯金が減ったら怒る。Bさんは送金されてないのに貯金が増えてラッキー！）
AとBの両方が成功したら更新処理を確定する。AとBのどちらか、または両方が失敗したら更新処理は破棄してなかったことにする。（やり直し！）
これがトランザクションだ。
ちょっと話がそれるけど、トラブルの重大さ＝クレーム対応の難易度について考えてみよう。
RDBは、SQLコマンドで操作するだけでなく、DB管理ツールを使って操作することもできる。
この講座では「phpMyAdmin」というDB管理ツールで「MySQL」を操作した。
他にも、Google検索で「DB 管理 ツール GUI」などで探してみよう。商用だけでなく無料でも便利なソフトがたくさんあるね。
など。
SQLコマンドを組み立てる作業はパズルのような要素もあるので、遊びだと思ってSQLに取り組んでみて欲しい。
「SQL パズル」でGoogle検索すると、いろんなテクニックが紹介されているので、時間があったらチャレンジしてみよう！
SQLの話は、それだけで1冊の本になるぐらい広範だ。今回は、SQLの概要を説明するだけになってしまった。
SQLの詳細については、前回紹介したSQLの参考書などを読んでみてね。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書
anond:20181028152656 増田式プログラマー養成講座 その13 SQLの文法 ←★今ここ★
anond:20181031014212 増田式プログラマー養成講座 その14 Webアプリの試作品を作成
：
前回は、MySQLとphpMyAdminを使って、リレーショナル・データベース（RDB）を少し触ってみた。
今回は、RDBの使い方や仕組みについて理解を深めるための資料を探してみよう。
本は、買う価値のある本と、買わなくてもいい本の2種類があるね。
どちらの本かは自分の判断で決めよう。（１度で理解できない本は、何度も読み返すことになるだろう。）
最初に読めば、DB全体を俯瞰する地図を手に入れたようなもの。その後の見通しが良くなる。
本書はMySQLをはじめて触る方を対象として，開発環境の準備からSQLの基本的な書き方，PHPによるWebシステム開発まで，図解でわかりやすく解説します。
まずは、データ操作の基本「CRUD」（Create＝追加、Read＝取得、Update＝更新、Delete＝削除）を理解しよう。
CRUDが分かれば、DBを使ったWebアプリを作れる。→ここがIT土方の最低レベルだぜ！
本書は、データベースを操作する問合型言語「SQL」の文法を練習できる。
SQLが読める＆書けるようになれば、RDBを使ったプログラミングで苦労しなくなる。
上記２冊の入門書程度の知識を身に付ければ、RDBに関しては初心者から脱却できるはずだ。
RDBを使うプログラムを作るなら、まずはこの程度の知識をクリアしておけば、十分だろう。
次の段階では、既存のDBを使うだけでなく、「ゼロからDBを設計、構築してくれ」と頼まれるようになるはずだ。
（以下の話は、今の段階では無視してもOK。RDBにある程度慣れたら読んでみて！）
データベースの本はいろいろあるけど、「ミック」という人が書いた本はRDBの要点がまとまってるので、なるべく早い段階で一通り目を通しておくことをお勧めする。（ミックさんの本は買って何度も読み返してる。）
RDBの設計方法はいろいろあるが、古典的な手法として「DOA」（データ中心アプローチ）がある。
↑DOAと、他の「OOA（Object Oriented Approach：オブジェクト指向アプローチ）」「POA（Process Oriented Approach：プロセス中心アプローチ）」を比較した図を見てみよう。
OOAは、言い方を変えれば、
という流れになっている。
つまり、ユーザー側から見ると、間にある[プログラム]は、[DB]を包んでいる「ラッパー」でしかない。
＝[DB]のデータ構造（スキーマ）さえシッカリしていれば、間にある[プログラム]は取り替えてもあまり困らない。
RDBを使うシステムなら、DB設計がプログラム設計よりも重要になる。
（後で[プログラム]を変更するよりも[DB]を変更する方が影響は大きい）
だから、今日でもDOAは十分に役立つ手法だと思って理解して欲しい。
慣れたらER図を書かなくても、頭の中で思い浮かべるだけでもテーブルを作れるようになる。
最初にDOAを知っておけば、今後他の設計方法を使うときでも、比較検討の基準として使えるので、損はないはずだ。
初級者が押さえておくべきDB設計の基礎知識やポイント、正規化／非正規化のケーススタディ、テーブル設計のやってはいけないバッドノウハウ、注意すべきグレーノウハウなどを丁寧に解説します。
DOA、正規化、階層構造（木構造）のデータの扱い方など、DB設計の基本を網羅的に説明している。
私が設計のスキルを付けるために実際に行ってきた「身の回りのものを題材にERDを書く」という方法のサンプルを今回は8種類書き下ろさせていただきました。
手前味噌ではありますが、本書をお読みいただき実践していただくことで「実務で具体的に手が動く」というレベルに達していただけると考えています。
RDBやSQLは「関係代数」という数学が、その基礎を支える理論になっている。
RDBを改造したり、自作したくなったら、RDBの原理を知っておきたい。
この手のコンピューターサイエンスの本って、難しくてつまらない本が多いけど、この本は図解が多くて、珍しく分かりやすい本だったｗ
自分が使うデータベースのマニュアルは最も基本的な１次情報になるので、不明点があったらまず確認するようにしたい。
など、公式サイト、オンラインマニュアルをチェックしておこう。
ミックさんは、ネットでもDB技術論の記事を公開されており、参考になるかも？
（↑無料Webサーバー「Yahooジオシティーズ」は2019年3月閉鎖予定なので、読むなら今のうち？）
階層構造になっているデータ（カテゴリー情報など）をRDBに保存するとき、主なやり方が3通り紹介されてた。（上記の本でも紹介されてる）
自分は(2)の「経路列挙モデル」が分かりやすくて、いつも使ってる。
…という具合に、ネット上の公開記事にも参考になる情報がたくさんあるよ。
（ここまでの説明でURLを9個張ってしまったので、もうこれ以上URLを張れない。＞＜）
他にもGoogle検索などで役立つ記事を探してみよう！（唐突な締めｗ）
データストア（データを保存する道具）は、RDB以外にもいろいろある。→「NoSQL」とか呼ばれている。（自分で検索してみてｗ）
Redis、Hadoop、ElasticSearch、OpenStack…いろいろな道具が発明されてるね。
RDB以外のデータストアを使うときでも、RDBと相違点を比較しながら学べば、取っ掛かりが持てて、理解がスムーズになるだろう。
RDBは、知っておいて損はない。使いまくって、体得しよう！
RDB、SQLはパズルみたいなものだから、楽しんで学んで欲しい。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書 ←★今ここ★
anond:20181028152656 増田式プログラマー養成講座 その13 SQLの文法
：
要はこれって、あの作者は感情を絵にするのが上手じゃないという単純な話だと思う。
感情表現っていっても、ワンピースや僕のヒーローアカデミアみたいに泣き顔をドアップで見せろとか、感情優先で頭の悪い展開をやれってな話じゃないよ。
ワールドトリガーって意外に感情で動くシーンも多い。というか、ストーリーの楽しみってのは感情的なもので（数式や理屈だけで展開するものを物語とは言わない）、そこを異常に毛嫌いする方が変なんだけど。
増田の書いている三輪もそうだし、そもそもチカを守ろうとするメガネくんや借りを返すためにそこに着いていく木虎とか、戦略的な見せ場でありながら戦いそのものを楽しんでいたランバネイン、自滅するエネドラなど、感情で行動するシーンもキャラもそれなりにある。
なのにその印象が弱いのは、作者がそこを強調出来てないからなんだよね。（エネドラはかなり強調されていたと思うが、逆にエネドラくらいじゃないと印象的な感情描写をしないともいえる）
展開に感情起因のゴタゴタがなくてストレスを感じにくいのはいいんだけど、それと引き換えに肝心のクライマックスでも読者の感情を煽るような絵と演出になってないってのは、やっぱりちょっと弱い。
ドラゴンボールの有名な場面も「ギャルのパンティおくれー！」「クリリンこのことかー！」「バカヤロー！」「バイバイみんな」、
ハンター×ハンターも「今すぐ君を壊したい」「余はこの瞬間のために生まれてきたのだ」など、全部感情的な瞬間。キャラの感情描写ってのは少年漫画では凄く重要なわけ。
漫画を書くならまずはキャラの表情を最低20種類は書けるようにしようという指南もある。
他のメジャー少年漫画と比べればすぐわかるけど、ワールドトリガーはそもそも喜怒哀楽その他の表情がものすごく乏しい。顔だけじゃなくて、体も感情表現をしていなくて、ある種棒立ちと言える描き方が多い。
キャラが主体となる少年漫画としてはかなり異色の作画で、ただの新人なら真っ先に直されるところだ。そこが許されてるあたりが、この作品のストーリー構成の非凡さの証明でもあるんだけど。
ピンチになってキャラがあせってる場面でも、非常に形式的な表情しか書かれていないので、「うわー大変だメガネくんどうなるんだ」と読者の感情をあおる力が弱い。人によっては、ただ答え合わせを読まされているような白けた気分にもなると思う。やはり読者はキャラと一緒にドキドキしたいのだ。
過去の回想で姉の助けを求める三輪も、涙を流してこそいるが、なんていうか物凄く曖昧な表情だ。これでは三輪が姉の死を悲しんでいることは理解できても、共感しない読者が出てもおかしくない。
印象的な場面として記憶に残らないので、三輪がいくらネイバーに憎悪をむき出しにしようとこのシーンが頭によぎらないのだ。こういう点が辛い。
感情描写が薄いところも含めて「それが味」といえなくもないけど、ネームはそのままに人物作画や表情を少し変えるだけで劇的にプラスになると思うので、これは欠点と言っていいと思う。面白いんだけどね。
これは個人の体験で、他の女性たちがどうだったか分からないんだけど、それでも私にとっては確かに衝撃を受けた体験だったから書き残しておく。
私がエロ表現に初めて触れたのは、十歳にならない頃、電車の中。向かいの席の男性が読んでいたスポーツ新聞のこちら側にヌードの女性が写っていた。多分ビデオの紹介とかだったのだろう「喘ぐナントカ…」みたいなコピーがついていた。体育の着替えが男女同室だったくらいの歳で、性的衝動の存在を知らなかったから、そのヌードを見てただ驚いた。女性の裸が新聞に載って眺められる需要が存在することを初めて知った。
意識して周りを見渡すと、それらしい気配は各所にあった。大磯ロングビーチの広告、公衆電話ボックスに貼られた女子学生の写真と電話番号、週刊誌の中吊り広告に太字で書かれた「ついに脱いだ！」という踊り文句。女性の外見、特に裸は世間から求められていて、しかもそれはあまり上品な欲求をもとにした明るいものではなさそうだということに気がついた。（ちなみに当時は女性の幼さを強調したイラストはそう無かったように思う。覚えているのは「幼妻」という単語の衝撃くらい。セーラームーンの月野うさぎちゃんが１３歳とは思えないほど大人びたスタイルで描かれていた。変身シーンで一度ヌード風になる意味が分からず何となく恐ろしかった。）
時を同じくして、電車の中で痴漢にあうようになった。隣に座って太ももを摺り上げてくる人、ぐいぐい押しよってくる人、自慰の様子を見せつけてくる人、色んなバリエーションがあった。特に自慰を見せつける人は印象に残っていて、膝の上で週刊誌を開き読んでいる風を装いながら、その下で性器を触っていた。時折目の前に座る私に視線を寄越すので、何だか危険な感じがして動けなかった。当時男性が自慰をするなんて知識は全くなく、隣に座る友達と「前のお兄さん何してると思う？」と小声で話し合えるくらい、その行為はただの変な出来事だった。他の痴漢も同じくらいセクシャルな意味はまるで理解できず、ただなぜ自分の体を触られているのかが意味不明で混乱した。
そんな鈍感な私も、身体もやがて第二次性徴を迎え、初潮を経験し、乳房が形になり始め、何よりアンダーヘアが薄く生え始めた。このとき一気に、大人のお姉さんたちとそこに注がれる視線が他人事ではなく、このあと私が受けるものであることを自覚した。振り返れば、太ももを撫でたあの人も、「セックスって知ってるか」と話しかけてきたあの人も、変な行為に目が釘付けの私をチラ見してきたあの人も、私をヌードのお姉さんたちと同じように扱っていたのだと思い至った。私は一方的に慰みものになっていた。
それからしばらくは成長するのが嫌で仕方なかった。胸の膨らみを憎み、下の毛をカミソリで全部剃った。修学旅行ではこの成長を周囲に悟られたくなくて大浴場には入らなかった。成長が進んでしまったら、女性の性的な部分を世間に差し出し、あの水着のお姉さんたちのように他者に評価されながら生きていくしかないのだと絶望した。
やがて中学生となり男性に恋をして、女性であること・女性の身体を持っていることへの嫌悪感は減った。男性がそれに魅力を感じること、またそれを上手く見せることで好意を引き寄せることができると学習したから受け入れられるようになったのだと思う。自分の体と社会の折り合いをつけるようになったのだ。その学習効果は、スカートを短くすることや、石鹸の香りの香水をつけること、唇をツヤツヤにして”キスしたくなる”状態に保つことなんかに現れた。（当時、セブンティーンやプチセブンはそういう指南に溢れていた。）
このあとは割愛。私は一般的な異性交友体験を重ね、特にセクシャリティに関するトラウマを持つこともなく、平均的な年齢で好きな人と性体験をし、恋に悩んだり、遊んだりしながら結婚して母になった。
もしあの頃の自分に声をかけてあげられるとしたら、女性・男性の性的魅力を記号のように表現したり消費したりする文化の一段奥には、相手個人を切実に求める個人間の原始的な愛のやり取りがあることを先に教えてあげたい。それは人間（というか生き物）として自然な欲望であり、それを感じる相手とだけでいいから、お互いに性的魅力を伝えあえる関係になることが大切なんだと安心させてあげたい。
幼い頃は健康で丈夫な自分の体をただそれだけで好きで信頼していたのに、チラチラと差し込んでくる性的なものたちに気を取られ、私はその信頼を疑ってしまった。スカートは膝上20センチじゃないと、ブラは2センチ厚のパッドが入っていないと、髪はセミロングを揺らしていないと、女子学生らしくないと毎日夢中で取り組んでいた。その呪い、タイムマシンで解きに行きたいよ。
駅前、イオンモール、巣の公園にしか人が集まらない。イオンモール以外は何らかの連絡手段で呼び寄せないと人がいない。
ジムの範囲内にトレーナーが住んでいる場合、高い確率で同じ色のチームのジムとして死守される。あまりにも死守されることを痛感するとほかの色のトレーナーが近づかなくなる。複垢に進化すると自演によるジムの取り合いが始まる。
山の中の公園のように明らかに誰もいない場所で急に配置されるポケモンが増える怪現象が発生。夜間に車で行かないと到達できない人けのない場所なのに不思議なことが起こる。位置偽装か？！
ミニバンに定員いっぱいの7人を乗せジムを殲滅していく車が隣町から現れる。1人あたり2から3台のスマホを持っている模様。7人乗っているので、ジムに配置できる6体分が瞬時に埋まる。
館内はGPSの入りがよくないので屋上駐車場を車で移動するとトレーナーが多数現れる。屋上駐車場では店内入口に近い場所から埋まっていくのが常であるが、トレーナーたちは、ジムに近い位置や複数のポケストップの影響下にある場所に停めるため、トレーナー同士では相手の存在がバレバレである。一般人には意味不明な位置に停めていると思われるだろう。
自転車のハンドルにスマホを5台固定したじいさんが朝からジムを巡回している。ビートマニアやポップンミュージックを華麗にプレイするかのごとく5台のスマホを操作する。複垢に対するいいわけは孫の分もやっているとのこと。スマホには雨カバーが付いていて雨対策も抜群だ。
地域のlineグループを取り仕切っているおばさん。専業主婦らしく朝から夜遅くまで出没する。新参トレーナーには、EXジムなどの攻略情報を指南して子分にしている。
車で行けない遊歩道の奥にあるジムにポケモンを配置すると2週間くらい帰ってこなくなる。
ジムニー君と呼ばれるトレーナーがいる。レイドバトルで集まっても遠目からこっそり参加している。春先に山奥のジムに向かおうとして「この先除雪しません」の看板を無視してジムニーで雪道に突っ込んでスタック。山道に乗り捨てられたジムニーを目撃されてlineに流されてしまう。そこまでしてジムに行きたかったのか。
位置座標が律儀に本堂に設定してあり、有名寺院でもないので、私有地感というかアウエー感がありすぎて、ジムまで近寄れない。いつの間にかポケストップに降格。
撤退してなくなりました。
夏のウイークエンドまつりのときに県内に1つか2つしかないタリーズにトレーナーが殺到。4時間待ちの行列ができるも配布枚数は100枚。律儀に1ドリンク1枚を配ったら、50人くらいにしか行きわたらなかった伝説。翌日、lineグループおばさんが親と妹と行って券が余っているですけどーと配布していた。
ドライブで日本の秘境にいったときのお話。日本の秘境と呼ばれるエリアにもジムがあり、配置したら予想に反して3時間で戻ってきた。秘境に常時出入りしているトレーナーがいるらしい。
子供は親に対してこうするべき、を見ない。
以前、小さい子供がいる時の長期休みに夫は妻に旅行をプレゼントすべきではない、というツイートをみた。
人が溢れる休みの子連れ旅行は休みにならないよ、パパは子供を連れて実家に行くなりしてママに一人の時間を楽しんでもらってはどうか、というものだった。
今私は親孝行について考えている。
しかし動くのもだるそうにしているので旅行はどうなのだろう、趣味もよくわからない。
世代も大きく違い、一方的に話はするがあまり仲がいいというほどでもない。
しかし親が我慢して私の学費を支払い、親の自由に使える時間を短くしてしまったことに対して私は何かしたいと思っている。（例え親が選択、同意した事だとしてもだ）
ここ数年、中古1棟マンションを売りまくって荒稼ぎしてきた。素人同然のサラリーマン大家を勧誘し、通帳や源泉徴収票などの審査資料を偽造・捏造しては多額の融資をスルガ銀から引き出した。資料改竄は銀行員に指南された、と社長は言う。ウソでも高利回りの家賃収入をうたえば、3～4割の利益をピンハネしても物件が飛ぶように売れ、田舎のボロマンションでも奪い合いになった。
ところが、シェアハウス投資の運営会社の破綻を機にスルガ銀融資での不正が表面化。金融庁が立ち入り検査に乗り出す事態を招き、審査が厳しくなって改竄資料が通らなくなった。貯蓄や年収を水増ししないと、高額物件を買える客層はグンと狭まるため、取引が一気に低調になった、というわけだ。「甘い汁を吸ってきたツケですね」と社長は肩を落とす。
依頼の文面で「〜（して）いただけるでしょうか」を使う同僚がいて、見るたびに違和感を覚えていた。
「書類を頂けるでしょうか」
「教えていただけるでしょうか」
「返却いただけるでしょうか」
などが用例。この人は会話でもこう言う。最後の例は「ご返却」としてほしい。
「いただけるでしょうか」ググってみたらそれなりに使われている。例えば「ご理解いただけるでしょうか」とか。これはなぜか違和感があまりない。しかしよくよく検索結果を見ると、依頼ではなく質問ばかりだ。あるいは、質問の体だけど答えは求めていない投げかけが多い。やはり依頼の「〜（して）いただけるでしょうか」は珍しいのではないか。
動詞の終止形に「でしょうか」が付いているから変なのかと思ったらそうでもない。
「まだ使えるでしょうか」
「雨は降るでしょうか」
自分は「〜（して）いただけますでしょうか」を使う。経験的に、他の人もよくこれを使っていると感じている。念のためこちらもググってみたら、誤用として複数のビジネスマナー指南サイトで紹介されているようだ。「ます」「です」が二重敬語なのだと。なるほど。
とはいえ、検索上位にくるのは薄っぺらなページばかりで、これなんて特に酷い。
https://www.rirekisyodo.com/study/doublehonorific-point.html
日本語も論理も内容もおかしい。こんな記事にとやかく言われたくない。
このページも酷い。
「いただけますでしょうか」は二重敬語だから NG と言いながら、「よろしかったでしょうか」は相手への配慮だから OK とか。実際に NG か OK かは別としても、この論理でよく記事にできたなと思う。
そしてこの「専門家」とは誰なのか。その専門家に「いただけますでしょうか」について聞くことはできなかったのか。まあ、そこだけ何かを読んで適当にぼかして引用したのだろうけど。
ここで感じたのは、「〜（して）いただけるでしょうか」は、こういったゴミみたいなビジネスマナー指南に従って「〜（して）いただけますでしょうか」を避けた結果として使われているんじゃないか、という疑問だ。
以下について知りたいけれども、検索だけでは答えが出そうにない。
1. 依頼の「〜（して）いただけるでしょうか」は昔から使われていて、これがむしろ自然だという人がいるのか。
2. 依頼の「〜（して）いただけるでしょうか」は「〜（して）いただけますでしょうか」を避けた結果という仮説は正しいか。
3. 「〜（して）いただけますでしょうか」は、専門的にはどういう扱いなのか。
（追記）
http://www.kotonoha.gr.jp/shonagon/
まず「ますでしょうか」で調べてみた。「いただけ」は二重敬語の指摘に関係ないので。検索対象からヤフーや国会会議録は除く。かなり例が出てくる。有名な執筆者のソースを幾つかピックアップしよう。
山﨑豊子「沈まぬ太陽」1999※
宮部みゆき「誰か」2003
曽根綾子「この悲しみの世に」1986
ここには、依頼でなく質問の「ますでしょうか」の例も含まれる（※印）。でも二重敬語が駄目なら依頼・質問の区別は関係ないだろう。
さて、「いただけるでしょうか」を検索したかったが、検索文字列は 10 字までということなので「けるでしょうか」で検索した。例はかなり少なく、依頼の用例はさらに少ない。とはいってもゼロではない。こちらも有名どころを挙げておこう。
1. 「いただけますでしょうか」は、文法的な是非はともかく、今後も自信を持って使っていいといえる十分な用例がある。
2. 「いただけるでしょうか」はそれなりに古い用例が存在するので、とやかく言うほどではなさそうだ。
今、作者買いしている少女漫画があるのだけど、先日それの5巻が発売されたので買って読んだ(連載はまだ続いてる)。
ファッションデザイナーを目指すおしゃれ大好きな中学生の女の子が、ダサい服装の女子にファッション指南をしてオシャレにしていくという、とくにこれといって変わった設定でもない普通の少女漫画。
最近の少女漫画はいじめ系や重い病気をもっているといった暗かったり切なかったりする話が多い気がするのだけど、この漫画は明るくて元気な女の子が主人公のいたって平和なサクセスストーリーだ(過去にいじめられてたそうだけど)。
そこに、ヒーローポジションとして幼馴染の男の子がでてくる。ヒロインの支えとなっているイケメンだ。
4巻ではお互い両想いということが分かり、付き合うようになったのだけれども、5巻ではパリに留学にいくことになった。
「衝撃の展開」と宣伝されてたけど、留学することか。なんて思って読み進めていったら、パリに向かう飛行機が落ちて死んだ。
内容からして実は生きているというオチにはできそうにないし、SFやファンタジーものではないので生き返らせるということもできない。
「なんじゃこりゃ」と思った。主人公の次に主要な人物が死ぬなんて話は今まで見たことがなかったので本当に驚いた。
融資先のベンチャー企業に突然出向を命ぜられた銀行マンが、その会社の社長から「会社経営指南」をうけるという内容で、フィクションですが社長のモデルは本田宗一郎氏だそうです。
「ニワトリを殺すな」というタイトルに目をひかれて買いましたが（意味はもちろん本書を読めば書いてあります）、とても軽いタッチで書かれている、というか、軽すぎてちょっと物足りない。
コストパフォーマンス的にも本田氏の著作（「俺の考え」とか）を文庫で読んだほうがいいように思います。
https://www.amazon.co.jp/gp/customer-reviews/R3SH0X788KC9GA/
おそらく変動しても±1kgくらいに収まっている。
今20代後半だが、身長170cm体重56kgで、BMIで言うと痩せ気味の標準体型。
今までダイエットしようだとか、体型を維持しようだとかは考えたことがない。
1日3食好きな量を食べているし、間食もあまりするほうではないが、昼間にチョコレートや煎餅を1つ2つ口にするくらいならほぼ毎日している。
つまり、自分は特に何も意識せず、好きなものを好きなように食べているだけで、太りもしないし痩せもしない人間なのだ。
だけど、自分のような人間は少数派で、世の中の大半の人は油断するとすぐ太るらしい。
TVを見ても本屋に行ってもダイエットの情報はこれでもかと言うくらいに溢れている。
それも、ここ数年だけの話じゃない。
不思議なのは単に健康を指南する情報でさえ、当たり前のようにダイエットの話になることだ。
どうしてぽっこりお腹を凹ませることを前提に話が進んでいくんだ？
こっちには凹ませるお腹がないのだが。
どうして糖質0がヘルシーなんだ？
そして、何よりも疑問に思うのが、痩せる方法なんてどう考えたって一つに決まってるのに多くの人がそれを実践していないことだ。
どうして食べるのをやめないんだ？
食べなければ痩せるんじゃないのか？
そりゃあ健康的に痩せるためには筋トレだの有酸素運動だの必要なのだろうが、究極的に言えば体の脂肪が全部なくなるまで何も食べなければそれで痩せられるんじゃないの？
1日3食好きなだけ食べると太ってしまうのなら、1日2食にするとか、それぞれの食事の量を減らすとかして、一日の消費カロリーより摂取カロリーを低くすればいいだけなのになぜそれをしないんだ？
食べなければそれだけ食費も浮くし、高い月謝を払ってスポーツジムに通ったり、高価なサプリメントや健康食品なんて買わなくて済むのに。
空腹ってそんなに我慢出来ないほどに辛いことか？
健康な人間なら丸一日絶食したって余裕で生きていられるだろう。
それなのにせいぜい数時間の空腹も耐えられない？
あと、お菓子やケーキを目にすると二言目には「でも太るよ」って言う女の子、マジなのか？
だって、ケーキを1つ食べたとしてその重さはせいぜい数十gだろう？
水分やうんこになって出る分を考えたら身に残る重量は少しだけのはずだ。
なんてことを言うと顰蹙を買いそうなので普段は誰にも言えない。
まぁ世が世なら真っ先に死ぬのは自分のような体質の人間なのは間違いないのだろうが、現代においてダイエットなんていう不毛な行為に少しの時間もお金も使わなくて済むのは幸運と言えるだろう。
でも、大多数の共有する価値観を少しも理解できないというのもまた寂しいものだ。
追記：
初めて増田に書いたんですけど、700個くらいコメントがあってびっくりしました。
やっぱりダイエットってセンセーショナルなトピックなんですかね～。
でも、なんていうか、コメントに品があっていいですね、ここは。
ついてたコメント大体読みましたけど、30～40代からが本番って意見が圧倒的に多かったですね。
