こんにちは、 BOXIL の開発をしている徳田(@haze_it_ac）です。
今日はBOXILの開発チーム、特にエンジニアが今どういうことを考えてどんな開発をしているのか、そしてこれからどうなっていこうとしているか をご紹介します。
スマートキャンプという名前を聞いたことがある人、興味がある人に読んでもらえると嬉しいです。
合わせて読みたい
昨年末までの「BOXIL開発チームのこれまで」を、現Product Managerの笹原が書いているので一緒に読んでもらえると嬉しいです🙏
BOXIL開発チームの今
今の開発チームを、徳田の目線で振り返ってみます。
開発体制
現在、「BOXIL開発チーム」は3つの役割を持つチームが定義されています。（兼務もいます）
1. Product Manager
スクラムにおけるPOの役割です。
CS, Sales等とのコミュニケーションや仕様(=Product Backlog)に関する責任を持ちます。
現在、Product Managerとして一名が担っています。
2. Designer Team
https://boxil.jp , https://boxil.jp/mag のUIや、BOXILにかかわるLPやイベントで使用するチラシ等のデザインを行うチームです。
デザイン、見た目の責任を持ちます。
現在、一名＋業務委託メンバが担っています。
3. Developer Team
デベロッパーの集まり、所謂エンジニアです。
Product Manager、Designerが作った仕様・デザインを実装する責任を持ちます。スクラムで言うところのPBLの消化です。
現在、正社員二名と業務委託メンバに加えてProduct Managerが兼任で担っています。
補足: 現時点ではスクラムマスターの役割を持っているメンバはいません。
昨年からお手伝いいただいているアジャイルコーチには、今は主にPO側の改善活動に注力してもらっています。
（スクラムマスターは任命するものではなく自然発生的に生えてくるもので、生えていないうちはチーム全体で補うため大丈夫、という認識です。）
開発プロセス・スタイル
スクラム
開発プロセスのベースはスクラムです。
毎週金曜日に Sprint Review, 振り返り, Planning を実施。それ以外の月〜木に作業を行っています。
モブプロ・ペアプロ・個人作業
3~4ヶ月ほどモブプロを積極的に取り入れていましたが、少しずつモブでやること・やらないほうが早くできることの認識がメンバ間で合ってきたこともあり、最近は少しずつ個人やペアでの開発が多くなっています。
今はDeveloper Teamの中で、正社員二名チーム・Product Manager＋業務委託メンバチーム の2つに分かれて、担当する開発範囲を分けて開発しています。
ペアでやるか、個人作業＋レビューでやるかも、そのチーム間で好きに決めてやっています。
チーム間の連携は随時必要に応じてドキュメントを書いて共有しています。今週からは金曜日に時間を取ってやるようになりました。
参考: 実践して分かったモブプログラミングのメリット・デメリット - SMARTCAMP Engineer Blog
振り返り
めちゃくちゃ振り返っています。
朝会（Daily Scrum）、毎週の振り返り、KPT等は安定してずっと出続けており、一ヶ月も経つとチームの形やプロセスがかなり変わっています。
今の課題
やりたいことに対してのリソース不足
昨年末にプロダクトマネージャが爆誕し、アジャイルコーチ・デザイナと共にPOのサイクルが回ってきたことで、開発チーム全体のボトルネックがDeveloper Teamに寄ってきました。
（最近は PdM, Designer, コーチでOpportunity CanvasやLean Canvasを作成していて、Backlogの質もどんどん上がってきています👏）
開発速度を上げていくための施策はいくつか走っていますが、やりたいと思っていることの全てをDeveloper Teamだけでこなすことはできておらず、（元）開発リーダでもあるProduct Managerに一部機能開発を手伝ってもらっている状況です。
技術負債
複数サービスが密結合していることや、Viewにかなりのロジックが残っていることから、開発やテストに大きな影響が出ています。
課題となる箇所にかかわる機能改修を行う際はリファクタリングや不要なコードの削除をしており、少しずつ改善はされていますが、まだまだやれることは多いです。
BOXIL開発チームのこれから
採用
まずは、Product Managerが開発にも入っている状態を脱するのがDeveloper Teamとしての第一の目標。
そのために、今のメンバで開発をすすめるためにできることはやると同時に、採用もやっていくことになります。
現時点でメンバも全員採用の面接に入ったり話をしたりしていますが、会社そのものを知ってもらったり、興味を持ってもらうための活動を開発とは別軸でやっていく必要があります。
（具体的には このエンジニアブログもそうですし、カンファレンスへのスポンサー、自社開催のエンジニアイベント等。やれることはやっていますが、今後も継続してやっていくぞ！という意味です）
改善活動: 技術
今でも開発の合間のリファクタリングは積極的に実施していますが、もっと直せる部分は多くあります。
ある程度モノリスでの改善ができたら、システム・組織の分割を行い、人が増え、チームが大きくなっても開発を早く進められるような形にアプリケーションも変えていく必要があります。
Ruby on Railsのレイヤ以外でも、クリティカルなインフラ周りの改善などももっとやっていきたい...と思っています。
改善活動（プロセス
リファクタリングの障壁の一つに、複雑な割に仕様がソースコードに以外にないことがあげられます。
そのためオンボーディングプロセスにおいて、現状の仕様を共有していく手段がモブプロ・ペアプロで直接伝えるぐらいしか今は無く、（最終的にはどうであれそうなるのですが）関連する機能のソースコードを全部読まないと先に進めない状況になっています。
また、人によって仕様の理解度に差があり、考慮漏れが発生したりすることもあります。
それらを解決するため、構造化されたテストや、重要な仕様のドキュメントを整備していこうとしています。
おわりに: 宣伝
BOXIL開発チーム、特にDeveloper Team目線からのお話を割と長々と書かせていただきました。イメージは湧きましたか？
残りは宣伝です。が、ここでブラウザバックせずに、読んでくれると嬉しいです😌
BOXIL開発チームでお待ちしています
解決しないといけない課題はある程度見えていますが、とりあえず人が足りないこともあってやれる範囲はめちゃくちゃ広いチームです。
また課題に対していくつか書かれている解決策は、今の状態で最善だと思うやり方です。
「もっとこうしたほうが良い」とか、「ここは得意だからやらせろ」とかは喜んで聞き、適切であれば即座に実行したり、だめそうなら一緒に考えていける組織です。
興味を持った、少し話を聞いてみたいと思った方はぜひ気軽にお話しましょう！！！！！
エンジニアイベントやっています
2/21に、スマートキャンプで開催するエンジニア向けのイベントを行います。
採用文脈でイベントのこと書いちゃったけど 管理画面とか、フォームとかを仕事でこねこねしている人はぜひ気軽に来てください🙏🙏🙏🙏🙏🙏🙏🙏
