ミッションたぶんPossible

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

6/16(金)、「駅すぱあと」× EXPERTプロジェクト ストームチェイサー青木豊氏 トークイベント に参加してきた

f:id:takigawa401:20170619002335j:plain

はじめに

 6/16(金)は高円寺:ヴァル研究所で開催された「「ストームチェイサー青木豊トークイベント 」に参加してきました。ストームチェイサーとは、嵐・竜巻・雷などの異常気象を専門に扱うカメラマンのこと。日本では青木さん唯お一人のみがプロのストームチェイサーとして活動されているそうです。人が逃げる危険な異常気象を敢えて間近で撮影するその日常ぶりは常軌を逸しており、あまりの凄まじさにTBS系ドキュメンタリー系バラエティ「クレイジージャーニー」でも特集を組まれたほど。


 今回このイベントは、ITコミュニティづてでご紹介頂き、開催を知りました。オレ自身、写真が趣味で、親父も野鳥撮影が趣味ですが、親父から聞く野鳥の撮影は、普段写真を撮り慣れているオレからしてもかなり過酷です。それをさらに上回る困難さが付きまとう異常気象の撮影というのはどういうものなのか、ぜひお話を伺いたいと思い参加した次第です。


ekispamall.net
www.tbs.co.jp


 以下、トークショーのメモ。最初の10分程度は遅刻したこともあって聞き逃していますのでご了承ください。


聴講メモ

  • 食っていけるか?
    • 1人しか知らない
    • 自身もバイトしながらやってる
    • 普段は普通のカメラマンと同じ
  • きっかけ
    • 最初の一枚
    • 昼間は撮れない
      • 動体視力があれば行けるんじゃね?
        • バッティングセンター
      • 被写体の特性を知らねば撮影をはできない
        • ネット
        • 図書館
  • 雷の特性
    • 地上と上空を何往復もしている
    • 雷をとらえやすいシャッター速度があることに気づく
    • 月刊誌から引き合いが!
    • 狙っても取れないが、狙わないと取れない
    • 2012/05、茨城県つくばで竜巻
      • 死者も出ている
      • 取材が殺到
      • この機を逃すと後がない!
    • 2012/11、プロのストームチェイサー
  • トームチェイサーのお仕事
    • 自営業
      • 事務処理も自分で行う
        • 実は事務処理は嫌い
    • パチンコ屋の早朝清掃
      • (色々あってパチンコ屋のエピソードは自主規制)
      • 雷は午後が多い
    • シーズンオフ
      • ブライダル撮影
      • 商品撮影
      • リフォーム物件撮影
    • 本当は好きな写真を撮って暮らしたい
      • 日本には写真を買うという文化が根付かない
    • 最盛期は寝ない
      • 夜遅くまで作業
        • 仮眠取るつもりがいつの間にか深夜に
    • バイトで得た収入は生活費
    • 撮影で得た収入は撮影機材やガソリン代
      • ガソリン代は馬鹿にならない、シーズンは月7万の時も
  • チェイスをするための準備
    • アメリカはどこに停めても撮影できる
      • 高速道路は無料
        • 停車は禁止だが停めて撮影している人はいっぱいいる
          • そのせいで曳かれて死ぬ撮影家も
    • 3日前
      • 情報収集
        • ネット
          • 天気予報
          • 天気図
          • 発雷確率
    • 2日前
      • 予報や確率のっ変化を気にしながら撮影地を模索
      • 予報は当たらないことが多い
    • 当日
      • レーダーを気にしながら
      • 目視で確認
        • 輪郭のはっきりした雲が狙いやすい
        • 雲は動きが早い
          • 30km/hくらい
          • 日本は信号や渋滞が多い
          • 車を停められる場所が見つからない
            • 停められる場所を探している間に雲をロストすることも
    • めったに撮れない
      • 撮れたらうれしい
        • 奮発してお酒やお肉が食べたくなる
    • 情報源
      • レーダーは重要
        • それぞれ得意分野が違う
      • 竜巻注意報
        • 当たる確率は3%程度
      • 気象庁レーダーナウキャスト
      • 国交省ZRAIN
        • 更新間隔1分
      • 電力会社提供の雷情報
      • 車の中で待つ
        • ただ待つだけじゃない
        • 自分の判断と勘で
          • ゲーム感覚
  • 楽しみながら撮りたい
    • 長続きしない
  • 五感を研ぎ澄ます
    • 自分で見て肌で風を感じて危険を察知する
    • 危険を感じた場合、車がシェルターになる
      • 金属に囲まれていると安全
        • 窓が開いているとNG
        • 金属に触れているとNG
        • 鉄板が薄いと突き抜ける?
    • 危ないと思ったときにはもう遅い
    • 雨が降ってきたら移動を考える
    • 目当ての雲が迫ってきたら
      • 雨が降ってきたら雨が降ってない場所まで移動して撮影
      • 虹は10分くらいで消える
  • モチベーション
    • いつか理想の一枚を撮りたい
    • 雲や天気のことをもっと知りたい
  • 撮影時のエピソード
    • 小さめなカメラの使用
      • 「えっプロなのにこんなので撮影してるんですか」
      • 車の中で撮影するので、小さくて使いやすいカメラがよい
      • 最近のカメラは性能が良いので、小さくてもちゃんと写真は撮れる
    • 認められた一枚
      • 日経に掲載された
      • 反響がすごかった
        • これがきっかけでプロ宣言に
    • 情熱大陸
      • まるまる一年かけて撮影
      • ストレスで4kgやせた
        • 撮影日に雷がとれるとは限らない
      • プライベートまで撮影
        • 食事
        • 洗濯
        • 言わなければトイレまでついてくる
        • ディレクターと折り合いが悪い
          • こいつとは一生友達になりたくない
      • アメリカロケ
        • モンタナ州
          • スーパーセルを撮影
          • この年は米国で竜巻発生数が少なかった
          • 夕焼けに染まったスーパーセル
          • 日本車と韓国車だらけ
          • 地平線が見える
            • 数百キロ先の雲も小さく見える
          • 住民の気象に対する関心が高い
            • 農業が盛ん
            • 自分の身は自分で守る
            • 気象専門チャンネルがある
            • 地下シェルター
              • 20万円くらい
        • 怪しい奴がいると銃で撃たれる
          • 竜巻や雷よりも住民を警戒しなければいけない
          • ガイドに同行してもらう
            • 一筆書かされる
            • 死んだという人は聞いたことが無い
        • カンザス
          • 現地のチェイサーのアドバイスに従うしかない
      • 放送4日前
        • 予告が入った後でも撮影は続いた
        • 人工物・建物を比較対象として写すことが多い
    • 火災旋風
      • ファイアートルネード(ファイアーネード)
      • 炎の上昇気流で出来る旋風
      • 発生条件がはっきりしていない
      • 野焼き・大火災
      • 炎だけでは発生しない、風が加わることで発生条件を満たすらしい
    • ガストフロント
      • 横長の雲
      • 積乱雲の前兆
      • 突風を伴ってやってくる
        • 通り過ぎると積乱雲がやってくる
      • コンパクトな寒冷前線
      • アーククラウド・アーチ雲
        • 昔は年一回撮れるか撮れないか
        • 最近たびたび発生する
        • 風速20m、カメラがバラバラになるほど
        • 重しをつけて飛ばないように工夫している
    • ダウンバースト
      • 茨城県下館市
        • 国内最大級のダウンバースト(F2 / 20年前)
          • テレビのアンテナが全部とんだ
          • 死者発生
            • 太陽光パネルが吹き飛ばされてそれに直撃
      • F0・F1、風速はそれほどでもない
        • 体感的にはかなり風が強い
        • 木がバタバタとゆれる
      • 被害範囲が広い
      • 飛行機には大変危険
      • ダウンバーストを解明したのが藤田博士
        • Fレベルは藤田博士の頭文字から
        • アメリカでは神様みたいな人、亡くなった時には特番まで組まれた
        • 測定するためにセスナ機をチャーターしてダウンバーストに特攻した
          • 米国人「イッツアクレイジー!!!」
      • ダウンバーストをTVで撮影したがお蔵入りになってしまった
      • 被害が出るとテレビが買いたがる
        • 画像データが大きいので、データが簡単に送れない
          • ADSLを未だに使っていたり
          • 夕方の番組に間に合いませんでした
      • 電車にとって脅威
      • 雷の軌跡を追えるソフト
        • 雷の予報に役立てる?
          • 学者の言ってることが難しくてよくわからなかった
      • 横走りの雷が増えると積乱雲が衰退してきた証拠
  • まとめ
    • 分かりづらい現象(=気象現象)を可視化すれば、子供から大人まで分かってもらえる
      • 「こういう雲が来たら危ないよ」
    • 気象現象に興味を持ってもらいたい
    • 防災に役立てられれば
    • トームチェイサーは役に立ってる? まぁ役に立ってるでしょう
    • 気象予報士は専門用語を並べる
    • 同業者がいない
      • 同業者がいた方が喜ばしい
    • -
    • 7/15~9/03群馬県立館林美術館「カミナリとアート」
    • あとは内緒だけど自然現象全般のイベントも準備中
  • Q&A
    • 火災旋風がレーダーが映った
    • 冬の雷は大雪を呼ぶというが、ご自身の経験は?
      • 実際に撮りに行ったことがある。日本海側では割と浸透している知識
    • 一番危険な経験は
      • 冠水した道路に取り残された
        • 電柱を目印に冠水した道路
    • 竜巻が起こりやすい条件は?(by気球男)
      • 竜巻は平地で起こりやすい
      • 積乱雲が発達しやすい=風が交差しやすい
      • スーパーセル
    • トームチェイサーの一番大事な条件は
      • 土地勘
      • 土地を把握していないと機構を読めない
      • 危険を回避するうえでも重要

