ID:47480さん

# 求人検索システムの改善・運用保守 ## 概要 障害者向け求人検索サイトの運用保守と要望対応、改善 ## 担当 フロントエンド・バックエンド問わず基本設計から〜リリースまで一貫して1人で担当 ## プロジェクト規模 全2名（PM1名,SE1名） ## 使用技術 PHP, MySQL, HTML, CSS, jQuery, AWS ## 参画経緯 1人の方が社内の他業務と兼務して運用保守されており、追加開発はほぼ行わず不具合には対応する程度だった。 フロントエンド / バックエンドの開発経験があり指示がなくても自ら効率化・改善を提案実施できると 弊社社長からの推薦によって参画が決定し、開発を一手に担うこととなった。 ## 実績 運用スタッフからの掲載文や画像の変更に対して、対応箇所の精査から改修そしてリリースまで1人で担当している。 定期作業として、複数の外部システムからのデータ取り込みとその反映を実施している。 ## 課題 ``` 1. 外部システムから求職者情報は連携できているが、求人情報の連携が実装できておらず手動登録をしている状態だった。 外部システムの求人情報を当システムの求人情報として取り込みたい。" ``` ### 取り組み 当システムの求職者登録API呼び出し処理と外部システムのAPIドキュメントをもとに、求人情報取得APIの呼び出しからデータ登録までを実装した。 ### 工夫点 まず必須パラメータのみで実データを数件取得してレスポンス形式を把握し、当システムのどのテーブル・どのカラムに当てはめるべきかマッピング表を作成した。 足りない要素についてはカスタマイズ項目があるかなどを外部システム運用者に確認、当システムでの表示フォーマットの要望なども合わせてヒアリングした。 外部システムのユニークIDを保持するカラムを新設し、照合して新規登録 / 更新 / 削除の処理を分岐した。 SQL負荷軽減のため1件ずつSQLを発行するのではなく、それぞれの対象リストを形成し一括SQLを作成した。 新規登録 / 更新 / 削除の一括操作について、テーブルや対象カラムを変更し他処理でも利用できる共通メソッドとして実装した。 SQLの最大文字数超過を防止するため、各カラムの最大文字数をもとに一括操作可能件数を定義、制御を追加した。 取り込み実行完了後、取り込み総数、新規登録 / 更新 / 削除それぞれの実行件数を画面に表示した。" ### 成果 平均約1500件の求人情報について、1分弱で取り込みが完了できるようになった。 ``` 2. GitHubへのマージ後に自動デプロイを構築していたが、現在エラーが発生してしまいデプロイが実行されない。 エラー原因の特定・解消 または 新規の自動デプロイを構築して欲しい。 ``` ### 取り組み 将来を考えた上で専門外が安易に構築するのは危ういと考えインフラエンジニアを参画させたいという提案し、自社の技術に信頼がおけるインフラエンジニアを斡旋、参画につなげた。 ### 工夫点 依頼があった際、まずはEC2など調べながら自分で対応できるかを確認した。 今後企業として拡大の計画がありシステムもより本格的に運用されていること・私自身がインフラ経験が浅く現状では調べながらの構築しかできないことから、将来的にトラブルが発生しインフラ再構築になるリスクなどを考えると、本格的に専門知識のあるインフラエンジニアに構築を依頼した方が良いと判断した。 単にインフラエンジニアの参画を提案するだけでなく、自社内で技術力・コミュニケーション力などを考慮して対応ができるインフラエンジニアを抜粋し、自社営業などに該当エンジニアの稼働を確保できるかなどを確認した。 参画したインフラエンジニアに現状と要望を伝え、構築にあたりアプリ側でのエラーが発生した際はエラー解消に協力した。 ### 成果 デプロイエラーが解消がされ自動デプロイが動くようになった。 インフラエンジニアが参画したことにより、インスタンスの最適化、各種環境の構築など本格的なインフラ整備も始動することになった。 自社からの増員を斡旋し、自社営業にも貢献したと社内で大きく評価された。

