shiozo

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

# プロジェクトの背景と課題 ### プロジェクト概要 大手ケーブルTV会社用の、施工業務アプリケーションの新規機能追加開発です。 外部サービスののIOT機器を料金プランに含めるという対応で、公開された外部APIを利用し機器の利用設定等のプロビジョニングを行えるようにする対応です ### プロジェクト実行時に感じた課題 - 対応機器が2種類あり、うち1種類は海外スタートアップの機器である点 - 国内企業は外部APIの設計がされておらず、弊社開発と同時に作り始めていくという点 # 担当業務 # 要件定義・外部企業との折衝 導入したい外部機器の仕様や、導入上のアプリケーション側の壁等をまとめあげ、顧客に対しての説明資料を用意、プレゼンを実施しました。 また、外部企業の1つは海外もう一つはAPI未設計というのもありとにかくコントロール性を高く保つためやり取りをする上で必ず、ドキュメントを残す、非効率にならぬようコミュニケーションの精度を高めるため問題点、課題等の事前認識統一、利用する語句の統一を徹底しました。 また、API未設計側企業に対しては、他社の設計ではありますが、コンサル的な立ち位置を確保することで最後までコントロール性を高く保つことができました。 ### 担当機能の設計 外部APIは検証環境が用意されていなかったため、独自にモックサーバを建てる必要性を初期段階で訴え、設計工程に組み込みました。 外部APIを呼び出すというのがプロダクト上で初めてであったので、今後自社だけでなく外部APIを呼び出すケースが増えると想定しHttp通信用ライブラリを利用した汎用的なAPIクライアントを作成しました。 ### 実装からテスト モックサーバは、顧客が業務トレーニングとしても使いたいという要件があったため既存業務の通しに耐えられる用独自にDBを用意するなどして対応。 バックエンド機能の特にAPIハンドリング部分を担当しました。 また課題として海外企業のリリースサイクルスピードが早い、修正点を通達しないで修正するケース（実際開発期間中に発生し、問題となりました。。） を事前に変化を察知する仕組みが必要と考え、主機能の開発とは別で利用APIを定期実行で自動でコールし、前回との差分をチェックする効率化ツールを用意しました。 # 学び - コミュニケーションの重要性 黙々作業を求める層が多い業種ではあるが、プロジェクトを前進する上ではステークホルダーとの会話が特に重要であると学んだ。 課題解決のマイルストーンがしっかり話し合われて適切なFBが存在するならば実装プロセスの差異（品質担保するための技術力はもちろん大切ですが）誤差でしかなく、情報の不透明性から生まれる手戻りは事業観点から見るとマイナスを生むだろうなと感じました。

# プロジェクトの背景と課題 ### プロジェクト概要 大手ケーブルTV会社用の、施工業務アプリケーションの新規機能追加開発です。 施工工程として多くのプロセスがありながら、iPadより入力した帳票を最後まで入力しないと帳票を出力できず、並行した施工作業や、アプリのクラッシュ時に入力した帳票データが残らないという点を、一時保存という機能を追加することで解決するというプロジェクトです。 ### プロジェクト実行時に感じた課題 - 歴史のある大規模なアプリケーションであるという点から、知識などが属人化している - 大規模アプリケーションであるにも関わらず、テストコードが存在しない # 担当業務 ### 担当機能の設計 「一時保存」というデータ的な妥当性を求められる機能なため、特にトランザクションの意識、ユーザ業務の中でどこまで保存されていると嬉しく、逆に保存すべきでない箇所（施工業務なので業務ルール上データ的な新鮮さが求められる箇所）の洗い出し等、前回プロジェクトで疎かにしていた事前準備を徹底し設計業務に当たりました。 ### 実装からテスト 既存プロダクトが大きいかつ、慣習的要素が強いコードが多かった背景もありなるべく全体バランスを崩さないように実装しました。 またテストコードの重要性を、過去の単体ケースでの手戻り率等数値で語ることでステークホルダーを説得し、新規追加分についてはテストコードを導入しました。 # 課題 - ドメイン知識の複雑さ ドメイン知識については、自身が営業をできるのではないかと自信を持てるまで関連資料を読み込むことで対応しました。 - コード品質の低さ テストは、案件ごとにエンジニアがポチポチして実施するという非効率なものとなっていました。 また業態上エンジニアの出入りが激しかったため、人によらないテストの必要性を感じました。結果として全てに導入することは叶わなかったですが、前述の通り一部へ導入することができました。 # 課題 - ドメイン知識の複雑さ ドメイン知識については、自身が営業をできるのではないかと自信を持てるまで関連資料を読み込むことで対応しました。 - コード品質の低さ テストは、案件ごとにエンジニアがポチポチして実施するという非効率なものとなっていました。 また業態上エンジニアの出入りが激しかったため、人によらないテストの必要性を感じました。結果として全てに導入することは叶わなかったですが、前述の通り一部へ導入することができました。 # 学び - 一人では限界があるということ テストコード導入の件では、とにかくステークホルダーを巻き込むことの大切さを強く学びました。 場合によりますが、既に成熟した文化がある場合にそこに異議を唱えることの難しさと達成したときの肯定感はただ、言われたことをすればいいという中では得られない良いものでした。

