序盤の飲み会の幹事をやらされる理由は、似たようなことを先輩に言われてやらされたのを思い出しました。 まぁ、でも当たらずとも遠からずなのですよね、調整作業そのものですから。主賓確認、スケジュール調整、 場所確保、コース内容・会費決め、参加者連絡などなど、SE業務に限らず通ずるものですが。
　それとPJ単位だけではなくフロアやグループ、部門、さらには顧客と対象範囲が広がるとその分知り合いが増えるわけですし、 あのころは純粋に楽しかった。唯一悩みの種は飲むことに集中できないことです。二次会でようやく安心できる感覚、懐かしい。 最後に幹事らしい幹事をやったのはいつだろう、５年前の忘年会？いやその後の送別会だったかなぁ。年単位でやっていないのは確実です。 今、幹事やったら確実に酔っぱらって破たんするのが目に見えます。

　今回は運用のお話ということで、開発と運用が仲良しでないという物語としてはよくあるパターン。 個人的には最初に配属された開発の部署が運用も巻き込んで協力してやっていかないとユーザに対してサービスを提供など できるわけもないところでしたので、ある程度の役割分担はあるにせよ一体となるのが普通だと思っていましたし、 24時間365日一次窓口として対応しなければいけない、インフラ環境は整えなければいけないし安定的に稼働するのが当たり前なことを 課せられる分、いつも開発部隊として申し訳ない気持ちと感謝の気持ちでいっぱいでした。
　梢の言い分として役割分担をきちんと明確にしましょうということもわかります。これをしておかないと、劇中で言われているとおり 際限なく運用側の仕事が増えるだけで最終的に回らなくなるからです。ただ、それにしても杓子定規すぎやしないかな〜と思っていました。 立華への信頼が(あとで技術としての信頼関係はあることは判明しますが)ない状況とはいえ、工兵の提案も別に私としては開発(立華たちは構築)部隊が 問い合わせフローの後ろにいるのは業務として担当していたので普通かと。

　まぁ、その理由は障害対応後に語られているとおり、梢が出来過ぎる能力を持っていた過去の経験で、自分がいなくなったあとの部署の末路を 見てしまったことによるのは仕方ないのかな。ただ、その理由を見るまでは急に実力を出したのには、本当に運用しか経験したことがないならこれまでの態度は理解できるけど、 立華と同レベルなのにこの態度だったのは最悪ではと思っていました。それでももう少し融通利かせてもいいと思いますが、そこが技術は一流でも社会人経験はまだ少ないことにつながるのでしょうか。 もしくは運用部組織全体として底上げしたいなら余計に杓子定規にドキュメントの分担をするのではなく、自分の技術をどうやって習得してもらうかも考えるとよいのに。
　立華の技術や今回の障害調査の書きぶりからすると、作者はネットワーク分野が主担当だったのかな、レスポンスが遅い時の切り分けで DBサーバまでたどり着くのに工兵の話を聞くまであれだけの二人がぴんと来ないというのは少しだけ不自然だったので。展開としてのわざとなのかもしれませんが。
　ただそのサーバ障害の内容がクラスタ構成のことだったので、これは私は知識としては知っていますが担当経験はないので中々面白かった上に、 その原因がメモリ不良というのがこれは経験したことあるので厄介なことはわかります。合っている型番のメモリなのに説明書通りのスロットに挿しても認識しないのに 同じ型番の別のメモリを挿すと認識し、認識しなかったメモリを他のスロットに挿すと認識するとか、ハード周りの障害は本当にわからない。 保守切れ起こしそうな古いサーバですと電源不安定になりやすくて停電などで電源落とすたびに次にきちんと起動するかひやひやものでした。

　そして今回もあとがきに共感が。もうタイムリープする場所にはいけないです。