MOTEX DAYS 2019 ユーザー事例発表会に登壇させて頂きました
かれこれ 3～4 ヶ月前のこと
MOTEX社様と打ち合わせをする機会がありまして、打ち合わせの中で登壇のご依頼を頂きました。弊社を担当して下さった営業さんは実は前職でも担当して下さってた経緯もあり、そんなこんなの縁での依頼でした。縁って大事ですね。
去年頃に同じ依頼を受けていたら実はお断りしていたかもしれません・・・・が、今年はこのブログでのアウトプットを始めとして、「色々なことに挑戦したい！」と決めた年だったので依頼を受けました。
資料作成～当日登壇前
資料作成自体はMOTEX社様が流れのテンプレートを作成して下さってたので叩き版自体、割と早いタイミングで完成しておりました。社内で数度レビューした後に実際に修正の上、模擬プレゼンも数度行いました。ちなみに、持ち時間は20分だったのですが、一度目の練習は25～30分近くかかってしまってました。笑
当日も付き添ってくれた上司の方と数度模擬練習を行った上で最終的には20分ちょっとまで縮んだのであとは本番で微調整しながら、という感じで臨みました。
当日の行きは品川まで新幹線だったのですが、乗った車両でまさかのライバル会社の宣伝が！しかし、今日の藤原君は応援するかのような視線を送ってくれているようにも見えました。（100.1%違う）
ココが事例発表会が開催された品川インターシティホール。ドキドキ。しているうちにリハーサルが始まり、基調講演が始まりと自分自身の出番が近づいてきました。。
登壇（本番）
予定通り、持ち時間20分を頂いてスタート。ほぼほぼ予定通りの流れで本筋の話とおまけ的な話も出来ました。聴講してくださった方はMOTEX社様の社員の方々も合わせて50人程でした。冒頭でもお話したのですが他のセッションが割と注目のキーワードだった中、当セッションにお越し頂き、誠に有難う御座いました！
初登壇でよかったこと・悪かったこと
よかったこと
・発表時間が予定通りの20分程で完了できたこと（ほぼニアだったかと）
・原稿らしい原稿は用意せず、練習通り、自然体で話せたこと。
・初志貫徹で決めたこと（極力技術寄りにならず平易に話すこと）を実践できた
悪かったこと
・作成したパワポが自社テンプレートでフォント埋め込みだったことを忘れていたこと。結果、大きなズレはなかったものの失態です。。
・プラスして一部のスライドのオブジェクトが大幅にズレていたこと。結果、登壇前に修正できたので良かったですが、振り返ればPC持ち込みにすれば解決した気がします。
・途中咳払いしてしまった、後半少し声が枯れてしまった。
➡ちゃんと水分を取っておくべきでした・・・・。
とまぁ、あっという間に発表は終わり、その後のセッションを拝聴しMOTEX社様と懇親を深めつつ、帰路につくのでした。ちなみに、以前のブログ記事で記載した3つのポイント（セキュリティの重要性を伝える・同業者の方と繋がる・コミュ障を克服する）は大方達成できたのかなと思うので満足です！
御礼
まずは今回の会がMOTEX社様の力なくしては開催されなかったこと、このようなイベントで登壇させて頂きまして、誠に有難う御座います。また、会が行われる中でお会いしたことのある社員の方々とコミュニケーションを取ることができて非常に嬉しかったです。
続きまして、前述もさせて頂いておりますがセッションに足を運んでくださいました皆様。拙い点が多々ありお聞き苦しかったとは思いますが、最後までご静聴頂きまして有難う御座いました！
最後におまけのような感じではありますが、午後帯一杯、終始おつきあい頂いた弊社の上司の方にも心から感謝しております。
Next LanScope？
事例発表の場には立たせて頂いたのですが、弊社もまだまだ LanScope Cat を活用してやりたいことが多々あります。スライドにも盛り込んでいたライセンス管理・セキュリティパッチ適用の平準化・MDM・Cylance Protect などなど。
LanScope An を利用していることもあり、MDM強化のため、「Syncpit」は導入したいなと考えております。ビジネスチャットの普及も後押ししていると思います。
また、マルウェア対策を強固にするため、CylancePROTECT の導入も考えたいです。特別講演で拝聴しましたが、他社の有名な製品と比べても見劣りしない、むしろ、（ほぼ）完全無欠の状態に引き上げることができます。
製品自体への「愛」を含めて社内のセキュリティレベルを上昇させたいです！！！！！
Kubernetes（AKS）をやさしく学ぶ旅 その6
まだまだつかめない Kubernetes の世界。。
その1～その5まで紹介してきている Kubernetes ですが、まだまだ、色々と理解しきれていないところがあります。そこで、今回は Pod についてもう少し掘り下げてみようと思います！
Pod とは
以前の記事で Pod の大まかな部分は記述していますが、設計思想を含め、Pod はどう扱っていくのが最適なのかの細かな話はできていません。
コンテナーの世界では「1コンテナーで1プロセス」という鉄則があるようで、シンプルな機能をもつアプリケーションにすることが理想とされています。ただし、Web - Proxy、SSL、OAuth等、メインコンテナーに付随する1つのまとまりになったコンテナーを作るのが便利なようです。Kubernetes では関連するコンテナーの集合体を Pod と呼びます。また、Podの特性を下記に記載します。
・アプリケーションのスケールアウトは Pod 単位
・Pod 内のコンテナーはネットワークとストレージを共有
Pod のデザインパターン
Pod をどのように設計していくかは作成するアプリケーションの機能・非機能要件によります。
・同一 Node で実行する必要があるか？
・同じタイミングでスケールする必要があるか？
プロキシの役割をするコンテナー
元は HTTP にしか対応していない Web アプリケーションを HTTPS に対応させる場合です。
上記のケースの場合、SSL Proxy Container から本来の HTTP Web Application に対しては http://localhost/ でアクセスできるので既存の Web Application のコードに対して変更は不要になります。
認証処理を行うコンテナー
Web Application が OAuth 認証を必要とする場合は Web Application 本体とは分離して認証処理の Pod を配置する必要があります。
上記2例は以上にして、注意点があります。それは Kubernetes のデプロイの最小単位は Pod だということです。アプリケーションを今後拡張していく上で将来的にどうスケールしたいかがデザインパターンを決定する上で重要になります。Web Application において前段のフロントとバックのビジネスロジックは必ずしもスケールのタイミングが一緒ではない（可能性が高い）ため、Pod は別管理にした方が望ましくなります。
Pod のその他もろもろ
Node のスケジューリングも学ぼうと思ったのですが、ボリュームも非常に多いため、こちらでは割愛致します。ちなみに、ざっくりとした概略等は前回の その5 で記載しております。
ReplicaSet について学ぼう（ハンズオン前まで）
クラスターに複数の Pod をデプロイする、ということで Kubernetes のコンセプトである自己修復機能を実現するための ReplicaSet について学びます。
ReplicaSet はクラスター内で動作させる Pod の数を設定した数字で維持する仕組みです。Node 障害で Pod が停止した際には ReplicaSet を使用し自動的に新しい Pod を立ち上げます。
ハンズオンは その7 にして、少々短いですが今回はここまでとします！
DevRel/Beginners #6 に参加しました
DevRel とは？
10/11（金）に関連セミナーに参加しました。当セミナーの主催者はMOONGIFTさんという方、実は業務中にも色々と参考にさせて頂いていたWebページの管理者の方だったので驚きでした。笑
話を戻し DevRel ですが一言でいうと Developer Relations で自社製品やサービスと開発者の良好な関係性を築くためのマーケティング施策となります。
セミナーで得た気付き メモ編
内容が盛り沢山（＋ワークショップ）だったので抜粋して記載致します。
なぜ、DevRel というものが存在するのか？というのは「認知度の向上を目指す」これに尽きます。マインドシェアを上げ、自社製品（またはサービス）を土俵に上げてもらうことが重要です。
その上でなぜ開発者にリーチするのか？という点に関しては「調査するのが面倒だから」これに尽きます。開発者は広告を嫌う傾向があるようでリテラシーも高いです。そうとなると、直接開発者に知ってもらう機会が必要になります。かつ、ソーシャルやブログ保有率が高いこともあり、情報の拡散を狙える一面もあります。
しかし、DevRel の活動を行う上で注意する点もあります。それは「すぐに効果が出ない」ということです。あくまでも中長期的な戦略として実施する必要があり、その先の KGI / KPI は明確に定めておく必要があります。（ただし、KPI は水増ししないものを。）
ちなみに、DevRel 界隈にも超有名な方がいらっしゃって「ガイ・カワサキ」さん（元Appleのエバンジェリスト）は講演して頂くとなるとその額もスゴいんだとか。それ程、DevRel の開発者に向けての影響度というのは重要なのでしょう。
ちなみに、DevRel を行う目的としては「採用に繋げるためのもの」か「自社製品を良く見せるか」で大分され、日本で前者の企業として有名なところでは DeNA や クックパッドがあげられます。これに関してはどちらが良い悪いというのはないようです。
日本でも（特に）大きな企業から広まりつつある DevRel ですが海外は本質でもあるマーケティングが進んでいるというところもあり、日本はこれから追いついていくといったイメージでした。ただ、日本も決して遅れているわけではなくコミュニティ形成他進んでいる部分もあるそうです。ちなみに、海外の事例はそのまま日本では使えないので日本風なアレンジが必要とのことでした。
セミナーで得た気付き 実践編
セミナーは座学だけでなくところどころワークショップのようなものが入りました。中には時間の関係上、割愛されてしまったものもありましたが、実際の DevRel 活動に役立ちそうなものが多かったのでセミナー資料を元に後程振り返りたいと思います。
自社の DevRel は直接収益型？間接収益型？
下記ページが参考になります。
DevRelの取り組みを分ける三つの価値 | DEVREL - 開発者向けマーケティング支援サービス -
自社製品のターゲットは国内・世界どちら？
それぞれのターゲットの違い、人的・市場的なものを理解していますか？それぞれのターゲットに向けた戦略は用意されていますか？というものでした。
また、自社分析をする上で有名な SWOT 分析をするのはオススメとのことでした。
DevRelにおける戦略の立て方、考え方 | DEVREL - 開発者向けマーケティング支援サービス -
上記ページはセミナーで習ったことの多くのエッセンスが詰まっているので是非是非閲覧した方が良いと思います！
セミナーで得た気付き その他編
DevRel の施策の決定
ローリスクでハイリターンの追求が必要だそうです。かつ、時間のかかる施策はなるべく予算をかけずに続けるのが重要とのこと。登録したらプレゼント系に関しては一時的にユーザを惹きつけるものの、その後が続かないのでオススメしませんという話でした。ココはキモであり、難しそうです・・・・。
ブログは Q & A 記事で書くのがオススメ
これは話を聞いて納得しました。言われてみると自分自身も眺めるブログ記事の大半は Q & A 記事で、かつ、結論にいかに早く辿り着けるものに惹かれる傾向があります。
セミナーに参加して結局自分はどうするのか？
まだまだ、DevRel 初心者ということもあり、何から手をつければ良いのか、というところではありますが、「もっと自社製品を多くの人に知ってほしい」・「もっと自社のことをより多くの人に知ってほしい」という気持ちは強まりました。現職はまだ2年半ということもあり、まずは自社をもっと勉強した上で施策を練って行かなければなぁと感じます。
今年は connpass を始めとしたセミナー参加、事例発表会の登壇等、外部の方との交流が増えた一年でした（まだあと2ヶ月くらいありますが）が少しずつ自社・自分自身を知っていって頂き本格的な DevRel 活動に繋げていきたいと思う所存です。m(_ _)m
Kubernetes（AKS）をやさしく学ぶ旅 その5
今回はハンズオンなしです
前回、割とガッツリなハンズオンだったので今回は要点を押さえた座学？形式でまとめようと思います。
Kubernetes の仕組みを覚える為の用語たち
スケジューリングとディスカバリー
スケジューリング
アプリケーションを適切なところにデプロイする仕組みで個別の要件に合わせたものをマニフェストファイルで定義しクラスター内サーバーに（独自アルゴリズムで）デプロイする。
サービスディスカバリー
デプロイされたアプリケーションがどこにあるかを見つけだす仕組み。Kubernetes とセットのキーワードで良く挙げられる「マイクロサービス」型のアプリケーションでは小さな機能を提供する多数のサービスで組み合わされシステムを作る。その際のサービス間のやり取りを担う。サービスディスカバリーの種類としては「固定IPアドレス」や「構成レジストリ」が挙げられる。
Kubernetesのサーバー構成
Master
Kubernetes のクラスター全体を管理する役割を担う。Master は etcd と呼ばれる分散キーバリューストア（KVS）を使ってクラスターの構成情報を管理している。
Node
コンテナーアプリケーションを動作させるサーバー群。通常は Node を複数用意して、クラスターを構成する。クラウドでは仮想マシン（VM）インスタンスが Node になることが一般的。
と、ここまでをまとめるとこんな感じです。
図のように Master の API がクラスター全体を制御します。
Kubernetes のコンポーネントたち
Master
API Server
Kubernetes のリソース情報を管理するためのフロントエンドの REST API。各コンポーネントからリソース情報を受け取り、データストアである etcd に格納する役目を持っている。他のコンポーネントは etcd の情報に API Server を介してアクセスし、開発者／システム管理者がこの API Server にアクセスする際には kubectl コマンドを利用する。
Scheduler
Pod をどの Node で動かすかを制御するためのバックエンドコンポーネント。前回のその4 計5つの Pod をクラスターで動作させましたが、Kubernetes 内部では Scheduler によって Pod の配置先を割り当てていました。
Controller Manager
Controller Manager は Kubernetes クラスターの状態を監視し、あるべき状態の維持に努めるバックエンドコンポーネント。
データストア（etcd）
Kubernetes クラスターの構成を保持する分散KVS。Key - Value型でデータを管理する。マニフェストの内容が保存されるイメージを持つとよい。
Node
Kubelet
Node では kubelet というエージェントが動作しており、Pod の定義ファイルに従ってコンテナーを実行したりストレージをマウントしたりする機能を持つ。
kube-proxy
さまざまな中継、変換を行うネットワークプロキシ。
Kubernetes のリソースたち
アプリケーションの実行
Pod
Kubernetesでは複数のコンテナーをまとめて Pod という単位として管理する。Pod は Kubernetes においてアプリケーションのデプロイの単位となり、Pod の単位で作成や開始、停止や削除などを行う。
ReplicaSet
ReplicaSetはクラスター内で指定された Pod を起動しておく仕組み。起動中の Pod を監視し、何かしらの理由で停止してしまった場合に該当の Pod を削除し新たな Pod を起動するようにする。
Deployment
アプリケーションの配布単位を管理するもの。Deployment は ReplicaSet の履歴を持ち、Pod 内のコンテナーのバージョンアップを行いたい時に停止することなくローリングアップデートできる。また、ロールバック（1つ前の世代に戻す）もできる。
DaemonSet
ReplicaSet で Pod を配置する際には Node の選択ができないものの、「各 Node に Pod を1つずつ配置する」といった場合には DaemonSet で要件を叶える。
StatefulSet
基本的にコンテナーアプリケーションはステートレスであるが、データベースなど永続データと連携する場合は状態を保持する必要がある。その際に利用するのが StatefulSet。
ネットワークの管理
Service
Kubernetes クラスター内で起動した Pod に対してアクセスするときは Service を定義する。
Ingress
クラスター外部のネットワークからアクセスを受け付けるためのオブジェクト。
アプリケーション設定情報の管理
ConfigMap
アプリケーションの設定情報や構成ファイル等の固有識別情報を Pod から参照できる仕組み。
Secrets
ConfigMap と同様に構成情報をコンテナーアプリケーションに渡すものだが、DBに接続するときのパスワード他、秘匿性の高い情報を管理するときに利用。
バッチジョブの管理
Job
1つまたは複数の Pod で処理されるバッチ的なジョブ。
CronJob
決まったタイミングで繰り返す Job の実行に使われるリソース。
マニフェストファイル
Kubernetes は宣言的設定を行うときにマニフェストファイルを使用します。
マニフェストファイルの基本
Kubernetes ではクラスター内で動かすコンテナーアプリケーションやネットワークの設定、バッチ実行するジョブなどのリソースを作成します。リソースの具体的な設定情報はファイルで管理しておりそのファイルがマニフェストファイルです。（YAML形式）
ちなみに、マニフェストファイルをクラスターに登録する際は kubectl コマンドを利用します。
$ kubectl apply -f webserver.yaml
クライアントから受け取った命令をベースに Kubernetes Master の API Server が構成情報である etcd に書き込みます。ちなみに、クラスターから削除する場合は その4 でも実行しておりますが下記のコマンドで実現できます。
$ kubectl delete -f webserver.yaml
ちなみに、マニフェストファイルの書き方は下記が参考になります。
YAML はインデントでデータの階層構造を表すのでインデントが正常な形式でないとエラーになるので注意しましょう！私はそこで少しはまりました。。
その他、、
他にも Pod の管理に最適なラベル設定やリソースをまとめて仮想的に分離する Namespace という機能がありますがこれ以上書くと長くなってしまうので今回は割愛します・・・・。
Kubernetes（AKS）をやさしく学ぶ旅 その4
読了した本を参考にハンズオンしてみました
以前、記事に掲載していた可能性もありますが、下記本の Chapter 02 にて環境準備を実施しその後、クラスターを作成していることが前提です。
xxx > az aks create --name AKSCluster --resource-group AKSCluster --node-count 3 --node-vm-size Standard_DS1_v2 --generate-ssh-keys --service-principal 5b2eaf2e-XXXX-4304-XXXX-16XXXX1dXXXX --client-secret XXXX7bef-c468-XXXX-827d-bc2XXXX7XXXX （略） xxx > kubectl get node NAME STATUS ROLES AGE VERSION aks-nodepool1-11226562-0 Ready agent 8m4s v1.13.10 aks-nodepool1-11226562-1 Ready agent 8m6s v1.13.10 aks-nodepool1-11226562-2 Ready agent 8m1s v1.13.10
また、クラスター作成前に ACR（Azure Container Registry） にサンプルWebアプリケーションをデプロイしています。この時点では Kubernetes クラスターではアプリケーションが何も動いていない状態です。
アプリケーションのデプロイをするには？
デプロイの基本的な流れを把握する為、以下3点を実施する必要があります。
（1）マニフェストファイルの作成
（2）クラスターでのリソース作成
（3）アプリケーションの動作確認
マニフェストファイルの作成
Kubernetesではクラスターにどのようにアプリケーションをデプロイするか、またユーザからのアクセスがあった際にどう処理するかをマニフェストファイルという設定ファイルに定義します。JSONまたはYAML形式で定義可能ですが可読性の面からもYAML形式が推奨されています。中身は省略しますが、サンプルでは自環境のACR名に合わせてYAMLファイルを編集しました。
クラスターでのリソース作成
作成したマニフェストファイルをもとに、Kubernetesクラスター上にアプリケーションをデプロイして動かしてみるところまでやります。前提条件の振り返りですが、クラスター作成自に「Standard_DS1_v2」サイズにてノードを3つ作成しております。ここでPodの状態を確認してみます。Podは「コンテナアプリケーション」の集合体でこの旅の その1 で図解にて解説しております。
xxx > kubectl get pod No resources found.
アプリケーションをデプロイしていないため、このような表示になります。そこで前述のYAMLファイルを apply すると？
xxx > kubectl apply -f .\tutorial-deployment.yaml deployment.apps/photoview-deployment created xxx > kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES photoview-deployment-79448db46b-7f44h 1/1 Running 0 3m34s 10.244.1.3 aks-nodepool1-11226562-0photoview-deployment-79448db46b-c7hrq 1/1 Running 0 3m34s 10.244.2.3 aks-nodepool1-11226562-2 photoview-deployment-79448db46b-l54sg 1/1 Running 0 3m34s 10.244.0.8 aks-nodepool1-11226562-1 photoview-deployment-79448db46b-pwzzj 1/1 Running 0 3m34s 10.244.0.7 aks-nodepool1-11226562-1 photoview-deployment-79448db46b-zcbjw 1/1 Running 0 3m34s 10.244.2.2 aks-nodepool1-11226562-2
状態に変化がありました。5つのPodが稼働状態ということが分かります。ただ、ここまでの状態ではクラスター外のネットワークからはアクセスできない為、もう1つのYAMLファイルを apply します。
xxx > kubectl apply -f .\tutorial-service.yaml service/webserver created
アプリケーションの動作確認
2つ目のYAMLファイルの apply を経て Service の公開が成されるため、アクセスのアドレスをこの時点で確認できます。
xxx > kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.0.0.1443/TCP 98m webserver LoadBalancer 10.0.86.185 40.115.159.202 80:32429/TCP 8m44s
イメージとしては下記のようになります。既に（1）と（2）は割愛している前提です。
ブラウザで確認してみると・・・・。
無事、アクセスできました！ロードバランサで割り振られ、「10.240.0.5」にアクセスしているようです。ちなみに前述の図を見るとアクセスできるPodは5つあります。F5で更新していくと・・・・。
同一のグローバルIPにアクセスしているにも関わらず、別のところにもアクセスしていることを確認できました。そんなこんなで確認が完了したのでリソース削除して今回は完了とします。
xxx > kubectl delete -f .\tutorial-service.yaml service "webserver" deleted xxx > kubectl delete -f .\tutorial-deployment.yaml deployment.apps "photoview-deployment" deleted
これを実施することにより、クラスターが空の状態になります。もちろんですが、Webアクセスしようとしてもアクセスできません。
以上です！
【雑記】凱旋門賞で日本馬が頂点に立てるか！？
凱旋門賞ってどんなレース？
総賞金 6億5,000万円 （1着賞金 約3億7,000万円）という世界でも超有名なビッグレースです。私は小さい頃からダビスタの影響で競馬が好きというのもありますが、大人になる今の今まで日本馬が勝ったという例がありません。。
過去に日本馬で最高位の2着に食い込んだのは記憶に新しいオルフェーブル（2回）・ナカヤマフェスタ・エルコンドルパサーです。日本を代表する名馬達が何度も挑み続け敗戦してしまっているのが凱旋門賞、それ程、勝利するのは厳しいものがあります。
今年は日本馬3頭が挑戦！
と、いつもはITネタをメインに書いておりますが、競馬が趣味ということもあり、日本馬3頭の挑戦も兼ねて記事にしてみました。
フィエールマン
日本馬3頭の中でも最有力候補の1頭。父親は凱旋門賞にも挑戦したことのあるディープインパクト。去年に菊花賞・今年に天皇賞（春）を勝利しており、スタミナに関しては文句なし。安定度も高く展開さえ向けば・・・・というところか。
キセキ
名前からして奇跡を起こす可能性があるとしたらこの馬？直前では6番人気。逃げて粘る競馬が持ち味だが、チャンスを獲得するならいっそ大逃げを打つか！？
ブラストワンピース
フィエールマンが一番注目されているものの、個人的にはこの馬に一番期待しています。前走の札幌記念（GII）でもフィエールマンを負かしており、ポカさえ起きなければ実は潜在能力はヒケを取らない1頭。過去の戦績を見ても1着か4着以下のどちらかであり、まさかを起こすのはこの1頭なのではないかと・・・・。
見どころは？
フォルスストレート（偽の直線）と呼ばれる下り坂であたかも直線のように感じてしまう偽の直線がコースの特色です。歴戦の騎手達は把握済なのですが、馬が体感的にどう感じるか、というところがポイントです。
ロンシャン競馬場芝2400m 凱旋門賞 詳しいコース特徴 | 競馬場 特徴分析 傾向 攻略法レポート
そして、日本馬3頭に立ちはだかるのは現在凱旋門賞を2連覇している世界最強馬といっても過言ではないエネイブルです。
過去に1戦のみ負けておりますが、それ以外は全て勝利。日本の国際競走であるジャパンカップには参戦していないですが、国際レーティングから見ても現時点では世界最強馬（かつ牝馬）でしょう。3連覇を目指す今回も単勝は1倍台であり、絶対視されております。
ブラストワンピースが一番チャンスがあると前述しておりますが、父親であるハービンジャーは欧州の大きいレースを勝利しており、ブラストワンピース自体も力のいる馬場を得意としていることもあるので筆頭格に上げております。
さぁ、夢を見ようでないか！
そんなこんなで凱旋門賞はあともう少し、日本時間 10/6（日）23:05 頃に発走予定です。何度も何度も挑戦し苦杯を味わった日本馬が1着で駆け抜ける瞬間を見れるのは今日が最初で最後かも！？
追記（Appendix）
2019/10/06
残念ながら今年も日本馬は頂点に立てず！エネイブルの3連覇も成らずでした。勝ったのはヴァルトガイスト。単勝で40倍程度ついていたので完全なる伏兵、といった感じでしょうか。重馬場でいつも以上に力が必要だったということもあり、まさかの逆転劇が起きたのかなと感じます。
日本馬の最先着はキセキの7着。ブラストワンピースとフィエールマンは11着と12着でした。壁はやはり厚いですが、いつかは日本馬が1着で駆け抜ける瞬間に立ち会いたいです。。
MSDN サブスクリプションで Azure のクレジットを有効化する
皆さん、特典を忘れていませんか！
MSDN に限った話ではないのですが、製品には特典がついていることってありませんか？しかも、特典がついているのを有効期限が過ぎてからハッと思い出すとか。。
Visual Studio の MSDN を購入するとエディションにもよりますが、Professional の場合は月で \6,000 分、Azure のクレジットが付加されます。以降で記載する手順は Business Center で会社のドメインの関連付けが完了しており、サブスクライバーを登録した後の話のみなので前提条件が完了していない場合はそこまで進行ください。
その手順
組織でサブスクライバーの登録を実施すると上記のようなメールが飛んでくるので「サブスクリプションにアクセスする」を押下します。その後はマイクロソフトアカウント等を入力し進むと「my.visualstudio.com」の個人ポータルに入ることができます。
［Benefits］（言語による）をクリックし Azure の［Activate］をクリック。
必要項目を入力していきますが、「アグリーメント」の2つ目のチェックに関してはつけなくても先に進むことが可能です。
処理が完了するとメールが飛んでくるので Azure にサインインします。
上記のようにサインインできて \6,000 のクレジット残があることを確認できます。ただし、あくまでも開発用のサブスクリプションなので本番用としては利用できません！詳しくは前述のリンクのページ下部「知っておく必要のある制限は他にありますか？」をご参照ください。
追記（Appendix）
2019/11/04
当記事の Azure クレジットの有効化は10月頭に行った記憶なのですが、本日該当のサブスクリプションを確認したところまたリセットされて \6,000 の残になっていました。
タスクマネージャーの画面表示が止まってしまった場合の対応
みんな大好き？タスクマネージャーが。。
おそらく、エンジニアの10人に7人くらいは起動しているであろうタスクマネージャーが止まってしまった（ように見える）時の対応です。かれこれ、数ヶ月、私のPCでは下記のような画面表示で止まってしまっていました。
だからといって、PCが不調なわけでもなく何でもない状態だったのですが気になり少し調べたところ、今回の私と同じ症状の場合はすぐに治るようです。
対処法
原因の1つとしては［表示］➡［更新の頻度］で「一時停止」になっていることが考えられます。これを「通常」にしてみましょう。
すると？
無事、動き出しました！ここ数ヶ月悶々としていたことがたった数分で解決しました。笑
ちなみに、スクリーンショットを撮ったタイミングがマチマチなのでメモリの使用量が繋がっていないのはご了承くださいませ。
Microsoft Azure Training Day: Fundamentals に参加しました（＋受験しました）
どんなイベントだったか？
connpass経由で知ったイベントで、AZ-900 の講座にバウチャー付で受講できるということで即飛びつきました！ちなみに、今後も定期的に実施されるみたいです。マイクロソフトさんとしてはこれを皮切りに Azure を利用してくれる企業（人）が広がってくれることと、上位資格を受験してくれることを願ってこんな太っ腹なイベントを開催してくれているのかなと。（に違いない！）
東京方面の直近の開催は確認できる限り、10/23（水）が最短なようです。別途、更新はされるかもしれませんのでご確認下さいませ。
AZ-900 の位置づけは？どんな試験？
Azure の中でも入門資格であり、エンジニアの方ならずとも受験されている資格のようです。
Exam AZ-900: Microsoft Azure Fundamentals
Azure ならずとも、他のパブリッククラウド（AWS・GCP）を利用する上でも共通として習得しておきたい知識も当資格で吸収できます。ただ、それは全体の1.5～2割程度でそれ以外は Azure に関する知識と考えておいた方が良いです。
ちなみに、CBT（PC受験）形式です。現状では44問を60分で解答するというのがベーシックみたいです。難易度としては入門資格なので優しい方だと思います！
勉強法は？
基本的には事前に Azure のサブスクリプションを取得して触っておくと当イベントの話がスムーズに入ってくると思います。逆に触ってなかったり事前知識がないとスムーズに入ってこない、、かもしれません。ただ、サブスクリプションを取得していなくても Microsoft Learn で事前予習しておけばある程度のところまでいけます。
Azure の基礎ラーニング パス - Learn | Microsoft Docs
このモジュール自体が AZ-900 向けなので、この中身を一通り理解していれば合格へのラインがグンと近くなります。ちなみに私の場合は6末頃に Azure のサブスクリプションを取得してから少しずつ触っていました。体系だった形で受講して知識にしたかったのもあり、年内には当試験を受験しようと考えていました。
今回のイベントに関しては、後程の受験でもOKですし、当日合格する自信があればそのまま受験してもOK（ただし人数に限りあり？）でした。
当日受験の結果は？今後は？
700点が合格点で86X点（最後の1桁は忘れました。笑）だったと思います。朝からぶっ続けで受講した上での受験なので体力的に中々厳しいですが知識が新鮮なうちに受験できるという意味では大きいかなと。
本当は11月頃に受験予定で合格は早まったので上位資格をどうしようか考えつつ、関連する事項をブログへアウトプットできれば理想です。
あとは、会社自体（パブリッククラウド活用なし。。）のクラウド人口を、当イベントの布教も兼ねて広めていきたいです。
これに続くロゴを貼っていきたい・・・・。笑
追記（Appendix）
2019/09/30
当イベントの狙いと思われる記事を先日発見しましたので共有致します。
デジタル人材・組織の育成を社内外で進めるマイクロソフトの狙い - ZDNet Japan
社内外問わず、人材・組織の育成を図るようです。その取り組みの一環として「Microsoft Learn」も取り上げられていました。
【Azure Studies その13】Microsoft Learnをはじめてみる（最終更新日：2019-08-25） - SE（しがないエンジニア）のブログ
情シスはどう評価されるのが理想か？
昨日（9/21）に情シスのイベントに参加
connpass では「ある技術」に対してのもくもくや勉強会等は多いのですが、「ある職種」にフォーカスをあてたイベントが少なめ（自分が知らないだけ？）な中、自分自身が担当している「情シス」に関してのイベントに参加しました！（＠浅草）
ちなみに、同じコミュニティの過去イベントで「情シス」の実態をとてもよくまとめて下さっている方がいらっしゃったのでそちらのリンクも貼ります。
全然関係ないネタですが先日始めた「ドラクエウォーク」で浅草を散歩するとおみやげがGETできます、初ゲットでした。笑
LTがメインで進行
LTが4本立てという構成がメインで進みました。お題は「俺の、私の自慢話聞いて！労ってもらえない情シスに拍手を！」です。このタイトルから既に賛同してしまう感。
司会進行されていたしのもりさんがトップバッターでした。今、巷でホットなRPAの話です。オチはここに書いてしまうとアレなので書かないですがRPAは万能ではない！というところから始まり、ただ、使いどころを間違わなければ絶大な効果を発揮する、という内容でした。結末はいかに・・・・自社の場合でもRPAを導入したいという流れは少しずつ起きてはいるものの結果、プログラムやロジックを書くのは私（一人）になりそうで。ある企業さんによっては情シスは導入のPMで率いてプログラムはユーザ部門が書くという例もありました。まさしく理想です。
RPAの導入・運用の注意点｜よくある失敗例・改善ポイントを解説！｜ITトレンド
続いては hikky さん、お題に沿った感じで「メチャクチャな要望を乗り越えたけどそれを評価してほしい！」という内容でした。hikkyさんが今まで経験したフィクションな内容が並べられてましたが、割と過激な内容が多くて会場に和やか（？）な笑いが発生していました。よく界隈で聞くブラックな話に似通ったものだったので「こんなことも世の中あるんやなぁ（遠い目）」という感じで聞いていました。それに比べたら自社は色々とホワイティーに感じました。。:-)
情シスあるある 障害対応編：情報システム部門のリアル：エンジニアライフ
3番手は _john_doe_ さん、情シスのチームビルディングのお話でした。小規模だった企業が急成長した際にありがちな「整理のできていない状況」をどう乗り切るかということで参考になる意見が多かったです。Redmineで要望管理をしたりするところは自社にも似通ったところがあって親近感が湧きました。Redmine（に限らずプロジェクト管理ツール）は試行錯誤の連続ですが上手く運用に乗ればオープンソースですし本当に費用対効果の高いツールだと思います。
4番手はイチロヲさんでした。なぜか、情シスの勉強会だったのに営業をやっているという異色？の方でした。会場の配信がNGだったこともあり詳しい内容は記載できないのですがとにかくプレゼン上手でした。LTをされた4名の方全員に共通していたのですが皆さんプレゼン能力に非常に長けており、羨ましい限りでした。
LTを受けてのグループディスカッション（私自身の意見も兼ねて）
4本のLTを受けた後のディスカッションはほぼフリートークだったので本日のお題に沿った形で「情シスはどう評価されるのが理想か？」という内容で盛り上がりました。
・情シスは明確にこれができたら、という基準が無く評価が難しい。
➡実際に評価できている会社さんもあるのかもしれないですが、対応している業務も広すぎてどこを評価すれば良いのか、という評価軸を定めるのが難しい。
・IPA他、有名な団体が評価の大まかなガイドラインを示してくれていると嬉しい。
➡結局は自社にフィットした形に落とし込む必要があるのですが、有名な団体が情報を発信していると説得力はとても高いので・・・・。
・明確な成果物というコミットメントというよりは仕事一つ一つの結果に対するプロセスを重要視してほしい
➡ベンダー利用している企業の場合はそのベンダー折衝でどう成功に導いたか、とか。転職の際にも「ベンダーとの折衝経験」が求められたりするのがその1つなのかなと思います。
➡ヘルプデスク業務における人とのコミュニケーション（≒信頼関係）やそのナレッジの蓄積もそれに該当すると思います。
➡他、挙げたらキリがないですが、やっている業務が幅広い分成果物のコミットメントよりはそのプロセスを重視した方が良いのかと。（とはいえ「コスト削減」や「○○導入」等、ゴールが明確なものもあるのでそのバランスは難しいですが。。）
・やはり、給与ややりがいを含めて本人のモチベーションに繋がるのが理想。
振り返っての個人的な活動 etc...
2019年からではありますが、情シスをやっている身として活動の方針を（割と大幅に）変えてみました。ちなみに、Twitter でフォローしている方で Qiita にとてもためになる良記事を挙げて下さっている方がいらっしゃるので共有しておきます。
ブログでアウトプットするようになった
3月頃から開始しました。理由としては情報INするばかりでOUTする場を持たなかった為です。割と話題にはなっていると思いますが「東大○○」シリーズ（作文も読書も読了しました）でもアウトプットは推奨されています。純粋にTipsを分かりやすく共有したいところもありますが、その分かりやすくは情シスをやっている身としては仕事にも繋がるところがあるので良い循環かなと思ってます。ひとまず、100記事アップが目標です。
技術書（技術書以外も）を割と読み漁るようになった
ライフスタイルの変化もあり、技術書を読む時間は大分減ってしまったのですが変化を言い訳にするとこれからのエンジニアとしての人生に危機感が芽生えてしまうので読むのをボチボチ再開し始めました。会社のお昼休みはボッチなことが多いので自席で Kindle を使って読むことが多いです。ちなみに、最後の5分はほぼ毎日睡眠をとるように心がけています。これは下記の本を参考にしています。
ただ、技術書もINしただけでなく1点目に挙げたようなOUTをしてこそ自分自身の身になると思います。（「読んで満足」ではなくて）
Twitter・LinkedIn・connpass
今回のイベントも connpass で知ったのですが、やはりSNSで情報をキャッチアップしていかないと新しい情報も拾い切れません。
➡言わずと知れたSNS。気になる方々をフォローさせて頂き、最新の技術情報他をキャッチアップするようにしています。クソリプも含めて楽しんでいます。
・LinkedIn https://www.linkedin.com/
➡転職のイメージが強いSNSではありますが、私の場合はビジネスの動向を把握するようにしたり、イベント情報がないかをキャッチアップするようにしています。
・connpass https://connpass.com/
➡セミナーに参加する場合は基本このサイトを利用しています。他にも幾つかあるとは思いますが使い勝手もよく良質なセミナー（グループ）が多い気がするので。
登壇（LT含む）・DevRel
登壇（LT含む）
前述の Qiita の記事にも書かれているのですが登壇活動はアウトプットの中でもかなり効果の高いものなのかなと思います。受け手にリアルタイムに聞いて頂くことを始めとし、かつ、資料を作成する過程は受け手のことを考えつつ自分自身の知識の整理にもなります。以前のブログの記事でも上げておりますが第一弾としてMOTEX様の事例発表会を10月に控えております。
コミュ障なところもあり、こういう機会を得るのには今まで消極的だったところもあるのですが、今後のエンジニア人生を楽しむ為にも今後は（もっと知識を付けてですが）積極的に参加するようにしたいと思います！
DevRel
今回の「評価」というところにも繋がるような活動として何をしていこうかと思い、今悩み考えているのがこの「DevRel」です。少々古めの記事ですが下記のサイトが参考になります。
最近よく聞く「DevRel」ってなに？ | 株式会社ユーティル
私自身はエバンジェリストでも何でもないのですが色々なコミュニティやイベント（≒アウトプット活動）の場を通して自社や自分自身を知って行って頂けたら良いなと考えております。ちなみに、この言葉に関連するイベントとして直近、以下のイベントに参加します。
結果、色々なアウトプット活動のプロセスを踏んでいる中で「評価」に繋がっていけば最高だなぁ、、と。（いう妄想でした）
本題に戻り、イベント後の飲み会でのお話を含め、改めて情シスとしてどうやっていくべきかという良い指針になりました、開催してくださった運営の皆様、有難う御座いました！
