The BEENOS

今回はBEENOSの主要プロダクト「Buyee」で倉庫周りの開発を支える田保さんにインタビューさせていただきました。倉庫チームのリーダーとして、また、開発組織のサブマネージャーとして、大きな開発組織でのスピード感を持った開発を実現しています。社内でも評価され、昨年の社員表彰優秀賞にもノミネートされたスピード感とコミュニケーションの秘密に迫りました。


ー まずはBEENOSグループに入社してからの経歴を教えてください

初めはスタッフとして転送コム事業に関わっていて、担当していた仕事を終えた後Buyeeに異動しました。Buyeeへ異動してからは転送コムでの経験を活かして倉庫関連の業務に取り組んでいて、ユニットのリーダー、そして倉庫チームのリーダーを任せてもらっていました。 
現在は開発グループのサブマネージャーをしつつ、倉庫チームのリーダーも兼務しています。 
サブマネージャーとしてBuyeeチーム全体や開発グループとしてどうしていくのかなどを考えながら、Buyee、転送コムの倉庫の開発も行っています。


ー 倉庫周りの開発を担当するようになった経緯はどういったものでしたか？

元々スタッフ時代に関わっていた転送コム事業が倉庫をメインとしたサービスだったので、当時の社員の中では一番倉庫周りに詳しかったというのが大きいと思います。
そのため、自然とビジネス側からも倉庫関連の問い合わせや改善要望が集まってきていました。
以前から倉庫のビジネス側を担当している方たちと多くコミュニケーションを取っていたこともあって、個人メンションで要望や課題がくることもしばしばでした。


ー その時期はどのようにお仕事を進めていたのでしょうか。

スタッフの方やビジネス側は人がいたのですが、開発側の社員は3人しかいない時期がありました。そのため、自然とマネージャー1人に問い合わせや案件が集中してしまっていたので、メンバーとしてそれをどれだけ奪って減らせるかを意識していました。
この時期はとにかくなんでも自分たちでやるしかなくて案件を捌くのに必死でしたが、それだけたくさん課題解決できたということでもあるので、それはそれで個人的には楽しかったです。
それからマネージャー陣が人員の補充やチーム編成に動いてくれたことで、今はそういった忙しさもなくなり、案件の中で他部署に対する知見を深める余裕が生まれたのはとても良いことだと思っています。


ー 働く上でのポリシーや、大事にしていることなどはありますか？

自分のベースとしては「人の役に立ちたい」とか、「困っている人を助けたい」というのがあります。
何か問い合わせがあれば、それを解決するために動くというのが基本です。
今考えると、当時困っていることが多かったのが倉庫周りなのかな、とも思いますね。
自分が社員になった当時は、Buyeeの流通総額を伸ばそうというミッションが大きく掲げられていて、開発のリソースもユーザーの購入を増やす部分に集中していました。そのため、流通総額は伸びて荷物はたくさん届くけど、それを受け止める倉庫の開発が追いついていないため課題も多くて。倉庫のビジネス側とも距離が近かったこともあり要望を聞いている中で、「これを助けよう」と思ったのが自分のベースの部分かつ倉庫周りをメインに担当するようになった理由でもあるかなと思います。


ー 「困っている人を助ける」という面で、具体的に意識していることや得意なことはありますか？

わりと異変には気づきやすいのかなと思います。Slackを結構よく見ていて、別チームから上がってくる問い合わせも含めて、今どのような課題があるのかはそこでキャッチアップしています。また、全部を対応できているわけではないですが、宛先不明の問い合わせについては、適宜担当チームへ繋ぐようにしていたりもします。アラートチャンネルに通知があったら都度見る癖はついているのかもしれないです。

ただ、最近は開発グループの中でもチーム化とか各々の担当領域が明確になってきていて、自然とその問い合わせの担当の人が拾えるようになっているので、自分が間に入ることはほとんどなくなってきましたね。


ー 関係のないアラートも全部見る意識はいつから持っていますか？

社員が3人しかいなかった時期にだいぶ染み付いたのかもしれないです。その時期は倉庫関連の業務を担当しながらユーザーに表示するキャンペーンバナー周りの改修もしたりと、なんでも自分たちでやるしかなくて。その時にBuyeeの色々な点を知れたことで、ちょっと分からないから放置しておこう、ということがなく、Buyee全体の異変に敏感に反応できるのかなと思います。


ー 社員表彰にノミネートされた際には「課題解決におけるスピード感」も大きく評価されていましたよね

ノミネートされた案件はBuyeeにとっても会社にとっても重要なプロジェクトで、開発も工数がかかるものだったので、私は意図的に開発にはあまり関わらずマネジメントに注力するようにしていました。開発者が開発スピードを高められる環境を一番に考えて動いていましたね。
開発側から疑問が出たら、開発側には別の作業をお願いしつつ他部署とコミュニケーションを取って情報を補って、開発側の手が空いたらすぐに作業をお願いして、みたいな感じです。
他部署とのコミュニケーションを自分が担って情報の橋渡しをスムーズにすることで、開発側が常に開発し続けられる環境を維持することを意識していました。


ー 情報共有で意識していることや難しかったことはありますか？

今も継続して向き合っている課題の一つに、インフラチームとの連携があります。
プロジェクトに必要な環境をインフラチームに用意してもらう際に条件や権限等の要望を伝える必要があるのですが、それは精度を向上する余地があると感じています。
プロジェクト開始の段階で開発側の要件が揃っていればよいのですが、後に追加の要件が出てきて変更をお願いすることになってしまうこともあります。
インフラ側の作業に必要な情報を把握しきれていなかったので、分からない部分はとにかく聞くようにしていました。
最近では事前に必要な情報が少しずつ予測できるようになってきましたが、よりスムーズな連携に向けて今も試行錯誤を続けています。


ー マネジメントで意識していることはありますか？

成果物の品質を大事にしているのは大前提の元、スピード感を意識しています。
Buyeeとして、事業会社として、競合もいる中でいち早くBuyeeに変化を与えるためにやっぱりスピード感は大事かなと思います。ビジネス側と開発者の橋渡し的な役割なので、そこの情報の受け渡しをスムーズにするようにしていて、例えばSlackの反応を早くするとかは日常的に意識しています。
あとは、自分としても課題な部分ではあるんですけど、困っていることって基本的に現在のことが多いのでマネジメントもそっちに寄ってしまうことが多くて。
でも、未来のことも、現時点では困っている度合いは低いけどBuyeeのためには必要なことなので、マネジメントとしては現在と未来の両方の課題解決を考えていけるようにしたいです。


ー 現在はご自身で手を動かすことも多い印象ですが、今後もマネジメントもしつつ自分でコードを書く等、プレイヤーとしても活躍していきたいですか？

自分が手を動かさなくても良いとは思っています。ただ、チームの状況を見て他の人にお任せしづらい状況であれば、ちょっと急ぎの案件来てるから自分の手の空いている時間にやっちゃおう、とかで動いたりはしていますね。
「品質の高い成果物をいち早くリリースする」という目的がブレないことが大事だと思っています。
マネジメントとしてはチームメンバーに手を動かしてもらうことが正解かもしれないですが、自分が手を動かすことが最良と判断したらその行動を取ると思います。


ー 今後のキャリアビジョンを教えてください

今後もマネジメントの方向で成長していきたいと考えています。「自分で手を動かしたい」というこだわりはあまりありません。私が1日8時間作業するよりも、5人をうまくマネジメントして組織として40時間分の成果を出すほうが、Buyeeの成長に大きく貢献できるからです。
現在のことと、未来のこと、この両方のバランスを取りながら、組織をより良い方向へ導いていきたいですね。