このシリーズでは、テクニカル エグゼクティブや、エンジニアリング、管理、サイト信頼性の現場担当者など、CircleCI のエンジニアリングに携わるチーム メンバーから、自身にとって「自信」とは何か、キャリアを積む中でその認識はどのように変化してきたかについて話を聞いていきます。現時点では Michael Stahnke, Stig Brautaset, Glen Mailer, Jacque Garcia, and Mike Marquez の 5 名のインタビューをお読みいただけます。
今回は、CircleCI の最高技術責任者 (CTO) を務める Rob Zuber のインタビューを紹介します。どうぞお楽しみください。
あなたにとってエンジニアとしての自信とは何ですか。
そうですね、正当性に関する自信と、設計に関する自信があると思います。正当性に関する自信とは、「これをデリバリーしても問題ない」という自信です。ここで CI/CD の出番になるわけですが、実はコードの正当性には、私は関与していないんです。アウトソースしていますから。テスト システムを使ってコードを評価することで、「よし、機能しているぞ」と自信を持てるようになります。もちろん、私が担当する範囲をもっと増やすこともできますよ。そうして自分が関与したあれこれが、さらに大きな自信を与えてくれます。
もう 1 つの自信は、抽象化、設計などの面で適切な実装方法を選択したという自信です。これは先ほどの正当性に関する自信よりも、もっと私の内面的な自信です。
皆さんもさまざまなことを学習されていると思いますが、学ぶことは単に多くのアイデアを得ることではなくて、多くのパターンを見て、物事がどう展開していくのかを知ることだと思います。その経験を通じて「これで十分うまくいくだろう」という自信が得られるのです。私は自分が今関与していること、これから取り組もうとしていることについて十分な自信を持っています。
学ぶことは単に多くのアイデアを得ることではなくて、多くのパターンを見て、物事がどう展開していくのかを知ることだと思います。その経験を通じて「これで十分うまくいくだろう」という自信が得られるのです。
これは自信を構築するプロセスの中で特に難しい部分でしょう。私はリスクについて話す場を積極的に設けています。リスクを把握していることは重要です。だからこそ、十分に業務にかかわり、問題の重要度に応じて適切な措置を図ろうと努力してきました。または、これが重要なシステムであると知っているからこそ、より多くの業務にかかわり、自信を高めようとしています。
エンジニアリングにおける意思決定モデルでは、その決定による影響や、影響が及ぶ範囲、決定をくつがえす場合のコストを考えなくてはなりません。このため、多くのアドバイザーと関係者から話を聞いて、さまざまな意見を取り入れたうえで、意思決定を行う必要があります。
あなたのキャリアにおいて自信はどう変化してきましたか。
パターン ライブラリを作ることについてよく考えます。経験を回顧するためのライブラリです。わかりにくくてごめんなさい、変わった比喩が好きなもので。
たとえば、ロック クライミングについて考えてみましょう。まず、ゴール付近にかけたロープを登っていくトップ ロープ クライミングに挑戦するとき、「もし足を滑らせたらどうしよう」とつい手に力が入りすぎてしまうかもしれません。そして、実際に落ちてしまったとします。8 cm くらい。「なんだ、大したことなかった」と思うはずです。そこで、今度はもう少し難しいことにチャレンジする気持ちが湧いてきます。別のホールドにジャンプしてみよう。少しくらい落ちても大丈夫なことはもうわかっていますから。次は、リード クライミングをやってみます。これは今までとはまったく違うタイプのクライミングです。でも実際に挑戦し、落下を経験してみると「なんだ、そんなに大したことなかったな」と気づきます。
つまり、自分が恐れていることを経験すると、大きな自信につながるのです。実際に経験すれば、それがどういうことか身をもってわかるようになりますから。怖いのは経験していないからであって、未知のものは恐ろしいものなのです。でも経験してしまえば平気になる。「大丈夫、どうすればよいかわかっているよ。難しいけれど、自分たちなら解決できる」失敗を恐れたままでは、大きなことは達成できません。前進の先に失敗があるのではないかと恐れているかぎり、決して前進することはできないでしょう。
自分が恐れていることを経験すると、大きな自信につながるのです。実際に経験すれば、それがどういうことか身をもってわかるようになりますから。
ツールやオートメーションは、自信という意味でコードへの取り組み方に影響を及ぼしましたか。
あらゆる面に変化が見られました。コードを検証したいときは、ラッパーを作成してテストを行い、その正当性を確認できます。コードをテストしたいときは、テストを行うラッパーを作成します。以前なら、大規模で複雑なシステムにラッパーを組み込み、大規模で複雑な手作業でテストを行おうとしていたでしょう。また、このコードをテストするすべてのシナリオを作成しようとしていたはずです。
今作業している部分だけを切り離すことで、それが適切なのかどうかわかるようになります。自動化されたテストは、自分がビルドした内容が適切かをチェックするには大きすぎます。
クイック デプロイなら、何か問題があっても修正できます。私自身が何かミスした場合でも、不具合のあるコードをリリースしてしまったり、事前に想定していなかった方法で顧客がコードを使用したりして本番環境で問題が発生した場合でも、あっという間に問題を特定して修正できます。なぜなら、その部分だけを修正して、修正を本番環境にプッシュするだけだからです。これは大きな変化ですよね。
Copious を立ち上げたとき、共同創業者の Jim (Rose) から「継続的にデプロイしないとね」と言われたので、すぐにこう返しました。「まるで問題があったときにデプロイを修正する必要がない人のセリフみたいだ。いや、それは恐ろしいアイデアだよ。デプロイは大変な作業だ。徹夜しなきゃならないし、リスクもすごく高い。そんなの継続的にやりたくないよ。睡眠時間を削りたくない」その後、ちょっと読み物をしているときに、リスク プロファイル、リスクの軽減、自分のアクションのリスクについて考えるようになりました。多くの作業を組み合わせると、大きなリスクが生まれます。それがデプロイの難しさにつながるのです。それを小さなパーツに切り分けることで、リスク プロファイルを削減し、エラーのある箇所を切り離せるようになります。エラーの規模が小さくなるので、その内容を把握しやすくなります。
翌朝私はこう宣言しました。「何をすべきかわかった。継続的デプロイをしよう」そして、私たちはシステムの構築を開始し、もう後戻りすることはありませんでした。
改めて自信とは何だと思いますか。
たとえば、何かを構築して、その日のうちに顧客に見せたとします。そういうときに、自負心が生まれるのではないでしょうか。突然自分が何かを成し遂げて何者かになったような。もうテストが終わっていて、自分に能力が感じられるというのは、とても気分が良いものです。
前進しているという手応えがあれば、心は満たされ、「自分は今の仕事に向いている。顧客のために問題を解決できている」とか「顧客が期待しているものを提供できている」と思えます。それはまったく異なるタイプの自信ですが、強く力づけてくれる自信でもあります。自分に自信が付き、自分は達成できると思うことで、もっと多くのことをやってみよう、もっと生産的になろうと思えて、気持ちが高まる。それは多くの問題を覆い隠します。何かを成し遂げられる、価値を生み出している、ミッションにつながっていると感じられることが大切です。
私が継続的デプロイを諦めずに続けているのは、このためかもしれません。顧客の手に何かを届けるまでに、お待たせするのが嫌なんです。
若いころの自分に会えるとしたら、どんなアドバイスをしますか。
失敗から学べ、ですかね。中には、過去に戻って失敗をやり直したいと考える人たちもいますが、もし私がこれまでのキャリアで一度も失敗をしなかったとしたら、今の仕事に就けていたかどうかわかりません。失敗してもよいのです。重要なのは、失敗したときにくよくよ思い悩むのではなく、その経験を振り返ってよく考えることです。すべての失敗には学ぶところがあります。
ちょっと逆説的ですかね。私たちが歩む道の上では、いろいろな面倒や問題が発生します。でもそれを楽しんでもらいたい。そこから何か学ぶことがあるはずなんです。
CircleCI にユーザー登録して、コード作成の自信を高めましょう。
