s平面の左側

左側なので安定してます

JAWS FESTA 中四国 2017 in 愛媛松山 に参加してきた

jawsohenro.doorkeeper.jp

これまで AWS はほとんど触ったことないし、愛媛松山に特に縁があるわけでもないのだが、友人に誘われたのをきっかけにノリと勢いで愛媛まで足を運んだ。

何気にこれで四国初上陸だったりする。

クラウドでつながり、今を、明日を変えていく」というテーマのもと、AWS に限定せず「クラウド×地方」が取り上げられていた。 参加者は全部で 170 名ほど。

聴講したセッションのメモ

基調講演:武闘派はコミュニティに生きる。

フジテックのCIO、友岡さんによる3つのお話。

メモ

  • 「コミュニティの活動等になぜ参加したら良いか?」を理論武装する
    • 弱いつながりの強さ
      • 交流頻度が少なく多様性があるのでブリッジが生まれやすい
        • コミュニティ、SNS
        • イデアを創出するのに必要
      • c.f. 強いつながり
        • 「タバコ部屋」の世界
        • 組織として実行するために必要
      • 遠いところと弱くつながるように心がける
        • 一方で会社内では強いつながりを作る
      • スモールワールド現象
      • ストラクチャルホール理論
        • 結節点(ブローカー)を介してしかやり取りできない状態
        • ブローカーは得をする
        • H型人材になろう = 2箇所(以上)に軸がある
      • 多様性は時間とともに失われる(同質化)
        • 同質化のプレッシャー3つ
          • 規範的圧力→「やってはいけないとはいってないけど、やったことないからダメ」
        • 常識は同質化が生み出した幻想
          • ビジネスとしての打ち手
            • 常識に従う
            • 常識をうまく活用する
            • 破壊して塗り替える
      • 同一性
        • 人間は似たものと交流する
        • 誰と付き合うかで自分が変わる
        • 人間はそもそも多様性を求めていない
        • →会社の中で同質化していることを意識する
  • ダメな情シスに対する処方箋
    • CIOがいないから
      • IT の話が役員会の場でできない
    • 資源依存理論
      • 3つの対抗策
    • 思考のフレームワークを使う
    • 取りうる戦略(思考のフレームワークに基づく)
      • 例1
      • 例2
        • 下位20%に合わせる→上位20%の人が欲しているものは過剰性能
        • 上位20%に合わせる→最新のモノが安い・早い
  • 若いエンジニアに贈る言葉
    • 好きなこと・できること・やらなければならないこと
      • 一致すると幸福
      • できることが小さく、やらなければならないことがずれていると不幸せ
      • 一致していないときどうするか
        • やらなければならないことに集中する
        • できることを増やす→誰よりもうまくできるように努力する
        • それを、好きになる
      • やりたいこと
        • それって人よりうまくできるの?
        • あなたがやらなければならない理由はあるの?
    • PRIDE と BRAND
      • PRIDE
        • 邪魔になるもの
        • 「どれだけ自分が気持いいか」
      • BRAND
        • 信用の積み重ねでつくられるもの、期待値
        • 他人によって作られる
        • 頼まれていないことをやっておく
          • 「お役に立てる機会が得られた」
        • イチローは会ったこともない、何も約束していない人から「ヒットを打つ」ことを期待されている
    • 「働く」4つの発展階層
      • Art → Play → Work → Labor
        • Wrok
        • Play
          • プロフェッショナル
        • Art
          • マイスター
          • 必要なのは時間ではない

所感

「周りの人を誘ったけど来てくれなくてぼっちの人」を勇気づける発表。ぼっち最強。

考え方の切り口として、弱いつながり・強いつながりを活用していきたい。

(香川) 陸と離島の距離を「ゼロ」に!次世代無人物流システム「KAZAMIDORI」実現に向けた取り組み

株式会社かもめや 小野さん

