ID:71309さん

キャリアビジョン


技術と事業の両面で強いエンジニア

単純な知的欲求が高く、技術を極めることに喜びを感じるからです。しかし、技術はあくまで事業で勝つための手段であるため、本質は事業に強いエンジニアであることが必要だと考えています。

プロジェクト経験

2024年/3ヶ月以内

請求書発行機能の新規開発

# プロジェクト詳細 ▼プロジェクト概要 建設系SaaSサクミルにおいて請求書発行機能の新規開発をリードしました。期間は約3ヶ月、PdM・EMと私の3名体制で、要件定義からDB設計、API設計、フロントエンド実装、PDF生成まで一貫して担当しました。 ▼事業背景 建設業界は他業界と比較してDX化が遅れており、重要データを紙やホワイトボード、Excelで管理していることが多く、業務効率化が進んでいないという現状がありました。サクミルは建設業を営む中小企業に向けて業界最安値×高いプロダクト品質を提供することで生産性を高めることを目指しています。 当時のサクミルには「案件」「顧客」などの管理機能が存在していましたが、他社のプロダクトと比較して「請求書」が不足しており、サクミル導入に至らないケースが多かったです。「請求書」はインボイス制度対応のため会計処理上重要な書類であり、「案件」「顧客」「請求書」を一つのサービスで一元管理したいという要望が多く寄せられていました。そのため、請求書発行機能の実装が急務でした。 # 課題と取り組み ▼請求書という概念の捉え方 請求書およびその周辺概念は、関係者ごとに捉え方が異なる複雑な領域でした。 もしPdMやビジネスサイドが想定する請求書と異なる前提で設計してしまうと、事業価値に直結しない機能になってしまうリスクがありました。この課題に対して、DDDのユビキタス言語の考え方を参考に、概念整理と継続的な議論のプロセスを実践しました。 まず、請求書機能の要件をもとにDB設計を含めた概念整理を行い、請求書の目的、満たすべき項目、法律や他社プロダクトのAPIなどを調査して、請求書に関連する概念をNotion上で体系的に整理しました。次に、作成したドキュメントをもとにPdMおよびビジネスサイドと複数回のディスカッションを実施。概念の解釈にズレがある箇所はその都度質問・議論を重ね、共通理解が形成されるたびにドキュメントを更新しました。 結果として、チーム間で請求書ドメインにおける概念の統一が実現し、その過程で当初の仕様の考慮漏れなどを発見することができました。たとえば「請求先」という概念について、当初は「顧客」と同義と考えられていましたが、議論を通じて「顧客の中に部署や事業所単位で複数の請求先が存在する」ケースを整理し、これをモデリングに反映することでより現実的な設計を実現しました。さらに、議論の過程で「合算請求書(複数取引をまとめて請求する形式)」という建設業特有の概念を把握できたため、将来的にこの機能を実装する際の拡張性も考慮したテーブル設計を行うことができました。 ▼インボイス制度への対応 請求書機能の要件として、インボイス制度への対応が求められました。 しかし、PdMを含めチーム全体で制度そのものに対する理解が十分でなく、システムとして何を担保すべきかが不明瞭な状態でした。 そこで私は、国税庁の一次情報をもとにインボイス制度の目的や要件を整理し、ドメインマスター的な役割としてシステム的にどの条件を満たせばインボイス制度を満たせるのかを明確化しました。 結果として、仕様書に加えて以下の2点をシステム側で担保すべきであると新たに定義することができ、より良いプロダクト品質に貢献することができました。 1. 売り手側の登録番号のバリデーション  登録番号に付与されるチェックデジットを利用した検証ロジックを追加。 2. 税率別の消費税計算処理  税率ごとに端数計算を行う汎用的な税計算クラスを設計・実装し、将来の見積書・発注書機能にも再利用可能な形で抽象化。 ▼請求金額計算のパフォーマンス 請求書の合計金額は、サクミルのトップページである案件一覧画面のカラムの1つとして表示されます。正規化された構造のまま案件ごとにSUMクエリを発行すると、データ件数の増加に伴いパフォーマンス低下のリスクがありました。 請求書は一度作成されると更新頻度が低い、つまりリードヘビーな特性を持つと仮定し、テーブルの非正規化を採用しました。請求書作成時に合計金額を計算・保持するよう実装することで、結果的に一覧表示時の集計コストを削減しました。 ▼請求書フォーマットとPDFプレビュー生成 より多くの企業にサクミルの請求書機能を利用してもらうためには、請求書フォーマット追加の容易さとプレビュー生成の高速化が求められました。 請求書フォームへの入力内容を即座に反映し、高パフォーマンスでプレビュー表示できる仕組みを実現する必要がありました。 複数のnpmパッケージを調査・比較した結果、pdfmeを採用しました。 pdfmeは、JSON形式で請求書の描画位置を宣言的に定義できるため、非エンジニアでもフォーマットの追加・修正が可能という利点がありました。 結果として、リリース後に4種類の請求書フォーマットを迅速に追加でき、多様な企業ニーズに対応することができました。 # リリース結果 本機能のリリース(8月)により、導入社数が4月時点の100社から3月末には1,000社へと10倍成長を達成し、その功績が評価され顧客賞と呼ばれる全社表彰を受賞しました。顧客からは「請求漏れがなくなった」「複数サービスを1つに集約できた」などの声をいただき、業務効率化に大きく貢献しました。

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

マネージメント能力

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
あり
Zenn アカウント
あり
Speaker Deck アカウント
あり
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
あり

今後、身につけなければいけないと思っている技術は何ですか?

未入力です

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

未入力です

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
未入力です
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
未入力です
その他の特徴
未入力です
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で20代中盤
好きなテキストエディタ
未入力です
希望勤務地
東京都
希望年収
未入力
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?