はじめに

NTTドコモサービスデザイン部でCiRCUSというシステムを担当している夏目です。タイトルの通り、仕事に対する愚痴を聞いてもらいつつ、華麗に乗り切った話を書きます。

どんな仕事をしていても、もっとこうできたらいいのになぁとか、なんでこんなことやってるんだろう、という疑問は誰しも感じたことがあると思います。私は常に目的意識を持って、他に楽できる手段はないかを考えるようにしています。要は目的さえ達成できれば、その道中は効率的にすべし、と考えています。

そういった意味で、愚痴はモチベーションの一つと捉えて、そこをいかに最適化するかを考えながら日々の業務を送っています。ここ1年間で愚痴が幸せに繋がったエピソードを紹介したいと思います。

その愚痴とは・・・

ずばりデータ管理です。

みなさん、どのようにデータを管理していますか？データといってもいろいろありますが、今回はよくあるExcelで管理しているようなデータについて。

私自身、データベースは全くの初心者ですが、愚痴をモチベーションにしてあらゆる方々の協力を仰ぎながらこの問題に対応してきたので、ご覧いただけると幸いです。

「このExcelに記入して返信してください」

例えば、来年度の予算を立てるとき、部内にヒアリングしますよね。

「↓このフォーマットを12/25までに全て埋めてメールで返信してください。」

#	部署	担当者	予算	支出月	カテゴリ	用途
1
2
3
4
5

するとこんなExcelが返ってきてマージしませんか？（返してくれるだけありがたいかも？）

#	部署	担当者	予算	支出月	カテゴリ	用途
1	経理部	鈴木一郎	1,000,000	2025年6月	旅費	海外出張費
2	経理部	鈴木二郎	300,000	2025/7	備品費	ノートPC
3	総務	三郎、四郎	2,500,000	202509	業務委託費
4	総務部	五郎丸	400,000	2025年4月4日	交通費	国内出張費
5	営業部	鈴木	30,000,000	2025年3月	接待費	A社様

ツッコミどころ満載ですね。

年月の書き方がバラバラ

Excelはそこそこ賢いので、一括で統一させることも可能ですが、「202509」のように文字列のようになっていると扱いづらいですよね。

部署、担当者名の書き方がバラバラ

●●部の人もいれば●●だけの人もいる。フルネームの人もいれば苗字だけ名前だけの人もいるし、半角スペースがある人ない人いるし、連名の人も・・・

カテゴリの書き方がバラバラ

旅費と交通費って分ける必要ありますかね？何のためにこの項目が設けられているかを考えれば、旅費と交通費を分けて管理する必要はありません。ピポットしたときに同じ性質の予算として集計したいですよね。一応Excelにはドロップダウンリストがあるので、それを使えば制限できますが。

用途の空欄

250万円も使うのに、どこに何の業務を委託するのかわからない業務委託費。空欄にされてはまた聞き返す必要があるので二度手間です。

来年度の予算なのに今年度の支出が・・・

タイポなのか依頼の趣旨が伝わってないのか分かりません。

入力制限で一定の制限はかけられそうですが、Excelには限界がありそう。これが5件だけではなく500件を対象にしていたら集計作業も一苦労です。 Excelを見ただけでも、もっとスマートにしたくなるところばかりですが、プロセスにも問題があります。

メールでフォーマットをばら撒いて集めるのは時代遅れ

メール衰退期に入社した自分としては当たり前になっているチャットツールですが、ベテラン勢はメールと電話だけでよく業務がこなせていたなと今でも感じます。フォーマットをばら撒いてそれを返信させることは以下のムダに繋がります。もちろんチャットツールでも同じことですが。

・フォーマットを作るのがそもそもムダ
・ゴリゴリに入力制限を固めないとデータに揺らぎが生まれ、その最適化に係る稼働がムダ
・期限を過ぎても返信しない人を特定し、リマインドを送るというムダ
・集めたExcelを一つのExcelにマージするというムダ

Accessをベースとしたデータ管理

以前、私は上記のExcelをAccessに落とし込んでデータを管理していました。 Accessはデータベース管理ソフトとして有名なので、複雑なデータの集計や管理を実現するツールとして重宝されてきました。私は全くの素人ですが、先人の有識者によって作り込まれたAccessに頼らないと仕事にならない状態でした。

しかしAccessにも限界があります。まず、扱うデータが多くなるにつれて、処理速度が低下していきます。社内のスタンドアロンPC上に構築されていたため、同時編集ができません。さらに、日々変化する業務に対応するため、機能をメンテしようにも構造が分からずじまい。

Access上で、Excelフォーマットを吐き出してメールで依頼し、集まったExcelをAccessにアップロードし、集計結果を吐き出す、修正があればまたExcelをAccessに・・・という業務にうんざりしてしまいました。しかも1回のアップロードに数十分かかったり。

神（紙）Excelというリアルタイム性と完全性に欠けるファイル

