これまで AWS はほとんど触ったことないし、愛媛松山に特に縁があるわけでもないのだが、友人に誘われたのをきっかけにノリと勢いで愛媛まで足を運んだ。
何気にこれで四国初上陸だったりする。
「クラウドでつながり、今を、明日を変えていく」というテーマのもと、AWS に限定せず「クラウド×地方」が取り上げられていた。 参加者は全部で 170 名ほど。
聴講したセッションのメモ
基調講演：武闘派はコミュニティに生きる。
フジテックのCIO、友岡さんによる3つのお話。
メモ
- 「コミュニティの活動等になぜ参加したら良いか？」を理論武装する
- 弱いつながりの強さ
- 交流頻度が少なく多様性があるのでブリッジが生まれやすい
- c.f. 強いつながり
- 「タバコ部屋」の世界
- 組織として実行するために必要
- 遠いところと弱くつながるように心がける
- 一方で会社内では強いつながりを作る
- スモールワールド現象
- ストラクチャルホール理論
- 結節点（ブローカー）を介してしかやり取りできない状態
- ブローカーは得をする
- H型人材になろう = 2箇所（以上）に軸がある
- 多様性は時間とともに失われる（同質化）
- 同質化のプレッシャー3つ
- 規範的圧力→「やってはいけないとはいってないけど、やったことないからダメ」
- 常識は同質化が生み出した幻想
- ビジネスとしての打ち手
- 常識に従う
- 常識をうまく活用する
- 破壊して塗り替える
- ビジネスとしての打ち手
- 同質化のプレッシャー3つ
- 同一性
- 人間は似たものと交流する
- 誰と付き合うかで自分が変わる
- 人間はそもそも多様性を求めていない
- →会社の中で同質化していることを意識する
- 弱いつながりの強さ
- ダメな情シスに対する処方箋
- 若いエンジニアに贈る言葉
- 好きなこと・できること・やらなければならないこと
- 一致すると幸福
- できることが小さく、やらなければならないことがずれていると不幸せ
- 一致していないときどうするか
- やらなければならないことに集中する
- できることを増やす→誰よりもうまくできるように努力する
- それを、好きになる
- やりたいこと
- それって人よりうまくできるの？
- あなたがやらなければならない理由はあるの？
- PRIDE と BRAND
- PRIDE
- 邪魔になるもの
- 「どれだけ自分が気持いいか」
- BRAND
- 信用の積み重ねでつくられるもの、期待値
- 他人によって作られる
- 頼まれていないことをやっておく
- 「お役に立てる機会が得られた」
- イチローは会ったこともない、何も約束していない人から「ヒットを打つ」ことを期待されている
- PRIDE
- 「働く」4つの発展階層
- Art → Play → Work → Labor
- Wrok
- 自立スペシャリスト
- Play
- プロフェッショナル
- Art
- マイスター
- 必要なのは時間ではない
- Wrok
- Art → Play → Work → Labor
- 好きなこと・できること・やらなければならないこと
所感
「周りの人を誘ったけど来てくれなくてぼっちの人」を勇気づける発表。ぼっち最強。
考え方の切り口として、弱いつながり・強いつながりを活用していきたい。
(香川) 陸と離島の距離を「ゼロ」に！次世代無人物流システム「KAZAMIDORI」実現に向けた取り組み
株式会社かもめや 小野さん
メモ
- 離島大国日本
- ドローンを使った無人物流
- 課題
- 日本特有の面積の狭さ
- 離着陸用地の確保
- 新航空法への対応
- 日本特有の面積の狭さ
- ハイブリッド型（島国モデル）
- 陸海空の組み合わせ
- やっていること
- 全航路の輸送コスト計測
- 輸送ルート最適化・定期航路の設定
- ドローンポートの場所確保
- 山間
- 海よりも難しい→火災など
- 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 特有のノウハウ）
- インフラ・サーバの勉強にならない
- ノウハウ特殊で属人化しがち（Docker 特有のノウハウ）
- beanstalk に載せるのが一番楽
- 環境展開は 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作成入門
株式会社デジタルキューブ オカモトさん
メモ
所感
中身の技術としても、アプリケーションとしても元言語処理の人として興味深い。
(岡山) 週末趣味のAWS ElasticBeanstalk編 その2（仮）
株式会社リゾーム 難波 さん
メモ
- Elastic Beanstalk
- クラウド環境作成・構成管理ツール
- 開発者ガイド（日本語・pdf）
- ボリューム大
- だいたいこれを読めば解決する
- サンプルも豊富
- Application > Environment
- Environment を組み合わせて Application を構築
- Application 内で異なるバージョンの Environment 切り替えられる
- Application 内で異なる機能の Environment
- multi-container docker
- CodeCommit などで構成を管理できる
- multi-container docker を使うときの注意
- オートスケーリング グループ ヘルスチェックタイプ
- EC2 ← デフォルト
- ELB ← こっちのほうが良いのでは？説
- docker プロセスが停止したとき、再起動しない
- docker プロセスが再起動したとき ecs-agentコンテナ再起動しない
- ELB ならよしなに再起動してくれる
- オートスケーリング グループ ヘルスチェックタイプ
所感
開発者ガイド読もうと思った（小並感）。 私自身が AWS の各種サービスに明るくないので詳細まで追い切れなかったが、それでも丁寧な検証とデモを合わせて見やすい・分かりやすい発表だった。
パネルデスカッション クラウドとコミュニティを活用したこれからの働き方
メモ
- サイボウズ「働き方改革に関するお詫び」
- 個々人に合わせた働き方 = 多様性だ
- 一律で与えられるものではない
- 一律に決めたほうが良いかはお仕事の内容による
- エンジニアの仕事は多様なので決められない
- 「同質化」すると変化に弱くなる
- 社長が変化を掲げてもアクセルがかからない
- 優秀な人材を入れるために会社の制度を変えていった
- 外の物差しを入れていった
- エンジニア採用は東京だと難しい→全国から
- 必然があってそうなった
- リモートワーク・副（複）業は信頼がなければ成り立たない
- 一定のスキルセット・人事制度
- 文字ベースのやり取りのガイドライン
- 否定しない
- 叱責しない
- 2回やって伝わらないなら face to face
- リモートワーク・副（複）業は人によって向き不向きがある
- 「仕事をすれば良いんでしょ？」では作業者と同じになってしまう
- 中の人になる、それができないと情報がインプットされない
- 「仕事をすれば良いんでしょ？」では作業者と同じになってしまう
- 会社は最後のコミュニティになっている
- 同質化を回避する
- 世界を拡張する
所感
もし、働き方改革が「働き方の多様性を実現すること」なのであれば、 これは会社側だけでなく、働く人自身も「自分の働き方を他人に強要しない」という変化が必要なのだろう。
また、東京でエンジニアを採用するのは難しくなってきており、優秀な人材を採用するためにリモートワーク・副（複）業という仕組みを取り入れなければならない、という考え方はなるほどな、と思った。
全体所感
今回は内容も開催地域も普段とは全く異なる場所だったので、はじめは「せっかく愛媛まで足を運んだのに、何もわからずに終わるんじゃないだろうか？」という不安もあった。
しかし基調講演にて「ブリッジ」「弱いつながり」「ぼっち最強」の話を聞いて、むしろこれまで全く関わってこなかった領域で「弱いつながり」を作る絶好の機会であると考えた。
今回は
- AWS
- IoT
- 愛媛松山
など、新しいことを知る・触れるきっかけがたくさんあり、「多様性」がキーとなった一日だった。
場所が変われば、考え方も変わるものだなあ、と改めて感じた。
AWS は楽しそうなので、 Lambda あたりから触っていこうと思う。
最後に
運営委員のみなさま、登壇者のみなさま、本当にありがとうございました！
