とある案件にて、インフラの仕事を他のメンバーにも担当できるように、画面をシェアしながら説明していていると、何だかペアプロっぽい動きになりました。
別に意図した訳ではなかったのですが、結果的に凄い効果が得られました。
「これは、インフラの仕事の進め方の１つとして、かなり有効なのでは？」と感じたので、書いてみることにします。
ペアプロとは
２人のエンジニアが１台のマシンを操作してプログラミングを行う手法。
コードを書く人とサポートする人に分かれ、交互にコーディングする。
現代におけるペアプロの問題点（※超個人的主観）
エンジニアの環境は多様化していて、その傾向は時代が進むにつれて、より強くなっている（ような気がする）。
ディスプレイの数、キーボード、マウスといったハードウェア的なものや、
エディタなどのアプリケーション、ショートカットキーやシェルの設定といったソフトウェア的なものと、非常にバラエティに富んでいる。
ペアでプログラミングをすると、ハードとソフトを共有するため、自分が使いやすいようにカスタマイズした環境を用意する事は、ほぼ不可能となる。
僕はエディタは VSCode を愛用し、シェルはデフォルトのシェルをほぼそのまま使い、エイリアスの設定はごくわずか、スニペットの登録も数える程度、プラグインは結構使ってる、というレベルだが、「Vimを使わないと実力が発揮できん」というエンジニアや、「自分用に魔改造したショートカットキーが無いと、パフォーマンスが出ない」というエンジニアと組んだ瞬間に、双方のパフォーマンスは大幅に低下する。
そもそも、最近はリモートワークが主流になってきて、同じ場所でプログラミングをする頻度も少なくなってきている。
そういった事情を考えると、ペアプロは双方のパフォーマンスを落とさない状況を整えるのも難しくなっているだけでなく、実践する事すらハードルが高くなっている、というのが実情なのではないかと思います。
（全社員のフルタイム出社が義務付けられていて、全エンジニアの環境が同一の会社ならそれほどハードルが高くなさそうだが、そういう環境を用意できる会社は、文化的にペアプロを取り入れないと思う。）
インフラのペアプロって？
通常のプログラミングと異なり、インフラはエンジニアごとに環境の差異が大きくなるケースは少ない。
一旦サーバにログインしてしまえば、使えるコマンドはエンジニアごとに差異が出るものではないし、複数のディスプレイを並べて作業する必要があるケースも、それほど多くない。
そのため、作業する側のエンジニアの画面をシェアし、オンラインで会話するだけで、ペアプロっぽい環境が出来てしまう。
リモートでも簡単に実現できて、超お手軽。
インフラのペアプロのメリット
やってみて、以下の効果があると感じました。
ブラックボックスを減らす事ができる
インフラの仕事は、基本的に単独で作業する事が多いためブラックボックス化しやすいだけでなく、社内リソースの都合で、いつの間にかインフラ担当者がごく少数となっている事も多い。
また、「運用でカバー」という名目で、プロジェクト進行時に発生した問題が長年放置されていたり、不要なほどに複雑化したインフラ構成のシステムを回すために様々なバッドノウハウを抱えているケースも多く、そういった情報や知識は、正式にドキュメント化されてチームに共有されるケースは少ないんじゃないかと思う。
この種のナレッジは、インフラ担当者が退職する引き継ぎのフェーズでしか露見しない事もある。
が、ペアプロをするような感じで画面をシェアしながらインフラの仕事をしていると、「何のためにそれやってるの？」といった突っ込みがパートナーから入り、ブラックボックス化していた部分を表面化する事ができる。
また、一通り仕事が終わった後、「そういえば、あの部分、ドキュメント化しておいた方がいいんじゃねーの？」といった会話をして、言語化・明文化する事ができる。
フォーマルな資料を作らずに、引継ぎのような作業もできる
様々な事情からインフラが最適ではない状態が維持され、そのために余計な作業を挟んでしまうケースが多いが、それらをドキュメント化するには多大な労力が必要となるケースも多い。
（様々な事情の例：「前任の担当者が超適当な仕事をしてて、めちゃめちゃ複雑なうえに超イケてない構成になっていた。リリースまで期日も無かったので、とりあえず後で最適な形に作り変えようと思って突貫工事で解決しておいたけど、突貫工事で作った状態がもう何年もそのままの状態になっている」等）
ドキュメント化する労力が大きいため、ずっと作業が後回しになり、気が付けば自分しかインフラを触れる人が居なくなっていたり、誰か他の人にも担当できるように画策したくとも、説明の難解さゆえにそれもままならない・・・と、悪循環に陥っているケースは珍しくないと思う。
が、ペアプロのように画面を共有しながらインフラを仕事をしていると、パートナーから「え？何でこの操作が必要なの？」と突っ込みが入った時に、「これはな、実は…」と、ドキュメント化しづらい複雑な事情を、他のエンジニアに伝える事ができる。
また、ソースコードと異なり、インフラの作業内容や資料はレビューの対象にならない事も多いが、この方法ではその問題点もカバーできる。
画面をシェアしながらインフラの仕事をする事で、必然的に作業がレビューのような働きをし、パートナーから「ここはこうした方がいいんじゃねーの？」といったアドバイスを貰ったりする事で、新たな気付きを得たり、さらに効率の良い進め方や、ミスを軽減できる進め方を発見できたりする。
IaC が進んでいるとはいえ、全てのインフラタスクをコード化するのはまだ難しい部分もあるので、こういう作業はかなり効果があると思う。
コマンドミスの警告ができる
インフラの仕事は、細心の注意を払わなければならない作業も多い。
中には、コマンドミスが致命的な問題に発展する事も珍しくないため、慣れた作業でも結構神経を使う。
しかし、画面をシェアしながらコマンドを入力する時、
「今からこれ実行するぞ。（このコマンドの内容）間違ってないよな？」
ペアプロのパートナーと意見を合わせながら進める事ができる。
作業手順を間違えていた場合、「おい。あの操作が抜けてるぞ」といった警告をして、ミスを軽減する事ができる。
有益なコマンドを共有できる
インフラの仕事をするにあたり、様々なコマンドを使う必要があるかと思う。
あなたが日常的に何気なく使っているコマンドでも、同僚のエンジニアから見たら「え？そんなコマンドあったん？知らなかった」という印象を受けたり、「へー。そのコマンドに、こういう使い方があったんだ」という受け取られる事があります。
他にも、「へー。こういう事を調査したい時、こんなコマンドが有効なんだ」というナレッジもシェアできます。
逆もまた然り。
そんな感じで、互いが保持している有益なコマンドやノウハウを共有できる。
エラー発生時に、協力して解決する事ができる
作業中、「あれ？エラー出てる。何が原因やろか。」という現象に遭遇した時、手分けして調査する事ができる。
例えば、エラー発生時に、１人は nginx 等の Webサーバのログを調査し、もう１人は Laravel等のアプリケーションのログを調査する、といった作業を分担できる。
各々のローカルの情報を参照しているわけではなく、共有で使用しているサーバならではのメリットを享受できる。
メンタルに良い
個人的には、これが最も効果が高いと感じています。
インフラの仕事にはプロジェクトに重大な影響を与えるタスクも非常に多いので、よく分からないエラーが発生し、いくら調査しても原因が特定できない場合、本気で具合が悪くなります。
例えば、
「マジかよ・・・いつも通りデプロイしているだけなのに、何でこんな事が起こってるんだよ.. 明日の朝にデモするから、今日中に解決しないと。
・・・って、調査してたら、もう朝４時なんだけど？」
みたいな状況になった時、誰にも相談できずに一人で黙々と作業をしていると、結構メンタルに来ます。
そんな時、パートナーと相談しながら作業をしていると、効率もメンタルへのダメージも格段に変わります。
インフラの仕事で胃が痛くなった経験のあるエンジニアは、是非試してみてはどうでしょう。
実際に行われていた会話の例
箇条書きでメリットを並べても、いまいちイメージが湧きづらいと思うので、実際にどんな会話がされていたのかを文字に起こしてみました。
テキスト化するにあたり、分かりやすくするために表現を変えた部分はありますが、現実世界で交わされた会話と、ほぼ同内容です。
１．
『あれ？ npm install がコケた。何が原因だ。何か新しいライブラリとか入れた？』
「ああ。何か色々入れた。もしかしたら、それが原因かも。」
『ちょっとエラーメッセージ見てみるわ。・・・これか。うっわ、これ Node.js の v17 はダメらしいぞ。』
「え？ 何で v17入れてるの？ 開発環境は v18だよな。」
『Amazon Linux 2 は v18が入らなかった。それで渋々 v17 を入れた。』
「マジか！？ v18 インストールできないの！？」
『うん。v18 は Amazon Linux 3 じゃないとインストールできないらしい。最初、Amazon Linux 3 でやってたけど、あまりにも Amazon Linux 2 と勝手が違い過ぎたんで、途中で 2 に切り替えた。デモ提供日まで時間も無いし。』
「そんなに違うのか？」
『ああ。マジで全然別物だ。Amazon Linux 2 の時に用意したスクリプトやコマンドが、ほっとんど使えん。色んなコマンドをまた覚え直さないといけなくなった。何でこんな凄まじい変更が必要だったのか本気で分からん。今後、二度と Amazon Linux を積極的に使わんと誓った事案だった。
デモ環境準備の期日も近かったんで、そんなの覚える余裕ねーと思って、途中から 3 を破棄して 2 に切り替えた。そしたら、Node.js v18 がインストールできなかったんで、代わりに v17 を入れた。』
「すると、こんな問題が起こったのか。」
『あ。でも v16なら使えるみたいだぞ。nvm入れて、バージョンを切り替えて対応しよう。』
２．
『また npm install がコケたぞ。今度は別のエラーメッセージだ。今度は何が原因だ。』
「分からん。ちょっと調べてみるわ」
『助かる。俺も調べてみる』
～ 調査 ～
「npm install 時にメモリ不足だと、このメッセージが出る事があるらしい。これが原因かも」
『マジか！ microじゃダメか。そういえば、前のプロジェクトでも、結構メモリがカツカツだっけか』
「他に思い当たる原因もなさそうだし、スペック上げてから試してみたら？」
『OK。やってみよう。』
「ところで、EC2のスペックって上げた事ある？ やった事無いからちょっと怖いけど」
『大丈夫。やった事あるけど、大して難しくなかった。変更も速攻で終わる。インスタンス止めて設定変えるだけで行ける。』
～ 作業 ～
『それでもダメか。』
「エラーメッセージの内容が変わらんな。スペックをもう１段階上げてみては？」
『分かった。じゃ、medium で行くか。』
～ 作業 ～
『今度は成功した！よっしゃあ！』
「おお。長かったな。」
『ああ。とりあえず、今後 Node.js は安定版以外は使わない事にするわ。Laravel だと最新版使っておくことが正解のケースが多い気がするが、Node.js はそうは行かんな。今後、Node.js は二度と LTS以外は使わん。あと、EC2 は、スペックをケチらずに medium ぐらいを基準にしておくわ。』
３．
『えええ！？ Seederがコケたぞ！？ 何が原因だ？？』
「ローカルではちゃんと動いてるな。」
『テーブルをリフレッシュしてから実行してるから、既存データが原因って可能性は無いよな。んで、二人ともローカルの環境では正常に動いている。何が原因だ。マジで分からん。』
「ちょっと調べてみる」
～ 調査 ～
『原因、これかもしれん！見ろ！』
「え？分かったの？ ・・・って、なんだこれ！？」
『同じSeederが２つある！ １つは “OutDoorUnitGroupSeeder” で、もう１つは “OutdoorUnitGroupSeeder” だ。１つは大文字の “D” で、もう一方は小文字の “d” だ。』
「何でこんなファイルが混在してるんだ？？」
『分からん。多分、作成担当者がファイル名間違えて push して、後で名前間違えていた事に気が付いて修正したが、誤って既存のファイルを消し忘れていたとか。だとしたら、レビュー時のチェックが甘かった。すまん。』
「ちなみに、どっちが正解なんだ？」
『大文字の方。こっちだけあれば OKだ。』
「何なんだこれ。ローカルではファイルは１つしか無いのに。」
『多分、俺ら二人とも Windowsだからだな。Windowsは大文字小文字の違いで同名のファイルは存在できないんだ。それで git clone時に重複ファイルが存在しないように制御されているのかもしれん。そして、ローカルで実行する時はファイルが１つしか無いので、正常に実行できていた。』
「なるほど。・・・ってこれ、正式な対応はどうするんだ。Windowsだと、ローカルにファイルが存在しないから、どう頑張っても修正できねーぞ」
『Macで作業して push するわ。ちょっと待ってて。EC2に入ってるソースを直接編集するのも手だけど、それだと次回のデプロイ時に面倒な作業が起こりそうだし、この程度ならサクッと修正してアップしとく。』
４．
『CORSエラーが消えねー！ 何が原因や』
「もう考えらる事は調べつくしたな。マジで分からん。」
『明日、クライアントにデモをするのに、何で今日に限ってこんなエラーが頻発するんだよ。』
「どうする。これ」
『よし。いっそ CORSを無効にしよう』
「おい。マジか」
『マジだ。
大丈夫。クライアントへのデモが終わったら速攻で修正する。今日はもう遅いんで、これ以上の調査に時間かけるより、とりあえず動く状態に持っていく事を考えよう。』
「で、どうやって CORSを無効にするんだ？」
『ミドルウェアのこの部分をコメントアウトするだけで行ける。とりあえず、今日はそれで乗り切ろう。』
「え？直接ソースいじるの？」
『さすがにこの内容をリポジトリに含める訳にはいかんしな。次回の作業用に revert必須ってメモを残しておこう』
「まぁ、もう時間も遅いし、仕方ねーか。」
『おっけー。多分、これで行ける。』
「おい。何かまた別のエラーが（以下略」
５．
「ログインができねーぞ。何が原因だ」
『分からん。ログインユーザはちゃんと登録されているぞ。』
「よく見たら何かエラー出てるな」
『何やらバックエンドのエラーみたいだな』
「とりあえず分担して調査しよう。俺は nginxのログを見るから、そっちは Laravelのログ見てくれ。」
『OK！』
～ 調査 ～
『分かった！ laravel.log への書き込みができていなかった。パーミッションの問題だ。』
「よし。修正頼む。」
『OK。・・・よーし。ようやくログインできたぞ！』
６．
『はー。ようやくデプロイ終わった。フロントがPM2で動くようにしたし、クッソ不安定だったフロントエンドが、ようやく安定するな。
おい。チャット開始時刻見てみろ。４時間以上経ってるぞ。』
「本気で疲れたな。」
『PM2 の導入、ありがとう。言い忘れてたけど、実は先週のデモでは、npm run dev で動かしてたんだ。』
「嘘だろｗｗｗ」
『本当だ。デモやってる最中、エラーが起こったら、その都度手動で再起動してた。常にコンソールを横に置いて仕事してたぞ』
「何やってんだよｗｗｗ」
『他に方法が無かったんだよ。マジで余裕なかったんだ。文句はフロントエンドリーダーに言ってくれ。こんな重大な問題を放っておいて、どうでもいい事ばっかりやって全然進捗上げてくれないんだよ。毎回毎回、些細な事を「重大な問題です！」とか言って、タスクの進捗上げる事をせずに余計な事ばっかやってて、いつも苦労してる。』
「時々、聞いているな。フロントのカオスな状況は。途中から入ったからよく知らなかったけど。」
『フロントの技術課題、ぜんっっぶ、こっちが解決している状態だからな。ちなみに、先週までビルドすら通らなかった。フロントエンドリーダー、デモが近いって言ってるのに、ビルドが通らない事すらほったらかしにして、大して重要じゃない仕事ばかりをやっていた。』
（何やらカオスな状況ですが、何故こんな事が起こったのかは以下のエントリに書きました。簡単に言えば、経歴詐称疑惑のあるエンジニアが入ってきたのが原因です。）
【システム開発】タチの悪いエージェントの地雷を踏んだ時、被害を最小限に抑える方法を考えてみた
終わりに
何だか凄まじいレベルのダメな会話をしているような気もしますが、インフラ経験者なら、この程度の事はよくあるんじゃないかと思います。一人でやってるから他のメンバーに知られていないだけで。
・・・あるよね？ あると言ってくれえええ
という感じで、僕はインフラの仕事をペアプロっぽく進めるのは非常に効果が高いと感じたし、もしインフラ仕事の引継ぎを受ける場合、「こういう理由で、画面をシェアしながら引継ぎを受けたいです！」とお願いしようかと思っています。
追記
英語版も書いてみました。
https://dev.to/kakisoft/when-i-tried-pair-programming-for-infrastructure-work-it-turned-out-to-be-super-effective-449g
スペイン在住の友人（フロントエンドエンジニア兼デザイナー）にチェックを依頼して、実際の現場で使っているような自然な言い回しになるようにしています。
コメント