小林

# プロジェクト概要 ドラックストア企業様向けのWebシステムについてIE11が利用できなくなるため全てChromeで動作するように修正するプロジェクトです。 本プロジェクトにおいては表向きではChrome対応ですが、システム全体を網羅的に検証するといういい期間のため、裏の目的も同時に設定しました。 - 表の目的　Chrome対応 - 裏の目的　システムの品質改善 表の目的としてはブラウザ対応のため、プロジェクトに使用できる期間は限られていましたが、今後のためにもできる限りの範囲で品質改善を行いました。 どちらかというとブラウザ対応よりも品質改善のための作業の方が時間がかかってしまいました。 # 本プロジェクトでの役割 本プロジェクトでは主に不具合修正とテストケース作成、環境作成、チームメンバーへの指導、ドキュメント整理、リリースなどを行いました。 ## Chrome対応 自分の担当している5システムのうち、クライアント様が選出された緊急性の高い4システムについて修正とテストを行いました。 現状IE11でのみ動作するシステムについて、動作検証と修正、リリースを行いました。 プロジェクトの流れとしては、下記のようになります。 1. 検証（1回目） プロジェクトの開始が3月とかなり時間的にギリギリだったため、まずは検証環境を整備してテストケース作成せずに画面で見えているテキストボックスやボタンなど操作できるものを網羅的に操作して動作不具合がないか、画面のレイアウトがIEと異なっていないかなどをテスト実施者の主観に基づいて不具合を検出するように依頼しました。 2. プログラム修正（1回目） システム担当者（自分）が不具合を修正し、再度検証環境へリリースします。 3. テストケース作成 ただ画面を操作するだけでは見つけられなかった画面や動かなかった機能の先にある画面についてのテストケース作成も作成してテスト実施者にテストしてもらいました。 このときに画面やマニュアルには記載されていない画面遷移をプログラムを解読して発見し、テストケースに盛り込みました。 4. 検証（2回目） 作成したテストケースを基に2回目の検証を行って1回目では発見できなかった不具合を検出します。 5. プログラム修正（2回目） 再度不具合について修正を行います。 1回目の修正でほとんどの不具合は修正し終わっているため、3回目の検証は行わず、ユーザーの受け入れ試験へ進みました。 6. 受け入れ試験 ユーザーに普段の業務と同じように使用していただき、動作に問題ないことを確認してもらいました。 7. 本番リリース IE11が使えなくなる前にリリースを終えることができました。 ## 品質改善 2022年にシステムを引き継いだばかりでもあったためそのシステムについての理解はあまり深くありませんでした。 また、システムについての開発ルール・コーディング規約・仕様書・設計書・自動テスト・テスト仕様書・議事録・最新のマニュアルなどのシステムについての資料などは全くなかったのでそれを整備することも行いました。 今回のプロジェクトでは自分の担当するシステムについて網羅的に検証を行ったため、システムについての仕様理解が深まりました。その知見を忘れないためにドキュメントなどで残すことにしました。 今回のプロジェクトではまだ改善しきれていない部分も多くのこっているので本プロジェクトが終了した後も継続して改善する予定です。 ### 画面遷移図 まずは画面遷移図を作成しました。 ユーザーからの仕様の問い合わせにおいてどの画面についてなのかを迅速に把握できるようになること、プログラム修正が発生した場合の機能テストの利便性を向上などを目的として、画面名、主な機能、出力帳票、特殊処理、権限による変化、遷移条件などを図にしました。 ### 自動テスト 次に、自動テストを導入しました。 別のプロジェクトで機能追加を行った際に既存の機能が壊れてしまったため、システム障害が発生していました。ユーザーへの不便はもちろん、そのリカバリのために長時間の残業が発生してしまいました。 既存機能のテストはそのプロジェクトでは行っていなかったこと、仕様が明確にわからなかったために機能追加が既存機能の破壊につながったことが原因と考えました。 そのため、自動テストを導入して既存テストを保護することで機能追加を行う際に必要以上に機能を壊すことに不安にならなくてよくなり、テストコードによって仕様を明確化したいと思い導入しました。 ### リファクタリング 自動テストと同時に、リファクタリングを行いました。 javaでの開発だったため、JUnitをインストールし、テストを書き始めましたが、そもそもコードがテストに適した書き方にはなっていなかったためリファクタリングも必須の状態でした。 役割を持たせすぎて肥大化したクラスを分割し、適切な箇所にビジネスロジックを移動し、重複したコードは共通化し、それぞれに対してテストを作成して自動でテストを行うようにしました。 ### ドキュメント整理 コードを修正する中でのアンチパターンやリファクタリング手法、テストコードについての経験を共有して組織全体で運用業務の負担軽減をしたいと思ったためなるべくドキュメントにして残すことにしました。 作成したドキュメントは以下のようになりました - 開発ルール 開発において気を付けること、ミスを減らすためのルーティン、可読性を上げるためのコメント、コミットルールなどを一つの文書としてまとめました。 新規アサインした要員が最初に読むものとして作成しました。 - ユニットテスト作業手順書・リファクタリング方針 いくつかの書籍を読み、そこから得られた知見の中で自分なりに伝えたいことをまとめました。 - 画面遷移図 今回のプロジェクトがあったおかげですべての画面を網羅できたと思います。 テスト実施者にテストケースだけではなく画面遷移図も一緒に渡したところ、テストケースには記載されているがどのように遷移したらいいかわからないという質問が1回目の検証に比べて大幅に減りました。（1回目と2回目でテスト実施者は別） - Tips その他の細かいTipsはテキストドキュメントで作り一つのフォルダにまとめました。 自分が運用するときに便利になるように作成したので、次の担当者にも便利なはずです。 - 初期環境作成手順書 環境作成についてまとまった資料がなかったため、いちいちjavaたtomcatのバージョンを口頭で伝えるという文化に嫌気がさしたので資料を渡せるようにしました。 ### 参考書籍 すべてを読破したわけではないですが、品質改善において参考にした書籍です。 - レガシーコード改善ガイド（翔泳社） - レガシーソフトウェア改善ガイド（翔泳社） - リーダブルコード（オライリージャパン） - JUnit実践入門（技術評論社） - ソフトウェアアーキテクチャの基礎（オライリージャパン）

