ミッションたぶんPossible

どこにでもいるシステムエンジニアのなんでもない日記です。たぶん。

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.
AWSのComputeサービス
スケールの単位 抽象化
EC2 インスタンス ハードウェア
ECS アプリケーション OS
Lambda ファンクション ランタイム
サーバレスなアプリケーションモデル
    1. イベントソース(発生源)における状態変化
    2. ファンクション呼出
    • Java
    • C#
    • Node
    • Python
    • カスタムライブラリも利用可能
    1. サービス呼出
    • DynamoDB
  • -
イベントソース
  • いっぱい
    • S3
    • DynnamoDB
    • Kiness
  • どんどん増え続けている
AWSのサーバレスファリング
  • Lambda≠サーバレス
  • Lambdaが中心になるのはたしか
アーキテクチャパターン
ベストプラクティス
  • The Twelve-Factor App
    • モダンなWebアプリ開発のための方法論
    • 元はHerokuエンジニアが公開
      • コードベース
        • バージョン管理された1つのコードベースと複数のデプロイ
      • 依存関係
        • 明示的に宣言して分離する
        • 暗黙的に依存しない
      • 設定
      • バックエンドサービス
        • アプリケーションがネットワーク越しで利用するようなサービスは全て外部サービスとして扱う
      • ビルド・リリース・ラン
        • 3つのステージを厳密に分離する
      • プロセス
        • ステートレスなプロセスとして実行
      • ポートバインディング
        • アプリ自体がリクエストを待ち受けた方がよい
      • 並行性
      • 廃棄容易性
        • 高速な起動と簡単な廃棄
      • 開発/本番一致
        • 各環境をできるだけ一致させた状態を保つ
      • ログ
        • ログ管理をアプリ自身で行わない
      • 管理プロセス
        • 管理タスクを1回限りの実行プロセスとする
その他の(Lambda特有の)ベストプラクティス
  • メモリ設定
    • メモリを増やすとCPUも倍になる
    • Lambdaはメモリ使用量と処理時間で課金、メモリを増やすとパフォーマンスも向上する
    • 段階的に試して最適化を目指すのが吉
  • VPCは必須ではない
    • 必要でない限り使用しない
    • 使うのはVPC内のリソースにどうしてもアクセスする必要がある時だけ
    • パフォーマンス劣化の原因になる
    • VPC内のリソースとの通信が必要な時は非同期にする
  • Design for failure
    • リトライ
    • Dead Letter Queueの活用(非同期の場合)
  • 冪等性はコードで確保する必要あり
    • Lambdaで保証しているのは最低1回実行すること
    • 場合によっては2回以上実行していることも
  • コールドスタート
    • 安定的なトラフィックが発生している場合、コールドスタートの発生頻度は低い
    • コールドスタートは発生するものと思った方がよい
      • 遅延が一切許容できないのであれば使用しない方がよい
  • ローカル実行について
    • Lambdaで使われているAMIは公開されている
    • ファンクションんと言ってもただのプログラム
    • Contextとイベントを再現する必要がある
      • 単なるJSONオブジェクト
コールドスタートを速くする
  • Lambdaファンっくしょんに対してPingする
    • 定期的にアクセスしてコンテナ破棄を防ぐ
  • コンピューティングリソースうを増やす
    • CPUも早くなるので初期化処理も早くなる
  • ランタイムを変える
    • Java(JVM)は起動が遅い
      • 一回起動しちゃうとJavaの方が早い
  • VPCを使わない
  • パッケージサイズを小さくする
    • サイズが大きくなると起動時間も長くなる
    • 不要なコードは減らす
    • 依存関係を減らす
    • Javaは肥大しがち
  • 初期化処理をハンドラ外に書くとコールドスタートが遅くなるので、遅延ロードを行う
ローカル実行
  • テストドライバ
Q&A
  • 後日ブログで
告知

