美しい時代へ ー 東急グループ

東急テックソリューションズ株式会社

Oneday Report

東急グループ内の事業会社において、鉄道系ビジネス部門のプロジェクト支援と
建設系事業会社の社内SEを担当している、エンジニア2名のある1日をご紹介します。

Daily Schedule一日の流れ

01

運用保守・開発エンジニア脇田さんの一日

私は、東急グループの建設系事業会社へ常駐し、約3,500人が利用する基幹系システムや業務アプリケーションの運用保守・開発を担当しています。常駐先で稼働しているシステム全般を統括しているシステム部門において、社内SEの立場で日々業務に励んでいます。

 

※基幹系システム:企業の基幹となる業務を担うシステムを指しています。
例:会計システム、人事給与システムなど

【登場人物】

■グループ会社(常駐先)従業員
  • 財務部門(経費精算システムのオーナー部門)関係者
  • 総務部門(車両管理システムのオーナー部門)関係者

    ※経費精算システム:会社に代わって交通費、物品購入にかかった金銭を、会社に申請して払戻しを受けるための仕組みです。

    ※車両管理システム:通勤や業務で車を使用するための申請・許可を取得する仕組みです。車検証や運転免許証などの管理も行います。


■当社メンバー
  • 基幹グループ(当社メンバーが所属する基幹システムや業務アプリケーションの運用保守・開発を担当するユニット)
09:00

出社

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

09:30

お問い合わせ調査

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

10:00

調査報告書類の作成

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

11:00

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

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

12:30

ランチタイム

本日のランチは、ナポリタン専門店でナポリタン焼きチーズトッピングを注文します。

13:00

打合せ・結果報告

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

13:30

チーム内共有

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

14:00

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

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

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

17:00

総務部門への質問

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

18:00

退社

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

その他の担当業務について

現在の業務は運用保守や要件整理が主ですが、開発が本格的にスタートすれば、要件定義以降の設計フェーズを担当することもあります。
また、大規模なシステム案件は、大手開発会社(システムベンダー)と一緒になってシステム導入を進めたり、ユーザーが実現したいことを目指すために、市場にある様々な大規模パッケージソフトから良いものを探すという目利きができるようになることも必要です。

  • 要件定義
  • 基本設計&詳細設計
  • コーディング
  • テスト(試験/動作確認) 
  • 運用保守
02

PMO(プロジェクトマネジメントオフィサー)宮坂さんの一日

私は、東急グループの鉄道系新規事業プロジェクトのシステムPMO(プロジェクトマネジメントオフィサー)として、プロジェクト支援をしています。
担当プロジェクトでは、ビジネス部門や外部の開発会社と一緒に仕事を進めています。
今回はシステム導入前のテスト(本番環境試験)を控えたある日のスケジュールを紹介します。

【登場人物】

■グループ内関係者

① プロジェクトメンバー

  • プロジェクトマネージャー
  • ビジネス部門担当者
  • システムPMO(私) と システム担当メンバー

② ユーザ部門

  • 鉄道スタッフ部門


■社外関係者
  • システム開発会社 3社
09:30

出社

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

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

10:00

受領資料のチェック

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

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

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

11:30

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

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

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

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

12:30

ランチタイム

本日はお気に入りの中華料理屋でランチです。

14:00

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

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

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

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

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

15:30

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

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

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

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

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

18:00

タスクの整理 ~ 退社

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

その他の担当業務について

本日紹介したプロジェクトは後半に差し掛かっています。
私は、このプロジェクトのスタート時から参加し、様々な仕事に関わっていますので、担当業務を3つほどご紹介します。

  1. 企画段階

    ビジネス部門と一緒に、新しいビジネス(サービス)に必要なシステムのイメージを『要求仕様書』に落とし込み、外部の開発会社へ提示し開発を依頼します。

  2. 要件定義

    システムの詳細を決めていく中で出てくる課題を、お客様が提供しようとしているサービスの業務とシステムの両面から検討していきます。これが定まらないと、システムとして具体的に何を開発し、何ができるようになれば良いのかが決まりません。

  3. 開発と試験計画

    開発スケジュール管理や品質管理を行います。今回のケースでは、複数の開発会社がそれぞれの担当領域を開発しているため、開発会社間の仕様連携と各開発会社が作成したシステムの結合試験計画や試験内容の確認を行います。