むーてく

## サービス概要 PDFの給与明細書および賞与明細書を決まった場所にアップロードすると、自動で情報を読み取りダッシュボードで蓄積された情報を閲覧できるようにするサービス。 ## リポジトリ https://github.com/mu-editech/sgg ## 構成 S3に給与明細書あるいは賞与明細書をpdfのままアップロードすると、SNS経由でイベント情報がメインの処理機構へ走り、PDFから抽出したデータをS3あるいはDynamoDBに格納する。 最初はLambdaでメインの処理をするフルサーバーレス構成を考えた。 たまにしか稼働せず稼働時間も短いため、アイドリングの時間に課金されないようなシステムが望ましいと考えたからである。 また、EC2を使う構成より構成の管理もコードでできる部分が増えるので、保守性や開発効率が向上するという点も理由として挙げられる。 しかし後述する技術的課題が発見されたため、メインの処理をする部分を三通りの方法で実装を試みた。最終的には「Fargateで構成したパターン」の構成を採用した。 1. EC2で構成したパターン 2. AWS_Lambdaで構成したパターン 3. Fargateで構成したパターン ## 開発背景 * 給与明細や賞与明細を集計して、いままでの残業時間や給与のトレンドおよびサマリーを一望できるようにしたかったため。 * 「帳票データの読取りと集計」という観点で見てみれば、他にも応用が効きそうな開発拡張性があると考えたため。 * 業務で扱わない技術に挑戦する場とするため。 * 複数通りの実装方法が考えられたので、それぞれの方法のメリット・デメリットを比較しつつ最適な実装方法を実験するため。 ## 発見した技術的課題とその対応 ### 課題1:ライブラリの大きさ PDFの行列表をCSVに変換するというところで、どのライブラリを選択しようとも以下二点の難点が発見され初予定していたLambdaに搭載できないことが判明。 1. ライブラリがyumリポジトリで取得するツールも多用している 2. ライブラリのサイズが大きすぎて[Lambdaの制限](https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/limits.html)に抵触している。 したがって以上の条件をクリアしつつイベントドリブンなシステムを構築するため、コンテナでサービスを設計し直す事を発想した。 ### 課題2:データ仕様が不確定 給与明細の項目を見ると、ある時点で突然列項目が増加したり順番が変更になったりしていることが判明。 RDBのテーブルのように列項目を固め打ちする方法では都合が悪いということ、保持されるデータはinsertとselectが必要な処理であり複雑なJOINなどは不要であることからDocument storeのDynamoDBに変更した。 ## 得られたもの **業務では扱わない技術の習得** 最初は自分で理解している範囲の技術を使ったシンプルなシステムを開発しようと目論んだが、上述の技術課題が発生し設計をやり直す必要があった。 具体的な技術課題に遭遇してコンテナやNoSQLなど耳にしたことはあったが初めて使用する技術に触れることで、新技術の習得はもちろん、その技術のメリットや適用すべきシチュエーションも身体で理解することができた。