感想

 いやぁ、思っていた以上に大変ですね。このトークショーの後で「クレイジージャーニー」の放送回も観たのですが*1、あれだけ下調べをしていても空振りが圧倒的に多いことにビックリしました。本当に好きでなければ続けられないっすわ。また青木さんの場合は、「異常気象がどれほど危険か知らせたい」「研究機関に提供することで将来の災害予測に役立てたい」と使命感を持たれており、「雷が好き」「良い写真が撮りたい」以外のモチベーションもそれを支えているようです。
 オレはあくまで趣味で写真を撮っており、できればその趣味で撮った写真をプレゼンやブログで活かしたい、とは思って続けていますが、さすがにあそこまでのめり込むことは……。ただただ感心するばかりでした。あの辛抱強さと執念は見習いたいです。


 お話の中には、青木さんの生活感あふれる話や、「情熱大陸」で長期間の密着取材があった際の撮影スタッフとのイザコザの話など、青木さんの生身の部分が見えて親近感がわきました。「クレイジー」と評される人であっても、視点を変えればただの人、というのは、個人的には安心感もありますし、立ち入れない領域ではないのかもしれないと感じて心強くもあります。



f:id:takigawa401:20170619002357j:plain


 トークショー最後にはじゃんけん大会も。勝ち抜いた女性お二人が、会場に展示されていた青木さんのお写真のパネルをプレゼントされていました。また、自己申告で「今日が誕生日だから自分にも写真をくれ」という若い男性にもパネルがプレゼントされるという太っ腹な一面も。……クレイジージャーニーで青木さんの平均月収を知っていたら、とてもじゃないけど「タダでくれ!」とは言えないですね。今思い返せばじゃんけんで早々に負けてよかったのかも。
 帰り際に写真集も購入、青木さんから直々にサインも頂きました。オレの購入した費用だと、印税が10%だとして……残念ながら唐揚げ&ビールには到底届かないですが、また機会を見つけて買わせて頂きます。




 最後に、このイベントを教えて頂いた@Toshiaki0315さんと丸山さんに多大なる感謝を。イベント最後に回答したアンケートから察する限り、ヴァル研究所さんの「駅すぱあと× EXPERTプロジェクト」では、また青木さんと同じようなエキスパートな方のお話が聞けそうなので、今後もチェックしてみたいと思います。