正しく使えば便利なExcelです。私自身も業務で使うことは多いです。しかし、データ管理という点においては、Excelは非常に愚痴を言いたくなる場面が多いのです。

例えば、最初の例で挙げた来年度の予算調査において、各部署がそれぞれのExcelを保有することになります。経理部が提出したExcel、総務部が提出したExcel、営業部が提出したExcel、そしてあなたがマージしたExcel。どれも最新ですが、いずれどれが最新なのか分からなくなります。経理部が予算を修正して後日再報告しても、そのメールを見逃してしまったらマージ版には反映されません。こうなると目も当てられない状況となり、結局最新の予算計画はマージしたExcelで相違ないのか、またヒアリングする羽目になります。さらに、人によっては共有サーバにしっかり残す人もいれば、メールの内容が常に最新だと認識する人もいるし、PCローカルに保存して加工する人もいるかもしれません。

ある程度愚痴を聞いていただいたところで、どのようにこの状況から脱却すべきか考えてみましょう。

データの一元管理

まずはデータを一元管理していくことから始めます。誰がどんなExcelを持っていても構いませんが、元となるデータが一元管理されていることが重要であると考えます。

今はクラウドサービスが充実しているので、MicrosoftであればSharepoint、GoogleであればGoogle Driveのように、ファイル共有すれば一元管理は容易に行えます。

これでマージするムダはなくせそうですし、入力規則もメンテすればバラバラだった表記の揺らぎも抑止できてマシになりそうです。

また、一元管理することで全員が同じ神様ファイルを参照できるので、リアルタイム性の観点では良くなったと言えます。

ですが、まだ課題は残ります。フォーマットを作ったり、入力規則をメンテする点については改善されていません。また、全員が同じファイルを触ることになるので、経理部が誤って総務部のデータを上書きしてしまうリスクが増えてしまいました。

ではどうすべきなのか。

脱・神（紙）Excel

はい、Excel使うことをやめればいいのです。全ての元凶はExcelなのですから。

どんなツールでもそうですが、向き不向きがあります。あくまでもExcelは表計算ソフトであって、データ管理においては不向きだと判断しました。

そこで、AWSのサービスを使うことにしました。データ管理はAWS上で行い、データのインプットは専用のインターフェースを用意することで、各部門が用意に報告できる環境を構築したのです。

構成

データベースも初心者ですが、AWSも初心者でした。 S3って何？というレベルでした。ですが詳しい人に頼りながら少しずつ理解していくことで、今まで愚痴だったことが、ワクワクするような世界が見えてきたのです。

最終的に今回開発したシステムの構成を以下に載せます。

フロントエンド部分はスクラッチ開発ですが、その先のデータベース管理やデータ分析はすべてAWS上で行いました。いわゆるクラウドシフトなのですが、もっと早く取り組めばよかった、と後悔さえしました。データを一元管理できて、アカウントさえあれば誰でもアクセスできて、常に最新情報が手に届くって素晴らしい。 Excelでは実現できない世界ですよね。

効果

当初抱えていた課題の解消はもちろん、さまざまな副産物も得られました。

まず課題についてですが、以下の通り解消することができました。

フォーマット作成のムダ

各部門のユーザは、決められたインターフェースに直接データを投入します。インターフェースは自由にカスタマイズできるため、入力してほしい項目を並べておけばいいのです。一度作成すれば次回の依頼の際も手間なく対応することができます。

入力制限等の最適化に関わるムダ

各インターフェースには、データの型があらかじめ決められるので、日付や数字、テキスト等幅広く入力を制限することができます。必須項目であれば、入力しないと次に進めないよう制限することもできます。フォーマットと同じく、一度決めてしまえば次回以降の作成も不要なので、使い回すことができます。

期限を過ぎた部門へのリマインドのムダ

各ユーザにはアカウントを払い出して運用しています。そのため、誰がいつ何を入力/変更したのか、ログとして記録することができます。逆に、誰が何もしていないのかも抽出することができます。作り方によっては、自動的に未対応者へのリマインドメールやチャットを送信することもできますね。

集めたExcelをマージするというムダ

ここが非常に効果的でした。これまで、マージ作業に稼働がかかるため、各部門には短期間での報告をお願いしていました。そのため報告内容の精度が低くなることもありました。また、修正が入るたびにマージ作業をやり直し集計作業を行なっていました。 AWS上にデータを置くことで、分析ツールと連携することができ、最新のデータをマージすることなくグラフや表にまとめることができるのです。これにより、短期間で上司へ報告することができますし、上司自ら見たいときに見たいデータを、可視化された形で閲覧することができるようになりました。一例ですが、QuickSightを用いたデータ分析のイメージを載せておきます。

積上げグラフや表作成など、Excelで表現できることは大抵Quicksightで実現できます。フィルタの自由度も高いのでExcel以上の自由度があると考えています。イメージその２で選択した年度をクリックすると、その年度でイメージその３の表にフィルタをかけることもできます。

