【読了】Kubernetes 入門 第1章

入門 Kubernetes

EKSがGAになる前に勉強しとく！

Kubernetesを使う利点

ベロシティ(速さ)

• CDに入れられるソフトウェアから、Webベースのサービスに移り変わりユーザーへ提供するスピードが速くなった
• 近年はスピードに加え可用性を求められ、常にサービスを提供していく必要がある
• Kubernetesとコンテナがあれば、これらを実現出来る
• これを実現するための核となるコンセプト
  • イミュータブルであること
  • 宣言的設定
  • オンラインで自己回復するシステム

イミュータブル

• イミュータブルであることは分散システムを構築しやすい、ロールバックが容易
• ミュータブル：伝統的にシステムはミュータブル。既存のバイナリや設定ファイルを変更が積み重ねられる
• イミュータブル：一回のオペレーションでイメージを更新する、既存のものを変更するのではなく新しく入れ替える

宣言的設定

• Kubernetes上はすべて宣言的設定のオブジェクト
• 宣言的なため、設定間違いが起こりにくい、ソースコード管理ができレビューやテストをしやすい
• 宣言的設定(declarative)：状態を定義する(Ansibleやコンテナのように状態を定義)
• 命令的設定(imperative)：命令的なコマンドの羅列によって状態を定義する(古くからある手順書による設定)
  • 例：あるソフトウェアのレプリカを3つ起動するとき
  • 宣言的設定：レプリカ数を3にする
  • 命令的設定：Aを起動し、Bを起動し、Cを起動する
• 昔ながらの切り戻し手順考えて頑張ってた世界がかなり簡単で完全にロールバックできるようになる

自己回復するシステム

• 旧来であれば命令的なので、障害はアラートで通知され、オペレーターが手順に従い復旧を行う
• Kubernetesは宣言的設定になり、その状態は継続的に保たれる。障害が起きても宣言的設定に従い、状態を回復すり。AWSでいう、AutoScalingのイメージ。
• オペレータが介在しないので、確実で素早く、コスト効率のよいシステムを運用できる

サービスとチームのスケール

分離

• 分離し境界を設けることで、チームのスケールとインフラリソースのスケールが容易になる
• 各コンポーネントの分離：各コンポーネントはAPIで分離
  • チームの境界が明確になる
  • コンポーネント単位でのスケールが可能になる
• インフラの分離：インフラはロードバランサとコンテナによる分離
  • 各チームがインフラの競合を意識せずに、アプリケーションをデプロイできる
  • スケールがしやすい

アプリケーションとクラスタの簡単なスケール

• コンテナのスケールはイミュータブルかつ宣言的設定なので容易
• クラスタのスケールも、コンテナによるインフラの分離がされているので、インスタンスをクラスタに追加するだけ
• 複数のアプリを同じインスタンスで共有できるので効率が良い

マイクロサービスによる開発チームのスケール

• チームの人数は2枚のピザ。ただ開発規模との兼ね合いで人数が必要だったりする。これはマイクロサービスによる複数チームによる開発で解決する
• Kubernetesはマイクロサービス開発を容易にする、抽象化層やAPIを提供する
  • Pod：複数のコンテナをグループ化
  • マイクロサービス間の接続のために、ロードバランシグ、ネーミング、ディスカバリ機能を提供
  • Namespaceが分離とアクセス制御、リソースの分離など
  • Ingress：ロードバランシングとインターネットフェイシングのエンドポイント、SSLのターミネーション

インフラの抽象化

• インフラ管理とアプリケーション管理を分離できるので効率的

効率性

• 1つのサーバーに複数アプリを依存なく、効率的に起動できる、集約できる

【読了】部長の仕事術

部長の仕事術 (アスカビジネス)

ふと、部長に求められることに興味を持ったので読んでみました アウトプットしておきます 感想としては今の会社は、メンバー、マネージャー、部長、社長に恵まれてるなと思った。なぜなら、この本に書かれていることは当たり前なことでしかなかった。そして今の自分を継続して行っても大丈夫って自身を持てた。ただできてない箇所もあるので、今後は意識して実践していく（ボールドの箇所）

部長と課長の違い

部長には経営上の重要な判断をし、部門の長 課長は一般社員と仕事することが多く、現場レベル仕事がメイン

部長に求められること

• 専門性より組織を動かすこと
• プロセスより結果
• 過去より未来にコミットし、どうやって実現するか
• 世の中は進歩しているのに、去年と同じことをやっている状態だと、衰退しているだけ
• 部下の話に耳を傾ける
• 2 - 3年後のビジョンを持つ

