出社

はじめに、「進めなければいけない」タスクを確認し、目標を設定することから始めます。
私の場合、経費精算システム（運用保守）や車両管理システムの開発など複数案件を担当していますので、対応漏れ・遅れを発生させないために、スケジュールを意識して仕事をしています。
朝はメールチェックも行いますが、本日は経費精算システムに関するお問い合わせが、財務部門から届いていましたので、内容を確認します。

お問い合わせ調査

財務部門からのお問い合わせは、「課題管理表」に記録します。
「課題管理表」は、ユーザーからのお問い合わせを記録し、進捗をエンジニア間で共有するためのデータベースです。今回のお問い合わせは、ある従業員（Aさん）が部門異動をしたところ、経費精算システム上のAさんの所属部門が更新されていない、という内容でした。不具合なのか原因調査を行います。経費精算システムに登録されている所属部門は、他システム（会計システム）の情報を自動（データ連携）で取得する仕組みになっています。
システムの構成や仕様が書いてあるシステム設計書をチェックしたところ、経費精算システムに登録の所属部門は、部門異動の翌日にシステムへ反映されるということがわかりました。結論としては、不具合ではないようです。

調査報告書類の作成

次は財務部門への報告準備を行います。
専門的な話は電話やメールでは伝わりづらいこともありますので、説明資料を作成します。相手方がITに詳しいとは限りませんので、図を用いながら所属部門のデータ連携処理について、要点を絞って伝えられるようにします。

報告資料のチームレビュー

基幹グループのメンバーに対し、調査結果の共有と作成資料のレビューを行います。
レビューは、作成者とは異なった第3者目線で確認してもらうことができますので、仕事ではよく行います。
メンバーからもらった意見を資料に反映させ、午後は財務部門へ説明に伺いたいと思います。

打合せ・結果報告

財務部門へ、作成資料を交えて調査報告をします。
事象の背景を説明し、理解を得ることができました。
各部門からITに関する様々な相談・要望を受けることがありますが、自分たちで調査回答を行うだけでなく、他のシステム開発会社が関与するものは、私たちが関係先に問い合わせて回答を得るケースもあります。

チーム内共有

報告結果は、「課題管理表」に反映させチーム内へ共有します。
情報を共有しておくことで、先々にお問い合わせを受けた時のナレッジとして蓄積することができます。
各部門との接点は、情報交換や意見・要望をもらうことができる大切な機会です。

車両管理システムの機能追加

お問い合わせ対応がひと段落しましたので、別案件に取り掛かります。
当社で開発した車両管理システムについて、機能追加の依頼が総務部門から来ていますので、仕様の検討を行います。1週間後には総務部門との要件定義^（※）の打ち合わせを控えているため、どのような形で追加機能を実装できるのかを確認します。盛込む内容やボリュームによって開発工数や費用も大きく変わりますし、ユーザーからの要望や使い勝手、組み立て方など、様々な要素を考慮しながら案を固めていきます。
要件定義の打合わせ資料として、追加機能の画面イメージや処理のフローをなるべくわかりやすくまとめていきます。

※要件定義：解決したい課題や目標を明確にし、システムに必要な機能や構成・進め方などを決めること。

総務部門への質問

今回の機能追加のようにユーザー要件やユーザー側の業務にひもづく様な仕事を進めていくと、不明点が出ることは少なくありません。
総務部門へ確認をする必要が出てきましたので、連絡を入れたいと思います。
私は総務部門の方と同じオフィス（グループ会社のビル）に常駐していますので、コミュニケーションもとりやすい環境です。
確認した内容をもとに、さらに仕様検討を進めていきます。

退社

間もなく退社時刻です。繁忙期ではありませんので、本日の業務はここまで。
1日の振り返りと明日のタスクを確認して退社したいと思います。

出社

私の担当プロジェクトは、来月に本番環境試験を控えていますので、今は試験実施に向けた準備が主な仕事です。
まず最初にメールを確認すると、開発会社から検証環境試験に関する資料が届いていました。
午後に開発会社と打合せの予定があるので、それまでに資料を確認することにしました。

