amareloのブログ(仮)

IT系勉強会で感じた想いや知見をメインに書いていきます。

AWS認定 デベロッパーアソシエイトの試験に出るかもなデモ見せあいっこ(ヤマムギvol.12) 参加レポート

4/7(水)、「AWS認定 デベロッパーアソシエイトの試験に出るかもなデモ見せあいっこ(ヤマムギvol.12)」に参加しました。 デベロッパーアソシエイト(DVA)の受験を検討しているため参考にしたいと思い、楽しみにしていました。

簡単ですが、セッションの内容を書いていきます。

自分の勉強不足のためか、実は途中からついていくのが大変になっていました… そのため、デモ内容が簡単なものになってしまいましたので、抜け漏れがあるかもしれません。ご容赦ください。 資料が公開されたら復習します。

目次

イベントページ

yamamugi.connpass.com

セッション

AWS Secrets Managerをチュートリアル中心に触ってみた 杉山 美鈴さん

デモ内容

  • AWS Secrets Manager は、DB接続情報を格納する。
  • Secrets Managerで以下ライブデモを実施。
    • シークレットの作成と取得。
    • MySQLデータベースに作成したシークレットでアクセス。
  • System Managerのパラメータストアでも似たような使い方ができる。ただし、パラメータストアにはローテート機能がないので、ローテートが必要な場合はSecrets Managerを選ぶべき。

S3を使ったWebサイトホスティング (S3 + CloudFront) 木村 亮さん

デモ内容

  • 書籍の212ページをもとにデモを実施

  • メモ

    • 静的Webサイトホスティングを有効かするとOAIが使用できない
    • エラーページのレスポンス
      • OAIを設定してアクセスする場合、存在しないパスは403を返す仕様。
        • OAIは、cloudFront経由でしかS3にアクセスできないようにする設定。
      • 静的Webサイトホスティングだと404を返す。

S3にて静的ホスティングしているWebページにCognitoでログイン機能をつけてみた 宮崎 翔平さん

資料

speakerdeck.com

内容

  • Cognitoとは

    • ウェブアプリケーションやモバイルアプリケーションの認証、許可、ユーザ管理をサポートしている。
    • ユーザープールとIDプールがある。
    • HTTPSのみサポート。
    • 認証認可をAWSにおまかせできるサービス。
  • デモの構成

    • S3にアクセス
    • Cognitoに登録されているユーザか確認
      • あらかじめユーザープールとIDプールを連携済
    • トークン取得
    • トークンにてAWS認証許可
    • S3からDynamoDBにアクセス
  • ライブデモ

    • ログイン画面に企業ロゴを追加
    • ユーザープール作成
    • IDプールの作成

API Gatewayの基本、認証付きREST APIを作る 小木 悠斗さん

デモ内容

API GatewayとStepFunctionsで非同期のオンラインバッチを作ってみた 伊藤 秀樹さん

デモ内容

  • REST API経由で非同期のバッチ処理をStepFunctionsで実装
  • API GatewayからLambdaを呼び出す。
    • POST処理の場合StepFunctionsで処理を実施。
      • ステータス初期化。
      • Lambdaで3処理実施。
      • DynamoDBに処理結果を書き込む。
    • GETでDynamoDBから処理結果を取得。

Amazon AppSyncでリアルタイムチャットシステム作ってみた 川路 義隆さん

デモ内容

  • 構成
    • Cognito、AppSync、DynamoDBを使用
    • Amplify にて環境構築
    • チャットアプリにログイン

AWS Beanstalkでお手軽Webサイト構築 ハンズラボ/中川 皓紘さん

デモ内容

  • Elastic Beanstalkとは?

    • 簡単にアプリケーション開発環境構築できるサービス
    • CloudFormationとの違い
      • ミドルウェアの設定が不要
      • インフラ環境を簡単に構築=Erastic Beanstalk   - 複雑な環境を構築=CloudFormation
  • デモ

    • Beanstalkで環境作成
  • AWS試験あるある

    • 近場のテストセンターだと、ランクが上になるほど空きが少ない。
    • 日本語が怪しい問題がある。
    • 専門知識系の参考書はほとんどない。
  • まとめ

    • AWS リソースの作成を簡略化できる。
    • 不要になったら、Beanstalkのアプリケーションから一度でリソースを消せる。
    • テストや検証で環境を作りたい場合は便利。
    • CI/CD化した環境を構築することも可能。

S3でセキュアにファイル交換してみる 山崎 遼平さん

資料

speakerdeck.com

デモ内容

  • WinSCPでS3に接続
  • KMSによるS3バケットの暗号化による、Pre-signed URL作成
  • ALBの設定
  • Cognitoのユーザープール設定

全体を通しての感想

皆さん、ライブデモをしながらのLTで凄いとしか言えませんでした(語彙力…)。いつか自分もやってみたいです。

S3とCognitoの登場回数が多かったですが、それだけDVAに深くかかわるところなのかなと思いました。 Cognitoの機能はDVAの試験範囲とのことなので、Cognitoを深堀りしたくなりました。 大変そうだけど、問題の答えを覚えるだけので勉強ではなく、自分で何を作るか考えて触ることが一番理解できて学びになるなぁと改めて思いました。 ソリューションアーキテクトアソシエイトに合格してから1年。AWS認定へのチャレンジが随分と停滞していたけど、DVAにチャレンジしたくなりました!! 4/18のネットワークスペシャリストが終わったら、山下さんの書籍を購入して受験します!

www.amazon.co.jp

ARPとGratious ARPについて(ネットワークスペシャリスト勉強自分メモ)

ネットワークスペシャリスト試験(4/18)まであと3週間。 今更ながらようやく勉強にスイッチが入り、急ピッチで猛勉強を進めています。 ただ書籍読んだり過去問読むだけではなく、改めて勉強になったことを自分メモとして書いていこうと思います。 まずはARPとGratious ARPについて書きます。

目次

参考図書とサイト

参考図書は下記の通りですが、これから自分が書く内容には認識不足があるかもしれません。誤りや不足などありましたらご指摘ください。

ARP(Address Resoluton Protocol)について

ARPとは

ARPの仕組み

  • 送信先ホストのIPアドレスを元に、最初にARP要求をブロードキャストする。
    • 送信元ホストと同セグメントのPCやルータが受信し、該当するホストがMACアドレスを返す。
  • ARP要求を送信したホストは、取得したMACアドレスIPアドレスARPテーブルに数分間キャッシュ(ARPキャッシュ)する。
  • ARP要求を受けたホストも、ARP要求送信元のIPアドレスMACアドレスを一定期間キャッシュする。
    • 毎回同じような通信を送っていたら、無駄なトラフィックが増加するため。
    • こうすることでARPパケットがネットワークの圧迫を防ぐ。
  • 一定期間経過するとARPキャッシュはクリアされる。
    • MACアドレスIPアドレスの関係性が変わっても正しくパケットを送れるようにするため。
      • NICを交換したり、端末を別ネットワークセグメントに移動させた時に通信できるようにするため。

