入社1年目が自社サービスAPIを利用したアプリを作って実感した現在地

1. はじめに

この記事の概要

この記事は、外部の初学者向けに、NEXLINK API を用いた小さな試作開発を通して見えた課題や学びを振り返る記録です。

今回作成したのは、NEXLINK APIを利用して、1件1宛先でFAX送信を行う簡易Webアプリ「NEXLINK Mobile」です。
ただし、完成度の高いプロダクト紹介を目的とした記事ではありません。

むしろ、0→1で小さく作ってみたことで、普段の実務では見えていなかった前提や、自分の知識不足、設計や実装に対する考えの甘さがかなりはっきりと見えました。
そのため本記事では、何を作ったか以上に、どこで詰まり、そこから何に気づいたのかを中心に整理していきます。

NEXLINK APIとは

NEXLINKは、株式会社ネクスウェイが提供するFAX・メール一斉送信サービスです。
専用ツールによる一斉送信に加えて、APIタイプでは自社システムから直接送信指示を行うことができます。
詳細は公式サイトをご参照ください。

• NEXLINKとは
• NEXLINK APIタイプ

筆者のレベル

筆者は、実務でRailsアプリの改修や小規模な機能開発の経験はありますが、0からWebアプリを設計し、環境構築・API連携・画面作成までを一通り自分で進める経験は多くありません。
そのため、本記事は、既存の実務経験はあるものの、0→1の試作では多くの不足が露呈した立場からの振り返りに近い内容です。

プロジェクトの背景

このプロジェクトは、技術広報プロジェクトの中で、普段から自分の面倒を見てくださっているメンターの先輩から提案いただきました。
背景として、担当しているプロダクトは成熟期にあり、機能開発の機会は比較的少ないです。
そのため、NEXLINK APIを用いた0→1の小さなプロダクト開発を行い、MVPとしてのリリースを目指し、その経験や感想をもとにQiitaへ記事を投稿することが期待されていました。

また、自分としても、普段関わっているNEXLINK APIを、利用ユーザー側の開発者目線で組み込む体験をしてみたいと考えていました。
あわせて、自分が開発したアプリから実際にFAXを送る体験をしてみたかったです。

2. 作ったものの概要

今回作成したのは、NEXLINK APIを利用して、1件1宛先でFAXを送信できる簡易Webアプリ「NEXLINK Mobile」です。

このアプリでは、案件名・FAX番号・送信用のPDFファイルを入力し、確認画面を経てFAX送信を行うことができます。
今回は、NEXLINK APIを自分で組み込んだ最小構成のアプリとして、まずは「1件のFAXを送る体験」が成立することを目標にしました。

一連の流れ

アプリ全体の流れは上記のとおりです。
入力画面で案件名・FAX番号・PDFファイルを指定し、確認画面で内容を確認したうえで送信します。
送信後は、受付メッセージを表示する構成にしています。

画面イメージ

入力画面

案件名、FAX番号、PDFファイルを入力する画面です。
今回は1件1宛先に絞っているため、入力項目も最小限にしています。

入力後の画面

PDFファイルを選択すると、画面上にファイル名が表示されます。
入力内容を確認したうえで、次の確認画面に進めるようにしています。

確認画面

送信前に、案件名・FAX番号・ファイル名を確認できる画面です。
入力してすぐ送信するのではなく、1画面挟むことで最低限の確認ができるようにしました。

送信後の画面

送信後は、受付メッセージを表示する画面に遷移します。
まずは、送信処理が受け付けられたことを確認できる最小限の形にしています。

実装できた範囲

今回の試作で実現できたのは、主に以下の機能です。

• 案件名、FAX番号、PDFファイルの入力
• 確認画面での入力内容の確認
• NEXLINK APIを利用した1件1宛先のFAX送信
• 送信受付メッセージの表示

まずは「入力して、確認して、送る」という一連の基本動作を成立させることを優先しました。
そのため、今回は1件1宛先に絞り、できるだけ小さな構成で形にしています。

今後実装したいこと

一方で、当初はMVPとして入れたいと考えていたものの、今回の試作では実現できなかった機能もあります。

• ログイン機能
• 送信結果の一覧表示
• 過去の送信履歴の確認
• 入力や送信処理に対するエラーハンドリングの充実

現時点では、あくまで「NEXLINK APIを組み込んで、最小限の送信体験を作った段階」です。
今後は、こうした周辺機能も含めて拡張することで、よりMVPらしい形に近づけていきたいと考えています。

3. 開発の進め方と技術構成

この章では、試作をどのような流れで進めたのかと、それを支えた技術構成を整理します。

開発の進め方

今回の試作は、機能ごとにブランチを切って進めました。
実装がある程度まとまった段階で、メンターの先輩にレビューをお願いし、承認をいただけたらマージする流れにしていました。

また、実装中に詰まった点や設計の迷いが出たときは、その都度相談しながら進め方や方針を見直していました。
本務と並行していたこともあり、一気に作り切るというよりは、小さな単位で区切って進める形だったと思います。

そのため、機能を増やすことよりも、今回の試作でどこまでを対象にするかを意識しながら進めていました。

技術スタック

この試作では、Ruby on Rails を用いてWebアプリを作成しました。
フロントエンドは ERB と Bootstrap、データベースは MySQL を利用し、FAX送信処理には NEXLINK API を組み込みました。
また、ローカル開発環境は Docker Compose で構築し、本番環境まわりは SRE チームに支えていただきました。

技術スタック

