シェア
ツイート
ブックマークさまざまな現場でQA業務に携わっている方々の「声」をお届けする『隣のQAに聞く！』。社会のデジタル化が進み、クラウドサービスを活用して企業変革を推進する時代になっています。その流れもあり、さまざまなクラウドサービスへの関心が高まりを見せ、同時にアプリやソフトウェアの品質も重視されるようになりました。そんな中、他のチームでは、どのようにQA業務を実施しているか、気になっているエンジニアの方も多いのではないでしょうか？
本記事では、QAに取り組む上でのポイントなどを伺い、皆さまにお伝えします。
今回はランサーズ株式会社の三宅勇魚さんに、同社の専門チームやポジションがない独自のQA活動についてお話をいただきました。
今回インタビューを受けてくださった方
- 三宅 勇魚 氏
ランサーズ株式会社 Productivityチーム
豊田工業高等専門学校卒業後、大手エアコンメーカーに入社。製造現場にて組み立てや改善を担当し、トヨタ式「カイゼン」を学ぶ。エンジニア派遣の会社に転職し、 VBAでの業務改善やコンサルティングの経験を経てWeb系エンジニアにキャリアチェンジする。2021年ランサーズにジョイン。Productivityチームにて開発生産性向上のための業務を担当。大阪からフルリモートで勤務中。
- もくじ
ものづくりの経験を生かしてDevOpsの実現を目指す
――まずはこれまでのご経歴をお聞かせいただけますか。
私のキャリアはエアコンメーカーからスタートしました。そこで3年ほど働き、トヨタ生産方式をはじめとする、ものづくりの基礎となる体系的な知識を学びました。その後、業務改善エンジニアという仕事を経て、現在はランサーズのProductivityチームに所属しています。トヨタ生産方式は、ウェブの世界では「リーン開発」や「リーンマネジメント」と呼ばれます。
製造業で培った知識や経験を活かしながら、今はDevOpsの実現をミッションとして幅広い業務を担当しています。
――製造業からウェブ業界だと大きく異なる印象ですが、どんな転職動機があったんですか。
私は学生の頃に情報工学を専攻していました。その当時は卒業後プログラマーになることへのハードルがかなり高いと感じていて、進路選択ではソフトウェアの世界に踏み込むことができませんでした。それで一度は機械系の会社に就職しました。でも製造の仕事を通して手を動かすうちに、やはりソフトウェアの世界でやりたいことがあると自覚し始めました。製造で得た仕事への自信から、当初感じていた心理的ハードルも徐々に下がっていき、やっぱりソフトウェアの世界に行きたいと思って転職しました。
――数ある企業の中でランサーズを選ばれたのは、そうした製造業や業務改善エンジニアの経験を活かせるからですか。
経験もそうですが、一番はカルチャーが自分の価値観と合っていたからです。ランサーズの行動規範「ランサーズWay」の1つに、「アクションアジャイル」というものがあります。これは「ユーザーにとって真に価値のあるものをより早く提供するために、率先して動いていこう」という内容ですが、私は製造業でもウェブ業界でもその部分は一致して重要だと思っているので、目指す先が同じというのは大きなポイントでした。
コロナ禍によりオンラインでの仕事マッチングの需要は伸びている
――御社のサービス・ミッションについて教えてください。
ランサーズは、仕事を発注したい企業と、スキルを持つ個人をマッチングするプラットフォームを提供しています。350種類以上の多様なカテゴリで実績を持つプロに仕事を依頼でき、低コストでスピーディーに成果物を得られるのが特徴です。
当社は「個のエンパワーメント」をミッションに掲げています。これは、個人の力が最大限発揮できる社会を実現するということです。個人の持つ才能やスキルが誰かに届いて、それによって価値を生むことができれば、住む場所や働く時間に縛られず、より自分らしいライフスタイルが実現しますよね。ランサーズでは、それこそが「個のエンパワーメントが実現した社会」という風に考えています。
――コロナ禍をきっかけに多くの企業でリモートワークが普及しましたが、そんな社会背景の中でランサーズを使う方は増えているのでしょうか。
コロナ前後の登録者の増加数で言いますと、コロナ前の2019年4月とコロナ禍の2020年4月の1カ月間を比べた場合、動画編集者などを含む映像クリエイターの登録者数が約500％増加したというデータが出ています。コロナ禍で在宅勤務が主流になったことや、通勤時間がなくなったことから時間の余裕ができ、今まで挑戦してみたかったものに挑戦する人が増加したと考えられます。
また、発注側においても、コロナ禍でYouTubeやTikTokなどの動画コンテンツが人気となり、サイトや広告なども動画を利用する場が広がりました。それによって「動画編集」のカテゴリの発注数の増加率がコロナ前後で最も高い結果となるなど、社会背景に伴い、新たな利用者が増えているのではないかと思います。
開発スピードを確保するため開発者が自らテストを行う
――御社のQA業務の位置づけ、ミッションをどのように設定されているか教えてください。
この話をすると驚かれる方も多いのですが、ランサーズにはQA業務を専門とするチームがそもそもありません。
チームもなければ、肩書きとしてQAエンジニアのようなポジションもいない。じゃあ、どうやって品質を保証しているのかという話になるのですが、ランサーズでは開発者が自らテストを行うことで品質と開発スピードを確保する運用にしています。
というのも、前提として「設計やエンジニアリング、開発、QA、オペレーション、運用のような特定のプロセスやロールでチームや組織を分断してしまうことによっていろいろ不都合ってあるよね」という共通認識があり、それを解決していくのがProductivity チームが重要視しているDevOpsの考え方なんです。
――では、三宅さんが所属するProductivtiyチームはどのような役割があるのでしょうか。
そもそも「Productivity」は日本語で生産性を意味する単語です。プロダクト開発における生産性をいかに向上させるか、そのために必要なことはすべてやる、そういう役割のチームです。
開発者自身がテストを行う体制だと、属人化が問題として指摘されることがありますが、テストを開発者自身が行うということは、近視眼的に見ればアジリティ高くテストを実施してサービス機能をリリースすることが可能になります。
属人化という課題に対しては、たとえばE2Eテストを行うツールとしてmablを導入したり、ドキュメンテーションの運用ルールを明文化してNotionを使ってリファレンスを整備したりしています。
また今後は、組織構造としてドメインの知識が高く求められるようなところは、個人をアサインするのではな くチームをアサインする形にしていきたいと私は考えています。
――サービスの品質を改善するために業務上、何か工夫されていることはありますか？
「品質」という言葉自体、定義が曖昧というか、切り口がいろいろあると思うんですね。古いもので代表的なものだと「狩野モデル」なんてのもあったりしますが、現在、一番力を入れている取り組みは、外部品質の悪化、いわゆるリグレッションを可能な限り早く検知して、ユーザーに対する悪影響を最小限に組み止めましょうというものです。
詳しく説明すると、障害が発生してからその障害が修復するまでの時間の平均値でMTTR（平均障害復旧時間）というものがあり、この改善に力を入れているというところです。
なぜここに力を入れているのかというと、課題が複数ある中で自分たちの現状で「最もボトルネックになっているものは何だろう」と定量的なものから定性的なものまで議論しました。その結果、「何らかの不具合がそのユーザーの手元に届いてしまってから、それが発覚するまでの期間が業界平均と比較してかなり長いんじゃないか」という話が出て、まずはMTTRを真っ先に修正していくのが効果的だろうと現在動いている最中です。
――御社のようなSaaS系サービスは24時間サイトが稼働している中で、もちろん深夜対応も発生する可能性もありますよね？
そうですね、まず問い合わせ対応という点では、窓口のスタッフは1年365日稼働しており、技術的な障害はオンコールでアラートが発生したら対応するような体制になっています。すごく不思議ですが、技術的な障害は必ずと言っていいほど深夜に起こり、真夜中にサーバーが落ちるんですよね（笑）
品質課題は組織課題、組織が同じ方向を向いて協力することが重要
――これまでさまざまなチャレンジをされてきていると思いますが、ミッションの遂行にあたってどのような苦労を経験されてきましたか。
さきほど品質保証QAに対する取り組みの質問の中で、E2Eテストを自動化するツールを入れた事例を紹介しましたが、このツールに関しては一度方針を立て直そうってことで導入を断念しました。
実際に導入してみたところ、期待していた課題の解決とは別に、長年開発を続けてきたサービスゆえの、別の課題があることに気づき、E2Eテストを自動化するのが非常に難しいことがわかったんです。そこで別途抱えている問題を解決した後に、再度取り組む方がいいだろうと結論に至りました。
――では、また新たな取り組みとして今後は別の形で進めているのでしょうか。
はい。代表的なものとしては、先ほど説明したアーキテクチャ上の課題を解決する、リアーキテクチャリングの取り組みがあります。
リアーキテクチャリングを行うチームが中心になって、アプリケーションの内部の仕組みを、継続的なサービス開発を意識した仕組みに作り変えていく、いわゆる技術的負債を解消する取り組みをしています。
――社内で品質について課題になっているところや、改善したい点はありますか。
改善したい点でいうと、組織構造とソフトウェアのアーキテクチャを一致させていきたいと考えています。ここまで説明している通り非常に難しい課題に取り組んでいると思います。
これは、現場のエンジニアが気合いと根性でやるだけでは駄目なんですよね。それだけでは乗り越えることはできないと僕は考えていて、ボトムアップだけの変化ではなくてトップダウンで組織の上からも下からも同じ方向を向いて協力し合って変えていくことが重要ではないかと考えています。
このトップダウンっていう観点でいうと、いかにエンジニアの認知負荷を下げていくのかをテーマにして、組織構造を作り変えるとか、組織の構造もアーキテクチャに合わせて変えていく必要があるのではないかという議論を最近はしているところです。
「いかに自立した開発組織を作っていくか」が今後の課題
――どんなときにQA業務のやりがいを感じますか？
やはり「ユーザーのために」を体現できるときですね。ランサーズでは行動指針である「全てはユーザーのために」という共通のカルチャーを軸にして、全員で目標に向かってやっていくことができます。
例えば、QAを担当するチームやエンジニアが不在であるからこそ「全員でやらなきゃいけないよね」とエンジニア一人一人が品質に向き合う文化が芽生えつつあり、その中で自分がどういうバリューを発揮できるのかというところにQA業務の面白さがあるのではないでしょうか。
――今後、業務を通じて達成したいことがございましたらお教えください
僕の達成したい目標に「自立」というキーワードがあります。個々人がユーザーや品質、技術に向き合った結果、行き着く先こそがこの「自立」だと僕は捉えていて、その上で自立した開発組織や自立したチームをいかに作っていくのかが課題だと思っています。
難しすぎていつもめげそうになりますが、「どうしたら自立できるんだ？そもそも自立ってなんだ？」といつも考え、悩みながらやっているところです。
――本日はお時間をいただき、ありがとうございました。
