2023.05.09
テストエンジニアから開発エンジニアへキャリアチェンジしたとき、どんな経験が活きるのでしょうか。
今回はバルテス・モバイルテクノロジー株式会社（VMT）開発部マネージャーの荻野 和俊（おぎの かずとし）さんにお話しを伺いました。
荻野さんはテストエンジニアとしてキャリアをスタートさせ、その後、開発会社であるVMTの立ち上げに携わり、現在では開発者として第一線で活躍しています。
VMT立ち上げ当初にあった苦労話や、両方を経験して見えてきた点などについてお話しいただきました。
今回インタビューを受けてくださった方
- 荻野 和俊
バルテス・モバイルテクノロジー株式会社
開発部 マネージャー
立命館大学 情報理工学部卒。2011年、バルテス株式会社に入社。テストエンジニアとして2年間の実績を積んだ後、当時社内で新規事業だったシステム開発事業（バルテス・モバイルテクノロジー）の立ち上げメンバーとして抜擢。Windowsアプリ、Webシステム、スマホアプリ、エンタープライズ系システム等、様々な開発実績を経て、現在ではVMTのマネージャーとしてプロジェクトマネジメント業務に従事。
- もくじ
テストエンジニアとして入社、その後開発へ
――開発エンジニアではなく、テストエンジニアとしてキャリアをスタートさせたと伺っています。そもそもなぜテストエンジニアになろうと思ったのでしょうか？
荻野氏：大学の専攻が情報系の学部で、プログラミングやアルゴリズム、インターネット関連の技術を学びました。開発エンジニアを希望し就活していたのですが、たまたまテスト専門会社のバルテスと出会ったんです。リリース前の製品のテストをする人達がいるというのもバルテスで初めて知りました。決め手はテストエンジニアの方々がキラキラと輝いていることでしたね。誇りをもって品質担保しているという自信を感じました。
――どういう経緯で品質エンジニアから開発エンジニアにキャリアチェンジすることになったのですか？
荻野氏：新卒で入社して2年ほどバルテスでテストエンジニアとして勤務しました。
その後VMTが発足する際、社長から「開発を勉強していたならVMTで開発をやってみないか」とオファーを受け、立ち上げに合流し開発に携わることになりました。
――「開発にチャレンジしたい」という気持ちは当初からあったのでしょうか？
荻野氏：当初全く考えていませんでした。私自身結構テストにハマっていたんです。不具合が出せると嬉しいですし、効率的なテスト戦略を考えたり、顧客に感謝してもらえたりすることも多く、やりがいを感じていたので、ずっと続けていきたいと思いました。5年、10年ぐらいはテストエンジニアで行くのかと思っていましたので、正直2年でキャリアチェンジするのは抵抗がありました。テストで「できるようになった」という実感もなかったんですよね。
――それでもテストエンジニアから開発エンジニアになった、最終的な決め手は？
荻野氏：テストのやりがいもありましたが、会社立ち上げに関わることで「もっと大きな課題と戦えるのではないか？」と考えました。新規の会社に行くということはチャレンジとして魅力的だと思えたんです。
VMT移籍後は苦労や失敗、試行錯誤の連続
――VMTに移籍してからどんな仕事をしていましたか？
荻野氏：最初、黒澤明監督の映画「七人の侍」のような、エンジニアの精鋭部隊を作ることを会社は目指していたんです。AndroidとiOSを同じソースを共有して、同時に作成できる「Flutter（フラッター）」や「Cordova（コルドバ）」のような、アプリ開発のフレームワークを作りたいという考えでした。その頃は既に「Cordova」はあったんですが、それの対抗馬を作りたいと考えていました。当時は2人で企画/研究開発しており、コンセプトはネイティブソースを生成することだったのですが、OSアップデートの影響を大きく受けるという課題を解消する案が出せず、結局、2か月程度で計画は白紙になりました。
業務システム系などのBtoBのお仕事を獲得したいと考えて展示会への出展も行いました。アピールのために面白いアプリを作れないか？と社内で企画を考え、一般コンシューマー向けのアプリを開発しました。それが「よせ音」というアプリで、写真を撮るときに周囲の音を録音したり、あとから音声を追加できるアプリでした。スマートデバイスの業務利用を狙っていたこともあり、NFCやBluetoothなど最新技術を組み込んだアプリにしました。これが営業ツールとしては好評で、次第に商談も増えました。ちなみに何度かテレビでも取り上げられたことがあります。こうしてシステム関連の仕事も徐々に増え始めました。
――テストから開発だと仕事内容が全く異なるので、移動当初は相当大変だったのではないでしょうか？
荻野氏：はい、色々なことがありました。会社として立ち上がったばかりの頃、実績がなく仕事を取れないので、失注するたび次の見積もりはチャレンジングに少ない工数で安く見積もってしまいました。結果、圧倒的に安い金額で受注できてしまったんです。絶対やっちゃダメなことだったんですが、どれだけ赤字になるか覚悟してやったわけではなく、工数を減らしていって、受注してしまったんです。この時、費用を下げるだけでなく、工数に合わせたスケジュールにしてしまったのも問題でした。例えば制作に10ヶ月必要なシステムに対し、「4ヵ月で作れます」と無茶な期間と工数で提案してしまったんですね。
結局、グループ全体で協力してもらいプロジェクトを立て直しました。お客様と上手く交渉をし、期間を伸ばしたり、フェーズ分けをしたりなど整理することでプロジェクトを進めやすくしたんです。他のプロジェクトを中断して、そのプロジェクトに携わっていた優秀な方を集めるなどして、何とか立て直すことができました。その時はフィリピンにある「VAT（バルテス・アドバンスト・テクノロジー）」にいる海外のメンバーも加わってくれました。海を跨いで巻き込んだ大プロジェクトになってしまいました。
苦労した経験を活かし、社内体制の改善を実施
――大変なご経験をされたんですね。苦労した経験からどんなことを学べたのでしょうか？
荻野氏：苦労や失敗から学んだ部分は多くありますが、一番はプロジェクトの進め方ですね。フォーマットを変えたり、同じやり方を変えたりと徹底して行いました。立て直した頃に作った設計書のフォーマットは今でも改善しながら使ってます。システムの要件や開発に集中できるようになるべく考えることを減らすようにしていますね。ただし、全員の想いとかを共有できているわけではないので、それを活用できている人は社内でも一部になってしまっているのが現在の課題です。
先ほどのエピソードで語ったような大変だった当時と比較すると、環境は整ってきたと感じます。ちなみに、その後も案件のPLをやらせていただくことが多かったんですよ。そういう意味では、VMTに移って最初の2〜3年はかなり鍛えられました。
――実績を積んで変化してきたことはありますか？
荻野氏：案件の内容が変わってきました。実績を積んだことで、官公庁系の仕事にも取り組むようになりました。案件が受注できた時は大規模業務システムの要件定義から、基本設計までやらせていただいています。官公庁の案件は実績がないと無理ですから、業界にある程度詳しい開発者が対応するというのが定石です。
開発もテストも、ユーザー側とシステム側の双方の理解が必要
――テストエンジニアをやっていたからこそ開発エンジニアでも役に立ったということはありますか？
荻野氏：テスト設計は頭の中でユーザーがどう使うかをイメージしてテストするんですが、開発設計も実は同じなんです。ただ、開発エンジニアはそうしたバリエーションより「どう実現するんだろう」と実現性の方に目が行ってしまうんですよ。そうすると、たまに「そんなもの作っても使えない」というものを作ってしまうことがあるんです。常にユーザーを意識した開発ができるのは、プラスに働いていると思います。
他にも、私はテストの重要性をバルテスで叩き込まれたので、細かいところをケアした設計をしたんです。そうしたら、お客様に評価いただけました。テストエンジニアの経験を積んできたお陰で、顧客にとっての品質の影響度や重要性を理解しています。
――テストエンジニアと開発エンジニア、両方を経験して特に違うと感じた点は？
荻野氏：開発はお客様から要望を引き出して、意図を汲み取って作り込む、といった、考えることや、決めなくてはいけないことが多岐にわたります。ただ、重要なポイントはお客様と合意を取る点にあります。お客様はシステムのことは分かりませんから、システム上のつくりを説明して合意をとっても意味ないですし、お客さんの質問にも答えられるよう、システム上でできることできないことなど、熟知しておく必要もあります。
開発に移動してからは、ずっと新しいことを勉強しながら業務する日々で、その間はテストのことも忘れていました。なので、最初の頃はテストの経験を活かせませんでした。テストエンジニアから開発エンジニアになってもすぐにテストの知識が役に立つわけでもなくて、一からやり直しですね。1年半経ってからようやくテストのことを考えながら設計できるようになりました。
――テストと開発で共通して考えなければならないポイントは何ですか？
荻野氏：テストと開発には仕様理解という共通点があります。テストエンジニアの場合、そのシステムを使うユーザー側のことを理解してユースケースを出すなど、先を見据えたテスト設計ができることも重要です。開発エンジニアも同様で、お客様がユーザーにしてほしいことや、実際に使う人がどういう状況で使うのか、といったところから理解していく必要があります。
テストを甘く見ている人は、設計書に書いていることをテストするだけで満足します。その「当たり前」のテストをどう削減するかや、それ以上の品質をどう作るかに頭を使わなければいけません。一見、設計書が上手く作られているように見えても、実は「上手く書けていないところ」がたくさん隠れていることを、開発にかかわる人には理解してほしいと思っています。
「上手く書けていないところ」というのは、例えば設計書だと入力桁数の上限だったりチェックの仕様だったり、細かい挙動は書かれていることが多いんです。ただ、通常は複数の機能を連続して使うことになるので、その使う流れや組み合わせは無限にあります。すべての組み合わせを確認しているとキリがないので、「普通はこういう使い方をするけど、こういう使い方をした場合はどうなるのか？」という普通の業務フロー上では実施しないような様々なユースケースを考えてテストしてほしいです。逆に開発者はユースケースから考えてユーザーがどんな操作をしても、異常が発生しないようにしたいですね。
ユーザーがどういう時にどんな機能を使うかという、ユーザー側とシステム側の両方を理解しなければなりません。設計書に書いてあることはその中の一部で、システムを使う人がどうすれば役に立つのか、という部分まで考える必要があるのです。この点は、テストエンジニアでも開発者でも、共通で必要となる部分ですね。
「品質にこだわった開発」をしていきたい
――テストと開発の両方を経験して良かったと感じる点は何ですか？
荻野氏：製品やものづくりに関する視野が広がりましたね。テストは開発工程全体で言うところの下流工程で、開発の中の一プロセスです。それ以外の部分を知ることができたのは大きいですね。対応できる幅が広がりましたし、共感できる人達の幅も広がり、コミュニケーションが取りやすくなりました。現在では、テスト側の気持ちもしっかり理解した上で、開発できることが自分の強みになっていると感じます。
――今後の目標について教えてください
荻野氏：やはり「品質にこだわった開発」をしていきたいですね。人によって製品の品質や使いやすさはどうしても変わってしまいます。それを底上げすることについては取り組んでいきたいですね。バルテスが体系立てたテストアプローチ方法の『QUINTEE（クインティ）』を薦めているんですけど、開発は「こういうやり方をしたら品質が高まるだろう」ということを世の中に発信して、標準化できたらいいと考えています。またバルテスも世の中の流行りを取り入れて良いものを押さえていっているので、それを見習いたいです。VMTはテストをアウトソーシング前提でやっているので「テストを依頼した場合のドキュメントの残し方」「連携をどのようにすべきか」など、運用する側のことまで考えてこだわっていきたいですね。
――本日はお時間を頂きありがとうございました。