# 社内運用システムの改善・運用保守 ## 概要 オフィス利用者の勤怠や健康状態の管理をするシステムの運用保守と要望対応、改善 ## 担当 フロントエンド・バックエンド問わず基本設計からリリースまで一貫して1人で担当。 SE増員後はPLとしてタスク采配や優先順位決定、設計・開発サポートなども担当。 ## プロジェクト規模 2024年1月~ 全2名（PM1名,SE1名） 2025年3月~ 全5名（PM1名,PL1名,SE3名） ## 使用技術 Laravel8(Blade, JetStream), PostgreSQL, AWS ## 参画経緯 社外チームに外注して実装されたシステムだがその開発チームは解散。 1人の方が社内の他業務と兼務して運用保守されており、追加開発はほぼ行わず不具合には対応する程度だった。 フロントエンド / バックエンドの開発経験があり指示がなくても自ら効率化・改善を提案実施できると 弊社社長からの推薦によって参画が決定し、開発を一手に担うこととなった。 ## 課題 ``` 1. 管理スタッフ用画面の利用者一覧において、利用オフィスを列として示したい。 ``` ### 取り組み 利用者を所属会社ごとにグループ化して表示していたため、利用オフィスでの並び替えもしくはグループ化をした方が業務がしやすいのではないかと提案した。 その結果、利用オフィスでタブ表示をしたいと要望をもらい、列追加ではなくタブで実装をした。 ### 工夫点 利用オフィスを表示したい理由を考えた際、オフィスごとに利用者に対するアクションをしたいのではないかと思い、並び替え・グループ化を提案した。 提案をする際はより業務や実運用を想定しやすいように、文章だけではなく簡単なモックを作成してそのイメージを提出した。 改修対象画面を表示する際のSQLを確認したところN+1が発生していたため、納期に余裕があることを確認した上で合わせて課題を解消し、SQLの発行数を必要最小限に抑えた。 ### 成果 普段直接交流をすることのないスタッフから、画面がサクサク動く・業務がしやすくなったなどの複数の感謝のメッセージをいただいた。 スタッフ情報に普段管理しているオフィスを紐づけたい、企業とオフィスを関連づけたいなど追加の要望につながった。 ``` 2. 管理スタッフを都度SQL操作で追加しているため、登録画面を実装したい。 ``` ### 取り組み 既存である利用者登録画面などを参考にしつつ、Livewireを初めて利用して実装した。 登録画面のみの依頼ではあったが、登録済みの管理スタッフを確認する画面もなかったため一覧画面も実装した。 入力項目の必須表記を提案し採用され、新設画面だけでなく既存の登録画面にも反映した。 ### 工夫点 テーブル情報にて電話番号カラムがNOT NULLになっているが利用されている様子がなかったため仕様を確認したところ、必須である必要はないとのことだったのでNOT NULLを解除した。 参考にした利用者登録画面において入力項目が必須か任意か表記がなく登録ボタン押下時にバリデーションエラーが表示されて初めて分かる状態だったため、必須の表記をしたいと提案し採用された。 必須表記について、できるだけ多くの人が直感的に理解ができるようアスタリスクなどの記号ではなく必須と文字で表示するようにした。 ### 成果 管理スタッフ登録画面が実装されたことにより、管理スタッフからの依頼での開発者によるSQL操作ではなく管理スタッフ自身が任意のタイミングで登録できるようになり、開発者・管理スタッフ双方の作業軽減に貢献した。 必須項目が明確になったことにより、新規スタッフもバリデーションエラーを発生させることなく登録作業が行えるようになった。 ``` 3. カードを端末で読み取り、データ登録をしたい。端末とのシステム連携の実績はない。 ``` ### 取り組み 利用したい端末について、webで公開されている資料は自身で収集し、契約に紐づく独自情報は必要な内容を整理してプロジェクトマネージャーに依頼して該当資料を共有いただいた。 共有いただいたAPI仕様書を読み解き、要件に合わせたパス設計やI/Oの定義を実施した。 端末側の管理システムにて設定する必要のある項目を整理し、プロジェクトマネージャーに共有して設定を依頼した。 端末からのシステムアクセスについて、インフラにも連携をして、特定アクセスのみ許可するなどの設定を相談・確認した。 ### 工夫点 必要な情報や依頼する内容について、資料にある設定画面のキャプチャにマークをつけて添付するなど、できるだけプロジェクトマネージャーが悩まず単純作業できるようにした。 端末からはシステムへ直接アクセスするのではなく、外部連携用ドメインを形成して、外部連携用ドメインでリクエストをシステム向けに変換し、データ操作はシステムドメイン側で行うように切り分けをした。 端末都合の設定値とシステムでカスタマイズした値が分かるよう資料にまとめた。 端末資料を読み込む中で、将来的に利用できそうなステータス変更のAPI機能なども合わせて資料に記載をしておいた。 ### 成果 端末との連携は実現でき、リリース後運用を開始してからも大きな不具合は発生していない。 利用した上で追加の要望が出てきたが、仕様書を丁寧に記載していたことから別メンバーへ仕様書を見ながら改修をして欲しいと依頼ができ、ほぼ質問なく改修対応が完了された。 端末側の使えそうなAPI機能をまとめていた中から、これを利用した追加機能を開発して欲しいと新たな要望を受けた。

