ID:692さん

## 参加時の状況 4月に入社して間もなく既存サービスの一部を切り出す形で新規メディアサイトを立ち上げることとなり、その開発を任されました。 サービスの特性上、8月が繁忙期のためそれまでにリリースしたいとのことで開発期間は約2.5ヶ月でした。 体制は ディレクター1名、デザイナ2名、エンジニアは2名で私のみ専任。もう一名は既存サービスの開発の傍らでサポートしてもらい、主に既存サービスとの連携部分を担当してもらいました。 関連記事：[いこレポ はじめました。](https://tech.actindi.net/2017/08/14/ikorepo.html) ## システム設計 既存サービスからの独立なのでおおよその要件は決まっているも同然でした。 その上で新たに実現したい機能をディレクターとコンテンツを作る編集チームと調整して詰めました。 その結果、開発するアプリケーションとしてはRailsアプリケーションとして難しそうな部分はないと判断できました。一方で、リリース後も運用に自分以外のリソースを割いてもらえない状況が見えており、できるだけ手放しで運用できるようにインフラを構築する必要があると考えました。 ### 運用環境インフラ 次の理由からDockerで運用することを最初に決めました。 - 本場同様の環境で開発を進められること - Dockerfile にサーバの構築手順がコード化できること - 将来的なOS、Rubyのアップデートもアプリケーションのデプロイと同時に可能で容易 - 自分の技術的な興味 ローカルで一通りRailsが動かせるDockerイメージを作った後、本番での稼働環境を検討しました。AWSで運用することは決まっていたため、ECS等いくつかの候補を検討した結果 ElasticbeanStalkが最もAWS側でやってくれることが多そうなので採用することとしました。それを軸に必要なネットワーク設計等を行い構築しました。 ## アプリケーション開発 アプリケーション側の開発ではサイトを訪問するエンドユーザ側のUIが最も重要ですが、 コンテンツの表示を行うのみで特にインタラクティブな機能は不要でした。 幸いデザイナはSlimテンプレートを書けたのでおまかせすることにしました。 一方、管理側の機能は私が担当しました。 コンテンツを作成するCMS機能の使いやすさが運用上重要で、開発を効率化するためにJSのフレームワークを導入することは最初に決めていました。Reactと比較した結果Vue.jsのほうが使いやすいと判断し、採用しました。Vue.jsの学習に多少時間がかかったものの、難しかったのはCMS機能のみであとは想定通りの開発難度で開発は進められました。 また、過去の失敗経験から既存サービスから移行してくるデータについては開発初期に変換スクリプトを使ってデータ移行しました。移行処理の中でデータ補間と変換でクリーニングしデータに起因する不具合を排除しました。 ## CI環境 開発前半で本番用のインフラを構築後はGithubで管理しているリポジトリのmasterにpushすれば本番用にDcokerイメージをビルドし、デプロイできる仕組みを構築しました。 当初はJenkinsを導入しようと検討していましたが、1日数回しか使わないサーバを稼働させるコストと運用の手間が惜しくなり、CodeBuildとCodePipelineを利用してサーバレスな仕組みを構築しました。これによりコストダウンでき、サーバ運用の手間から解放されました。 リリース前には上記と3つのステージング環境のみしか用意できなかったのですが、リリース後GithubのpullrequestにpushするとRSpecを実行できるように開発時のテストを効率化しました。これもDocker、CodeBuild、Lambdaを使って処理しサーバレスで実現しています。 ## リリースとその後 利用頻度の低いいくつかの管理側の機能の開発を先送りしたものの、予定通り7月末にリリースを果たしました。 リリース後は大きなトラブルもなく安定稼働し、月間100万PV超えるサイトに成長しました。 当初の目論見通り、Elasticbeanstalkは運用の手間を最小にしてくれていますし、Rubyのアップデート等もDockerのおかげで手間なく実施できています。

## 自社メーリングリストサービスを中心にサービスの設計、開発、運用を担当。 ### 参加時の状況 2013年のサービスサイトのリニューアル時に入社。 リニューアル開発のリーダーとして開発に参加し、Railsを利用してAPIサーバの開発を行いました。 リニューアルの目的はスマートホンへの本格対応と老朽化したシステムを作り直すことによるパフォーマンスとメンテナンス性の向上でした。 入社の時点で、要件定義はほぼ終わっており、 リニューアルによりフロントエンドとAPIサーバに完全に分離するシステム構成とすること、 既存システムのDBは変更せず、アプリケーションのみの開発を行うと決まっていました。 リソースが足りないためフロントエンドは外注することも決まっていました。 ### リニューアル開発 最初にDBスキーマの分析および既存機能の構造分析を行い、各機能パートを分割しました。 それぞれの機能に必要なAPIを設計して実装に臨みました。 実装に際してはまず、APIのモックを制作しました。 それによりフロントエンドの開発も並行して進めることができ、 設計時の仕様不備も早期に発見することができました。 仕様不備は外注業者と調整し、仕様を修正しながらAPIの本実装を行いました。 フロントエンドは機能ごとに一つのSPAとなっており、それを一つづつ作る形で開発工程をすすめました。 旧システムのログを調査しよく使われる機能、時間がかかっている処理についてはパフォーマンス・チューニングも行いました。 テストカバレッジ90%を目標にRsecによるテストドリブンな実装を行い、品質向上を図るとともにリニューアル完了後もテストをベースに開発できるようにしました。 若干の遅れはあったもののほぼ目標通り約五ヶ月で開発を終えリリースしました。 しかし無事にというわけではなく、リリース直後から多数のユーザ様からのお問い合わせと不具合報告をいただく状況となりました。 リリース前には実際のサービスデータを用いて動作テストを行っていましたが、 そのときに検出されなかった想定外のデータがに起因して発生するものが多く、 ログを頼りに対応の優先度をつけ、デバッグを行いました。 （開発時にDBのスキーマだけでなくデータの分析にもっとリソースを割かなかったことは今でも後悔しています。） テキストのログ検索では効率が悪いため、Fluentを導入し、MongoDBにログを格納するように変更しました。ログ調査は効率化しましたが、オンプレで運用していたため用意できるサーバにも限界があり、やがてログの量が多くなると効率が落ちていきました。そこで当時サービスを開始し始めたBigQueryにログをすべて格納するように変更して調査を行えるようにしました。それによりデバッグの効率が向上し約1.5ヶ月で初期不良をほぼ解消しました。 ### リニューアル後 リニューアル終了後、スマホ向けアプリをリリースすることとなり、スマホ向けの追加APIの開発を担当、アプリエンジニアと協力しながら、リリースを行いました。 その後はサーバサイド開発のマネージャとしてチームの運営をしながら自らは主に新規機能の開発を約3.5年間担当しました。 開発手法：スクラム 規模：会員数 数百万人

・小規模施設向けにネットワーク対応デジタルフォトフレームにコンテンツを配信する簡易なシステムの開発を行いました。 担当フェーズ：要件定義、仕様作成、実装、構築 PRポイント： ・開始からリリースまで一人で開発。 ・小中規模(端末50台程度)のデジタルサイネージ向けに少ない手順で配信できるように機能を絞り込み開発した。 ・初期開発は約3ヶ月。以降別プロダクトの開発、メンテナンスを行いながら機能追加・改善を担当しました。