はじめてのプロダクト開発～SMS 配信機能の改修～

当社のサービスである Synergy! のバックエンドを担当している桂川大輝です。2020年3月、Synergy! でカスタマイズ機能として提供している SMS 配信機能の改修を行いました。本記事では、私がはじめてのプロダクト開発を経て学んだことを振り返ります。

桂川 大輝（カツラガワ ダイキ）

2019年4月新卒入社のバックエンドエンジニア。主に Synergy! のファイル管理機能の保守を担当。

配属直後のお昼時、先輩に連れて行ってもらった近所の中華料理店の麻婆豆腐にハマり、それ以来、頻繁に通っています。はじめは堪え切れず少なめにしていた山椒の量もこの1年で少しずつ増え、成長を実感しています。

Synergy! SMS 配信機能について

SMS 配信機能とは

SMS（ショートメッセージサービス）とは、携帯電話回線を利用してテキストメッセージを送受信するサービスです。もともと携帯電話事業者間では70文字まで送受信することができたことからショートメールとも呼ばれています。

SMS はメールや LINE などの配信方法と比較して、電話回線を利用しているため番号が無効ではない限り、確実に配信することができるという特徴があります。

SMS 配信機能は Synergy! では非標準のカスタマイズ機能として提供されており、「すぐに確認して欲しい、もしくは緊急性の高いお知らせ」や「ホームページへの誘導」というメッセージを配信する目的で利用されていることが多いようです。

「SMS で長文を送信したい」という要望に対応

改修前の SMS 配信機能では、携帯電話事業者ごとの文字数制限による端末間のメッセージの相違を防ぐため、利用可能な文字数として70文字という制限を設けていました。

お客様が配信したいメッセージは URL が含まれる場合など、70文字では表現できないことも多く、「SMS で長文を送信したい」といった要望を受けていました。

そこで、初期リリース時は存在していなかった長文の送信が可能なサードパーティー製品の API を利用し、送信可能な文字数が最大700文字となる改修を行いました。

改修プロジェクトの概要

プロジェクトを通して新人を育成

当時から担当しているファイル管理機能では、保守が主な業務だったためプロダクトの機能開発する機会がありませんでした。そこで、実業務を通したバックエンドエンジニアの育成、つまり私が開発の経験を積み成長することを目的として、実装を担当しました。

ただし、普段担当している機能ではないため、機能の仕様から把握する必要がありました。

OJT 体制でのプロジェクトの進行

育成をも目的としたプロダクト開発ということもあり、私とトレーナーの2人による OJT 体制でプロジェクトを進行しました。

トレーナーは SMS 配信機能を以前から担当していた先輩社員で、設計、レビュー、リリースの立ち合い、スケジュールの管理のほか、細かな指導、相談などのサポートを担当し、私は機能の実装、テストの設計と実施、リリースを担当しました。

育成を目的としていることやリスクを考慮して工期を2ヶ月間と設定し、早期の利用を希望しているお客さまの要望も踏まえつつ、余裕をもってサービス利用開始日を設定しました。

結果として、最初に設定した工期からずれはあったものの、お客さまへのサービス提供開始は遅延なく行うことができました。現在は問題なくお客さまに利用していただいています。

振り返り

私がプロジェクトを通して学んだことがいくつかあります。特に心に残っている3つを紹介します。

1. リスクを考慮したスケジューリング

本番環境へのデプロイ直前にアプリケーションの不具合を発見し、トレーナーの判断により作業を延期しました。幸い、そのような可能性も考慮して、余裕をもってスケジュールを組んでいたため、冷静な対応ができました。

業務には期日があり、確実にこなす必要があります。それゆえ、スケジューリングには様々なリスクの考慮が必要であると学びました。

2. 仕組みをつくることによる属人性の減少

プロジェクト中に、以下のような出来事がありました。

• 本番環境へのデプロイ手順に小さなミスの混入
• 仕様の勘違いによる誤ったテストの設計

これらの主な原因は自分の理解の乏しさや、不注意です。意識するだけでは再発の可能性もあるため、ツールや仕組みを導入して、個人の能力や意識に依存せずに十分な確認を実施し、属人性を減少させつつ進行するという考え方を教わりました。

例えば、手順書作成時、変更箇所を明確にするためにバージョン管理ツールを導入することで、作業やシステムに不慣れな人が手順書を作成・実施する際でも誤りを検知しやすくなります。

また、仕様の勘違いを防ぎ理解の確認をするために、各工程の後にレビュー工程を組み込む事で、作業やシステムに不慣れな人が実施する場合であっても、確実な進行ができます。

3. プロダクトにふさわしいソースコード

保守性、可読性、パフォーマンス向上のために、ソースコードの記述方法については、命名規則や再利用性、シンプルさなど自分なりにこだわりました。しかし、自分がベストであると判断したソースコードでも改善の余地があるという指摘を受けました。

特に、オブジェクト指向に基づいたデザインパターンやアーキテクチャについてです。これらレビューを受けて様々な考え方を学ぶことができました。そして、ソースコードのベストプラクティスについて、より一層考えるようになりました。

先輩方から以下のような書籍を勧めていただいたので、次の機会に備えて読もうと思います。

オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)

オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座

アジャイルソフトウェア開発の奥義

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

終わりに

社会人1年目のエンジニアによるはじめてのプロダクト開発はこのように終わりました。想像していたよりも苦戦した分、経験でしか得られない学びは多かったように思います。

この経験を活かして、また経験が浅い＝伸びしろが大きいとポジティブに考えて、今後も精進して参ります！早速、担当している機能に対して今回の学びを活用して、業務の質を高めていきたいと思います！