# 運営・請求支援システムの社内向け拡張開発 ## 概要 既存システムにおける社内専用機能の新規開発と既存機能の社内専用分岐の実装 ## 担当 フロントエンド・バックエンド問わず詳細設計から結合テストまで担当 フロントエンド・バックエンドを一貫して1機能丸ごと担当することもあれば、複数機能のバックエンドを一括で担当することもあった。 ## プロジェクト規模 全約25名（PM1名,PL4名,SE15名,PG5名） 在籍チーム構成約6名（PL1名,SE5名） ## 使用技術 Laravel(5.5), Nuxt.js, Go, MySQL, PHPUnit ## 参画経緯 外販向けに実装していたシステム開発に携わっておりシステムの構造を知っている 社内運用でどういった工夫がされているかなど大まかに把握している といった点からプロジェクトに新規参画するエンジニアの開発主導を見込まれ参画が決定した。 ## 実績 外部システムについて、システムに取り込むための項目の照合や検証・設計・実装（ダウンロード・インポート用のCSV形成を含む）・テスト・保守まで一貫して1人で担当した。 システムの初期開発から携わっていることにより実装の経緯などを知っており、それらを元にした意見や懸念などが重宝され、他メンバーよりも設計の早い段階から議論に参加した。 新規実装の際、関連する既存機能のメモリ負荷を検知し、工数に余裕があることを確認した上で負荷軽減・速度改善を実施した。それによりユーザーからの該当箇所の動作が重いという問い合わせが削減された。 開発環境やテスト環境での試験データについて、関連テーブルを紐づけた形でレコードを量産・管理できるExcelを自主的に作成した。個人やチーム利用を目的としていたが結果として他チームも利用するようになり、データ作成時間やデータ不整合のトラブルが削減した。 ## 課題 ``` 1. 大規模な開発として新規参画エンジニアを投入することになった。 別部署別システムを担っていた開発リーダー、外販システムに携わっていた既存エンジニア2名、新規参画エンジニア5名の体制。 開発リーダーは自身のタスク把握や他チームとの連携で手が回らないので既存エンジニア2名で5名の新規参画サポートをしなければならない。 ``` ### 取り組み 従来、開発ツールの導入手順や使用言語などの資料はあったがまとまっていなかったため 既存資料へのリンクをまとめたり稼働しているGitリポジトリの一覧を新規作成したりと、新規参画者対応の資料として整えた。 GitHubやコミュニケーションツールのアカウントなど、開発に必要な権限一覧を作成して事前に発行者へ依頼し 参画日までに必要な権限を全員分取り揃えた。 Windows,Macそれぞれの利用者がいる中で5人分の開発準備をサポートし、リモートでの開発が開始できる状態にした。 ### 工夫点 コミュニケーションツールの導入手順や各チャンネルの用途説明、参画前日までに迎える側が用意しておくべきアカウントや手続き一覧など 開発作業だけでなく新規参画者がオフィスへ初出勤されてからローカル環境での作業開始ができるまで、を考えて資料を参画日前までに作成した。 人数分のチェックリストを作成しておき、できた部分にチェックを入れてもらいつつ作業を進めた。 途中で発生したエラーなどはチームメンバー全員が見れるチャットですぐさま共有し、同様の事象での質問が減るよう努めた。 また、サポート完了後にそのチャットを遡り、参画準備中のトラブルシューティングとして資料に追加した。 ### 成果 新規参画者5名一括の参画サポート・環境構築だったが、事前に準備のおかげで約2日で全員がリモートでのローカル環境における作業が開始できた。 従来の新規参画者サポートの経験から3,4営業日はかかるのではと言われていた中で、迅速に開発着手できる状態にできた。 コミュニケーションツールの導入手順や事前アカウント発行リストなどはチーム外からも重宝され、プロジェクト全体の参画資料として利用されるようになった。 ``` 2. 非同期処理の実装に伴い、Go言語を利用することになった。しかしチームにはGo言語経験者が1人もいない状態である。 ``` ### 取り組み チームリーダーが文字列を返却するだけのGETメソッドAPIが動く状態は構築しており、そこから先はリーダー含めたチーム4名でモブプログラミングをすることになった。 一定時間ごとにドライバーを交代しつつ、1APIを協力して実装した。 ### 工夫点 通常開発がLaravelであり静的型付けに馴染みがなく型エラーがよく発生していた中で、誰よりも早くエラー箇所を特定し修正することが多かった。 頻発するエラーをトラブルシューティングとしてまとめたり、誤字を発見した際に開発は続行してもらい裏で類似誤字を探して修正したりと 自身がナビゲーターのターンであっても円滑に開発が進むようサポートを積極的に行った。 後からコミットログなどを見て実装順序が追えるよう、定期的にこの時点でコミットしませんかとこまめに促した。 ### 成果 開発リーダー含め全員が1APIの実装ができる程度まで理解をした状態でモブプログラミングでの実装を完了することができた。 その後他開発と並行するため全員がGo言語での開発はできないとなった際、Go言語の理解が最も早く高かったとして開発リーダーから残りのAPIの開発担当を任された。