IPアドレスMACアドレスが両方必要な理由

たとえば、ホストAからホストBにデータを送りたい場合で、ホストAのセグメントとホストBのセグメントが違う場合、間にルータが挟まります。 IPアドレスを知っていても違うネットワークセグメントにデータを送るため、目的地に経由するためのルータの位置情報を知るべくMACアドレスが必要となります。

Gratious ARP(GARP)について

GARPとは

なぜGARPが必要?

普通ならば、自分自身のMACアドレスを知っているはずですが、以下の用途で使います。

  • 重複IPアドレスの検知
  • ネットワーク機器の切り替わりが発生した時のARPキャッシュ更新

前者は、自分のIPアドレスが他で使われていないか確認するために使います。

後者は、サーバやスイッチを冗長化して仮想IPアドレスを共有しているネットワーク構成で、 主系から待機系に切り替わった時に使われます。 サーバが切り替わると仮想IPアドレスが変わらなくてもMACアドレスは変わりますので、 ARPキャッシュを更新しないと切り替わり後のサーバに通信できなくなってしまいます。

最後に

書籍を複数冊読むと、片方に書いていてもう片方に書いていないことがあり、相互に補完しながら知識を身に付けられると思いました! 1冊に集中するのも良いですが、同じ内容の本は2冊不要ってことはないですね。今更ながら気づきました。

自分の言葉に置き換えて書くのも大事だと思いました。 まだまだ書籍の内容を基に書いている部分があるものの、自分が理解して人に説明できるようにするための練習になって良いかなと思いました。

次もネスペの勉強で学んだことを書いていこうと思います。

Backlog World 2021 旅 ~Journey~ オンライン 参加レポート

3/13(土)Backlog World 2021 旅 ~Journey~ オンライン に参加しました。

半日に及ぶ大規模なイベントでした。当日にブログ枠に登録しなおして参加しましたが、なかなか書けず遅くなってしまいました… ようやく書けそうなので、レポートを書いていきます。

目次

イベントページ

jbug.connpass.com

アーカイブ

YouTubeに公開されています。

www.youtube.com

セッション概要

ワークスタイル・トランスフォーメーション 株式会社キャスター石倉 秀明さん

資料

speakerdeck.com

概要
コミュニケーション
  • 集合型ワークスタイル(オフィスに集まって同じ時間働くなど)からは分散型ワークスタイル(リモート、時間帯バラバラ、雇用形態様々)に。
  • 多様な人とチームを組む人が当たりまえに。
  • 本人の働き方に関係なく「全員」に仕事の変化は訪れている。
  • コミュニケーションを「いない」人に合わせ、その場にいない人にも「見える」ようにする。同期から非同期に。
  • 相談と雑談は意図しないとできない。意図して増やしていくこと。
  • 業務のやりとりをすべてパブリック(公開)する。
タスク管理、プロジェクト管理
  • ボールはなるべく持たない。
  • ものづくりや思考に時間を割くためには、事務処理やコミュニケーションのボールはさっさと手放す。
マネジメントシフト
  • リーダーの役目は「邪魔しない」こと。多様なメンバーが活躍できる場の創造。
  • 適切な目標設定をすることが評価の10倍大事。
  • 思考と成果のプロセスの見える化を当たり前のようにできるリーダーが必要。
マインドセット
  • 自分が他人を信頼することはできるが、自分が他人から信頼されることは簡単ではない。
    • 基本に忠実にやるべきことに真剣に向き合うこと。
  • 多様性はバラバラであるほど強い。
  • 役割を果たせるひとであれば、多様な価値観や働き方をしている人の方が良い。
  • モチベーションはチームにいる理由は人によって違う。気にしない。
  • 仕事と人格を同一視しない。
感想

もう今までと同じような働き方ではスムーズにいかない、成り立たないことが多いと思います。 今までの働き方、マネジメントの仕方をリセットして変わっていける人が強い人なんだなと思いました。 コミュニケーションをパブリックにし、自分で抱え込まないこと。 ついやりがちですが、考えすぎずに関係者にはもっとオープンでありたいと思いました。

Go To Eatキャンペーンを支えたプロジェクトマネジメント Retty株式会社常松 祐一さん

資料

speakerdeck.com

概要
情報を一か所に集めオープンにする
  • Slackのチャンネル1つで共有
  • 議事録はGoolge Docで1ファイル追記型で
  • 設計資料はスプレッドシート1ファイルに追記
  • 会議はGoogleMeetを使いROM専(聴く専用)もOKにした。気になる人が参加できる。
    • 探すことが簡単、経緯が追いやすい。どんな情報に基づいて意思決定したかが分かりやすい。
初期ミーティングを頻度高く実施
  • 毎日1時間ミーティングを設定
    • 半日、1日でまとめるより、考え直す時間を設けた方が見落としが減ると考えた。
    • 具体的な実装に入る前にユースケースを洗い出し、データの流れとシステムの挙動を十分に話した(企画も営業もCSも)。
プロジェクト全体の進め方を揃える
  • リスクが大きい順に着手した。
  • メディア側開発は利用者の多いスマホWeb・iOSを優先した。
    • キャンペーンが始まった場合に少しずつ対応できるように。
決定はできる限りチームにゆだねる
  • 必要な情報は十分共有・話せているはず。
  • 決定は開発チームと実装担当者に基本委ね、決められないものはエスカレーションしてもらう。
結果
  • スケジュール最優先、要件と仕様が変わり、ステークホルダーの多いプロジェクトで「メンバが自律して動ける仕組みを整備」して対応できた。
  • プロジェクトの学びを組織に蓄積していく動きはこれから。
感想

スピード感もってプロジェクトを進めるには、情報を公開し検索の手間を省くことがホント大事だと思いました。 メンバが仕事をやり易くする、自分たちの判断で動けるようにする、その環境作りが必要だと思いました。 なかなかこれをしない、できない人が多いので、どうにかしたいなぁという思いです。。。

PJメンバーで共有する「プロジェクト憲章」ことはじめ 株式会社サービシンク 名村 晋治さん

資料

www.slideshare.net

概要
自発的に動けない理由
  • 何をしたらいいのかが分からない。
  • どこに必要な情報がないかわからない。
  • 前提条件がなければ「言われたとおりにする」しかやりようがない。
    • 言われた情報が少ないと思い通りの結果にならない。