# プロジェクト概要 卸売業を行っている企業様からの二次受けの受託開発です。 仕入入力、販売入力、締め処理、帳票出力といった卸売業におけるほぼすべての業務を行うシステムを業務効率化を目的としてリプレースを行うプロジェクトです。 クライアント様が提出されたRFPを基にフルスクラッチで開発を行っています。 # チーム 本プロジェクトでは大きく4つチームを分けてシステム構築を行っています。 - 共通基盤 - 市場向け機能 - 量販向け機能 - 管理機能 # 担当業務 私は管理機能チームのリーダーとして、主に締め処理と帳票出力機能の要件定義、設計、コーディング、テストを行っています。それに加え、関連機能のデータ移行を担当しています。 # マネジメント経験 マネジメント経験としては、管理機能チームは時期により2～5人と変動がありますが、メンバーの進捗管理を行っていました。 # 要件定義 要件定義においては、自身の経験が浅かったこともあり書籍を読むなどで知識や手法を学んでから着手しました。先輩や上司に協力していただいたこともあり大きな問題はなく進行することができました。 一次受け企業様の意向もあり現行システムを解析して同様のシステムを別言語で焼き直しするような要件定義を行なわず、現場ユーザーの業務ヒアリングを入念に行ってユーザーの煩雑に感じている作業を省くなど、無駄のない業務フローを実現するシステムの構築を目指して要件定義を行いました。 # 設計・開発 設計、コーディング、テストに関しては入社一年目から行っていることもあり順調な進行に貢献することができました。 設計・開発を行うにあたり常に心掛けていることは丁寧に作業することです。 例えば軽微な仕様変更があった際に、プログラムは修正しているが設計書は修正していないなどの齟齬が起こらないように都度メモを作成して修正対象を漏らさないようにしています。 また、コーディングを行う際には分岐する条件や処理の目的などをコメントに記載して後から読むチームメンバーや後々自分で修正するときに楽になるようにしています。 # データ移行 現行システムのデータを新システムで使用できるようにするためにデータ解析や移行プログラムを作成したりしました。 移行プログラムはストアドプロシージャで作成しなるべく時間がかからないような実装を心がけました。 # プロジェクトへの貢献 現行の業務システムで出力している帳票を解析することにより、内容が似通った複数帳票を一つの帳票へ統合し業務における煩雑さの軽減と、印刷用紙の使用枚数を減らすことを実現できました。 また、現行システムとは異なる専用端末で動作する実績を参照するシステムを統合しました。 # リリース こちらのプロジェクトは残念ながら志半ばで中止になってしまいました。

# プロジェクト概要 ドラックストア企業様向けのシステム開発、運用保守を行うプロジェクトです。 私が入社する以前よりそのドラックストア企業様の社内システムのほぼすべてを担っているため、新規のシステム作成よりも機能追加や運用保守を行うことが多いため一つのプロジェクトとして記入いたします。 # 勤怠管理システム 勤怠管理システムでは運用作業が主な業務でした。システムの運用を行うにあたっての電話対応やシステム調査手法など基礎的な知識などを学びました。 データ抽出やマスタ整備などの作業も行いました。 # 経費系システム 経費系システムにおいて運用と機能追加の開発を行っています。 経費系システムの運用においては運用手順を作成し、自分以外でも運用作業を行えるようにしています。運用手順を作成することにより副担当として配置している後輩への教育もスムーズに行えました。 機能追加においては中心となって動いていたメンバーが他の業務対応しきれないため、大体メンバーとして参加しました。仕様についてドキュメントの管理やテストが十分に行われていなかったためそのリカバリを行い、不具合が発覚した部分のコード修正とテストを担当しました。 その後のリリースと現場からの質問の対応なども行っております。 経費システムでは機能改修の要望が頻繁に発生しているため、次期機能改修に向けて要件定義を進めています。 # 安否確認システム 運用業務が主な業務でした。 メールでの安否確認を行うシステムであり、メールシステムのログ調査などを学ぶことができました。