# 運営・請求支援システムの新規開発 ## 概要 全国の施設における利用者の管理や利用者・行政それぞれへの請求計算と書類作成を行うシステムの新規開発 ## 担当 フロントエンド・バックエンド問わず詳細設計から結合テストまで担当 大まかな機能ごとに小チーム開発を行い、画面単位でフロントエンド,バックエンドを一貫して担当することもあれば、機能のバックエンドを一括で担当することもあった。 ## プロジェクト規模 全約16名（PM1名,PL4名,SE10名,デザイナー1名） 在籍チーム構成約4名（PL1名,SE2名,デザイナー1名） ## 使用技術 Laravel(5.5), Nuxt.js, MySQL, PHPUnit ## 参画経緯 1つ前に参画していたシステムの初回リリースが完了し初期不具合も落ち着いたことから、大型プロジェクトに招集された。 数年前に中止・凍結されてしまった今回新規開発の前身となるプロジェクトに参画していたことから 参考にする予定の資料について、作成の経緯や背景などの情報も覚えている範囲で構わないので提供して欲しいと依頼された。 ## 実績 別機能からのデータ連携について、設計当初は当機能表示時に情報取得する形となっていたが、処理の負荷が高くなることやデータ不整合の可能性を提示し、別機能担当者とも議論して別機能でのデータ保存時に連携をする形式に変更した。 結果、設計に含まれていた情報取得時のデータ不整合への考慮処理など一部を削減でき、処理を向上させた。 テーブル設計について、懸念されるケースなどの例をあげなからデータ構造を確認した。その際、いくつか考慮漏れが発見され改善につながった。 複数画面におけるAPI開発をほぼ一手に担うことにより、他メンバーがフロント開発・機能制御に注力できるようにした。 DBテーブル作成や各環境への反映・環境変数の検討反映など開発着手前の環境整備を一手に担い、各メンバーの作業開始前に整備を完了した。 ## 課題 ``` 1. 過去凍結したプロジェクトで実現しようとしていた機能をシステムへ追加したい。 過去凍結したプロジェクトでの機能の設計・実装をメインで担当していたことからメンバーとしての開発だけでなく 育成目的として配置するリーダーのタスク采配などのサポートも依頼された。 ``` ### 取り組み 過去プロジェクトで利用していた資料の発掘・整備を実施し、資料に記載のなかった当時の設計意図なども含めてチームメンバーに共有した。 改修の必要な箇所とそうでない箇所をチームで決めた後、過去ソースと照らし合わせて担当箇所の分担を采配した。 ### 工夫点 過去プロジェクトでの要望と現プロジェクトでの要望を整理し、踏襲すべき設計と改善すべき設計を分けた。 各所へのデータ連携APIのコール実装を依頼する際、APIの実装仕様だけでなくどういった意図でいつどの様にデータが活用されるのかも説明に含めた。 ### 成果 過去プロジェクトの設計だけでなく実装も一部復活・流用できたことにより、0からの実装よりも工数を大幅に削減できた。 連携の仕様だけでなく意図も合わせて説明したことにより、連携元各所からもデータ連携タイミングの提案などをもらうことができた。