項目	内容	バージョン
バックエンド	Ruby on Rails	Rails 8.1.2
言語	Ruby	3.4.7
フロントエンド	ERB	Rails標準のため個別バージョン記載なし
CSSフレームワーク	Bootstrap	5系
DB	MySQL	8.0.43
外部API	NEXLINK API	-

担当範囲

区分	内容
自分が担当した範囲	画面 / controller / model / API連携 / DB設計
SREチームにお願いした範囲	ドメイン / デプロイ先 / コンテナ実行基盤 / 環境変数設定 / DB確認用ツール接続設定

4. 詰まったことと、そこから見えた課題

今回の試作では、採用したコードや設計の意図を、自分の言葉で説明できない場面が何度もありました。
特に多かったのは、必要性を十分に整理しないまま技術要素を置いていたことと、見慣れた書き方を理由なく再利用していたことです。

具体例1：保存先の設計と ActiveStorage の理解不足

問題

PDFファイルの保存方法では、当初
開発：ローカル / 本番：S3互換
のように、環境ごとに保存先を分ける想定にしていました。

また、ファイルアップロード周りでは ActiveStorage を使う予定で考えていました。

背景

普段携わっているプロダクトの構成に少しでも近づけたいという意識がありました。
ただ、その構成が今回の試作に本当に必要かは十分に整理できていませんでした。

ActiveStorage についても、「ファイルアップロードを簡単にする機能」くらいの理解で、必要性や役割を説明できないまま使う前提で考えていました。

結果

今回の試作は利用想定数がほぼなく、実装難易度も踏まえると保存先を無理に分ける必要はないのではないか、という指摘を受けました。
その結果、保存先の設計は
開発・本番：ローカル
へ見直しました。

また、ActiveStorage も今回は不要という判断になり、組み込みませんでした。

具体例2：routing で見慣れた書き方を再利用していたこと

問題

routing では、public_id を使って以降の画面や処理を参照するために、次のような書き方をしていました。

scope "/fax/:public_id" do

この書き方について、メンターの方から「なぜ scope を使ったのか」と質問を受けました。
しかし、その場では十分に説明できませんでした。

背景

当時の自分は、とにかく route を作ることが先に立っていました。
scope についても、「共通する path をまとめて可読性を上げるもの」程度の理解しかありませんでした。

また、学習用に作成したプロダクトで見た書き方や、過去の断片知識をそのまま再利用しており、resources で Rails の規約に沿って表現できないか、という発想が抜けていました。

結果

説明できなかったのは、scope が何をするかそのものよりも、「なぜこの場面で scope を採用するのか」を考えずに使っていたためでした。

見慣れた書き方を理由なく再利用しており、Rails の規約を起点に考えられていなかったことが、説明できなかった原因でした。

この章で見えた課題

• 利用想定を整理する前に、技術要素を置いてしまっていた
• 動きそうな書き方を先に選び、採用理由を後から考える状態になっていた
• Rails の規約を起点に考える意識が弱く、見慣れた書き方を再利用しがちだった

そこから見えた課題と気づき

今回の試作を通して、特に大きかった気づきは次の4点でした。

• 利用想定より先に技術を置かないこと
  普段見慣れた構成や技術要素をそのまま持ち込むのではなく、今回の試作で本当に必要かを先に整理する必要がありました。

• 動くことと、採用理由を説明できることは別であること
  動きそうな書き方を先に選ぶと、その場は進んでも、なぜそれを採用したのかを説明できず、後から負債になりやすいと感じました。

• 小さな判断でも、技術負債は積み上がること
  メソッドをどこで切り出すか、変数を定義するかどうかといった細かな判断でも、可読性や保守性には大きな差が出ると実感しました。

• 普段の実務環境は、多くの前提の上に成り立っていること
  DB確認用の接続先やデプロイの流れなど、普段は既に整えられた開発・運用の土台の上で実装に向き合えていたのだと初めて気づきました。

また、普段のチーム開発では、こうした負債が溜まりにくいように、設計や実装の段階で細かくバランスが取られていたのだとも実感しました。

5. 今後に向けて

今回の試作を通して、まず優先して取り組むべきことは、Ruby / Rails の基礎理解を埋めることだと改めて感じました。
特に、書いたコードや採用した設計について、自分の言葉で説明できる状態を最低ラインにしたいです。
理解が曖昧なまま進めても、その場では形になったように見えても、結局は自分の力にならず、後から詰まることになると実感したためです。

また今回の経験を通して、0→1で小さく作り切ること、利用想定に応じて本当に必要な構成を見極めること、書いたコードを説明できることは、本来であれば、実務の中で詰まる前に、もっと早い段階で一通り経験しておくべき内容だったとも感じました。
それだけ、自分には基礎的な部分で不足しているものが多く、その不足が今回かなり明確になりました。

今回の試作では、本来実装したかった機能まで到達できませんでした。
そのため、ここで終わりにするのではなく、未実装の部分も含めて少しずつ作り進めていきたいと考えています。
完成度の高いものを一気に目指すというよりも、小さくても自分で考え、判断し、最後まで作り切る経験を重ねることを今後の課題にしたいです。

今回見えた課題は、今の自分に足りないものがかなり具体的に分かったという点では、大きな収穫でもありました。
この経験を一度きりで終わらせず、次の実装や学習につなげていきたいです。

• もっと他の記事も読んでみたい方

  • 【Qiita】株式会社ネクスウェイ【Organization】
  • 【note】ネクスウェイのエンジニア
    　

• 当社に興味がある方はこちら👀

  • エンジニア採用について | 株式会社ネクスウェイ

• 当社のサービスに興味がある方はこちら

  • 僕たちは「黒子のサービス」。CPaaSのリーディングカンパニーを目指すネクスウェイメンバーの野望