メモ

  • 離島大国日本
    • 6000以上うち 412 が有人
    • 18:00代に最終フェリー
      • 時間外は海上タクシー・漁船・自家用船などで移動
      • 緊急時は防災ヘリ・ドクターヘリ・救急艇
    • 離島・僻地過疎地人口 1000万人
      • 買い物難民 700万人
      • 医薬品のうけとりも大変
      • 人手不足・高コスト
      • 定期航路が現象 2008年100往復→現在5往復
    • 離島では、日本で未来に起こるであろうことが先んじて起こっている
  • ドローンを使った無人物流
    • 課題
      • 日本特有の面積の狭さ
        • 離着陸用地の確保
        • 新航空法への対応
    • ハイブリッド型(島国モデル)
      • 陸海空の組み合わせ
    • やっていること
      • 全航路の輸送コスト計測
      • 輸送ルート最適化・定期航路の設定
      • ドローンポートの場所確保
      • 山間
        • 海よりも難しい→火災など
      • AWS IoT
        • Lambda
        • DynamoDB
        • Cognito
    • プロジェクトサポーター→「かもめーず」で検索

所感

普段関わることの少ない IoT のお話。 これを聞いて「本当に困っている人を助ける」のは IoT のような領域なのかなあ、と感じた。

多くのインターネット上のサービスというのは比較的「恵まれている」人をより豊かにするものだと思う。

どちらが優れている、劣っている、という話ではなく。性質の話として。

(広島) OpsWorksを使ったミニマムDevOps

Wardish合同会社 三戸さん

メモ

  • 社員4人で開発だけでなく運用も回す
  • DevOps
    • できるだけ属人作業を減らす
  • devops のメリットを妨げる(Portability を妨げる)要素
  • 対策
    • 1プロジェクト1環境
    • キッティングツール
    • 環境依存のパラメータ化
  • キッティングツール
    • beanstalk に載せるのが一番楽
      • ライバルがたくさんでてくる
      • フルマネージドだとロックインが怖い
      • 教育が入っているのも大切(フルマネージドだと教えたいことが教えられない)
    • Cloudformation → アプリエンジニアが使うには大変
    • Chef + KitchenCI + BERKSHELF を採用している
      • BERKSHELF 使うために Chef は Ver12 以降を使う
      • KitchenCI → ネット上に古い解説が多い→公開日で絞り込んで検索しよう!
    • BERKSHELF
      • コミュニティレシピは使わない方がいい
    • Docker?
      • ノウハウ特殊で属人化しがち(Docker 特有のノウハウ)
        • インフラ・サーバの勉強にならない
  • 環境展開は Vagrantfile のみ
    • Vagrant の add-in 等はホストでそろえる
  • OpsWorks はリポジトリを指定ディレクトリにデプロイしてくれる
    • Vagrant の sync-folder と相性が良い
    • デプロイ次に色々処理したいときはレシピに書いておく
  • OpsWork
    • CodeCommit に限定しない
    • パラメータはデプロイスクリプトで書き換える方針 → 初心者のミス防止
      • 書き換えるファイルはプロジェクトで方針を決める
    • CloudFormation との役割分担
    • Time-based
      • 製造業→深夜早朝・土日を止めることで、お安く
      • 日曜の早朝だけ動いてバッチを実行する簡易バッチサーバとして
  • どちらかと言うと Ops が Dev に食い込むイメージ
    • 逆はいつまでたっても Dev が終わらないパターン

所感

環境構築の問題とか「あるある」だなあ、と思いながら AWS 等を活用した一つの事例を聞けたので、非常に興味深かった。

(島根) CMS開発者 + データセンターエンジニア = AWSでdevOpsに取り組み始めた

株式会社 ティーエム21 吉岡 さん

メモ

  • 社外(自前のデータセンター)のエンジニアを巻き込んで、運用の質を上げつつ自分たちが開発に集中できる環境をいかにして手に入れたか
  • 自社CMS
    • 行政向け
    • 実際のサイト作成者が作ったCMS
    • アプリケーションを管理と公開で分離
      • DBへのアクセス権限を制御
      • アプリケーションとしてカスタマイズするのは公開側→管理がしやすい
  • 問題点
    • 障害時にApacheのチューニングで対応(アクセス制限など)
    • 共用サーバのため、融通がきかないことが多々ある
  • まずは一部サイトAWS
    • 自分で運用するようになって管理コストが降ってきた→相手を巻き込むように
  • AWS の良さをアピール
    • 「せっかくある技術を使わないのもったいないですよ」
  • CloudFront
    • キャッシュがすごく便利
      • 当初は WAF 目的で導入
      • 管理画面・公開画面で切り分けているので複雑な設定いらない

所感

データセンターを持っている会社の中の人に AWS を勧め、導入していく話。