# プロジェクトの背景と課題 ### プロジェクト概要 被介護者と介護施設を繋ぐ役割をもつケアマネジャーをサポートするサービスとなります。 介護施設の入居状況や、各入居者の加入オプションや入退去管理をWeb上で完結することで、ケアマネジャーが管理業務に追われることなく、本来の被介護者とのコミュニケーションへ集中できることを狙いとしています。 ### プロジェクト実行時に感じた課題 - 企画のみが存在する状態かつHowの部分や手を動かす人材の部分が決まっていない - 当時エンジニアとして参加した私は趣味でプログラミングをしていた業界未経験のエンジニアが担当 ### 使用技術 - Java1.8 - SpringFramework - SpringBoot - JavaScript - jQuery - AWS - EC2 - ELB - RDS - Amazon Route 53 # 担当業務 - 技術選定 - 基本設計、詳細設計、実装、テスト ### 技術選定について 選定自体は前述の通りとなります。 こちらに関しては正直反省点が多く当時自分のできる範囲で決めてしまったという点です。 特にエンジニアは何かを実現する際に、無意識に自分が出来るかどうかで発想してしまい、俯瞰すればより良い選択肢があるにも関わらず、目の前良いと思われるものを選んでしまう傾向があるかと思います。 今であるならば、リソース面やプロダクトの市場価値を試すべく軽量言語でのプロトタイピングと取り扱うデータのシンプルさ（究極今回の要件は所謂管理画面的なもの）からサーバーレスアーキテクチャを選択していたかと思います。 ### 実装業務について バックエンドサーバーをREST APIに従い実装。 知見等がなかったため特にURI設計などの仕様は既存のサービスであるGitHubやTwiter等を参考にしました。 フロントエンドは、Ajaxを利用した非同期SPAとして実装しました。 UIは掛けられる工数と、管理画面的な仕様であったためBootStrapを使用し簡潔に実装しました。 インフラは全く知識がなかったため、AWSのホワイトペーパーや、AWSSomeDayなどのオンラインカンファレンスを参考に、基本的なマルチAZ構成としました。 とにかく手が足りなかったため、当時選定した技術の中でなるべくマネージドに利用できる箇所はそれを徹底しました。 車輪の再開発を避け、セキュリティやUI等はFW、UIライブラリに頼りエンジニアが注力すべきDBのモデリング、業務ロジックの実装へ集中しました。 テストはテスティングFWを利用し、特に業務ロジックの複雑な箇所のみに絞りテストコードを用意、ビルドのタイミングで実施するようにしました。 # 課題 特に課題となったのが、未経験であった私が業務アプリケーションレベルのDBモデリングを以下にきれいに作りきるかという点でした。 走り初めは、ドメイン知識を仕入れることを疎かにした結果、新たな知識が入る度にDBの構造が変わるという最悪な形となっていました。 これではまずいと思い、とにかくどのような登場人物があるのか徹底的にリストアップしデータ的にまとめたほうが良いもの等を整理していきました。結果としてシンプルかつ無駄のないモデリングができたと思います。 # 学び - 無知は罪であるということ エンジニアは課題解決のプロであるべきで、視野の狭さは短絡的な解決を助長する - 責任範囲を広げること 実装は手段・過程であって課題解決にはもっと多くの要素が存在するということ