感想

 AWS Lambdaは今まさに仕事で使っているサービスで、オレにとって実質最初に触ったAWSサービスと言えるんですが、とっても大好きです。こういう要らんこと気にせずに、やりたいことに集中できて、パズルみたいに組み合わせて作れるのは非常に楽しいですね。今回のオンラインセミナーでは、オレが思ってた以上にLambdaの活用パターンがあることが知れて、とても参考になりました。今後Lambdaと連携できるサービスも増えるようですので、今後とも活用していきたいです。

4/12(水)、AWS Black Belt Online Seminar Amazon VPC 受講レポート

はじめに

 Amazonが配信している「AWS Black Belt Online Seminar Amazon VPC」を受講しました。以下受講メモ。


メモ

Virtual Private Cloud

Amazon VPCとは
  • データセンタ・ラック・ネットワーク機器
    • 様々なステップが必要
      • 時間(=コスト)がかかる。早くても数か月
  • クラウドで仮想ネットワークを構築(必要な機能を抽象化、サービスとしてあらかじめ用意されている)
    • 組み合わせてすぐ利用可能
  • クラウドに対する悩み・不安
    • VPCで解決可能
    • AWS上にプライベートネットワーク空間を構築
    • 論理的なネットワーク分離が可能
    • ネットワーク環境のコントロールが可能
    • 複数のコネクティビティオプション
VPCコンポーネント
  • 様々なコンポーネントを用意
    • VPCウィザードで数画面で作成可能
      • 作成過程をウォークスルーで(VPCウィザードを用いずに)説明
        1. アドレスレンジの選択
        2. アベイラビリティゾーンの設定
        3. インターネットへの接続を設定
        4. VPCのIN/OUTトラフィックを許可
      • セットアップの補足
        • サブネット内のDHCP
        • Amazon DNSサーバ
          • DNS機能の有効化とホストへのDNS名割り当て
            • Enable DNS resolution
            • Enable DNS hostname
          • -
      • IPv6の対応
        • IPv4/IPv6デュアルスタックで構築可能
      • VPCにおけるIPv4IPv6の特徴と制限
        • IPv4:デフォルトで適用
        • IPv6:自動適用ではなく任意
オンプレミスとのハイブリッド構成
  • VPN接続
    • 安価なベストエフォート
    • 海鮮も利用可能
  • 専用線(Direct Connnecct)
    • 準備期間が必要
    • よりセキュアに接続できる
  • VPN専用線の並行運用も可能
  • Transit VPC(海外拠点と国内企業をつなぐ)
    • CloudFormationテンプレートとして提供
VPCの設計
  • 使用するAWSサービスがVPCの内外どちらからアクセスするかを確認する
  • NATゲートウェイ
  • VPCを分割するケース
    • アプリケーション
    • 監査スコープ
    • リスクレベル
    • 本番/検証/開発フェーズ
    • 部署
    • 共通サービスの切り出し
    • VPCピアリング(VPCピア接続)
VPCの実装
VPCの運用
  • VPC Flow Logs
  • VPCのリミット関連
    • 超える場合には制限解除申請
まとめ

感想

 メモの少なさからお察しいただけるかと思いますが、途中で振り落とされました。ネットワークの知識が十分でないと、いくら使い方やサービスを聞いてもわかりませんね。猛省。
 それはそれとして、その拙い前提知識でも、Amazon VPCの使いやすさは十分伝わりました。あんなめんどくさい(分からない)ものを、簡単な手順で構築できちゃうのは凄いなぁ。
今回の受講内容で引っ掛かったキーワードを調べ直して、また資料と動画アーカイブに再チャレンジしたいと思います。

4/11(火) AWS Black Belt Online Seminar 初心者向けクラウドコンピューティングはじめの一歩 受講レポート

はじめに

 Amazonが配信している「AWS Black Belt Online Seminar 初心者向けクラウドコンピューティングはじめの一歩」を受講しました。以下受講メモ。

メモ

初心者向けクラウドコンピューティング
  • 初心者向け、新卒向け