部長のマネジメント力

• 誰に対しても丁寧に対応する、メンバもお客様と考える
• 地味で面倒な仕事でも重要、監査とか。他の部署との面識も増える
• 組織やそれ以外の業務に関する方針を作ること、臨機応変い対応できる組織にすること
• 細かい指示を伝えるのではなく、目標、方針、予算、スケジュールだけ伝える、報告を受けながら軌道修正する
• 失敗を恐れて細かく聞いてくる場合は、失敗を許容する文化を意識する、本人が考えて行動するために指示を我慢する
• 作業を細かく分担するると、視点が全体的ではなく局所的になる。結果、他の人の作業を気にしなくなる。スクラム的なアプローチが有効そう
• 属人化を排除して仕組みで対応できる組織を目指す
• 判断力と決断力、決断したあとの補正、いい情報だけで判断せず、0ベースでもの後を見る
• 悪い情報こそ早めに報告し、軌道修正する
• 工数は5割り増しで想定するのが落とし所、見直しや他部署との連携など想定外が起こるので想定しておく
• 時間がないときに、早めに判断して手放す。早く判断しないと、時間だけがなくなり、チームの負荷が大きくなるだけ
• プレイング部長で、部下のことを気にかけないのはだめだよね、部下の成長を考えながら仕事を渡す
• 部下の相談は速攻で乗る、すぐ判断する
• モチベーション低下やマンネリしたら、他部署移動を案内したり
• ＊チェックポイントを設けておく、序盤、中盤、終盤、いいかんじに物事をすすめるため、後から遅れに気づいて怒るのは3流だと思う
• 定期的な振り返りポイントを設ける、私の場合はこういう本を読んだり、銭湯行った時。＊月一で銭湯行く日を設ける
• 打ち合わせは自分の意見を通す場所ではない、会議の目的を達成すること。必要なのはファシリテーション力。聴いて相手の意見を引き出す。＊意見をしていない人にどう思うか聴く
• プレゼンに必要なのは、相手が判断するためのポイントを齟齬なく伝えること、それには相手のリサーチが最も重要

部長の数字力

• 人は見たいと思う現実しか見ようとしない、いい数字はよろこばれる、悪い数字は受け入れられにくい
• 世界共通で、悪い報告は叱責される、ただ叱責だけだと隠蔽や報告の先延ばしが起こる、そして叱責しても事実は変わらない
• 悪い報告こそ早く行う
• 悪い報告をされる場合は、一呼吸置いて笑顔で話を聴く、建設的な話をする、悪い報告をしやすい工夫をする
• ＊数字を把握することで、投資やネクストステップ、現在の課題が浮き彫りになる。数字を根拠に話す
• ただし数字を武器にしない、社員のモチベーションを結果的にさげる可能性がある。相手をねじ伏せるのではなく、前向きな目的のために数字を使う
• 数値の予測の場合は、正確さよりも早さが重要な場合もある
• 成果を横取りされる場合もなきにしもあらず、数字は他部署に渡さない
• 悪い数字は早めに報告する、部長レベルだと足の引っ張り合いや功績の奪い合いになる可能性あり
• 通常の数字と、挑戦的な数字やベストケース、ワーストケースなどの2段構えで用意する

部長の育成術

• ダイバーシティを理解し、特性や属性に合わせた育成を実践する
• 新入社員は暖かく迎えて、育む雰囲気を作る
• メンター制度を導入する、安心して頑張れる環境を用意する
• 仕事の半分は部下の育成に使う、細かい指示は出さず目的、方針の共有をし進め方をガイドする
• 部下は部長の手足ではないよ！
• 仕事の移譲とサポート
• 言われたことを着実にこなすタイプは、思い切って担当を変えて成長する機会を与える、ただし責任は自分がもって安心して仕事ができるように伝える
• 上級管理職に適任な人とは？バランス型、調整もするし、着実に仕事もこなしつつ環境も整備できる人
• 地位があがると結果責任を求められるようになるが、部下には結果だけではなくプロセスも考慮する
• 評価する場合は企業理念に沿っているかを考慮する、企業理念から逸れた方法で業績をあげても評価しない、それをきちんとフィードバックする

部長の人間力