結果双方(サービスの質も上がって三方)幸せになっているので、このように「ものごとを進める力」というのも大切だなあ、と。

Node.jsとServerless FrameworkではじめるAlexa Skills作成入門

株式会社デジタルキューブ オカモトさん

メモ

  • Amazon Alexa
  • amazon echo
    • Skill = Alexa で使えるアプリ
    • Alexa / Amazon Echo 年内に国内
    • 受話→音声認識→WebAPI→音声変換→発話
    • 音声認識・音声変換は Alexa Skills Kit で完結
      • 言語判定もやってくれる
    • WebAPI を AWS Lambda 等で実装すればよい
    • JSON を受け取って JSON を返す
  • Intent, Slot 引数のような形で渡ってくる
  • sample が優秀

所感

中身の技術としても、アプリケーションとしても元言語処理の人として興味深い。

(岡山) 週末趣味のAWS ElasticBeanstalk編 その2(仮)

株式会社リゾーム 難波 さん

メモ

  • Elastic Beanstalk
    • クラウド環境作成・構成管理ツール
    • 開発者ガイド(日本語・pdf)
      • ボリューム大
      • だいたいこれを読めば解決する
      • サンプルも豊富
  • Application > Environment
    • Environment を組み合わせて Application を構築
    • Application 内で異なるバージョンの Environment 切り替えられる
    • Application 内で異なる機能の Environment
  • multi-container docker
    • EC2
    • Dockerrun.aws.json
    • .ebextensions
      • ファイルの番号順に実行される
  • CodeCommit などで構成を管理できる
  • multi-container docker を使うときの注意
    • オートスケーリング グループ ヘルスチェックタイプ
      • EC2 ← デフォルト
      • ELB ← こっちのほうが良いのでは?説
    • docker プロセスが停止したとき、再起動しない
    • docker プロセスが再起動したとき ecs-agentコンテナ再起動しない
    • ELB ならよしなに再起動してくれる

所感

開発者ガイド読もうと思った(小並感)。 私自身が AWS の各種サービスに明るくないので詳細まで追い切れなかったが、それでも丁寧な検証とデモを合わせて見やすい・分かりやすい発表だった。

パネルデスカッション クラウドとコミュニティを活用したこれからの働き方

  • コガさん DIGITALCUBE
  • クラヌキさん ソニックガーデン
  • 大石さん サーバーワークス
  • 水戸さん サイボウズ

メモ

  • サイボウズ「働き方改革に関するお詫び」
  • 個々人に合わせた働き方 = 多様性だ
    • 一律で与えられるものではない
    • 一律に決めたほうが良いかはお仕事の内容による
      • エンジニアの仕事は多様なので決められない
  • 「同質化」すると変化に弱くなる
    • 社長が変化を掲げてもアクセルがかからない
    • 優秀な人材を入れるために会社の制度を変えていった
      • 外の物差しを入れていった
  • エンジニア採用は東京だと難しい→全国から
    • 必然があってそうなった
  • リモートワーク・副(複)業は信頼がなければ成り立たない
    • 一定のスキルセット・人事制度
  • 文字ベースのやり取りのガイドライン
    • 否定しない
    • 叱責しない
    • 2回やって伝わらないなら face to face
  • リモートワーク・副(複)業は人によって向き不向きがある
    • 「仕事をすれば良いんでしょ?」では作業者と同じになってしまう
      • 中の人になる、それができないと情報がインプットされない
  • 会社は最後のコミュニティになっている
    • 同質化を回避する
    • 世界を拡張する

所感

もし、働き方改革が「働き方の多様性を実現すること」なのであれば、 これは会社側だけでなく、働く人自身も「自分の働き方を他人に強要しない」という変化が必要なのだろう。

また、東京でエンジニアを採用するのは難しくなってきており、優秀な人材を採用するためにリモートワーク・副(複)業という仕組みを取り入れなければならない、という考え方はなるほどな、と思った。

全体所感

今回は内容も開催地域も普段とは全く異なる場所だったので、はじめは「せっかく愛媛まで足を運んだのに、何もわからずに終わるんじゃないだろうか?」という不安もあった。

しかし基調講演にて「ブリッジ」「弱いつながり」「ぼっち最強」の話を聞いて、むしろこれまで全く関わってこなかった領域で「弱いつながり」を作る絶好の機会であると考えた。

