「自分で考えて自分の思いが入ったものを作ることは、仕事は大変ですがとても素晴らしいこと」と話すのはVeogle創業メンバーの一人で、現在はプロダクトオーナーを担当する奥村です。

開発エンジニアからQAリーダー、そしてプロダクトオーナーという異色のキャリアを持つ奥村にVeogleの開発のプロセスと品質について詳しく伺いました。

「お客様のために何ができるか」を最優先する考え方に賛同し、Veogleへ入社　

ーまずはこれまでのご経歴を簡単に教えてください。

Veogleは3社目になります。1社目では、金融関連の大規模プロジェクトに携わり、エンジニアとして勤務していました。キャリアのスタートは開発者としてプログラミングを行い、主にソフトウェア開発に注力していました。その後、QAを任され、10人から20人規模のQAチームをリードするリーダーをしていました。

プロジェクトでは、お客様と会話をするチーム、開発をするチーム、テストをするチームと、業務が完全に縦割りになっていました。

縦割りのチームだと自分たちのことだけ考えればいいので、ある意味楽ではあるんです。ただ、お客様の事情や開発の詳細などがわからないなど、できない仕事も多く、限界を感じることもありました。

代表の小松とは同じ会社ではありませんが、その当時から一緒に仕事をしていました。

その後、小松と共にIoT分野のベンチャー企業に参加し、顧客対応、開発、テストなどあらゆる業務を任され、結果としてプロダクトオーナーという肩書きになりました。

その後、創業メンバーとしてVeogleに参画しています。

ーVeogleの創業メンバーということですが、参画の決め手を教えてください。

意思決定の決め手は代表である小松の人柄や考え方です。

お客様のために何ができるかを最優先に考え、当たり前の仕事を徹底的にやるという小松の考えに賛同したことがきっかけですね。

小松の会社であれば、お客様のためにサービスを作る仕事を優先できると感じ入社に至りました。

ー現在の役割や担当している業務を教えてください。

Veogleは受託開発でありながら、社内でプロダクトオーナーを立てる体制にしており、お客様とVeogle1名ずつ、プロダクトオーナー2名体制で開発を進めるという独特のサービス体系を持っています。私はそのプロダクトオーナーとして、お客様とともに開発するプロダクトの方向性を決めています。

お客様の叶えたい要望を整理したり、業務の優先順位をつけたりするユーザーストーリーを作成し、お客様と共にプロダクトの方向性を決めています。

何を作ればいいのか決まっていない段階から、お客様が実現したいことを聞かせてもらい、イメージを擦り合わせながら開発可能な状態まで持っていくんですよね。

情報を開発者に渡す時にも、設計書を渡すだけでなく、相手に合わせた対話でのコミュニケーションをとりながら情報伝達を心がけています。

[参考記事]
なぜ受託開発をするVeogleにプロダクトオーナーがいるのかがわかる記事
▼Veogleが提唱する「受託アジャイル開発」とは？真のフルスタックエンジニアになれる開発環境とエンジニア育成への想い
https://www.wantedly.com/companies/veogle/post_articles/886176

エンジニア自らが顧客と直接対話し、自らプロダクトの価値を考え、思いが入ったものづくりを行う

ーVeogleではどのようなプロセスで開発をしているのか、一連の流れを教えてください。

まずはお客様へのヒアリングをします。まだ何を作るべきか定まってない状態なので、ざっくばらんに実現したいことを聞いていきます。その後に誰が、何のために、何ができるというユーザーストーリーをまとめ、紙芝居のような画面のモックアップを準備しますね。

お客様と一緒にモックアップを見ながらイメージを膨らませ、お客様の感想を聞きながら作るものを決定していきます。

そこで決めた要件をエンジニアに伝え、基本設計を作る時には口頭でも伝えますし、場合によってはお客様とのミーティングにエンジニアが参加することもあります。お客様と直接話す機会が多いので、エンジニア自身にも高いコミュニケーション能力が要求されますね。

エンジニアもお客様が必要とするサービスを理解できるので、「自分が作る機能は、誰のために・何のために作るのか」を考えながら開発を進められます。

とはいえ、すべての仕事をエンジニアに丸投げする訳ではなく、私とコミュニケーションを取りながら開発を進めていく感じですね。開発者に裁量のある状態で開発を進め、レビューしながらより良いものにしていくイメージです。

また、Veogleではテスト担当者がいないので、開発担当者がある程度のところまでテスト業務も行います。

昔からのやり方でありがちな、作るだけ作って、一番最後にまとめてテストする形ではなく、出たバグは随時発見できるようにしています。