更新日時を指定してスナップショットをとっておけば、2つの時間軸間の比較も用意に行うことができます。

どうしてもExcelでガチャガチャいじりたい人向けには、Excel形式で出力することもできます。 2次加工はお好きにどうぞ、でも元データはここが神様だからね、という運用にしておけばデグレ防止にもなりますし、最新データを関係者間で共有することが容易になります。

また、各部門の担当者はこのグラフを見るだけで予算の積上げ状況を把握することができ、予算に対する意識も高まります。

最初の作り込みがとにかく大変！それでも・・・

業務都合上、どうしても複雑な設計にせざるを得ませんでした。初期構想から運用を開始するまで、およそ1年かかりました。ですが、明らかに将来的な効果が大きいことは分かっていたので、なんとしても実現させようと検討を重ねました。

最後にその苦労話も添えさせていただきます。

シナリオ検討

まずは大まかなシナリオを検討しました。シナリオとは、開発したツールをどのように利用するのか、想定される業務フローをアウトプットします。

私の場合は、まず一番頻繁に発生する業務シナリオをメインシナリオとして書き起こしました。いきなり細かいことまで考えるとキリがなくなり、やる気も低下していくので徐々にブレイクダウンしていくのがコツです。

次に、よく使うであろう機能のシナリオや例外的なシナリオ等、業務フローと情報のIn/Outと共に整理します。

ある程度イメージが具現化できたら、開発チームやツール利用者と意識合わせを行い、詳細検討に入ります。

テーブル検討

データベースの肝と過言ではないテーブル検討。設計をするうえで、一番重要であると私は考えています。（当たり前かもしれませんが）

まず、主キーとなるカラムを決めること。下の表だと、「001」や「002」が主キーになります。これが正規化するための第一歩です。

#	担当者	予算	支出月	カテゴリ	用途
001	鈴木一郎	1,000,000	2025年06月	旅費	海外出張費
001	鈴木二郎	300,000	2025年07月	備品費	ノートPC
002	鈴木三郎	2,500,000	2025年09月	業務委託費	保守業務
002	鈴木四郎	400,000	2025年04月	旅費	国内出張費
003	鈴木五郎丸	30,000,000	2026年03月	接待費	A社様

「001」に注目すると、鈴木一郎さんという社員が担当者になっています。この担当者のテーブルも用意してみましょう。

#	担当者	所属	電話番号	メールアドレス	ロール
01	鈴木一郎	経理部	090-xxxx-xxxx	xxxx@hogehoge.com	編集者

こうすることで、鈴木さんへのメール自動配信ができるようになったり、一郎さんに編集者という特別なロール権限も付与することができます。

カテゴリのように、あらかじめ入力規則を決めたい場合は、ドロップダウンリストとして以下のようなテーブルも検討するとよいでしょう。

#	カテゴリ
01	旅費
02	備品費
03	業務委託費

このようなテーブルはマスタテーブルと呼ばれ、定義を一元化することで正規化を実現できます。

上記のデータを集計すると・・・

#	部署	予算	支出年度
001	経理部	1,300,000	2025
002	総務部	2,900,000	2025
003	営業部	30,000,000	2025

このようになります。

このマスタも含めたテーブルの定義が何よりも重要であり、その分苦労しました。テーブル同士のリンク関係や、各テーブルの守備範囲を明確に定義しなければいけません。また、インターフェース上に入力できる型はどうするのか、初期値はどうするのか、必須項目とするか等、運用を見据えた設計をしっかり構築することで、その後の運用が大きく変わります。

新ツールへのデータお引越し

新ツールの作りこみができたらいよいよデータの移行作業になります。これもかなり苦労しました。旧Access時代のデータ量も膨大で、またそれぞれのデータも揺らぎがあったりごちゃごちゃしていたので、新ツールで綺麗に引き継ぐためにデータ補正を行いました。

産みの苦しみと思って何とか耐えるモチベーションと、将来楽になる姿を想像しながらパワーをかけました。

おわりに

良し悪しはさておき、愚痴やストレスも仕事に対する一つのモチベーションだと今回の施策を通して感じました。むしろ現状に満足していては効率化もできないし、よりよい仕事は生まれない、と私は考えます。増え続ける仕事に対して働き手は少なくなるこれからの社会。働き方を変えて効率化を徹底していかなければ、本当にすべき仕事に充てられる時間が足りなくなってしまいます。

自動化ツールや生成AI等、あらゆる技術が進化した令和時代。せっかくこの時代で働くのであれば、DX化をどんどん進めて行き、少しでも快適な仕事を実現させたいものです。もちろん、サイバー攻撃技術も進化しているのでそこは注意が必要ですが。

色々な仕事がありますが、すべて何かしらゴール（目的）があるはずです。目的を見失わなければ手段は無数にあると思います。交通手段も昔の徒歩に比べたら　車→電車→新幹線→リニアと進化し、それを活用しているのと同じように、業務を効率化していきましょう！