なぜプロジェクト憲章がいるのか?
  • そもそも何をするのかを共有することが目的。クリエイターは「作業者」ではない
  • 情報共有がプロジェクトの成功の鍵を持つ。
  • 調べている=仕事をしていない時間
  • ディレクターはゼッタイに「プロジェクト憲章」を作ること。
  • また、「作る」ことではなく「使って」こそ意味がある。
情報共有
  • Backlogに集約してBacklogを見ていない人を切る。
  • 見ていないと置いていかれる感を出す。
    • 意義意図の理解すれば、意図的に使い始めて使いこなすようになる。
    • プロジェクトが動き出したらディレクターはハブ
  • 「第三者が探せる」ようにそのために共通のフォーマットやいつもここにあるという場所を作る。
  • 共有することがすべてはプロジェクトのため
バックログWikiテンプレートをおみやげ

感想

クリエイターは「作業者」ではない。同感です。 一作業者としか扱われなければ、それ以上の働きは誰もしない。 メンバーが働きやすくて誇りをもって働けるような環境が必要だと思いました。 wikiテンプレートをおみやげとして公開しているのも、自分だけでなく他者も同じように成功してほしいという 名村さんのオープンマインドの表れなのかなぁと思いました。

Good Project Award 2021

概要
スターフライヤー 石神様 世界初プラネタリウム上映遊覧フライト
  • 顧客に明るい話題でお客様に喜んでもらいたいという想いではじめた。
  • 社内からは無くて逆に「やろう」という声が出た。
  • Backlogを使って社内外のメンバとの情報共有
  • 社員全体で取り組んだことでの成果。
  • これからも航空業界でやったことがないことに挑戦したい。
SOMPOホールディングス株式会社 柴崎様 スマホカメラを使ったレジャー・娯楽サービス産業の従業員向け健康チェック
  • スマホカメラでバイタルチェック
  • メディア露出、社外問い合わせ増、社内で味方が増えた。
  • 発案から1か月程度でPoCスタート
    • ワンスプリントを速く回す。Backlogがその役にたった。
  • 健康経営応援アプリを開発(実証開始)
  • 日本とイスラエル共同のため言語の壁があった。文化を合わせることが大変だった。
大成建設 田辺様 建設プロジェクトデータ管理フレームワークの構築
  • X-grabの開発ではzoomでしかあったことがない人同士でプロジェクトを進めていた。
  • システム連携設計、ユーザーインターフェース、設計レビューなど、すべてCACOOの中で進めた。
  • もう昔のような業務スタイルへは戻れない。
    • 今までより密なコミュニケーションができた。
FUNBEST 矢島ノブ雄様(オシエルズ) 進路漫才プロジェクト
  • 進路漫才プロジェクトとは、高校の出前授業で進路選択のアドバイスをするプロジェクト
    • 子供のすべてを肯定する優しく楽しい進路の授業を。
    • 学区や子供の要望をかなえる即興性のある授業を。

‐ 進路漫才プロジェクトで伝えていること ‐ 視野を広げよう。 - 夢も安定もどっちも取れ! - 社会的価値を創れ! - やりたいことを社会のニーズとリンクさせる。

  • 結果、生徒の自己肯定感が高まり、働く意義を考えるキッカケになった。
  • 今後は教育CSR事業として取り入れてくれる企業を探す。
  • 事務所の垣根を超えて進路漫才を担当できる芸人を増やす。

  • 先生が伝えたいことを芸人を通して刺さってほしい。

  • 会議をブレストではなく芸人が場を盛り上げながらアジェンダを解決していくことを考えている。
別府市役所 別府市システム開発および運用保守業務など12プロジェクト
  • 市役所全体の課題

    • 生産年齢人口の減少による職員数の減少
    • 業務量の増加
    • アナログコミュニケーション
    • 契約先ごとに異なるコミュニケーション方法を統一したい
  • コミュニケーション方法をBacklogに統一した。

    • とりあえずやりましょう。で進めた。
    • Backlogを利用した人が他のプロジェクトで利用する等の広がりの兆しを見せた。  - 進捗が一目瞭然、コミュニケーションが容易に。
      • ナレッジの共有ができてスピードアップにつながった。
      • UXが優れているため、とりあえず使ってみてくれで大丈夫
      • 進捗状況の管理、誰がボールを持っているかがすぐわかる。
      • 契約先でBacklog使っているところも多く、便利な使い方を教えてもらえた。
  • Backlogを導入したことで仕事の効率化できたのは成功体験。

    • 忙しくて大変だーと言っているだけでは変わらない。
    • デジタルを活用して改善していくのは大切。この成功体験を重ねていきたい。
LINE Fukuoka 南方様 混雑情報発信プロジェクト
  • バス・電車の混雑状況をLINEで確認

    • 西鉄とLINE Fukuokaの初プロジェクトにも関わらず、8日間でサービスリリースした。
      • 発見から24時間以内に社内承認にした。
      • インフラ企業としての町のピンチに対する使命感があったため。
  • ローンチまでのコミュニケーション

    • すべてのコミュニケーションはオンラインで実施して、開発からローンチまで一回も顔を合せなかった。
    • 同じ会社のように堅苦しくない爆速コミュニケーション。
  • 結果

    • 全国に先駆けて行った対策が全国で話題に
    • LINEを活用した西鉄グループのDX推進が活発に
  • このプロジェクトの学びを生かして

    • 市民のみなさんの困りごとを解決できるか、そのインパクトを大事にしたい。
    • LINE Fukuokaだけでなく西鉄様も強いオーナーシップを持つこと、それがプロジェクトの成功の秘訣。
    • 西鉄様だけでなく全国にこの取り組みを広げていきたい。
  • これだけ早くプロジェクトを進められた要因は?

    • LINE Fukuokaの職員以前に福岡市民という意識があった。他の市民の方々も同じ不安を持っているため、スピード勘を持って対応した。
    • 西鉄様は企業存続の危機感を持っていた。何とか安全安心を確保したいという想いが速い意思決定につながったと思う。
龍谷大学 熊谷様 UKAWAカレーPJ
  • 地方創生で持続可能な地域の在り方を学ぶ。
  • 獣害対策として害獣に付加価値を
    • ジビエカレー
    • 宇川の風景を想像されるパッケージ
      • 宇川の風景を感じてもらうため。
    • あえてカレーぽくしないことで差別化するため。
  • 資金はクラウドファンディングで調達して目標金額達成した。
  • 販売について

    • 龍谷大学の生協のみで販売
    • 問い合わせ電話対応可能
    • 今後は温泉や道の駅での販売
    • ふるさと納税の返礼品も検討
  • 地域に利益を還元でき宇川の知名度向上して持続可能な地域にしたい。

感想

