はい。よろしくお願いします。あるサービスの価格改定に伴う開発の話になります。

お客さまから「○月から料金を切り替えたい」というご相談をいただいたのが始まりです。グローバルなサービスということもあり、当時の為替の影響から1ヶ月ほどで対応が必要な状況でした。

そうですね。隔週でお客さまとミーティングを行っているのですが、初回のミーティングから次のミーティングまでの2週間で基本的な準備を整え、その10日後くらいにはシステム側で価格改定が完了している、というかなりのスピード感でした。

私にとって、この案件が特に印象に残っているのは、やはり「お金」を直接扱うプロジェクトだったからです。入社してまだ1年ちょっとのタイミングで、これほど大きな仕事を任されたことに、正直なところ大きなプレッシャーを感じていました。画面の表示が少し崩れるといった類の問題であれば、「直しますね」で済みますが、価格設定のミスは許されません。

お客さまに本来より多く支払わせてしまったり、逆にサービスが購入できなくなったり、あるいは安く購入されて事業運営に影響が出たりと、一つ一つの判断が非常に重要になる。その重圧は常に感じていましたね。

最も頭を悩ませたのは、ロジックの複雑さです。単に改定日になったら価格を一斉に切り替える、という単純な話ではありませんでした。お客さまからは、「継続利用のユーザーさんに対しては、旧料金のまま一定期間は利用できるようにしたい」という移行期間を設けたいという要望をいただいていました。

これにより、考慮すべきパターンが増えました。改定日の切り替えタイミングだけでなく、そこから一定の移行期間中のロジックも正確に組まなければなりません。

その結果、最終的には「絶対に失敗できない料金切り替えを、短時間で約50パターン実現する」という、難易度の高い改修になりました。

この案件で最も重要だったのは、高度な技術というよりも、複雑な分岐をいかに正確に「設計」するかという点でした。そして、その設計に基づいて徹底的にテストを行うことです。

一方で、時間は限られていましたので、パターンごとに優先順位を付けて、お客さまへの影響が最も大きいクリティカルな部分、例えば「サービスが購入できない」「誤った金額で決済される」といった最悪の事態を防ぐことを最優先に考え、そこから重点的に検証を進めていきました。

また、このプロジェクトでは、単に今回の価格改定を乗り切るだけでなく、将来も同様の改定が発生することを見据えていました。過去の価格改定時に作られたコードの中には、今回の対応では使いにくい部分もありました。そのため、これを機に整理し、将来の変更にも耐えられるような「いいコード」にすることも意識しました。変更の履歴が追えるようにログをきちんと残したり、ミスが起こりにくい手順を確立したりと、その場しのぎではない、持続可能な開発を心がけました。

はい、大きなトラブルなく無事に完了しました。リリースは日本時間の午前0時だったのですが、切り替えの瞬間はやはりドキドキしながら見守っていました。切り替え直後に、一部考慮漏れから軽微な修正が必要になり、夜中に親方であるさかぺさんと一緒に対応する場面はありましたが、サービスの根幹に関わるような致命的なミスはありませんでした。

この短期間での成功は、親方のさかぺさんの存在が本当に大きかったと感じます。お客さまからの『こういう場合はこうしたい』といった様々なご要望を、打ち合わせの場でさかぺさんが見事に整理し、実装可能な形に落とし込んでくれました。その姿を間近で見て、自分にはまだそのレベルの設計能力はないなと痛感し、大きな学びと刺激にもなりましたね。

はい。この話は、まさに青天の霹靂といった感じで始まりました。ある日、開発を手がけるサービスで使っているオンライン会議ツールが、2ヶ月後に使えなくなるというお知らせが突然届いたのです。

サービスの根幹となるツールで、使えなくなるとサービスそのものが成り立たなくなってしまいます。停止まで2ヶ月を切っているという状況で、サービスの行き先に大きな影響を及ぼす移行プロジェクトがスタートしました。

最初に着手したのは、代替となるツールの選定です。複数の選択肢を比較検討し、それぞれのメリット・デメリットを整理して移行先を決定しました。

