学長がSREエンジニアの石橋さんにいろいろと聞いてみた。
こんにちは学長です。社長の浜野に代わってみんマで働く人に話を聞いていきます。今回はテクノロジー本部でSREエンジニアとして活躍する石橋さんに話を聞きました。石橋さんはルパン三世の次元大介のようなキャラなので、飾らず実直な人です。そこで、当社のエンジニアの評価制度に対する考えを聞いてみました！
目標設定は”ゆるい”気がする
―よろしくお願いします。いきなりなんですけど、当社のエンジニアの目標設定や評価制度について教えてください。
評価制度は、メンバー同士で技術力を評価するというものです。目標設定も大体それに関連した目標を各々が決めてそれが上から承認される感じです。
―目標は自分で決めるんですね。
自分はそうしてますね。一応、会社の業績にどう貢献するかというポイントはできるだけ入れてくださいねとは言われているので、それっぽい理由を付けて目標を設定してます。だけど「できるだけ」って言われてるので、会社の業績に全然関係ない、自分が技術的に「こういうことをする」みたいな目標でもいいような気がしています。
―いいような気がしているんですね（笑）今のところ石橋さんが立てた目標に対してNOと言われたことはないってことですか？
はい、今のところNOと言われたことはないですね。
ーそれはすごいですね！石橋さんが毎回会社の成長を考えて目標を出しているってことですよね？もしくは、当社がエンジニアの自主性を尊重しているからNOと言わないのか？どっちなのでしょうか。
私もそれは分からないですね。他の人の様子を全く知らないので自分の場合で言うと、出した目標は全部OKと言われてます。良く言えば尊重されているんじゃないでしょうか。あんまり悪く言いようもない気もしますけど。
―当社のエンジニアの目標設定は、会社から与えられるものではなく自分で決めていく自由度が高いものになってるということですよね。
まぁそうですね。これは良し悪しがあると思うんですけど、「もうちょっといけるんじゃない？」とか「これはちょっと厳しいでしょ」みたいな数値の程度の話とか、会社の業績との関連度をすり合わせたり、というようなガッツリすり合わせるような目標設定と比べると、当社の目標設定は”ゆるい”と言うべきか、そんな雰囲気を感じますね。
―そうすると、制度を悪用する人も出てくるんじゃないですか？超簡単な目標を設定するみたいな。
全然ハックできると思います。そうなんですよね。それはちょっと悩みどころで。ストイックに目標を立てても、もしかしてあまり良いことがないんじゃないかっていうのがあったりします。ストイックなものは内なる目標に留めておいて、オフィシャルの目標としてはゆるくするっていう戦略は全然ありだと思います（そういうことをする人が出てくる可能性はあると思います）。
―そういう人はいるかもしれないですよね。でもそれってエンジニアからしたら「それでいいじゃん！」ってなると思うんですけど、石橋さんは「本当にそれでいいのか？」と思ってるわけですよね？
あまりちゃんとした理由はなくて、多分人情的な部分なんだと思います。本当に機械的にハックできる気はしていて、割と達成可能性の高い目標を設定するっていう戦略は全然ある気がするんですけど、なんとなくそこに対して良心が邪魔をする感じです。
―なるほどですね。でも石橋さん的には良心の呵責があるし、もしハックした場合「その目標はダメです」って言われるかもしれないわけですね。ある意味で自分の「職業倫理観を試される制度」かも知れませんね。
もしかしたら、そうですね。
―もう一つ、エンジニア間で技術力を評価する相互評価制度に関してはどう思いますか？
一緒に仕事をしている同僚からの評価なので、ある意味一番実態が反映されるというメリットはあるような気がします。一方で、たまには同僚からだけじゃなくて上司からの評価があってもいいんじゃないかなって気はしてます。
―エンジニア間の相互評価が実態に即しているなら、上長評価はなくてもいいのかなと思うんですけど、そこは違うんですか？
メンバーではなく、マネージャー的な位置からの評価ってまた少し違うと思うんですよ。メンバーからはあまり発想されないような評価があってもおかしくないと思うので、そういう評価がたまにはあってもいいかなという気持ちはありますね。ただ当社の場合、上からの評価というとCTO一人だけなんですよね。CTOの上となると社長なので。評価する上長が一人しかいないというところが、ある意味デメリットかなとは思います。CTOよりももう一段階下の立場の上長がもしいたら、健全な上長評価になる気はします。
―結論としては、石橋さんは今の当社の評価制度に満足しているけれど、たまには上長評価があってもいいんじゃないかということですね。
はい、そんな感じですね。
非機能的な改善に注力できる面白さ
―石橋さんはみんマに入社する前は何をしていたのですか？
BtoBの会社でSaaSの開発運用をやっていまして、いわゆるインフラエンジニアと呼ばれるようなことをやってました。自社でデータセンターにサーバーがあるオンプレミスの状態から、その後AWSを触るようになって、AWSの面白さに気づきました。現在も「AWS楽しいな」という気持ちでみんマにおります。
―今、石橋さんのチームではどんな仕事をしているのですか？
SREというチームにいて、基本的にはプロダクトのインフラ周りの面倒を見ています。一応「開発者体験向上」みたいな取り組みも我々のチームでやっていると言えるのかなという感じです。ここについては一般的によく言われるSREとは結構違う可能性があるので、いわゆる「SREっぽいことをやってます」という感じではない可能性があります。
―そもそも「開発者体験向上」ってどういうことですか？
自分が開発者ではないと一旦仮定すると、社内にいっぱい開発者がいるわけじゃないですか。その人達がくらしのマーケットの開発をやっているわけですけど、そのために必要なテスト環境などを整えるということですかね。
―なるほど。だとすると「開発者体験向上」の業務も含めて、当社のSREチームの仕事として面白いところはどんなところですか？
基本的には、エンジニアの皆さんはプロダクトの機能を作ってリリースするということを一生懸命やられているんですけど、その一方で、我々SREチームは機能ではない非機能の改善を行う責任があると思っています。多分一般的なSREもそうだと思うんですけど、非機能的な改善に注力できるというのは面白いことだと思ってまして。こういうウェブサービスのシステムは様々なコンポーネントで成り立っていて、それらが複雑に絡み合っています。機能を開発する上では、必ずしも全体を知らなくても開発できるという側面はあったりするんですが、一方で、普段そうやって開発者が見ないところを見て改善していくっていうのは我々がやるべきことだし、個人的には誰も触っていないところを自分がいい感じにしてやるぞっていうのは楽しいところだなと思ってます。業務的にISUCON（いい感じスピードアップコンテスト）みたいな状況になることもまぁまぁあって楽しいです。普段開発者があまり見れていないところで、実はすごく遅くて使いにくくなっているようなところをスピードアップさせたりできると、めっちゃ達成感がありますよね。
―くらマ全体を見た時に、問題だと思うことは何ですか？
AWS周りでもそうなんですけど、それぞれの設計意図のドキュメント化があまりされていないような状況があります。雰囲気で歴史を読み解くしかない、知ってる人がいたらラッキーみたいな状況ですね。外側からは見えない部分ですけど、これは結構分かりやすい課題だと思いますね。ただここについては、自分からInfrastructure as Codeという技術要素を社内に布教して、導入するみたいなことは実際にやりました。
―今もそれは取り入れられているのですか？
はい、やってますね。今まで結構塩漬けにされてきたリソースとかについてアーキテクチャをより良い感じにしたり、そのタイミングでInfrastructure as Codeを取り入れるっていうのを最近、僕だけじゃなくてテックみんなでやってます。自分が元々Infrastructure as Codeが好きだったので社内で推して、半ば布教していくような感じで進めました。自分としてはInfrastructure as Codeによってこういう管理をした方がいいよねという青写真があるので、それに向かってみんなに「これいいよね、これをやっていこう」って呼びかけていますね。
―石橋さんがいいなと思うものをみんなに理解を求めていって、実際にそれがテック全体に取り入れられているんですね。それは素晴らしいですね。
あえて意識してデメリットを考える
―石橋さんが考える優秀なエンジニアってどんな人ですか？
日々の仕事において高い視座で取り組める人、それぞれのメリットデメリットを意識できる人、適切に人を巻き込んで仕事ができる人、動くだけで満足しない、動かした後の運用しやすさなどを考慮する人かなと思います。
―高い視座で取り組むというのは具体的にどういうことですか？
いちメンバーとしての立場でいうと、例えば与えられた仕事があるならその仕事だけに目が行ってもおかしくないと思うのですが、それだけでなく自分の担当範囲以外の業務や人にも目を行き届かせながら仕事ができる人に憧れます。くらしのマーケットは特にシステムが大きく、様々なコンポーネントや人が絡んで動いてるので、特にそうあるべきだと思いますね。
―それは当社のプロダクトの性質上、と言えますか？
いや、これは会社員をやってる以上、一般的にそうあった方が優秀かなと思いますね。
―確かに一人で仕事をしている訳じゃないですからね。「メリットデメリットを意識できる人」も挙げていたと思いますが、これまでお話を聞いている中でも、石橋さんは比較的断定的な言い方ではなくて「これにはこういう良い面があり、こういう悪い面がある」みたいな言い方をされているのがすごく印象的だったんですけど、普段からそこは意識されてるんですか？
そうですね、考えている気がします。自分が良いと思ったことがあるとそればっかり見ちゃうことってありがちなので。あえてデメリットも考えることは、意識していますね。逆に言うと優柔不断になってしまう側面もあるんですけど...。
―それはやっぱりエンジニアとして、システムを開発する時に必要な考え方として意識しているところなんですか？
そうですね。開発はもちろんそうですし、開発してしまった後で「やっぱりこうすれば良かったな」と思うことが経験としても割とあって。最初に着手する段階では考慮できなくても仕方がない問題もいっぱいあるんですけれど、考慮できる問題もいっぱいあるので。それはちゃんと考えた上で開発して動かし続けていくというのは、信条としてある気がしますね。
―そこが「動くだけで満足しない、動かした後の運用のしやすさを考慮できる人」にも繋がってくるんですね。
そうですね。自分でも話しながら、なんやかんやで全部繋がっている感じがしてきましたね。
推しポイントは「開発者体験の良さ」
―最後に、みんマでエンジニアとして働く良さはどこにあると思いますか？
みんマでエンジニアとして働く良さとして明確に推せるポイントだと思っているのは、さっきも話した「開発者体験の良さ」だと思っています。自分がやった変更を柔軟且つ安全にデプロイできるし、すぐにデプロイされるのでユーザーに使われているのを実感することもできる。その仕組みや文化は、会社の規模にしてはかなりイケてる気がしますね。
―開発者体験をどんどん良くしていくというのは、石橋さんが今までやってきたことでもありますよね。
実を言うと、僕が入社した時点ですでに開発者体験は良かったんです。なのであんまり大きいことは言えないんですけどね！
―そうだったんですね。では、逆に石橋さんが今後取り組んでいきたい課題はありますか？
開発者体験が良い一方で、開発者にとっての使いやすさを求めるあまり、その動作環境がシンプルじゃなくなってるというのはあると思います。最近聞いて印象的だったのが「イージーとシンプルは違う」っていう言葉なんですけど。まさにうちの場合、開発者にとってはイージーだけど、その裏の仕組みや動作環境が複雑になっていて変更しにくい、みたいな状況になってて結果的に塩漬けになってるコンポーネントがあるという課題があるのかなと思いますね。個人的には今後はもっとシンプル化していきたいなという思いがあります。
―分かりました。ありがとうございました！
当社は石橋さんだけでなく、職業倫理観の高いエンジニアが多いと思います。しかし、事業が成長すると色んな人が集まるので評価制度をハックする人も出てくるでしょう。「目標をハックする」「仕事をサボる」など、職業倫理観の低い人のせいで、割を食うのはいつも真っ当に働いている人です。みんマらしさを維持するためには、働く個々人に高いモラルが求められると思いました。ところで、Vimって何ですか！？
実は、石橋さんからこの「あとがき」に対して修正依頼をもらいました。石橋さんは高い職業倫理観で働いているのにも関わらず、私の「あとがき」は自分の考えと合わないと言うのです。
「目標のハックは、ハックする側の問題ではなく、目標制度設計をする経営者の責任である。従業員に高いモラルを求めるのはどうなのか？」という趣旨でした。
なぜ高い職業倫理観で働く石橋さんが、低い職業倫理観の人を利するような修正を依頼したのか…私には理解できませんでした。
私は制度やルールをハックして悪用する人や、働いているふりをして働かない人は（同じ従業員の立場からしても）会社の成長を妨げる迷惑な存在だと考えています。だからこそ、石橋さんのスタンスを肯定する意味で書いたのに、どうしてそんなこと言うの？…と思ったわけです。
おそらくそれは、モラルや善悪の話では無いんです。「システムに穴があれば、それは開発者の責任である」という石橋さんのプロ意識に由来しているのだと思います。それが潜在意識に染み付いているからから、石橋さんは責任感を持ってシステムを作れるのだと理解しました。
あなたにエンジニアとしてのプロ意識はありますか？