f:id:takigawa401:20170619002352j:plain

*1:一応リンクは貼りますが、違法だったら消えると思うので、その旨ご了承ください

「開発をアジャイルで」「でも契約は一括で」と言ってくる顧客がいたらどうすべきか?

IMG_4803

はじめに

 このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。


 ついこの間、その新会社で、PM的役割をこなす社員を対象に開かれた「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。
 ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰かが、壇上に立つ法務部の人間に、こんな質問を投げかけました。


 「たまにお客さんから『アジャイルで開発したいんだけど、契約は一括(作成請負)にしてほしい』って言われるんだけど、こういう場合はどうしたらいい?


 あまりに驚いたのでその後の経緯をあまり覚えていないのですが、確か壇上の人間には答えられず、会場脇にいた講師役社員の上司にあたる人物が、「契約をできるだけ細かく区切るしかない」みたいな回答でその場は収まったような記憶がおぼろげながらにあったり無かったりします。
 そのやり取りを聞いていたオレは、「どうしたらいい?じゃねーよ!契約以前にやること山ほどあるだろうか!!」と怒鳴りつけたくなるところでしたが、この場は法務研修、アジャイルの議論をする場ではない、とそっと胸の内の矛を収めた次第です。


 今回のQ&Aで出てきた、客からの「開発をアジャイルで」「でも契約は一括で」という要望は、いったい何が問題なのでしょうか?


開発費用が高くなる

 問いに対して法務部の上役が回答した「契約をできるだけ細かく区切るしかない」は、おそらく開発プロセスに「スクラム」を採用して開発を進めることを想定して言ったのでしょう。巷では昨今どうやら「アジャイル」=「スクラム」というイメージが定着しているようなので、ソフトウェア開発を主務としていない法務部の人間がこう勘違いしてしまうのは、まぁ止む無いことだと思います。(質問してたヤツは絶対許さん!)


 スクラムでは1イテレーションの開発対象(タスク)を確定すると、基本的にそのイテレーションの最中はタスクの変更は行いませんので、イテレーション単位で見積を作成しその都度契約を行うことは、まぁ可能か不可能かでいえば可能でしょう。
 でも、契約作業にかかる工数は、非常に膨大です。工数見積を作成して、付帯条件作って、利益乗せて、正式な見積書作って、顧客側企業内で稟議通して、発注して。どんなに早くても2~3日はかかるでしょうし、1週間~10日はかかるのがザラ、というのがオレの個人的な感覚です。ところが、スクラムイテレーションは、長くても3週間、短いところでは1週間というところも多いです。1ヶ月のイテレーション期間、というのはオレは今のところ聞いたことが無いので、少なくとも単月契約よりは短いスパンで契約作業が強いられることになります。これをやるのは相当シンドイですよ?


 SIerサイドは契約作業にかかる工数を明示的に顧客に請求したりはしない(「見積は無料」という悪しき文化が定着している)ので、開発工数のいづれかにまぶして請求することになるのでしょう。結果、開発工数は多くなり、費用も高くなる。「アジャイルで開発する費用」として見込んでくれているならいいですが、費用が高くなることを顧客サイドは了承してくれているのかは甚だ疑問ではあります。


スクラムのメリットが失われる

 またもや「顧客のいうアジャイル開発」=「スクラム」という仮説に基づいて弁を進めます。


 以前たしか、原田騎郎さん(「カンバン仕事術」や「ジョイ・インク」「スクラム現場ガイド」らの訳者のお一人)がこんな事をSNSでおっしゃられていたと記憶しています。(ニュアンスが異なっていたり、そもそも発言者が原田さんじゃなかったらスミマセン)


スクラムは開発チームにマーケティングを取り入れるための開発プロセス


 そもそも開発対象にブレが無かったら、ウォーターフォールで開発した方が楽ですし確実です。そうではなく、市場やユーザーのニーズに対応し随時開発の方向を見直す必要があるからこそ、スクラムイテレーションまわして開発する必要があるのです。*2


 イテレーションごとに契約を行うことによるオーバーヘッド増加について前述しましたが、費用だけでなく開発スピードにも弊害が生じます。仮に、イテレーション期間を3週間として設定し、契約手続きに毎回1週間必要だとすると、最低でもイテレーション開始2週間前にはそのイテレーションで開発する対象を確定し、見積を開始する必要があります。結果、実質1ヶ月強も開発対象を変更することが出来ないわけです。前イテレーションで作ったものが気に入らなかったとき、顧客側はどうするつもりなんですかね? SIer側に無理を言って強引にねじ込むのでしょうか? それとも泣く泣く我慢して次の機会を待つのでしょうか?


 また、一括(作成請負)契約にする時点で、顧客側の担当者がどの程度このプロダクトにコミットする気があるのかが気になります。理想としてはプロダクトオーナーとしてフルタイムをプロダクトにコミットするのが望ましいですが、そこまで行かないにせよ、ある程度開発サイド(チーム)と対話しやすい距離にい続けることは非常に重要です。それにも関わらず、開発を発注した時点で要件をすべて伝えた気になり、以降をSIerに任せきりにするつもりなら、そもそもスクラムで開発する意味は皆無でしょう。開発契約を一括にしたい理由が、値段を先に決めたい・社内稟議を通しやすくしたい のであれば、心情的には理解はできますが、単にITに関わる作業を丸投げしたいだけであれば、おまえちょっとチャランポラン過ぎないか、と思わなくも無いです。