このセッションでは、6プロジェクトの紹介をされていました。 どれもすばらしいプロジェクトばかりでした。 情報共有の仕方もだけでなく、皆さんプロジェクトにかける熱量が大きいことに感動しました。 その中でも、LINE Fukuoka様と龍谷大学様のプロジェクトは地域をよくしたいという想いが籠ったプロジェクトで、特に興味深く拝聴することができました。

私も地域コミュニティ活動に関わっているため、自分が住んでいる地域をよくしたいという想いがあります。 ツイートもしましたが、やはり私は地域の生活をよりよくするための仕事をしたいのかなぁと思い始めてきました。 このように熱量高くプロジェクトに関わっている方々を見て、早く行動に移す段階に行きたいと思いました。

Backlog × Redmineツール対談 ~プロジェクトマネジメントを民主化しよう~ redmineエバンジェリスト 門屋 浩文さん、株式会社ヌーラボ 河内 一弘さん、株式会社タンバリン 駒田 美沙子さん

概要
それぞれのツールの特徴について
  • Redmine

    • ワークフローで統制を意識した運用が可能。
    • OSSプラグインの開発が活発。
  • Backlog

    • コラボレーション重視
    • 非エンジニアでも親しみやすいUI
    • 感謝の気持ちを伝えやすい
    • 多彩なAPI連携でシステム化
  • 両方共通

    • コミュニティが熱い!
    • 推進する人がいないと定着しづらい。
コミュニティでどんなことをやっている?
  • Redmine
    • Redmineを使ったPM話が中心。
    • 最近はDBの構造など仕組みよりが好きな人も多くなった。
  • JBUG
    • プロジェクトマネジメントについて語り合う
  • 共通
    • プロジェクトマネジメント大事!
プロジェクトマネジメントを民主化しよう
  • プロジェクトマネジメントは偉い人だけのものではない。
  • セルフマネジメントからはじめよう。
  • 現場から盛り上げていくのが大事!
  • Redmineは文化を変えるきっかけになった。
  • 自分に向き合って得手不得手を理解する。
  • ツールに助けてもらうことも必要。
  • チケットが次の判断のきっかけにもなる。
感想

2大プロジェクト管理ツールのコミュニティの代表者間でのトークセッション。 コミュニティイベントならではの試みで、ワクワクしながら聴いていました。 どちらもコミュニティが熱い、それだけ自分たちのツールを好きで推しているからだと思いました。 どちらが良いか悪いかではなく、その場にあったプロジェクトマネジメントを行えるように、その場に合ったツールを使っていけばよい。 そのためにプロジェクトマネジメント民主化、プロジェクトマネジメントをできるようになっていこうと思いました。

顧問弁護士だってBacklogを使いたい! 遠藤 千尋 さん

資料

www.slideshare.net

概要
  • 悩み

    • 課題の進捗が追えない。
    • 最新ファイルがどれだか分からない。
    • ナレッジがたまらない。
    • 1人で寂しい…
  • Backlogを選んだ理由

    • 期限設定・ステータス管理ができる。
    • ファイル一覧機能ができる。
    • 定量化可視化はダッシュボードを使えばわかる。
    • 顧問先企業の方にとっても一覧性があってわかりやすい。
  • 気をつけている点

    • テンプレ化
    • 月の進捗を可視化
    • 定期的な運用見直し
  • 残された課題

    • 課題設定のしにくさは残る。
    • タイムチャージ表との連携ができれば。
    • Wordからの呪縛から逃れたい。
    • まだまだ使いきれていない。
      • JBUGで旅の仲間に入れてほしい。
感想

プロジェクトマネジメントの仲間が欲しいため、というきっかけで登壇した行動力、見習いたいと思いました。 私もやってみたことの登壇はしたことはありますが、自分が勉強中であること、知らないことが多いから教えてほしいという背景をちゃんと伝えていなかったかなぁと思いました。 共感してくれる人も増え、色々な情報が集まりやすくなり、よりスキルアップできるかもしれないと思いました。 とにかくやってみる、ふりかえりをしてさらに工夫する、これに尽きるなぁと思いました。

Backlogでプログラマーに顧客対応をやってもらったら業務改善が進んだ 株式会社インターファクトリー 塩谷 俊介 さん

資料

www.slideshare.net

概要
  • 改善したこと

    • 課題解決のスピードアップ
      • 顧客とPG感に人を介してた時のタイムラグが無くなった。
      • 課題に対する議論のタイミングがはやまった。
        • 関係者が顧客が登録した課題を見て動けるようになった。
    • サポートの負荷軽減
      • 直接PGに担当してもらうことで、サポートが管理する課題数は1/3になった。
    • プログラマーの意識向上
      • 顧客が具体的にイメージ出来る存在になった。
      • 直接感謝されることでモチベーションが上がった。
  • まとめ

    • ツールを活用しよう。
    • 伝える技術をつけよう。
    • 成果を意識しよう。
    • 顧客と良い関係性を築くことに注力しよう。
    • チームの成果を最大化することを意識しよう。
感想

顧客にはプログラマーの人たちを、プログラマーには顧客を見える存在にして、 リスペクトされるようにしたことがとても素晴らしいと思いました。 リスペクトされると、顧客との関係性も成果も良いものになっていき、 チームメンバの働きがいも増えるのかもしれないと思いました。 今後私が責任者になったら心がけたいです。

「越境」〜未来の旅人たちへのメッセージ〜 あまねキャリア工房 沢渡 あまね さん

資料

docs.google.com

時代を超える旅
  • 旧来製造型モデル(統制管理型)では合わなくなってきている。
  • 不確実性が増す時代の今、オープン型(コラボレーション型)に変わっていかないと、勝てなくなってきている。
  • 統制型とオープン型いずれも合理性はあるが、それ一辺倒のやり方は過去の勝ちパターン
  • 部分的にでもオープン型スタイルを取り入れ、新時代の勝ちパターンを探す旅をしよう。
地域を超える旅
  • IT(デジタル)は皆に公平。ITで地域をを超えて同じテーマでファン(共感者)とつながろう。

    • 同じ職種
    • 同じ業種
    • 同じ問題意識
    • 同じ技術
    • 同じライフステージ
  • あなたのテーマは何ですか?

立場を超える旅
  • 経営とITの景色合わせの旅に出よう。
  • 現場のリアルと経営のリアルは違う。ただし、課題は一つにつながっている。
  • 組織の旅の水先案内人、ファシリーダー(ファシリテーター + リーダー)であれ!
さいごに
  • ともに旅する仲間を見つけよう。私たちはその手段を持っている。
  • 半径5m以内から世の中は変えられる。
感想

沢渡さんのセッションは何度も拝聴させていただきましたが、いつも元気をいただけています。 今回のお話の中に出た「あなたのテーマは何ですか?」については、

  • 私が住む地域をよりよくしたい(ITはもちろんだけどそれに限らず)。
    • この活動の中で私のコーヒーを提供できれば…

