ID:74537さん

＃ プロジェクト概要 製造業向け受発注システムのリプレースを行いました。 事業成⻑による商流変化への対応と、上場に向けた会計処理の健全化を実現する為です。 ＃ チーム情報 エンジニア 15 〜 20 名、 3 チーム制（ LeSS ）のプロジェクトでした。 私は 1 チームのリード（ スクラムマスター、評価 / 採用 ）兼バックエンド開発者、および LeSS の運営を行っていました。 ＃開発・実装内容A 【概要】 既存システムは、少量多品種製品の受発注というビジネスニーズに応じ、 まず受注を作成し、その受注に紐付けるかたちで発注を作成するユースケースを想定したつくりとなっていました。 それを、新たなビジネスニーズである大量生産に対応するため、受注に紐付かない発注、つまり在庫を扱えるものに変える必要がありました。 既存システムの開発リードとプロダクトオーナーにより、改修よりリプレースするという判断となりました。 テスト不足でレガシー化している部分が多く、技術的負債を解消しながら進めるよりリプレースしたほうが早いということ、 および、他システムとの連携の視野に入れ、受注 / 発注 / 在庫の疎結合な API を確立させたいという構想があったためです。 【どのような機能の開発・実装か】 （どういう構造のシステムか書く） 大量製品を扱うようになったため、受注を前提としない発注、つまり在庫を作るための発注機能が必要になりました。 既存システムは受注に応じた発注を行う機能となっていたため、 受注、発注、 【課題・問題点】 - エンジニアリング上の問題として手動シナリオテストのみ存在し、テストに守られていないためリファクタリング による設計の進化が困難な状況でした。 【打ち手・使用した技術】 ＃開発・実装内容B 【概要】 【どのような機能の開発・実装か】 【課題・問題点】 【打ち手・使用した技術】 # 直近の大規模プロジェクト ## ポイント - Rust で Clean Architecture を体現した、マイクロサービスバックエンド API が複数協調するプロダクト ## 解決したい課題 ## 背景 上記の課題に対し、既存プロダクトの受発注モジュールが密結合していること、永続化されたデータを用いての会計処理 が困難であることなどの問題が顕在化しました。 大量製品を扱うようになったために、受注を前提としない発注、つまり在庫を作るための発注機能が必要でしたが、受発 注機能の分離が難しいつくりとなっていました。 また、製品マスターが正しく管理されていなかったため、会計処理上必要な受発注時点の製品情報のトレースが不可能に なっていました。 また、エンジニアリング上の問題として手動シナリオテストのみ存在し、テストに守られていないためリファクタリング による設計の進化が困難な状況でした。 これらの問題を鑑みリプレースを行う判断となりました。 ユーザーは社内の受発注管理者です。 ## 取り組んだこと ### 開発をどう進めたか 受発注システムを構成するプロダクトは 3 つ想定されました。 受発注自体を管理するもの、被発注者が使用するポータル機能、新たにつくる在庫管理システムです。 これらを 3 つのチームがそれぞれ担当するのですが、システムに依存関係があるためプロジェクトは協調して進める必要 がありましたので LeSS を採用しました。( LeSS の導入経緯と振り返りはイベントで行いました。) 商流が変わるためユーザーのオペレーションから再設計する必要がありましたので、 紙芝居( スプシ、Figma )を含んだプロトタイピングをユーザーに早めにレビューしてもらうという進め方を行いました。 このような不確実性が高いプロジェクトでしたので、スクラムベースで MVP を常に見直しながら進めることに特に配慮し ました。 ### コミュニケーション 基本的にスクラムではチケットにユーザーストーリーを表現し、チームで優先順位を合意して、手が空いたメンバーが優 先順位の高い順からチケットに着手します。 ユーザーストーリーはユーザー提供価値を現していますので、その中にはバックエンド、フロントエンドなどの複数種の タスクが含まれることが多いです。 一方、エンジニアは得意分野とそうでない分野を持っていますので、 discord に常駐していつでも声を掛け合えることを ベースに、必要に応じてペアプログラミングを行うこと推奨してコンテキストの属人化を排し、スキルトランスファーを 促進しました。 また、チケットに詳細な実装方針などは記載せず、背景と完了条件のみを記述するルールとし、不明な点がある場合は情 報を取りに行くように促すことで、チケットに対するオーナーシップを個々のメンバーが強く持ってもらうようにしてい ました。 ### 成果 上記ビジネス課題を解決し、運用されている状態となりビジネス価値に貢献できました。 また、汎用 API として外部システムとの連携も可能な状態となり、その構想が進んでいる状態となりました。