客がそもそもアジャイル」が何なのかを分かっていない

 だいたいにおいて、「開発をアジャイルでやりたい」とか言い出す輩ほど、アジャイルのことを何も分かってないケースが多いです。
 そもそもアジャイル開発」などと言うものは存在しません。「アジャイル(agile)」は「俊敏な」「素早い」「小回りのきく」といった意味を示す形容詞であり、「アジャイルな開発」というものはあっても「アジャイル開発」という開発手法や開発プロセスがこの世にあるわけではないです。アジャイルソフトウェア開発宣言(アジャイルマニフェスト)その背後にある12の原則に沿う開発プラクティスがいくつも存在し、それらを総じて「アジャイル」と呼ばれているのに過ぎないのです。
 前述のように「アジャイルスクラム」のイメージを持っていてくれているならまだマシですが、そんなレベルにさえないことが残念ながら大半のようです。


 一年ほど前、「アジャイルがダメだと思う7つの理由」について議論する会というイベントが開催されました。その3年ほど前に鈴木雄介さんが問題提起した「アジャイルがダメだと思う7つの理由」について、もう一度議論してみようというのがイベントの主な目的。


 この会でオレは「6.手段が目的になっている」の議論の場のファシリテーターを担当しました。アジャイルな開発を実施する上で「Don't do Agile, Be Agile.」(アジャイルをしようとするな、アジャイルであれ)という有名な格言があります。この格言の指摘にもあるように「アジャイル開発をすること自体が目的になっていないか?」というのが、この議論の場の主な議題。もっともこのイベントの参加者はアジャイルな開発に熟練しており、さすがに手段と目的を履き違えているような方はお一人もいらっしゃいませんでしたが、一方で面白い話が議論の中心になりました。


 「最近は顧客から『アジャイルで開発してほしい』と言われることが多い


 冒頭のうちの会社の話とまるで同じです。が、でも詳細を聞いていくと、アジャイルで開発してほしいと言ってきた顧客の、実際の要望はまったく違うようです。

 当たり前ですが、開発の本質はアジャイルにしようが何も変わらないので、アジャイルな開発手法に変えても吉野家のごとく旨く早く安く開発対象が出来上がることはありません。普通に考えれば当たり前なんですが、アジャイルという言葉がIT業界に定着した今、ユーザーサイドにはそれがバズワードとして広まり、背びれ尾びれが付いた状態で、まるで魔法かなにかのように認識されているのでしょう。前述のイベントの最後に自分たちの議論の場のまとめを簡単に発表したのですが、まるで童話の「オズの魔法使い」だなと思い、皮肉を交えて以下のように紹介したところ、会場からは大爆笑を頂戴しました。笑い話で済めば幸せだったのですが、残念ながらこれが今のソフトウェア開発の現実のようです。



顧客から「開発をアジャイルで」「でも契約は一括で」と言われた時にすべきこと

 では、SIer側は「開発をアジャイルで」「でも契約は一括で」と顧客に言われた場合、どうすべきでしょうか? オレのたしない頭で3案考えてみました。

1.アジャイルに何を求めるのかを確認する

 要は顧客に「お前の言うアジャイルってなんなんだ?」と確認する、ということです。コストダウンがしたいのか、なんとなくモノをヨロシク作りたいのか、要件があいまいでフワフワした状態から開発を始めたいのか、流行だからなんとなくやってみたいのか。顧客にこんなことを聞くと失注するのでは、と不安に思うのかもしれませんが、そこをあやふやにしたまま契約しても、双方ともに不幸を見るだけです。勇気を持って、まずは要求を明確に確認するところからはじめるべきでしょう。間違っても「アジャイルスクラム でやりたいのね」などと早合点しないように。

2.準委任(SES)契約を勧める

 スクラムで開発することになった場合、納品物を最初に確定する一括(作成請負)契約はとてもリスキーです。契約期間中に数イテレーションを挟めば、最初の要求と異なる成果物になる可能性が十分ありえるからです。であれば、契約物を確定しない準委任(SES・作業請負)契約を勧めるのが望ましいです。準委任契約は成果物を保証しないので、顧客から嫌がられる場合が考えられますが、であればスクラムで開発を諦めるか、選択を迫ってみるべきでしょう。

3.一括契約ながら成果物をあいまいにしておく

 スクラムで開発することは断れない、でも一括契約も避けられない、失注もしたくない。そんなジレンマを抱えた時の最終手段です。開発期間と案件参画人員数を単純に掛け算して工数を算出し、それを元に見積を作成、しかし成果物はなるべく明確に定義しない、という契約にします。一括契約ながら中身は実質準委任契約、みたいな契約にすることを目指したものです。顧客が「値段を先に決めたい・社内稟議を通しやすくしたい」という目的で一括契約を望んでいるのであれば、ある程度実現性はあるのかな、と思います。ただ、成果物があいまいになる都合、開発中に問題が発生して、最悪裁判沙汰になったりした場合には、結構大変なことになりそうな気がします。成果物とは異なる作業エビデンスを随時残しておく必要は出てくるかもしれません。