と考えています。まだまだ具体化できていないので、自分の人生のテーマを探す旅を続けたいと思いました。 ひとまずは、今の職場で困りごとの改善、より良い仕事をできるよう貢献する経験を積みたいと思います。

最後に

セッション全体を通して、パブリック・オープンにしたことで成功した事例が多く、 これからプロジェクトを続けていくには、オープンマインドで進めていくことが望ましいと改めて思いました。 私がリーダーになってプロジェクトを進めることはまだありませんが、 まずは、自分自身が積極的に情報共有するなどオープンになり、私も相手も働きやすい環境を目指したいと思いました。 お互い何か隠されていたり、変に特別扱いされたら不信感を抱きます。そうならないよう、普段の生活から注意したいです。

私はBacklogを会社で使っておらず、個人で入れたものの使いこなせていませんので、使いこなせるようになるためのアイディアを考えてみたくなりました。 良いアイディアが出たら仕事にフィードバックしたいと思いました。

半日にわたりほぼPCの前から離れることなく聴講しました。 終わってから気が抜けたのか、レポートブログの執筆が遅くなってしまいましたが、それだけ引き付けられて満足できました。

運営の皆様、ありがとうございました。そして、お疲れ様でした!!

第1回 ぶろぐの勉強会 参加レポート

3/2 第1回 ぶろぐの勉強会 に参加しましたので、レポートを書きます。

目次

イベントページ

blog-o.connpass.com

セッション概要

ぶろぐの勉強会にようこそ!はじめまして! 山下さん

資料

www.yamamanx.com

概要
  • 検証したこと勉強したことを必ず書くようにしている。
  • 書き出すことで整理をしている。
  • ブログを書くことが仕事の中心。
  • 趣味でつながっていくためのツール。
  • 自分自身が勉強になっている。
  • Stay Writing!

「途中の人」になるために  坂本 雄一さん

資料

※公開されたら追記します。

良いアウトプットをしていくための5つのポイント
1.ちゃんと影響を受ける
  • ふむふむで終わらせるとそのうち忘れる。
  • ちゃんと影響を受けることが重要。ただ、取り入れるものは選んでも良い。
    • 土日でも勉強頑張ってみる。
      • 資格が取れた。
    • 本には好き勝手書き込む。
      • 記憶に残りやすい。過去の自分の思考回路が面白い。
    • だらだらテレビを見そうになったら消す。
      • 本当に興味あることに時間を割ける。
2.途中のものでも見せる
  • 完璧でないものでも途中で見せることが大切。
  • 点数が付くところに出ている人の方がカッコイイ。
  • 10点でも20点でもいいから自分の中から出す。そうしないと点数すらつけてもらえない。
3.他人の批評は控える
4.ゆるく継続する
  • 習慣に頼る。
  • 楽にできないか考える。
  • 間が空いても恥ずかしがらずに再開する。
  • 「ゆるくても続く知の整理術」という本がおすすめ
5.インプットする
  • アウトプットのためのインプットが一番効率が良い。
  • 必要だと思った書籍がよい。
    • 書籍は厳しいチェックを経て出版されている。
    • 体系的にまとまっている。
    • 知識が線でつながる。
まとめ
  • 自分の思うカッコいい人になりたい。

    • カッコいい人とは?
      • やり始めた人、やり続けている人、成し遂げた人
      • やり続けている人、途中の人が一番カッコいい。
  • ブログ含む外部発信は、簡単に途中の人になれる。

    • 検索したら出てくる。
    • 知識が整理される。
    • 自分自身思い出させる。

ブログをしてたらNHK出演につながった話 福村 浩治さん

資料

docs.google.com

エンジニアになった理由
  • 技術力で兄の介護できるのではないかと考えて。
  • 介護分野に特化したのは、両親の高齢化と兄の将来が不安になったため。
ITツールを使って見守りを
  • 自宅にタブレットを配置して、Skypeにより通勤中や業務の合間に見守りを。
  • ネットワークカメラを導入
    • 要介護側は何の操作もする必要がないため上手くいった。
      • 要介護側に負担を強いても定着しない。
      • ボタンを押すだけだとしても、それが難しい人もいる。
ブログをはじめたきっかけ
  • これまでの介護のノウハウを発信するため。
ブログが名刺代わりになることも
  • 介護の話での執筆依頼が来た。
  • ブログを見たNHKの職員から出演依頼が来た。
ブログをしない理由は?
  • 間違ったことを書いたら恥ずかしい。
  • アウトプットすることで何が得なのかわからない。
    • 間違っても良い。間違ったら訂正するだけ。
まとめ
  • 自分のノウハウを共有することで有益なブログを作ろう。

さあ、ブログをはじめよう。どこで?どうやって? トレノケート株式会社 髙山さん

資料

※公開されたら追記します。

ブログ公開先について
Self Install / CMS
  • メリット

    • 自由度がたかい
    • 個人ならば無償で利用可能
    • 有償版ならば日本語サポートあり
    • コンテンツ配信とプログラムを分離可能でセキュア
  • デメリ

    • メンテを含め運用はすべて自己責任
    • 脆弱性対策も必要
    • ブログ書くだけではオーバースペックなことも
WordPress
  • メリット

    • 自由に自分好みのサイトを作れる。
    • デザインテーマが豊富。
    • プラグインによる拡張。
    • 利用者数の多さで情報や関連書式も多い
  • デメリ

    • メンテは自己責任
    • 脆弱性対策
    • プログラムへの攻撃がひどい
    • 動的生成なのでアクセス負荷が大きくなる
Static Site Generator
  • メリット

    • 使い慣れたエディタからそのままデプロイ
    • 静的ファイルを生成するのでセキュリティが高い
  • デメリ

    • 公開サーバ、構築サーバを用意しないといけない。
    • メンテ、運用は自己責任
SaaS(Zenn)
  • メリット

    • 技術系記事とポエム系記事を分けて書ける。
    • 書き溜めた記事を本にできて販売できる。
    • Markdownで書ける。
    • GitHub連携できる。
  • デメリ

    • あまり見当たらない。
    • 技術系とポエム系は運営の判断で入れ替えられる。
    • マサカリが飛んでくるかも
ブログを書くときに気をつけることは?
  • コードを書くとき

    • セキュリティ情報が含まれていないか確認する。
    • ちゃんと動くか確認する。
  • 勉強会について書くとき

    • 写真や資料の公開ルールを確認する。
    • 鮮度が落ちないうちに書く。
まとめ
  • 楽しく続けることが一番!
  • 今ならおススメはZenn。
  • 今日から始めてみよう!

最後に