クラウドとは
  • 形のないもの
  • 実体は分からないけど使いたいサービスが使い時に使用できる
  • 必要な時に、必要なだけ、低価格で利用
  • 既存インフラ
    • 初期投資が発生
    • 余剰・不足のリスク
    • 固定費
  • クラウド
    • 初期投資が不要
    • 必要な分だけ利用
    • 変動費
  • クラウドの利点
    • 余剰リソースをさけることができる
    • リソース不足による機会損失を避けることができる
  • クラウドの特徴
    • セルフサービス
    • 迅速展開インフラ
    • 低額な利用価格
    • 実際の使用分のみ支払い
    • 初期投資が不要
    • スケールアップ・ダウンが容易
    • ビジネススピードの改善
アマゾンウェブサービスのなりたち
WAWSグローバルインフラストラクチャ
AWSサービス群と活用例
  • AWSサービス群:90以上
    • 顧客要望から生まれた
  • AWSは最も汎用性の高いクラウドの一つ
    • 迅速にクラウド移行を可能にする
    • 様々なOSS / 商用プロダクトを活用できる
      • 1500のパートナー / 3500のソフトウェア
  • 主だったサービス
  • 様々なサービスを組み合わせてシステムを構築できる
  • Serverless Architecture
はじめの一歩
  • アカウントを作ろう
    • インターネット接続可能PC
    • 携帯電話
    • クレジットカード
  • チュートリアル
  • 習うより慣れろ
  • 失敗したら消せばいい
  • 無料利用枠でお試し
  • AWS Trusted Adviser
    • コスト最適化、セキュリティ、耐障害性、性能をチェックし推奨事項をお知らせするサービス
  • AWS知識習得方法
    • 無料オンラインセミナー
    • 無料ドキュメント
    • 有料トレーニング
  • AWS認定資格

感想

 本当に初心者向けなので、「AWSの理解を深める」という点だけ見れば、オレがこのオンラインセミナーを受講する必要は無かったでしょうね。でも、「どうやって初心者に向けてクラウドAWSを説明するか?」という観点では参考になりました。
 内容はとても分かり易いので、セミナー冒頭にもあったように初心者や新卒社員が学ぶには適した内容だと思います。
 このセミナーではスライドのみを画面に映すので発表者(講師)の顔は見えないんですが、それでも声の調子などで相当緊張している様子がうかがえました。あまり発表経験がない方だったのかもしれませんね。

4/05(水)、AWS Black Belt Online Seminar Amazon EC2 受講レポート

はじめに

 Amazonが配信している「AWS Black Belt Online Seminar Amazon EC2」を受講しました。
 今の会社ではAWSの知識が必須なので、それまでレガシーなシステムしか触ってこなかったオレは突貫工事でAWSに関する知識を詰め込んでいってるんですけど、意外と社外勉強会の開催がないorタイミングが合わないこともあり、今後積極的にAmazon主催のオンラインセミナーを活用することになりそうです。


 以下、受講時に取ったメモ。

メモ

EC2の基本
  • EC2
    • どこかのリージョンのどこかのアベイラビリティゾーンで起動
      • インスタンス
        • 仮想コンピューティング
        • 1時間ごと
      • 既存のOS/アプリ/ミドルウェアが利用可能
      • APIでインフラの自動化が可能
        • どのリージョンで起動するか、なども指定できる
  • Amazon VPC(仮想ネットワーク)によるハイブリッド構想
インスタンスタイプ
  • 最大1228vCPU 1952GiBメモリ
      • 小規模向け
      • コア性能重視
      • バランスタイプ
      • メモリ重視
    • 新しいインスタンスタイプを年々追加
  • AMIの分類
    • 32bit/64bit
    • 準仮想化(PV)/完全仮想化(HMV)
    • ブートストレージ
  • インスタンスとHOstの違い
    • アフィニティ:同じところで起動し続ける
ストレージ
  • EC2インスタンスストア
    • ホストコンピューターに内蔵されたディスク
    • EC2を停止→起動するとクリアされる
    • I/Oは早い
  • Amazon Elastic Block store
    • データ永続性
    • 追加利用料金が発生
  • インスタンスストア
  • EBS
    • EC2にアタッチされるストレージ
    • EC2から独立
    • 他のEC2に付け替え可能
    • ネットワーク越しにアタッチ
      • EBS専用回線(ストレージエリアネットワーク)を用意することも可能