今回は

  • AWS
  • IoT
  • 愛媛松山

など、新しいことを知る・触れるきっかけがたくさんあり、「多様性」がキーとなった一日だった。

場所が変われば、考え方も変わるものだなあ、と改めて感じた。

AWS は楽しそうなので、 Lambda あたりから触っていこうと思う。

最後に

運営委員のみなさま、登壇者のみなさま、本当にありがとうございました!

PHP カンファレンス 2017 に参加してきた

9月は業務が忙しかったのでブログの更新が滞っていた(言い訳)ので、久々の更新。

昨日 10月8日、大田区産業プラザ Pio で開催された PHP カンファレンス 2017 に参加してきた。

スピーカーのみなさんがスライド自体分かりやすくまとめてくださっているのと、他の方が詳細をまとめていたりするので、私は私なりの感想やまとめをつらつらと書くだけ。

phpcon.php.gr.jp

聴講したセッション(と所感)

OpenID Connectを通じてWebアプリケーション技術とPHPによる実装を学ぼう

www.youtube.com

(スライドがすぐに見つからなかったので動画を貼った)

ユーザ認証 + 属性情報取得のためのプロトコルである OpenID Connect について。

認証・認可のレイヤーの処理について、結構あやふやなので順を追った具体的な解説が聞けてよかった。

OpenID Connect は初めて知った。

ネイティブは JWT を「ジョット」と発音するらしい。

Serverless FrameworkでAWSフルマネージドなツールをいくつか作って得たアーキテクチャ設計の知見

speakerdeck.com

バズワードっぽい Serverless Architecture, Serverless Framework について。

いわゆる LAMP 構成とはアプローチ・考え方を変える必要がある。

理論だけでなく、実践で得られたノウハウの話が聞けてよかった。

広告配信管理システムを支えるPHP - レガシーシステムからの段階的移行戦略

speakerdeck.com

コードの改善のためにまずは守りを固めよう。コードを自分たちの手に取り戻す。

ちょうど自分たちのプロダクトで目指す次のステップというのがこの辺りにあるんじゃないかと感じ、ためになった。

内容もさることながら、話し方もうまいなあと思ったので参考にしたい。

ここで差がつくエラー処理

niconare.nicovideo.jp

みんな大好き(?)エラー処理について。

try catch だけでなくset_exception_handler とか set_exception_handler とかも含めて、設定の具体的なコードが添えてある。

「必要になったときに見返す」用途の資料としての価値も高い内容になっている。

全体の所感

今年は2回目の参加だったが、個人的に昨年と大きく変わったのは「知り合いが増えた」ということ。

昨年末あたりから「勉強会を開催する」だとか「登壇する」だとかいう活動の中で、新しく人とつながり、その人たちと別の勉強会であったり、というのを繰り返しているうちに(人付き合いが苦手な私としては)それなりに界隈の知り合いというものが増えてきている。

その人達と会場ですれ違って話をしたり、あるいは「この前の勉強会で登壇してた人ですよね?」と話しかけられたり、ということが何度かあった。

そのおかげで、これまでは既に存在するコミュニティに「お邪魔させてもらっている」という感覚だったのが、今回はホームにいる感覚というか、「自分もコミュニティの一部である」という風に感じることができた。

また、その知り合いがスピーカーだったりもして、これまで遠かった世界が一気に近づいた感覚でもある。

これを受けて来年はコンテンツを享受するだけでなく、コンテンツを提供する側に回ってみよう、と思った。

さいごに

この手のイベントが開催されているのも、運営委員の方々の多大な労力・苦心があってのことと思う。

(比べるのもおこがましいのかもしれないが)学生時代に学園祭の運営をやっていた身として、一部だけかもしれないがその苦労を想像することはできる。

なので、改めてこの場で労いと感謝の言葉を述べたいと思う。

スタッフのみなさん、そしてスピーカーのみなさん、本当に、お疲れ様でした。そして、ありがとうございました。

また来年も参加させていただきます!

ISUCON の過去問に挑戦した(ISUCON3 予選問題編)

仲間内でやっている勉強会の一環で、ISUCON の過去問に挑戦した。

今回は ISUCON 3 のオンライン予選問題。

公式で AMI が提供されている。

isucon.net

github.com

今回のルールは下記の通り

PHP 実装でベンチマークを回すと再現性無く FAIL が発生したため、平均ではなく最高スコアとした