• 公平性を持つ
• 誰にでも同じ態度をとる、人によって態度を豹変しない
• 弱い立場の人にも同じ態度で、協力的に、ただし改善など建設的なフィードバックはバシッと。目的は互いのためでありwin-winになるようにするため。
• 年齢や性別、人種も考慮し公平性を保つ
• 誠実さを持つ
• ルールで縛らない、ルールよりも価値観を大切にする
• 価値観を定期的に共有する
• 部下のやったことに責任を持つ、責任をとる
• 柔軟性を持って、走りながら考える
• スピード感を持って仕事を進める
• ＊弱みを強みに変える
• 失敗したこととどう挽回したか、調整したかというネタをもっておく。失敗したことから学んだこと、そして挑戦すること
• 修羅場は買ってでも体験する。そうすると苦難に遭遇しても開き直れる。これはすげーわかる！冷静な頭脳と温かい心を手に入れられる
• 社畜とは自分の意思と良心を放棄すること、上司に絶対忠実である必要はない！
• 会社の理念の共鳴して、理念を追求してく人を新社畜として定義

役員の出世術

• 部長はスキルより人間力が大切、役員は人間力より運が大切
• 無駄に敵を作らない、人格や能力を否定しない、論理で相手をねじ伏せない、恥をかかせない
• 言い訳をしない、バックアッププランを用意する
• 不運のことが書いてあったけど、個人的には運に逃げるのは好きじゃない、良いこと悪いことは必ず起きるので、考えて対応していくかが超重要。運は言い訳。
• 負のエネルギーをためない、感情的にならない

苦難の乗り越え方

• 部長は逃げ出したくなるようなことが多々起こる、対応するときのアドバイス
• 会社の業績が悪いときでも、致命的な失敗しないこと。命や法に触れるとかはしちゃいけない、窮地に陥ると判断ミスしやすい。倒産しても命が取られるわけではない、またやり直せる
• 上司とうまくいかない、相手の要求に応えること、例えば不安だからマイクロマネジメントを行う、この場合は自分の実力を伝えて信頼を勝ち取るとまるっと任せされる
• いじめやパワハラ、仕事に注力する、あまりにひどい場合は転職も検討する
• 部下から総スカン、一方的にやる気がない、たるんでると押し付ける、やり方が間違ったときでも、めげずにコミュニケーションしていく

部長の自己啓発

• 部長になっても自己啓発は大切ね
• 年一回振り返りをする、職務経歴書をアプデする、マンネリ回避してチャレンジしていく
• ＊自己啓発に歴史、哲学が必要、自分の物差しを得る
• 実務は専門家に任せる
• 専門家に任せられる程度の知見を持つ
• 英語、粘り強い英語、質問力
• ＊会計力、簿記3級レベル

宿題

• ＊数字を把握することで、投資やネクストステップ、現在の課題が浮き彫りになる。数字を根拠に話す
• ＊弱みを強みに変える
• ＊自己啓発に歴史、哲学が必要、自分の物差しを得る
• ＊会計力、簿記3級レベル

読了 SCRUM BOOT CAMP

SCRUM BOOT CAMP THE BOOK

読んだのでアウトプットしておく

スクラムとは

• プロダクトをチームで作り上げる
• プロジェクトの透明性を大切にする
• プロダクト小さく作って育てていく ためのメソッド

ウォーターフォルと比較

• ウォーターフォルはタスクで担当が決められて分業なイメージ、スクラムは全員がプロダクトに責任を持つスタイル
• ウォーターフォールはリーダーが管理するスタイル、スクラムは全員がプロダクトの方向性や機能の背景、要件を知りかつプロジェクトの状況も把握し課題があったらチームで解決する
• 要件がかっちり決められたらウォーターフォール、それができない新しいプロダクト、未来がわからないものについてはスクラム

メソッド

• プロダクトバックログ：要求がすべて記載されているリスト。優先順位が高いものを上にもっていく。開発は上から順に実装していく。機能をどうつかうかというストーリー、テストができる具体的なレベルで記載する
• スプリント：2週間とか1ヶ月とかテンポを決めてプロダクトをシップする。期間を延長しない。
• スプリントバックログ：開発チームのためのタスク一覧

ロール

プロダクトオーナー

• プロダクトの結果責任。要件を決めプロダクトバックログを管理する。開発チームと協力してプロダクトを作っていく。
• リリース計画
• 予算管理
• 利害関係者への報告、相談
• 開発されたプロダクトの検査

開発チーム

