CloudNative Days Tokyo 2021 の事前収録を終えた - 宣伝と収録方法のふりかえり

先週、CloudNative Days Tokyo 2021 での発表の、事前収録を終えました。宣伝と収録方法のふりかえりがトピックです

CNDT2021

こんな発表をする予定です

event.cloudnativedays.jp

CNDT2021 では発表形式を複数選択 (会場で登壇、オンラインでライブ、事前録画) 可能だったが、事前収録を希望して 先週の木曜日に撮り終えました。


次のようなスライドを用意しています。一部紹介。

f:id:hiboma:20211024113140p:plain

f:id:hiboma:20211024113135p:plain

f:id:hiboma:20211024113125p:plain

f:id:hiboma:20211024113130p:plain

イベント後に全スライドと動画を公開する予定でいております。まずは CNDT で見てほしいですね !


SRE の取り組みが広がった影響か、障害対応や緊急時のオペレーションに題材をフォーカスして書かれたブログをよく見かけるようになったなぁと思います。

私の発表は GMO ペパボでのインシデント対応 (障害・セキュリティインシデントを含む) の事例紹介です。

  • インシデントマネジメントの必要性
  • slack bot を使ってコミュニケーションを支援する
  • インシデント対応の専門家のモデルやプラクティスを学ぶ
  • エンジニアリングと両輪でマネジメントを実施し組織文化をつくいく

という話を盛り込みました。また、CNDT 後に このブログで詳細を取り上げたいと思います。

発表の録画/録音

事前収録は KeynoteiMovie で行いました。

Keynote でナレーションを録音

Keynoteプレゼンテーションを記録する で、スライドと合わせてナレーションを録音しました。

support.apple.com

こんな機能あるの、いままで全然知らなかった!

iMovie で音声と尺を調整

Keynote で録ったあとに iMovie に取り込んで、オーディオを補正してノイズを抑えたり、声が聞きやすい音質を変えてみたりしました。

support.apple.com

Keynote で録った段階では、何も喋らない「間」を少し長めに余裕をもっていれて喋りました。ただ、全体を通して聞くとリズムが悪いなと思ったところも多かったので iMovie でクリップ編集して無言部分を切り詰めも行いました。便利! クリップ編集のおかげで、40分の時間制限にぴったり納めることもできました。

ところどころ噛んだりした箇所はあったけど、締め切りギリギリだったのでアフレコまではやりませんでした。iMovie の操作は、特に難しい手続きもなく助かりました。

その他のツールは検討しなかったか?

OBS, Zoom , mmhmm といったツールで顔を出して録画もできたと思います。ただ、今回は 締め切りに間に合わせたい + 音声だけにしておいて事後の編集がしやすい方式にしました。別の機会でチャレンジしたいですね!

録音機器

人気のマイクを使いました。

今回の CNDT2021 にも、いろいろ使う機会があるだろうと思って買ったのでした。 toruby でもオススメしてもらっていた。

何度も試行錯誤していくうちに録り方のコツがわかってきて、ノイズが載りにくいセッティングを理解できました。ただ、喋りの技術が未熟なので まだ いろいろいらん音が入ってる箇所はあるのはすんません。

感想

ライブでの喋りは得意ではないので、事前にナレーションの原稿も用意して、収録後の編集も可能やり方は 自分にはあっているやり方だなと思いました。細かいところを気にし出して補正や調整に時間がかかりがちなのは少し面倒ではありますが、ライブで一発勝負で失敗するよりはいいなぁ。

SREcon21: Brent Chapman さんの発表 『Evolution of Incident Management at Slack』でインシデントマネジメントを学ぶ

調べ物中に Brent Chapman さんが発表した『SREcon21 - Evolution of Incident Management at Slack』という動画をみつけた

SREcon21 - Evolution of Incident Management at Slack

タイトルのスクリーンショットです

f:id:hiboma:20211018110209p:plain

YouTube 視聴のリンクは ↓ です

www.youtube.com


Slack 社での障害事例から導入して、インシデント対応のビジョン、トレーニング方法、いろんなシチュエーションでのインシデント対応の戦略/戦術、なんかを説いてる感じ。自動化だとかの技術的なアプローチの話はなかったです。

f:id:hiboma:20211018111301p:plain

インシデントマネジメントを 3つに分解して考えるモデルが参考になりました。COVID-19 下についても触れていて今時な話題もあります。