加えて、この移行を機に、ただツールを入れ替えるだけでなく、サービスフローそのものを見直すことにしました。従来は、オンライン会議ツールを使ってユーザー同士が繋がるフローになっており、サービスの本サイトに訪れる機会が少なかったんですね。

そこで、新しいフローでは、サービス内のマイページにボタンを設置し、そこからユーザー同士が会議に参加できるように統一しました。これにより、ユーザーにサービスのサイトやマイページを訪れてもらう動機付けにも繋がりました。

最大の挑戦は、私自身が新しく使うことになったオンライン会議ツールやそのプラットフォームのAPIを業務で全く使ったことがなかった、という点です。普段使うRailsとは勝手が違う、未知の外部ツールのAPIを使うのは、まさに手探りの状態です。公式ドキュメントを読み解き、手元で実際に動かしながら、何ができて何ができないのかを検証していく日々でした。

お恥ずかしい話ですが、焦るあまり、ついドキュメントをじっくり読む前にコードをいじくり回してしまい、「なぜか動かない…」と時間を浪費してしまうこともありました。しかし、結局は公式ドキュメントにほとんどの答えが書いてあるんですよね。急いでいる時こそ、基本的な手順を飛ばさず、着実に仕様を理解することが、結果的に一番の近道なのだと痛感しました。この経験は、技術者としての姿勢を改めて見直す良い機会になったと思います。

技術的な課題以上に大変だったのが、プログラムの外にある問題、特にサービスの運営スタッフのアカウントの移行に苦労しましたね。

運営スタッフの多くが海外にいるのですが、こちらがスケジュール調整したアカウントの移行期間が、ちょうどその国の文化である長期休暇と被っていたり……。あとはパソコンが古いものしかなかったり、スマホがなくて二段階認証をどうしようという人もいたり……といろいろとハードルが存在しました。

まさに、私たち開発チーム、お客さま、そして海外の運営メンバーが一丸となって対応しました。海外のマネージャーにご協力いただいて、技術的な問題でパソコンが使えないメンバーへのフォローを行ってもらったり、二段階認証の問題をクリアしたりと、一つ一つ地道に解決していったんです。

同時に、開発側としては最悪の事態を想定した備えも進めました。万が一、期限までにアカウントの移行が間に合わないメンバーが出てきてしまう可能性を考え、「もし間に合っていなかったら、○○の機能は使えないようにする」「もしアカウント移行前に機能が使える状態になってしまったら、私たちにアラートが飛ぶようにする」といった、異常系の処理を組み込んだんです。

お客さまのサービスが止まってしまうことがないように、「もしこれができなかったら、何が起きるのか」を常に自問自答しながら開発を進めていましたね。

はい。無事に移行を完了できたときは、本当にホッとしました。

まさしくその通りです。そして、そのスピード感の源泉は、先ほどの案件と同じになるのですが、やはり親方であるさかぺさんの圧倒的な課題抽出力と設計力にあったと感じています。

お客さまの複雑な要望をその場で整理し、実現可能な仕様に落とし込んでいく。打ち合わせが終わる頃には、もうある程度の開発のレールが敷かれているんです。その強固な設計があったからこそ、私は実装や技術調査に集中し、短期間でゴールにたどり着くことができました。

はい。それから、これは納品のない受託開発の特徴でもあると思いますが、いずれの案件においても、単純にコードを書くだけではありませんでした。価格改定の複雑なロジックを考えたり、未知のAPIを調査したり、ツール移行に伴うアカウント移行をサポートしたりと、本当に多様なタスクを同時にこなす必要がありました。

他の開発会社であれば、役割がもっと細分化されているかもしれません。しかし、ソニックガーデンでは、お客さまと直接対話し、技術的な課題だけでなく、その周辺にある様々な問題まで含めて解決していくことが求められます。

それはもちろん大変なことではありますが、だからこそ得られる経験の幅と密度は非常に大きい。この二つの案件を通じて、プログラマとして、そしてビジネスに貢献する一人の開発者として、大きく鍛えられたと実感しています。

引き続き、さかぺさんのもとで弟子として修行を積みながら、さらなる力を身につけ、お客さまにより大きな価値を提供できるよう、一歩一歩成長していきたいと思います。