最近ブログ書いてて良かったと思うことや、書いてて楽しいと思うことが多かったので、今日の勉強会はホントに共感ばかりのでした。

勉強したことをアウトプットしていくことを繰り返したいというと思いで最近はブログ書き続けていますが、 あまり「書かねば」で考えすぎずに「書きたい」で書いていこうと思いました。 私は「書かねば」と変な義務感持つ性格なので、上手く付き合っていこうと思いました。

あと、時間見つけてZennに書いてみよう!

P.S.ブログ公開後、勢いでZenn登録しました!何を書くかはこれから考える!!

JAWS-UG朝会 #18 参加レポート

2/24(水)JAWS-UG朝会 #18 に参加しましたので、レポートを書きます。

#目次

イベントページ

jawsug-asa.connpass.com

セッション

AWS KMSを触る 富松 広太さん

資料

www.slideshare.net

KMS(Key Management Service)の概要
  • CMK
    • owned CMK(AWSが管理、見れない)
    • AWS Managed CMK(AWSが管理、見れる。)
    • Customer managed CMK(利用者が管理)
      • AWSが作成する方法と、自分で作成する方法がある。
    • データキー
KMSとは
  • 鍵を安全に保管してくれるサービス
  • S3、EBSのデータ暗号化、復号化
  • キーローテーション、暗号化鍵の方式を決定
CMKとデータキーの違い
  • データキー:データを暗号、復号化するために利用
  • CMKキー :データキーを暗号、復号化するために利用

    • なぜCMKで直接暗号、復号化しないのか
      • マスターキーをAWS外部に出したくないから。
      • データをAWSに送るのは不便だから。復号処理が一定時間でないのが嫌だから。
  • 暗号、復号化の利用お作法

    • Encrypted data Keyを使い暗号化し、使っても取っておく。
    • Plaintext data Key で暗号化し、使ったら捨てる。
      • エンベローブ暗号化
EC2にEBSをアタッチすると
  • ①暗号化されたデータキーを復号指示
  • ②復号化されたデータキーを取得
  • ③EBSデータを復号化
  • ④利用終了時(EBSデタッチ)に復号化されたデータキーを削除

    • データキーの管理はAWSが裏側でやってくれている。
    • KMSを削除すると即座にEC2の動作に影響はないが、次回EBSアタッチ時にエラーがでるので注意が必要。
    • KMSを削除したら、EC2が起動している間にデータを他の場所に保管する。
キーローテーション
  • キーの実態を入れ替えること。
  • 過去に暗号化したデータでも、キーIDを元に暗号化復号化できる。
  • 世代管理もしているため利用者側に影響はない。
  • AWS管理だと自動利用が可能。
KMS削除
  • KMSを削除して良いか迷ったら、暗号化データが復号できない可能性もある。
    • 一定期間様子見できるのでいきなり削除しないこと。
    • KMS削除は時間差の障害が起こる可能性がある。

Amazon QuickSight導入事例で解説、お蔵入りしないBI導入のポイント 小寺 加奈子さん

資料

www.slideshare.net

BIプロジェクトが失敗しやすいのは?
  • 何のデータをどのように見るのか、目的が不明確。
  • BIシステムをアップデートする予算、計画、体制がない。
  • BIプロジェクトならではの事情
    • 正解が明確ではない。
    • スペシャリストがいない。
    • 使わなくても業務が回ってしまう。
    • 現場の業務が増える。
顧客導入成功(QuickSight)のポイント
  • データを毎日見る業務プロセスと風土作り。
  • ユーザや情報システム部門のセルフサービスに依存しない、ベンダとの継続的な運用支援体制の構築。
  • データを見れる店長を育成した後に、多店舗に全面展開。
  • アンバサダー的人材を育成。
  • データの統廃合とデータ構造の最適化。
まとめ
  • データ活用プロジェクトは、作って終わりにするのでなく、PDCAを回し続ける業務プロセスと実行可能な体制を実現すること。
  • 運用サポートを手厚くし、データ文化を育成すること。

PDCAはホント何においても大事ですね。目的の言語化、導入後の運用体制構築、終わりの定義も大切だと思います。データ分析のファンを作り続けていくことも必要だと思いました。やはり文化作りは大事!!

AWS関連のブログを書いてて山ほど得したこと報告 山下 光洋さん

資料

www.slideshare.net

山下さんのブログ(ヤマムギ)

www.yamamanx.com

人とつながる
  • Redmineについて、学生さんから手順の問い合わせしてSNSでつながった。
  • Cogintoについて、他支部メンバからSNSで感謝の連絡がきた。
ブログ自体が勉強になってる
  • AWSへブログを移行したこと、失敗したこと障害対応について書いて勉強になった。
  • Well-Architected フレームワークのベストプラクティスを試し、理解を深められた。
  • モニタリングの結果から対応して、主要な攻撃について理解を深められた。
仕事で使う
  • ブログに書いた内容をトレーニングで見せることができる。サブドキュメント化できる。
  • コンテンツ化(書籍化)ができる。
  • 理解できていないことの整理ができる。
  • ブログを書くことが必須。
ブログ書くことのメリット
  • 勉強になる。
  • 書くことで整理できて不明点抽出もできる。
  • 人に知ってもらえて人とつながる。
  • 仕事のツールとして活用できる。

ツイートした通り共感しかありません!間違いを書かないように注意する必要はありますが、自分だけでなく誰かの役に立ってると前向きに描き続けたいと改めて思いました。

最後に

朝会後の仕事は気持ちが引き締まりますね! 2ヶ月参加できませんしたが、久々み朝から刺激をいただけました!次回も参加したいです!

次回は、3/24(水)です!

jawsug-asa.connpass.com

BPStudy#162〜アジャイルな組織のつくり方 参加レポート

2/22 BPStudy#162〜アジャイルな組織のつくり方 に参加しましたので、レポートを書きます。

目次

イベントページ

bpstudy.connpass.com

第1部 BPStudyラジオスペシャル〜アジャイルな組織のつくり方

チームを機能させるために、今までで高い効果を感じたアジャイル開発のプラクティス

  • ふりかえりとナレッジを残すことで大抵のことは上手くいく。

    • 過去に失敗した課題がわかるので、前向きな議論ができる。
    • デジタルの上で行動する。あとで検索できるように。
    • 可視化して議論する習慣を。
  • バリューストリームマッピング

    • 組織横断でボトルネックの改善意識が生まれる。
    • 個別最適化から全体最適化に。
    • 人は目先の仕事にとらわれがち。仕事全体を俯瞰して視座を上げることが大事。
    • ルールは作った瞬間に陳腐化する。作った時点では正常に挙動していても、時間が経つと想定外の挙動(バグ)が生じる。
      • 定期的に制度のリファクタリングをすることが大事。
      • 当時は必要だったのものが今必要か見直すこと。
    • value stream mapping を作成する際におススメのデジタルツール
      • ホワイトボード系のツール。縦横無尽に使えるものがいい。
      • 付箋紙系のツール。