# 福祉支援計画作成システム開発 ## 概要 児童福祉における1年間の支援の計画書作成システムの新規開発 ## 担当 フロントエンド・バックエンド問わず、詳細設計からリリースまで担当 開発メンバーとしての参画であったが設計も学びたいと志願し、画面設計 / データベース設計をメインの作業者として担当した。 ## プロジェクト規模 全約11名（PM1名,PL3名,SE6名,デザイナー1名） 在籍チーム構成約4名（PL1名,SE2名,デザイナー1名） ## 使用技術 Laravel(5.5), Vue.js, MySQL, PHPUnit ## 参画経緯 過去プロジェクトにおけるバックエンド開発において実装の早さと視野を広く持って開発する姿勢を評価され、修正業務より1から作る部分を担当して欲しいと声をかけられた。 ## 実績 ステータスによる画面制御が複雑な機能に対し、マトリクスを用いて整理をすることにより抜け漏れを防止し、確認者にも分かりやすくまとめた。 結果その機能でのパターン考慮漏れはゼロだった。また、確認者からも見やすいと評価いただき、他機能でも確認作業における雛形として採用された。 ## 課題 ``` 1. 参画当初、PLが設計を担当するということで設計を待つ状態であったが PLが前担当プロジェクトの対応に追われており設計に取り掛かることができておらず、スケジュール管理などもうまく回っていない ``` ### 取り組み プロジェクト運用について、スケジュール作成など私ができる範囲は代わりに動きたいと進言し、一部を担当するようになった。 設計についても、その当時運用されていたスプレットシートをもとに着手をしたいとPLに提案した。 システム全体のテーブル設計などは未経験だったが機能単位での複数テーブルの設計は経験しており、その際の能力を見ていたPMが任せても問題ないと判断してくださり レビューをしていただく前提でシステム全体のテーブル設計を任された。 テーブル設計完了後は作業の報告頻度や資料の完成度が評価され、そのまま画面やAPIの設計も担当した。" ### 工夫点 資料が何もない状態から作り上げるよりも、何かベースがあってそこに指摘修正をする方が労力が少ないと考え、PLの作業負担を軽減するためにベース作りを立候補した。 まず1テーブルずつ・基本的な認識齟齬がなくなって機能ごとの複数テーブルというように、作業依頼者の不安や作業後の手戻りが減るよう 最初は細かく確認依頼を出し認識を合わせた上で一定の作業を進めるようにした。 作業資料は共有しいつでも閲覧可能にしておき、PLが対応の隙間にわずかでも見て随時指摘ができる形を取った。 データベース設計においては、開発時にテーブル構造の変更が頻発する経験を過去にしていたため、そういった手戻りを削減したい思いから 何に着目して設計をすべきかなどを指導いただいた上で作業に取り組んだ。 ### 成果 PLが取り組む余力がなく設計スケジュールが遅れつつあったところを、予定通りのスケジュールまで戻すことができた。 開発中に何度か仕様変更があったが 設計時の動きやPLの負担が軽減された実績から、その後の開発においてもスケジュールなどの相談に乗って欲しいとサブリーダーとして任命された。 リリースを終えたのち、数年が経過するが大きなバグやシステム改修しなければならないという話は出ていない。 ``` 2. 従来運用されていたスプレットシートについて、マクロや関数を用いてアルゴリズムが構築されているような、単純なデータ形成だけではない複雑な構造をしている ``` ### 取り組み スプレットシートを作成し、利用するスタッフを統括されている方と直接お話する機会を設けていただき、現在の運用からシステムに期待することまで自らヒアリングをした。 ヒアリングの内容・内容を受けて設計の変更した箇所などを資料にまとめ、先輩方に自らの説明をしながらアドバイスをいただいた。 アルゴリズム解析用の質問・回答やそのグループが不定期に変更されると知り、質問を画面に固定文字列で実装するのではなく、データ保持してバージョン管理ができ過去質問・回答も復元できる構成にした。 ### 工夫点 マクロや関数の解析だけでなく、スプレットシートにおける入力方法や解析における意図や目的も合わせて確認をした。 連続する入力項目のずれや抜け漏れを防止するためにスプレットシートで適用されていた色付けなどはシステムにも適用した。 実装を担当するメンバーに、着手時に依頼内容だけでなく担当箇所の目的・用途についても説明をした。 ### 成果 利用するスタッフを統括されている方にアルゴリズムを取り入れ希望も叶え、よく実装してくれたとチームとして賞賛をいただいた。 リリース後、複数回質問のバージョンアップを経てもクリティカルな不具合は発生せず、兼務の運用チームでも安定して保守ができていた。 離脱してから数年後に、追加要望対応がありその際の開発チームから前任者として質問を受けたが、当時の資料を提示して的確に回答ができた。

