目次
はじめに
こんにちは！2023年の新卒としてアソビューに入社した加藤です。プログラミング未経験からアソビューに参画し、現在はエンジニアとして開発業務に携わっています。
最近めっきり暑くなってきましたね...いや、もうね、暑過ぎますよ。日本はいつからアマゾン川流域になってん🥵
今回のおはなし
さて、プログラミング歴2年目の私ですが、入社〜現在に至るまで2回の設計を行いました。
今回はそんな私が、設計の際に意識したことを書き留めようと思います。
1回目に行った設計を通じて得た学びや反省点を通じ、2回目の設計ではどのようなことを意識したのか、という流れをシェアできればと思います🫡
若手エンジニアで設計を行う方は、ぜひ参考にしてください！
1回目に行った設計
まず、本項では1回目に行った設計と実装、その際の反省点を紹介します。
設計詳細
1回目は、アソビュー！のTOPページに表示される画像登録をCMS化させる、という実装の設計を行いました。
結果
この実装を行うことで、以下の問題点を改善することができました。
- 工数削減（実装前は更新に約2日かかっていたが、実装後は15分ほどで更新できるようになった）
- 掲載開始日を設けることで、1月1日などの年末年始休みの場合でも事前に画像登録をしておけば、当日に更新する必要がなくなった
反省点
一方で、TOP画像更新CMS化の設計を行った上で、以下の反省点がありました。
早くリリースしなきゃという焦りで設計が雑になった
とにかく期日までにリリースしなきゃ、早く実装しなきゃ、という焦りから、ユーザーとの仕様すり合わせ・設計が雑なまま実装を進めてしまいました。
その結果、以下のような状態になりました。
- 実装中に手戻りが発生
- 仕様があやふやなまま実装を進めたので、実装への理解もあやふや（レビュー指摘対応も受動的になってしまった）
- リリース後、ユーザーが使い方がわからない箇所が何点かある、という事象が発生した
設計書のレビューがしづらい
設計書を作成し、チームメンバーにレビューしてもらう際、「大丈夫なら、設計書にスタンプでリアクションをお願いします」というようなことを行ってました。
その結果、誰がapproveしたかという視認性が悪いため、チームメンバーが同じような修正依頼を何度も出してしまう...といったことが発生しました。
2回目に行なった設計
次に、本項では1回目に行った設計の反省点を通じて、2回目に行った設計と実装、その際に意識したことを紹介します。
設計詳細
2回目に行った設計は、施設情報拡充のCMS化です。
施設情報拡充とは、アソビューのチケットやアクティビティページに、当該施設様のイベントスケジュールや施策、FAQなどといった付加情報を掲載し、リッチ化させるものです。
（以下、アクアパーク品川様の例。ペンギンって可愛いですよね。私はアデリーペンギンが好きです🐧）
施設情報拡充は現状、ハードコーディングで行っています。ハードコーディングで行うと依頼〜反映までに最低でも2週間ほどかかるため、CMS化を通じて工数削減をするという目的のもと、設計に着手しました。
意識したこと
施設情報拡充CMS化に際し、TOP画像CMS化の反省を生かすため、以下の点を意識しながら設計を行いました。
ユーザーとのすり合わせを入念に行う
前回の反省を生かし、ユーザーとの仕様すり合わせは以下の点を意識して行いました。
- 要望には上がっていないが必要な機能、逆に要望しているが今は必要ない機能などの洗い出しを行う ＝MVP（Minimum Viable Product）的観点から、「最速で」「必要な機能」のリリースを行うための方針を固める
- 些細な疑問点でも、とにかく聞いて認識齟齬をなくす
設計書をレビューしやすくする工夫
設計書を作成する際、以下のような「レビューチェックシート」というものを設計書の下に配置しました。
レビューチェックシートを作成することで、誰がapproveしたかが一目でわかります。
そのため、設計書の修正を行なってから誰にレビュー依頼を投げれば良いのか、ということもすぐに把握できるため、やり取りの工数も減らすことができました。
V字モデルの意識
V字モデルとは、以下図のように開発工程とテスト工程で各作業をリンクさせ、検証作業を効率よく実施することです。
（参照:webrage V字モデルとは？https://webrage.jp/techblog/v_shaped_mode/ ）
ただ、アソビューの開発ではアジャイルを導入しているため、私は「V字モデルってウォーターフォールなのでは。これってアジャイルに向いてないんとちゃいますのん...？」と思っていました。
そんな矢先、「メーカーでのアジャイル、ウォーターフォール、そしてV字モデル：誤解を解き明かす」という記事に出会いました。
https://developer.mamezou-tech.com/blogs/2024/04/30/no-feedback-agile/
この記事ではウォーターフォール、V字モデルについて、
- ウォーターフォールは、一連のフェーズを段階的に進める方法で、1つのフェーズが100％完了すると次のフェーズに移る
- V字モデルはあくまで「スムーズなモノづくりの順序」を示したものであり、100%完了してから次の工程に進むという意味はなく、むしろ各工程の行き来が前提となっている。
と述べています。
なるほど、つまりアジャイルにおけるV字モデルで意識することは、
「とりあえず考えてわかることは設計に書き起こす。わからないことはそのまま放置してイテレーティブに実装、フィードバックを経てわからなかったところを設計に書き起こして...を繰り返す」.
ということですね！これで誤解が解けました。
結果
「ユーザーとのすり合わせ」「設計書レビューの工夫」「V字モデル」の3つを意識した設計を行なった結果、1回目のAPI実装と比較し、2回目のAPI実装ではリードタイム（オープン〜レビュー〜マージまでの時間）を劇的に改善することができました🎉🎉
（API本数は2倍、リードタイムは1/2！）
実装に対する理解度が深まり、レビュワーとも有意義なコミュニケーションを取ることができ、スムーズに実装を進めることができたのが要因かなと思います。
| 実装 | API本数 | リードタイム |
|---|---|---|
| 1回目（TOP画像CMS化） | 2本 | 1ヶ月 |
| 2回目（施設情報拡充CMS化） | 5本 | 2週間 |
2回目の設計での反省点
API実装のリードタイムを改善できた一方、2回目の設計でも反省点がありました。それは、設計に時間をかけすぎたことです。
設計を丁寧にやろうとするあまり、実装にバッファがあまり持たせられず、逼迫するという場面がありました。
次回設計を行う際は、
- 設計・実装する前にまずはロードマップを作成
- 大枠設計した段階でユーザーとの認識すり合わせを行う
- バックエンドの設計を早めに詰める、フロントエンド設計は大まかに行う（修正が効きやすいので）
を意識して設計を行います！
さいごに
いかがでしたでしょうか。設計をちゃんとすることで、実装もスムーズに進むことを実感しました。「急がば回れ」ということですな。
設計を行なったことがない...初めて設計を行う...といった若手エンジニアの方は、ぜひ参考にしてみてください！
アソビューでは、「生きるに、遊びを。」を実現するための良いプロダクトを世の中に届けられるよう共に挑戦していく様々なエンジニアを募集しています。
カジュアル面談のご希望も随時お受けしておりますので、お気軽にエントリーください！
お待ちしております。
