こんにちは！ウエディングパーク新卒1年目エンジニアのダテです。

今回は、研修の集大成として取り組んだ社内アナログ施策のシステム化を通して学んだこと、工夫したこと、今後の課題と感じたことをまとめたいと思います。

エンジニアとしての技術というよりかは、チームの一員として開発に取り組んでの思いをまとめているので、これからチーム開発を行う多くの方に見て頂ける内容になっているかと思います。

目次

  • 取り組んだ施策について
  • 苦労したポイント
  • 技術のこだわりポイント
  • 良かったポイント
  • 改善ポイント
  • システム化を通して大きく成長できたポイント

取り組んだ施策について

まずは今回システム化に至った背景とその社内施策についてです。今回システム化した社内施策は「シャッフル座席」というものでした。「シャッフル座席」とは出社時の社内活性化のために提案されたもので、毎朝出社したら座る席をくじ引きで決めるという内容です。

実際に「シャッフル座席」を導入してから普段は関わることの少ない社員の方たちと席が近くなることでコミュニケーションの活性化が起こった一方で、くじを紙で作っていたため「管理が難しい」という課題があがり、これを解決すべく私達がシステム化に取り組みました。

システム化のメンバー構成はディレクターが1人、デザイナーが2人、エンジニアが1人という普段の開発では経験することがあまりないデザイナー2人構成となっていました。

苦労したポイント

その1：スケジュール調整

なるべくメンバーの空き時間ができないように、開発スケジュールを敷くのがとても難しかったです。エンジニア1人、デザイナー2人という構成だったので、役割分担と負担の兼ね合いを考えるのにとても頭を使いました。最終的に、ディレクターが中心となって、クリティカルパスを元に3パターンのスケジュールを作りました。「このタイミングでここまで進んでなかったら違うパターンのスケジュールに切り替える」といったように臨機応変に対応できるスケジュールを決められたのはスケジュール通りのリリースができた大きな要因だと思います。

その2：アプリケーション側の環境設定

普段の改修案件ではなかなか触ることのできないデータベース接続の設定、Sentry導入の設定、メール送信の設定など知識が浅かったため先輩に聴きながら1歩進んでは立ち止まるというのを開発序盤では繰り返していました。質問をする度に丁寧に教えてくれる先輩がいてくれたおかげで無事設定をすることができたので本当に感謝しています。また、自分で設定を行うことで設定周りのファイルの理解が深まったのは苦労してよかったポイントでした。

技術のこだわりポイント

その1：非同期処理を一切使わなかったこと

非同期処理を使ったほうが情報のリアルタイム性を実現できるというメリットはあった一方で、その実装担当をJavaScriptを初めて触るデザイナーに任せる決断をしていたので、なるべくJavaScriptでの実装負担を軽くする手段を選びました。また、システムを利用できるのが社内に配置している1台のタブレットのみということが仕様で決まっていたので、データの差分が起きにくい状況だったのも非同期処理を使わない選択をした理由になります。

非同期処理を使わない分、1度のリクエストで取得する情報量が増えたのでLaravelでデータベースからデータを取得する際にEager Loadingを使用したりとデータ取得に掛かる負担を最小限に抑えるようにしたのもこだわりの1つです。

その2：データベースに保存するくじ引き結果を14日で削除するようにしたこと

くじ引き結果は毎日データベースに保存されていくようにしたため、増えれば増えるほどデータ取得への影響が出てしまう可能性がありました。そうならないようにバッチ処理によってくじ引き結果を定期的に削除する実装を行いました。

保存する日数を14日にしたのはコロナウイルスの感染判別にかかる日数が14日であるため、万が一社内で陽性反応が出た際の接触の指標にできるようにしたかったのが理由になります。（こちらも先輩からのアドバイスあってのこだわりでした。本当にありがとうございます。）

良かったポイント

その1：開発タスクを実装イメージができる粒度まで細分化したこと

自分が処理を頭でイメージできる粒度まで落とし込んでタスクを洗い出したことで、実装前から大体の流れをイメージしてすすめることができました。また、タスクの粒度が小さくなったことで工数の見積もりがしやすかったのも良かったポイントでした。加えて、デザイナーにお願いしたJavaScript周りもタスクを細分化していたことで初めてでもキャッチアップがしやすかったと言ってもらえたのが嬉しかったです。

