SUPER STUDIOで実施している社内表彰制度「SUPER STUDIO AWARD」の受賞者を、7回に渡って紹介しています。

今回紹介するのは、2022年度MVI（Most Valuable Innovator）を受賞したプロダクトエンジニアリンググループ / ビッグデータユニット / グロースチームに所属するRavi（ハヴィー）さんのインタビュー。前回に引き続き、COOの花岡がインタビュアーを務めます。

Raviさんは大きなプロジェクトに自ら参加を希望し、その推進に積極的に関わってきました。技術力の高さだけでなくスクラムマスターとしてチームを引っ張る力もあり、プロジェクト成功の立役者といえる存在です。

特に技術面では定評があり、AWS関連の知識や確かな実装力は社内からも大きな信頼を得ています。最近はさらに高いコミュニケーション力や気遣いで、プロジェクトの雰囲気作りにも大きく貢献しています。

システム移行の半自動化を目指すm4プロジェクトでは、大幅なコストの改善、安全性向上、高速化を実現しました。今やSUPER STUDIOに欠かせないエンジニアとして高い総合力を持ち、ビッグプロジェクトにアサインされています。

これらの活躍が評価され、2022年度のMVI受賞に至りました。

今回はそんなRaviさんに、自己成長する上での考え方やマインドを中心に話を伺いました。

－まずは自己紹介と、今までのキャリアを簡単に教えてください。

Ravi：ブラジル出身で、メカトロニクスエンジニアリングを学んだあと日本に来ました。ほぼ未経験でSIerのWebエンジニアの仕事に就いて、請負プロジェクトとしてアーキテクチャ、基盤作り、インフラ周りを担当し、4年間で幅広い経験をしました。SUPER STUDIOに入社したのはその後です。

－前述の半自動化プロジェクトで大きな成果を出したことが今回の受賞につながりましたが、プロジェクトに対してどのように関わっていったのかを教えてください。

Ravi：m4プロジェクトは顧客であるECメーカーが別のEC基幹システムからecforceに乗り換える際のシステム移行を半自動化することが目的のプロジェクトです。私が入社したときはこの半自動化の実現に向けてインフラ周りの整理をしようとしていた段階でした。

そこで、まず自動化する前はどんな作業をしていたのかを見て、改善点はどこかをメンバーと一緒に考えました。実際に基盤を作り、自動化できるところを自動化していく、というようにプロジェクトを進めていきました。

－プロジェクトを進めるにあたって、意識していたことはありますか？

Ravi：プロジェクトの推進には技術力だけではなく、ソフトスキルも高めるように意識していました。

m4プロジェクトは、先程もお話ししたように改善点をメンバー全員で見つけ、改善案を出し合って、まとめて、少しずつ改善や自動化を繰り返すというやり方で進めていました。

この方法でプロジェクトを進める場合は、コードを書く力に加えてプロジェクトマネジメントの力も必要になってきます。しかし私は当時、プロジェクトマネジメントに必要な知識をまったく持っていませんでした。

そこで、スクラム運営に関する本を読んで知識をつけました。スクラム運営そのものというよりは、事例を多く交えながら、スクラムの中身や理由について説明している本でした。この本を読んだことで、プロジェクトをスムーズに進められるようになったと思います。

－スクラムなどのフレームワークは、現場によって相性の良し悪しがあると思います。m4プロジェクトとスクラム運営の相性はどうでしたか？

Ravi：実は、最初のうちは検証が多く、何をどれくらいの時間使うか把握できず、スプリントに分けにくかったんです。そこで途中から、カンバン方式で優先順位を決めてやっていく方法に切り替えました。こちらの方が相性は良かったと思います。

メンバー全員、スクラムがうまく進められていないことになんとなく気づいていたんです。そこで、どうすればいいか議論をして最終的にやり方を変えました。

－相性が実は良くないとわかったからやり方を変えたということですね。課題に気づき、やり方を変えるのは大切ですね。技術力はどのようにして高めているのでしょうか？

Ravi：プロジェクトで使う同じ技術でサイドプロジェクトを作ることが最初のステップです。何を作るかを決めて、そのために必要な知識を身につける。この方法が一番効率よく技術力を高められると思っています。

最初にいろいろ調べてから作る方法だと、調べているときにはわかったつもりになっていても、実際に何か作ろうとするとわからないことが多く出てきてしまう。そうなると、精神的にも負担がかかってしまいます。

－サイドプロジェクトを作り技術力を高める方法は再現性が高そうですね。どのようなものを作っているのか教えてください。