おわりに

 色々書きましたが、こういうノウハウを持って対処していらっしゃる企業さんはきっといるのでしょう。どこかでそういうのを共有出来る機会*3があるといいんですけどね。


 今オレは現場に出ていて、顧客企業内で働いています。この現場では、一応ウォーターフォールプロセスで開発しているんですが、要求はプロダクトバックログで管理して、都度(3ヶ月単位)でビジネスサイドからの要望を見直して開発対象を決めていたりと、ちょっとスクラムっぽいところもあるんですね。こういうやり方もあるんだなぁと密かに感心してました。
 ちなみに今のオレの契約は準委任……いや、上司からは時間清算って強調されたなぁ、時間に見合った成果物が出せないとすぐリリースされるから、そうならないようにちゃんと働けよと散々釘を刺されました。ハーイ、気をつけマース。


 上記に書いたような内容は、以前SlideShareに資料をあげてますので、良かったらそちらもご覧ください。


*1:来月が暇だとは言ってない

*2:よくある誤解ですが、ウォーターフォール開発とアジャイルな開発は対立しません。ウォーターフォール開発でも、アジャイルな開発の要素はプラクティス単位で取り込むことは全然可能です。開発プロセスに限って言えば、1開発で1つしかプロセスを選択できない、という意味で、ウォーターフォールスクラムは対立はするとは思います。が、スクラムイテレーションをまわしていることがアジャイルな開発ではありませんので、あしからず。

*3:若干ステマです、サーセン

ロジカルシンキングのことを「ロジシン」と呼ぶ営業マンがいた

 ものすっごいロクでもない話なんですが。


 今週火曜だったかな、定時ダッシュして山手線で内輪で開催・運営している社外勉強会に向かっている最中のことです。ちょうど時間は帰宅ラッシュ、社内はかなり混雑しており、オレも吊革で体を支えながらiPhoneでポチポチとソシャゲなんぞをこなしていたんですが、ふと目黒あたりから混雑した車中でも良く通る男性同士の会話が聞こえてきました。ふと声の方に目をやると、いかにも営業マンな男性2人組が、おそらく仕事に関する内容なのでしょう、一方がもう一方に仕事の進め方についてレクチャーしているように見受けられます。その様子はずいぶんと熱を帯びており、周りの混雑もはばからず一生懸命に話していました。


 そんな様子を特に気にも留めず耳にしながら再びiPhoneに目を落としていたのですが、ふとレクチャーする側の営業マンの口から、とても気になる言葉が飛び出してきました。



「だからさ、ロジカルシンキングってのはあの売上表に数字を入れていくためのツールなんだよ!」








 ……………………はぁ?


 一瞬我が耳を疑いました。まさかそんな馬鹿な。でもそれは聞き間違いではありませんでした。その後もレクチャー側の営業マンは同様の内容を繰り返します。聞く側の営業マンも特に訂正もせずにウンウンと熱心に耳を傾けています。挙句の果てには「つまりロジシンをさ!」などと「ロジカルシンキング」という用語を略し始める始末。「ロジシン」なんて略語、聞いたこともねーよオレは!


 やがてオレは品川で電車を降りたので、それ以上その会話を聞くことはありませんんでしたが、精神衛生上それで本当によかったと思っています。




 わざわざ後述するまでもありませんが、「ロジカルシンキング」は「ツール」ではありませんし、ましてや営業上の数字を入れるものでもありません。彼らが使っていた「ロジカルシンキング」という言葉は、明らかに意味が間違っています。Web辞書で調べてみると、以下のように解説されていました。

論理的な考え方と、その技法。

 ― goo国語辞書

ロジカルシンキング(logical thinking)とは、一貫していて筋が通っている考え方、あるいは説明の仕方のことである。

 ― Wikipedia

論理的思考法。物事整理して考え、論理的に筋道立てて、他の人に分かり易く説明する手法。また、その能力のこと。
「スピーディーにスムーズに相手に分かりやすく物事を伝える」こと。コミュニケーション能力を推し量る指標の一つ。

 ― はてなキーワード


 これはあくまで想像に過ぎない(しかも彼らに対してかなり好意的かつ同情的な)んですが、おそらくは彼らの会社もしくは部署で、とあるツールに対し、なぜか「ロジカルシンキング」などという名前をつけてしまったのでしょうね。これが事実であったなら、その命名者のセンスと語彙力は壮絶に残念なものであることは言うまでもありません。かつ、彼らが不勉強で「ロジカルシンキング」という一般ビジネスパーソンにとって割と当たり前(少なくともちょっとWebで調べれば意味が分かる)用語を知らない・他で聞いたことが無いならば、まぁこういったことがあるのかもな、と思いました。思いましたが、彼らが自信満々声高らかにラッシュアワーの山手線で喋った内容が、実は周囲が眉をひそめるようなものであったこと、彼らがビシッと決めたスーツも髪型も胸元のバッヂもすべて台無しにするものであったことは、きっとソッとしておいてあげるべきなんでしょうな。


 さっき上記の記事を読んで、そんなことを思い出しました。ロクに意味も分かってないで横文字使ってる人、非常に多いんでしょうね。オレもこれを他山之石とせず、今後の自戒としたいと思います。だって、あんな格好悪い目に遭うの、オレ絶対にヤだもの!

5/24「AWS Blackbelt Online Seminar Amazon Elastic Compute Cloud (EC2) - Windows」受講レポート

はじめに

 Amazonが配信している「AWS Blackbelt Online Seminar Amazon Elastic Compute Cloud (EC2) - Windows」を受講しました。以下受講メモ。


メモ

