4/26(水)、「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」参加レポート
はじめに
東京丸の内：株式会社IDOMさんで開催されたGitHub社・クラスメソッド社の合同開催勉強会「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」に参加してきました。以下、聴講メモ。
メモ
開催概要・諸注意
- クラスメソッド：佐々木大輔さん
- How we ship GitHub
- DevOps
- 色んな人が色んな意味で使ってる
- インフラ効率化
- リリース自動化
- ただの何かのツール
- 大事なのは
- 価値を無駄なく遅滞なく届けること！
- 近年起きていること
- アジャイル
- 三角形はさかさまに
- スコープがFix、リソースとタイムを動かす
- →リソースと時間がFix、スコープを動かす
- →世の中の変化の方が早いので
- イテレーティブに開発しましょうね
- コラボレーションがやりやすく
- 中央集権型→分散型へ
- CI
- 必須のプラクティス
- Continuous deliveryy
- 今のDevOpsブームが目指しているところ
- Continuous deployment
- 常に本番にデプロイされている状態
- ここまで行くべき
- 例
- ネットフリックス
- GitHubでは？
- 数十回デプロイ/日
- GitHubberは世界中に散らばっている
- 60%はリモート
- 日本は11人
- 実際にはもうちょっといる
- 米国が明らかに多い
- 米国各地に散らばっている
- 地理的にもタイムゾーン的にもバラバラ
- どうやっているか？
- GitHub Flow
- Guide.github.com
- Masterを
- 常にデプロイ可能な状態に保つ
- 本番とイコールに
- 必ずブランチを作って開発
- 生存サイクルを短く
- 溜め込まずすぐPull Requestを作り、フィードバックをもらう
- Hubotが大活躍
- Pull Requestブランチを各環境にリリース
- 問題ないものだけMasterにリリース(マージ)
- もし現在のMASTERブランチの内容がPull Requestブランチに無い場合は、まずMSTER→Pull Requestにマージ
- もう一度テスト
- Masterにコミット
- Hubot(ChatOps)
- ディスカッション上で重要な役割
- OSSチャットボットの仕組み
- GitHubで一番働いてるのは人間じゃない！
- チャット上で様々なオペレーションを行う
- なぜチャットか
- Shared Console
- 誰がやっても同じ結果が出る
- 他人がやってる様子をチャット上で見て学べる
- いつでもどこでもリモートワーク
- デプロイだけならスマホでもできる
- さすがにコード書くのにはPCが必要
- Pull Requestリリース時に、自分がどこにリリース可能か、教えてくれる
- Deplyment API
- チャットコマンド上で手軽にリリースできる
- 「queue for github」
- プロダクションへのデプロイ待ち状況をHubotが教えてくれる
- 待ちが発生している間は他の人がデプロイはできない
- Deployment confidence
- デプロイしたものが本番環境でどのように動作しているかを確認できる
- 様々な形での支援
- 自動でISSUEを立ててくれる
- etc
- チャットやグラフで確認可能
- 様々なことを全てChatで
- CIのセットアップ
- 営業的な見積
- メンバーの居場所通知
- Google Map確認
- 画像(ランダム)
- GIF画像
- 近くにいる人
- メンバーのプロフィールをhubotが紹介
- 様々なツールを活用
- GitHub
- Hubot
- Slack
- Janky
- Heaven
- Heroku
- gPanel
- sentinel
- etc...
- まとめ
- 市場のニーズはすごいスピードで変わっていってる
- DevOpsは必須
- さらにその先へ
- リモートで非同期に
- ChatOpsは企業をグローバルかつフレキシブルなスタイルに
- AIが絡んでくる？
DevOpsとAWSサービス
- DevOpsとは？
- DevOpsの目的
- ビジネスに使う時間を増やす
- デプロイ：月1回→毎日10回
- 運用者：10人→3人
- -
- CIとは？
- ビルド・テストの自動化
- 小さくたくさん回す
- 継続的デリバリー(CD)とは？
- CIにデプロイまで含む
- 統合テスト
- AWSサービス紹介
- CodeCommit
- CodeBuild
- CodeDeploy
- CodePipeline
- ビルド・テスト・デプロイ・承認などのワークフロー管理
- CodeStart
- ここまでのCodeXXXを使ってCI/CD環境を一発で作成できる
- マイクロサービス
- Lambda
- API Gateway
- ECS
- Dockerオーケストレーション
- ECR
- コンテナレジストリ
- 他色々
- 時間がないので猛ダッシュで
- サービスをどう選ぶ？
- 時間がないので後で見てね♪
- 実装例
- 例1：CI/CD EC2でBlue/Greenデプロイ
- 例2：CI/CD ECS
- まとめ
- 安全に早くたくさんリリース
- ユーザーに提供する価値を増やす
- リリースフローの見える化、自動化
- モニタリング可能に
- 開発者・運用者・経営者、三方良しに！
感想
とりあえず「GitHubすげえな！」と。チャットってあんなに活用できるもんなんですね。正直ビックリしました。
同様にhubot凄い。オレの友人に頻繁に承認欲求を満たすために褒めることを要求してくるメンドクサイ奴がいるんですが、そいつのメンタルも管理してくれねーかな。(冗談ですよ、ジョーダン)
個人的にはお二人目の千葉さんの発表はかなり参考になりました。ちょうどAWS使い始めたばかりだというのもあり、サービス概要を把握してなかった、というのもありますが、今すぐ活用できそうなサービスがあったのも個人的には嬉しかったです。早速明日試してみようかｎ……いや、明日はダメだ、見積資料作らないとマズイ。
逆に三人目の中山さんのお話は、そもそも情報量が多かったことと、かなりディープな内容だったこともあって、AWSもGitHub Enterpriseも初心者なオレはあっという間に振り落とされました(笑)。最初の事例くらいまでは理解できたんですけどねぇ、GitHub Enterpriseってそんなに色々やんないと使いにくいモンなのかな？ 全然使い込みが足らないオレには、その辺がいまいちピンと来なかったです。でもまぁ実際にニーズがあってお客さんがあっての事例でしょうから、必要なんだろうなぁ。
それはそれとして、クラメソさんの勉強会って、だいぶ久々(数年ぶり？)に参加しました。Adobe Flexとかの頃にはよく参加させて頂いたんですけど。オレ自身、遅まきながらここ最近になってAWSを触り始めたので、また積極的に参加したいですね。
4/18(火)、AWS Black Belt Online Seminar サーバレスによるアーキテクチャパターンのご紹介 受講レポート
はじめに
Amazonが配信している「AWS Black Belt Online Seminar サーバレスによるアーキテクチャパターンのご紹介」を受講しました。以下受講メモ。
メモ
サーバレスによるアーキテクチャパターン
- AWS Lambdaを中心に
- ベストプラクティス的なもの
What is Serverless?
- おさらい程度
- ユーザーが管理しなければいけないサーバがなくなる
- AWSのサーバレスの場合
- シンプルで使いやすい
- プロビジョニングをしない(できない)
- 処理実行分に対して課金が発生、アイドルタイムに支払いが発生しない
- スケーリングは使用率に合わせて自動で行われる
- 高可用性・組込済み(既にプラットフォーム側で行われている)
- You don't do that, we do that.
サーバレスなアプリケーションモデル
- -
イベントソース
- いっぱい
- S3
- DynnamoDB
- Kiness
- どんどん増え続けている
AWSのサーバレスファリング
- Lambda≠サーバレス
- Lambdaが中心になるのはたしか
アーキテクチャパターン
- ユースケース
- Webアプリ
- バックエンド
- データ処理
- ファイル処理
- ストリーム処理
- IoTバックエンドと似ている
- https://github.com/awslabs/lambda-refarch-streamprocessing
- ETL処理
- 画像認識
- チャットボット
- AI
- 自動化
ベストプラクティス
- The Twelve-Factor App
- モダンなWebアプリ開発のための方法論
- 元はHerokuエンジニアが公開
- コードベース
- バージョン管理された1つのコードベースと複数のデプロイ
- 依存関係
- 明示的に宣言して分離する
- 暗黙的に依存しない
- 設定
- バックエンドサービス
- アプリケーションがネットワーク越しで利用するようなサービスは全て外部サービスとして扱う
- ビルド・リリース・ラン
- 3つのステージを厳密に分離する
- プロセス
- ステートレスなプロセスとして実行
- ポートバインディング
- アプリ自体がリクエストを待ち受けた方がよい
- 並行性
- プロセスモデルによってスケールアウトする
- 廃棄容易性
- 高速な起動と簡単な廃棄
- 開発/本番一致
- 各環境をできるだけ一致させた状態を保つ
- ログ
- ログ管理をアプリ自身で行わない
- 管理プロセス
- 管理タスクを1回限りの実行プロセスとする
その他の(Lambda特有の)ベストプラクティス
- メモリ設定
- メモリを増やすとCPUも倍になる
- Lambdaはメモリ使用量と処理時間で課金、メモリを増やすとパフォーマンスも向上する
- 段階的に試して最適化を目指すのが吉
- VPCは必須ではない
- Design for failure
- リトライ
- Dead Letter Queueの活用(非同期の場合)
- 冪等性はコードで確保する必要あり
- Lambdaで保証しているのは最低1回実行すること
- 場合によっては2回以上実行していることも
- コールドスタート
- 安定的なトラフィックが発生している場合、コールドスタートの発生頻度は低い
- コールドスタートは発生するものと思った方がよい
- 遅延が一切許容できないのであれば使用しない方がよい
- ローカル実行について
- Lambdaで使われているAMIは公開されている
- ファンクションんと言ってもただのプログラム
- Contextとイベントを再現する必要がある
- 単なるJSONオブジェクト
コールドスタートを速くする
ローカル実行
- テストドライバ
Q&A
- 後日ブログで
告知
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系業務システムエンジニアに転身
という道をオレはたどりました。一見すると無軌道な人生にも見えますが、源流に叔母と母の影響で漫画好きだったこと鑑みると、それなりに筋が通っているようにも見えます。
このように、今の自分が、過去の何に影響されているかは、意外に今だけ見ていると分かりづらいです。また、分かり易く役立つものだけがつながりになっているとも限らないです。スティーブ・ジョブズの言う「後から振り返って点を点を繋ぐ」のには、洗いざらい過去を漁ってみて、全部平らにして並べてみた方が、より効果的だとオレは思います。
時間がかかる作業ですし、協力者(インタビュアー)も必要です。やれば必ず成果が出ることは約束出来ませんが、少なくともオレに関してはこれまではそれなりに手ごたえを得ることができていました。仕事や進路で悩んだ時、自分の棚卸が必要になった際には、ぜひ一度試してみて頂ければと思います。
余談
今回インタビューを行うにあたり利用した店はこちらでした。カウンターメインの店で店員さんが頻繁に話しかけてきてくれるので、一人でも行きやすいんじゃないかと。「アキバで女の子がサービスする店」というイメージを良い意味で裏切られ、料理もお酒も大変美味しかったです。また、我々のインタビューの内容にイイカンジでツッコミをくれたのも面白かったですね。話に夢中になってて肝心の寿司を食い忘れたので、またいづれリベンジしたいです。