私の最終的なスコアは下記の通り。

Result:   SUCCESS 
RawScore: 3772.6
Fails:    6
Score:    3433.1

ISUCON3 予選突破ラインが約 10000 とのことなのでまだまだ。

インフラ・ミドルウェア周りを疎かにしていることがはっきりと結果に反映された。

目次

やったこと

※施策ごとのスコアは記録を取っておらず、記憶に頼って書いているので不正確であることに留意

最終的なソースはこちらにアップしてある。

github.com

初期スコア測定・環境の準備など

とりあえず PHP 実装に切り替えて、ベンチマークを回す。

Result:   SUCCESS 
RawScore: 1864.2
Fails:    4
Score:    1845.5

先述のとおり、PHP実装では再現性なく FAIL が発生してしまう。(この結果も何回か回した上でやっと出た)

その次に作業環境として

  • SSH 接続のために isucon ユーザの鍵を登録
  • PhpStorm のプロジェクトを作成
  • GitHub リポジトリを作成

あたりをやっておく。

index (雰囲気)を貼ったつもりになる

最初にざっくりテーブル定義を確認し、ソースコードを見渡した後に「雰囲気」で index を貼った。

create index memos_user_id_index on memos (user, is_private);

しかしデータ初期化の仕組みを理解しておらず、ベンチマーク時には index が削除されてしまっている状態だったため、スコアは変動せず。

原因に気づいたのは最後の方だった。

PHP のバージョンアップ(に失敗)

ISUCON3 実施当時は PHP 7 などなかったので少しズルい気がするが、使えるものはなんでも使おう。

ということでまず最初に PHP7.1 のインストールを試みる。

# yum remove php*
# wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
# rpm -ivh remi-release-6.rpm
# yum --enablerepo=remi-php71 --disablerepo=amzn-main install php php-mysql php-pecl-memcached

が、 apache2.4 まわりの依存性解決につまずいたので断念。

ここに時間を割きたくなかったので PHP 7.0 で妥協。

# yum remove php*
# yum install php70 php70-mysqlnd php70-pecl-memcached

「今度はうまくいきそう!」とベンチマークを回すも今度は FAIL が多発してスコアが 0 に。

どうやらセッションが保存できていなさそうなことを確認。

いったん元のバージョンに戻す。

memos 取得の order by 指定を created_at から id に変更

色んな所で memos テーブルのレコードを取得する際に created_at カラムで order by していたが、主キーであり auto increment である id を使っても同じやろ!ということで変更。

結構な確信を持ってベンチーマークを回したが、かえってスコアは下がり 1000 を切るようになった。

泣く泣く戻す。

※原因は後ほど

last_accessed の更新をやめる

last_accessed を更新しない · okashoi/isucon3-practice@d33c500 · GitHub

ユーザがログインする都度 last_accessed というカラムの日時を更新していたが、どこにも使われていなかったので更新をやめる。

これで RawScore が 100 ほど改善 (1900)。

PHP7.0 再挑戦(セッション保存先をファイルに変更)

memcached がうまく動かないのでいったん使わないようにしておく · okashoi/isucon3-practice@9648b61 · GitHub

セッションの保存に失敗しているようなので、いったん memcache ではなくファイルに保存するように変更。

これで動くようになった。

PHP7.0 にする前と比べて RawScore が 400 ほど改善 (2300)。

そこまで劇的には変わらなかった。

$older, $newer が見つかったらループを抜ける

と が見つかったら break · okashoi/isucon3-practice@080f712 · GitHub

メモ閲覧画面には、1つ前 ($older)・1つ後 ($newer) のメモへのリンクが存在している。

それを見つけるロジックにて、見つけた後もループし続けていたため、見つけたらループ抜けるように変更。

RawScore が 100 ほど改善 (2400)。

N+1 問題を回避

N+1 を回避 · okashoi/isucon3-practice@76ae871 · GitHub

トップページにて、メモとユーザ名を結びつける部分があからさまに N+1 になっていたので修正。

RawScore が 300 ほど改善 (2700)。

セッションを保存先を Redis に変更

セッションの保存先を Redis に変更 · okashoi/isucon3-practice@ef0ffc3 · GitHub

「memcache がダメなら Redis だ!」という発想で Redis インストール。

sudo yum install --enablerepo=epel install redis
sudo yum install php70-pecl-redis

