Webを支える技術を研修で読んでる まとめ３
この記事について
技術研修で読み進めているWebを支える技術について、各章のまとめを順次上げていく。 前 pokotyamu.hatenablog.com
次
HTTPメソッドの概要
HTTPメソッドには9つの種類がある。
| メソッド | 意味 |
|---|---|
| GET | リソースの取得 |
| POST | 子リソースの作成、リソースへのデータの追加、その他処理 |
| PUT | リソースの更新、リソースの作成 |
| PATCH | リソースの一部更新 |
| DELETE | リソースの削除 |
| HEAD | リソースのヘッド(メタデータ)の取得 |
| OPTION | リソースがサポートしているメソッドの取得 |
| TRACE | 自分宛てにリクエスト・メッセージを返す(ループバック)試験 |
| CONNECT | プロキシ動作のトンネル接続への変更 |
以降、各メソッドについて見ていく。 また、ステータスコードについては、次の第8章で述べる。 今回説明中で使用するステータスコードは、あくまで実装の一例である。そのため、実装のやり方によっては変化することがある。
各ヘッダの確認方法はGoogle Chromeの場合 以下の参考リンクのレスポンスヘッダのコピーを参照 参考：coliss.com - Chrome デベロッパーツールの使い方: プロのように華麗に使いこなすための20のテクニック
GETメソッド
GETでは、指定したURIの情報を取得する。 Webページの取得、画像の取得、映像の取得、フィードの取得など、実際にブラウザを利用している時に一番使われるメソッドがGETメソッドである。
GET / HTTP/1.1 Host: www.hottomotto.com
HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Connection: keep-alive Date: Tue, 26 Apr 2016 03:27:37 GMT Server: Apache Vary: Accept-Encoding X-IIJ-Cache: MISS Transfer-Encoding: chunked <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!-- 途中略 --> </body> </html>
レスポンス例のレスポンスボディー内に、指定したリクエストのhtmlの情報が返されている。 これを読み込んでWebブラウザ上で表示している。
POSTメソッド
POSTメソッドでは３つの役割が存在する。
子リソースの作成
ブログページを親とした時に、ブログ記事が子リソースに当たる。 つまり、ブログ記事の投稿がこの子リソースの作成に当たる。
POST /list HTTP/1.1 Host: example.jp Content-Type: text/plain; charset=utf-8 こんにちは！
HTTP/1.1 201 Created Content-Type: text/plain; charset=utf-8 Location http://example.jp/list/item5 こんにちは！
201 Createdというステータスコードが返ってきたが、これは正常にリソースの作成が出来たことを示す。
Locationヘッダにその新しいリソースのURIが入っている。
リソースへのデータの追加
ログリソースの追加などがこれに当たる。
POST /log HTTP/1.1 Host: example.jp 2016-04-25T10:13:00Z, GET /log, 200
HTTP/1.1 200 OK
ここではPOSTのレスポンスとして、200が返ってきたが、これは、リソースの作成ではなく、データの追加を示す。
POSTがデータ作成を意味するか、またはデータ追加を意味するかは実装に依存するため、WebAPIの仕様書などを調べる必要がある。
他のメソッドでは対応出来ない処理
URIの長さにはブラウザの実装上2000文字以内などの制約が入る場面がある。 そのような長いキーワードの場合、URIのクエリにキーワードを入れてGETする方法は利用出来ない。 この時に POSTを利用することで、ボディの中にキーワードを格納することが出来る。
POST /search HTTP/1.1 Content-Type: application/x-www-form-urlencoded q=very+long+keyword+hogehogehoge......
PUTメソッド
PUTは２つの役割が存在する。
リソースの更新
先ほどのPOSTの記事作成で作ったリソースの内容を更新する。
PUT /list/item5 HTTP/1.1 Host: example.jp Content-Type: text/plain; charset=utf-8 こんばんは！
HTTP/1.1 200 OK Content-Type: text/plain; charset=utf-8 こんばんは！
このように、PUTメソッドは、元のリソースを更新するときに使う
リソースの作成
http://example.jp/newitemが存在してないものとする。
POST /newitem HTTP/1.1 Host: example.jp Content-Type: text/plain; charset=utf-8 新しいリソース/newitemの内容
HTTP/1.1 201 Created Content-Type: text/plain; charset=utf-8 新しいリソース/newitemの内容
PUTは存在しないURIへのリクエストのため、サーバはリソースを新しく作成すると解釈し、201 Createdを返す。
/newitemが存在していた場合は、更新として処理される。
PATCHメソッド
2010年のRFC7589で追加された一番新しいメソッド。 リソースの一部更新で使用される。 例えば、ブログ記事のタイトルの更新などに使用される。
PATCH /list/item5 HTTP/1.1 Host: example.jp Content-Type: text/plain; charset=utf-8 ##一部更新内容##
HTTP/1.1 200 OK Content-Type: text/plain; charset=utf-8 ##一部更新が反映##
このように、基本的には、PUTの子リソースの更新となんら変わらない。 それぞれの違いについては後述する。
Github APIでも採用されているほか、Ruby on Rails v4.0から正式に採用された。
DELETEメソッド
名前の通りリソースの削除を行うメソッド。
DELETE /list/item2 HTTP/1.1 Host: example.jp
HTTP/1.1 200 OK
一般にDELETEのレスポンスはボディーを持たない。
そのため、ステータスコードにボディーがないという意味の204 No Contentが使われる場合がある。
POSTでPUT/DELETEを代用する
今現在、一番よく利用されているのが、GETとPOSTメソッドである。 HTMLのフォームで指定出来るのもこの2つだったが、技術の発展とともに、AjaxのXMLHttpRequestというモジュールを利用することで、任意のメソッドを発行できるようになった。 しかし、XMLHttpRequestをサポートしない携帯電話向けブラウザでは2つのメソッドしか利用出来ない。 また、プロキシサーバではPUTによって勝手にサーバーに関する情報をクライアントに追加させたり置き換えさせたりするため、セキュリティの問題で2つのメソッド以外のアクセスを制限する場合がある。
このような状況で、サーバにPUTやDELETEを伝えるためには、
- _methodパラメータ
- フォームの隠しパラメータに_methodというパラメータを入れる
- その中に本来送りたかったメソッドの名前を入れる
- Ruby on Railsが採用している
- X-HTTP-Method-Overrde
HEADメソッド
GETとよく似ていているが、GETはリソースを取得、HEADはリソースのヘッダ(メタデータ)のみを取得するメソッド。
HEAD /list/item1 HTTP/1.1 Host: example.jp
HTTP/1.1 200 OK Content-Type: text/plain; charset=utf-8
先述した通り、ヘッダのみ返すため、HEADへのレスポンスにはボディーを含まない。 利用用途としては、ネットワークの帯域を節約しつつ、リソースの大きさや、更新日時を調べるために使う。
OPTIONSメソッド
OPTIONSは、そのリソースがサポートしているメソッドの一覧を返す。
OPTIONS /list HTTP/1.1 Host: example.jp
HTTP/1.1 200 OK Allow: GET, HEAD, POST
OPTIONS /list/item1 HTTP/1.1 Host: example.jp
HTTP/1.1 200 OK Allow: GET, HEAD, PUT,DELETE
OPTIONS自体は、Allowヘッダには含めない。 また、OPTIONSメソッドは開発者が独自で実装しなければならない。
主要ではないHTTPメソッド
今まで説明した、7つのメソッドが主にHTTPメソッドとしては使われやすい。 ここからは、少し使用頻度の低い2つのメソッドについて説明していく。
TRACEメソッド
TRACEは、HTTPリクエストを「オウム返しに」HTTPレスポンスとして返す。
ただし、注意すべき点として、リクエストをそのまま返すため、レスポンスの中にCookieヘッダやAuthorizationヘッダも含まれてしまう。
そのため、Cross-Site Tracing(XST)攻撃に利用された。
XST攻撃とは、XSS^1とTRACEメソッドを組み合わせた攻撃手法である。
以下、徳丸浩の日記 - 実はそんなに怖くないTRACEメソッドから引用
XSS単独では、XSSによりJavaScript等が動いているブラウザ上のレスポンス(ヘッダ及びボディ)は取得出来ますが、リクエストヘッダを取得することはできません。このため通常は、HttpOnly属性の指定されたCookieや、Authorizationヘッダ（Basic認証のIDとパスワード）を取得することはできません。 しかし、TRACEメソッドを実行すると、先に見たようにリクエストヘッダがそのままレスポンスとして返るので、XSS単独ではとることのできないHttpOnly属性の指定されたCookieや、Authorizationヘッダを盗み出すことができます。これがXST攻撃です。とくに、BASIC認証のIDとパスワードを盗むことができると、長期にわたって不正にログインすることができてしまうため、XSSの影響が大きくなります。
CONNECTメソッド
RFC 2817の定義によると
A CONNECT method requests that a proxy establish a tunnel connection on its behalf. The Request-URI portion of the Request-Line is always an 'authority' as defined by URI Generic Syntax [2], which is to say the host name and port number destination of the requested connection separated by a colon:
```レスポンス例 CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80
日本語に軽く訳すと、 「CONNECTは、proxyとのトンネル接続を作るために使われる。リクエストURIの中にhostme名、ポート番号、リクエスト元の情報がコロン区切りで記述される。これらは、URIの一般的なシンタックスである。」
べき等性と安全性
べき等とは「ある操作を何回行っても結果は同じという考え方」である。 数学の絶対値、0の乗算(3 * 0 = 0)などがあげられる。
また、安全性とは「操作対象のリソースの状態を変化させないこと」を意味している。
これらを主要メソッドであるGET、POST、PUT、PATCH、DELETE、HEADに当てはめると次のような図に分類出来る
| ○ | 安全性あり | 安全性なし |
|---|---|---|
| べき等 | GET、HEAD | PUT、DELETE |
| べき等でない | POST,PATCH |
GETとHEADは、値を取ってくるだけなのでべき等かつ安全なのは自明である。 PUTとDELETEは、値を更新や作成、削除する点から変化を与えるため安全性はないが、何度やっても値は同じなのでべき等性はある。 POSTは、リクエストの結果次第で何が起こるか分からないためべき等性はなし。更に、リソースの状態に変化も与えるため安全性もなし。 POSTの例としては、通販サイトでのブラウザの戻るボタンを押してしまった時に、2重注文のような問題が発生する可能性を示している。 PATCHは、更新の時に、べき等でなく、安全性もない更新であると定義されている。
POSTとPUTとPATCHの使い分け
POSTとPUT
どちらも新しいリソースの作成を行えるが、それぞれの使い分ける指針として、 リソースのURI決定権が挙げられる。
POSTでリソースを作成する場合、URIの決定権は サーバ側にある。 なので、レスポンスヘッダー内にLocationが含まれる。 この動作の例としては、TwitterのようにUTIをサーバーが自動的に作成する場合が挙げられる。
PUTでリソースを作成する場合、 クライアントが決めたURIがそのままサーバ側で使用される。 なので、レスポンスヘッダー内でLocationが含まれていない。 この動作の例としては、Wikiのようにクライアントが決めたタイトルがそのままURIになるものが挙げられる。
PUTとPATCH
Ruby on Rails(以下Rails)の導入された経緯から、この２つのメソッドの違いを考える。
元々Railsでは、レコードの更新に対して、PUTメソッドが使われていた。
Railsで使用するレコードの中にはupdate_atという更新時間の項目が常に含まれている。これは、ユーザが指定していない時でも作成される。
この時、レコード内の別の項目だけを更新した時にupdate_atも一緒に更新時間が変わってしまう。つまり、同じ更新を行う時に毎回同じ結果が返るという べき等性が失われている。
そこで、最初からべき等性も安全性もない、PATCHメソッドを用いることで、この誤用を解消した。
このように、PUTとPATCHは基本的に処理内容としては、同じだが、べき等性が必要か否かで選ぶと良い。 参考：Edge Rails - PATCH is the new primary HTTP method for updates
メソッドの誤用
先ほど、べき等性と安全性の対応表を出したが、全てがあの表に当てはまるとは限らない。 そのパターンについて述べる。
なお、これらのパターンは開発者の問題であることが多く、前述した図が基本と考えて良い。 そのため、べき等性や安全性を考慮して、適切なメソッドを適切なタイミングで使用することを心がける。
GETが安全でなくなる場合
GET: /resources/1/delete HTTP/1.1 Host: example.jp
このようにGETで要求しているにもかかわらず、example.jp/resources/1 を削除しようとする時、安全性がなくなる。 これを防ぐためには、GETの発行前後でリソースに変化が入っていないか？を考えると良い。 基本的にGETでは参照しか出来ないはずなので、deleteなどの動詞がURIに入ってる段階で矛盾している。
PUTがべき等でなくなる場合
価格の更新に対して、現在の価格の50%増加させるといったように、今の差分から処理を行う時 毎回結果が変わってくるため、べき等性がなくなる。 このようなときには、PATCHを使うか、「+50%」といった相対的な表現を避けるべきである。
DELETEがべき等でなくなる場合
ソフトウェアの最新バージョンがhttp://example.jp/latestというエイリアスリソースで管理されている時、このURIに対してDELETEを行うとどうなるか？
もし、エイリアスリソースそのものを削除するという処理の場合、http://example.jp/latestが削除されるだけなので、べき等性は保たれる。
しかし、エイリアス先のリソース(最新バージョンのリソース)を指していた場合、ver2.0が削除された次の削除はver1.9になるため、べき等性がなくなってしまう。
このようにエイリアスリソースを削除するように設計するのもいいが、このような特殊なリソースについては、更新や削除などの操作が出来ないような設計にするのが求められる。
CRUDな設計
これまで、9つのHTTPメソッドの種類をまとめた。
これらのメソッドのうち、GET、POST、PUT、DELETEは4つでCRUDという性質を満たす。
CRUDとは、
- Create：作成、生成
- Read：読み取り
- Update：更新
- Delete：削除
の４つの頭文字を取ったものである。
それぞれの対応関係は、以下の図のようになっている。
| CRUD名 | 意味 | メソッド |
|---|---|---|
| Create | 作成 | POST、PUT |
| Read | 読み込み | GET |
| Update | 更新 | PUT |
| Delete | 削除 | Delete |
CRUDな設計の代表例は、railsのscaffoldした雛形Webアプリケーションが挙げられる。 参考：TECHSCORE - 4.scaffoldを利用した開発(1)
Webを支える技術を研修で読んでる まとめ２
この記事について
技術研修で読み進めているWebを支える技術について、各章のまとめを順次上げていく。
次
HTTPの概要
HTTPはTCP/IPをベースにしている。 TCP(Transmission Control Protocol) IP(Internet Protocol) 現在のHTTPはバージョン1.1が主流として使われており、10年以上更新されていない。 現代の開発スタイルでは、HTTP1.1を有効に使っていこうという流れになっている。^1 ネットワーク・プロトコルは階層毎にわかれている。
各階層は次のようになっている。
- ネットワークインターフェース層
- 物理的なケーブルやネットワークアダプタに相当する部分
- イーサネット
- インターネット層
- IPを使ってパケット単位でネットワークで実際にやり取りする部分
- この時、最終的にたどり着くかは保証していない
- IP
- IPを使ってパケット単位でネットワークで実際にやり取りする部分
- トランスポート層
- アプリケーション層
階層にすることの特徴は
- 抽象度別に分けることが出来る
- ネットワークインターフェース層のほうが抽象度が低い
- 各階層の実装が独立している
- 下位層の実装に依存しない
- 障害発生時などの問題を各層毎に区切ることが出来る
HTTPの仕組みについて
HTTPはアーキテクチャスタイルに クライアント/サーバ を採用している。 クライアント(Webブラウザ)が情報を提供するサーバ(Webサーバ)に接続し、各種リクエストを出してレスポンスを受け取る。 このようなプロトコルを リクエスト/レスポンス型(Request-Response Style) と呼ぶ。
クライアント/サーバそれぞれの役割
クライアントでは、リクエストの送信から受信する際、次のことを行う。
- リクエストメッセージの構築
- リクエストメッセージの送信
- (レスポンスが返るまで待機)
- レスポンスメッセージの受信
- レスポンスメッセージの解析
- クライアントの目的を達成するために必要な処理
次に、サーバでは次のことを行う
- (リクエストの待機)
- リクエストメッセージの受信
- リクエストメッセージの解析
- 適切なアプリケーション・プログラムへの処理の委譲
- DBから最新記事を取得処理
- 広告へのリンク作成処理
- アプリケーション・プログラムから結果を取得
- レスポンスメッセージの構築
- レスポンスメッセージの送信
HTTPメッセージ
先述した、リクエストメッセージとレスポンスメッセージはまとめて、 HTTPメッセージ と呼ぶ。
リクエストメッセージの構造
リクエストメッセージの構造は以下の図のようになっている。
リクエスト行のURIには、http://example.jp:8080/search?q=test&debug=true#n10のようなURIフラグメントは、リクエストメッセージには含めない。この場合のリクエスト行は、URIフラグメントを除いた、パス以降の文字列が入る。具体的には/search?q=test&debug=trueが入る。
また、リクエストURIは基本絶対URIでも相対URIでも使用出来る。^2 しかし、プロキシへのリクエストの場合必ず 絶対URI となる。
レスポンスメッセージの構造
レスポンスメッセージの構造は以下のずのようになっている。
参考：ネットワークエンジニアとして TCP/IP - HTTP
HTTPのステートレス性
HTTPはステートレスなプロトコルとして設計されている。 これは、サーバがアプリケーション状態を保存しないということである。
アプリケーション状態とは？
アプリケーション状態は、別名セッション状態とも言う。 システムにログインしてから、ログアウトするまでの一連の操作間の状態をアプリケーション状態と呼ぶ。
もしステートフルなプロトコルだと、アプリケーション毎のやり取りをサーバが記憶する必要がある。 反対にステートレスなプロトコルだと、アプリケーション自身でやり取りを全て記憶する必要がある。
それぞれの概要は次のようになる。
- やり取りについて
- ステートフル：簡潔(サーバが記憶しているから)である。
- ステートレス：冗長(今までの状態を話す必要があるから)である。
- 利点
- ステートフル：送信するデータ量が少なくて済む。
- ステートレス：クライアント数が増えた際にシステムをスケールさせるのが楽になる。
- 欠点
- ステートフル：クライアント数が増えると、サーバが記憶しなければならないデータ量が増えるため負担が増える。
- ステートレス：送信データ量が増える。認証など、サーバに負担がかかる処理を繰り返す。通信エラーの際にリクエストが処理出来ているか分からない。
Webを支える技術を研修で読んでる まとめ１
輪講形式で読んでいて、気になった点をまとめておく
第１部：Webの概要
- RPC
- 分散システムを実現するための技術の１つ
- 分散システムの流れが来たが、複雑さの問題から発展しなかった
- Webはシンプルな単方向リンクだけを持つものとして開発
- SOAP
- メッセージ転送の方法だけを定めたプロトコル
- 標準化戦争勃発
- REST
- リソース
- RESTなアーキテクチャのために
- クライアント/サーバ
- ユーザインターフェースと処理を分離する
- ステートレスサーバ
- クライアントのアプリケーション状態をサーバで管理しない
- ステートフルな場合、Cookieを使ったセッション管理をしている
- REST的には間違い
- キャッシュ
- 一度取得したリソースをクライアント側で使い回す
- 効率化はできるが、情報の信頼性が下がる
- 一度取得したリソースをクライアント側で使い回す
- 統一インターフェース
- URIで指し示したリソースに対する操作を統一した限定的なインターフェースで行う
- 階層化システム
- サーバとクライアントの間にロードバランサを設置して負荷分散を行う
- コードオンデマンド
- ブラウザ以外にクライアント側を拡張出来る
- JSやFlashなど
- プログラムをクライアントにダウンロードして実行する
- ブラウザ以外にクライアント側を拡張出来る
- クライアント/サーバ
第２部：URI
- URIの仕様
- railsのrouteファイルなどに関わってくるから、ここから大事！
- URIスキーム
http://hogehoge.comhttpの部分がURIスキーム
- URIフラグメント
hogehoge/member#user1- ページ内の#以下の文字列の要素を示す
- URIの設計
第３部：HTTP(Hypertext Transfer Protocol)
アメリカの中学生を対象にワークショップやってみて感じた日本との違い
留学６週目の最終週の記録です。
今週はSunnyvaleの中学校でロボットでサッカーを行うロボット教室をやりました。
ロボットはDAISEN社製のTJ3Bという既成品を使用して
それの組み立て→プログラム作成という流れで行いました。daisen-netstore.com
ロボットはC言語を用いたプログラムに従って動くのですが、
実際に子供たちが作成する時はC-styleというビジュアルプログラミングソフトを使用して行います。*1
今回はその中で私が感じた日本の子供たちとの違いについてまとめていきたいと思います。
1.子供の自発性に任せる
【日本の場合】
進研ゼミの告知の仕方が日本の教育の全てを物語ってるのではないでしょうか？
「この夏休みで短所を長所に変えよう！！！」
つまりは、日本の教育では、短所をなるべく消して平均的に取れるように指導を進めていく風潮が強いということです。
この教育方針には、
メリット ・クラス全体が同じ進捗で進めやすい ・なんでもそれなりにこなせる人間を増やせる デメリット ・尖った人間が育ちにくい ・一度ついていけなくなると落ちこぼれる可能性が高い
というメリット・デメリットがあると考えました。
高校生のときに、中学後半の英語や数学を授業レベルでやり直すのは難しいのは容易に想像が出来るかと思います。
自分からというより、受動的にしか受けようがないというのが今の教育の限界なのかもしれません。
そして、平均的に出来るだろうという気持ちから、
失敗するのが怖いという思考になってしまうのかなと思います。
【アメリカの場合】
ロボット教室をやってて思ったのは
自分達が用意したスライドの２歩ぐらい先を勝手に自分で考えて進めていたことです。
最後には、お互いに分からないとこを教え合って授業と言っても後ろからサポートしてあげるだけ、という時間が多かったです。
こっちの子供たちの好奇心は、実際に形にするまで止まりません。
トライ・アンド・エラーで勉強できることを彼らは知っているのです。
では、もしこの時日本式に
「みんなで一緒に進めるからちょっと待ってて。」
と言って彼らのやる気を止めたらどうなるか？
答えは、全く関係ないことをやり始めて、その後ロボットには目もくれなくなります。
それだけこっちの子供は自発的に興味を持ったものには全力で突き進みますが、
上から押し付けたり指示すると興味をモチベーションが下がってしまう文化が、ここにはあると感じました。
さらにもう１つ
アメリカの学校では、単位毎に飛び級が認められています。
やってることが幼稚なら先に進む。
分からないで進むなら、理解するまで止まる。
このような教育を受けることが出来ます。
2.何事にもアグレッシブ
【日本の場合】
日本の授業風景を思い出してください。
先生「質問ある人ー？」 生徒「・・・・・・」 先生「はい、次進みますー」
これは、よくある日本の教室の光景だと思います。
全員の前で質問することに対して恥ずかしさや、授業を止めてしまうのでは？という申し訳無さ
そんな空気感からなかなか手を挙げるのは簡単ではないことは、私も当時感じていました。
いわゆる、日本人はシャイだねってやつですね。
【アメリカの場合】
もし、自分の分からない点が出てきたら
「これはどうなってるの？」
「どうして動かないの？」
こんな質問をひたすら連呼してきます。
この連呼するというのがポイントで、自分が分からないポイントは
とことん理解するまで知りたいという欲求が、彼らには働いているように感じました。
だからこそ、自分の理解している範囲内ではドンドン進めていきたいのでしょう。
特に今回の授業では、自分がプログラムを書く→ロボットが実際に動くことで確認出来る。
このサイクルで開発を進めていけたので、早くもっと高度なことがしたいという気持ちに駆られたように感じます。
3.意見の伝え方と納得の仕方
【日本の場合】
小学校、中学校で何か決め事をするときに一番使われるもの
そう「多数決」ですね。
多くの日本人が多数決で決まったなら、自分が納得せずとも受け入れてしまう
そんな経験はありませんか？
現在の大人が受けた教育で、多くの人が議論を行う経験が少なかったように感じます。
自分の意見を主張するより周りに合わせる。
５段階評価アンケート形式で真ん中が多かったりする。
自分の意見を意地でもねじ込もうとする方法が確立されてないため
どうしても感情的に突き進む連中が、最近よく国会前で騒いでいたりするのかなと。
教育されてないから、あんな滑稽な演説しか出来ないのだろうとまとめながら感じました。
デモ自体やることはいいのですが、もう少しロジカルに演説すればいいのに、
「戦争法案！」「徴兵制にはさせない！」「安倍下ろし！」
これしか言わないデモに何の意味があるのか。
【アメリカの場合】
ロボット教室の場面でこのようなことがありました。
今回のサッカーの試合では、白い枠からはみ出したら１分間退場扱いというルールがあります。
試合時間は５分なので、そのうちの１分とはかなり大きいペナルティと感じたのでしょう。
１人の子供が「３０秒に変更してよ！！！」
これを１０回以上審判である私達に訴えてきました。
確かに、彼のロボットは何回も場外に進んでいました。
これに対して「それは出来ない」という回答を私達は繰り返しました。
教室が終わった後の反省で言われたのは
・"Just rule!!”と突っ張る ・なぜ３０秒に変更してはダメなのかの理由を伝えてあげる
この２つでした。
まず１つ目は、自分達が試合をしている彼らより圧倒的に上の位置で判断していると伝えてあげることで
変な申請をこれ以上させないという効果があります。
これをしないと、今回のようにナメられて、自分の意見をねじ込めようとしてきます。
そして２つ目は、ロジカルに納得するとそれ以上自分の意見を訴えても無駄だと本人が一番わかっているということからです。
実際、今回１分と設定した理由としては、授業の中で最低限フィールドから出ないようなプログラムを組むようにという指示をしていたので
かなり重いペナルティとなっていました。
それを伝えることが出来れば、彼も納得して試合をすることが出来ただろうなと今になって思っています。
まとめ
以上の３点について最後にまとめると
日本人の教育の場合
・短所を直して全体を平均的にする ・疑問があっても蓋をして進める ・反対の意見を述べることが悪いことという空気感がある
アメリカ人の教育の場合
・長所をひたすら伸ばし続ける ・自分だけでは分からない疑問は即解決する ・自分の意見をロジカルに否定することでのみ納得する
今回は特にアメリカの子供たちのメリットの部分を強調して記事を書いてみました。
もちろん、デメリットも考えたらあると思います。
けど、それはアメリカ社会と日本社会の違いだと思っていて、
アメリカでは個の特徴的な人の集合体で会社が動いている。
日本では、平均的な力でベースとなる底力を上げることで会社が動いている。
まぁ最近は日本でもITベンチャーはアメリカナイズされた考え方を持ってる会社も多いかと思います。
そこで、自分が働く場合は、自分の価値観(スキルセットの揃え方)もアメリカナイズさせる必要があるのかと感じました。
*1:ビジュアルプログラミングといえば、scrachやsmalrubyが有名ですね
協調学習のススメ
アイディアソンの中で、教育というテーマで議論することが多かったので
前回の記事で別に分けた協調学習というテーマで今回は書きたいと思います。
人に何かを教えるときに気をつけたい３つのポイント - pokotyamu的書きなぐり日記
最初に、東大の大学院の方のブログを参考に学問的な定義をまとめた上で、
自分の体験からどんな学習効果があったかという体験談の形で進めていきます。
学問的な定義
blog.iii.u-tokyo.ac.jp
blog.iii.u-tokyo.ac.jp
２つの記事をまとめると、
協調学習とは、
学習者がグループ活動の中で互いの学習を助け合い、一人一人の学習に対する責任を果たすことで、グループとしての目標を達成していく、協調的な相互依存学習
のことで、家庭教師や塾のチューターように一方の利益のために勉強することは含みません。
これによって得られる成果としては、
・学業成果（成績） ・対人関係（コミュニケーション能力） ・動機付け（モチベーションの維持） ・批判的思考やメタ認知的思考
などなどが挙げられます。
難しいことを言ってますが、要するに
試験前にみんなで図書館で集まって個人で勉強するのではなく、
ノートを持ち寄って、互いに得意な分野を教えあいながら、勉強していくことで成績の向上はもちろん、対人関係の向上や、人に教える責任感も含めて効果として求め、個人で勉強する以上の効果を期待する学習スタイルです。
PS①：かなり割愛していますので、詳しく知りたい方は原文を読んでください。
PS②：間違いあればコメントいただけると助かります。
実際に協調学習してみて感じたメリット
今回留学期間中に行ったアイディアソンについて紹介と感想について書いていきます。
どんなアイディアソンをしたかについては過去記事を見てください。
知識の学習法のパスを知れる
もし、新しい分野を勉強する時どのようにしますか？
参考書等を買って勉強するという方法も考えられますが、協調学習で勉強していくことでその人の持ってる知識に加えて様々な知見を得られます。
例えば
・どのように勉強したか？ ・実際に使ってみた時の体験談 ・その知識について、その人の考え方（意見）
このような副産物も込みで得ることが出来るため、
最終的な学習スピードが上がるように感じました。
今回の場合は「ビジネス」というワードに対して経営・経済系の学部の子に教えてもらったのですが
１人で勉強する上でどのように進めていこうかという方針を固めることが出来ました。
自分の知識が整理される
私は、一番効率がいい学習方法は「人に教える」ことだと思っています。*1
その理由は、
・人に教えるために再度知識を復習する ・責任が発生するので下手なことは教えれない ・ロジカルに伝えないと伝わらないので、文章構成のトレーニングにもなる
などが挙げられます。
協調学習では、教えあうことがベースになるため
必然的に教える機会が増え、高い学習効果が期待出来ると考えています。
ゴールを決めれる
個人でするよりも確認出来る人がいる分、
今日はどんなことを学ぶというゴールが設定しやすい気がしました。
さらに、そのゴールに向かう途中で話が脱線して別の議論に波及することで、
別な考え方も身につける事ができる可能性があります。
たまに脱線しすぎて、本来のゴールまで辿り着かないこともありますがね笑
コミュニケーション能力の向上
これは人によるのですが、
私は誰かと会話してコミュニケーションを取るのが好きなので
会話前提で学習が進む協調学習が向いているのかも知れません。
恐らく気がしれている間柄でやることになると思うので、
先生よりとことん理解できるまで質問攻めに出来るのもメリットと思っています。
質問することで、相手の知識の盲点を付くことが出来るかもしれない。
それによってさらに教えている側も勉強になっていて、学習効果が期待できる。
このような流れで進んでいるのがこれの面白いところですね。
なので、遠慮なく質問していきましょう！
九州工業大学の取り組み
私は現在九州工業大学の大学院に通っているのですが、
2011年に協調学習の研究を目的として「MILAiS」という施設が作られました。
MILAiS：九州工業大学 情報工学部 未来型インタラクティブ教室
最後にこの施設について触れて終わりたいと思います。
議論しやすい環境
この施設には協調学習を円滑に進める様々な仕組みが施されています。
まずは壁です。
４つの壁全てにホワイトボードがズラーっと設置されています。
もちろんそのままも使えますが、取り外して移動することも出来ます。
さらにそれぞれにプロジェクターが備えられており、生徒が希望すればいつでも使用出来ます。
次に机です。
勾玉上に設計された机では、人数に合わせて机の広さを変えることが出来ます。
これも協調学習としては重要で、机が広すぎて議論しにくかったり狭すぎるということを防いでいます。
各テーブルに充電ケーブルを引けますし、飲食も可能です*2。
端末の貸出
MILAiSではMBAやiPadなど様々な端末を借りることが出来ます。
プログラミングを勉強する上で簡単にスペックの高いPCが借りれるのはありがたい。
例えば端末を忘れたという時でも駆け込みで使えます。
質の高い情報が集まる
ここからは私の体験なのですが、
協調学習でモチベーションが高まっている学生が集まっているため
他のグループから刺激を受けることが頻発します。
頻繁に利用してたらお互いに知らなくても顔覚えますしね。
やっぱりこの環境でつながった人は尖っている人間が多かったように感じます。
尖っている人間は、他の世界から情報をキャッチしてくる。それをこの環境で広める。
そんなループが回っているような感じがしています。
まとめ
最後の方は、大学施設の話になりましたが、
今回は協調学習についてまとめました。
本文の中ではメリットを中心に書きましたが当然デメリットもあります。
それは、相手のスキルセットに依存してしまうため
間違った情報を入れてしまう可能性があるということです。
これは自分が与える情報についても同じです。
これを防ぐためには、まず自分の与える情報の質を高めることがあります。
ギブ・アンド・テイクの精神がベースにあるため、質の高い情報をくれる人には、それに見合った質を持ってきてくれる人に出会える可能性が増えてくるように感じます。
さらに上のレベルの人と勉強できることをモチベーションにやるのも楽しいかもしれませんね。
人に何かを教えるときに気をつけたい３つのポイント
留学４週目の更新。
最近は、シリコンバレー界隈でウリウリやってる学生で集まって
１週間に５回ほどアイディアソンやってみました。
Workshop Cafeにほぼ毎日お世話になっております。
Workshop Cafe - サンフランシスコ - 喫茶店、職場・オフィス | Facebook
アイディアソンと言っても内容はその時々で変えて
・個人が持ってるアイディアのブラッシュアップ ・◯◯ ✕ ◯◯ を２０個出すまで帰らない ・ダイレクトマーケティングをテーマにビジネスモデルを考える ・日本とシリコンバレーの働き方の違いについて議論
とか色々でした。
面白い点としては、集まったのがエンジニアとして勉強した人だけではなく
経営系を中心に勉強している人など、違うバックグラウンドの学生だったことです。
そのため、いかに専門性の高い言葉を相手にわかりやすく教えるか？ということが求められてきます。
このようにグループワークで勉強していく時の体験は、
協調学習のススメという記事でまとめる予定なので、そちらも合わせてご覧頂ければと思います。*1
というわけで、今回の体験から感じたことを
人に教えるときに気をつけたい３つのポイントという形でまとめていきます。
１．知識レベルが違うことを意識する
前述したとおり、バックグラウンドが違うということは
知識レベルにおいて差が生まれているので、相手に教えなければならない状況の場合
１歩２歩階段を降りて会話をする必要があります。
大学教授の講義がつまらないと感じるのは、この部分が大きいのかもしれません。
かといって、大学教授が自分のレベルを落とすことはしない。
そのため、学生が主体的に埋めようとしない限り、いつまで経ってもつまらないと感じるのだと思っていると私は考えています。
*2
２．PREP法を利用してみる
これは人に何かを伝える時にロジカルに話すポイントでもあります。
PREP法とは、
P・・・Point（結論） R・・・Reason（理由） E・・・Example（具体例） P・・・Point（再度、結論）
の略で、この文章構成で人に物を伝えることも効果的です。
具体的な例を挙げてみます。
A「この公式はよく使うから覚えとけよー！」 B「この公式は絶対に覚えとけ！」 「なぜなら、センター試験の大問１で頻出だからだ！」 「去年、一昨年とどちらもこの公式を使えば解けた！」 「だからこの公式は絶対に覚えとけ！」
AさんとBさんの会話を比べた時に、言葉数が多いのもありますが、説得力という面では
Bさんの方が強く重要性を伝えることができています。
これは教えるときだけでなく、何かを質問するときにも使えて、
A「このバグが取れないんですよね...」 B「このバグの取り方がわかる調べ方を教えて欲しいです。」 「なぜなら、自分の知ってる知識を使っても取れなかったからです。」 「このテストを書いてみても、変数を固定にしてもわかりませんでした。」 「だから調べ方を教えて欲しいです。」
いかがでしょうか？
Aさんの質問の仕方をしてしまった場合、相手はなにが問題なのかわかりません。
自分の意図する答えが返ってこない可能性がありますし、
相手が知らなかった場合、無駄に考えさせるこにもなります。
実際に、ここまで厳密に構成を守りながら話すのは難しいのですが
予め準備出来る場合、この考えに基いて話を整理するのをおすすめします。
３．説明は３分でまとめる
せっかく話の構成が上手く立てられていても、ダラダラと話し続けられたらどうでしょうか？
きっと途中で相手の集中力が切れてしまい内容理解が難しくなってしまいます。
しかし、全ての会話をコンパクトに纏めることは難しいのも事実です。
これを解決する方法としては
・相手に考えさせる時間を与える ・相手に質問を聞いてみる
といった相手に投げかける方法を試すと飽きずにすすめることが出来ます。
相手が何をどれだけ知りたいのか？に合わせて話のボリューム感を決定し、
分からないことや質問を相手に投げかけながら進めていくことで、人に教えるときの上手さが向上するヒントかもしれません。
最後に、これまでの話は私のこっちでの体験や、インターンでの経験がもとになっています。
この話し方が合う合わないもあるので、１つの参考として、考えて頂ければ幸いです。
英語が満足に話せるわけではない私がシリコンバレーの勉強会で名刺渡しまくった話
留学3週目の更新。
今週は、SFRailsに参加してきました！
イベントのリンクはこちらwww.meetup.com
今回の会場は、きれいめなオフィスの一角でした。
前回はどっちかといえば経営層の人が多かったがこっちは基本的にエンジニアかデザイナーの人しかいなかったです。
前回記事pokotyamu.hatenablog.com
ーー
今回は、そんな中で大した英語力のない私がどう立ち回ったか？という話をまとめていきます。
これから同じ境遇になる方、なかなか会話のキッカケが掴めない方の参考になれば。
日本のエンジニアの懇親会でも共通の部分もあるので、もっとこんなことしたらいいよ！などありましたらコメントで教えていただけると助かります。
１．初対面のきっかけ作り
まずは、いかに話し相手を見つけるか？という点についてです。
飯を食わずにビールを飲む
これにはいくつかの利点があります。
・空腹にアルコールを入れることで、酔いを早くする
これによりボッチの緊張感や英語が話せない恥ずかしさを軽減させることが狙いです。
むろん、酔いすぎて相手の話を聞けなくなるのはもってのほかです。
ビールが色々あったのでオススメを聞いてみることで、会話を始めるというのもよかったです。
What's your recommendation?
迷った顔してこのこれぐらいのシンプルな英語で聞いたら
快く教えてくれますよ。
・乾杯という話はじめのきっかけが出来る
ビール片手に話しかけやすそうで、まだ話し相手がいない方を見つけましょう。
見つけたら、その人に目線を合わせてニッコリしながらビールをちょい高くあげましょう。
乾杯に応じてくれない方はいないので、これをきっかけに話しはじめるといいです。
下に書いている避けるべきポイントの人より、話し相手探してる感じの人の方が
実際話しやすかったです。
２．話はじめの会話
さぁ話し相手が見つかったなら次のステップです。
実際に会話する時の場面に移ります。
・あえて自己紹介をしすぎない
会話はキャッチボールという言葉もありますが
1人でベラベラ話すより、相手から聞いてもらうというのが長続きする秘訣かもしれません。
最初の会話で言うことは
・名前*1
・自分が大学生/社会人であること
・日本人であるということ
なぜ日本人であることを言うかというと、中国人や台湾人に間違えられている可能性があり、
日本人であるというだけで、相手の表情がかなり変わった印象があったからです。
これが日本人の海外における評価なのかもしれません。
また、英語が苦手な方に向けては
I study English now.
この一言をつけるだけでも相手の話し方を変えてくれます。
日本でも頑張って話そうとする片言の外国人の話は文法めちゃくちゃでも聞くし、ある程度補完もすると思いますが、それの逆バージョンだと想像してみてください。
・自己紹介シーンでの注意点
Ruby歴やどんな言語を書けるか？どんな仕事(研究)をしているのか？ということを不用意に言わないことです。
これらは後々の会話のネタになるので、最初のアイスブレイクは日本の話題や、どれくらいこっちにいるの？的な話しやすい話題で始める方が私は話しやすかったです。
自分から言わなくても向こうから聞いてくれますし、
How about you?
で会話を相手に振れますしね。
最初に話してしまうと、ここの話を放ったらかすと、いきなり専門性の高い話に移行してしまうので、オススメしません。(体験談)
日本に興味を持ってるアメリカ人は多いので、桜の写真や富士山の写真を見せるだけでも
Pretty coooool
って興奮してくれます笑
３．専門性の高い話になった時
アイスブレイクも終わって、いよいよ専門性の高い話になった時の立ち回りです。
・自分ではなく相手に話してもらう
今までの会話の中である程度打ち解けていたら、自分がどれぐらい英語を話せるかを相手も理解してくれます。
懇親会の会話はgive and take ということもありますが、相手に質問しこちらがその回答に対して会話を続ける方が続けやすかったです。
アドリブで思い浮かばない人は事前に質問を用意しておくのもいいと思います。*2
・話す時は相手の目を見て話す
時には言葉より気持ちで気合いで伝えることが必要な場面も出てきます。
もしその時に携帯見ながらとか話すのはNGです。別にこれはアメリカに限った話でもないですがね。
言葉が拙い分は目で訴える！！笑
日本人と会話する時の200%増しでリアクションするといいです。
イメージはアナとかのディズニーキャラですかね。
長い文章を話す必要はなく、短めの文章を連発させてもいいと思います。
無理に関係代名詞を使って2つにまとめたりせずゆっくりはっきり一文ずつ伝えることの方が遥かに大事です。実際その方が話しやすいですしね。
４．絶対に避けるべき行動
最後に、これやってるとぼっちになる可能性がある人の注意点を2つ
・隅っこに座ってPCカタカタorスマホいじいじ
こっちの人はフレンドリーな方が多いので、話しかけられて嫌な顔する人はいません。
スタバや電車で座ってて、いきなり隣の人から話しかけられたりもする環境です。
仕事だったら仕方がない部分もありますが、立っているだけでも話しかけてくれたりします。
