 |
牛尾: Product の側面についてお聞かせいただいたので、次は People についてお聞かせください。どういう箇所が荻野さんにとって難しかったですか? |
 |
荻野: システム テストの自動化自体、テスト側、開発側で意見の相違がありました。 |
|
牛尾: それをどう改善しましたか? |
|
荻野: メリットを具体的な結果として見せました。自動化してみて、壊れてもすぐにわかるとかが伝わると徐々に自動化いいよねとなってきました。 |
 |
家永: そういう風にムードが変わっていった大きなきっかけはありますか? |
|
荻野: スモーク テストですね。例えば、検索エンジンに対して１件だけ検索する単純なテストを書きます。ところが、日本人じゃない人は日本語処理の優先順位が低いのでそもそも、文字化けしていても気づかなかったりします。しかし、それは日本の市場では最優先事項の 1 つです。ですので、そのスモーク テストに日本語のテストを加えると、すぐに気づいてもらえるようになりました。そして、彼らもその重要性にも気づいたようでした。 |
|
牛尾: 確かにそれは彼らにとっては気づかなくてしかたがないですよね。では、Dev と Ops の関係についての話はありますか? |
|
荻野: 別組織ですのであまり僕の口から言えることは少ないのですが。彼らも Infrastructure as Code の技術つまり Chef/OpenStack 等を使っていて、インフラの構成なども継続的インテグレーションの仕組みを使って管理、自動化しています。 |
|
牛尾: さすがですね。 |
 |
川口: 最近、DevOps 会議 (本当の名前は長いので省略) というのをやってみたんです。 |
|
荻野: 過去にはせっかくそのような仕組みがあるのですが、開発側と連携していませんでした。しかし、今ちょうど、Dev と Ops の自動化ツールを結合しようという動きが出てきています。 |
|
牛尾: 面白いですね。どちらも高度な技術をつかっているのに、それが最初から連携して使われるとは限らない感じですね。 |
|
牛尾: では、関連してなのですが、Dev と Ops をはじめとするサイロがどこの会社さんでも課題になっていると思います。このようなサイロはなぜ発生してしまうのでしょう? |
|
荻野: やはり、お互いのことが理解できていないのだと思います。例えば TDD や CI は Dev 側は当たり前かもしれませんが、ops 側では、そうでないことが多いでしょう。それが Infrastructure as Code の技術になると、Chef を使ったプロビジョニングを Jenkins から実行するといったことがありうりますよね。システム テストはもとは Ops の人だけでやっていたので、同じようなことが発生するわけです。
|
|
川口: 私はサイロは単なるストラクチャー (構造) だと思います。今は一見すると、なんでこんなサイロに分かれているんだろうと思うことでも、昔はきっとそのほうがよかったんじゃないかと。その時点では必要なストラクチャーだった。ところが、技術が変遷していった時に、「これってサイロじゃね?」となる感じです。 |
|
牛尾: どういうことですか? |
|
川口: 例えば、昔はテープを運用する役割の人がいました。それが昔は効率的だったんです。今はもっと簡単にバックアップできるようになったので、そういう人や役割は専門にはいらなくなりました。その過渡期の時に「これってサイロじゃない」といわれるという仮説です。 |
|
牛尾: ところで、皆さんは川口さんを除いて Dev 側の出身ですよね? 皆さんからみて Ops の方はどのように見えますか? |
|
荻野: もっと開発側の人とコミュニケーションをとる機会をもってもらえたらなあと。先日 XP 祭りにいったら、1 人だけインフラの人が講演していていいなあと。 |
|
牛尾: ちなみに DevOps 会議ではどんなことがわかりましたか? |
|
荻野: そうですね。やはりお互いがお互いのことを知らないということです。Ops の方は例えば、Dev 側が何で困っていて、何を要望しているのかを知らない人もまだまだ多いと思います。Infrastructure as Code によってどんなDev側の問題が解決できるのかもっと知ってもらえたらなあと。 |
|
家永: 誰がうれしいとかを描けている人がまだ少ないんですね? |
|
荻野: ですね。でも最近少しずつ Dev のパッションを受け取ってもらえるようになってきました。 |
|
家永: ようやく交差し始めたのですね。 |
|
川口: Ops 側の特色としては、職人気質というのがあります。アプリを動作させる大切な基盤を地面から立ち上げる仕事なので、大工さんのような棟梁気質があります。責任感があるんですね。だから、しっかりとしたものを設計・テストして、さあ、使ってくださいと完璧なものを出そうと頑張るんですよ。 |
|
牛尾: なるほど。 |
|
川口: ところが、実は Dev にその基盤を渡すと、完璧にしたつもりでもでこぼこがあるかもしれない。すると Dev の人は Ops のやつら全然完璧じゃないし、いけてないとかなるわけです。 |
|
牛尾: 人間だからそんなの無理ですよね。 |
|
川口: はい。しかし、それを完璧にしようと努力するのです。この引継ぎモデルでは、ある意味、下請け的な仕事をさせられているともいえますので、きっちりやろうと。でも本当は、Devからすると、別にでこぼこで、多少最初に問題があってもいい場合もあるかもしれません。 |
|
川口: だから、Ops の人のカタルシスをどれだけDevの人が理解できるか。お互いのパッションのポイントがわかっていないのでお互い理解しないといけないのです。相手に興味をもつというか。 |
|
荻野: そういう意味では 1 つ面白い体験をしました。私は当初非機能テストという名前をつかっていたのですが、運用テスト (Operability Testing) という名前にしたら Ops の人が運用的要求を出してくれるようになったんですね。 |
|
牛尾: 詳しく説明してください。 |
|
荻野: 非機能テストと呼んでいたときはとても開発主導と思われていたようで、Ops の人は要求をだしちゃいけないと思っていたようなのですが、Operability Testing という名前にすることによって、あ、Ops からも要求をだしていいんだと気づいてもらえたみたいです。 |
|
牛尾: なるほど。そういう小さなところでもブレークスルーのタイミングはあるのですね。 |
|
牛尾: ところで、皆さんはDev系の人が多いですが、もし皆さんが Ops の人になったとしたら、Devの人にはどういう課題があると思いますか? |
 |
一同: ... |
|
牛尾: ですよね。今の時代、すべての領域を 1 人でカバーできないと思います。だから、コラボレーションが必要なんだと思いますね。 |