うまく動いてくれた。

RawScore が 200 ほど改善 (2900)。

view 内のループで preg_split を使っていたので explode に変更

ループで preg_split を使わないようにした · okashoi/isucon3-practice@0b9792e · GitHub

view 内のループの中でメモの1行目を取得するために、贅沢にも preg_split を使っていた。

正規表現を使った処理は重いので、文字列処理である explode (と trim) に変更。

シンプルだが、意外と効いて RawScore が 400 ほど改善 (3300)。

MySQL のクエリキャッシュ設定

デフォルトでクエリキャッシュは効かないようになっているため、効くように設定。

[mysqld]
query_cache_limit=1M
query_cache_min_res_unit=4k
query_cache_size=256M
query_cache_type=1

これで RawScore が 300 ほど改善 (3600)。

※ ただしあくまでクエリキャッシュであるため、本番の ISUCON では使い所が難しいとのこと。強いてやるとしたら、 init のタイミングで沢山実行されそうなクエリを予め実行しておく、など。これも init の時間制限があるの積極的には利用し難い。

改めて、index(雰囲気)

インデックス貼った · okashoi/isucon3-practice@373b2b3 · GitHub

データ初期化の仕組みを理解して、改めて冒頭の雰囲気 index を設定。

RawScore が 200 ほど改善 (3800)。

マシンを再起動し動作確認

残り時間 15 分を切ったあたりでマシンを再起動し、ベンチマークが問題なく回るか確認。

httpd が立ち上がらないようになっていたので、設定。確認してよかった。

そして競技時間終了。

反省・感想など

終わった後は、解説記事を読みつつ反省会。

isucon.net

スコアと作業の記録を結びつける

慣れているメンバーは作業ログを次のようにして残していた。

  • ミドルウェアの設定ファイルも Git 管理下に置き、シンボリックリンクを張るようにして一元管理する
  • 作業を Pull Request にすることで、Pull Request のページがそのまま作業ログのページになる
  • Pull Request のコメントとして、その時点のベンチマーク結果を貼る

これは「何をやったら、どれくらいスコアが上がった」が見えるようになるので、振り返りもしやすく、とても良い。

後でブログ記事を書くのも楽だ。

施策に根拠を持つ

今回はなんとなく「この辺かな?」というところを手当たり次第触った感じだった。

これでは施策の優先順位付けや、「つまずいたときに『いつ』見切りをつけるか」という判断ができなくなる。

とくに SQL まわりはお粗末な対応だったのできちんと slowlog を見たり、explain の結果を見たりした上で施策を考えなきゃな、と痛感した。

「memos 取得の order by 指定を created_at から id に変更」の施策の効果が出なかったのは、クエリの where 句にて is_private を指定していたため。

is_private, created_at の複合 index を貼るのが正しい対応で、他の参加メンバーはみんなきちんとこれをやっていた。

普段の業務とは違うアプローチを身につける

普段の私が業務で扱うシステムは高負荷状態になったり、極端にスピードが求められることが無い。

どちらかと言えば運用保守のし易さや、データの健全性を優先することが多く、考え方もガチガチに正規化テーブルに立脚されたものになりがちである。

上記の解説記事ではテーブルの非正規化によってスコアを改善していく部分(public_memos, public_count テーブルの追加、memos.title カラムの追加等)があるので、こういったスピード優先のアプローチを身に付けたい。

デフォルトの構成を決める

一緒に参加していた勉強会メンバー曰く、デフォルの構成を決めてしまい「いつも通りに作業ができる」土俵に持ち込むのが良い、とのこと。

勉強会メンバーではスキルセット的に PHP7.1 + nginx + php-fpm + MySQL5.6 という構成が良さそう、という話で落ち着いた。

ただ、例年の ISUCON を見るに PHP はやや不遇な扱いを受けているような気がしており「第二の選択肢は準備しておきたいよね」という話にもなった。

「身に付けたいスキル」という観点も含めて「言語としては Go あたりかな〜」という話をした。

まとめ

単独で ISUCON の問題に挑戦するのは今回が初めてだった。

いろいろ勉強になり、自身の課題もたくさん見えてきたので ISUCON に取り組むことは非常にいいことだと思う。

1人だとなかなか「やろう!」という気にならないが、人と一緒ならやる気になるので今のメンバーがいることに感謝。