ID:25952さん

## 行なってきたことの概要 * 自社サービス popinfo の開発、保守運用を行ないました。 * 自社サービスをいくつかのコンポーネントに分け、複数のコンポーネントの責任者として、開発、保守、運用まで責任を持って行なってきました。 ## 背景(なぜ行なったか) ``` * 自社サービスはまだ開発段階であり、多くのissueが残っていた * サービスが多くの方に利用されるようになり、品質を強化するために保守運用を行う必要があった ``` ================================================================================= # 技術点なアピール点 - 開発として主に行なってきたこと ``` * 機能/API 開発 (Python、Django、JQuery、Vue.js) * インシデント管理・対応 (Python、Django、Nginx、Datadog、AWS) * 保守・運用(Python、Django、JQuery、Datadog) ``` ---------------- #### アピール点① - `Djangoのソースを読み理解できたこと` ### 困ったこと - Djangoで、 - Formの各fieldにrequiredオプションを設定しているのに、空文字列を入力してもFormset.is_valid()=>Trueっとなってしまっていた - 検索では原因がヒットせず、DjangoのOSSを深くまで読み込む必要があった ### 工夫したこと - DjangoのOSSを深くまで読み込み、原因を突き止めたこと - 学んだことをアウトプットし、同じ悩みを抱えている人にアドバイスしたこと ### 結果 - `原因を突き止めた` - `Djangoの開発がスムーズになった` - `アウトプット` - http://kohei1116.hateblo.jp/entry/2018/01/14/154929 - http://kohei1116.hateblo.jp/entry/2018/02/04/185918 ------------------------- #### アピール点② - `Nginxの検証で、TCPのレイヤーまで掘り下げて検証をしたこと` ### 困ったこと - NginxからS3にプロキシして画像取得を行なっている箇所で、数日に1度エラーが発生していた - クラウドを使っており、かつ平均100万リクエスト/日なので、ある程度仕方ないものではあるが、回避策を考えた - Nginxにはリトライの設定はないので、エラー時にリトライを行うことは簡単にはできなかった - 原因もstatus_code以外では読み取れず、TCPレイヤーまで掘り下げて検証をする必要があった ### 工夫したこと - Nginxのロードバランシングの設定を応用して、結果的にリトライさせる仕組みを作ったこと - upstreamにリトライ回数分サーバーを記述し、結果的にリトライをさせるようにした - stubのサーバーを立てて、同じ条件を再現させ、設定によりリトライを行なっているか検証したこと ### 結果 * `エラーが発生しなくなった` - `アウトプット` - http://kohei1116.hateblo.jp/entry/2018/02/04/104000 - http://kohei1116.hateblo.jp/entry/2018/02/17/193916

## 行なってきたことの概要 顧客満足度を向上させることを目的としてプロジェクトを発足させ、 責任者として運用をさせていただきました。 ========================================================================= ## 背景(なぜ行なったか) - 社内に以下の問題点があった - 社員数も会社の規模も大きくなっていく中、仕組み化して解決していく必要があると思ったから ``` * 社内で顧客満足度に関わる要望が生まれても、投げるあてがない(どこに投げれば良いのかわからない) * お客様からの開発に関わる要望で、一旦保留となったが放置されたままのものがある * 顧客満足度に関わる課題でどのようなものがあるか把握できない ``` ## 解決するための手段 - 上記の問題点を解決するために以下のことを行なった ``` * 社内からの顧客満足度に関わる要望を管理、解決する * 過去に一旦保留となった改善策を見直し、必要性や稼働を考慮し改修するか考え直す * 顧客満足度に関わる課題はどのようなものがあるかを知る ``` #### アピール点 - 解決すべき課題(以下 issue)の優先度を特定の指標や社内の計画を考慮し考えたこと - 優先度決めやissueの管理を仕組み化することができたこと ### 困ったこと * 解決するissueの優先度決め * 仕組み化していく必要もあり、主観的ではなくデータや指標を元に決める必要があった ### 工夫したこと * 狩野モデルの採用 * 採用理由 * 時間をかけることなく自分たちでもすぐに優先度をつけられるから * そのissueを解決するとどうなのか、解決しないとどうなのかという簡単な質問に対する答えを元に定量的に優先度が決められるもの * 企業に取り入れられている実績もあった * そのモデルに独自の指標を加えてプロジェクトのオリジナルの指標を決めた * 要望元顧客からの売り上げなど * その指標を全てのissueにかけ、優先度を決めた ### 結果 * `Issueの管理や優先度決めを仕組み化したので、開発に大きく工数をかけることができた` ## プロジェクト全体の結果 - 社内要望を多く解消していくことができた - 社内からの要望が明文化された - 他の社員も開発に協力していただき、社内を巻き込んで開発を行うことができた - このプロジェクトが社内で評価され、大人数でプロジェクトを進めることになった - マーケティング、PM、CS一体となって進めることになった - 仕組み化していたので、管理・運用はメンバーに引き継ぐことができた ================================================================================= # 技術点なアピール点 - 開発として主に行なってきたこと ``` * PythonでCS用コマンド作成 * Python/Djangoを用いたアプリケーション改修 * Python/Djangoを用いた新機能開発 ``` ---------------- #### アピール点① - `システムの利用者のユースケースに基づいた要件定義ができたこと` ### 困ったこと - 要件定義(特にCS用スクリプト作成) - 他人が使うものなので、ユースケースを把握する必要があった - どのようなオプションを設定できるようにすべきかわからない ### 工夫したこと - 繰り返しのヒアリング - 何度もヒアリングを重ね、本当に必要なものは何かチームで精査 - 過去のIssueを見返し、本質的に困っていることの調査 - 表面的な課題を見てしまう可能性があるため - 実は修正する必要がなかった場合もあるため ### 結果 - 要望を網羅するコマンドを作成し、`CSの方には長く利用`していただいている ------------------------- #### アピール点② - `SQLのパフォーマンスチューニングができたこと` ### 困ったこと - パフォーマンスを意識したチューニング - 100万レコードを超えるDB tableに対してQueryを投げることもあるため - 処理時間が長くなったORMを使ったコマンドを改修する場合もあるため ### 工夫したこと * ORMからSQLを読み取り、最終的に取得したいデータを把握し、それを最適なSQLに書き換えること * クエリキャッシュもサニタイズも注意しながら作成 * Queryに入力されたオプションを組み込む必要があるため * https://dev.mysql.com/doc/connector-python/en/connector-python-api-mysqlcursor-execute.html ### 結果 * SQLをかけてから`12時間ほどかかっていた処理を15分ほどで終わらせる`ことに成功した