shiozo

# プロジェクトの背景と課題 ### プロジェクト概要 建設業における、工事外の書類業務をITによって効率化、改善し本来の工事そのものに集中できることを狙いとしたSaaSアプリケーションになります。 その中で、**外部機関の提供するAPIを利用し、プロダクトに蓄積した工事情報を連携する機能**を作成しました。 ### プロジェクト実行時に感じた課題 - API仕様が複雑である点 - 連携データと、自社プロダクトのデータ的差分 - ドメイン駆動設計への挑戦 - 処理データ量の多さ # 担当業務 ### プロジェクトマネジメント 私自身もプレイヤーとして換算をしながら、プロジェクトマネジメントを実施 全体人数は私含め5人程で、プロジェクトの方針や外部機関との折衝、不確実性削減のため行動をしました。 - スタートアップと大企業（外部機関）の速度感の差を意識して最大効率で連絡を取る - ドメイン駆動設計という技術的挑戦もあったので、リード期間を設けることで初速を上げた - 連携をする上で、不都合となり得る点を精査し、外部機関とのやり取りで課題として取り上げ、双方納得する形で推し進めた。 - 目標を常に確認しつつチェックポイントの設定を怠らず、適切な工数で実施 ### 実装 対象データ量が多い、また今後利用ユーザの増加によるDBへの負荷を考慮し、バッチ処理用DBをユーザアプリと切り離して利用できる設計としました。 バックエンドFWとしてdjangoを利用したのですが、複数のDBを切り替えて利用するルーター機能に関する情報が少なく実装の際には、ドキュメントを読み込む等をして対応しました。 またデータの加工処理を常に成功した前回の差分から作り出すことで再実行時に必ず冪等となるような仕様、設計としました。 データを効率的に処理できるようORMだけでなく、チューニングしたSQLを部分的に使うことで処理効率を向上させました。 弊社プロダクトとして0~1で作るものが久々であったため今後のお手本となるような品質を目指し、ドメイン駆動設計、テスト駆動を基本とし実装しました。 # 学び - 目標設定とチェックポイントの設定 スタートアップとしては半年弱という、長期のプロジェクトでしたが、目標設定とチェックポイントの設定を徹底することで、無理なく対応することが出来た。 設定するだけでなく、常に見直すことも大事で、**長期的なプロジェクトであっても随所随所にインテグレーションの機会はある**のでそれを見逃さない目を養えたと思っています。 - 設計パターンや手法の選択肢 今回はドメイン駆動設計、テスト駆動設計を実施しましたが、プロダクトの規模やフェーズによってはドメイン駆動設計は毒にも薬にもなるなと肌で感じられたこと。 インテグレーションを前提としたサイクルを回す開発においてはテスト駆動設計は切っても切り離せないものであるという点を感じられたことです。 特にテスト駆動設計については、自分が想像していたより早く恩恵が得られたと思っており、慣れないドメイン駆動設計でコードの修正がやや多めに発生していたとも思っており、それを支えられたのはテスト駆動設計を徹底していた点だったなと。。 またテストコードは万能ではなく、モジュールが適切に設計されていることによってより力を発揮する、インテグレーションの回数を増やせば増やすほど効果が増すといった点