ExcelのWBSを捨てずに、AWSサーバーレスの進捗管理ツールへ置き換えた

はじめに

仕事のプロジェクトで、WBS（作業分解構成図）を Excel で管理していました。困っていたのは次の3つです。

• どのファイルが最新か分からない（WBS_最新_修正版(2).xlsx が増えていく）
• 全体がどこまで進んでいるのか、開いて数えないと分からない
• 先週から何が動いたのかを、毎週手で拾っている

そこで、Excel の WBS を取り込んで進捗を画面で見られるツールを、AWS のサーバーレス構成で作りました。いまはチームで実際に使っています。

この記事は5本のシリーズの1本目で、全体像を書きます。

1. ExcelのWBSを捨てずに、AWSサーバーレスの進捗管理ツールへ置き換えた（この記事）
2. Excelとの往復を壊さない取込の作り方（下見・全件主義・列の持ち方）
3. 同じAWSアカウントに似た名前のスタックが同居しているときのデプロイの守り方
4. テストが通っても安心できないので、実装をわざと壊して確かめる仕組みを作った
5. 作った進捗管理ツールに入力が集まらなかったので、入れてもらうための機能を足した

方針：Excel を捨てない

最初に決めたのは「Excel を捨てない」ことです。

WBS を書く人は Excel に慣れています。いきなり「今日から画面で入力してください」と頼んでも、手元の Excel で書いてから写す、という二度手間が増えるだけです。

そのため、Excel の取込と出力を、画面での編集と同じ扱いの機能として作りました。

やり方	使う場面
Excel を取り込む	最初の登録、まとめて書き換えるとき
Excel に出力して直し、また取り込む	慣れた形で一括編集したいとき
画面で直接直す	実績日や進捗を1件ずつ入れるとき

どれを使っても同じデータに入ります。画面で直接直す人が増えれば、少しずつ Excel から離れていけます。

できること

• ダッシュボード（全体の進捗率、遅延件数、今週完了の件数、遅延タスクの一覧、週ごとの推移）
• ガントチャート（階層の折りたたみ、今日の線、「今日あるべき進捗」の目盛り）
• タスク一覧（検索、絞り込み、一括更新、一覧からその場で「今日完了」）
• Excel の取込（下見してから反映）と出力
• 案件の作成・切り替え・アーカイブ
• メンバーの招待と権限（閲覧のみ・編集・管理者の3段階）
• Teams への通知（タスクの変更、週次サマリ、異常）
• 工数・先行タスク・コメント・当初計画（ベースライン）との比較

画面はダミーのデータで撮っています。

構成

サービス	役割
CloudFront + S3	画面（React の SPA）の配信。S3 は非公開のまま OAC で配る
Cognito	ログイン。招待制で、自分で登録はできない
API Gateway	REST API。Cognito で認証する
Lambda（API）	認可と、タスク・案件・メンバーの読み書き
Lambda（取込）	Excel を読んで検査し、差分を出す
Lambda（出力）	Excel を作る
Lambda（履歴）	DynamoDB Streams から変更履歴を書き、Teams に通知する
Lambda（週次）	毎週月曜に進捗を控え、週次サマリを送る
Lambda（異常）	CloudWatch アラームを受けて Teams に流す
DynamoDB	データ。テーブルは1つ
S3（取込用）	Excel の受け取りと出力先。一定期間で自動削除

インフラは AWS CDK（Python）で書いています。Lambda は6本で、すべて Python です。

データの持ち方

DynamoDB のテーブルは1つにまとめ、ソートキーの頭で種類を分けています。

種類	PK	SK
案件	PROJECT#<id>	META
タスク	PROJECT#<id>	TASK#<taskId>
メンバーと権限	PROJECT#<id>	USER#<userId>
変更履歴	PROJECT#<id>	HIST#<taskId>#<時刻>
週次の控え	PROJECT#<id>	SNAP#<日付>#<taskId>
取込の記録	PROJECT#<id>	IMPORT#<importId>
コメント	PROJECT#<id>	CMNT#<taskId>#<時刻>
当初計画	PROJECT#<id>	BASE#<日時>#<taskId>