次は、システム担当のメンバーと朝会です。
朝会では本日のスケジュール・タスクの確認や、役割分担、相談事項について会話します。
毎朝コミュニケーションをとることで、トラブルに早く気づき対処することができるだけでなく、チームとして協力しやすい関係を築くことができます。

受領資料のチェック

メールで受け取ったテストに関する資料（試験要項書）に目を通します。
『試験要項書』とは、出来上がったシステムが求められている仕様通りに機能するか、確認観点を記したものです。
試験内容は、システムの品質を左右するものなので、誤りや不足が無いかを入念に確認し、指摘事項を一覧にまとめて開発会社に送ります。

要項書の試験結果（想定）を確認したところ、お客様の操作ミスによって生じる可能性のあるエラーが確認項目に含まれていないことに気が付きました。
念のため仕様書を確認してみたところ、今回のエラーについてどのようなエラーメッセージが表示されるのか記載されていませんでした。
仕様書への記載を忘れてしまっている可能性があるため、開発会社へ確認する必要があります。

他の指摘事項と合わせて一覧に追記した後、開発会社へ「午後の打合せで確認させてください」とメールで返信しました。

プロジェクトメンバーミーティング

東急側のビジネス担当とシステム担当を含めた打合せに参加します。
課題一覧を見ながら、各担当者が進捗状況を報告します。

それぞれの担当で困っていることがあれば、ミーティングの前に「こんなことを相談したいです」という内容を連絡し、議題にします。
本日は、サービス取引状況を確認するためのマニュアルを作成している担当者から、システムの操作方法について教えてほしいという相談がありました。

私から情報共有として、午後の開発会社との打合せ内容について、プロジェクトメンバーが内容を理解できるように丁寧に説明しました。
システムの専門的な話になりそうな時は、事前に説明しておくとスムーズです。

外部のシステム開発会社と打合せ

午後の打合せ相手は、今回のサービスの主要部分を作っているシステム開発会社です。

いくつか課題となっていた部分を議論した後、午前中にメールを出していた試験要項書の確認項目について、お客様の操作ミスによって発生する可能性があるエラーが含まれていない事を改めて伝えました。
原因はエラーパターンの考慮漏れで、作成途中のシステムで試してみたところ「不明なエラー」と表示されてしまうことがわかりました。

「不明なエラー」という表示ではお客様にはわかりにくい表示ですから、新たなメッセージを追加することになりました。

開発会社から、表示するメッセージを決めてほしいと依頼を受けましたが、システム上のエラー発生時に鉄道スタッフ部門がどのような対応を行うのか確認をしてからでないと、適切なエラーメッセージが決まらないと判断し、持ち帰りの検討事項としました。

スタッフ部門との調整・資料作成

打合せ終了後、先ほどの打合せ内容について鉄道スタッフ部門に相談をしたいという内容のメールを送り、明日打合せをすることになりました。
相談内容が少し難しい話になりそうなので、説明用資料は今回の背景や事象（出来事）の説明について図を用いて丁寧に作成しました。

相談内容はシステム上のエラーメッセージの件ですが、検討が必要なのはエラーが発生したときの鉄道スタッフ部門の対応方法についてですから、スタッフ目線で資料を作成することが大切です。お客様にとってわかりやすく親切なシステムとなるよう、エラーメッセージのパターンをいくつか考え、パターン毎に鉄道スタッフ部門の仕事にどのような影響が及ぶかという視点で資料をまとめるようにしました。

私たちはシステム会社ですが、東急グループのサービスを利用いただいているお客様と、システムとの中間に立つ仕事が多い所が特長です。

より良いシステムであることだけでなく、より良いサービスであることを考える仕事にとてもやりがいを感じています。

タスクの整理 ～ 退社

終業時刻は18:30なので、そろそろ本日の振り返りを実施します。
一日の進捗内容を記録に残し、明日のタスクを整理し終わったら退社です。