Slide 1

Slide 1 text

密集、ドキュメントのコロケーション with AWS Lambda 2025.02.15 SATOSHI KANEYASU

Slide 2

Slide 2 text

2 自己紹介 氏名:兼安 聡 所属:株式会社サーバーワークス アプリケーションサービス部 在住:広島(フルリモート) 担当:DevOps、PM、SM、プリせ、トレーナー 2024 Japan AWS Top Engineers (Database) 2024 Japan AWS All Certifications Engineers Certified ScrumMaster PMP X:@satoshi256kbyte

Slide 3

Slide 3 text

3 コロケーションとは ➢ コロケーションとは、関連するリソースを近くに置くことを指します。 ➢ コロケーションは、Next.jsの公式ページが参考になります。 ➢ コロケーション自体は設計書だけに焦点をあてたものではないのですが、私のチームではこれをバックエンドプログラ ムの設計書に適用してみました。

Slide 4

Slide 4 text

4 やってみたコロケーションのイメージ ➢AWS LambdaとPythonによるバックエンドのプログラムでやってみました / ├── app │ ├── function_a │ │ ├── handler.py │ │ └── README.md │ ├── function_b │ │ ├── handler.py │ │ └── README.md │ └── function_c │ ├── handler.py │ └── README.md ├── docs │ ├── database.md │ └── system_diagram.drawio └── README.md 業務ごと(=AWS Lambda関数ごと)でディレクトリを分けている これが設計書、いわゆるプログラム設計書に相当 プログラム テーブル定義、構成図など機能・業務を跨ぐものはここ

Slide 5

Slide 5 text

5 このような構成にした理由 ➢ 設計書はシンプルにしたい(スクラムで回してるので余計そう思う) ➢ 設計書もプルリクエストを回したい ➢ 何がどこにあるか見通しをよくしたい ➢ 後から来る人にもわかりやすくしたい

Slide 6

Slide 6 text

6 現在の構成に至るまでに考えた他の構成候補 / ├── app │ └─── functions │ ├── function_a.py │ ├── function_b.py │ └── function_c.py ├── docs │ ├── database.md │ ├── function_a.md │ ├── function_b.md │ ├── function_c.md │ └── system_diagram.drawio └── README.md / ├── app │ └─── functions │ ├── function_a.md │ ├── function_a.py │ ├── function_b.md │ ├── function_b.py │ ├── function_c.md │ └── function_c.py ├── docs │ ├── system_diagram.drawio │ └── database.md └── README.md 実案件ではもっと関数が多い 場所が遠くで探しづらい functions配下が煩雑 実際には関数の名前はもっと不規則 なのでかなり見づらい

Slide 7

Slide 7 text

7 この構成における設計書で書くもの ➢ Markdownで書く ➢ 機能の概要 ➢ 何をする機能か ➢ 大まかな処理の流れ ➢ 入出力内容 ➢ パラメータ ➢ 出力するファイル・データのフォーマットなど ➢ 使用方法/テスト方法 ➢ フローチャートやシーケンス図は開発者からの需要がなく、メンテ負荷になったのでカット ➢ Marmaidも不採用、AWSを使用してるのでアイコンが揃ってるdraw.io/Cacooで書いた方が良いとなった

Slide 8

Slide 8 text

8 メリットとデメリット メリット デメリット ➢ 目論見通り、見やすい ➢ プルリクエストで設計書がレビューできる ➢ 設計だけできてるのか?実装まで済んでるの いか?がツリーに表れる ➢ 設計書の配置に関してはやり切った感があり、 最近設計書の配置に関する無駄な議論がない ➢ ディレクトリ構造そのものに工夫を入れてい るので、他のPJにも展開できると言い切れな い(AWS Lambdaを使用してるからできてる とも感じる) ➢ レビュアーがGitに入らないといけない

Slide 9

Slide 9 text

9 その他の悩み ➢ 設計書を非常にシンプルにしているが故に、なぜその機能がそうなっているのか?というのは語りきれていない ➢ これを補うために「意思決定の経緯」を文書として残っている(=ADR) ➢ 故に、実は設計書よりBacklogの方が情報量が多い・・・ ➢ BacklogでPBI/SBIを管理 ➢ ソースコードと設計書はGit ➢ ADRはBacklogのWiki

Slide 10

Slide 10 text

10 まとめ ➢ 導入にはディレクトリ構成レベルでの工夫が必要になりますが、ドキュメントをコロケーションすると快適だと思います ➢ もし試されたら意見交換しましょう

Slide 11

Slide 11 text

No content