python-docx を使うと Python で Word ドキュメントを操作できる．新しく Word ドキュメントを作ることもできるし，既存の Word ドキュメントから文章を抽出することもできる．前に紹介した python-pptx と関連している．最近 PowerPoint の文章を Word に繰り返しコピーする機会があり，作業効率を上げるために python-pptx と python-docx を組み合わせた自動化コードを実装していた．
from pptx import Presentation
presentation = Presentation('example.pptx')
for slide in presentation.slides:
if slide._element.get('show') isNone:
print(slide.shapes.title.text)
「Anti-Type B: DevOps Team Silo」は，独立した「DevOps チーム」が作られて，また別のサイロ化が進んでしまう状況のことを表現している．単純に「DevOps」というバズワードに翻弄されている可能性もあるし，僕自身も数年前に「DevOps Engineer」という肩書を使っていた経験もあり実際の現場ではよくありそう！ただ一時的に「Dev と Ops を近付ける目的」で「DevOps チーム」を作るのは効果があるとも書かれている．その場合は，後半に出てくるベストプラクティス「Type 5: DevOps Team with an Expiry Date」となる．
個人的には以下の Netflix のプレゼンテーション「How Netflix Thinks of DevOps」に出てくる「DON'T DEVOPS / DO CULTURE」というフレーズが好きで，この YouTube は何度も繰り返し観ている．おすすめ！
🌀 Anti-Type C: Dev Don't Need Ops（Dev が Ops を必要としない）
「Anti-Type C: Dev Don't Need Ops」は，Dev 主導で DevOps を実現する組織構造となり，最初はベストプラクティスなのでは？と感じたけど，意味としては，例えば「クラウドを使えば Ops は不要」というような思想から「運用の必要性」を過小評価してしまっている状況のことを表現している．その後，運用の波が押し寄せて，ある意味で現実を知ることになると「Type 3: Ops as Infrastructure-as-a-Service」や「Type 4: DevOps as an External Service」に進化していく．
🌀 Anti-Type D: DevOps as Tools Team（ツールチームとしての DevOps）
DevOps を実現するために，例えば「継続的デリバリーパイプライン」を構築したり，「構成管理」の仕組みを作ったり，自動化ツールの開発にフォーカスしすぎてしまう状況のことを表現している．個人的には「Anti-Type B: DevOps Team Silo」にも似ていると感じた．当然ながらツールチェーンが整うことによる価値はあるけど，Dev と Ops のコラボレーションが実現できない点に再検討の余地がある．
よく知られた SysAdmin（システム管理者）という役割をリブランディングして DevOps（やることは SysAdmin と同じ）として採用を進めているような状況のことを表現している．エンジニアリングの成熟度が低い組織で起きると書いてある．重要なのは，役割をリブランディングしただけでは「文化的／組織的な価値」は生まれないことだと思う．「Anti-Type A: Dev and Ops Silos」や「Anti-Type C: Dev Don't Need Ops」にも関連するけど「DevOps」というバズワードに翻弄されていると Anti-Type に近付いてしまう．
🌀 Anti-Type F: Ops Embedded in Dev Team（Dev に組み込まれた Ops）
⭐️ Type 2: Fully Shared Ops Responsibilities（完全に共有された Ops 責任）
Potential effectiveness: HIGH
Dev と Ops の役割が完全に共有（オーバーラップ）されている．チーム全員が同じ目標に向けて集中している．Netflix や Facebook などウェブサービスを提供していると実現しやすいけど，多くの場合では適用しにくく「Type 1: Dev and Ops Collaboration」のように Dev と Ops の役割は分割されていくと書いてある．本当？個人的には1番好きな組織構造だと感じた．関連した役割としては Netflix の提唱する「Full Cycle Developers」という考え方もとても好き！
⭐️ Type 3: Ops as Infrastructure-as-a-Service（IaaS としての Ops）
Potential effectiveness: MEDIUM
クラウドを活用することにより，アプリケーションをデプロイしたり，拡張性を高めることができる．特にコードでインフラを操作できるようになるため，Dev が運用のことを考えながら進めやすくなる．納得できる内容だった．最初から「Type 1: Dev and Ops Collaboration」に挑戦するよりも素早く価値を引き出せると書いてある．
⭐️ Type 4: DevOps as an External Service（外部サービスとしての DevOps）
Potential effectiveness: MEDIUM
特に小規模な組織だと，ソフトウェアの運用を主導するための資金や経験やメンバーがいない場合がある．そこで，例えば Rackspace などのサービスプロバイダーと連携をして，サポートを受けながら学んでいく．その後「Type 3: Ops as Infrastructure-as-a-Service」もしくは「Type 1: Dev and Ops Collaboration」に移行していく．
⭐️ Type 5: DevOps Team with an Expiry Date（有効期限のある DevOps チーム）
Potential effectiveness: LOW to HIGH
組織構造としては「Anti-Type B: DevOps Team Silo」に似ているけど，チームとしての寿命が異なる．最終的にベストプラクティスの「Type 1: Dev and Ops Collaboration」や「Type 2: Fully Shared Ops Responsibilities」を目指すために一時的な責任を与える．コラボレーションを実現するために「スタンドアップ」や「カンバン」などの DevOps プラクティスを組織に広めていく．さらに技術的な検証や実装も進めていく．「Anti-Type B: DevOps Team Silo」にならないように気を付ける．
⭐️ Type 6: DevOps Advocacy Team（DevOps 推進チーム）
Potential effectiveness: MEDIUM to HIGH
「Type 5: DevOps Team with an Expiry Date」で長期的な責任を与えるべきではないと書いてあったけど「Type 6: DevOps Advocacy Team」は，継続的に Dev と Ops のコラボレーションを推進する役割を担当する．DevOps プラクティスを組織に広めていくことから「DevOps 推進者（アドボケイト）」と呼ばれることもあると書いてある．「Anti-Type B: DevOps Team Silo」にならないように気を付ける．
⭐️ Type 7: SRE Team（SRE チーム）
Potential effectiveness: LOW to HIGH
DevOps では，Dev もオンコール（障害対応）に参加することが推奨されている．例えば Google により提唱されている SRE (Site Reliability Engineering) モデルを採用して，ソフトウェア開発に対してサポートを受けることもできる．サイトに載っている図解によると Dev / Ops / DevOps / SRE それぞれの役割が少しずつオーバーラップしている．さらに SRE はコード（実装）の見直しまで手を出す点もポイントと言える．「Anti-Type A: Dev and Ops Silos」にならないように気を付ける．
⭐️ Type 8: Container-Driven Collaboration（コンテナ駆動コラボレーション）
Potential effectiveness: MEDIUM to HIGH
Kubernetes の普及など，コンテナワークロードが一般的になった今，アプリケーションのデプロイやランタイム要件をコンテナイメージとしてカプセル化できるようになった．エンジニアリング文化をうまく築けていると，コンテナは Dev と Ops の境界として機能すると書いてある．しかし，コンテナワークロード特有の運用もあることも忘れないこと！「Anti-Type A: Dev and Ops Silos」にならないように気を付ける．
⭐️ Type 9: Dev and DBA Collaboration（Dev と DBA のコラボレーション）
Potential effectiveness: MEDIUM
Dev と DBA (Database Administrator) の溝を埋めるために，能力を補完しながらコラボレーションを実現する．大規模なデータベースを管理している組織に適していると書いてある．それ以上は具体的に書かれてなく，少しイメージしにくかった．「Anti-Type G: Dev and DBA Silos」にならないように気を付ける．
僕自身，平日は朝イチに「メモ帳」に1日の TODO を書き出しているし，毎週日曜日 22:00 頃に「1週間の振り返り」をする生活をかれこれ「5年以上」も続けているほどには習慣化できている．だからこそ，本書で紹介されていた多くの TODO は日常的に意識できているものだったけど，その中でも特に印象に残った「2点」の TODO を紹介する．
本書は全体的にカジュアルな文章で，文字数は少なく，挿絵もあり，スラスラと読める．1時間もあればザッと読み終わると思う．また本書には「やってみよう」というアクティビティとして，多くの「TODO」が紹介されている．気になった TODO は実際に書き出してみたりした．読むだけではなく，アクションに繋げると効果的だと思う．
Chapter.1「ひとり会議をはじめる」
Chapter.2「5つのひとり会議」
手法 1「テーマ会議」
手法 2「問題対策会議」
手法 3「フリー会議」
手法 4「スケジュール会議」
手法 5「情報収集会議」
Chapter.3「ひとり会議後の仕事術」
Chapter.4「自分を見つめるひとり会議デラックス」
📝 5分あったらやること
「スケジュール会議のコツ」の中に「ワクワクは仕込むもの」という話があり，そこに以下の TODO が載っていた．そして「時間ができたらやろう」では「はじまらない」とも書いてあり大好きなフレーズだった．
朝イチに TODO を書き出したり，毎週日曜日に「1週間の振り返り」をしていても，ほとんど「自分は成果を出せているか？」や「自分は成長できているか？」や「自分は次は何に挑戦したいか？」という視点を軸にしていて「どうしたら楽しくなるか？」という視点で考えたことはなかった．本書を読みながら，そもそも僕自身「楽しい」という感情をあまり持っていないことにも気付けた．まずは「楽しさ」を自分の中で定義するところからはじめつつ，考える時間も少しずつ取り入れていきたい．
リモートで働くことが増えたであろう今年は「画面共有」を使う機会も増えたと思う．例えば，ミーティング中に資料を投影したり，リモートペアプロ（モブプロ）をしたり．僕自身は技術講師として，演習中にトラブルになっているお客様の問題解決をするときにも「画面共有」をよく使う．ツールで言えば，Zoom / Discord / Amazon Chime / Microsoft Teams / Google Meet / Screenleap など，選択肢はいろいろあるけど，今回は Go で実装された OSS の画面共有ツール「Screego」を試す．
「Screego」のドキュメントには以下「5種類」の特徴が載っている．参考として日本語訳も載せておく．また「Screego」を支える要素技術として STUN (Session Traversal Utilities for NAT) や TURN (Traversal Using Relays around NAT) の紹介もドキュメントに載っている．
Multi User Screenshare（複数ユーザーでの画面共有）
Secure transfer via WebRTC（WebRTC でセキュアな転送）
Low latency / High resolution（低遅延 / 高解像度）
Simple Install via Docker / single binary（Docker で簡単にインストール / シングルバイナリ）
Integrated TURN Server see NAT Traversal（統合された TURN サーバーで NAT トラバーサルをする）
今回はサンプルとして「Screego」のコードを VS Code で表示しているウィンドウを画面共有している．以下のスクリーンショットは別ブラウザで画面共有を見る側の視点で取得した．「Screego」の特徴にも載っている通り，コードを操作しても遅延はほとんど感じなかった．とは言え，今回の検証環境は同じネットワーク上に存在する macOS 同士になるため，正確な結果とは言えないと思う．
🖥 複数ユーザーでの画面共有を試す
「Screego」の特徴に載っている「Multi User Screenshare（複数ユーザーでの画面共有）」も試す．今度は画面共有を見る側から kakakakakku blog を表示したブラウザを画面共有する．すると右下にピクチャ・イン・ピクチャのような UI で表示された．これは便利！クリックするとメインの画面共有と入れ替えることもできる．
🖥 まとめ
Go で実装された OSS の画面共有ツール「Screego」をデモサイトで試した．簡単に使えるし，複数ユーザーでの画面共有は便利だし，機能面では使えそうだった．そして「Screego」の特徴にも載っていた通り，Docker で簡単にインストールできるため，次は自分専用の「Screego」環境を構築してみようと思う．