お客様へサービスを納品する前の最終テスト段階では、そこまで大きなバグは出てこないですね。

ーエンジニアもお客様のミーティングに参加するなど守備範囲が広いと思いますが、このようなプロセスにしている背景や狙いを教えてください。

1社目の会社でテストチームのリーダーをしていた時、設計書通りのテストしかできなかった経験があります。しかし実際にテストをする人は色んな改善案やアイディアを持っていたんです。他の人が最初に決めたゴールを確実に守るよりも、自分の頭で考えた上で開発した方がいいものが作れると考え、現在のプロセスにしています。

新しく参加していただくエンジニアにも、開発に幅広く携わって欲しいですね。

自分で考えて自分の思いが入ったものを作ることは、仕事は大変ですがとても素晴らしいことなので、最初は難しくても一緒にやっていきたいです。

ー開発プロセスについて今後想定される課題はありますか？課題に対する対策も含めて教えてください。

現在のプロセスで仕事が進められているのは、少ない人数と能力の高いエンジニアが揃っている恵まれた環境だからです。

規模が大きくなっても、クリエイティブなエンジニアをやれるという証明ができたら嬉しいなと思うので、この文化をちゃんと守りたいです。

人数が増えると、コミュニケーションのロスは今よりも増えてきます。

新しくVeogleに参加したエンジニアともコミュニケーションをとり、お互いに会話がしやすいよう意識したいですね。

プロダクトオーナーと新入社員という関係ではなく、対等な立場を心がけて会話をしたいです。

「過剰品質と適正品質の差を理解することが大切」強い信頼関係の元、ユーザーストーリーを実現できる製品を作る

ー続いて品質に関する質問です。高い品質を保つために心がけていることは何かありますか？

開発者もテストに携わり、確認できることは早めにし、バグを随時修正するようにしています。チーム全体でのアプローチとして高い品質を保てるようにしていますね。

また、あまり経験がないエンジニアには、わからないところは聞いてほしいということをしっかりと伝えています。「何でも聞いていいよ」という感じで質問しやすい空気感を常に意識し、できるだけコミュニケーションしやすいようにはしています。

私には同じ質問を何度してもいいので、疑問点があれば気軽に相談して欲しいです。

ー奥村さんは過去にQAリーダーをされるなど、品質に精通されていますが、品質に対してどのような価値観や考えを持っていますか？

品質の良し悪しは、使う人やプロジェクトなど様々な要因を考慮して変わってくるものです。つまり、プロダクトを使った人が目的を果たせるか、どういう果たし方ができるかという観点ですね。

必要以上に品質を磨きすぎて工数が増えたり、逆に時間に追われて品質を蔑ろにはしたくありません。

いつも同じ品質の守り方をする訳ではなく、どのようなやり方がベストなのか、どこまで磨くことがベストなのかを見極めることが大切です。

私はこれまで、過剰品質に陥った人や納期に追われて品質を蔑ろにした人、双方を見てきました。

特に日本人は真面目なので、過剰品質になりがちです。新人のころ、何度もテストを行なっている先輩に思わず過剰なテストを指摘したところ、先輩自身も返す言葉を持っていなかったという経験がありました。そこで過剰品質の効率の悪さに気づき、経験を積む中でより確信をしました。

お客様のニーズを満たすことが最優先なので、細かすぎる品質の担保よりも、強い信頼関係の元でお客様の描くユーザーストーリーを実現できる製品を作ることに重点をおいています。

ー現在の品質に関する課題が何かあれば教えて教えてください。

現在大きな課題はありませんが、強いていえば、経験が少ないエンジニアの方に、過剰品質と適正品質の差を理解していただくための教育が必要ですね。

自分自身で多くの仕事を経験し、適切な品質とは何かに気づいて欲しいと思います。

ただ、様々な経験をすぐに積むことはかなり難しいと感じますね。

今後、人数が増えて新しい方も増えた時に、しっかり対応する必要があると思っています。

ーどういった価値観を持つ人がVeogleにマッチしそうか、奥村さんご自身どういった人と働きたいか教えてください。

素直で自分のことを大事にできる人がVeogleにマッチすると思います。能力の高さよりも、人間的な柔らかさのある人です。

お客様のために仕事をする前提はありつつ、仕事で落ち込むことがあっても、最終的には自分を責めすぎず早く立ち直れる人がいいですね。

個人的には、嘘をつかない人と働きたいです。

しっかりと話ができ、コミュニケーションが取れる人が理想的ですね。