発表者は Brent Chapman という方で、インシデント対応に関する PDF を公開している

Incident Command for IT: What We’ve Learned from the Fire Department

f:id:hiboma:20211017163424p:plain

消防隊から学んだことを、IT 系企業のインシデント対応に活かすという内容で、ちょっとした tips やコミュニケーションのプラクティス、はてはマネジメント〜組織文化論まで ぎっちりつまった素晴らしい内容だ。

GMOペパボのインシデント対応でも、ここから学んだことを取りいている。

Brent Chapman さん の経歴

greatcircle.com

改めて経歴を調べ直してみました。

ブレントチャップマンは、緊急事態管理の専門家であり、ITインフラストラクチャとサイト信頼性エンジニアリング(SRE)の強力なバックグラウンドから働き、緊急事態に備えて緊急事態から学ぶように組織を指導しています。

ブレントは、Googleの伝説的なSRE組織のリーダーとして、上級管理職に会社のインシデント管理慣行を強化および標準化する必要性を確信させ、現在会社全体で使用されているGoogleでのインシデント管理(IMAG)システムを作成しました。彼はまた、会社が大小の事件から学ぶために使用するGoogleでの事後分析(PMAG)システムの改良を支援しました。

Googleの伝説的なSRE組織のリーダー !!! SRE 本にも載っているような Google のインシデント周りの話は、この方が作り上げたものんだろうかな?


ブレントは、元航空捜索救助パイロットおよびインシデントコマンダー、主要なアート&ミュージックフェスティバルおよびイベントの緊急ディスパッチャーおよびディスパッチスーパーバイザー、コミュニティ緊急対応チーム(CERT)のメンバーおよびインストラクターとして、ITにおける彼の仕事に独自の視点をもたらします。 。

こういう経歴があって IT 系企業のインシデントに手法や方法論を持ち込んだのかなぁ


ブレントはそのキャリアを通じて、初期の新興企業からGoogleAppleNetflixなどの巨人まで、あらゆるものに対応するITインフラストラクチャとチームを設計、構築、管理、拡張してきました。彼は、高く評価されているO'Reillyの著書Building Internet Firewallsの共著者であり、広く使用されているオープンソースソフトウェアの開発者であり、世界中の会議で人気のある講演者です。 彼は、シリコンバレーと世界中の数十の組織、およびさまざまな非営利団体や政府機関と協力してきました。

(プロフィール分は https://greatcircle.com/ のプロフィールを Google 翻訳したものです )


別サイトのプロフィールでは、 marjordomo の開発者であるとも載っていた。wikipedia で確認すると たしかにお名前が載っている! Perl !

ja.wikipedia.org

LKML 読むときにお世話になってるよなと思った

突然の宣伝

CNDT2021 では GMO ペパボのインシデント対応について話をする予定です (*1)

event.cloudnativedays.jp

『Incident Command for IT: What We’ve Learned from the Fire Department』 も引き合いに出すスライドを作成中です

f:id:hiboma:20211019102608p:plain

こんな話も盛り込む 🚒 🔥

f:id:hiboma:20211019102643p:plain


*1) 実は事前録画を提出する締め切り間際。このエントリを書きつつスライドと動画を準備している

キャリアドリフトと IT エンジニア

キャリアの話です


関連エントリ

<キャリア> に絡めたて 先に二つのエントリを書いていた

hiboma.hatenadiary.jp

hiboma.hatenadiary.jp


キャリアドリフト という理論があるので、 (Web系の) IT エンジニアとを絡めて小さいエントリを書いてみます

キャリアドリフト

「キャリアドリフト」とは、自分のキャリアについて大きな方向づけさえできていれば、人生の節目ごとに次のステップをしっかりとデザインするだけでいい、節目と節目の間は偶然の出会いや予期せぬ出来事をチャンスとして柔軟に受け止めるために、あえて状況に“流されるまま”でいることも必要だという考え方を言います。

ドリフト(drift)とは「漂流する」という意味。キャリアドリフトは、神戸大学大学院の金井壽宏教授が提唱するキャリア理論のひとつで、同教授によると職業人生はキャリアデザインとキャリアドリフトの繰り返しであると考えられます。

キャリアドリフトとは - コトバンク


自分の本業である (Web 系の ) IT エンジニアのスコープだけで絞って考えると、 技術の趨勢によって <ドリフト> を余儀なくされることがあるな〜と。いったいどんなものに流されるだろうか?