書籍に描かれるような現場は多いのか?変われない原因は?

  • 既存の日常業務の重力・バイアスが強いため。それを壊せないと変われない。

    • それを壊すためには、ビジョンを明確に、臨場感のあるゴール、問題に合意する、因果関係を明らかにする。
    • 変化するにはゆとりの時間、考える時間が必要。
    • 余白のマネジメント。余白のための仕組みづくりを。
  • 思考停止、行動停止、1人で何とかしようとしすぎ(させようとしすぎ)

    • 古い価値観に縛られすぎている。
    • ミスすることを責めることで、その人を思考停止と行動停止に追い込む。
      • 1人でなんとかしない、なんとかさせようとしないこと。
    • 問題提起をした人だけに問題を押し付けないこと。
    • モブワークにすることで属人化を防ぐことができる。意見を出しやすくなる。

まとめ

  • 変化を楽しむ。今までと違うことをしてみる。見方を変えてみる(沢渡さん)。

    • 変化を楽しめる人がこれからは強いと思う。
    • 変化を楽しめるファンを増やす。
  • 感謝、共感を口に出して言うことが大事。自信を持たせることが大事(新井さん)。

第2部 LT大会

ここアジャ で紹介されているふりかえりを見てみよう 森一樹さん(@viva_tweet_x)

資料

speakerdeck.com

タイムライン
  • 時系列順、イベント別に出来事を並べる。思いついたところから大まかに。
  • 出来事は事実と感情を合わせて書く。
  • みんなで共有して掘り下げる。

    • チームの共通認識を作ることができる。
感情グラフ
  • 感情の高低をグラフにする。
    • チームの変化や何にモチベーションを感じているかなどを共有できる。
    • チームをメタ認知できる。
    • お互いの相互理解に使える。
チームストーリー(未来)
  • 未来のありたい姿、なりたい姿を共有する。
  • なりたい姿への現在地、そのギャップ、ギャップの打破策、なりたい姿への加速装置を書いて共有する。
    • 未来志向になる。チームの軌道修正がしやすくなる。

最後に

沢渡さんと新井さんのセッションは、2/19のデブサミでも聴講しましたが、2/19のセッションとは少し違ったお話を聴くことができました。

1人で何とかしようとしないで、チームで成果を出して変化を楽しめるようになること、大事だなと思いました。 一担当者だけが問題に対応して他の人は手を出さない文化は不健全ですし、属人化の要因になりかねません。 チームの共通認識を作って未来志向に進んでいけるようになれば、チームみんなで問題を受け止められるようになり、より良い成果を出せるようになると思います。 少なくとも社内のメンバーは敵ではなく味方。共感者を増やし、思考停止に陥らず、身近なところから少しずつ変えていきたいと思いました。

今回も貴重なお話ありがとうございました!!

Developers Summit 2021 参加レポート

2/18、2/19の2日間、Developers Summit 2021 が開催されました。 私は、2/19を休暇にしていたため、2日目のみ聴講しました(1日目も仕事しながら聴きたかったのですが、無理でした…)。 それでも全部聴くことはできなかったため、聴講出来たセッションについてレポートを書きます。

目次

イベントページ

event.shoeisha.jp

セッション概要

デベロッパーからはじめるレガシー組織の景色の変え方~旧ノーマルからニューノーマル

沢渡 あまねさん、新井 剛さん、【モデレーター】近藤 佑子さん

旧ノーマル組織の限界
  • 統制管理型一辺倒の組織(クローズな組織)では限界。
  • 統制管理型、アジャイル型両方の良さを知っている方が、エンジニアとしては強い。
  • 統制管理型は変化に弱い。思考力主体性を奪う。
  • やっていくと慣れるけど思考停止になる。どこかで揺らぎを入れて思考停止を防ぐ。
慣れた不便から解放されよう ~僕たちが見せられる「新しく心地よい」世界
  • 新しいツールを使ってみる。広めてみる。
    • いっしょに操作しながら進めてみると良い。
  • ディベロッパー発のルネサンスを。
半径5m以内の変化のファンを創る
  • 新しいやり方を率先して試し、快感体験と成長体験を創る。
  • すぐに実感できる小さな変化を楽しんでいく。

  • ファンを創るのはブランディングそのもの。3つのファンを創ることが大事。

    • 技術のファン(自分が使っている技術への理解)
    • サービスやプロダクトのファン
    • カルチャーのファン(オープンに議論するカルチャーのファン)
まとめ
  • 過去はどうあれ、未来を創るのが(ニューノーマルを創るのが)エンジニア
  • カスタマーサクセスを創る。オープンになってみんなで未来を変えていこう。
感想

沢渡さんのセッションは何度も参加させていただきましたが、毎回勇気を貰えます。 小さな改善と成功体験を自分も相手も繰り返していく、そうすることで少しずつ改善が改革につながっていく。 改めて、オープンで優しい組織を作れるようになりたいと思いました。

やったもんがち!ニューノーマル時代を生き抜くために、組織の1メンバーであるあなたがDevOpsを促進する方法 横田 紋奈さん

資料

speakerdeck.com

DevOpsとは
  • 顧客に素早く価値を届けるための文化的な姿勢・取り組み。
  • Dev(開発)とOps(運用)が協業する。コラボレーション。
DevOpsで得られるものの例
  • 組織がビジネスが上手くいくことで自社や自分の価値が上がる。
  • 互いのことを考慮し、質の高い成果を出せる。できることが増える。
  • 責めない文化でバトルが減る。
  • 作業の効率化で楽できる。
DevOpsを実践するには
  • ベストプラクティスを取り入れながら改善を繰り返していく。
  • 他と同じである必要はないし、ゴールもない。
  • 改善と議論の繰り返し。
  • 組織の数だけ成功がある。やったもん勝ち!
一人一人がどんな行動をすればよいか?
  • ネガティブな思考、発言では変化を起こせない。また、変化は一人では起こせない。

  • 人に影響を与えるには

    • 話す前から協力してもらえないと決めつけない。同僚を味方ととらえて向き合う。
    • 課題に合った小さく身近なゴールを設定する。ゴールは複数でよいが優先度をつける。
    • 他者が置かれている状況を理解する。
    • 自分を過小評価せず、どんな人も価値を与えることができると認識する。
      • 人に刺激を与える、個人的な関係性など。
    • ギブアンドテイクで影響を与える
      • 価値を与え合うことで周りを巻き込んで成果を出す。
      • 相手に動いてもらうために自分にできることがあると認識することが大切。
  • ゴールを意識できるようになり、行動できるようになった。

    • とにかくコミュニケーションを取り続けた。
    • 長期的な目線も取り入れた価値を生み出そうとした。
  • 「味方」としてコラボレーションしたことで達成感と絆を感じた。
