DevOps時代におけるクオリティ・エンジニアの重要性 （前編）

はじめに

お久しぶりです。@numehaです。前回の投稿から約半年間が経過しました。AKB48のあっちゃんさよならライブ生中継を見ながら書いております。
「DevOps時代」なんて目を引くタイトルにしてみたものの、ただの思いつきの投稿です。はい。
とあるメーカで働いている私の体験談や思いを一部フィクションを交えてお届けしたいと思います。何かフィードバックいただけるとこれからの活動の参考になります。よろしくお願いします。

DevOpsって

DevOpsはムーブメントだ！なんて言われていますね。このスライドの説明が一番わかりやすいですね。

そうそう。わかるわかる。。。。
ん。いや、ちょっと待てよ。私は未熟者なのでまだピンときていないのですが、何か違和感がありますね。

開発と運用の垣根がなくなるのだけど責任は異なるの？お互いのことをわかった上で取り組もうということなのだろうけど、そもそもこれ系の話は開発と運用だけに限った話ではないですよね。多少の壁がありながらもうまくお互いのことを理解するのはある意味当たり前の話でみんな苦しんでいる話だと思います。

f:id:numeha:20120823143512j:plain

歩み寄りもしないで一方的に否定から入るなんてもってのほかですね。

そんなこんなで最近もやもや考えながら日々仕事をしているわけですが、自分の中の勝手な定義としては、

何事もDevOpsな態度で取り組め！

これならピンとくるんだな。
相手を責めない、押しつけない、信頼しあう。相手がいてこその自分なのだから。

クオリティ・エンジニアって

一般的にはテスト・エンジニア？ということが多いのでしょうか。呼び方はどうでもよいのですが、あるソフトウェアの品質を最優先に考えて行動しているエンジニアのことです。
そんなのDeveloperであれば品質のこと考えてやってるよ、という声が聞こえてきそうですね。


「最優先に考える」

というところが重要だと私は考えています。


Developerであったら、何かを設計する、開発するということに注力することでしょう。今であればテストが重要だというDeveloperは多いと思いますが、「品質を最優先に考える」ことはかなり難しいでしょう。
また、運用のことも理解して開発をすることが求められていますが、それは意識だけではどうにもならない能力を要することだと思います。
（最優先に考えなくてもソフトウェア開発に重要なことを全て均等に完璧に考えられるスーパーマンだらけの組織は除きますがねw）

というわけで、

f:id:numeha:20120823144853j:plain

クオリティ・エンジニアはDeveloper、Operatorと協力して、品質の高いソフトウェアをリリースしてお客様にビジネス価値を届ける。それぞれが注力して取り組んでいるところの穴を埋めるような、そんな役割として活動するメンバーが重要だと感じています。
DevOpsの議論では、品質関係の話が軽薄な印象を受けます。品質の話は、開発と運用と同等またはそれ以上に難しいことだと私は思います。

だって人間だもの

話がそれますが、なんでクオリティ・エンジニアの役割が必要かと思った理由について少し。
私は長い間Developerとして活動してきましたが、いくら自分がたくさんのテストコードを書いても、いけてる設計だと思っても、たくさんのレビューをしても、思わぬバグを踏むことがあります。

そしてそのバグはリリース直前やリリース後に運用してみて発見されることもありました。
Developerにとってこんな悔しいことはありません。そのときは、なんで事前に発見できなかったのか、自分を責めて責めて枕を濡らした日もありました（言い過ぎましたw）。

そこで発見されるバグは例えば単純なマージミスのときもあるし、テストコードの漏れ、運用環境でしか発見されない問題もあり様々です。
また、ソフトウェア自体ではなくそれをデプロイした実行環境の設定ミスにより思わぬトラブルを踏むこともあります。
OperatorもDeveloperと同じことです。人間なのだからミスだって検討不足のことだってあるんです。

そんなこんなで、開発を最優先に考えるDeveloperと、品質・テストを最優先に考えるクオリティ・エンジニア、安定運用を最優先に考えるOperatorを定義して、お互いが協力して活動すればうまくいくのではないかと思ったのがきっかけです。
協力するということが重要で、お互いが相手のことを考えて行動しなくては意味がありません。

クオリティ・エンジニアは、とにかくビジネス（お客様）視点で、リリースするシステムの品質を向上させることが一番の仕事です。Developerの設計指針や仕様に関して検討段階から参加し、意識を合わせる必要があります。Operatorが運用する環境を理解してテストを実行する必要もあります。
こうすることにより、従来からあるすでに出来上がったもののバグ出しテストにはならず、戦略的に早期にテストを行うことができるようになります。
早期にクオリティ・エンジニアとテスト戦略について議論を重ねることで、バグをなるべく作りこまない開発を意識的に行うことができるようになります。

後編では、そんなクオリティ・エンジニアが取り組むいくつかの事例を紹介したいと思います。

参考