ふと思ったこと#
インフラエンジニアとしてキャリアをスタートして、今はSREとして働き、ITエンジニアとしては14年が経つ。 過去に大小問わず数え切れないほどのシステムの移行を行ってきた。 その中の作業は概ね下記に大別される。
- バージョンアップ(OS, ミドルウェア, アプリケーション)
- スケールアップ
- スケールアウト
- アプリケーションの移行
- アーキテクチャの変更
- P2V
- V2V
- 自前管理からマネージドサービス
これらのことを行う際に、考慮しないといけないことはシステムの複雑性、ビジネスサイドとの連携、そして自分のスキルによっては手段や手法を時には変えざるをえないこともある。
逆に言えば、自分がコントロールできる範囲で、より高みを目指した構成にすることも可能である。
特にインフラ部分に於いて、インフラエンジニアのチームで受け入れられたアーキテクチャをアプリケーションエンジニアがひっくり返すようなことはあまりしない。
インフラの責任はインフラを管理している人間が最初に負うので、自分の責任範囲でやるならばどんな構成にしようとも極端に言えばどんな構成にしても問題ないと言える。
しかし、そこまでのスキルがない場合、特に私のような平凡なエンジニアの場合、大きなシステム移行をやるのにあたり今更ながら守ったほうが良いことが分かってきた。
それは一つのことをうまくやるということである。
この言葉はUNIX哲学にある一つのことをうまくやるという考えを参考にしたものだが、改めて偉大な言葉であると思うようになった。
まず、システムの移行はなにかしらの変化が伴う。
システムのバージョン、パフォーマンス、管理方法、構成、場合によっては管理するチームなどまで変わることがある。
その中で大事だと思ったのは、ゴールを明確にすること。そして、やらないことを決めるということ。
ごくごく当たり前だが、これがなかなかできない、やらない、疎かにしがちである。
そして、痛い目をみるのである。
全部盛り盛りアウトプット出し放題チャンスではあったとしても、やるべきことはゴールだけに絞ったほうが良い。
システム変更は目的があってやるはずである。
そして多分なリスクも伴う。
新しいことを2つも3つも盛り込んだ上で、想定通りの見積もりでスケジュールが組める人がいたら、その人は相当な手練れだ。
私は複数の事柄を同時に盛り込むことだけは必ず避けるようになった。
そうでないと想定の何倍もスケジュールが遅れてしまうことがあるからだ。
新しいことをやる時は1つ、ないしは1.5くらいと決めている。
それでも見積もりが外れることはままある。
スクラムの見積もりの難しさはとてもよく理解できる。
そのリスクをないがしろにして、ビッグバンリリースをするのはオススメできない。
失敗した先に待っているのは繰り返されるメンテナンス、振り返り、検証、収まらない動悸…。
無事にメンテナンスが終わっても、なんとなく後味の悪い気持ちが薄らぼんやり残るあの感じは思い出すだけで頭痛がする。
だから、小さなことを小さく進めて、一つのことをうまく進めてることで、気がついたら終わっているのがベターである。
一つのことがうまくいったら、その後別のことを進めれば良いのである。
気がついたら目的が達成できていたなんて最高である。
ただ、これには人に気が付かれにくいという唯一にして最大の弱点がある。
下手をすると、同じチームのメンバーですらあまり理解してもらえていないことすらある。
これはまた別の課題なので今回はあまり触れないものの、改めてチームや部署で共有の機会を設けるなどが必要だと感じている。
サマリーの話なら皆聞いてくれる。
まとめ#
一つのことをうまくやることについて普段考えていたことを書き出した。
すぐに忘れてしまい、後悔すること数え切れず。同じ過ちをおかさないよう時折見返しては肝に銘じたい。