まとめ
  • コラボレーションすべきは開発と運用だけではない。色んなパターンがある。
  • 序盤のステップを大切にして自分自身と向き合うこと。
  • ゴールを決めて方向性を定めていく。
  • できることからはじめていくこと。
感想

自分はネガティブ思考なので、どうしても他人を味方ではなく敵と思ってしまいがち。 でも、それでは自分も相手も成し遂げたいことをうまく進められない。 沢渡さんのセッションでもオープンにとありましたが、自分自身の心もオープンにしないとなぁと思いました。

エンジニアのためのメンタルヘルスマネジメント 鈴木 裕介 さん

ストレス、ストレッサー
  • 身体的症状には気づきづらい。まず身体のサインに気付くのが大事。特に不眠や頭痛には注意。
  • 変化はすべからくストレス。

  • 心理的ストレッサーは3つあり、特にデイリーハッスルズには注意。ドラクエでたとえると毒の沼地。気づいた時には遅いことも…

    • カタストロフィ(社会的不安、生命の危機)
    • ライフイベント(配偶者との離別など)
    • デイリーハッスルズ(面倒な状況、上司の言い方など)
  • ストレッサーには個人差がある。

  • エンジニアに多い因子は「弁別性」。無駄やリターンがないことが嫌いなため、不合理な白黒つかない状況がストレス。
腰痛対策
  • 慢性腰痛とは、作業による前傾姿勢により、背骨の間にあるクッション「髄核」が後ろにはみ出た状態が固定しちゃう状態。

    • 後ろにずれた髄核をこまめに戻す体操をこまめに。
  • 職場での対人関係のストレスが強く出ると、腰痛を感じやすくなる。

    • 腰痛はメンタル疾患でもある。
コーピング
  • ストレスに対応するために意図的に行う「自分助け」の行動。
  • ドラクエの呪文のようにあればあるほどよい。リスト化しておくとよい。
感想

ツイートにも書いた通り、これに尽きるなと思いました。 自己肯定感が低いこともあり、すぐに落ち込んで罪悪感に苛まれるので、ストレス反応に弱いことにも改めて気づきました。 結構メンタルヘルスを害しやすい要因が自分にはそろっているので、うまく自衛しながら過ごせるようになりたいです。

ほんと今までよくメンタルヘルス害せずにやれたものだなぁ。。。危ない危ない(汗)

ニューノーマル時代のコミュニティは誰もがチャンスに満ち溢れている。 中道 一志さん(@ici_mici)

資料

speakerdeck.com

意思を示す。
  • 勉強会に参加して質問したり、参加レポートを書く。
  • 意思を観測可能な形にする。
  • 人前で話すなど意思を表現する。
  • 意思を示すことで共感されたり、視野が広がったりする。スキルアップにもつながる。
  • 意思を示すのに経歴や肩書は関係ない。
  • 自信がないとかは気にしなくていい!
  • 「違い」は価値である。
  • 「制約」は味方を変えると武器になる。
コミュニティの運営
  • ヒトデ型組織を作る。

    • 分散協調型、それぞれが自律的に動きながら協調をもって成り立つ組織。
    • 縦割りにせずその時対応できる人で対応する。
  • ヒトデ型組織を作るには。

    • ビジョン(最重要)

      • ビジョンを明文化する。仲間を集めてからのビジョン定義ではなく、ビジョンをもとに仲間集めする。
      • モチベーションを統一する必要はないが、皆の想いを知ることは非常に重要。
      • 他人のモチベーションをどうにかしようというのが間違い。
    • 鉄のルール

      • 関心を寄せリアクションをする。励まし合う。
      • 各々の立場や状況に関心を持ち、常に決定を尊重する。意見は遠慮なく。
    • 同期と非同期

      • 問題提起と意思決定は同期で行う。情報共有と議論は最小限にする。
        • 初めて出た重要な事柄をその場で決定することはしない。
      • 検討はすべて非同期で。非同期を生かして、会議に参加できない人の意見も取り入れる仕組みを作る。
    • 情報を透明化する。

  • リーダーとして大切なこと

    • みんなを信頼し感謝の意を伝える。
まとめ
  • 日本中があなたの舞台。踏み出す勇気を!
感想

登壇やレポート執筆で意思を示すこと。本当に大事だと思います。 また、表現力や文章力がない、経験値がないなど、制約がある中で挑戦する方が成長するなぁと思いました。 最近では自分も気にせず色々「あ、やります」の気持ちでやってたりします。

コミュニティの運営については、今自分が置かれている立場において、とても参考になるお話でした。 ビジョンの共有、メンバへの関心、感謝、今までの自分はできていたか改めてふりかえりたいと思いました。

コロナ禍でエンジニアイベントはどう変化していくのか? オンライン時代の技術と人との出会い方

モデレーター:仲亀 拓馬さん(@kameneko1004)

登壇者:赤川 朗さん(@Akira_Akagawa)、草間 一人さん(@jacopen)、森川 晃さん(@ariaki4dev)

オンラインイベントについての課題についての議論をmiroを使い、聴講者参加型で行われました。 自分が感じたことは以下の通りです。

  • 登壇してレスポンスが感じづらいと、登壇内容良かったのか悪かったのか、ふりかえりしづらい。
  • アーカイブ残る勉強会だと、登壇の場合はあとでふりかえりしやすい。ブログ書く場合は見返すことができて本当に助かってる。
  • やはり何でかんでイベントに参加した人たちと直接話をしたいなぁって思う。

じっくりと聴いたり、復習しやすくなったという利点がオンラインにはありますので、今はその利点を十分活用したいです。 しかし、オンライン生活慣れたけど、同じ興味や思考を持つ参加者や登壇者と話をしたいという気持ちは残ります。 完全オフラインはまだまだ難しいと思うけど、少しずつでもオフラインとオンラインのハイブリッドや、 規模を縮小したオフラインイベントが開催されると嬉しく思います。

最後に

2日目だけの参加でしたけど、多くの気づきを得られました。 デブサミの登壇者には、表現のしかたは違えど、

  • オープン
  • 他者への共感・関心
  • 感謝
  • 未来思考

を共通して持っている人が多いなぁと思いました。 自分は性格上後ろ向きになったり、自分の表現を躊躇することが多いですが、積極的にオープンマインドでいようと思いました。 また、他者へのリスペクトを忘れず、他者にどんな価値を提供できるか考えて仕事しようと思いました。

初日聴講したかったですが、参加できなかったセッションについては後で資料を読もうと思います。