ぼちぼち思いつくものを書き下す。どうまとめたらいいか分からなくて、粒度がバラバラで混ぜこぜだがご了承を

  • 言語の趨勢
    • 盛り上がりを見せる言語、人気が薄れていく言語
      • 最近は Rust とか Wasm の盛り上がりがすごいね
      • 「〇〇言語の人気がなくなった」は 炎上しそうなので書かない
  • フレームワークの趨勢
  • OS の進化
  • ハードウェアの進化
    • CPU、メモリ、ハードディスク、
  • インフラ技術や運用技術の変化
  • 新しいライブラリ・ソフトウェア・ミドルウェア
    • Apache httpd が Nginx にとって変わったような
    • NoSQL
  • 適用する技術の拡大
  • セキュリティ
  • 新しいプラクティスの登場 / 常識化
    • TDD , IaC, CI/CD
    • DevOpS, DevSecOps
  • 新しいプロトコルの登場
  • ソフトウェアのバージョンアップ
    • 古いのが使えない -> 新しいの使う / 機能が増えたり変わってたり
  • コモディティ化
    • 求められるレベルが底上げされる
  • 技術コミュニティの趨勢

他どういったものがあるか


「〇〇 技術が得意です」「△△のエキスパート・専門家」をキャリアンカー (キャリアの錨、拠り所) としていても、技術の変化次第でアンカーごと押し流されてしまうようなこともあるだろう


<キャリアドリフト> を起こす変化とまではいかなくとも、「キャッチアップするために勉強せざるをえなくなった」「変化に対応するために新しいスキルを身につけた」... とった小さな波に揺られる経験は、技術者をやっていると必ず通過するのではないか


突出した技術者であれば、自らの作り出したもの (ソフトウェア、ハードウェア、手法・プラクティス ... ) で他人をドリフトさせている側に回っている人もあろうかと思う (例: 「〇〇 のコミッタです」「〇〇 を作ってます」 ) 。とはいえ、そういった人であっても全てをコントロールすることは叶わず、周縁の技術に関しては、ドリフトを余儀無くされそうだ


キャリアドリフトについては もうちょいと言語化したいが、ここまで

toruby 174回に参加しました

toruby.connpass.com

( チャリできた! の写真を撮り忘れました )


ポジションペーパーでは、自転車の話と DTM / DTW 環境整えている話をしました。

ギター/ベースを PC につなげるんだと iRig ってメーカー製品があると seki さんに教えていただいた。小さくて持ち運びも便利そう。


前は各自のポジションペーパーで終わり。後半は、Nokogiri で Web サイトの HTML をスクレイピングするのを みんなでポチポチしました。

評価制度での主張を図形的なモデル化で考える

会社の評価制度と 私のアプローチの話です。


tech.pepabo.com

tech.pepabo.com

hr.pepabo.com

ペパボの評価制度では

  • 作り上げる力
  • 先を見通す力
  • 影響を広げる力

の三つの力 = 人材要件に対して、等級要件に則して専門性を主張する必要がある。 だいぶはしょった説明なので、詳細はリンク先を見て欲しい。


実際にやってると ロジカルに評価を組み立てて「私は 〇〇 の力を発揮して 〇級にふさわしい 」と主張を展開するのは 毎度のこと 苦戦する。

評価資料においては、ただ単に issue や Pull Request を列挙するだけでは足りず、その取り組みにどのような背景があって、どのような技術的なアプローチをとり、どのような成果/評価にいたったかも書き下して、評価者に向けて専門性を主張していかないといけない。

ある種の論文みたいなもんだと例えることもできる


「会社、事業部、チーム、あるいは、時間やプロジェクト ... 等の種々のコンテキストがあって、自分を実績をどのようにコンテキストに位置付けて論じるか」 で 苦労する同僚は多い。私も苦手なんだが。


これ、いきなりやってもうまくできなくて、ちょいとした認知の訓練が必要も感じる。

どうやって訓練するか ... いろんなアプローチがあろうが、私の婆は図形的なモデルとして捉えることで 思考がすっきりする。改めて どういう風にモデルにできそうかなぁと 思索してみた


ツリーで考えるモデル

f:id:hiboma:20211001113716p:plain

  • 大きなものを小さなものにブレイクダウンする
  • 小さなものを大きなものにビルドアップする

OKR ツリー や 会社の目標 -> 事業部の目標 -> チームの目標 -> 個人の目標 に位置付けて考える

