ID:67192さん

## プロジェクト概要 動画コンテンツをWEBページに表示するためのCMS開発。参画当初はプロトタイピング開発から、システムの本番化、開発、運用・保守とプロダクトの各フェーズに関わる。エンジニアとPjMを兼任し、要件定義、詳細設計、開発、テスト、顧客折衝、スケジュール・進捗管理、企画・提案なども行なっています。 ## プロジェクトメンバー構成 * PM：2名 * エンジニア：4名 * デザイナー：1名 ## E2Eテストによる手動テストの工数削減 - 課題 - システムの規模が大きくなるにつれて、リグレッションテストなどの負荷が高くなっていた。 - E2Eテストを開発当初からメンテナンスしていたが、その価値について疑問視する声がクライアントから上がっていた。 - 周辺状況 - 手動テストについてはクライアントも負荷が高いことを認識していた - E2Eテストを開発当初からメンテナンスしており正常系の処理は概ね網羅していた。 - 手動テスト用のテスト仕様書は機能開発ごとに作成されており、仕様書の精度も洗練されていた。 - 大規模な機能開発が控えていた - 施策 - 大規模な機能開発に伴い、品質向上の施策として提案 - 段階的にテストを実装していくことで工数感を調整 - テスト仕様書をもとにE2Eテストでリグレッションテストをカバー。 - 結果 - 手動テストの工数が機能開発のリリースごとに10~15人日程度削減された - E2Eテストの価値が評価された - デグレ発生率が低下し、品質が向上した ## チーム内のコミュニケーション改善 - 課題 - 社内向けの情報伝達がスムーズにいかず、伝達漏れ・タスクの偏り・定期確認の漏れなどが発生していた。 - 周辺状況 - 日次、月次の定例・振り返りなどは実施していた。 - リモートなのでテキストコミュニケーションがベースだった。 - 人によって参加している会議とそうでない会議があった。その内容の共有はSlackで行われていた。 - 施策 - 週次で定例を実施し、その中で会議内容の共有、定期確認、チームとして改善すべき議題に関する議論を行うようにした。 - 各議題についてはNotionに記入するようにして、Slackのようなフロー情報ではなくストック情報として参照できるようにした。 - 結果 - 課題で発生していた問題について解消された ## リリースサイクルの改善 - 課題 - クライアントから開発生産性について指摘を受けた - 周辺状況 - 開発生産性について定義されていなかった - 施策 - クライアントの指す開発生産性についての仮説検証 - 開発速度について、PR数やオープンからクローズまでの期間などを定量的に調査。一般的な指標と照らして問題が見られなかった。 - リリースサイクルについて調査。2~3ヶ月に一度のPRDリリースとなっており、価値提供までの時間がかかっている点について費用対効果が薄いと感じられている可能性があることを確認 - リリースフローの改善 - 大規模な機能開発により、リリースごとに開発・テストの期間が伸びていた。そこで、機能を細分化した。 - 開発が直列的に行われていたため、開発リソースを整理。並列的に開発を進めるように改善した。 - 結果 - リリース頻度が月1回程度に改善された。

## プロジェクト概要 施工業者の仲介事業者の業務改善のためのWebアプリケーション新規開発。クライアントが自社でローコード開発したツールと連携し、施工業者の管理コストの削減を目指す。PL兼エンジニアとして参画。PM・デザイナー・クライアント・メンバーと連携しながらアプリケーション開発を行いました。 ## プロジェクトメンバー構成 * 構成：PM 1人、PL 1人、エンジニア: 4人、デザイナー: 3人 ## 開発手法の選定 - 課題 - メンバーの経験が全体的に浅く、開発をスムーズに行えるか不安要素が多かった。 - 周辺状況 - 施策 - 各メンバーの技術スタックを入念にヒアリング。大きくフロントエンド・バックエンドに分離できる可能性が出てきた。 - フロントエンド・バックエンドを分離した開発手法の調査。スキーマ駆動開発が適していると考えた。 - 結果 - フロントエンドチームとバックエンドチームに分担することで、開発そのものはスムーズに進めることができた。 - ただ、スキーマ駆動開発への理解度の浅さから、開発終盤に差し掛かるにつてフロントエンドとバックエンドの調整が必要な部分が出てきてしまい、トータルの開発速度が上げれたかというと微妙な結果になってしまった。 - 学び - スキーマ駆動開発においてはスキーマ設計を入念に行う必要があること。その設計部分を変更する際はフロント・バックエンドチームが同席した上でチームとしての認識を形成しつつ進めないと細かい点で齟齬が発生し、細かい調整が必要になってしまうということ。 ## 特殊な要件への対応 - 課題 * DBをFileMakerというローコードツールに置き換えるという特殊な要件があり、予期せぬ不具合などが多発した。その影響でスケジュールの調整や仕様の再検討などが必要な場面が多々あった。 - 周辺状況 - 調整や仕様の再検討が発生する可能性があることを前提に置けるよう認識を形成していく必要がある - 施策 - 工数見積もり時点で、PMに懸念点を調査・共有し、同意した上でバッファを多めに積んだ。 - メンバーのタスクで問題や困りごとが発生した場合は即共有するよう周知し、発生した場合に同期作業を行い共有認識を迅速に構築できるようにした。 - PMや顧客に情報を連携する際には「現状」・「原因」・「代案」の三点を持って話すことを心がけた。また、先方がエンジニアではなかったため、図式化するなどして仕様の提案・調整を同期的に行った。 - 結果 - 先方から一定以上の評価をいただき、システム開発後の保守対応などの継続的な開発のご依頼をいただいた - 学び - 想定外のエラーなどが多発した結果、バッファを多めに見積もっていても開発そのものは遅延してしまった。開発実績を元に細かく見積もりを修正しつつ、徐々に精度を上げていくように調整していればもう少しスケジュールに近い形で開発を進めることができたと感じている。