Amazon EC2 Windows概要
Amazon Machine Image(AMI)
  • インスタンスとAMI
    • AMI
    • Windows AMI
    • Windows Server 2016 AMIにおける変更点
      • EC2Configサービスが廃止
      • EC2Launchを採用
    • Dockerを利用する場合
      • Base with Container AMIを利用する必要がある
        • 別のAAMIを利用すると正しく起動できない
    • Windows AMIの検索
      • 条件に基づいて検索
        • リージョン
        • OS
        • 32/64bit
        • ルートデバイスタイプ
        • プロバイダ
        • 日本語版はImage Nameに「Japanese」を指定
    • Windows AMIのバージョン
      • いくつかのツールをデフォルトインストール済み
      • MSからの定例パッチを提供後5営業日以内に更新されたWindows AMIを提供
      • Amazon SNSで更新の通知を受信可能
        • 専用の設定が必要
        • 新しくWindows AMIが追加された場合
        • 既存のWindows AMIが削除された場合
インスタンスの設定
  • EC2Configサービスを使用したWindowsインスタンスの設定
    • 2016 Serverには含まれない
    • ユーザーデータの使用
    • Sysprepの実行
  • EC2Launchを使用したWinddowsインスタンスの構成
    • EC2Configを置き換えるもの
      • ほぼ同じことができる
  • ステートマネージャー(SSM Config)を使用したWindowsインスタンスの設定
  • 準仮想化(PV)ドライバの種類
    • 古いドライバ(RedHat PV)が入っていることも
      • 手動で更新が可能
  • Windows OSのアップグレード
    • Windows Server 2016へのアップグレードは未サポート
モニタリング
  • Amazon CloudWatch
    • AWSの各種リソースをモニタリングするサービス
      • メトリクス監視
      • アラーム作成
      • ログ監視
    • CloudWatchへの情報送信
      • ローカル設定ファイル
      • EC2 Systems Manager/ステートマネージャー
  • EC2Rescue
ネットワークとセキュリティ
まとめ
Q&A
  • Visual Studioは使用可能か?
  • 既存インスタンスについては従来通り手動でWindowsパッチを適用する必要があるか?
    • 手動も可能
    • EC2 Systems Managerの設定で自動的用も可能
  • EC2 Systems ManagerでオンプレミスやデスクトップのWindowsに対して操作を行うことが可能か?
    • 可能。エージェントを捜査対象にインストールすることで操作できる
  • Windows Serverに機能制限は?
    • 基本的には無いが、EC2の制限として共有ディスクやマルティディスクには対応できない。

感想

 オレ、Windowsサーバって、これまでの案件でほんの数案件でしか使ったことないんですよねぇ。特に自分がインフラ触るようになってからはLinuxオンリーです。今後もWindowsサーバに触ることはあるのだろうか……?
 それはそれとして、EC2 Systems Managerについてはとても強い関心が持てました。実はAWSではサーバレス構成のプロジェクトでしか開発したことがないので、EC2はまだ触ったことが無いんですが、こういったツールは積極的に活用していきたいです。

5/23「AWS Blackbelt Online Seminar AWS認定試験準備に向けて」受講レポート

はじめに

 Amazonが配信している「AWS Black Belt Online Seminar AWS認定試験準備に向けて」を受講しました。以下受講メモ。


メモ

  • AWS任手プログラム紹介
  • 準備作業の紹介
イントロダクション
  • AWSクラウドの現状を紹介
  • AWS認定
    • エキスパートの証明
    • キャリアアップ
    • 名刺にAWSを貼れる
    • コミュニティ参加
  • AWS認定保持者
    • 高い年棒だよ
    • 技術的な信頼獲得に役立った
    • 同僚から頻繁に相談されるようになった
  • 認定プログラムについて
    • ソリューションアーキテクト
      • DevOpsエンジニア
    • デベロッパ
      • DevOpsエンジニア
    • システムオペレーションアドミニストレーター
      • DevOpsエンジニア
    • それぞれに
      • アソシエイト
      • プロフェッショナル
  • 認定要件
    • 各試験に合格
  • 申込
    • AWSサイトにて
  • 申込後キャンセル
    • 72時間前までなら無料
    • 以降は9000円の手数料発生
  • 持ち物
    • 身分証明書
    • 認証コード
    • NDAの事前確認
  • 試験結果
    • 即時通知
    • 14日以降であれば再受験可能
    • 同じ試験を1年以内に3回受験可能
  • 再認定
    • 2年以内に再認定試験に合格
    • より高いレベルの試験に合格
試験内容について
  • 必要な知識と出題範囲
    • AWSサイトにて確認
    • 必要なAWSの知識
    • 必要なIT全般の知識
  • 出題分野
    • 料金の詳細等変化が頻繁なものは範囲外になりやすい
    • 頻繁に使わない機能は範囲外になりやすい
  • 回答方法
    • 4つ以上の選択肢から設問に最も良くあてはまるものを選択
      • 択一
      • 複数選択(選択数は設問に明記)
試験準備
  • 認定試験の最善の準備は実践的な準備
  • 学習に役立つ準備マテリアル
    1. トレーニングクラスの受講
      • 3日間
      • 21万円
      • 個々のシステム構築
      • ベストプラクティス
      • 身分証明書の持参が必要
    2. 認定試験ガイド・サンプル問題の確認
      • AWSサイトより
        • 先にサンプル問題を読んで、自分の苦手を把握した方がよい
    3. QwikLABS
      • オンライン学習環境
        • クレジットカード登録が必要
        • 一部は無料
    4. AWSホワイトペーパー
      • AWSサイトより
    5. AWS FAQ
      • AWSサイトより
    6. 認定試験準備ワークショップ
      • AWSサイトより
    7. 模擬試験
      • AWSサイトより
      • 回数制限なし
        • 同一の問題が出題される可能性がある
    8. 認定試験