ネットワークとセキュリティ
  • 責任共有モデル
    • クラウドの中のセキュリティ:AWS
    • 搭載するアプリ:ユーザー
  • Key Pair
    • 鍵認証でログイン
    • AWS:公開鍵、ユーザー側:秘密鍵でアクセ巣
  • セキュリティグループ
    • アクセスルールをひとまとめにしたグループ
  • AWS上でのIPの種類
    • Elastic IP
      • 明示的にIPを割り当てる
      • 固定IPアドレスが必要な場合のみ(単にアドレスが必要な場合はPublicIPで十分)
      • EIPをインスタンスにアタッチしてない場合は利用料金が発生(有限資産なので)
    • Public ID
      • ランダムに割り当てられる
    • Private IP
      • 必ず割り当てられるIP

  • Elasticc Network Interface(ENI)
    • VPC上で実現する仮想ネットワークインターフェース

  • 拡張ネットワーキング(Enhanced Networking)
    • ネットワークI/Oが必要な場合に活用するサービス
    • スイッチを通さず直接NICにアクセスできる
  • Placemnet Group
    • node間通信が大量発生する場合に有効
運用・監視
  • Cloud Watch
    • AWS各種サービスをモニタリングするためのサービス
      • メトリクス監視
      • メトリクスに対するアラームの作成
      • ログ監視
  • Auto recovery
  • EC2のSLA
    • 可用性:99.95%
    • それに満たない場合には金返してくれるらしい
料金
  • ECC2使用状況レポート
  • Trusted Adviseor
    • ビジネスサポート以上のユーザーのみ
    • 概算見積ツールも
    • AWS無料枠
      • t2.micro 720時間

感想

 EC2はたぶんAWSの中で一番有名かつ一般的なサービスだと思うんですが、実はオレはまだちゃんと使用したことがありません(略式には無いこともない)。今回のオンラインセミナーでは、ハンズオンと違い手を動かすようなことはないので、あくまでEC2というサービスの紹介にとどまる内容なんですが、それでも網羅的に提供サービスを把握できたのはありがたいです。要は既存のレンタルサーバっぽいものだということなので、そういう意味ではこれまでの開発経験が最も活かせるところでもあるとは思っています。まずは無料枠で触ってみるところからかな。
 途中音声トラブルがあってオンラインセミナーが一時中断したんですが、オレが受講したネットワーク環境は妙にネット接続が悪いことがあるので、こちらとあちら、どちらに問題があるのか分からずちょっと焦りました。まぁこういうのはオンラインセミナーならではのトラブルですね。

AWS API GatewayでPOSTリクエストの配列を扱えるようにする

 ここ最近仕事でずっと悩んでたのが、昨晩やっと解決したので、備忘録的にメモメモ。


 クライアントからAWS API Gatewayを経由して AWS Lambdaで処理を行うAPIを開発しているんですが、LambdaはJSONデータしか扱えません。一方クライアントからは通常のHTTPS POSTでリクエストが送信されます。この場合、API Gatewayの統合リクエストにあるマッピングテンプレートでJSONデータに変換してあげる必要があります。このマッピングテンプレートは「Velocityテンプレート言語(VTL)」で記述するのですが、これがイマイチ情報が少なくて書き方が分からない!



f:id:takigawa401:20170407103429j:plain
1. API Gatewayで作成したAPIから「リソース」を選択
2. 「メソッド(「GET」とか「POST」とか。今回は「POST」)」を選択
3. 「統合リクエスト」をクリック

f:id:takigawa401:20170407103436j:plain
4. 「本文マッピングテンプレート」をクリック
5. 「マッピングテンプレートの追加」をクリックして「Content-Type」に「application/x-www-form-urlencoded」を追加

f:id:takigawa401:20170407103444j:plain
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

こういう風にAPI Gatewayにやってくるのを

