◎はじめに
お久しぶりです。次の現場に参画して数ヶ月が経ったので、その振り返りを記事にしてみました。
今回も前と似た感じの記事ではありますが、少しばかり書き方を変えています。
ちょうど設計書作成あたりで一区切りだったので、実装の話は次回に回す予定です。
◎環境構築
前回は1週間以上かかって苦戦した環境構築ですが、今回は意外とスムーズに終わりました。
手順書が整理されていて、作業量も少なく、迷うポイントがほとんどなかったのが大きかったです。
手順書には「各ツールの導入方法」「保管場所」「ログイン情報」などがしっかりまとまっており、GITからのソース取得もスクリーンショット付きで説明されていました。なので理解しやすかったです。
疑問点もほとんど発生せず、手順書ベースでやり取りできたので、確認依頼もしやすかったです。
◎事前確認用の資料
上司が以下の情報をひとつのExcelファイルに整理してくださっていて、設計書や改修箇所を探すのが楽でした。
- 要件定義書の対応課題と、対象画面ファイル名
- 要件定義書の画面名と、実際の表示画面名
- 改修後の画面イメージ図
- フロント画面のソースファイルパス
- 各画面で動く主な処理ソースのパス
- 全体フォルダ構成と、各フォルダの役割
自分でも設計書名や画面の開き方などを調べていたのですが、ちょうど調査途中で、この資料を共有いただけたので、最後は答え合わせのみにしか使いませんでした…(笑)
◎ソース確認の進め方
これまでは画面レイアウトの修正が中心でしたが、今回はフロントとバックエンドの両方に対応が必要でした。
そのため、上司に1パターンの「全体の流れ」を教えてもらい、動作確認の手順を掴みました。イメージとしてはこんな感じです。
メイン画面でボタンをクリック
→ 処理Aが走る
→ 処理Bが走る
→ 次の画面が表示される
この流れをもとに「バックエンドは開発ツール」で、「JSなどの画面側はブラウザの開発者ツール」でブレークポイントを設定し、どのソースが動いているかを確認していきました。
上司が多忙な時でも、自分で調査できる下地になりました。デバッグを繰り返したり、既存ソースを流用したりして、自力で解決できる機会も増えたので良かったです。
◎設計書の追加修正
設計書はしっかり作りこまれていて、読むだけでも大変でした。 改修対象外の部分になると、正直まだわからない箇所も多いです。
修正箇所も前回より多かったため、最初は上司が修正した設計書を参考にして、似た内容を横展開することしかできませんでした。真似して慣れるしかありませんでした。
➤設計書の追加修正を進めていく中で上司にアドバイスをもらい「画面レイアウト追加 → 項目追加 → 処理系の追加 → その他」の順番だと修正作業が進めやすいことに気づきました。
➤上司とのQA表で、不明点は以下のように整理して共有しました。
- 要件定義書の課題No
- 設計書ファイル名、該当シート名、セル位置
- 不明点の詳細（YES/NOで答えやすく書く）
質問文が多少長くなっても、名称を正しく書くことで、確認がスムーズに進みました。文字数はなるべく絞りつつも、必要な情報は落とさないよう意識しました。
感想
こうして振り返ってみると、少しずつ「どこをどう確認すればいいか」が見えてきている気がします。知らなかったことを教えてもらって、前より細部に注意できたり、ほんの小さな進歩でも実感できると嬉しいですね。
ここまで読んでいただきありがとうございました。
※本記事は、自分で内容と考えをまとめ文章の下書きを作成した上で、読みやすくするため一部で生成AIによる日本語のチェック・表現調整のみ行っています。
株式会社ONE WEDGE
IT業界に、 ITエンジニアに貢献する企業！
ひとつひとつ (ONE by ONE)の事柄を
「WEDGE」として繋ぎ真摯に 向き合い創造していく