包含で考えるモデル

f:id:hiboma:20211001115221p:plain

  • 背景やコンテキストを捉える
  • 小さなとりくみと、背景の大きなコンテキスト

ツリーで考えるのと似たところがあるかな?

グラフで考えるモデル

f:id:hiboma:20211001113646p:plain

ツリーとは違い階層をもたないグラフ

「〇〇が△△に影響を与えた」 (影響を広げる力)

時間軸で考えるモデル (1)

f:id:hiboma:20211001113703p:plain

時間軸で捉えるモデル

  • 現在 -> 未来 に位置付ける
  • 有効期限、締め切り をもつもの

「プロジェクトを完遂させる」「次の期にやること」 (作り上げる力、先を見通す力 )

時間軸でモデル (2) 増大・減衰

時間の経過で変化するモデル

f:id:hiboma:20211001115035p:plain

「〇〇の取り組みが未来に価値を出していく」「未来に向けて不確実性が増す」 (先を見通す力)

f:id:hiboma:20211001115023p:plain

逆に減衰するモデル。「〇〇 の取り組みが未来に向けて △△を減らしていく」とか? コストや技術的負債の話と絡めて。

サイクルで考えるモデル

f:id:hiboma:20211001113735p:plain

  • 繰り返すもの
  • プロセスとしてサイクルするもの

CI/CD, DevSecOps サイクル、スクラムスプンリントサイクル ...


その他 いろんなモデル化があろうが、思い使いないので ここで終わり。

「こんなのもあるんじゃない?」があったらフィードバックしてください〜

バウンダリーレスキャリアと IT エンジニア

技術者とキャリアの話です

イントロ

キャリアに関する書籍を掘り出して読み返している中で、 バウンダリーレスキャリア という単語が目に留まる

この著作から引用する

マイケル・アーサーは、変わりつつある新しいキャリアのあり方を「インテリジェント・キャリア」もしくは「バウンダリーレス(境界なき)・キャリア」 - 職務、組織、仕事と家庭、産業の壁を越えて動くキャリア ー と読んでいる

『働くひとのためのキャリア・デザイン』 P.52 から引用

別の説明も引用する

バウンダリーレス・キャリアとは、ひとつの組織の中だけでキャリアが展開される従来の組織キャリアに対して、1つの企業や職務といった境界(バウンダリー)に閉ざされた範囲を超えてキャリアが構築されるものと考えます。バウンダリーレス・キャリアを歩む個人は、異なる企業や業種の境界を横断しながら、新たなスキルや経験、ノウハウを獲得し、自律的に成長を重ねていきます

【人材育成】組織内キャリアマネジメント(2)|コンサルタントコラム|人事評価制度の構築、評価者研修、運用コンサルティング │ ブレインパートナー


さて、自分や同僚の姿でもって この単語を咀嚼してみよう。( Web に関係する ) IT エンジニアにとっては バウンダリーレスキャリアの考えは、特に珍しくもないのかなとも思う。

例えば

  • 会社で開発しつつ、OSS 開発にもコミットして技術を磨く・発揮している
    • 会社に限らず、大学や研究機関なども含まれるかな?
    • 会社に所属しつつ、OSS 開発者としてのフルコミットを本流のキャリアとしている方もいらっしゃらるな
    • 国の境界を超えての活躍もあろ
  • ブログ、勉強会、カンファレンス、執筆等でアウトプットをかさねて、他の技術者からも広く認知されている
  • 技術顧問で複数の会社に携わり業界横断的に活躍している
  • ... etc

... 等々と例をあげいくことができるように思う。

注) 話が発散しないよう 「IT 技術者としてのキャリア」だけにスコープをとどめておきたい 。趣味やプライベートで別のキャリア (例:音楽活動とか) を掛け持ちしているような例もあろうが捉えきれない。


よくよく『働くひとのためのキャリア・デザイン』を読み進めたら 以下のような記述があった

... アーサーの唱える「バウンダリーレスキャリア」のモデル(手本)はどこにあるのか ... (略)

まずその典型的モデル (手本、見本) となる人物は、たとえば、シリコンバレーで活躍する創造的な起業家やハイテク産業のエンジニアである シコリンバレーでなくとも、より一般的に、開発エンジニア、起業家、コンピューター・コンサルタント などにもあてはまる。

しっかり ITエンジニアも射程に含んでいた