### 仕事の背景 * 業務委託(個人事業として) * 60~80時間/月程度の稼働 * リモート * PM1名｜デザインチーム(4名)｜開発チーム(4名) * 開発チームの構成：開発経験 2年 2人、開発経験1年 1人、業務未経験 1人 * タスクの管理、PM/デザインチームとの調整、顧客折衝、技術選定、開発などを行いました ### プロジェクトの目的 - 顧客がLPサイトから問い合わせが行われ、その問い合わせ情報を別システムに入力する作業をを全て手動で行なっており、入力のミスや運用コストが高まっていた。 - 手動作業を撤廃することで、運用コストの削減につなげる。 ### 特筆すべきアクション * アプリケーション作成の提案 * 顧客の運営するLPサイトからFileMakerにデータをPOSTできるようにするという要件がありました。その際に、FileMakerの仕様でリクエストに認証情報が含まれることがわかりました。 * 一方で、顧客の運営するサイトはメンバーの開発経験がない、PHPで作成されており、開発にコストがかかる状態でした。 * そこで、認証情報が漏洩するリスクを抑制しつつ、開発コストを下げる目的でLPサイトとFileMakerの中間にRuby on Railsで作成したアプリケーションを挟むことを提案しました。 * その結果、情報漏洩のリスクは解消され、開発コストを抑えることに成功しました。

### やったこと 立ち上げまもない部門の業務改善 ### ミッション 現状の課題を明確化しシステム導入による業務改善を提案すること ### 分析した課題 業務の区分が曖昧なため、情報の統制が取れていないという点が ### アクション 部門の業務に直接携わり、現場メンバー・関係部門メンバーにヒアリングを行うことで業務フローを洗いだしました。その中で定量的な業務、定性的な業務を仕分け、そして定性的な業務は業務フローの変更に柔軟に応じ、導入コストを低く抑えて実 践できるBPMSをの導入を提案しました。 一方で定量的な業務は部門の規模感・変化のスピード感から、ノーコード・ローコードツールによる開発が適していると判断し、それらのツールでアジャイル開発で活用するという方針を取りました。 ### 結果 BPMSの開発プロジェクトの発足 kintoneを使用した業務効率化ツールの開発を実施

### やったこと バックエンドからフロントエンドの実装、テスト、顧客との折衝 ### プロジェクトの課題 ドキュメントが整備されておらず、仕様の把握が困難だった ### アクション テスト仕様書の作成、JUnitによる自動テストの導入を提案しました。 ### アクションの理由 テスト仕様書を整備することで仕様書作成とテストの実施を兼ねて工数を抑えられると考えたからです。 コードの重複・肥大化が目立っており、保守・運用のコストとリスクが高まっていたため、リファクタリングを進める必要があったため。 ### 結果 テストカバレッジを80%程度まで上げることができました。 リファクタリングにより、コードを2割程度削減し、保守運用のコスト削減・リスク低減に貢献することができました。

## 新機能開発(Java/JSP/Servlet/Wijimo/jQuery) ### 背景 初めてエンジニアとしてアサインされた業務でした。 * 意識したこと 1. 実装の方針を定めてから作業に着手すること 2. 実装中に進捗の遅れが発生した場合など、こまめに冗長に報告・相談すること 3. 類似した機能の実装を行なっているメンバーにコワークを依頼し、効率的に進めること * 結果 メンバーも含めて大きな遅延を起こすことなくタスクを消化し、スケジュールに沿ったリリースを行うことができました。 ### 単体・結合テスト * やったこと テスト仕様書の作成、実施、報告 * 意識したこと テストケース、カバレッジが適切かフィードバックを頂いてから作業に移ること。 * 結果 テストケース漏れによる不具合などは特に発生しませんでした。