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

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

Oneday Report

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

Daily Schedule一日の流れ

01

開発エンジニア宮田さんの一日

私は入社3年目です。新たに『共通会計ユニット(開発チーム)』に配属になり、グループ各社で導入を進めている大規模な会計システムの開発を担当しています。

東急テックソリューションズ(TSOL)以外の関係者も多く従事していますので、TSOL本社とは別のオフィスに行って勤務しています。社外の方と一緒に仕事をするのは初めてですが、関係者の皆さんも上司も親切にしてくれるのですぐに慣れてしまいました。他社の仕事の進め方・やり方を実地で学ぶことができ、とても勉強になっています。

【登場人物】

■TSOL以外の開発会社のエンジニア 複数名

■TSOLの共通会計ユニット(3チーム)
  • 『開発チーム』:設計・開発・テストを担当
  • 『展開チーム』:グループ各社へのシステム導入を担当
  • 『運用チーム』:導入後の保守(メンテナンス)を担当
09:30

出社

まずは朝会から始まります。
進捗報告、不明点の確認、連絡事項の伝達は毎日行っています。
同じチームのメンバーでも一人ひとりの作業は異なりますので、コミュニケーション不足に陥らないための大切な時間です。

朝会は『WBS(作業分解構成図)※』と『課題管理表』を全員でチェックし、作業の進捗状況とやるべきことを確認します。
作業の遅れが発生した場合は、速やかに気づくことができるのも『WBS』『課題管理表』とメンバーのこまめな更新のおかげです。

[(※)IT用語を解説!]

WBS(作業分解構成図)

プロジェクトを細かな作業に分解した構成図です。作業工程や進捗状況を明らかにすることで作業の抜け・遅れを防ぐことができます。 メンバー全員が1つのWBSを共有・更新することになります。

10:00

設計書の確認

私が担当するシステムの『設計書』を読み込みます。
開発作業は闇雲に作るのではなく、その元となる『設計書』があります。
自分で作成することもありますが、今回のように他のエンジニアが作成したものが用意されていることもあり、どのような仕様で開発を進める必要があるのかチェックします。

細かい仕様の確認も大切ですが、 その機能が何のためにあるのか、お客様がどのように使用されるのか、機能自体の役割を意識することも重要です!

[仕事の工夫]

担当の共通会計システムは、他の多くのシステムと連携(接続)して作られているため、システムの全体像を理解するのが少し大変です。『設計書』だけでなく、会計システム全体として求められている条件や目的を確認するために『要件定義書』もチェックし、理解を深めるようにしています。

11:00

開発業務

『設計書』の確認が終わり、作業に取り掛かります。『設計書』には作り方までは書いていないので、具体的な実現方法はエンジニアが考えて開発作業を進めます。わからないところはトライ&エラーを繰り返し、他の機能がどのように設定されているのかを参考にしながら、できるだけ自力で実装(コーディングや機能追加)します。

前に進めない場合は、 WEBや書類を調べたり関係者へ質問をして、作業が遅れないよう進捗を管理しながら進めます。

[心がけていること]

  • 質問が多い時は、自分のわかる事・わからない事を質問表にまとめて整理します
  • 作業の合間に、設定手順やエラー回避方法など、その工程で得た知識をまとめています
12:30

ランチタイム

渋谷は価格帯が高いので週に1回だけ、後輩と外ランチに行きます!
ランチは1000円以上ですが、選択肢が多く開拓するのが楽しいです。

13:30

開発業務(続き)

午前中の続きを再開し、今日は15時で終わりにします。

15:00

社内の定例会議

共通会計ユニットは3つのチームがあり、それぞれ役割をもって業務を分担していますが、今日は3チーム合同で会議です。

普段は各々の活動拠点で仕事をしていますが、 週一回、全チームで集まり情報共有を行います。問題点だけでなく、共有しておくとお互いプラスになる情報もありますので大切な時間です。ユニットメンバーと顔を合わせるので、社内メンバーの人柄や近況を知る場になっています。

17:00

不明点の確認

本日の進捗報告や質問などを上司へ行います。ここで、開発業務でまとめていた『質問表』 が役に立ちます。
上司には、作業中の疑問点だけでなく、『これなんだったけ?』『今更ちょっと聞きづらいけど、、、』 というような事柄もなるべく質問するようにしています。(あの時聞いておけばよかったということを防ぐことができます)

18:30

退社

今日の業務は順調でしたので定時で退社したいと思います。

その他の担当業務

開発業務が終了すると次はテスト(試験)に入ります。
せっかくなので少し紹介します。

開発したアプリケーションが想定通りの性能・機能に達しているか、バグ等の不具合が起きないか、品質チェックを行う仕事です。

[テスト工程の業務]

  • テスト仕様書の作成
  • テストデータの準備
  • テストの実施&エビデンス(履歴や実施結果)の作成
  • レビュー依頼&修正
  • 故障管理表の更新(故障があった場合)
    ※『故障』とは、ソフトウェア上の不具合(バグ)を意味します

テストは単調作業のイメージが強いようですが、システムの仕組みを理解できていないとテスト項目の作成はできませんし、色々な利用状況があるという想定を考えますので頭を使います。
バグを発見した際の改善は自分で対応することも多く、原因を突き止めて改修するのはなかなか骨の折れる仕事です。
テストは製品を磨き上げるための仕上げ作業になります。

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. 開発と試験計画

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