その他リファレンス
  • AWS初心者向け学習リソース
    • オンライン動画
    • AWS製品ページ
      • 特徴
      • 料金
      • 開始方法
    • AWSドキュメント
    • Blog
    • AWSの最新情報
    • AWS Answers
    • AWSサポート ナレッジセンター
    • セミナー
      • 国内のセミナー
      • オンラインセミナー
      • セミナー過去資料
    • イベント
      • AWS re:Invent
      • AWS Summit Tokyo
        • 新サービス発表
        • テクニカルセッション
        • 事例セッション
        • パートナー事例
        • 認定試験の受験も可能
          • 50%ディスカウントクーポン(次回から活用)

感想

 まぁそんなに特筆すべきこともないのですが。
 会社の今期の自身の評価基準に、うっかり「1つ以上のAWS認定資格の合格」を入れてしまったものだから、ぼちぼち(つまり6/末までに)受験しなくちゃいけないんですけど、そういえばちゃんと調べてなかったなぁと思って、ザックリ把握するために受講してみました。いやー、やること多いですね。本当に残り1月で合格できるのか、オレ? 元々あまり資格取得に興味が無いので、正直放置できるなら放置しておきたいところなんですが、そうも言ってられないので、とりあえずトライだけはしてみようかなと思います。


 そういや、今回のオンラインセミナーは女性の方が講師でした。今まですべて男性だったから珍しいですね、内容も技術者向けバリバリって感じでもないので、営業さんだったりとかしたのかしら?

Amazon AthenaでCloudFrontログを解析しようとしたらエラく苦労した話

 この2日間、さんざん悩んだので、メモメモ。


 Amazon AthenaはS3に格納したログファイルとかを、まるでRDBのようにSQLで検索・分析できる、いわゆるサーバレスなサービスです。
