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」ってなに？ | 株式会社ユーティル
私自身はエバンジェリストでも何でもないのですが色々なコミュニティやイベント（≒アウトプット活動）の場を通して自社や自分自身を知って行って頂けたら良いなと考えております。ちなみに、この言葉に関連するイベントとして直近、以下のイベントに参加します。
結果、色々なアウトプット活動のプロセスを踏んでいる中で「評価」に繋がっていけば最高だなぁ、、と。（いう妄想でした）
本題に戻り、イベント後の飲み会でのお話を含め、改めて情シスとしてどうやっていくべきかという良い指針になりました、開催してくださった運営の皆様、有難う御座いました！
Kubernetes（AKS）をやさしく学ぶ旅 その3
ちょっとグダってました・・・・。
3連休、PC周りに触れたかったのですがなんだかんだでグダってしまい、寝落ちを3連発してました・・・・かろうじて日曜日、お昼に下記のイベントに参加したのですが、ブログにアウトプットできる程の文字起こしができなさそうなので頭の中にこっそりしまっておきます。笑
everyone-cyber-security.connpass.com
＊イベントとしては多角的なセキュリティのLTを聞けたので楽しかったです！
話は変わり Kubernetes の本題に（～アプリケーションの実行まで）
どんな切り口でAKSに入ればよいだろうとウロウロしていると下記のサイトを発見しました。
Azure Kubernetes Service (AKS) のドキュメント - チュートリアル、API リファレンス | Microsoft Docs
まずは、「5分間のクイック スタート」部分にて。今回は「Azure Portal」を利用することにします。（スクリーンショットは細かいものではなくざっくりとです）
説明に沿ってこんな感じで作成します。ひとまず、ノードサイズはテスト的なものなので「Standard B2s」のお安いものにしました。ノード数も今回は「1」で。その後に「次: スケール > 」を押下します。「スケール」ではそのままを維持して「次: 認証 > 」を押下します。
「認証」はこんな感じで。（表示された設定のまま）
以降の設定もそのまま進んで検証に成功するとクラスターを作成できます。デプロイが開始して私の環境では10分程かかりました。ちなみに、AKSの利用料金に関しては下記を参照下さいませ。
価格 - Container Service | Microsoft Azure
リソース移動後の詳細はこんな感じです。ここからはクラスターへの接続を行いますが、Azure Cloud Shell を利用します。
ポータル画面上部の検索ボックス右にある中のアイコンをクリックします。
私の場合は初回利用だったこともあり、ストレージアカウントの作成を求められました。
完了するとこんな感じです。ここからが実践になります。kubectlを構成するには「az aks get-credentials」コマンドを使用します。リソースグループ「resgr」の私の環境下では下記のコマンドです。
az aks get-credentials --resource-group resgr --name myAKSCluster
「Merged ～～」のようなメッセージがリターンされればOKです。その後にクラスターへの接続を確認する際は「kubectl get nodes」を入力します。
Azure:/ Merged "myAKSCluster" as current context in /home/xxxxxxxx/.kube/configr Azure:/ NAME STATUS ROLES AGE VERSION aks-agentpool-19xxxx23-0 Ready agent 24m v1.13.10 Azure:/
このような感じで入力したコマンドはクリアされ、リターンの結果表示されます。ここまででクラスターへの接続確認が取れたので続いてアプリケーションの実行を行います。接続確認が取れたパスにて説明の通りYAMLファイルを作成します。作成後は「kubectl apply」コマンドを使用してアプリケーションをデプロイします。
viで作成したファイル名 ➡ azure-vote.yaml
実行コマンド ➡ kubectl apply -f azure-vote.yaml
deployment.apps/azure-vote-back created.yaml service/azure-vote-back created deployment.apps/azure-vote-front created service/azure-vote-front created
アプリケーションの実行後は Kubernets サービスにとって（サンプル）アプリケーション フロント エンドがインターネットに公開される形になります。状況監視は下記のコマンドで確認可能です。（Ctrl + C にてブレイク可能）
kubectl get service azure-vote-front --watch
Azure:/ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE azure-vote-front LoadBalancer 10.0.243.139 52.243.36.91 80:32401/TCP 6m45s ＊本来は「EXTERNAL-IP」部分は Pending から遷移します
「EXTERNAL-IP」が開放され、自PCのブラウザで確認してみると？
デプロイされたアプリケーションが表示されます！勿論、ボタンを押下してカウントされ、リセットも動作します。
おまけ（Azure Monitor での正常性の監視とログ）
前述のクラスター作成時にコンテナーに対する Azure Monitor が有効になっている状態です。監視機能に関しては説明を確認する限りでは AKS クラスターとクラスター上で動作するポッドの両方の正常性メトリックを提供してくれるとのことです。ちなみに、クラスターやポッドの概念に関しては既に上げている記事を振り返り下さいませ。
こんな感じの その1 です。
こんな感じの その2 です。
こんな感じの その3 です。
「azure-vote-front」コンテナーに対するログを確認したい場合は上記のような形で確認可能です。と、色々と閲覧することが可能です。
ちなみに、今回サクッとアプリケーションがデプロイできたのは既に準備されたコンテナー イメージを利用した為です。YAMLファイルでそれを指定しており、サクッとできたように見えただけです。笑
今回の「Kubernetes（AKS）をやさしく学ぶ旅 その3」では感覚を掴む為に前述リンクのクイックスタートを利用しました。次回以降はステップバイステップに進みつつ、その先は応用にスライドしていければイイな、と思います。
忘れずに検証のクラスターは削除！
今回の検証したクラスターはクラスターこそ課金対象ではないものの付随する各種リソースが課金対象の為、忘れずに削除するようにします。（自環境では10分少々で削除されました）
az aks delete --resource-group resgr myAKSCluster --no-wait
Azure:/ PS Azure:\> az aks delete --resource-group resgr --name myAKSCluster --no-wait Are you sure you want to perform this operation? (y/n): y Azure:/ PS Azure:\>
＊関連するすべてのリソースも削除されます
ご利用は計画的に・・・・。
追記（Appendix）
2019/09/22
この記事のあとに「その4」と「その5」を上げたのですが、ステップバイステップの手順「4」で詰まってしまった為、混乱の元となるので記事は 2019/09/22 2:20 頃におろしました。「その4」に☆を付けて下さった皆様、申し訳ありません・・・・。
「その4」の Appendix にも記載したのですが、クラスター作成時に「--node-vm-size」オプションを付加しないと割と良いVMになってしまうようで。私の場合は1日放置してお布施が跳ね上がりました。泣
結果、詰まった上にお布施だけ払う結果になってしまいました！（また、別の形で検証はしようと思います。。）
TGS 2019 に参加しました
久々の TGS 2019 でした
現職はゲームとは無縁な会社なのですが、とある会社様にご訪問頂いた際にゲーム関連の話で盛り上がり、かつ、以前ゲーム会社に勤めていたことからビジネスデーのチケットを1枚お譲り頂きました。感謝です！（6年ぶり？）
見どころは？
実のところをいいますと2時間弱しか居ることができなかったため、基調講演を少々とブースを少々と知り合いの方とのコミュニケーションであっという間に完了してしまいました。。涙
基調講演 5Gインパクト～5Gによって“ゲームチェンジ”は起こるか？
多少のメモは書き起こしていたのですが 4gamer にまとまった記事が上がっていたのでそちらを拝見しました。笑
「5G」というキーワードで盛り上がるこの業界ですがいきなり設備等々が揃って開始されるというよりは徐々に徐々に、、という感じのようです。ただ、いずれは本格普及してゲーム業界に対する強いインパクトを与えるキーワードになりそうで楽しみで！
ブース見学
ブースは必ずしも「ゲーム」一色というイメージではなくIntelやマウスコンピューター、レノボ等、ゲームには関連するけどゲームそのものをウリにしていない企業も多く出展していました。ただ、目立って何か会社に持ち帰れそうなネタは収穫できなかったので残念です。
ざっと回った写真館
短い時間で（個人的に）気になったスポットをいくらか・・・・。
『FF7リメイク』で盛り上がっていたスクエニブースのモーグリちゃん。開場1時間後でフォトスポット70分待ち、試遊60分待ちの大盛況でした。
人混みを隠している関係で下部の雰囲気が分かりにくく申し訳ありませんが、人だかりができていました！「7」といえばPSでガッツリとプレイしたのと映像作品になってから少し見たくらいで時が止まってた為、トレーラーの映像には驚愕しました。笑
『Vジャンプ』、26年前の5月からずっと続いているのですね、しみじみ。実は小さい頃この1号を持っていて将来プレミアがつくと思って取っておこう！と思いましたが、親にあっさりと捨てられました。あの時は泣いたなぁ、、と。
ちなみに、これが令和の『Vジャンプ』。（反射しててスミマセン）
と、殆ど時間がなかった為、多少の思い出に浸りつつ会場を後にした TGS 2019 でした。次に行くときは1日ゆっくり回りたいものです・・・・。