• プロダクトバックログの項目に従って開発していく
• 3-9人で構成される
• 上下関係なし
• スキルを補って全員で開発する
• スプリント期間を決め、その間にリリース判断 可能な成果物をアウトプットする
• プロダクトバックログからタスクとして切り出して、スプリントバックログを作る
• デイリースクラム：昨日やったこと、今日やること、困ってることを簡潔に共有する

スクラムマスター

• プロジェクトがうまくまわるようにサポートする
• 妨害を排除し、支援し、スクラムについて教育する
• プロジェクト効率的に進めるために妨害リストを作って、課題を解決していく
• PMとしてスケジュール管理するS

プロジェクトのキックオフ

インセプションデッキやビジネスモデルキャンバスを使って、チームないでプロジェクトに関する共通認識をもっておく

見積もり

プロジェクトがいつ終わるか、どれくらいの工数がかかるかを見積もるにはプロダクトバックログを利用する プロダクトバックログには、要件がまとまってるので、どれくらい開発がひつようか、1つ1つの項目に対して行なって合計をみる 開発チームが見積もるのがよい、この機能を開発するにはどれくらいか、1から10で数値化する あとはスプリント1回でどれくらいのポイントを消化できるかがわかれば、必要な期間、期間に合わせて人数がどれくらい必要かを見積もることができる

ただし、マニュアル作成やリリースにかかる作業が見積もりから漏れることがある マニュアルやリリース、インフラ構築など非機能要件、マーケティング活動につても最初から検討できるとよい

リリース作業が見積もれない場合は、スプリント以外のスケジュールとしてリリース期間を設ける

ルールはチームで決める

• デイリースクラムの目的とルール
• リリースに関するルール
• などなど チームで決めることで、なぜこのルールが必要かの共通認識を持つつともに、ルールに問題があればチームで改善できる

進捗アップするには？

スケジュールを前倒ししたいと言われても簡単ではない 前倒しするには人を増やすことで可能だが、スクラムに慣れる、チームに慣れることが前提になるため時間がかかる

技術的負債

プロジェクトを進めていくと必ず発生する これをいつ返すか、必ず悩む時期がくる 技術的負債を理解した上でプロジェクトを進める必要がある

スコープの調整

リリース前にスケジュールが間に合わない可能性が出てきたらどうする？ 予算、期間、スコープで調整する ただ、まずスコープを再度検討することからはじめる 最低限の要件を満たすようにする、必要な機能に対し優先順位を決める、ユーザーの要件を満たすようにしながら不要な機能をけずる、実現方式をかえて簡単な実装に変更するなど

開発チームでのスキルマップ

全員がなんでもできるわけではないので、スキルマップを作って得意不得意を見える化し、得意なことでチームに貢献できるような仕組みを作ろう

規模が大きい場合の開発

規模が大きい開発でスクラムをやるには、スクラムチームを複数作って対応していく マイクロサービス化し、システムを分割してスクラムチームを作る

パソコン環境の整理、やりたいことを見定め適切なデバイスを選択する

ipadとかmacbookとかiphoneとかkindleとかデバイスを複数持ってるんですが、どのタイミングでどれ使うと適切かってあまり考えてなかったのでちょっと整理してみました。

目的

さまざまな場所でアウトプットできる環境を用意し、学習効率を上げたい 気軽にアウトプットできるように、環境に合わせてデバイスを選択し目的を達成できるようにするのがゴール

プレイス

アウトプットする場所を整理する - 電車 - リビング - カフェ - 図書館

やりたいこと

どんなことをやりたいかを整理する - 英語 - 技術検証 - 技術ブログ - 読書 - 読書ブログ - 技術に関する情報収集 - ライフログの記録と振り返り

デバイス

持っているデバイスと、その役割を整理する - MacBook Pro - 技術検証 - ブログ - iPhone - 日々の情報収集 - Apple Watch - ライフログの記録 - iPad Pro - タスク整理 - ブログ、メモ - kindle paperwhite - 読書

アプリ

やりたいこを実現するためのアプリを整理する - twitter - facebook - feedly - backlog

課題

インターネット環境の用意

• 公衆無線LANを契約する？
  • 使える場所があまりないのでやめる
• モバイルwifを契約する？
  • コスパを考えた時に外で毎日がっつり使うわけではない
• 結論
  • テザリングしつつ、容量が足りなくなりそうであればlineモバイルのプランを見直す
  • lineモバイルとだとプラス1000円で月10GB使えるからまぁ大丈夫でしょう

バッテリー問題

