優秀なエンジニアの方にジョインいただき、少しずつ体制が整いつつあるストラーツ。数ヶ月前まで5人だった開発チームも、現在14人まで拡大し、サービス拡充に向けてチーム一丸となって開発を進めています。しかし、それでもまだエンジニアは不足しているのが現状です。そこで第6回目の本記事では、なぜエンジニアがそれだけ必要なのか、開発チームが今抱えている課題についてリードエンジニアの木村さんに話を伺いました。

■多角的な視点でベストな機能をつくる

（鎌上）今回は、チームリーダーでもあるリードエンジニアの木村さんから見た開発の課題について聞かせて下さい。


（木村さん）まずサービスの最も大きな課題は、カバレッジを上げることです。顧客ニーズが先行したので新規開発を優先した結果、テストコードを書く時間がなかった。それが原因で、もし不具合が起きても感知しづらい。今は解決に向けて、テストを書くだけでなくe2eテスト/CIを入れて自動に回すような仕組み作りに取り組んでいます。まだ走り出しなので解決には至っていませんが、サービスのカバレッジを上げるために日々動いています。

また、より良いサービスにするためにはどんどん新機能も追加したいのですが……スケジュール通りに進んでいないのが現状です。リリースしたい新機能のロードマップはあるものの、優先すべき施策が多く、手が回っていません。この課題を解決するには、やはり人手を増やしていくしかないんですよね。特に、今はフロントエンドに特化しているエンジニアがいなくて。最低でも、フロントエンド、バックエンドそれぞれでもう1名ずつはジョインしていただきたいなと思っています。


（鎌上）新しくジョインされるエンジニアの方には、こんな役割をお願いしたいなど、具体的に考えていることはありますか？


（木村さん）まずは、新機能開発をお願いしたいですね。また、カバレッジを高める点は現在進行中なので、それよりもコードをキレイに書いてもらったり、負債になりにくいような書き方をお願いしたいです。現在ストラーツでは「DDD」という開発手法を取り入れている最中なので、DDDの経験がある方や得意な方は大歓迎ですよ！

ストラーツが今成し遂げようとしているのは、これまでにない全く新しいオンラインイベントのサービスです。だから、正解か不正解かやってみないとわからない道を我々は進んで行かなければいけない。

例えば一つの機能をとっても、ある人の視点から見るとこの機能のほうがいいけど、別の視点だとそうじゃない場合もあります。複数の視点をそれぞれで見ると実にいろんな機能が必要になってしまいますが、もちろん全部解決はできないので取捨選択が必要です。そのために、開発チームと代表率いるPMセクションが積極的にやりとりをして、より良いサービスの形を模索しています。

ただ、PMセクションから上がってきたものが必ずしも正しいとは限らないので、仕様の見直しもその都度必要なんですよね。そういう点でも、言われたことをただ淡々とこなすのではなく、チーム内外としっかりコミュニケーションをとって議論ができる人に来てもらいたいですね。

新機能開発についても同様で、やっぱり正解がない……というか、誰も正解を知らないという表現が正しいかもしれません。

そういった意味でPMセクションから上がってきた案が必ずしも正しいとは限らないし、既存の機能も本当にベストなものなのか常に仕様の見直しも必要です。そのため、エンジニアも積極的に意見を出したり、考えてやってくれる人だと嬉しいですね。

どのメンバーもより良いサービスをリリースしたいと思っているので、経験や年数、部署やポジションに関係なく、ちゃんと意見を聞いて議論できる環境なのはストラーツの強みだと思います。


（鎌上）そうですね！課題はありつつも、メンバー全員が同じ方向を向いて議論ができるのはストラーツの良いところでもありますし、意見を遠慮なく言い合える場はやりがいにも繋がりますよね。ほかにも課題はありますか？


（木村さん）初期に突っ走って作ったβ版の名残がまだあるので、その作りから脱却したいです（笑）。新機能開発と同時並行でやらなきゃいけないんですけど、読み解くのが難しくて。あと、サービス全体のブラッシュアップも必要ですね。

最近インフラを刷新して、ECSとFargateを使った構成に変わりました。Docker（コンテナ）を使った開発環境になったおかげで開発が楽になり、本番との差異もかなり減りましたね。本番への反映も自動化できるようになるなど、インフラ周りの自動化は粛々と進んでいます。エンジニアにとっては働きやすい環境になったと思いますよ。

ただ、開発のタスクや回し方はかっちり決まってる訳ではないですし、よりやりやすい方法や環境はまだまだあると思っています。なので、そのあたりも積極的に意見を出してくれる方だとやりやすいですね。

■柔軟性のある組織――各チームの意見を取り入れて新しくできる機能も

（鎌上）サービスの課題についてお伺いしましたが、チーム間の課題や会社としての課題など、組織の課題について木村さんはどのように感じていますか？


（木村さん）エンジニアはチーム間で顔を突き合わせてコミュニケーションを取ることがそこまでないので、チームの課題は特に思いつかないかなぁ（笑）。基本的には僕がタスクを割り振って、みなさん割り振られたタスクをこなしていくという感じです。

チーム内で顔を合わせるのは、全員が集まる週1回の開発会議と、正社員が集まる見積会議（新機能構築にどのくらい時間を要するか業務の見積もりをする）くらいですかね。

メンバーは、稼働中はバーチャルオフィスに必ずインしているので何かあれば音声コミュニケーションはいつでも取れますし、特にエンジニアはSlackでテキストでコミュニケーション取ることが多いですね。

会社全体の課題としては、やることづくしで全員多忙極まりないことですかね。個人的には、仕事がいっぱいあるのは良いことですし、嬉しいことだと思っています。


（鎌上）はい、ないよりはいいですよね（笑）。他にも課題に感じる部分はありますか？


（木村さん）先述のとおり誰も正解を知らない状態なので、開発チームがその時は必要だと思って作った機能でも、あとからCSが見て「何でこんな機能があるんだ？もっとこっちの方がいいのでは？」となることももちろんあります。

でも一度決まったものは絶対に変更しないということはなくて、その時必要なものをその時々で見極めていく柔軟性が大切です。柔軟性という部分では弊社は長けていると思うんですが、過去の記録がドキュメント化されていないこともあるのでその辺りも課題ですね。

また、目下取組中なのは就業規則などのルール作りです。現在PMセクションが中心となって、就業規則や福利厚生などを整備しています。

あと、最近は少しづつメンバーも増えてきて、メンバーと代表の距離感が以前と異なってきているのが気になりますかね。これはフルリモートならではだとも思いますが、実際にオフィスで代表とみんなが話している場面を見ることができないので、入ったばかりの人は特に距離を感じてしまうかもしれません。でも実際は、代表とは本当にフランクにコミュニケーションが取れるし、むしろみんなには積極的にコミュニケーションを取ってもらいたいんですよ。時間を合わせてバーチャルオフィス上で一緒にお昼を食べながら雑談するような企画があると、実際の雰囲気がより伝わるんじゃないかなぁ……不定期でもやってみたらよさそうだな。


（鎌上）確かにオンラインだと、どうコミュニケーションを取っていいか伝わりにくいですよね。最後に、木村さんの個人的な課題って何かありますか？


（木村さん）マネジメントやディレクションに時間を取られて、コードをなかなか書けていないことですかね。もう1人マネージャー的ポジションで入ってくれると非常に助かるので、マネージャー候補やチームリーダーの経験がある人が来てくれるといいですね。


（鎌上）木村さん、お忙しいところありがとうございました！