このAmazon Athenaで、S3→CloudFront経由でダウンロードしたファイルのアクセス数をカウントするような簡単な分析を行いたい、というのが今回の要件。CloudFrontはS3にgzip形式(拡張子:「.gz」)でアクセスログを吐くので、こいつを無加工(gzipを回答したりファイル群を結合したりせずに)で検索できるあたりがAmazon Athenaとても便利なところです。


 Amazon Athenaは割と最近リリースされたばかり(「AWS re:Invent 2016」で発表)なので、社内に知見もなく、Webの記事を参考に構築を試みました。……がこれがどエラい苦労しました。


 参考にすべきものがあって何故苦労したか? これじゃまともに動かなかったからです。各記事のテーブル作成SQLでテーブルを作ると、なぜかログファイルのレコード行が空白で取り込まれ、ヘッダー行が1カラム目がやはり取り込まれない状況でした。


 結論から言うと、以下のSQLで正しくテーブル作成ができました。カラム名を「` (アポストロフィ)」で囲む必要があったのです。今回はSQLを直接エディタに書くのではなく、コンソールからチマチマ入力してテーブルを作った際、このSQL文が生成されたことで違いに気づけました。

CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_log (
  `date` date,
  `time` string,
  `x_edge_location` string,
  `sc_bytes` int,
  `c_ip` string,
  `cs_method` string,
  `cs_host` string,
  `cs_uri_stem` string,
  `sc_status` int,
  `cs_referer` string,
  `cs_user_agent` string,
  `cs_uri_query` string,
  `cs_cookie` string,
  `x_edge_result_type` string,
  `x_edge_request_id` string,
  `x_host_header` string,
  `cs_protocol` string,
  `cs_bytes` int,
  `time_taken` int,
  `x_forwarded_for` string,
  `ssl_protocol` string,
  `ssl_cipher` string,
  `x_edge_response_result_type` string,
  `cs_protocol_version` string 
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES (
  'serialization.format' = '	',
  'field.delim' = '	'
) LOCATION 's3://sample-cloudfront-log/logs/'
TBLPROPERTIES ('has_encrypted_data'='false')

※S3バケット名は記事記述用のでたらめなものです。ご注意あれ。



 参考にした記事らは以下。参照した記事のうちのほんの一部です。


 これらの記事の内容が間違っていた、とはオレは思いません。何故なら、同時期に書かれた記事で同じようなSQL文が書かれており、実際に検証した結果の画面スクリーンショットも張り付けられていたからです。
 おそらくは、かなり直近……おそらく昨日今日のレベルで、Amazon Athenaで仕様変更があったんじゃないでしょうか? 詳細は分かりませんが、今後突然CloudFrontログ分析がAmazon Athenaで行えないケースが増えそうな気がしたので、自分用のメモを公開しておきます。


※何か誤りあればご指摘頂けますと大変助かります。

「AWS Black Belt Online Seminar AWS for Game Developers」受講レポート

はじめに

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

メモ

講師
  • 畑 史彦さん
ゲームの進化とゲーム開発
  • ゲームの進化
  • 複雑化・高度化・大型化するゲーム開発
    • プラットフォームの多様化
    • クオリティ上昇=コスト上昇
    • マルチプレイヤーゲーム
    • ユーザーのエンゲージメントを高める仕組みが必要
    • 開発プロジェクトの大規模化
Amazon Lumberyard
  • Cloudとccrowdの力を活用しAWSとTwitchを深く統合させた無料のAAAゲームプラットフォーム
  • AWSと非常に深く統合
  • 共通のネットワーク接続を簡単に作成
  • 新しい・素晴らしい体験
    • 手続き的なゲームプレイ
    • 人工知能
    • 多くのプレイヤー
  • クライアント - エンジンプラットフォーム
  • Lumberyard Editorの基本機能
    • 基本的なゲーム開発に必要なものは大体そろってる
  • レンダリング
    • 非常にきれいなレンダリングを実現可能
    • HDRサポート
    • 物理ベースシェーダー
    • ダイナミックライティング
    • etc...
  • モバイルサポート
  • VR
    • サポート
      • OCulus
      • Vive
      • OSVR
      • PSVR
    • エディタからのインスタントVRプレビュー
    • モジュラーVRフレームワーク
    • 360度ビデオ再生
  • ワークフロー
    • Windowsエディター
    • 新しいComponent Entity Sysytemが非エンジニアに新しい権限を
    • C++, Lua Visual Scripting
    • etc...
  • New IDE
  • Component Entities
  • Gem
    • Lumberyardのゲームプロジェクトをっ拡張するためのコードやアセットが含まれているパッケージ
    • 現在Lumberyardには、すぐ利用できる26のgemが用意されている
  • Modular Gemシステム
    • ゲームプロジェクト間でコードとアートアセットを共有するための管理インフラストラクチャ
    • プロジェクトのコンテンツの追加と削除が容易にできる
      • コアエンジン部分は必要なテクノロジーのみに
  • UI Editer
  • GridMate
  • CloudCanvas
    • クラウドリソースを利用したゲーム機能を構築・管理
      • クラウドセーブ
      • ニュースティッカー
      • リーダーボード
      • アチーブメント
      • キャラクター状態保存
      • etc...
    • バックエンド経験がほとんどないエンジニアでも構築可能
      • ニュースフィードなど
    • ビジュアルスクリプティングIFを搭載
    • Lumberyardとセットで簡単に利用可能
    • CloudCamvasから利用するAWSリソース
    • Lumberyardとっクラウドの間を糊付けするような役割
    • Cloud Canvasリソースマネージャーで管理
      • AWSリソースを定義
      • スタックを生成
      • ローカル作業
      • 使用しているAWSリソースを維持
      • 安全なリソース使用
  • Cloud Gem Framework
    • 1人のエンジニアが30分でクラウドコネクティッドなオンライゲーム機能を構築可能
    • Cloud Gems
      • クラウドコネクティッドなオンラインゲーム機能を提供するGem
        • デイリーメッセージ
        • リーダーボード
        • 動的コンテンツ配信
        • ユーザーアカウント認証
    • Cloud Gem Portalでチームの誰もがCloud Gemで作成された機能を管理できる
      • Cloud Gemを管理するためのGUIポータル
      • 実態はS3に配置された静的コンテンツとLambda・Amazon API Gatewayからなるサーバレスアプリケーション
  • Lumberyard IDE
    • システム要件
    • 料金
      • 無料
      • Cloud Canvasなどの利用時に使用料が発生
    • ライセンス
      • Not Opensource
        • 修正・改修は可能
        • 外部公開は不可能
      • AWWSで代替できるような外部のサービスには利用不可
Amazon GameLift
  • セッションベースのマルチプレイヤーゲーム専用のゲームサーバ管理サービス
    • 設計
    • プロトタイプ構築
    • 本番環境構築(複数回)
    • スケーリングに関わるたちの悪い問題
    • UIダッシュボード構築
    • リリース
    • 24/365保守
    • コストの最適化作業
  • ビルドとフリート
  • 開発者のワークフロー
  • 開発環境
    • AWSアカウント
    • Lumberyardのゲーム
    • ネットワーク
  • 開発ステップ
    • 4ステップで実現可能
  • デプロイ
    • プレイヤーから透過的
    • 進行中にゲームプレイに影響しない
    • Alias
      • フリートによりプレイヤーの乳流を制限
  • セッション管理
    • 稼働している世界中のゲームサーバーを継続的にスキャンし、プレイヤーからのゲーム参加リクエストをマッチング
  • リアルタイムで情報を把握
  • 世界展開
    • 9リージョンから配信可能
  • オートスケーリング
    • ルールベース
    • リアルタイムな利用可能量に基づく調整
  • 利用料金
    • 従量課金
  • 採用事例
    • STREAM LINE
      • Proletariat Inc.開発
  • Unreal Engine,Unityを含むすべてのC++/C#ゲームエンジンをサポート
  • Amazon GameLisft Local
Twitch
  • ソーシャルビデオプラットフォーム・コミュニティ
  • 新しいゲームプレイ体験を提供
    • 視聴者がゲームに参加
      • チャットコマンド
      • 配信者からの招待
      • ゲーム画面にゲーム状況をオーバーレイ
amazon.com
  • ECサイトと連携し販売プラットフォームを提供
    • Amaozn.com
    • Androidアプリストア
まとめ
  • ゲーム開発者向けのEnd-to-Endソリューション
  • インフラ管理に労力を割くのではなく、コンテンツ制作とゲーム制作に注力できる

感想

 オレ自身、ゲームを開発したことはないですし、その予定もないのですが、今回はAWSの提供サービスをざっくり把握することを目的に聴講しました。聞いている限りでは、確かにインフラに関わる部分をかなり省力化できそうな印象を受けました。ソーシャルゲームなんかは当たり外れが大きいので、オンプレで1からやるよりはこういうプラットフォームを開発・運営に活用するのは良さそうですね。グランブルーファンタジーのような超大規模ソーシャルゲームは、クラウドだと調整しきれないのでオンプレで運営しているという資料を読んだことがありますが、あそこまで大規模になるかどうかはリリースしてみないと分からないでしょうし、まぁ別物と考えていいんじゃなかなと思います。


 さて、それじゃあオレは四象降臨(グラブルのイベント)に戻るかな。