{
"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('$') 」と回避できました。



ちなみに参考にさせて頂いたサイトは以下。上記のマッピングテンプレートも、配列の処理以外はほぼ以下のクラメソさんの記事のものを使わせて頂きました。


インタビューによる「自分半生記」のススメ

IMG_6996

はじめに

 週末にインタビューめいたことをやってきました。

 相手は社外勉強会つながりの知人。コンサルというかコーチというか、まぁそんなような仕事をされている方なんですが、「最近インプットはしてるんだけど、アウトプットをちゃんとできてない。一回整理してアウトプットしたい。」というようなことをSNSでつぶやいてるのを見かけて「面白そうだからケツひっぱたいて強引にアウトプットさせちゃえ!」とばかりにオレから声をかけ、時間確保してガッツリ根掘り葉掘り聞いて書き出して、アウトプットしてもらうための整理をしてもらおうと試みたわけです。

 ……「試みた」と表現したのは、つまり、終わらなかったんですよ、インタビューが。結果面白い話は聞けたし、インタビュイーの方にもかなり満足してもらえたので、それはそれで良かったのですが、本題までたどり着けなかったのは非常に残念でした。

 なぜ終わらなかったのか? それは、今回オレが行ったインタビューが、「その人が生まれた時から今日に至るまで、全て話を聞いていったから」です。今回はインタビュイーの方は4x歳で、まぁそれでも2時間くらいで最後まで行けるかな、と見積もっていたんですが、実際にはインタビュイーの方の話があまりに波瀾万丈すぎて一晩中話しても全然時間が足らなかったですね。まぁオレの見積精度が甘いのはいつものことなのでしょうがないか。

 とはいえ、一応好評だったんで、今回のインタビューでどんなことをやったのかを書き出してみたいと思います。


ルール

 今回行ったようなインタビューは、以下のようなルールに基づいて行いました。

  • その人の生まれた時から聞いていく
    • 出身地は?
    • 家族構成は?
    • ご両親の職業は?
    • 環境は都市か田舎か?
    • etc...
  • 人生の節目を意識して聞いていく
    • 小学校と中学校はセットで考えてOK
    • 高校くらいからその人の選択が見て取れるので、意識して聞いていく
      • 部活や趣味、その頃興味を持っていたものなども
  • 必ず他者がインタビュイーに質問する形式で聞く
    • 意外と自分のこと(≒分かっていること)は端折って喋りがち
  • インタビュイーが話したくないことは聞かない
  • 脱線上等!ユルいスタンスでインタビューに臨む
    • 脱線してもあまり無理に話を戻さない
    • その人の「ひととなり」が把握できることのほうが重要
  • 細かく聞き過ぎない
    • 時間がいくらあっても足らなくなる
    • 掘り下げたいポイントがあれば個別にインタビューを行う

なぜ「半生」をインタビューするのか

 このインタビュー方法は元々、オレが派遣常駐型のSIerで小さな部署を任されていた時に、自分の部下たちに対して行っていたものです。

 その会社では四半期〜半年に一度、自社に戻ってきて部下たちと面談することが各部署の上長に義務付けられていました。それが無くとも、必ず年に一度は人事評価を行う必要があります。
 ところが部下たちと顔をあわせるのはせいぜい月一回程度。これで「人となり」を把握するのはどだい無理ですし、人事評価を行うのも困難です。人事評価に関しては結局「営業から伝え聞いた現場の評判」に頼らざるを得ないのですが、元々大した情報が期待できないうえに伝聞の情報です。はっきり言ってお話にならない。さらに言えば、人事評価も含め、部下の育成責任も背負わなくてはならないのです。現状の能力評価も正しくできない、「人となり」も把握できてない。こんな状態で部署の上長としての責務を全うできますか?出来る奴がいたら、そいつは予言者かイタコです。IT業界なんかにいないで芸能界進出でも考えた方がよっぽど稼げます。

 というわけで、予言者でもイタコでもない凡庸たるオレが取った手段は、部下が自分の部署に就いた一番最初の面談で、それまでの人生含め様々なことを根掘り葉掘り聞いて、その部下の「人となり」をザックリとでも把握する、というものでした。それぞれ部下一人一人から半生に相当するものを聞き、その上で会社の方針や部署の方針、人事評価の方法、今後どういう方向に進みたいか、といった一般的な評価面談の内容を改めて話すようにしていました。

 これをやるとメッチャクチャ時間がかかります。一人あたりの面談時間が2時間なんてのはザラ、場合によっては3時間やってそれでも足らずに居酒屋に移動して延長戦突入、なんてのもありました。
 でもその甲斐もあって、オレの部署は(成果はともかくとして)当時社内で一番活気があって面白いチームでしたし、週末に勉強会なんかを頻繁にやっていたこともあってか、その取り組みが評価されて、リーマンショックで社内全員一律ボーナスカットなんて事態でも、オレのチームだけは全員ボーナスが出た、なんてこともありました。


 その辺の取り組みは以前発表したことがあるので、興味があれば以下のスライドをご覧いただければと思います。




 これは

  • チームが同じ場所で働いていない(多くて月一程度しか顔を合わさない)
  • 部下の人事評価と育成を行う義務がある

という特殊状況下で否応なく迫られて行ったことでした。
 しかし、今回異なるシチュエーション(他者の能力の棚卸の実施)でインタビューを行う場合にも、割と悪くない手法なんじゃないかと思い、今回は採用しました。


 以下は故:スティーブ・ジョブズ氏の有名なスピーチです。このスピーチで個人的に一番大事だと思っているのは、スクリーンショットを貼付した以下の部分です。

スティーブ・ジョブス スタンフォード大学卒業式辞 日本語字幕版


https://www.youtube.com/watch?v=XQB3H6I8t_4

f:id:takigawa401:20170402152450p:plain
f:id:takigawa401:20170402152507p:plain
f:id:takigawa401:20170402152513p:plain
f:id:takigawa401:20170402152518p:plain


 この箇所については「物事はいつか何かしらつながっていくから、将来それが役に立つ・立たないに関わらず、今自分が興味のあることに全力を注ぐべきだ」「役立てるための点と点とをつなぐ努力は後でやれ」とオレは理解しています。過去に起こったこと、体験したこと、学んだことは、大なり小なり何かしら今の自分に影響しているはず。

 例えば、オレは漫画が好きですが、その遠因は

  • 叔母が漫画家だったこと
  • その影響で彼女の生家でもあるオレの実家には、彼女の残していった漫画があふれかえっていたこと
  • 母が元々漫画やアニメが好きで、子供たちからそれを隠したり遠ざけたりしなかったこと

 が考えられます。その結果として、

  1. 親がTVゲームにも理解があり、小中高と楽しくゲームで遊べる環境にあった
  2. ゲームクリエイターになりたくて専門学校に入る(大学に入るよりも近道に感じた)
  3. 元々進学校の出身だったこともあって、そうではない学生向きの授業……特にプログラミングで全く苦労しなかった
  4. 「これだったら独習で十分だな。それよりは教わらないとできないものを学校で教えてもらった方が良さそうだ」とゲーム科からCG科に転科
  5. CG科で教わったWeb・HTMLが面白くなり、そちら側に進路を変更
  6. アルバイトで入った光通信系のホームページ作成会社で、自分にデザインのセンスがまるで無いことを思い知る
  7. Webの知識があり、PhotoshopIllustratorも使えることから、Web系業務システムエンジニアに転身

 という道をオレはたどりました。一見すると無軌道な人生にも見えますが、源流に叔母と母の影響で漫画好きだったこと鑑みると、それなりに筋が通っているようにも見えます。


 このように、今の自分が、過去の何に影響されているかは、意外に今だけ見ていると分かりづらいです。また、分かり易く役立つものだけがつながりになっているとも限らないです。スティーブ・ジョブズの言う「後から振り返って点を点を繋ぐ」のには、洗いざらい過去を漁ってみて、全部平らにして並べてみた方が、より効果的だとオレは思います。



 時間がかかる作業ですし、協力者(インタビュアー)も必要です。やれば必ず成果が出ることは約束出来ませんが、少なくともオレに関してはこれまではそれなりに手ごたえを得ることができていました。仕事や進路で悩んだ時、自分の棚卸が必要になった際には、ぜひ一度試してみて頂ければと思います。



余談

 今回インタビューを行うにあたり利用した店はこちらでした。カウンターメインの店で店員さんが頻繁に話しかけてきてくれるので、一人でも行きやすいんじゃないかと。「アキバで女の子がサービスする店」というイメージを良い意味で裏切られ、料理もお酒も大変美味しかったです。また、我々のインタビューの内容にイイカンジでツッコミをくれたのも面白かったですね。話に夢中になってて肝心の寿司を食い忘れたので、またいづれリベンジしたいです。

www.nadeshico-sushi.com

日常に+1して深堀りする

 どーも、一度は物語をちゃんと書いてみたいと思ってるワナビーなタキガワです。一度も書くのにチャレンジできてないから、ワナビーにさえなれてない、が表現として正しいのか。


 オレは周囲の人間にはアニメオタクっぽく思われてるようですが、実際には殆どアニメを観てないです。1クールに1作品見ていれば多い方でしょうか。昔はもうちょい見てた気もしますが、最近深夜アニメも観なくなったのは……飲んで帰ってくることが多すぎてテレビ観ずに寝落ちしちゃうからでしょうな。良い子と良い大人はお酒の飲み過ぎには注意しましょう。

 そんなオレが今クールは珍しく2作品を追っかけてました。1つは今話題の「けものフレンズ」、もう1つが「亜人ちゃんは語りたい」です。前者は話題だからというのが見始めた理由ですが、後者は妹が録画してたのに付き合って観てた感じです。とはいえ、オレが苦手な作品は、妹はオレが不在の時に観てくれるので、付き合って観てるうちにオレもハマった、が表現として適切かもしれません。

kemono-friends.jp
demichan.com


 そしてもう1作品。先ほどニコニコ生放送タイムシフト視聴で一挙全話放送で「ふらいんぐうぃっち」を一気に観ました。いやぁ、面白かった。
 横浜で生まれ育った新米魔女の女の子が、高校進学を機に青森の親戚の家に居候しながら修行をする、というのが主なあらすじ。魔女や魔法使いというとハリーポッターさながらの非日常なファンタジーの世界を思い浮かべるかもしれませんが、この作品ではそういった派手な演出は抑えられており、魔女が自然との親和性を大切にする、という設定のもと、自然の多い青森での生活を丁寧に描いた、いわゆる日常系な内容になっています。


www.vap.co.jp
live.nicovideo.jp


 「亜人ちゃんは語りたい」と「ふらいんぐうぃっち」はとてもよく似ていると、作品を視聴していて感じました。どちらも日常系だからであり、どちらも既存の架空のものをちょっとだけ足している。「ふらいんぐうぃっち」は「魔女」で、「亜人ちゃんは語りたい」は亜人(吸血鬼、デュラハン、雪女、サキュパス)。足した要素を丁寧に丁寧に掘り下げ、同じように日常(≒現実)を丁寧に描写することで、日常を破綻させないようにしています。
 その辺の最たるが「シン・ゴジラ」なんですが、こちらは追加した要素が苛烈すぎて、日常が破綻しちゃうというか破綻せざるをえないのが、前述の2作品と異なるところかもしれません。(数話しか見たことないんで自信ないけど、東京喰種も同系統かも)


 オレは週刊少年ジャンプを読み、スタジオジブリ映画を観て育ったせいか、どうも物語を作る、というと、とんでもない大スペクタクルな話を作らなくてはいけない、他人が絶対に思いつかないような話にしないといけない、と物凄く大仰に構えていたような気がします。

 でもそうではなく、既存のファンタジー要素をちょっとだけ目の前の現実に足して、それを丁寧に深堀りしていくことで、今までにない新しい作品を作ることができるんだなぁ、と、これらの作品に教えられた気がします。まぁその「丁寧に深堀り」が大変な作業でセンスを伴うものなのは、言うまでもありませんが。


 明日からはもうちょっとだけ日常と丁寧に向き合ってみようと思います。その中で「+1」できる何かを見つけることができたら、オレもワナビー未満から卒業できるのかもしれませんね。