Ravi：会社の業務とは関係なしに、個人的に作りたいものを作っています。アイデアがないときは、本当に簡単なクローンを作ることや、特に目的のないシステムを作ることもあります。

いつか自分のプロダクトをゼロから作りたいという目標があるので、成長したいというモチベーションで学習しています。

－プロジェクトメンバーとの関わり方について意識していることがあれば教えてください。

Ravi：エンジニアの立場としては、できるだけ自分から技術関連の提案をして、相談できる場を作ってメンバー同士で決めていくことを意識しています。

スクラムマスターの立場になったときは、自分のやりたいことを一方的に押しつけないことを意識しています。やりたいことの理由やその根拠をメンバーに開示して、同じ方向を見てもらえるようにする。同じ情報をインプットすれば、最終的にみんな同じ結論になるはずだと思っています。

あとは、良い意味で期待しない。シンプルな技術でも、使ったことがなければわからない、できないのは当たり前。だからメンバーに対しても「できなくて当たり前」という考え方をすることが多いです。

－同じ方向を見てもらえるように、というのは良い考えですね。確かに、全員の情報量が同じなら、チーム全体が合理的な判断に収束していくものですし。

Ravi：「このやり方が良いんです、信じてください」と言われて従った方法と、自分で「このやり方が良い」と信じた方法だと、後者のほうがモチベーションも上がります。理解度も、責任感も違ってきます。

－大きなプロジェクトに名乗りを上げるなど、常に積極的に仕事を取りに行く姿勢ですが、そのような姿勢でいられる理由を教えてください。

Ravi：根本にあるのは「成長したい」という気持ちです。

同じような作業を続けていたら、慣れが出てくるしモチベーションも下がってしまう。新しい、面白いことに挑戦し続けていたいです。その方がストレスもないですから。

あと、私はタスクの調整をしっかり行うので基本的に残業はしません。新しいことに挑戦したとしてもタスクの調整をする前提なので、残業が増えることもないです。仕事を取りに行ってもデメリットは特にない、というのも理由のひとつですね。

－「成長したい気持ち」に関連してですが、上長からフィードバックをもらったときに、どう咀嚼して改善を進めているのでしょうか。

Ravi：フィードバックを受けたら、成長のために必要なことは何か、どんなアクションを起こせばいいかを考えます。自ら、次のレベルに行くために求められることやどうすればいいかを相談することも多いです。

自分より少し上のスキルを持った人や役職者から、自分に何が足りないか、どうすればレベルアップできるか客観的にアドバイスしてもらうことって大事だと思います。自分の認識と外から見た自分は違うことも多いですから。

－技術力を高めた人は、ビジネス的側面にも目を向けることが多いように思います。Raviさんはどうでしょうか。

Ravi：エンジニアリングに限らず、本当に良いプロダクトを作るためにはビジネス的側面も必要になっていきます。だから、マネジメントフローやお客様から見たサービスの価値など、技術だけでは解決できないところを学びたいと思っています。最近はマーケティングやブランディングにも興味を持つようになりました。

－ありがとうございます。最後に、SUPER STUDIOのVALUEで意識しているものがあれば教えてください。

Ravi：SUPER STUDIOのVALUEと自分の価値観は、かなり近いと思っています。だから、意識することはあまりありません。大体無意識のうちに実践しているように思います。

例えば、新しい技術を試したり、フローを改善できないか考えたりするのは「CHANGE」。変化し続けていれば慣れや飽きがこなくていい、と私自身思っているので、自然とCHANGEはし続けていると思います。

改善点がないか考え、見つけたら改善を提案することは「INSIGHT」。わからないときは「わからない」と言う、傲らずに困ったときは助けを求めるなどは「HONESTY」。どれも私にとってはごく自然なことだな、と。

－確かに、Raviさんはとても素直に「わからない」と言いますね。とても大事なことだと思います。

Ravi：人との関わりがすごくシンプルになるので、素直になって悪いことはないと思いますね。どんなにシンプルな技術のことでも、わからないことはわからないので、聞き手へ過度に期待せず話し手も期待値調整をすることは大事です。「わからない」と言ってもSUPER STUDIOには迷惑がる人はいないので、もっと素直に伝えて良いと思います。

MVI受賞者のRaviさんのインタビューを紹介しました。特にエンジニアの人には、サイドプロジェクトを作って学ぶ、フレームワークに固執しないという点が参考になったのではないかと思います。

また、情報量をそろえてチーム全体で同じ方向を見る、成長のために必要な情報について自らフィードバックを貰うなど、エンジニア以外の人にとっても参考になる話もありました。ぜひ、日々の仕事に取り入れてみてはいかがでしょうか。