# 直近の小規模プロジェクト ## ポイント - 1ヶ月限定のミニプロジェクト - Clojure で Clean Architecture を体現した、マイクロサービスバックエンドAPI - XBRL 内の非定形データから企業情報を抽出 ## 解決したい課題 企業の有価証券報告書提出からそのコンテンツをプロダクトに反映するまでの期間の短縮とその工数、外注費用の削減 ## 背景 データ生成チーム経由で PDF から企業情報を抽出する作業を外注しており、 さらにその成果物をプロダクトに反映するまでに半年を要していました。 データの鮮度はプロダクトの価値に直結します。 データ生成チームが上記のようなペインをいくつか開発チームに共有しており、 その中から選択しました。 チーム開発が基本ですが、「ひとりプロジェクト」と呼ばれる取り組みがあり、これに自ら手を挙げて行いました。 ユーザーはデータ生成チームです。 ## 取り組んだこと ### 開発をどう進めたか まずはスパイクとして、ひとつの企業の XBRL を tsv に変換するコマンドをつくり、 数十社をサンプルとしてユーザーに示し、運用をイメージしてもらいながら、仕様とそれらの優先順位をざっくりと決め ました。 上記コマンドにそのフィードバックを反映した後、数百社をサンプルとしてユーザーに渡し、外注も含めたデータ品質 チェック作業を依頼しました。 それを行ってもらってる間、コマンドを REST API 化しました。 コマンドは書捨てのつもりでモノリシック、テストも必要性を都度判断して書きましたが、 REST API は Clean Architecture、 TDD かつアウトサイドインで実装を行い、可変性、可読性を意識しました。 ### 非定形データをどう扱ったか 取得したいコンテンツが含まれるエリアまでは XBRL で定義されたタグでたどり着けるのですが、そのコンテンツは一般 的な HTML タグで表現されています。 その構成は個社毎に異なるものです。 なので、Instaparse のようなパーサコンビネータ−を用いてかっちりやることは出来ないと判断し、以下のように「泥臭い が徐々に正解に近づいていける」やり方にしました。 まず、 tr を全て企業レコード候補とみなします。 それらを、ドメイン層で spec を用いて定義した企業属性群の値のプールへの適合具合を見て判定するようにしました。 spec とそれを構成する述語を調整することで、徐々に精度を高めてゆきました。 また、上記のサンプル企業データを e2e の expected としていたので、積極的に調整することができました。 ### コミュニケーション フルリモートの為、Discord の特定の部屋に常駐し、気軽に話しかけてもらえるようにしていました。 ミニプロジェクトなので、カンバンは作らず、 Trello を用いて画面共有しながらユーザーとストーリーの優先順位づけ、スコープの決定を行いました。 また、特に Clojure の知見を持っているエンジニア中心に、 ライブラリの選定やアーキテクチャの妥当性についてフィードバックを得て反映していきました。 ### 成果 上記品質チェックは OK となり、外注の成果物と遜色無いものになり、ユーザーに感謝されました。 # その他、過去のプロジェクト まとめて書きます。 前々職では、金融系、事業会社の経営企画をターゲットユーザーとした B2B SaaS の開発を行っていました。( 5 年 ) 当初はバッチ処理、後にマイクロサービス化が進んできた後では、名寄せ API はじめ各種バックエンド API、フロント (Web, BFF)などを開発していました。 チームは 4-5 人で、常にペア・プログラミングを行っていました。 前々職では、SIer で航空会社のデータ解析基盤などをつくっていました。( 3年 ) AWS Redshift、S3 などをデータストア、Tableau BI をフロントとした基盤で導入からサポートを行いました。