この数ヶ月で開発体制が大きく変わった話

beta
こんにちは。仕事中にわんこに癒されている beta です。()

Qurage
こんにちはー!髪の毛を切るタイミングを失ってぼさぼさになりがちな Qurage です!

beta
今回は、あしたのチームで実際にプロダクトを開発している現場の雰囲気をご紹介します。この記事を通して、あしたのチームに少しでも興味を持っていただいたりカジュアル面談にお声がけいただくキッカケとなればと思っています。

この数ヶ月で変わってきたことを入社 12 ヶ月目の Qurage の視点で、最近の雰囲気を入社 2 ヶ月目 beta の視点で、それぞれ比較しながら対談形式でお送りします。

​tl;dr;

​ 1. 改善したいことがあればいつでも変えていける柔軟性があります
2. あしたのチームでは一緒に課題をみつけて解決していってくれるエンジニアを募集しています ​

アジェンダ

  • なぜ変化が必要だったのか
  • どう変化を始めたか
  • どう定着させるか
  • どう変化したか
  • どう変化していきたいか
  • 改善を続けていくために

なぜ変化が必要だったのか

Qurage
入った直後の印象として、人数が多いわりに横の共有がうまくいっていない印象を受けていました。例えばフィーチャー単位で開発が分断されていてあとから苦労したり。

このフィーチャーはどこの会社さんが作ったから詳しいことは聞きに行かないとわからないという状況で、これは大変そうだぞと。

ありがちではあるんですが、素早く作り続けるための再設計やリファクタリングなどに必要なコストが膨れ上がっていく一方で、これをどう解消していくかが当面の大きな課題となっていました。

どう変化を始めたか

Qurage
折よくアジャイル開発やスクラムマスターとしての経験が豊富な方たちが続けて数人 join されたんですよね。

それでスクラム導入の流れを強く推し進められるメンバーが揃い、このときプロパーもパートナーも垣根をなくしていくことになりました。「社員と業務委託」ではなく「ひとつのチームとしてプロダクトを改善していきたいよね」という話になって。

明確に決まっていなかった改善サイクルを開発フローとして定めるところからはじめて、複数パートナー企業さんの壁も薄くしていこうということで開発チームも 3 チームに分けて編成しなおし、かなり大きな変化でした。

まずは「改善サイクルの確立とその可視化」を最初の目標に設定して動き始めることにしました。

beta
経験豊富なメンバーが多いですよね。メンバーに惹かれて入社したのでそのあたりは実感が高いです。優秀な方が多くて一緒に成長させていただきたいなと毎日思っています。

スクラム導入の流れで、「アジャイルへの移行をアジャイルの枠組みで」始めた時期も最近数ヶ月間のできごとだったのですね。そうだったのか...。

どう定着させるか

beta
大きな変化があるとすんなりいかない可能性もあったと思うのですが、実際に現場で浸透させていくときの様子はどうでしたか?

変化できる人を求めているようなメッセージからするとハイカロリーだなという印象はありそうですけれども、今はそうなっていないのでどういった経緯があったんだろうと思っています。

Qurage
自分も含め、新しいやり方に慣れるまでの混乱はありましたし、今も手探りでみんなで都度立ち止まって考えながら進んでいるという印象です。

ただこの変化に対してはすごくポジティブな意見が圧倒的に多かったですね。もともとみんなの本音として「どうもうまく噛み合ってないな」という気持ちが長らくあったんだろうという気がします。本当はもっとプロダクトをよくできるはずなのに、うまくいっていなかったというか。

beta
私が入社した時も、ちょうどスプリントの期間を 2 週間から 1 週間に変えているタイミングだったのですが、もっとよくするための方法としてまずは試してみるというのと、スクラムをどうやって活用するかという現実的な考え方でしたね。 もっとよくしていきたいという会話が印象的でした。

「ひとつのチームとしてプロダクトを改善していきたい」というところでパートナーさんとも協力体制を築くためには信頼関係が必要だったと思いますが、そのあたりはどうでしたか?

Qurage
リードしてくれたのはスクラムマスター役の方🙏なんですが、基本的には社内メンバーから「これからはこうしていきたい」という話を伝え、不安や懸念があれば遠慮なく言ってもらい、全て解消していくように動くという、ごく普通の活動を地道に行いました。

Qurage
大きく変えるとなると「ついてこれない者は去れ」というピリピリした雰囲気にもなりかねないんですが、そうならなかったのは良かったなと思います。ついてこられない人が出ないよう慎重にリードするというのは、言ってみれば当たり前の話ではあるものの、ていねいに手を差し伸べあう雰囲気がリード役だけでなくチーム全体にあって良いチームだなと思いました。

どう変化したか

Qurage
僕自身はフロントエンドのメンバーを中心に 1 on 1 をやったんですが、やったあとには会話の量や自然発生的なモブワークが目に見えて増えたのがうれしかったですね。細かいやり方はヒアリングした内容をもとに全てみんながやりやすそうな方向に合わせるようにしました。

beta
私は入社直後から全員と 1 on 1 させていただいています。
一緒に働いていく上でお互いのことを知ることができたり誰が何を知っているのかわかってきて、とても助かっています。
最近では偏愛マップを使った自己紹介でお互いのことを知るキッカケを作るというのもの流行り始めていますね。
これまでの経験からすると技術的なことはテックリードなど技術的腕力の強い人がいればなんとかなる印象が強いので、最近は開発にまつわる組織で文化を形成していく過程に興味があって、人に時間を使っていきたいという思いも個人的にはあったりします。

大きな変化の中で、コミュニケーション面では何か取り組んできたことなどはありますか?