## 取り組み概要 自らチームを作り、リリース日を設定して写真投稿Webサービスの開発を行った。 フルサーバーレスと従来型のWeb三層構造の２通りの実装方法で、「写真の投稿」という同じ機能を達成するシステムを開発することにより、両者のメリット・デメリットを検証し、成果をまとめた。 サーバーレスの実装に関しては、以下の書を大いに参考にした。 [西谷圭介『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』](https://book.mynavi.jp/ec/products/detail/id=89081) #### スライド資料 https://speakerdeck.com/mutech/serverlessheyoukoso #### 結論 サーバーレスの方が圧倒的なコストメリットや開発期間の短縮がはかれる一方、新興の技術でもあるため開発難度が上がる点がネックとなることが判明した。 ## 取り組みの背景 業務の縛りを超えた自由な実装の場でサーバーレスシステムを作れないかという発想が始まり。業務でAWS Lambdaを使うようになり、サーバーレスの魅力を感じるとともに、新しい技術を使って自分も一気通貫したものづくりをやってみたいと考えるようになった。しかし当時新人だった自分は業務では与えられた大システムの一部の実装課題を解くことで精一杯であり、自分の裁量に従って自由な技術開発をするような試みはできなかった。そこで会社に貢献する成果を上げることを条件に、好きに実験や実装ができる制度を利用し、開発意欲はあるが業務では開発ができていない同僚二人を集めてチームを立ち上げ応募し、本取組をスタートさせた。 最初は * はじめからWebサービスを作りたい * ただ作るだけでなく、一般に公開して運用までした経験を含めて最終成果発表に盛り込みたい * 小さくてもいいから社会課題を解決するようなプロダクトにしていきたい と考えていたが、野望が大きすぎたため最終的にはサーバーレスという技術そのものにフォーカスをあてたプロダクトを作り、技術実験の色を強く出すことで意義を出すこととした。具体的にはシンプルな写真投稿サービスを想定し、**同じ機能を実現する複数通りの実装をすることで、開発経験値を上げつつ両者を比較し、それぞれの長所短所を割り出していくという取り組み**にした。 取り組みのおおきな目標としては、以下を設定した * サーバーレスの技術実装を通じて、メリット・デメリットを検証する * チームメンバー全員が実装を通して技術的成長をはかれるようにする ## この取組を通して得たもの 自分で企画立案から実装、テスト、成果のまとめと発表まで、自分で立ち上げたチームのマネジメントも含めて一気通貫に実践できた本取り組みからは特に以下について学びを得た。 ### 実装技術力 当時の自分は業務では大きなシステムのほんの一部をサーバーレス化しただけであり、それがシステムにおいてどのような位置付けにありどのような点で有用なのかはわからなかった。この取組を通して実際にシステムを設計から組み上げることで、クラウドのマネージド・サービスを疎結合にどのように適用するのがベスト・プラクティスなのかを体を通して理解することができた。またサーバーレスそのものの理解や現在進行系で繰り広げられている業界を理解するため[Serverless-conf](http://tokyo.serverlessconf.io/)のハッカソンやカンファレンスにも出席し、会社外のエンジニアとのハッカソンや交流への参加も行った。腕に覚えのある他社のエンジニアと共同でプロダクトを作った経験は、使用しているツールや言語の知識に始まり、様々なマネージドサービスの実装方法、チームでのワークの進め方まで大いに本取り組みに参考にした。 また、従来型の実装を行ったことも大いに学びになった。Webシステムを一つ完成させる体験の中で、実装を通じて体系的に知識と経験を得ることができた。業務では人員が必要になった部分の実装やテストしかやらないため、システムを考えて組み上げていく経験は少ない。さらにサーバーレス（マネージド・サービス）という新しい在り方の恩恵を本質から理解するには、そうした新技術の登場前に存在した技術的課題がどのようなものだったのか、体験を通じて理解することが肝要となる。オーソドックスな手法の中にはサーバーのメンテナンスやセキュリティ対策、帯域の確保等アプリ開発に行き当たるまで考慮事項が様々に存在していることを知ると同時に、サーバーレスが克服しようとしている方向性がこうしたところにあることをより深く理解することができた。 ### マネジメント能力 メンバー全員の技術経験値上昇を取り組みの目標としていたため、機能ごとに実装担当をわける方式ではなく、全員がプロジェクタの大画面を見ながら交代で実装する方法を取った。これが「モブプログラミング」という名前を持っていることは後で知ったことであったが、同僚同士というのもあり初歩的な技術的不明点も素直に「わからない」と言いながら解る者が解説しつつ作業を進めた。結果全員がWebを支える技術一式を理解することができた。 また、私以外は開発の中でバージョン管理ツールやチャットツールと監視サービスの連携等を利用したことがなかったため、GitやJIRAなどを導入し、ブランチモデルや開発の手順についてメンバーに共有することで、チームでの開発をスムーズにすすめていくことにも気を配った。開発を支える体制を構築したこともスムーズな開発につながったと思われる。 開発を進めていく中では、各人のモチベーションをどのように維持していくかという点を最も注意しながら進めていった。最初「同僚だから」という理由だけで声をかけた仲間たちであったため、大したつながりもない人間と業務外で責任も発生しない取り組みを一年弱続けてもらうためには自ら楽しんで取り組みに参加してもらうべきであると考えた。最初にどのような技術や知識を今後身につけたいのかを聞き取り、それに合致するような取り組み内容を設計できるようにしていった。また、取り組みをやっていく中で、各人は自分すら気づいていなかった自身の得意分野が明らかになってきたため、途中で他のメンバーの理解が乏しい技術領域がでたとき、得意なメンバーに講師を頼むこともした。調べて話し、質問を受ける機会をもうけたことで、受け身で学習するよりもさらに学びが進み、結果各人の学習意欲を継続的に満たすことができ、最後まで全員で完遂することができた。 ## 本取組みの今後の課題 * CloudFormationやTerraformなどのインフラ自動化。 * テスト自動化・ビルド自動化を含むCI/CDを回せるような実装やチームづくり