• テザリングによるiphoneのバッテリー減りをどうする？
• 結論
  • ankerのpower coreがあるので事足りている
  • 容量不足を感じるようになったらモバイルバッテリーの購入を検討する
  • 電源あるカフェを探す

まとめ

• iPad Pro
  • 日々持ち歩いてアウトプットする
  • 電車やカフェでライトに使う
• Macbook Pro
  • 日々持ち歩かないが、必要に応じて持ち歩く
  • 主に技術検証を行う場合に利用する
• Kindle
  • 日々持ち歩いて時間を見つけてインプットする
• Apple Watch
  • 日々つけてライフログをつけ体調管理する

【読了】中学・高校6年間の英語をこの1冊でざっと復習する[1日目]

3人称単数、現在系

• 一般動詞に(s)がつく
• 1人称(I)、2人称(You)以外にsがつく
• 複数系はつかない(Theyなど)
• 3人称は代名詞(he, she, it)とこれに置き換えられるもの
  • he: Mike（マイク），my brother（わたしの兄〔弟〕），Mr. Tanaka（田中氏）
  • she: Yumi（ユミ），my mother（わたしの母），Ms. Sato（佐藤さん）
  • it: this book（この本），my bag（わたしのバッグ），the dog（その犬)

疑問文と否定文

• Does he play tennis?
• He doesn't play tennis.
• 3人称単数の場合does、それ以外はdo

文の要素

• S(主語), V(述語動詞), O(目的語), C(補語), M(修飾語)
• 主語(Subject): 誰が
  • 主語は、名詞と代名詞
  • [I] am Jun.
• 述語動詞(Verb): 〜である、〜する
  • 述語動詞は、be動詞、 一般動詞、 助動詞 + 動詞
  • I [am] Jun.
• 目的語(Object): 〜を、 〜が
  • 動詞の対象(私は〇〇を見る)
  • 目的語は、名詞と代名詞
  • I play [tennis].
• 補語(Complement): 主語または目的語を補足する
  • 私の名前は〇〇です(私 = 〇〇)
  • 補語は、名詞と形容詞
  • I am [Jun].
• 修飾語(Modifier): 形容詞、副詞
  • 修飾語はなくても意味が通じる
  • He run [fast].

5文型

• 1: 主語(S) + 動詞(V)
• 2: 主語(S) + 動詞(V) + 補語(C)
• 3: 主語(S) + 動詞(V) + 目的語(O)
• 4: 主語(S) + 動詞(V) + 間接目的語(O) + 直接目的語(O)
• 5: 主語(S) + 動詞(V) + 目的語(O) + 補語(C)

第２文型: 主語(S) + 動詞(V) + 補語(C)

• He is [a teacher].
• []が補語
• 補語は、主語を補う言葉。主語 = 補語
• 第２文型の動詞
  • 〜である： be動詞(am is are was were)
    • He is a singer.
    • She is kind.
  • 〜になる： become get grow comeなど
    • She became a doctor.
    • He got angry.
    • My son is growing tall.
    • His dream came true.
  • 〜に見える: seem appear look
    • She looks young.
  • 〜のにおいがする: smell
    • This tea smells good.
  • 〜の味がする: taste
    • This dish tastes sour.
  • 〜に聞こえる: sound
    • It sounds strange.
  • 〜と感じる: feel
    • I feel sad.
  • 〜のままである: keep remain
    • I kept quiet.
    • He remained silent.

第５文型: 主語(S) + 動詞(V) + 目的語(O) + 補語(C)

• 目的語 + 補語の関係が、主語 + 述語になる
  • I call [him Tom]. は[He is Tom]の関係
• 第５文型の動詞
  • 〜を…にする
    • He made us huppy.
    • We chose her captain.
  • 〜を…と呼ぶ
    • He calls me Micky.
  • 〜に…するように要求する
    • I want you to go there.
    • I asked him to do this.
  • 〜を…にしておく
    • Keep your room clean.
    • Don't leave the windows open.
  • 〜が…だと思う
    • I believe my son honest.
    • I found the book interesting.
  • 〜を…させる
    • My joke made him laugh.(強制)
    • I had him repaire my PC.(頼んでしてもらう)
    • He let me use his phone.(望み通り)
    • I got him to repaire my PC.(haveと同じ)※getの場合はtoを付与する
  • 〜が…するのを見る[聞く、感じる]
    • I felt the earth shake.
    • I swa him walking.
    • He heard his name called.

第３文型: 主語(S) + 動詞(V) + 目的語(O)