# スケジュール管理システムの新規開発 ## 概要 児童福祉における施設利用スケジュール管理システムの新規開発 ## 担当 フロントエンド・バックエンド問わず詳細設計から結合テストまで担当 デザイナーもいなかったため、画面レイアウトや遷移構成まで担当した。 ## プロジェクト規模 全約6名（PM1名,PL2名,SE3名） 在籍チーム構成約2名（PL1名,SE1名） ## 使用技術 Laravel(5.5), Vue.js, MySQL ## 参画経緯 急遽優先度が上がった開発であり、他エンジニアは深い業界知識が必要な作業に携わっており手が空かない。 当開発は業界知識が少なくても着手できるということで経験・知識共に浅いが動きは良いということで任された。 ## 実績 Vue.jsの経験があるメンバーがいない中、カレンダー機能の実装について https://fullcalendar.io/docs/vue を自ら調べ導入から実装までを担当した。 Laravelにてデータ操作をするAPIを実装し、その値をVueの画面にて操作する実装を行なった。 ## 課題 ``` 1. デザイナーもいない中、スプレットシートを利用している運用をシステムに置き換えたい。 ``` ### 取り組み drow.io を活用して画面イメージ・遷移図を作成した。 作成した図について、プロジェクトの先輩方にレビューをいただき、何度も修正を行った。 ### 工夫点 先輩方にレビューをいただく際、その場で調整できる部分は即座に変更して確認をしていただき、何度もレビューの時間を割かないようにした。 どうしてその形にしようと思ったのか、意図や理由を明記もしくはレビュー時に口頭で説明した。 ### 成果 画面の設計を自分でやり遂げることができた。

