複数スペースのBacklogの課題をspreadsheetで一覧表示
Backlog、便利ですよね。
筆者もここ数年、プロジェクト管理ツールはBacklogを使っています。 ツール自体が素晴らしいのは言わずもがなですが、Backlog自体が普及しているということが一番の理由かなと思います。 筆者の場合は付き合っているベンダーさんもBacklogを利用していて、現在は3~4スペースのBacklogで10以上のプロジェクトのタスク管理を行っています。
※Backlogのスペースは、プロジェクトの上位概念で1スペースで複数のプロジェクト管理が出来ます。 スペースが複数となってしまうのは、契約者が違うからです。 自社のBacklogやベンダーさんのBacklogが存在するので複数スペースになってしまいます。
スペースの説明はこちら。 スペース ID とは？ - Backlog（Japanese）
複数スペースのしんどいこと
複数のスペースがあると、筆者自身のスペックの問題もありますが、正直チェックがしんどいです。
理由を考えてみましたが、
- スペース各々でログインしないとタスクがチェック出来ない。
- 全体を俯瞰出来ないので、自分はどれから取り掛かるべきかがわからない。
- 個人の問題が大きいが、好きなプロジェクトばっかり見がち。
- Backlogはタスクの更新があればアラートメールが飛ぶからいいじゃんという話もあるが、全プロジェクトを見る立場になってくると、アラートの数が大量で、とても追いきれない。
複数スペースの課題をチェック出来るツールを作りました！
ネットで似たようなことを考えているか人がいるか探しまして、下記の記事にたどり着きました。
この記事のツールの場合は1スペースにある複数プロジェクトを俯瞰してみるのには良いんですが、やりたいのは複数スペースの全プロジェクトの中で私がやるべきタスクを俯瞰して見たいわけです。
ただ、Google Apps Scriptで結構簡単にBacklogのAPIを利用できるのと、Google Spread Sheetは使いやすい！というのがわかりましたので、作ってみました！
Google Apps Script
とりあえず、コードを張り付けておきますね。大分、さきほどの参照記事のコードを参考にしています。
function main(action) { var IssuesSheet = SpreadsheetApp.getActive().getSheetByName('issues'); /* 一旦、シートをクリアにする */ if(IssuesSheet.getLastRow() > 1){ IssuesSheet.getRange("A2:I"+IssuesSheet.getLastRow()+"").clearContent(); } /* ヘッダをセットする。 */ IssuesSheet.getRange("A1").setValue("space"); IssuesSheet.getRange("B1").setValue("url"); IssuesSheet.getRange("C1").setValue("summary"); IssuesSheet.getRange("D1").setValue("createUser"); IssuesSheet.getRange("E1").setValue("priority"); IssuesSheet.getRange("F1").setValue("status"); IssuesSheet.getRange("G1").setValue("dueDate"); var issuelist = get_issues_lists(IssuesSheet); } function onGet(event) { main('on_manual'); } /* space分の課題を取得して書き込む */ function get_issues_lists(IssuesSheet) { var Confsheet = SpreadsheetApp.getActive().getSheetByName('config'); var range= Confsheet.getRange(2, 1); var values = Confsheet.getRange(2, 1, Confsheet.getLastRow()-1, Confsheet.getLastColumn()).getValues(); var range= IssuesSheet.getRange(2, 1); for(var i=0;i<values.length;i++){ var backlog_team = values[i][0] var backlog_api_key = values[i][1] var backlog_assigneeid = values[i][2] res = UrlFetchApp.fetch("https://" + backlog_team + ".backlog.jp/api/v2/issues?apiKey=" + backlog_api_key + "&assigneeId[]=" + backlog_assigneeid+ "&order=&statusId[]=3&statusId[]=2&statusId[]=1&count=100"); if (res.getResponseCode() != 200) { return false; } // Logger.log("res :" + res); var issues = JSON.parse(res.getContentText()); write_issues(backlog_team, range, issues); range = range.offset(issues.length, 0); } } /* 課題をシートに書き込む */ function write_issues(backlog_team, range, issues) { for(var i=0; i<issues.length; i++) { range.offset(i, 0).setValue(backlog_team); var issue_url = "https://" + backlog_team + ".backlog.jp/view/" + issues[i]["issueKey"] range.offset(i, 1).setValue('=HYPERLINK(\"' + issue_url + '\",\"' + issues[i]["issueKey"] + '\")') range.offset(i, 2).setValue(issues[i]["summary"]); range.offset(i, 3).setValue(issues[i]["createdUser"]["name"]); range.offset(i, 4).setValue(issues[i]["priority"]["name"]); range.offset(i, 5).setValue(issues[i]["status"]["name"]); range.offset(i, 6).setValue(issues[i]["dueDate"]); } }
どんな感じで使うか
見た目はこんな感じです。
モザイク掛かっているのでわかりにくいですが、複数スペースの自分の課題が一覧で取得できました。 これでいちいち各スペースにログインする手間が省けます。 更新は[update]ボタンで行います。
シートに色がついてますが、これはGoogle Spread Sheetの条件付き書式を使っているだけです。 筆者の場合は優先度が「高」のものを目立つように、「低」のものは目立たないようにしました。 これは個人の好みですね。 納期で色分けしてもアリかと思います。
設定はどうしてるか、ですが、別のシートにconfigをまとめています。
ここで、各パラメータについてですが、
「backlog_team」はスペース名になります。
「backlog_api_key」とはBaklogのメニューから「個人設定」＞「API」でAPIキーを新規登録すればすぐに作れます。 こんな画面です。
「backlog_assigneeid」は各スペースでの自分のIDになります。確認方法ですが、課題の検索画面で自分担当の課題を表示したときにurlに「backlog_assigneeid=*****」みたいなパラメータを確認出来ると思うので、それを入れます。
すぐに使えるSpreadSheetをご用意しました
いろいろ説明しましたけど、使い勝手は使ってみて確認するのが一番です。 すぐに使えるSpreadSheetをご用意しましたのでご自由にどうぞ。
Backlog All task - Google スプレッドシート
必ずコピーして使ってください。 Google Apps Scriptもコピーしないと参照出来ないと思いますし。
あと、ご使用は自己責任で！
Webエンジニアがビジネスの理解にも使えるリボンモデル
前回、こんな記事を書いたんですが、
この記事で下記2点が重要だと書きました。
- UI/UXも大事だけど、どんなデータに価値があるのかを考えなければいけない。
- それにはエンジニアのビジネスの理解が重要。
じゃWebエンジニアはどんな形でビジネスを理解すれば良いのかを、筆者なりの方法を書いてみたいと思います。
業務フローを書く前に考えて欲しいモデルがあります
システム開発には業務をシステムに落とすための方法論があります。ユースケースや業務フローを書くとかですね。ユースケースはこんな図ですね。
ただこれらはビジネス側とエンジニアリング側で共通理解を得た上で設計に落とし、システムを構築するための方法です。
少し欠けているものがあります。
- どうやったらサービスが伸びていくか、利益をあげていくか
- 顧客の視点
利益をあげるためにシステムを構築するわけですから重要な視点です。 その時に役立つのが後述するリボンモデルです。
リボンモデル
リボンモデルを知っている人もいるかと思いますが、これはリクルート社がビジネスを設計する手法です。新規事業を考えるときだけでなく、既存事業を伸ばすための分析にも使われるようです。 リクルートは人材、結婚、不動産紹介など様々なサービスを提供していますが、全てこのリボンモデルで説明できます。 リクルートのサービスはBtoCのマッチングサービスが多いと理解していますが、BtoBもCtoCもリボンモデルで説明できます。
もしあなたが開発しようとしているシステムがこのリボンシステムで説明できるなら、ぜひリボンモデルを書くところから始めて欲しいです。
リボンモデルの説明は下記ページが参考になるかと思います。
試しにリクルートの転職サービスである「リクナビNext」のリボンモデルを書いてみました。
凄くさっぱりとした図ですね！でもがっかりしないで最後まで読んでください！
この図のマッチングというのは「企業が人材を採用する」になるかと思います。そしてそれを最大化させるために「企業」と「求職者」を集め、動かし（喚起）、マッチングの結び目を最大化したいことを表現しています。
集めて動かしてマッチングです。
マッチング効率だけ上げてもあまり意味がありません。実際、Webサイトの改善を行うときも、まずは入り口のランディングページから修正した方が効果が早いわけですし。
また、図には現れていないですが、利益を最大化させるためにはマネタイズをどうするかも重要です。リクナビNextの場合、それは広告商品の設計かと思います。
「値決めは経営」by 稲森和夫
開発する上でのリボンモデルを書く効果
先ほどの図で意識したいのは、リボンモデルの登場人物としては「求職者」と「企業」のみです。実際は広告営業とか広告を作るライターとか、求職者を集めるマーケッターとか、オペレーションを回す人とか、登場人物はたくさんいるはずですが、身内は出てきません。 一方、いきなりユースケース・業務フローを書く場合、むしろ身内の登場人物の方がたくさん出てきます。 それだと顧客視点がわかりにくく、何を最大化すれば良いのかもブレやすくなります。優先順位も表現出来ません。
要件定義をするときって、関係者と要件を詰めていくことになると思いますが、リボンモデルを理解しているリクルート社員ならまだしも、ほとんどの場合、各々の関係者が全体を把握していて、かつ顧客視点を有しているわけではありません。参考記事にも書いてありますが、プロダクトアウト型（作りての論理）にもなりやすいと思います。
ただし、もしこのリボンモデルを先に定義しておけば、どんなデータ、機能、施策があればマッチングを最大化できるのか、ビジネスの成功が掛かっているのがが一目でわかるので、組織のコンセンサスも取りやすくなるかと思います。
- 求職者をどうやってたくさん集めるのか。どんな観点で企業を探しているのか。
- 企業をどうやってたくさん集めるのか。どんな観点で求職者を探しているのか。
- 求職者をどんな施策で喚起するのか。マッチングするのか。
- 企業をどんな施策で喚起するのか。マッチングするのか。
ブラッシュアップが重要な部分はこのシンプルな図で説明出来ています。 優先順位付けを失敗しないためにも、組織全体での理解が重要かと思います。
最後に
筆者は今までにたくさんのWebサービスの開発に携わってきましたが、今でも現役バリバリで利益を出しているサービスは半分もありません。
新規事業は失敗する確率が高いのはわかっていますが、開発者側からすると、「そんなにおれらの開発を簡単に無駄にするなよ！」っていう想いもあります。
だからこそ、Webエンジニアはビジネスを理解しようよっていうお話でした。
あと、筆者は元リクルート社員ではないので、ネットで見た情報を参考にこのリボンモデルを理解していますが、間違いなどあれば指摘頂けるとありがたいです。 私のリボンモデルの説明が拙くて、凄さが伝わっていなかったら凄く残念なので、おすすめの書籍も貼っておきます。
リクルートの すごい構“創"力 アイデアを事業に仕上げる9メソッド
- 作者: 杉田浩章
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2017/05/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
UI/UXよりもまず、ビジネスで重要なデータの価値を理解しよう
UI（ユーザーインターフェース）、UX（ユーザーエクスペリエンス）って言葉、格好良いですよね。似たような言葉でIA（インフォメーションアーキテクチャ）も格好良いですね。Webサービスの仕事をしていると良く出てくる言葉です。 そしてWebサービスを作ってて筆者的に一番おもしろいのはUIを設計しているときです。
でもちょっと待ってください。
その前にやることがあります。そもそもどんなデータが必要か、重要かを考えなければいけません。
ユーザにどんなデータを見せるか、ユーザからどんなデータを入力してもらうか、運営側はどんなデータを入れるべきか、どんなデータがマッチング出来るか、紐づけられるか、自動化できるか、計測できるか、、、
大袈裟じゃなく、データ設計次第でビジネスのスケールの速度は段違いです。メモの固まりではスケールするサービスに昇華させることが出来ません。 なぜなら後からUIを変えることより、データベースの構造を変える方が圧倒的に大変だからです。
筆者はリニューアル案件で残念なデータベースにたくさん出会ってきましたが、これはエンジニアがビジネスの理解が足りないのが一番の原因だと思っています。
エンジニアは技術だけでもカバーするのは大変なのに、ビジネスの領域までカバーするのはさらに大変ですが、筆者はもうその時代になってしまったと思います。
IT技術の発展の早さは凄まじく、Webエンジニアは便利なフレームワークやツールで効率良く開発出来るようになりました。 その代わり現在は、ビジネスの理解が強く求められていると思います。
今回はその辺を深掘りしたいと思います。
データ設計に必要なスキル
データ設計に必要なスキルというのは、ひとことで言うとエンジニアリングのスキルとビジネス・マーケティングの理解です。
広すぎですね！
でもそうとしか言えません。
筆者は通販システムを数多く開発してきたので、通販を例にします。
例えば商品データを設計する際、こんなことを考えます。
- ユーザに購入したいと思わせるための情報（アパレルの場合なら「ささげ」（撮影、採寸、原稿））
- ユーザに探しやすくするためのカテゴリや商品のグルーピング
- 仕入れなどバックオフィス業務をまわすために必要な情報
- 会計で必要な情報
- 物流で必要な情報
- カスタマーサポートで必要な情報
- 法的に明記しないといけない情報
- 楽天やYahooショッピングなど、マーケットプレイスに出品するための情報
- SEOに必要な情報
- データフィード広告など広告に必要な情報
- あとで分析するために必要な情報、MD的な観点
もちろん一人で全部把握しているわけではないので、関係者からヒアリングして設計をしていきます。
さらに加えて、エンジニアリング的な知識、制約も把握しておかなくてはいけません。 データ量が大きければ、データベースを非正規化をしたり、検索エンジンを入れたりするなど考慮が必要になってきます。
また、通販システムは注文データ、顧客データ、在庫データなど他にもたくさんのテーブルがあります。 複数のテーブルのデータをうまくマッチングさせることが出来れば、ユーザにレコメンドする機能、通知する機能、ユーザを掘り起こす機能、運営者が楽になる自動化の仕組みなど、サービスをスケールさせるための機能を開発することができます。
データに価値が生まれるとき、大体の場合、複数のデータを組み合わせることで起こります。
例えば筆者が通販で効果を上げた事例だと、商品のブランドのデータ、広告のデータ、顧客のLTV（1顧客あたりの消費金額の合計）のデータを掛け合わせることにより、ブランドワードのCPA（1注文あたりにかかった広告費）で判断していたリスティング広告の評価方法を、LTVの高いブランドで評価することにより、広告のパフォーマンスを上げた経験があります。
データはクロスさせると価値が出る、これだけは覚えて帰ってください！
（このあたりはいずれ深堀したい）
ちょっと話がズレますが、エンジニアが一番、その会社のビジネスを理解しているケースって多々ありますよね。 ただそういう会社に限ってサービスがあまりスケールしていないと感じます。 まー統計的な根拠があるわけでなく、あくまでも筆者の経験論です。 ただサービスがスケールしない理由に、そのエンジニアに頼りきっている、そのエンジニアをボトルネックにしてしまった、というのは原因としてあると思っています。
ビジネスサイドもデータの価値というのを理解すれば、良い化学反応が起きるのになー、惜しいなー、惜しいなー
データ設計を邪魔するもの
筆者がデータ設計をするときに一番困るのは「私は関係ない」という考えです。
先ほどの商品の例でもいろんな情報を集約してデータを設計しているのがわかると思いますが、関係者の中には「私にその情報は関係無いからその入力は必要無い」、みたいな意見は良く耳にします。
もちろん運用が楽になるように設計をすべきですが、必要か、必要でないかを判断するのは、全体を把握していなければ出来ないはずです。 しかし日本の組織の場合、役職やパワーバランスで決まってしまうケースも多くないですか？
ただ筆者もそこそこベテランです。
うまくデータ設計を進めるコツがあります。
要件定義の最初に伝える言葉があります。
情報が価値となり、サービスがスケールするためには下記が必要です。
- 検索できる、発見できる
- マッチングできる、紐づけられる
- 集計できる
単なるメモでこれは出来ません。あたなはそれで楽かもしれないが、タイトルに入れておけば大丈夫！じゃないんです。
メモじゃ人間が把握しておかなければいけないし、人間が把握できないものは動きません。
逆に様々なところでこれが出来れば、自動化出来る範囲が広がり、サービスもスケールすることが出来るでしょう。
例えば昨今流行りのMA（マーケティングオートメーション）もこれが出来ることが大前提です。
誰の視点でデータを設計すれば良いか？一番増やしたいのは顧客ですよね？
顧客を増やすためのデータ、顧客が増えても楽なデータベースを一緒に考えませんか？
なかなかこれを否定することは難しいですよね。
最初に宣言しておけば、協力してくれる人も増えるかと思います。
さらに具体的にメリットを提示できると、もっと良いですね。
- こんなデータを入れてくれれば、こんな軸で探しやすくなり、ユーザビリティだけじゃなく、SEO的にもいいよ！
- このデータを紐づけられれば、ユーザにアラートを出せてアクティブ率をあげられるよ！
最後に
実はこのテーマを書きたかったきっかけがありまして。
この記事はドワンゴの川上量生氏と、ただいま炎上中の伊藤直也氏の対談記事なんですけど、
この記事の中で川上氏は、
「僕が嫌いな言葉でさ、UIとかUXとかあるけど、どうでもいいのよ。UXとか言い出すもんだから、間違ってクリエイティブな方向に行くんであってさ。」
「WEBのエンジニアってクリエイターではなく、工業デザインに近い」
「デザイナーっていうのは、サーバとかのアーキテクチャをわかってない人間がやるべきじゃないと思う。まぁ、サーバと言わないまでも、クライアントのレベルっていうか」
この意見に筆者も同意です！
ちょっと簡単にUIとかUXって言葉を使いすぎじゃないですかね、昨今。 まー確かに誰でも参加できるテーマと言ってもいいかもしれません。
筆者は過去に「UXを強化する通販サイトのリニューアル」の請負の仕事を行ったことがあります。 結果その通販サイトはSEO的に多くのインデックスを失い、よってまたサイトのリニューアルを実施しました。 そのプロジェクトにやはりいたんですよ、UI/UXのことばかりで、システムやマーケティングの知識が皆無な担当者が。
システムの仕様というのは様々な要因のトレードオフで決まってきます。商材、業務、データベース、マーケティング、組織、コスト、、、UIもその例に漏れません。仕様を決める人間は全体を把握した上で決めなければいけません。全体を把握していない、設計出来ない人間がUIの仕様を決めてしまうのは危険しかありません。
UXが優れていると言えば、Apple製品が思い出されます。 例えばiPhoneは電話を再発明しました。単純に製品が使いやすいというだけでなく、アプリとそれを流通させるプラットフォームは大きな市場を作りました。 iPhoneを作ったジョブスはデザインに深い造詣がある前に、ソフトウェアとか工業製品とか通信とかプラットフォームとか、多くのことを把握しています。ジョブスはAppleに復帰する前も、OSを開発している会社をAppleに売却したぐらいです。何が言いたいかと言うと、優れたUXを作るためには様々な知識が必要なんです。
特にデザイナーとかWebディレクターと呼ばれる人たちが多いんですが、簡単にUI/UX言い過ぎちゃうところがあります。もっと裏側というか背景を汲んでから考えて欲しいなと。 エンジニアもビジネスに対する深い理解が必要だと先に述べましたが、デザイナーもそういう時代になったかもしれませんね。
Webに携わる人なら非エンジニアも知っていて欲しい、HTTPのCookieとSession
前回の記事の続きです。
今回はHTTPのCookie（クッキー）とSession（セッション）について書いてみます。
やっぱりこれも理解していないと様々な弊害があります。
非エンジニアだから関係無いとは言い切れません。
- CookieとSessionがわからないことによる弊害
- もしHTTPにCookieとSessionが無かったら
- Cookieとは？ Sessionとは？
- 広がるCookieの用途、3rd Party Cookie（サードパーティクッキー）
- 最後に
※.前回の記事を理解している前提で書いていきます。
CookieとSessionがわからないことによる弊害
まず、わからないことによってどんな弊害があるか、例をあげてみます。
例というか実は全て私の経験談です。恐ろしー(‘Д’)
- （昔のガラケーのサイトで多い話ですが）URLにSESSIONのIDを書くようなシステムで、SESSION ID付きのURLをメルマガなどで送信してしまう。
結果：下記サイトのセッション乗っ取りと同じ状態です。セキュリティ的な大事故です！
- Sessionに入れるべき会員番号をCookieに入れてしまい、Cookieの書き換えで個人情報が抜けてしまう。
結果：これもセキュリティ的な大事故です。
エンジニアはもちろんWebサイトのセキュリティについて勉強すべきです。 IPAの「安全なWebサイトの作り方」は理解する必要があります。
非エンジニアの方もエンジニアがせっかくセキュリティ対策を行っても、人為的な穴を空けてしまいますので、基本的なことは理解しておく必要があります。
もしHTTPにCookieとSessionが無かったら
セキュリティ的な穴が開く危険性があるのに利用するわけですから、やっぱりCookieとSessionは便利なんです。 GetとPost同様、CookieとSessionもHTTPに定義されているもので、Webサーバとブラウザ間のやりとりの一部として規定されています。
Webは基本的には情報をGetする（取得する）、Postする（送信する）ものですが、状態によって画面の表示を変えたい場合があります。
例えばAmazonような通販サイトでは
- 会員登録をすると「こんにちは〇〇さん」というような個人に合わせた表示をする。
- 会員が過去にチェックした商品を表示する。
- カートに入れた商品情報を表示する。
この時、ユーザを特定するときに使われるのがCookieであり、Sessionです。
これらの説明は「CookieとSessionのおかげで、ステートレス（状態がない）からステートフル（状態を持てる）になる」と一言で言い換えられます。
「ガラケーの時代はWebサイトをステートフルにするのが大変だったなー(‘Д’)」という言い方だと「歴戦の猛者」感を演出できます！
Cookieとは？ Sessionとは？
当たり前の話ですが、Webサーバはたくさんのユーザからのアクセスがある前提で出来ています。
そしてユーザごとに画面表示を変えたい場合どうするか？なのですが、
Webサーバにアクセスがあったブラウザに対してCookieを発行する。そのCookieがユーザに対して一意のIDであればそれはSessionのIDとも言える。
ブラウザが次回以降、そのWebサーバにアクセスする際はサーバから発行されたCookieを含めて通信する。 これによってWebサーバ側ではどのユーザからアクセスがあったかを理解することが出来る。
Webサーバ側でユーザの情報を保持する仕組としてSessionがある。例えばカートに入れた商品の情報やユーザの閲覧履歴など。CookieにSessionのIDが含まれている間はユーザを特定し続けられる。
※.システム構成にSessionの管理方法は大きくことなります。大規模なサイトではSession管理だけで1冊本が書けそうです。
そして注意点としては、
Sessionの情報はあくまでWebサーバ側の情報であってブラウザ側には存在しないものです。ブラウザはCookieの仕組みでSession IDを送信するのみです。
ブラウザがWebサーバにCookieを送信する際は別のサーバで発行されたCookieを送信することはありません。送信してしまうとセキュリティ的な大問題です。
WebサーバがCookieを発行するときに、有効期間を設けられます。Session IDを保持しているCookieに有効期限を付ければ、それはSessionの有効期間となります。
Cookieよりも大きな容量のデータを保持できるWeb Storageというものもあります。
- Session IDをCookieに保存する方法もあれば、URLで送信する方法もあります。これはCookieが使えないガラケーのサイトで良く用いられた方法です。これを用いる際はセッションが乗っ取られないように、セキュリティ的な対策を講じておく必要があります。
広がるCookieの用途、3rd Party Cookie（サードパーティクッキー）
3rd Party Cookieは既に広がって久しいですね。アドテクには必要不可欠なものです。
例えばAmazonで商品を物色して、そのあとYahooニュースでAmazonで見た商品が表示される広告も3rd Party Cookieがあるからこそです。
アドテクの話をすると長くなりそうなので、アドテク以外にも3rd Party Cookieが使われている例を挙げますね。
メディアサイトでFacebookのいいね！やTwitterのフォローが簡単に行える。 これはブラウザにFacebookやTwitterのCookieが保存されていれば、わざわざログイン作業が必要無いということですね。 いいね！したときの動作としては、ブラウザとFacebookのWebサーバ間の通信で、この通信にはメディアサイトのWebサーバは登場しません。
ユーザの行動履歴を取ってマーケティングに活用。 MA（Marketing Automation）で行われていることですが、サイトにユーザをトラッキングするためのタグを貼り、その情報をもとにマーケティング活動（広告の出稿をチューニングしたり、自動でメルマガをしたり、スコアリングして重要な顧客からタッチしたり、いろいろあります）を行います。
3rd Party Cookieはユーザが意図しないところで通信が発生するケースが多いので、セキュリティ的な問題を指摘されることがありますが、もうInternetの世界では必要不可欠になってしまっている技術とも言えます。
最後に
HTTPのGet、Postに始まり、今回はCookieとSessionを説明しました。
非エンジニア向けに簡単な文章にしたつもりですが、簡単に説明するっていうのは本当に難しいですね。 今回のはそんなに難しい技術ではないんですが、、、
そしてなぜ難しいか、理由を考えたんですが、恐らく1個の技術を説明しようとしたときに、前提が多いとか、関連する技術がまた2個、3個と出てくるからかなとも思いました。
挫折する人ってそういうところで挫折するのかなー
Webに携わる人なら非エンジニアも知っていて欲しい、HTTPのGetとPost
Webの仕事をしている人はHTTPのGet、Postは絶対覚えるべきです、エンジニア以外も。
反論は受け付けません。なぜなら弊害があるからです。
HTTPとは？
HTTPというのはHyper Text Transfer Protocolの略になり、Webサーバとブラウザ（ChromeやSafariなど）とのデータフォーマット、通信方法、ルール・手順を定義したものになります。
最後のProtocolというのは規約とか手順といった意味があるので、
「あいつとはコミュニケーションのプロトコルが合わない」
って言っとけばIT業界人っぽく見せることが可能です(´▽｀)
HTTPのデータフォーマット
その中のデータフォーマットでメジャーなのが、みなさんご存知のHTMLになるわけです。
もちろん画像や動画なんかもデータとして認められているので、文字だけじゃなくて綺麗な写真がみえたり、Youtubeで動画が見れたりするわけです。
HTTPの通信方法
そして通信方法の中に今回のテーマのGet、Postが定義されています。 そして通信というのは、Webサーバとお使いのPCやスマホで利用しているブラウザ間の通信を指します。
Getとは？
これは文字通りですが、情報を取得する（ゲッツ！）という意味です。
この時、
- ブラウザがWebサーバに対して目的のURLの情報（www.hogehogehoge,xyz/get.html）を要求する。
- Webサーバがブラウザに対して、要求された情報を送る。
すごく当たり前のように聞こえますね。 そして我々がブラウザでやっている操作のほとんどはGetになります。
大事なのはPostとの違いなので、先に進みます。
Postとは？
Postとはサーバに対して情報を送信することを指します。 ここで気付いたと思いますが、GetやPostの主語はブラウザなどのクライアント側になります。 ブラウザがGetする（情報を取得する）、ブラウザがPostする（情報を送信する）ということです。
Postを使う時の代表的な例として、通販サイトで商品を購入するために、メールアドレスや住所などの個人情報を入力するケースがあります。 もちろんテキストだけでなく、HTTPは動画や画像も扱えますから、最近はそれらを送信することが多いかもしれません。
この時の動きとして、
- 会員情報を入力するための画面（www.hogehogehoge,xyz/post.html）を要求する。
- Webサーバがブラウザに対して、要求された情報を送る。ここまでGetと一緒。
- メールアドレスや住所などを入力して、Webサーバに対して情報を送信する。そのときのURLは1.と同じかもしれないし、違うかもしれないが、URLには入力した情報は含まれない。
- Webサーバ側で受け取った情報をもとに、新たな情報を返却する。入力情報が間違っているかもしれないし成功するかもしれないので、入力内容によって返却内容は異なる。
GetとPostの違い
Getで情報を取得する際に、情報を区別するためのキーは基本的にURLだけです。 そしてWebの特徴であるリンクはURLで情報がユニーク、一意ということでが成立しています。
ですから
“www.hogehogehoge,xyz/a.html”
と
“www.hogehogehoge,xyz/b.html”
で同じ情報を表示されても困りますし、アクセスするたびに違う情報を送信されても困ります。
当たり前ですけど、ちゃんとルールがあるから気軽にリンクが張れるわけです。
一方Postは、ユーザが入力した情報をもとに画面の情報を切り替えて返却します。ただし、入力情報によってURLが変わるわけではないです。
URLが変わらないのに、表示されている画面が違うとも言えます。
Postのありがちなミスとその弊害
楽天の検索画面を思い出して欲しいのですが、検索条件に商品のカテゴリやブランド、あとフリーのキーワードや送料無料の条件など、いろんな条件が入力できると思います。 それらの条件は確かにユーザが入力するものですが、基本的には情報を取得する、Getする行為なので、Getで書くのが正しいです。
これをユーザが入力するからといって、Postで書いたらどんな弊害があるか？
先に述べた通り、ユーザが入力した情報はURLには含まれませんから
- リンクを友人などに共有しても同じ情報が見れません。
- ブラウザの閲覧履歴というのは基本的にはURLの履歴です。ブラウザの[戻る]ボタンで前の情報を出そうとしてもうまくいきません。使いにくいUIになってしまいます。
- Googleなどのクローラがサイトを巡回しても、URLで一意な情報が作れないわけですから、適切にインデックスを作成できません。つまりSEO対策が出来ていません。
- URLで一意にならないわけですから、どの画面が良く見られているかなどのアクセス解析が出来ません。
結構な弊害がありますよね。Webサービスとしては完全にアウトです。
今ではほとんど見かけなくなりましたが、これを理解していないエンジニアがいることもまた事実です。
なのでエンジニアに発注する側も理解すべきです。
また、Postはブラウザの[戻る]ボタンに弱いことも言及しました。 例えば会員登録などの仕組みは複数画面にわたる場合があり、[戻る]ボタンをユーザが使ってしまうケースがあると思います。 その対策にPRGパターン（Post Redirect Getの略）と手法があります。
これ非エンジニアに理解はつらいんですが、これも見ておくことをお勧めします。
もう一声！
HTTPのCookieとSessionについても書きました。 これもWebに携わる人は理解すべき内容です。
理解すると、むしろ武器になりますので是非ご一読ください！
