こんにちは。バックエンドエンジニアの髙嶋です。
今回は、私が BASE に転職するに至った動機の一つでもある「開発力をあげたい」ということについて、実際入社してどうだったかを半年が経過した今、あくまでも私個人の経験としてお話しさせていただこうと思います。
結論から言うと「開発力」が向上した実感は確かにあり、
- DDD や TDD、あるいはスクラムといったものを使っていこうという機運が開発組織的にもあった
- ただしやり方がガチガチに決まっているということはなく、チームごとに合った方法を考えていく余白が十分にあった
- それをするための Be Hopeful(楽観的)で Move Fast(速く動く)かつ Speak Openly(率直)であるという、会社としての風土が自分に合っていた
といったことが振り返ってみると挙げられると思っています。
先に結論を言ってしまったので、ここからは少し時間を巻き戻しながら順にお話ししていこうと思います。
なかなか一般化できるような内容ではありませんが、一つの参考として読んでいただけると幸いです。
そもそも開発力とは
「開発力」のまま話を進めるとスコープが広すぎるので、今回の話における定義を決めておこうと思います。
一言でいうと、「設計力」となります。
そして「設計」という言葉自体も非常に様々な捉えられ方をする、広い意味を持つ単語です。
そのためここでは
- 企画担当から提示されたやりたいこと(要件)の解像度を高め
- どう既存プロダクトの中に落とし込むかあらゆる選択肢を洗い出し
- その中から様々な要素を加味して現状における最適解と思われるものを一つ選び
- それをどのようにユーザーに見える形で実現するかを考え、実行する力
と表現しておきます。
なぜ開発力もとい設計力をあげたいと思ったか
前提として、私の転職理由をお話ししておかなければなりません。
前職では Web アプリケーションを開発するチームのグループマネージャーを任せていただいており、それ自体は非常によい経験ではありました。
一方で、エンジニアとして自信を持てるほどの知識や経験がないまま、その時の状況もあって役職に就かせていただいたという背景がありました。
その結果、いわゆるマネジメント業務に割く時間が多くなっていく中で、チームメンバーから技術的なアドバイスを求められても、引き出しが少ないがために確固たる根拠を持って助言できない自分に対してもどかしさを感じていました。
そういった背景もあり、一度環境を変えて技術的な幅を広げる経験を積みたいと思った際に、ご縁があって BASE に入社させていただく運びとなりました。
入社して何をやっているか
ネットショップ作成サービス BASE の、ショップオーナー様向けの機能開発に主に取り組んでいます。
特にショップ開設直後、スムーズにショップ公開まで行うことができるよう、そのオンボーディングを手助けする領域を担当させていただくこととなりましたが
- これまで会社としても抜本的な施策をそれほど多くうってこなかったドメインである
- 歴史があり、技術的負債も少なくない
- 多くの機能に影響しうるため、開発上の影響範囲が広いというだけではなく関係各所との連携も必要になる
という背景もあり、自分にとってもチャレンジングで面白みの感じられる業務と思っています。
加えてプロジェクトチーム自体も新たに発足したこともあって、そういった意味でも一から作り上げていくようなわくわく感がありました。
一方で開発の進め方にフォーカスすると、
- プロダクト開発に取り組む、プロジェクトチームとしてのフレームワークとしては「スクラム」
- いわゆるソフトウェア設計手法としては「DDD(ドメイン駆動設計)」
を採用しました。
これは既に社内でも活用事例があり、参考にしやすかったことが前提としてはあります。
そして自身としても今までやってみたいとは思いつつも、業務の中でしっかりと取り組んだ経験がなかったものなので非常に前のめりではありました。
冒頭でも触れましたが特に新参者の自分にとっては、オープンにコミュニケーションをとり、前向きにどんどん試していこうという雰囲気がベースにあったことは大きかったと思います。
新しいチームで新しいことに取り組むことのハードルがぐっと下がり、その結果様々な知識を吸収し、価値のある経験を多く積むことができていると感じています。
どんな成長があったか
しかしながら、もちろん全てが最初から順調に進んだわけではありません。
特に印象的だったことがこの2つです。
- 抜本的に画面構成やユーザー導線を見直すような施策を打とうとしたが、レガシーなアプリケーションの作りが制約となり、リファクタリングから始めざるをえなかった
- スクラムで開発に取り組もうとしたものの、チームメンバー内の認識がバラバラで円滑に進まなかった
以下、それぞれについて簡単にその経緯を説明します。
まず1つ目のリファクタリング対応が必要になったことについて。
これは本当に想定外で、蓋を開けてみたら判明したことではありました。
プロダクトオーナーから「こんなことがやりたい」という企画があがってきて、最初のうちは開発チームとしても「多少大変だろうがまあできるだろう」という感覚ではありました。
ただ実際にソースコードを見てみると、現状の構成のままでは実現自体が難しい、あるいは実現できたとしても相当な工数がかかり複雑な対応になってしまう、ゆえに不具合につながる可能性も高まるといったところです。
そのためリファクタリングすることに関しての合意形成はそこまで難しくありませんでしたが、当然ながら無尽蔵にコストや期間をかけられるわけではありません。
どこまでやるかのスコープを明確にし、そのうえでボトルネックとなっている問題を解決できる設計方針を練ることには非常に頭を悩ませました。
やったことの全てを挙げるのは難しいですが、
- Web API の構成見直し(OpenAPI を利用しており、その開発体験については こちらの記事 も参照ください)
- それに伴い、MVC 構成でバックエンド側に偏っていた処理の一部をフロントエンド側に委譲
- ユニットテストが十分になかったこともあり、責務を適切に分解してテスタブルなコードに修正
といったことに取り組み、そのリリースを経て施策が打ちやすい状態にすることができました。
リファクタリングという性質上、いわゆる目に見えるような形での成果はなかなかありません。
ただ今後の改修を安心かつ高速に実施できるようになったことは非常に重要であり、エンジニアとしても一回り成長できた、非常に有意義な体験となりました。
そして2つ目、スクラムでの開発がうまくいかなかったことについて。
こちらについてはやり方うんぬんの問題はありつつも、結論としては最初にチームメンバーでスクラムに対する認識を揃えておけなかったことが一番の問題であったと思います。
まず起こっていたことしては、デイリースクラムやスプリントプランニング、ふり返り会(スプリントレトロスペクティブ)といったイベントについてもある程度形式に沿ってやってはみたものの、どこか進め方や生み出されるアウトプットがしっくりこない、結果として「なんかやりにくいなあ」といった状況が続いていました。
そしてスクラムマスターがいなかったこともあり、その軌道修正を図る動きも起こりづらくなっていたという背景もあったかと思います。
どう改善を試みたかというとトリガーとなったのはふり返り会で、上述したような「スクラムにおける動き方についてそれぞれの頭の中に正解があり、そもそもそのすり合わせができていない」といった課題が挙がったことでした。
そういった意味では、ふり返り会が一定機能していたことが最後の砦となり、そこから改善の動きにつながったことは重要なターニングポイントであったと思います。
その後の流れとしては以下のようなことをやりました。
- 対象図書を決めて読書会を開き、チームとしての認識を揃える
- 仕事の進め方やチームとしての考え方をドキュメントに明示し、各イベントの進行方法などについてもフォーマットを固める
- 少しでも疑問に思うようなことがあれば、タイムリーに相談して話し合う
- 話し合った結果変わったことがあれば、それをすぐドキュメントなどに反映し、実際に試してみる
そして少しずつ改善を重ねながら、以前と比べるとチームとして同じ方向を向いてメンバーが自立してスムーズに動けるようになったことで、アウトプットの質と量の向上にもつながってきていると感じます。
ただ形式どおりにやるのではなく、自分たちのチーム状況にあったやり方を都度考えていく中で悩み抜いたことが、確かな財産となって今があるんだろうなあと実感しています。
いわゆる個に閉じた開発スキルといったものとは少し性質が異なりますが、チームとして開発を進めるという点において、これも非常に大きな学びとなりました。
おわりに
とは言え、全てを自分たちで一から解決しなければならないということは決してなく、困ったことがあれば先輩社員が気軽に相談に乗ってくれたり、壁打ち相手になってくれたりといったことも支えになりました。
また Slack におけるコミュニケーションも活発であり、スクラムについてはアジャイル開発に関するあれこれを相談できる #iikanji-agile といったチャンネルでのアドバイスも参考になりました。
そういった中で失敗も成功も経験し、開発に取り組む際に半年前の自分では絶対に出てこなかったであろう選択肢が自然と出てくるようになったときに、少しは力がついてきたんじゃないかな?という自信が生まれてきていると今では感じます。
まだまだ貪欲にインプットとアウトプットを繰り返していく必要はありますが、
- 新しいフレームワークや開発手法に取り組むことでエンジニアとしての幅を広げることができた
- その前提として、本記事で挙げたものに限らず新しいことに取り組むことへの理解や活発なコミュニケーションがあった
ということを、結びの言葉とさせていただきます。
BASE では、このように一緒に試行錯誤しながら、会社としても個人としても成長できる環境で、一緒にサービスを発展させていく仲間を募集しております。
カジュアル面談も実施しておりますので、ぜひお気軽にお問い合わせください。