# 就労支援システムの新規開発 ## 概要 全国施設利用者の書類を管理するシステムの新規開発 ## 担当 バックエンドエンジニアとして、実装から結合テストまで担当 ## プロジェクト規模 全約6名（PM1名,PL1名,SE5名） 在籍チーム構成約4名（PL1名,SE3名） ## 使用技術 Laravel(5.5), Angular, MySQL ## 参画経緯 Laravelを使った新規開発プロジェクトということで、設計から知り経験を積めるであろうということと 過去現場での意欲・行動を評価いただき自社から推薦という形で参画が決定した。 ## 実績 Laravel初体験だったが、他メンバーに学びながら進める前提での採用だったにも関わらずわずか2週間ほどで1人で実装ができバックエンドの実装について相互レビューもするようになった。 画面仕様書ベースだと動きが想像できないというお客様の意見を受け、HTMLやJQueryを用いてモックを作成し、会議のその場で動作確認をできるようにした。 モック作成者として会議にも参加し、お客様の要望をできる限り会議の場で即座にモック反映・確認することにより、仕様検討の工数を削減した。

# 産業ガスECサイト開発 ## 概要 産業企業向けECサイトの要望対応、改善 ## 担当 フロントエンド・バックエンド問わず、実装から結合テストまでを担当 ## プロジェクト規模 全3名（PM1名,PL1名,SE1名） ## 使用技術 PHP, MySQL, EC-CUBE, HTML, CSS,JavaScript ## 参画経緯 既存メンバーの離脱などがあり、経験が浅くとも実装ができるエンジニアが求められた際 若手ながらも疑問点などを積極的に質問し、開発するものの意義を考えながら実装ができるとして採用された。 ## 実績 ECサイトの利用者動向を分析するためGoogleアナリティクスを導入することになり、分析できる項目の調査と整理・サイトへの導入・お客さまへ提出する分析結果の作成をすべて1人で行った。 他プロジェクトにおいてもお客様先訪問は原則プロパーのみの中、パートナー参画として初めて訪問に同行するようになった。 常駐先企業がホスピタリティ向上の勉強会をするということで、普段意識していることや取り組んできることを参考にしたいとインタビューされた。 ## 課題 ``` 1. 営業とPMが月次でお客様の要望を確認して、その月の改修を決定するが 実装工数などが分からないままお客様感覚の見積で受けてしまい、結果的に遅延してしまう事象が多発している。 ``` ### 取り組み 自身の担当タスクが無理なく完了できるようになってきたタイミングで、要件整理や見積と開発スケジュールの案作成を担当したいと提案した。 お客様からの要望をもとに、対応整理・見積算出・想定スケジュールを作成した。 ### 工夫点 要望と合わせて提示された見積から長い短い問わず変化がある場合、必ずその変化の理由を添えてお客様からも営業からも納得を得ることができるようにした。 1ヶ月契約分の工数が微妙に余る場合、お客様として無駄が発生しないようにとこちらが気になっていた点などを改善提案として出した。 実装を把握したうえで要件を整理し、全メンバーの並行タスクやバッファも考慮してスケジュールを組むようにした。 ### 成果 スケジュールの遅延と要望に合わない改修が削減された。 当初エンジニアは不参加だったお客様との定期打ち合わせに、是非参加して欲しいと依頼され出席するようになった。 営業との契約に関する打ち合わせとエンジニアとのシステム開発に関する打ち合わせが分けられ、より開発が本格化した。 ``` 2. プロジェクト中盤よりオフショア開発が採用され、実装は海外エンジニアに依頼する形になった。 オフショア開発のノウハウがある人員はおらず、当プロジェクトを含めた数件がオフショア開発を開始したが認識齟齬による想定以上の手戻りが発生している。 ``` ### 取り組み 日本語は理解できるとのことだったため当初は日本人エンジニアと同じ設計書を連携していたが、オフショア用の設計書を書き直した。 進捗について、満たすべき要素をチェックリストとして作成した。チェックリストを記載をしてもらい、できている/できていないを指摘した。 ### 工夫点 設計書の日本語を英語に翻訳してから再翻訳して、意味が変わっていないことを確認した。 日本語ならではの言い換えを極力統一した。（例：入力する、記入する、記載する = 書く） 求めている精度が伝わらない場合、工数は多少かかってしまうがサンプルを1つ作成して提示した。 ### 成果 1ヶ月ほど試行錯誤を重ねた結果、手戻りを削減でき、期限内に期待した品質の機能を完成させることができた。 他プロジェクトから依頼されてノウハウを共有した。その結果他プロジェクトでも手戻りが削減された。