ほとんどの読み出しは「この案件の、この種類」なので、PK を指定して SK の前方一致で引けば足ります。ユーザーから参加している案件を引くときだけ、権限のアイテムに付けた GSI を使います。

設計で決めたこと

WBS 番号をキーにしない

WBS 番号（1.2.3）は、行を1つ挿入すると後ろが全部振り直されます。これをキーにすると、番号が変わった瞬間に履歴やコメントとのつながりが切れます。

そのため、タスクには英数字だけの ID を別に振り、WBS 番号はただの属性として持っています。Excel に出力するときは、この ID を非表示の列に入れておきます。直して取り込むと、ID で元のタスクと突き合わせます。

ID に日本語や記号を使わないのは、URL のパスに載るためです。実際、日本語とコロンを含むメンバー ID を作ってしまい、削除の API が正しく受け取れなくなったことがありました。

認可は API 側に置く

すべての API で、最初に「この人はこの案件で何ができるか」を DynamoDB から引いて判定します。

画面でも、閲覧のみの人には編集ボタンを出していません。ただ、これは使いやすさのためで、守りの本体は API 側です。

Excel の取込は S3 に直接上げる

API Gateway には、リクエストの大きさ（10MB）と時間（29秒）の上限があります。Excel を API に直接送ると、大きなファイルで引っかかります。

そこで、API は署名付き URL を返すだけにして、ブラウザから S3 に直接アップロードしています。S3 のイベントで取込の Lambda が動き、画面は結果をポーリングして待ちます。

同時編集は版数で止める

タスクに version を持たせ、更新するときに「読んだときの版数と同じなら書く」という条件を付けています。外れたら 409 を返し、画面に「他の人が先に更新しました」と出します。

変更履歴は Streams から作る

変更履歴を API の中で書くと、新しい更新の口を足したときに書き忘れが起きます。DynamoDB Streams から履歴の Lambda を動かすと、どこから書き換えても必ず履歴が残ります。

ただし、削除のイベントには「誰が消したか」が入っていません。API で削除する直前に updatedBy を書いておき、Streams の削除イベントに残る直前の値から読んでいます。

Teams 通知は Workflows を使う

Teams の Office 365 コネクタ（Incoming Webhook）は2026年5月に使えなくなりました。いまは Power Automate の Workflows で Webhook を作り、Adaptive Card の形で送っています。

通知の量は、まとめ方で調整しています。

契機	まとめ方
画面での追加・更新	タスクごとに1通
Excel の取込	1回の取込で1通（先頭10件の明細つき）
削除	1回の処理で1通

開発のしかた

このツールは、最初は Claude（チャット）と相談しながら作り、途中から Claude Code に移しました。コードの多くは Claude Code が書いています。

移してから気をつけたのは、引き継ぎの資料（CLAUDE.md）に「なぜそうしたか」と「一度踏んだ罠」を必ず書くことです。罠は25個を超えました。そのうちいくつかは、このシリーズの後の記事で書きます。

	数
Lambda	6本（共通レイヤー1つ）
Lambda のテスト	404件
画面のテスト	43件
わざと壊して確かめる検査	48項目

費用

Cost Explorer で、このツールが使っているサービスの請求額を見ました（ドル）。

サービス	8月	9月
DynamoDB	0.018	0.005
S3	0.013	0.002
API Gateway	0.011	0.005
合計	0.041	0.012

1か月で数円です。Lambda・CloudFront・Cognito は無料枠に収まっていて、請求に出てきませんでした。8月が多いのは、Excel の取込を何度も試した月だからです。

この表は、同じアカウントに同居している別のアプリの分も含んだ上限です。リソースには Project=WBS のタグを付けていますが、コスト配分タグを有効にしていなかったので、タグでは分けられませんでした。

ちなみに、Cost Explorer の API は1回の呼び出しで0.01ドルかかります。9月の請求でいちばん大きかったのは、このツールではなく Cost Explorer でした。

おわりに

Excel を捨てずに置き換えたことで、使う人のやり方を大きく変えずに導入できました。

一方で、作って終わりではありませんでした。実際に使い始めてから数えてみると、入力がほとんど集まっていなかったのです。その話は5本目に書きます。

次の記事では、Excel との往復を壊さないための取込の作り方を書きます。