4/12(水)、AWS Black Belt Online Seminar Amazon VPC 受講レポート
4/11(火) AWS Black Belt Online Seminar 初心者向けクラウドコンピューティングはじめの一歩 受講レポート
はじめに
Amazonが配信している「AWS Black Belt Online Seminar 初心者向けクラウドコンピューティングはじめの一歩」を受講しました。以下受講メモ。
メモ
初心者向けクラウドコンピューティング
- 初心者向け、新卒向け
クラウドとは
- 形のないもの
- 実体は分からないけど使いたいサービスが使い時に使用できる
- 必要な時に、必要なだけ、低価格で利用
- 既存インフラ
- 初期投資が発生
- 余剰・不足のリスク
- 固定費
- クラウド
- 初期投資が不要
- 必要な分だけ利用
- 変動費
- クラウドコンピューティング利用は年々増加傾向
- クラウドの利点
- 余剰リソースをさけることができる
- リソース不足による機会損失を避けることができる
- クラウドの特徴
- セルフサービス
- 迅速展開インフラ
- 低額な利用価格
- 実際の使用分のみ支払い
- 初期投資が不要
- スケールアップ・ダウンが容易
- ビジネススピードの改善
アマゾンウェブサービスのなりたち
- Amazonのビジネス
- E-Commerce
- マーケットプレイス(物流サービスの提供)
- クラウドコンピューティング
- Amazonの元々持つ既存インフラをサービス化して対応
- ビジネス拡大スピード：12年間で20倍
- 2016年には1017個の新機能をリリース
- 小売業での体験をクラウドサービスでも生かしている
WAWSグローバルインフラストラクチャ
AWSサービス群と活用例
- AWSサービス群：90以上
- 顧客要望から生まれた
- AWSは最も汎用性の高いクラウドの一つ
- 主だったサービス
- 様々なサービスを組み合わせてシステムを構築できる
- Serverless Architecture
- Lambda等
- サーバを立てずにクラウド構築
4/05(水)、AWS Black Belt Online Seminar Amazon EC2 受講レポート
はじめに
Amazonが配信している「AWS Black Belt Online Seminar Amazon EC2」を受講しました。
今の会社ではAWSの知識が必須なので、それまでレガシーなシステムしか触ってこなかったオレは突貫工事でAWSに関する知識を詰め込んでいってるんですけど、意外と社外勉強会の開催がないorタイミングが合わないこともあり、今後積極的にAmazon主催のオンラインセミナーを活用することになりそうです。
以下、受講時に取ったメモ。
メモ
インスタンスタイプ
- 最大1228vCPU 1952GiBメモリ
- 小規模向け
- コア性能重視
- バランスタイプ
- メモリ重視
- 新しいインスタンスタイプを年々追加
- インスタンスとHOstの違い
- アフィニティ：同じところで起動し続ける
ストレージ
- EC2インスタンスストア
- ホストコンピューターに内蔵されたディスク
- EC2を停止→起動するとクリアされる
- I/Oは早い
- Amazon Elastic Block store
- データ永続性
- 追加利用料金が発生
- インスタンスストア
- EBS
- EC2にアタッチされるストレージ
- EC2から独立
- 他のEC2に付け替え可能
- ネットワーク越しにアタッチ
- EBS専用回線(ストレージエリアネットワーク)を用意することも可能
ネットワークとセキュリティ
- セキュリティグループ
- アクセスルールをひとまとめにしたグループ
- AWS上でのIPの種類
- Elasticc Network Interface(ENI)
- VPC上で実現する仮想ネットワークインターフェース
- 拡張ネットワーキング(Enhanced Networking)
- ネットワークI/Oが必要な場合に活用するサービス
- スイッチを通さず直接NICにアクセスできる
- Placemnet Group
- node間通信が大量発生する場合に有効
- ペネトレーションテスト
- SMTP送信
- 申請が必要
感想
EC2はたぶんAWSの中で一番有名かつ一般的なサービスだと思うんですが、実はオレはまだちゃんと使用したことがありません(略式には無いこともない)。今回のオンラインセミナーでは、ハンズオンと違い手を動かすようなことはないので、あくまでEC2というサービスの紹介にとどまる内容なんですが、それでも網羅的に提供サービスを把握できたのはありがたいです。要は既存のレンタルサーバっぽいものだということなので、そういう意味ではこれまでの開発経験が最も活かせるところでもあるとは思っています。まずは無料枠で触ってみるところからかな。
途中音声トラブルがあってオンラインセミナーが一時中断したんですが、オレが受講したネットワーク環境は妙にネット接続が悪いことがあるので、こちらとあちら、どちらに問題があるのか分からずちょっと焦りました。まぁこういうのはオンラインセミナーならではのトラブルですね。
AWS API GatewayでPOSTリクエストの配列を扱えるようにする
ここ最近仕事でずっと悩んでたのが、昨晩やっと解決したので、備忘録的にメモメモ。
クライアントからAWS API Gatewayを経由して AWS Lambdaで処理を行うAPIを開発しているんですが、LambdaはJSONデータしか扱えません。一方クライアントからは通常のHTTPS POSTでリクエストが送信されます。この場合、API Gatewayの統合リクエストにあるマッピングテンプレートでJSONデータに変換してあげる必要があります。このマッピングテンプレートは「Velocityテンプレート言語(VTL)」で記述するのですが、これがイマイチ情報が少なくて書き方が分からない！
1. API Gatewayで作成したAPIから「リソース」を選択
2. 「メソッド(「GET」とか「POST」とか。今回は「POST」)」を選択
3. 「統合リクエスト」をクリック
4. 「本文マッピングテンプレート」をクリック
5. 「マッピングテンプレートの追加」をクリックして「Content-Type」に「application/x-www-form-urlencoded」を追加
6. 追加した「Content-Type」をクリックしてマッピングテンプレートを記述
- key1[]=value1
- key1[]=value2
- key2=value3
- key3=value4
- key4[]=value5
- key4[]=value6
- key4[]=value7
こういうデータが
key1=value1&key1=value2&key2=value3&key3=value4&key4=value5&key4=value6&key4[]=value7
{
"key1" : ["value1", "value2"],
"key2" : "value3",
"key3" : "value4",
"key4" : ["value5", "value6", "value7"]
}
こう変換したいんですね。
POSTリクエストをJSONに変換するサンプルはネットでも割と簡単に見つかるんですが、配列まで扱ったサンプルはまず見つからないんですよね。配列を適切に変換しないとこんな風になっちゃいます。
{
"key1[]" : "value2",
"key2" : "value3",
"key3" : "value4",
"key4[]" : "value7"
}
配列のkeyに「[]」が混入してしまう他、同じkeyだと後勝ちでデータ上書きされるので、配列の中で一番最後に入っている値しか残らない。ふぁっく！
で、結論から言うと以下のようになりました。
{
"headers" : {
#foreach( $key in $input.params().header.keySet() )
"$key" : "$input.params().header.get($key)"#if( $foreach.hasNext ),#end
#end
},
"queryParameters" : {
#set( $tmpstr = $input.path('$') )
#set( $arraykeyvalue = {} )#foreach( $keyandvaluestr in $tmpstr.split( '&' ) )
#set( $keyandvaluearray = $keyandvaluestr.split( '=' ) )#if( $keyandvaluearray[0].indexOf('[]') > 0)
#set($arraykey = $keyandvaluearray[0].substring(0, $keyandvaluearray[0].indexOf('[]') ))
#set($arrayvalue = [])
#if($arraykeyvalue.containsKey($arraykey))
#set($arrayvalue = $arraykeyvalue.get($arraykey))
#end
#set($dev_null = $arrayvalue.add($keyandvaluearray[1]))
#set($dev_null = $arraykeyvalue.put($arraykey, $keyandvaluearray[1]) )
#elseif( $keyandvaluearray[0].indexOf('%5B%5D') > 0)
#set($arraykey = $keyandvaluearray[0].substring(0, $keyandvaluearray[0].indexOf('%5B%5D') ))
#set($arrayvalue = [])
#if($arraykeyvalue.containsKey($arraykey))
#set($arrayvalue = $arraykeyvalue.get($arraykey))
#end
#set($dev_null = $arrayvalue.add($keyandvaluearray[1]))
#set($dev_null = $arraykeyvalue.put($arraykey, $keyandvaluearray[1]) )
#else
"$keyandvaluearray[0]" : "$keyandvaluearray[1]",
#end
#end
#foreach( $key in $arraykeyvalue.keySet())
"$key" : "$arraykeyvalue.get($key)"#if($foreach.hasNext()),#end
#end
},
"stage" : "$context.stage",
"sourceIp" : "$context.identity.sourceIp",
"userAgent" : "$context.identity.userAgent"
}
個人的なキーポイントはこれ！
#set( $arraykeyvalue = {} )
VTLでHashMapを宣言するには「{}」を指定します。(変数名がいいかげんなのは無視してください。) これがVelocityの公式サイトにもAWSの公式サイトにも書いてなくて、散々探した挙句、海外の掲示板で見つけました。たったこれだけのことに2日も使ってしまうとは……。
VTLは割とJavaのメソッドがそのまま使えるので、後はそれほど苦労せずに書けると思います。とはいえAPI Gatewayはエラー原因をちゃんとログ(Cloud Watch)に吐いてくれないので、何か記述に問題があると原因探しは結構大変でした。(スタックトレース吐いてくれてたらどれほど楽だったか……)
余談ですが、bodyの中身は「input.body」でも取れるんですが、POSTリクエストの送信時にbodyが空っぽだと変換時にエラーになります。「$input.path('$') 」と回避できました。
ちなみに参考にさせて頂いたサイトは以下。上記のマッピングテンプレートも、配列の処理以外はほぼ以下のクラメソさんの記事のものを使わせて頂きました。
- API Gateway + Lambda にFormからPOSTする時のマッピングテンプレートを作成しました ｜ Developers.IO
- HTMLフォームからAPIGatewayを使ってAWS LambdaにPOSTする - Qiita
インタビューによる「自分半生記」のススメ
はじめに
週末にインタビューめいたことをやってきました。
相手は社外勉強会つながりの知人。コンサルというかコーチというか、まぁそんなような仕事をされている方なんですが、「最近インプットはしてるんだけど、アウトプットをちゃんとできてない。一回整理してアウトプットしたい。」というようなことをSNSでつぶやいてるのを見かけて「面白そうだからケツひっぱたいて強引にアウトプットさせちゃえ！」とばかりにオレから声をかけ、時間確保してガッツリ根掘り葉掘り聞いて書き出して、アウトプットしてもらうための整理をしてもらおうと試みたわけです。
……「試みた」と表現したのは、つまり、終わらなかったんですよ、インタビューが。結果面白い話は聞けたし、インタビュイーの方にもかなり満足してもらえたので、それはそれで良かったのですが、本題までたどり着けなかったのは非常に残念でした。
なぜ終わらなかったのか？ それは、今回オレが行ったインタビューが、「その人が生まれた時から今日に至るまで、全て話を聞いていったから」です。今回はインタビュイーの方は4x歳で、まぁそれでも2時間くらいで最後まで行けるかな、と見積もっていたんですが、実際にはインタビュイーの方の話があまりに波瀾万丈すぎて一晩中話しても全然時間が足らなかったですね。まぁオレの見積精度が甘いのはいつものことなのでしょうがないか。
とはいえ、一応好評だったんで、今回のインタビューでどんなことをやったのかを書き出してみたいと思います。
ルール
今回行ったようなインタビューは、以下のようなルールに基づいて行いました。
- その人の生まれた時から聞いていく
- 出身地は？
- 家族構成は？
- ご両親の職業は？
- 環境は都市か田舎か？
- etc...
- 人生の節目を意識して聞いていく
- 小学校と中学校はセットで考えてOK
- 高校くらいからその人の選択が見て取れるので、意識して聞いていく
- 部活や趣味、その頃興味を持っていたものなども
- 必ず他者がインタビュイーに質問する形式で聞く
- 意外と自分のこと(≒分かっていること)は端折って喋りがち
- インタビュイーが話したくないことは聞かない
- 脱線上等！ユルいスタンスでインタビューに臨む
- 脱線してもあまり無理に話を戻さない
- その人の「ひととなり」が把握できることのほうが重要
- 細かく聞き過ぎない
- 時間がいくらあっても足らなくなる
- 掘り下げたいポイントがあれば個別にインタビューを行う
なぜ「半生」をインタビューするのか
このインタビュー方法は元々、オレが派遣常駐型のSIerで小さな部署を任されていた時に、自分の部下たちに対して行っていたものです。
その会社では四半期〜半年に一度、自社に戻ってきて部下たちと面談することが各部署の上長に義務付けられていました。それが無くとも、必ず年に一度は人事評価を行う必要があります。
ところが部下たちと顔をあわせるのはせいぜい月一回程度。これで「人となり」を把握するのはどだい無理ですし、人事評価を行うのも困難です。人事評価に関しては結局「営業から伝え聞いた現場の評判」に頼らざるを得ないのですが、元々大した情報が期待できないうえに伝聞の情報です。はっきり言ってお話にならない。さらに言えば、人事評価も含め、部下の育成責任も背負わなくてはならないのです。現状の能力評価も正しくできない、「人となり」も把握できてない。こんな状態で部署の上長としての責務を全うできますか？出来る奴がいたら、そいつは予言者かイタコです。IT業界なんかにいないで芸能界進出でも考えた方がよっぽど稼げます。
というわけで、予言者でもイタコでもない凡庸たるオレが取った手段は、部下が自分の部署に就いた一番最初の面談で、それまでの人生含め様々なことを根掘り葉掘り聞いて、その部下の「人となり」をザックリとでも把握する、というものでした。それぞれ部下一人一人から半生に相当するものを聞き、その上で会社の方針や部署の方針、人事評価の方法、今後どういう方向に進みたいか、といった一般的な評価面談の内容を改めて話すようにしていました。
これをやるとメッチャクチャ時間がかかります。一人あたりの面談時間が2時間なんてのはザラ、場合によっては3時間やってそれでも足らずに居酒屋に移動して延長戦突入、なんてのもありました。
でもその甲斐もあって、オレの部署は(成果はともかくとして)当時社内で一番活気があって面白いチームでしたし、週末に勉強会なんかを頻繁にやっていたこともあってか、その取り組みが評価されて、リーマンショックで社内全員一律ボーナスカットなんて事態でも、オレのチームだけは全員ボーナスが出た、なんてこともありました。
その辺の取り組みは以前発表したことがあるので、興味があれば以下のスライドをご覧いただければと思います。
これは
- チームが同じ場所で働いていない(多くて月一程度しか顔を合わさない)
- 部下の人事評価と育成を行う義務がある
という特殊状況下で否応なく迫られて行ったことでした。
しかし、今回異なるシチュエーション(他者の能力の棚卸の実施)でインタビューを行う場合にも、割と悪くない手法なんじゃないかと思い、今回は採用しました。
以下は故：スティーブ・ジョブズ氏の有名なスピーチです。このスピーチで個人的に一番大事だと思っているのは、スクリーンショットを貼付した以下の部分です。
スティーブ・ジョブス スタンフォード大学卒業式辞 日本語字幕版
https://www.youtube.com/watch?v=XQB3H6I8t_4
この箇所については「物事はいつか何かしらつながっていくから、将来それが役に立つ・立たないに関わらず、今自分が興味のあることに全力を注ぐべきだ」「役立てるための点と点とをつなぐ努力は後でやれ」とオレは理解しています。過去に起こったこと、体験したこと、学んだことは、大なり小なり何かしら今の自分に影響しているはず。
例えば、オレは漫画が好きですが、その遠因は
- 叔母が漫画家だったこと
- その影響で彼女の生家でもあるオレの実家には、彼女の残していった漫画があふれかえっていたこと
- 母が元々漫画やアニメが好きで、子供たちからそれを隠したり遠ざけたりしなかったこと
が考えられます。その結果として、
- 親がTVゲームにも理解があり、小中高と楽しくゲームで遊べる環境にあった
- ゲームクリエイターになりたくて専門学校に入る(大学に入るよりも近道に感じた)
- 元々進学校の出身だったこともあって、そうではない学生向きの授業……特にプログラミングで全く苦労しなかった
- 「これだったら独習で十分だな。それよりは教わらないとできないものを学校で教えてもらった方が良さそうだ」とゲーム科からCG科に転科
- CG科で教わったWeb・HTMLが面白くなり、そちら側に進路を変更
- アルバイトで入った光通信系のホームページ作成会社で、自分にデザインのセンスがまるで無いことを思い知る
- Webの知識があり、PhotoshopやIllustratorも使えることから、Web系業務システムエンジニアに転身
という道をオレはたどりました。一見すると無軌道な人生にも見えますが、源流に叔母と母の影響で漫画好きだったこと鑑みると、それなりに筋が通っているようにも見えます。
このように、今の自分が、過去の何に影響されているかは、意外に今だけ見ていると分かりづらいです。また、分かり易く役立つものだけがつながりになっているとも限らないです。スティーブ・ジョブズの言う「後から振り返って点を点を繋ぐ」のには、洗いざらい過去を漁ってみて、全部平らにして並べてみた方が、より効果的だとオレは思います。
時間がかかる作業ですし、協力者(インタビュアー)も必要です。やれば必ず成果が出ることは約束出来ませんが、少なくともオレに関してはこれまではそれなりに手ごたえを得ることができていました。仕事や進路で悩んだ時、自分の棚卸が必要になった際には、ぜひ一度試してみて頂ければと思います。
余談
今回インタビューを行うにあたり利用した店はこちらでした。カウンターメインの店で店員さんが頻繁に話しかけてきてくれるので、一人でも行きやすいんじゃないかと。「アキバで女の子がサービスする店」というイメージを良い意味で裏切られ、料理もお酒も大変美味しかったです。また、我々のインタビューの内容にイイカンジでツッコミをくれたのも面白かったですね。話に夢中になってて肝心の寿司を食い忘れたので、またいづれリベンジしたいです。
日常に+１して深堀りする
どーも、一度は物語をちゃんと書いてみたいと思ってるワナビーなタキガワです。一度も書くのにチャレンジできてないから、ワナビーにさえなれてない、が表現として正しいのか。
オレは周囲の人間にはアニメオタクっぽく思われてるようですが、実際には殆どアニメを観てないです。1クールに1作品見ていれば多い方でしょうか。昔はもうちょい見てた気もしますが、最近深夜アニメも観なくなったのは……飲んで帰ってくることが多すぎてテレビ観ずに寝落ちしちゃうからでしょうな。良い子と良い大人はお酒の飲み過ぎには注意しましょう。
そんなオレが今クールは珍しく2作品を追っかけてました。1つは今話題の「けものフレンズ」、もう1つが「亜人ちゃんは語りたい」です。前者は話題だからというのが見始めた理由ですが、後者は妹が録画してたのに付き合って観てた感じです。とはいえ、オレが苦手な作品は、妹はオレが不在の時に観てくれるので、付き合って観てるうちにオレもハマった、が表現として適切かもしれません。
kemono-friends.jp
demichan.com
そしてもう1作品。先ほどニコニコ生放送のタイムシフト視聴で一挙全話放送で「ふらいんぐうぃっち」を一気に観ました。いやぁ、面白かった。
横浜で生まれ育った新米魔女の女の子が、高校進学を機に青森の親戚の家に居候しながら修行をする、というのが主なあらすじ。魔女や魔法使いというとハリーポッターさながらの非日常なファンタジーの世界を思い浮かべるかもしれませんが、この作品ではそういった派手な演出は抑えられており、魔女が自然との親和性を大切にする、という設定のもと、自然の多い青森での生活を丁寧に描いた、いわゆる日常系な内容になっています。
www.vap.co.jp
live.nicovideo.jp
「亜人ちゃんは語りたい」と「ふらいんぐうぃっち」はとてもよく似ていると、作品を視聴していて感じました。どちらも日常系だからであり、どちらも既存の架空のものをちょっとだけ足している。「ふらいんぐうぃっち」は「魔女」で、「亜人ちゃんは語りたい」は亜人(吸血鬼、デュラハン、雪女、サキュパス)。足した要素を丁寧に丁寧に掘り下げ、同じように日常(≒現実)を丁寧に描写することで、日常を破綻させないようにしています。
その辺の最たるが「シン・ゴジラ」なんですが、こちらは追加した要素が苛烈すぎて、日常が破綻しちゃうというか破綻せざるをえないのが、前述の2作品と異なるところかもしれません。(数話しか見たことないんで自信ないけど、東京喰種も同系統かも)
オレは週刊少年ジャンプを読み、スタジオジブリ映画を観て育ったせいか、どうも物語を作る、というと、とんでもない大スペクタクルな話を作らなくてはいけない、他人が絶対に思いつかないような話にしないといけない、と物凄く大仰に構えていたような気がします。
でもそうではなく、既存のファンタジー要素をちょっとだけ目の前の現実に足して、それを丁寧に深堀りしていくことで、今までにない新しい作品を作ることができるんだなぁ、と、これらの作品に教えられた気がします。まぁその「丁寧に深堀り」が大変な作業でセンスを伴うものなのは、言うまでもありませんが。
明日からはもうちょっとだけ日常と丁寧に向き合ってみようと思います。その中で「＋１」できる何かを見つけることができたら、オレもワナビー未満から卒業できるのかもしれませんね。
社外勉強会の登壇者や有名人を過剰に尊敬してはいけない
昨晩は毎月恒例参加のLeSS Study。「LeSS (Large Scale Scrum)」は大規模開発向けスクラムのことで、この勉強会では、各々持ち回りで原典を翻訳したりその内容についてディスカッションしたり、といった活動を月一で行っています。前回と今回は番外編ということでちょっと主旨が異なり、今回はソーシャルゲームメーカーのアカツキさんから@yunon_physさんが「自社でLeSSっぽいことやってるよ」と事例を紹介してくださいました。LeSS Studyの参加者はSIerだったりサービスやってる会社だったりの開発者が多いこともあって、ゲームメーカーの話はどれも目新しさに満ちており、本当に面白かったです。最終的にLeSSどころかアジャイルやスクラムの話さえそっちのけでゲーム開発の話ばかり質問してしまったのはここだけの話。ぜひまたお話を伺いたいです。
less-study.doorkeeper.jp
hackerslab.aktsk.jp
qiita.com
さて、本記事の本題は、アカツキさんの話でもLeSSやスクラムの話でもなく(大変申し訳ない)、その後の懇親会で出た話。@takaesu0さんの話に感銘を受けたというか、本当にその通りだなぁと思ったのでここでご紹介。とはいえ、タイトルでほぼ完結してしまっているような気もしないでもないですが。
我々がどこかで開催される社外勉強会だったりカンファレンス・セミナーだったりに参加すると、当然「花形」なのは登壇者になります。彼らは往々にして他でも登壇経験があったり、書籍を執筆・翻訳していたり、はてブでホッテントリ取るような記事をいくつか書いていたり、とその日の登壇以前から有名人だったりすることも珍しくありません。
そうすると、そういう場に慣れてない人は、どうしてもそういう「花形」な人たちを尊敬からなのか遠い存在だと思っているのか、遠巻きに見ているだけで質問したり話しかけたりしないことが多いように感じます。日本人はシャイなので、そうなってしまうことは非常に分かります。オレ自身も典型的な人見知りなんで、勉強会に参加して講演だけ聞いて質問もせずに一人寂しく帰る、といったことは過去何度もありました。
でもそれだと、せっかくの勉強会の機会を十分生かし切れたとは言えないんですよね。せっかく情報元が目の前にいるのに、講演聞くだけで帰っちゃうと、家でブログ読んだり動画見たりしてるのと大差なくなっちゃう。会場までわざわざ来たことを考えると、移動時間や交通費の分だけ損してる、と言えなくもないです。もちろん、必ずしもブログや動画中継があるわけではないので、勉強会参加で聴講だけなのは損、と結論付けるのは暴論ですが、でもまぁそれだけで終わっちゃうのはヤッパリ勿体無いかな、と。
社外勉強会の醍醐味は、やはり同じ興味や悩みを持つ人と知り合えて、話ができることだと思うのです。それが登壇者であれ、ちょっとブログやSNSで有名人だからと言っても同じです。オレ自身、何回か勉強会などで登壇したことがあるので分かるのですが、登壇したりブログ書いたりしたからと言って全然凄くないんです。オレ自身、登壇する人たちに対して凄いなぁと憧れのまなざしで遠巻きに眺めていた立場でしたが、あの頃のオレと今のオレに、そんなに大した違いはないです。人はそんなに急に成長したりはしないもんですよ、実績もまた然りです。その自分の経験を他の人に照らし合わせると、今まさに壇上で輝かしい発表をしているあの人も、SNSをにぎわすあの人も、実はオレと大して差がないんじゃないかな、と思えたりするのです。
そして実際そういった人たちとつながって話してみると、勿論凄いのだけれど、基本はやっぱり自分と同じなんだと良くわかります。何かに悩んであがいてもがいて、その結果として掴んだ何かをふとしたきっかけでアウトプットしているに過ぎないんですよね。
昨晩一緒に飲んでいた@takaesu0さんも@iwaoRdさんも、元々はオレにとって雲の上の存在でした。彼らは壇上で、オレは聴講席。それがどこかの勉強会でふとしたきっかけで知り合って、だんだん仲良くなって、気安く話せる・相談できる・飲みに行ける関係になったんです。登壇している側だって悩みは尽きないし、誰かと話したり質問されたりすると、やはり新しい発見がある。そうやって相乗効果で互いに成長できる環境は素晴らしいと思いますし、目の前にそういうチャンスがあるのに逃してしまうのは、やっぱり勿体無いと思うのですよ。
サッカーには「相手をリスペクトし過ぎる」という言葉があります。相手を強者と認めるあまり、警戒しすぎて及び腰になってしまい、普段の自分たちの持ち味が出せない、受け身なってしまう、消極的なプレイに終始してしまうような際に、このような表現を使います。まぁこの言葉を監督が試合終了後インタビューで使うときは、その試合には大体負けてますね。そんな「相手をリスペクトし過ぎる」プレイよりは、相手の胸を借りるつもりで積極的にプレイする、どころか、相手を削るくらいのつもりでプレイする方が姿勢としては正しいとされていますし、監督もサポーターも喜びます。
社外勉強会には勝ち負けも勝ち点3もサポーターも監督も関係ないので、相手を削る(トマホークを投げる)必要は全くないのですが、相手の胸を借りるつもりで積極的に話しかけ質問したりする方が、相手にも喜ばれますし、場も活発になることが多いです。ちょっと有名だろうが偉そうだろが、しょせん相手も自分も同じ井戸の中の蛙。仲良く遠慮なくゲコゲコ鳴き合いましょう。独唱よりは輪唱の方がきっと楽しいと思うんですよね。
オマケ
そうは言っても人見知りだしそんなに簡単に声を掛けられないよ、という人は、以前こんな記事を書いたんで、良かったら読んでみてください。もしかしたら何か参考になるかも。
個人的には、別の……例えばたまたま隣にいた聴講者に話しかけるよりは、登壇者に話しかける方が楽なんじゃないかなと思います。ブログでも講演でも事前に発表してくれている分、何考えているかある程度分かるので、話しかけるきっかけが作りやすいんじゃないかなぁとか思ってたりしてます。
