チームの共通認識を積み上げて、納得感のあるプロダクト開発を | AIRVISAエンジニア座談会
迫地 康大 Kodai Sakochi
大学在学中にエンジニアリングを独学で習得しインターンシップを通じて実務経験を積んだ後、新卒で株式会社アラタナに入社しソフトウェアエンジニアとしてキャリアをスタート。
その後株式会社ゲームエイトに転職し、Ruby on RailsやReactを用いたB2Cの新規事業開発に従事。2022年にAIRVISAに入社後、一人目の正社員エンジニアとしてプロダクト開発をリード。愛称はさこっち
土谷 光 Hikari Tsuchiya
2006年にSIerでエンジニアとしてのキャリアをスタートし、金融や医療等の大規模システム開発に携わる。その後2011年にGMOペパボに転職し、ブクログやminneの開発に従事。2018年に株式会社one visaに入社し、在留資格管理システムの開発に取り組む。新型コロナのパンデミック禍で事業撤退などを経験し、株式会社enechainで電力のマーケットプレイス開発に携わった後、フリーランスとして活動。2023年6月よりAIRVISA参画。フロントエンド開発が得意領域。愛称はつっちー
田中 大揮 Daiki Tanaka
在学中よりITベンチャーでソフトウェアエンジニアとして働き始め、そのまま新卒入社。受託開発を中心に、約7年間Web開発やロボットアプリの開発に従事する。その後宅配クリーニングのリネットを提供する株式会社ホワイトプラスで約3年間エンジニアマネージャーの経験を積み、2024年1月にAIRVISAに入社。愛称はDさん
「緩やかに役割をはみ出しながらその時必要なことをやる」
皆さんはAIRVISAの開発チーム内でどのような役割を担当していますか？
迫地（さこっち）
AIRVISAはB2Bの在留資格管理SaaSをエンタープライズ企業を中心に提供していて、約10社ほど顧客がいます。それに加えて、新規事業としてB2Cサービスの開発を進めているのが今の状況です。
僕はB2Bサービスの保守運用を担当しつつ、新規事業のB2Cプロダクトの方でもインフラからバックエンド開発まで幅広く担当しています。
土谷（つっちー）
僕はB2Cプロダクトのフロントエンド開発を中心に担当しています。B2Cプロダクトの開発はまだ始まったばかりのフェーズなので、これまではデザイナーやプロダクトオーナーとコミュニケーションしながら、要件を固めたりドキュメント作成などを行っていました。
ありがとうございます、つっちーさんはいわゆる「フロントエンドエンジニア」ですが、AIRVISAの開発では、フロントエンドとバックエンドの役割分担はどのようになっていますか。
土谷（つっちー）
正直に言いますと、私はバックエンド側の開発には関わっていません。中間にAPIがあり、その設計は一緒に行いますが、基本的にはフロントエンドを担当しています。
なるほど。逆に、他の方々はフロントエンドもやられるんですか。
田中 （Dさん）
必要に応じて行いますね。得意じゃないけれど、コードは読めるし、書けるかな。
会社によっては、プロジェクトごとにエンジニアをアサインする形もありますし、プロジェクトのフロントエンドとバックエンドでチームを分けて開発する会社もあると思います。AIRVISAではどのように進行していますか？
迫地（さこっち）
今のフェイズでは基本的には全員が1つのことをやる方が好ましいと思っています。明確にぱきっと役割分担をしているというよりは、必要だと思った人が得意領域で動いている感じですね。
土谷（つっちー）
人数が増えてくると役割分担をしてレールを分ける必要も出てくるかもしれませんが、現時点では緩やかに役割をはみ出しながらその時必要なことをやる体制がやりやすいですしね。
チームの成熟度が増して経験主義的なスクラム開発に変化
では、そうした体制の話を踏まえつつ、より具体的な開発プロセスとして、スプリントのサイクルや会議体などのイメージが湧くように教えてください！
田中 （Dさん）
開発はスクラムを採用していて、スプリントサイクルは1週間で進めています。
スクラムは比較的教科書通りに実施していて、スプリントプランニング、デイリースタンドアップ、スプリントレビューやレトロスペクティブも実施しています。
ありがとうございます。スクラムマスターはどなたが担当しているんですか？
田中 （Dさん）
一応私になるのかな。
土谷（つっちー）
うんうん。Dさんじゃないですかね。
今はDさんがスクラムマスターをしているんですね！AIRVISAはDさんの入社前からスクラムを実施していましたが、その頃から変化はありますか？
迫地（さこっち）
以前はスクラムイベントをなぞってはいるものの、スクラムで重視される価値観を大事にしていこう！みたいな感じはあんまりなかったと思います。
それが最近は以前よりもチームが成熟してきている感じがしますし、経験主義っぽい形になってきてるのかなと思います。
土谷（つっちー）
たしかにそうですね、うん。
なるほど、ちなみに以前と比較するとどのあたりに違いがあるのでしょう？
迫地（さこっち）
一つはやはりつっちーさん、Dさんのようなスクラム経験者が導いてくれるのは大きいですね。
あとはメンバー同士の相互理解が進んできて、信頼感が生まれて集合知が醸成される基盤が整ってきた感じがあるというか。
田中 （Dさん）
あ〜それ分かりますね。
迫地（さこっち）
感覚的なんですけど、誰かが言ったことに対してすっと入ってくる感じというか。以前のレーンを分けて開発していた時と比べると、みんなで同じものを見て開発しているというのもありますかね。
つっちーさんやDさんの参画もあって、チームの成熟度が増してきている感じですね。
土谷（つっちー）
スクラムには完成系があるわけではないのですが、 いい感じにチームが育ってきているというか、日々やりやすくなっていってる感じがありますね。
共通認識を積み上げて、納得感をもって開発をする
なるほど。ちなみに開発チームが大事にしている価値観というか、 キーワードみたいなものってありますか？
田中 （Dさん）
一つあるのは納得感ですかね。設計にしろ何にしろ、みんな完全に腹落ちするまで議論してから 進めるようにしています。
土谷（つっちー）
それはあるかも。
AIRVISAの開発って共通認識を積み上げていく感じが結構ありますよね。
割と土台の部分から考えて、その一つ一つの決定を積み重ねていくみたいな意識が結構みんな強くて。その上でドキュメントを読めばちゃんと追跡できるようになっているとか。
田中 （Dさん）
たしかに、認識合わせにはめっちゃ時間使ってるかも。
なんとなくみんな違うと思ってるから、多分すり合わせた方がいいねって誰かが言い出して、完全に認識がすりあった状態で開発に取り掛かるので走り出したらすごく早い。
土谷（つっちー）
そうですね、みんなの認識が揃ってないと、頑張って開発して出来上がったプロダクトがやっぱちょっと違わない？ってなってしまうと思っていて。作り終えたタイミングで、ユーザーも含めてみんなが欲しかったものにちゃんとなってないとダメじゃんっていう気持ちが強いです。
迫地（さこっち）
AIRVISAって革新的な技術を実装して市場に投入するプロダクトというよりは、ちゃんとユーザーが求めているものを作って、UXで勝つみたいなところがあると思うんです。
だから、作っている側の僕らが考える「何を提供すべきか」という考えがブレてたらそもそも勝てないと思っていて、そういう意味でも今のチームのこの考え方はハマっているのかなと思います。
田中 （Dさん）
なるほど。そうですね、確かに。
一度認識が擦り合えば、実装は早い
この納得感を生むためのすり合わせって、認識が揃って進めやすい一方でスピードを落とす可能性もあるなと思うんですけど、実際どうですか？
迫地（さこっち）
すり合わせには時間を使うんですけど、認識が揃ったら3ヶ月ぐらいでバッと頑張って作ろうぜ！みたいな感じで、認識が揃ってる分手戻りが少ないので、実装に入ってからは早いと思っています。
実装に入るまでの期間は比較的長いのかなとは思いますが、それを戦略的に許容しているというか。
土谷（つっちー）
作るものが何でも良くてリリースするのが目的だったら、認識がバラバラでもめちゃくちゃ早く作れるんですけど、ちゃんと価値を届けるプロダクトを作るにはこのやり方の方が結果的に早いんじゃないかなと僕は思いますね。
ペルソナを定義して認識を揃える
ちなみにその最初の納得感を作るために何かフレームワークは使ってますか？インセプションデッキとか。
田中 （Dさん）
インセプションデッキは作りましたが、それ自体はそんなにハマらなかったですね。でもそれが原型になって、我々がものづくりするときのルールを定義した「プロダクト原則」が出来上がったりしました。
迫地（さこっち）
あとは新規プロダクトの性格設定や、ペルソナの定義もしましたよね。
詳しく教えて下さい！
田中 （Dさん）
僕たちが作っているのは外国籍向けの在留資格の申請・管理システムなのですが、例えばどの国の言語に対応すべきか議論してみると、意外とみんなの認識が違ったりしたんです。
土谷（つっちー）
それ以外にも普段から行政書士を利用している申請人をターゲットにするのか、 あるいは自分で入管に行って手続きしている人たちをターゲットにするのか、みたいなところが僕たちの中でふんわりしてたんですよね。
でもそこを決めないと全然作るべきものの優先順位が変わってきたり、チグハグなものができてしまう。
なので、しっかりとターゲットのペルソナを定義して、そのペルソナの課題の真ん中に刺さるようなものを作ろうということですり合わせをしました。
まずこういうニーズを持った人たちがいるよねというパターンをざっと洗い出して、その中から我々にとって明らかにターゲットじゃない人を定義していきます。
これを負のペルソナと呼ぶのですが、例えば設計の議論をしているときに、「それって負のペルソナのニーズを満たしにかかってるよね」みたいなことが判断できれば、やっぱその機能いらないじゃんみたいに決定ができる。
田中 （Dさん）
例えば、犯罪歴がある方は審査の難易度が上がってしまい、アプリに求められる機能も増えてしまいます。そういった方達もターゲットに含めるべきか？という議論でもペルソナが活躍していましたね。最終的には負のペルソナという整理にして、少なくとも初期リリースではカバーしない方針にしました。その分、主要ペルソナにリソースを割けるようになったと思います！
素晴らしい。この進め方はすごくいいですね。
プロダクトの「キャラ設定」を行い、コミュニケーションのテイストを統一する
土谷（つっちー）
あとは、プロダクトUIの中にイラストを入れたりするんですが、実際デザインが上がってくると、なんか人によっては「なんかもっと明るい調子がいいんじゃない」とか「もっと真面目な方がいいでしょ」みたいな意見とかも出てくるようになってきて。
これは多分プロダクトに対してみんなが思い描いてるキャラ設定が定まってなさそうだなと思ったんですよね。
在留資格って国の手続きなので、めちゃくちゃ真面目なテイストを期待してる人もいれば、正式で大変な手続きだからこそ逆にフランクに砕けた感じのコミュニケーションを期待してる人もいたり。
この状態で一貫性無くプロダクトを作っていくと、多重人格みたいに「ここではすごい砕けてるのにこっちではめっちゃ真面目」みたいな感じになってしまうなと危惧しまして。
陽気で天真爛漫なのか、しっかり者で真面目なのかどの辺だろうねみたいなのをそれぞれスライダーを用意して、なぜそう思うのかも一緒に説明したうえですり合わせてみたんです。これはやってよかった。
丁寧に認識をすり合わせるためにはお互いのリスペクトが必須条件
すごく面白いです！ものづくりへのこだわりを感じるなかなかいいカルチャーの開発チームだなと感じたのですが、新しい人を迎え入れるとしたらどんな人と働きたいですか？
迫地（さこっち）
いちばん大事なのは「上機嫌な人」であるということですね。
大事ですよね、上機嫌なこと。
迫地（さこっち）
そうですね。ここまで話してきているとおり、僕たちはかなり丁寧に認識のすりあわせをするチームなんですが、これは前提としてお互いにリスペクトがあって、自分の意見を言っても大丈夫っていう空気感があるからできることだと思っているんです。
不機嫌なコミュニケーションが1つあるだけで崩壊するなと思うので、上機嫌な人と働く、というのは重要なピースな気がしてたりします。
田中 （Dさん）
完全に同意です。おじさんは不機嫌なだけで罪だと思うんですよ。上機嫌でいきましょう。
土谷（つっちー）
おじさん差別じゃないですか、大丈夫ですか（笑）
田中 （Dさん）
いまのは記事にしないでいただいて。。
迫地（さこっち）
いや、名言かもしれません（笑）
これからも上機嫌な人たちで、建設的に認識をすり合わせながら開発をしていけるようなチームであり続けたいですね！
We are hiring!
AIRVISAに少しでも興味をお持ちいただけましたら、お気軽にカジュアル面談にお申し込みください！