Qurage
別の変化としてフルリモートの制度化も行ったんですが、フルリモートの鍵は雑談なので、積極的に雑談をしやすい雰囲気づくりをこころがけました。といってもやっていることは「なるべくみんなに見える場所でバカそうな雑談をして誘いまくる」とかなんですけどね。

新しいことを始めるときに考え方を共有したり、モブワークでナレッジシェアを進めるにも、お互いの距離感を縮められる場がないとすごく難しいと思います。

どう変化していきたいか

beta
チームごとだけでなくロールごとに横串で情報共有する「場」を設けているのも印象的で、知見や困りごとを相談しやすいしくみになっていると感じることが多いです。

私が入社した時はすでにフルリモートが制度化されていて、入社してから一度もオフィスに行ったことがないです。エンジニアとデザイナーはオフィスには自席がないというのもわかりやすくて好きです。個人的にはフルリモートという働き方があっているので、仕事と生活を両立させやすいなと思っています。

これまでも大きく変わってきたとは思うのですが、それでもまだ課題もあるように感じることがあって、たとえば、個人戦ぽくなってしまってる部分をチーム戦にしていきたいなと感じています。
モブワークが浸透しているのですごくやりやすくて、一方で、モブでないとわからないことも多いという面もありそうですね。

Qurage
一部のわかってる人が個人単位で課題を解決するような流れがまだまだありますね。時間をかけなければ難しい課題だとも思います。

ひとつのプロダクトの開発を情報的に分断された複数チームで進めるやり方が長らく続いていたのが大きな要因だとは思いますが、このナレッジギャップを埋めていく必要性を強く感じています。

すぐに始めやすいことはわりとかたっぱしから手をつけてみてはいます。

  • 社内 LT 会
    • カルチャー醸成と技術向上のため
  • 読書会
    • カルチャー醸成と技術向上のため
  • DocBase
    • コードと強く結びつかないドキュメント置き場として
    • リアルタイム共同編集を利用して議事録を作成して共通認識のブレを減らすため
  • Discord
    • モブワークとフルリモートには必須の雑談を気軽にできるスペースとして
    • 「居酒屋」channel でたまにみんなでゲームやってたり
  • レビュアーアサインルールの明示化とレビュープロセスの再定義
    • レビュアーの偏りを防ぎ、リリース作業の属人性もなくすため
  • 開発フローの再定義と明示化
    • リリース作業の属人性をなくすため
  • デプロイフローの見直しと簡略化
    • デプロイ作業の属人性をなくすため
  • モブレビュー
    • モブプロしなかった Pull Request はレビューだけでもモブワークで
  • Pull Request のテンプレートを変更する
    • diff から読み取れない Why を含む背景を説明してもらいやすいように
  • Times channel
    • Working Out Loud 推奨の一貫として
  • notice-神 channel
    • :kami::tada: リアクションのついた Slack メッセージが自動で集まることで良いアクションがより広く広まるように

みんなの提案から始まったこういう施策はいずれも好評で、今はかなり定着しました。

ただこれらだけでは当然問題の解消まではすぐにはたどり着けないので、今後も思いつくことは端からやりながら時間をかけて付き合っていく課題という印象です。

beta
加えて、たとえば「仕様が不明瞭なのでドキュメントを充実させたい」といった課題もあって、最初に作っていたメンバーがいない、仕様が不明瞭なままという現状にも果敢に立ち向かっていて...これもナレッジギャップに通じる課題ですよね...。

モブワークで解消しようにもそもそもの仕様を探り当てるような考古学が求められる局面が最初にあるというか、触ったことがある機能とそうではない機能との理解度のバラツキも現状あるのかなと。だからこそ、理解度を揃えるためにモブワークが活躍しているという印象です。
入社した時の印象で、仕様に限らず新たにわかったことがあればドキュメントに書き残す、変更があればドキュメントを書き換える文化は特にありがたかったです。そういえば、入社して最初に書いた Pull Request は開発環境に関するドキュメントを更新する内容だったと思います。😇

Qurage
「わかったことは都度その場で書き出すようにするとどうなってもあとあとお得」「とにかく聞いたら書く」という話を布教してはいます、が、最終的には地道に書く時間をつくってみんなでやっていくしかないやつですね...。チーム内で問題認識がある程度一致していて、書く必要性を感じているメンバーが多いのが救いです。

まとめ

Qurage
今回挙げた施策や変化はごく一部ですし、まだまだやりたいことも課題も盛りだくさんなのですが、長くなってしまったので今回のご紹介はここまでとします。今後何回かに分けてまたご紹介できればと思います。

beta
最初の大きな変化から数ヶ月経ってきましたが、最初の変化で止まることなく、どうあればいいのか課題を見つけつつ変化し続けていくメンバーが揃っているように思います。

beta, Qurage
改善活動は点検を含めた継続も重要であり、いつでも見直しをしていく柔軟なチームの土壌ができはじめています。
あしたのチームでは、一緒に課題をみつけて解決していってくれるエンジニアを募集しています!

【リモート手当2万円支給/フルリモート】有給取得率100%・平均残業5-10hの働きやすい環境★人事評価×ビックデータで新しい働き方を創造するプロダクトマネージャー募集 - 株式会社あしたのチーム

【リモート手当2万円支給/フルリモート】全国3000社以上が導入する人事評価クラウドのUIUXをリードするフロントエンドエンジニア・テックリード候補募集 - 株式会社あしたのチーム

【リモート手当2万円支給/フルリモート】人事評価×ビックデータで新しい働き方を創造するRailsテックリード候補募集 - 株式会社あしたのチーム