その2：コードレビューの事前依頼をするようにしたこと

今回の開発では4人の先輩方にコードレビューの機会をいただいていたため、適切なタイミングで時間をもらえるかがスケジュール進行のカギでもありました。そのため、コードレビュー依頼日の目途が立ったら、いつまでに依頼ができれば希望日までに見てもらえるかを先輩方に事前に確認することで、タスクの優先度を調整しながら開発を進めることができました。これもスケジュール通りにリリースできた1つの要因だと思っています。

要改善ポイント

その1：設計レビューの質が悪かった

0→1の開発であったにもかかわらず、設計レビューに持っていく際に文章と言葉のみで説明しようとしていました。その結果、処理の流れや重要ポイントの説明がうまくできず、先輩の理解力におんぶにだっこ状態の設計レビューをしてしまいました。また、このときは設計レビューの本質を理解しておらず、「実装する前に通らなければいけない門」のように思っていて、変な緊張もしていました。もっと実装における不安点や不明確な点の相談、方向性が間違っていないかのディスカッションをする場としての意識を持って行くべきだったなと今では思っています。また、説明をする際もフローチャートやシーケンス図などを用いた視覚的な説明をするべきだったなとも今では思っています。

その2：タスクの受け渡し時のすり合わせができていなかった

リリース後テストの際に1つhotfix対応をしたのですが、修正の原因がデザイナーが作成してくれたモックアップをVIEWファイルに反映する際の分岐漏れでした。これはデザイナーとのすり合わせがしっかり出来ていれば防げたことでした。これはエンジニアとデザイナー間だけにとどまらず、実装方法が変わったときに新たにテスト項目として追加する必要がないかをディレクターとすり合わせる時もそうだし、チームで開発をしている以上、全員で認識をすり合わせておく必要があることを身にしみて実感しました。今回は最後のテストで気がつけたから良かったものの、もし気づけていなかったらと思うとゾッとしています。これからは今回のような社内システムだけではなく、世の中すべての人に使ってもらうメディアに携わるので、この失敗を胸にチームでの認識合わせを丁寧に行っていこうと思います。

システム化を通して大きく成長できたポイント

最後に、今回のシステム化を通して大きく成長できたポイントですが、「報連相」と「タスクの細分化」だと自分では思っています。

「報連相」

これはきっとエンジニア以外の方にも通ずることだと思いますが、関わる人達の「報連相」つまり「進捗、変化、意図を常に共有できているのか」というのは組織で仕事をしていくにあたって重要であり、仕事のスピードにも大きく関わってくると思っています。実際、今回チーム間で進捗や変化の報連相ができていなければ、臨機応変なスケジュール変更ができていなかったと思いますし、先輩へのコードレビュー事前依頼もなかったらスケジュール通りでリリースができていなかったと思っています。当たり前だけれど社会人として必要不可欠なこの報連相をシステム化をとおして学び、以前よりもできるようになったことは大きな成長の1つでした。

「タスクの細分化」

実は、このシステム化をする前の研修で開発タスクの細分化ができておらず、納得の行く結果を得られなくて悔しい思いをした背景がありました。その苦い思いがあったので、今回は細かすぎると言われるくらい細かくタスクを分割したら案の定開発がとてもやりやすかったです。また、細かくタスクを細分化することで実装イメージがつきにくい部分がわかり、そこの相談を先輩に予めしておくといったことにもつながったので、研修前の自分からしたらとても大きな成長だと思っています。今後の実業務においても細かいだろと言われるくらい細分化を行って丁寧な開発をしていきたいと思います。

最後に

今回のシステム化が無事完遂できたのは一緒に進めた同期3人と嫌な顔ひとつせず何でも教えてくれた先輩方がいてくれたこそだと改めて感じています。チームで1つのものを完成させる喜びを実業務に入る前に実感できたのは自分にとって、とても大きな財産になりました。これからはチームウエディングパークとして各メディアの発展に貢献し、全社でこの感動を味わえるように日々尽力していきたいと思います。本当にありがとうございました。

※今回のシステム化にいっしょに取り組んだデザイナーがまた別の視点でこのシステム化についての記事を載せているので、興味がある方はぜひご覧ください！

Join Us !

ウエディングパークでは、一緒に働く仲間を募集しています！
ご興味ある方は、お気軽にお問合せください（カジュアル面談から可）

採用情報を見る