『働くひとのためのキャリア・デザイン』は 2002年の著作で、当時はキャリアのあり方としてまだ珍しい事例だったのかもしれないが、20年も経過した今だとバウンダリーレスキャリアの話は、私の周りでも「ごく ふつう」に存在するくらいの概念になっているのだなと思った。


ところで バウンダリレス だけでも一つの用語として提唱されたものらしい

バウンダリレス」(boundaryless)とは、直訳すると「境界(バウンダリ)のなさ」という意味で、企業の従業員が部門や役職、立場、事業所の所在地など、組織内外のあらゆる境界を超えて自社に貢献しようとする姿、あるいはそうした価値観を指す用語です。1990年代初めに、米ゼネラル・エレクトリック(GE)社の当時の社長兼CEOジャック・ウェルチ氏が自社の目指すべきビジョン、組織や人材に求めるバリューを象徴する言葉として提唱しました。

「バウンダリレス」とは? - 『日本の人事部』

ITエンジニアの話だと、SRE や DevOps / DevSecOps あたりも組織内での <バウンダリレス> の例に挙げられるのだろうか。これもまた肌感で理解できる概念である。


誰も彼もがバウンダリーなふるまいをするのがよいのか よく分からないところもあって、それはまた個人のキャリアの話から組織の話にスコープが広がるところなので 感想を書くのは控えておく。

内的キャリアと自分の中で大切に思っている専門書

技術・キャリアに関する文章です

追記

内容を省みて 技術書 から 専門書 に訂正した。

イントロ

先だってペパボ社内の「CTOが訊く」 という企画で、あんちぽくん ( id:antipop ) とzoom 対談する機会があった。「CTOが訊く」はペパボ社の技術職のメンバーに対談を回していく企画で(*1) 、事前にテーマが何か決まってる訳でもなく 、あんちぽくんと何の話をしてもいい。


私は 外的キャリア/内的キャリア/キャリアンカー をテーマにして話をした (対談の内容を公開できないまんま このエントリを書いてるのは申し訳ない )

外的キャリア

職種・職位・技能・実績・報酬など客観的に把握できる職業上の経歴。→内的キャリア

外的キャリアとは - コトバンク

内的キャリア

なぜ働くのか、何のために働くのか、なぜその仕事をしたいのかなど、仕事や働き方に対する個人の主観的な評価や認識。

内的キャリアとは - コトバンク

キャリアンカー

「キャリア・アンカー」とは、MITのエドガー・H.シャイン教授(組織心理学者)が提唱しているキャリア形成の概念です。キャリアにおけるアンカー(錨=不動点)を指しています。 個人が自らのキャリアを形成する際に最も大切で、他に譲ることのできない価値観や欲求のこと、また、周囲が変化しても、自己の内面で不動なもののことをいいます。

キャリア・アンカーとは | 人事用語集・辞典 | 人事のプロを支援するHRプロ


対談に備えて、内的キャリアやキャリアアンカー を考える拠り所をピックアップしていたのだが、 「自分の中で大切に思ってる専門書」 をざっとリストしてみたら こんな本が挙がってきた。

f:id:hiboma:20210930112959p:plain

それぞれがどういった「大切」なのかの説明は ちょいと長くなるので省いておくが、自分のキャリアを「開始、転換、強化、再発見、 内省」 を促した書籍という感じなんだろうか。

「誰かに薦めたい専門書」 であれば また違ったものが出てくるだろうとは思う。「自分の中で大切に」というスコープだと こんなリストだ。もしかすると、もう少し時間が経つとリストが変わりそうなきもする。


内的キャリアを考えるには、書籍以外にもいろんなソースがあろう。 「人」「経験」... とソースをあれこれを挙げていくと発散するので、このエントリでは書籍紹介だけに止める 。Web 系の技術者なら「書籍」という制約だけでもいろいろ語りうるところがあるかなと思う。


同僚がどんな本をあげるかも知りたくなってきた。誰か頼む〜


内的キャリアを語る

blog.hifumi.info

(ITエンジニアが) 内的キャリアを語ることについては こんな力強い文章があって改めて読み返している。また別のエントリでここに繋がる話を書こう

余談

*1) 「CTO が訊く」は "笑っていいとも! のテレフォンショッキング みたいに1人ずつバトンタッチで対談する人を回していく企画だ" ... という比喩を思いついた。が、当の番組は 7年前に放送終了したので、伝わらない世代もいるだろうな 🕶 🎤