• She wrote a latter.
• 他動詞: I played soccer.(第３文型)
• 自動詞: I went to the store.(第１文型)
• 他動詞と自動詞には慣れが必要なので、沢山英文を読む、かつ意識しながら読む
• 間違いやすい他動詞
  • discuss A
  • resemble A
  • approach A
  • attend A
  • mention A
  • marry A
  • reach A
  • answer A
  • enter A
  • obey A

第４文型: 主語(S) + 動詞(V) + 間接目的語(O) + 直接目的語(O)

• He bought me a pen.
• 語順次第で変わる文型
  • 第４文型: 主語 + 動詞 + 人 + 物
  • He bought me a book.
  • 第３文型: 主語 + 動詞 + 物 to/for + 人
  • He bought a book for me.
• to/for/ofの使い分け
  • toを使う動詞: give/ lend/ send/ show/ teach /tell
    • 4: I'll give you a pencil.
    • 3: I'll give a pencil to you.
  • forを使う動詞: buy/ get/ find/ make /cook
    • 4: She made me a cake.
    • 3: She made a cake for me.
  • ofを使う動詞: ask
    • 4: I asked him a quiestion.
    • 3: I asked a quiestion of him.
• 第４と第５の見分け方
  • 第４文型: He bough me a book. [me ≠ a book]
  • 第５文型: We call him Mike. [him = Mike]

第１文型: 1: 主語(S) + 動詞(V)

• There is a park near my school.
• He came to Japan last year.

2018年の目標と2017年の振り返り

ビジネス書を読む方が多く、技術書をあまり読めてなかったので今年はどちらも読む

英語も頑張る

2016振り返り

仕事

• ブログは月5本かけた。目標値＋1だったのでよかった
• 社内活動として、MSP、スタンダード改善、採用改善、クリスタル立ち上げをした。結果マネージャーになった。マネージャーとしてできてないこと沢山あるので2018の目標にする
• 英語は若干進化、道を聞けた、買い物できた、来年はセッション聞けるようになる
• マネージャーになって、心の余裕がなくなり仕事でいっぱいいっぱいな日々が続いた、仕事後の勉強ができない日が続いた
• re:Invent行けた、楽しかった

プライベート

• TOEIC700点 > そもそも受けてない...
• マラソン大会3回参加 > ツール・ド・ちばに出た、来年も出たい、違うレースにしようかな
• 夏目漱石5冊 > 読めてない
• 皿洗いする > ストレス？で晩酌するようになって、年の後半はあまりできなかった
• 家族旅行2回 > 鴨川シーワールド、ハワイアンズ、ユネッサンスなので3回いけた！

2018年の目標

やめること

やりたいこと沢山書いても時間は限られるので、やめることも書く

• ゲーム、スプラトゥーン2やめる
• 毎日の晩酌
• 夜更かし、12時には寝る、夜運動(22:00-00:00)、朝勉強(7:00-9:00)、土日も勉強する
• 風呂でのyoutube、風呂は読書にする、youtubeは自転車乗ってる時にする

仕事

• 技術の習得(python、データベース、セキュリティ、ネットワーク)
• マネージャーとして、一年後、二年後に意味のある施策をやっていく

プライベート

• 毎日勉強する(7:00-9:00)
• 毎日自転車乗る(22:00-23:00)
• 本10冊読む
  • 英語：映画やyoutubeを見て理解できるようになる
  • Python覚える
  • MySQL覚える

【2017年9月】自転車の記録

日付	距離(km)	カロリー(kcal)
2017年9月1日(金)
2017年9月2日(土)
2017年9月3日(日)
2017年9月4日(月)	10	243
2017年9月5日(火)	20	491
2017年9月6日(水)	11	250
2017年9月7日(木)	30	638
2017年9月8日(金)	33	1008
2017年9月9日(土)
2017年9月10日(日)	10	231
2017年9月11日(月)
2017年9月12日(火)
2017年9月13日(水)
2017年9月14日(木)
2017年9月15日(金)
2017年9月16日(土)
2017年9月17日(日)
2017年9月18日(月)	56	1122
2017年9月19日(火)
2017年9月20日(水)
2017年9月21日(木)
2017年9月22日(金)
2017年9月23日(土)
2017年9月24日(日)
2017年9月25日(月)
2017年9月26日(火)
2017年9月27日(水)
2017年9月28日(木)
2017年9月29日(金)
2017年9月30日(土)
合計	170	3983